Hello Josh,
On Friday, May 16, 2014, 2:50:15 PM, you wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
The powerpc secondary arch team has disabled all ppc32 builds in koji for F21 and beyond:
https://lists.fedoraproject.org/pipermail/ppc/2014-May/002801.html
There's little point in keeping support for ppc32 support in the kernel package when it will never be built. This also removes the -smp variant and with_smp* support, as that was only used on ppc32.
Josh,
In the fedora-ppc list you will also find that there are a number of us who are attempting to keep support for ppc32 active, and restore the ability to create new installations.
Yes. I've commented on the thread.
This may take the form of a remix - it has been suggested that we talk to Fesco, this this seems to set a precedent on how x84 32-bit might be treated in the future.
I doubt that. i686 will most like go to a secondary arch status like ppc64 is today. ppc32 has been demoted even further down than secondary arch, as the secondary arch team that was working on it no longer wishes to do so.
In essence, ppc32 is now analogous to sparc and ia64 in Fedora.
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
A core advantage for ppc32 is that one can still readily get hardware for a quite reasonable price locally or on EBay.
Because of branding, I would certainly prefer that ppc32 remain under the Fedora umbrella as a seconday-secondary tertiary architecture rather than be forced to become a remix.
We have no intention of preventing a successful Fedora 21 release for ppc64. A number of folks on the ppc64 team agree it is a useful goal (largely those with nostalgic feelings for vintage hardware). Others are more of the "take it out behind the barn and shoot it" category.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
I hope that we can prevent things from becoming as hopeless as sparc and ia64. Being a viable separate secondary arch for older hardware is certainly a better fate than a dead tertiary arch.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
As someone that actually was crazy enough to do this kind of thing when ppc/ppc64 was originally dropped, I would highly recommend you get on it immediately.
Trying. I likely spent too much time gathering a representative mix of hardware. Lesson learned.
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Al
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
Hello Josh,
On Friday, May 16, 2014, 2:50:15 PM, you wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
The powerpc secondary arch team has disabled all ppc32 builds in koji for F21 and beyond:
https://lists.fedoraproject.org/pipermail/ppc/2014-May/002801.html
There's little point in keeping support for ppc32 support in the kernel package when it will never be built. This also removes the -smp variant and with_smp* support, as that was only used on ppc32.
Josh,
In the fedora-ppc list you will also find that there are a number of us who are attempting to keep support for ppc32 active, and restore the ability to create new installations.
Yes. I've commented on the thread.
This may take the form of a remix - it has been suggested that we talk to Fesco, this this seems to set a precedent on how x84 32-bit might be treated in the future.
I doubt that. i686 will most like go to a secondary arch status like ppc64 is today. ppc32 has been demoted even further down than secondary arch, as the secondary arch team that was working on it no longer wishes to do so.
In essence, ppc32 is now analogous to sparc and ia64 in Fedora.
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
Great. I know someone that has the hardware too. We still removed support for both in the kernel spec because it was entirely moribund. Hardware availability is often secondary to sustained effort from people that have that hardware. History shows that people seem less interested in keeping it running when they have to do the work or go it alone in doing the work.
A core advantage for ppc32 is that one can still readily get hardware for a quite reasonable price locally or on EBay.
Because of branding, I would certainly prefer that ppc32 remain under the Fedora umbrella as a seconday-secondary tertiary architecture rather than be forced to become a remix.
Branding?
We have no intention of preventing a successful Fedora 21 release for ppc64. A number of folks on the ppc64 team agree it is a useful goal (largely those with nostalgic feelings for vintage hardware). Others are more of the "take it out behind the barn and shoot it" category.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
Outside build systems are probably going to be a requirement here. That is how ARM started, so it's not unreasonable. I doubt you're going to get Fedora Infrastructure to host any ppc32 hardware in the colo due to both space and configuration issues (they only take rack machines).
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
To be clear, whatever is built is entirely supported by the team doing the ppc32 work. Any bugs filed in Fedora bugzilla will get assigned to the contact person.
would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Cross-compiling is not allowed in Fedora anyway. Which is really unfortunate because it is actually a very useful thing to do in situations just like this.
josh
On Friday, May 16, 2014, 4:41:51 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
Because of branding, I would certainly prefer that ppc32 remain under the Fedora umbrella as a seconday-secondary tertiary architecture rather than be forced to become a remix.
Branding?
My understanding is that after a Fedora-based distribution varies too far from the standard Fedora build configuration, it becomes a remix and can no longer legally be called Fedora - they must pick a name, and modify everything with the Fedora trademark.
What we've been talking about is creating a pure Fedora ppc32 build, focussing on getting the packages on the critical path, installs and Live CD/DVD creation working again. The latter is important for getting the video back into shape.
Once the basics are running, then we have reached a point where more folks can begin to contribute and help get the remaining packages into shape, starting with what that contributor feels is important.
Al
On Friday, May 16, 2014, 4:41:51 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 2:50:15 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
Great. I know someone that has the hardware too. We still removed support for both in the kernel spec because it was entirely moribund.
That is reasonable.
Hardware availability is often secondary to sustained effort from people that have that hardware. History shows that people seem less interested in keeping it running when they have to do the work or go it alone in doing the work.
Human nature. We'll hope there is a different outcome.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
Outside build systems are probably going to be a requirement here. That is how ARM started, so it's not unreasonable. I doubt you're going to get Fedora Infrastructure to host any ppc32 hardware in the colo due to both space and configuration issues (they only take rack machines).
We need to see what can be done to make sure we can stay "Fedora" under those circumstances. Being forced to be a Fedora-like remix would be a shame if that is the only issue.
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
Entirely reasonable.
To be clear, whatever is built is entirely supported by the team doing the ppc32 work. Any bugs filed in Fedora bugzilla will get assigned to the contact person.
That's pretty well the way it is with ARM even now, whether they like it or not.
There is likely to be a rare occasion when ppc32 discovers an issue that also affects other builds. Reproducing on on X86, X86_64, or ppc64 should allow the problem to be addressed by the regular developers.
Worst case, providing a remote login seems to be the standard approach.
would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Cross-compiling is not allowed in Fedora anyway. Which is really unfortunate because it is actually a very useful thing to do in situations just like this.
That is the rule for release builds, but like ARM (and ARM64) sometimes you have to use cross-compilation during bring up.
Unlike ARM, ppc64 does support user processes running in ppc32 mode (via multi-arch). Do the current (up to today) ppc32 builds run on ppc32 hardware, or do they run on ppc64 machines via multi-arch?
If there is ppc32-only hardware, why can't we continue to use it?
Hi,
A-EON had sold a lot of new PA6T systems (http://www.a-eon.com/?page=nemo), last year. And there are lot of PA6T systems to buy (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=116...). It would be a pity to remove ppc32 support because 64-bit packages won't work. The PA6T is not compatible (enough) to Power5 or newer which is the minimum requirement for 64-bit Fedora to work.
A-EON Nemo board with the PA6T cpu: http://www.supertuxkart-amiga.de/amiga/x1000.html
Please don't remove the ppc32 support. I like Fedora very much and it would be a very pity to remove the ppc32 support.
Rgds,
Christian
Am 17.05.14 00:58, schrieb Al Dunsmuir:
On Friday, May 16, 2014, 4:41:51 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 2:50:15 PM, Josh Boyer wrote:
On Fri, May 16, 2014 at 2:37 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Friday, May 16, 2014, 12:22:26 PM, Josh Boyer wrote:
I know someone who has sparc, alpha hardware. I'm not sure if they have an ia64 box taking up space in a closet somewhere.
Great. I know someone that has the hardware too. We still removed support for both in the kernel spec because it was entirely moribund.
That is reasonable.
Hardware availability is often secondary to sustained effort from people that have that hardware. History shows that people seem less interested in keeping it running when they have to do the work or go it alone in doing the work.
Human nature. We'll hope there is a different outcome.
Making it so that ppc32 does not get built by default is one thing,
Actually, it's a very very big thing. Those wishing to keep it alive now need to come up with their own build hardware and build enviroment setup. This is by far the largest hurdle, and if it isn't done quickly the ppc32 secondary-secondary (thirdary?) arch will quickly fall behind and into disrepair.
Some folks have volunteered to host the builds, and provide build hardware. We'll see how that works out. If we do have to build outside the Fedora systems, there are going to be security considerations.
Outside build systems are probably going to be a requirement here. That is how ARM started, so it's not unreasonable. I doubt you're going to get Fedora Infrastructure to host any ppc32 hardware in the colo due to both space and configuration issues (they only take rack machines).
We need to see what can be done to make sure we can stay "Fedora" under those circumstances. Being forced to be a Fedora-like remix would be a shame if that is the only issue.
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
Entirely reasonable.
To be clear, whatever is built is entirely supported by the team doing the ppc32 work. Any bugs filed in Fedora bugzilla will get assigned to the contact person.
That's pretty well the way it is with ARM even now, whether they like it or not.
There is likely to be a rare occasion when ppc32 discovers an issue that also affects other builds. Reproducing on on X86, X86_64, or ppc64 should allow the problem to be addressed by the regular developers.
Worst case, providing a remote login seems to be the standard approach.
would best be used for builds, should "build native" and lack of a ppc32 cross compiler & binutils mean we can's use a ppc64 build host.
Cross-compiling is not allowed in Fedora anyway. Which is really unfortunate because it is actually a very useful thing to do in situations just like this.
That is the rule for release builds, but like ARM (and ARM64) sometimes you have to use cross-compilation during bring up.
Unlike ARM, ppc64 does support user processes running in ppc32 mode (via multi-arch). Do the current (up to today) ppc32 builds run on ppc32 hardware, or do they run on ppc64 machines via multi-arch?
If there is ppc32-only hardware, why can't we continue to use it?
ppc mailing list ppc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ppc
On Saturday, May 17, 2014, 8:52:55 AM, Christian Zigotzky wrote:
A-EON had sold a lot of new PA6T systems (http://www.a-eon.com/?page=nemo), last year. And there are lot of PA6T systems to buy (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=116...). It would be a pity to remove ppc32 support because 64-bit packages won't work. The PA6T is not compatible (enough) to Power5 or newer which is the minimum requirement for 64-bit Fedora to work.
ppc64 is focussing on modern 64-bit architecture levels, and likely wants to exploit the new instruction sets for best performance. That is entirely reasonable.
Some questions:
1) Is the PA6T Linux kernel that you have 32-bit, or 64 bit?
2) Could the PA6T, PowerMac G5, and older IBM pSeries use a common 64-bit kernel, built at a lower arch level? - PA Semi Dual-core PA6T-1682M is Power ISA v2.04 - My PowerMac G5 has an (IBM?) PowerPC 970 - Power ISA v2.02 - Alex's IBM pSeries 610 (Model 6C1) is POWER3-II
Such a kernel would support a 32-bit chroot environment suitable for initial ppc32 builds and development. Alternatively, multiple kernels would allow sharing the lowest common denominator 64-bit minimal core functionality but allow the G5 and PA6T to better exploit the hardware.
Supporting this seems like a reasonable parallel goal to build up core functionality for the lower architecture 64-bit processors, distinct from the mainstream ppc64. It would require a distinct arch name for the common (P3) and slightly higher (G5 and PA6T) levels - perhaps ppc64p3, ppc64g5 and ppc64pa6t respectively.
That being said, I'd still like the ppc32 support be the primary focus for the common user-land code that does not *have* to be 64-bit.
Note that a resurrected ppc32 Fedora would return to building in 32-bit chroots running under a mainstream ppc64 build in whatever modern hardware Fedora would make available. Similarly, the ppc64p3 would be built in 64-bit chroots (like mainstream ppc64, but using distinct build options).
A-EON Nemo board with the PA6T cpu: http://www.supertuxkart-amiga.de/amiga/x1000.html
Please don't remove the ppc32 support. I like Fedora very much and it would be a very pity to remove the ppc32 support.
It is basically gone, until we can bring it back.
The good news is that since Fedora ppc32 used the chroot environment for the builds, we don't have the worry that ppc32-specific build hardware is being scrapped.
On Sat, May 17, 2014 at 6:20 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Saturday, May 17, 2014, 8:52:55 AM, Christian Zigotzky wrote:
A-EON had sold a lot of new PA6T systems (http://www.a-eon.com/?page=nemo), last year. And there are lot of PA6T systems to buy (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=116...). It would be a pity to remove ppc32 support because 64-bit packages won't work. The PA6T is not compatible (enough) to Power5 or newer which is the minimum requirement for 64-bit Fedora to work.
ppc64 is focussing on modern 64-bit architecture levels, and likely wants to exploit the new instruction sets for best performance. That is entirely reasonable.
Some questions:
- Is the PA6T Linux kernel that you have 32-bit, or 64 bit?
They would have to be 64bit. It's a 64bit CPU and PowerPC doesn't do the 32-bit kernel on 64-bit hardware.
- Could the PA6T, PowerMac G5, and older IBM pSeries use a common 64-bit kernel, built at a lower arch level?
- PA Semi Dual-core PA6T-1682M is Power ISA v2.04
- My PowerMac G5 has an (IBM?) PowerPC 970 - Power ISA v2.02
- Alex's IBM pSeries 610 (Model 6C1) is POWER3-II
Such a kernel would support a 32-bit chroot environment suitable for initial ppc32 builds and development. Alternatively, multiple kernels would allow sharing the lowest common denominator 64-bit minimal core functionality but allow the G5 and PA6T to better exploit the hardware.
Supporting this seems like a reasonable parallel goal to build up core functionality for the lower architecture 64-bit processors, distinct from the mainstream ppc64. It would require a distinct arch name for the common (P3) and slightly higher (G5 and PA6T) levels - perhaps ppc64p3, ppc64g5 and ppc64pa6t respectively.
I'm not adding support to the kernel for any of those, sorry. The existing ppc64 kernel works fine on g5 and it should on pa6t. There's no way I'm enabling POWER3 support either.
Your proposal has gone from "continue with what is provided for ppc32 today" to "continue with what is provided for ppc32 today plus add 3 entirely new kernel builds." That is entirely unreasonable.
josh
Hello Josh,
On Saturday, May 17, 2014, 7:40:33 PM, you wrote:
On Sat, May 17, 2014 at 6:20 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
On Saturday, May 17, 2014, 8:52:55 AM, Christian Zigotzky wrote:
A-EON had sold a lot of new PA6T systems (http://www.a-eon.com/?page=nemo), last year. And there are lot of PA6T systems to buy (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=116...). It would be a pity to remove ppc32 support because 64-bit packages won't work. The PA6T is not compatible (enough) to Power5 or newer which is the minimum requirement for 64-bit Fedora to work.
ppc64 is focussing on modern 64-bit architecture levels, and likely wants to exploit the new instruction sets for best performance. That is entirely reasonable.
Some questions:
- Is the PA6T Linux kernel that you have 32-bit, or 64 bit?
They would have to be 64bit. It's a 64bit CPU and PowerPC doesn't do the 32-bit kernel on 64-bit hardware.
- Could the PA6T, PowerMac G5, and older IBM pSeries use a common 64-bit kernel, built at a lower arch level?
- PA Semi Dual-core PA6T-1682M is Power ISA v2.04
- My PowerMac G5 has an (IBM?) PowerPC 970 - Power ISA v2.02
- Alex's IBM pSeries 610 (Model 6C1) is POWER3-II
Such a kernel would support a 32-bit chroot environment suitable for initial ppc32 builds and development. Alternatively, multiple kernels would allow sharing the lowest common denominator 64-bit minimal core functionality but allow the G5 and PA6T to better exploit the hardware.
Supporting this seems like a reasonable parallel goal to build up core functionality for the lower architecture 64-bit processors, distinct from the mainstream ppc64. It would require a distinct arch name for the common (P3) and slightly higher (G5 and PA6T) levels - perhaps ppc64p3, ppc64g5 and ppc64pa6t respectively.
I'm not adding support to the kernel for any of those, sorry. The existing ppc64 kernel works fine on g5 and it should on pa6t. There's no way I'm enabling POWER3 support either.
Your proposal has gone from "continue with what is provided for ppc32 today" to "continue with what is provided for ppc32 today plus add 3 entirely new kernel builds." That is entirely unreasonable.
Josh,
My assembler-level background is zSeries and x84, where for the most part 32-bit software runs fine in 32-bit mode on 64-bit capable hardware.
I am also used to running 32-bit AIX user-land programs on 64-bit AIX. I know that ppc64 Linux will run ppc32 user-land programs (given the appropriate ppc32 libraries).
When Dennis said they used a 32-bit chroot on ppc64 for ppc32 builds, I made the assumption that Power hardware was the same. I was not aware of this limitation, so I obviously need to get more familiar with the Power processors at an instruction level.
Al
Am 18.05.14 00:20, schrieb Al Dunsmuir:
On Saturday, May 17, 2014, 8:52:55 AM, Christian Zigotzky wrote:
A-EON had sold a lot of new PA6T systems (http://www.a-eon.com/?page=nemo), last year. And there are lot of PA6T systems to buy (http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=116...). It would be a pity to remove ppc32 support because 64-bit packages won't work. The PA6T is not compatible (enough) to Power5 or newer which is the minimum requirement for 64-bit Fedora to work.
ppc64 is focussing on modern 64-bit architecture levels, and likely wants to exploit the new instruction sets for best performance. That is entirely reasonable.
Some questions:
- Is the PA6T Linux kernel that you have 32-bit, or 64 bit?
It's 64-bit. For example Ubuntu. We use a 32-bit userland with a 64-bit kernel.
On Fri, May 16, 2014 at 4:41 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, May 16, 2014 at 3:12 PM, Al Dunsmuir al.dunsmuir@sympatico.ca wrote:
but removing the ability to build ppc32 at all seems excessive, and certainly premature given the current situation.
Which is why I sent it as a patch instead of simply committed it. Discussion is requested. At a minimum though, I really would like to drop the -smp flavor because it was of very limited use even when ppc was a primary arch and it adds the most complication to the spec.
Thanks for clarifying that.
The problem with dropping smp is that I and other have smp hardware that we would like to use. That is also likely the hardware that
Yes, I've seen that. I'm willing to hold off on the removal for a bit to see how quickly your effort gets off the ground. I won't wait forever though.
So it's been not quite 2 months yet and I haven't seen or heard anything about this being worked on. How is the ppc32 effort going and who is working on it?
josh
-
Al Dunsmuir -
Christian Zigotzky -
Josh Boyer