Bug#925411: kernel-package: Not suitable for release

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#925411: kernel-package: Not suitable for release

Ben Hutchings-3
Control: severity -1 serious

On Sun, 2019-03-24 at 16:19 -0600, Nicholas D Steeves wrote:
> Control: severity -1 important
> Justification: essential package that works flawlessly for me

This was agreed with the maintainer, so you should not override it.

The discussion is here:
https://lore.kernel.org/lkml/1551888035-13329-1-git-send-email-yamada.masahiro@.../
but unfortunately Manoj's message didn't get archived there for some
reason.

[...]
> The new style kernel packaging is hard to learn how to use, and builds
> take much longer for some reason (generation of more packages?).
[...]

It sounds like you're looking at the linux source package.  I would
certainly not suggest using that for local custom packages; it's meant
for distributions.

The simple alternative is already included in the kernel tree itself:

    make bindeb-pkg

It does generate some extra packages (linux-headers and linux-libc-dev)
but that doesn't take very long.  The generated packages don't support
/etc/kernel-img.conf but they do support hooks in /etc/kernel.

> 13.018+nmu1 on buster works like it always has for me--flawlessly.  I
> built upstream vanilla 4.19.31 two days ago.

Bug #890817 also looks like it may be a big problem for current kernel
versions, but apparently you have avoided it.

Ben.

--
Ben Hutchings
Larkinson's Law: All laws are basically false.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#925411: kernel-package: Not suitable for release

Ben Hutchings-3
On Mon, 2019-04-08 at 00:20 -0400, Nicholas D Steeves wrote:
[...]
> Ah, yes, thank you! :-)  Regarding documentation, should
> Debian-specific bits go on our wiki or be forwarded upstream?

The bindeb-pkg target is part of the upstream build system, not
something patched in by Debian, so the primary place to document it
should be upstream.

[...]
> Should users who track a 4.19.x-based branch use buster's
> linux-libc-dev headers, or install the ones that correspond to their
> custom kernel?
[...]

No, the only reason to install a custom linux-libc-dev package would be
to provide definitions for new UAPI added in a new kernel version.

Ben.

--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.



signature.asc (849 bytes) Download Attachment