Re: status of 0.9.30 release

[Chase Douglas]

On Sep 27, 2008, at 6:09 PM, Rob Landley wrote:

On Friday 26 September 2008 10:06:22 Chase Douglas wrote:

Has anyone else tried to compile openssh against the new linuxthreads
stack? When I tried a few weeks ago it failed to compile auth-pam.c.
In that file they do some pretty wacky stuff like redefining some of
the pthread functions. Unfortunately, there doesn't seem to be a way
to get that file to build due to the way the uClibc pthread header
files are architected. So my suggestion would be to make sure that
openssh can compile against uClibc with the newer linuxthreads stack
before contemplating getting right of the older linuxthreads stack.

threaten to make the old one go away.


and a half.  We can't avoid it, we should just face up to it.


tracking down where it went.)

See, this is exactly the sort of bug report we _don't_ get unless we at least At this point, it's been so long since 0.9.29 shipped that 0.9.30 is going to need a 0.9.30.1 fairly promptly, from the bug reports of people who don't try it until it ships and then find some regression snuck in over the past year Getting as many people as possible to test it before we ship is of course vital. (Mentioning -rc1 on the uClibc website might be a good idea, but the website seems to have moved out of the main archive and I have no interest in

I understand your reasoning for trying to remove the linuxthreads.old stack. However, I see an issue with this approach in that there are users who depend on a "stable" release to be stable, within a margin of error. Removing the only known stable stack, as in well tested in many environments, does not inspire confidence in the reliability of "stable" releases. If one needs a truly stable uClibc, you're basically telling people not to rely on 0.9.30, at least until 0.9.30.1. That leaves users in a tough spot because the last "stable" release was way back in May of 2007. A ton of bug fixes have entered the tree since then leaving users the impression that 0.9.29 isn't really "stable" anymore. What I propose is that uClibc actually maintain the stable branches of uClibc, at least the current stable release if not more. That means backporting bug fixes to the latest release as well as the development trunk. If that is handled correctly, there wouldn't be much of an issue about transitioning to 0.9.30 without linuxthreads.old as those requiring linuxthreads.old due to known stability wouldn't have to sacrifice development-driven bug fixes seen only on trunk. Because that is not possible today without quite an effort to track down all the bug fixes in the past 8 months (since the last change to the 0.9.29 branch), I would recommend leaving linuxthreads.old in uClibc. I know it may depress testing and bug reports against the new stack, but to post a "stable" version that is known not to be completely tested just to spur testing is backwards. We need to inspire more confidence in the stability of the package, especially since every part of a system depends on the C library functioning correctly.

Also, I posted a patch to rectify a pthread fork mutex issue for

safely deals with the situation either, so porting that patch may be
wise. It shouldn't take hardly any work to do so as well.

linuxthreads.old. I am not convinced that the newer linuxthreads stack

I'm guessing you're referring to:
http://uclibc.org/lists/uclibc/2008-September/020110.html

And yes, I'd like to have this discussion about the new linuxthreads.


which ones are needed in the new one.  I'll add it to the todo heap...

Possibly I should look for all svn commits to the old linuxthreads and see

Thanks,
Chase Douglas

That fix hasn't been committed anywhere yet, so you'll have to base off of the patch I posted.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc