All GNOME-like UIs should install the backgrounds to get a few default
ones to choose from in g-c-c. ui-gnome previously pulled them in per
`gnome`-pkg, ui-gnome-mobile previously depended on the wallpapers
directly. So only phosh has a actual effect.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8068>
On devices using a combined initramfs, init_2nd.sh is exec'd directly
from the first stage without ever calling load_modules(). This means the
loop kernel module (CONFIG_BLK_DEV_LOOP=m) is not guaranteed to be
loaded before mount_subpartitions() runs, causing losetup to fail:
losetup: /dev/sda13: failed to set up loop device: No such file or directory
ERROR: failed to mount subpartitions!
On the split initramfs path (init.sh), load_modules is called explicitly
before jumping to init_2nd.sh, so this regression did not affect those
devices.
Fix by explicitly loading the loop module in mount_subpartitions(),
right before the loop that searches for partitions. This location was
suggested by Clayton Craft.
Regression introduced by: 86bdb82116 (use loop device for subpartitions)
Tested on: oneplus-cheeseburger (combined initramfs, msm8998, loop=m)
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8034>
This reworks the subpartition init to use loop devices instead of
kpartx/dm mappings. This allows us to use the same logic for resizing
as we do for other partitioning schemes (and refactors that code a bit).
This also helps duranium, because systemd tooling (repart, sysupdate,
gpt-auto-generator) can't properly handle GPT subpartitions exposed via
kpartx dm mappings, but works correctly with loop devices created with
partition scanning enabled.
After this change, subpartitions show up as loop devices, e.g.:
$ ls /dev/loop*
/dev/loop0p1
/dev/loop0p2
There *should* be no impact to existing installs.
This also drops the dependency on multipath-tools, which seems to have
been added years ago as a workaround for installing kpartx (like maybe
multipath-tools used to provide kpartx?), see 7573f5fce4. Anyways, we
don't use anything in this pkg in the initramfs AFAIK.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7932>
Removed in Alpine: cd6c73d27e
> There seems to be no chance they move to Qt6 in the short term and they
> have already been disabled for a while. When it finally updates to Qt6
> this commit can simply be reverted, together with
> e4b455e8
Removing references of asteroid in this MR, since it's no longer in any
use. Feel free to revert once they migrated to Qt6.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7972>
If $modules is empty, then `modprobe -a` is run which gives an error
with full modprobe (i.e. not busybox variant):
[pmOS-rd]: modprobe: ERROR: missing parameters. See -h.
Add a check and return early to avoid potentially printing the error
to users.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7916>
We used to use this param when the MM systemd unit was vendored in
pmaports but it was dropped when we switched to the upstream unit. This
also sets the param in openrc installs.
Fixes#4194
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7840>
The pmb:gpu-accel option is deprecated in favour of pmb:drm. However, it
doesn't do anything when applied to packages that aren't UI packages
(base-ui packages aren't UI packages), so just remove it instead of
replacing it with the proper option.
[ci:skip-vercheck]: Doesn't affect resulting package, only read by
pmbootstrap during `init`.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7847>
Previously the process was that once a branch is EOL, the
notification-commit was cherry-picked from the branch before.
However that makes less sense, since the package then doesn't go
through the same mass updates as pmaports master does, e.g. it still
referenced gitlab.com & -gtk3, and doesn't allow changes by contributors
other than the one cherry-picking it.
Adapted from c088d806ea25 ("main/postmarketos-upgrade-gtk3: new aport")
See https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/4197.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7769>
I contacted Mark who confirmed that he is not likely to return to
contributing to postmarketOS any time soon and is okay with me
removing his maintainer line.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7825>
This "size"/factor/percentage represents the total amount of
**uncompressed** data that is allowed to be written to the zram-backed
swap device. It is **not** the amount of RAM to use for zram swap (as I
had previously and erroneously thought.) What this means is that if we
set the percent to 50% on a device with 3GB of RAM then up to 1.5GB of
*uncompressed* data can be written to it, BUT since compression algos
usually do better than a ratio of 1:1... less than 1.5GB of RAM will
actually be occupied by this data when it is compressed.
A 1.5:1 compression ratio seems relatively safe to assume, even if we
use lz4 (which is less "good" at compressing than zstd), so I propose we
set the size to 150%. Some distros (PureOS) set this higher (200%), but
I think we should be somewhat conservative since we want to avoid any
thrashing in case the compression ratio at runtime ends up being less
than 2:1 for some reason.
This does set a limit of 50% for devices with >32GB of RAM, to
reduce overhead with using a larger amount of zram swap. The kernel
documentation for zram suggests there's a 0.1% overhead, so if we let
this amount get large then it could be tens or hundreds of MB of RAM
"wasted." The amount I chose is kinda arbitrary, I think this can be
improved later. At the very least, users can change this amount in the
deviceinfo variable.
Fixes#4250
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7754>
This is meant to replace zram-init. It's much simpler, since it only
sets up zram swap and doesn't try to do all the things that zram-init
does. This also lets us add additional logic, such as selecting
different default algorithms based on the runtime CPU arch and
conditionally applying sysctl settings that might be inappropriate when
*not* using zram swap.
To create zramstart, I took the zram-configurator, which reads config
from deviceinfo vars, and extended it to create the zram swap device.
zramstart and zramstop were inspired by what Fedora does. The sysctl
config is from the work done here:
https://source.puri.sm/Librem5/librem5-base/-/merge_requests/381
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7754>
* Set Co-Mainatiner as maintainer, if they exist
* Add me as co-maintainer of QEMU packages to fulfill main requirements
* Add people interested in maintainance to their packages
* device-google-snow now has no maintainer, if someone is interested,
please add yourself as maintainer, otherwise it has to be dropped
As we all know they are inactive nowadays, the maintainer variables
should reflect the reality who cares/is responsible about a package, and
inactive members are not. And waiting for a inactive maintainer 2 weeks
is just staling the MR.
Thanks for all the work Minecrell & Jenneron, and feel free to add
yourself again if you're back again.
[skip ci]: too many false positives :p
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7748>
