Casey authored 4 months ago and Oliver Smith committed 3 months ago

Signed-off-by: Caleb Connolly <caleb@postmarketos.org>

[ci:skip-build]: already built successfully in CI

Minecrell authored 4 months ago and Oliver Smith committed 3 months ago

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).

Minecrell authored 4 months ago and Oliver Smith committed 3 months ago

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.

Minecrell authored 4 months ago and Oliver Smith committed 3 months ago

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.

Raymond Hackley authored 1 year ago and Newbyte committed 4 months ago

[ci:skip-build]: already built successfully in CI

Raymond Hackley authored 4 months ago and Newbyte committed 4 months ago

[ci:skip-build]: already built successfully in CI

Fiona Klute authored 4 months ago and Clayton Craft committed 4 months ago

/usr/lib/NetworkManager/dispatcher.d/50-tethering.sh had a typo in the
"killall" command in the "disable_tethering" function, leading to it
never stopping any unudhcpd process. As a new instance is started each
time a USB cable is connected, so the number of instances kept growing
until reboot. Fix the typo so any old unudhcpd instance is actually
stopped before starting a new one.

To illustrate the bug, a sample with an uptime of 4 days:

$ ps w | grep unudhcpd
 2467 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
 5009 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
 5525 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
 6360 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
 7271 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
 9356 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
11045 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
14779 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
15696 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
17454 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
19119 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
24729 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
25565 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
25691 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
27417 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
30649 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
31690 root      0:00 unudhcpd -i usb0 -s 172.16.42.1 -c 172.16.42.2
[ci:skip-build]: already built successfully in CI

Casey authored 4 months ago and Oliver Smith committed 4 months ago

* reduce op6 default earpiece volume
* add symlinks to enable audio when booting with u-boot

Signed-off-by: Caleb Connolly <caleb@postmarketos.org>

Related: https://fosstodon.org/@postmarketOS/113624366198561582

[ci:skip-build]: already built successfully in CI

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

Raymond Hackley authored 8 months ago and Oliver Smith committed 4 months ago

[ci:skip-build]: already built successfully in CI

Adam Thiede authored 4 months ago and Oliver Smith committed 4 months ago

replace power-profiles-daemon with virtual package

[ci:skip-build]: already built successfully in CI

Newbyte authored 4 months ago and Oliver Smith committed 4 months ago

[ci:skip-build]: already built successfully in CI

Ferass El Hafidi authored 4 months ago and Anjan Momi committed 4 months ago

lafrite has u-boot in SPI already

it also prevents lafrite from booting because pmbootstrap uses GPT partitioning now.

Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org>

Jan Jasper de Kroon authored 4 months ago and Newbyte committed 4 months ago

[ci:skip-build]: already built successfully in CI

Jack K authored 4 months ago and Newbyte committed 4 months ago

[ci:skip-build]: already built successfully in CI

Cedric Busacker authored 4 months ago and Newbyte committed 4 months ago

Fixes the problem that BOOT partition is only 10 MB big while boot.img is 13 MB now.
Also heimdall was stuck at 7% with the sparse flag this gets fixed.

[ci:skip-build]: already built successfully in CI

[ci:skip-build]: already built successfully in CI

As @grimler stated in MR !5887 (comment) [1], samsung-jackpotlte,
samsung-xcover4lte, and samsung-a30 share the same name for Wi-Fi
proprietary blobs, and packaged in their own specific firmware package.

The problem is these firmware packages put files in the same directory
as `firmware-samsung-a51`: /lib/firmware/postmarketos/mx140/. This opens
up the probability of conflicting blobs when multiple firmware packages
are installed on the system, resulting in wrong blobs used.

To ensure that this firmware is located in its own directory, move
`samsung-a51` blobs into its own subdirectory. This way, `a51` blobs
will stay intact whether multiple firmware packages are installed.

[1] !5887 (comment 459185)

Successfully built and booted postmarketOS on Samsung Galaxy A51. It's based on Exynos 9611 SoC.

Currently, these are tested working:

- Boots from internal storage
- Display (DECON driver needs to be patched. Included in the kernel package)
- Framebuffer (additionally with msm-fb-refresher to refresh the screen)
- Touchscreen
- USB Networking (RNDIS)
- Wi-Fi

Tested UI environments: XFCE 4 & Console.

Wiki: https://wiki.postmarketos.org/wiki/Samsung_Galaxy_A51_(samsung-a51)

[ci:skip-build]: already built successfully in CI

Barnabás Czémán authored 4 months ago and Anjan Momi committed 4 months ago

Upgrade lk2nd to 20.0.

Additional changes:
- Add msm8996 subpackage
- Limit msm8953, msm8996, msm8952-xiaomi-land packages to aarch64.

Oliver Smith authored 4 months ago and Anjan Momi committed 4 months ago

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

Fixes #1920

[ci:skip-build]: already built successfully in CI

Actually Xfce4 is capable to use the "draw-user-backgrounds" option of
"slick-greeter", applying the users wallpaper on the greeter.

However, as it turns out, the users background in pmOS Xfce4 is set at first
login of the user. Therefore, the greeters background is black at the first
boot.

Therefore set the greeters background to the default postmarketOS wallpaper.

Move the polkit-elogind into depends= instead of pmb_recommends=, so
packages depending on postmarketos-base-ui-gnome can build successfully
again. The previous fix only helped for "pmbootstrap install", this fix
will help for both cases.

Without this, e.g. postmarketos-base-ui-gnome-mobile fails to build:
https://builds.sr.ht/~postmarketos/job/1384469
[ci:skip-build]: already built successfully in CI

Add polkit-elogind to _pmb_recommends, to help apk resolve the polkit
depends again. Otherwise it fails with a conflict since recent changes
in apk's dependency resolving code.

Fixes: issue 3349
[ci:skip-vercheck]: pmb_recommends change doesn't need rebuild
[ci:skip-build]: already built successfully in CI