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

?

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit:

Samuel Thibault <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Samuel Thibault <[email protected]> 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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmWv2tAACgkQ0EujoAEl 1cDjqxAAoQKMC7wzhqt//chXIp1pWGcoP67BNrB2LjWDEt6hhmx9YpMf2xc22CAJ mWiNYJpJc3yhUoIGBfvgSrh4TVGpktDckx+7dThAzwmpIuL6HABiomTOASXqeTcS 9hcwZYz6dT2OoKkmlCdibQBcWK4FZSFgFSutQC0B4Yq74dBs45wdq6g6+hJ55llS DqJ3hI4wg98RxCK9WtJD8NPDMIEJMC4cpvkrGUkAeer+1UbD90Z1lHsO17uNqaC0 i9fIq5op+pvX9BsqPgL75VCM6NEAKvP7Ihd6BhTGpzXZppl1bbHtPXyzQaupSb9D eS6Afd4Tm+HRsVAzHZUgCd+2ukpbHyw2CooT7xbtXpNm+iXLbRRt1ukxh7NwY5NC Uezg0NIi95W8i4iWd+4HCnW2R5n/+178qbrkWdfOi8GHumQzEKb+k54NUp5MllNg XMXemQSZMbzqUC2uwWPTzoA9BlyOnD/0LoqATzlyvIf1RxxxMg6FK2JGZFRjxXqu 01/QkzYkJSZIhaZhuVUTSzaNcKMYM54/Ba16/DY/6kgmF6FT9GksFaUdJZVeW96T n5NXB/TnCzVn418Kq7z3JgHfAj/uLodLOGU3abofx5CxZK2QDEFqOtmSmgudrzvP jozNATkLnufoxlGKcGJibplZJBBky1bEgEujpqk/tD6KJymArrgQ7
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway

Philip Hands, le mar. 23 janv. 2024 17:52:57 +0100, a ecrit:

Samuel Thibault <[email protected]> writes:

Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit:

Samuel Thibault <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Samuel Thibault <[email protected]> writes:

Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit:

Samuel Thibault <[email protected]> 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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmWv7ukACgkQ0EujoAEl 1cDsVw//denZ8qE4f+z3ruDGWjb+1Qn6vRAo+KfDa6IHWtZr9djTFjvYIRW/55aO 40t6IPCbmLWnIlEPwfYLp4E+Fu1EQ1K0Vatqzz2jkdW7rZeRg87oy3kQ4KWa5Z+X bJJu3tcdg9llFYx3uWgKQ5NGa4ys05aNaPICSCC6QLn5KxA4MnprAlL7UWe9CpEl QbFj0zeTOzuOOiN2uVd9iuX+k5jvZ599CBm3hcb1iwUofLbz0zruL1TBQIadhoTU 1vaVkidrMlNhVAgeLPcdx6pZ+pUzMOobsQegIHmRhqEa7+mvhuJP/yZuL4fevks5 e8eb7r5GCyxKiWUGm03cP4GYmNSjTBh71qjletlGJ1dnKS1ue/qZUWIzXVoEJpDF UyBPB4e+Iv/hcfZmWBgixLf2kHNkpPLPg6Am+CT1P1RQa1rAdRCYjMPGlvT3QXx+ UaovRqfL4B10Cl/DR2HaKXDbxENC7iVkQB/pYkVn5SCbxzGX1qU3MSP4OCuaVFQx upYty6FRaeJFKV9Rl5/Pm90tBL+jA6PmI2jtZaf2OxueX+FHHWrQQkPlCs1oAgSr z+uafyLCxn5FPKRE42xGBAJ1bHDY2VABLG7FgIgHLcQl+NKgN/nj3/Pn9L0Q0s9o 5wlo/V3syMGOkTKahLSrAqyw2fZlq+/4/DwQgEtUToGQVMgswpc�tM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway

Samuel Thibault <[email protected]> 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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmWw7XkACgkQ0EujoAEl 1cC9Jg/+KiR8fIxmCQx6NClssBYFMl4pH4GsHUO71fLEaGh/e7tCpxNVqHH3NLyk yerXPRfmysXnqm9rvdOp2zyNLkHqkv9MO1jtn2Qmxra8e0jbUjhvc/kVlg1sdeC3 sYd4Hf5rMZwBpZag/RsSN4kYmkJXYJITBTNgjX1GyplXS5Yds72XfrcA+004cO0M dr+SwJoBZbysefGmuMYH5jgi5SYFQRCjqIesHnwqi18jf+vdgzw/LLf6mpODrNrg +Xp5RGrRiuB5XzLwUouAL6xPhs3Tba2MNy/0NpKXwh0u7wdc4LK7B24C8kv44NiB N7T4N9QP1tEqYKpKu9V0BaMJa3+8TJBFXrlgl/Ue1z/reDCI4yrVYSjSHRrkFGNL 5W63Fo61MD3Sqm48mpkTLNaTi6D2m8YTepTKDPn0I7eDytwMwsu1O1xdQMiaUk84 q2sZbno9SF30TVYOawi8VKVPhuuQdKpaGEurI2rKmXve76JOPIBazqogSYqatx8Y yAPIQEOO6VpkvERkkxzL8g/bGL+8cXJT/LptccpWtYzin991i0Kda/vCvUftqHG7 bZCwBavpV6r75FAmd5xvZvy2NzB7VrNXei0lMHpPKenB+I+WfMnkhtTA2DtHu7/1 pgASl6VMsJvkWf2ytou8vzB8f1gYvLVwpk14TlKeni7v97SlRagj/9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway

Samuel Thibault <[email protected]> (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 ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmWxJ20ACgkQ/5FK8MKz VSAWuA/+M9U/giJzDxdq1+n2cX5N86oJaiAD0zTXZv2e3x452hoNSjQkoH7yGtuT q6cHoP1AjwiNpMNuWAOYuBtgd2xEXMYDK0RyuIFA89B2LPUqNa5DsrNVnvGQlt7l +LfL6RpoCRcKorm4MeHcGgKEPA2oEz3G9wPoinsuNKHYr8jhj+T7RThR6ebPVkZv +jPBo31ERRcgxJlxiKUAsqunBifzOWh/m2KRfjv/54BjZPvQfkJcqL657+JoMeF7 zp094HZPD/O4NbB1LaGCjpwmhgjcSIG++33X62ad6EEc4Wh9SZSm6qF7DB/BQmbi qEH5TY7wJa3yZGC9Uo7oXa8fvW1hZKdhWsI7AXR9GNFTTkkQYhGSQtUrIZyEjMhr yz0df3YJb+w5lyCUaLATskbeDh8QEYf7yJQp2FTwn+QaP9GQKuQGahI0CSfSebCG Zs78Fk9QRhlE8tCSk9oNklVPesnSmfF5JQKUxWD4GI+pH+rrFJoJnhywHwMuBT/9 Pitss7kMn1M6JdHwn5E3GXVEaWilsC02jrBg/1ehoymFvx0/BOJwfQZ+K7Yj3vqZ kYmOWrqrbANo2etOs5l4F0LzhwNeimujfRvc7Hl17HreWvU3Zibf/OTfyJg7LYkn gH/vuDZqgopK0Axluw8vwLmM3C6lza/GFpiUMIP+S/iI3JEDg2k=
=+Kzf
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*