I dropped 2 patches that seem to have been merged upstream.
I also updated the pkgver format to follow what we do for other forked
pkgs, so hopefully the upstream compat monitoring thing will detect when
this pkg is out of date again
This adds a new patch to fix#3787
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7099>
This only allowed categories that were aliases (and only categories
under those), but stuff like `pmb:kconfigcheck-uefi` was flagged as an
invalid option by the linting.
This change parses aliases AND all categories in the kconfigcheck and
allows those as options.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7101>
I chose this device pkg name because it's descriptive, this pkg doesn't
support the 'idevice' things or x86_64 or PPC Macs. I didn't include
"generic" because, while it supports Macbooks, (in theory) Mac Minis
and something called Mac Studio, it's not really *that* generic for Mac
computers AND by having the manufacturer be "Apple" it'll show up in pmb
init under "apple." This will make it more intuitive to find, I think.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7048>
Alpine's linux-asahi kernel is missing some config for booting on the
macbook M2, and is missing config for supporting other pmOS features /
kconfig checks. It's easier to maintain this kernel downstream for now
so changes can be made easily to support this hardware and functionality
we need.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7048>
The device wiki check currently runs for *all* devices in any given
MR, and can sometimes fail (e.g. if someone edits the wiki for some
unrelated device.) It's not fair to block MRs for devices when the
check fails on unrelated devices. This changes the default behavior to
only run on devices that are changed in the branch. This also adds an
`--all` flag that restores the previous behavior, this could be run on
the pmaports master branch to test general compliance for all devices
without blocking MRs where the check fails for unrelated devices.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7098>
This fixes an issue where the mkosi-generated initrd fails to load udev
because libkmod is not installed when systemd-udevd is installed.
For pmOS installs/initramfs stuff, this change should be a no-op,
libkmod is already pulled in by other things and our initramfs config
includes the library manually.
[ci:skip-build]: already built successfully in CI
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7079>
The trigger runs `systemctl preset cups.service`, but then if it runs
preset on the other two *afterwards* it will disable them (because no
explicit preset and we default to disable). This helps ensure they're
kept enabled.
The same seems to also happen for NetworkManager-wait-online and the
other things here, leading to them being accidentally disabled.
This also removes cups.service, it should be socket-activatable now that
cups.socket is enabled.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7029>
Apparently the eval trick doesn't work for passing vars if the var to
set is the same as the var for the value, in this case the caller of
this function was using `added_paths` and `removed_paths`. Shell scripts
suck.
This was missed in the tests because the unit tests call
trigger_unit_presets directly.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7025>
Apparently this fails on other archs when cross compiling, not just
riscv64. I hit it locally when building x86_64 on aarch64. bpo is
hitting it when trying to build aarch64 on x86_64. This is kinda of a
big hammer, but I think we'll be able to drop this cups fork when abuild
systemd split func support is upstreamed, and bpo is currently blocked
trying to build changes to support our effort to upstream that abuild
patch.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7023>
This trigger has a lot going on, so let's make sure it always passes
shellcheck. It's not picked up by the normal search for triggers in this
script because the actual logic for the trigger is broken out from the
.trigger file.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6892
This reworks the preset, reload/restart, and cleanup handling and moves
it from a (proposed [1]) abuild patch that would generate install
scripts for every -systemd package to a series of commit hooks and
a trigger that would exist in this package. This was made
possible by using `treescan`, which quickly[2] recursively scans
/usr/lib/systemd and allows the commit hook and trigger to diff units
before and after an install or uninstall transaction.
I chose to put the trigger and commit hook in pmos-base-systemd instead
of the systemd package because:
1) It's annoying to have to rebuild systemd just to update the logic in
this script. Rebuilding this package is MUCH faster (nothing to
compile)
2) IF the systemd package moves elsewhere (i.e. out of pmaports), it's
unclear if this preset stuff would follow it, and it's safer for us to
keep it separate so know it's always being included in pmOS+systemd
installs. It can always be moved later if we decide to.
More info on how the three situations are handled by this patch:
Presets: Pre-commit hook captures current unit file list (using
treescan) before changes, then the trigger on /usr/lib/systemd/system
captures (using treescan) the state after changes and diffs them. It
picks out only unit files that were added, and runs systemctl preset to
apply any preset config that might exist for them.
Reload/restart: This relies on manual post-upgrade scripts in packages
that need it. post-upgrade scripts should mark units with systemctl
set-property ... Markers=+needs-reload/restart. Actual reload/restart
handled by the existing systemd.trigger that queries these markers...
This is going to be a bit annoying for package maintainers[3], but I
don't think many packages will *need* this. As of today, there are 0
packages explicitly requesting reload/restart on upgrade. This also
means there will be no automatic detection of whether a unit should be
reloaded/restarted. AFAIK Fedora doesn't support this, packages have to
explicitly request a reload or restart.
Cleanup: The pre-commit hook uses treescan to capture systemd unit
directory state before transactions and the trigger identifies removed
units (using treescan + diff). It then finds broken symlinks in
/etc/systemd/ that point to any newly removed unit files from the
transaction, and removes only them.
Benefits:
- Simple abuild patch for -systemd split func
- Uses existing APK mechanisms (commit hooks, triggers). Hooks can see
before/after transaction state for cleanup.
- Logic updates don't require rebuilding all packages.
Tradeoffs:
- Requires additional per-package complexity to support
reload/restart functionality.
- Moves unit discovery/parsing for preset and cleanup from build-time to
runtime (every device does this work vs. once at build)
- Package behavior varies based on installed trigger/hook
versions rather than being deterministic per package version.
- There's a (tiny) risk of some operations being race-y, e.g. if the
user is actively enabling/disabling/adding unit files between apk
running the pre-commit hook and the trigger firing... It seems
unlikely this will cause issues, but 🤷♂️
1. https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/394
2. I used hyperfine to measure performance of treescan on my laptop,
with lots of units installed, and it was ~20ms without disk caching
3. A post-upgrade that would mark a unit for reload might look like
this:
```
if [ -d "/run/systemd/system" ]; then
echo "Marking sshd.service for reload..."
systemctl set-property sshd.service Markers=+needs-reload
fi
```
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6892
These packages were previously built by a WIP abuild patch that added
install scripts to each -systemd subpkg for handling preset application
on install and symlink cleanup on uninstall. This functionality has been
replaced by a trigger/commit hook, so we need to rebuild these packages
to drop the install scripts that were previously generated.
[ci:ignore-count]
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6892
This could be folded into aports/qemu.. but I'm not sure if
they'd accept it since the path these install to seems(?) to be
systemd-specific? Once there's -systemd split pkg support in abuild,
then maybe it'll make sense to move this to aports.
fixes#3394
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6950
[ci:skip-build]: already built successfully in CI
When building immutable images, we'll be putting /etc into
/usr/share/factory, and then using systemd-tmpfiles to symlink all of
that stuff under /etc. When systemd installs into this dir, it leads to
accidentally adding some "example" config to the system's runtime
config, e.g. adding pam config with a comment like this which completely
breaks login/auth for many UIs (Phosh, Plasma Mobile, etc) :
# You really want to adjust this to your local distribution. If you use this
# unmodified you are not building systems safely and securely.
I could technically just scrub this dir when building immutable images,
but tbh I can't think of any reason why we'd want to ship this in the
first place.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6915
This does a hack to removing the need to build the stuff in src/boot for
enabling bless-boot. Previously I tried to enable bless-boot by adding
-Dbootloader=enable, which would be required without this hack, but
cross-compiling systemd/src/boot failed on 32-bit archs and it seemed
unnecessary to go down that rabbit hole to debug/fix.
Why? Because:
1) It's not actually needed for building the stuff I care about enabling
in this MR (systemd-bless-boot and its generator). These things build
and work just fine without building stuff in src/boot.
2) Even if it worked, we would have to remove the artifacts made
from src/boot and not package them here. They would conflict with the
systemd-boot package in Alpine.
So it seems pointless to waste time fixing some weird cross-compiling
issue for some components that don't actually need to be built to enable
the extra features I want and would be discarded anyways in package()
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6840
This commit (and the one before it) seem to have broken building new
images, apk hits a conflict with udevd and systemd-udevd:
systemd-udevd-257.7-r1:
conflicts: systemd-257.7-r1[eudev=257.7-r1]
satisfies: systemd-257.7-r1[systemd-udevd=257.7-r1]
systemd-257.7-r1:
conflicts: systemd-udevd-257.7-r1[eudev=257.7-r1]
satisfies: postmarketos-base-systemd-48-r0[systemd]
systemd-journald-257.7-r1[so:libsystemd-shared-257.so]
systemd-logind-257.7-r1[systemd=257.7-r1]
systemd-logind-257.7-r1[so:libsystemd-shared-257.so]
systemd-timesyncd-257.7-r1[systemd=257.7-r1]
systemd-timesyncd-257.7-r1[so:libsystemd-shared-257.so]
systemd-udevd-257.7-r1[so:libsystemd-shared-257.so]
This reverts commit a6a31b3fe7.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6794
We currently don't build systemd for armhf anymore. Disable all other
packages in the systemd repo too, as these can't be built without the
systemd dependency.
FWIW all of Phosh, Gnome Mobile and Plasma Mobile already have major
packages not building for armhf so they couldn't be used on this arch
anyway.
Once pmb issue 2618 is resolved, we can re-enable systemd for armhf.
Co-authored-by: Oliver Smith <ollieparanoid@postmarketos.org>
Related to !6637Fixes#3783
[ci:skip-build], [ci:skip-vercheck]: changing arch= only
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6710
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
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
These options are things that other required kconfig depend on, found
when creating a new config from scratch and noticing a few required
kconfig wasn't making it into the final config.
I don't expect this to have any impact on existing kernel packages that
already pass the kconfig check, because they would already need to have
these options enabled.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6641
This test is apparently wrong a lot now, so let's disable it. Audio
apps should inhibit sleep/suspend on their own, or worst case you can do
something like `systemd-inhibit <audio app>`.
We still want sleep-inhibitor around for now to inhibit sleep/shutdown
when an SSH client is connected or when apk is running.
Fixes#3745
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6612
[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
This splits off two new subpackages in postmarketos-base, allowing for
tools (e.g. mkosi) to build a very small "postmarketOS" rootfs.
postmarketos-base depends on these two new packages, so there should be
no functional change outside of enabling this specific use case.
The versioned replaces is meant to fix installing this new package on
existing installs. In some cases apk installs this package *before*
installing the `postmarketos-base-systemd` update that accompanies this
patch.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6565
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
Clayton Craft