Created attachment 337410 [details] build.log # grep dev-python/setuptools -R /etc/portage/ -B1 /etc/portage/profile/package.use.mask/2-disable_tests_world.mask-# (bug #335120) FAIL: test_add_from_site_is_ignored (setuptools.tests.test_easy_install.TestPTHFileWriter) /etc/portage/profile/package.use.mask/2-disable_tests_world.mask:dev-python/setuptools test but emerge runs tests when rebuilding this package: >>> Source compiled. * python2.7: running distutils-r1_run_phase python_test /usr/bin/python2.7 setup.py test running test The problems exists with 'setuptools-0.6.30-r1.ebuild,v 1.14', but did not exist 'Thu Dec 13 13:13:55 2012' with 'setuptools-0.6.30-r1.ebuild,v 1.7'. Seems something is now broken in python-r1 related eclasses. Other 57 packages from '/etc/portage/profile/package.use.mask/' respect mask. Portage 2.1.11.31 (hardened/linux/amd64, gcc-4.6.3, glibc-2.15-r3, 3.7.4-hardened-r1 x86_64) ================================================================= System Settings ================================================================= Timestamp of tree: Thu, 31 Jan 2013 09:15:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r2 dev-util/cmake: 2.8.10.2-r1 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo nikoli ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=corei7-avx -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /usr/share/themes/oxygen-gtk/gtk-2.0 /usr/share/themes/oxygen-gtk/gtk-3.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=corei7-avx -O2 -pipe" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict test unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTDIR_OVERLAY="/var/lib/layman/nikoli" USE="X a52 aac acl acpi aes-ni akonadi alsa amd64 amr atm audiofile avx bash-completion bzip2 cairo caps cdda cddb cdio cdparanoia cdr celt cli consolekit cracklib crypt css cups cxx dbus djvu dri dts dv dvd dvdr encode exif fat ffmpeg flac fluidsynth fontconfig fortran gd geoip gif gimp gmp gnutls gphoto2 gpm graphviz gsm gstreamer gtk handbook hardened iconv icu id3tag idn ilbc imagemagick imap imlib ios ipod ipv6 jbig jpeg jpeg2k justify kde kipi kontact lame laptop lcms libass libnotify libproxy libsamplerate lm_sensors lzma lzo mac mad matroska mikmod mmx mmxext mng modplug modules mp3 mp4 mpeg mtp mudflap multilib musepack musicbrainz ncurses networkmanager nls nptl nptlonly ntfs ogg openal openexr opengl openmp opus pam pango pax_kernel pcre pdf pg-intdatetime phonon plasma pm-utils png policykit postscript qt3support qt4 quicktime rar raw readline reiserfs replaygain rtmp sasl scanner schroedinger semantic-desktop session sid smp sndfile socks5 speex spell sqlite sse sse2 sse3 sse4_1 ssl ssse3 startup-notification svg symlink sysfs taglib theora threads thumbnail tiff truetype tta udev udisks unicode upnp upower usb v4l v4l2 vcd vorbis vpx wavpack webkit webp wifi wma wmf x264 xattr xcb xcomposite xface xinerama xml xmp xpm xscreensaver xv xvid xz zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="*" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="pdfimport presenter-console presenter-minimizer report-builder nlpsolver" LINGUAS="ru ru_RU en" NGINX_MODULES_HTTP="access auth_basic autoindex fastcgi gzip rewrite" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby19" USERLAND="GNU" VIDEO_CARDS="radeon r600 modesetting vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= dev-python/setuptools-0.6.30-r1 was built with the following: USE="" PYTHON_TARGETS="python2_7 -python2_5 -python2_6 -python3_1 -python3_2"
Masking USE=test is not a method of disabling tests. In order to disable tests, you need to set FEATURES=-test. You can use /etc/portage/env for that.
Portage profiles use it, why users should not use it in local profiles? $ grep test$ `find profiles/ -name package.use.mask`|wc -l 26 Also are you sure you did not break package.use.mask from /usr/portage/profiles/?
(In reply to comment #2) > Portage profiles use it, why users should not use it in local profiles? > $ grep test$ `find profiles/ -name package.use.mask`|wc -l > 26 > > Also are you sure you did not break package.use.mask from > /usr/portage/profiles/? I have no idea how people used it and how it was supposed to work. It seems to me like a completely fragile thing which was never defined by the PMS. If it worked, good for you. If it didn't, I wouldn't be surprised. Feel free to provide a patch if you know how it should work.
Zac, please explain, what is now correct way of masking tests per package in global (portage tree, overlays) and local profiles? Should masking with profile/package.use.mask be supported?
This appears to be a change in portage behavior caused by setting EAPI=5. With EAPI=4, masking the test USE flag will disable the test phase, regardless of the contents of IUSE. With EAPI=5, masking the test USE flag only disables the test phase if the ebuild happens to set IUSE="test".
(In reply to comment #5) > This appears to be a change in portage behavior caused by setting EAPI=5. > > With EAPI=4, masking the test USE flag will disable the test phase, > regardless of the contents of IUSE. > > With EAPI=5, masking the test USE flag only disables the test phase if the > ebuild happens to set IUSE="test". If that's the case, then it's due to implicit USE flags change. In EAPI 5, the ebuild does no longer contain a random bunch of profile-injected flags.
(In reply to comment #6) That was my thought as well. Maybe we should add "test" to IUSE_IMPLICIT in the base profile?
(In reply to comment #4) > Zac, please explain, what is now correct way of masking tests per package in > global (portage tree, overlays) and local profiles? Should masking with > profile/package.use.mask be supported? You can use /etc/portage/package.env, like this: echo 'FEATURES="-test"' > /etc/portage/env/no_test.conf echo 'dev-python/setuptools no_test.conf' >> /etc/portage/package.env (In reply to comment #7) > (In reply to comment #6) > > That was my thought as well. Maybe we should add "test" to IUSE_IMPLICIT in > the base profile? Not sure if it's really necessary, give the above approach.
You could also use package.env to enable FEATURES=test-fail-continue selectively.
Please add. Reasons: 1) If it worked and was used, why break? Was there any announce about this breakage? I think no. 2) package.env seems fine for local /etc/portage/, but not for profiles in overlays and portage tree. In portage tree it is possible to mask tests for some arch by editing RESTRICT in ebuild, but in overlay it is better to use package.use.mask when ebuild is in portage tree only. Copying ebuild to overlay and keeping it in sync with portage tree changes only for custom RESTRICT seems not best approach. 3) Using package.use.mask is just simpler: creating file with custom env variables and then sourcing it via second file vs just masking one USE flag by adding one line to one file.
(In reply to comment #10) > Please add. Reasons: > 1) If it worked and was used, why break? Was there any announce about this > breakage? I think no. Well, it was discussed in the sense that IUSE_IMPLICIT was discussed. But no, the affect that it would have on people who rely on package.use.mask to disable tests was not discussed (to my knowledge). > 3) Using package.use.mask is just simpler: creating file with custom env > variables and then sourcing it via second file vs just masking one USE flag > by adding one line to one file. IUSE_IMPLICIT changes really should be discussed on the gentoo-dev mailing list, because they will affect the policy for what needs to be explicitly listed in IUSE for *all* ebuilds.
(In reply to comment #10) > Please add. Reasons: > 1) If it worked and was used, why break? Was there any announce about this > breakage? I think no. How do you know that it worked? Maybe it worked only for the few people who actually used it? Did it work in pkgcore and paludis? > 2) package.env seems fine for local /etc/portage/, but not for profiles in > overlays and portage tree. > In portage tree it is possible to mask tests for some arch by editing > RESTRICT in ebuild, but in overlay it is better to use package.use.mask when > ebuild is in portage tree only. Copying ebuild to overlay and keeping it in > sync with portage tree changes only for custom RESTRICT seems not best > approach. Restricting tests per-arch is not a good idea. That usually means that someone is masking failures and pretending that something does work properly. > 3) Using package.use.mask is just simpler: creating file with custom env > variables and then sourcing it via second file vs just masking one USE flag > by adding one line to one file. How simpler? We're talking about creating one file in /etc/portage/env once and using it in /etc/portage/package.env vs creating a local profile.
> How do you know that it worked? Maybe it worked only for the few people who > actually used it? Did it work in pkgcore and paludis? I have FEATURES=test in make.conf since 2010 year using only package.use.mask for disabling tests per package. It worked fine until this bug report. Do not use pkgcore or paludis. > Restricting tests per-arch is not a good idea. That usually means that someone > is masking failures and pretending that something does work properly. It was just example, possibly not the best. Actually i never masked tests per profile or arch, the only use case i had: mask broken tests without any condition. > > 3) Using package.use.mask is just simpler: creating file with custom env > > variables and then sourcing it via second file vs just masking one USE flag > > by adding one line to one file. > > How simpler? We're talking about creating one file in /etc/portage/env once and > using it in /etc/portage/package.env vs creating a local profile. When you open '/etc/portage/profile/package.use.mask' and see line 'foo/bar test', you sure know, that tests are disabled for package foo/bar When you open '/etc/portage/package.env' and see 'foo/bar notests.conf', you guess, that tests are disabled. But you do not know it for sure until you read '/etc/portage/env/test.conf' If you are dealing with your current desktop system, you remember what every custom .conf does, but if it is system, which you see first time or did not see for a while, you need to read these custom .conf files and check what and how exactly are they doing.
(In reply to comment #13) > > > 3) Using package.use.mask is just simpler: creating file with custom env > > > variables and then sourcing it via second file vs just masking one USE flag > > > by adding one line to one file. > > > > How simpler? We're talking about creating one file in /etc/portage/env once and > > using it in /etc/portage/package.env vs creating a local profile. > > When you open '/etc/portage/profile/package.use.mask' and see line 'foo/bar > test', you sure know, that tests are disabled for package foo/bar No. When I see that, I say 'wtf?' Did someone just mask test dependencies? > When you open '/etc/portage/package.env' and see 'foo/bar notests.conf', you > guess, that tests are disabled. But you do not know it for sure until you > read '/etc/portage/env/test.conf' > If you are dealing with your current desktop system, you remember what every > custom .conf does, but if it is system, which you see first time or did not > see for a while, you need to read these custom .conf files and check what > and how exactly are they doing. Do you often work with systems where people intentionally put 'no-tests' files in order to do something else than disabling tests?
(In reply to comment #8) > (In reply to comment #4) > > Zac, please explain, what is now correct way of masking tests per package in > > global (portage tree, overlays) and local profiles? Should masking with > > profile/package.use.mask be supported? > > You can use /etc/portage/package.env, like this: > > echo 'FEATURES="-test"' > /etc/portage/env/no_test.conf > echo 'dev-python/setuptools no_test.conf' >> /etc/portage/package.env Don't do that; fix the actual issue, the ability to disable tests via USE=-test has been around a *long* time- I know pkgcore has had it for years, and portage has had similar (minimally, look at bug #373209 fixing portage support yet again). > (In reply to comment #7) > > (In reply to comment #6) > > > > That was my thought as well. Maybe we should add "test" to IUSE_IMPLICIT in > > the base profile? > > Not sure if it's really necessary, give the above approach. PMS doesn't even discuss FEATURES, so adding test to IUSE_IMPLICIT still doesn't actually lock down the long standing behaviour; it would just fix portage for eapi5. Frankly, it's better to just recognize the history here and add the exception; if folks want to force it via IUSE_IMPLICT, fine, although that means each/every profile structure people build will have to carry all of those (which is kind of retarded).
(In reply to comment #15) > Don't do that; fix the actual issue, the ability to disable tests via > USE=-test has been around a *long* time- I know pkgcore has had it for > years, and portage has had similar (minimally, look at bug #373209 fixing > portage support yet again). > > PMS doesn't even discuss FEATURES, so adding test to IUSE_IMPLICIT still > doesn't actually lock down the long standing behaviour; it would just fix > portage for eapi5. > > Frankly, it's better to just recognize the history here and add the > exception; if folks want to force it via IUSE_IMPLICT, fine, although that > means each/every profile structure people build will have to carry all of > those (which is kind of retarded). Then we'd have to retroactively amend PMS for EAPI 5. Re-assigning to pms-bugs, since there's nothing to do for portage unless we amend PMS.
(In reply to comment #16) > (In reply to comment #15) > > Don't do that; fix the actual issue, the ability to disable tests via > > USE=-test has been around a *long* time- I know pkgcore has had it for > > years, and portage has had similar (minimally, look at bug #373209 fixing > > portage support yet again). > > > > PMS doesn't even discuss FEATURES, so adding test to IUSE_IMPLICIT still > > doesn't actually lock down the long standing behaviour; it would just fix > > portage for eapi5. > > > > Frankly, it's better to just recognize the history here and add the > > exception; if folks want to force it via IUSE_IMPLICT, fine, although that > > means each/every profile structure people build will have to carry all of > > those (which is kind of retarded). > > Then we'd have to retroactively amend PMS for EAPI 5. Re-assigning to > pms-bugs, since there's nothing to do for portage unless we amend PMS. In the interim, portage broke it's own behaviour. I'd fix that rather than play hot potatoe w/ PMS. :)
Portage's EAPI 5 behavior is intentional, since it results from EAPI 5's implicit IUSE rules. I don't like the idea of using use.mask settings for things that aren't members of IUSE_EFFECTIVE. It just doesn't feel right.
I think "test" became a special case when it was bound to FEATURES. If FEATURES="test" enables or disables tests for all packages, whether they have "test" in IUSE or not, it stands to reason that masking the flag to disable the feature would work likewise. The current behaviour is confusing and inconsistent (I've been wondering for weeks now why half my masks haven't been working).
IIUC this bug isn't about the spec but about the implementation. Reassigning (keeping pms in CC).
Ping. Looks like we won't revert to EAPI 4 behaviour, and I see no other suggestion for a change. So, can this bug be closed?
Closing per comment #6 and comment #18.