Support for the downstream kernel has been removed entirely. This is
because the downstream kernel only has support for the armhf
architecture, whereas linux-postmarketos-qcom-msm8916 is only built
for aarch64. Since pmbootstrap has no way to handle having two
kernels on differing architectures, the decision was made to remove
the downstream kernel and only support mainline.
postmarketos-ui-sway already depends on xorg-server-xwayland for
X clients. There is no need to pull in the entire X server including
all necessary drivers.
This saves ~84 MiB of disk space when installing postmarketos-ui-sway
on asus-me176c. X applications are still working fine through Xwayland.
Also remove explicit dependency on dbus - it is already pulled in
by dependencies like lightdm or elogind and nothing in
postmarketos-ui-sway depends on it specifically.
The Intel graphics in asus-me176c have (incomplete) Vulkan support
in Mesa. Make it possible to use Vulkan by installing the Intel
driver that is necessary for it.
The mesa-dri-intel package is deprecated since it was replaced with
mesa-dri-classic and mesa-dri-gallium. Installing mesa-dri-intel
causes both packages to be installed.
The Intel graphics in asus-me176c are not supported by the new
Gallium "iris" driver, therefore asus-me176c can only use the old
i965 driver available in mesa-dri-classic.
Removing mesa-dri-gallium reduces the disk space needed for a minimal
installation on asus-me176c:
- Before: 329M
- After: 256M (-73M)
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...
silver