PASS: <standard>tests/openpgp/quick-key-manipulation.scm PASS: <standard>tests/openpgp/4gb-packet.scm =================== 183 tests run, 182 succeeded, 1 failed, 0 failed expectedly, 0 succeeded unexpectedly, 0 skipped. Failed tests: <keyboxd>tests/openpgp/use-exact-key.scm =================== make[2]: *** [Makefile:931: xcheck] Error 1 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop-j4_test-20220420-221025 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-12.0.1 * clang/llvm (if any): clang version 14.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/14/bin /usr/lib/llvm/14 14.0.1 Python 3.9.12 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby27 (with Rubygems) [3] ruby31 (with Rubygems) * Available Rust versions: [1] rust-bin-1.60.0 [2] rust-1.60.0 * The following VMs are available for generation-2: *) Eclipse Temurin JDK 11.0.14_p9 [openjdk-bin-11] 2) Eclipse Temurin JDK 8.322_p06 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-11 system-vm The Glorious Glasgow Haskell Compilation System, version 8.10.4 php cli: [1] php7.4 [2] php8.0 [3] php8.1 * HEAD of ::gentoo commit a46e376aa10758c6e9e2da2f330794220b7f1cef Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sat Apr 23 22:04:23 2022 +0000 2022-04-23 22:04:23 UTC emerge -qpvO app-crypt/gnupg [ebuild U ] app-crypt/gnupg-2.3.5-r1 [2.3.5] USE="bzip2 nls readline smartcard ssl test tofu usb -doc -ldap (-selinux) -tools -tpm -user-socket -verify-sig -wks-server"
Created attachment 773830 [details] emerge-info.txt
Created attachment 773833 [details] app-crypt:gnupg-2.3.5-r1:20220423-221033.log.bz2
Created attachment 773836 [details] emerge-history.txt
Created attachment 773839 [details] environment
Created attachment 773842 [details] etc.portage.tar.bz2
Created attachment 773845 [details] logs.tar.bz2
Created attachment 773848 [details] temp.tar.bz2
The file size of ./files/tests.tar.bz2 is too big (1.1M) for an upload. For about 8 weeks the link http://tinderbox.zwiebeltoralf.de:31560/17.1_desktop-j4_test-20220420-221025/var/tmp/tb/issues/20220424-001201-app-crypt_gnupg-2.3.5-r1/files/tests.tar.bz2 is valid.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3a897380659705845cd60c7665ad4f55c28c4812 commit 3a897380659705845cd60c7665ad4f55c28c4812 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-04-25 16:05:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-04-25 16:05:54 +0000 app-crypt/gnupg: add 2.3.6 Same flaky test failure. Bug: https://bugs.gentoo.org/840511 Bug: https://bugs.gentoo.org/840746 Signed-off-by: Sam James <sam@gentoo.org> app-crypt/gnupg/Manifest | 2 + app-crypt/gnupg/gnupg-2.3.6.ebuild | 161 +++++++++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+)
*** Bug 840815 has been marked as a duplicate of this bug. ***
@Toralf this bug is weird, because it never was possible to reach testing stage: in the ebuild is a patch non existing: "${FILESDIR}"/${P}-fix-buffering-hang.patch I thought I got my gentoo repo broken, so I had a look into: 1. the above patch is mentioned here: https://data.gpo.zugaina.org/gentoo/app-crypt/gnupg/gnupg-2.3.5-r2.ebuild 2. but the above patch is not found here: https://data.gpo.zugaina.org/gentoo/app-crypt/gnupg/files/ How this failing ebuild can reach a state: ... "fails test - Failed tests:" ...
And yes - the revision -r1 also required the non existing patch.
(In reply to Ulenrich from comment #12) > And yes - the revision -r1 also required the non existing patch. You're confused. See https://gitweb.gentoo.org/repo/gentoo.git/commit/app-crypt/gnupg?id=e67bb84b2c008c569b7e1113260b3ca029b266bb and https://gitweb.gentoo.org/repo/gentoo.git/commit/app-crypt/gnupg?id=e6d5dc95e4eb2e7282b0faeb7908569cb2103134. The patch was in tree but only there for a few minutes because a release was made upstream.
@Sam - I am confused: Why does emerge try to patch with non existing patch file? --- >>> Emerging (1 of 1) app-crypt/gnupg-2.3.5-r2::gentoo >>> Failed to emerge app-crypt/gnupg-2.3.5-r2, Log file: >>> '/var/log/portage/build/app-crypt/gnupg-2.3.5-r2:20220501-205902.log' >>> Jobs: 0 of 1 complete, 1 failed Load avg: 1.08, 0.80, 0.68 * Package: app-crypt/gnupg-2.3.5-r2 * Repository: gentoo * Maintainer: zlogene@gentoo.org base-system@gentoo.org * USE: abi_x86_64 amd64 bzip2 doc elibc_glibc kernel_linux nls readline ssl tofu tools userland_GNU verify-sig wks-server * FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox >>> Unpacking source... * Verifying gnupg-2.3.5.tar.bz2 ... gpg: Signature made Do 21 Apr 2022 17:41:52 CEST gpg: using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA gpg: Good signature from "Werner Koch (dist signing 2020)" [ultimate] >>> Unpacking gnupg-2.3.5.tar.bz2 to /tmp/portage/app-crypt/gnupg-2.3.5-r2/work >>> Unpacking gnupg-2.3.5.tar.bz2.sig to /tmp/portage/app-crypt/gnupg-2.3.5-r2/work unpack gnupg-2.3.5.tar.bz2.sig: file format not recognized. Ignoring. >>> Source unpacked in /tmp/portage/app-crypt/gnupg-2.3.5-r2/work >>> Preparing source in /tmp/portage/app-crypt/gnupg-2.3.5-r2/work/gnupg-2.3.5 ... * Applying gnupg-2.1.20-gpgscm-Use-shorter-socket-path-lengts-to-improve-tes.patch ... [ ok ] * Applying gnupg-2.3.5-fix-buffering-hang.patch ... /tmp/portage/app-crypt/gnupg-2.3.5-r2/temp/environment: line 716: /tmp/portage/app-crypt/gnupg-2.3.5-r2/files/gnupg-2.3.5-fix-buffering-hang.patch: No such file or directory /tmp/portage/app-crypt/gnupg-2.3.5-r2/temp/environment: line 719: /tmp/portage/app-crypt/gnupg-2.3.5-r2/files/gnupg-2.3.5-fix-buffering-hang.patch: No such file or directory [ !! ] * ERROR: app-crypt/gnupg-2.3.5-r2::gentoo failed (prepare phase): * patch -p1 failed with /tmp/portage/app-crypt/gnupg-2.3.5-r2/files/gnupg-2.3.5-fix-buffering-hang.patch * * Call stack: * ebuild.sh, line 127: Called src_prepare * environment, line 1722: Called default * phase-functions.sh, line 858: Called default_src_prepare * phase-functions.sh, line 923: Called __eapi6_src_prepare * environment, line 244: Called eapply '/tmp/portage/app-crypt/gnupg-2.3.5-r2/files/gnupg-2.1.20-gpgscm-Use-shorter-socket-path-lengts-to-improve-tes.patch' '/tmp/portage/app-crypt/gnupg-2.3.5-r2/files/gnupg-2.3.5-fix-buffering-hang.patch' * environment, line 784: Called _eapply_patch '/tmp/portage/app-crypt/gnupg-2.3.5-r2/files/gnupg-2.3.5-fix-buffering-hang.patch' * environment, line 722: Called __helpers_die 'patch -p1 failed with /tmp/portage/app-crypt/gnupg-2.3.5-r2/files/gnupg-2.3.5-fix-buffering-hang.patch' * isolated-functions.sh, line 112: Called die * The specific snippet of code: * die "$@" ---
(In reply to Ulenrich from comment #14) > @Sam - I am confused: > Why does emerge try to patch with non existing patch file? > --- > >>> Emerging (1 of 1) app-crypt/gnupg-2.3.5-r2::gentoo Now I see -- you're trying -r2, but I already cleaned up the patch since. Just try 2.3.6, it has the same problem (which is reported upstream)?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5fa2de42bd4a2a9a6006e73610d8cf32dc6aaf36 commit 5fa2de42bd4a2a9a6006e73610d8cf32dc6aaf36 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-05-01 21:03:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-01 21:26:13 +0000 app-crypt/gnupg: drop 2.3.5-r2 Bug: https://bugs.gentoo.org/840511 Signed-off-by: Sam James <sam@gentoo.org> app-crypt/gnupg/Manifest | 2 - app-crypt/gnupg/gnupg-2.3.5-r2.ebuild | 162 ---------------------------------- 2 files changed, 164 deletions(-)
Yes app-crypt/gnupg-2.3.6 emerges fine and runs fine. So, the not merging app-crypt/gnupg-2.3.5-r2 I would remove from the repo. Simple, because an unstable version. My question (since this issue was since -r1): How could Toralfs testing case fail, when the ebuild failed before?
(In reply to Ulenrich from comment #17) > Yes app-crypt/gnupg-2.3.6 emerges fine and runs fine. > So, > the not merging app-crypt/gnupg-2.3.5-r2 > I would remove from the repo. Simple, because an unstable version. Yep, it's gone. > > My question (since this issue was since -r1): > How could Toralfs testing case fail, when the ebuild failed before? Because he tested -r1 when the patch was still in tree. 2.3.6 has the same issue. See the upstream bug.
