As explained in the previous commit, this was initially envisioned to
be used in a different way, and with ci-tron the way to add the
console is different (just a gitlab variable), so this won't be needed
in the future.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7489>
The check in Python did not work with devices without kernel variants
due to it returning None and that breaking the has_kernel_variants
check. Fix that, and also adding the kernel variant to install
packages, which was missed. In the process, rename kernels to
kernel_variants. All devices have at least one kernel, but not all
have "variants" :)
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7489>
So we can read the complete output in the logs. This was initially
done to avoid the output from being interrupted, and therfore easier
to read. However, it avoids kernel logs to be collected, which is an
important part of the tests, and necessary for debugging. So let dmesg
be as default.
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7489>
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
Pablo Correa Gómez