Le Dimanche 28 Juillet 2002 02:42, Dan Harkless a �crit :
> Jacques Nilo <[EMAIL PROTECTED]> writes:
> > > Hi.  What's the best way to report bugs in Bering?  Just post here? 
> > > Email Jacques Nilo and Eric Wolzak directly?  Use the sourceforge.net
> > > tracker (I see only 11 LEAF bugs have ever been reported there)?
> >
> > The devel-list is fine.
>
> Okay, noted.  Not sure if leaf-devel allows non-subscribers to post,
> though.  Guess I'll find out with this post (attempt).  If it does get
> through, please cc me on any followup posts, as otherwise I won't see them.
>
> > The bug tracking feature is better but as you mentioned rarely used.
>
> Okay.  Well, I'd be happy to help get it into more common usage by using it
> myself.  One question, though.  Because it's rarely-used, does that mean
> it's also rarely-checked by you guys, and a leaf-devel post is less likely
> to slip through the cracks?  Or does the bug-tracking have some kind of
> feature to automatically email you guys when new bugs are reported?
Yes

> > cc to myself or Eric only fills up our mailing boxes
>
> Right.  I wasn't planning on cc'ing you on mailing list posts, just asking
> whether problems should be sent to you directly, bypassing the lists.  This
> is currently what the installation guide and user's guide say to do.
>
> > > Ditto for the installation and user's guides -- what's the best way to
> > > give feedback?
> >
> > Same as above.
>
> Although, unlike the above, it's presumably not the case that "The bug
> tracking feature is better", eh?
:-)

> Okay, a couple of documentation notes will be in a forthcoming leaf-devel
> post.
>
> > > In any case, doing a leaf-user archive search, it looks like one of the
> > > bugs I was going to report (sh-httpd should be in group 4 rather than
> > > 10, or it can't read log files after they get cycled) has already been
> > > discussed. Since the bug tracking isn't really used, though, it's not
> > > really possible to verify that this will be addressed in the successor
> > > to 1.0-rc3...
> >
> > It will. See the end of the following message:
> > http://www.mail-archive.com/[email protected]/msg05329.htm
> >l
>
> Um, not sure how that mail applies -- it's talking about gzip, not the
> sh-httpd permissions problem.
OK. That  one will be addressed in rc4 as well . I am still investigating 
this grsecurity pb

> > > I have a PPPoE system and I was very consternated that the plog script
> > > mentioned in the user's guide never gave me any output.
> > >
> > > I figured out the problem with the script:
> > >
> > >     #!/bin/sh
> > >
> > >     if [ -s /var/log/ppp.log ]; then
> > >       exec tail "$@" /var/log/ppp.log
> > >     else
> > >       exec tail "$@" /var/log/syslog | grep ' \(pppd\|chat\)\['
> > >     fi
> >
> > This is the original Debian plog script.
>
> Okay, then it's a bug in Debian, rather than a bug in LEAF, bug it's still
> a bug.  It doesn't make sense for the tail to be on the front end.  If
> you've got other things going to your log besides PPP messages, then plog
> will incorrectly make it appear that you have none of the latter (or will
> show an unpredictable and incomplete number of them).  It should be grep
> followed by tail.
>
> It's not particularly useful to get a list of "whatever PPP messages happen
> to appear amongst the last 10 (or N) general syslog messages".  It would be
> particularly useful to get "the last 10 (or N) PPP messages", and indeed
> that's inherently how the first half of the 'if' works (the PPP case), so
> why should the second half of the 'if' (the PPPoE case) work differently?
>
> > > The problem is that only the last few messages from the log (of any
> > > kind) are tailed, so it's unsurprising that usually none of them are
> > > pppd messages.  If tail is going to be used, the tail should be on the
> > > other end:
> > >
> > >       exec grep ' \(pppd\|chat\)\[' /var/log/syslog | tail "$@"
> > >
> > > Personally, though, I'd prefer it if the tail were taken out
> > > completely, especially since the BusyBox tail doesn't actually support
> > > -<number_of_lines_to_tail>, making that "$@" useless right now.
> >
> > Wrong. the "$@" parameter is precisely what makes this plog flexible: you
> > can use it to give extra parameters to tail
>
> Okay.  I assumed when tail failed to support the -<number_of_lines_to_tail>
> option that every other version of tail in the universe supports, that it
> didn't support any options at all.  In that case I guess I withdraw my
> suggestion about removing the tail, but the Bering user's guide should be
> modified to warn that plog only prints the last 10 PPP messages by default
> (or, it *will* work that way if you follow my suggestion of switching
> around the pipeline; else, you'll have to warn that plog prints some
> unpredictable number of the last PPP messages, between 0 and 10).
>
> > >From bb manual available options  are:
> >
> > Options:
> >
> >         -c N[kbm]       output the last N bytes
> >         -n N[kbm]       print last N lines instead of last 10
> >         -f              output data as the file grows
> >         -q              never output headers giving file names
> >         -s SEC          wait SEC seconds between reads with -f
> >         -v              always output headers giving file names
>
> Very useful information to have.  Is the BusyBox manual available within
> Bering, by default or as an add-on .lrp?  If not, where is it available for
> outside-Bering use?  I don't think the installation or user's guides
> address this important issue (and they should).
The busybox manual is here:
http://www.busybox.net/downloads/BusyBox.html
No lrp package planned for that one :-) We are talking about a floppy based 
distro aren't we ?

> > > Personally, I'd prefer it if plog just printed _all_ the pppd messages,
> > > leaving it to the user to pipe that output into more or tail as
> > > desired.
> >
> > I 'll leave as it is in the distro. As a policy I try to stick as much as
> > possible to Debian standards. There only very few exception (ifup/down
> > being the most notable) for space consideration.
>
> Very understandable, but as I said, I think the Debian plog is faulty (and
> perhaps they've even fixed it in a recent update).  Perhaps you could fix
> it "locally" in rc4 and report the bug to the Debian guys (if they haven't
> fixed it already) so that in the future LEAF's plog will be in sync with
> theirs, and both will have the bugfix.
Well it is still the  one which was released in theJuly Woody stable release.
Will think more about your suggested change for rc4
Jacques

> > You can easily adapt it to your taste if you want.
>
> I don't think it's a matter of taste.  I think plog is objectively wrong as
> it stands.  And I _have_ modified my copy.  I'm trying to think beyond
> myself -- when plog printed no output, I assumed something was broken (like
> pppd not doing any logging at all).  Other people wouldn't have to face
> this confusing issue if the pipeline were just switched around so that you
> always get _some_ output, if indeed pppd has logged anything.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to