| Summary: | app-crypt/gnupg-2.3.5-r1 fails test - Failed tests: <keyboxd>tests/openpgp/use-exact-key.scm | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | base-system |
| Priority: | Normal | Keywords: | TESTFAILURE |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://dev.gnupg.org/T5948 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge-info.txt
app-crypt:gnupg-2.3.5-r1:20220423-221033.log.bz2 emerge-history.txt environment etc.portage.tar.bz2 logs.tar.bz2 temp.tar.bz2 |
||
|
Description
Toralf Förster
2022-04-24 07:01:57 UTC
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. |
