status of 0.9.30 release

Chase Douglas cndougla at us.ibm.com
Sat Sep 27 23:42:33 UTC 2008


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.
>
> See, this is exactly the sort of bug report we _don't_ get unless we  
> at least
> threaten to make the old one go away.
>
> 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
> and a half.  We can't avoid it, we should just face up to it.
>
> 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
> tracking down where it went.)

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
>> linuxthreads.old. I am not convinced that the newer linuxthreads  
>> stack
>> 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.
>
> 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.
>
> Possibly I should look for all svn commits to the old linuxthreads  
> and see
> which ones are needed in the new one.  I'll add it to the todo heap...

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

Thanks,
Chase Douglas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3892 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20080927/7e638e6f/attachment-0002.bin 


More information about the uClibc mailing list