These packages were previously built by a WIP abuild patch that added
install scripts to each -systemd subpkg for handling preset application
on install and symlink cleanup on uninstall. This functionality has been
replaced by a trigger/commit hook, so we need to rebuild these packages
to drop the install scripts that were previously generated.
[ci:ignore-count]
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6892
A recent(?) update in shellcheck made this fail, possibly because the
test in shellcheck was fixed(?) or ???
The failure this fixes is:
Test with shellcheck: ./main/msm-firmware-loader/msm-firmware-loader.sh
In msm-firmware-loader.sh line 49:
if [ -z "${FW_PARTITIONS##*$PARTNAME*}" ] && [ -n "$PARTNAME" ]
^-------^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
[ci:skip-build] already built successfully in CI
firmware-qcom-msm8916-wcnss is a virtual package used for MSM8916
devices without secure boot (i.e. device that do not require signed
firmware). For those it's best to install more recent firmware by
default rather than using the firmware on the firmware partition.
firmware-qcom-msm8916-wcnss is provided by firmware-qcom-db410c-wcnss
by default, however it's still useful to make it possible to switch to
the stock firmware on the firmware partition if needed. To allow that,
add a dummy msm-firmware-loader-wcnss package that provides the virtual
package using the msm-firmware-loader.
# apk add msm-firmware-loader-wcnss
(1/2) Purging firmware-qcom-db410c-wcnss (1034.2.1-r2)
(2/2) Installing msm-firmware-loader-wcnss (1-r1)
Many devices need proprietary firmware blobs. So far those blobs were
packaged and installed from the repository but this approach has many
drawbacks:
- The rootfs can only be used on a single device model.
- If a model has multiple variants that have diferent secire-boot key,
each must have it's own firmware blobs.
This makes maintaining packaged firmware very hard and outweights the
benefits of having a repeatable installation in most cases.
Instead we can load blobs dynamically from preexisting firmware
partitions that usually have same structure and contain the blobs we are
interested in.
The proposed scripts place symlinks to the blobs in a special dir that
then given to the kernel. Blobs from firmware/postmarketos (or another
dir that was set as extra path prior the script execution) will take
priority which allows to override some blobs (e.g. for deviecs with no
secure-boot)
Achill Gilgenast