Remove ppc32 support

[Dennis Gilmore]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTdqhZAAoJEH7ltONmPFDRTGcQAMttKr8YBxs9cA4/dGB7sjEH
gCTMlbv9CLuJVm/b5EzqARfxrOCLTbc60s/3pAeGf+aZ+Wynj7XwRw64AjlylYlg
eX/n6thtSoAjkXILlxXTBWVerars+HEQLPBTduetnO1dgGXWFL7gfmgjeu4FiAji
8k8lb1MuBMGIEiuAmzDXykzI6qK+bBTiZ9KJqPtOu1cw6X9VaeIh7S9Achmk7tJF
pOwd1S/oHq2omORJQQL12UC55iinrv1ocBw3QRRP0LdUNfgNLBFw2RbB5vAcoulc
jfF52twwnKfTDM3gqZIGXcXru19AToHeNBzeKEmz0HHWbOkuEKSzITpkARcQM3vl
06EUqMrKofddpUIuhnxt4IgYomV3G7B12uJ4k2kQ5JzXIU+GgqALCC335n5slwAD
bg0faUNlmyBsk+Cjo9hD+H0gXCutl+DXQBF6F1vc145DrhQAd/hJ1jzUwGGRab7I
pSGwaiSt2RZRLWxVDkJQUAVvNnH/1An6QPy59T1JDv10yY8qC38Eh0O2nSH0EzI9
WQTS58MbpYMRVi0/o0aVxQlvF3ioUT5tWa9xGkFuzKFhvradLmdwUUhTtqSWKnzL
NM1Y/JotiM6oBYAS76Oi5gJL7I3gob792YUMx1r0coe9s0FatyA0e1+mwXvHZO54
ABlBpDbAfjczovHHw5Ek
=oafJ
-----END PGP SIGNATURE-----