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 <st...@einval.com> (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? -- Steve McIntyre, Cambridge, UK. st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
