Hi, Daniel Lewart <lewa...@gmail.com> (2025-06-29): > The Weekly build of the installer image for amd64 has grown by 4%: > * 811597824 Jun 16 00:23 debian-testing-amd64-netinst.is0 > * 846200832 Jun 22 22:39 debian-testing-amd64-netinst.iso
That happens when building images from d-i daily builds, built against
sid. That doesn't happen when building against an official d-i, built
against testing.
I'd prefer not merging this patch before the upcoming D-I Trixie RC 2,
just to be on the safe side of things.
> diff -ru a/tools/generate_di_list b/tools/generate_di_list
> --- a/tools/generate_di_list 2025-06-24 14:46:12.000000000 -0500
> +++ b/tools/generate_di_list 2025-06-29 00:00:00.000000000 -0500
> @@ -141,7 +141,7 @@
> # Append this driver udeb to a list for that kernel_ver
> push(@{ $driver_udebs{$kernel_ver} }, $udeb);
>
> - } elsif ($udeb =~ m/-modules-(\d+)\.(\d+)\.(\d+)-.*-di/) {
> + } elsif ($udeb =~
> m/-modules-(\d+)\.(\d+)\.(\d+)(\+deb\d+)?-.*-di$/) {
I don't think we'll have cases where we have +deb13 vs. +deb14, with the
exact same upstream version, so I suppose it doesn't really make sense
to try and capture the last digits and reinject them below:
> # Newer udeb package names don't, so use "0" as a dummy
> value here
> my $kernel_ver = di_ker_abi_to_number($1, $2, $3, 0);
> if ($kernel_ver > $highest_kernel_ver) {
… but I'm making a note of it anyway.
With my easy-build.sh-based setup, targetting NETINST (much smaller than
STICK1GB), I'm indeed getting an FTBFS due to lack of space, having both
sets of packages. With this patch, the problem goes away, and the image
can be generated successfully.
Cheers,
--
Cyril Brulebois (k...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
