Hi Steve, > On Tue, Jan 23, 2024 at 02:02:15AM -0800, Simon Chopin wrote: > > Hi Release Team, > > > It seems we have a few big transitions either in progress (perl, > > python) or about to start in the coming weeks (php, armhf 64bit time_t). > > My original plans for glibc would add fuel to that fire, as I projected > > to upload it to -proposed in about 2 weeks. > > You use the past tense here; > https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649 shows > glibc 2.39 for this week. Did this projection change, and in which > direction?
I though I'd scheduled it for next week, that's my bad. If you prefer I stick to the announced plan I can probably do it for Friday, though. > FWIW I've just added 64-bit time_t onto the page, estimating that it will > start to happen next week. There are some externalities there not directly > under our control, specifically the timing of the upload of dpkg to unstable > and the analysis of the uploads to experimental (which are currently in > progress) with respect to usrmerge. I had asked about making sure the perl > and python transitions complete before 64-bit time_t lands in noble, because > I don't want these to overlap; and my intention is to turn off Debian > autosyncs if necessary until perl and python migrate. But I don't think > there's the same concern about glibc (it's just a new upstream version with > new symbols rather than a transition), so I'm not going to argue for > postponing either glibc 2.39 or 64-bit time_t to avoid entanglement. > > > A possible way to reduce the friction introduced by a new glibc verison > > would be to delay it until after Feature Freeze: fewer packages would > > pick up the new symbols and thus wouldn't get blocked waiting for the > > glibc rdeps autopkgtests to clear. > > > I can see a couple of downsides to that approach: > > > * Fewer packages would pick the new ABIs, which presumably bring in some > > sort of improvement in one form or another. > > "presumably" - usually, the new symbols from one release to the next are > small and don't affect too many packages. Can you give us a list of new > symbols in 2.39, to understand how significant this is? Because there's a > tension here between wanting packages to pick up the new interfaces, and > wanting unrelated uploads of packages to not get stuck behind glibc in > -proposed if the migration takes a long time. I've attached the list. It is entirely composed of brand new symbols rather than redefinition of existing APIs. The bulk of the symbols are implementations of the <stdbit.h> header, which feels like the kind of things that configure scripts check for and conditionally enable. That is purely speculation on my part though. > > * The newer glibc would be tested for less time, although presumably > > that's somewhat offset by it taking less time to reach the release > > pocket from -proposed. > > > WDYT? > > Thanks, > -- > 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/ > [email protected] [email protected]
2.39_symbols
Description: Binary data
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
