Re: 2.6.8-16 in sarge; 2.6.8-15sarge1 for security?
On Mon, Aug 01, 2005 at 08:58:53PM -0600, dann frazier wrote:
> On Tue, 2005-08-02 at 12:32 +0900, Horms wrote:
> > On Mon, Aug 01, 2005 at 07:26:26PM -0600, dann frazier wrote:
> > > hey,
> > > Sorry if this has already been discussed; but I noticed that although
> > > 2.6.8-16 is the latest version of kernel-source in sarge[1],
> > > 2.6.8-15sarge1 appears to be what is in the works[2] for a security
> > > update.
> > >
> > > All the patches referenced in -16 are already in svn for 2.6.8-15sarge1,
> > > so looks like its not a regression problem. The problems would be the
> > > decreasing version string and missing 'Provides:
> > > kernel-tree-2.6.8-16' (and the cosmetic issue of the missing changelog
> > > snippet.)
> > >
> > > Just checking to make sure I'm not on crack; if not, I'll be happy to
> > > relinearize things.
> > >
> > > [1]
> > > $ grep-dctrl -F Package -s Version kernel-source-2.6.8 < Sources.sarge
> > > Version: 2.6.8-16
> > > [2]
> > > $ svn cat svn://svn.debian.org/svn/kernel/sarge-security/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog | head
> >
> > Ok, I think I am the cause of confusion here.
>
> Oh, ok; I'd been working under the (bad) assumption that trunk was
> security + stuff for a point release, and sarge-security was
> security-only. That answers another question I had as well...
My thinking is that as long as there is only one version
we are updating, then we can just handle it in trunk. If
we want to do a security-only release (with the security team),
then that would be a good time to use sarge-security,
as we would probably be creating that as a stripped down
version of what is in trunk. Well, that my thoughts anwyay.
> > I prepared 2.6.8-15sarge1 and 2.6.8-16 at the same time. Is basically
> > the security fixes only version of 2.6.8-16. The plan was to try and
> > get 2.6.8-15sarge1 released as a security updated, and release of
> > 2.6.8-16 into unstable, then testing, and finaly sarge r1. However it
> > turned out to be easier to slip of 2.6.8-16 into sarge, and
> > 2.6.8-15sarge1 was never released. That is 2.6.8-15sarge1 is dead. It
> > will move it to obsolete to avoid further confusion.
> >
> > In the mean time I have been working on updates to 2.6.8-16. These are
> > in the main trunk as 2.6.8-17. These are mostly security updates.
> > However the problem that the security team seems to have very little
> > interest in corrseponding with the kernel team is still present, and for
> > this reason I am very dubious about the possibility of making a seurity
> > update. For this reason I have recently been exploring the idea of making
> > updates to volitile.
> >
> > Using volile seems to have to advantages 1) we can put non-security
> > fixes in, like fixes for broken drivers and 2) the security
> > team don't need to be involved in these updates, which I imagine
> > they would be quite pleased about.
>
> I like the idea from those perspectives; but most of our users are going
> to be completely ignorant of these fixes when apt-get doesn't pull in a
> new version and no DSA ever appears. I think its *critical* that these
> changes go in through the security team.
Yes, I agree. Volatile is good. But its not the answer to
our users' security needs.
The good thing is the work we are doing on these volatile packages -
from mailing list and IRC discussions I think that has more or less been
decided now - should make it very easy to spin out a security release,
but just stripping out the non-security changes and changing the release
number. Or at the very least, collecting all the security patches
together should help someone.
> fyi, I've added team@security.debian.org to the cc list; that's their
> preferred address, iirc; though its not obvious from the FAQ :)
Thanks, I was confused.
> > On a related note, I'd like to remove 2.6.8 and 2.4.27 from unstable.
> > This means removing 2.4 from unstable. Let the fun begin.
>
> yay :)
:-)
--
Horms
Reply to: