Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #84820 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1084789: debian-testing-amd64-netinst.iso has multiple versions of module udebs Cyril Brulebois <kibi@debian.org> - 2024-12-15 04:50 +0100
    Bug#1084789: debian-testing-amd64-netinst.iso has multiple versions of module udebs Steve McIntyre <steve@einval.com> - 2024-12-15 20:10 +0100
      Bug#1084789: debian-testing-amd64-netinst.iso has multiple versions of module udebs Steve McIntyre <steve@einval.com> - 2024-12-15 23:30 +0100
      Bug#1088605: Bug#1084789: debian-testing-amd64-netinst.iso has multiple versions of module udebs Cyril Brulebois <kibi@debian.org> - 2024-12-15 23:30 +0100
        Bug#1084789: debian-testing-amd64-netinst.iso has multiple versions of module udebs Steve McIntyre <steve@einval.com> - 2024-12-16 23:10 +0100
          Bug#1084789: Bug#1088605: Bug#1084789: debian-testing-amd64-netinst.iso has multiple versions of module udebs Cyril Brulebois <kibi@debian.org> - 2024-12-17 02:50 +0100

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

[Multipart message — attachments visible in raw view] — view raw

Cc += ftp team (for input), kernel team (for information)

Steve McIntyre <steve@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.

> 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?

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


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [next] | [standalone]

#84832

On Sun, Dec 15, 2024 at 05:14:55PM +0000, Steve McIntyre wrote:
>On Sun, Dec 15, 2024 at 04:38:57AM +0100, Cyril Brulebois wrote:
>>
>>Any thoughts about my proposal to lift that expectation?
>
>That looks eminently possible as a workaround at the very
>least. Working on it now.

In fact, simpler answer: there was already code in
tools/generate_di_list to cope with udebs for multiple kernel versions
in the archive. The change of package names for udebs (no ABI included
now) broke a regexp there. I've fixed things up to cope with either
style, and that should do what we want here.

>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!

Looking at this next.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

[toc] | [prev] | [next] | [standalone]

#84835

On Sun, Dec 15, 2024 at 06:58:18PM +0000, Steve McIntyre wrote:
>On Sun, Dec 15, 2024 at 05:14:55PM +0000, Steve McIntyre wrote:
>>On Sun, Dec 15, 2024 at 04:38:57AM +0100, Cyril Brulebois wrote:
>>>
>>>Any thoughts about my proposal to lift that expectation?
>>
>>That looks eminently possible as a workaround at the very
>>least. Working on it now.
>
>In fact, simpler answer: there was already code in
>tools/generate_di_list to cope with udebs for multiple kernel versions
>in the archive. The change of package names for udebs (no ABI included
>now) broke a regexp there. I've fixed things up to cope with either
>style, and that should do what we want here.

I just triggered a manual netinst build now, and things look OK from
the log output. Grabbing the amd64 netinst to test locally now.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"This dress doesn't reverse." -- Alden Spiess

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Steve McIntyre <steve@einval.com> (2024-12-15):
> On Sun, Dec 15, 2024 at 05:14:55PM +0000, Steve McIntyre wrote:
> >On Sun, Dec 15, 2024 at 04:38:57AM +0100, Cyril Brulebois wrote:
> >>
> >>Any thoughts about my proposal to lift that expectation?
> >
> >That looks eminently possible as a workaround at the very
> >least. Working on it now.
> 
> In fact, simpler answer: there was already code in
> tools/generate_di_list to cope with udebs for multiple kernel versions
> in the archive. The change of package names for udebs (no ABI included
> now) broke a regexp there. I've fixed things up to cope with either
> style, and that should do what we want here.

OK, thanks. I had decided to wait a little for some possible feedback before
spending time looking into it on my own, I should have looked directly… :/

> >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!
> 
> Looking at this next.

Thanks.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#84850

On Sun, Dec 15, 2024 at 11:20:25PM +0100, Cyril Brulebois wrote:
>Steve McIntyre <steve@einval.com> (2024-12-15):
>> On Sun, Dec 15, 2024 at 05:14:55PM +0000, Steve McIntyre wrote:
>
>> >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!
>> 
>> Looking at this next.
>
>Thanks.

Done and working. This already caused me to fix our s390x and mips64el
image generation - they've *never* had kernels pulled onto image
#1. Nobody is using these images... *sigh*

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Steve McIntyre <steve@einval.com> (2024-12-16):
> Done and working. This already caused me to fix our s390x and mips64el
> image generation - they've *never* had kernels pulled onto image
> #1.

OK. That matches the two archs I mentioned earlier as being possibly
tricky because of their kernel variations… The bottom line is a bit meh
(regarding usage or lack thereof) but at least there's some overall
consistency, so yay?


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web