Bug#1084050: Mouse cursor oversized when over ptyxis window (with display scaling enabled)

[Simon McVittie]

On Fri, 04 Oct 2024 at 06:09:26 -0700, Josh Triplett wrote:
> I have display scaling enabled (at 150%). When the mouse is over the
> ptyxis window, the mouse cursor is oversized; it's quite a bit larger
> than the terminal text, making it harder to aim for the correct line.

This is probably a duplicate of https://bugs.debian.org/1083115 rather
than a new ptyxis bug: we took some patches from upstream to fix a cursor
scaling issue in KDE Plasma + Wayland, and they had the side-effect of
causing the opposite cursor scaling issue in GNOME Shell + Wayland.

You could verify this by comparing with GTK3 apps like gtk-3-examples
(should all behave the same as Firefox and gnome-terminal), and with GTK4
apps like gnome-console (kgx) and gtk-4-examples (should all behave the
same as ptyxis, if my guess is correct).

smcv

Bug#1083471: Migrating away from pkg_resources is difficult for namespace packages

[Simon McVittie]

Control: tags -1 + upstream moreinfo
Control: forwarded -1 
https://github.com/projectmallard/mallard-ducktype/issues/21

On Fri, 04 Oct 2024 at 11:22:32 +0100, Colin Watson wrote:
> While pkg_resources is indeed deprecated upstream, there's nothing that
> we can sensibly do about it at the Debian level in lazr.* or zope.*, and
> it's not even as clear as you might hope what to do upstream.  They all
> do something like this in an __init__.py (with unimportant variations):
> 
>   __import__('pkg_resources').declare_namespace(__name__)
> 
> As
> https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages
> says:
> 
>   If you are creating a new distribution within an existing namespace
>   package that uses this method then it’s recommended to continue using
>   this as the different methods are not cross-compatible and it’s not
>   advisable to try to migrate an existing package.
> 
> I know pkg_resources is deprecated for most other purposes, but even
> upstream currently advises here not to try to migrate in this case.
> Now, I know there've been some attempts to figure this out:
> https://github.com/pypa/sample-namespace-packages thinks a migration may
> be possible as long as developers are willing to accept some
> limitations.

mallard-ducktype (#1083471) is in a similar situation, although there don't
seem to be any third-party extensions to it packaged in Debian in practice,
so we might be able to get away with just deleting
/usr/lib/python3/dist-packages/mallard/ducktype/extensions/__init__.py and
hoping it doesn't break anything for unpackaged code.

I've asked upstream whether they are aware of third-party extensions that
are not packaged in Debian. I'm not intending to work on this further in
mallard-ducktype until there is an obvious correct thing to do.

Thanks,
smcv

Bug#1079241: gnome-shell-extension-dash-to-panel: needs update for GNOME Shell 47

[Simon McVittie]

On Fri, 04 Oct 2024 at 13:25:49 +0100, Christopher Obbard wrote:
> I already have an existing access request on salsa for
> gnome-team, do I need to do anything else ?

I believe being added to the gnome-team group with level >= Developer
should give you push access to all Shell extensions maintained in the
team. I am not an Owner of gnome-team, so I can't see or approve your
request myself.

smcv

Bug#1079241: gnome-shell-extension-dash-to-panel: needs update for GNOME Shell 47

[Simon McVittie]

Control: tags -1 + fixed-upstream
Control: forwarded -1 
https://github.com/home-sweet-gnome/dash-to-panel/releases/tag/v63

On Fri, 04 Oct 2024 at 12:56:47 +0100, Christopher Obbard wrote:
> The latest tagged upstream version v63 is compatible with gnome-shell
> 47 (running it on my machine as we speak). The linked PR is no longer
> relevant, but it is still open upstream.

Thanks, that's useful. An updated version can go to unstable if it's still
compatible with GNOME Shell 46 (the upstream metadata.json suggests that
this is true), or to experimental if it's waiting for the GNOME Shell
47 transition (#1081519).

If you're a user of this extension (I'm not), perhaps you could join
the GNOME team and help to maintain its package?

smcv

Bug#1083166: meson: calling host_machine.kernel() on hurd-any results in an error

[Simon McVittie]

Package: meson
Version: 1.5.2-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian-h...@lists.debian.org
User: debian-h...@lists.debian.org
Usertags: hurd
Forwarded: https://github.com/mesonbuild/meson/issues/13740

See the upstream bug report, but the tl;dr is that configuring this
Meson project on Hurd:

project('test')
message('system is @0@'.format(host_machine.system()))
message('subsystem is @0@'.format(host_machine.subsystem()))
message('kernel is @0@'.format(host_machine.kernel()))

outputs:

> Message: system is gnu
> Message: subsystem is gnu
>
> meson.build:4:43: ERROR: Kernel not defined or could not be autodetected.

Untested solution: in mesonbuild/environment.py, edit KERNEL_MAPPINGS and
add 'gnu': 'some suitable value'.

Hurd porters: what do you want host_machine.kernel() to return on Hurd?
Should it be 'gnu' (consistent with uname -s which prints 'GNU'), or
should it be 'hurd' or 'mach' or something else?

Whatever is the desired value, it would be great if someone who uses
Hurd could send a tested PR upstream.

The context for this is that I noticed that `meson env2mfile` (used during
cross-compilation) sets kernel to 'linux' for all Debian architectures,
which is certainly wrong.
https://github.com/mesonbuild/meson/pull/13722 fixes that for kFreeBSD,
but I don't know whether the kernel field on Hurd ought to be
'gnu', 'hurd', 'mach' or something else.

Thanks,
smcv

Bug#1083090: bookworm-pu: package ostree/2022.7-2+deb12u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ost...@packages.debian.org
Control: affects -1 + src:ostree src:flatpak libcurl3-gnutls
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Fix a serious regression in flatpak when libcurl3-gnutls is upgraded to
the version from bookworm-backports

[ Impact ]
For users of pure bookworm, no impact.

For users of bookworm-backports' libcurl3-gnutls, flatpak crashes with
an assertion failure when trying to install or upgrade apps/runtimes,
which is fixed by the proposed package.

[ Tests ]
Unfortunately neither the ostree test suite nor the flatpak test suite
reproduces the assertion failure (they use a simple mock http server
and the bad code path appears to require a fully-featured http server,
possibly HTTP/2).

There is a simple manual reproducer, and I've verified that the proposed
package fixes the assertion failure here:

$ podman run --rm -it debian:bookworm-slim
# echo "deb http://deb.debian.org/debian bookworm-backports main" > 
/etc/apt/sources.list.d/debian-backports.list
# apt update
# apt install --no-install-recommends flatpak ca-certificates
# apt install libcurl3-gnutls/bookworm-backports
# flatpak remote-add --if-not-exists flathub 
https://dl.flathub.org/repo/flathub.flatpakrepo
# flatpak install flathub org.gnome.Recipes

(It is OK and expected that installation of
org.freedesktop.Platform.openh264 fails with "apply_extra script failed",
and other steps log a warning "bwrap: Creating new namespace failed:
Operation not permitted", when installing inside an unprivileged
container: this is a limitation of nested containers and is unrelated
to the regression.)

I have also confirmed that the proposed ostree version can successfully
install a Flatpak app in a Debian 12 GNOME desktop VM with each of
bookworm libcurl3-gnutls or bookworm-backports libcurl3-gnutls.

[ Risks ]
The actual fix seems very low-risk: it's a straightforward backport
of an upstream change that they specifically called out as suitable
for backporting.

The accompanying change to add an assertion failure if curl_multi_assign()
fails could conceivably make a wrong-but-harmless situation into a crash,
but my understanding is that it's something that should never fail for
reasons other than a programming error, and it does seem valuable to
check this.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
d/control, d/gbp.conf:
Administrivia because this is its first stable update in the bookworm cycle

debian/patches/curl-Make-socket-callback-during-cleanup-into-no-op.patch:
This is the actual bug-fix. The original uses C11 , but 2022.7
didn't use that, so I adjusted the patch to use GLib's booleans instead
(the only functional difference is that the struct might be slightly
larger).

debian/patches/curl-Assert-that-curl_multi_assign-worked.patch:
While debugging this assertion failure, upstream added an assertion that
improved their ability to locate the problem.

src/libostree/ostree-fetcher-curl.c:
Modified by each of the patches, see above
diffstat for ostree-2022.7 ostree-2022.7

 debian/changelog |   13 ++
 debian/control   |2 
 debian/gbp.conf  |2 
 debian/patches/curl-Assert-that-curl_multi_assign-worked.patch   |   31 
 debian/patches/curl-Make-socket-callback-during-cleanup-into-no-op.patch |   64 ++
 debian/patches/series|2 
 src/libostree/ostree-fetcher-curl.c  |   17 ++
 7 files changed, 128 insertions(+), 3 deletions(-)

diff -Nru ostree-2022.7/debian/changelog ostree-2022.7/debian/changelog
--- ostree-2022.7/debian/changelog	2022-12-06 11:11:05.0 +
+++ ostree-2022.7/debian/changelog	2024-10-01 12:25:32.0 +0100
@@ -1,3 +1,16 @@
+ostree (2022.7-2+deb12u1) bookworm; urgency=medium
+
+  * d/control, d/gbp.conf: Configure for stable updates
+  * d/p/curl-Assert-that-curl_multi_assign-worked.patch,
+d/p/curl-Make-socket-callback-during-cleanup-into-no-op.patch:
+Add patches from upstream 2024.8 to avoid libflatpak crash with an
+assertion failure when using curl 8.10.x.
+This was originally reported in testing/unstable, but can affect
+bookworm if using libcurl3-gnutls from bookworm-backports.
+(Closes: #1082121)
+
+ -- Simon McVittie   Tue, 01 Oct 2024 12:25:32 +0100
+
 ostree (2022.7-2) unstable; urgency=medium
 
   * Skip test-sysroot.js on s390x (Mitigates: #1025532)
diff -Nru ostree-2022.7/debian/control ostree-2022.7/debian/control
--- ostree-2022.7/debia

Bug#1082121: libostree-1-1: `flatpak update` fails: src/libostree/ostree-fetcher-curl.c:534:sock_cb: code should not be reached

[Simon McVittie]

Control: found -1 2022.7-2

On Wed, 18 Sep 2024 at 16:39:42 +0100, Simon McVittie wrote:
> After upgrading curl to 8.10.0, `flatpak update` fails with:
> 
> > OSTree:ERROR:src/libostree/ostree-fetcher-curl.c:534:sock_cb: code should 
> > not be reached
> > Bail out! OSTree:ERROR:src/libostree/ostree-fetcher-curl.c:534:sock_cb: 
> > code should not be reached
> > [1]21258 IOT instruction (core dumped)  flatpak update

(-backports cc'd for visibility)

This also affects bookworm if using libcurl3-gnutls from
bookworm-backports. I would suggest avoiding backports of core libraries
like libcurl unless you have a specific reason to need them.

Minimal reproducer:

$ podman run --rm -it debian:bookworm-slim
# echo "deb http://deb.debian.org/debian bookworm-backports main" > 
/etc/apt/sources.list.d/debian-backports.list
# apt update
# apt install --no-install-recommends flatpak ca-certificates
# apt install libcurl3-gnutls/bookworm-backports
# flatpak remote-add --if-not-exists flathub 
https://dl.flathub.org/repo/flathub.flatpakrepo
# flatpak install flathub org.gnome.Recipes

If the upstream fix applies cleanly to bookworm's libostree 2022.7-2,
then I'm going to ask the stable release team for permission to include
it in the next bookworm point release.

smcv

Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG

[Simon McVittie]

On Mon, 30 Sep 2024 at 15:46:24 +0200, Fabian Greffrath wrote:
> Maybe the `deutex -h` output to stdout get spoiled by other build steps
> running in parralel, so that it doesn't include "PNG" as an isolated word
> anymore?

That shouldn't be the case, assuming the shell is working correctly:
it's the output of `deutex -h` that is redirected to a pipe (to grep),
not the output of the build system as a whole.

smcv

Bug#1083045: xine-lib-1.2: consider disabling DirectFB support

[Simon McVittie]

Source: xine-lib-1.2
Severity: wishlist
User: debian...@lists.debian.org
Usertags: directfb
Control: block 1083037 by -1

directfb has been orphaned in Debian since 2018 and is effectively
unmaintained.

If DirectFB support is considered to be an essential part of xine-lib-1.2,
please adopt the directfb package (possibly in collaboration with the
maintainers of other packages that depend on it) and fix its RC bugs.

Or, if the xine-lib-1.2 maintainers are not interested in adopting directfb,
please consider disabling the DirectFB backend and removing the
build-dependency.

Thanks,
smcv

Bug#1083044: baresip: consider disabling DirectFB support

[Simon McVittie]

Source: baresip
Severity: wishlist
User: debian...@lists.debian.org
Usertags: directfb
Control: block 1083037 by -1

directfb has been orphaned in Debian since 2018 and is effectively
unmaintained.

If DirectFB support is considered to be an essential part of baresip,
please adopt the directfb package (possibly in collaboration with the
maintainers of other packages that depend on it) and fix its RC bugs.

Or, if the baresip maintainers are not interested in adopting directfb,
please consider disabling the DirectFB backend and removing the
build-dependency. If I'm reading correctly, there is already support in
the build system for building without directfb, for non-Linux ports.

Thanks,
smcv

Bug#1083043: directvnc: should this package be removed?

[Simon McVittie]

Source: directvnc
Severity: serious
Tags: trixie sid
User: debian...@lists.debian.org
Usertags: directfb
Control: block 1083037 by -1

directfb has been orphaned (unmaintained) in Debian since 2018 (see
also #1083037) and I think it's time to consider removing it from the
distribution. If I am reading correctly, directvnc requires DirectFB
and does not have any other display backends?

If directvnc is still relevant/useful and maintained, please adopt its
dependency directfb (possibly by forming a team with the maintainers of
other packages that use it) and fix the release-critical bugs in directfb
and directvnc.

Or, if directvnc is no longer relevant for release in Debian 13, can we
remove it from unstable to stop it from blocking the removal of directfb?

Thanks,
smcv

Bug#1083042: links2: consider disabling DirectFB support

[Simon McVittie]

Source: links2
Severity: wishlist
User: debian...@lists.debian.org
Usertags: directfb
Control: block 1083037 by -1

directfb has been orphaned in Debian since 2018, but for now it is still
considered a key package because links2 (among others) build-depends
on it.

If DirectFB support is considered to be an essential part of links2,
please adopt the directfb package and fix its RC bugs.

Or, if the links2 maintainers are not interested in adopting directfb,
please consider disabling the DirectFB backend and removing the
build-dependency. If I'm reading correctly, that would leave X11 as the
only surviving graphics implementation, which would mean that links2 would
be an ordinary X11 app like xterm, in which case #322995 and #638383 could
also be closed by that change.

Thanks,
smcv

Bug#1083040: gst-plugins-bad1.0: consider disabling DirectFB support

[Simon McVittie]

Source: gst-plugins-bad1.0
Severity: wishlist
User: debian...@lists.debian.org
Usertags: directfb
Control: block 1083037 by -1

directfb has been orphaned in Debian since 2018, but for now it is
still considered a key package because gst-plugins-bad1.0 (among others)
build-depends on it.

If the GStreamer maintainers are not interested in adopting directfb,
please consider disabling the DirectFB plugin (which is presumably not
important for most users of GStreamer?) and removing the build-dependency.

Thanks,
smcv

Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG

[Simon McVittie]

On Mon, 30 Sep 2024 at 13:06:31 +0200, Santiago Vila wrote:
> - When I build with 1 CPU, I have never found the build problem so far.
> - When I build with 2 CPUs, I got a failure rate of 66%
> (16 failures over 24 tries so far).

When I tried this, it was consistently failing if and only if I use
the .dsc from the archive, and consistently succeeding with a rebuilt
.dsc. All of these builds have been in a VM with 3 VCPUs, on a host
system with 4 cores (SMT disabled, so 1 thread per core).

I don't know *why* rebuilding the .dsc avoids this failure mode, but it
appears that it does. This means that I can't usefully try workarounds
or add extra debugging instrumentation, because any time I do that, the
.dsc is rebuilt, the problem vanishes, and the debugging instrumentation
doesn't trigger.

In particular I tried modifying the failing target to add the obvious
debug info for why upstream's check was failing:

```diff
 deutex-check:
+   $(DEUTEX) -h || echo exit status $$?
+   $(DEUTEX) -h | grep -w PNG || echo exit status $$?
@$(DEUTEX) -h | grep -qw PNG || { \
```

but that didn't exhibit the failure (deutex -h showed the expected output
and exited with status 0, deutex -h | grep -w PNG showed non-empty output
and exited with status 0, and upstream's check succeeded).

Are you able to send a modified .dsc (rebuilt with no changes, or with
only changelog changes) to your rebuild infrastructure? If yes, please
try with a rebuilt .dsc (with 2 or more CPUs, since that seems to be
your worst-case scenario for this particular package).

> I would try how it behaves when using --no-parallel.

It did build successfully with `dh $@ --no-parallel`, but that doesn't
necessarily mean anything, because adding that flag required rebuilding
the .dsc, and my experience has been that rebuilding the .dsc is itself
enough to work around this for some as yet unknown reason.

smcv

Bug#1083037: directfb: Should this package be removed?

[Simon McVittie]

Source: directfb
Severity: serious
Justification: ensure visibility for potential adopters
X-Debbugs-Cc: debian-...@lists.debian.org, debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: directfb

directfb has been unmaintained in Debian since 2018, and its web pages
directfb.org and directfb.net seem to have been domain-squatted.

In practice, DirectFB targeted highly resource-constrained embedded
systems, most of which are likely to be no longer relevant: much of the
embedded market has been eaten by Android, and outside the Android world
the replacement for directfb is typically to use X11, Wayland or maybe
KMSDRM, which have an acceptable footprint on modern hardware and make
better use of discrete or integrated GPUs.

There are maintained(?) forks of DirectFB at
https://github.com/deniskropp/DirectFB and https://directfb2.github.io/
(possibly others) but as far as I'm aware, nobody is packaging those.

Typical graphical toolkits like GTK and SDL have generally been removing
DirectFB support: it was present (but did not necessarily work well) in
GTK 2 and SDL 2, and available as a third-party plugin for Qt 4 and 5,
but seems to have been removed from GTK 3, SDL 3 and Qt 6.

Older versions of the graphical debian-installer used GTK 2 on DirectFB,
but current versions use GTK on X11.

If nobody is intending to take over maintenance of directfb, is it time
to remove it from Debian?

When I've received a bug number for this bug, I'll block it by bugs
against the remaining reverse-dependencies:

baresip
directvnc
gst-plugins-bad1.0
links2
xine-lib-1.2

I'm cc'ing debian-arm since that seems like the platform where DirectFB
is most likely to be relevant.

smcv

Bug#1082679: freedoom: FTBFS with .dsc from archive: mis-detects that deutex does not support PNG

[Simon McVittie]

Control: retitle -1 freedoom: FTBFS with .dsc from archive: mis-detects that 
deutex does not support PNG

On Tue, 24 Sep 2024 at 19:41:09 +0200, Santiago Vila forwarded:
> deutex does not support PNG. Try building deutex with the PNG
> libraries (libpng and libpng-devel or similar packages) installed.
...
> make[2]: *** [Makefile:56: deutex-check] Error 1

I can reproduce this, but I don't understand it.

I can reproduce this if I tell sbuild (in my case bookworm's sbuild in a
bookworm VM) to rebuild the .dsc from the archive, mimicking an official
buildd, which I believe is also what Santiago's mass-rebuilds are doing.

However, I can't reproduce the failure if I rebuild the .dsc (no content
changes!), and then tell sbuild to build *that*.

The rebuilds done by the reproducible-builds infrastructure are also not
reproducing this build failure, as far as I can see.

The failure is that the upstream build system runs
`deutex -h | grep -qw PNG` and asserts that the exit status is 0 (i.e. the
help mentions PNG somewhere), as a way to fail early if built by a version
of deutex that was built without PNG support.

The version of deutex in Debian *is* built with PNG support, and does
mention it in help output; and both of my rebuilds (successful and failing)
are using the same version of deutex that was seen in Santiago's build log.
So I would have expected that all three builds would have the same
behaviour, either all successful or all failing.

At first I thought that maybe it wasn't finding /usr/games/deutex in the
PATH, but debian/rules explicitly prepends /usr/games to PATH, and in any
case my sbuild logs say the PATH already included it, the same as in
Santiago's log:

> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

The differences between the .dsc file in the archive and my
locally-rebuilt .dsc file are only timestamps (in my rebuilt .dsc,
dpkg-source has set all timestamps to the ${SOURCE_DATE_EPOCH}), and
the fact that my rebuilt .dsc is unsigned:

--- /home/smcv/tmp/deb/build/freedoom_20240930t094628/freedoom_0.13.0-1.dsc
+++ /home/smcv/tmp/deb/build/freedoom_latest/freedoom_0.13.0-1.dsc
├── GPG header
│ @@ -1,2 +0,0 @@
│ --BEGIN PGP SIGNED MESSAGE-
│ -Hash: SHA256
├── Files
│ @@ -1,3 +1,3 @@
│
│   6f391230509aaeb943c5b18f6890af4e 18520091 freedoom_0.13.0.orig.tar.gz
│ - bef1f6130faebd9ff116de20a62a2340 7388 freedoom_0.13.0-1.debian.tar.xz
│ + 3e1c69dc1585b8c8cd8e2b02527266f0 7376 freedoom_0.13.0-1.debian.tar.xz
├── GPG signature
│ @@ -1,17 +0,0 @@
│ --BEGIN PGP SIGNATURE-
│ -
│ -iQJGBAEBCAAwFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmW9VK4SHGZhYmlhbkBk
…
│ -=bC4T
│ --END PGP SIGNATURE-
├── filetype from file(1)
│ @@ -1 +1 @@
│ -PGP signed message
│ +ASCII text
├── freedoom_0.13.0-1.debian.tar.xz
│ ├── freedoom_0.13.0-1.debian.tar
│ │ ├── file list
│ │ │ @@ -1,10 +1,10 @@
│ │ │  drwxr-xr-x   0000 2024-02-02 20:42:23.00 
debian/
│ │ │  -rw-r--r--   00012942 2024-02-02 20:42:23.00 
debian/changelog
│ │ │ --rw-r--r--   000 2137 2024-02-02 20:41:54.00 
debian/control
│ │ │ --rw-r--r--   000 4458 2024-02-02 20:38:03.00 
debian/copyright
│ │ │ --rwxr-xr-x   000 1046 2024-02-02 20:12:39.00 
debian/rules
│ │ │ -drwxr-xr-x   0000 2024-02-02 20:12:39.00 
debian/source/
│ │ │ --rw-r--r--   000   12 2024-02-02 20:12:39.00 
debian/source/format
│ │ │ -drwxr-xr-x   0000 2024-02-02 20:12:39.00 
debian/upstream/
│ │ │ --rw-r--r--   000  178 2024-02-02 20:12:39.00 
debian/upstream/metadata
│ │ │ --rw-r--r--   000  174 2024-02-02 20:41:14.00 
debian/watch
│ │ │ +-rw-r--r--   000 2137 2024-02-02 20:42:23.00 
debian/control
│ │ │ +-rw-r--r--   000 4458 2024-02-02 20:42:23.00 
debian/copyright
│ │ │ +-rwxr-xr-x   000 1046 2024-02-02 20:42:23.00 
debian/rules
│ │ │ +drwxr-xr-x   0000 2024-02-02 20:42:23.00 
debian/source/
│ │ │ +-rw-r--r--   000   12 2024-02-02 20:42:23.00 
debian/source/format
│ │ │ +drwxr-xr-x   0000 2024-02-02 20:42:23.00 
debian/upstream/
│ │ │ +-rw-r--r--   000  178 2024-02-02 20:42:23.00 
debian/upstream/metadata
│ │ │ +-rw-r--r--   000  174 2024-02-02 20:42:23.00 
debian/watch

I suspect that re-uploading freedoom with no changes other than the
changelog entry, or with only janitorial changes like updating the
Standards-Version, would "accidentally" resolve this - but I don't
understand why the rebuild changes anything.

I'm very tempted to downgrade this to non-RC, on the basis that the build
failure is not preventing binNMUs (this package is Architecture: all
and therefore can't be binNMU'd anyway), is not p

Bug#1082763: flatpak-builder: Unable to build apps using the 24.08 SDK

[Simon McVittie]

On Wed, 25 Sep 2024 at 22:42:44 +0200, Felix Geyer wrote:
> It seems difficult to backport these changes to 1.2.

Yes, I suspect you're right.

> What do you think about at least providing 1.4 in bookwork-backports?
> I can upload that if you don't mind. It's working fine for me in bookworm 
> without
> any changes.

The whole flatpak family usually backports relatively easily - they're
designed to have relatively light dependencies on anything outside that
immediate family of packages.

If flatpak-builder is something you use regularly, would you be able to
help to maintain it? I would welcome co-maintainers. I don't really use
it myself (other than for smoke-testing), so I'm only uploading it for
others' benefit. It's in the debian team on Salsa, so you probably have
commit access already.

And, for the more immediate question, if you can maintain flatpak-builder
in bookworm-backports for the lifetime of bookworm, please go ahead.

Thanks,
smcv

Bug#1082927: flatpak [LTS]: CVE-2024-42472: sandbox escape for apps with --persist=DIR permission

[Simon McVittie]

Source: flatpak
Version: 1.10.8-0+deb11u2
Severity: grave
Justification: user security hole
Tags: bullseye security
X-Debbugs-Cc: debian-...@lists.debian.org
Control: found -1 1.2.5-0+deb10u4
Control: fixed -1 1.14.10-1~deb12u1
Control: fixed -1 1.14.10-1
Control: fixed -1 1.15.10-1

Advisory:
https://github.com/flatpak/flatpak/security/advisories/GHSA-7hgv-f2j8-xw87

This is fixed in stable, testing and unstable but I'm opening a bug to
represent this in (E)LTS. I am not intending to work on this vulnerability
in (E)LTS myself.

For context, Flatpak is a desktop-oriented app framework, allowing
sandboxed apps (potentially much newer than the base OS) to be
installed onto any distribution. I don't know whether the LTS team are
interested in supporting it or not: it will depend on your user-base. On
desktop/laptop-style interactive GUI systems, it might be considered
important/interesting for LTS because it's a way to install newer apps on
an old OS. Conversely, on servers and appliance-style embedded systems,
it's probably entirely uninteresting.

This particular vulnerability is awkward to fix because a complete
fix requires a new feature (the --bind-fd and --ro-bind-fd options)
in bubblewrap, one of Flatpak's dependencies.

There are several options for how it could be addressed:

1. Update bubblewrap to 0.10.0, and give Flatpak a versioned dependency
   on it. This is what we did in unstable and experimental, and in the
   Flatpak team's backports PPAs for Ubuntu noble and jammy:
   
https://salsa.debian.org/debian/flatpak/-/commit/0b47cdbb10d5183239299dba27053055d8fa1ec0
   I imagine that (E)LTS will not want to do this.

2. Backport the --bind-fd feature to an older bubblewrap, give Flatpak a
   suitable versioned dependency on it, and release both packages in a
   single DLA. This is what we did for Flatpak 1.14.10 in Debian 12
   'bookworm':
   
https://salsa.debian.org/debian/bubblewrap/-/commit/258ab8fb3a3faa54a811631d81fe43b9ca2d2936
   
https://salsa.debian.org/debian/flatpak/-/commit/37a25fd50181e93f5329c8cfbec7f69dce406a63

3. Instead of using the bwrap package, build Flatpak with its vendored
   convenience copy (`--without-system-bubblewrap`), and if necessary
   backport the new feature into that (in the 1.14.10 upstream release,
   this was already done, by releasing bubblewrap 0.6.3 and updating the
   vendored copy accordingly). This is what we did in the Flatpak team's
   backports PPAs for Ubuntu focal and bionic:
   
https://github.com/flatpak/ppa-flatpak/commit/e22a18b1ba36c39515750bf1fcf99bf2206b7e0d
   (bubblewrap and xdg-dbus-proxy are orthogonal, it is very easy to use
   a vendored copy of one and a system copy of the other if you want)

4. Only apply a partial solution (mitigation) for the CVE, which doesn't
   require touching bubblewrap. The gap here is that if an instance of a
   malicious or compromised app runs in parallel with a second instance
   being started, it can attempt to exploit a race condition to give the
   second instance access to files outside the sandbox (probably difficult
   to achieve in practice, but I'm not a professional exploit developer,
   and maybe there is a trick that can make the timing easier).

5. Old versions of Flatpak are decreasingly useful as time goes on due to
   third-party Flatpak apps requiring features of a newer Flatpak, so
   if Flatpak is seen as important for LTS, the LTS team could decide to
   base their flatpak package on bookworm/bullseye-backports instead of
   on bullseye-security, similar to the way buster ELTS uses a backported
   kernel. This is what I would personally do if I found myself wanting to
   use Flatpak to install a newer third-party app onto a bullseye or even
   buster system, but I realise it's contrary to how LTS usually works.
   Upstream, we aim to avoid adding new dependencies to Flatpak 1.14.x for
   as long as it is supported. The new dependency that was needed to fix
   this CVE was exceptional, and we would not have done it if we saw
   another option.

6. Or, if Flatpak is not seen as important for (E)LTS, the (E)LTS teams
   could decide to add it to the list of packages with limited support
   ("only suitable for installing completely trusted apps"), or with no
   security support at all.

For reference, the versions of flatpak and bubblewrap in various suites are:

* bookworm stable
  - latest flatpak 1.14.x release, currently 1.14.10
- contains a vendored copy of bubblewrap 0.6.3, currently unused
  - bubblewrap 0.8.0 + backported --bind-fd

* bullseye LTS
  - flatpak 1.10.8 (1.10.x is recently EOL upstream)
- contains a vendored copy of bubblewrap from an intermediate commit
  between 0.4.1 and 0.5.0, currently unused
  - bubblewrap 0.4.1 + some backported bug fixes (similar to the version
vendored into flatpak 1.10.x)

* buster ELTS
  - flatpak 1.2.5 (1.2.x is very much EOL upstream)
- contains a vendored copy of bubblewrap 0.3.0, currently unused
  - bubblewrap 0.3.1 

Bug#1082885: debian-security-support: please mark src:vte as unsupported

[Simon McVittie]

Package: debian-security-support
Severity: wishlist
Tags: security

As discussed on https://bugs.debian.org/1081907, the only reason why
src:vte is still in the archive is because debian-installer is still
using GTK 2 (and the only reason why it compiles .deb and not just .udeb
is in an attempt to make it somewhat easier to debug d-i-related issues).

For anything outside the installer, the replacement is src:vte2.91, which
is compiled in GTK 3 and GTK 4 flavours (but does not support GTK 2).

The GNOME team does not intend to support the use of src:vte for untrusted
content, and we don't intend to fix DoS vulnerabilities like #1081907,
or any bugs at all, really (unless they are critical for d-i). We've been
trying to remove src:vte from the archive since at least 2017.

I'm not sure whether this would be better represented in d-s-s as
"limited support" or "EOL", but I feel as though it probably ought to
be one of those.

Thanks,
smcv

Bug#1081907: vte: CVE-2024-37535

[Simon McVittie]

Control: tags -1 + wontfix

On Fri, 27 Sep 2024 at 15:34:33 +0200, Moritz Mühlenhoff wrote:
> Am Sun, Sep 15, 2024 at 11:03:42PM +0100 schrieb Simon McVittie:
> > I think this is wontfix. The only reason why the GTK2-based vte is still
> > in Debian at all is for the benefit of debian-installer, which hasn't
> > caught up with GTK3 yet.
>
> Feel free to mark the bug as wontfix or even close it, both seem fine
> (there's a public reference in the Security Tracker anyway).

Doing so now.

Thanks,
smcv

Bug#1082750: qemu-system-misc: uninstallable in unstable: depends on opensbi (>> 1.5.1-1)

[Simon McVittie]

Package: qemu-system-misc
Version: 1:9.1.0+ds-4
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: open...@packages.debian.org

qemu-system-misc version 1:9.1.0+ds-4 has dependencies that include:

opensbi (>> 1.5.1-1)

where ">>" denotes "strictly greater than". This dependency is not
satisfiable by the opensbi (= 1.5.1-1) in testing/unstable.

Did you perhaps mean (>= 1.5.1-1~), which would be satisfiable by the
current testing/unstable opensbi and also by backports of it, while
not being satisfiable by some hypothetical other distro's forked packaging
1.5.1-0hypothetical1, which might not contain the necessary symlinks?

(I also wonder whether the architecture-specific external firmware
for qemu-system-misc should be Recommends rather than Depends, because
unlike e.g. qemu-system-x86, there's no particular common theme to the
architectures supported by -misc - for example it can presumably still
emulate a s390x machine perfectly well without needing riscv64 firmware,
and vice versa.)

Thanks,
smcv

Bug#1082709: dar-static: Built-Using lists permissively-licensed dependencies

[Simon McVittie]

Package: dar-static
Version: 2.7.15-2
Severity: normal

Policy §7.8 says that the Built-Using field "should be used only when
there are license or DFSG requirements to retain the referenced source
packages". This seems to be true for about half of the dependencies
of dar-static.

dpkg now has a second similar field, Static-Built-Using, which
can/should be used for permissively-licensed dependencies. If I'm
reading correctly, packages with a requirement to retain source code
(most commonly (L)GPL packages) should now be listed in both Built-Using
*and* Static-Built-Using, and packages with no such requirement should
now be listed in Static-Built-Using only. There's more discussion in
.

Taking trixie amd64 as an example, dar-static declares Built-Using on:

argon2 (= 0~20190702+dfsg-4)
bzip2 (= 1.0.8-6)
curl (= 8.9.1-2)
e2fsprogs (= 1.47.1-1)
glibc (= 2.40-2)
gpgme1.0 (= 1.18.0-6)
libassuan (= 2.5.6-1)
libcap2 (= 1:2.66-5)
libgcrypt20 (= 1.11.0-6)
libnsl (= 1.3.0-3)
librsync (= 2.3.4-1.1)
libthreadar (= 1.5.0-1)
libzstd (= 1.5.6+dfsg-1)
lz4 (= 1.9.4-3)
lzo2 (= 2.10-3)
openssl (= 3.3.2-1)
zlib (= 1:1.3.dfsg+really1.3.1-1)

If I'm reading correctly, many of those packages are permissively-licensed
(BSD-style licensing) and therefore we do not need to retain their source
code just because a derivative of it was statically linked into dar-static,
so they can be in Static-Built-Using only:

* argon2: CC0 or Apache-2.0
* bzip2: BSD variant
* curl: MIT variant
* libcap2: BSD or GPL, we can choose BSD
* libzstd: BSD or GPL, we can choose BSD
* lz4: library code is BSD
* openssl: Apache-2.0
* zlib: BSD-style

Other packages still *do* need to be in Built-Using, because they are
copyleft:

* e2fsprogs: GPL
* glibc: LGPL
* gpgme1.0: variously LGPL and GPL
* libassuan: LGPL
* libgcrypt20: LGPL
* libnsl: LGPL
* librsync: LGPL
* libthreadar: LGPL
* lzo2: GPL

For example, in the current state of the archive, I think dropping curl
from dar-static's Built-Using would allow curl (= 8.10.0-2), which is
newer than testing but older than unstable, to be dropped.

smcv

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Simon McVittie]

On Wed, 21 Aug 2024 at 23:45:30 +0200, Guillem Jover wrote:
> On Sat, 2024-04-27 at 17:40:49 +0800, Maytham Alsudany wrote:
> > +A package statically linked with the libraries contained in the
> > +librust-gtk4-dev and librust-pulsectl-rs-dev binary packages, where
> > +the latter is licensed under GPL-3+ (a license that requires full
> > +source code to be available), would have these fields in its control
> > +file:
> > +
> > +::
> > +
> > +Built-Using: rust-pulsectl-rs (= 0.3.2-1+b1)
> > +Static-Built-Using: rust-gtk4 (= 0.7.3-3), rust-pulsectl-rs (= 
> > 0.3.2-1+b1)

With this interpretation of the relationship between the two fields,
is there any situation where a source package would validly appear in
Built-Using but not in Static-Built-Using? (Other than the obvious
"this package has not yet been updated to implement Static-Built-Using")

Thanks,
smcv

Bug#1082659: libunwind8: 1.7 regression: Xvfb segfaults on armhf

[Simon McVittie]

Package: libunwind8
Version: 1.7.2-1
Severity: serious
Justification: results in FTBFS in unrelated packages
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: armhf

The test suite for the libportal package, like many packages that use
GUI libraries, is run under Xvfb:

xvfb-run -a -s "-noreset" dh_auto_test -- $(options)

In a recent upload this failed on armhf, and only armhf: the actual
tests appear to have all succeeded, but then xvfb-run exited with status
1 anyway. I am able to reproduce this on the armhf porterbox amdahl.

A simplified reproducer is:

xvfb-run -e /dev/stderr -a -s "-noreset" true

which should exit 0, or

Xvfb :42 -noreset -nolisten tcp

which should start and wait until terminated (assuming the socket for :42
is available).

Running `gdb --args Xvfb :42 -noreset -nolisten tcp` produces this
backtrace inside libunwind:

#0  _ULarm_step (cursor=cursor@entry=0xfffe68f0) at arm/Gstep.c:175
#1  0xf7ea5596 in trace_init_addr (f=, cursor=0xfffe68f0, 
cfa=, pc=,
r7=, sp=) at 
../include/tdep-arm/libunwind_i.h:144
#2  trace_lookup (cursor=0xfffe68f0, cache=, cfa=, pc=,
r7=, sp=) at arm/Gtrace.c:334
#3  _ULarm_tdep_trace (cursor=cursor@entry=0xfffe68f0, 
buffer=buffer@entry=0xfffee918, size=size@entry=0xfffe6828)
at arm/Gtrace.c:452
#4  0xf7ea3692 in unw_backtrace (buffer=buffer@entry=0xfffee918, 
size=size@entry=1) at mi/backtrace.c:70
#5  0x0050d9f2 in OsInit () at ../../../../os/osinit.c:217
#6  0x004d24c4 in dix_main (argc=5, argv=0xfffefc74, envp=) at 
../../../../dix/main.c:151
#7  0xf7b374fa in __libc_start_call_main (main=main@entry=0x4277d5 , 
argc=argc@entry=5, argv=0xfffefc74,
argv@entry=0xf7c27e44) at ../sysdeps/nptl/libc_start_call_main.h:58
#8  0xf7b3759e in __libc_start_main_impl (main=0x4277d5 , argc=5, 
argv=0xf7c27e44, init=,
fini=0x0, rtld_fini=0xf7fd399d <_dl_fini>, stack_end=0xfffefc74) at 
libc-start.c:360
#9  0x00427800 in _start ()

This appears to be a regression between trixie (where xvfb-run and Xvfb
work as I had expected) and sid (where Xvfb crashes).

For whatever reason, if I run xvfb-run with arguments that include
`-s "-screen 0 1280x1024x24 -noreset"` instead of just `-s "-noreset"`,
Xvfb doesn't crash.

The system information below is from an armhf chroot on amdahl where I
could reproduce this.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: armhf (armv8l)

Kernel: Linux 6.1.0-25-arm64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libunwind8 depends on:
ii  libc6  2.40-2
ii  libgcc-s1  14.2.0-5
ii  liblzma5   5.6.2-2

libunwind8 recommends no packages.

libunwind8 suggests no packages.

-- no debconf information

Bug#1082625: mesa: llvm 19 regression: llvmpipe/lavapipe logs message: '-avx512er' is not a recognized feature for this target (ignoring feature)

[Simon McVittie]

Source: mesa
Version: 24.2.3-1
Severity: normal
Tags: upstream patch
Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11870

Since Mesa moved from LLVM 18 to 19, running programs with the lavapipe
or llvmpipe driver logs these messages, sometimes repeatedly:

> '-avx512er' is not a recognized feature for this target (ignoring feature)
> '-avx512pf' is not a recognized feature for this target (ignoring feature)

In particular this caused a test failure for a validation tool in GTK 4,
which I've worked around in src:gtk4 by running that particular test with
GALLIUM_DRIVER=softpipe for now.

Simple reproducers, with mesa-utils and vulkan-tools installed:

LIBGL_ALWAYS_SOFTWARE=1 glxgears
VK_LOADER_DRIVERS_SELECT='lvp*' vkcube

I believe https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31321
should be a solution for this (not verified).

smcv

Bug#1082588: libportal: FTBFS on armhf: tests pass but then command exits with status 1

[Simon McVittie]

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

My recent libportal upload repeatably fails to build on armhf buildds,
with a failure mode that I don't understand. It built successfully on
all other release architectures, and on all -ports architectures where
a build was attempted so far.

To work around an unreliable upstream test-case ("pytest"), it runs this:

override_dh_auto_test:
xvfb-run -a -s "-noreset" dh_auto_test -- $(meson_test_options) 
--no-suite pytest
xvfb-run -a -s "-noreset" dh_auto_test -- $(meson_test_options) --suite 
pytest || true

The first of those two commands seems to be entirely successful:

> xvfb-run -a -s "-noreset" dh_auto_test -- --timeout-multiplier 3 --no-suite 
> pytest
>   cd obj-arm-linux-gnueabihf && DEB_PYTHON_INSTALL_LAYOUT=deb 
> LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-multiplier 3 
> --no-suite pytest
> ninja: Entering directory `/<>/obj-arm-linux-gnueabihf'
> ninja: no work to do.
> 1/2 libportal:qt5 / Qt 5 unit test OK  0.07s
> 2/2 libportal:qt6 / Qt 6 unit test OK  0.10s
> 
> Ok: 2
> Expected Fail:  0
> Fail:   0
> Unexpected Pass:0
> Skipped:0
> Timeout:0
> 
> Full log written to 
> /<>/obj-arm-linux-gnueabihf/meson-logs/testlog.txt

but then the next line of output is:

> make[1]: *** [debian/rules:87: override_dh_auto_test] Error 1

which I don't understand. Is this perhaps an architecture-specific bug in
xvfb-run, dh_auto_test or meson causing one of them to exit 1 even though
testing was successful?

smcv

Bug#1082570: libportal: FTBFS: Fatal Python error: Segmentation fault

[Simon McVittie]

Control: severity -1 important

On Sun, 22 Sep 2024 at 14:28:09 +0200, Santiago Vila wrote:
> I suggest that the test is disabled and the bug is forwarded until
> they fix it.

In version 0.8.1-1 this test is still run, but its result is ignored.

> My offer for a VM to reproduce this still holds if it helps
> (but maybe you could try GRUB_CMDLINE_LINUX="nr_cpus=1" first).

I have already put a significant amount of time into trying to chase this,
and I cannot guarantee to be able to set more time aside soon enough that
it would make externally-provided resources like a remote VM useful. I'm
sorry that doing my best has not been enough.

I will try to reproduce this in a VM with limited CPUs if time permits,
but, again, I cannot provide any guarantees. Sorry.

smcv

Bug#1082570: libportal: FTBFS: Fatal Python error: Segmentation fault

[Simon McVittie]

Control: retitle -1 libportal: intermittent FTBFS: Segmentation fault in pytest
Control: forwarded -1 https://github.com/flatpak/libportal/issues/169

On Sun, 22 Sep 2024 at 13:55:01 +0200, Santiago Vila wrote:
> test: pytest
> result:   killed by signal 11 SIGSEGV
...
>   File "/<>/tests/pyportaltest/test_inputcapture.py", line 88 in 
> create_session_with_barriers
>   File "/<>/tests/pyportaltest/test_inputcapture.py", line 269 
> in test_session_create_no_zones_on_getzones

This is an intermittent test failure, which I experienced while trying
to upgrade to 0.8.1. I have only been able to reproduce it by running
the test suite repeatedly in a loop, and it's extremely timing-dependent
(when I tried to add additional debug logging, that perturbed the timing
enough that I could no longer reproduce it).

There is another intermittent test failure,
https://github.com/flatpak/libportal/issues/166, which is similarly
difficult to reproduce.

smcv

Bug#1082529: gnome-characters: application fails to start 'Gjs_MainWindow': .:0:0 Invalid object type 'AdwSpinner'

[Simon McVittie]

On Sat, 21 Sep 2024 at 17:16:45 +0200, SubOptimal wrote:
> starting the application from command line reveals the following error
...
> Invalid object type 'AdwSpinner'

Please try with libgtk-4-1 and libadwaita-1-0 from unstable? Perhaps this
package has an undeclared dependency on those newer versions.

Thanks,
smcv

Bug#1082518: openmsx-catapult: autopkgtest requires gdm3:armel which no longer exists

[Simon McVittie]

Source: openmsx-catapult
Severity: important
Tags: patch trixie sid
Control: block 1080521 by -1

The Debian GNOME team is in the process of removing gjs, and therefore
gnome-shell and gdm3, from armel, because the upgrade to mozjs128 has
made it impractical to support architectures whose baseline does not
include atomic operations.

openmsx-catapult has an autopkgtest that installs gdm3. Please exclude
armel from the list of architectures where this test is expected to be
runnable, for example by applying the attached patch.

I'm reasonably sure that gdm3 is not actually required for this test:
the test runs xvfb-run, which does not require a display manager. However,
I don't know the specifics of this package or whether it has non-obvious
dependencies on some GNOME component.

If you can reduce the test's dependencies to avoid a dependency on
gdm3 and gnome-shell so that it is still runnable on armel, that would
be an equally valid solution.

Thanks,
smcv
>From 500a8026d25954f0e48c1849faeaaab2c97dee5f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 Sep 2024 14:36:10 +0100
Subject: [PATCH] d/tests/control: Don't require gdm3 on armel

gdm3 is no longer available on armel due to the removal of gjs and
gnome-shell, prompted by the upgrade from mozjs115 (which supported
architectures without atomic operations) to mozjs128 (which does not).
See #1080521.

Closes: #-1
---
 debian/tests/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/tests/control b/debian/tests/control
index e641d69..d7e02f3 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,4 @@
 Tests: run
+Architecture: !armel
 Depends: xvfb, xauth, psmisc, xvkbd, python3-dogtail, openmsx-catapult, at-spi2-core, libglib2.0-bin, dbus, dbus-x11, gdm3
 Restrictions: allow-stderr, flaky
-- 
2.45.2

Bug#1082519: gtg: autopkgtest requires gdm3:armel which no longer exists

[Simon McVittie]

Source: gtg
Severity: important
Tags: patch trixie sid
Control: block 1080521 by -1

The Debian GNOME team is in the process of removing gjs, and therefore
gnome-shell and gdm3, from armel, because the upgrade to mozjs128 has
made it impractical to support architectures whose baseline does not
include atomic operations.

gtg has an autopkgtest that installs gdm3. Please exclude armel from
the list of architectures where this test is expected to be runnable,
for example by applying the attached patch.

I'm reasonably sure that gdm3 is not actually required for this test:
the test runs xvfb-run, which does not require a display manager. However,
I don't know the specifics of this package or whether it has non-obvious
dependencies on some GNOME component.

If you can reduce the test's dependencies to avoid a dependency on
gdm3 and gnome-shell so that it is still runnable on armel, that would
be an equally valid solution.

Thanks,
smcv
>From 69784ce68e0e1f46817cd06b85eb150cfd4c4d63 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 Sep 2024 14:42:47 +0100
Subject: [PATCH] d/tests/control: Don't require gdm3 on armel

gdm3 is no longer available on armel due to the removal of gjs and
gnome-shell, prompted by the upgrade from mozjs115 (which supported
architectures without atomic operations) to mozjs128 (which does not).
See #1080521.

Closes: #-1
---
 debian/tests/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/tests/control b/debian/tests/control
index ba853412..7099adde 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -3,5 +3,6 @@ Depends: gtg, gir1.2-secret-1
 Restrictions: superficial
 
 Test-Command: xvfb-run debian/tests/check-graphical-app
+Architecture: !armel
 Depends: gtg, gir1.2-secret-1, python3-dogtail, xvfb, xauth, gdm3, dbus, dbus-x11, at-spi2-core
 Restrictions: allow-stderr
-- 
2.45.2

Bug#1082516: systemd: please stop installing gdm3:armel in autopkgtests

[Simon McVittie]

Source: systemd
Severity: important
Tags: patch trixie sid
Control: block 1080521 by -1

The Debian GNOME team is in the process of removing gjs, and therefore
gnome-shell and gdm3, from armel, because the upgrade to mozjs128 has
made it impractical to support architectures whose baseline does not
include atomic operations.

systemd has a couple of autopkgtests that install gdm3 on desktop-capable
architectures, but not on s390x or riscv64. Please add armel to the list
of architectures where this is not done.

(If you would like to have these tests continue to exercise some sort
of display manager on armel, you could add something like
"lightdm [armel]" to these tests' dependencies, but that's out of scope
for this particular request.)

Thanks,
smcv
>From f6b9117c46ab57a0eea9801212de5a87540ec76a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 Sep 2024 14:23:34 +0100
Subject: [PATCH] d/tests/control: Don't require gdm3 on armel

gdm3 is no longer available on armel due to the removal of gjs and
gnome-shell, prompted by the upgrade from mozjs115 (which supported
architectures without atomic operations) to mozjs128 (which does not).
See #1080521.

Closes: #-1
---
 debian/tests/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 857416db8a..36cfbb4d2c 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -85,7 +85,7 @@ Depends: systemd-sysv,
   libelf-dev,
   xserver-xorg-video-dummy,
   xserver-xorg,
-  gdm3 [!s390x !riscv64],
+  gdm3 [!armel !s390x !riscv64],
   cron,
   network-manager,
   busybox-static,
@@ -135,7 +135,7 @@ Tests: boot-smoke
 Depends: systemd-sysv,
   systemd-resolved,
   network-manager,
-  gdm3 [!s390x !riscv64],
+  gdm3 [!armel !s390x !riscv64],
   xserver-xorg-video-dummy,
 Restrictions: needs-root, isolation-container, allow-stderr, breaks-testbed
 
-- 
2.45.2

Bug#987802: libglib2.0-dev: /usr/share/glib-2.0/gdb/*.pyc not removed if created

[Simon McVittie]

Control: retitle -1 libglib2.0-dev: /usr/share/glib-2.0/gdb/*.pyc not removed 
if created
Control: severity -1 minor
Control: tags -1 + pending

On Fri, 30 Apr 2021 at 02:42:34 +0200, Christoph Anton Mitterer wrote:
> Upon [purging libglib2.0-dev] there were some leftovers:
>
> Removing libglib2.0-dev:amd64 (2.66.8-1) ...
> dpkg: warning: while removing libglib2.0-dev:amd64, directory 
> '/usr/share/glib-2.0/gdb' not empty so not removed
> 
>  l /usr/share/glib-2.0/gdb/
> total 25k
> drwxr-xr-x 1 root root   38 Apr 30 00:44 .
> drwxr-xr-x 1 root root   76 Apr 30 00:44 ..
> -rw-r--r-- 1 root root 9,8k May 31  2015 glib.pyc
> -rw-r--r-- 1 root root  11k May 31  2015 gobject.pyc

Normally this does not happen:

$ podman run --rm -it debian:sid-slim
# apt update
...
# apt upgrade
...
# apt install libglib2.0-dev
...
# apt purge libglib2.0-dev
...
Removing libglib2.0-dev:amd64 (2.82.0-1) ...
Processing triggers for libglib2.0-0t64:amd64 (2.82.0-1) ...
No schema files found: doing nothing.
# apt autoremove --purge
(no warnings about /usr/share/glib-2.0/gdb here either)

I believe the root cause for you having seen this warning is that
you have run gdb *as root* to debug a program that uses GLib, which
results in /usr/share/glib-2.0/gdb/*.py being byte-compiled as a
side-effect. Normally, if you run gdb as an unprivileged user, this does
not happen, because the unprivileged user doesn't have write access to
/usr/share/glib-2.0/gdb. A reproducer:

$ podman run --rm -it debian:sid-slim
# apt update
...
# apt upgrade
...
# apt install libglib2.0-dev gdb
...
# gdb --args gio cat /dev/null
...
(gdb) run
(gdb) exit
# apt purge libglib2.0-dev
...
Removing libglib2.0-dev:amd64 (2.82.0-1) ...
dpkg: warning: while removing libglib2.0-dev:amd64, directory 
'/usr/share/glib-2.0/gdb' not empty so not removed

I believe this can be resolved by migrating /usr/share/glib-2.0/gdb into
libglib2.0-dev-bin or libgio-2.0-dev-bin package, and registering its
contents with dh_python.

smcv

Bug#1082505: gnome-console: crashes on startup: double free or corruption (out)

[Simon McVittie]

Control: retitle -1 gnome-console: crashes on startup: double free or 
corruption (out)
Control: reassign -1 gnome-console
Control: tags -1 + moreinfo

On Sat, 21 Sep 2024 at 11:22:06 +0200, 1...@gmx.us wrote:
> Looks like it was a coincidence that it worked for a couple of times after 
> installing libvte-2.91-0. Because it stopped working and instead got this 
> message.
> 
> $ kgx
> 
> (kgx:8877): Gtk-WARNING **: 11:16:41.855: Unable to acquire the address of 
> the accessibility bus: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: 
> The name org.a11y.Bus was not provided by any .service files. If you are 
> attempting to run GTK without a11y support, GTK_A11Y should be set to 'none'.
> double free or corruption (out)
> Aborted

I'm reassigning this to gnome-console (kgx) because with the information
available, it is not possible to know whether this is a bug in libvte,
GTK, gnome-console or something else. If it started with a libvte upgrade,
then it's perhaps most likely to be a libvte bug, but we don't yet know
that for sure.

This is not happening for everyone (I'm typing this message into a
gnome-console right now) so we will need more information.

Please run `reportbug --template gnome-console` to collect information
about the libraries that gnome-console depends on and what their
versions are. If you report bugs by using reportbug in future, then this
step will not be necessary.

Also please try to get a backtrace from this crash:
https://wiki.debian.org/HowToGetABacktrace

Thanks,
smcv

Bug#1082505: Unclear dependency on libvte-2.91-0

[Simon McVittie]

On Sat, 21 Sep 2024 at 11:02:22 +0200, 1...@gmx.us wrote:
> After updating libvte-2.91-gtk4-0 from version 0.77.92-1 to 0.78.0-1,
> gnome-console would not start. Installing libvte-2.91-0 fixes the issue.

Did anything else change in the same apt transaction where you installed
libvte-2.91-0? Please look at /var/log/apt/history.log and
/var/log/apt/term.log.

(For example, perhaps upgrading libvte-2.91-gtk4-0 didn't initially
upgrade libvte-2.91-common, but installing libvte-2.91-0 pulled in a
newer version?)

Thanks,
smcv

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#1081957: libgtk-4-1: libgtk-4-1: vulkan renderer crashes on startup under kwin-wayland

[Simon McVittie]

Control: retitle -1 libgtk-4-1: vulkan renderer crashes on startup under 
kwin-wayland

On Mon, 16 Sep 2024 at 19:25:35 +0200, Zoltán wrote:
> Since installing the new version on sid gtk4 applications crash on
> startup with SIGSEGV.
> 
> The crash seems to occur with the vulkan renderer, disabling it with
> GDK_DISABLE=vulkan things run fine.
> 
> I'm running a kde desktop on wayland (kwin-wayland 4:5.27.11-2)
> on AMD with mesa-vulkan-drivers 24.2.2-1

On Fri, 20 Sep 2024 at 18:39:43 +0200, Michael Biebl wrote:
> My backtrace looks slightly different though, maybe a result of having
> fractional scaling enabled (150% for the external and internal monitor).
> 
> @Simon: If you think we should split this into two separate bug reports,
> please let me know.

Let's keep it as one bug for now.

Zoltán, do you also have desktop scaling enabled?

smcv

Bug#1082389: RM: src:gjs and rdeps [armel] -- RoM/RoQA; #1080521

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org, eos-...@packages.debian.org, 
foli...@packages.debian.org, 
gnome-shell-extension-panel-...@packages.debian.org, 
gnome-shell-pomod...@packages.debian.org, gpa...@packages.debian.org, 
debian-...@lists.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Control: block -1 by 1082122
Control: block 1080521 by -1

The GNOME team recently uploaded a version of gjs that uses mozjs128,
which is not available on armel. For this to be able to migrate, we'll
need to remove the old binaries for gjs from armel, together with packages
that depend on it.

First, please remove only the NBS gdm3 binary package (but *not* its
other binary packages such as libgdm1!) as requested in #1082122.

Then, please remove all armel packages that were built by one of these
source packages:

eos-sdk
foliate
gnome-characters
gnome-maps
gnome-shell
gnome-shell-extension-manager
gnome-shell-extension-panel-osd
gnome-shell-pomodoro
gnome-sound-recorder
gnome-sushi
gpaste
polari

These packages are listed as having their Build-Depends broken by removal
of gjs, but I believe they are false positives and should not be removed,
because they all build-depend on gjs [amd64 arm64 armhf ...] or
gjs [!armel !s390x] or similar:

- gdm3
- glade
- libguestfs
- libsecret
- ostree

Similarly these packages are listed as having their Build-Depends broken
by removal of gjs/gnome-shell/etc., but I believe they are false positives
and do not need to be removed, because they only build Architecture: all
binaries and therefore do not need to be buildable on armel:

- arc-theme
- gnome-shell-extension-caffeine
- gnome-shell-extensions-extra

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#1082277: please rename pypi transmission-rpc package to python3-transmission-rpc if you want to package then as debian package

[Simon McVittie]

On Thu, 19 Sep 2024 at 23:40:55 +0800, trim21 wrote:
> I recently found that you are packaging this pypi package in debian
> testing and unstable repo as `python3-transmissionrpc`, and it's
> originally pypi package transmissionrpc.
> 
> This package is forked from the original pypi transmissionrpc package
> and renamed as transmission-rpc on pypi.
> 
> I don't want it to cause confusion between these two package names,
> can we rename it to `python3-transmision-rpc` instead?

Debian's policy is to name Python packages according to the name that
you can `import`, not the PyPI name:
https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names
What name do you `import` to use this package?

If you would use `from transmissionrpc import ...` then
python3-transmissionrpc is considered correct for Debian, regardless of
whether that module name is provided by a fork or by the original.

But if you would use `from transmission_rpc import ...` then yes, it
should ideally be renamed to python3-transmission-rpc (underscores are
not allowed in Debian package names, so the convention is to replace
them with dashes) because it no longer has an API that is compatible
with the transmissionrpc module.

Renaming a package is not something that the package's maintainer can
do immediately - it requires approval from the archive administrators,
who are very busy and have a long queue of packages needing review in
https://ftp-master.debian.org/new.html - so if a rename is required,
please be patient.

smcv

Bug#1082212: Depends/Build-Depends cycle with libgtk-4-dev

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 19 Sep 2024 at 20:43:15 +0900, Simon Richter wrote:
> when bootstrapping gtk 4, libsysprof-4-dev is one of the indirect build
> dependencies of gtk-4, but itself depends on libgtk-4-dev.

libsysprof-4-dev is obsolete and no longer exists in testing/unstable. It
was my understanding that new architectures are bootstrapped in unstable,
and we do not support adding new architectures to an existing stable
release, at least not without deploying a time machine that I don't have
access to? Is that wrong?

In the trixie cycle, packages that have sysprof capture integration
(instrumentation that feeds extra information into sysprof), like glib2.0
and gtk4, should only Build-Depend on libsysprof-capture-4-dev which is
a more minimal package without GLib or GTK dependencies.

Those packages should also limit their dependency on
libsysprof-capture-4-dev to architectures where sysprof already exists
(which means it is irrelevant when bootstrapping new architectures),
and ideally they should have a build profile to turn off the sysprof
integration if re-bootstrapping an existing architecture (for example
glib2.0 has pkg.glib2.0.nosysprof which can be used if a re-bootstrap
is required).

For gtk4 the cycle can also be broken from the sysprof end, by building
sysprof with the pkg.sysprof.nogui build profile (see below).

gtk4 does not currently have a pkg.gtk4.nosysprof build profile, but it
should be easy to add if you want to send a patch (debian/rules already
allows building without sysprof on architectures where it isn't buildable,
so it should be a simple matter of wiring up the build profile itself).

I don't think glib2.0 had its sysprof integration enabled in bookworm,
so it presumably didn't participate in any cyclic dependencies.

Helmut Grohne has been testing the re-bootstrapping case by using
GLib's pkg.glib2.0.nosysprof build-profile (and others), e.g. in
https://salsa.debian.org/gnome-team/glib/-/merge_requests/42, and reports
that it is successful when using glib2.0 from experimental.
glib2.0 in unstable has other re-bootstrapping issues unrelated to
sysprof, but fixing those in testing/unstable is currently blocked
by getting the new version of src:architecture-properties migrated
(#1081799), for which I'm waiting for
https://salsa.debian.org/debian/architecture-properties/-/merge_requests/6
to be merged and released.

> It would be nice if there was a way to bootstrap, e.g. splitting off the
> UI classes into a separate libsysprof-4-ui-dev and a build profile
> without these packages

This already exists in testing/unstable. The sysprof development files
have been split into libsysprof-capture-4-dev (minimal dependencies),
libsysprof-6-dev (requires GLib and friends), and the sysprof UI
(requires GTK).

In testing/unstable there is no longer a public shared library for the UI
parts of sysprof, and all of the UI stuff is now internal to sysprof.deb
(which can be turned off by building with -Ppkg.sysprof.nogui).

A pkg.sysprof.nogui build profile for src:sysprof already existed in
bookworm in a different form. I don't know whether that version was fully
effective, but if it wasn't, we can't retroactively fix it in the past.

smcv

Bug#1082122: RM: gdm3 [armel] -- NBS; #1080521

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove

src:gdm3 no longer builds the gdm3 binary package for armel, as another
step towards removing this dependency chain from armel:

[many packages] -> gnome-shell -> gjs -> mozjs128

Please remove the old gdm3 *binary package only* from armel.

We want to keep the source package and the gir1.2-gdm-1.0, libgdm-dev,
libgdm1 binary packages on armel (this avoids some intrusive changes in
other packages like gnome-panel).

Thanks,
smcv

Bug#1082121: libostree-1-1: `flatpak update` fails: src/libostree/ostree-fetcher-curl.c:534:sock_cb: code should not be reached

[Simon McVittie]

Package: libostree-1-1
Version: 2024.7-2
Severity: important
Tags: upstream
Forwarded: https://github.com/ostreedev/ostree/issues/3299
Control: affects -1 + src:flatpak
X-Debbugs-Cc: c...@packages.debian.org

After upgrading curl to 8.10.0, `flatpak update` fails with:

> OSTree:ERROR:src/libostree/ostree-fetcher-curl.c:534:sock_cb: code should not 
> be reached
> Bail out! OSTree:ERROR:src/libostree/ostree-fetcher-curl.c:534:sock_cb: code 
> should not be reached
> [1]21258 IOT instruction (core dumped)  flatpak update

Looking at the line with the assertion failure, it seems that we're
getting CURL_POLL_REMOVE from the CURLMOPT_SOCKETFUNCTION for a socket
that we either didn't add to the table of known sockets yet, or already
removed from the table of known sockets.

According to users of Alpine Linux, the trigger for this was when this
libcurl commit was applied (originally as a patch, now in the upstream
release):
https://github.com/curl/curl/commit/48f61e781a01e6a8dbc4a347e280644b1c68ab6a
but I haven't independently verified this.

smcv

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#1082010: libgdata: unmaintained upstream

[Simon McVittie]

On Tue, 17 Sep 2024 at 09:56:03 -0400, Jeremy Bícha wrote:
> My opinion is that libgdata is the most critical thing blocking
> removal of libsoup2.4 from Debian.

Indeed.

> I think the Google Drive integration is very useful and it would be a
> shame to lose it.

Let's leave it in gvfs if someone (most likely Alessandro Astone?) can
fix the libgdata build for time64 and updated json-glib, but consider
it to be "at risk".

> There were other apps that had extra Google
> integration like gnome-photos but those were lost when libgdata wasn't
> ported to libsoup3

I think we should try to remove the unused libgdata-dev build-dependency
from these, so that we have a more realistic picture of what is actually
using libgdata. I've started looking at some of the GNOME Team packages
in this situation, but it would be better if someone who is a regular
user of the relevant packages could test and upload.

> Except for the libsoup issue, I didn't have other problems with libgdata.

My problem with it is that it seems to be de facto unmaintained upstream.
If the Google Drive integration in gvfs is important, perhaps someone
from Canonical could look after it?

smcv

Bug#1082017: totem: unused build-dependency on unmaintained libgdata-dev

[Simon McVittie]

Source: totem
Version: 43.0-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgdata
Control: block 1082010 by -1

totem has a build-dependency on libgdata, but it doesn't seem to have any
features that would require libgdata any more. Perhaps integration with
Youtube or a similar service was already removed?

libgdata is no longer maintained upstream, so we should clean up unused
dependencies on it to get a more realistic picture of how hard it would
be to remove libgdata.

I'm testing whether the Build-Depends on libgdata-dev can be removed
without affecting the binary package contents.

smcv

Bug#1082016: eog-plugins: unused build-dependency on unmaintained libgdata-dev

[Simon McVittie]

Source: eog-plugins
Version: 44.1-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgdata
Control: block 1082010 by -1

eog-plugins has a leftover build-dependency on libgdata from its old
Picasa integration, but that feature was disabled a while ago to avoid
a libsoup2 dependency.

libgdata is no longer maintained upstream, so we should clean up unused
dependencies on it to get a more realistic picture of how hard it would
be to remove libgdata.

I'm testing whether the Build-Depends on libgdata-dev can be removed
without affecting the binary package contents.

smcv

Bug#1082015: shotwell: (unused?) build-dependency on unmaintained libgdata-dev

[Simon McVittie]

Source: shotwell
Version: 0.32.7-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgdata
Control: block 1082010 by -1

shotwell has a build-dependency on libgdata, but it looks as though this
was only needed for a feature that has been disabled or removed (I haven't
fully confirmed this).

libgdata is no longer maintained upstream, so we should clean up unused
dependencies on it to get a more realistic picture of how hard it would
be to remove libgdata. Please check whether libgdata-dev can be removed
from its Build-Depends.

Thanks,
smcv

Bug#1082014: grilo-plugins: unused build-dependency on unmaintained libgdata-dev

[Simon McVittie]

Source: grilo-plugins
Version: 0.3.16-1.1
Severity: important
Tags: pending
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgdata
Control: block 1082010 by -1

grilo-plugins has a leftover build-dependency on libgdata from its old
Youtube integration, but that feature was disabled a while ago to avoid
a libsoup2 dependency.

libgdata is no longer maintained upstream, so we should clean up unused
dependencies on it to get a more realistic picture of how hard it would
be to remove libgdata.

It looks as though there is already a fix for this pending in the
packaging git repo.

smcv

Bug#1082013: gnome-photos: unused build-dependency on unmaintained libgdata-dev

[Simon McVittie]

Source: gnome-photos
Version: 43~beta-1
Severity: important
Tags: pending
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgdata
Control: block 1082010 by -1

gnome-photos has a leftover build-dependency on libgdata from its old
Google integration, but that feature was disabled in 43~beta to avoid
a libsoup2 dependency. I've verified that removing the build-dependency
does not affect the contents of the binary packages (when working around
the FTBFS by using the nocheck build profile).

libgdata is no longer maintained upstream, so we should clean up unused
dependencies on it to get a more realistic picture of how hard it would
be to remove libgdata.

I'm not actually going to upload the fix for this, because gnome-photos
FTBFS against current gegl (see #1040746, #1040202) and fixing that is not
something I'm particularly interested in investigating. However, I'll push
a change to remove the unused B-D so that if someone is interested in this
package, they won't have to fix the libgdata dependency, only the FTBFS.

smcv

Bug#1082010: libgdata: unmaintained upstream

[Simon McVittie]

Source: libgdata
Severity: important
Tags: trixie sid upstream wontfix
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

According to comments on
,
libgdata is effectively unmaintained upstream. I am not aware of any
obvious replacement.

Several packages in Debian depend on it and would be broken by its
removal, but its uses in most of them are trivial/obsolete:

Genuine(?) uses
---

- gvfs has a runtime dependency, for the Google Drive plugin. This could
  be disabled by compiling with -Dgoogle=false if desired.

- gnome-shell-extension-gsconnect Recommends the GIR typelib. I haven't
  investigated further.

Obsolete references
---

- eog-plugins Build-Depends on libgdata-dev but doesn't use it any more
  (it's for a plugin for Google PicasaWeb, which was disabled after
  Google discontinued the web service).

- gnome-photos Build-Depends on libgdata-dev but doesn't use it any more
  (the plugin was disabled in order to avoid a libsoup2 / librest 0.7
  dependency)

- grilo-plugins Build-Depends on libgdata-dev, but there's a change staged
  in its git repo to remove the build-dependency

- shotwell Build-Depends on libgdata-dev but I don't see any sign that
  it's used, maybe a plugin was removed?

- totem Build-Depends on libgdata-dev but I don't see any sign that
  it's used, maybe a plugin was removed?

I think we should seriously consider removing this from trixie.

smcv

Bug#1081962: libgtk-4-1: complains to terminal on Intel graphics cards

[Simon McVittie]

Control: retitle -1 mesa-vulkan-drivers: Intel driver logs "FINISHME" warnings 
on load
Control: reassign -1 mesa-vulkan-drivers 24.2.2-1

On Mon, 16 Sep 2024 at 18:31:05 +, brian m. carlson wrote:
>   % gnome-text-editor foo.rs
>   MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:763: FINISHME: 
> support YUV colorspace with DRM format modifiers
>   MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:794: FINISHME: 
> support more multi-planar formats with DRM modifiers
...
> GTK and the libraries it depends on should never write to stderr unless
> a user-visible problem has occurred, since this is annoying when being
> invoked in the terminal.  Since the software appears to be otherwise
> functional here, it should remain silent.
> 
> I realize this may be a bug in Mesa

Yes, this is a message from the Mesa Vulkan driver for Intel hardware, and
there isn't much that GTK can do about it other than not using Vulkan.

> if it will not be fixed
> promptly, please apply a workaround to revert the appropriate parts to
> the 4.14 version in the meantime

If the Vulkan renderer has enough problems (#1081957 is a more serious
one), a possible workaround in GTK is to switch the default back to one
of the OpenGL-based renderers.

In the short term, if you consider this to be a serious problem, please
use environment variable GDK_DISABLE=vulkan or GSK_RENDERER=ngl
(or GSK_RENDERER=gl or GSK_RENDERER=cairo).

smcv

Bug#1081953: libgstreamer-plugins-base1.0-dev: gtk4 FTBFS on hurd-i386: fatal error: GLES3/gl3.h: No such file or directory

[Simon McVittie]

Package: libgstreamer-plugins-base1.0-dev
Version: 1.24.4-1+hurd.1
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: debian-h...@lists.debian.org
User: debian-h...@lists.debian.org
Usertags: hurd-i386
Control: affects -1 + src:gtk4

https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=hurd-i386&ver=4.16.1%2Bds-2&stamp=1726438813&raw=0
> Get:209 http://deb.debian.org/debian-ports unreleased/main hurd-i386 
> libgstreamer-plugins-base1.0-dev hurd-i386 1.24.4-1+hurd.1 [539 kB]
...
> In file included from ../../../modules/media/gtkgstsink.c:53:
> /usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:40:13: fatal error: 
> GLES3/gl3.h: No such file or directory
>40 | #   include 

On Linux, this header is part of libgles-dev, which is a dependency of
libgstreamer-plugins-base1.0-dev:

> libgles-dev: /usr/include/GLES3/gl3.h

but perhaps this works differently on Hurd?

smcv

Bug#1081952: gtk4: FTBFS on powerpc: gtk:gtk / sorter test fails

[Simon McVittie]

Source: gtk4
Version: 4.16.1+ds-2
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: debian-powe...@lists.debian.org
User: debian-powe...@lists.debian.org
Usertags: powerpc

gtk4 passes most of its test suite on powerpc, but fails one test:

https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=powerpc&ver=4.16.1%2Bds-2&stamp=1726438341&raw=0
> == 163/692 ===
> test: gtk:gtk / sorter
> start time:   22:08:07
> duration: 0.07s
> result:   killed by signal 6 SIGABRT
> command:  GTK_A11Y=test GDK_DEBUG=default-settings MESON_TEST_ITERATION=1 
> GSETTINGS_SCHEMA_DIR=/<>/debian/build/deb/gtk 
> G_TEST_BUILDDIR=/<>/debian/build/deb/testsuite/gtk 
> G_TEST_SRCDIR=/<>/testsuite/gtk GDK_BACKEND=x11 
> GSK_RENDERER=cairo MALLOC_PERTURB_=63 
> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  TEST_OUTPUT_SUBDIR=x11 LD_LIBRARY_PATH=/<>/debian/build/deb/gtk 
> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  GTK_DEBUG=css GTK_CSD=1 GSETTINGS_BACKEND=memory 
> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> G_ENABLE_DIAGNOSTIC=0 /<>/debian/build/deb/testsuite/gtk/sorter 
> --tap -k
> --- stdout ---
> TAP version 14
> # random seed: R02S6b2c8c0fedad0d1281925bd23a570430
> 1..19
> # Start of sorter tests
> ok 1 /sorter/simple
> ok 2 /sorter/string
> ok 3 /sorter/change
> ok 4 /sorter/multi
> ok 5 /sorter/stable
> # Start of numeric tests
> ok 6 /sorter/numeric/boolean
> ok 7 /sorter/numeric/char
> ok 8 /sorter/numeric/uchar
> ok 9 /sorter/numeric/int
> ok 10 /sorter/numeric/uint
> ok 11 /sorter/numeric/float
> ok 12 /sorter/numeric/double
> ok 13 /sorter/numeric/long
> ok 14 /sorter/numeric/ulong
> not ok /sorter/numeric/int64 - 
> ERROR:../../../testsuite/gtk/sorter.c:439:test_numeric_int64: assertion 
> failed (model == "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20"): ("10 
> 12 18 19 13 7 5 3 6 9 16 15 20 1 11 4 2 17 14 8" == "1 2 3 4 5 6 7 8 9 10 11 
> 12 13 14 15 16 17 18 19 20")
> Bail out!

I don't know whether this is a bug in the test, or a bug in the part of
GTK that is being tested. It might be a problem with pointers or varargs
or something (powerpc is 32-bit big-endian, which is unusual these days).

The same test fails on hppa, which I think might also be 32-bit big-endian?

That test does succeed on ppc64 and s390x, which are 64-bit big-endian.

The Debian GNOME team is unlikely to prioritize investigating this,
because our focus is the release architectures where GNOME is most
commonly used, but tested patches (ideally sent upstream) would be
appreciated.

Thanks,
smcv

Bug#1081799: architecture-properties: foreign-cross-exe-wrapper autopkgtest still failing on i386, ppc64el, s390x

[Simon McVittie]

On Sun, 15 Sep 2024 at 01:10:24 +0100, Simon McVittie wrote:
> > Meanwhile on ppc64el and s390x, qemu-user fails to run busybox, which is
> > certainly a bug but isn't an *architecture-properties* bug:
> > 
> > [on ppc64el]
> > > 136s Setting up cross-exe-wrapper:i386 (0.2.1) ...
> > ...
> > > 137s qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> > 
> > [on s390x]
> > > 74s qemu-arm64: /usr/bin/busybox: Invalid note in PT_GNU_PROPERTY
> 
> Attached patch 0002 works around this by skipping tests where
> qemu-user appears to be non-functional.

I'd missed that this is output on stderr, which by default will make
autopkgtests fail. Please consider applying
https://salsa.debian.org/debian/architecture-properties/-/merge_requests/6
as well.

As with the previous patches sent to this bug, I don't know whether this
is going to block migration of architecture-properties. If necessary I can
restore the "explicitly use qemu" code path in glib2.0/NEW and
gobject-introspection/experimental to unblock the ability to upload them
to unstable and get them migrated to testing, but I'd prefer to get
architecture-properties migrated instead.

Thanks,
smcv

Bug#1078780: mesa: Disable llvmpipe on loong64

[Simon McVittie]

Control: tags -1 + moreinfo

On Fri, 16 Aug 2024 at 09:08:35 +0800, wuruilong wrote:
> The loongarch architecture of llvm does not support mcjit, so don't use
> llvmpipe in loongarch at this time.

Now that Mesa supports ORCJIT, llvmpipe seems to work acceptably on loong64.
In particular, it works well enough to run the GTK4 test suite:
https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=loong64&ver=4.16.1%2Bds-2&stamp=1726438431&raw=0

So perhaps this request is obsolete and can be closed with no action taken?

smcv
(not a mesa maintainer)

Bug#1081947: libgl1-mesa-dri: llvmpipe exists but does not work on powerpc

[Simon McVittie]

Source: libgl1-mesa-dri
Version: 24.2.2-1
Severity: normal
X-Debbugs-Cc: debian-powe...@lists.debian.org
User: debian-powe...@lists.debian.org
Usertags: powerpc

Similar to the situation on sparc64.

To reproduce:
- install gtk4 build-dependencies on powerpc porterbox with no access to a
  real GPU
- get gtk4 source
- edit debian/rules to remove the special case that forces use of softpipe
  on powerpc
- build and run tests

Expected result: either of these:
- llvmpipe exists, is used, and works
- llvmpipe doesn't exist and softpipe is automatically used instead

Actual result:
- all tests that use OpenGL fail with message "LLVM ERROR: Relocation
  type not implemented yet!" and a SIGABRT

I would suggest special-casing llvmpipe (and anything else requiring LLVM
JIT: lavapipe?) to be built on most of the $(LLVM_ARCHS), but not powerpc.

smcv

Bug#1081943: libgl1-mesa-dri: llvmpipe exists but does not work on sparc64

[Simon McVittie]

Source: libgl1-mesa-dri
Version: 24.2.2-1
Severity: normal
X-Debbugs-Cc: debian-sp...@lists.debian.org
User: debian-sp...@lists.debian.org
Usertags: sparc64

To reproduce:
- install gtk4 build-dependencies on sparc64 porterbox with no access to a
  real GPU
- get gtk4 source
- edit debian/rules to remove the special case that forces use of softpipe
  on sparc64
- build and run tests

Expected result: either of these:
- llvmpipe exists, is used, and works
- llvmpipe doesn't exist and softpipe is automatically used instead

Actual result:
- all tests that use OpenGL fail with message "Target has no JIT support"

I would suggest special-casing llvmpipe (and anything else requiring LLVM
JIT: lavapipe?) to be built on most of the $(LLVM_ARCHS), but not sparc64.

smcv

Bug#1081940: gnome-session: "Oh no! Something has gone wrong." screen because of screensaver

[Simon McVittie]

On Mon, 16 Sep 2024 at 11:39:38 +0200, Michael Ott wrote:
> I add journalctl output from the minute I had this problem.

Thanks, I don't see an obvious root cause in there but perhaps another
maintainer will.

Please try with GNOME Shell extensions disabled: it's possible for them to
cause crashes.

smcv

Bug#1081940: gnome-session: "Oh no! Something has gone wrong." screen because of screensaver

[Simon McVittie]

Control: reassign -1 gnome-shell 47.0-1
Control: tags -1 + experimental moreinfo

On Mon, 16 Sep 2024 at 10:42:40 +0200, Michael Ott wrote:
> Gnome crashed regularly without a reason.
[...]
> journalctl -xe -t gnome-session

gnome-session is one component of GNOME, but not the only component. Please
look at the whole Journal for error messages, not just the gnome-session
topic.

I see you are using GNOME Shell from experimental, and GNOME Shell is
the most important component of the GNOME session, so the most likely
reason would seem to be GNOME Shell.

> Sep 16 06:00:24 k-c13 gnome-session[3287]: gnome-session-binary[3287]: 
> WARNING:
> Desktop file /etc/xdg/autostart/tracker-miner-rss-3.desktop for application
> tracker-miner-rss-3.desktop could not be parsed or references a missing 
> TryExec
> binary
> Sep 16 06:00:24 k-c13 gnome-session[3287]: gnome-session-binary[3287]:
> GnomeDesktop-WARNING: Could not create transient scope for PID 3319:
> GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Failed to set 
> unit
> properties: No such process
> Sep 16 06:00:25 k-c13 gnome-session[3287]: gnome-session-binary[3287]:
> GnomeDesktop-WARNING: Could not create transient scope for PID 3567:
> GDBus.Error:org.freedesktop.DBus.Error.UnixProcessIdUnknown: Failed to set 
> unit
> properties: No such process
> Sep 16 10:30:42 k-c13 gnome-session[3287]: gnome-session-binary[3287]: 
> WARNING:
> Could not retrieve current screensaver active state:
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.gnome.Shell.ScreenShield was not provided by any .service files

These are warnings, not fatal errors.

smcv

Bug#1081907: vte: CVE-2024-37535

[Simon McVittie]

On Sun, 15 Sep 2024 at 23:18:53 +0200, Moritz Mühlenhoff wrote:
> The following vulnerability was published for vte. This is already addressed
> in vte2.91, but also filing this for completeness for the deprecated source
> package:
> 
> CVE-2024-37535[0]:
> | GNOME VTE before 0.76.3 allows an attacker to cause a denial of
> | service (memory consumption) via a window resize escape sequence, a
> | related issue to CVE-2000-0476.

I think this is wontfix. The only reason why the GTK2-based vte is still
in Debian at all is for the benefit of debian-installer, which hasn't
caught up with GTK3 yet.

In principle we could remove the .deb and leave only the .udeb, but I think
that would make it harder to test vte, so is probably not a great idea.

It would probably make sense to add vte to the list of packages that don't
have security support.

smcv

Bug#1081850: qemu-arm64: can't run busybox:arm64 on s390x: Invalid note in PT_GNU_PROPERTY

[Simon McVittie]

Package: qemu-user
Version: 1:9.0.2+ds-2+b1
Severity: normal
User: debian-s...@lists.debian.org
Usertags: s390x
X-Debbugs-Cc: debian-s...@lists.debian.org

The new cross-exe-wrapper package in src:architecture-properties runs
binaries from a foreign architecture, either directly or via qemu-user.
Its autopkgtest uses busybox from each release architecture (specifically
the `busybox true` and `busybox echo` applets) as a smoke-test to see
whether this works as intended.

On s390x, the result indicates that the qemu-arm64 in qemu-user:s390x
can't run busybox:arm64:

>  74s qemu-arm64: /usr/bin/busybox: Invalid note in PT_GNU_PROPERTY

I don't know whether this is specific to busybox, or whether the qemu-arm64
in qemu-user:s390x doesn't work more generally.

architecture-properties (>= 0.2.2) works around this by skipping its
self-test on architecture pairs where qemu-$arch doesn't run successfully.

smcv

Bug#1081849: qemu-i386: can't run busybox:i386 on ppc64el: Segmentation fault

[Simon McVittie]

Package: qemu-user
Version: 1:9.0.2+ds-2+b1
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: ppc64el
X-Debbugs-Cc: debian-powe...@lists.debian.org

The new cross-exe-wrapper package in src:architecture-properties runs
binaries from a foreign architecture, either directly or via qemu-user.
Its autopkgtest uses busybox from each release architecture (specifically
the `busybox true` and `busybox echo` applets) as a smoke-test to see
whether this works as intended.

On ppc64el, the result indicates that the qemu-i386 in qemu-user:ppc64el
can't run busybox:i386:

> 137s qemu: uncaught target signal 11 (Segmentation fault) - core dumped

I don't know whether this is specific to busybox, or whether the qemu-i386
in qemu-user:ppc64el doesn't work more generally.

architecture-properties (>= 0.2.2) works around this by skipping its
self-test on architecture pairs where qemu-$arch doesn't run successfully.

smcv

Bug#1081847: qemu-armel: can't run busybox:armel on riscv64

[Simon McVittie]

Package: qemu-user
Version: 1:9.0.2+ds-2
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

The new cross-exe-wrapper package in src:architecture-properties runs
binaries from a foreign architecture, either directly or via qemu-user.
Its autopkgtest uses busybox from each release architecture (specifically
the `busybox true` and `busybox echo` applets) as a smoke-test to see
whether this works as intended.

On riscv64, the result indicates that the qemu-armel in qemu-user:riscv64
can't run busybox:armel:

> 648s qemu-armel: /usr/bin/busybox: Unable to find a guest_base to satisfy all 
> guest address mapping requirements
> 648s   -

I don't know whether this is specific to busybox, or whether the qemu-armel
in qemu-user:riscv64 doesn't work more generally.

architecture-properties (>= 0.2.2) works around this by skipping its
self-test on architecture pairs where qemu-$arch doesn't run successfully.

smcv

Bug#1078203: pyglet: requires update for ffmpeg 7.0

[Simon McVittie]

On Sun, 15 Sep 2024 at 15:18:42 +0200, Timo Röhling wrote:
> pyglet still lacks FFmpeg 7.0 support, but version 2.0.17 no longer requires
> FFmpeg to be present, so I downgraded the Depends to Recommends and this bug
> to severity Important.

I believe missing Recommends are considered RC (Policy §2.2.1 says packages
in main "must not require **or recommend** a package outside of main", and
the older ffmpeg that is compatible with pyglet is no longer in main)
so this probably needs to be a Suggests.

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#1081799: architecture-properties: foreign-cross-exe-wrapper autopkgtest still failing on i386, ppc64el, s390x

[Simon McVittie]

Control: tags -1 + patch

The attached patches address this. Also available as a MR at
https://salsa.debian.org/debian/architecture-properties/-/merge_requests/5

It is not clear to me whether these failing tests are going to block
migration: https://release.debian.org/testing/rc_policy.txt says that
only regressions are RC (except on amd64 and arm64 where any failing test
is RC), and these are not regressions, but architecture-properties lists
them as though they might be migration blockers.

On Sun, 15 Sep 2024 at 00:38:26 +0100, Simon McVittie wrote:
> On i386, if the testbed happens to be running an
> amd64-capable kernel, the foreign-cross-exe-wrapper test fails:
> 
> > 89s 
> > /tmp/autopkgtest-lxc.7txv9lyb/downtmp/build.IPq/src/debian/tests/foreign-cross-exe-wrapper:
> >  37: rc: parameter not set

Fixed in attached patch 0001.

> Meanwhile on ppc64el and s390x, qemu-user fails to run busybox, which is
> certainly a bug but isn't an *architecture-properties* bug:
> 
> [on ppc64el]
> > 136s Setting up cross-exe-wrapper:i386 (0.2.1) ...
> ...
> > 137s qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> 
> [on s390x]
> > 74s qemu-arm64: /usr/bin/busybox: Invalid note in PT_GNU_PROPERTY

Attached patch 0002 works around this by skipping tests where
qemu-user appears to be non-functional. To test the functionality of
the cross-exe-wrapper script, we only really need one architecture where
it all works.

Attached patch 0003 is not really directly related, just something I
noticed while testing this: if we install Recommends, then we'll get
qemu-user-binfmt, which means we would be able to run foreign executables
even if we didn't intentionally wrap them with qemu.

smcv
>From 6dccca47f946f5b0f64ee86d6f1e94fb3e8e9939 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 15 Sep 2024 00:10:23 +0100
Subject: [PATCH 1/3] d/tests/foreign-cross-exe-wrapper: Make sure rc is
 initialized

If the first test happens to be successful (for example running an
amd64 binary in an i386 environment that happens to be running on an
amd64-capable kernel) then rc will be uninitialized, causing the script
to fail due to the use of `set -u`.

Helps: #1081799
Signed-off-by: Simon McVittie 
---
 debian/tests/foreign-cross-exe-wrapper | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/tests/foreign-cross-exe-wrapper b/debian/tests/foreign-cross-exe-wrapper
index 304e19a..3016867 100755
--- a/debian/tests/foreign-cross-exe-wrapper
+++ b/debian/tests/foreign-cross-exe-wrapper
@@ -33,6 +33,7 @@ for arch in $ARCHITECTURES; do
 	gnutype=$(dpkg-architecture "-a$arch" -qDEB_HOST_GNU_TYPE 2>/dev/null)
 
 	# We expect no output and an exit code of 0 or 1
+	rc=0
 	output=$("/usr/lib/$multiarch/cross-exe-wrapper/cross-exe-test" 2>&1) || rc=$?
 	test "$rc" = 2 && die "cross-exe-test exited $rc for $arch with output $output"
 
-- 
2.45.2

>From 2a0bff7c415e49f933c8f8dee5be282fae451a4c Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 15 Sep 2024 00:16:23 +0100
Subject: [PATCH 2/3] d/tests/control: Skip testing foreign-cross-exe-wrapper
 if qemu fails

On ppc64el, qemu-i386 currently crashes with a segfault, and on s390x,
qemu-arm64 (and possibly others) fails with:

qemu-arm64: /usr/bin/busybox: Invalid note in PT_GNU_PROPERTY

Neither of these is actually a cross-exe-wrapper bug.

Closes: #1081799 (when combined with previous commit)
Signed-off-by: Simon McVittie 
---
 debian/tests/foreign-cross-exe-wrapper | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/tests/foreign-cross-exe-wrapper b/debian/tests/foreign-cross-exe-wrapper
index 3016867..2cc2d00 100755
--- a/debian/tests/foreign-cross-exe-wrapper
+++ b/debian/tests/foreign-cross-exe-wrapper
@@ -37,6 +37,11 @@ for arch in $ARCHITECTURES; do
 	output=$("/usr/lib/$multiarch/cross-exe-wrapper/cross-exe-test" 2>&1) || rc=$?
 	test "$rc" = 2 && die "cross-exe-test exited $rc for $arch with output $output"
 
+	if ! "qemu-$arch" /bin/busybox true; then
+		echo "Skipping foreign test for $arch because qemu-$arch didn't work"
+		continue
+	fi
+
 	# Expect successful exit
 	"$gnutype-cross-exe-wrapper" /bin/busybox true
 
-- 
2.45.2

>From 4aad108a9a9ffc604a3b29bee9da57df401fea46 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 15 Sep 2024 00:54:42 +0100
Subject: [PATCH 3/3] d/tests: Install additional packages with
 --no-install-recommends

Otherwise we end up installing qemu-user-binfmt, which could make the
tests pass for the wrong reasons.

Signed-off-by: Simon McVittie 
---
 debian/tests/foreign-cross-exe-wrapper | 2 +-
 debian/tests/sibling-cross-exe-wrapper | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/tests/foreign-cross-exe-wrapper b/debian/tests/foreign-cross-exe-w

Bug#1081799: architecture-properties: foreign-cross-exe-wrapper autopkgtest still failing on i386, ppc64el, s390x

[Simon McVittie]

Source: architecture-properties
Version: 0.2.1
Severity: normal
X-Debbugs-Cc: debian-cr...@lists.debian.org

Thanks for adding cross-exe-wrapper to architecture-properties: I think it
will be a big improvement for the GLib packaging, among others.

However, at the moment the autopkgtests are failing on several
architectures. On i386, if the testbed happens to be running an
amd64-capable kernel, the foreign-cross-exe-wrapper test fails:

> 89s 
> /tmp/autopkgtest-lxc.7txv9lyb/downtmp/build.IPq/src/debian/tests/foreign-cross-exe-wrapper:
>  37: rc: parameter not set

Meanwhile on ppc64el and s390x, qemu-user fails to run busybox, which is
certainly a bug but isn't an *architecture-properties* bug:

[on ppc64el]
> 136s Setting up cross-exe-wrapper:i386 (0.2.1) ...
...
> 137s qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[on s390x]
> 74s qemu-arm64: /usr/bin/busybox: Invalid note in PT_GNU_PROPERTY

I'm testing patches which I hope will fix the i386 issue, and work around
the ppc64el/s390x issue (by skipping tests where qemu turns out not to
actually work).

Thanks,
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#1081748: RM: gnome gnome-core [armel] -- NBS; #1080521

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove

src:meta-gnome3 no longer builds the gnome and gnome-core metapackages
for armel, as the first step in removing this dependency chain from armel:

[many packages] -> gnome-shell -> gjs -> mozjs128

It appears that mozjs128 no longer works on architectures that do not
have atomic operation opcodes in their baseline (it builds, but FTBFS
with test failures), and that rules out armel.

Please remove the old gnome{,-core}_1:47~beta+1_armel binary packages.

Thanks,
smcv

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#1081519: transition: gnome-shell 47

[Simon McVittie]

On Fri, 13 Sep 2024 at 14:16:29 -0400, Jeremy Bícha wrote:
> - GNOME Shell

This is the only one of the three batches you described that is really
in-scope for #1081519, and I think the only one that really needs a
transition slot from the release team.

> Some things like xwayland scaling won't work right if we don't have
> gnome-settings-daemon >= 47~rc. The build tests do pass if retried a
> few times. [...] If it helps, we only started running this mutter
> set of tests in July because we didn't notice earlier we had tests
> that were not being run.

OK, then we want gnome-settings-daemon to be in-scope for #1081519. To
me, this is sounding like: the gnome-settings-daemon tests are not yet
reliable enough to be a QA gate, so we should just disable the flaky ones
(or perhaps all of them).

I would say that manual testing on real GNOME systems is much more
practically important for g-s-d than its build-time unit tests.

> - gjs with the switch to mozjs128. Years ago, gjs updates were
> disruptive but not really anymore. We are doing some armel surgery
> this time though.

This is a separate sort-of-transition, #1080521. It doesn't involve an
ABI break as such, but it will require ftp team action (removing NBS
binaries from armel) to get it into testing, so I opened a release team
bug to check that they were aware and we weren't trying to do anything
impossible.

The main risk here is that if NBS binaries aren't removed reasonably
quickly, it could stall migrations and interfere with a transition.

> - gtk4 + libadwaita + all the GNOME 47 app & library updates that are
> not in Unstable already and not part of the other 2 categories

This is tracked by the GNOME team as #1079548. It isn't really a
transition as such, everything in it is backwards-compatible (no ABI
breaks) as far as I'm aware.

Unfortunately it's now blocked by Weston 14, which is crashing when
we use it to run the GTK 4 test suite, causing the test suite to fail
as collateral damage (#1081515); we can't upgrade gtk4 until that's
resolved somehow, either by fixing Weston or by using a different
headless compositor to run our tests. I tried to use wlheadless-run from
the xwayland-run package, wrapping mutter or cage instead of weston,
but I haven't had any success with that yet.

smcv

Bug#1081678: gtk4: riscv64: please do not force softpipe to run the testsuite

[Simon McVittie]

On Fri, 13 Sep 2024 at 19:52:14 +0200, Aurelien Jarno wrote:
> Since version 4.16.0+ds-1, softpipe is forced to run the gtk4 testsuite
> due to bug#1080475). As this bug is now fixed, could you please stop
> forcing softpipe? I have verified that after applying the patch below
> the gtk4 testsuite works fine with the fixed libllvm18 version (after
> downgrading weston due to #1081515).

Let's wait for the fixed llvm-toolchain-18 to reach testing; but after
that, sure, llvmpipe is preferable to softpipe.

(This is not urgent to apply, because weston is breaking our ability to
release any new gtk4 versions anyway.)

smcv

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#1081515: gtk4: FTBFS with weston 14: many tests fail with --setup=wayland: Failed to open display

[Simon McVittie]

Control: retitle -1 gtk4: FTBFS with weston 14: many tests fail with 
--setup=wayland: Failed to open display
Control: severity -1 serious

(Please remove -ports from cc in replies, this is no longer believed to
be -ports specific)

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

It seems that it's now also failing on release architectures, and the
failure seems well-correlated with weston being upgraded to version 14.
The reason this particularly affected -ports is that -ports didn't have
an installable version of weston 13, so by definition all of their recent
gtk4 builds had to be with weston 14.

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.

smcv

Bug#1079548: gtk4: upload of 4.16 to unstable blocked by riscv64 build

[Simon McVittie]

Control: block -1 by 1081515

On Thu, 12 Sep 2024 at 21:26:55 +0200, Aurelien Jarno wrote:
> Unfortunately it failed to build from source,
> but it is not riscv64 specific and can be reproduced easily on amd64.
> 
> As a first guess by looking at the packages difference, it seems to be
> due to weston 14

This looks like the same problem we saw on -ports (where weston 13 was
uninstallable for a while, so all recent gtk4 builds were done with
weston 14). Perhaps there is a behaviour change that is breaking the way
we use headless Weston, or perhaps Weston is crashing.

https://bugs.debian.org/1081515

> and seems to be corroborated by the corresponding
> autopkgtest:
> 
> https://ci.debian.net/packages/g/gtk4/testing/amd64/51575899/

I see that the first 87 tests passed, and then gtk/action.test failed.
That seems like perhaps weston was initially working, but then crashed
or otherwise became unavailable.

smcv

Bug#1081515: gtk4: FTBFS on -ports architectures: many tests fail with --setup=wayland: Failed to open display

[Simon McVittie]

On Fri, 13 Sep 2024 at 02:07:25 +0800, Bo YU wrote:
> On Thu, Sep 12, 2024 at 11:48:21AM +0100, Simon McVittie wrote:
> If I understand correctly, the gtk4 can be built[0] on riscv64 once llvm-18
> got upload to riscv64[1].

I believe the current gtk4 in experimental can be built successfully on
riscv64 anyway, because it forces GALLIUM_DRIVER=softpipe (it worked for me
on the porterbox, we're waiting for a result from the buildd).

The most likely thing to break it would be if this bug is not actually
about the difference between release and -ports architectures, but more
like the difference between buildds that run on stable and buildds that
run on testing/unstable. We'll see.

> I would like to suggest we can enable llvmpipe on riscv64

In future, yes we probably can, but we can only try that after
ORCJIT *works* on riscv64, which requires llvm-toolchain-18 to build
successfully. That has taken more than 3 days of compiling so far,
and is still not finished.

We want to upload GTK 4 to unstable soon because it's blocking many GNOME
47 apps and libraries, and riscv64 is a release architecture candidate,
so my understanding is that failure to compile on riscv64 would be
a migration blocker. Letting a multi-day compile on riscv64 delay the
upload of GNOME 47 on desktop architectures like x86 seems like it would
be harming our users.

*After* gtk4 (>= 4.16) is in unstable and preferably testing, *then* we
can try removing riscv64 from the list of softpipe architectures - at
that point I hope it will work reliably, like e.g. amd64 and arm64 do.
If that's successful, we can remove some workarounds.

And, when someone has solved this bug, providing a build environment
where gtk4 can run all of its tests on -ports architectures, we can make
each -ports architecture use either llvmpipe (like ppc64) or softpipe
(like powerpc), whichever one the architecture's porters tell us works
better for that architecture. We would prefer llvmpipe if possible,
because softpipe seems to mis-render some of the test cases.

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#1081514: libcurl-gnutls.so.4: undefined symbol: gnutls_free

[Simon McVittie]

Control: reassign -1 libcurl3t64-gnutls 8.10.0-1
Control: severity -1 grave
Control: forcemerge 1081517 -1

On Thu, 12 Sep 2024 at 12:33:45 +0100, Simon McVittie wrote:
> On Thu, 12 Sep 2024 at 20:39:25 +1000, Russell Coker wrote:
> > flatpak: symbol lookup error: /lib/aarch64-linux-gnu/libcurl-gnutls.so.4: 
> > undefined symbol: gnutls_free
> > 
> > I get the above error when I run flatpak on my PinePhonePro on both the
> > unstable (1.14.10-1) and experimental (1.15.10-1) versions.

Looks like a duplicate of <https://bugs.debian.org/1081517> which is a
regression in libcurl3t64-gnutls. libcurl4t64 (curl with OpenSSL) looks OK
according to packages.debian.org.

smcv

Bug#1081514: libcurl-gnutls.so.4: undefined symbol: gnutls_free

[Simon McVittie]

Control: tags -1 + moreinfo
Control: affects -1 + libgnutls30t64 libcurl3t64-gnutls

On Thu, 12 Sep 2024 at 20:39:25 +1000, Russell Coker wrote:
> flatpak: symbol lookup error: /lib/aarch64-linux-gnu/libcurl-gnutls.so.4: 
> undefined symbol: gnutls_free
> 
> I get the above error when I run flatpak on my PinePhonePro on both the
> unstable (1.14.10-1) and experimental (1.15.10-1) versions.

What version of libgnutls.so.30 (libgnutls30t64 or libgnutls30)
is installed? Is it a local build? Or do you have a local build in
/usr/local or the $LD_LIBRARY_PATH or similar?

It's an indirect dependency via libcurl3t64-gnutls, so it doesn't appear
in the reportbug report when reporting a bug against flatpak.

At first glance this looks like it would have to be an ABI break in GNUTLS,
affecting Flatpak indirectly. But I don't see any sign of this having
happened in the gnutls28 packaging repository.

The libcurl-gnutls.so.4 version involved should be this one:

> Versions of packages flatpak depends on:
...
> ii  libcurl3t64-gnutls 8.10.0-1

(for historical reasons the package name and the SONAME don't match up).

smcv

Bug#1081519: transition: gnome-shell 47

[Simon McVittie]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
Tags: moreinfo
Control: block -1 by 1080521 1079548
Control: affects -1 + src:gnome-shell src:mutter src:gnome-settings-daemon 
src:gnome-remote-desktop
User: release.debian@packages.debian.org
Usertags: transition
Forwarded: https://release.debian.org/transitions/html/gnome-shell-47.html

The GNOME team is preparing GNOME 47 in experimental. As usual, we will
need a transition to get a new libmutter SONAME into testing, and to
get GNOME Shell and its extensions migrated.

This is the GNOME release that is likely to be shipped in Debian 13,
assuming a freeze date somewhere between December 2024 and March 2025.

GNOME 47 is not fully released yet (release day is the 14th) but I'm
opening this bug a little early to make the release team aware.

Blockers


We should get GTK 4.16.x into unstable first (#1079548).

We are waiting for GNOME 47 final releases which are due on Saturday
(currently most of it is at release-candidate status), hence moreinfo tag.

We should seriously consider getting gjs upgraded to 1.81.x/1.82.x either
first or at the same time, which will require a mini-transition to remove
it from armel (#1080521).

Ideally gnome-settings-daemon would go along with this transition, but it
has several very flaky build-time tests which cause FTBFS. If they can't
be fixed soon, a mitigation would be to disable those tests (I suspect
this is a problem with the test scaffolding rather than g-s-d itself).

Packages involved
=

The core packages are all GNOME-team-maintained:

gjs
gnome-control-center
gnome-kiosk
gnome-remote-desktop
gnome-settings-daemon
gnome-shell
gnome-shell-extensions
mutter
nautilus
xdg-desktop-portal-gnome

and then as usual, we will need to do a mass removal of any GNOME Shell
extensions that have not been updated (several are already fixed in
experimental and can be team-uploaded or NMU'd to unstable, but some
will almost certainly need to be removed from testing):

https://release.debian.org/transitions/html/gnome-shell-47.html
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org&tag=gnome-shell-47

Thanks,
smcv

Bug#1079548: gtk4: upload of 4.16 to unstable blocked by riscv64 build

[Simon McVittie]

Control: unblock -1 by 1081275

On Sat, 24 Aug 2024 at 09:37:57 -0400, Jeremy Bícha wrote:
> This is a tracker bug with known blockers for uploading the new gtk4
> series 4.15.x/4.16.x to Unstable.
> 
> The new gtk4 series is required for libadwaita 1.6 which is required
> by many GNOME 47 apps.

I believe we are now only waiting for GTK 4.16.0+ds-2 to be successfully
built on a riscv64 buildd. (It works on a porterbox, but it would be safer
to have a successful build on a buildd before going to unstable.)

Would it be possible for a riscv64 porter or a buildd operator to bump up
the priority of gtk4/experimental (gtk4_4.16.0+ds-2) on riscv64, to get that
built a bit sooner?

Hopefully that unblocks all of GNOME 47, except for the packages that are
tied up with Shell.

smcv

Bug#1081515: gtk4: FTBFS on -ports architectures: many tests fail with --setup=wayland: Failed to open display

[Simon McVittie]

Source: gtk4
Version: 4.14.4+ds-8
Severity: important
Tags: ftbfs help
X-Debbugs-Cc: debian-po...@lists.debian.org

Until recently, gtk4 was not buildable on any -ports architectures because
its build-dependency, weston, was uninstallable. Now it's installable, and
building and testing can be attempted.

gtk4's test suite is failing on all -ports architectures that have buildds,
except for m68k (which I believe builds with nocheck and therefore does not
run the test suite at all).

The GNOME team is busy with GNOME 47 on release architectures and
unlikely to have time to look into this in detail any time soon, but if
porting teams would like to have GTK 4 available (it will be increasingly
important for desktop architectures in trixie), it would be useful if
someone from -ports could investigate.

The gtk4 test suite is run in two phases:

1. with --setup=x11, wrapped by "debian/tests/run-with-display x11" which
   is basically xvfb-run

2. with --setup=wayland, wrapped by "debian/tests/run-with-display wayland"
   which is intended to be a Wayland equivalent of xvfb-run, using weston
   in headless mode as the compositor

Taking powerpc as my arbitrary example, most tests are passing during the
x11 phase. On powerpc, I see a failure in "gtk:gtk / sorter" (unstable
and experimental) and in "gtk:gdk / memorytexture" (experimental only)
which can be investigated separately; please treat those isolated failures
as out-of-scope for the purposes of this bug.

However, in the wayland phase, most tests are failing with (fatal) warnings
like:

(/<>/debian/build/deb/testsuite/gtk/spinbutton:12693): Gtk-WARNING 
**: 17:54:18.469: Failed to open display

weston might be broken on all -ports architectures and functional on
all release architectures, but that level of coincidence seems a little
far-fetched. So my next theory for this is that something is consistently
different about the -ports buildds - perhaps their XDG_RUNTIME_DIR is
set up differently? - and that is causing
"debian/tests/run-with-display wayland" (or the copy of weston that it
runs) to fail?

After the failure mode discussed in this bug report has been addressed,
it will become more useful to look at individual/isolated test
failures (as separate bug reports, please). Based on the status of the
less-production-ready release architectures like mips64el and riscv64, I
suspect that the most common root cause for individual test failures will
be the software OpenGL stack: implementation issues in Mesa's llvmpipe
and softpipe, implementation issues in LLVM's old MCJIT and new ORCJIT,
and the GTK packaging's choice of whether to mitigate llvmpipe bugs by
forcing softpipe (currently done on mips*, riscv*, powerpc, sparc*)
or test with llvmpipe (as we do on x86, ARM, etc.).

Thanks,
smcv

Bug#1081454: libcares2: "Conflicts: libcares2" prevents multiarch co-installation

[Simon McVittie]

Package: libcares2
Version: 1.33.1-1
Severity: normal
X-Debbugs-Cc: vor...@debian.org

The package containing libcares.so.2 was renamed during the t64 transition
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062032,
https://salsa.debian.org/debian/c-ares/-/commit/6972270af2b7d53a2be08ca0059b17476a628d95
 )
and at that time, instead of being renamed from libc-ares2 to libc-ares2t64,
Steve took the opportunity to rename it from the non-standard libc-ares2
to the Policy-compliant name libcares2.

However, it already had a "Conflicts: libcares2" which was preserved during
that rename. The addition of that Conflicts was before the beginning of git
history, but it seems to have been added in order to force removal of a
historical unofficial package from outside the Debian archive
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478588#10).

If a package Conflicts with itself, apt/dpkg allows it to be installed,
but only for one architecture at a time, making the Multi-Arch: same
field ineffective. This prevents libcares2 and higher-level libraries
that depend on it from being co-installed.

For example, the situation that made me trip over this was inability to
co-install the libear:amd64 and libear:i386 used by the bear package if
you are building both amd64 and i386 code, because they have the dependency
chain libear -> libgrpc29t64 -> libcares2.

I think the solution is to just delete the "Conflicts: libcares2"
(untested, but should work).

libcares2 correctly has a Breaks/Replaces on libc-ares2, so it will
correctly replace the pre-t64 version of itself.

Thanks,
smcv

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#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#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#1081436: git-buildpackage: should escape indented diffs somehow

[Simon McVittie]

Package: git-buildpackage
Version: 0.9.34
Severity: normal

gtk+3.0_3.24.43-3 contains a patch in the `git format-patch` dialect of
DEP-3 format, whose long description contains a diff illustrating how
to test the change (patch attached for reference).

The author of this patch clearly meant for the machine-readable part
of the patch to apply changes to gtk/gtkmessagedialog.c only.
`git apply` and `git am` have this behaviour, therefore so does `gbp pq`.

However, patch(1) and therefore dpkg-source looks for anything in the
patch text that looks vaguely diff-like, even if it's indented (!), and
applies it. The result is that in the uploaded gtk+3.0_3.24.43-3 package,
both gtk/gtkmessagedialog.c and demos/gtk-demo/dialog.c have been edited
(reported as #1081179).

I could even imagine this becoming a security issue, if the long
description of a patch contains instructions for changes to be made
during testing that are not suitable for production (for example if the
long description describes how to stub out authentication in order to
test something).

I've reported a separate dpkg-source bug asking for it to refuse to apply
the indented part of diffs like the attached.

To address this interop issue from both sides, I think that when
`gbp-pq export` serializes patches into debian/patches to become input
to dpkg-source, it should try to identify parts of the long commit
message that patch(1) would consider to be the beginning of a diff (I
think this means lines matching regexes r'^\s+-{3}' and r'^\s+[+]{3}',
or something like that?) and escape them somehow, perhaps by prepending
"#", ">" or ".".

Thanks,
smcv
From: Michael Weghorn 
Date: Fri, 9 Aug 2024 18:37:11 +0200
Subject: a11y: Use non-empty message dialog title as a11y name

If a `GtkMessageDialog` has a non-empty title set, use
that for the accessible name instead of a generic name
indicating the type of the message dialog, as the
window title is generally more informative, if set.
It also better matches the information presented
visually on screen (in the window title, task switchers,...)
and is in line with the handling for non-message-dialog
windows.

This can easily be tested with the "Dialogs and
Message Boxes" sample from gtk3-demo when setting
a title for the message dialog in there like this:

diff --git a/demos/gtk-demo/dialog.c b/demos/gtk-demo/dialog.c
index 0eb1c62397..53fb7f8b0e 100644
--- a/demos/gtk-demo/dialog.c
+++ b/demos/gtk-demo/dialog.c
@@ -25,6 +25,8 @@ message_dialog_clicked (GtkButton *button,
"number of times:");
   gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (dialog),
 "%d", i);
+  gtk_window_set_title (GTK_WINDOW (dialog), "Some informative title");
+
   gtk_dialog_run (GTK_DIALOG (dialog));
   gtk_widget_destroy (dialog);
   i++;

(cherry picked from commit 939737c3e72c2deaa0094f35838038df92f2a724)

Origin: upstream gtk-3-24 branch, after 3.24.43
---
 gtk/gtkmessagedialog.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gtk/gtkmessagedialog.c b/gtk/gtkmessagedialog.c
index 1de3118..ee35b26 100644
--- a/gtk/gtkmessagedialog.c
+++ b/gtk/gtkmessagedialog.c
@@ -373,7 +373,12 @@ update_accessible_name (GtkMessageDialog *dialog)
   if (!GTK_IS_ACCESSIBLE (atk_obj))
 return;
 
-  const char *name = NULL;
+  const char *name = gtk_window_get_title (GTK_WINDOW (dialog));
+  if (name && name[0])
+  {
+atk_object_set_name (atk_obj, name);
+return;
+  }
 
   switch (dialog->priv->message_type)
   {
@@ -438,6 +443,8 @@ update_title (GObject*dialog,
   title = gtk_window_get_title (GTK_WINDOW (dialog));
   gtk_label_set_label (GTK_LABEL (label), title);
   gtk_widget_set_visible (label, title && title[0]);
+
+  update_accessible_name (GTK_MESSAGE_DIALOG (dialog));
 }
 
 static void

Bug#1081434: dpkg-source: should refuse to apply indented diffs, or at least give a warning

[Simon McVittie]

Package: dpkg-dev
Version: 1.22.11
Severity: normal

gtk+3.0_3.24.43-3 contains a patch in the `git format-patch` dialect of
DEP-3 format, whose long description contains a diff illustrating how
to test the change (patch attached for reference).

The author of this patch clearly meant for the machine-readable part
of the patch to apply changes to gtk/gtkmessagedialog.c only.
`git apply` and `git am` have this behaviour.

However, patch(1) and therefore dpkg-source looks for anything in the
patch text that looks vaguely diff-like, even if it's indented (!), and
applies it. The result is that in the uploaded gtk+3.0_3.24.43-3 package,
both gtk/gtkmessagedialog.c and demos/gtk-demo/dialog.c have been edited
(reported as #1081179).

I think the same thing could equally well happen with the
more-Debian-specific dialect of DEP-3 where the long human-readable
message is in an indented deb822-style "Description", although I don't have
a reproducer for that. However, the old dpatch framework would not have been
susceptible to this, because it prepended "#" to all the non-diff content.

Ideally, I think dpkg-source would (configure patch(1) to) refuse to apply
diffs that are indented in this way - applying them seems like a violation
of the principle of least astonishment.

Or, if that's considered to be too much of a compatibility break, I think
it would be useful for dpkg-source to issue a warning on such diffs.
patch(1) does output "(Patch is indented 4 spaces.)" when I apply that
diff, but it seems that dpkg-source suppresses that output.

I could even imagine this becoming a security issue, if the long
description of a patch contains instructions for changes to be made
during testing that are not suitable for production (for example if the
long description describes how to stub out authentication in order to
test something).

smcv
From: Michael Weghorn 
Date: Fri, 9 Aug 2024 18:37:11 +0200
Subject: a11y: Use non-empty message dialog title as a11y name

If a `GtkMessageDialog` has a non-empty title set, use
that for the accessible name instead of a generic name
indicating the type of the message dialog, as the
window title is generally more informative, if set.
It also better matches the information presented
visually on screen (in the window title, task switchers,...)
and is in line with the handling for non-message-dialog
windows.

This can easily be tested with the "Dialogs and
Message Boxes" sample from gtk3-demo when setting
a title for the message dialog in there like this:

diff --git a/demos/gtk-demo/dialog.c b/demos/gtk-demo/dialog.c
index 0eb1c62397..53fb7f8b0e 100644
--- a/demos/gtk-demo/dialog.c
+++ b/demos/gtk-demo/dialog.c
@@ -25,6 +25,8 @@ message_dialog_clicked (GtkButton *button,
"number of times:");
   gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (dialog),
 "%d", i);
+  gtk_window_set_title (GTK_WINDOW (dialog), "Some informative title");
+
   gtk_dialog_run (GTK_DIALOG (dialog));
   gtk_widget_destroy (dialog);
   i++;

(cherry picked from commit 939737c3e72c2deaa0094f35838038df92f2a724)

Origin: upstream gtk-3-24 branch, after 3.24.43
---
 gtk/gtkmessagedialog.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gtk/gtkmessagedialog.c b/gtk/gtkmessagedialog.c
index 1de3118..ee35b26 100644
--- a/gtk/gtkmessagedialog.c
+++ b/gtk/gtkmessagedialog.c
@@ -373,7 +373,12 @@ update_accessible_name (GtkMessageDialog *dialog)
   if (!GTK_IS_ACCESSIBLE (atk_obj))
 return;
 
-  const char *name = NULL;
+  const char *name = gtk_window_get_title (GTK_WINDOW (dialog));
+  if (name && name[0])
+  {
+atk_object_set_name (atk_obj, name);
+return;
+  }
 
   switch (dialog->priv->message_type)
   {
@@ -438,6 +443,8 @@ update_title (GObject*dialog,
   title = gtk_window_get_title (GTK_WINDOW (dialog));
   gtk_label_set_label (GTK_LABEL (label), title);
   gtk_widget_set_visible (label, title && title[0]);
+
+  update_accessible_name (GTK_MESSAGE_DIALOG (dialog));
 }
 
 static void

Bug#1081179: Example patch hunk from a commit message applied to package source

[Simon McVittie]

On Sun, 08 Sep 2024 at 22:23:17 +0100, Simon Tatham wrote:
> But if you look at that patch, it's in 'git format-patch' format,
> containing a few headers, a commit message, and then the actual patch.
> And the patch hunk that introduced "Some informative title" is part of
> the _commit message_: it's clear from the surrounding text that the
> commit message author intended it as an example of the kind of change
> you _could_ apply if you wanted to test the behaviour modified by the
> patch. The author even indented the entire patch hunk by 4 spaces to
> indicate extra clearly that it wasn't intended to be applied.
> 
> So it surely should _not_ have been applied to the Debian source!

This seems to be because the patch series was generated with
`git format-patch` and `git apply`, but dpkg-source uses patch(1), which
has a much more "do what I mean" approach to reading patches.
In particular, it treats indented diffs as real diffs.

Ideally, `gbp pq` would somehow escape the indented diff when it
serializes the patch series into debian/patches to prevent this
misinterpretation.

Using dgit to upload would have detected this, because it validates that
what's in git matches what's in the .dsc:

gtk+3.0$ dgit --quilt=gbp push-source --dry-run
...
dgit: quilt differences: src:  == orig ## gitignores:  == orig ==
dgit: quilt differences:  HEAD ## o+d/p   HEAD == o+d/p
dgit view: creating patches-applied version using gbp pq
dgit view: created (commit id 97d5c77cbc50c059ecebc9a699f83b5475916431)
...
dpkg-source: info: local changes detected, the modified files are:
 work/demos/gtk-demo/dialog.c

> I suppose this could very well be viewed as a bug in whatever thing
> underlying 'apt source' is applying the patches

dpkg-source, I think.

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#1081314: nvidia-vulkan-icd: Recommends on -rtcore should be a Depends

[Simon McVittie]

Package: nvidia-vulkan-icd
Severity: important

nvidia-vulkan-icd currently Recommends libnvidia-rtcore on the
architectures where it exists.

According to Nvidia developers who I spoke to during my work on the Steam
Runtime, the 64-bit Vulkan driver is not meant to be run in production
without libnvidia-rtcore: even if some basic functionality might work
without it, that setup isn't tested or supported. They say that a
Recommends is not really strong enough here, and it should be a Depends.

https://github.com/ValveSoftware/Dota-2/issues/2787 is an example of a
game that does not work correctly (at least on newer GPUs) without
libnvidia-rtcore being installed.

Thanks,
smcv

Bug#1081302: nvidia-graphics-drivers: New upstream releases 550 (production) and 560 (new-feature)

[Simon McVittie]

Source: nvidia-graphics-drivers
Version: 545.23.06-2
Severity: wishlist

According to https://www.nvidia.com/en-gb/drivers/unix/ the 545 branch
has been superseded by:

* Latest Production Branch Version: 550.78
* Latest New Feature Branch Version: 560.35.03

I'm not completely clear on which of these is suitable for experimental
and which is suitable for testing/unstable, but it would be great if the
v545 packaging in experimental could be replaced with one of those.

According to
https://docs.nvidia.com/datacenter/tesla/drivers/index.html#cuda-drivers
the 535 branch is still the current long-term-support branch for data
centre use, and 550 is the shorter-lifetime production branch for data
centre use (but I don't know whether that has any impact on the support
lifetime of the corresponding consumer drivers, and 535 is no longer listed
on https://www.nvidia.com/en-gb/drivers/unix/ at all, which might indicate
that it's no longer a supported version for consumer/gaming use-cases).

I would guess the most appropriate thing might be 550 in experimental
first, possibly followed by 550 in unstable and 560 in experimental?

There are indications that Vulkan games like Dota 2, when running on newer
GPUs, might need a newer driver than the v535 that we currently have in
Debian: .
But I don't have an affected GPU, so I'm unable to confirm that.

Thanks,
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#1077178: gtk4: reftest failure in label-shadows.ui when using softpipe

[Simon McVittie]

Control: retitle -1 gtk4: reftest failure in label-shadows.ui when using 
softpipe

On Fri, 26 Jul 2024 at 14:38:33 +0100, Simon McVittie wrote:
> On Fri, 26 Jul 2024 at 14:18:53 +0200, Matthias Geiger wrote:
> > 604/668 gtk:reftest / reftest label-shadows.ui  fails because there is a
> > (imo) minor diff
> 
> According to #1077181 the same thing happens on riscv64. This might be
> to do with llvmpipe being problematic on those two architectures.

I can reproduce this on another architecture (armel) by forcing use of
GALLIUM_DRIVER=softpipe, so it seems this is a rendering difference
between llvmpipe (good) and softpipe (bad).

For riscv64, we can revisit this when a hopefully-fixed llvm-toolchain-18
has finished compiling, at which point we might be able to use llvmpipe.

For mips64el, I don't know what the outlook is.

smcv