Bug#1033733: vkd3d: new upstream release 1.11

[Simon McVittie]

Control: retitle -1 vkd3d: new upstream release 1.11

On Fri, 31 Mar 2023 at 11:54:01 +0100, Simon McVittie wrote:
> On Fri, 31 Mar 2023 at 10:58:46 +0100, Simon McVittie wrote:
> > vkd3d has a new upstream release available, v1.7.

Since then there have been several more upstream releases and it is
currently at v1.11.

> > I need .deb packages of this version for a work project, so I've been
> > looking at updating the packaging used for Debian as a starting point
> > for that
> 
> Please consider merging this:

Updated version at:

https://salsa.debian.org/smcv-guest/vkd3d wip/1.11

Once again I used `uscan --download` to get the orig.tar.* I used for
test-builds.

debian/patches/fixes/byte-comparison.patch no longer applies; I dropped
it for now (and the package builds successfully in my environment), but
if it's still necessary for other build environments, it will need some
adjustment. It would be ideal if this issue could be reported upstream
and fixed there.

smcv

Bug#1071717: gnome-settings-daemon: gsd-media-keys fires D-Bus MPris PlayPause message randomly

[Simon McVittie]

On Fri, 24 May 2024 at 10:08:28 +0300, Andres Gomez Garcia wrote:
> I've some keyboard key combination mapped for doing the PlayPause
> action.
> 
> Rarely, when I'm using the headphones for other use than music, for
> example, attending a confcall, the music playback is activated
> randomly.

This is expected to happen if your headphones have a play/pause button,
their Linux kernel driver maps it as a partial keyboard, and the
headphones send the keycode for a play/pause multimedia key
(XF86AudioPlay).

Typically wireless headphones have 3 buttons which are mapped as
a partial keyboard with play/pause, volume up and volume down keys
(internally XF86AudioPlay, XF86AudioRaiseVolume, XF86AudioLowerVolume).

Depending on how your USB dongle works, it might identify itself as a
generic USB keyboard with these keys and others, in which case it would
be indistinguishable from a real keyboard; or it might identify itself
as a more specific device.

> The sender is gsd-media-keys

It sends MPRIS PlayPause in response to a keyboard event reporting either
your configured key combination, or the dedicated play/pause multimedia key.

gsd-media-keys intentionally recognises the multimedia key even if a
different keyboard key combination has also been configured, because that's
necessary to make typical Bluetooth headphones work as expected.

> Oddly enough, this happens more often when using some wireless
> headphones (no bluetooth, but with a proprietary USB dongle
> transmitter) and I'm far from the computer.

This sounds as though your USB dongle might be falsely reporting button
presses when the wireless link to the headphones is at the limits of its
range. If that's the case, then there is nothing that gsd-media-keys
will be able to do about this: it can't tell the difference between a
real button press and a spurious one.

A workaround would be to use dconf-editor or gsettings(1) to unconfigure
the static/hard-coded binding for XF86AudioPlay:

gsettings set org.gnome.settings-daemon.plugins.media-keys play-static '[]'

Please try that and see whether it avoids this problem?

This will prevent correctly-functioning wireless headphones
(e.g. Bluetooth) from controlling play/pause as they are intended to be
able to do, and will also prevent recognition of a dedicated play/pause
key that is available on some USB or wireless keyboards, so only use
that workaround long-term if that is acceptable collateral damage. You
can undo the workaround if it is no longer desirable with:

gsettings reset org.gnome.settings-daemon.plugins.media-keys play-static

I don't think the various -static bindings are configurable in the UI,
because reconfiguring them breaks intended functionality of hardware
that is working correctly.

smcv

Bug#1071373: ITS: hardinfo

[Simon Quigley]

Hello,

Firstly, I would like to thank you and others for your persistence in 
this effort. I am glad that there is interest in this package again.


My original interest in maintaining hardinfo was due to its inclusion in 
Lubuntu, prior to our switch to LXQt. It was one of the first packages I 
worked on as an "up and coming" Debian Developer, and to my 
understanding, the packaging as of 2018 was fully up to date and 
standards-compliant.


That being said, I no longer have as much interest in this package as I 
used to. Boyuan, please go ahead and take over maintainership if you are 
interested. My only request is that I stay as a co-maintainer, since 
this package has sentimental value to me.


Thank you again for your efforts. Proceed.

--
Simon Quigley
si...@tsimonq2.net
@tsimonq2:ubuntu.com on Matrix
tsimonq2 on LiberaChat and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071634: itstool: SyntaxWarnings with Python 3.12

[Simon Chopin]

Package: itstool
Version: 2.0.6-2
Severity: normal
X-Debbugs-Cc: scho...@ubuntu.com

Hi,

Since the transition to Python 3.12, it now emits SyntaxWarnings when
using unknown escape sequences, which typically happens on regexps.
itstool is impacted in its default path:

❯ itstool
/usr/bin/itstool:239: SyntaxWarning: invalid escape sequence '\s'
  if re.sub('\s+', ' ', text).strip() != '':
/usr/bin/itstool:337: SyntaxWarning: invalid escape sequence '\s'
  message = re.sub('\s+', ' ', message).strip()
/usr/bin/itstool:475: SyntaxWarning: invalid escape sequence '\s'
  return re.sub('\s+', ' ', self.locnote).strip()
/usr/bin/itstool:477: SyntaxWarning: invalid escape sequence '\s'
  return '(itstool) link: ' + re.sub('\s+', ' ', self.locnoteref).strip()
/usr/bin/itstool:891: SyntaxWarning: invalid escape sequence '\<'
  regex = re.compile('(.*) \<(.*)\>, (.*)')
/usr/bin/itstool:926: SyntaxWarning: invalid escape sequence '\s'
  if re.sub('\s+', '', prevtext) == '':
/usr/bin/itstool:1452: SyntaxWarning: invalid escape sequence '\.'
  _locale_pattern = 
re.compile('([a-zA-Z0-9-]+)(_[A-Za-z0-9]+)?(@[A-Za-z0-9]+)?(\.[A-Za-z0-9]+)?')
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2024-05-22 17:25+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

This has been reported both upstream and in Launchpad, but it seems that
upstream is somewhat unresponsive, so I think the patch posted in
https://github.com/itstool/itstool/pull/51 should be carried in Debian,
even just to reduce the amount of noise in build logs :)

I'll be posting a Salsa MR to that effect shortly.

-- System Information:
Debian Release: trixie/sid
  APT prefers noble-updates
  APT policy: (500, 'noble-updates'), (500, 'noble-security'), (500, 'noble')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-31-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages itstool depends on:
ii  python3  3.12.3-0ubuntu1
ii  python3-libxml2  2.9.14+dfsg-1.3ubuntu3

itstool recommends no packages.

itstool suggests no packages.

-- no debconf information

Bug#1071161: glib2.0 2.66.8-1+deb11u4 flagged for acceptance

[Simon McVittie]

On Mon, 20 May 2024 at 20:12:24 +, Adam D Barratt wrote:
> The upload referenced by this bug report has been flagged for acceptance
> into the proposed-updates queue for Debian bullseye.
...
> Package: glib2.0
> Version: 2.66.8-1+deb11u4
> Explanation: fix a (rare) memory leak

Thanks for reviewing this change. Please consider also accepting #1071159
into bookworm-p-u (same change, different base version) to preserve the
property that bookworm has no regressions when compared with bullseye,
which I assume is something we want to be able to treat as an invariant.

smcv

Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building

[Simon McVittie]

On Mon, 20 May 2024 at 19:45:53 +0200, Helmut Grohne wrote:
> On Fri, May 17, 2024 at 10:42:11AM +0100, Simon McVittie wrote:
> > If someone with more time available for cross-development
> > implemented the cross-exe-wrapper design that I sketched in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030223#37, then
> > gobject-introspection and libglib2.0-dev would be able to migrate to
> > depending on
> > 
> > cross-exe-wrapper | can-run-arch,
> > python3:any,
> > 
> > or for backwards-compat maybe
> > 
> > cross-exe-wrapper | can-run-arch | qemu-user | qemu-user-static,
> > python3:any,
> > 
> > and I think this would also solve the problem?
> 
> I think this is technically unsolvable on the package relation level.
> The "can-run-arch" property that you suggest here cannot technically be
> expressed by a dependency relation, because the answer depends on things
> apt doesn't know.

Oh, what I had assumed was that in most cases where there was any doubt,
the cross-exe-wrapper would have to depend on and run qemu-user (at least
after a runtime check for whether it can get away with avoiding qemu). The
cases where cross-exe-wrapper relied on direct execution instead of
qemu or equivalent would be build=foo, host=foo for all values of foo,
plus probably build=amd64, host=i386 as a common special case.

I'd been thinking of can-run-arch as an extension point that a sysadmin
could set up with equivs (for example to represent the use-case you
described where qemu-user-static is set up with binfmt_misc outside the
chroot), rather than something that would exist in the archive; I'd assumed
that cross-exe-wrapper would be the automatic interface.

Thinking more about this, though, I think the cross-exe-wrapper itself
could have the same problem that you've described in libglib2.0-dev:
on build=amd64 and (let's say) host=riscv64, if we had something like

Package: libglib2.0-dev
Architecture: riscv64
Multi-Arch: same
Depends: cross-exe-wrapper | can-run

Package: cross-exe-wrapper
Architecture: riscv64
Multi-Arch: same
Depends: cross-exe-wrapper-riscv64-linux-gnu

Package: cross-exe-wrapper-riscv64-linux-gnu
Architecture: riscv64
Multi-Arch: ???# no? foreign? allowed?
# trivial wrapper, runs binary directly

Package: cross-exe-wrapper-riscv64-linux-gnu
Architecture: amd64
Multi-Arch: foreign
Depends: qemu-user
# non-trivial wrapper, runs via qemu

then I think it would be valid (but definitely undesired!) for
apt to satisfy cross-exe-wrapper's dependency by installing
cross-exe-wrapper-riscv64-linux-gnu:riscv64, which of course we would
be unable to run. So this is another place where ideally we would like
to be able to depend on "cross-exe-wrapper-riscv64-linux-gnu:runnable"
or some similar syntax that doesn't yet exist.

>  * We cross build from amd64 to x32, but the kernel does not enable the
>x32 abi.

It's common to do that (and I believe x32 is runtime-disabled on Debian
kernels by default to limit attack surface), so I would have assumed
we'd want to make cross-exe-wrapper pull in qemu-user when build=amd64,
host=x32; but if it can avoid actually needing to run it, with a runtime
check like the ones in the cross g-i tools, then so much the better.

>  * We cross build from amd64 to m68k and have externally installed
>qemu-user-static as we mostly care about speeding up builds rather
>than doing "pure" cross builds.

In this case it would be harmless to install qemu-user into the chroot
(a bit of a waste of I/O but no real harm), and it hardly matters whether
we use the host system's qemu or the chroot's, as long as all the necessary
tools are runnable.

>  * We cross build for i386 from amd64 and disable the i386 kernel ABI
>via seccomp-bpf to simulate a QA cross build.

My inclination would be to say that's too artificial to be something
that we'd be willing to pay a price to support (the price is #1070773),
but you know better than I do.

>  * Some arm64 CPUs can run arm32, but not all.

As with x32 on amd64, the wrapper would have to pessimistically assume
that we do need qemu-user (optionally with a runtime check to shortcut
to running the binary directly if we can).

smcv

Bug#1071406: gnulib: dh_gnulib_patch: use git merge-base --is-ancestor

[Simon Josefsson]

Package: gnulib
Severity: wishlist

The current logic of dh_gnulib_patch to try each patch in a .d
sub-directory and pick one patch that applies.  It was suggested to use
a more clever method to pick the "right" patch.  One more clever
approach would be "git merge --is-ancestor" to programtically figure out
which patch to apply.

I'm opening a bug report so this idea is not forgotten, even if not
implemented now.

One concern with the --is-ancestor approach is that there is no
requirement to use gnulib from a git clone, and currently
dh_patch_gnulib works without that assumption.  This may not be an
important limitation though.

/Simon


signature.asc
Description: PGP signature

Bug#1071271: gdk-pixbuf: Consider disabling "other" image decoders as recommended upstream

[Simon McVittie]

Source: gdk-pixbuf
Version: 2.42.10+dfsg-3
Severity: important
Tags: security upstream sid trixie help
X-Debbugs-Cc: Debian Security Team , 
gkre...@packages.debian.org, xs...@packages.debian.org

In response to a security vulnerability in the essentially unmaintained
.ani decoder (CVE-2022-48622), gdk-pixbuf upstream has changed the default
set of loaders that are enabled.

Upstream's position appears to be that gdk-pixbuf should not be considered
to be secure enough for unsandboxed decoding of crafted, malicious images,
even if only the "good" loaders are enabled. At the same time, they are
attempting to mitigate CVEs by disabling the "bad" loaders.

The loaders that are still enabled by default and appear to be considered
to be basically OK are:

- .jpeg: uses libjpeg, built-in since bookworm
- .png: uses libpng, built-in since bookworm
- .tiff: uses libtiff, plugin
- .gif: local C code, plugin

.jpeg and .png are considered to be core functionality, and upstream
recommends having those loaders be built-in so they cannot accidentally
disappear (even if the plugin infrastructure is broken). We follow that
recommendation since bookworm. In older versions, they were plugins like
all the others.

.tiff and .gif are plugins, and it would be technically possible to move
them to a separate binary package if people want to do that (subject to
the usual backwards-compatibility concerns about that breaking apps that
might rely on being able to open those files with no extra dependency).

The loaders that are no longer enabled by default (the "other" loaders) are:

- .ani (Windows animated cursor)
- .bmp (Windows uncompressed bitmap)
- .icns (macOS icon, I think?)
- .ico (Windows icon)
- .pnm (historical Unix)
- .qtif (something to do with Quicktime?)
- .tga (historically used in games)
- .xbm (historical Unix)
- .xpm (historical Unix)

all of which are implemented in local C code and compiled as plugins.

For completeness, we also have several third-party loaders in Debian:

- SVG in librsvg2-common (uses librsvg)
- WebP in webp-pixbuf-loader (uses libwebp)
- HEIF in heif-gdk-pixbuf (uses libheif)
- JPEG-XL in src:jpeg-xl should ideally be enabled too (#1001786)

In Debian unstable, for now I have overridden the default and kept the
poorly-maintained loaders in gdk-pixbuf enabled. This turns out to have
been a good idea, because disabling them is known to break multiple
non-GNOME packages including gkrellm
(,
)
and xsane ().

There is active and contentious discussion upstream, for example on
,
about whether these formats should be enabled by default, disabled by
default, part of gdk-pixbuf, part of a separate source package that is
flagged as legacy, or what. There are good reasons on both sides, and
unfortunately there are people on each side who consider their reasons
to be obviously important and the other side's reasons to be obviously
unimportant.

As a result, if I take any side on this, it's likely to result in me
getting thinly-veiled accusations of incompetence from *someone*, and
I'm sorry but I do not have enough spoons to add more Debian items to
my "must feel guilty about" list; so I am not intending to enter this
fight on either side. If you feel strongly about this, please engage
with upstream; but please don't shoot the messenger, and keep in mind
that the GNOME team in Debian are doing our best to do the least-bad
thing in a situation with no good answer.

It is possible that upstream will force our hand by deleting the "other"
loaders from gdk-pixbuf, in which case it will be increasingly difficult
for us to keep them as part of the same source package downstream, even
if we think that's the best plan.

For Debian, one option would be to keep compiling the "other" loaders,
but move them to one or more separate binary packages that are not
necessarily mandatory. A technical constraint is that the loaders depend
on libgdk_pixbuf-2.0.so.0, so they must have a Depends on the package
that contains libgdk_pixbuf-2.0.so.0, and we should avoid circular
dependencies; ideally we should also avoid circular Depends/Recommends
loops, because those break the ability to autoremove.

For example we could consider this:

Package: gkrellm
Depends: libgdk-pixbuf-2.0-0, pixbufloader-xpm

Package: libgdk-pixbuf-2.0-0
# note that this cannot be stronger than Suggests without breaking
# autoremoval of unused packages
Suggests: gdk-pixbuf-other-loaders, heif-gdk-pixbuf, librsvg2-common, ...
# contains libgdk_pixbuf-2.0.so.0 only

Package: gdk-pixbuf-other-loaders
Depends: libgdk-pixbuf-2.0-0
# contains libpixbufloader-xpm.so, etc.

or this:

Package: gkrellm
Depends: libgdk-pixbuf-2.0-0

Package: 

Bug#1071265: CVE-2022-48622: memory corruption via crafted .ani files (Windows animated cursors)

[Simon McVittie]

Source: gdk-pixbuf
Version: 2.38.1+dfsg-1
Severity: important
Tags: security upstream fixed-upstream patch
X-Debbugs-Cc: Debian Security Team 
Control: fixed -1 2.42.12+dfsg-1

gdk-pixbuf has a memory corruption vulnerability leading to at least denial
of service, and possibly arbitrary code execution, when a user loads a
crafted ANI file (a Windows animated cursor) into a gdk-pixbuf-based
image viewer, thumbnailer, etc.

A mitigation is that the gdk-pixbuf-based thumbnailer used in GNOME is
sandboxed using bubblewrap.

This was fixed upstream in 2.42.12 by

(specifically the first commit "ANI: Reject files with multiple anih
chunks", but applying the other two commits would be a good idea IMO).

I uploaded 2.42.12 as a team upload from a "maintainer of last resort"
point of view, but I seem to have become a single point of failure for
too many libraries already, so I would prefer not to be the only one
who ever uploads gdk-pixbuf.

For stable updates, an uploader could either apply the security fixes
as patches, or do a 2.42.12+dfsg-0+deb12u1. If doing the latter, beware
that the new upstream release disables support for several file formats
by default (including .ani but also more common formats like .bmp)
which would be a disruptive change as discussed upstream in
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/169,
so building with -Dothers=enabled would probably be necessary.

smcv

Bug#1071182: dracut: requires changes for systemd 256; boot fails otherwise

[Simon Pilkington]

I believe this should be Severity: critical.  With the current set of packages
in unstable all it takes is one apt upgrade to instantly get an unbootable
system with no warning.

To get a working dracut I packaged version 101 of the dracut-ng fork and
included this commit as a patch:
https://github.com/dracut-ng/dracut-ng/commit/04b362d713235459cff1f370efb4cd5e36e4a358

The result produced bootable initramfs images with systemd 256-rc2 in a VM.

Regards,
Simon

Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building

[Simon McVittie]

On Fri, 17 May 2024 at 08:14:41 +0200, Helmut Grohne wrote:
> Package: libglib2.0-dev
> Version: 2.80.2-1
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> Control: affects -1 + src:tkgate
> X-Debbugs-Cc: debian-cr...@lists.debian.org
> 
> you recently added an alternative python3 to the qemu dependency. This
> is posing a challenge to cross building now, but the devil is in the
> detail.

This is happening because upstream GLib 2.80.x has taken over
the lower-level parts of the GObject-Introspection toolchain
from src:gobject-introspection. As a result, providing its full
functionality requires the ability to run host-architecture binaries
(for at least gi-compile-repository, which will eventually replace
gobject-introspection's g-ir-compiler).

In older versions, src:gobject-introspection would likely have had
the same issue; the only difference is that libglib2.0-dev affects
more packages.

As a reminder of the design here, g-ir-scanner from in the
gobject-introspection source package examines shared libraries and outputs
GIR XML, which is analogous to C headers: usually, but not always,
architecture-independent. g-ir-compiler or gi-compile-repository takes the
GIR XML and compiles it into architecture-dependent binary typelibs.
The GIR XML is used directly by some language bindings (typically at
compile-time for static languages like Rust and C++), and the typelibs are
used for others (typically at runtime for dynamic languages like Perl and
Paython).

I had initially hoped that we could wrap the build-architecture
g-ir-compiler/gi-compile-repository to compile GIR XML into typelibs,
but that was broken and caused a RC bug (#1066900), so we cannot do that.

In principle we could build one copy of gi-compile-repository per (build
architecture, host architecture) pair, like cross-compilers, but that
seems bad from a maintainabiity point of view. Upstream does not support
this use-case (and in general has little interest in cross g-i) so it
would be very easy for it to regress, it would require either GLib or
some other package to know a complete list of all interesting Debian
architectures in the same way that gcc-13-cross does, and running
g-ir-scanner fundamentally requires executing code from the host
architecture *anyway* because that's just how g-i works.

If the dependency was changed to:

something-native | qemu-user | qemu-user-static,
python3:any,

where "something-native" is any package that is either M-A: no or
M-A: allowed (but must not be M-A: foreign, and in practice is required
to be installed from a runnable architecture and not a barbarian
architecture) but is *not* Python, would that solve the problem?

Most of the obvious Essential or Build-Essential packages like base-files
are Multi-Arch: foreign, therefore not suitable for this purpose, but for
example a short-term hack version of this might be to use apt, perl or
perl-base as the something-native - because they are already installed
(and because apt is Important: yes and perl-base is Essential: yes),
hopefully apt will prefer to keep the existing version installed and take
the qemu-user alternative, in preference to attempting to crossgrade them
to a version that does not, in fact, work.

I don't know whether apt might become Multi-Arch: foreign in the future,
though. If it did, that would break our ability to use it like this.

This intersects with #1070773, in which users of amd64 + i386 multiarch
don't want to have to install qemu-user, and would prefer to have some
way to say "it's OK, my amd64 system can run i386 binaries directly".

If someone with more time available for cross-development
implemented the cross-exe-wrapper design that I sketched in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030223#37, then
gobject-introspection and libglib2.0-dev would be able to migrate to
depending on

cross-exe-wrapper | can-run-arch,
python3:any,

or for backwards-compat maybe

cross-exe-wrapper | can-run-arch | qemu-user | qemu-user-static,
python3:any,

and I think this would also solve the problem?

If that doesn't work, another option (but IMO a bad one) is that because
g-i functionality in GLib is a new feature in trixie, it would in
principle be possible to move gi-compile-repository and related tools to
a separate binary package, at the cost of breaking backwards compatibility
with older versions of trixie-as-testing (and also breaking compatibility
with Ubuntu 24.04, which would be unfortunate). We would probably need
*two* new binary packages:

- one Multi-Arch: same, analogous to gobject-introspection, to contain
  /usr/bin/$(DEB_HOST_GNU_ARCH)-gi-*, plus their implementations in a
  private directory (at the moment this is part of libglib2.0-dev);

- and one Multi-Arch: no containing the non-architecture-prefixed
  /usr/bin/gi-* which will be expected by simple non-cross-capable
  upstream scripts and build systems (at the moment this is part of
  libglib2.0-dev-bin, which is 

Bug#1070119: gnome-remote-desktop: long delay when first installing version 46.1-2, odd workaround in 46.1-3

[Simon McVittie]

On Wed, 15 May 2024 at 09:52:53 +0200, Jeremy Bícha wrote:
> I'm not happy with the performance of what I've implemented because it
> still has the 90 second delay even though gnome-remote-desktop is
> otherwise working now.

I don't think this is a debhelper or systemd bug.
I am able to reproduce it by building gnome-remote-desktop from
,
which I believe is functionally equivalent to 46.1-2 (without the
workaround of invoking sysusers and tmpfiles in the opposite order as
was done in 46.1-3, which I think is the wrong workaround and I'm honestly
not sure why it would even help).

After reproducing the issue, I can re-reproduce it like this:

sudo systemctl stop gnome-remote-desktop
sudo deluser gnome-remote-desktop
sudo rm -fr /etc/gnome-remote-desktop /var/lib/gnome-remote-desktop
sudo dpkg-reconfigure gnome-remote-desktop

If I hack /lib/systemd/system/gnome-remote-desktop.service to have
"ExecStart=/usr/bin/env G_MESSAGES_DEBUG=all ...", then I can see output
from g-r-d, indicating that systemd has successfully executed the daemon
as the target user (in other words, probably not a systemd bug). However,
the daemon fails to acquire its name on the system bus. This made me think:
what is/should be giving it permission to own that name?

The answer is that it installs a D-Bus policy fragment to allow the g-r-d
user to own the intended name. dbus has an "interest-noawait" on the
directory containing policy fragments, which is sufficient for subsequent
on-demand activation of D-Bus services, but is not sufficient to ensure
that a system service that needs to own a bus name can be run immediately
from the postinst of a package that is configured during the same apt
transaction that created the system user!

However, an "interest-await" would happen too soon: it would reload the
bus policy before gnome-remote-desktop.postinst is allowed to run, but
at that point the gnome-remote-desktop uid wouldn't exist yet, so the
policy would have to be skipped.

So I think a correct invocation sequence would go something like this:

1. sysusers: Create user
2. tmpfiles: Create home directory owned by that user
3. invoke-rc.d dbus reload, as is done in polkitd.postinst
   (or busctl call org.freedesktop.DBus /org/freedesktop/DBus \
   org.freedesktop.DBus ReloadConfig)
   (or the equivalent with dbus-send, see dbus.postinst)
4. systemctl daemon-reload
5. Start system services that run as that user

Strictly speaking the partial order is: 1 < 2 < 5, 1 < 3 < 5, 1 < 4 < 5
but steps 2, 3, 4 can be arbitrarily parallelized, I think.

polkitd currently achieves this by not using the sysusers sequence, and
instead invoking sysusers and `invoke-rc.d dbus reload` before #DEBHELPER#.

It might be better if there was a way to ask debhelper to insert the
`invoke-rc.d dbus reload` into the generated part of the postinst, such
that it will be done in the appropriate sequence.

smcv

Bug#1070473: debhelper: Run dh_installsysusers after dh_installtmpfiles

[Simon McVittie]

On Mon, 06 May 2024 at 08:05:55 +0200, Niels Thykier wrote:
> I thought the order was sysusers (to create the user) and then tmpfiles (to
> create files/directories and set ownership accordingly). In this bug report,
> the request is to have the directories first before the user is created.

The request to run tmpfiles before sysusers seems wrong to me, and I think
it should be wontfix. The directories certainly can't be successfully
created owned by the gnome-remote-desktop user before the user even
exists!

My understanding is that the sequence should be:

1. sysusers: Create user
2. tmpfiles: Create home directory owned by that user
3. systemctl daemon-reload
4. Start system services that run as that user

And if there are any systemd *user* services that rely on the tmpfiles
snippet, they will also need to be set up no earlier than step 3.

It looks as though debhelper itself, in a sufficiently new compat level,
gets this right:

$include_if_compat_X_or_newer->(14, 'dh_installsysusers'),
$include_if_compat_X_or_newer->(13, 'dh_installtmpfiles'),
$include_if_compat_X_or_newer->(11, 'dh_installsystemd'),
$include_if_compat_X_or_newer->(12, 'dh_installsystemduser'),

In older compat levels, opting-in to dh-sequence-installsysusers triggers
somewhat earlier:

insert_after('dh_install', 'dh_installsysusers');

but that seems like it should be fine too: the important thing is that
we get sysusers -> tmpfiles -> systemd{,user} in that order.

I think the *actual* bug here is that gnome-remote-desktop installs a
D-Bus policy fragment to allow the gnome-remote-desktop user to own the
org.gnome.RemoteDesktop name, but the postinst does not ensure that
the D-Bus system message bus (dbus-daemon or dbus-broker) has reloaded
its configuration before attempting to start gnome-remote-desktop.
I'll follow up to #1070119 with more details since this is not a
debhelper problem.

smcv

Bug#1071161: bullseye-pu: package glib2.0/2.66.8-1+deb11u4

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: glib...@packages.debian.org
Control: affects -1 + src:glib2.0

[ Reason ]
Fix a minor memory leak introduced by recent security updates, matching
a similar request for bookworm-pu.

[ Impact ]
In an unusual situation that I believe is very rare in practice, programs
using D-Bus via GLib will leak memory.

[ Tests ]
There is a relatively extensive test suite, which is how the leak was found
in the first place, and it still passes.

I no longer have Debian 11 on real hardware, but I tried the proposed
version briefly in a GNOME virtual machine and it still works.

[ Risks ]
Low risk. The change is small and obviously correct, already migrated
to testing, and was included in the backported security fix for Debian
10 LTS. It was discovered too late to be included with the more serious
regression fixes in Debian 12 and 11, and in any case would not have been
urgent enough to justify delaying fixes for the more serious regression.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  - this is vs. bullseye-security, I assume that's OK
  [x] the issue is verified as fixed in unstable

[ Changes ]
All changes are for this single bug fix.

[ Other info ]
I already uploaded the proposed version to bullseye-proposed-updates.

The security team did not consider this to be important enough to issue
another DSA update.
diffstat for glib2.0-2.66.8 glib2.0-2.66.8

 debian/changelog   |8 +
 debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch |   41 ++
 debian/patches/series  |1 
 gio/gdbusmessage.c |6 -
 4 files changed, 53 insertions(+), 3 deletions(-)

diff -Nru glib2.0-2.66.8/debian/changelog glib2.0-2.66.8/debian/changelog
--- glib2.0-2.66.8/debian/changelog	2024-05-08 16:25:40.0 +0100
+++ glib2.0-2.66.8/debian/changelog	2024-05-14 11:12:17.0 +0100
@@ -1,3 +1,11 @@
+glib2.0 (2.66.8-1+deb11u4) bullseye; urgency=medium
+
+  * d/p/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch:
+Add patch from upstream fixing a memory leak that can occur in
+rare situations since 2.66.8-1+deb11u2 (Closes: #1070851)
+
+ -- Simon McVittie   Tue, 14 May 2024 11:12:17 +0100
+
 glib2.0 (2.66.8-1+deb11u3) bullseye-security; urgency=high
 
   * d/p/CVE-2024-34397/gdbusconnection-Allow-name-owners-to-have-the-syntax-of-a.patch:
diff -Nru glib2.0-2.66.8/debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch glib2.0-2.66.8/debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch
--- glib2.0-2.66.8/debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch	1970-01-01 01:00:00.0 +0100
+++ glib2.0-2.66.8/debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch	2024-05-14 11:12:17.0 +0100
@@ -0,0 +1,41 @@
+From: =?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= 
+Date: Wed, 8 May 2024 22:53:51 +0200
+Subject: gdbusmessage: Clean the cached arg0 when setting the message body
+
+We're now caching arg0 but such value is not cleared when a new body is
+set as it's in the connection filter test cases where we've a leak as
+highlighted by both valgrind and leak sanitizer
+
+Origin: upstream, 2.80.3, commit:fe89e9f3cb6e0fd0dc2bd8a2d413799e1443cef1
+Bug-Debian: https://bugs.debian.org/1070851
+---
+ gio/gdbusmessage.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/gio/gdbusmessage.c b/gio/gdbusmessage.c
+index c4357cb..ffe8827 100644
+--- a/gio/gdbusmessage.c
 b/gio/gdbusmessage.c
+@@ -1127,10 +1127,12 @@ g_dbus_message_set_body (GDBusMessage  *message,
+ 
+   if (message->body != NULL)
+ g_variant_unref (message->body);
++
++  g_clear_pointer (>arg0_cache, g_variant_unref);
++
+   if (body == NULL)
+ {
+   message->body = NULL;
+-  message->arg0_cache = NULL;
+   g_dbus_message_set_signature (message, NULL);
+ }
+   else
+@@ -1144,8 +1146,6 @@ g_dbus_message_set_body (GDBusMessage  *message,
+   if (g_variant_is_of_type (message->body, G_VARIANT_TYPE_TUPLE) &&
+   g_variant_n_children (message->body) > 0)
+ message->arg0_cache = g_variant_get_child_value (message->body, 0);
+-  else
+-message->arg0_cache = NULL;
+ 
+   type_string = g_variant_get_type_string (body);
+   type_string_len = strlen (type_string);
diff -Nru glib2.0-2.66.8/debian/patches/series glib2.0-2.66.8/debian/patches/series
--- glib2.0-2.66.8/debian/patches/series	2024-05-08 16:25:40.0 +0100
+++ glib2.0-2.66.8/debian/patches/s

Bug#1071159: bookworm-pu: package glib2.0/2.74.6-2+deb12u3

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: glib...@packages.debian.org
Control: affects -1 + src:glib2.0

[ Reason ]
Fix a minor memory leak introduced by recent security updates.

[ Impact ]
In an unusual situation that I believe is very rare in practice, programs
using D-Bus via GLib will leak memory.

(Specifically, that situation is: the program allocates a GDBus message
with a non-empty body, then replaces the message body with something
different, and the original body is leaked. The only use I'm aware of
for editing messages in this way in Debian was in a hack to avoid gdm3
upgrades from jessie to stretch being unable to unlock the screensaver,
by rewriting D-Bus messages in-place, and that was removed between
stretch and buster.)

[ Tests ]
There is a relatively extensive test suite, which is how the leak was found
in the first place, and it still passes.

The proposed version is also working well to run the GNOME environment
where I'm typing this.

[ Risks ]
Low risk. The change is small and obviously correct, already migrated
to testing, and was included in the backported security fix for Debian
10 LTS. It was discovered too late to be included with the more serious
regression fixes in Debian 12 and 11, and in any case would not have been
urgent enough to justify delaying fixes for the more serious regression.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  - the debdiff is vs. bookworm-security, I assume that's OK
  [x] the issue is verified as fixed in unstable

[ Changes ]
All changes are for this single bug fix.

[ Other info ]
I already uploaded to -proposed-updates.

The security team agreed with my assessment that this is not important
enough to issue another DSA update.

Thanks,
smcv
diffstat for glib2.0-2.74.6 glib2.0-2.74.6

 debian/changelog   |8 +
 debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch |   41 ++
 debian/patches/series  |1 
 gio/gdbusmessage.c |6 -
 4 files changed, 53 insertions(+), 3 deletions(-)

diff -Nru glib2.0-2.74.6/debian/changelog glib2.0-2.74.6/debian/changelog
--- glib2.0-2.74.6/debian/changelog	2024-05-08 12:35:38.0 +0100
+++ glib2.0-2.74.6/debian/changelog	2024-05-14 11:11:32.0 +0100
@@ -1,3 +1,11 @@
+glib2.0 (2.74.6-2+deb12u3) bookworm; urgency=medium
+
+  * d/p/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch:
+Add patch from upstream fixing a memory leak that can occur in
+rare situations since 2.74.6-2+deb12u1 (Closes: #1070851)
+
+ -- Simon McVittie   Tue, 14 May 2024 11:11:32 +0100
+
 glib2.0 (2.74.6-2+deb12u2) bookworm-security; urgency=high
 
   * d/p/CVE-2024-34397/gdbusconnection-Allow-name-owners-to-have-the-syntax-of-a.patch:
diff -Nru glib2.0-2.74.6/debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch glib2.0-2.74.6/debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch
--- glib2.0-2.74.6/debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch	1970-01-01 01:00:00.0 +0100
+++ glib2.0-2.74.6/debian/patches/gdbusmessage-Clean-the-cached-arg0-when-setting-the-messa.patch	2024-05-14 11:11:32.0 +0100
@@ -0,0 +1,41 @@
+From: =?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= 
+Date: Wed, 8 May 2024 22:53:51 +0200
+Subject: gdbusmessage: Clean the cached arg0 when setting the message body
+
+We're now caching arg0 but such value is not cleared when a new body is
+set as it's in the connection filter test cases where we've a leak as
+highlighted by both valgrind and leak sanitizer
+
+Origin: upstream, 2.80.3, commit:fe89e9f3cb6e0fd0dc2bd8a2d413799e1443cef1
+Bug-Debian: https://bugs.debian.org/1070851
+---
+ gio/gdbusmessage.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/gio/gdbusmessage.c b/gio/gdbusmessage.c
+index a8656df..9e8fca7 100644
+--- a/gio/gdbusmessage.c
 b/gio/gdbusmessage.c
+@@ -1164,10 +1164,12 @@ g_dbus_message_set_body (GDBusMessage  *message,
+ 
+   if (message->body != NULL)
+ g_variant_unref (message->body);
++
++  g_clear_pointer (>arg0_cache, g_variant_unref);
++
+   if (body == NULL)
+ {
+   message->body = NULL;
+-  message->arg0_cache = NULL;
+   g_dbus_message_set_signature (message, NULL);
+ }
+   else
+@@ -1181,8 +1183,6 @@ g_dbus_message_set_body (GDBusMessage  *message,
+   if (g_variant_is_of_type (message->body, G_VARIANT_TYPE_TUPLE) &&
+   g_variant_n_children (message->body) > 0)
+ message->arg0_cache = g_variant_get_child_value (message->bo

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: 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#1070862: poppler: possibly unintended revert of t64 renames for non-main library in 24.x

[Simon McVittie]

Source: poppler
Version: 24.02.0-1
Severity: important
X-Debbugs-Cc: po...@debian.org, jeremy.bi...@canonical.com

Attempting to summarize recent discussion with _rene_ on #debian-devel:

poppler in trixie builds these libraries:

- libpoppler126t64
- libpoppler-glib8t64
- libpoppler-qt5-1t64
- libpoppler-qt6-3t64
- libpoppler-cpp0t64

It is not obvious to me whether the -glib, -qt, -cpp libraries genuinely
broke their ABIs during the time64 transition, or whether they were only
renamed out of an abundance of caution.

poppler in experimental and (since today) unstable builds these libraries:

- libpoppler134
- libpoppler-glib8
- libpoppler-qt5-1
- libpoppler-qt6-3
- libpoppler-cpp0v5

In other words, it correctly drops the t64 suffix from the main libpoppler
across a SONAME bump, but it also reverts the renaming of the -glib,
-qt, -cpp libraries.

Was this intentional?

If the higher-level libraries never actually broke their ABI, then renaming
them back to their Debian 12 names might be OK, but they're probably going
to need versioned Breaks/Replaces on their ...t64 names.

If the higher-level libraries *did* break their ABI, then they need to
keep the new t64 names.

Please bump this up to RC if analysis shows that it is a genuine problem,
or close it if analysis shows that I'm being overly cautious.

smcv

Bug#1070851: glib2.0: minor memory leak after fixing CVE-2024-34397

[Simon McVittie]

Source: glib2.0
Version: 2.74.6-2+deb12u1
Severity: minor
Tags: patch fixed-upstream
X-Debbugs-Cc: secur...@debian.org
Control: found -1 2.79.0+git20240110~g38f5ba3c-1
Control: found -1 2.66.8-1+deb11u2
Control: fixed -1 2.80.2-1

While applying the CVE-2024-34397 fixes to glib2.0 in (old)stable,
I backported an upstream bug fix from GLib 2.79.x to fix a possible
use-after-free, which had gone undetected in older versions, but caused
intermittent failures in the new test coverage that I added to reproduce
CVE-2024-34397.

It turns out that this bug fix is not 100% correct, and causes a rare
memory leak: if a program replaces a non-NULL message body with a different
non-NULL message body, the first argument of the old message body is leaked.
This has now been fixed upstream and will be in 2.80.3, and I backported
the fix in 2.80.2-1 (uploaded to unstable today).

My current understanding is that this will not affect
typical applications, and only applications that call
g_dbus_connection_add_filter() and use it to edit incoming or outgoing
messages in-place will normally be affected. This is not a common pattern,
and the only real-world use I'm aware of is that stretch's gdm3 had a hack
that used this to work around an incompatibility between jessie and stretch
versions' D-Bus APIs during upgrade.

This is technically a regression in a security update, so I'm cc'ing
the security team, but I imagine they will not want to update the DSA
for this. My inclination is to wait for a few days to see whether
there are any other regressions; if yes, take the opportunity to
fix this leak at the same time; and otherwise, propose an upload to
(old)stable-proposed-updates fixing the memory leak.

smcv
>From 8966099e9bef3fd3481f87bb7ad933f5cacad885 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marco=20Trevisan=20=28Trevi=C3=B1o=29?= 
Date: Wed, 8 May 2024 22:53:51 +0200
Subject: [PATCH] gdbusmessage: Clean the cached arg0 when setting the message
 body

We're now caching arg0 but such value is not cleared when a new body is
set as it's in the connection filter test cases where we've a leak as
highlighted by both valgrind and leak sanitizer
---
 gio/gdbusmessage.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gio/gdbusmessage.c b/gio/gdbusmessage.c
index 0b77dc607..331e68d45 100644
--- a/gio/gdbusmessage.c
+++ b/gio/gdbusmessage.c
@@ -1155,10 +1155,12 @@ g_dbus_message_set_body (GDBusMessage  *message,
 
   if (message->body != NULL)
 g_variant_unref (message->body);
+
+  g_clear_pointer (>arg0_cache, g_variant_unref);
+
   if (body == NULL)
 {
   message->body = NULL;
-  message->arg0_cache = NULL;
   g_dbus_message_set_signature (message, NULL);
 }
   else
@@ -1172,8 +1174,6 @@ g_dbus_message_set_body (GDBusMessage  *message,
   if (g_variant_is_of_type (message->body, G_VARIANT_TYPE_TUPLE) &&
   g_variant_n_children (message->body) > 0)
 message->arg0_cache = g_variant_get_child_value (message->body, 0);
-  else
-message->arg0_cache = NULL;
 
   type_string = g_variant_get_type_string (body);
   type_string_len = strlen (type_string);
-- 
2.39.2

Bug#1070837: gnome-shell: Last Gnome-Shell upgrade crashes logged session

[Simon McVittie]

Control: tags -1 + moreinfo

On Fri, 10 May 2024 at 12:08:27 +0200, Julien Negros wrote:
> In Bookworm last gnome-shell upgrade 43.9-0+deb12u1 -> 43.9-0+deb12u2
> closes current logged session. Same issue with Bullseye
> (3.38.6-1~deb11u1 -> 3.38.6-1~deb11u2). Doesn't look like an actual
> crash in logs : [...] But rather a GDM restart.

I did not experience this when upgrading several bookworm GNOME machines,
and one bullseye virtual machine. My GNOME session continued to run until
I rebooted the machine manually.

In general I would recommend rebooting the system anyway after installing
security updates in core library packages like libglib2.0-0, otherwise
running programs and sessions will remain vulnerable.

Are you sure you were not using some tool like checkrestart or needrestart
that detected gdm3 as a service that was affected by the security-fixed
versions of libglib2.0-0, and offered to restart it for you?

In needrestart's default configuration, it will default to not
restarting gdm3 and other known display managers (this is set up in
$nrconf{override_rc}, in /etc/needrestart/needrestart.conf), but if they
are explicitly selected to be restarted, it will assume you are aware of
the consequences and do as you ask.

I don't know whether checkrestart has similar mechanisms.

If you *do* restart gdm3, then it is probably expected that active GUI
sessions managed by gdm3 will be terminated - that's why needrestart avoids
doing this by default.

smcv

Bug#967941: nautilus: fails to generate thumbnails for h264 encoded video files

[Simon McVittie]

On Fri, 10 May 2024 at 06:14:46 +0200, Alban Browaeys wrote:
> Would adding openblas_set_num_threads(1) to totem-resource.c be fine?
> Wouldn't it add  a hard dependency to openblas on totem?

I think this would not be OK. totem cannot assume that the current
implementation of libblas.so.3 or liblapack.so.3 is openblas: it might
equally well be libatlas3-base, which presumably does not offer that
openblas-specific function.

> Should the ffmpeg or gstreamer provide an API to set this openblas
> number or thread to 1 in case the application is multi-threaded (I
> believe totem is multi-threaded) to avoid adding such hard dependency
> in the upper layers if they don't already provides such an API?

My understanding is that all GStreamer programs are automatically
multi-threaded, because GStreamer uses threads for the elements of a
pipeline.

It is not usually safe for libraries to alter process-global state at
runtime, because by the time the application calls into the library,
it might already have multiple threads running.

> until a solutoin that does not involve hardcoding low level optional
> dependencies into totem is sorted out (probably more of an upsteam
> issue), one can add "OPENBLAS_NUM_THREADS=1" to the environment of the
> totem thumbnailer.

It would be possible for affected applications like totem to work
around this bug by adding g_setenv("OPENBLAS_NUM_THREADS", "1", TRUE)
near the beginning of main(), before they have had the opportunity to
create multiple threads.

After a second thread has been created, it is no longer safe to call
g_setenv() or similar functions like setenv() and putenv(), so it really
does have to be right at the beginning of main(), and probably cannot
be in library code.

This seems like a workaround that would not scale particularly well,
because totem is far from being the only application that uses GStreamer.

smcv

Bug#1070832: option to add an RFC822 apt source

[Simon Richter]

Package: debootstrap
Version: 1.0.128+nmu2+deb12u1
Severity: wishlist
X-Debbugs-Cc: s...@debian.org

Hi,

it would be nice to allow specifying RFC822-style apt sources from local
files, both as a main mirror and as additional package sources.

For example, I have a local mirror that uses a different signing key
(because I import packages from Debian, and add a few of my own), and
I'd like to debootstrap using

debootstrap bookworm /tmp/bookworm my-mirror.sources

which would provide both the URL and the signing key to verify.

In the same vein, I have a few extra packages that use regular Debian as
a base, but have additional build dependencies that are also only in my
repository, for those I'd like to use something like

debootstrap --othermirror my-packages.sources bookworm /tmp/bookworm

And, last but not least, I sometimes need to combine these. In either
case, the signing key for that source is provided inline in the .sources
file.

   Simon

-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-21-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.20-1
ii  debian-archive-keyring  2023.3+deb12u1
ii  gnupg   2.2.40-1.1

Versions of packages debootstrap suggests:
ii  binutils2.40-2
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
ii  xz-utils5.4.1-0.2
ii  zstd1.5.4+dfsg2-5

-- no debconf information

Bug#1070826: totem: Cannot create profiling:/build direcotry errors when quitting totem (even without playback) - Debian packaging?

[Simon McVittie]

Control: reassign -1 src:libdmapsharing 3.9.13-1
Control: merge 1055324 -1
Control: found 1055324 3.9.13-2
Control: affects 1055324 + totem

On Fri, 10 May 2024 at 00:07:54 +0200, Alban Browaeys wrote:
> When I open totem then quit it (whatver I dod inside totem even if I do
> nothing), I get this error output on the console.
> It might well be a libdmapsharing library or plugin issue.
...
> profiling:/build:Cannot create directory
> profiling:/build/reproducible-path/libdmapsharing-3.9.13/libdmapsharing/.libs/libdmapsharing_4_0_la-gst-util.gcda:Skip

As the path used suggests, this is a libdmapsharing packaging issue,
see #1055324.

smcv

Bug#1070773: libglib2.0-dev:i386 on amd64 should not require qemu-user

[Simon McVittie]

Control: retitle -1 libglib2.0-dev:i386 on amd64 should not require qemu-user
Control: severity -1 wishlist
Control: tags -1 + help

On Wed, 08 May 2024 at 23:32:03 +0100, Simon McVittie wrote:
> > So, I now have to install qemu-user as dependency, which comes with a few 
> > other
> > heavy dependencies. Is this really needed, and how does that help at all?
> 
> For the special case of i386 on an amd64 system, qemu is usually not
> actually needed because amd64 systems can nearly always run i386 binaries
> directly (although I believe there are kernel configurations that will
> not allow that), but it's not obvious how to express that conditional
> dependency in apt syntax.
> 
> Tested patches welcome

Retitling the bug to reflect this.

smcv

Bug#1070792: flatpak: flaky autopkgtest on amd64: test-summaries: File 'httpd-log' doesn't match regexp

[Simon McVittie]

Source: flatpak
Version: 1.14.8-1
Severity: important
Tags: help upstream
User: debian...@lists.debian.org
Usertags: flaky
X-Debbugs-Cc: debian...@lists.debian.org
Control: affects -1 + src:glib2.0
Control: found -1 1.4.6-1

One of the tests in Flatpak's extensive test-suite appears to be "flaky":
that is, it usually passes, but is not completely reliable.

This means that when packages that are depended on by the test suite, such
as the glib2.0 security fix currently in unstable, are trying to migrate
to testing, the test will randomly pass or fail, causing those packages
to be detected as having caused a regression when in fact they have not.

For example see
https://ci.debian.net/packages/f/flatpak/unstable/amd64/46118904/
(while testing a new systemd from experimental),
https://ci.debian.net/packages/f/flatpak/testing/amd64/46456176/
(while testing a new glib2.0) and
https://ci.debian.net/packages/f/flatpak/unstable/amd64/45863529/
(while testing a new glib2.0 from experimental).

I suspect this is a race condition in the test, rather than a result of
a change immediately before one of those runs. This appears to happen
rather rarely.

The failure mode is that one of several instantiations of test-summaries.sh
(which is run multiple times with different options, and I have never seen
more than one of its runs per test fail) will fail like this:

378s ++ assert_not_file_has_content httpd-log 
summaries/cb09c0ee49abd2a14a6a556463d4cf696e5f58a2341112c612ea533ac18531f9.gz
378s ++ assert_file_has_content httpd-log 
summaries/7d82d86befacc5608749cb851a2deaa04156345146dbfd8970b6ff97a321db23-cb09c0ee49abd2a14a6a556463d4cf696e5f58a2341112c612ea533ac18531f9.delta
378s File 'httpd-log' doesn't match regexp 
'summaries/7d82d86befacc5608749cb851a2deaa04156345146dbfd8970b6ff97a321db23-cb09c0ee49abd2a14a6a556463d4cf696e5f58a2341112c612ea533ac18531f9.delta'
 at test-summaries.sh:258
378s OK closing connection
378s fusermount: entry for /tmp/test-flatpak-0Wl0GX/runtime/doc not found in 
/etc/mtab
378s 127.0.0.1 - - [09/May/2024 00:24:18] "GET 
/test/summaries/7d82d86befacc5608749cb851a2deaa04156345146dbfd8970b6ff97a321db23-cb09c0ee49abd2a14a6a556463d4cf696e5f58a2341112c612ea533ac18531f9.delta
 HTTP/1.1" 200 -
378s FAIL: Flatpak/test-summar...@system.wrap.test (Child process exited with 
code 1)

This is fairly obviously a race condition: the desired request does get
written to the web server log, but not until after the test script has
checked for it, not found it, and made the test fail. The test probably
needs to loop until the desired output is seen in the log, or make some
other distinctive request as a marker and loop until that request is
seen in the log.

I am aware that, in practice, I am this package's only uploader, so this
is in some sense my fault, and the community will presumably now demand
that I drop everything and fix it. I do not have the bandwidth to be
the single point of failure for the various things that I have ended up
responsible for, and I would very much appreciate it if other contributors
could help to improve the reliability of this test suite upstream.

smcv

Bug#1070790: fwupd: flaky autopkgtest on arm64: fwupd/fwupdmgr-p2p.test: The connection is closed

[Simon McVittie]

Source: fwupd
Version: 1.9.19-1
Severity: important
User: debian...@lists.debian.org
Usertags: flaky
X-Debbugs-Cc: debian...@lists.debian.org
Control: affects -1 + src:glib2.0
Control: found -1 1.9.16-1

fwupd appears to have a "flaky" autopkgtest: that is, an autopkgtest
that usually passes, but is not reliable.

This means that when packages that are depended on by the test suite, such
as the glib2.0 security fix currently in unstable, are trying to migrate
to testing, the test will randomly pass or fail, causing those packages
to be detected as having caused a regression when in fact they have not.

For example see
https://ci.debian.net/packages/f/fwupd/testing/arm64/46456704/
(while testing a new glib2.0),
https://ci.debian.net/packages/f/fwupd/testing/arm64/46242873/
(while testing a new sqlite) and
https://ci.debian.net/packages/f/fwupd/testing/s390x/46251882/
(while testing a new fwupd).

I suspect this is a race condition in the test, rather than a result of
a change immediately before one of those runs. This appears to happen
rarely on arm64, very rarely on s390x, and in practice never on amd64 -
which again makes me think that timing is involved.

"The connection is closed" is the error message used by GLib's GDBus when
a D-Bus connection is closed with D-Bus method calls still "in-flight",
or when the D-Bus connection is flushed or closed or an attempt is made
to send a message after it is already closed.

Perhaps this test closes a D-Bus connection during teardown, and there is
a race condition in which it might or might not have finished doing other
things on that connection before that point?

If this test or this feature cannot be made fully reliable, one option
is to skip it in debian/tests/ci, and re-run it in a separate
autopkgtest script that is marked as "Restrictions: flaky". A few GNOME
packages use the convention that flaky tests are marked like this:

@unittest.skipIf('DEB_ALLOW_FLAKY_TESTS' not in os.environ, 
'https://bugs.debian.org/123456')
def test_something_flaky(...):
...

(or the equivalent in other languages) so that they are normally skipped,
but we can force them to be run (to assess whether they are still a
problem!) by using "export DEB_ALLOW_FLAKY_TESTS=1".

smcv

Bug#1070789: clevis: flaky autopkgtest: bind(6, {AF=10 [0000:0000:0000:0000:0000:0000:0000:0000]:53140}, 28): Address already in use

[Simon McVittie]

Source: clevis
Version: 20-1
Severity: important
User: debian...@lists.debian.org
Usertags: flaky
X-Debbugs-Cc: debian...@lists.debian.org
Control: affects -1 + src:glib2.0

clevis appears to have a "flaky" autopkgtest: that is, an autopkgtest
that usually passes, but is not reliable.

This means that when packages that are depended on by the test suite, such
as the glib2.0 security fix currently in unstable, are trying to migrate
to testing, the test will randomly pass or fail, causing those packages
to be detected as having caused a regression when in fact they have not.

For example see
https://ci.debian.net/packages/c/clevis/testing/amd64/46456138/
(while testing a new glib2.0) and
https://ci.debian.net/packages/c/clevis/testing/amd64/46260455/
(while testing a new glibc).

I suspect this is a race condition in the test (perhaps starting a new
server before the previous server has been cleaned up?) rather than
genuinely being a regression in glib2.0 or glibc.

If this test or this feature cannot be made fully reliable, one option
is to skip it in debian/tests/unittests, and re-run it in a separate
autopkgtest script that is marked as "Restrictions: flaky". A few GNOME
packages use the convention that flaky tests are marked like this:

@unittest.skipIf('DEB_ALLOW_FLAKY_TESTS' not in os.environ, 
'https://bugs.debian.org/123456')
def test_something_flaky(...):
...

so that they are normally skipped, but we can force them to be run
(to assess whether they are still a problem!) by using
"export DEB_ALLOW_FLAKY_TESTS=1".

smcv

Bug#1070773: libglib2.0-dev: dependency on python seems broken for multi-arch?

[Simon McVittie]

On Wed, 08 May 2024 at 23:24:57 +0200, Christian Klein wrote:
> I install both the i386 and amd64 version for multi-arch support.
> 
> With the newest versions, a dependency to python was added.
> 
> Unfortunately, the package has two dependencies for python:
> "python3:any"
> and
> "python3 | qemu-user | qemu-user-static".
> 
> While python3:any is satisfied by the amd64 version of python, the second the
> second dependency  resolves to "python3:i386", which is not co-installable 
> with
> python:amd64.
> So, I now have to install qemu-user as dependency, which comes with a few 
> other
> heavy dependencies. Is this really needed, and how does that help at all?

Yes this is really needed, and it was not added just to spite you.

In general, qemu is required to be able to run GObject-Introspection tools
on cross-compiling architectures (which were packaged separately in older
versions of GLib, but are part of GLib itself in 2.80.x). Some of the
GObject-Introspection tools are required to be of the same architecture
as the typelib they are handling, and using an amd64 tool to load a
non-amd64 typelib will cause bugs.

The dependency on python3 | qemu-user is to avoid needing to pull in
qemu-user in the common case where only one architecture is relevant
(libglib2.0-dev:amd64 on amd64).

For the special case of i386 on an amd64 system, qemu is usually not
actually needed because amd64 systems can nearly always run i386 binaries
directly (although I believe there are kernel configurations that will
not allow that), but it's not obvious how to express that conditional
dependency in apt syntax.

Tested patches welcome, but my understanding is that all
the obvious ideas like
"Depends: python3 | python3:amd64 [i386] | qemu-user | qemu-user-static"
are not suitable, because explicit cross-architecture dependencies like
that one are not supported by the multiarch specification or the Debian
archive software.

If someone designs and implements the can-run-arch or cross-exe-wrapper
interfaces sketched in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030223#37 then I
believe that would give libglib2.0-dev:i386 a way to be installable on
amd64 without needing qemu-user. If you are interested in doing this,
please talk to the debian-cross team to make sure that the design is
sound. Until something like that happens, I am not aware of a better
approach.

smcv

Bug#1070775: gnome-shell: Update gnome-shell from testing to unstable looses umlauts

[Simon McVittie]

Control: reassign -1 libglib2.0-0 2.80.0-10
Control: affects -1 + gnome-shell
Control: fixed -1 2.80.1-1

On Wed, 08 May 2024 at 23:10:19 +0200, Thomas Renard wrote:
> updating from testing version of gnome-shell to unstable version (44.9-2) 
> looses the
> umlauts of a german keyboard.

This is not a gnome-shell bug, this is a regression in the libglib2.0-0
security fix that you installed at the same time. Specifically, it's the
same bug as #1070730, #1070736, #1070743, #1070745, #1070749 and #1070752.
Please upgrade libglib2.0-0 to 2.80.1-1 which should become available
on your mirror soon.

smcv

Bug#1070752: Symbols missing - glib2.0 update - Bookworm+Gnome

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4053
Control: tags -1 + pending

On Wed, 08 May 2024 at 10:42:21 -0300, Pedro Carvalho wrote:
> After upgrading to version 2.74.6-2+deb12u1, I have noticed the following
> symbols are missing for some applications:
> 
> ´ ` ^ ~

This is the same issue as #1070730, #1070736, #1070743, #1070745 and
#1070749. We do not need any more reports of this regression, and I am
fixing it as fast as I can. 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.

smcv

Bug#1070749: libglib2.0-0t64: Update 2.80.0-9 to 2.80.0-10 breaks compose

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4053
Control: tags -1 + pending

On Wed, 08 May 2024 at 14:11:32 +0200, Hannah Stern wrote:
>  Set the "<>" key (German keyboard) to compose (xmodmap), in combination
>  with an US keyboard layout. Type compose " a in order to insert
> a-umlaut,
>  in programs like gvim, thunderbird, firefox. (In xterm it works.)

This is the same issue as #1070730, #1070736, #1070743, #1070745. I'm
fixing this as fast as I can, please be patient.

smcv

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: 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#1070668: Processed: glibc: packages FTBFS caused by vector math library header on arm64

[Simon Chopin]

As the one who reported the issue in the glibc upstream tracker, I'm now
of the opinion it's not a glibc bug, but rather issues with the
individual packages that are now FTBFS. As far as I know, this is either
a parser pretending to be GCC without implementing all the GCC features
(e.g. aspectc++), and/or a compiler targetting another platform while
still using the system headers (e.g. rocm-hipamd).

Bug#1020217: S3-backed snapshot implementation

[Simon Josefsson]

Lucas Nussbaum  writes:

> - I got the OK to host a S3-backed snapshot mirror using the Debian AWS
>   account (see thread in #1020217)

Is this s3 bucket public, or will it be?

I have been worried about the state of snapshot and I am mirroring its
data into local Git LFS.  Since snapshot.debian.org doesn't support
rsync and don't make the postgres database dumps available (so that I
can identify SHA1 objects and speed up downloads), I am using HTML web
scraping to find out what files exists to snapshot.d.o.

My goal has been to put all the Git LFS objects in a publicly-accessible
S3 bucket too.  While imports were running I didn't work on the bucket
side, and I suspect my download will take months to complete at current
speeds.  I publish Git LFS versions of archive.debian.org,
ftp.debian.org and ftp.ports.debian.org already, though, so perhaps I
could start on the bucket publishing part for them and see about adding
an incremental snapshot.d.o copy while it is still working.

/Simon


signature.asc
Description: PGP signature

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

[Simon McVittie]

Control: retitle 1057620 doomsday: segfault in _XFlush() when Qt is using 
native Wayland

On Mon, 06 May 2024 at 00:31:31 +0200, Bernhard Übelacker wrote:
> Bug 1062969 / Bug 1065714 mentions a workaround
> to be able to run doomsday with wayland:
> 
> SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday

Bug 1062969 is about a problem with SDL_JoystickName(), which is
fixed in unstable. The clone #1065714 is also about doomsday's use
of SDL_JoystickName(). Fixing those is unrelated to that workaround:
the only connection is that I had to use that workaround to avoid the
crash-on-startup before I was able to reproduce the joystick bug on
my system.

Bug 1057620 and its duplicate 1065709 are about the crash on startup that
can be worked around with "SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb".
I'm copying the title from 1065709 to 1057620 to make its scope a bit
clearer.

> It looks like upstream removed the relevant code and relies just
> on SDL functions, but unfortunately did not release a new version yet.
> 
> https://github.com/skyjake/Doomsday-Engine/commit/5cc4995861

I haven't reviewed that change in detail, but letting SDL handle all of the
functionality within its scope is generally a good direction to go in.

The root cause of this bug is that doomsday uses both SDL and Qt, each
of which makes its own independent choice between an X11 backend or a
native Wayland backend, and then uses X11 directly itself and assumes
that both SDL and Qt have also chosen to use X11.

If Doomsday needs to use both SDL and Qt for graphics/windowing, probably
the right way to implement this would be to let one of those libraries
choose its backend (X11 or Wayland) according to its usual heuristic,
and then call configuration functions that force the other library to
make the same choice.

smcv

Bug#1069755: libntlm0: broken symlink: README -> README.md

[Simon Josefsson]

Paul Wise  writes:

> Package: libntlm0
> Version: 1.8-2
> Severity: normal
> File: /usr/share/doc/libntlm0/README
> User: debian...@lists.debian.org
> Usertags: adequate broken-symlink
>
> libntlm0 1.8-2 introduced a broken symlink:
>
>    /usr/share/doc/libntlm0/README -> README.md
>
> This appears to be because upstream switched README to a symlink to
> README.md and debian/libntlm0.docs was not updated to use README.md.

Thanks for catching this.  I wonder why no QA tool reported this?  Seems
like a simple thing for lintian to discover?  Or did you use some tool
to discover this that isn't linked from the PTS?

A patch like the one below seems to fix this.  But maybe we should raise
a lintian wishlist bug report too.

/Simon
From 4144c80941d5d099b2ff6678750bae5419c74b6a Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Fri, 3 May 2024 13:31:03 +0200
Subject: [PATCH] docs: Ship README.md.  Closes: #1069755.

---
 debian/changelog | 6 ++
 debian/libntlm0.docs | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 8e2d40a..0ae4286 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libntlm (1.8-3) UNRELEASED; urgency=medium
+
+  * docs: Ship README.md.  Closes: #1069755.
+
+ -- Simon Josefsson   Fri, 03 May 2024 13:31:01 +0200
+
 libntlm (1.8-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --git a/debian/libntlm0.docs b/debian/libntlm0.docs
index 05c2865..41b2efb 100644
--- a/debian/libntlm0.docs
+++ b/debian/libntlm0.docs
@@ -1,4 +1,4 @@
 AUTHORS
 NEWS
-README
+README.md
 THANKS
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1070283: chromium-common: Recommends obsolete transitional package libu2f-udev

[Simon McVittie]

Package: chromium-common
Version: 124.0.6367.118-1~deb12u1
Severity: normal
Control: block 1038319 by -1
X-Debbugs-Cc: libu2f-h...@packages.debian.org

libu2f-udev has been an empty transitional package since Debian 11
(the version in Debian 10 had content). Please remove chromium-common's
"Recommends: libu2f-udev" or replace it with "Recommends: udev (>= 244)".

If no-changes backports to Debian 10 are required, the way to achieve
that would be "Recommends: udev (>= 244) | libu2f-udev", but that's
probably no longer interesting.

This will become RC when the transitional package gets removed (#1038319),
due to Recommends being in-scope for Policy §2.2.1.

Thanks,
smcv

Bug#1070205: nut-scanner: complains about missing libnetsnmp.so

[Simon]

Package: nut-snmp
Version: 2.8.1-3.1+b1
Severity: important
X-Debbugs-Cc: simon.harh...@muenster.de

Dear Maintainer,

'nut' and 'nut-snmp' are installed. I tried to query our ups via 'nut-scanner 
-S' and got following message:
'Cannot load SNMP library (libnetsnmp.so) : file not found. SNMP search 
disabled.'
This renders nut unusable with a UPS via snmp.

But the package 'libsnmp40t64' (in sid) is installed and following files are 
present:
root@host:~# ls /usr/lib/x86_64-linux-gnu/libnetsnmp.so*
/usr/lib/x86_64-linux-gnu/libnetsnmp.so.40  
/usr/lib/x86_64-linux-gnu/libnetsnmp.so.40.2.1

With bookworm 'nut-scanner -S' works without problems.

Thanks for your work and support!
Simon

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.4-2-pve (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nut-snmp depends on:
ii  libc6 2.37-19
ii  libsnmp40t64  5.9.4+dfsg-1.1+b1
ii  nut-server2.8.1-3.1+b1

nut-snmp recommends no packages.

nut-snmp suggests no packages.

-- no debconf information

Bug#1070195: glib2.0: test failure with pcre2/10.43: asserts that a variable-length lookbehind is an error

[Simon McVittie]

Source: glib2.0
Version: 2.78.4-7
Severity: important
Tags: ftbfs trixie sid patch upstream fixed-upstream
Forwarded: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3945
X-Debbugs-Cc: Matthew Vernon 
Control: fixed -1 2.80.0-7

GLib contains GRegex, an API wrapper around pcre2 (or pcre in older GLib
branches).

Because variable-length lookbehind was historically not allowed, its test
suite includes a test that asserts that these two regexes:

(?= 10.43) isn't urgent, please don't upload it to
unstable until after this glib2.0 bug has been fixed (and ideally also
migrated to testing).

Unfortunately my understanding of the time64 situation is that further
package migrations are stalled because they cause the testing migration
scripts to crash (see #1070121). I would prefer to avoid significant
non-urgent changes in unstable until more of the time64 migration can
be forced through by the release team.

Thanks,
smcv

Bug#1069268: gnulib: package version is long

[Simon Josefsson]

Hi Vincent,

Vincent Lefevre  writes:

> Thanks for the explanations. However, I think that it is not the
> goal of the Debian version string to entirely reflect all the
> Debian-side and upstream-side versions involved. This may be a
> good idea when the obtained version string is short enough and
> easy to understand, but here, this is not the case. There are
> probably better places to give such information, in a clearer
> way. This could be in well-chosen files and/or output from
> commands like "gnulib-tool --version" (see below).

I agree now.

> BTW, is the "+stable" really useful in the version string?

I'm no longer convinced it adds anything useful, so would prefer to
remove it.

>> To be honest, after writing all this, I'm no longer certain why anyone
>> would really look at the version number at all for the gnulib Debian
>> package.  A sequentially increasing number is sufficient for packaging
>> reasons: if anyone really wants to know what git commits are inside the
>> package, just read the source code in the package to find out.
>
> IMHO, for additional version information, the Debian changelog is a
> good place for the user + output from a standard command providing
> the version, e.g. "gnulib-tool --version". Scripts can use such a
> command to record the necessary information about software in log
> files. By "standard", I mean that it needs to exist upstream.
>
> For instance, for GCC, there is "gcc --version", where Debian adds
> some information. In particular for gcc-snapshot:
>
> $ gcc-snapshot --version
> gcc (Debian 20240117-1) 14.0.1 20240117 (experimental) [master 
> r14-8187-gb00be6f1576]
> [...]
>
> One has all the details... When compiling software, this can be
> found in the generated config.log file, which is really nice for
> bug reports and debugging.
>
> And the gcc-snapshot version string is basically just a date.

Right.  There is one implementation problem: gnulib-tool is patched to
read the version from /usr/share/doc/gnulib/changelog.Debian.gz now, but
if we change changelog to only be a date, we would want to change this
logic to actually print the useful git commit version information, and
I'm not yet sure how to do that.

There is also the "risk" that upstream gnulib eventually release
versioned archives.  There is a recently added v1.0 tag in git for
example, suggesting things may change.  Since we haven't used the
0~20240501* pattern for gnulib version historically, to move to a
version based approach we would need an epoch like 1:1.3-1 or (more
likely) 1:1.3+20250314-2 since I think we need to package more recent
git commits than what's in any most recent gnulib git tags.  However I
don't think the upstream version number is relevant either, for the same
reasons we realized the upstream commit id or branches weren't.  So we
can continue to use dates for package versions even if upstream start to
release packaged archives.

I'm now inclinced to use a pure date-based version string like
20240501-1 going forward.  Any objections?

We then also have to fix Debian's gnulib-tool --version output to embed
the latest git commit information from upstream that we package --
possibly using the new git bundle as a source?  Instead of parsing
/usr/share/doc/gnulib/changelog.Debian.gz, which may not be present in
stripped down images anyway.

Since gnulib is a fairly large package, I would prefer to not spam the
archive with new *.orig.tar.gz uploads too often.  So I prefer to not
fix this bug until we have to upload a more recent gnulib into the
archive for other reasons.  I don't expect that to take long: I'm
planning to do new release of several projects (oath-toolkit, libidn2,
inetutils, etc) that use gnulib, and work on making those Debian
packages use the Debian gnulib package instead of vendored code would
require a new gnulib Debian package upload.

/Simon


signature.asc
Description: PGP signature

Bug#1069672: bookworm-pu: package flatpak/1.14.8-1~deb12u1

[Simon McVittie]

est for CVE-2024-32462
+  + Fix a double-free in the test suite
+  + Skip more tests if bubblewrap works but FUSE doesn't
+- New upstream stable release 1.14.8
+  + Respin of 1.14.7 reverting unintended submodule changes
+- d/control: Move dbus-system-bus from Depends to Recommends.
+  `flatpak run` no longer has a working system bus as a hard requirement
+  (verified in `podman run --privileged --rm -it debian:sid-slim`)
+- Drop CVE-2024-32462 patches, included in the upstream stable release
+- debian/test.sh: Disable http proxy if used, to ensure we can reach
+  a HTTP server on localhost during automated tests
+  * Changes relative to 1.14.8-1 in unstable:
+- Revert polkitd dependencies to polkitd | policykit-1 as previously
+  used in bookworm
+- Revert pkgconf dependencies to pkg-config as previously used in
+  bookworm
+- Revert location of systemd unit to /lib/systemd/system as previously
+  used in bookworm, dropping versioned dependency on debhelper 13.11.6~
+- Revert changes related to Debian 13 GIR XML packaging policy
+
+ -- Simon McVittie   Tue, 30 Apr 2024 16:50:10 +0100
+
 flatpak (1.14.4-1+deb12u1) bookworm-sec

Bug#1070121: nmu: coreutils_9.4-3 (trixie), pam_1.5.2-9.1 (trixie)

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: coreut...@packages.debian.org, p...@packages.debian.org, 
debian-b...@lists.debian.org
Control: affects -1 + src:coreutils src:pam

coreutils_9.4-3.1 and pam_1.5.3-7 aren't currently migrating to trixie
for whatever reason. Because debootstrap doesn't currently know about
versioned Provides, I think it would be useful to get versions of these
packages in trixie that have been rebuilt against the 64-bit time_t ABIs
and package names.

If the versions in trixie don't migrate imminently, please consider:

nmu coreutils_9.4-3 . ANY . trixie . -m "rebuild against libssl3t64"
nmu pam_1.5.2-9.1 . ANY . trixie . -m "rebuild against libdb5.3t64"

In a trixie derivative (a non-public future branch of the Steam Runtime)
I found that local rebuilds of those two source packages were enough to
bring a minbase debootstrap back from repeatably failing to reasonably
reliable. I hope they would have a similar effect in real trixie.

Based on kibi's thread "Making trixie debootstrap-able again?" on -release
and -boot, binNMUing util-linux and iproute2 might also help for d-i's
use-case, which is larger than minbase and wants fdisk and iproute2:

nmu util-linux_2.39.3-6 . ANY . trixie . -m "rebuild against libreadline8t64"
nmu iproute2_6.7.0-2 . ANY . trixie . -m "rebuild against libtirpc3t64"

but I have not independently verified that those two are necessary
or sufficient.

smcv

Bug#1068505: RFH: reprepro -- Move experimental multi-version feature to unstable

[Simon Richter]

Hi,

On 4/6/24 22:22, Bastian Germann wrote:

As many in the Debian world depend on reprepro to manage their 
repositories, I would like to ask for help because I did not have the 
capacity in the last two years (and probably not in the remaining year 
to come during the trixy cycle) to give those bugs the attention that 
they deserve.


I don't have the capacity either, but I have added it to my list of 
things I should be looking into.


   Simon

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#1069751: gvfs-daemons: gvfsd-network fills the logs with errors

[Simon McVittie]

On Wed, 24 Apr 2024 at 09:24:14 +0200, Francesco Potortì wrote:
> 2024-04-23T04:21:41.887252+02:00 tucano gvfsd-wsdd[1507271]: Failed to spawn 
> the wsdd daemon: Failed to execute child process “wsdd” (No such file or 
> directory)
> 2024-04-23T04:21:41.887324+02:00 tucano gvfsd-network[318402]: Couldn't 
> create directory monitor on wsdd:///. Error: Automount failed: Failed to 
> spawn the underlying wsdd daemon.
> 
> The above sequence is repeated every 15 s

This should be fixed by 1.54.x from unstable, when it migrates to testing
(upstream commit "wsdd: Print debug info only if GVFS_WSDD_DEBUG is set").
That's currently blocked by the 64-bit time_t transition, but according to
the latest update from the release team, packages should start migrating
again soon.

> 2024-04-23T04:55:28.315700+02:00 tucano gvfsd-network[318402]: GFileInfo 
> created without standard::content-type
> 2024-04-23T04:55:28.315722+02:00 tucano gvfsd-network[318402]: file 
> ../../../gio/gfileinfo.c: line 1822 (g_file_info_get_content_type): should 
> not be reached
> 2024-04-23T04:55:28.315743+02:00 tucano gvfsd-network[318402]: 
> g_ref_string_new_intern: assertion 'str != NULL' failed

This might be fixed by 1.54.x too.

smcv

Bug#1069672: bookworm-pu: package flatpak/1.14.6-1~deb12u1 or 1.14.7-1~deb12u1

[Simon McVittie]

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

After the dust has settled from CVE-2024-32462, I would like to do a
stable-update of Flatpak using the upstream 1.14.x branch.

At the moment bookworm-security has 1.14.4 plus the patches for
CVE-2024-32462. The current upstream release is 1.14.6 (also available in
unstable and in testing-proposed-updates), which moves the security fix
from patches into the upstream source and fixes various less serious bugs.

We are also hoping to do a 1.14.7 upstream release soon, perhaps this
week. Would the stable release team prefer this to be proposed as one
big update from 1.14.4 to 1.14.7, or two smaller updates
1.14.4 → 1.14.6 → 1.14.7, or do you not mind either way?

[ Impact ]
If not accepted, several known bugs remain present in stable.
The highest-visibility is that the developer name of an app appears
in the CLI where the app name should be, for example "The Chromium Authors"
instead of the correct "Chromium Web Browser".

Also, if we keep up with upstream stable releases, then next time there
is a CVE, we can take upstream's stable release directly instead of
having to backport individual patches.

[ Tests ]
There is a fairly comprehensive test suite. It cannot be run under schroot
or lxc due to limitations of nested containers, but I run in
autopkgtest-virt-qemu before each upload, and ci.debian.net has now been
configured to run flatpak's tests under autopkgtest-virt-qemu has well.

I will test a final version manually on a bookworm system before upload.

[ Risks ]
Somewhat low risk, all changes are targeted bug fixes. I would say that
the highest-risk are the alterations to how AppStream metadata is parsed
and displayed, but several distributions are already using those changes
via the 1.15.x branch and we have not had regression reports.

[ Checklist ]
The changes in 1.14.7 will not be finalized until the release actually
happens, but I have reviewed and attached a proposed diff.

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

[ Changes in 1.14.5 and 1.14.6 ]
See attached flatpak-1.14.6-bookworm.diff.gz

* Makefile.am,
  configure.ac,
  data/Makefile.am.inc,
  data/tmpfiles.d/flatpak.conf,
  debian/flatpak.install,
  sideload-repos-systemd/Makefile.am.inc:
  - Delete obsolete /var/tmp/flatpak-cache-* (if any) during boot

* app/flatpak-builtins-build.c,
  common/flatpak-dir.c,
  common/flatpak-run.c,
  tests/test-run.sh:
  - Fix CVE-2024-32462 (previously done via a patch)

* app/flatpak-builtins-remote-info.c:
  - Fix display of app info in `flatpak remote-info`
  - Fix some uses of deprecated libappstream API
  - Forward-compatibility with libappstream 0.17.x and 1.0

* app/flatpak-builtins-remote-ls.c,
  app/flatpak-builtins-search.c,
  app/flatpak-builtins-utils.c,
  app/flatpak-builtins-utils.h,
  config.h.in,
  configure.ac:
  - Fix some uses of deprecated libappstream API
  - Forward-compatibility with libappstream 0.17.x and 1.0

* app/flatpak-builtins-run.c,
  common/flatpak-dir.c,
  tests/testlibrary.c:
  - Silence some compiler warning false-positives

* common/flatpak-appdata.c,
  tests/make-test-app.sh,
  tests/test-info.sh:
  - Don't parse the app developer name as though it was the app name

* common/flatpak-run.c,
  doc/flatpak-run.xml:
  - Don't let the sandboxed app inherit a wrong value for $VK_DRIVER_FILES,
$VK_ICD_FILENAMES

* common/flatpak-utils-http.c:
  - Cancel downloads if they become very slow

* common/flatpak-utils.c,
  tests/test-exports.c,
  tests/test-instance.c:
  - Forward-compatibility with newer GLib releases

* NEWS,
  common/flatpak-version-macros.h,
  configure.ac,
  tests/package_version.txt:
  - The usual release management noise

* debian/test.sh:
  - Unset proxy environment variables to make sure a test http server on
localhost is reachable

* doc/flatpak-metadata.xml:
  - Provide anchors for internal linking
  - Clarify documentation on which D-Bus names are allowed by default

* doc/reference/html/*.html:
  - Regenerated with Debian 12 toolchain
(these are also re-regenerated during build)
  (Filtered from debdiff)

* po/*.po,
  po/flatpak.pot:
  - Regenerated during upstream release procedure (different line numbering)
  (Filtered from debdiff)

* portal/flatpak-portal.c:
  - Save the original environment before setting GIO_USE_VFS, and restore it
before starting sandboxed programs, so that GVfs can work

* revokefs/main.c:
  - Forward-compatibility with libostree 2023.4

* session-helper/flatpak-session-helper.c:
  - Same as portal/, but for programs run on the host system by trusted
Flatpak apps

* tests/make-test-runtime.sh:
  - Fail tests earlier, with a better error message, if a 

Bug#1069576: blhc: False positive NONVERBOSE BUILD in src:fim

[Simon Ruderich]

Hi Rafael,

On Sat, Apr 20, 2024 at 09:13:58PM +0200, Rafael Laboissière wrote:
> Dear Maintainer,
>
> blhc triggers a NONVERBOSE BUILD error in src:fim
>
> https://salsa.debian.org/debian/fim/-/jobs/5618524
>
>   [snip]
>   $ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS} 
> ${WORKING_DIR}/*.build || [ $? -eq 1 ]
>   338:NONVERBOSE BUILD: CXX  : g++
>   [snip]
>
> blhc is complaining about the output of the upstream configure script,
> which indicates to the user which C++ compiler will be used.

should be fixed in [1].

> The patch attached to this bug report fixes the problem for me.
> Hopefully, it will not introduce false negatives.

Thanks for the patch. I've fixed it slightly differently to
reduce the chance of false negatives.

Best,
Simon

[1] 
https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=5d2c33804eade9a6b1463d4cb46d7cac0018274c
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#1037521: (no subject)

[Simon Ruderich]

Hi,

On Fri, Apr 05, 2024 at 12:48:19AM -0400, Yogeswaran Umasankar wrote:
> eribe...@debian.org, Matthias Geiger 
> Bcc: Subject: Re: false positive NONVERBOSE BUILD for rust code in Python
> modules
> Reply-To: Hi,
>
> I am having similar issue in another package 'python-cotengrust' [0].
> The link for buildlog [1].
>
> [0] https://salsa.debian.org/python-team/packages/python-cotengrust/
> [1] 
> https://salsa.debian.org/python-team/packages/python-cotengrust/-/jobs/5519541

as discussed in IRC the problem is that blhc cannot detect that
this is a rust package. In regular buildd logs the "Filtered
Build-Depends:" lines contain the build dependencies. This gives
blhc a way to enable special handling for certain situations (in
this case if a rust compiler is used).

I couldn't find a way to get this information from the salsa
build logs. If they could be modified to show the build
dependencies then I'll adapt blhc to detect this case.

Best,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#1068773: Subject: blhc: Stack clash and branch protection flag issues in Debian Bookworm and older releases

[Simon Ruderich]

Hi,

On Wed, Apr 10, 2024 at 09:09:13PM +, aquilamac...@riseup.net wrote:
> The ${RELEASE} variable in the context of this issue refers to the
> specific Debian release being used during the Salsa CI process. One
> potential solution that has been considered is to ensure that
> blhc:${RELEASE} correctly handles the flags for each release. This
> approach could alleviate the compilation errors and ensure consistency
> across different Debian releases.
>
> For more details, you can check the issue in the Salsa CI repository at
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/340
>
> Before proceeding with any changes, I would appreciate your input on
> this matter. Specifically, do you think it would be sensible to use blhc
> from each release? Your insights would be greatly appreciated.

I think the best solution is to use the blhc version from the
corresponding release (i.e. blhc:${RELEASE}). Otherwise each
change to flags in blhc will require manual work for earlier
releases as carnil mentioned.

The blhc version in each release should be able to handle the
flags for that release (otherwise it's a bug which should be
fixed). So the suggested first approach should work fine and
cause the less additional maintenance overhead.

Best,
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9


signature.asc
Description: PGP signature

Bug#1069597: gnulib: describe a security patch mechanism

[Simon Josefsson]

Package: gnulib
Severity: wishlist

I don't know how to implement this, so I'll describe it pending for
inspiration or someone else to come along who wants to work on this.

Let's say we are in a situation were Debian packages Build-Depends on
the gnulib package as the source for gnulib related source code.  I've
implemented this for libntlm [1], but it could be done for any package
that uses gnulib.  That approach would reduce the need to audit vendored
gnulib code from upstream tarballs.  Most packages today (e.g.,
coreutils, tar, gzip inetutils) just vendor all gnulib files into to the
tarball.  So this wishlist is more relevant in a future reality where
Build-Depends on gnulib is a more widespread solution.

If there is a security bug in gnulib code, it would make sense to
manually patch that the gnulib package, and then automatically rebuild
all the dependent packages to get the fix released.  Rather than
manually patch all packages that has vendored gnulib code in them and
release those.

The GNULIB_REVISION or --gnulib-refdir mechanism used by gnulib does not
support this way of working: the git commit to use comes from the
package (e.g., libntlm) via GNULIB_REVISION in bootstrap.conf or through
a git submodule that pins the gnulib commit.  So patching code in the
Debian gnulib package doesn't alter the code that's in the gnulib git
commit tree used.

Some mechanism that let packages pin the gnulib git commit to use AND
then let the Debian gnulib package be able to patch the resulting gnulib
code seems to be needed.

Possibly we can implement rules via the new
/usr/share/gnulib/gnulibvars.mk dpkg makefile snippet.  Then all
packages that rely on gnulib would have to include that and invoke the
hook, in order to allow the gnulib Debian package to provide a patched
gnulib source code, before the package is building it.

/Simon

[1] 
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/


signature.asc
Description: PGP signature

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#1069285: trixie-pu: package flatpak/1.14.6-1~deb13u1

[Simon McVittie]

On Fri, 19 Apr 2024 at 14:09:24 +0200, Emilio Pozuelo Monfort wrote:
> On 19/04/2024 12:49, Simon McVittie wrote:
> > Fix CVE-2024-32462, a sandbox escape vulnerability, without having to
> > wait for the whole 64-bit time_t transition.
> 
> Please go ahead once you're ready, and let us know so that we can hint it
> into testing.

Uploaded, no changes since the debdiff you saw.

smcv

Bug#1069285: trixie-pu: package flatpak/1.14.6-1~deb13u1

[Simon McVittie]

his file was extended by Flatpak $as_me 1.14.6, which was
 generated by GNU Autoconf 2.71.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -22668,7 +22668,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config='$ac_cs_config_escaped'
 ac_cs_version="\\
-Flatpak config.status 1.14.5
+Flatpak config.status 1.14.6
 configured by $0, generated by GNU Autoconf 2.71,
   with options \\"\$ac_cs_config\\"
 
diff -Nru flatpak-1.14.5/configure.ac flatpak-1.14.6/configure.ac
--- flatpak-1.14.5/configure.ac	2023-12-08 12:15:05.0 +
+++ flatpak-1.14.6/configure.ac	2024-04-17 18:28:16.0 +0100
@@ -15,7 +15,7 @@
 
 m4_define([flatpak_major_version], [1])
 m4_define([flatpak_minor_version], [14])
-m4_define([flatpak_micro_version], [5])
+m4_define([flatpak_micro_version], [6])
 m4_define([flatpak_extra_version], [])
 m4_define([flatpak_interface_age], [0])
 m4_define([flatpak_binary_age],
diff -Nru flatpak-1.14.5/debian/changelog flatpak-1.14.6/debian/changelog
--- flatpak-1.14.5/debian/changelog	2023-12-08 12:25:50.0 +
+++ flatpak-1.14.6/debian/changelog	2024-04-19 11:00:13.0 +0100
@@ -1,3 +1,22 @@
+flatpak (1.14.6-1~deb13u1) trixie; urgency=high
+
+  * Rebuild for trixie
+
+ -- Simon McVittie   Fri, 19 Apr 2024 11:00:13 +0100
+
+flatpak (1.14.6-1) unstable; urgency=high
+
+  * New upstream stable release 1.14.6
+- Don't allow an executable name to be misinterpreted as a command-line
+  option for bwrap(1). This prevents a sandbox escape where a malicious
+  or compromised app could ask xdg-desktop-portal to generate a .desktop
+  file with access to files outside the sandbox. (CVE-2024-32462)
+- Don't parse `` as the application name
+  * d/control: Drop alternative dependencies on transitional policykit-1.
+polkitd was released in Debian 12 and Ubuntu 22.04.
+
+ -- Simon McVittie   Wed, 17 Apr 2024 19:34:28 +0100
+
 flatpak (1.14.5-1) unstable; urgency=medium
 
   * New upstream stable release
diff -Nru flatpak-1.14.5/debian/control flatpak-1.14.6/debian/control
--- flatpak-1.14.5/debian/control	2023-12-08 12:25:50.0 +
+++ flatpak-1.14.6/debian/control	2024-04-19 11:00:13.0 +0100
@@ -52,7 +52,7 @@
  libzstd-dev,
  ostree (>= 2020.8) ,
  pkgconf,
- polkitd  | policykit-1 ,
+ polkitd ,
  procps,
  python3:any,
  python3-pyparsing,
@@ -87,7 +87,7 @@
  gtk-update-icon-cache,
  libpam-systemd,
  p11-kit,
- polkitd | policykit-1,
+ polkitd,
  shared-mime-info,
  xdg-desktop-portal (>= 1.6),
  xdg-desktop-portal-gtk (>= 1.6) | xdg-desktop-portal-backend,
diff -Nru flatpak-1.14.5/ltmain.sh flatpak-1.14.6/ltmain.sh
--- flatpak-1.14.5/ltmain.sh	2023-12-08 10:49:53.0 +
+++ flatpak-1.14.6/ltmain.sh	2024-04-17 19:17:44.0 +0100
@@ -31,7 +31,7 @@
 
 PROGRAM=libtool
 PACKAGE=libtool
-VERSION="2.4.7 Debian-2.4.7-7"
+VERSION="2.4.7 Debian-2.4.7-5"
 package_revision=2.4.7
 
 
@@ -572,15 +572,27 @@
 # -
 # Append VALUE onto the existing contents of VAR.
 
+  # We should try to minimise forks, especially on Windows where they are
+  # unreasonably slow, so skip the feature probes when bash or zsh are
+  # being used:
+  if test set = "${BASH_VERSION+set}${ZSH_VERSION+set}"; then
+: ${_G_HAVE_ARITH_OP="yes"}
+: ${_G_HAVE_XSI_OPS="yes"}
+# The += operator was introduced in bash 3.1
+case $BASH_VERSION in
+  [12].* | 3.0 | 3.0*) ;;
+  *)
+: ${_G_HAVE_PLUSEQ_OP="yes"}
+;;
+esac
+  fi
+
   # _G_HAVE_PLUSEQ_OP
   # Can be empty, in which case the shell is probed, "yes" if += is
   # useable or anything else if it does not work.
-  if test -z "$_G_HAVE_PLUSEQ_OP" &&  \
-  __PLUSEQ_TEST="a" &&  \
-  __PLUSEQ_TEST+=" b" 2>/dev/null &&  \
-  test "a b" = "$__PLUSEQ_TEST"; then
-_G_HAVE_PLUSEQ_OP=yes
-  fi
+  test -z "$_G_HAVE_PLUSEQ_OP" \
+&& (eval 'x=a; x+=" b"; test "a b" = "$x"') 2>/dev/null \
+&& _G_HAVE_PLUSEQ_OP=yes
 
 if test yes = "$_G_HAVE_PLUSEQ_OP"
 then
@@ -2296,7 +2308,7 @@
compiler:   $LTCC
compiler flags: $LTCFLAGS
linker: $LD (gnu? $with_gnu_ld)
-   version:$progname $scriptversion Debian-2.4.7-7
+   version:$progname $scriptversion Debian-2.4.7-5
automake:   `($AUTOMAKE --version) 2>/dev/null |$SED 1q`
autoconf:   `($AUTOCONF --version) 2>/dev/null |$SED 1q`
 
diff -Nru flatpak-1.14.5/NEWS flatpak-1.14.6/NEWS
--- flatpak-1.14.5/NEWS	2023-12-08 12:15:04.0 +
+++ flatpak-1.14.6/NEWS	2024-04-17 18:28:07.0 +0100
@@ -1,3 +1,18 @@
+Changes in 1.14.6
+~
+
+Security fixes:
+
+ * Don't allow an executable name to be misinterpreted as a command-line

Bug#1069283: New version of arista.eos collection

[Simon Spöhel]

Package: ansible
Version: 9.4.0+dfsg-1

Dear Maintainers

Thank you for updating and maintaining Ansible.

Ansible in Debian contains arista.eos collection version 6.2.2. Current 
upstream version is 9.0.0. An update would be much appreciated.


Regards
Simon

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

[Simon Josefsson]

Maytham Alsudany  writes:

> In early 2022, Guillem added support for a new Static-Built-Using field to
> dpkg, encouraging packagers to use it over Built-Using to specify
> statically-linked dependencies [2]. The commit message states the following:
>
>   This field mimics the previous Built-Using field semantics, but is
>   specifically intended for shadow dependencies stemming from static builds.
>   
>   In Debian, the Rust and Go teams agreed to use this language agnostic field,
>   instead of one for each of the languages. This means it can be easily
>   supported by dpkg, and can be used by other languages and run-times.
>
> This was also added to the deb-control(5) manpage, specifically 
> differentiating
> it from Built-Using as a field to be used "for static building purposes (for
> example linking against static libraries, builds for source-centered languages
> such as Go or Rust[...])".
>
> The proposed change is to clarify and formally mandate the requirement to
> declare statically-linked libraries used to build packages containing binaries
> in Static-Built-Using. Attached is a draft patch of the proposed change.
> Feedback is welcome!

I think there is a gap between "statically linked libraries" and "builds
for source-centered languages" -- could it be clarified if
Static-Built-Using is intended to cover situations where package A
incorporate source code from package B and source code from B affects
whatever goes into the binary package of A?  That is definitely true for
statically linked libraries.

I'm thinking of how gnulib C code is included in many packages, which
could be set up to work in a way similar to how Go packages work.  I
just made 'libntlm' use the 'gnulib' package this way, to reduce
xz-related risks with vendored gnulib code.  Should libntlm's
debian/control now include a 'Static-Built-Using: gnulib'?

/Simon


signature.asc
Description: PGP signature

Bug#1069268: gnulib: package version is long

[Simon Josefsson]

Vincent Lefevre  writes:

> Package: gnulib
> Version: 20240412~dfb7117+stable202401.20240408~aa0aa87-2
> Severity: normal
>
> A long package version is annoying for the user (for the "dpkg -l"
> output and other reasons). I doubt that such a long version is
> necessary;

Hi Vincent and thanks for the report.

Yeah, I can sympathise with this concern, and deciding on the version
scheme probably took me the most time in the last update.  Some
discussion would help.  Quoting README.source:

 A package version "20240411~b57dd0d+stable202401.20240408~aa0aa87"
 means that the gnulib git clone had the latest commit on "master"
 dated "20240411" with revision "b57dd0d" and the "stable-202401"
 branch had a commit dated "20240408" with revision "aa0aa87".  The
 files in /usr/share/gnulib correspond to files on the "stable-202401"
 branch with revision "aa0aa87", except for
 /usr/share/gnulib/gnulib.bundle which is a git bundle containing both
 master and stable branches up until "b57dd0d" (master) and "aa0aa87"
 (stable-202401) respectively.  This approach enable /usr/share/gnulib
 to be an unpacked stable gnulib release, but the
 /usr/share/gnulib/gnulib.bundle (which is more likely to be used by
 other packages for bootstrapping) can contain newer commits too.

So there really are two upstreams versions involved, and upstream
neither tag nor release tarballs, so timestamps, branch names and git
commits are the only identifiers that we have available:

0~a57dd0d~stable-202401~ba0aa87

It could be that we will have these two versions at some point, maybe
one in unstable and one in experimental:

20250411~a57dd0d+stable202501.20250408~ba0aa87
20250411~a57dd0d+stable202407.20250308~c928adb

That correspond to the same master branch but different stable branches.

We could also have differences like this, showing updated commits on the
same stable branch:

20250411~a57dd0d+stable202501.20250408~ba0aa87
20250411~a57dd0d+stable202501.20250308~c928adb

Upstream maintains multiple stable branches in parallel.

We can have uploads for different master commits but same stable branch,
consider if a security fix was applied to a stable branch at some point:

20250411~8585cab+stable202501.20250408~ba0aa87
20250411~abc4818+stable202501.20250408~abc4874

or even:

20250411~8585cab+stable202501.20250408~ba0aa87
20250311~abc4818+stable202501.20250408~ba0aa87

To be able to identify the upstream version, we need the information of
the commit id on the master branch together with which stable branch was
used and which commit on the stable branch.

The only superflous information in the version strings are the dates,
but removing them does not seem like it would improve on your concern,
rather the opposite.  Maybe the dates are what makes sense for users.
And something like dates are needed for dpkg version ordering.

Some ideas for improvement:

20240411+stable-1 - revert to earlier pattern, this loses the commit id
information and which stable branch was used, potentially making it
impossible to use the same pattern in the future if there is one Debian
upload of 20240411+stable-1 and somehow upstream gnulib commits an
important patch on the same date that we need to package.

20240411~a57dd0d-1 - this makes the git commit identifiable, but loses
information about which stable branch was used.  Maybe the stable branch
version is more important than the master branch release date?

20240411+stable2401~a47dd0d-1 - this adds the release branch used, and
has git commit id corresponding to git master.  May lead to version
conflicts if multiple releases are needed on the same date.

I guess you can come up with some more variations that for better or
worse make some sense.

To be honest, after writing all this, I'm no longer certain why anyone
would really look at the version number at all for the gnulib Debian
package.  A sequentially increasing number is sufficient for packaging
reasons: if anyone really wants to know what git commits are inside the
package, just read the source code in the package to find out.

So maybe just fall back to what 'uscan' suggests: 20240418~0a85f70-1.
Or 20240418+stable-1 like we had before, although I'm not really sure if
the '+stable' helps anyone, and it is a bit confusing if the date refers
to the timestamp on the stable or master branch.

> I'm wondering whether it is intended or is due to a bug in a script
> (the "Fix gnulib-tool --version" seems to have done nothing
> significant).

The current version scheme is intentional, but I'm open to changing it.
That was a unrelated fix: before 'gnulib-tool --version' tried to parse
/usr/share/doc/gnulib/NEWS.stable.gz, which doesn't exist, so you got an
error message and the printed version string became garbled.

/Simon


signature.asc
Description: PGP signature

Bug#1018120: evolution: depends on unmaintained clutter-1.0 and related libraries

[Simon McVittie]

Control: tags -1 + patch

On Thu, 25 Aug 2022 at 20:22:41 +0100, Simon McVittie wrote:
> [Evolution] depends on clutter-1.0, which is no longer maintained
> upstream (and has been effectively unmaintained for a while).
> 
> It looks as though disabling the "contact maps" option might resolve this.

Please consider the attached (compiles successfully after
`apt purge libclutter-1.0-0`, otherwise untested).

I'm a GNOME team member but I don't regularly use evolution, so I am
not intending to upload this change myself.

smcv
>From 1ed10e612ae2203acbec4392505d703eba67ddf5 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 18 Apr 2024 10:57:38 +0100
Subject: [PATCH] Disable contact maps and remove libchamplain build-dependency

clutter-1.0 is unmaintained upstream (#996690) and should ideally not
be included in trixie.

Closes: #659512, #1018120
---
 debian/control | 2 --
 debian/rules   | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 8c9f3a3eaa..b80153c0b6 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,6 @@ Build-Depends: cmake,
debhelper-compat (= 13),
dh-sequence-gnome,
dpkg-dev (>= 1.16.1),
-   libchamplain-gtk-0.12-dev (>= 0.12.21),
libglib2.0-dev (>= 2.66),
libgtk-3-dev (>= 3.10.0),
libgail-3-dev (>= 3.0.2),
@@ -51,7 +50,6 @@ Build-Depends: cmake,
libsm-dev,
libice-dev,
gsettings-desktop-schemas-dev (>= 2.91.92),
-   libclutter-gtk-1.0-dev (>= 0.90),
highlight,
libcryptui-dev,
libgnome-autoar-0-dev (>= 0.1.1),
diff --git a/debian/rules b/debian/rules
index 324a55f4cb..ce64fb91b8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,7 @@ override_dh_auto_configure:
 		-DWITH_OPENLDAP=ON \
 		-DENABLE_PLUGINS=all \
 		-DENABLE_PST_IMPORT=ON \
-		-DENABLE_CONTACT_MAPS=ON \
+		-DENABLE_CONTACT_MAPS=OFF \
 		-DENABLE_AUTOAR=ON \
 		-DENABLE_INSTALLED_TESTS=OFF \
 		-DWITH_HELP=ON \
-- 
2.39.2

Bug#1069211: clutter-1.0: build-time tests fail on loong64

[Simon McVittie]

Control: retitle -1 clutter-1.0: build-time tests fail on loong64
Control: tags -1 + moreinfo

On Thu, 18 Apr 2024 at 02:26:08 +, wuruilong wrote:
> The clutter software fails to compile on loongarch architecture, 
> please refer to the attached patch to fix it.

This is not a fix, this is a workaround: it's adding loong64 to the list of
architectures where the tests are expected to fail. Why are the tests failing
on loong64?

If our first reaction to tests failing is to disable the tests completely
instead of investigating what is failing and why, then the tests have
no value.

One possible reason is that Mesa's llvmpipe might be broken on loong64,
similar to #1002690 on mips64el, src:mutter bug #1059000 on loong64,
src:gnome-shell bug #1058687 on riscv64, and various src:gtk4 bugs on
all of those architectures.

loong64, mips64el and riscv64 seem to all have similar issues when using
llvmpipe, so a fix for one might well help the others.

Note that unlike mutter and gtk4, clutter-1.0 is dead upstream (#996690),
so if loong64 users do not have a specific need for packages that depend
on clutter-1.0, it might be better for clutter-1.0 and the packages that
depend on it to be permanently missing from new architectures.

The only important package that would be missing if clutter-1.0 is not
present seems to be evolution, although I see that in #1018120 I thought
that disabling one optional feature ("contact maps") would avoid that
dependency.

smcv

Bug#1069089: ruby-rubygems: Broken platform detection which lead to unability to install sass-embedded

[Simon Elst]

Package: ruby-rubygems
Version: 3.4.20-1
Severity: important
X-Debbugs-Cc: s...@nedra.be


   * What led up to the situation?
Trying to build a website with Jekyll (through "bundle exec jekyll serve").

   * What exactly did you do (or not do) that was effective (or ineffective)?
1. Running "bundle" on a Jekyll fresh new site with "minimal" template
2. Installing missing gem ("sass-embedded") with "gem install" command, and
then running "bundle exec jekyll serve".

   * What was the outcome of this action?
1. Bundler::HTTPError: Could not download gem from https://rubygems.org/ due to
underlying error https://rubygems.org/gems/sass-
embedded-1.75.0-x86_64-linux.gem)>
2. Install works, but it brings "sass-embedded (1.75.0 x86_64-linux-android)"
instead of "[...]-linux-gnu)". Then, the bundle exec command fails :
"Conversion error: Jekyll::Converters::Scss encountered an error while
converting 'assets/main.scss': Broken pipe"

   * What outcome did you expect instead?
Bundle should install sass-embedded (linux-gnu).

It looks like it is related to a patch in Debian version (3.4.20) that breaks
platform detection. The bug is pointed out here :
https://github.com/jekyll/jekyll/issues/9478#issuecomment-1785797746
My usecase and the full terminal transcript are available here :
https://www.reddit.com/r/Jekyll/comments/1c4g90p/unable_to_build_site_because_of_sass/



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-rubygems depends on:
ii  ruby  1:3.1

ruby-rubygems recommends no packages.

ruby-rubygems suggests no packages.

-- no debconf information

Bug#921954: gnulib

[Simon Josefsson]

Jonas Smedegaard  writes:

> I am happy that gnulib is in good hands.
>
> I've moved on to other challenges, and have no interest in working on
> gnulib now.  That said, you are welcome to try nudge me if some concrete
> task emerges where you image I might be of help.

Thank you for support!

Boyuan Yang  writes:

> Thanks for your work; I am okay with the changes. For git bundle
> reproducibility, seeking advice from Debian people in the reproducible-
> builds project may be helpful. With the changes in project structure, it
> might be useful to provide documents about how to use the updated gnulib
> Debian package for other Debian software packagers.

Definitely, my blog post [1] illustrates how it can be done, but the
details for a Debian packager is sketchy.  I should summarize how to
convert a Debian package from a traditional 'make dist' tarball that
includes gnulib to a 'git-archive' based approach that uses gnulib from
the Debian package, maybe as a debian-devel post.

However I don't think it is wise to do that for packages that are
validating PGP signatures of the existing tarball and there is an
upstream that doesn't provide PGP signed 'git-archive' releases.  We can
nudge upstream's to sign 'git-archive' exports of their projects,
though.

/Simon

[1] 
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/


signature.asc
Description: PGP signature

Bug#921954: gnulib

[Simon Josefsson]

Hi

You may have noticed I adopted gnulib and have made an upload to
experimental.  I am happy to have this team maintained, so feel free to
join the effort -- I added Boyuan to Uploaders: since you've been doing
QA uploads for some time, but happy to add others too.

If you don't object, I will upload to unstable in a couple of days if
nothing comes up.  Relevant reading material on the changes I did for
this package:

https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/README.source
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/

What do you think?  I hope I'm not stepping on anyone's toes here.  The
package was orphaned and is a critical component to be able to build
source-only tarballs for other packages in Debian.

/Simon

Simon Josefsson  writes:

> Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnulib
> and intend to adopt it in Debian, but I’m happy to co-maintain it. My
> plan is to keep it updated to latest upstream version, and see if we
> can offer some way for it to be used to bootstrap various projects
> that depend on vendored gnulib code.
>
> /Simon


signature.asc
Description: PGP signature

Bug#1068748: autopkgtest-build-qemu: Ubuntu EFI VMs fail to boot

[Simon McVittie]

On Wed, 10 Apr 2024 at 11:54:02 +0200, Christian Kastner wrote:
> I've already filed an MR at vmdb2 upstream that fixes the logic, but I
> thought it might be best to track the issue here as well. Please feel
> free to close this bug if you think it is superfluous.

If there's no actionable bug in autopkgtest, and a fix in vmdb2 will
automatically fix autopkgtest without any autopkgtest code changes being
required or desirable, then the usual way to represent that would be to
give the vmdb2 bug report an "affects" on autopkgtest.

smcv

Bug#1065084: libelfin fails autopkg test with LLVM 18

[Simon Chopin]

Source: libelfin
Followup-For: Bug #1065084
X-Debbugs-Cc: scho...@ubuntu.com

I've applied the attached debdiff in Ubuntu to fix the issue, as it
prevents llvm-defaults from migrating.

-- System Information:
Debian Release: trixie/sid
  APT prefers noble
  APT policy: (500, 'noble'), (100, 'noble-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-22-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libelfin-0.3/debian/changelog libelfin-0.3/debian/changelog
--- libelfin-0.3/debian/changelog   2024-04-01 06:44:16.0 +0200
+++ libelfin-0.3/debian/changelog   2024-04-10 11:33:31.0 +0200
@@ -1,3 +1,9 @@
+libelfin (0.3-3.1ubuntu1) noble; urgency=medium
+
+  * Fix autopkgtests against newer clang (Closes: 1065084, LP: #2060786)
+
+ -- Simon Chopin   Wed, 10 Apr 2024 11:33:31 +0200
+
 libelfin (0.3-3.1build1) noble; urgency=medium
 
   * No-change rebuild for CVE-2024-3094
diff -Nru 
libelfin-0.3/debian/patches/0003-don-t-use-a-VLA-just-to-compute-a-buffer-size.patch
 
libelfin-0.3/debian/patches/0003-don-t-use-a-VLA-just-to-compute-a-buffer-size.patch
--- 
libelfin-0.3/debian/patches/0003-don-t-use-a-VLA-just-to-compute-a-buffer-size.patch
1970-01-01 01:00:00.0 +0100
+++ 
libelfin-0.3/debian/patches/0003-don-t-use-a-VLA-just-to-compute-a-buffer-size.patch
2024-04-10 11:33:31.0 +0200
@@ -0,0 +1,26 @@
+From: Simon Chopin 
+Date: Wed, 10 Apr 2024 11:25:19 +0200
+Subject: don't use a VLA just to compute a buffer size
+
+VLAs in C++ are compiler extensions, and clang will complain about it.
+
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libelfin/+bug/2060786
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065084
+Forwarded: https://github.com/aclements/libelfin/pull/82
+---
+ dwarf/small_vector.hh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/dwarf/small_vector.hh b/dwarf/small_vector.hh
+index e73ab60..9437328 100644
+--- a/dwarf/small_vector.hh
 b/dwarf/small_vector.hh
+@@ -93,7 +93,7 @@ public:
+ while (target < n)
+ target <<= 1;
+ 
+-char *newbuf = new char[sizeof(T[target])];
++char *newbuf = new char[target * sizeof(T)];
+ T *src = base, *dest = (T*)newbuf;
+ for (; src < end; src++, dest++) {
+ new(dest) T(*src);
diff -Nru libelfin-0.3/debian/patches/series libelfin-0.3/debian/patches/series
--- libelfin-0.3/debian/patches/series  2023-02-13 21:57:02.0 +0100
+++ libelfin-0.3/debian/patches/series  2024-04-10 11:33:31.0 +0200
@@ -1,2 +1,3 @@
 0001-Let-d-rules-override-library-version.patch
 0002-Remove-const-qualifier-from-setter.patch
+0003-don-t-use-a-VLA-just-to-compute-a-buffer-size.patch

Bug#1068747: python3-djangorestframework: Package does not include bootstrap-tweaks.css file

[Simon Lyngshede]

Package: python3-djangorestframework
Version: 3.14.0-2
Severity: normal
X-Debbugs-Cc: si...@lyngshede.dk

Dear Maintainer,

When deploying a Django application, using the staticfiles module, the
application will throw a 500, if the user attempts to access the a REST
endpoint using a normal browser, as the staticfiles module will fail to
locate the bootstrap-tweaks.css file. The file is shipped be the Django
REST Framework project, but is excluded by the debian/rules file.

It happens because the following rule accidentally matches the
bootstrap-tweaks.css file: 
$(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/bootstrap*.css

The correct rule would be:
$(RM) 
debian/python3-djangorestframework/usr/lib/python3/dist-packages/rest_framework/static/rest_framework/css/bootstrap*.min.css


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-9-arm64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-djangorestframework depends on:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  fonts-glyphicons-halflings  1.009~3.4.1+dfsg-3
ii  libjs-bootstrap 3.4.1+dfsg-3
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-prettify  2015.12.04+dfsg-1.1
ii  python3 3.11.2-1+b1
ii  python3-django  3:3.2.19-1+deb12u1
ii  python3-tz  2022.7.1-4

Versions of packages python3-djangorestframework recommends:
ii  python3-coreapi  2.3.3-6
ii  python3-coreschema   0.0.4-5
ii  python3-django-filters   23.1-1
ii  python3-django-guardian  2.4.0-2
ii  python3-markdown 3.4.1-2
ii  python3-psycopg2 2.9.5-1+b1
ii  python3-yaml 6.0-3+b2

Versions of packages python3-djangorestframework suggests:
pn  python-djangorestframework-doc  

-- no debconf information

Bug#1067562: FTBFS: missing symbols on 32-bit architectures

[Simon Chopin]

Source: mpg123
Followup-For: Bug #1067562
X-Debbugs-Cc: scho...@ubuntu.com
Control: tags -1 ftbfs patch

Hi,

I just uploaded the attached debdiff to Ubuntu to both fix the FTBFS and
start the t64 transition for this package, based on the following
comment:

> the non-suffixed functions now work with 64 bit offsets, where they
> formerly worked with 32 bit off_t arguments. This could be considered
> ABI breakage, too.

That's definitely an ABI break, so the transition is necessary in any
case. We can always add back the compat layer if we deem it necessary.


-- System Information:
Debian Release: trixie/sid
  APT prefers noble-updates
  APT policy: (500, 'noble-updates'), (500, 'noble'), (100, 'noble-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-20-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru mpg123-1.32.5/debian/changelog mpg123-1.32.5/debian/changelog
--- mpg123-1.32.5/debian/changelog  2024-03-31 10:08:02.0 +0200
+++ mpg123-1.32.5/debian/changelog  2024-04-03 20:29:56.0 +0200
@@ -1,3 +1,13 @@
+mpg123 (1.32.5-1ubuntu1) noble; urgency=medium
+
+  [ Steve Langasek ]
+  * Rename libraries for 64-bit time_t transition. (Closes: #1063140)
+
+  [ Simon Chopin ]
+  * Only include 32bit compat symbols on i386 arches (Closes: #1067562)
+
+ -- Simon Chopin   Wed, 03 Apr 2024 20:29:56 +0200
+
 mpg123 (1.32.5-1build2) noble; urgency=medium
 
   * No-change rebuild for CVE-2024-3094
diff -Nru mpg123-1.32.5/debian/control mpg123-1.32.5/debian/control
--- mpg123-1.32.5/debian/control2024-03-12 07:39:44.0 +0100
+++ mpg123-1.32.5/debian/control2024-04-03 20:20:46.0 +0200
@@ -43,7 +43,10 @@
  OSS4, the Advanced Linux Sound Architecture (ALSA), JACK, PortAudio,
  PulseAudio, OpenAL and the Network Audio System (NAS).
 
-Package: libmpg123-0
+Package: libmpg123-0t64
+Provides: ${t64:Provides}
+Replaces: libmpg123-0
+Breaks: libmpg123-0 (<< ${source:Version})
 Multi-Arch: same
 Architecture: any
 Section: libs
@@ -57,7 +60,10 @@
  This package contains the C libraries needed to run executables that use
  the mpg123 library.
 
-Package: libout123-0
+Package: libout123-0t64
+Provides: ${t64:Provides}
+Replaces: libout123-0
+Breaks: libout123-0 (<< ${source:Version})
 Multi-Arch: same
 Architecture: any
 Section: libs
@@ -70,7 +76,10 @@
  .
  This package contains the shared out123 library.
 
-Package: libsyn123-0
+Package: libsyn123-0t64
+Provides: ${t64:Provides}
+Replaces: libsyn123-0
+Breaks: libsyn123-0 (<< ${source:Version})
 Multi-Arch: same
 Architecture: any
 Section: libs
@@ -88,9 +97,9 @@
 Architecture: any
 Section: libdevel
 Depends:
- libmpg123-0 (= ${binary:Version}),
- libout123-0 (= ${binary:Version}),
- libsyn123-0 (= ${binary:Version}),
+ libmpg123-0t64 (= ${binary:Version}),
+ libout123-0t64 (= ${binary:Version}),
+ libsyn123-0t64 (= ${binary:Version}),
  ${misc:Depends}
 Description: MPEG layer 1/2/3 audio decoder (development files)
  mpg123 is a real time MPEG 1.0/2.0/2.5 audio player/decoder for layers
diff -Nru mpg123-1.32.5/debian/libmpg123-0.install 
mpg123-1.32.5/debian/libmpg123-0.install
--- mpg123-1.32.5/debian/libmpg123-0.install2023-10-01 15:44:05.0 
+0200
+++ mpg123-1.32.5/debian/libmpg123-0.install1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-usr/lib/*/libmpg123.so.0*
diff -Nru mpg123-1.32.5/debian/libmpg123-0.lintian-overrides 
mpg123-1.32.5/debian/libmpg123-0.lintian-overrides
--- mpg123-1.32.5/debian/libmpg123-0.lintian-overrides  2023-10-01 
15:44:05.0 +0200
+++ mpg123-1.32.5/debian/libmpg123-0.lintian-overrides  1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-# The SSE, 3DNowExt, 3DNow, and MMX decoders use non-pic assembly code.
-libmpg123-0 [i386]: specific-address-in-shared-library
diff -Nru mpg123-1.32.5/debian/libmpg123-0.symbols 
mpg123-1.32.5/debian/libmpg123-0.symbols
--- mpg123-1.32.5/debian/libmpg123-0.symbols2023-10-02 21:38:58.0 
+0200
+++ mpg123-1.32.5/debian/libmpg123-0.symbols1970-01-01 01:00:00.0 
+0100
@@ -1,160 +0,0 @@
-libmpg123.so.0 libmpg123-0 #MINVER#
- mpg123_add_string@Base 1.6.2
- mpg123_add_substring@Base 1.6.2
- mpg123_chomp_string@Base 1.15.1
- mpg123_clip@Base 1.6.2
- mpg123_close@Base 1.6.2
- mpg123_copy_string@Base 1.6.2
- mpg123_current_decoder@Base 1.7.2
- mpg123_decode@Base 1.6.2
- mpg123_decode_frame64@Base 1.32.3
- mpg123_decode_frame@Base 1.6.2
- mpg123_decode_frame_64@Base 1.13.7
- mpg123_decoder@Base 1.6.2
- mpg123_decoders@Base 1.6.2
- mpg123_delete@Base 1.6.2
- mpg123_delete_pars@Base 1.6.2
- mpg123_delete_string@Base 1.26.0
- mpg123_distversion@Base 1.32.3
- mpg123_enc_from_id3@Base 1.9.1
- mpg123

Bug#921954: Volunteer to adopt this

[Simon Josefsson]

Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnulib and 
intend to adopt it in Debian, but I’m happy to co-maintain it. My plan is to 
keep it updated to latest upstream version, and see if we can offer some way 
for it to be used to bootstrap various projects that depend on vendored gnulib 
code.

/Simon

Bug#1068014: urlwatch: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: urlwatch
Version: 2.28-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068013: telegram-send: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: telegram-send
Version: 0.37-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068012: python3-subliminal: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-subliminal
Version: 2.1.0-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068011: sqlfluff: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: sqlfluff
Version: 2.3.5-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068010: snakemake: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: snakemake
Version: 7.32.4-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068009: rope: Please replace python3-appdirs build-dependency with platformdirs

[Simon McVittie]

Source: rope
Version: 1.13.0-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

(I also notice that this package has a Build-Depends on python3-appdirs, but
not a Depends. Is this a mistake? I would be surprised for it to need
python3-appdirs at build-time but not at runtime.)

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068007: python3-satpy: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-satpy
Version: 0.47.0-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068006: qiime: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: qiime
Version: 2024.2.0-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068005: pytoolconfig: Please replace python3-appdirs build-dependency with platformdirs

[Simon McVittie]

Source: pytoolconfig
Version: 1.3.1-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

(I also notice that this package has a Build-Depends on python3-appdirs, but
not a Depends. Is this a mistake? I would be surprised for it to need
python3-appdirs at build-time but not at runtime.)

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068004: python3-pytools: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-pytools
Version: 2023.1.1-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068003: python3-ulmo: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-ulmo
Version: 0.8.8+dfsg1-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068002: python3-rply: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-rply
Version: 0.7.7-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068001: python3-requests-cache: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-requests-cache
Version: 0.9.8-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1068000: python3-os-faults: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-os-faults
Version: 0.2.1-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067999: python3-openstacksdk: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-openstacksdk
Version: 1.5.0-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067998: python3-npe2: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-npe2
Version: 0.7.2-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067997: python3-miio: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-miio
Version: 0.5.12-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067996: python3-mbed-ls: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-mbed-ls
Version: 1.6.2+dfsg-10
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067995: python3-ironicclient: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-ironicclient
Version: 5.4.0-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067994: python3-fs: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-fs
Version: 2.4.16-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067993: python-fastparquet: Please replace python3-appdirs build-dependency with platformdirs

[Simon McVittie]

Source: python-fastparquet
Version: 2024.2.0-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

(I also notice that this package has a Build-Depends on python3-appdirs, but
not a Depends. Is this a mistake? I would be surprised for it to need
python3-appdirs at build-time but not at runtime.)

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067992: python3-fissix: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-fissix
Version: 21.6.6-3
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067991: python3-etesync: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-etesync
Version: 0.12.1-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067990: python3-datacache: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-datacache
Version: 1.2.1-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/