[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 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)
** 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 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)
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 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)
** 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 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 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
Fix Committed with having:
pam | 1.5.3-4ubuntu1 | noble-proposed | source
** Changed in: pam (Ubuntu)
Status: New => Fix Committed
** Changed in: ubuntu-z-systems
Status: New => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in pam package in Ubuntu:
Fix Committed
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) {
316- strftime (the_time, sizeof (the_time),
317- /* TRANSLATORS: "strftime options for date of last
login" */
--
574-
575- lf_time = utuser.ut_tv.tv_sec;
576: tm = localtime_r (&lf_time, &tm_buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
Included in pam | 1.5.3-5ubuntu3.
** Changed in: pam (Ubuntu)
Status: Fix Committed => Fix Released
** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in Ubuntu on IBM z Systems:
Fix Released
Status in pam package in Ubuntu:
Fix Released
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) {
316- strftime (the_time, sizeof (the_time),
317- /* TRANSLATORS: "strftime options for date of last
login" */
--
574-
575- lf_time = utuser.ut_tv.tv_sec;
576: tm = localtime_r (&lf_time, &tm_buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 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 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
** 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 1874381] Re: LVM device unavailable after 18.04 to 20.04 upgrade Timed out waiting for device /dev/mapper/s5lp8--v g-home
** Changed in: lvm2 (Ubuntu) Assignee: Canonical Foundations Team (canonical-foundations) => (unassigned) ** Changed in: ubuntu-z-systems 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 lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1874381 Title: LVM device unavailable after 18.04 to 20.04 upgrade Timed out waiting for device /dev/mapper/s5lp8--v g-home Status in Ubuntu on IBM z Systems: Confirmed Status in lvm2 package in Ubuntu: Confirmed Status in lvm2 source package in Focal: Confirmed Bug description: After upgrading an LPAR configured with LVM from 18.04 to 20.04 /home is no longer mounted. During boot the console shows Timed out waiting for device /dev/mapper/s5lp8--vg-home Please see the attached dist-upgrade logs and console output for more detail. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974056] Re: iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless-bitwise_0 fails on s390x
** 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 iptables in Ubuntu. https://bugs.launchpad.net/bugs/1974056 Title: iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless- bitwise_0 fails on s390x Status in iptables: Unknown Status in Ubuntu on IBM z Systems: In Progress Status in iptables package in Ubuntu: New Bug description: In Ubuntu, we execute the full iptables shell testcases across all architectures. They seem to all pass everywhere, however iptables-1.8.7/iptables/tests/shell/testcases/nft-only/0009-needless- bitwise_0 is currently failing on s390x like so: command17FAIL stderr: W: [FAILED] ././testcases/nft- only/0009-needless-bitwise_0: expected 0 but got 1 i wonder if there is some endian bug, as this is currently Ubuntu's only big-endian architecture. this can be reproduced with: pull-lp-source iptables cd iptables-1.8.7/ chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0 cd iptables/tests/shell sudo ./run-tests.sh --host To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1974056/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977493] Re: Upgrade from Ubuntu 21.10 to 22.04 fails - unmet dependencies: libpam-modules
** Package changed: linux (Ubuntu) => pam (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** 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 pam in Ubuntu. https://bugs.launchpad.net/bugs/1977493 Title: Upgrade from Ubuntu 21.10 to 22.04 fails - unmet dependencies: libpam- modules Status in Ubuntu on IBM z Systems: New Status in pam package in Ubuntu: New Bug description: ---Problem Description--- Upgrade from Ubuntu 21.10 to 22.4 fails I run do-release-upgrade and I got a message upgrade completed with errors. I rebooted the server and it is now in an undefined state between 21.10 and 22.04. Not all packages have been installed. I attach apt log and output of some commands: root@tuxmaker:~# cat /etc/os-release PRETTY_NAME="Ubuntu 21.10" NAME="Ubuntu" VERSION_ID="21.10" VERSION="21.10 (Impish Indri)" VERSION_CODENAME=impish ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=impish root@tuxmaker:~# do-release-upgrade Checking for a new Ubuntu release Please install all available updates for your release before upgrading. root@tuxmaker:~# apt dist-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: libpam-modules : PreDepends: libpam-modules-bin (= 1.3.1-5ubuntu11) but 1.4.0-11ubuntu2 is installed Recommends: update-motd but it is not installed E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). root@tuxmaker:~# apt --fix-broken install Reading package lists... Done Building dependency tree... Done Reading state information... Done Correcting dependencies... Done The following additional packages will be installed: libpam-modules The following packages will be upgraded: libpam-modules 1 upgraded, 0 newly installed, 0 to remove and 1208 not upgraded. 4 not fully installed or removed. Need to get 0 B/279 kB of archives. After this operation, 1,024 B disk space will be freed. Do you want to continue? [Y/n] y Preconfiguring packages ... (Reading database ... 401827 files and directories currently installed.) Preparing to unpack .../libpam-modules_1.4.0-11ubuntu2_s390x.deb ... dpkg: error processing archive /var/cache/apt/archives/libpam-modules_1.4.0-11ubuntu2_s390x.deb (--unpack): new libpam-modules:s390x package pre-installation script subprocess returned error exit status 2 Errors were encountered while processing: /var/cache/apt/archives/libpam-modules_1.4.0-11ubuntu2_s390x.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Contact Information = pp...@de.ibm.com ---uname output--- Linux tuxmaker 5.13.0-44-generic #49-Ubuntu SMP Wed May 18 13:30:03 UTC 2022 s390x s390x s390x GNU/Linux Machine Type = z15, 8561-701 ---boot type--- upgade ---Kernel cmdline used to launch install--- do-release-upgrade ---Install repository type--- Internet repository ---Install repository Location--- http://ports.ubuntu.com:80/ ---Point of failure--- Other failure during installation (stage 1) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1977493/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1977493] Re: Upgrade from Ubuntu 21.10 to 22.04 fails - unmet dependencies: libpam-modules
First of all I assume there was no previous attempt of doing a 'do- release-upgrade' or even an attempt that was stopped/interrupted, or an attempt to get the system updated in a different way, for example (in the abs. not recommended way to) to change all 'impish' entries in /etc/apt/sources.list to jammy or so. Launchpad (https://launchpad.net/ubuntu/+source/pam/) clearly shows that 21.10/impish has currently 1.3.1-5ubuntu11 (and 22.04/jammy has 1.4.0-11ubuntu2). A different way to check this is: $ rmadison --arch=s390x libpam-modules | egrep "impish|jammy" libpam-modules | 1.3.1-5ubuntu11 | impish | s390x libpam-modules | 1.4.0-11ubuntu2 | jammy | s390x (And since no 'impish-updates' line is listed here, this particular package was also never updated during the impish release.) So since your current system is (still) 21.10, it must have version 1.3.1-5ubuntu11 installed. $ lsb_release -cs impish $ apt-cache policy libpam-modules libpam-modules: Installed: 1.3.1-5ubuntu11 Candidate: 1.3.1-5ubuntu11 Version table: *** 1.3.1-5ubuntu11 500 500 http://ports.ubuntu.com/ubuntu-ports impish/main s390x Packages 100 /var/lib/dpkg/status ... but I must not have 1.4.0-11ubuntu2 installed, since this is the version of the 22.04 release. Calling 'apt-cache policy libpam-modules' on your system will give a hint where the currently installed version was taken from. Sharing the output of this command from your system would be interesting - in addition to the 'sudo apt update' and 'lsb_release -a' output and the file /etc/apt/sources.list. Such a situation could have been caused if someone downloaded the jammy version of a package manually and (forcefully) installed it or if someone wanted to try packages from a different release and added an archive line pointing to that different Ubuntu release (e.g. jammy) to the /etc/apt/sources.list file. The line "'1 upgraded, 0 newly installed, 0 to remove and 1208 not upgraded." is also very suspicious, because 1208 must be close to the overall number of packages in your system (a default install on s390x has about 1020 packages). So please check that no packages are taken from an Ubuntu release other than the currently installed one: $ lsb_release -cs impish Means check the content of /etc/apt/sources.list (and maybe further sources* files in that folder). You should also monitor the output of 'sudo apt update' while updating the package indices and check if a wrong Ubuntu release is listed. In case a wrong archive line is listed, fix it by editing the file and execute: $ sudo apt clean && sudo apt update If everything is fine now, upgrade the current system to the very latest level: $ sudo apt full-upgrade # or maybe: apt dist-upgrade before re-doing the 'do-release-upgrade'. (IF a previous do-release-upgrade broke, or an attempt was made to upgrade the system in a different way, the system might be in a pretty bad shape and difficult to fix. And 'sudo apt-get install --fix-broken' might be needed or even a forceful remove of a wrong package. Hence, as long as you have access to this system, backup any important data!) ** Changed in: ubuntu-z-systems Status: New => Incomplete ** Changed in: pam (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1977493 Title: Upgrade from Ubuntu 21.10 to 22.04 fails - unmet dependencies: libpam- modules Status in Ubuntu on IBM z Systems: Incomplete Status in pam package in Ubuntu: Incomplete Bug description: ---Problem Description--- Upgrade from Ubuntu 21.10 to 22.4 fails I run do-release-upgrade and I got a message upgrade completed with errors. I rebooted the server and it is now in an undefined state between 21.10 and 22.04. Not all packages have been installed. I attach apt log and output of some commands: root@tuxmaker:~# cat /etc/os-release PRETTY_NAME="Ubuntu 21.10" NAME="Ubuntu" VERSION_ID="21.10" VERSION="21.10 (Impish Indri)" VERSION_CODENAME=impish ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=impish root@tuxmaker:~# do-release-upgrade Checking for a new Ubuntu release Please install all available updates for your release before upgrading. root@tuxmaker:~# apt dist-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: libpam-modules : PreDepends: libpam-modules-bin (= 1.3.1-5ubuntu11) but 1.4.0-11ubuntu2 is installed
[Touch-packages] [Bug 1977493] Re: Upgrade from Ubuntu 21.10 to 22.04 fails - unmet dependencies: libpam-modules
Well, it's a bit difficult to give remote recommendation for a system in this state. (Ideally I want to login to it by myself ...) It would be good to know how many of the installed packages are still packages from impish, and how many already from jammy. One, may try to move forward to jammy (and forcing it), but I think it's better to be careful and go one step back first of all. So I would replace all occurrences of jammy in /etc/apt/sources.list back to impish and do an 'apt clean' and 'apt update'. Now I provoked a /similar/ situation like yours by manually downloading the jammy package and force installing it: $ wget http://launchpadlibrarian.net/592653998/libpam-modules- bin_1.4.0-11ubuntu2_s390x.deb $ sudo dpkg -i --force-depends ./libpam-modules-bin_1.4.0-11ubuntu2_s390x.deb (Reading database ... 83842 files and directories currently installed.) Preparing to unpack .../libpam-modules-bin_1.4.0-11ubuntu2_s390x.deb ... Unpacking libpam-modules-bin (1.4.0-11ubuntu2) over (1.3.1-5ubuntu11) ... Setting up libpam-modules-bin (1.4.0-11ubuntu2) ... Processing triggers for man-db (2.9.4-2) ... After that apt full-upgrade shows the same error like on your system: $ sudo apt full-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: libpam-modules : PreDepends: libpam-modules-bin (= 1.3.1-5ubuntu11) but 1.4.0-11ubuntu2 is installed Recommends: update-motd but it is not installed E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Now - since we want to go back to impish - the opposite can be done to solve the situation, means forcing the installation of the impish package: $ wget http://launchpadlibrarian.net/558628390/libpam-modules- bin_1.3.1-5ubuntu11_s390x.deb $ sudo dpkg -i --force-depends ./libpam-modules-bin_1.3.1-5ubuntu11_s390x.deb dpkg: warning: downgrading libpam-modules-bin from 1.4.0-11ubuntu2 to 1.3.1-5ubuntu11 (Reading database ... 83840 files and directories currently installed.) Preparing to unpack .../libpam-modules-bin_1.3.1-5ubuntu11_s390x.deb ... Unpacking libpam-modules-bin (1.3.1-5ubuntu11) over (1.4.0-11ubuntu2) ... Setting up libpam-modules-bin (1.3.1-5ubuntu11) ... Processing triggers for man-db (2.9.4-2) ... After that apt is happy again: $ sudo apt full-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: apport-symptoms eatmydata libavahi-core7 libdaemon0 libeatmydata1 libregexp-assemble-perl libwrap0 python3-debconf python3-jinja2 python3-json-pointer python3-jsonpatch python3-jsonschema python3-markupsafe python3-pyrsistent python3-systemd squashfs-tools Use 'sudo apt autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. (Please notice that forcing packages is usually a bad idea and can break the packaging system, and should only be done with caution and in rare corner cases!) And it could be that more packages are affected and in such a 'limbo' state, so further steps like this might be needed. Once apt doesn't report further issues, and a sudo apt update && sudo apt full-upgrade runs fine and you ideally restarted the system afterwards, it might be the time for a new "do-release-upgrade' ideally in a screen session, in case the connection breaks and to save the output). (But please think about a backup before doing all this ) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1977493 Title: Upgrade from Ubuntu 21.10 to 22.04 fails - unmet dependencies: libpam- modules Status in Ubuntu on IBM z Systems: Incomplete Status in pam package in Ubuntu: Incomplete Bug description: ---Problem Description--- Upgrade from Ubuntu 21.10 to 22.4 fails I run do-release-upgrade and I got a message upgrade completed with errors. I rebooted the server and it is now in an undefined state between 21.10 and 22.04. Not all packages have been installed. I attach apt log and output of some commands: root@tuxmaker:~# cat /etc/os-release PRETTY_NAME="Ubuntu 21.10" NAME="Ubuntu" VERSION_ID="21.10" VERSION="21.10 (Impish Indri)" VERSION_CODENAME=impish ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=impish root@tuxmaker:~# do-release-upgrade Checking for a new Ubuntu release Please install all available updates for your release before upgrading. root@tuxmaker:~# apt dist-
[Touch-packages] [Bug 1978129] Re: Incomplete support for DT_RELR relocations on Ubuntu 22.04
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) ** Changed in: ubuntu-power-systems Importance: Undecided => Medium ** Changed in: glibc (Ubuntu) Importance: Undecided => Medium ** Package changed: glibc (Ubuntu) => binutils (Ubuntu) ** Also affects: binutils (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: binutils (Ubuntu Kinetic) Importance: Medium Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) Status: New -- 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: New Status in binutils package in Ubuntu: New Status in binutils source package in Jammy: New Status in binutils source package in Kinetic: New Bug description: == 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 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
** Also affects: binutils (Ubuntu Jammy) Importance: Undecided Status: New -- 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: New Status in binutils package in Ubuntu: New Status in binutils source package in Jammy: New Status in binutils source package in Kinetic: New Bug description: 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
** Description changed:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15 hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
+
+ * On top of this actual zlib fix, there is another patch needed:
+ 'Remove compressBound assertions. (PR #1258)' for htslib.
+
+ * But there is a standalone 'htslib' package version, as well as a
+ htslib version included in (some) 'bedtools' packages.
+ Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
- * Ubuntu jammy, impish and focal are affected.
+ * Ubuntu jammy, impish and focal are affected by the zlib issue.
+
+ * The 'htslib' version '1.13+ds' (as it is part of I, J and K),
+ already includes the patch,
+ hence only htslib '1.10.2' in focal needs to be patched.
+
+ * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
+ requires the patch,
+ but version '2.27.1+dfsg' bedtools in focal does not incl. an
+ embedded htslib, hence does not need to be (actually can't be)
+ patched.
+
+ * Patched version of the affected htslib and bedtools packages
+ are build and also available at this PPA:
+ https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
+
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
Reproduction: z15 only:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
** Also affects: htslib (Ubuntu)
Importance: Undecided
Status: New
** Changed in: htslib (Ubuntu Impish)
Status: New => Invalid
** Changed in: htslib (Ubuntu Jammy)
Status: New => Invalid
** Changed in: bedtools (Ubuntu Focal)
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Patch added:
"debdiff_bedtools_kinetic_from_2.30.0+dfsg-2_to_2.30.0+dfsg-2ubuntu1.patch"
https://bugs.launchpad.net/ubuntu/focal/+source/bedtools/+bug/1961427/+attachment/5597488/+files/debdiff_bedtools_kinetic_from_2.30.0+dfsg-2_to_2.30.0+dfsg-2ubuntu1.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Incomplete
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
New
Status in zlib package in Ubuntu:
Incomplete
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
New
Status in htslib source package in Impish:
Invalid
Status in zlib source package in Impish:
New
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Incomplete
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Patch added:
"debdiff_bedtools_impish_from_2.30.0+dfsg-1_to_2.30.0+dfsg-1ubuntu0.1.patch"
https://bugs.launchpad.net/ubuntu/focal/+source/bedtools/+bug/1961427/+attachment/5597490/+files/debdiff_bedtools_impish_from_2.30.0+dfsg-1_to_2.30.0+dfsg-1ubuntu0.1.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Incomplete
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
New
Status in zlib package in Ubuntu:
Incomplete
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
New
Status in htslib source package in Impish:
Invalid
Status in zlib source package in Impish:
New
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Incomplete
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Patch added:
"debdiff_bedtools_jammy_from_2.30.0+dfsg-2_to_2.30.0+dfsg-2ubuntu0.1.patch"
https://bugs.launchpad.net/ubuntu/focal/+source/bedtools/+bug/1961427/+attachment/5597489/+files/debdiff_bedtools_jammy_from_2.30.0+dfsg-2_to_2.30.0+dfsg-2ubuntu0.1.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Incomplete
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
New
Status in zlib package in Ubuntu:
Incomplete
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
New
Status in htslib source package in Impish:
Invalid
Status in zlib source package in Impish:
New
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Incomplete
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
I would like to proceed on this (to not loose to much time...)
To sum things up:
On top of the actual zlib fix,
there is another patch 'Remove compressBound assertions. (PR #1258)'
needed for htslib.
Unfortunately there is a standalone 'htslib' package,
as well as a htslib version included in (some) 'bedtools' packages.
Both need to be patched.
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. and embedded
htslib, hence does not need to be (actually can't be) patched.
Due to the fact that now in total 3 packages are involved and two libraries
(zlib and htslib, well and the libraries included in bedtools), this will cause
a bigger transition (especially for htslib in focal, and zlib itself on all
affected Ubuntu releases).
(The transition(s) need to be planned here:
https://people.canonical.com/~ubuntu-archive/transitions/index.html)
** Attachment added: "reverse dependencies, gathered on focal.txt"
https://bugs.launchpad.net/ubuntu/focal/+source/bedtools/+bug/1961427/+attachment/5597497/+files/reverse%20dependencies%2C%20gathered%20on%20focal.txt
** Changed in: htslib (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/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Incomplete
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Incomplete
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
New
Status in htslib source package in Impish:
Invalid
Status in zlib source package in Impish:
New
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Incomplete
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, imp
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Thx for the retest!
With that I would go from Incomplete back to In Progress ...
** Changed in: ubuntu-z-systems
Status: Incomplete => In Progress
** Changed in: zlib (Ubuntu)
Status: Incomplete => 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/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
In Progress
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
New
Status in htslib source package in Impish:
Invalid
Status in zlib source package in Impish:
New
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Incomplete
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
the DFLTCC pull request:
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
You are right, these are 'just' fixes w/o ABI changes and I am not aware
(couldn't find) of any cases of static linkages - I apologize.
So fortunately the complexity of this will be far less.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
In Progress
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
New
Status in htslib source package in Impish:
Invalid
Status in zlib source package in Impish:
New
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Incomplete
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
the DFLTCC pull request:
https://github.com/mad
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Just to clarify - only 21.10/impish got dropped.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
In Progress
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
Reproduction: z15 only:
[Touch-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)
** 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 nettle in Ubuntu. https://bugs.launchpad.net/bugs/1959469 Title: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto) Status in Ubuntu on IBM z Systems: New Status in nettle package in Ubuntu: New Bug description: Upgrade nettle to latest version >= 3.7.4 (crypto) Description Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for Crypto Libraries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1978129] Re: Incomplete support for DT_RELR relocations on Ubuntu 22.04
** Changed in: binutils (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: binutils (Ubuntu Kinetic) Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => Canonical Foundations Team (canonical-foundations) ** Changed in: binutils (Ubuntu Jammy) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- 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: New Status in binutils package in Ubuntu: New Status in binutils source package in Jammy: New Status in binutils source package in Kinetic: New Bug description: == 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 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
** Changed in: binutils (Ubuntu Jammy) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: binutils (Ubuntu Kinetic) Importance: Undecided => Medium ** Changed in: binutils (Ubuntu Jammy) Importance: Undecided => Medium -- 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: New Status in binutils package in Ubuntu: New Status in binutils source package in Jammy: New Status in binutils source package in Kinetic: New Bug description: After the announcement support for the official machine name z16 has been added to binutils. Please consider picking up the following patch from 2.37 branch: commit e24d2a2d11008aa363366c1087219f3e3405782a (origin/binutils-2_37-branch, 2.37) IBM zSystems: Add support for z16 as CPU name. So far z16 was identified as arch14. After the machine has been announced we can now add the real name. (cherry picked from commit 69341966def7f6551bc4452684136831d6a6941c) (cherry picked from commit fb4d148004f28494e9fb5d2400a13308d07a7988) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1974115/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
** Description changed: + 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) + IBM zSystems: Add support for z16 as CPU name. + + So far z16 was identified as arch14. After the machine has been + announced we can now add the real name. + + (cherry picked from commit 69341966def7f6551bc4452684136831d6a6941c) + (cherry picked from commit fb4d148004f28494e9fb5d2400a13308d07a7988) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1974115 Title: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16 Status in Ubuntu on IBM z Systems: New Status in binutils package in Ubuntu: New Status in binutils source package in Jammy: New Status in binutils source package in Kinetic: New 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
** Description changed: + 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 - + + Contact Information = Matheus Castanho/mscasta...@ibm.com + ---uname output--- N/A - - Machine Type = N/A - + + Machine Type = N/A + ---Debugger--- A debugger is not configured - + ---Steps to Reproduce--- - git clone git://sourceware.org/git/glibc.git + 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 tool common name: binutils + + The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils - Userspace tool obtained from project website: na - + Userspace tool obtained from project website: na + *Additional Instructions for Matheus Castanho/mscasta...@ibm.com: -Attach ltrace and strace of userspace application. -- 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: New Status in binutils package in Ubuntu: New Status in binutils source package in Jammy: New Status in binutils source package in Kinetic: New 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
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Attachment removed: "reverse dependencies, gathered on focal.txt"
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1961427/+attachment/5597497/+files/reverse%20dependencies%2C%20gathered%20on%20focal.txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
In Progress
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
the DFLTCC pull request:
[Touch-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)
Since the symbol files are a bit tricky in this case (because the incl. arch-specific entries), I'm uploading them here separately, too. ** Attachment added: "updated_symbols.tgz" https://bugs.launchpad.net/ubuntu/+source/nettle/+bug/1959469/+attachment/5603726/+files/updated_symbols.tgz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nettle in Ubuntu. https://bugs.launchpad.net/bugs/1959469 Title: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto) Status in Ubuntu on IBM z Systems: New Status in nettle package in Ubuntu: New Bug description: Upgrade nettle to latest version >= 3.7.4 (crypto) Description Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for Crypto Libraries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)
Here is the debdiff for this version bump (from 3.7.3-1build2_to_3.8-0ubuntu1). ** Patch added: "debdiff_nettle_3.7.3-1build2_to_3.8-0ubuntu1.diff" https://bugs.launchpad.net/ubuntu/+source/nettle/+bug/1959469/+attachment/5603732/+files/debdiff_nettle_3.7.3-1build2_to_3.8-0ubuntu1.diff ** Changed in: nettle (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 nettle in Ubuntu. https://bugs.launchpad.net/bugs/1959469 Title: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto) Status in Ubuntu on IBM z Systems: In Progress Status in nettle package in Ubuntu: In Progress Bug description: Upgrade nettle to latest version >= 3.7.4 (crypto) Description Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for Crypto Libraries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1978129] Re: Incomplete support for DT_RELR relocations on Ubuntu 22.04
** Changed in: ubuntu-power-systems Status: New => In Progress -- 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: In Progress Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: In Progress 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 1974115] Re: [UBUNTU 22.04] BINUTILS: Adding new platform name IBM z16
** 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 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: In Progress Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: In Progress 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 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)
** Bug watch added: Debian Bug tracker #1015346 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015346 ** Also affects: nettle (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015346 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nettle in Ubuntu. https://bugs.launchpad.net/bugs/1959469 Title: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto) Status in Ubuntu on IBM z Systems: In Progress Status in nettle package in Ubuntu: In Progress Status in nettle package in Debian: Unknown Bug description: Upgrade nettle to latest version >= 3.7.4 (crypto) Description Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for Crypto Libraries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Since the zlib package progressed meanwhile due to a security update, I
created new debdiffs for jammy and kinetic - see debdiffs_J_K.tar.gz.
** Attachment added: "zlib debdiffs for jammy and kinetic (latest)"
https://bugs.launchpad.net/ubuntu/+source/htslib/+bug/1961427/+attachment/5604504/+files/debdiffs_J_K.tar.gz
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
In Progress
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
zlib debdiffs for kinetic, jammy and focal (latest, with proper dep3)
** Patch removed: "zlib debdiffs for jammy and kinetic (latest)"
https://bugs.launchpad.net/ubuntu/+source/htslib/+bug/1961427/+attachment/5604504/+files/debdiffs_J_K.tar.gz
** Attachment added: "zlib debdiffs for kinetic, jammy and focal (latest)"
https://bugs.launchpad.net/ubuntu/+source/htslib/+bug/1961427/+attachment/5604515/+files/debdiffs_K_J_F.tar.gz
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
New
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
In Progress
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DF
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
I've noticed that the updated zlib for kinetic just landed in -proposed:
"zlib | 1:1.2.11.dfsg-2ubuntu10 | kinetic-proposed"
hence I'm updating the corresponding entry to Fix Committed.
** Changed in: zlib (Ubuntu)
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:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Committed
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated
[Touch-packages] [Bug 1983128] [NEW] linux-lowlatency fals to build on arm64 due to kernel option settings
Public bug reported:
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)
** Affects: linux-lowlatency (Ubuntu)
Importance: High
Assignee: Canonical Kernel Team (canonical-kernel-team)
Status: New
** Affects: zlib (Ubuntu)
Importance: Undecided
Status: New
** Tags: kinetic update-excuse
** Attachment added: "log.gz"
https://bugs.launchpad.net/bugs/1983128/+attachment/5605906/+files/log.gz
** Also affects: zlib (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
- The 'linux-lowlatency' kernel build (incl. autopkgtest) was triggered in a
kinetic-proposed migration process (for zlib) and runs into a 'regression'.
+ 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: 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)
+ 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?]:
+ 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)
--
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 fals to build on arm64 due to kernel option settings
Status in linux-lowlatency package in Ubuntu:
New
Status in zlib package in Ubuntu:
New
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', 's3
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
zlib 1:1.2.11.dfsg-2ubuntu10 is stuck in kinetic-proposed for some time:
http://people.canonical.com/~ubuntu-archive/proposed-
migration/kinetic/update_excuses.html#zlib
https://wiki.ubuntu.com/ProposedMigration
Several of the initial regressions were due to timeouts and network
issues and are solved meanwhile. Two (red) regressions are left (aot):
I opened LP#1983128 for:
"autopkgtest for linux-lowlatency/5.19.0-1001.1: amd64: Pass, arm64: Regression
♻"
and due to:
"autopkgtest for libbio-samtools-perl/1.43-3build2: amd64: Pass, arm64: Pass,
armhf: Pass, ppc64el: Pass, s390x: Regression ♻"
I re-ran the autopkgtest (using LXD) for libbio-samtools-perl explicitly on
s390x (using the zlib PPA) which worked fine for me (see attachemnt),
hence I'm going to ask for a re-run. (I don't have permissions yet to
re-trigger it myself.)
(While looking into libbio-samtools-perl and other related packages, I
found that there is yet another htslib bundled in tabix - which is not
great. But this at at least already the needed patch.)
** Attachment added: "autopkgtest_local_for_libbio-samtools-perl.txt"
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1961427/+attachment/5605907/+files/autopkgtest_local_for_libbio-samtools-perl.txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Committed
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J an
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Looks like libbam-dev is the reason for the libbio-samtools-perl regression
on s390x. libbam-dev is used by libbio-samtools-perl and build based on it's
source package samtools-legacy, which includes another version of bgzf,
that misses the 'Remove compressBound assertions' (PR #1258) fix.
Problematic is that the code differs quite a bit from the one in the htslib
or bedtools package (no bgzf_hopen etc. - looks pretty much out of date),
so the PR does not apply cleanly.
According to upstream 'https://github.com/lh3/samtools-legacy' the project
is "For testing only." and marked as "DON'T USE!" and it's last update
is from Nov 9, 2013.
I've created a separate 'update-excuse' but for this: LP#1983255
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Committed
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description
[Touch-packages] [Bug 1983128] Re: linux-lowlatency fals to build on arm64 due to kernel option settings
So yes, this is a new feature / kernel option for (arm only) introduced with
the migration to gcc 12:
[v3,1/2] AARCH64: Add gcc Shadow Call Stack support
https://patchwork.kernel.org/project/linu
x-hardening/patch/20220303074323.86282-1-ashim...@linux.alibaba.com/#24774364
--
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 fals to build on arm64 due to kernel option settings
Status in linux-lowlatency package in Ubuntu:
New
Status in zlib package in Ubuntu:
New
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 1961427] Re: zlib: compressBound() returns an incorrect result on z15
There is now a solution for LP#1983255.
Meanwhile I've noticed that gdcm is now flagged as a new regression for
zlib's proposed miration at 'update excuses' (was not the case before).
Found that this happened on Debian too:
https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1863513.html
(with exactly the same error:
https://ci.debian.net/data/autopkgtest/testing/s390x/g/gdcm/23826805/log.gz)
but seems to be solved meanwhile: https://qa.debian.org/excuses.php?package=gdcm
So can obviously be solved by an update from (Ubuntu) 3.0.13-2 to (Debian)
3.0.13-3 (sync),
( according to changelog:
https://metadata.ftp-master.debian.org/changelogs//main/g/gdcm/gdcm_3.0.13-3_changelog
)
Just noticed that it was already synched a few hours ago:
"3.0.13-3 release (universe) 19 hours ago"
(https://launchpad.net/ubuntu/+source/gdcm)
So I assume it's a matter of time until update-excuses reflects this
gdcm update and get's again rid of the regression.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Committed
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
New
Status in zlib source package in Focal:
New
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib,
[Touch-packages] [Bug 1982841] Re: [22.10 FEAT] [SEC2210] p11-kit: add IBM specific mechanisms and attributes (crypto)
The requested commits/patches were added and test packages '0.24.1-1ubuntu1' were build in PPA: https://launchpad.net/~fheimes/+archive/ubuntu/lp1982841/+packages The builds also trigger intensive tests, that were all successful: Testsuite summary for p11-kit 0.24.1 # TOTAL: 762 # PASS: 762 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 (https://launchpadlibrarian.net/616683202/buildlog_ubuntu-kinetic-s390x.p11-kit_0.24.1-1ubuntu1_BUILDING.txt.gz) Attaching a debdiff for kinetic as patch. ** Patch added: "debdiff p11-kit kinetic from 0.24.1-1 to 0.24.1-1ubuntu1" https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/1982841/+attachment/5607146/+files/debdiff_p11-kit_kinetic_from_0.24.1-1_to_0.24.1-1ubuntu1.diff ** Changed in: p11-kit (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) ** Changed in: p11-kit (Ubuntu) Status: New => In Progress ** Changed in: ubuntu-z-systems Status: New => In Progress ** 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 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: In Progress Status in p11-kit package in Ubuntu: In Progress 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 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Regarding zlib focal-proposed migration:
For libbio-samtools-perl it's the same situation like on kinetic.
samtools-legacy requires the PR #1258, and libbio-samtools-perl a rebuild (to
link against the new libbio-dev). See update-excuse bug LP#1983255.
On top vcftools misses the 'Remove compressBound assertions' (PR #1258) fix as
well.
I created a separate update-execuse bug LP#1983867.
The mentioned issue with htslib/1.10.2-3 is because the patched htslib
1.10.2-3ubuntu0.1 (that again incl. PR #1258) is needed:
https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#htslib
This htslib 1.10.2-3ubuntu0.1 will at least solve kallisto, libtabixpp
and probably samtools as well.
The isues with the kernels linux-hwe-5.11, linux-hwe-5.13 and linux-
hwe-5.15 are all time outs on arm64, resspectively amrhf builds. So it's
worth to retrigger these.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Committed
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
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:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
[Touch-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)
Meanwhile libnettle8 3.8.1-2 landed in kinetic-proposed, hence updating status to Fix Committed. (thx to Magnus Holmgren) ** Changed in: nettle (Ubuntu) Status: In Progress => Fix Committed ** 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 nettle in Ubuntu. https://bugs.launchpad.net/bugs/1959469 Title: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto) Status in Ubuntu on IBM z Systems: Fix Committed Status in nettle package in Ubuntu: Fix Committed Status in nettle package in Debian: New Bug description: Upgrade nettle to latest version >= 3.7.4 (crypto) Description Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for Crypto Libraries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)
libnettle8 3.8.1-2 finally landed in kinetic, hence updating the status to Fix Released and closing this ticket. ** Changed in: nettle (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 nettle in Ubuntu. https://bugs.launchpad.net/bugs/1959469 Title: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto) Status in Ubuntu on IBM z Systems: Fix Released Status in nettle package in Ubuntu: Fix Released Status in nettle package in Debian: New Bug description: Upgrade nettle to latest version >= 3.7.4 (crypto) Description Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for Crypto Libraries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1987062] [NEW] console-setup.sh is causing setfont: ERROR kdfontop.c: put_font_piofontx: ioctl(PIO_FONTX)
Public bug reported: On 22.04.1 I've noticed the following error in systlog: Aug 16 06:19:15 s1lp10 console-setup.sh[783]: setfont: ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: Inappropriate ioctl for device Aug 16 06:19:15 s1lp10 console-setup.sh[786]: setfont: ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: Inappropriate ioctl for device (It happened for me on a s390x system, but I saw at least one report of it on amd64 in March 2022 [https://forum.ubuntu- fr.org/viewtopic.php?id=2070514], hence I believe it's not architecture specific). ** Affects: console-setup (Ubuntu) Importance: Medium Assignee: Canonical Foundations Team (canonical-foundations) Status: New ** Tags: jammy s390x ** Tags added: jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to console-setup in Ubuntu. https://bugs.launchpad.net/bugs/1987062 Title: console-setup.sh is causing setfont: ERROR kdfontop.c: put_font_piofontx: ioctl(PIO_FONTX) Status in console-setup package in Ubuntu: New Bug description: On 22.04.1 I've noticed the following error in systlog: Aug 16 06:19:15 s1lp10 console-setup.sh[783]: setfont: ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: Inappropriate ioctl for device Aug 16 06:19:15 s1lp10 console-setup.sh[786]: setfont: ERROR kdfontop.c:266 put_font_piofontx: ioctl(PIO_FONTX): 512,8x16: failed: Inappropriate ioctl for device (It happened for me on a s390x system, but I saw at least one report of it on amd64 in March 2022 [https://forum.ubuntu- fr.org/viewtopic.php?id=2070514], hence I believe it's not architecture specific). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1987062/+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)
Had to re-upload the debdiff - now with fixed URLs in the Origin, section of the DEP3 header. (Notice the prefix 'new_' in the new version ...) ** Patch added: "new_debdiff_p11-kit_kinetic_from_0.24.1-1_to_0.24.1-1ubuntu1.diff" https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/1982841/+attachment/5610777/+files/new_debdiff_p11-kit_kinetic_from_0.24.1-1_to_0.24.1-1ubuntu1.diff -- 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: In Progress Status in p11-kit package in Ubuntu: In Progress 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 1978129] Re: Incomplete support for DT_RELR relocations on Ubuntu 22.04
** Changed in: ubuntu-power-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/1978129 Title: Incomplete support for DT_RELR relocations on Ubuntu 22.04 Status in The Ubuntu-power-systems project: Fix Committed Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Committed Status in binutils source package in Kinetic: Fix Released Bug description: SRU Justification: == [Impact] * The latest glibc uses DT_RELR relocations, but it turned out that the linker support is still incomplete, as of binutils-2.38-3ubuntu1 on Ubuntu 22.04. * It lacks the fix/commit 'PowerPC64 DT_RELR relative reloc addresses'. * As discussed at the binutils mailing list: https://sourceware.org/pipermail/binutils/2022-March/119921.html this fixes several (glibc) regressions (from 574 to 17). * Instead of stashing r_offset final address calculations in ppc64_elf_size_stubs for use by ppc64_elf_build_stubs, section/offset pairs need to be kept. [Test Plan] * Build and run the official (make) check: git clone git://sourceware.org/git/glibc.git mkdir build && cd build ../glibc/configure --prefix=/usr && make -j8 && make check [Where problems could occur] * In case relr_addr is not replaced everywhere it's deletion in elf64-ppc.c can cause problems, which will mainly occur at build time. * The relr section/offset array may lead to problems if the array is not properly handled or used. * The rewrite of append_relr_off may cause issues due to wrong allocs erroneous pointer arithmetic or array handling. * The entirely new sort_relr function may introduce new code issues or performance issues. * The adjustments of ppc64_elf_size_stubs and ppc64_elf_build_stubs to the new relr code could be done wrong in which case the linker support is still not working. * But the patch was discussed at the upstream mailing list: https://sourceware.org/pipermail/binutils/2022-March/thread.html#119921 * and is limited to ppc, and even to file 'elf64-ppc.c'. __ == Comment: #0 - Matheus Salgueiro Castanho - 2022-06-09 09:32:29 == ---Problem Description--- Latest glibc uses DT_RELR relocations, but linker support is incomplete as of binutils-2.38-3ubuntu1 on Ubuntu 22.04. It lacks the following fix integrated into the upstream 2.38 branch: PowerPC64 DT_RELR relative reloc addresses https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e4a35c7319628045302d4c597cb27f1b0a08c858 As mentioned in the binutils mailing list when this patch was discussed, this fixes several glibc regressions: https://sourceware.org/pipermail/binutils/2022-March/119921.html Contact Information = Matheus Castanho/mscasta...@ibm.com ---uname output--- N/A Machine Type = N/A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- git clone git://sourceware.org/git/glibc.git mkdir build && cd build ../glibc/configure --prefix=/usr && make -j8 && make check Userspace tool common name: binutils The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils Userspace tool obtained from project website: na *Additional Instructions for Matheus Castanho/mscasta...@ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1978129/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 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
[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 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 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Thx Iliya! (updating tag accordingly)
** Tags removed: verification-needed verification-needed-focal
verification-needed-jammy
** Tags added: verification-done verification-done-focal verification-done-jammy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Released
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
Fix Committed
Status in zlib source package in Focal:
Fix Committed
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
Fix Committed
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Fix Committed
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Changed in: ubuntu-z-systems
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Released
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
Fix Committed
Status in zlib source package in Focal:
Fix Committed
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
Fix Released
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Fix Released
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e73
[Touch-packages] [Bug 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 2075204] Re: gdb on s390x chokes on divide-by-zero from chaos-marmosets
** Tags added: reverse-proxy-bugzilla s390x ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => bugproxy (bugproxy) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/2075204 Title: gdb on s390x chokes on divide-by-zero from chaos-marmosets Status in Ubuntu on IBM z Systems: New Status in gdb package in Ubuntu: New Bug description: To help in the development of apport we're using the chaos-marmosets set of binaries, which triggers various crashes. In particular, we're using /usr/bin/divide-by-zero which does as its name indicates, which naturally triggers a native crash. However, GDB fails on s390x. Note that for the following I have the debugging symbols from ddebs.ubuntu.com installed: ubuntu@glibc-proposed:/tmp$ gdb /usr/bin/divide-by-zero [snip] Reading symbols from /usr/bin/divide-by-zero... Reading symbols from /usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug... (gdb) run Starting program: /usr/bin/divide-by-zero [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Program received signal SIGTRAP, Trace/breakpoint trap. 0x02aa0814 in ?? () (gdb) bt #0 0x02aa0814 in ?? () #1 0x03fff7d2baac in __libc_start_call_main (main=0x2aa0690 , main@entry=, argc=argc@entry=1, argv=argv@entry=0x3ffa468) at ../sysdeps/nptl/libc_start_call_main.h:58 #2 0x03fff7d2bbae in __libc_start_main_impl (main=, argc=1, argv=0x3ffa468, init=, fini=, rtld_fini=0x3fff7f85650 <_dl_fini>, stack_end=0x3ffa3b0) at ../csu/libc-start.c:360 #3 0x02aa0720 in _start () (gdb) info address divide_by_zero Symbol "divide_by_zero" is a function at address 0x2aa0810. (gdb) So at this point GDB isn't capable of identifying the various symbols on the stack, which isn't ideal. Now, if I try to step in: ubuntu@glibc-proposed:/tmp$ gdb -q /usr/bin/divide-by-zero Reading symbols from /usr/bin/divide-by-zero... Reading symbols from /usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug... (gdb) start Temporary breakpoint 1 at 0x690: file divide-by-zero.c, line 29. Starting program: /usr/bin/divide-by-zero [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Temporary breakpoint 1, main (argc=1, argv=0x3ffa468) at divide-by-zero.c:29 warning: 29 divide-by-zero.c: No such file or directory (gdb) s 34 in divide-by-zero.c (gdb) divide_by_zero () at divide-by-zero.c:25 25 in divide-by-zero.c (gdb) /build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. - Backtrace - 0x2aa100a247f ??? 0x2aa104efce5 ??? 0x2aa104eff7f ??? 0x2aa10668c13 ??? 0x2aa102553db ??? 0x2aa10255bd1 ??? 0x2aa10255f5f ??? 0x2aa10259195 ??? 0x2aa1025c315 ??? 0x2aa1025e9a5 ??? 0x2aa10260015 ??? 0x2aa1066951b ??? 0x2aa10669e6d ??? 0x2aa102b01cd ??? 0x2aa102b3607 ??? 0x2aa0ffed839 ??? 0x3ffb142baab __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x3ffb142bbad __libc_start_main_impl ../csu/libc-start.c:360 0x2aa0fff8f8f ??? 0x ??? - /build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) I can provide a core dump if you think that'd help, but it seems trivially reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2075204/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2075567] [NEW] zlib fails to build on s390x on oracular with gcc 14
Public bug reported:
Rebuilding zlib for s390x on oracular fails to build, probably due to
gcc 14 usage (since it became more strict).
Full build log can be found here:
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz
erroneous lines are:
D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13
-mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c
contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but argument
is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but argument
is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but argument
is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but argument
is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but argument
is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but argument
is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but argument
is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16)
unsigned char
contrib/s390/crc32-vx.c:114:52: note: expected ‘__int128 unsigned’ but argument
is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:161:46: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
161 | v1 = (uv2di)vec_gfmsum_accum_128(r5, v1, (uv16qi)v2);
| ^~
| |
| __vector(16) unsigned char
contrib/s390/crc32-vx.c:161:46: no
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
Hi Simon, not yet, but I'm pushing for this ...
** Changed in: ubuntu-z-systems
Importance: High => Critical
** Changed in: ubuntu-z-systems
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2075567
Title:
zlib fails to build on s390x on oracular with gcc 14
Status in Ubuntu on IBM z Systems:
Triaged
Status in zlib package in Ubuntu:
Triaged
Bug description:
Rebuilding zlib for s390x on oracular fails to build, probably due to
gcc 14 usage (since it became more strict).
Full build log can be found here:
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz
erroneous lines are:
D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13
-mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c
contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
|
[Touch-packages] [Bug 2076340] Re: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x
A new upload of the s390-tools package always also requires an upload of the s390-tools-signed package with the same version as well. I've attached the debdiff for it here... ** Also affects: s390-tools-signed (Ubuntu) Importance: Undecided Status: New ** Patch added: "debdiff_s390-tools-signed_noble_from_2.31.0-0ubuntu5_to_2.31.0-0ubuntu5.1.diff" https://bugs.launchpad.net/ubuntu/+source/s390-tools-signed/+bug/2076340/+attachment/5805363/+files/debdiff_s390-tools-signed_noble_from_2.31.0-0ubuntu5_to_2.31.0-0ubuntu5.1.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2076340 Title: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x Status in atlas package in Ubuntu: New Status in bzip2 package in Ubuntu: New Status in containerd-app package in Ubuntu: New Status in curl package in Ubuntu: New Status in cyrus-sasl2 package in Ubuntu: New Status in dbus package in Ubuntu: New Status in docker.io-app package in Ubuntu: New Status in dotnet8 package in Ubuntu: New Status in gnutls28 package in Ubuntu: New Status in golang-1.22 package in Ubuntu: New Status in icu package in Ubuntu: New Status in lapack package in Ubuntu: New Status in libdeflate package in Ubuntu: New Status in libseccomp package in Ubuntu: New Status in libzdnn package in Ubuntu: Fix Released Status in libzstd package in Ubuntu: New Status in lz4 package in Ubuntu: New Status in mysql-8.0 package in Ubuntu: New Status in nettle package in Ubuntu: New Status in openssh package in Ubuntu: New Status in openssl package in Ubuntu: New Status in p11-kit package in Ubuntu: New Status in postgresql-16 package in Ubuntu: New Status in postgresql-common package in Ubuntu: New Status in powerpc-utils package in Ubuntu: Fix Released Status in python-greenlet package in Ubuntu: Fix Released Status in qemu package in Ubuntu: New Status in runc-app package in Ubuntu: Fix Released Status in rustc package in Ubuntu: New Status in s390-tools package in Ubuntu: New Status in s390-tools-signed package in Ubuntu: New Status in systemd package in Ubuntu: New Status in util-linux package in Ubuntu: New Status in xz-utils package in Ubuntu: New Status in zlib package in Ubuntu: New Status in atlas source package in Noble: Fix Committed Status in bzip2 source package in Noble: Fix Committed Status in containerd-app source package in Noble: Fix Committed Status in curl source package in Noble: Fix Committed Status in cyrus-sasl2 source package in Noble: Fix Committed Status in dbus source package in Noble: Fix Committed Status in docker.io-app source package in Noble: Fix Committed Status in dotnet8 source package in Noble: Fix Committed Status in gnutls28 source package in Noble: Fix Committed Status in golang-1.22 source package in Noble: Fix Committed Status in icu source package in Noble: Fix Committed Status in lapack source package in Noble: Fix Committed Status in libdeflate source package in Noble: Fix Committed Status in libseccomp source package in Noble: Fix Committed Status in libzdnn source package in Noble: Fix Committed Status in libzstd source package in Noble: Fix Committed Status in lz4 source package in Noble: Fix Committed Status in mysql-8.0 source package in Noble: Fix Committed Status in nettle source package in Noble: Fix Committed Status in openssh source package in Noble: Fix Committed Status in openssl source package in Noble: Fix Committed Status in p11-kit source package in Noble: Fix Committed Status in postgresql-16 source package in Noble: Fix Committed Status in postgresql-common source package in Noble: Fix Committed Status in powerpc-utils source package in Noble: Fix Committed Status in python-greenlet source package in Noble: Fix Committed Status in qemu source package in Noble: Fix Committed Status in runc-app source package in Noble: Fix Committed Status in rustc source package in Noble: Fix Committed Status in s390-tools source package in Noble: Fix Committed Status in s390-tools-signed source package in Noble: New Status in systemd source package in Noble: Fix Committed Status in util-linux source package in Noble: Fix Committed Status in xz-utils source package in Noble: Fix Committed Status in zlib source package in Noble: Fix Committed Bug description: SRU: no-change rebuild to pick up changed build flags on ppc64el and s390x This is batch of packages that we want to rebuild to pick up the changed build flags on ppc64el (LP: #2064539) and s390x (LP: #2064538). Impact: These are no change uploads on architectures other than ppc64el and s390x. All of those packages already built successful in oracular with the changed build flags. We will validate picking up the changed build flags by inspecting
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
Patch got upstream accepted:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e8a7142a697c5d2673adea33ba23af82a89c9559
It looks to me that it should be picked together with:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a247088adaf122116919235f4a40189506139495
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2075567
Title:
zlib fails to build on s390x on oracular with gcc 14
Status in Ubuntu on IBM z Systems:
Triaged
Status in gcc-14 package in Ubuntu:
New
Status in zlib package in Ubuntu:
Triaged
Bug description:
Rebuilding zlib for s390x on oracular fails to build, probably due to
gcc 14 usage (since it became more strict).
Full build log can be found here:
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz
erroneous lines are:
D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13
-mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c
contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
Thanks iii, just saw this a few minutes ago.
Does it makes sense to also add:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a247088adaf122116919235f4a40189506139495
(seems to be a bit related ...)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2075567
Title:
zlib fails to build on s390x on oracular with gcc 14
Status in Ubuntu on IBM z Systems:
Triaged
Status in gcc-14 package in Ubuntu:
New
Status in zlib package in Ubuntu:
Triaged
Bug description:
Rebuilding zlib for s390x on oracular fails to build, probably due to
gcc 14 usage (since it became more strict).
Full build log can be found here:
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz
erroneous lines are:
D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13
-mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c
contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~~~
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
The fix solves the problem - I tried with a patched gcc-14:
https://launchpad.net/~fheimes/+archive/ubuntu/lp2073786/+sourcepub/16401085/+listing-archive-extra
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2075567
Title:
zlib fails to build on s390x on oracular with gcc 14
Status in Ubuntu on IBM z Systems:
Triaged
Status in gcc-14 package in Ubuntu:
New
Status in zlib package in Ubuntu:
Triaged
Bug description:
Rebuilding zlib for s390x on oracular fails to build, probably due to
gcc 14 usage (since it became more strict).
Full build log can be found here:
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz
erroneous lines are:
D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13
-mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c
contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
|
[Touch-packages] [Bug 2075567] Re: zlib fails to build on s390x on oracular with gcc 14
** Changed in: ubuntu-z-systems
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2075567
Title:
zlib fails to build on s390x on oracular with gcc 14
Status in Ubuntu on IBM z Systems:
Fix Released
Status in gcc-14 package in Ubuntu:
Fix Released
Status in zlib package in Ubuntu:
Invalid
Bug description:
Rebuilding zlib for s390x on oracular fails to build, probably due to
gcc 14 usage (since it became more strict).
Full build log can be found here:
https://launchpadlibrarian.net/741961061/buildlog_ubuntu-oracular-s390x.zlib_1%3A1.3.dfsg-3.1ubuntu4_BUILDING.txt.gz
erroneous lines are:
D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DHAVE_IFUNC -DHAVE_S390X_VX -march=z13
-mzarch -c -o crc32-vx.o contrib/s390/crc32-vx.c
contrib/s390/crc32-vx.c: In function ‘crc32_le_vgfm_16’:
contrib/s390/crc32-vx.c:91:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
91 | v1 = (uv2di)vec_gfmsum_accum_128(r2r1, v1, part1);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:91:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:92:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
92 | v2 = (uv2di)vec_gfmsum_accum_128(r2r1, v2, part2);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:92:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:93:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
93 | v3 = (uv2di)vec_gfmsum_accum_128(r2r1, v3, part3);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:93:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:94:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
94 | v4 = (uv2di)vec_gfmsum_accum_128(r2r1, v4, part4);
|^
||
|uv16qi {aka
__vector(16) unsigned char}
contrib/s390/crc32-vx.c:94:52: note: expected ‘__int128 unsigned’ but
argument is of type ‘uv16qi’ {aka ‘__vector(16) unsigned char’}
contrib/s390/crc32-vx.c:105:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
105 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:105:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:106:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
106 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v3);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:106:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:107:48: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
107 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v4);
|^~
||
|__vector(16) unsigned
char
contrib/s390/crc32-vx.c:107:48: note: expected ‘__int128 unsigned’ but
argument is of type ‘__vector(16) unsigned char’
contrib/s390/crc32-vx.c:114:52: error: incompatible type for argument 3 of
‘__builtin_s390_vgfmag’
114 | v1 = (uv2di)vec_gfmsum_accum_128(r4r3, v1, (uv16qi)v2);
|^~
||
|
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Changed in: ubuntu-z-systems Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: Fix Released Status in s390-tools package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in s390-tools source package in Oracular: Fix Released Status in systemd source package in Oracular: Fix Released Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corresponding udev rule not
[Touch-packages] [Bug 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
** 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 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 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] 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 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
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 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
** Description changed:
+ SRU Justification:
+ --
+
+ [ Impact ]
+
+ * zlib version 1.2.13, as well as patched zlib versions 1.2.11 with
+the patch from LP#1990379, break libxml2 and lxml on s390x.
+
+ * The problem appears during loading a gzipped XML file.
+
+ * Disabling hw compression with 'export DFLTCC=0' solves this,
+hence it's a problem with the hardware acceleration patches DFLTCC.
+
+ * For more info see:
+ https://bugzilla.redhat.com/show_bug.cgi?id=2155328
+
+ [ Test Plan ]
+
+ * Steps to Reproduce:
+1. echo "" > file.xml
+2. gzip file.xml
+3. python3
+>>> import libxml2
+>>> libxml2.parseFile("file.xml.gz")
+
+ * Actual results:
+file.xml.gz:1: parser error : Document is empty
+^
+Traceback (most recent call last):
+ File "", line 1, in
+ File "/usr/lib/python3.11/site-packages/libxml2.py",
+ line 1362, in parseFile
+if ret is None:raise parserError('xmlParseFile() failed')
+ ^^
+libxml2.parserError: xmlParseFile() failed
+
+ * Expected results:
+Loaded file.
+
+ [ Where problems could occur ]
+
+ * Since this is limited to s390x and DFLTCC / hw acceleration active,
+any possible problems are limited to such environments.
+
+ * Fix can be broken if the state handling (state->wrap),
+or the states mixed.
+
+ * The translation from stream to parameter block could be broken
+(again due to wrong states) and the inflate as well.
+
+ [ Other Info ]
+
+ * The official upstream fix is here:
+https://github.com/zlib-ng/zlib-ng/pull/1390
+but it's for zlib-ng.
+
+ * For zlib this needs to be adjusted and was done by the author here:
+https://launchpadlibrarian.net/641454325/patch-1.2.11
+
+ * And again slightly adjusted by me (renamed, some white-space fixes
+and conversion into a quilt patch with proper dep3 header):
+https://launchpadlibrarian.net/645435847/1390.patch
+
+ * The zlib version in Focal, Jammy, Kinetic and Lunar are affected.
+ __
+
It has been reported that 1.2.13 as well as the patch from LP#1990379 breaks
libxml2 (and libxml) on s390x:
(https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch
should fix the issue.
The upstream author proposed a fix and a new test for zlib-ng
(https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such
breakages in the future.
___
This was initially reported as part of LP#1990379,
especially:
https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1990379/comments/12
but needs a separate LP bug (number) - this one.
___
The proposed patch at https://launchpadlibrarian.net/641454325/patch-1.2.11
needed some tweaks regarding white-spaces, but then applied fine on focal,
jammy, kinetic and also 1.2.13, which is what we currently have in
lunar-proposed.
** Also affects: zlib (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: zlib (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: zlib (Ubuntu Kinetic)
Importance: Undecided
Status: New
** Also affects: zlib (Ubuntu Lunar)
Importance: High
Status: New
** Changed in: ubuntu-z-systems
Status: New => Triaged
** Changed in: zlib (Ubuntu Lunar)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/2002511
Title:
zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
Status in Ubuntu on IBM z Systems:
Triaged
Status in zlib package in Ubuntu:
In Progress
Status in zlib source package in Focal:
New
Status in zlib source package in Jammy:
New
Status in zlib source package in Kinetic:
New
Status in zlib source package in Lunar:
In Progress
Bug description:
SRU Justification:
--
[ Impact ]
* zlib version 1.2.13, as well as patched zlib versions 1.2.11 with
the patch from LP#1990379, break libxml2 and lxml on s390x.
* The problem appears during loading a gzipped XML file.
* Disabling hw compression with 'export DFLTCC=0' solves this,
hence it's a problem with the hardware acceleration patches DFLTCC.
* For more info see:
https://bugzilla.redhat.com/show_bug.cgi?id=2155328
[ Test Plan ]
* Steps to Reproduce:
1. echo "" > file.xml
2. gzip file.xml
3. python3
>>> import libxml2
>>> libxml2.parseFile("file.xml.gz")
* Actual results:
file.xml.gz:1: parser error : Document is empty
^
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.11/site-packages/libxml2.py",
line 1362, in parseFile
if ret is None:raise parserError('xmlParseFile() failed')
^^
libxml2.parserError: xml
[Touch-packages] [Bug 2002511] Re: zlib 1.2.13 (and patched 1.2.11) breaks libxml(2) on s390x
** 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 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 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
** 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 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 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 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Package changed: linux (Ubuntu) => s390-tools (Ubuntu) ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-z-systems Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corres
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
This was implemented around 2020, mainly to catch any ccw config changes in a user friendly way: https://bugs.launchpad.net/bugs/1892367 https://i527439087.restricted.launchpadlibrarian.net/527439087/20f6c87a-829f-11eb-9412-002481e91f22.txt?token=zC4n7TlCmffBDHm9Dl002PsfchDXC3Dk Regarding: "1) Have the generic udev initramfs script not copy zdev-generated Udev rules," we need to be super careful here to not break stuff ... How to best identify the zdev-generated Udev rules, since these are not all the rules generated by chzdev (indicated by first line in rule), are they? I'm not very sure if initramfs(-tools) maintainer(s) are very happy ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution.
[Touch-packages] [Bug 2044104] Re: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set
** Changed in: s390-tools (Ubuntu) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Medium ** Changed in: ubuntu-z-systems Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which > make the parameter zdev:early=0 ineffective. Correct? > If you confirm, you may also close this bug. > > Not nice - then we have to find an alternate solution. chzdev -p on Ubuntu will by default rebuild the initrd. This is intended behavior by Canonical and controlled by the ZDEV_ALWAYS_UPDATE_INITRD build-time switch. You can suppress it by adding option --no-root-update to the command line. Specifying zdev:early=0 to chzdev has exactly the effect that it is supposed to have: it tells zdev not to enable that device during initrd processing, resulting in the corresponding ud
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Excuse me for chiming in so late, but we can test (and even recreate) the situation by ourselves on our system (and we have systems with attached crypto hw to it). I just tried it on a jammy z/VM guest: $ lszcrypt -V CARD.DOM TYPE MODESTATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER 02 CEX5C CCA-Coproc online10 11 08 S--D--N-- cex4card 02.0011 CEX5C CCA-Coproc online10 11 08 S--D--N-- cex4queue $ sudo apt-get install libica-utils libica? openssl-ibmca $ sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf $ openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support $ openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ..+++...+*.++...+.++.+..+..+*...+..+..+...+...++.+..++...+...+..+..+.+ ...+..+.+.+*...+..+...++...+...++.+.+...+...+...+*+...+.+..++...+..+..+...+..+.+..+.+.+...++.+.+..+.+...+..+.+.++...+.++..+.+...+...+..+.+...++...+++.+.+..+..+...+..+.+.+.+.+.+..+..++...+..+...+...+..+++..+.+..+.+...+.+.+.+.+.+.+.+.+.+.+++..+..+..+..+.+..+...+..+..++.+..+..+..+...+.+.+...+...+.+.+..+...+..+..+.+ - Segmentation fault (core dumped) $ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. The issue has also been reported independently and with another engine (devcrypto). The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in pri
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
I had the update of the bug description on my todo list - it's done now. ** Description changed: === SRU information === + [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An engine is needed to test the fix and I don't think we have many in the archive. This complicates reproducing the issue. I have been relying on user reports which have been very detailled and helpful. - The issue has also been reported independently and with another engine (devcrypto). - The issue is fixed in openssl 3.0.8 which landed in lunar. + - An openssl engine is req. to test the fix. + - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. + - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. + - Install the needed package that allows to exploit the hw crypto resources: + sudo apt-get install libica-utils libica? openssl-ibmca + - And copy a working sample openssf.cnf file: + sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf + - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: + (dynamic) Dynamic engine loading support + (ibmca) Ibmca hardware engine support <=== + - try to create a new certificate, using this cmd-line: + openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' + - The above command must not lead to a 'Segmentation fault (core dumped)', + rather than create a proper certificate file. + Also watch /var/log/syslog / journalctl for more details. + - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1
[Touch-packages] [Bug 2045250] [NEW] pam_lastlog doesn't handle localtime_r related errors properly
Public bug reported:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314-ll_time = last_login.ll_time;
315:if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) {
316-strftime (the_time, sizeof (the_time),
317-/* TRANSLATORS: "strftime options for date of last
login" */
--
574-
575-lf_time = utuser.ut_tv.tv_sec;
576:tm = localtime_r (&lf_time, &tm_buf);
577-strftime (the_time, sizeof (the_time),
578-/* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
** Affects: pam (Ubuntu)
Importance: Undecided
Status: New
** Affects: pam (Fedora)
Importance: Unknown
Status: Unknown
** Tags: rls-ff-incoming rls-jj-incoming rls-ll-incoming rls-mm-incoming
rls-nn-incoming
** Bug watch added: Red Hat Bugzilla #2012871
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
** Also affects: pam (Fedora) via
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in pam package in Ubuntu:
New
Status in pam package in Fedora:
Unknown
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) {
316- strftime (the_time, sizeof (the_time),
317- /* TRANSLATORS: "strftime options for date of last
login" */
--
574-
575- lf_time = utuser.ut_tv.tv_sec;
576: tm = localtime_r (&lf_time, &tm_buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2045250] Re: pam_lastlog doesn't handle localtime_r related errors properly
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in Ubuntu on IBM z Systems:
New
Status in pam package in Ubuntu:
New
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) {
316- strftime (the_time, sizeof (the_time),
317- /* TRANSLATORS: "strftime options for date of last
login" */
--
574-
575- lf_time = utuser.ut_tv.tv_sec;
576: tm = localtime_r (&lf_time, &tm_buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 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
** Changed in: ubuntu-z-systems
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/2045250
Title:
pam_lastlog doesn't handle localtime_r related errors properly
Status in Ubuntu on IBM z Systems:
New
Status in pam package in Ubuntu:
New
Status in pam package in Fedora:
Fix Released
Bug description:
The pam version(s) in Debian (checked buster) and Ubuntu (checked focal to
noble) are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=2012871
Customers report a command going through PAM crashing for a given user.
A potential follow on issue can be that no ssh remote connections to an
affected server are possible anymore, esp. painful with headless systems (was
reported on a different distro).
This is caused by an issue in modules/pam_lastlog/pam_lastlog.c:
with tm = localtime_r(...) that can be NULL and needs to be handled.
There are two such cases in modules/pam_lastlog/pam_lastlog.c (here noble):
314- ll_time = last_login.ll_time;
315: if ((tm = localtime_r (&ll_time, &tm_buf)) != NULL) {
316- strftime (the_time, sizeof (the_time),
317- /* TRANSLATORS: "strftime options for date of last
login" */
--
574-
575- lf_time = utuser.ut_tv.tv_sec;
576: tm = localtime_r (&lf_time, &tm_buf);
577- strftime (the_time, sizeof (the_time),
578- /* TRANSLATORS: "strftime options for date of last login" */
Case 1 (line 315) is properly handled, but not case 2 (line 576).
The second case got fixed by:
https://github.com/linux-pam/linux-pam/commit/40c271164dbcebfc5304d0537a42fb42e6b6803c
This fix should be included in Ubuntu (and Debian).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2045250/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1833322] Re: Consider removing irqbalance from default install on desktop images
** 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 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
verification on jammy was successful ** Description changed: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: - sudo apt-get install libica-utils libica? openssl-ibmca + sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: - sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: - (dynamic) Dynamic engine loading support - (ibmca) Ibmca hardware engine support <=== + sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf + - Verify if the 'openssl engine' lists an ibmca engine, + in addition to the dynamic engine: + openssl engine + (dynamic) Dynamic engine loading support + (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: - openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' + openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', - rather than create a proper certificate file. - Also watch /var/log/syslog / journalctl for more details. + rather than create a proper certificate file. + Also watch /var/log/syslog / journalctl for more details. + - Upgrade not only the openssl package itself, + but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2)
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Hi Grgo, did you also updated libssl3? see test plan in Description: " - Upgrade not only the openssl package itself, but also libssl3, before verification. " With that I could successfully verify. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Status in openssl source package in Jammy: Fix Committed Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', rather than create a proper certificate file. Also watch /var/log/syslog / journalctl for more details. - Upgrade not only the openssl package itself, but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Since this bug is fixed with openssl 3.0.8 and newer, I'm changing the status of the current devel. release to Fix Released too (since we are there on 3.0.10). And with that the affected project status can be set to Fix Released, too. Thx! ** Changed in: openssl (Ubuntu) Status: In Progress => Fix Released ** Changed in: ubuntu-z-systems Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: Fix Released Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: Fix Released Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug is part of a series of three bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Openssl using an engine dumps core upon certificate creation; other operations are probably affected too. Overall, engines are likely mostly unusable. [Test plan] - An openssl engine is req. to test the fix. - A z13 / LinuxONE LPAR or z/VM guest is needed, with attached APQN. - Check with 'lszcrypt -V' the availability (online) of the hw crypto resources. - Install the needed package that allows to exploit the hw crypto resources: sudo apt-get install libica-utils libica? openssl-ibmca - And copy a working sample openssf.cnf file: sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf - Verify if the 'openssl engine' lists an ibmca engine, in addition to the dynamic engine: openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support <=== - try to create a new certificate, using this cmd-line: openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' - The above command must not lead to a 'Segmentation fault (core dumped)', rather than create a proper certificate file. Also watch /var/log/syslog / journalctl for more details. - Upgrade not only the openssl package itself, but also libssl3, before verification. - The issue is fixed in openssl 3.0.8 which landed in lunar. [Where problems could occur] I don't pretend to understand the lifecycle of providers in openssl3 but the patch is simple and has been widely tested by now, including on ubuntu. Thus, I see little chance an unexpected problem would occur with it. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18578 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy- sru-0001-Release-the-drbg-in-the-global-default-context- befor.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 47
[Touch-packages] [Bug 1925211] Re: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x
** Changed in: ubuntu-z-systems Status: Triaged => Fix Committed -- 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/1925211 Title: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Status in linux source package in Hirsute: Fix Committed Status in systemd source package in Hirsute: Invalid Status in udev source package in Hirsute: Invalid Bug description: SRU Justification [Impact] Hot removal of disks under kvm on s390 does not result in the kernel removing the block device, which can lead to hung tasks and other issues. [Test Plan] See steps to reproduce the bug in the original description below. To test, execute these steps and confirm that the block device gets removed as expected. [Where problems could occur] The fix is a revert of the changes which introduced this regression. The original commit was a removal of supposedly unused code, but it seems a mistake was made in the logic around unregistering of disks. Reverting the changes could have potential to introduce bugs related to other virt devices, especially if it interacts badly with subsequent driver changes. However, the patch reverted cleanly, and reverting restores the code to the state which has been working well in previous kernels and seems like the lowest risk option until a proper fix is available upstream. --- Repro: #1 Get a guest $ uvt-kvm create --disk 5 --password=ubuntu h release=hirsute arch=s390x label=daily $ uvt-kvm wait h release=hirsute arch=s390x label=daily #2 Attach and Detach disk $ sudo qemu-img create -f qcow2 /var/lib/libvirt/images/test.qcow2 10M $ virsh attach-disk h /var/lib/libvirt/images/test.qcow2 vdc $ virsh detach-disk h vdc From libvirts POV it is gone at this point $ virsh domblklist h Target Source -- vda /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs.qcow vdb /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs-ds.qcow But the guest thinks still it is present $ uvt-kvm ssh --insecure hirsute-2nd-zfs lsblk ... vdc252:32 0 20M 0 disk This even remains a while after (not a race). Any access to it in the guest will hang (as you'd expect of a non-existing blockdev) 4 017581739 20 0 12140 4800 - S+ pts/0 0:00 | \_ sudo mkfs.ext4 /dev/vdc 4 017591758 20 0 6924 1044 - D+ pts/0 0:00 | \_ mkfs.ext4 /dev/vdc The result above was originally found with hirsute-guest@hirsute-host on s390x I do NOT see the same with groovy-guest@hirsute-host on s390x I DO see the same with hirsute-guest@groovy-host on s390x => Guest version dependent not Host/Hipervisor dependent I DO see the same with ZFS disks AND LVM disks being added&removed => not type dependent I do NOT see the same on x86. => Arch dependent ?? ... the evidence slowly points towards an issue in the guest, damn we are so close to release - but non-fully detaching disks are critical in my POV :-/ Filing this as-is for awareness, but certainly this will need more debugging. Unsure where this is going to eventually I'll now file it for kernel/udev/systemd. If there are any known issues/components that are related let me know please! --- ProblemType: Bug AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access '/dev/snd/': No such file or directory AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu65 Architecture: s390x ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: N/A CasperMD5CheckResult: unknown DistroRelease: Ubuntu 21.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Lspci-vt: -[:00]- Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Error: command ['lsusb', '-t'] failed with exit code 1: /sys/bus/usb/devices: No such file or directory Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: Package: udev PackageArchitecture: s390x PciMultimedia: ProcFB: ProcKernelCmdLine: root=LABEL=cloudimg-rootfs ProcVersionSignature: User Name 5.11.0-14.15-generic 5.11.12 RelatedPackageVersions: linux-restricted-modules-5.11.0-14-generic N/A linux-backports-modules-5.11.0-14-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: hirsute uec-images Uname: Linux 5.11.0-14-generic s390x UpgradeStatus: No upgrade log pr
[Touch-packages] [Bug 1929825] Re: [Ubuntu 21.04] OSA Device doesn't get enabled if a vlan is specified on the kernel cmdline for the installer
*** This bug is a duplicate of bug 1924794 ***
https://bugs.launchpad.net/bugs/1924794
This is an issue that got already identified and reported (late in the cycle)
during 21.04 testing and is described at LP#1924794 in more detail.
It was unfortunately too late to get it fixed in time for 21.04 GA,
but you will find a fixed initramfs file in LP#1924794 comment #10 that needs
to be used as a replacement for the initfamfs file that is shipped by the ISO
in /boot.
The fix is already included in Impish, too.
Hence I'm marking this LP bug as a duplicate of LP#1924794.
** Changed in: linux (Ubuntu)
Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)
** Changed in: ubuntu-z-systems
Status: New => Fix Released
** Package changed: linux (Ubuntu) => initramfs-tools (Ubuntu)
** Changed in: initramfs-tools (Ubuntu)
Status: New => Fix Released
** This bug has been marked a duplicate of bug 1924794
Getting error "ipconfig: no devices to configure" while trying to
autoinstall in a VLAN env on s390x
--
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/1929825
Title:
[Ubuntu 21.04] OSA Device doesn't get enabled if a vlan is specified
on the kernel cmdline for the installer
Status in Ubuntu on IBM z Systems:
Fix Released
Status in initramfs-tools package in Ubuntu:
Fix Released
Bug description:
The OSA Device doesn't get enabled if a vlan is specified on the
kernel cmdline for the installer.
with the cmdline
`ip=10.1.8.74::10.1.10.1:255.255.252.0::enc800.300:none nameserver=10.1.9.101
vlan=enc800.300:enc800
url=http://10.1.9.101:1002/iso/ubuntu-21.04-live-server-s390x.iso quiet ---`
the boot fails with this message and drops to a shell:
```
BusyBox v1.30.1 (Ubuntu 1:1.30.1-6ubuntu2) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) [6n
ip: SIOCGIFFLAGS: No such device
ip: can't find device 'enc800'
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
no search or nameservers found in /run/net-enc800.300.conf /run/net-*.conf
/run/
net6-*.conf
Connecting to 10.1.9.101:1002 (10.1.9.101:1002)
wget: can't connect to remote host (10.1.9.101): Network is unreachable
Unable to find a live file system on the network
```
It the zdev 800 doesn't get enabled.
```
ip addr
1: lo: mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
(initramfs) [6n
lszdev | grep 0.0.0800
qeth 0.0.0800:0.0.0801:0.0.0802 no no
```
But I can enable it manually:
```
chzdev -e 800
QETH device 0.0.0800:0.0.0801:0.0.0802 configured
Note: The initial RAM-disk must be updated for these changes to take effect:
- QETH device 0.0.0800:0.0.0801:0.0.0802
A manual update of the initial RAM-disk is required.
(initramfs) [6n
ip addr
1: lo: mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enc800: mtu 1500 qdisc noop qlen 1000
link/ether f2:ae:7d:de:88:a0 brd ff:ff:ff:ff:ff:ff
```
The same cmdline (adjusted for the iso url) works on 20.04.
Between 20.04 and 21.04 the line 318 `echo "${VLAN}" | grep -q "${dev}" &&
continue` was added to /scripts/functions in the initrd.ubuntu. If I remove
this line and repack the ramdisk the network boot works as expected like on
ubuntu 20.04
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929825/+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 1929921] Re: Ubuntu 20.04.2 - OPENSSL_cleanse() fails with segmentation fault in eddsa_test
** Package changed: linux (Ubuntu) => openssl (Ubuntu) -- 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/1929921 Title: Ubuntu 20.04.2 - OPENSSL_cleanse() fails with segmentation fault in eddsa_test Status in Ubuntu on IBM z Systems: Invalid Status in openssl package in Ubuntu: Invalid Bug description: ---Problem Description--- === IBM z15 with D41C Bundle S39a and z/VM 7.2.0 guest with crypto cards attached OS: Ubuntu 20.04.2 (focal fossa) with 5.4.0-73-generic and libica 3.6.1 installed Core dump when running the eddsa_test from libica Details === The available openSSL version is: OpenSSL 1.1.1f 31 Mar 2020 The ibmca engine was installed, but not defined into the openssl.cnf file, openssl engine displayed the default line: (dynamic) Dynamic engine loading support The segmentation fault was generated by `./eddsa_test'. Program terminated with signal SIGSEGV, Segmentation fault in openSSL (gdb) bt #0 0x03ff896e50be in OPENSSL_cleanse () from /lib/s390x-linux-gnu/libcrypto.so.1.1 #1 0x03ff898a26fa in ica_ed25519_ctx_del (ctx=0x3fff9b7e010) at ica_api.c:1897 #2 0x02aa28986f14 in ed25519_stress () at eddsa_test.c:441 #3 0x02aa289831bc in main (argc=0x1, argv=0x3fff9b7eaf8) at eddsa_test.c:66 See https://wiki.ubuntu.com/Debug%20Symbol%20Packages about how to define debug repositories apt install libica3-dbgsym #0 0x03ff896e50be in OPENSSL_cleanse () from /lib/s390x-linux-gnu/libcrypto.so.1.1 (gdb) bt # coredumpctl dump 158582 > eddsa.core PID: 158582 (eddsa_test) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Wed 2021-05-26 19:52:28 CEST (15h ago) Command Line: ./eddsa_test Executable: /root/crypto/libica-3.6.1/test/eddsa_test Control Group: /user.slice/user-0.slice/session-9.scope Unit: session-9.scope Slice: user-0.slice Session: 9 Owner UID: 0 (root) Boot ID: 6a7a23240f464a0d9f2d3fa3e82be73e Machine ID: c933ae494f9a4c6e8d82625c952945d5 Hostname: t3514002.lnxne.boe Storage: /var/lib/systemd/coredump/core.eddsa_test.0.6a7a23240f464a0d9f2d3fa3e82be73e.158582.1622051548.lz4 Message: Process 158582 (eddsa_test) of user 0 dumped core. Stack trace of thread 158582: #0 0x03ff896e50be OPENSSL_cleanse (libcrypto.so.1.1 + 0x1650be) ---uname output--- Linux system 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = Manufacturer: IBM Type: 8561 Model:703 T01 ---Debugger--- A debugger was configured, however the system did not enter into the debugger ---Steps to Reproduce--- 1.) install the github libica 3.6.1 package and build the test cases 2.) cd .../libica-3.6.1 3.) ./bootstrap.sh; configure --enable-coverage 4.) make coverage Watch the segmentation fault to happen Userspace tool common name: eddsa_test The userspace tool has the following bit modes: 64bit Userspace rpm: libica3 Userspace tool obtained from project website: na The problem could be reproduced with libica 3.6.1, however, it does not show up with libica 3.8.0. Looks like the problem was fixed by commit https://github.com/opencryptoki/libica/commit/b40d0d2ad4a2aac088cf47befbddd8b3b9fca1c5 After applying this fix on top of 3.6.1, the segfault does not occur anymore. It's sufficient to apply the 4 changes in eddsa_test.c. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929921/+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 1925211] Re: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x
With that we can close the entire bug, since hirsute / 5.11 is now Fix Released (#34), groovy / 5.8 is not affected (#17) and the patches are upstream with 5.13 (#33), hence will end up sooner or later in impish. ** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released ** Changed in: linux (Ubuntu) Status: Fix Committed => 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/1925211 Title: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Status in linux source package in Hirsute: Fix Released Status in systemd source package in Hirsute: Invalid Status in udev source package in Hirsute: Invalid Bug description: SRU Justification [Impact] Hot removal of disks under kvm on s390 does not result in the kernel removing the block device, which can lead to hung tasks and other issues. [Test Plan] See steps to reproduce the bug in the original description below. To test, execute these steps and confirm that the block device gets removed as expected. [Where problems could occur] The fix is a revert of the changes which introduced this regression. The original commit was a removal of supposedly unused code, but it seems a mistake was made in the logic around unregistering of disks. Reverting the changes could have potential to introduce bugs related to other virt devices, especially if it interacts badly with subsequent driver changes. However, the patch reverted cleanly, and reverting restores the code to the state which has been working well in previous kernels and seems like the lowest risk option until a proper fix is available upstream. --- Repro: #1 Get a guest $ uvt-kvm create --disk 5 --password=ubuntu h release=hirsute arch=s390x label=daily $ uvt-kvm wait h release=hirsute arch=s390x label=daily #2 Attach and Detach disk $ sudo qemu-img create -f qcow2 /var/lib/libvirt/images/test.qcow2 10M $ virsh attach-disk h /var/lib/libvirt/images/test.qcow2 vdc $ virsh detach-disk h vdc From libvirts POV it is gone at this point $ virsh domblklist h Target Source -- vda /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs.qcow vdb /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs-ds.qcow But the guest thinks still it is present $ uvt-kvm ssh --insecure hirsute-2nd-zfs lsblk ... vdc252:32 0 20M 0 disk This even remains a while after (not a race). Any access to it in the guest will hang (as you'd expect of a non-existing blockdev) 4 017581739 20 0 12140 4800 - S+ pts/0 0:00 | \_ sudo mkfs.ext4 /dev/vdc 4 017591758 20 0 6924 1044 - D+ pts/0 0:00 | \_ mkfs.ext4 /dev/vdc The result above was originally found with hirsute-guest@hirsute-host on s390x I do NOT see the same with groovy-guest@hirsute-host on s390x I DO see the same with hirsute-guest@groovy-host on s390x => Guest version dependent not Host/Hipervisor dependent I DO see the same with ZFS disks AND LVM disks being added&removed => not type dependent I do NOT see the same on x86. => Arch dependent ?? ... the evidence slowly points towards an issue in the guest, damn we are so close to release - but non-fully detaching disks are critical in my POV :-/ Filing this as-is for awareness, but certainly this will need more debugging. Unsure where this is going to eventually I'll now file it for kernel/udev/systemd. If there are any known issues/components that are related let me know please! --- ProblemType: Bug AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access '/dev/snd/': No such file or directory AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu65 Architecture: s390x ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: N/A CasperMD5CheckResult: unknown DistroRelease: Ubuntu 21.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Lspci-vt: -[:00]- Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Error: command ['lsusb', '-t'] failed with exit code 1: /sys/bus/usb/devices: No such file or directory Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: Package: udev PackageArchitecture: s390x PciMultimedia: ProcFB: ProcKernelCmdLine: root=LABEL=cloudimg-rootfs ProcVersionSignature: User Name 5.11.0-14.15-generic 5.11.12 RelatedPackageVersions: linux-restricted-mo
