Progress on t64 transition -> building the installer in sid

[Roland Clobus]

Hello list,

Since two days the live images based on sid can be generated again
(hurray!), now that debootstrap is able to generate a bootstrap again.
The smallest image is generated properly now, because it does not have
an installer.

For the other images, the installer is currently failing to build from
source, as some dependencies (in the udebs) are still missing (due to
the t64-transition).

The latest message (from my local build_cdrom_gtk.log) is:

The following packages have unmet dependencies:
libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not
installable
libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is
not installable
libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but
it is not installable
libinput10-udeb : Depends: libmtdev1t64 but it is not installable

On openQA I've additionally seen that for Debian Edu, the installer
fails with the message that libaio.1.so is missing, so some udeb is
probably also requiring an update.

With kind regards,
Roland Clobus

[Cyril Brulebois]

Post by Roland Clobus
For the other images, the installer is currently failing to build from
source, as some dependencies (in the udebs) are still missing (due to
the t64-transition).
libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not
installable
libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not
installable
libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it
is not installable
libinput10-udeb : Depends: libmtdev1t64 but it is not installable

https://lists.debian.org/debian-boot/2024/03/msg00102.html

Post by Roland Clobus
On openQA I've additionally seen that for Debian Edu, the installer fails
with the message that libaio.1.so is missing, so some udeb is probably also
requiring an update.

Do you have more details? That thing doesn't exist, but libaio.so.1
does (different suffix order).

In any case, there are no reasons to complicate the t64 transition with
transitioning udebs, so I wouldn't be surprised if “images” (whatever
they are) built against old udebs would break if newer udebs are pulled
from the network.


Cheers,

[Cyril Brulebois]

Hi,
[
]

The diagram shows nicely that the t64-transition is affecting the
Loading Image...

Glad you like it, those have been quite useful a very long while back;
it's been a while since the last time we had such a huge archive-wide
transition


Post by Cyril Brulebois
Do you have more details? That thing doesn't exist, but libaio.so.1
does (different suffix order).

My bad, I reversed the order when typing.

No worries, thanks for confirming.

https://openqa.debian.net/tests/244163#comments
https://openqa.debian.net/tests/244163#step/grub/3
https://openqa.debian.net/tests/244163#step/grub/35

Thanks, that's pvs from lvm2-udeb; for some reason libaio1-udeb got
t64-transitioned, and without an lvm2 rebuild, its tools will want the
non-t64 version.

I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
is the only udeb with t64 (at least according to the output of
`apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
would be sufficient (and might happen at some point anyway).

For the sake of consistency, I think I'm tempted to suggest a revert of
the udeb part (it wasn't renamed so there's a contents vs. package name
mismatch anyway).

Post by Cyril Brulebois
In any case, there are no reasons to complicate the t64 transition with
transitioning udebs, so I wouldn't be surprised if “images” (whatever
they are) built against old udebs would break if newer udebs are pulled
from the network.

The images I've spoken of are the daily-built Debian live ISO-images based
on sid. They are built by Jenkins https://jenkins.debian.net/view/live/

OK, but what I meant to say is that the failure mode I was alluding to
isn't specific to d-i daily builds, or debian-cd builds, or live builds;
that's something that can happen, and might do until things stabilize.


Cheers,

[Cyril Brulebois]

Hi,

Post by Cyril Brulebois
I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
is the only udeb with t64 (at least according to the output of
`apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
would be sufficient (and might happen at some point anyway).
For the sake of consistency, I think I'm tempted to suggest a revert of
the udeb part (it wasn't renamed so there's a contents vs. package name
mismatch anyway).

Checking libaio's changelog (last mail got sent a little too fast,
sorry) is enlightening: this library required special attention and
wasn't just about getting rebuilt with a different package name.

https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/

Guillem is absolutely right regarding avoiding the roundtrip to NEW and
d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
would have been welcome.

It'd be nice if the Debian LVM Team (hello waldi) could pick it up from
here and see whether requesting a binNMU is what makes most sense here,
or if there other plans on the t64 front. A local, cowbuilder-powered
rebuild of unstable's lvm2 results in udebs referencing libaio.so.1t64
as expected (i.e. libaio1t64's shlibs).


Cheers,

[Guillem Jover]

Hi!

Post by Cyril Brulebois

Post by Cyril Brulebois
I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
is the only udeb with t64 (at least according to the output of
`apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
would be sufficient (and might happen at some point anyway).
For the sake of consistency, I think I'm tempted to suggest a revert of
the udeb part (it wasn't renamed so there's a contents vs. package name
mismatch anyway).

Checking libaio's changelog (last mail got sent a little too fast,
sorry) is enlightening: this library required special attention and
wasn't just about getting rebuilt with a different package name.
https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/
Guillem is absolutely right regarding avoiding the roundtrip to NEW and
would have been welcome.

Ah, sorry, the heads-up part didn't cross my mind, as I guess I
assumed transitory breakage was expected as part of that transition,
and that it would auto-heal after the release-team would trigger the
necessary binNMUs. Will try to have that in mind in the future. (I'll
do so as well once/if I revert the libaio SONAME bump, even though there
I'd be planning to add backwards compatibility symlinks if the ABI does
not change from what upstream accepts.)

Thanks,
Guillem

[Philip Hands]

Hi,

I realised that there might be a way to kludge around the current D-I
build failures, so I gave it a try and it seems to work:

https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45

That creates dummy udebs with the missing names, where each depends upon
the matching udeb that actually exists. Dropping them into localudebs.

That's enough to get D-I to build in salsa pipelines, such that one gets
a mini-ISO to test.

It may be enough to get D-I and debian-cd back to the point where we can
produce daily images etc. but I'm not completely sure about that bit
(perhaps the use of localudebs is enough to make debian-cd grumpy?)

Anyway, it's currently broken anyway, so perhaps it's worth giving it a
go, and then reverting the commit once the proper fixes become
available.

What do you think?

Cheers, Phil.

[Cyril Brulebois]

Post by Philip Hands
I realised that there might be a way to kludge around the current D-I
https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45
That creates dummy udebs with the missing names, where each depends upon
the matching udeb that actually exists. Dropping them into localudebs.
That's enough to get D-I to build in salsa pipelines, such that one gets
a mini-ISO to test.
It may be enough to get D-I and debian-cd back to the point where we can
produce daily images etc. but I'm not completely sure about that bit
(perhaps the use of localudebs is enough to make debian-cd grumpy?)
Anyway, it's currently broken anyway, so perhaps it's worth giving it a
go, and then reverting the commit once the proper fixes become
available.
What do you think?

I'd rather see actual progress in getting packages fixed. So far I haven't
been chasing because I thought people would be busy rebuilding the world, in
the right order, and patching things along, but I had hoped to get *some*
kind of feedback after filing those bug reports and putting people driving
changes in the loop.


Cheers,

[Philip Hands]

Post by Cyril Brulebois

Post by Philip Hands
I realised that there might be a way to kludge around the current D-I
https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45
That creates dummy udebs with the missing names, where each depends upon
the matching udeb that actually exists. Dropping them into localudebs.
That's enough to get D-I to build in salsa pipelines, such that one gets
a mini-ISO to test.
It may be enough to get D-I and debian-cd back to the point where we can
produce daily images etc. but I'm not completely sure about that bit
(perhaps the use of localudebs is enough to make debian-cd grumpy?)
Anyway, it's currently broken anyway, so perhaps it's worth giving it a
go, and then reverting the commit once the proper fixes become
available.
What do you think?

I'd rather see actual progress in getting packages fixed. So far I haven't
been chasing because I thought people would be busy rebuilding the world, in
the right order, and patching things along, but I had hoped to get *some*
kind of feedback after filing those bug reports and putting people driving
changes in the loop.

I too had rather hoped that it would already have been fixed by now.

On the other hand, it's taken over a month so far. Rather than living in
hope for another month, I thought it might be worth removing this as a
blocker (I've had to tell a couple of people that they'll need to wait
before they can do their salsa-CI tests :-/ )

I can just tell branch2repo to use the 'philh' D-I repo in the mean
time, and that'll fix the salsa-CI side of things, but that doesn't help
debian-cd or people's ability to build D-I locally.

Cheers, Phil.

[Cyril Brulebois]

Post by Philip Hands
On the other hand, it's taken over a month so far. Rather than living in
hope for another month, I thought it might be worth removing this as a
blocker (I've had to tell a couple of people that they'll need to wait
before they can do their salsa-CI tests :-/ )

I'm not suggesting living in hope, I'm suggesting to get the ball rolling.

The commit lists #1066070, which was a duplicate (because -ECOFFEE) of
#1066069, which got fixed rather quickly. So what we would need are
rebuilds of the reverse dependencies (which I haven't checked right now
would be sufficient to get them fixed), which one could request on the
release team side.

Regarding #1066071, that needs a fix in the package first. Looking at
tracker, it's not migrating any time soon as far as I can see (due to
regressions on 32-bit arms), and I'm not sure how fixing the udeb would
interfere there. So one could start with an upload.


Cheers,

[Philip Hands]

Post by Cyril Brulebois

Post by Philip Hands
On the other hand, it's taken over a month so far. Rather than living in
hope for another month, I thought it might be worth removing this as a
blocker (I've had to tell a couple of people that they'll need to wait
before they can do their salsa-CI tests :-/ )

I'm not suggesting living in hope, I'm suggesting to get the ball rolling.
The commit lists #1066070, which was a duplicate (because -ECOFFEE) of
#1066069, which got fixed rather quickly. So what we would need are
rebuilds of the reverse dependencies (which I haven't checked right now
would be sufficient to get them fixed), which one could request on the
release team side.

Oh, I seem to have managed to overlook the bit with you closing it.
Sorry about that. Anyway, that's encouraging.

If I can work out what needs prodding, and where to prod, I'll give it a
go.

Post by Cyril Brulebois
Regarding #1066071, that needs a fix in the package first. Looking at
tracker, it's not migrating any time soon as far as I can see (due to
regressions on 32-bit arms), and I'm not sure how fixing the udeb would
interfere there. So one could start with an upload.

I had looked at fixing that, but didn't immediately know in which
direction the mismatch should be resolved which convinced me that I
probably don't know enough about the background to be doing NMUs.

Which is what lead me to try working around it instead.

Cheers, Phil.