Hi Ben, On Sun, Mar 24, 2019 at 11:23:58PM +0000, Ben Hutchings wrote: > 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.masah...@socionext.com/ > but unfortunately Manoj's message didn't get archived there for some > reason. >
Maybe I'm missing something, but I couldn't find sufficient justification there... That said, I did more tests, because an RC bug that cuts such a useful package from a release really ought to have justification. I can now confirm that at least one dkms module (tp-smapi-dkms) doesn't build with make-kpkg-generated kernel packages on buster. Maybe all dkms modules are affected? Maybe Manoj' message said something to that affect, and how make-kpkg produces packages that are defective in this way...and maybe other ways? > [...] > > 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 > Ah, yes, thank you! :-) Regarding documentation, should Debian-specific bits go on our wiki or be forwarded upstream? eg: the top line of BuildADebianKernelPackage says "this is an obsolete now guide", but then at the bottom it says "make -j`nproc` bindeb-pkg". I specifically missed that because first line conveys the message "stop reading this doc now, it's an obsolete waste of time". > 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. > 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? > > 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. > For once, yes :-) Generally I'm unlucky and hit all the bugs haha. Thanks again for taking the time to reply, I appreciate it! Also, thank you for your hard work, and for all time spent on the BTS. Cheers, Nicholas
signature.asc
Description: PGP signature
