Re: Preparing 2.6.18.dfsg.1-13
On Mon, Apr 09, 2007 at 04:48:29PM +0200, Bastian Blank wrote: > On Sun, Apr 08, 2007 at 01:38:31PM -0600, dann frazier wrote: > > Sure, I can handle them. > > Okay. > > You want to use the -XetchY namespace for security builds and the -X for > p-u uploads? The first is no problem, but the later is if we don't > update linux-2.6 in testing ASAP. That was my default plan, but I can use -XetchY in the meantime for both since they need to be ordered anyway. > > Rebuild on every linux-2.6 update > > - > > fai-kernels > > user-mode-linux > > BinNMUs at least for fai-kernels will work. Ah, good point. > > Rebuild on ABI changes > > -- > > linux-latest-2.6 > > linux-modules-contrib-2.6 > > linux-modules-extra-2.6 > > linux-modules-nonfree-2.6 > > loop-aes > > nvidia-kernel-legacy-2.6.18-4-amd64 > > Hmm? What's your question? > > Does this need rebuilding? > > -- > > firmware-nonfree > > No. Except that the build dependencies will go away. A FTBFS is certainly a regression, so I suppose this should be on the ABI change list? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.18.dfsg.1-13
* Bastian Blank ([EMAIL PROTECTED]) [070409 16:48]: > You want to use the -XetchY namespace for security builds and the -X for > p-u uploads? The first is no problem, but the later is if we don't > update linux-2.6 in testing ASAP. Well, don't you plan to upload linux-2.6 soon anyways? :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.18.dfsg.1-13
On Sun, 08 Apr 2007, dann frazier wrote: > From what I can tell, the following packages need to updated along > with linux-2.6 (in dists/etch/dependent-pkgs in svn). Are there any > obvious ones missing? > > Rebuild on every linux-2.6 update > - > fai-kernels > user-mode-linux > > Rebuild on ABI changes > -- > linux-latest-2.6 > linux-modules-contrib-2.6 > linux-modules-extra-2.6 > linux-modules-nonfree-2.6 > loop-aes > nvidia-kernel-legacy-2.6.18-4-amd64 > nvidia-graphics-legacy-modules-i386 > nvidia-graphics-modules-amd64 > nvidia-graphics-modules-i386 klibc (will get fixed in lenny with the newly exported headers) notify me and i'd like to handle that. > Does this need rebuilding? > -- > firmware-nonfree > > -- > dann frazier -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.18.dfsg.1-13
On Sun, Apr 08, 2007 at 01:38:31PM -0600, dann frazier wrote: > Sure, I can handle them. Okay. You want to use the -XetchY namespace for security builds and the -X for p-u uploads? The first is no problem, but the later is if we don't update linux-2.6 in testing ASAP. > Rebuild on every linux-2.6 update > - > fai-kernels > user-mode-linux BinNMUs at least for fai-kernels will work. > Rebuild on ABI changes > -- > linux-latest-2.6 > linux-modules-contrib-2.6 > linux-modules-extra-2.6 > linux-modules-nonfree-2.6 > loop-aes > nvidia-kernel-legacy-2.6.18-4-amd64 Hmm? > Does this need rebuilding? > -- > firmware-nonfree No. Except that the build dependencies will go away. Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, "The Corbomite Maneuver", stardate 1514.0 signature.asc Description: Digital signature
Re: Preparing 2.6.18.dfsg.1-13
dann frazier wrote: >>From what I can tell, the following packages need to updated along > with linux-2.6 (in dists/etch/dependent-pkgs in svn). Are there any > obvious ones missing? openvz is closely coupled and likely requires a source-level resync. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.18.dfsg.1-13
On Sun, Apr 08, 2007 at 08:22:58PM +0200, Bastian Blank wrote: > On Thu, Apr 05, 2007 at 03:01:41PM -0600, dann frazier wrote: > > aba tells me that we should be able to do our first upload real soon > > now. Once he gives me a go, I'd like to upload a -13. Again, that > > doesn't mean that -13 will ship in r1 - if we resolve additional > > issues in time we can always do another upload. Please let me know if > > you have any concerns about this plan, or if you have any imminent > > fixes we should wait for. > > This is fine for me. Do you want to handle the uploads? Otherwise I can > take my hands on it. linux-latest-2.6 needs to be updated as well. Sure, I can handle them. >From what I can tell, the following packages need to updated along with linux-2.6 (in dists/etch/dependent-pkgs in svn). Are there any obvious ones missing? Rebuild on every linux-2.6 update - fai-kernels user-mode-linux Rebuild on ABI changes -- linux-latest-2.6 linux-modules-contrib-2.6 linux-modules-extra-2.6 linux-modules-nonfree-2.6 loop-aes nvidia-kernel-legacy-2.6.18-4-amd64 nvidia-graphics-legacy-modules-i386 nvidia-graphics-modules-amd64 nvidia-graphics-modules-i386 Does this need rebuilding? -- firmware-nonfree -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.18.dfsg.1-13
On Thu, Apr 05, 2007 at 03:01:41PM -0600, dann frazier wrote: > aba tells me that we should be able to do our first upload real soon > now. Once he gives me a go, I'd like to upload a -13. Again, that > doesn't mean that -13 will ship in r1 - if we resolve additional > issues in time we can always do another upload. Please let me know if > you have any concerns about this plan, or if you have any imminent > fixes we should wait for. This is fine for me. Do you want to handle the uploads? Otherwise I can take my hands on it. linux-latest-2.6 needs to be updated as well. > Since both the etch and etch-security branches contain ABI breakers > and since neiter of the security issues is critical enough (imo) to > warrant an immediate DSA, I plan to merge the security changes into > the etch branch and introduce them in r1. Okay. Bastian -- ... The prejudices people feel about each other disappear when they get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5 signature.asc Description: Digital signature
Preparing 2.6.18.dfsg.1-13
The SRM team would like for us to keep s-p-u current with our latest fixes, rather than holding back uploads until just before a point release. This means we may upload multiple candidates before one actually makes it into etch. This should increase our testing base, get us autobuilt on more architectures[1], and hopefully reduce the latency of doing regular point releases. aba tells me that we should be able to do our first upload real soon now. Once he gives me a go, I'd like to upload a -13. Again, that doesn't mean that -13 will ship in r1 - if we resolve additional issues in time we can always do another upload. Please let me know if you have any concerns about this plan, or if you have any imminent fixes we should wait for. Since both the etch and etch-security branches contain ABI breakers and since neiter of the security issues is critical enough (imo) to warrant an immediate DSA, I plan to merge the security changes into the etch branch and introduce them in r1. [1] kernel-archive.buildserver.net is doing snapshot builds for the etch branch, so that should catch most build issues and help us catch issues in-between uploads to s-p-u -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
