Re: Status of the t64 transition
On Sun, Apr 28, 2024 at 02:28:30PM +0200, Paul Gevers wrote: > > Can you please look at libproxy<->glib-networking? libproxy excuses show > > glib-networking tests failing, but they are working in sid. > > And that's not missing a versioned Depends and/or Breaks? I.e. this is a > test only failure? I'm not a maintainer of either of them and I couldn't understand from the test failure what's the reason of it. Jeremy, can you please look at it and help it migrate? -- WBR, wRAR signature.asc Description: PGP signature
Re: Status of the t64 transition
Hi, On 27-04-2024 7:52 p.m., Andrey Rakhmatullin wrote: Can you please look at libproxy<->glib-networking? libproxy excuses show glib-networking tests failing, but they are working in sid. And that's not missing a versioned Depends and/or Breaks? I.e. this is a test only failure? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
On Wed, Apr 24, 2024 at 07:38:42PM +0200, Paul Gevers wrote: > Hi, > > On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: > > What to do with autopkgtests that fail in testing because of problems with > > packages in testing that are fixed in unstable, e.g. the autopkgtest for > > speech-dispatcher/0.11.5-2 on > > Inform the Release Team and we can either schedule the combination manually, > add a hint or both. Can you please look at libproxy<->glib-networking? libproxy excuses show glib-networking tests failing, but they are working in sid. -- WBR, wRAR signature.asc Description: PGP signature
Re: Status of the t64 transition
Hi, On 24-04-2024 7:42 p.m., Jérémy Lal wrote: Inform the Release Team and we can either schedule the combination manually, add a hint or both. Isn't it processed automatically ? What needs manual intervention and what doesn't ? Well, the migration software *tries* to figure out combinations that need to go together. It's greedy, but not infinitely so (otherwise we'd just look at unstable). If a test fails, reference runs are used to compare it to. If the reference run doesn't fail a test is a regression. Regressions are retried (after a day). Reference runs for regressions are rescheduled once they are a week old. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Hi, On 24-04-2024 7:38 p.m., Paul Gevers wrote: On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on Inform the Release Team and we can either schedule the combination manually, add a hint or both. Or in cases like this, wait a bit. The test regressed in testing, which the migration software figures out automatically. (If you want to see earlier, you can retry "migration-reference/0" runs, which I already did for speech-dispatcher). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
Le mer. 24 avr. 2024 à 19:39, Paul Gevers a écrit : > Hi, > > On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: > > What to do with autopkgtests that fail in testing because of problems > with > > packages in testing that are fixed in unstable, e.g. the autopkgtest for > > speech-dispatcher/0.11.5-2 on > > Inform the Release Team and we can either schedule the combination > manually, add a hint or both. > Isn't it processed automatically ? What needs manual intervention and what doesn't ?
Re: Status of the t64 transition
Hi, On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote: What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on Inform the Release Team and we can either schedule the combination manually, add a hint or both. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Status of the t64 transition
On Wed, Apr 24, 2024 at 08:51:48AM +0200, Sebastian Ramacher wrote: > If you wonder how you are able to help with the migration, here are > some things to do: > * Fix FTBFS bugs > * Check the status of autopkgtests [1] and report or fix any issues > related to failing tests. > * Check if source-only uploads for Arch: all packages are missing. What to do with autopkgtests that fail in testing because of problems with packages in testing that are fixed in unstable, e.g. the autopkgtest for speech-dispatcher/0.11.5-2 on https://qa.debian.org/excuses.php?package=glib2.0? -- WBR, wRAR signature.asc Description: PGP signature
Re: Status of the t64 transition
Hi, dpkg and gcc with t64 enabled migrated to trixie last night. The other packages will slowly migrate as we fix the remaining blockers (autopkgtest regressions, FTBFS bugs, etc). Be aware that temporary removals from trixie may occur to get packages (especially key packages) unstuck as we work through all the packages hat need to migrate. Since the time_t bugs are now also RC in trixie, I will reraise the severity of all time_t bugs to serious in 1 week. If you wonder how you are able to help with the migration, here are some things to do: * Fix FTBFS bugs * Check the status of autopkgtests [1] and report or fix any issues related to failing tests. * Check if source-only uploads for Arch: all packages are missing. Cheers [1] Note that wecurrently ignore autopkgtest results on armel and armhf. -- Sebastian Ramacher
Re: Status of the t64 transition
Hi Andreas, please stop reopening the time_t bugs where transitions are staged in experimental. When we eventually start those transitions, they do not need to change the package name again as they will enter unstable with a new SONAME and built with the 64 bit time_t ABI. Cheers -- Sebastian Ramacher
Re: Status of the t64 transition
Lists updated to omit packages not in testing: On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote: > Let's start with the first category. Those are packages that could be > binNMUed, but there are issues that make those rebuilds not have the > desired effect. This list include packages that > * are BD-Uninstallabe, > * FTBFS but with out ftbfs-tagged RC bug, > * have hard-coded dependencies on pre-t64 libraries, > * have $oldlib | $newlib dependencies (those are at least wrong on >armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are >decrufted), > * have been rebuilt before all dependencies were built, > * have broken symbols/shlibs files producing incorrect dependencies, > * or might just be missing the binNMU (but those should be few). (52 packages out of 78) arctica-greeter cegui-mk2 condor deepin-movie-reborn fastnetmon gentle gocryptfs gtk-chtheme haskell-gi-dbusmenugtk3 haskell-gi-gtk haskell-gi-gtk-hs haskell-gi-vte haskell-gtk-strut hugin jellyfish lcmaps-plugins-basic lcmaps-plugins-verify-proxy lcmaps-plugins-voms libcanberra libosmo-netif lightdm lightdm-gtk-greeter light-locker limesuite llvm-toolchain-17 lmms lyskom-server nautilus-wipe nfs-ganesha ppp prelude-lml prelude-manager purple-xmpp-carbons purple-xmpp-http-upload python-escript qt5-ukui-platformtheme quorum rtags sdpa seafile-client slick-greeter sonic-visualiser spectrwm spice-gtk swtpm tfortune trantor ukui-greeter urfkill vdeplug-pcap vdeplug-slirp xca > Next, packages that need an upload since they build Architecture: all > binaries depending on pre-t64 libraries: (9 packages out of 13) alsa-ucm-conf jruby mandos python-pylibdmtx pyzbar rapid-photo-downloader ruby-ethon ruby-ffi-libarchive sbmltoolbox > Finally, packages that need rebuilds but currently have open FTBFS (RC + > ftbfs tag) bugs: (57 packages out of 221) 3dchess acm adns barrier blasr cctools clanlib code-saturne das-watchdog deepin-log-viewer dub dvbstreamer epic4 epic5 eterm freebayes gnome-breakout google-compute-engine-oslogin gtkterm gyoto hping3 hplip httest isoquery kamailio kdrill kexec-tools klatexformula kluppe lftp linssid linuxtv-dvb-apps llvm-toolchain-16 loqui matchbox-keyboard matchbox-panel mdbtools mlpcap moonshot-ui ncrack netdiag nitrokey-app pesign pidgin-sipe porg projecteur raku-readline s390-tools siridb-server slrn spek tcptrack tightvnc tlog veusz wmweather+ xpra -- WBR, wRAR signature.asc Description: PGP signature
Re: Status of the t64 transition
On 18.04.24 21:22, Sebastian Ramacher wrote: Hi, as the progress on the t64 transition is slowing down, I want to give an overview of some of the remaining blockers that we need to tackle to get it unstuck. I tried to identify some clusters of issues, but there might be other classes of issues. Let's start with the first category. Those are packages that could be binNMUed, but there are issues that make those rebuilds not have the desired effect. This list include packages that * are BD-Uninstallabe, * FTBFS but with out ftbfs-tagged RC bug, * have hard-coded dependencies on pre-t64 libraries, * have $oldlib | $newlib dependencies (those are at least wrong on armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are decrufted), * have been rebuilt before all dependencies were built, * have broken symbols/shlibs files producing incorrect dependencies, * or might just be missing the binNMU (but those should be few). wine-development Ignore src:wine-development, it's in unstable only: #988246 wine-development: not intended for a stable release src:wine tracks the same upstream, currently has a newer version and is not on your list. So Wine should be fine. Greets jre
Re: Status of the t64 transition
All missing bugs about wrong deps are now filed. -- WBR, wRAR signature.asc Description: PGP signature
Re: Status of the t64 transition
Hi
thanks for checking all the packages and filing bugs!
On 2024-04-20 00:43:30 +0500, Andrey Rakhmatullin wrote:
> On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> > Let's start with the first category. Those are packages that could be
> > binNMUed, but there are issues that make those rebuilds not have the
> > desired effect. This list include packages that
> > * are BD-Uninstallabe,
> > * FTBFS but with out ftbfs-tagged RC bug,
> > * have hard-coded dependencies on pre-t64 libraries,
> > * have $oldlib | $newlib dependencies (those are at least wrong on
> >armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are
> >decrufted),
> > * have been rebuilt before all dependencies were built,
> > * have broken symbols/shlibs files producing incorrect dependencies,
> > * or might just be missing the binNMU (but those should be few).
> >
> > cegui-mk2
> not sure?
libcegui-mk2-dev has a hard-coded dependency on libxerces-c3.2. Should
be the corresponding -dev package, I guess.
> > condor
> not sure?
Hard-coded dependencies on pre-64 libraries:
Package: condor
Architecture: any
Depends: adduser,
libdate-manip-perl,
python3,
python3-requests,
libcom-err2,
libgssapi-krb5-2,
libk5crypto3,
libkrb5-3,
libkrb5support0,
libmunge2,
libssl3,
libscitokens0,
libvomsapi1v5,
net-tools,
libjs-bootstrap,
libjs-jquery,
${misc:Depends},
${perl:Depends},
${python3:Depends},
${shlibs:Depends}
> > deepin-movie-reborn
> not sure?
Hard-coded dependencies on pre-64 libraries:
Package: deepin-movie
Architecture: any
Depends:
libdmr0.1 (= ${binary:Version}),
libffmpegthumbnailer4v5,
libgstreamer-plugins-base1.0-0,
libgstreamer1.0-0,
libmpris-qt5-1 (>= 0.1.0.1),
libpulse0,
libqt5concurrent5,
va-driver-all,
${libmpv:Depends},
${misc:Depends},
${shlibs:Depends},
> > fastnetmon
> not sure?
Was BD-Uninstallable until 21h ago … could be fine now.
> > gentle
> not sure?
> > hugin
> not sure?
> > limesuite
> not sure?
Required binNMUs for wxwidgets3.2 on mips64el.
> > gvmd
> not sure?
Hard-coded dependencies on pre-t64 libraries:
Package: gvmd
Section: net
Architecture: any
Depends: adduser,
doc-base,
greenbone-feed-sync,
gvmd-common (= ${source:Version}),
libgvm22 (>= 22.4.0),
notus-scanner (>= 22.4.0),
ospd-openvas (>= 22.4.0),
pg-gvm,
xml-twig-tools,
${misc:Depends},
${postgresql:Depends},
${shlibs:Depends}
> > ippsample
> not sure?
Hard-coded dependencies on pre-t64 libraries:
Package: ippsample
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}, ippsample-data, libcups2
> > jellyfish
> not sure?
> > ncl
> not sure?
Handled in another sub thread.
> > libcanberra
> not sure?
Hard-coded dependencies on pre-t64 libraries: #1068936
> > libosmo-netif
> not sure?
Was recently reverted, the t64 libraries will need to be decrufted.
> > llvm-toolchain-17
> not sure?
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/8b318786ef954db7e3d0706c57b67114ac47dbc0
> > nautilus-wipe
> not sure?
Hard-coded dependencies on pre-t64 libraries:
Package: nautilus-wipe
Architecture: any
Multi-Arch: same
Depends:
libgsecuredelete0 (>= 0.3),
libgtk-3-0,
libnautilus-extension1a,
${misc:Depends},
${shlibs:Depends},
> > obs-advanced-scene-switcher
> not sure?
Hard-coded dependencies on pre-t64 libraries:
Package: obs-advanced-scene-switcher
Architecture: any
Multi-Arch: same
Depends: ${misc:Depends},
${shlibs:Depends},
libcurl4,
obs-advanced-scene-switcher-data (>= 1.16.3-1~),
obs-studio (>= 26.1.2)
> > perdition
> not sure?
Hard-coded dependencies on pre-t64 libraries:
Package: perdition
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libvanessa-socket2 (>= 0.0.12),
lsb-base (>= 3.2-14)
> > prads
> not sure?
Hard-coded dependencies on pre-t64 libraries:
Package: prads
Architecture: any
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}, libpcap0.8, libpcre3,
> > purple-xmpp-carbons
> not sure?
> > purple-xmpp-http-upload
> not sure?
#1069222
> > qt5-ukui-platformtheme
> not sure?
Hard-coded dependencies on pre-t64 libraries:
Package: libqt5-ukui-style1
Architecture: any
Depends: libglib2.0-0,
libqt5widgets5,
libgsettings-qt1,
${misc:Depends},
${shlibs:Depends}
> > quorum
> not sure?
False positive due to the jellyfish revert.
> > seafile-client
> not sure?
Hard-coded dependencies on pre-t64 libraries:
Package: seafile-gui
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends},
libsearpc1 (>= 3.2.0-8+really3.2+git20220425.54145b0),
libseafile0 (>= ${source-Upstream-Version}),
seafile-daemon (>=
Re: Status of the t64 transition
Hi Andreas On 2024-04-19 10:49:15 +0200, Andreas Tille wrote: > I've spotted these Debian Med packages. > > > gentle gentle required a rebuild for wxwidgets3.2 on mips64el. Done > > jellyfish The t64 changes were reverted. crac needs to rebuilt for this change so that libjellyfish-2.0-2t64 can be decrufted. I've scheduled binNMUs and excluded from further checks. > > quorum With jellyfish reverted, this one is fine. > > sbmltoolbox Builds an arch: all package with a dependency on a pre-t64 library. This will need an upload fixing this issue. > > vg > > This package is in a bad state in any case and we are aware of this. > However, could you explain in how far is this affecting t64 transition > since 32bit architectures are excluded? As said in my initial mail, I didn't exclude packages that are not part of testing. Patches welcome. Cheers -- Sebastian Ramacher
Re: Status of the t64 transition
On 2024-04-19 10:34:45 +0200, Simon Josefsson wrote:
> Sebastian Ramacher writes:
>
> > Hi,
> >
> > as the progress on the t64 transition is slowing down, I want to give an
> > overview of some of the remaining blockers that we need to tackle to get
> > it unstuck. I tried to identify some clusters of issues, but there might
> > be other classes of issues.
>
> Thanks for update. I haven't seen any response to my analysis of why
> 'shishi' shouldn't have t64-migrating, and lacking any response I
> eventually made an upload to revert the renaming. I've raised an Ubuntu
> bug too since they haven't synced the updated package. The Debian bug
> is now closed, so it wasn't included in your list, and maybe everything
> that can be hoped for is already achieved, but I wanted to mention as it
> ought to be on the t64 radar.
Thanks for letting us know. I'll exclude libshis{a,hi}0t64 in reruns of
my scripts. There are no reverse dependencies that need to be rebuilt,
so we only need to wait for the cruft to be removed from the archive.
Cheers
--
Sebastian Ramacher
Re: Status of the t64 transition
On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote: > Let's start with the first category. Those are packages that could be > binNMUed, but there are issues that make those rebuilds not have the > desired effect. This list include packages that > * are BD-Uninstallabe, > * FTBFS but with out ftbfs-tagged RC bug, > * have hard-coded dependencies on pre-t64 libraries, > * have $oldlib | $newlib dependencies (those are at least wrong on >armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are >decrufted), > * have been rebuilt before all dependencies were built, > * have broken symbols/shlibs files producing incorrect dependencies, > * or might just be missing the binNMU (but those should be few). > > 3depict BD-Uninstallable (mathgl FTBFS) > arctica-greeter fixed recently > cegui-mk2 not sure? > condor not sure? > courier FTBFS without a bug, filed > deepin-movie-reborn not sure? > fastnetmon not sure? > fcitx-kkc BD-Uninstallable (libkkc FTBFS) > gentle not sure? > gnome-subtitles FTBFS without a bug, filed > gocryptfs FTBFS without a bug, filed > gozer BD-Uninstallable (giblib FTBFS) > gtk-chtheme fixed recently > gvmd not sure? > gxneur BD-Uninstallable (xneur FTBFS) > haskell-gi-dbusmenugtk3 BD-Uninstallable (haskell-gi-gtk FTBFS) > haskell-gi-gtk FTBFS without a bug, filed > haskell-gi-gtk-hs BD-Uninstallable (haskell-gi-gtk FTBFS) > haskell-gi-vte BD-Uninstallable (haskell-gi-gtk FTBFS) > haskell-gtk-strut BD-Uninstallable (haskell-gi-gtk FTBFS) > hkl BD-Uninstallable (datatype99 FTBFS) > hugin not sure? > hxtools Dep-Wait on libhx > ibus-kkc BD-Uninstallable (libkkc FTBFS) > ippsample not sure? > jellyfish not sure? > jskeus FTBFS without a bug, filed > lcmaps-plugins-basic fixed recently > lcmaps-plugins-jobrep fixed recently > lcmaps-plugins-verify-proxy fixed recently > lcmaps-plugins-voms fixed recently > libcanberra not sure? > libosmo-netif not sure? > lightdm fixed recently > lightdm-gtk-greeter fixed recently > light-locker fixed recently > limesuite not sure? > llvm-toolchain-17 not sure? > lmms FTBFS, bug in wine > lyskom-server BD-Uninstallable (adns FTBFS) > massxpert2 BD-Uninstallable (libpappsomspp FTBFS) > nautilus-wipe not sure? > ncl not sure? > nfs-ganesha BD-Uninstallable (ceph dropped 32bit) > obs-advanced-scene-switcher not sure? > openjdk-20 BD-Uninstallable (wrong BD without a bug, filed) > perdition not sure? > ppp FTBFS > prads not sure? > prelude-lml BD-Uninstallable (libprelude FTBFS) > prelude-manager BD-Uninstallable (libprelude FTBFS) > purple-xmpp-carbons not sure? > purple-xmpp-http-upload not sure? > python-escript FTBFS (pmix dropped 32bit?) > qt5-ukui-platformtheme not sure? > quorum not sure? > renpy BD-Uninstallable (pygame-sdl2 FTBFS) > roger-router BD-Uninstallable (librm bug) > rtags FTBFS without a tag, tagged > sdpa Dep-Wait (mumps FTBFS because pmix dropped 32bit?) > seafile-client not sure? > slick-greeter fixed recently > sonic-visualiser FTBFS without a bug, filed > spectrwm not sure? > spice-gtk not sure? > swtpm not sure? > tfortune not sure? > thunderbird not sure? > trantor fixed recently > ui-gxmlcpp not sure? > ukui-greeter fixed recently > urfkill not sure? > vdeplug-pcap not sure? > vdeplug-slirp not sure? > wine-development FTBFS without a bug, filed > worker Dep-Wait (avfs FTBFS) > xbase64 not sure? > xca FTBFS without a tag, tagged -- WBR, wRAR signature.asc Description: PGP signature
Re: Status of the t64 transition
Hi Sebastian, Andreas Tille, on 2024-04-19: > I've spotted these Debian Med packages. […] > Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: […] > > jellyfish > > quorum […] > No idea how we can help here. Please let us know if we can do > something. About these two packages, I'm not 100% sure, but I believe some confusion may stem from jellyfish's support removal for 32-bit architectures[1,2]. This made the transition unnecessary so the package renaming has been undone in version 2.3.1-3, as far as I can witness in the changelog. This probably affected quorum transitively; and also this possibly affected crac, the other libjellyfish-2.0-2 reverse dependency, although I don't know why it hasn't stood out on the list. [1]: https://bugs.debian.org/1067166 [2]: https://github.com/gmarcais/Jellyfish/pull/202#issuecomment-2007544485 In hope this clarifies things, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Re: Status of the t64 transition
Hi Sebastian, thank you for your work on t64 transition. Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: I've spotted these Debian Med packages. > gentle > jellyfish > quorum > sbmltoolbox No idea how we can help here. Please let us know if we can do something. > anfo We like to fix gcc-12 issues (#1012893) in anfo but so far nobody managed to do so since it seems to be quite complex. If we are blocking progress with this package its probably a sign that it should be removed from Debian. > blasr We try to work on #1067374. > freebayes Upstream is working on bug #1067271. > vg This package is in a bad state in any case and we are aware of this. However, could you explain in how far is this affecting t64 transition since 32bit architectures are excluded? > If you maintain any of the packages above, please check their status and > help get them fixed. Any help in filing bugs, fixing packages, > requesting removals, etc. is appreciated so that we can look into > unblocking the whole stack and migrate it to testing. I fixed two packages of Debian Python Team and pinged about some packages in Debian Science Team. Kind regards Andreas. -- https://fam-tille.de
Re: Status of the t64 transition
Hello, On Thu, 2024-04-18 at 21:22 +0200, Sebastian Ramacher wrote: > Finally, packages that need rebuilds but currently have open FTBFS (RC + > ftbfs tag) bugs: > (...) > virtualjaguar I already have a tentative patch and will fix the package within the next days. I am also preparing to fix two other bugs, one being missing SDL-2 support and the other the FTBFS after rebuild from the same source unpack. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Status of the t64 transition
Sebastian Ramacher writes: > Hi, > > as the progress on the t64 transition is slowing down, I want to give an > overview of some of the remaining blockers that we need to tackle to get > it unstuck. I tried to identify some clusters of issues, but there might > be other classes of issues. Thanks for update. I haven't seen any response to my analysis of why 'shishi' shouldn't have t64-migrating, and lacking any response I eventually made an upload to revert the renaming. I've raised an Ubuntu bug too since they haven't synced the updated package. The Debian bug is now closed, so it wasn't included in your list, and maybe everything that can be hoped for is already achieved, but I wanted to mention as it ought to be on the t64 radar. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062896 https://bugs.launchpad.net/ubuntu/+source/shishi/+bug/2061743 https://tracker.debian.org/pkg/shishi /Simon signature.asc Description: PGP signature
Re: Status of the t64 transition
On 2024-04-19 06:02:03 +0200, Andreas Metzler wrote: > On 2024-04-18 Sebastian Ramacher wrote: > [...] > > Let's start with the first category. Those are packages that could be > > binNMUed, but there are issues that make those rebuilds not have the > > desired effect. This list include packages that > > * are BD-Uninstallabe, > > * FTBFS but with out ftbfs-tagged RC bug, > > * have hard-coded dependencies on pre-t64 libraries, > > * have $oldlib | $newlib dependencies (those are at least wrong on > >armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are > >decrufted), > > * have been rebuilt before all dependencies were built, > > * have broken symbols/shlibs files producing incorrect dependencies, > > * or might just be missing the binNMU (but those should be few). > > > hugin > [...] > > Good morning, > > thanks for the update. > > Looking at hugin, I think it is fine on all release-architectures, none > of the problems noted above apply here. Am I missing something? It required rebuilds for wxwidgets3.2 on mips64el: INFO Rebuilding src:hugin/2023.0.0+dfsg-1 (hugin) for libwxbase3.2-1 on mips64el INFO Rebuilding src:hugin/2023.0.0+dfsg-1 (hugin-tools) for libwxbase3.2-1 on mips64el They were scheduled last night and now hugin is fine. Thanks for double checking. > PS: fakeroot seems to be an important blocker not in the list. The lists in my mail only contain those packages that require changes to their dependencies due to the library package renames. So everything on these lists depends on foo, but should depend on foot64 [1]. fakeroot only depends on packages that are not involved in the t64 transition. Cheers [1] And some other variations including previous ABI transitions such as v5, etc: https://github.com/sebastinas/drt-tools/blob/main/src/nmu_t64.rs#L75 -- Sebastian Ramacher
Re: Status of the t64 transition
On 2024-04-18 Sebastian Ramacher wrote: [...] > Let's start with the first category. Those are packages that could be > binNMUed, but there are issues that make those rebuilds not have the > desired effect. This list include packages that > * are BD-Uninstallabe, > * FTBFS but with out ftbfs-tagged RC bug, > * have hard-coded dependencies on pre-t64 libraries, > * have $oldlib | $newlib dependencies (those are at least wrong on >armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are >decrufted), > * have been rebuilt before all dependencies were built, > * have broken symbols/shlibs files producing incorrect dependencies, > * or might just be missing the binNMU (but those should be few). > hugin [...] Good morning, thanks for the update. Looking at hugin, I think it is fine on all release-architectures, none of the problems noted above apply here. Am I missing something? TIA, cu Andreas PS: fakeroot seems to be an important blocker not in the list.
