Update to 0.270.0 will fix this issue.
Please attach context from test failure. You're probably right, but no context makes for a very poor bug report.
Created attachment 396886 [details] build.log
Portage 2.2.14 (python 3.3.5-final-0, hardened/linux/amd64, gcc-4.8.3, glibc-2.19-r1, 3.17.7-hardened-r1 x86_64) ================================================================= System uname: Linux-3.17.7-hardened-r1-x86_64-Intel-R-_Core-TM-_i7-2600K_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 8133844 total, 345676 free KiB Swap: 8388604 total, 8034480 free Timestamp of tree: Wed, 18 Feb 2015 18:15:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.2_p53 dev-java/java-config: 2.2.0 dev-lang/perl: 5.20.2 dev-lang/python: 2.7.9-r1, 3.3.5-r1 dev-util/cmake: 2.8.12.2-r1 dev-util/pkgconfig: 0.28-r1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.9 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6-r1, 1.13.4 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.8.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.4 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.16 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo perl-experimental-snapshots gamerlay powerman local ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/upsmon-usb/EXT/DownOS /opt/upsmon-usb/EXT/JSystem /service /usr/inferno/keydb /usr/inferno/lib /usr/inferno/services /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/easy-rsa /usr/share/gnupg/qualified.txt /var/log /var/qmail/alias /var/qmail/control" 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" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage-distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y --autounmask-write" FCFLAGS="-march=native -O2 -pipe" FEATURES="assume-digests binpkg-logs clean-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-march=native -O2 -pipe" GENTOO_MIRRORS="http://tux.rainside.sk/gentoo/ http://trumpetti.atm.tut.fi/gentoo/ http://gentoo.inode.at/" LANG="ru_RU.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j8" PKGDIR="/usr/portage-packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--exclude ChangeLog --delete-excluded" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/perl-experimental-snapshots /var/lib/layman/gamerlay /var/lib/layman/powerman /usr/local/portage" SYNC="rsync://rsync.ua.gentoo.org/gentoo-portage" USE="X a52 aac adns aes alac alsa amd64 avx bash-completion berkdb bzip2 caps cdda cddb cli cracklib crypt cups cxx dbus dri drm dts dvb dvd flac fontconfig gallium gdbm gif gnutls gpg hardened iconv icu id3tag idn ipv6 jpeg jpeg2k justify libav libnotify mac mad matroska mbox mmx mmxext mng modules mp3 mpeg multilib musepack ncurses network-cron nls nptl nsplugin ogg opengl openmp openvg pam pax_kernel pcre perl png popcnt qt3support readline session spell sse sse2 sse3 sse4_1 sse4_2 ssl ssse3 svg tcpd theora tiff truetype udev unicode urandom vdpau vim-syntax vorbis wavpack x264 xattr xosd xtpax xv xvid xvmc zlib" ABI_X86="64" 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" APACHE2_MODULES="log_config vhost_alias autoindex alias rewrite dir deflate filter mime negotiation auth_basic authn_file authz_host authz_user authz_groupfile cgi actions headers env setenvif" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" 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 ublox ubx" GRUB_PLATFORMS="efi-64 pc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en ru ru_RU" NGINX_MODULES_HTTP="access auth_basic autoindex browser charset empty_gif fastcgi geo gzip limit_conn limit_req map memcached proxy referer rewrite scgi split_clients ssi upstream_ip_hash userid uwsgi fancyindex" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" QEMU_SOFTMMU_TARGETS="x86_64 i386" QEMU_USER_TARGETS="x86_64 i386" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="nvidia nouveau" 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, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, USE_PYTHON
Hm, this bug seems to be triggered by some kind of Moo/Test-Fatal/Try-Tiny interaction. But I don't seem to be able to reproduce it reliably. Best data I have says Moo 1.005 started this bug. ( But I can't even reproduce it with Moo 1.005, and I can't reproduce it locally without having Moo 1.006 ) equery l Moo ? Of course, this means we should fix it before we add Moo >=1.006 to tree, but that's presently only archaic 1.4.2 http://packages.gentoo.org/package/dev-perl/Moo
(In reply to Kent Fredric from comment #4) > Hm, this bug seems to be triggered by some kind of Moo/Test-Fatal/Try-Tiny > interaction. > > But I don't seem to be able to reproduce it reliably. I'm using Moo-1.7.0, which isn't in portage. I had to update Moo because Pod-Readme-1.1.2 depend on >=dev-perl/Moo-1.4.5. And I had to update Pod-Readme because of dev-perl/Dist-Zilla-Plugin-ReadmeFromPod-0.320.0. Which in turn was one of updates needed to install dev-perl/Dist-Milla. BTW, it was a huge headache to get Dist::Milla installed with portage. It (or it dependencies) require nearly latest Dist::Zilla, so I've to add about 40-50 packages on top of perl-experimental overlay. I was nearly ready to give up and install all of them in a couple of minutes with single cpanm command in ~/perl5/. Probably this isn't a right place to discuss this issue, but what is officially recommended "right way" to prepare environment for development in Perl? Use only available in portage perl modules isn't an option - too many important modules are missing, use only versions (even ~arch) of perl modules in portage also isn't an option - most modules are too outdated and usually latest version from CPAN works better (at least it pass tests!). Install CPAN modules system-wide manually using cpan/cpanm as root - also isn't an option, because portage version of same modules have higher priority in @INC and thus cpan/cpanm fall into endless loop when trying to upgrade some module which is already installed by portage. Remove all modules installed by portage and use only manually installed modules - result in big headache with manuall support of packages.provided, and it's too easy to overlook missing dependency on world update which result in installing some perl modules from portage, effectively hiding usually newer version installed by cpan/cpanm. Why not use g-cpan to automatically update all CPAN modules to latest versions every few hours in some overlay? Even if it will keep only ebuilds for modules which successfully pass tests it may be a huge advantage over current situation. And if we add a couple of small fixed to make g-cpan handle modules based on Module::Build::Tiny this way we'll probably will cover 99% of CPAN modules.
The "right" option with regards to a development environment is not to use portage at all for your perl modules, and to isolate your development environment from Gentoo. This is why I've been so hell-bent on getting dev-perl/App-cpanminus, dev-perl/local-lib and dev-perl/App-perlbrew into tree. These three modules make it straight forward to begin working independently of Gentoo. local-lib is the "lazy" option which allows you to install your own dependencies locally in ~/ and while still inheriting gentoo modules and gentoo perl. perlbrew is the "serious" option which builds a perl in ~/ Both give code to inject into ~/.bashrc so that the rest of perl toolchain use the above as install targets. gcpan itself has historically caused more problems than it fixes. ( Additionally, if you need some more stringent dependency management, Carton might be something we could look into providing as well ) But fully automated tree generation is simply not viable presently. I've worked on it a bit, but its a giant mindblow. So yes: > I was nearly ready to give up and install all of them in a couple of minutes with single cpanm command in ~/perl5/. That is IMO the "preferred" option for development tasks ( And it is how I myself do it, and it is the way upstream recommend it for every flavour of linux ) The contents of /usr/ are more tailored to supporting other things in /usr/ as dependencies of top level applications that users may want to use. ( That is, you should consider augmenting "/usr/" perl to be "for gentoo' , not "for gentoo users" )
Hmm. Isn't this way we will get different behaviour/bugs for all apps in /usr/bin/ which use perl - when they run by root they'll use gentoo's perl modules, when they run by me they'll use perl modules from my ~/perl5/, when they run by some other user they will work in 3rd different way because his ~/perl5/ differs from mine...?
(In reply to Alex Efros from comment #7) > Hmm. Isn't this way we will get different behaviour/bugs for all apps in > /usr/bin/ which use perl - when they run by root they'll use gentoo's perl > modules, when they run by me they'll use perl modules from my ~/perl5/, when > they run by some other user they will work in 3rd different way because his > ~/perl5/ differs from mine...? Yeah. That is occasionally a problem. And thats a problem that is somewhat exacerbated by this: grep 'usr/bin/env perl' -l /usr/bin/* 2>/dev/null If you're using local::lib, you need to unset PERL5LIB prior to running system perl apps, and if you're using perlbrew, you'll need to unset PATH to avoid them running on the wrong perl. But "which perl it should run on" is a generic debate that has been waged for aeons :/ Ultimately there's things that will be sub-optimal whatever direction you travel, its just a matter of working out which ones matter most to you. Yes, Ideally, we'd be able to have everything roll out automatedly as soon as it hits cpan. But realistically, the plumbing required for that is way more than it looks.
But I should add, all of the above are far better than having a hosed system because you updated something blindly which breaks installation of other gentoo packages ;)
(In reply to Kent Fredric from comment #9) > But I should add, all of the above are far better than having a hosed system > because you updated something blindly which breaks installation of other > gentoo packages ;) You mean this is the main reason why vendor_perl have higher priority than site_perl in @INC in Gentoo (which is actually the real root of discussed issue)?
(In reply to Alex Efros from comment #10) > (In reply to Kent Fredric from comment #9) > > But I should add, all of the above are far better than having a hosed system > > because you updated something blindly which breaks installation of other > > gentoo packages ;) > > You mean this is the main reason why vendor_perl have higher priority than > site_perl in @INC in Gentoo (which is actually the real root of discussed > issue)? No. perl -V:sitelibexp sitelibexp='/usr/local/lib64/perl5/5.20.2'; perl -V:vendorlibexp vendorlibexp='/usr/lib64/perl5/vendor_perl/5.20.2'; perl -V:privlibexp privlibexp='/usr/lib64/perl5/5.20.2'; @INC: /etc/perl # extra /usr/local/lib64/perl5/5.20.2/x86_64-linux # site arch /usr/local/lib64/perl5/5.20.2 # site /usr/lib64/perl5/vendor_perl/5.20.2/x86_64-linux # vendor arch /usr/lib64/perl5/vendor_perl/5.20.2 # vendor /usr/local/lib64/perl5 # extra /usr/lib64/perl5/vendor_perl/5.20.1/x86_64-linux # legacy vendor arch /usr/lib64/perl5/vendor_perl/5.20.1 # legacy vendor /usr/lib64/perl5/vendor_perl # probably a bug /usr/lib64/perl5/5.20.2/x86_64-linux # private arch ( perl itself ) /usr/lib64/perl5/5.20.2 # private site > vendor > core
(In reply to Kent Fredric from comment #11) > site > vendor > core Wow. Last time I've checked this was many years ago, site was in /usr/lib/perl5/site_perl/5.*/, not in /usr/local/lib/perl5/5.*/, and vendor_perl had higher priority than site_perl in Gentoo (and lower by default in perl and most other distro). Thanks, looks like now we can use cpanm as root to avoid all issues mentioned above!
Converting this bug into a bump request because its a low-importance feature-enhancement that won't be a bug until something else happens in tree. At least this way if somebody files a bump req for Moo they can just make it depend on this :)
Bumped.
