>>> Emerging (1 of 1) sys-libs/db-4.8.30-r2::gentoo * db-4.8.30.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking db-4.8.30.tar.gz to /var/tmp/portage/sys-libs/db-4.8.30-r2/work >>> Source unpacked in /var/tmp/portage/sys-libs/db-4.8.30-r2/work >>> Preparing source in /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/build_unix ... * Applying db-4.8-libtool.patch ... [ ok ] * Applying db-4.8.24-java-manifest-location.patch ... [ ok ] * Applying db-4.8.30-rename-atomic-compare-exchange.patch ... [ ok ] * Applying db-4.6-jni-check-prefix-first.patch ... [ ok ] * Applying db-4.3-listen-to-java-options.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/dist' ... * Running libtoolize --install --copy --force ... [ ok ] * Running aclocal -I aclocal -I aclocal_java ... [ ok ] * Running autoconf -I aclocal -I aclocal_java --force ... [ !! ] * Failed Running autoconf ! * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-libs/db-4.8.30-r2/temp/autoconf.out * ERROR: sys-libs/db-4.8.30-r2::gentoo failed (prepare phase): * Failed Running autoconf ! * * Call stack: * ebuild.sh, line 90: Called src_prepare * environment, line 5311: Called eautoreconf * environment, line 1313: Called eautoconf '--force' * environment, line 1226: Called autotools_run_tool '--at-m4flags' 'autoconf' '--force' * environment, line 828: Called die * The specific snippet of code: * die "Failed Running $1 !"; * * If you need support, post the output of `emerge --info '=sys-libs/db-4.8.30-r2::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/db-4.8.30-r2::gentoo'`. !!! When you file a bug report, please include the following information: GENTOO_VM= CLASSPATH="" JAVA_HOME="/etc/java-config-2/current-system-vm" JAVACFLAGS="" COMPILER="" and of course, the output of emerge --info =db-4.8.30 * The complete build log is located at '/var/log/portage/sys-libs:db-4.8.30-r2:20150926-181957.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/sys-libs/db-4.8.30-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/db-4.8.30-r2/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/dist' * S: '/var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/build_unix' >>> Failed to emerge sys-libs/db-4.8.30-r2, Log file: >>> '/var/log/portage/sys-libs:db-4.8.30-r2:20150926-181957.log' /var/tmp/portage/sys-libs/db-4.8.30-r2/temp/autoconf.out: ***** autoconf ***** ***** PWD: /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/dist ***** autoconf -I aclocal -I aclocal_java --force configure.ac:461: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... aclocal/cxx.m4:16: AC_CXX_WSTRING is expanded from... configure.ac:461: the top level configure.ac:482: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from... aclocal/types.m4:43: AM_TYPES is expanded from... configure.ac:482: the top level configure.ac:482: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from... ../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from... aclocal/types.m4:43: AM_TYPES is expanded from... configure.ac:482: the top level autom4te-2.69: cannot open configure: Permission denied Reproducible: Always
I just got this too. The only thing I have changed is to migrate to gold. However, I currently have packages matching sys-libs/db configured not to use gold anyhow. Check this out (whitespace modified) moneypit ~ # ebuild /usr/portage/sys-libs/db/db-4.8.30-r2.ebuild clean unpack * db-4.8.30.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking db-4.8.30.tar.gz to /var/tmp/portage/sys-libs/db-4.8.30-r2/work >>> Source unpacked in /var/tmp/portage/sys-libs/db-4.8.30-r2/work moneypit ~ # chmod -Rc u+w /var/tmp/portage/sys-libs/db-4.8.30-r2 | wc -l 6899 This says that 6899 filesystem objects (presumably all either files or directories) were created by portage under /var/tmp/portage/sys-libs/db-4.8.30-r2 set as "read-only" files with permissions like: moneypit ~ # ebuild /usr/portage/sys-libs/db/db-4.8.30-r2.ebuild clean unpack &> /dev/null || echo failed moneypit ~ # ls -l /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/mod_db4/configure -r-xr-xr-x 1 portage portage 97416 Apr 12 2010 /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/mod_db4/configure This is the file that happens to trigger the failure we are seeing. However, that's just a coincidence, if the other configure file created during src_unpack were used, it would have caused the failure as well: moneypit ~ # find /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30 -name 'configure' -exec ls -l {} \; -r-xr-xr-x 1 portage portage 97416 Apr 12 2010 /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/mod_db4/configure -r-xr-xr-x 1 portage portage 719025 Apr 12 2010 /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/dist/configure pretty wierd, I've never seen anything like it all my years of using gentoo... can a tarball simply be packaged with those permissions? Would it be faithfully unpacked by tar as invoked by portage? moneypit ~ # portageq envvar FEATURES assume-digests binpkg-logs buildsyspkg ccache cgroup compressdebug config-protect-if-modified distlocks downgrade-backup ebuild-locks fixlafiles installsources ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch prelink-checksums preserve-libs protect-owned sandbox sfperms sign splitdebug strict suidctl test-fail-continue unknown-features-filter unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr Also, what's up with these files being created in the first place? Can that really be legal? oh... yep: greg@moneypit ~/delme $ ls -l total 0 -rw-r--r-- 1 greg greg 0 Sep 26 17:22 blah greg@moneypit ~/delme $ chmod u-w blah greg@moneypit ~/delme $ ls -l total 0 -r--r--r-- 1 greg greg 0 Sep 26 17:22 blah greg@moneypit ~/delme $ echo blah >> blah bash: blah: Permission denied greg@moneypit ~/delme $ rm blah rm: remove write-protected regular empty file ‘blah’? y greg@moneypit ~/delme $ ls -l total 0 forgot this was possible -- a regular user can indeed create a removable, but not otherwise manipulable file for himself. One more test then: greg@moneypit ~/delme $ tar -xzpf /usr/portage/distfiles/db-4.8.30.tar.gz >/dev/null || echo failed greg@moneypit ~/delme $ ls -l db-4.8.30/mod_db4/ total 184 -r--r--r-- 1 greg greg 1755 Apr 12 2010 ABOUT -r--r--r-- 1 greg greg 1483 Apr 12 2010 BSD -r--r--r-- 1 greg greg 570 Apr 12 2010 config.h.in -r-xr-xr-x 1 greg greg 97416 Apr 12 2010 configure -r--r--r-- 1 greg greg 2737 Apr 12 2010 configure.in -r--r--r-- 1 greg greg 408 Apr 12 2010 INSTALL -r--r--r-- 1 greg greg 596 Apr 12 2010 Makefile.in -r--r--r-- 1 greg greg 2929 Apr 12 2010 mm_hash.c -r--r--r-- 1 greg greg 1089 Apr 12 2010 mm_hash.h -r--r--r-- 1 greg greg 3149 Apr 12 2010 mod_db4.c -r--r--r-- 1 greg greg 552 Apr 12 2010 mod_db4_export.h -r--r--r-- 1 greg greg 2417 Apr 12 2010 sem_utils.c -r--r--r-- 1 greg greg 652 Apr 12 2010 sem_utils.h -r--r--r-- 1 greg greg 14817 Apr 12 2010 skiplist.c -r--r--r-- 1 greg greg 3023 Apr 12 2010 skiplist.h -r--r--r-- 1 greg greg 14989 Apr 12 2010 utils.c -r--r--r-- 1 greg greg 716 Apr 12 2010 utils.h indeed, it seems, if we ask tar to preserve permissions, those are the permissions in the tarball... WTF?
So... just to finish the above thought... We might fix this several ways: * add code to src_unpack to remove the configure scripts * add code to src_prepare to fix the permissions in the tarball * ask upstream what is up with those permissions in their tarball, and attempt to get them to fix them * modify autotools eclass to make sure configure scripts have u+w perm * change portage not to invoke tar in such a way as to create these u-w files I am not sure which is the most appropriate
What I find particularly vexing is that I very recently did an emerge -e @world and everything was fine. Seeking to isolate just problems due to gold I: * updated my portage rsync tree and fixed any issues until I could successfully emerge -e @world (about two days ago) * used binutils-config to select the gold linker * implemented work-arounds for the various bugs in the gold-bug tracker (mostly package.env hacks) * enabled the llvm gold use-flag * re-emerged world After the first time, I never re-synched my portage tree. Anyhow, the last time github:gentoo/gentoo showed any changes to the sys-libs/db folder was September 2nd, well before I successfully emerged @world, just a couple of days ago. So, tricking along with another @world re-emerge, I found sys-libs/db is suffering from some sort of gold incompatibility that is not manifested as an open bug in bgo. OK, I figured, for now, I'll do this: * added "sys-libs/db use-bfd.ld" to /etc/portage/package.env Which just does: LDFLAGS="${LDFLAGS} -Wl,-fuse-ld=bfd" It's very hard for me to imagine how the above change led to exposing this problem. I guess it's not terribly important however, one can drive oneself crazy worrying about such things.
Please include emerge --info too.
(In reply to Michael Palimaka (kensington) from comment #4) > Please include emerge --info too. http://pastebin.com/mbMLMkBP
(In reply to Serge Gavrilov from comment #5) never use pastebin here. attach the files/output.
Created attachment 413208 [details] emerge --info
(In reply to Gregory Turner from comment #2) there is no need to modify either the ebuild or the eclass. portage already does this for us: /usr/lib/portage/python2.7/phase-helpers.sh: unpack() { ... find . -mindepth 1 -maxdepth 1 ! -type l -print0 | \ ${XARGS} -0 chmod -fR a+rX,u+w,g-w,o-w } and indeed, if you look at the unpacked files: $ tar tvvf /usr/portage/distfiles/db-4.8.30.tar.gz | grep configure$ -r-xr-xr-x cupsys/users 719025 2010-04-12 16:25 db-4.8.30/dist/configure -r-xr-xr-x cupsys/users 97416 2010-04-12 16:25 db-4.8.30/mod_db4/configure $ ebuild db-4.8.30-r2.ebuild clean unpack $ ls -l /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/dist/configure -rwxr-xr-x 1 vapier users 719025 Apr 12 2010 /var/tmp/portage/sys-libs/db-4.8.30-r2/work/db-4.8.30/dist/configure if that file isn't u+w on your system, you should figure out where it's going wrong. you can pass the --debug flag to emerge or ebuild to get a full shell trace of the commands executed.
I am seeing the same problem on amd64-fbsd. The reason seems to be that ebuild-helpers.sh "find . -mindepth 1 '!' -type l '!' -perm /a+rX,u+w,g-w,o-w" does not return any results. One problem here is that the find construct appears to be non-portable and fails with BSD find (I filed bug 561886 about it). Another issue is that even when substituting gfind, it comes up empty. So likely a portage problem, not a sys-libs/db one. bsdhorst work # gfind . -mindepth 1 '!' -type l '!' -perm /a+rX,u+w,g-w,o-w bsdhorst work # stat db-4.8.30/dist/configure 1074766590 21005 -r-xr-xr-x 1 portage portage 4294967295 719039 "Sep 30 09:31:12 2015" "Sep 30 09:31:12 2015" "Sep 30 09:31:12 2015" "Sep 30 09:31:12 2015" 131072 1541 0x800 db-4.8.30/dist/configure
The change that triggers this has been reverted (see bug 561368). *** This bug has been marked as a duplicate of bug 561368 ***
(In reply to Zac Medico from comment #10) > The change that triggers this has been reverted (see bug 561368). > > *** This bug has been marked as a duplicate of bug 561368 *** I hit this bug too. I followed the link to bug 561368 and the links inside bug 561368. But I could not find any solution to avoid the bug. Is there not any patch?
(In reply to Juergen Rose from comment #11) > (In reply to Zac Medico from comment #10) > > The change that triggers this has been reverted (see bug 561368). > > > > *** This bug has been marked as a duplicate of bug 561368 *** > > I hit this bug too. I followed the link to bug 561368 and the links inside > bug 561368. But I could not find any solution to avoid the bug. Is there not > any patch? Here's the patch: https://github.com/gentoo/portage/commit/24779b15daef7101111c12de2dd6a6a5c3e374d4.patch Create a directory name /etc/portage/patches/sys-apps/portage-2.2.22/ and save the patch there.
