[arch-dev-public] [signoff] udev-145-1

[Dan McGee]

On Sun, Aug 23, 2009 at 9:12 AM, Andreas Radke<a.radke at arcor.de> wrote:
> Am Sun, 23 Aug 2009 23:10:54 +1000
> schrieb Allan McRae <allan at 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-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