On 02/14/2012 07:52 PM, Steven Haigh wrote:
> On 15/02/2012 3:32 AM, Steven Haigh wrote:
>> On 15/02/2012 3:26 AM, Pat Riehecky wrote:
>>> On 02/14/2012 10:14 AM, Bart Swedrowski wrote:
>>>>
>>>>
>>>> On 14 February 2012 15:52, Steven Haigh <[log in to unmask]
>>>> <mailto:[log in to unmask]>> wrote:
>>>>
>>>> Out of interest, is there any way to see (easily) if the patch
>>>> attached applies cleanly to the build environment used to rebuild
>>>> the SL packages?
>>>>
>>>>
>>>> It applies cleanly to
>>>> http://vault.centos.org/6.2/updates/Source/SPackages/glibc-2.12-1.47.el6_2.5.src.rpm 
>>>>
>>>>
>>>> build through mock. At least for me :)
>>>
>>> I can confirm the same for SL
>>
>> Ok, now it comes down to a policy thing... The bug just got closed with:
>>
>> --- Comment #5 from Jeff Law <[log in to unmask]> 2012-02-14 11:14:59 EST 
>> ---
>> This is a duplicate of 752122, which is scheduled to be fixed in Red Hat
>> Enterprise Linux 6.3.
>>
>> *** This bug has been marked as a duplicate of bug 752122 ***
>>
>> This means until RHEL 6.3 is released, they won't be fixing it.
>>
>> As we're in 6.2 RC2, and I can't find a date for TUV to release 6.3, how
>> should we handle this bug?
>
> As a test for this, I've rebuild glibc with the patch applied, however 
> I get a bit unstuck - as the system I need to apply this update on 
> also requires a 32 bit version of glibc for the install of IBM Tivoli 
> Storage Manager!
>
> One thing I don't have is a build environment that is able to process 
> .i686 packages!
>
> I'm wondering if it is possible to build the glibc packages with the 
> patch applied and either:
>     1) Put them on a separate web site so we can point people who have 
> this issue to them and not confuse stuff with the main repos, or;
>     2) Build it and push it out in sl6x-fastbugs?
>
> I rebuilt the packages as:
>     glibc-2.12-1.47.1.el6.5.x86_64.rpm etc
>
> This way I figure that the next release from TUV will be 
> glibc-2.12-1.(xx) where xx will be higher than 47.
>
> The only annoyance is that if we patch it separately, then we'll have 
> to manually add the patch to any possible glibc updates until TUV fix 
> their end...
>
> A penny for the thoughts of the SL team? :)
>

We are going to stick with upstream on this one.  The reasoning is 
somewhat complex.  We have a few concerns before we ever consider 
forking off.

Is upstream going to fix?
How likely are the uninformed end users to blame us for things not working?
How entrenched is this package?
Does this effect our compatibility with TUV?

With upstream having the patch on Q/A and promising a fix with 6.3, we 
know they are going to fix it.  Both Connie and I expect they will 
release the fix sooner than that.

And because it is so invasive people may blame it for unrelated problems.

This package is listed by TUV as _THE_ core library, changes have a very 
large impact.

Changing glibc clearly changes our compatibility with TUV.

Since a fix is coming, we are going to wait for it.

-- 
Pat Riehecky
Scientific Linux Developer