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 Touch seeded packages, 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 -- 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
