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

[Simon McVittie]

Control: severity -1 normal

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

gobject-introspection uploaded, downgrading to non-RC.

smcv

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

[Simon McVittie]

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

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

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

I still think this.

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

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

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

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

smcv

Bug#1060953: marked as pending in gobject-introspection

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


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

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

Closes: #1060951, #1060953
Mitigates: #1071116


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1060953

Bug#1060951: marked as pending in gobject-introspection

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


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

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

Closes: #1060951, #1060953
Mitigates: #1071116


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1060951

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

[Simon McVittie]

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

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

smcv

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

[Simon McVittie]

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

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

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

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

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

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

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

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

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

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

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

smcv

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

[Simon McVittie]

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

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

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

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

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

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

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

smcv

Bug#1070745: marked as pending in glib2.0

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


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

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

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


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1070745

Bug#1070745: marked as pending in glib2.0

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


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

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

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


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1070745

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

[Simon McVittie]

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

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

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

smcv

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

Control: severity 1070706 normal
Control: severity 1070714 normal

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

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

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

Thanks!

smcv

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

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

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

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

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

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

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

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

Thanks,
smcv

Bug#1070706: gtk4 udeb has unsatisfiable dependencies

[Simon McVittie]

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

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

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

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

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

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

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

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

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

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

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

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

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

smcv

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

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


d/control: Switch quake4 dependency from libasound2 to libasound2t64

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

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


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1070016

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

[Simon McVittie]

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

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

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

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

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

smcv

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

[Simon McVittie]

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

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

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

smcv

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

[Simon McVittie]

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

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

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

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

which appears to have been an intentional compatibility break?

smcv

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

[Simon McVittie]

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

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

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

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

Here is a convenient reproducer in an unprivileged container:

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

Thanks,
smcv

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

[Simon McVittie]

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

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

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

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

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

The failure reason here is that this test timed out.

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

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

smcv

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

[Simon McVittie]

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

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

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

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

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

smcv

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

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


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

Closes: #1067677


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1067677

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

[Simon McVittie]

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

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

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

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

smcv

Bug#1067677: clutter-gst-3.0: build-dependency on libglib2.0-0 is unsatisfiable on armel/armhf

[Simon McVittie]

Source: clutter-gst-3.0
Version: 3.0.27-3
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

The build-dependency on libglib2.0-0 is no longer satisfiable in unstable
due to the 64-bit time_t transition. It should be replaced with
libglib2.0-dev (>= 2.18), or just libglib2.0-dev.

Alternatively, clutter-gst-3.0 could be removed (#1018112), but that
would require also removing cheese (#1018115) and pinpoint (#1018133),
as well as breaking a Recommends in mugshot.

smcv

Bug#1067676: gpick: build-dependency on libglib2.0-0 is unsatisfiable on armel/armhf

[Simon McVittie]

Source: gpick
Version: 0.2.6-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

gpick Build-Depends on:

debhelper-compat (= 13),
cmake,
libcairo2 (>=1.6),<---
libglib2.0-0 (>=2.16),<---
libgtk-3-dev,
liblua5.4-dev (>= 5.4),
libboost-dev,
libexpat1-dev,
lemon,
flex,
ragel,
gettext,
libboost-test-dev,
libboost-system-dev,
libboost-filesystem-dev

The build-dependency on libglib2.0-0 is no longer satisfiable in unstable
due to the 64-bit time_t transition. It should be replaced with
libglib2.0-dev (>= 2.16), or just libglib2.0-dev.

Similarly, the build-dependency on libcairo2 should be replaced with
libcairo2-dev.

Thanks,
smcv

Bug#1067616: FTBFS: error: ‘struct input_event’ has no member named ‘time’

[Simon McVittie]

On Sun, 24 Mar 2024 at 23:06:18 +0500, Andrey Rakhmatullin wrote:
> GLX/input_device_linuxevent.cpp: In member function ‘virtual void
> CL_InputDevice_LinuxEvent::keep_alive()’:
> GLX/input_device_linuxevent.cpp:269:72: error: ‘struct input_event’ has no
> member named ‘time’
>   269 |
> ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].code ? "Config Sync" : "Report
> Sync" );

Looks like another instance of essentially the same issue that's fixed in
SDL by . Applying the
same technique would probably work here too.

smcv

Bug#1067508: debhelper: lost most of its dependencies in 13.15

[Simon McVittie]

Package: debhelper
Version: 13.15
Severity: grave
Justification: renders package unusable
Control: block 1036884 by -1

debhelper 13.14.1 has:

Depends: autotools-dev, dh-autoreconf (>= 17~), dh-strip-nondeterminism (>= 
0.028~), dpkg (>= 1.18.0~), dpkg-dev (>= 1.18.2~), dwz (>= 0.12.20190711), file 
(>= 3.23), libdebhelper-perl (= 13.14.1), libdpkg-perl (>= 1.17.14), man-db, 
po-debconf, perl:any

According to its buildd log (I haven't upgraded to the new version locally
yet), debhelper 13.15 only has:

Depends: perl:any

This leads to multiple packages failing to build from source because
one of the dh_ tools cannot load Dh_Lib, for example in
.

I suspect this might have regressed in
?

smcv

Bug#1067288: pulseaudio: FTBFS on x86: cpu-volume-test fails, segfault in svolume_orc_test

[Simon McVittie]

Control: retitle -1 pulseaudio: FTBFS on x86: cpu-volume-test fails, segfault 
in svolume_orc_test
Control: reassign -1 src:orc 1:0.4.38-1
Control: forwarded -1 https://gitlab.freedesktop.org/gstreamer/orc/-/issues/66
Control: tags 1067458 + ftbfs sid trixie
Control: merge 1067458 -1
Control: affects 1067458 + src:pulseaudio

On Wed, 20 Mar 2024 at 21:48:23 +0100, Lucas Nussbaum wrote:
> > === 47/53 
> > 
> > test: cpu-volume-test
> > start time:   06:46:56
> > duration: 2.82s
> > result:   exit status 1
> > command:  
> > UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
> >  
> > LD_LIBRARY_PATH=/<>/obj-x86_64-linux-gnu/src/pulse:/<>/obj-x86_64-linux-gnu/src/pulsecore:/<>/obj-x86_64-linux-gnu/src
> >  MALLOC_PERTURB_=255 MAKE_CHECK=1 
> > ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> > /<>/obj-x86_64-linux-gnu/src/tests/cpu-volume-test
> > --- stdout 
> > ---
> > Running suite(s): CPU
> > 66%: Checks: 3, Failures: 0, Errors: 1
> > ../src/tests/cpu-volume-test.c:188:E:svolume:svolume_orc_test:0: (after 
> > this point) Received signal 11 (Segmentation fault)
> > ==

This seems to be the same issue as #1067458.

If a fix isn't obvious, could we perhaps roll back orc to 0.4.34
(presumably versioned as 1:0.4.38+really0.4.34), or disable its use
in PulseAudio for now?

Thanks,
smcv

Bug#1067427: dpkg-dev: Fail to generate a substitution variable ${t64:Provides} (time_t transition)

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 21 Mar 2024 at 15:00:52 +0100, Christian Marillat wrote:
> I noticed this bug with the libopenshot-audio source and with
> armel, armh and powerpc architectures from buildd logs and my rebuild.
> 
> I didn't pay attention for others sources, but I noticed that only
> after a second rebuild...
> 
> ,
> | pkg-gencontrol: warning: Provides field of package libopenshot-audio9t64: 
> substitution variable ${t64:Provides} used, but is not defined
> | dpkg-gencontrol: warning: Provides field of package libopenshot-audio9t64: 
> substitution variable ${t64:Provides} used, but is not defined
> `

This appears to be working as designed (cc'ing the instigator of this
transition for confirmation). It is correct that no ${t64:Provides}
is generated on armel, armhf and powerpc (and other 32-bit non-i386
architectures, like hppa).

There are four categories of architectures for this transition (text
adapted from https://wiki.debian.org/ReleaseGoals/64bit-time, which was
itself adapted from a recent message from me to -devel):

 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.

On these architectures, libopenshot-audio9t64 can safely have
Provides: libopenshot-audio9, because the ABI has not actually changed.

 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.

On i386, libopenshot-audio9t64 can have the Provides, as above.

 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.

On x32, libopenshot-audio9t64 should ideally have the Provides, as above
(I'm not sure whether it actually does, but given the status of x32,
I don't think this is actually harming anyone.)

 4. armel, armhf are the two 32-bit release architectures which are
not in any of the previous categories, so they are genuinely changing
their ABIs.
Non-release architectures in the same category: hppa m68k powerpc sh4.

On these architectures, libopenshot-audio9t64 must not have a Provides
on libopenshot-audio9, because its ABI has changed, so the new library
does not provide an interface that is compatible with the old library.
(This is the reason why we're doing all this renaming!)

So I think this is not a bug, and certainly not a RC bug. The warnings are
a bit annoying, but do not indicate a genuine problem.

smcv

Bug#1067247: pulseaudio: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Simon McVittie]

On Wed, 20 Mar 2024 at 20:00:32 +, Thorsten Glaser wrote:
> Unfortunately, as with umockdev, I have no idea what is going on
> here… does it #undef _FILE_OFFSET_BITS or something?

Yes it does. padsp(1) is based on a LD_PRELOAD module similar to those
used in fakeroot, fakechroot, umockdev and so on, which works by
interposing a bunch of glibc functions including stat(). As currently
implemented, it achieves this by #undef'ing the _FILE_OFFSET_BITS feature
test so that it can interpose all flavours of stat(), including
stat64() and so on.

Since glibc 2.34, on 32-bit architectures all such LD_PRELOAD modules
need updating to also interpose __lstat64_time64(), __stat64_time64(),
__fstat64_time64() and __fstatat64_time64() on architectures where they
exist - otherwise, programs and libraries compiled with 64-bit time_t
will bypass the wrapped stat(), stat64() etc. and call __stat64_time64()
instead, and therefore the wrapping will be ineffective and padsp will
not work as intended.

Because padsp is not core functionality for pulseaudio, a brute-force
approach to unblocking this could be to disable it on 32-bit non-i386
architectures. Untested pseudocode:

--- meson.build
+++ meson.build
 if cc.has_header('sys/soundcard.h', required: get_option('oss-output'))
   # OSS output via daemon module-detect
   cdata.set('HAVE_OSS_OUTPUT', 1)
   # OSS wrapper
-  cdata.set('HAVE_OSS_WRAPPER', 1)
+  if cc.sizeof('void *') >= 8 or host_machine.cpu_family() == 'x86'
+cdata.set('HAVE_OSS_WRAPPER', 1)
+  endif
   cdata.set('PULSEDSP_LOCATION', pulsedsp_location)
 endif

(and then change the packaging to tolerate it not being installed)

In practice padsp is mainly useful for legacy i386 binaries and maybe
a few very early legacy amd64 binaries (late 90s/early 00s era games,
especially ported by Loki Games) which might assume OSS audio, and not
support ALSA or PulseAudio directly. Since we're breaking the platform ABI
on armel/armhf/etc. *anyway*, we can't rely on the ability to run legacy
binaries even if they exist, so it's probably no longer interesting to
provide padsp on those architectures.

smcv

Bug#1067208: umockdev: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

[Simon McVittie]

On Thu, 21 Mar 2024 at 14:13:38 +0500, Andrey Rakhmatullin wrote:
> On Wed, Mar 20, 2024 at 03:05:34AM +, Thorsten Glaser wrote:
> > cc -Ilibumockdev-preload.so.0.0.0.p -I. -I.. -fdiagnostics-color=always 
> > -Wall -Winvalid-pch -std=gnu11 -Werror=missing-prototypes 
> > -Werror=strict-prototypes -Werror=nested-externs -Werror=pointer-arith 
> > -Werror=implicit-function-declaration -Werror=implicit-int 
> > -Werror=int-conversion -Werror=old-style-definition -Werror=pointer-arith 
> > -Werror=init-self -Werror=format-security -Werror=format=2 
> > -Werror=return-type -Werror=uninitialized -Wcast-align -Wno-error=pragmas 
> > -Wno-error=discarded-qualifiers -Wno-error=incompatible-pointer-types 
> > -Wno-error=pointer-sign -Wno-unused-but-set-variable -Wno-unused-function 
> > -Wno-unused-label -Wno-unused-value -Wno-unused-variable -g -O2 
> > -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> > -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
> > -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> > -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=default 
> > -MD -MQ libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o -MF 
> > libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o.d -o 
> > libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o -c 
> > ../src/libumockdev-preload.c
> > In file included from /usr/include/features.h:393,
> >  from /usr/include/assert.h:35,
> >  from ../src/libumockdev-preload.c:31:
> > /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is 
> > allowed only with _FILE_OFFSET_BITS=64"
> >26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
> >   | ^
> > 
> > 
> > I admit I don’t exactly see what’s going on here. Does it
> > maybe #unset _FILE_OFFSET_BITS or something?
> It does. src/libumockdev-preload.c:
> 
> /* override -D_FILE_OFFSET_BITS, it breaks us */
> #undef _FILE_OFFSET_BITS
> 
> This has the same roots as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065973 as this file
> says "The initial code for intercepting function calls was inspired and
> partially copied from kmod's testsuite". Maybe it can also have the same
> fix (but that bug isn't fixed yet, though it has a proposed fix).

This appears to be because umockdev is based on a LD_PRELOAD module that
interposes wrapped or mock versions of glibc functions like stat() that
are sensitive to the sizes of off_t and time_t.

I don't think the proposed fix in kmod is correct, and I don't think
an equivalent in umockdev would be correct either. Since glibc 2.34,
on 32-bit architectures all such LD_PRELOAD modules will need updating
to also wrap __lstat64_time64(), __stat64_time64(), __fstat64_time64()
and __fstatat64_time64() on architectures where they exist - otherwise,
programs and libraries compiled with 64-bit time_t will bypass the
wrapped stat(), stat64() etc. and call __stat64_time64() instead, and
therefore the wrapping will be ineffective and umockdev's mock devices
will not be seen.

fakeroot, fakechroot and other LD_PRELOAD modules that interpose stat()
will already be doing something similar, and might provide a useful
reference for what is needed. Here's the equivalent in fakechroot:
https://github.com/dex4er/fakechroot/pull/104/commits/dac74cd68cfb6eeaae9cd13bdc48737a44980df9

smcv

Bug#1065973: kmod: FTBFS due to time64 transition

[Simon McVittie]

On Thu, 21 Mar 2024 at 15:45:13 +0500, Andrey Rakhmatullin wrote:
> On Wed, Mar 13, 2024 at 08:23:07AM +0100, Helge Deller wrote:
> > The patch below builds for me on the hppa platform.
> Unfortunately tests fail here with it in an armhf chroot, I don't know if
> it's generic or because the chroot is a qemu-based one on amd64.

I think the root cause (both for needing to unset _FILE_OFFSET_BITS, and
for the tests failing) is that kmod's test suite is interposing
mock/wrapped versions of the stat() family.

With the transition to 64-bit time_t, there are new members of the stat()
family that will also need interposing on 32-bit architectures:
__lstat64_time64() is the replacement for lstat(), and __stat64_time64()
for stat().

There are also __fstat64_time64() and __fstatat64_time64(), but kmod
doesn't seem to interpose fstat() or fstatat(), so those are probably
unnecessary in this case.

fakeroot, fakechroot and other LD_PRELOAD modules that interpose stat()
will already be doing something similar, and might provide a useful
reference for what is needed. Here's the equivalent in fakechroot:
https://github.com/dex4er/fakechroot/pull/104/commits/dac74cd68cfb6eeaae9cd13bdc48737a44980df9

smcv

Bug#1066797: gstreamer1.0: FTBFS: tests/check/libs/gstharness.c: Received signal 11 (Segmentation fault)

[Simon McVittie]

Control: retitle -1 gstreamer1.0: FTBFS: tests/check/libs/gstharness.c: 
Received signal 11 (Segmentation fault)

On Wed, 13 Mar 2024 at 16:11:03 +0100, Lucas Nussbaum wrote:
> gstreamer1.0: FTBFS: gst-validate-1.0 Failed to execute child process
> ?gst-validate-1.0? (No such file or directory)

This is not the reason for failure: the test that wanted to run
gst-validate-1.0 detects that it was not found, and is skipped harmlessly.
The only actual failure in Lucas' build log appears to be this one:

> === 87/109 ===
> test: libs_gstharness
> start time:   20:20:23
> duration: 1.46s
> result:   exit status 2
> command:  
> LD_LIBRARY_PATH=/<>/obj-x86_64-linux-gnu/gst:/<>/obj-x86_64-linux-gnu/libs/gst/base:/<>/obj-x86_64-linux-gnu/libs/gst/controller:/<>/obj-x86_64-linux-gnu/libs/gst/check:/<>/obj-x86_64-linux-gnu/libs/gst/net
>  ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> GST_PLUGIN_SCANNER_1_0=/<>/obj-x86_64-linux-gnu/libs/gst/helpers/gst-plugin-scanner
>  GST_PLUGIN_LOADING_WHITELIST=gstreamer 
> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  MALLOC_PERTURB_=129 GST_PLUGIN_SYSTEM_PATH_1_0='' 
> GST_REGISTRY=/<>/obj-x86_64-linux-gnu/tests/check/libs_gstharness.registry
>  CK_DEFAULT_TIMEOUT=20 GST_STATE_IGNORE_ELEMENTS='' 
> GST_PLUGIN_PATH_1_0=/<>/obj-x86_64-linux-gnu 
> /<>/obj-x86_64-linux-gnu/tests/check/libs_gstharness
> --- stdout ---
> Running suite(s): GstHarness
> 75%: Checks: 8, Failures: 0, Errors: 2
> ../tests/check/libs/gstharness.c:157:E:harness:test_forward_event_and_query_to_sink_harness_while_teardown:0:
>  (after this point) Received signal 11 (Segmentation fault)
> ../tests/check/libs/gstharness.c:200:E:harness:test_forward_sticky_events_to_sink_harness_while_teardown:0:
>  (after this point) Received signal 11 (Segmentation fault)
> Check suite gst_harness ran in 1.346s (tests failed: 2)
> ==

I hope that this helps a GStreamer developer to identify what is wrong here.

smcv

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

On Tue, 19 Mar 2024 at 22:55:31 +0100, Matthias Klumpp wrote:
> Am Di., 19. März 2024 um 22:25 Uhr schrieb Simon McVittie :
> > Yes, the library is renamed on all architectures. (On architectures where
> > the ABI didn't actually break, like amd64, it Provides the old name.)
>
> So, in that case the most straightforward way to fix this would just
> be to rename the dependency to libgtk-3-0t64?

Yes, that'll be the simplest approach.

smcv

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

On Tue, 19 Mar 2024 at 22:14:12 +0100, Matthias Klumpp wrote:
> Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> > libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> > to be replaced by libgtk-3-0t64 after checking that the functions that
> > interact with time_t (methods of GtkRecentInfo) are handled correctly.
> 
> Will this be the new name on all platforms?

Yes, the library is renamed on all architectures. (On architectures where
the ABI didn't actually break, like amd64, it Provides the old name.)

The same is true for essentially all of the libraries involved in this
transition: there are hundreds of them.

> Annoyingly, libgtkd does not depend on
> libgtk properly on its own via linking it, and instead will dlopen it
> at runtime.

One way I've sometimes seen this handled is by making a list of the
SONAMEs that will be dlopen'd, linking them into a dummy C executable
with -Wl,--no-as-needed, and letting dpkg-shlibdeps inspect that executable
and generate dependencies.

smcv

Bug#1067193: meld: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: meld
Version: 3.22.1-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

meld is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtksource-4 and gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0, and replace it
with gir1.2-gtk-3.0 if appropriate. For Python code that uses GTK via
GObject-Introspection, it is sufficient to depend on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067192: gtk-d: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Source: gtk-d
Version: 3.10.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
to be replaced by libgtk-3-0t64 after checking that the functions that
interact with time_t (methods of GtkRecentInfo) are handled correctly.

There might be other library dependencies in a similar situation: I suggest
using this bug report to represent all of them, rather than having multiple
bugs to track this.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067191: gnome-subtitles: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: gnome-subtitles
Version: 1.8-1
Severity: serious
Justification: 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t

gnome-subtitles has a hard-coded dependency on libgtk-3-0, which needs to
be replaced with libgtk-3-0t64 as part of the 64-bit time_t transition.
When doing this, please check that it doesn't call any functions from
GTK that take a time_t argument or return a time_t (the affected methods
all involve GtkRecentInfo, please see
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-26T12%3A07%3A00/compat_reports/libgtk-3-dev/lfs_to_time_t/compat_report.html
for full details).

This is mostly a theoretical concern because gnome-subtitles is already
excluded from testing as a result of an unrelated RC bug #1053529.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067190: timekpr-next: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: timekpr-next
Version: 0.5.4-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

timekpr-next is an Architecture: all package, but has a direct dependency
on libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067189: syncthing-gtk: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: syncthing-gtk
Version: 0.9.4.4+ds+git20221205+12a9702d29ab-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

syncthing-gtk is an Architecture: all package, but has a direct dependency
on libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067175: exaile: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: exaile
Version: 4.1.3+dfsg-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

exaile is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067174: cpupower-gui: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: cpupower-gui
Version: 0.7.2-2.1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t

cpupower-gui is an Architecture: all package, but has a direct dependency
on libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

(This is mostly a theoretical concern because cpupower-gui is already
excluded from testing as a result of an unrelated RC bug #102.)

More information about this transition is available on
.

Thanks,
smcv

Bug#1067173: clearlooks-phenix-theme: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: clearlooks-phenix-theme
Version: 7.0.1-3
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t

clearlooks-phenix-theme is an Architecture: all package, but has a
direct (versioned) dependency on libgtk-3-0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is going to become an impossible dependency,
because libgtk-3-0 and libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0, or swap it for
libgtk-3-0t64. Perhaps it could become a Recommends: libgtk-3-0t64,
Breaks: libgtk-3-0 (<< 3.20)?

(This is mainly a theoretical concern because clearlooks-phenix-theme
was removed from testing as a result of an unrelated RC bug.)

Thanks,
smcv

Bug#1067171: bleachbit: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: bleachbit
Version: 4.6.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

bleachbit is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067170: 0install: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: 0install
Version: 2.18-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

Versions of 0install that have been rebuilt for the 64-bit time_t
transition (for example on amd64) have dependencies on both libgtk-3-0
and libgtk-3-0t64. On the architectures where the ABI transition took
place (for example armel and armhf) this will be an impossible dependency.

It looks as though 0install is correctly picking up a dependency on GTK
from ${shlibs:Depends}, so please remove the explicit dependency on
libgtk-3-0.

Thanks,
smcv

Bug#1066032: marked as pending in gobject-introspection

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


Add patches from upstream git to fix handling of time_t and off_t

Closes: #1066032


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066032

Bug#1066032: marked as pending in gobject-introspection

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


Add patches from upstream git to fix handling of time_t and off_t

Closes: #1066032


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066032

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

[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#1061703: marked as pending in gnome-characters

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/gnome-team/gnome-characters/-/commit/04fb8b2309a41d79d6fa586870b53e70c54965bf


d/control: gjs is needed at build-time even if not running tests

This source package only has one binary package, and it requires gjs,
so there would be no benefit to adjusting the upstream build system to
be able to build without gjs present.

Closes: #1061703


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1061703

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

[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

[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

[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#1066306: marked as pending in gmpc-plugins

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/mpd-team/gmpc-plugins/-/commit/4cb2a4b9369fb3f29c00cd51f468e9d854c77705


Add patch to fix implicit declarations that caused FTBFS

Closes: #1066306


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066306

Bug#1066611: marked as pending in gmpc

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/mpd-team/gmpc/-/commit/f75c68077d5ab7de53e01c0b736b64c0736aaa07


Add patch to fix missing declaration for main_window_add_status_icon()

Closes: #1066611


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066611

Bug#1066904: marked as pending in glib2.0

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/gnome-team/glib/-/commit/22ad69bf8f1470d36b4fd99442470cc1dfd3c74f


Use host-architecture gi-compile-repository, etc. when cross-compiling

When setting up the cross wrappers for gi-compile-repository, etc. I had
assumed that gi-compile-repository was a simple transformation from
GIR XML into binary, which varied only by its endianness. Unfortunately,
it is not: it also transforms abstract types such as size_t into
equivalent fixed-size types such as guint64, which requires knowledge
of the size of each type.

Instead of running the build architecture gi-compile-repository and
telling it to use the host architecture search path, install upstream's
gi-compile-repository etc. into ${pkglibdir}, and set up cross wrappers
that will automatically detect whether we can run them directly or
whether we must use qemu-user. This is not "pure" cross-compilation,
but it's the best we can do.

This means that the build and host OS must match, but it does have the
side benefit that we no longer require the build and host endianness to
be the same, because everything that interacts the typelib is now a
host binary (possibly running under qemu).

Closes: #1066904


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066904

Bug#1066900: marked as pending in gobject-introspection

[Simon McVittie]

Control: tag -1 pending

Hello,

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

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


Use host-architecture g-ir-compiler, etc. when cross-compiling

When setting up the cross wrappers for g-ir-compiler, etc. I had
assumed that g-ir-compiler was a simple transformation from
GIR XML into binary, which varied only by its endianness. Unfortunately,
it is not: it also transforms abstract types such as size_t into
equivalent fixed-size types such as guint64, which requires knowledge
of the size of each type.

Instead of running the build architecture g-ir-compiler and
telling it to use the host architecture search path, install upstream's
g-ir-compiler etc. into ${pkglibdir}, and set up cross wrappers
that will automatically detect whether we can run them directly or
whether we must use qemu-user. We already had logic for this for the
dumper executable that is run by g-ir-scanner, which is always a
host-architecture binary.

This involves running qemu more often, but does have the side benefit
that we no longer require the build and host endianness to be the same,
because everything that interacts the typelib is now a host binary
(possibly running under emulation).

Closes: #1066900


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066900

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

[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

[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#1064707: devscripts: FTBFS: AssertionError: black found code that needs reformatting:

[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#1066032: pygobject: FTBFS on armhf: time_t build test failure

[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’

[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

[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#1065821: librsvg: FTBFS: rtl-tspan: 2655 pixels changed with maximum difference of 112

[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

[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'

[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#1062969: doomsday: launching doomsday (2.3.1+ds1-1+b2) causes segfault in libsdl2-2.0-0 (2.30.0+dfsg-1)

[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#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[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#1065494: marked as pending in gtk+3.0

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/gnome-team/gtk3/-/commit/1c4fb7e79ab1d3c28a957b777e692afa09afdc52


d/libgtk-3-0t64.preinst: Remove libgtk-3-0 postrm to avoid file loss

During the migration from libgtk-3-0 to libgtk-3-0t64, the package
that is responsible for "owning" /usr/lib/*/gtk-3.0/3.0.0/immodules.cache
changed from libgtk-3-0 to libgtk-3-0t64. Because dpkg does not have an
equivalent of RPM's %ghost files, the ownership of this file is managed
by social convention rather than by the package management system.

Unfortunately, libgtk-3-0's postrm as shipped in Debian releases from
2010 to the present is not aware of the possibility that another binary
package might need to take over responsibility for this file, and so
will remove it during purge (and in fact also during upgrades) in
accordance with the requirement that the package must not leave unowned
files behind. This causes input methods to be non-functional in GTK apps
until the next time the gtk-query-immodules-3.0 trigger happens to be run.

To disarm the problematic maintainer script, delete it during the new
package's preinst, similar to what was done for GLib in response
to #1065022.

A subsequent commit will improve the postrm so that if we find that we
need to migrate from libgtk-3-0t64 to libgtk-3-0xyz at some point in
the future, similar efforts will not be needed.

Closes: #1065494


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065494

Bug#1065493: marked as pending in gtk+2.0

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/gnome-team/gtk2/-/commit/3406805d5833fc78ccab4c1aaff3cbc9e9197799


d/libgtk2.0-0t64.preinst: Remove libgtk2.0-0 postrm to avoid file loss

During the migration from libgtk2.0-0 to libgtk2.0-0t64, the package
that is responsible for "owning" /usr/lib/*/gtk-2.0/2.10.0/immodules.cache
changed from libgtk2.0-0 to libgtk2.0-0t64. Because dpkg does not have an
equivalent of RPM's %ghost files, the ownership of this file is managed
by social convention rather than by the package management system.

Unfortunately, libgtk2.0-0's postrm as shipped in Debian releases from
2010 to the present is not aware of the possibility that another binary
package might need to take over responsibility for this file, and so
will remove it during purge (and in fact also during upgrades) in
accordance with the requirement that the package must not leave unowned
files behind. This causes input methods to be non-functional in GTK apps
until the next time the gtk-query-immodules-2.0 trigger happens to be run.

To disarm the problematic maintainer script, delete it during the new
package's preinst, similar to what was done for GLib in response
to #1065022.

A subsequent commit will improve the postrm so that if we find that we
need to migrate from libgtk2.0-0t64 to libgtk2.0-0xyz at some point in
the future, similar efforts will not be needed.

Closes: #1065493


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065493

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

[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#1065022: marked as pending in glib2.0

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/gnome-team/glib/-/commit/451ed4fd133f4cac0b1530cbba2a63a18c6543e1


d/libglib2.0-0t64.preinst: Remove libglib2.0-0 postrm to avoid file loss

During the migration from libglib2.0-0 to libglib2.0-0t64, the package
that is responsible for "owning" /usr/lib/*/gio/modules/giomodule.cache
and /usr/share/glib-2.0/schemas/gschemas.compiled changed from
libglib2.0-0 to libglib2.0-0t64. Because dpkg does not have an equivalent
of RPM's %ghost files, the ownership of these files is managed by social
convention rather than by the package management system.

Unfortunately, libglib2.0-0's postrm as shipped in Debian releases from
2010 to the present is not aware of the possibility that another binary
package might need to take over responsibility for those files, and so
will remove both files during purge (and giomodules.cache also during
remove) in accordance with the requirement that installing and then
removing and purging a package must not leave unowned files behind.
This causes most applications that depend on GSettings schemas to crash
with an assertion failure, until the next time the glib-compile-schemas
trigger happens to be run; it will also cause functionality loss for
applications that depend on GIO modules.

To disarm the problematic maintainer script, delete it during the new
package's preinst. This is (probably) a Policy violation, but seems like
the least-bad exit strategy from the unacceptable situation we have
found ourselves in.

A subsequent commit will improve the postrm so that if we find that we
need to migrate from libglib2.0-0t64 to libglib2.0-0xyz or libglib-2.0-0
at some point in the future, similar efforts will not be needed.

Closes: #1065022


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065022

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

[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#1065022: libglib2.0-0t64: transition from libglib2.0-0 breaks GSettings, GIO modules

[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

[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

[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

[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

[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

[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: marked as pending in libproxy

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/gnome-team/libproxy/-/commit/302ee018ae76b179b7a9d3ea7acbb4a682104fbb


Add back transitional packages for the plugins

These provide smooth upgrades from Debian 12 and Ubuntu 22.04, and
should be removed after Debian 13 and Ubuntu 24.04 are released.

Closes: #1064889


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1064889

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

[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#1064704: gtk4: FTBFS: one run of gtk:tools / validate test failed

[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#1064369: gobject-introspection dropped versioned dependency on python3

[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

[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#1064042: marked as pending in gsettings-desktop-schemas

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/gnome-team/gsettings-desktop-schemas/-/commit/3f422e6291950a881d1c7d0b9e5f538323a0c572


Revert locale-sensitive default for 12h/24h clock format

This was intended to change the default to 12h for American English,
but had the side-effect of changing the default for all locales that
have not specifically chosen 24h (like British English), and also for
locales that are not supported by gsettings-desktop-schemas
(like for example Welsh). Revert the change entirely for now, while we
discuss a better way to get the desired effect.

Closes: #1064042
Reopens: GNOME/gsettings-desktop-schemas#30 upstream


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1064042

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

[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

[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#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el

[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: marked as pending in mozjs

[Simon McVittie]

Control: tag -1 pending

Hello,

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

https://salsa.debian.org/gnome-team/mozjs/-/commit/c099d1d6251023ab44361e995f5b04cd798a45a8


Add a patch to fix linking of gjs (>= 1.78.3)

Closes: #1063446


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1063446

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

[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

[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)

[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

[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)

[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#1061884: allegro4.4: NMU diff for 64-bit time_t transition

[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 +

Bug#1061015: pygame-sdl2: FTBFS: Cannot assign type 'Sint64 (SDL_RWops *) except? -1 nogil' to 'Sint64 (*)(SDL_RWops *) noexcept'

[Simon McVittie]

On Sun, 28 Jan 2024 at 22:49:37 +0100, Alexandre Detiste wrote:
> Le jeu. 25 janv. 2024 à 11:15, Simon McVittie  a écrit :
> > I also don't understand where these new upstream releases are coming from,
> > because https://github.com/renpy/pygame_sdl2 only has tags for 8.1.0,
> > and there don't seem to be any recent commits that are relevant to
> > cython3 compatibility.
> 
> The release are coming from here.
> https://www.renpy.org/latest.html

Oh, do those tarball code-drops have changes that are newer than what's
in https://github.com/renpy/pygame_sdl2 git?

> pygame-sdl2 state (which is a very old fork of pygame) is in limbo,
> upstream is considering vendoring it inside the main tarball
> it is maybe already maintained in the main git three.

I see. Do I understand correctly that we would consider it to be a bug
for anything other than renpy to use pygame-sdl2?

If so, I think if I was the Debian maintainer of these packages,
I'd be very tempted to vendor pygame-sdl2 into renpy (using dpkg's
multiple-.orig-tarballs feature if upstream have not done similar
vendoring) so that there's only one Debian source package to keep track
of, and no possibility of version skew between renpy and its pygame fork.

smcv

Bug#1061015: pygame-sdl2: FTBFS: Cannot assign type 'Sint64 (SDL_RWops *) except? -1 nogil' to 'Sint64 (*)(SDL_RWops *) noexcept'

[Simon McVittie]

Control: affects -1 + src:renpy

On Tue, 16 Jan 2024 at 20:43:34 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > src/pygame_sdl2/rwobject.pyx:336:22: Cannot assign type 'Sint64 (SDL_RWops 
> > *) except? -1 nogil' to 'Sint64 (*)(SDL_RWops *) noexcept'. Exception 
> > values are incompatible. Suggest adding 'noexcept' to type 'Sint64 
> > (SDL_RWops *) except? -1 nogil'.

This looks like probably a regression with cython 3.x, which has this
in its release notes:

Cython-implemented C functions now propagate exceptions by default,
rather than swallowing them in non-object returning function if the
user forgot to add an except declaration to the signature. This was
a long-standing source of bugs, but can require adding the noexcept
declaration to existing functions if exception propagation is really
undesired. (Github issue #4280)

...

To opt out of the new, safer exception handling behaviour, legacy
code can set the new directive legacy_implicit_noexcept=True for
a transition period to keep the previous, unsafe behaviour. This
directive will eventually be removed in a later release.

References: ,
.

The changelog for pygame-sdl2 8.1.3-1 says the new upstream release is
compatible with cython3, but that doesn't seem to be the case? But I
also don't understand where these new upstream releases are coming from,
because https://github.com/renpy/pygame_sdl2 only has tags for 8.1.0,
and there don't seem to be any recent commits that are relevant to
cython3 compatibility.

smcv

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

[Simon McVittie]

Control: retitle -1 xdg-desktop-portal: FTBFS: test_inputcapture: Timed out 
waiting for response from SetPointerBarriers
Control: tags -1 + unreproducible

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.

smcv

Bug#1060994: libshumate: FTBFS: Couldn't find include 'GObject-2.0.gir'

[Simon McVittie]

Control: retitle -1 libshumate: FTBFS: Couldn't find include 'GObject-2.0.gir'

On Tue, 16 Jan 2024 at 20:43:20 +0100, Lucas Nussbaum wrote:
> > Couldn't find include 'GObject-2.0.gir' (search path: 
> > '['/usr/share/gir-1.0', '/usr/lib/x86_64-linux-gnu/gir-1.0', 
> > '/<>/debian/.debhelper/generated/_source/home/.local/share/gir-1.0',
> >  'gir-1.0', '/usr/local/share/gir-1.0', '/usr/share/gir-1.0', 
> > '/usr/lib/x86_64-linux-gnu/gir-1.0', '/usr/share/gir-1.0', 
> > '/usr/share/gir-1.0']')

This is collateral damage from me removing an unnecessary dependency in
src:graphene, which previously pulled in an unwanted dependency chain
that included libgirepository1.0-dev.

Historically, packages that processed GIR XML needed to build-depend on
libgirepository1.0-dev. As of this week, it's better to build-depend on
gobject-introspection and the individual GIR XML packages that are needed,
which opens the way for being cross-compilable in future.

smcv

Bug#1060779: src:mesa: fails to migrate to testing for too long: unavailable Build-Depends on mips64el

[Simon McVittie]

On Sun, 14 Jan 2024 at 08:39:52 +0100, Paul Gevers wrote:
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:mesa has been trying to migrate for 31 days [2].
> Hence, I am filing this bug. The version in unstable build depends on
> binaries from llvm-toolchain-17, which haven't been built on mips64el yet
> (reported in bug 1056116).

Adding mips64el porting team to Cc for visibility.

Mesa could probably work around this by disabling the LLVM parts on
mips64el (removing mips64 from LLVM_ARCHS in d/rules and from various
lists of LLVM-capable architectures in d/control).

The cost would be that most mips64el users would have to use slow
fallback software rendering, because disabling LLVM support would
disable llvmpipe (which it seems doesn't actually work properly
on mips* in any case) but also the AMD driver (which is what
graphical MIPS users rely on in practice, according to discussion on
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71).

That's a high cost for mips64el users, but the alternative seems to be
letting mips64el hold back all of our other architectures, and I don't
think that's really viable.

Thanks,
smcv

Bug#1060849: mesa: FTBFS on armel: static assertion failed: "vn_ring_shared requires lock-free 32-bit atomic_uint"

[Simon McVittie]

Source: mesa
Version: 23.3.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: armel
Control: block 1060779 by -1

The armel baseline does not have lock-free atomic operation opcodes. The
result is a build failure:

https://buildd.debian.org/status/fetch.php?pkg=mesa=armel=23.3.3-1=1705055313=0
> In file included from ../src/util/u_math.h:43,
>  from ../src/virtio/vulkan/vn_common.h:35,
>  from ../src/virtio/vulkan/vn_buffer.h:14,
>  from ../src/virtio/vulkan/vn_buffer.c:11:
> ../src/virtio/vulkan/vn_ring.h:40:1: error: static assertion failed: 
> "vn_ring_shared requires lock-free 32-bit atomic_uint"
>40 | static_assert(ATOMIC_INT_LOCK_FREE == 2 && sizeof(atomic_uint) == 4,

Could this perhaps be solved by disabling the virtio driver on armel?

Thanks,
smcv

Bug#1060735: glib2.0/experimental: FTBFS on s390x and other 64-bit BE: gdatetime test fails or crashes

[Simon McVittie]

Control: severity -1 important

On Sat, 13 Jan 2024 at 19:32:58 +, Simon McVittie wrote:
> On Sat, 13 Jan 2024 at 16:21:46 +0000, Simon McVittie wrote:
> > On Sat, 13 Jan 2024 at 15:21:02 +0000, Simon McVittie wrote:
> > > I recently uploaded a snapshot of GLib 2.79.x to experimental (in
> > > preparation for NEW processing) and it failed tests on s390x and on
> > > the 64-bit, big-endian ports ppc64 and sparc64. I suspect this means
> > > it's a general problem with 64-bit BE, rather than specifically s390x.
> > 
> > git bisect says commit df4aea76 "gdatetime: Add support for %E modifier
> > to g_date_time_format()" is the first bad commit, which would be consistent
> > with it being...
> > 
> > > instead
> > > of segfaulting, the test failed with an assertion error involving dates 
> > > with
> > > a Japanese era marker:
> > 
> > ... something to do with Japanese and Thai eras, and the %E modifier.
> 
> I can't see anything in the relevant commit[1] that looks like it would be
> affected by endianness. Could there be an endianness problem in one of the
> glibc APIs that it's calling into, or something like that?

I have successfully worked around this by disabling support for era-based
dates with the %E modifier (used in Japan and Thailand) on big-endian
64-bit, which reduces the severity of this bug to non-RC.

It looks as though:

- glibc documents nl_langinfo(ERA) as returning a semicolon-delimited list
  of eras

- but in fact it returns a NUL-delimited, double-NUL-terminated list of
  eras, such that parsing the list cannot be done without risking a read
  overrun, unless you either assume that the undocumented
  double-NUL-termination will be present or use the undocumented
  nl_langinfo(_NL_TIME_ERA_NUM_ENTRIES). GLib currently does the latter.

- GLib has, at least for now, prioritized its own usability for Japanese
  and Thai users higher than the design principle that it should not rely
  on undocumented APIs

- this is OK on 32-bit and on little-endian, but glibc's
  nl_langinfo(_NL_TIME_ERA_NUM_ENTRIES) returns what appears to be a
  wrong result on 64-bit big-endian architectures

Discussion in GLib: https://gitlab.gnome.org/GNOME/glib/-/issues/3225

Workaround in GLib: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3820

Related glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31030

If there is a safe way to get this information from glibc, then GLib should
use that, but I don't know what that safe way would be.

smcv