https://buildd.debian.org/status/package.php?p=swt4-gtk&suite=sid

...
callback.c:697:2: error: initializer element is not constant
  697 |  (jlong)FN(0, args), \
      |  ^
...

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.

Kind Regards,

Bas

The binaries for the 32-bit architectures were removed in #962915 [1],
but only for version 4.13.0-1 in unstable.  bullseye still contains the
binaries [2].  From the RM email:

Is the problem here that we need to RM all of the rdeps on those
architectures from unstable as well?  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" ?

Thanks,
tony

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962915
[2] https://packages.debian.org/bullseye/libswt-glx-gtk-4-jni

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

At least in the case of openjfx (and its non-arch:all rdeps).
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

I see.  It sounds like the RM should remove the set of transitive
(non-arch:all) rdeps.
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

It turns out there was already an RM bug filed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969975

I will merge the duplicate I created into it:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971730

Hi,

[Release Team member hat on]: I have added hints to allow the breakage
on i386 as this was now done on purpose. I've been watching this issue
since August, but was waiting for all the right binary packages in
unstable to be removed. This bug at severity serious was preventing
swt4-gtk from migrating to testing, but as the 32 bit packages were
removed, this bug should no longer blocking migration, hence I downgrade
it now.

Paul

Hi Paul,

openjfx is still not migrating to testing, the britney output complains
about several arch:all packages on i386:

 trying: openjfx
skipped: openjfx (1, 0, 30)
    got: 91+0: a-1:a-0:a-0:a-0:i-89:m-0:m-0:p-0:s-1
    * i386: josm, libafterburner.fx-java, libjavafxsvg-java,
libopenjfx-java, mediathekview, pdfsam, starlink-topcat-java, topcat,
topcat-doc, zeroc-ice-all-runtime, zeroc-ice-utils-java, zeroc-icegridgui

Some more allow-uninst hints are likely needed for the other packages.

Kind Regards,

Bas

Hi Paul,

Thanks for the additional allow-uninst hints, it finally let openjfx
migrate to testing.

Kind Regards,

Bas

Hi Sebastiaan,

You're welcome. Thanks for pinging me.

Paul