| Summary: | net-analyzer/ngrep-1.45-r1 fails to build with net-libs/libpcap-1.0.0-r1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthias Liebig <pqGungnir> |
| Component: | Current packages | Assignee: | Gentoo Netmon project <netmon> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | Adrian.Bassett, jpr5+gentoo, polynomial-c |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
Matthias Liebig
2008-11-17 00:32:31 UTC
Created attachment 172036 [details]
build.log
There is a --with-pcap-includes option. I get this package compiled with libpcap-1.0.0-r1 when I either put --with-pcap-includes=/usr/include or --with-pcap-includes=/usr/include/pcap into ngrep's ebuild but I am not sure what is the right directory to choose. Assigning this bug to netmon. I don't CC package's author as this doesn't seem to be a bug in his software but rather some problem with the ebuild. Well I've fixed this using workaround you suggested (1.45-r2 with some other changes added to the tree). But I consider this to be upstream bug since it's upstream changed location of pcap.h header and we just followed them and as they suggested we have two headers (read comments in /usr/include/pcap.h). (In reply to comment #2) > Assigning this bug to netmon. I don't CC package's author as this doesn't seem > to be a bug in his software but rather some problem with the ebuild. BTW if upstream is more or active I'd like to clean a bit our patches and forward all of them upstream... Please, CC author if he/she is around. Fixed in ngrep-1.45-r2. > (In reply to comment #2)
> > Assigning this bug to netmon. I don't CC package's author as this doesn't seem
> > to be a bug in his software but rather some problem with the ebuild.
>
> BTW if upstream is more or active I'd like to clean a bit our patches and
> forward all of them upstream... Please, CC author if he/she is around.
Upstream is listed in metadata.xml. Do you really think it's useful to CC him in an already fixed bug?
Jordan, since you are interested in ngrep bugs take a look at this one. IMHO searching for pcap.h in predefined locations is ok, but it should not fail if it finds headers both in /usr/include and /usr/include/pcap, since that's how pcap upstream now installs pcap. Possible fix for ngrep will be just take first pcap.h occurrence instead of failure... Lars, thank you for pointing me. Yes, I think upstream should be aware about bugs we fixed and how we did that. (In reply to comment #5) > Lars, thank you for pointing me. Yes, I think upstream should be aware about > bugs we fixed and how we did that. I completely agree with you on this. I asked because I was still under the impression that this problem is rather one in our ebuild than in upstream's build system. Hey guys, thanks for CCing me. FWIW, IIRC the ngrep multiple-pcap-header check dates back to old RedHat days (maybe 5.x) when RH had changed the default install location for the headers, which was important back then because older (stock) versions of libpcap had a borked *_restart() (pcap filter logic parser reset) that would segfault when called. I'll take a look at the new libpcap now to familiarize myself with the change, and write back soon. I've been sitting on a colorization feature (in CVS version) for too long now; would you rather I address this as an A.B.C, or 1.46 (which will wrap the new changes)? (In reply to comment #7) > > I've been sitting on a colorization feature (in CVS version) for too long now; > would you rather I address this as an A.B.C, or 1.46 (which will wrap the new > changes)? From my user's point of view I'd say go with 1.46 as colorization is a new feature. A.B.C could be useful to indicate bugfix-only releases... Thank you for clarification Jordan. It was really helpful because it puzzled me why some programs use such strange logic and die in case they found two pcap.h files. And yes, I agree that it's better to keep current versioning scheme (so 1.46) since there are new features :) |
