When emerging wireshark, the ebuild seems to totally ignore USE flags. Seemingly, all versions of wireshark exhibit this. And, although I have stated the USE flags manually and within /etc/portage/package.use, emerge -pv wireshark will state that it's going to build with those specified USE flags up until a "emerge wireshark" is issued. Then the fateful "USE=-gtk will means no gui..." message during build. I am using =sys-apps/portage-2.2_rc67, however, I don't think I've ever seen this strangeness with any other package. And, I might have seen similar with wireshark during past attempts at emerging it on other systems -- but the ebuild file for it looks OK. Reproducible: Always Actual Results: # USE="gtk" emerge wireshark -pv Calculating dependencies... done! [ebuild R ] net-analyzer/wireshark-1.2.9 USE="caps* gtk* ipv6* pcap* pcre* zlib* -adns -ares -gcrypt -geoip -gnutls -kerberos -lua -portaudio -profile (-selinux) -smi -threads" 0 kB # USE="gtk" emerge wireshark Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-analyzer/wireshark-1.2.9 * wireshark-1.2.9.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: net-analyzer/wireshark-1.2.9 * REPO: gentoo * USE: -profile * USE=-gtk will means no gui called wireshark will be created and * only command line utils are available >>> Unpacking source... ... skips gtk pcap pcre zlib USE flags as well as some others. No problems with going into the /var/tmp/portage folder and manually configuring. What gives??
Please provide emerge --info and attach /etc/portage/package.use.
Created attachment 236299 [details] emerge --info > info.log emerge --info > info.log
Created attachment 236301 [details] package.use package.use
...nothing really unusual within those files. System is pretty much stripped to use only the needed USE flags, with any additional USE flags placed within /etc/portage/package.use. This sounds more like an issue with either the ebuild... or likely with this portage version. ... really, out of the 5+ years of I've never seen an ebuild behave like this else I missed something ... as usual. ;-)
I'm using stable portage and it works fine. This time post the debugging output from emerging wireshark with '--debug' flag, and then we'll let the portage team tackle this weirdness.
Created attachment 236473 [details] Emerge with --debug Emerge with --debug
... stopped the emerge just after configure and before compiling, but am guessing any hints of the bug will be near the top for this bug.
Is there anything in /etc/portage/bashrc or /etc/portage/env?
I replaced the USE within /etc/portage/env/net-analyzer/wireshark with: USE="-profile caps gtk ipv6 pcap pcre zlib". Below is what I had in there before the modification to this file, then modified the file as noted above and then built/emerged wireshark. I conclude for some reason /etc/portage/env variables are taking priority over shell specified variables... ie: USE="gtk" emerge wireshark... portage drops the "gtk" if it's not present within /etc/portage/env?? From my experience, shell induced variables should take priority over environmental variables. roger ~ $ cat /etc/portage/bashrc cat: /etc/portage/bashrc: No such file or directory roger ~ $ find /etc/portage/env /etc/portage/env /etc/portage/env/dev-libs /etc/portage/env/dev-libs/libgcrypt /etc/portage/env/sys-libs /etc/portage/env/sys-libs/zlib /etc/portage/env/sys-libs/libsmbios /etc/portage/env/sys-boot /etc/portage/env/sys-boot/grub /etc/portage/env/media-libs /etc/portage/env/media-libs/jpeg /etc/portage/env/app-text /etc/portage/env/app-text/libpaper /etc/portage/env/sys-apps /etc/portage/env/sys-apps/busybox /etc/portage/env/net-analyzer /etc/portage/env/net-analyzer/wireshark /etc/portage/env/x11-libs /etc/portage/env/x11-libs/pixman /etc/portage/env/www-client /etc/portage/env/www-client/mozilla-firefox /etc/portage/env/xfce-base /etc/portage/env/xfce-base/xfconf /etc/portage/env/net-libs /etc/portage/env/net-libs/xulrunner roger ~ $ cat /etc/portage/env/net-analyzer/wireshark CFLAGS="-march=pentium3 -O2 -pipe -m32" #CFLAGS="-g -Wall -ggdb" CXXFLAGS="${CFLAGS}" #unset LDFLAGS USE="-profile" #FEATURES="nostrip noclean keeptemp keepwork" ADDED USE="-profile caps gtk ipv6 pcap pcre zlib" to /etc/portage/env/net-analyzer/wireshark file.... roger# emerge net-analyzer/wireshark Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-analyzer/wireshark-1.2.9 * wireshark-1.2.9.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: net-analyzer/wireshark-1.2.9 * REPO: gentoo * USE: -profile caps gtk ipv6 pcap pcre zlib >>> Unpacking source... ... snip ... The Wireshark package has been configured with the following options. Build wireshark : yes Build tshark : yes Build capinfos : yes Build editcap : yes Build dumpcap : yes Build mergecap : yes Build text2pcap : yes Build idl2wrs : yes Build randpkt : yes Build dftest : yes Build rawshark : yes Install dumpcap setuid : yes Use plugins : yes Use lua library : no Build rtp_player : no Use threads : no Build profile binaries : no Use pcap library : yes Use zlib library : yes Use pcre library : yes Use kerberos library : no Use c-ares library : no Use GNU ADNS library : no Use SMI MIB library : no Use GNU crypto library : no Use SSL crypto library : no Use IPv6 name resolution : yes Use gnutls library : no Use POSIX capabilities library : yes Use GeoIP library : no >>> Source configured. ... at this point, it would appear variables are holding. I have also rebooted the system several times since, and only rsynced /usr/portage but did not upgrade any packages yet. Verified the recent install of wireshark does have the gtk and other USE flags I want enabled as I specified. I then went back reverted the /etc/portage/env file to USE="-profile" and then tried emerging with the USE via command line: # USE="gtk" emerge wireshark and got the same following message: # USE="gtk" emerge wireshark Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-analyzer/wireshark-1.2.9 * wireshark-1.2.9.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: net-analyzer/wireshark-1.2.9 * REPO: gentoo * USE: -profile * USE=-gtk will means no gui called wireshark will be created and * only command line utils are available
I just realized, the whole reason I created the /etc/portage/env file for wireshark was because I couldn't emerge with my USE flags via command line (for testing to see what packages a package pulls in with specific USE flags ... if the package pulled in too many packages I didn't need, I would just disable the USE flag in /etc/portage/package.use). For some reason, things seem to be working just fine now, but like I said, I did do a sync /usr/portage today aside from a few reboots in the past week. Maybe something fixed itself. I'll mark this as closed for now for you. ;-)
We really should make USE a readonly variable, but there's some code in the eubild.sh dyn_test function that needs to be fixed first.
But would this clear up the order of precedence. Making it read-only would probably make things worse for those modifying the environmental USE variable. From what I read from the "Managing Projects with Make" O'Reilly book (open book available for download too.. in it's 3rd edition...) Makes order of precedence is the usual logical (going from memory as I read the whole booklet over the past week): 1) Terminal defined variables via command line (as I was doing USE="blah" emerge fooey) 2) Environmental variables (ie. make.conf, bashrc, and even /etc/portage/package.use ...) 3) Internal variables. (ie. /usr/portage) From what I'm seeing, /etc/portage/env is taking precedence over terminal defined... and maybe even over /etc/portage/package/use!) This is probably something to just gnaw on for now whomever is writing the portage python code. Since I know this now, I can probably avoid it myself. ... so, just making some noise that maybe something isn't right here. ;-) Test defining environmental variables via the command line while installing a package is easier then having to open /etc/portage/* files with a text editor, or even using cat/echo/sed to add/remove entries.
In the context of portage, it makes no sense to modify USE from bashrc. Therefore, it should be marked readonly.
Who mentioned anything about putting USE stuff within bashrc?
The /etc/portage/env files are bashrc files, and you said that's where you modified USE.
Ah. I think I see where you're going with this now. Individual package USE descriptions should be put in /etc/portage/package.use. ... I just took a step back from this bug, and then ... just realized the whole scenario. Sounds as if there's a huge loop (or a hack ontop of a hack ontop of a hack) going on here with defining ebuild variables. One reason I think /etc/portage/package/env is used is a place to define CFLAGS when package breaks on compile with CFLAGS. Instead of a /etc/portage/package.cflags, just push everything into /etc/portage/env instead of having a file for every variable. But in essence, it's easier to get to, and modify /etc/portage/package.cflags file instead of creating a separate folders and files for every ebuild needing the variable modifications. It's great to have options, but too many options can confuse things. What's missing is "Which file should take precedence, /etc/portage/env or /etc/portage/package.* files?" ... If I'm not mistaken, currently /etc/portage/env does, and I'm fine with this as long as I can remember it. ;-)
(In reply to comment #16) > Sounds as if there's a huge loop (or a hack ontop of a hack ontop of a hack) > going on here with defining ebuild variables. One reason I think > /etc/portage/package/env is used is a place to define CFLAGS when package > breaks on compile with CFLAGS. Instead of a /etc/portage/package.cflags, just > push everything into /etc/portage/env instead of having a file for every > variable. The existing /etc/portage/env approach works for almost everything. However, there is a patch on bug 44796 which makes it possible to do per-package environment settings on the python side. That's useful since it allows those settings to be displayed by emerge --info, and also allows per-package FEATURES settings on the python side (some FEATURES are implemented entirely in python, so /etc/portage/env can't enable/disable them).
There's a patch in the following branch: https://github.com/zmedico/portage/tree/bug_325009 I've posted it for review here: https://archives.gentoo.org/gentoo-portage-dev/message/433c81924690a77984c21b603e0f6b6c
This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=bc53f538039006f49bdcd19d3f17ab7f6b7a48d9
I vaguely remember filing this bug and rarely use WireShark, in the past and present. I know I filed this bug as it was something that obviously needed fixing. Shrugs. Just hope the patch doesn't break performing something like the following: # USE="doc" emerge -pv net-analyzer/wireshark ... as it is quite common to perform such trivial tasks during testing within the shell, compared to editing a system file within your text editor which requires much more time. (And then you have to undo the changes within the system files.)
(In reply to Roger from comment #20) > Shrugs. Just hope the patch doesn't break performing something like the > following: > > # USE="doc" emerge -pv net-analyzer/wireshark The patch doesn't affect that. There's no valid reason to modify USE inside the ebuild environment, because the USE setting affects dependencies which need to be satisfied before the ebuild environment is created.
Released in portage-2.2.19