On Saturday 15 November 2008 21:48:16 walter harms wrote: > > Tito schrieb: > > On Saturday 15 November 2008 10:51:44 walter harms wrote: > >> Rob Landley schrieb: > >>> On Friday 14 November 2008 09:42:50 walter harms wrote: > >>>> hhhmmm, > >>>> > >>>> releasing a code that depends on a libc version that is not released yet > >>>> it not nice to users. > >>> I suspect glibc had this years ago and that's what they were testing > >>> against. > >>> > >>> I also note that uClibc had an -rc1, -rc2, and -rc3 in the month of > >>> october, > >>> and had stated on the mailing list the intention to have a release out at > >>> the > >>> end of October. In reality, the busybox 1.13.0 and uClibc 0.9.30 > >>> releases > >>> were essentially synonymous. > >>> > >> hi Rob, > >> > >> that may be but if you require the latest feature of the latest release > >> you should give the users a hint. > >> > >> > >> > >>>> something like > >>>> > >>>> if uClibc version < 0.9.30 > >>>> you need version 0.9.30 at least > >>>> exit > >>>> end if > >>>> > >>>> may help also. > >>> For a single applet? (Other applets build fine against much older > >>> versions.) > >>> > >>> Would you like to add tests for dietlibc, newlib+libgloss, and klibc as > >>> well? > >>> Plus the various BSDs people occasionally send in patches for, MacOS X, > >>> and > >>> mingw? > >>> > >>> Plus the various non-x86 targets with varying functionality, such as the > >>> fact > >>> you can't build taskset on m68k under _any_ libc due to the lack of smp > >>> processor affinity syscalls? > >>> > >>> Wanna keep all of the above in sync, for each applet, for each new > >>> release of > >>> every project? And warn about gcc versions that miscompile things on > >>> various > >>> hardware targets? > >>> > >>> Or we could just avoid going down that rathole entirely, and stay simple. > >>> I > >>> like simple... > >> i do not call it *the solution*. Of cause you can not solve every problem. > >> This was not intended. But you can help with obvious problems in basic > >> stuff > >> like ulibc. and if you aware that the last version of gcc will cause havoc > >> why not add a warning ? > >> With m68k i am not sure i would assume that m68k people will be aware that > >> it has no smp processor affinity. > >> > >> NTL is is not our business to decide about releases. Denys is the > >> maintainer > >> and if he does , he does it. > >> IMHO it is unfair to say nothing when i (i do not speak for other people) > >> think he > >> made a mistake. > >> > >> re, > >> wh > >> > > > > Hi, > > i'm the culprit!! ;-) > > As the checks for the missing of getgrouplist in uClibc were in > > the code.......I would dare to say uglyfied the code and due to > > the fact that i did an integral rewrite of id.c I removed them. > > The main reason that made me decide to remove the ifdefs was that: > > > > 1) libc has getgrouplist > > 2) getgrouplist was added to libbbpwdgrp > > 3) getgrouplist was already in uClibc svn > > and the mantainer was talking about releasing soon. > > > > So for the sake of code cleaness I removed the ifdef hell. > > In reality uClibc was 2 days late or we 2 days to early, > > this is surely annoying, but was not intended to happen. > > Now the problem is resolved anyway.....and we have > > clean, readable and maintenable code. > > > > @Walter > > Nonetheless if you want to add some warning or > > maybe some advice in the id help text feel free > > to send a patch. > > > > i am guilty also :) since i started patching id, what was the starting reason > you did the rewrite. i think a patch is not needed anymore since the needed > ulibc is out now. > > my (only) point was that we should not release SW that needs a ulibc version > (a supported libc!) that is not yet released. I am fully aware why this bad > timing happened but this is simply a bad habit, no matter what, you can not > do that. > i thought is important to communicate that. > > re, > wh > > > >
Hi, we will do better next time and coordinate the efforts with Bernard should a similar situation arise again in the future. Ciao, Tito _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
