Re: D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)
On Tuesday 05 February 2008, dann frazier wrote: On Mon, Feb 04, 2008 at 01:53:43AM +0100, Frans Pop wrote: Finally I created the etch-support udeb which does two things: 1) add an early base-installer hook script that sets the 'altmeta' template 2) add an partman init.d hook script that changes the default inode_size from 256 to 128 (only for i386 and amd64) [2] Is it known whether or not bootloaders on other archs (the etch versions, in particular) are affected by this change? I'm wondering if we shouldn't change the etch default to 128, except for archs with etch bootloaders that are known to support 256. As you may have seen on the d-boot list I have changed this in the final version after a discussion with Ted Ts'o. I now include a complete replacement of the mke2fs.conf file that has the same defaults as current Etch. Besides the reverted inode_size default this also reverts the addition of the ext_attr feature. There are still things to decide, and IMO consensus on this should be reached soon! - The naming of the etch+1/2 kernel meta packages is now suddenly essential for the installer and should thus be decided on ASAP. We talked about this on #debian-kernel last week, and linux-image-2.6-$flavor-etchnhalf had no objections. OK. It's now hardcoded in D-I, so no chance to change your mind anymore :-) signature.asc Description: This is a digitally signed message part.
Re: Beta1 missing decisions and possible timeline
On Sun, Feb 03, 2008 at 05:23:14PM -0200, Otavio Salvador wrote: As suggested by Frans, with many good points, we'll release with 2.6.22 but just after it, we'll start to work to release another beta with 2.6.24 kernel. This should allow us to install a etchnhalf 2.6.24 on hardware supported by 2.6.22, and then the follow-on beta would add support for the remaining hardware (that supported by 2.6.24 but not 2.6.22). Unless someone sees a problem with this, it seems fine to me. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)
On Mon, Feb 04, 2008 at 01:53:43AM +0100, Frans Pop wrote: Finally I created the etch-support udeb which does two things: 1) add an early base-installer hook script that sets the 'altmeta' template 2) add an partman init.d hook script that changes the default inode_size from 256 to 128 (only for i386 and amd64) [2] Is it known whether or not bootloaders on other archs (the etch versions, in particular) are affected by this change? I'm wondering if we shouldn't change the etch default to 128, except for archs with etch bootloaders that are known to support 256. The result of 1) is IMO exactly what we want: - the installer will automagically prefer the Etch+1/2 kernel [4] (preseeding of the exact image as mentioned in [1] is /not/ needed) that's a significant improvement, imo - the installer will also install the etch+1/2 kernel meta package, which ensures users will automatically get ABI-changing security updates - if for some reason the etchnhalf kernels are not available, the installer will fall back to the 2.6.18 kernels - all this only happens if the Lenny installer is used and thus installs using the regular (updated) Etch installer are not changed at all which is critical.. There are still things to decide, and IMO consensus on this should be reached soon! - The naming of the etch+1/2 kernel meta packages is now suddenly essential for the installer and should thus be decided on ASAP. We talked about this on #debian-kernel last week, and linux-image-2.6-$flavor-etchnhalf had no objections. - There has as yet been no discussion about exactly which Etch + Lenny D-I CD images to create and exactly what should be included on them [3]. (Hell, the whole Etch + Lenny D-I concept hasn't even really been OKed.) Because of mirror space issues _and_ because of required preparations on the debian-cd side this _really_ needs to be discussed with Sledge urgently. I'll reply to this on debian-cd only -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
* dann frazier [EMAIL PROTECTED] [2008-02-05 01:13]: On Sun, Feb 03, 2008 at 05:23:14PM -0200, Otavio Salvador wrote: As suggested by Frans, with many good points, we'll release with 2.6.22 but just after it, we'll start to work to release another beta with 2.6.24 kernel. This should allow us to install a etchnhalf 2.6.24 on hardware supported by 2.6.22, and then the follow-on beta would add support for the remaining hardware (that supported by 2.6.24 but not 2.6.22). Unless someone sees a problem with this, it seems fine to me. I think it's a good idea to do beta releases more regularly and it definitely makes sense to base the next beta on the 2.6.24 release which will also be used for etchnhalf. At the same time, I'm a bit unhappy because 2.6.25 will finally have support for the Orion (ARM) platform which I'd like to support in d-i soon, and putting out a beta based on 2.6.24 will delay Orion support quite a bit. Given we're doing a beta based on 2.6.22 now, how quickly could we get another beta based on 2.6.24 out? Can you be done relatively quickly after the beta based on 2.6.22? Another solution would be to backport Orion support from 2.6.25 to 2.6.24. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
Martin Michlmayr [EMAIL PROTECTED] writes: Given we're doing a beta based on 2.6.22 now, how quickly could we get another beta based on 2.6.24 out? Can you be done relatively quickly after the beta based on 2.6.22? I guess we can. d-i itself isn't receiving deeply changes latelly (except latest Frans partman improvements but that has been very well test by him, as usual) and other minor things. I guess we could do another in begin of April or so, dunno for sure. Another solution would be to backport Orion support from 2.6.25 to 2.6.24. Do you know how difficult would be to do that? -- 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://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
On Monday 04 February 2008, Frans Pop wrote: You've probably seen that a new grub has been uploaded, which should solve this issue for unstable and etch^Wlenny. However, there are also plans to use the Lenny Beta release of the installer for Etch+1/2 installations: installs of Etch, but with a newer kernel (either 2.6.22 or 2.6.24). As I don't expect the etch version of grub will be changed to support 256 byte inodes, we need to solve this in the installer. For the record, here are the most relevant parts of an IRC conversation I've just had with Ted Ts'o on this (copied with permission). The resulting change for the etch-support udeb has already been committed. [tytso] It would be nice to get the 256 byte inodes support sooner rather than later because it means significantly better performance for SELinux and Samba, plus the ext4 forwards compatibility. [tytso] But if the new grub isn't going to make the etch point release, I guess we don't have a choice. [fjp] Are other arches known safe, or is it basically unknown whether there are any issues with 256 support? [tytso] It probably makes sense to use the same default inode size for the root filesystem for all architectures, I agree. [tytso] To be honest, I'm not sure if there are issues for the other architectures. [tytso] We uncovered the grub issue on Fedora, since FC9 is going to ship with ext4 support, if all goes well. [fjp] OK. Then the only real option is to be conservative. [tytso] Yes, I agree that conservative is the better choice here. [fjp] What about the sed command I use to change the default? Should that be safe for the next 6 months or so? [fjp] sed -ir s/(inode_size =) 256/\1 128/ /etc/mke2fs.conf [tytso] you'd want to change that before the lenny D-I beta to add ext4 support. [tytso] But for the etch + 0.5 D-I release, I assume once you snapshot the e2fsprogs.udeb, it wouldn't change from that point on, right? [fjp] Well, some installation methods pull the udeb from lenny mirrors at install time. [tytso] Hmm. [fjp] So I'd like to be safe against future changes in defaults in unstable/testing too. [tytso] Well, in the next 2 months we will be adding ext4 support to e2fsprogs. But if you make that a global search and replace, and not just replace the first instance of inode_size=256, it should be OK for the etch D-I. [fjp] I could also just snapshot the whole conf file and just replace it. [tytso] that would be safer. [fjp] OK. Will do. signature.asc Description: This is a digitally signed message part.
Re: Beta1 missing decisions and possible timeline
* Otavio Salvador [EMAIL PROTECTED] [2008-02-05 16:43]: d-i itself isn't receiving deeply changes latelly (except latest Frans partman improvements but that has been very well test by him, as usual) and other minor things. I guess we could do another in begin of April or so, dunno for sure. I think it would be good to make the 2.6.24 based release soon after the one based on 2.6.22; beginning of April sounds fine. Another solution would be to backport Orion support from 2.6.25 to 2.6.24. Do you know how difficult would be to do that? Shouldn't be too hard but I haven't looked into it yet. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
On Sunday 03 February 2008, Otavio Salvador wrote: Also note that I have _never_ intended the massbuild script to be used for mass uploads when switching to a new kernel minor version [1]. I still feel that porters should be responsible for checking their configurations and included modules when switching from one upstream kernel release to the next, and that goes double when we are skipping a version. If you want to change that policy, that's fine. But in that case that policy change should first be discussed and agreed with the porters. Right. I wasn't going to change architecture specific packages but going to update kernel-wedge recipes only. OK. It would be nice if people say if they prefer to me to do a first look on the modules and then porters review it again or prefer to do it themselfs. The procedure in the past (as I saw it at least) was: - Joey would check for changes in x86, thereby also catching most/all general changes and make changes necessary for that. After making sure x86 built, kernel-wedge would just be uploaded (and x86 udebs too). - Then he or I would request porters to do their own arches. In some cases that would require extra changes in kernel-wedge, which would either be done by the porter himself, or with help from (mostly) Joey. - Additional kernel-wedge uploads would be done as needed. Note that for some arches there has not been a great involvement from porters and I've done the last updates for sparc, hppa and s390 myself. Which was possible as those are relatively stable arches, sometimes with some help on IRC from porters. This is completely impossible, especially for packages that also produce regular debs. You are forgetting time needed to build, test and age new uploads. Do you really expect packages to be built for all arches within one day? After mips problem was fix, this happened but I agree I could give a bigger slot of time to be able to deal with problems and exceptions. Will update it. AFAICT it's not really fixed. Both architectures still run on only one buildd and that can barely keep up. Both still have a huge backlog of 500+ packages. signature.asc Description: This is a digitally signed message part.
Re: D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)
Quoting Frans Pop ([EMAIL PROTECTED]): Sorry for the long explanation below, but I really want people to understand what is happening and why so we are agreed on this implementation and don't have nasty surprises after the point release. Your mail (which I read carefully) requires ACK from several people. You maybe want to target these people specifically with specific questions, in order to be sure to get the quick answers you need. Apart from that minor suggestion, kudos for that work. I'm pretty much ignorant with the involved issues and therefore won't care commenting in the details but, as often, I'm impressed..:-) signature.asc Description: Digital signature
Re: Beta1 missing decisions and possible timeline
Kartik Mistry [EMAIL PROTECTED] writes: On Feb 4, 2008 12:53 AM, Otavio Salvador [EMAIL PROTECTED] wrote: With all comments that has been sent to this thread, I've changed the timeline to the following: snip +--+---+ |March 3, 2007 |planned release date | +--+---+ Please ack this timeline and comment on it. I guess we're ok now. You mean 2008 :) Indeed! -- 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://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
Frans Pop [EMAIL PROTECTED] writes: Before begin to answer, I want to say that I agree with you and will follow your advice of do a 2.6.22 based release and prepare a beta2 changing the kernel just after beta1 release. On Thursday 31 January 2008, Otavio Salvador wrote: - kernel to release We have 2.6.22 as a safe bed on lenny now and their udebs are there too however since EtchAndHalf intends to release with 2.6.24 and it has been uploaded to sid already I'm considering a better option to us to release with it. It it _way_ too early to switch to 2.6.24: - experience has shown that the first new upstream kernel release always has important issues and, looking at lkml, this one is no exception; for D-I to switch, _especially_ for a release, normally requires at least a .2 or .3 upstream release Yes, sure. But we could redo massbuilds once new kernels were upload. - even if upstream was perfect, you still have initial Debian packaging issues that will need to be sorted out - switching to 2.6.24 only for unstable is not a good idea because, as long as there has not been a D-I upload, we don't have any working builds from testing, so effectively _all_ our images would be switched to 2.6.24, which is not good for release testing - with your current schedule we'd have not nearly enough testing of D-I with 2.6.24 Agreed. You would give us problem to work with a safe bed. linux-2.6 has been built in all architectures and linux-modules-extra-2.6 has been fastly processed (thanks ftpmasters) and then we could manage to get a massbuild done in few days (+- 5 of febuary or even before). I've started to check the new modules and prepare the patches for kernel-wedge for it and hope to get it ready for tomorrow or so. Did you discuss with Joey whether he wanted to do that or not? Joey of course has huge experience with doing that. I did it last time and coordinated the changes with Joey before commiting. Also note that I have _never_ intended the massbuild script to be used for mass uploads when switching to a new kernel minor version [1]. I still feel that porters should be responsible for checking their configurations and included modules when switching from one upstream kernel release to the next, and that goes double when we are skipping a version. If you want to change that policy, that's fine. But in that case that policy change should first be discussed and agreed with the porters. Right. I wasn't going to change architecture specific packages but going to update kernel-wedge recipes only. It would be nice if people say if they prefer to me to do a first look on the modules and then porters review it again or prefer to do it themselfs. My conclusion is that unless you are willing to significantly delay the Beta release, I don't see any way you can do the release with 2.6.24. I would suggest to do the release with 2.6.22 and keep the option to do a quick new release based on 2.6.24. Right. I agree with you conclusion. Talking with Dann, I realised that Etch 1/2 isn't going to be release before mid march or so, giving us time for it. Besides that, I think I was wrongly mixing both releases. While they're more or less related I still think I were wrong to change the kernel so near of the release. Ack! - e2fsprogs inode size change Lastest release[1] changed the default inode size to 256 bytes. This is not yet on lenny but is already available on sid and will hit lenny in few days. 1. http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.5 Currently, there's a know problem with GRUB[2] and the safest solution is to change the current inode size back to 128 bytes using -I option of mke2fs for Beta1 release and then work on GRUB or GRUB2 to support it for lenny Beta2 release with 256 bytes again. 2. http://bugs.debian.org/463236 What about the option to just apply the recent patch from Stefan Lippers-Hollmann to grub and go with that? I very much disliked the reaction from Robert basically saying that the patch would not even be considered because grub was dead. AFAIK, grub is still very much the major bootloader for x86 and issues such as this definitely should be resolved. Yes, Robert will handle it for us. I understand and share the feeling that GRUB is in legacy mode for Debian but I also think this is a important change and, if the patch gives no know problems, it could be considered and then we could allow it to go in as an exception. |2/15/2007|mass upload of translation updates | [...] |2/16/2007|mass migration of udebs| This is completely impossible, especially for packages that also produce regular debs. You are forgetting time needed to build, test and age new uploads. Do you really expect packages to be built for all arches within one day? After mips problem was fix, this happened but I
Re: Beta1 missing decisions and possible timeline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With all comments that has been sent to this thread, I've changed the timeline to the following: +--+---+ | Date | What happens | +--+---+ |February 5, 2007 |translation update request is send | +--+---+ |February 15, 2007 |mass upload of translation updates | +--+---+ |February 15, 2007 |kernel, modules and their udebs hitted testing | +--+---+ |February 18, 2007 |mass migration of udebs| +--+---+ |February 19, 2007 |debian-installer is uploaded | +--+---+ |February 21, 2007 |daily images are changed to use lenny installer| +--+---+ |February 23, 2007 |test of images starts | +--+---+ |March 1, 2007 |final image builds | +--+---+ |March 3, 2007 |planned release date | +--+---+ As suggested by Frans, with many good points, we'll release with 2.6.22 but just after it, we'll start to work to release another beta with 2.6.24 kernel. Please ack this timeline and comment on it. I guess we're ok now. - -- 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://otavio.ossystems.com.br - - Microsoft sells you Windows ... Linux gives you the whole house. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFHphSaLqiZQEml+FURArq2AKCs3tjiR8wrW/sCqDwO0yZeD0KL2ACgnzLL Mv/ksAJ5bfSmDhGDw/vnJL4= =OI02 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
On Sunday 03 February 2008, Otavio Salvador wrote: - e2fsprogs inode size change Lastest release[1] changed the default inode size to 256 bytes. This is not yet on lenny but is already available on sid and will hit lenny in few days. 1. http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.5 Currently, there's a know problem with GRUB[2] and the safest solution is to change the current inode size back to 128 bytes using -I option of mke2fs for Beta1 release and then work on GRUB or GRUB2 to support it for lenny Beta2 release with 256 bytes again. 2. http://bugs.debian.org/463236 What about the option to just apply the recent patch from Stefan Lippers-Hollmann to grub and go with that? I very much disliked the reaction from Robert basically saying that the patch would not even be considered because grub was dead. AFAIK, grub is still very much the major bootloader for x86 and issues such as this definitely should be resolved. Yes, Robert will handle it for us. Great. BTW. I guess this change is also going to break stable installs if we use the Lenny installer for Etch+1/2... I guess we'll have to hack things so that for Etch installs partitions will be created with a 128 byte inode size. I'll see what I can do about that. signature.asc Description: This is a digitally signed message part.
Re: Beta1 missing decisions and possible timeline
Frans Pop [EMAIL PROTECTED] writes: On Sunday 03 February 2008, Otavio Salvador wrote: - e2fsprogs inode size change Lastest release[1] changed the default inode size to 256 bytes. This is not yet on lenny but is already available on sid and will hit lenny in few days. 1. http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.5 Currently, there's a know problem with GRUB[2] and the safest solution is to change the current inode size back to 128 bytes using -I option of mke2fs for Beta1 release and then work on GRUB or GRUB2 to support it for lenny Beta2 release with 256 bytes again. 2. http://bugs.debian.org/463236 What about the option to just apply the recent patch from Stefan Lippers-Hollmann to grub and go with that? I very much disliked the reaction from Robert basically saying that the patch would not even be considered because grub was dead. AFAIK, grub is still very much the major bootloader for x86 and issues such as this definitely should be resolved. Yes, Robert will handle it for us. Great. BTW. I guess this change is also going to break stable installs if we use the Lenny installer for Etch+1/2... I guess we'll have to hack things so that for Etch installs partitions will be created with a 128 byte inode size. I'll see what I can do about that. Yes, we'll need to. It would be interesting if partman could read something like /etc/defaults/e2fsprogs and like so we could provide etch-support udeb with this and any other specific thing we need. What do you think? -- 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://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
D-I Etch+1/2 kernel selection (was: Beta1 missing decisions and possible timeline)
On Sunday 03 February 2008, Frans Pop wrote: I have been quite disappointed that there was no real follow-up to my mails, which now leaves us in the situation that there is basically no support yet to select the correct kernel for etch+1/2. Being the sucker that I am, I did start to look into this after venting my frustration in the previous mail. I've looked at several options and initially the conclusion was that supporting selection for the etch+1/2 kernel was far from trivial and very likely to be messy. However, after some false starts that were all way to complex, failure prone and ugly, I decided to drag out an old invention: the etch-support udeb. Sorry for the long explanation below, but I really want people to understand what is happening and why so we are agreed on this implementation and don't have nasty surprises after the point release. The required patches for the installer are attached. I have successfully tested them using a custom built netinst CD that had both the 2.6.18 and 2.6.22-686 kernels on it. Because of changes in the installation procedure since I implemented the sarge-support udeb, I first needed to ensure installation of the etch-support udeb is queued in cdrom-detect and iso-scan. With that, we will have the following situation: - cdrom-detect: queues etch-support for netinst and full CDs - iso-scan: queues etch-support for hd-media - choose-mirror: queues etch-support for netboot/floppy-net/businesscard CD The trick in this is that the udeb will be automatically installed _only_ if etch is being installed _and_ the lenny installer is being used. This is the case if: - the user is using an Etch netinst or full CD that has the Lenny installer on it (this is option 4 from [1]) - the user uses a netboot image or businesscard CD and boots the installer with 'suite=etch' or 'suite=stable', or (at medium/low prio) selects stable (this is option 3 from [1]) I then added a hack in base-installer which does the following. If the (new) debconf template base-installer/kernel/altmeta has a value (e.g. 'etchnhalf'), it will add new potential kernel defaults before the the normal kernel defaults, with that value postfixed. I.e, if the normal possible defaults are: linux-image-2.6-686 linux-image-2.6-486 this now becomes: linux-image-2.6-686-etchnhalf linux-image-2.6-486-etchnhalf linux-image-2.6-686 linux-image-2.6-486 Finally I created the etch-support udeb which does two things: 1) add an early base-installer hook script that sets the 'altmeta' template 2) add an partman init.d hook script that changes the default inode_size from 256 to 128 (only for i386 and amd64) [2] The result of 1) is IMO exactly what we want: - the installer will automagically prefer the Etch+1/2 kernel [4] (preseeding of the exact image as mentioned in [1] is /not/ needed) - the installer will also prefer the correct flavor (which was the main issue with my earlier attempts) - the installer will also install the etch+1/2 kernel meta package, which ensures users will automatically get ABI-changing security updates - if for some reason the etchnhalf kernels are not available, the installer will fall back to the 2.6.18 kernels - all this only happens if the Lenny installer is used and thus installs using the regular (updated) Etch installer are not changed at all There is one issue, which I will detail in a follow-up mail to debian-boot only. The short summary is that for arm the etchnhalf kernel meta packages are currently not considered installable, so as things stand now the above would not work for arm. There are still things to decide, and IMO consensus on this should be reached soon! - The naming of the etch+1/2 kernel meta packages is now suddenly essential for the installer and should thus be decided on ASAP. - There has as yet been no discussion about exactly which Etch + Lenny D-I CD images to create and exactly what should be included on them [3]. (Hell, the whole Etch + Lenny D-I concept hasn't even really been OKed.) Because of mirror space issues _and_ because of required preparations on the debian-cd side this _really_ needs to be discussed with Sledge urgently. - The changes in the installer need to be implemented and uploaded, preferably before the upcoming Beta release, i.e. *very quickly*. One final remark. Because of the use of the Lenny installer, the installation procedure will be slightly different (improved!) from the Etch installer. Most relevant changes: - automatic hardware clock update from NTP server - by default addition of volatile.d.o besides security.d.o - slightly changed installation order - support for installation from multiple CDs from CD/DVD sets - more targeted prompts for whether or not to use a mirror - various cleanups and fixes, especially in partman - some preseeding changes (users should consult the Lenny installation guide for preseeding!) Cheers, FJP [1]
Re: Beta1 missing decisions and possible timeline
Hello Ted, On Wed, 30 Jan 2008 08:00:20 -0500, Ted Tso wrote: If the grub maintainers can't figure out a way to break up the monolithic patch quickly, or to get it incorporated into Debian, or get it upstreamed ASAP, one of the things that I could do is change mke2fs.conf in the udeb file, so that it doesn't impact the Debian installer. Or better yet, the Anaconda could be hacked so that -I Please do not insult D-I by calling it Anaconda ;-) 128 is passed to mke2fs just for the root filesystem, and not for others. You've probably seen that a new grub has been uploaded, which should solve this issue for unstable and etch. However, there are also plans to use the Lenny Beta release of the installer for Etch+1/2 installations: installs of Etch, but with a newer kernel (either 2.6.22 or 2.6.24). As I don't expect the etch version of grub will be changed to support 256 byte inodes, we need to solve this in the installer. I already have a patch for this (and tested that it works), but would appreciate your confirmation on the solution. Note that this fix will not affect installs of lenny or sid. Is it correct that _only_ grub and thus only i386 and amd64 are affected? Or phrased differently, is it enough to only change the default back to 128 for i386 and amd64, or should we also do that for other arches (even if just to be on the safe side)? The fix I have is ATM to execute the following command (in the D-I environment) before the start of partitioning: sed -ir s/(inode_size =) 256/\1 128/ /etc/mke2fs.conf This works with the current conf file, but if needed I could make that a bit more generic, for example: sed -ir s/(inode_size =) .*/\1 128/g /etc/mke2fs.conf What do you think? In general, could you please keep the debian-boot list (or maybe even just d-d-a) informed if any other changes are planned that could affect people? Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#463123: Info received (Beta1 missing decisions and possible timeline)
Thank you for the additional information you have supplied regarding this problem report. It has been forwarded to the package maintainer(s) and to other interested parties to accompany the original report. Your message has been sent to the package maintainer(s): [EMAIL PROTECTED] (Theodore Y. Ts'o) If you wish to continue to submit further information on this problem, please send it to [EMAIL PROTECTED], as before. Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Beta1 missing decisions and possible timeline
Frans Pop [EMAIL PROTECTED] writes: ... You've probably seen that a new grub has been uploaded, which should solve this issue for unstable and etch. Lenny ... -- 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://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
On Feb 4, 2008 12:53 AM, Otavio Salvador [EMAIL PROTECTED] wrote: With all comments that has been sent to this thread, I've changed the timeline to the following: snip +--+---+ |March 3, 2007 |planned release date | +--+---+ Please ack this timeline and comment on it. I guess we're ok now. You mean 2008 :) -- Cheers, Kartik Mistry | 0xD1028C8D | IRC: kart_ blog.ftbfs.in | kartikm.wordpress.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
On Fri, Feb 01, 2008 at 09:51:07PM -0500, Joey Hess wrote: It's far to early to switch d-i to 2.6.24, especially since it drops support for most of /proc/acpi, including the parts used by laptop-detect. I suspect you already know this, but for the record, that's not an intrinsic property of 2.6.24; enabling CONFIG_ACPI_PROCFS_POWER again will restore compatibility. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
Joey Hess [EMAIL PROTECTED] writes: Otavio Salvador wrote: We have 2.6.22 as a safe bed on lenny now and their udebs are there too however since EtchAndHalf intends to release with 2.6.24 and it has been uploaded to sid already I'm considering a better option to us to release with it. linux-2.6 has been built in all architectures and linux-modules-extra-2.6 has been fastly processed (thanks ftpmasters) and then we could manage to get a massbuild done in few days (+- 5 of febuary or even before). I've started to check the new modules and prepare the patches for kernel-wedge for it and hope to get it ready for tomorrow or so. It's far to early to switch d-i to 2.6.24, especially since it drops support for most of /proc/acpi, including the parts used by laptop-detect. I've uploaded laptop-detect with this fixed (using your provided patch) so it is solved on sid now. -- 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://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
Hi, On Fri, Feb 01, 2008 at 09:51:07PM -0500, Joey Hess wrote: It's far to early to switch d-i to 2.6.24, especially since it drops support for most of /proc/acpi, including the parts used by laptop-detect. I still think this switch was an extremely premature and really, really bad idea. We need either to turn the acpi proc interface back on before .24 migrates to testing, or we track a .24 with this change outside of the archive, which is a no go for me. So, let's reenable CONFIG_ACPI_PROCFS_POWER, please. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Beta1 missing decisions and possible timeline
On Saturday 02 February 2008, Otavio Salvador wrote: It's far to early to switch d-i to 2.6.24, especially since it drops support for most of /proc/acpi, including the parts used by laptop-detect. I've uploaded laptop-detect with this fixed (using your provided patch) so it is solved on sid now. That change is still going to break installations if D-I with 2.6.24 is going to be used for Etch+1/2. signature.asc Description: This is a digitally signed message part.
Re: Beta1 missing decisions and possible timeline
On Thursday 31 January 2008, Otavio Salvador wrote: - kernel to release We have 2.6.22 as a safe bed on lenny now and their udebs are there too however since EtchAndHalf intends to release with 2.6.24 and it has been uploaded to sid already I'm considering a better option to us to release with it. It it _way_ too early to switch to 2.6.24: - experience has shown that the first new upstream kernel release always has important issues and, looking at lkml, this one is no exception; for D-I to switch, _especially_ for a release, normally requires at least a .2 or .3 upstream release - even if upstream was perfect, you still have initial Debian packaging issues that will need to be sorted out - switching to 2.6.24 only for unstable is not a good idea because, as long as there has not been a D-I upload, we don't have any working builds from testing, so effectively _all_ our images would be switched to 2.6.24, which is not good for release testing - with your current schedule we'd have not nearly enough testing of D-I with 2.6.24 linux-2.6 has been built in all architectures and linux-modules-extra-2.6 has been fastly processed (thanks ftpmasters) and then we could manage to get a massbuild done in few days (+- 5 of febuary or even before). I've started to check the new modules and prepare the patches for kernel-wedge for it and hope to get it ready for tomorrow or so. Did you discuss with Joey whether he wanted to do that or not? Joey of course has huge experience with doing that. Also note that I have _never_ intended the massbuild script to be used for mass uploads when switching to a new kernel minor version [1]. I still feel that porters should be responsible for checking their configurations and included modules when switching from one upstream kernel release to the next, and that goes double when we are skipping a version. If you want to change that policy, that's fine. But in that case that policy change should first be discussed and agreed with the porters. My conclusion is that unless you are willing to significantly delay the Beta release, I don't see any way you can do the release with 2.6.24. I would suggest to do the release with 2.6.22 and keep the option to do a quick new release based on 2.6.24. - e2fsprogs inode size change Lastest release[1] changed the default inode size to 256 bytes. This is not yet on lenny but is already available on sid and will hit lenny in few days. 1. http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.5 Currently, there's a know problem with GRUB[2] and the safest solution is to change the current inode size back to 128 bytes using -I option of mke2fs for Beta1 release and then work on GRUB or GRUB2 to support it for lenny Beta2 release with 256 bytes again. 2. http://bugs.debian.org/463236 What about the option to just apply the recent patch from Stefan Lippers-Hollmann to grub and go with that? I very much disliked the reaction from Robert basically saying that the patch would not even be considered because grub was dead. AFAIK, grub is still very much the major bootloader for x86 and issues such as this definitely should be resolved. |2/15/2007|mass upload of translation updates | [...] |2/16/2007|mass migration of udebs| This is completely impossible, especially for packages that also produce regular debs. You are forgetting time needed to build, test and age new uploads. Do you really expect packages to be built for all arches within one day? Cheers, FJP [1] http://lists.debian.org/debian-boot/2006/08/msg00631.html http://lists.debian.org/debian-boot/2006/09/msg00660.html [2] http://lists.debian.org/debian-boot/2008/01/msg00830.html signature.asc Description: This is a digitally signed message part.
Re: Beta1 missing decisions and possible timeline
On Friday 01 February 2008, dann frazier wrote: Is there anything special we need to add to deal with etch 1/2 kernel metapackages? We were talking about using a name like linux-image-2.6-686-etchnhalf. As I explained in my mails re etch+1/2 some time back [1] , D-I simply will not install the correct kernel unless either: - the user installs at medium/low priority and selects the correct kernel - the user preseeds the exact kernel version at the boot prompt (the addition of an alias as discussed back then to make that easier has _not_ yet been implemented) [2] - something is changed in base-installer to make it select the updated kernel automatically Having metapackages with whatever name changes nothing in those facts. I have been quite disappointed that there was no real follow-up to my mails, which now leaves us in the situation that there is basically no support yet to select the correct kernel for etch+1/2. If the metapackages will be limited to Etch (i.e. only purpose is to allow easy updates in case of ABI-changing security updates), I have no real objection to naming them etchnhalf, although I think it is a disastrous option for people who may have to type it at the command line. Cheers, FJP [1] http://lists.debian.org/debian-boot/2007/12/msg00234.html + thread [2] Note that adding the preseeding on the CD is _not_ going to work as that does not allow selecting a correct kernel flavor. signature.asc Description: This is a digitally signed message part.
Re: Beta1 missing decisions and possible timeline
Quoting Frans Pop ([EMAIL PROTECTED]): My conclusion is that unless you are willing to significantly delay the Beta release, I don't see any way you can do the release with 2.6.24. I would suggest to do the release with 2.6.22 and keep the option to do a quick new release based on 2.6.24. I second this. Most arguments have been given by others and my last argument has been seeing my battery status icon disappear when I switched to 2.6.24 yesterday. So, I support a beta1 now with 2.6.22 and, hopefully, a beta2 in March or April with 2.6.24 (and very few other changes). signature.asc Description: Digital signature
Re: Beta1 missing decisions and possible timeline
Otavio Salvador wrote: We have 2.6.22 as a safe bed on lenny now and their udebs are there too however since EtchAndHalf intends to release with 2.6.24 and it has been uploaded to sid already I'm considering a better option to us to release with it. linux-2.6 has been built in all architectures and linux-modules-extra-2.6 has been fastly processed (thanks ftpmasters) and then we could manage to get a massbuild done in few days (+- 5 of febuary or even before). I've started to check the new modules and prepare the patches for kernel-wedge for it and hope to get it ready for tomorrow or so. It's far to early to switch d-i to 2.6.24, especially since it drops support for most of /proc/acpi, including the parts used by laptop-detect. -- see shy jo signature.asc Description: Digital signature
Beta1 missing decisions and possible timeline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [ Reply-To adjusted to debian-boot so we can keep this discussion in a single mailing list ] Hello folks, I've been working at migrations of packages for lenny and I think we're more or less fine to define a timeline to the end of Febuary for the release of Beta1. This is going to be my first release as d-i RM and so I'm a bit nervous and doing small mistakes (as everybody has probably noticed already). There're few open questions that I'd like to discuss here before we make it: - kernel to release We have 2.6.22 as a safe bed on lenny now and their udebs are there too however since EtchAndHalf intends to release with 2.6.24 and it has been uploaded to sid already I'm considering a better option to us to release with it. linux-2.6 has been built in all architectures and linux-modules-extra-2.6 has been fastly processed (thanks ftpmasters) and then we could manage to get a massbuild done in few days (+- 5 of febuary or even before). I've started to check the new modules and prepare the patches for kernel-wedge for it and hope to get it ready for tomorrow or so. - e2fsprogs inode size change Lastest release[1] changed the default inode size to 256 bytes. This is not yet on lenny but is already available on sid and will hit lenny in few days. 1. http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.5 Currently, there's a know problem with GRUB[2] and the safest solution is to change the current inode size back to 128 bytes using -I option of mke2fs for Beta1 release and then work on GRUB or GRUB2 to support it for lenny Beta2 release with 256 bytes again. 2. http://bugs.debian.org/463236 Please, I'd like to ask for comments on above points so we can decide about the timeline. The current timeline that looks sane is: +-+---+ |Date |What happens | +-+---+ |2/1/2007 |translation update request is send | +-+---+ |2/15/2007|mass upload of translation updates | +-+---+ |2/15/2007|kernel, modules and their udebs hitted testing | +-+---+ |2/16/2007|mass migration of udebs| +-+---+ |2/17/2007|debian-installer is uploaded | +-+---+ |2/19/2007|daily images are changed to use lenny installer| +-+---+ |2/21/2007|test of images starts | +-+---+ |2/27/2007|final image builds | +-+---+ |3/1/2007 |planned release date | +-+---+ Obviously, to be able to get there, we all need to work together. This means that d-i team, kernel team, release team, and package maintainers of packages that builds udebs will need to work closely those days and cooperate each other. One thing that could delay whole release is the migration of xorg package to testing. It needs to go otherwise we won't have desktop installation properly working on Beta1 since we don't use discover1 and xresprobe for detection anymore. I'm sure we all can do that and I'll do my best to work closely of you all too. What people say? - -- 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://otavio.ossystems.com.br - - Microsoft sells you Windows ... Linux gives you the whole house. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFHokXDLqiZQEml+FURApdJAJ9o2u2TlzMuNhB1tNKrGgf0O6oBCgCeKX55 ILVAsJMEyGfP0vCI2h58yEo= =sWpY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Beta1 missing decisions and possible timeline
On Thu, Jan 31, 2008 at 08:04:23PM -0200, Otavio Salvador wrote: - kernel to release We have 2.6.22 as a safe bed on lenny now and their udebs are there too however since EtchAndHalf intends to release with 2.6.24 and it has been uploaded to sid already I'm considering a better option to us to release with it. 2.6.24 is our default - 2.6.22 is a backup. We wanted to get some testing in sid first, and should be able to make a more informed decision based on user reports in about a week. linux-2.6 has been built in all architectures and linux-modules-extra-2.6 has been fastly processed (thanks ftpmasters) and waldi, maks, panthera :) and then we could manage to get a massbuild done in few days (+- 5 of febuary or even before). I've started to check the new modules and prepare the patches for kernel-wedge for it and hope to get it ready for tomorrow or so. Awesome. Is there anything special we need to add to deal with etch 1/2 kernel metapackages? We were talking about using a name like linux-image-2.6-686-etchnhalf. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
