Hi Charles, On 11/27/25 10:32, Jochen Sprickerhof wrote:
Hi Charles, * Charles Plessy <plessy@debian.org> [2025-11-27 18:16]:I plan to rebuild all the r-* packages with restricting them to 64-bit little-endian architectures.Do you think we can coordinate the two mass uploads?Yes, absolutely.
The request from Jochen and me was about binNMU, which doesn't require uploads. Obviously that request becomes moot if your mass upload happens.
Btw. could you also do at lest no change uploads of the arch all packages listed here:https://reproduce.debian.net/all/stats/forky/#dpkg-buildpackage-failed:- dh-r-(#1089197) https://reproduce.debian.net/all/stats/forky/#failed-to-reproduce:-dh-r- (#1089197)That would help us a lot!
Jochen mentions these as arch:all binaries aren't binNMU-able. However, I'd expect they are also not part of your restrict-arch mass upload either. So this is an orthogonal request.
On my side I have been delaying it for a long time because I am under theimpression that the packages must first move out of testing to clear out the unsupported architectures, and I yet have to find a reasonably minimal set ofpackages that I can action to acheive that.
Or shall I just open a RC bug on all of them, and then mass-close the bugs once the work is done, without changing them in the changelog? The issue is I do not have the techical knowledge to make a mass upload of hundred of packagesclosing hundreds of different bugs...You could simply upload the new packages and fill removal bugs against ftp.debian.org afterwards.
With a bit more information, hoping that's useful. Removal from testing isn't required as far as I can tell. What need to happen is that binaries on the no longer supported architectures need to be removed from unstable (by filing RM bugs against ftp.debian.org, they normally want one bug per (source) package). I'm not 100% sure, but I think the cravat is that you need to prevent the buildds from picking up the build again and building new versions of the binary on the architecture you just had removed. (I don't think the buildds are smart enough to know that the package built in the past for the same version and thus prevent building it again). So, if the build doesn't fail or is prevented from building currently, you need to fix that first and then have ftp-master remove the binaries on those architectures. Once the full set of binaries for a particular architecture from a given source is removed in unstable and no longer has reverse dependencies in testing, the set will be removed from testing too. Although with a new source in unstable I think that happens only once the new source migrates too.
So, I think for you mass upload it's probably the easiest to start with leaf packages and then work your way up the stack, unless you make special arrangements with ftp-master.
Be aware that there are r-* package in the key packages set. If any of them is on the list you want to drop 64 bit support for, you'll need to take care of the reverse (build) depends first. key packages are hard to remove from testing.
Paul
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature