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
Attachment:
signature.asc
Description: PGP signature