[arch-dev-public] [signoff] udev-147-1
Hi Major changes: - Minimal kernel version bumped to 2.6.27: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=1da6c797fdbb94372... - Older kernels than 2.6.31 might need the udev-compat package: Most NAME= instructions got removed. Kernel 2.6.31 supplies the needed names if they are not the default. To support older kernels, the NAME=rules need to be added to the compat rules file. Other changes: To support DEVPATH strings larger than the maximum file name length, the private udev database format has changed. If some software still reads the private files in /dev/.udev/, which it shouldn't, now it's time to fix it. Please do not port anything to the new format again, everything in /dev/.udev is and always was private to udev, and may and will change any time without prior notice. Multiple devices claiming the same names in /dev are limited to symlinks only now. Mixing identical symlink names and node names is not supported. This reduces the amount of data in the database significantly. NAME="%k" causes a warning now. It's is and always was completely superfluous. It will break kernel supplied DEVNAMEs and therefore it needs to be removed from all rules. Symlinks to udevadm with the old command names are no longer resolved to the udevadm commands. The udev-acl tool got adopted to changes in ConsoleKit. Version 0.4.11 is required now. The option "last_rule" does no longer exist. Its use breaks too many things which expect to be run from independent later rules, and is an idication that something needs to be fixed properly instead. The gudev API is no longer marked as experimental, G_UDEV_API_IS_SUBJECT_TO_CHANGE is no longer needed. The gudev introspection is enabled by default now. Various projects already depend on introspection information to bind dynamic languages to the gudev interfaces. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Tried the pkg on my laptop and on my LTS driven server. No problems so far. With the new udev-compat pkg the custom rule for usb printers isn't needed anymore. "lp" group permission is set properly even after printer power off and on again. I will rebuild the LTS server pkg and make it depend on the udev-compat pkg now. Please move it then along with udev from testing to core after signoff procedure. signoff x86_64 :) -Andy
with more major changes... -Andy
Am Wed, 2 Dec 2009 21:50:17 +0100 schrieb Andreas Radke <a.radke@arcor.de>:
with more major changes...
-Andy
and 149 is out. Just a question: is our early boot stuff and kernel part well enough maintained right now? I often see Tobias and Thomas away for longer periods these days. -Andy
On Thu, Dec 3, 2009 at 12:09 PM, Andreas Radke <a.radke@arcor.de> wrote:
Am Wed, 2 Dec 2009 21:50:17 +0100 schrieb Andreas Radke <a.radke@arcor.de>:
with more major changes...
-Andy
and 149 is out.
Just a question: is our early boot stuff and kernel part well enough maintained right now? I often see Tobias and Thomas away for longer periods these days.
Well, yes and no. We want to get rid of klibc and just stick glibc in the image, and that's a big project that's on the plate. What are you worried about specifically? The klibc build udev?
Am Thu, 3 Dec 2009 12:30:44 -0600 schrieb Aaron Griffin <aaronmgriffin@gmail.com>:
What are you worried about specifically? The klibc build udev?
mkinitcpio is broken for my notebook with new .32 kernels and kms. I mailed about the new kernel some time ago. Somebody had already asked about a new release. Udev needs a lot of love these days and the new kernel is also out. But it's more a general feeling that has come over me that in the last weeks the number of active developers has decreased again. -Andy
Andreas Radke schrieb:
mkinitcpio is broken for my notebook with new .32 kernels and kms. I mailed about the new kernel some time ago. Somebody had already asked about a new release. Udev needs a lot of love these days and the new kernel is also out.
But it's more a general feeling that has come over me that in the last weeks the number of active developers has decreased again.
tpowa is already working on 2.6.32 and your problem with KMS is not a problem in mkinitcpio. About udev - we have a problem with cryptsetup that will cause regressions if we move the current udev+device-mapper to core, and I still have no solution for those. That said, releasing a new mkinitcpio with a bugfix is not possible if commits are being pushed that obviously break existing setups without any reasonable upgrade path. The reason for that breakage is that some people think sh-compatibility is more important than anything else: http://projects.archlinux.org/mkinitcpio.git/commit/?id=984cbd4eb023001668ee... And then you also add a warning that is printed every time mkinitcpio is run. So now before I can release anything, I have to clean up other people's commits first.
Am Freitag 04 Dezember 2009 schrieb Thomas Bächler:
Andreas Radke schrieb:
mkinitcpio is broken for my notebook with new .32 kernels and kms. I mailed about the new kernel some time ago. Somebody had already asked about a new release. Udev needs a lot of love these days and the new kernel is also out.
But it's more a general feeling that has come over me that in the last weeks the number of active developers has decreased again.
tpowa is already working on 2.6.32 and your problem with KMS is not a problem in mkinitcpio. About udev - we have a problem with cryptsetup that will cause regressions if we move the current udev+device-mapper to core, and I still have no solution for those.
That said, releasing a new mkinitcpio with a bugfix is not possible if commits are being pushed that obviously break existing setups without any reasonable upgrade path. The reason for that breakage is that some people think sh-compatibility is more important than anything else: http://projects.archlinux.org/mkinitcpio.git/commit/?id=984cbd4eb023001668e ea530e2b5ed2e57ba3693 And then you also add a warning that is printed every time mkinitcpio is run. So now before I can release anything, I have to clean up other people's commits first.
Udev-149 removes /dev/hd* rules, the question is if we should add it as compat rules, i don't know how stable the ata subsystem is on .27 lts series. Also we can think of removing the old ide subsystem from kernel .32 series and mkinitcpio. I think it can stay until it's removed from kernel anyway, any other opinions? thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Fri, 2009-12-04 at 08:24 +0100, Tobias Powalowski wrote:
Udev-149 removes /dev/hd* rules, the question is if we should add it as compat rules, i don't know how stable the ata subsystem is on .27 lts series. Also we can think of removing the old ide subsystem from kernel .32 series and mkinitcpio. I think it can stay until it's removed from kernel anyway, any other opinions?
The libata framework is stable for 2.6.27, I'm using libata on 2.6.24 and 2.6.26 without problems, so 2.6.27 shouldn't be an issue. Problem is the drivers. Not all drivers are bug-free in the libata framework. With intel you won't notice any problems, but the sis driver is a bit suspicious.
Jan de Groot schrieb:
The libata framework is stable for 2.6.27, I'm using libata on 2.6.24 and 2.6.26 without problems, so 2.6.27 shouldn't be an issue. Problem is the drivers. Not all drivers are bug-free in the libata framework. With intel you won't notice any problems, but the sis driver is a bit suspicious.
The pata_sis driver never worked for my desktop - until the motherboard went up in smoke, so I cannot test if this improved. That said, I agree that we can remove IDE from 2.6.32 with the appropriate warning signs set everywhere.
On Fri, Dec 4, 2009 at 2:58 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Jan de Groot schrieb:
The libata framework is stable for 2.6.27, I'm using libata on 2.6.24 and 2.6.26 without problems, so 2.6.27 shouldn't be an issue. Problem is the drivers. Not all drivers are bug-free in the libata framework. With intel you won't notice any problems, but the sis driver is a bit suspicious.
The pata_sis driver never worked for my desktop - until the motherboard went up in smoke, so I cannot test if this improved.
That said, I agree that we can remove IDE from 2.6.32 with the appropriate warning signs set everywhere.
Hell no, -300 on this. My second computer won't boot at *all* with the newer drivers, it absolutely needs the older drivers. What is the rush to kill these drivers from our kernel anyway? If upstream doesn't remove them we shouldn't be... -Dan
Dan McGee schrieb:
The pata_sis driver never worked for my desktop - until the motherboard went up in smoke, so I cannot test if this improved.
That said, I agree that we can remove IDE from 2.6.32 with the appropriate warning signs set everywhere.
Hell no, -300 on this. My second computer won't boot at *all* with the newer drivers, it absolutely needs the older drivers. What is the rush to kill these drivers from our kernel anyway? If upstream doesn't remove them we shouldn't be...
tpowa decided to leave them in the kernel for now. Does this still not work? It's been a long time since we talked about it, I thought this might be solved by now.
Tobias Powalowski schrieb:
Hi Major changes: - Minimal kernel version bumped to 2.6.27: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=1da6c797fdbb94372...
- Older kernels than 2.6.31 might need the udev-compat package: Most NAME= instructions got removed. Kernel 2.6.31 supplies the needed names if they are not the default. To support older kernels, the NAME=rules need to be added to the compat rules file.
There is another problem: This requires the latest device-mapper package from testing to work, as I removed part of the arch-rules.patch to solve a bug with cryptsetup. Now, this opened another bug related to cryptsetup, which I cannot solve right now. Is it a problem if this stays in testing for a while longer, together with device-mapper?
Am Donnerstag 03 Dezember 2009 schrieb Thomas Bächler:
Tobias Powalowski schrieb:
Hi Major changes: - Minimal kernel version bumped to 2.6.27: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=1da6c797fdbb94 372c1a809acf1a0ca159b2d7b1
- Older kernels than 2.6.31 might need the udev-compat package: Most NAME= instructions got removed. Kernel 2.6.31 supplies the needed names if they are not the default. To support older kernels, the NAME=rules need to be added to the compat rules file.
There is another problem: This requires the latest device-mapper package from testing to work, as I removed part of the arch-rules.patch to solve a bug with cryptsetup. Now, this opened another bug related to cryptsetup, which I cannot solve right now. Is it a problem if this stays in testing for a while longer, together with device-mapper?
Hi bumped udev to latest version, please try and signoff. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Signoff x86_64. I already moved latest LTS kernel that depends on udev-compat. So -Syu fails now. It would be nice to move udev quickly. -Andy
Signoff x86_64. I already moved latest LTS kernel that depends on udev-compat. So -Syu fails now. It would be nice to move udev quickly. -Andy
On 12/23/2009 11:51 AM, Andreas Radke wrote:
Signoff x86_64.
I already moved latest LTS kernel that depends on udev-compat. So -Syu fails now. It would be nice to move udev quickly.
-Andy
signoff x86_64 -- Ionut
participants (7)
-
Aaron Griffin
-
Andreas Radke
-
Dan McGee
-
Ionut Biru
-
Jan de Groot
-
Thomas Bächler
-
Tobias Powalowski