Bug#1081192: libllvm19: declares itself as MA: same but is not co-installable

[Simon McVittie]

Control: reopen 1081192
Control: found 1081192 1:19.1.0-3
Control: affects -1 + src:mesa

On Mon, 09 Sep 2024 at 09:57:01 +, Debian Bug Tracking System wrote:
> #1081192: libllvm19: declares itself as MA: same but is not co-installable
> [...] has been closed

This bug is still present in unstable (or, perhaps, present again in
unstable):

Unpacking libllvm19:amd64 (1:19.1.0-3) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-2k1zjW/03-libllvm19_1%3a19.1.0-3_amd64.deb (--unpack):
 trying to overwrite shared '/usr/lib/llvm-19/lib/libLLVM.so.19.1', which 
is different from other instances of package libllvm19:amd64

$ dpkg -L libllvm19:i386
...
/usr/lib/llvm-19/lib/libLLVM.so.19.1

Please test multiarch co-installability whenever this package is
restructured: as Sebastian said, this is important for a common use-case
of libllvm. On typical x86 machines, an easy way to do this is to have
the amd64 and i386 flavours co-installed, or if test-building for both
architectures takes a prohibitively long time, upload to experimental
after any restructuring of the package's contents and check that the
amd64 and i386 flavours from experimental are still co-installable before
re-uploading to unstable.

cc Mesa maintainers: similarly, please check for amd64/i386
co-installability before updating Mesa in unstable to a new version
of LLVM.

Thanks,
smcv

Bug#1082284: libunwind: FTBFS on arm64: expected 'unw_tdep_context_t *' but argument is of type 'ucontext_t *'

[Simon McVittie]

Source: libunwind
Version: 1.7.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: arm64
X-Debbugs-Cc: debian-...@lists.debian.org

Vaguely similar to the i386 build failure in the same version that I
reported separately:

https://buildd.debian.org/status/fetch.php?pkg=libunwind&arch=arm64&ver=1.7.2-1&stamp=1726720968&raw=0
> In file included from aarch64/Linit.c:4:
> aarch64/Ginit.c: In function 'access_reg':
> aarch64/Ginit.c:373:28: error: initialization of 'unw_tdep_context_t *' from 
> incompatible pointer type 'ucontext_t *' [-Wincompatible-pointer-types]
>   373 |   unw_tdep_context_t *uc = ((struct cursor *)arg)->uc;
>   |^
> aarch64/Ginit.c: In function 'access_fpreg':
> aarch64/Ginit.c:402:28: error: initialization of 'unw_tdep_context_t *' from 
> incompatible pointer type 'ucontext_t *' [-Wincompatible-pointer-types]
>   402 |   unw_tdep_context_t *uc = ((struct cursor *)arg)->uc;
>   |^

(There are many more errors involving `unw_tdep_context_t *` and
`ucontext_t *` not being interchangeable, I only quoted the first
two here.)

Thanks,
smcv

Bug#1082282: libunwind: FTBFS on i386: passing argument 1 of '_Ux86_sigreturn' from incompatible pointer type

[Simon McVittie]

Source: libunwind
Version: 1.7.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: i386

https://buildd.debian.org/status/fetch.php?pkg=libunwind&arch=i386&ver=1.7.2-1&stamp=1726720970&raw=0
> x86/Gos-linux.c: In function '_Ux86_local_resume':
> x86/Gos-linux.c:302:22: error: passing argument 1 of '_Ux86_sigreturn' from 
> incompatible pointer type [-Wincompatible-pointer-types]
>   302 |   x86_sigreturn (sc);
>   |  ^~
>   |  |
>   |  struct sigcontext *
> In file included from x86/Gos-linux.c:26:
> x86/unwind_i.h:64:42: note: expected 'unw_cursor_t *' {aka 'struct unw_cursor 
> *'} but argument is of type 'struct sigcontext *'
>64 | extern void x86_sigreturn (unw_cursor_t *cursor);
>   |~~^~

Possibly related to pre-existing bug #994510, which is also about uses
of struct sigcontext on i386.

I notice that many of the packages that link to libunwind on my system
seem to be using it as a nice-to-have feature to try to show backtraces
if they crash (on architectures supported by libunwind), rather than as
something that is functionally necessary. Should packages in this situation
be moving away from enabling libunwind on i386?

Thanks,
smcv

Bug#1081803: marked as pending in json-glib

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1081803 in json-glib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/json-glib/-/commit/16571e56ada4a1a8504011be67859f77bc7805f7


Add patches from upstream to restore parsing of single-quoted strings

These are a non-standard extension, therefore are only accepted in the
default non-strict mode, similar to the support for C-style comments.

Closes: #1081803


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1081803

Bug#1081417: gnome-settings-daemon: frequent test failure: timed out waiting for plugin startup: XSettings

[Simon McVittie]

Control: severity -1 wishlist
Control: retitle -1 gnome-settings-daemon: should ideally run additional 
build-time tests
Control: block -1 by 1081437 1081439 1081440
Control: severity 1081437 wishlist
Control: severity 1081439 wishlist
Control: severity 1081440 wishlist

On Fri, 13 Sep 2024 at 15:24:07 -0400, Jeremy Bícha wrote:
> These build tests backed by Mutter have only been enabled starting in
> July. We didn't know that we weren't running them, but we could
> consciously choose not to run them now.

These tests are now disabled. We can (and perhaps should) re-enable them
in future, but only if someone can get them to be reliable enough to make
a good QA gate.

smcv

Bug#1081803: libgdata: test regression with json-glib 1.10.x: assumes single-quoted strings are OK in JSON

[Simon McVittie]

Source: libgdata
Version: 0.051-1
Tags: ftbfs trixie sid
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
X-Debbugs-Cc: json-g...@packages.debian.org
Forwarded: https://gitlab.gnome.org/GNOME/libgdata/-/issues/50
Control: affects -1 src:json-glib

libgdata's autopkgtest regressed with json-glib 1.10.x:

>  60s libgdata:ERROR:../gdata/tests/general.c:2412:test_app_categories: 
> assertion failed (error == NULL): Error parsing JSON: :1:1: Parse 
> error: unexpected character `{', expected string constant 
> (gdata-parser-error-quark, 1)

I think this would also cause a FTBFS from build-time test failures if it
was rebuilt with the new json-glib.

The root cause appears to be that test assuming that json-glib will accept
a JSON-like format with single-quoted strings (these are not part of the
JSON standard), which was true in 1.8.x but not any more. Please see the
upstream bug for more details.

json-glib 1.10.x has a new opt-in strict mode which disallows several
other non-standard extensions (such as comments), but it seems that
single-quoted strings are not accepted even when not in strict mode.

smcv

Bug#1081515: gtk4: FTBFS with weston 14: many tests fail with --setup=wayland: Failed to open display

[Simon McVittie]

Control: tags -1 + patch

On Thu, 12 Sep 2024 at 22:41:10 +0200, Aurelien Jarno wrote:
> Weston 14 is crashing with SIGSEGV a following a few tests like flowbox
> or textiter, despite the test being successful. The following tests
> fails with no display.

The attached patch (proposed upstream by Jan Alexander Steffens) seems to
resolve this: I can build and test gtk4 successfully on amd64 and i386.

Also available as a merge request,
https://salsa.debian.org/xorg-team/wayland/weston/-/merge_requests/11

Thanks,
smcv
From: "Jan Alexander Steffens (heftig)" 
Date: Sat, 14 Sep 2024 06:35:09 +0200
Subject: libweston/noop-renderer: Check shm_buffer for NULL

Copy the check from the pixman renderer.

Bug: https://gitlab.freedesktop.org/wayland/weston/-/issues/953
Signed-off-by: Jan Alexander Steffens (heftig) 
Forwarded: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1614
Bug-Debian: https://bugs.debian.org/1081515
---
 libweston/noop-renderer.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libweston/noop-renderer.c b/libweston/noop-renderer.c
index 06b4aeb..58d0b66 100644
--- a/libweston/noop-renderer.c
+++ b/libweston/noop-renderer.c
@@ -94,6 +94,12 @@ noop_renderer_attach(struct weston_paint_node *pnode)
 	}
 
 	shm_buffer = buffer->shm_buffer;
+	/* This can happen if a SHM wl_buffer gets destroyed before we attach,
+	 * because wayland-server just nukes the wl_shm_buffer from underneath
+	 * us. */
+	if (!shm_buffer)
+		return;
+
 	data = wl_shm_buffer_get_data(shm_buffer);
 	stride = buffer->stride;
 	height = buffer->height;

Bug#1081701: libglib-object-introspection-perl: test regression with g-i 1.81.x: Cannot convert record value of unknown type GIMarshallingTestsPointerStruct to SV

[Simon McVittie]

Control: tags -1 + patch

On Sat, 14 Sep 2024 at 01:24:28 +0100, Simon McVittie wrote:
> libglib-object-introspection-perl's autopkgtests fail when testing against
> gobject-introspection 1.81.x in experimental

Please consider the attached patch, as proposed upstream by a
gobject-introspection maintainer. Also available as a merge request:
https://salsa.debian.org/perl-team/modules/packages/libglib-object-introspection-perl/-/merge_requests/1

It passes tests with the old gobject-introspection (1.80.x in
testing/unstable) and also with the new version (1.81.x in experimental).

I haven't done any manual testing with dependent packages: I don't know
which ones, if any, use this particular pattern.

Thanks,
smcv
From: Emmanuele Bassi 
Date: Sat, 14 Sep 2024 13:09:59 +0100
Subject: Handle pointer types

Now that gobject-introspection pairs G_TYPE_POINTER types with their
type registration function, we need to handle the case in which we are
passed a pointer to a record that inherits from G_TYPE_POINTER. Since
these types are basically plain pointers, we can reuse the sv_to_struct
and struct_to_sv functions we use for untyped structures.

Bug: https://gitlab.gnome.org/GNOME/perl-glib-object-introspection/-/issues/7
Bug-Debian: https://bugs.debian.org/1081701
Forwarded: https://gitlab.gnome.org/GNOME/perl-glib-object-introspection/-/merge_requests/12
---
 gperl-i11n-marshal-interface.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/gperl-i11n-marshal-interface.c b/gperl-i11n-marshal-interface.c
index 2bef8eb..50cce51 100644
--- a/gperl-i11n-marshal-interface.c
+++ b/gperl-i11n-marshal-interface.c
@@ -41,6 +41,12 @@ instance_sv_to_pointer (GICallableInfo *info, SV *sv, GPerlI11nInvocationInfo *i
 info_type,
 sv);
 			}
+} else if (g_type_is_a (type, G_TYPE_POINTER)) {
+dwarn ("  -> pointer\n");
+pointer = sv_to_struct (GI_TRANSFER_NOTHING,
+container,
+info_type,
+sv);
 		} else {
 			dwarn ("  -> boxed: type=%s (%"G_GSIZE_FORMAT")\n",
 			   g_type_name (type), type);
@@ -397,6 +403,12 @@ interface_to_sv (GITypeInfo* info,
 			}
 		}
 
+else if (g_type_is_a (type, G_TYPE_POINTER)) {
+dwarn ("  -> pointer: pointer=%p, type=%"G_GSIZE_FORMAT" (%s), own=%d\n",
+   arg->v_pointer, type, g_type_name (type), own);
+			sv = struct_to_sv (interface, info_type, arg->v_pointer, own);
+}
+
 #if GLIB_CHECK_VERSION (2, 24, 0)
 		else if (g_type_is_a (type, G_TYPE_VARIANT)) {
 			dwarn ("  -> variant\n");

Bug#1081701: libglib-object-introspection-perl: test regression with g-i 1.81.x: Cannot convert record value of unknown type GIMarshallingTestsPointerStruct to SV

[Simon McVittie]

Source: libglib-object-introspection-perl
Version: 0.051-1
Tags: ftbfs trixie sid
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
X-Debbugs-Cc: gobject-introspect...@packages.debian.org
Forwarded: 
https://gitlab.gnome.org/GNOME/perl-glib-object-introspection/-/issues/7
Control: affects -1 src:gobject-introspection

libglib-object-introspection-perl's autopkgtests fail when testing against
gobject-introspection 1.81.x in experimental:

> t/structs.t ... 
> 1..6
> ok 1
> ok 2
> Cannot convert record value of unknown type GIMarshallingTestsPointerStruct 
> (94216787708512) to SV at t/structs.t line 26.
> # Looks like your test exited with 255 just after 2.
> Dubious, test returned 255 (wstat 65280, 0xff00)
> Failed 4/6 subtests 

There's a similar test failure when libglib-object-introspection-perl is
rebuilt against gobject-introspection/experimental.

I'm reporting this as serious even though it doesn't directly
affect testing/unstable right now, because we should really upload
gobject-introspection 1.82.0 to unstable relatively soon as part of
GNOME 47.

smcv

Bug#1081598: marked as pending in cheese

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1081598 in cheese reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/cheese/-/commit/38931708158b2897061557c0ac73790d5ee23a04


Add patch from upstream merge request !73 to fix JSON standards compliance

json-glib 1.10 parses JSON more strictly.

Closes: #1081598


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1081598

Bug#1074878: marked as pending in cheese

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1074878 in cheese reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/cheese/-/commit/27fb8a85cf0853b230d7a2016cf8bf8aade36c07


Add patch from upstream merge request !70 to fix build with gcc-14

Closes: #1074878


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1074878

Bug#1081515: gtk4: FTBFS with weston 14: many tests fail with --setup=wayland: Failed to open display

[Simon McVittie]

Control: retitle -1 weston: 14.x regression: crashes during gtk4 test suite
Control: reassign -1 weston 14.0.0-1
Control: affects -1 + src:gtk4

On Thu, 12 Sep 2024 at 22:41:10 +0200, Aurelien Jarno wrote:
> On 2024-09-12 20:59, Simon McVittie wrote:
> > On Thu, 12 Sep 2024 at 11:48:21 +0100, Simon McVittie wrote:
> > > gtk4's test suite is failing on all -ports architectures that have buildds
> > >
> > > (/<>/debian/build/deb/testsuite/gtk/spinbutton:12693): 
> > > Gtk-WARNING **: 17:54:18.469: Failed to open display
> > 
> > My current working theory is either a behaviour change in Weston 14,
> > or Weston 14 is crashing part way through testing and all subsequent
> > tests fail.
> 
> Weston 14 is crashing with SIGSEGV a following a few tests like flowbox
> or textiter, despite the test being successful. The following tests
> fails with no display.

Thanks for checking that, reassigning this to weston.

smcv

Bug#1081517: libcurl-gnutls.so.4 no longer linked with needed libraries

[Simon McVittie]

On Thu, 12 Sep 2024 at 17:48:57 +0100, Simon McVittie wrote:
> As a future improvement, it might be worthwhile to restructure the GNUTLS
> patch so that it works more like this (pseudo-diff, hopefully you will
> see what I mean):
> 
> 
> diff...
> ---...
> +++...
>  libcurl_la_CPPFLAGS = $(AM_CPPFLAGS) $(libcurl_la_CPPFLAGS_EXTRA)
>  libcurl_la_LDFLAGS = $(AM_LDFLAGS) $(libcurl_la_LDFLAGS_EXTRA) 
> $(CURL_LDFLAGS_LIB) $(LIBCURL_PC_LIBS_PRIVATE)
>  libcurl_la_CFLAGS = $(AM_CFLAGS) $(libcurl_la_CFLAGS_EXTRA)
> +
> +if GNUTLSBUILD
> +libcurl_la_CPPFLAGS = $(libcurl_la_CPPFLAGS)
> +libcurl_la_LDFLAGS = $(libcurl_la_LDFLAGS)
> +libcurl_la_CFLAGS = $(libcurl_la_CFLAGS)
> +endif
> 

Sorry, that should of course have said:


diff...
---...
+++...
 libcurl_la_CPPFLAGS = $(AM_CPPFLAGS) $(libcurl_la_CPPFLAGS_EXTRA)
 libcurl_la_LDFLAGS = $(AM_LDFLAGS) $(libcurl_la_LDFLAGS_EXTRA) 
$(CURL_LDFLAGS_LIB) $(LIBCURL_PC_LIBS_PRIVATE)
 libcurl_la_CFLAGS = $(AM_CFLAGS) $(libcurl_la_CFLAGS_EXTRA)
+
+if GNUTLSBUILD
+libcurl_gnutls_la_CPPFLAGS = $(libcurl_la_CPPFLAGS)
+libcurl_gnutls_la_LDFLAGS = $(libcurl_la_LDFLAGS)
+libcurl_gnutls_la_CFLAGS = $(libcurl_la_CFLAGS)
+endif


smcv

Bug#1081517: libcurl-gnutls.so.4 no longer linked with needed libraries

[Simon McVittie]

Control: tags -1 + patch

On Thu, 12 Sep 2024 at 10:20:59 -0300, Carlos Henrique Lima Melara wrote:
> > E   ImportError: /lib/i386-linux-gnu/libcurl-gnutls.so.4: undefined symbol: 
> > gnutls_free
> 
> We are aware of the issue and will try to solve by
> the end of the week - or as soon as we have time to debug it.

I think I can see why this happens. The OpenSSL code path in
lib/Makefile.am changed some of the lists of parameters in 8.10.0 (in
particular the variable containing dependency libraries was renamed),
and the GNUTLS code path that is patched in by the Debian packaging
wasn't updated to match.

The attached patch 0001 makes it easy to see this failure mode, by refusing
to link the library with incomplete dependencies. Please consider applying
this so that the same failure mode cannot happen again.

I believe the attached patch 0002 fixes the regression (it compiles
successfully, not otherwise tested).

Please also consider patch 0003 which ensures that the correct compilation
flags are used for libcurlu.la, the static library that is used by some
(all?) of the unit tests.

As a future improvement, it might be worthwhile to restructure the GNUTLS
patch so that it works more like this (pseudo-diff, hopefully you will
see what I mean):


diff...
---...
+++...
 libcurl_la_CPPFLAGS = $(AM_CPPFLAGS) $(libcurl_la_CPPFLAGS_EXTRA)
 libcurl_la_LDFLAGS = $(AM_LDFLAGS) $(libcurl_la_LDFLAGS_EXTRA) 
$(CURL_LDFLAGS_LIB) $(LIBCURL_PC_LIBS_PRIVATE)
 libcurl_la_CFLAGS = $(AM_CFLAGS) $(libcurl_la_CFLAGS_EXTRA)
+
+if GNUTLSBUILD
+libcurl_la_CPPFLAGS = $(libcurl_la_CPPFLAGS)
+libcurl_la_LDFLAGS = $(libcurl_la_LDFLAGS)
+libcurl_la_CFLAGS = $(libcurl_la_CFLAGS)
+endif


but that would be a more intrusive change, so I haven't done that, for the
sake of providing a minimal proposed fix sooner.

smcv
>From fe7322ff926f71f34ed766c754d590f08f391c20 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 12 Sep 2024 17:23:56 +0100
Subject: [PATCH 1/3] d/rules: Do not allow any undefined symbols when linking

Instead of allowing creation of a library with missing dependencies if
the build has gone wrong, make sure that the build will fail early.

Reproduces: #1081517
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index b982151d3f..6acc0e875e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,6 +35,7 @@ endif
 
 export DEB_CFLAGS_MAINT_APPEND = -D_DEB_HOST_ARCH=\"$(DEB_HOST_MULTIARCH)\" -DCURL_PATCHSTAMP=\"$(DEB_VERSION)\"
 export DEB_CXXFLAGS_MAINT_APPEND = -D_DEB_HOST_ARCH=\"$(DEB_HOST_MULTIARCH)\" -DCURL_PATCHSTAMP=\"$(DEB_VERSION)\"
+export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-undefined
 
 ifneq ($(filter pkg.curl.openssl-only,$(DEB_BUILD_PROFILES)),)
 	DEB_BUILD_PROFILES += pkg.curl.no-gnutls
-- 
2.45.2

>From d277e4e16ad7b06479e2bee5a314af86d6f6b314 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 12 Sep 2024 17:31:07 +0100
Subject: [PATCH 2/3] ZZZgnutls-build.patch: Resync libraries used for GNUTLS
 flavour

The libraries used to link the OpenSSL flavour moved from
LIBCURL_LIBS to LIBCURL_PC_LIBS_PRIVATE in 8.10.0 upstream.
Link the GNUTLS flavour to the same libraries.

Closes: #1081517
---
 debian/patches/ZZZgnutls-build.patch | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/patches/ZZZgnutls-build.patch b/debian/patches/ZZZgnutls-build.patch
index aa0b11f679..85e2ccca12 100644
--- a/debian/patches/ZZZgnutls-build.patch
+++ b/debian/patches/ZZZgnutls-build.patch
@@ -4,7 +4,7 @@ Subject: Build with GnuTLS.
 
 Origin: vendor
 Forwarded: not-needed
-Last-Update: 2024-09-11
+Last-Update: 2024-09-12
 ---
  configure.ac   | 10 
  docs/examples/Makefile.am  |  2 +-
@@ -51,7 +51,7 @@ index 91f90cf..13874e1 100644
  # This might hold -Werror
  CFLAGS += @CURL_CFLAG_EXTRAS@
 diff --git a/lib/Makefile.am b/lib/Makefile.am
-index 851cee2..0191200 100644
+index 851cee2..f0fddca 100644
 --- a/lib/Makefile.am
 +++ b/lib/Makefile.am
 @@ -34,7 +34,11 @@ EXTRA_DIST = Makefile.mk config-win32.h config-win32ce.h config-plan9.h \
@@ -155,7 +155,7 @@ index 851cee2..0191200 100644
  
 +if GNUTLSBUILD
 +libcurl_gnutls_la_CPPFLAGS = $(AM_CPPFLAGS) $(libcurl_gnutls_la_CPPFLAGS_EXTRA)
-+libcurl_gnutls_la_LDFLAGS = $(AM_LDFLAGS) $(libcurl_gnutls_la_LDFLAGS_EXTRA) $(CURL_LDFLAGS_LIB) $(LIBCURL_LIBS)
++libcurl_gnutls_la_LDFLAGS = $(AM_LDFLAGS) $(libcurl_gnutls_la_LDFLAGS_EXTRA) $(CURL_LDFLAGS_LIB) $(LIBCURL_PC_LIBS_PRIVATE)
 +libcurl_gnutls_la_CFLAGS = $(AM_CFLAGS) $(libcurl_gnutls_la_CFLAGS_EXTRA)
 +libcurlu_gnutls_la_CPPFLAGS = $(AM_CPPFLAGS) -DCURL_STATICLIB -DUNITTESTS
 +libcurlu_gnutls_la_LDFLAGS = $(AM_LDFLAGS) -static $(LIBCURL_LIBS)
-- 
2.45.2

>From 625dea43c80dc7f25223e6c9239ca1322d07ab2c Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 12 Sep 2024 17:34:59 +0100
Subject: [PATCH 3/3] ZZZgnutls-build.patch:

Bug#1081440: gnome-settings-daemon: test failure on arm64: Lid: timed out waiting for unblank

[Simon McVittie]

Source: gnome-settings-daemon
Version: 47~rc-1
Severity: serious
Tags: ftbfs experimental
Justification: fails to build from source (but built successfully in the past)

A retried build on arm64 has a test failure not seen on any other release
architectures:

https://buildd.debian.org/status/fetch.php?pkg=gnome-settings-daemon&arch=arm64&ver=47%7Erc-1&stamp=1726070527&raw=0

> ==
> FAIL: test_unblank_on_lid_open 
> (__main__.PowerPluginTestLid.test_unblank_on_lid_open)
> Check that we do unblank on lid opening, if the machine will not suspend
> --
> Traceback (most recent call last):
>   File "/<>/tests/output_checker.py", line 93, in check_line_re
> l = self._lines.pop(0)
> ^^
> IndexError: pop from empty list
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/<>/plugins/power/test.py", line 692, in 
> test_unblank_on_lid_open
> self.check_unblank(2)
>   File "/<>/plugins/power/test.py", line 384, in check_unblank
> self.check_plugin_log('TESTSUITE: Unblanked screen', timeout,
>   File "/<>/plugins/power/test.py", line 349, in check_plugin_log
> self.plugin_log.check_line(needle, timeout=timeout, failmsg=failmsg)
>   File "/<>/tests/output_checker.py", line 120, in check_line
> return self.check_line_re(needle_re, timeout=timeout, failmsg=failmsg)
>^^^
>   File "/<>/tests/output_checker.py", line 105, in check_line_re
> raise AssertionError(failmsg)
> AssertionError: timed out waiting for unblank

(Probably intermittent, and probably not actually architecture-specific.)

smcv

Bug#1081439: gnome-settings-daemon: test failure on ppc64el: timeout and segfault in BrightnessStep test

[Simon McVittie]

Source: gnome-settings-daemon
Version: 47~rc-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

ppc64el has a test failure not seen on any other release architectures:

https://buildd.debian.org/status/fetch.php?pkg=gnome-settings-daemon&arch=ppc64el&ver=47%7Erc-1&stamp=1726061858&raw=0

> === 10/10 
> test: test-power BrightnessStep
> start time:   13:35:11
> duration: 120.03s
> result:   killed by signal 11 SIGSEGV
> command:  MESON_TEST_ITERATION=1 MALLOC_PERTURB_=101 
> LD_PRELOAD=libumockdev-preload.so.0 HAVE_SYSFS_BACKLIGHT=1 
> BUILDDIR='/<>/obj-powerpc64le-linux-gnu/plugins/power' 
> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 NO_AT_BRIDGE=1 
> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  TOP_BUILDDIR='/<>/obj-powerpc64le-linux-gnu' 
> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  '/<>/plugins/power/test.py' PowerPluginTestBrightnessStep
> --- stdout ---
> (process:1137353): GLib-GIO-DEBUG: 13:35:11.678: _g_io_module_get_default: 
> Found default implementation dconf (DConfSettingsBackend) for 
> ‘gsettings-backend’
> (process:1137353): dconf-DEBUG: 13:35:11.678: watch_fast: 
> "/org/gnome/desktop/session/" (establishing: 0, active: 0)
> test_brightness_compression 
> (__main__.PowerPluginTestBrightnessStep.test_brightness_compression)
> --- stderr ---
> /<>/plugins/power/test.py:842: SyntaxWarning: invalid escape 
> sequence '\('
>   self.p_notify_log.check_line_re(b'[0-9.]+ Notify "Power" .* ".*" 
> ".*Wireless mouse .*low.* power.*\([0-9.]+%\).*"', timeout=0.5)
> /<>/plugins/power/test.py:872: SyntaxWarning: invalid escape 
> sequence '\('
>   self.p_notify_log.check_line_re(b'[0-9.]+ Notify "Power" .* ".*" 
> ".*Wireless mouse .*low.* power.*\([0-9.]+%\).*"', timeout=0.5)
> /<>/plugins/power/test.py:924: SyntaxWarning: invalid escape 
> sequence '\('
>   self.p_notify_log.check_line_re(b'[0-9.]+ Notify "Power" .* ".*" 
> ".*Wireless mouse .*very low.* power.*\([0-9.]+%\).*"', timeout=0.5)
> /<>/plugins/power/test.py:975: SyntaxWarning: invalid escape 
> sequence '\('
>   self.assertNotRegex(l, b'[0-9.]+ Notify "Power" .* ".*" ".*\([0-9.]+%\).*"')
> dbus-daemon[1137357]: [session uid=2952 pid=1137357] Reloaded configuration
> dbus-daemon[1137357]: [session uid=2952 pid=1137357] Connection :1.5 
> (uid=2952 pid=1137360 comm="dbus-monitor --monitor") became a monitor.
> ==

(Probably intermittent, and probably not actually architecture-specific.)

smcv

Bug#1081437: gnome-settings-daemon: frequent test failure: timed out waiting for a reader on klass.display_name_fifo

[Simon McVittie]

Source: gnome-settings-daemon
Version: 47~rc-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

In several of the buildd builds, test-xsettings fails with:

> Traceback (most recent call last):
>   File "/<>/plugins/xsettings/test.py", line 141, in 
> dbus-daemon[1007603]: [session uid=2952 pid=1007603] Monitoring connection 
> :1.5 closed.
> unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, 
> verbosity=2))
>   File "/usr/lib/python3.12/unittest/main.py", line 105, in __init__
> self.runTests()
>   File "/usr/lib/python3.12/unittest/main.py", line 281, in runTests
> self.result = testRunner.run(self.test)
>   ^
>   File "/usr/lib/python3.12/unittest/runner.py", line 240, in run
> test(result)
>   File "/usr/lib/python3.12/unittest/suite.py", line 84, in __call__
> return self.run(*args, **kwds)
>^^^
>   File "/usr/lib/python3.12/unittest/suite.py", line 122, in run
> test(result)
>   File "/usr/lib/python3.12/unittest/suite.py", line 84, in __call__
> return self.run(*args, **kwds)
> 
> (mutter:1007675): libmutter-WARNING **: 15:37:11.877: Connection to xwayland 
> lost
> 
> (mutter:1007675): libmutter-WARNING **: 15:37:11.877: Xwayland terminated, 
> exiting since it was mandatory
>  ^^
> (mutter:1007675): libmutter-WARNING **: 15:37:11.877: 
> (../src/core/meta-context.c:575):meta_context_terminate: runtime check 
> fa^iled: (g_main_loop_is_running (priv->main_loop))
> 
>   File "/usr/lib/python3.12/unittest/suite.py", line 122, in run
> 
> (mutter:1007675): libmutter-WARNING **: 15:37:11.877: 
> (../src/core/meta-context.c:575):meta_context_terminate: runtime check 
> failed: (g_main_loop_is_running (priv->main_loop))
> test(result)
>   File "/usr/lib/python3.12/unittest/case.py", line 690, in __call__
>   File "/<>/tests/gsdtestcase.py", line 154, in run
> super(GSDTestCase, self).run(result)
>   File "/usr/lib/python3.12/unittest/case.py", line 638, in run
> self.doCleanups()
>   File "/usr/lib/python3.12/unittest/case.py", line 671, in doCleanups
> self._callCleanup(function, *args, **kwargs)
>   File "/usr/lib/python3.12/unittest/case.py", line 597, in _callCleanup
> function(*args, **kwargs)
>   File "/<>/tests/gsdtestcase.py", line 291, in stop_mutter
> with open(klass.display_name_fifo, 'w') as f:
>  ^^
>   File "/<>/tests/gsdtestcase.py", line 123, in r
> raise KeyboardInterrupt()
> KeyboardInterrupt

(Not the same failure mode as the other FTBFS I reported, although they
might share a root cause.)

smcv

Bug#1081417: gnome-settings-daemon: frequent test failure: timed out waiting for plugin startup: XSettings

[Simon McVittie]

Source: gnome-settings-daemon
Version: 47~rc-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

In several of the buildd builds, test-xsettings fails with:

> ==
> FAIL: test_fontconfig_timestamp 
> (__main__.XsettingsPluginTest.test_fontconfig_timestamp)
> --
> Traceback (most recent call last):
>   File "/<>/plugins/xsettings/test.py", line 79, in setUp
> self.start_plugin(os.environ.copy())
>   File "/<>/tests/gsdtestcase.py", line 332, in start_plugin
> assert timeout > 0, 'timed out waiting for plugin startup: %s' % 
> (self.gsd_plugin_case)
>^^^
> AssertionError: timed out waiting for plugin startup: XSettings
>
> ==
> FAIL: test_gtk_modules (__main__.XsettingsPluginTest.test_gtk_modules)
> --
> Traceback (most recent call last):
>   File "/<>/plugins/xsettings/test.py", line 79, in setUp
> self.start_plugin(os.environ.copy())
>   File "/<>/tests/gsdtestcase.py", line 332, in start_plugin
> assert timeout > 0, 'timed out waiting for plugin startup: %s' % 
> (self.gsd_plugin_case)
>^^^
> AssertionError: timed out waiting for plugin startup: XSettings

There's some previous discussion of this on
https://salsa.debian.org/gnome-team/gnome-settings-daemon/-/merge_requests/20

smcv

Bug#1081275: gtk4: gdk/memorytexture test failing in r16g16b16-float/ngl on mips64el only

[Simon McVittie]

On Tue, 10 Sep 2024 at 10:13:30 +0100, Simon McVittie wrote:
> I'm going to mark the 16-bit half-float
> tests to be skipped on mips64el and downgrade the severity of this bug to
> important. Anyone else is very welcome to investigate further.

Done in 4.16.0+ds-2. It's still a bug, just not RC any more.

To reproduce the bug, revert
debian/patches/workarounds/memorytexture-test-Ignore-failures-with-FP-softpipe-ngl-o.patch
and rebuild.

smcv

Bug#1081309: src:gnome-characters: fails to migrate to testing for too long

[Simon McVittie]

On Tue, 10 Sep 2024 at 18:27:48 +0200, Paul Gevers wrote:
> Migration status for gnome-characters (46.0-1 to 47~alpha-1): BLOCKED: Maybe
> temporary, maybe blocked but Britney is missing information (check below)
> Issues preventing migration:
> ∙ ∙ missing build on mips64el

This was caused by the unit test segfaulting on mips64el, and the latest
retry seems to have avoided this fate. I'm hoping that this was fixed by
the recent addition of an ORCJIT llvmpipe driver in Mesa, meaning that we
finally have working OpenGL on mips64el buildds (among other architectures)
without needing special workarounds.

I'm reluctant to have packages compile on all architectures for the sake
of compiling on all architectures if there is evidence that the resulting
binaries might not actually work, so if we get similar test failures
in leaf packages, I'm likely to start asking for architecture-specific
removals.

smcv

Bug#1077075: mutter: Monitors on second GPU not detected on Wayland

[Simon McVittie]

Control: retitle -1 mutter: Monitors on second GPU not detected on Wayland
Control: severity -1 important

On Sat, 27 Jul 2024 at 09:05:39 -0400, Jeremy Bícha wrote:
> On Thu, Jul 25, 2024 at 3:39 PM Fabrice Quenneville
>  wrote:
> > Justification: breaks the whole system
> 
> I'm sorry that the upgrade has caused you problems, but I think this
> is overstating the severity since there is a workaround (use the GNOME
> on Xorg session) and you can still use 2 monitors on Wayland.

I agree, reducing severity accordingly.

smcv

Bug#1081275: gtk4: gdk/memorytexture test failing in r16g16b16-float/ngl on mips64el only

[Simon McVittie]

Source: gtk4
Version: 4.15.6+ds-1
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el
Control: block 1079548 by -1

After upgrading some lower-level component (my guess would be Mesa
24.1.x -> 24.2.x but I could be wrong), I'm seeing one test-case failing
in the memorytexture executable, in a gtk4 version where it previously
passed.

In different builds with different GTK4 versions, I'm variously seeing

# (0 0): 0.600098 1.00 0.199951 != 89920.00 89920.00 89920.00
# (1 0): 0.600098 1.00 0.199951 != 89920.00 89920.00 89920.00
# (2 0): 0.600098 1.00 0.199951 != 89920.00 89920.00 89920.00
...
# (109 271): 0.600098 1.00 0.199951 != 89920.00 89920.00 
89920.00
# (110 271): 0.600098 1.00 0.199951 != 89920.00 89920.00 
89920.00
# (111 271): 0.600098 1.00 0.199951 != 89920.00 89920.00 
89920.00
not ok 455 /memorytexture/download_random/r16g16b16-float/ngl

or

# (0 0): 0.00 1.00 0.199951 != -71104.00 1.00 0.199951
not ok 125 /memorytexture/download_1x1/r16g16b16-float/ngl

or

# r16g16b16-float (0 0): 0.533203 0.133301 0.533203 != 98240.00 -137.875000 
87.125000
not ok 125 /memorytexture/download_1x1/r16g16b16-float/ngl

In each case the left side of the "!=" is the pixel we expected to see,
and the right side is what we got.

The common factors are that this is using a 16 bits per channel half-float
texture format in conjunction with the NGL ("new" OpenGL) renderer. The
same test-case with the GL ("old" OpenGL) renderer is still working.
Unlike other bugs that have been seen on architectures where we use the
softpipe Mesa driver, this one seems to be specific to mips64el and does
not affect riscv64.

4.14.x in testing/unstable does not seem to be affected, but we are overdue
for uploading 4.15.x/4.16.x to unstable, which is blocking a lot of GNOME
libraries and applications.

I do not have any mips hardware or much remaining patience for
architecture-specific issues, so I'm going to mark the 16-bit half-float
tests to be skipped on mips64el and downgrade the severity of this bug to
important. Anyone else is very welcome to investigate further.

We could potentially mitigate any user-visible impact of this by forcing
use of GTK's "old" OpenGL renderer on mips64el, although that might
cause brokenness elsewhere (the "new" renderer is the default if Vulkan
is not available, and I suspect that the "old" renderer is essentially
unmaintained upstream).

smcv

Bug#1072512: marked as pending in mutter

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1072512 in mutter reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/mutter/-/commit/192f357b3a59715a6cd29537ba6cc4bcae3dff59


d/p/workarounds, d/tests: Treat all stacking tests as flaky

Unfortunately these don't seem to be stable enough to be used as a QA
gate, and there are enough of them that at least one will often fail in
any given buildd build or autopkgtest run

Closes: #1072512, #1078359
Mitigates: #1077800


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1072512

Bug#1078359: marked as pending in mutter

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1078359 in mutter reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/mutter/-/commit/192f357b3a59715a6cd29537ba6cc4bcae3dff59


d/p/workarounds, d/tests: Treat all stacking tests as flaky

Unfortunately these don't seem to be stable enough to be used as a QA
gate, and there are enough of them that at least one will often fail in
any given buildd build or autopkgtest run

Closes: #1072512, #1078359
Mitigates: #1077800


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1078359

Bug#1072512: mutter: flaky autopgktest

[Simon McVittie]

On Fri, 06 Sep 2024 at 23:40:15 +0200, Paul Gevers wrote:
> On Mon, 3 Jun 2024 10:12:07 -0400 =?UTF-8?Q?Jeremy_B=C3=ADcha?=
>  wrote:
> > The tests passed on retry and libxcursor is no longer blocked from
> > migrating. Sorry that the autopkgtests are flaky. :(
>
> The ratio at which mutter (at least on amd64) is failing on ci.d.n is
> unacceptable. (The ratio where I'm starting to doubt about severity is about
> 1/6 to 1/8 failures, but recent history is more like 1/2.)

Looking at the recent failure logs, the failures all seem to be in the
"stacking" test suite, which has two semi-common failure modes:

- sometimes mutter tries to create a texture with a negative size for
  reasons that I tried to investigate but do not understand
  (#1077800 aka #1078359)

- and sometimes the stacking (window management) tests just aren't reliable
  (#1050022, #1050023, similar random failures)

None of the individual test failures are particularly frequent, but there
are enough affected test cases that there's a high probability of at least
one of them failing in any given buildd build or autopkgtest run.

To mitigate this, I'm going to try something I had been considering for
a while: treat the whole "stacking" test suite as flaky. Unfortunately it
just isn't stable enough to be used as a QA gate.

smcv

Bug#1079499: marked as pending in gjs

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1079499 in gjs reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gjs/-/commit/49026d25724bd476b95e682895401bcd37bbf766


Add proposed patch to fix autopkgtest failures

Closes: #1079499


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1079499

Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works

[Simon McVittie]

On Wed, 04 Sep 2024 at 20:38:04 +0200, John Paul Adrian Glaubitz wrote:
> On Wed, 2024-09-04 at 18:51 +0100, Simon McVittie wrote:
> > but it's taking a while (mips64el machines are not fast)
> 
> The powerpc/ppc64 porterbox perotto.debian.net should be considerably faster
> than any mips64el machine we have. So, you may give it a try there as well.

Thanks for the suggestion, but gtk4's build-deps are unsatisfiable on
-ports, because freerdp2 can't be rebuilt for the new ffmpeg until its
FTBFS bugs are fixed, the current freerdp2 can't be installed because -ports
doesn't keep "cruft" packages like the old ffmpeg, and it's a dependency
for Weston.

So the best I'd be able to do is running less than half of the test suite:
some tests are run twice (under Xvfb and Weston) and some are only run
under Weston. Not a great way to have confidence that everything works!

The good news is that the removal of softpipe has been reverted in Mesa,
so we can continue to use gtk4's GALLIUM_DRIVER=softpipe workaround
on mips*, powerpc and sparc*, and probably add it to riscv* too. The
same workaround could probably help some other -ports architectures
(especially loong64) if someone wants to try it - although that isn't
actionable right now, again because of Weston.

smcv

Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works

[Simon McVittie]

Control: tags -1 + pending

On Wed, 04 Sep 2024 at 18:51:11 +0100, Simon McVittie wrote:
> src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
> around #1010838. Mesa 24.2.x is no longer built with softpipe enabled

24.2.1-4 re-enables softpipe (#1080475) which should resolve this for
mips*, powerpc and sparc*. The new Mesa version has not compiled on
buildds yet, but when it has, I'll check whether it fixes the build
regression on mips64el. Hopefully we can also start using softpipe on
riscv64 as a workaround for #1080435, until that gets fixed.

If there are -ports architectures where llvmpipe is known-broken,
I don't mind adding them to the list of architectures where we use
GALLIUM_DRIVER=softpipe - but I would suggest that as a longer-term
plan to have working GL everywhere, porters should look into fixing
llvmpipe for their architecture (via changes in Mesa and/or LLVM) if
necessary. The addition of an ORCJIT code path in Mesa seems like a
really big step towards this.

> I'm doing a gtk4 build on the mips64el porterbox eberlin to assess whether
> we can use the new ORCJIT llvmpipe and remove the workaround for #1010838

Unfortunately the answer seems to be "no we can't": lots of tests still
fail on mips64el with ORCJIT llvmpipe. I haven't looked into the failures
in detail, but this does not seem to be the same problem as on riscv64
(#1080435, #1080493) since the patch that has been suggested for the
riscv64 issue is in riscv64-specific code.

I haven't tried the -ports architectures with llvmpipe: they might be OK
with llvmpipe now, or they might still have similar problems. If a porter
wants to look into this, please look for "GALLIUM_DRIVER=softpipe"
in debian/rules and it should be obvious from there how to disable the
workaround. Testing the gtk4 4.15.x from experimental is more important
than the gtk4 4.14.x in testing/unstable right now, because we're hoping
to upload 4.15.x/4.16.x to unstable soon (it's required for GNOME 47).

smcv

Bug#1080477: gtk4: FTBFS on mips64el with Mesa 24.2.x: GALLIUM_DRIVER=softpipe no longer works

[Simon McVittie]

Source: gtk4
Version: 4.14.4+ds-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org, 
debian-powe...@lists.debian.org, debian-sp...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el

src:gtk4 uses GALLIUM_DRIVER=softpipe on mips*, powerpc and sparc* to work
around #1010838. Mesa 24.2.x is no longer built with softpipe enabled,
so this makes the softpipe driver fail to load and as a result makes (E)GL
initialization fail, breaking the test suite on these architectures, for
example:

> test: gtk:gsk / normalize
> ...
> not ok /node/normalize/color - 
> ERROR:../../../testsuite/gsk/normalize.c:18:test_normalize: assertion failed 
> (error == NULL): Could not initialize EGL display (gdk-gl-error-quark, 0)

Affected tests are

* gtk:gsk / normalize (run twice, for X11 and Wayland)
* gtk:gsk / misc (run twice, ditto)
* gtk:tools / validate (only run once, for Wayland)

I have only verified this on mips64el, but it probably affects the powerpc
and sparc64 -ports architectures equally.

My preferred solution for this would be for Mesa to re-enable softpipe,
at least on the affected architectures (I've opened a src:mesa bug #1080475
requesting that). If we stop using softpipe in gtk4 before Mesa 24.2.x
migrates to testing, then we will likely get a different failure mode
with the Mesa from testing: #1010838.

I'm doing a gtk4 build on the mips64el porterbox eberlin to assess whether
we can use the new ORCJIT llvmpipe and remove the workaround for #1010838,
but it's taking a while (mips64el machines are not fast). So far it's
looking as though we will still get quite a lot of test failures.

smcv

Bug#1080325: libadwaita-1: FTBFS on i386: segfault in test-bottom-sheet

[Simon McVittie]

Source: libadwaita-1
Version: 1.6~beta-1
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: i386
X-Debbugs-Cc: b...@debian.org

libadwaita-1 since 1.6~beta-1 failed to build from source on the i386 buildd,
with a test failure that does not seem to occur on any other architecture:

> === 12/58 
> test: test-bottom-sheet
> start time:   03:06:15
> duration: 0.47s
> result:   killed by signal 11 SIGSEGV
> command:  ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> PYTHONDONTWRITEBYTECODE=yes GSETTINGS_BACKEND=memory MESON_TEST_ITERATION=1 
> MALLOC_PERTURB_=70 G_DEBUG=gc-friendly 
> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  MALLOC_CHECK_=2 G_TEST_BUILDDIR='/<>/debian/testtmp/tests' 
> GTK_A11Y=none G_TEST_SRCDIR='/<>/tests' 
> LD_LIBRARY_PATH='/<>/debian/testtmp/src' 
> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  '/<>/debian/testtmp/tests/test-bottom-sheet'
> --- stdout ---
> TAP version 14
> # random seed: R02Sc8bc34657eb706470db14b5eabd21f46
> # GLib-GIO-DEBUG: Using cross-namespace EXTERNAL authentication (this will 
> deadlock if server is GDBus < 2.73.3)
> # GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
> local (GLocalVfs) for ?gio-vfs?
> # GLib-GIO-DEBUG: Using cross-namespace EXTERNAL authentication (this will 
> deadlock if server is GDBus < 2.73.3)
> # Adwaita-DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> # Adwaita-DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> # Adwaita-DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> # Adwaita-DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> # GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
> memory (GMemorySettingsBackend) for ?gsettings-backend?
> 1..10
> # Start of Adwaita tests
> # Start of BottomSheet tests
> ok 1 /Adwaita/BottomSheet/content
> ok 2 /Adwaita/BottomSheet/sheet
> ok 3 /Adwaita/BottomSheet/bottom_bar
> ok 4 /Adwaita/BottomSheet/open
> --- stderr ---
> libEGL warning: DRI3: Screen seems not DRI3 capable
> libEGL warning: DRI3: Screen seems not DRI3 capable
> MESA: error: ZINK: failed to choose pdev
> libEGL warning: egl: failed to create dri2 screen
> ==

I've retried the build to see whether this is reproducible, but a
segfault in a similar place was seen multiple times for 1.6~beta-1,
so it probably is.

smcv

Bug#1080324: libadwaita-1: FTBFS on s390x: test_adw_bottom_sheet_align: assertion failed (adw_bottom_sheet_get_align (sheet) == 0 (+/- 0.005)): (0.0078125 == 0)

[Simon McVittie]

Source: libadwaita-1
Version: 1.6~rc-1
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-s...@lists.debian.org
Usertags: s390x
X-Debbugs-Cc: debian-s...@lists.debian.org

libadwaita-1_1.6~rc-1 failed to build from source on the s390x buildd,
with an assertion failure that does not seem to occur on any other
architecture:

> === 11/58 
> test: test-bottom-sheet
> start time:   00:01:21
> duration: 0.18s
> result:   killed by signal 6 SIGABRT
> command:  MALLOC_PERTURB_=200 G_DEBUG=gc-friendly 
> LD_LIBRARY_PATH='/<>/debian/testtmp/src' 
> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  PYTHONDONTWRITEBYTECODE=yes GSETTINGS_BACKEND=memory 
> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  MESON_TEST_ITERATION=1 GTK_A11Y=none 
> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> G_TEST_BUILDDIR='/<>/debian/testtmp/tests' MALLOC_CHECK_=2 
> G_TEST_SRCDIR='/<>/tests' 
> '/<>/debian/testtmp/tests/test-bottom-sheet'
> --- stdout ---
> TAP version 14
> # random seed: R02S0cc070aa1325c8bbabac8caa15669dd9
> # GLib-GIO-DEBUG: Using cross-namespace EXTERNAL authentication (this will 
> deadlock if server is GDBus < 2.73.3)
> # GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
> local (GLocalVfs) for ?gio-vfs?
> # GLib-GIO-DEBUG: Using cross-namespace EXTERNAL authentication (this will 
> deadlock if server is GDBus < 2.73.3)
> # Adwaita-DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> # Adwaita-DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> # Adwaita-DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> # Adwaita-DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> # GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
> memory (GMemorySettingsBackend) for ?gsettings-backend?
> 1..10
> # Start of Adwaita tests
> # Start of BottomSheet tests
> ok 1 /Adwaita/BottomSheet/content
> ok 2 /Adwaita/BottomSheet/sheet
> ok 3 /Adwaita/BottomSheet/bottom_bar
> ok 4 /Adwaita/BottomSheet/open
> not ok /Adwaita/BottomSheet/align - 
> ERROR:../../tests/test-bottom-sheet.c:154:test_adw_bottom_sheet_align: 
> assertion failed (adw_bottom_sheet_get_align (sheet) == 0 (+/- 0.005)): 
> (0.0078125 == 0)
> Bail out!
> --- stderr ---
> libEGL warning: DRI3: Screen seems not DRI3 capable
> libEGL warning: DRI3: Screen seems not DRI3 capable
> MESA: error: ZINK: failed to choose pdev
> libEGL warning: egl: failed to create dri2 screen
> **
> ERROR:../../tests/test-bottom-sheet.c:154:test_adw_bottom_sheet_align: 
> assertion failed (adw_bottom_sheet_get_align (sheet) == 0 (+/- 0.005)): 
> (0.0078125 == 0)
> ==

I've retried the build to see whether this is reproducible. If not, I'll
downgrade it to important.

The test is doing an inexact comparison, so it might be OK to just increase
the tolerance a bit.

Alternatively, the same test is crashing with a segfault on i386 in
approximately the same place (I'll report a separate bug), so it's
possible that there is a bug here that will go away when the crash on
i386 is fixed.

smcv

Bug#1080323: gnome-snapshot: FTBFS on armel, armhf: LLVM runs out of memory

[Simon McVittie]

Source: gnome-snapshot
Version: 47~beta-1
Severity: serious
Tags: experimental ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: armel armhf
X-Debbugs-CC: debian-...@lists.debian.org, debian-r...@lists.debian.org

The new version of gnome-snapshot in experimental FTBFS on armel and
armhf with this error message:

>Compiling snapshot v46.0.0 (/<>)
>  Running [a long rustc command]
> rustc-LLVM ERROR: out of memory
> Allocation failed
> error: could not compile `snapshot` (bin "snapshot")

Presumably this is actually running out of address space available to a
single process, which is 2G on 32-bit if I understand correctly.
This probably affects the other 32-bit architectures equally, but some
build-dependencies are missing on i386 and on all 32-bit -ports
architectures, so we cannot yet confirm or deny that.

Is there anything that can be done in the rustc/cargo options to reduce
memory consumption, like perhaps reducing optimizations or debug symbol
coverage?

Whether this can be fixed will affect the decision being made in #1080153
about cheese vs. gnome-snapshot in the src:meta-gnome3 metapackages. If
gnome-snapshot becomes unavailable on armel/armhf/i386, we'll have to do
architecture-specific removals; but then if we decide that gnome-snapshot
is preferred on 64-bit architectures, we will need to either continue to
have cheese (and therefore clutter-1.0, which is unmaintained upstream)
available for at least the 32-bit architectures, or omit webcam
integration from the metapackages on 32-bit (or not provide the metapackages
at all on 32-bit, but that will require coordination with the release team).

smcv

Bug#1079546: marked as pending in gtk4

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1079546 in gtk4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gtk4/-/commit/4538b0f0eaa4d68266576ff9e5b9a64619c0581f


Add proposed patches to fix crashes on 64-bit big-endian since 4.15.x

Closes: #1079546


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1079546

Bug#1079545: marked as pending in gtk4

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1079545 in gtk4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gtk4/-/commit/f56af804c75d085d020d8a10f78c14caf805da40


Add a patch to work around fesetround() not working on armel

Closes: #1079545


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1079545

Bug#1079545: gtk4: test regression in 4.15.x: css/parser/math2.css test fails on armel

[Simon McVittie]

On Sun, 01 Sep 2024 at 13:01:17 +, Martin wrote:
> My company is still a heavy user of glib and gobject on armel. But
> certainly not of GTK. Is there still any use case for GTK on armel?

Probably not, but Debian has never really managed to do partial
architectures, which is why I felt obliged to spend time on this bug in
the first place. At the moment, my understanding of the release team
policy and infrastructure is that it is not possible to have a release
architecture where not all tasksel tasks are installable.

Even if we could ignore installability of task-gnome-desktop and other
GTK-dependent task metapackages on armel, if GTK was removed from armel,
then I suspect that many other packages would need to be modified to
add architecture conditions, so that they're still built on armel but
without GTK support.

smcv

Bug#1079545: gtk4: test regression in 4.15.x: css/parser/math2.css test fails on armel

[Simon McVittie]

Control: tags -1 + patch pending

On Sat, 24 Aug 2024 at 09:24:02 -0400, Jeremy Bícha wrote:
> A new test added in gtk4 4.15.* is failing on armel but not on any
> other release architecture.
...
> not ok 1 /<>/testsuite/css/parser/math2.css

The bug is that GTK implements CSS expressions like `round(up, 18px, 5px)`
by using fesetround() to select the desired rounding mode, and nearbyint()
to do the rounding.

On all release architectures except armel, this works as intended:
floating point arithmetic is done in hardware, and the FPU supports
all four of the rounding modes required by GTK's CSS implementation
(FE_TONEAREST, FE_UPWARD, FE_DOWNWARD, FE_TOWARDZERO).

On armel, the software implementation of floating-point only implements
the default FE_TONEAREST[1], and the other modes are not available. This
causes the test to fail: `round(to-zero, 18px, 5px)` comes out as 20px
instead of the intended 15px, and similar for `round(down, 18px, 5px)`.

[1] see also https://lists.debian.org/debian-arm/2008/03/msg1.html

I was able to get this test passing with GTK 4.15.6 by applying the
attached patch, also available as part of the update to 4.15.6 in
<https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/26>
(I have not tried to backport it to 4.15.5 but I suspect it would apply
cleanly there too).

I have intentionally not tried to upstream this patch, because I can
already predict what will happen: upstream will ask why I'm trying to
run GTK on an old embedded device with no FPU and no useful GPU, and I
will not have a good answer, because I, personally, have never wanted
to do that. I find being upstream's punching bag for all of Debian's
architecture support decisions to be really demotivating, and even if
I had unlimited motivation, I think upstreaming this myself would be
tactically a bad idea: every time I try to make upstream spend their
limited time on an architecture that they don't have any interest in
supporting, I feel as though I'm coming one step closer to the point
where they start intentionally ignoring me, which would significantly
harm my ability to do other work that the project expects from me.

So, I'm invoking Debian Constitution §2.1.1 and declining to attempt
to fix this upstream myself. If someone from the ARM porting team
feels strongly that armel should continue to be a first-class-citizen
architecture for GTK for whatever reason, please take over here.

Thanks,
smcv
From: Simon McVittie 
Date: Sat, 31 Aug 2024 10:13:48 +0100
Subject: gtkcssnumbervalue: Don't use fesetround() on ARM softfloat

Older ARM CPUs have to emulate floating-point in software, and do not
implement rounding modes other than the default, FE_TONEAREST.
Implement nearbyint() the hard way when targeting an affected platform.

Bug-Debian: https://bugs.debian.org/1079545
Signed-off-by: Simon McVittie 
---
 gtk/gtkcssnumbervalue.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/gtk/gtkcssnumbervalue.c b/gtk/gtkcssnumbervalue.c
index 1181c1a..d9cdf5f 100644
--- a/gtk/gtkcssnumbervalue.c
+++ b/gtk/gtkcssnumbervalue.c
@@ -1846,11 +1846,21 @@ gtk_css_dimension_value_is_zero (const GtkCssValue *value)
   return value->dimension.value == 0;
 }
 
+#if defined(__arm__) && !defined(__ARM_PCS_VFP)
+/* Floating-point emulated in software. Setting the rounding mode to
+ * anything other than FE_TONEAREST doesn't work */
+#undef HAVE_WORKING_FESETROUND
+#else
+#define HAVE_WORKING_FESETROUND
+#endif
+
 static double
 _round (guint mode, double a, double b)
 {
+#ifdef HAVE_WORKING_FESETROUND
   int old_mode;
   int modes[] = { FE_TONEAREST, FE_UPWARD, FE_DOWNWARD, FE_TOWARDZERO };
+#endif
   double result;
 
   if (b == 0)
@@ -1880,12 +1890,36 @@ _round (guint mode, double a, double b)
 }
 }
 
+#ifdef HAVE_WORKING_FESETROUND
   old_mode = fegetround ();
   fesetround (modes[mode]);
 
   result = nearbyint (a/b) * b;
 
   fesetround (old_mode);
+#else
+  result = a / b;
+
+  switch (mode)
+{
+case ROUND_NEAREST:
+  result = round (result);
+  break;
+case ROUND_TO_ZERO:
+  result = (result >= 0 ? floor (result) : ceil (result));
+  break;
+case ROUND_UP:
+  result = ceil (result);
+  break;
+case ROUND_DOWN:
+  result = floor (result);
+  break;
+default:
+  g_assert_not_reached ();
+}
+
+  result *= b;
+#endif
 
   return result;
 }

Bug#1079546: gtk4: two css tests are failing on s390x

[Simon McVittie]

Control: tags -1 + pending

On Sat, 31 Aug 2024 at 02:15:00 +0100, Simon McVittie wrote:
> On Sat, 24 Aug 2024 at 09:29:57 -0400, Jeremy Bícha wrote:
> > test: gtk:css / style
> 
> Fixed by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7672, and
> included in my WIP packaging for 4.15.6:
> https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/26
> 
> > test: gtk:css / parser variables.css
> 
> This is not solved by the same change and will presumably need debugging
> separately.

A second commit in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7672
and https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/26 solves the
other s390x failure (with 4.15.6, I haven't tried with 4.15.5).

smcv

Bug#1079546: gtk4: two css tests are failing on s390x

[Simon McVittie]

On Sat, 24 Aug 2024 at 09:29:57 -0400, Jeremy Bícha wrote:
> test: gtk:css / style

Fixed by https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7672, and
included in my WIP packaging for 4.15.6:
https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/26

> test: gtk:css / parser variables.css

This is not solved by the same change and will presumably need debugging
separately.

smcv

Bug#1079522: software-properties: FTBFS in unstable (setuptools 73?): invalid command 'test'

[Simon McVittie]

Source: software-properties
Version: 0.99.30-4.1
Severity: serious
Tags: ftbfs trixie sid
Justification: fails to build from source
X-Debbugs-Cc: setupto...@packages.debian.org

software-properties builds successfully in testing but fails to build in
unstable, presumably due to a change in some other package:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/software-properties.html

Hopefully the relevant part of the log:

> dbus-run-session -- dh_auto_test
> I: pybuild base:311: python3.12 setup.py test 
...
> /usr/lib/python3/dist-packages/setuptools/_distutils/dist.py:268: 
> UserWarning: Unknown distribution option: 'test_suite'
>   warnings.warn(msg)
> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>or: setup.py --help [cmd1 cmd2 ...]
>or: setup.py --help-commands
>or: setup.py cmd --help
> 
> error: invalid command 'test'
> E: pybuild pybuild:389: test: plugin distutils failed with: exit code=1: 
> python3.12 setup.py test 
> dh_auto_test: error: pybuild --test -i python{version} -p 3.12 returned exit 
> code 13

This is easy to reproduce by building locally with sbuild in a trixie
schroot (succeeds) or a sid schroot (fails).

Looking at the diff between the packages installed in my build chroot for
testing and unstable (attached), my first guess would be that this could
have been triggered by the upgrade of python3-setuptools from 70 to 73.

smcv

Bug#1079499: gjs: autopkgtest regression in experimental: cannot find typelib for GjsTestTools, Regress, etc.

[Simon McVittie]

Source: gjs
Version: 1.81.2-2
Severity: serious
Justification: rc_policy.txt §6a
Tags: experimental

gjs is failing tests on ci.debian.net in experimental, e.g.:
https://ci.debian.net/packages/g/gjs/unstable/amd64/50788944/

This appears to be because many of the installed-tests can no longer find
their required typelibs, for example:

> 144s (process:3833): Gjs-CRITICAL **: 14:27:30.698: JS ERROR: Error: 
> Requiring GIMarshallingTests, version none: Typelib file for namespace 
> 'GIMarshallingTests' (any version) not found
> 144s @//usr/libexec/installed-tests/gjs/js/testExceptions.js:5:50

Perhaps /usr/libexec/installed-tests/gjs is no longer getting added to
the search path as intended?

smcv

Bug#1074727: Request for IkiWiki NMU (FTBFS #1074727)

[Simon McVittie]

On Sat, 17 Aug 2024 at 16:14:52 +0100, Simon McVittie wrote:
> Utkarsh Gupta said elsewhere that they would (also) NMU, so I'm going to
> let them handle this instead

I waited 1 day, I don't see a NMU uploaded or in the deferred queue,
so I'm going to continue with preparing and testing my own.

smcv

Bug#1074727: Request for IkiWiki NMU (FTBFS #1074727)

[Simon McVittie]

On Sat, 17 Aug 2024 at 13:21:20 +0100, Simon McVittie wrote:
> On Sat, 17 Aug 2024 at 13:13:51 +0100, Jonathan Dowland wrote:
> > intrigeri's patch at
> > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074727#22>
> > looks good to me (eyeball test only)
> > 
> > I would be very grateful if someone would be prepared to Debian-ize
> > it and NMU IkiWiki (due to be removed from testing this week); I am
> > not able to do any Debian work at the moment.
> 
> I used to maintain ikiwiki and I can step back in to NMU this.

Utkarsh Gupta said elsewhere that they would (also) NMU, so I'm going to
let them handle this instead (Utkarsh, if you're unable to NMU after all,
please let me know).

smcv

Bug#1074727: Request for IkiWiki NMU (FTBFS #1074727)

[Simon McVittie]

On Sat, 17 Aug 2024 at 13:13:51 +0100, Jonathan Dowland wrote:
> intrigeri's patch at
> 
> looks good to me (eyeball test only)
> 
> I would be very grateful if someone would be prepared to Debian-ize
> it and NMU IkiWiki (due to be removed from testing this week); I am
> not able to do any Debian work at the moment.

I used to maintain ikiwiki and I can step back in to NMU this.

smcv

Bug#1078359: mutter: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test -C /<>/obj-x86_64-linux-gnu --no-re

[Simon McVittie]

Control: block -1 by 1077800

On Sat, 10 Aug 2024 at 07:43:11 +0200, Lucas Nussbaum wrote:
> > *** BUG ***
> > In pixman_region32_init_rect: Invalid rectangle passed
> > Set a breakpoint on '_pixman_log_error' to debug
> > 
> > *** BUG ***
> > In pixman_region32_init_rect: Invalid rectangle passed
> > Set a breakpoint on '_pixman_log_error' to debug
> > 
> > Bail out! FATAL-CRITICAL: cogl_texture_2d_new_from_data: assertion 'data != 
> > NULL' failed

This looks very much like #1077800 which is an intermittent failure in
several tests, most commonly (but not always) basic-x11.

smcv

Bug#1068363: src:autopkgtest: test_copy_timeout skipped because it's dependent on speed of testbed

[Simon McVittie]

Control: severity -1 normal
Control: retitle -1 src:autopkgtest: test_copy_timeout skipped because it's 
dependent on speed of testbed
Control: tags -1 - pending

On Thu, 04 Apr 2024 at 10:08:29 +0200, Paul Gevers wrote:
> I looked at the results of the autopkgtest of your package. I noticed that
> it recently started to fail a lot on ppc64el.

On Thu, 04 Apr 2024 at 22:08:32 +0200, Paul Gevers wrote:
> The test is [copying] a huge file and expects the copy to
> fail because it should take longer. Well, with [/tmp on] tmpfs the
> autopktest inside
> the test passes and hence the outer test fails.

On Sun, 12 May 2024 at 08:59:18 +0200, Paul Gevers wrote:
> On 06-04-2024 9:58 p.m., Paul Gevers wrote:
> > Anyways, it looks like we could just lower the timeout to 1 second and
> > hope were fine for some time to come.
> 
> No. 1 second is *too short* for the PodmanRunner.test_copy_timeout test on
> salsa. So I'll just disable the test for now.

This was done in 5.35, making this bug non-RC. I'm retitling it and
leaving it open to represent the technical debt of missing test-suite
coverage, but I'm not really seeing any good way to test this particular
corner case: it's difficult to trigger a timeout during copying on-demand
without making the test vulnerable to timing out for an unrelated reason.

If other maintainers don't think this is worth having a bug open for,
please close it.

smcv

Bug#1033147: accountsservice: autopkgtest fails when using a bookworm kernel

[Simon McVittie]

On Thu, 08 Aug 2024 at 08:28:04 +0200, Paul Gevers wrote:
> Hi Simon,
> > The test failure I saw under a-v-podman is concerning, but probably
> > ought to be a separate bug report - and probably non-RC, since Debian's
> > production infrastructure is currently based on a-v-lxc (and ideally
> > a-v-qemu) only?
> 
> The good part on the ci.d.n
> side of things is that we have the capability to direct packages to a
> preferred (supported) backend, so if there are problems with podman, we
> could keep accountservice on lxc.

Or qemu, now that that's fixed (although not in a released autopkgtest yet).

smcv

Bug#1033147: accountsservice: autopkgtest fails when using a bookworm kernel

[Simon McVittie]

On Mon, 05 Aug 2024 at 00:43:06 +0100, Simon McVittie wrote:
> A sid lxc container in a bookworm VM (built with a-b-lxc from bookworm)
> doesn't currently start up at all for me

I reported that separately, as #1078165.

After resolving that by using autopkgtest(-virt-lxc) from
bookworm-backports, I cannot reproduce the accountsservice test failure
(in a sid lxc container on bookworm, built with a-b-lxc from bookworm).

accountsservice's relationship with policykit-1, combined with the timing
of Paul's bug report, makes me think that this could be #1050256
"AppArmor breaks locking non-fs Unix sockets" and its symptom #1042880
"systemd: service with PrivateNetwork=yes fails inside lxc container on
bookworm".

We now have at least two workarounds for those: as per
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050256#264>, systemd
falls back from PrivateNetwork=yes to PrivateNetwork=no if necessary;
and policykit-1 is also patched to turn off PrivateNetwork=yes (which
can probably be reverted, now that systemd has a workaround).
So I think that theory is consistent with why sid's accountsservice now
passes its autopkgtest when run in lxc on bookworm.

The test failure I saw under a-v-podman is concerning, but probably
ought to be a separate bug report - and probably non-RC, since Debian's
production infrastructure is currently based on a-v-lxc (and ideally
a-v-qemu) only?

smcv

Bug#1033147: accountsservice: autopkgtest fails when using a bookworm kernel

[Simon McVittie]

On Sat, 18 Mar 2023 at 07:17:34 +0100, Paul Gevers wrote:
> I ran the [accountsservice autopkgtest] (lxc backend, just
> like on ci.d.n) on my own laptop running bookworm and the test hangs
> like on the other architectures.

Some potentially interesting data points:

I can reproduce this (or something similar) with an a-v-podman container
(image built with a-b-podman --init=none) or an a-v-podman --init container
(image built with a-b-podman --init=systemd) on a sid kernel.

A sid lxc container in a bookworm VM (built with a-b-lxc from bookworm)
doesn't currently start up at all for me, so I cannot confirm or
deny whether that particular scenario passes or fails this test. I
think there's some orthogonal brokenness with a-b-lxc or a-v-lxc, not
involving accountsservice. (Wild guess: lxc-templates or a-b-lxc might
need updating to account for the /usr merge, or for formerly Essential
packages having become non-Essential; or recent sid systemd might need
Paride's recent await-boot.sh improvements.)

After working around #1072004 with
,
I *can't* reproduce this for accountsservice 22.08.8-6 from bookworm in
a bookworm qemu VM (a-b-qemu + a-v-qemu on sid), or in a bookworm lxc
container inside a bookworm qemu VM. I also can't reproduce this for
accountsservice 22.08.8-6.1 from sid, in a sid qemu VM.

I haven't yet tried lxc inside a non-bookworm VM, or sid's a-b-lxc and
a-v-lxc on bookworm. I'm reluctant to run lxc directly on my host system,
because unlike typical uses of podman, it's a privileged container
framework for which the motto is "containers don't contain".

smcv

Bug#1074657: accountsservice: FTBFS: AttributeError: 'TestAccountsServicePreExistingUser' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'?

[Simon McVittie]

Control: tags -1 + upstream fixed-upstream pending
Control: forwarded -1 
https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/142

On Tue, 02 Jul 2024 at 14:40:06 +0200, Lucas Nussbaum wrote:
> >   File 
> > "/<>/obj-x86_64-linux-gnu/../tests/test-libaccountsservice.py",
> >  line 118, in test_multiple_inflight_get_user_by_id_calls
> > self.assertEquals(user.get_user_name(), 'pizza')
> > ^
> > AttributeError: 'TestAccountsServicePreExistingUser' object has no 
> > attribute 'assertEquals'. Did you mean: 'assertEqual'?

This is a regression caused by Python 3.12 becoming the default version.
The deprecated method assertEquals() was removed:
https://docs.python.org/3/whatsnew/3.12.html#unittest-testcase-removed-aliases

This was fixed in upstream git a while ago, and I've pushed that change
to Salsa as a patch.

I didn't do a team upload with that fix, because I don't yet have a
solution to the other RC bugs involving autopkgtest failures (#1033147,
#1034257).

smcv

Bug#1075708: zsh: FTBFS with GCC-14

[Simon McVittie]

Control: tags -1 + patch

On Sat, 03 Aug 2024 at 17:56:30 +0100, Simon McVittie wrote:
> Unfortunately, while [the patch I sent earlier] fixes the issue that
> Matthias reported, it
> doesn't seem to be a complete solution to making zsh build successfully:
> there are at least two other reasons why it fails to build from source
> with `debuild -B`, described below.

> Hang during build-time tests

> missing files: obj/Src/Modules/*.h

Applying the attached patch, in addition to the one I sent earlier, seems
to be enough to get a successful build on a porterbox by fixing both of
the new issues that I mentioned.

This is from upstream, but I found it by looking at Arch Linux's patchset;
thanks are due to Christian Hesse, one of Arch's zsh maintainers.

I believe both
52383-Avoid-incompatible-pointer-types-in-terminfo-global.patch
(commit ab4d62eb975a4c4c51dd35822665050e2ddc6918 upstream) and
50641-use-int-main-in-test-C-codes-in-configure.patch
(commit 4c89849c98172c951a9def3690e8647dae76308f upstream)
are necessary.

smcv
From: Nicholas Vinson 
Date: Wed, 21 Sep 2022 09:22:11 +0900
Subject: 50641: use 'int main()' in test C-codes in configure

Origin: upstream, commit:ab4d62eb975a4c4c51dd35822665050e2ddc6918
Bug-Debian: https://bugs.debian.org/1075708
---
 aczsh.m4 | 64 -
 configure.ac | 94 ++--
 2 files changed, 72 insertions(+), 86 deletions(-)

diff --git a/aczsh.m4 b/aczsh.m4
index d2a47ba..27cc260 100644
--- a/aczsh.m4
+++ b/aczsh.m4
@@ -44,6 +44,7 @@ AC_DEFUN(zsh_64_BIT_TYPE,
 #include 
 #endif
 
+int
 main()
 {
   $1 foo = 0; 
@@ -118,7 +119,6 @@ AC_TRY_COMMAND($DLLD -o conftest1.$DL_EXT $LDFLAGS $DLLDFLAGS conftest1.o $LIBS
 AC_TRY_COMMAND($CC -c $CFLAGS $CPPFLAGS $DLCFLAGS conftest2.c 1>&AS_MESSAGE_LOG_FD) &&
 AC_TRY_COMMAND($DLLD -o conftest2.$DL_EXT $LDFLAGS $DLLDFLAGS conftest2.o $LIBS 1>&AS_MESSAGE_LOG_FD); then
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
-#include 
 #ifdef HPUX10DYNAMIC
 #include 
 #define RTLD_LAZY BIND_DEFERRED
@@ -146,29 +146,30 @@ char *zsh_gl_sym_addr ;
 #define RTLD_GLOBAL 0
 #endif
 
+int
 main()
 {
 void *handle1, *handle2;
 void *(*zsh_getaddr1)(), *(*zsh_getaddr2)();
 void *sym1, *sym2;
 handle1 = dlopen("./conftest1.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle1) exit(1);
+if(!handle1) return(1);
 handle2 = dlopen("./conftest2.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle2) exit(1);
+if(!handle2) return(1);
 zsh_getaddr1 = (void *(*)()) dlsym(handle1, "${us}zsh_getaddr1");
 zsh_getaddr2 = (void *(*)()) dlsym(handle2, "${us}zsh_getaddr2");
 sym1 = zsh_getaddr1();
 sym2 = zsh_getaddr2();
-if(!sym1 || !sym2) exit(1);
-if(sym1 != sym2) exit(1);
+if(!sym1 || !sym2) return(1);
+if(sym1 != sym2) return(1);
 dlclose(handle1);
 handle1 = dlopen("./conftest1.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle1) exit(1);
+if(!handle1) return(1);
 zsh_getaddr1 = (void *(*)()) dlsym(handle1, "${us}zsh_getaddr1");
 sym1 = zsh_getaddr1();
-if(!sym1) exit(1);
-if(sym1 != sym2) exit(1);
-exit(0);
+if(!sym1) return(1);
+if(sym1 != sym2) return(1);
+return(0);
 }
 ]])],[zsh_cv_shared_$1=yes],
 [zsh_cv_shared_$1=no],
@@ -200,7 +201,6 @@ AC_TRY_COMMAND($DLLD -o conftest1.$DL_EXT $LDFLAGS $DLLDFLAGS conftest1.o $LIBS
 AC_TRY_COMMAND($CC -c $CFLAGS $CPPFLAGS $DLCFLAGS conftest2.c 1>&AS_MESSAGE_LOG_FD) &&
 AC_TRY_COMMAND($DLLD -o conftest2.$DL_EXT $LDFLAGS $DLLDFLAGS conftest2.o $LIBS 1>&AS_MESSAGE_LOG_FD); then
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
-#include 
 #ifdef HPUX10DYNAMIC
 #include 
 #define RTLD_LAZY BIND_DEFERRED
@@ -228,19 +228,19 @@ char *zsh_gl_sym_addr ;
 #define RTLD_GLOBAL 0
 #endif
 
-
+int
 main()
 {
 void *handle1, *handle2;
 int (*fred1)(), (*fred2)();
 handle1 = dlopen("./conftest1.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle1) exit(1);
+if(!handle1) return(1);
 handle2 = dlopen("./conftest2.$DL_EXT", RTLD_LAZY | RTLD_GLOBAL);
-if(!handle2) exit(1);
+if(!handle2) return(1);
 fred1 = (int (*)()) dlsym(handle1, "${us}fred");
 fred2 = (int (*)()) dlsym(handle2, "${us}fred");
-if(!fred1 || !fred2) exit(1);
-exit((*fred1)() != 42 || (*fred2)() != 69);
+if(!fred1 || !fred2) return(1);
+return((*fred1)() != 42 || (*fred2)() != 69);
 }
 ]])],[zsh_cv_sys_dynamic_clash_ok=yes],
 [zsh_cv_sys_dynamic_clash_ok=no],
@@ -276,7 +276,6 @@ AC_TRY_COMMAND($DLLD -o conftest1.$DL_EXT $LDFLAGS $DLLDFLAGS conftest1.o $LIBS
 AC_TRY_COMMAND($CC -c $CFLAGS $CPPFLAGS $DLCFLAGS conftest2.c 1>&AS_MESSAGE_LOG_FD) &&
 AC_TRY_COMMAND($DLLD -o conftest2.$DL_EXT $LDFLAGS $DLLDFLAGS conftest2.o $LIBS 1>&AS_MESSAGE_LOG_FD

Bug#1075708: zsh: FTBFS with GCC-14

[Simon McVittie]

On Wed, 03 Jul 2024 at 12:50:04 +, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-14/g++-14, but succeeds to build with gcc-13/g++-13.
...
> ../../../Src/Modules/termcap.c:45:14: error: conflicting types for 
> ‘boolcodes’; have ‘char *[]’
>45 | static char *boolcodes[] = {
>   |  ^
> In file included from ../../Src/zshterm.h:1,
>  from ../../../Src/zsh_system.h:932,
>  from ./../../Src/zsh.mdh:15,
>  from ./termcap.mdh:15,
>  from ../../../Src/Modules/termcap.c:38:
> /usr/include/term.h:783:56: note: previous declaration of ‘boolcodes’ with 
> type ‘const char * const[]’
>   783 | extern NCURSES_EXPORT_VAR(NCURSES_CONST char * const ) boolcodes[];
>   |^

Please consider applying the attached patch, taken from upstream git.
gcc 14 also produces several compiler warnings which I think would be
useful to look into, but those don't break the build and hopefully don't
indicate serious bugs.

I tried compiling this in my usual build environment (sbuild inside
an amd64 Debian 12 VM) and on the amd64 porterbox barriere, and the
dh_auto_build step finishes successfully.

Unfortunately, while this patch fixes the issue that Matthias reported, it
doesn't seem to be a complete solution to making zsh build successfully:
there are at least two other reasons why it fails to build from source
with `debuild -B`, described below.

`debuild -A` (Architecture: all only) does succeed with the attached
patch.

Hang during build-time tests


During dh_auto_test, the test hangs for a significant time, with no
obvious CPU load, and this output:

>debian/rules override_dh_auto_test-arch
> make[1]: Entering directory '/home/smcv/zsh'
> if dpkg-architecture -qDEB_BUILD_ARCH_OS | grep -qv hurd; then \
> HOME="/home/smcv/zsh/obj/testhome" ZTST_verbose=1 dh_auto_test -B 
> obj; \
> fi
> cd obj && make -j4 test "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1
> make[2]: Entering directory '/home/smcv/zsh/obj'
> cd Test ; make check
> make[3]: Entering directory '/home/smcv/zsh/obj/Test'
> if test -n "ld"; then \
>   cd .. && DESTDIR= \
>   make MODDIR=`pwd`/Test/Modules install.modules > /dev/null; \
> fi
> if test -z "$ZTST_handler"; then \
>   ZTST_handler=runtests.zsh; \
> fi; \
> if ZTST_testlist="`for f in ../../Test/*.ztst; \
>do echo $f; done`" \
>  ZTST_srcdir="../../Test" \
>  ZTST_exe=../Src/zsh \
>  ../Src/zsh +Z -f ../../Test/$ZTST_handler; then \
>  stat=0; \
> else \
>  stat=1; \
> fi; \
> sleep 1; \
> rm -rf Modules .zcompdump; \
> exit $stat
> ../../Test/A01grammar.ztst: starting.
> Running test: Test skipping if ZTST_test_skip is set

This is reproducible on barriere.

I see that there is already a patch applied,
debian/patches/further-mitigate-test-suite-hangs.patch.
Perhaps it will be necessary to further further mitigate test-suite hangs...

Or perhaps the affected tests could be skipped without harming coverage
too much?

missing files: obj/Src/Modules/*.h
==

If I skip the build-time tests with DEB_BUILD_OPTIONS=nocheck, instead
I get this build failure:

>dh_install
> dh_install: warning: Cannot find (any matches for) "obj/Src/Modules/*.h" 
> (tried in ., debian/tmp)
>
> dh_install: warning: zsh-dev missing files: obj/Src/Modules/*.h
> dh_install: error: missing files, aborting

This is also reproducible on barriere. I don't know what has changed to
stop these headers from being generated.

I'm sorry I couldn't fully fix the build of this package, but I hope the
patch I attached is a useful step in the right direction.

smcv
From: Florian Weimer 
Date: Fri, 8 Dec 2023 21:58:07 +0100
Subject: 52383: Avoid incompatible pointer types in terminfo global variable
 checks

Origin: upstream, commit:https://sourceforge.net/p/zsh/code/ci/4c89849c98172c951a9def3690e8647dae76308f/
Bug-Debian: https://bugs.debian.org/1075708
---
 configure.ac | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index f810052..928b467 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1771,27 +1771,27 @@ if test x$zsh_cv_path_term_header != xnone; then
   fi
 
   AC_MSG_CHECKING(if boolcodes is available)
-  AC_LINK_IFELSE([AC_LANG_PROGRAM([[$term_includes]], [[char **test = boolcodes; puts(*test);]])],[AC_DEFINE(HAVE_BOOLCODES) boolcodes=yes],[boolcodes=no])
+  AC_LINK_IFELSE([AC_LANG_PROGRAM([[$term_includes]], [[char **test = (char **)boolcodes; puts(*test);]])],[AC_DEFINE(HAVE_BOOLCODES) boolcodes=yes],[boolcodes=no])
   AC_MSG_RESULT($boolcodes)
 
   AC_MSG_CHECKING(if numcodes is available)
-  AC_LINK_IFELSE([AC_LANG_PROGRAM([[$term_includes]], [[char **test = numcodes; puts(*test);]])],[AC_DEFINE(HAVE_NUMCODES) numcodes=yes],[numcodes=no])
+  AC_LINK_IFELSE([AC_LANG_PROGRAM([[$term

Bug#1077846: rust-gdk4: autopkgtest regression: cannot find function `gdk_display_get_dmabuf_formats` in crate `ffi`

[Simon McVittie]

Source: rust-gdk4
Version: 0.8.2-6
Severity: serious
Justification: https://release.debian.org/testing/rc_policy.txt 6a
User: debian...@lists.debian.org
Usertags: needs-update

rust-gdk4 is failing tests on ci.debian.net, with lots of errors like:

343s error[E0425]: cannot find function `gdk_display_get_dmabuf_formats` in 
crate `ffi`
343s --> src/auto/display.rs:129:33
343s  |
343s 129  | 
from_glib_none(ffi::gdk_display_get_dmabuf_formats(self.as_ref().to_glib_none().0))
343s  | ^^ 
help: a function with a similar name exists: `gdk_display_get_default_seat`
343s  |
343s ::: /usr/share/cargo/registry/gdk4-sys-0.8.2/src/lib.rs:4105:5

This is building against librust-gdk4-sys-dev 0.8.2-4 in the
autopkgtest environment. Does it perhaps need a versioned dependency on
librust-gdk4-sys-dev (>= 0.8.2-7) to get access to GTK 4.14.x features?

When testing a proposed migration, ci.debian.net takes all dependencies
from testing, unless a versioned dependency explicitly requires the
version from unstable. In this case the versioned dependency on GTK 4
means we get that from unstable:

 17s Get:167 http://deb.debian.org/debian unstable/main amd64 libgtk-4-common 
all 4.14.4+ds-8 [2,490 kB]
 17s Get:168 http://deb.debian.org/debian unstable/main amd64 libgtk-4-1 amd64 
4.14.4+ds-8 [3,109 kB]
 18s Get:169 http://deb.debian.org/debian unstable/main amd64 gir1.2-gtk-4.0 
amd64 4.14.4+ds-8 [212 kB]
 ...
 19s Get:298 http://deb.debian.org/debian unstable/main amd64 libgtk-4-dev 
amd64 4.14.4+ds-8 [981 kB]

and obviously we get the package under test from unstable, too:

 21s Get:425 http://deb.debian.org/debian unstable/main amd64 librust-gdk4-dev 
amd64 0.8.2-6 [72.5 kB]

but everything else comes from testing.

If a new gtk4 upload is needed for some other reason before this all
migrates, we might also want to give it a Breaks on
librust-gdk4-dev (<< 0.8.2-6~), librust-gdk4-sys-dev (<< 0.8.2-7~)
to stop the testing migration infrastructure from wasting its time
testing the new GTK against the old Rust bindings (which we already know
doesn't work).

smcv

Bug#1077299: git: Not migrating to testing for long time due to autopkgtest results

[Simon McVittie]

Control: block -1 by 1076751 1076750

On Sun, 28 Jul 2024 at 07:50:26 +0200, Salvatore Bonaccorso wrote:
>   • Issues preventing migration:
>   □ autopkgtest for ikiwiki-hosting/0.20220716-2: amd64: Regression

This is #1076751, for which the root cause is #1076750 in which I asked the
git maintainers for advice on how to proceed.

Obviously git is more important than ikiwiki-hosting, so if the
release/security teams would prefer to push git into testing and break
ikiwiki-hosting, I believe removing ikiwiki-hosting from testing or
ignoring its autopkgtest regression would work.

ikiwiki-hosting is up for removal on 2024-08-21 anyway.

I am the current maintainer of ikiwiki-hosting, but I intend to orphan
it in the next upload if it isn't adopted, and the amount of time I can
spend on it is limited.

smcv

Bug#1077757: gtk4: memorytexture test fails on s390x

[Simon McVittie]

Control: retitle -1 gtk4: memorytexture test fails on s390x
Control: severity -1 important

I mitigated this in 4.14.4+ds-8 by skipping the memorytexture test during
autopkgtest as well as during build-time testing, so I'm downgrading this
to important.

On Thu, 01 Aug 2024 at 10:15:11 -0400, Jeremy Bícha wrote:
> There were several upstream fixes to the memorytexture test in June
> and July that aren't in our gtk 4.14.4
> 
> https://gitlab.gnome.org/GNOME/gtk/-/commits/main/testsuite/gdk/memorytexture.c

If you're going to update to 4.15.x in experimental soon *anyway*, then
that could be a good opportunity to find out whether the memorytexture
test might have been fixed on s390x (again). Sorry, but I have already put
more time than I can justify into repeatedly building GTK on porterboxes
in the last couple of weeks, so I am probably not going to chase this
any time soon.

I believe the situation is that it failed in 4.12.x, was fixed in 4.12.x,
was fixed differently in 4.13.x, and then regressed in 4.14.x? Or
something like that?

I'm 95% sure this is because s390x is big-endian and nobody except
us is routinely testing (or even building) GTK on big-endian systems.
Probably one of the mappings between different libraries' colour channel
layouts (GTK, Cairo, OpenGL, Vulkan, ...) is mixing up "first byte is red"
with "least significant 8 bits are red", or similar.

There have been endianness issues in the past that turned out to be a
regression in lower-level libraries like libpixman, so we can't necessarily
be sure that this is really a GTK bug.

> We do have a patch,
> debian/tests-Mark-memorytexture-as-expected-to-fail-on-big-endian.patch
> I'm unsure about the significance: did this test actually pass on
> s390x in 4.12 and then began failing again in 4.14?

Yes. Sebastien Bacher disabled this test in 4.14.4+ds-3
"mark also memorytexture as expected to fail on big endian", without
any reference to a Debian or upstream bug; let's use this bug to
represent that failure.

> gdk/memorytexture.test passes in installed-tests-wayland but not in
> installed-tests-x11

That's perhaps interesting input for someone who understands the finer
points of OpenGL, but I'm sorry, that's not me.

smcv

Bug#1077741: rust-gdk4-sys: autopkgtest regression with GTK 4.14

[Simon McVittie]

Source: rust-gdk4-sys
Version: 0.8.2-4
Severity: serious
Tags: trixie sid
Justification: https://release.debian.org/testing/rc_policy.txt §6a
X-Debbugs-Cc: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update

rust-gdk4-sys is failing its autopkgtest with the recently-uploaded
GTK 4.14:

> 219s  cross_validate_constants_with_c stdout 
> 219s Constant value mismatch for (gint) GDK_MEMORY_N_FORMATS
> 219s Rust: "28"
> 219s C:"33"

It presumably needs to be updated in unstable. The version in experimental
is probably suitable, and might just need a re-upload to unstable?

Thanks,
smcv

Bug#1074971: marked as pending in fteqcc

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1074971 in fteqcc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/fteqcc/-/commit/fb376e762f44003cf36c5c7d70f54e879ead9a30


Add patch to fix FTBFS with gcc 14

Closes: #1074971


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1074971

Bug#1077690: gtk4: intended CFLAGS/LDFLAGS no longer set, leading to test failures and FTBFS on i386

[Simon McVittie]

On Thu, 01 Aug 2024 at 01:47:57 +0300, Adrian Bunk wrote:
> Sorry, I got that backwards.
> 
> LDFLAGS were missing with dpkg 1.22.9 in gtk4 4.14.4+ds-4 but are now back.

OK, that's consistent with the log I was looking at. None of gtk4's extra
LDFLAGS are actually critical to the build, so it isn't surprising that
we wouldn't notice they weren't being applied.

> What works with both versions is
>   -DEB_CFLAGS_MAINT_APPEND = -ffloat-store
>   +export DEB_CFLAGS_MAINT_APPEND = -ffloat-store

Thanks, I'll try that when it isn't on the critical path for other packages.

smcv

Bug#1077690: marked as pending in gtk4

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1077690 in gtk4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gtk4/-/commit/1a46546210d73c0c523ed32070c6d3e3b4a68247


d/rules: Append to CFLAGS for i386 the same way we append to LDFLAGS

Using DEB_CFLAGS_MAINT_APPEND here worked a few days ago, but does not
seem to work now, possibly affected by the changes in dpkg 1.22.10.

Closes: #1077690


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1077690

Bug#1077690: gtk4: intended CFLAGS/LDFLAGS no longer set, leading to test failures and FTBFS on i386

[Simon McVittie]

On Wed, 31 Jul 2024 at 23:02:31 +0100, Simon McVittie wrote:
> On Thu, 01 Aug 2024 at 00:19:45 +0300, Adrian Bunk wrote:
> > Comparing build logs the "-Wl,-z,defs -Wl,-O1" is also gone
> > (not only on i386)

Are you sure those LDFLAGS are missing? I can see the -Wl,-O1 showing up
in the build log when Meson links libraries and executables (search for
"cc  -o", with two spaces; I checked the amd64 and i386 logs).

(The -Wl,-z,defs is also there, but that isn't necessarily useful evidence
because the upstream build system also adds it.)

It's possible that it's missing when g-ir-scanner links its "dumper", but
that isn't actually important anyway, because it's run once to parse its
output and then thrown away - it isn't installed.

I think the difference is that I tried to add the CFLAGS for i386 the "new"
way, via DEB_CFLAGS_MAINT_APPEND, but the LDFLAGS are set the "old" way,
by importing dpkg's default.mk and then appending with "LDFLAGS += ...".

As I said, this worked at the weekend (including the addition of
-ffloat-store on i386), so it must be something that changed rather
recently.

Bug#1077690: gtk4: intended CFLAGS/LDFLAGS no longer set, leading to test failures and FTBFS on i386

[Simon McVittie]

Source: gtk4
Version: 4.14.4-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: Adrian Bunk 

(Redirecting from a reply to #1077675 since this is a different bug)

On Thu, 01 Aug 2024 at 00:19:45 +0300, Adrian Bunk wrote:
> On Wed, Jul 31, 2024 at 08:56:55PM +0100, Simon McVittie wrote:
> >,,,
> > The good news is that this seems to be the only test failure, on all the
> > architectures that have been attempted so far.
> 
> The bad news is that this is not true on i386,
> apparently the -ffloat-store is gone there.
> 
> Comparing build logs the "-Wl,-z,defs -Wl,-O1" is also gone
> (not only on i386), so I'd suspect some of the recent dpkg
> changes in that area might have broken LDFLAGS/CFLAGS setting?

I think this must be the case. I built 4.14.4-4 successfully for i386 while
testing the -ffloat-store change, so it must be a very recent change
(since the weekend) that made it regress.

Perhaps debian/rules will need some reordering so that it gets the
architectures from architecture.mk, then uses those to find out whether
we are on i386, then sets DEB_CFLAGS_MAINT_APPEND (on i386) and
DEB_LDFLAGS_MAINT_APPEND (everywhere), and finally includes the rest of
default.mk so the build flags are set up?

If a dpkg-dev change can make our intended CFLAGS and LDFLAGS go from
"works fine" to "silently ignored", that feels uncomfortably fragile.

smcv

Bug#1077675: gtk4: FTBFS: gtk / notify test fails: gtk_calendar_set_month: assertion 'date != NULL' failed

[Simon McVittie]

Source: gtk4
Version: 4.14.4-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The new version of gtk4 in unstable failed to build on all architectures
so far:

> == 140/668 ===
> test: gtk:gtk / notify
...
> ok 204 /Notification/GtkButton
> ok 205 /Notification/GtkButtonsType
> not ok /Notification/GtkCalendar - Gtk-FATAL-CRITICAL: 
> gtk_calendar_set_month: assertion 'date != NULL' failed

I don't know why 4.14.4-5 is failing now, when 4.14.4-4 (which was
basically the same) built successfully and passed tests in experimental.

The good news is that this seems to be the only test failure, on all the
architectures that have been attempted so far.

smcv

Bug#1077178: gtk4: reftest failure in label-shadows.ui on mips64el and riscv64 mips64el

[Simon McVittie]

Control: reopen -1 4.14.4+ds-3
Control: found -1 4.14.4+ds-4
Control: severity -1 important

On Fri, 26 Jul 2024 at 14:56:10 +0100, Simon McVittie wrote:
> After a version with a workaround like that has been uploaded and built
> successfully on mips64el and riscv64, we can downgrade this bug to a
> non-RC severity.

I mistakenly closed the bug in the changelog, but it was only mitigated
and not really fixed. Reopening and downgrading to non-RC now.

smcv

Bug#1077287: marked as pending in gtk4

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1077287 in gtk4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gtk4/-/commit/1a7127b19938d260c750e3ae125aac847e95bbf1


Depend on libgles2

This is used by default since 4.14. It isn't strictly mandatory because
another backend can be chosen via environment variables, but the
failure mode if it is missing is very bad (applications crash) so it
seems proportionate to make it a Depends.

Closes: #1077287


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1077287

Bug#1077287: libgtk-4-1 v4.14: missing dependency on libgles2 (maybe there are alternatives) on at least i386

[Simon McVittie]

Package: libgtk-4-1
Version: 4.14.4+ds-3
Severity: serious
Justification: a maintainer says so
Tags: experimental
Control: block 1072395 by -1

While investigating test failures on i386, I tried installing
gtk-4-examples:i386 and its mandatory dependencies onto an amd64 GNOME
unstable system to assess whether the test failures reflect a serious
problem with applications or are ignorable.

(Full disclosure: I was actually testing with a prerelease of 4.14.4+ds-4;
but I suspect that 4.14.4+ds-3 has the same problem, and anyway it
definitely has other RC bugs.)

When I run gtk4-widget-factory, I get:

> Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: 
> No such file or directory
> zsh: IOT instruction  gtk4-widget-factory

After installing libgles2:i386, gtk4-widget-factory runs successfully
and seems to work OK.

I already had libegl1:i386, libgl1:i386 and mesa-vulkan-drivers:i386
installed, so those are presumably not sufficient; but perhaps I was
missing some other related package that made "big GL" or Vulkan backends
not work?

Or maybe libgtk-4-1 needs to depend on libgles2, either on some or all
architectures?

I have not kept up with the status of which backend is used under which
circumstances, so I don't know the correct solution.

On the affected test system I'm using GNOME in Wayland mode on an Intel
GPU, if it matters.

smcv

Bug#1077192: marked as pending in gtk4

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1077192 in gtk4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gtk4/-/commit/63e31a9d63201c7f6fcd07a980e4ab160e6d67b3


d/patches: Align GskPath points to an 8-byte boundary where necessary

GSK internally uses `gskpathop`, a compressed encoding of a path
operation where the 3 low-order bits of a pointer are used to encode
the type. This only works if the pointers can be guaranteed to be
8-byte-aligned, which is not the case on at least s390x and i386.

Closes: #1077192


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1077192

Bug#1077181: gtk4: FTBFS on riscv64: a11y/text, a11y/textview tests segfault

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/-/issues/6490
Control: tags -1 + pending

On Fri, 26 Jul 2024 at 15:55:15 +0100, Simon McVittie wrote:
> This might be related to https://gitlab.gnome.org/GNOME/gtk/-/issues/6490
> which reported that these same tests were segfaulting on Ubuntu armhf and
> i386.

Yes, this is indeed the same issue. It turns out to be a signal handler
signature mismatch, so I have no idea how why worked on amd64...

Fix proposed in https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7504
and pushed to debian/latest, also dropping the patch that previously
skipped these two tests on i386.

smcv

Bug#1077181: marked as pending in gtk4

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1077181 in gtk4 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gtk4/-/commit/490bcaee93502a95afb54d503d543ea8e064746b


Add patch to fix a11y/text, a11y/textview tests instead of skipping them

Closes: #1077181


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1077181

Bug#1077181: gtk4: FTBFS on riscv64: a11y/text, a11y/textview tests segfault

[Simon McVittie]

On Fri, 26 Jul 2024 at 15:55:17 +0100, Simon McVittie wrote:
> On Fri, 26 Jul 2024 at 14:48:36 +0100, Simon McVittie wrote:
> > On Fri, 26 Jul 2024 at 14:53:03 +0200, Matthias Geiger wrote:
> > > The a11y tests just seem to segfault:
> > > 
> > > 478/668 gtk:a11y / text   
> > >ERROR 0.73s   killed by signal 11 SIGSEGV
> > > 
> > > 479/668 gtk:a11y / textview   
> > >ERROR 0.71s   killed by signal 11 SIGSEGV

I can (eventually!) reproduce this on the riscv64 porterbox, ricci.
I'll try to get a backtrace later.

smcv

Bug#1077181: gtk4: FTBFS on riscv64: a11y/text, a11y/textview tests segfault

[Simon McVittie]

On Fri, 26 Jul 2024 at 14:48:36 +0100, Simon McVittie wrote:
> On Fri, 26 Jul 2024 at 14:53:03 +0200, Matthias Geiger wrote:
> > The a11y tests just seem to segfault:
> > 
> > 478/668 gtk:a11y / text 
> >  ERROR 0.73s   killed by signal 11 SIGSEGV
> > 
> > 479/668 gtk:a11y / textview 
> >  ERROR 0.71s   killed by signal 11 SIGSEGV

This might be related to https://gitlab.gnome.org/GNOME/gtk/-/issues/6490
which reported that these same tests were segfaulting on Ubuntu armhf and
i386. debian/patches/debian/ignore_a11ytext_i386.patch marks these tests
to be skipped on i386, but no further diagnosis appears to have been done.

The obvious next step here is for someone to run those tests and get a
backtrace, and see whether it's (a) reproducible, and (b) the same on i386
and riscv64.

Note that as noted on the upstream issue, these tests require special
environment variables to be set, and are expected to crash otherwise
(but that is not a bug).

smcv

Bug#1076751: ikiwiki-hosting: autopkgtest regression with git 2.45.2: dubious ownership in repository at '/var/lib/ikiwiki-hosting-web/git/foo.example.com.git'

[Simon McVittie]

Source: ikiwiki-hosting
Version: 0.20220716-2
Severity: serious
Tags: upstream trixie sid
Justification: https://release.debian.org/testing/rc_policy.txt §6a
X-Debbugs-Cc: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update

As reported (eventually) in
,
ikiwiki-hosting's autopkgtest is failing with git >= 2.45 as a result
of new restrictions on reading other uids' git repositories.

The root cause of this appears to be .
ikiwiki-hosting-web runs an instance of git-daemon(1) as uid 'ikiwiki-anon'
to serve user-generated content that is owned by other uids, and
git-daemon(1) no longer allows this by default. This is a genuine
regression in ikiwiki-hosting-web that was detected by its autopkgtest,
and not just a test issue.

I asked the git maintainers on #1076750 whether this was an intentional
behaviour change for git-daemon(1), which I had expected might have been
special-cased to be unaffected by this hardening because exporting git
repositories that it doesn't own is its whole purpose.

A crude solution would be for ikiwiki-hosting to write

[safe]
directory=*

into /var/lib/ikiwiki-hosting-web/git/.gitconfig, which happens to be
~/.gitconfig for the ikiwiki-anon user. I'm hoping that git maintainers
can suggest a better version of this, but unfortunately the first thing
I tried,

[safe]
directory=/var/lib/ikiwiki-hosting-web/git/*

does not work.

I do not consider the workaround proposed in

to be a valid solution to this issue.

ikiwiki-hosting is a less important package than git, so I'm reporting this
as a RC bug in ikiwiki-hosting so that it will eventually get autoremoved,
hopefully allowing git to migrate.

smcv

Bug#1071329: marked as pending in meson-python

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1071329 in meson-python reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/meson-python/-/commit/ae823cedfb62a556bfd604a97a396ed5aa90675b


Add patch from upstream to fix test failures with updated pyproject-metadata

Closes: #1071329


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1071329

Bug#1072467: marked as pending in pysdl2

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1072467 in pysdl2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/pysdl2/-/commit/fbc7f0bfd1969277217277287c62c889218e245a


Drop build-dependency on transitional libgl1-mesa-glx

Closes: #1072467


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1072467

Bug#1074727: ikiwiki: FTBFS: t/po.t: msgfmt: input file doesn't contain a header entry with a charset specification

[Simon McVittie]

Control: retitle -1 ikiwiki: FTBFS: t/po.t: msgfmt: input file doesn't contain 
a header entry with a charset specification

On Tue, 02 Jul 2024 at 15:19:37 +0200, Lucas Nussbaum wrote:
> > Test Summary Report
> > ---
> > t/po.t   (Wstat: 256 (exited 1) Tests: 114 Failed: 0)
> >   Non-zero exit status: 1
> >   Parse errors: No plan found in TAP output

The actual error message here appears to be this:

> Invalid po file /tmp/ikiwiki-po-filter-in.45fFpXdrCQ:
> msgfmt: input file doesn't contain a header entry with a charset specification
>
> # Tests were run but no plan was declared and done_testing() was not seen.

This could be a bug in ikiwiki, or it could be a regression or behaviour
change in some other component, like perhaps po4a or the gettext toolchain.
Possibly related to (but not the same issue as) #1072760.

I can reproduce a similar failure by rebuilding ikiwiki for unstable in
sbuild (in a Debian 12 VM).

I see that intrigeri has been the main author of the po plugin: perhaps
they can make this plugin work again?

If that isn't possible, it might be proportionate to disable the po plugin
and disable its test coverage, so that at least the other parts of ikiwiki
can remain usable.

smcv

Bug#1052108: transition: mutter/gnome-shell 46

[Simon McVittie]

On Fri, 19 Jul 2024 at 05:13:31 +0100, Sid T wrote:
> Note. The gnome-shell-extension-system-monitor (which is from [1]https://
> github.com/paradoxxxzero/gnome-shell-system-monitor-applet/issues/767) is kind
> of abandoned.
> 
> The original author (paradoxxxzero) was not responding much for a long time,
> and other dev contributions kept it alive. Since there was no response from 
> the
> original author, development kind of moved to its fork at [2]https://
> extensions.gnome.org/extension/3010/system-monitor-next/. Though the fork was
> started by "mgalgs" (who was contributing to upstream as well) as a stop gap
> measure, the fork gained traction and more users started using it. So,
> atm "mgalgs" is actively maintaining the fork. I've been using it for months
> without any issues.
> 
> Though the original author (paradoxxxzero) made some initiative to revive his
> repo, it was too late. Refer [3]https://github.com/paradoxxxzero/
> gnome-shell-system-monitor-applet/issues/767#issuecomment-1819485628.

This is all useful information for #1052108, but at this point it's
too late to resolve that before starting the GNOME Shell 46 transition,
so the requested short-term action for this particular package is for
the release team to remove it from testing and move on.

If someone (perhaps you?) wants to resurrect the
gnome-shell-extension-system-monitor package by switching its upstream
to a more-maintained fork, that can still happen after the transition
goes through, as long as someone keeps it up-to-date with versions required
for the current GNOME Shell in the future.

Thanks,
smcv

Bug#1075811: autokey-qt can be installed but will nor run

[Simon McVittie]

Control: reassign -1 python3-pyinotify 0.9.6-2
Control: affects -1 + autokey-common

On Fri, 05 Jul 2024 at 16:25:30 +0100, Joe wrote:
> joe@jrenewsid:~$ autokey-qt
> Traceback (most recent call last):
...
> File "/usr/lib/python3/dist-packages/pyinotify.py", line
> 71, in 
> import asyncore
> ModuleNotFoundError: No module named 'asyncore'

This is a bug in pyinotify rather than in autokey-qt (a duplicate of
#1075939, see also #1040102).

> Is there a workaround?

According to #1040102, `apt install python3-pyasyncore` should work
around this.

smcv

Bug#1073788: gimp: whole-system froze when adjusting threshold

[Simon McVittie]

Control: reassign -1 sway 1.7-6
Control: retitle -1 sway: whole system froze when adjusting threshold in gimp

On Tue, 18 Jun 2024 at 13:13:44 +0200, Manny wrote:
> As soon as the slider is moved, *both* screens on a dual headed
> machine go black for ~1½ seconds then pop back on. GIMP is only ever
> present one of the two displays, never spread out. On one occassion,
> the system froze for a few seconds before the cursor could move
> again. On another occasion, the keyboard and mouse were permanently
> frozen. I walked away from the machine for ~5 minutes or so to give it
> time to unfreeze, but it never unfroze. I was ultimately forced to
> physically force a power down of the whole system. It would have been
> catastrophic if I had unsaved work in any application.

It should not be possible for GIMP to achieve this sort of freeze of
the compositor even if it wanted to, so I'm reassigning this to sway
(I've assumed that you're using the version of sway from Debian 12,
please correct the version metadata if that's wrong).

Please check for messages in the systemd journal at the time of this
freeze - I suspect you will see some sort of warning or error from
sway, Xwayland and/or the kernel.

> There is also a security problem here. In principle, what if a user
> were to leave GIMP to enter a password in another app?  GIMP should
> not have access to the keyboard when it is not in focus. This security
> flaw is not in GIMP, but rather in Wayland or Sway and GIMP is merely
> demonstrating how an unfocused app can eavesdrop on the keystrokes.

If the compositor (in your case that's sway) gives GIMP access to the
keyboard at times when you think it should not have access, then that's
also not a GIMP bug: it's the compositor that controls what information
is available to applications, not the other way around.

smcv

Bug#1072963: jpeg-xl: Failing autopkgtests on non-amd64

[Simon McVittie]

On Tue, 11 Jun 2024 at 13:28:52 +0200, Chris Hofstaedtler wrote:
> Maybe smcv can chime in here.

(I am not a maintainer of gdk-pixbuf and I do not intend to be any
sort of single point of failure for Debian's use of gdk-pixbuf; I have
sometimes done team uploads of it as part of the GNOME team, but please
don't rely on me to keep the distribution working. Please consider using
@packages.debian.org addresses if you want to get an opinion from the
uploaders of a related package without blocking on a named individual.)

On Tue, 11 Jun 2024 at 13:28:52 +0200, Chris Hofstaedtler wrote:
> On Tue, Jun 11, 2024 at 01:04:06PM +0200, Julian Wollrath wrote:
> > > > Specifically, the problem is that debian/libjxl-gdk-pixbuf.postinst
> > > > and debian/libjxl-gdk-pixbuf.postrm have hardcoded the amd64
> > > > architecture

If true (I have not checked) then that's clearly a bug.

> > in principle [gdk-pixbuf-query-loaders]
> > should be called, to make gdk-pixbuf
> > aware of the jpeg-xl loader.
>
> I think there is a better way than running a
> postinst script in each individual package (triggers?).

Yes, there is a better way, and it is triggers.

libgdk-pixbuf-2.0-0 registers a trigger on
/usr/lib/MULTIARCH/gdk-pixbuf-2.0/2.10.0/loaders which should result
in it automatically running
/usr/lib/MULTIARCH/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
every time a package that provides a gdk-pixbuf loader is installed,
removed or updated.

As a result, a jpeg-xl loader for gdk-pixbuf should not need to do
anything special in its postinst at all: it should install a loader
that matches the naming convention set by gdk-pixbuf, and that should be
enough for the gdk-pixbuf packaging to handle the rest. If the trigger
is not sufficient, please report a bug with steps-to-reproduce.

The naming convention is ${gdk_pixbuf_moduledir}/*.so, where
${gdk_pixbuf_moduledir} should be discovered at build-time from
the gdk-pixbuf-2.0 pkgconf module. Hopefully the upstream build system
already does this correctly.

heif-gdk-pixbuf from src:libheif, librsvg2-common from src:rsvg, and
webp-pixbuf-loader from src:webp-pixbuf-loader might be good examples of
a working gdk-pixbuf loader.

heif-gdk-pixbuf and webp-pixbuf-loader do not seem to have any
hand-written code in their postinsts at all, so they completely rely on
gdk-pixbuf's triggers, and that seems to work fine in practice.

librsvg2-common does have code in its postinst, but it seems to be a
workaround for an old bug
(https://bugs.launchpad.net/ubuntu/+source/librsvg/+bug/719861) and
is probably unnecessary now that gdk-pixbuf is using interest-noawait
triggers.

smcv

Bug#1066606: marked as pending in fteqcc

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1066606 in fteqcc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/fteqcc/-/commit/7d6b0167eab10c97d05ff6ba1595f09ef2bd7635


Add patches from upstream git to fix implicit function declarations

Closes: #1066606


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066606

Bug#1071116: libkkc: likely shouldn't add recursive dependencies to Marisa_gir_SCANNERFLAGS

[Simon McVittie]

Control: severity -1 normal

On Tue, 14 May 2024 at 18:41:01 +0100, Simon McVittie wrote:
> On Tue, 14 May 2024 at 17:12:29 +0100, Simon McVittie wrote:
> > I'm testing a patch to make g-ir-scanner explicitly disable
> > -Wl,--as-needed, so that the SONAMEs can be extracted reliably.
> 
> This successfully mitigates the libkkc issue, and we need it anyway for
> ibus-anthy. After uploading that patch, I'll downgrade this bug to non-RC.
> 
> > However, I think libkkc is also invoking g-ir-scanner wrong
> 
> I still think this.

gobject-introspection uploaded, downgrading to non-RC.

smcv

Bug#1071116: libkkc: likely shouldn't add recursive dependencies to Marisa_gir_SCANNERFLAGS

[Simon McVittie]

On Tue, 14 May 2024 at 17:12:29 +0100, Simon McVittie wrote:
> I'm testing a patch to make g-ir-scanner explicitly disable
> -Wl,--as-needed, so that the SONAMEs can be extracted reliably.

This successfully mitigates the libkkc issue, and we need it anyway for
ibus-anthy. After uploading that patch, I'll downgrade this bug to non-RC.

> However, I think libkkc is also invoking g-ir-scanner wrong

I still think this.

> Like this pseudo-patch (untested):
> 
> -libmarisa_glib_la_LIBADD = $(GIO_LIBS) $(MARISA_LIBS)
> +libmarisa_glib_la_LIBADD = $(GIO_LIBS) $(MARISA_LIBS) 
> $(MARISA_GLIB_STATIC_DEPENDENCIES)
> ...
> -Marisa_gir_SCANNERFLAGS = --pkg-export=marisa-glib --pkg=marisa 
> --namespace=Marisa $(MARISA_GLIB_STATIC_DEPENDENCIES)
> +Marisa_gir_SCANNERFLAGS = --pkg-export=marisa-glib --pkg=marisa 
> --namespace=Marisa

Unfortunately this doesn't work, because -lstdc++ gets stripped from the
linker arguments (possibly by libtool), and then the link fails because
the static library needs to use symbols from it.

Possibly adding -Wl,--copy-dt-needed-entries to the Marisa_gir_CFLAGS
would help?

I don't know what the correct solution would be, but I'm reasonably
sure that making Marisa.gir claim to be a GObject binding for libstdc++
is not it.

smcv

Bug#1060953: marked as pending in gobject-introspection

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1060953 in gobject-introspection reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gobject-introspection/-/commit/bebef08c063a0e891019f9a333e0fa219f56b192


d/patches: Add proposed patch to apply -Wl,--no-as-needed more thoroughly

This avoids build regressions in libkkc and ibus-anthy, which pass
libraries to `g-ir-scanner --library` that do not contain any functions
directly called by the dumper.

Closes: #1060951, #1060953
Mitigates: #1071116


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1060953

Bug#1060951: marked as pending in gobject-introspection

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1060951 in gobject-introspection reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/gobject-introspection/-/commit/bebef08c063a0e891019f9a333e0fa219f56b192


d/patches: Add proposed patch to apply -Wl,--no-as-needed more thoroughly

This avoids build regressions in libkkc and ibus-anthy, which pass
libraries to `g-ir-scanner --library` that do not contain any functions
directly called by the dumper.

Closes: #1060951, #1060953
Mitigates: #1071116


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1060951

Bug#1060953: ibus-anthy: FTBFS: make[3]: *** [/usr/share/gobject-introspection-1.0/Makefile.introspection:156: Anthy-9000.gir] Error 1

[Simon McVittie]

Control: reassign -1 src:gobject-introspection 1.78.1-17
Control: affects -1 src:ibus-anthy

This looks like almost the same situation as #1060951, except that
in #1060951, I think libkkc is probably using g-ir-scanner incorrectly
(cloned as #1071116), whereas in #1060953 I don't see anything that
ibus-anthy is obviously doing wrong.

smcv

Bug#1060951: libkkc: likely shouldn't add recursive dependencies to Marisa_gir_SCANNERFLAGS

[Simon McVittie]

Control: clone -1 -2
Control: retitle -1 gobject-introspection: multiarch g-ir-scanner doesn't find 
recursive library dependencies
Control: retitle -2 libkkc: likely shouldn't add recursive dependencies to 
Marisa_gir_SCANNERFLAGS
Control: reassign -2 libkkc 0.3.5-8
Control: tags -2 + upstream

On Tue, 30 Apr 2024 at 08:23:55 -0400, Boyuan Yang wrote:
> * When manually invoking using /usr/bin/g-ir-scanner, the build is fine.
> 
> * When invoking using /usr/bin/x86_64-linux-gnu-g-ir-scanner, the build
> error (libm not found) will happen, as shown in the build log attached.
> 
> Comparing the invocation of g-ir-scanner with native compilation, the
> only extra flag is the addition of "--use-ldd-
> wrapper=/usr/libexec/gobject-introspection-bin/deb-elf-get-needed". I
> guess this wrapper is doing something bad.

The reason for the regression is that ldd is recursive, but
deb-elf-get-needed is not. In builds that link with -Wl,--as-needed,
explicitly linking the GObject-Introspection "dumper" binary to each
--library is not always enough to produce a direct dependency, which means
we can't find out the SONAME of the library.

I'm testing a patch to make g-ir-scanner explicitly disable
-Wl,--as-needed, so that the SONAMEs can be extracted reliably.

Using ldd to parse the dependencies accidentally works around this (today,
but not necessarily forever) because libm is in its indirect dependencies,
via libstdc++ - but arguably that's wrong, because libm no longer exists
as an independent library and has been merged into libc.

However, I think libkkc is also invoking g-ir-scanner wrong: it's passing
its dependencies into g-ir-scanner as -l (--library). This is not just an
alias of the gcc -l argument: it is specifically intended to be a list
of the libraries that are part of the library for which g-ir-scanner is
generating a binding. By passing "-lstdc++ -lm -lgcc_s -lgio-2.0 ..."
to g-ir-scanner, this project is claiming to be a GObject-Introspection
binding for libstdc++, libm, libgcc_s, libgio-2.0 and so on - which seems
unlikely to be true! So I think it would be worthwhile to fix this in
libkkc as well.

A symptom of this problem is that Marisa.gir contains
shared-library="libstdc++.so.6,libm.so.6,libc.so.6,libgcc_s.so.1"
instead of what I would expect it to contain, which is something more like
shared-library="libmarisa-glib.so" (or perhaps even an empty list or no
attribute at all, because libmarisa seems to be static-only).

Producing GObject-Introspection bindings for static-only libraries is
unusual, so there are probably some rough edges here. The incorrect
shared-library attribute happens to not matter very much, because the
GIR XML is only used to generate Vala bindings and then thrown away,
rather than being installed like GIR XML usually is.

Looking at its git history, I think
https://github.com/ueno/libkkc/commit/16cd162f1c018fcf74435b3ae920d2805eba40e9
was probably not the right thing to do. My Autotools knowledge
is increasingly rusty, so I don't know what the right thing would
have been: perhaps moving $(MARISA_GLIB_STATIC_DEPENDENCIES) into
libmarisa_glib_la_LIBADD and then relying on libtool to pick up the
static-linking dependencies from the .la file in the usual way?
Like this pseudo-patch (untested):

-libmarisa_glib_la_LIBADD = $(GIO_LIBS) $(MARISA_LIBS)
+libmarisa_glib_la_LIBADD = $(GIO_LIBS) $(MARISA_LIBS) 
$(MARISA_GLIB_STATIC_DEPENDENCIES)
...
-Marisa_gir_SCANNERFLAGS = --pkg-export=marisa-glib --pkg=marisa 
--namespace=Marisa $(MARISA_GLIB_STATIC_DEPENDENCIES)
+Marisa_gir_SCANNERFLAGS = --pkg-export=marisa-glib --pkg=marisa 
--namespace=Marisa

Let's use #1060951 for the gobject-introspection regression, and the
bug that I've cloned for the libkkc side of this.

smcv

Bug#1070745: Bug#1070730 etc.: libglib2.0-0: ibus input regression

[Simon McVittie]

On Wed, 08 May 2024 at 03:48:21 +, unfathomabl...@protonmail.com wrote:
> Latest upgrade from 2.74.6-2 to 2.74.6-2+deb12u1 broke input of Japanese
> characters GTK programs (such as firefox, gedit etc).

For users of testing/unstable, this will be fixed as soon as I can,
probably by version 2.80.1-1. Each GLib build takes around an hour,
plus the time required for testing, so it is not possible to fix this
instantaneously.

For users of Debian 12 'bookworm', a test-build of a fix for this
regression is available here: https://people.debian.org/~smcv/bug1070730/
(amd64 + i386 + source)

I've contacted the security team about releasing this regression fix
officially as 2.74.6-2+deb12u2, but that cannot be done without their
permission.

Debian 11 'bullseye' is in the same situation as Debian 12 'bookworm'.
A test-build for that release is not yet available. I'll upload one when
available, if the security team doesn't get back to me first.

On Wed, 08 May 2024 at 10:10:48 +0200, Arne Nordmark wrote:
> Another thing that might well be the same underlying problem:
> 
> Using version 2.74.6-2+deb12u1, a Compose sequence like 'Compose " a' enters
> nothing in gnome-terminal and emacs.
> 
> Using version 2.74.6-2, the same sequence enters an "ä".

All non-trivial input methods in GNOME involve ibus, so the Compose key
and dead keys will also be affected by this regression.

smcv

Bug#1070745: marked as pending in glib2.0

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1070745 in glib2.0 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/glib/-/commit/344f7b2e170baf69b3467b6585aac6cff2babdb8


d/patches: Relax name owner checks to avoid a regression in ibus

Fixing CVE-2024-34397 caused a regression in ibus affecting text entry
with non-trivial input methods.

Closes: #1070730, #1070736, #1070743, #1070745


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1070745

Bug#1070745: marked as pending in glib2.0

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1070745 in glib2.0 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/glib/-/commit/1bf4d8867da5d19f3a94f8e4da7aab338fee8c9c


d/patches: Relax name owner checks to avoid a regression in ibus

Fixing CVE-2024-34397 caused a regression in ibus affecting text entry
with non-trivial input methods.

Closes: #1070730, #1070736, #1070743, #1070745


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1070745

Bug#1070745: Bug on Debian 12 Bookworm - Gnome-Shell / After today's upgrade, the dead keys on my keyboard no longer work

[Simon McVittie]

Control: reassign -1 libglib2.0-0 2.74.6-2+deb12u1
Control: affects -1 + gnome-shell

On Wed, 08 May 2024 at 11:42:10 +0200, pham...@bluewin.ch wrote:
> After today's update, the dead keys on my keyboard no longer work

This is a regression in GLib triggered by fixing CVE-2024-34397. I'm
testing a possible fix as rapidly as I can, but each GLib build takes
about an hour, so please be patient.

smcv

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

Control: severity 1070706 normal
Control: severity 1070714 normal

On Tue, 07 May 2024 at 22:53:33 +0200, Cyril Brulebois wrote:
> Simon McVittie  (2024-05-07):
> > do the release/installer teams consider udeb dependencies
> > on non-udeb packages, by udebs that d-i does not currently need or use,
> > to be a RC issue or merely a nice-to-have?
> 
> If udebs are actually used, I call that an RC bug and try to get it
> fixed swiftly (sometimes NMUing right away when time is of the essence).
> Otherwise I usually let those fly (without even filing bug reports).

In that case I'm downgrading #1070714 and #1070706 to normal, because the
issues I noticed while investigating #1070706 are worth tracking and being
aware of but non-RC, and the issue that Peter originally reported is not
actionable for the gtk4 maintainers (it needs to be fixed via a binNMU).

We'll need to revisit #1070714 and #1070706 if someone makes a concerted
effort to GTK3ize the installer, but that has been on my to-do list since
before bookworm and shows no signs of approaching the top, so it might
have to be someone else's project.

Thanks!

smcv

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

On Tue, 07 May 2024 at 22:02:12 +0200, Paul Gevers wrote:
> On 07-05-2024 7:49 p.m., Simon McVittie wrote:
> > The version in testing, 4.12.5+ds-3, has the same dependencies, so this
> > is not a regression.
> 
> Is it? It seems that the version in unstable depends on libpng16-16t64-udeb
> where the version in testing depends on libpng16-16-udeb. The later exists,
> the former not.

Oh, well spotted! It looks as though src:gtk4 needs a binNMU against
libpng-dev (>= 1.6.43-4) for #1066069, because we were unlucky with
the timing of gtk4's most recent upload and so it got built against the
incorrect libpng-dev.

My understanding is that a binNMU would be better than a sourceful upload
of gtk4 because it won't reset the migration clock. If that's correct,
please could someone with release team or wanna-build powers schedule it?

nmu gtk4_4.12.5+ds-6 . ALL . -m 'rebuild with #1066069 fixed'

Looking at the d-i Packages.gz for amd64, the only other source
package that has picked up the bad libpng16-16t64-udeb dependency
seems to be matchbox-keyboard, which needs a sourceful upload to fix an
implicit-declarations FTBFS anyway, therefore isn't useful to binNMU.

After those binNMUs, the gtk4 udeb will still not be installable into
the debian-installer environment (either in testing or in unstable), but
it should at least be able to migrate, because all of its dependencies
will be packages that exist (whether deb or udeb).

After that: do the release/installer teams consider udeb dependencies
on non-udeb packages, by udebs that d-i does not currently need or use,
to be a RC issue or merely a nice-to-have?

Thanks,
smcv

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

Control: tags -1 + d-i
Control: found -1 4.12.5+ds-3
Control: retitle -1 gtk4 udeb has unsatisfiable dependencies
Control: clone -1 -2
Control: retitle -2 libvte-2.91-0-udeb depends on both GTK 3 and GTK 4
Control: reassign -2 src:vte2.91 0.75.92-1

On Tue, 07 May 2024 at 15:44:02 +0100, Peter Michael Green wrote:
> According to britney, gtk4's udebs are uninstallable.

gtk4 is not yet used by debian-installer (which is still on GTK 2)
so the udeb is not actually necessary, and one workaround would be to
disable it entirely (but then we'd have to put GTK 4 through NEW again
if we are ever able to upgrade d-i to it).

The version in testing, 4.12.5+ds-3, has the same dependencies, so this
is not a regression. Is this requirement newly enforced by britney?

I think a large part of the problem is that when GTK 4 support was added
to src:vte2.91, both the GTK 3 and GTK 4 versions were put into the same
udeb package, libvte-2.91-0-udeb, instead of giving the GTK 4 version
its own udeb. However, I'm unsure how that change got into testing -
if britney is enforcing installability of udebs, I would have expected
that the updated libvte-2.91-0-udeb would have been newly-uninstallable,
preventing its migration?

It seems most realistic that d-i in Debian 13 will depend on GTK 3 if
someone finds the time to do the necessary porting and testing, or stay
on GTK 2 if not, so libvte-2.91-0-udeb should become a udeb version of
only libvte-2.91-0 (i.e. GTK 3 only) as it was in Debian 12, and drop
its GTK 4 parts. That would mean that GTK 4 would no longer be regressing
the installability of libvte-2.91-0-udeb.

If there is a serious attempt to get d-i using GTK *4*, then that would
require a new libvte-2.91-gtk4-0-udeb. However, GTK 4's threading model
is definitely incompatible with the current design of cdebconf-gtk (it
calls into GTK from more than one thread, which is discouraged in GTK
3 and not allowed at all in GTK 4), so a prerequisite for that would
be to move all of cdebconf-gtk's GTK interactions onto one thread,
with message-passing between that thread and the cdebconf thread.

I'm also unsure how GTK 4 can possibly have caused libvte-2.91-0-udeb's
installability to regress anyway, because libvte-2.91-0-udeb in testing
depends on liblz4-1, which does not have a corresponding udeb. That
will need fixing (by adding a liblz4-1-udeb, or linking it statically,
or allowing .deb libraries to satisfy udebs' dependencies) if we ever
want a GTK 3 or later installer.

Making the GTK 4 udeb installable looks like a significant task. It depends
on:

OK - fontconfig-udeb (>= 2.15.0),
OK - libc6-udeb (>= 2.37),
!! - libcairo-script-interpreter2 (>= 1.18.0),
OK - libcairo2-udeb (>= 1.18.0),
OK - libepoxy0-udeb (>= 1.5.4),
OK - libfribidi0-udeb (>= 1.0.13),
OK - libgdk-pixbuf-2.0-0-udeb (>= 2.42.10+dfsg),
OK - libglib2.0-udeb (>= 2.78.4),
!! - libgraphene-1.0-0 (>= 1.10.8),
OK - libharfbuzz0-udeb (>= 8.3.0),
!! - libjpeg62-turbo (>= 1:2.1.5),
OK - libpango1.0-udeb (>= 1.52.1+ds),
OK - libpng16-16t64-udeb (>= 1.6.2),
!! - libtiff6 (>= 4.5.1+git230720),
OK - libx11-6-udeb (>= 2:1.6.0),
OK - libxcursor1-udeb (>> 1.1.2),
!! - libxdamage1 (>= 1:1.1),
OK - libxext6-udeb (>= 2:1.3.0),
OK - libxfixes3-udeb (>= 1:5.0),
OK - libxi6-udeb (>= 2:1.6.99.1),
OK - libxinerama1-udeb (>= 2:1.1.4),
OK - libxrandr2-udeb (>= 2:1.5)

cairo has a udeb, but it doesn't include the equivalent of
libcairo-script-interpreter2. It might be possible to disable the GTK
features that rely on that library? Or it might be possible to add the
script interpreter to the udeb?

graphene does not have udebs at all, and I think it's a mandatory
dependency for GTK 4, so if we ever want a GTK-4-based d-i, there is
no avoiding adding a graphene udeb.

libjpeg-turbo, tiff and libxdamage are in the same situation as graphene
(these were optional in GTK 3 but are required in GTK 4). Unlike graphene,
these are not maintained by the GNOME team, so we cannot unilaterally
add udebs to them.

smcv

Bug#1070016: marked as pending in game-data-packager

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1070016 in game-data-packager reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/game-data-packager/-/commit/07d91b93d1bcbc4fb6e08db04cdb668ab752d5c5


d/control: Switch quake4 dependency from libasound2 to libasound2t64

For the 64-bit time_t transition. quake4 is i386-only, so there has
been no actual ABI break on this architecture.

Closes: #1070016
Signed-off-by: Simon McVittie 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1070016

Bug#1070016: quake4: hard-coded dependencies on pre-t64 libraries

[Simon McVittie]

On Mon, 29 Apr 2024 at 17:12:05 +0200, Sebastian Ramacher wrote:
> It will also help dak to decruft the pre-t64 from unstable and render
> game-data-packages as good on the transition trackers.

OK. Would it be OK to make these dependencies be of the form
"libasound2t64 | libasound2" and so on, or is it a requirement that we
use only the new name?

The version of game-data-packager in testing/unstable has generally
remained installable on older suites like stable, and I'd prefer that
to remain true if possible (but if that's a problem for the transition,
then we can sacrifice that desirable property to simplify things).

game-data-packager generates non-distributable .deb packages which can
be installed onto end-user systems, and some of those have dependencies
too, of which at least libsmpeg-0.4.so.0 has been affected by this
transition. To avoid needing to know the target Debian release when
generating those packages, I'd prefer to turn that into a dependency
on libsmpeg0t64 | libsmpeg0 rather than just libsmpeg0t64 if that isn't
going to be disruptive.

I believe libasound2t64 is the only one of these dependencies that will
affect the packages in contrib.

smcv

Bug#1070016: quake4: hard-coded dependencies on pre-t64 libraries

[Simon McVittie]

On Sun, 28 Apr 2024 at 17:27:21 +0200, Sebastian Ramacher wrote:
> quake4 has hard-coded dependencies on shared libraries (at least
> libasound2) that were renamed as part of the t64 transition. Please
> update the dependencies accordingly.

quake4 is i386-only, and i386 has Provides for the old names and no real
ABI break, so I don't think this is necessarily RC - although updating
quake4 in src:game-data-packager might help apt to choose better upgrade
paths, so it's a valid bug.

(The i386 binaries referenced by quake4 - really in the quake4-bin package
produced by game-data-packager - are proprietary and non-modifiable,
and target the pre-t64 ABI.)

smcv

Bug#1069841: python-icalendar: FTBFS with tzdata 2024a: UnknownTimeZoneError: 'America/Godthab'

[Simon McVittie]

Control: retitle -1 python-icalendar: FTBFS with tzdata 2024a: 
UnknownTimeZoneError: 'America/Godthab'

On Thu, 25 Apr 2024 at 18:27:15 +0200, Santiago Vila wrote:
> E   pytz.exceptions.UnknownTimeZoneError: 'America/Godthab'

This was presumably triggered by this change in tzdata 2024a-2:

tzdata (2024a-2) unstable; urgency=medium
...
  * Replace America/Godthab by America/Nuuk

which appears to have been an intentional compatibility break?

smcv

Bug#1069258: ruby-curb: test regression with curl 8.7.1: client read function EOF fail, only only 4/5 of needed bytes read

[Simon McVittie]

Control: retitle -1 ruby-curb: test regression with curl 8.7.1: client read 
function EOF fail, only only 4/5 of needed bytes read
User: debian...@lists.debian.org
Usertags: breaks needs-update

On Thu, 18 Apr 2024 at 22:42:11 +0200, Sebastian Ramacher wrote:
> Error: test_easy_http_verbs(TestCurbCurlEasy): Curl::Err::ReadError: Failed 
> to open/read local data from file/application: client read function EOF fail, 
> only only 4/5 of needed bytes read
...
> Error: test_put_data(TestCurbCurlEasy): Curl::Err::ReadError: Failed to 
> open/read local data from file/application: client read function EOF fail, 
> only only 6/7 of needed bytes read
...
> Error: test_put_data_null_bytes(TestCurbCurlEasy): Curl::Err::ReadError: 
> Failed to open/read local data from file/application: client read function 
> EOF fail, only only 2/3 of needed bytes read

These messages with "only only (n)/(n+1) of needed bytes read" seem to
be characteristic. As well as being a FTBFS, this is also an autopkgtest
regression when upgrading curl, which is one of several factors preventing
curl from migrating; that, in turn, blocks elfutils, which blocks GLib,
which will likely be blocking a significant chunk of the 64-bit time_t
transition.

This could either be a regression in curl, or a pre-existing bug in
ruby-curb that was exposed by a behaviour change in curl (for example
maybe curl started applying stricter checks). I don't know curl well
enough to say which, but perhaps the curl maintainers can help? This
upstream commit introduced the new error message and seems relevant:
https://github.com/curl/curl/commit/9369c30cd87c041cf983bcdfabd1570980abbaf6

Here is a convenient reproducer in an unprivileged container:

$ podman run -v $(pwd):$(pwd):rw -w $(pwd) -it debian:trixie-slim
# sed -i -e 's/Types: deb/& deb-src/' /etc/apt/sources.list.d/debian.sources
# apt update
# apt upgrade
# apt install --no-install-recommends build-essential
# apt source ruby-curb
# cd ruby-curb-*
# apt --no-install-recommends build-dep .
# dpkg-buildpackage -us -uc -B
... succeeds ...
# sed -i -e 's/Suites: trixie /Suites: sid /'
# apt --no-install-recommends install curl
...
The following additional packages will be installed:
  libcurl3t64-gnutls libcurl4-gnutls-dev libcurl4t64
Suggested packages:
  libcurl4-doc libgnutls28-dev libidn-dev libkrb5-dev libldap2-dev librtmp-dev 
libssh2-1-dev pkgconf zlib1g-dev
The following packages will be REMOVED:
  libcurl3-gnutls
The following NEW packages will be installed:
  curl libcurl3t64-gnutls libcurl4t64
The following packages will be upgraded:
  libcurl4-gnutls-dev
...
# dpkg-buildpackage -us -uc -B
... fails as seen in the buildd log ...

Thanks,
smcv

Bug#1069401: nautilus: FTBFS on arm64: test-nautilus-search-engine-tracker timed out

[Simon McVittie]

Control: retitle -1 nautilus: FTBFS on arm64: 
test-nautilus-search-engine-tracker timed out

(cc'ing Lucas in case whatever heuristics are parsing the log can be
improved)

On Sat, 20 Apr 2024 at 14:09:18 +0200, Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > (tracker-miner-fs-3:3061640): dconf-CRITICAL **: 04:05:03.655: unable to 
> > create directory '/sbuild-nonexistent/.cache/dconf': Permission denied.  
> > dconf will not work properly.
> > 
> > (tracker-miner-fs-3:3061640): libupower-glib-WARNING **: 04:05:03.655: 
> > Couldn't connect to proxy: Could not connect: No such file or directory

These are non-fatal (they'd say FATAL-CRITICAL or FATAL-WARNING if they
had been made fatal for testing purposes), although obviously it would
be better to make dconf work correctly (by setting a better $HOME and
$XDG_RUNTIME_DIR, as newer debhelper compat levels do by default) to
reduce the log noise and make real problems visible.

> > 17/17 test-nautilus-search-engine-trackerTIMEOUT480.24s 
> >   exit status 1

The failure reason here is that this test timed out.

> > test: test-nautilus-search-engine-tracker
...
> > ERROR: g-io-error-quark: The connection is closed (18)

I think that's more likely to be the root cause. It might be a D-Bus
connection, or some other socket.

smcv

Bug#1069361: libgweather4: FTBFS on arm64: Location 'Greenland' has invalid timezone 'America/Godthab'

[Simon McVittie]

Control: retitle -1 libgweather4: FTBFS on arm64: Location 'Greenland' has 
invalid timezone 'America/Godthab'

On Sat, 20 Apr 2024 at 14:06:28 +0200, Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > # GLib-GIO-DEBUG: Failed to initialize portal (GNetworkMonitorPortal) for 
> > gio-network-monitor: Not using portals
> > # GLib-GIO-DEBUG: Failed to initialize networkmanager (GNetworkMonitorNM) 
> > for gio-network-monitor: Could not connect: No such file or directory

I'm fairly sure these are harmless and not an error, hence the DEBUG prefix.
If GLib can't use the NetworkManager network monitor, it will do something
else instead (in practice, generic sockets APIs and Linux netlink).

> > # Location 'Greenland' has invalid timezone 'America/Godthab'
> > # 
> > # Location 'Thule A. B.' has invalid timezone 'America/Godthab'
(etc.)

I think those are likely to be the actual test failure.

smcv

Bug#1067677: marked as pending in clutter-gst-3.0

[Simon McVittie]

Control: tag -1 pending

Hello,

Bug #1067677 in clutter-gst-3.0 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/clutter-gst/-/commit/15bc5874d29376d81d0c097ab5b82ec4b38a8639


d/control: Build-depend on libglib2.0-dev instead of libglib2.0-0

Closes: #1067677


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1067677

Bug#1067773: plank: FTBFS when Build-Depends-Indep are not installed

[Simon McVittie]

Source: plank
Version: 0.11.89-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Thanks for trying to address #1067764, but unfortunately the version that
was uploaded fails to build on all of the per-architecture buildds:

> dh_auto_configure -- \
> --enable-docs \
> --enable-headless-tests \
...
> checking for valadoc... :
> configure: error: Doc building requested but valadoc not installed.

I did suggest how to avoid this in #1067764: only --enable-docs if the
-doc package is going to be built.

smcv