Hi!
I've created a patch to busybox' build system to allow building it in
separate tree in a manner similar to kbuild from kernel version 2.6.
That is, one runs command like
'make O=/build/some/where/for/specific/target/and/options'
and everything is built in this exact directory, provided that it exists.
I understand that applyingc such invasive changes during 'release
candidates' stage of development is at best unwise. So, i'm currently
asking for comments about this patch, starting from whether such thing
is needed at all to whether it coded properly.
'make check' should work now, and one make creates Makefile in build
directory, so one can run 'make' in build directory after that.
One possible caveat is that if we build in some directory other than
source one, the source directory should be 'distclean'ed first.
egor
This is a bulk spelling fix patch against busybox-1.00-pre10.
If anyone gets a corrupted copy (and cares), let me know and
I will make alternate arrangements.
Erik - please apply.
Authors - please check that I didn't corrupt any meaning.
Package importers - see if any of these changes should be
passed to the upstream authors.
I glossed over lots of sloppy capitalizations, missing apostrophes,
mixed American/British spellings, and German-style compound words.
What is "pretect redefined for test" in cmdedit.c?
Good luck on the 1.00 release!
- Larry
I had previously provided you with a patch to help complete busybox's
props suite, but have heard no word back. Sense then I've made use of as
many of busybox's native API settings as I could find and would really
love for you to include support for this. If there is something more I
need to do to get this supported added in please let me know.
the busybox menuconfig triggered my "inacceptable number of spelling mistakes"
upper level, so I decided to make a patch ;-)
I also improved some wording to describe some things in a better way.
Many thanks for an incredible piece of software!
Andreas Mohr, random OSS developer
Erik,
The format for /proc/meminfo has changed between 2.4 and 2.6, quite considerably.
In addition to the removal of the two-line summary that was present in 2.4,
MemShared was also removed. Presently (at least in busybox CVS HEAD), top fails
to parse this correctly and spews forth a:
top: failed to read 'meminfo'
message. This patch switches around some of the semantics a little to do sane
parsing for both 2.4 and 2.6. Also, in the event that the summary gets yanked
from 2.4, this patch will deal with that as well. With this patch, I'm able
to run top correctly on 2.6.0-test7 (tested on sh).
Please apply.
procps/top.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++------------
1 files changed, 48 insertions(+), 12 deletions(-)
Hello all,
This patch adds more "Help" text to the config system. Almost
all applets now have a help entry. Also, I cleaned up the spacing of
the existing text so that things are consistent. This patch is against
this morning's CVS.
Thomas Cameron
CEI Systems, Inc.
modified Kbuild system I put into uClibc. With this, there should be no more
need to modify Rules.mak since I've moved all the interesting options into the
config system. I think I've got everything updated, but you never know, I may
have made some mistakes, so watch closely.
-Erik
Ok. I generate patch for include to busybox-devel my work with
top (original author give me maintaining) and telnetd (my
support and unofficial maintaining) applets. Docs changes
also: added awk, netstat, time applets to list ;)
Hi, Erik.
my_getpw(uid/gid) and applets used it have problem:
if username for uid not found, applets can`t detect it
(but code pessent). Also "%8ld " format is bad:
spaces not required (applets have self format
or spec format (tar applet) and overflow for "id" applet...)
This problem also pressent in stable version.
Patch for unstable in attach.
--w
vodz
the busybox development tree. This eliminates the use of recursive make, and
once again allows us to run 'make' in a subdirectory with the expected result.
And things are now much faster too. Greatly improved IMHO...
-Erik
that into a pid_t, which is unsigned on a number archs. Furthermore,
find_pid_by_name() would _never_ return an error if the intended proces
was "init", but instead would return 1, meaning we would fail to work
on 2.4.x kernels running an initrd...
-Erik
