[BusyBox] Getting started on 1.0.1-rc2

Rob Landley rob at landley.net
Sat Aug 13 02:28:43 UTC 2005

On Thursday 11 August 2005 21:30, Mike Frysinger wrote:
> On Wednesday 10 August 2005 07:30 pm, Rob Landley wrote:
> > 10917 something to do with stat.c?
> i thought we were gonna keep stat out of 1.0 ?  i added the applet cause i
> was bored, not cause i needed/wanted it :)

Ah.  Right then.

> > 10923 big makefile change.  Nervous.
> not really ... just changes hardcoded arflags to a variable (like it should
> be) ... this should be safe

I applied it.  I touched lotsa files, but luckily "svn commit ." works...

> > 10974: is this a bugfix, or a follow-up to 10887?
> not a bugfix, just gets rid of a warning (accept is a function defined in
> header files and newer gcc/glibc combos complain)

It's also apparently dependent on the big unzip rewrite.  Attempting to apply 
it all the hunks fail.

> > 10975: what?
> sometimes the build process generates a .hdepend file ... i just added it
> to the '.cvsignore' list

This is another one I don't know how to apply.

> > 11002 ether-wake and uclibc?
> should be moved to 1.0 if it isnt already ... the warning explains the
> issue ...

Having read this patch: no.

Fix uclibc (add a stub function), or don't use ether-wake, but don't #ifdef 
uclibc in the middle of the code.  That's not progress.

> > 11011 whitespace changes to makefile?
> i like fixing whitespace :P

And the problem with gratuitous whitespace thrashing is it creates artificial 
dependencies for other patches.

For example, with this patch hunk 1 failed and hunks 2 and 3 succeeded.  And 
I'm applying it with hunk 1 failed.  You keep track of which future patches 
this will cause to fail to apply cleanly.

> > 11012 bbconfigopts.h dependency?
> only needed if 1.0 is going to have the bbconfig applet

That would be a no, then.

> > 10922 #ifdef newlib is not an improvement.
> it's an improvement if you use newlib ;)

If I'm not going to apply a uclibc #ifdef and I _use_ uclibc, what do you 
think the chances of me applying a newlib #ifdef?

> > 10973, 10984 mke2fs
> i thought we were going to keep e2fsprogs out of busybox-1.0

Yup.  That's why it's in the "no" category, isn't it?

> > 10978, 10980: NO!  Evil evil evil evil...
> not our fault gcc can dig it :P


> > 10995: I don't care about devfs.
> just a whitespace change, nothing to worry over

I still don't care about devfs.

> > 11006, 11008, 11015 new applets.
> fine with me if we just keep these in 1.1


More information about the busybox mailing list