Re: Debian Etch ....
I imagine that no one followed up on the bug because the it was marked
as closed with the RESPONSE
that 2.5-exp3 *is* the fix for #325600.
That gave many of us the expectation that a 2.5 series glibc would make
its way into testing and then to
stable with the Etch release, I mean why else would the maintainers mark
such a critical bug as being fixed
in that way?
It really wasn't an issue so long as the glibc in stable was okay - no
one was expecting Etch to be released
with that flawed glibc because it was MARKED as closed (granted with a
2.5 series that made little sense).
I do not understand the first sentence above, but I'm so sorry that I
offered a possible list of explanations.
Perhaps it would have been better to have posted fewer details about the
experience of tracking it
I for one don't understand why the patch offered in #325600 and haven't had
a chance to examine the consequences of the proposed change. Further, your
comments in the bug that the real bug might be an optimizer bug, or a broken
inline_syscall4 implementation, don't inspire me to urge the glibc
maintainers to apply such a patch without digging a lot deeper into it
down to the single line of code where the problem was located.
Sometimes in complicated software, one cannot always easily find and
understand the root cause failure.
I took it as far as I could in the time I had - I thought that passing
it to the "experts" was the correct thing to do.
I noticed that in newer glibc sources that the not-cancel.h header file
is now separated via architecture.
There is one for i386, sparc, x86_64, etc (they all point to the i386
version at the moment), but that implies
that an alpha specific version is possible and with that, a change that
ONLY affects alpha should be possible.
If someone can address these doubts with some measure of authority, I'd be
happy to ask the glibc maintainers and stable release managers to include a
fix in etch r1, but from the bug log it looks like no one has bothered
following up on the bug since a fix became available in experimental --
which is totally the wrong fix for etch, because experimental's glibc is
NPTL-only, making it a separate codebase for thread handling. (And the
current build failures on alpha are in NPTL now besides, so...)