On Sat, Sep 27, 2025 at 08:37:16AM +0200, Paul Gevers wrote: > The devref recommends [2] to inform/discuss this on [email protected]. I > recommend you follow the devref recommendation and state your intentions > before doing such a new mass bug filing. I suggest to use some or all of the > text from [1] in both the message to d-devel as well as in your bug reports; > at the very least reference it. I'm slightly concerned about good > communications here, because I believe this is delicate. For maintainers, > the trivial way to avoid this RC issue is to no longer annotate > Build-Depends with <!nocheck>, but we are also asking people to actively do > that. Your mass bug filing should not lead to the wrong mindset.
Hmm, ok, I will send something to -devel, but note that at some point such inform/discuss should be considered implicit and taken from granted. (After all, I don't send anything to -devel when I reported 400 FTBFS bugs the last time, I believe people just expect them as a normal thing). Therefore, I hope you don't mind if I try to convey the idea that future mass reporting covering this particular mode of failure will not have a previous annoucement in -devel anymore. I think it would help if you updated Release Policy to reflect this, the canonical place to check if something is RC or not. Regarding the text of the bugs, I've started this page: https://wiki.debian.org/qa.debian.org/FTBFS/Nocheck which I will intend to reference in the bug reports, so that the template may be a little bit shorter. Such page in turn has a reference to your annoncement. You are welcome to fine-tune the wording regarding the "how to fix them" section to emphasize that we only want to remove <!nocheck> annotations when it's really necessary. While we are at it, removing <!nocheck> is what we are calling the "trivial fix", but you would be surprised at how many non-trivial bugs are there of this kind. As an example, yesterday I fixed a package which had this in debian/rules: parallel := 1 $(eval $(DEB_BUILD_OPTIONS)) This worked by pure chance when DEB_BUILD_OPTIONS=parallel=N but not if we also have "nocheck" after parallel=N... The package had only two build-dependencies, and none of them used <!nocheck>. So, if someone wants to document more cases in the above wiki page other than the trivial one, they are more than welcome. I just can't think right now of another "big" category that we could put there. To me they are all different, but maybe it's just because I've not tried to fix too many of them myself yet. Thanks.
