Bug 679179 - openbios-ppc subpackage, which qemu depends on, disappeared
openbios-ppc subpackage, which qemu depends on, disappeared
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openbios (Show other bugs)
15
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Justin M. Forbes
Fedora Extras Quality Assurance
repoclosure_hash:f7c97270b4749e194419...
:
: 682453 (view as bug list)
Depends On:
Blocks: F15Beta/F15BetaBlocker
  Show dependency treegraph
 
Reported: 2011-02-21 14:55 EST by Adam Williamson
Modified: 2011-08-18 16:58 EDT (History)
14 users (show)

See Also:
Fixed In Version: qemu-0.14.0-7.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-03 00:22:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2011-02-21 14:55:37 EST
In all openbios builds since openbios-1.0-2.fc12 , the openbios-ppc subpackage has gone missing. It's not present in openbios-1.0-3.fc15 , openbios-1.0-4.1031.fc16 or openbios-1.0-4.1031.fc15 . 

The whole handling of all these arch-specific subpackages seems horribly weird:

%ifarch ppc ppc64
%package ppc
Summary: OpenBIOS for ppc
BuildArch: noarch

if it's BuildArch: noarch why does it only even *exist* on specific buildarches? That doesn't seem to make any sense at all.

Anyway, the practical upshot of this is to break qemu's dep chain. If I try and update my F15 machine, it fails due to the missing openbios-ppc. If I try 'yum remove openbios-ppc' to clear the blockage, I see that qemu-system-ppc relies on openbios-ppc , and qemu relies on qemu-system-ppc . So removing openbios-ppc kills qemu.
Comment 1 Justin M. Forbes 2011-03-04 13:32:15 EST
Right, there are build problems with ppc for some reason, we are trying to figure them out, but not having an actual build root to test in or knowing what is in that build root make it a bit more painful.
Comment 2 Jan ONDREJ 2011-03-04 13:53:12 EST
May be problem is, that koji does not run noarch builds on ppc, then ifarch ppc does never evaluate.
Comment 3 Vaclav "sHINOBI" Misek 2011-03-06 08:04:08 EST
*** Bug 682453 has been marked as a duplicate of this bug. ***
Comment 4 Adam Williamson 2011-03-16 14:48:48 EDT
This should block the Beta release, I believe it will affect DVD compose and also will break criterion "The release must boot successfully as a virtual guest in a situation where the virtual host is running the same release (using Fedora's current preferred virtualization technology)".
Comment 5 Adam Williamson 2011-03-18 13:56:33 EDT
Discussed at 2011-03-18 blocker review meeting, accepted as blocker as per criteria referenced above. We need some firepower to get this resolved ASAP, so CCing dgilmore for releng and Karsten from PPC team to help out. Thanks.
Comment 6 Karsten Hopp 2011-03-18 15:57:02 EDT
I don't think this can be handled a build time. As Jan already said in comment #2,
%ifarch ppc ppc64 is only true if the build happens to be on a ppc machine.
Maybe we can build openbios-ppc on all archs (by removing the %ifarch ppc) and exclude this subpackage at compose time for a ll non-ppc archs.
Or just ship it on all archs, even if it doesn't get used on non-PPC archs.
Comment 7 Kevin Kofler 2011-03-18 18:57:30 EDT
Is the reason for the %ifarch really that we only want to ship the package on PPC archs? Isn't qemu-system-ppc and thus openbios-ppc useful on ANY arch? Wasn't the %ifarch added because a PPC toolchain is needed to build this, with the (possibly false) expectation that the output from the PPC buildsys somehow magically gets imported into the primary Koji instance?
Comment 8 Adam Williamson 2011-03-18 21:54:50 EDT
kev: yeah, that's how I understood it too.
Comment 9 Jan ONDREJ 2011-03-19 15:36:07 EDT
You should ask releng to start build for this package on ppc, or prefer ppc build for this package.

Maybe you should add ppc bios binary to sources and if ppc compilation utilities are not available on package compile time, fallback to binary. I think you should ask for an exception for this in packaging guidelines.
Comment 10 Dennis Gilmore 2011-03-20 14:43:37 EDT
this package needs special handling, we need to build openbios on ppc and sparc and import the resulting rpms into the primary koji  as they need native compilation.  they are the openfirmware implementations  used by qemu.  it just happened that the ppc build failed. we probably should do the builds on ppc and sparc then do the build on the primary arches, the mass build scripts should be updated to handle this. 

we may need to just untag the mass rebuild build unless we can get it building again.
Comment 11 Jan ONDREJ 2011-03-20 16:47:54 EDT
And what's wrong with adding binary blobs to source packages? Looking at packaging guidelines, you can build rpm binaries from source binaries for firmwares. Is BIOS a firmware? I think it is.

You can build openbios binaries using mock for sparc, ppc, ... all required archs, then add them to the source package. For each arch, try to build from source, if it fails, just copy prebuild binaries from source.

Does this met packaging guidelines?
Comment 12 Adam Williamson 2011-03-20 18:17:18 EDT
"Is BIOS a firmware? I think it is."

Per our guidelines, I'm not actually sure. I think we consider things to be 'firmware' that are not executed on the host processor. BIOS is executed on the host processor, isn't it?
Comment 13 Jan ONDREJ 2011-03-21 03:52:49 EDT
(In reply to comment #12)
> "Is BIOS a firmware? I think it is."
> 
> Per our guidelines, I'm not actually sure. I think we consider things to be
> 'firmware' that are not executed on the host processor. BIOS is executed on the
> host processor, isn't it?

Not exactly. It's executed on the guest virtual CPU. Especially if guest has different architecture than guest, it's emulated and does not run directly on host CPU. For same arch, you can compile binaries form source without problems.
Comment 14 Tom "spot" Callaway 2011-03-24 15:18:23 EDT
So, I talked to Josh Boyer, and he pointed out that the qemu ppc support was prep only, and that almost nothing supports prep anymore, not even Fedora PPC. His recommendation was to simply not bother building the qemu-system-ppc* bits, and I'm inclined to agree with him.
Comment 15 Adam Williamson 2011-03-25 13:40:29 EDT
as long as the dependencies are lined up, that would be fine by me. as far as release blocking goes, we really only need this to be 'fixed' insofar as the dependencies are cleared up so upgrades work, DVD composes work, and virtualization works.
Comment 16 Adam Williamson 2011-03-25 13:46:39 EDT
Discussed at 2011-03-25 blocker review meeting. Looks like this is in progress, but please note the TC compose is scheduled for Tuesday, and we may need this fixed by then to do a successful compose, as it affects the DVD package set. dgilmore, is that the case?
Comment 17 Justin M. Forbes 2011-03-28 15:12:19 EDT
So it seems we are going to drop the ppc support from qemu? I can make that update today.
Comment 18 Tom "spot" Callaway 2011-03-28 15:16:19 EDT
(In reply to comment #17)
> So it seems we are going to drop the ppc support from qemu? I can make that
> update today.

Yep. This is the simplest resolution.
Comment 19 Dennis Gilmore 2011-03-28 15:45:12 EDT
for the record it doesnt effect the compose, its been broken since the mass rebuild pre-Alpha.
Comment 20 Fedora Update System 2011-03-29 18:16:46 EDT
qemu-0.14.0-7.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/qemu-0.14.0-7.fc15
Comment 21 Fedora Update System 2011-03-29 22:24:36 EDT
Package qemu-0.14.0-7.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing qemu-0.14.0-7.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/qemu-0.14.0-7.fc15
then log in and leave karma (feedback).
Comment 22 Fedora Update System 2011-04-03 00:22:22 EDT
qemu-0.14.0-7.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Paolo Bonzini 2011-07-26 06:26:29 EDT
QEMU 0.15 supports pSeries emulation, so it makes sense to add back PPC support for F16.
Comment 24 Tom "spot" Callaway 2011-07-26 10:31:51 EDT
Is there openbios code for that?
Comment 25 Paolo Bonzini 2011-07-26 11:11:34 EDT
It uses Slimline Open Firmware ("SLOF"), which has the same problem as OpenBIOS of requiring native compilation.  There is a git repository for the source.

Precompiled binaries for both openbios and SLOF are included in QEMU releases.
Comment 26 Henrik Nordström 2011-08-18 16:58:05 EDT
I also miss the Sparc32 support which got disabled due to this openbios dependency.

I would too agree that the OpenBIOS/SLOF should be seen as a kind of firmware with available source. As noted they do run in the emulated CPUs. Should be sufficient to meet Fedoras freedom requirements that source IS available and the distributed builds can be verified to match the source, even if rebuilding the source is a little tricky and can not be done in an automated manned by the build farm.

According to OpenBIOS 1.0 docs it can cross-compile just fine. But obviously needs compilers for the target architecture. Fedora do not ship cross-compilers for any of these arches which is the actual reason to why the package can not be rebuilt the normal way.

Note You need to log in before you can comment on or make changes to this bug.