[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1079617: marked as done (logcheck and logrotate snippets are no longer shipped)

Your message dated Wed, 23 Oct 2024 13:21:55 +0200
with message-id <576e0c6c-5dd3-40e3-8ea0-34291e803a65@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 owner@bugs.debian.org
immediately.)


-- 
1079617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079617
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: syslog-ng-core
Version: 4.4.0-3
Severity: important
X-Debbugs-Cc: debian.axhn@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>

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
Hi,
On Fri, 18 Oct 2024 08:38:50 +0200 Christoph Biedl <debian.axhn@manchmal.in-ulm.de> wrote: 
Control: reassign 1079617 release.debian.org
Control: affects 1079617 + src:syslog-ng
Control: severity normal
User: release.debian.org@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: syslog-ng@packages.debian.org
X-Debbugs-Cc: debian.axhn@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 ---
Reply to: