On Friday, May 16, 2014, 8:07:47 PM, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 16 May 2014 18:58:14 -0400
Al Dunsmuir <al.dunsmuir(a)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(a)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(a)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
> Worst case, providing a remote login seems to be the standard
> >> 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
> (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
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.