[arch-dev-public] [signoff] glibc-2.13 toolchain rebuild

[Dan McGee]

On Fri, Jan 21, 2011 at 12:42 AM, Allan McRae <allan at archlinux.org> wrote:
> On 20/01/11 21:25, Allan McRae wrote:
>>
>> On 20/01/11 03:13, Dan McGee wrote:
>>>
>>> On Tue, Jan 18, 2011 at 7:55 PM, Allan McRae<allan at archlinux.org> wrote:
>>>>
>>>> Here goes the toolchain rebuild for glibc-2.13:
>>>>
>>>> glibc-2.13-1
>>>> - major upstream release
>>>> - Fedora 14 uses a pre-release glibc from this branch so it should be a
>>>> fairly safe update...
>>>>
>>>> linux-api-headers-2.6.37-1
>>>> - version bump
>>>>
>>>> gcc-4.5.2-5
>>>> - just a rebuild (I will probably bump to a newer snapshot in the coming
>>>> weeks as lots of backports are moving onto that branch lately with
>>>> progress
>>>> towards gcc-4.6)
>>>>
>>>> binutils-2.21-3
>>>> - just a rebuild (not much of interest has landed on the 2.21 branch
>>>> since
>>>> the last build)
>>>>
>>>> valgrind-3.6.0-2
>>>> - patch and rebuild for glibc-2.13
>>>> - not particularly tested here so reports of success/failures would be
>>>> good...
>>>>
>>>
>>> Working good here for our old friend pacman. Signoff
>>> valgrind/glibc/gcc and probably everything for x86_64. But we did
>>> expose a problem via valgrind in glibc gettext (it doesn't occur if
>>> you do something like `pacman -Q glibc` because there are no gettext
>>> calls), what fun. Looks like both strcasecmp_l and strncasecmp_l have
>>> something odd with them.
>>>
>>
>> This looks like:
>> http://bugs.kde.org/show_bug.cgi?id=256600
>>
>> Nothing to worry about. I will pull the patch from valgrind SVN at some
>> stage.
>>
>
> And valgrind-3.6.0-3 is in [testing] with a fix for this.

Appears to be working now and suppressing this stuff, thanks.

-Dan