On Sun, Aug 23, 2009 at 9:12 AM, Andreas Radke<a.radke@arcor.de> wrote:
Am Sun, 23 Aug 2009 23:10:54 +1000 schrieb Allan McRae <allan@archlinux.org>:
Jan de Groot wrote:
On Sun, 2009-08-02 at 21:08 +0200, Tobias Powalowski wrote:
Hi bump to latest udev version, please test it well. Has many new things included, which also dig in glib2 and libusb depend.
greetings tpowa
To bump this thread:
- udev 145 contains .la files, they should be removed - Allan has to patch glibc to support older kernels with signalfd
When this is done, we need to move: - e2fsprogs - util-linux-ng - udev - hal - initscripts - glibc
I don't know what's allan's schedule is for this, but I could release a glibc package with just that patch included. We have quite some stuck packages due to the old util-linux-ng and udev in core at this moment.
Please go ahead and release a glibc with that patch. I am quite busy at the moment so probably will not get to Arch stuff until later next week...
Allan
Hm. IMHO this would break our own patching rules though it may be helpful here. We usually don't apply patches for unsupported packages. And we currently only have one kernel to support in our repos. So I thinking that patch would not be allowed.
This line of thinking is absurd. Patching rules? We had like 8 devs say this was a good thing, and the fucking patch is upstream! An excuse like "patching rules" here is ridiculous, and calling any non-stock kernel unsupported is also a great way to anger a large crowd of Arch users. You did approve this kernel patch, right? http://projects.archlinux.org/?p=linux-2.6-ARCH.git;a=blob;f=patches/quirks-... Obviously I'm being a bit sarcastic here- I don't think you actually approved this patch, but my point is that we already patch our kernel for some things that affect a small proportion of our users with that hardware, and yet a extremely scope-limited yet useful glibc patch draws more fire. In light of recent activity in the dev circle, I'd also like to ensure this isn't seen as a personal attack on you, Andy. I'm only frustrated that a crutch like "patching rules" could even be pulled out here. The second kernel idea is a good one. However, it still does not address the main reason a lot of us wanted this patch in, which is when you are running in an environment where you do *not* control the kernel. -Dan