XPost: linux.debian.devel.release
El 9/4/25 a las 14:26, Jeremy Bícha escribió:
Note that both gcr and gcr4 are key packages, so a serious severity
will not make the package to be removed.
It feels like there is less reason to argue about severity for gcr & gcr4 then?
Less reason to downgrade without asking RMs first, as you did.
Remember: we do not hide problems. Somebody should look at this bug
during Bug Squashing Parties, even if it does not make the package
to be removed.
A brief explanation for the maintainers that we don't want
flaky tests in trixie would also be nice.
"flaky" is vague and until there is a specific standard for failure
rate, this is going to be subject to maintainer discretion to some
degree.
As of 4.4.0.1, gcr4 does not appear to be flaky at all in the official buildds or on the reproducible builds server:
What happens in the buildds remains in the buildds. Whoever wants to
rebuild the package from source will not do so in the official buildds.
You are still violating Policy 4.2 for no particular reason.
If build-time dependencies are specified, it must be possible to build the package and produce > working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (
including any implied relationships).
We should not rely on a test which segfaults to determine if the package
is good or not. If the Release Managers still think this is ok
"because it works in the buildds", I can still call the TC for
your unwillingness to follow Debian Policy 4.2.
Please stop wasting everyone's time and disable the test which segfaults.
Do you need a patch for that?
Thanks.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)