User Details
- User Since
- Jan 29 2021, 9:30 PM (139 w, 3 d)
- Availability
- Available
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.