Migrate the compiler to LLVM toolchain and update config as per required
and preferred config options by kconfigcheck.
Update the APKBUILD to follow some more recent standards as well.
And similar to linux-postmarketos-qcom-msm8974, activate
CONFIG_CC_OPTIMIZE_FOR_SIZE and CONFIG_KERNEL_XZ to get the kernel a bit
smaller again.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7539>
The PowerPC boot wrapper script in Linux currently requires a GNU
cross toolchain in PATH. This went unnoticed because we currently always
install GCC for native builds, but since recently only install a cross
GCC toolchain if clang is not used to build.
Indeed, we want to only build the kernel with clang and LLVM binutils.
There has been some discussion around fixing this in the past, and
Nathan Chancellor has written some patches that do fix it, but has
apparently not submitted them because the VDSO may require further
changes. I've followed up on the mailing list and asked about the
possibility to submit the patches without reworking the VDSO, since it
fixes this particular usecase nonetheless.
I've also considered installing the cross GCC package in the APKBUILD,
but that's not possible because pmbootstrap cannot evaluate conditional
dependencies. As it stands, we *need* to patch the kernel to get it
building, or revert the pmbootstrap patch, which I really want to avoid.
I'll do my best to get these patches integrated upstream.
[ci:skip-vercheck]: let's not rebuild all the architectures when we're
only touching ppc64le that isn't building in BPO
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8072>
In the case that the compilation is broken, it is not possible to wait
until a patch is merged upstream to fix it. We want to be able to patch
the kernels temporarily while also ensuring the fixes make it upstream.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8072>
Without a sufficient vm.min_free_kbytes value, the kernel may not start
reclaiming memory early enough to make use of zram swap before the
kernel OOM killer fires. Set a minimum of 100000 KB on devices with >=
1GB of RAM where the kernel's calculated value is lower.
This ignores devices with <1GB of RAM, because I think with so little
RAM isn't unlikely to really matter and if we set this too high then we
risk insta-OOMs.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8157>
This sets the max disk space used by journald logs to 1GB (systemd
default is 4GB). This seems like a good trade-off between having access
to more older logs in case there are transient issues that need debug
or we need to understand system behavior long term, and not filling too much
space on devices with little storage.
If a device is really constrained for space, the device package
can ship an override file in journald.conf.d to lower this limit
even further. Users/system admins can also override this value in
/etc/systemd/journald.conf.d.
Fixes#4389
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8156>
Put phosh-tour in pmb_recommends instead of having postmarketos-welcome
indirectly installed by default through
postmarketos-base-ui-gnome-mobile. In order to do that, move
postmarketos-welcome from the pmb_recommends of
postmarketos-base-ui-gnome-mobile to postmarketos-ui-gnome-mobile.
The reasons for that is that the postmarketos-welcome app by now has
in part incomplete and outdated explanations about how phosh shall be
used. For example, a common question that we don't answer but phosh-tour
does is how the keyboard can be launched from any app.
The postmarketos-welcome app warns more about that this is an
experimental system, but that is prominently displayed on our homepage
when trying to download images. Otherwise it also doesn't contain much
information that makes it worth keeping instead of phosh-tour.
Finally phosh upstrem has also said that they would be willing to have
distro-specific tour pages, so if we notice that something would be
really good to have there in the long run, we could look into getting it
in phosh-tour.
[ci:skip-vercheck]: changing pmb_recommends doesn't need rebuilds
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8145>
This was the only package starting with "device-generic-" that did not
end in an architecture name, which means it is not generic for that
architecture. Rename this package, so we can define all packages
starting with "device-generic-" as Generic Device Packages and document
guidelines for making these types of packages consistent.
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8122>
See the meeting notes from the 2026-01-19:
(https://docs.postmarketos.org/policies-and-processes/governance/team-meetings/meeting-notes.html)
> Discussed pmaports!7770, possibly limiting the wait period for maintainer
> approval from 2 weeks to 1 week.
>
> We discussed to keep 2 weeks and make an issue template for “had to merge
> without maintainer review”, the new process will then be that the template
> gets filled out if a MR has to be merged without maintainer review after
> two weeks. The maintainer can then either say that they plan to review
> future merge requests, or indicate that they don’t want to maintain the
> thing anymore, or just not respond (which implies that they don’t want
> to maintain anymore). That way we should be able to get the listed
> maintainers to reflect reality better.
>
> Everyone reading this, please make sure you are not listed as maintainer
> for packages that you don’t plan to do reviews for anymore :)
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7770>
Pablo Correa Gómez