Portage 2.1.1_rc1-r4 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.16-gentoo-r6 i686) ================================================================= System uname: 2.6.16-gentoo-r6 i686 Mobile AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.12.4 Last Sync: Wed, 06 Sep 2006 01:54:01 +0000 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-mp -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=athlon-mp -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.inode.at/ ftp://gentoo.inode.at/source/ ftp://213.186.33.38/gentoo-distfiles/ ftp://213.186.33.37/gentoo-distfiles/" LC_ALL="en_US.UTF-8" LINGUAS="" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/webapps-experimental /usr/portage/local/layman/java-migration-packages /usr/portage/local/layman/java-gcj-overlay /usr/portage/local/layman/java-experimental /usr/portage/local/layman/initng /usr/portage/local/layman/gnome-experimental" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X accessibility acpi alsa apache2 avi bitmap-fonts cairo cdr cli crypt dbus dlloader dri dvd dvdr eds elibc_glibc emacs emboss encode fam firefox gdbm gif gnome gpm gstreamer gtk gtk2 hal input_devices_keyboard input_devices_mouse input_devices_synaptics ipv6 isdnlog jikes jpeg kernel_linux libg++ mad mikmod minimal mmx mp3 mpeg ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pcre pdflib png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl sse ssl tcpd truetype truetype-fonts type1-fonts udev unicode userland_GNU userlocales video_cards_vesa video_cards_via vorbis win32codecs xml xmms xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
since I have have the minimal USE-flag in /etc/make.conf the useflag list of perl-5.8.8 includes minimal, even so perl-5.8.8 does not declare the minimal USE-flag anymore. find the little patch which fixes that problem. I was not able to very whether the bug from ebuilds comment is still fixed or not - that bug number has nothing to do with wireshark or etherreal.
Created attachment 96264 [details] patch for ebuild
Don't restrict bugs without any reason. Just leave the checkboxes alone, please.
Don't use USE="minimal" if you don't know what you are doing. Definitely don't use it globally. I don't see any need for this patch, perl-5.8.8 is stable everywhere and no longer has USE="minimal".
(In reply to comment #3) > Don't restrict bugs without any reason. Just leave the checkboxes alone, > please. > sorry which checkbox ??
(In reply to comment #4) > Don't use USE="minimal" if you don't know what you are doing. Definitely don't > use it globally. can you please explain your statement, since the describtion of 'minimal' definitely fits my needs and I never had a problem until emerging wireshark: Install a very minimal build (disables, for example, plugins, fonts, most drivers, non-critical features)
*** Bug 146839 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > (In reply to comment #4) > > Don't use USE="minimal" if you don't know what you are doing. Definitely don't > > use it globally. > > can you please explain your statement, since the describtion of 'minimal' > definitely fits my needs and I never had a problem until emerging wireshark: > Install a very minimal build (disables, for example, plugins, fonts, most > drivers, non-critical features) Sure, USE="minimal" meaning wildly differs between packages, setting it globally is a bad idea. Anyway, latest stable has no USE="minimal" -> not a problem any more.
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #4) > > > Don't use USE="minimal" if you don't know what you are doing. Definitely don't > > > use it globally. > > > > can you please explain your statement, since the describtion of 'minimal' > > definitely fits my needs and I never had a problem until emerging wireshark: > > Install a very minimal build (disables, for example, plugins, fonts, most > > drivers, non-critical features) > > Sure, USE="minimal" meaning wildly differs between packages, setting it > globally is a bad idea. > > Anyway, latest stable has no USE="minimal" -> not a problem any more. > no perl is not the problem, it is the if(perl has_build_with minimal) in wireshark. since in the portage cache or db the complete list of use flags whether they mean something for tha package or not get queried. yet that quey makes assuption of how to use make.conf and certain use-flags and that is incorrect here.
There's no minimal use flag for perl any more -> upgrade.
(In reply to comment #10) > There's no minimal use flag for perl any more -> upgrade. > it is already uptodate, yet wireshark does not build
(In reply to comment #11) > it is already uptodate, yet wireshark does not build Uh, well I see what you mean now. Well, this is just wrong, the eclass should check only for existing flags that are in /var/db/pkg/*/*/IUSE and compare them w/ var/db/pkg/*/*/USE, not to return success for flags that don't exist in an ebuild and so the package can't be built with them.
Created attachment 96392 [details, diff] eutils.eclass.diff OK, did a quick testing w/ this one: minimal in IUSE + minimal in USE -> returns success minimal in IUSE + minimal not in USE -> returns failure minimal not in IUSE + minimal in USE -> returns failure I also did a quick testing w/ built_with_use -o variation for two flags and it seems to behave properly as well.
no, the packages doing the checks should be handling this there's no point in asking a package that doesnt support a USE flag if it's been built with that USE flag
(In reply to comment #14) > no, the packages doing the checks should be handling this > > there's no point in asking a package that doesnt support a USE flag if it's > been built with that USE flag Except that it actually breaks when a flag is removed/changed and the result given by eutils.eclass doesn't make any sense. foo.ebuild <snip> if ! built_with_use cat/bar qt ; then die "You need to compile QT bindings in cat/bar for this to work." fi </snip> When cat/bar build changes the flag to qt3, foo ebuild won't find out because user hasn't removed qt from his use flags and will bomb out later on. Another example why this is wrong is shown in this bug, it's dying completely pointlessly. The check is wrong, it simply returns results that don't make sense. If an ebuild is missing a flag, you shouldn't tell other ebuilds that it's been built with that flag just because user has it in make.conf.
(In reply to comment #14) > no, the packages doing the checks should be handling this > > there's no point in asking a package that doesnt support a USE flag if it's > been built with that USE flag > first I thought to patch the ebuild, not to ask if a package does not support a USE flag. but just from the semantic of that method and if I read something like <snip> if built_with_use net-www/apache dvd ; then do something strange fi </snip> I would never ever expect that this method returns TRUE if apache does not support dvd
you have two choices: - i can close this bug again as INVALID - i can add change the logic so that if a package is asked if it supports a flag but in reality it doesnt, built_with_use will call 'die' and tell people to fix their broken package
(In reply to comment #17) > you have two choices: > - i can close this bug again as INVALID > - i can add change the logic so that if a package is asked if it supports a > flag but in reality it doesnt, built_with_use will call 'die' and tell people > to fix their broken package > I personally think, the method should return "sense": TRUE means the package was build with that USE flag, FALSE means the package was not build with that USE flag. with the given choices of yours: it should die, if the paramaters makes no sense, i.e. the per-condition is that the given package declares the given USE flag
(In reply to comment #18) > with the given choices of yours: it should die, if the paramaters makes no > sense +1 from me. Still better to die than return success for non-existant IUSE. :) One caveat - this will bomb out if an ebuild uses USE_EXPAND vars that are not in IUSE for such checks (I don't recall any such ebuild, if there's any, then either is should stick such stuff into IUSE or Bug 133327 should be solved).
Created attachment 96561 [details, diff] built_with_use.patch try this then please
!!! ERROR: net-analyzer/wireshark-0.99.3 failed. Call stack: ebuild.sh, line 1562: Called dyn_setup ebuild.sh, line 665: Called pkg_setup wireshark-0.99.3.ebuild, line 44: Called built_with_use 'dev-lang/perl' 'minimal' eutils.eclass, line 1605: Called die !!! dev-lang/perl-5.8.8-r2 does not actually support the minimal USE flag! !!! If you need support, post the topmost build error, and the call stack if relevant. After sticking minimal into /var/db/pkg/dev-lang/perl-5.8.8-r2/IUSE it emerges just fine, so I guess it does what's it supposed to do. ;)
added to cvs then
just for me to understand the ratio behind the scene and if you have time for answering such questions. can please give me a hint why you think it is better to have the check "manual" instead of "automated". is it to again the nature of for example the minimal flag, that you do not know what it concrete means in the future versions of package ? thanx
There's no real reason why the merge should die. Die is for situations where the function can't return a SANE result. If some ebuild doesn't support some useflag, it's completely SANE to return that it WASN'T built with that useflag. Yes, you should tell the user that there's something wrong about missing useflag in ebuild, however, simple warning is just enough. Why kill merge that can successfully finish?!
i'm not getting into this again, let alone on bugzilla the current behavior is sane, the value returned is meaningless, and if you want more information go read the portage mailing list
Sorry, bad idea. Just like returning true or killing the merge. Here's why: 1) The package has no such useflag because it was hardcoded into the new package - it's always on. You return false and the other package breaks because false is incorrect. Result: Broken package. 2) The package has no such useflag because it was removed from the new package - it's alway off. You return true and the other package breaks because true is incorrect. Result: Broken package. 3) The package has no such useflag because it was renamed in the new package - the same thing depends on another useflag. If the returned value doesn't match the presence of that useflag, the other package breaks because the returned value is incorrect. Result: Broken package. 4) You kill the merge, the user sends a bugreport and you 'fix' the dependent ebuild. However, you're fixing the effect, not the cause. If the useflag reappears a few versions later, you'll have to fix the dependent ebuild again and again and again. Result: Broken package in the future. The only correct solution I can think of is some sort of useflag history in ebuild where you could check what actually happened to the particular useflag you're looking for. If it was removed, you can return false. If it was hardcoded, you can return true. If it was renamed, you can check for the new useflag and return the proper value. If it was never there, you can kill the merge because that's a true ebuild bug.
you need to read comment #25 again
*** Bug 153463 has been marked as a duplicate of this bug. ***
