Bug#960769: swt4-gtk FTBFS on 32bit

[Sebastiaan Couwenberg]

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).

> 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.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1