Merge ~bryce/ubuntu/+source/logwatch:eoan-merge-7.5.0-2 into ubuntu/+source/logwatch:debian/sid

I tried to track down then the logrotation change was added, but that is very old. I think this is when it was introduced:
logwatch (7.3.6.cvs20090906-1ubuntu3) maverick; urgency=low

  * conf/logfiles/*, debian/dist.conf/logfiles/*:
    Due to migration to rsyslog, the first rotation is now .1 and not .0
    (fixes LP: #606715)

 -- Thierry Carrez (ttx) <email address hidden> Mon, 06 Sep 2010 14:57:14 +0200

Can you please check if that's also the case in debian, i.e., if they are also affected by it, and then submit this change to them? Salsa may not be the best place, given https://salsa.debian.org/debian/logwatch/merge_requests/1 is still unanswered, so maybe a debian bug that we can "Closes: #xxxxxx" in our d/changelog.

I think we can drop the default-mta delta. It is provided by postfix at least since precise, as far as I can see:

precise:
root@precise:~# aptitude search '~Pdefault-mta'
p postfix - High-performance mail transport agent
p postfix:i386 - High-performance mail transport agent

trusty:
root@trusty:~# aptitude search '~Pdefault-mta'
p postfix - High-performance mail transport agent

xenial:
root@xenial:~# aptitude search '~Pdefault-mta'
p postfix - High-performance mail transport agent

bionic:
root@bionic:~# aptitude search '~Pdefault-mta'
p postfix - High-performance mail transport agent
p postfix:i386 - High-performance mail transport agent

cosmic:
root@cosmic:~# aptitude search '~Pdefault-mta'
p postfix - High-performance mail transport agent

disco:
root@disco:~# aptitude search '~Pdefault-mta'
p postfix - High-performance mail transport agent

I tracked it down to this change in 2009:
postfix (2.6.2~rc1-1) unstable; urgency=low

  [Wietse Venema]

  * New upstream release: 2.6.2~rc1

  [LaMont Jones]

  * move postfix-add-{filter,policy} manpages to section 8, and deliver
  * provide: default-mta on ubuntu

 -- LaMont Jones <email address hidden> Wed, 03 Jun 2009 14:17:08 -0600

Good suggestions Andreas. I dug into debian and discovered they were indeed aware of the problem, incl. the specific bug that spawned our patch:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612634

However, they appear to have chosen the approach of listing both the .0 and .1 in their dist.conf/logfiles/maillog.conf file.

Presumably if there is no .0, it's just ignored? If so, perhaps this change could simply be dropped from our changeset?

Regarding the default-mta, that makes sense in relation to Christian's commit message. I agree with your analysis and will drop this change item.

> Good suggestions Andreas. I dug into debian and discovered they were indeed
> aware of the problem, incl. the specific bug that spawned our patch:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612634
>
> However, they appear to have chosen the approach of listing both the .0 and .1
> in their dist.conf/logfiles/maillog.conf file.
>
> Presumably if there is no .0, it's just ignored? If so, perhaps this change
> could simply be dropped from our changeset?

Something to check, I don't know the behavior. If you can check a few logrotate runs, see what happens, and turns out it's a no-op, then +1 for dropping that delta as well.

I read through the logwatch docs yesterday, and studied things a bit further. I've also set up an lxc install and manually ran through a few forced logrotate runs and logwatch cycles.

The behavior in question is described here:

    You can have as many LogFile entries as you wish. All the files specified
    will be merged into one input stream for any filters that use this logfile
    group. You can also use standard wildcards when you specify the filename.
    -- https://sourceforge.net/p/logwatch/git/ci/master/tree/HOWTO-Customize-LogWatch

IOW, listing mail.log.0 as well as mail.log.1 in /usr/share/logwatch/dist.conf/logfiles/maillog.conf will have no effect if the mail.log.0 is missing. I've verified this in the sut: http://paste.ubuntu.com/p/Pvwc6kfYRM/

So, we can indeed drop the delta.

I also looked through the other config files in logwatch/*.conf/logfiles/ for any irregularities. Everything looks ok as far as I understand, except for /usr/share/logwatch/default.conf/logfiles/vdr.conf. It lists "LogFile = vdr.log.0", but iiuc that should more correctly be "LogFile = vdr.log.1". I'll file a bug report on this; I don't think it's necessary to be addressed in this merge.

Above finding reported at https://bugs.launchpad.net/ubuntu/+source/logwatch/+bug/1830109