Hi everyone.
Over the past year the team working on the Power architecture for Fedora has been struggeling more and more with keeping 32bit alive and happy. This is simply due to the fact that we neither have the manpower to fix all the issues coming up over and over again for 32bit nor do we have the legacy hardware anymore for testing things (though the later is less of a problem).
A few weeks ago the team then sat together and talked about this for a while. At the end we bascially were left with 4 possible scenarios:
1) Manually modify all packages that continually fail on 32bit ppc and ExcludeArch them, together with the whole dep chain if necessary 2) Split off 32bit as a completely separate arch. That would require changes in yum and rpm as well as changes to koji and our infrastructure. 3) Someone with proven packager status from the community steps up and commits to do the work on fixing the 32bit ppc failures when they occur 4) Phase out and retire 32bit ppc over the course of the next Fedora release
Keeping the status quo wasn't an option to begin with, as we just can't continue with the current rising issues on 32bit ppc anymore.
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
For 2) we discussed how that would look like and to what it would lead: If we'd split 32bit ppc and 64bit ppc in koji, we'd have to then treat them really as separate and distinct archs as we would never be able to guarantee that the same versions of all packages would be available for both 32bit ppc and 64bit ppc anymore (as thats kind of the point in the separation as well). In turn that means we'd then have to have a full 2nd infrastructure set up for 32bit ppc, complete with hub and builders, nearly doubling our infrastructure. We'd also need changes in rpm, yum and all other package related tooling to not treat ppc and ppc64 as multilib anymore, as they wouldn't and couldn't be anymore (see point before with versions). So again, due to the massive impact of this separation we decided that that wouldn't be a workable solution either.
That leaves us with only option 3) and 4). For 3) we'd need someone really dedicated to actually fix the build issues on 32bit ppc, so proven packager is basically a necessity there. And that person would have to really commit to it. Being away for a month or 2 would block 64bit builds for that time then as well, and thats what's really been hurting us more and more over the past year and what we want to get away from.
So unless 3) happens over the next few weeks, the only option at this point for us is to say goodbye to 32bit ppc for Fedora. The maintenance burden has grown just too big for the team to handle it and the quality of the 64bit ppc port suffers more and more because of it. We'll of course still keep the old 32bit trees around for anyone to use, enjoy or play around with, or even pick them up themselves and do their own thing with it. Or alternatively anyone can set up their on koji and 32bit ppc build infrastructure for building things[1]
The plan for now is to do this prior to the branching for Fedora 21 in Rawhide only. We will of course be continuing to do 32bit update builds for Fedora 20 and earlier until they go EOL.
According to the current schedule[2] and the planed mass rebuild for Fedora 21[3] that means we have to do this before the beginning of June. Therefore we're currently aiming at Friday Mai 16 to make this change.
We just wanted to communicate this early so not to surprise anyone and give ample time for everyone to look for alternatives.
Yours, The Fedora Secondary Arch Team for Power
[1] http://fedoraproject.org/wiki/Koji/ServerHowTo [2] https://fedoraproject.org/wiki/Releases/21/Schedule [3] https://fedorahosted.org/rel-eng/ticket/5877
On Fri, 2014-05-09 at 11:32 +0200, Phil Knirsch wrote:
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
Hm, does this really have to be that much work? If feasible, it would have been my preferred option. Although since I do almost nothing on PPC these days I appreciate how little my opinion counts :)
Let's assume that you can write a script which, when run as a provenpackager, will check out a package from the git tree, add the ExcludeArch tag to it and commit it, and file a bug in bugzilla marked as blocking the 'PPC32 ExcludeArch tracker'. So the actual work involved in adding the ExcludeArch is basically limited to giving a *reason*.
It's also not that hard to use repoquery or similar tools to automatically run that script up the dependency chain, surely?
If we're genuinely talking about an "enormous amount of effort" then we really can script it and make it easy. And "constantly done for any new 32bit ppc package failing" also surprised me. As I said, I've been paying little attention to PPC for a while, but we used to have fairly much 100% coverage... are things really falling apart that much, and at such a rate?
If we really can't manage this, then I suppose I have no fundamental objection to just configuring the PPC koji to build only 64-bit from now on, and let someone set up a PPC32 koji instance if they want to. I think that's what you're proposing, right? All the RPM multilib bits ought to still work, if the packages come into existence again.
Configuring the PPC32 koji to just *accept* failures of the 32-bit builds, while still allowing PPC64 builds to complete successfully when that happens, would be nice. But that requires hacking on koji, doesn't it?
On 05/09/2014 12:15 PM, David Woodhouse wrote:
On Fri, 2014-05-09 at 11:32 +0200, Phil Knirsch wrote:
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
Hm, does this really have to be that much work? If feasible, it would have been my preferred option. Although since I do almost nothing on PPC these days I appreciate how little my opinion counts :)
Let's assume that you can write a script which, when run as a provenpackager, will check out a package from the git tree, add the ExcludeArch tag to it and commit it, and file a bug in bugzilla marked as blocking the 'PPC32 ExcludeArch tracker'. So the actual work involved in adding the ExcludeArch is basically limited to giving a *reason*.
Sure, but remember the chained dependencies we have in the build requires in Fedora. One of the recent efforts in the Base WG that me and Harald Hoyer were actually driving was investigate the inter build dependencies for a self hosting Fedora that includes gcc, rpm, yum and anaconda. We ended up needing over 1800 packages to be self hosting, but if we'd drop the self hosting requirement that dropped to less than 700. Which means the build requires pulls in more than 2x the amount of packages. And if you e.g. have to ExcludeArch eclipse (just as a typical example of a component that has proven to be quite difficult) you're then either left with unraveling the whole build requires chain of eclipse, java and all it's friends or excludearch the whole java world, which then in chain requires you to disable db4 and db, which is required by rpm. So you can't really disable the java stack but have to manually clean up the buildrequires and as you can imagine, doing that is a lot of work.
It's also not that hard to use repoquery or similar tools to automatically run that script up the dependency chain, surely?
Jup, we've done exactly that for the Base WG effort. Harald produced a nice graph of the inter dependencies here:
http://www.harald-hoyer.de/2014/01/14/self-hosting-fedora-base/
So we know it's a mess, and running repoquery regularly only will confirm that, but without someone dedicated and having the spare cycles to actually do the work to unravel those, that in itself won't help a lot unfortunatly. :(
If we're genuinely talking about an "enormous amount of effort" then we really can script it and make it easy. And "constantly done for any new 32bit ppc package failing" also surprised me. As I said, I've been paying little attention to PPC for a while, but we used to have fairly much 100% coverage... are things really falling apart that much, and at such a rate?
It's rather often core packages where we see build failures, be it java or toolchain related, or somewhere in the high level desktop space where things are quite dependent on another, too.
And it's often enough to having us spend a considerable amount of time having to investigate the failures, work with maintainers on potential fixes etc. And although most maintainers are really very helpful and forthcoming with finding fixes even for secondary architectures, occasionally we get a "don't have time" from someone (which is of course totally understandable and not meant as an accusation), which then means we'll have to find the fix ourselves or again, unravel dep build chains and would have to start ExludeArchs:
If we really can't manage this, then I suppose I have no fundamental objection to just configuring the PPC koji to build only 64-bit from now on, and let someone set up a PPC32 koji instance if they want to. I think that's what you're proposing, right? All the RPM multilib bits ought to still work, if the packages come into existence again.
Exactly, maybe i should have been clearer about that. We're totally fine and would be happy if someone sets up a ppc32 koji and builds and composes away, it's just that we simply don't have the time to really do this anymore as a more official secondary arch for Fedora anymore.
Configuring the PPC32 koji to just *accept* failures of the 32-bit builds, while still allowing PPC64 builds to complete successfully when that happens, would be nice. But that requires hacking on koji, doesn't it?
We thought about it, but the problem comes with the ppc and ppc64 bit architectures being multiarch. They are defined like that in rpm, yum and all the tooling we have for dealing with those architectures. If we'd only hack koji to accept builds if the 32bit fails but the 64bit succeeds that would break general multilib closure and David Aquilina said the side effects of different versions then could lead to another really ugly mess in the long run.
Hope that clarifies it a bit more in depth, and apologies for leaving out some of the alternatives that are of course absolutely viable (e.g. for someone to set up his own ppc32 bit koji and continuing to build there then).
Thanks & regards, Phil
On Friday, May 9, 2014, 7:18:13 AM, Phil Knirsch wrote:
On 05/09/2014 12:15 PM, David Woodhouse wrote:
On Fri, 2014-05-09 at 11:32 +0200, Phil Knirsch wrote:
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
I would suggest that supporting all desktops and the full package set would indeed be an unrealistic goal. Not just for ppc-32, but also for ppc-64.
One of the limiting factors is that the graphics hardware simply does not have the capabilities in most cases. Perhaps Wayland can simplify that.
From my point of view, for ppc-32 I would prioritize those packages required to operate the system, and do development in a set of core languages. I would tend to prioritize the basic languages as C, C++, Python, and Perl.
I would tend to downgrade support for Java, Ruby and the others if that was the cost of life or death of ppc32.
Hm, does this really have to be that much work? If feasible, it would have been my preferred option. Although since I do almost nothing on PPC these days I appreciate how little my opinion counts :)
Let's assume that you can write a script which, when run as a provenpackager, will check out a package from the git tree, add the ExcludeArch tag to it and commit it, and file a bug in bugzilla marked as blocking the 'PPC32 ExcludeArch tracker'. So the actual work involved in adding the ExcludeArch is basically limited to giving a *reason*.
Sure, but remember the chained dependencies we have in the build requires in Fedora. One of the recent efforts in the Base WG that me and Harald Hoyer were actually driving was investigate the inter build dependencies for a self hosting Fedora that includes gcc, rpm, yum and anaconda. We ended up needing over 1800 packages to be self hosting, but if we'd drop the self hosting requirement that dropped to less than 700. Which means the build requires pulls in more than 2x the amount of packages. And if you e.g. have to ExcludeArch eclipse (just as a typical example of a component that has proven to be quite difficult) you're then either left with unraveling the whole build requires chain of eclipse, java and all it's friends or excludearch the whole java world, which then in chain requires you to disable db4 and db, which is required by rpm. So you can't really disable the java stack but have to manually clean up the buildrequires and as you can imagine, doing that is a lot of work.
It's also not that hard to use repoquery or similar tools to automatically run that script up the dependency chain, surely?
Jup, we've done exactly that for the Base WG effort. Harald produced a nice graph of the inter dependencies here:
http://www.harald-hoyer.de/2014/01/14/self-hosting-fedora-base/
So we know it's a mess, and running repoquery regularly only will confirm that, but without someone dedicated and having the spare cycles to actually do the work to unravel those, that in itself won't help a lot unfortunatly. :(
If we're genuinely talking about an "enormous amount of effort" then we really can script it and make it easy. And "constantly done for any new 32bit ppc package failing" also surprised me. As I said, I've been paying little attention to PPC for a while, but we used to have fairly much 100% coverage... are things really falling apart that much, and at such a rate?
It's rather often core packages where we see build failures, be it java or toolchain related, or somewhere in the high level desktop space where things are quite dependent on another, too.
And it's often enough to having us spend a considerable amount of time having to investigate the failures, work with maintainers on potential fixes etc. And although most maintainers are really very helpful and forthcoming with finding fixes even for secondary architectures, occasionally we get a "don't have time" from someone (which is of course totally understandable and not meant as an accusation), which then means we'll have to find the fix ourselves or again, unravel dep build chains and would have to start ExludeArchs:
If we really can't manage this, then I suppose I have no fundamental objection to just configuring the PPC koji to build only 64-bit from now on, and let someone set up a PPC32 koji instance if they want to. I think that's what you're proposing, right? All the RPM multilib bits ought to still work, if the packages come into existence again.
Exactly, maybe i should have been clearer about that. We're totally fine and would be happy if someone sets up a ppc32 koji and builds and composes away, it's just that we simply don't have the time to really do this anymore as a more official secondary arch for Fedora anymore.
Configuring the PPC32 koji to just *accept* failures of the 32-bit builds, while still allowing PPC64 builds to complete successfully when that happens, would be nice. But that requires hacking on koji, doesn't it?
We thought about it, but the problem comes with the ppc and ppc64 bit architectures being multiarch. They are defined like that in rpm, yum and all the tooling we have for dealing with those architectures. If we'd only hack koji to accept builds if the 32bit fails but the 64bit succeeds that would break general multilib closure and David Aquilina said the side effects of different versions then could lead to another really ugly mess in the long run.
The more you separate ppc and ppc64, the harder it would be to maintain multiarch support. There are a certain set of core packages that require actual ppc 32-bit hardware for development, but interested parties could provide assistance on most of the user space packages with a viable mulilib.
Reviving support for 32-bit ppc installs (using a more modern package set, including grub2) is a core requirement. Likely the same on older Mac G5s. If multilib breaks, then we would have to also support ppc installs on newer ppc64 (Prep and other) hardware and that may be problematic in the general case.
Hope that clarifies it a bit more in depth, and apologies for leaving out some of the alternatives that are of course absolutely viable (e.g. for someone to set up his own ppc32 bit koji and continuing to build there then).
If that someone is not within the Fedora engineering group, you would introduce a whole new set of issues with coordination and security. I don't think they would approve key signing with the Fedora keys unless the final builds were on Fedora hosting.
Thanks & regards, Phil
On 09.05.2014 18:17, Al Dunsmuir wrote:
On Friday, May 9, 2014, 7:18:13 AM, Phil Knirsch wrote:
On 05/09/2014 12:15 PM, David Woodhouse wrote:
On Fri, 2014-05-09 at 11:32 +0200, Phil Knirsch wrote:
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
I would suggest that supporting all desktops and the full package set would indeed be an unrealistic goal. Not just for ppc-32, but also for ppc-64.
One of the limiting factors is that the graphics hardware simply does not have the capabilities in most cases. Perhaps Wayland can simplify that.
We have Radeon HD 4000, 5000, 6000, and 7000 in our A1-X1000 (Nemo boards). They have enough capabilities for new desktops.
From my point of view, for ppc-32 I would prioritize those packages required to operate the system, and do development in a set of core languages. I would tend to prioritize the basic languages as C, C++, Python, and Perl.
I would tend to downgrade support for Java, Ruby and the others if that was the cost of life or death of ppc32.
Hm, does this really have to be that much work? If feasible, it would have been my preferred option. Although since I do almost nothing on PPC these days I appreciate how little my opinion counts :)
Let's assume that you can write a script which, when run as a provenpackager, will check out a package from the git tree, add the ExcludeArch tag to it and commit it, and file a bug in bugzilla marked as blocking the 'PPC32 ExcludeArch tracker'. So the actual work involved in adding the ExcludeArch is basically limited to giving a *reason*.
Sure, but remember the chained dependencies we have in the build requires in Fedora. One of the recent efforts in the Base WG that me and Harald Hoyer were actually driving was investigate the inter build dependencies for a self hosting Fedora that includes gcc, rpm, yum and anaconda. We ended up needing over 1800 packages to be self hosting, but if we'd drop the self hosting requirement that dropped to less than 700. Which means the build requires pulls in more than 2x the amount of packages. And if you e.g. have to ExcludeArch eclipse (just as a typical example of a component that has proven to be quite difficult) you're then either left with unraveling the whole build requires chain of eclipse, java and all it's friends or excludearch the whole java world, which then in chain requires you to disable db4 and db, which is required by rpm. So you can't really disable the java stack but have to manually clean up the buildrequires and as you can imagine, doing that is a lot of work.
It's also not that hard to use repoquery or similar tools to automatically run that script up the dependency chain, surely?
Jup, we've done exactly that for the Base WG effort. Harald produced a nice graph of the inter dependencies here: http://www.harald-hoyer.de/2014/01/14/self-hosting-fedora-base/ So we know it's a mess, and running repoquery regularly only will confirm that, but without someone dedicated and having the spare cycles to actually do the work to unravel those, that in itself won't help a lot unfortunatly. :(
If we're genuinely talking about an "enormous amount of effort" then we really can script it and make it easy. And "constantly done for any new 32bit ppc package failing" also surprised me. As I said, I've been paying little attention to PPC for a while, but we used to have fairly much 100% coverage... are things really falling apart that much, and at such a rate?
It's rather often core packages where we see build failures, be it java or toolchain related, or somewhere in the high level desktop space where things are quite dependent on another, too. And it's often enough to having us spend a considerable amount of time having to investigate the failures, work with maintainers on potential fixes etc. And although most maintainers are really very helpful and forthcoming with finding fixes even for secondary architectures, occasionally we get a "don't have time" from someone (which is of course totally understandable and not meant as an accusation), which then means we'll have to find the fix ourselves or again, unravel dep build chains and would have to start ExludeArchs:
If we really can't manage this, then I suppose I have no fundamental objection to just configuring the PPC koji to build only 64-bit from now on, and let someone set up a PPC32 koji instance if they want to. I think that's what you're proposing, right? All the RPM multilib bits ought to still work, if the packages come into existence again.
Exactly, maybe i should have been clearer about that. We're totally fine and would be happy if someone sets up a ppc32 koji and builds and composes away, it's just that we simply don't have the time to really do this anymore as a more official secondary arch for Fedora anymore.
Configuring the PPC32 koji to just *accept* failures of the 32-bit builds, while still allowing PPC64 builds to complete successfully when that happens, would be nice. But that requires hacking on koji, doesn't it?
We thought about it, but the problem comes with the ppc and ppc64 bit architectures being multiarch. They are defined like that in rpm, yum and all the tooling we have for dealing with those architectures. If we'd only hack koji to accept builds if the 32bit fails but the 64bit succeeds that would break general multilib closure and David Aquilina said the side effects of different versions then could lead to another really ugly mess in the long run.
The more you separate ppc and ppc64, the harder it would be to maintain multiarch support. There are a certain set of core packages that require actual ppc 32-bit hardware for development, but interested parties could provide assistance on most of the user space packages with a viable mulilib.
Reviving support for 32-bit ppc installs (using a more modern package set, including grub2) is a core requirement. Likely the same on older Mac G5s. If multilib breaks, then we would have to also support ppc installs on newer ppc64 (Prep and other) hardware and that may be problematic in the general case.
Hope that clarifies it a bit more in depth, and apologies for leaving out some of the alternatives that are of course absolutely viable (e.g. for someone to set up his own ppc32 bit koji and continuing to build there then).
If that someone is not within the Fedora engineering group, you would introduce a whole new set of issues with coordination and security. I don't think they would approve key signing with the Fedora keys unless the final builds were on Fedora hosting.
Thanks & regards, Phil
ppc mailing list ppc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ppc
On Sunday, May 11, 2014, 8:35:33 AM, Christian Zigotzky wrote:
On 09.05.2014 18:17, Al Dunsmuir wrote:
On Friday, May 9, 2014, 7:18:13 AM, Phil Knirsch wrote:
On 05/09/2014 12:15 PM, David Woodhouse wrote:
On Fri, 2014-05-09 at 11:32 +0200, Phil Knirsch wrote:
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
I would suggest that supporting all desktops and the full package set would indeed be an unrealistic goal. Not just for ppc-32, but also for ppc-64.
One of the limiting factors is that the graphics hardware simply does not have the capabilities in most cases. Perhaps Wayland can simplify that.
We have Radeon HD 4000, 5000, 6000, and 7000 in our A1-X1000 (Nemo boards). They have enough capabilities for new desktops.
Those are covered by the Radeon 600 and later KMS and Mesa drivers, so should work well (except for ppc/ppc64 specific issues).
That means LXDE, XCFE, Mate and Gnome 3 at least should be viable. I do not have have any personal KDE experience.
The Nemo boards are ppc64, and I saw on the blog you referenced that you have the 3.14 Kernel running. What are you using as the boot loader, and what distribution?
On 11.05.2014 16:20, Al Dunsmuir wrote:
We have Radeon HD 4000, 5000, 6000, and 7000 in our A1-X1000 (Nemo boards). They have enough capabilities for new desktops.
Those are covered by the Radeon 600 and later KMS and Mesa drivers, so should work well (except for ppc/ppc64 specific issues).
That means LXDE, XCFE, Mate and Gnome 3 at least should be viable. I do not have have any personal KDE experience.
The Nemo boards are ppc64, and I saw on the blog you referenced that you have the 3.14 Kernel running. What are you using as the boot loader, and what distribution?
We boot our Linux distributions with the Common Firmware Environment (http://en.wikipedia.org/wiki/Common_Firmware_Environment). For example:
CFE> setenv bootargs "root=/dev/sdb2" CFE> boot -elf -noints -fatfs cf0:vmlinux-3.9.8.1-opensuse
The Common Firmware Environment offers a boot menu. You can simply add entries, to boot Linux distributions from the menu.
The following Linux distributions work on the Nemo board:
- Debian 6, 7, and Sid - Ubuntu 10.04.4 LTS, 12.04.4 LTS, Lubuntu 14.04 LTS, and the Ubuntu Live Remix DVD - openSUSE 11.1, 12.3, and 13.1 - Fedora 17 - Gentoo - CRUX PPC - Red Ribbon RC6 - MintPPC 11 - SliTaz PPC Linux
Linux kernel: 2.6.38, 2.6.39, 3.5.7, 3.8.7, 3.9.0, 3.9.8.1 (openSUSE kernel), 3.10.0, 3.10.3 (Ubuntu kernel), 3.10.13, 3.10.15 (Live Ubuntu Remix DVD kernel), 3.11.0, 3.12.0, 3.12.5, 3.13.11 (Ubuntu longterm kernel), and 3.14.2 with "PR" KVM support. In development: 3.15.
RadeonHD 4000, 5000, 6000 series support: WORKS WITH 3D ACCELERATION RadeonHD 7000 series support: WORKS WITHOUT 3D ACCELERATION HDAudio 7.1 Driver: WORKS PA Semi Network Driver: WORKS 3D acceleration: WORKS (Mesa 8.0.X - 9.1.X). For the new distributions you need the unofficial Mesa packages (http://www.supertuxkart-amiga.de/amiga/mesalib-unofficial.html).
Screenshots: http://www.supertuxkart-amiga.de/amiga/x1000.html
On Fri, 9 May 2014 12:17:58 -0400 Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 9, 2014, 7:18:13 AM, Phil Knirsch wrote:
On 05/09/2014 12:15 PM, David Woodhouse wrote:
On Fri, 2014-05-09 at 11:32 +0200, Phil Knirsch wrote:
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
I would suggest that supporting all desktops and the full package set would indeed be an unrealistic goal. Not just for ppc-32, but also for ppc-64.
One of the limiting factors is that the graphics hardware simply does not have the capabilities in most cases. Perhaps Wayland can simplify that.
From my point of view, for ppc-32 I would prioritize those packages required to operate the system, and do development in a set of core languages. I would tend to prioritize the basic languages as C, C++, Python, and Perl.
I would tend to downgrade support for Java, Ruby and the others if that was the cost of life or death of ppc32.
That's not how the secondary arches are supposed to work. The build process is automated and the secondary arches follow all builds from primary with a short delay. And builds in secondaries are using the same package versions in the buildroots as were used on primary. Yes, there are exceptions, but the exceptions should be about using newer versions, when the exact one fails to build. And also with a different package set our product couldn't be called Fedora. So called remixes allow using different package sets.
Dan
Hm, does this really have to be that much work? If feasible, it would have been my preferred option. Although since I do almost nothing on PPC these days I appreciate how little my opinion counts :)
Let's assume that you can write a script which, when run as a provenpackager, will check out a package from the git tree, add the ExcludeArch tag to it and commit it, and file a bug in bugzilla marked as blocking the 'PPC32 ExcludeArch tracker'. So the actual work involved in adding the ExcludeArch is basically limited to giving a *reason*.
Sure, but remember the chained dependencies we have in the build requires in Fedora. One of the recent efforts in the Base WG that me and Harald Hoyer were actually driving was investigate the inter build dependencies for a self hosting Fedora that includes gcc, rpm, yum and anaconda. We ended up needing over 1800 packages to be self hosting, but if we'd drop the self hosting requirement that dropped to less than 700. Which means the build requires pulls in more than 2x the amount of packages. And if you e.g. have to ExcludeArch eclipse (just as a typical example of a component that has proven to be quite difficult) you're then either left with unraveling the whole build requires chain of eclipse, java and all it's friends or excludearch the whole java world, which then in chain requires you to disable db4 and db, which is required by rpm. So you can't really disable the java stack but have to manually clean up the buildrequires and as you can imagine, doing that is a lot of work.
It's also not that hard to use repoquery or similar tools to automatically run that script up the dependency chain, surely?
Jup, we've done exactly that for the Base WG effort. Harald produced a nice graph of the inter dependencies here:
http://www.harald-hoyer.de/2014/01/14/self-hosting-fedora-base/
So we know it's a mess, and running repoquery regularly only will confirm that, but without someone dedicated and having the spare cycles to actually do the work to unravel those, that in itself won't help a lot unfortunatly. :(
If we're genuinely talking about an "enormous amount of effort" then we really can script it and make it easy. And "constantly done for any new 32bit ppc package failing" also surprised me. As I said, I've been paying little attention to PPC for a while, but we used to have fairly much 100% coverage... are things really falling apart that much, and at such a rate?
It's rather often core packages where we see build failures, be it java or toolchain related, or somewhere in the high level desktop space where things are quite dependent on another, too.
And it's often enough to having us spend a considerable amount of time having to investigate the failures, work with maintainers on potential fixes etc. And although most maintainers are really very helpful and forthcoming with finding fixes even for secondary architectures, occasionally we get a "don't have time" from someone (which is of course totally understandable and not meant as an accusation), which then means we'll have to find the fix ourselves or again, unravel dep build chains and would have to start ExludeArchs:
If we really can't manage this, then I suppose I have no fundamental objection to just configuring the PPC koji to build only 64-bit from now on, and let someone set up a PPC32 koji instance if they want to. I think that's what you're proposing, right? All the RPM multilib bits ought to still work, if the packages come into existence again.
Exactly, maybe i should have been clearer about that. We're totally fine and would be happy if someone sets up a ppc32 koji and builds and composes away, it's just that we simply don't have the time to really do this anymore as a more official secondary arch for Fedora anymore.
Configuring the PPC32 koji to just *accept* failures of the 32-bit builds, while still allowing PPC64 builds to complete successfully when that happens, would be nice. But that requires hacking on koji, doesn't it?
We thought about it, but the problem comes with the ppc and ppc64 bit architectures being multiarch. They are defined like that in rpm, yum and all the tooling we have for dealing with those architectures. If we'd only hack koji to accept builds if the 32bit fails but the 64bit succeeds that would break general multilib closure and David Aquilina said the side effects of different versions then could lead to another really ugly mess in the long run.
The more you separate ppc and ppc64, the harder it would be to maintain multiarch support. There are a certain set of core packages that require actual ppc 32-bit hardware for development, but interested parties could provide assistance on most of the user space packages with a viable mulilib.
Reviving support for 32-bit ppc installs (using a more modern package set, including grub2) is a core requirement. Likely the same on older Mac G5s. If multilib breaks, then we would have to also support ppc installs on newer ppc64 (Prep and other) hardware and that may be problematic in the general case.
Hope that clarifies it a bit more in depth, and apologies for leaving out some of the alternatives that are of course absolutely viable (e.g. for someone to set up his own ppc32 bit koji and continuing to build there then).
If that someone is not within the Fedora engineering group, you would introduce a whole new set of issues with coordination and security. I don't think they would approve key signing with the Fedora keys unless the final builds were on Fedora hosting.
Thanks & regards, Phil
ppc mailing list ppc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ppc
On Monday, May 12, 2014, 7:57:07 AM, Dan Horák wrote:
On Fri, 9 May 2014 12:17:58 -0400 Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 9, 2014, 7:18:13 AM, Phil Knirsch wrote:
On 05/09/2014 12:15 PM, David Woodhouse wrote:
On Fri, 2014-05-09 at 11:32 +0200, Phil Knirsch wrote:
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
I would suggest that supporting all desktops and the full package set would indeed be an unrealistic goal. Not just for ppc-32, but also for ppc-64.
One of the limiting factors is that the graphics hardware simply does not have the capabilities in most cases. Perhaps Wayland can simplify that.
From my point of view, for ppc-32 I would prioritize those packages required to operate the system, and do development in a set of core languages. I would tend to prioritize the basic languages as C, C++, Python, and Perl.
I would tend to downgrade support for Java, Ruby and the others if that was the cost of life or death of ppc32.
That's not how the secondary arches are supposed to work. The build process is automated and the secondary arches follow all builds from primary with a short delay. And builds in secondaries are using the same package versions in the buildroots as were used on primary. Yes, there are exceptions, but the exceptions should be about using newer versions, when the exact one fails to build. And also with a different package set our product couldn't be called Fedora. So called remixes allow using different package sets.
Dan,
Indeed, "downgrade support" is the wrong terminology.
What I meant was if we want a working ppc32, we have to first concentrate on the core components. We need the kernel, boot support, lorax, x11, rpm, core languages, and components required to build those components to be fully functional before we can move on to diagnosing and solving issues with in other components.
Phil suggested automatically using ExcludeArch to remove a failing component for ppc32, to prevent a working build for that package in ppc64 from also being treated as a failure. He needs to do this so that the ppc64 team can deliver his package set for F21.
While that solves ppc64's immediate problem for that package, it means that rpm dependencies can and will cause immediate ppc32 build failures. We have to prioritize those failures for the core components (so the ppc32 system can still boot and build new changes) over failures for other components that are less critical.
As usual with build failures, some issues will be readily solved by the ppc32 team, while others will require assistance by the package owner, or by other knowledgeable parties.
Phil wanted proven packagers involved to reduce the overhead in fixing trivial problems across many packages (since they have acl access to all packages, not just their own).
It will take a while (likely F22) before ppc32 is stable enough to let the situation return to normal so that ppc32 builds are relevant.
Hm, does this really have to be that much work? If feasible, it would have been my preferred option. Although since I do almost nothing on PPC these days I appreciate how little my opinion counts :)
Let's assume that you can write a script which, when run as a provenpackager, will check out a package from the git tree, add the ExcludeArch tag to it and commit it, and file a bug in bugzilla marked as blocking the 'PPC32 ExcludeArch tracker'. So the actual work involved in adding the ExcludeArch is basically limited to giving a *reason*.
Sure, but remember the chained dependencies we have in the build requires in Fedora. One of the recent efforts in the Base WG that me and Harald Hoyer were actually driving was investigate the inter build dependencies for a self hosting Fedora that includes gcc, rpm, yum and anaconda. We ended up needing over 1800 packages to be self hosting, but if we'd drop the self hosting requirement that dropped to less than 700. Which means the build requires pulls in more than 2x the amount of packages. And if you e.g. have to ExcludeArch eclipse (just as a typical example of a component that has proven to be quite difficult) you're then either left with unraveling the whole build requires chain of eclipse, java and all it's friends or excludearch the whole java world, which then in chain requires you to disable db4 and db, which is required by rpm. So you can't really disable the java stack but have to manually clean up the buildrequires and as you can imagine, doing that is a lot of work.
It's also not that hard to use repoquery or similar tools to automatically run that script up the dependency chain, surely?
Jup, we've done exactly that for the Base WG effort. Harald produced a nice graph of the inter dependencies here:
http://www.harald-hoyer.de/2014/01/14/self-hosting-fedora-base/
So we know it's a mess, and running repoquery regularly only will confirm that, but without someone dedicated and having the spare cycles to actually do the work to unravel those, that in itself won't help a lot unfortunatly. :(
If we're genuinely talking about an "enormous amount of effort" then we really can script it and make it easy. And "constantly done for any new 32bit ppc package failing" also surprised me. As I said, I've been paying little attention to PPC for a while, but we used to have fairly much 100% coverage... are things really falling apart that much, and at such a rate?
It's rather often core packages where we see build failures, be it java or toolchain related, or somewhere in the high level desktop space where things are quite dependent on another, too.
And it's often enough to having us spend a considerable amount of time having to investigate the failures, work with maintainers on potential fixes etc. And although most maintainers are really very helpful and forthcoming with finding fixes even for secondary architectures, occasionally we get a "don't have time" from someone (which is of course totally understandable and not meant as an accusation), which then means we'll have to find the fix ourselves or again, unravel dep build chains and would have to start ExludeArchs:
If we really can't manage this, then I suppose I have no fundamental objection to just configuring the PPC koji to build only 64-bit from now on, and let someone set up a PPC32 koji instance if they want to. I think that's what you're proposing, right? All the RPM multilib bits ought to still work, if the packages come into existence again.
Exactly, maybe i should have been clearer about that. We're totally fine and would be happy if someone sets up a ppc32 koji and builds and composes away, it's just that we simply don't have the time to really do this anymore as a more official secondary arch for Fedora anymore.
Configuring the PPC32 koji to just *accept* failures of the 32-bit builds, while still allowing PPC64 builds to complete successfully when that happens, would be nice. But that requires hacking on koji, doesn't it?
We thought about it, but the problem comes with the ppc and ppc64 bit architectures being multiarch. They are defined like that in rpm, yum and all the tooling we have for dealing with those architectures. If we'd only hack koji to accept builds if the 32bit fails but the 64bit succeeds that would break general multilib closure and David Aquilina said the side effects of different versions then could lead to another really ugly mess in the long run.
The more you separate ppc and ppc64, the harder it would be to maintain multiarch support. There are a certain set of core packages that require actual ppc 32-bit hardware for development, but interested parties could provide assistance on most of the user space packages with a viable mulilib.
Reviving support for 32-bit ppc installs (using a more modern package set, including grub2) is a core requirement. Likely the same on older Mac G5s. If multilib breaks, then we would have to also support ppc installs on newer ppc64 (Prep and other) hardware and that may be problematic in the general case.
Hope that clarifies it a bit more in depth, and apologies for leaving out some of the alternatives that are of course absolutely viable (e.g. for someone to set up his own ppc32 bit koji and continuing to build there then).
If that someone is not within the Fedora engineering group, you would introduce a whole new set of issues with coordination and security. I don't think they would approve key signing with the Fedora keys unless the final builds were on Fedora hosting.
Thanks & regards, Phil
ppc mailing list ppc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ppc
ppc mailing list ppc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ppc
Hello Phil,
On Friday, May 9, 2014, 5:32:33 AM, Phil Knirsch wrote:
Over the past year the team working on the Power architecture for Fedora has been struggeling more and more with keeping 32bit alive and happy. This is simply due to the fact that we neither have the manpower to fix all the issues coming up over and over again for 32bit nor do we have the legacy hardware anymore for testing things (though the later is less of a problem).
There has not been any discussion on this mailing list regarding ppc-32 since my posting in December, and a recent query re ppc-64 also went unanswered.
Keeping the discussion in the open makes it more likely for you to get assistance, and perhaps introduce opinions that would represent a different viewpoint.
Since this fall, I've been busy collecting information, and additional ppc hardware for testing, as well as attempting to install various current and obsolete ppc distributions.
I've now got the following Apple hardware: iMac 350 MHz eMac G4 1 GHz (ATI) PowerMac G4 dual 1GHz Mini G4 1.5GHZ PowerMac G5 1.6 GHz (AGP) about 1/2 dozen different ATI video cards for the PowerMacs - Also have x86 variants of most to allow video driver validation and development on both architectures.
Within the last 2 months, I was able to pick up a pair of inexpensive IBM 7046-B50 (32-bit, CHRP) servers, so I can run AIX 5.3 to do work-related programming (new AIX ports of rpm, Perl, Python 2.7 and 3.4, and eventually a more modern minimal desktop - likely Mate), plus dual boot with Fedora.
Both units now have IBM GXT135P video (Matrox G450) and I have a GXT120P as well. I've got x86 variants of the G450, and one for the other on order. Redhat just produced a minimal Matrox KMS driver targeted for servers, so that should be good enough.
I'm also interested in supporting the older ATI video (R128, R300 and R600) on 32-bit x86 as well, and have been collecting a reasonable sample of the various Radeon generations.
Related to this, I've been in contact with Conner Behan (r128 video maintainer), and he expressed an interested in actively supporting that video arch on ppc-32 because of the dearth of other big-endian platforms.
I've been in contact with a couple of other folks offline who can also provide some assistance. I've taken the liberty of CCing Conner and the others.
A few weeks ago the team then sat together and talked about this for a while. At the end we bascially were left with 4 possible scenarios:
- Manually modify all packages that continually fail on 32bit ppc and
ExcludeArch them, together with the whole dep chain if necessary 2) Split off 32bit as a completely separate arch. That would require changes in yum and rpm as well as changes to koji and our infrastructure. 3) Someone with proven packager status from the community steps up and commits to do the work on fixing the 32bit ppc failures when they occur 4) Phase out and retire 32bit ppc over the course of the next Fedora release
Keeping the status quo wasn't an option to begin with, as we just can't continue with the current rising issues on 32bit ppc anymore.
So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution.
For 2) we discussed how that would look like and to what it would lead: If we'd split 32bit ppc and 64bit ppc in koji, we'd have to then treat them really as separate and distinct archs as we would never be able to guarantee that the same versions of all packages would be available for both 32bit ppc and 64bit ppc anymore (as thats kind of the point in the separation as well). In turn that means we'd then have to have a full 2nd infrastructure set up for 32bit ppc, complete with hub and builders, nearly doubling our infrastructure. We'd also need changes in rpm, yum and all other package related tooling to not treat ppc and ppc64 as multilib anymore, as they wouldn't and couldn't be anymore (see point before with versions). So again, due to the massive impact of this separation we decided that that wouldn't be a workable solution either.
That leaves us with only option 3) and 4). For 3) we'd need someone really dedicated to actually fix the build issues on 32bit ppc, so proven packager is basically a necessity there. And that person would have to really commit to it. Being away for a month or 2 would block 64bit builds for that time then as well, and thats what's really been hurting us more and more over the past year and what we want to get away from.
So unless 3) happens over the next few weeks, the only option at this point for us is to say goodbye to 32bit ppc for Fedora. The maintenance burden has grown just too big for the team to handle it and the quality of the 64bit ppc port suffers more and more because of it. We'll of course still keep the old 32bit trees around for anyone to use, enjoy or play around with, or even pick them up themselves and do their own thing with it. Or alternatively anyone can set up their on koji and 32bit ppc build infrastructure for building things[1]
The plan for now is to do this prior to the branching for Fedora 21 in Rawhide only. We will of course be continuing to do 32bit update builds for Fedora 20 and earlier until they go EOL.
According to the current schedule[2] and the planed mass rebuild for Fedora 21[3] that means we have to do this before the beginning of June. Therefore we're currently aiming at Friday Mai 16 to make this change.
We just wanted to communicate this early so not to surprise anyone and give ample time for everyone to look for alternatives.
It really sounds like you've communicated your final decisions, without soliciting input. As today is Friday May 8th, you've left a week for final discussion.
I am not a Fedora packager, but I am willing to dedicate the effort required to become one. I can understand the need for a proven packager to be able to access packages in general... but it seems that to raise the entry point for anyone else to atttempt to provide assistance to an impossible height.
Yours, The Fedora Secondary Arch Team for Power
[1] http://fedoraproject.org/wiki/Koji/ServerHowTo [2] https://fedoraproject.org/wiki/Releases/21/Schedule [3] https://fedorahosted.org/rel-eng/ticket/5877
On 09.05.2014 17:46, Al Dunsmuir wrote:
Hello Phil,
On Friday, May 9, 2014, 5:32:33 AM, Phil Knirsch wrote:
Over the past year the team working on the Power architecture for Fedora has been struggeling more and more with keeping 32bit alive and happy. This is simply due to the fact that we neither have the manpower to fix all the issues coming up over and over again for 32bit nor do we have the legacy hardware anymore for testing things (though the later is less of a problem).
There has not been any discussion on this mailing list regarding ppc-32 since my posting in December, and a recent query re ppc-64 also went unanswered.
Keeping the discussion in the open makes it more likely for you to get assistance, and perhaps introduce opinions that would represent a different viewpoint.
Since this fall, I've been busy collecting information, and additional ppc hardware for testing, as well as attempting to install various current and obsolete ppc distributions.
I've now got the following Apple hardware: iMac 350 MHz eMac G4 1 GHz (ATI) PowerMac G4 dual 1GHz Mini G4 1.5GHZ PowerMac G5 1.6 GHz (AGP) about 1/2 dozen different ATI video cards for the PowerMacs - Also have x86 variants of most to allow video driver validation and development on both architectures.
I could test it on my PA6T system (Nemo board) if you like. ;-)
Within the last 2 months, I was able to pick up a pair of inexpensive IBM 7046-B50 (32-bit, CHRP) servers, so I can run AIX 5.3 to do work-related programming (new AIX ports of rpm, Perl, Python 2.7 and 3.4, and eventually a more modern minimal desktop - likely Mate), plus dual boot with Fedora.
Both units now have IBM GXT135P video (Matrox G450) and I have a GXT120P as well. I've got x86 variants of the G450, and one for the other on order. Redhat just produced a minimal Matrox KMS driver targeted for servers, so that should be good enough.
I'm also interested in supporting the older ATI video (R128, R300 and R600) on 32-bit x86 as well, and have been collecting a reasonable sample of the various Radeon generations.
Related to this, I've been in contact with Conner Behan (r128 video maintainer), and he expressed an interested in actively supporting that video arch on ppc-32 because of the dearth of other big-endian platforms.
I've been in contact with a couple of other folks offline who can also provide some assistance. I've taken the liberty of CCing Conner and the others.
A few weeks ago the team then sat together and talked about this for a while. At the end we bascially were left with 4 possible scenarios:
- Manually modify all packages that continually fail on 32bit ppc and
ExcludeArch them, together with the whole dep chain if necessary 2) Split off 32bit as a completely separate arch. That would require changes in yum and rpm as well as changes to koji and our infrastructure. 3) Someone with proven packager status from the community steps up and commits to do the work on fixing the 32bit ppc failures when they occur 4) Phase out and retire 32bit ppc over the course of the next Fedora release Keeping the status quo wasn't an option to begin with, as we just can't continue with the current rising issues on 32bit ppc anymore. So for 1) this would effectively mean we'd have to look at every failed build for 32bit ppc and put ExcludeArch: ppc in it. On top of that we'd then need to additionally look for all components that require or buildrequire recursively these packages and do the same for all those packages, too. Just for the java stack thats several hundreds of packages alone. Overall thats an enormous amount of effort and would have to be constantly done for any new 32bit ppc package failing, so we dropped this solution. For 2) we discussed how that would look like and to what it would lead: If we'd split 32bit ppc and 64bit ppc in koji, we'd have to then treat them really as separate and distinct archs as we would never be able to guarantee that the same versions of all packages would be available for both 32bit ppc and 64bit ppc anymore (as thats kind of the point in the separation as well). In turn that means we'd then have to have a full 2nd infrastructure set up for 32bit ppc, complete with hub and builders, nearly doubling our infrastructure. We'd also need changes in rpm, yum and all other package related tooling to not treat ppc and ppc64 as multilib anymore, as they wouldn't and couldn't be anymore (see point before with versions). So again, due to the massive impact of this separation we decided that that wouldn't be a workable solution either. That leaves us with only option 3) and 4). For 3) we'd need someone really dedicated to actually fix the build issues on 32bit ppc, so proven packager is basically a necessity there. And that person would have to really commit to it. Being away for a month or 2 would block 64bit builds for that time then as well, and thats what's really been hurting us more and more over the past year and what we want to get away from. So unless 3) happens over the next few weeks, the only option at this point for us is to say goodbye to 32bit ppc for Fedora. The maintenance burden has grown just too big for the team to handle it and the quality of the 64bit ppc port suffers more and more because of it. We'll of course still keep the old 32bit trees around for anyone to use, enjoy or play around with, or even pick them up themselves and do their own thing with it. Or alternatively anyone can set up their on koji and 32bit ppc build infrastructure for building things[1] The plan for now is to do this prior to the branching for Fedora 21 in Rawhide only. We will of course be continuing to do 32bit update builds for Fedora 20 and earlier until they go EOL. According to the current schedule[2] and the planed mass rebuild for Fedora 21[3] that means we have to do this before the beginning of June. Therefore we're currently aiming at Friday Mai 16 to make this change. We just wanted to communicate this early so not to surprise anyone and give ample time for everyone to look for alternatives.
It really sounds like you've communicated your final decisions, without soliciting input. As today is Friday May 8th, you've left a week for final discussion.
I am not a Fedora packager, but I am willing to dedicate the effort required to become one. I can understand the need for a proven packager to be able to access packages in general... but it seems that to raise the entry point for anyone else to atttempt to provide assistance to an impossible height.
Yours, The Fedora Secondary Arch Team for Power [1] http://fedoraproject.org/wiki/Koji/ServerHowTo [2] https://fedoraproject.org/wiki/Releases/21/Schedule [3] https://fedorahosted.org/rel-eng/ticket/5877
ppc mailing list ppc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ppc
On Sunday, May 11, 2014, 8:30:27 AM, Christian Zigotzky wrote:
On 09.05.2014 17:46, Al Dunsmuir wrote:
Hello Phil,
On Friday, May 9, 2014, 5:32:33 AM, Phil Knirsch wrote:
Over the past year the team working on the Power architecture for Fedora has been struggeling more and more with keeping 32bit alive and happy. This is simply due to the fact that we neither have the manpower to fix all the issues coming up over and over again for 32bit nor do we have the legacy hardware anymore for testing things (though the later is less of a problem).
There has not been any discussion on this mailing list regarding ppc-32 since my posting in December, and a recent query re ppc-64 also went unanswered.
Keeping the discussion in the open makes it more likely for you to get assistance, and perhaps introduce opinions that would represent a different viewpoint.
Since this fall, I've been busy collecting information, and additional ppc hardware for testing, as well as attempting to install various current and obsolete ppc distributions.
I've now got the following Apple hardware: iMac 350 MHz eMac G4 1 GHz (ATI) PowerMac G4 dual 1GHz Mini G4 1.5GHZ PowerMac G5 1.6 GHz (AGP) about 1/2 dozen different ATI video cards for the PowerMacs - Also have x86 variants of most to allow video driver validation and development on both architectures.
I could test it on my PA6T system (Nemo board) if you like. ;-)
Another ATI/Radeon.
For Nvidia on ppc, I only have the Nvidia Geforce4 MX that came with one the PowerMac G4.
Within the last 2 months, I was able to pick up a pair of inexpensive IBM 7046-B50 (32-bit, CHRP) servers, so I can run AIX 5.3 to do work-related programming (new AIX ports of rpm, Perl, Python 2.7 and 3.4, and eventually a more modern minimal desktop - likely Mate), plus dual boot with Fedora.
Both units now have IBM GXT135P video (Matrox G450) and I have a GXT120P as well. I've got x86 variants of the G450, and one for the other on order. Redhat just produced a minimal Matrox KMS driver targeted for servers, so that should be good enough.
I don't know if the minimal KMS driver has any acceleration. Even IBM added minimal acceleration for the GXT135p to AIX, so there should be hope for something useful in the future.
I started with the GXT145Ps, but then picked up the GXT120P from the UK for completeness after reading that the older Linux support for the B50 only targeted GXT120P and GXT130P. The Matrox MY220P (x86 618-04 PCI) matching the GXT120P arrived in yesterday's post.
The older Fedora version won't boot on the B50 (yaboot to start in 64-bit mode), but I've found a reference to SUSE lilo updates to support the B50. I'm going to spend today investigating further.
There is a fair bit of information about switching to grub2 on the Macs, but I'd like to get the B50 to the starting gate in yaboot and progress the systems together to grub.
Al
On Fri, May 9, 2014 at 11:46 AM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
Since this fall, I've been busy collecting information, and additional ppc hardware for testing, as well as attempting to install various current and obsolete ppc distributions.
I've now got the following Apple hardware: iMac 350 MHz
Released August 1998. Discontinued.
eMac G4 1 GHz (ATI)
Released April 2002. Discontinued.
PowerMac G4 dual 1GHz
Released January 2003. Discontinued.
Mini G4 1.5GHZ
Release September 2005. Discontinued.
PowerMac G5 1.6 GHz (AGP)
64-bit, so kind of irrelevant for this conversation.
about 1/2 dozen different ATI video cards for the PowerMacs
- Also have x86 variants of most to allow video driver validation and development on both architectures.
Within the last 2 months, I was able to pick up a pair of inexpensive IBM 7046-B50 (32-bit, CHRP) servers, so I can run AIX 5.3 to do
Released September 1999. Discontinued.
The crux of the issues here are mostly not the software. You can run 32-bit software on 64-bit POWER cpus without issue. What is really at play here is the fact that ppc32 hardware has absolutely no roadmap at all. IBM, Apple, Freescale, and Applied Micro have all essentially stopped developing new 32-bit PowerPC hardware, and nobody else has stepped in to continue that.
I think it's great that people are interested in keeping these kinds of machines running. However, without any sort of future hardware developments, I'm really concerned that putting in effort to support such old hardware is not a worthwhile investment. The machines you have will eventually break, and you can't replace them with anything else.
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have. I'm certainly not trying to dissuade you from pursuing your own interests, but asking the broader Fedora maintainer pool to help doesn't seem appropriate.
josh
On Monday, May 12, 2014, 11:11:49 AM, Josh Boyer wrote:
On Fri, May 9, 2014 at 11:46 AM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
Since this fall, I've been busy collecting information, and additional ppc hardware for testing, as well as attempting to install various current and obsolete ppc distributions.
I've now got the following Apple hardware: iMac 350 MHz
Released August 1998. Discontinued.
eMac G4 1 GHz (ATI)
Released April 2002. Discontinued.
PowerMac G4 dual 1GHz
Released January 2003. Discontinued.
Mini G4 1.5GHZ
Release September 2005. Discontinued.
PowerMac G5 1.6 GHz (AGP)
64-bit, so kind of irrelevant for this conversation.
about 1/2 dozen different ATI video cards for the PowerMacs
- Also have x86 variants of most to allow video driver validation and development on both architectures.
Within the last 2 months, I was able to pick up a pair of inexpensive IBM 7046-B50 (32-bit, CHRP) servers, so I can run AIX 5.3 to do
Released September 1999. Discontinued.
The crux of the issues here are mostly not the software. You can run 32-bit software on 64-bit POWER cpus without issue. What is really at play here is the fact that ppc32 hardware has absolutely no roadmap at all. IBM, Apple, Freescale, and Applied Micro have all essentially stopped developing new 32-bit PowerPC hardware, and nobody else has stepped in to continue that.
I think it's great that people are interested in keeping these kinds of machines running. However, without any sort of future hardware developments, I'm really concerned that putting in effort to support such old hardware is not a worthwhile investment. The machines you have will eventually break, and you can't replace them with anything else.
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have. I'm certainly not trying to dissuade you from pursuing your own interests, but asking the broader Fedora maintainer pool to help doesn't seem appropriate.
At work, we don't have application-level AIX systems anymore - only virtualized systems running in LPARs on larger systems. I suspect that nearly all of the ppc64 individual users are running on hardware that commercial users would consider to at least some degree vintage (or at least not mainstream).
This puts Power systems in an odd place between Fedora, Centos, and Redhat. It tends to limit the number of folks interested in working on Power systems in general to those with commercial interests, which means they may tend to be less interested in contributing to Fedora. As Fedora in general tends to be the incubator for new code and ideas for the other two, this may hurt the Power platform in general.
I'll agree that there is at times more affection than sanity involved with wanting to use or support vintage hardware.
The issue of supporting vintage hardware is not isolated to ppc32. There are quite a few folks who use x86 32-bit hardware who are running into the same issues in areas such as video support. There just happen to be far more users of Intel hardware than ppc (32-bit or 64-bit).
The intent is not to simply use Fedora resources, but to grow skills and experience that can also contribute to ppc64, x86 and x86_64. Proven packagers don't suddenly appear - they start contributing in their areas of interest and over time gain enough knowledge (and trust) to contribute to the community in a broader way.
Until now, the ppc64 maintainers have kept the ppc32 user land operational via multi-arch. They have also kept many of the core ppc32 core components in good shape too.
It may well be more appropriate to create a remix, targeted towards this ppc32 hardware. This remix could just be the core system, if the ppc32 userland components continued to exist in a viable form. Without that, the effort becomes more difficult, and the number of packages delivered drastically reduced.
On Mon, May 12, 2014 at 12:33 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Monday, May 12, 2014, 11:11:49 AM, Josh Boyer wrote:
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have. I'm certainly not trying to dissuade you from pursuing your own interests, but asking the broader Fedora maintainer pool to help doesn't seem appropriate.
At work, we don't have application-level AIX systems anymore - only virtualized systems running in LPARs on larger systems. I suspect that nearly all of the ppc64 individual users are running on hardware that commercial users would consider to at least some degree vintage (or at least not mainstream).
Very much no.
This puts Power systems in an odd place between Fedora, Centos, and Redhat. It tends to limit the number of folks interested in working on Power systems in general to those with commercial interests, which means they may tend to be less interested in contributing to Fedora.
On the contrary, the Fedora ppc64 efforts (more accurately POWER efforts) are driven in large part by the lone commercial interest in POWER today: IBM. They have put, and are continuing to put, significant resources into making sure Fedora runs well on POWER platforms.
As Fedora in general tends to be the incubator for new code and ideas for the other two, this may hurt the Power platform in general.
I disagree. The recent POWER8 open KVM announcements clearly underline the value of making POWER a more open platform, and that makes Fedora a great incubator for the future in those efforts.
I'll agree that there is at times more affection than sanity involved with wanting to use or support vintage hardware.
The issue of supporting vintage hardware is not isolated to ppc32. There are quite a few folks who use x86 32-bit hardware who are running into the same issues in areas such as video support. There just happen to be far more users of Intel hardware than ppc (32-bit or 64-bit).
Yes. I believe 32-bit intel will face the same issue, though several years down the road. Intel seems to want to cling to 32-bit hardware and make it even weirder (e.g. Quark) for some reason, but I suspect they'll eventually stop that at some point.
The intent is not to simply use Fedora resources, but to grow skills and experience that can also contribute to ppc64, x86 and x86_64.
I think that is a good idea in theory. In practice, I don't think it will actually pan out that way. The number of people that have access to x86_64 machines is significantly larger than ppc32, so whatever net-effect ppc32 has in growing the broader contributor base will be very small.
Proven packagers don't suddenly appear - they start contributing in their areas of interest and over time gain enough knowledge (and trust) to contribute to the community in a broader way.
Yes, true. At the same time, the existing packagers already have access to things that are much more relevant to the broader Fedora user base and package set. ppc32 (and to be fair, ppc64) is something many of them view as irrelevant, though they still try and fix issues that come up. It's a burden for them.
Until now, the ppc64 maintainers have kept the ppc32 user land operational via multi-arch. They have also kept many of the core ppc32 core components in good shape too.
It may well be more appropriate to create a remix, targeted towards this ppc32 hardware. This remix could just be the core system, if the ppc32 userland components continued to exist in a viable form. Without that, the effort becomes more difficult, and the number of packages delivered drastically reduced.
A remix for those interested would possibly be a great idea. I think several years ago Freescale had a Fedora-like/ish remix thing, but it's long since been abandoned internally there and it wasn't very public to begin with.
josh
On Monday, May 12, 2014, 1:05:55 PM, Josh Boyer wrote:
On Mon, May 12, 2014 at 12:33 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Monday, May 12, 2014, 11:11:49 AM, Josh Boyer wrote:
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have. I'm certainly not trying to dissuade you from pursuing your own interests, but asking the broader Fedora maintainer pool to help doesn't seem appropriate.
At work, we don't have application-level AIX systems anymore - only virtualized systems running in LPARs on larger systems. I suspect that nearly all of the ppc64 individual users are running on hardware that commercial users would consider to at least some degree vintage (or at least not mainstream).
Very much no.
This puts Power systems in an odd place between Fedora, Centos, and Redhat. It tends to limit the number of folks interested in working on Power systems in general to those with commercial interests, which means they may tend to be less interested in contributing to Fedora.
On the contrary, the Fedora ppc64 efforts (more accurately POWER efforts) are driven in large part by the lone commercial interest in POWER today: IBM. They have put, and are continuing to put, significant resources into making sure Fedora runs well on POWER platforms.
I'm aware of IBM's involvement.
I was an IBMer from 1979 to 2002, working in various roles from hardware test, test systems software, mainframe debuggers and the C/C++ compiler group. These days I develop a large server (low-level C, assembler) for RBC that runs on z/OS as well as some additional AIX projects.
The problem with one vendor doing most of the work is that there does not seem to be effective communications - this mailing list stands largely unuused.
As Fedora in general tends to be the incubator for new code and ideas for the other two, this may hurt the Power platform in general.
I disagree. The recent POWER8 open KVM announcements clearly underline the value of making POWER a more open platform, and that makes Fedora a great incubator for the future in those efforts.
I'll agree that there is at times more affection than sanity involved with wanting to use or support vintage hardware.
The issue of supporting vintage hardware is not isolated to ppc32. There are quite a few folks who use x86 32-bit hardware who are running into the same issues in areas such as video support. There just happen to be far more users of Intel hardware than ppc (32-bit or 64-bit).
Yes. I believe 32-bit intel will face the same issue, though several years down the road. Intel seems to want to cling to 32-bit hardware and make it even weirder (e.g. Quark) for some reason, but I suspect they'll eventually stop that at some point.
The intent is not to simply use Fedora resources, but to grow skills and experience that can also contribute to ppc64, x86 and x86_64.
I think that is a good idea in theory. In practice, I don't think it will actually pan out that way. The number of people that have access to x86_64 machines is significantly larger than ppc32, so whatever net-effect ppc32 has in growing the broader contributor base will be very small.
I've got 3 AMD and 1 Intel 64-bit systems (2 Fedora, 1 Win 7, 1 dual booted) under my desk right now. I just didn't mention those because they are not that noteworthy 8^).
Proven packagers don't suddenly appear - they start contributing in their areas of interest and over time gain enough knowledge (and trust) to contribute to the community in a broader way.
Yes, true. At the same time, the existing packagers already have access to things that are much more relevant to the broader Fedora user base and package set. ppc32 (and to be fair, ppc64) is something many of them view as irrelevant, though they still try and fix issues that come up. It's a burden for them.
Until now, the ppc64 maintainers have kept the ppc32 user land operational via multi-arch. They have also kept many of the core ppc32 core components in good shape too.
It may well be more appropriate to create a remix, targeted towards this ppc32 hardware. This remix could just be the core system, if the ppc32 userland components continued to exist in a viable form. Without that, the effort becomes more difficult, and the number of packages delivered drastically reduced.
A remix for those interested would possibly be a great idea. I think several years ago Freescale had a Fedora-like/ish remix thing, but it's long since been abandoned internally there and it wasn't very public to begin with.
Remixes seem to be more common these days for ARM. I know of the Pidora remix for Raspberry PI, since it is ARM6 and does not meet the hardware requirements for the current Fedora ARM architecture.
A remix does introduce the need to rework Fedora-branded elements, and adds a burden of syncing to rawhide changes on a regular basis. It would be useful to somehow continue to use the existing infrastructure.
On Mon, 2014-05-12 at 13:32 -0400, Al Dunsmuir wrote:
On Monday, May 12, 2014, 1:05:55 PM, Josh Boyer wrote:
On Mon, May 12, 2014 at 12:33 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Monday, May 12, 2014, 11:11:49 AM, Josh Boyer wrote:
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have. I'm certainly not trying to dissuade you from pursuing your own interests, but asking the broader Fedora maintainer pool to help doesn't seem appropriate.
The problem is that all the PPC32 hardware is pre V2 ISA. The 970 (G5) and PA6T are 64-bit and V2 ISA.
Since PowerISA-2.01 (POWER4) we have added ~470 (up to the current PowerISA-2.07 POWER8) new user mode instructions and several new facilities (Decimal Floating Point, Vector Scalar Extended / 64 float/vector register, Hardware Transactional Memory, Event Based Branch, Crypto, ...)
So how does keeping old PPC32 machines alive help the ecosystem, if that community can't help exploit the latest (last 10 years) PowerISA features?
At work, we don't have application-level AIX systems anymore - only virtualized systems running in LPARs on larger systems. I suspect that nearly all of the ppc64 individual users are running on hardware that commercial users would consider to at least some degree vintage (or at least not mainstream).
Very much no.
This puts Power systems in an odd place between Fedora, Centos, and Redhat. It tends to limit the number of folks interested in working on Power systems in general to those with commercial interests, which means they may tend to be less interested in contributing to Fedora.
On the contrary, the Fedora ppc64 efforts (more accurately POWER efforts) are driven in large part by the lone commercial interest in POWER today: IBM. They have put, and are continuing to put, significant resources into making sure Fedora runs well on POWER platforms.
I'm aware of IBM's involvement.
Are you really?
http://openpowerfoundation.org/ http://www.enterprisetech.com/2014/04/23/ibm-google-show-power8-systems-open...
IBM is moving aggressively to open up and expand the POWER ecosystem. But starting with 64-bit, Binary/Decimal Floating Point, and Vector.
I was an IBMer from 1979 to 2002, working in various roles from hardware test, test systems software, mainframe debuggers and the C/C++ compiler group. These days I develop a large server (low-level C, assembler) for RBC that runs on z/OS as well as some additional AIX projects.
The problem with one vendor doing most of the work is that there does not seem to be effective communications - this mailing list stands largely unuused.
As Fedora in general tends to be the incubator for new code and ideas for the other two, this may hurt the Power platform in general.
I disagree. The recent POWER8 open KVM announcements clearly underline the value of making POWER a more open platform, and that makes Fedora a great incubator for the future in those efforts.
I'll agree that there is at times more affection than sanity involved with wanting to use or support vintage hardware.
The issue of supporting vintage hardware is not isolated to ppc32. There are quite a few folks who use x86 32-bit hardware who are running into the same issues in areas such as video support. There just happen to be far more users of Intel hardware than ppc (32-bit or 64-bit).
Yes. I believe 32-bit intel will face the same issue, though several years down the road. Intel seems to want to cling to 32-bit hardware and make it even weirder (e.g. Quark) for some reason, but I suspect they'll eventually stop that at some point.
The intent is not to simply use Fedora resources, but to grow skills and experience that can also contribute to ppc64, x86 and x86_64.
I think that is a good idea in theory. In practice, I don't think it will actually pan out that way. The number of people that have access to x86_64 machines is significantly larger than ppc32, so whatever net-effect ppc32 has in growing the broader contributor base will be very small.
I've got 3 AMD and 1 Intel 64-bit systems (2 Fedora, 1 Win 7, 1 dual booted) under my desk right now. I just didn't mention those because they are not that noteworthy 8^).
Proven packagers don't suddenly appear - they start contributing in their areas of interest and over time gain enough knowledge (and trust) to contribute to the community in a broader way.
Yes, true. At the same time, the existing packagers already have access to things that are much more relevant to the broader Fedora user base and package set. ppc32 (and to be fair, ppc64) is something many of them view as irrelevant, though they still try and fix issues that come up. It's a burden for them.
Until now, the ppc64 maintainers have kept the ppc32 user land operational via multi-arch. They have also kept many of the core ppc32 core components in good shape too.
It may well be more appropriate to create a remix, targeted towards this ppc32 hardware. This remix could just be the core system, if the ppc32 userland components continued to exist in a viable form. Without that, the effort becomes more difficult, and the number of packages delivered drastically reduced.
A remix for those interested would possibly be a great idea. I think several years ago Freescale had a Fedora-like/ish remix thing, but it's long since been abandoned internally there and it wasn't very public to begin with.
Remixes seem to be more common these days for ARM. I know of the Pidora remix for Raspberry PI, since it is ARM6 and does not meet the hardware requirements for the current Fedora ARM architecture.
A remix does introduce the need to rework Fedora-branded elements, and adds a burden of syncing to rawhide changes on a regular basis. It would be useful to somehow continue to use the existing infrastructure.
ppc mailing list ppc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ppc
On 12/05/14 08:11 AM, Josh Boyer wrote:
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have.
Although I'm not involved with Fedora, my suggestion would be dropping ppc versions of heavyweight packages instead of doing a full phase out. There are plenty of window managers, text editors, image viewers, media players, etc whose stated goal is to not bloat over time. Isn't this one of the main advantages of free software?
On Tue, 13 May 2014 13:00:30 -0700 Connor Behan connor.behan@gmail.com wrote:
On 12/05/14 08:11 AM, Josh Boyer wrote:
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have.
Although I'm not involved with Fedora, my suggestion would be dropping ppc versions of heavyweight packages instead of doing a full phase out. There are plenty of window managers, text editors, image viewers, media players, etc whose stated goal is to not bloat over time. Isn't this one of the main advantages of free software?
this is not feasible, but anybody is free to take Fedora packages as an upstream and do a partial rebuild themselves
Dan
On Wednesday, May 14, 2014, 5:14:01 AM, Dan Horák wrote:
On Tue, 13 May 2014 13:00:30 -0700 Connor Behan connor.behan@gmail.com wrote:
On 12/05/14 08:11 AM, Josh Boyer wrote:
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have.
Although I'm not involved with Fedora, my suggestion would be dropping ppc versions of heavyweight packages instead of doing a full phase out. There are plenty of window managers, text editors, image viewers, media players, etc whose stated goal is to not bloat over time. Isn't this one of the main advantages of free software?
this is not feasible, but anybody is free to take Fedora packages as an upstream and do a partial rebuild themselves
That partial rebuild being known as a remix. The packages are restricted to largely what is within the Fedora git, but built in a different manner.
It really does sound like the practical solution for to the pcc32 situation. As a group, we need to come to an understanding of the rules for a remix, and the relationship between the remix and the parent distribution.
As in any situation where multiple groups work together on divergent goals, there will always be differences of opinion. While some may view the whole goal of the remix as a distraction and Pandora's box of problems waiting to happen, others will view it favourably (perhaps as a result of nostalgia, or their own active interest).
Over the next interval, the ppc64 folks have immediate taks to do to get the ppc64 alpha into shape. I think we can agree that is the most important task - the ppc32 remix effort can't get in the way of the official ppc64 Fedora release.
That being said, my hope would be that the ppc64 folks cooperate at least passively in helping the remix to achieve its goals. Fedora is not only the effective upstream for the remix, but it (or RedHat in general) is the actual upstream for many packages.
Actively removing support for ppc32 from packages presents such a problem. By some casual checks of Bugzilla, I know that the build environment, kernel and system configuration tools such as lorax have recent ppc32-specific fixes. Other tools such as pungi have had their ppc32 support (for Mac and CHRP) actively removed.
I would submit that removing the ability to do live CDs/DVDs has hurt ppc in general, as it makes testing more difficult for areas such as video driver and boot support. That would be a focus area for the remix.
It is not just Fedora where cooperation will be helpful. Perhaps working together we can revive some of the infrastructure around Fedora (such as RPM Fusion) for both. It would be nice to be able to have packages such as VLC available.
In any case, I'm sure the folks that have been around for a while can provide some history, insights and advise. I'm interested in hearing them!
My immediate task would be to research the formal rules for a Fedora remix, and the normal conventions - for build, source management of remix-specific changes such as remix-specific configuration files, required branding changes, patches (in some cases to restore stripped function), and spec files.
My understanding is that a remix can't actually be called Fedora. I don't know if this is so blank-and-white with the advent of copr and the new Fedora world. It would be nice if we could stay under the Fedora umbrella, but I suspect limiting the package set prevents that - perhaps folks with knowledge of this (on Fesco and otherwise) could provide input.
I think Pidora is a good model, as it is intended to reflect the main ARM release, simply built for ARM6 and using a package subset.
There are a number of areas where it would be useful if we could still have some minimal active involvement for specific packages and tools - gcc, binutils, kernel, build environment. This is really a case of wanting to make sure the upstream for the remix is able to build ppc32 code on an ongoing basis as the upstream package set advances.
For a number of these, it might well be appropriate to have a small formal set of Fedora ppc64 packages that would support builds targeting ppc32, to make it easier for the upstream to do problem analysis and fix validation under Fedora. The remix would build the ship the native versions.
Al
On 05/15/2014 02:05 AM, Al Dunsmuir wrote:
On Wednesday, May 14, 2014, 5:14:01 AM, Dan Horák wrote:
On Tue, 13 May 2014 13:00:30 -0700 Connor Behan connor.behan@gmail.com wrote:
On 12/05/14 08:11 AM, Josh Boyer wrote:
Even if build failures were the major problem, solving those isn't actually going to result in a working ppc32 platform. There's little invested in upstream software development on the platform. The software will bloat over time and grow beyond the resources these machines have.
Although I'm not involved with Fedora, my suggestion would be dropping ppc versions of heavyweight packages instead of doing a full phase out. There are plenty of window managers, text editors, image viewers, media players, etc whose stated goal is to not bloat over time. Isn't this one of the main advantages of free software?
this is not feasible, but anybody is free to take Fedora packages as an upstream and do a partial rebuild themselves
That partial rebuild being known as a remix. The packages are restricted to largely what is within the Fedora git, but built in a different manner.
It really does sound like the practical solution for to the pcc32 situation. As a group, we need to come to an understanding of the rules for a remix, and the relationship between the remix and the parent distribution.
As in any situation where multiple groups work together on divergent goals, there will always be differences of opinion. While some may view the whole goal of the remix as a distraction and Pandora's box of problems waiting to happen, others will view it favourably (perhaps as a result of nostalgia, or their own active interest).
Over the next interval, the ppc64 folks have immediate taks to do to get the ppc64 alpha into shape. I think we can agree that is the most important task - the ppc32 remix effort can't get in the way of the official ppc64 Fedora release.
That being said, my hope would be that the ppc64 folks cooperate at least passively in helping the remix to achieve its goals. Fedora is not only the effective upstream for the remix, but it (or RedHat in general) is the actual upstream for many packages.
Actively removing support for ppc32 from packages presents such a problem. By some casual checks of Bugzilla, I know that the build environment, kernel and system configuration tools such as lorax have recent ppc32-specific fixes. Other tools such as pungi have had their ppc32 support (for Mac and CHRP) actively removed.
I would submit that removing the ability to do live CDs/DVDs has hurt ppc in general, as it makes testing more difficult for areas such as video driver and boot support. That would be a focus area for the remix.
It is not just Fedora where cooperation will be helpful. Perhaps working together we can revive some of the infrastructure around Fedora (such as RPM Fusion) for both. It would be nice to be able to have packages such as VLC available.
In any case, I'm sure the folks that have been around for a while can provide some history, insights and advise. I'm interested in hearing them!
My immediate task would be to research the formal rules for a Fedora remix, and the normal conventions - for build, source management of remix-specific changes such as remix-specific configuration files, required branding changes, patches (in some cases to restore stripped function), and spec files.
My understanding is that a remix can't actually be called Fedora. I don't know if this is so blank-and-white with the advent of copr and the new Fedora world. It would be nice if we could stay under the Fedora umbrella, but I suspect limiting the package set prevents that
- perhaps folks with knowledge of this (on Fesco and otherwise) could
provide input.
I think Pidora is a good model, as it is intended to reflect the main ARM release, simply built for ARM6 and using a package subset.
There are a number of areas where it would be useful if we could still have some minimal active involvement for specific packages and tools - gcc, binutils, kernel, build environment. This is really a case of wanting to make sure the upstream for the remix is able to build ppc32 code on an ongoing basis as the upstream package set advances.
For a number of these, it might well be appropriate to have a small formal set of Fedora ppc64 packages that would support builds targeting ppc32, to make it easier for the upstream to do problem analysis and fix validation under Fedora. The remix would build the ship the native versions.
Al
Hi Al.
I don't know if it needs to be a remix, but maybe looking at it as a spin would be an option? I'm uncertain though if that would be feasible from a definition point, as iirc spins need to be created from packages officially built and signed in Fedora proper, which would not be the case anymore. It's for certain some gray area here where probably FESCO or our Fedora legal team will have better and more concrete answers.
Overall though the whole point is not preventing anyone to do 32bit PPC, quite the contrary. The bottom line as i tried to explain (probably badly so, apologies) is that the focus of the people currently actively working on making the Power platform happen in Fedora have eyes mainly on current and future technology of the Power platform, see Steven Munroe's email for more details. The point is rather that we therefore don't have the time anymore to do all this, so something had to give now. And the best time to do so is prior to branching and our mass rebuild for a release, which is scheduled to begin on June 6 and where everything needs to be prepared by May 26.
All that being said, as all of us have an interest in non Intel architectures we'll certainly be available for helping out with getting the infrastructure set up and running and we're available on IRC or via this email list if any questions come up.
Hope that clarifies some of the reasons why we want to do this.
Thanks & regards, Phil
On Thursday, May 15, 2014, 8:37:52 AM, Phil Knirsch wrote:
On 05/15/2014 02:05 AM, Al Dunsmuir wrote: I don't know if it needs to be a remix, but maybe looking at it as a spin would be an option? I'm uncertain though if that would be feasible from a definition point, as iirc spins need to be created from packages officially built and signed in Fedora proper, which would not be the case anymore. It's for certain some gray area here where probably FESCO or our Fedora legal team will have better and more concrete answers.
This is certainly a cloudy area, and as has been stated by others may be president setting in regards to x86 32-bit.
I would prefer some way for this to remain officially Fedora, so that a small group of folks can restore ppc32 to be useful, while not hurting ppc64 or the rest of Fedora.
I'll open a FESCO ticket, to ask what the allowed alternatives are, and what their views are as to the preferred approach.
Overall though the whole point is not preventing anyone to do 32bit PPC, quite the contrary. The bottom line as i tried to explain (probably badly so, apologies) is that the focus of the people currently actively working on making the Power platform happen in Fedora have eyes mainly on current and future technology of the Power platform, see Steven Munroe's email for more details. The point is rather that we therefore don't have the time anymore to do all this, so something had to give now. And the best time to do so is prior to branching and our mass rebuild for a release, which is scheduled to begin on June 6 and where everything needs to be prepared by May 26.
in my mind, we are dealing with an inverse Bell curve - where there are two population groups interested in the Power family of architectures, but they tend towards the extremes.
- Steven made it clear that the majority interest in the ppc64 port is in the leading edge of Power development. No one is arguing that.
- Others of us have some Mac and IBM power based hardware which all those involved agree is vintage, but which we still want to be able to use for a certain set of tasks. Just because. 8^)
Apple OS/X upgrades for the last ppc release (10.5) have basically dried up. We prefer Linux, most especially Fedora. We can't do installs or run Live CDs/DVDs, and no current Linux kernel or user-land is available. Heartbleed and the growing list of unpatched XP exploits make it clear that using old unmaintained code is unsafe.
All that being said, as all of us have an interest in non Intel architectures we'll certainly be available for helping out with getting the infrastructure set up and running and we're available on IRC or via this email list if any questions come up.
Hope that clarifies some of the reasons why we want to do this.
Thanks & regards, Phil
Hi all,
We've disabled ppc for rawhide/Fedora 21.
Ultimately the time for a remix would have been back in Fedora 18, when we first stopped creating PPC installer images and stated that MacPPC systems would no longer be supported. It was discussed, but no action was taken by the community.
Old power hardware in general is problematic to support. Even old PPC64 hardware such as the YDL PowerStation can't boot current versions of Fedora due to firmware bugs.
Development is active on modern PPC64 and the upcoming PPC64LE platforms, as we're a small team that's where our focus is.
best regards, David
On Friday, May 16, 2014, 11:27:28 AM, David Aquilina wrote:
We've disabled ppc for rawhide/Fedora 21.
Ultimately the time for a remix would have been back in Fedora 18, when we first stopped creating PPC installer images and stated that MacPPC systems would no longer be supported. It was discussed, but no action was taken by the community.
Sometimes it takes a while for folks to act, or for opportunity to knock. I came into the ppc32 world as a result of interest in supporting older video hardware on x86 32-bit and 64-bit.
Old power hardware in general is problematic to support. Even old PPC64 hardware such as the YDL PowerStation can't boot current versions of Fedora due to firmware bugs.
Installing and booting Mac G5s in 64-bit mode also seems problematic.
Development is active on modern PPC64 and the upcoming PPC64LE platforms, as we're a small team that's where our focus is.
Anyone who has been talking about continuing (or improving) ppc32 support in any way wants ppc64 to be hurt by a separate ppc64 effort.
I would submit that we are an even smaller group of people who happen to have a different focus, and would like the freedom to make our best shot at making ppc32 useful to us. There may even be a few folks who will choose to contribute to both efforts.
I am concerned when we are still in the early stages of talking about this, and there is already a post in the fedora kernel mailing list that strips the *ability* to build ppc32. That seems excessive.
Does the ppc64 team now object to using *any* Fedora resources (such as this mailing list) to talk about ppc32?
Al
Hello Al,
On Friday, May 16, 2014, 2:53:58 PM, Al Dunsmuir wrote:
Anyone who has been talking about continuing (or improving) ppc32 support in any way wants ppc64 to be hurt by a separate ppc64 effort.
Oh man - did I mangle that sentence! I meant to say:
Anyone who has been talking about continuing (or improving) ppc32 support in NO way wants ppc64 to be hurt by a separate ppc32 effort.
-
Al Dunsmuir -
Christian Zigotzky -
Connor Behan -
Dan Horák -
David Aquilina -
David Woodhouse -
Josh Boyer -
Phil Knirsch -
Steven Munroe