On 4 February 2018 at 22:50, Michael Fothergill < michael.fotherg...@gmail.com> wrote:
> > > On 4 February 2018 at 15:20, Andy Smith <a...@strugglers.net> wrote: > >> Hi Michael, >> >> On Sat, Feb 03, 2018 at 11:44:39PM +0000, Michael Fothergill wrote: >> > On 3 February 2018 at 23:14, Andy Smith <a...@strugglers.net> wrote: >> > > If you want to make genuine constructive suggestions for how things >> > > could be improved, I think you should start by identifying what >> > > exactly the deficiencies are. >> > >> > Only wanting kernels quicker so chrooting not needed. >> >> Okay! That, Debian can do. >> >> Easiest thing to do when requiring a newer kernel would be to check >> the backports suite, so in this case in stretch-backports we find >> linux-image-amd64: >> >> <https://packages.debian.org/stretch-backports/linux-image-amd64> >> >> That's a virtual package that gets you the latest real kernel >> package available in that suite, which right now is >> linux-image-4.14.0-0.bpo.3-amd64: >> >> <https://packages.debian.org/stretch-backports/linux-image-amd64> >> >> >From there, if you look on the right you will see the Debian >> changelog link >> <http://ftp-master.metadata.debian.org/changelogs//main/l/li >> nux/linux_4.14.13-1~bpo9+1_changelog> >> which tells us that this corresponds to upstream release 4.14.13. >> The upstream release was made on 10 January and this backports >> package came on 14 January, so that's pretty swift. >> > > This is impressive stuff. I didn't know about this. It seems that > Debian is swifter and more responsive than I thought here.......... > > >> >> Of course, there have been newer upstream kernel releases since >> then, but you can see from the Debian changelog that a new package >> is made available every couple of weeks. >> > > Now that sounds like a way forward here........ > > > >> >> A lot of the time that is going to be "new enough" for anyone >> running Debian stable who for some reason needs a newer kernel. No >> need for compiling anything, no chroot, just install different >> binary packages from a different suite. It was no use for your >> specific request because it still lags behind upstream a little bit >> and it wasn't compiled with a new enough gcc. >> >> Yes, but what you have posted here suggests at least two good things. > > One is that these current kernels are actually very nearly there (and > impressively so) with respect to > offering both meltdown and spectre protection. > > And the joint fix is likely to come a lot faster than I had realised. > > > > >> So what if you really do need to build a Debian kernel package based >> off of the very latest upstream kernel release? >> >> If you take a look at the Debian Linux Kernel Handbook >> <https://kernel-handbook.alioth.debian.org/> you will see there is a >> section about rebuilding the kernel package >> <https://kernel-handbook.alioth.debian.org/ch-common-tasks. >> html#s-common-official>. >> That isn't exactly what you want because it's talking about only >> rebuilding from an existing source package, but it contains >> instructions that you will also need later on. >> >> This is excellent - not just for me but for the brief period when a new > user might want a bit > extra flexiblity without too much technical difficulty - but I now realise > that new kernels > will likely also be put to debian stretch in the conventional way to solve > this faster than > I had thought as well. > > > >> Later on there's a section on building kernel packages from any >> kernel source archive: >> <https://kernel-handbook.alioth.debian.org/ch-common-tasks. >> html#s-kernel-org-package>. >> Using that process you can build kernel packages from the latest >> kernel.org archive available. >> > > I will read up on this. > > >> >> Usually you can do that on the stable release, no chroot needed, >> just a few downloads, a few commands and a lot of CPU time. >> >> The reason why you were directed to do a lot more (chroot and gcc) >> is because in the specific instance of Spectre a new gcc is needed >> as well, and that was only available in Debian sid. Absent that >> requirement, it is much simpler. >> > > And it is only a temporary problem, and also I now realise the response > to it > will come a lot faster than I had realised. > > > >> So there you go, the Debian Kernel team has got you covered for a >> variety of kernel-related needs. :) >> > > Impressive stuff. > > I now realise that I was too gloomy in email posts > and > needed to be > thinking in a "glass half full" kind of way > instead > . > I made a correction to the above sentence. > > Debian has more firepower built into it than I had imagined. > > I apologise for being such a silly eeyore and grinch here. No more > gloomy posts from now on! > > Regards > > MF > >> >> Cheers, >> Andy >> >> -- >> https://bitfolk.com/ -- No-nonsense VPS hosting >> >> >
