The value after the colon is defines to apply only to the
XDG_CURRENT_DESKTOP. Phosh upstream defines it for setting a yellow
accent color and no background image, and therefore takes priority if we
don't enforce it to the XDG_CURRENT_DESKTOP value aswell.
Part-of: https://gitlab.postmarketos.org/postmarketos/pmaports/-/merge_requests/6479
The value after the colon is defines to apply only to the
XDG_CURRENT_DESKTOP. Phosh upstream defines it for setting a yellow
accent color and no background image, and therefore takes priority if we
don't enforce it to the XDG_CURRENT_DESKTOP value aswell.
Part-of: https://gitlab.postmarketos.org/postmarketos/pmaports/-/merge_requests/6479
The DTS patches for it do not apply anymore, and exkc has said that
their device is now broken, so they are unable to continue maintaining
the port.
As a stop-gap solution, xiaomi-once users who still wish to use
postmarketOS can use the p212 port. They are also welcome to fix the
devicetree patches and upstream them.
Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org>
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6412
Installing systemd-resolved by default is still probably not a good
idea (e.g. until #1430 is fixed, at least?), but this adds config for
NM and sd-resolved to get the stub resolver set up automatically when
systemd-resolved is installed manually by a user.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6250
[ci:skip-build]: already built successfully in CI
This helps ensure the logs are actually flushed.
The numbers chosen are relatively arbitrary, and it might be that using
a longer delay, maybe with more messages too, is desirable.
Right now, it's printing 20 times over a span of 2 seconds.
The whole `precision` schtick is how we can approximate float division,
when using only integer division. Then, the important trick is to shove
the given number back into the correct representation for `sleep`, and
careful `printf` application gives us exactly what we need.
Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6335
[ci:skip-build]: already built successfully in CI
- Point shellcheck to the files this is sourcing
- Tell it about the shell in use
- Drop unused variable (grepped around)
The last change is about how the hooks are ran. The warning shellcheck
was giving was that using `if <command...>; then ...; fi` is preferred,
instead of comparing `$?`.
This is exactly what is now being done, so the branches have been
swapped around, and the command (full path to a hook) is being used
within the if condition.
Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6335
alpine-base directly depends on openrc. We have had different[1]
conversations[2] with upstream. And the main conclussion[3] has been:
if you want to do something different, just depend on things
yourself. This is indeed what docker images do. So let's just get the
things that we want from alpine base (quite some!), and ignore what we
don't want (openrc, busybox openrc and init packages). alpine-conf is
now a dependency of postmarketos-base-openrc, since it dependes on
openrc for calling setup-* scripts. postmarketos-base-systemd already
implements those needed.
Contrary to the first attempt[4], I have kept the dependency on
alpine-release. Changes to that are independent to the usr-merge, and
can be done as a follow-up.
This should allow to drop the fork of alpine-base currently in the
systemd-extra repository!
To this day, every single pmOS installation will have alpine-base in
the world file, which means that systemd installs will the forked
package until users specifically run "apk del alpine-base". We must
add this to release notes and to an edge blog post. Alternatively we
could have an empty package with a very high version providing
alpine-base.
[1] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63935
[2] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71686
[3] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71686#note_435428
[4] https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/5026
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6375
Why is this needed?
To be able to test the usr-merge downstream we need to stop
depending on alpine-baselayout. For that, we need to stop depending on
alpine-base. This is a first step to create a "provides" solution
downstream between openrc and systemd systems, so that in a follow-up
commit we can recreate alpine-base downstream without the hard-coded
openrc dependency. The virtual instead of a versioned dependency means
that:
* In theory systemd and openrc could be installed in parallel. In
practice we avoid that with !openrc in the systemd package and
!systemd in the postmarketos-base-openrc one. There is a lot more
work required with provides (both upstream and downstream) regarding
things like elogind and eudev to be able to even have them
package-wise ready to be installed in parallel
* There must always be one installed. Here we have 3 scenarios:
* pmbootstrap install where pmbootstrap will decide which one
* update from existing install. The virtual makes sure that APK
won't remove the local package because versions changed
* Manual APK work, where the provider_priority or the user will
choose
How does this work? Hypothesis:
* openrc upgrades: the postmarketos-base-openrc remains installed,
moves from being an "install_if", to be there because it fulfills
the postmarketos-base-init requirements.
* systemd upgrades: postmarketos-base-systemd is still in
/etc/apk/world, and it fulfills the new dependency in
postmarketos-base. Nothing happens.
* openrc installs: pmbootstrap will choose one of
postmarketos-base-openrc and postmarketos-base-systemd... But which?
The one with the higher version?
* systemd installs: postmarketos-base-systemd is installed before
anything else is. That means, postmarketos-base-init will already
be satisfied when postmarketos-base gets installed, and openrc will
not be installed
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6375
This is inconsistent through the file. In addition, the "_" prefix is
often used when a function is not directly a split function from a
subpackage, but a "private" function that others call. So remove it to
make it clear that these are subpackage split functions
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6375
Xiaomi didn't ship some firmware in the vendor partition, so i needed to package that firmware by myself, at that point i had some reports that in some devices (or some android versions) they were missing some firmware, so i would rather go back to package the firmware in a different package
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6429
Mainline port supports all features currently available on the
platform, bringing whyred in line with the best supported devices
on the sdm660 kernel.
Working:
* framebuffer display
* regulators
* volume/power keys
* gpio hall sensor
* battery fulegauge & charger
* PMIC vibrator
* PMIC WLED backlight
* notification LED
* storage: eMMC, SD cards
* USB (only USB2 and only gadget mode, like the rest of the platform)
* hardware video enocder/decoder (venus)
* WCN3990 Bluetooth, Wi-Fi
* Synaptics rmi4 touchscreen
* Display (mdss), GPU Adreno 509
* LCD IPS video mode panel (Tianma TD4310)
* sensors are automagically supported too
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6469
Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Robert Eckelmann