Bug 1734179
| Summary: | Cannot be installed due to unsatisfied 'bitfrost' dependency | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
| Component: | dracut-modules-olpc | Assignee: | Daniel Drake <dsd> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 31 | CC: | chris, dsd, kevin, lsedlar, mboddu, pbrobinson, robatino, yajosev |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | AcceptedBlocker openqa | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-09-11 00:10:32 UTC | Type: | Bug |
| 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: | 1674828 | ||
| Bug Blocks: | 1644937, 1737929 | ||
|
Description
Adam Williamson
2019-07-29 21:27:54 UTC
Why is dracut-modules-olpc on the server DVD? It's not listed in comps and "dnf repoquery --whatrequires dracut-modules-olpc" returns nothing. Both as I would have expected. I don't see anything of note in kickstarts. Is anaconda doing something like dracut* as part of it's includes? I am honestly not at all sure. This isn't the install environment, it's the packages included on the Server DVD for installation. I can't find a comps entry or dependency that would cause this either, but it definitely *is* there, you can see it in the Server tree too: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190729.n.0/compose/Server/x86_64/os/Packages/d/dracut-modules-olpc-0.7.6-13.fc29.x86_64.rpm Oh, think I found it... https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_130 pungi docs say:
**additional_packages**
(*list*) -- additional packages to be included in a variant and
architecture; format: ``[(variant_uid_regex, {arch|*: [package_globs]})]``
The packages specified here are matched against RPM names, not any other
provides in the package not the name of source package. Shell globbing is
used, so wildcards are possible. The package can be specified as name only
or ``name.arch``.
(In reply to Adam Williamson from comment #4) > Oh, think I found it... > > https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_130 Yea, that's wrong, it would pull in all sorts of things: dracut.x86_64 049-26.git20181204.fc30 @fedora dracut-config-rescue.x86_64 049-26.git20181204.fc30 @fedora dracut-network.x86_64 049-26.git20181204.fc30 @fedora dracut-squash.x86_64 049-26.git20181204.fc30 @fedora dracut-caps.x86_64 049-26.git20181204.fc30 fedora dracut-config-generic.x86_64 049-26.git20181204.fc30 fedora dracut-kiwi-lib.noarch 9.18.9-1.fc30 updates dracut-kiwi-live.noarch 9.18.9-1.fc30 updates dracut-kiwi-oem-dump.noarch 9.18.9-1.fc30 updates dracut-kiwi-oem-repart.noarch 9.18.9-1.fc30 updates dracut-kiwi-overlay.noarch 9.18.9-1.fc30 updates dracut-live.x86_64 049-26.git20181204.fc30 fedora dracut-modules-olpc.x86_64 0.7.6-13.fc29 fedora dracut-tools.x86_64 049-26.git20181204.fc30 fedora EG we probably don't want kiwi either yeah, all those things do seem to be in the Server tree. The wildcard has been in the tree since the beginning, it seems, though it was originally incorrect and fixed by lsedlar in 2016. This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31. Filed https://pagure.io/pungi-fedora/issue/759 for the pungi-fedora side of this. I was testing a change to pungi-fedora config to fix this, but it seems the dracut-modules-olpc was retired/blocked on 2019-09-08, so I think this problem is fixed by that. Can you confirm? Indeed. Not sure why this bug wasn't automatically closed or anything, but never mind. The mediakit tests are passing in openQA, so this looks like it's resolved indeed. |