Remove ppc32 support

[Al Dunsmuir]

On Friday, May 16, 2014, 8:07:47 PM, Dennis Gilmore wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> On Fri, 16 May 2014 18:58:14 -0400
> Al Dunsmuir <al.dunsmuir at sympatico.ca> wrote:

>> 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.
> cross compilation is the only way to bring up a new architecture

>> 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?

> The builds today happen in a 32 bit chroot on 64 bit hardware. the
> chroot is made from scratch every build just as all the other arches
> are.

> Dennis

That's  very good news.   It means physical ppc32 hosting was not used
up  to now on ppc32, and a resurrected ppc32 should be able to play by
the same rules.