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 <sanvila@debian.org> 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 given architecture.
Under this simplified model, of course, we can tell if the package
builds in some architecture or not by just looking at what happens in
the matching autobuilder.
But there is life outside buildd.debian.org, and this simplistic
view of buildability has its flaws.
In this particular case, I'm getting failures on amd64, so I think
it's not correct to say that the package is "buildable on amd64".
See the Salsa CI link above.
Thanks.
Reply to: