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
FTBS bugs -- MBF?
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. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ A tit a day keeps the vet away. ⠈⠳⣄ adduser arandr aspell-bn aspell-gu aspell-hi aspell-it aspell-kn aspell-ml aspell-mr aspell-or aspell-pa aspell-pl aspell-sl aspell-ta aspell-te beaker biojava4-live bkchem bleachbit blends bless c++-annotations c3p0 caveconverter cecil cecil-flowanalysis cl-asdf-finalizers cl-asdf-system-connections cl-closure-common cl-command-line-arguments cl-containers cl-curry-compose-reader-macros cl-cxml cl-daemon cl-db3 cl-dynamic-classes cl-ftp cl-garbage-pools cl-github-v3 cl-graph cl-ieee-floats cl-ixf cl-local-time cl-log cl-lparallel cl-markdown cl-metatilities-base cl-mssql cl-parse-number cl-py-configparser cl-qmynd cl-quri cl-rfc2388 cl-salza2 cl-sqlite cl-trivial-utf-8 cl-utilities cl-uuid cl-who cl-yason cl-zip cl-zs3 classycle cmd2 colplot confy context-nonfree coq-doc darcula db4o dbus-sharp dbus-sharp-glib debian-astro debian-electronics debian-fbx debian-gis debian-hamradio debian-junior debian-med debian-multimedia debian-pan debian-science debichem developers-reference dhcpy6d django-axes django-cacheops django-filter django-graphene django-graphiql-debug-toolbar django-ipware django-pglocks django-rich django-rq django-simple-captcha django-tables django-taggit djvubind docbook-xml dput drf-yasg-nonfree dstat dtrx dynalang easygit editorconfig-core-py elasticsearch-curator fonts-arundina foolscap fop fortunes-debian-hints freeplane funnyboat ghp-import git-publish gramps graphql-core graphql-relay graxxia gvb hachoir howm hunchentoot imagej isenkram isorelax jaligner jclic jcommander jheatchart jlha-utils jline jruby-joni jsxgraph jtb jupyter-sphinx-theme jvyamlb jxplorer jython klaus kunststoff latex-make latex2html lazygal lfm libcobra-java libitext1-java libjlha-java libjspeex-java libjt400-java liblastfm-java libpal-java libpdfbox-java libpixie-java libproxool-java libsoftware-copyright-perl libswarmcache-java libvorbisspi-java libyanfs-java logging-tree logilab-constraint mcomix mergedeep messagingmenu-sharp metastudent mkdocs-autorefs mkdocs-material-extensions mkdocs-redirects mkdocstrings mkdocstrings-python-handlers mkdocstrings-python-legacy mobile-atlas-creator monajat mono-addins mono-tools mpd-sima nagstamon nant nekohtml net-luminis-build-plugin nini notify-sharp-3.0 ognl onionbalance osmnx othman pagekite paste pastescript pdfposter piccolo pixelmed pixelmed-codec plm png-sixlegs postgis-java psycopg3 puddletag pygments pyracerz pyro4 pyroma pyroute2 python-amqp python-arrow python-bleach python-bottle python-box python-cookies python-daemon python-django-braces python-django-crispy-forms python-django-crispy-forms-foundation python-django-debug-toolbar python-django-tagging python-docutils python-dotenv python-elasticsearch python-flickrapi python-funcy python-gitlab python-graphene python-griffe python-irc python-k8sclient python-l20n python-ldappool python-libusb1 python-lunr python-markdown-include python-markuppy python-marshmallow python-network python-nmap python-opcodes python-prometheus-client python-promise python-pydub python-q python-readme-renderer python-repoze.tm2 python-requests-toolbelt python-roman python-smstrade python-socksipychain python-stem python-tablib python-tempita python-text-unidecode python-u2flib-server pytkdocs pyvo pyyaml-env-tag recommonmark resteasy3.0 rst2pdf runsnakerun safeeyes sat4j seahorse-adventures sentry-python serpent simplyhtml smuxi solaar sphinx squaremap svgsalamander swagger-spec-validator swing-layout swtcalendar taoframework terraintool towncrier tp-smapi translate-toolkit tunnelx uncertainties unittest2 urlscan velocity-tools virtualenvwrapper w3c-linkchecker weather-util webtest xhtml2pdf xom yapps2 yapsy yaret yorick-cubeview Aggelos Avgerinos elasticsearch-curator (U) Agustin Henze yapsy Alexandre Rossi lazygal (U) Andrea Colangelo python-roman (U) Andreas Tille blends (U) debian-gis (U) debian-med
