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