Created attachment 666713 [details] failing build log [ebuild U ] net-print/hplip-3.20.9::gentoo [3.20.6-r3::gentoo] USE="X fax hpcups qt5 scanner -doc -hpijs -kde -libnotify -libressl -libusb0 -minimal -parport -policykit -snmp -static-ppds" PYTHON_SINGLE_TARGET="python3_8 -python3_6 -python3_7 (-python3_9%)" 0 KiB ... fails to build with this error: scan/sane/hpaio.c:39:10: fatal error: avahiDiscovery.h: No such file or directory 39 | #include "avahiDiscovery.h" | ^~~~~~~~~~~~~~~~~~ Diffing the 3.20.6 and 3.20.9 sources, hpaio.c line 39: #include "avahiDiscovery.h" ... is new to 3.20.9. Obviously there's something wrong with it. avahi itself doesn't have such a file, but the hplip sources have protocol/discovery/avhiDiscovery.h, with the file also new to 3.20.9. Should the #include line include the relative path to the header? Build log attached.
Created attachment 666719 [details, diff] avahiDiscovery.h path patch This patch, making it protocol/discovery/avahiDiscovery.h, seems to work. Note that there's a similar "unpathed" avahiDiscovery.h include in io/hpmud. I didn't need it patched for my build but people with other USE flags may. Assuming my search-foo is working all other occurrences of avahiDiscovery.h (mostly makefile) appear to include the path already.
Also, that USE=scanner RDEPEND on avahi now needs to be a DEPEND (as it already is for USE=snmp). After successfully building hplip-3.20.9 with the above patch and avahi merged I tested building without avahi merged (since it's an RDEPEND) and get this: In file included from scan/sane/hpaio.c:39: ./protocol/discovery/avahiDiscovery.h:18:10: fatal error: avahi-client/client.h: No such file or directory 18 | #include <avahi-client/client.h> That's an avahi file, so the new avahiDiscovery.h in hplip now has a DEPEND on avahi for USE=scanner, not just an RDEPEND.
Thank you for the report! You are right regarding the dependency. Avahi is of course a build dependency. This was an oversight and will be fixed. I can't however reproduce the error regarding avahiDiscovery.h. Can you please test if your patch is still required if avahi is present at build time?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab44732c304c7e8a237e3bbe4eadae6c5be8c018 commit ab44732c304c7e8a237e3bbe4eadae6c5be8c018 Author: Daniel Pielmeier <billie@gentoo.org> AuthorDate: 2020-10-19 19:41:21 +0000 Commit: Daniel Pielmeier <billie@gentoo.org> CommitDate: 2020-10-19 19:41:55 +0000 net-print/hplip: Revision bump to hplip-3.20.9-r1. Make net-dns/avahi a build dependency. Bug: https://bugs.gentoo.org/750116 Package-Manager: Portage-3.0.8, Repoman-3.0.2 Signed-off-by: Daniel Pielmeier <billie@gentoo.org> net-print/hplip/hplip-3.20.9-r1.ebuild | 282 +++++++++++++++++++++++++++++++++ 1 file changed, 282 insertions(+)
(In reply to Daniel Pielmeier from comment #3) > Thank you for the report! > > I can't however reproduce the error regarding avahiDiscovery.h. > > Can you please test if your patch is still required if avahi is present at > build time? Sorry, I think comment #2, while correct (and thanks for that fix), confused things a bit. Here's the actual sequence I tried along with results as appropriate (more detailed than normal since I'm trying to clear up the confusion I triggered): 1) Try merging hplip with a /fake/ avahi-999 (-999 is my standard "fake ebuild" number, just like -9999 is the standard live-build number.) USE flags as posted above, never changed them at all. Failed with the avahiDiscovery.h error. 2) Start filling in a bug but decide I better try with a real avahi merged first so I don't actually submit the bug. 3) Manually merge the real avahi-0.8-r2 (and its deps) from the gentoo tree. avahi merged fine. 4) Try merging hplip with the /real/ avahi from step 3 (USE flags still as posted). ** Still failed with the avahiDiscovery.h error, even with the real avahi-0.8-r2 merged earlier. 5) Begin troubleshooting. 5a) Did an equery belongs avahiDiscovery.h, expecting to find it in avahi. Couldn't find it avahiDiscovery.h in avahi. 5b) Google (DDG) for it, thinking it might have been in an old avahi version or something. Didn't find much/anything useful. 5c) Well, is it in the hplip sources? Yes, but it's in a subdir and the #include line doesn't have a path, maybe... 5d) I wonder if it's new to hplip-3.20.9? Yes, or at least it's not in 3.20.6, the older in-tree version available (3.20.7 and 3.20.8 were apparently skipped). By this time I've searched the sources (multiple times) for avahiDiscovery.h both as a filename as as text content, and I see it's with a path in the makefiles but not in the include, and the the file is as I said in the subdir. ** 6) Erase the text I'd started in the bug and file the bug with the error and the new info, real avahi-0.8-r2 still merged, hplip-3.20.9 still broken. 7) Let's try a patch adding the path and see if that works. (Real avahi still merged.) Sure does! Adding the patch worked. Without it didn't. 8) Add the patch to the bug. Only then... 9) Hmm, now that I have it build/merged against the real avahi-0.8-r2 and the patch applied, and the bug is filed, what about that DEPEND/RDEPEND thing I thought was the original problem? 10) Emerge my fake/empty avahi-999 package again and try the hplip merge against it. hplip fails with the error in comment #2. 11) Add comment #2 saying avahi needs to be a DEPEND not just an RDEPEND. 12) Delete my fake avahi-999 as I've satisfied myself the real avahi is needed at build time, and remerge the real avahi-0.8-r2 again. 13) Remerge hplip-3.20.9 over top of itself, just to be sure I didn't screw anything up with my testing. --- So as you can see, I had the real avahi merged and still needed the patch. But let me move the patch and try again without it just to be sure... Yes, still getting the same error without the patch, and the fake avahi-999 ebuild in my overlay was deleted in step 12, with the real avahi-0.8-r2 merged. And equery says avahi-0.8-r2 is what's merged as well. And remerged with the patch, to verify that again as well. Just to be sure, here's my USE flags again. USE="X fax hpcups qt5 scanner -doc -hpijs -kde -libnotify -libressl -libusb0 -minimal -parport -policykit -snmp -static-ppds" PYTHON_SINGLE_TARGET="python3_8 -python3_6 -python3_7" USE=scanner is almost certainly necessary since the problem's in the scanner subdir. And USE=snmp would possibly interfer with its avahi dep so better verify with scanner on and snmp off, matching my flags above. What python you have? As you can see I have python 3.8 setup (and python 2.7 only, unfortunately still necessary to build chromium, firefox and qtwebengine probably due to its chromium basis, not in any flags, and no other python3s on the system, only 3.8). Could it be gold-linker related? I have it set default.
Just tried toggling to USE=snmp, so USE="snmp scanner", /without/ the patch, and... It WORKS! So USE=snmp does something that makes USE=scanner work, making it work with BOTH flags on (without the patch), but NOT with USE="scanner -snmp", which then requires the patch. Trying USE="snmp scanner" /with/ the patch now... That works too. ... And USE="snmp -scanner" (ccache is getting a workout today! =:^)... ... works with and without the patch. So the patch isn't needed but doesn't break USE=snmp with or without USE=scanner as well, but is needed for USE="-snmp scanner". The /proper/ fix should then be to make scanner without snmp do whatever snmp is doing regarding the avahiDiscovery.h file. Maybe it's handling it via makefile? But I don't know makefile "magic" while I can obviously hack-patch an include with a path, so that's what I did. It's probably not the proper (aka upstreamable) fix, but I believe the patch establishes pretty well that the problem is a missing path, anyway, whatever the /proper/ fix for that is. (Now to clean up the test, going back to USE="scanner -snmp" and unmerging the snmp I built and merged for that test...)
I found the issue which has already been reported upstream! hplip-3.20.9-r2 will include a patch fixing the build with USE="scanner -snmp"
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4486e02414931a7b5a38cdd01e52edd3732ef57 commit d4486e02414931a7b5a38cdd01e52edd3732ef57 Author: Daniel Pielmeier <billie@gentoo.org> AuthorDate: 2020-10-20 12:56:40 +0000 Commit: Daniel Pielmeier <billie@gentoo.org> CommitDate: 2020-10-20 12:57:17 +0000 net-print/hplip: Revison bump to hplip-3.20.9-r2. Fix build with USE="scanner -snmp". Thanks to Duncan for the report. Closes: https://bugs.gentoo.org/750116 Package-Manager: Portage-3.0.8, Repoman-3.0.2 Signed-off-by: Daniel Pielmeier <billie@gentoo.org> net-print/hplip/Manifest | 1 + net-print/hplip/hplip-3.20.9-r2.ebuild | 282 +++++++++++++++++++++++++++++++++ 2 files changed, 283 insertions(+)
