Hi, On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote: > The time_t transition seems to be stalled due to issues on armel/armhf > architecture. My understanding is, as long as this transition isn't over, > uploaders of affected packages are discouraged to upload anything > unrelated to this transition (to avoid any delays to get it through).
> Do we have an updated rough idea for how long this transition will take? > Is it in the range of day, weeks or months? I have no clue... Well, I think I should send an update about this probably, because I don't think you should be discouraged from uploading right now. The source packages with the renames have landed in unstable, and will take a while (probably weeks) to get all of the build-dependency loops worked out and the binNMUs all done. There's no real need to hold off on other uploads at this point in the face of that, I don't expect it to significantly change the timeline. There may be some rare cases of pending transitions that would add to the set of packages that need to migrate to testing all at once (though this seems unlikely to me when there are already so many!), so those should still be coordinated with the Release Team. > Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek <vor...@debian.org>: > >Hi Simon, > > > >On Mon, Feb 26, 2024 at 11:40:56AM +0000, Simon McVittie wrote: > >> > glib2.0 # already in experimental > > > >> The upstream version in experimental is unsuitable for unstable, but it's > >> "the same shape" as the version in unstable in all the places that matter, > >> and we ack'd the earlier NMU to experimental already, so I'm confident > >> that similar changes will apply cleanly to the version in unstable. The > >> GNOME team can probably handle this one when the time comes, if that > >> would help (I know your Canonical colleague Jeremy Bícha was asking to > >> let the GNOME team do coordinated team-uploads rather than NMUs, I'm not > >> sure what the resolution of that was). > > > >Yes, this is on the list to flag that it is a package for which we do not > >have a guarantee of dumat coverage in experimental prior to uploading to > >unstable, and thus we might hit usrmerge problems for the first time in > >unstable. > > > >In this particular case the t64 NMU sat in experimental for 2 weeks > >(31Jan-13Feb) before being replaced by a maintainer upload. So I trust that > >Helmut would have screamed at me if glib2.0 had gone pear-shaped. > > > >But that is a finer level of investigation than we have the capacity for at > >this stage for each of these 50+ packages. > > > >> Also, if it's valid to apply this reasoning: > > > >> - libhigh0 depends on liblow0 > >> - liblow0 will transition to liblow0t64 > >> - libhigh0 does not really need to change its name because we know that the > >> version built against liblow0 is the old ABI, the version built against > >> liblow0t64 is the new ABI, and they cannot be co-installable > > > >> then we can cross all of the GLib-based packages off the list > >> immediately, and handle them by transitioning glib2.0 from libglib2.0-0 > >> to libglib2.0-0t64. That covers at least these: > > > >> > evolution # no sane ABI info, but maintainer handling via > >> > e-d-s > >> > gimp # already in experimental > >> > gtk+2.0 # false positive > >> > gtk+3.0 # false positive > >> > libvirt-glib # ftbfs > >> > mutter # already in experimental > >> > telepathy-farstream # known ftbfs > > > >> ... and similar logic could be applied to in the Qt ecosystem, with Qt > >> as the low-level package. Does that help to reduce the numbers? > > > >Special-casing these stacks because they don't "need" to be renamed is, on > >our side, more work and more prone to mistakes than if we just include them > >in the mass NMU. *Not* renaming is not meaningfully better as a user > >experience than renaming, so I don't think it's valuable from the > >perspective of the overall transition to carve out these exceptions. > > > >If maintainers are confident that the renames are unnecessary and want to > >remove the 'pending' tag from the bug reports to exclude them, or want to > >revert the renames after upload, that's their choice. > > > >The only caveat I would raise is that on the Ubuntu side, we're working to a > >very tight deadline now: Feature Freeze for Ubuntu 24.04 LTS is this > >Thursday, and while I think we're going to vary our Debian Import Freeze in > >order to get the time_t transition through, we aren't going to vary it by > >much. So maintainer name reverts in unstable that happen after this are not > >guaranteed to be picked up, and whatever package names we have on the Ubuntu > >side are going to be locked in for a 10-year LTS cycle. So I think any > >maintainer who's concerned about dependency compatibility with third-party > >debs should bear this in mind. > > > >-- > >Steve Langasek Give me a lever long enough and a Free OS > >Debian Developer to set it on, and I can move the world. > >Ubuntu Developer https://www.debian.org/ > >slanga...@ubuntu.com vor...@debian.org -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
