I think rsyslog is ready to be released to both oracular-updates and noble-updates.
I have confirmed that the test plans were performed correctly, the package built on all arches, and there are no autopkgtest regressions. In particular for this bug, I also confirmed that rsyslog's own tests now pass on s390x. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/2100765 Title: Consistent DEP8/s390x failure: boot notice unexpectedly in journalctl logs Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Noble: Fix Committed Status in rsyslog source package in Oracular: Fix Committed Bug description: [ Impact ] There is a consistent autopkgtest failure in s390x only, where the logcheck test fails because there is an unexpected boot notice in the output[1]: 136s ** Running logcheck 136s This email is sent by logcheck. If you no longer wish to receive 136s such mail, you can either uninstall the logcheck package or modify 136s its configuration file (/etc/logcheck/logcheck.conf). 136s 136s System Events 136s =-=-=-=-=-=-= 136s -- Boot f50e9bf0cfe04fdbb0e7815e3d03ce39 -- 136s 136s * FAIL: unmatched lines - logcheck rules may need updating 136s This email is sent by logcheck. If you no longer wish to receive 136s such mail, you can either uninstall the logcheck package or modify 136s its configuration file (/etc/logcheck/logcheck.conf). 136s 136s System Events 136s =-=-=-=-=-=-= 136s -- Boot f50e9bf0cfe04fdbb0e7815e3d03ce39 -- 136s 137s autopkgtest [19:22:39]: test logcheck: -----------------------] 137s logcheck FAIL stderr: * FAIL: unmatched lines - logcheck rules may need updating At some point I thought it was related to the new apparmor rules that now allow reading some systemd files, but the test last worked, and started failing, with the same rsyslog version, so nothing changed in rsyslog itself. A migration-reference/0 would also fail, and then this failure would not block migration/release. But that also means the other, valuable, working, and important, tests would not be looked at. On its own, this does not warrant an SRU, but it's being bundled together with other fixes. [ Test Plan ] Since this is an autopkgtest fix, the test plan is that all autopkgtests must pass on all architectures, with no bad-test hint or migration-reference/0 help. [ Where problems could occur ] The fix is restricting the log lines that logcheck will analyze. Specifically, it's restricting them to the current system boot. If there were errors logged before the boot, logcheck will not see them. Note, however, that logcheck is already being fed just rsyslog messages from a particular timestamp that is AFTER the testbed rebooted (notice the journalctl filtering), so it's already a subset of all messages. [ Other Info ] This was only seen on s390x, and the root cause was not found. [ Original Description ] There is a consistent autopkgtest failure in s390x only, where the logcheck test fails because there is an unexpected boot notice in the output[1]: 136s ** Running logcheck 136s This email is sent by logcheck. If you no longer wish to receive 136s such mail, you can either uninstall the logcheck package or modify 136s its configuration file (/etc/logcheck/logcheck.conf). 136s 136s System Events 136s =-=-=-=-=-=-= 136s -- Boot f50e9bf0cfe04fdbb0e7815e3d03ce39 -- 136s 136s * FAIL: unmatched lines - logcheck rules may need updating 136s This email is sent by logcheck. If you no longer wish to receive 136s such mail, you can either uninstall the logcheck package or modify 136s its configuration file (/etc/logcheck/logcheck.conf). 136s 136s System Events 136s =-=-=-=-=-=-= 136s -- Boot f50e9bf0cfe04fdbb0e7815e3d03ce39 -- 136s 137s autopkgtest [19:22:39]: test logcheck: -----------------------] 137s logcheck FAIL stderr: * FAIL: unmatched lines - logcheck rules may need updating At some point I thought it was related to the new apparmor rules that now allow reading some systemd files, but the test last worked, and started failing, with the same rsyslog version, so nothing changed in rsyslog itself. Last pass: 8.2412.0-2ubuntu1 postgresql-common/274 2025-02-22 22:37:20 UTC 0h 28m 43s - pass da643947-4f61-4567-97ff-930a77206d06 log artifacts First failure after that: 8.2412.0-2ubuntu1 systemd/257.3-1ubuntu2 glibc/2.41-1ubuntu1 php-twig/3.20.0-2 samba/2:4.21.4+dfsg-1ubuntu1 symfony/6.4.18+dfsg-1ubuntu1 tinysparql/3.8.2-3 2025-02-24 19:30:36 UTC 0h 10m 13s - fail 74381588-1934-40f9-b06a-831634f68bdb log artifacts It also fails with other triggers, simpler ones: 8.2412.0-2ubuntu1 krb5/1.21.3-4ubuntu2 2025-02-26 03:56:06 UTC 0h 12m 30s - fail 90d5a082-37fe-4859-8044-4973c5d68202 log artifacts And a migration-reference/0 run from a few days before also failed, with the same error: 8.2412.0-2ubuntu1 migration-reference/0 2025-02-20 01:14:47 UTC 0h 10m 33s - fail d7415807-95c5-4bc6-8fb2-0a4c3dc1b3f6 log artifacts 1. https://autopkgtest.ubuntu.com/results/autopkgtest- plucky/plucky/s390x/r/rsyslog/20250224_193036_105c8@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2100765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
