Bug#1084789: debian-testing-amd64-netinst.iso has multiple versions of module udebs

Control: forcemerge 1088605 1084789

(#1088605 is very clearly caused by the many sets of udebs, I think)

On Sun, Dec 15, 2024 at 04:38:57AM +0100, Cyril Brulebois wrote:
>Cc += ftp team (for input), kernel team (for information)

ACK, thanks - should have thought of that!

>Steve McIntyre <[email protected]> (2024-12-15):
>> I think there's a problem here in (the archive|the kernel packaging),
>> as far as I can see. Look at
>> 
>>   https://packages.debian.org/source/unstable/linux-signed-amd64
>> 
>> and you'll see that right now the linux-signed-amd64 (6.12.3+1) source
>> package claims to build modules for all of the following kernel
>> ABIs.
>
>No, it does not.
>
>> Picking crypto-dm-modules-* as an example:
>> 
>>  * crypto-modules-6.10.9-amd64-di
>>  * crypto-modules-6.10.9-amd64-di
>>  * crypto-modules-6.10.11-amd64-di
>>  * crypto-modules-6.10.11-amd64-di
>>  * crypto-modules-6.10.12-amd64-di
>>  * crypto-modules-6.10.12-amd64-di
>>  * crypto-modules-6.11.2-amd64-di
>>  * crypto-modules-6.11.2-amd64-di
>>  * crypto-modules-6.11.4-amd64-di
>>  * crypto-modules-6.11.4-amd64-di
>>  * crypto-modules-6.11.5-amd64-di
>>  * crypto-modules-6.11.5-amd64-di
>>  * crypto-modules-6.11.6-amd64-di
>>  * crypto-modules-6.11.6-amd64-di
>>  * crypto-modules-6.11.7-amd64-di
>>  * crypto-modules-6.11.7-amd64-di
>>  * crypto-modules-6.11.9-amd64-di
>>  * crypto-modules-6.11.9-amd64-di
>>  * crypto-modules-6.11.10-amd64-di
>>  * crypto-modules-6.11.10-amd64-di
>>  * crypto-modules-6.12.3-amd64-di
>>  * crypto-modules-6.12.3-amd64-di
>
>That's just how packages.d.o represents things; the tracker page is
>less misleading.

Ah, OK. That's an unfortunate display issue there. :-(

>> debian-cd just pulls in all the modules in a release, expecting that
>> to be a sensible set.
>
>Any thoughts about my proposal to lift that expectation?

That looks eminently possible as a workaround at the very
least. Working on it now.

And yes: we should definitely ensure that the first image in each set
has linux-image-$foo and all dependencies. And fail the build
otherwise - this is critical, as you say!

>> WTH is happening here?
>
>A number of source versions are being kept for some reason:
>
>    $ rmadison linux-signed-amd64 -s unstable
>    linux-signed-amd64 | 6.10.9+1      | unstable   | source
>    linux-signed-amd64 | 6.10.11+1     | unstable   | source
>    linux-signed-amd64 | 6.10.12+1     | unstable   | source
>    linux-signed-amd64 | 6.11.2+1      | unstable   | source
>    linux-signed-amd64 | 6.11.4+1      | unstable   | source
>    linux-signed-amd64 | 6.11.5+1      | unstable   | source
>    linux-signed-amd64 | 6.11.6+1      | unstable   | source
>    linux-signed-amd64 | 6.11.7+1      | unstable   | source
>    linux-signed-amd64 | 6.11.9+1      | unstable   | source
>    linux-signed-amd64 | 6.11.10+1     | unstable   | source
>    linux-signed-amd64 | 6.12.3+1      | unstable   | source
>
>Note: this isn't a case of Extra-Source-Only fun.
>
>(Another way to see this is to `apt-cache showsrc linux` in a sid
>environment, you'll see the many versions.)
>
>Binaries stay around and nothing seems to show up in the cruft report.

Nod, looking in sid here:

$ zgrep -c "Package: linux-signed-amd64" /mirror/debian/dists/unstable/main/source/Sources.gz
11

ftp folks: this looks like a problem with cruft building up for some
reason?