On Wed, Sep 14, 2011 at 8:45 PM, Nathaniel McCallum <nathaniel@xxxxxxxxxxxxxxxx> wrote: > On Wed, Sep 14, 2011 at 8:13 PM, Josh Boyer <jwboyer@xxxxxxxxx> wrote: >> On Wed, Sep 14, 2011 at 7:29 PM, Nathaniel McCallum >> <nathaniel@xxxxxxxxxxxxxxxx> 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... Not it's not. You build them as noarch. It's not magic at all. > 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. You could try and get an exception from FESCo for that, yes. I'm not sure it would be approved until someone actually tries building them first. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
