Bug#272047: [Logcheck-devel] Bug#272047: logcheck's greplogoutput code needs cleaning

[maks attems]

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