Rob Landley | 1 Jul 01:03 2006
Picon

Re: [PATCH] shell/lash.c: set environment variable

On Friday 30 June 2006 6:01 pm, Shaun Jackman wrote:
> On 6/13/06, Rob Landley <rob <at> landley.net> wrote:
> > Ok, svn 15378.  I shrank enough from lash with the previous checkin that
> > I didn't feel guilty about adding one more feature. :)
>
> Oops, Rob. You mistakenly checked in my buggy patch from 2006-04-21.
> The bug-fixed version was posted on 2006-05-25. Here is an aggregate
> patch reverting the former and applying the latter.

You couldn't have told me this 2 hours earlier? :)

I'll queue this up as the first thing for 1.2.1.

But not today. :)

Rob
--

-- 
Never bet against the cheap plastic solution.
Shaun Jackman | 1 Jul 02:47 2006
Picon

Re: [PATCH] shell/lash.c: set environment variable

On 6/30/06, Rob Landley <rob <at> landley.net> wrote:
> You couldn't have told me this 2 hours earlier? :)
>
> I'll queue this up as the first thing for 1.2.1.
>
> But not today. :)

Bad timing on my part. =P Thanks, Rob.

Cheers,
Shaun
Dave Hylands | 1 Jul 06:36 2006
Picon

Question about ifupdown.c and udhcpc

Hi,

I've been looking into a problem where udhcpc sometimes hangs around
and sometimes goes away. I think I've narrowed the behaviour down to
this:

1 - If I bring the ethernet adapter up and no cable is plugged in,
then udhcpc quits after a few seconds.

2 - If I bring the ethernet adapter up and the cable is plugged in,
then udhcpc hangs around, even across multiple cable
removal/insertions.

I looked at the networking/ifupdown.c and saw this:

    if (execable("/sbin/udhcpc")) {
        return( execute("udhcpc -n -p /var/run/udhcpc.%iface%.pid -i "

in the dhcp_up routine. The -n option tells udhcpc to quit if it can't
get a lease, which would be the case if the cable isn't plugged in.

So my question is: is this the expected behaviour? Do I have something
else misconfigured?

Should cable insertion/removals have any impact on udhcp?

--

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
(Continue reading)

Max Okumoto | 1 Jul 09:22 2006

Re: Question about ifupdown.c and udhcpc

Some ethernet drivers detect at the phy level
if there is cable attached.  They will not allow
you to ifconfig up the interface.  So dhcpd will
fail on the open of the interface.

One way around this problem is to fork
a program/script to monitor the interface and
which it succeeds, to invoke dhcpd.

               Max

Dave Hylands <dhylands <at> gmail.com> wrote:

Hi,

I've been looking into a problem where udhcpc sometimes hangs around
and sometimes goes away. I think I've narrowed the behaviour down to
this:

1 - If I bring the ethernet adapter up and no cable is plugged in,
then udhcpc quits after a few seconds.

2 - If I bring the ethernet adapter up and the cable is plugged in,
then udhcpc hangs around, even across multiple cable
removal/insertions.

I looked at the networking/ifupdown.c and saw this:

if (execable("/sbin/udhcpc")) {
return( execute("udhcpc -n -p /var/run/udhcpc.%iface%.pid -i "

in the dhcp_up routine. The -n option tells udhcpc to quit if it can't
get a lease, which would be the case if the cable isn't plugged in.

So my question is: is this the expected behaviour? Do I have something
else misconfigured?

Should cable insertion/removals have any impact on udhcp?

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox

_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Robert P. J. Day | 1 Jul 13:20 2006
Picon

yanking all that "#if 0" and "#if 1" stuff


  now that 1.2.0 is out, i'm prepared to submit/commit patches to rip
out/clean up everything surrounded by those meaningless preprocessor
directives.  speak now or ... well, don't.

rday
Bernhard Fischer | 1 Jul 18:02 2006
Picon

Re: svn commit: trunk/busybox/networking

On Sat, Jul 01, 2006 at 08:00:01AM -0700, rpjday <at> busybox.net wrote:
>Author: rpjday
>Date: 2006-07-01 07:59:54 -0700 (Sat, 01 Jul 2006)
>New Revision: 15572

>Modified: trunk/busybox/networking/ifupdown.c
>===================================================================
>--- trunk/busybox/networking/ifupdown.c	2006-07-01 14:52:12 UTC (rev 15571)
>+++ trunk/busybox/networking/ifupdown.c	2006-07-01 14:59:54 UTC (rev 15572)
> <at>  <at>  -43,11 +43,7  <at>  <at> 
> #define MAX_INTERFACE_LENGTH 10
> #endif
> 
>-#if 0
>-#define debug_noise(fmt, args...) printf(fmt, ## args)
>-#else
> #define debug_noise(fmt, args...)
>-#endif
> 
> /* Forward declaration */
> struct interface_defn_t;

Whoever that may be..
Doing stuff like this is nonsense, to say the least.

You're breaking the conventient possibility to turn on debugging
facilities with what reasoning again?

Either do it right (export the debug_noise into config / remove all
debugging support completely; Exporting it is pointless, imo and
removing it is of questionable use anyway since it's easier to tell
people to toggle that single #if 0 to see why they fail than to delve
into a blind indirect debugging session in order to help them) or just
leave it alone.
Bernhard Fischer | 1 Jul 18:06 2006
Picon

Re: svn commit: trunk/busybox: e2fsprogs e2fsprogs/blkid e2fsprogs/ext2 etc...

On Sat, Jul 01, 2006 at 08:09:20AM -0700, rpjday <at> busybox.net wrote:
>Author: rpjday
>Date: 2006-07-01 08:09:17 -0700 (Sat, 01 Jul 2006)
>New Revision: 15573
>
>Log:
>Yet more "#if 0" content removed.
>
>
>Modified:
[]
>   trunk/busybox/scripts/objsizes
>
>
>Changeset:
[]
>Modified: trunk/busybox/scripts/objsizes
>===================================================================
>--- trunk/busybox/scripts/objsizes	2006-07-01 14:59:54 UTC (rev 15572)
>+++ trunk/busybox/scripts/objsizes	2006-07-01 15:09:17 UTC (rev 15573)
> <at>  <at>  -4,5 +4,4  <at>  <at> 
> find -name '*.o' | sed 's:^\./::' | xargs size | grep '^ *[0-9]' \
> | while read text data bss dec hex filename; do
>     printf "%9d %11d %9d %9d %s\n" $((text+data)) $text $data $bss "$filename"
>-done \
>-| sort
>+done

Was that changed on purpose or are you also leaking stuff unintentionally?
Robert P. J. Day | 1 Jul 18:41 2006
Picon

my outgoing mail server has died

  i'm trying to reply to bernhard's recent e-mails and, while i can *fetch*
my mail just fine, i can't send normally so i'm reduced to doing it through
a browser until the server comes back.  argh.  so i've seen bernhard's 
posts but i'll wait until mail is once again functioning before i respond, to 
not break the threading.

rday
Rob Landley | 1 Jul 19:19 2006
Picon

Re: [PATCH] shell/lash.c: set environment variable

On Friday 30 June 2006 6:01 pm, Shaun Jackman wrote:
> On 6/13/06, Rob Landley <rob <at> landley.net> wrote:
> > Ok, svn 15378.  I shrank enough from lash with the previous checkin that
> > I didn't feel guilty about adding one more feature. :)
>
> Oops, Rob. You mistakenly checked in my buggy patch from 2006-04-21.
> The bug-fixed version was posted on 2006-05-25. Here is an aggregate
> patch reverting the former and applying the latter.

Applied.

Rob
--

-- 
Never bet against the cheap plastic solution.
Rob Landley | 1 Jul 19:45 2006
Picon

Re: [PATCH] LDFLAGS configuration

On Friday 30 June 2006 6:19 pm, Shaun Jackman wrote:
> On 6/9/06, Rob Landley <rob <at> landley.net> wrote:
> > On Thursday 08 June 2006 6:22 pm, Shaun Jackman wrote:
> > > On 6/8/06, Shaun Jackman <sjackman <at> gmail.com> wrote:
> > > > I agree. I'd also like to see CROSS_COMPILER_PREFIX renamed to
> > > > CROSS_COMPILE, as Linux names it. It makes sense to do it at the same
> > > > time it's remove from .config.
> > >
> > > I just noticed that although the config option was named
> > > CROSS_COMPILER_PREFIX, the make variable was named CROSS. So, do the
> > > maintainers prefer to keep the make variable named CROSS, or switch to
> > > the Linux name, CROSS_COMPILE? I can see benefits to both, but we
> > > should pick one definitively.
> >
> > Go with CROSS_COMPILE.  You only have to build three things for a minimal
> > embedded system: the Linux Kernel, uClibc, and BusyBox.  It would be nice
> > if they all worked roughly the same way...
>
> As discussed above. Please apply.
>
> Cheers,
> Shaun
>
> 2006-06-30  Shaun Jackman  <sjackman <at> gmail.com>
>
> 	* (CROSS) Rename to CROSS_COMPILE and move its configuration to
> 	.config.mak.

This patch doesn't seem current.

Rob
--

-- 
Never bet against the cheap plastic solution.

Gmane