rsyslog FTBFS due to gzip different behavior with hw acceleration on s390x

Bug #2083700 reported by Nick Rosbrook
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Confirmed
High
bugproxy
gzip (Ubuntu)
Status tracked in Plucky
Focal
New
Undecided
Unassigned
Jammy
Confirmed
Undecided
Unassigned
Noble
Fix Committed
Undecided
Andreas Hasenack
Oracular
Fix Committed
Undecided
Andreas Hasenack
Plucky
Fix Released
Undecided
Andreas Hasenack
rsyslog (Ubuntu)
Status tracked in Plucky
Focal
New
Undecided
Unassigned
Jammy
New
Undecided
Unassigned
Noble
Invalid
Undecided
Unassigned
Oracular
Invalid
Undecided
Unassigned
Plucky
Invalid
Undecided
Unassigned
zlib (Ubuntu)
Status tracked in Plucky
Focal
New
Undecided
Unassigned
Jammy
New
Undecided
Unassigned
Noble
Incomplete
Undecided
Unassigned
Oracular
Incomplete
Undecided
Unassigned
Plucky
Incomplete
Undecided
Unassigned

Bug Description

[ Impact ]

This affects s390x only, and causes an FTBFS in rsyslog in that architecture.

For some time, the gzip package has been carrying a patch to use s390x-specific hardware acceleration, if available. That was never the case it seems, in the ubuntu s390x infrastructure.

At some point in the past year, the ubuntu s390x infrastructure got upgraded and the new hardware had support for this code that was dormant in gzip until then. This surfaced a difference in implementation between the hardware-backed code, and the software-only code, and was enough to trigger a test failure in the rsyslog package, creating an FTBFS there on s390x.

[ Test Plan ]

The test plan consists in rebuilding rsyslog on s390x, and asserting that its build-time tests pass.

Without the gzip fix, the rsyslog tests that fail are:

FAIL: gzipwr_flushInterval
FAIL: gzipwr_flushOnTXEnd

The full log can be seen in the original description of this bug.

With the gzip fix, the rsyslog tests all pass.

[ Where problems could occur ]

The fix is only affecting s390x-specific code, and only gets used on s390x hardware that has support for the used functions. If there were to be a regression, it would manifest itself on this specific hardware, and could cause all sorts of problems, as the gzip tool is used all over the place. Therefore, we also expect any regressions to be quickly found. The gzip test suite of course still passes after these changes.

[ Other Info ]

Due to the interdependency of this SRU with the rsyslog ones, the gzip package must be accepted and published before rsyslog. Specifically, these rsyslog bugs must only be accepted after gzip is accepted and published:
- https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2056768
- https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2073628
- https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2061726

If this is not observed, then rsyslog will fail to build on s390x, until the new gzip package is in proposed and published.

Upstream gzip is still discussing[1] details of this bug, tests, RFCs, and other places where the hardware implementation differs from the software one. Depending on the outcome and impact, we may SRU follow-up fixes down the road.

1. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75924

[ Original Description ]

During an archive rebuild, rsyslog FTBFS on s390x only: https://launchpadlibrarian.net/751879056/buildlog_ubuntu-oracular-s390x.rsyslog_8.2406.0-1ubuntu2_BUILDING.txt.gz

The build fails due to two tests:

FAIL: gzipwr_flushInterval
==========================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
08:47:04[0] Test: ./gzipwr_flushInterval.sh
------------------------------------------------------------
config rstb_216690_cea0d3b3Yo0x_.conf is:
     1 module(load="../plugins/imdiag/.libs/imdiag")
     2 global(inputs.timeout.shutdown="60000"
     3 default.action.queue.timeoutshutdown="20000"
     4 default.action.queue.timeoutEnqueue="20000")
     5 # use legacy-style for the following settings so that we can override if needed
     6 $MainmsgQueueTimeoutEnqueue 20000
     7 $MainmsgQueueTimeoutShutdown 10000
     8 $IMDiagListenPortFileName rstb_216690_cea0d3b3Yo0x.imdiag.port
     9 $IMDiagServerRun 0
    10 $IMDiagAbortTimeout 580
    11
    12 :syslogtag, contains, "rsyslogd" ./rstb_216690_cea0d3b3Yo0x.started
    13 ###### end of testbench instrumentation part, test conf follows:
    14
    15 module(load="../plugins/imtcp/.libs/imtcp")
    16 input(type="imtcp" port="0" listenPortFileName="rstb_216690_cea0d3b3Yo0x.tcpflood_port")
    17
    18 template(name="outfmt" type="string" string="%msg:F,58:2%\n")
    19 :msg, contains, "msgnum:" action(type="omfile" template="outfmt"
    20 zipLevel="6" ioBufferSize="256k"
    21 flushOnTXEnd="off" flushInterval="1"
    22 asyncWriting="on"
    23 file="rstb_216690_cea0d3b3Yo0x.out.log.gz")
rsyslogd: NOTE: RSYSLOG_DEBUG_TIMEOUTS_TO_STDERR activated
main Q:Reg: worker start requested, num workers currently 0
main Q:Reg: wrkr start initiated with state 0, num workers now 1
rsyslog debug: main Q:Reg: worker 0x2aa0873c810 started
rsyslog debug: main Q:Reg: started with state 3, num workers now 1
08:47:04[0] rstb_216690_cea0d3b3Yo0x:.pid found, pid 158166
08:47:04[0] rsyslogd startup msg seen, pid 158166
waiting for file rstb_216690_cea0d3b3Yo0x.imdiag.port
imdiag port: 35391
waiting for file rstb_216690_cea0d3b3Yo0x.tcpflood_port
TCPFLOOD_PORT now: 32793
starting run 1
Sending 2500 messages.

00002500 messages sent
runtime: 0.005
End of tcpflood Run

gzip: rstb_216690_cea0d3b3Yo0x.out.log.gz: invalid compressed data--format violated
scanf error in index i=0

gzip: rstb_216690_cea0d3b3Yo0x.out.log.gz: invalid compressed data--format violated
sequence error detected in rstb_216690_cea0d3b3Yo0x.out.log.gz
number of lines in file: 0 rstb_216690_cea0d3b3Yo0x.out.log.gz
sorted data has been placed in error.log, first 10 lines are:
     1 scanf error in index i=0
---last 10 lines are:
     1 scanf error in index i=0
UNSORTED data, first 10 lines are:
     1 scanf error in index i=0
---last 10 lines are:
     1 scanf error in index i=0
not reporting failure as RSYSLOG_STATSURL is not set
rsyslog pid file still exists, trying to shutdown...
rsyslogd debug: info: trying to cooperatively stop input ../plugins/imdiag/.libs/imdiag, timeout 60000 ms
rsyslogd debug: info: trying to cooperatively stop input imtcp, timeout 60000 ms
rsyslog debug: main Q:Reg/w0: enter WrkrExecCleanup
rsyslog debug: 0x2aa0873c990: worker exiting
rsyslog debug: main Q:Reg/w0: thread joined
08:47:09[5] FAIL: Test ./gzipwr_flushInterval.sh (took 5 seconds)
FAIL gzipwr_flushInterval.sh (exit status: 1)

FAIL: gzipwr_flushOnTXEnd
=========================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
08:47:04[0] Test: ./gzipwr_flushOnTXEnd.sh
------------------------------------------------------------
config rstb_586738_b0a588ae30Do_.conf is:
     1 module(load="../plugins/imdiag/.libs/imdiag")
     2 global(inputs.timeout.shutdown="60000"
     3 default.action.queue.timeoutshutdown="20000"
     4 default.action.queue.timeoutEnqueue="20000")
     5 # use legacy-style for the following settings so that we can override if needed
     6 $MainmsgQueueTimeoutEnqueue 20000
     7 $MainmsgQueueTimeoutShutdown 10000
     8 $IMDiagListenPortFileName rstb_586738_b0a588ae30Do.imdiag.port
     9 $IMDiagServerRun 0
    10 $IMDiagAbortTimeout 580
    11
    12 :syslogtag, contains, "rsyslogd" ./rstb_586738_b0a588ae30Do.started
    13 ###### end of testbench instrumentation part, test conf follows:
    14
    15 module(load="../plugins/imtcp/.libs/imtcp")
    16 input(type="imtcp" port="0" listenPortFileName="rstb_586738_b0a588ae30Do.tcpflood_port")
    17
    18 template(name="outfmt" type="string" string="%msg:F,58:2%\n")
    19 :msg, contains, "msgnum:" { action(type="omfile" template="outfmt"
    20 zipLevel="6" ioBufferSize="256k"
    21 flushOnTXEnd="on"
    22 asyncWriting="on"
    23 file="rstb_586738_b0a588ae30Do.out.log")
    24 action(type="omfile" file="rstb_586738_b0a588ae30Do.countlog")
    25 }
rsyslogd: NOTE: RSYSLOG_DEBUG_TIMEOUTS_TO_STDERR activated
main Q:Reg: worker start requested, num workers currently 0
main Q:Reg: wrkr start initiated with state 0, num workers now 1
rsyslog debug: main Q:Reg: worker 0x2aa18a89a50 started
rsyslog debug: main Q:Reg: started with state 3, num workers now 1
08:47:04[0] rstb_586738_b0a588ae30Do:.pid found, pid 158888
08:47:04[0] rsyslogd startup msg seen, pid 158888
waiting for file rstb_586738_b0a588ae30Do.imdiag.port
imdiag port: 35511
waiting for file rstb_586738_b0a588ae30Do.tcpflood_port
TCPFLOOD_PORT now: 39421
starting run 1
Sending 2500 messages.

00002500 messages sent
runtime: 0.001
End of tcpflood Run
imdiag: wait q_empty: qsize 1210 nempty 0
imdiag: wait q_empty: qsize 0 nempty 1
imdiag[35511]: mainqueue empty
test 1
wait_file_lines success, have 2500 lines, took 0 seconds, file rstb_586738_b0a588ae30Do.countlog
-rw-r--r-- 1 buildd buildd 4841 Sep 29 08:47 rstb_586738_b0a588ae30Do.out.log

gzip: stdin: invalid compressed data--format violated
chkseq: start 0, end 2499
scanf error in index i=0
sequence error detected
not reporting failure as RSYSLOG_STATSURL is not set
rsyslog pid file still exists, trying to shutdown...
rsyslogd debug: info: trying to cooperatively stop input ../plugins/imdiag/.libs/imdiag, timeout 60000 ms
rsyslogd debug: info: trying to cooperatively stop input imtcp, timeout 60000 ms
rsyslog debug: main Q:Reg/w0: enter WrkrExecCleanup
rsyslog debug: 0x2aa18a89bd0: worker exiting
rsyslog debug: main Q:Reg/w0: thread joined
08:47:05[1] FAIL: Test ./gzipwr_flushOnTXEnd.sh (took 1 seconds)
FAIL gzipwr_flushOnTXEnd.sh (exit status: 1)

--

Since these are both gzip related, I looked at zlib and noticed that there are s390x-specific optimization patches for that package: https://launchpad.net/ubuntu/+source/zlib/1:1.3.dfsg+really1.3.1-1ubuntu1.

In a PPA build, I re-built zlib without these s390x patches, and re-built rsyslog against that version. In that case, the build succeeded: https://launchpad.net/~enr0n/+archive/ubuntu/proposed-migration/+build/29141297

Therefore, I believe the cause of this FTBFS is related the s390x-specific patches in zlib. This needs investigating by someone more familiar with s390x and/or these patches.

Related branches

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I had filed https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2083526 previously, and I couldn't reproduce the build/test failures on a s390x vm, just in a ppa.

description: updated
Revision history for this message
Andreas Hasenack (ahasenack) wrote (last edit ):

Ok, looking a bit more into this. Turns out there is a difference in the s390x hardware between the LP builders and canonistack s390x VMs:

-features : esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx
+features : esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx vxd vxe gs vxe2 vxp sort dflt

(+ is LP/PPAs)

These optimizations probably do not kick in in the canonistack VMs, where I was trying to reproduce the problem, and failing to do so.

To be clear, the rsyslog test fails on a machine with the extended set of flags (the "+" line above).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in rsyslog (Ubuntu):
status: New → Confirmed
Changed in zlib (Ubuntu):
status: New → Confirmed
Changed in rsyslog (Ubuntu Noble):
status: New → Confirmed
Changed in rsyslog (Ubuntu Oracular):
status: New → Confirmed
Changed in zlib (Ubuntu Noble):
status: New → Confirmed
Changed in zlib (Ubuntu Oracular):
status: New → Confirmed
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: New → Confirmed
assignee: nobody → bugproxy (bugproxy)
importance: Undecided → High
tags: added: s390x
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

This makes the test pass on s390x, and the build succeed:

--- a/debian/rules
+++ b/debian/rules
@@ -87,5 +87,5 @@ override_dh_installinit:

 override_dh_auto_test:
 ifeq (, $(filter nocheck, $(DEB_BUILD_OPTIONS)))
- PATH=$$PATH:/usr/sbin dh_auto_test || ( cat tests/test-suite.log; exit 1 ) && ( cat tests/test-suite.log )
+ PATH=$$PATH:/usr/sbin DFLTCC=0 dh_auto_test || ( cat tests/test-suite.log; exit 1 ) && ( cat tests/test-suite.log )
 endif

But rsyslog itself, of course, on these specific s390x CPUs, would still not work properly with zlib compression.

bugproxy (bugproxy)
tags: added: architecture-s39064 bugnameltc-210346 severity-high targetmilestone-inin---
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2024-10-30 09:57 EDT-------
Eddy asked me to have a look at it while he is on vacation.

The root cause seems to be that DFLTCC-enabled gunzip behaves differently on truncated archives:

# ls -l rstb_567931_cea0d3b3uMHc.out.log.gz
-rw-r--r--. 1 root root 5090 Oct 30 13:44 rstb_567931_cea0d3b3uMHc.out.log.gz
# head -c 5080 <rstb_567931_cea0d3b3uMHc.out.log.gz >partial.gz
# gunzip <partial.gz | wc -c
gzip: stdin: invalid compressed data--format violated
0
# DFLTCC=0 gunzip <partial.gz | wc -c
gzip: stdin: unexpected end of file
22500

This seems like a test-only issue to me, but we'll probably need to change how gzip handles this situation.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2024-11-08 06:10 EDT-------
indeed the problem is that the ibm unzip function dfltcc_inflate and gzip own function gzip_inflate differ in behavior.

gzip_inflate will flush its output buffers in many more cases, where dfltcc_inflate is much stricter about only flushing when everything went right.

i will prepare a patch that adds an outbuffer flush to dfltcc_inflate in case of a premature EOF.

Revision history for this message
Andreas Hasenack (ahasenack) wrote : Re: rsyslog FTBFS (s390x only) against zlib 1:1.3.dfsg+really1.3.1-1ubuntu1

Hi Eduard, thanks for working on this!

Do you have a patch already that I could test? I'm contemplating an rsyslog stable release update, but it fails to build on s390x due to this problem. I *could* disable that test in rsyslog I suppose, since there is nothing wrong in rsyslog per se, but am unsure if that the test is replicating could also happen to rsyslog in normal usage, so I'm a bit hesitant.

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2024-11-29 03:32 EDT-------
Hi,

so i have a patch for gzip that will fix the problem. Unfortunately my Copyright Assignment is still processed by the FSF. Until then i cannot send patches in. Ilja and I will figure out a way to make the patch available.

Revision history for this message
Andreas Hasenack (ahasenack) wrote : Re: rsyslog FTBFS (s390x only) against zlib 1:1.3.dfsg+really1.3.1-1ubuntu1

I'm marking the zlib tasks as incomplete, because this particular test failure in rsyslog happens with gzip, and it's not yet clear if zlib also has the same problem.

Changed in zlib (Ubuntu Plucky):
status: Confirmed → Incomplete
Changed in zlib (Ubuntu Oracular):
status: Confirmed → Incomplete
Changed in zlib (Ubuntu Noble):
status: Confirmed → Incomplete
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Applying this patch[1] to gzip, and rebuilding rsyslog with this new gzip.

1. https://lists.gnu.org/archive/html/bug-gzip/2024-12/msg00000.html

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I have 3 PPAs with builds now:
a) reference rsyslog[1]. FTBFS in s390x as expected.
b) rsyslog with patched gzip (patch from this thread[4])[2]. FTBFS in
s390x. Unexpected.
c) rsyslog with zlib with both s390x patches removed[3]. Build
succeeds in s390x. Unexpected.

Looks like whatever rsyslog is doing, it's zlib that is affecting it.

1. https://launchpad.net/~ahasenack/+archive/ubuntu/rsyslog-reference/+packages
2. https://launchpad.net/~ahasenack/+archive/ubuntu/rsyslog-apparmor/+packages
3. https://launchpad.net/~ahasenack/+archive/ubuntu/rsyslog-with-patched-zlib/+packages
4. https://lists.gnu.org/archive/html/bug-gzip/2024-12/msg00000.html

Changed in gzip (Ubuntu Plucky):
status: New → Confirmed
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Marking rsyslog invalid, since it's a bug in gzip. zlib might have the same problem, but we don't have a confirmation yet, so leaving that as incomplete. And gzip is confirmed, I rebuilt it with a patch in [1], and, with that build, rsyslog also built fine (test that was previously failing, now passes).

1. https://launchpad.net/~ahasenack/+archive/ubuntu/rsyslog-apparmor

Changed in gzip (Ubuntu Noble):
status: New → Confirmed
Changed in gzip (Ubuntu Oracular):
status: New → Confirmed
Changed in rsyslog (Ubuntu Noble):
status: Confirmed → Invalid
Changed in rsyslog (Ubuntu Oracular):
status: Confirmed → Invalid
Changed in rsyslog (Ubuntu Plucky):
status: Confirmed → Invalid
Changed in gzip (Ubuntu Noble):
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in gzip (Ubuntu Oracular):
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in gzip (Ubuntu Plucky):
assignee: nobody → Andreas Hasenack (ahasenack)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gzip - 1.12-1.1ubuntu2

---------------
gzip (1.12-1.1ubuntu2) plucky; urgency=medium

  * d/p/0001-maint-fix-s390-buffer-flushes.patch: align the behavior of
    dfltcc_inflate to do the same as gzip_inflate when it hits a premature EOF
    (LP: #2083700)

 -- Andreas Hasenack <email address hidden> Mon, 27 Jan 2025 14:04:06 -0300

Changed in gzip (Ubuntu Plucky):
status: Confirmed → Fix Released
summary: - rsyslog FTBFS (s390x only) against zlib 1:1.3.dfsg+really1.3.1-1ubuntu1
+ rsyslog FTBFS (s390x only) due to gzip different behavior with hw
+ acceleration on s390x
summary: - rsyslog FTBFS (s390x only) due to gzip different behavior with hw
- acceleration on s390x
+ rsyslog FTBFS due to gzip different behavior with hw acceleration on
+ s390x
description: updated
description: updated
description: updated
description: updated
description: updated
Revision history for this message
Andreas Hasenack (ahasenack) wrote (last edit ):

I just saw that gzip got a new upload earlier this month disabling hardware acceleration on s390x[1]:

gzip (1.13-1ubuntu2) plucky; urgency=medium

  * Turn off DFLTCC optimizations on s390x, they're causing decompression to
    crash with an illegal instruction

 -- Aaron Rainbolt <email address hidden> Tue, 11 Feb 2025 18:46:48 -0600

There is no bug reference or logs, I'm trying to find out what happened. In the meantime, I'll continue preparing this SRU.

1. https://launchpadlibrarian.net/776063771/gzip_1.13-1ubuntu1_1.13-1ubuntu2.diff.gz

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

There is no bug reference or logs, I'm trying to find out what happened.

Changed in gzip (Ubuntu Jammy):
status: New → Confirmed
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I did a no-change-rebuild of rsyslog on focal and jammy, and it also fails in the same gzip tests, so I added tasks for gzip on those ubuntu releases.

Revision history for this message
Timo Aaltonen (tjaalton) wrote : Please test proposed package

Hello Nick, or anyone else affected,

Accepted gzip into oracular-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gzip/1.12-1.1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-oracular to verification-done-oracular. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-oracular. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in gzip (Ubuntu Oracular):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-oracular
Changed in gzip (Ubuntu Noble):
status: Confirmed → Fix Committed
tags: added: verification-needed-noble
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Hello Nick, or anyone else affected,

Accepted gzip into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gzip/1.12-1ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (gzip/1.12-1ubuntu3.1)

All autopkgtests for the newly accepted gzip (1.12-1ubuntu3.1) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

httpdirfs-fuse/1.2.5-1build4 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#gzip

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.