The S/390 breakage fix coming to rawhide and f21 soon
by Siddhesh Poyarekar
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
9 years, 8 months
Updated glibc in rawhide
by Siddhesh Poyarekar
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
9 years, 8 months
[RFC] Revert patch for bz#737223
by Siddhesh Poyarekar
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
9 years, 8 months