Re: Bits from the kernel team
On Wed, Dec 23, 2009 at 01:51:01AM +0100, Frans Pop wrote: The following change in /etc/init.d/nfs-kernel-server fixes this: # See if our running kernel supports the NFS kernel server - if [ -f /proc/kallsyms ] ! grep -qE 'init_nf(sd|)' /proc/kallsyms; then + if ! [ -d /sys/module/nfsd ]; then Only when nfsd is a module, not when it is compiled in: $ grep NFSD /boot/config-2.6.32.2 CONFIG_NFSD=y $ ls -dl /sys/module/nfs* drwxr-xr-x 3 root root 0 Dec 23 09:05 /sys/module/nfs $ Testing for /proc/fs/nfs/exports could probably work everywhere. Regards, Michael -- Michael GernothDepartment of Computer Science IV Martensstrasse 1 D-91058 Erlangen Germany University of Erlangen-Nuremberg http://www4.informatik.uni-erlangen.de/~gernoth/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
Michael Gernoth wrote: On Wed, Dec 23, 2009 at 01:51:01AM +0100, Frans Pop wrote: The following change in /etc/init.d/nfs-kernel-server fixes this: # See if our running kernel supports the NFS kernel server -if [ -f /proc/kallsyms ] ! grep -qE 'init_nf(sd|)' /proc/kallsyms; then +if ! [ -d /sys/module/nfsd ]; then Only when nfsd is a module, not when it is compiled in: $ grep NFSD /boot/config-2.6.32.2 CONFIG_NFSD=y $ ls -dl /sys/module/nfs* drwxr-xr-x 3 root root 0 Dec 23 09:05 /sys/module/nfs $ Right. Looks like that's already being discussed in #550153. Testing for /proc/fs/nfs/exports could probably work everywhere. That's mentioned in the BR as well. Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
Ben Hutchings wrote: On Wed, 2009-12-23 at 01:51 +0100, Frans Pop wrote: Ben Hutchings wrote: Currently you can install kernel images from unstable or backports without any extra dependencies. I'm not aware of any significant breakage though some packages may rely on deprecated and removed stuff in procfs or sysfs. I've been running upstream kernels without any problems on Lenny. The only issue I'm aware of is that the init script of nfs-kernel-server is not compatible with 2.6.32. The following change in /etc/init.d/nfs-kernel-server fixes this: # See if our running kernel supports the NFS kernel server -if [ -f /proc/kallsyms ] ! grep -qE 'init_nf(sd|)' /proc/kallsyms; then +if ! [ -d /sys/module/nfsd ]; then I made that change myself, how could I forget it?! That apparently breaks non-modular nfsd -- see #561674. /mjt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
On Mon, Dec 21, 2009 at 01:56:05AM +, Ben Hutchings wrote: On Mon, 2009-12-21 at 09:24 +0800, Paul Wise wrote: I guess oss4-dkms will be enough to take care of these users, hopefully it will reach squeeze in time. Hopefully not. OSS4 on Linux is part of the problem, not part of the solution. Linux applications should not use /dev/dsp any more. Those that do may be handled by some kind of bridge to ALSA, which was what Something CUSE based, for example, or one of the existing LD_PRELOAD hacks. Replacing the OSS emulation with something that throws the data back out to userspace would also work, I guess. this item refers to. (The existing snd-pcm-oss and snd-mixer-oss don't seem to be good enough.) Specifically since they are in kernel they don't (and can't really) play at all with any userspace ALSA stuff such as DSP, PulseAudio or the various network and wireless I/O drivers that are implemented in userspace. They also cause pain for the standard ALSA drivers since the mismatch between the OSS and ALSA configuration APIs results in ALSA drivers having to jump through hoops for the benefit of the OSS emulation, and the OSS configuration model is just too limited to express the control available on many modern systems. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
On Sun, Dec 20, 2009 at 04:50:22PM +, Ben Hutchings wrote: On Sun, 2009-12-20 at 17:22 +0100, Kurt Roeckx wrote: Hi, Now that we have a 2.6.32 kernel in unstable, can you updates us on the various things mentioned in this mail? For instance, as I understand it, most other distro's recently had a release with a 2.6.31 kernel? Fedora 12, Ubuntu 9.10 and openSUSE 11.2 have this kernel version. Do you know if there are plans to have a kernel with backported drivers, one used by multiple distributions? I've not heard of a general plan for that. However there is a compat-wireless project (covering Wifi and Bluetooth drivers) that I think Fedora and Ubuntu are pulling from. That might be something we should do too. For etch we had an Etch-And-A-Half kernel to add support for new hardware. Which also meant we had to upgrade some things because the kernel has the habbit of breaking things. I don't know if there are simular plans for lenny? Anyway what I would really like to see is a kernel that adds support for more hardware and fixes bugs without any other changes. I believe that 2.6.16.x was supposed to do that, but in the end only contained bug fixes. And they now seem to have various versions for which they fix bugs. But this doesn't solve our problem that by the time we release our kernel is probably outdated already for new hardware. And this is about more than just wifi and bluetooth. I was hoping that various distributions could work together to have long time support for 1 kernel version that adds new hardware support. Where that would be atleast some time after squeeze+1 is released. Since the other distro's used a 2.6.31 kernel recently, and we seem to be going for 2.6.32(?), it seems unlikely that we can get all to work on 1 such kernel version. But maybe we should look at what the enterprise versions will be using instead? Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
On Tue, Dec 22, 2009 at 07:39:22PM +0100, Kurt Roeckx wrote: On Sun, Dec 20, 2009 at 04:50:22PM +, Ben Hutchings wrote: On Sun, 2009-12-20 at 17:22 +0100, Kurt Roeckx wrote: Fedora 12, Ubuntu 9.10 and openSUSE 11.2 have this kernel version. I was hoping that various distributions could work together to have long time support for 1 kernel version that adds new hardware support. Where that would be atleast some time after squeeze+1 is released. Since the other distro's used a 2.6.31 kernel recently, and we seem to be going for 2.6.32(?), it seems unlikely that we can get all to work on 1 such kernel version. But maybe we should look at what the enterprise versions will be using instead? Fedora and Ubuntu both do 6-monthly releases, and are certainly not supported for a long time by Debian standards. Ubuntu 10.04 LTS and RHEL 6 are both expected in the first half of 2010[1]. Ubuntu 10.04 LTS will be shipping 2.6.32, and my understanding (based on discussions at LPC) is that RHEL 6 will as well; and 2.6.32 will have extended upstream support, including support for new hardware. So this look at the enterprise versions was already done, and is what resulted in picking 2.6.32. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] http://www.h-online.com/open/news/item/Red-Hat-Summit-videos-presentations-and-outlook-for-RHEL6-743323.html signature.asc Description: Digital signature
Re: Bits from the kernel team
On Sun, Dec 20, 2009 at 16:50:22 +, Ben Hutchings wrote: The X packages will be able to use modprobe config files to enable KMS at run time as required. This is not for the kernel team to do. FWIW, this is done for intel in experimental, probably soon in unstable. For radeon the decision whether to enable kernel mode setting by default for squeeze is still to be made. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
On Tue, 2009-12-22 at 19:39 +0100, Kurt Roeckx wrote: On Sun, Dec 20, 2009 at 04:50:22PM +, Ben Hutchings wrote: On Sun, 2009-12-20 at 17:22 +0100, Kurt Roeckx wrote: Hi, Now that we have a 2.6.32 kernel in unstable, can you updates us on the various things mentioned in this mail? For instance, as I understand it, most other distro's recently had a release with a 2.6.31 kernel? Fedora 12, Ubuntu 9.10 and openSUSE 11.2 have this kernel version. Do you know if there are plans to have a kernel with backported drivers, one used by multiple distributions? I've not heard of a general plan for that. However there is a compat-wireless project (covering Wifi and Bluetooth drivers) that I think Fedora and Ubuntu are pulling from. That might be something we should do too. For etch we had an Etch-And-A-Half kernel to add support for new hardware. Which also meant we had to upgrade some things because the kernel has the habbit of breaking things. I don't know if there are simular plans for lenny? No, this would have had to be planned for in the middle of this year, but then we were told squeeze would freeze in December. Currently you can install kernel images from unstable or backports without any extra dependencies. I'm not aware of any significant breakage though some packages may rely on deprecated and removed stuff in procfs or sysfs. Anyway what I would really like to see is a kernel that adds support for more hardware and fixes bugs without any other changes. We already do backport new hardware support in response to specific requests. I believe that 2.6.16.x was supposed to do that, but in the end only contained bug fixes. And they now seem to have various versions for which they fix bugs. Right, and 2.6.32 will be one of them. But this doesn't solve our problem that by the time we release our kernel is probably outdated already for new hardware. And this is about more than just wifi and bluetooth. I was hoping that various distributions could work together to have long time support for 1 kernel version that adds new hardware support. Where that would be atleast some time after squeeze+1 is released. Since the other distro's used a 2.6.31 kernel recently, and we seem to be going for 2.6.32(?), it seems unlikely that we can get all to work on 1 such kernel version. We talked to the Ubuntu kernel team and the plan is that Ubuntu 10.04 LTS will also use 2.6.32. But maybe we should look at what the enterprise versions will be using instead? RHEL 6 is due real soon now. I hope they will also go with 2.6.32, but RH is keeping very quiet about such specifics. SLE 11 is not that old so I don't expect SUSE will use this version. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: Bits from the kernel team
Ben Hutchings wrote: Currently you can install kernel images from unstable or backports without any extra dependencies. I'm not aware of any significant breakage though some packages may rely on deprecated and removed stuff in procfs or sysfs. I've been running upstream kernels without any problems on Lenny. The only issue I'm aware of is that the init script of nfs-kernel-server is not compatible with 2.6.32. The following change in /etc/init.d/nfs-kernel-server fixes this: # See if our running kernel supports the NFS kernel server - if [ -f /proc/kallsyms ] ! grep -qE 'init_nf(sd|)' /proc/kallsyms; then + if ! [ -d /sys/module/nfsd ]; then Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
Kurt Roeckx wrote: Now that we have a 2.6.32 kernel in unstable, can you updates us on the various things mentioned in this mail? I have another question. The naming policy for linux-image packages seems to have changed: instead of an ABI we now have trunk. First I thought this was a bug, but now that meta packages have been updated to use trunk too that seems unlikely. I've not seen any announcement for this, nor any discussion on how this may affect other packages (such as packages building out of tree modules and Debian Installer). I've always considered the fact that a kernel update with a different ABI did not replace the current kernel an important feature (reducing the need for an immediate reboot). Are we no longer interested in the ABI? What will happen during/after upgrades if the ABI does change? Would someone care to explain to the rest of the project? Cheers, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
On Wed, 2009-12-23 at 01:51 +0100, Frans Pop wrote: Ben Hutchings wrote: Currently you can install kernel images from unstable or backports without any extra dependencies. I'm not aware of any significant breakage though some packages may rely on deprecated and removed stuff in procfs or sysfs. I've been running upstream kernels without any problems on Lenny. The only issue I'm aware of is that the init script of nfs-kernel-server is not compatible with 2.6.32. The following change in /etc/init.d/nfs-kernel-server fixes this: # See if our running kernel supports the NFS kernel server - if [ -f /proc/kallsyms ] ! grep -qE 'init_nf(sd|)' /proc/kallsyms; then + if ! [ -d /sys/module/nfsd ]; then I made that change myself, how could I forget it?! Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: Bits from the kernel team
On Wed, 2009-12-23 at 01:57 +0100, Frans Pop wrote: Kurt Roeckx wrote: Now that we have a 2.6.32 kernel in unstable, can you updates us on the various things mentioned in this mail? I have another question. The naming policy for linux-image packages seems to have changed: instead of an ABI we now have trunk. First I thought this was a bug, but now that meta packages have been updated to use trunk too that seems unlikely. The error was in uploading 2.6.32-rc8 to unstable rather than experimental as was intended. Following that, we could only move forward to 2.6.32 even though we have not stabilised its configurations and the resulting ABIs. I've not seen any announcement for this, nor any discussion on how this may affect other packages (such as packages building out of tree modules and Debian Installer). I've always considered the fact that a kernel update with a different ABI did not replace the current kernel an important feature (reducing the need for an immediate reboot). Are we no longer interested in the ABI? What will happen during/after upgrades if the ABI does change? Would someone care to explain to the rest of the project? Once we are finished with major changes to 2.6.32 (such as the libata transition) the ABI version will change from 'trunk' to '1' and we will then try to avoid unnecessary ABI changes. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: Bits from the kernel team
Hi, Now that we have a 2.6.32 kernel in unstable, can you updates us on the various things mentioned in this mail? For instance, as I understand it, most other distro's recently had a release with a 2.6.31 kernel? Do you know if there are plans to have a kernel with backported drivers, one used by multiple distributions? Kurt On Mon, Oct 19, 2009 at 10:54:47PM +0100, Vincent Sanders wrote: The Debian Kernel team recently had a series of face to face meetings during the Linux Plumbers Conference [1]. The DPL managed to arrange for the whole team to be present in Oregon at the same time, a representative of the release team was also present. The LPC conference venue allowed the kernel team to interact with the upstream developers and other distributions kernel teams in an positive and productive way. The Debian kernel team meetings ran over four days and covered a large number of topics, the abridged minutes are presented here, the full meeting minutes are also available [2]. Co-operation and version synchronisation with other distributions - This discussion involved timing of the Debian freeze and what implications this might have on the kernel version selected for squeeze. The version selected by other distributions was also discussed. In conclusion the 2.6.32 release will probably be the initial kernel version shipped with squeeze. Separate firmware, what is left to do? -- A constructive discussion was held about the outstanding firmware issues, how the team addresses them and how we might work with upstream to address our DSFG issues with kernel sources. Kernel Mode Setting transition -- It was resolved that KMS will be enabled at build time but disabled at run time by default. The X packages will be able to use modprobe config files to enable KMS at run time as required. Feature patches --- These are patches the Debian kernels have for major features which are not upstream. openvz ++ Debian will continue to support this system with assistance from the openvz developers. rt patchset +++ This is apparently not ready for production use and will not be present in Debian kernels. vserver +++ This feature will be present in squeeze but will be marked as deprecated and a migration path to Linux containers investigated. xen dom 0 + This feature will be included in the squeeze kernel release subject to ongoing stabilisation work. The feature will be marked as deprecated and will not appear in future releases. IDE to libata decision -- Debian will perform this transition using the udev packages in a similar way to Ubuntu. The Ubuntu developers have offered their assistance with this transition. preemption -- This feature will be enabled for the squeeze release. OSS --- This has been a deprecated kernel interface for some time and will be disabled for squeeze with mechanisms put in place to deal with legacy users. bug triage and tagging -- The kernel team has a large number of bugs, many of which contain inadequate information. The team decided that a policy for bugs and patches will be produced and enforced. We will also be improving the bug reporting by improving the reportbug usage. Moving the Debian Kernel packaging to Git - A robust discussion happened with several views and ideas expressed. The final outcome was that the team as a whole favoured the move to git and that further investigation and implementation would occur. Coordination with release team and D-I -- Several issues were covered the main item from this session was an investigation as to if udeb generation should be merged with the main kernel source package. Out of tree modules --- After some discussion it was resolved to remove linux-modules-extra and -nonfree as they are an impossible to support properly. A few modules the project really must have will be placed directly into the linux-2.6 source The kernel team will endorse the use of dkms as a way for out-of-tree module maintainers to get their modules auto-built. Leveraging upstream .deb building - This became a discussion about the general kernel packaging and how we might use the upstream provided facilities better. There was some discussion we have way too many ways to build a kernel. We will be rationalising this to two methods, an upstream merged make deb-pkg target and the linux-2.6 Debian source. We will also be rationalising the kernel postinst and co-ordinating our efforts with the Ubuntu developers. New lists to co-ordinate There is
Re: Bits from the kernel team
On Sun, 2009-12-20 at 17:22 +0100, Kurt Roeckx wrote: Hi, Now that we have a 2.6.32 kernel in unstable, can you updates us on the various things mentioned in this mail? For instance, as I understand it, most other distro's recently had a release with a 2.6.31 kernel? Fedora 12, Ubuntu 9.10 and openSUSE 11.2 have this kernel version. Do you know if there are plans to have a kernel with backported drivers, one used by multiple distributions? I've not heard of a general plan for that. However there is a compat-wireless project (covering Wifi and Bluetooth drivers) that I think Fedora and Ubuntu are pulling from. That might be something we should do too. I'm also keen to pull in nouveau if the X maintainers are happy with that. Kernel Mode Setting transition -- It was resolved that KMS will be enabled at build time but disabled at run time by default. Done. The X packages will be able to use modprobe config files to enable KMS at run time as required. This is not for the kernel team to do. Feature patches --- These are patches the Debian kernels have for major features which are not upstream. openvz ++ Debian will continue to support this system with assistance from the openvz developers. In progress, I believe. rt patchset +++ This is apparently not ready for production use and will not be present in Debian kernels. vserver +++ This feature will be present in squeeze but will be marked as deprecated and a migration path to Linux containers investigated. Don't know. xen dom 0 + This feature will be included in the squeeze kernel release subject to ongoing stabilisation work. The feature will be marked as deprecated and will not appear in future releases. In progress. IDE to libata decision -- Debian will perform this transition using the udev packages in a similar way to Ubuntu. The Ubuntu developers have offered their assistance with this transition. Since we also have a wide variety of bootloaders to update, we now intend to do this separately from udev. I have written an update script (written in Perl) which I will be sending out for review shortly. preemption -- This feature will be enabled for the squeeze release. OSS --- This has been a deprecated kernel interface for some time and will be disabled for squeeze Done. with mechanisms put in place to deal with legacy users. Er, not sure. bug triage and tagging -- The kernel team has a large number of bugs, many of which contain inadequate information. The team decided that a policy for bugs and patches will be produced and enforced. We will also be improving the bug reporting by improving the reportbug usage. See http://lists.debian.org/debian-kernel/2009/11/msg00114.html. This still needs to be incorporated into the kernel handbook. Moving the Debian Kernel packaging to Git - A robust discussion happened with several views and ideas expressed. The final outcome was that the team as a whole favoured the move to git and that further investigation and implementation would occur. Still to do; I think this may have to be post-squeeze. Coordination with release team and D-I -- Several issues were covered the main item from this session was an investigation as to if udeb generation should be merged with the main kernel source package. No change as yet. Out of tree modules --- After some discussion it was resolved to remove linux-modules-extra and -nonfree as they are an impossible to support properly. A few modules the project really must have will be placed directly into the linux-2.6 source The kernel team will endorse the use of dkms as a way for out-of-tree module maintainers to get their modules auto-built. Done. Leveraging upstream .deb building - This became a discussion about the general kernel packaging and how we might use the upstream provided facilities better. There was some discussion we have way too many ways to build a kernel. We will be rationalising this to two methods, an upstream merged make deb-pkg target and the linux-2.6 Debian source. Done. We will also be rationalising the kernel postinst and co-ordinating our efforts with the Ubuntu developers. In progress. Debug Packages -- This refers to debugging information from current packages, not a separate configuration, useful for crash tools. This will be investigated further. Not done. Automated build and test This might be a useful tool in the future and work is ongoing. Don't know. Experimental Some upload experimental
Re: Bits from the kernel team
On Mon, Dec 21, 2009 at 12:50 AM, Ben Hutchings b...@decadent.org.uk wrote: OSS --- This has been a deprecated kernel interface for some time and will be disabled for squeeze Done. with mechanisms put in place to deal with legacy users. Er, not sure. I guess oss4-dkms will be enough to take care of these users, hopefully it will reach squeeze in time. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
On Mon, 2009-12-21 at 09:24 +0800, Paul Wise wrote: On Mon, Dec 21, 2009 at 12:50 AM, Ben Hutchings b...@decadent.org.uk wrote: OSS --- This has been a deprecated kernel interface for some time and will be disabled for squeeze Done. with mechanisms put in place to deal with legacy users. Er, not sure. I guess oss4-dkms will be enough to take care of these users, hopefully it will reach squeeze in time. Hopefully not. OSS4 on Linux is part of the problem, not part of the solution. Linux applications should not use /dev/dsp any more. Those that do may be handled by some kind of bridge to ALSA, which was what this item refers to. (The existing snd-pcm-oss and snd-mixer-oss don't seem to be good enough.) Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Bits from the kernel team
Le lundi 19 octobre 2009 à 22:54 +0100, Vincent Sanders a écrit : IDE to libata decision -- Debian will perform this transition using the udev packages in a similar way to Ubuntu. The Ubuntu developers have offered their assistance with this transition. When is this change planned? We discovered that DeviceKit doesn’t handle IDE CDs properly and the DK migration will have to be backed out unless this transition happens soon. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bits from the kernel team
On Mon, 19 Oct 2009 22:54:47 +0100 Vincent Sanders vi...@kyllikki.org wrote: A constructive discussion was held about the outstanding firmware issues, how the team addresses them and how we might work with upstream to address our DSFG issues with kernel sources. By chance, did any of that discussion touch on patching drivers so that they can load without the firmware? Many Eee PC owners currently have no DFSG-free option for wifi (short of replacing the card) because rt2860sta depends on a non-free firmware. Some months ago I had a discussion on irc with some members of the rt2x00 project about this problem. I discovered then that: 1. They expressed no interest in putting any more work into the legacy vendor-supplied rt2860sta driver that is in the current Squeeze kernel and were instead focusing efforts on rt2x00. (Unfortunately, rt2x00 will almost certainly not be ready for 2.6.32, so I'm hoping someone else will be willing to help with rt2860sta for Squeeze.) 2. They thought that all that without the firmware, users would really miss would be some non-essential features like power management. 3. They thought it would be possible, and perhaps even essential to deal with certain boards, to make rt2x00 work without the firmware. 4. However, a quick test: just tearing out the call to load it, caused the driver to fail with a kernel panic. The Debian Eee PC project would love to see Squeeze release with DFSG support for as much Eee PC hardware as possible, so if anyone can assist with supporting this chipset without the firmware for the Squeeze release, we'd like to hear from you. Ben -- ,-. nSLUGhttp://www.nslug.ns.ca sy...@sanctuary.nslug.ns.ca \`' Debian http://www.debian.orgsy...@debian.org ` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ] signature.asc Description: PGP signature
Re: Bits from the kernel team
On Tue, Oct 20, 2009 at 07:51:20AM -0300, Ben Armstrong wrote: On Mon, 19 Oct 2009 22:54:47 +0100 Vincent Sanders vi...@kyllikki.org wrote: A constructive discussion was held about the outstanding firmware issues, how the team addresses them and how we might work with upstream to address our DSFG issues with kernel sources. By chance, did any of that discussion touch on patching drivers so that they can load without the firmware? Many Eee PC owners currently have no DFSG-free option for wifi (short of replacing the card) because rt2860sta depends on a non-free firmware. Some months ago I had a discussion on irc with some members of the rt2x00 project about this problem. I discovered then that: 1. They expressed no interest in putting any more work into the legacy vendor-supplied rt2860sta driver that is in the current Squeeze kernel and were instead focusing efforts on rt2x00. (Unfortunately, rt2x00 will almost certainly not be ready for 2.6.32, so I'm hoping someone else will be willing to help with rt2860sta for Squeeze.) The rt2860sta driver is effectively being maintained by Bartlomiej Zolnierkiewicz bzoln...@gmail.com. 2. They thought that all that without the firmware, users would really miss would be some non-essential features like power management. I find this hard to believe. 3. They thought it would be possible, and perhaps even essential to deal with certain boards, to make rt2x00 work without the firmware. [...] If someone can make that work, and if that change is accepted upstream, then the kernel team can probably apply it to the version in squeeze. But we do not normally apply patches without upstream review (DFSG-compliance has been an exception, but I'm feeding those patches upstream as well), and we do not carry out significant development of our own (at least, not in our Debian roles). Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
Hi, Vincent and others,
On Oct 19 2009, Vincent Sanders wrote:
IDE to libata decision
--
Debian will perform this transition using the udev packages in a
similar way to Ubuntu. The Ubuntu developers have offered their
assistance with this transition.
There are some blocking bugs that still need to be worked on, really.
For instance, I have here a pdc controller whose ide driver works
flawlessly, but for which the corresponding libata driver is not really
ready for prime time.
http://lkml.org/lkml/2009/4/20/211
http://lkml.org/lkml/2009/4/20/311
http://lkml.org/lkml/2009/4/20/298
http://lkml.org/lkml/2009/4/20/319
http://lkml.org/lkml/2009/4/23/611
http://lkml.org/lkml/2009/5/1/53
http://lkml.org/lkml/2009/5/11/452
The Linux IDE people are amazingly great, but some bugs are still there.
This one persists, in particular. :-(
It's very visible with Ubuntu's kernel for many releases (since it uses
libata). The way that I'm working with that computer is that I'm
hand-compiling my own kernels, for the moment, but I'm not always there
to support my parents using it and the distribution kernels don't work
satisfactorily. (Unfortunately).
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the kernel team
Quoting Bastian Blank ([EMAIL PROTECTED]): Hi, Half-way between the sarge release and the etch freeze the Debian kernel Aren't we closer from etch freeze than sarge release? :-) This is at least my feeling when I consider the packages and the proejcts I'm part of: we, developers, should begin to put ourselves in release mode.now. signature.asc Description: Digital signature
