From mwigge at marcant.net  Thu Feb  1 00:04:16 2007
From: mwigge at marcant.net (Markus Wigge)
Date: Thu, 01 Feb 2007 09:04:16 +0100
Subject: version 1.4.1
Message-ID: <45C19F00.4060903@marcant.net>

Hi,

I'm a little bit confused, I recently read about busybox 1.4.1 and found 
an archive I could download but there is no tag for it in subversion and 
it is not announced on the web?

Is this an official version or what?

bye,
   Markus


From vapier at gentoo.org  Thu Feb  1 00:12:33 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Feb 2007 03:12:33 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200701300108.09929.vda.linux@googlemail.com>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
Message-ID: <200702010312.34740.vapier@gentoo.org>

On Monday 29 January 2007, Denis Vlasenko wrote:
> I propose to simply never define anything "modular"
>
> If people run "make modules",  well, that's their problems.

there are a bunch of env config settings which can cause problems ... what i'm 
looking at is busybox gets integrated into a larger build system which 
includes a kernel and next thing i know, busybox is failing because it's 
trying to generate depmod and build modules
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/33de39e9/attachment.pgp 

From aurel at gnuage.org  Thu Feb  1 05:03:23 2007
From: aurel at gnuage.org (Aurelien Jacobs)
Date: Thu, 1 Feb 2007 14:03:23 +0100
Subject: busybox 1.4.1 build failure
Message-ID: <20070201140323.4dc138fa.aurel@gnuage.org>

Hi,

When upgrading from bb-1.4.0 to bb-1.4.1 I got the following error
(gcc-4.1.1, uClibc for i386 target):

  CC      networking/interface.o
cc1: warnings being treated as errors
networking/interface.c: In function 'in_ether':
networking/interface.c:853: warning: pointer targets in assignment differ in signedness
make[1]: *** [networking/interface.o] Error 1
make: *** [networking] Error 2

The attached patch fixes it.

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 90_build_fix.diff
Type: text/x-diff
Size: 413 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/94b338fe/attachment.bin 

From yuwend at gmail.com  Thu Feb  1 05:23:42 2007
From: yuwend at gmail.com (Yuwen Dai)
Date: Thu, 1 Feb 2007 21:23:42 +0800
Subject: ash test suite
In-Reply-To: <45BF6F79.4020601@bfs.de>
References: <45B719C7.8010503@bfs.de>
	<f7e548110701240121ga2c4b1ej288f660ce7c6e6c6@mail.gmail.com>
	<45B75AF8.8050304@bfs.de>
	<f7e548110701290138w4e6b600g50263bbcd0d6f04f@mail.gmail.com>
	<45BDE4E6.200@bfs.de>
	<f7e548110701290553n206d528dt276a1764fa70d53b@mail.gmail.com>
	<45BDFDAA.8040508@bfs.de>
	<f7e548110701292155n4d52575ex5fb6d52d7fa6beea@mail.gmail.com>
	<45BF6F79.4020601@bfs.de>
Message-ID: <f7e548110702010523j78d24c9cvbd876fd12901fcc4@mail.gmail.com>

On 1/31/07, walter harms <wharms at bfs.de> wrote:
>
> your are right,
> note:  have removed the original diff for a 'diff -y | less' to see more
> clearly the differences.
> take also a look at the readme inside the ash* tests.


I see ash-* directories as well as test files in the same directory. While
in Bash testsuite, all test files are in same level, no subdirectories.  Did
you intend to put all all the test files into subdirectories?

Best regards,
Yuwen


re,
> wh
>
> inside the ash*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070201/c9b57984/attachment.html 

From wangbj at lzu.edu.cn  Thu Feb  1 05:56:04 2007
From: wangbj at lzu.edu.cn (Wang, Baojun)
Date: Thu, 1 Feb 2007 21:56:04 +0800
Subject: busybox 1.4.0(with patches) crosscompile failed:
Message-ID: <370399254.25716@eyou.net>

hi,


the cross compiler are being built using the clfs embedded way which can be 
found at: http://cross-lfs.org/view/clfs-embedded/x86/

after patching all patches, 

# make defconfig
# make menuconfig # select ash as default shell
# make CROSS_COMPILE=i686-pc-linux-uclibc- V=1

encounter the fellowing error:

  
i686-pc-linux-uclibc-gcc -Wp,-MD,miscutils/.taskset.o.d   -std=gnu99 -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.4.0/libbb -include 
include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.4.0)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386 -mpreferred-stack-boundary=2 -Wdeclaration-after-statement -Wno-pointer-sign    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(taskset)"  -D"KBUILD_MODNAME=KBUILD_STR(taskset)" -c -o 
miscutils/taskset.o miscutils/taskset.c
miscutils/taskset.c: In function '__from_cpuset':
miscutils/taskset.c:22: error: 'CPU_SETSIZE' undeclared (first use in this 
function)
miscutils/taskset.c:22: error: (Each undeclared identifier is reported only 
once
miscutils/taskset.c:22: error: for each function it appears in.)
cc1: warnings being treated as errors
miscutils/taskset.c:26: warning: implicit declaration of function 'CPU_ISSET'
miscutils/taskset.c: In function 'taskset_main':
miscutils/taskset.c:67: warning: implicit declaration of function 'CPU_ZERO'
miscutils/taskset.c:68: error: 'CPU_SETSIZE' undeclared (first use in this 
function)
miscutils/taskset.c:70: warning: implicit declaration of function 'CPU_SET'
miscutils/taskset.c:77: warning: implicit declaration of 
function 'sched_getaffinity'
miscutils/taskset.c:85: warning: implicit declaration of 
function 'sched_setaffinity'
make[1]: *** [miscutils/taskset.o] Error 1
make: *** [miscutils] Error 2

-- 
Wang, Baojun                                        Lanzhou University
Distributed & Embedded System Lab              http://dslab.lzu.edu.cn
School of Information Science and Engeneering        wangbj at lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000                     .P.R.China
Tel:+86-931-8912025                                Fax:+86-931-8912022
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/0eb146e7/attachment.pgp 

From strange at nsk.no-ip.org  Thu Feb  1 07:03:29 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Thu, 1 Feb 2007 15:03:29 +0000
Subject: Busybox build problem
In-Reply-To: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
Message-ID: <20070201150329.GB8446@nsk.no-ip.org>

On Thu, Feb 01, 2007 at 12:26:20AM -0600, Brion Finlay wrote:
> Here are the compile problems that I get:
<snip>

Could you show the lines giving the errors?

> I'm sure it is something wrong with my environment, but I do not know what.
> Does anyone have any hints?

You could have hardware problems.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/7ec746b7/attachment.pgp 

From wangbj at lzu.edu.cn  Thu Feb  1 07:12:06 2007
From: wangbj at lzu.edu.cn (Wang, Baojun)
Date: Thu, 1 Feb 2007 23:12:06 +0800
Subject: busybox 1.4.0(with patches) crosscompile failed:
In-Reply-To: <370338889.00965@lzu.edu.cn>
References: <370338889.00965@lzu.edu.cn>
Message-ID: <370403821.29556@eyou.net>

:t???k-5??????M;?^zY???#?|+?????^r?,??&?)^???m?????????x-??%~??m?]y??br??????j?m???r?,?W?????'???_???y?^w?|??????j?!?x?ZZ??^?f?y??r???	??????(?????^r????y????!zYfjG?D??? ?
From rep.dot.nop at gmail.com  Thu Feb  1 07:18:28 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Thu, 1 Feb 2007 16:18:28 +0100
Subject: no sched_setaffinity in uClibc [was: Re: busybox 1.4.0(with patches)
	crosscompile failed:]
In-Reply-To: <200702012156.07524.wangbj@lzu.edu.cn>
References: <200702012156.07524.wangbj@lzu.edu.cn>
Message-ID: <20070201151828.GA24370@aon.at>

On Thu, Feb 01, 2007 at 09:56:04PM +0800, Wang, Baojun wrote:
>hi,
>
>
>the cross compiler are being built using the clfs embedded way which can be 
>found at: http://cross-lfs.org/view/clfs-embedded/x86/
>
>after patching all patches, 
>
># make defconfig
># make menuconfig # select ash as default shell
># make CROSS_COMPILE=i686-pc-linux-uclibc- V=1
>
>encounter the fellowing error:
>
>  
>i686-pc-linux-uclibc-gcc -Wp,-MD,miscutils/.taskset.o.d   -std=gnu99 -Iinclude -Ilibbb  -I/mnt/clfs/sources/busybox-1.4.0/libbb -include 


uClibc trunk has no support for sched_[sg]etaffinity.

Turn that applet off.
-- 
>include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.4.0)" -DBB_BT=AUTOCONF_TIMESTAMP  -Wall -Wstrict-prototypes -Wshadow -Werror -Wundef -funsigned-char -fno-builtin-strlen -finline-limit=0 -static-libgcc -Os -falign-functions=1 -falign-jumps=1 -falign-loops=1 -fomit-frame-pointer -ffunction-sections -fdata-sections -march=i386 -mpreferred-stack-boundary=2 -Wdeclaration-after-statement -Wno-pointer-sign    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(taskset)"  -D"KBUILD_MODNAME=KBUILD_STR(taskset)" -c -o 
>miscutils/taskset.o miscutils/taskset.c
>miscutils/taskset.c: In function '__from_cpuset':
>miscutils/taskset.c:22: error: 'CPU_SETSIZE' undeclared (first use in this 
>function)
>miscutils/taskset.c:22: error: (Each undeclared identifier is reported only 
>once
>miscutils/taskset.c:22: error: for each function it appears in.)
>cc1: warnings being treated as errors
>miscutils/taskset.c:26: warning: implicit declaration of function 'CPU_ISSET'
>miscutils/taskset.c: In function 'taskset_main':
>miscutils/taskset.c:67: warning: implicit declaration of function 'CPU_ZERO'
>miscutils/taskset.c:68: error: 'CPU_SETSIZE' undeclared (first use in this 
>function)
>miscutils/taskset.c:70: warning: implicit declaration of function 'CPU_SET'
>miscutils/taskset.c:77: warning: implicit declaration of 
>function 'sched_getaffinity'
>miscutils/taskset.c:85: warning: implicit declaration of 
>function 'sched_setaffinity'
>make[1]: *** [miscutils/taskset.o] Error 1
>make: *** [miscutils] Error 2
>
>-- 
>Wang, Baojun                                        Lanzhou University
>Distributed & Embedded System Lab              http://dslab.lzu.edu.cn
>School of Information Science and Engeneering        wangbj at lzu.edu.cn
>Tianshui South Road 222. Lanzhou 730000                     .P.R.China
>Tel:+86-931-8912025                                Fax:+86-931-8912022



>_______________________________________________
>busybox mailing list
>busybox at busybox.net
>http://busybox.net/cgi-bin/mailman/listinfo/busybox

From somlo at cmu.edu  Thu Feb  1 13:07:00 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 16:07:00 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <78a54e1b0701301258k5e2446fdi90a4c69bb7e4d0e7@mail.gmail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<78a54e1b0701291906i58239c8at93fe71bab40b1da2@mail.gmail.com>
	<20070130195006.GD21905@hedwig.net.cmu.edu>
	<78a54e1b0701301258k5e2446fdi90a4c69bb7e4d0e7@mail.gmail.com>
Message-ID: <20070201210700.GA20549@hedwig.net.cmu.edu>

On Tue, Jan 30, 2007 at 02:58:50PM -0600, Jason Schoon wrote:
> On 1/30/07, Gabriel L. Somlo <somlo at cmu.edu> wrote:
> >And what to do about all the (pre isc 3.1.0) clients that just dump the
> >content of option 15 into the search string ? :)
> 
> They still will.  Or they will disregard the option entirely.

So, the way I see it, 3.1.0 and later clients will first look for the
domain-search option to add to resolv.conf, and default to domain-name
if the former isn't being sent by the server. As far as pre-3.1.0
clients:

> They will not
> have your patch, so they will not be expecting to receive multiple strings
> in a single field.  They will be expecting this field to contain a single
> domain value.

no, they'll expect a single string :) which may contain spaces. Which
is the way this is being done today, via the domain-name option.
Here's a quote from the dhcp-options man page that comes with 3.1.0a3:

	The domain-search option specifies a 'search list' of
	Domain Names to be used by the client to locate
	not-fully-qualified domain names. The difference between
	this option and historic use of the domain-name option
	                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	for the same ends is that this option is encoded in
	^^^^^^^^^^^^^^^^^^
	RFC1035 compressed labels on the wire.

The problem with udhcpd is that it won't allow quoted strings to be
parsed from the udhcpd.conf file (which would allow passing single
strings that contain spaces).

So, we either complicate parsing of strings from the config file, or
we make certain string-type options listable, and insert single spaces
between members of the "list", ending up with longer strings that
contain spaces.

We'd have to do one or the other of these anyway, even for RFC3397, as
we'll try to pass multiple strings (or one space-separated line of
them) to the domain-search option.

My patch did this in one of the two possible ways. Do you think it
should be done the other way (i.e., by adding support for parsing
quoted strings from the config file) ?

Speaking of RFC3397, I've written a compact function that expands
RFC1035-compressed strings, and it's included at the bottom of this
email, if anyone wants to poke at it. I'm working on a compression
function, at which time I'll whip up a patch to add 3397 to udhcpd.

Either way, adding 3397 support won't fix my original problem, which
is to support passing space-separated strings via the domain-name
option, which is something lots of people do, today, with isc dhcpd...

Cheers.
Gabriel


#define NS_CMPRSFLGS 0xc0	/* name compression pointer flag */

/* expand a RFC1035-compressed list of domain names "src", of length "slen";
 * returns a newly allocated string containing the space-separated domains,
 * or NULL if an error occurs.
 */
char *ns_name_expand(const unsigned char *src, unsigned slen) {
	const unsigned char *c;
	unsigned crtpos, retpos, len = 0;
	char *dst = NULL;

	if (!src || !slen)
		return NULL;

	/* We make two passes over the src string. First, we compute
	 * how long the resulting string would be. Then we allocate a
	 * new buffer of the required length, and fill it in with the
	 * expanded content. The advantage of this approach is not
	 * having to deal with requiring callers to supply their own
	 * buffer, then having to check if it's sufficiently large, etc.
	 */

	while (!dst) {

		if (len > 0)	/* second pass? allocate dst buffer */
			dst = xmalloc(len);

		len = crtpos = retpos = 0;

		while (crtpos < slen) {
			c = src + crtpos;

			if (*c & NS_CMPRSFLGS) { /* pointer */
				if (retpos == 0) /* toplevel? save ret. spot */
					retpos = crtpos + 2;
				crtpos = *(c + 1);/* jump to pointed location */
			} else if (*c) { /* label */
				if (dst)
					memcpy(dst + len, c + 1, *c);
				len += (*c + 1);
				crtpos += (*c + 1);
				if (dst)
					*(dst + len - 1) = '.';
			} else {  /* null -- end of current domain name */
				if (retpos == 0) { /* toplevel? keep going */
					crtpos++;
				} else {   /* go back to toplevel saved spot */
					crtpos = retpos;
					retpos = 0;
				}
				if (dst)
					*(dst + len - 1) = ' ';
			}
		}

		if (dst)
			*(dst + len - 1) = '\0';
	}

	return dst;
}

From vda.linux at googlemail.com  Thu Feb  1 14:08:20 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:08:20 +0100
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <20070126170058.GA31444@hedwig.net.cmu.edu>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
Message-ID: <200702012308.20367.vda.linux@googlemail.com>

On Friday 26 January 2007 18:00, Gabriel L. Somlo wrote:
> Denis & All,
> 
> Whatever I specify as the value for "option domain" in udhcpd.conf
> ends up being on the "search" line in my client's /etc/resolv.conf
> 
> As such, I discovered that specifying multiple values for
> "option domain" doesn't work with udhcpd.
> 
> The following patch fixes that by making "domain" accept a list of
> options, and by insuring that STRING type options with multiple values
> end up being separated by spaces (instead of being cat-ed together).
> 
> Let me know what you think.
> 
> Thanks,
> Gabriel 
> 
> 
> diff -NarU5 busybox-svn-17463.orig/networking/udhcp/files.c busybox-svn-17463/networking/udhcp/files.c
> --- busybox-svn-17463.orig/networking/udhcp/files.c	2007-01-22 11:17:58.000000000 -0500
> +++ busybox-svn-17463/networking/udhcp/files.c	2007-01-26 11:52:26.000000000 -0500
> @@ -106,11 +106,16 @@
>  	if (existing) {
>  		DEBUG("Attaching option %s to existing member of list", option->name);
>  		if (option->flags & OPTION_LIST) {
>  			if (existing->data[OPT_LEN] + length <= 255) {
>  				existing->data = realloc(existing->data,

realloc? why not xrealloc?

> -						existing->data[OPT_LEN] + length + 2);
> +						existing->data[OPT_LEN] + length + 3);
> +				if ((option->flags & TYPE_MASK) == OPTION_STRING) {
> +					/* add space separator between STRING options in a list */
> +					*(existing->data + existing->data[OPT_LEN] + 2) = ' ';
> +					existing->data[OPT_LEN]++;
> +				}
>  				memcpy(existing->data + existing->data[OPT_LEN] + 2, buffer, length);
>  				existing->data[OPT_LEN] += length;

You can overflow existing->data[OPT_LEN].

The below version should fix that (and even mostly fit
into 80 column displays). Can you try it?

static void attach_option(struct option_set **opt_list,
                const struct dhcp_option *option, char *buffer, int length)
{
        struct option_set *existing, *new, **curr;

        existing = find_option(*opt_list, option->code);
        if (!existing) {
                DEBUG("Attaching option %s to list", option->name);

                /* make a new option */
                new = xmalloc(sizeof(struct option_set));
                new->data = xmalloc(length + 2);
                new->data[OPT_CODE] = option->code;
                new->data[OPT_LEN] = length;
                memcpy(new->data + 2, buffer, length);

                curr = opt_list;
                while (*curr && (*curr)->data[OPT_CODE] < option->code)
                        curr = &(*curr)->next;

                new->next = *curr;
                *curr = new;
                return;
        }

        /* add it to an existing option */
        DEBUG("Attaching option %s to existing member of list", option->name);
        if (option->flags & OPTION_LIST) {
                if (existing->data[OPT_LEN] + length <= 255) {
                        existing->data = xrealloc(existing->data,
                                        existing->data[OPT_LEN] + length + 3);
                        if ((option->flags & TYPE_MASK) == OPTION_STRING) {
                                if (existing->data[OPT_LEN] + length >= 255)
                                        return;
                                /* add space separator between STRING options in a list */
                                existing->data[existing->data[OPT_LEN] + 2] = ' ';
                                existing->data[OPT_LEN]++;
                        }
                        memcpy(existing->data + existing->data[OPT_LEN] + 2, buffer, length);
                        existing->data[OPT_LEN] += length;
                } /* else, ignore the data, we could put this in a second option in the future */
        } /* else, ignore the new data */
}

--
vda

From vda.linux at googlemail.com  Thu Feb  1 14:15:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:15:51 +0100
Subject: version 1.4.1
In-Reply-To: <45C19F00.4060903@marcant.net>
References: <45C19F00.4060903@marcant.net>
Message-ID: <200702012315.51620.vda.linux@googlemail.com>

On Thursday 01 February 2007 09:04, Markus Wigge wrote:
> Hi,
> 
> I'm a little bit confused, I recently read about busybox 1.4.1 and found 
> an archive I could download but there is no tag for it in subversion and 
> it is not announced on the web?
> 
> Is this an official version or what?

I added relevant text in news.html in busybox cvs and expected it
to appear at busybox.net after a day or so, but it didn't.
(I planned to announce it after it is there)

I was a bit busy and didn't ask people why it is so.

Anyway, 1.4.1 is 1.4.0 plus these:

http://busybox.net/downloads/fixes-1.4.0/

--
vda

From vda.linux at googlemail.com  Thu Feb  1 14:21:40 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:21:40 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
Message-ID: <200702012321.40884.vda.linux@googlemail.com>

On Thursday 01 February 2007 07:26, Brion Finlay wrote:
> This seems like it should be a simple question that other people have had
> problems with, but I cannot get Busybox to build.  I have tried google-ing
> for similar problems, searching the mail archives, and reading the FAQs and
> all of the documentation, but I cannot figure out what is going on.
> 
> I am using a fairly fresh install of Ubuntu 6.1, and I have installed enough
> of the development packages to build a custom kernel.  (I mention this
> because Ubuntu does not preinstall many development packages, so it is
> possible I am still missing some, but I have installed quite a few.)
> 
> The GCC version is 4.1.2.
> sed is GNU Sed version 4.1.5
>
> Here are the compile problems that I get:
> 
> Busybox 1.4.1
> # make defconfig; make
> 
> ...
> include/bbconfigopts.h:1088: error: missing terminating " character
> (repeated for each line)
> include/bbconfigopts.h:1089: error: expected expression before ';' token
> make[1]: *** [miscutils/bbconfig.o] Error 1
> make: *** [miscutils] Error 2

gcc 4.1.1, glibc 2.4, gnu sed 4.1.5, bbox 1.4.1: 

# make defconfig; make
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/split-include
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  HOSTCC  scripts/kconfig/mconf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf -d Config.in
/.local/tmp/busybox-1.4.1/scripts/defconfig:351:warning: trying to assign nonexistent symbol E2FSCK
/.local/tmp/busybox-1.4.1/scripts/defconfig:354:warning: trying to assign nonexistent symbol MKE2FS
/.local/tmp/busybox-1.4.1/scripts/defconfig:355:warning: trying to assign nonexistent symbol TUNE2FS
/.local/tmp/busybox-1.4.1/scripts/defconfig:356:warning: trying to assign nonexistent symbol E2LABEL
/.local/tmp/busybox-1.4.1/scripts/defconfig:357:warning: trying to assign nonexistent symbol FINDFS
/.local/tmp/busybox-1.4.1/scripts/defconfig:635:warning: symbol value '' invalid for FEATURE_COMMAND_HISTORY
*
* Busybox Configuration
*
*
* Busybox Settings
*
*
* General Configuration
*
See lots more (probably unnecessary) configuration options. (NITPICK) [N/y/?] n
Enable options for full-blown desktop systems (DESKTOP) [N/y/?] n
...
envdir (ENVDIR) [Y/n/?] y
softlimit (SOFTLIMIT) [Y/n/?] y
  SPLIT   include/autoconf.h -> include/config/*
  GEN     include/bbconfigopts.h
  HOSTCC  applets/usage
  GEN     include/usage_compressed.h
  CC      applets/applets.o
  CC      applets/busybox.o
...
  CC      util-linux/switch_root.o
  CC      util-linux/umount.o
  AR      util-linux/lib.a
  LINK    busybox_unstripped

include/bbconfigopts.h from build tree is attached.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bbconfigopts.h
Type: text/x-chdr
Size: 16270 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/6425a36c/attachment.h 

From vda.linux at googlemail.com  Thu Feb  1 14:22:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:22:56 +0100
Subject: Busybox build problem
In-Reply-To: <20070201002140.bfc52cea95091b0fffcb409eab6296ba.9cd207e1ee.wbe@email.secureserver.net>
References: <20070201002140.bfc52cea95091b0fffcb409eab6296ba.9cd207e1ee.wbe@email.secureserver.net>
Message-ID: <200702012322.56287.vda.linux@googlemail.com>

On Thursday 01 February 2007 08:21, akennedy at techmoninc.com wrote:
> 
> > I'm sure it is something wrong with my environment, but I do not know what.  Does anyone have any hints?
> Attempt the build with BuildRoot.  This will install uclibc and a gcc
> that will work with it to build BusyBox.  I've found it VERY difficult
> to build BusyBox with GLibC.

Really?! I do it all the time...

Please report what are the problems.
Provide gcc, glibc version, .config...
--
vda

From vda.linux at googlemail.com  Thu Feb  1 14:36:52 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:36:52 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <1170276931.18296.5.camel@studio>
References: <1170276931.18296.5.camel@studio>
Message-ID: <200702012336.52095.vda.linux@googlemail.com>

On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> The attatched patch adds support for option -user. The arg to -user can
> be either username or uid.
>
> Would be nice if it could be committed.
> Thanks!

+???????????????????????ap->uid = bb_strtoul(arg1, (char **)NULL, 10);

Why you use *strtoul* and then assign it to unsigned *int*?
Why cast?

Otherwise looks ok, applying...
--
vda

From vda.linux at googlemail.com  Thu Feb  1 14:57:03 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Thu, 1 Feb 2007 23:57:03 +0100
Subject: CGI script and Content-type change in 1.4.0
In-Reply-To: <45C0533A.5000309@lkh-vil.or.at>
References: <45C0533A.5000309@lkh-vil.or.at>
Message-ID: <200702012357.03564.vda.linux@googlemail.com>

On Wednesday 31 January 2007 09:28, Alexander Griesser wrote:
> Hi folks!
> 
> Another thing that broke when upgrading to 1.4.0 is the management
> interface for my thinclients.
> 
> Previously, I used the following command to output a valid HTML header:
> 
> echo 'Content-type: text/html
> 
> 
> <html>
> <head>
> ...'
> 
> Now, with busybox 1.4.0, this doesn't work anymore.
> I get exactly the same output as written above in firefox (IE7 works
> fine).
> 
> I had a look at the changelog and found the following entry:
> 
> || httpd: stop adding our own "Content-type:" to CGI output
> 
> Additionally, I found a cgi-example (httpd_index_cgi_example) inside
> the busybox distribution that suggests do pipe all output generated
> through "dd bs=4k" with the following comment:
> 
> # Pipe thru dd (need to write header as single write(),
> # or else httpd doesn't see "Content-type: text/html"
> # in first read() and decides that it is not html)
> 
> Why is this needed with the current busybox release or are there any
> ways to work around this?

This piping not needed anymore, it has been fixed
after indexer example was addded.

Regarding your script: I must admit I am not a CGI expert,
but maybe you need to echo "HTTP/1.0 200 OK\r\n" first.

I just tested and cgi indexer works (also without piping thru dd),
so at least this cgi example is working.

If you definitely know that CGI should not print "200 OK"
(IOW: that https server process should add that instead),
please give me the URL so that I can educate myself too.

Thanks.
--
vda

From vapier at gentoo.org  Thu Feb  1 15:16:23 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 1 Feb 2007 18:16:23 -0500
Subject: version 1.4.1
In-Reply-To: <200702012315.51620.vda.linux@googlemail.com>
References: <45C19F00.4060903@marcant.net>
	<200702012315.51620.vda.linux@googlemail.com>
Message-ID: <200702011816.24169.vapier@gentoo.org>

On Thursday 01 February 2007, Denis Vlasenko wrote:
> I was a bit busy and didn't ask people why it is so.

looks like svn locks got screwed up ... i cleared them and it should be OK now
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/66ae121a/attachment.pgp 

From vda.linux at googlemail.com  Thu Feb  1 15:14:21 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 00:14:21 +0100
Subject: extra targets in busybox Makefile
In-Reply-To: <200702010312.34740.vapier@gentoo.org>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
	<200702010312.34740.vapier@gentoo.org>
Message-ID: <200702020014.21335.vda.linux@googlemail.com>

On Thursday 01 February 2007 09:12, Mike Frysinger wrote:
> On Monday 29 January 2007, Denis Vlasenko wrote:
> > I propose to simply never define anything "modular"
> >
> > If people run "make modules",  well, that's their problems.
> 
> there are a bunch of env config settings which can cause problems ... what i'm 
> looking at is busybox gets integrated into a larger build system which 
> includes a kernel and next thing i know, busybox is failing because it's 
> trying to generate depmod and build modules

Huh, if this is really getting problematic,
then feel free to chainsaw "modular" support off.

Or just rename makefile targets ('modules' -> 'dont_use_me__modules')
if you don't want to spend too much time on things which
do not materially improve generated code.
--
vda

From strange at nsk.no-ip.org  Thu Feb  1 15:44:35 2007
From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha)
Date: Thu, 1 Feb 2007 23:44:35 +0000
Subject: CGI script and Content-type change in 1.4.0
In-Reply-To: <200702012357.03564.vda.linux@googlemail.com>
References: <45C0533A.5000309@lkh-vil.or.at>
	<200702012357.03564.vda.linux@googlemail.com>
Message-ID: <20070201234435.GA6908@nsk.no-ip.org>

On Thu, Feb 01, 2007 at 11:57:03PM +0100, Denis Vlasenko wrote:
> If you definitely know that CGI should not print "200 OK"
> (IOW: that https server process should add that instead),
> please give me the URL so that I can educate myself too.

Links with specs:
http://hoohoo.ncsa.uiuc.edu/cgi/out.html
http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html#7.0

Basically, there are two different types of CGI scripts (the method to
distinguish between the two types is implementation defined; the first
link defines cgi prefix of nph-):
1. non-parsed header (NPH) output (support not required)
  - all output is sent as is to the client (full HTTP response is
    created by the script)

2. parsed header output (support required)
  - one of the following headers must be present, and will be parsed by
    the server (not limited to one, but no repetitions are allowed):
    * Content-type: the Internet Media Type of the entity body,
       which is to be sent unmodified to the client.
    * Location: specify to the server that the script is
       returning a reference to a document rather than an actual
       document:
      - absolute uri: Location: http://.... -> 302 redirect (unless
        Status also defined);
      - or path: Location: /path/... -> server internally processes the
        redirect and the output is as if the new location was directly
        called (POST and other requests may lose the request body).
    * Status: indicates to the server what status code the server MUST
      use in the response message: Status: [0-9]{3} reason-phrase

  - output consists of header plus body (body may be null):
    * if body, Content-type is mandatory
    * else one of Location or Status is mandatory

  - headers are specified on a single line
  
Also, #8.1 on the second link, Requirements for Servers, should be of
interest.

-- 
lfr
0/0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070201/48863634/attachment.pgp 

From vda.linux at googlemail.com  Thu Feb  1 17:14:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 02:14:33 +0100
Subject: busybox 1.4.1 build failure
In-Reply-To: <20070201140323.4dc138fa.aurel@gnuage.org>
References: <20070201140323.4dc138fa.aurel@gnuage.org>
Message-ID: <200702020214.33849.vda.linux@googlemail.com>

On Thursday 01 February 2007 14:03, Aurelien Jacobs wrote:
> Hi,
> 
> When upgrading from bb-1.4.0 to bb-1.4.1 I got the following error
> (gcc-4.1.1, uClibc for i386 target):
> 
>   CC      networking/interface.o
> cc1: warnings being treated as errors
> networking/interface.c: In function 'in_ether':
> networking/interface.c:853: warning: pointer targets in assignment differ in signedness
> make[1]: *** [networking/interface.o] Error 1
> make: *** [networking] Error 2
> 
> The attached patch fixes it.

thanks, applied
--
vda

From somlo at cmu.edu  Thu Feb  1 17:23:04 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 20:23:04 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702012308.20367.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
Message-ID: <20070202012303.GA23689@hedwig.net.cmu.edu>

On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> You can overflow existing->data[OPT_LEN].

Yes, by exactly 1 :)

>         /* add it to an existing option */

...

>                 if (existing->data[OPT_LEN] + length <= 255) {
>                         existing->data = xrealloc(existing->data,
>                                         existing->data[OPT_LEN] + length + 3);
>                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {
>                                 if (existing->data[OPT_LEN] + length >= 255)
>                                         return;

You already know that's never going to be more than 255 (see the if
statement at the beginning of the quote :) What you don't know is
whether the extra space I want to add will make it 256 instead of 255.
So, maybe do this:

>                               if (existing->data[OPT_LEN] + length + 1>= 255)
                                                                     ^^^^^
>                                         return;

The other choice would be to do this:

>                 if (existing->data[OPT_LEN] + length <= 254) {
                                                        ^^^^^^^
>                         existing->data = xrealloc(existing->data,
>                                         existing->data[OPT_LEN] + length + 3);
>                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {

and drop the second check entirely. I'd almost vote for this, but then
we'd be depriving non-string options of one potential byte. Makes the
code cleaner, though... I guess you're the decider :)

Otherwise, it compiles cleanly, and looks ok to me. Won't be able to
test it until some 15 hours from now, though, since I'll have to
physically hook up a dhcp client to the box which is in my office...

Cheers,
Gabriel

From vda.linux at googlemail.com  Thu Feb  1 17:55:13 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 02:55:13 +0100
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <20070202012303.GA23689@hedwig.net.cmu.edu>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
	<20070202012303.GA23689@hedwig.net.cmu.edu>
Message-ID: <200702020255.13687.vda.linux@googlemail.com>

On Friday 02 February 2007 02:23, Gabriel L. Somlo wrote:
> On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> > You can overflow existing->data[OPT_LEN].
> 
> Yes, by exactly 1 :)
> 
> >         /* add it to an existing option */
> 
> ...
> 
> >                 if (existing->data[OPT_LEN] + length <= 255) {
> >                         existing->data = xrealloc(existing->data,
> >                                         existing->data[OPT_LEN] + length + 3);
> >                         if ((option->flags & TYPE_MASK) == OPTION_STRING) {
> >                                 if (existing->data[OPT_LEN] + length >= 255)
> >                                         return;
> 
> You already know that's never going to be more than 255 (see the if
> statement at the beginning of the quote :) What you don't know is
> whether the extra space I want to add will make it 256 instead of 255.
> So, maybe do this:
> 
> >                               if (existing->data[OPT_LEN] + length + 1>= 255)
>                                                                      ^^^^^
> >                                         return;

No. My check is really

		if (existing->data[OPT_LEN] + length == 255)

that is, "is it exactly 255? that wont fit because of +1!"
but I use >= because of sheer paranoia. ;)

--
vda

From somlo at cmu.edu  Thu Feb  1 19:21:42 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 1 Feb 2007 22:21:42 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702020255.13687.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
	<20070202012303.GA23689@hedwig.net.cmu.edu>
	<200702020255.13687.vda.linux@googlemail.com>
Message-ID: <20070202032142.GA24474@hedwig.net.cmu.edu>

On Fri, Feb 02, 2007 at 02:55:13AM +0100, Denis Vlasenko wrote:
> 
> No. My check is really
> 
> 		if (existing->data[OPT_LEN] + length == 255)
> 
> that is, "is it exactly 255? that wont fit because of +1!"
> but I use >= because of sheer paranoia. ;)

Heh... You're right, of course...

That's why I like using computers -- you only have to get this
crap right once, and won't keep having to worry about spotting
that equal sign after the > sign... Or something... :) :)

Cheers,
Gabriel

From natanael.copa at gmail.com  Thu Feb  1 23:09:50 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 02 Feb 2007 08:09:50 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <200702012336.52095.vda.linux@googlemail.com>
References: <1170276931.18296.5.camel@studio>
	<200702012336.52095.vda.linux@googlemail.com>
Message-ID: <1170400190.28276.11.camel@localhost>

On Thu, 2007-02-01 at 23:36 +0100, Denis Vlasenko wrote:
> On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> > The attatched patch adds support for option -user. The arg to -user can
> > be either username or uid.
> >
> > Would be nice if it could be committed.
> > Thanks!
> 
> +                       ap->uid = bb_strtoul(arg1, (char **)NULL, 10);
> 
> Why you use *strtoul* and then assign it to unsigned *int*?

You are right. The uid type should ofcourse be uid_t and not int.

The xuname2uid() returns a long (why not uid_t?) so i think I could use
strtol() instead of bb_strtou().

> Why cast?

When I was looking for a atoi with error detection in libbb I found that
the atoi man-page states that the atoi behaviour is the same as

              strtol(nptr, (char **)NULL, 10);

The cast comes from there.

Sorry for the type confusion. New patch is attatched.

> Otherwise looks ok, applying...

Thanks!

> --
> vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-uid_t.patch
Type: text/x-patch
Size: 886 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070202/bddb1e2f/attachment.bin 

From somlo at cmu.edu  Fri Feb  2 06:25:53 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Fri, 2 Feb 2007 09:25:53 -0500
Subject: PATCH: udhcpd "option domain" multiple values
In-Reply-To: <200702012308.20367.vda.linux@googlemail.com>
References: <20070126170058.GA31444@hedwig.net.cmu.edu>
	<200702012308.20367.vda.linux@googlemail.com>
Message-ID: <20070202142553.GA8714@hedwig.net.cmu.edu>

On Thu, Feb 01, 2007 at 11:08:20PM +0100, Denis Vlasenko wrote:
> The below version should fix that (and even mostly fit
> into 80 column displays). Can you try it?

Tried it, and it looks like it's working fine.

Thanks,
Gabriel

From natanael.copa at gmail.com  Fri Feb  2 07:01:30 2007
From: natanael.copa at gmail.com (Natanael Copa)
Date: Fri, 02 Feb 2007 16:01:30 +0100
Subject: [PATCH] find ! ... (operator -not)
Message-ID: <1170428490.28276.35.camel@localhost>

Hi,

Attatched is a patch for support of the '!' operator for find.

I created another macro ALLOC_TEST for actions that can be inverted with
'!'. They are not really actions (like -print) but tests (like -name).

It should not touch anything unless you have enabled the
FEATURE_FIND_NOT config option.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: find-operator-not.patch
Type: text/x-patch
Size: 5665 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070202/a13eb967/attachment-0001.bin 

From mcross at irobot.com  Fri Feb  2 09:24:21 2007
From: mcross at irobot.com (Cross, Matthew)
Date: Fri, 2 Feb 2007 12:24:21 -0500
Subject: Revisiting an old losetup bug (bug 609)
Message-ID: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>

I have run into this old bug.  I'm using an old version of busybox
(1.1.3) on an i.MX21 embedded system (it's ARM based).  I understand
what's going on and how it could be fixed but I'm not sure if it's a
busybox bug or a problem with the toolchain.  Looking at the code, the
problem is still in the latest source.  Let me explain:
 
In my case, I'm using a "BSP" provided by Freescale for this chip.  They
provide a pre-built toolchain (binutils, gcc, glibc).  When the
toolchain was built, kernel headers from a 2.6.11 kernel were used by
glibc.  The kernel that is running on the board is a heavily patched
2.4.20 kernel.  Therefore, when libbb/loop.c is compiled it sees a 2.6
kernel, and so uses LOOP_GET_STATUS64 for BB_LOOP_GET_STATUS - note that
this is ioctl 0x4c05 (if you look in the strace output in the log of bug
609 you see this ioctl there, so it looks like the original submitter
had a similar problem).  However, the loop driver in 2.4 kernels does
not support the 64 bit variants of these ioctl's, only the 32 bit
LOOP_GET_STATUS (which is 0x4c03).  When I hack loop.c to use the 2.4
version of the code, it works on my system properly, so clearly the 2.4
kernel supports the loop device fine.
 
Busybox could be modified to work in this scenario by trying the 32 bit
version of the ioctl if the 64 bit version fails, but I don't know if
that goes against the low-bloat philosophy of busybox.  Does the busybox
dev team feel that this is a problem with the build system, or should a
busybox built with headers from a 2.6 kernel work with a 2.4 kernel?
The vendor I am working from has argued that userland applications
should not depend on kernel headers and that this toolchain has been
working for several years with this processor and kernel.
 
    -Matt
 
--
Matt Cross
Senior Lead Software Engineer
iRobot Corporation
63 South Avenue, Burlington, MA 01803
781-418-3373 (ph)
781-345-0201 (fax)
mcross at irobot.com
www.irobot.com <http://www.irobot.com/> 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070202/6186fc96/attachment.htm 

From rob at landley.net  Fri Feb  2 11:58:58 2007
From: rob at landley.net (Rob Landley)
Date: Fri, 2 Feb 2007 14:58:58 -0500
Subject: extra targets in busybox Makefile
In-Reply-To: <200702010312.34740.vapier@gentoo.org>
References: <200701282116.46840.vapier@gentoo.org>
	<200701300108.09929.vda.linux@googlemail.com>
	<200702010312.34740.vapier@gentoo.org>
Message-ID: <200702021458.59394.rob@landley.net>

On Thursday 01 February 2007 3:12 am, Mike Frysinger wrote:
> On Monday 29 January 2007, Denis Vlasenko wrote:
> > I propose to simply never define anything "modular"
> >
> > If people run "make modules",  well, that's their problems.
> 
> there are a bunch of env config settings which can cause problems ... what 
i'm 
> looking at is busybox gets integrated into a larger build system which 
> includes a kernel and next thing i know,

What do you mean by "integrated into a larger build system"?  Busybox's 
menuconfig is not the same as the kernel's (version skew among other things).  
If you write your own Config and use your own menuconfig infrastructure, you 
have to debug your new code as well, correct?

> busybox is failing because it's  
> trying to generate depmod and build modules

Because your "larger build system" (which we didn't write) is calling make 
modules on busybox?

What exactly is going on here?

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

From vda.linux at googlemail.com  Fri Feb  2 12:17:30 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 21:17:30 +0100
Subject: Revisiting an old losetup bug (bug 609)
In-Reply-To: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>
References: <712A2DEC228C7448978CBD7A7AD5B09002F5613F@fever.wardrobe.irobot.com>
Message-ID: <200702022117.30601.vda.linux@googlemail.com>

On Friday 02 February 2007 18:24, Cross, Matthew wrote:
> In my case, I'm using a "BSP" provided by Freescale for this chip.  They
> provide a pre-built toolchain (binutils, gcc, glibc).  When the
> toolchain was built, kernel headers from a 2.6.11 kernel were used by
> glibc.  The kernel that is running on the board is a heavily patched
> 2.4.20 kernel.  Therefore, when libbb/loop.c is compiled it sees a 2.6
> kernel, and so uses LOOP_GET_STATUS64 for BB_LOOP_GET_STATUS - note that
> this is ioctl 0x4c05 (if you look in the strace output in the log of bug
> 609 you see this ioctl there, so it looks like the original submitter
> had a similar problem).  However, the loop driver in 2.4 kernels does
> not support the 64 bit variants of these ioctl's, only the 32 bit
> LOOP_GET_STATUS (which is 0x4c03).  When I hack loop.c to use the 2.4
> version of the code, it works on my system properly, so clearly the 2.4
> kernel supports the loop device fine.
>  
> Busybox could be modified to work in this scenario by trying the 32 bit
> version of the ioctl if the 64 bit version fails, but I don't know if
> that goes against the low-bloat philosophy of busybox.

It depents on the amount of bloat. If it is something like 32 bytes
it's ok. If significantly bigger, maybe create a CONFIG_xxx for it,
or sweep it under CONFIG_DESKTOP if you are lazy.

Please, by all means, send your patch to list. Thanks.
--
vda

From vda.linux at googlemail.com  Fri Feb  2 13:19:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 22:19:11 +0100
Subject: [PATCH] support for find -user
In-Reply-To: <1170400190.28276.11.camel@localhost>
References: <1170276931.18296.5.camel@studio>
	<200702012336.52095.vda.linux@googlemail.com>
	<1170400190.28276.11.camel@localhost>
Message-ID: <200702022219.11973.vda.linux@googlemail.com>

On Friday 02 February 2007 08:09, Natanael Copa wrote:
> On Thu, 2007-02-01 at 23:36 +0100, Denis Vlasenko wrote:
> > On Wednesday 31 January 2007 21:55, Natanael Copa wrote:
> > > The attatched patch adds support for option -user. The arg to -user can
> > > be either username or uid.
> > >
> > > Would be nice if it could be committed.
> > > Thanks!
> > 
> > +                       ap->uid = bb_strtoul(arg1, (char **)NULL, 10);
> > 
> > Why you use *strtoul* and then assign it to unsigned *int*?
> 
> You are right. The uid type should ofcourse be uid_t and not int.

Ideally, yes.

> The xuname2uid() returns a long (why not uid_t?) so i think I could use
> strtol() instead of bb_strtou().

strtol treats really bizarre things like "      -" as 'numbers'.
That's why we have bb_strtoXXX.
--
vda

From vda.linux at googlemail.com  Fri Feb  2 13:43:56 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Fri, 2 Feb 2007 22:43:56 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <1170428490.28276.35.camel@localhost>
References: <1170428490.28276.35.camel@localhost>
Message-ID: <200702022243.56100.vda.linux@googlemail.com>

On Friday 02 February 2007 16:01, Natanael Copa wrote:
> Hi,
> 
> Attatched is a patch for support of the '!' operator for find.
> 
> I created another macro ALLOC_TEST for actions that can be inverted with
> '!'. They are not really actions (like -print) but tests (like -name).
> 
> It should not touch anything unless you have enabled the
> FEATURE_FIND_NOT config option.

parse_params():
invert_flag is never reset to 0. This must be a bug -
"not" shouldn't be applied to the second -name here, I think
(did not check it versus GNU find, tho...):
find ! -name '*.a' -o -name '*.b'


Now, to more cosmetic matters:


+#define LOGIC_XOR(a, b) ( (!(a)) != (!(b)) )
                         ACTS(print)
                         ACTS(name,  const char *pattern;)
 USE_FEATURE_FIND_PRINT0(ACTS(print0))
@@ -120,7 +124,13 @@
                cur_action = -1;
                do {
                        ap = app[++cur_action];
-               } while (ap && (rc = ap->f(fileName, statbuf, ap)));
+               } while (ap &&
+#if ENABLE_FEATURE_FIND_NOT
+                       (rc = LOGIC_XOR(ap->f(fileName, statbuf, ap), ap->invert))
+#else
+                       (rc = ap->f(fileName, statbuf, ap))
+#endif
+               );


This is obscure. I propose to do this instead - much easier to read:


        while ((app = appp[++cur_group])) {
                cur_action = -1;
-               do {
+               while (1) {
                        ap = app[++cur_action];
-               } while (ap && (rc = ap->f(fileName, statbuf, ap)));
-               if (!ap) {
-                       /* all actions in group were successful */
-                       break;
+                       if (!ap) {
+                               /* all actions in group were successful */
+                               return rc;
+                       }
+                       rc = ap->f(fileName, statbuf, ap);
+#if ENABLE_FEATURE_FIND_NOT
+                       if (ap->invert) rc = !rc;
+#endif
+                       if (!rc) return rc;
                }
        }
        return rc;



+#if ENABLE_FEATURE_FIND_NOT
+               else if (strcmp(arg, "!") == 0
+                       USE_DESKTOP(|| strcmp(arg, "-not") == 0)
+               ) invert_flag = 1;
+#endif

Don't torture code reader please :) How about this?

+#if ENABLE_FEATURE_FIND_NOT
+               else if (strcmp(arg, "!") == 0
+                       USE_DESKTOP(|| strcmp(arg, "-not") == 0)
+               ) {
+                       invert_flag = 1;
+               }
+#endif



        action* alloc_action(int sizeof_struct, action_fp f
                USE_FEATURE_FIND_NOT(, int invert)
        )
        {
                action *ap;
                appp[cur_group] = xrealloc(appp[cur_group], (cur_action+2) * sizeof(*appp));
                appp[cur_group][cur_action++] = ap = xmalloc(sizeof_struct);
                appp[cur_group][cur_action] = NULL;
                ap->f = f;
                USE_FEATURE_FIND_NOT( ap->invert = invert; )
                return ap;
        }
#define ALLOC_ACTION(name) (action_##name*)alloc_action(sizeof(action_##name), (action_fp) func_##name USE_FEATURE_FIND_NOT(, 0))

#define ALLOC_TEST(name) (action_##name*)alloc_action(sizeof(action_##name), (action_fp) func_##name USE_FEATURE_FIND_NOT(, invert_flag))


You do not need to pass "int invert" to alloc_action. Just use invert_flag
in alloc_action body, and forcefully reset invert_flag = 0 whenever
you are about to do ALLOC_ACTION, like when you handle -print.
(GNU find doesn't error out on "find ! -print", it simply ignores "!").

Care to produce updated patch?
--
vda

From etzvetanov at xceedium.com  Fri Feb  2 15:05:08 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 18:05:08 -0500
Subject: "ls -l" Segmentation fault
Message-ID: <45C3C3A4.9050405@xceedium.com>

Hi all,

I have compiled version 1.4.1 of BusyBox and I have put it on a little 
system for testing.
It is running Linux kernel 2.6.18.1.

If I call "ls -l" in a directory with lots of files (say /dev or even 
/usr/bin) it is pulling Segmentation Fault.
What could be wrong or I am probably not on the same page with you guys...

I tried to search in the mailing list, but I could not find (or I was 
not able to find) any recent complains
-- 
*ET

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070202/1ad4838b/attachment.html 

From ddaney at avtrex.com  Fri Feb  2 15:18:40 2007
From: ddaney at avtrex.com (David Daney)
Date: Fri, 02 Feb 2007 15:18:40 -0800
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C3A4.9050405@xceedium.com>
References: <45C3C3A4.9050405@xceedium.com>
Message-ID: <45C3C6D0.8020209@avtrex.com>

Evgueni Tzvetanov wrote:
> Hi all,
> 
> I have compiled version 1.4.1 of BusyBox and I have put it on a little 
> system for testing.
> It is running Linux kernel 2.6.18.1.
> 
> If I call "ls -l" in a directory with lots of files (say /dev or even 
> /usr/bin) it is pulling Segmentation Fault.
> What could be wrong or I am probably not on the same page with you guys...
> 

What happens when you run it under gdb?

From etzvetanov at xceedium.com  Fri Feb  2 16:02:21 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 19:02:21 -0500
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C6D0.8020209@avtrex.com>
References: <45C3C3A4.9050405@xceedium.com> <45C3C6D0.8020209@avtrex.com>
Message-ID: <45C3D10D.8010006@xceedium.com>

David Daney wrote:
> Evgueni Tzvetanov wrote:
>> Hi all,
>>
>> I have compiled version 1.4.1 of BusyBox and I have put it on a 
>> little system for testing.
>> It is running Linux kernel 2.6.18.1.
>>
>> If I call "ls -l" in a directory with lots of files (say /dev or even 
>> /usr/bin) it is pulling Segmentation Fault.
>> What could be wrong or I am probably not on the same page with you 
>> guys...
>>
>
> What happens when you run it under gdb?
It is a very small environment and I don't have a lot of stuff in the 
system.
But I think it must be a string boundary issue or something really 
small, because when I do "ls" or ls -1, it is not bombing.

I don't have ti time to look at the applet right now, but I may try next 
week. Though I think the owner should take a look at it...
Cheers.






From etzvetanov at xceedium.com  Fri Feb  2 16:49:17 2007
From: etzvetanov at xceedium.com (Evgueni Tzvetanov)
Date: Fri, 02 Feb 2007 19:49:17 -0500
Subject: "ls -l" Segmentation fault
In-Reply-To: <45C3C6D0.8020209@avtrex.com>
References: <45C3C3A4.9050405@xceedium.com> <45C3C6D0.8020209@avtrex.com>
Message-ID: <45C3DC0D.900@xceedium.com>

David Daney wrote:
> Evgueni Tzvetanov wrote:
>> Hi all,
>>
>> I have compiled version 1.4.1 of BusyBox and I have put it on a 
>> little system for testing.
>> It is running Linux kernel 2.6.18.1.
>>
>> If I call "ls -l" in a directory with lots of files (say /dev or even 
>> /usr/bin) it is pulling Segmentation Fault.
>> What could be wrong or I am probably not on the same page with you 
>> guys...
>>
>
> What happens when you run it under gdb?
Even stranger. When I call the command like (if this can help in anyway):
"busybox ls -l" it is not bombing. When I run it as "ls -l" it is bombing.


From questforhappiness at hotmail.com  Fri Feb  2 17:34:30 2007
From: questforhappiness at hotmail.com (none none)
Date: Fri, 02 Feb 2007 17:34:30 -0800
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
Message-ID: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>

Hi there,

My aventail appliances are using busybox as OS.  I checked and find that it 
is not using the new 2007 Daylight Saving Time schedule.  Does anyone know 
if there are patches or instructions to update busybox to accommodate the 
new 2007 Daylight Saving Time change?

Thank you,
Donald.

_________________________________________________________________
Laugh, share and connect with Windows Live Messenger 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline


From vda.linux at googlemail.com  Fri Feb  2 17:47:11 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 02:47:11 +0100
Subject: Patch to accommodate 2007 Daylight Saving Time change (busybox)
In-Reply-To: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>
References: <BAY123-F186FE396D92EA2CE1C10FAB99A0@phx.gbl>
Message-ID: <200702030247.11080.vda.linux@googlemail.com>

On Saturday 03 February 2007 02:34, none none wrote:
> Hi there,
> 
> My aventail appliances are using busybox as OS.  I checked and find that it 
> is not using the new 2007 Daylight Saving Time schedule.  Does anyone know 
> if there are patches or instructions to update busybox to accommodate the 
> new 2007 Daylight Saving Time change?

This is done by libc routines. If it doesn't work for you,
you should update/fix your libc.
--
vda

From brion.finlay at gmail.com  Fri Feb  2 21:14:36 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Fri, 2 Feb 2007 23:14:36 -0600
Subject: Busybox build problem
In-Reply-To: <200702012321.40884.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
Message-ID: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>

Thanks for the responses.  It helped knowing that my gnu compiler/c library
configuration was correct.  It also helped knowing what the
bbconfigopts.hwas supposed to look like.

I did some digging into the problem and found the following.  The immediate
cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
/bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
construction for generating bbconfigopts.h.  This construction contains a
"\n" sequence, which the dash echo command interprets literally.  (See the
attached bbconfigopts.h production to see what happens.)

Linking /bin/sh to /bin/bash resolved this problem and allowed the build to
complete successfully.

The fix that could be made to scripts/mkconfigs in order to work more
generally, be less indirect, and avoid some of the backslash quoting would
be to eliminate the echo "`...`" construction and just execute the command
directly.  That is, change this:

echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
"\\"" $0 "\\\\n\\"";}'`"

to this:

sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
"\\n\"";}'

I tested this change under bash and dash and it works in both shells.


Alternatively, since awk is being invoked anyway, this line could be changed
to just a single line awk invocation to do away with the sed, the grep, and
the echo:

awk '/^#? ?CONFIG_/ {gsub(/\"/,"\\\\\"",$0); print "\"" $0 "\\n\"";}'
$config

I tested this change under bash and dash and it also works in both shells.

I have also attached a patch file to mkconfigs for the single line awk
version.


On 2/1/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Thursday 01 February 2007 07:26, Brion Finlay wrote:
> > This seems like it should be a simple question that other people have
> had
> > problems with, but I cannot get Busybox to build.  I have tried
> google-ing
> > for similar problems, searching the mail archives, and reading the FAQs
> and
> > all of the documentation, but I cannot figure out what is going on.
> >
> > I am using a fairly fresh install of Ubuntu 6.1, and I have installed
> enough
> > of the development packages to build a custom kernel.  (I mention this
> > because Ubuntu does not preinstall many development packages, so it is
> > possible I am still missing some, but I have installed quite a few.)
> >
> > The GCC version is 4.1.2.
> > sed is GNU Sed version 4.1.5
> >
> > Here are the compile problems that I get:
> >
> > Busybox 1.4.1
> > # make defconfig; make
> >
> > ...
> > include/bbconfigopts.h:1088: error: missing terminating " character
> > (repeated for each line)
> > include/bbconfigopts.h:1089: error: expected expression before ';' token
> > make[1]: *** [miscutils/bbconfig.o] Error 1
> > make: *** [miscutils] Error 2
>
> gcc 4.1.1, glibc 2.4, gnu sed 4.1.5, bbox 1.4.1:
>
> # make defconfig; make
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/basic/split-include
>   HOSTCC  scripts/basic/docproc
>   HOSTCC  scripts/kconfig/conf.o
>   HOSTCC  scripts/kconfig/kxgettext.o
>   HOSTCC  scripts/kconfig/mconf.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/lex.zconf.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf -d Config.in
> /.local/tmp/busybox-1.4.1/scripts/defconfig:351:warning: trying to assign
> nonexistent symbol E2FSCK
> /.local/tmp/busybox-1.4.1/scripts/defconfig:354:warning: trying to assign
> nonexistent symbol MKE2FS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:355:warning: trying to assign
> nonexistent symbol TUNE2FS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:356:warning: trying to assign
> nonexistent symbol E2LABEL
> /.local/tmp/busybox-1.4.1/scripts/defconfig:357:warning: trying to assign
> nonexistent symbol FINDFS
> /.local/tmp/busybox-1.4.1/scripts/defconfig:635:warning: symbol value ''
> invalid for FEATURE_COMMAND_HISTORY
> *
> * Busybox Configuration
> *
> *
> * Busybox Settings
> *
> *
> * General Configuration
> *
> See lots more (probably unnecessary) configuration options. (NITPICK)
> [N/y/?] n
> Enable options for full-blown desktop systems (DESKTOP) [N/y/?] n
> ...
> envdir (ENVDIR) [Y/n/?] y
> softlimit (SOFTLIMIT) [Y/n/?] y
>   SPLIT   include/autoconf.h -> include/config/*
>   GEN     include/bbconfigopts.h
>   HOSTCC  applets/usage
>   GEN     include/usage_compressed.h
>   CC      applets/applets.o
>   CC      applets/busybox.o
> ...
>   CC      util-linux/switch_root.o
>   CC      util-linux/umount.o
>   AR      util-linux/lib.a
>   LINK    busybox_unstripped
>
> include/bbconfigopts.h from build tree is attached.
> --
> vda
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070202/802bfa3b/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bbconfigopts.h
Type: text/x-chdr
Size: 20606 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070202/802bfa3b/attachment-0001.h 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkconfigs.patch
Type: text/x-patch
Size: 429 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070202/802bfa3b/attachment-0001.bin 

From vapier at gentoo.org  Fri Feb  2 23:41:38 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 3 Feb 2007 02:41:38 -0500
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702030241.41425.vapier@gentoo.org>

On Saturday 03 February 2007, Brion Finlay wrote:
> The fix that could be made to scripts/mkconfigs in order to work more
> generally

another fix would be to use a POSIX compliant shell ... then there wouldnt be 
problem
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/af9e409d/attachment.pgp 

From vapier at gentoo.org  Fri Feb  2 23:44:07 2007
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 3 Feb 2007 02:44:07 -0500
Subject: build system doesnt properly detect applet rebuild requirement
Message-ID: <200702030244.08150.vapier@gentoo.org>

$ make distclean
$ make allnoconfig
$ make menuconfig
-> enable dmesg, syslog, klogd, logger
$ make
$ nano .config
-> disable syslog, klogd, logger
$ make oldconfig
$ make
<link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/97fef1e6/attachment.pgp 

From rep.dot.nop at gmail.com  Sat Feb  3 04:09:49 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:09:49 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702030244.08150.vapier@gentoo.org>
References: <200702030244.08150.vapier@gentoo.org>
Message-ID: <20070203120949.GB12488@aon.at>

On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
>$ make distclean
>$ make allnoconfig
>$ make menuconfig
>-> enable dmesg, syslog, klogd, logger
>$ make
>$ nano .config
>-> disable syslog, klogd, logger
>$ make oldconfig
>$ make
><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>-mike

Confirmed. See also vda's note that it's disfunctional:
http://busybox.net/lists/busybox/2007-January/025966.html

In the old buildsys we had a dependency like
applets.o: .config

Nowadays applets.o depends on usage_compressed.h alone.
Iff the problem turns out to be passing -include autoconf.h directly
(so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
#include "autoconf.h" into libbb.h would perhaps change that
misbehaviour. Any takers?

From vda.linux at googlemail.com  Sat Feb  3 04:07:45 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:07:45 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702030244.08150.vapier@gentoo.org>
References: <200702030244.08150.vapier@gentoo.org>
Message-ID: <200702031307.45497.vda.linux@googlemail.com>

On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> $ make distclean
> $ make allnoconfig
> $ make menuconfig
> -> enable dmesg, syslog, klogd, logger
> $ make
> $ nano .config
> -> disable syslog, klogd, logger
> $ make oldconfig
> $ make
> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> -mike

Does this patch help?
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 1914 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/2ad8d42b/attachment.bin 

From rep.dot.nop at gmail.com  Sat Feb  3 04:21:31 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:21:31 +0100
Subject: sigset_t [was: Re: svn commit: trunk/busybox/runit]
In-Reply-To: <20070203014756.DD8AE48641@busybox.net>
References: <20070203014756.DD8AE48641@busybox.net>
Message-ID: <20070203122131.GD12488@aon.at>

On Fri, Feb 02, 2007 at 05:47:56PM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-02 17:47:56 -0800 (Fri, 02 Feb 2007)
>New Revision: 17732
>
>Log:
>sigset_t blocked_sigset is too big for static (128 bytes)

and what about
$ svngrep -rl sigset_t * 
init/init.c
loginutils/vlock.c
mk.check.log
networking/inetd.c
networking/arping.c
runit/runit_lib.c
runit/svlogd.c


From rep.dot.nop at gmail.com  Sat Feb  3 04:41:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:41:21 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702031307.45497.vda.linux@googlemail.com>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
Message-ID: <20070203124121.GF12488@aon.at>

On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
>On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
>> $ make distclean
>> $ make allnoconfig
>> $ make menuconfig
>> -> enable dmesg, syslog, klogd, logger
>> $ make
>> $ nano .config
>> -> disable syslog, klogd, logger
>> $ make oldconfig
>> $ make
>> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>> -mike
>
>Does this patch help?

An IMHO cleaner approach would be the attached.

Comments?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox.fix-autoconf-dep.00.diff
Type: text/x-diff
Size: 1564 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/74944a0c/attachment.bin 

From vda.linux at googlemail.com  Sat Feb  3 04:39:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:39:51 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203120949.GB12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<20070203120949.GB12488@aon.at>
Message-ID: <200702031339.51374.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:09, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
> >$ make distclean
> >$ make allnoconfig
> >$ make menuconfig
> >-> enable dmesg, syslog, klogd, logger
> >$ make
> >$ nano .config
> >-> disable syslog, klogd, logger
> >$ make oldconfig
> >$ make
> ><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >-mike
> 
> Confirmed. See also vda's note that it's disfunctional:
> http://busybox.net/lists/busybox/2007-January/025966.html
> 
> In the old buildsys we had a dependency like
> applets.o: .config
> 
> Nowadays applets.o depends on usage_compressed.h alone.
> Iff the problem turns out to be passing -include autoconf.h directly
> (so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
> #include "autoconf.h" into libbb.h would perhaps change that
> misbehaviour. Any takers?

Attached patch should fix it. Works for me.
Can someone else confirm?

Will need big dumb patch with lots of

+int ar_main(int argc, char **argv);
 int ar_main(int argc, char **argv)

in order to suppress warnings.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 1914 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/aeffe6ef/attachment.bin 

From rep.dot.nop at gmail.com  Sat Feb  3 04:43:59 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sat, 3 Feb 2007 13:43:59 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <200702031339.51374.vda.linux@googlemail.com>
References: <200702030244.08150.vapier@gentoo.org>
	<20070203120949.GB12488@aon.at>
	<200702031339.51374.vda.linux@googlemail.com>
Message-ID: <20070203124359.GG12488@aon.at>

On Sat, Feb 03, 2007 at 01:39:51PM +0100, Denis Vlasenko wrote:
>On Saturday 03 February 2007 13:09, Bernhard Fischer wrote:
>> On Sat, Feb 03, 2007 at 02:44:07AM -0500, Mike Frysinger wrote:
>> >$ make distclean
>> >$ make allnoconfig
>> >$ make menuconfig
>> >-> enable dmesg, syslog, klogd, logger
>> >$ make
>> >$ nano .config
>> >-> disable syslog, klogd, logger
>> >$ make oldconfig
>> >$ make
>> ><link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
>> >-mike
>> 
>> Confirmed. See also vda's note that it's disfunctional:
>> http://busybox.net/lists/busybox/2007-January/025966.html
>> 
>> In the old buildsys we had a dependency like
>> applets.o: .config
>> 
>> Nowadays applets.o depends on usage_compressed.h alone.
>> Iff the problem turns out to be passing -include autoconf.h directly
>> (so, perhaps, autoconf.h isn't listed in foo.d as dep), then putting an
>> #include "autoconf.h" into libbb.h would perhaps change that
>> misbehaviour. Any takers?
>
>Attached patch should fix it. Works for me.
>Can someone else confirm?
>
>Will need big dumb patch with lots of
>
>+int ar_main(int argc, char **argv);
> int ar_main(int argc, char **argv)
>
>in order to suppress warnings.

I don't like that approach, personally.
Seen my counter-proposal that i sent a minute ago?

From vda.linux at googlemail.com  Sat Feb  3 04:49:47 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:49:47 +0100
Subject: sigset_t [was: Re: svn commit: trunk/busybox/runit]
In-Reply-To: <20070203122131.GD12488@aon.at>
References: <20070203014756.DD8AE48641@busybox.net>
	<20070203122131.GD12488@aon.at>
Message-ID: <200702031349.47336.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:21, Bernhard Fischer wrote:
> On Fri, Feb 02, 2007 at 05:47:56PM -0800, vda at busybox.net wrote:
> >Author: vda
> >Date: 2007-02-02 17:47:56 -0800 (Fri, 02 Feb 2007)
> >New Revision: 17732
> >
> >Log:
> >sigset_t blocked_sigset is too big for static (128 bytes)
> 
> and what about
> $ svngrep -rl sigset_t * 
> init/init.c
> loginutils/vlock.c
> mk.check.log
> networking/inetd.c
> networking/arping.c
> runit/runit_lib.c
> runit/svlogd.c

None of them is static (all are auto variables)
--
vda

From vda.linux at googlemail.com  Sat Feb  3 04:51:44 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:51:44 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702031351.44512.vda.linux@googlemail.com>

On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> Thanks for the responses.  It helped knowing that my gnu compiler/c library
> configuration was correct.  It also helped knowing what the
> bbconfigopts.hwas supposed to look like.
> 
> I did some digging into the problem and found the following.  The immediate
> cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
> /bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
> construction for generating bbconfigopts.h.  This construction contains a
> "\n" sequence, which the dash echo command interprets literally.  (See the
> attached bbconfigopts.h production to see what happens.)
> 
> Linking /bin/sh to /bin/bash resolved this problem and allowed the build to
> complete successfully.
> 
> The fix that could be made to scripts/mkconfigs in order to work more
> generally, be less indirect, and avoid some of the backslash quoting would
> be to eliminate the echo "`...`" construction and just execute the command
> directly.  That is, change this:
> 
> echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> "\\"" $0 "\\\\n\\"";}'`"
> 
> to this:
> 
> sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
> "\\n\"";}'
> 
> I tested this change under bash and dash and it works in both shells.

There is presumably a reason why it is done that way. Is bbconfig.h different?

Another question, does it (unmodified version, that is) work with bbox ash?
--
vda

From vda.linux at googlemail.com  Sat Feb  3 04:57:17 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 13:57:17 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203124121.GF12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
	<20070203124121.GF12488@aon.at>
Message-ID: <200702031357.17715.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:41, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
> >On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> >> $ make distclean
> >> $ make allnoconfig
> >> $ make menuconfig
> >> -> enable dmesg, syslog, klogd, logger
> >> $ make
> >> $ nano .config
> >> -> disable syslog, klogd, logger
> >> $ make oldconfig
> >> $ make
> >> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >> -mike
> >
> >Does this patch help?
> 
> An IMHO cleaner approach would be the attached.
> 
> Comments?

--- busybox_trunk/include/libbb.h???????(revision 17735)
+++ busybox_trunk/include/libbb.h???????(working copy)

+#include "autoconf.h"
?#include "platform.h"

This will make every .c file depend on .config. Change just one
CONFIG_xxx and watch make rebuild everything.

-include/usage_compressed.h: $(srctree)/include/usage.h applets/usage
+include/usage_compressed.h: include/autoconf.h $(srctree)/include/usage.h applets/usage

Maybe this is needed. Or just .config instead of include/autoconf.h?
I admit I'm not good in Makefile hacking...

--
vda

From vda.linux at googlemail.com  Sat Feb  3 05:19:10 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sat, 3 Feb 2007 14:19:10 +0100
Subject: build system doesnt properly detect applet rebuild requirement
In-Reply-To: <20070203124121.GF12488@aon.at>
References: <200702030244.08150.vapier@gentoo.org>
	<200702031307.45497.vda.linux@googlemail.com>
	<20070203124121.GF12488@aon.at>
Message-ID: <200702031419.10898.vda.linux@googlemail.com>

On Saturday 03 February 2007 13:41, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 01:07:45PM +0100, Denis Vlasenko wrote:
> >On Saturday 03 February 2007 08:44, Mike Frysinger wrote:
> >> $ make distclean
> >> $ make allnoconfig
> >> $ make menuconfig
> >> -> enable dmesg, syslog, klogd, logger
> >> $ make
> >> $ nano .config
> >> -> disable syslog, klogd, logger
> >> $ make oldconfig
> >> $ make
> >> <link failure due to applets.o still wanting syslog/klogd/logger _main funcs>
> >> -mike
> >
> >Does this patch help?
> 
> An IMHO cleaner approach would be the attached.

Why is it 'cleaner'? I checked my change: it muchly
reduces false dependencies. Isn't it nice?
--
vda

From pgf at brightstareng.com  Sat Feb  3 05:41:00 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Sat, 03 Feb 2007 08:41:00 -0500
Subject: Busybox build problem 
In-Reply-To: vapier's message of Sat, 03 Feb 2007 02:41:38 -0500.
	<200702030241.41425.vapier@gentoo.org> 
Message-ID: <28616.1170510060@brightstareng.com>

vapier wrote:
 > On Saturday 03 February 2007, Brion Finlay wrote:
 > > The fix that could be made to scripts/mkconfigs in order to work more
 > > generally
 > 
 > another fix would be to use a POSIX compliant shell ... then there wouldnt
 > be problem
 > -mike
 > 

we had the same problem with a different build system when we
moved it to ubuntu.  i did some googling at the time, but
couldn't find a definitive answer -- i expected to find a lot of
discussion on it somewhere in ubuntu-land, since it's a pretty
big change, but i didn't.  it's not clear to me that dash isn't
posix compliant, at least with regard to echo's expanding '\n'. 
but it might not be.  is there a "dash is/isn't POSIX" discussion
page out there anywhere?

in our case it was expedient (and safe) to simply replace
"#!/bin/sh" with "#!/bin/bash", but that's probably not
appropriate for busybox.

paul
=---------------------
 paul fox, pgf at brightstareng.com

From brion.finlay at gmail.com  Sat Feb  3 11:15:22 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 13:15:22 -0600
Subject: Busybox build problem
In-Reply-To: <200702031351.44512.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
	<200702031351.44512.vda.linux@googlemail.com>
Message-ID: <aa1451e00702031115l292e2079seb2d37257c051ec2@mail.gmail.com>

bbconfig.h: Yes, it seems to be a different file that is not generated by
scripts/mkconfigs.  include/config/bbconfig.h looks to be only a single
line, and it does not have quotes or "\n" in the file like
include/bbconfigopts.h.  Whether built with dash or bash using the
unmodified mkconfigs, both include/config/bbconfig.h files look like this:

#define CONFIG_BBCONFIG 1

I don't think scripts/mkconfigs generates include/config/bbconfig.h, I think
it only generates bbconfigopts.h, despite the comment in the header.  The
main evidence for this is that the include define for the .h file it
generates is always "_BBCONFIGOPTS_H", and is always generated.
include/config/bbconfig.h does not contain any of the text that is always
generated.

To be honest, though, I am not sure what IS generating the
include/config/bbconfig.h file.  Some quick greps through the source tree do
not turn anything up, but I know that this file gets replaced with a #undef
CONFIG_BBCONFIG when that option is turned off.

I could also clean up the comments and submit another patch if you are
interested.  There is another error in the comments where it refers to
scripts/config/mkconfigs instead of scripts/mkconfigs, which is propogated
to the generated bbconfigopts.h.

ash:  I just tested with ash.  The unmodified version does work with the
bbox ash.  The unmodified version also works with bash, in case that wasn't
clear from my other email.  The modified version also works with ash, bash,
and dash.

I agree, presumably there was a reason.  Maybe someone can shed some light.
I will share some of my thoughts.

It might be that the reason for using the echo "` ... `" construction is
simply to make the script look nicer, since the other lines in the script
are all echo statements.

The only difference that I see using an echo "` ... `" versus direct
execution of the command is that the echo statement could process escape
characters from the output of the backquote command.   If it isn't the
intent to process escape characters, then it seems like it might as well
execute the command directly.  In this case, the echo command of "dash" IS
processing the escape characters, and this causes a problem, so it
certainly doesn't seem like the intent is to use echo to process escape
characters (which seems like a dubious intent, anyway.)

The mkconfigs script appears to be simple.  As the comments state, it is
pulling lines from .config which start with "CONFIG_" or "# CONFIG_",
replacing " with \", and prints each line as "<string>\n".


On 2/3/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> > Thanks for the responses.  It helped knowing that my gnu compiler/c
> library
> > configuration was correct.  It also helped knowing what the
> > bbconfigopts.hwas supposed to look like.
> >
> > I did some digging into the problem and found the following.  The
> immediate
> > cause of my problem is that Ubuntu 6.1 uses the "dash" shell 0.5.3-3 for
> > /bin/sh.  At the same time, scripts/mkconfigs uses an echo "`...`"
> > construction for generating bbconfigopts.h.  This construction contains
> a
> > "\n" sequence, which the dash echo command interprets literally.  (See
> the
> > attached bbconfigopts.h production to see what happens.)
> >
> > Linking /bin/sh to /bin/bash resolved this problem and allowed the build
> to
> > complete successfully.
> >
> > The fix that could be made to scripts/mkconfigs in order to work more
> > generally, be less indirect, and avoid some of the backslash quoting
> would
> > be to eliminate the echo "`...`" construction and just execute the
> command
> > directly.  That is, change this:
> >
> > echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
>
> > "\\"" $0 "\\\\n\\"";}'`"
> >
> > to this:
> >
> > sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\""
> $0
> > "\\n\"";}'
> >
> > I tested this change under bash and dash and it works in both shells.
>
> There is presumably a reason why it is done that way. Is bbconfig.hdifferent?
>
> Another question, does it (unmodified version, that is) work with bbox
> ash?
> --
> vda
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070203/2f8b8a35/attachment.html 

From brion.finlay at gmail.com  Sat Feb  3 12:02:41 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 14:02:41 -0600
Subject: Busybox build problem
In-Reply-To: <28616.1170510060@brightstareng.com>
References: <200702030241.41425.vapier@gentoo.org>
	<28616.1170510060@brightstareng.com>
Message-ID: <aa1451e00702031202l2e85adffuf8c45864b272bf74@mail.gmail.com>

I agree Paul, I wasn't sure that dash was/wasn't compliant.  It is the
default with the latest Ubuntu for /bin/sh, which means busybox builds don't
work on Ubuntu by default.

Since the question was raised about posix compliance, I decided to go look
it up.  Here is what I found:

Here are the posix specs:
(free registration required)

Here is the main link:
http://www.unix.org/single_unix_specification/

here are some direct links:
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_02
http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_03
http://www.opengroup.org/onlinepubs/000095399/utilities/echo.html

Here are some excerpts for consideration:

2.6.3 Command Substitution
"Within the backquoted style of command substitution, backslash shall retain
its literal meaning, except when followed by: '$', '`', or '\' (dollar sign,
backquote, backslash).
...
A single-quoted or double-quoted string that begins, but does not end,
within the "`...`" sequence produces undefined results."

so a single " or ' is undefined behavior within a backquote command
substitution and cannot be escaped with a backslash.

echo:
"It is not possible to use *echo* portably across all POSIX systems unless
both *-n* (as the first argument) and escape sequences are omitted."

"The following operands shall be supported:
*string*A string to be written to standard output. If the first operand is *
-n*, or if any of the operands contain a backslash ( '\' ) character, the
results are implementation-defined....
    \nWrite a <newline>....
"

So in the POSIX specs, the echo operand is not necessarily quoted, and a
"\n" is SUPPOSED to be printed as a newline, unless the "-n" option is used
(in which case backslash escapes are implementation specific), so according
to the spec technically bash and bbox ash are non-compliant because they
print the \n instead of the newline.

"New applications are encouraged to use
*printf*<http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html>instead
of
*echo*."
"

The *echo* utility has not been made obsolescent because of its extremely
widespread use in historical applications. Conforming applications that wish
to do prompting without <newline>s or that could possibly be expecting to
echo a *-n*, should use the
*printf*<http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html>utility
derived from the Ninth Edition system.

As specified, *echo* writes its arguments in the simplest of ways. The two
different historical versions of *echo* vary in fatally incompatible ways.

The BSD *echo* checks the first argument for the string *-n* which causes it
to suppress the <newline> that would otherwise follow the final argument in
the output.

The System V *echo* does not support any options, but allows escape
sequences within its operands, as described for XSI implementations in the
OPERANDS section.

The *echo* utility does not support Utility Syntax Guideline 10 because
historical applications depend on *echo* to echo *all* of its arguments,
except for the *-n* option in the BSD version.

"
Regardless of all of this (or perhaps this is a good demonstration) -
quoting is complicated and it is probably a good idea to avoid it when
possible.  An echo "`...`" command substitution seems a little like calling
"a 

On 2/3/07, Paul Fox <pgf at brightstareng.com> wrote:
>
> vapier wrote:
> > On Saturday 03 February 2007, Brion Finlay wrote:
> > > The fix that could be made to scripts/mkconfigs in order to work more
> > > generally
> >
> > another fix would be to use a POSIX compliant shell ... then there
> wouldn't
> > be problem
> > -mike
> >
>
> we had the same problem with a different build system when we
> moved it to ubuntu.  i did some googling at the time, but
> couldn't find a definitive answer -- i expected to find a lot of
> discussion on it somewhere in ubuntu-land, since it's a pretty
> big change, but i didn't.  it's not clear to me that dash isn't
> posix compliant, at least with regard to echo's expanding '\n'.
> but it might not be.  is there a "dash is/isn't POSIX" discussion
> page out there anywhere?
>
> in our case it was expedient (and safe) to simply replace
> "#!/bin/sh" with "#!/bin/bash", but that's probably not
> appropriate for busybox.
>
> paul
> =---------------------
> paul fox, pgf at brightstareng.com
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070203/e179b110/attachment.htm 

From vda.linux at googlemail.com  Sat Feb  3 15:34:32 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 00:34:32 +0100
Subject: Busybox build problem
In-Reply-To: <aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
Message-ID: <200702040034.32257.vda.linux@googlemail.com>

On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> The fix that could be made to scripts/mkconfigs in order to work more
> generally, be less indirect, and avoid some of the backslash quoting would
> be to eliminate the echo "`...`" construction and just execute the command
> directly.  That is, change this:
> 
> echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> "\\"" $0 "\\\\n\\"";}'`"
> 
> to this:
> 
> sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\"" $0
> "\\n\"";}'
> 
> I tested this change under bash and dash and it works in both shells.

But it doesn't work for me. ;) Your sed should have three \\\ instead of five.

Can you try the attached patch? Will apply if it also works for you.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.patch
Type: text/x-diff
Size: 1349 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070204/3103bfbe/attachment.bin 

From somlo at cmu.edu  Sat Feb  3 15:58:43 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sat, 3 Feb 2007 18:58:43 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
Message-ID: <20070203235843.GA4059@hedwig.net.cmu.edu>

Denis & All,

The first part of this patch fixes BB_EXECLP in libbb.h, (it
accidentally calls execvp instead of execlp).

The rest replaces execlp and execvp calls with BB_EXECLP and
BB_EXECVP, respectively (except in the shells, where we use
STANDALONE_SHELL to accomplish this).

Once this is in, we should be able to remove hardcoded paths from
anywhere else they might still be used.

Cheers,
Gabriel

diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
--- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
@@ -559,11 +559,11 @@
 	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
 #define BB_EXECLP(prog,cmd,...) \
 	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
 #else
 #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
-#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
+#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
 #endif
 
 USE_DESKTOP(long long) int uncompress(int fd_in, int fd_out);
 int inflate(int in, int out);
 
diff -NarU5 busybox-svn-17746.orig/archival/tar.c busybox-svn-17746/archival/tar.c
--- busybox-svn-17746.orig/archival/tar.c	2007-02-03 18:17:52.000000000 -0500
+++ busybox-svn-17746/archival/tar.c	2007-02-03 18:48:50.000000000 -0500
@@ -527,11 +527,11 @@
 			dup2(tbInfo.tarFd, 1);
 
 			close(gzipStatusPipe[0]);
 			fcntl(gzipStatusPipe[1], F_SETFD, FD_CLOEXEC);	/* close on exec shows success */
 
-			execlp(zip_exec, zip_exec, "-f", NULL);
+			BB_EXECLP(zip_exec, zip_exec, "-f", NULL);
 			vfork_exec_errno = errno;
 
 			close(gzipStatusPipe[1]);
 			exit(-1);
 		} else if (gzipPid > 0) {
diff -NarU5 busybox-svn-17746.orig/console-tools/openvt.c busybox-svn-17746/console-tools/openvt.c
--- busybox-svn-17746.orig/console-tools/openvt.c	2007-02-03 18:17:52.000000000 -0500
+++ busybox-svn-17746/console-tools/openvt.c	2007-02-03 18:31:02.000000000 -0500
@@ -34,10 +34,10 @@
 		dup2(fd, STDIN_FILENO);
 		dup2(fd, STDOUT_FILENO);
 		dup2(fd, STDERR_FILENO);
 		while (fd > 2) close(fd--);
 
-		execvp(argv[2], &argv[2]);
+		BB_EXECVP(argv[2], &argv[2]);
 		_exit(1);
 	}
 	return EXIT_SUCCESS;
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/chroot.c busybox-svn-17746/coreutils/chroot.c
--- busybox-svn-17746.orig/coreutils/chroot.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/chroot.c	2007-02-03 18:32:55.000000000 -0500
@@ -31,8 +31,8 @@
 			*argv = (char *) DEFAULT_SHELL;
 		}
 		argv[1] = (char *) "-i";
 	}
 
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("cannot execute %s", *argv);
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/env.c busybox-svn-17746/coreutils/env.c
--- busybox-svn-17746.orig/coreutils/env.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/env.c	2007-02-03 18:33:53.000000000 -0500
@@ -79,11 +79,11 @@
 		}
 		++argv;
 	}
 
 	if (*argv) {
-		execvp(*argv, argv);
+		BB_EXECVP(*argv, argv);
 		/* SUSv3-mandated exit codes. */
 		xfunc_error_retval = (errno == ENOENT) ? 127 : 126;
 		bb_perror_msg_and_die("%s", *argv);
 	}
 
diff -NarU5 busybox-svn-17746.orig/coreutils/install.c busybox-svn-17746/coreutils/install.c
--- busybox-svn-17746.orig/coreutils/install.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/install.c	2007-02-03 18:49:11.000000000 -0500
@@ -124,11 +124,11 @@
 		) {
 			bb_perror_msg("cannot change ownership of %s", dest);
 			ret = EXIT_FAILURE;
 		}
 		if (flags & OPT_STRIP) {
-			if (execlp("strip", "strip", dest, NULL) == -1) {
+			if (BB_EXECLP("strip", "strip", dest, NULL) == -1) {
 				bb_perror_msg("strip");
 				ret = EXIT_FAILURE;
 			}
 		}
 		if (ENABLE_FEATURE_CLEAN_UP && isdir) free(dest);
diff -NarU5 busybox-svn-17746.orig/coreutils/nice.c busybox-svn-17746/coreutils/nice.c
--- busybox-svn-17746.orig/coreutils/nice.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/nice.c	2007-02-03 18:34:17.000000000 -0500
@@ -45,11 +45,11 @@
 		if (setpriority(PRIO_PROCESS, 0, prio) < 0) {
 			bb_perror_msg_and_die("setpriority(%d)", prio);
 		}
 	}
 
-	execvp(*argv, argv);		/* Now exec the desired program. */
+	BB_EXECVP(*argv, argv);		/* Now exec the desired program. */
 
 	/* The exec failed... */
 	xfunc_error_retval = (errno == ENOENT) ? 127 : 126; /* SUSv3 */
 	bb_perror_msg_and_die("%s", *argv);
 }
diff -NarU5 busybox-svn-17746.orig/coreutils/nohup.c busybox-svn-17746/coreutils/nohup.c
--- busybox-svn-17746.orig/coreutils/nohup.c	2007-02-03 18:17:54.000000000 -0500
+++ busybox-svn-17746/coreutils/nohup.c	2007-02-03 18:34:07.000000000 -0500
@@ -51,10 +51,10 @@
 
 	if (nullfd > 2)
 		close(nullfd);
 	signal(SIGHUP, SIG_IGN);
 
-	execvp(argv[1], argv+1);
+	BB_EXECVP(argv[1], argv+1);
 	if (ENABLE_FEATURE_CLEAN_UP && home)
 		free((char*)nohupout);
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17746.orig/e2fsprogs/fsck.c busybox-svn-17746/e2fsprogs/fsck.c
--- busybox-svn-17746.orig/e2fsprogs/fsck.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/e2fsprogs/fsck.c	2007-02-03 18:34:40.000000000 -0500
@@ -675,11 +675,11 @@
 			if (!interactive) {
 				/* NB: e2fsck will complain because of this!
 				 * Use "fsck -s" to avoid... */
 				close(0);
 			}
-			execvp(argv[0], argv);
+			BB_EXECVP(argv[0], argv);
 			bb_perror_msg_and_die("%s", argv[0]);
 		}
 	}
 
 	for (i = num_args+1; i < argc; i++)
diff -NarU5 busybox-svn-17746.orig/findutils/xargs.c busybox-svn-17746/findutils/xargs.c
--- busybox-svn-17746.orig/findutils/xargs.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/findutils/xargs.c	2007-02-03 18:35:23.000000000 -0500
@@ -58,11 +58,11 @@
 	if (p < 0)
 		bb_perror_msg_and_die("vfork");
 
 	if (p == 0) {
 		/* vfork -- child */
-		execvp(args[0], args);
+		BB_EXECVP(args[0], args);
 		exec_errno = errno;     /* set error to shared stack */
 		_exit(1);
 	}
 
 	/* vfork -- parent */
diff -NarU5 busybox-svn-17746.orig/loginutils/adduser.c busybox-svn-17746/loginutils/adduser.c
--- busybox-svn-17746.orig/loginutils/adduser.c	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/loginutils/adduser.c	2007-02-03 18:49:30.000000000 -0500
@@ -78,11 +78,11 @@
 static void passwd_wrapper(const char *login) ATTRIBUTE_NORETURN;
 
 static void passwd_wrapper(const char *login)
 {
 	static const char prog[] = "passwd";
-	execlp(prog, prog, login, NULL);
+	BB_EXECLP(prog, prog, login, NULL);
 	bb_error_msg_and_die("failed to execute '%s', you must set the password for '%s' manually", prog, login);
 }
 
 /* putpwent(3) remix */
 static int adduser(struct passwd *p, unsigned long flags)
diff -NarU5 busybox-svn-17746.orig/loginutils/login.c busybox-svn-17746/loginutils/login.c
--- busybox-svn-17746.orig/loginutils/login.c	2007-02-03 18:17:57.000000000 -0500
+++ busybox-svn-17746/loginutils/login.c	2007-02-03 18:36:35.000000000 -0500
@@ -355,11 +355,11 @@
 				setenv("LOGIN_TTY", full_tty, 1);
 				setenv("LOGIN_USER", pw->pw_name, 1);
 				setenv("LOGIN_UID", utoa(pw->pw_uid), 1);
 				setenv("LOGIN_GID", utoa(pw->pw_gid), 1);
 				setenv("LOGIN_SHELL", pw->pw_shell, 1);
-				execvp(script, t_argv);
+				BB_EXECVP(script, t_argv);
 				exit(1);
 			default: /* parent */
 				wait(NULL);
 			}
 		}
diff -NarU5 busybox-svn-17746.orig/miscutils/devfsd.c busybox-svn-17746/miscutils/devfsd.c
--- busybox-svn-17746.orig/miscutils/devfsd.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/devfsd.c	2007-02-03 18:38:06.000000000 -0500
@@ -376,11 +376,11 @@
 		exit (EXIT_SUCCESS);
 	}
 	 /* Child : if arg0 != NULL do execvp */
 	if(arg0 != NULL )
 	{
-		execvp (arg0, arg);
+		BB_EXECVP(arg0, arg);
 		msg_logger_and_die(LOG_ERR, "execvp");
 	}
 }
 
 static void safe_memcpy( char *dest, const char *src, int len)
diff -NarU5 busybox-svn-17746.orig/miscutils/setsid.c busybox-svn-17746/miscutils/setsid.c
--- busybox-svn-17746.orig/miscutils/setsid.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/setsid.c	2007-02-03 18:39:23.000000000 -0500
@@ -34,9 +34,9 @@
 	}
 	/* child */
 
 	setsid();  /* no error possible */
 
-	execvp(argv[1], argv + 1);
+	BB_EXECVP(argv[1], argv + 1);
 
 	bb_perror_msg_and_die("%s", argv[1]);
 }
diff -NarU5 busybox-svn-17746.orig/miscutils/taskset.c busybox-svn-17746/miscutils/taskset.c
--- busybox-svn-17746.orig/miscutils/taskset.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/taskset.c	2007-02-03 18:39:02.000000000 -0500
@@ -89,11 +89,11 @@
 		state += 8;
 		++argv;
 		goto print_aff;
 	}
 	++argv;
-	execvp(*argv, argv);
+	BB_EXECVP(*argv, argv);
 	bb_perror_msg_and_die("%s", *argv);
 }
 #undef OPT_p
 #undef TASKSET_PRINTF_MASK
 #undef from_cpuset
diff -NarU5 busybox-svn-17746.orig/miscutils/time.c busybox-svn-17746/miscutils/time.c
--- busybox-svn-17746.orig/miscutils/time.c	2007-02-03 18:17:56.000000000 -0500
+++ busybox-svn-17746/miscutils/time.c	2007-02-03 18:38:33.000000000 -0500
@@ -408,11 +408,11 @@
 	if (pid < 0)
 		bb_error_msg_and_die("cannot fork");
 	else if (pid == 0) {	/* If child.  */
 		/* Don't cast execvp arguments; that causes errors on some systems,
 		   versus merely warnings if the cast is left off.  */
-		execvp(cmd[0], cmd);
+		BB_EXECVP(cmd[0], cmd);
 		bb_error_msg("cannot run %s", cmd[0]);
 		_exit(errno == ENOENT ? 127 : 126);
 	}
 
 	/* Have signals kill the child but not self (if possible).  */
diff -NarU5 busybox-svn-17746.orig/networking/ifupdown.c busybox-svn-17746/networking/ifupdown.c
--- busybox-svn-17746.orig/networking/ifupdown.c	2007-02-03 18:17:50.000000000 -0500
+++ busybox-svn-17746/networking/ifupdown.c	2007-02-03 18:40:21.000000000 -0500
@@ -1002,11 +1002,11 @@
 		dup2(outfd[1], 1);
 		close(infd[0]);
 		close(infd[1]);
 		close(outfd[0]);
 		close(outfd[1]);
-		execvp(command, argv);
+		BB_EXECVP(command, argv);
 		exit(127);
 	default:			/* parent */
 		*in = fdopen(infd[1], "w");
 		*out = fdopen(outfd[0], "r");
 		close(infd[0]);
diff -NarU5 busybox-svn-17746.orig/networking/nc.c busybox-svn-17746/networking/nc.c
--- busybox-svn-17746.orig/networking/nc.c	2007-02-03 18:17:50.000000000 -0500
+++ busybox-svn-17746/networking/nc.c	2007-02-03 18:42:22.000000000 -0500
@@ -147,11 +147,11 @@
 			dup2(cfd, 0);
 			close(cfd);
 		}
 		dup2(0, 1);
 		dup2(0, 2);
-		USE_NC_EXTRA(execvp(execparam[0], execparam);)
+		USE_NC_EXTRA(BB_EXECVP(execparam[0], execparam);)
 		/* Don't print stuff or it will go over the wire.... */
 		_exit(127);
 	}
 
 	// Select loop copying stdin to cfd, and cfd to stdout.
diff -NarU5 busybox-svn-17746.orig/runit/chpst.c busybox-svn-17746/runit/chpst.c
--- busybox-svn-17746.orig/runit/chpst.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/runit/chpst.c	2007-02-03 18:42:47.000000000 -0500
@@ -308,11 +308,11 @@
 	if (env_user) euidgid(env_user);
 	if (set_user) suidgid(set_user);
 	if (OPT_nostdin) close(0);
 	if (OPT_nostdout) close(1);
 	if (OPT_nostderr) close(2);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void setuidgid(int argc, char **argv)
 {
@@ -320,11 +320,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	suidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envuidgid(int argc, char **argv)
 {
@@ -332,11 +332,11 @@
 
 	account = *++argv;
 	if (!account) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	euidgid((char*)account);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void envdir(int argc, char **argv)
 {
@@ -344,11 +344,11 @@
 
 	dir = *++argv;
 	if (!dir) bb_show_usage();
 	if (!*++argv) bb_show_usage();
 	edir(dir);
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
 
 static void softlimit(int argc, char **argv)
 {
@@ -367,8 +367,8 @@
 	if (option_mask32 & 0x200) limits = xatoul(s); // -s
 	if (option_mask32 & 0x400) limitt = xatoul(t); // -t
 	argv += optind;
 	if (!argv[0]) bb_show_usage();
 	slimit();
-	execvp(argv[0], argv);
+	BB_EXECVP(argv[0], argv);
 	bb_perror_msg_and_die("exec %s", argv[0]);
 }
diff -NarU5 busybox-svn-17746.orig/runit/runsvdir.c busybox-svn-17746/runit/runsvdir.c
--- busybox-svn-17746.orig/runit/runsvdir.c	2007-02-03 18:17:58.000000000 -0500
+++ busybox-svn-17746/runit/runsvdir.c	2007-02-03 18:43:10.000000000 -0500
@@ -71,11 +71,11 @@
 		prog[1] = (char*)name;
 		prog[2] = NULL;
 		sig_uncatch(SIGHUP);
 		sig_uncatch(SIGTERM);
 		if (pgrp) setsid();
-		execvp(prog[0], prog);
+		BB_EXECVP(prog[0], prog);
 		//pathexec_run(*prog, prog, (char* const*)environ);
 		fatal2_cannot("start runsv ", name);
 	}
 	sv[no].pid = pid;
 }
diff -NarU5 busybox-svn-17746.orig/util-linux/setarch.c busybox-svn-17746/util-linux/setarch.c
--- busybox-svn-17746.orig/util-linux/setarch.c	2007-02-03 18:17:59.000000000 -0500
+++ busybox-svn-17746/util-linux/setarch.c	2007-02-03 18:45:38.000000000 -0500
@@ -44,10 +44,10 @@
 
 	/* Try to set personality */
 	if (personality(pers) >= 0) {
 
 		/* Try to execute the program */
-		execvp(argv[0], argv);
+		BB_EXECVP(argv[0], argv);
 	}
 
 	bb_perror_msg_and_die("%s", argv[0]);
 }

From vda.linux at googlemail.com  Sat Feb  3 16:08:05 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 01:08:05 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070203235843.GA4059@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
Message-ID: <200702040108.05723.vda.linux@googlemail.com>

On Sunday 04 February 2007 00:58, Gabriel L. Somlo wrote:
> Denis & All,
> 
> The first part of this patch fixes BB_EXECLP in libbb.h, (it
> accidentally calls execvp instead of execlp).

Thanks! Consider this already fixed.

> The rest replaces execlp and execvp calls with BB_EXECLP and
> BB_EXECVP, respectively (except in the shells, where we use
> STANDALONE_SHELL to accomplish this).
> 
> Once this is in, we should be able to remove hardcoded paths from
> anywhere else they might still be used.
> 
> Cheers,
> Gabriel
> 
> diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
> --- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
> +++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
> @@ -559,11 +559,11 @@
>  	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
>  #define BB_EXECLP(prog,cmd,...) \
>  	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
>  #else

Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
(which should be a function) to save space?

>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 

It's probably too messy to make BB_EXECLP a function because of varargs...

Otherwise looks ok.
--
vda

From brion.finlay at gmail.com  Sat Feb  3 19:54:33 2007
From: brion.finlay at gmail.com (Brion Finlay)
Date: Sat, 3 Feb 2007 21:54:33 -0600
Subject: Busybox build problem
In-Reply-To: <200702040034.32257.vda.linux@googlemail.com>
References: <aa1451e00701312226t19e40c7se4c36559677086f2@mail.gmail.com>
	<200702012321.40884.vda.linux@googlemail.com>
	<aa1451e00702022114s54e67c87h800a273c69af39e0@mail.gmail.com>
	<200702040034.32257.vda.linux@googlemail.com>
Message-ID: <aa1451e00702031954m171e377fw55fdedbbba6360aa@mail.gmail.com>

Whoops, you are absolutely right.  I did not do the ash testing correctly,
but I figured out why and retested.  The patch I gave you did not work under
ash, and that was because of the extra back slash quotes, just like you say.

I tested this new patch you sent under ash and I also tested it with dash -
it works there too.

I have one more change for your patch - the comment about
"scripts/config/mkconfigs" should be "scripts/mkconfigs".  This comment gets
put into bbconfigopts.h.  I regenerated the diff with this additional change
and attached it as "4.sed.patch".  I also fixed the awk-only version and
retested it under ash.  I attached it as "4.awk.patch".   I personally like
the awk-only version a little better because it is only one invocation vs.
three invocations and two pipes for the sed | grep  | awk version, and maybe
more because it is a slick awk one-liner - but its trivial, really.  It's
just a shell script that is part of the build process.  They both work to
get the job done so they both work for me.

Thanks

Brion

On 2/3/07, Denis Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Saturday 03 February 2007 06:14, Brion Finlay wrote:
> > The fix that could be made to scripts/mkconfigs in order to work more
> > generally, be less indirect, and avoid some of the backslash quoting
> would
> > be to eliminate the echo "`...`" construction and just execute the
> command
> > directly.  That is, change this:
> >
> > echo "`sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print
> > "\\"" $0 "\\\\n\\"";}'`"
> >
> > to this:
> >
> > sed 's/\"/\\\\\"/g' $config | grep "^#\? \?CONFIG_" | awk '{print "\""
> $0
> > "\\n\"";}'
> >
> > I tested this change under bash and dash and it works in both shells.
>
> But it doesn't work for me. ;) Your sed should have three \\\ instead of
> five.
>
> Can you try the attached patch? Will apply if it also works for you.
> --
> vda
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/busybox/attachments/20070203/1a4813d7/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.sed.patch
Type: text/x-patch
Size: 1290 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/1a4813d7/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.awk.patch
Type: text/x-patch
Size: 1287 bytes
Desc: not available
Url : http://busybox.net/lists/busybox/attachments/20070203/1a4813d7/attachment-0001.bin 

From Alexander at Kriegisch.name  Sat Feb  3 21:25:29 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 06:25:29 +0100
Subject: httpd and form-based upload
Message-ID: <45C56E49.9030907@Kriegisch.name>

Hi!

I would like to know if httpd supports form-based uploads and how they
can be handled in plain shell scripts (/bin/sh). I would be glad to see
one or more sample script(s).

Kind regards
-- 
Alexander Kriegisch

From rep.dot.nop at gmail.com  Sun Feb  4 02:28:53 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 11:28:53 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702040108.05723.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
Message-ID: <20070204102853.GJ12488@aon.at>

On Sun, Feb 04, 2007 at 01:08:05AM +0100, Denis Vlasenko wrote:
>On Sunday 04 February 2007 00:58, Gabriel L. Somlo wrote:
>> Denis & All,
>> 
>> The first part of this patch fixes BB_EXECLP in libbb.h, (it
>> accidentally calls execvp instead of execlp).
>
>Thanks! Consider this already fixed.
>
>> The rest replaces execlp and execvp calls with BB_EXECLP and
>> BB_EXECVP, respectively (except in the shells, where we use
>> STANDALONE_SHELL to accomplish this).
>> 
>> Once this is in, we should be able to remove hardcoded paths from
>> anywhere else they might still be used.
>> 
>> Cheers,
>> Gabriel
>> 
>> diff -NarU5 busybox-svn-17746.orig/include/libbb.h busybox-svn-17746/include/libbb.h
>> --- busybox-svn-17746.orig/include/libbb.h	2007-02-03 18:17:57.000000000 -0500
>> +++ busybox-svn-17746/include/libbb.h	2007-02-03 18:36:09.000000000 -0500
>> @@ -559,11 +559,11 @@
>>  	execvp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd)
>>  #define BB_EXECLP(prog,cmd,...) \
>>  	execlp((find_applet_by_name(prog)) ? CONFIG_BUSYBOX_EXEC_PATH : prog, cmd, __VA_ARGS__)
>>  #else
>
>Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
>(which should be a function) to save space?

Yes, please put it into an bb_execvp
>
>>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
>> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
>> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
>
>It's probably too messy to make BB_EXECLP a function because of varargs...

Why so? We already have several functions with varargs (our print
helpers), so this is fine. I'll note that several uncommon compilers had
problems with __VA_ARGS__ in the preprocessor but work fine for varargs
for the compiler. I'd prefer to have bb_execlp as a function, too.

From rep.dot.nop at gmail.com  Sun Feb  4 02:32:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 11:32:21 +0100
Subject: svn commit: trunk/busybox: include libbb networking sysklogd
In-Reply-To: <20070204023908.12D5548601@busybox.net>
References: <20070204023908.12D5548601@busybox.net>
Message-ID: <20070204103221.GK12488@aon.at>

On Sat, Feb 03, 2007 at 06:39:08PM -0800, vda at busybox.net wrote:
>Author: vda
>Date: 2007-02-03 18:39:08 -0800 (Sat, 03 Feb 2007)
>New Revision: 17749

>Modified: trunk/busybox/include/libbb.h
>===================================================================
>--- trunk/busybox/include/libbb.h	2007-02-04 02:38:21 UTC (rev 17748)
>+++ trunk/busybox/include/libbb.h	2007-02-04 02:39:08 UTC (rev 17749)
>@@ -317,13 +317,13 @@
>  * Currently will return IPv4 or IPv6 sockaddrs only
>  * (depending on host), but in theory nothing prevents e.g.
>  * UNIX socket address being returned, IPX sockaddr etc... */
>-len_and_sockaddr* host2sockaddr(const char *host, int port);
>+len_and_sockaddr* xhost2sockaddr(const char *host, int port);
> #if ENABLE_FEATURE_IPV6
> /* Same, useful if you want to force family (e.g. IPv6) */
>-len_and_sockaddr* host_and_af2sockaddr(const char *host, int port, sa_family_t af);
>+len_and_sockaddr* xhost_and_af2sockaddr(const char *host, int port, sa_family_t af);

Why don't you mark those extern, btw?
> #else


From vda.linux at googlemail.com  Sun Feb  4 02:50:51 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 11:50:51 +0100
Subject: svn commit: trunk/busybox: include libbb networking sysklogd
In-Reply-To: <20070204103221.GK12488@aon.at>
References: <20070204023908.12D5548601@busybox.net>
	<20070204103221.GK12488@aon.at>
Message-ID: <200702041150.51385.vda.linux@googlemail.com>

On Sunday 04 February 2007 11:32, Bernhard Fischer wrote:
> On Sat, Feb 03, 2007 at 06:39:08PM -0800, vda at busybox.net wrote:
> >Author: vda
> >Date: 2007-02-03 18:39:08 -0800 (Sat, 03 Feb 2007)
> >New Revision: 17749
> 
> >Modified: trunk/busybox/include/libbb.h
> >===================================================================
> >--- trunk/busybox/include/libbb.h	2007-02-04 02:38:21 UTC (rev 17748)
> >+++ trunk/busybox/include/libbb.h	2007-02-04 02:39:08 UTC (rev 17749)
> >@@ -317,13 +317,13 @@
> >  * Currently will return IPv4 or IPv6 sockaddrs only
> >  * (depending on host), but in theory nothing prevents e.g.
> >  * UNIX socket address being returned, IPX sockaddr etc... */
> >-len_and_sockaddr* host2sockaddr(const char *host, int port);
> >+len_and_sockaddr* xhost2sockaddr(const char *host, int port);
> > #if ENABLE_FEATURE_IPV6
> > /* Same, useful if you want to force family (e.g. IPv6) */
> >-len_and_sockaddr* host_and_af2sockaddr(const char *host, int port, sa_family_t af);
> >+len_and_sockaddr* xhost_and_af2sockaddr(const char *host, int port, sa_family_t af);
> 
> Why don't you mark those extern, btw?

Function declarations are externs even if you don't put
extern keyword there, I think. extern is a must only for
variable declarations.

If you know a reason why extern should be there, please let me know.
--
vda

From vda.linux at googlemail.com  Sun Feb  4 03:03:28 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 12:03:28 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204102853.GJ12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
Message-ID: <200702041203.28506.vda.linux@googlemail.com>

On Sunday 04 February 2007 11:28, Bernhard Fischer wrote:
> >>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
> >> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
> >> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
> >
> >It's probably too messy to make BB_EXECLP a function because of varargs...
> 
> Why so? We already have several functions with varargs (our print
> helpers), so this is fine. I'll note that several uncommon compilers had
> problems with __VA_ARGS__ in the preprocessor but work fine for varargs
> for the compiler. I'd prefer to have bb_execlp as a function, too.

I have difficulty imagining how to _implement_ it.

int bb_execlp(char *prog, ...)
{
        va_list p;
	int n;
        va_start(p, prog);
        n = vexec(prog, p); ???? libc doesn't have vexec! ???
        va_end(p);
	return n;
}

Maybe it is doable with dirty tricks like calling execvp
with address of a parameter and hope that on your architecture
it will work.

But it doesn't worth the effort/complexity.
We have only four callsites of execlp.
--
vda

From rep.dot.nop at gmail.com  Sun Feb  4 03:51:21 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 12:51:21 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <200702041203.28506.vda.linux@googlemail.com>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
	<200702041203.28506.vda.linux@googlemail.com>
Message-ID: <20070204115117.GM12488@aon.at>

On Sun, Feb 04, 2007 at 12:03:28PM +0100, Denis Vlasenko wrote:
>On Sunday 04 February 2007 11:28, Bernhard Fischer wrote:
>> >>  #define BB_EXECVP(prog,cmd) execvp(prog,cmd)
>> >> -#define BB_EXECLP(prog,cmd,...) execvp(prog,cmd, __VA_ARGS__) 
>> >> +#define BB_EXECLP(prog,cmd,...) execlp(prog,cmd, __VA_ARGS__) 
>> >
>> >It's probably too messy to make BB_EXECLP a function because of varargs...
>> 
>> Why so? We already have several functions with varargs (our print
>> helpers), so this is fine. I'll note that several uncommon compilers had
>> problems with __VA_ARGS__ in the preprocessor but work fine for varargs
>> for the compiler. I'd prefer to have bb_execlp as a function, too.
>
>I have difficulty imagining how to _implement_ it.

>But it doesn't worth the effort/complexity.
>We have only four callsites of execlp.

I see. Well if it's only four callsite, then a define is fine.

cheers,

From Alexander at Kriegisch.name  Sun Feb  4 05:44:40 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 14:44:40 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5E348.2050602@Kriegisch.name>

I wrote earlier:
>> I would like to know if httpd supports form-based uploads and how
>> they can be handled in plain shell scripts (/bin/sh). I would be glad
>> to see one or more sample script(s).

Some more background info: An HTML page for form-based upload could look like this:

<html>
<body>
  <form action="/cgi-bin/do_upload.cgi" method=post enctype="multipart/form-data">
    <input type=file size=50 maxlength=100000 name="File"><br>
    <input type=submit value="Submit">
  </form>
</body>
</html>

A server-side script receiving the upload could look like this:

#!/bin/sh
echo -n -e 'HTTP/1.0 200 OK\r\n'
echo -n -e 'Content-type: text/html\r\n\r\n'

cat > /var/tmp/upload.bin
cat << EOF
<html>
<body>
  <h2>Upload finished</h2>
</body>
</html>
EOF

And this would be the content of upload.bin:

-----------------------------7d72033ac0372
Content-Disposition: form-data; name="File"; filename="I:\install\sample_upload.tar.gz"
Content-Type: application/x-gzip

(...) unencoded binary stuff (...)
-----------------------------7d72033ac0372--

So, basically, I would need a shell script which could
cut away the MIME header and footer, so as to only save 
the "unencoded binary stuff" section to disk. This may 
not be a very busybox-specific question, but anyway, 
probably I should use the limited means provided by 
busybox's shell (ash) and toolset (sed, awk, maybe others) 
to achieve. I was also hoping for an httpd  configuration
option to help me achieve my goal without having to code
a CGI upload handler in C. BTW: My busybox is running on
a DSL router.
--
Alexander Kriegisch


From somlo at cmu.edu  Sun Feb  4 05:47:37 2007
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Sun, 4 Feb 2007 08:47:37 -0500
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204102853.GJ12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
Message-ID: <20070204134737.GA10874@hedwig.net.cmu.edu>

On Sun, Feb 04, 2007 at 11:28:53AM +0100, Bernhard Fischer wrote:
> >Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
> >(which should be a function) to save space?
> 
> Yes, please put it into an bb_execvp

OK, will do that. Now, about the specifics: I could simply do what the
macro now does, i.e., check for the existance of a busybox applet and
then call execvp. Or, I could "unwind" execvp, and check for the
presence of a '/' in the program name first, then for the presence of
an applet, and last search PATH the way the real execvp does, and end
up by calling execve(), the way the real execvp does.

Do we want to keep it simple more than we care about speed (avoiding
work when the progname contains a '/') ?

Cheers,
Gabriel

From wharms at bfs.de  Sun Feb  4 06:12:02 2007
From: wharms at bfs.de (walter harms)
Date: Sun, 04 Feb 2007 15:12:02 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5E9B2.70800@bfs.de>

hi Alexander
you would like to use httpd for uploading files ? (rfc1867)
the problem is already solved and called 'ftp'. there are several
examples how to script ftp. http has a totally different target
and misuse are mostly to be punished with serve problems.

Why do you need this ?

re,
 wh


Alexander Kriegisch wrote:
> Hi!
> 
> I would like to know if httpd supports form-based uploads and how they
> can be handled in plain shell scripts (/bin/sh). I would be glad to see
> one or more sample script(s).
> 
> Kind regards

From Alexander at Kriegisch.name  Sun Feb  4 06:21:22 2007
From: Alexander at Kriegisch.name (Alexander Kriegisch)
Date: Sun, 04 Feb 2007 15:21:22 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C5E9B2.70800@bfs.de>
References: <45C56E49.9030907@Kriegisch.name> <45C5E9B2.70800@bfs.de>
Message-ID: <45C5EBE2.1050203@Kriegisch.name>

> you would like to use httpd for uploading files ? (rfc1867) the
> problem is already solved and called 'ftp'. there are several 
> examples how to script ftp. http has a totally different target and
> misuse are mostly to be punished with serve problems.
> 
> Why do you need this ?

Dear Walter,

I want to extend my router's web configuration interface, so it would be
natural to use form based upload and not open a second data transmission
channel. As you wrote, there is an RFC for form-based upload, and MIME
multiparts are known much longer than that anyway. So this should nort
be regarded a misuse, it is a standard.
--
Alexander

> Alexander Kriegisch wrote:
>> I would like to know if httpd supports form-based uploads and how
>> they can be handled in plain shell scripts (/bin/sh). I would be
>> glad to see one or more sample script(s).


From rep.dot.nop at gmail.com  Sun Feb  4 07:01:57 2007
From: rep.dot.nop at gmail.com (Bernhard Fischer)
Date: Sun, 4 Feb 2007 16:01:57 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204134737.GA10874@hedwig.net.cmu.edu>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<200702040108.05723.vda.linux@googlemail.com>
	<20070204102853.GJ12488@aon.at>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
Message-ID: <20070204150157.GN12488@aon.at>

On Sun, Feb 04, 2007 at 08:47:37AM -0500, Gabriel L. Somlo wrote:
>On Sun, Feb 04, 2007 at 11:28:53AM +0100, Bernhard Fischer wrote:
>> >Twenty one callsites. Maybe BB_EXECVP should call bb_execvp()
>> >(which should be a function) to save space?
>> 
>> Yes, please put it into an bb_execvp
>
>OK, will do that. Now, about the specifics: I could simply do what the
>macro now does, i.e., check for the existance of a busybox applet and
>then call execvp. Or, I could "unwind" execvp, and check for the
>presence of a '/' in the program name first, then for the presence of
>an applet, and last search PATH the way the real execvp does, and end
>up by calling execve(), the way the real execvp does.
>
>Do we want to keep it simple more than we care about speed (avoiding
>work when the progname contains a '/') ?

I don't think that spawning a subprogram is _that_ performance critical,
so i'd go for the simple case of looking if we've got an applet (like
the macro did) only. Also, i'd expect this to me smaller, which is the
ultimate reason there.

From nangel at nothome.org  Sun Feb  4 06:32:50 2007
From: nangel at nothome.org (Nathan Anglacos)
Date: Sun, 04 Feb 2007 09:32:50 -0500
Subject: httpd and form-based upload
In-Reply-To: <45C56E49.9030907@Kriegisch.name>
References: <45C56E49.9030907@Kriegisch.name>
Message-ID: <45C5EE92.80307@nothome.org>

[reposting to the busybox list]


Alexander Kriegisch wrote:
> Hi!
> 
> I would like to know if httpd supports form-based uploads and how they
> can be handled in plain shell scripts (/bin/sh). I would be glad to see
> one or more sample script(s).
> 
> Kind regards

Hi Alexander,

haserl (haserl.sourceforge.net) does what you are asking for.    haserl 
is a C cgi script, and works with busybox httpd.


From vda.linux at googlemail.com  Sun Feb  4 08:07:33 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 17:07:33 +0100
Subject: PATCH: replacing exec*p with BB_EXEC*P
In-Reply-To: <20070204150157.GN12488@aon.at>
References: <20070203235843.GA4059@hedwig.net.cmu.edu>
	<20070204134737.GA10874@hedwig.net.cmu.edu>
	<20070204150157.GN12488@aon.at>
Message-ID: <200702041707.33774.vda.linux@googlemail.com>

On Sunday 04 February 2007 16:01, Bernhard Fischer wrote:
> >OK, will do that. Now, about the specifics: I could simply do what the
> >macro now does, i.e., check for the existance of a busybox applet and
> >then call execvp. Or, I could "unwind" execvp, and check for the
> >presence of a '/' in the program name first, then for the presence of
> >an applet, and last search PATH the way the real execvp does, and end
> >up by calling execve(), the way the real execvp does.
> >
> >Do we want to keep it simple more than we care about speed (avoiding
> >work when the progname contains a '/') ?
> 
> I don't think that spawning a subprogram is _that_ performance critical,

Yes. PATH search is completely dwarfed by fork+exec time anyway
(on current x86 processors and kernels, fork+exec flushes entire
L1 data cache (too many pages copied/zeroed out)).
--
vda

From vda.linux at googlemail.com  Sun Feb  4 09:10:57 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 18:10:57 +0100
Subject: [PATCH] find ! ... (operator -not)
In-Reply-To: <200702022243.56100.vda.linux@googlemail.com>
References: <1170428490.28276.35.camel@localhost>
	<200702022243.56100.vda.linux@googlemail.com>
Message-ID: <200702041810.57851.vda.linux@googlemail.com>

On Friday 02 February 2007 22:43, Denis Vlasenko wrote:
> On Friday 02 February 2007 16:01, Natanael Copa wrote:
> > Hi,
> > 
> > Attatched is a patch for support of the '!' operator for find.
> > 
> > I created another macro ALLOC_TEST for actions that can be inverted with
> > '!'. They are not really actions (like -print) but tests (like -name).
> > 
> > It should not touch anything unless you have enabled the
> > FEATURE_FIND_NOT config option.
> 
> parse_params():
> invert_flag is never reset to 0. This must be a bug -
> "not" shouldn't be applied to the second -name here, I think
> (did not check it versus GNU find, tho...):
> find ! -name '*.a' -o -name '*.b'

I did it myself. find ! support is in svn. Please test.
--
vda

From wharms at bfs.de  Sun Feb  4 09:44:14 2007
From: wharms at bfs.de (walter harms)
Date: Sun, 04 Feb 2007 18:44:14 +0100
Subject: httpd and form-based upload
In-Reply-To: <45C5EE92.80307@nothome.org>
References: <45C56E49.9030907@Kriegisch.name> <45C5EE92.80307@nothome.org>
Message-ID: <45C61B6E.4010705@bfs.de>



hi nathan,
i could not find any security stuff (like preventing an rm -r /).
did you try check it out ?

maybe this is something that should go to the webpage.

re,
 wh


Nathan Anglacos wrote:
> [reposting to the busybox list]
> 
> 
> Alexander Kriegisch wrote:
>> Hi!
>>
>> I would like to know if httpd supports form-based uploads and how they
>> can be handled in plain shell scripts (/bin/sh). I would be glad to see
>> one or more sample script(s).
>>
>> Kind regards
> 
> Hi Alexander,
> 
> haserl (haserl.sourceforge.net) does what you are asking for.    haserl 
> is a C cgi script, and works with busybox httpd.
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
> 
> 

From pgf at brightstareng.com  Sun Feb  4 09:51:04 2007
From: pgf at brightstareng.com (Paul Fox)
Date: Sun, 04 Feb 2007 12:51:04 -0500
Subject: Busybox build problem 
In-Reply-To: brion.finlay's message of Sat, 03 Feb 2007 14:02:41 -0600.
	<aa1451e00702031202l2e85adffuf8c45864b272bf74@mail.gmail.com> 
Message-ID: <10826.1170611464@brightstareng.com>

 > 
 > "New applications are encouraged to use
 > *printf* ... instead of *echo*."

perhaps busybox should start moving in this direction in its
build scripts?  (i've never tried this sort of conversion myself,
and don't know whether other portability issues would emerge
as a result...)

paul
=---------------------
 paul fox, pgf at brightstareng.com

From vda.linux at googlemail.com  Sun Feb  4 13:17:09 2007
From: vda.linux at googlemail.com (Denis Vlasenko)
Date: Sun, 4 Feb 2007 22:17:09 +0100
Subject: svn commit: trunk/busybox/libbb
In-Reply-To: <20070204203239.23E9B48657@busybox.net>
References: <20070204203239.23E9B48657@busybox.net>
Message-ID: <200702042217.09589.vda.linux@googlemail.com>

On Sunday 04 February 2007 21:32, aldot at busybox.net wrote:
> -void llist_add_to(llist_t **old_head, void *data)
> +void llist_add_to(llist_t ** old_head, void *data)

Why different style for llist_t* and void*?

I think than this particular aspect of style should
be left unspecified.
--
vda

From rep.dot.nop at gmail.com  Sun Feb  4 13:50:40 2007
From: rep.do