On Mon, Oct 05, 2020 at 06:30:51AM +0200, Sebastiaan Couwenberg wrote: > On 10/5/20 6:04 AM, tony mancill wrote: > > On Sun, Oct 04, 2020 at 04:34:17PM +0200, Sebastiaan Couwenberg wrote: > >> Control: severity -1 serious > >> Control: affects -1 src:openjfx > >> > >> This issue is preventing testing migration of swt4-gtk, it also blocks > >> openjfx builds on the architectures where swt4-gtk FTBFS preventing the > >> fix for #967185 from migrating to testing. > >> > >> Either fix the build or request removal of swt4-gtk and its rdeps from > >> these architectures. > > > > The binaries for the 32-bit architectures were removed in #962915 [1], > > but only for version 4.13.0-1 in unstable. > > This was not sufficient to let it migrate to testing. > > The britney output logs a bunch of packages on i386. > > i386 & amd64 are the NOBREAKALL_ARCHES in britney.conf, see: > > https://release.debian.org/britney/britney.conf > > > bullseye still contains the > > binaries [2]. From the RM email: > > > >> Packages are usually not removed from testing by hand. Testing tracks > >> unstable and will automatically remove packages which were removed > >> from unstable when removing them from testing causes no dependency > >> problems. The release team can force a removal from testing if it is > >> really needed, please contact them if this should be the case. > > > > Is the problem here that we need to RM all of the rdeps on those > > architectures from unstable as well? > > At least in the case of openjfx (and its non-arch:all rdeps).
I see. It sounds like the RM should remove the set of transitive (non-arch:all) rdeps. > > If that's sufficient, I can put > > together that RM request. > > > > Also, shouldn't we explicitly enumerate the supported Architectures in > > the next upload of swt4-gtk instead of specifying "Architecture: all" ? > > You mean "Architecture: any" I presume? If so, you could do that, but > maintaining the list of architectures over time is a PITA from my > experience, I wouldn't recommend it unless swt4-gtk only sometimes fails > to build on these architectures. If it's persistent removing the > packages from those architectures should suffice. Once its rdeps are > removed as well they will be in BD-Uninstallable state on those archs. > But because of the RM the missing binaries won't block testing migration. Oops - yes, I meant "Architecture: any" and thank you for the guidance here. It sounds like the arch-specific RM acts like a mask that will prevent the auto builders on the RM'd arches from attempting to rebuild subsequent source uploads. (As I type that, I realize that I should know that already. But arch-specific RMs don't occur that often for the Java Team packages.) Thank you again, tony