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 <sanvila@debian.org> 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.
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature