[Touch-packages] [Bug 2044104] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From mario.h...@de.ibm.com 2024-09-05 04:23 EDT---
The problem seems fixed meanwhile for Oracular (24.10) see here 
https://launchpad.net/ubuntu/+source/s390-tools
Are you thinking of backports for the LTS releases 22.04 and 20.04 ?

-- 
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:
  New
Status in s390-tools package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  New
Status in s390-tools source package in Oracular:
  Fix Released
Status in systemd source package in Oracular:
  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 exac

[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2024-08-19 11:34 EDT---
Thanks everyone for your work!
With the fix being verified and released, we can close this bug.
==> Changing status to "CLOSED"

** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2410

-- 
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

[Touch-packages] [Bug 1992178] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From cha...@us.ibm.com 2024-08-15 16:17 EDT---
What is the status of this bug? Looking at:

> https://github.com/systemd/systemd/issues/25091#issuecomment-1695289642
> https://github.com/systemd/systemd/issues/25091#issuecomment-1398091323

It looks like a couple of commits were provided to mitigate the issue
last year? I only see one track in the LP bug that indicates a fix was
released. Thanks.

-- 
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 2075567] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2024-08-15 09:00 EDT---
I don't think the other patch is necessary. Stefan backported only 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e903ada5e8881acec734eb3f89c3644bbd8da7e9
 to gcc-14.

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2024-08-15 04:26 EDT---
Stefan has committed the patches:

master:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e8a7142a697c5d2673adea33ba23af82a89c9559

gcc-14:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e903ada5e8881acec734eb3f89c3644bbd8da7e9

-- 
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

[Touch-packages] [Bug 2075567] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2024-08-09 05:47 EDT---
Thanks Stefan, for your GCC patch posted at: 
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659923.html

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2024-08-07 12:48 EDT---
Thanks Ilya for your quick analysis, finding out that this is a compiler issue. 
Stefan will send a patch to the GCC mailing list.
We will post a link here once it's available.

-- 
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] Re: zlib fails to build on s390x on oracular with gcc 14

[bugproxy]

** Tags added: architecture-s39064 bugnameltc-208475 severity-high
targetmilestone-inin---

-- 
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);
|^~
||
|__vector(16) 
unsigned

[Touch-packages] [Bug 2075204] Re: gdb on s390x chokes on divide-by-zero from chaos-marmosets

[bugproxy]

** Tags added: architecture-s39064 bugnameltc-208023 severity-high
targetmilestone-inin---

-- 
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 1833322] Comment bridged from LTC Bugzilla

[bugproxy]

Now?  CPUs are faster; if you disable irqtune, you can observe in
/proc/interrupts that various device interrupts are still sent to CPUs
other than CPU0, they just don't go ping-ponging around between all of
them like they do with irqtune.  A big difference compared to the early
days, for example for ethernet a lot of the work that was done in the
interrupt handler back then, the interrupt handler now does the bare
minimum and does the rest of the work with a kernel thread (same for
wifi, which tends to be a bit of an interrupt and CPU hog).  Meaning the
actual interrupts take much less time to run now than they did then.
The total CPU time could still add up to more than 1 core can handle if
you had, say, 10gbps ethernet.  But the kernel threads can be scheduled
to any CPU core just like any other thread even if the interrupts are
tied to one CPU.

-- 
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 2044104] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From peter.oberparlei...@de.ibm.com 2024-01-31 04:28 EDT---
(In reply to comment #22)
> Then `/sbin/chzdev --is-author-of-udev-rule "$rules"` should produce the
> correct exit code. The tool that generates the udev rules should be queried
> (is that chzdev or something else?) or a separate helper should be used.
>
> Re-assinging from initramfs-tools to systemd, because
> /usr/share/initramfs-tools/hooks/udev is shipped by udev.

I agree with this approach.

Yes, the udev rules are generated by chzdev, so we'll work on adding a
chzdev command line option that can be used to query ownership of a udev
rule/configuration file similar to what is as outlined above.

I'll update this bug report once the option as available in upstream
s390-tools.

-- 
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:
  New
Status in s390-tools package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New
Status in s390-tools source package in Noble:
  New
Status in systemd source package in Noble:
  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_

[Touch-packages] [Bug 2023545] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2024-01-25 07:28 EDT---
Thanks everyone for your work.
With the fix being released to -updates, I will close this bug as soon as the 
status in Launchpad changes to "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: 
4700bc0,0
   #03ffae11c704: 
b24f00a0ear%r10,%a0
    

[Touch-packages] [Bug 2023545] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From grgo.mari...@ibm.com 2024-01-23 05:09 EDT---
# apt-cache policy libssl3 openssl
libssl3:
Installed: 3.0.2-0ubuntu1.13
Candidate: 3.0.2-0ubuntu1.13
Version table:
*** 3.0.2-0ubuntu1.13 400
400 http://ports.ubuntu.com/ubuntu-ports jammy-proposed/main s390x Packages
100 /var/lib/dpkg/status
3.0.2-0ubuntu1.12 500
500 http://ports.ubuntu.com/ubuntu-ports jammy-updates/main s390x Packages
500 http://ports.ubuntu.com/ubuntu-ports jammy-security/main s390x Packages
3.0.2-0ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports jammy/main s390x Packages
openssl:
Installed: 3.0.2-0ubuntu1.13
Candidate: 3.0.2-0ubuntu1.13
Version table:
*** 3.0.2-0ubuntu1.13 400
400 http://ports.ubuntu.com/ubuntu-ports jammy-proposed/main s390x Packages
100 /var/lib/dpkg/status
3.0.2-0ubuntu1.12 500
500 http://ports.ubuntu.com/ubuntu-ports jammy-updates/main s390x Packages
500 http://ports.ubuntu.com/ubuntu-ports jammy-security/main s390x Packages
3.0.2-0ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports jammy/main s390x Packages

Successfully verified. The problem is not visible any more. Thank you!

-- 
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 ker

[Touch-packages] [Bug 2023545] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From grgo.mari...@ibm.com 2024-01-23 03:53 EDT---
After upgrading to Ubuntu 22.04.3 the solution is working and the problem is 
not visible anymore.

Explicit update of the fix is not valid on the older version (22.04.1).

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From grgo.mari...@ibm.com 2024-01-23 03:44 EDT---
The problem is still visible after installing the -proposed package:

root:~# dpkg -l | grep openssl
ii  openssl   3.0.2-0ubuntu1.13 
  s390xSecure Sockets Layer toolkit - cryptographic utility
ii  openssl-ibmca 2.2.3-0ubuntu1.1  
  s390xlibica based hardware acceleration engine for OpenSSL
ii  python3-openssl   21.0.0-1  
  all  Python 3 wrapper around the OpenSSL library
root:~# openssl engine
(dynamic) Dynamic engine loading support
(ibmca) Ibmca hardware engine support

By running with gdb the following BT can be observed:
(gdb) r
Starting program: /usr/bin/openssl req -new -newkey rsa:2048 -x509 -sha256 
-nodes -out __cert.pem -keyout __key.pem --subj /CN=US
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
.+*..+.+.+..++...+...+.+*.+.+.+.+..+...+.+..+.+...+.+.+.+..+..+...++.+...+..+...+...+..+.+...+
...+.+++*...+.+.+..+*++...+
-

Program received signal SIGSEGV, Segmentation fault.
0x03fffd89c738 in __pthread_rwlock_wrlock_full64 (abstime=0x0, clockid=0, 
rwlock=0x0) at pthread_rwlock_common.c:603
603 pthread_rwlock_common.c: No such file or directory.
(gdb) bt
#0  0x03fffd89c738 in __pthread_rwlock_wrlock_full64 (abstime=0x0, 
clockid=0, rwlock=0x0) at pthread_rwlock_common.c:603
#1  ___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:26
#2  0x03fffdbb7812 in CRYPTO_THREAD_write_lock () from 
/lib/s390x-linux-gnu/libcrypto.so.3
#3  0x03fffdb634f2 in ENGINE_finish () from 
/lib/s390x-linux-gnu/libcrypto.so.3
#4  0x03fffdb86314 in EVP_CIPHER_CTX_reset () from 
/lib/s390x-linux-gnu/libcrypto.so.3
#5  0x03fffdb8635c in EVP_CIPHER_CTX_free () from 
/lib/s390x-linux-gnu/libcrypto.so.3
#6  0x03fffdc791ac in ?? () from /lib/s390x-linux-gnu/libcrypto.so.3
#7  0x03fffdb8ca88 in EVP_RAND_CTX_free () from 
/lib/s390x-linux-gnu/libcrypto.so.3
#8  0x03fffdbe4bc2 in ?? () from /lib/s390x-linux-gnu/libcrypto.so.3
#9  0x03fffdbb0c6c in CRYPTO_free_ex_data () from 
/lib/s390x-linux-gnu/libcrypto.so.3
#10 0x03fffdba8dfa in ?? () from /lib/s390x-linux-gnu/libcrypto.so.3
#11 0x03fffdbb36b8 in OPENSSL_cleanup () from 
/lib/s390x-linux-gnu/libcrypto.so.3
#12 0x03fffd84b6ec in __run_exit_handlers (status=, 
listp=0x3fffd9ce618 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:113
#13 0x03fffd84b7b0 in __GI_exit (status=) at exit.c:143
#14 0x02aa00047c06 in main ()

syslog shows the following:

Jan 22 15:14:03 a8314006.lnxne.boe kernel:  [<03ff89d3242c>] 0x3ff89d3242c
Jan 22 15:14:03 a8314006.lnxne.boe kernel: Last Breaking-Event-Address:
Jan 22 15:14:03 a8314006.lnxne.boe kernel: User Code: 03ff89b1c72c: 
b90400b2lgr%r11,%r2
03ff89b1c730: 4700bc0,0
#03ff89b1c734: b24f00a0ear%r10,%a0
>03ff89b1c738: 58102018l%r1,24(%r2)
03ff89b1c73c: ebaa002dsllg%r10,%r10,32
03ff89b1c742: b24f00a1ear%r10,%a1
03ff89b1c746: 5910a0d0c%r1,208(%r10)
03ff89b1c74a: a7840033brc8,03ff89b1c7b0
Jan 22 15:14:03 SYSTEM kernel:03ff89c4dd10 03ff8a057120 
03ff89e37812 03ffc93fe170
Jan 22 15:14:03 SYSTEM kernel:03ff8a270720 03ff8a057128 
02aa03ff 
Jan 22 15:14:03 SYSTEM kernel:02aa272ac835 02aa0d8d5a40 
 02aa0d8da370
Jan 22 15:14:03 SYSTEM kernel: User GPRS: 0007 03ff89b1c720 
 02aa0d8d5a40
Jan 22 15:14:03 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
Jan 22 15:14:03 SYSTEM kernel: User PSW : 070500018000 03ff89b1c738
Jan 22 15:14:03 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0)
Jan 22 15:14:03 SYSTEM kernel: CPU: 0 PID: 98944 Comm: openssl Not tainted 
5.15.0-91-generic #101-Ubuntu
Jan 22 15:14:03 SYSTEM kernel: AS:9b00c1c7 R3:0024
Jan 22 15:14:03 SYSTEM kernel: Fault in primary space mode while u

[Touch-packages] [Bug 1974056] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From wint...@de.ibm.com 2024-01-19 05:42 EDT---
@xnox, @Boris,

are there any updates on this?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1974056

Title:
  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0 fails on s390x

Status in iptables:
  Unknown
Status in Ubuntu on IBM z Systems:
  In Progress
Status in iptables package in Ubuntu:
  New

Bug description:
  In Ubuntu, we execute the full iptables shell testcases across all
  architectures.

  They seem to all pass everywhere, however

  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0

  is currently failing on s390x like so:

  command17FAIL stderr: W: [FAILED]  ././testcases/nft-
  only/0009-needless-bitwise_0: expected 0 but got 1

  i wonder if there is some endian bug, as this is currently Ubuntu's
  only big-endian architecture.

  this can be reproduced with:

  pull-lp-source iptables
  cd iptables-1.8.7/
  chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
  cd iptables/tests/shell
  sudo ./run-tests.sh --host

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1974056/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From cborn...@de.ibm.com 2024-01-15 06:46 EDT---
Just a statement from s390x/IBM Z. For our platform irqbalance makes no sense 
as our interrupt handling works differently. So we do not need it.

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From holger.deng...@ibm.com 2024-01-11 13:09 EDT---
(In reply to comment #9)
> Holger: I can't pretend speaking for the SRU team, but I'd be willing to bet
> that having "the fix is trivial" as a test plan would result in the SRU
> being trivially rejected :-).

@schopin: The API description of localtime_r() (man localtime_r)
describes, that the function can return a NULL pointer on error. The API
documentation of strftime() (man strftime) describes, that the last
parameter of the function should not be a NULL pointer. If a program put
the return value of localtime_r() as the last parameter in a strftime()
call, than we have a classical programming error. It is just a missing
NULL pointer check. That was the thing, that I meant with "trivial".
There are a lot of patches in many projects, which introduces NULL
pointer checks. For the most of them I guess, there was never a test
case or test plan.

So yes, if you find a way to cause a reproducible failure of
localtime_r(), you can write a testcase. But I'm not sure, if it is
worth to spend all that effort in a fix, which just fixes a missing NULL
pointer check...

-- 
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

[bugproxy]

** Tags added: architecture-s39064 bugnameltc-204586 severity-medium
targetmilestone-inin2404

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From holger.deng...@ibm.com 2023-12-11 02:24 EDT---
Even if the problem can be reproduced easier on 32-bit architectures, the 
architecture doesn't matter at all. If you do a syscall in userspace programs, 
you have to check the returned value for errors. Period.

In my opinion, the fix for the problem is trivial (just do not call
strftime() with a NULL pointer), so the reproduction of a failure and a
test of the fix can be skipped here. It is more important, that the fix
is pushed into the field as soon as possible.

-- 
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:
  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/+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 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly

[bugproxy]

** Tags added: architecture-s39064 bugnameltc-204450 severity-medium
targetmilestone-inin---

-- 
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:
  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/+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 2037569] Re: udev issues with mantic beta

[bugproxy]

** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2310

-- 
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 2044104] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From peter.oberparlei...@de.ibm.com 2023-11-22 09:17 EDT---
(In reply to comment #19)
> 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?

chzdev creates udev rules that can most easily be recognized via their name:
- 41--.rules
- 41-cio-ignore.rules
- 40-zdev-id.rules

So a simple filter would be to skip rules named 41-*.rules on s390x in
the initramfs udev hook.

As an alternative, the s390-tools zdev initramfs hook could try to
delete specifically those rules with zdev:early=0 that the upstream udev
hook created. While this should work correctly, it is also a kind of a
workaround, where one hook adds files that another hook removes again...

If this approach is more likely to be acceptable, it could be achieved
by adding something like the following to /usr/share/initramfs-
tools/hooks/s390-tools-zdev:

# Remove zdev rules not intended for early boot that were copied by udev hook
chzdev --disable --persistent --by-attr zdev:early=0 \
--base "/etc/udev/rules.d/=$DESTDIR/lib/udev/rules.d/" \
--yes --quiet --no-root-update --force >/dev/null 2>&1

-- 
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://bugzil

[Touch-packages] [Bug 1992178] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From sthou...@in.ibm.com 2023-11-20 03:40 EDT---
Harsh, This issue/bug is reported on Ubuntu 22.04 Distro and hence we cannot 
track behavior reported in other Distro like fedora though internally 
Development can check those behaviour.

I will ask Jamie if he can pass the machine recreate information and steps on 
Ubuntu distro.
.

-- 
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 1990379] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2023-10-17 10:45 EDT---
Fix has been released to Focal, Jammy and Kinetic. With 22.10 being out of 
service, we can close the bug.

==> Changing the status to: "CLOSED"

-- 
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:
  Won't Fix

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 2037569] Re: udev issues with mantic beta

[bugproxy]

** Tags added: architecture-s39064 bugnameltc-203787 severity-high
targetmilestone-inin---

-- 
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 2023545] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From christian.r...@de.ibm.com 2023-09-14 03:15 EDT---
First, reproduced the behaviour of the problem as described and encountered the 
segmentation fault situation as described.
Wrote out the coredump with coredumpctl dump and saw from the call stack the 
reported problem was reproduced.

The installed libssl3 and openssl versions were:
# dpkg -l libssl3 openssl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--
ii  libssl3:s390x  3.0.2-0ubuntu1.10 s390xSecure Sockets Layer toolkit 
- shared libraries
ii  openssl3.0.2-0ubuntu1.10 s390xSecure Sockets Layer toolkit 
- cryptographic utility

Next, added the ppa repository as instructed.

# apt list --upgradable
Listing... Done
libssl-dev/jammy 3.0.2-0ubuntu1.11~ppa2 s390x [upgradable from: 
3.0.2-0ubuntu1.10]
libssl3/jammy 3.0.2-0ubuntu1.11~ppa2 s390x [upgradable from: 3.0.2-0ubuntu1.10]
openssl/jammy 3.0.2-0ubuntu1.11~ppa2 s390x [upgradable from: 3.0.2-0ubuntu1.10]

Successfully updated the three required packages to the version provided by the 
ppa package:
# apt upgrade libssl3 openssl libssl-dev
The following packages will be upgraded:
libssl-dev libssl3 openssl
3 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
Need to get 5,038 kB of archives.
After this operation, 5,120 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
...

Cross-checked the libssl3 and openssl packages had been successfully upgraded:
# dpkg -l libssl3 openssl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--
ii  libssl3:s390x  3.0.2-0ubuntu1.11~ppa2 s390xSecure Sockets Layer 
toolkit - shared libraries
ii  openssl3.0.2-0ubuntu1.11~ppa2 s390xSecure Sockets Layer 
toolkit - cryptographic utility

Next checked the ibmca engine is still enabled, and subsequently was able to 
run the key generation request without encountering the segmentation fault.
Thanks for providing the fix.
Please integrate.

Thanks.

# openssl engine
(dynamic) Dynamic engine loading support
(ibmca) Ibmca hardware engine support
# openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
# openssl req  -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem 
-keyout __key.pem --subj '/CN=US'
..+..+.+..+...+.+.+..+...+.+.+*..+..+.+.+...++...++.+*+.+.+...+..+...+..+..+.+..+.+..+..+.++...+...+.+..+..++...+...+...+..+.+
+...+.++..++..+++.+..+...+.+...+.+..++*..+..+...+...+..+..+...+..+...+*++..+..+...++..+.+.+..+
-
# echo RC=$?
RC=0

-- 
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:
  ---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:

[Touch-packages] [Bug 2029438] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2023-08-28 04:22 EDT---
Thanks @Canonical for catching this.
Thank you Stefan for your fix & successful verification.

The updated package has been included in Mantic, therefore we can close
this bug.

==> Changing the status to: "CLOSED"

-- 
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/2029438

Title:
  gmp z13 config fails with illegal instructions

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in gmp package in Ubuntu:
  Fix Released

Bug description:
  seen with 
  https://launchpad.net/ubuntu/+source/gmp/2:6.3.0+dfsg-2ubuntu2/+build/26470068

  Note, that MPN_PATH is now unset in 2:6.3.0+dfsg-2ubuntu3

  [...]
  ../../../test-driver: line 112: 76812 Illegal instruction (core dumped) 
"$@" >> "$log_file" 2>&1
  FAIL: t-hamdist
  PASS: t-oddeven
  ../../../test-driver: line 112: 76824 Illegal instruction (core dumped) 
"$@" >> "$log_file" 2>&1
  FAIL: t-popcount
  PASS: t-set_f
  PASS: t-io_raw
  PASS: t-import
  PASS: t-export
  PASS: t-pprime_p
  ../../../test-driver: line 112: 76856 Illegal instruction (core dumped) 
"$@" >> "$log_file" 2>&1
  FAIL: t-nextprime
  PASS: t-remove
  PASS: t-limbs
  
  Testsuite summary for GNU MP 6.3.0
  
  # TOTAL: 64
  # PASS:  57
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  7
  # XPASS: 0
  # ERROR: 0
  
  See tests/mpz/test-suite.log
  Please report to gmp-b...@gmplib.org (see 
https://gmplib.org/manual/Reporting-Bugs.html)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2029438/+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 2029438] Re: gmp z13 config fails with illegal instructions

[bugproxy]

** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2310

-- 
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/2029438

Title:
  gmp z13 config fails with illegal instructions

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in gmp package in Ubuntu:
  Fix Released

Bug description:
  seen with 
  https://launchpad.net/ubuntu/+source/gmp/2:6.3.0+dfsg-2ubuntu2/+build/26470068

  Note, that MPN_PATH is now unset in 2:6.3.0+dfsg-2ubuntu3

  [...]
  ../../../test-driver: line 112: 76812 Illegal instruction (core dumped) 
"$@" >> "$log_file" 2>&1
  FAIL: t-hamdist
  PASS: t-oddeven
  ../../../test-driver: line 112: 76824 Illegal instruction (core dumped) 
"$@" >> "$log_file" 2>&1
  FAIL: t-popcount
  PASS: t-set_f
  PASS: t-io_raw
  PASS: t-import
  PASS: t-export
  PASS: t-pprime_p
  ../../../test-driver: line 112: 76856 Illegal instruction (core dumped) 
"$@" >> "$log_file" 2>&1
  FAIL: t-nextprime
  PASS: t-remove
  PASS: t-limbs
  
  Testsuite summary for GNU MP 6.3.0
  
  # TOTAL: 64
  # PASS:  57
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  7
  # XPASS: 0
  # ERROR: 0
  
  See tests/mpz/test-suite.log
  Please report to gmp-b...@gmplib.org (see 
https://gmplib.org/manual/Reporting-Bugs.html)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2029438/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From s...@de.ibm.com 2023-07-21 05:29 EDT---
I've installed libgmp-dev, libgmp10 from matic in version 
2:6.2.1+dfsg1-1.1ubuntu2 and GMPbench shows the expected increase due to the 
z13 optimizations.
Thanks

-- 
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] debdiff_gmp_mantic_from_6.2.1+dfsg1-1.1ubuntu1_to__6.2.1+dfsg1-1.1ubuntu2.diff

[bugproxy]

Default Comment by Bridge

** Attachment added: 
"debdiff_gmp_mantic_from_6.2.1+dfsg1-1.1ubuntu1_to__6.2.1+dfsg1-1.1ubuntu2.diff"
   
https://bugs.launchpad.net/bugs/1926752/+attachment/5685690/+files/debdiff_gmp_mantic_from_6.2.1+dfsg1-1.1ubuntu1_to__6.2.1+dfsg1-1.1ubuntu2.diff

-- 
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 1974056] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From wint...@de.ibm.com 2023-07-05 12:00 EDT---
Is this a new testcase, or did it work before?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1974056

Title:
  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0 fails on s390x

Status in iptables:
  Unknown
Status in Ubuntu on IBM z Systems:
  In Progress
Status in iptables package in Ubuntu:
  New

Bug description:
  In Ubuntu, we execute the full iptables shell testcases across all
  architectures.

  They seem to all pass everywhere, however

  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0

  is currently failing on s390x like so:

  command17FAIL stderr: W: [FAILED]  ././testcases/nft-
  only/0009-needless-bitwise_0: expected 0 but got 1

  i wonder if there is some endian bug, as this is currently Ubuntu's
  only big-endian architecture.

  this can be reproduced with:

  pull-lp-source iptables
  cd iptables-1.8.7/
  chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
  cd iptables/tests/shell
  sudo ./run-tests.sh --host

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1974056/+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 1974056] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From wint...@de.ibm.com 2023-07-04 07:59 EDT---
Is this issue reproducable on your side?
Or can we close this?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1974056

Title:
  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0 fails on s390x

Status in iptables:
  Unknown
Status in Ubuntu on IBM z Systems:
  In Progress
Status in iptables package in Ubuntu:
  New

Bug description:
  In Ubuntu, we execute the full iptables shell testcases across all
  architectures.

  They seem to all pass everywhere, however

  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0

  is currently failing on s390x like so:

  command17FAIL stderr: W: [FAILED]  ././testcases/nft-
  only/0009-needless-bitwise_0: expected 0 but got 1

  i wonder if there is some endian bug, as this is currently Ubuntu's
  only big-endian architecture.

  this can be reproduced with:

  pull-lp-source iptables
  cd iptables-1.8.7/
  chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
  cd iptables/tests/shell
  sudo ./run-tests.sh --host

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1974056/+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 1974056] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From wint...@de.ibm.com 2023-06-26 03:07 EDT---
I was not able to reproduce this.
Runs fine on my machine (see below).
Any ideas how to continue?

root@m8360007:~/# cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/";
SUPPORT_URL="https://help.ubuntu.com/";
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/";
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
UBUNTU_CODENAME=jammy

root@m8360007:~# pull-lp-source iptables
Found iptables 1.8.7-1ubuntu7 in mantic
Downloading iptables_1.8.7-1ubuntu7.dsc from ports.ubuntu.com (0.003 MiB)
[=>]100%
Public key not found, could not verify signature
Downloading iptables_1.8.7.orig.tar.bz2 from ports.ubuntu.com (0.685 MiB)
[=>]100%
Downloading iptables_1.8.7-1ubuntu7.debian.tar.xz from ports.ubuntu.com (0.084 
MiB)
[=>]100%
root@m8360007:~# cd iptables-1.8.7/
root@m8360007:~/iptables-1.8.7# ll 
./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
-rw-r--r-- 1 root root 1682 Jun 26 08:59 
./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
root@m8360007:~/iptables-1.8.7# chmod +x 
./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
root@m8360007:~/iptables-1.8.7# cd iptables/tests/shell
root@m8360007:~/iptables-1.8.7/iptables/tests/shell# sudo ./run-tests.sh --host

I: [OK]  ././testcases/arptables/0001-arptables-save-restore_0
I: [OK]  ././testcases/arptables/0002-arptables-restore-defaults_0
I: [OK]  ././testcases/arptables/0003-arptables-verbose-output_0
I: [OK]  ././testcases/chain/0001duplicate_1
[...]
I: [OK]  ././testcases/nft-only/0007-mid-restore-flush_0
I: [OK]  ././testcases/nft-only/0008-basechain-policy_0
I: [OK]  ././testcases/nft-only/0009-needless-bitwise_0
I: nft results: [OK] 50 [FAILED] 0 [TOTAL] 50
I: combined results: [OK] 100 [FAILED] 0 [TOTAL] 100

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1974056

Title:
  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0 fails on s390x

Status in iptables:
  Unknown
Status in Ubuntu on IBM z Systems:
  In Progress
Status in iptables package in Ubuntu:
  New

Bug description:
  In Ubuntu, we execute the full iptables shell testcases across all
  architectures.

  They seem to all pass everywhere, however

  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0

  is currently failing on s390x like so:

  command17FAIL stderr: W: [FAILED]  ././testcases/nft-
  only/0009-needless-bitwise_0: expected 0 but got 1

  i wonder if there is some endian bug, as this is currently Ubuntu's
  only big-endian architecture.

  this can be reproduced with:

  pull-lp-source iptables
  cd iptables-1.8.7/
  chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
  cd iptables/tests/shell
  sudo ./run-tests.sh --host

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1974056/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From sthou...@in.ibm.com 2023-06-06 01:35 EDT---
(In reply to comment #6)
> Backtraces are on the upstream bug, eg:
>
> https://github.com/systemd/systemd/issues/25091#issuecomment-1401824195
> https://github.com/systemd/systemd/issues/25091#issuecomment-1402425787
>
> It would be better if the IBM developers could engage directly on the
> upstream ticket for the initial investigation, given the information is
> recorded there. Thanks!

Peter, Could you check this upstream bug and confirm if this needs to be
looked by tools chain team as claimed by Ubuntu distro team?

-- 
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 2017979] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From pp...@de.ibm.com 2023-05-11 10:35 EDT---
Is there any update on this? I have a request to update Ubuntu 20.04 to 22.04 
but currently it is not possible.

-- 
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 1992178] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From cha...@us.ibm.com 2023-02-14 17:28 EDT---
Howdy. Adding developers from KVM on Power and Toolchain to our bug but it 
would be good to understand exactly what IBM needs to look at. For example, you 
mention a backtrace you see but I don't see that in the bug. Any details you 
can provide are appreciated.

-- 
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 1992178] Re: autopkgtest: upstream tests that run in qemu hang on ppc64el

[bugproxy]

** Tags added: architecture-ppc64le bugnameltc-201628 severity-medium
targetmilestone-inin---

-- 
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 1997579] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From christian.r...@de.ibm.com 2022-11-28 12:42 EDT---
Thanks for having a look Frank and Steve.
I am all right with closing.

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From christian.r...@de.ibm.com 2022-11-24 12:16 EDT---
Hello Frank,

thanks for getting back to me on this. I did freshly install jammy jellyfish on 
a z/VM guest system.
I had updated the package definitions before I tried to install the 
systemd-coredump package (and attached my sources.list file)

Cross-checked the repository priority selections for 'coredump'
# apt-cache policy systemd-coredump
systemd-coredump:
Installed: (none)
Candidate: 249.11-0ubuntu3.6
Version table:
249.11-0ubuntu3.6 500
500 http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages
249.11-0ubuntu3 500
500 http://ports.ubuntu.com/ubuntu-ports jammy/universe s390x Packages

Next I followed the hint to clean up the package definitions. Updated all 
packages until I got 0 pacakges for any category:
# apt-get -y -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

# apt update
Hit:1 http://ports.ubuntu.com/ubuntu-ports jammy InRelease
Hit:2 http://ports.ubuntu.com/ubuntu-ports jammy-updates InRelease
Hit:3 http://ports.ubuntu.com/ubuntu-ports jammy-backports InRelease
Get:4 http://ports.ubuntu.com/ubuntu-ports jammy-security InRelease [110 kB]
Get:5 http://ports.ubuntu.com/ubuntu-ports jammy-security/main s390x Packages 
[273 kB]
Get:6 http://ports.ubuntu.com/ubuntu-ports jammy-security/main Translation-en 
[108 kB]
Get:7 http://ports.ubuntu.com/ubuntu-ports jammy-security/universe s390x 
Packages [398 kB]
Get:8 http://ports.ubuntu.com/ubuntu-ports jammy-security/universe 
Translation-en [80.9 kB]
Fetched 969 kB in 1s (1,924 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

After these operations the installation process for the systemd-coredump
package worked well, and the coredumpctl command was available. libssl3
(i.e. OpenSSL 3.0) remained to be the single available OpenSSL version.

-- 
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 system

[Touch-packages] [Bug 1982583] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-11-22 04:52 EDT---
As a comprehensive test plan I would suggest the following:

* Run zlib-ng testsuite against Ubuntu zlib. This is possible since
https://github.com/zlib-ng/zlib-
ng/commit/e63f36b1cf615a81e2cfa2d97fc54a5f493c9c19, the testsuite is
quite comprehensive.

* Run pyzlib testsuite - https://github.com/iii-i/pyzlib. It stresses
some DFLTCC-related corner cases, might be useful for CRC-32 as well.

* Do a large transfer with rsync -z. Copying locally is enough.

* Do a stress-ng run, e.g. stress-ng --zlib --timeout 60s.

This needs to be run 4 times:

- On a >=z15 machine.
- On a >=z15 machine with DFLTCC=0 environment variable.
- On a <=z14 machine (no DFLTCC).
- On a <=zEC12 machine (no vgfma at runtime).

-- 
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
Status in zlib source package in Jammy:
  Incomplete
Status in zlib source package in Kinetic:
  Incomplete

Bug description:
  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#1990379,
     so that only one package update is needed.
     However, LP#1990379 also affects Focal, but this bug only Jammy and 
Kinetic.

   * To fix LP#1990379 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.

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 1982583] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-10-10 19:01 EDT---
Thanks! With

https://ppa.launchpadcontent.net/fheimes/lp1990379+lp1982583/ubuntu
kinetic/main s390x zlib1g s390x 1:1.2.11.dfsg-4.1ubuntu2

the following command:

python3 -c 'import zlib; zlib.crc32(b"X"*50)'

begins to work ~2x faster.

-- 
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:
  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#1990379,
     so that only one package update is needed.
     However, LP#1990379 also affects Focal, but this bug only Jammy and 
Kinetic.

   * To fix LP#1990379 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.

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 1978129] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From manjunath.ma...@ibm.com 2022-09-29 10:33 EDT---
The issue was reproduced on Ubuntu 22.04

---uname output---
Linux 5.15.0-48-generic #54-Ubuntu SMP Fri Aug 26 13:27:34 UTC 2022 ppc64le 
ppc64le ppc64le GNU/Linux

?Steps to recreate ---
install the following packages
dpkg -i libbinutils_2.38-3ubuntu1_ppc64el.deb
dpkg -i binutils-common_2.38-3ubuntu1_ppc64el.deb
dpkg -i binutils-powerpc64le-linux-gnu_2.38-3ubuntu1_ppc64el.deb

Clone the glibc repository and build glibc.
git clone git://sourceware.org/git/glibc.git
git reset ?hard 2d5ec6692f5746ccb11db60976a6481ef8e9d74f
mkdir build && cd build
../glibc/configure ?prefix=$HOME/prefix && make -j8 && make check

---Error Message---
Generating locale C.UTF-8: this might take a while...
Segmentation fault
Charmap: "UTF-8" Inputfile: "C" Outputdir: "C.UTF-8" failed

---Fix---
The latest binutils package on Ubuntu 22.04 has the above mentioned fix 
included, so updating to the below mentioned packages resolved the issue.

binutils-powerpc64le-linux-gnu_2.38-4ubuntu2_ppc64el.deb
libbinutils_2.38-4ubuntu2_ppc64el.deb
binutils-common_2.38-4ubuntu2_ppc64el.deb

-- 
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 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]

   * 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] kinetic patch

[bugproxy]

--- Comment on attachment From i...@de.ibm.com 2022-09-27 20:08 EDT---


Here is the patch for kinetic. It's just an one liner.

** Attachment added: "kinetic patch"
   
https://bugs.launchpad.net/bugs/1990379/+attachment/5619612/+files/410-lp1990379.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/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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From ra...@ca.ibm.com 2022-09-23 13:07 EDT---
Hi, I am Eclipse OpenJ9 developer. This issue was exposed by Java Certification 
Kit running on RHEL 9 on z15+ and impacts all JDK versions (8,11,17, etc.) 
using system default settings.  The JCK failure impacts our ability to certify 
Java SDKs on this platform/distro.  Also, the incorrect alder32 result may 
cause functional issues to Java applications that depend on the result.

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

However, a chance would be to piggy-back a fix like this with a more
severe zlib update that might come up in future.

-- 
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

[bugproxy]

--- Comment From i...@de.ibm.com 2022-09-22 08:10 EDT---
zlib1g s390x 1:1.2.11.dfsg-2ubuntu1.4 passes all of my tests.

--- Comment From boris.m...@de.ibm.com 2022-09-22 08:18 EDT---
@Ilya: thanks a lot for your instant verification on focal!

With that, I am updating the tags / keywords to: verification-done,
verification-done-focal, verification-done-jammy

** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-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.

[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15

[bugproxy]

** Tags removed: verification-done verification-done-focal
** Tags added: verification-needed verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/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/41

[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15

[bugproxy]

** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-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 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/41

[Touch-packages] [Bug 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16

[bugproxy]

** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2204

-- 
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 1974115] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From andreas.kreb...@de.ibm.com 2022-09-13 10:40 EDT---
I've installed binutils 2.38-4ubuntu2 on jammy. With that the -march=z16 option 
is accepted by 'as'. So looks good to me.

No idea about the regressions mentioned above. I don't see how an IBM
zSystems only patch can affect builds on arm and amd64.

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-09-05 11:31 EDT---
zlib1g-dev s390x 1:1.2.11.dfsg-2ubuntu9.1 and zlib1g s390x 
1:1.2.11.dfsg-2ubuntu9.1 pass all of my tests.

-- 
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
     the DFLTCC pull request:
   

[Touch-packages] [Bug 1974115] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2022-09-01 04:48 EDT---
@Canonical: Hi Brian,
the test / verification on our side will be delayed as our SME is out on 
vacation.
We should have an answer by the end of next week.
Thanks

-- 
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] Comment bridged from LTC Bugzilla

[bugproxy]

(While looking into libbio-samtools-perl and other related packages, I
found that there is yet another htslib bundled in tabix - which is not
great. But this at at least already the needed 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/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 Committed
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
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:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  New

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:
     

[Touch-packages] [Bug 1437375] Re: [udev] Adding "Austin" adapter to Ubuntu partition take over system network interface

[bugproxy]

--- Comment From cdead...@us.ibm.com 2022-07-23 09:55 EDT---
Re-open to move to diff. component.

#=#=# 2015-04-23 10:27:57 (CDT) #=#=#
New Fix_Potential = [GSI_HDW]
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#

Any updates on this issue? Thanks!

Some "sync" issue between CQ and bugzilla.

Please see the bugzilla: https://bugzilla.linux.ibm.com/show_bug.cgi?id=122308
The approval '*** STG AUTO-GENERATED *** Verify Fix' has been removed because 
the following condition was met: perform the action Close

** Bug watch added: bugzilla.linux.ibm.com/ #122308
   https://bugzilla.linux.ibm.com/show_bug.cgi?id=122308

-- 
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/1437375

Title:
  [udev] Adding "Austin" adapter to Ubuntu partition take over system
  network interface

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Released
Status in systemd source package in Vivid:
  Fix Released
Status in systemd source package in Wily:
  Fix Released

Bug description:
  [Impact]
  This impacts any user of LPARs; upon adding physical network interfaces (or, 
realistically, any network interface at all, even virtual), the network 
interface which is used for system access and used to install the system may 
not appear in the same order after reboot.

  [Test Case]
  Requires access to logical partitions.
  1) Install system
  2) Add an physical network adapter to the partition
  3) Reboot.

  Observed behavior:
  After reboot, the virtual adapter expected to be used is unavailable, the 
address is assigned to any other network adapter which may have been detected 
and used persistent addresses.

  Expected behavior
  The system should come up with network interfaces in the same order as before 
rebooting.

  [Regression Potential]
  Added virtual interfaces that should be not persist (because they are locally 
administered and thus may have their MAC address change) may come up as 
persistent devices due to the use of the ibmveth driver, and thus fail to work 
as expected.

  ---

  Problem Description:
  

  Adding Austin adapter to Ubuntu partition took over system network
  interface.  This caused system to be off network connection.

   ver 1.5.4.3 - OS, HTX, Firmware and Machine details

     OS: GNU/Linux
     OS Version: Ubuntu Vivid Vervet (development branch) \n \l
     Kernel Version: 3.18.0-13-generic
    HTX Version: htxubuntu-322
  Host Name: br14p08
  Machine Serial No: IBM,0210800E7
     Machine Type/Model: IBM,9119-MHE
    System FW Level: FW830.00 (SC830_021)

  BEFORE adding Austin adapter to br14p08:
  

  Before adding austin adapter to br14p05 (vio client), the system
  network is good.

  ubuntu@br14p08:~$ lsslot -cpci
  ubuntu@br14p08:~$

  + eth0 U9119.MHE.10800E7-V8-C2-T1
   Interpartition Logical LAN

  root@br14p08:~# lscfg |grep eth
  + eth0 U9119.MHE.10800E7-V8-C2-T1

  root@br14p08:~# ifconfig
  eth0  Link encap:Ethernet  HWaddr 16:59:c0:50:0a:02
    inet addr:9.3.21.12  Bcast:9.3.21.255  Mask:255.255.254.0
    inet6 addr: fe80::1459:c0ff:fe50:a02/64 Scope:Link
    inet6 addr: 2002:903:15f:290:1459:c0ff:fe50:a02/64 Scope:Global
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:37366 errors:0 dropped:16 overruns:0 frame:0
    TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:2472739 (2.4 MB)  TX bytes:22596 (22.5 KB)
    Interrupt:19

  loLink encap:Local Loopback
    inet addr:127.0.0.1  Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING  MTU:65536  Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

  root@br14p08:~# ping br14p08
  PING br14p08.aus.stglabs.ibm.com (9.3.21.12) 56(84) bytes of data.
  64 bytes from br14p08.aus.stglabs.ibm.com (9.3.21.12): icmp_seq=1 ttl=64 
time=0.008 ms
  64 bytes from br14p08.aus.stglabs.ibm.com (9.3.21.12): icmp_seq=2 ttl=64 
time=0.004 ms
  64 bytes from br14p08.aus.stglabs.ibm.com (9.3.21.12): icmp_seq=3 ttl=64 
time=0.005 ms
  ^C
  --- br14p08.aus.stglabs.ibm.com ping statistics ---
  3 packets transmitted, 3 received, 0% packet loss, time 1998ms
  rtt min/avg/max/mdev = 0.004/0.005/0.008/0.003 ms

  root@br14p08:~# ping nimitz
  PING nimitz.aus.stglabs.ibm.com (9.3.165.31) 56(84) bytes of data.
  64 bytes from nimitz.aus.stglabs.ibm.com (9.3.165.31): icmp_seq=1 ttl=254 
time

[Touch-packages] [Bug 1982583] Re: zlib CRC32 optimization for s390x works only in a static library

[bugproxy]

** Tags added: architecture-s39064 bugnameltc-199129 severity-high
targetmilestone-inin---

-- 
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:
  zlib CRC32 optimization for s390x works only in a static library

Status in zlib package in Ubuntu:
  New

Bug description:
  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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2022-07-21 05:51 EDT---
Comment on attachment 153124
zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8 (jammy)

this is obsolete - has been replaced by newer version

--- Comment From boris.m...@de.ibm.com 2022-07-21 05:52 EDT---
Comment on attachment 154585
reverse dependencies, gathered on focal.txt

obsolete - has been removed

-- 
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:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  In Progress
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
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:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  New

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

[Touch-packages] [Bug 1961427] zlib debdiffs for jammy and kinetic (latest)

[bugproxy]

Default Comment by Bridge

** Attachment added: "zlib debdiffs for jammy and kinetic (latest)"
   
https://bugs.launchpad.net/bugs/1961427/+attachment/5604516/+files/debdiffs_J_K.tar.gz

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/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:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  In Progress
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
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:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  New

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/mad

[Touch-packages] [Bug 1961427] Comment bridged from LTC Bugzilla

[bugproxy]

Since the zlib package progressed meanwhile due to a security update, I
created new debdiffs for jammy and kinetic - see debdiffs_J_K.tar.gz.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/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:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  In Progress
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
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:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  New

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 commi

[Touch-packages] [Bug 1961427] reverse dependencies, gathered on focal.txt

[bugproxy]

Default Comment by Bridge

** Attachment added: "reverse dependencies, gathered on focal.txt"
   
https://bugs.launchpad.net/bugs/1961427/+attachment/5604505/+files/reverse_dependencies%2C_gathered_on_focal.txt

-- 
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:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  In Progress
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
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:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  New

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:
  

[Touch-packages] [Bug 1961427] Comment bridged from LTC Bugzilla

[bugproxy]

Due to the fact that now in total 3 packages are involved and two libraries 
(zlib and htslib, well and the libraries included in bedtools), this will cause 
a bigger transition (especially for htslib in focal, and zlib itself on all 
affected Ubuntu releases).
(The transition(s) need to be planned here: 
https://people.canonical.com/~ubuntu-archive/transitions/index.html)

-- 
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:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  In Progress
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
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:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  New

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().

[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15

[bugproxy]

** Tags removed: targetmilestone-inin2110
** Tags added: targetmilestone-inin20045

-- 
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:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  In Progress
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
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:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  New

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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reprodu

[Touch-packages] [Bug 1959469] Comment bridged from LTC Bugzilla

[bugproxy]

An updated test package was created for kinetic and build with the help of this 
PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1959469
for the major architectures.

This incl. building and executing the testsuite too, which results in all tests 
passed:
...

All 112 tests passed

...
PASS: rsa-sign
PASS: rsa-verify
PASS: rsa-encrypt
==
All 3 tests passed
==

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nettle in Ubuntu.
https://bugs.launchpad.net/bugs/1959469

Title:
  [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

Status in Ubuntu on IBM z Systems:
  New
Status in nettle package in Ubuntu:
  New

Bug description:
  Upgrade nettle to latest version >= 3.7.4 (crypto)

  Description

  Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for
  Crypto Libraries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From mario.h...@de.ibm.com 2022-07-07 07:55 EDT---
(In reply to comment #13)
> We just realized that we had DFLTCC support in 20.04, so we need to put this
> fix there as well.

So this still gets fixed in Focal (20.04).

-- 
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:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  In Progress
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
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:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  New

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 DFLTC

[Touch-packages] [Bug 1961427] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-06-15 14:00 EDT---
I don't really remember, so I retested.

20.04: 1.2.11.dfsg-2ubuntu1.3 fixes the problem (I had to install the .deb file 
manually with dpkg).
22.04: 1.2.11.dfsg-2ubuntu9.1 fixes the problem.

-- 
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:
  Incomplete
Status in bedtools package in Ubuntu:
  New
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  Incomplete
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  New
Status in zlib source package in Focal:
  New
Status in bedtools source package in Impish:
  New
Status in htslib source package in Impish:
  Invalid
Status in zlib source package in Impish:
  New
Status in bedtools source package in Jammy:
  New
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  Incomplete

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
     th

[Touch-packages] [Bug 1977493] sources.list file

[bugproxy]

--- Comment (attachment only) From pp...@de.ibm.com 2022-06-03 08:34 
EDT---


** Attachment added: "sources.list file"
   
https://bugs.launchpad.net/bugs/1977493/+attachment/5594615/+files/sources.list

-- 
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/1977493

Title:
  Upgrade from Ubuntu 21.10 to 22.04 fails - unmet dependencies: libpam-
  modules

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in pam package in Ubuntu:
  Incomplete

Bug description:
  ---Problem Description---
  Upgrade from Ubuntu 21.10 to 22.4 fails

  I run do-release-upgrade and I got a message upgrade completed with
  errors. I rebooted the server and it is now in an undefined state
  between 21.10 and 22.04. Not all packages have been installed. I
  attach apt log and output of some commands:

  root@tuxmaker:~# cat /etc/os-release 
  PRETTY_NAME="Ubuntu 21.10"
  NAME="Ubuntu"
  VERSION_ID="21.10"
  VERSION="21.10 (Impish Indri)"
  VERSION_CODENAME=impish
  ID=ubuntu
  ID_LIKE=debian
  HOME_URL="https://www.ubuntu.com/";
  SUPPORT_URL="https://help.ubuntu.com/";
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/";
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
  UBUNTU_CODENAME=impish

  root@tuxmaker:~# do-release-upgrade 
  Checking for a new Ubuntu release
  Please install all available updates for your release before upgrading.

  root@tuxmaker:~# apt dist-upgrade
  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:
   libpam-modules : PreDepends: libpam-modules-bin (= 1.3.1-5ubuntu11) but 
1.4.0-11ubuntu2 is installed
Recommends: update-motd but it is not installed
  E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).

  root@tuxmaker:~# apt --fix-broken install
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Correcting dependencies... Done
  The following additional packages will be installed:
libpam-modules
  The following packages will be upgraded:
libpam-modules
  1 upgraded, 0 newly installed, 0 to remove and 1208 not upgraded.
  4 not fully installed or removed.
  Need to get 0 B/279 kB of archives.
  After this operation, 1,024 B disk space will be freed.
  Do you want to continue? [Y/n] y
  Preconfiguring packages ...
  (Reading database ... 401827 files and directories currently installed.)
  Preparing to unpack .../libpam-modules_1.4.0-11ubuntu2_s390x.deb ...
  dpkg: error processing archive 
/var/cache/apt/archives/libpam-modules_1.4.0-11ubuntu2_s390x.deb (--unpack):
   new libpam-modules:s390x package pre-installation script subprocess returned 
error exit status 2
  Errors were encountered while processing:
   /var/cache/apt/archives/libpam-modules_1.4.0-11ubuntu2_s390x.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)


  Contact Information = pp...@de.ibm.com 
   
  ---uname output---
  Linux tuxmaker 5.13.0-44-generic #49-Ubuntu SMP Wed May 18 13:30:03 UTC 2022 
s390x s390x s390x GNU/Linux
   
  Machine Type = z15, 8561-701 
   
  ---boot type---
  upgade
   
  ---Kernel cmdline used to launch install---
  do-release-upgrade
   
  ---Install repository type---
  Internet repository
   
  ---Install repository Location---
  http://ports.ubuntu.com:80/
   
  ---Point of failure---
  Other failure during installation (stage 1)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1977493/+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 1977493] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From pp...@de.ibm.com 2022-06-03 08:33 EDT---
I have already run the command do-release-upgrade. At the end of the upgrade I 
could see "upgrade completed" but there were errors. Than I rebooted the system.

I attach the sources.list file an the output of the commands.

root@tuxmaker:~# apt-cache policy libpam-modules
libpam-modules:
Installed: 1.3.1-5ubuntu11
Candidate: 1.4.0-11ubuntu2
Version table:
1.4.0-11ubuntu2 500
500 http://ports.ubuntu.com:80 jammy/main s390x Packages
*** 1.3.1-5ubuntu11 100
100 /var/lib/dpkg/status

root@tuxmaker:~# sudo apt update
Hit:1 http://ports.ubuntu.com:80 jammy InRelease
Get:2 http://ports.ubuntu.com:80 jammy-updates InRelease [109 kB]
Get:3 http://ports.ubuntu.com:80 jammy-backports InRelease [99.8 kB]
Get:4 http://ports.ubuntu.com/ubuntu-ports jammy-security InRelease [110 kB]
Get:5 http://ports.ubuntu.com:80 jammy-updates/main s390x Packages [170 kB]
Get:6 http://ports.ubuntu.com:80 jammy-updates/main Translation-en [59.5 kB]
Get:7 http://ports.ubuntu.com:80 jammy-updates s390x Contents (deb) [3,398 kB]
Get:8 http://ports.ubuntu.com:80 jammy-updates/main s390x c-n-f Metadata [3,904 
B]
Get:9 http://ports.ubuntu.com:80 jammy-updates/restricted s390x Packages [3,024 
B]
Get:10 http://ports.ubuntu.com:80 jammy-updates/restricted Translation-en [21.4 
kB]
Get:11 http://ports.ubuntu.com:80 jammy-updates/universe s390x Packages [68.4 
kB]
Get:12 http://ports.ubuntu.com:80 jammy-backports s390x Contents (deb) [12.6 kB]
Get:13 http://ports.ubuntu.com/ubuntu-ports jammy-security/main s390x Packages 
[77.2 kB]
Get:14 http://ports.ubuntu.com/ubuntu-ports jammy-security/main Translation-en 
[34.0 kB]
Get:15 http://ports.ubuntu.com/ubuntu-ports jammy-security s390x Contents (deb) 
[2,164 kB]
Get:16 http://ports.ubuntu.com/ubuntu-ports jammy-security/main s390x c-n-f 
Metadata [2,132 B]
Fetched 6,334 kB in 1s (5,198 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
1209 packages can be upgraded. Run 'apt list --upgradable' to see them.

root@tuxmaker:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 21.10
Release:21.10
Codename:   impish

There are over 2000 Packages on the system:
root@tuxmaker:~# dpkg-query -l | wc -l
2061

-- 
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/1977493

Title:
  Upgrade from Ubuntu 21.10 to 22.04 fails - unmet dependencies: libpam-
  modules

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in pam package in Ubuntu:
  Incomplete

Bug description:
  ---Problem Description---
  Upgrade from Ubuntu 21.10 to 22.4 fails

  I run do-release-upgrade and I got a message upgrade completed with
  errors. I rebooted the server and it is now in an undefined state
  between 21.10 and 22.04. Not all packages have been installed. I
  attach apt log and output of some commands:

  root@tuxmaker:~# cat /etc/os-release 
  PRETTY_NAME="Ubuntu 21.10"
  NAME="Ubuntu"
  VERSION_ID="21.10"
  VERSION="21.10 (Impish Indri)"
  VERSION_CODENAME=impish
  ID=ubuntu
  ID_LIKE=debian
  HOME_URL="https://www.ubuntu.com/";
  SUPPORT_URL="https://help.ubuntu.com/";
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/";
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
  UBUNTU_CODENAME=impish

  root@tuxmaker:~# do-release-upgrade 
  Checking for a new Ubuntu release
  Please install all available updates for your release before upgrading.

  root@tuxmaker:~# apt dist-upgrade
  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:
   libpam-modules : PreDepends: libpam-modules-bin (= 1.3.1-5ubuntu11) but 
1.4.0-11ubuntu2 is installed
Recommends: update-motd but it is not installed
  E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).

  root@tuxmaker:~# apt --fix-broken install
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Correcting dependencies... Done
  The following additional packages will be installed:
libpam-modules
  The following packages will be upgraded:
libpam-modules
  1 upgraded, 0 newly installed, 0 to remove and 1208 not upgraded.
  4 not fully installed or removed.
  Need to get 0 B/279 kB of archives.
  After this operation, 1,024 B disk space will be freed.
  Do you want to continue? [Y/n] y
  Preconfiguring packages ...
  (Reading database ... 401827 files and directories currently installed.)
  Preparing to unpack .../libpam-modules_1.4.0-11ubuntu2_s390x.deb ...
  dpkg: error processing archive 
/var/cache/apt/archives/libpam-modules_1.4.0-11ubuntu2_s390x.deb (--unpack):
   new libpam-mo

[Touch-packages] [Bug 1974056] Re: iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-bitwise_0 fails on s390x

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2022-05-25 04:39 EDT---
Description by Canonical (LP#1974056):

command17 FAIL stderr: W: [FAILED] ././testcases/nft-only/0009-needless-
bitwise_0: expected 0 but got 1

this can be reproduced with:

pull-lp-source iptables
cd iptables-1.8.7/
chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
cd iptables/tests/shell
sudo ./run-tests.sh --host

** Tags added: architecture-s39064 bugnameltc-198367 severity-high
targetmilestone-inin2204

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1974056

Title:
  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0 fails on s390x

Status in iptables:
  Unknown
Status in Ubuntu on IBM z Systems:
  New
Status in iptables package in Ubuntu:
  New

Bug description:
  In Ubuntu, we execute the full iptables shell testcases across all
  architectures.

  They seem to all pass everywhere, however

  iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-
  bitwise_0

  is currently failing on s390x like so:

  command17FAIL stderr: W: [FAILED]  ././testcases/nft-
  only/0009-needless-bitwise_0: expected 0 but got 1

  i wonder if there is some endian bug, as this is currently Ubuntu's
  only big-endian architecture.

  this can be reproduced with:

  pull-lp-source iptables
  cd iptables-1.8.7/
  chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0
  cd iptables/tests/shell
  sudo ./run-tests.sh --host

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1974056/+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 1959408] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2022-05-18 23:07 EDT---
Fix released, hence closing the bug.
Status: -> CLOSED

-- 
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/1959408

Title:
  [22.04 FEAT] BINUTILS: Support for new IBM Z Hardware

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in binutils package in Ubuntu:
  Fix Released

Bug description:
  BINUTILS: Support for new IBM Z Hardware

  Upstream target: binutils = 2.37

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959408/+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 1959407] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2022-05-18 23:17 EDT---
fix verified and released, hence closing the bug.
Staus: => CLOSED.

-- 
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/1959407

Title:
  [22.04 FEAT] BINUTILS: Support for new IBM Z Hardware - GDB Part

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in binutils package in Ubuntu:
  Fix Released
Status in gdb package in Ubuntu:
  Fix Released

Bug description:
  BINUTILS: Support for new IBM Z Hardware

  This request will track the inclusion of the patches for this feature
  in GDB to provide the GDB disassembler support for the new
  instructions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959407/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-05-16 06:17 EDT---
With the new combination, bedtools testsuite is green and zlib passes all of my 
tests too. So it looks good, thanks!

-- 
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:
  Incomplete
Status in bedtools package in Ubuntu:
  New
Status in zlib package in Ubuntu:
  Incomplete
Status in bedtools source package in Focal:
  New
Status in zlib source package in Focal:
  New
Status in bedtools source package in Impish:
  New
Status in zlib source package in Impish:
  New
Status in bedtools source package in Jammy:
  New
Status in zlib source package in Jammy:
  Incomplete

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

  [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.
  __

  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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reproduction:  z15 only:
     #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);
     }

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1961427/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-05-10 07:14 EDT---
Hi, thanks for looking into this. I'll wait until 
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427 finishes the build and 
try it.

In the meantime I've asked the bedtools upstream to cherry-pick the
htslib commit: https://github.com/arq5x/bedtools2/pull/993.

-- 
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:
  Incomplete
Status in bedtools package in Ubuntu:
  New
Status in zlib package in Ubuntu:
  Incomplete
Status in bedtools source package in Focal:
  New
Status in zlib source package in Focal:
  New
Status in bedtools source package in Impish:
  New
Status in zlib source package in Impish:
  New
Status in bedtools source package in Jammy:
  New
Status in zlib source package in Jammy:
  Incomplete

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

  [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.
  __

  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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reproduction:  z15 only:
     #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);
     }

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch

[Touch-packages] [Bug 1961427] Comment bridged from LTC Bugzilla

[bugproxy]

Well, that bundled htslib seems to make the situation a bit messy,
So my guess is that this should be fixed in bedtools upstream first...

-- 
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:
  Incomplete
Status in bedtools package in Ubuntu:
  New
Status in zlib package in Ubuntu:
  Incomplete
Status in bedtools source package in Focal:
  New
Status in zlib source package in Focal:
  New
Status in bedtools source package in Impish:
  New
Status in zlib source package in Impish:
  New
Status in bedtools source package in Jammy:
  New
Status in zlib source package in Jammy:
  Incomplete

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

  [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.
  __

  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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reproduction:  z15 only:
     #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);
     }

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1961427/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-05-06 06:22 EDT---
Here are the originally reported failures:

> But I found in "bedtools":
> bedtools: bgzf.c:351: bgzf_hopen: Assertion
> `compressBound(BGZF_BLOCK_SIZE) < BGZF_MAX_BLOCK_SIZE' failed. test-
> intersect.sh: line 201:  1981 Aborted (core dumped)
> $htsutil samtobam one_block.sam one_block.bam
>
> or in libbio:
> perl: bgzf.c:142: bgzf_open: Assertion
> `compressBound(BGZF_BLOCK_SIZE) < BGZF_MAX_BLOCK_SIZE' failed.Failed
> 268/268 subtests

I just double-checked, and apparently bedtools bundles htslib (under
src/utils/htslib). I didn't check libbio, but most likely it does this
as well. So the patch must be cherry-picked into all of the bundled
copies.

-- 
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:
  Incomplete
Status in zlib package in Ubuntu:
  Incomplete
Status in zlib source package in Focal:
  New
Status in zlib source package in Impish:
  New
Status in zlib source package in Jammy:
  Incomplete

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

  [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.
  __

  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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reproduction:  z15 only:
     #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);
     }

To manage notifications about this bug go to:
https://bug

[Touch-packages] [Bug 1961427] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-05-04 08:51 EDT---
Good that this was pinged - it seems that we hit a deadlock here :-)

I was waiting on Ubuntu to bump the HTSlib version (or cherry-pick
https://github.com/samtools/htslib/pull/1258), where the incompatibility
issue is resolved. The original zlib patch should then just work.

-- 
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:
  Incomplete
Status in zlib package in Ubuntu:
  Incomplete
Status in zlib source package in Focal:
  New
Status in zlib source package in Impish:
  New
Status in zlib source package in Jammy:
  Incomplete

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

  [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.
  __

  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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reproduction:  z15 only:
     #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);
     }

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1961427/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From mario.h...@de.ibm.com 2022-05-04 05:20 EDT---
It seems there is no progress with this issue for a while. What is next? Is the 
reason for the incompatibility found meanwhile?

-- 
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:
  Incomplete
Status in zlib package in Ubuntu:
  Incomplete
Status in zlib source package in Focal:
  New
Status in zlib source package in Impish:
  New
Status in zlib source package in Jammy:
  Incomplete

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

  [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.
  __

  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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reproduction:  z15 only:
     #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);
     }

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1961427/+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 1959408] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From andreas.kreb...@de.ibm.com 2022-04-07 02:38 EDT---
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)
Author: Andreas Krebbel 
Date:   Thu Apr 7 07:45:49 2022 +0200

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)

-- 
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/1959408

Title:
  [22.04 FEAT] BINUTILS: Support for new IBM Z Hardware

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in binutils package in Ubuntu:
  Fix Released

Bug description:
  BINUTILS: Support for new IBM Z Hardware

  Upstream target: binutils = 2.37

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959408/+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] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-03-15 18:41 EDT---
zlib1g s390x 1:1.2.11.dfsg-2ubuntu1.3 passes all of my tests on focal, thanks!

-- 
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:
  New
Status in zlib package in Ubuntu:
  In Progress
Status in zlib source package in Focal:
  New
Status in zlib source package in Impish:
  New
Status in zlib source package in Jammy:
  In Progress

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

  [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.
  __

  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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reproduction:  z15 only:
     #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);
     }

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1961427/+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] debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8

[bugproxy]

Default Comment by Bridge

** Attachment added: 
"debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8"
   
https://bugs.launchpad.net/bugs/1961427/+attachment/5569373/+files/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_impish.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/1961427

Title:
  zlib: compressBound() returns an incorrect result on z15

Status in Ubuntu on IBM z Systems:
  New
Status in zlib package in Ubuntu:
  In Progress
Status in zlib source package in Focal:
  New
Status in zlib source package in Impish:
  New
Status in zlib source package in Jammy:
  In Progress

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

  [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.
  __

  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 b25781e735363e04f6c56e21431c47e4afc50b17.

  Reproduction:  z15 only:
     #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);
     }

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1961427/+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 1951470] Re: webkit javascript segmentation fault

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2021-12-01 10:03 EDT---
The bug was fixed in Focal, Impish and Hirsute. Thanks for everybody 
contributing to fix and verify.
IBM Bugzilla status change: -> CLOSED

** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin2004

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtwebkit-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1951470

Title:
  webkit javascript segmentation fault

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in qtwebkit-opensource-src package in Ubuntu:
  Fix Released
Status in qtwebkit-opensource-src source package in Focal:
  Fix Committed
Status in qtwebkit-opensource-src source package in Hirsute:
  Fix Committed
Status in qtwebkit-opensource-src source package in Impish:
  Fix Committed
Status in qtwebkit-opensource-src source package in Jammy:
  Fix Released

Bug description:
  SRU Justification:

  [Impact]

   * WebKit Javascript engine is causing a segmentation fault on big
  endian (s390x) systems.

   * This happens for example when transferring an html to a pdf file
  using wkhtmltopdf.

   * The fix is relatively simple with changing loadisFromInstruction to 
loadpFromInstruction
 in macro getProperty(slow), which solves this unpleasant situation.

   * The JIT ocde is 32bit (even on 64bit systems),
 hence is crucial to make sure the lower part of a 64bit value is taken on 
big endian systems.

  [Test Plan]

   * Testing is very straight forward by following these steps:

   * install the following packages (incl. their dependencies):
 $ sudo apt install libqt5webkit5 wkhtmltopdf

   * create an html file like this:
 $ vi index.html
 $ cat index.html
 
 
   
   
 
   
 
   
 

   * create a JavaScript file like this:
 $ vi min.js
 $ cat min.js
 var i = Math.max

   * call wkhtmltopdf to process the local files:
 $ wkhtmltopdf --enable-local-file-access index.html test.pdf

   * if it's broken one gets this output:
 Loading page (1/2)
 Segmentation fault (core dumped) ] 50%
 and no pdf file was generated:
 $ ls *.pdf
 ls: cannot access '*.pdf': No such file or directory

   * in case it's fixed one gets this output:
 Loading page (1/2)
 Printing pages (2/2)   
 Done   
 and a pdf file was generated and in placed in the current directory (with 
more than 0 bytes size):
 $ ls -l ./*.pdf
 -rw-rw-r-- 1 ubuntu ubuntu 1339 Nov 24 11:48 ./test.pdf

  [Where problems could occur]

   * While this issue only affects big endian systems (like s390x),
 a bad fix may have an impact on little endian systems, too
 for example in case the wrong function got used in the macro.

   * But loadpFromInstruction is known to work for LE and BE systems;

   * and on top cross-architecture builds were done:
 https://launchpad.net/~fheimes/+archive/ubuntu/lp1951470

   * and tested on s390x (if the fix works) and on non-s390x (regression
  testing).

   * The changes are otherwise very limited, just:
 macro getProperty(slow)
 -loadisFromInstruction(6, t1)
 +loadpFromInstruction(6, t1)
 hence I think there is not much more to say.

  [Other Info]
   
   * The maintainer of the Debian packages (Dmitry Shachnev)
 is going to add this to the Debian package, too.

   * This issue affects Ubuntu jammy, impish, hirsute and focal - SRUs
  are ongoing.

   * The issue does not occur with the very latest upstream version anymore,
 and was fixed in a similar way as part of a commit
 that fixes numerous other CLoop issues on top:
 "Fix all CLoop JSC test failures (including some LLInt bugs due to recent 
bytecode format change)."
 commit 3fdde71c7d95d758a61fcbc4c58168616794c102

  __

  == Comment: #0 - Andreas Krebbel  - 2021-11-15 
09:29:44 ==
  ---Problem Description---
  Segmentation fault from WebKit Javascript engine

  Contact Information = andreas.kreb...@de.ibm.com

  ---uname output---
  Linux 193438490afd 5.8.15-301.fc33.s390x #1 SMP Thu Oct 15 15:55:57 UTC 2020 
s390x s390x s390x GNU/Linux

  Machine Type = IBM Z

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   index.html:
  
  
    
    

    
  
    
  

  min.js:
  var i = Math.max

  wkhtmltopdf index.html test.pdf
  QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
  Loading page (1/2)
  Segmentation fault (core dumped) ] 17%

  Userspace tool common name: wkhtmltopdf

  The userspace tool has the following bit modes: 64

  Userspace rpm: libqt5webkit5

  Userspace tool obtained from project website:  na

  *Additional Instructions for andreas.kreb...@de.ibm.com:
  -Attach ltrace and stra

[Touch-packages] [Bug 1951470] Re: webkit javascript segmentation fault

[bugproxy]

--- Comment From andreas.kreb...@de.ibm.com 2021-11-22 02:30 EDT---
(In reply to comment #10)
> This does not look like an Ubuntu system. Linux kernel has wrong version:
> "Linux 193438490afd 5.8.15-301.fc33.s390x". Are you sure you are testing it
> on Ubuntu image?

I just mechanically copied the uname -a output there forgetting that I
was working in a container. Hence the output is bogus, please ignore.
But as mentioned already the issue is not kernel related anyway.

--- Comment From andreas.kreb...@de.ibm.com 2021-11-22 02:37 EDT---
(In reply to comment #13)
...
> @Andreas Is your proposed fix known to be save for other platform (LE), too?

Yes, the fix should be safe for LE platforms as well. Before that change
it just accidentally worked on LE. But this would need to be tested of
course.

> And can you point me to the upstream issue where this got fixed?

It looks like it got fixed as part of a commit which fixes numerous
other CLoop issues:

commit 3fdde71c7d95d758a61fcbc4c58168616794c102
Author: Mark Lam 
Date:   Mon Jan 14 21:34:47 2019 +

Fix all CLoop JSC test failures (including some LLInt bugs due to recent 
bytecode format change).
https://bugs.webkit.org/show_bug.cgi?id=193402

Reviewed by Keith Miller.

There you can find a similar change as in my proposed patch. However, it
is based on a commit which changed how these data are stored. So it
might not be obvious to backport it. On the other hand it looks like it
contains more fixes which we might want to have as well.

llintOpWithMetadata(op_get_from_scope, OpGetFromScope, macro (size, get, 
dispatch, metadata, return)
macro getProperty()
-loadis OpGetFromScope::Metadata::operand[t5], t3
+loadp OpGetFromScope::Metadata::operand[t5], t3
loadPropertyAtVariableOffset(t3, t0, t1, t2)
valueProfile(OpGetFromScope, t5, t1, t2)
return(t1, t2)

** Bug watch added: bugs.webkit.org/ #193402
   https://bugs.webkit.org/show_bug.cgi?id=193402

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtwebkit-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1951470

Title:
  webkit javascript segmentation fault

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in qtwebkit-opensource-src package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - Andreas Krebbel  - 2021-11-15 
09:29:44 ==
  ---Problem Description---
  Segmentation fault from WebKit Javascript engine
   
  Contact Information = andreas.kreb...@de.ibm.com 
   
  ---uname output---
  Linux 193438490afd 5.8.15-301.fc33.s390x #1 SMP Thu Oct 15 15:55:57 UTC 2020 
s390x s390x s390x GNU/Linux
   
  Machine Type = IBM Z 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   index.html:
  
  




  

  

  min.js:
  var i = Math.max

  wkhtmltopdf index.html test.pdf
  QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
  Loading page (1/2)
  Segmentation fault (core dumped) ] 17%
   
  Userspace tool common name: wkhtmltopdf 
   
  The userspace tool has the following bit modes: 64 

  Userspace rpm: libqt5webkit5

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for andreas.kreb...@de.ibm.com:
  -Attach ltrace and strace of userspace application.

  == Comment: #1 - Andreas Krebbel  - 2021-11-15 
09:44:04 ==
  In CodeBlock.cpp the code preparing the operands of op_get_from_scope writes 
the property offset as pointer size (hence 64 bit) value:

  2141: instructions[i + 6].u.pointer =
  reinterpret_cast(op.operand);

  while the same slot is accessed later by the jitted code as 32 bit
  integer:

  macro getProperty(slow)
  loadisFromInstruction(6, t1)

  This fails on big endian targets since the integer access takes the
  higher part of the 64 bit value.

  Changing:

  macro getProperty(slow)
  loadisFromInstruction(6, t1)

  to

  macro getProperty(slow)
  loadpFromInstruction(6, t1)

  in llint/LowLevelInterpreter64.asm fixes the problem for me.

  
  I could not reproduce the problem on Ubuntu 20.10. In upstream webkit the 
problem got fixed as a side effect of a larger change but in the end quite 
similar to the change I'm proposing. The value resides somewhere else now but 
it is accessed as 64 bit value in getProperty:

  macro getProperty()
  loadp OpGetFromScope::Metadata::m_operand[t5], t1


  If you have the jsc binary from the webkit package available the
  problem can be reproduced with just 'jsc -e "i=Math.min"'

  == Comment: #2 - Andreas Krebbel  -
  2021-11-15 09:49:55 ==

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1951470/+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 1951470] Comment bridged from LTC Bugzilla

[bugproxy]

The steps are fine and do not cause a seg. fault on jammy/22.04, impish/21.10 
or hirsute/21.04.
But as already assumed it seg. faults on focal/20.04.

(This is not kernel related, a wrong package  was
marked as affected, but if it would have been kernel related, we would
have asked to reproduce on focal's 5.4 latest.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtwebkit-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1951470

Title:
  webkit javascript segmentation fault

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in qtwebkit-opensource-src package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - Andreas Krebbel  - 2021-11-15 
09:29:44 ==
  ---Problem Description---
  Segmentation fault from WebKit Javascript engine
   
  Contact Information = andreas.kreb...@de.ibm.com 
   
  ---uname output---
  Linux 193438490afd 5.8.15-301.fc33.s390x #1 SMP Thu Oct 15 15:55:57 UTC 2020 
s390x s390x s390x GNU/Linux
   
  Machine Type = IBM Z 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   index.html:
  
  




  

  

  min.js:
  var i = Math.max

  wkhtmltopdf index.html test.pdf
  QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
  Loading page (1/2)
  Segmentation fault (core dumped) ] 17%
   
  Userspace tool common name: wkhtmltopdf 
   
  The userspace tool has the following bit modes: 64 

  Userspace rpm: libqt5webkit5

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for andreas.kreb...@de.ibm.com:
  -Attach ltrace and strace of userspace application.

  == Comment: #1 - Andreas Krebbel  - 2021-11-15 
09:44:04 ==
  In CodeBlock.cpp the code preparing the operands of op_get_from_scope writes 
the property offset as pointer size (hence 64 bit) value:

  2141: instructions[i + 6].u.pointer =
  reinterpret_cast(op.operand);

  while the same slot is accessed later by the jitted code as 32 bit
  integer:

  macro getProperty(slow)
  loadisFromInstruction(6, t1)

  This fails on big endian targets since the integer access takes the
  higher part of the 64 bit value.

  Changing:

  macro getProperty(slow)
  loadisFromInstruction(6, t1)

  to

  macro getProperty(slow)
  loadpFromInstruction(6, t1)

  in llint/LowLevelInterpreter64.asm fixes the problem for me.

  
  I could not reproduce the problem on Ubuntu 20.10. In upstream webkit the 
problem got fixed as a side effect of a larger change but in the end quite 
similar to the change I'm proposing. The value resides somewhere else now but 
it is accessed as 64 bit value in getProperty:

  macro getProperty()
  loadp OpGetFromScope::Metadata::m_operand[t5], t1


  If you have the jsc binary from the webkit package available the
  problem can be reproduced with just 'jsc -e "i=Math.min"'

  == Comment: #2 - Andreas Krebbel  -
  2021-11-15 09:49:55 ==

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1951470/+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 1929184] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2021-10-25 05:40 EDT---
Fix landed in impish, hence closing the bug.
IBM BZ status change:->CLOSED

-- 
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/1929184

Title:
  [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  Feature Description:  
  - Interface names for RoCE Express adapters are currently very hard to 
predict, causing problems with the installer which requires knowledge of the 
interface name
  - Interface names can change between re-boots, invalidating any previously 
stored network card configuration
  To fix this requires changes in the Linux kernel to indicate whether UIDs are 
unique (and therefore usable), and in systemd to generate an interface name 
based on UIDs all the time.

  Business Case:
  Increase usability, lower service efforts.

  The code is in the upstream repository and should eventually be
  contained in the upcoming systemd release 249

  a496a23 udev: fix slot based network names on s390
  b08c3fb udev: add missing initialization to fix freeing invalid address
  5a7eb46 udev: allow onboard index up to 65535

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929184/+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 1932010] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2021-10-25 05:29 EDT---
Fix is part of impish U21.10, hence closing the bug.
IBM BZ status change:->CLOSED

-- 
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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in zlib package in Ubuntu:
  Fix Released

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1929184] Re: [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2021-08-19 06:35 EDT---
Despite the initial concern because of the amount of fixes, Canonical managed 
to get this feature (systemd part) into Impish 21.10.
This way, we will have the full functionality of this feature and don't have to 
add a release note regarding limitations.
Therefore, changing Target Milestone back from 22.04 -> 21.10

** Tags removed: targetmilestone-inin2204
** Tags added: targetmilestone-inin2110

-- 
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/1929184

Title:
  [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  Feature Description:  
  - Interface names for RoCE Express adapters are currently very hard to 
predict, causing problems with the installer which requires knowledge of the 
interface name
  - Interface names can change between re-boots, invalidating any previously 
stored network card configuration
  To fix this requires changes in the Linux kernel to indicate whether UIDs are 
unique (and therefore usable), and in systemd to generate an interface name 
based on UIDs all the time.

  Business Case:
  Increase usability, lower service efforts.

  The code is in the upstream repository and should eventually be
  contained in the upcoming systemd release 249

  a496a23 udev: fix slot based network names on s390
  b08c3fb udev: add missing initialization to fix freeing invalid address
  5a7eb46 udev: allow onboard index up to 65535

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929184/+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 1929184] Re: [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2021-08-17 06:07 EDT---
This feature (systemd part) will not be integrated in 21.10 (see comment #6 
and#7), therefore moving to U22.04.
Canonical will add a release note to reflect changes and limitations due to the 
fact, that only the kernel part of this feature will make it into 21.10.

Changing Target Milestone: 21.10 -> 22.04

** Tags removed: targetmilestone-inin2110
** Tags added: targetmilestone-inin2204

-- 
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/1929184

Title:
  [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

Status in Ubuntu on IBM z Systems:
  In Progress
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Feature Description:  
  - Interface names for RoCE Express adapters are currently very hard to 
predict, causing problems with the installer which requires knowledge of the 
interface name
  - Interface names can change between re-boots, invalidating any previously 
stored network card configuration
  To fix this requires changes in the Linux kernel to indicate whether UIDs are 
unique (and therefore usable), and in systemd to generate an interface name 
based on UIDs all the time.

  Business Case:
  Increase usability, lower service efforts.

  The code is in the upstream repository and should eventually be
  contained in the upcoming systemd release 249

  a496a23 udev: fix slot based network names on s390
  b08c3fb udev: add missing initialization to fix freeing invalid address
  5a7eb46 udev: allow onboard index up to 65535

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929184/+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 1932010] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2021-08-12 11:39 EDT---
Thanks, everything looks good now!

# time -p env DFLTCC=0 python3 -c 'import gzip; 
gzip.decompress(gzip.compress(b"\x00" * 5, 1))'
real 2.56
user 2.23
sys 0.33

# sha1sum zlib1g_1.2.11.dfsg-2ubuntu7_s390x.deb
56f20f19ee81e025b6ee26efb803f442aeb2819a  zlib1g_1.2.11.dfsg-2ubuntu7_s390x.deb
# dpkg -i zlib1g_1.2.11.dfsg-2ubuntu7_s390x.deb

# time -p env DFLTCC=0 python3 -c 'import gzip; 
gzip.decompress(gzip.compress(b"\x00" * 5, 1))'
real 1.95
user 1.62
sys 0.32

-- 
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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  In Progress
Status in zlib package in Ubuntu:
  In Progress

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1932010] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2021-08-11 14:45 EDT---
Oh, sorry, I forgot that you can't use the IBM BZ links. I indeed had the 
following diffs in mind:

1.
#ifndef Z_IFUNC_ASM
local
#endif
-unsigned long (*(crc32_z_ifunc(void)))(unsigned long, const unsigned char FAR 
*, z_size_t)
+unsigned long (*(crc32_z_ifunc(
+#ifdef __s390__
+unsigned long hwcap
+#else
+void
+#endif
+)))(unsigned long, const unsigned char FAR *, z_size_t)
{
#if _ARCH_PWR8==1
#if defined(__BUILTIN_CPU_SUPPORTS__)

2.
#endif
#endif /* _ARCH_PWR8 */

+#ifdef HAVE_S390X_VX
+if (hwcap & HWCAP_S390_VX)
+return s390_crc32_vx;
+#endif
+
/* return a function pointer for optimized arches here */

3.
static unsigned long ZEXPORT (*crc32_func)(unsigned long, const unsigned char 
FAR *, z_size_t) = NULL;

if (!crc32_func)
-crc32_func = crc32_z_ifunc();
+crc32_func = crc32_z_ifunc(
+#ifdef __s390__
+getauxval(AT_HWCAP)
+#endif
+);
return (*crc32_func)(crc, buf, len);
}

I think the latest debdiff still misses the second one (the getauxval()
call is still there):

++#if defined(__s390__) && defined(S390_CRC32_VX)
++if (getauxval(AT_HWCAP) & HWCAP_S390_VX)
++return s390_crc32_vx;
++#endif

A couple nits:
- changelog: it's dfltcc, not dltss (yeah, the name is super weird :-))
- "/* Work around a probable bug in glibc when invoking getauxval in the ifunc 
*/" - I don't think it's actually a bug, since 
https://sourceware.org/glibc/wiki/GNU_IFUNC says that:

When LD_BIND_NOW=1 or -Wl,z,now is in effect symbols must be immediately
resolved at startup. In cases where an external function call depends
needs to be made that may fail if such a call has not been initialized
yet (PLT-based relocation which is processed later). For example calling
strlen in an IFUNC resolver built with -Wl,z,now may lead to a segfault
because the PLT is not yet resolved. This may work on x86_64 where the
R_*_IRELATIVE relocations happen in DT_JMPREL after the DT_REL*
relocations, but that is no guarantee that it will work on AArch64,
PPC64, or other architectures that are slightly different. Such
fundamental limitations may be lifted at a future point.

What's surprising is rather that, given this paragraph, the code
nevertheless works and there doesn't seem to be an obvious glibc commit
that lifts this limitation.

-- 
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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  In Progress
Status in zlib package in Ubuntu:
  In Progress

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1932010] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2021-08-11 10:36 EDT---
I think it rather has to do with glibc - ifunc are normally called quite early 
and therefore cannot use the dynamically resolved symbols, but maybe newer 
glibcs tolerate that. Unfortunately I couldn't find more information on this 
subject. The code seems to work, but just to be on the safe side I'd rather 
switch to the "old way" of doing things, that involves the hwcap argument:

https://bugzilla.linux.ibm.com/attachment.cgi?id=150618&action=diff#a/crc32.c_sec1
https://bugzilla.linux.ibm.com/attachment.cgi?id=150618&action=diff#a/crc32.c_sec3

-- 
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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  In Progress
Status in zlib package in Ubuntu:
  In Progress

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1932010] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2021-08-11 06:59 EDT---
zlib1g_1.2.11.dfsg-2ubuntu7~ppa2_s390x.deb works fine, thanks!

# time -p env DFLTCC=0 python3 -c 'import gzip; 
gzip.decompress(gzip.compress(b"\x00" * 5, 1))'
real 2.59
user 2.23
sys 0.35

# dpkg -i zlib1g_1.2.11.dfsg-2ubuntu7~ppa2_s390x.deb

# time -p env DFLTCC=0 python3 -c 'import gzip; 
gzip.decompress(gzip.compress(b"\x00" * 5, 1))'
real 1.99
user 1.62
sys 0.36

However, I'm not quite sure why does

++#ifdef S390_CRC32_VX
++if (getauxval(AT_HWCAP) & HWCAP_S390_VX)
++return s390_crc32_vx;
++#endif

work. For me getauxval() causes a segfault when called from an ifunc,
that's why I have to use the s390-specific ifunc's hwcap parameter.

-- 
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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  In Progress
Status in zlib package in Ubuntu:
  In Progress

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1932010] patch

[bugproxy]

--- Comment on attachment From i...@de.ibm.com 2021-08-10 17:47 EDT---


Argh, I haven't noticed this ticket and made a backport on my own a week ago. 
I'm attaching my patch here just for reference and will give yours a try 
tomorrow.

** Attachment added: "patch"
   
https://bugs.launchpad.net/bugs/1932010/+attachment/5517176/+files/0001-s390x-vectorize-crc32.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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  In Progress
Status in zlib package in Ubuntu:
  In Progress

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1932010] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2021-08-10 17:45 EDT---
*** Bug 193835 has been marked as a duplicate of this bug. ***

-- 
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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  In Progress
Status in zlib package in Ubuntu:
  In Progress

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1929657] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From mario.alberto.gali...@ibm.com 2021-07-28 17:41 EDT---
Sound good for me, lets close it

-- 
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/1929657

Title:
  [Ubuntu 20.4.2]  vLan not getting static IP assigned (on s390x)

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  Doing vLAN configuration one of the vLANs is not getting static IP assigned 
when the rest are workin without problems
   
  Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com 
   
  ---uname output---
  Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 
17:29:32 UTC 2021 s390x s390x s390x GNU/Linux
   
  Machine Type = z15 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1)Configure the netplan file as follow:
  root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml

  # This is the network config written by 'subiquity'

  network:

ethernets:

  encdb0:

addresses:

- 11.111.114.213/22

macaddress: 02:76:54:00:00:03

  encdc0:

addresses:

- 11.111.112.213/22

macaddress: 02:76:54:00:00:04

  enP50s3832 :

addresses:

- 11.111.112.214/22

  enP53p0s0:

addresses:

- 11.111.112.215/22

vlans:

  encdb0.160:

id: 160

link: encdb0

mtu: 9000

addresses:

- 192.168.160.53/24

  encdc0.150:

id: 150

link: encdc0

mtu: 9000

addresses:

- 192.168.150.53/24

  enP50s3832.170:

id: 170

link: enP50s3832

mtu: 9000

addresses:

- 192.168.170.53/24

  enP53p0s0.171:

id: 171

link: enP53p0s0

mtu: 9000

addresses:

- 192.168.171.53/24

version: 2

  2)run net plan apply:
  root@ilabg13:~# netplan --debug apply

  ** (generate:59965): DEBUG: 14:55:15.046: Processing input file
  /etc/netplan/00-installer-config.yaml..

  ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass

  ** (generate:59965): DEBUG: 14:55:15.046: Processing input file
  /etc/netplan/01-iscsi-config.yaml..

  ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass

  ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass
  them through a final round of validation

  ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting
  default backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting
  default backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.047: Generating output files..

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  ence0f is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  ence0f is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  encdb0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  encdb0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  encdc0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  encdc0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  enP50s3832 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  enP50s3832 is not for us (backend 1)

  ** (generate:5996

[Touch-packages] [Bug 1929657] udevadm_reload

[bugproxy]

--- Comment (attachment only) From mario.alberto.gali...@ibm.com 2021-07-27 
11:37 EDT---


** Attachment added: "udevadm_reload"
   
https://bugs.launchpad.net/bugs/1929657/+attachment/5514091/+files/udevadm_reload.txt

-- 
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/1929657

Title:
  [Ubuntu 20.4.2]  vLan not getting static IP assigned (on s390x)

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  Doing vLAN configuration one of the vLANs is not getting static IP assigned 
when the rest are workin without problems
   
  Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com 
   
  ---uname output---
  Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 
17:29:32 UTC 2021 s390x s390x s390x GNU/Linux
   
  Machine Type = z15 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1)Configure the netplan file as follow:
  root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml

  # This is the network config written by 'subiquity'

  network:

ethernets:

  encdb0:

addresses:

- 11.111.114.213/22

macaddress: 02:76:54:00:00:03

  encdc0:

addresses:

- 11.111.112.213/22

macaddress: 02:76:54:00:00:04

  enP50s3832 :

addresses:

- 11.111.112.214/22

  enP53p0s0:

addresses:

- 11.111.112.215/22

vlans:

  encdb0.160:

id: 160

link: encdb0

mtu: 9000

addresses:

- 192.168.160.53/24

  encdc0.150:

id: 150

link: encdc0

mtu: 9000

addresses:

- 192.168.150.53/24

  enP50s3832.170:

id: 170

link: enP50s3832

mtu: 9000

addresses:

- 192.168.170.53/24

  enP53p0s0.171:

id: 171

link: enP53p0s0

mtu: 9000

addresses:

- 192.168.171.53/24

version: 2

  2)run net plan apply:
  root@ilabg13:~# netplan --debug apply

  ** (generate:59965): DEBUG: 14:55:15.046: Processing input file
  /etc/netplan/00-installer-config.yaml..

  ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass

  ** (generate:59965): DEBUG: 14:55:15.046: Processing input file
  /etc/netplan/01-iscsi-config.yaml..

  ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass

  ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass
  them through a final round of validation

  ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting
  default backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting
  default backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.047: Generating output files..

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  ence0f is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  ence0f is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  encdb0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  encdb0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  encdc0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  encdc0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  enP50s3832 is not for us (backend 1)

  ** (generate

[Touch-packages] [Bug 1929657] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From mario.alberto.gali...@ibm.com 2021-07-27 11:33 EDT---
Enable udev monitor:
udevadm --debug monitor --property >> udevadm_reload.txt

Steeps followed to retrieve logs:

- Checking actual status of the vLan:
root@ilabg13:~# date
Tue Jul 27 08:23:47 MST 2021
root@ilabg13:~# ip addr show dev enP53p0s0.171
10: enP53p0s0.171@enP53p0s0:  mtu 9000 qdisc 
noqueue state UP group default qlen 1000
link/ether 82:0c:9b:c9:78:f8 brd ff:ff:ff:ff:ff:ff
inet6 fe80::800c:9bff:fec9:78f8/64 scope link
valid_lft forever preferred_lft forever

- Reload udevadm
root@ilabg13:~# date
Tue Jul 27 08:24:22 MST 2021
root@ilabg13:~# udevadm control --reload; udevadm trigger; udevadm settle

- Try to assign ip via netplan
root@ilabg13:~# date
Tue Jul 27 08:26:01 MST 2021
root@ilabg13:~# netplan --debug apply
** (generate:3616109): DEBUG: 08:26:04.430: Processing input file 
/etc/netplan/00-installer-config.yaml..
** (generate:3616109): DEBUG: 08:26:04.431: starting new processing pass
** (generate:3616109): DEBUG: 08:26:04.431: Processing input file 
/etc/netplan/01-iscsi-config.yaml..
** (generate:3616109): DEBUG: 08:26:04.431: starting new processing pass
** (generate:3616109): DEBUG: 08:26:04.431: We have some netdefs, pass them 
through a final round of validation
** (generate:3616109): DEBUG: 08:26:04.431: encdc0: setting default backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: encdb0: setting default backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: ence0f: setting default backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: encdb0.160: setting default backend 
to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: enP50s3832: setting default backend 
to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: enP53p0s0.171: setting default 
backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: enP50s3832.170: setting default 
backend to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: enP53p0s0: setting default backend 
to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: encdc0.150: setting default backend 
to 1
** (generate:3616109): DEBUG: 08:26:04.431: Configuration is valid
** (generate:3616109): DEBUG: 08:26:04.431: Generating output files..
** (generate:3616109): DEBUG: 08:26:04.431: openvswitch: definition ence0f is 
not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.431: NetworkManager: definition ence0f 
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.431: openvswitch: definition encdb0 is 
not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.431: NetworkManager: definition encdb0 
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition encdc0 is 
not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition encdc0 
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition enP50s3832 
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition 
enP50s3832 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition enP53p0s0 
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition 
enP53p0s0 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition encdb0.160 
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition 
encdb0.160 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition encdc0.150 
is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition 
encdc0.150 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition 
enP53p0s0.171 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition 
enP53p0s0.171 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: openvswitch: definition 
enP50s3832.170 is not for us (backend 1)
** (generate:3616109): DEBUG: 08:26:04.432: NetworkManager: definition 
enP50s3832.170 is not for us (backend 1)
(generate:3616109): GLib-DEBUG: 08:26:04.432: posix_spawn avoided (fd close 
requested)
(generate:3616109): GLib-DEBUG: 08:26:04.432: posix_spawn avoided (fd close 
requested)
DEBUG:netplan generated networkd configuration changed, restarting networkd
DEBUG:ence0f not found in {}
DEBUG:encdb0 not found in {'ence0f': {'addresses': ['9.11.116.213/24'], 
'

[Touch-packages] [Bug 1929657] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From mario.alberto.gali...@ibm.com 2021-07-27 10:40 EDT---
Since the file /etc/systemd/network/10-enP53p0s0.link was removed it wasn't get 
generated again.

Is there a way to get it generated again?

-- 
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/1929657

Title:
  [Ubuntu 20.4.2]  vLan not getting static IP assigned (on s390x)

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in linux package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  Doing vLAN configuration one of the vLANs is not getting static IP assigned 
when the rest are workin without problems
   
  Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com 
   
  ---uname output---
  Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 
17:29:32 UTC 2021 s390x s390x s390x GNU/Linux
   
  Machine Type = z15 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1)Configure the netplan file as follow:
  root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml

  # This is the network config written by 'subiquity'

  network:

ethernets:

  encdb0:

addresses:

- 11.111.114.213/22

macaddress: 02:76:54:00:00:03

  encdc0:

addresses:

- 11.111.112.213/22

macaddress: 02:76:54:00:00:04

  enP50s3832 :

addresses:

- 11.111.112.214/22

  enP53p0s0:

addresses:

- 11.111.112.215/22

vlans:

  encdb0.160:

id: 160

link: encdb0

mtu: 9000

addresses:

- 192.168.160.53/24

  encdc0.150:

id: 150

link: encdc0

mtu: 9000

addresses:

- 192.168.150.53/24

  enP50s3832.170:

id: 170

link: enP50s3832

mtu: 9000

addresses:

- 192.168.170.53/24

  enP53p0s0.171:

id: 171

link: enP53p0s0

mtu: 9000

addresses:

- 192.168.171.53/24

version: 2

  2)run net plan apply:
  root@ilabg13:~# netplan --debug apply

  ** (generate:59965): DEBUG: 14:55:15.046: Processing input file
  /etc/netplan/00-installer-config.yaml..

  ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass

  ** (generate:59965): DEBUG: 14:55:15.046: Processing input file
  /etc/netplan/01-iscsi-config.yaml..

  ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass

  ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass
  them through a final round of validation

  ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting
  default backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting
  default backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default
  backend to 1

  ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid

  ** (generate:59965): DEBUG: 14:55:15.047: Generating output files..

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  ence0f is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  ence0f is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  encdb0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  encdb0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  encdc0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition
  encdc0 is not for us (backend 1)

  ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition
  enP50s3832 is not for us (backend 1)

  ** (generate:59965):

[Touch-packages] [Bug 1931994] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From boris.m...@de.ibm.com 2021-07-27 04:23 EDT---
Attachment "Standalone C program from the upstream test case" removed on the 
bugzilla side as requested by Canonical

-- 
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/1931994

Title:
  [Ubuntu 20.04] OpenSSL bugs im s390x AES code

Status in Ubuntu on IBM z Systems:
  In Progress
Status in openssl package in Ubuntu:
  Fix Committed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Hirsute:
  New
Status in openssl source package in Impish:
  Fix Committed

Bug description:
  Problem description:

  When passing a NULL key to reset AES EVC state, the state wouldn't be 
completely reset on s390x.
  https://github.com/openssl/openssl/pull/14900

  Solution available here:
  
https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8

  Should be applied to all distros where openssl 1.1.1 is included for 
consistency reason.
  -> 21.10, 20.04, 18.04.
  I think not needed for 16.04 anymore

  [Test plan]

  $ sudo apt install libssl-dev
  $ gcc test.c -o evc-test -lcrypto -lssl # See 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for 
the test.c program
  $ ./evc-test && echo OK

  [Where problems could occur]

  This patch only touches s390x code paths, so there shouldn't be any 
regression on other architectures. However, on s390x this could reveal
  latent bugs by spreading a NULL key to new code paths.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Standalone C program from the upstream test case

[bugproxy]

Default Comment by Bridge

** Attachment added: "Standalone C program from the upstream test case"
   
https://bugs.launchpad.net/bugs/1931994/+attachment/5513259/+files/evp_extra_test.c

-- 
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/1931994

Title:
  [Ubuntu 20.04] OpenSSL bugs im s390x AES code

Status in Ubuntu on IBM z Systems:
  Triaged
Status in openssl package in Ubuntu:
  New
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Groovy:
  New
Status in openssl source package in Hirsute:
  New
Status in openssl source package in Impish:
  New

Bug description:
  Problem description:

  When passing a NULL key to reset AES EVC state, the state wouldn't be 
completely reset on s390x.
  https://github.com/openssl/openssl/pull/14900

  Solution available here:
  
https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8

  Should be applied to all distros where openssl 1.1.1 is included for 
consistency reason.
  -> 21.10, 20.04, 18.04.
  I think not needed for 16.04 anymore

  [Test plan]

  $ sudo apt install libssl-dev
  $ gcc test.c -o evc-test -lcrypto -lssl # See 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for 
the test.c program
  $ ./evc-test && echo OK

  [Where problems could occur]

  This patch only touches s390x code paths, so there shouldn't be any 
regression on other architectures. However, on s390x this could reveal
  latent bugs by spreading a NULL key to new code paths.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Standalone C program from the upstream test case

[bugproxy]

Default Comment by Bridge

** Attachment added: "Standalone C program from the upstream test case"
   
https://bugs.launchpad.net/bugs/1931994/+attachment/5513213/+files/evp_extra_test.c

-- 
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/1931994

Title:
  [Ubuntu 20.04] OpenSSL bugs im s390x AES code

Status in Ubuntu on IBM z Systems:
  Triaged
Status in openssl package in Ubuntu:
  New
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Groovy:
  New
Status in openssl source package in Hirsute:
  New
Status in openssl source package in Impish:
  New

Bug description:
  Problem description:

  When passing a NULL key to reset AES EVC state, the state wouldn't be 
completely reset on s390x.
  https://github.com/openssl/openssl/pull/14900

  Solution available here:
  
https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8

  Should be applied to all distros where openssl 1.1.1 is included for 
consistency reason.
  -> 21.10, 20.04, 18.04.
  I think not needed for 16.04 anymore

  [Test plan]

  $ sudo apt install libssl-dev
  $ gcc test.c -o evc-test -lcrypto -lssl # See 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for 
the test.c program
  $ ./evc-test && echo OK

  [Where problems could occur]

  This patch only touches s390x code paths, so there shouldn't be any 
regression on other architectures. However, on s390x this could reveal
  latent bugs by spreading a NULL key to new code paths.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1935617] Re: systemd autopkgtest broken on ppc64el with qemu 6.0

[bugproxy]

** Tags removed: architecture-all targetmilestone-inin---
** Tags added: architecture-ppc64le targetmilestone-inin2110

-- 
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/1935617

Title:
  systemd autopkgtest broken on ppc64el with qemu 6.0

Status in The Ubuntu-power-systems project:
  New
Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure yet if this is flaky or a real issue, but I'm filing it
  to avoid multiple people analyzing the same.

  The Qemu 6.0 upload 
https://launchpad.net/ubuntu/+source/qemu/1:6.0+dfsg-1~ubuntu2 triggers a test 
failure like
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/s/systemd/20210708_223311_e3bbb@/log.gz

  I have tested the new qemu on ppc64 and it worked fine for device emulation 
and migration cases.
  But this is suspicious.
  Of the last tests exactly and only those with the new qemu failed.

  
  impish
ppc64el
  tests-in-lxd   (F  5% f  0% S  0% B  0% => P 95%/) 
F.F.
  systemd-fsckd  (F  0% f  0% S 100% B  0% => P  0%/) 

  upstream-1 (F 15% f  0% S  0% B  0% => P 85%/) 
F..F
  upstream-2 (F 12% f  0% S  0% B  0% => P 87%/) 
F...

  
  For an insight in flakyness/reproducibility I've retriggered the missing qemu 
and the non-qemu cases a few times. If those reproduce all-bad vs all-good 
again this would further indicate a real issue.

  Unfortunately the ppc maas seems down right now and canonistack also
  isn't too nice this week - overall that inhibits the testing a bit :-/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1935617/+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