Bug 679179
| Summary: | openbios-ppc subpackage, which qemu depends on, disappeared | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
| Component: | openbios | Assignee: | Justin M. Forbes <jforbes> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | circular, darrellpf, dennis, dgoodwin, gcosta, henrik, jforbes, jlaska, karsten, misek, ondrejj, pbonzini, tcallawa, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | repoclosure_hash:f7c97270b4749e194419d39ae72cb0987d727c85555a2dd2f4064d317cfbe4cc AcceptedBlocker | ||
| 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 04:22:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 657618 | ||
|
Description
Adam Williamson
2011-02-21 19:55:37 UTC
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. May be problem is, that koji does not run noarch builds on ppc, then ifarch ppc does never evaluate. *** Bug 682453 has been marked as a duplicate of this bug. *** 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)". 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. 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. 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? kev: yeah, that's how I understood it too. 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. 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. 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? "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? (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. 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. 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. 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? So it seems we are going to drop the ppc support from qemu? I can make that update today. (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. for the record it doesnt effect the compose, its been broken since the mass rebuild pre-Alpha. 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 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). 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. QEMU 0.15 supports pSeries emulation, so it makes sense to add back PPC support for F16. Is there openbios code for that? 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.
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. |