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

[Allan McRae]

Andreas Radke 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.
>   

In general I would agree with you.  But in the case of glibc, there is 
no real upstream management of the stable branch and each distro picks 
and chooses patches to include.  I was going to make a package based on 
the "candidate stable" branch along with extra patches from the Fedora 
branch but ran out of time. The question we need to ask is would this 
patch have been included on the 2.10 stable branch if there was actually 
one...

> I'm thinking about adding a long requested 2nd kernel back to our
> repos. It would be the wanted "fallback" when core kernel would fail
> booting after rebooting. I'd like to maintain myself a "longlife"
> upstream supported kernel that is right now kernelseries 2.6.27.xx with
> maybe all 3rd party modules + Xen support if possible. We should be
> able to support this 2nd kernel for a longer time with our udev and
> mkinitcpio until next longlife version will be ready. This one would
> become the recommended kernel for server usage (not sure if it should
> become a different preempt setting). We could have it either in core as
> 2nd one but extra would be also ok to me and would save us signoffs in
> case of quick security fixes. Not sure if it shoul be a choice for the
> iso.
>   

I had started looking into making a 2.6.27 kernel package (for the AUR) 
for pretty much the same reasons here.  However, I am not that great at 
making kernels for general usage so I gave up for the time being...  I'd 
be happy if you included it in [extra].

Allan