Your message dated Wed, 23 Oct 2024 13:21:55 +0200
with message-id <576e0c6c-5dd3-40e3-8ea0-34291e803...@debian.org>
and subject line Re: logcheck and logrotate snippets are no longer shipped
has caused the Debian Bug report #1079617,
regarding logcheck and logrotate snippets are no longer shipped
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1079617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079617
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: syslog-ng-core
Version: 4.4.0-3
Severity: important
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Dear maintainer,
starting with 4.4.0-3, the syslog-ng-core package no longer ships snippets
related to logcheck and logrotate:
```
$ dpkg -c syslog-ng-core_4.4.0-3_amd64.deb | grep -E 'log(check|rotate)'
$
```
While previously:
```
$ dpkg -c /tmp/syslog-ng-core_4.4.0-2_amd64.deb | grep -E 'log(check|rotate)'
drwxr-xr-x root/root 0 2024-07-27 10:46 ./etc/logcheck/
drwxr-xr-x root/root 0 2024-07-27 10:46
./etc/logcheck/ignore.d.paranoid/
-rw-r--r-- root/root 390 2024-05-04 17:23
./etc/logcheck/ignore.d.paranoid/syslog-ng
drwxr-xr-x root/root 0 2024-07-27 10:46 ./etc/logcheck/ignore.d.server/
-rw-r--r-- root/root 631 2024-05-04 17:23
./etc/logcheck/ignore.d.server/syslog-ng
drwxr-xr-x root/root 0 2024-07-27 10:46
./etc/logcheck/violations.ignore.d/
-rw-r--r-- root/root 300 2024-05-04 17:23
./etc/logcheck/violations.ignore.d/syslog-ng
drwxr-xr-x root/root 0 2024-07-27 10:46 ./etc/logrotate.d/
-rw-r--r-- root/root 534 2024-05-04 17:23 ./etc/logrotate.d/syslog-ng
$
```
Now checking your packaging repository, there's nothing related to that
change. Even more confusing, rebuilding 4.4.0-3 locally yields a package
with the desired content. Now I reckon the issue might be in debhelper
but it must have has been fixed recently then (4.4.0-2 was build using
debhelper 13.18, 4.4.0-3 using 13.18, now it's already 13.20).
So perhaps just do another upload, and things should be fine again.
Christoph
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.39 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages syslog-ng-core depends on:
ii libc6 2.39-7
ii libcap2 1:2.66-5
ii libglib2.0-0t64 2.81.2-1
pn libivykis0t64 <none>
ii libjson-c5 0.17-1+b1
pn libnet1 <none>
ii libpcre2-8-0 10.42-4+b1
ii libssl3t64 3.3.1-7
ii libsystemd0 256.5-1+jj1+deb99
ii libwrap0 7.6.q-33
ii sysvinit-utils [lsb-base] 3.10-1
Versions of packages syslog-ng-core recommends:
pn logrotate <none>
Versions of packages syslog-ng-core suggests:
pn syslog-ng-mod-add-contextual-data <none>
pn syslog-ng-mod-amqp <none>
pn syslog-ng-mod-examples <none>
pn syslog-ng-mod-geoip2 <none>
pn syslog-ng-mod-graphite <none>
pn syslog-ng-mod-http <none>
pn syslog-ng-mod-mongodb <none>
pn syslog-ng-mod-python <none>
pn syslog-ng-mod-rdkafka <none>
pn syslog-ng-mod-redis <none>
pn syslog-ng-mod-riemann <none>
pn syslog-ng-mod-slog <none>
pn syslog-ng-mod-snmp <none>
pn syslog-ng-mod-sql <none>
pn syslog-ng-mod-stardate <none>
pn syslog-ng-mod-stomp <none>
pn syslog-ng-mod-xml-parser <none>
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Hi,
On Fri, 18 Oct 2024 08:38:50 +0200 Christoph Biedl
<debian.a...@manchmal.in-ulm.de> wrote:
Control: reassign 1079617 release.debian.org
Control: affects 1079617 + src:syslog-ng
Control: severity normal
User: release.debian....@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: syslog...@packages.debian.org
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
This missed a Cc to debian-release@, as debbugs doesn't Cc the target package
when reassigning.
nmu syslog-ng_4.4.0-3 . ANY . unstable . -m "Rebuild to restore logrotate and
logcheck snippet"
Hello,
as outlined earlier in this bug, the syslog-ng-core package no longer
contains the snippets related to logcheck and logrotate. This was caused
by a glitch in debhelper 13.17 and 13.18 where under some circumstances
the according files in debian/ were not properly processed. Therefore
this package is currently rc-buggy (Policy 10.8, Log files).
Please schedule a binNMU for src:syslog-ng 4.4.0-3, this will restore
these snippets.
Additionally, I've spent some time looking for other packages that
suffer from the same problem but didn't find any. The following steps
were done:
* Rebuild syslog-ng with various debhelper versions.
* Identify debhelper 13.17 as the first "bad" version. It appeared in
the archives on Aug 13th.
* Identify debhelper 13.19 as the first "good again" version, appeared
on Aug 18th.
* As there is no way I'm aware of to identify packages built using a
particular version of a given build dependency: Find all the packages in
today's unstable that appeared between (including) August 13th and
August 19th, so likely were built using the affected debhelper versions.
* Compare the version of the package with the one listed in the last
dinstall run before the appearance of the bad debhelper, as available
via at http://snapshot.debian.org/archive/debian/20240813T144616Z
* If the snapshot version has a logrotate and/or logcheck snippet but
the later version does not, this is a candidate.
* Make sure this was not a deliberate maintainer decision.
Only syslog-ng was reported in this check after processing about 1280
binary packages.
There is a slight chance this check did not find all the affected
packages, especially if they were build right after the first bad
debhelper version entered the archive. If someone can provide a better
check, I'll be happy to re-run the test.
Thanks for the analysis. I don't have a better suggestion, so unless somebody
else chimes in, let's trust it.
binNMU scheduled.
Cheers,
Emilio
--- End Message ---
