Re: Progress on t64 transition -> building the installer in sid

[Philip Hands]

Cyril Brulebois  writes:

> Philip Hands  (2024-04-15):
>> 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.

> 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.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Re: Progress on t64 transition -> building the installer in sid

[Cyril Brulebois]

Philip Hands  (2024-04-15):
> 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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Progress on t64 transition -> building the installer in sid

[Philip Hands]

Cyril Brulebois  writes:

> Philip Hands  (2024-04-14):
>> 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?
>
> 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.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Re: Progress on t64 transition -> building the installer in sid

[Cyril Brulebois]

Philip Hands  (2024-04-14):
> 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?

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Progress on t64 transition -> building the installer in sid

[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.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Re: lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)

[Guillem Jover]

Hi!

On Thu, 2024-03-21 at 23:13:31 +0100, Cyril Brulebois wrote:
> Cyril Brulebois  (2024-03-21):
> > 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.

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

lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)

[Cyril Brulebois]

Hi,

Cyril Brulebois  (2024-03-21):
> 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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Progress on t64 transition -> building the installer in sid

[Cyril Brulebois]

Hi,

Roland Clobus  (2024-03-21):
> On 21/03/2024 15:58, Cyril Brulebois wrote:

[…]

> The diagram shows nicely that the t64-transition is affecting the
> installer, with currently 1 major bottleneck, libpng16-16t64-udeb:
> https://d-i.debian.org/dose/graph-unstable-amd64.png

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…

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

> I've done some basic triaging in the openQA comment:
> https://openqa.debian.net/tests/244163#comments
> 
> The installer fails here:
> https://openqa.debian.net/tests/244163#step/grub/3
> 
> Some details are here (/var/log/syslog):
> 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).

> > 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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Progress on t64 transition -> building the installer in sid

[Roland Clobus]

Hello Cyril, list,

On 21/03/2024 15:58, Cyril Brulebois wrote:

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


The diagram shows nicely that the t64-transition is affecting the 
installer, with currently 1 major bottleneck, libpng16-16t64-udeb:

https://d-i.debian.org/dose/graph-unstable-amd64.png


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


My bad, I reversed the order when typing.

I've done some basic triaging in the openQA comment:
https://openqa.debian.net/tests/244163#comments

The installer fails here:
https://openqa.debian.net/tests/244163#step/grub/3

Some details are here (/var/log/syslog):
https://openqa.debian.net/tests/244163#step/grub/35


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/
Seeing the breakage on sid before the weekly-build installer breaks on 
trixie would be nice :-)


With kind regards,
Roland


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Progress on t64 transition -> building the installer in sid

[Cyril Brulebois]

Roland Clobus  (2024-03-19):
> 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

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

> 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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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


OpenPGP_signature.asc
Description: OpenPGP digital signature