This is a workaround for pmb#2618, basically.
To build systemd with BPF support (so things like unpriv. nspawn work),
we have to install linux-stable-dev to get a special header(vmlinux.h).
This kernel (linux-stable) isn't build in Alpine for armhf. Normally
that's not a problem, we could just add linux-stable-dev conditionally
to the makedepends, right? No... not possible until pmb#2618 is fixed.
Given this arch is used by only 3 devices in testing (the rest are in
`downstream` or `archive`), I think it makes sense to disable systemd on
this arch until someone has the motivation to fix the pmb bug.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6637
[ci:skip-build]: already built successfully in CI
Remove the systemd-specific MOTD that says it is still in preview.
v25.06 is about to come out, the first stable release with systemd!
Any future adjustments to make it use fancy ascii colors etc. should be
made in postmarketos-base instead.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6669
[ci:skip-build]: already built successfully in CI
This is needed by some(all?) Xwayland implementations too, so don't make
installing it exclusive to having the actual X11 xorg-server installed.
This fixes an issue where Xwayland doesn't work on COSMIC.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6658
[ci:skip-build]: already built successfully in CI
On a merged /usr system, this results in a broken symlink since
sbin/udevd is really usr/sbin/udevd, and usr/sbin/../usr/lib/ is not a
real thing. This should have no effect on unmerged /usr systems, since
sbin/../../usr/lib/.... is still a correct (if ugly) path.
It's quite difficult to create a relative symlink for these things
that works reliably on a merged AND unmerged /usr install, so for now
I'm going to make the symlink source path absolute so that we can be
confident it'll work on either type of installation, and we can revisit
making them relative after usr merge is done/deployed on all installs.
Part-of: https://gitlab.postmarketos.org/postmarketos/pmaports/-/merge_requests/6598
This change makes the zram_swap service depend on a deviceinfo being
present in the rootfs (which may not always be the case, e.g. when
building an image with mkosi), and it replaces the ExecStartPre with
a dependency on modprobe@zram.service so that modprobe is only called
once if other services happen to also depend on this module (which is
unlikely, but a nicer way to handle this)
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6566
The abuild package has been forked to temp/abuild and
extra-repos/systemd/abuild in the past. The systemd one is legacy from
the initial systemd repo bootstrap method that is currently broken and
will be replaced soon (see MR 6440). While the new one is not ready yet,
this package is currently not useful so remove it to fix the failing
upstream-compat check (currently it is on a different version than
temp/abuild).
[ci:skip-vercheck]: just removing a comment in temp/abuild
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6573
[ci:skip-build]: already built successfully in CI
Shells (and DEs!) that set environment from /etc/profile.d will end
up sourcing 20locale.sh from alpine-baselayout. This file will set
`LANG=C.UTF8`, and this will override whatever systemd-localed/systemd
sets LANG to. In other words, locale.conf is effectively ignored. I
hit this issue when debugging why the date in COSMIC was always `M05`
instead of `May`, and why various COSMIC components failed to detect the
locale (because it was set to C.UTF8)
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6535
[ci:skip-build]: already built successfully in CI
Why is this needed?
To be able to test the usr-merge downstream we need to stop
depending on alpine-baselayout. For that, we need to stop depending on
alpine-base. This is a first step to create a "provides" solution
downstream between openrc and systemd systems, so that in a follow-up
commit we can recreate alpine-base downstream without the hard-coded
openrc dependency. The virtual instead of a versioned dependency means
that:
* In theory systemd and openrc could be installed in parallel. In
practice we avoid that with !openrc in the systemd package and
!systemd in the postmarketos-base-openrc one. There is a lot more
work required with provides (both upstream and downstream) regarding
things like elogind and eudev to be able to even have them
package-wise ready to be installed in parallel
* There must always be one installed. Here we have 3 scenarios:
* pmbootstrap install where pmbootstrap will decide which one
* update from existing install. The virtual makes sure that APK
won't remove the local package because versions changed
* Manual APK work, where the provider_priority or the user will
choose
How does this work? Hypothesis:
* openrc upgrades: the postmarketos-base-openrc remains installed,
moves from being an "install_if", to be there because it fulfills
the postmarketos-base-init requirements.
* systemd upgrades: postmarketos-base-systemd is still in
/etc/apk/world, and it fulfills the new dependency in
postmarketos-base. Nothing happens.
* openrc installs: pmbootstrap will choose one of
postmarketos-base-openrc and postmarketos-base-systemd... But which?
The one with the higher version?
* systemd installs: postmarketos-base-systemd is installed before
anything else is. That means, postmarketos-base-init will already
be satisfied when postmarketos-base gets installed, and openrc will
not be installed
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6475
