April 2025 - openSUSE Z Systems - openSUSE Mailing Lists

Cancellation of openSUSE knowledge sharing session/Meeting - Tuesday 12th November 2024
by Sarah Julia Kriesch 13 May '25

13 May '25

Hello together, I have to cancel our meeting tomorrow because of sickness. I have got a cold with Business without any voice now. Sorry for these circumstances! I am looking forward to seeing you next time again. Best regards, Sarah

1 1

openSUSE knowledge sharing session/Meeting - Tuesday 29th April 2025
by Sarah Julia Kriesch 29 Apr '25

29 Apr '25

Hello together, Today, Tuesday, the 20th April 2025, is the next of our training/meeting sessions. We will meet us at 19:00 (German time)/ 10:00 (Pacific time) on our openSUSE Jitsy: meet.opensuse.org/s390x Topics for this session: 1) Know each other (networking) 2) Graphics bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1233167 * Continuously waiting for bug fix by IBM 3) Updates regarding z17 topic 4) Z Trainings this year (request by a new IBM Developer) 5) Packaging topics 6) Open tasks and questions 7) Q & A I expect, that we will need 1.5 hours. I am looking forward to see you all. :-) Best regards, Sarah P.S. I am in Dresden this time, but the remote session should be no problem from the conference hotel.

1 0

chez-scheme is fixed for s390x - Update available
by Raphael Groner 21 Apr '25

21 Apr '25

2 2

New IBM z17 not supported by openSUSE
by Sarah Julia Kriesch 17 Apr '25

17 Apr '25

Verbatim, Andreas Krebbel said in the bug report: "What, in general, is a good thing to get aware of problems, but also has the consequence of considering a package build to be failing because of testcase bugs." -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hello together, I have received an request by Andreas Krebbel to correct the citation regarding the bugreport for Python Onnx based on a mistake on myside to try to recap the content. He meant, that it has consequences to use clean test suites as a foundation for successful builds for a package. Best regards, Sarah ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hello together, most of you know, that we all have to build and develop for s390x on old z15 systems by IBM. IBM has introduced an AI Hardware Accelerator with z16 [0] as a nice feature besides others, like Confidential Computing and Post-Quantum Cryptography. Last week they had the IBM Z Day with the announcement of the new z17. That is full with AI integrated on the hardware level [1].. I want to create an announcement in the IBM Community with „IBM z17 not supported by the Linux Community“ or as a minimum „IBM z17 not supported by Community Linux Distributions“ based on following facts Last year I started with enabling and testing the AI/ML libraries based on the presentation by Andreas Krebbel [2]. Last year, IBM has published also a Redbook about AI on IBM Z [6]. Basic libraries like numpy did not make any problems. But we have received rounding errors and more with integrating onnx and other libraries on s390x. The interesting statemengt from IBM about build failures by IBM was then: > ------- Comment From Andreas.Krebbel(a)de.ibm.com 2024-06-19 05:37 EDT------- > (In reply to comment #28) > > (In reply to LTC BugProxy from comment #27) > > > (In reply to comment #25) > > > These logs do not indicate actual build failures to me. The builds are done > > > at this point. In both logs I see 16 *testsuite* failures. These are known > > > to us and we are working on it, but I do not see a reason to let the build > > > fail because of that. Once the patches mentioned earlier have been merged we > > > will be down to one fail in our tests. The last remaining fail seems to be > > > triggered by a build issue of the pillow package and not onnx. We will try > > > to address this. > > > > The OBS has got an integrated CI/CD pipeline. Therefore, if too many tests > > (from upstream) are failing, our builds are failing also. You can experience > > that also with Koji at Fedora. > What, in general, is a good thing to get aware of problems, but also has the > consequence of considering a package build to be failing because of testcase > bugs. We should disable our upstream tests for getting successful builds for AI on s390x… I made it also to a topic at our openSUSE Conference. I received an agreement by Dominique not to disable the tests. Aleksandra by Fedora said, that we should say to IBM, that we only support, what is integrated in our Linux distributions and no 3rd Party libraries via pip by IBM (especially for s390x now). If they integrate more AI features without giving us any hardware access for testing, we should say, that the new hardware is not supported. I received the hint from SUSE side, that their Python version had not been compatible for all the upstream enablements. They tried it with libzdnn [3]. Finally, we made the decision that we don’t support AI on openSUSE Leap and SLES as log as SUSE does not receive any feature requests. I was asked, how important AI is on IBM z16, which is not available for the Linux distributions. I have called it a „nice feature“ on z16. I wanted to work in my free time on these Python packages in collaboration with IBM until all is working (besides the default Release Engineering). I did that also upstream and forwarded it via the Linux Distributions Working Group, because all Linux distributions are affected. OneDNN is one example [4]. The IBM Developer does not respond here any more, because he is overloaded also with feature requests and more. And I hadn’t so much time besides my job to create bug reports for all. If you take a look into OBS, the number of failed/unresolvable Python libraries has not been reduced. It has been growing for s390x. After the release announcement of z17 it is the time stamp, where I say, that we should interact with a cut with „not supported as long as we do not receive any hardware upgrade and IBM does not use upstream tests“. I spoke also with the other Linux distributions: Canonical has bought a z16 last year, that they can test the AI features via pip. They have followed only the test specs by IBM, what they expect, how and what should be working. I received the feedback, that they don’t run any upstream tests. I explained the difference between manual smoke tests based on test specs and automated full tests based on upstream projects. My question „What is, if the customer wants to use features of a library, which has not been included into the tests by IBM?“ has opened the eyes and he wanted to drive Upstream First principles in the company. He has left Canonical at the beginning of this year. Red Hat is in a special situation. IBM Developers are developing based on RHEL (KVM Developers are running tests on SLES and Ubuntu afterwards), make smoke tests for AI based on their test specs and publish that all as Python libraries. Therefore, that is the most tested Linux distribution at IBM. But Red Hat has received the same statement as I have got by IBM. They are not allowed to argue against it as a daughter company. Therefore, they made the same statement as I did in my IBM announcement for openSUSE, that the responsibility for AI is on IBM side [5]: "WARNING (related to all Linux distributions on IBM Z & LinuxONE): Linux distributions can not guarantee the functionality of newly developed features related to AI and other things for z16 any more. That is based on missing/incorrect tests on IBM's side and missing z16 systems for Linux distributions for validation. Please create bug reports at IBM if you experience issues with „IBM supported“ open source software on z16, which is not included in our repositories." Fedora is an open source project by Red Hat, but not directly under IBM. Therefore, Fedora is allowed to support our activities via the Linux Distributions Working Group to bring all into the correct direction. But the main responsible persons for s390x and CI are Red Hatters. Therefore, I think about integrating the Fedora Council here, that they can support us based on failed tests in AI libraries and missing hardware. The Debian Project Lead said at Chemnitzer Linuxtage, that he wants to speak with IBM in person about this AI topic and how to bring software to Debian. We as openSUSE can be lucky to have the SUSE CTO and a VP in the openSUSE Board. I have asked also the Project Management via mail for their status yesterday. But I expect, that there is no big change on IBM side, if they didn’t recognize the missing Python compatibility last year already. That is a hint for missing SLES tests for AI. @Gerald and @Jeff: Are you also for the announcement (from SUSE side), that we do not support the new z17 until we receive an hardware upgrade and IBM is integrating upstream tests? You can add additional requirements as a response on this email, what I should write as the (Co-)Chair of the Linux Distributions Working Group. I will setup the announcement after receiving feedback from you and the Enterprise level and send it to the mailing list of the Linux Distributions Working Group for a review next week. Because that should be a common statement. I am allowed to decide it for openSUSE, because the former openSUSE Board has delegated the whole decision for openSUSE on s390x to myself. As the (Co-)Chair of the Linux Distributions Working Group, I want to interact pro all Linux distributions. Therefore, I manke the announcement as a suggestion on the mailing list before publishing it in the IBM community. Respond with feedbak on this email, if you disagree. We are supporting the hardware on what we are developing (z15) with our integrated Python packages on openSUSE Tumbleweed. The announcement should be a signal for IBM. Best regards, Sarah [0] https://community.ibm.com/zsystems/uploads/document/slider/12qs4awwowtp.pdf [1] https://newsroom.ibm.com/z17 [2] https://www.youtube.com/watch?v=_t7O6C0kU1Y [3] https://bugzilla.suse.com/show_bug.cgi?id=1215337#c30 [4] https://github.com/uxlfoundation/oneDNN/issues/2228 [5] https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/sarah-juli… [6] https://www.redbooks.ibm.com/redpapers/pdfs/redp5712.pdf

1 0

New IBM z17 not supported by openSUSE
by Sarah Julia Kriesch 16 Apr '25

16 Apr '25

Hello together, I have received an request by Andreas Krebbel to correct the citation regarding the bugreport for Python Onnx based on a mistake on myside to try to recap the content. He meant, that it has consequences to use clean test suites as a foundation for successful builds for a package. Best regards, Sarah ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hello together, most of you know, that we all have to build and develop for s390x on old z15 systems by IBM. IBM has introduced an AI Hardware Accelerator with z16 [0] as a nice feature besides others, like Confidential Computing and Post-Quantum Cryptography. Last week they had the IBM Z Day with the announcement of the new z17. That is full with AI integrated on the hardware level [1].. I want to create an announcement in the IBM Community with „IBM z17 not supported by the Linux Community“ or as a minimum „IBM z17 not supported by Community Linux Distributions“ based on following facts Last year I started with enabling and testing the AI/ML libraries based on the presentation by Andreas Krebbel [2]. Last year, IBM has published also a Redbook about AI on IBM Z [6]. Basic libraries like numpy did not make any problems. But we have received rounding errors and more with integrating onnx and other libraries on s390x. The interesting statemengt from IBM about build failures by IBM was then: > ------- Comment From Andreas.Krebbel(a)de.ibm.com 2024-06-19 05:37 EDT------- > (In reply to comment #28) > > (In reply to LTC BugProxy from comment #27) > > > (In reply to comment #25) > > > These logs do not indicate actual build failures to me. The builds are done > > > at this point. In both logs I see 16 *testsuite* failures. These are known > > > to us and we are working on it, but I do not see a reason to let the build > > > fail because of that. Once the patches mentioned earlier have been merged we > > > will be down to one fail in our tests. The last remaining fail seems to be > > > triggered by a build issue of the pillow package and not onnx. We will try > > > to address this. > > > > The OBS has got an integrated CI/CD pipeline. Therefore, if too many tests > > (from upstream) are failing, our builds are failing also. You can experience > > that also with Koji at Fedora. > What, in general, is a good thing to get aware of problems, but also has the > consequence of considering a package build to be failing because of testcase > bugs. We should disable our upstream tests for getting successful builds for AI on s390x… I made it also to a topic at our openSUSE Conference. I received an agreement by Dominique not to disable the tests. Aleksandra by Fedora said, that we should say to IBM, that we only support, what is integrated in our Linux distributions and no 3rd Party libraries via pip by IBM (especially for s390x now). If they integrate more AI features without giving us any hardware access for testing, we should say, that the new hardware is not supported. I received the hint from SUSE side, that their Python version had not been compatible for all the upstream enablements. They tried it with libzdnn [3]. Finally, we made the decision that we don’t support AI on openSUSE Leap and SLES as log as SUSE does not receive any feature requests. I was asked, how important AI is on IBM z16, which is not available for the Linux distributions. I have called it a „nice feature“ on z16. I wanted to work in my free time on these Python packages in collaboration with IBM until all is working (besides the default Release Engineering). I did that also upstream and forwarded it via the Linux Distributions Working Group, because all Linux distributions are affected. OneDNN is one example [4]. The IBM Developer does not respond here any more, because he is overloaded also with feature requests and more. And I hadn’t so much time besides my job to create bug reports for all. If you take a look into OBS, the number of failed/unresolvable Python libraries has not been reduced. It has been growing for s390x. After the release announcement of z17 it is the time stamp, where I say, that we should interact with a cut with „not supported as long as we do not receive any hardware upgrade and IBM does not use upstream tests“. I spoke also with the other Linux distributions: Canonical has bought a z16 last year, that they can test the AI features via pip. They have followed only the test specs by IBM, what they expect, how and what should be working. I received the feedback, that they don’t run any upstream tests. I explained the difference between manual smoke tests based on test specs and automated full tests based on upstream projects. My question „What is, if the customer wants to use features of a library, which has not been included into the tests by IBM?“ has opened the eyes and he wanted to drive Upstream First principles in the company. He has left Canonical at the beginning of this year. Red Hat is in a special situation. IBM Developers are developing based on RHEL (KVM Developers are running tests on SLES and Ubuntu afterwards), make smoke tests for AI based on their test specs and publish that all as Python libraries. Therefore, that is the most tested Linux distribution at IBM. But Red Hat has received the same statement as I have got by IBM. They are not allowed to argue against it as a daughter company. Therefore, they made the same statement as I did in my IBM announcement for openSUSE, that the responsibility for AI is on IBM side [5]: "WARNING (related to all Linux distributions on IBM Z & LinuxONE): Linux distributions can not guarantee the functionality of newly developed features related to AI and other things for z16 any more. That is based on missing/incorrect tests on IBM's side and missing z16 systems for Linux distributions for validation. Please create bug reports at IBM if you experience issues with „IBM supported“ open source software on z16, which is not included in our repositories." Fedora is an open source project by Red Hat, but not directly under IBM. Therefore, Fedora is allowed to support our activities via the Linux Distributions Working Group to bring all into the correct direction. But the main responsible persons for s390x and CI are Red Hatters. Therefore, I think about integrating the Fedora Council here, that they can support us based on failed tests in AI libraries and missing hardware. The Debian Project Lead said at Chemnitzer Linuxtage, that he wants to speak with IBM in person about this AI topic and how to bring software to Debian. We as openSUSE can be lucky to have the SUSE CTO and a VP in the openSUSE Board. I have asked also the Project Management via mail for their status yesterday. But I expect, that there is no big change on IBM side, if they didn’t recognize the missing Python compatibility last year already. That is a hint for missing SLES tests for AI. @Gerald and @Jeff: Are you also for the announcement (from SUSE side), that we do not support the new z17 until we receive an hardware upgrade and IBM is integrating upstream tests? You can add additional requirements as a response on this email, what I should write as the (Co-)Chair of the Linux Distributions Working Group. I will setup the announcement after receiving feedback from you and the Enterprise level and send it to the mailing list of the Linux Distributions Working Group for a review next week. Because that should be a common statement. I am allowed to decide it for openSUSE, because the former openSUSE Board has delegated the whole decision for openSUSE on s390x to myself. As the (Co-)Chair of the Linux Distributions Working Group, I want to interact pro all Linux distributions. Therefore, I manke the announcement as a suggestion on the mailing list before publishing it in the IBM community. Respond with feedbak on this email, if you disagree. We are supporting the hardware on what we are developing (z15) with our integrated Python packages on openSUSE Tumbleweed. The announcement should be a signal for IBM. Best regards, Sarah [0] https://community.ibm.com/zsystems/uploads/document/slider/12qs4awwowtp.pdf [1] https://newsroom.ibm.com/z17 [2] https://www.youtube.com/watch?v=_t7O6C0kU1Y [3] https://bugzilla.suse.com/show_bug.cgi?id=1215337#c30 [4] https://github.com/uxlfoundation/oneDNN/issues/2228 [5] https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/sarah-juli… [6] https://www.redbooks.ibm.com/redpapers/pdfs/redp5712.pdf

1 0

openSUSE knowledge sharing session/Meeting - Tuesday 14th April 2025
by Sarah Julia Kriesch 14 Apr '25

14 Apr '25

Hello together, Tomorrow, Tuesday, the 14th April 2025, is the next of our training/meeting sessions. We will meet us at 19:00 (German time)/ 10:00 (Pacific time) on our openSUSE Jitsy: meet.opensuse.org/s390x Topics for this session: 1) Know each other (networking) 2) Graphics bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1233167 * Continuously waiting for bug fix by IBM 3) CoreDNS fix suggested by IBM Developer upstream: https://github.com/coredns/coredns/issues/6682#issuecomment-2701187356 -> Interesting also for Rancher 4) gzip fix integrated by Andreas Stieger: https://github.com/andreasstieger/gzip/commit/23ddd95f3e152423fe0dfc96ff31d… 5) python-onnx hint for Container Image in IBM Container Registry -> Request for community access? 6) Python version at SUSE (AI/ML packages) 7) Comparison of "supported" AI packages by IBM and failed tests/builds 8) Infos about new IBM z17 9) Packaging topics 10) Open tasks and questions 11) Q & A I expect, that we will need 1.5 hours. I am looking forward to see you all. :-) Best regards, Sarah

2 1

New IBM z17 not supported by openSUSE
by Sarah Julia Kriesch 13 Apr '25

13 Apr '25

Hello together, most of you know, that we all have to build and develop for s390x on old z15 systems by IBM. IBM has introduced an AI Hardware Accelerator with z16 [0] as a nice feature besides others, like Confidential Computing and Post-Quantum Cryptography. Last week they had the IBM Z Day with the announcement of the new z17. That is full with AI integrated on the hardware level [1].. I want to create an announcement in the IBM Community with „IBM z17 not supported by the Linux Community“ or as a minimum „IBM z17 not supported by Community Linux Distributions“ based on following facts Last year I started with enabling and testing the AI/ML libraries based on the presentation by Andreas Krebbel [2]. Last year, IBM has published also a Redbook about AI on IBM Z [6]. Basic libraries like numpy did not make any problems. But we have received rounding errors and more with integrating onnx and other libraries on s390x. The interesting statemengt from IBM about build failures by IBM was then: > ------- Comment From Andreas.Krebbel(a)de.ibm.com 2024-06-19 05:37 EDT------- > (In reply to comment #28) > > (In reply to LTC BugProxy from comment #27) > > > (In reply to comment #25) > > > These logs do not indicate actual build failures to me. The builds are done > > > at this point. In both logs I see 16 *testsuite* failures. These are known > > > to us and we are working on it, but I do not see a reason to let the build > > > fail because of that. Once the patches mentioned earlier have been merged we > > > will be down to one fail in our tests. The last remaining fail seems to be > > > triggered by a build issue of the pillow package and not onnx. We will try > > > to address this. > > > > The OBS has got an integrated CI/CD pipeline. Therefore, if too many tests > > (from upstream) are failing, our builds are failing also. You can experience > > that also with Koji at Fedora. > What, in general, is a good thing to get aware of problems, but also has the > consequence of considering a package build to be failing because of testcase > bugs. We should disable our upstream tests for getting successful builds for AI on s390x… I made it also to a topic at our openSUSE Conference. I received an agreement by Dominique not to disable the tests. Aleksandra by Fedora said, that we should say to IBM, that we only support, what is integrated in our Linux distributions and no 3rd Party libraries via pip by IBM (especially for s390x now). If they integrate more AI features without giving us any hardware access for testing, we should say, that the new hardware is not supported. I received the hint from SUSE side, that their Python version had not been compatible for all the upstream enablements. They tried it with libzdnn [3]. Finally, we made the decision that we don’t support AI on openSUSE Leap and SLES as log as SUSE does not receive any feature requests. I was asked, how important AI is on IBM z16, which is not available for the Linux distributions. I have called it a „nice feature“ on z16. I wanted to work in my free time on these Python packages in collaboration with IBM until all is working (besides the default Release Engineering). I did that also upstream and forwarded it via the Linux Distributions Working Group, because all Linux distributions are affected. OneDNN is one example [4]. The IBM Developer does not respond here any more, because he is overloaded also with feature requests and more. And I hadn’t so much time besides my job to create bug reports for all. If you take a look into OBS, the number of failed/unresolvable Python libraries has not been reduced. It has been growing for s390x. After the release announcement of z17 it is the time stamp, where I say, that we should interact with a cut with „not supported as long as we do not receive any hardware upgrade and IBM does not use upstream tests“. I spoke also with the other Linux distributions: Canonical has bought a z16 last year, that they can test the AI features via pip. They have followed only the test specs by IBM, what they expect, how and what should be working. I received the feedback, that they don’t run any upstream tests. I explained the difference between manual smoke tests based on test specs and automated full tests based on upstream projects. My question „What is, if the customer wants to use features of a library, which has not been included into the tests by IBM?“ has opened the eyes and he wanted to drive Upstream First principles in the company. He has left Canonical at the beginning of this year. Red Hat is in a special situation. IBM Developers are developing based on RHEL (KVM Developers are running tests on SLES and Ubuntu afterwards), make smoke tests for AI based on their test specs and publish that all as Python libraries. Therefore, that is the most tested Linux distribution at IBM. But Red Hat has received the same statement as I have got by IBM. They are not allowed to argue against it as a daughter company. Therefore, they made the same statement as I did in my IBM announcement for openSUSE, that the responsibility for AI is on IBM side [5]: "WARNING (related to all Linux distributions on IBM Z & LinuxONE): Linux distributions can not guarantee the functionality of newly developed features related to AI and other things for z16 any more. That is based on missing/incorrect tests on IBM's side and missing z16 systems for Linux distributions for validation. Please create bug reports at IBM if you experience issues with „IBM supported“ open source software on z16, which is not included in our repositories." Fedora is an open source project by Red Hat, but not directly under IBM. Therefore, Fedora is allowed to support our activities via the Linux Distributions Working Group to bring all into the correct direction. But the main responsible persons for s390x and CI are Red Hatters. Therefore, I think about integrating the Fedora Council here, that they can support us based on failed tests in AI libraries and missing hardware. The Debian Project Lead said at Chemnitzer Linuxtage, that he wants to speak with IBM in person about this AI topic and how to bring software to Debian. We as openSUSE can be lucky to have the SUSE CTO and a VP in the openSUSE Board. I have asked also the Project Management via mail for their status yesterday. But I expect, that there is no big change on IBM side, if they didn’t recognize the missing Python compatibility last year already. That is a hint for missing SLES tests for AI. @Gerald and @Jeff: Are you also for the announcement (from SUSE side), that we do not support the new z17 until we receive an hardware upgrade and IBM is integrating upstream tests? You can add additional requirements as a response on this email, what I should write as the (Co-)Chair of the Linux Distributions Working Group. I will setup the announcement after receiving feedback from you and the Enterprise level and send it to the mailing list of the Linux Distributions Working Group for a review next week. Because that should be a common statement. I am allowed to decide it for openSUSE, because the former openSUSE Board has delegated the whole decision for openSUSE on s390x to myself. As the (Co-)Chair of the Linux Distributions Working Group, I want to interact pro all Linux distributions. Therefore, I manke the announcement as a suggestion on the mailing list before publishing it in the IBM community. Respond with feedbak on this email, if you disagree. We are supporting the hardware on what we are developing (z15) with our integrated Python packages on openSUSE Tumbleweed. The announcement should be a signal for IBM. Best regards, Sarah [0] https://community.ibm.com/zsystems/uploads/document/slider/12qs4awwowtp.pdf [1] https://newsroom.ibm.com/z17 [2] https://www.youtube.com/watch?v=_t7O6C0kU1Y [3] https://bugzilla.suse.com/show_bug.cgi?id=1215337#c30 [4] https://github.com/uxlfoundation/oneDNN/issues/2228 [5] https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/sarah-juli… [6] https://www.redbooks.ibm.com/redpapers/pdfs/redp5712.pdf

1 0