Changelog of xfce4-phone 0.6.0:
- Update screenshot
- Remove separator on the left-hand side of the clock
- Increase font size of the clock
- Change order of panel plugins "pulseaudio" and "power-manager"
- Increase icon size of status tray in panel
- After Xfce 4.20 release remove outdated "backdrop" settings
- After Xfce 4.20 release set theme "Greybird" explicitely
[ci:skip-build]: already built successfully in CI
The Xfce4 power manager can control the display brightness. It doesn't
save and restore it over boots, however. In distributions with systemd
this is handled by "systemd-backlight@.service". For OpenRC the package
brightnessctl offers a service saving the state of the brightness at
shutdown and reboot.
As brightnessctl is a rather simple tool and not specifically adapted to
Xfce4, it can get confused when the power manager e.g. lowers the display
brightness when on idle. To avoid such a hassle, the display power settings
were simplifyed in repository "xfce4-phone" version 0.5.3 (and needed a
correction in version 0.5.4). Users nonetheless can change them if desired.
when stdin is /dev/null (e.g. when console=null is on the kernel
cmdline) syslogd will call read() over and over and never handle the
SIGTERM we send it, pinning a CPU core on every boot.
Hooking up syslogd std I/O to /dev/zero prevents this.
Co-authored-by: Richard Acayan <mailingradian@gmail.com>
Co-authored-by: Clayton Craft <clayton@craftyguy.net>
[ci:skip-build]: already built successfully in CI
This new version includes initial support for systemd (for bluetooth
only atm). udev rules are only installed for openrc systems, bt config
on systemd was replaced by a unit file and using bootmac for wifi has
issues (https://gitlab.postmarketos.org/postmarketOS/bootmac/-/issues/7)
[ci:skip-build]: already built successfully in CI
This tool is similar to msm-firmware-loader or droid-juicer, except it
copies firmware from Windows instead.
Currently when the ADSP loads the new firmware it causes a usb reset
which breaks booting from USB. For now ask people to run this manually
and ensure the adsp firmware isn't available on the USB.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
The daemon has been split out from the library and is thus not
automatically installed anymore when applications using the library are
installed. However the daemon (the UnifiedPush distributor) is also
useful to have installed when Flatpak apps are in use or other UnifiedPush
supporting apps that don't use kunifiedpush as their library.
Fixes#3333
So Gnome-based DEs have a video-player by default. The main arguments
in favor showtime I see are:
1. It's the main candidate to become the new Gnome default video player.
2. It's has a mobile-friendly UI.
3. It uses HW-decoding and even zero-copy playback by default on many pmOS
devices (by using Gstreamer and unlike e.g. ffmpeg-based players like mpv).
4. Its main dependencies are shared with other apps like snapshot.
The other candidate that would tick the same boxes but 1. is livi.
[ci:skip-build]: already built successfully in CI
boot-deploy uses 'local', which technically isn't POSIX-compliant
and if someone has 'sh' from something else that strictly adheres to
POSIX then boot-deploy will fail.
This is a workaround for https://gitlab.postmarketos.org/postmarketOS/boot-deploy/-/issues/38
[ci:skip-build]: already built successfully in CI
There is a special check in init_2nd.sh for older postmarketOS
installations that do not have a valid /etc/fstab file. When /boot does not
appear in fstab, it searches for the boot partition and mounts it manually.
However, /boot might be intentionally omitted in fstab, e.g. because we
just have a single rootfs partition that also contains /boot. In that case
it will wait forever, trying to find the missing boot partition.
The old installations do not have any entries in fstab, so fix this by
checking if the file is empty instead (with all comments and whitespace
removed).
[ci:skip-build]: already built successfully in CI
This reverts commit 1259d74b09.
The main reason why that change was necessary is because we skipped
mounting subpartitions entirely if we found a potential root partition
(which could be simply a crypto_LUKS partition from a different distro).
Now that we look only for the actual root partition (based on the UUID),
this should not happen anymore.
Checking both conditions causes delays if there is no boot partition,
e.g. if pmOS was installed with --single-partition. Usually we don't need
to mount the boot partition anymore, because all needed files are part of
the initramfs. So let's drop the check for the boot partition again and
rely on the UUIDs to ensure we set up the correct partitions.
When using an encrypted installation of postmarketOS, the pmos_root_uuid=
on the cmdline only tells us the UUID of the crypto_LUKS partition. Once
the partition is unlocked, we perform the the old unreliable auto detection
again. This might mount the wrong partition if multiple installations of
pmOS are attached to the system.
After we unlock the root partition, we know exactly where the root
partition is supposed to be (= at /dev/mapper/root). Let's use that
directly instead of going through the whole detection sequence again.
Right now we fallback to the old behavior of searching for the "pmOS_root"
label when the root partition specified by pmos_root_uuid= on the cmdline
is not found. This works fine most of the time, but there are edge cases in
which this does not behave correctly. Problems occur especially if there
are multiple installations of pmOS (e.g. one on internal storage, and one
on USB drive/SD card). Depending on timing or enumeration order, the system
might boot into the wrong rootfs if the intended root partition shows up
too late.
For the boot partition we already enforce the UUID provided on the cmdline.
Let's apply the same for the root partition to ensure we always boot into
the correct root partition.
To support the HTC One (M8), a new specific target is required
since it needs non-default values for mkbootimg.
Signed-off-by: Alexandre Messier <alex@me.ssier.org>
LXQt can control the display brightness. It doesn't save and restore it
over boots, however. In distributions with systemd this is handled by
"systemd-backlight@.service". For OpenRC the package brightnessctl offers
a service saving the state of the brightness at shutdown and reboot.
In addition to the pmos.debug-shell cmdline argument, add
pmos.usb-storage=<block-device> to set up the USB mass storage gadget by
default when going into debug shell. This allows building a special boot
image/option that directly exposes the storage for flashing, without having
to type in extra debug-shell commands.
Right now we have two similar implementations of setting up a USB mass
storage gadget, in init_functions.sh and as separate script for the
debug-shell. Given that init_functions.sh is available in debug-shell
anyway, unify both in a common setup_usb_storage_configfs() function.
Having this included in the initramfs debug-shell by default (without
installing postmarketos-mkinitfs-hook-debug-shell) also simplifies
recovery, since you can set up the USB storage for repairing the flashed
postmarketOS installation in case of boot failures. The size overhead is
minimal, since this has no extra dependencies.
BTRFS only supports online resizing. Right now we implement that by
temporarily mounting the file system, resizing it, and then unmounting it
again. But most of this is redundant since we mount the rootfs at /sysroot
immediately after.
Avoid this by splitting the file system resizing in offline resize (before
mount) and online resize (after mount) and resize BTRFS after mounting
/sysroot. For EXT4 we can either do offline resizing or online resizing.
Keep offline resizing for now for better compatibility with older kernels.
F2FS does not seem to support online resizing, so we need to keep the
functionality for offline resizing anyway.
Drop the splash for now, since it would introduce flickering on each boot.
We can restore it later if needed (ideally by adding a way to update the
splash message without restarting pbsplash).
Right now we use the resize2fs -f (force) option, which "Forces resize2fs
to proceed with the filesystem resize operation, overriding some safety
checks which resize2fs normally enforces." For example, this flag instructs
resize2fs to attempt resizing file systems with errors in some situations.
We primarily care about resizing the file system on initial boot, where we
shouldn't have any errors in the file system. For all other subsequent
boots, we shouldn't risk the filesystem data just to resize it again.
So let's drop the -f flag and only resize clean file systems.
At the moment, the root file system is only resized to span the entire
partition if we previously also resized the partition itself. However, if
a rootfs image without subpartitions is flashed to a pre-existing partition
this means that the installation only has very limited space available
without manual resizing.
Such a setup is used for devices using the "fastboot-bootpart" flasher
(e.g. asus-me176c), where boot and root images are flashed to two separate
partitions and the device boots directly from the boot partition.
Avoid this problem on these devices by always resizing the root file system
on each boot. All the resize tools exit early if the file system is already
expanded to the maximum size. It's faster to call resize2fs unconditionally
instead of manually checking if the file system needs resizing before.
Similar tooling like systemd-growfs also resizes unconditionally.
Fix the bug that prevented "pmbootstrap install" from working with
postmarketos-ui-gnome (not -mobile).
This bug has been here in pmaports for a long time, but until recent
changes in apk's resolver code, this did not fail (apk installed
gnome-extensions-app instead of gnome-mobile-extensions-app in that
scenario).
How it happened:
* postmarketos-ui-gnome has _pmb_recommends="gnome-extensions-app".
* pmbootstrap: pmb.install._install.get_recommends() works like this:
1. Look at the packages i in _pmb_recommends of the packages that
will be installed in "pmbootstrap install".
2. For each package j in _pmb_recommends of i:
2.1 Add all packages in j's _pmb_recommends to the list of
packages to be installed.
(2.2 Recurse by doing 1. with each package in j's _pmb_recommends.)
* In step 2:
* pmaports doesn't have a gnome-extensions-app (it's in Alpine, a
subpackage of gnome-shell).
* Therefore our gnome-shell-mobile fork gets looked at, which has a
gnome-mobile-extensions-app subpackage that provides
gnome-extensions-app.
* pmbootstrap looks at the _pmb_recommends of the gnome-shell-mobile
package, which has "gnome-mobile-extensions-app" (this is wrong,
it should be in postmarektos-ui-gnome-mobile instead and this patch
fixes this!).
* pmbootstrap adds the "gnome-mobile-extensions-app" to the list of
packages to be installed.
* The result is an "apk add" line that has "postmarketos-ui-gnome" and
"gnome-mobile-extensions-app" (and more packages), which results in a
conflict betwen gnome and gnome-mobile packages.
Fixes: issue 3360
[ci:skip-vercheck]: _pmb_recommends changes don't need package rebuilds
[ci:skip-build]: already built successfully in CI
Ensure postmarketos-base-nofde is built before this package, otherwise
bootstrapping this on a new stable branch fails. This does not need to
be backported, as postmarketos-base-nofde has already been built for
v24.12.
Related: https://builds.sr.ht/~postmarketos/job/1384748
