On Wed, Sep 14, 2011 at 9:12 PM, Josh Boyer <jwboyer@xxxxxxxxx> wrote: > 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. Care to walk me through the process? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
