Bug#1067083: python-uinput: FTBFS on arm{el,hf}: libsuinput/src/suinput.c:48:28: error: ‘struct input_event’ has no member named ‘time’

2024-03-18 Thread Simon McVittie
On Mon, 18 Mar 2024 at 09:12:36 +0100, Sebastian Ramacher wrote:
> arm-linux-gnueabihf-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g 
> -Werror=implicit-function-declaration -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python3.11 -c libsuinput/src/suinput.c -o 
> build/temp.linux-armv7l-cpython-311/libsuinput/src/suinput.o
> libsuinput/src/suinput.c: In function ‘suinput_emit’:
> libsuinput/src/suinput.c:48:28: error: ‘struct input_event’ has no member 
> named ‘time’
>48 | gettimeofday(, 0);
>   |^

This is probably the same thing fixed by
. Untested pseudocode
for a fix:

-gettimeofday(, 0);
+struct timeval timestamp;
+gettimeofday(, 0);
+event.input_event_sec = timestamp.tv_sec;
+event.input_event_usec = timestamp.tv_usec;

smcv



Bug#1061019: xdg-desktop-portal: FTBFS: test_inputcapture: Timed out waiting for response from SetPointerBarriers

2024-03-17 Thread Simon McVittie
Control: tags -1 + moreinfo help
Control: severity -1 important

On Sun, 21 Jan 2024 at 13:17:45 +, Simon McVittie wrote:
> On Tue, 16 Jan 2024 at 20:37:49 +0100, Lucas Nussbaum wrote:
> > > 26/28 xdg-desktop-portal:pytest / pytest test_inputcaptureFAIL
> > > 11.21s   exit status 1
> > > >>> MALLOC_PERTURB_=39 
> > > >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> > > >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
> > > >>>  /usr/bin/pytest-3 --verbose --log-level=DEBUG -k test_inputcapture
> 
> I tried rebuilding the package locally (in sbuild in an amd64 bookworm
> VM) and this test passed.

I still cannot reproduce this, and it doesn't seem to affect the buildds
or reproducible-builds infrastructure, so I don't consider this to be RC.
I attach an example of a successful build log.

It's probably a race condition in the upstream test suite, possibly
triggered by Lucas' test-build happening on a machine with 8 cores and 32G
of RAM. If someone else can reproduce this, patches gratefully received.

Thanks,
smcv


xdg-desktop-portal_1.18.2-1_amd64_20240317t150806.build.gz
Description: application/gzip


Bug#1067043: libruby: needs updating for libruby3.1t64

2024-03-17 Thread Simon McVittie
Package: libruby
Version: 1:3.1
Severity: serious
Justification: blocker for 64-bit time_t transition
X-Debbugs-Cc: z...@debian.org, debian-...@lists.debian.org
Control: affects -1 + src:graphviz src:vala

Now that libruby3.1t64 has reached unstable, libruby is uninstallable on
the architectures affected by the 64-bit time_t transition, blocking the
rebuild of packages such as graphviz and vala via this dependency chain:

... -> vala -> graphviz -> ruby -> libruby -> libruby3.1

The impact of this is visible in for example
.

I suspect the only change needed here is to update the libruby metapackage
so that it depends on libruby3.1t64 instead of libruby3.1. Please could
someone who knows Ruby check this?

Thanks,
smcv



Bug#1067035: apache2-bin: rebuild for the 64-bit time_t migration is uninstallable

2024-03-17 Thread Simon McVittie
Control: reassign -1 libaprutil1t64
Control: found -1 1.6.3-1.1
Control: affects -1 + apache2-bin
Control: tags -1 + patch

On Sun, 17 Mar 2024 at 12:01:38 +0100, Étienne Mollier wrote:
> libaprutil164 (note the missing 't' for "t64") is not available
> in unstable.  The dependency looks typoed and duplicated, as
> libaprutil1t64 (>= 1.6.0) is also present as needed in the
> Depends field,

If I'm reading correctly, this is a bug in the NMU of libaprutil1t64 with
the rename for 64-bit time_t, not a bug in apache2-bin. The .symbols
file in libaprutil1t64 generates dependencies on a nonexistent package
name if functions related to LDAP or database functionality are used.

I believe the attached patches should fix this (untested). After fixing
this in apr-util, apache2 will need a binNMU (or a re-upload).

I have not attempted to fix apr-util's other RC bug, #1066821.

smcv
>From e36a8c4784278ccfb32d112b57cd2260fedb2e3c Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 17 Mar 2024 13:21:29 +
Subject: [PATCH 2/3] d/libaprutil1t64.symbols: Fix name of t64 binary package

It's libaprutil1t64 (with the "t"), not libaprutil164.

Closes: #1067035
---
 debian/libaprutil1t64.symbols | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/libaprutil1t64.symbols b/debian/libaprutil1t64.symbols
index 8468461..0b6493b 100644
--- a/debian/libaprutil1t64.symbols
+++ b/debian/libaprutil1t64.symbols
@@ -1,6 +1,6 @@
 libaprutil-1.so.0 libaprutil1t64 #MINVER#
-| libaprutil1-ldap , libaprutil164 #MINVER#
-| libaprutil1-dbd-sqlite3|libaprutil1-dbd-mysql|libaprutil1-dbd-odbc|libaprutil1-dbd-pgsql|libaprutil1-dbd-freetds , libaprutil164 #MINVER#
+| libaprutil1-ldap , libaprutil1t64 #MINVER#
+| libaprutil1-dbd-sqlite3|libaprutil1-dbd-mysql|libaprutil1-dbd-odbc|libaprutil1-dbd-pgsql|libaprutil1-dbd-freetds , libaprutil1t64 #MINVER#
  _crypt_blowfish_rn@Base 1.5.0
  _crypt_gensalt_blowfish_rn@Base 1.5.0
  _crypt_output_magic@Base 1.5.0
-- 
2.43.0

>From 1ea1785071067c436b9e0b1938fbc2553e849d3f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 17 Mar 2024 13:22:27 +
Subject: [PATCH 3/3] d/libaprutil1t64.lintian-overrides: Remove unnecessary
 lintian override

---
 debian/libaprutil1t64.lintian-overrides | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/libaprutil1t64.lintian-overrides b/debian/libaprutil1t64.lintian-overrides
index 90a6b4d..fb2f313 100644
--- a/debian/libaprutil1t64.lintian-overrides
+++ b/debian/libaprutil1t64.lintian-overrides
@@ -1,3 +1,2 @@
 libaprutil1t64: symbols-declares-dependency-on-other-package
 libaprutil1t64: package-name-doesnt-match-sonames libaprutil-1-0
-libaprutil1t64: package-name-doesnt-match-sonames libaprutil1
-- 
2.43.0



Bug#1067004: gmpc: no upstream maintainer

2024-03-16 Thread Simon McVittie
Source: gmpc
Severity: important
Tags: upstream wontfix
X-Debbugs-Cc: gmpc-plug...@packages.debian.org

It appears that gmpc no longer has any sort of upstream developer.
https://github.com/DaveDavenport/gmpc is specifically labelled as
unmaintained, https://repo.or.cz/w/gmpc.git hasn't been touched since 2015,
and the former maintainer's domains sarine.nl and gmpclient.org are
domain-parking placeholders.

I am already a single point of failure for too many things, so I am not
able to become the new upstream maintainer for this. Is there anyone else
in the mpd team who could?

Next time there is a problem that is not trivial to solve, we are
probably going to have to deprecate and remove this package, for example
in favour of sonata (which is also looking for a new maintainer, but at
least it still has somewhere for that announcement to appear).

smcv



Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

2024-03-16 Thread Simon McVittie
On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote:
> For example curl isn't building on armel/armhf now and numerous packages that
> depend of curl are not building on armel/armhf.

I believe a maintainer upload or NMU of #1066981 and #1066982 would
now be enough to unblock curl, which would hopefully unblock a lot of
the C/C++ ecosystem (in particular fixing the unsatisfiable dependency
libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow
gdb to be installed), while also making life easier for the people trying
to re-bootstrap cargo.

As a non-user of the affected architectures, I'm not comfortable with
being responsible for NMU'ing those changes (certainly not without giving
the curl maintainers a chance to comment!), but I've provided patches so
that either a curl maintainer or a porter could do so.

Thanks,
smcv



Bug#1066982: curl: please consider temporarily disabling LDAP and build-time tests on 32-bit non-x86

2024-03-16 Thread Simon McVittie
Source: curl
Version: 8.6.0-3.2
Severity: wishlist
X-Debbugs-Cc: debian-...@lists.debian.org, e...@debian.org
Tags: trixie sid patch
Control: block -1 by 1066981

On the architectures affected by the 64-bit time_t transition, there
are at least two cyclic build-dependencies involving this package:
curl, openldap, cyrus-sasl2, postgresql-16, gdb, elfutils, curl and
curl, impacket, pyopenssl, python-cryptography, cargo, curl.

I think it could be pragmatic to disable build-time tests and LDAP on
the affected architectures for a short time in order to unblock this
transition: quite a lot of packages are queued for rebuilding behind
curl and/or cargo.

The attached patches (which are also available from
https://salsa.debian.org/debian/curl/-/merge_requests/24, and depend
on the build profile added in #1066981) implement what I'm
suggesting. I've confirmed that the package builds successfully with
this change in armel and armhf porterbox chroots, and that it still runs
build-time tests on amd64 and i386 (at the time of writing, my amd64
build has passed its tests and my i386 build is still running them).

Unlike #1066981, the patches attached to this bug are intended to be
temporary and should be reverted when the transition has finished.

Thanks,
smcv
>From bc8cd5d7a40c8acaf2c164c538b6c0b07f2d3dab Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 16 Mar 2024 11:36:05 +
Subject: [PATCH 2/3] Temporarily disable LDAP support on 32-bit non-x86

This makes official buildd builds of curl (with no special build
profiles) temporarily equivalent to pkg.curl.noldap on the
architectures affected by the ongoing 64-bit time_t transition.

This helps to break cyclic dependencies like this one:
curl, openldap, cyrus-sasl2, postgresql-16, gdb, elfutils, curl.
It can be reverted after the transition has progressed past curl.

Helps: #1036884
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index ee188861b..fe6cf6881 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Build-Depends: dpkg-dev (>= 1.22.5),
  libgnutls28-dev,
  libidn2-dev,
  libkrb5-dev,
- libldap2-dev ,
+ libldap2-dev [!armel !armhf !hppa !m68k !powerpc !sh4] ,
  libnghttp2-dev,
  libpsl-dev,
  librtmp-dev,
-- 
2.43.0

>From c105fbbae946bae3c755d8f87d247a36d8d59d47 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 16 Mar 2024 11:34:46 +
Subject: [PATCH 3/3] Temporarily disable build-time tests on 32-bit non-x86

This makes official buildd builds of curl (with no special build profiles)
temporarily equivalent to nocheck on the architectures affected by the
ongoing 64-bit time_t transition.

This helps to break cyclic dependencies like this one:
curl, impacket, pyopenssl, python-cryptography, cargo, curl.
It can be reverted after the transition has progressed past curl.

Helps: #1036884
---
 debian/control | 12 ++--
 debian/rules   |  4 
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index fe6cf6881..35945dfcf 100644
--- a/debian/control
+++ b/debian/control
@@ -25,13 +25,13 @@ Build-Depends: dpkg-dev (>= 1.22.5),
  libssl-dev,
  libtool,
  libzstd-dev,
- locales-all ,
- openssh-server ,
- python3:native ,
- python3-impacket ,
- gnutls-bin [!ppc64el] ,
+ locales-all [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ openssh-server [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ python3:native [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ python3-impacket [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ gnutls-bin [!armel !armhf !hppa !m68k !powerpc !sh4 !ppc64el] ,
  quilt,
- stunnel4 ,
+ stunnel4 [!armel !armhf !hppa !m68k !powerpc !sh4] ,
  zlib1g-dev,
 Build-Conflicts: autoconf2.13, automake1.4
 Standards-Version: 4.6.2
diff --git a/debian/rules b/debian/rules
index 3049d659d..f0ceec938 100755
--- a/debian/rules
+++ b/debian/rules
@@ -100,6 +100,9 @@ TESTS_GENERAL_PARAMETERS += $(TESTS_FAILS_ON_IPV6_ONLY_MACHINES)
 
 override_dh_auto_test:
 ifeq ($(filter nocheck,$(DEB_BUILD_PROFILES)),)
+ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
+	: # TODO: Tests temporarily skipped for 64-bit time_t transition
+else
 ifeq ($(filter pkg.curl.no-openssl,$(DEB_BUILD_PROFILES)),)
 # OpenSSL tests.
 	cd debian/build && VERBOSE=1 \
@@ -113,6 +116,7 @@ ifeq ($(filter pkg.curl.no-gnutls,$(DEB_BUILD_PROFILES)),)
 		$(MAKE) test-nonflaky
 endif
 endif
+endif
 
 override_dh_install:
 ifeq ($(filter pkg.curl.no-openssl,$(DEB_BUILD_PROFILES)),)
-- 
2.43.0



Bug#1066981: curl: please provide a build-profile that disables LDAP

2024-03-16 Thread Simon McVittie
Source: curl
Version: 8.6.0-3.2
Severity: wishlist
Tags: trixie sid patch
User: debian-cr...@lists.debian.org
Usertags: staged-build

curl is involved in the critical path for re-bootstrapping 32-bit
architectures for the time_t transition, and in general it's likely
to be tied up in bootstrapping of every other new architecture, because
important toolchain components like elfutils and cmake depend on it.
One thing that can easily be done to break some of the cycles is to
disable its optional support for openldap, which is involved in cycles like:
curl, openldap, cyrus-sasl2, postgresql-16, gdb, elfutils, curl.

The attached patch (also available from
https://salsa.debian.org/debian/curl/-/merge_requests/23)
adds a build-profile that disables this optional feature.

I've confirmed that in the current state of unstable, curl can be built
successfully in armel and armhf porterbox chroots with the combination of
this build profile and nocheck.

(An ulterior motive for me contributing this change is that in my
day job, I'm involved in maintaining the Debian-based Steam Runtime,
which contains a copy of curl with its packaging patched to disable
LDAP, RTSP, RTMP and possibly other features that are unlikely to be
used by game engines. When I'm back at work I'd be happy to look at
contributing similar build-profiles to disable other optional bits if
there is interest.)

smcv
>From ae094c1e4b2b0ec943f39f2b6a6176091af20d33 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 16 Mar 2024 11:26:58 +
Subject: [PATCH 1/3] d/control: Add a build-profile that disables LDAP support

openldap is involved in a cyclic build dependency
(curl, openldap, cyrus-sasl2, postgresql-16, gdb, elfutils, curl).
The ability to load LDAP resources is probably a relatively infrequently
used feature of curl, and is straightforward to disable.

Helps: #1036884
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index de9ac8f69..ee188861b 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Build-Depends: dpkg-dev (>= 1.22.5),
  libgnutls28-dev,
  libidn2-dev,
  libkrb5-dev,
- libldap2-dev,
+ libldap2-dev ,
  libnghttp2-dev,
  libpsl-dev,
  librtmp-dev,
-- 
2.43.0



Bug#1066900: g-ir-compiler: generates incorrect typelib when cross-compiling with different type sizes

2024-03-15 Thread Simon McVittie
Control: clone -1 -2
Control: retitle -2 gi-compile-repository: generates incorrect typelib when 
cross-compiling with different type sizes
Control: reassign -2 libglib2.0-dev 2.79.3-1
Control: tags -2 = experimental

On Fri, 15 Mar 2024 at 07:48:17 +, Simon McVittie wrote:
> When it converts GIR XML to binary typelib files, g-ir-compiler replaces
> abstract types such as int and gsize (size_t) with concrete types such as
> gint32 (int32_t) and guint64 (uint32_t). The way in which it does this
> depends on the type sizes discovered at configure time when compiling
> g-ir-compiler.

gi-compile-repository in libglib2.0-dev/experimental has the same issue,
cloning the bug for that.

> A workaround to enable cross-compiling between word sizes would be to use
> the host architecture g-ir-compiler, and run it via qemu-user.

Actually it looks like this is going to be a shorter path to correctness
than the other approaches I described, so I'll probably go with this one.

smcv



Bug#1066900: g-ir-compiler: generates incorrect typelib when cross-compiling with different type sizes

2024-03-15 Thread Simon McVittie
Package: gobject-introspection
Version: 1.78.1-16
Severity: serious
Justification: results in misbuilt packages
X-Debbugs-Cc: debian-cr...@lists.debian.org

When it converts GIR XML to binary typelib files, g-ir-compiler replaces
abstract types such as int and gsize (size_t) with concrete types such as
gint32 (int32_t) and guint64 (uint32_t). The way in which it does this
depends on the type sizes discovered at configure time when compiling
g-ir-compiler.

This means that cross-compiling for an arm64 or riscv64 host on an amd64
build machine should be OK, but cross-compiling for armhf or i386 on amd64
will produce invalid typelibs. I am sorry that I didn't notice this sooner.

A crude solution to this would be to revert gobject-introspection and
gobject-introspection-bin to be Multi-Arch: no, so that building typelibs
is no longer possible in cross-builds. [1]

A more refined version of that would be to change the relationship between
gobject-introspection and gobject-introspection-bin so that instead of the
current arrangement where the dependency is on a virtual package
gobject-introspection-linux-little-endian, it would be on a virtual package
that also reflects the word size in use:
gobject-introspection-linux-lp64-little-endian or similar. This would
preserve the ability to cross-compile in only those situations where it
would be correct. [2]

A workaround to enable cross-compiling between word sizes would be to use
the host architecture g-ir-compiler, and run it via qemu-user.
Unfortunately this will greatly increase the amount of host-architecture
code that needs to be run via emulation.

In the short term, I'm going to do [1] or [2] as a matter of urgency,
to ensure that Ubuntu 24.04 doesn't ship with faulty cross-tools that
claim to work but actually do not. Any further improvement can be in-scope
for #1030223 "gobject-introspection: make cross-compilation possible".

If we do [2] then we will have to be extra-careful to distinguish between
dissimilar ILP32 ABIs, because gobject-introspection currently hard-codes
that it thinks time_t is long and off_t is size_t, both of which happen
to be correct on LP64 and on i386, but neither of which is correct on
an ILP32 architecture that has transitioned to large file support and
64-bit time_t (such as armel and armhf in 2024) or an ILP32 architecture
that always had 64-bit off_t and time_t (such as x32).

I apologise for having been insufficiently careful when enabling this
feature.

smcv



Bug#1066847: openssh: please consider disabling ssh-askpass-gnome on 32-bit during the time_t transition

2024-03-14 Thread Simon McVittie
Source: openssh
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian-...@lists.debian.org

On the architectures affected by the 64-bit time_t transition, there
is at least one cyclic build-dependency involving this package:
openssh-server, gtk+3.0, at-spi2-core, dbus-broker, systemd, cryptsetup,
libssh, openssh-server.

I've tried to break this cycle at at-spi2-core (#1066844) but that's going
to require additional changes in gtk+3.0, to disable its test suite (which
requires librsvg, which requires Rust, which needs re-bootstrapping)
on the affected architectures, and at this stage I'm unsure whether other
relevant cycles exist.

I think it would be pragmatic to disable ssh-askpass-gnome on the affected
architectures for the duration of this transition: it's a low-popcon
leaf package which is the only thing pulling in "heavy" dependencies
to openssh. I attach a possible patch. I've verified that it compiles
successfully in an armhf porterbox chroot (without ssh-askpass-gnome)
and on amd64 (with ssh-askpass-gnome), but I haven't otherwise tested it.

Thanks,
smcv
>From bbefe785a6ab567677af77ccd12b1fbb59a42d8d Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 14 Mar 2024 10:48:03 +
Subject: [PATCH] d/control, d/rules: Disable ssh-askpass-gnome on 32-bit,
 except i386

On the architectures affected by the 64-bit time_t transition, there
is at least one cyclic build-dependency involving this package:
openssh-server, gtk+3.0, at-spi2-core, dbus-broker, systemd, cryptsetup,
libssh, openssh-server. Temporarily dropping a low-popcon binary package
that is already excludable by a build-profile seems like a convenient
place to break the cycle.

Closes: #-1
---
 debian/control | 2 +-
 debian/rules   | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 0a785bcb2..38abe62ec 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends: debhelper (>= 13.1~),
libaudit-dev [linux-any],
libedit-dev,
libfido2-dev (>= 1.5.0) [linux-any],
-   libgtk-3-dev ,
+   libgtk-3-dev [!armel !armhf !hppa !m68k !powerpc !sh4] ,
libkrb5-dev | heimdal-dev,
libpam0g-dev | libpam-dev,
libselinux1-dev [linux-any],
diff --git a/debian/rules b/debian/rules
index fd9ab8d03..cd4c27b58 100755
--- a/debian/rules
+++ b/debian/rules
@@ -108,6 +108,10 @@ ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386)
   BUILD_PACKAGES += -Nopenssh-tests
 endif
 
+ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
+  BUILD_PACKAGES += -Nssh-askpass-gnome
+endif
+
 %:
 	dh $@ --with=runit $(BUILD_PACKAGES)
 
@@ -132,9 +136,11 @@ ifeq ($(filter noudeb,$(DEB_BUILD_PROFILES)),)
 	$(MAKE) -C debian/build-udeb $(PARALLEL) ASKPASS_PROGRAM='/usr/bin/ssh-askpass' ssh scp sftp sshd ssh-keygen
 endif
 
+ifneq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
 ifeq ($(filter pkg.openssh.nognome,$(DEB_BUILD_PROFILES)),)
 	$(MAKE) -C contrib gnome-ssh-askpass3 CC='$(CC) $(CPPFLAGS) $(CFLAGS) -Wall -Wl,--as-needed $(LDFLAGS)' PKG_CONFIG=$(PKG_CONFIG)
 endif
+endif
 
 override_dh_auto_build-indep:
 
-- 
2.43.0



Bug#1066844: at-spi2-core: needs re-bootstrapping on armel, armhf for 64-bit time_t transition

2024-03-14 Thread Simon McVittie
Package: at-spi2-core
Version: 2.51.90-3
Severity: important
X-Debbugs-Cc: debian-...@lists.debian.org
Tags: patch

at-spi2-core has a circular build-dependency on itself when tests are
enabled, which makes its build-dependencies unsatisfiable (libglib2.0-dev
depends on libglib2.0-0t64, but at-spi2-core still depends on libglib2.0-0)
and prevents it from being rebuilt for the 64-bit time_t transition.
I think the easiest way to unblock this will be to disable tests on the
affected architectures temporarily, similar to what was done in stunnel4.

It's also affected by a longer cyclic build-dependency chain:
at-spi2-core, dbus-broker, systemd, cryptsetup, libssh, openssh-server,
gtk+3.0, back to at-spi-2-core. I think the easiest way to break this
one will be temporarily swapping back from dbus-broker to dbus-daemon
as preferred on the affected architectures. I confirmed that this makes
it buildable on a porterbox.

Proposed patches available on
https://salsa.debian.org/a11y-team/at-spi2-core/-/merge_requests/8,
I'll attach them to the bug when I've amdended them to include the
bug number.

After at-spi2-core has been rebuilt, I'm hoping that similar changes will
unblock the ability to rebuild gtk+2.0 and gtk+3.0.

smcv



Bug#1031802: fuse3: inaccurate information in symbols file (was: Re: libvirt-daemon-driver-lxc: Incorrect dependencies)

2024-03-13 Thread Simon McVittie
On Sat, 18 Mar 2023 at 14:46:47 +0100, Andrea Bolognani wrote:
> In other words, upstream developers have retroactively added symbols
> (fuse_new_31) to existing symbol groups (FUSE_3.1).
...
> really this looks like an upstream
> bug in my opinion: even if the function was present in the source
> code all the way back in 3.1, it's only publicly exported starting
> with 3.13, and so exposing it as fuse_new_31@FUSE_3.13 would have
> been the correct way to go about it IMO.

I agree that this was incorrect, but now that several released libfuse
versions have had this bug, it is part of the ABI. In the absence of a
time machine, upstream cannot go back and correct it.

> I believe it should be possible to work around this in Debian by
> adding an entry like
> 
>   fuse_new_31@FUSE_3.1 3.13.0
> 
> to debian/libfuse3-3.symbols

Since we don't have a time machine, I think this would be the
correct answer to this bug. That would result in packages like
libvirt-daemon-driver-lxc generating correct dependencies next time they
are rebuilt.

On Wed, 13 Mar 2024 at 01:05:40 +0100, Bernd Schubert wrote:
> Would it help to move that symbol to FUSE_3.13 in the version script
> (for example in libfuse-3.17?)?

No, please don't do that: that would make the library as shipped by
Debian permanently incompatible with one built from upstream source.

smcv



Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

2024-03-13 Thread Simon McVittie
On Tue, 12 Mar 2024 at 23:13:30 -0500, Steven Robbins wrote:
> I checked the build logs for cargo and noticed that most architectures have 
> been built on the buildds.  All release arches except armel & armhf.  How is 
> it that these two have build dep installability problems but others do not?

Those two are the only release architectures where the 64-bit time_t
transition has caused an ABI break:

1. amd64, arm64, mips64el, ppc64el, riscv64, s390x are all 64-bit, so they
   already had 64-bit time_t
  - non-release architectures in the same category:
alpha hurd-amd64 ia64 loong64 ppc64 sparc64

2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
   because its major purpose this decade is running legacy 32-bit binaries,
   a purpose that would no longer be possible if it broke ABI
   - non-release architectures in the same category: hurd-i386 (I think)

3. There is currently no release architecture that is 32-bit but already had
   a 64-bit time_t prior to 2024
   - non-release architectures in this category: x32

4. armel, armhf are the two remaining 32-bit release architectures after
   excluding all of the above
   - non-release architectures in the same category:
 hppa m68k powerpc sh4

I hope that helps to categorise the architectures that do/don't have a
problem here.

For architectures in categories 1, 2 and 3 above, libfoo0 is still renamed
to libfoo0t64, but libfoo0t64 Provides: libfoo0, making it significantly
easier to satisfy build-dependencies. The last category is the only one
where there has genuinely been a compatibility break and therefore this
Provides would be wrong, so it is also the category where some packages
need re-bootstrapping.

smcv



Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

2024-03-12 Thread Simon McVittie
On Tue, 12 Mar 2024 at 22:30:01 +0100, Michael Biebl wrote:
> On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer  wrote:
> > My speculation is that this happened while satisfying dependencies for
> > a third party i386 application. That meant installing required 32 bit
> > libraries, and one of them must have come with a polkitd dependency,
> > and the i386 version was selected because I was installing an i386
> > package.
...
> Is there a valid use case where we need/want a foreign systemd/policykit-1?

The valid use-case for polkitd being Multi-Arch: foreign is the scenario
Bertram described: you install third-party, potentially binary-only
i386 software onto an amd64 system, and it depends on polkitd. We want
polkitd:amd64 to be able to satisfy that dependency.

That's also why we want systemd(-sysv) to be Multi-Arch: foreign:
for example the i386-only quake4-server needs systemd (in that case
it's actually a only Recommends, because you don't *need* to use the
systemd units, but it could in principle have been a Depends) and we
want systemd(-sysv):amd64 to satisfy that dependency.

I don't know of any valid use-case for polkitd and systemd(-sysv)
being of an architecture that is not the same as the system's primary
architecture, except for perhaps briefly during crossgrading, but that
isn't what Multi-Arch: foreign means anyway.

"The primary architecture" really just means "the same architecture
as dpkg", and I don't think there is any metadata that could be set on
polkitd or systemd to say that they must be of that same architecture.

smcv



Bug#1064707: devscripts: FTBFS: AssertionError: black found code that needs reformatting:

2024-03-12 Thread Simon McVittie
On Sun, 25 Feb 2024 at 20:36:58 +0100, Lucas Nussbaum wrote:
> > FAIL: test_black (devscripts.test.test_black.BlackTestCase.test_black)
> > Test: Run black code formatter on Python source code.

I think lint checks like this one should be run by contributors and CI
when targeting the main branch, but skipped when building or testing
a released, production-ready .deb package - they're just too fragile
against new versions of the lint tool that move the goalposts.

smcv



Bug#1036884: transition: time64_t

2024-03-12 Thread Simon McVittie
Control: block -1 by 1065787 1066049

One dependency chain that is blocking a lot of rebuilds right now is
this one:

... => curl -> stunnel4 -> python-cryptography => cargo => ...

key: => mandatory dependency
 -> nocheck dependency

In the medium term, cargo needs re-bootstrapping on the affected
architectures (armel and armhf, plus a bunch of -ports architectures
where as far as I can see cargo was never available in the past) -
that's #1065787, and Steve already replied to that bug describing how
Ubuntu did this. Is there a porter who can take responsibility for that?

In the shorter term, I think it might be pragmatic to build either curl
or stunnel4 with tests disabled on the affected architectures, breaking
that dependency chain and allowing most C/C++ packages that are being held
up by curl to be rebuilt in parallel.

I think disabling tests in stunnel4 would have less impact on the rest
of Debian than disabling tests in curl if it results in an undetected
regression, so I'd suggest stunnel4 as the place to break that chain. I've
sent a proposed patch to #1066049.

On IRC, Michael Biebl suggested an alternative plan of configuring the
armel|armhf buildds to always build with the nocheck profile for the
duration of the transition (and presumably keep track of the affected
packages to be rebuilt with build-time tests afterwards), but as far as
I know that's not possible in our infrastructure?

Thanks,
smcv



Bug#1066049: stunnel4: please consider temporarily disabling tests on arm to unblock the t64 transition

2024-03-12 Thread Simon McVittie
On Mon, 11 Mar 2024 at 20:09:06 +, Simon McVittie wrote:
> Thanks for proposing this, but I think these should be ifneq instead
> of ifeq

Actually, this patch also still allowed dh_auto_test to run on the
time64-affected architectures, which would presumably fail because the
tests' dependencies weren't met.

I attach a tested patch based on Mattia's, also available from
<https://salsa.debian.org/debian/stunnel/-/merge_requests/3>. This seems
to have the desired results:

* amd64: tests are run, and pass; autopkgtests also pass
* i386: tests are run, and pass; autopkgtests still in progress at the
  time of writing
* armhf on a porterbox: tests are not run, package is buildable without
  having to wait for python3-cryptography

armhf and other affected architectures will still be tested via autopkgtest
after python3-cryptography becomes available.

I think this change might be a pragmatic way to shorten the critical
path for the time64 transition. Please consider applying it?

Thanks,
smcv
>From 93d5d5d18d916d7fda9dcd0298019f9e1c887133 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 12 Mar 2024 10:26:49 +
Subject: [PATCH 1/2] Don't run build-time tests on the 32-bit non-i386
 architectures

This allows libcurl to be rebuilt on the architectures affected by the
64-bit time_t transition, which unblocks rebuilding of a lot of the
C/C++ ecosystem without having to wait for rustc/cargo to be
re-bootstrapped (#1065787).

Closes: #1066049
Co-authored-by: Mattia Rizzolo 
Signed-off-by: Simon McVittie 
---
 debian/control | 10 +-
 debian/rules   |  5 +
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index f32dc6f..f34acbd 100644
--- a/debian/control
+++ b/debian/control
@@ -10,13 +10,13 @@ Build-Depends:
  libssl-dev,
  libsystemd-dev [linux-any],
  libwrap0-dev,
- net-tools ,
- netcat-openbsd ,
+ net-tools [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ netcat-openbsd [!armel !armhf !hppa !m68k !powerpc !sh4] ,
  openssl,
  pkgconf,
- procps ,
- python3 ,
- python3-cryptography ,
+ procps [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ python3 [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ python3-cryptography [!armel !armhf !hppa !m68k !powerpc !sh4] ,
 Maintainer: Peter Pentchev 
 Uploaders: Laszlo Boszormenyi (GCS) 
 Standards-Version: 4.6.2
diff --git a/debian/rules b/debian/rules
index 8801c88..d022647 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,6 +30,10 @@ override_dh_auto_configure:
 	sleep 1
 	touch src/dhparam.c
 
+ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
+override_dh_auto_test:
+	: # Tests temporarily skipped for 64-bit time_t transition
+else
 execute_before_dh_auto_test:
 	env PYTHONPATH='$(CURDIR)/debian/tests/python' \
 		python3 -B -u -m struntime \
@@ -42,6 +46,7 @@ override_dh_auto_test:
 		find tests/logs/ -type f -name '*.log' -exec grep -EHe '^' -- '{}' + 1>&2; \
 		false; \
 	}
+endif
 
 override_dh_auto_install:
 	dh_auto_install -- -C src
-- 
2.43.0

>From ca30697de1fd1f034947dff786cca0f897fc2f03 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 12 Mar 2024 10:29:26 +
Subject: [PATCH 2/2] Update changelog

---
 debian/changelog | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9f9ff57..90f0a3b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+stunnel4 (3:5.72-1.1) UNRELEASED; urgency=medium
+
+  * Don't run build-time tests on the 32-bit non-i386 architectures.
+This allows libcurl to be rebuilt on the architectures affected by the
+64-bit time_t transition, which unblocks rebuilding of a lot of the
+C/C++ ecosystem without having to wait for rustc/cargo to be
+re-bootstrapped (#1065787).
+Thanks to Mattia Rizzolo (Closes: #1066049)
+
+ -- Simon McVittie   Tue, 12 Mar 2024 10:28:55 +
+
 stunnel4 (3:5.72-1) unstable; urgency=medium
 
   * Minor improvements to the test suite for the autopkgtest suite:
-- 
2.43.0



Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

2024-03-12 Thread Simon McVittie
Control: tags -1 + fixed-upstream
Control: block -1 by 1061616
Control: retitle 1061616 pixman: New upstream version 0.43.4

On Mon, 29 Jan 2024 at 10:23:45 +, Simon McVittie wrote:
> On Mon, 29 Jan 2024 at 05:13:59 +, Gayathri Berli wrote:
> > we found out that while
> > upgrading libpixman (libpixman-1-0:s390x) package from version 0.40.0-1 to
> > version 0.42.2-1, the test suites failed in the librsvg.
...
> > There is one open issues in pixman regarding to this commit changes which
> > effecting the big-endian systems.

I've been told in private email that
https://gitlab.freedesktop.org/pixman/pixman/-/issues/78 was fixed in the
recent pixman 0.43.4 release.

As noted in https://bugs.debian.org/1061616, pixman upstream has stopped
using the odd/even minor version convention (as seen in GLib, dbus,
Flatpak, SDL, etc.) and switched to a versioning scheme where odd and
even minor versions are interchangeable, so 0.43.x is a stable relase
series even though 0.41.x was not.

pixman maintainers: please upgrade to 0.43.4 when it will not disrupt
the ongoing 64-bit time_t transition.

Thanks,
smcv



Bug#1066049: stunnel4: please consider temporarily disabling tests on arm to unblock the t64 transition

2024-03-11 Thread Simon McVittie
On Mon, 11 Mar 2024 at 19:54:00 +0100, Mattia Rizzolo wrote:
> +ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
>  execute_before_dh_auto_test:
>   env PYTHONPATH='$(CURDIR)/debian/tests/python' \
>   python3 -B -u -m struntime \
>   --certdir='$(CURDIR)/debian/tests/certs' \
>   --program='$(CURDIR)/src/stunnel'
> +endif
>  
> +ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
>  override_dh_auto_test:
>   dh_auto_test || { \
>   printf '\n\n=== Some tests failed; here are all the 
> logs...\n\n' 1>&2; \
>   find tests/logs/ -type f -name '*.log' -exec grep -EHe '^' -- 
> '{}' + 1>&2; \
>   false; \
>   }
> +endif

Thanks for proposing this, but I think these should be ifneq instead
of ifeq: the current implementation looks like it's running tests on
exactly those architectures where you don't want to run tests :-)

The expression before the comma will expand to:

- 64: on amd64, arm64, s390x, etc. (we still want to run tests)
- 32: on armel, armhf, hppa, etc. (we don't want to run tests)
- 32i386: on i386 (we still want to run tests, because as a special
  exception, i386 does not get 64-bit time_t)

so we want to run the tests if it expands to anything other than 32.

The two if(n)eq..endif blocks could also be combined into one, to make
it more obvious that their condition is the same.

smcv



Bug#1066032: pygobject: FTBFS on armhf: time_t build test failure

2024-03-11 Thread Simon McVittie
On Mon, 11 Mar 2024 at 08:13:30 -0400, Jeremy Bícha wrote:
> Although Debian has not yet gotten to pygobject in the time_t
> transition for armel/armhf, Ubuntu has and experienced a build test
> failure in test_gi.py for the test_time_t tests which I believe are
> using functions in glib2.0. I assume Debian also experiences this
> issue.

This is probably the same issue that mwhudson reported to
.

smcv



Bug#1065713: directfb: FTBFS on arm{el,hf}: error: ‘const struct input_event’ has no member named ‘time’

2024-03-10 Thread Simon McVittie
On Sat, 09 Mar 2024 at 12:29:26 +0100, Sebastian Ramacher wrote:
> linux_input.c: In function ‘translate_event’:
> linux_input.c:761:28: error: ‘const struct input_event’ has no member named 
> ‘time’
>   761 |  devt->timestamp = levt->time;
>   |^~

This seems to be essentially the same bug that was fixed in SDL by:
https://github.com/libsdl-org/SDL/commit/10fc3b3db715f0e2050e49f39d7d6e932813723c
so hopefully that's a useful reference.

smcv



Bug#1065821: librsvg: reftest regression for rtl-tspan with pango1.0 1.52.1: 2655 pixels differ from reference

2024-03-10 Thread Simon McVittie
Control: retitle -1 librsvg: reftest regression for rtl-tspan with pango1.0 
1.52.1: 2655 pixels differ from reference
Control: severity -1 important

On Sun, 10 Mar 2024 at 14:45:24 +, Simon McVittie wrote:
> For now, I'm testing an upload that will temporarily disable this test,
> after which this bug can be downgraded to non-RC.

Uploaded, downgrading severity accordingly.

smcv



Bug#1065907: shared-mime-info: consider including upstream source in Vcs-Git

2024-03-10 Thread Simon McVittie
Source: shared-mime-info
Version: 2.4-1
Severity: wishlist
Tags: patch

In my experience it is usually easier to work with source packages in a VCS
if their upstream source code is also present in the same VCS, and is
merged into the packaging branch (the same layout used by the GNOME,
Perl, Python and systemd teams, among others).

I've imported all upstream source known to snapshot.debian.org into:
https://salsa.debian.org/smcv/shared-mime-info/-/tree/pristine-tar?ref_type=heads
https://salsa.debian.org/smcv/shared-mime-info/-/tree/upstream/latest?ref_type=heads
Would it be OK to fetch these from my fork, push them to the main packaging
repository, and merge upstream/latest into the master branch?

Tags in the `upstream/*` namespace can also be fetched from my fork.

It might also be worth considering a rename of the master branch to
debian/latest as per .

Thanks,
smcv



Bug#1065821: librsvg: FTBFS: rtl-tspan: 2655 pixels changed with maximum difference of 112

2024-03-10 Thread Simon McVittie
Control: tags -1 + pending

On Sun, 10 Mar 2024 at 14:03:18 +, Simon McVittie wrote:
> On Sun, 10 Mar 2024 at 13:12:57 +0100, Sebastian Ramacher wrote:
> > rtl-tspan: 2655 pixels changed with maximum difference of 112
> 
> This appears to have been caused by upgrading pango1.0 from 1.52.0
> to 1.52.1. The librsvg test suite is unfortunately very sensitive to
> differences in the exact version of dependencies like pango1.0.

For now, I'm testing an upload that will temporarily disable this test,
after which this bug can be downgraded to non-RC.

After pango1.0 >= 1.52.1 reaches testing, we should add a versioned
build-dependency on it and re-enable this test, updating the reference
rendering if necessary (see also the upstream bug report
https://gitlab.gnome.org/GNOME/librsvg/-/issues/1063).

smcv



Bug#1065821: librsvg: FTBFS: rtl-tspan: 2655 pixels changed with maximum difference of 112

2024-03-10 Thread Simon McVittie
On Sun, 10 Mar 2024 at 13:12:57 +0100, Sebastian Ramacher wrote:
> rtl-tspan: 2655 pixels changed with maximum difference of 112

This appears to have been caused by upgrading pango1.0 from 1.52.0
to 1.52.1. The librsvg test suite is unfortunately very sensitive to
differences in the exact version of dependencies like pango1.0.

Please can we minimize disruptive changes in unstable until the ongoing
time_t disaster is resolved? In most cases, experimental is available
for testing newer upstream releases.

(For example glib2.0 2.80.x is only in experimental despite being an
upstream stable release, and I think that was an appropriate decision
at this stage.)

Thanks,
smcv



Bug#1065816: weston: Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0'

2024-03-10 Thread Simon McVittie
Control: block 1036884 by -1

On Sun, 10 Mar 2024 at 10:37:51 +0100, Aurelien Jarno wrote:
> weston fails to build in unstable since the upload of neatvnc in version
> 8.0. From my build log on amd64:
...
> | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 
> 0.7.0'

This is important for the 64-bit time_t transition, because weston is
part of that transition, and also because packages like gtk4 use weston in
headless mode to test their Wayland backends. This could be mitigated by
temporarily making gtk4 skip its Wayland tests on 32-bit architectures,
but with gtk4 hat on, I would not be comfortable with doing that in
the long term, because in practice it seems to be inevitable that
functionality that isn't tested doesn't actually work.

Looking at the recent neatvnc upload, I was surprised to see that its
former maintainer updated it to a new upstream release in the same upload
as orphaning it (#1065738), and also updated the closely-related wayvnc
package to a new upstream release that matches neatvnc.

I also noticed that neatvnc 0.8.0 has an ABI break without bumping the
SONAME (#1065824), although that might be ignorable since nothing in
Debian seems to use the affected symbol.

I think the options here in the short term are:

1. adapt weston to support neatvnc 0.8.0, if it's straightforward to do so;
2. revert neatvnc to 0.8.0+really0.7.1+dfsg and wayvnc to 0.8.0+really0.7.2,
   and revisit this later, when we are *not* in the middle of a transition
   that touches thousands of packages;
3. temporarily disable the VNC backend in weston, and revisit this later

I would personally be very tempted by (2.) since it seems like the option
with least risk of regressions when compared with what's currently in
trixie, but I have no particular knowledge of these packages, so it
would be better if the maintainers of weston and/or wayvnc could adopt
neatvnc and handle this in whatever way they prefer. If this situation
is not resolved then I might do the revert (2.), by QA-uploading neatvnc
and NMU'ing wayvnc.

Thanks,
smcv



Bug#1065824: libneatvnc0: ABI break in 0.8.0 without SONAME bump

2024-03-10 Thread Simon McVittie
Package: libneatvnc0
Version: 0.8.0+dfsg-1
Severity: important
Justification: Policy 8.6.2
Tags: upstream
X-Debbugs-Cc: wes...@packages.debian.org, way...@packages.debian.org

libneatvnc 0.8.0 removes a public function from its API/ABI:

│ -const char* nvnc_client_get_hostname(const struct nvnc_client* client);
│ +int nvnc_client_get_address(const struct nvnc_client* client,
│ + struct sockaddr* restrict addr, socklen_t* restrict addrlen);

>From codesearch.debian.net, it seems that nothing in Debian actually calls
nvnc_client_get_hostname(), so perhaps this is non-RC. Normally I'd be
saying this is a decision for its maintainer, but it was recently orphaned
(in the same upload that updated it to this new upstream version, which
seems an unusual choice), so now it's a decision for whoever takes over
maintenance.

If important packages like weston are going to have dependencies on
neatvnc, then I think it would be helpful for whoever takes over this
package to teach its upstream about the two options for ABI stability
(briefly: either don't break ABI, or do break ABI but at the same time
also bump the SONAME).

smcv



Bug#1065709: doomsday: segfault in _XFlush() when Qt is using native Wayland

2024-03-09 Thread Simon McVittie
Control: forcemerge 1065709 1057620

On Sat, 09 Mar 2024 at 11:06:46 +, Simon McVittie wrote:
> In a GNOME Wayland session, with qtwayland5 installed:
> 
> $ doomsday
> QSocketNotifier: Can only be used with threads started with QThread
> [1]381459 segmentation fault (core dumped)  doomsday

Sorry, I didn't see that #1057620 already existed as a report of this bug.
I'll keep the more specific title and higher severity of #1065709.

smcv



Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)

2024-03-09 Thread Simon McVittie
Control: clone -1 -2
Control: reassign -1 libsdl2 2.30.0+dfsg-1
Control: reassign -2 doomsday 2.3.1+ds1-1
Control: retitle -1 libsdl2: SDL_JoystickName() doesn't tolerate NULL joystick 
object since 2.30
Control: retitle -2 doomsday: shouldn't rely on being able to call methods on a 
NULL SDL object

On Sun, 04 Feb 2024 at 12:31:35 +, Simon McVittie wrote:
> When I try the command above, on GNOME in Wayland mode, I get what
> appears to be a different crash

Now reported separately as #1065709, which I now see was a duplicate
of #1057620 (I'll merge them).

> which makes me wonder whether there is some conflict between the way
> libsdl2 is using X11, and the way the doomsday engine is using X11
> internally?

Yes. A workaround for this crash is to run it like:

SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday -game doom2

and with that command I can reproduce a backtrace similar to the one
you provided.

> This might either be a regression in libsdl2, or an unintended interaction
> with the new libsdl2 exposing a bug in doomsday; at this stage it's hard
> to tell which.

I think it's really both, so I'm cloning the bug.

If you don't have a joystick or gamepad attached, Doomsday relies on being
able to call SDL_JoystickName(nullptr).

On one hand, this is fairly clearly a programming error, because
SDL_JoystickName() is documented to take a pointer to a SDL_Joystick as
its parameter, and nullptr isn't a joystick (more like the absence of a
joystick). So doomsday should be doing more like this:

 de::String Joystick_Name()
 {
 #ifndef DENG_NO_SDL
-return SDL_JoystickName(joy);
+return (joy ? SDL_JoystickName(joy) : "");
 #else
 return "";
 #endif
 }

or perhaps:

 de::String Joystick_Name()
 {
 #ifndef DENG_NO_SDL
-return SDL_JoystickName(joy);
+return (joyAvailable ? SDL_JoystickName(joy) : "");
 #else
 return "";
 #endif
 }

Let's use a cloned bug to represent that.

But on the other hand, SDL has historically tolerated NULL parameters to
most of its public API, returning an error code, so the fact that 2.30
no longer does that for this particular function is technically a
regression I suppose. I'll use #1062969 to represent the SDL regression.

smcv



Bug#1065709: doomsday: segfault in _XFlush() when Qt is using native Wayland

2024-03-09 Thread Simon McVittie
Package: doomsday
Version: 2.3.1+ds1-1+b2
Severity: important

In a GNOME Wayland session, with qtwayland5 installed:

$ doomsday
QSocketNotifier: Can only be used with threads started with QThread
[1]381459 segmentation fault (core dumped)  doomsday

Backtrace:

#0  0x7f9dc2c3ee83 in require_socket (dpy=) at 
../../src/xcb_io.c:70
#1  _XFlush (dpy=0x55af92e13230) at ../../src/xcb_io.c:606
#2  0x7f9dc2c41b3d in _XGetRequest (dpy=dpy@entry=0x55af92e13230, 
type=type@entry=98 'b', len=len@entry=8)
at ../../src/XlibInt.c:1787
#3  0x7f9dc2c34a57 in XQueryExtension
(dpy=dpy@entry=0x55af92e13230, name=name@entry=0x7f9dc2bf9128 
 "RANDR", major_opcode=major_opcode@entry=0x7fffc208bde4, 
first_event=first_event@entry=0x7fffc208bde8, 
first_error=first_error@entry=0x7fffc208bdec)
at ../../src/QuExt.c:49
#4  0x7f9dc2c27b16 in XInitExtension
(dpy=dpy@entry=0x55af92e13230, name=name@entry=0x7f9dc2bf9128 
 "RANDR")
at ../../src/InitExt.c:59
#5  0x7f9dc42ecc9b in XextAddDisplay
(extinfo=extinfo@entry=0x7f9dc2bf91b0 , 
dpy=dpy@entry=0x55af92e13230, ext_name=ext_name@entry=0x7f9dc2bf9128 
 "RANDR", hooks=hooks@entry=0x7f9dc2bf9140 
, nevents=nevents@entry=2, data=data@entry=0x0) at 
../../src/extutil.c:110
#6  0x7f9dc2bef860 in XRRFindDisplay (dpy=dpy@entry=0x55af92e13230) at 
../../src/Xrandr.c:295
#7  0x7f9dc2beffc0 in XRRFindDisplay (dpy=0x55af92e13230) at 
../../src/Xrandr.c:361
#8  XRRQueryExtension (dpy=0x55af92e13230, event_base_return=0x7fffc208bee8, 
error_base_return=0x7fffc208bee8)
at ../../src/Xrandr.c:352
#9  0x7f9dc5223ae4 in de::internal::RRInfo::RRInfo() (this=0x7fffc208bf70)
at ./doomsday/sdk/libgui/src/displaymode_x11.cpp:63
#10 0x7f9dc522302d in DisplayMode_Native_Init() () at 
./doomsday/sdk/libgui/src/displaymode_x11.cpp:188
#11 0x7f9dc51b7d11 in DisplayMode_Init() () at 
./doomsday/sdk/libgui/src/displaymode.cpp:195
#12 0x55af91335b1d in ClientApp::initialize() (this=0x7fffc208c160)
at ./doomsday/apps/client/src/clientapp.cpp:628
#13 0x55af9131875d in main(int, char**) (argc=, 
argv=0x7fffc208c388)
at ./doomsday/apps/client/src/main_client.cpp:109

It looks as though doomsday is mixing Qt, SDL and direct use of X11.
If it's going to do this, then it should either force both Qt and SDL to
use X11 too, or allow one of the GUI libraries to auto-select a backend
and force the other one to follow that decision, then conditionalize
its direct use of X11 so it's only done if the GUI library has actually
initialized X11.

Workaround:

$ SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday

gets further into its startup.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-security'), (500, 'oldstable-security'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages doomsday depends on:
ii  doomsday-common 2.3.1+ds1-1+b2
ii  doomsday-data   2.3.1+ds1-1
ii  libc6   2.37-15.1
ii  libgcc-s1   14-20240303-1
ii  libqt5core5t64 [libqt5core5a]   5.15.10+dfsg-7.2
ii  libqt5gui5t64 [libqt5gui5]  5.15.10+dfsg-7.2
ii  libqt5network5t64 [libqt5network5]  5.15.10+dfsg-7.2
ii  libqt5widgets5t64 [libqt5widgets5]  5.15.10+dfsg-7.2
ii  libsdl2-2.0-0   2.30.1+dfsg-1
ii  libsdl2-mixer-2.0-0 2.8.0+dfsg-1
ii  libstdc++6  14-20240303-1

Versions of packages doomsday recommends:
ii  fluid-soundfont-gm  3.1-5.3

doomsday suggests no packages.

-- debconf-show failed



Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

2024-03-07 Thread Simon McVittie
Control: reassign -1 aptitude,libgtk2.0-0t64
Control: tags -1 + moreinfo

On Thu, 07 Mar 2024 at 16:10:17 +0100, Vincent Lefevre wrote:
> During an upgrade with aptitude:
> 
> dpkg: dependency problems prevent removal of libgtk2.0-common:
>  libgtk2.0-bin depends on libgtk2.0-common.
>  libgtk2.0-0t64:amd64 depends on libgtk2.0-common.
> 
> dpkg: error processing package libgtk2.0-common (--purge):
>  dependency problems - not removing
> Errors were encountered while processing:
>  libgtk2.0-common
> 
> Note that "apt install -f" has nothing to fix; this upgrade just
> triggered a dpkg error (similar to bugs 1065603 and 1065625).
> 
> Moreover, like in these bugs, aptitude did not propose the removal
> of libgtk2.0-common:
> 
> Aptitude 0.8.13: log report
> Thu, Mar  7 2024 16:01:36 +0100
> 
>   IMPORTANT: this log only lists intended actions; actions which fail
>   due to dpkg problems may not be completed.
> 
> Will install 5 packages, and remove 2 packages.
> 2048 B of disk space will be used
> 
> [...]
> [HOLD, DEPENDENCIES] libgtk2.0-common:amd64 2.24.33-3
> [...]
> [INSTALL, DEPENDENCIES] libgail18t64:amd64 2.24.33-4
> [INSTALL, DEPENDENCIES] libgtk2.0-0t64:amd64 2.24.33-4
> [REMOVE, DEPENDENCIES] libgail18:amd64 2.24.33-3
> [REMOVE, DEPENDENCIES] libgtk2.0-0:amd64 2.24.33-3
> [...]
> [UPGRADE] gtk2-engines-pixbuf:amd64 2.24.33-3 -> 2.24.33-4
> [UPGRADE] libgail-common:amd64 2.24.33-3 -> 2.24.33-4
> [UPGRADE] libgtk2.0-bin:amd64 2.24.33-3 -> 2.24.33-4
> 

I can confirm that version 2.24.33-4 of libgtk2.0-common, libgtk2.0-0t64
and libgtk2.0-bin are, in fact, installable (I have them installed
right now). I can't see any dependency relationships between them that
look suspicious.

If dpkg is removing libgtk2.0-common, then something must surely be
asking dpkg to remove it?

I notice that you have reported at least three bugs that are "the same
shape" with three unrelated libraries, which suggests that this might
be more of an aptitude problem than a GTK problem.

>   IMPORTANT: this log only lists intended actions

Other logs, in particular /var/log/apt/term.log, might provide more
information about what actually happened.

Alternatively, if there is some heuristic about "try to keep packages
from the same source at the same version" being applied, perhaps waiting
for libgtk2.0-common_2.24.33-4 to become available from the
Architecture: all buildd would help?

smcv



Bug#1065574: libgtk-3-0 and libgtk-3-0t64 are mutually dependent but out of line, many packages are being kept back

2024-03-07 Thread Simon McVittie
On Wed, 06 Mar 2024 at 21:40:10 +0100, Arnaldo Pirrone wrote:
> libgtk-3-0t64 3.24.41-1.1 is breaking libgtk-3-0

This is part of the ongoing 64-bit time_t transition (for details please
see a large proportion of recent traffic on the debian-devel mailing
list). Please be patient: sometimes unstable lives up to its name.

The intended migration path is that libgtk-3-0t64 entirely replaces
libgtk-3-0, and similarly libgail-3-0t64 entirely replaces libgail-3-0.

On x86, each of the ...t64 packages Provides the name without the ...t64
suffix, so it should be possible to replace one with the other while
still satisfying GTK-dependent packages' dependencies, but apt cannot
currently work out how to achieve that automatically in all cases.

> many other packages including task-cinnamon-desktop from
> experimental branch

Experimental does what its name suggests, and is not expected to
be completely installable at all times. I'm sorry if this has been
inconvenient for your workflow, but it's inconvenient for everyone
right now.

smcv



Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-06 Thread Simon McVittie
On Sat, 02 Mar 2024 at 20:19:47 +, Simon McVittie wrote:
> I have proposed a change for glib2.0/experimental at
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
> implements the "delete the old postrm" approach

An equivalent glib2.0 change is now in unstable.

Unfortunately, GTK 2 and 3 both have an equivalent issue for their input
method modules (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065493,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065494 respectively).
I'm proposing to address this in the same way as for glib2.0 with
https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/3 and
https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/22 respectively
(untested, test-builds are in progress). As with glib2.0, I apologise for
not having caught this at nmudiff time.

gdk-pixbuf and GTK 4 probably have a latent version of the same issue,
but have avoided a practical problem during this particular transition by
not having any time_t in their ABIs and therefore not needing a rename,
so they are presumably not immediately urgent to address.

I have not attempted to audit other libraries that have plugins, either
inside or outside the GNOME team, for an equivalent problem.

smcv



Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications

2024-03-04 Thread Simon McVittie
On Mon, 04 Mar 2024 at 20:21:56 +, Markus Koller wrote:
> So it's trying to use the `DND_IN_DRAG` cursor at [1].

That's not a concrete cursor name, it's an alias in libmutter. Depending
on version of libmutter, it could end up referring to either "dnd-none"
(which is no longer provided) or "no-drop" (which still exists) or
perhaps even something else.

> I should also mention I'm using gnome-shell 45.3-2 from
> experimental.

With which version of libmutter-13-0?

Locating some cursors with newer adwaita-icon-theme is known to be
broken with mutter/45.3-2 but should be fixed with mutter/45.3-3, as
far as I know.

If upgrading libmutter-13-0 (and other packages from the same source)
to 45.3-3 fixes this, then you were experiencing #1063640. If not,
we should open a separate bug.

Thanks,
smcv



Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-04 Thread Simon McVittie
Copying context from elsewhere in the thread, Sam Hartman wrote:
> Are there solutions in the space of having glib2.0-0 continue to exist
> as a package depended on by glib2.0-0t64 or depending on the new library
> allowing you to replace the postrm?

to which I replied:

If libglib2.0-0 continues to exist, then packages that expect the affected
entry points to have 32-bit time_t will still have their dependencies
satisfied, but then when they call the affected entry points, they will
crash, because their time_t is not the same size as GLib's. So as far
as I can see, this is functionally equivalent to reverting the rename:
to be correct, it would have to be accompanied by versioned Breaks on
every package that calls into the affected entry points.

On Mon, 04 Mar 2024 at 08:46:52 -0700, Sam Hartman wrote:
> > "Matthew" == Matthew Garrett  writes:
> Matthew> I would like some further
> Matthew> analysis of Sam's proposal, though - I don't think there's
> Matthew> any advantage in undoing the existing solution, but if it
> Matthew> would work then it's maybe a more straightforward solution
> Matthew> for any similar issues in future?
> 
> Unfortunately, I think Simon's response to me is definitive.
> Ultimately if the old package exists, it will continue to satisfy
> dependencies.
> That's exactly what we don't want in the time_t transition.

I think the one thing we could do in this direction would be to mitigate
problems like this one *on architectures unaffected by the transition*
(in this case, 64-bit plus i386) by having this situation:

Package: libglib2.0-0
Architecture: amd64 arm64 i386 s390x (etc.)
Depends: libglib2.0-0t64 (>= ${binary:Version})
Description: empty transitional package

Package: libglib2.0-0t64
Architecture: any
Breaks: libglib2.0-0 (<< ${binary:Version})
Replaces: libglib2.0-0 (<< ${binary:Version})
Description: GLib library

I think this would have made upgrades significantly more smooth on the
non-armel, non-armhf architectures, as well - but perhaps I'm missing an
important reason why the 64-bit time_t transition team have chosen not to
do this (and perhaps it's not even possible).

Nothing we do in this direction would help armel and armhf, so there would
still be a problem here to be solved (and probably we would not have found
out about this particular bug until much, much later, when an armel or
armhf GUI user did the upgrade and encountered the bug).

This is obviously only going to help if "most" architectures are
unaffected by the transition. If our next such transition involves
genuinely breaking ABI on the more widely-used architectures, then I
don't see any way to make it less painful. Perhaps this is a sign that
we should try hard to only have transitions shaped like this one if
there is no alternative.

smcv



Bug#1065393: libphonenumber: phonenumberprotoabi not computed correctly after time64 transition

2024-03-03 Thread Simon McVittie
Source: libphonenumber
Version: 8.12.57+ds-4.1
Severity: important
X-Debbugs-Cc: vor...@debian.org

After the time64 transition, libphonenumber8t64 Provides
libphonenumber8t64-protobuf with no version suffix. This appears to be
caused by the rename of libprotobuf32 to libprotobuf32t64: the regex in

> phonenumberprotoabi := libphonenumber8t64-protobuf$(shell dpkg-query -W -f 
> '$${Depends}' libprotobuf-dev | sed -n 's/.*libprotobuf\([0-9]*\) .*/\1/p')

will not match libprotobuf32t64.

This also has the effect that the compatibility glue that seems to
have been intended to avoid mandatory rebuilds on 64-bit architectures
and i386:

>   phonenumberprotocompatabi := , libphonenumber8-protobuf$(shell dpkg-query 
> -W -f '$${Depends}' libprotobuf-dev | sed -n 's/.*libprotobuf\([0-9]*\) 
> .*/\1/p')

doesn't work as intended, because it generates a virtual package name
libphonenumber8-protobuf and not the required libphonenumber8-protobuf32.

I don't know whether the virtual package should be named
libphonenumber8t64-protobuf32 or libphonenumber8t64-protobuf32t64 (the
latter would probably be easiest), but presumably one of those?

I've reported this as important for now, but maybe it should be RC.

smcv



Bug#1065382: trap int3 ip:7fed77a24587 sp:7ffc8e859b40 error:0 in libglib-2.0.so.0.7800.4[7fed779e0000+99000]

2024-03-03 Thread Simon McVittie
On Sun, 03 Mar 2024 at 17:34:25 +0100, Harald Dunkel wrote:
> I got a few messages in kern.log:
> 
> 2024-03-03T17:10:55.375204+01:00 cecil kernel: traps: at-spi-bus-laun[2238] 
> trap int3 ip:7f52523f5587 sp:7ffded761730 error:0 in 
> libglib-2.0.so.0.7800.4[7f52523b1000+99000]

Please try reinstalling the libglib2.0-0t64 package. If you have multiarch
(e.g. amd64 + i386), reinstall each instance (e.g. libglib2.0-0t64:amd64
+ libglib2.0-0t64:i386).

If that workaround is successful, then this is probably #1065022, for
which a real fix is pending. I am sorry that this bug has taken time
to resolve.

Or, if that workaround is unsuccesful, then this is some other bug,
in which case we will not be able to solve it without more information:
please see .

Thanks,
smcv



Bug#1064369: gobject-introspection dropped versioned dependency on python3

2024-03-03 Thread Simon McVittie
Control: severity -1 important

On Tue, 20 Feb 2024 at 23:15:09 +0100, Matthias Klose wrote:
> On 20.02.24 22:50, Simon McVittie wrote:
> > If gobject-introspection explicitly depended on gobject-introspection-bin
> > by name (not just via a virtual package), would that help?
> 
> I think that would do it

I will upload this change soon. It is not clear to me why it would be
helpful, but it's also unlikely to cause a problem.

If I am wrong about this and it somehow causes a regression, I will
try to revert it immediately, but I am quite burned-out at the moment
and I have responsibilities outside Debian, so I would appreciate it if
someone else in the team could keep an eye on this package.

> > On Tue, 20 Feb 2024 at 22:15:21 +0100, Matthias Klose wrote:
> > > The package had in the past dependencies of the form
> > > 
> > >python3 (<< 3.12), python3 (>= 3.11~), python3:any
> > > 
> > > the new one just
> > > 
> > >python3:any
> > 
> > The parts that require a specific python3 version are now in the
> > gobject-introspection-bin binary package, which correctly depends on:
> > 
> >  python3 (<< 3.12), python3 (>= 3.11~), python3:any
> > 
> > via dh_python and ${python3:Depends}. The gobject-introspection package
> > no longer contains any binary Python extensions.

I've explained why I believe this arrangement is correct, and therefore I
don't think there is a bug to be resolved here (certainly not a RC bug).
I am sorry if I have failed to understand the point you were making.

If you disagree and still consider there to be a serious bug here,
please describe a test scenario where the wrong thing happening can be
reproduced (either dependencies that permit an incorrect situation to
be installed, or package relationships that cause some other component
like britney or autopkgtest to misbehave), the result you would expect
from that test scenario, and the actual result.

Thanks,
smcv



Bug#1065364: low-memory-monitor: consider adding Multi-Arch: foreign

2024-03-03 Thread Simon McVittie
Package: low-memory-monitor
Version: 2.1-2
Severity: minor

low-memory-monitor appears to be an activatable D-Bus service with no
particular C/C++ ABI. If this is the case, then it could be marked
Multi-Arch: foreign (since D-Bus is normally an architecture-independent
protocol if the interface has been designed in a conventional way),
which would allow client libraries or applications to depend on it
without forcing installation of a particular multiarch instance.

I noticed this because libglib2.0-0{,t64} Suggests low-memory-monitor,
and when I upgrade GLib for both amd64 and i386 at the same time, this
results in apt suggesting that I could install low-memory-monitor:i386
even though I already have low-memory-monitor:amd64 installed (which of
course is impossible, they have file conflicts). In GLib's case this is
non-problematic, because Suggests is the weakest form of dependency, but
if some other library (let's say liblowmemory) wanted a hard dependency
on low-memory-monitor, then this would make liblowmemory:amd64 and
liblowmemory:i386 non-co-installable.

(I have not verified that low-memory-monitor's D-Bus interface is genuinely
architecture-independent, but I strongly suspect that it is.)

Thanks,
smcv



Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-02 Thread Simon McVittie
On Sat, 02 Mar 2024 at 20:19:47 +, Simon McVittie wrote:
> I have proposed a change for glib2.0/experimental at
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
> implements the "delete the old postrm" approach.

I've uploaded this to experimental, incorporating feedback from Helmut.
(Thank you for your thorough review!)

Due to the time required to put each version through build/testing,
I am not able to propose a corresponding upload for unstable tonight
(and having this version in experimental for at least a few hours is
probably not a bad plan in any case).

smcv



Bug#1065316: libatspi2.0-dev 2.51.90-1 no longer multi-arch installable due to dependencies

2024-03-02 Thread Simon McVittie
Control: clone -1 -2
Control: reassign -2 gobject-introspection 1.78.1-15
Control: retitle -2 dh_girepository: generates unwanted dependency on 
libgirepository1.0-dev if that package is installed
Control: severity -2 important

On Sun, 03 Mar 2024 at 00:40:52 +0100, Samuel Thibault wrote:
> Christian Klein, le sam. 02 mars 2024 16:33:15 +0100, a ecrit:
> > libatspi2.0-dev is no longer muti-arch installable.
> > It now has a dependency on libgirepository1.0-dev, which isn't multi-arch.
> > 2.50.0-1 didn't have that dependency
> > 
> > Looking at the changelog, I don't see why the additional dependency is
> > necessary.
> 
> This is coming from gir:Depends:
> 
> ./debian/libatspi2.0-dev.substvars:gir:Depends=gir1.2-atspi-2.0 (= 
> 2.51.90-1), gir1.2-dbus-1.0-dev, gir1.2-gobject-2.0-dev, 
> libgirepository1.0-dev
> 
> I don't know the ins and outs why this comes like this, thus asking for
> help on this.

This was an unintended regression caused by changes made in
gobject-introspection, ironically to make multiarch co-installability and
cross-compilation of GObject-Introspection data possible. I am sorry to
have inconvenienced you and will try to fix the bug in dh_girepository
soon. I know that regressions are unacceptable, but this week there have
been several unrelated time-sensitive issues for which I have been made
a single point of failure, so I hope you will forgive me for not putting
this right at the top of my queue.

The bug is that if libgirepository1.0-dev is installed, dh_girepository
will wrongly generate dependencies on that package in preference to
gir1.2-glib-2.0-dev. This is because, for backwards compatibility
with packages that have not yet been updated to look for GIR XML
in a multiarch-friendly location, libgirepository1.0-dev provides a
symbolic link to the architecture-specific GIR XML for GLib-2.0 in a
non-multiarch-friendly location. This backwards compatibility glue is also
the reason why libgirepository1.0-dev cannot be Multi-Arch: same.

Samuel or other AT-SPI maintainers, if you want to avoid this unwanted
dependency while also bringing libatspi2.0-dev one step closer to being
cross-compilable itself, please consider replacing the build-dependency on
libgirepository1.0-dev with the canonicalized package names corresponding
to the GIR modules required by the upstream source, which according to
the build log means this:

diff --git a/debian/control b/debian/control
index 5408552..1dd2830 100644
--- a/debian/control
+++ b/debian/control
@@ -11,8 +11,10 @@ Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
libx11-dev, libxtst-dev,
meson (>= 0.63.0),
pkgconf,
-   libgirepository1.0-dev,
gtk-doc-tools, gi-docgen, python3-sphinx,
+   gir1.2-dbus-1.0-dev,
+   gir1.2-glib-2.0-dev,
+   gir1.2-gobject-2.0-dev,
gobject-introspection | dh-sequence-gir,
xauth ,
xvfb ,

(Compile-tested only, I have not attempted to verify that the resulting
binaries are perfect; at the moment I'm only looking at this while I wait
for an urgent glib2.0 bug fix to finish running automated tests, and I
will have to re-prioritize back to glib2.0 as soon as it is ready. I
apologise for not providing an exhaustively-tested, production-ready
solution right now.)

smcv



Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-02 Thread Simon McVittie
On Sat, 02 Mar 2024 at 20:19:50 +, Simon McVittie wrote:
> I am currently downloading all versions of libglib2.0-0 that have
> existed on amd64 as tracked by snapshot.d.o. My plan is to extract their
> DEBIAN/postrm, import them into a git branch and go back through the
> history that way.

https://salsa.debian.org/smcv/glib2.0-control-files has the full history.
`git log -p postrm` confirms that the only things the postrm has ever
done in versions known to snapshot.d.o are:

- deleting gschemas.compiled, which is what we want to avoid here;
- deleting giomodule.cache, which is what we want to avoid here;
- running ldconfig, which is handled by triggers now

So I think removing the postrm is viable.

smcv



Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-02 Thread Simon McVittie
I have proposed a change for glib2.0/experimental at
https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
implements the "delete the old postrm" approach. I would appreciate
review and comments on whether this is something that would be acceptable
to upload to experimental, and/or to cherry-pick to the debian/trixie
branch that is currently being used for unstable uploads.

I believe it is ready for review, and it includes semi-automated
tests for #1065022, which do pass for a test-build; but at the time of
writing I am waiting for the systematic testing that is appropriate for
a production-quality upload, because it takes a long time (around 1 to
2 hours of sbuild, autopkgtest and piuparts in the case of glib2.0). I
hope that I am not wasting reviewers' time by asking for review of
only-partially-tested changes.

As well as the "delete the old postrm" part, the proposed change also
includes an attempt to prevent this situation from happening again, by
changing the postrm logic so the cleanup is not done if a future package
like libglib2.0-0xyz takes over /usr/lib/*/glib-2.0.

Because my upload pipeline is time-consuming and I only get a finite
number of attempts in a day, I would prefer it if reviewers could make
it clear whether any deficiencies are considered to be experimental
upload blockers, unstable upload blockers, or merely nice-to-have. If
only nice-to-have changes are requested, then I will not necessarily
restart the release process for them.

If I do not receive any positive or negative feedback by the time the
build finishes, I will probably upload it to DELAYED in an attempt to take
myself off the critical path, and I might also prepare a DELAYED upload
for unstable. This is an attempt to balance the two competing factors
that result in there being no acceptable thing to do in this situation:
because this is a critical bug that will eventually become critical-path
for a project-wide transition, the expectation is that I must upload a
fix as soon as possible, but because maintainer scripts run as root on
hundreds of thousands of systems, the expectation is that I must not
upload without sufficient testing. So, my intention is to do my best,
and then invite other developers to take responsibility for a better,
higher-version-numbered upload with different timing if they prefer.

On Fri, 01 Mar 2024 at 17:44:57 +, Simon McVittie wrote:
> Perhaps giomodules.cache should *also* only be removed
> during purge, but fixing that has never been anyone's highest priority.

That is also implemented in
https://salsa.debian.org/gnome-team/glib/-/merge_requests/32.

> On Fri, 01 Mar 2024 at 15:58:10 +0100, Helmut Grohne wrote:
> > I'm not sure anyone of us wants to look into multiple old
> > libglib2.0-0.postrm scripts
> 
> If my choice is between spending O(hours) on reading old postrm scripts
> or O(days) on NMUing GLib-dependent packages, then I'd prefer to read
> the postrm scripts. I can't say that either is something I would look
> forward to, but if it's what the project requires from me then it will
> have to happen.

I am currently downloading all versions of libglib2.0-0 that have
existed on amd64 as tracked by snapshot.d.o. My plan is to extract their
DEBIAN/postrm, import them into a git branch and go back through the
history that way. I am doing this in parallel with building a release
candidate for experimental rather than doing this analysis first, because
as stated above my release pipeline is very long, and I am optimistically
assuming that the code added by debhelper when it replaces the #DEBHELPER#
token will not be functionally significant. If that assumption is wrong
then I will presumably need to to start again and rethink my approach.

smcv



Bug#1065280: glib2.0: missing dpkg-dev (>= 1.22.5) build dependency for time_t transition

2024-03-02 Thread Simon McVittie
Control: tags -1 + pending

On Sat, 02 Mar 2024 at 11:51:26 +0100, Sebastian Ramacher wrote:
> Please add dpkg-dev (>= 1.22.5) to Build-Depends

This is already fixed in git, but we were told not to upload that version
yet, to avoid interfering with the migration of the NMU currently
in unstable (which, at the time, was believed to be sufficient and
desirable). It is also already fixed in experimental (2.79.3-1).

> and upload the new version ASAP

glib2.0 already has a Severity: critical bug related to this transition
(#1065022) which I am attempting to resolve with a minimum of collateral
damage (#1065170). I apologise for not having been able to resolve this
instantaneously; maintaining GLib in Debian is not my only responsibility.

If it is critically urgent that it must be uploaded to fix the missing
dpkg-dev dependency as soon as possible, someone is welcome to upload
what's in gnome-team git, but it takes me 2 hours per attempt to carry
out the minimal level of testing on GLib that I understand the project
to require from me (build, autopkgtest, piuparts), so it seems like it
might be better to combine the upload for this with the upload to fix
#1065022 when that change is ready.

smcv



Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-01 Thread Simon McVittie
On Fri, 01 Mar 2024 at 13:21:51 +0100, Christoph Berg wrote:
> > Possible solution: other ideas?
> 
> Make glib2.0-t64 use a different cache filename?

I'm not happy about the idea of introducing long-term divergence in
the upstream code as a result of a Debian-specific packaging problem;
I think we should be going in the direction of fewer, not more,
"weird Debianisms" that break reasonable upstream assumptions.

If there was a finite time window after which we could revert this, that
would be less bad, but as far as I can see it would be possible to keep
libglib2.0-0 installed for multiple release cycles and then purge it, and
it would have just as much impact whenever it happens to get purged.

On Fri, 01 Mar 2024 at 15:58:10 +0100, Helmut Grohne wrote:
> For this one (but not gschemas.compiled), I am wondering whether
> installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright
> might work. That is a file that is going away and therefore, removal of
> libglib2.0-0 should cause libglib2.0-0t64.postinst to be invoked with a
> triggered argument after libglib2.0-0.postrm having done the damage.
> 
> Do you agree that this would solve giomodule.cache but not
> gschemas.compiled?

Probably? Sorry, I don't have a sufficiently in-depth understanding of
the finer points of triggers to know whether it is guaranteed that the
trigger would go off after libglib2.0-0.postrm has already run.

(Also, as said elsewhere, sysadmins are allowed to remove/exclude
/usr/share/doc, so I wouldn't want to make that load-bearing.)

> Of course, not solving the other one makes this somewhat theoretical.

Right; the schemas problem is the more serious one anyway. So I don't
think it's necessarily worth spending time on bringing my understanding
of triggers up to a point where I would be able to answer your previous
question.

> > - for gschemas.compiled (shared by all architectures), if the multiarch
> >   refcount of the library reaches 0, then the file is deleted during the
> >   next postrm purge
> 
> Do you happen to remember why gschemas.compiled is being removed in
> purge rather than remove?

I don't remember, as such (it was before my involvement) but thankfully
we have version control to answer questions like this for us. According
to the git history, it was originally removed in remove, but that caused
breakage during upgrades (which run the old postrm and then, eventually,
the new postinst): there was a window of time in which the file did
not exist.

For GIO modules, having a window of breakage is not great but not a
disaster, because "most" GLib programs are at least partially functional
without them. Perhaps giomodules.cache should *also* only be removed
during purge, but fixing that has never been anyone's highest priority.

For GSettings schemas, missing schemas are usually treated as a
programming error (assertion failure and hard crash) which caused more
extensive brokenness:

debian/libglib2.0-0.postrm.in: Only remove the compiled schemas on purge,
not during upgrades. Otherwise we have no schemas available until the new
postinst is run, which leads to applications aborting on missing schemas.
— c8b28bc30b4a5ca7ec7bf643ebaeae88bf21c588, 2012-03-30

> > libglib2.0-0t64 could gain a preinst that deletes
> > /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm
> 
> Consider a variant of this. We don't really know how old libglib2.0-0
> is

The postrm was introduced in 2010 and hasn't changed a whole lot (14
commits between the beginning of time and current experimental, according
to git log -p --follow debian/libglib2.0-0t64.postrm in the experimental
packaging).

> and I'm not sure anyone of us wants to look into multiple old
> libglib2.0-0.postrm scripts

We don't support skipping an upgrade, so probably only the one in bookworm
(and Ubuntu 22.04 I suppose) is relevant here?

If my choice is between spending O(hours) on reading old postrm scripts
or O(days) on NMUing GLib-dependent packages, then I'd prefer to read
the postrm scripts. I can't say that either is something I would look
forward to, but if it's what the project requires from me then it will
have to happen.

> Both of my thoughts leave a window of time where users of these caches
> will fail.

Yes, and in the case of GSettings schemas that does seem particularly
high-impact.

> > Possible solution: revert t64 rename for glib2.0
> 
> Do you see this as a realistic solution for trixie?

Which is "this"?

If you mean reverting the rename and adding Breaks, then yes, it's a
simple matter of doing an extensive amount of of routine work (rename
back, no-changes-NMU all packages that mention those symbols if necessary
so that they will have a higher version number, and add versioned Breaks).
I can't say that I'm looking forward to that work, particularly if the
project expects me to do all of it personally, but it's routine.
I don't know how it would fit into Ubuntu's schedules and deadlines, but
if the alternative is "most 

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

2024-03-01 Thread Simon McVittie
Package: tech-ctte
Severity: normal
X-Debbugs-Cc: debian-d...@lists.debian.org, debian-gtk-gn...@lists.debian.org, 
vor...@debian.org

I'm requesting advice from the tech-ctte (or anyone else with relevant
knowledge, e.g. the dpkg team or the drivers of the time64 transition)
on how to resolve glib2.0 bug #1065022. This is time-sensitive,
because it is a RC bug (temporarily breaking many applications across
this transition) and will hold up the time64 transition.

Background
==

glib2.0 has two similar patterns where files that are managed by dpkg
are summarized in a non-dpkg-managed file, maintained by triggers and the
library postinst/postrm.

The first of these patterns is GSettings schemas. There is a tool that
loads GSettings schemas in XML format from /usr/share/glib-2.0/schemas
and aggregates them into a single binary blob in a more efficient format,
/usr/share/glib-2.0/schemas/gschemas.compiled. For performance reasons,
applications only load gschemas.compiled: there is no support for loading
the more authorable but less efficient XML files directly.

The second of these patterns is GIO modules, a plugin architecture which
loads .so files from /usr/lib/${DEB_HOST_MULTIARCH}/gio/modules
and summarizes their functionality
in /usr/lib/${DEB_HOST_MULTIARCH}/gio/modules/giomodule.cache.
Applications that want to load plugins parse giomodule.cache, and only
dlopen the plugins that provide the desired functionality (for example
an application that doesn't do any networking will not load plugins that
only implement gio-proxy-resolver).

This is implemented with dpkg file-based triggers: when a package adds
or removes GSettings schemas or GIO modules, it triggers processing by
the libglib2.0-0{,t64} postinst. The implementation has been approximately
the same shape for 10 years, and has worked well until now.

Because dpkg doesn't have an equivalent of RPM %ghost files, the two
generated summary files need to be deleted by the library's postrm.
As of bookworm (and still true in trixie), the implementation is:

- for giomodule.cache (per-architecture), the file is simply deleted by
  postrm remove

- for gschemas.compiled (shared by all architectures), if the multiarch
  refcount of the library reaches 0, then the file is deleted during the
  next postrm purge

The bug
===

When we transition from libglib2.0-0 to libglib2.0-0t64, this involves
the removal of libglib2.0-0. In the postrm of libglib2.0-0, removing
libglib2.0-0:amd64 deletes
/usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache, and so on for
all the other architectures.

The result is that until the postinst of libglib2.0-0t64:amd64 is run,
amd64 applications will be unable to load GIO plugins, causing
functionality loss (for example, inability to use https, because the
TLS plugin is not loaded).

Similarly, either during or after the transition from libglib2.0-0
to libglib2.0-0t64, users will want to purge libglib2.0-0. In
the postrm of libglib2.0-0, if there are no multiarch
instances of libglib2.0-0 remaining, purging the package deletes
/usr/share/glib-2.0/schemas/gschemas.compiled. The result is that
applications that want to load GSettings schemas will not find their
required schemas, which is normally treated as a programming error
(incorrect installation) that causes a crash with an assertion failure.

The workaround is: after removal or purging of libglib2.0-0, reinstall
either libglib2.0-0t64 or any package that will trigger libglib2.0-0t64.
On multiarch systems, this must be done for the architecture that matches
the instance of libglib2.0-0 that was removed.

During upgrade, I am unsure what ordering guarantees we have about
the postrm of libglib2.0-0 running before or after the postinst of
libglib2.0-0t64 - perhaps we avoid the giomodule.cache bug in practice,
because the postrm runs before the postinst? But purge can happen at any
later time, so we certainly cannot guarantee that libglib2.0-0t64.postinst
will run after purging libglib2.0-0.

I apologise for not having foreseen this.

Non-solutions
=

I am not interested in solutions that would require a use of a time
machine to change the postrm that was shipped in bookworm: bookworm was
already released, and now we are stuck with it. *After* the time-sensitive
part of this issue has been solved, I plan to look into making the postrm
robust against future transitions similar to this one by adding some way
for the new package to take over responsibility for giomodule.cache and
gschemas.compiled, but for this particular transition it's too late: the
first time at which we could rely on that functionality is trixie -> forky.

I am also not interested in solutions that require design changes in GLib,
for example adding a fallback slow-path that ignores the absence of the
summary files and loads the individual GSettings schemas and GIO modules
directly. This is because upstream would not accept such a change, and it
would introduce significant delta into 

Bug#1065022: libglib2.0-0t64: transition from libglib2.0-0 breaks GSettings, GIO modules

2024-02-29 Thread Simon McVittie
On Thu, 29 Feb 2024 at 14:00:02 +0100, Christoph Anton Mitterer wrote:
> So the advise for "end users" is to simply re-install one package of
> both groups and everything should be cleaned up again?

The advice for "end users" would be don't run unstable or experimental,
and wait for maintainers to fix release-critical bugs like this one as
they are detected. Unfortunately I have several other time-sensitive
responsibilities and cannot drop everything to investigate how to solve
this immediately. I'm sorry if this means I am not living up to your
expectations.

For advanced users who want to run unstable, yes, the advice would
be to reinstall one package from each of those groups. Or now that I
think about it, reinstalling libglib2.0-0t64 would probably also work,
and is simpler.

> I see. But isn't one more or less supposed to purge?

I'm not saying that purging old packages is necessarily wrong, I'm only
saying that it is the step that triggered this bug. In an ideal world,
all packages would be perfect and there would be no code path that would
cause problems, but sadly we do not live in that world.

> > Removing libglib2.0-0 will also remove the GIO modules cache
> 
> Would that (cache) be re-created by reinstalling?

Installing and then reinstalling libglib2.0-0t64 should recreate this
cache, yes.

If you have multiarch versions of libglib2.0-0t64 installed
(typically libglib2.0-0t64:amd64 and libglib2.0-0t64:i386) then you
will need to reinstall each of them.

smcv



Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

2024-02-29 Thread Simon McVittie
On Thu, 29 Feb 2024 at 08:40:28 -0300, Leandro Cunha wrote:
> Jeremy uploaded glib 2.0 to experimental which fixes such problems

libglib2.0-0t64 in experimental does not contain any changes that would
intentionally fix this.

Upgrading to the experimental libglib2.0-0t64 probably fixes this as a
side-effect, but if it does, then reinstalling the unstable libglib2.0-0t64
would have the same effect as upgrading to experimental.

smcv



Bug#1065022: libglib2.0-0t64: transition from libglib2.0-0 breaks GSettings, GIO modules

2024-02-29 Thread Simon McVittie
On Thu, 29 Feb 2024 at 10:33:17 +, Simon McVittie wrote:
> Yes, the workaround for this is to reinstall any package that carries
> GSettings schemas. gsettings-desktop-schemas is a common one, but actually
> any package that has files in /usr/share/glib-2.0/schemas/ should be
> equally good here.

To clarify that, I mean "reinstall any single package in this category"
and not "reinstall every package in this category". Because of the way
this is set up, one is enough.

> There is a related failure mode with a less dramatic impact that
> can be worked around by reinstalling either dconf-gsettings-backend,
> glib-networking or gvfs after the upgrade.

Similarly, reinstalling any one of these packages per architecture
should be enough, you don't have to reinstall all of them.

smcv



Bug#1065022: libglib2.0-0t64: transition from libglib2.0-0 breaks GSettings, GIO modules

2024-02-29 Thread Simon McVittie
Control: retitle -1 libglib2.0-0t64: transition from libglib2.0-0 breaks 
GSettings, GIO modules

Ash Joubert wrote:
> Workaround for me was to reinstall gsettings-desktop-schemas:
>
> # apt-get reinstall gsettings-desktop-schemas

Yes, the workaround for this is to reinstall any package that carries
GSettings schemas. gsettings-desktop-schemas is a common one, but actually
any package that has files in /usr/share/glib-2.0/schemas/ should be
equally good here.

There is a related failure mode with a less dramatic impact that
can be worked around by reinstalling either dconf-gsettings-backend,
glib-networking or gvfs after the upgrade.

On Thu, 29 Feb 2024 at 05:31:17 +0100, Christoph Anton Mitterer wrote:
> Attached is the aptitude log.

Please also check the apt logs, particularly /var/log/apt/term.log,
which will tell us what actually happened (not just what aptitude
planned to do, which is what the aptitude logs show). What I'm mainly
interested in in is the order of these events relative to each other,
during the upgrade transaction that added libglib2.0-0t64:

- De-configuring libglib2.0-0 (it's OK if this is not present)
- Preparing to unpack libglib2.0-0t64
- Processing triggers for libglib2.0-0t64
- Purging configuration files for libglib2.0-0
- Removing libglib2.0-0
- Setting up libglib2.0-0t64
- Unpacking libglib2.0-0t64

Ash, the same information from you would be useful.

> [INSTALL, DEPENDENCIES] libglib2.0-0t64:amd64 2.78.4-2
...
> [REMOVE (PURGE)] libglib2.0-0:amd64 2.78.4-1

I think what has happened here is that because you are *purging* (and not
just removing) the old libglib2.0-0, this code in the postrm is triggered:

if [ "$1" = purge ] && [ -d /usr/share/glib-2.0/schemas ] && [ 
"$DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT" = 1 ]; then
# This is the last multiarch variant to be removed, so drop the
# architecture-independent compiled schemas
rm -f /usr/share/glib-2.0/schemas/gschemas.compiled
rmdir -p --ignore-fail-on-non-empty /usr/share/glib-2.0/schemas
fi

... and then you have no GSettings schemas available any more, so anything
that uses GSettings will crash.

And then when you reverted the transition, you did the same thing in
reverse:

> [INSTALL, DEPENDENCIES] libglib2.0-0:amd64 2.78.4-1
...
> [REMOVE (PURGE)] libglib2.0-0t64:amd64 2.78.4-2

which would have the same problem.

Removing libglib2.0-0 will also remove the GIO modules cache, even though
it is (now) still being used by libglib2.0-0t64. That has a less dramatic
impact, but will break glib-networking and gvfs, which would explain some
bug reports we've seen recently where certificate validation in GLib apps
stops working with a message about there being no trusted CAs. Unlike
the code path for schemas, this *does* get triggered when libglib2.0-0
is removed-but-not-purged.

This is code that has existed for over a decade, written with the
assumption that the only time GLib would break ABI is if there was an
upstream transition to libglib3.0 with completely parallel-installable
paths. In the absence of a time machine, we can't go back and change it.

Unfortunately at the moment I'm not seeing a way to fix this without
a time machine: we can't go back and change the postrm of libglib2.0-0
in bookworm to have different behaviour. The only reliable solution I
can immediately see would be for libglib2.0-0t64 to delete the postrm
of libglib2.0-0 during its preinst (which is a Policy violation, and
relies on the filesystem layout of dpkg internals). Steve, are you aware
of any better options?

For future versions of glib2.0, I can see a few ways this could be made
more robust against in-place ABI transitions - but we can't retroactively
make any of those changes in bookworm, because bookworm was already
released, so I think we should defer discussion of those until after
the immediate problem has been solved.

smcv



Bug#1064369: gobject-introspection dropped versioned dependency on python3

2024-02-27 Thread Simon McVittie
On Tue, 27 Feb 2024 at 23:07:33 +0100, Matthias Klose wrote:
> On 23.02.24 22:10, Jeremy Bícha wrote:
> > Since glib and gobject-introspection have migrated out of
> > noble-proposed, is there still a need to keep this bug open?
> 
> Suppose you would start again building glib2.0 (and depending packages) for
> all supported Python versions, would that work with the current
> gobject-introspection?

I'm not sure I understand the question. When you say "start again" do
you mean bootstrapping (starting from the beginning), or do you mean
"resume doing something that we did in the past but we now don't"?

If you mean bootstrapping, there is a chain of builds that I believe would
work: build glib2.0 with -Pnogir, use it to build gobject-introspection,
and use that to rebuild glib2.0 with no special profiles.

If you mean "resume doing what we did in the past", I think that
question is based on a false assumption. You might be imagining that
gobject-introspection provides a public Python library, like python3-gi or
python3-dbus, which should be available for every supported Python version
in parallel, but that isn't the case: its role in the Python ecosystem is
more like borgbackup or vim, so it's correct for gobject-introspection-bin
to have a dependency on: python3 (>= current), python3 (<< next).

As far as I know, glib2.0 has never done a build pass or byte-compilation
for each supported Python version in parallel. Its only Python parts
are in libglib2.0-dev-bin (gdbus-codegen and other CLI tools) and
libglib2.0-dev (gdb extensions), both of which are only relevant to
the default Python version, and it has no Python extensions written in
C, only "pure Python" code. The only interface to any of this is by
running tools in /usr/bin, and the fact that they happen to be written in
Python is an implementation detail. It doesn't need any manual action
to be taken when a new Python version is introduced, unless there are
incompatibilities. Ideally the private modules used by gdbus-codegen get
byte-compiled when the default Python version changes, but that's done
automatically, and there would be no particularly significant impact if
it didn't happen.

As far as I know, gobject-introspection has also never been built once
per supported Python version, only for the default Python version. Its
Python part is a private library shared between several of its CLI tools,
and again, the only public interface is via running tools in /usr/bin.
Unlike glib2.0, the private library includes a C extension, so it does
need to be binNMU'd when the default Python version changes.

python3-gi from src:pygobject (a Python library that uses libgirepository)
*is* built for all supported Python versions, and it does provide a
public API to Python callers; but it can do that regardless of what
Python version happens to be used internally by gobject-introspection's
CLI tools. Is that perhaps the library you were thinking of?

If I understand correctly, the usual progression for adding a new Python
version goes like this:

1. Start with only python3.11 supported and default
2. Add python3.12 as supported but non-default
3. binNMU python3-gi and similar packages so they support both 3.11 and 3.12
4. Make python3.12 the default, with python3.11 still supported
5. binNMU gobject-introspection and similar packages for the new default
6. Drop support for python3.11
7. binNMU python3-gi and similar packages so they only support 3.12

python3-gi is involved in steps 3 and 7 (the same as e.g. python3-dbus),
but gobject-introspection is only involved in step 5 (the same as e.g. vim).

Does that answer your question?

smcv



Bug#1064889: libproxy: should have transitional packages for the plugins

2024-02-27 Thread Simon McVittie
(Sorry, I thought I had sent this earlier.)

On Tue, 27 Feb 2024 at 08:39:05 -0500, Jeremy Bícha wrote:
> On Tue, Feb 27, 2024 at 5:33 AM Simon McVittie  wrote:
> > If that's the case, then we should have transitional packages with those
> > names that just depend on libproxy1v5 (>= 0.5.3). This serves two purposes:
> 
> What do you think about adding versioned Breaks/Replaces/Provides
> instead? That seemed to work when Ubuntu dropped
> adwaita-icon-theme-full this month.

That sometimes works, but sometimes doesn't: it relies on apt being
able to find a solution that its heuristics see as acceptable. In my
experience, having real transitional packages has always worked, so it's
a more robust route.

The upgrade to Debian 13 and Ubuntu 24.04 is going to include a lot of
Conflicts/Replaces as a result of the 64-bit time_t transition, so I think
anything we can do to reduce the number of packages being removed in the
upgrade path is likely to be helpful.

smcv



Bug#1064889: libproxy: should have transitional packages for the plugins

2024-02-27 Thread Simon McVittie
Source: libproxy
Version: 0.5.4-1
Severity: serious
Justification: breaks debian-edu-config dependencies

It looks as though the new libproxy1v5 has absorbed all of the
functionality of the older libproxy plugins:

- libproxy1-plugin-gsettings replaced by config-gnome internal to the library
- -kconfig replaced by config-kde
- -networkmanager functionally replaced by a GNetworkMonitor
- -webkit functionally replaced by pacrunner-duktape

If that's the case, then we should have transitional packages with those
names that just depend on libproxy1v5 (>= 0.5.3). This serves two purposes:

- avoid breaking metapackages that explicitly depend on a plugin:
  debian-edu-config (now fails its autopkgtest,
  ),
  gnome, gnome-core and phosh-full;

- minimize the number of packages that are forced to be removed when
  upgrading from bookworm to trixie or Ubuntu jammy to noble, to help apt
  to find a solution

The transitional packages can/should be removed after Debian 13 'trixie' and
Ubuntu 24.04 'noble' are released.

Running a command like this on the developer-accessible archive mirror,
coccia.debian.org, is a useful way to assess the impact *before* removing
packages:

dak rm -R -n -b \
libproxy1-plugin-gsettings \
libproxy1-plugin-kconfig \
libproxy1-plugin-webkit \
libproxy1-plugin-networkmanager

Thanks,
smcv



Bug#1060838: meson: should use the host gobject-introspection-1.0.pc for looking up g-ir-scanner

2024-02-26 Thread Simon McVittie
On Sun, 25 Feb 2024 at 03:21:23 +0200, Jussi Pakkanen wrote:
> Meson comes with a tool that converts native and cross environments
> into cross files. It is run with `meson env2mfile`. It even has a mode
> to generate Debian package building scripts. Updating that to handle
> this case would probably be the smartest thing to do.

I did consider that, but if I'm understanding what you propose
correctly, that would involve going through these steps for every
possible cross-tool:

* inventing a new environment variable similar to CC and PKG_CONFIG, for
  example perhaps G_IR_SCANNER in this case
* making debhelper (or dpkg) add it to the environment
* making `meson env2mfile` (or the older debcrossgen) read it from the
  environment and add it to the generated cross-file

and that seems like something that would scale poorly with the number
of cross-tools that exist? We would have to coordinate changes between
debhelper and meson every time a new cross-tool was identified.

Or do you mean that `meson env2mfile` would have a long list of pkg-config
queries that it would do using ${PKG_CONFIG} in order to populate the
cross-file, like for example in this case, if gobject-introspection-1.0.pc
was found, it would output the equivalent of the shell-like pseudocode
"g-ir-scanner = '$(${PKG_CONFIG} --variable=g_ir_scanner 
gobject-introspection-1.0)'"
and so on? That would avoid needing to invent new environment variables
and modify debhelper, but it would still make updating `meson env2mfile`
into a single point of failure for the ability to use any cross-tool.

I see two possible routes that would scale better.

One is what Helmut suggested: if running a cross-tool might make sense,
ask the host pkg-config rather than the build pkg-config for the path to
that tool, and rely on the packaging having been set up to make that work
(as I already did for gobject-introspection). For the finite number of
tools discovered internally by meson (like g-ir-scanner in the gnome
module) this would still need to be a meson change, but for tools run
by third-party packages as a custom_target or similar, it would be up
to the third-party package to do this (although Meson could perhaps
encourage it in documentation).

The other is to do something with the common convention of an
architecture prefix. In Autotools-world, there's a convention that
if running a cross-tool might make sense, then the configure script
looks for ${host_tuple}-${tool} before ${tool}, where ${tool} is
something like pkg-config or g-ir-scanner, and ${host_tuple} is the
host architecture given to the configure script (in Debian this
is ${DEB_HOST_GNU_TYPE}). Similarly, when using plain Makefiles,
it's relatively common to ask for ${CROSS_COMPILE}${tool}, where
${CROSS_COMPILE} is normally empty, but can be set to the host tuple
followed by "-" when cross-compiling. Either of these will successfully
find our /usr/bin/x86_64-linux-gnu-g-ir-scanner and so on.

smcv



Bug#1064704: gtk4: FTBFS: one run of gtk:tools / validate test failed

2024-02-26 Thread Simon McVittie
Control: tags -1 + confirmed

Context for Mesa maintainers: gtk4 passed its build-time tests on
2024-01-29, but is now failing in a test rebuild. I can reproduce this,
and I think it's a regression triggered by Mesa changes (see also
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10293 upstream).

On Sun, 25 Feb 2024 at 20:37:28 +0100, Lucas Nussbaum wrote:
> > 1332/1515 gtk:tools / validate  
> > FAIL
> > 2.07s   0/9 subtests passed
> > >>> GDK_BACKEND=x11 G_ENABLE_DIAGNOSTIC=0 
> > >>> GTK_QUERY_SETTINGS=/<>/debian/build/deb/tools/gtk4-query-settings
> > >>>  MALLOC_PERTURB_=208 
> > >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> > >>> GTK_A11Y=test GDK_DEBUG=default-settings GTK_CSD=1 
> > >>> GTK_BUILDER_TOOL=/<>/debian/build/deb/tools/gtk4-builder-tool
> > >>>  GSETTINGS_SCHEMA_DIR=/<>/debian/build/deb/gtk 
> > >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
> > >>>  
> > >>> TEST_RESULT_DIR=/<>/debian/build/deb/testsuite/tools/output
> > >>>  GSETTINGS_BACKEND=memory 
> > >>> G_TEST_BUILDDIR=/<>/debian/build/deb/testsuite/tools 
> > >>> G_TEST_SRCDIR=/<>/testsuite/tools TEST_OUTPUT_SUBDIR=x11 
> > >>> /usr/bin/bash validate

Unfortunately, the only log output for this was:

1..9
not ok 1 invalid1
not ok 2 invalid2
not ok 3 invalid3
not ok 4 invalid4
not ok 5 invalid5
not ok 6 valid1
not ok 7 valid2
not ok 8 valid3
not ok 9 valid4

I notice that many tests have this stderr output:

> MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
> libEGL warning: egl: failed to create dri2 screen
> MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
> glx: failed to create drisw screen
> failed to load driver: zink

Looking at the implementation of the testsuite/tools/validate test,
the way it works is: run GTK's validator against a valid or invalid
input, compare the resulting stderr with what was expected, and fail if
they differ. I think the reason why it's failing is that it's seeing this
extra stderr from Zink.

Obviously, this is quite fragile, because anything that emits a diagnostic
message can break it; but I also don't see any way for GTK upstream to get
the behaviour they want ("assert that the validator produces the messages
that we think it should") without that fragility.

Could this output to stderr in Zink perhaps be reconsidered upstream?

smcv



Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

2024-02-26 Thread Simon McVittie
On Mon, 26 Feb 2024 at 08:25:37 +, Gayathri Berli wrote:
> We are having a Debian unstable environment(sid) on s390x.. We think, it's
> better to reproduce the issue with git cloned repo instead of using “sbuild”
> method, so that we can get the commit history and see the code changes.

I see. In that case, you will still need to install the build-dependencies
of GTK 4 (or more generally, whatever package you're testing), and you will
need to either follow whatever steps Debian uses to run the tests, or make
your own build steps and workarounds that have similar behaviour.

> Can you please provide the exact steps to reproduce the bug?

If the bug you are referring to is #1057782, I didn't reproduce it myself
at first: our official autobuilders reproduced it, which they did by
building the package using sbuild.

When I reproduced it on the s390x porterbox 'zelenka', I followed steps
similar to these, which are the same for all Debian packages:

- create a new s390x unstable chroot
- install gtk4's build dependencies into it
- unpack gtk4 source and cd into it
- dpkg-buildpackage -us -uc -rfakeroot -B

> We cloned the gtk repo and built it with the following meson commands.. But 
> we 
> see that almost all of the tests are failing.

If you have chosen to build from upstream source, then you're welcome to do
so, but the way that Debian packages are always built is to use
dpkg-buildpackage, and depending on the package, that might need to do
Debian-specific things as a result of the package's upstream design choices.
Those Debian-specific things should always be a good starting point for how
you can do a build from upstream source.

The debhelper tools log what they do, so if you look at the output from a
Debian build, you will see the exact commands that were used. For example,
in 
https://buildd.debian.org/status/fetch.php?pkg=gtk4=s390x=4.12.4%2Bds-1=1701103591=0
you will find this command:

cd debian/build/deb && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 
meson setup ../../.. --wrap-mode=nodownload --buildtype=plain --prefix=/usr 
--sysconfdir=/etc --localstatedir=/var --libdir=lib/s390x-linux-gnu 
-Dpython.bytecompile=-1 -Dauto_features=enabled -Dbroadway-backend=true 
-Dx11-backend=true -Dcolord=enabled -Dman-pages=true -Dsysprof=enabled 
-Dwayland-backend=true -Ddocumentation=false -Dbuild-examples=true -Ddemos=true 
-Dinstall-tests=true -Dmedia-ffmpeg=disabled -Dcloudproviders=enabled

... which codifies exactly how Debian did the "meson setup" step for
that particular version of GTK. (In this case we're building in
debian/build/deb instead of _build, and we're setting a lot of options.)

Later in the log, you'll see the commands that were run instead of
"meson compile" and "meson test".

On Mon, 26 Feb 2024 at 11:01:07 +0100, John Paul Adrian Glaubitz wrote:
> Looking at the debian/rules of the gtk4 package, there is a dedicated
> script in the package that the Debian package uses to run the tests:
> 
> > https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/run-tests.sh?ref_type=heads
> 
> It's reference from here:
> 
> > https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/rules?ref_type=heads#L288

Yes, this.

This is partly because upstream expects that the test suite will be
invoked when you are already in a working X11 or Wayland environment,
but autobuilders and similar non-interactive or text-based systems
generally do not have that, so you have to run the tests under a mock
X11 environment (with xvfb-run) or under a mock Wayland environment
(we use weston --backend=headless-backend.so for this). In the Debian
packaging, this is encapsulated in debian/tests/run-with-display.

This is also partly because GTK can be either an X11 client or a Wayland
client. In Debian, we want to know that both of those work, so we run
the whole test suite twice: once under X11, and once under Wayland.

The debian/run-tests.sh script also skips some tests or adjusts the
thresholds used to to work around various issues:

- Some tests have slightly different rendering on i386 and other
  architectures with non-IEEE floating point. Upstream doesn't consider
  this to be a problem because they don't actively support non-x86_64
  architectures. There is a Debian-specific patch in the packaging that
  adds a mechanism by which we can tell the test suite to accept small
  rendering differences; I tried to upstream this, but upstream refused
  to apply it.

- Some tests have slightly different rendering with the versions of Pango,
  fonts and other dependencies in Debian. Upstream only really fully
  supports whatever exact versions they happen to have installed on their
  CI and development systems at the time (mostly Fedora).
  Again, there is a Debian-specific patch that adds a mechanism by which
  we can tell the test suite to accept small rendering differences.

- Sometimes tests fail because of architecture-specific issues (often bugs
  in Mesa or another dependency, 

Bug#1062956: sysprof: NMU diff for 64-bit time_t transition

2024-02-24 Thread Simon McVittie
On Sat, 24 Feb 2024 at 11:19:48 +, Simon McVittie wrote:
> This unconditional use of restrict seems like a bug, I'll report it
> upstream.

https://gitlab.gnome.org/GNOME/sysprof/-/issues/114, fix proposed in
https://gitlab.gnome.org/GNOME/sysprof/-/merge_requests/88.

smcv



Bug#1062956: sysprof: NMU diff for 64-bit time_t transition

2024-02-24 Thread Simon McVittie
Control: tags -1 + wontfix

On Sat, 24 Feb 2024 at 02:10:45 -0800, Steve Langasek wrote:
> +sysprof (46~beta-1.1~exp1) experimental; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.

I'm pretty sure this one is actually unnecessary...

> --- sysprof-46~beta/debian/libsysprof-6-6t64.symbols  1970-01-01 
> 00:00:00.0 +
> +++ sysprof-46~beta/debian/libsysprof-6-6t64.symbols  2024-02-24 
> 10:09:00.0 +
> @@ -0,0 +1,5 @@
> +libsysprof-6.so.6 libsysprof-6-6t64 #MINVER#
> +* Build-Depends-Package: libsysprof-6-dev
> + sysprof_callgraph_category_get_type@Base 45~beta
> + sysprof_callgraph_flags_get_type@Base 45~beta
> + sysprof_recording_phase_get_type@Base 45~beta

... because these symbols clearly have no time_t in them.

Looking at build logs in
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-22T21%3A03%3A00/logs/libsysprof-6-dev/
it seems like the test-build is onky failing because sysprof has headers that
are valid as C but not valid as C++. This is new since libsysprof-4, which
was the version that was tested successfully during the early phases of
this transition.

This unconditional use of restrict seems like a bug, I'll report it
upstream.

https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/138 makes
this package compile successfully during the ABI check.

smcv



Bug#1064511: proton-caller: please replace Suggests on transitional steam package with steam-installer

2024-02-23 Thread Simon McVittie
Package: proton-caller
Version: 3.1.2-1
Severity: minor

proton-caller Suggests steam. Since Debian 12, the steam:i386 in contrib is
a transitional package which Depends on steam-installer.

Meanwhile, for users of Valve's .deb packages (official from Valve's
point of view, unofficial from Debian's point of view), steam is a
transitional package which Depends on steam-launcher (which in turn
Provides, Conflicts and Replaces steam-installer).

Please swap this suggestion to steam-installer, or possibly
steam-installer|steam-launcher, so that the transitional steam package
can eventually go away.

Thanks,
smcv



Bug#1064510: gamehub: please replace Suggests on transitional steam package with steam-installer

2024-02-23 Thread Simon McVittie
Package: gamehub
Version: 0.16.3-2-master+ds-1
Severity: minor

gamehub Suggests steam. Since Debian 12, the steam:i386 in contrib is
a transitional package which Depends on steam-installer.

Meanwhile, for users of Valve's .deb packages (official from Valve's
point of view, unofficial from Debian's point of view), steam is a
transitional package which Depends on steam-launcher (which in turn
Provides, Conflicts and Replaces steam-installer).

Please swap this suggestion to steam-installer, or possibly
steam-installer|steam-launcher, so that the transitional steam package
can eventually go away.

Thanks,
smcv



Bug#1064509: protontricks: please replace Recommends on transitional steam package with steam-installer

2024-02-23 Thread Simon McVittie
Package: protontricks
Version: 1.10.5-1
Severity: minor

protontricks Recommends steam. Since Debian 12, the steam:i386 in contrib
is a transitional package which Depends on steam-installer.

Meanwhile, for users of Valve's .deb packages (official from Valve's
point of view, unofficial from Debian's point of view), steam is a
transitional package which Depends on steam-launcher (which in turn
Provides, Conflicts and Replaces steam-installer).

Please swap this recommendation to steam-installer, or possibly
steam-installer|steam-launcher, so that the transitional steam package
can eventually go away.

Thanks,
smcv



Bug#1060838: meson: should use the host gobject-introspection-1.0.pc for looking up g-ir-scanner

2024-02-23 Thread Simon McVittie
On Wed, 21 Feb 2024 at 10:47:33 +0100, Johannes Schauer Marin Rodrigues wrote:
> I've just learned from Simon McVittie in #debian-devel that there is a way to
> cross-build packages using meson and gobject-introspection without this patch
> by configuring them with --cross-file. Here is an example from libportal:
> 
> https://salsa.debian.org/debian/libportal/-/commit/4efec56ef735eac25836acca867fe59812c3dc6d

I did mention this cross-file in an earlier
message to this same bug. This and other non-trivial
gobject-introspection packaging topics are documented in:
file:///usr/share/doc/gobject-introspection/README.Debian.gz (which I
hope to keep up to date with best-practice as it changes).

smcv



Bug#1050220: mutter: autopkgtest regression on s390x: tests time out after 5 minutes

2024-02-22 Thread Simon McVittie
On Tue, 20 Feb 2024 at 16:08:26 +, Gayathri Berli wrote:
> Please let us know if this bug still needs to be fixed.

I have never seen a s390x machine and probably never will, so you will
know much better than I do whether it's advantageous to our users for
mutter and gnome-shell to be available on that platform, or whether
it would be better to ask for architecture-specific removals of these
packages from s390x and stop spending time on them.

If you would like mutter and gnome-shell to be supportable on s390x,
then yes, we would like their tests to pass reliably there, because
otherwise we have no evidence that they work.

Does it make any sense for gnome-shell to exist on s390x? Or is s390x
only useful as a server platform?

smcv



Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

2024-02-22 Thread Simon McVittie
On Wed, 14 Feb 2024 at 16:47:23 +, Gayathri Berli wrote:
> In the current issue of gtk4 When I tried to reproduce
> the issue on s390x there are 1507 tests that are failing. Can you please
> suggest that version of dependency packages being used/issue reproduce steps/
> logs.

I'm sorry, I don't understand the question. You say you can reproduce 1507
test failures: if that's the case, why do you need steps-to-reproduce?
It seems like you can already reproduce a problem that needs solving?

smcv



Bug#1058740: gtk4,librsvg: big-endian support is at risk of being removed

2024-02-22 Thread Simon McVittie
On Wed, 14 Feb 2024 at 16:47:23 +, Gayathri Berli wrote:
> In librsvg also we have seen some test failures and regressions. when we
> debugged, we came to know that pixman code changes are triggering the
> regression in librsvg.

That's good to know. I see in
https://gitlab.freedesktop.org/pixman/pixman/-/issues/78 that there is
some confusion over which layer of the stack is the right one to be doing
this byteswapping: the original change was made to fix a bug seen in
gnome-characters, but then that change caused the librsvg bug.

In my experience the only way to solve endianness issues without causing
regressions is to have clear documentation of what endianness each layer
of the stack is aiming to use, so that you can check the behaviour of
each function against that documentation/specification and say "this is
correct" or "this is wrong" with confidence. The majority of computers this
decade are little-endian, so it's mainly the people who are interested in
supporting big-endian computers who need to get this right.

For instance, if a function is returning 32-bit RGBA data, you need
to be able to know whether the correct format is "red first" or "alpha
first" or "red in the least significant byte of the first 32-bit word"
or "alpha in the least significant byte". Otherwise, you can't know
whether a change is actually correct, or whether it's a workaround for
the layer above or below also being wrong.

I think this is what Simon Ser means in their comments on
https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/92.
In your commit message you said "This will write out the pixels as BGRA
on big endian systems but obviously that's wrong", but that isn't obvious
(at least not to me, and probably not immediately obvious to the other
Simon either).

In https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/92
you mentioned that before reverting that change, pixman was failing its
test suite on big-endian, and reverting the change makes its test suite
pass. That's probably relatively good evidence that the revert is the
correct thing to do, but that means it deserves to be mentioned in the
commit message.

This SDL change might be a good example of making sure that an intended
endianness is documented clearly:
https://github.com/libsdl-org/SDL/pull/8318/files

and this one might be a good example of justifying why a change is the
correct change:
https://github.com/libsdl-org/SDL/pull/8819

smcv



Bug#1064468: Settings schema 'org.gnome.desktop.a11y.interface' does not contain a key named 'show-status-shapes'

2024-02-22 Thread Simon McVittie
Control: forcemerge 1064438 -1

On Thu, 22 Feb 2024 at 12:25:53 -0500, David Mandelberg wrote:
> Upgrading gsettings-desktop-schemas from 45.0-2 to 46~beta-3 seems to have
> fixed the problem. So I think gnome-settings-daemon's dependency on
> gsettings-desktop-schemas (>= 42~) should be updated to require a newer
> version?

Yes, it's already marked as release-critical and pending upload.

smcv



Bug#1064461: gnome-settings-daemon: Xft.dpi not set correctly for 4K monitor at 200% scale

2024-02-22 Thread Simon McVittie
On Thu, 22 Feb 2024 at 14:21:38 +, Daniel Thompson wrote:
> I assume this is a version skew problem caused by gnome-settings-daemon
> updating to GNOME 46 before other components

If you upgrade both gnome-settings-daemon and gsettings-desktop-schemas
to their versions from unstable, does that resolve this?

(Possibly the same bug as #1064438)

smcv



Bug#1064457: RFP: composefs -- file system for mounting container images

2024-02-22 Thread Simon McVittie
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: ost...@packages.debian.org

* Package name: composefs
  Version : 1.0.3
  Upstream Contact: Alexander Larsson, Colin Walters
* URL : https://github.com/containers/composefs
* License : GPL-3.0-or-later AND LGPL-2.0-or-later AND Apache-2.0
  Programming Lang: C
  Description : file system for mounting container images

The composefs project combines several underlying Linux features to
provide a very flexible mechanism to support read-only mountable
filesystem trees, stacking on top of an underlying "lower" Linux
filesystem.

The key technologies composefs uses are:

  * overlayfs as the kernel interface
  * EROFS for a mountable metadata tree
  * fs-verity (optional) from the lower filesystem

---

libostree optionally uses composefs to mount OS images. At the moment it
uses a vendored copy of composefs, but there is movement upstream towards
using composefs as an external shared library and de-vendoring it. When
this happens, I will have to disable the composefs feature in src:ostree
until/unless composefs is packaged separately.

My interest in libostree is mainly for Flatpak, which doesn't use
composefs anyway, so I am not able to take responsibility for composefs as
a separate package; but I'd be fine with linking to an external composefs
maintained by someone else, if that's useful for a different use-case.



Bug#901631: Bug#901507: lintian: warn if dh-* sequence is in B-D-Arch or B-D-Indep but not Build-Depends

2024-02-22 Thread Simon McVittie
On Wed, 21 Feb 2024 at 21:55:08 +0100, Niels Thykier wrote:
> On Mon, 18 Jun 2018 12:16:55 +0100 Simon McVittie  wrote:
> > I hadn't intended that you'd add this mechanism for packages that
> > ship debhelper addons alongside other content, just the ones that have
> > little or no purpose other than their debhelper addons, like most/all
> > of the dh-$addon family, and maybe some of the pkg-$team-tools family.
> 
> Some dh add-ons can be in ``Build-Depends-Indep`` now and is used to support
> cross-building in some cases. I do not remember when the feature was added
> though, so it might not have been possible at the time this was filed.

If I remember correctly, the reason I opened the bug is that while
doing unrelated bug-fixing I was seeing a significant number of source
packages that failed to `debian/rules clean` if you install only the
Build-Depends. The typical scenario was that a source package that only
builds Architecture: all binaries would have debhelper or a sequence addon
that runs during clean (like gnome-pkg-tools) in its Build-Depends-Indep.
At the time I opened this bug, I think the only way to activate a sequence
addon was like `dh $@ --with gnome`, which is difficult to set up to
happen conditionally for some but not all builds.

I think the whole dh-sequence-foo mechanism was added since then, and
is a big improvement. Yes, if an addon is activated via dh-sequence-foo
(for example "Build-Depends(|-Arch|-Indep): dh-sequence-gnome"), then it
can be in Build-Depends-Indep, and it will just not be activated during
-B builds. For some addons this is normal, and for some addons this will
mean it doesn't work as intended - it depends what the addon does. But,
either way, that isn't going to break the ability to `debian/rules clean`
without the addon. So I think it would make sense for the the
dh-sequence-foo names to be excluded from any check that is intended to be
a solution for this bug.

smcv



Bug#1064369: gobject-introspection dropped versioned dependency on python3

2024-02-20 Thread Simon McVittie
On Tue, 20 Feb 2024 at 23:15:09 +0100, Matthias Klose wrote:
> On 20.02.24 22:50, Simon McVittie wrote:
> > What is the situation that is going wrong in autopkgtest? Can you perhaps
> > provide a log?
> 
> see
> https://autopkgtest.ubuntu.com/packages/m/meson/noble/ppc64el
> 
> the one triggered by python3-defaults/3.12.1-0ubuntu1
> gobject-introspection/1.79.1-1

Do you mean b2bf9aa6-b7bf-4f75-a69c-d2292de2ebbe, requested by you with
those two packages as triggers, which failed like this?

377s autopkgtest [20:34:18]: test exhaustive: preparing testbed
...
559s The following packages have unmet dependencies:
559s  gobject-introspection : Depends: python3 (< 3.12) but 3.12.1-0ubuntu1 is 
to be installed
559s  python3-dev : Depends: python3 (= 3.11.4-5ubuntu1) but 3.12.1-0ubuntu1 is 
to be installed
559s E: Unable to correct problems, you have held broken packages.
559s autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt 
install on test deps directly for further data about failing dependencies in 
test logs
559s exhaustive   FAIL badpkg

It isn't clear to me why that one is failing. apt seems to have started
by trying to install gobject-introspection_1.78.1-6, even though it had
--apt-pocket=proposed=src:python3-defaults,src:gobject-introspection on the
autopkgtest command-line - which I would have expected would make all binary
packages from src:gobject-introspection have 1.79.1-1 as the candidate
version?

Is it possible that autopkgtest might be adding pins for all of the
binary packages built by src:gobject-introspection in noble that will
take those binary packages from -proposed, but without adding similar pins
for the binary packages that were newly added in -proposed? Or some similar
interaction?

It's unfortunate that Ubuntu is trying to go directly from
gobject-introspection 1.78.1-6 to 1.79.x, without ever getting the higher
1.78.1-x revisions that are in Debian testing: that would have decoupled
the introduction of new binary packages from the GLib 2.79.x and Python
3.12 transitions.

> The problem is, that the -bin package is new and that no rdeps know about it
> yet.

rdeps are not meant to depend on the -bin package directly (it's meant
to be an implementation detail of the main g-i package), so any solution
that involves adding the -bin package to rdeps' dependencies seems like
the wrong thing. Ideally, all rdeps continue to not know about it.

smcv



Bug#1064369: gobject-introspection dropped versioned dependency on python3

2024-02-20 Thread Simon McVittie
Control: tags -1 + moreinfo

On Tue, 20 Feb 2024 at 22:15:21 +0100, Matthias Klose wrote:
> The package had in the past dependencies of the form
> 
>   python3 (<< 3.12), python3 (>= 3.11~), python3:any
> 
> the new one just
> 
>   python3:any
> 
> This leads to badly triggered autopkg tests, with a mismatching
> python3-defaults.  Afaik, gobject-introspection can only handle the default
> python version, not all supported python versions.

The parts that require a specific python3 version are now in the
gobject-introspection-bin binary package, which correctly depends on:

python3 (<< 3.12), python3 (>= 3.11~), python3:any

via dh_python and ${python3:Depends}. The gobject-introspection package
no longer contains any binary Python extensions. This was necessary to be
able to make it a Multi-Arch: same wrapper around a build-architecture
gobject-introspection-bin.

As far as I can see, it would not be straightforward to add a
lockstep-Python-version dependency to gobject-introspection, because it
does not directly contain any binary Python extensions itself (although
of course anyone wanting to prove me wrong is welcome to provide an
implementation).

gobject-introspection depends on gobject-introspection-linux-little-endian
(= 1.78.1-15) (or -big-endian on s390x, etc.). That's a virtual package
provided by gobject-introspection-bin, ensuring that gobject-introspection
and gobject-introspection-bin are upgraded in lockstep; so it should
not be possible to install a mismatched set.

What is the situation that is going wrong in autopkgtest? Can you perhaps
provide a log?

If gobject-introspection explicitly depended on gobject-introspection-bin
by name (not just via a virtual package), would that help?

Thanks,
smcv



Bug#1064016: fixed in adwaita-icon-theme 46~beta-2

2024-02-20 Thread Simon McVittie
On Tue, 20 Feb 2024 at 21:05:55 +0100, Amy Kos wrote:
> latest change in 46~beta-4
>  "Use a more minimal set of aliases as requested by upstream"
> is understandable from Gnome perpective.

I did try to get a more comprehensive set of aliases merged, but
the upstream maintainer refused, and I was concerned that if I pushed
harder, he would have rejected the change entirely (leaving e.g. Firefox,
Chromium, SDL in a similarly bad situation).

The policy we ended up with is that where the CSS/freedesktop.org
cursors had an obvious equivalence with one of the XC_ constants in
, we added aliases for those, but we did not add any
aliases for the hashes of custom cursors, or for other non-standardized
names (some of which might have originated in Qt, but the nature of
non-standardized names is that it's hard to tell where they came from
or who might be using them).

> Nevertheless it will take time until other software catch up.
> For instance in LXQt at least these are missing:
>  progress, help, nwse-resize and nesw-resize

Those are some of the standardized (CSS/freedesktop.org) names, so I
assume you mean that LXQt is looking for legacy/non-standardized names
that should be equivalent to those. What names is it looking for?

> Would it be worthwile to provide the missing symlinks
> from 46~beta-3 in Debian for the time being?

I would prefer not to have too many aliases that have been specifically
rejected upstream: if we do that, it will encourage projects whose
upstream maintainers happen to use Debian/Ubuntu to keep using the old
names, and then be surprised when their code doesn't work as intended
on non-Debian-derived distributions.

If these cursors are particularly high-visibility, we could consider
adding back a small number of aliases, but I'd prefer to have a
bug report against the package that needs them (in this case LXQt)
before we do that. That bug report's steps to reproduce will show us
how high-visibility the other package's use of those cursors is, and
watching to see when those bugs are closed will give us a cutoff point
at which we can drop the legacy aliases.

In particular, I don't want to keep the hash-based aliases as a
downstream divergence unless they're absolutely necessary, because
those are *extremely* opaque. (We can at least guess at the intended
semantics of left_ptr_watch, but what are the intended semantics of
1081e37283d983c07f3ef6bf? Nobody knows, unless someone can dig
out the original X11 bitmap that hashes to that value!)

So perhaps you could open a bug report against LXQt as a starting point?
That would consist of a list of some scenarios in which a wrong cursor
is seen, and ideally some suggestions for the CSS/freedesktop.org name
that it should be using in those scenarios. Some useful references:
https://drafts.csswg.org/css-ui/#cursor
https://developer.mozilla.org/en-US/docs/Web/CSS/cursor
https://www.freedesktop.org/wiki/Specifications/cursor-spec/

Or, if you can identify the lower-level code that is actually selecting
these cursors (perhaps Qt?), a bug report against the library that would
need to be updated to switch to CSS/freedesktop.org names would also
be fine.

All of the packages I've looked at so far (Firefox, Chromium, SDL) seemed
to be using either CSS/freedesktop.org names, or  names
(which now have aliases set up, where available), or a mixture of the two:
they were only using other legacy names as fallbacks, if at all.

smcv



Bug#1064042: gsettings-desktop-schemas: regression: LC_TIME=en_GB.utf8 uses 12-hour time format

2024-02-16 Thread Simon McVittie
Control: forwarded -1 
https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/issues/55
Control: tags -1 + upstream

On Fri, 16 Feb 2024 at 11:02:42 +0100, Jörg-Volker Peetz wrote:
> upgrading from version 45.0-2 to this version introduces a regression:
> with LC_TIME=en_GB.utf8 now a 12-hour time format (instead of 24-hour)
> is used, for example, in thunderbird.
> 
> Is it intended?

Sort of:
https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/commit/73e83eae294066266b98b80f525a88a5be3b38dd
(presumably the en_GB translation is one of many that have not been
updated to translate '12h' to '24h').

>From the upstream change:

"Translators: you will want to translate this from '12h' to '24h' if
your locale uses a 24-hour clock. Yes, it's a shame that we have to
do this when in theory the locale already knows how to format time,
but this is a pragmatic solution."

I don't think this is actually a pragmatic solution for anyone except
en_US speakers, so I've opened an upstream issue asking for a rethink.

smcv



Bug#1064016: adwaita-icon-theme: v46 cursor theme is missing legacy X11 icon names expected by many applications

2024-02-15 Thread Simon McVittie
Package: adwaita-icon-theme
Version: 46~beta-1
Severity: important
Tags: upstream
Control: affects -1 firefox firefox-esr chromium libsdl2-2.0-0
Forwarded: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/278

adwaita-icon-theme 46~beta removed a lot of symlinks representing legacy
X11 cursor names, such as left_ptr, hand2 and xterm.

Instead, it exclusively contains cursor names corresponding to the CSS
cursor list: https://drafts.csswg.org/css-ui/#cursor
which is the same as the freedesktop.org cursor spec, minus the proposed
"up-arrow" which is in neither CSS nor Adwaita:
https://www.freedesktop.org/wiki/Specifications/cursor-spec/

Unfortunately, lots of applications expect/assume that the legacy X11
cursor names will exist, and use them in preference to the CSS names.
Depending on the application, this can result in it either falling
back to the default arrow, or a nasty-looking pixelated X11 cursor,
or an empty rectangle.

A particularly visible symptom for this is that in affected applications,
the cursor does not change from its default shape to an I-beam when
hovering over selectable text, and does not change to a pointing finger
when hovering over a hyperlink.

For the cursors that have a corresponding entry in the legacy
X11 vocabulary and the CSS vocabulary, it's very easy to provide
backwards-compat by creating symlinks, for example left_ptr -> default,
hand2 -> pointer, xterm -> text. If upstream are not going to do this,
then I think it would be pragmatic for Debian and other distros to do it.

I am *not* intending to create or ship cursors that existed in the X11
cursor vocabulary but do not exist in the CSS vocabulary, some of which
are frankly baffling (I'm pretty sure we don't actually need boat,
pirate or umbrella, for example). Applications wanting those cursors
can either use unthemed X11 cursors or ship their own.

smcv



For reference, the CSS cursor names are as follows:

alias
all-scroll
cell
col-resize
context-menu
copy
crosshair
default
e-resize
ew-resize
grab
grabbing
help
move
n-resize
ne-resize
nesw-resize
no-drop
not-allowed
ns-resize
nw-resize
nwse-resize
pointer
progress
row-resize
s-resize
se-resize
sw-resize
text
vertical-text
w-resize
wait
zoom-in
zoom-out

and the X11 cursor names are:

X_cursor
arrow
based_arrow_down
based_arrow_up
boat
bogosity
bottom_left_corner
bottom_right_corner
bottom_side
bottom_tee
box_spiral
center_ptr
circle
clock
coffee_mug
cross
cross_reverse
crosshair
diamond_cross
dot
dotbox
double_arrow
draft_large
draft_small
draped_box
exchange
fleur
gobbler
gumby
hand1
hand2
heart
icon
iron_cross
left_ptr
left_side
left_tee
leftbutton
ll_angle
lr_angle
man
middlebutton
mouse
pencil
pirate
plus
question_arrow
right_ptr
right_side
right_tee
rightbutton
rtl_logo
sailboat
sb_down_arrow
sb_h_double_arrow
sb_left_arrow
sb_right_arrow
sb_up_arrow
sb_v_double_arrow
shuttle
sizing
spider
spraycan
star
target
tcross
top_left_arrow
top_left_corner
top_right_corner
top_side
top_tee
trek
ul_angle
umbrella
ur_angle
watch
xterm



Bug#1063768: debuginfod: man page gives an outdated equivalent of -U

2024-02-12 Thread Simon McVittie
Package: debuginfod
Version: 0.188-2.1
Severity: minor
Tags: upstream
Control: found -1 0.190-1

Related to the bug I recently opened regarding a missing dependency on
libarchive-tools, debuginfod(8) says:

   -U Activate DEB/DDEB patterns in archive scanning.  The default  is
  off.  Equivalent to-Z .deb='dpkg-deb --fsys-tarfile'
  -Z .ddeb='dpkg-deb --fsys-tarfile'.

but that hasn't been true since at least upstream version 0.184. What it
is now equivalent to is these commands quoted from debuginfod.cxx, if I'm
reading the code correctly:

case 'U':
  scan_archives[".deb"]="(bsdtar -O -x -f - data.tar\\*)<";
  scan_archives[".ddeb"]="(bsdtar -O -x -f - data.tar\\*)<";
  scan_archives[".ipk"]="(bsdtar -O -x -f - data.tar\\*)<";
  // .udeb too?
  break;

Thanks,
smcv



Bug#1063767: debuginfod: should have Recommends or Depends on libarchive-tools, for bsdtar

2024-02-12 Thread Simon McVittie
Package: debuginfod
Version: 0.188-2.1
Severity: important
Control: found -1 0.190-1

By default, debuginfod wants to unpack detached debug symbols and libraries
from Debian packages using bsdtar:

> Feb 12 13:14:46 REDACTED docker[2367192]: [Mon Feb 12 13:14:46 2024] (7/7): 
> accepting archive types .ddeb((bsdtar -O -x -f - data.tar\*)<) .deb((bsdtar 
> -O -x -f - data.tar\*)<) .ipk((bsdtar -O -x -f - data.tar\*)<) 
> .pkg.tar.zst(zstdcat)

(In my case the .ddeb, .deb and .ipk are built-in defaults, while handling
of .pkg.tar.zst is from a command-line option.)

But debuginfod has no dependency relationship with libarchive-tools, so
there's no reason to expect that bsdtar will work. For an installation of
debuginfod on a Debian system, I think unpacking .deb is basic
functionality, so I think a Recommends or maybe even a Depends would be
proportionate.

Looking at NEWS, I think this is probably a regression in 0.184 (therefore
a regression between bullseye and bookworm). Older versions were able to
use dpkg-deb to extract detached debug symbols, but 0.184+ requires bsdtar
for this:

case 'U':
  scan_archives[".deb"]="(bsdtar -O -x -f - data.tar\\*)<";
  scan_archives[".ddeb"]="(bsdtar -O -x -f - data.tar\\*)<";
  scan_archives[".ipk"]="(bsdtar -O -x -f - data.tar\\*)<";
  // .udeb too?
  break;

Please add a Recommends or Depends on libarchive-tools, whichever you
feel is more appropriate.

Thanks,
smcv



Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

2024-02-12 Thread Simon McVittie
Control: retitle -1 krb5: FTBFS on IPv6-only buildds: "Can't resolve hostname" 
in dh_auto_test
Control: tags -1 + ipv6

On Sun, 11 Feb 2024 at 23:40:34 +0000, Simon McVittie wrote:
> It might be relevant that according to #972151, arm-conova-03 (and
> perhaps other *-conova-* buildds?) is IPv6-only, with no IPv4 addresses
> or routes other than loopback (not even via NAT).

I gave back the failed builds and they succeeded on a different buildd.

I also notice that the original Architecture: all build of 1.20.1-5 failed
on x86-conova-02, and succeeded when retried on x86-grnet-02. I think
this supports the theory that this is really "FTBFS on IPv6-only buildds".

smcv



Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

2024-02-11 Thread Simon McVittie
On Sun, 11 Feb 2024 at 13:53:56 -0800, Benjamin Kaduk wrote:
> On Sat, Feb 10, 2024 at 01:33:15PM +0100, Johannes Schauer Marin Rodrigues 
> wrote:
> > there as a binNMU "Rebuild to sync binNMU versions" for krb5 and that
> > failed for arm64, armel and ppc64el:
> > 
> > https://buildd.debian.org/status/package.php?p=krb5
> > 
> > The error logs look very similar:
> > *** Output of last command:
> > Can't resolve hostname arm-conova-03
> 
> This is due more to the build environment than the test suite per se.
...
> In short, the test suite, as for the protocol itself, assumes that it can
> resolve the server's hostname to an IP address

It might be relevant that according to #972151, arm-conova-03 (and
perhaps other *-conova-* buildds?) is IPv6-only, with no IPv4 addresses
or routes other than loopback (not even via NAT).

I believe there is consensus that we consider "localhost resolves to
127.0.0.1" to be a reasonable thing to demand from all buildds as part
of the build-essential interface.

I am unsure whether there is consensus that "the result of gethostname()
resolves to some address of the local machine" is also a reasonable
thing to demand from all buildds as part of build-essential: /etc/hosts
typically makes this true, but is not *guaranteed* to do so. On Linux,
packages can ensure that it happens by build-depending on
libnss-myhostname [linux-any], if necessary.

However, even with both of those, if the krb5 test suite (or protocol)
is resolving the local hostname with AF_INET (IPv4-only), and with either
AI_ADDRCONFIG or NULL hints, then that will not yield any results on
an IPv6-only system for the reasons discussed in #952740 and related
bug reports.

A workaround is to resolve with AF_UNSPEC, which currently disregards
AI_ADDRCONFIG, but that is, itself, arguably a bug (#854301).

If I'm understanding the krb5 issue correctly, the version of this in krb5
is more troublesome than the related issues seen in the GLib test suite,
because the GLib test suite would be happy with localhost always being
resolvable to 127.0.0.1 (as requested in #801362), but the krb5 test suite
wants to be able to resolve the local host name as well (so
resolving #801362 would not be enough).

smcv



Bug#1063745: srt: FTBFS on i386: build-gnutls/test-srt failed in Transmission.FileUpload: srt_close(accepted_sock) -> SRT_ERROR

2024-02-11 Thread Simon McVittie
Source: srt
Version: 1.5.3-1
Severity: important
Tags: ftbfs unreproducible

The srt_1.5.3-1+b1 binNMU initially failed to build on the i386 buildd
with this test failure:

> 100: Test command: /<>/build-gnutls/test-srt 
> "--gtest_filter=Transmission.FileUpload"
> 100: Working Directory: /<>/build-gnutls
> 100: Test timeout computed to be: 1000
> 100: Note: Google Test filter = Transmission.FileUpload
> 100: [==] Running 1 test from 1 test suite.
> 100: [--] Global test environment set-up.
> 100: [--] 1 test from Transmission
> 100: [ RUN  ] Transmission.FileUpload
> 100: Running test on port 5000
> 100: WILL CREATE source file with size=84410368 (= 7 * 12058624[sndbuf])
> 100: Connection initialized
> 100: Finished sending, closing sockets:
> 100: Sockets closed, joining receiver thread
> 100: Received 0 bytes, breaking.
> 100: ./test/test_file_transmission.cpp:130: Failure
> 100: Expected: (srt_close(accepted_sock)) != (SRT_ERROR), actual: -1 vs -1
> 100:
> 100: Comparing files
> 100: [  FAILED  ] Transmission.FileUpload (9806 ms)

I gave back the build and it succeeded, so this is probably only an
intermittent failure, hence reported as non-RC; but it seemed like
something that maintainers should be aware of, to monitor whether it
happens again. Older build logs don't seem to show this test failing.

(I don't really know what this package is or does, I only noticed this
because the build failure temporarily made its amd64 and i386 instances
non-co-installable).

Thanks,
smcv



Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland

2024-02-11 Thread Simon McVittie
Control: affects -1 + xfce4 task-xfce-desktop

On Sun, 11 Feb 2024 at 17:51:43 +0100, Yves-Alexis Perez wrote:
> Control: reassign -1 ibus

Marking this as affecting xfce4 and task-xfce-desktop so that it'll show up
in the most likely places to report a bug in "the normal Xfce desktop", to
avoid duplicates.

> Ibus maintainers: on Debian (Xfce) live images for 12.5 it seems that at
> startup ibus outputs an error message which shouldn't be there (no idea if it
> should work or not, but at least there's no Wayland or Plasma involved).

Note that this is (at least for now) a bookworm-specific bug report for
a high-visibility message in live images. I haven't tested Xfce on older
or newer suites.

It's entirely possible that this is fixed in testing/unstable already:
codesearch seems to indicate that the warning message "Keymap changes
do not work (etc.)" has been removed from ibus at some point before
unstable, leaving only a commented-out version in the .po files.

smcv



Bug#1063709: lintian: should recommend gobject-introspection for dh --with=gir, not gobject-introspection-bin

2024-02-11 Thread Simon McVittie
Control: forwarded -1 
https://salsa.debian.org/lintian/lintian/-/merge_requests/492
Control: tags -1 + patch

On Sun, 11 Feb 2024 at 13:44:27 +, Simon McVittie wrote:
> `lintian -Ii ostree_2024.1-1.dsc` reports:
> 
> E: ostree source: missing-build-dependency-for-dh-addon gir (does not satisfy 
> gobject-introspection-bin:any) [debian/rules]
...
> Perhaps
> lib/Lintian/Data/Debhelper/Addons.pm could learn to have a hand-maintained
> list of special cases, "if you would generate a dependency on package x,
> use package y instead", and add
> gobject-introspection-bin => gobject-introspection to that list?

In fact that list already exists. Fix proposed in
https://salsa.debian.org/lintian/lintian/-/merge_requests/492

smcv



Bug#964290: lintian: FP missing-build-dependency-for-dh-addon gir => gobject-introspection

2024-02-11 Thread Simon McVittie
Control: tags -1 + patch

On Sat, 04 Jul 2020 at 23:35:17 -0700, Felix Lechner wrote:
> In my package liferea, I am getting this error:
> 
> missing-build-dependency-for-dh-addon gir => gobject-introspection
> 
> but I have in my control: gobject-introspection | dh-sequence-gir

Fix proposed in
https://salsa.debian.org/lintian/lintian/-/merge_requests/492

smcv



Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland

2024-02-11 Thread Simon McVittie
On Sun, 11 Feb 2024 at 15:12:17 +0100, Yves-Alexis Perez wrote:
> On Sat, 2024-02-10 at 17:22 +0000, Simon McVittie wrote:
> > I got this notification popping up (screenshot attached, transcribed here):
> > 
> >     IBus Notification
> >     -
> >     Keymap changes do not work in Plasma Wayland at present. Please use
> >     systemsettings5 instead.
> > 
> > It seems odd to get this message when I'm running a non-Plasma, X11 desktop.
> 
> Yes indeed, that's really weird. I'll try a live 12.5 cd at some point but if
> you have one handy can you run a dpkg -l |grep '^ibus' or something?

No need for dpkg -l,
https://cdimage.debian.org/images/release/current-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso.packages
says, among other things:

ibus1.5.27-5
ibus-data   1.5.27-5
ibus-gtk:amd64  1.5.27-5
ibus-gtk3:amd64 1.5.27-5
ibus-gtk4:amd64 1.5.27-5
ibus-hangul 1.5.4-2
ibus-m17n   1.4.19-1

At a guess, this is probably here because task-korean-desktop pulls in
ibus-hangul? But that has been the case since at least Debian 11...

> I don't really know why it would suddenly get installed but maybe some
> dependencies changed in 12.5.

I don't remember noticing this when I helped to test XFCE live images
during the 12.0 release, but I also can't say for sure that 12.0 wasn't
affected.

smcv



Bug#1063709: lintian: should recommend gobject-introspection for dh --with=gir, not gobject-introspection-bin

2024-02-11 Thread Simon McVittie
Package: lintian
Version: 2.117.0
Severity: normal

For context, ostree_2024.1-1 runs "dh $@ --with=gir" in d/rules.

`lintian -Ii ostree_2024.1-1.dsc` reports:

E: ostree source: missing-build-dependency-for-dh-addon gir (does not satisfy 
gobject-introspection-bin:any) [debian/rules]

However, the gobject-introspection-bin package is an implementation
detail, and is not meant to be relied on. Packages that depend on the gir
addon should depend on either dh-sequence-gir or gobject-introspection
(which, behind the scenes, depends on gobject-introspection-bin), and
ostree correctly depends on gobject-introspection. I don't think this
is an uncommon pattern.

I don't know how best to avoid this in Lintian - I see that it's doing
the equivalent of
`apt-file search /usr/share/perl5/Debian/Debhelper/Sequence/gir.pm`
in order to generate data/debhelper/add_ons.json. Perhaps
lib/Lintian/Data/Debhelper/Addons.pm could learn to have a hand-maintained
list of special cases, "if you would generate a dependency on package x,
use package y instead", and add
gobject-introspection-bin => gobject-introspection to that list?

I could work around this by moving gir.pm to gobject-introspection and
asking the lintian maintainers to regenerate add_ons.json; but if I
did that, it would be duplicated in the archive, once per architecture,
which doesn't seem ideal.

data/debhelper/commands.json also mentions gobject-introspection-bin,
therefore whatever part of Lintian reads that file will have the same
problem.

Thanks,
smcv



Bug#1037299: debian-live-12.0.0-amd64-xfce.iso: "Install Debian" -> "Untrusted application launcher"

2024-02-10 Thread Simon McVittie
On Sat, 10 Jun 2023 at 17:42:34 +0100, Simon McVittie wrote:
> Here is a route towards a proper fix which can hopefully go into the
> 12.1 point release:
> 
> # as root
> apt install libglib2.0-bin
> 
> # as the 'live' user
> gio set --type=string ~/Desktop/install-debian.desktop \
> metadata::trusted true
> gio set --type=string ~/Desktop/install-debian.desktop \
> metadata::xfce-exe-checksum \
> "$(sha256sum ~/Desktop/install-debian.desktop | cut -f1)"
> touch ~/Desktop/install-debian.desktop

I might have been transcribing this incorrectly from the live session
(which didn't have a convenient storage mechanism).
https://salsa.debian.org/live-team/calamares-settings-debian-packaging/-/merge_requests/2
points out that I probably meant $(... | cut -f1 -d ' '), to get only
the checksum and not the whole line.

smcv



Bug#1063665: konqueror: start page -> "The requested operation could not be completed", "Undocumented error"

2024-02-10 Thread Simon McVittie
On Sat, 10 Feb 2024 at 19:30:35 +, Simon McVittie wrote:
> I have not yet verified whether this is reproducible in the live image
> itself (that's the next thing on my list).

Yes it is.

> Unknown error code 1,560,894,720 Please send a full bug report at 
> https://bugs.kde.org.

The error code was different (a similarly large negative number) when
I tried it in the live image. I assume it's uninitialized or otherwise
meaningless, rather than having billions of distinct error codes.

smcv



Bug#1063665: konqueror: start page -> "The requested operation could not be completed", "Undocumented error" code 1560894720

2024-02-10 Thread Simon McVittie
Package: konqueror
Version: 4:20.12.0-4
Severity: normal
Tags: bullseye upstream
Forwarded: https://bugs.kde.org/show_bug.cgi?id=451480

Issue found during Debian 11.9 point release media testing, sorry if this
is already a known problem (I couldn't fnd a duplicate bug report).

To reproduce


* Boot an expendable machine into debian-installer from
  debian-live-11.9.0-amd64-kde.iso
* Install (I used British English and default settings for everything else)
* Log in
* Open the menu in the bottom left corner
* Choose Konqueror from the menu

I have not yet verified whether this is reproducible in the live image
itself (that's the next thing on my list).

Expected result
===

Konqueror with either a totally blank page, or some sort of splash page

Actual result
=

The URL bar shows "konq:blank".

The window content is as transcribed here:

---
[/!\] The requested operation could not be completed
 |/   --
  Undocumented Error
  --
Details of the request:

* URL:
* Date and Time: (a correct date and time)
* Additional Information:

Description:

Unknown error code 1,560,894,720 Please send a full bug report at 
https://bugs.kde.org.
---

This appears to be the same issue as upstream bug report
.

I don't know whether Debian 12 still has this issue. I don't normally use
Plasma, I'm only here because it's on the install media testing checklist.

Thanks,
smcv



Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland

2024-02-10 Thread Simon McVittie
Package: xfce4
Version: 4.18
Severity: normal
Tags: bookworm

Encountered while testing Debian 12.5.0 live media. This is probably a
bug in some component other than xfce4, but I don't know which one -
please reassign as appropriate and add "affects" on xfce4.

Steps to reproduce
==

Boot Debian 12.5.0 live media, or install from the same live media
(with either d-i or Calamares) and log in. In case it matters, my
installation was in en_GB (British English) and otherwise using defaults.

Expected result
===

No spurious popups

Actual result
=

I got this notification popping up (screenshot attached, transcribed here):

IBus Notification
-
Keymap changes do not work in Plasma Wayland at present. Please use
systemsettings5 instead.

It seems odd to get this message when I'm running a non-Plasma, X11 desktop.

smcv


Bug#1037299: debian-live-12.5.0-amd64-xfce.iso: "Install Debian" -> "Untrusted application launcher"

2024-02-10 Thread Simon McVittie
On Wed, 03 Jan 2024 at 17:03:09 +0200, Jonathan Carter wrote:
> On 2024/01/03 12:37, Patrick Schleizer wrote:
> > Didn't work for me but this did:
> > 
> > https://forum.xfce.org/viewtopic.php?id=16357
> 
> What did you do from there that made it work? We set the metadata bit from a
> script on the live image too, but it doesn't seem to have any effect.

I confirm that this bug is still present in the Debian 12.5 XFCE live image.
As Patrick said, a workaround is to run this in a terminal in the live image:

sudo apt install libglib2.0-bin
gio set -t string \
~/Desktop/install-debian.desktop \
metadata::xfce-exe-checksum \
$(sha256sum ~/Desktop/install-debian.desktop | awk '{print $1}')

before launching the installer.

smcv



Bug#1063657: installation-reports: expert install + https asks for a choice with only one option

2024-02-10 Thread Simon McVittie
Package: installation-reports
Severity: minor

Boot method: USB flash drive
Image version: reproduced on debian-12.5.0-i386-DVD-1.iso and 
debian-12.5.0-amd64-netinst.iso
Date: 2024-02-10
Machine: not relevant
Partitions: not relevant

My partner encountered an unexpected UX during point release media
testing, which #debian-cd asked me to report as a bug.

Steps to reproduce:

- boot into expert install (we used text mode)
- accept defaults until "Configure the package manager"
- asked to choose http, https or ftp for file downloads
- choose https

Expected result: maybe one of these:

- be offered a list of countries with https mirrors
- or proceed directly to entering information manually
- or a 2-way choice between https://deb.debian.org/debian or
  "enter information manually"

Actual result:

- I'm asked for "Debian archive mirror country"
- the only option is "enter information manually", which makes it look
  as though there isn't going to be any reasonable default
- but when I choose that, the default is deb.debian.org, which is good



Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el

2024-02-08 Thread Simon McVittie
On Thu, 08 Feb 2024 at 10:37:33 +, Simon McVittie wrote:
> Package: libmozjs-115-dev
> Justification: makes gjs FTBFS (#1063433)

I believe mozjs115_115.7.0-3 should fix this.

wb-team: Please could someone with wanna-build access schedule gjs
on mips64el to be built after the fixed version of mozjs115 becomes
available? I believe the correct spelling is:

dw gjs_1.78.3-1 . unstable . mips64el . -m 'libmozjs-115-dev (>= 115.7.0-3)'

mips team, or mozjs experts: Please could someone look into upstreaming
the attached mips-specific patch?

Thanks,
smcv
From: Simon McVittie 
Date: Thu, 8 Feb 2024 10:36:53 +
Subject: Export js::detail::CanonicalizedNaNBits on architectures that use it

Otherwise the inline function JS::CanonicalizeNaN(double), which is
called by gjs, cannot validly refer to it.

Bug-Debian: https://bugs.debian.org/1063446
Signed-off-by: Simon McVittie 
---
 js/public/Value.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/js/public/Value.h b/js/public/Value.h
index de8db0f..d934b59 100644
--- a/js/public/Value.h
+++ b/js/public/Value.h
@@ -445,7 +445,7 @@ constexpr uint64_t CanonicalizedNaNSignificand = 0x8;
 #endif
 
 #if defined(JS_RUNTIME_CANONICAL_NAN)
-extern uint64_t CanonicalizedNaNBits;
+extern JS_PUBLIC_DATA uint64_t CanonicalizedNaNBits;
 #else
 constexpr uint64_t CanonicalizedNaNBits =
 mozilla::SpecificNaNBits

Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el

2024-02-08 Thread Simon McVittie
On Thu, 08 Feb 2024 at 10:37:33 +, Simon McVittie wrote:
> Simplified steps to reproduce:
> Try to compile the attached, with:
> g++ test.cpp -o test $(pkgconf --cflags --libs mozjs-115)

Oops, really attached now.

> I'm preparing a possible patch (but it will take a long time to test,
> because compiling mozjs on mips64el is extremely slow).

Untested patch attached. I'm trying to build with this change on eberlin.

smcv
// Copyright 2024 Simon McVittie
// SPDX-License-Identifier: MIT

#include 
#include 

#include 
#include 

int main(int argc, char** argv)
{
// Smoke-test
const char* reason = JS_InitWithFailureDiagnostic();
if (reason) {
std::fprintf(stderr, "Fatal error: %s\n", reason);
return 1;
}
JSContext* cx = JS_NewContext(32 * 1024 * 1024);

// https://bugs.debian.org/1063446
uint64_t u64;
double d = JS::CanonicalizeNaN(0.0/0.0);
static_assert(sizeof(u64) == sizeof(d));
memcpy(, , sizeof(d));
std::printf("Representation of a canonicalized NaN: %" PRIx64 "\n", u64);

JS_DestroyContext(cx);
JS_ShutDown();
return 0;
}
>From ac5a01642f111e88cb80aa54b1ee438b3bc6d07e Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 8 Feb 2024 10:36:53 +
Subject: [PATCH] Export js::detail::CanonicalizedNaNBits on architectures that
 use it

Otherwise the inline function JS::CanonicalizeNaN(double), which is
called by gjs, cannot validly refer to it.

Bug-Debian: https://bugs.debian.org/1063446
Signed-off-by: Simon McVittie 

Gbp-Pq: Name Export-js-detail-CanonicalizedNaNBits-on-architectures-th.patch
---
 js/public/Value.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/js/public/Value.h b/js/public/Value.h
index de8db0fed8..d934b59dd4 100644
--- a/js/public/Value.h
+++ b/js/public/Value.h
@@ -445,7 +445,7 @@ constexpr uint64_t CanonicalizedNaNSignificand = 0x8;
 #endif
 
 #if defined(JS_RUNTIME_CANONICAL_NAN)
-extern uint64_t CanonicalizedNaNBits;
+extern JS_PUBLIC_DATA uint64_t CanonicalizedNaNBits;
 #else
 constexpr uint64_t CanonicalizedNaNBits =
 mozilla::SpecificNaNBits

Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el

2024-02-08 Thread Simon McVittie
Package: libmozjs-115-dev
Version: 115.7.0-2
Severity: serious
Tags: upstream
Justification: makes gjs FTBFS (#1063433)
X-Debbugs-Cc: debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el
Control: block 1063433 by -1

Original steps to reproduce:
Try to compile gjs 1.78.3-1 (#1063433), which calls this public API:
double JS::CanonicalizeNaN(double)

Simplified steps to reproduce:
Try to compile the attached, with:
g++ test.cpp -o test $(pkgconf --cflags --libs mozjs-115)

Expected result:
gjs or the simplified test compiles, links and runs successfully

Actual result:
On amd64 and other architectures, linking succeeds.
On mips64el, linking fails:
/usr/bin/ld: /tmp/cc41qWiD.o: in function `main':
test.cpp:(.text+0x22c): undefined reference to 
`JS::detail::CanonicalizedNaNBits'

I think this is because mozjs has mips-specific code to detect which is
the preferred representation of NaN, with the result stored in a global
variable that is read by the inline function JS::CanonicalizeNaN(double);
but that global variable is not exported, so gjs cannot validly refer to it.

I'm preparing a possible patch (but it will take a long time to test,
because compiling mozjs on mips64el is extremely slow).

smcv



Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)

2024-02-06 Thread Simon McVittie
On Tue, 06 Feb 2024 at 10:20:46 +0100, Yves Le Berre wrote:
> I am not familiarized with building debian debug packages.
> do doomsday and libsdl2 packages need to be rebuilt or do they exist
> somewhere ?

Their detached debug symbols should already be provided in Debian, so you
don't need to rebuild anything. You can either use

export DEBUGINFOD_URLS="https://debuginfod.debian.net;

(that's the easier option), or add these apt sources:

deb http://deb.debian.org/debian-debug/ testing-debug main
deb http://deb.debian.org/debian-debug/ unstable-debug main

and install the relevant -dbgsym packages:

- doomsday-dbgsym
- libsdl2-2.0-0-dbgsym
- libx11-6-dbgsym
- libxcb1-dbgsym
- libxext6-dbgsym
- libxrandr2-dbgsym
- probably others, but I can't tell which ones without seeing
  a backtrace with partial symbols

Thanks,
smcv



Bug#1063203: pangomm2.48: NMU diff for 64-bit time_t transition

2024-02-05 Thread Simon McVittie
On Mon, 05 Feb 2024 at 14:06:16 -0300, Lucas Kanashiro wrote:
> we have identified
> pangomm2.48 as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).

I suspect that this one might well be a false positive. The ABI check
is failing with:

/usr/include/pangomm-2.48/pangomm/private/renderer_p.h:18:25: error: 'Renderer' 
does not name a type; did you mean 'FT_Renderer'?
   18 |   using CppObjectType = Renderer;
  | ^~~~
  | FT_Renderer
— 
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09%3A18%3A00/logs/libpangomm-2.48-dev/time_t/log.txt

But from its name, "pangomm/private/renderer_p.h" is probably not intended
to be part of the public API anyway?

smcv



Bug#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)

2024-02-04 Thread Simon McVittie
Control: reassign -1 doomsday,src:libsdl2
Control: found -1 doomsday/2.3.1+ds1-1
Control: found -1 libsdl2/2.30.0+dfsg-1

On Sun, 04 Feb 2024 at 09:18:27 +0100, Yves Le Berre wrote:
> * What led up to the situation?
> 
> loading  wad file (doom /doom2/heretic/...)

Please assume that I'm unfamiliar with the doomsday package. What packages
would I install and what command would I run to reproduce this?

Also, it might be relevant to ask: what desktop environment or other
GUI are you using? And for desktop environments that support being run
as a Wayland compositor, is it in Wayland or X11 mode?

To reproduce *a* crash on my system (GNOME in Wayland mode), it seems
to be sufficient to install doomsday and doom-wad-shareware, and run:

doomsday -iwad /usr/share/games/doom/doom1.wad

but I don't think this is necessarily the same crash you're seeing.

> segmentation fault :
> 
> févr. 04 08:54:11 jupiter kernel: Code: 1d df b0 17 00 48 89 df 48 83 ec 08
> e8 ff b8 fc ff 48 8b 3d d0 b0 17 00 e8 23 61 0e 00 48 89 df be ff ff ff ff
> e8 e6 b8 fc ff <8b> 7d 08 83 05 ac b0 17 00 01 e8 f7 fd ff ff 48 89 c3 48 85
> c0 74
> févr. 04 08:54:11 jupiter kernel: doomsday[4521]: segfault at 8 ip
> 7fd6534a268a sp 7ffe8e89e7d0 error 4 in
> libSDL2-2.0.so.0.3000.0[7fd65346a000+12c000] likely on CPU 0 (core 0, socket
> 0)

Are you able to get a backtrace from this segfault? Please see:
https://wiki.debian.org/HowToGetABacktrace

When I try the command above, on GNOME in Wayland mode, I get what
appears to be a different crash:

Thread 1 (Thread 0x709b1980 (LWP 584950) "doomsday"):
#0  0x753ace83 in require_socket (dpy=) at 
../../src/xcb_io.c:70
#1  _XFlush (dpy=0x55faf230) at ../../src/xcb_io.c:606
#2  0x753afb3d in _XGetRequest (dpy=dpy@entry=0x55faf230, 
type=type@entry=98 'b', len=len@entry=8) at ../../src/XlibInt.c:1787
#3  0x753a2a57 in XQueryExtension (dpy=dpy@entry=0x55faf230, 
name=name@entry=0x75367128  "RANDR", 
major_opcode=major_opcode@entry=0x7fffd714, 
first_event=first_event@entry=0x7fffd718, 
first_error=first_error@entry=0x7fffd71c) at ../../src/QuExt.c:49
#4  0x75395b16 in XInitExtension (dpy=dpy@entry=0x55faf230, 
name=name@entry=0x75367128  "RANDR") at 
../../src/InitExt.c:59
#5  0x760e7c9b in XextAddDisplay (extinfo=extinfo@entry=0x753671b0 
, dpy=dpy@entry=0x55faf230, 
ext_name=ext_name@entry=0x75367128  "RANDR", 
hooks=hooks@entry=0x75367140 , nevents=nevents@entry=2, 
data=data@entry=0x0) at ../../src/extutil.c:110
#6  0x7535d860 in XRRFindDisplay (dpy=dpy@entry=0x55faf230) at 
../../src/Xrandr.c:295
#7  0x7535dfc0 in XRRFindDisplay (dpy=0x55faf230) at 
../../src/Xrandr.c:361
#8  XRRQueryExtension (dpy=0x55faf230, event_base_return=0x7fffd818, 
error_base_return=0x7fffd818) at ../../src/Xrandr.c:352
#9  0x77995ae4 in de::internal::RRInfo::RRInfo() (this=0x7fffd8a0) 
at ./doomsday/sdk/libgui/src/displaymode_x11.cpp:63
#10 0x7799502d in DisplayMode_Native_Init() () at 
./doomsday/sdk/libgui/src/displaymode_x11.cpp:188
#11 0x77929d11 in DisplayMode_Init() () at 
./doomsday/sdk/libgui/src/displaymode.cpp:195
#12 0x5573eb1d in ClientApp::initialize() (this=0x7fffda90) at 
./doomsday/apps/client/src/clientapp.cpp:628
#13 0x5572175d in main(int, char**) (argc=, 
argv=0x7fffdcb8) at ./doomsday/apps/client/src/main_client.cpp:109

which makes me wonder whether there is some conflict between the way
libsdl2 is using X11, and the way the doomsday engine is using X11
internally?

At the time of this crash, all other threads seem to be blocked in poll()
or pthread_cond_wait() or similar: none of them are actively running code.

> NB: Downgrading libsdl2-2.0-0 to 2.28.5+dfsg-3 solves issue.

This might either be a regression in libsdl2, or an unintended interaction
with the new libsdl2 exposing a bug in doomsday; at this stage it's hard
to tell which.

smcv



Bug#1051010: Bug #1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

2024-02-02 Thread Simon McVittie
I've changed the subject line back to the one from the bug - I get a
*lot* of bugmail, which I usually see out-of-context, so "Investigating"
doesn't really work as a reminder of what bug and what package you're
talking about. I hope that's compatible with your workflow.

On Fri, 02 Feb 2024 at 12:11:13 +, Nicholas Bamber wrote:
> So far in order to investigate I have:
> 
> 1. installed discord on a lwm desktop via flatpak. This works but is pretty
> ugly and the whole filesystem is exposed.

Large proprietary apps containing an entire web browser engine tend not to
be feasible to sandbox meaningfully, unfortunately, especially if their
packagers want them to have full functionality for users who are unaware of
the existence of sandboxing and want everything to "just work".

My usual go-to test apps are GNOME Recipes
https://flathub.org/apps/org.gnome.Recipes, ASHPD demo
https://flathub.org/apps/com.belmoussaoui.ashpd.demo, or the portal tests
built by src:libportal (install libportal-tests-gtk3 and
libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in
the environment, or you can build them into Flatpak apps from the source
package). Those are a lot more meaningfully sandboxed.

> 2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user
> environment.

In the original bug report, part of the solution I suggested was this:

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/lwm.desktop, most likely just "Lwm":

DesktopNames=Lwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

Most display managers take this into account and will convert it into
setting the XDG_CURRENT_DESKTOP setting (for example, I know that gdm3,
lightdm and sddm do this).

This won't work for xdm, but at some point I think we have to start
treating that sort of thing as an xdm limitation, rather than something
that individual desktop environments are expected to address?

> Putting a script into the 55 priority in /etc/X11/Xsession.d. This works
> (and does not pollute other desktop environments since we can check at that
> point). However it depends on the the package dbus-x11 and I have concerns
> about the long term support for this package.

Doesn't the combination of these two files

dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime
dbus-x11: /etc/X11/Xsession.d/95dbus_update-activation-env

already do what's needed here? Those two packages represent the only two
implementations of the dbus-session-bus virtual package that currently
exist in Debian.

xdg-desktop-portal already depends on
default-dbus-session-bus | dbus-session-bus, so whenever xdg-desktop-portal
is installed, so is at least one of those two packages; and they both pull
in dbus-bin, which provides /usr/bin/dbus-update-activation-environment.

If someone adds a third implementation of dbus-session-bus, I think it
would be entirely reasonable for us to expect it to have similar handling
of at least the most basic variables like DBUS_SESSION_BUS_ADDRESS,
DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP.

The other possible way to do this, which *would* work even for xdm, is to
do like gnome-session does, and upload at least those few basic environment
variables to the D-Bus activation environment during GUI session startup,
either from the main executable (using libdbus or a similar library) or
from a shell script wrapper (using dbus-update-activation-environment or
equivalent). This wouldn't necessarily have to imply a hard dependency
on d-u-a-e, it could be done conditionally. I realise that this is
unappealing for a specifically lightweight desktop environment, so I'd
be fine with the answer to this particular part being "wontfix, use a
better display manager if you want this functionality".

smcv



Bug#1062026: autopkgtest: add loongarch64 support

2024-01-31 Thread Simon McVittie
On Wed, 31 Jan 2024 at 01:28:43 +, Zhang Na wrote:
>   Add loongarch64 support, thanks!

Thanks, have you successfully tested this? Does it successfully test
packages under qemu?

> +elif self.qemu_architecture in ('arm', 'riscv64', 'loongarch64'):
>  argv.extend(['-machine', 'virt'])

Is this required? `qemu-system-loongarch64 -machine help` says virt is
the default anyway. We probably shouldn't be forcing particular options
if it isn't required.

(On arm there is no default, and on riscv64 qemu's default machine is
not virtio-based, so they do need this special case)

smcv



Bug#1061884: allegro4.4: NMU diff for 64-bit time_t transition

2024-01-30 Thread Simon McVittie
On Mon, 29 Jan 2024 at 23:45:11 +, Steve Langasek wrote:
> Dear maintainer,

(I am a games team member but not a maintainer of this particular package)

> diff -Nru allegro4.4-4.4.3.1/debian/liballeggl4.4t64.4.install 
> allegro4.4-4.4.3.1/debian/liballeggl4.4t64.4.install
> --- allegro4.4-4.4.3.1/debian/liballeggl4.4t64.4.install  1970-01-01 
> 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/liballeggl4.4t64.4.install  2023-08-28 
> 13:02:32.0 +

Should this have been liballeggl4.4t64.install, without the last ".4"?

> diff -Nru allegro4.4-4.4.3.1/debian/liballeggl4.4t64.4.lintian-overrides 
> allegro4.4-4.4.3.1/debian/liballeggl4.4t64.4.lintian-overrides
> --- allegro4.4-4.4.3.1/debian/liballeggl4.4t64.4.lintian-overrides
> 1970-01-01 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/liballeggl4.4t64.4.lintian-overrides
> 2024-01-29 23:44:39.0 +

Similarly this, and:

> --- allegro4.4-4.4.3.1/debian/liballegro4.4t64.4.examples 1970-01-01 
> 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/liballegro4.4t64.4.examples 2023-08-28 
> 13:02:32.0 +

> --- allegro4.4-4.4.3.1/debian/liballegro4.4t64.4.install  1970-01-01 
> 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/liballegro4.4t64.4.install  2023-08-28 
> 13:02:32.0 +

> --- allegro4.4-4.4.3.1/debian/liballegro4.4t64.4.lintian-overrides
> 1970-01-01 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/liballegro4.4t64.4.lintian-overrides
> 2024-01-29 23:44:39.0 +

> --- allegro4.4-4.4.3.1/debian/libjpgalleg4.4t64.4.install 1970-01-01 
> 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/libjpgalleg4.4t64.4.install 2023-08-28 
> 13:02:32.0 +

> --- allegro4.4-4.4.3.1/debian/libjpgalleg4.4t64.4.lintian-overrides   
> 1970-01-01 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/libjpgalleg4.4t64.4.lintian-overrides   
> 2024-01-29 23:44:39.0 +

> --- allegro4.4-4.4.3.1/debian/libloadpng4.4t64.4.lintian-overrides
> 1970-01-01 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/libloadpng4.4t64.4.lintian-overrides
> 2024-01-29 23:44:39.0 +

> --- allegro4.4-4.4.3.1/debian/liblogg4.4t64.4.install 1970-01-01 
> 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/liblogg4.4t64.4.install 2023-08-28 
> 13:02:32.0 +

> --- allegro4.4-4.4.3.1/debian/liblogg4.4t64.4.lintian-overrides   
> 1970-01-01 00:00:00.0 +
> +++ allegro4.4-4.4.3.1/debian/liblogg4.4t64.4.lintian-overrides   
> 2024-01-29 23:44:39.0 +



  1   2   3   4   5   6   7   8   9   10   >