Bug#272047: [Logcheck-devel] Bug#272047: logcheck's greplogoutput code needs cleaning
maks attems
debian at sternwelten.at
Sun Sep 19 09:01:24 UTC 2004
On Sat, 18 Sep 2004, Ross Boylan wrote:
..
> > i tried to rewrite it at some point in june, but failed somehow.
> > with sarge approaching we opted for a surprisingly working redundancy.
> > (we is meant for the debian logcheck team).
>
> Sounds like a reasonable decision. It would be good to fix it up for
> later releases.
yup, but it's not top priority. look at /usr/share/doc/logcheck/TODO
> > > The code is actually using every single ignore file, though the
> > > comments say it should be using only the logcheck-* files.
> > >
> Although you say you don't agree on any points, I assume you agree
> with the previous one :)
yup,
i know this comment mismatch, it was left as is,
to remember what the original author wanted to do there.
i changed it in cvs to:
# Now ignore all entries from the ignore dir
# old logcheck versions only ignored logcheck-<package> files
> > hmm i've longer no more looked at this function,
> I'm not sure what he preceding sentence means; I assume it's that you
> haven't looked at the function in a while.
:)
..
> > there could be strings raised by logcheck-postfix
> > that are ignored by local-postdrop or whatever.
>
> As the next sentence in the original indicated, my comments were
> addressed to the non-logcheck-* cases. In particular, if you're
> dealing with package foo, why use the ignore patterns in local-bar?
logcheck is very tolerant how you name your ignore files,
i find that a feature.
i do not like the current dir structure. i find it confusing,
thats for sarge+1, again it's listed in the TODO
..
> It's impossible to fix it without knowing what the desired behavior
> is, and I don't know what it is. Maybe the file you cite at the
> bottom of your message gives that.
>
> The other thing to be considered is that a lot of systems are probably
> relying on the current behavior, so there are migration and
> compatibility issues.
a rewrite of greplogouput should match current behaviour as you
said, but remove the duplicate runnings of ignore files.
a good start might be have a sane logic inside.
> > i already closed your above named bug, because of the strange
> > confusion in your proposed manpage. good bits like the FILES
> What confusion?
hmm i do not remember, i'll repost on logcheck-devel,
when the manpage rewrite gets on the surface,
another logcheck developper, who rewrote the debconf templates,
said to do it.
> > section and discussion of *all* logchek options is already done!
> > after reading this bug report i'm even less inclined to look
> > at your misinterpretations.
>
> Well, this probably belongs in the thread about that bug, but even if
> you don't like my patches, please don't close it until the
> underlying problem is solved. That problem is that you can't tell
> from the manpage how the program operates. And there are issues with
> other docs as well.
examples would be nice, but AFAIR you didn't propose that.
the other issues should be named through.
> Historically, note that some of the bits that are done are done
> because you (maks) incorporated them from 215640 into the official
> release. However, there are substantial parts that are not there--in
> fact, almost all of the most significant parts. For that reason, bug
> 215640 was already closed and reopened by a logcheck maintainer once
> before.
i know.
> >
> >
> > > I really would like to avoid the necessity of rereading the code every
> > > time I want to figure out how to fill in the configuration files :)
> >
> > /usr/share/doc/logcheck-database/README.logcheck-database.gz
> > should be enough.
> >
>
> Thanks for the pointer; it looks really useful. Perhaps that's the
> specification logcheck should try to match. Given the issues above, I
> doubt it accurately describes the current behavior. In terms of
> documentation, minimally there should be a pointer to this from the
> logcheck manpage. Since it describes the behavior of the program, it
> might be good to move it to the main logcheck package. But I'm
> wandering from the original subject of this bug.
latest logcheck(8) manpage has a pointer to that file.
speaking of version 1.2.27
--
maks
More information about the Logcheck-devel
mailing list