Add firmware packaging guidelines to the documentation. The goal behind
this was to make it so that it is very clear which packaging method is
preferred for which cases to avoid fragmentation and inconsistency in
pmaports packaging.
Co-authored-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8161>
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>
Start the documentation for generic device packages and document how to
handle device-specific services. This is a question that came up in the
review of PMCR-0009 (new main device category).
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>
Currently, even if dint fails for some reason, the documentation
generation continues on. This is not good as it hides problems until
someone manually discovers them. Fix this by checking the exit code of
dint and raising an exception if it isn't zero.
To facilitate this, also replace call() with run() since it's a more
modern and more flexible API.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7982>
Keeping it in the docs under a new section to reduce the risk of
confusion about its disappearance. It's also still relevant if you
target older branches where it hasn't been removed.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7822>
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>
