On Sun, Aug 23, 2009 at 9:12 AM, Andreas Radke<[email protected]> wrote: > Am Sun, 23 Aug 2009 23:10:54 +1000 > schrieb Allan McRae <[email protected]>: > >> 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-h12y.patch;h=99f5fa0a86e26f562a217ce9b641262d4ac699f4;hb=HEAD 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
