On 02/10/22 at 22:21 +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Lucas Nussbaum (2022-10-02 21:51:52) > > On 02/10/22 at 04:23 +0200, Adam Borowski wrote: > > > Nǐmen hǎo! > > > I did another _source_ rebuild of the archive -- checking if every package > > > is capable of repacking its source. Ie, if you can unpack it, (possibly > > > modify), and pack again. > > > > > > Putting aside packages that are broken in other ways as well (B-Depends > > > non-installable, FTBFS or a RC bug), there seems to be no new fancy types > > > of breakage that haven't been fixed in 2020. > > > > > > This leaves one big set: packages that fail the clean step due to > > > undeclared B-Depends. According to the Policy: > > > > > > # "clean" > > > # Only the "Build-Depends" and "Build-Conflicts" fields must be > > > # satisfied when this target is invoked. > > > > > > ... which makes sense as you might be interested in only an arch:all or > > > arch:any build, and we have no clean-indep/clean-arch targets. > > > > > > For sbuild, the incantation is: > > > alias sbuild-source='sbuild -s --source-only-changes --no-arch-all > > > --no-arch-any --no-run-autopkgtest' > > > > > > As 291 packages fail this requirement, I'm posting here before (instead?) > > > filing bugs. There's also a question of severity. > > > > > > Raw list and dd-list attached. > > > > All those source packages are Architecture: all. > > > > To make this easier to detect (and avoid regressions in the long term), > > I wonder if sbuild should have an option that would make it do, for a > > source+all build: > > please do not abuse sbuild to produce source packages. Source packages are the > input to sbuild and not its output. Sbuild has some convenience features that > let it create the source package for you from an unpacked directory so that > you > do not have to do that step manually but that doesn't change the fact that to > operate it still needs to create a dsc first. > > Instead of trying to use the -s or --source option, use the > --source-only-changes option instead which will not re-create the source > package but gives you a .changes file ready to a source-only upload anyways in > addition to the arch-all or arch-any .changes file.
My point is: if the issue raised by Adam is something we want to fix, it would be great if we could come up with a way to detect this issue on a regular basis, rather than with one-off QA checks. One way to achieve that would be to extend sbuild so that it is able to check for that while also checking for rebuildability of binary packages. (and then I would integrate that into my regular archive rebuilds) > > - install B-D > > - run clean > > - install B-D-I > > - build the binary packages > > This will be tricky to implement because sbuild doesn't run the clean target. > Instead it runs dpkg-buildpackage which then runs the clean target. But feel > free to try and implement it and file a merge request on salsa. Maybe it's not > as bad as I fear. > > Changing salsa-ci.yml to test for this would not be easy either, because > "apt-get build-dep" only exposes the --arch-only and --indep-only options. So > there is no way to tell apt "only the dependencies for the clean target, > please". ... but I see your point. Lucas
