[BusyBox] Getting started on 1.0.1-rc2
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