[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- 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 Released Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Released 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
This bug was fixed in the package zlib - 1:1.2.11.dfsg-2ubuntu1.2 --- zlib (1:1.2.11.dfsg-2ubuntu1.2) focal; urgency=medium * Cherrypick update of s390x hw acceleration #410 pull request patch, which corrects inflateSyncPoint() return value to always gracefully fail when hw acceleration is in use. This fixes rsync failure with zlib compression on hw accelerated s390x. LP: #1899621 -- Dimitri John Ledkov Thu, 15 Oct 2020 11:10:29 +0100 ** Changed in: zlib (Ubuntu Focal) Status: Fix Committed => Fix Released -- 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 Released 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
Ok, as suspected - the test suite seems really REALLY flacky. All passing now. -- 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
If you follow the above link (comment #11): https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#zlib and click on the s390x status [here 'not a regression'], you should eventually find it - or just directly look here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/b/burp/20201020_215047_4c004@/log.gz -- 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
I see that the burp armhf autopkgtest keeps on failing on the new zlib. I wonder if the burp-unit-test suite is really flaky and the release- pocket run only passed by chance? -- 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
Many thx for testing on focal - I've updated the tags accordingly. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal ** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
Hello bugproxy, or anyone else affected, Accepted zlib into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/zlib/1:1.2.11.dfsg- 2ubuntu1.2 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- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. 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: zlib (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-focal -- 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: In Progress 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** No longer affects: ubuntu-release-notes -- 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: In Progress Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: In Progress 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: ubuntu-z-systems Status: New => In Progress -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: In Progress 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-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
This bug was fixed in the package zlib - 1:1.2.11.dfsg-2ubuntu4 --- zlib (1:1.2.11.dfsg-2ubuntu4) groovy; urgency=medium * Cherrypick update of s390x hw acceleration #410 pull request patch, which corrects inflateSyncPoint() return value to always gracefully fail when hw acceleration is in use. This fixes rsync failure with zlib compression on hw accelerated s390x. LP: #1899621 -- Dimitri John Ledkov Thu, 15 Oct 2020 11:01:38 +0100 ** Changed in: zlib (Ubuntu Groovy) Status: In Progress => Fix Released -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: In Progress 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-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
1.2.11.dfsg-2ubuntu4 is the latest package that incl. the patch -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Groovy: In Progress 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-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
Same for focal: https://launchpad.net/ubuntu/focal/+queue?queue_state=3_text=zlib1g zlib1g | 1:1.2.11.dfsg-2ubuntu1.1 | focal-updates | s390x (groovy: zlib1g | 1:1.2.11.dfsg-2ubuntu4 | groovy-proposed | s390x ) -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Groovy: In Progress 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-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
Fixed package landed in proposed: https://launchpad.net/ubuntu/groovy/+queue?queue_state=3_text=zlib1g -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Groovy: In Progress 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-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: zlib (Ubuntu Focal) Status: New => In Progress ** Changed in: zlib (Ubuntu Groovy) Status: New => In Progress -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Groovy: In Progress 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-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Description changed: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data -stream" on z15. + stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware -compression state and returns an incorrect result. + 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. + 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. + + * rsync with non-default zlib compression (-z flag) uses + inflateSyncPoint() API. + + * 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. ** Description changed: 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] - [Impact] - - * Certain rsync builds fail with "error in rsync protocol data stream" + * Certain rsync builds fail with "error in rsync protocol data stream" on z15. - * rsync with non-default zlib compression (-z flag) uses - inflateSyncPoint() API. + * 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 + * 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 + * 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. + * 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 + * 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. + + * 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. -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: zlib (Ubuntu Groovy) Milestone: ubuntu-20.10 => groovy-updates -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New 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. Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New 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. Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: zlib (Ubuntu Groovy) Importance: Undecided => Critical ** Changed in: zlib (Ubuntu Focal) Importance: Undecided => Critical ** Also affects: ubuntu-release-notes Importance: Undecided Status: New ** Changed in: zlib (Ubuntu Groovy) Milestone: None => ubuntu-20.10 ** Changed in: zlib (Ubuntu Focal) Milestone: None => focal-updates -- 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 Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New 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. Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Also affects: zlib (Ubuntu Groovy) Importance: Undecided Assignee: Skipper Bug Screeners (skipper-screen-team) Status: New ** Also affects: zlib (Ubuntu Focal) Importance: Undecided Status: New -- 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: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New 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. Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 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
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => High -- 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: New Status in zlib package in Ubuntu: New 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. Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 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
