This is device-agnostic, and allows to not depend on a package that
might end up in alpine in the future. In the process, also remove the
unnecessary postmarketos-test dependency in makedepends. That is just
an empty package.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7553>
This will be removed from unl0kr in the following commits, since at
some point it might be that unl0kr is not packaged in postmarketOS,
and this is a completely device-agnostic test, which is what this
package is for.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7553>
Since this was introduced, we no longer create "initramfs-extra"
unconditionally. So the "extra" files will be included in the
initramfs anyway. In addition, to be able to test the initramfs-extra
split for devices that need it, we require:
* To have one of those devices available for test.
* To modify our test setup to pass a rootfs that can be mounted.
Both are long into the future, if they will ever materialize. So let's
remove this, reducing the complexity.
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7553>
In the process, bump the pkgver to 1 similarly to what we do with
device packages where version numbers don't have a meaning. We
specifically don't create a subpackage, since the app is in flathub,
which is officially supported by the provider, and is a common way for
most non-technical users to ust it, since it's offically endorsed.
Unconditionally opening this really high port should also not increase
the attack area in any remarkable way.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6221>
add_upstream_git_remote was just being run at beginning of every
method using get_changed_packages or get_changed_files, to have
upstream available to use get_base_commit. So then, just move it to
get_base_commit. As a positive side-effect, since the previous commit
get_base_commit will just use the gitlab variable if available. So in
CI we will just completely avoid running these two commands!
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7078>
Previously, this test would 12 to 16 seconds to run locally, and
having it run unconditionally slows CI (it's always the last test in
the pipelines). This commit changes it to only run on changed UI
packages, speeding up the pytest CI by more than 75% in most situations.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7078>
This is not something we can measure or reason about, since "obscure"
is very subjective. An alternative of using "multiple users" has also
been discarded, since we don't have a way to measure that either for
now.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7077>
The reviewers are responsible to check that the pipeline actually
built and run successfully. The bot has the option to skip the
pipeline completely, but that means we also skip the checks about
bumping pkgver and pkgrel, which means some rebases could cause
issues. Since there is no straight-foward way to make the bot add
"[ci:skip-build]" to the commit message, then we can actually do this
check instead.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6963>
common is otherwise over-used with things with very little
consumers. So reduce the list by moving the
get_changed_packages_sanity_check to check_changed_aports_versions,
which is the only user. In the process, also rename it to make it more
clear what it's used for: check_package_count
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6963>
This carries some risks, but we are willing to put up with them. We
need everybody to have a /usr-merge to continue moving on our
priorities. Fortunately, the merge-usr script has received quite a lot
of testing so far.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6389>
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
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/6375
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/6375
Following Alpine's example. This allows some optimizations:
* Don't start one job per architecture simply to skip them after
rebase and before merge
* If there are no packages, don't start the jobs at all (not true,
gitlab bug)
* Avoid creating jobs for architectures that don't have changed
packages, thus further reducing the unnecessary
jobs and possibly reducing transient failures
Co-authored-by: Clayton Craft <clayton@craftyguy.net>
The regex has not been working for a long while, there have been
previous attempts to try fix it, but it's still failing. There is
also common understanding in the team, that the regex is not terribly
useful. So remove it.
We now have a bot that reads those lines from APKBUILD files, instead
of using a proprietary gitlab feature. Relevant changes:
* Change @ollieparanoid for @Newbyte as maintainer for GNOME packages
where Oliver was listed.
* Don't add @craftyguy as Librem5 maintainer, as he dropped it long
ago
* Remove entries referencing archived ports
* Don't touch jenneron's maintainership. That's a task for another day
* Don't add "balejk" as maintainer. We have tried pinging them, but
seem to be currently idle
person is. Help figuring it out would be welcomed.
* Don't add "binarycraft" as maintainer. Last contribution was years
ago: https://gitlab.com/binarycraft
* Don't add more maintainers to linux-postmarketos-qcom-msm8953, as it
would have ended up with 7, which might be a bit too much
* Don't add more maintainers to the PinePhone. The current ones seem
to actually be the most active
* Don't add Danct12 to N900. Sicelo has been single-handedly managing
it for a long while
* Update maintainer emails for Nikita Travkin, Alexey Minnekhanov, and
Barnabás Czémán
[ci:skip-vercheck] Co-Maintainer changes require no pkgrel updates
since the names do not make it to the package itself
[ci:ignore-count]
Fixes#3530
[ci:skip-build]: already built successfully in CI
Pablo Correa Gómez