User Details
- User Since
- Jan 29 2021, 9:30 PM (187 w, 1 d)
- Availability
- Available
Mar 23 2024
Thanks, that patch works for me.
Mar 18 2024
Thank you!
Mar 14 2024
Mar 7 2024
I should say: I can ship a snapshot in Gentoo if that's okay, but I'd prefer not to.
Mar 4 2024
Thank you!
Feb 29 2024
@gniibe Thank you very much! That works.
No, thank you both for the speedy responses :)
Ah, thanks Werner, I'll keep that in mind.
This seems to have regressed musl support, per https://bugs.gentoo.org/925443.
Feb 28 2024
Feb 27 2024
Feb 20 2024
It seems to pass for me with gnupg-2.2.41 but fails with gnupg-2.2.42?
Feb 15 2024
Per https://dev.gnupg.org/rG04cbc3074aa98660b513a80f623a7e9f0702c7c9#83517, it looks like the fix might be incomplete?
Dec 22 2023
Dec 15 2023
Oct 28 2023
I did this locally:
--- a/lang/python/tests/support.py +++ b/lang/python/tests/support.py @@ -46,13 +46,15 @@ def is_gpg_version(version):
Sep 1 2023
Thanks. For the record, done at https://lists.gnupg.org/pipermail/gnupg-users/2023-August/066692.html.
Aug 21 2023
I'll swap us over to out of source build for this as well. I've been doing it gradually for the gpg suite. Thanks.
Jul 6 2023
Thanks. Wouldn't that require OpenLDAP on every system with gnupg?
Jul 4 2023
Jun 10 2023
Ah, I see https://dev.gnupg.org/rG2f872fa68c6576724b9dabee9fb0844266f55d0d applies cleanly. I guess can go with that, although would prefer it if on the 2.4 branch.
Is there a commit we could backport downstream to 2.4.x? We've had quite a few reports of this.
Dec 20 2022
Sorry, one more thing: I should use out of source builds for all gnupg software (libgpg-error, libksba, etc)? It's fine if so, just want to check what the policy is.
Ah, thanks! I didn't know this was unsupported. I'll change what we're doing.
Sep 9 2022
Thanks for your help @gniibe and apologies for wasting your time. It looks like this is an issue with ncurses on musl systems and I'll pursue it there. I have a patch to their configure which works & fixes building pinentry.
I've reported it on bug-ncurses@ to get some insight: https://marc.info/?l=ncurses-bug&m=166268018624805&w=2.
Mysteriously, I get nothing:
$ pkg-config --cflags nurses
Sep 8 2022
It looks like there was a problem similar to this a while ago: https://dev.gnupg.org/T2320 where it turned out for unicode ncurses builds, a specific header had to be included, but that workaround seems to have been removed from pinentry since.
Aug 25 2022
That's a fair point, cheers!
Jun 15 2022
Thanks! Interestingly didn't seem to work with 1.9.x but it does with 1.10x. Maybe I made some error when testing.
May 14 2022
Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.
May 13 2022
Thank you for your fast reply. My apologies - I should have thought to do that (share log with asm enabled)! But now I'm confused. I think the failure was only ever with asm disabled. I will check with somebody else tomorrow just to make sure though.
May 12 2022
Full build.log:
. Happy to get more information if you tell us what's needed. Hardware access can be given over SSH too.Apr 27 2022
Apr 25 2022
After re-running myself a few times, I managed to hit it again. In tests/openpgp/report.xml, I see:
[...] <testsuite name="<keyboxd>tests/openpgp/use-exact-key.scm" time="0" package="<keyboxd>tests/openpgp" id="0" timestamp="2022-04-25T16:18:27" hostname="unknown" tests="1" failures="0" errors="0" > <properties/> <testcase name="use-exact-key.scm" classname="<keyboxd>tests.openpgp" time="0" > <failure message="Unknown error." /> </testcase> <system-out> Importing public key. Checking that the most recent, valid signing subkey is used by default > 8BC90111 3E880CFF F5F77B83 45117079 1EA97479 < Checking that we can select a specific signing key > 8BC90111 F5F77B83 1EA97479 < </system-out> <system-err> </system-err> [...]
Feb 17 2022
Yeah, please do issue a new release as soon as possible if you can, as otherwise downstream we're in an awkward position where we have to rebuild everything without a SONAME bump, then do it again once the release is out.
Feb 15 2022
Feb 14 2022
Jan 22 2022
Jan 17 2022
On behalf of @gyakovlev (pending approval for his account):
[03:05:23] <@gyakovlev> AC_DEFINE(HAVE_COMPATIBLE_CC_PPC_ALTIVEC,1, [03:05:23] <@gyakovlev> [Defined if underlying compiler supports PowerPC AltiVec/VSX/crypto intrinsics]) [03:05:34] <@gyakovlev> they should definitely check for __POWER8_VECTOR__ 1 [03:05:44] <@gyakovlev> it's not plain altivec [03:06:52] <@gyakovlev> that power check should check for __POWER8_VECTOR__ [03:06:52] <@gyakovlev> not only for what they check already. [03:08:59] <@gyakovlev> it probably should be checked after __powerpc64__ or instead of it.
Looks like it's triggered if e.g. -mcpu=power9 isn't in CFLAGS.
Build log here:
Oct 29 2021
Jan 30 2021
@jukivili Thanks for the reply! We've reverted that commit downstream in Gentoo as a temporary workaround, as due to some complications, our release systems needed to build without asm (for now) to ensure portability. Rest assured, this is not the default, and is discouraged for regular users.