On Friday 03 February 2017 06:40 PM, Carlos O'Donell wrote:
> This should not block the release and I've told Dave Miller (in the
> test status request thread) that he should just make whatever changes
> he needs making since it's restricted to the SPARC32 backend. Anything
> is better than broken.
> My only goal today is to try fix this with a minimum of change and
> retest across all the affected arches. I have a bunch of boxes on loan
> to use for that.
That sounds good.
>> - I have posted a tunables test case fix that I'll commit soon if
>> nobody objects
> Your patches there look good to me.
> On 02/03/2017 06:36 AM, Siddhesh Poyarekar wrote:
>> On Friday 03 February 2017 05:00 PM, Adhemerval Zanella wrote:
>>> One option could be removing  and check if fixing  yields any performance gain
>>> compared to . Otherwise removing both is the best option.
>>> In any way, it is a nice fix to have, but it is not a release blocker imho.
>> Thanks for the detailed analysis. Changing routines so close to the
>> release is a bit tricky IMO and we have in the past deferred it until
>> after the release. I'd say lets do the same for this too unless not
>> fixing this has a significant and known impact on known applications or
>> workloads on sparc.
> I think Dave or the distributions should make that choice, but if it's really
> broken then fixing it would be better than nothing.
I think the idea is to just defer this specific issue to 2.26 and not
handle it as a release blocker.
From: Carlos O'Donell <[hidden email]>
Date: Fri, 3 Feb 2017 08:08:15 -0500
> Siddhesh won't be cutting the branch until Sunday because of a few other
> last minute blocker's that we're clearing off the decks.
> Therefore if you want to commit the SPARC-only changes, please do so,
> and post the test results to the wiki?
> https://sourceware.org/glibc/wiki/Release/2.25 >
> Anything in the wiki is better than nothing. Just saying what system
> you used for testing and compiler+binutils+kernel combination is useful
> information for others.