On 2025-10-10 16:28, Mathias Gibbens wrote:
Thanks for taking care of that, although I think we'll need a
separate RM bug for [armel armhf i386] before it will be able to
migrate to testing.
You might be right. However, that's not my reading of
https://wiki.debian.org/ftpmaster_Removals:
| The release team can remove source packages - and *all* binaries built
from them - from testing. Per-architecture removals from testing are not
handled by the Release Managers directly, but rather as a result of the
package's state in unstable propagating to testing.
This also matches the behavior of reportbug:
siretart@x1:~ $ reportbug release.debian.org
*** Warning: You are trying to set an X-Debbugs-CC header. This is
possibly an old default setting from your ~/.reportbugrc. In that case
you may want to re-run 'reportbug --configure', or
edit your configuration file to use the 'list-cc-me' command (without
recipient address) instead. If you used the -H option on the command
line, please see the '--list-cc' option. Reportbug
cannot handle custom headers reliably with its MUA support, it is
therefore recommended to use pseudoheaders instead where possible.
*** Welcome to reportbug. Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of
the submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.
Using 'Reinhard Tartler <[email protected]>' as your from address.
Will send report to Debian (per lsb_release).
What sort of request is this? (If none of these things mean anything to
you, or you are trying to report a bug in an existing package, please
press Enter to exit reportbug.)
1 binnmu binNMU requests
2 bookworm-pu bookworm proposed updates requests
3 britney testing migration script bugs
4 other None of the other options
5 rm Stable/Testing removal requests
6 transition transition tracking
7 trixie-pu trixie proposed updates requests
8 unblock unblock requests
Choose the request type: 5
Please enter the name of the package: msgp
Checking package information...
Your report will be carbon-copied to the package maintainer.
Latest version seems to be 1.2.5-1+b4, is this the proper one [Y|n|?]? y
Is this request for specific architectures [y|N|?]? y
The proper way to request a partial removal from testing is to file a
partial removal from unstable: this way the package for the specified
architectures will be automatically removed from
testing too. Please re-run reportbug against ftp.debian.org package.
siretart@x1:~ $ rmadison msgp
msgp | 1.0.2-3+b6 | oldoldstable | amd64, arm64,
armhf, i386
msgp | 1.1.6-1+b4 | oldstable | amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
msgp | 1.2.0-1~bpo12+1 | oldstable-backports | amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
msgp | 1.2.5-1+b4 | stable | amd64, arm64,
armel, armhf, i386, ppc64el, riscv64, s390x
msgp | 1.2.5-1+b4 | testing | amd64, arm64,
armhf, i386, ppc64el, riscv64, s390x
msgp | 1.2.5-1+b4 | unstable | armel, armhf, i386
msgp | 1.4.0-2 | buildd-unstable | amd64, arm64,
mips64el, ppc64el, riscv64, s390x
msgp | 1.4.0-2 | unstable | amd64, arm64,
mips64el, ppc64el, riscv64, s390x
My understanding / assumption is that at some point in the future, the
"auto-decruft" mechanism (cf.
https://people.debian.org/~nthykier/blog/2015/introducing-dak-auto-decruft.html)
should kick in and remove the remaining msgp binaries with the version
1.2.5-1+b4 from unstable. After that, britney removes them from testing
and allows the migration.
I don't know how long that takes though. Niels, am I on the right track
or am I missing something? Do I need to file a bug against
ftp.debian.org?
Also, if you're not aware of `architecture-properties`, it's a nice
meta-package for situations like this. Rather than trying to enumerate
all non-32bit architectures, you can simply add a Build-Depends on
`architecture-is-64-bit`. That will give you the same result, but I
think it's cleaner and more future-proof. (There's no need for another
upload right now, but I'll include that change in the next update.)
Thanks for pointing me to it, that's neat!
-rt
