SCIENTIFIC-LINUX-DEVEL Archives

February 2012

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steven Haigh <[log in to unmask]>
Reply To:
Steven Haigh <[log in to unmask]>
Date:
Wed, 15 Feb 2012 12:52:00 +1100
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2163 bytes) , smime.p7s (4 kB)
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? :)

-- 
Steven Haigh

Email: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299



ATOM RSS1 RSS2