On 3 February 2018 at 23:14, Andy Smith <a...@strugglers.net> wrote:

> Hello,
> On Sat, Feb 03, 2018 at 09:43:33PM +0000, Michael Fothergill wrote:
> > I am trying to suggest one would want to move faster than the approximate
> > cycle time of new stable releases here.
> You have been repeatedly told that the updates will appear as
> security updates in Debian stable when the kernel team judges they
> have had an appropriate amount of testing. Security updates do not
> wait for the next stable release, nor even the next stable point
> release.
> You are writing vastly more text in this thread than any other
> single correspondent but you don't appear to be particularly
> familiar with your subject matter. I suggest that for a newcomer
> trying to follow your long and winding tale thinking it is somehow
> representative of Debian, *that* would seem like an odyssey, and
> there's just no need. The answers were all given in the first few
> posts and the rest of it is a combination of you misunderstanding
> what Debian is, and you wishing Debian was something that it's not.

> > I am concerned about new users and what they would have to to
> > install the current kernels (ie use a separate live sid
> > distribution (correctly and helpfully referred to by Andy) to
> > compile the new kernel and then transfer it to the stable
> > install).
> Well I didn't say you needed a live distribution, I suggested a
> chroot would be the normal way. Unless you consider a chroot to be a
> live distribution, which I personally would not, but it is
> debatable.

​OK I am incorrect here.​

> To me a live distribution is something you boot into, whereas a
> chroot is a lightweight thing that you just create, launch processes
> in and then throw away. No rebooting, etc. Telling people that they
> need "a live sid distribution" implies a lot more work than is
> actually required.
> > That does not seem to me to be ideal for a new user.  Hence my
> > comment about it not being fit for purpose at present.
> The Spectre bugs are quite unusual in that they need a kernel update
> *and* a new compiler to build it with (and microcode updates too).
> That is a really exceptional set of requirements and it would be
> inappropriate to design your whole distribution around that being a
> normal state of affairs.
> ​I agree it is only temporary. I don't a dramatic solution but perhaps
bending the rules
a bit for a while because it's a funny problem but I see that is pehpas not
really needed.​

> The mere fact that the Debian kernel team is waiting a little while
> before pushing new packages into stable does not for me render the
> entire distribution "not fit for purpose" - nor even the kernel
> team's processes.

​I did not think that at all.  Really not. It was just having to sid in
some way to make the new kernel for a while in some cases I now realise
with a chroot
I see now not a live distribution.

> *Someone*'s got to do that work and I'd rather
> Debian's kernel team did it than have the latest upstream stuff
> thrown at the general user base.
> Other distributions which track upstream more aggressively are
> designed for that. It's part of their contract with their users.
> Proposals to make some sort of rolling release version of Debian
> that more closely follows upstream have been made many times but
> have never come to much. For example:
>     <https://lists.debian.org/debian-devel/2015/03/msg00045.html>
> > It has been suggested to me others on the site that eventually the
> > GCC 7.3 compiler might be introduced into Debian Buster whereupon
> > it could be used to compile the latest kernels.
> I don't know what the plans are for gcc but that would make things a
> little easier, yes. However the route to a fix for the majority of
> Debian users will be to receive new binary kernel packages from a
> security update. Which is even easier.
> > The odyssey is debian itself as I see it.​
> …because you went on a learning experience and instead of doing what
> multiple people suggested, went down some very long dead ends of
> your own.
> 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. ​

> A lot of this thread seems to have been along the lines of "it's too
> hard to build Debian kernel packages that are fixed against Spectre
> and Meltdown", but the point is marred by a) you taking a lot of
> wrong turns, and b) the Spectre bugs being quite exceptional in how
> they can be mitigated.

​I don't think its much harder than in gentoo which I have already done.
Trying with
GCC was making it more difficult than is now necessaruy and is fair

> Having to build a chroot and then rebuild a kernel package with the
> gcc inside that chroot sounds tricky but it's actually fairly easy
> once you've done it once. Given how rare it is to need to do that,
> I'm not convinced it is that onerous or that it is any kind of
> condemnation of Debian.

​"Condemnation" is too harsh a word.  All I wanted was earlier new kernels
you have pointed out they are comgin soon above.​

​OK, I agree a chroot is *a lot* simpler than a live distribution of sid
etc. I use it
all time with gentoo and chroot into gentoo from debian all the time when
has problems Sorry about that.​

> If that is *not* what you consider the deficiency to be, can you
> succinctly explain what it is?

​I think we should leave it at that.​



> Cheers,
> Andy
> --
> https://bitfolk.com/ -- No-nonsense VPS hosting

Reply via email to