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? > 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.html Um, not sure how that mail applies -- it's talking about gzip, not the sh-httpd permissions problem. > > 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). > > 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. > 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. -- Dan Harkless [EMAIL PROTECTED] http://harkles.org/dan/ ------------------------------------------------------- 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
