Plasma 5.20.90 was being built while a libgps upgrade happened. It seems
that even though the package had already been built for every arch, it
had not for x86 yet and thus our plasma-workspace is still depending on
the older package and fails to install because it isn't available
anymore
Just bump the pkgrel so it now gets correctly build against libgps.so.27
This is required by some software, e.g. bluez/gnome to set some ACLs on
/dev/rfkill (see #904). While probably nobody will notice on the
downstream kernels (as we don't have any proper software there anyways)
it's definitely needed on mainline-ish kernels. Surprisingly only one
kernel has broken by enabling this option (linux-sony-tulip) which I've
patched up.
linux-postmarketos-qcom-sdm660 did not break by enabling this option,
but required linux4.17-gcc10-extern_YYLOC_global_declaration.patch to
build again, so this was fixed too.
[ci:skip-build] [ci:ignore-count]
Fixes installs with pmbootstrap using default recommends. Foxtrotgps has been
removed from alpine since it depends on libglade which will soon be deprecated
from alpine.
According to Purism, the imx8mq-librem5.dtb alias is going away soon,
and we should be using the -r2 dtb. The -r2 dtb (which represents
Birch/Chestnut L5 variants) is most compatible, it'll boot on later
variants. dtbs for later L5 devices won't work on older devices.
Seems there are more places where ecm_find_qmlmodule is used
To fix the build from failing on armv7 we should disable them all
[ci:skip-build]: don't try to build all depends, takes too long
[ci:skip-vercheck]: unblocking armv7 build, no need to bump pkgrel
The build is still failing, probably because ecm_find_qmlmodule is not
only present in the main CMakeLists.txt, but also in others.
$ git grep ecm_find_qmlmodule
CMakeLists.txt:ecm_find_qmlmodule(QtQuick 2.3)
CMakeLists.txt:ecm_find_qmlmodule(QtQuick.Controls 1.2)
CMakeLists.txt:ecm_find_qmlmodule(QtQuick.Layouts 1.3)
CMakeLists.txt:ecm_find_qmlmodule(QtQuick.Window 2.1)
CMakeLists.txt:ecm_find_qmlmodule(QtMultimedia 5.0)
CMakeLists.txt:ecm_find_qmlmodule(org.kde.kquickcontrolsaddons 2.0)
CMakeLists.txt:ecm_find_qmlmodule(org.kde.plasma.core 2.0)
CMakeLists.txt:ecm_find_qmlmodule(org.kde.plasma.components 2.0)
kcmkwin/kwindesktop/CMakeLists.txt:ecm_find_qmlmodule(org.kde.plasma.core 2.0)
kcmkwin/kwineffects/CMakeLists.txt:ecm_find_qmlmodule(org.kde.plasma.core 2.0)
[ci:skip-build]: don't try to build all depends, takes too long
[ci:skip-vercheck]: unblocking arm build, no need to bump pkgrel
Seems we missed these when forking Plasma and now the armv7 builders are
failing on it
[ci:skip-build] Won't succeed anyway as the packages haven't been
uploaded to the repos yet, so pmbootstrap will try to build the entirety
of Plasma and fail because it takes too long
[ci:skip-vercheck] No need to bump pkgrel
This is a generic package for devices which use x86_64 CPU and 32-bit
EFI. Most distributions don't provide installation for 32-bit EFI, so
installation is not user-friendly.
Actually, these tablets deserve device-specific packages (I am going to
make ones for ASUS VivoTab Note 8 and ASUS Transformer Book T100TA), but
this one includes basic functions and can be booted on any 32-bit EFI
tablet with disabled secure boot and missing device-specific package.
I guess 32-bit EFI with 64-bit CPU is Intel's "feature" and AMD doesn't
have such stuff, so this package will be installed only on devices with
Intel CPU, unlike device-tablet-x64uefi which can be installed on any
x86_64 PC. So i decided to enable some Intel specific things (userspace
GPU stuff and alsa-ucm-conf).
I used for reference device-tablet-x64uefi and
device-trekstor-surftabduow1 packages. This package also can be used as
a reference for device-specific ones.
2.0.15 is a development 'version' (it'll never be released), and will be
replaced by 2.0.16 when that is released. The reason for forking this
is because there are some issues that are resolved here that prevent
SDL2 from working on the Librem 5. The fixes cannot be easily
backported to 2.0.14, hence the fork and upgrade.
fixes#950
[ci:skip-build] Never succeeds in time, too many packages for CI
[ci:skip-vercheck] We need our Mauikit to have -r1 to be newer
than in Alpine repos, but the CI requires all new packages to
have -r0.
[ci:skip-build] Never succeeds in time
[ci:skip-vercheck] We need our Mauikit to be a rel newer than in Alpine
repos, but the CI doesn't like it
This includes a big rewrite in kwin which should increase the
performance a whole lot, and some awesome other stuff
We're going to omit Telegram though, we shouldn't recommend a walled
garden with proprietary backend like that. Besides, NeoChat (and thus
Matrix) is already in there
Added support for Motorola Moto E 2014 codename: condor
It is booting, has usb, battery, flashing needs special fastboot command for the boot partition
Remove devmappings service. The original purpose of this service was to
ensure that /boot is mounted properly after the initramfs passed control
to OpenRC, because the initramfs used to umount /boot before that. With
/etc/fstab alone, /boot get not get mounted with subpartitions (which we
use on Android devices), if util-linux >= 2.33 was installed (MR 115).
Nowadays, we don't umount /boot in the initramfs before passing control
to OpenRC anymore (MR 1398). So this service isn't needed anymore, and
prevented the previous pmOS_inst_boot <> pmOS_boot patch from working
correctly.
Find partitions with the label "pmOS_inst_boot" too, and prefer using
them as boot partition over ones with label "pmOS_boot". (I'd use
"pmOS_install_boot", but there is a character limit in the label.)
Without this, the initramfs may choose the wrong boot partition if
postmarketOS is available once as install OS (on device installer) on
the SD card and once on the eMMC (installed).
I just had this problem with QEMU when simulating the install from SD to
eMMC use case with pmbootstrap qemu --second-storage. The pmOS initramfs
scripts would detect the previously created eMMC boot partition as the
proper one and mount it. It would boot into the right root partition,
because that already has a different label (pmOS_install instead of
pmOS_root), but because the wrong boot partition is already mounted,
during the install it would not be possible to run mkfs on it.
