The same patch is already used on 3 devices, to make it shared.
WARNING: vmlinux.o(.devinit.text+0x1bd4): Section mismatch in reference from the function msm_pm_boot_probe() to the function .init.text:msm_pm_boot_init()
ERROR: postmarketos-base-downstream-disable-udev-v4l-2-r1: trying to overwrite usr/lib/udev/rules.d/60-persistent-v4l.rules owned by systemd-udevd-257.5-r0.
The APKBUILD reference seems to suggest that versioned provides= can
have any valid version string (e.g. 0.12-r3) in the `provides=` var, and
that it doesn't have to match `$pkgver-r$pkgrel` for the APKBUILD. IIRC
this test intends to catch typos like `provides=foo=$pkgver-$pkgrel`, so
this makes it pass when any valid version string is given.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6475
[ci:skip-build]: already built successfully in CI
alpine-base directly depends on openrc. We have had different[1]
conversations[2] with upstream. And the main conclussion[3] has been:
if you want to do something different, just depend on things
yourself. This is indeed what docker images do. So let's just get the
things that we want from alpine base (quite some!), and ignore what we
don't want (openrc, busybox openrc and init packages). Up until commit
12d125ab8b72f0249fd6aae000170a4fa78a83ab in pmbootstrap every
postmarketOS installation would have alpine-base in
/etc/apk/world. Therefore, we add a versioned provides to
postmarketos-base with a very high version, which conflicts with the
upstream version but should be chosen instead.
alpine-conf is now a dependency of postmarketos-base-openrc, since it
dependes on openrc for calling setup-*
scripts. postmarketos-base-systemd already implements those needed.
Contrary to the first attempt[4], I have kept the dependency on
alpine-release. Changes to that are independent to the usr-merge, and
can be done as a follow-up.
This should allow to drop the fork of alpine-base currently in the
systemd-extra repository!
To this day, every single pmOS installation will have alpine-base in
the world file, which means that systemd installs will the forked
package until users specifically run "apk del alpine-base". We must
add this to release notes and to an edge blog post. Alternatively we
could have an empty package with a very high version providing
alpine-base. This also means that to get installs to work, we need a
pmbootstrap release with[5] on it.
[1] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63935
[2] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71686
[3] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71686#note_435428
[4] https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/5026
[5] https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/merge_requests/2580Fixes#2806
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6475
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
This is inconsistent through the file. In addition, the "_" prefix is
often used when a function is not directly a split function from a
subpackage, but a "private" function that others call. So remove it to
make it clear that these are subpackage split functions
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6475
It is a lot more prone to breaking than stable, which is the
default. The reason to have them there is also not very clear.
The editor-config has been there since its introduction in
e7a8141113. It might be that at the time
it was not in community or in a stable release. The shellcheck-grep
has been there since 81872a59c1, which
was already 6 years ago. Probably at the time our tooling was a lot
less integrated and stable in alpine as it is today, and everything
was running edge.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6471
This sounds counter-productive and counter-intuitive, but hear me out:
this allows using `needs` to depend on those jobs, without further
templating downstream jobs.
In turn, those jobs depending on a disabled jobs, while they still exist
in the “graph” of the pipeline, are also transitively disabled.
This change, for all intents and purpose, is a no-op regarding the
amounts of jobs being sent to CI runners.
Also updates the comment for the placeholder job, since the wording
could lead to think that *having jobs* is sufficient. In reality, having
jobs that ran succesfully is necessary for the child pipeline to be
successful.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6399
None of the devices running trailblazer actually need all these daemons
or firmware. Move almost everything to recommends so that users can free
up space and so that customised images can be built with
--no-recommends.
Since there are some folks already using trailblazer who DO depend on
these packages, let's try letting users know about this at least.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6239
Luca Weiss