Re: FTBS bugs -- MBF?
On Sun, Oct 02, 2022 at 01:06:31PM +0200, Mattia Rizzolo wrote: > On Sun, Oct 02, 2022 at 10:57:11AM +0100, Simon McVittie wrote: > > > Packages that only build Architecture: all binary packages tend to use > > > Build-Depends-Indep. > > > > Policy is quite clear about that being a bug. I think a better rule of > > thumb for maintainers in a hurry would be: if you don't have time to think > > about which dependency list is the right one, and preferably test the > > result (with a source-only build like Adam has been doing, a --build=all > > build, and a --build=any build), then the safe option is to put everything > > in B-D. > > I totally agree, and I consider that a RC bug in my mind. > > I would support filing all the bugs as sev:important, and bump them > right after the bookworm release (so we don't add all these RC bugs so > near the freeze, even if they are trivial to fix). I've filed a few of those, let's see if there's any pushback or comments. https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-qa%40lists.debian.org=ftbs Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring. ⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.
Re: FTBS bugs -- MBF?
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
Re: FTBS bugs -- MBF?
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. > - 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". Thanks! cheers, josch signature.asc Description: signature
Re: FTBS bugs -- MBF?
On Sun, Oct 02, 2022 at 09:51:52PM +0200, Lucas Nussbaum wrote: > On 02/10/22 at 04:23 +0200, Adam Borowski wrote: > > 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. > 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: > - install B-D > - run clean > - install B-D-I > - build the binary packages There is nothing that stops B-D-A being necessary for clean for an arch:any package. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring. ⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.
Re: FTBS bugs -- MBF?
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: - install B-D - run clean - install B-D-I - build the binary packages Lucas
Re: FTBS bugs -- MBF?
On Sun, Oct 02, 2022 at 10:57:11AM +0100, Simon McVittie wrote: > > Packages that only build Architecture: all binary packages tend to use > > Build-Depends-Indep. > > Policy is quite clear about that being a bug. I think a better rule of > thumb for maintainers in a hurry would be: if you don't have time to think > about which dependency list is the right one, and preferably test the > result (with a source-only build like Adam has been doing, a --build=all > build, and a --build=any build), then the safe option is to put everything > in B-D. I totally agree, and I consider that a RC bug in my mind. I would support filing all the bugs as sev:important, and bump them right after the bookworm release (so we don't add all these RC bugs so near the freeze, even if they are trivial to fix). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: FTBS bugs -- MBF?
On Sun, 02 Oct 2022 at 10:16:00 +0200, Sebastiaan Couwenberg wrote: > On 10/2/22 04:23, Adam Borowski quoted Policy: > > # "clean" > > #Only the "Build-Depends" and "Build-Conflicts" fields must be > > #satisfied when this target is invoked. > > Shouldn't Build-Depends-Indep be considered as part of Build-Depends? I think that would defeat the purpose of splitting B-D, B-D-I and B-D-A. A common reason to use B-D-I is that building documentation needs a relatively "heavy" tool like doxygen, gtk-doc or TeX, which is time- and space-consuming to install and harder to satisfy during architecture bootstrapping. If we required B-D-I to be satisfied for clean, then that would mean the documentation tool would be required when running dpkg-buildpackage -B, which expands to somethng similar to debian/rules clean debian/rules build-arch debian/rules binary-arch That would have the same practical result as moving everything from B-D-I to B-D. > Packages that only build Architecture: all binary packages tend to use > Build-Depends-Indep. Policy is quite clear about that being a bug. I think a better rule of thumb for maintainers in a hurry would be: if you don't have time to think about which dependency list is the right one, and preferably test the result (with a source-only build like Adam has been doing, a --build=all build, and a --build=any build), then the safe option is to put everything in B-D. smcv
Re: FTBS bugs -- MBF?
Package: dh-golang Severity: wishlist Control: retitle -1 dh-golang unnecessary call for go command in clean target > Apparently there's not a single package that needs B-D-Arch. I've just > looked in case if sbuild installs those by default, but it's not the case. > A sample package (acmetool) for example says: > > dh clean --buildsystem=golang --with=golang,apache2 >dh_auto_clean -O--buildsystem=golang > Can't exec "go": No such file or directory at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443. > Use of uninitialized value in pattern match (m//) at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443. > Can't exec "go": No such file or directory at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449. > Use of uninitialized value in pattern match (m//) at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449. > Use of uninitialized value $_gcc_major in multiplication (*) at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450. >dh_autoreconf_clean -O--buildsystem=golang >dh_clean -O--buildsystem=golang > dpkg-source -b . Looks like a bug in dh-golang, it shouldn't need to use the compiler to clean. -- Shengjing Zhu
Re: FTBS bugs -- MBF?
On Sun, Oct 02, 2022 at 08:40:04AM +0200, Lucas Nussbaum wrote: > On 02/10/22 at 04:23 +0200, Adam Borowski wrote: > > 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. [...] > > This leaves one big set: packages that fail the clean step due to > > undeclared B-Depends. [...] > > ... 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. [...] > > As 291 packages fail this requirement, I'm posting here before (instead?) > > filing bugs. There's also a question of severity. > Are you saying that those 291 packages fail when only > Build-Depends/Build-Conflicts are satisfied, but do not fail when > Build-Depends-Indep is also satisfied? Yes, exactly. > FWIW, when I do archive rebuilds, I rebuild the source, but that's with > Build-Depends-Indep installed. Apparently there's not a single package that needs B-D-Arch. I've just looked in case if sbuild installs those by default, but it's not the case. A sample package (acmetool) for example says: dh clean --buildsystem=golang --with=golang,apache2 dh_auto_clean -O--buildsystem=golang Can't exec "go": No such file or directory at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443. Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443. Can't exec "go": No such file or directory at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449. Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449. Use of uninitialized value $_gcc_major in multiplication (*) at /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450. dh_autoreconf_clean -O--buildsystem=golang dh_clean -O--buildsystem=golang dpkg-source -b . but succeeds. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Genetics say, virgin birth may not possibly produce male offspring. ⣾⠁⢠⠒⠀⣿⡁ Thus, either Jesus was fathered by (Abdes?) Pantera, or she was trans. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄ In neither case Joseph is involved, making Jesus a bastard.
Re: FTBS bugs -- MBF?
On 10/2/22 04:23, Adam Borowski wrote: 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. Shouldn't Build-Depends-Indep be considered as part of Build-Depends? Packages that only build Architecture: all binary packages tend to use Build-Depends-Indep. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: FTBS bugs -- MBF?
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. Hi, Are you saying that those 291 packages fail when only Build-Depends/Build-Conflicts are satisfied, but do not fail when Build-Depends-Indep is also satisfied? FWIW, when I do archive rebuilds, I rebuild the source, but that's with Build-Depends-Indep installed. Lucas