Re: 2.6.8-16 in sarge; 2.6.8-15sarge1 for security?
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.
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.
For the record, the same holds with 2.4.27. 2.4.27-10 is in sarge,
2.4.27-9sarge1 is dead, and the current lastest and greatest in svn is
2.4.27-11, in the main trunk.
If the packages end up in volatile, they should probably be
2.6.8-16volatile1 and 2.4.27-10volatile1 respecrively. If they end up
in security they should probably be 2.6.8-16sarge1 and 2.4.27-10sarge1
respectively. But s comes before v, so I am not sure of the long term
implications of that naming scheme. Perhaps we would
be better to make the volatile uploads follow the unstable
naming convention, that is just make them 2.6.8-17 and 2.4.27-11
respectively.
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.
--
Horms
Reply to: