Dear maintainer:

During a rebuild of all packages in unstable, this package failed to build.

Below you will find the last part of the build log (probably the most
relevant part, but not necessarily). If required, the full build log
is available here:

https://people.debian.org/~sanvila/build-logs/202608/

About the archive rebuild: The build was made on virtual machines from AWS,
using sbuild and a reduced chroot with only build-essential packages.

If you cannot reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and add an affects on src:network-manager, so that this is still
visible in the BTS web page for this package.

Thanks.
--------------------------------------------------------------------------------
[...]
==============================================================================


Summary of Failures:

52/85 NetworkManager:src/libnm-glib-aux/tests/test-shared-general            FAIL              0.01s   exit status 5

Ok:                84
Fail:              1
dh_auto_test: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=2 meson test --verbose --timeout-multiplier 2 returned exit code 1
make[1]: *** [debian/rules:82: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:14: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess failed with exit status 2
--------------------------------------------------------------------------------

Am 26.08.26 um 20:05 schrieb Santiago Vila:

If you cannot reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

Moreover, it also fails here after I triggered a rebuild:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/network-manager.html

Whatever is the reason for the failure, it apparently started to
happen somewhere between 2026-08-04 and 2026-08-21 according to my
build history:

Status: successful  network-manager_1.58.0-2_amd64-20260729T213058.984Z
Status: successful  network-manager_1.58.0-2_amd64-20260804T135514.761Z
Status: failed      network-manager_1.58.0-2_amd64-20260821T223539.163Z
Status: failed      network-manager_1.58.0-2_amd64-20260822T100432.126Z
Status: failed      network-manager_1.58.0-2_amd64-20260823T072345.958Z
Status: failed      network-manager_1.58.0-2_amd64-20260823T075901.111Z
Status: failed      network-manager_1.58.0-2_amd64-20260826T043132.628Z
Status: failed      network-manager_1.58.0-2_amd64-20260826T044547.710Z
Status: failed      network-manager_1.58.0-2_amd64-20260826T164703.396Z
Status: failed      network-manager_1.58.0-2_amd64-20260826T164801.667Z
Status: failed      network-manager_1.58.0-2_amd64-20260826T165148.755Z
Status: failed      network-manager_1.58.0-2_amd64-20260826T165326.489Z

Thanks.

Am 26.08.26 um 21:34 schrieb Santiago Vila:

Maybe a failure introduced by glib2.0 then.
https://tracker.debian.org/pkg/glib2.0

Can you reproduce the failure with glib2.0 from forky?

Hi,

* Michael Biebl <biebl@debian.org> [260826 23:31]:

I can repro the build failure in unstable, and that building in
forky works. Obviously there are more differences than just forky,
but at least that's a start...

Best,
Chris

Good question.

Same as Chris (thanks for testing), the build failure happens
(right now) in unstable but not in forky.

(Note: I tried a lot of times to discard failures of random nature).

[ I see you have restored the metadata, thanks a lot ].

Control: retitle -1 network-manager: FTBFS: test-shared-general.c:283:test_nm_strdup_int: assertion failed (_s1 == "0"): (NULL == "0")
Control: forwarded -1 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/work_items/2015
Control: tags -1 + upstream
...

This doesn't show the actual assertion failure, which is:

nm:ERROR:../src/libnm-glib-aux/tests/test-shared-general.c:283:test_nm_strdup_int: assertion failed (_s1 == "0"): (NULL == "0")

I think I can see why this regressed with the new GLib, I replied on the
upstream issue that Michael already created.

     smcv