This fixes 1943ead268, which accidentally
removed the dev() function that generates the mesa-git-dev package..
causing mesa-dev to be pulled in in cases where mesa-dev is required
(and failing because mesa-dev is older)
[ci:skip-build]: already built successfully in CI
This addresses the issue here, but only for the devkit:
https://source.puri.sm/Librem5/linux-next/issues/114
I didn't patch the dts for the phone because:
1) I don't have one to test
2) it might negatively impact batter life (I'm only speculating)
[ci:skip-build]: already built successfully in CI
MP:[AL13]:maemo/gconf/APKBUILD:17:cd "$builddir" can be removed in phase 'build'
MP:[AL13]:maemo/gconf/APKBUILD:30:cd "$builddir" can be removed in phase 'check'
MP:[AL13]:maemo/gconf/APKBUILD:35:cd "$builddir" can be removed in phase 'package'
MP:[AL32]:maemo/gconf/APKBUILD:12:unnecesary usage of braces: ${pkgver}
main/gconf was removed upstream in Alpine:
0878ac0f6e
However, some packages in maemo/ (e.g. libhildon) still depend on it.
This breaks the package parsing in bpo: https://builds.sr.ht/~postmarketos/job/146132
ERROR: Package 'gconf-dev': Could not find aport, and could not find this package in any APKINDEX!
Add it to maemo/ for now to fix the error.
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
