Re: salsa CI

2024-01-24 Thread Cyril Brulebois
Samuel Thibault  (2024-01-23):
> The CI on salsa doesn't manage to build the debian-installer package
> because the signed linux 6.6.13 package is not available yet. Perhaps we
> should turn these build-deps:
> 
>   linux-image-6.6.13-amd64 [amd64],
>   linux-image-6.6.13-arm64 [arm64],
>   linux-image-6.6.13-686 [i386],
>   linux-image-6.6.13-686-pae [i386],
> 
> into
> 
>   linux-image-6.6.13-amd64 [amd64] | linux-image-6.6.13-amd64-unsigned 
> [amd64],
>   linux-image-6.6.13-arm64 [arm64] | linux-image-6.6.13-arm64-unsigned 
> [arm64],
>   linux-image-6.6.13-686 [i386] | linux-image-6.6.13-686-unsigned [i386],
>   linux-image-6.6.13-686-pae [i386] | linux-image-6.6.13-686-pae-unsigned 
> [i386],
> 
> ?

udebs are built from the linux-signed-* packages, so that doesn't help
at all.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Re: salsa CI

2024-01-24 Thread Philip Hands
Samuel Thibault  writes:

> For me it's fine for CI to fall back to the previous kernel for most
> jobs of the pipeline. I guess we'd still want a build job in the
> pipeline that sticks with the requested version, so that we notice in
> case that's not working, without breaking the entire CI pipeline.

That's a good idea -- I've done something slightly different, which is
to add an 'ABI-check' job which fails if we are in version-skew:

  
https://salsa.debian.org/philh/debian-installer/-/commit/3b862d27f3ca07e840c0f1a44e42fd26ab69b176

I think that's the finishing touch that makes me happy to merge this.

If you can tell me how the *-unsigned version of the build is actually
supposed to succeed (my attempt failed at the point where it tries to
get hold of the matching modules, where the new version was not yet
available), then I'll happily add that as an additional condition (and
will also check in the check job to see if that's what is going on).

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature


Re: salsa CI

2024-01-23 Thread Samuel Thibault
Philip Hands, le mar. 23 janv. 2024 17:52:57 +0100, a ecrit:
> Samuel Thibault  writes:
> 
> > Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit:
> >> Samuel Thibault  writes:
> >> 
> >> > Hello,
> >> >
> >> > The CI on salsa doesn't manage to build the debian-installer package
> >> > because the signed linux 6.6.13 package is not available yet.
> >> 
> >> Is the thing you want to:
> >>   a) be able to build d-i on salsa even when we're in version skew,
> >> or
> >>   b) do you want to be able to test with the latest version, whether it is 
> >> signed or not?
> >
> > b)
> >
> > Normally the bump in debian-installer comes about the same time as the
> > linux upload. But there is the period between the linux upload and the
> > linux-signed upload during which we don't really know whether we want to
> > bump or not. Adding the alternative between non-signed and signed as I
> > proposed would allow to be fine with either, while making sure it's the
> > signed version which is used on buildds.
> 
> Ah, fair enough.
> 
> I guess in that case I'll need to adjust what I'm doing to detect the
> available versions of kernel that I'm looking for in that patch.
> 
> If you're only worried about builds on salsa-CI, same approach as used
> in my MR ought to work,

Indeed.

It however doesn't fix the build on my laptop without some change :)

> and then one could perhaps control which kernel
> is selected via variables, or perhaps defaulting to the unsigned kernel
> (if available) would work for my use-case too, in which case I could
> just add that as a feature.
> 
> The MR's here BTW: https://deb.li/3hHY2
> 
> BTW would it actually cause you a problem for the build to work, despite
> the kernel being unavailable (e.g. by falling back to the previous
> version)?

For me it's fine for CI to fall back to the previous kernel for most
jobs of the pipeline. I guess we'd still want a build job in the
pipeline that sticks with the requested version, so that we notice in
case that's not working, without breaking the entire CI pipeline.

Samuel



Re: salsa CI

2024-01-23 Thread Philip Hands
Samuel Thibault  writes:

> Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit:
>> Samuel Thibault  writes:
>> 
>> > Hello,
>> >
>> > The CI on salsa doesn't manage to build the debian-installer package
>> > because the signed linux 6.6.13 package is not available yet.
>> 
>> Is the thing you want to:
>>   a) be able to build d-i on salsa even when we're in version skew,
>> or
>>   b) do you want to be able to test with the latest version, whether it is 
>> signed or not?
>
> b)
>
> Normally the bump in debian-installer comes about the same time as the
> linux upload. But there is the period between the linux upload and the
> linux-signed upload during which we don't really know whether we want to
> bump or not. Adding the alternative between non-signed and signed as I
> proposed would allow to be fine with either, while making sure it's the
> signed version which is used on buildds.

Ah, fair enough.

I guess in that case I'll need to adjust what I'm doing to detect the
available versions of kernel that I'm looking for in that patch.

If you're only worried about builds on salsa-CI, same approach as used
in my MR ought to work, and then one could perhaps control which kernel
is selected via variables, or perhaps defaulting to the unsigned kernel
(if available) would work for my use-case too, in which case I could
just add that as a feature.

The MR's here BTW: https://deb.li/3hHY2

BTW would it actually cause you a problem for the build to work, despite
the kernel being unavailable (e.g. by falling back to the previous
version)?

If so, I guess a variable is required to stop that behaviour.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature


Re: salsa CI

2024-01-23 Thread Samuel Thibault
Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit:
> Samuel Thibault  writes:
> 
> > Hello,
> >
> > The CI on salsa doesn't manage to build the debian-installer package
> > because the signed linux 6.6.13 package is not available yet.
> 
> Is the thing you want to:
>   a) be able to build d-i on salsa even when we're in version skew,
> or
>   b) do you want to be able to test with the latest version, whether it is 
> signed or not?

b)

Normally the bump in debian-installer comes about the same time as the
linux upload. But there is the period between the linux upload and the
linux-signed upload during which we don't really know whether we want to
bump or not. Adding the alternative between non-signed and signed as I
proposed would allow to be fine with either, while making sure it's the
signed version which is used on buildds.

Samuel



Re: salsa CI

2024-01-23 Thread Philip Hands
Samuel Thibault  writes:

> Hello,
>
> The CI on salsa doesn't manage to build the debian-installer package
> because the signed linux 6.6.13 package is not available yet.

Is the thing you want to:
  a) be able to build d-i on salsa even when we're in version skew,
or
  b) do you want to be able to test with the latest version, whether it is 
signed or not?

If what you're after a), I have a patch that does that, as you can see
here:

  https://salsa.debian.org/philh/debian-installer/-/jobs/5193962

which works by finding out the version that's actually available, and
using whatever it is (in this case, it used 6.6.11).

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature