On 23/04/2023 21:07, Paul Gevers wrote:
Can you point to a discussion where we might draw the conclusion that
this is common practice or consensus? I *personally* [no hats on] find
that distinction a bit weird although I can see how we would come to
it and also why.
No, I can't point to a discussion. I vaugely remember hearing it from a
more experianced developer (possiblly a release team member) on IRC
years ago.
But it has been consistent with how I have seen bugs handled in practice
over my years in Debian.
It's also consistent with how britney behaves or at least did until very
recently. My understanging is that britney performs architecture checks
on all release architectures where a package is built for arch specific
packages, but only performs architecture checks on a small subset of
architectures (when I first started with Debian it was i386 only, I
think now it's amd64 and arm64, maybe also i386) for arch all packages.
I have vauge reccollections of a document descirbing the different
behaviour for arch all packages in britney as a "hack", so I presume
this is something that started as a hack and then just became the status
quo. If you wanted your package in testing and it was arch specific you
had to make sure it was installable on all architectures where it was
built, but if it was arch all you did not (and often could not).
I have seen people ask the release team for exceptions when their
arch-all package is not installable on one of the architectures where
arch all packages are checked but I can't recall ever seeing such a
request for an arch-specific package.
And when I look at
https://qa.debian.org/dose/debcheck/testing_main/index.html this seems
to back up my observation.
That does leave the question of how brial with this bug migrated to
testing in the first place. Whether there was a recent intentional
change in britney, whether there was a bug/glitch, or whether it was
forced in (and if-so who forced it).
This seems to be your real issue. Why file the bug against
python3-brial?
When an issue involving multiple packages shows up on my radar, I
tend to start by filing a bug with the package where a fix could
potentially have the most impact and cc the maintainers of other
packages that are involved.
Ack. And I agree with this approach. However, we are *also* in the
Hard Freeze, so RC bugs reports have more severe results if not
treated swiftly.
Agreed, given where we are in the Freeze, enough time has passed to file
a rc bug against singular with an expression of intent to NMU. I'll do
that later today.
I also hereby announce that I intend to NMU brial if I don't get a
maintainer response soon.
(I am assuming Paul is posting as a release team member and not as a
maintainer of the package, if that is wrong please speak up)
