Created attachment 556954 [details] gcc-build-logs.tar.bz2 Portage 2.3.52 (python 3.6.6-final-0, default/linux/amd64/17.0/desktop/plasma, gcc-8.2.0, glibc-2.28-r2, 4.19.5-gentoo x86_64) ================================================================= System uname: Linux-4.19.5-gentoo-x86_64-Intel-R-_Core-TM-_i7-4900MQ_CPU_@_2.80GHz-with-gentoo-2.6 KiB Mem: 16102336 total, 2490856 free KiB Swap: 8388604 total, 8388604 free Head commit of repository 4nykey: 7eaf14daec3478ef3aeff4cdd2f7ed8ff8656924 Head commit of repository bliss-overlay: 150f6a676bb8abd52255cfe22ca5d158dae3bbca Timestamp of repository earshark: Sat, 01 Dec 2018 19:44:54 +0000 Head commit of repository earshark: c9afa6401159a208227ee47a9b04fd0844276aa7 Head commit of repository steam-overlay: 0db8f021e8c769344a1fdb5c17b914353b03abba Timestamp of repository gentoo: Sun, 02 Dec 2018 14:44:28 +0000 Head commit of repository gentoo: 4e16aeebd73a897fd26e81e25f20c33493884150 sh bash 4.4_p23 ld GNU ld (Gentoo 2.31.1 p3) 2.31.1 ccache version 3.5 [disabled] app-shells/bash: 4.4_p23::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.26.2::gentoo dev-lang/python: 2.7.15::gentoo, 3.6.6::gentoo, 3.7.0::gentoo dev-util/ccache: 3.5-r1::gentoo dev-util/cmake: 3.13.1::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.39.2::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.16.1-r1::gentoo sys-devel/binutils: 2.31.1-r1::gentoo sys-devel/gcc: 8.2.0-r4::gentoo sys-devel/gcc-config: 2.0::gentoo sys-devel/libtool: 2.4.6-r5::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers) sys-libs/glibc: 2.28-r2::gentoo Repositories: 4nykey location: /var/lib/overlays/4nykey sync-type: git sync-uri: https://github.com/4nykey/4nykey.git masters: gentoo bliss-overlay location: /var/lib/overlays/bliss-overlay sync-type: git sync-uri: https://github.com/fearedbliss/bliss-overlay.git masters: gentoo earshark location: /var/lib/overlays/earshark sync-type: git sync-uri: https://github.com/gentoo-mirror/earshark.git masters: gentoo steam-overlay location: /var/lib/overlays/steam-overlay sync-type: git sync-uri: https://github.com/anyc/steam-overlay.git masters: gentoo gentoo location: /usr/portage sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo.git priority: 1000 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" 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 -march=native" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y --keep-going=y --quiet-build" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,--hash-style=gnu" LINGUAS="en pl" MAKEOPTS="-j8" 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 --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi activities alsa amd64 berkdb bluetooth bzip2 cairo cdda cdr cli consolekit crypt cups cxx dbus declarative dri dts dvd dvdr emboss encode exif fam flac fortran gallium gdbm gif glamor gpm gtk iconv ipv6 jpeg kde kipi kwallet laptop lcms ldap libnotify libtirpc libzfs mad mng mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds pulseaudio qml qt5 readline sdl seccomp semantic-desktop spell ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vaapi vorbis widgets wxwidgets x264 xattr xcb xcomposite xml xv xvid zfs 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="karbon plan sheets stage words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc emu efi-64" INPUT_DEVICES="libinput synaptics mouse keyboard evdev" KERNEL="linux" L10N="en en_US pl pl_PL" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby23 ruby24" USERLAND="GNU" VIDEO_CARDS="intel i965 nvidia" 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: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
* Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). There is no problem if you simply drop 'collision-protect' from FEATURES. Assigning toolchain just in case this leftover is a symptom of anything.
One: * If portageq reports that only one package owns a file then do * NOT file a bug report. Two: * And once again, please do NOT file a bug report * unless you have completely understood the above message. * * package sys-devel/gcc-8.2.0-r5 NOT merged * * Detected file collision(s): * * /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). Three: Do not file a bug report.
These files are owned nowadays: $ qfile /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/* sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/cpp.info) sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir) sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/gcc.info) sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/cppinternals.info) sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/gccinstall.info) sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/gccint.info) sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/libquadmath.info) sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/libgomp.info) sys-devel/gcc (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/libitm.info) But I have a few orphans that look unexpected: $ qfile -o /usr/share/gcc-data/x86_64-pc-linux-gnu/*/info/* /usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.4/info/dir.old /usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.5/info/dir.old /usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.6/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.6/info/dir.old /usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info/dir.old /usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0/info/dir.old /usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info/dir I wonder if prepman used to produce unowned 'dir' files which was fixed accidentally in: https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/toolchain.eclass?id=c3277200aee40cf90d32221e7ec776f41c61443c I'll have a closer look. As a workaround you can manually remove all orphan files reported by: $ qfile -o /usr/share/gcc-data/x86_64-pc-linux-gnu/*/info/*
I see portage's lib/portage/util/_info_files.py does 'dir' / 'dir.old' handling. CCing dev-portage@ in case it's a known problem.
The dir and dir.old files are generated by emerge before it exits, for every directory in INFOPATH. It's never been considered a problem, it's just the expected behavior. FEATURES="noinfo" disables this behavior, but it also adds info files to INSTALL_MASK.
(In reply to Zac Medico from comment #5) > The dir and dir.old files are generated by emerge before it exits, for every > directory in INFOPATH. It's never been considered a problem, it's just the > expected behavior. Aha. Is it added to package's CONTENTS as well? I wonder why I don't have old files uninstalled. Might be a leftover from times when I used paludis (paludis did not like to uninstall files which contents did not match vdb checksums). > FEATURES="noinfo" disables this behavior, but it also adds info files to INSTALL_MASK. Interesting. I never had FEATURES="noinfo" set and yet I had the orphans. Do you know if prepinfo had similar effect whet was not a no-op?
I ran into this on fresh install moving from amd64 to ~amd64 (during the gcc upgrade). Not sure when or where the file came from. I just rm'd it and resumed since it wasn't owned.
(In reply to Sergei Trofimovich from comment #6) > (In reply to Zac Medico from comment #5) > > The dir and dir.old files are generated by emerge before it exits, for every > > directory in INFOPATH. It's never been considered a problem, it's just the > > expected behavior. > > Aha. Is it added to package's CONTENTS as well? I wonder why I don't have > old files uninstalled. Might be a leftover from times when I used paludis > (paludis did not like to uninstall files which contents did not match vdb > checksums). It's not added to CONTENTS. Multiple packages can install info files in the same directory, so how would we decide which package "owns" the dir file? > > FEATURES="noinfo" disables this behavior, but it also adds info files to INSTALL_MASK. > > Interesting. I never had FEATURES="noinfo" set and yet I had the orphans. If you never had FEATURES="noinfo" set, the orphans are expected for any directory included in INFOPATH. Note that FEATURES="collision-protect" is not enabled by default, so it's not a problem with default configuration.
(In reply to Zac Medico from comment #8) > (In reply to Sergei Trofimovich from comment #6) > > (In reply to Zac Medico from comment #5) > > > The dir and dir.old files are generated by emerge before it exits, for every > > > directory in INFOPATH. It's never been considered a problem, it's just the > > > expected behavior. > > > > Aha. Is it added to package's CONTENTS as well? I wonder why I don't have > > old files uninstalled. Might be a leftover from times when I used paludis > > (paludis did not like to uninstall files which contents did not match vdb > > checksums). > > It's not added to CONTENTS. Multiple packages can install info files in the > same directory, so how would we decide which package "owns" the dir file? Oh, is the below a gcc ebuild bug then? Or a portage bug? $ qlist sys-devel/gcc | fgrep info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/3.3.6/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.6/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.4/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.4/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info/dir /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir gcc has INFOPATH only for one active gcc in /etc/env.d. Should we change to all gccs? But even that does not seem to be enough to avoid /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir from getting into CONTENTS. Should I remove files manually?
(In reply to Sergei Trofimovich from comment #9) > Oh, is the below a gcc ebuild bug then? Or a portage bug? I think it's best if we allow portage to create the info dir files, for consistency with other packages that install info files in directories like /usr/share/info that are shared with other packages. > $ qlist sys-devel/gcc | fgrep info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/3.3.6/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.6/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/4.0.4/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.4/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info/dir > /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir > > gcc has INFOPATH only for one active gcc in /etc/env.d. Should we change to > all gccs? There's an alternative INFODIR variable that portage supports, so maybe use that if it's preferable to adding them all to INFOPATH. > But even that does not seem to be enough to avoid > /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir from getting into > CONTENTS. Should I remove files manually? Yes.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d266c61788fe8457e0ed0d7674bcb5d963692e8c commit d266c61788fe8457e0ed0d7674bcb5d963692e8c Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-12-04 09:05:17 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-12-04 11:05:57 +0000 toolchain.eclass: drop info/dir index, bug #672408 As explained by Zac in #672408 prepinfo() was used to drop 'info/dir' index to allow portage regenerate it. gcc package does not always install 'info/dir' files (USE-dependent). This causes nondeterminism for 'info/dir' to be owned or be an orphan file. This change drops 'info/dir' unconditionally to avoid owned/orphan collisions and always make it an orphan file. Reported-by: Michal Jakubowski Bug: https://bugs.gentoo.org/672408 Bug: https://bugs.gentoo.org/587316 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain.eclass | 8 ++++++++ 1 file changed, 8 insertions(+)
(In reply to Zac Medico from comment #10) > There's an alternative INFODIR variable that portage supports, so maybe use > that if it's preferable to adding them all to INFOPATH. Both variables are populated throught env.d, right? As I understand in general case that means that 'dir' orphans will always be left when package is uninstalled along with env.d entry. Because portage will run INFO rebuilding too late. Is my understanding correct? > > But even that does not seem to be enough to avoid > > /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir from getting into > > CONTENTS. Should I remove files manually? > > Yes. Thanks! Added 'dir' file deletion consistently into gcc ebuilds now. Would be nice if portage would keep those paths through package metadata and would act on those paths when: - any files are merged into those paths -> regenerate 'dir' files - any entries are added/removed to this magic path list -> regenerate/delete 'dir' files
(In reply to Sergei Trofimovich from comment #12) > (In reply to Zac Medico from comment #10) > > There's an alternative INFODIR variable that portage supports, so maybe use > > that if it's preferable to adding them all to INFOPATH. > > Both variables are populated throught env.d, right? As I understand in > general case that means that 'dir' orphans will always be left when package > is uninstalled along with env.d entry. Because portage will run INFO > rebuilding too late. Is my understanding correct? The uninstall code for bug 323213 evaluates INFOPATH and INFODIR and the beginning of the unmerge operation, so it should include INFOPATH and INFODIR settings from the package being unmerged: https://gitweb.gentoo.org/proj/portage.git/commit/?id=3acce846c43eed7feefd3ab9c47dd172a83ae1db > > > But even that does not seem to be enough to avoid > > > /usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info/dir from getting into > > > CONTENTS. Should I remove files manually? > > > > Yes. > > Thanks! Added 'dir' file deletion consistently into gcc ebuilds now. > > Would be nice if portage would keep those paths through package metadata and > would act on those paths when: > - any files are merged into those paths -> regenerate 'dir' files > - any entries are added/removed to this magic path list -> regenerate/delete > 'dir' files It should be doing that stuff already. The regeneration happens before emerge exits, and things are deleted during unmerge.
(In reply to Larry the Git Cow from comment #11) > This change drops 'info/dir' unconditionally to avoid owned/orphan > collisions and always make it an orphan file. This doesn't look right. Why should the dir file be an orphan, when it clearly belongs to the package? IIUC Portage will only flag a problem with FEATURES=collision-protect, which is neither the default nor a setting that is generally recommended. Maybe we should turn the logic around: - Have Portage only regenerate the dir in the top-level /usr/share/info (because it is shared by many packages). - Packages should be responsible to install dir files in their info directories, which will avoid orphan files. AFAICS only toolchain packages and Emacs install GNU Info files outside /usr/share/info, in order to avoid issues with slotting.
Is this still a problem?
(In reply to Andreas K. Hüttel from comment #15) > Is this still a problem? Apparently not.