Bug#960769: swt4-gtk FTBFS on 32bit
Hi Sebastiaan, On 22-10-2020 09:44, Sebastiaan Couwenberg wrote: >> Some more allow-uninst hints are likely needed for the other packages. > > Thanks for the additional allow-uninst hints, it finally let openjfx > migrate to testing. You're welcome. Thanks for pinging me. Paul signature.asc Description: OpenPGP digital signature
Bug#960769: swt4-gtk FTBFS on 32bit
Hi Paul, On 10/21/20 4:30 PM, Sebastiaan Couwenberg wrote: > On Thu, 15 Oct 2020 10:07:28 +0200 Paul Gevers wrote: >> On Mon, 5 Oct 2020 06:30:51 +0200 Sebastiaan Couwenberg wrote: 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: >> >> [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. > > 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. Thanks for the additional allow-uninst hints, it finally let openjfx migrate to testing. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#960769: swt4-gtk FTBFS on 32bit
Hi Paul, On Thu, 15 Oct 2020 10:07:28 +0200 Paul Gevers wrote: > On Mon, 5 Oct 2020 06:30:51 +0200 Sebastiaan Couwenberg wrote: > > > 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: > > [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. 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 -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#960769: swt4-gtk FTBFS on 32bit
Control: severity -1 important Hi, On Mon, 5 Oct 2020 06:30:51 +0200 Sebastiaan Couwenberg wrote: > > 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: [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 signature.asc Description: OpenPGP digital signature
Bug#960769: swt4-gtk FTBFS on 32bit
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
Bug#960769: swt4-gtk FTBFS on 32bit
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
Bug#960769: swt4-gtk FTBFS on 32bit
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
Bug#960769: swt4-gtk FTBFS on 32bit
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. 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? 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
Bug#960769: swt4-gtk FTBFS on 32bit
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. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#960769: swt4-gtk FTBFS on 32bit
Source: swt4-gtk Version: 4.15.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=swt4-gtk=sid ... callback.c:697:2: error: initializer element is not constant 697 | (jlong)FN(0, args), \ | ^ ...
