Am Wed, 2 Dec 2009 21:50:17 +0100 schrieb Andreas Radke :

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

Am Thu, 3 Dec 2009 12:30:44 -0600 schrieb Aaron Griffin :

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

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

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.

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.

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