Created attachment 408146 [details] emerge log At my tinderbox it happens now few times in a row that a newly created chroot image failed in its initially system/world upgrade - always at the same package/step, an example is attached. /me wonders if portage should run after a (major) perl upgrade automatically "perl-cleaner --all" before it continues in its package list ? BTW would an "emerge -1u perl; emerge -uD @system" be a work around ?
# emerge --info Portage 2.2.20 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop, gcc-4.8.4, glibc-2.21-r1, 4.0.8-hardened x86_64) ================================================================= System uname: Linux-4.0.8-hardened-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 16164692 total, 848192 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Sun, 02 Aug 2015 13:45:01 +0000 sh bash 4.3_p39 ld GNU ld (Gentoo 2.25.1 p1.0) 2.25.1 app-shells/bash: 4.3_p39::gentoo dev-lang/perl: 5.22.0::gentoo dev-lang/python: 2.7.10::gentoo, 3.4.3::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.17::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.69-r1::gentoo sys-devel/automake: 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1::gentoo sys-devel/gcc: 4.8.4::gentoo sys-devel/gcc-config: 1.8::gentoo sys-devel/libtool: 2.4.6-r1::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.21-r1::gentoo Repositories: local location: /usr/local/portage masters: gentoo gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: 9999 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/var/tmp/distfiles" EMERGE_DEFAULT_OPTS="--nospinner --tree --quiet-build --accept-properties=-interactive --accept-restrict=-fetch" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync network-sandbox news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo rsync://mirror.netcologne.de/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gor.bytemark.co.uk/gentoo/ rsync://ftp.snt.utwente.nl/gentoo" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" 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" USE="X a52 aac acl acpi alsa amd64 apache2 berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit corefonts cracklib crypt cups curl custom-cflags cxx dbus dot dri dts dvd dvdr ecc elp emboss encode exif fam ffmpeg firefox flac fontconfig fortran fpm freetds gd gdbm gif glamor gnome-keyring gpm gtk gudev h hpn iconv inifile ipv6 jadetex jpeg kde kvm lcms ldap libnotify logrotate mad mbox minizip mmx mmxext mng modules mp3 mp4 mpeg multilib mysql mysqli ncurses nls nptl obj odbc offensive ogg opengl openmp pam pango pax_kernel pcre pdf pdo png policykit postgres ppds pwquality qemu qml qt3support qt4 qt5 readline sdl session smartcard sockets spell sqlite3 sse sse2 sse4 sse4_1 ssl ssse3 startup-notification svg system-jpeg system-sqlite tcl tcpd tiff tk truetype udev udisks unicode upower usb vorbis wxwidgets x264 xa xcb xml xmp xscreensaver xv xvid xvmc zenmap 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="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 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" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_GB" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" 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, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Not our problem. This is only happening because many base-system packages do not declare proper Perl dependencies (for which they would need to use EAPI=5 in their ebuilds.) There's absolutely nothing the Perl team can do.
The problem appears due to help2man (probably due to nls use flag). help2man itself has a pure dependency on perl but without subslot. It should be subslotted probably.
(In reply to Andreas K. Hüttel from comment #2) of course there is -- you can explain what exactly "proper dependencies" are and even provide a simple patch for help2man
I added a quirk to my tinderbox scripts.
I think ebuild simply needs to change: dev-lang/perl by: dev-lang/perl:= but, for that, it needs to use eapi5... that is usually not a problem, but looks like there are some issues with this in some base system packages :| The following link exposes how to set perl dependencies to prevent issues like this and, in the future, even deprecate perl-cleaner: http://dilfridge.blogspot.de/2014/11/rdepending-on-perl-itself.html Thanks
From the build log: Can't locate Locale/gettext.pm in @INC (you may need to install the Locale::gettext module) (@INC contains: /etc/perl /usr/local/lib64/perl5/5.22.0/x86_64-linux /usr/local/lib64/perl5/5.22.0 /usr/lib64/perl5/vendor_perl/5.22.0/x86_64-linux /usr/lib64/perl5/vendor_perl/5.22.0 /usr/lib64/perl5/5.22.0/x86_64-linux /usr/lib64/perl5/5.22.0 .) at /usr/bin/help2man line 29. So, the libtool build uses help2man and needs its nls support. Solution: add "sys-apps/help2man[nls]" to DEPEND.
(In reply to Andreas K. Hüttel from comment #7) pretty sure that's incorrect. help2man, when built with USE=-nls, does not import the gettext module. if libtool did actually need nls functionality, it would have gotten an error message like so: die "$this_program: no locale support (Locale::gettext required)\n" so we're back to where we started -- comment #2 & comment #4
(In reply to Andreas K. Hüttel from comment #7) > From the build log: > > Can't locate Locale/gettext.pm in @INC (you may need to install the > Locale::gettext module) (@INC contains: /etc/perl > /usr/local/lib64/perl5/5.22.0/x86_64-linux /usr/local/lib64/perl5/5.22.0 > /usr/lib64/perl5/vendor_perl/5.22.0/x86_64-linux > /usr/lib64/perl5/vendor_perl/5.22.0 /usr/lib64/perl5/5.22.0/x86_64-linux > /usr/lib64/perl5/5.22.0 .) at /usr/bin/help2man line 29. > > So, the libtool build uses help2man and needs its nls support. > > Solution: add "sys-apps/help2man[nls]" to DEPEND. As this is the error, then I think sys-apps/help2man was built already with USE="nls" enabled -- if this could be confirmed i think it would help. Now if that's true, the issue here is that dev-perl/Locale-gettext (which *is* slated for rebuild) is scheduled for rebuild too late and help2man remains broken in between the upgrade of dev-lang/perl and dev-perl/Locale-gettext. The sys-devel/libtool merge simply happened to fall into that timeline.[1] So, in this case, what we actually need is a way to ensure packages depending on help2man are either emerged before the perl upgrade, or after the Locale-gettext rebuild. Since help2man is(should be) a DEPEND atom, and does already exist in the system, i'm not sure if adding a subslot operator on its dev-lang/perl atom is actually going to help anything. [1] Now, one thing that I *DONT* understand, is that help2man is only a DEPEND atom on libtool-9999 , while it seems rather obvious based on the build failure here that it's being used during the build of libtool-2.4.6-r1. I think this in and of itself is a bug that should be addressed: either make libtool DEPEND all the time or remove the automagic use of help2man in the build system.
OK, so i've confirmed with every test I can think of, that help2man is *not* optional when building sys-devel/libtool-2.4.6-r1 and likely the other versions in the tree as well. The build always attempts to run help2man on doc/libtool.1 (despite it already being there), and always fails if help2man can't be found or run. No matter what issue may exist in relation to perl and subslot rebuilds, libtool needs this dependency, OR it needs its build system patched so that a missing (and preferably, existing but failing) help2man doesn't cause the build to fail, especially when libtool.1 and others already exist.
(In reply to Ian Stakenvicius from comment #10) > OK, so i've confirmed with every test I can think of, that help2man is *not* > optional when building sys-devel/libtool-2.4.6-r1 and likely the other > versions in the tree as well. The build always attempts to run help2man on > doc/libtool.1 (despite it already being there), and always fails if help2man > can't be found or run. ...here's why: Makefile.am, line 415: > # It's wrong to make distributed files (e.g. $(libtool_1)) rely on > # files created in the build tree, so instead we regenerate the > # manual pages if the sources for the build-tree files we want to > # run have changed. > $(libtool_1): $(ltmain_sh) > $(AM_V_GEN)$(update_mans) --help-option=--help-all libtool > $(libtoolize_1): $(libtoolize_in) > $(AM_V_GEN)$(update_mans) libtoolize
(In reply to Ian Stakenvicius from comment #9) the man pages are not stored in git, so it always needs help2man to build the man pages. the release tarball includes them, but sometimes patches tweak timestamps in a way that they inadvertently get regenerated. in this case, we patch build-aux/ltmain.in which regenerates build-aux/ltmain.sh which regenerates libtool which regenerates doc/libtool.1 which needs help2man. http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=840e66d340d39348cf401d8079138b7ed5676354
(In reply to Pacho Ramos from comment #6) i don't think help2man is broken here actually. why does it need a subslot dep on perl ? it doesn't install any modules ... it only installs a /usr/bin/ script which imports other modules. it also doesn't need any subslot dep on Locale-gettext for the same reason. that means only Locale-gettext needs a subslot dep on perl stuff, and i'm assuming that's already fixed.
