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 <[email protected]> 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.
