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... 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
