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 <sanvila@debian.org> 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 <sanvila@debian.org>
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()
Reply to: