Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
On Thu, Jul 01, 2004 at 09:53:50AM +0900, GOTO Masanori wrote: > At Wed, 30 Jun 2004 10:51:22 +0200, > Sven Luther wrote: > > So, i am seriously considering dropping all 2.4 powerpc kernels, and > > going with 2.6 only, and would like to get feedback both from > > debian-kernel as well as debian-powerpc, feedback i didn't get in the > > past. > > > > Ah, and i am seriously considering dropping support for apus from the > > kernels (and thus debian-installer). I believe that they are only a > > handfull of apus users left, and those are happily running self built > > 2.2 kernels. Furthermore, i have some evidence that not only where the > > debian apus kernels never tried on apus, but also that there is big > > chance they don't even work. I don't have apus hardware anymore, so ... > > The transition 2.4 -> 2.6 is generally good idea. Cool. > However, did you confirm that various packages is 2.6 ready? For Nope, which is why i asked for discussion on this topic. I personally run only 2.6, and i believe this is already the case for a majority of powerpc users though. But thanks for your input. Also, i don't exactly follow you on the the FTBFS mentioned below, since the glibc is using 2.6 headers anyway since some time now, and all the 2.6 related FTFBS bugs we were going to run against we already did. I may be missing something though. > example video/console related package and so on. I don't want to see video/console ? You mean, like fbset and various things that depend on the fbdev device ? We would have to give them a try, thanks for the hint. I know the fbdev layer was rewritten, but does it really affect userland ? > a lot of FTBFS bugs that say: "PPC has only 2.6 kernel, and this Well, there will always be the 2.4 kernel, but 2.6 would be the default. > package is not usable!" before releasing sarge. Testing one kernel is > easy; testing various packages is hard. Yep, which is why we should move to 2.6 as default as soon as possible. Now, if only the 2.6.7 kernel would finally escape the NEW queue, but ftp-masters are mute about this, as usual. This is going to be a real problem. > Unfortunatelly sarge release schedule is not decided yet, but I fear > this transition makes something damage for releasing sarge (including > d-i). Is this well tested? Except for this issue, I welcome your > decision. Yep, i am not entirely sure that userland is really ready, which is my only point of hesitation at this time, and i would like to have a help in tracking down possible issues. But again it is not as if 2.4 is going away, so if it doesn't work out, we can always return to 2.4 before the release. Another issue would be the various kernel module package which may not be 2.6 ready. Friendly, Sven Luther
Re: 2.6.7
On Wed, Jun 30, 2004 at 04:01:16PM +0200, Sven Luther wrote: [snip] > We really need to get 2.6.7 out in the open. How long has it been > already, two weeks or three maybe ? > > Anyway, i am CCing ftpmasters, in hope to get some feedback. [I did not CC them on this post, I think it is only relevant to debian-kernel] > So, ftpmasters, i know you are probably busy either with other debian > stuff, or real life, but i would like to bring two points to your > attention : > > 1) Well, there is this matter of the 2.6.7 kernel-source packages, as > well as the port related patches packages which it would be nice to > have in unstable quickly (at least on my box 2.6.7 solve a nasty box > freeze, and i belive other rather important bugs are fixed by it). Agreed. > 2) In general, this waiting for each new kernel version for NEW queue > processing is a bit problematic for good quality debian/kernel > packaging, especially so near the sarge release (hopefully). I > understand that they may be issues with just allowing the package in > quickly, but i would like to know from you what we as debian kernel > packager team can do to help you review the new packages quickly ? > Some preprocessing of the diffs maybe or something such ? What do you > usually do when examining a new kernel version ? Should we really be tring to spin the kernel version repeatedly as we aproach sarge? Shouldn't we settle on a kernel that is going into sarge, one for 2.4 and one for 2.6 and work on making that as stable as possible? To me, constantly chasing new kernel versions doesn't seem to be the best way to get something rock solid for Sarge. -- Simon Horman (Horms) [EMAIL PROTECTED] http://verge.net.au/~horms/
Bug#257038: kernel-image-2.6.6-1-686: Does not mount HFS+ volume
Package: kernel-image-2.6.6-1-686 Version: 2.6.6-1 Severity: normal 192:~# mount -t hfsplus /dev/hdc5 /mnt mount: Not a directory the same thing with mount /dev/hdc /mnt I can mount /dev/hdc5 /mnt but it is mounted only hfs, so the hfs+ filesystem is not visible. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages kernel-image-2.6.6-1-686 depends on: ii coreutils [fileutils]5.0.91-2The GNU core utilities ii fileutils5.0.91-2The GNU file management utilities ii initrd-tools 0.1.69 tools to create initrd image for p ii module-init-tools3.0-pre10-3 tools for managing Linux kernel mo -- no debconf information
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
At Wed, 30 Jun 2004 10:51:22 +0200, Sven Luther wrote: > So, i am seriously considering dropping all 2.4 powerpc kernels, and > going with 2.6 only, and would like to get feedback both from > debian-kernel as well as debian-powerpc, feedback i didn't get in the > past. > > Ah, and i am seriously considering dropping support for apus from the > kernels (and thus debian-installer). I believe that they are only a > handfull of apus users left, and those are happily running self built > 2.2 kernels. Furthermore, i have some evidence that not only where the > debian apus kernels never tried on apus, but also that there is big > chance they don't even work. I don't have apus hardware anymore, so ... The transition 2.4 -> 2.6 is generally good idea. However, did you confirm that various packages is 2.6 ready? For example video/console related package and so on. I don't want to see a lot of FTBFS bugs that say: "PPC has only 2.6 kernel, and this package is not usable!" before releasing sarge. Testing one kernel is easy; testing various packages is hard. Unfortunatelly sarge release schedule is not decided yet, but I fear this transition makes something damage for releasing sarge (including d-i). Is this well tested? Except for this issue, I welcome your decision. Regards, -- gotom
Bug#257040: Acknowledgement (gzip hangs system with large argument list)
Additional information on this bug:
The command "find . -name \*.ps -exec gzip \{\{ \;"
hangs the system in the same way.
This time the "ps" command shows "gzip shower.ps"
as the invocation that is hung. But this file "shower.ps"
is not the first in the order returned by "find . -name \*.ps"
and after turning off the power and rebooting, the files earlier
in the list have not been compressed.
The command "gzip shower.ps" run from the tcsh prompt succeeds in
a normal fashion.
These files are on a Reiser files system partition.
--
Kenneth H. Carpenter <[EMAIL PROTECTED]>
Processed: Re: Bug#257040: gzip hangs system with large argument list
Processing commands for [EMAIL PROTECTED]: > tags 257040 - security Bug#257040: gzip hangs system with large argument list Tags were: security Tags removed: security > reassign 257040 kernel Bug#257040: gzip hangs system with large argument list Bug reassigned from package `gzip' to `kernel'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
On Wed, Jun 30, 2004 at 02:01:34PM -0500, Benjamin Herrenschmidt wrote: > > > > Well... That isn't really what I said ;) What I said is that I don't > > > have time to actively maintain the PowerMac support in 2.4, that is make > > > it evolve & support newer machines. That doesn't mean that PPC will be > > > going away from 2.4 ;) > > > > I think the exact quote was that you are not going to support G5 on 2.4 > > forever. But anyway, a move to 2.6 should be salutable if all the > > linuxppc developers have much more interest for 2.6 trhan 2.4, and we > > will be saddled with this for the next 2 years probably, so ... > > Oh yes, G5 is another matter, it's not supported at all in 2.4 ;) The > fact that there is a very minimal support in 2.4 was done to help some > distro who had 2.4-only installers at one point, and definitely not meant > to be used after the install stage. Yep, so if we move for G5, then we should as well move for the rest of them, and drop apus by the way. > Also, I don't intend to support the 32 bits kernel on them for long neither, > G5s should really run a 64 bits kernel even with a 32 bits userland. This will probably not be for sarge though, altough once i get some time again, i need to look into this again. At least a 64bit toolchain should be easily obtainable now. Friendly, Sven Luther
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Wed, Jun 30, 2004 at 06:22:51PM +0200, Thiemo Seufer wrote: > Sven Luther wrote: > [snip] > > > > Err, what is the problem in having 2.4 floppy debian-installer, and then > > > > install the 2.6 kernel on the installed system. > > > > > > That's not a problem, apart from diverging device support for e.g. SATA. > > > But d-i uses the normal debian kernel. If you eliminate 2.4 i386, then > > > there's no such kernel left for d-i. > > The general idea, however, is to use the same kernel for d-i and for > the installed system. Rationale: An installer which dies immediately > is better than one which installs half of the new system and then > dies on reboot. Yeah sure, but remember this will only affect those boxes without netboot or CD/DVD drives. > > I am not proposing anything so drastic, just that 2.6 be made the > > defaultm with 2.4 as fallback for those who need it. > > AFAIK starting the installer with "linux26" or from 2.6 images should > already have this effect. Since 2.4 is still much better tested, it's > probably a good idea to keep it that way (at least as long as we have > some hope for releasing sarge in the next months). Well, not really, since we are speaking about floppies, but you are right. i was suposing installing with 2.6 by default and having linux24 just in case, but this is a decision that is for the x86 mfolk to make. For powerpc i believe the decision is much more easy. Friendly, Sven Luther
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
> > Well... That isn't really what I said ;) What I said is that I don't > > have time to actively maintain the PowerMac support in 2.4, that is make > > it evolve & support newer machines. That doesn't mean that PPC will be > > going away from 2.4 ;) > > I think the exact quote was that you are not going to support G5 on 2.4 > forever. But anyway, a move to 2.6 should be salutable if all the > linuxppc developers have much more interest for 2.6 trhan 2.4, and we > will be saddled with this for the next 2 years probably, so ... Oh yes, G5 is another matter, it's not supported at all in 2.4 ;) The fact that there is a very minimal support in 2.4 was done to help some distro who had 2.4-only installers at one point, and definitely not meant to be used after the install stage. Also, I don't intend to support the 32 bits kernel on them for long neither, G5s should really run a 64 bits kernel even with a 32 bits userland. Ben.
Re: status of 2.6.7 ?
On Wed, Jun 30, 2004 at 04:57:12PM +, Andreas Metzler wrote: > Sven Luther <[EMAIL PROTECTED]> wrote: > > On Wed, Jun 30, 2004 at 09:43:40PM +1000, Andrew Pollock wrote: > >> On Wed, Jun 30, 2004 at 08:19:07AM +0200, Sven Luther wrote: > [...] > >> > For example, i know that the XF86Config-4 file needs to be changed when > >> > using a ps2 mouse, since it was /dev/psaux previously, and is > >> > /dev/input/mice now. Breaking X during the upgrade is hardly acceptable > >> > if we are going to make 2.6 the default. > [...] > > But i hear there is a psaux workaround in the 2.6 package by Herbert. Is > > this still there, or did it get removed by Christoph and William, and if > > so, why? > > There is the possibilty for psmouse.ko to _additionally_ provide > /dev/psaux > config INPUT_MOUSEDEV_PSAUX_ENABLE > bool "Enable /dev/psaux device by default" > and it is at least enabled in > kernel-image-2.6.7-1-386_2.6.7-1_i386.deb uploaded by dilinger. However > this is no fix. - If you upgrade from Kernel 2.4 you'll have two > mousedevices[1] in XF86Config-4, /dev/psaux as primary one and > /dev/input/mice as optional secondary one. - The result is that with 2.6 > every mousemovement (or click) is doubled. - So you'll need to > dpkg-reconfigure xserver-xfree86 and select /dev/input/mice. Yep, that is indeed the problem, i wonder if the correct thing would not be for the 2.6 kernels to probe the debconf database of XFree86, modify this value, and regenerate the database, or if the XF86Config file is handled by hand, inform the user about this modification. > The only real fix I can imagine is: > * 2.6 does not provide /dev/psaux anymore Currently happening on powerpc 2.6, breaks if /dev/psaux is corepointer. > * XFree starts treating /dev/psaux and /dev/input/mice equally if both > are listed, i.e. it will work if _either_ of them are accessible > instead of insiting on the primary one. A huge XFree86 Change probably, i don't know that code so well, so am CCing debian-x for advice. > cu andreas > > [1] I assume this was added for laptops, the primary device being a > touchpad, the secondary one a USB-mouse which is not always connected. Yep probably. Friendly, Sven Luther
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
On Wed, Jun 30, 2004 at 11:40:14AM -0500, Benjamin Herrenschmidt wrote: > On Wed, 2004-06-30 at 03:51, Sven Luther wrote: > > Hello, > > > > Well, nobody seemed to care or comment on this, so let's take this to a > > wider audience. > > > > Christoph has recently told me that he doesn't care about 2.4, and even > > benh has mentioned to me that 2.4 support for powerpc will be going away > > in the near term (well, not the eact words, but you get my meaning). And > > i guess that Jens also is only interested on 2.6 kernels, even though he > > is comaintainer of the 2.4 kernels too. > > Well... That isn't really what I said ;) What I said is that I don't > have time to actively maintain the PowerMac support in 2.4, that is make > it evolve & support newer machines. That doesn't mean that PPC will be > going away from 2.4 ;) I think the exact quote was that you are not going to support G5 on 2.4 forever. But anyway, a move to 2.6 should be salutable if all the linuxppc developers have much more interest for 2.6 trhan 2.4, and we will be saddled with this for the next 2 years probably, so ... Friendly, Sven Luther
Re: status of 2.6.7 ?
Sven Luther <[EMAIL PROTECTED]> wrote: > On Wed, Jun 30, 2004 at 09:43:40PM +1000, Andrew Pollock wrote: >> On Wed, Jun 30, 2004 at 08:19:07AM +0200, Sven Luther wrote: [...] >> > For example, i know that the XF86Config-4 file needs to be changed when >> > using a ps2 mouse, since it was /dev/psaux previously, and is >> > /dev/input/mice now. Breaking X during the upgrade is hardly acceptable >> > if we are going to make 2.6 the default. [...] > But i hear there is a psaux workaround in the 2.6 package by Herbert. Is > this still there, or did it get removed by Christoph and William, and if > so, why? There is the possibilty for psmouse.ko to _additionally_ provide /dev/psaux config INPUT_MOUSEDEV_PSAUX_ENABLE bool "Enable /dev/psaux device by default" and it is at least enabled in kernel-image-2.6.7-1-386_2.6.7-1_i386.deb uploaded by dilinger. However this is no fix. - If you upgrade from Kernel 2.4 you'll have two mousedevices[1] in XF86Config-4, /dev/psaux as primary one and /dev/input/mice as optional secondary one. - The result is that with 2.6 every mousemovement (or click) is doubled. - So you'll need to dpkg-reconfigure xserver-xfree86 and select /dev/input/mice. The only real fix I can imagine is: * 2.6 does not provide /dev/psaux anymore * XFree starts treating /dev/psaux and /dev/input/mice equally if both are listed, i.e. it will work if _either_ of them are accessible instead of insiting on the primary one. cu andreas [1] I assume this was added for laptops, the primary device being a touchpad, the secondary one a USB-mouse which is not always connected.
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
On Wed, 2004-06-30 at 03:51, Sven Luther wrote: > Hello, > > Well, nobody seemed to care or comment on this, so let's take this to a > wider audience. > > Christoph has recently told me that he doesn't care about 2.4, and even > benh has mentioned to me that 2.4 support for powerpc will be going away > in the near term (well, not the eact words, but you get my meaning). And > i guess that Jens also is only interested on 2.6 kernels, even though he > is comaintainer of the 2.4 kernels too. Well... That isn't really what I said ;) What I said is that I don't have time to actively maintain the PowerMac support in 2.4, that is make it evolve & support newer machines. That doesn't mean that PPC will be going away from 2.4 ;) > So, i am seriously considering dropping all 2.4 powerpc kernels, and > going with 2.6 only, and would like to get feedback both from > debian-kernel as well as debian-powerpc, feedback i didn't get in the > past. > > Ah, and i am seriously considering dropping support for apus from the > kernels (and thus debian-installer). I believe that they are only a > handfull of apus users left, and those are happily running self built > 2.2 kernels. Furthermore, i have some evidence that not only where the > debian apus kernels never tried on apus, but also that there is big > chance they don't even work. I don't have apus hardware anymore, so ... > > So, please feedback is welcome. > > Friendly, > > Sven Luther > > On Sun, Jun 27, 2004 at 09:55:46PM +0200, Sven Luther wrote: > > On Sun, Jun 27, 2004 at 05:29:38PM +0200, Christoph Hellwig wrote: > > > There's a few reports against 2.4 kernel that are fixed in 2.6 and are > > > unlikely to get in 2.4 every (Examples: #146956 or #130217). How should > > > we deal with them in the BTS? > > > > The real question here is to ask ourselves what is our option for the > > sarge release. Will we release with 2.4 as default, which is the track > > we are on right now, or will we release with 2.6 as default, and keep > > 2.4 about only as backup in case there is a real problem with 2.4. > > > > There are both advantages and problems in going with 2.6 : > > > > advantage: it is the future, has some features and fixes which will > > not be backported to 2.4, and moreover many of our new kernel team > > have no interest whatsoever for 2.4, which includes benh and Christoph > > among others. > > > > problems: not all architectures support 2.6 yet (well, most of them do > > not), and moreover, our userland has probably not been fully tested > > with 2.6 all that much. > > > > So, the real question, for those arches which do support 2.6, and if > > those bug reports you mention are problems only on those arches where > > 2.6 is supported, and if we decide to go for 2.6, then it should be ok > > to mark those bugs as wontfix, and put a note that it is fixed in 2.6. > > > > If on the other hand we decide to go with 2.4 by default, or those bugs > > affect arches which are not ready to go with 2.6, then not only it is > > not ok to close them (even if our new kernel team doesn't care for 2.4), > > but we should either backport the fix, or find another way to close it > > before the sarge release. > > > > Now, about going with 2.6, i personnally would maybe like to go with 2.6 > > eclusively for all the powerpc subarches, altough i am not entirely sure > > we are ready for this. For this to happen we need to achieve the > > following : > > > > Have a kernel bootable on all subarches : > > > > -> yaboot using newworld pmac & chrp-rs6k : Ok, but need testing on > > chrp-rs6k > > -> mkvmlinuz generated chrp : Need to find a solution for the > > generation of the vmlinuz image, should be easy, once we agree on a > > way to go. > > -> oldworld pmac : We need to shrink the size of the kernel so it > > fits on a miboot floppy and test it. This should be best achieved by > > modularizing the pmac-ide driver, and other pmac stuff which could > > be modularized. Benh said he scarcely has time for it, and Christoph > > promised he would have a look. > > -> prep : renamed pplus in the kernel code. We need to add mkvmlinuz > > code for this one, not sure about the others, we did not support > > them, but it should be possible to add support to mkvmlinuz easily > > enough. Testing on those subarches is needed though. > > -> apus : Well, a 2.6 port could be done and tested, using a > > conditionally applied patch or something such, or merging the > > patches. That said, since there are at most 5-10 users left, and > > those are using their own kernels, maybe we should drop kernel > > support for them. > > > > Another point would be to test the 2.6 debian-installer on all those > > subarches, and fi the problems if they appear. > > > > If all this does happen before the sarge release, and if the userland > > issues are solved, then i would strongly recomend going for
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
Sven Luther wrote: [snip] > > > Err, what is the problem in having 2.4 floppy debian-installer, and then > > > install the 2.6 kernel on the installed system. > > > > That's not a problem, apart from diverging device support for e.g. SATA. > > But d-i uses the normal debian kernel. If you eliminate 2.4 i386, then > > there's no such kernel left for d-i. The general idea, however, is to use the same kernel for d-i and for the installed system. Rationale: An installer which dies immediately is better than one which installs half of the new system and then dies on reboot. > I am not proposing anything so drastic, just that 2.6 be made the > defaultm with 2.4 as fallback for those who need it. AFAIK starting the installer with "linux26" or from 2.6 images should already have this effect. Since 2.4 is still much better tested, it's probably a good idea to keep it that way (at least as long as we have some hope for releasing sarge in the next months). Thiemo
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Wed, Jun 30, 2004 at 05:14:30PM +0200, Thiemo Seufer wrote: > Sven Luther wrote: > [snip] > > > > Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who > > > > is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). > > > > > > It would kill floppy boot images for i386 (2.6 is too big for it). > > > > Err, what is the problem in having 2.4 floppy debian-installer, and then > > install the 2.6 kernel on the installed system. > > That's not a problem, apart from diverging device support for e.g. SATA. > But d-i uses the normal debian kernel. If you eliminate 2.4 i386, then > there's no such kernel left for d-i. I am not proposing anything so drastic, just that 2.6 be made the defaultm with 2.4 as fallback for those who need it. > > We also have this > > problem on powerpc, and another solution may be a separate kernel > > flavour for 2.6 debian-installer floppies. Altough we are only 300-400KB > > away of fiting on a floppy with miboot. > > IOW, it doesn't work there as well. Everything not needed for boot > should already be in modules anyway. Ah, this is indeed worse than on powerpc, where there is ample possibilities to remove stuff still, at least for oldworld who don't need a whole bunch of stuff which is actually builtin. Friendly, Sven Luther
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
Sven Luther wrote: [snip] > > > Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who > > > is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). > > > > It would kill floppy boot images for i386 (2.6 is too big for it). > > Err, what is the problem in having 2.4 floppy debian-installer, and then > install the 2.6 kernel on the installed system. That's not a problem, apart from diverging device support for e.g. SATA. But d-i uses the normal debian kernel. If you eliminate 2.4 i386, then there's no such kernel left for d-i. > We also have this > problem on powerpc, and another solution may be a separate kernel > flavour for 2.6 debian-installer floppies. Altough we are only 300-400KB > away of fiting on a floppy with miboot. IOW, it doesn't work there as well. Everything not needed for boot should already be in modules anyway. Thiemo
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Wed, Jun 30, 2004 at 04:06:35PM +0200, Thiemo Seufer wrote: > Sven Luther wrote: > [snip] > > > AFAIK, there's one or two arches that haven't even got to 2.4 yet. I'm > > > pushing for all 2.2 kernel packages to get the boot from the archive, but > > > I > > > think m68k has issues with 2.4. I think we're a long way away from > > > universal > > > 2.6. > > > > Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who > > is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). > > It would kill floppy boot images for i386 (2.6 is too big for it). Err, what is the problem in having 2.4 floppy debian-installer, and then install the 2.6 kernel on the installed system. We also have this problem on powerpc, and another solution may be a separate kernel flavour for 2.6 debian-installer floppies. Altough we are only 300-400KB away of fiting on a floppy with miboot. Friendly, Sven Luther
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
Sven Luther wrote: [snip] > > AFAIK, there's one or two arches that haven't even got to 2.4 yet. I'm > > pushing for all 2.2 kernel packages to get the boot from the archive, but I > > think m68k has issues with 2.4. I think we're a long way away from universal > > 2.6. > > Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who > is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). It would kill floppy boot images for i386 (2.6 is too big for it). Thiemo
Re: 2.6.7
On Wed, Jun 30, 2004 at 03:47:20PM +0200, Christian Heim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am Mittwoch, 30. Juni 2004 15:21 schrieb Jens Schmalzing: > > Hi, > > > > Christian Heim writes: > > > But I've tested [the vesafb patch] now for you. > > > > > > Doesn't compile at all. > > > > Where did you get the kernel source tree from? The build Works very > > well here, using kernel-source-2.6.7_2.6.7-2. > > In my lack of knowledge, i've grabbed the vanilla sources, added Christoph > Hellwig's debian-patches (http://verein.lst.de/~hch/debian-2.6.7.tgz), added > your vesafb_fix and tried to compile these. > > But now, I'm a little bit smarter ... We really need to get 2.6.7 out in the open. How long has it been already, two weeks or three maybe ? Anyway, i am CCing ftpmasters, in hope to get some feedback. So, ftpmasters, i know you are probably busy either with other debian stuff, or real life, but i would like to bring two points to your attention : 1) Well, there is this matter of the 2.6.7 kernel-source packages, as well as the port related patches packages which it would be nice to have in unstable quickly (at least on my box 2.6.7 solve a nasty box freeze, and i belive other rather important bugs are fixed by it). 2) In general, this waiting for each new kernel version for NEW queue processing is a bit problematic for good quality debian/kernel packaging, especially so near the sarge release (hopefully). I understand that they may be issues with just allowing the package in quickly, but i would like to know from you what we as debian kernel packager team can do to help you review the new packages quickly ? Some preprocessing of the diffs maybe or something such ? What do you usually do when examining a new kernel version ? Please provide some feedback over this instead of this heavt silence that is the usual response to this kind of inquiries. Friendly, Sven Luther
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
On Wed, Jun 30, 2004 at 12:32:43PM +0100, Colin Watson wrote: > On Wed, Jun 30, 2004 at 10:51:22AM +0200, Sven Luther wrote: > > Well, nobody seemed to care or comment on this, so let's take this to a > > wider audience. > > > > Christoph has recently told me that he doesn't care about 2.4, and even > > benh has mentioned to me that 2.4 support for powerpc will be going away > > in the near term (well, not the eact words, but you get my meaning). And > > i guess that Jens also is only interested on 2.6 kernels, even though he > > is comaintainer of the 2.4 kernels too. > > > > So, i am seriously considering dropping all 2.4 powerpc kernels, and > > going with 2.6 only, and would like to get feedback both from > > debian-kernel as well as debian-powerpc, feedback i didn't get in the > > past. > > While generally I think defaulting to 2.6 would be a good idea, I'd > really prefer not to drop 2.4 (as in remove the packages) just yet. It's This was not my intention, altough a little chat with Branden on irc made me doubt it. Anyway, i am preparing 2.4.26 packages right now, as there seems to be a urgent need of it :/ I am somehow doubtfull about the wisdom of continuing following the 2.4 -benh tree, as not much effort goes into it, and benh main interest is with 2.6. > worth noting that no release candidate version of d-i has yet had > working support for 2.6 on powerpc (test candidate 1 would have done but > ran into a busybox-cvs bug, so it's likely that neither TC2 nor RC1 will > have either), although daily builds have had it for some time and in my > experience work well. Huh ? how come daily builds have support while TC2 has not ? And as you know, i am actively working on getting the support for it right. Friendly, Sven Luther
Re: 2.6.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Mittwoch, 30. Juni 2004 15:21 schrieb Jens Schmalzing: > Hi, > > Christian Heim writes: > > But I've tested [the vesafb patch] now for you. > > > > Doesn't compile at all. > > Where did you get the kernel source tree from? The build Works very > well here, using kernel-source-2.6.7_2.6.7-2. In my lack of knowledge, i've grabbed the vanilla sources, added Christoph Hellwig's debian-patches (http://verein.lst.de/~hch/debian-2.6.7.tgz), added your vesafb_fix and tried to compile these. But now, I'm a little bit smarter ... - -- Mfg Christian Heim Auszubildender im Rechenzentrum der Universität Greifswald -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA4sRo0PE+gcQmOyURAjmQAJ0W2b9n9uCZhacnxX1o24owAeUDRgCcDSJD 1EvDnWobqyngYobazm+UAt0= =aspP -END PGP SIGNATURE-
Re: 2.6.7
Hi, Christian Heim writes: > But I've tested [the vesafb patch] now for you. > > Doesn't compile at all. Where did you get the kernel source tree from? The build Works very well here, using kernel-source-2.6.7_2.6.7-2. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Wed, Jun 30, 2004 at 09:43:40PM +1000, Andrew Pollock wrote: > On Wed, Jun 30, 2004 at 08:19:07AM +0200, Sven Luther wrote: > > On Wed, Jun 30, 2004 at 03:59:10PM +1000, Andrew Pollock wrote: > > > On Wed, Jun 30, 2004 at 07:45:25AM +0200, Sven Luther wrote: > > > > > > > > Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who > > > > is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). > > > > > > > > I believe now is the time to take that decision, it may even be too late > > > > already, given the sarge release schedule, and provided the GR doesn't > > > > finish in some catastrophic result for the sarge release. > > > > > > Well, AIUI, d-i should be able to on a per-arch basis default to a 2.6 > > > kernel. So we can have sarge release with a 2.6 kernel by default on > > > selected architectures. -boot may correct me. > > > > Well, the important thing is not so much -boot, but compatbility with > > the rest of userland, as well as upgrrades from woody with a 2.2 or 2.4 > > kernel to sarge with a 2.6 kernel. > > > > For example, i know that the XF86Config-4 file needs to be changed when > > using a ps2 mouse, since it was /dev/psaux previously, and is > > /dev/input/mice now. Breaking X during the upgrade is hardly acceptable > > if we are going to make 2.6 the default. > > Hmm. dist-upgrading won't install a new kernel-image package, and a fresh > install with 2.6 is going to get the mouse device right, so I don't think > this particular example is a showstopper. Sure, if you've got a pre-existing > install, with XFree86, and you choose to install a 2.6 kernel-image package, > you're in for a bit of mouse pain... No, it should just work. But i hear there is a psaux workaround in the 2.6 package by Herbert. Is this still there, or did it get removed by Christoph and William, and if so, why ? Friendly, Sven Luther
Re: 2.6.7
> But I've tested it now for you. > > Doesn't compile at all. > > - -- snip -- > CC drivers/video/vesafb.o > drivers/video/vesafb.c: In function `vesafb_remove': > drivers/video/vesafb.c:410: error: stray '\240' in program -- snip -- > Doesn't know what this really means, because I'm not familiar with gcc error > messages. That just means there were spurious characters in the input file, usually inserted by bad editors. They usually show up as white space and are a real PITA. HTH, Thibaut VARENE PA/Linux ESIEE Team http://www.pateam.org/
Re: 2.6.7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Samstag, 19. Juni 2004 15:01 schrieb Christoph Hellwig:
> On Fri, Jun 18, 2004 at 04:58:06PM +0200, Philipp H?gelmeyer wrote:
> > I still got some Problem compiling this new version because of missing
> > headers etc. After applying the following patch it worked.
>
> I've applied some of the fixes.
>
> I'm not sure about those swsusp vs swapper_pg_dir changes - neither of
> those symbols is referenced by the debian patches at all.
>
> The vesafb patch is completly bogus and you're only papering over the
> compile issue. I've a new patch below but don't have any hardware to
> actually test it:
>
> [ ... ]
But I've tested it now for you.
Doesn't compile at all.
- -- snip --
CC drivers/video/vesafb.o
drivers/video/vesafb.c: In function `vesafb_remove':
drivers/video/vesafb.c:410: error: stray '\240' in program
drivers/video/vesafb.c:410: error: stray '\240' in program
drivers/video/vesafb.c:410: error: stray '\240' in program
drivers/video/vesafb.c:410: error: stray '\240' in program
drivers/video/vesafb.c:410: error: stray '\240' in program
drivers/video/vesafb.c:410: error: stray '\240' in program
drivers/video/vesafb.c:410: error: stray '\240' in program
drivers/video/vesafb.c:412: error: stray '\240' in program
drivers/video/vesafb.c:412: error: stray '\240' in program
drivers/video/vesafb.c:412: error: stray '\240' in program
drivers/video/vesafb.c:412: error: stray '\240' in program
drivers/video/vesafb.c:412: error: stray '\240' in program
drivers/video/vesafb.c:412: error: stray '\240' in program
drivers/video/vesafb.c:412: error: stray '\240' in program
drivers/video/vesafb.c:413: error: stray '\240' in program
drivers/video/vesafb.c:413: error: stray '\240' in program
drivers/video/vesafb.c:413: error: stray '\240' in program
drivers/video/vesafb.c:413: error: stray '\240' in program
drivers/video/vesafb.c:413: error: stray '\240' in program
drivers/video/vesafb.c:413: error: stray '\240' in program
drivers/video/vesafb.c:413: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:414: error: stray '\240' in program
drivers/video/vesafb.c:415: error: stray '\240' in program
drivers/video/vesafb.c:415: error: stray '\240' in program
drivers/video/vesafb.c:415: error: stray '\240' in program
drivers/video/vesafb.c:415: error: stray '\240' in program
drivers/video/vesafb.c:415: error: stray '\240' in program
drivers/video/vesafb.c:415: error: stray '\240' in program
drivers/video/vesafb.c:415: error: stray '\240' in program
drivers/video/vesafb.c:416: error: stray '\240' in program
drivers/video/vesafb.c:416: error: stray '\240' in program
drivers/video/vesafb.c:416: error: stray '\240' in program
drivers/video/vesafb.c:416: error: stray '\240' in program
drivers/video/vesafb.c:416: error: stray '\240' in program
drivers/video/vesafb.c:416: error: stray '\240' in program
drivers/video/vesafb.c:416: error: stray '\240' in program
drivers/video/vesafb.c: At top level:
drivers/video/vesafb.c:452: error: stray '\240' in program
drivers/video/vesafb.c:453: error: stray '\240' in program
drivers/video/vesafb.c:465: error: `vesafb_exit' undeclared here (not in a
function)
drivers/video/vesafb.c:467: error: redefinition of `__check_options'
drivers/video/vesafb.c:62: error: `__check_options' previously defined here
drivers/video/vesafb.c:467: error: redefinition of `__param_str_options'
drivers/video/vesafb.c:62: error: `__param_str_options' previously defined
here
drivers/video/vesafb.c:467: error: redefinition of `__param_options'
drivers/video/vesafb.c:62: error: `__param_options' previously defined here
{standard input}: Assembler messages:
{standard input}:972: Error: symbol `__param_str_options' is already defined
{standard input}:978: Error: symbol `__param_options' is already defined
- -- snip --
Doesn't know what this really means, because I'm not familiar with gcc error
messages.
Regards
- --
Mfg Christian Heim
Auszubildender im Rechenzentrum der Universität Greifswald
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA4rtL0PE+gcQmOyURAvz/AJ4nrfzUKAdnEs+aetD6rBGuMzGPPACfS6/2
Xq4v8r2jPL0xcHaqQrTs76c=
=
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Wed, Jun 30, 2004 at 08:19:07AM +0200, Sven Luther wrote: > On Wed, Jun 30, 2004 at 03:59:10PM +1000, Andrew Pollock wrote: > > On Wed, Jun 30, 2004 at 07:45:25AM +0200, Sven Luther wrote: > > > > > > Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who > > > is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). > > > > > > I believe now is the time to take that decision, it may even be too late > > > already, given the sarge release schedule, and provided the GR doesn't > > > finish in some catastrophic result for the sarge release. > > > > Well, AIUI, d-i should be able to on a per-arch basis default to a 2.6 > > kernel. So we can have sarge release with a 2.6 kernel by default on > > selected architectures. -boot may correct me. > > Well, the important thing is not so much -boot, but compatbility with > the rest of userland, as well as upgrrades from woody with a 2.2 or 2.4 > kernel to sarge with a 2.6 kernel. > > For example, i know that the XF86Config-4 file needs to be changed when > using a ps2 mouse, since it was /dev/psaux previously, and is > /dev/input/mice now. Breaking X during the upgrade is hardly acceptable > if we are going to make 2.6 the default. Hmm. dist-upgrading won't install a new kernel-image package, and a fresh install with 2.6 is going to get the mouse device right, so I don't think this particular example is a showstopper. Sure, if you've got a pre-existing install, with XFree86, and you choose to install a 2.6 kernel-image package, you're in for a bit of mouse pain... Andrew
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
On Wed, Jun 30, 2004 at 10:51:22AM +0200, Sven Luther wrote: > Well, nobody seemed to care or comment on this, so let's take this to a > wider audience. > > Christoph has recently told me that he doesn't care about 2.4, and even > benh has mentioned to me that 2.4 support for powerpc will be going away > in the near term (well, not the eact words, but you get my meaning). And > i guess that Jens also is only interested on 2.6 kernels, even though he > is comaintainer of the 2.4 kernels too. > > So, i am seriously considering dropping all 2.4 powerpc kernels, and > going with 2.6 only, and would like to get feedback both from > debian-kernel as well as debian-powerpc, feedback i didn't get in the > past. While generally I think defaulting to 2.6 would be a good idea, I'd really prefer not to drop 2.4 (as in remove the packages) just yet. It's worth noting that no release candidate version of d-i has yet had working support for 2.6 on powerpc (test candidate 1 would have done but ran into a busybox-cvs bug, so it's likely that neither TC2 nor RC1 will have either), although daily builds have had it for some time and in my experience work well. > Ah, and i am seriously considering dropping support for apus from the > kernels (and thus debian-installer). Amen! -- Colin Watson [EMAIL PROTECTED]
Re: Open a discussion about bug 253324
> The low techie people I came across think that anything beside graphics are >"old computing" or recovery broken things... so a bootsplash help they to >trust the operating system (the computer as whole object from their point of >view). I'm totally agree on this point. In my experience of installing debian to many different kind of people this is a very diffuse user cases and not only for low tech people also for avg tech people. It's a little psicological problem against debian that a small and tested kernel patch could solve. Some basically bootslpash + kernel patch for debian could be finded here: http://mentors.debian.net/debian/dists/unstable/main/binary-i386/ This cuold be a pointo of start for an official integration in the debian kernel. Cheers, Stefano
Re: Open a discussion about bug 253324
> The low techie people I came across think that anything beside graphics are >"old computing" or recovery broken things... so a bootsplash help they to >trust the operating system (the computer as whole object from their point of >view). I'm totally agree on this point. In my experience of installing debian to many different kind of people this is a very diffuse user cases and not only for low tech people also for avg tech people. It's a little psicological problem against debian that a small and tested kernel patch could solve. Cheers, Stefano
Re: Open a discussion about bug 253324
On Wed, Jun 30, 2004 at 12:13:41PM +0200, Marco Amadori wrote: > Alle 02:01, mercoledì 30 giugno 2004, Andres Salomon ha scritto: > > > >> I want to "open" a discussion about this bug on the debian-kernel > > >> mailing list: > > >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253224 > > > Heh, when I first saw this post, I was ready to agree w/ Herbert (feh, > > unnecessary eyecandy). > > Same to me. > > > Then I went to the page; the screenshots are > > impressive. > > Yes! It will really helps the "debian desktop experience" IMHO. > > > I'd be up for adding this sort of thing, as long as the > > impact to users who don't want it (in disk space, memory, and > > processor cycles) is minimal. > > The kernel patch is small, the userspace is trival and the media space is 1% > of e.g. kde-artworks eye candy stuff. > > > I recently set up a Debian box for my mom, > > and she asked about all the obscure boot messages that come up; it would > > be nice to have a graphical display that could hide all that. > > Same to me here too, but instead of my mom, she was m girlfriend and a low > techie friend that bought a computer from me (debian-only obviously, no > double boot or such). > > The low techie people I came across think that anything beside graphics are > "old computing" or recovery broken things... so a bootsplash help they to > trust the operating system (the computer as whole object from their point of > view). > > Suse already has bootsplash (it seems that they pushed some developing in it > also), and debian is just a few patch away from it (mainly mkinitrd support > and a kernel-patch). > > But if the debian-kernel team agree on not having bootsplash support, I will > be silent until I can make easy (not more word but patch bytes!) for your > team to add it. I don't know if we agree, it was not even discussed, so thanks for your input. Friendly, Sven Luther
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 10:59:43AM +0200, Michael Banck wrote: > On Wed, Jun 30, 2004 at 09:34:45AM +0200, Sven Luther wrote: > > > If you have an axe to grind with me, Christoph, "purists" or somebody > > > stiffling your flexibility, whatever that might mean - feel free to > > > take it offlist. > > > > Why offlist, this is most certainly on topic, since it defines the way > > debian is going to threat the kernel package. > > I don't see how this bickering is on-topic for debian-amd64, you might > want to check your CC list from time to time. Ah, erm, ok. ... It was on debian-kernel though. All ports should be concerned though, or at least their kernel packagers. Friendly, Sven Luther
Re: Dealing with 2.4 bugreports that are fixed in 2.6 only
On Tue, Jun 29, 2004 at 12:31:52PM +0100, Martin Michlmayr wrote: > * Christoph Hellwig <[EMAIL PROTECTED]> [2004-06-27 17:29]: > > There's a few reports against 2.4 kernel that are fixed in 2.6 and > > are unlikely to get in 2.4 every (Examples: #146956 or #130217). > > How should we deal with them in the BTS? > > Is there any chance of those fixes being backported to 2.4 and how > much work would it be? It seems that you guys have all given up on > 2.4 completely, but I'd imagine that the majority of our users will > still use 2.4 for a while. Especially as some arches are not ready yet for 2.6. I belive only x86 and powerpc are ready for 2.6 right now, with maybe amd64, but as the kernel team has against rejected the amd64 patch guys rather brutally, not sure if it is still relevant. > This is really related to some other postings in this thread: are we > ready to move to 2.6 by default? Yep, but it has not seen much interest yet. I wonder why. I have forwarded it to aj also, since i really would like to have its opinion on this, especially with regard to userland. Friendly, Sven Luther
Re: Dealing with 2.4 bugreports that are fixed in 2.6 only
* Christoph Hellwig <[EMAIL PROTECTED]> [2004-06-27 17:29]: > There's a few reports against 2.4 kernel that are fixed in 2.6 and > are unlikely to get in 2.4 every (Examples: #146956 or #130217). > How should we deal with them in the BTS? Is there any chance of those fixes being backported to 2.4 and how much work would it be? It seems that you guys have all given up on 2.4 completely, but I'd imagine that the majority of our users will still use 2.4 for a while. This is really related to some other postings in this thread: are we ready to move to 2.6 by default? -- Martin Michlmayr [EMAIL PROTECTED]
Re: Open a discussion about bug 253324
Alle 02:01, mercoledì 30 giugno 2004, Andres Salomon ha scritto: > >> I want to "open" a discussion about this bug on the debian-kernel > >> mailing list: > >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253224 > Heh, when I first saw this post, I was ready to agree w/ Herbert (feh, > unnecessary eyecandy). Same to me. > Then I went to the page; the screenshots are > impressive. Yes! It will really helps the "debian desktop experience" IMHO. > I'd be up for adding this sort of thing, as long as the > impact to users who don't want it (in disk space, memory, and > processor cycles) is minimal. The kernel patch is small, the userspace is trival and the media space is 1% of e.g. kde-artworks eye candy stuff. > I recently set up a Debian box for my mom, > and she asked about all the obscure boot messages that come up; it would > be nice to have a graphical display that could hide all that. Same to me here too, but instead of my mom, she was m girlfriend and a low techie friend that bought a computer from me (debian-only obviously, no double boot or such). The low techie people I came across think that anything beside graphics are "old computing" or recovery broken things... so a bootsplash help they to trust the operating system (the computer as whole object from their point of view). Suse already has bootsplash (it seems that they pushed some developing in it also), and debian is just a few patch away from it (mainly mkinitrd support and a kernel-patch). But if the debian-kernel team agree on not having bootsplash support, I will be silent until I can make easy (not more word but patch bytes!) for your team to add it. BTW: is the next kernel-source-2.6.7 including dm-snapshot and dm-mirror lkms or we'll get them only in 2.6.8?? -- Marco Amadori <[EMAIL PROTECTED]>
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 09:34:45AM +0200, Sven Luther wrote: > > If you have an axe to grind with me, Christoph, "purists" or somebody > > stiffling your flexibility, whatever that might mean - feel free to > > take it offlist. > > Why offlist, this is most certainly on topic, since it defines the way > debian is going to threat the kernel package. I don't see how this bickering is on-topic for debian-amd64, you might want to check your CC list from time to time. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
On Wed, Jun 30, 2004 at 10:59:29AM +0200, Jens Schmalzing wrote: > Hi, > > Sven Luther writes: > > > Jens [...] is comaintainer of the 2.4 kernels. > > Nope. Oh, well, we had agreed that you where well before you even thought about 2.6, but i understand. Now, please could i have your opinion on going all 2.6 on powerpc, since you obviously read that mail ? Friendly, Sven Luther
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
Hi, Sven Luther writes: > Jens [...] is comaintainer of the 2.4 kernels. Nope. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: 2.4 & 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
Hello, Well, nobody seemed to care or comment on this, so let's take this to a wider audience. Christoph has recently told me that he doesn't care about 2.4, and even benh has mentioned to me that 2.4 support for powerpc will be going away in the near term (well, not the eact words, but you get my meaning). And i guess that Jens also is only interested on 2.6 kernels, even though he is comaintainer of the 2.4 kernels too. So, i am seriously considering dropping all 2.4 powerpc kernels, and going with 2.6 only, and would like to get feedback both from debian-kernel as well as debian-powerpc, feedback i didn't get in the past. Ah, and i am seriously considering dropping support for apus from the kernels (and thus debian-installer). I believe that they are only a handfull of apus users left, and those are happily running self built 2.2 kernels. Furthermore, i have some evidence that not only where the debian apus kernels never tried on apus, but also that there is big chance they don't even work. I don't have apus hardware anymore, so ... So, please feedback is welcome. Friendly, Sven Luther On Sun, Jun 27, 2004 at 09:55:46PM +0200, Sven Luther wrote: > On Sun, Jun 27, 2004 at 05:29:38PM +0200, Christoph Hellwig wrote: > > There's a few reports against 2.4 kernel that are fixed in 2.6 and are > > unlikely to get in 2.4 every (Examples: #146956 or #130217). How should > > we deal with them in the BTS? > > The real question here is to ask ourselves what is our option for the > sarge release. Will we release with 2.4 as default, which is the track > we are on right now, or will we release with 2.6 as default, and keep > 2.4 about only as backup in case there is a real problem with 2.4. > > There are both advantages and problems in going with 2.6 : > > advantage: it is the future, has some features and fixes which will > not be backported to 2.4, and moreover many of our new kernel team > have no interest whatsoever for 2.4, which includes benh and Christoph > among others. > > problems: not all architectures support 2.6 yet (well, most of them do > not), and moreover, our userland has probably not been fully tested > with 2.6 all that much. > > So, the real question, for those arches which do support 2.6, and if > those bug reports you mention are problems only on those arches where > 2.6 is supported, and if we decide to go for 2.6, then it should be ok > to mark those bugs as wontfix, and put a note that it is fixed in 2.6. > > If on the other hand we decide to go with 2.4 by default, or those bugs > affect arches which are not ready to go with 2.6, then not only it is > not ok to close them (even if our new kernel team doesn't care for 2.4), > but we should either backport the fix, or find another way to close it > before the sarge release. > > Now, about going with 2.6, i personnally would maybe like to go with 2.6 > eclusively for all the powerpc subarches, altough i am not entirely sure > we are ready for this. For this to happen we need to achieve the > following : > > Have a kernel bootable on all subarches : > > -> yaboot using newworld pmac & chrp-rs6k : Ok, but need testing on > chrp-rs6k > -> mkvmlinuz generated chrp : Need to find a solution for the > generation of the vmlinuz image, should be easy, once we agree on a > way to go. > -> oldworld pmac : We need to shrink the size of the kernel so it > fits on a miboot floppy and test it. This should be best achieved by > modularizing the pmac-ide driver, and other pmac stuff which could > be modularized. Benh said he scarcely has time for it, and Christoph > promised he would have a look. > -> prep : renamed pplus in the kernel code. We need to add mkvmlinuz > code for this one, not sure about the others, we did not support > them, but it should be possible to add support to mkvmlinuz easily > enough. Testing on those subarches is needed though. > -> apus : Well, a 2.6 port could be done and tested, using a > conditionally applied patch or something such, or merging the > patches. That said, since there are at most 5-10 users left, and > those are using their own kernels, maybe we should drop kernel > support for them. > > Another point would be to test the 2.6 debian-installer on all those > subarches, and fi the problems if they appear. > > If all this does happen before the sarge release, and if the userland > issues are solved, then i would strongly recomend going for 2.6 for > powerpc at least, especially as the members of the debian kernel team > with interest in powerpc care very little about 2.4 kernels. > > Friendly, > > Sven Luther > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: kernel-patch-amd64
On Wed, 30 Jun 2004 08:30:05 +0200 "Sven Luther" <[EMAIL PROTECTED]> wrote: > On Tue, Jun 29, 2004 at 11:14:02PM +0100, [EMAIL PROTECTED] wrote: > > On Tue, Jun 29, 2004 at 06:23:21PM +0200, Jens Schmalzing wrote: > > > I would suggest that you subscribe to debian-kernel, prepare > > > kernel-patch-amd64-2.6.7 packages based on the example of the other > > > 2.6 kernel-patch packages (right now, this means the powerpc patches, > > > so please let me know if you find a better way of doing it) , and > > > upload them as soon as amd64 enters sid. > > > > Bad idea. Split the patch and get as much as possible merged upstream. > > Note that large parts are simply "Lindent that file" and they certainly > > should not be mixed with the rest. > > And ? Is that incompatible with making a kernel-patch-amd64 package and > building a kernel from it ? > > What i really dislike about this politic of submitting stuff upstream, > is that we are going all stupid and rigid about it, and totally loosing > the interest of our users from our minds. I don't think so. Getting the patch upstream has several reasons IMHO: 1) We're applying an opensource scheme: "if you're making changes, send feedback upstream so that everyone can benefit of it". We're not willing to fork the Linux kernel and make a "Debian kernel", are we? 2) Getting the patch upstream allows upstream kernel hackers to review it. This is of real interest to our users, since we ensure that they will have a verified and accepted (read: supported) kernel. Forking the kernel would actually be missing the interest of our users. BTW, IMHO that last sentence also applies WRT negative diffs (read: removing files)... I know that we've been having kernel packages rather "different" than pristing source (at least for 2.4), and I'm not quite sure that is a Good Thing (tm), especially when it comes to arch-dependent bits. (who said hppa patch was 700k+? ;) > So what if it is a monolitic patch ? The kernel-patch package gets first > prepared, uploaded to svn, and built and uploaded to the archive. Our > users wouldn't care less if the patch is monolitic or lot of small > files, but they do benefit from having an amd64 kernel. Once that is > done, it is easy enough to modify the patch by splitting it or whatever, > and merging stuff into the kernel-source package for later inclusion > into the main packages, but at least there will be a package available > now. I do agree that we need to provide our users with good software in a timely fashion. "Good" here means "good quality", and that's very important as well. Greetings, Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/
Re: kernel-patch-amd64
Hi, [EMAIL PROTECTED] writes: > "Me Og. Og wget. Og package. Og upload. Og no read. Og maintainer." YMMD :) Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-patch-amd64
Hi, [EMAIL PROTECTED] writes: > > [..] prepare kernel-patch-amd64-2.6.7 packages > > Bad idea. Split the patch and get as much as possible merged upstream. Of course, sorry for omitting it. Still, a kernel-patch package should be prepared. Thing is, the kernel-patch source package for powerpc that I mentioned as an example also creates the kernel-image binary packages. So even if the patch was completely empty, the package would still serve a very valid purpose. BTW, hppa does it in a different way, having separate source packages kernel-patch-hppa and kernel-image-hppa. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Open a discussion about bug 253324
On Wed, Jun 30, 2004 at 03:28:21AM -0400, Andres Salomon wrote: > On Wed, 30 Jun 2004 08:32:43 +0200, Sven Luther wrote: > [...] > > Notice that Christoph did close this bug report without even bothering > > to discuss this, thus taking the decision from the team and into his own > > hands. Christoph, could you please justify your actions here ? They may > > be right and all, but if we are going to work out as a team, we need to > > discuss things. > > > > Friendly, > > > > Sven Luther > > He didn't close it; he tagged in +wontfix. He mentioned his reasoning > (the fact that there's userspace graphical boot screens), but it's not > apparent due to the way the BTS works. FYI, Christoph, people will > usually email @bugs.debian.org, and BCC [EMAIL PROTECTED], w/ > that same email body; [EMAIL PROTECTED] processes the commands, and > sending to @bugs.debian.org means the message shows up on the main > page of the bug report. I'd also recommend CC'ing > [EMAIL PROTECTED], so that the original submitter sees the > update and can respond in a timely fashion. Don't ask me why the BTS > doesn't automatically forward responses to the submitter; that would seem > to be the logic thing to do. :/ Ah, i guess that those new non-debian kernel maintainers should probably be submitted to the debian NM process, after all, nobody else with such say on what happens with debian is not. > If the kernel team disagrees, they can follow up to the bug, change the > tag, etc. I can't say I disagree; I quickly scanned the patch, and it > definitely could've been pared down a bit. I probably don't disagree, i only disagree with the dictatorial method, while this was supposed to be a team. Friendly, Sven Luther
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 08:24:56AM +0100, [EMAIL PROTECTED] wrote: > On Wed, Jun 30, 2004 at 09:20:18AM +0200, Sven Luther wrote: > > > ... and you might want to check kernel changelogs before starting > > > moralizing of your own. > > > > What has your status as kernel maintainer have to do with the > > maintainance of the dbeian-kernel packages, and how debian handles this ? > > It has something with the amount of cleanups being done and, excuse me, > certain experience with the results of different approaches to said > cleanups. So, we should immeditely remove all the extraneous patches, and ship only the pristine upstream source ? > If you have an axe to grind with me, Christoph, "purists" or somebody > stiffling your flexibility, whatever that might mean - feel free to > take it offlist. Why offlist, this is most certainly on topic, since it defines the way debian is going to threat the kernel package. > If you have any technical arguments, you are welcome to make them (starting > with that thing called "point"). Well, and what point have you made, apart from the "It should be split and merged upstream before it goes into debian kernel packages", which is hardly realist and maybe tainted with your other responsabilities as kernel packager. I just ask that we put aside this rigidity and be a bit flexible about this. If the amd64 patches are going to be split and merged upstream, what harm is there in making the monolitic patch available to our users in the meantime ? And sorry, upto now, your only arguments where dogma, white space and the monolitic nature of the patch. Friendly, Sven Luther
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 09:08:18AM +0200, Thibaut VARENE wrote: > On Wed, 30 Jun 2004 08:30:05 +0200 > "Sven Luther" <[EMAIL PROTECTED]> wrote: > > > On Tue, Jun 29, 2004 at 11:14:02PM +0100, [EMAIL PROTECTED] wrote: > > > On Tue, Jun 29, 2004 at 06:23:21PM +0200, Jens Schmalzing wrote: > > > > I would suggest that you subscribe to debian-kernel, prepare > > > > kernel-patch-amd64-2.6.7 packages based on the example of the other > > > > 2.6 kernel-patch packages (right now, this means the powerpc patches, > > > > so please let me know if you find a better way of doing it) , and > > > > upload them as soon as amd64 enters sid. > > > > > > Bad idea. Split the patch and get as much as possible merged upstream. > > > Note that large parts are simply "Lindent that file" and they certainly > > > should not be mixed with the rest. > > > > And ? Is that incompatible with making a kernel-patch-amd64 package and > > building a kernel from it ? > > > > What i really dislike about this politic of submitting stuff upstream, > > is that we are going all stupid and rigid about it, and totally loosing > > the interest of our users from our minds. > > I don't think so. > Getting the patch upstream has several reasons IMHO: And where did i say it should not go upstream ? The only thing i am saying is that _IN THE MEANTIME_ there is nothing stopping us from releasing a kernel-patch-amd64 so users can benefit and test, while we do the splitting and merging job behind the scene. > 1) We're applying an opensource scheme: "if you're making changes, send > feedback upstream so that everyone can benefit of it". We're not willing > to fork the Linux kernel and make a "Debian kernel", are we? Who took that decision ? And even then, how would it be all that different from the many alternative trees out there, like the -mm one Christoph refered to me recently. Nothing is stoping us from presenting usefull stuff to our unstable users while we are still working on it, is this not how free software works ? > 2) Getting the patch upstream allows upstream kernel hackers to review > it. This is of real interest to our users, since we ensure that they > will have a verified and accepted (read: supported) kernel. Except that it doesn't always work, often the upstream kernel hackers don't even care to read the patch and you wait forever for comments. > Forking the kernel would actually be missing the interest of our users. > BTW, IMHO that last sentence also applies WRT negative diffs (read: > removing files)... Stop being stupid and actually read what i said, and not what you think i am saynig. I am not speaking about forking, but about making the in development stages available to our users, and seriously to a compiled kernel-image user which is what we are speaking about here, the monoliticness or amount of white space is hardly a consideration. > I know that we've been having kernel packages rather "different" than > pristing source (at least for 2.4), and I'm not quite sure that is a > Good Thing (tm), especially when it comes to arch-dependent bits. (who > said hppa patch was 700k+? ;) Well, and ? What is the problem with that, and more importantly, how is this relevant to the topic at hand. I am _NOT_ against merging stuff upstream, on the contrary, but am just saying that we should also make the intermediary steps available to our users while we work on it, a bit like you kernel guys make the bitkeeper repo available, and are not stopping people from compiling those versions. The main difference is that debian deals with compiled binaries, and not with source only releases. > > So what if it is a monolitic patch ? The kernel-patch package gets first > > prepared, uploaded to svn, and built and uploaded to the archive. Our > > users wouldn't care less if the patch is monolitic or lot of small > > files, but they do benefit from having an amd64 kernel. Once that is > > done, it is easy enough to modify the patch by splitting it or whatever, > > and merging stuff into the kernel-source package for later inclusion > > into the main packages, but at least there will be a package available > > now. > > I do agree that we need to provide our users with good software in a > timely fashion. "Good" here means "good quality", and that's very > important as well. Well, and how do you weight software which is available and of average quality over software which is perfect but unavailable ? I still feel that all you kernel gurus, apart from being less than polite to the remaining of the debian-kernel team in general, don't have a real feel of what is important for debian. Hell, most of you didn't even pass the debian maintainer process, and you would dictate to us how things should be going ? Friendly, Sven Luther
Re: Open a discussion about bug 253324
On Wed, 30 Jun 2004 08:32:43 +0200, Sven Luther wrote: [...] > Notice that Christoph did close this bug report without even bothering > to discuss this, thus taking the decision from the team and into his own > hands. Christoph, could you please justify your actions here ? They may > be right and all, but if we are going to work out as a team, we need to > discuss things. > > Friendly, > > Sven Luther He didn't close it; he tagged in +wontfix. He mentioned his reasoning (the fact that there's userspace graphical boot screens), but it's not apparent due to the way the BTS works. FYI, Christoph, people will usually email @bugs.debian.org, and BCC [EMAIL PROTECTED], w/ that same email body; [EMAIL PROTECTED] processes the commands, and sending to @bugs.debian.org means the message shows up on the main page of the bug report. I'd also recommend CC'ing [EMAIL PROTECTED], so that the original submitter sees the update and can respond in a timely fashion. Don't ask me why the BTS doesn't automatically forward responses to the submitter; that would seem to be the logic thing to do. :/ If the kernel team disagrees, they can follow up to the bug, change the tag, etc. I can't say I disagree; I quickly scanned the patch, and it definitely could've been pared down a bit.
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 09:20:18AM +0200, Sven Luther wrote: > > ... and you might want to check kernel changelogs before starting > > moralizing of your own. > > What has your status as kernel maintainer have to do with the > maintainance of the dbeian-kernel packages, and how debian handles this ? It has something with the amount of cleanups being done and, excuse me, certain experience with the results of different approaches to said cleanups. If you have an axe to grind with me, Christoph, "purists" or somebody stiffling your flexibility, whatever that might mean - feel free to take it offlist. If you have any technical arguments, you are welcome to make them (starting with that thing called "point").
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 08:06:46AM +0100, [EMAIL PROTECTED] wrote: > On Wed, Jun 30, 2004 at 09:01:23AM +0200, Sven Luther wrote: > > > BTW, who are you anyway who don't sign your messages and which i have > > never seen here before ? > > Al Viro... Ok, i have seen in the meantime you posted 3 times here already. > > And your help to cleanup said patches are > > welcome, instead of your moralizing speaches from up there. > > ... and you might want to check kernel changelogs before starting > moralizing of your own. What has your status as kernel maintainer have to do with the maintainance of the dbeian-kernel packages, and how debian handles this ? This is the thing you, not Christoph also, don't understand. The whole aim of you participating here is to make things easier, not dictating what should or should not go into the debian kernel, and stiffling flexibility like you are trying to do. Friendly, Sven Luther
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 09:01:23AM +0200, Sven Luther wrote: > BTW, who are you anyway who don't sign your messages and which i have > never seen here before ? Al Viro... > And your help to cleanup said patches are > welcome, instead of your moralizing speaches from up there. ... and you might want to check kernel changelogs before starting moralizing of your own.
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 07:47:10AM +0100, [EMAIL PROTECTED] wrote: > On Wed, Jun 30, 2004 at 08:30:05AM +0200, Sven Luther wrote: > > > Bad idea. Split the patch and get as much as possible merged upstream. > > > Note that large parts are simply "Lindent that file" and they certainly > > > should not be mixed with the rest. > > > > And ? Is that incompatible with making a kernel-patch-amd64 package and > > building a kernel from it ? > > > > What i really dislike about this politic of submitting stuff upstream, > > is that we are going all stupid and rigid about it, and totally loosing > > the interest of our users from our minds. > > WTF does it have to do with interest of our users? Well, i don't know about the amd64 situation, but basically it goes like that : This feature/port/whatever is not in the nice situation we want it (not splitted patch, or not everything is upstream yet, or whatever), so let's not package it yet, and wait that someone eventually cleans it up. In the meantime, the users are on their own. > > So what if it is a monolitic patch ? > > Simple fact that it makes maintaining it (as opposed to "Me Og. Og wget. > Og package. Og upload. Og no read. Og maintainer.") harder. And no, > I'm not implying that anyone involved in this thread is on that level. Sure, but what trouble it is, if there is already a existing monolitic patch, to make the result available to the general user, _while_ the cleanup is happening behing the scene, over not making it available while cleaning it up. And i really don't see what the best maintenance is if it is never released. > Have you reviewed the patch in question? Beyond "applies clean, might No, have you ? > even boot" stage, that is. Guess what - to do that you will need to > start with splitting it up, at least to see if e.g. msr.c part is > Lindent-only or there are actual changes in it. And, do we care ? We are not going to force that thing upstream as is or something such, we are just going to build the amd64 kernel-image with it, and while the users use it and make bug reports and such, hopefully getting the thing cleaned and split. After allm if it doesn't work, the maintainer will get the bug report and will have to deal with it, and none of the rest of us will be affected, but on the other side, if it works, the code will be there and the user will profit from it. > > So, don't forget, in the fight between user availablitiy and mostly > > cosmetic changes which won'ty be noticed by anyone apart from us, it is > > clear where the priority of debian goes, go reread the social contract > > if you are not convinced. > > Where does social contract say that blind, unreviewed use of code that > will run with maximal priveleges possible is in the interests of users? "Our priorities are our users and free software" This does speak nowhere that said code has to be in pristine conditions, and that a bunch of purist will withold the code from our users because of that, trying to force work on volunteers they are not willing to do themselves. BTW, who are you anyway who don't sign your messages and which i have never seen here before ? And your help to cleanup said patches are welcome, instead of your moralizing speaches from up there. Friendly, Sven Luther
Re: kernel-patch-amd64
On Wed, Jun 30, 2004 at 08:30:05AM +0200, Sven Luther wrote: > > Bad idea. Split the patch and get as much as possible merged upstream. > > Note that large parts are simply "Lindent that file" and they certainly > > should not be mixed with the rest. > > And ? Is that incompatible with making a kernel-patch-amd64 package and > building a kernel from it ? > > What i really dislike about this politic of submitting stuff upstream, > is that we are going all stupid and rigid about it, and totally loosing > the interest of our users from our minds. WTF does it have to do with interest of our users? > So what if it is a monolitic patch ? Simple fact that it makes maintaining it (as opposed to "Me Og. Og wget. Og package. Og upload. Og no read. Og maintainer.") harder. And no, I'm not implying that anyone involved in this thread is on that level. Have you reviewed the patch in question? Beyond "applies clean, might even boot" stage, that is. Guess what - to do that you will need to start with splitting it up, at least to see if e.g. msr.c part is Lindent-only or there are actual changes in it. > So, don't forget, in the fight between user availablitiy and mostly > cosmetic changes which won'ty be noticed by anyone apart from us, it is > clear where the priority of debian goes, go reread the social contract > if you are not convinced. Where does social contract say that blind, unreviewed use of code that will run with maximal priveleges possible is in the interests of users?
Re: Open a discussion about bug 253324
On Wed, Jun 30, 2004 at 09:17:59AM +1000, Andrew Pollock wrote: > On Tue, Jun 29, 2004 at 10:54:23PM +0200, Bluefuture wrote: > > I want to "open" a discussion about this bug on the debian-kernel > > mailing list: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253224 > > > > Ah yes. Herbert had quite strong views on what should and shouldn't be done > in the kernel, despite the fact that things existed in the kernel here and > now, and to implement the equivalent in userspace would require someone to > actually develop something... > > I thought the bootsplash stuff was a combination of kernelspace and > userspace anyway? > > I personally think having the kernel hooks to support the init.d stuff would > be good. It should then be trivial to have Debian boot with a bootsplash, > which is mainly cosmetic wank, but nice, nonetheless. Notice that Christoph did close this bug report without even bothering to discuss this, thus taking the decision from the team and into his own hands. Christoph, could you please justify your actions here ? They may be right and all, but if we are going to work out as a team, we need to discuss things. Friendly, Sven Luther
Re: kernel-patch-amd64
On Tue, Jun 29, 2004 at 11:14:02PM +0100, [EMAIL PROTECTED] wrote: > On Tue, Jun 29, 2004 at 06:23:21PM +0200, Jens Schmalzing wrote: > > Hi, > > > > Frederik Schueler writes: > > > > > Since the debian kernel packages now are being maintained by the > > > debian-kernel maintainers team, what is going to happen to these > > > inofficial packages once amd64 will enter sid? > > > > > > Do I have to ITP kernel-patch-amd64 and/or kernel-image-amd64? > > > > I would suggest that you subscribe to debian-kernel, prepare > > kernel-patch-amd64-2.6.7 packages based on the example of the other > > 2.6 kernel-patch packages (right now, this means the powerpc patches, > > so please let me know if you find a better way of doing it) , and > > upload them as soon as amd64 enters sid. > > Bad idea. Split the patch and get as much as possible merged upstream. > Note that large parts are simply "Lindent that file" and they certainly > should not be mixed with the rest. And ? Is that incompatible with making a kernel-patch-amd64 package and building a kernel from it ? What i really dislike about this politic of submitting stuff upstream, is that we are going all stupid and rigid about it, and totally loosing the interest of our users from our minds. So what if it is a monolitic patch ? The kernel-patch package gets first prepared, uploaded to svn, and built and uploaded to the archive. Our users wouldn't care less if the patch is monolitic or lot of small files, but they do benefit from having an amd64 kernel. Once that is done, it is easy enough to modify the patch by splitting it or whatever, and merging stuff into the kernel-source package for later inclusion into the main packages, but at least there will be a package available now. So, don't forget, in the fight between user availablitiy and mostly cosmetic changes which won'ty be noticed by anyone apart from us, it is clear where the priority of debian goes, go reread the social contract if you are not convinced. And BTW, is the svn server hosed or something ? I am able to refresh the debian-installer svn repository, but not the kernel one. Friendly, Sven Luther
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Wed, Jun 30, 2004 at 03:59:10PM +1000, Andrew Pollock wrote: > On Wed, Jun 30, 2004 at 07:45:25AM +0200, Sven Luther wrote: > > > > Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who > > is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). > > > > I believe now is the time to take that decision, it may even be too late > > already, given the sarge release schedule, and provided the GR doesn't > > finish in some catastrophic result for the sarge release. > > Well, AIUI, d-i should be able to on a per-arch basis default to a 2.6 > kernel. So we can have sarge release with a 2.6 kernel by default on > selected architectures. -boot may correct me. Well, the important thing is not so much -boot, but compatbility with the rest of userland, as well as upgrrades from woody with a 2.2 or 2.4 kernel to sarge with a 2.6 kernel. For example, i know that the XF86Config-4 file needs to be changed when using a ps2 mouse, since it was /dev/psaux previously, and is /dev/input/mice now. Breaking X during the upgrade is hardly acceptable if we are going to make 2.6 the default. > > (Still a bit pissed at the syntactic GR proponent who slyly passed this > > when nobody was noticing) > > Yes well, what's done is done. Learn from it. Yeah, never let your guard done, even if you are away, and hardly connected, and just got out of a month/year long GR over the non-free issue, even if they claimed it was syntactical changes only. I should have learned from the first tentative of Branden to get the non-free removal clause in on the sly. Friendly, Sven Luther
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Wed, Jun 30, 2004 at 07:45:25AM +0200, Sven Luther wrote: > > Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who > is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). > > I believe now is the time to take that decision, it may even be too late > already, given the sarge release schedule, and provided the GR doesn't > finish in some catastrophic result for the sarge release. Well, AIUI, d-i should be able to on a per-arch basis default to a 2.6 kernel. So we can have sarge release with a 2.6 kernel by default on selected architectures. -boot may correct me. > (Still a bit pissed at the syntactic GR proponent who slyly passed this > when nobody was noticing) Yes well, what's done is done. Learn from it. regards Andrew
Re: status of 2.6.7 ? (Was Re: Bug#256763: kernel-image-2.6.6-i386: not ready for sarge just yet)
On Wed, Jun 30, 2004 at 09:15:03AM +1000, Andrew Pollock wrote: > On Tue, Jun 29, 2004 at 09:40:15AM +0200, Sven Luther wrote: > > On Mon, Jun 28, 2004 at 11:55:19PM -0700, William Lee Irwin III wrote: > > > On Mon, Jun 28, 2004 at 04:10:32PM -0700, William Lee Irwin III wrote: > > > >> Sounds good. We should move to the 2.6.7 debs ASAP so this should keep > > > >> the thing out of people's hands until it's removed from the archives. > > > > > > On Tue, Jun 29, 2004 at 08:46:04AM +0200, Sven Luther wrote: > > > > Any news on the 2.6.7 debs ? It is again something like 2-3 weeks now > > > > since they where uploaded, isn't it ? > > > > Also, what is your opinion on going with 2.6 over 2.4 on certain arches > > > > by default ? I noticed nobody seemed to care about my mail on the > > > > subject. > > > > Friendly, > > > > Sven Luther > > > > > > It would be great to move to 2.6 in as many areas as possible. It's the > > > new stable kernel, and 2.4 is in a deep freeze, so we would make the > > > best use of maintenance effort that way. I think the only exceptions are > > > architecture ports not supported and/or working in 2.6 but that need 2.4 > > > or earlier to function. But this can only be a recommendation since I > > > only have the i386 and alpha packages. > > > > I wish to do the same for powerpc, but when i mentioned it here sunday > > evening, nobody responded at all. It has also an influence on how we > > threat bugs present in 2.4 and not in 2.6, Christoph wanted to close > > them or something such, and we can do this only if we are actively going > > to move to 2.6. > > AFAIK, there's one or two arches that haven't even got to 2.4 yet. I'm > pushing for all 2.2 kernel packages to get the boot from the archive, but I > think m68k has issues with 2.4. I think we're a long way away from universal > 2.6. Yeah, but what about 2.6 for powerpc and x86 (and maybe some other who is ready) and 2.4 for the rest of it (and 2.2 for some m68k subarches). I believe now is the time to take that decision, it may even be too late already, given the sarge release schedule, and provided the GR doesn't finish in some catastrophic result for the sarge release. (Still a bit pissed at the syntactic GR proponent who slyly passed this when nobody was noticing) Friendly, Sven Luther
