We need to generate the splash screens separately for each device,
because they are specific to the device's display resolution.
At the moment we do this dynamically during the installation process.
This has the advantage that there is no need to re-build all device
packages when one of the splash screen is changed (or a new one is added).
In reality, however, the splash screens do not change very frequently.
On the other hand, generating the splash screens dynamically has signficant
disk usage overhead for a minimal ("none" UI) rootfs:
The Python interpreter together with the necessary libraries requires
about ~60 MB of disk space on aarch64.
The splash screens itself require about ~100 KB for 720x1280.
This is not necessary if we move the splash screen generation into
devicepkg-dev, which is used to build the device package for all devices.
Another advantage is that we no longer need the (rather complicated)
caching mechanism for splash screens - so we actually end up with less
lines than before.
rootfs size for samsung-a5ulte ("none" UI):
Before: 450M
After: 388M (-62M)
After this change, every(!) device package needs to be rebuilt once.
No changes are necessary in device packages.
This was only needed to load the ALSA PulseAudio plugin outside
the chroot when running QEMU. Now that we allow configuring the
QEMU PulseAudio backend directly this is no longer needed.
At the moment, installing the rootfs for ouya-ouya fails with:
ERROR: unsatisfiable constraints:
libdrm-grate-2.4.100_git20191221-r0:
conflicts: libdrm-2.4.100-r0[libdrm]
libdrm-2.4.100-r0[so:libdrm.so.2=2.4.0]
libdrm-2.4.100-r0[so:libdrm_tegra.so.0=0.0.0]
libdrm-2.4.100-r0[so:libkms.so.1=1.0.0]
satisfies: device-ouya-ouya-1-r12[libdrm-grate]
libvdpau-tegra-0_git20190315-r0[libdrm-grate]
.pmbootstrap-20200110.144341[libdrm-grate]
.pmbootstrap-20200110.144341[libdrm]
mesa-gl-19.3.2-r0[so:libdrm.so.2]
directfb-1.7.7-r1[so:libdrm.so.2]
directfb-1.7.7-r1[so:libkms.so.1]
mesa-dri-swrast-19.3.2-r0[so:libdrm.so.2]
mesa-19.3.2-r0[so:libdrm.so.2]
libdrm-2.4.100-r0:
conflicts: libdrm-grate-2.4.100_git20191221-r0
libdrm-grate-2.4.100_git20191221-r0[so:libdrm.so.2=2.4.0]
libdrm-grate-2.4.100_git20191221-r0[so:libdrm_tegra.so.0=0.0.0]
libdrm-grate-2.4.100_git20191221-r0[so:libkms.so.1=1.0.0]
satisfies: .pmbootstrap-20200110.144341[libdrm]
mesa-gl-19.3.2-r0[so:libdrm.so.2]
directfb-1.7.7-r1[so:libdrm.so.2]
directfb-1.7.7-r1[so:libkms.so.1]
mesa-dri-swrast-19.3.2-r0[so:libdrm.so.2]
mesa-dri-swrast-19.3.2-r0[so:libdrm_amdgpu.so.1]
mesa-dri-swrast-19.3.2-r0[so:libdrm_nouveau.so.2]
mesa-dri-swrast-19.3.2-r0[so:libdrm_radeon.so.1]
mesa-19.3.2-r0[so:libdrm.so.2]
mesa-19.3.2-r0[so:libdrm_amdgpu.so.1]
mesa-19.3.2-r0[so:libdrm_nouveau.so.2]
mesa-19.3.2-r0[so:libdrm_radeon.so.1]
Looking closer at the error we see that:
1. We want to explicitly install libdrm-grate for device-ouya-ouya.
2. libdrm-grate provides
- so:libdrm.so.2=2.4.0
- so:libdrm_tegra.so.0=0.0.0
- so:libkms.so.1=1.0.0
3. But the mesa package also builds AMD and Nouveau drivers and
therefore requires:
- so:libdrm_amdgpu.so.1
- so:libdrm_nouveau.so.2
- so:libdrm_radeon.so.1
These libraries are not provided by libdrm-grate, therefore it is impossible
to install mesa and libdrm-grate at the same time.
A simple solution to fix this problem is to let libdrm-grate provide
these additional libraries as well - the package size overhead is negligible
and the additional drivers build just fine.
[ci:skip-build]: already built successfully in CI
mesa-git-dri-gallium covers all Gallium DRI drivers
(including lima and kmsro).
Also mesa-git-dri-gallium now depends directly on all relevant
mesa-git subpackages, so the subpackages do not need to be specified
in each device APKBUILD anymore.
mesa-git-dri-gallium covers all Gallium DRI drivers
(including lima and kmsro).
Also mesa-git-dri-gallium now depends directly on all relevant
mesa-git subpackages, so the subpackages do not need to be specified
in each device APKBUILD anymore.
mesa-git-dri-gallium covers all Gallium DRI drivers
(including lima and kmsro).
Also mesa-git-dri-gallium now depends directly on all relevant
mesa-git subpackages, so the subpackages do not need to be specified
in each device APKBUILD anymore.
At the moment, every device that wants to make use of mesa-git needs
to depend on all relevant mesa-git subpackages.
We can simplify this by adding these directly as depends for the
-dri- package that most devices will be depending on. That way,
the fact that you need to depend on all relevant subpackages is
mostly hidden away as "implementation detail" in the mesa-git
package, and no special care is required when using mesa-git.
I'm not sure how this package even worked before... The install location
on the second loop was invalid as the "$fw" variable would result to
nothing. This would normally cause all files in that loop to be named
the same...
This renamed the u-boot package for Purism librem5 devices, since the
phone and devkit share the same u-boot version. It also updates the
various components to the latest versions
