Created attachment 339270 [details] output of emerge --info When updating dev-libs/cyrus-sasl-2.1.25-r4 when logged in via ssh I get this error: Emerging (2 of 10) dev-libs/cyrus-sasl-2.1.25-r4 * cyrus-sasl-2.1.25.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking cyrus-sasl-2.1.25.tar.gz to /var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work gzip: stdout: Broken pipe * ERROR: dev-libs/cyrus-sasl-2.1.25-r4 failed (unpack phase): * failure unpacking cyrus-sasl-2.1.25.tar.gz * * Call stack: * ebuild.sh, line 93: Called src_unpack * environment, line 5152: Called __eapi0_src_unpack * phase-helpers.sh, line 575: Called unpack 'cyrus-sasl-2.1.25.tar.gz' * phase-helpers.sh, line 339: Called __unpack_tar 'gzip -d' * phase-helpers.sh, line 312: Called __assert_sigpipe_ok 'failure unpacking cyrus-sasl-2.1.25.tar.gz' * isolated-functions.sh, line 39: Called die * The specific snippet of code: * [[ $x -ne 0 && $x -ne ${PORTAGE_SIGPIPE_STATUS:-141} ]] && die "$@" * * If you need support, post the output of `emerge --info '=dev-libs/cyrus-sasl-2.1.25-r4'`, * the complete build log and the output of `emerge -pqv '=dev-libs/cyrus-sasl-2.1.25-r4'`. !!! When you file a bug report, please include the following information: GENTOO_VM= CLASSPATH="" JAVA_HOME="" JAVACFLAGS="" COMPILER="" and of course, the output of emerge --info * The complete build log is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work' * S: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work/cyrus-sasl-2.1.25' >>> Failed to emerge dev-libs/cyrus-sasl-2.1.25-r4, Log file: >>> '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/build.log' * Messages for package dev-libs/cyrus-sasl-2.1.25-r4: * ERROR: dev-libs/cyrus-sasl-2.1.25-r4 failed (unpack phase): * failure unpacking cyrus-sasl-2.1.25.tar.gz * * Call stack: * ebuild.sh, line 93: Called src_unpack * environment, line 5152: Called __eapi0_src_unpack * phase-helpers.sh, line 575: Called unpack 'cyrus-sasl-2.1.25.tar.gz' * phase-helpers.sh, line 339: Called __unpack_tar 'gzip -d' * phase-helpers.sh, line 312: Called __assert_sigpipe_ok 'failure unpacking cyrus-sasl-2.1.25.tar.gz' * isolated-functions.sh, line 39: Called die * The specific snippet of code: * [[ $x -ne 0 && $x -ne ${PORTAGE_SIGPIPE_STATUS:-141} ]] && die "$@" * * If you need support, post the output of `emerge --info '=dev-libs/cyrus-sasl-2.1.25-r4'`, * the complete build log and the output of `emerge -pqv '=dev-libs/cyrus-sasl-2.1.25-r4'`. * The complete build log is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work' * S: '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/work/cyrus-sasl-2.1.25' * GNU info directory index is up-to-date. * After world updates, it is important to remove obsolete packages with * emerge --depclean. Refer to `man emerge` for more information. When I logged in physically at the machine via konsole, the emerge completed normally. This same problem occurred with the previous stable package of cyrus-sasl (2.1.23-r6), with the same workaround.
Sorry, made a mistake; Version 2.1.23-r6 was the last stable version not affected by this issue for me. Version 2.1.25-r3 was also affected by this issue.
Please attach the environment file (from when you log in through SSH) to this bug report: * The ebuild environment file is located at '/var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/environment'.
That's a strange problem. Maybe it helps if you run it inside of a session of app-misc/screen or app-misc/tmux?
What versions of tar and gzip do you have? Have you tried to rebuild them? Maybe rebuild bash too.
Created attachment 339508 [details] Environment file
Rebuilding tar, gzip and bash didn't help. Running the emerge in screen also didn't help. Thanks
Version info: app-arch/tar-1.26 app-arch/gzip-1.5 (Sorry for multiple posts, can't see how to edit one)
It looks a lot like bug 309001 and bug 252680, but those are supposed to be handled by __assert_sigpipe_ok. Please reproduce the problem with --debug and attach a log created as follows: emerge --oneshot --pretend --debug cyrus-sas > debug.log 2>&1 xz -9 debug.log
Created attachment 339510 [details] Debug log
Actually, please create the debug log without --pretend. We actually need to see the build failure in the log. Sorry.
Created attachment 339512 [details] New debug.log
For the failure, we have 'pipestatus=1 0' inside __assert_sigpipe_ok. Normally it's 'pipestatus=141 0' due to the SIGPIPE. So, apparently something is causing gzip to handle the SIGPIPE differently. Portage already tries to reset the SIGPIPE handler before exec, with this code: signal.signal(signal.SIGPIPE, signal.SIG_DFL) I don't know what else we can do.
(In reply to comment #5) > Created attachment 339508 [details] > Environment file Is this the environment from a failed build when logged in via ssh? You should compare it the environment when you're logged on locally. You can get /var/tmp/portage/dev-libs/cyrus-sasl-2.1.25-r4/temp/environment after running this command: ebuild /usr/portage/dev-libs/cyrus-sasl/cyrus-sasl-2.1.25-r4.ebuild unpack Is there anything special about your ssh configuration?
There are files with '#' (and '~') in their name in cyrus-sasl; is it possible that these rather uncommon filenames causes this bug?
(In reply to comment #14) > There are files with '#' (and '~') in their name in cyrus-sasl; is it > possible that these rather uncommon filenames causes this bug? File names should not matter, since the problem is with the gzip exit code as described in comment #12, and gzip does not know anything about file names (only tar handles the file names).
I thought so, too. But I re-compressed the tar file as bzip2 and the bug persisted. After untaring, deleting those files and then making a new .tar.bz2-file from it it worked.
(In reply to comment #16) That's because your new tar file doesn't trigger the case where tar closes the pipe and triggers SIGPIPE for the decompressor (see bug 309001).
I get this error even if I log in locally as a user and then switch to root with 'su -'. I have to log in as root directly then it passes.
Me too: I get this error even if I log in locally as a user and then switch to root with 'su -'. I have to log in as root directly to get this package to build.
I have the same problem with 2.1.26-r3 when logged in as a user and running su to become root. When logged in as root, everything works.
I suspect that this bug (which I now have) is related to a previous bug I reported: https://bugs.gentoo.org/show_bug.cgi?id=490310 I also still have that "WORKSFORME" bug because it doesn't work for me :-) Oddly enough, just as xterm works fine without throwing the bzip2 errors as in bug 490310, xterm also works fine for emerging cyrus-sasl. It's only when I'm in konsole that I see both bugs.
Perhaps the way how the cyrus-sasl tarball is extracted should be changed in the ebuild. While remotely connected, untaring it I get: $ tar xf /usr/portage/distfiles/cyrus-sasl-2.1.26.tar.gz gzip: stdout: Broken pipe tar: Child returned status 1 tar: Error is not recoverable: exiting now I am, however able to successfully unpack it with gunzip and tar separately: $ gunzip /usr/portage/distfiles/cyrus-sasl-2.1.26.tar.gz $ tar xf /usr/portage/distfiles/cyrus-sasl-2.1.26.tar [no error] Actually, after repacking it with tar czf ... (and updating digest) the emerge finished successfully. It is in contradiction with comments #14+#16, I know, strange. Also I did not found any files with ~ or # in the cyrus-sasl-2.1.26.tar.gz.
I know this bug is half-a-year-old, but I was hit by the exact one recently (emerging dev-lang/erlang, but the very exact symptoms). The cause was overoptimized gzip and/or tar. I have ~amd64 system with _very_ aggressive optimizations: CFLAGS_GRAPHITE="-floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block" CFLAGS_LTO="-flto=8 -ftree-vectorize" CFLAGS="-O3 -ggdb -pipe -march=core-avx2 ${CFLAGS_GRAPHITE}" CXXFLAGS="${CFLAGS}" LDFLAGS="${CFLAGS_GRAPHITE} -fuse-linker-plugin" (LTO is enabled via package.env) This ended with "Called __assert_sigpipe_ok 'failure unpacking ...' " for some (not all) packages, to take erlang-17 as a notable example. When I downoptimized tar and gzip to classic CFLAGS="-O2 -ggdb -pipe -march=native" CXXFLAGS="${CFLAGS}" emerge went smoothly.
*** Bug 511466 has been marked as a duplicate of this bug. ***
