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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
