Dear Release Managers:

AFAIK, this was going to be RC for trixie, but in the last minute you
requested to file remaining bugs as important, because there were more
affected packages than expected and the release was close.

For forky, I will try to report this category of bugs in a more
consistent way (i.e. more often and not letting those issues to
accumulate without reporting them). Currently I have around 220 bugs
pending to be reported, and I would like to report them like this:
but the severity will be raised to "serious" after some weeks.
------------------------------------------------------------------------

If this is ok for you, I will proceed.

Alternatively, if you think it would be better, I could also report
them directly as serious, considering that testing currently has more
than 1300 RC bugs due to GCC 15, CMake 4, and others.

Thanks.

Hi Santiago,


This issue is RC since since we announced it in [1] and I have seen
multiple bug reports at severity serious. What we asked you to not do is
to start a mass bug filing at severity serious so close to the trixie
release for an issue we haven't done mass bug filing for before and for
which at the time there was no practical impact on the reason why we
made the issue RC. We were fearing too much maintainers would not
understand that they shouldn't rush in a solution for that particular
problem so close to the release if not bundled with other reasonable
fixes. We see too often that people don't read or grasp the details and
just trigger on RC bugs, even if the tagging says it doesn't need to be
solved immediately in unstable.


Great, that way we avoid mass filings in the future.


The devref recommends [2] to inform/discuss this on debian-devel@l.d.o.
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.

Thank you for working on this.

Paul


[1] https://lists.debian.org/debian-devel-announce/2022/10/msg00004.html
[2]
https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#reporting-lots-of-bugs-at-once-mass-bug-filing

One option would be linking to a wiki page listing common problems and
their usual solutions.

This is also more updatable than the text of an email.

That's only one class of bugs.

m68k and sh4 build with nocheck for years but do install <!nocheck>
build dependencies during the build, and while the resulting number
of (so far non-RC) FTBFS bugs filed and fixed  for that over the years
was not huge it has been a constant source of bugs.

There are also non-FTBFS issues regarding nocheck:

The contents of the packages must not change with nocheck.

Is running tests despite nocheck now RC?

cu
Adrian

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.

Hi,


That's exactly what I implied. This is a new category, hence one thread
on d-devel makes sense to me.


How many appear to be in the non-trivial class? To be fair, I didn't
consider this twist.

Paul