Re: time_t progress report

[Simon McVittie]

On Sun, 24 Mar 2024 at 18:20:30 +0100, Samuel Thibault wrote:
> - it's indeed better to avoid loading porters with this, notably because
>   it'll be most often the same for a set of architectures. The buildd
>   infrastructure could have an additional build-profile parameter that
>   can be set on a binNMU, so that such temporary-profile binNMUs can be
>   requested easily.

For this particular transition, since that feature doesn't currently exist
in our production infrastructure, we need to get by without it. But, for
the longer term, if someone is able to work on developing what you suggest:

Instead of applying a temporary build profile to all architectures,
ideally we'd be able to say something like "build with nocheck on armel,
armhf, hppa, m68k and powerpc, and normally everywhere else". I think
as well as being able to perform binNMUs with a specified set of build
profiles on particular architectures, this transition would have needed
a way to get the initial build (no +b suffix) to be done with specified
build profiles, because we're often seeing this pattern:

- a developer uploads foo_1.2-3.1 to rename libfoo0 to libfoo0t64
- on the 64-bit architectures plus i386, it builds fine
- on the 32-bit non-x86 architectures, it's blocked waiting for libbar1t64
  to become available
- armel is unblocked when a porter does a binary build of foo on armel
  with , which means it no longer needs libbar1t64
- and so on for the other architectures

and I don't think creating a binNMU is allowed if the sourceful upload
hasn't been built successfully yet.

Also, if this feature existed as you describe it, then we'd be moving the
bottleneck from porters to the release team / wanna-build operators, who
can schedule binNMUs (unilaterally or on request from other contributors).

If this feature existed *and* DDs could schedule binNMUs on a self-service
basis (the same way we can give back failed builds now), then yes,
that would spread out the load to all DDs. Or, if the maintainer or NMU
uploader could do a source upload with something like this in either
the .dsc, the .changes or some accompanying file:

Use-Build-Profiles: nocheck [armel armhf hppa m68k powerpc], ...

then that would be a way to get the same result as some of the temporary
changes I've been making, but without having to write custom code in
debian/rules.

smcv

Re: time_t progress report

[Johannes Schauer Marin Rodrigues]

Quoting Samuel Thibault (2024-03-24 18:20:30)
> - making sure that the Debian release eventually only contains non-profile
> builds should be relatively easy thanks to the buildinfo files (they
> currently only contain them in the DEB_BUILD_PROFILES environment variable,
> they could be added as proper field). We already track against packages built
> on non-buildd, we could track packages built with profiles.

the information is also stored in the .changes file in the Built-For-Profiles
field. The main reason why the information is not stored in the .deb itself is,
because that would make it impossible for packages to be bit-by-bit identical
compared those built without certain build profiles active.

Thanks!

cheers, josc

signature.asc
Description: signature

Re: time_t progress report

[Samuel Thibault]

Simon McVittie, le dim. 24 mars 2024 16:45:02 +, a ecrit:
> On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:
> > Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> > > For the specific example of pipewire, I've suggested temporarily
> > > dropping that feature from pipewire on the affected architectures
> > >  which would get the rebuilds further
> > > along (particularly if it unblocks weston, which lots of packages use
> > > in their tests). There are various places where targeted changes like
> > > this can unblock a whole tree of dependencies.
> > 
> > Could we use build profiles for this? That'd avoid full uploads, and
> > document for architecture bootstrapping.
> 
> Only if a porter is willing to do a binary build with the relevant
> build profile on each of the affected architectures, and upload it as
> binary-only, after making a note to get it binNMU'd later. The official
> buildds for release architectures always build with no build profiles,
> and do not have any way (that I'm aware of) to vary this.
> 
> The porter-binary-upload approach is necessary for the actual bootstrap
> phase of the dependency stack, but doesn't seem to be scaling well in
> higher layers, because the number of porters is limited. I'd prefer
> to give porters the opportunity to work on more difficult issues where
> their architecture-specific knowledge is actually relevant, so I'm doing
> my best to unblock some of the dependency chains without having to block
> on porter uploads.

I understand these, but

- making sure that the Debian release eventually only contains
  non-profile builds should be relatively easy thanks to the buildinfo
  files (they currently only contain them in the DEB_BUILD_PROFILES
  environment variable, they could be added as proper field). We already
  track against packages built on non-buildd, we could track packages
  built with profiles.

- it's indeed better to avoid loading porters with this, notably because
  it'll be most often the same for a set of architectures. The buildd
  infrastructure could have an additional build-profile parameter that
  can be set on a binNMU, so that such temporary-profile binNMUs can be
  requested easily.

I'm not saying that this is trivial now, of course, but it seems to
me that it's not so far, and thus something we'd want to aim for
longterm-wise?

Samuel

Re: Re: time_t progress report

[Simon McVittie]

On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:
> Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> > For the specific example of pipewire, I've suggested temporarily
> > dropping that feature from pipewire on the affected architectures
> >  which would get the rebuilds further
> > along (particularly if it unblocks weston, which lots of packages use
> > in their tests). There are various places where targeted changes like
> > this can unblock a whole tree of dependencies.
> 
> Could we use build profiles for this? That'd avoid full uploads, and
> document for architecture bootstrapping.

Only if a porter is willing to do a binary build with the relevant
build profile on each of the affected architectures, and upload it as
binary-only, after making a note to get it binNMU'd later. The official
buildds for release architectures always build with no build profiles,
and do not have any way (that I'm aware of) to vary this.

The porter-binary-upload approach is necessary for the actual bootstrap
phase of the dependency stack, but doesn't seem to be scaling well in
higher layers, because the number of porters is limited. I'd prefer
to give porters the opportunity to work on more difficult issues where
their architecture-specific knowledge is actually relevant, so I'm doing
my best to unblock some of the dependency chains without having to block
on porter uploads.

However, I'm not an armel/armhf porter (and certainly not an hppa, m68k,
or powerpc porter) and I don't have the relevant hardware up and running,
so I'm not going to sign a specific binary build that I have no ability to
test. Similarly, there doesn't seem to be consensus on whether porterboxes
should be considered to be a trusted environment, so I'm not comfortable
with signing test-builds that have been done on a porterbox. I'm sorry
if my limitations are inconveniencing people: if other developers have
different policies and resources then they are welcome to take over.

When suggesting a cut-down version, what I'm often doing is suggesting
a change of the form "when building on 32-bit non-i386, always build
as though profile pkg.foo.bar was active" - although if there isn't
already a convenient build-profile to do this with, I admit I haven't
always been adding one, because that adds complexity, and I don't want
maintainers' response to my suggestions to be "that looks too hard, I'm
not going to touch this".

Build-profiles are at their most useful where they are "safe" or
"reproducible" (no functional effect on the built binaries, except
that some binary packages are skipped entirely), and in many cases
the features we're having to disable at this stage of the transition
*do* have a functional impact. I'd personally prefer for changes with
a functional impact to be documented in the changelog so that we know
they have happened, and built on the same trusted buildds as any other
official package.

smcv

Re: Re: time_t progress report

[Samuel Thibault]

Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:
> > 2. FTBFSing packages (those that block further work, anyway)
> ...
> > An example of a currently existing obstacle of this kind is snapd-glib
> > (mainly because it blocks pipewire).
> 
> For the specific example of pipewire, I've suggested temporarily
> dropping that feature from pipewire on the affected architectures
>  which would get the rebuilds further
> along (particularly if it unblocks weston, which lots of packages use
> in their tests). There are various places where targeted changes like
> this can unblock a whole tree of dependencies.

Could we use build profiles for this? That'd avoid full uploads, and
document for architecture bootstrapping.

Samuel

Re: Re: time_t progress report

[Simon McVittie]

On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:
> 2. FTBFSing packages (those that block further work, anyway)
...
> An example of a currently existing obstacle of this kind is snapd-glib
> (mainly because it blocks pipewire).

For the specific example of pipewire, I've suggested temporarily
dropping that feature from pipewire on the affected architectures
 which would get the rebuilds further
along (particularly if it unblocks weston, which lots of packages use
in their tests). There are various places where targeted changes like
this can unblock a whole tree of dependencies.

smcv

Re: Re: time_t progress report

[Andrey Rakhmatullin]

On Sat, Mar 23, 2024 at 04:50:48PM -0500, Steven Robbins wrote:
> Wondering about the current state of this transition. 
It's still in the stage of re-bootstrapping armel and armhf.
https://buildd.debian.org/stats/armel.png
https://buildd.debian.org/stats/armhf.png
https://buildd.debian.org/stats/graph-week-big.png

> 5. Do unchanged source rebuilds (binNMUs on all architectures) of 5000-6000 
> packages which depend on those. By the magic of transitions this just works.
> 
> 
> I'm guessing that we're somewhere in the midst of Milestone 5?  
Yes.

> In looking at packages I maintain, I find things like "blocked by ${pkg}".  
> But 
> when I go to the blocker, there's often no upload for 2-3 weeks and no other 
> visible sign of progress.
Just don't look at migration data now, it's intentionally blocked by dpkg
anyway. If a package B is successfully updated it won't migarte for now
and if a package A depends/build-depends on B it will say "B is blocked by
A" but no further action is needed for either of them.


> What's holding things up?  Are we waiting for folks to identify the 5-6k
> packages that need binNMU?   
We are waiting for:

1. Dependency cycles to be broken manually (both cases when A B-D: B, B
B-D: A and cases when A B-D: A), like when a new arch is bootstrapped.
This requires developer time, local build time and in the former cases
sometimes additional effort for finding where to break the cycle.
An example of a currently existing obstacle of this kind is openjdk-17.

2. FTBFSing packages (those that block further work, anyway) to be fixed
by their maintainers or NMUed. There are many FTBFSing packages, because
of
2.1. not being ready for 64-bit time_t (like assigning those to long);
2.2. not supporting -Werror=implicit-function-declaration;
2.3. symbol file changes due to 64-bit time_t;
2.3. usual bitrot.
An example of a currently existing obstacle of this kind is snapd-glib
(mainly because it blocks pipewire).

3. Not all binNMUs being scheduled yet.

4. buildd time to rebuild packages that can be rebuilt, when there are
any (currently not applicable).

> Can we help?  I tried filing a binNmu bug for a package, but then found out 
> the 
> package was nmu'd later -- without closing my bug.  So clearly someone is 
> looking at things.  Where are we in the process?  
From my experience in the past week, you (or any DD, and for parts not
involving uploads anyone) can do these things to speed up the process:

1. Help with FTBFS bugs. The options here are the usual ones: triage; fix
and attach the patch; fix and upload a NMU; find a patch in the upstream
source/upstream tracker/trackers of other distros; suggest general ideas
for a fix or at least for the reason of the problem.
This is more helpful for non-leaf packages.
2. File FTBFS bugs if you see something FTBFS but there is no bug reported
yet.
3. Identify packages that were not binNMUed against *t64 libraries
(packages.d.o helps with this, showing deps for all architectures), at all
or on some arches (usually armel and armhf) and file binNMU bugs against
release.debian.org for those.
4. Find packages that need to be rebuilt but can't, because they FTBFS or
B-D on packages that also can't be rebuilt, while blocking many packages,
and build them locally (most likely by enabling some build profile already
specified in the package) for armel and armhf and upload those binaries. 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: time_t progress report

[Steven Robbins]

Wondering about the current state of this transition.  Is there a tracker of 
any kind for this?  Or would someone be willing to post an email here 
periodically?  Weekly maybe?

I looked at the release goals wiki and at the "brain dump" page but failed to 
find anything dated more precisely than "***The t64 transition is ongoing 
(March 2024) in Debian***".  

There are five milestones listed on the release goal page.  I would hazard that 
the first three are done but I'm not sure whether the last two are complete?

The Milestones are:

1. Make a complete list of libraries with changed public ABI changes that must 
transition together.

2. Change gcc-* to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 by default.

3. Change dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 on 
all 32-bit arches except i386 and hurd-i386 (filter this out for 100-odd 
packages which are sensitive to LFS but not time_t).

4. NMU all libraries with binaries renamed from libfoo to libfoot64, removing 
old suffixes (c102, c2, ldbl, g…) if present, and emit a Provides/Replaces/
Breaks libfoo on 64-bit arches + i386 and hurd-i386.

5. Do unchanged source rebuilds (binNMUs on all architectures) of 5000-6000 
packages which depend on those. By the magic of transitions this just works.


I'm guessing that we're somewhere in the midst of Milestone 5?  

In looking at packages I maintain, I find things like "blocked by ${pkg}".  But 
when I go to the blocker, there's often no upload for 2-3 weeks and no other 
visible sign of progress.  What's holding things up?  Are we waiting for folks 
to identify the 5-6k packages that need binNMU?   

Can we help?  I tried filing a binNmu bug for a package, but then found out the 
package was nmu'd later -- without closing my bug.  So clearly someone is 
looking at things.  Where are we in the process?  

Appreciate all the good work going into this.  Just wondering whether there's 
something constructive I could pitch in on?  If there is nothing for me but to 
wait, that is useful information, too.

Thanks,
-Steve


signature.asc
Description: This is a digitally signed message part.

Re: time_t progress report

[Andrea Bolognani]

On Thu, Mar 14, 2024 at 08:42:14PM -0700, Steve Langasek wrote:
> 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.

That's great to hear. A more visible progress update would be greatly
appreciated.

> 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.

It would be nice if the update included information on how to figure
out whether one's packages are likely to fall into this "rare cases"
bucket. Something like that might have provided in the past, but
giving it greater visibility would help a lot IMO.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Re: time_t progress report

[Steve Langasek]

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 :
> >Hi Simon,
> >
> >On Mon, Feb 26, 2024 at 11:40:56AM +, 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   

Re: time_t progress report

[Micha Lenk]

Hi all,

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...

Regards,
Micha

Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek :
>Hi Simon,
>
>On Mon, Feb 26, 2024 at 11:40:56AM +, 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

Re: time_t progress report

[Steve Langasek]

Hi Simon,

On Mon, Feb 26, 2024 at 11:40:56AM +, 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


signature.asc
Description: PGP signature

Re: time_t progress report

[Simon McVittie]

On Sun, 25 Feb 2024 at 23:56:58 -0800, Steve Langasek wrote:
> I have attached the full list of current packages missing correct builds in
> experimental here for review.  I am also attaching dd-list output for the
> same.  Please check whether you have packages on this list that need
> attention.

> 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).

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?

smcv

Re: time_t progress report

[Steve Langasek]

On Fri, Feb 23, 2024 at 04:36:43PM +0100, Guillem Jover wrote:
> Hi!

> On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote:
> > I have coordinated with the gcc maintainer so that we can have the default
> > flags in gcc-13 changed this week.

> > We are therefore targeting Friday for the mass NMUs to unstable though there
> > is a possibility this won't start until as late as Monday depending on
> > capacity.

> Yesterday while trying to get a time for today's upload, I discussed
> with Matthias, and it looks like today is not great for timing. There
> are some things that might need to be hammered out in gcc, and Matthias
> was not going to be available today until next week or so. I also just
> realized the transition exceptions coverage does not match between
> what some porters expect (f.ex. hurd-i386 which I'll discuss with them
> later today), what dpkg and debhelper have implemented and what gcc
> does, I'll discuss the latter with Matthias separately.

> So as mentioned by Steve, this might need to be postponed a tiny bit
> more.

Yes, it looks like we're not quite ready to go.  There are also some bad
NMUs in experimental that need to be cleaned up, and also a few extra
annotations we're going to have to add to some packages after belatedly
realizing that debhelper magic isn't already DTRT as far as Provides: for
all packages.  So we'll use the time well until gcc is ready to go.

In the meantime, another happy update on the statistics, showing that we've
whittled away a few more libraries:

- 1093+50=1143 source packages to be transitioned
- 5261+180=5441 packages to be binNMUed

-- 
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

Re: time_t progress report

[Guillem Jover]

Hi!

On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote:
> I have coordinated with the gcc maintainer so that we can have the default
> flags in gcc-13 changed this week.
> 
> We are therefore targeting Friday for the mass NMUs to unstable though there
> is a possibility this won't start until as late as Monday depending on
> capacity.

Yesterday while trying to get a time for today's upload, I discussed
with Matthias, and it looks like today is not great for timing. There
are some things that might need to be hammered out in gcc, and Matthias
was not going to be available today until next week or so. I also just
realized the transition exceptions coverage does not match between
what some porters expect (f.ex. hurd-i386 which I'll discuss with them
later today), what dpkg and debhelper have implemented and what gcc
does, I'll discuss the latter with Matthias separately.

So as mentioned by Steve, this might need to be postponed a tiny bit
more.

Thanks,
Guillem