Hi,

Thanks for reply.

On Sun, 09 Jun 2024 18:04:32 +0100,
Jeremie Courreges-Anglas <jca@wxcvbn.org> wrote:
> 
> On Sun, Jun 09, 2024 at 11:03:54AM +0100, Kirill A. Korinsky wrote:
> > On Sat, 08 Jun 2024 23:35:32 +0100,
> > Kirill A. Korinsky <kirill@korins.ky> wrote:
> > > 
> > > Probably it worth to add an -extra flavor with all features.
> > > 
> > 
> > Here small update for net/tcpflow which includes:
> >  - add textproc/tre to enjoy regexes;
> >  - extended flavor to use cairo and exiv2.
> 
> tcpflow isn't linked against libexiv2 and its header files aren't
> included because HAVE_EXIV2 isn't defined.  portcheck warns about it.
> So exiv2 doesn't bring any feature and it doesn't make sense to add
> it as a dep.

Frankly speaking the last 30 minutes I spent to dig why here missed
HAVE_EXIV2, and my investigation lead to quite large commit without any
exaplanation: [1] the commit where check for header was introduced and [2]
the commit where such HAVE_EXIV2 was introduced.

I doubt that it was tested by anyone, and this code seems to be out of use.

Thus, in future version of dfxml such dependency was removed, so, no need to
keep note about it.

> Regarding cairo support I don't know if it is useful.  What bothers me
> is that configure.ac adds a bunch of other libraries because upstream
> uses a static link there on mingw.  Self-inflicted pain, and extra
> libs look extra.  LIB_DEPENDS=archivers/bzip2 just look bogus, cairo
> doesn't depend on it in our tree.
> 
> To me this all looks fragile and I wouldn't link a privileged tool to
> such libraries.  You don't *have* to ship such a FLAVOR.

Thanks. I absolutley agree that cairo and other stuff looks fragile and
wired, special for that software.

> So that leaves the addition of textproc/tre (I didn't look)

I jsut spent antoher hour into this code to figuring out how to use it to
test. I do not understand. All cases inside different scanners which should
configure it, simple hasn't got a way to do it.

Nor any documentation about it.

Seems that it also useless here.

> and theneed to add --without-o3 because the build currently uses -O3
> instead of respecting CFLAGS.

Very good point.

Also, I abit tired from created report.xml by tcpflow when using it with -c
and suggested a patch to upstream to avoid that [3] which I've included into
updated diff.

Footnotes:
[1]  https://github.com/simsong/dfxml/commit/81fa0e842f7c89be5d90ce7c2343e8b1468baa99

[2]  https://github.com/simsong/dfxml/commit/8915c81dd7a0271cf1e4fcb231acbc8497ea5884

[3]  https://github.com/simsong/tcpflow/pull/260

The diff:

diff --git net/tcpflow/Makefile net/tcpflow/Makefile
index 094dcec0696..a2720a25f82 100644
--- net/tcpflow/Makefile
+++ net/tcpflow/Makefile
@@ -3,6 +3,7 @@ COMMENT=		tool for capturing data from TCP connections
 V=			1.6.1
 DISTNAME=		tcpflow-${V}
 CATEGORIES=		net
+REBISION=		0
 
 SITES=			https://github.com/simsong/tcpflow/releases/download/tcpflow-${V}/
 
@@ -20,13 +21,12 @@ COMPILER=		base-clang ports-gcc
 BUILD_DEPENDS=		devel/boost
 LIB_DEPENDS=		databases/sqlite3
 
-# a test for cairo has a side effect which brokes pcap test
-# when it can't find cairo, so, disable it.
-CONFIGURE_ARGS=		--enable-cairo=false
+CONFIGURE_STYLE=	autoreconf
+
+CONFIGURE_ARGS=		--enable-cairo=false \
+			--without-o3
 
 AUTOCONF_VERSION=	2.71
 AUTOMAKE_VERSION=	1.16
 
-CONFIGURE_STYLE=	autoreconf
-
 .include <bsd.port.mk>
diff --git net/tcpflow/patches/patch-src_tcpflow_cpp net/tcpflow/patches/patch-src_tcpflow_cpp
new file mode 100644
index 00000000000..73153370651
--- /dev/null
+++ net/tcpflow/patches/patch-src_tcpflow_cpp
@@ -0,0 +1,12 @@
+https://github.com/simsong/tcpflow/pull/260
+Index: src/tcpflow.cpp
+--- src/tcpflow.cpp.orig
++++ src/tcpflow.cpp
+@@ -632,6 +632,7 @@ int main(int argc, char *argv[])
+ 	    demux.opt.suppress_header = 1;	DEBUG(10) ("packet header dump suppressed");
+ 	    break;
+ 	case 'c':
++            opt_enable_report = false;
+ 	    demux.opt.console_output = true;	DEBUG(10) ("printing packets to console only");
+ 	    break;
+     case '0':


-- 
wbr, Kirill