Hello Holger et al. I was trying hard not to reply in this thread, but there are some things that I'd like to point out and clarify.
El 10/10/23 a las 16:54, Holger Levsen escribió:
but why?
As Johannes has already replied, and I agree, there will be always somebody annoyed, and we don't have an "annoyometer" to decide who should be annoyed and who should not.
also because technically it's the right decision from the release team. these bugs are *currently*, in real life, merely cosmetic.
People forget easily that debootstrap is not the only tool to create chroots. As Johannes has pointed out in other threads (maybe not here), there are several different tools which need to implement "build-essential packages" in some way or another. And debootstrap was the only one who implemented this differently. *That's* what I would call annoying, not Debian Policy. But we are not driven by annoyance (or we should not), we are driven by policies and procedures, which represent, in theory, past discussions and the consensus that derived from them. It has been quite unfortunate for people working on QA that at this point people wanted to dispute something as fundamental as "packages must not have missing build-depends". You say this was "the right decision", but it was in fact a step backwards, because this was already declared "ok to be serious" by another Release Manager a long time ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836940#185 and this was already used by Lucas Nussbaum in the past to report "missing BD:tzdata" bugs as serious. Fortunately and hopefully debootstrap will be fixed soon and we can all stop worrying about this issue. However, at the very minimum, I would have expected this to be made not-RC by using the established procedure for that at the time, namely the bookworm-ignore tag: Further to this, certain issues may be exempted from being considered release critical for bookworm by a release manager. This is expressed by tagging the report "bookworm-ignore" I would still like some Release Manager (not necessarily Sebastian) to acknowledge this.
policy is not a stick to hit with.
I could agree with that, but only if we also agree on this one: "policy is not a stick to hit with" is not a stick to hit with In particular, I see several people in this project hitting people with "it does not happen in the buildds" as an excuse to downgrade perfectly valid FTBFS bugs. I invite you to take a look at what is probably the weirdest FTBFS bug I've ever reported: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028163 (TLDR: The test suite was using the "ssh" command without BD on openssh-client and it was also using the ssh service from the machine hosting the chroot!) Does somebody (other than the DD who tried to downgrade it) really think the package was suitable for release in such state just because it did not fail in the buildds? The debci infrastructure usually keeps packages from entering testing for much less. Thanks.
