glibc July 2014

glibc@lists.fedoraproject.org

5 participants
3 discussions

The S/390 breakage fix coming to rawhide and f21 soon
by Siddhesh Poyarekar 31 Jul '14

31 Jul '14

Hi, I just noticed that the S/390 arch maintainer in upstream glibc has pushed the patch to revert the ABI breakage he had introduced in 2.19. This will hit rawhide next week (and f21 a bit later), so please let me know if I can provide any extra assistance with this or if any particular day or time is convenient for the rebase. Siddhesh

3 3

Updated glibc in rawhide
by Siddhesh Poyarekar 29 Jul '14

29 Jul '14

Hi, I have updated glibc in rawhide to the latest master after verifying that it works fine on x86 (32 and 64-bit). The build is in progress here: http://koji.fedoraproject.org/koji/taskinfo?taskID=7204483 Please also test this against your architectures and report failures if any. Dan, please let me know if the setuid failure you saw on python persists and if it does, please let me know which machine I can access to debug the issue. For F21, the plan is to continue to track glibc upstream master till it branches off to 2.20. This should happen some time in the middle or end of August, so it ought to be well before Fedora turns beta. I'm planning to track f21 much more slowly though, since I got feedback that folks wanted slightly slower churn in f21. I'll probably do something like rebasing rawhide in the beginning of the week and then merging that point into f21 by the end of it. Please let me know if anyone has preferences regarding this. Thanks, Siddhesh

2 1

[RFC] Revert patch for bz#737223
by Siddhesh Poyarekar 07 Jul '14

07 Jul '14

Hi Carlos, I was going through the latest test failures in rawhide and one of them is in tst-dl-iter-static. I tracked the reason for failure to the fix for the bz 737223. The bz is an obscure crash in GL applications when using the proprietary nvidia driver and someone tracked it down to the assignment of the vdso soname to l->l_name. The fix was to do that assignment only when debug mask is non-zero, which seems to mask the crash. Through all that, there seemed to have been no root cause analysis for the crash, so we don't even know if the fix only papered over a symptom or if it actually fixed something. I could easily work around the failed test, but it seems to me that the right thing to here would be to drop the patch and see if the crash is still there, which would obviously be by waiting for bug reports. That would give us a chance to fix it correctly or at least justify the current fix to send it upstream. What do you think? Siddhesh

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

glibc July 2014