[Bug 1899621] Autopkgtest regression report (zlib/1:1.2.11.dfsg-2ubuntu1.2)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted zlib (1:1.2.11.dfsg-2ubuntu1.2) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

linux-hwe-5.8/5.8.0-25.26~20.04.1 (armhf)
libreoffice/1:6.4.6-0ubuntu0.20.04.1 (arm64)
dub/1.19.0-1build2 (s390x, armhf, arm64, amd64)
burp/2.2.18-2 (armhf)


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/focal/update_excuses.html#zlib

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

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1899621

Title:
  [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on
  z15

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in zlib package in Ubuntu:
  Fix Released
Status in zlib source package in Focal:
  Fix Committed
Status in zlib source package in Groovy:
  Fix Released

Bug description:
  Description:   zlib: inflateSyncPoint() returns an incorrect result on z15
  Symptom:       Certain rsync builds fail with "error in rsync protocol data
                 stream" on z15.
  Problem:       inflateSyncPoint() does not take into account the hardware
                 compression state and returns an incorrect result.
  Solution:      Make inflateSyncPoint() fail if the hardware compression is on.
                 The hardware does not provide enough information in order to
                 implement this function.

  [Impact]

   * Certain rsync builds fail with "error in rsync protocol data
  stream" on z15.

   * On ubuntu, rsync normally uses zstd or lz4. But when rsync is
  forced to use non-default zlib compression (-z flag) it uses
  inflateSyncPoint() API. This can also happen when rsync on the the
  other end doesn't support zstd & lz4.

   * inflateSyncPoint() does not take into account the hardware
  compression state and returns an incorrect result.

   * Make inflateSyncPoint() fail if the hardware compression is on. The
  hardware does not provide enough information in order to implement
  this function.

   * Above makes rsync to succeed, when zlib uses hardware compression.

  [Test Case]

  Reproduction:  z15 only: printf 1 >1 && rsync -z 1 2

  [Regression Potential]

   * inflateSyncPoint API is rarely used. Scanning codesearch, there is
  a lot of false positives due to embedded copies of zlib in all the
  things. I do see that both rsync and backuppc-rsync use it. It used
  during a safety check to ensure that algorithm is not at a sync point
  (or that cannot be determined). Nonetheless, returning error is a
  safer implementation for this API call.

  [Other Info]

   * This is a regression introduced by adding & enabling zlib hw
  acceleration by default on z15; and discovering using rsync that one
  API is implemented incorrectly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1899621/+subscriptions