RFC: turn off ppc32 and ppc64 big endian builds on openSUSE:Factory:PowerPC
Hi all, recently I was made aware that openSUSE:Factory:PowerPC is quite a large distribution as it is building for ppc 32bit, ppc64 big endian and ppc64 little endian. in OpenQA as far as I know we are only testing the ppc64 little endian builds. Given the upcoming data center move and the lack of testing, are there any concerns about turning off the builds for ppc 32bit and ppc64 big endian? It would reduce build power needs as well as disk storage /publishing bandwidth which is shared with other distributions and architectures and becomes a problem because of PowerPC being exceptionally large. Thanks a lot in advance for any insight you can provide, Greetings, Dirk
I personally sometimes use the ppc64 build to reproduce/fix endianness problems in software I develop. Maybe others do that as well. I guess one could still use the s390x build for that so it is supposedly not a big loss. I also work on our openQA setups and since we only use ppc64le on our worker hosts the dropping of ppc64 shouldn't be a problem. And yes, ppc32 and ppc64 are not tested via openQA (at least I wouldn't know where).
Hi Marius, Am Do., 22. Juni 2023 um 17:00 Uhr schrieb Marius Kittler <mkittler@suse.de>:
I personally sometimes use the ppc64 build to reproduce/fix endianness problems in software I develop. Maybe others do that as well. I guess one could still use the s390x build for that so it is supposedly not a big loss.
That wouldn't be a problem, we can keep the architecture enabled for building. The issue I would like to resolve is with the repository publishing/image building, as those resources are shared across all other architectures as well. the building is done on the specific hardware anyway, so it does not interfere with other project efforts. Greetings, Dirk
On Tuesday 2023-07-04 09:43, Dirk Müller wrote:
Am Do., 22. Juni 2023 um 17:00 Uhr schrieb Marius Kittler <mkittler@suse.de>:
I personally sometimes use the ppc64 build to reproduce/fix endianness problems in software I develop. Maybe others do that as well. I guess one could still use the s390x build for that so it is supposedly not a big loss.
That wouldn't be a problem, we can keep the architecture enabled for building. The issue I would like to resolve is with the repository publishing/image building, as those resources are shared across all other architectures as well.
But that's only the case for Leap, right? openSUSE:Factory:PowerPC is separate from openSUSE:Factory and thus o:F:PPC should not block publishing of o:F. o:F:PPC might still use x86 workers for the image building, but surely that too could be nudged in the right direction with hostlabels and a modification to the right program to evaluate such host label, couldn't it?
Hi Jan, Am Di., 4. Juli 2023 um 09:48 Uhr schrieb Jan Engelhardt <jengelh@inai.de>:
is with the repository publishing/image building, as those resources are shared across all other architectures as well. But that's only the case for Leap, right? openSUSE:Factory:PowerPC is separate from openSUSE:Factory and thus o:F:PPC should not block publishing of o:F. o:F:PPC might still use x86 workers for the image building, but surely that too could be nudged in the right direction with hostlabels and a modification to the right program to evaluate such host label, couldn't it?
They all share the same uplink. it's about uploading 100+ GB to the download server on every publish that very few if any people are currently using (or that is usable, as openqa has been turned off) Greetings, Dirk
Hi all, Given the conclusion in the discussion here, I've submitted a SR to remove ppc64 (the big endian one) from publishing. As it is already disabled from building, that should reduce the effort the OBS has to do a bit. https://build.opensuse.org/request/show/1110638 Thanks, Dirk
On 9/12/23 16:31, Dirk Müller wrote:
Hi all,
Given the conclusion in the discussion here, I've submitted a SR to remove ppc64 (the big endian one) from publishing.
The end of an era. For almost a decade I hoped that I could use OBS to build packages for a brand new big endian POWER hardware: https://www.powerpc-notebook.org/en/ When the project started, it even made some sense, not just nostalgia value. But I gave up home (and donations) a while ago. I still have ppc32 hardware with openSUSE 10.X somewhere in a box: I kept it for nostalgia value, as I worked for Genesi, the makers of the Pegasos PPC workstations for half a decade. But installing the latest openSUSE on a 20 years old hardware does not make much sense anymore... Peter
On Tue, Sep 12, 2023 at 07:09:34PM +0200, Peter Czanik wrote:
On 9/12/23 16:31, Dirk Müller wrote:
Hi all,
Given the conclusion in the discussion here, I've submitted a SR to remove ppc64 (the big endian one) from publishing.
The end of an era. For almost a decade I hoped that I could use OBS to build packages for a brand new big endian POWER hardware: https://www.powerpc-notebook.org/en/ When the project started, it even made some sense, not just nostalgia value. But I gave up home (and donations) a while ago.
That hardware runs in LE mode as well but does not support vector instructions then. That would be bad for performance. Our installer does not support anything that is not a Power server although it might happen to work by accident. Finally the kernel does not support these CPUs - I don't know if it's built for them but it's certainly not tested in any way. And it won't be - we don't have any openQA workers for this platform. Thanks Michal
On Tue, 2023-09-12 at 19:09 +0200, Peter Czanik wrote:
The end of an era. For almost a decade I hoped that I could use OBS to build packages for a brand new big endian POWER hardware: https://www.powerpc-notebook.org/en/ When the project started, it even made some sense, not just nostalgia value. But I gave up home (and donations) a while ago.
If openSUSE had a community instance of OBS which would allow the community to connect their own build hosts, it would be possible to use POWER machines from Oregon State University Open-Source Lab (OSUOSL). I have suggested such a community OBS instance for quite a while, but unfortunately there doesn't seem be any interested within openSUSE. So, I have to stick to Debian for maintaining old and obscure architectures.
I still have ppc32 hardware with openSUSE 10.X somewhere in a box: I kept it for nostalgia value, as I worked for Genesi, the makers of the Pegasos PPC workstations for half a decade. But installing the latest openSUSE on a 20 years old hardware does not make much sense anymore...
I actually have two Pegasos-II desktops ;-). Very cool that you worked for them. Adrian
Hi Adrian, Am Mi., 13. Sept. 2023 um 12:12 Uhr schrieb Adrian Glaubitz <adrian.glaubitz@suse.com>:
If openSUSE had a community instance of OBS which would allow the community to connect their own build hosts, it would be possible to use POWER machines from Oregon State University Open-Source Lab (OSUOSL).
We do have sufficient build power for building ppc64. the packages are still building for ppc64 in the project. What we're lacking isn't hardware, it is people fixing the build for the failing packages so that meaningful things (like a new repository, or a new installation media) can be produced.
I actually have two Pegasos-II desktops ;-). Very cool that you worked for them.
Maybe you two can collaborate on keeping the port alive? Greetings, Dirk
Hi Dirk! On Wed, 2023-09-13 at 12:47 +0200, Dirk Müller wrote:
We do have sufficient build power for building ppc64. the packages are still building for ppc64 in the project. What we're lacking isn't hardware, it is people fixing the build for the failing packages so that meaningful things (like a new repository, or a new installation media) can be produced.
Most packages actually build fine as IBM maintains POWER support on both big and little endian systems. For reference, here is what's been built on Debian on ppc64 compared to ppc64el: - ppc64: 15719 - ppc64el: 16514 Looking through the failures, the biggest blocker is QtWebEngine which is unlikely to be fixed as Google upstream doesn't care about big-endian targets.
I actually have two Pegasos-II desktops ;-). Very cool that you worked for them.
Maybe you two can collaborate on keeping the port alive?
I actually do that already by fixing issues upstream. Adrian
Hi Dirk! On Thu, 2023-06-22 at 13:39 +0200, Dirk Müller wrote:
Given the upcoming data center move and the lack of testing, are there any concerns about turning off the builds for ppc 32bit and ppc64 big endian? It would reduce build power needs as well as disk storage /publishing bandwidth which is shared with other distributions and architectures and becomes a problem because of PowerPC being exceptionally large.
Thanks a lot in advance for any insight you can provide,
There are possibilities to get server capacity for POWER architectures outside SUSE. For example, OSUOSL provides POWER instances that can be used for open source development work. Unfortunately, OBS currently does not allow external build server instances to connect. I have been wondering though whether it would be possible if we created an OBS community instance which developers associated either with openSUSE or SUSE could use to connect their own build server instances to. This would also allow to provide additional unofficial SUSE ports to more archi- tectures without hogging SUSE's own infrastructure. Adrian
On 6/22/23 06:39, Dirk Müller wrote:
Hi all,
recently I was made aware that openSUSE:Factory:PowerPC is quite a large distribution as it is building for ppc 32bit, ppc64 big endian and ppc64 little endian. in OpenQA as far as I know we are only testing the ppc64 little endian builds.
Given the upcoming data center move and the lack of testing, are there any concerns about turning off the builds for ppc 32bit and ppc64 big endian? It would reduce build power needs as well as disk storage /publishing bandwidth which is shared with other distributions and architectures and becomes a problem because of PowerPC being exceptionally large.
I am one of a few people running a PowerBook G4 with ppc32 architecture. I was not aware that openSUSE had a distribution for it. At the moment, I am running Debian 12, and I hate it, but it does not seem wise to switch to openSUSE if the build will be ended. My main usage of the G4 is to check that new kernel releases actually run on a real ppc32. The QEMU emulation is getting better, but in the past there were some things that ran on the emulator, but failed on real hardware. A second task is to check USB wireless drivers for correct operation on big-endian hardware. Larry
On Thu, 2023-06-22 at 10:21 -0500, Larry Finger wrote:
I am one of a few people running a PowerBook G4 with ppc32 architecture. I was not aware that openSUSE had a distribution for it. At the moment, I am running Debian 12, and I hate it
Thanks, I'm the primary maintainer for it. ;-) Adrian
Hi Am 22.06.23 um 13:39 schrieb Dirk Müller:
Hi all,
recently I was made aware that openSUSE:Factory:PowerPC is quite a large distribution as it is building for ppc 32bit, ppc64 big endian and ppc64 little endian. in OpenQA as far as I know we are only testing the ppc64 little endian builds.
Given the upcoming data center move and the lack of testing, are there any concerns about turning off the builds for ppc 32bit and ppc64 big endian? It would reduce build power needs as well as disk storage /publishing bandwidth which is shared with other distributions and architectures and becomes a problem because of PowerPC being exceptionally large.
Thanks a lot in advance for any insight you can provide,
I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 variant is mostly interesting for its big-endian feature. I wasn't aware of the ppc32 build. Do you have a link to the installer ISO? I'm interested in trying it. Best regards Thomas
Greetings, Dirk
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
On Fri, 2023-06-23 at 09:52 +0200, Thomas Zimmermann via openSUSE
I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 variant is mostly interesting for its big-endian feature.
I wasn't aware of the ppc32 build. Do you have a link to the installer ISO? I'm interested in trying it.
There hasn't been an installer medium for ppc32 for like ever... only ppc64 and ppc64le; IIRC, ppc32 is 'only' enabled to provide multi-arch support (aka -32bit packages) to ppc64. All published artefacts for ppc64/ppc64le (and the ppc32 rpms) are at http://download.opensuse.org/ports/ppc/tumbleweed Cheers, Dominique PS: and the ppc64 installer does not work since a long time and nobody cared sufficiently to get this in shape: https://bugzilla.opensuse.org/show_bug.cgi?id=1205401 bug boils down to 'installation-images' not being buildable due to multiple deps being broken Until like 3 weeks ago, we wasted openQA cycles on it: https://openqa.opensuse.org/tests/overview?distri=microos&distri=opensus... Cheers, Dominique
Hi Am 23.06.23 um 10:01 schrieb Dominique Leuenberger:
On Fri, 2023-06-23 at 09:52 +0200, Thomas Zimmermann via openSUSE
I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 variant is mostly interesting for its big-endian feature.
I wasn't aware of the ppc32 build. Do you have a link to the installer ISO? I'm interested in trying it.
There hasn't been an installer medium for ppc32 for like ever... only ppc64 and ppc64le; IIRC, ppc32 is 'only' enabled to provide multi-arch support (aka -32bit packages) to ppc64.
All published artefacts for ppc64/ppc64le (and the ppc32 rpms) are at http://download.opensuse.org/ports/ppc/tumbleweed
Cheers, Dominique
PS: and the ppc64 installer does not work since a long time and nobody cared sufficiently to get this in shape: https://bugzilla.opensuse.org/show_bug.cgi?id=1205401 bug boils down to 'installation-images' not being buildable due to multiple deps being broken
I have an older install that I kept up-tp-date from time to time. So I didn't notice.
Until like 3 weeks ago, we wasted openQA cycles on it: https://openqa.opensuse.org/tests/overview?distri=microos&distri=opensus...
Given your's and Adrian's answers, I think I can live without ppc32 and ppc64. Best regards Thomas
Cheers, Dominique
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Hi Thomas! On Fri, 2023-06-23 at 09:52 +0200, Thomas Zimmermann via openSUSE Factory wrote:
I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 variant is mostly interesting for its big-endian feature.
I wasn't aware of the ppc32 build. Do you have a link to the installer ISO? I'm interested in trying it.
If Debian is okay for your testing purposes, you can use the Debian images I am creating on a regular basis. These always contain the latest kernel in Debian unstable. See:
https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/
I would love to do the same for openSUSE, but I haven't found anyone to help me with the effort. Adrian
Hi Am 23.06.23 um 10:05 schrieb Adrian Glaubitz:
Hi Thomas!
On Fri, 2023-06-23 at 09:52 +0200, Thomas Zimmermann via openSUSE Factory wrote:
I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 variant is mostly interesting for its big-endian feature.
I wasn't aware of the ppc32 build. Do you have a link to the installer ISO? I'm interested in trying it.
If Debian is okay for your testing purposes, you can use the Debian images I am creating on a regular basis. These always contain the latest kernel in Debian unstable.
See:
https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/
I would love to do the same for openSUSE, but I haven't found anyone to help me with the effort.
Thanks a lot. I'll take a look. Best regards Thomas
Adrian
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
On 6/23/23 03:05, Adrian Glaubitz via openSUSE Factory wrote:
If Debian is okay for your testing purposes, you can use the Debian images I am creating on a regular basis. These always contain the latest kernel in Debian unstable.
See:
https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/
I would love to do the same for openSUSE, but I haven't found anyone to help me with the effort.
Would starting with your installer get me to a different place than regular 'apd update'/'apt upgrade'? Larry
Hi Larry! On Fri, 2023-06-23 at 10:06 -0500, Larry Finger wrote:
On 6/23/23 03:05, Adrian Glaubitz via openSUSE Factory wrote:
If Debian is okay for your testing purposes, you can use the Debian images I am creating on a regular basis. These always contain the latest kernel in Debian unstable.
See:
https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/
I would love to do the same for openSUSE, but I haven't found anyone to help me with the effort.
Would starting with your installer get me to a different place than regular 'apd update'/'apt upgrade'?
Depends on what is running on your system. If you have a very old installation that you kept up-to-date over the time, you will probably boot your machine using Yaboot while I switched the default boot loader to GRUB. Also, your partitioning scheme will be different if your system is very old since the default partioning scheme in the installer was changed as well. Besides that, the packages will be the same provided that you are using the proper sources.list for Debian Ports and kept the machine up-to-date. Adrian
Adrian: So, as mentioned over in the broken thread with this same name, I do have an '04 iBook that last I checked was running Lu 18 ppc?? I could try to switch it over to Debian just for kicks. But, what are you referring to the "partitioning scheme has changed"?? If running "custom" with the "/" "/home" and "swap" partitions pointed to, would that not work?? I haven't taken the time to check the Debian site . . . but today is Bookworm day in my daily desktop driver . . . so I'm close.
Hi Fritz! We should probably move the discussion over to debian-powerpc [1]. On Sat, 2023-06-24 at 14:29 +0000, Fritz Hudnut wrote:
So, as mentioned over in the broken thread with this same name, I do have an '04 iBook that last I checked was running Lu 18 ppc?? I could try to switch it over to Debian just for kicks. But, what are you referring to the "partitioning scheme has changed"??
The partitioning scheme was changed to accommodate the switch from Yaboot to GRUB as the default bootloader.
If running "custom" with the "/" "/home" and "swap" partitions pointed to, would that not work??
It would still work. All you need is an HFS partition mounted to /boot/grub.
I haven't taken the time to check the Debian site . . . but today is Bookworm day in my daily desktop driver . . . so I'm close.
Yes, indeed. Adrian
Adrian: Thanks for the reply, I'll find you over there when I get a minute. Got into the net installer and there were some issues on the iBook that required thoughtful decisions, didn't have time. F
Hi Am 23.06.23 um 10:05 schrieb Adrian Glaubitz:
Hi Thomas!
On Fri, 2023-06-23 at 09:52 +0200, Thomas Zimmermann via openSUSE Factory wrote:
I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 variant is mostly interesting for its big-endian feature.
I wasn't aware of the ppc32 build. Do you have a link to the installer ISO? I'm interested in trying it.
If Debian is okay for your testing purposes, you can use the Debian images I am creating on a regular basis. These always contain the latest kernel in Debian unstable.
See:
https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/
Beim Booten der Install-CD bleibt der interne Bildschirm dunkel. Der Kernel lädt und das letzte, dass ich sehe ist 'starting klogd'. Ich vermute, dass dann der Radeon-Treiber geladen wird. Gibt es eine Möglichkeit in Grub mit nomodeset zu booten? Viele Grüße Thomas
I would love to do the same for openSUSE, but I haven't found anyone to help me with the effort.
Adrian
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
On Jun 30, 2023, at 9:29 AM, Thomas Zimmermann <tzimmermann@suse.com> wrote:
Hi
Am 23.06.23 um 10:05 schrieb Adrian Glaubitz: Hi Thomas!
On Fri, 2023-06-23 at 09:52 +0200, Thomas Zimmermann via openSUSE Factory wrote: I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 variant is mostly interesting for its big-endian feature.
I wasn't aware of the ppc32 build. Do you have a link to the installer ISO? I'm interested in trying it. If Debian is okay for your testing purposes, you can use the Debian images I am creating on a regular basis. These always contain the latest kernel in Debian unstable. See: https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/
Beim Booten der Install-CD bleibt der interne Bildschirm dunkel. Der Kernel lädt und das letzte, dass ich sehe ist 'starting klogd'. Ich vermute, dass dann der Radeon-Treiber geladen wird. Gibt es eine Möglichkeit in Grub mit nomodeset zu booten?
Ja, klar. Im GRUB einfach “e” tippen und “nomodeset” an die Kommandozeile hängen, dann mit Ctrl + X booten. Es ist leider aktuell nicht so einfach, ISO-Images für Debian Ports mit Firmware zu bauen. Daher kommt das Problem. Adrian
Hi Am 30.06.23 um 09:40 schrieb Adrian Glaubitz:
On Jun 30, 2023, at 9:29 AM, Thomas Zimmermann <tzimmermann@suse.com> wrote:
Hi
Am 23.06.23 um 10:05 schrieb Adrian Glaubitz: Hi Thomas!
On Fri, 2023-06-23 at 09:52 +0200, Thomas Zimmermann via openSUSE Factory wrote: I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 variant is mostly interesting for its big-endian feature.
I wasn't aware of the ppc32 build. Do you have a link to the installer ISO? I'm interested in trying it. If Debian is okay for your testing purposes, you can use the Debian images I am creating on a regular basis. These always contain the latest kernel in Debian unstable. See: https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/
Beim Booten der Install-CD bleibt der interne Bildschirm dunkel. Der Kernel lädt und das letzte, dass ich sehe ist 'starting klogd'. Ich vermute, dass dann der Radeon-Treiber geladen wird. Gibt es eine Möglichkeit in Grub mit nomodeset zu booten?
Ja, klar. Im GRUB einfach “e” tippen und “nomodeset” an die Kommandozeile hängen, dann mit Ctrl + X booten.
Thanks, I'll try. The command line in the installer's GRUB looked 'unfamiliar'. It didn't occur to me to just append it. Best regards Thomas
Es ist leider aktuell nicht so einfach, ISO-Images für Debian Ports mit Firmware zu bauen. Daher kommt das Problem.
Adrian
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
participants (10)
-
Adrian Glaubitz -
Dirk Müller -
Dominique Leuenberger -
Fritz Hudnut -
Jan Engelhardt -
Larry Finger -
Marius Kittler -
Michal Suchánek -
Peter Czanik -
Thomas Zimmermann