So I'm trolling around for space savings (again) and my eye alighted on /lib/firmware/qcom . Under here we have: [root@localhost-live qcom]# du -h 556K ./vpu-1.0 588K ./vpu-2.0 360K ./venus-5.4 344K ./venus-5.2 6.9M ./sc8280xp/LENOVO/21BX 6.9M ./sc8280xp/LENOVO 6.9M ./sc8280xp 352K ./venus-4.2 372K ./venus-1.8 6.5M ./apq8096 4.0K ./LENOVO 6.4M ./sdm845 6.1M ./sm8250 29M . looking at the WHENCE file, the chunky things there - sc8280xp, apq8096, sdm845, sm8250 - are all related to ARM devices, but we're shipping them on all arches as they're just part of linux-firmware. Can we maybe split these out to a subpackage or something so we can exclude it from arches other than x86_64? is it possible that we don't care about any of those platforms so we could drop them entirely?
er, I meant "other than aarch64", obviously.
Can probably argue the same for most intel firmwares, I do actually have a bunch of patches to split out them and others, just not got up the priority list to finish it up yet.
yeah, that's true - we already split out some intel ones, right? but we could do the rest. I can do some work on this and send a PR if you like.
The kernel does automatically emit this information; modinfo will tell you what firmware a given module may need. We *could* theoretically turn that into dependencies for the kernel or kernel-modules RPMs. And split the firmware packages up accordingly. Although I don't think we want hard dependencies. Maybe we could pull in the kernel as a build dep and then build the file lists for a linux-firmware-core and linux-firmware-extra-modules from the modules in each kernel package...?
well...it's *sort of* automatic, but in point of fact it's a bit fragile, because the lists for most drivers (at least the ones I've looked at) aren't really generated from the code that actually does the firmware loading. They tend to be separate, which means they can be lies. Also, we want to do splits that go beyond where the modules live. For instance, we split out the firmwares for some big-iron network modules into their own separate packages because they're huge and almost never needed.
> They tend to be separate, which means they can be lies If that's a genuine concern, then we should fix the kernel so that request_firmware() of a filename not listed in MODULE_FIRMWARE() will emit a warning. That shouldn't be so hard, surely? And yeah, I don't necessarily think we want to have a hard split on RPM packaging boundaries, but we *can* (with the above concern addressed) decide that certain firmware blobs can be entirely omitted for a given architecture. We might want to be slightly careful around kernel versions; a new kernel might use a new version of firmware that the previous one didn't. But it *should* fall back to the old version in that case, unless it's a completely new driver.
FEDORA-2023-85168977a9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-85168977a9
FEDORA-2023-d15f5a186a has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d15f5a186a
FEDORA-2023-d15f5a186a has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d15f5a186a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d15f5a186a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-85168977a9 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-85168977a9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-85168977a9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-d15f5a186a has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
Cool, we just need to remember to make changes to comps / lorax templates now.
FEDORA-2023-eabbf4ca4d has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-eabbf4ca4d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-eabbf4ca4d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Peter already made qcom-firmware specific to aarch64 in comps when adding it. https://github.com/weldr/lorax/pull/1338 should do the same for lorax.
(In reply to Adam Williamson from comment #12) > Cool, we just need to remember to make changes to comps / lorax templates > now. For reference I did do a PR for comps: https://pagure.io/fedora-comps/pull-request/864
FEDORA-2023-eabbf4ca4d has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
I think getting a lorax build with https://github.com/weldr/lorax/pull/1338 in it would help a lot here: we have 36M of qualcomm firmware in the x86_64 ISO.
grrr, wrong bug, ignore above comment.