-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 16 May 2014 18:58:14 -0400 Al Dunsmuir <al.dunsmuir@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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----- _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
