[Touch-packages] [Bug 2076269] Re: invalid base64 encoded gzip data on s390x causes autopkgtest failures
** Tags added: s390x ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => bugproxy (bugproxy) ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Tags added: reverse-proxy-bugzilla -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2076269 Title: invalid base64 encoded gzip data on s390x causes autopkgtest failures Status in Ubuntu on IBM z Systems: New Status in apport package in Ubuntu: New Status in python3.12 package in Ubuntu: New Bug description: The following tests all fail with an encoding/decoding issue: tests/unit/test_problem_report.py::T:test_modify tests/unit/test_report.py::T::test_report_from_systemd_coredump_storage_journal tests/integration/test_problem_report::T::test_write_file Example failure: 564s === FAILURES === 564s T.test_modify _ 564s 564s self = 564s 564s def test_modify(self): 564s """reading, modifying fields, and writing back.""" 564s report = textwrap.dedent( 564s """\ 564s ProblemType: Crash 564s Date: now! 564s Long: 564s xxx 564s . 564s yyy 564s Short: Bar 564s File: base64 564s H4sICAAC/0ZpbGUA 564s c3RyxIAMcBAFAK/2p9Mf 564s """ 564s ).encode() 564s 564s pr = problem_report.ProblemReport() 564s pr.load(io.BytesIO(report)) 564s 564s self.assertEqual(pr["Long"], "xxx\n.\nyyy") 564s 564s # write back unmodified 564s out = io.BytesIO() 564s pr.write(out) 564s > self.assertEqual(out.getvalue(), report) 564s E AssertionError: b'Pro[73 chars]e64\n H4sICAAC/0ZpbGUA\n cnTChAxwEA==\n BRgAr/an0x8=\n' != b'Pro[73 chars]e64\n H4sICAAC/0ZpbGUA\n c3RyxIAMcBAFAK/2p9Mf\n' 564s 564s tests/unit/test_problem_report.py:509: AssertionError Autopkgtest noble log: https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/s390x/a/apport/20240807_023039_8850a@/log.gz oracular log: https://autopkgtest.ubuntu.com/results/autopkgtest-oracular/oracular/s390x/a/apport/20240805_132135_d3a80@/log.gz This failure was seen on noble (log above) but also on oracular. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2076269/+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 2083480] Re: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x
** Tags added: ppc64el s390x -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to krb5 in Ubuntu. https://bugs.launchpad.net/bugs/2083480 Title: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x Status in acl package in Ubuntu: New Status in apache2 package in Ubuntu: New Status in attr package in Ubuntu: New Status in audit package in Ubuntu: New Status in bind9 package in Ubuntu: New Status in boost1.83 package in Ubuntu: New Status in ceph package in Ubuntu: New Status in chrony package in Ubuntu: New Status in e2fsprogs package in Ubuntu: New Status in eigen3 package in Ubuntu: New Status in elfutils package in Ubuntu: New Status in expat package in Ubuntu: New Status in gmp package in Ubuntu: New Status in haproxy package in Ubuntu: New Status in isc-kea package in Ubuntu: New Status in isl package in Ubuntu: New Status in kmod package in Ubuntu: New Status in krb5 package in Ubuntu: New Status in libaio package in Ubuntu: New Status in libbsd package in Ubuntu: New Status in libcap2 package in Ubuntu: New Status in libgpg-error package in Ubuntu: New Status in libidn2 package in Ubuntu: New Status in libmd package in Ubuntu: New Status in libnl3 package in Ubuntu: New Status in libselinux package in Ubuntu: New Status in libunistring package in Ubuntu: New Status in libunwind package in Ubuntu: New Status in libvirt package in Ubuntu: New Status in libzpc package in Ubuntu: New Status in mpclib3 package in Ubuntu: New Status in mpfr4 package in Ubuntu: New Status in nfs-utils package in Ubuntu: New Status in nghttp2 package in Ubuntu: New Status in openjdk-21 package in Ubuntu: New Status in openldap package in Ubuntu: New Status in openvswitch package in Ubuntu: New Status in pcre2 package in Ubuntu: New Status in perl package in Ubuntu: New Status in php8.3 package in Ubuntu: New Status in rabbitmq-server package in Ubuntu: New Status in ruby3.2 package in Ubuntu: New Status in sqlite3 package in Ubuntu: New Status in vsftpd package in Ubuntu: New Bug description: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x This is batch of packages that we want to rebuild to pick up the changed build flags on ppc64el (LP: #2064539) and s390x (LP: #2064538). Impact: These are no change uploads on architectures other than ppc64el and s390x. All of those packages already built successful in oracular with the changed build flags. We will validate picking up the changed build flags by inspecting the log files on ppc64el and s390x. The packages are now all built, and passing autopkg tests (the failing software-properties test is unrelated). Packages, that are not yet ready: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/acl/+bug/2083480/+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 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
The verification here is to rebuild existing zlib on noble, but explicitly using the updated 14.2.0-4ubuntu2~24.04. I verified that it builds fine (on s390x and other archs). (But since gcc 13 is the default in noble (13.2.0-7ubuntu1), this doesn't matter that much, it was mostly a problem in oracular, where the default is v14, hence zlib was build be default with v14.) Updating tag. ** Tags removed: verification-needed verification-needed-noble ** Tags added: verification-done verification-done-noble -- 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/2075567 Title: zlib fails to build on s390x on oracular with gcc 14 Status in Ubuntu on IBM z Systems: Fix Released Status in gcc-14 package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Invalid Status in gcc-14 source package in Noble: Fix Committed Bug description: Rebuilding zlib for s390x on oracular fails to build, probably due to gcc 14 usage (since it became more strict). Full build log can be found here: https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz erroneous lines are: D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 -mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’: contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4); |^~ || |__vector(1
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Tags added: petest-446 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: Fix Released Status in s390-tools package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in s390-tools source package in Oracular: Fix Released Status in systemd source package in Oracular: Fix Released Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corresponding udev rule not being copied to the initrd [1]. Unfor
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Changed in: ubuntu-z-systems Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: Fix Released Status in s390-tools package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in s390-tools source package in Oracular: Fix Released Status in systemd source package in Oracular: Fix Released Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corresponding udev rule not
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
** Changed in: ubuntu-z-systems Status: Triaged => 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/2075567 Title: zlib fails to build on s390x on oracular with gcc 14 Status in Ubuntu on IBM z Systems: Fix Released Status in gcc-14 package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Invalid Bug description: Rebuilding zlib for s390x on oracular fails to build, probably due to gcc 14 usage (since it became more strict). Full build log can be found here: https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz erroneous lines are: D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 -mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’: contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
The fix solves the problem - I tried with a patched gcc-14: https://launchpad.net/~fheimes/+archive/ubuntu/lp2073786/+sourcepub/16401085/+listing-archive-extra -- 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/2075567 Title: zlib fails to build on s390x on oracular with gcc 14 Status in Ubuntu on IBM z Systems: Triaged Status in gcc-14 package in Ubuntu: New Status in zlib package in Ubuntu: Triaged Bug description: Rebuilding zlib for s390x on oracular fails to build, probably due to gcc 14 usage (since it became more strict). Full build log can be found here: https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz erroneous lines are: D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 -mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’: contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ |
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
Thanks iii, just saw this a few minutes ago. Does it makes sense to also add: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a247088adaf122116919235f4a40189506139495 (seems to be a bit related ...) -- 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/2075567 Title: zlib fails to build on s390x on oracular with gcc 14 Status in Ubuntu on IBM z Systems: Triaged Status in gcc-14 package in Ubuntu: New Status in zlib package in Ubuntu: Triaged Bug description: Rebuilding zlib for s390x on oracular fails to build, probably due to gcc 14 usage (since it became more strict). Full build log can be found here: https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz erroneous lines are: D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 -mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’: contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~~~
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
Patch got upstream accepted: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e8a7142a697c5d2673adea33ba23af82a89c9559 It looks to me that it should be picked together with: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a247088adaf122116919235f4a40189506139495 -- 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/2075567 Title: zlib fails to build on s390x on oracular with gcc 14 Status in Ubuntu on IBM z Systems: Triaged Status in gcc-14 package in Ubuntu: New Status in zlib package in Ubuntu: Triaged Bug description: Rebuilding zlib for s390x on oracular fails to build, probably due to gcc 14 usage (since it became more strict). Full build log can be found here: https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz erroneous lines are: D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 -mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’: contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
[Touch-packages] [Bug 2076340] Re: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x
A new upload of the s390-tools package always also requires an upload of the s390-tools-signed package with the same version as well. I've attached the debdiff for it here... ** Also affects: s390-tools-signed (Ubuntu) Importance: Undecided Status: New ** Patch added: "debdiff_s390-tools-signed_noble_from_2.31.0-0ubuntu5_to_2.31.0-0ubuntu5.1.diff" https://bugs.launchpad.net/ubuntu/+source/s390-tools-signed/+bug/2076340/+attachment/5805363/+files/debdiff_s390-tools-signed_noble_from_2.31.0-0ubuntu5_to_2.31.0-0ubuntu5.1.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2076340 Title: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x Status in atlas package in Ubuntu: New Status in bzip2 package in Ubuntu: New Status in containerd-app package in Ubuntu: New Status in curl package in Ubuntu: New Status in cyrus-sasl2 package in Ubuntu: New Status in dbus package in Ubuntu: New Status in docker.io-app package in Ubuntu: New Status in dotnet8 package in Ubuntu: New Status in gnutls28 package in Ubuntu: New Status in golang-1.22 package in Ubuntu: New Status in icu package in Ubuntu: New Status in lapack package in Ubuntu: New Status in libdeflate package in Ubuntu: New Status in libseccomp package in Ubuntu: New Status in libzdnn package in Ubuntu: Fix Released Status in libzstd package in Ubuntu: New Status in lz4 package in Ubuntu: New Status in mysql-8.0 package in Ubuntu: New Status in nettle package in Ubuntu: New Status in openssh package in Ubuntu: New Status in openssl package in Ubuntu: New Status in p11-kit package in Ubuntu: New Status in postgresql-16 package in Ubuntu: New Status in postgresql-common package in Ubuntu: New Status in powerpc-utils package in Ubuntu: Fix Released Status in python-greenlet package in Ubuntu: Fix Released Status in qemu package in Ubuntu: New Status in runc-app package in Ubuntu: Fix Released Status in rustc package in Ubuntu: New Status in s390-tools package in Ubuntu: New Status in s390-tools-signed package in Ubuntu: New Status in systemd package in Ubuntu: New Status in util-linux package in Ubuntu: New Status in xz-utils package in Ubuntu: New Status in zlib package in Ubuntu: New Status in atlas source package in Noble: Fix Committed Status in bzip2 source package in Noble: Fix Committed Status in containerd-app source package in Noble: Fix Committed Status in curl source package in Noble: Fix Committed Status in cyrus-sasl2 source package in Noble: Fix Committed Status in dbus source package in Noble: Fix Committed Status in docker.io-app source package in Noble: Fix Committed Status in dotnet8 source package in Noble: Fix Committed Status in gnutls28 source package in Noble: Fix Committed Status in golang-1.22 source package in Noble: Fix Committed Status in icu source package in Noble: Fix Committed Status in lapack source package in Noble: Fix Committed Status in libdeflate source package in Noble: Fix Committed Status in libseccomp source package in Noble: Fix Committed Status in libzdnn source package in Noble: Fix Committed Status in libzstd source package in Noble: Fix Committed Status in lz4 source package in Noble: Fix Committed Status in mysql-8.0 source package in Noble: Fix Committed Status in nettle source package in Noble: Fix Committed Status in openssh source package in Noble: Fix Committed Status in openssl source package in Noble: Fix Committed Status in p11-kit source package in Noble: Fix Committed Status in postgresql-16 source package in Noble: Fix Committed Status in postgresql-common source package in Noble: Fix Committed Status in powerpc-utils source package in Noble: Fix Committed Status in python-greenlet source package in Noble: Fix Committed Status in qemu source package in Noble: Fix Committed Status in runc-app source package in Noble: Fix Committed Status in rustc source package in Noble: Fix Committed Status in s390-tools source package in Noble: Fix Committed Status in s390-tools-signed source package in Noble: New Status in systemd source package in Noble: Fix Committed Status in util-linux source package in Noble: Fix Committed Status in xz-utils source package in Noble: Fix Committed Status in zlib source package in Noble: Fix Committed Bug description: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x This is batch of packages that we want to rebuild to pick up the changed build flags on ppc64el (LP: #2064539) and s390x (LP: #2064538). Impact: These are no change uploads on architectures other than ppc64el and s390x. All of those packages already built successful in oracular with the changed build flags. We will validate picking up the changed build flags by inspecting
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
Hi Simon, not yet, but I'm pushing for this ... ** Changed in: ubuntu-z-systems Importance: High => Critical ** Changed in: ubuntu-z-systems Status: New => Triaged -- 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/2075567 Title: zlib fails to build on s390x on oracular with gcc 14 Status in Ubuntu on IBM z Systems: Triaged Status in zlib package in Ubuntu: Triaged Bug description: Rebuilding zlib for s390x on oracular fails to build, probably due to gcc 14 usage (since it became more strict). Full build log can be found here: https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz erroneous lines are: D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 -mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’: contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ |
[Touch-packages] [Bug 2075567] [NEW] zlib fails to build on s390x on oracular with gcc 14
Public bug reported: Rebuilding zlib for s390x on oracular fails to build, probably due to gcc 14 usage (since it became more strict). Full build log can be found here: https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz erroneous lines are: D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13 -mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’: contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4); |^ || |uv16qi {aka __vector(16) unsigned char} contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’} contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2); |^~ || |__vector(16) unsigned char contrib/s390/crc32-vx.c:114:52: note: expected ‘__int128 unsigned’ but argument is of type ‘__vector(16) unsigned char’ contrib/s390/crc32-vx.c:161:46: error: incompatible type for argument 3 of ‘__builtin_s390_vgfmag’ 161 | v1 = (uv2di)vec_gfmsum_accum_128(r5, v1, (uv16qi)v2); | ^~ | | | __vector(16) unsigned char contrib/s390/crc32-vx.c:161:46: no
[Touch-packages] [Bug 2075204] Re: gdb on s390x chokes on divide-by-zero from chaos-marmosets
** Tags added: reverse-proxy-bugzilla s390x ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => bugproxy (bugproxy) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/2075204 Title: gdb on s390x chokes on divide-by-zero from chaos-marmosets Status in Ubuntu on IBM z Systems: New Status in gdb package in Ubuntu: New Bug description: To help in the development of apport we're using the chaos-marmosets set of binaries, which triggers various crashes. In particular, we're using /usr/bin/divide-by-zero which does as its name indicates, which naturally triggers a native crash. However, GDB fails on s390x. Note that for the following I have the debugging symbols from ddebs.ubuntu.com installed: ubuntu@glibc-proposed:/tmp$ gdb /usr/bin/divide-by-zero [snip] Reading symbols from /usr/bin/divide-by-zero... Reading symbols from /usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug... (gdb) run Starting program: /usr/bin/divide-by-zero [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Program received signal SIGTRAP, Trace/breakpoint trap. 0x02aa0814 in ?? () (gdb) bt #0 0x02aa0814 in ?? () #1 0x03fff7d2baac in __libc_start_call_main (main=0x2aa0690 , main@entry=, argc=argc@entry=1, argv=argv@entry=0x3ffa468) at ../sysdeps/nptl/libc_start_call_main.h:58 #2 0x03fff7d2bbae in __libc_start_main_impl (main=, argc=1, argv=0x3ffa468, init=, fini=, rtld_fini=0x3fff7f85650 <_dl_fini>, stack_end=0x3ffa3b0) at ../csu/libc-start.c:360 #3 0x02aa0720 in _start () (gdb) info address divide_by_zero Symbol "divide_by_zero" is a function at address 0x2aa0810. (gdb) So at this point GDB isn't capable of identifying the various symbols on the stack, which isn't ideal. Now, if I try to step in: ubuntu@glibc-proposed:/tmp$ gdb -q /usr/bin/divide-by-zero Reading symbols from /usr/bin/divide-by-zero... Reading symbols from /usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug... (gdb) start Temporary breakpoint 1 at 0x690: file divide-by-zero.c, line 29. Starting program: /usr/bin/divide-by-zero [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Temporary breakpoint 1, main (argc=1, argv=0x3ffa468) at divide-by-zero.c:29 warning: 29 divide-by-zero.c: No such file or directory (gdb) s 34 in divide-by-zero.c (gdb) divide_by_zero () at divide-by-zero.c:25 25 in divide-by-zero.c (gdb) /build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. - Backtrace - 0x2aa100a247f ??? 0x2aa104efce5 ??? 0x2aa104eff7f ??? 0x2aa10668c13 ??? 0x2aa102553db ??? 0x2aa10255bd1 ??? 0x2aa10255f5f ??? 0x2aa10259195 ??? 0x2aa1025c315 ??? 0x2aa1025e9a5 ??? 0x2aa10260015 ??? 0x2aa1066951b ??? 0x2aa10669e6d ??? 0x2aa102b01cd ??? 0x2aa102b3607 ??? 0x2aa0ffed839 ??? 0x3ffb142baab __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x3ffb142bbad __libc_start_main_impl ../csu/libc-start.c:360 0x2aa0fff8f8f ??? 0x ??? - /build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) I can provide a core dump if you think that'd help, but it seems trivially reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2075204/+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 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image
** Changed in: ubuntu-z-systems Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2060311 Title: Setting "optional: true" to overcome he timeout "Job systemd-networkd- wait-online" does no longer work with latest noble image Status in Netplan: In Progress Status in Ubuntu on IBM z Systems: Fix Released Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Status in netplan.io source package in Noble: Fix Released Status in systemd source package in Noble: Invalid Bug description: Especially on s390x (but not limited to s390x) it's often the case that a system has network devices that are not necessarily connected during boot-up and one gets such a 2 min timeout: "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)" In the past I could avoid that by setting "optional: true" post-install (no perfect, but worked), but this does no longer seem to work using the latest noble ISO image (Apr 5th). Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like this for me: # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: ethernets: enP1p0s0: optional: true dhcp4: true enP1p0s0d1: optional: true dhcp4: true enP2p0s0: optional: true dhcp4: true enP2p0s0d1: optional: true dhcp4: true encc000: {} version: 2 vlans: encc000.2653: addresses: - 10.11.12.15/24 gateway4: 10.11.12.1 id: 2653 link: encc000 nameservers: addresses: - 10.11.12.1 ... can be set fine (also --dry-run does not moan, except about dhcp4). This worked in the past on noble, but also on older Ubuntu releases like jammy. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2060311/+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 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image
I gave ~ppa5 a try on my s390x system. If I set all interfaces to "optional: true" (incl. encc000), but except encc000.2653, I don't face the timeout anymore. But if I UNset "optional: true" for encc000 on top, I tap into the timeout again. In the past it was okay to NOT have "optional: true" set for both: encc000 and encc000.2653 (and I found that logical, since both interfaces are needed in a VLAN context). Knowing now what's missing, I could live with that (even if it's a change in behavior). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2060311 Title: Setting "optional: true" to overcome he timeout "Job systemd-networkd- wait-online" does no longer work with latest noble image Status in Netplan: In Progress Status in Ubuntu on IBM z Systems: New Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in netplan.io source package in Noble: Confirmed Status in systemd source package in Noble: Confirmed Bug description: Especially on s390x (but not limited to s390x) it's often the case that a system has network devices that are not necessarily connected during boot-up and one gets such a 2 min timeout: "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)" In the past I could avoid that by setting "optional: true" post-install (no perfect, but worked), but this does no longer seem to work using the latest noble ISO image (Apr 5th). Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like this for me: # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: ethernets: enP1p0s0: optional: true dhcp4: true enP1p0s0d1: optional: true dhcp4: true enP2p0s0: optional: true dhcp4: true enP2p0s0d1: optional: true dhcp4: true encc000: {} version: 2 vlans: encc000.2653: addresses: - 10.11.12.15/24 gateway4: 10.11.12.1 id: 2653 link: encc000 nameservers: addresses: - 10.11.12.1 ... can be set fine (also --dry-run does not moan, except about dhcp4). This worked in the past on noble, but also on older Ubuntu releases like jammy. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2060311/+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 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image
I see (deep in my mind I remember that such a discussion happened or at least started somewhere). Just notice that one interface is still _not_ optional, here in my case: encc000 And the behavior changed recently, with the above config I didn not hit the timeout in the past (even with earlier noble daily images). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2060311 Title: Setting "optional: true" to overcome he timeout "Job systemd-networkd- wait-online" does no longer work with latest noble image Status in Netplan: New Status in Ubuntu on IBM z Systems: New Status in systemd package in Ubuntu: New Bug description: Especially on s390x (but not limited to s390x) it's often the case that a system has network devices that are not necessarily connected during boot-up and one gets such a 2 min timeout: "Job systemd-networkd-wait-online. Start running (1min 59s / no limit)" In the past I could avoid that by setting "optional: true" post-install (no perfect, but worked), but this does no longer seem to work using the latest noble ISO image (Apr 5th). Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like this for me: # This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: ethernets: enP1p0s0: optional: true dhcp4: true enP1p0s0d1: optional: true dhcp4: true enP2p0s0: optional: true dhcp4: true enP2p0s0d1: optional: true dhcp4: true encc000: {} version: 2 vlans: encc000.2653: addresses: - 10.11.12.15/24 gateway4: 10.11.12.1 id: 2653 link: encc000 nameservers: addresses: - 10.11.12.1 ... can be set fine (also --dry-run does not moan, except about dhcp4). This worked in the past on noble, but also on older Ubuntu releases like jammy. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2060311/+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 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
Included in pam | 1.5.3-5ubuntu3. ** Changed in: pam (Ubuntu) Status: Fix Committed => Fix Released ** 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 pam in Ubuntu. https://bugs.launchpad.net/bugs/2045250 Title: pam_lastlog doesn't handle localtime_r related errors properly Status in Ubuntu on IBM z Systems: Fix Released Status in pam package in Ubuntu: Fix Released Status in pam package in Fedora: Fix Released Bug description: The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to noble) are affected by https://bugzilla.redhat.com/show_bug.cgi?id=2012871 Customers report a command going through PAM crashing for a given user. A potential follow on issue can be that no ssh remote connections to an affected server are possible anymore, esp. painful with headless systems (was reported on a different distro). This is caused by an issue in modules/pam_lastlog/pam_lastlog.c: with tm = localtime_r(...) that can be NULL and needs to be handled. There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble): 314- ll_time = last_login.ll_time; 315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) { 316- strftime (the_time, sizeof (the_time), 317- /* TRANSLATORS: "strftime options for date of last login" */ -- 574- 575- lf_time = utuser.ut_tv.tv_sec; 576: tm = localtime_r (&lf_time, &tm_buf); 577- strftime (the_time, sizeof (the_time), 578- /* TRANSLATORS: "strftime options for date of last login" */ Case 1 (line 315) is properly handled, but not case 2 (line 576). The second case got fixed by: https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c This fix should be included in Ubuntu (and Debian). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+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 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
Fix Committed with having: pam | 1.5.3-4ubuntu1 | noble-proposed | source ** Changed in: pam (Ubuntu) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/2045250 Title: pam_lastlog doesn't handle localtime_r related errors properly Status in Ubuntu on IBM z Systems: Fix Committed Status in pam package in Ubuntu: Fix Committed Status in pam package in Fedora: Fix Released Bug description: The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to noble) are affected by https://bugzilla.redhat.com/show_bug.cgi?id=2012871 Customers report a command going through PAM crashing for a given user. A potential follow on issue can be that no ssh remote connections to an affected server are possible anymore, esp. painful with headless systems (was reported on a different distro). This is caused by an issue in modules/pam_lastlog/pam_lastlog.c: with tm = localtime_r(...) that can be NULL and needs to be handled. There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble): 314- ll_time = last_login.ll_time; 315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) { 316- strftime (the_time, sizeof (the_time), 317- /* TRANSLATORS: "strftime options for date of last login" */ -- 574- 575- lf_time = utuser.ut_tv.tv_sec; 576: tm = localtime_r (&lf_time, &tm_buf); 577- strftime (the_time, sizeof (the_time), 578- /* TRANSLATORS: "strftime options for date of last login" */ Case 1 (line 315) is properly handled, but not case 2 (line 576). The second case got fixed by: https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c This fix should be included in Ubuntu (and Debian). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+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 1833322] Re: Please consider no more having irqbalance enabled by default (per image/use-case/TBD)
** Changed in: ubuntu-z-systems Status: Opinion => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1833322 Title: Please consider no more having irqbalance enabled by default (per image/use-case/TBD) Status in cloud-images: New Status in Release Notes for Ubuntu: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in irqbalance package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: Fix Released Bug description: as per https://github.com/pop-os/default-settings/issues/60 Distribution (run cat /etc/os-release): $ cat /etc/os-release NAME="Pop!_OS" VERSION="19.04" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Pop!_OS 19.04" VERSION_ID="19.04" HOME_URL="https://system76.com/pop"; SUPPORT_URL="http://support.system76.com"; BUG_REPORT_URL="https://github.com/pop-os/pop/issues"; PRIVACY_POLICY_URL="https://system76.com/privacy"; VERSION_CODENAME=disco UBUNTU_CODENAME=disco Related Application and/or Package Version (run apt policy $PACKAGE NAME): $ apt policy irqbalance irqbalance: Installed: 1.5.0-3ubuntu1 Candidate: 1.5.0-3ubuntu1 Version table: *** 1.5.0-3ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status $ apt rdepends irqbalance irqbalance Reverse Depends: Recommends: ubuntu-standard gce-compute-image-packages Issue/Bug Description: as per konkor/cpufreq#48 and http://konkor.github.io/cpufreq/faq/#irqbalance-detected irqbalance is technically not needed on desktop systems (supposedly it is mainly for servers), and may actually reduce performance and power savings. It appears to provide benefits only to server environments that have relatively-constant loading. If it is truly a server- oriented package, then it shouldn't be installed by default on a desktop/laptop system and shouldn't be included in desktop OS images. Steps to reproduce (if you know): This is potentially an issue with all default installs. Expected behavior: n/a Other Notes: I can safely remove it via "sudo apt purge irqbalance" without any apparent adverse side-effects. If someone is running a situation where they need it, then they always have the option of installing it from the repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1833322/+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 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
** 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 gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: Fix Released Status in gdb package in Ubuntu: Fix Released Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+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 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
** 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 gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: Fix Committed Status in gdb package in Ubuntu: Fix Committed Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+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 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
Thx doko, for having this incl. in gdb trunk/15 / 15.0.50.20240219-0ubuntu1: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/15802578/+listing-archive-extra -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: In Progress Status in gdb package in Ubuntu: In Progress Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+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 1833322] Re: Please consider no more having irqbalance enabled by default (per image/use-case/TBD)
[Please ignore comment#35 - this was caused by a BZ-to-LP-bridge issue ...] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1833322 Title: Please consider no more having irqbalance enabled by default (per image/use-case/TBD) Status in Ubuntu on IBM z Systems: Confirmed Status in irqbalance package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: as per https://github.com/pop-os/default-settings/issues/60 Distribution (run cat /etc/os-release): $ cat /etc/os-release NAME="Pop!_OS" VERSION="19.04" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Pop!_OS 19.04" VERSION_ID="19.04" HOME_URL="https://system76.com/pop"; SUPPORT_URL="http://support.system76.com"; BUG_REPORT_URL="https://github.com/pop-os/pop/issues"; PRIVACY_POLICY_URL="https://system76.com/privacy"; VERSION_CODENAME=disco UBUNTU_CODENAME=disco Related Application and/or Package Version (run apt policy $PACKAGE NAME): $ apt policy irqbalance irqbalance: Installed: 1.5.0-3ubuntu1 Candidate: 1.5.0-3ubuntu1 Version table: *** 1.5.0-3ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status $ apt rdepends irqbalance irqbalance Reverse Depends: Recommends: ubuntu-standard gce-compute-image-packages Issue/Bug Description: as per konkor/cpufreq#48 and http://konkor.github.io/cpufreq/faq/#irqbalance-detected irqbalance is technically not needed on desktop systems (supposedly it is mainly for servers), and may actually reduce performance and power savings. It appears to provide benefits only to server environments that have relatively-constant loading. If it is truly a server- oriented package, then it shouldn't be installed by default on a desktop/laptop system and shouldn't be included in desktop OS images. Steps to reproduce (if you know): This is potentially an issue with all default installs. Expected behavior: n/a Other Notes: I can safely remove it via "sudo apt purge irqbalance" without any apparent adverse side-effects. If someone is running a situation where they need it, then they always have the option of installing it from the repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+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 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
** Tags added: pe-sponsoring-request -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: In Progress Status in gdb package in Ubuntu: In Progress Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+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 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
Test builds are done here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1982336 ** Information type changed from Private to Public ** Changed in: ubuntu-z-systems Status: New => In Progress ** Changed in: gdb (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: In Progress Status in gdb package in Ubuntu: In Progress Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+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 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
debdiff ** Patch added: "debdiff_gdb_noble_from_14.1-0ubuntu2_to_14.1-0ubuntu3.diff" https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1982336/+attachment/5746408/+files/debdiff_gdb_noble_from_14.1-0ubuntu2_to_14.1-0ubuntu3.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: In Progress Status in gdb package in Ubuntu: In Progress Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+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 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Since this bug is fixed with openssl 3.0.8 and newer, I'm changing the status of the current devel. release to Fix Released too (since we are there on 3.0.10). And with that the affected project status can be set to Fix Released, too. Thx! ** Changed in: openssl (Ubuntu) Status: In Progress => Fix Released ** Changed in: ubuntu-z-systems Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: Fix Released Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: Fix Released Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', rather than create a proper certificate file. Also watch /var/log/syslog / journalctl for more details. - Upgrade not only the openssl package itself, but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 47
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Hi Grgo, did you also updated libssl3? see test plan in Description: " - Upgrade not only the openssl package itself, but also libssl3, before verification. " With that I could successfully verify. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', rather than create a proper certificate file. Also watch /var/log/syslog / journalctl for more details. - Upgrade not only the openssl package itself, but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
verification on jammy was successful ** Description changed: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: - sudo apt-get install libica-utils libica? openssl-ibmca + sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: - sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: - (dynamic) Dynamic engine loading support - (ibmca) Ibmca hardware engine support <=== + sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf + - Verify if the 'openssl engine' lists an ibmca engine, + in addition to the dynamic engine: + openssl engine + (dynamic) Dynamic engine loading support + (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: - openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' + openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', - rather than create a proper certificate file. - Also watch /var/log/syslog / journalctl for more details. + rather than create a proper certificate file. + Also watch /var/log/syslog / journalctl for more details. + - Upgrade not only the openssl package itself, + but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2)
[Touch-packages] [Bug 1833322] Re: Consider removing irqbalance from default install on desktop images
** Changed in: ubuntu-z-systems Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1833322 Title: Consider removing irqbalance from default install on desktop images Status in Ubuntu on IBM z Systems: Confirmed Status in irqbalance package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: as per https://github.com/pop-os/default-settings/issues/60 Distribution (run cat /etc/os-release): $ cat /etc/os-release NAME="Pop!_OS" VERSION="19.04" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Pop!_OS 19.04" VERSION_ID="19.04" HOME_URL="https://system76.com/pop"; SUPPORT_URL="http://support.system76.com"; BUG_REPORT_URL="https://github.com/pop-os/pop/issues"; PRIVACY_POLICY_URL="https://system76.com/privacy"; VERSION_CODENAME=disco UBUNTU_CODENAME=disco Related Application and/or Package Version (run apt policy $PACKAGE NAME): $ apt policy irqbalance irqbalance: Installed: 1.5.0-3ubuntu1 Candidate: 1.5.0-3ubuntu1 Version table: *** 1.5.0-3ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status $ apt rdepends irqbalance irqbalance Reverse Depends: Recommends: ubuntu-standard gce-compute-image-packages Issue/Bug Description: as per konkor/cpufreq#48 and http://konkor.github.io/cpufreq/faq/#irqbalance-detected irqbalance is technically not needed on desktop systems (supposedly it is mainly for servers), and may actually reduce performance and power savings. It appears to provide benefits only to server environments that have relatively-constant loading. If it is truly a server- oriented package, then it shouldn't be installed by default on a desktop/laptop system and shouldn't be included in desktop OS images. Steps to reproduce (if you know): This is potentially an issue with all default installs. Expected behavior: n/a Other Notes: I can safely remove it via "sudo apt purge irqbalance" without any apparent adverse side-effects. If someone is running a situation where they need it, then they always have the option of installing it from the repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+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 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
** 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 pam in Ubuntu. https://bugs.launchpad.net/bugs/2045250 Title: pam_lastlog doesn't handle localtime_r related errors properly Status in Ubuntu on IBM z Systems: New Status in pam package in Ubuntu: New Status in pam package in Fedora: Fix Released Bug description: The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to noble) are affected by https://bugzilla.redhat.com/show_bug.cgi?id=2012871 Customers report a command going through PAM crashing for a given user. A potential follow on issue can be that no ssh remote connections to an affected server are possible anymore, esp. painful with headless systems (was reported on a different distro). This is caused by an issue in modules/pam_lastlog/pam_lastlog.c: with tm = localtime_r(...) that can be NULL and needs to be handled. There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble): 314- ll_time = last_login.ll_time; 315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) { 316- strftime (the_time, sizeof (the_time), 317- /* TRANSLATORS: "strftime options for date of last login" */ -- 574- 575- lf_time = utuser.ut_tv.tv_sec; 576: tm = localtime_r (&lf_time, &tm_buf); 577- strftime (the_time, sizeof (the_time), 578- /* TRANSLATORS: "strftime options for date of last login" */ Case 1 (line 315) is properly handled, but not case 2 (line 576). The second case got fixed by: https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c This fix should be included in Ubuntu (and Debian). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+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 1833322] Re: Consider removing irqbalance from default install on desktop images
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => bugproxy (bugproxy) ** Tags added: reverse-proxy-bugzilla -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1833322 Title: Consider removing irqbalance from default install on desktop images Status in Ubuntu on IBM z Systems: New Status in irqbalance package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: as per https://github.com/pop-os/default-settings/issues/60 Distribution (run cat /etc/os-release): $ cat /etc/os-release NAME="Pop!_OS" VERSION="19.04" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Pop!_OS 19.04" VERSION_ID="19.04" HOME_URL="https://system76.com/pop"; SUPPORT_URL="http://support.system76.com"; BUG_REPORT_URL="https://github.com/pop-os/pop/issues"; PRIVACY_POLICY_URL="https://system76.com/privacy"; VERSION_CODENAME=disco UBUNTU_CODENAME=disco Related Application and/or Package Version (run apt policy $PACKAGE NAME): $ apt policy irqbalance irqbalance: Installed: 1.5.0-3ubuntu1 Candidate: 1.5.0-3ubuntu1 Version table: *** 1.5.0-3ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status $ apt rdepends irqbalance irqbalance Reverse Depends: Recommends: ubuntu-standard gce-compute-image-packages Issue/Bug Description: as per konkor/cpufreq#48 and http://konkor.github.io/cpufreq/faq/#irqbalance-detected irqbalance is technically not needed on desktop systems (supposedly it is mainly for servers), and may actually reduce performance and power savings. It appears to provide benefits only to server environments that have relatively-constant loading. If it is truly a server- oriented package, then it shouldn't be installed by default on a desktop/laptop system and shouldn't be included in desktop OS images. Steps to reproduce (if you know): This is potentially an issue with all default installs. Expected behavior: n/a Other Notes: I can safely remove it via "sudo apt purge irqbalance" without any apparent adverse side-effects. If someone is running a situation where they need it, then they always have the option of installing it from the repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+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 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
** Also affects: ubuntu-z-systems Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/2045250 Title: pam_lastlog doesn't handle localtime_r related errors properly Status in Ubuntu on IBM z Systems: New Status in pam package in Ubuntu: New Status in pam package in Fedora: Fix Released Bug description: The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to noble) are affected by https://bugzilla.redhat.com/show_bug.cgi?id=2012871 Customers report a command going through PAM crashing for a given user. A potential follow on issue can be that no ssh remote connections to an affected server are possible anymore, esp. painful with headless systems (was reported on a different distro). This is caused by an issue in modules/pam_lastlog/pam_lastlog.c: with tm = localtime_r(...) that can be NULL and needs to be handled. There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble): 314- ll_time = last_login.ll_time; 315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) { 316- strftime (the_time, sizeof (the_time), 317- /* TRANSLATORS: "strftime options for date of last login" */ -- 574- 575- lf_time = utuser.ut_tv.tv_sec; 576: tm = localtime_r (&lf_time, &tm_buf); 577- strftime (the_time, sizeof (the_time), 578- /* TRANSLATORS: "strftime options for date of last login" */ Case 1 (line 315) is properly handled, but not case 2 (line 576). The second case got fixed by: https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c This fix should be included in Ubuntu (and Debian). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+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 2045250] [NEW] pam_lastlog doesn't handle localtime_r related errors properly
Public bug reported: The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to noble) are affected by https://bugzilla.redhat.com/show_bug.cgi?id=2012871 Customers report a command going through PAM crashing for a given user. A potential follow on issue can be that no ssh remote connections to an affected server are possible anymore, esp. painful with headless systems (was reported on a different distro). This is caused by an issue in modules/pam_lastlog/pam_lastlog.c: with tm = localtime_r(...) that can be NULL and needs to be handled. There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble): 314-ll_time = last_login.ll_time; 315:if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) { 316-strftime (the_time, sizeof (the_time), 317-/* TRANSLATORS: "strftime options for date of last login" */ -- 574- 575-lf_time = utuser.ut_tv.tv_sec; 576:tm = localtime_r (&lf_time, &tm_buf); 577-strftime (the_time, sizeof (the_time), 578-/* TRANSLATORS: "strftime options for date of last login" */ Case 1 (line 315) is properly handled, but not case 2 (line 576). The second case got fixed by: https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c This fix should be included in Ubuntu (and Debian). ** Affects: pam (Ubuntu) Importance: Undecided Status: New ** Affects: pam (Fedora) Importance: Unknown Status: Unknown ** Tags: rls-ff-incoming rls-jj-incoming rls-ll-incoming rls-mm-incoming rls-nn-incoming ** Bug watch added: Red Hat Bugzilla #2012871 https://bugzilla.redhat.com/show_bug.cgi?id=2012871 ** Also affects: pam (Fedora) via https://bugzilla.redhat.com/show_bug.cgi?id=2012871 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/2045250 Title: pam_lastlog doesn't handle localtime_r related errors properly Status in pam package in Ubuntu: New Status in pam package in Fedora: Unknown Bug description: The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to noble) are affected by https://bugzilla.redhat.com/show_bug.cgi?id=2012871 Customers report a command going through PAM crashing for a given user. A potential follow on issue can be that no ssh remote connections to an affected server are possible anymore, esp. painful with headless systems (was reported on a different distro). This is caused by an issue in modules/pam_lastlog/pam_lastlog.c: with tm = localtime_r(...) that can be NULL and needs to be handled. There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble): 314- ll_time = last_login.ll_time; 315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) { 316- strftime (the_time, sizeof (the_time), 317- /* TRANSLATORS: "strftime options for date of last login" */ -- 574- 575- lf_time = utuser.ut_tv.tv_sec; 576: tm = localtime_r (&lf_time, &tm_buf); 577- strftime (the_time, sizeof (the_time), 578- /* TRANSLATORS: "strftime options for date of last login" */ Case 1 (line 315) is properly handled, but not case 2 (line 576). The second case got fixed by: https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c This fix should be included in Ubuntu (and Debian). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/2045250/+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 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
I had the update of the bug description on my todo list - it's done now. ** Description changed: === SRU information === + [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. - The issue has also been reported independently and with another engine (devcrypto). - The issue is fixed in openssl 3.0.8 which landed in lunar. + - An openssl engine is req. to test the fix. + - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. + - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. + - Install the needed package that allows to exploit the hw crypto resources: + sudo apt-get install libica-utils libica? openssl-ibmca + - And copy a working sample openssf.cnf file: + sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf + - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: + (dynamic) Dynamic engine loading support + (ibmca) Ibmca hardware engine support <=== + - try to create a new certificate, using this cmd-line: + openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' + - The above command must not lead to a 'Segmentation fault (core dumped)', + rather than create a proper certificate file. + Also watch /var/log/syslog / journalctl for more details. + - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Excuse me for chiming in so late, but we can test (and even recreate) the situation by ourselves on our system (and we have systems with attached crypto hw to it). I just tried it on a jammy z/VM guest: $ lszcrypt -V CARD.DOM TYPE MODESTATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER 02 CEX5C CCA-Coproc online10 11 08 S--D--N-- cex4card 02.0011 CEX5C CCA-Coproc online10 11 08 S--D--N-- cex4queue $ sudo apt-get install libica-utils libica? openssl-ibmca $ sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf $ openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support $ openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ..+++...+*.++...+.++.+..+..+*...+..+..+...+...++.+..++...+...+..+..+.+ ...+..+.+.+*...+..+...++...+...++.+.+...+...+...+*+...+.+..++...+..+..+...+..+.+..+.+.+...++.+.+..+.+...+..+.+.++...+.++..+.+...+...+..+.+...++...+++.+.+..+..+...+..+.+.+.+.+.+..+..++...+..+...+...+..+++..+.+..+.+...+.+.+.+.+.+.+.+.+.+.+++..+..+..+..+.+..+...+..+..++.+..+..+..+...+.+.+...+...+.+.+..+...+..+..+.+ - Segmentation fault (core dumped) $ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in pri
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Changed in: s390-tools (Ubuntu) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Medium ** Changed in: ubuntu-z-systems Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corresponding ud
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
This was implemented around 2020, mainly to catch any ccw config changes in a user friendly way: https://bugs.launchpad.net/bugs/1892367 https://i527439087.restricted.launchpadlibrarian.net/527439087/20f6c87a-829f-11eb-9412-002481e91f22.txt?token=zC4n7TlCmffBDHm9Dl002PsfchDXC3Dk Regarding: "1) Have the generic udev initramfs script not copy zdev-generated Udev rules," we need to be super careful here to not break stuff ... How to best identify the zdev-generated Udev rules, since these are not all the rules generated by chzdev (indicated by first line in rule), are they? I'm not very sure if initramfs(-tools) maintainer(s) are very happy ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution.
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Package changed: linux (Ubuntu) => s390-tools (Ubuntu) ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-z-systems Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corres
[Touch-packages] [Bug 2037569] Re: udev issues with mantic beta
Hi Dan, I've took the manytic daily from yesterday (Oct 3rd) and checked if the updated udisks2 package is in - which is the case - and gave it a try. I did multiple different installations - all with DASDs, on LPAR and on z/VM. Installations with a single DASD or with multiple DASDs (even combining them to a bigger disk using LVM), and I didn't faced udev issues anymore. I checked with top during the installation as well as after the post-install reboot was completed -- all good. So many thanks for your fix and upload on this (and Seb's review) ! ** Changed in: ubuntu-z-systems Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037569 Title: udev issues with mantic beta Status in Ubuntu on IBM z Systems: Fix Released Status in libblockdev package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in udisks2 package in Ubuntu: Fix Released Bug description: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 2037569] Re: udev issues with mantic beta
I think it's caused by udisksctl here: https://github.com/storaged-project/udisks/blob/c7027d888c00381851d918f33a13102e7b86e188/tools/udisksctl.c#L2810C1-L2811C75 due to its repeating monitor messages: udisksctl monitor ** (udisksctl monitor:424911): WARNING **: 11:14:33.100: (udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check failed: (g_strv_length ((gchar **) invalidated_properties) == 0) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037569 Title: udev issues with mantic beta Status in Ubuntu on IBM z Systems: Confirmed Status in systemd package in Ubuntu: Confirmed Status in udisks2 package in Ubuntu: Confirmed Bug description: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 2037569] Re: udev issues with mantic beta
Today I did some more tests and investigations. First of all I moved to the new mantic ISO image (20230928) that improved things quite a lot! The installation (on z/VM so far) is again very snappy and quick, incl. the enablement of a DASD device in the zDev activation screen. At the end of the installation, before hitting 'Reboot now' I went to the console and had a look at top to see if udev related processes are active, but I couldn't identify any: top - 10:47:51 up 9 min, 2 users, load average: 0.44, 0.41, 0.20 Tasks: 137 total, 1 running, 136 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 3988.9 total,214.3 free, 1957.6 used, 3233.2 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2031.3 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 15026 root 20 08788 4864 2816 R 0.7 0.1 0:00.28 top 1439 root 20 0 129824 74216 21376 S 0.3 1.8 0:03.76 /snap/subiquity/5183/usr/bin/python3.10 /snap/subiquity/518+ 1441 root 20 0 129788 74312 21376 S 0.3 1.8 0:03.57 /snap/subiquity/5183/usr/bin/python3.10 /snap/subiquity/518+ 2381 root 20 0 12216 5760 4864 S 0.3 0.1 0:00.10 sudo snap run subiquity 2383 root 20 0 206204 77680 21632 S 0.3 1.9 0:04.96 /snap/subiquity/5183/usr/bin/python3.10 -m subiquity 1 root 20 0 103300 13676 8940 S 0.0 0.3 0:03.49 /sbin/init --- 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kthreadd] 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [rcu_gp] 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [rcu_par_gp] 5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [slub_flushwq] 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [netns] 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [kworker/0:0H-events_highpri] 9 root 20 0 0 0 0 I 0.0 0.0 0:00.00 [kworker/0:1-cgroup_destroy] 10 root 20 0 0 0 0 I 0.0 0.0 0:01.11 [kworker/u128:0-events_unbound] 11 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [mm_percpu_wq] 12 root 20 0 0 0 0 I 0.0 0.0 0:00.00 [rcu_tasks_rude_kthread] 13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 [rcu_tasks_trace_kthread] Then, having the post-install reboot completed, and looking at top, I can observe the udev activities: top - 10:55:26 up 6 min, 1 user, load average: 2.16, 1.75, 0.84 Tasks: 108 total, 5 running, 103 sleeping, 0 stopped, 0 zombie %Cpu(s): 18.1 us, 22.7 sy, 0.0 ni, 48.8 id, 8.1 wa, 0.6 hi, 0.8 si, 0.9 st MiB Mem : 3988.9 total, 3274.2 free,271.4 used,539.0 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3717.5 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 1177 root 20 0 24884 5724 2560 R 33.2 0.1 1:50.24 (udev-worker) 1 root 20 0 168592 12912 8432 R 20.6 0.3 1:07.93 /sbin/init 690 root 20 0 467964 13112 10752 D 15.6 0.3 0:52.91 /usr/libexec/udisks2/udisksd 660 message+ 20 09328 4480 3840 S 14.6 0.1 0:52.68 @dbus-daemon --system --address=systemd: --nofork --nopidfile -+ 16285 ubuntu20 0 18004 9984 8448 S 10.6 0.2 0:33.06 /lib/systemd/systemd --user 385 root 20 0 24764 7492 4676 S 9.3 0.2 0:30.40 /lib/systemd/systemd-udevd 373 root rt 0 288412 26368 8064 S 6.6 0.6 0:21.50 /sbin/multipathd -d -s 686 root 20 0 16096 7424 6528 S 4.0 0.2 0:13.20 /lib/systemd/systemd-logind 681 root 20 0 2066332 34480 21248 S 1.7 0.8 0:0
[Touch-packages] [Bug 2037569] Re: udev issues with mantic beta
** Changed in: ubuntu-z-systems Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037569 Title: udev issues with mantic beta Status in Ubuntu on IBM z Systems: Confirmed Status in systemd package in Ubuntu: Confirmed Status in udisks2 package in Ubuntu: Confirmed Bug description: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 2037569] [NEW] udev issues with mantic beta
Public bug reported: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... ** Affects: ubuntu-z-systems Importance: High Status: New ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: mantic s390x ** Attachment added: "installation_testing.txt" https://bugs.launchpad.net/bugs/2037569/+attachment/5704968/+files/installation_testing.txt ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037569 Title: udev issues with mantic beta Status in Ubuntu on IBM z Systems: New Status in systemd package in Ubuntu: New Bug description: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** 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 openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Bug description: ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c Found module libc.so.6 with build-id: 74250317950da91d3345f258cb2dd12d22c3f2e5 Found module libcrypto.so.3 with build-id: a27f20e6cf293f214d459530ce2c0b2b52fdbdb4 Found module libssl.so.3 with build-id: e2c031c3dac06b5ce43bdea022aee7989f78dde4 Found module openssl with build-id: ed0fe325182e99d135ee6b08e6d90a9d1c42af7f Stack trace of thread 2344: #0 0x03ffae11c708 __pthread_rwlock_wrlock_full64 (libc.so.6 + 0x9c708) #1 0x03ffae437c22 CRYPTO_THREAD_write_lock (libcrypto.so.3 + 0x1b7c22) #2 0x03ffae3e3472 ENGINE_finish (libcrypto.so.3 + 0x163472)
[Touch-packages] [Bug 1926752] Re: [23.10 FEAT] libgmp SIMD optimizations
** 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 gmp in Ubuntu. https://bugs.launchpad.net/bugs/1926752 Title: [23.10 FEAT] libgmp SIMD optimizations Status in Ubuntu on IBM z Systems: Fix Released Status in gmp package in Ubuntu: Fix Released Bug description: Optimize the GNU MP Bignum Library using vector instructions. - Requirement for Full Homomorphic Encryption, libgmp is used as a backend for NTL - libgmp performance is critical also for GNU Cobol on Z. Here a customer requested using packed decimal instructions in libgmp which does not appear to fit for libgmp - however SIMD would help on distros with ALS z13 https://gmplib.org/#STATUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1926752/+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 1926752] Re: [23.10 FEAT] libgmp SIMD optimizations
Many thx for your sponsorship, Graham! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gmp in Ubuntu. https://bugs.launchpad.net/bugs/1926752 Title: [23.10 FEAT] libgmp SIMD optimizations Status in Ubuntu on IBM z Systems: Fix Committed Status in gmp package in Ubuntu: Fix Committed Bug description: Optimize the GNU MP Bignum Library using vector instructions. - Requirement for Full Homomorphic Encryption, libgmp is used as a backend for NTL - libgmp performance is critical also for GNU Cobol on Z. Here a customer requested using packed decimal instructions in libgmp which does not appear to fit for libgmp - however SIMD would help on distros with ALS z13 https://gmplib.org/#STATUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1926752/+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 1926752] Re: [23.10 FEAT] libgmp SIMD optimizations
** 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 gmp in Ubuntu. https://bugs.launchpad.net/bugs/1926752 Title: [23.10 FEAT] libgmp SIMD optimizations Status in Ubuntu on IBM z Systems: Fix Committed Status in gmp package in Ubuntu: Fix Committed Bug description: Optimize the GNU MP Bignum Library using vector instructions. - Requirement for Full Homomorphic Encryption, libgmp is used as a backend for NTL - libgmp performance is critical also for GNU Cobol on Z. Here a customer requested using packed decimal instructions in libgmp which does not appear to fit for libgmp - however SIMD would help on distros with ALS z13 https://gmplib.org/#STATUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1926752/+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 1926752] Re: [23.10 FEAT] libgmp SIMD optimizations
added updated debdiff ** Patch added: "debdiff_gmp_mantic_from_6.2.1+dfsg1-1.1ubuntu1_to__6.2.1+dfsg1-1.1ubuntu2.diff" https://bugs.launchpad.net/ubuntu/+source/gmp/+bug/1926752/+attachment/5685689/+files/debdiff_gmp_mantic_from_6.2.1+dfsg1-1.1ubuntu1_to__6.2.1+dfsg1-1.1ubuntu2.diff ** Changed in: gmp (Ubuntu) Assignee: Frank Heimes (fheimes) => (unassigned) ** Information type changed from Private to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gmp in Ubuntu. https://bugs.launchpad.net/bugs/1926752 Title: [23.10 FEAT] libgmp SIMD optimizations Status in Ubuntu on IBM z Systems: In Progress Status in gmp package in Ubuntu: In Progress Bug description: Optimize the GNU MP Bignum Library using vector instructions. - Requirement for Full Homomorphic Encryption, libgmp is used as a backend for NTL - libgmp performance is critical also for GNU Cobol on Z. Here a customer requested using packed decimal instructions in libgmp which does not appear to fit for libgmp - however SIMD would help on distros with ALS z13 https://gmplib.org/#STATUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1926752/+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 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Package changed: linux (Ubuntu) => openssl (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: openssl (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) ** Changed in: openssl (Ubuntu) Importance: Undecided => High ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Tags added: rls-jj-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: New Status in openssl package in Ubuntu: New Bug description: ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c Found module libc.so.6 with build-id: 74250317950da91d3345f258cb2dd12d22c3f2e5 Found module libcrypto.so.3 with build-id: a27f20e6cf293f214d459530ce2c0b2b52fdbdb4 Found module libssl.so.3 with build-id: e2c031c3dac06b5ce43bdea022aee7989f78dde4 Found module openssl with build-id: ed0fe325182e99d135ee6b08e6d90a9d1c42af7f Stack trace of thread 2344:
[Touch-packages] [Bug 2017979] Re: [UBUNTU 20.04] Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated
Hi - the majority of engineers where on Sprints in the recent weeks, so we were a bit short on staff - apologize. This bug got already assigned. But to get you unblocked, you may just remove (sudo apt remove ...) the package in question (and the one that has it as dependency), since they are not mandatory: $ apt-cache policy language-pack-en-base language-pack-en language-pack-en-base: Installed: (none) Candidate: 1:20.04+20220818 Version table: 1:20.04+20220818 500 500 http://ports.ubuntu.com/ubuntu-ports focal-updates/main s390x Packages 1:20.04+20200416 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages language-pack-en: Installed: (none) Candidate: 1:20.04+20200416 Version table: 1:20.04+20200416 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages If you remove them, please note if further (reverse) dependencies are removed too, if so record them and re-install again after the upgrade. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to language-pack-en-base in Ubuntu. https://bugs.launchpad.net/bugs/2017979 Title: [UBUNTU 20.04] Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated Status in Ubuntu on IBM z Systems: Confirmed Status in language-pack-en-base package in Ubuntu: New Status in language-pack-en-base source package in Focal: Confirmed Bug description: ---Problem Description--- Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated do-release-update does not work Contact Information = pp...@de.ibm.com ---uname output--- Linux lnxut06 5.4.0-148-generic #165-Ubuntu SMP Tue Apr 18 08:52:35 UTC 2023 s390x s390x s390x GNU/Linux Machine Type = 3906 758 M03 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- root@lnxz:/etc/apt# do-release-upgrade Checking for a new Ubuntu release Please install all available updates for your release before upgrading. root@lnxz:/etc/apt# apt update Hit:1 http://de.ports.ubuntu.com/ubuntu-ports focal InRelease Get:2 http://de.ports.ubuntu.com/ubuntu-ports focal-updates InRelease [114 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [114 kB] Ign:4 https://pkg.jenkins.io/debian-stable binary/ InRelease Hit:5 https://pkg.jenkins.io/debian-stable binary/ Release Hit:7 http://de.ports.ubuntu.com/ubuntu-ports focal-backports InRelease Fetched 228 kB in 1s (201 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 1 package can be upgraded. Run 'apt list --upgradable' to see it. root@lnxz:/etc/apt# apt list --upgradable Listing... Done language-pack-en-base/focal-updates 1:20.04+20220818 all [upgradable from: 1:20.04+20220211] N: There are 2 additional versions. Please use the '-a' switch to see them. root@lnxz:/etc/apt# apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@lnxz:/etc/apt# apt --only-upgrade install language-pack-en-base Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: language-pack-en-base : Depends: language-pack-en (>= 1:20.04+20220818) but it is not going to be installed E: Unable to correct problems, you have held broken packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2017979/+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 2017979] Re: [UBUNTU 20.04] Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated
I can confirm that package 'language-pack-en-base' is not installable on an up to date 20.04.06 installation. $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.6 LTS Release:20.04 Codename: focal $ sudo apt update Hit:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease Hit:2 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease Hit:3 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease Hit:4 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date. $ apt-cache policy language-pack-en-base language-pack-en-base: Installed: (none) Candidate: 1:20.04+20220818 Version table: 1:20.04+20220818 500 500 http://ports.ubuntu.com/ubuntu-ports focal-updates/main s390x Packages 1:20.04+20200416 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages $ sudo apt install language-pack-en-base Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: language-pack-en-base : Depends: language-pack-en (>= 1:20.04+20220818) but it is not going to be installed E: Unable to correct problems, you have held broken packages. $ apt-cache policy language-pack-en language-pack-en: Installed: (none) Candidate: 1:20.04+20200416 Version table: 1:20.04+20200416 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages $ ** Package changed: linux (Ubuntu) => language-pack-en-base (Ubuntu) ** Also affects: language-pack-en-base (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: language-pack-en-base (Ubuntu Focal) Status: New => Confirmed ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => Confirmed ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: language-pack-en-base (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to language-pack-en-base in Ubuntu. https://bugs.launchpad.net/bugs/2017979 Title: [UBUNTU 20.04] Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated Status in Ubuntu on IBM z Systems: Confirmed Status in language-pack-en-base package in Ubuntu: New Status in language-pack-en-base source package in Focal: Confirmed Bug description: ---Problem Description--- Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated do-release-update does not work Contact Information = pp...@de.ibm.com ---uname output--- Linux lnxut06 5.4.0-148-generic #165-Ubuntu SMP Tue Apr 18 08:52:35 UTC 2023 s390x s390x s390x GNU/Linux Machine Type = 3906 758 M03 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- root@lnxz:/etc/apt# do-release-upgrade Checking for a new Ubuntu release Please install all available updates for your release before upgrading. root@lnxz:/etc/apt# apt update Hit:1 http://de.ports.ubuntu.com/ubuntu-ports focal InRelease Get:2 http://de.ports.ubuntu.com/ubuntu-ports focal-updates InRelease [114 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [114 kB] Ign:4 https://pkg.jenkins.io/debian-stable binary/ InRelease Hit:5 https://pkg.jenkins.io/debian-stable binary/ Release Hit:7 http://de.ports.ubuntu.com/ubuntu-ports focal-backports InRelease Fetched 228 kB in 1s (201 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 1 package can be upgraded. Run 'apt list --upgradable' to see it. root@lnxz:/etc/apt# apt list --upgradable Listing... Done language-pack-en-base/focal-updates 1:20.04+20220818 all [upgradable from: 1:20.04+20220211] N: There are 2 additional versions. Please use the '-a' switch to see them. root@lnxz:/etc/apt# apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@lnxz:/etc/apt# apt --only-upgrade install language-pack-en-base Reading packag
[Touch-packages] [Bug 1998470] Re: [23.04] re-add s390x vectorized crc32 support to zlib in lunar
** Summary changed: - re-add s390x vectorized crc32 support to zlib in lunar + [23.04] re-add s390x vectorized crc32 support to zlib in lunar ** 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/1998470 Title: [23.04] re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: Fix Released Status in zlib package in Ubuntu: Fix Released Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+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 1992178] Re: autopkgtest: upstream tests that run in qemu hang on ppc64el
** Tags added: ppc64el reverse-proxy-bugzilla ** Changed in: ubuntu-power-systems Importance: Undecided => Medium ** Changed in: ubuntu-power-systems Assignee: (unassigned) => bugproxy (bugproxy) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1992178 Title: autopkgtest: upstream tests that run in qemu hang on ppc64el Status in systemd: Unknown Status in The Ubuntu-power-systems project: New Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: New Bug description: I believe this started early in the kinetic cycle, cf. https://autopkgtest.ubuntu.com/packages/systemd/kinetic/ppc64el vs https://autopkgtest.ubuntu.com/packages/systemd/jammy/ppc64el. Timeouts in the upstream tests have been an issue for a while, but kinetic on ppc64el consistently times out with upstream tests that run in QEMU. Skipping individual tests does not help, because *which* tests time out appears to change with each build. For example, in 251.4-1ubuntu4 the TEST-36-NUMAPOLICY test was consistently the culprit, but now in 251.4-1ubuntu6 the TEST-14-MACHINE-ID often times out. I have not been able to identify a root cause for this, but it seems that running tests in QEMU is very fragile on ppc64el, where as the tests that run in nspawn are more consistent. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1992178/+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 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
** Changed in: ubuntu-z-systems Status: Triaged => 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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x Status in Ubuntu on IBM z Systems: In Progress Status in zlib: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: New Status in zlib source package in Jammy: New Status in zlib source package in Kinetic: New Status in zlib source package in Lunar: In Progress Bug description: SRU Justification: -- [ Impact ] * zlib version 1.2.13, as well as patched zlib versions 1.2.11 with the patch from LP#1990379, break libxml2 and lxml on s390x. * The problem appears during loading a gzipped XML file. * Disabling hw compression with 'export DFLTCC=0' solves this, hence it's a problem with the hardware acceleration patches DFLTCC. * For more info see: https://bugzilla.redhat.com/show_bug.cgi?id=2155328 [ Test Plan ] * Steps to Reproduce: 1. echo "" > file.xml 2. gzip file.xml 3. python3 >>> import libxml2 >>> libxml2.parseFile("file.xml.gz") * Actual results: file.xml.gz:1: parser error : Document is empty ^ Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.11/site-packages/libxml2.py", line 1362, in parseFile if ret is None:raise parserError('xmlParseFile() failed') ^^ libxml2.parserError: xmlParseFile() failed * Expected results: Loaded file. [ Where problems could occur ] * Since this is limited to s390x and DFLTCC / hw acceleration active, any possible problems are limited to such environments. * Fix can be broken if the state handling (state->wrap), or the states mixed. * The translation from stream to parameter block could be broken (again due to wrong states) and the inflate as well. [ Other Info ] * The official upstream fix is here: https://github.com/zlib-ng/zlib-ng/pull/1390 but it's for zlib-ng. * For zlib this needs to be adjusted and was done by the author here: https://launchpadlibrarian.net/641454325/patch-1.2.11 * And again slightly adjusted by me (renamed, some white-space fixes and conversion into a quilt patch with proper dep3 header): https://launchpadlibrarian.net/645435847/1390.patch * The zlib version in Focal, Jammy, Kinetic and Lunar are affected. __ It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+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 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
** Patch added: "debdiff_zlib_lunar_from_1.2.13.dfsg-1ubuntu3_to_1.2.13.dfsg-1ubuntu4.diff" https://bugs.launchpad.net/zlib/+bug/2002511/+attachment/5640780/+files/debdiff_zlib_lunar_from_1.2.13.dfsg-1ubuntu3_to_1.2.13.dfsg-1ubuntu4.diff -- 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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x Status in Ubuntu on IBM z Systems: Triaged Status in zlib: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: New Status in zlib source package in Jammy: New Status in zlib source package in Kinetic: New Status in zlib source package in Lunar: In Progress Bug description: SRU Justification: -- [ Impact ] * zlib version 1.2.13, as well as patched zlib versions 1.2.11 with the patch from LP#1990379, break libxml2 and lxml on s390x. * The problem appears during loading a gzipped XML file. * Disabling hw compression with 'export DFLTCC=0' solves this, hence it's a problem with the hardware acceleration patches DFLTCC. * For more info see: https://bugzilla.redhat.com/show_bug.cgi?id=2155328 [ Test Plan ] * Steps to Reproduce: 1. echo "" > file.xml 2. gzip file.xml 3. python3 >>> import libxml2 >>> libxml2.parseFile("file.xml.gz") * Actual results: file.xml.gz:1: parser error : Document is empty ^ Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.11/site-packages/libxml2.py", line 1362, in parseFile if ret is None:raise parserError('xmlParseFile() failed') ^^ libxml2.parserError: xmlParseFile() failed * Expected results: Loaded file. [ Where problems could occur ] * Since this is limited to s390x and DFLTCC / hw acceleration active, any possible problems are limited to such environments. * Fix can be broken if the state handling (state->wrap), or the states mixed. * The translation from stream to parameter block could be broken (again due to wrong states) and the inflate as well. [ Other Info ] * The official upstream fix is here: https://github.com/zlib-ng/zlib-ng/pull/1390 but it's for zlib-ng. * For zlib this needs to be adjusted and was done by the author here: https://launchpadlibrarian.net/641454325/patch-1.2.11 * And again slightly adjusted by me (renamed, some white-space fixes and conversion into a quilt patch with proper dep3 header): https://launchpadlibrarian.net/645435847/1390.patch * The zlib version in Focal, Jammy, Kinetic and Lunar are affected. __ It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+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 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
** Summary changed: - zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x + zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on 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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x Status in Ubuntu on IBM z Systems: Triaged Status in zlib: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: New Status in zlib source package in Jammy: New Status in zlib source package in Kinetic: New Status in zlib source package in Lunar: In Progress Bug description: SRU Justification: -- [ Impact ] * zlib version 1.2.13, as well as patched zlib versions 1.2.11 with the patch from LP#1990379, break libxml2 and lxml on s390x. * The problem appears during loading a gzipped XML file. * Disabling hw compression with 'export DFLTCC=0' solves this, hence it's a problem with the hardware acceleration patches DFLTCC. * For more info see: https://bugzilla.redhat.com/show_bug.cgi?id=2155328 [ Test Plan ] * Steps to Reproduce: 1. echo "" > file.xml 2. gzip file.xml 3. python3 >>> import libxml2 >>> libxml2.parseFile("file.xml.gz") * Actual results: file.xml.gz:1: parser error : Document is empty ^ Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.11/site-packages/libxml2.py", line 1362, in parseFile if ret is None:raise parserError('xmlParseFile() failed') ^^ libxml2.parserError: xmlParseFile() failed * Expected results: Loaded file. [ Where problems could occur ] * Since this is limited to s390x and DFLTCC / hw acceleration active, any possible problems are limited to such environments. * Fix can be broken if the state handling (state->wrap), or the states mixed. * The translation from stream to parameter block could be broken (again due to wrong states) and the inflate as well. [ Other Info ] * The official upstream fix is here: https://github.com/zlib-ng/zlib-ng/pull/1390 but it's for zlib-ng. * For zlib this needs to be adjusted and was done by the author here: https://launchpadlibrarian.net/641454325/patch-1.2.11 * And again slightly adjusted by me (renamed, some white-space fixes and conversion into a quilt patch with proper dep3 header): https://launchpadlibrarian.net/645435847/1390.patch * The zlib version in Focal, Jammy, Kinetic and Lunar are affected. __ It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+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 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
** Bug watch added: Red Hat Bugzilla #2155328 https://bugzilla.redhat.com/show_bug.cgi?id=2155328 ** Also affects: zlib via https://bugzilla.redhat.com/show_bug.cgi?id=2155328 Importance: Unknown Status: Unknown -- 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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: Triaged Status in zlib: Unknown Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: New Status in zlib source package in Jammy: New Status in zlib source package in Kinetic: New Status in zlib source package in Lunar: In Progress Bug description: SRU Justification: -- [ Impact ] * zlib version 1.2.13, as well as patched zlib versions 1.2.11 with the patch from LP#1990379, break libxml2 and lxml on s390x. * The problem appears during loading a gzipped XML file. * Disabling hw compression with 'export DFLTCC=0' solves this, hence it's a problem with the hardware acceleration patches DFLTCC. * For more info see: https://bugzilla.redhat.com/show_bug.cgi?id=2155328 [ Test Plan ] * Steps to Reproduce: 1. echo "" > file.xml 2. gzip file.xml 3. python3 >>> import libxml2 >>> libxml2.parseFile("file.xml.gz") * Actual results: file.xml.gz:1: parser error : Document is empty ^ Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.11/site-packages/libxml2.py", line 1362, in parseFile if ret is None:raise parserError('xmlParseFile() failed') ^^ libxml2.parserError: xmlParseFile() failed * Expected results: Loaded file. [ Where problems could occur ] * Since this is limited to s390x and DFLTCC / hw acceleration active, any possible problems are limited to such environments. * Fix can be broken if the state handling (state->wrap), or the states mixed. * The translation from stream to parameter block could be broken (again due to wrong states) and the inflate as well. [ Other Info ] * The official upstream fix is here: https://github.com/zlib-ng/zlib-ng/pull/1390 but it's for zlib-ng. * For zlib this needs to be adjusted and was done by the author here: https://launchpadlibrarian.net/641454325/patch-1.2.11 * And again slightly adjusted by me (renamed, some white-space fixes and conversion into a quilt patch with proper dep3 header): https://launchpadlibrarian.net/645435847/1390.patch * The zlib version in Focal, Jammy, Kinetic and Lunar are affected. __ It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+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 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
** Description changed: + SRU Justification: + -- + + [ Impact ] + + * zlib version 1.2.13, as well as patched zlib versions 1.2.11 with +the patch from LP#1990379, break libxml2 and lxml on s390x. + + * The problem appears during loading a gzipped XML file. + + * Disabling hw compression with 'export DFLTCC=0' solves this, +hence it's a problem with the hardware acceleration patches DFLTCC. + + * For more info see: + https://bugzilla.redhat.com/show_bug.cgi?id=2155328 + + [ Test Plan ] + + * Steps to Reproduce: +1. echo "" > file.xml +2. gzip file.xml +3. python3 +>>> import libxml2 +>>> libxml2.parseFile("file.xml.gz") + + * Actual results: +file.xml.gz:1: parser error : Document is empty +^ +Traceback (most recent call last): + File "", line 1, in + File "/usr/lib/python3.11/site-packages/libxml2.py", + line 1362, in parseFile +if ret is None:raise parserError('xmlParseFile() failed') + ^^ +libxml2.parserError: xmlParseFile() failed + + * Expected results: +Loaded file. + + [ Where problems could occur ] + + * Since this is limited to s390x and DFLTCC / hw acceleration active, +any possible problems are limited to such environments. + + * Fix can be broken if the state handling (state->wrap), +or the states mixed. + + * The translation from stream to parameter block could be broken +(again due to wrong states) and the inflate as well. + + [ Other Info ] + + * The official upstream fix is here: +https://github.com/zlib-ng/zlib-ng/pull/1390 +but it's for zlib-ng. + + * For zlib this needs to be adjusted and was done by the author here: +https://launchpadlibrarian.net/641454325/patch-1.2.11 + + * And again slightly adjusted by me (renamed, some white-space fixes +and conversion into a quilt patch with proper dep3 header): +https://launchpadlibrarian.net/645435847/1390.patch + + * The zlib version in Focal, Jammy, Kinetic and Lunar are affected. + __ + It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. ** Also affects: zlib (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: zlib (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: zlib (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: zlib (Ubuntu Lunar) Importance: High Status: New ** Changed in: ubuntu-z-systems Status: New => Triaged ** Changed in: zlib (Ubuntu Lunar) 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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: Triaged Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: New Status in zlib source package in Jammy: New Status in zlib source package in Kinetic: New Status in zlib source package in Lunar: In Progress Bug description: SRU Justification: -- [ Impact ] * zlib version 1.2.13, as well as patched zlib versions 1.2.11 with the patch from LP#1990379, break libxml2 and lxml on s390x. * The problem appears during loading a gzipped XML file. * Disabling hw compression with 'export DFLTCC=0' solves this, hence it's a problem with the hardware acceleration patches DFLTCC. * For more info see: https://bugzilla.redhat.com/show_bug.cgi?id=2155328 [ Test Plan ] * Steps to Reproduce: 1. echo "" > file.xml 2. gzip file.xml 3. python3 >>> import libxml2 >>> libxml2.parseFile("file.xml.gz") * Actual results: file.xml.gz:1: parser error : Document is empty ^ Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.11/site-packages/libxml2.py", line 1362, in parseFile if ret is None:raise parserError('xmlParseFile() failed') ^^ libxml2.parserError: xml
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
PPA test builds a ongoing for F, J, K and L at https://launchpad.net/~fheimes/+archive/ubuntu/lp2002511 -- 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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
Hi Ilya, yepp, breaking libxml2 is of course an issue. Regarding the fix/patch, you attached here a patch named 'patch-1.2.11'. We have currently the following package versions in the archive: 1.2.11.dfsg-2ubuntu1.5 | focal 1.2.11.dfsg-2ubuntu9.2 | jammy 1.2.11.dfsg-4.1ubuntu1 | kinetic 1.2.13.dfsg-1ubuntu3 | lunar-proposed (After having tweaked the patch a bit regarding white-spaces...) the patch applies fine on focal, jammy and kinetic. I wondered if the patch is also for 1.2.13 (I think so, since the RH bug tells that), which is what we currently have in lunar-proposed - and it actually applies there fine too. I just needed to open a separate LP bug for this, since I need a separate bug number to reference this fix/patch in the changelogs: https://bugs.launchpad.net/bugs/2002511 So regarding the libxml(2) issue, the further work and communication will be there. -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: Triaged Status in zlib source package in Jammy: Triaged Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. * This bug (LP#1990379) is solved in combination with LP#1982583, so that only one package update is needed. However, this bug affects Kinetic, jammy and Focal, but LP#1982583 only Jammy and Kinetic. * The debdiffs for Kinetic and Jammy should be taken from LP#1982583, and the remaining debdiff for Focal from here. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
Attaching the slightly modified and renamed patch (original is at LP#1990379), now as quilt patch, with some whitespace adjustments and a proper dep3 header. ** Patch added: "1390.patch" https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+attachment/5640638/+files/1390.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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+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 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on 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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+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 2002511] [NEW] zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
Public bug reported: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. ** Affects: ubuntu-z-systems Importance: High Status: New ** Affects: zlib (Ubuntu) Importance: High Status: New ** Tags: s390x ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Summary changed: - zlib 1.2.13 breaks libxml(2) on s390x + zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x ** 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/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+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 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
** 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/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Committed Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+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 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
Thx for reviewing, uploading and the fix! -- 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/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Triaged Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+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 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
After getting the successful test results, I'm attaching the debdiff ... ** Attachment added: "debdiff_zlib_lunar_from_1.2.13.dfsg-1ubuntu2_to_1.2.13.dfsg-1ubuntu3.diff~" https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1998470/+attachment/5634588/+files/debdiff_zlib_lunar_from_1.2.13.dfsg-1ubuntu2_to_1.2.13.dfsg-1ubuntu3.diff~ -- 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/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Triaged Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+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 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
Cross-referencing Ilya's comment about testing from here: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1982583/comments/7 " I ran tests 1-3 with Frank's 1:1.2.13.dfsg-1ubuntu3. They all pass; the performance improvement is also measurable. Test 4 turned out to be meaningless: Ubuntu requires at least z13. " Just notice that we have z13 as minimal required Z architecture starting with Ubuntu 20.04/focal anyway. -- 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/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Triaged Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+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 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
** Changed in: zlib (Ubuntu) Status: New => Triaged ** Changed in: ubuntu-z-systems Status: New => Triaged ** Changed in: ubuntu-z-systems Status: Triaged => 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/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Triaged Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+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 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
Test builds of the updated package are currently running in this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1998470 ** Description changed: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch - since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. + since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. + https://launchpad.net/ubuntu/+source/zlib/+changelog - This new patch is now available as + The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): - * Re-add vectorized crc32 support for s390x by adding - d/p/s390x-vectorize-crc32.patch - (crc32vx-v4: s390x: vectorize crc32). - This replaces the previously dropped patch: - lp1932010-ibm-z-add-vectorized-crc32-implementation.patch - * Remove option '--crc32-vx' for s390x in d/rules, that was previously just - commented out, since it's no longer needed with the new s390x crc32 code. + * Re-add vectorized crc32 support for s390x by adding + d/p/s390x-vectorize-crc32.patch + (crc32vx-v4: s390x: vectorize crc32). + This replaces the previously dropped patch: + lp1932010-ibm-z-add-vectorized-crc32-implementation.patch + * Remove option '--crc32-vx' for s390x in d/rules, that was previously just + commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: - * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 - due to unused "const char *endptr;". + * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 + due to unused "const char *endptr;". -- 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/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+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 1998470] [NEW] re-add s390x vectorized crc32 support to zlib in lunar
Public bug reported: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. This new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". ** Affects: ubuntu-z-systems Importance: Medium Assignee: Skipper Bug Screeners (skipper-screen-team) Status: New ** Affects: zlib (Ubuntu) Importance: Medium Assignee: Frank Heimes (fheimes) Status: New ** Tags: s390x ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => Medium ** 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/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. This new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+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 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
** Changed in: systemd (Ubuntu) Status: Incomplete => Invalid ** Changed in: ubuntu-z-systems Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Invalid Status in systemd package in Ubuntu: Invalid Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+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 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
Oh yes, makes sense - thanks for the hint! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+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 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
Hmm, I just checked the changelog of the relevant packages (openssl and systemd), assuming to find a fix that might have landed in between your two attempts - but not much, mainly CVE fixes. (I also assume you haven't installed any local packages either...) And you've used the same packages than I did. So right now I can't really say what happened... Anyway, would you be okay with me closing this bug? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+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 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
Btw. before you retry, you may fix the broken packaging state of your system with: sudo apt-get -y -f install and then: sudo apt update ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+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 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu) ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Status: New => Incomplete ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+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 1983128] Re: linux-lowlatency fails to build on arm64 due to kernel option settings
set to invails, since this was for a previous proposed migrations issue that was meanwhile solved ** Changed in: linux-lowlatency (Ubuntu) Status: New => Invalid ** Changed in: zlib (Ubuntu) Status: New => Invalid -- 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/1983128 Title: linux-lowlatency fails to build on arm64 due to kernel option settings Status in linux-lowlatency package in Ubuntu: Invalid Status in zlib package in Ubuntu: Invalid Bug description: The 'linux-lowlatency' kernel build (incl. autopkgtest) was triggered in a kinetic-proposed migration process (for zlib) and runs into a 'regression': "autopkgtest for linux-lowlatency/5.19.0-1001.1: amd64: Pass, arm64: Regression ♻" The regression is highly likely not due to zlib itself, but due to NEW kernel options, that don't have a default yet and a check-config FAIL, see: ... check-config: /tmp/autopkgtest.ZQs9si/build.cYo/src/debian/build/build-lowlatency/.config: loading config check-config: /tmp/autopkgtest.ZQs9si/build.cYo/src/debian.lowlatency/config/annotations loading annotations check-config: FAIL (n != -): CONFIG_KCOV policy<{'amd64': 'n', 'arm64': -, 'armhf': 'n', 'ppc64el': '-', 'riscv64': 'n', 's390x': '-'}> check-config: 11323/11324 checks passed -- exit 1 ... Shadow Call Stack (SHADOW_CALL_STACK) [N/y/?] (NEW) Error in reading or end of file. ... Initialize kernel stack variables at function entry > 1. no automatic stack variable initialization (weakest) (INIT_STACK_NONE) 2. pattern-init everything (strongest) (INIT_STACK_ALL_PATTERN) (NEW) 3. zero-init everything (strongest and safest) (INIT_STACK_ALL_ZERO) (NEW) choice[1-3?]: Error in reading or end of file. ... Full log is here: https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/arm64/l/linux-lowlatency/20220728_135536_c2061@/log.gz (this might be caused by the recent compiler update) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1983128/+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 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
** 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 binutils in Ubuntu. https://bugs.launchpad.net/bugs/1974115 Title: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16 Status in Ubuntu on IBM z Systems: Fix Released Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Released Status in binutils source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact] * As of today the architectural (level) name 'arch14' is used as CPU name for the new IBM z16 system. * The real name 'z16' couldn't be used until officially announced. * That happened meanwhile, hence we can now add and use the real name. [Test Plan] * Check if the same (proper) opcodes are detected on an IBM z16 system with and without the patch. Since only the identification and name of a z16 system was modified. * Or the simplest test is probably to check (after having 'binutils' installed on an Ubuntu 22.04 s390x system) if not only: 'as -m64 -march=arch14 --target-help' but also: 'as -m64 -march=z16 --target-help' succeeds and leads to the same output. (As it does for '-march=arch13' and '-march=arch15'.) [Where problems could occur] * Issues could happen if the conditional statement that look for architectural / CPU name are paired wrongly, since: * 'z16' belongs to 'arch14', 'z15' to 'arch13', etc. * If these pairs are not handled correctly, or the identification is erroneous a wrong system might be identified and wrong instructions used etc. [Other] * This is a hardware enablement SRU to enhance the IBM z16 support. __ After the announcement support for the official machine name z16 has been added to binutils. Please consider picking up the following patch from 2.37 branch: commit e24d2a2d11008aa363366c1087219f3e3405782a (origin/binutils-2_37-branch, 2.37) IBM zSystems: Add support for z16 as CPU name. So far z16 was identified as arch14. After the machine has been announced we can now add the real name. (cherry picked from commit 69341966def7f6551bc4452684136831d6a6941c) (cherry picked from commit fb4d148004f28494e9fb5d2400a13308d07a7988) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1974115/+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 1978129] Re: Incomplete support for DT_RELR relocations on Ubuntu 22.04
** Changed in: ubuntu-power-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 binutils in Ubuntu. https://bugs.launchpad.net/bugs/1978129 Title: Incomplete support for DT_RELR relocations on Ubuntu 22.04 Status in The Ubuntu-power-systems project: Fix Released Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Released Status in binutils source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact] * The latest glibc uses DT_RELR relocations, but it turned out that the linker support is still incomplete, as of binutils-2.38-3ubuntu1 on Ubuntu 22.04. * It lacks the fix/commit 'PowerPC64 DT_RELR relative reloc addresses'. * As discussed at the binutils mailing list: https://sourceware.org/pipermail/binutils/2022-March/119921.html this fixes several (glibc) regressions (from 574 to 17). * Instead of stashing r_offset final address calculations in ppc64_elf_size_stubs for use by ppc64_elf_build_stubs, section/offset pairs need to be kept. [Test Plan] * Build and run the official (make) check: git clone git://sourceware.org/git/glibc.git mkdir build && cd build ../glibc/configure --prefix=/usr && make -j8 && make check [Where problems could occur] * In case relr_addr is not replaced everywhere it's deletion in elf64-ppc.c can cause problems, which will mainly occur at build time. * The relr section/offset array may lead to problems if the array is not properly handled or used. * The rewrite of append_relr_off may cause issues due to wrong allocs erroneous pointer arithmetic or array handling. * The entirely new sort_relr function may introduce new code issues or performance issues. * The adjustments of ppc64_elf_size_stubs and ppc64_elf_build_stubs to the new relr code could be done wrong in which case the linker support is still not working. * But the patch was discussed at the upstream mailing list: https://sourceware.org/pipermail/binutils/2022-March/thread.html#119921 * and is limited to ppc, and even to file 'elf64-ppc.c'. __ == Comment: #0 - Matheus Salgueiro Castanho - 2022-06-09 09:32:29 == ---Problem Description--- Latest glibc uses DT_RELR relocations, but linker support is incomplete as of binutils-2.38-3ubuntu1 on Ubuntu 22.04. It lacks the following fix integrated into the upstream 2.38 branch: PowerPC64 DT_RELR relative reloc addresses https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e4a35c7319628045302d4c597cb27f1b0a08c858 As mentioned in the binutils mailing list when this patch was discussed, this fixes several glibc regressions: https://sourceware.org/pipermail/binutils/2022-March/119921.html Contact Information = Matheus Castanho/mscasta...@ibm.com ---uname output--- N/A Machine Type = N/A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- git clone git://sourceware.org/git/glibc.git mkdir build && cd build ../glibc/configure --prefix=/usr && make -j8 && make check Userspace tool common name: binutils The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils Userspace tool obtained from project website: na *Additional Instructions for Matheus Castanho/mscasta...@ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1978129/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Summary changed: - [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used + [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: Triaged Status in zlib source package in Jammy: Triaged Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. * This bug (LP#1990379) is solved in combination with LP#1982583, so that only one package update is needed. However, this bug affects Kinetic, jammy and Focal, but LP#1982583 only Jammy and Kinetic. * The debdiffs for Kinetic and Jammy should be taken from LP#1982583, and the remaining debdiff for Focal from here. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1990379] Re: [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Description changed: SRU Justification: -- [ Impact ] - * The zlib function inflate() does not update strm.adler -in case DFLTCC is used. + * The zlib function inflate() does not update strm.adler + in case DFLTCC is used. - * This issue was exposed by Java Certification Kit (JCK) running on z15 -hardware and newer and impacts all JDK versions (8,11,17, etc.) -that use the system default settings. + * This issue was exposed by Java Certification Kit (JCK) running on z15 + hardware and newer and impacts all JDK versions (8,11,17, etc.) + that use the system default settings. - * The JCK failure impacts the ability to certify Java SDKs on this -platform/Linux-distribution combination. + * The JCK failure impacts the ability to certify Java SDKs on this + platform/Linux-distribution combination. - * On top the incorrect alder32 result may cause functional issues with -Java applications that depend on the result. + * On top the incorrect alder32 result may cause functional issues with + Java applications that depend on the result. [ Test Plan ] - * An affected Ubuntu release (20.04, 22.04 and 22.10) installed -on a z15/LinuxONE III or newer system is needed. + * An affected Ubuntu release (20.04, 22.04 and 22.10) installed + on a z15/LinuxONE III or newer system is needed. - * Then it's possible to test the updated package with the help -of a small test program (in C) that makes use of the zlib1g library -or run the Java Certification Kit. + * Then it's possible to test the updated package with the help + of a small test program (in C) that makes use of the zlib1g library + or run the Java Certification Kit. - * Test will be done by IBM. + * Test will be done by IBM. [ Where problems could occur ] - * The patch is a one-line change: -https://launchpadlibrarian.net/626003193/410-lp1990379.patch -and there are not many issues to expect. + * The patch is a one-line change: + https://launchpadlibrarian.net/626003193/410-lp1990379.patch + and there are not many issues to expect. - * There could be a potential problem with the adler field -in the strm struct. -For example in case the struct is not as assumed or contains -and unexpected value, which would then ripple through -the other fields, too. + * There could be a potential problem with the adler field + in the strm struct. + For example in case the struct is not as assumed or contains + and unexpected value, which would then ripple through + the other fields, too. - * Structural changes could be identified with a test build that was done -for all affected Ubuntu releases and for all major architectures: -https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 + * Structural changes could be identified with a test build that was done + for all affected Ubuntu releases and for all major architectures: + https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] - - * The patch itself is the same for all zlib version in -20.04, 22.04 and 22.10 - no further adjustments were needed. + + * The patch itself is the same for all zlib version in + 20.04, 22.04 and 22.10 - no further adjustments were needed. + + * This bug (LP#1990379) is solved in combination with LP#1982583, +so that only one package update is needed. +However, this bug affects Kinetic, jammy and Focal, +but LP#1982583 only Jammy and Kinetic. + + * The debdiffs for Kinetic and Jammy should be taken from LP#1982583, +and the remaining debdiff for Focal from here. + __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 -- 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/1990379 Title: [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Jammy: In Progress Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib funct
[Touch-packages] [Bug 1982583] Re: Fix for zlib CRC32 optimization for s390x
** Description changed: + SRU Justification: + -- + + [ Impact ] + + * There were two issues identified in the current +zlib CRC32 optimization for s390x implementation: + + * 1) s390_crc32_vx() signature mismatch + which causes a warning + + * 2) '-DS390_CRC32_VX' was not added to SFLAGS + which results in vectorization being enabled only in the static library. + + * The fixes are quite small and affect each only one line: + + * 1) by using unsigned longs instead of uint32_t in s390_crc32_vx + declaration + + * 2) by add line 'SFLAGS="$SFLAGS -DS390_CRC32_VX"' + + [ Test Plan ] + + * An affected Ubuntu release ([20.04], 22.04 and 22.10) installed +on a z15/LinuxONE III or newer system is needed. + + * Then it's possible to test the updated package with the help +of a small test program (in C) that checks for +s390_crc32_vx() signature mismatches. + + * The bug reporter has a set of s390x-specific tests that will be + executed. + + * Test will be done by IBM. + + [ Where problems could occur ] + + * The fixes are each limited to one line, hence there are +not many issues to expect, other than: + + * Typos (e.g. in the flags), mixing of CFLAGS and SFLAGS, + + * in case the changed data type in s390_crc32_vx is causing issues +inside of s390_crc32_vx or in other parts of the code. + + * Structural and syntactical issues can be identified with a test build +that was done for all affected Ubuntu releases and for all major archs: +https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379+lp1982583 + + [ Other Info ] + + * This bug (LP#1982583) is solved in combination with LP#1982583, +so that only one package update is needed. +However, LP#1982583 also affects Focal, but this bug only Jammy and Kinetic. + + * To fix LP#1982583 also for focal the debdiff mentioned there is needed, too. + __ + 'zlib CRC32 optimization for s390x works only in a static library' I've discovered two issues in lp1932010-ibm-z-add-vectorized- crc32-implementation.patch: 1) s390_crc32_vx() signature mismatch, resulting in a warning. 2) -DS390_CRC32_VX is not added to SFLAGS, resulting in vectorization being enabled only in the static library. I've attached the updated patch. ** Description changed: SRU Justification: -- [ Impact ] - * There were two issues identified in the current -zlib CRC32 optimization for s390x implementation: + * There were two issues identified in the current + zlib CRC32 optimization for s390x implementation: - * 1) s390_crc32_vx() signature mismatch - which causes a warning + * 1) s390_crc32_vx() signature mismatch + which causes a warning - * 2) '-DS390_CRC32_VX' was not added to SFLAGS - which results in vectorization being enabled only in the static library. + * 2) '-DS390_CRC32_VX' was not added to SFLAGS + which results in vectorization being enabled only in the static library. - * The fixes are quite small and affect each only one line: + * The fixes are quite small and affect each only one line: - * 1) by using unsigned longs instead of uint32_t in s390_crc32_vx + * 1) by using unsigned longs instead of uint32_t in s390_crc32_vx declaration - * 2) by add line 'SFLAGS="$SFLAGS -DS390_CRC32_VX"' + * 2) by add line 'SFLAGS="$SFLAGS -DS390_CRC32_VX"' [ Test Plan ] - * An affected Ubuntu release ([20.04], 22.04 and 22.10) installed -on a z15/LinuxONE III or newer system is needed. + * An affected Ubuntu release ([20.04], 22.04 and 22.10) installed + on a z15/LinuxONE III or newer system is needed. - * Then it's possible to test the updated package with the help -of a small test program (in C) that checks for -s390_crc32_vx() signature mismatches. + * Then it's possible to test the updated package with the help + of a small test program (in C) that checks for + s390_crc32_vx() signature mismatches. - * The bug reporter has a set of s390x-specific tests that will be + * The bug reporter has a set of s390x-specific tests that will be executed. - * Test will be done by IBM. + * Test will be done by IBM. [ Where problems could occur ] - * The fixes are each limited to one line, hence there are -not many issues to expect, other than: + * The fixes are each limited to one line, hence there are + not many issues to expect, other than: - * Typos (e.g. in the flags), mixing of CFLAGS and SFLAGS, + * Typos (e.g. in the flags), mixing of CFLAGS and SFLAGS, - * in case the changed data type in s390_crc32_vx is causing issues -inside of s390_crc32_vx or in other parts of the code. + * in case the changed data type in s390_crc32_vx is causing issues + inside of s390_crc32_vx or in other parts of the code. - * Structural and syntactical issues can be identified with a test build -that was done for all affected Ub
[Touch-packages] [Bug 1982583] Re: Fix for zlib CRC32 optimization for s390x
I transferred the modification into a separate patch (d/p/lp1982583-fix-for-zlib-crc32-optimization-for-s390x.patch), and build a patched version (for all major architectures) in PPA for jammy and kinetic: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379+lp1982583 and attaching here the debdiff for jammy and kinetic - which are for both LP bugs, this LP#1982583 and LP#1990379. ** Attachment added: "lp1990379+lp1982583_debdiffs.tgz" https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1982583/+attachment/5622051/+files/lp1990379+lp1982583_debdiffs.tgz ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: zlib (Ubuntu) Importance: Undecided => High ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: zlib (Ubuntu) Status: New => In Progress ** 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/1982583 Title: Fix for zlib CRC32 optimization for s390x Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Bug description: 'zlib CRC32 optimization for s390x works only in a static library' I've discovered two issues in lp1932010-ibm-z-add-vectorized- crc32-implementation.patch: 1) s390_crc32_vx() signature mismatch, resulting in a warning. 2) -DS390_CRC32_VX is not added to SFLAGS, resulting in vectorization being enabled only in the static library. I've attached the updated patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982583/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
I've just noticed another bug that I want to fix with the same package update: LP#1982583 But LP#1982583 affects only jammy and kinetic, not focal. This means for fixing this bug (LP#1990379) for jammy and kinetic, please use these debdiffs: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982583/comments/2 and for fixing this bug (LP#1990379) for focal, please take the focal debdiff from the previous comment: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/comments/7 -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Jammy: In Progress Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1982583] Re: zlib CRC32 optimization for s390x works only in a static library
** Description changed: + 'zlib CRC32 optimization for s390x works only in a static library' + I've discovered two issues in lp1932010-ibm-z-add-vectorized- crc32-implementation.patch: 1) s390_crc32_vx() signature mismatch, resulting in a warning. 2) -DS390_CRC32_VX is not added to SFLAGS, resulting in vectorization being enabled only in the static library. I've attached the updated patch. ** Summary changed: - zlib CRC32 optimization for s390x works only in a static library + Fix for zlib CRC32 optimization for 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/1982583 Title: Fix for zlib CRC32 optimization for s390x Status in zlib package in Ubuntu: New Bug description: 'zlib CRC32 optimization for s390x works only in a static library' I've discovered two issues in lp1932010-ibm-z-add-vectorized- crc32-implementation.patch: 1) s390_crc32_vx() signature mismatch, resulting in a warning. 2) -DS390_CRC32_VX is not added to SFLAGS, resulting in vectorization being enabled only in the static library. I've attached the updated patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1982583/+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 1961427] Re: zlib: compressBound() 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/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Fix Released Status in bedtools package in Ubuntu: Fix Released Status in htslib package in Ubuntu: Invalid Status in zlib package in Ubuntu: Fix Released Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: Fix Committed Status in zlib source package in Focal: Fix Released Status in bedtools source package in Impish: Won't Fix Status in htslib source package in Impish: Won't Fix Status in zlib source package in Impish: Won't Fix Status in bedtools source package in Jammy: Fix Released Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Fix Released Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Changed in: zlib (Ubuntu Kinetic) Importance: Medium => 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Jammy: In Progress Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Also affects: zlib (Ubuntu Kinetic) Importance: Medium Status: In Progress ** Also affects: zlib (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: zlib (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: zlib (Ubuntu Focal) Status: New => In Progress ** Changed in: zlib (Ubuntu Jammy) 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Jammy: In Progress Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Description changed: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. + + --- + External link: https://warthogs.atlassian.net/browse/PEI-28 ** Tags added: pei-28 -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae3
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
debdiffs for F, J and K ** Attachment added: "debdiffs.tgz" https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+attachment/5619739/+files/debdiffs.tgz -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Description changed: + SRU Justification: + -- + + [ Impact ] + + * The zlib function inflate() does not update strm.adler +in case DFLTCC is used. + + * This issue was exposed by Java Certification Kit (JCK) running on z15 +hardware and newer and impacts all JDK versions (8,11,17, etc.) +that use the system default settings. + + * The JCK failure impacts the ability to certify Java SDKs on this +platform/Linux-distribution combination. + + * On top the incorrect alder32 result may cause functional issues with +Java applications that depend on the result. + + [ Test Plan ] + + * An affected Ubuntu release (20.04, 22.04 and 22.10) installed +on a z15/LinuxONE III or newer system is needed. + + * Then it's possible to test the updated package with the help +of a small test program (in C) that makes use of the zlib1g library +or run the Java Certification Kit. + + * Test will be done by IBM. + + [ Where problems could occur ] + + * The patch is a one-line change: +https://launchpadlibrarian.net/626003193/410-lp1990379.patch +and there are not many issues to expect. + + * There could be a potential problem with the adler field +in the strm struct. +For example in case the struct is not as assumed or contains +and unexpected value, which would then ripple through +the other fields, too. + + * Structural changes could be identified with a test build that was done +for all affected Ubuntu releases and for all major architectures: +https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 + + [ Other Info ] + + * The patch itself is the same for all zlib version in +20.04, 22.04 and 22.10 - no further adjustments were needed. + __ + == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. ** Changed in: zlib (Ubuntu) Status: New => In Progress ** 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/c
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
Ok, that's a (minimal) patch that can be handled nicely, thanks Ilya! Test packages are now being build in the following PPA for focal/20.04, jammy/22.04 and kinetic/22.10: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379/+packages It would be great if someone (for example 'rahil'?!) could test (probably) at least the focal package upfront, to ensure that the situation is really solved, and with that, give us confidence for the SRU process. (Please notice that this would be on top of the official verification request that will come up later during the SRU process). -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
So the next step would be to get more clarity on the complexity of the patch that is required. We have the (initial) PR 410 incl. in the zlib package, plus the patches from LP#1899621 and LP#1961427 on top. Hence we cannot directly use the new version of PR 410: https://github.com/madler/zlib/pull/410 and also the zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 seems to incl. more than just the fix for 'zlib: inflate() does not update strm.adler if DFLTCC is used'. For example I'm pretty sure that the modifications in contrib/s390/dfltcc.c and infback.c (as listed in the zlib diff) are part of the fix, but since I'm not the author I am unsure if this is everything that's needed. Are the changes in the crc32 needed on top? I think the typo fixes can be largely neglected ... Hence can you please provide us with a patch/backport for the minimal changes that are needed to fix 'zlib: inflate() does not update strm.adler if DFLTCC is used' and that applies on top of what's already in the zlib package (obviously after the quilt patches were applied)? Ideally based on the kinetic package (but the zlib packages in jammy and focal are pretty close, hence I assume that a backport will apply there too.) -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Changed in: zlib (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
Thanks for reporting this, Ilya. Can you please elaborate about the potential impact of this issue - that 'inflate() does not update strm.adler if DFLTCC is used'? Especially because this is marked with severity medium, but the Ubuntu stable release update process (SRUs: https://wiki.ubuntu.com/StableReleaseUpdates) is generally in order to fix high-impact bugs. With updating stable releases (like in this case 20.04 and 22.04) there is huge carefulness needed, and especially with updating key packages and libraries like zlib, since zlib has significant package reverse dependencies and a huge amount of reverse build dependencies (both in the thousands). Furthermore a potential update will impact multi-millions of installations, cross architecture, and we won't do that for a non-critical bugs, that maybe even only impact a small number of installations. However, there might be a little chance to piggy-back a fix like this with a more severe zlib update that might come up in future. ** Changed in: zlib (Ubuntu) Importance: Undecided => Medium -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Package changed: linux (Ubuntu) => zlib (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: ubuntu-z-systems Importance: Undecided => Medium -- 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/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+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 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Well, I had comment #11 in mind where the 1:1.2.11.dfsg-2ubuntu1.3 was successfully verified on focal. Meanwhile that version got overruled by a security update: zlib (1:1.2.11.dfsg-2ubuntu1.3) focal-security; urgency=medium and became 'already used', hence a new version was needed for this bug and so we are now at: 1:1.2.11.dfsg-2ubuntu1.4 - but it incl. the same patches. Anyway, I'll ask to get 1:1.2.11.dfsg-2ubuntu1.4 verified again on 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/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Fix Committed Status in bedtools package in Ubuntu: Fix Released Status in htslib package in Ubuntu: Invalid Status in zlib package in Ubuntu: Fix Released Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: Fix Committed Status in zlib source package in Focal: Fix Committed Status in bedtools source package in Impish: Won't Fix Status in htslib source package in Impish: Won't Fix Status in zlib source package in Impish: Won't Fix Status in bedtools source package in Jammy: Fix Released Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Fix Released Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjus
[Touch-packages] [Bug 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
Hi Andreas, thanks for the verification, I'm going to adjust the tags accordingly. Don't worry about the potential regression, it's an automated mail based on the results of the autopkgtests that run automatically while processing such an SRU like this - and binutils trigger a lot of tests. Such regressions can be caused by several different things, like a different package that is handled at the same time and triggers similar tests or a flaky test etc. - we deal with it. (IF we think it's due to s390x-specific code, we may reach out to you ;-) ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1974115 Title: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16 Status in Ubuntu on IBM z Systems: Fix Committed Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Committed Status in binutils source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact] * As of today the architectural (level) name 'arch14' is used as CPU name for the new IBM z16 system. * The real name 'z16' couldn't be used until officially announced. * That happened meanwhile, hence we can now add and use the real name. [Test Plan] * Check if the same (proper) opcodes are detected on an IBM z16 system with and without the patch. Since only the identification and name of a z16 system was modified. * Or the simplest test is probably to check (after having 'binutils' installed on an Ubuntu 22.04 s390x system) if not only: 'as -m64 -march=arch14 --target-help' but also: 'as -m64 -march=z16 --target-help' succeeds and leads to the same output. (As it does for '-march=arch13' and '-march=arch15'.) [Where problems could occur] * Issues could happen if the conditional statement that look for architectural / CPU name are paired wrongly, since: * 'z16' belongs to 'arch14', 'z15' to 'arch13', etc. * If these pairs are not handled correctly, or the identification is erroneous a wrong system might be identified and wrong instructions used etc. [Other] * This is a hardware enablement SRU to enhance the IBM z16 support. __ After the announcement support for the official machine name z16 has been added to binutils. Please consider picking up the following patch from 2.37 branch: commit e24d2a2d11008aa363366c1087219f3e3405782a (origin/binutils-2_37-branch, 2.37) IBM zSystems: Add support for z16 as CPU name. So far z16 was identified as arch14. After the machine has been announced we can now add the real name. (cherry picked from commit 69341966def7f6551bc4452684136831d6a6941c) (cherry picked from commit fb4d148004f28494e9fb5d2400a13308d07a7988) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1974115/+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 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** 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/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Fix Committed Status in bedtools package in Ubuntu: Fix Released Status in htslib package in Ubuntu: Invalid Status in zlib package in Ubuntu: Fix Released Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: Fix Committed Status in zlib source package in Focal: Fix Committed Status in bedtools source package in Impish: Won't Fix Status in htslib source package in Impish: Won't Fix Status in zlib source package in Impish: Won't Fix Status in bedtools source package in Jammy: Fix Released Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Fix Released Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e73
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Thx Iliya! (updating tag accordingly) ** Tags removed: verification-needed verification-needed-focal verification-needed-jammy ** Tags added: verification-done verification-done-focal verification-done-jammy -- 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/1961427 Title: zlib: compressBound() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: In Progress Status in bedtools package in Ubuntu: Fix Released Status in htslib package in Ubuntu: Invalid Status in zlib package in Ubuntu: Fix Released Status in bedtools source package in Focal: Invalid Status in htslib source package in Focal: Fix Committed Status in zlib source package in Focal: Fix Committed Status in bedtools source package in Impish: Won't Fix Status in htslib source package in Impish: Won't Fix Status in zlib source package in Impish: Won't Fix Status in bedtools source package in Jammy: Fix Committed Status in htslib source package in Jammy: Invalid Status in zlib source package in Jammy: Fix Committed Bug description: SRU Justification: == [Impact] * zlib: compressBound() returns an incorrect result on IBM z15 hardware. * Passing the result of compressBound() to compress() results in an error code. * This is because compressBound() is not adjusted for DFLTCC. [Fix] * Adjust compressBound() for DFLTCC like it's already done for deflateBound(). * Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is b25781e735363e04f6c56e21431c47e4afc50b17. * The fix extracted out of the above is: https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff * On top of this actual zlib fix, there is another patch needed: 'Remove compressBound assertions. (PR #1258)' for htslib. * But there is a standalone 'htslib' package version, as well as a htslib version included in (some) 'bedtools' packages. Both need to be patched (see '[Other]' for more details). [Test Plan] * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine) with Ubuntu Server 21.10 (or 22.04). * A test can be done based on the following C test program: #include #include #include int main() { Bytef in_buf[128], out_buf[1024]; for (size_t i = 0; i < sizeof(in_buf); i++) in_buf[i] = rand(); uLongf dest_len = compressBound(sizeof(in_buf)); assert(dest_len <= sizeof(out_buf)); int ret = compress(out_buf, &dest_len, in_buf, sizeof(in_buf)); assert(ret == Z_OK); } * The test needs to be done by IBM, due to the requirements for the special z15 hardware. * A successful test was just completed, based on the version in jammy- proposed, which is at the same code level that the impish version this SRU is targeted for. [Where problems could occur] * If the adjustment of compressBound() for DFLTCC is done erroneously the issue can still be present or in worst case even affect Z systems other than z15 only. * The compression can become errorneous with the new changes, e.g. in compressBound. * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN, (incl. the bit definitions), may cause various and unforseen defects. * Any build time issues that might have been introduced by this patch can be identified by a test build; this was done and is available here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 [Other Info] * Ubuntu jammy, impish and focal are affected by the zlib issue. * The 'htslib' version '1.13+ds' (as it is part of I, J and K), already includes the patch, hence only htslib '1.10.2' in focal needs to be patched. * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K), requires the patch, but version '2.27.1+dfsg' bedtools in focal does not incl. an embedded htslib, hence does not need to be (actually can't be) patched. * Patched version of the affected htslib and bedtools packages are build and also available at this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 __ Description: zlib: compressBound() returns an incorrect result on z15 Symptom: Passing the result of compressBound() to compress() results in an error code. Problem: compressBound() is not adjusted for DFLTCC. Solution: Adjust compressBound() for DFLTCC like it's already done for deflateBound(). Since zlib project does not accept patches at the moment, the fix has been integrated into