sys-apps/lshw is missing build dependencies. The gtk useflag misses dev-util/pkgconfig, x11-proto/glproto and x11-proto/dri2proto. The sqlite useflag misses dev-util/pkgconfig. Reproducible: Always Steps to Reproduce: 1. Cleanup your system, for example using emerge --depclean --with-bdeps n 2. USE=gtk emerge sys-apps/lshw # I'm using 02.15b here (the latest right now) 3. - or - USE=static emerge sys-apps/lshw Actual Results: Build failure missing the described dependencies. Expected Results: No build failure :-) Patch is going to be attached.
Created attachment 264303 [details, diff] Patch against lshw-02.15b.ebuild
i see no indication that either of those proto packages are needed. the pc and header files they install do not seem to be used by lshw. ive added the pkgconfig dep only: http://sources.gentoo.org/sys-apps/lshw/lshw-02.15b.ebuild?r1=1.3&r2=1.4
Hmm, it dies here in the src/gui Makefile when calling pkg-config gtk+-2.0 --cflags when calling directly on the shell it looks like: gui # pkg-config gtk+-2.0 --cflags Package dri2proto was not found in the pkg-config search path. Perhaps you should add the directory containing `dri2proto.pc' to the PKG_CONFIG_PATH environment variable Package 'dri2proto', required by 'egl', not found (after installing dri2proto it misses glproto, after installing that it works) x11-libs/gtk+-2.22.1-r1[cups jpeg tiff xinerama] is installed. Do you need any more information?
you're stepping into a gray area. those are *gtk* dependencies, not lshw. we do not list dependencies of dependencies in packages.
*scratchinghead* so this is not fixed, but a WONTFIX. Grey area or not - it does not build without those deps.
uh, no. by your logic, every single package in the tree that depends on gtk+ must also depend on every proto package that gtk+ depends on. you can obviously see how that makes absolutely no sense. what you're actually complaining about is the lack of BDEPEND. there are other bugs which track this issue. for now, stop unmerging random proto packages from your system.
Yes, that actually makes sense, because it doesn't build otherwise. Calling a package with unresolved deps "fixed" is... well... strange, but not my decision. I've tried my best to be honest ;-) About BDEPEND - I thought DEPEND specifies build dependencies (and RDEPEND runtime deps). What would be the difference between DEPEND and BDEPEND? Can you point me to some document about that? (about unmerging "random" packages - depclean does this for me. Maybe the --with-bdeps option should be removed then)
(In reply to comment #7) > Yes, that actually makes sense, because it doesn't build otherwise. Calling a > package with unresolved deps "fixed" is... well... strange, but not my > decision. I've tried my best to be honest ;-) > > About BDEPEND - I thought DEPEND specifies build dependencies (and RDEPEND > runtime deps). What would be the difference between DEPEND and BDEPEND? Can you > point me to some document about that? > > (about unmerging "random" packages - depclean does this for me. Maybe the > --with-bdeps option should be removed then) > Rant in bug 342393 instead, not here.
(In reply to comment #8) > Rant in bug 342393 instead, not here. When I'm going to rant, I'll do that where it belongs. But thanks for the insight. Someone care to answer my question though?