Hi, I'm unsure on how to should fix this correctly. Recently we gained include/byteswap.h via commit 1761b09bf42d2842e82c1ac614c23d31c4d4c0dc (see https://lists.freebsd.org/archives/freebsd-current/2023-March/003357.html) which also got backported to stable/13 and is included in 13.2-RELEASE. In https://cgit.freebsd.org/ports/tree/Templates/config.site#n119 we hardcode it as not available which seems to break at least dns/dnsjit. Reference: https://lists.freebsd.org/archives/freebsd-pkg-fallout/2023-July/452527.html If I override our config.site ( CONFIGURE_ENV= ac_cv_header_byteswap_h=yes ) it compiles so perhaps we need to do some kind of split config until 12 is deprecated? The code itself looks alright to me, https://github.com/DNS-OARC/dnsjit/blob/v1.2.3/src/input/fpcap.c Best regards, Daniel
I can only repeat the dilemma which you and others are aware of and stated in more detail than what I comprehend of what I withnessed happening. And I have no clue of the impact; I would expect 'capture' may be much FreeBSD, while 'parsing' many Linux (since that probably is often cloud-based), and 'replay' in between. But wether the actual number of users may be zero users - or thousands of users with X number of daemons, I have no indication at all. Plus, even that number has relative meaning in relation to importance. I will try (later this week - or next) the split config, or else mark 12 as broken.
so either you use the whole gnu/glib solution, or use the whole BSD one. using half and half is impossible because they define different things, sadly. I'd override the hard coding, and who cares if 12 is broken. If it is broken by the decoupling, then let it be broken... there's only a few more weeks / days left of 12 support anyway, and that's an acceptable fallout imho.
Created attachment 244003 [details] dnsjit 1.2.3 with gnu Added the byteswap, and adjusted the pcap "problem" of PR262976
Created attachment 244005 [details] dnsjit 1.2.3 w/o gnu > use the whole gnu/glib solution, or use the whole BSD one. > What about the latter option - as in this attachment? Poudriere says it's all fine.
Instead of hacking the port we should look into https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273032
(In reply to Daniel Engberg from comment #5) The only "hacking" related to the PR was going from GNU_CONFIGURE to HAS_CONFIGURE. I've spotted this relevant mutation now already is in the current ports, so I guess this PR can be closed ..?
Yeah somehow I was on a shooting spree for fixing all the ports broken on 14 and fixed this without checking this bug. But on another note this is relevant for another big fix so I will keep it open for diizzy@ until he fixes it properly. :)
Created attachment 250256 [details] Patch for dns/dnsjit Based on Leo's patch Remove net/libpcap dependency and rely on base version
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=8e136401b5b90f15faf969f66123435327979fcd commit 8e136401b5b90f15faf969f66123435327979fcd Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2024-05-11 09:54:59 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2024-05-11 10:17:14 +0000 dns/dnsjit: Update to 1.3.0 Remove dependency of net/libpcap dependency and rely on base version Based on patch by Leo Vandewoestijne (maintainer) PR: 272812 Approved by: portmgr (maintainer timeout, 2+ weeks) dns/dnsjit/Makefile | 15 ++++++--------- dns/dnsjit/distinfo | 8 +++----- dns/dnsjit/pkg-plist | 2 +- 3 files changed, 10 insertions(+), 15 deletions(-)