From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3 Description of problem: New logwatch available from http://www.logwatch.org. The new 6.0.2 supersedes the 6.0.1 currently in the development directory. logwatch-6.0.2 should go into FC4test3. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Check http://www.logwatch.org 2. 3. Additional info: I believe that version 6.0.2 addresses the following open bugs: 116599 128617 132449 133940 139606 140238 140429 141116 141721 143267 146506 146507 146508 150459 151612 152419 Bug 153980 appears to be a diskcheck issue, not a logwatch issue. I could not reproduce 119287, so it probably got fixed since it was filed.
Agreed, a cursory look here seems to suggest that a heap of open bugzilla entries some listed above, could be killed by this minor upgrade. Unfortunately all the existing patches would have to remain in, as none seem to have been picked up upstream. Having noted that, why have these not been pushed upstream by anyone? Seems silly to carry forward patches which look like they fix real problems. Or were they pushed upstream and rejected? It would make life easier on the Redhat maintainer if there were less patches to maintain, and obviously sending them upstream would achieve this. I don't mind liasing with logwatch people if no-one else has had a go already. But for now, can the maintainer possibly upgrade to 6.0.2 ? :)
Thanks for the comment, Reuben. I did not realize there were patches in the Fedora rpm; I just assumed it was a copy of the one in logwatch.org. I recently started helping with updating the logwatch source, so I can help move the patches upstream. Here is my take on them: -logwatch-2.6-101744-up2date.patch: This appears to have been fixed in the scripts/logfiles/up2date/removeheaders file. -logwatch-4.3.2-nosegfault.patch: I couldn't find the original bug report for this. I am concerned about just ignoring those strings. For example, any error message with the word "allocated" will also be ignored, or any error with the word "module". Usually it is better to define a more specific line in the filter for the service in question (kernel, in this case). -logwatch-4.3.2-nounicode.patch: It mentions bug #81144, but I can't access it. Again, it would be good to know what the problem is before applying patches. -logwatch-5.1-http400.patch: This was fixed. -logwatch-6.0.1-spaces.patch: This will go in next release. -logwatch-6.0.1-zz_disk_space.patch: This will go in next release. So more info on the logwatch-4.3.2* patches would be helpful; it's possible the problem was fixed in a different way upstream. A new release is being readied, so maybe 6.0.2 can wait. If we can solve the remaining two logwatch-4.3.2* patches now the next release might be patch-free.
Version 6.1 is now available from http://www.logwatch.org.
Thank you for your notices. The last devel version is logwatch-6.1.2-1 now.