[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image
** Changed in: ubuntu-z-systems
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311
Title:
Setting "optional: true" to overcome he timeout "Job systemd-networkd-
wait-online" does no longer work with latest noble image
Status in Netplan:
In Progress
Status in Ubuntu on IBM z Systems:
Fix Released
Status in netplan.io package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Invalid
Status in netplan.io source package in Noble:
Fix Released
Status in systemd source package in Noble:
Invalid
Bug description:
Especially on s390x (but not limited to s390x) it's often the case that a
system has network devices that are not necessarily connected during boot-up
and one gets such a 2 min timeout:
"Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"
In the past I could avoid that by setting "optional: true" post-install (no
perfect, but worked),
but this does no longer seem to work using the latest noble ISO image (Apr
5th).
Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
this for me:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enP1p0s0:
optional: true
dhcp4: true
enP1p0s0d1:
optional: true
dhcp4: true
enP2p0s0:
optional: true
dhcp4: true
enP2p0s0d1:
optional: true
dhcp4: true
encc000: {}
version: 2
vlans:
encc000.2653:
addresses:
- 10.11.12.15/24
gateway4: 10.11.12.1
id: 2653
link: encc000
nameservers:
addresses:
- 10.11.12.1
... can be set fine (also --dry-run does not moan, except about
dhcp4).
This worked in the past on noble, but also on older Ubuntu releases
like jammy.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image
I gave ~ppa5 a try on my s390x system.
If I set all interfaces to "optional: true" (incl. encc000), but except
encc000.2653, I don't face the timeout anymore. But if I UNset
"optional: true" for encc000 on top, I tap into the timeout again.
In the past it was okay to NOT have "optional: true" set for both:
encc000 and encc000.2653 (and I found that logical, since both
interfaces are needed in a VLAN context).
Knowing now what's missing, I could live with that (even if it's a
change in behavior).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311
Title:
Setting "optional: true" to overcome he timeout "Job systemd-networkd-
wait-online" does no longer work with latest noble image
Status in Netplan:
In Progress
Status in Ubuntu on IBM z Systems:
New
Status in netplan.io package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Confirmed
Status in netplan.io source package in Noble:
Confirmed
Status in systemd source package in Noble:
Confirmed
Bug description:
Especially on s390x (but not limited to s390x) it's often the case that a
system has network devices that are not necessarily connected during boot-up
and one gets such a 2 min timeout:
"Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"
In the past I could avoid that by setting "optional: true" post-install (no
perfect, but worked),
but this does no longer seem to work using the latest noble ISO image (Apr
5th).
Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
this for me:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enP1p0s0:
optional: true
dhcp4: true
enP1p0s0d1:
optional: true
dhcp4: true
enP2p0s0:
optional: true
dhcp4: true
enP2p0s0d1:
optional: true
dhcp4: true
encc000: {}
version: 2
vlans:
encc000.2653:
addresses:
- 10.11.12.15/24
gateway4: 10.11.12.1
id: 2653
link: encc000
nameservers:
addresses:
- 10.11.12.1
... can be set fine (also --dry-run does not moan, except about
dhcp4).
This worked in the past on noble, but also on older Ubuntu releases
like jammy.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2060311] Re: Setting "optional: true" to overcome he timeout "Job systemd-networkd-wait-online" does no longer work with latest noble image
I see (deep in my mind I remember that such a discussion happened or at
least started somewhere).
Just notice that one interface is still _not_ optional, here in my case:
encc000
And the behavior changed recently, with the above config I didn not hit
the timeout in the past (even with earlier noble daily images).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2060311
Title:
Setting "optional: true" to overcome he timeout "Job systemd-networkd-
wait-online" does no longer work with latest noble image
Status in Netplan:
New
Status in Ubuntu on IBM z Systems:
New
Status in systemd package in Ubuntu:
New
Bug description:
Especially on s390x (but not limited to s390x) it's often the case that a
system has network devices that are not necessarily connected during boot-up
and one gets such a 2 min timeout:
"Job systemd-networkd-wait-online. Start running (1min 59s / no limit)"
In the past I could avoid that by setting "optional: true" post-install (no
perfect, but worked),
but this does no longer seem to work using the latest noble ISO image (Apr
5th).
Setting 'optional: true' in /etc/netplan/50-cloud-init.yaml looks like
this for me:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enP1p0s0:
optional: true
dhcp4: true
enP1p0s0d1:
optional: true
dhcp4: true
enP2p0s0:
optional: true
dhcp4: true
enP2p0s0d1:
optional: true
dhcp4: true
encc000: {}
version: 2
vlans:
encc000.2653:
addresses:
- 10.11.12.15/24
gateway4: 10.11.12.1
id: 2653
link: encc000
nameservers:
addresses:
- 10.11.12.1
... can be set fine (also --dry-run does not moan, except about
dhcp4).
This worked in the past on noble, but also on older Ubuntu releases
like jammy.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2060311/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
Included in pam | 1.5.3-5ubuntu3.
** Changed in: pam (Ubuntu)
Status: Fix Committed => Fix Released
** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in Ubuntu on IBM z Systems:
Fix Released
Status in pam package in Ubuntu:
Fix Released
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (_time, _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 (_time, _buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
Fix Committed with having:
pam | 1.5.3-4ubuntu1 | noble-proposed | source
** Changed in: pam (Ubuntu)
Status: New => Fix Committed
** Changed in: ubuntu-z-systems
Status: New => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in pam package in Ubuntu:
Fix Committed
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (_time, _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 (_time, _buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1833322] Re: Please consider no more having irqbalance enabled by default (per image/use-case/TBD)
** Changed in: ubuntu-z-systems Status: Opinion => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1833322 Title: Please consider no more having irqbalance enabled by default (per image/use-case/TBD) Status in cloud-images: New Status in Release Notes for Ubuntu: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in irqbalance package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: Fix Released Bug description: as per https://github.com/pop-os/default-settings/issues/60 Distribution (run cat /etc/os-release): $ cat /etc/os-release NAME="Pop!_OS" VERSION="19.04" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Pop!_OS 19.04" VERSION_ID="19.04" HOME_URL="https://system76.com/pop; SUPPORT_URL="http://support.system76.com; BUG_REPORT_URL="https://github.com/pop-os/pop/issues; PRIVACY_POLICY_URL="https://system76.com/privacy; VERSION_CODENAME=disco UBUNTU_CODENAME=disco Related Application and/or Package Version (run apt policy $PACKAGE NAME): $ apt policy irqbalance irqbalance: Installed: 1.5.0-3ubuntu1 Candidate: 1.5.0-3ubuntu1 Version table: *** 1.5.0-3ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status $ apt rdepends irqbalance irqbalance Reverse Depends: Recommends: ubuntu-standard gce-compute-image-packages Issue/Bug Description: as per konkor/cpufreq#48 and http://konkor.github.io/cpufreq/faq/#irqbalance-detected irqbalance is technically not needed on desktop systems (supposedly it is mainly for servers), and may actually reduce performance and power savings. It appears to provide benefits only to server environments that have relatively-constant loading. If it is truly a server- oriented package, then it shouldn't be installed by default on a desktop/laptop system and shouldn't be included in desktop OS images. Steps to reproduce (if you know): This is potentially an issue with all default installs. Expected behavior: n/a Other Notes: I can safely remove it via "sudo apt purge irqbalance" without any apparent adverse side-effects. If someone is running a situation where they need it, then they always have the option of installing it from the repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1833322/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: Fix Released Status in gdb package in Ubuntu: Fix Released Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: Fix Committed Status in gdb package in Ubuntu: Fix Committed Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
Thx doko, for having this incl. in gdb trunk/15 / 15.0.50.20240219-0ubuntu1: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/15802578/+listing-archive-extra -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: In Progress Status in gdb package in Ubuntu: In Progress Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1833322] Re: Please consider no more having irqbalance enabled by default (per image/use-case/TBD)
[Please ignore comment#35 - this was caused by a BZ-to-LP-bridge issue ...] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1833322 Title: Please consider no more having irqbalance enabled by default (per image/use-case/TBD) Status in Ubuntu on IBM z Systems: Confirmed Status in irqbalance package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: as per https://github.com/pop-os/default-settings/issues/60 Distribution (run cat /etc/os-release): $ cat /etc/os-release NAME="Pop!_OS" VERSION="19.04" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Pop!_OS 19.04" VERSION_ID="19.04" HOME_URL="https://system76.com/pop; SUPPORT_URL="http://support.system76.com; BUG_REPORT_URL="https://github.com/pop-os/pop/issues; PRIVACY_POLICY_URL="https://system76.com/privacy; VERSION_CODENAME=disco UBUNTU_CODENAME=disco Related Application and/or Package Version (run apt policy $PACKAGE NAME): $ apt policy irqbalance irqbalance: Installed: 1.5.0-3ubuntu1 Candidate: 1.5.0-3ubuntu1 Version table: *** 1.5.0-3ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status $ apt rdepends irqbalance irqbalance Reverse Depends: Recommends: ubuntu-standard gce-compute-image-packages Issue/Bug Description: as per konkor/cpufreq#48 and http://konkor.github.io/cpufreq/faq/#irqbalance-detected irqbalance is technically not needed on desktop systems (supposedly it is mainly for servers), and may actually reduce performance and power savings. It appears to provide benefits only to server environments that have relatively-constant loading. If it is truly a server- oriented package, then it shouldn't be installed by default on a desktop/laptop system and shouldn't be included in desktop OS images. Steps to reproduce (if you know): This is potentially an issue with all default installs. Expected behavior: n/a Other Notes: I can safely remove it via "sudo apt purge irqbalance" without any apparent adverse side-effects. If someone is running a situation where they need it, then they always have the option of installing it from the repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
** Tags added: pe-sponsoring-request -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: In Progress Status in gdb package in Ubuntu: In Progress Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
Test builds are done here: https://launchpad.net/~fheimes/+archive/ubuntu/lp1982336 ** Information type changed from Private to Public ** Changed in: ubuntu-z-systems Status: New => In Progress ** Changed in: gdb (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: In Progress Status in gdb package in Ubuntu: In Progress Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982336] Re: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16)
debdiff ** Patch added: "debdiff_gdb_noble_from_14.1-0ubuntu2_to_14.1-0ubuntu3.diff" https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1982336/+attachment/5746408/+files/debdiff_gdb_noble_from_14.1-0ubuntu2_to_14.1-0ubuntu3.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1982336 Title: [24.04 FEAT] GDB: Support for new IBM Z Hardware (IBM z16) Status in Ubuntu on IBM z Systems: In Progress Status in gdb package in Ubuntu: In Progress Bug description: GDB Support for new IBM Z Hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982336/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Since this bug is fixed with openssl 3.0.8 and newer, I'm changing the status of the current devel. release to Fix Released too (since we are there on 3.0.10). And with that the affected project status can be set to Fix Released, too. Thx! ** Changed in: openssl (Ubuntu) Status: In Progress => Fix Released ** Changed in: ubuntu-z-systems Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: Fix Released Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: Fix Released Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', rather than create a proper certificate file. Also watch /var/log/syslog / journalctl for more details. - Upgrade not only the openssl package itself, but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=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: 4700
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Hi Grgo, did you also updated libssl3? see test plan in Description: " - Upgrade not only the openssl package itself, but also libssl3, before verification. " With that I could successfully verify. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', rather than create a proper certificate file. Also watch /var/log/syslog / journalctl for more details. - Upgrade not only the openssl package itself, but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
verification on jammy was successful ** Description changed: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: - sudo apt-get install libica-utils libica? openssl-ibmca + sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: - sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: - (dynamic) Dynamic engine loading support - (ibmca) Ibmca hardware engine support <=== + sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf + - Verify if the 'openssl engine' lists an ibmca engine, + in addition to the dynamic engine: + openssl engine + (dynamic) Dynamic engine loading support + (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: - openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' + openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', - rather than create a proper certificate file. - Also watch /var/log/syslog / journalctl for more details. + rather than create a proper certificate file. + Also watch /var/log/syslog / journalctl for more details. + - Upgrade not only the openssl package itself, + but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2)
[Touch-packages] [Bug 2049958] [NEW] package bluez-obexd 5.68-0ubuntu1 failed to install/upgrade: unable to make backup link of './usr/lib/bluetooth/obexd' before installing new version: Input/output
Public bug reported:
bug found during software update launched from bootable usb
ProblemType: Package
DistroRelease: Ubuntu 23.10
Package: bluez-obexd 5.68-0ubuntu1
ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
Uname: Linux 6.5.0-9-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckMismatches: ./casper/minimal.squashfs
CasperMD5CheckResult: fail
CasperVersion: 1.486
CloudArchitecture: x86_64
CloudID: nocloud
CloudName: unknown
CloudPlatform: nocloud
CloudSubPlatform: seed-dir (/var/lib/cloud/seed/nocloud)
Date: Sat Jan 20 00:18:32 2024
DuplicateSignature:
package:bluez-obexd:5.68-0ubuntu1
Unpacking bluez-obexd (5.68-0ubuntu1.1) over (5.68-0ubuntu1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-MsVzUs/045-bluez-obexd_5.68-0ubuntu1.1_amd64.deb
(--unpack):
unable to make backup link of './usr/lib/bluetooth/obexd' before installing
new version: Input/output error
ErrorMessage: unable to make backup link of './usr/lib/bluetooth/obexd' before
installing new version: Input/output error
InterestingModules: rfcomm bnep btusb bluetooth
LiveMediaBuild: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1)
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz persistent
layerfs-path=minimal.standard.live.squashfs --- quiet splash
Python3Details: /usr/bin/python3.11, Python 3.11.6, python3-minimal, 3.11.4-5
PythonDetails: N/A
RelatedPackageVersions:
dpkg 1.22.0ubuntu1
apt 2.7.3
SourcePackage: bluez
Title: package bluez-obexd 5.68-0ubuntu1 failed to install/upgrade: unable to
make backup link of './usr/lib/bluetooth/obexd' before installing new version:
Input/output error
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/26/2018
dmi.bios.release: 5.6
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 306
dmi.board.asset.tag: Default string
dmi.board.name: GL553VW
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr306:bd09/26/2018:br5.6:svnASUSTeKCOMPUTERINC.:pnGL553VW:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnGL553VW:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:skuASUS-NotebookSKU:
dmi.product.family: GL
dmi.product.name: GL553VW
dmi.product.sku: ASUS-NotebookSKU
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.
hciconfig:
hci0: Type: Primary Bus: USB
BD Address: D0:57:7B:12:13:2F ACL MTU: 1021:5 SCO MTU: 96:6
UP RUNNING
RX bytes:1345 acl:0 sco:0 events:90 errors:0
TX bytes:3835 acl:0 sco:0 commands:90 errors:0
** Affects: bluez (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-package mantic need-duplicate-check
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/2049958
Title:
package bluez-obexd 5.68-0ubuntu1 failed to install/upgrade: unable to
make backup link of './usr/lib/bluetooth/obexd' before installing new
version: Input/output error
Status in bluez package in Ubuntu:
New
Bug description:
bug found during software update launched from bootable usb
ProblemType: Package
DistroRelease: Ubuntu 23.10
Package: bluez-obexd 5.68-0ubuntu1
ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
Uname: Linux 6.5.0-9-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckMismatches: ./casper/minimal.squashfs
CasperMD5CheckResult: fail
CasperVersion: 1.486
CloudArchitecture: x86_64
CloudID: nocloud
CloudName: unknown
CloudPlatform: nocloud
CloudSubPlatform: seed-dir (/var/lib/cloud/seed/nocloud)
Date: Sat Jan 20 00:18:32 2024
DuplicateSignature:
package:bluez-obexd:5.68-0ubuntu1
Unpacking bluez-obexd (5.68-0ubuntu1.1) over (5.68-0ubuntu1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-MsVzUs/045-bluez-obexd_5.68-0ubuntu1.1_amd64.deb
(--unpack):
unable to make backup link of './usr/lib/bluetooth/obexd' before installing
new version: Input/output error
ErrorMessage: unable to make backup link of './usr/lib/bluetooth/obexd'
before installing new version: Input/output error
InterestingModules: rfcomm bnep btusb bluetooth
LiveMediaBuild: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1)
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz persistent
layerfs-path=minimal.standard.live.squashfs --- quiet splash
Python3Details: /usr/bin/python3.11, Python 3.11.6, python3-minimal, 3.11.4-5
PythonDetails: N/A
RelatedPackageVersions:
dpkg 1.22.0ubuntu1
apt 2.7.3
SourcePackage: bluez
Title: package bluez-obexd 5.68-0ubuntu1 failed to
[Touch-packages] [Bug 1833322] Re: Consider removing irqbalance from default install on desktop images
** Changed in: ubuntu-z-systems Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1833322 Title: Consider removing irqbalance from default install on desktop images Status in Ubuntu on IBM z Systems: Confirmed Status in irqbalance package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: as per https://github.com/pop-os/default-settings/issues/60 Distribution (run cat /etc/os-release): $ cat /etc/os-release NAME="Pop!_OS" VERSION="19.04" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Pop!_OS 19.04" VERSION_ID="19.04" HOME_URL="https://system76.com/pop; SUPPORT_URL="http://support.system76.com; BUG_REPORT_URL="https://github.com/pop-os/pop/issues; PRIVACY_POLICY_URL="https://system76.com/privacy; VERSION_CODENAME=disco UBUNTU_CODENAME=disco Related Application and/or Package Version (run apt policy $PACKAGE NAME): $ apt policy irqbalance irqbalance: Installed: 1.5.0-3ubuntu1 Candidate: 1.5.0-3ubuntu1 Version table: *** 1.5.0-3ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status $ apt rdepends irqbalance irqbalance Reverse Depends: Recommends: ubuntu-standard gce-compute-image-packages Issue/Bug Description: as per konkor/cpufreq#48 and http://konkor.github.io/cpufreq/faq/#irqbalance-detected irqbalance is technically not needed on desktop systems (supposedly it is mainly for servers), and may actually reduce performance and power savings. It appears to provide benefits only to server environments that have relatively-constant loading. If it is truly a server- oriented package, then it shouldn't be installed by default on a desktop/laptop system and shouldn't be included in desktop OS images. Steps to reproduce (if you know): This is potentially an issue with all default installs. Expected behavior: n/a Other Notes: I can safely remove it via "sudo apt purge irqbalance" without any apparent adverse side-effects. If someone is running a situation where they need it, then they always have the option of installing it from the repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
** Changed in: ubuntu-z-systems
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in Ubuntu on IBM z Systems:
New
Status in pam package in Ubuntu:
New
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (_time, _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 (_time, _buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1833322] Re: Consider removing irqbalance from default install on desktop images
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => bugproxy (bugproxy) ** Tags added: reverse-proxy-bugzilla -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1833322 Title: Consider removing irqbalance from default install on desktop images Status in Ubuntu on IBM z Systems: New Status in irqbalance package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: as per https://github.com/pop-os/default-settings/issues/60 Distribution (run cat /etc/os-release): $ cat /etc/os-release NAME="Pop!_OS" VERSION="19.04" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Pop!_OS 19.04" VERSION_ID="19.04" HOME_URL="https://system76.com/pop; SUPPORT_URL="http://support.system76.com; BUG_REPORT_URL="https://github.com/pop-os/pop/issues; PRIVACY_POLICY_URL="https://system76.com/privacy; VERSION_CODENAME=disco UBUNTU_CODENAME=disco Related Application and/or Package Version (run apt policy $PACKAGE NAME): $ apt policy irqbalance irqbalance: Installed: 1.5.0-3ubuntu1 Candidate: 1.5.0-3ubuntu1 Version table: *** 1.5.0-3ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status $ apt rdepends irqbalance irqbalance Reverse Depends: Recommends: ubuntu-standard gce-compute-image-packages Issue/Bug Description: as per konkor/cpufreq#48 and http://konkor.github.io/cpufreq/faq/#irqbalance-detected irqbalance is technically not needed on desktop systems (supposedly it is mainly for servers), and may actually reduce performance and power savings. It appears to provide benefits only to server environments that have relatively-constant loading. If it is truly a server- oriented package, then it shouldn't be installed by default on a desktop/laptop system and shouldn't be included in desktop OS images. Steps to reproduce (if you know): This is potentially an issue with all default installs. Expected behavior: n/a Other Notes: I can safely remove it via "sudo apt purge irqbalance" without any apparent adverse side-effects. If someone is running a situation where they need it, then they always have the option of installing it from the repositories. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in Ubuntu on IBM z Systems:
New
Status in pam package in Ubuntu:
New
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (_time, _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 (_time, _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 2044304] Re: Apparmor crashes GPU acceleration in Firefox 120
thanks for this report and solution, very strange that FF uses dri/mesa
when hw-acceleration is disabled (yes, i unchecked both checkboxes).
i had this issue reproducable on google-login (drive.google.com) with
clean new profile without extensions
i can verify that the change in usr.bin.firefox file and restarting
apparmor solves this issue
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2044304
Title:
Apparmor crashes GPU acceleration in Firefox 120
Status in apparmor package in Ubuntu:
Confirmed
Bug description:
$ lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
$ apt-cache policy apparmor
apparmor:
Installed: 3.0.4-2ubuntu2.3
Candidate: 3.0.4-2ubuntu2.3
Version table:
*** 3.0.4-2ubuntu2.3 500 (phased 20%)
500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64
Packages
100 /var/lib/dpkg/status
3.0.4-2ubuntu2 500
500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
$ apt-cache policy firefox
firefox:
Installed: 120.0+build2-0ubuntu0.22.04.1~mt1
Candidate: 120.0+build2-0ubuntu0.22.04.1~mt1
Version table:
1:1snap1-0ubuntu2 -1
500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
*** 120.0+build2-0ubuntu0.22.04.1~mt1 1001
1001 https://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu
jammy/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy libglx-mesa0
libglx-mesa0:
Installed: 23.0.4-0ubuntu1~22.04.1
Candidate: 23.0.4-0ubuntu1~22.04.1
Version table:
*** 23.0.4-0ubuntu1~22.04.1 500
500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64
Packages
100 /var/lib/dpkg/status
22.0.1-1ubuntu2 500
500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
Firefox Apparmor profile seems out of date and needs extra
permissions.
The issue started happening in Firefox version 120 after an upgrade
from 119.0.1.
I do see the lots of DENIED Apparmor errors before the freeze/crash:
AVC apparmor="DENIED" operation="open" class="file" profile="firefox"
name="/sys/devices/pci:00/:00:01.0/:01:00.0/config" pid=11949
comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
AVC apparmor="DENIED" operation="open" class="file" profile="firefox"
name="/sys/devices/pci:00/:00:01.0/:01:00.0/revision"
pid=11949 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000
ouid=0
AVC apparmor="DENIED" operation="open" class="file" profile="firefox"
name="/proc/34029/cgroup" pid=34029
comm=49736F6C617465642057656220436F requested_mask="r" denied_mask="r"
fsuid=1000 ouid=1000
MESA: error: Failed to query drm device.
libEGL warning: egl: failed to create dri2 screen
Adding the following the following permissions to
/etc/apparmor.d/local/usr.bin.firefox seems to mitigate the issue:
/sys/devices/pci*/**/{config,revision} r,
@{PROC}/[0-9]*/**/comm r,
@{PROC}/[0-9]*/**/oom_score_adj w,
Disabling the firefox profile also mitigates the issue. It seems the
profile needs an update to include permissions required by Firefox
120.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2044304/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2045250] [NEW] pam_lastlog doesn't handle localtime_r related errors properly
Public bug reported:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314-ll_time = last_login.ll_time;
315:if ((tm = localtime_r (_time, _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 (_time, _buf);
577-strftime (the_time, sizeof (the_time),
578-/* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
** Affects: pam (Ubuntu)
Importance: Undecided
Status: New
** Affects: pam (Fedora)
Importance: Unknown
Status: Unknown
** Tags: rls-ff-incoming rls-jj-incoming rls-ll-incoming rls-mm-incoming
rls-nn-incoming
** Bug watch added: Red Hat Bugzilla #2012871
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
** Also affects: pam (Fedora) via
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in pam package in Ubuntu:
New
Status in pam package in Fedora:
Unknown
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (_time, _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 (_time, _buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
I had the update of the bug description on my todo list - it's done now. ** Description changed: === SRU information === + [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. - The issue has also been reported independently and with another engine (devcrypto). - The issue is fixed in openssl 3.0.8 which landed in lunar. + - An openssl engine is req. to test the fix. + - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. + - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. + - Install the needed package that allows to exploit the hw crypto resources: + sudo apt-get install libica-utils libica? openssl-ibmca + - And copy a working sample openssf.cnf file: + sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf + - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: + (dynamic) Dynamic engine loading support + (ibmca) Ibmca hardware engine support <=== + - try to create a new certificate, using this cmd-line: + openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' + - The above command must not lead to a 'Segmentation fault (core dumped)', + rather than create a proper certificate file. + Also watch /var/log/syslog / journalctl for more details. + - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Excuse me for chiming in so late, but we can test (and even recreate) the situation by ourselves on our system (and we have systems with attached crypto hw to it). I just tried it on a jammy z/VM guest: $ lszcrypt -V CARD.DOM TYPE MODESTATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER 02 CEX5C CCA-Coproc online10 11 08 S--D--N-- cex4card 02.0011 CEX5C CCA-Coproc online10 11 08 S--D--N-- cex4queue $ sudo apt-get install libica-utils libica? openssl-ibmca $ sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf $ openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support $ openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ..+++...+*.++...+.++.+..+..+*...+..+..+...+...++.+..++...+...+..+..+.+ ...+..+.+.+*...+..+...++...+...++.+.+...+...+...+*+...+.+..++...+..+..+...+..+.+..+.+.+...++.+.+..+.+...+..+.+.++...+.++..+.+...+...+..+.+...++...+++.+.+..+..+...+..+.+.+.+.+.+..+..++...+..+...+...+..+++..+.+..+.+...+.+.+.+.+.+.+.+.+.+.+++..+..+..+..+.+..+...+..+..++.+..+..+..+...+.+.+...+...+.+.+..+...+..+..+.+ - Segmentation fault (core dumped) $ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru=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
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Changed in: s390-tools (Ubuntu) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Medium ** Changed in: ubuntu-z-systems Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corresponding
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
This was implemented around 2020, mainly to catch any ccw config changes in a user friendly way: https://bugs.launchpad.net/bugs/1892367 https://i527439087.restricted.launchpadlibrarian.net/527439087/20f6c87a-829f-11eb-9412-002481e91f22.txt?token=zC4n7TlCmffBDHm9Dl002PsfchDXC3Dk Regarding: "1) Have the generic udev initramfs script not copy zdev-generated Udev rules," we need to be super careful here to not break stuff ... How to best identify the zdev-generated Udev rules, since these are not all the rules generated by chzdev (indicated by first line in rule), are they? I'm not very sure if initramfs(-tools) maintainer(s) are very happy ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Package changed: linux (Ubuntu) => s390-tools (Ubuntu) ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-z-systems Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the
[Touch-packages] [Bug 2037569] Re: udev issues with mantic beta
Hi Dan, I've took the manytic daily from yesterday (Oct 3rd) and checked if the updated udisks2 package is in - which is the case - and gave it a try. I did multiple different installations - all with DASDs, on LPAR and on z/VM. Installations with a single DASD or with multiple DASDs (even combining them to a bigger disk using LVM), and I didn't faced udev issues anymore. I checked with top during the installation as well as after the post-install reboot was completed -- all good. So many thanks for your fix and upload on this (and Seb's review) ! ** Changed in: ubuntu-z-systems Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037569 Title: udev issues with mantic beta Status in Ubuntu on IBM z Systems: Fix Released Status in libblockdev package in Ubuntu: New Status in systemd package in Ubuntu: Invalid Status in udisks2 package in Ubuntu: Fix Released Bug description: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2037569] Re: udev issues with mantic beta
I think it's caused by udisksctl here: https://github.com/storaged-project/udisks/blob/c7027d888c00381851d918f33a13102e7b86e188/tools/udisksctl.c#L2810C1-L2811C75 due to its repeating monitor messages: udisksctl monitor ** (udisksctl monitor:424911): WARNING **: 11:14:33.100: (udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check failed: (g_strv_length ((gchar **) invalidated_properties) == 0) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037569 Title: udev issues with mantic beta Status in Ubuntu on IBM z Systems: Confirmed Status in systemd package in Ubuntu: Confirmed Status in udisks2 package in Ubuntu: Confirmed Bug description: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2037569] Re: udev issues with mantic beta
Today I did some more tests and investigations. First of all I moved to the new mantic ISO image (20230928) that improved things quite a lot! The installation (on z/VM so far) is again very snappy and quick, incl. the enablement of a DASD device in the zDev activation screen. At the end of the installation, before hitting 'Reboot now' I went to the console and had a look at top to see if udev related processes are active, but I couldn't identify any: top - 10:47:51 up 9 min, 2 users, load average: 0.44, 0.41, 0.20 Tasks: 137 total, 1 running, 136 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 3988.9 total,214.3 free, 1957.6 used, 3233.2 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2031.3 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 15026 root 20 08788 4864 2816 R 0.7 0.1 0:00.28 top 1439 root 20 0 129824 74216 21376 S 0.3 1.8 0:03.76 /snap/subiquity/5183/usr/bin/python3.10 /snap/subiquity/518+ 1441 root 20 0 129788 74312 21376 S 0.3 1.8 0:03.57 /snap/subiquity/5183/usr/bin/python3.10 /snap/subiquity/518+ 2381 root 20 0 12216 5760 4864 S 0.3 0.1 0:00.10 sudo snap run subiquity 2383 root 20 0 206204 77680 21632 S 0.3 1.9 0:04.96 /snap/subiquity/5183/usr/bin/python3.10 -m subiquity 1 root 20 0 103300 13676 8940 S 0.0 0.3 0:03.49 /sbin/init --- 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kthreadd] 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [rcu_gp] 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [rcu_par_gp] 5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [slub_flushwq] 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [netns] 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [kworker/0:0H-events_highpri] 9 root 20 0 0 0 0 I 0.0 0.0 0:00.00 [kworker/0:1-cgroup_destroy] 10 root 20 0 0 0 0 I 0.0 0.0 0:01.11 [kworker/u128:0-events_unbound] 11 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [mm_percpu_wq] 12 root 20 0 0 0 0 I 0.0 0.0 0:00.00 [rcu_tasks_rude_kthread] 13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 [rcu_tasks_trace_kthread] Then, having the post-install reboot completed, and looking at top, I can observe the udev activities: top - 10:55:26 up 6 min, 1 user, load average: 2.16, 1.75, 0.84 Tasks: 108 total, 5 running, 103 sleeping, 0 stopped, 0 zombie %Cpu(s): 18.1 us, 22.7 sy, 0.0 ni, 48.8 id, 8.1 wa, 0.6 hi, 0.8 si, 0.9 st MiB Mem : 3988.9 total, 3274.2 free,271.4 used,539.0 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3717.5 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 1177 root 20 0 24884 5724 2560 R 33.2 0.1 1:50.24 (udev-worker) 1 root 20 0 168592 12912 8432 R 20.6 0.3 1:07.93 /sbin/init 690 root 20 0 467964 13112 10752 D 15.6 0.3 0:52.91 /usr/libexec/udisks2/udisksd 660 message+ 20 09328 4480 3840 S 14.6 0.1 0:52.68 @dbus-daemon --system --address=systemd: --nofork --nopidfile -+ 16285 ubuntu20 0 18004 9984 8448 S 10.6 0.2 0:33.06 /lib/systemd/systemd --user 385 root 20 0 24764 7492 4676 S 9.3 0.2 0:30.40 /lib/systemd/systemd-udevd 373 root rt 0 288412 26368 8064 S 6.6 0.6 0:21.50 /sbin/multipathd -d -s 686 root 20 0 16096 7424 6528 S 4.0 0.2 0:13.20 /lib/systemd/systemd-logind 681 root 20 0 2066332 34480 21248 S 1.7 0.8
[Touch-packages] [Bug 2037569] Re: udev issues with mantic beta
** Changed in: ubuntu-z-systems Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037569 Title: udev issues with mantic beta Status in Ubuntu on IBM z Systems: Confirmed Status in systemd package in Ubuntu: Confirmed Status in udisks2 package in Ubuntu: Confirmed Bug description: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2037569] [NEW] udev issues with mantic beta
Public bug reported: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... ** Affects: ubuntu-z-systems Importance: High Status: New ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: mantic s390x ** Attachment added: "installation_testing.txt" https://bugs.launchpad.net/bugs/2037569/+attachment/5704968/+files/installation_testing.txt ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037569 Title: udev issues with mantic beta Status in Ubuntu on IBM z Systems: New Status in systemd package in Ubuntu: New Bug description: While installing mantic beta (on s390x, LPAR and z/VM - but this might not be architecture specific) I faced issues with udev. In my installation I've updated the installer to "edge/lp-2009141" (subiquity 22.02.2+git1762.1b1ee6f4 5164). During my installations I first noticed bad response times in case of dealing with devices (like enabling new devices with chzdev). chzdev is used during the installation, hence the installation procedure is also affected by this. (I mainly notice this issue in case of DASD ECKD disk enablements.) But even after after a successful (but due to this issue less snappier) installation, means after the post-install reboot, in the installed system I can find several udev related processes, like: 69448 root 20 0 31280 11944 2560 S 39.2 0.0 2:51.67 (udev-worker) 509 root 20 0 31276 13812 4600 S 20.6 0.0 2:07.76 systemd-udevd 893 root 20 0 469016 13544 10496 R 17.3 0.0 1:43.53 udisksd 1 root 20 0 168664 12748 8396 S 16.3 0.0 1:40.47 systemd which is not only unusual, but (as one can see) they consume quite some resources. Even the remote ssh into that system is impacted by this high load. So far I only see this in mantic. I tried 20.04.3 as well as lunar, but both do not seem to be affected by this udev problem. I neither face the bad response on device enablement, nor can see any udev related processes still running after post-install-reboot in the installed system. (Sometimes I could also see a growing log file 'syslog'). I cannot say yet what is causing this, but since I see 'systemd-udevd' as prominent process in top, I'll first of all mark this as affecting systemd-udevd (or systemd). I've attached the outcome of some more investigations I did ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Changed in: ubuntu-z-systems Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Bug description: ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c Found module libc.so.6 with build-id: 74250317950da91d3345f258cb2dd12d22c3f2e5 Found module libcrypto.so.3 with build-id: a27f20e6cf293f214d459530ce2c0b2b52fdbdb4 Found module libssl.so.3 with build-id: e2c031c3dac06b5ce43bdea022aee7989f78dde4 Found module openssl with build-id: ed0fe325182e99d135ee6b08e6d90a9d1c42af7f Stack trace of thread 2344: #0 0x03ffae11c708 __pthread_rwlock_wrlock_full64 (libc.so.6 + 0x9c708) #1 0x03ffae437c22 CRYPTO_THREAD_write_lock (libcrypto.so.3 + 0x1b7c22) #2 0x03ffae3e3472 ENGINE_finish (libcrypto.so.3 + 0x163472)
[Touch-packages] [Bug 1926752] Re: [23.10 FEAT] libgmp SIMD optimizations
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gmp in Ubuntu. https://bugs.launchpad.net/bugs/1926752 Title: [23.10 FEAT] libgmp SIMD optimizations Status in Ubuntu on IBM z Systems: Fix Released Status in gmp package in Ubuntu: Fix Released Bug description: Optimize the GNU MP Bignum Library using vector instructions. - Requirement for Full Homomorphic Encryption, libgmp is used as a backend for NTL - libgmp performance is critical also for GNU Cobol on Z. Here a customer requested using packed decimal instructions in libgmp which does not appear to fit for libgmp - however SIMD would help on distros with ALS z13 https://gmplib.org/#STATUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1926752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926752] Re: [23.10 FEAT] libgmp SIMD optimizations
Many thx for your sponsorship, Graham! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gmp in Ubuntu. https://bugs.launchpad.net/bugs/1926752 Title: [23.10 FEAT] libgmp SIMD optimizations Status in Ubuntu on IBM z Systems: Fix Committed Status in gmp package in Ubuntu: Fix Committed Bug description: Optimize the GNU MP Bignum Library using vector instructions. - Requirement for Full Homomorphic Encryption, libgmp is used as a backend for NTL - libgmp performance is critical also for GNU Cobol on Z. Here a customer requested using packed decimal instructions in libgmp which does not appear to fit for libgmp - however SIMD would help on distros with ALS z13 https://gmplib.org/#STATUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1926752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926752] Re: [23.10 FEAT] libgmp SIMD optimizations
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gmp in Ubuntu. https://bugs.launchpad.net/bugs/1926752 Title: [23.10 FEAT] libgmp SIMD optimizations Status in Ubuntu on IBM z Systems: Fix Committed Status in gmp package in Ubuntu: Fix Committed Bug description: Optimize the GNU MP Bignum Library using vector instructions. - Requirement for Full Homomorphic Encryption, libgmp is used as a backend for NTL - libgmp performance is critical also for GNU Cobol on Z. Here a customer requested using packed decimal instructions in libgmp which does not appear to fit for libgmp - however SIMD would help on distros with ALS z13 https://gmplib.org/#STATUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1926752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926752] Re: [23.10 FEAT] libgmp SIMD optimizations
added updated debdiff ** Patch added: "debdiff_gmp_mantic_from_6.2.1+dfsg1-1.1ubuntu1_to__6.2.1+dfsg1-1.1ubuntu2.diff" https://bugs.launchpad.net/ubuntu/+source/gmp/+bug/1926752/+attachment/5685689/+files/debdiff_gmp_mantic_from_6.2.1+dfsg1-1.1ubuntu1_to__6.2.1+dfsg1-1.1ubuntu2.diff ** Changed in: gmp (Ubuntu) Assignee: Frank Heimes (fheimes) => (unassigned) ** Information type changed from Private to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gmp in Ubuntu. https://bugs.launchpad.net/bugs/1926752 Title: [23.10 FEAT] libgmp SIMD optimizations Status in Ubuntu on IBM z Systems: In Progress Status in gmp package in Ubuntu: In Progress Bug description: Optimize the GNU MP Bignum Library using vector instructions. - Requirement for Full Homomorphic Encryption, libgmp is used as a backend for NTL - libgmp performance is critical also for GNU Cobol on Z. Here a customer requested using packed decimal instructions in libgmp which does not appear to fit for libgmp - however SIMD would help on distros with ALS z13 https://gmplib.org/#STATUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1926752/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
** Package changed: linux (Ubuntu) => openssl (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: openssl (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) ** Changed in: openssl (Ubuntu) Importance: Undecided => High ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Tags added: rls-jj-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: New Status in openssl package in Ubuntu: New Bug description: ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c Found module libc.so.6 with build-id: 74250317950da91d3345f258cb2dd12d22c3f2e5 Found module libcrypto.so.3 with build-id: a27f20e6cf293f214d459530ce2c0b2b52fdbdb4 Found module libssl.so.3 with build-id: e2c031c3dac06b5ce43bdea022aee7989f78dde4 Found module openssl with build-id: ed0fe325182e99d135ee6b08e6d90a9d1c42af7f Stack trace of thread 2344:
[Touch-packages] [Bug 2017979] Re: [UBUNTU 20.04] Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated
Hi - the majority of engineers where on Sprints in the recent weeks, so we were a bit short on staff - apologize. This bug got already assigned. But to get you unblocked, you may just remove (sudo apt remove ...) the package in question (and the one that has it as dependency), since they are not mandatory: $ apt-cache policy language-pack-en-base language-pack-en language-pack-en-base: Installed: (none) Candidate: 1:20.04+20220818 Version table: 1:20.04+20220818 500 500 http://ports.ubuntu.com/ubuntu-ports focal-updates/main s390x Packages 1:20.04+20200416 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages language-pack-en: Installed: (none) Candidate: 1:20.04+20200416 Version table: 1:20.04+20200416 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages If you remove them, please note if further (reverse) dependencies are removed too, if so record them and re-install again after the upgrade. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to language-pack-en-base in Ubuntu. https://bugs.launchpad.net/bugs/2017979 Title: [UBUNTU 20.04] Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated Status in Ubuntu on IBM z Systems: Confirmed Status in language-pack-en-base package in Ubuntu: New Status in language-pack-en-base source package in Focal: Confirmed Bug description: ---Problem Description--- Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated do-release-update does not work Contact Information = pp...@de.ibm.com ---uname output--- Linux lnxut06 5.4.0-148-generic #165-Ubuntu SMP Tue Apr 18 08:52:35 UTC 2023 s390x s390x s390x GNU/Linux Machine Type = 3906 758 M03 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- root@lnxz:/etc/apt# do-release-upgrade Checking for a new Ubuntu release Please install all available updates for your release before upgrading. root@lnxz:/etc/apt# apt update Hit:1 http://de.ports.ubuntu.com/ubuntu-ports focal InRelease Get:2 http://de.ports.ubuntu.com/ubuntu-ports focal-updates InRelease [114 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [114 kB] Ign:4 https://pkg.jenkins.io/debian-stable binary/ InRelease Hit:5 https://pkg.jenkins.io/debian-stable binary/ Release Hit:7 http://de.ports.ubuntu.com/ubuntu-ports focal-backports InRelease Fetched 228 kB in 1s (201 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 1 package can be upgraded. Run 'apt list --upgradable' to see it. root@lnxz:/etc/apt# apt list --upgradable Listing... Done language-pack-en-base/focal-updates 1:20.04+20220818 all [upgradable from: 1:20.04+20220211] N: There are 2 additional versions. Please use the '-a' switch to see them. root@lnxz:/etc/apt# apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@lnxz:/etc/apt# apt --only-upgrade install language-pack-en-base Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: language-pack-en-base : Depends: language-pack-en (>= 1:20.04+20220818) but it is not going to be installed E: Unable to correct problems, you have held broken packages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2017979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2017979] Re: [UBUNTU 20.04] Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated
I can confirm that package 'language-pack-en-base' is not installable on an up to date 20.04.06 installation. $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.6 LTS Release:20.04 Codename: focal $ sudo apt update Hit:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease Hit:2 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease Hit:3 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease Hit:4 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date. $ apt-cache policy language-pack-en-base language-pack-en-base: Installed: (none) Candidate: 1:20.04+20220818 Version table: 1:20.04+20220818 500 500 http://ports.ubuntu.com/ubuntu-ports focal-updates/main s390x Packages 1:20.04+20200416 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages $ sudo apt install language-pack-en-base Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: language-pack-en-base : Depends: language-pack-en (>= 1:20.04+20220818) but it is not going to be installed E: Unable to correct problems, you have held broken packages. $ apt-cache policy language-pack-en language-pack-en: Installed: (none) Candidate: 1:20.04+20200416 Version table: 1:20.04+20200416 500 500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages $ ** Package changed: linux (Ubuntu) => language-pack-en-base (Ubuntu) ** Also affects: language-pack-en-base (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: language-pack-en-base (Ubuntu Focal) Status: New => Confirmed ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => Confirmed ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: language-pack-en-base (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to language-pack-en-base in Ubuntu. https://bugs.launchpad.net/bugs/2017979 Title: [UBUNTU 20.04] Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated Status in Ubuntu on IBM z Systems: Confirmed Status in language-pack-en-base package in Ubuntu: New Status in language-pack-en-base source package in Focal: Confirmed Bug description: ---Problem Description--- Cannot upgrade Ubuntu 20.04.6 LTS to 22.04. because the package language-pack-en-base cannot be updated do-release-update does not work Contact Information = pp...@de.ibm.com ---uname output--- Linux lnxut06 5.4.0-148-generic #165-Ubuntu SMP Tue Apr 18 08:52:35 UTC 2023 s390x s390x s390x GNU/Linux Machine Type = 3906 758 M03 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- root@lnxz:/etc/apt# do-release-upgrade Checking for a new Ubuntu release Please install all available updates for your release before upgrading. root@lnxz:/etc/apt# apt update Hit:1 http://de.ports.ubuntu.com/ubuntu-ports focal InRelease Get:2 http://de.ports.ubuntu.com/ubuntu-ports focal-updates InRelease [114 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [114 kB] Ign:4 https://pkg.jenkins.io/debian-stable binary/ InRelease Hit:5 https://pkg.jenkins.io/debian-stable binary/ Release Hit:7 http://de.ports.ubuntu.com/ubuntu-ports focal-backports InRelease Fetched 228 kB in 1s (201 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done 1 package can be upgraded. Run 'apt list --upgradable' to see it. root@lnxz:/etc/apt# apt list --upgradable Listing... Done language-pack-en-base/focal-updates 1:20.04+20220818 all [upgradable from: 1:20.04+20220211] N: There are 2 additional versions. Please use the '-a' switch to see them. root@lnxz:/etc/apt# apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@lnxz:/etc/apt# apt --only-upgrade install language-pack-en-base Reading
[Touch-packages] [Bug 2008964] Re: resolved falls back to a non-preferred name server when the preferred name server appears to be working.
I was able to reproduce on Ubuntu 20.04 too (by switching the active network interface), so this may not be a recent regression. -- 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/2008964 Title: resolved falls back to a non-preferred name server when the preferred name server appears to be working. Status in systemd package in Ubuntu: New Bug description: This is split from bug #2007728. On a network with multiple DNS servers provided by DHCP, the "Current DNS Server" shown by `resolvectl status` is sometimes not the first server or even the second server, even when those servers appear to be working (and other hosts continue to use them). This appears to occur on Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10. RFC 2132 section 3.8 provides that servers are listed in order of preference. It seems that the correct behavior is that resolved picks as its "Current DNS Server" the first reachable server in the list provided by the DHCP server. The observed behavior is that resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. My hypothesis is that there is some name server availability check that is too stringent and that there is no mechanism to retry the preferred server after that check fails. I have not looked at the code or captured packets. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2008964/+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 2007728] Re: resolved results differ from those from its current upstream server.
I split the "Current DNS Server" issue into bug #2008964. -- 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/2007728 Title: resolved results differ from those from its current upstream server. Status in systemd package in Ubuntu: Incomplete Bug description: On a network with multiple DNS servers provided by DHCP, only the first two of which cover local names, resolved returns universally known names but fails to return the special names even when the "Current DNS Server" shown by `resolvectl status` returns the special names. Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS servers with the local names. Windows servers with Active Directory enabled in this case. The DHCP server (a Cisco 4451 in this case) provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and 8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and 172.16.9.5 as the "Current DNS Server". `host localdomain.local` returns SRVFAIL, and `host localdomain.local 127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5` returns the correct result. This all happens regardless of the "Current DNS Server". Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons that are not clear even when the other servers are working properly, which seems to violate the principle of RFC 2132 section 3.8 that servers are listed in order of preference. So, in short, it seems that the correct behavior is that (1) resolved returns results consistent with its "Current DNS Server" and (2) resolved picks as its "Current DNS Server" the first reachable server in the list. The current behavior is that (1) resolved returns results sometimes inconsistent with its "Current DNS Server" and (2) resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. The first issue is consistently reproducible, and the second is readily reproducible in a short period of time. The problem appears on Ubuntu 22.04 and seems not to be present on Ubuntu 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2008964] [NEW] resolved falls back to a non-preferred name server when the preferred name server appears to be working.
Public bug reported: This is split from bug #2007728. On a network with multiple DNS servers provided by DHCP, the "Current DNS Server" shown by `resolvectl status` is sometimes not the first server or even the second server, even when those servers appear to be working (and other hosts continue to use them). This appears to occur on Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10. RFC 2132 section 3.8 provides that servers are listed in order of preference. It seems that the correct behavior is that resolved picks as its "Current DNS Server" the first reachable server in the list provided by the DHCP server. The observed behavior is that resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. My hypothesis is that there is some name server availability check that is too stringent and that there is no mechanism to retry the preferred server after that check fails. I have not looked at the code or captured packets. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2008964 Title: resolved falls back to a non-preferred name server when the preferred name server appears to be working. Status in systemd package in Ubuntu: New Bug description: This is split from bug #2007728. On a network with multiple DNS servers provided by DHCP, the "Current DNS Server" shown by `resolvectl status` is sometimes not the first server or even the second server, even when those servers appear to be working (and other hosts continue to use them). This appears to occur on Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10. RFC 2132 section 3.8 provides that servers are listed in order of preference. It seems that the correct behavior is that resolved picks as its "Current DNS Server" the first reachable server in the list provided by the DHCP server. The observed behavior is that resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. My hypothesis is that there is some name server availability check that is too stringent and that there is no mechanism to retry the preferred server after that check fails. I have not looked at the code or captured packets. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2008964/+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 2007728] Re: resolved results differ from those from its current upstream server.
Alright. The failure on a specific .local domain is consistent. I have not tested adding a non-".local" domain to the preferred name server, but your explanation that resolved now fully excludes .local from DNS queries makes sense. I still think that this is undesirable behavior since it breaks common legacy configurations without a clear indication of what the issue is and without an easy fix even for those who know what is broken. -- 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/2007728 Title: resolved results differ from those from its current upstream server. Status in systemd package in Ubuntu: Incomplete Bug description: On a network with multiple DNS servers provided by DHCP, only the first two of which cover local names, resolved returns universally known names but fails to return the special names even when the "Current DNS Server" shown by `resolvectl status` returns the special names. Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS servers with the local names. Windows servers with Active Directory enabled in this case. The DHCP server (a Cisco 4451 in this case) provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and 8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and 172.16.9.5 as the "Current DNS Server". `host localdomain.local` returns SRVFAIL, and `host localdomain.local 127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5` returns the correct result. This all happens regardless of the "Current DNS Server". Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons that are not clear even when the other servers are working properly, which seems to violate the principle of RFC 2132 section 3.8 that servers are listed in order of preference. So, in short, it seems that the correct behavior is that (1) resolved returns results consistent with its "Current DNS Server" and (2) resolved picks as its "Current DNS Server" the first reachable server in the list. The current behavior is that (1) resolved returns results sometimes inconsistent with its "Current DNS Server" and (2) resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. The first issue is consistently reproducible, and the second is readily reproducible in a short period of time. The problem appears on Ubuntu 22.04 and seems not to be present on Ubuntu 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2007728] Re: resolved results differ from those from its current upstream server.
Now that you mention it, I'm not sure. Something was definitely inconsistent, but the inconsistency may have been across different internal names rather than across requests on the same name, and it did not occur to me at the time that the .local names were in a different category. I will check tomorrow and report back. -- 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/2007728 Title: resolved results differ from those from its current upstream server. Status in systemd package in Ubuntu: Incomplete Bug description: On a network with multiple DNS servers provided by DHCP, only the first two of which cover local names, resolved returns universally known names but fails to return the special names even when the "Current DNS Server" shown by `resolvectl status` returns the special names. Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS servers with the local names. Windows servers with Active Directory enabled in this case. The DHCP server (a Cisco 4451 in this case) provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and 8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and 172.16.9.5 as the "Current DNS Server". `host localdomain.local` returns SRVFAIL, and `host localdomain.local 127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5` returns the correct result. This all happens regardless of the "Current DNS Server". Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons that are not clear even when the other servers are working properly, which seems to violate the principle of RFC 2132 section 3.8 that servers are listed in order of preference. So, in short, it seems that the correct behavior is that (1) resolved returns results consistent with its "Current DNS Server" and (2) resolved picks as its "Current DNS Server" the first reachable server in the list. The current behavior is that (1) resolved returns results sometimes inconsistent with its "Current DNS Server" and (2) resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. The first issue is consistently reproducible, and the second is readily reproducible in a short period of time. The problem appears on Ubuntu 22.04 and seems not to be present on Ubuntu 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2007728] Re: resolved results differ from those from its current upstream server.
Would you describe the "as documented" behavior? It still seems wacky to me that resolved returns the DNS result the majority of the time but not all of the time. If the design intent is to use only mDNS for .local domains, it ought to ignore DNS entirely for those domains. Inconsistent behavior means that a configuration can test as correct, fail in the field, fail to replicate the failure, and frustrate isolation of the problem. I think that the earlier behavior makes a lot more sense and would prefer to return to it. Are you able to replicate the issue? Given how closely the two possibly separate problems are related and their similar effects, I am inclined to wait on filing a second bug report on the server selection until it is clear that these are in fact separate issues. The fact that no other hosts on the network exhibit the problem (a highly symptomatic one since it breaks most services) suggests that this is not an issue of both internal servers failing at the same time. -- 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/2007728 Title: resolved results differ from those from its current upstream server. Status in systemd package in Ubuntu: Incomplete Bug description: On a network with multiple DNS servers provided by DHCP, only the first two of which cover local names, resolved returns universally known names but fails to return the special names even when the "Current DNS Server" shown by `resolvectl status` returns the special names. Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS servers with the local names. Windows servers with Active Directory enabled in this case. The DHCP server (a Cisco 4451 in this case) provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and 8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and 172.16.9.5 as the "Current DNS Server". `host localdomain.local` returns SRVFAIL, and `host localdomain.local 127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5` returns the correct result. This all happens regardless of the "Current DNS Server". Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons that are not clear even when the other servers are working properly, which seems to violate the principle of RFC 2132 section 3.8 that servers are listed in order of preference. So, in short, it seems that the correct behavior is that (1) resolved returns results consistent with its "Current DNS Server" and (2) resolved picks as its "Current DNS Server" the first reachable server in the list. The current behavior is that (1) resolved returns results sometimes inconsistent with its "Current DNS Server" and (2) resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. The first issue is consistently reproducible, and the second is readily reproducible in a short period of time. The problem appears on Ubuntu 22.04 and seems not to be present on Ubuntu 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2007728] Re: resolved results differ from those from its current upstream server.
The first two servers do indeed provide the .local domains. The possible violation of RFC 6762 does not explain the inconsistency of the results or the regression from Ubuntu 18.04 and Ubuntu 20.04. There is no case in which the correct behavior for a single configuration is to query the "Current DNS Server" for the .local name sometimes and mDNS other times. This also does not explain why the "Current DNS Server" selection sometimes fails to observe the order provided in the DHCP response. If resolved ignores the server ordering and the low-priority servers lack the internal names, even switching the suffix of the internal names is insufficient to provide the desired results. We have reverted the clients in question to Ubuntu 20.04 for now, and they work correctly. -- 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/2007728 Title: resolved results differ from those from its current upstream server. Status in systemd package in Ubuntu: Incomplete Bug description: On a network with multiple DNS servers provided by DHCP, only the first two of which cover local names, resolved returns universally known names but fails to return the special names even when the "Current DNS Server" shown by `resolvectl status` returns the special names. Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS servers with the local names. Windows servers with Active Directory enabled in this case. The DHCP server (a Cisco 4451 in this case) provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and 8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and 172.16.9.5 as the "Current DNS Server". `host localdomain.local` returns SRVFAIL, and `host localdomain.local 127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5` returns the correct result. This all happens regardless of the "Current DNS Server". Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons that are not clear even when the other servers are working properly, which seems to violate the principle of RFC 2132 section 3.8 that servers are listed in order of preference. So, in short, it seems that the correct behavior is that (1) resolved returns results consistent with its "Current DNS Server" and (2) resolved picks as its "Current DNS Server" the first reachable server in the list. The current behavior is that (1) resolved returns results sometimes inconsistent with its "Current DNS Server" and (2) resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. The first issue is consistently reproducible, and the second is readily reproducible in a short period of time. The problem appears on Ubuntu 22.04 and seems not to be present on Ubuntu 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+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 2007728] [NEW] resolved results differ from those from its current upstream server.
Public bug reported: On a network with multiple DNS servers provided by DHCP, only the first two of which cover local names, resolved returns universally known names but fails to return the special names even when the "Current DNS Server" shown by `resolvectl status` returns the special names. Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS servers with the local names. Windows servers with Active Directory enabled in this case. The DHCP server (a Cisco 4451 in this case) provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and 8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and 172.16.9.5 as the "Current DNS Server". `host localdomain.local` returns SRVFAIL, and `host localdomain.local 127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5` returns the correct result. This all happens regardless of the "Current DNS Server". Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons that are not clear even when the other servers are working properly, which seems to violate the principle of RFC 2132 section 3.8 that servers are listed in order of preference. So, in short, it seems that the correct behavior is that (1) resolved returns results consistent with its "Current DNS Server" and (2) resolved picks as its "Current DNS Server" the first reachable server in the list. The current behavior is that (1) resolved returns results sometimes inconsistent with its "Current DNS Server" and (2) resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. The first issue is consistently reproducible, and the second is readily reproducible in a short period of time. The problem appears on Ubuntu 22.04 and seems not to be present on Ubuntu 18.04. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2007728 Title: resolved results differ from those from its current upstream server. Status in systemd package in Ubuntu: New Bug description: On a network with multiple DNS servers provided by DHCP, only the first two of which cover local names, resolved returns universally known names but fails to return the special names even when the "Current DNS Server" shown by `resolvectl status` returns the special names. Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS servers with the local names. Windows servers with Active Directory enabled in this case. The DHCP server (a Cisco 4451 in this case) provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and 8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and 172.16.9.5 as the "Current DNS Server". `host localdomain.local` returns SRVFAIL, and `host localdomain.local 127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5` returns the correct result. This all happens regardless of the "Current DNS Server". Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons that are not clear even when the other servers are working properly, which seems to violate the principle of RFC 2132 section 3.8 that servers are listed in order of preference. So, in short, it seems that the correct behavior is that (1) resolved returns results consistent with its "Current DNS Server" and (2) resolved picks as its "Current DNS Server" the first reachable server in the list. The current behavior is that (1) resolved returns results sometimes inconsistent with its "Current DNS Server" and (2) resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. The first issue is consistently reproducible, and the second is readily reproducible in a short period of time. The problem appears on Ubuntu 22.04 and seems not to be present on Ubuntu 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1998470] Re: [23.04] re-add s390x vectorized crc32 support to zlib in lunar
** Summary changed: - re-add s390x vectorized crc32 support to zlib in lunar + [23.04] re-add s390x vectorized crc32 support to zlib in lunar ** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1998470 Title: [23.04] re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: Fix Released Status in zlib package in Ubuntu: Fix Released Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1992178] Re: autopkgtest: upstream tests that run in qemu hang on ppc64el
** Tags added: ppc64el reverse-proxy-bugzilla ** Changed in: ubuntu-power-systems Importance: Undecided => Medium ** Changed in: ubuntu-power-systems Assignee: (unassigned) => bugproxy (bugproxy) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1992178 Title: autopkgtest: upstream tests that run in qemu hang on ppc64el Status in systemd: Unknown Status in The Ubuntu-power-systems project: New Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: New Bug description: I believe this started early in the kinetic cycle, cf. https://autopkgtest.ubuntu.com/packages/systemd/kinetic/ppc64el vs https://autopkgtest.ubuntu.com/packages/systemd/jammy/ppc64el. Timeouts in the upstream tests have been an issue for a while, but kinetic on ppc64el consistently times out with upstream tests that run in QEMU. Skipping individual tests does not help, because *which* tests time out appears to change with each build. For example, in 251.4-1ubuntu4 the TEST-36-NUMAPOLICY test was consistently the culprit, but now in 251.4-1ubuntu6 the TEST-14-MACHINE-ID often times out. I have not been able to identify a root cause for this, but it seems that running tests in QEMU is very fragile on ppc64el, where as the tests that run in nspawn are more consistent. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1992178/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
** Changed in: ubuntu-z-systems
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2002511
Title:
zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
Status in Ubuntu on IBM z Systems:
In Progress
Status in zlib:
In Progress
Status in zlib package in Ubuntu:
In Progress
Status in zlib source package in Focal:
New
Status in zlib source package in Jammy:
New
Status in zlib source package in Kinetic:
New
Status in zlib source package in Lunar:
In Progress
Bug description:
SRU Justification:
--
[ Impact ]
* zlib version 1.2.13, as well as patched zlib versions 1.2.11 with
the patch from LP#1990379, break libxml2 and lxml on s390x.
* The problem appears during loading a gzipped XML file.
* Disabling hw compression with 'export DFLTCC=0' solves this,
hence it's a problem with the hardware acceleration patches DFLTCC.
* For more info see:
https://bugzilla.redhat.com/show_bug.cgi?id=2155328
[ Test Plan ]
* Steps to Reproduce:
1. echo "" > file.xml
2. gzip file.xml
3. python3
>>> import libxml2
>>> libxml2.parseFile("file.xml.gz")
* Actual results:
file.xml.gz:1: parser error : Document is empty
^
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.11/site-packages/libxml2.py",
line 1362, in parseFile
if ret is None:raise parserError('xmlParseFile() failed')
^^
libxml2.parserError: xmlParseFile() failed
* Expected results:
Loaded file.
[ Where problems could occur ]
* Since this is limited to s390x and DFLTCC / hw acceleration active,
any possible problems are limited to such environments.
* Fix can be broken if the state handling (state->wrap),
or the states mixed.
* The translation from stream to parameter block could be broken
(again due to wrong states) and the inflate as well.
[ Other Info ]
* The official upstream fix is here:
https://github.com/zlib-ng/zlib-ng/pull/1390
but it's for zlib-ng.
* For zlib this needs to be adjusted and was done by the author here:
https://launchpadlibrarian.net/641454325/patch-1.2.11
* And again slightly adjusted by me (renamed, some white-space fixes
and conversion into a quilt patch with proper dep3 header):
https://launchpadlibrarian.net/645435847/1390.patch
* The zlib version in Focal, Jammy, Kinetic and Lunar are affected.
__
It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks
libxml2 (and libxml) on s390x:
(https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch
should fix the issue.
The upstream author proposed a fix and a new test for zlib-ng
(https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such
breakages in the future.
___
This was initially reported as part of LP#1990379,
especially:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12
but needs a separate LP bug (number) - this one.
___
The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11
needed some tweaks regarding white-spaces, but then applied fine on focal,
jammy, kinetic and also 1.2.13, which is what we currently have in
lunar-proposed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
** Patch added:
"debdiff_zlib_lunar_from_1.2.13.dfsg-1ubuntu3_to_1.2.13.dfsg-1ubuntu4.diff"
https://bugs.launchpad.net/zlib/+bug/2002511/+attachment/5640780/+files/debdiff_zlib_lunar_from_1.2.13.dfsg-1ubuntu3_to_1.2.13.dfsg-1ubuntu4.diff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2002511
Title:
zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
Status in Ubuntu on IBM z Systems:
Triaged
Status in zlib:
In Progress
Status in zlib package in Ubuntu:
In Progress
Status in zlib source package in Focal:
New
Status in zlib source package in Jammy:
New
Status in zlib source package in Kinetic:
New
Status in zlib source package in Lunar:
In Progress
Bug description:
SRU Justification:
--
[ Impact ]
* zlib version 1.2.13, as well as patched zlib versions 1.2.11 with
the patch from LP#1990379, break libxml2 and lxml on s390x.
* The problem appears during loading a gzipped XML file.
* Disabling hw compression with 'export DFLTCC=0' solves this,
hence it's a problem with the hardware acceleration patches DFLTCC.
* For more info see:
https://bugzilla.redhat.com/show_bug.cgi?id=2155328
[ Test Plan ]
* Steps to Reproduce:
1. echo "" > file.xml
2. gzip file.xml
3. python3
>>> import libxml2
>>> libxml2.parseFile("file.xml.gz")
* Actual results:
file.xml.gz:1: parser error : Document is empty
^
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.11/site-packages/libxml2.py",
line 1362, in parseFile
if ret is None:raise parserError('xmlParseFile() failed')
^^
libxml2.parserError: xmlParseFile() failed
* Expected results:
Loaded file.
[ Where problems could occur ]
* Since this is limited to s390x and DFLTCC / hw acceleration active,
any possible problems are limited to such environments.
* Fix can be broken if the state handling (state->wrap),
or the states mixed.
* The translation from stream to parameter block could be broken
(again due to wrong states) and the inflate as well.
[ Other Info ]
* The official upstream fix is here:
https://github.com/zlib-ng/zlib-ng/pull/1390
but it's for zlib-ng.
* For zlib this needs to be adjusted and was done by the author here:
https://launchpadlibrarian.net/641454325/patch-1.2.11
* And again slightly adjusted by me (renamed, some white-space fixes
and conversion into a quilt patch with proper dep3 header):
https://launchpadlibrarian.net/645435847/1390.patch
* The zlib version in Focal, Jammy, Kinetic and Lunar are affected.
__
It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks
libxml2 (and libxml) on s390x:
(https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch
should fix the issue.
The upstream author proposed a fix and a new test for zlib-ng
(https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such
breakages in the future.
___
This was initially reported as part of LP#1990379,
especially:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12
but needs a separate LP bug (number) - this one.
___
The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11
needed some tweaks regarding white-spaces, but then applied fine on focal,
jammy, kinetic and also 1.2.13, which is what we currently have in
lunar-proposed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
** Summary changed:
- zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
+ zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2002511
Title:
zlib 1.2.13 (and patched 1.2.11) breaks libxml2 on s390x
Status in Ubuntu on IBM z Systems:
Triaged
Status in zlib:
In Progress
Status in zlib package in Ubuntu:
In Progress
Status in zlib source package in Focal:
New
Status in zlib source package in Jammy:
New
Status in zlib source package in Kinetic:
New
Status in zlib source package in Lunar:
In Progress
Bug description:
SRU Justification:
--
[ Impact ]
* zlib version 1.2.13, as well as patched zlib versions 1.2.11 with
the patch from LP#1990379, break libxml2 and lxml on s390x.
* The problem appears during loading a gzipped XML file.
* Disabling hw compression with 'export DFLTCC=0' solves this,
hence it's a problem with the hardware acceleration patches DFLTCC.
* For more info see:
https://bugzilla.redhat.com/show_bug.cgi?id=2155328
[ Test Plan ]
* Steps to Reproduce:
1. echo "" > file.xml
2. gzip file.xml
3. python3
>>> import libxml2
>>> libxml2.parseFile("file.xml.gz")
* Actual results:
file.xml.gz:1: parser error : Document is empty
^
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.11/site-packages/libxml2.py",
line 1362, in parseFile
if ret is None:raise parserError('xmlParseFile() failed')
^^
libxml2.parserError: xmlParseFile() failed
* Expected results:
Loaded file.
[ Where problems could occur ]
* Since this is limited to s390x and DFLTCC / hw acceleration active,
any possible problems are limited to such environments.
* Fix can be broken if the state handling (state->wrap),
or the states mixed.
* The translation from stream to parameter block could be broken
(again due to wrong states) and the inflate as well.
[ Other Info ]
* The official upstream fix is here:
https://github.com/zlib-ng/zlib-ng/pull/1390
but it's for zlib-ng.
* For zlib this needs to be adjusted and was done by the author here:
https://launchpadlibrarian.net/641454325/patch-1.2.11
* And again slightly adjusted by me (renamed, some white-space fixes
and conversion into a quilt patch with proper dep3 header):
https://launchpadlibrarian.net/645435847/1390.patch
* The zlib version in Focal, Jammy, Kinetic and Lunar are affected.
__
It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks
libxml2 (and libxml) on s390x:
(https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch
should fix the issue.
The upstream author proposed a fix and a new test for zlib-ng
(https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such
breakages in the future.
___
This was initially reported as part of LP#1990379,
especially:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12
but needs a separate LP bug (number) - this one.
___
The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11
needed some tweaks regarding white-spaces, but then applied fine on focal,
jammy, kinetic and also 1.2.13, which is what we currently have in
lunar-proposed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
** Bug watch added: Red Hat Bugzilla #2155328
https://bugzilla.redhat.com/show_bug.cgi?id=2155328
** Also affects: zlib via
https://bugzilla.redhat.com/show_bug.cgi?id=2155328
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2002511
Title:
zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
Status in Ubuntu on IBM z Systems:
Triaged
Status in zlib:
Unknown
Status in zlib package in Ubuntu:
In Progress
Status in zlib source package in Focal:
New
Status in zlib source package in Jammy:
New
Status in zlib source package in Kinetic:
New
Status in zlib source package in Lunar:
In Progress
Bug description:
SRU Justification:
--
[ Impact ]
* zlib version 1.2.13, as well as patched zlib versions 1.2.11 with
the patch from LP#1990379, break libxml2 and lxml on s390x.
* The problem appears during loading a gzipped XML file.
* Disabling hw compression with 'export DFLTCC=0' solves this,
hence it's a problem with the hardware acceleration patches DFLTCC.
* For more info see:
https://bugzilla.redhat.com/show_bug.cgi?id=2155328
[ Test Plan ]
* Steps to Reproduce:
1. echo "" > file.xml
2. gzip file.xml
3. python3
>>> import libxml2
>>> libxml2.parseFile("file.xml.gz")
* Actual results:
file.xml.gz:1: parser error : Document is empty
^
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.11/site-packages/libxml2.py",
line 1362, in parseFile
if ret is None:raise parserError('xmlParseFile() failed')
^^
libxml2.parserError: xmlParseFile() failed
* Expected results:
Loaded file.
[ Where problems could occur ]
* Since this is limited to s390x and DFLTCC / hw acceleration active,
any possible problems are limited to such environments.
* Fix can be broken if the state handling (state->wrap),
or the states mixed.
* The translation from stream to parameter block could be broken
(again due to wrong states) and the inflate as well.
[ Other Info ]
* The official upstream fix is here:
https://github.com/zlib-ng/zlib-ng/pull/1390
but it's for zlib-ng.
* For zlib this needs to be adjusted and was done by the author here:
https://launchpadlibrarian.net/641454325/patch-1.2.11
* And again slightly adjusted by me (renamed, some white-space fixes
and conversion into a quilt patch with proper dep3 header):
https://launchpadlibrarian.net/645435847/1390.patch
* The zlib version in Focal, Jammy, Kinetic and Lunar are affected.
__
It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks
libxml2 (and libxml) on s390x:
(https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch
should fix the issue.
The upstream author proposed a fix and a new test for zlib-ng
(https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such
breakages in the future.
___
This was initially reported as part of LP#1990379,
especially:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12
but needs a separate LP bug (number) - this one.
___
The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11
needed some tweaks regarding white-spaces, but then applied fine on focal,
jammy, kinetic and also 1.2.13, which is what we currently have in
lunar-proposed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
** Description changed:
+ SRU Justification:
+ --
+
+ [ Impact ]
+
+ * zlib version 1.2.13, as well as patched zlib versions 1.2.11 with
+the patch from LP#1990379, break libxml2 and lxml on s390x.
+
+ * The problem appears during loading a gzipped XML file.
+
+ * Disabling hw compression with 'export DFLTCC=0' solves this,
+hence it's a problem with the hardware acceleration patches DFLTCC.
+
+ * For more info see:
+ https://bugzilla.redhat.com/show_bug.cgi?id=2155328
+
+ [ Test Plan ]
+
+ * Steps to Reproduce:
+1. echo "" > file.xml
+2. gzip file.xml
+3. python3
+>>> import libxml2
+>>> libxml2.parseFile("file.xml.gz")
+
+ * Actual results:
+file.xml.gz:1: parser error : Document is empty
+^
+Traceback (most recent call last):
+ File "", line 1, in
+ File "/usr/lib/python3.11/site-packages/libxml2.py",
+ line 1362, in parseFile
+if ret is None:raise parserError('xmlParseFile() failed')
+ ^^
+libxml2.parserError: xmlParseFile() failed
+
+ * Expected results:
+Loaded file.
+
+ [ Where problems could occur ]
+
+ * Since this is limited to s390x and DFLTCC / hw acceleration active,
+any possible problems are limited to such environments.
+
+ * Fix can be broken if the state handling (state->wrap),
+or the states mixed.
+
+ * The translation from stream to parameter block could be broken
+(again due to wrong states) and the inflate as well.
+
+ [ Other Info ]
+
+ * The official upstream fix is here:
+https://github.com/zlib-ng/zlib-ng/pull/1390
+but it's for zlib-ng.
+
+ * For zlib this needs to be adjusted and was done by the author here:
+https://launchpadlibrarian.net/641454325/patch-1.2.11
+
+ * And again slightly adjusted by me (renamed, some white-space fixes
+and conversion into a quilt patch with proper dep3 header):
+https://launchpadlibrarian.net/645435847/1390.patch
+
+ * The zlib version in Focal, Jammy, Kinetic and Lunar are affected.
+ __
+
It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks
libxml2 (and libxml) on s390x:
(https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch
should fix the issue.
The upstream author proposed a fix and a new test for zlib-ng
(https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such
breakages in the future.
___
This was initially reported as part of LP#1990379,
especially:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12
but needs a separate LP bug (number) - this one.
___
The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11
needed some tweaks regarding white-spaces, but then applied fine on focal,
jammy, kinetic and also 1.2.13, which is what we currently have in
lunar-proposed.
** Also affects: zlib (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: zlib (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: zlib (Ubuntu Kinetic)
Importance: Undecided
Status: New
** Also affects: zlib (Ubuntu Lunar)
Importance: High
Status: New
** Changed in: ubuntu-z-systems
Status: New => Triaged
** Changed in: zlib (Ubuntu Lunar)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2002511
Title:
zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
Status in Ubuntu on IBM z Systems:
Triaged
Status in zlib package in Ubuntu:
In Progress
Status in zlib source package in Focal:
New
Status in zlib source package in Jammy:
New
Status in zlib source package in Kinetic:
New
Status in zlib source package in Lunar:
In Progress
Bug description:
SRU Justification:
--
[ Impact ]
* zlib version 1.2.13, as well as patched zlib versions 1.2.11 with
the patch from LP#1990379, break libxml2 and lxml on s390x.
* The problem appears during loading a gzipped XML file.
* Disabling hw compression with 'export DFLTCC=0' solves this,
hence it's a problem with the hardware acceleration patches DFLTCC.
* For more info see:
https://bugzilla.redhat.com/show_bug.cgi?id=2155328
[ Test Plan ]
* Steps to Reproduce:
1. echo "" > file.xml
2. gzip file.xml
3. python3
>>> import libxml2
>>> libxml2.parseFile("file.xml.gz")
* Actual results:
file.xml.gz:1: parser error : Document is empty
^
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.11/site-packages/libxml2.py",
line 1362, in parseFile
if ret is None:raise parserError('xmlParseFile() failed')
^^
libxml2.parserError:
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
PPA test builds a ongoing for F, J, K and L at https://launchpad.net/~fheimes/+archive/ubuntu/lp2002511 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
Hi Ilya, yepp, breaking libxml2 is of course an issue. Regarding the fix/patch, you attached here a patch named 'patch-1.2.11'. We have currently the following package versions in the archive: 1.2.11.dfsg-2ubuntu1.5 | focal 1.2.11.dfsg-2ubuntu9.2 | jammy 1.2.11.dfsg-4.1ubuntu1 | kinetic 1.2.13.dfsg-1ubuntu3 | lunar-proposed (After having tweaked the patch a bit regarding white-spaces...) the patch applies fine on focal, jammy and kinetic. I wondered if the patch is also for 1.2.13 (I think so, since the RH bug tells that), which is what we currently have in lunar-proposed - and it actually applies there fine too. I just needed to open a separate LP bug for this, since I need a separate bug number to reference this fix/patch in the changelogs: https://bugs.launchpad.net/bugs/2002511 So regarding the libxml(2) issue, the further work and communication will be there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: Triaged Status in zlib source package in Jammy: Triaged Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. * This bug (LP#1990379) is solved in combination with LP#1982583, so that only one package update is needed. However, this bug affects Kinetic, jammy and Focal, but LP#1982583 only Jammy and Kinetic. * The debdiffs for Kinetic and Jammy should be taken from LP#1982583, and the remaining debdiff for Focal from here. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
Attaching the slightly modified and renamed patch (original is at LP#1990379), now as quilt patch, with some whitespace adjustments and a proper dep3 header. ** Patch added: "1390.patch" https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+attachment/5640638/+files/1390.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2002511] [NEW] zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
Public bug reported: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. ** Affects: ubuntu-z-systems Importance: High Status: New ** Affects: zlib (Ubuntu) Importance: High Status: New ** Tags: s390x ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Summary changed: - zlib 1.2.13 breaks libxml(2) on s390x + zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x ** Changed in: ubuntu-z-systems Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/2002511 Title: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks libxml2 (and libxml) on s390x: (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue. The upstream author proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future. ___ This was initially reported as part of LP#1990379, especially: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12 but needs a separate LP bug (number) - this one. ___ The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11 needed some tweaks regarding white-spaces, but then applied fine on focal, jammy, kinetic and also 1.2.13, which is what we currently have in lunar-proposed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2002511/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Committed Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
Thx for reviewing, uploading and the fix! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Triaged Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
After getting the successful test results, I'm attaching the debdiff ... ** Attachment added: "debdiff_zlib_lunar_from_1.2.13.dfsg-1ubuntu2_to_1.2.13.dfsg-1ubuntu3.diff~" https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1998470/+attachment/5634588/+files/debdiff_zlib_lunar_from_1.2.13.dfsg-1ubuntu2_to_1.2.13.dfsg-1ubuntu3.diff~ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Triaged Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
Cross-referencing Ilya's comment about testing from here: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1982583/comments/7 " I ran tests 1-3 with Frank's 1:1.2.13.dfsg-1ubuntu3. They all pass; the performance improvement is also measurable. Test 4 turned out to be meaningless: Ubuntu requires at least z13. " Just notice that we have z13 as minimal required Z architecture starting with Ubuntu 20.04/focal anyway. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Triaged Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
** Changed in: zlib (Ubuntu) Status: New => Triaged ** Changed in: ubuntu-z-systems Status: New => Triaged ** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Triaged Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1998470] Re: re-add s390x vectorized crc32 support to zlib in lunar
Test builds of the updated package are currently running in this PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1998470 ** Description changed: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch - since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. + since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. + https://launchpad.net/ubuntu/+source/zlib/+changelog - This new patch is now available as + The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): - * Re-add vectorized crc32 support for s390x by adding - d/p/s390x-vectorize-crc32.patch - (crc32vx-v4: s390x: vectorize crc32). - This replaces the previously dropped patch: - lp1932010-ibm-z-add-vectorized-crc32-implementation.patch - * Remove option '--crc32-vx' for s390x in d/rules, that was previously just - commented out, since it's no longer needed with the new s390x crc32 code. + * Re-add vectorized crc32 support for s390x by adding + d/p/s390x-vectorize-crc32.patch + (crc32vx-v4: s390x: vectorize crc32). + This replaces the previously dropped patch: + lp1932010-ibm-z-add-vectorized-crc32-implementation.patch + * Remove option '--crc32-vx' for s390x in d/rules, that was previously just + commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: - * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 - due to unused "const char *endptr;". + * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 + due to unused "const char *endptr;". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. https://launchpad.net/ubuntu/+source/zlib/+changelog The new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1998470] [NEW] re-add s390x vectorized crc32 support to zlib in lunar
Public bug reported: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. This new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". ** Affects: ubuntu-z-systems Importance: Medium Assignee: Skipper Bug Screeners (skipper-screen-team) Status: New ** Affects: zlib (Ubuntu) Importance: Medium Assignee: Frank Heimes (fheimes) Status: New ** Tags: s390x ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => Medium ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1998470 Title: re-add s390x vectorized crc32 support to zlib in lunar Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: At the beginning of Nov a new zlib version (1:1.2.13.dfsg) got merged from Debian sid to Ubuntu lunar. At this time it was already clear that this new version is no longer compatible with patch d/p/lp1932010-ibm-z-add-vectorized-crc32-implementation.patch since this depends on zlib upstream PR 335 which has been superseded by upstream PR 478 with significant refactoring. Hence this patch was dropped and it was decided to backport (or better 'forward port'?) this vectorized crc32 implementation for s390x. This new patch is now available as crc32vx-v4: "s390x: vectorize crc32" https://github.com/iii-i/zlib/commit/05710d5fb8eb1447289ebf11109e149ece95d839 This LP bug is now to track the re-integration of the vectorized crc32 implementation for s390x. So a few things needed to happen (from the changelog): * Re-add vectorized crc32 support for s390x by adding d/p/s390x-vectorize-crc32.patch (crc32vx-v4: s390x: vectorize crc32). This replaces the previously dropped patch: lp1932010-ibm-z-add-vectorized-crc32-implementation.patch * Remove option '--crc32-vx' for s390x in d/rules, that was previously just commented out, since it's no longer needed with the new s390x crc32 code. And since I bumped into a little build issue, I've also needed to: * Update d/p/410.patch to version 26f2c0a4e17e5558d779797d713aa37ebaeef390 due to unused "const char *endptr;". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1998470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
** Changed in: systemd (Ubuntu) Status: Incomplete => Invalid ** Changed in: ubuntu-z-systems Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Invalid Status in systemd package in Ubuntu: Invalid Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
Oh yes, makes sense - thanks for the hint! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
Hmm, I just checked the changelog of the relevant packages (openssl and systemd), assuming to find a fix that might have landed in between your two attempts - but not much, mainly CVE fixes. (I also assume you haven't installed any local packages either...) And you've used the same packages than I did. So right now I can't really say what happened... Anyway, would you be okay with me closing this bug? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
Btw. before you retry, you may fix the broken packaging state of your system with: sudo apt-get -y -f install and then: sudo apt update ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1997579] Re: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x)
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu) ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Status: New => Incomplete ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1997579 Title: [Ubuntu22.04] systemd-coredump package not installable via apt install when only OpenSSL 3.0 is available on the system (s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in systemd package in Ubuntu: Incomplete Bug description: ---Problem Description--- Summary === IBM z16 LPAR (s390x architecture) OS: Ubuntu 20.04.1 LTS (jammy jellyfish) on 5.15.0-53-generic, openssl3.0.2-0ubuntu1.7 s390x systemd249.11-0ubuntu3.6 s390x The problem is immediately reproducible. Details === We fail to install the systemd-coredump package on a system where only OpenSSL 3.0.2 is available. Terminal output === # apt info systemd-coredump Package: systemd-coredump Version: 249.11-0ubuntu3.6 Priority: optional Section: universe/admin Source: systemd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Debian systemd Maintainers Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 337 kB Provides: core-dump-handler Depends: libc6 (>= 2.34), libdw1 (>= 0.158), libelf1 (>= 0.144), systemd (= 249.11-0ubuntu3.6), adduser Conflicts: core-dump-handler Replaces: core-dump-handler Homepage: https://www.freedesktop.org/wiki/Software/systemd Download-Size: 56.6 kB APT-Sources: http://ports.ubuntu.com/ubuntu-ports jammy-updates/universe s390x Packages Description: tools for storing and retrieving coredumps This package provides systemd tools for storing and retrieving coredumps: * systemd-coredump * coredumpctl N: There is 1 additional record. Please use the '-a' switch to see it # apt-get install systemd-coredump Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: apport : Conflicts: core-dump-handler libep11 : Depends: libssl1.0.0 but it is not installable or libssl1.1 but it is not installable systemd-coredump : Depends: libdw1 (>= 0.158) but it is not going to be installed Conflicts: core-dump-handler E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:54:41 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 3931 Model: 704 A01 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Configure the apt repos as shown in the attached sources.list file and run apt-get update 2.) Run: apt install systemd-coredump There is no package install available working with openssl version 3.0.N alone i.e. when openssl 1.0 or 1.1 are _NOT_ installed Userspace tool common name: coredumpctl The userspace tool has the following bit modes: 64-bit Userspace rpm: systemd-coredump Userspace tool obtained from project website: na *Additional Instructions for christian.r...@de.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1997579/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1983128] Re: linux-lowlatency fails to build on arm64 due to kernel option settings
set to invails, since this was for a previous proposed migrations issue
that was meanwhile solved
** Changed in: linux-lowlatency (Ubuntu)
Status: New => Invalid
** Changed in: zlib (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1983128
Title:
linux-lowlatency fails to build on arm64 due to kernel option settings
Status in linux-lowlatency package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Invalid
Bug description:
The 'linux-lowlatency' kernel build (incl. autopkgtest) was triggered in a
kinetic-proposed migration process (for zlib) and runs into a 'regression':
"autopkgtest for linux-lowlatency/5.19.0-1001.1: amd64: Pass, arm64:
Regression ♻"
The regression is highly likely not due to zlib itself, but due to NEW kernel
options, that don't have a default yet and a check-config FAIL, see:
...
check-config:
/tmp/autopkgtest.ZQs9si/build.cYo/src/debian/build/build-lowlatency/.config:
loading config
check-config:
/tmp/autopkgtest.ZQs9si/build.cYo/src/debian.lowlatency/config/annotations
loading annotations
check-config: FAIL (n != -): CONFIG_KCOV policy<{'amd64': 'n', 'arm64':
-, 'armhf': 'n', 'ppc64el': '-', 'riscv64': 'n', 's390x': '-'}>
check-config: 11323/11324 checks passed -- exit 1
...
Shadow Call Stack (SHADOW_CALL_STACK) [N/y/?] (NEW)
Error in reading or end of file.
...
Initialize kernel stack variables at function entry
> 1. no automatic stack variable initialization (weakest) (INIT_STACK_NONE)
2. pattern-init everything (strongest) (INIT_STACK_ALL_PATTERN) (NEW)
3. zero-init everything (strongest and safest) (INIT_STACK_ALL_ZERO) (NEW)
choice[1-3?]:
Error in reading or end of file.
...
Full log is here:
https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/arm64/l/linux-lowlatency/20220728_135536_c2061@/log.gz
(this might be caused by the recent compiler update)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1983128/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1974115 Title: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16 Status in Ubuntu on IBM z Systems: Fix Released Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Released Status in binutils source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact] * As of today the architectural (level) name 'arch14' is used as CPU name for the new IBM z16 system. * The real name 'z16' couldn't be used until officially announced. * That happened meanwhile, hence we can now add and use the real name. [Test Plan] * Check if the same (proper) opcodes are detected on an IBM z16 system with and without the patch. Since only the identification and name of a z16 system was modified. * Or the simplest test is probably to check (after having 'binutils' installed on an Ubuntu 22.04 s390x system) if not only: 'as -m64 -march=arch14 --target-help' but also: 'as -m64 -march=z16 --target-help' succeeds and leads to the same output. (As it does for '-march=arch13' and '-march=arch15'.) [Where problems could occur] * Issues could happen if the conditional statement that look for architectural / CPU name are paired wrongly, since: * 'z16' belongs to 'arch14', 'z15' to 'arch13', etc. * If these pairs are not handled correctly, or the identification is erroneous a wrong system might be identified and wrong instructions used etc. [Other] * This is a hardware enablement SRU to enhance the IBM z16 support. __ After the announcement support for the official machine name z16 has been added to binutils. Please consider picking up the following patch from 2.37 branch: commit e24d2a2d11008aa363366c1087219f3e3405782a (origin/binutils-2_37-branch, 2.37) IBM zSystems: Add support for z16 as CPU name. So far z16 was identified as arch14. After the machine has been announced we can now add the real name. (cherry picked from commit 69341966def7f6551bc4452684136831d6a6941c) (cherry picked from commit fb4d148004f28494e9fb5d2400a13308d07a7988) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1974115/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1978129] Re: Incomplete support for DT_RELR relocations on Ubuntu 22.04
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1978129 Title: Incomplete support for DT_RELR relocations on Ubuntu 22.04 Status in The Ubuntu-power-systems project: Fix Released Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Released Status in binutils source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact] * The latest glibc uses DT_RELR relocations, but it turned out that the linker support is still incomplete, as of binutils-2.38-3ubuntu1 on Ubuntu 22.04. * It lacks the fix/commit 'PowerPC64 DT_RELR relative reloc addresses'. * As discussed at the binutils mailing list: https://sourceware.org/pipermail/binutils/2022-March/119921.html this fixes several (glibc) regressions (from 574 to 17). * Instead of stashing r_offset final address calculations in ppc64_elf_size_stubs for use by ppc64_elf_build_stubs, section/offset pairs need to be kept. [Test Plan] * Build and run the official (make) check: git clone git://sourceware.org/git/glibc.git mkdir build && cd build ../glibc/configure --prefix=/usr && make -j8 && make check [Where problems could occur] * In case relr_addr is not replaced everywhere it's deletion in elf64-ppc.c can cause problems, which will mainly occur at build time. * The relr section/offset array may lead to problems if the array is not properly handled or used. * The rewrite of append_relr_off may cause issues due to wrong allocs erroneous pointer arithmetic or array handling. * The entirely new sort_relr function may introduce new code issues or performance issues. * The adjustments of ppc64_elf_size_stubs and ppc64_elf_build_stubs to the new relr code could be done wrong in which case the linker support is still not working. * But the patch was discussed at the upstream mailing list: https://sourceware.org/pipermail/binutils/2022-March/thread.html#119921 * and is limited to ppc, and even to file 'elf64-ppc.c'. __ == Comment: #0 - Matheus Salgueiro Castanho - 2022-06-09 09:32:29 == ---Problem Description--- Latest glibc uses DT_RELR relocations, but linker support is incomplete as of binutils-2.38-3ubuntu1 on Ubuntu 22.04. It lacks the following fix integrated into the upstream 2.38 branch: PowerPC64 DT_RELR relative reloc addresses https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e4a35c7319628045302d4c597cb27f1b0a08c858 As mentioned in the binutils mailing list when this patch was discussed, this fixes several glibc regressions: https://sourceware.org/pipermail/binutils/2022-March/119921.html Contact Information = Matheus Castanho/mscasta...@ibm.com ---uname output--- N/A Machine Type = N/A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- git clone git://sourceware.org/git/glibc.git mkdir build && cd build ../glibc/configure --prefix=/usr && make -j8 && make check Userspace tool common name: binutils The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils Userspace tool obtained from project website: na *Additional Instructions for Matheus Castanho/mscasta...@ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1978129/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Summary changed: - [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used + [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: Triaged Status in zlib source package in Jammy: Triaged Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. * This bug (LP#1990379) is solved in combination with LP#1982583, so that only one package update is needed. However, this bug affects Kinetic, jammy and Focal, but LP#1982583 only Jammy and Kinetic. * The debdiffs for Kinetic and Jammy should be taken from LP#1982583, and the remaining debdiff for Focal from here. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Description changed: SRU Justification: -- [ Impact ] - * The zlib function inflate() does not update strm.adler -in case DFLTCC is used. + * The zlib function inflate() does not update strm.adler + in case DFLTCC is used. - * This issue was exposed by Java Certification Kit (JCK) running on z15 -hardware and newer and impacts all JDK versions (8,11,17, etc.) -that use the system default settings. + * This issue was exposed by Java Certification Kit (JCK) running on z15 + hardware and newer and impacts all JDK versions (8,11,17, etc.) + that use the system default settings. - * The JCK failure impacts the ability to certify Java SDKs on this -platform/Linux-distribution combination. + * The JCK failure impacts the ability to certify Java SDKs on this + platform/Linux-distribution combination. - * On top the incorrect alder32 result may cause functional issues with -Java applications that depend on the result. + * On top the incorrect alder32 result may cause functional issues with + Java applications that depend on the result. [ Test Plan ] - * An affected Ubuntu release (20.04, 22.04 and 22.10) installed -on a z15/LinuxONE III or newer system is needed. + * An affected Ubuntu release (20.04, 22.04 and 22.10) installed + on a z15/LinuxONE III or newer system is needed. - * Then it's possible to test the updated package with the help -of a small test program (in C) that makes use of the zlib1g library -or run the Java Certification Kit. + * Then it's possible to test the updated package with the help + of a small test program (in C) that makes use of the zlib1g library + or run the Java Certification Kit. - * Test will be done by IBM. + * Test will be done by IBM. [ Where problems could occur ] - * The patch is a one-line change: -https://launchpadlibrarian.net/626003193/410-lp1990379.patch -and there are not many issues to expect. + * The patch is a one-line change: + https://launchpadlibrarian.net/626003193/410-lp1990379.patch + and there are not many issues to expect. - * There could be a potential problem with the adler field -in the strm struct. -For example in case the struct is not as assumed or contains -and unexpected value, which would then ripple through -the other fields, too. + * There could be a potential problem with the adler field + in the strm struct. + For example in case the struct is not as assumed or contains + and unexpected value, which would then ripple through + the other fields, too. - * Structural changes could be identified with a test build that was done -for all affected Ubuntu releases and for all major architectures: -https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 + * Structural changes could be identified with a test build that was done + for all affected Ubuntu releases and for all major architectures: + https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] - - * The patch itself is the same for all zlib version in -20.04, 22.04 and 22.10 - no further adjustments were needed. + + * The patch itself is the same for all zlib version in + 20.04, 22.04 and 22.10 - no further adjustments were needed. + + * This bug (LP#1990379) is solved in combination with LP#1982583, +so that only one package update is needed. +However, this bug affects Kinetic, jammy and Focal, +but LP#1982583 only Jammy and Kinetic. + + * The debdiffs for Kinetic and Jammy should be taken from LP#1982583, +and the remaining debdiff for Focal from here. + __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Jammy: In Progress Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib
[Touch-packages] [Bug 1982583] Re: Fix for zlib CRC32 optimization for s390x
** Description changed: + SRU Justification: + -- + + [ Impact ] + + * There were two issues identified in the current +zlib CRC32 optimization for s390x implementation: + + * 1) s390_crc32_vx() signature mismatch + which causes a warning + + * 2) '-DS390_CRC32_VX' was not added to SFLAGS + which results in vectorization being enabled only in the static library. + + * The fixes are quite small and affect each only one line: + + * 1) by using unsigned longs instead of uint32_t in s390_crc32_vx + declaration + + * 2) by add line 'SFLAGS="$SFLAGS -DS390_CRC32_VX"' + + [ Test Plan ] + + * An affected Ubuntu release ([20.04], 22.04 and 22.10) installed +on a z15/LinuxONE III or newer system is needed. + + * Then it's possible to test the updated package with the help +of a small test program (in C) that checks for +s390_crc32_vx() signature mismatches. + + * The bug reporter has a set of s390x-specific tests that will be + executed. + + * Test will be done by IBM. + + [ Where problems could occur ] + + * The fixes are each limited to one line, hence there are +not many issues to expect, other than: + + * Typos (e.g. in the flags), mixing of CFLAGS and SFLAGS, + + * in case the changed data type in s390_crc32_vx is causing issues +inside of s390_crc32_vx or in other parts of the code. + + * Structural and syntactical issues can be identified with a test build +that was done for all affected Ubuntu releases and for all major archs: +https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379+lp1982583 + + [ Other Info ] + + * This bug (LP#1982583) is solved in combination with LP#1982583, +so that only one package update is needed. +However, LP#1982583 also affects Focal, but this bug only Jammy and Kinetic. + + * To fix LP#1982583 also for focal the debdiff mentioned there is needed, too. + __ + 'zlib CRC32 optimization for s390x works only in a static library' I've discovered two issues in lp1932010-ibm-z-add-vectorized- crc32-implementation.patch: 1) s390_crc32_vx() signature mismatch, resulting in a warning. 2) -DS390_CRC32_VX is not added to SFLAGS, resulting in vectorization being enabled only in the static library. I've attached the updated patch. ** Description changed: SRU Justification: -- [ Impact ] - * There were two issues identified in the current -zlib CRC32 optimization for s390x implementation: + * There were two issues identified in the current + zlib CRC32 optimization for s390x implementation: - * 1) s390_crc32_vx() signature mismatch - which causes a warning + * 1) s390_crc32_vx() signature mismatch + which causes a warning - * 2) '-DS390_CRC32_VX' was not added to SFLAGS - which results in vectorization being enabled only in the static library. + * 2) '-DS390_CRC32_VX' was not added to SFLAGS + which results in vectorization being enabled only in the static library. - * The fixes are quite small and affect each only one line: + * The fixes are quite small and affect each only one line: - * 1) by using unsigned longs instead of uint32_t in s390_crc32_vx + * 1) by using unsigned longs instead of uint32_t in s390_crc32_vx declaration - * 2) by add line 'SFLAGS="$SFLAGS -DS390_CRC32_VX"' + * 2) by add line 'SFLAGS="$SFLAGS -DS390_CRC32_VX"' [ Test Plan ] - * An affected Ubuntu release ([20.04], 22.04 and 22.10) installed -on a z15/LinuxONE III or newer system is needed. + * An affected Ubuntu release ([20.04], 22.04 and 22.10) installed + on a z15/LinuxONE III or newer system is needed. - * Then it's possible to test the updated package with the help -of a small test program (in C) that checks for -s390_crc32_vx() signature mismatches. + * Then it's possible to test the updated package with the help + of a small test program (in C) that checks for + s390_crc32_vx() signature mismatches. - * The bug reporter has a set of s390x-specific tests that will be + * The bug reporter has a set of s390x-specific tests that will be executed. - * Test will be done by IBM. + * Test will be done by IBM. [ Where problems could occur ] - * The fixes are each limited to one line, hence there are -not many issues to expect, other than: + * The fixes are each limited to one line, hence there are + not many issues to expect, other than: - * Typos (e.g. in the flags), mixing of CFLAGS and SFLAGS, + * Typos (e.g. in the flags), mixing of CFLAGS and SFLAGS, - * in case the changed data type in s390_crc32_vx is causing issues -inside of s390_crc32_vx or in other parts of the code. + * in case the changed data type in s390_crc32_vx is causing issues + inside of s390_crc32_vx or in other parts of the code. - * Structural and syntactical issues can be identified with a test build -that was done for all affected
[Touch-packages] [Bug 1982583] Re: Fix for zlib CRC32 optimization for s390x
I transferred the modification into a separate patch (d/p/lp1982583-fix-for-zlib-crc32-optimization-for-s390x.patch), and build a patched version (for all major architectures) in PPA for jammy and kinetic: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379+lp1982583 and attaching here the debdiff for jammy and kinetic - which are for both LP bugs, this LP#1982583 and LP#1990379. ** Attachment added: "lp1990379+lp1982583_debdiffs.tgz" https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1982583/+attachment/5622051/+files/lp1990379+lp1982583_debdiffs.tgz ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: zlib (Ubuntu) Importance: Undecided => High ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: zlib (Ubuntu) Status: New => In Progress ** Changed in: ubuntu-z-systems Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1982583 Title: Fix for zlib CRC32 optimization for s390x Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Bug description: 'zlib CRC32 optimization for s390x works only in a static library' I've discovered two issues in lp1932010-ibm-z-add-vectorized- crc32-implementation.patch: 1) s390_crc32_vx() signature mismatch, resulting in a warning. 2) -DS390_CRC32_VX is not added to SFLAGS, resulting in vectorization being enabled only in the static library. I've attached the updated patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982583/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
I've just noticed another bug that I want to fix with the same package update: LP#1982583 But LP#1982583 affects only jammy and kinetic, not focal. This means for fixing this bug (LP#1990379) for jammy and kinetic, please use these debdiffs: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982583/comments/2 and for fixing this bug (LP#1990379) for focal, please take the focal debdiff from the previous comment: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/comments/7 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Jammy: In Progress Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982583] Re: zlib CRC32 optimization for s390x works only in a static library
** Description changed: + 'zlib CRC32 optimization for s390x works only in a static library' + I've discovered two issues in lp1932010-ibm-z-add-vectorized- crc32-implementation.patch: 1) s390_crc32_vx() signature mismatch, resulting in a warning. 2) -DS390_CRC32_VX is not added to SFLAGS, resulting in vectorization being enabled only in the static library. I've attached the updated patch. ** Summary changed: - zlib CRC32 optimization for s390x works only in a static library + Fix for zlib CRC32 optimization for s390x -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1982583 Title: Fix for zlib CRC32 optimization for s390x Status in zlib package in Ubuntu: New Bug description: 'zlib CRC32 optimization for s390x works only in a static library' I've discovered two issues in lp1932010-ibm-z-add-vectorized- crc32-implementation.patch: 1) s390_crc32_vx() signature mismatch, resulting in a warning. 2) -DS390_CRC32_VX is not added to SFLAGS, resulting in vectorization being enabled only in the static library. I've attached the updated patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1982583/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Fix Released
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Released
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
Fix Committed
Status in zlib source package in Focal:
Fix Released
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
Fix Released
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Fix Released
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, _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
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Changed in: zlib (Ubuntu Kinetic) Importance: Medium => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Jammy: In Progress Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Also affects: zlib (Ubuntu Kinetic) Importance: Medium Status: In Progress ** Also affects: zlib (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: zlib (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: zlib (Ubuntu Focal) Status: New => In Progress ** Changed in: zlib (Ubuntu Jammy) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Jammy: In Progress Status in zlib source package in Kinetic: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. --- External link: https://warthogs.atlassian.net/browse/PEI-28 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Description changed: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. + + --- + External link: https://warthogs.atlassian.net/browse/PEI-28 ** Tags added: pei-28 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff:
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
debdiffs for F, J and K ** Attachment added: "debdiffs.tgz" https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+attachment/5619739/+files/debdiffs.tgz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Description changed: + SRU Justification: + -- + + [ Impact ] + + * The zlib function inflate() does not update strm.adler +in case DFLTCC is used. + + * This issue was exposed by Java Certification Kit (JCK) running on z15 +hardware and newer and impacts all JDK versions (8,11,17, etc.) +that use the system default settings. + + * The JCK failure impacts the ability to certify Java SDKs on this +platform/Linux-distribution combination. + + * On top the incorrect alder32 result may cause functional issues with +Java applications that depend on the result. + + [ Test Plan ] + + * An affected Ubuntu release (20.04, 22.04 and 22.10) installed +on a z15/LinuxONE III or newer system is needed. + + * Then it's possible to test the updated package with the help +of a small test program (in C) that makes use of the zlib1g library +or run the Java Certification Kit. + + * Test will be done by IBM. + + [ Where problems could occur ] + + * The patch is a one-line change: +https://launchpadlibrarian.net/626003193/410-lp1990379.patch +and there are not many issues to expect. + + * There could be a potential problem with the adler field +in the strm struct. +For example in case the struct is not as assumed or contains +and unexpected value, which would then ripple through +the other fields, too. + + * Structural changes could be identified with a test build that was done +for all affected Ubuntu releases and for all major architectures: +https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 + + [ Other Info ] + + * The patch itself is the same for all zlib version in +20.04, 22.04 and 22.10 - no further adjustments were needed. + __ + == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. ** Changed in: zlib (Ubuntu) Status: New => In Progress ** Changed in: ubuntu-z-systems Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: In Progress Bug description: SRU Justification: -- [ Impact ] * The zlib function inflate() does not update strm.adler in case DFLTCC is used. * This issue was exposed by Java Certification Kit (JCK) running on z15 hardware and newer and impacts all JDK versions (8,11,17, etc.) that use the system default settings. * The JCK failure impacts the ability to certify Java SDKs on this platform/Linux-distribution combination. * On top the incorrect alder32 result may cause functional issues with Java applications that depend on the result. [ Test Plan ] * An affected Ubuntu release (20.04, 22.04 and 22.10) installed on a z15/LinuxONE III or newer system is needed. * Then it's possible to test the updated package with the help of a small test program (in C) that makes use of the zlib1g library or run the Java Certification Kit. * Test will be done by IBM. [ Where problems could occur ] * The patch is a one-line change: https://launchpadlibrarian.net/626003193/410-lp1990379.patch and there are not many issues to expect. * There could be a potential problem with the adler field in the strm struct. For example in case the struct is not as assumed or contains and unexpected value, which would then ripple through the other fields, too. * Structural changes could be identified with a test build that was done for all affected Ubuntu releases and for all major architectures: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 [ Other Info ] * The patch itself is the same for all zlib version in 20.04, 22.04 and 22.10 - no further adjustments were needed. __ == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff:
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
Ok, that's a (minimal) patch that can be handled nicely, thanks Ilya! Test packages are now being build in the following PPA for focal/20.04, jammy/22.04 and kinetic/22.10: https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379 https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379/+packages It would be great if someone (for example 'rahil'?!) could test (probably) at least the focal package upfront, to ensure that the situation is really solved, and with that, give us confidence for the SRU process. (Please notice that this would be on top of the official verification request that will come up later during the SRU process). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
So the next step would be to get more clarity on the complexity of the patch that is required. We have the (initial) PR 410 incl. in the zlib package, plus the patches from LP#1899621 and LP#1961427 on top. Hence we cannot directly use the new version of PR 410: https://github.com/madler/zlib/pull/410 and also the zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 seems to incl. more than just the fix for 'zlib: inflate() does not update strm.adler if DFLTCC is used'. For example I'm pretty sure that the modifications in contrib/s390/dfltcc.c and infback.c (as listed in the zlib diff) are part of the fix, but since I'm not the author I am unsure if this is everything that's needed. Are the changes in the crc32 needed on top? I think the typo fixes can be largely neglected ... Hence can you please provide us with a patch/backport for the minimal changes that are needed to fix 'zlib: inflate() does not update strm.adler if DFLTCC is used' and that applies on top of what's already in the zlib package (obviously after the quilt patches were applied)? Ideally based on the kinetic package (but the zlib packages in jammy and focal are pretty close, hence I assume that a backport will apply there too.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Changed in: zlib (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
Thanks for reporting this, Ilya. Can you please elaborate about the potential impact of this issue - that 'inflate() does not update strm.adler if DFLTCC is used'? Especially because this is marked with severity medium, but the Ubuntu stable release update process (SRUs: https://wiki.ubuntu.com/StableReleaseUpdates) is generally in order to fix high-impact bugs. With updating stable releases (like in this case 20.04 and 22.04) there is huge carefulness needed, and especially with updating key packages and libraries like zlib, since zlib has significant package reverse dependencies and a huge amount of reverse build dependencies (both in the thousands). Furthermore a potential update will impact multi-millions of installations, cross architecture, and we won't do that for a non-critical bugs, that maybe even only impact a small number of installations. However, there might be a little chance to piggy-back a fix like this with a more severe zlib update that might come up in future. ** Changed in: zlib (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990379] Re: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used
** Package changed: linux (Ubuntu) => zlib (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: ubuntu-z-systems Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1990379 Title: [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: == Comment: #0 - Ilya Leoshkevich - 2022-09-21 05:02:24 == inflate() does not update strm.adler if DFLTCC is used. Found with a JDK test. zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349 Updated zlib PR: https://github.com/madler/zlib/pull/410 zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920 zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620 Ubuntu 20.04 and later need to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Well, I had comment #11 in mind where the 1:1.2.11.dfsg-2ubuntu1.3 was
successfully verified on focal.
Meanwhile that version got overruled by a security update:
zlib (1:1.2.11.dfsg-2ubuntu1.3) focal-security; urgency=medium
and became 'already used', hence a new version was needed for this bug and so
we are now at:
1:1.2.11.dfsg-2ubuntu1.4 - but it incl. the same patches.
Anyway, I'll ask to get 1:1.2.11.dfsg-2ubuntu1.4 verified again on focal.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Released
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
Fix Committed
Status in zlib source package in Focal:
Fix Committed
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
Fix Released
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Fix Released
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, _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
[Touch-packages] [Bug 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
Hi Andreas, thanks for the verification, I'm going to adjust the tags accordingly. Don't worry about the potential regression, it's an automated mail based on the results of the autopkgtests that run automatically while processing such an SRU like this - and binutils trigger a lot of tests. Such regressions can be caused by several different things, like a different package that is handled at the same time and triggers similar tests or a flaky test etc. - we deal with it. (IF we think it's due to s390x-specific code, we may reach out to you ;-) ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1974115 Title: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16 Status in Ubuntu on IBM z Systems: Fix Committed Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Committed Status in binutils source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact] * As of today the architectural (level) name 'arch14' is used as CPU name for the new IBM z16 system. * The real name 'z16' couldn't be used until officially announced. * That happened meanwhile, hence we can now add and use the real name. [Test Plan] * Check if the same (proper) opcodes are detected on an IBM z16 system with and without the patch. Since only the identification and name of a z16 system was modified. * Or the simplest test is probably to check (after having 'binutils' installed on an Ubuntu 22.04 s390x system) if not only: 'as -m64 -march=arch14 --target-help' but also: 'as -m64 -march=z16 --target-help' succeeds and leads to the same output. (As it does for '-march=arch13' and '-march=arch15'.) [Where problems could occur] * Issues could happen if the conditional statement that look for architectural / CPU name are paired wrongly, since: * 'z16' belongs to 'arch14', 'z15' to 'arch13', etc. * If these pairs are not handled correctly, or the identification is erroneous a wrong system might be identified and wrong instructions used etc. [Other] * This is a hardware enablement SRU to enhance the IBM z16 support. __ After the announcement support for the official machine name z16 has been added to binutils. Please consider picking up the following patch from 2.37 branch: commit e24d2a2d11008aa363366c1087219f3e3405782a (origin/binutils-2_37-branch, 2.37) IBM zSystems: Add support for z16 as CPU name. So far z16 was identified as arch14. After the machine has been announced we can now add the real name. (cherry picked from commit 69341966def7f6551bc4452684136831d6a6941c) (cherry picked from commit fb4d148004f28494e9fb5d2400a13308d07a7988) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1974115/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Changed in: ubuntu-z-systems
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Released
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
Fix Committed
Status in zlib source package in Focal:
Fix Committed
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
Fix Released
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Fix Released
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, _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
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Thx Iliya! (updating tag accordingly)
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy
** Tags added: verification-done verification-done-focal verification-done-jammy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Released
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
Fix Committed
Status in zlib source package in Focal:
Fix Committed
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
Fix Committed
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Fix Committed
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, _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
[Touch-packages] [Bug 1982841] Re: [22.10 FEAT] [SEC2210] p11-kit: add IBM specific mechanisms and attributes (crypto)
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to p11-kit in Ubuntu. https://bugs.launchpad.net/bugs/1982841 Title: [22.10 FEAT] [SEC2210] p11-kit: add IBM specific mechanisms and attributes (crypto) Status in Ubuntu on IBM z Systems: Fix Released Status in p11-kit package in Ubuntu: Fix Released Bug description: Add support for IBM specific attributes and mechanis to the PKCS11 client-server implementation of p11-kit to p11-kit. This enables customers to access IBM Z HSMs remotely via a PKCS #11 API. Upstream Target: p11-kit 0.25.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982841/+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 1982841] Re: [22.10 FEAT] [SEC2210] p11-kit: add IBM specific mechanisms and attributes (crypto)
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to p11-kit in Ubuntu. https://bugs.launchpad.net/bugs/1982841 Title: [22.10 FEAT] [SEC2210] p11-kit: add IBM specific mechanisms and attributes (crypto) Status in Ubuntu on IBM z Systems: Fix Committed Status in p11-kit package in Ubuntu: Fix Committed Bug description: Add support for IBM specific attributes and mechanis to the PKCS11 client-server implementation of p11-kit to p11-kit. This enables customers to access IBM Z HSMs remotely via a PKCS #11 API. Upstream Target: p11-kit 0.25.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982841/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- 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
