On Thu, 09 Jan 2025 at 11:29:32 -0500, Paul Tagliamonte wrote: > On Thu, Jan 09, 2025 at 04:02:46PM +0000, Simon McVittie wrote: > > Sorry, I don't see how a binNMU would help? > > Sorry, I meant NMU. Was typing fast -- if a binNMU is still building for > an arch, we can NMU it to exclude that arch so future binNMUs are > excluded from the arch. It would likely also happen with a routine > maintainer upload.
Do you mean changing the package from Architecture: any to Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 alpha hppa hurd-amd64 hurd-i386 loong64 m68k powerpc ppc64 sh4 sparc64 x32 ? Yes is technically possible to do that, but it scales really, really badly: every time a new architecture gets added, its porters will ask for their architecture to be added to the list in each one of potentially hundreds of source packages that has done this. What I've generally seen as a preferred technique is to make sure that if a package should not be rebuilt on architectures that are missing some component (in this case gimp, but it could equally well be rustc or systemd or whatever), then it has a Build-Depends on something from that component, so that the package is built successfully on architectures that have it, and left in BD-Uninstallable state on architectures that don't. And https://buildd.debian.org/status/package.php?p=gimp-texturize shows that this is working as intended: it isn't being built on alpha, hppa, hurd-amd64, m68k, powerpc or sh4. Similarly, in https://buildd.debian.org/status/package.php?p=gjs , gjs isn't being built on armel (we had to remove it from armel because its dependency mozjs128 no longer supports CPUs without lock-free atomics) even though all of gjs' binary packages are Architecture: any. The only time we need ftp team intervention for this is when a component that was previously available on a release architecture becomes long-term unavailable on that architecture, at which point the ftp team acts as a second opinion for "is this removal reasonable?" and hopefully agrees with the judgement of the maintainers of affected packages. > When we do a partial rm, we're only removing the binary from the arch, > we're not perma-blocking a package / rejecting / stripping .debs on that arch > for future uploads. Yes, I understand that. If gimp somehow becomes successfully buildable on s390x again (including passing tests, etc.), then I think we have no problem with gimp-dependent packages like -texturize also reappearing on s390x. > I processed the gimp bug, so if you file a new rm bug for gimp-texturize > after "Architecture: any" drops s390x (via a maintainer upload or NMU) > we should be good. I reported the bug, but as above, I don't think source changes in gimp-texturize are necessary or even desirable. smcv
