There are currently 10 ports that have specified a library dependency on net/libpcap ambiguously. This specification is satisfied by the base libpcap library, so the specification has no effect. I can't tell what the port maintainer intends with regard to libpcap. If the maintainer intends to use the base libpcap, the specification should be removed (all platforms have libpcap so specification is never satisfied). If the maintainer intends that the ports libpcap be used, it needs to be specified as "LIB_DEPENDS= libpcap.so.1:net/libpcap", not "LIB_DEPENDS= libpcap.so:net/libpcap" Can everyone here indicate their intent? Or even commit the fix to their port and reference this PR number? Thanks! John net/daq (zi) (LIB_DEPENDS, intent unclear) net/hexinject (sbz) (LIB_DEPENDS, intent unclear) net/libtrace (matt@peterson.org) (LIB_DEPENDS, intent unclear) net/tcpdump (garga) (LIB_DEPENDS, intent unclear) net/xorp (hrs) (LIB_DEPENDS, intent unclear) net-mgmt/netams (jura@netams.com) (LIB_DEPENDS, intent unclear) net-mgmt/yaf (dikshie@sfc.wide.ad.jp) (LIB_DEPENDS, intent unclear) security/barnyard2 (bofh) (non-default option, mis-specified) security/py-crits (dvl) (LIB_DEPENDS, intent unclear) security/suricata (koobs) (non-default option, mis-specified)
A commit references this bug: Author: marino Date: Thu Aug 4 14:18:33 UTC 2016 New revision: 419614 URL: https://svnweb.freebsd.org/changeset/ports/419614 Log: net-mgmt/netams: reset maintainer, expire, make less broken First, the port already has 3 maintainer timeouts going back years, so go ahead and reset maintainership. Second, it's broken on FreeBSD 10 and newer. Third, the options were broken (e.g. USES defined after <options>, <pre> and <post> also used with options. I tweaked this some (untested) Fourth: The pcap specification is ambiguous. (I removed it). [1] The entire port is in really bad shape so set it for removal in two weeks. PR: 211578 [1] Changes: head/net-mgmt/netams/Makefile
pi@, you might be able to answer net-mgmt/yaf, it was your commit that added the pcap requirement back in March: https://svnweb.freebsd.org/ports/head/net-mgmt/yaf/Makefile?r1=410459&r2=410460 (upgrading 2.8.0 => 2.8.1)
A commit references this bug: Author: bofh Date: Thu Aug 4 16:25:53 UTC 2016 New revision: 419628 URL: https://svnweb.freebsd.org/changeset/ports/419628 Log: security/barnyard2: Fix ambiguous specification of libpcap PR: 211578 Submitted by: marino Changes: head/security/barnyard2/Makefile
Thanks Muhammad, I'm going to remove people from the CC list as their related ports get fixed to avoid spamming everyone unnecessarily.
A commit references this bug: Author: marino Date: Thu Aug 4 16:52:00 UTC 2016 New revision: 419630 URL: https://svnweb.freebsd.org/changeset/ports/419630 Log: net/libtrace: Fix LIB_DEPENDS on pcap (ports version desired) The configure argument makes it clear the ports version of libpcap is desired, but due to the ambiguous specification, the dependency was never registered, but this commit rectifies that issue. PR: 211578 approved by: just-fix-it Changes: head/net/libtrace/Makefile
These dependencies exist to enable Endace DAG functionality in our various ports. Since DAG support is off by default in libpcap (and requires external libraries), removing the port version of libpcap from the DEPENDS list on all of these ports will break this for Endace users. Please revert and leave it as it was.
I'm guessing that cdpsnarf users would probably not need to use it on their Endace cards, however, up to you.
A commit references this bug: Author: sbz Date: Thu Aug 4 18:14:31 UTC 2016 New revision: 419643 URL: https://svnweb.freebsd.org/changeset/ports/419643 Log: - Fix ambiguous specification of libpcap by using libpcap from base - Regenerate patch using make makepatch - Make happy portlint PR: 211578 Submitted by: marino Changes: head/net/hexinject/Makefile head/net/hexinject/distinfo head/net/hexinject/files/patch-prettypacket.h
(In reply to Ryan Steinmetz from comment #6) Ryan, I think you have misunderstood this PR. Take daq as an example. You just said daq is supposed to pull in ports libpcap. That's fine, but that's not what is happening. Thus, daq port has a bug in it. You want libpcap, but you aren't getting it because LIB_DEPENDS is badly specified and it's pulling in base libpcap instead (the opposite of what you want). What exactly is it that you think needs reverting? nothing has been committed yet. This a per-port decision which is why the PR was opened. THe only commits have happened on ports where a decision has been made. Is that clear now?
(In reply to Ryan Steinmetz from comment #7) Kurt already fixed cdpsnarf by choosing to continue to build it was base libpcap as it has been building since the beginning of the port. I didn't touch it.
i guess you said DAG not "daq" but my general point stands. Each maintainer has to decide explicitly decide if the want ports pcap or not.
A commit references this bug: Author: garga Date: Thu Aug 4 18:49:48 UTC 2016 New revision: 419648 URL: https://svnweb.freebsd.org/changeset/ports/419648 Log: - Update net/tcpdump to 4.8.0 - Fix ambiguous specification of libpcap by using libpcap from base [1] PR: 211578 [1] Sponsored by: Rubicon Communications (Netgate) Changes: head/net/tcpdump/Makefile head/net/tcpdump/distinfo
garga, this is related to your libpcap upgrade commit. Apparently it broke in the case of IPv6 option is off. I'm being told the following patch for DF should be applicable to FreeBSD as well: https://github.com/DragonFlyBSD/DeltaPorts/pull/602
4 of the five remaining belong to ports committers: net/daq (zi) net/xorp (hrs) net-mgmt/yaf (dikshie@sfc.wide.ad.jp) (libpcap introduced by pi) security/py-crits (dvl) security/suricata (koobs) All you have to do is say either "the port should be using base libpcap" or "the port should be using libpcap from ports". I will do the actual commit if you want, but I need direction. To recap: None of those ports use libpcap from ports, but it's likely that it was intended that some or all of them do.
regarding py-crits, somebody gave me a patch for the RUN_DEPENDS, says it appears to be a typo. I have no idea, it's for koobs to evaluate: @@ -56,7 +56,7 @@ RUN_DEPENDS+= 7z:archivers/p7zip \ ${PYTHON_PKGNAMEPREFIX}kombu>=2.5.4:net/py-kombu \ ${PYTHON_PKGNAMEPREFIX}celery>=3.0.12:devel/py-celery \ ${PYTHON_PKGNAMEPREFIX}requests1>=1.1.0_9:www/py-requests1 \ - ${PKGNAMEPREFIX}pillow>=2.4.0:graphics/py-pillow \ + ${PYTHON_PKGNAMEPREFIX}pillow>=2.4.0:graphics/py-pillow \ ${PYTHON_PKGNAMEPREFIX}pyparsing>=1.5.1:devel/py-pyparsing \ ${PYTHON_PKGNAMEPREFIX}ldap>=2.4.15:net/py-ldap \ ${PYTHON_PKGNAMEPREFIX}magic>0:devel/py-magic \
(In reply to John Marino from comment #15) Indeed a bug, should be PYTHON_PKGNAMEPREFIX, couldn't have passed testing
(In reply to Kubilay Kocak from comment #16) It passed testing last night when I was working on this PR. http://services.unixathome.org/poudriere/data/102amd64-testing/2016-08-05_18h19m36s/logs/py27-crits-3.1.0_3.log It passed again today with the patch. http://services.unixathome.org/poudriere/data/102amd64-testing/2016-08-05_18h19m36s/logs/py27-crits-3.1.0_3.log
A commit references this bug: Author: dvl Date: Fri Aug 5 18:28:18 UTC 2016 New revision: 419698 URL: https://svnweb.freebsd.org/changeset/ports/419698 Log: - Fix ambiguous specification of libpcap by using libpcap from base - use PYTHON_PKGNAMEPREFIX instead of PKGNAMEPREFIX for pillow depends - Bump PORTREVISION PR: 211578 Changes: head/security/py-crits/Makefile
Hey Dan, thanks. I'm curious though, you wrote the same thing as garga, "Fix ambiguous specification of libpcap by using libpcap from base", but the code actually specifies libpcap from ports. That's fine, it's just confusing because we can't tell if the commit message is inaccurate (you wanted from ports) or if the commit is wrong (you wanted it from base as the message states). From my point of view, I don't care because the problem is solved in any case. I just want to be sure it's fixed as you wanted it to be fixed.
(In reply to John Marino from comment #19) Yes, my commit message was inaccurate. I want to use libpcap from ports.
(In reply to John Marino from comment #13) Fixed. Thanks!
A commit references this bug: Author: marino Date: Sat Aug 6 00:09:48 UTC 2016 New revision: 419718 URL: https://svnweb.freebsd.org/changeset/ports/419718 Log: net-mgmt/yaf: Fix dependency on libpcap The WITH_DAG knob implies that the ports version of libpcap is desired for yaf, not the base version as it is currently configured. Fix the dependency specification accordingly. PR: 211578 Changes: head/net-mgmt/yaf/Makefile
A commit references this bug: Author: marino Date: Sat Aug 6 00:41:20 UTC 2016 New revision: 419721 URL: https://svnweb.freebsd.org/changeset/ports/419721 Log: net/xorp: Fix dependency on libpcap (use ports version) The specification on libpcap came on the v1.6 => v.1.8.5 transition while the port was unmaintained. Assume the change originator intended for the ports libpcap to be used, but didn't realize it needed an explicit version number to avoid the base library from satisfying the requirement. While here, remove an obsolete CONFLICTS definition. PR: 211578 Changes: head/net/xorp/Makefile
A commit references this bug: Author: marino Date: Sat Aug 6 01:02:28 UTC 2016 New revision: 419724 URL: https://svnweb.freebsd.org/changeset/ports/419724 Log: net/daq: Fix dependency on libpcap (use ports version) Back in r342092 (Jan 2014), the LIB_DEPENDS specification was updated from pcap to libpcap.so, which effectively moved the dependency from the ports version of libpcap to the base version. The maintainer also indicated the ports listed in the PR should specify the net/libpcap. PR: 211578 Changes: head/net/daq/Makefile
okay koobs, security/suricata is the only one port left from the original list. The fix is trivial. I just checked the makefile and it's obvious that PORTS_PCAL_LIB_DEPENDS needs to be changed to "libpcap.so.1:net/libpcap" based on the configuration arguments. Can you go ahead and commit that so that I can close this PR? Thanks.
A commit references this bug: Author: marino Date: Sat Aug 6 03:48:52 UTC 2016 New revision: 419730 URL: https://svnweb.freebsd.org/changeset/ports/419730 Log: security/py-crits: Really fix pillow depends The previous commit message indicated PYTHON_PKGNAMEPREFIX was added to the pillow dependency specification, but the commit didn't actually contain that change, so add it now. PR: 211578 Changes: head/security/py-crits/Makefile
A commit references this bug: Author: koobs Date: Sat Aug 6 08:51:43 UTC 2016 New revision: 419735 URL: https://svnweb.freebsd.org/changeset/ports/419735 Log: security/suricata: Fix libpcap LIB_DEPENDS Fix the PORTS_PCAP option LIB_DEPENDS entry ambiguously depending on net/libpcap, which should be libpcap.so.1 so as not to be satisfied with the pcap library provided by base. [1] While I'm here: - Explicitly BUILD_DEPEND on libhtp >= 0.5.20, as configure breaks when that minimum version is not available. PR: 211578 Reported by: marino [1] Changes: head/security/suricata/Makefile
Thanks Koobs!
(In reply to John Marino from comment #28) My pleasure John I also had a thought. Might a USES=pcap[:ports] or something similar that provides all the correct (library/include paths, libname etc) variables for ports to use be a handy thing to have?
A DF guy made the same suggestion, but I don't know if it's worth the effort. Grepping would come up with the true number, but there might be 20 ports that use libpcap at most. There are an untold (and undetectable) number of ports that use the base libpcap. Given the second fact, I'd just say people need to be careful with libpcap (sysutils/file was the same issue). If you are asking my opinion, I'd say consider the issue closed. The effort raised awareness on the issue. FYI, Synth detected this issue. It could be set up on FreeBSD to periodic do it (build the entire tree, then incrementally build it again. If any ports fail sanity checks and rebuild, they probably have this issue or bad options definition). Poudriere can't detect it.
let me add a caveat. If DF makes libpcap a private library, we would need to introduce USES=pcap:[port]. That could actually happen. DF would be in a good position to catch the fallout as well.