Fedora: Support for new PA6T systems (ppc32)

Sat May 17 12:52:55 UTC 2014

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=1160). 
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 at 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 at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ppc