Bug#1122432: libgusb: FTBFS: 2/3 libgusb:gusb-self-test FAIL 0.01s killed by signal 6 SIGABRT
Hi Jeremy, * Jeremy Bícha [2025-12-10 22:32]: This situation is different as it's not been demonstrated yet that the test is too unreliable for Debian's purposes. We don't have enough information about why your system is different and your simple patch (don't run the test in the official Debian build) isn't necessarily something Debian maintainers should be eager to accept. https://tests.reproducible-builds.org/debian/history/libgusb.html I had a quick look because it is failing on: https://reproduce.debian.net/all/#libgusb-doc but not: https://reproduce.debian.net/amd64/#libgusb2 The difference is that the arch:all build has no /sys/bus/usb/ and the test tries to access that. As I wrote in: https://lists.debian.org/debian-release/2025/11/msg00362.html /sys is known to be different on different systems. Eventually sbuild will wrap the build in qemu to fix this.. Cheers Jochen signature.asc Description: PGP signature
Bug#1122432: libgusb: FTBFS: 2/3 libgusb:gusb-self-test FAIL 0.01s killed by signal 6 SIGABRT
On Thu, Dec 11, 2025 at 8:19 AM Santiago Vila wrote: > Well, for the record, it also fails in Salsa CI. I tried adding a > salsa-ci.yml, which you removed in commit [8610af0], and this is what > happened: > > https://salsa.debian.org/sanvila/libgusb/-/pipelines Yes, I was the one who added the Salsa CI file but as I mentioned in the commit message, the repo wasn't configured to actually use that file, so I removed the file immediately afterwards. I'll contact the repo owners so that we can enable Salsa CI. The fact that the test fails in Salsa CI is a strong argument, and it was one that I attempted to check a week ago but I didn't get it done. Thank you for the data. Jeremy Bícha
Bug#1122432: libgusb: FTBFS: 2/3 libgusb:gusb-self-test FAIL 0.01s killed by signal 6 SIGABRT
On Wed, Dec 10, 2025 at 10:32:47PM -0500, Jeremy Bícha wrote: > On Wed, Dec 10, 2025 at 5:51 PM Santiago Vila wrote: > > On Wed, Dec 10, 2025 at 03:56:20PM -0500, Jeremy Bícha wrote: > > > Control: severity -1 normal > > > > I think this is wrong, because it's a violation of Policy 4.2. > > Policy 4.2 is "must" directive. > > https://www.debian.org/doc/debian-policy/ch-source.html#package-relationships > Debian Policy §4.2 is about build dependencies. Here's the heart of the > section: > "If build-time dependencies are specified, it must be possible to > build the package and produce working binaries on a system with only > essential and build-essential packages installed and also those > required to satisfy the build-time relationships" This is not only about build-dependencies. This is THE paragraph in policy mandating that packages must build from source. Just because it's worded in a section about build-dependencies does not mean that the paragraph only means "there must not be missing build-depends". > The package builds ok as is on Debian's buildds. It also builds for me > ok with sbuild. You can build libgusb on your system by using the > nocheck build profile. "It must be possible" means it has to work. Not only in your computer, not only in buildd.debian.org. It must work for anybody not doing anything "wrong", and I'm not doing anything wrong. And working means dpkg-buildpackage exiting with exit status 0 indicating success in the regular way of package building, without having to jump through hoops (like using nocheck). > This situation is different as it's not been demonstrated yet that the > test is too unreliable for Debian's purposes. Well, for the record, it also fails in Salsa CI. I tried adding a salsa-ci.yml, which you removed in commit [8610af0], and this is what happened: https://salsa.debian.org/sanvila/libgusb/-/pipelines > We don't have enough > information about why your system is different You don't really need "information about why my system is different". This is precisely why I always offer a VM to test, but for some reason you prefer to decline the offer and ignore that an unknown amount of people can't build the package, just because you can build the package. In this particular case, if you are still unwilling to use the VM I offer, I suggest you try in a VM with 2 CPUs, which afaik is also that Salsa CI uses. Paul Gevers wrote: > > Moreover, flaky tests are considered RC since trixie > > They were considered RC well before trixie. I don't think the > start date matters. Well, apparently some people seem not to be aware of that yet, and I think that's a problem that we should try to address, because not being aware is probably what makes discussions like this one to happen from time to time. (This is the meaning of the question which you call impossible to answer, but I'm not sure how to express it in the best possible way, sorry). > Debian's purposes are its users. Including those that build the software we > ship themselves. That's exactly the point I was trying to make. Source packages are for everybody, not just for buildd, not just for Salsa CI, not just for reproducible-builds, and not just for the maintainer's own PC. > [...] > PS Santiago: I don't really like you phrasing this question like this Ok, I apologize if my choice of words was not appropriate. Let me reword the question in another way: What can we do so that people abandon the (flawed, imo) idea that our sources packages only need to be buildable in buildd.debian.org? Is this a cultural problem? Is this a problem in the way Release Policy is worded? Is it maybe a communication problem? What kind of problem is it, and how could we address it? (I admit that it's a difficult question, but I would not call it impossible). I've seen too many people thinking that way and I consider that to be detrimental for the quality of Debian. I think this idea comes from this sentence in Release Policy: > Packages must autobuild without failure on all architectures on > which they are supported. My interpretation of that, and I think that was always the original intent, is that FTBFS bugs are only acceptable when they happen on non-release architectures, or on releases on which the package is not supported. And the idea is (or I believe it always was) that if we ship a given package for a given architecture in a stable release, the package must be buildable in such architecture within such stable release. (So we have to make the bugs RC before that to ensure that packages which do not build in some architecture do not reach the next stable). The problem here is that the sentence uses "autobuilding" and too many people interpret that as "autobuilding in the official buildds", when I think that was never the idea or the intent. In my opinion, the paragraph just follows a "simplified model" of building, in which a package either always build ok in a given architecture, or it always fail in a g
Bug#1122432: libgusb: FTBFS: 2/3 libgusb:gusb-self-test FAIL 0.01s killed by signal 6 SIGABRT
Hi, Let me start off with saying I can sympathize with both of you. In the end I concluded I believe the test to be unreliable. See below. On 12/11/25 04:32, Jeremy Bícha wrote: On Wed, Dec 10, 2025 at 5:51 PM Santiago Vila wrote: On Wed, Dec 10, 2025 at 03:56:20PM -0500, Jeremy Bícha wrote: The package builds ok as is on Debian's buildds. It also builds for me ok with sbuild. I also tried it (I used autopkgtest to build it) multiple times on two machines: my laptop and the amd64 ci.d.n host. It didn't fail for me. I noticed that for reproduce.debian.net if failed on another test [1]. You can build libgusb on your system by using the nocheck build profile. And what would the user conclude when the failing test? If it was me building it, I would conclude there is something wrong with the binaries. Moreover, flaky tests are considered RC since trixie They were considered RC well before trixie. I don't think the start date matters. This situation is different as it's not been demonstrated yet that the test is too unreliable for Debian's purposes. Debian's purposes are it's users. Including those that build the software we ship themselves. We don't have enough information about why your system is different Given that we now have 2 amd64 systems where the build fails with the SIGABRT in gusb-self-test (Santiago's and r-b.o), one where it fails with a timeout in gusb-umockdev-test and 4 where it works (amd64 buildd, Jeremy's system, my laptop and the ci.d.n amd64 host), it would be interesting to know about specialities of the hosts. I also note that Jeremy disabled the tests on some architectures, the changelog says because they fail. The build of several architectures on the buildds failed on SIGABRT in gusb-self-test too; I checked the logs of arm64, armhf, s390x and alpha. It seems that the gusb-self-test test isn't reliable. and your simple patch (don't run the test in the official Debian build) isn't necessarily something Debian maintainers should be eager to accept. Can it be made such that it runs, but failures ignored to collect some more statistics? Can more debugging information be added? I recognize the reluctance to disable tests, but I also believe flaky tests are bad. I also think this test has all appearances of being a bad test. Paul [1] https://reproduce.debian.net/amd64/api/v1/builds/102945/log PS Santiago: I don't really like you phrasing this question like this: """ Once again, I have to ask Paul: What needs to happen so that people stop using the simplistic "buildd" argument as an excuse to downgrade and/or ignore build failures like this one? """ I think the question is asking the impossible and I don't consider it my task to answer that question for you. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1122432: libgusb: FTBFS: 2/3 libgusb:gusb-self-test FAIL 0.01s killed by signal 6 SIGABRT
On Wed, Dec 10, 2025 at 5:51 PM Santiago Vila wrote: > On Wed, Dec 10, 2025 at 03:56:20PM -0500, Jeremy Bícha wrote: > > Control: severity -1 normal > > I think this is wrong, because it's a violation of Policy 4.2. > Policy 4.2 is "must" directive. https://www.debian.org/doc/debian-policy/ch-source.html#package-relationships Debian Policy §4.2 is about build dependencies. Here's the heart of the section: "If build-time dependencies are specified, it must be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships" The package builds ok as is on Debian's buildds. It also builds for me ok with sbuild. You can build libgusb on your system by using the nocheck build profile. > Moreover, flaky tests are considered RC since trixie, and we already > discussed about this in the gcr4 bug. I am sorry for the gcr situation and that it took so long to resolve. This situation is different as it's not been demonstrated yet that the test is too unreliable for Debian's purposes. We don't have enough information about why your system is different and your simple patch (don't run the test in the official Debian build) isn't necessarily something Debian maintainers should be eager to accept. https://tests.reproducible-builds.org/debian/history/libgusb.html Thank you, Jeremy Bícha
Bug#1122432: libgusb: FTBFS: 2/3 libgusb:gusb-self-test FAIL 0.01s killed by signal 6 SIGABRT
tags 1122432 patch
thanks
Note: Cc to Paul as Release Manager because he set some conventional
thresholds for flaky tests in the gcr4 bug which I also would like to
see applied here.
On Wed, Dec 10, 2025 at 03:56:20PM -0500, Jeremy Bícha wrote:
> Control: severity -1 normal
I think this is wrong, because it's a violation of Policy 4.2.
Policy 4.2 is "must" directive.
Moreover, flaky tests are considered RC since trixie, and we already
discussed about this in the gcr4 bug.
For the record, I'm getting a failure rate of 100% (i.e. *always*),
which clearly exceeds the conventional threshold of 1/6 set by Paul in
the gcr4 bug.
I've put a bunch of build logs here for you to see:
https://people.debian.org/~sanvila/build-logs/202512/
> On Wed, Dec 10, 2025 at 3:40 PM Santiago Vila wrote:
> > Package: src:libgusb
> > Version: 0.4.9-5
> > Severity: serious
> > Tags: ftbfs forky sid
> >
> > Dear maintainer:
> >
> > During a rebuild of all packages in unstable, this package failed to build.
>
> But libgusb built successfully on all Debian architectures a few days ago:
>
> https://buildd.debian.org/status/package.php?p=libgusb
So what? I've heard such argument before and I still believe it's wrong.
Policy 4.2 is not restricted to buildd.debian.org, and the end user
will not use buildd.debian.org to rebuild packages. Relying only on
whatever happens in buildd.debian.org to determine if something is
suitable for release does not make sense for a free software
distribution.
Once again, I have to ask Paul: What needs to happen so that people
stop using the simplistic "buildd" argument as an excuse to downgrade
and/or ignore build failures like this one? (The maintainer here even
claimed he would like to close the bug!).
Note that I'm *not* doing anything wrong, I'm also offering a VM to
reproduce, and I'm *not* the only one who can't rebuild the package:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libgusb.html
A test which fails over and over again is telling us that the program
might be wrong. If you ignore the outcome of the test, it means
you don't really care. But if you don't really care, then there
is no excuse to not disable the test.
The "it works for me" argument may be suitable for a proprietary
software company. But for Debian it's an anti-pattern. I'm not
offering a VM to reproduce in *every* and *each* FTBFS bug I report so
that people still tell me "it works for me" as an excuse to do
nothing.
I'm attaching a patch to disable the flaky test if ignoring the
outcome of the test is what you really want to do.
Thanks.Description: Disable flaky test
Author: Santiago Vila
Bug-Debian: https://bugs.debian.org/1122432
Last-Update: 2025-12-10
--- libgusb-0.4.9.orig/gusb/meson.build
+++ libgusb-0.4.9/gusb/meson.build
@@ -230,7 +230,7 @@ if get_option('tests')
cargs,
],
)
- test('gusb-self-test', e)
+ # test('gusb-self-test', e)
# Umockdev based tests
test_env = environment()
Bug#1122432: libgusb: FTBFS: 2/3 libgusb:gusb-self-test FAIL 0.01s killed by signal 6 SIGABRT
Control: severity -1 normal On Wed, Dec 10, 2025 at 3:40 PM Santiago Vila wrote: > Package: src:libgusb > Version: 0.4.9-5 > Severity: serious > Tags: ftbfs forky sid > > Dear maintainer: > > During a rebuild of all packages in unstable, this package failed to build. But libgusb built successfully on all Debian architectures a few days ago: https://buildd.debian.org/status/package.php?p=libgusb Notably, I enabled build tests this month for Debian's libgusb instead of silently skipping them. I believe that change was better for Debian. Those tests are disabled on some architectures where this self test is failing. Maybe there's some issue with umockdev or something on some systems. You're of course welcome to build with nocheck if you want. I don't think this is a FTBFS issue for Debian itself. Therefore, I'd like to close this bug but I'm at least marking as not RC. Thank you, Jeremy Bícha
Bug#1122432: libgusb: FTBFS: 2/3 libgusb:gusb-self-test FAIL 0.01s killed by signal 6 SIGABRT
Package: src:libgusb Version: 0.4.9-5 Severity: serious Tags: ftbfs forky sid 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/202512/ 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:libgusb, so that this is still visible in the BTS web page for this package. Thanks. [...] [26/33] cc -Igusb/gusb-umockdev-test.p -Igusb -I../gusb -I. [too-long-redacted] -c ../gusb/gusb-umockdev-test.c [27/33] /usr/bin/x86_64-linux-gnu-g-ir-compiler gusb/GUsb-1.0.gir --output gusb/GUsb-1.0.typelib --includedir=/usr/share/gir-1.0 [28/33] cc -Itools/gusbcmd.p -Itools -I../tools -Igusb -I../ [too-long-redacted] ain.c.o -c ../tools/gusb-main.c [29/33] cc -o gusb/gusb-self-test gusb/gusb-self-test.p/gus [too-long-redacted] son-glib-1.0.so -Wl,--end-group [30/33] cc -o gusb/gusb-umockdev-test gusb/gusb-umockdev-test.p/gusb-umockdev-test.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,-z,defs -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 '-Wl,-rpath,$ORIGIN/' -Wl,--start-group gusb/libgusb.so.2.0.10 /usr/lib/x86_64-linux-gnu/libumockdev.so /usr/lib/x86_64-linux-gnu/libgobject-2.0.so /usr/lib/x86_64-linux-gnu/libglib-2.0.so /usr/lib/x86_64-linux-gnu/libgio-2.0.so /usr/lib/x86_64-linux-gnu/libusb-1.0.so /usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so -Wl,--end-group [31/33] cc -o tools/gusbcmd tools/gusbcmd.p/gusb-main.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,-z,defs -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 '-Wl,-rpath,$ORIGIN/../gusb' -Wl,--start-group gusb/libgusb.so.2.0.10 /usr/lib/x86_64-linux-gnu/libgio-2.0.so /usr/lib/x86_64-linux-gnu/libgobject-2.0.so /usr/lib/x86_64-linux-gnu/libglib-2.0.so /usr/lib/x86_64-linux-gnu/libusb-1.0.so /usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so -Wl,--end-group [32/33] /usr/bin/vapigen --quiet --library=gusb --directory=/<>/obj-x86_64-linux-gnu/gusb --pkg=gio-2.0 --pkg=json-glib-1.0 --metadatadir=/<>/gusb /<>/obj-x86_64-linux-gnu/gusb/GUsb-1.0.gir [33/33] /usr/bin/gi-docgen generate --quiet --add-include-path=/<>/obj-x86_64-linux-gnu/docs/../libgusb --config=docs/libgusb.toml --output-dir=docs/libgusb --no-namespace-dir --content-dir=/<>/docs gusb/GUsb-1.0.gir dh_auto_test cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=2 meson test --verbose ninja: Entering directory `/<>/obj-x86_64-linux-gnu' [1/1] Generating gusb/gusb_mapfile with a custom command /<>/contrib/generate-version-script.py:10: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html from pkg_resources import parse_version 1/3 libgusb:gusb-exported-api RUNNING >>> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 >>> >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 >>> MALLOC_PERTURB_=25 MESON_TEST_ITERATION=1 /usr/bin/diff -urNp >>> /<>/gusb/libgusb.ver gusb/libgusb.ver 2/3 libgusb:gusb-self-test RUNNING >>> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 >>> >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 >>> MALLOC_PERTURB_=191 >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 >>> MESON_TEST_ITERATION=1 >>> /<>/obj-x86_64-linux-gnu/gusb/gusb-self-test 1/3 libgusb:gusb-exported-api OK 0.01s 3/3 libgusb:gusb-umockdev-test RUNNING >>> MALLOC_PERTURB_=188 >>> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 >>> >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 >>> LD_PRELOAD=libumockdev-preload.so.0 >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 >>> LD_LIBRARY_PATH=/<>/obj-x86_64-linux-gnu/gusb >>> MESON_TEST_ITERATION=1 >>> /<>
