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.