[witten after a few beers and a birthday party at 3 am, so please excuse
misleading wording]
Hello!
[Fri, 20 Aug 2004] Lee Revell wrote:
> Argh, they will not even fix it in unstable? What is the point of
> having an unstable distribution?!?. Can we at least add the fix to
> experimental?
It's always an additional commitment and more work to maintain another
branch. Since the NPTL bug is not considered important enough there is
no need to dedicate a branch to it. This is just coherent.
> If not now, then when do you expect this to be in unstable?
Personal judgement: With about 90% probability after the first release of
sarge.
> I guess we will have to start our own campaign to get this fixed. If
> they are too conservative to put a trivial fix like this in UNSTABLE,
Lacking triviality is not the barrier. The word "freeze" is.
> which is the most bleeding edge thing they offer, we will just have to
> update the jackd FAQ and post a notice on linux-audio-dev and
> linux-audio-user recommending people use FC2 or SuSE because Debian will
> not listen to its users.
>
> MONTHS were spent tracking this bug down. It is an insult to the Linux
> audio community for Debian to refuse to fix this.
Nah. Give me more arguments. Talk to the NPTL creator (the guy from
redhat) and ask him what he thinks about the problem _and_ the possible
sideeffects and consequences of the proposed patch. He solved the
problem in a much more complex way:
<http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl/pthread_create.c.diff?cvsroot=glibc&r2=1.32&r1=1.31&f=u>
Assuming thet his "if (0 && ..." was not just "defensive programming",
get a supportive quote from him.
[Fri, 20 Aug 2004] Paul Davis wrote:
> >> > MONTHS were spent tracking this bug down. It is an insult to the
> >> > Linux audio community for Debian to refuse to fix this.
>
> i think this is a bit of an overstatement.
>
> the bug affects one particular type of programming construct:
>
> pthread_attr_t attr;
>
> ... set attr ...
>
> pthread_create (&thread, &attr, ...)
>
>
> it has no effect on the alternative:
>
> void *
> thread_work (void *arg)
> {
> pthread_setschedparam (...);
> ...
> }
>
> so there *is* a workaround for the bug. and i personally believe that
> JACK, at least, should be using the workaround.
Right. To me it even seems that we can guarantee that this workaround
has fewer or at most as many side-effects as the patch to glibc.
[Sat, 21 Aug 2004] Fons Adriaensen wrote:
> I agree. And it breaks correctly written existing code. I see no
> reason why this shouldn't be fixed ASAP.
Glibc is frozen. If you don't come up with reasons why this NPTL but is
releas-ecritical, then it is not about to be ficed soon.
Not that I'm happy with it but that's the way it works.
Robert.
--
I develop for Linux for a living, I used to develop for DOS.
Going from DOS to Linux is like trading a glider for an F117.
-- Lawrence Foard, entropy@world.std.com
Attachment:
signature.asc
Description: Digital signature