Bug#960769: swt4-gtk FTBFS on 32bit

[tony mancill]

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