When are Qemu SPARC/PPC coming back?

[Nathaniel McCallum]

On Wed, Sep 14, 2011 at 8:13 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum
> <nathaniel at natemccallum.com> wrote:
>> The context for this question can be found here:
>> http://lists.fedoraproject.org/pipermail/virt-maint/2011-March/002289.html
>> https://bugzilla.redhat.com/show_bug.cgi?id=679179
>
>> What I'm not fine with is that there seems to be no desire to bring
>> these packages back. I spoke with several Red Hat virt people and the
>> consensus was that SPARC/PPC "don't work." I beg to differ. I am
>> building asm software on them right now. They are an invaluable
>> software testing platform, even with their relative age.
>>
>> So in short, can we please bring back SPARC/PPC? I realize that we'll
>> need a bit of build system magickery, but I really think its worth it.
>
> No.  Not magickery.  Basically, it needs a build-able openbios or SLOF
> (in the ppc case).  And since Fedora doesn't provide cross
> compilation, that is going to be hard to do in this case.
>
> As I see it, there is likely one option.  It is possible that we
> leverage the secondary architecture builders for PPC and SPARC and
> natively build the code, then allow an exception for i686/x86_64
> packages to use that natively built openbios/slof.  It would need
> FESCo approval, but exceptions for bootstrapping have been granted
> before.
>
> All of this is predicated on someone stepping forward to do the work.
> So far, we've found people that don't want to do the work but we need
> to work the opposite angle.

"No. Not magickery. ... Fedora doesn't provide cross compilation ..."

How is this not magickery? Heck, even the build them natively and
allow other arches to use them is magickery...

Of course, there is a second option, and one that require far less
work: use the binaries that qemu provides. Yes, I know its evil and
all that (and I agree). Except that in this case the binaries are made
form open code that's just hard to build (and absent investment in
infrastructure, won't get any easier) and for which upstream already
does the hard work. Further these binary firmwares are actually
running in an emulator and as such the possible damage is approaching
0. Will it be harder to debug? Maybe, but I doubt it. In fact, you
could make an argument that shipping the upstream bios builds is the
best way to get upstream support for our build.

I'm happy for this issue to go to FESCo, but I don't think this issue
should be dropped. Having the ability to test software on the
not-so-obscure PPC and SPARC (seriously, we ship sh4/m68k, but not
these two?) is a really important feature, the lack of which will cost
people real money (or worse, they'll just go to Debian/Ubuntu who seem
to have no problem packaging it).

And lastly, lest I just seem like I'm asking for stuff for free, let
me know what I can do to help.

Nathaniel