"ikloecker (Ingo Klöcker)" wrote:

ikloecker added a comment.

How is "invalid DISPLAY" defined? `DISPLAY=invalid`? Anything that's not `DISPLAY=:<some number>`? Why do screen and tmux have to use an extra-wurst?

[...]

In T8156#216401, @ikloecker wrote:

I'm not sure if we should consider env DISPLAY=invalid pinentry-qt a valid test.

[...]

So, I guess, @ametzler1's suggestion to remove the check for isX11SessionType is the correct solution. DISPLAY=invalid would still not work, but I think that's acceptable.

Afaict neither QT nor FLTK offer an equivalent to gtk-2's gtk_init_check() so there is no trivial change to get the same functionality.

CVE-2026-24882 has been assigned to this issue.

Some data points:
The latest version of the standard (issue 8) has "The -a and -o binary primaries and the '(' and ')' operators have been removed." instead of "obsoleted" https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.html

Thanks for fixing this.

Hello,
thank you all. I can confirm that 1.11.2 builds successfully on ppc64el with gcc-15 (Debian sid + experimental). Lacking access I have not be able to check alpha. I would suggest closing this report as fixed.
cu Andreas

In T7721#203182, @gniibe wrote:

For PowerISA 3.00 Instructions issue, following patch may help:

diff --git a/configure.ac b/configure.ac
index 6cc1e189..70d632af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2448,10 +2448,11 @@ AC_CACHE_CHECK([whether GCC inline assembler supports PowerISA 3.00 instructions
         else
           gcry_cv_gcc_inline_asm_ppc_arch_3_00=no
           AC_LINK_IFELSE([AC_LANG_PROGRAM(
-          [[__asm__(".text\n\t"
+          [[__asm__(".machine        \"any\"\n"
+                    ".text\n\t"
                     ".globl testfn;\n"
                     "testfn:\n"
-                    "stxvb16x %r1,%v12,%v30;\n"
+                    "stxvb16x 47,0,9;\n"
                   );
             void testfn(void);
             ]], [ testfn(); ])],

I figured out that .machine "any" is needed with GCC 15.

The powerpc64le issue (undefined reference to `gcry_poly1305_p10le_4blocks') also applies to GIT master.

In T7721#202963, @werner wrote:

Sure that this is about 1.11.0 ? We released 1.11.1 with at least one fix for gcc regression (T7166). In master we had some more fixes for gcc 15 bugs (or what ever you will call such regression in a compiler)

works for me, thanks

Good morning,
I stumbled upon this when digging through old Debian bug reports against 1.4 and checking whether they still applied to 2.4. This one really still applies.

This is still broken on 2.5.5.

this marked as fixed in 2.4.7. However afaict only one of the two patches made it to STABLE-BRANCH-2-4, b1857a2836c9a91ef4e359ef7ba949b54c77219d did not.

Taking a bigger sample of keys from the same domain and doing the same testing shows that the signature by B0D589D46708EC99 is removed on all keys.

Thank you Daniel for forwarding this. To get the attribution right: I did not find the issue, Todd Zullinger reported it on https://lists.gnupg.org/pipermail/gnupg-devel/2024-October/035661.html

Werner wrote:

We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility.

Hello,
I have a hard time to agree that is the right thing for gnupg to throw an error if it successfully imported a revocation certificate for an expired key. This is a meaningful (and not useless) change even if the key is expired.

In T7226#189443, @jukivili wrote:

This patch should fix the issue:

0001-mpi-ec-inline-reduce-register-pressure-on-32-bit-ARM.patch4 KBDownload

This already shows with 9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which initially added ec-inline.h. (Reproducing with old versions like this one requires cherry-picking 693ffa145378682229473b0e811a9cea7c4d307a since otherwise NEON support is disabled at configure time due to implicit functions.)

Any chance this could also be fixed in the 2.2.x series, where it seems to have been introduced in 2.2.42?

Ditto for ksba and assuan.

The gcrypt change works for me. Thanks!

Just to clarify: I personally think it would be perfectly fine to say that AM_PATH_* is only supported when AM_PATH_GPG_ERROR is also used. Adding an invocation AM_PATH_GPG_ERROR is not a great hassle and alternatively pkg-config/pkgconf exists and works perfectly fine (and is a lot faster).

Hello Werner,
the above is an excerpt from the exim log, I do not think the full bounce is more enlightening, vsrv21575.customer.vlinux.de got 550 from ellsberg.gnupg.com after " MAIL FROM:<ametzler@bebt.de>":

The mail server is misconfigured. no SPF <> not allowed.

Sorry for the fallout and thank you for taking care of it.

In T6309#166019, @ametzler1 wrote:

Missed some, will post an updated patch.

Missed some, will post an updated patch.

In T6285#165459, @gniibe wrote:

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Something like this?

In T6288#165435, @werner wrote:

Bootstrapping is an issue. Recall that pkg-config is not a simple program but requires the use of glib (which depends on libffi, libmount, libpcre) - catch-22. Makes building GnuPG on AIX not actually easy.

FWIW I would vote for a) "document gpgrt-config in detail" and suggest using pkg-config (variant) for direct invokations. There seems to be little benefit in investing effort/complicating gpgrt-config when pkg-config works fine.

thank you, works for me.

Thank you, looks good to me.

@gniibe - Thanks for the quick response. It now works for me.
cu Andreas

the pushed fix breaks when libgpg-error does not require special CFLAGS, i.e. when @GPG_ERROR_CFLAGS@ expands to an empty string:

bernhard added a comment.Mon, Sep 5, 6:05 PM

If it is was broken for you and works now, let us know here.
if "lists." still is there in email addresses somewhere, please also list.

In T5816#154715, @ikloecker wrote:

Try gcrypt-devel@gnupg.org, i.e. without the lists subdomain.

Recently, the gnupg.org mailing list manager started to prepend the lists. subdomain to the List-Id (which caused my email filters to fail) and to everything else. Probably due to an accidentally changed configuration.

This works for me:

This bug has been assigned CVE-2019-12904. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904

gniibe wrote: