Re: sarge3 kernel build r3
On Mon, Jun 12, 2006 at 06:50:36PM -0600, dann frazier wrote: The exceptions are: * linux-kernel-di-powerpc appears to require a 2.4 build host - I've poked around looking for help here, but no volunteers yet. Still need help with this one... * linux-kernel-di-m68k-* - I've just e-mailed pokes to a couple m68k folks Done (thanks Stephen!) * linux-kernel-di-mips* - I've poked a few mips folks; one responded saying that he could probably get a build done tomorrow night. Done (thanks tbm/Sledge!) -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Tue, Jun 13, 2006 at 03:41:42PM -0600, dann frazier wrote: On Mon, Jun 12, 2006 at 06:50:36PM -0600, dann frazier wrote: The exceptions are: * linux-kernel-di-powerpc appears to require a 2.4 build host - I've poked around looking for help here, but no volunteers yet. Still need help with this one... Sledge saw this did a build for us, so now all builds are complete and available at: people.debian.org:~dannf/3.1r3-lkdi-rebuilds Let me know if/when I should upload them. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Tue, Jun 06, 2006 at 01:32:42PM -0600, dann frazier wrote: On Tue, Jun 06, 2006 at 09:23:45PM +0200, Frans Pop wrote: The more arches are built by the same person, the easier coordination is. So your offer is very welcome. Note that you'll need to check out the kernel udeb package sources from the *sarge branch* of the d-i SVN repo for the different arches as ABI numbers have to be updated there. yes, np. I'll try to have these done by this weekend. Here's the current status... DSA is pending for the security update; jmm thought he'd be able to et those released tonight. I haven't reconfirmed this with him today. lkdi builds for most archs are complete, and at: people.debian.org:~dannf/3.1r3-lkdi-rebuilds The exceptions are: * linux-kernel-di-powerpc appears to require a 2.4 build host - I've poked around looking for help here, but no volunteers yet. * linux-kernel-di-m68k-* - I've just e-mailed pokes to a couple m68k folks * linux-kernel-di-mips* - I've poked a few mips folks; one responded saying that he could probably get a build done tomorrow night. The only interesting bit about these rebuilds is that the jfs-modules udeb has been dropped from ia64. jfs is completely broken on ia64, and I dropped the module build before sarge's release. This probably requires a pkglist tweak in d-i. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
dann frazier wrote: On Tue, Jun 06, 2006 at 01:32:42PM -0600, dann frazier wrote: On Tue, Jun 06, 2006 at 09:23:45PM +0200, Frans Pop wrote: The more arches are built by the same person, the easier coordination is. So your offer is very welcome. Note that you'll need to check out the kernel udeb package sources from the *sarge branch* of the d-i SVN repo for the different arches as ABI numbers have to be updated there. yes, np. I'll try to have these done by this weekend. Here's the current status... DSA is pending for the security update; jmm thought he'd be able to et those released tonight. I haven't reconfirmed this with him today. There have been some interruptions (klecker running out of disk space and strange NEW processing for some packages), which micht delay this a few days further. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
Karl Schmidt [EMAIL PROTECTED] writes: For people wanting to install Sarge on AMD64 I recommend using the mini.iso found here: http://amd64.debian.net/debian-installer/daily/netboot/ I did a sarge jfs on RAID with home on jfs/raid1/lvm with only minor problems with this iso. There should be a mention of this iso on the main installer page for the time being. The main page http://www.us.debian.org/devel/debian-installer/ links to there under the If you'd like something newer section: * other images (netboot, usb stick, floppy, tape, etc) [alpha] [amd64] [arm] [hppa] [i386] [ia64] [m68k] [mips] [mipsel] [powerpc] [s390] [sparc] MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
Sven Luther [EMAIL PROTECTED] writes: On Thu, Jun 08, 2006 at 09:33:54PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: That said, currently, backports are not an easy solution because of udev, which cannot be taken as is without pulling in the whole gnome, so a bit of work is needed. Friendly, Sven Luther What do you mean? You don't seriously mean udev depends on gnome? The version of udev in unstable means it cannot be installed with the stable gnome. I don't remember the details, but it involves gnome-volume-manager, the hal thingy and another package. But that is probably not something that can even be solved easily. udev changed quite a lot since sarge and anything interacting with it, like gnome-volume-manager, probably can't be fixed. Does the stable gnome conflict with the backports udev? Is that realy a problem? It is inconvenient but if the depends are that way then it can't be helped. As long as it works that's fine by me. I think there is some work needed on the sid udev to have it compile in a sarge environment, it is possible, it may even have been done for backport.org, but it doesn't build out of the box like the other packages. And since udev is needed for initramfs-tools, which is needed by the kernels, ... Yes, there was work needed but that ahs been done. Backports has a udev so that is solved. Also do you think that is an usual situation? Will it arise again for etch? I would think this is only a short term problem till etch comes out. udev is a mess, i can only hope that this will not come to happen in the future (even Linus had very harsh words about the current situation), but i can't promise anything. Already it is not possible in the current state to have upgrade udev with the 2.6.8 kernel installed. Friendly, Sven Luther Sux, doesn't it. :( MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
(Also replying to other mails about Sarge support in Etch installer) On Wednesday 07 June 2006 20:42, Goswin von Brederlow wrote: Frans Pop [EMAIL PROTECTED] writes: I ment that when you select sarge in choose-mirror in expert mode you get the inofficial list and if you choose etch/etch+1/sid you get the official one. Ah, OK. The Etch installer currently has extremely basic support for Sarge installations which has only really been tested for i386. The real downside of using the Etch installer for Sarge is that, although a current kernel will be used for the installation, it will still install 2.6.8 for the target system (it does not use any backports). This means that there is a relatively high chance that the user will experience problems on the reboot into the target system. I'm currently unsure if the udeb that adds Sarge support for the Etch installer will make it into the final release of d-i for Etch. The main reasons are: - increasing differences between the Sarge 2.6.8 and current kernels; - questionable usability of systems installed this way; - Sarge support may be incompatible with changes needed to realize persistent device naming for harddrives. If it does make it, there will be disclaimers shown to the user after mirror selection to the effect that there is only limited support and not to come complaining if there are problems on reboot. To finally answer your question: I don't think we will offer the unofficial AMD64 mirrors in the Etch installer in this case, if only because the mirror selection happens _before_ the suite/codename is selected. Cheers, FJP pgpgtFivUvOfy.pgp Description: PGP signature
Reboot in d-i (Was: Re: sarge3 kernel build r3)
On Thu, Jun 08, 2006 at 08:53:34AM +0200, Frans Pop wrote: installations which has only really been tested for i386. The real downside of using the Etch installer for Sarge is that, although a current kernel will be used for the installation, it will still install 2.6.8 for the target system (it does not use any backports). This means that there is a relatively high chance that the user will experience problems on the reboot into the target system. I never understood why it is necessary to reboot the system after installation. I remember that many years ago SuSE (don't know current status) just chrooted into the installed system. That's also nice compared to other commercial systems which required 10 or more reboots until they were ready (current state also unknown). It may be useful to test the bootloader and makes it easier to upgrade the kernel but is it required? Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reboot in d-i (Was: Re: sarge3 kernel build r3)
On Thu, Jun 08, 2006 at 09:50:44AM +0200, Jens Seidel wrote: On Thu, Jun 08, 2006 at 08:53:34AM +0200, Frans Pop wrote: installations which has only really been tested for i386. The real downside of using the Etch installer for Sarge is that, although a current kernel will be used for the installation, it will still install 2.6.8 for the target system (it does not use any backports). This means that there is a relatively high chance that the user will experience problems on the reboot into the target system. I never understood why it is necessary to reboot the system after installation. I remember that many years ago SuSE (don't know current status) just chrooted into the installed system. That's also nice compared to other commercial systems which required 10 or more reboots until they were ready (current state also unknown). This does indeed work just nicely, but the idea is to test the kernel bootloader install, and it is better to test that early, than at some later time when you just suffered from a loss of power while away and the system doesn't boot back. It may be useful to test the bootloader and makes it easier to upgrade the kernel but is it required? Not really, it is a technical choice that was made for the above reasons, nothing else. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
Frans Pop [EMAIL PROTECTED] writes: (Also replying to other mails about Sarge support in Etch installer) On Wednesday 07 June 2006 20:42, Goswin von Brederlow wrote: Frans Pop [EMAIL PROTECTED] writes: I ment that when you select sarge in choose-mirror in expert mode you get the inofficial list and if you choose etch/etch+1/sid you get the official one. Ah, OK. The Etch installer currently has extremely basic support for Sarge installations which has only really been tested for i386. The real downside of using the Etch installer for Sarge is that, although a current kernel will be used for the installation, it will still install 2.6.8 for the target system (it does not use any backports). This means that there is a relatively high chance that the user will experience problems on the reboot into the target system. Basicaly 100% since the user would/should have used the sarge installer if possible. But adding backports to the sources.list and installing a newer kernel is easily explained in a HowTo and done by the user on the fly. I don't think that this is a real show stopper. One could think about adding backports to sources.list automatically though if the testing installer is used to install stable. I'm currently unsure if the udeb that adds Sarge support for the Etch installer will make it into the final release of d-i for Etch. The main reasons are: - increasing differences between the Sarge 2.6.8 and current kernels; That is a reason for. - questionable usability of systems installed this way; Hmm, what is questionable? A stable system with a fresher kernel is totaly usable. A lot, if not the majority, of users do this. - Sarge support may be incompatible with changes needed to realize persistent device naming for harddrives. What changes are those? Is Debian finaly going to use LABEL= or UUID= in the generated fstab? Isn't that also just limited to kernel, udev and fstab? udev is also available on backports so there should be no big problem there. If it does make it, there will be disclaimers shown to the user after mirror selection to the effect that there is only limited support and not to come complaining if there are problems on reboot. Isn't it enough that you already need expert mode? To finally answer your question: I don't think we will offer the unofficial AMD64 mirrors in the Etch installer in this case, if only because the mirror selection happens _before_ the suite/codename is selected. That is a problem indeed. Cheers, FJP MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Thu, Jun 08, 2006 at 01:33:57PM +0200, Goswin von Brederlow wrote: Frans Pop [EMAIL PROTECTED] writes: What changes are those? Is Debian finaly going to use LABEL= or UUID= in the generated fstab? I hope not; /dev/disk/by-* names seem a lot less kludgy to me. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Thursday 08 June 2006 13:33, Goswin von Brederlow wrote: - increasing differences between the Sarge 2.6.8 and current kernels; That is a reason for. Only if we _would_ include some backports repository that is known to have a current backported kernel and all other packages needed with that kernel, but without random backports of other packages. And we would need some guarantees about the maintenance of and procedures for changes in such a repository (compare volatile.d.n). If we don't include such a repository, we're only offering an installation that is known not to work on the reboot. And currently we don't. If it does make it, there will be disclaimers shown to the user after mirror selection to the effect that there is only limited support and not to come complaining if there are problems on reboot. Isn't it enough that you already need expert mode? IMO not. Especially if we would add a backported repo by default as we'd have to make clear that the upgrade path of such a system to the next stable release is not guaranteed. Too many regular users choose expert mode (and you don't even need expert mode; deconf/priority=medium will offer Sarge as well). pgpH8G9OfgEfX.pgp Description: PGP signature
Re: sarge3 kernel build r3
On Thu, Jun 08, 2006 at 07:16:57PM +0200, Frans Pop wrote: On Thursday 08 June 2006 13:33, Goswin von Brederlow wrote: - increasing differences between the Sarge 2.6.8 and current kernels; That is a reason for. Only if we _would_ include some backports repository that is known to have a current backported kernel and all other packages needed with that kernel, but without random backports of other packages. And we would need some guarantees about the maintenance of and procedures for changes in such a repository (compare volatile.d.n). volatile.d.n is not a valid solution for this, since it doesn't allow for a flexible enough upload of packages (like bumped build-dependencies for stuff like kernel-package and other kernel related packages). The kernel team did already have this discussion some time ago (last year ever) and the result was to use kernel.debian.org as a repository for those. Check the debian-kernel archive for details. That said, currently, backports are not an easy solution because of udev, which cannot be taken as is without pulling in the whole gnome, so a bit of work is needed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
Frans Pop [EMAIL PROTECTED] writes: On Thursday 08 June 2006 13:33, Goswin von Brederlow wrote: - increasing differences between the Sarge 2.6.8 and current kernels; That is a reason for. Only if we _would_ include some backports repository that is known to have a current backported kernel and all other packages needed with that kernel, but without random backports of other packages. And we would need some guarantees about the maintenance of and procedures for changes in such a repository (compare volatile.d.n). If we don't include such a repository, we're only offering an installation that is known not to work on the reboot. And currently we don't. Worst case you have to add testing to sources.list and get the kernel from there. With the right pining or default release that still leaves you nearly completly stable. I also think we can trust backports.org to continue its great service of backporting. Lay out some groundrules that need to be met to support testing-sarge installs and I'm sure something can be worked out from there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Thursday 08 June 2006 20:08, Sven Luther wrote: On Thu, Jun 08, 2006 at 07:16:57PM +0200, Frans Pop wrote: Only if we _would_ include some backports repository that is known to have a current backported kernel and all other packages needed with that kernel, but without random backports of other packages. And we would need some guarantees about the maintenance of and procedures for changes in such a repository (compare volatile.d.n). volatile.d.n is not a valid solution for this, since it doesn't allow for a flexible enough upload of packages Would you please _read_ before you reply? I did not suggest using volatile for this. I was only saying that a repository with such backported packages would need a similar (though different) policy like aba and zobel formulated for volatile). I have not seen a formal policy defined for the kernel.debian.org repos that would make it suitable for this purpose for the d-i. pgpzX2moEdUq9.pgp Description: PGP signature
Re: sarge3 kernel build r3
Sven Luther [EMAIL PROTECTED] writes: That said, currently, backports are not an easy solution because of udev, which cannot be taken as is without pulling in the whole gnome, so a bit of work is needed. Friendly, Sven Luther What do you mean? You don't seriously mean udev depends on gnome? Does the stable gnome conflict with the backports udev? Is that realy a problem? It is inconvenient but if the depends are that way then it can't be helped. As long as it works that's fine by me. Also do you think that is an usual situation? Will it arise again for etch? I would think this is only a short term problem till etch comes out. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
For people wanting to install Sarge on AMD64 I recommend using the mini.iso found here: http://amd64.debian.net/debian-installer/daily/netboot/ I did a sarge jfs on RAID with home on jfs/raid1/lvm with only minor problems with this iso. There should be a mention of this iso on the main installer page for the time being. Karl Schmidt EMail [EMAIL PROTECTED] Transtronics, Inc. WEB http://xtronics.com 3209 West 9th StreetPh (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Time wounds all heels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Thu, Jun 08, 2006 at 09:33:54PM +0200, Goswin von Brederlow wrote: Sven Luther [EMAIL PROTECTED] writes: That said, currently, backports are not an easy solution because of udev, which cannot be taken as is without pulling in the whole gnome, so a bit of work is needed. Friendly, Sven Luther What do you mean? You don't seriously mean udev depends on gnome? The version of udev in unstable means it cannot be installed with the stable gnome. I don't remember the details, but it involves gnome-volume-manager, the hal thingy and another package. Does the stable gnome conflict with the backports udev? Is that realy a problem? It is inconvenient but if the depends are that way then it can't be helped. As long as it works that's fine by me. I think there is some work needed on the sid udev to have it compile in a sarge environment, it is possible, it may even have been done for backport.org, but it doesn't build out of the box like the other packages. And since udev is needed for initramfs-tools, which is needed by the kernels, ... Also do you think that is an usual situation? Will it arise again for etch? I would think this is only a short term problem till etch comes out. udev is a mess, i can only hope that this will not come to happen in the future (even Linus had very harsh words about the current situation), but i can't promise anything. Already it is not possible in the current state to have upgrade udev with the 2.6.8 kernel installed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Thu, Jun 08, 2006 at 09:33:51PM +0200, Frans Pop wrote: On Thursday 08 June 2006 20:08, Sven Luther wrote: On Thu, Jun 08, 2006 at 07:16:57PM +0200, Frans Pop wrote: Only if we _would_ include some backports repository that is known to have a current backported kernel and all other packages needed with that kernel, but without random backports of other packages. And we would need some guarantees about the maintenance of and procedures for changes in such a repository (compare volatile.d.n). volatile.d.n is not a valid solution for this, since it doesn't allow for a flexible enough upload of packages Would you please _read_ before you reply? I did not suggest using volatile for this. I was only saying that a repository with such backported packages would need a similar (though different) policy like aba and zobel formulated for volatile). ok, but this minor mistake of mine is non-substantial, the important thing was to point out that there was already a discussion about this selfsame subject, and i pointed to it for the purpose of those who didn't follow that discussion last time. Why are you so quick to jump on me again ? I have not seen a formal policy defined for the kernel.debian.org repos that would make it suitable for this purpose for the d-i. You also have not seen any formal policy defined that makes it unsuitable ffor d-i. We also have not seen any formal policy of what is considered suitable for d-i, so i guess your argument is not all that useful :) Now, shall we have another 100+ flamewar about this, or are you willing to hold a constructive discussion about it ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Tue, Jun 06, 2006 at 09:23:45PM +0200, Frans Pop wrote: The more arches are built by the same person, the easier coordination is. So your offer is very welcome. Note that you'll need to check out the kernel udeb package sources from the *sarge branch* of the d-i SVN repo for the different arches as ABI numbers have to be updated there. yes, np. I'll try to have these done by this weekend. I could do i386, sparc and S/390 myself if needed, but only next week. I'm still not sure about the status of AMD64 in this update. It would be nice if AMD64 could be brought back in line with the other arches with r3. If the kernel updates cannot be released into the main archive for AMD64, we'll have to skip that arch for d-i too. I don't think its very likely that amd64/sarge will be added to debian.org, but this is a good question for the amd64.debian.net maintainers. The next point release of sarge will have a kernel ABI change which will break net install flavors of d-i. We are preparing an updated d-i to go along with this release - does the amd64.debian.net project wish to follow suit? I have an interest (job-related) in seeing amd64.debian.net track sarge point releases, so if there is a desire but lack of resources, please let me know. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Tue, Jun 06, 2006 at 09:15:44PM +0200, Frans Pop wrote: I seem to remember though that the security update was planned for the end of Debconf, so I was a bit surprised when reading my mail backlog this week that it is not out yet. That was the optimistic plan (I didn't mean to imply otherwise - at the time I knew this was risky), but working from DebConf turned out to be pretty painful (net-wise) - we only managed to actually *release* the old woody updates. However, we (Troy, Moritz and I) got 2.6.8 source mostly complete there and I babysat builds off on from a net cafe in Mexico in between trips to the beach[1] :) I finished up 2.4.27 source when I got back from vacation, then went through the build cycle for them over the next few days. There was a lag waiting for porter builds, although I've eliminated my external dependencies on porters for m68k sparc, so they should be faster next time. ... if only I had a working NIC in my SGI Octane :( What is the full status of the updates for Sarge for both 2.4 and 2.6? I submitted them last weekend from bazcamp[2], Moritz said in this thread that he plans to release them this weekend. A release using sarge2 kernels would have been logical if the kernel udebs would have been available in t-p-u earlier than was the case. With all the holidays planned after debconf the timing for the remaining work was rather unfortunate. ATM waiting for sarge3 still seems more logical. Personally, I can only go full speed on this once I get back home next week. I hope to have all the bits you need waiting for you by then. As kernel udebs are built manually it is entirely up to the person doing the build to make sure that the correct kernel version is installed on the machine used for the builds. I will plan to build with sarge3 unless someone tells me different in the next couple days. aba/zorbel? On Tuesday 06 June 2006 18:56, Martin Schulze wrote: However, if kernel udebs should be part of the security update, then we'll need proper source packages that build these udebs - or, if these already exist, a pointer which source package has been forgotton in the last kernel update rounds. No, I don't think that really makes sense as just building the kernel udebs would not get them to the users. You need to release the installer as a whole for that. Agreed. Building them with each security update would have no positive impact that I can see, unless of course the process was completely automated. [1] http://en.wikipedia.org/wiki/Zihuatanejo [2] http://bazcamp.org/ I've had a tough few weeks :) -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Tue, Jun 06, 2006 at 07:41:05PM +0200, Moritz Muehlenhoff wrote: Martin Schulze wrote: It would be good if we would be able some day to release kernel updates in a more timely fashion and also not accumulate this many security updates in one update. However, due to the number of architectures and affected packages I'm not sure this goal can be met any time soon. But that's a different story... It will be possible for Etch, the linux-2.6 kernel packages can be autobuilt, which should reduce the overhead significantly. The d-i .udeb packages remain a mess, and the out-of-tree modules need some work yet. But basically, thanks to the excellent work of the kernel team, it should be much less of an issue than it was for sarge, altough cooperation from other teams is needed to go to end of the process, cooperation that has mostly been rejected violently in the past though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
dann frazier [EMAIL PROTECTED] writes: On Tue, Jun 06, 2006 at 09:23:45PM +0200, Frans Pop wrote: The more arches are built by the same person, the easier coordination is. So your offer is very welcome. Note that you'll need to check out the kernel udeb package sources from the *sarge branch* of the d-i SVN repo for the different arches as ABI numbers have to be updated there. yes, np. I'll try to have these done by this weekend. I could do i386, sparc and S/390 myself if needed, but only next week. I'm still not sure about the status of AMD64 in this update. It would be nice if AMD64 could be brought back in line with the other arches with r3. If the kernel updates cannot be released into the main archive for AMD64, we'll have to skip that arch for d-i too. I don't think its very likely that amd64/sarge will be added to debian.org, but this is a good question for the amd64.debian.net maintainers. The next point release of sarge will have a kernel ABI change which will break net install flavors of d-i. We are preparing an updated d-i to go along with this release - does the amd64.debian.net project wish to follow suit? I have an interest (job-related) in seeing amd64.debian.net track sarge point releases, so if there is a desire but lack of resources, please let me know. Currenly we all wait for Ganneff (Joerg Jaspert) to finaly do the Sarge R2 for amd64 but aba (Andreas Barth) is close to step in as backup ftp-admin and do it himself. Hopefully with R3 we can keep up in a more timely fashion. D-I changes would be welcome and a bit of work is needed there for both sarge and etch. If possibly it would be nice to have different mirror lists for sarge and etch/sid in choose-mirror. Since you are intrested and seem to be involved in the D-I changes anyway it would be welcome if you could lead the effort for amd64 and coordinate between amd64 and D-I. For kernel changes you should best contact fs (Frederik Schueler) directly. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
Frans Pop [EMAIL PROTECTED] writes: (Removed irrelevant CCs for this question) On Wednesday 07 June 2006 10:11, Goswin von Brederlow wrote: If possibly it would be nice to have different mirror lists for sarge and etch/sid in choose-mirror. This is not really a problem. choose-mirror for Sarge will remain unchanged and thus keeps using the unofficial mirrors. For the next d-i beta release for Etch we'll make sure that the exceptions for AMD64 are removed from choose-mirror so the regular mirror lists will be used for AMD64 too (in fact, these changes are already done in the udeb currently in unstable and thus in the daily built images). Cheers, FJP I ment that when you select sarge in choose-mirror in expert mode you get the inofficial list and if you choose etch/etch+1/sid you get the official one. Might be too much work for a transient problem though. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Wed, Jun 07, 2006 at 08:42:23PM +0200, Goswin von Brederlow wrote: Frans Pop [EMAIL PROTECTED] writes: (Removed irrelevant CCs for this question) On Wednesday 07 June 2006 10:11, Goswin von Brederlow wrote: If possibly it would be nice to have different mirror lists for sarge and etch/sid in choose-mirror. This is not really a problem. choose-mirror for Sarge will remain unchanged and thus keeps using the unofficial mirrors. For the next d-i beta release for Etch we'll make sure that the exceptions for AMD64 are removed from choose-mirror so the regular mirror lists will be used for AMD64 too (in fact, these changes are already done in the udeb currently in unstable and thus in the daily built images). Cheers, FJP I ment that when you select sarge in choose-mirror in expert mode you get the inofficial list and if you choose etch/etch+1/sid you get the official one. Might be too much work for a transient problem though. I thought that installing sarge with current etch installers is broken / not supported / whatever. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
Sven Luther [EMAIL PROTECTED] writes: I ment that when you select sarge in choose-mirror in expert mode you get the inofficial list and if you choose etch/etch+1/sid you get the official one. Might be too much work for a transient problem though. I thought that installing sarge with current etch installers is broken / not supported / whatever. People readded support for it also because we have a lot of hardware support issues and in this way is easy to workaround them. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
Sven Luther [EMAIL PROTECTED] writes: On Wed, Jun 07, 2006 at 08:42:23PM +0200, Goswin von Brederlow wrote: Frans Pop [EMAIL PROTECTED] writes: (Removed irrelevant CCs for this question) On Wednesday 07 June 2006 10:11, Goswin von Brederlow wrote: If possibly it would be nice to have different mirror lists for sarge and etch/sid in choose-mirror. This is not really a problem. choose-mirror for Sarge will remain unchanged and thus keeps using the unofficial mirrors. For the next d-i beta release for Etch we'll make sure that the exceptions for AMD64 are removed from choose-mirror so the regular mirror lists will be used for AMD64 too (in fact, these changes are already done in the udeb currently in unstable and thus in the daily built images). Cheers, FJP I ment that when you select sarge in choose-mirror in expert mode you get the inofficial list and if you choose etch/etch+1/sid you get the official one. Might be too much work for a transient problem though. I thought that installing sarge with current etch installers is broken / not supported / whatever. Friendly, Sven Luther It used to work and for many amd64 users nowadays it is the only way to install a stable system due to needed hardware support in 2.6.12+ kernels. I think it would be a good idea to preserv/restore that ability and to aim to support this for etch as well. If using the testing images to install stable is not possible in the future then we should seriously consider releasing images with newer kernels in point releases or having D-I on backports.org. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Thu, Jun 08, 2006 at 12:59:42AM +0200, Goswin von Brederlow wrote: If using the testing images to install stable is not possible in the future then we should seriously consider releasing images with newer kernels in point releases or having D-I on backports.org. This is being considered was discussed a lot at debconf. See the debian-kernel archives from around that time for some discussion. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
dann frazier wrote: I saw some questions on irc about the sarge3 kernel build r3... zobel it's just, i actualy wanted to release sarge r3 with sarge2 kernels. now i get told sarge3-kernels are already prepared, which disapoints me a bit, as noone told the stable release team there will be another kernel update round for r3 :( That's rediculous. The Security Team does not have to announce their updates n days in advance to the stable release team. The Security Team instead must be able to issue security updates at any time. Thanks to the new proposed-updates barrier these updates don't even have to affect proposed-updates as they can easily be installed into proposed-updates after the next point release. It would be good if we would be able some day to release kernel updates in a more timely fashion and also not accumulate this many security updates in one update. However, due to the number of architectures and affected packages I'm not sure this goal can be met any time soon. But that's a different story... zobel and actually sarge r3 is just waiting for a new d-i, which i understand is currently waiting for kernel udebs... waldi -boot is responsible for the udebs anyway -- Not the problem of the Security Team However, if kernel udebs should be part of the security update, then we'll need proper source packages that build these udebs - or, if these already exist, a pointer which source package has been forgotton in the last kernel update rounds. During the d-i bof at DebConf I pointed out that the sarge3 kernel build is in progress and is not an ABI change - there was consensus to wait for this build before doing the d-i build for r3. I don't remember the timeline we discussed for this build. The current status is that the build is complete and pending upload by the security team (I think Moritz would be the one to do it, so I've cc'd him). Oh. Great. Good to hear (err... sending such information to [EMAIL PROTECTED] would actually be a good idea as well...) h01ger dannf, as long as u dont upload (before coordinating with zobel/srm-team) everybody is happy about your work :) 1. Uploading to the security archive should be possible without coordination with the release team. If the later is required, something is broken. 2. Thanks to the barrier between incoming and proposed-updates even the push into the main archive should not be a problem since the stable release team only has to delay acceptance of the new packages so that the older ones are not overwritten before the point release. That's one of the benefits of the new barrier. Personally, I don't care which kernel gets used - that's a stable-release/d-i decision in my opinion. However, I do not think we Ack. should delay the release of the sarge3 kernel to security.debian.org - Ack. I want to avoid any situation that would prevent us from doing timely security updates. Ack. If you decide to stick with sarge2 for r3, would an upload of sarge3 to security.debian.org break this? As I understand it, sarge2 is already It shouldn't be able to. Regards, Joey -- Every use of Linux is a proper use of Linux. -- Jon 'maddog' Hall Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Tue, Jun 06, 2006 at 06:56:33PM +0200, Martin Schulze wrote: However, if kernel udebs should be part of the security update, then we'll need proper source packages that build these udebs - or, if these already exist, a pointer which source package has been forgotton in the last kernel update rounds. I've offered to perform these builds for all archs except mips, mipsel m68k (but I can help coordinate those as well - those arch maintainers have always been very responsive to my build requests). This offer is still open, just let me know if they should be against sarge2 or sarge3. I suspect I could turn this around in a day or two (if its the right day or two). Oh. Great. Good to hear (err... sending such information to [EMAIL PROTECTED] would actually be a good idea as well...) ok -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build r3
On Tuesday 06 June 2006 18:01, dann frazier wrote: I believed aba, joeyh fjp were all in on this decision, but apologies if it didn't get communicated back to everyone involved. That's right, aba agreed to this plan as representative of the stable release team. Also, I posted an update about this in [1]. I also posted proposed patches needed for d-i itself in that mail. I seem to remember though that the security update was planned for the end of Debconf, so I was a bit surprised when reading my mail backlog this week that it is not out yet. What is the full status of the updates for Sarge for both 2.4 and 2.6? A release using sarge2 kernels would have been logical if the kernel udebs would have been available in t-p-u earlier than was the case. With all the holidays planned after debconf the timing for the remaining work was rather unfortunate. ATM waiting for sarge3 still seems more logical. Personally, I can only go full speed on this once I get back home next week. Personally, I don't care which kernel gets used - that's a stable-release/d-i decision in my opinion. However, I do not think we should delay the release of the sarge3 kernel to security.debian.org - I want to avoid any situation that would prevent us from doing timely security updates. If you decide to stick with sarge2 for r3, would an upload of sarge3 to security.debian.org break this? As I understand it, sarge2 is already in the queue archive for stable, so those bits would still be available? As kernel udebs are built manually it is entirely up to the person doing the build to make sure that the correct kernel version is installed on the machine used for the builds. On Tuesday 06 June 2006 18:56, Martin Schulze wrote: However, if kernel udebs should be part of the security update, then we'll need proper source packages that build these udebs - or, if these already exist, a pointer which source package has been forgotton in the last kernel update rounds. No, I don't think that really makes sense as just building the kernel udebs would not get them to the users. You need to release the installer as a whole for that. Cheers, FJP [1] [EMAIL PROTECTED] pgpWbtvJipT3T.pgp Description: PGP signature
Re: sarge3 kernel build r3
On Tuesday 06 June 2006 19:22, dann frazier wrote: I've offered to perform these builds for all archs except mips, mipsel m68k (but I can help coordinate those as well - those arch maintainers have always been very responsive to my build requests). This offer is still open, just let me know if they should be against sarge2 or sarge3. I suspect I could turn this around in a day or two (if its the right day or two). The more arches are built by the same person, the easier coordination is. So your offer is very welcome. Note that you'll need to check out the kernel udeb package sources from the *sarge branch* of the d-i SVN repo for the different arches as ABI numbers have to be updated there. I could do i386, sparc and S/390 myself if needed, but only next week. I'm still not sure about the status of AMD64 in this update. It would be nice if AMD64 could be brought back in line with the other arches with r3. If the kernel updates cannot be released into the main archive for AMD64, we'll have to skip that arch for d-i too. Cheers, FJP pgpHPCPQUUFY2.pgp Description: PGP signature
Re: sarge3 kernel build r3
On Tuesday 06 June 2006 21:32, dann frazier wrote: I don't think its very likely that amd64/sarge will be added to debian.org, I did not mean to imply that of course. but this is a good question for the amd64.debian.net maintainers. The main reason we need to know is that the d-i source needs to be updated for the ABI change and so we need to know if this update should happen for AMD64 as well as for the other arches *before* we _upload_ it. Also, from a CD building point of view amd64 is the same as other arches, even if its packages reside on a different mirror. CDs for amd64 are normally built at the same time as other arches and it would be nice if they could follow the same timeline as the main archive. If need be, the _build_ of the new installer images and the build of CDs for AMD64 could be delayed, but preferably not. pgpjR3FVWhtyT.pgp Description: PGP signature
Re: sarge3 kernel build r3
Martin Schulze wrote: It would be good if we would be able some day to release kernel updates in a more timely fashion and also not accumulate this many security updates in one update. However, due to the number of architectures and affected packages I'm not sure this goal can be met any time soon. But that's a different story... It will be possible for Etch, the linux-2.6 kernel packages can be autobuilt, which should reduce the overhead significantly. During the d-i bof at DebConf I pointed out that the sarge3 kernel build is in progress and is not an ABI change - there was consensus to wait for this build before doing the d-i build for r3. I don't remember the timeline we discussed for this build. The current status is that the build is complete and pending upload by the security team (I think Moritz would be the one to do it, so I've cc'd him). Oh. Great. Good to hear (err... sending such information to [EMAIL PROTECTED] would actually be a good idea as well...) I'm pretty sure I kept you posted. I dropped a note when I pushed out the Woody updates, but it was probably too terse. Sorry for that, I've been very busy over the last months. I'll process the 2.4.27 and 2.6.8 packages on the weekend. Wrt the ABI bump: At DebConf Dann and I agreed to omit one kernel security issue: A hard-too-trigger denial of service vulnerability in the experimental SCTP code. As there will most definitely be another ABI breaker soon, it wasn't worth all the work to cope with an ABI change. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
