[arch-dev-public] [signoff] udev-145-1
dpmcgee at gmail.com
Sun Aug 23 10:44:04 EDT 2009
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
> 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?
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
More information about the arch-dev-public