The previous implementation of this caused upower to select a thing
called 'flash_strobe' in the L5, which doesn't operate like a
flashlight. This changes the detection logic to look at the suffix, on
the pinephone the device ends in ':flash', and on the L5 it ends in
':torch'.
fixed#967
This patch is in purism's fork and it removes messages like this when
starting upower on the librem5 by properly detecting/setting the type:
TI:15:11:12 did not recognise USB path /sys/devices/platform/soc@0/30800000.bus/30a20000.i2c/i2c-0/0-003f/power_supply/tps6598x-source-psy-0-003f, please report
...
TI:15:11:12 did not recognise USB path /sys/devices/platform/soc@0/30800000.bus/30a50000.i2c/i2c-3/3-006a/power_supply/bq25890-charger, please report
Handle USSD QMI indication messages.
Add support for UCS2 USS Data coding scheme.
Check for User Action TLV type.
Downstream the accepted ofono patch as temporary solution.
This has upstreamed fixes for call audio on the L5, but upstream hasn't
made a release yet. In the meantime, this is needed for calls to work on
5.11.0 and later kernels
[ci:skip-build]: won't finish in time
The TLVs are documented in GobiAPI. I pass 0xff for the call ID, as the
stock RIL appears to always do. I would guess it means "current foreground
call."
The call ID is returned in TLV 0x10, but I didn't implement parsing of
that.
Co-authored-by: Joey Hewitt <joey@joeyhewitt.com>
Acked-by: Alexey Andreyev <aa13q@ya.ru>
GNOME settings daemon notifies the user that the device will
suspend soon through a notification.
However, this triggers the notification LED which stays on during
suspend, causing unnecessary power consumption.
Plasma 5.20.90 was being built while a libgps upgrade happened. It seems
that even though the package had already been built for every arch, it
had not for x86 yet and thus our plasma-workspace is still depending on
the older package and fails to install because it isn't available
anymore
Just bump the pkgrel so it now gets correctly build against libgps.so.27
Seems there are more places where ecm_find_qmlmodule is used
To fix the build from failing on armv7 we should disable them all
[ci:skip-build]: don't try to build all depends, takes too long
[ci:skip-vercheck]: unblocking armv7 build, no need to bump pkgrel
The build is still failing, probably because ecm_find_qmlmodule is not
only present in the main CMakeLists.txt, but also in others.
$ git grep ecm_find_qmlmodule
CMakeLists.txt:ecm_find_qmlmodule(QtQuick 2.3)
CMakeLists.txt:ecm_find_qmlmodule(QtQuick.Controls 1.2)
CMakeLists.txt:ecm_find_qmlmodule(QtQuick.Layouts 1.3)
CMakeLists.txt:ecm_find_qmlmodule(QtQuick.Window 2.1)
CMakeLists.txt:ecm_find_qmlmodule(QtMultimedia 5.0)
CMakeLists.txt:ecm_find_qmlmodule(org.kde.kquickcontrolsaddons 2.0)
CMakeLists.txt:ecm_find_qmlmodule(org.kde.plasma.core 2.0)
CMakeLists.txt:ecm_find_qmlmodule(org.kde.plasma.components 2.0)
kcmkwin/kwindesktop/CMakeLists.txt:ecm_find_qmlmodule(org.kde.plasma.core 2.0)
kcmkwin/kwineffects/CMakeLists.txt:ecm_find_qmlmodule(org.kde.plasma.core 2.0)
[ci:skip-build]: don't try to build all depends, takes too long
[ci:skip-vercheck]: unblocking arm build, no need to bump pkgrel
Seems we missed these when forking Plasma and now the armv7 builders are
failing on it
[ci:skip-build] Won't succeed anyway as the packages haven't been
uploaded to the repos yet, so pmbootstrap will try to build the entirety
of Plasma and fail because it takes too long
[ci:skip-vercheck] No need to bump pkgrel
2.0.15 is a development 'version' (it'll never be released), and will be
replaced by 2.0.16 when that is released. The reason for forking this
is because there are some issues that are resolved here that prevent
SDL2 from working on the Librem 5. The fixes cannot be easily
backported to 2.0.14, hence the fork and upgrade.
fixes#950
[ci:skip-build] Never succeeds in time
[ci:skip-vercheck] We need our Mauikit to be a rel newer than in Alpine
repos, but the CI doesn't like it
This includes a big rewrite in kwin which should increase the
performance a whole lot, and some awesome other stuff
Fix about dialogs not being adaptive and all other changes by Purism,
which are the reason why we use the fork in the first place. The patches
didn't get applied in the previous version we had packaged in
postmarketOS, because the patches are in debian/patches now.
Remove check-version.py, it's in the source tree now.
bpo is currently failing to build images with the on-device installer,
because calamares needs to be rebuilt against libboost_python38.so. Fork
it until that's resolved. [ci:skip-vercheck]
[ci:skip-build]: already built successfully in CI
Related: https://builds.sr.ht/~postmarketos/job/398948#task-img_installer-307
This syncs u-boot with the upstream branch, and includes the following
new features:
- support for board rev in u-boot
- fix uart4
[ci:skip-build]: already built successfully in CI
This packages the libhandy work in dino's feature/handy branch, which
makes the UI quite usable on mobile displays. A couple of windows don't
work well yet (e.g., the setting window), but chatting/omemo/file
transfer all work pretty well.
Currently phosh is broken in postmarketOS edge. Fork wlroots from Alpine
and revert the new consistency check that results in the breakage. I've
submitted the same to Alpine, but let's get it in pmOS now so it is
fixed ASAP.
Alpine MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14522
[ci:skip-vercheck]: new package added with -r1 on purpose
plasma-nano (albeit saying it is 5.20.1) is pointing to the master branch
and kept as-is (there is no updates in master and I don't see a reason to
downgrade it to the actual 5.20.2 tag which is a few small commits behind
the master).
Remove patches:
'0001-gtk-meson.build-add-new-hdy-files.patch' and
'10-Revert-gdkseatdefault-Grab-touch-events-where-applic.patch'
appear in the code downloaded from Purism at precisely the
location of the patches.
[ci:skip-build]: already built successfully in CI
For some reason, the ModemManager build tends to freeze when built
with QEMU user emulation for arm*. Changing the build to use a single
thread only (-j1) avoids that, although the build is slower of course.
Also limit building to "armhf armv7 aarch64" since the forks are not
needed on any other architectures, to reduce build times a bit. The
other architectures can just use the upstream packages from Alpine.
This allows to connect the modem to the Internet with oFono.
I have verified that this does not break anything if the "rmnet0"
network interface is missing. Plus, all mainline devices currently
covered by the package should also be able to use the new "BAM DMUX"
network driver that is used as network interface to the modem.
(Note: This works differently on newer SoCs, but they also need
something different in oFono...)
Most older Qualcomm SoCs (e.g. MSM8916, MSM8974, ...) communicate
with the modem through shared memory. On mainline kernels these
shared memory channels are exposed through the RPMSG subsystem.
This is different from communication through USB or serial interfaces
that are currently supported by ModemManager.
This commit forks the "modemmanager" package from Alpine and adds
a patch that allows ModemManager to talk to modems through the RPMSG
subsystem.
Working functionality: Calls, SMS, Mobile Data
The same patch has also been submitted upstream:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/363
For some reason, the ModemManager build tends to freeze when built
with QEMU user emulation for arm*. Changing the build to use a single
thread only (-j1) avoids that, although the build is slower of course.
The same thing seems to happen fo oFono as well, so set that to -j1 too.
Also limit building to "armhf armv7 aarch64" since the forks are not
needed on any other architectures, to reduce build times a bit. The
other architectures can just use the upstream packages from Alpine.
* add install_if to pull in w/ gnome-software
90b924a334
* use abuild-meson & meson compile/test/install
47360782ab
* use apk-polkit-rs instead of apk-polkit
0f6c2d95f1
* upgrade to 0.8.1
ce795a4d27
* don't pull in alpinelinux-apppstream-data
c35a1b4ba7
NOTE: alpinelinux-apppstream-data was removed in
946967b01f
This patch is from upstream gnome-contacts:
22ac2c6fec
Purism doesn't have it in their fork:
https://source.puri.sm/Librem5/gnome-contacts/-/issues/43
[ci:skip-vercheck]: some of these have pkgrel>0 - let's keep that in
order to have less differences with v20.05.
[ci:skip-build]: generated log is too long, CI fails
This upgrades u-boot to the latest upstream Purism version, and uses the
latest DDR training firmware.
APKBUILD was reformatted to replace indentation with tabs.
We were using a frequency of 624 which froze my device and in the past
other units too. Set it back to 552 as before so this doesn't happen
anymore
This is being upstreamed, https://gitlab.com/pine64-org/u-boot/-/merge_requests/3
(cherry picked from commit 88b48dee152686a887809ddb296cfd96e0c89f55)
Alpine's aarch64 builder is stuck and did not build 20.04.3-r1 yet. This
causes kde/itinerary from pmaports.git to fail:
https://builds.sr.ht/~postmarketos/job/282427#task-pmbootstrap_build-415
I've verified that this package builds for aarch64 with pmbootstrap, and
disabled other architectures.
The "shellprocesstest" is failing when building for armv7 on sr.ht. I
was not able to reproduce it locally. Just disable all tests for now.
It would be better to just disable the failing test, but since I can't
reproduce it locally I can't say that the build will go through then.
This package is in temp/, so let's not waste much time here. !check can
be removed when upstreaming it to Alpine.
[ci:skip-vercheck] [ci:skip-build]
Taken from upstream. Our mesa-git is pretty outdated, we should update
it soon. But we need to unblock the repository first, so this is the
fastest way for now.
"plasma" and some related packages are currently missing in Alpine edge
armv7 due to a cyclic dependency. Let's disable all packages depending
on plasma for armv7 temporarily, to get the pmOS edge armv7 repo up
again.
[ci:skip-build], [ci:skip-vercheck]: only arch line changed
Related: build.postmarketos.org#72
Add patch to fix build for armv7, armhf. That patched version is being
upstreamed to Alpine. Fork it now, so our builds are not blocked.
Related: builds.postmarketos.org#72
gitlab.com had a service disruption, so it was not possible to "git
clone" from gitlab.com from some regions, like where the sourcehut
infrastructure is located. Since we are building our packages on
builds.sr.ht, this caused all packages that should be built at that time
to fail. It is working again, so bump the pkgrels to restart the builds.
This switch has happened in the Alpine repos quite a while ago and most
of the pmOS packages were using it already too, so let's switch over the
last ones as well.
This also cleans up the APKBUILDs where necessary
Put virtual keyboard style into a subpackage, and let the main package
depend on it. That way, it can be used in postmarketos-ondev, without
pulling in all of plasma-phone-components.
Fails to build, because extra-cmake-modules from Alpine is not available
for armhf. Its APKBUILD says "Blocked by qt5-qtdeclarative".
[ci:skip-vercheck]
At the moment we have Contributor: lines on some packages (but not all of them),
but often they don't represent the actual contributors to the package very well.
E.g. when we added them retroactively to the device packages we only added
the initial contributor (which isn't necessarily the person
who made most of the work for a device...)
The Git history is the most representative source for figuring out
who contributed to a package, so there is no reason to duplicate that
into the APKBUILD.
[skip ci]: way too many packages
Follow-up to cbc6b9fcd7
Build locally for both armv7 and aarch64 fine.
[ci:skip-build] x86_64 build is disabled anyway
Signed-off-by: Alexey Min <alexey.min@gmail.com>
* Upgrade to the released stable version of upstream u-boot.
* Added patch to make the led on the Pinebook Pro light up earlier
* Added the update-u-boot script from Alpine with updates for the rk3399
devices
This adds a package that builds u-boot from the pine64/u-boot repository
which includes patches for enableing less hardware while booting so
there's quicker feedback that the power button has been pressed.
It also has a seperate patch file that modifies the clockspeed for the
memory which is one of the main performance bottlenecks of the A64 SoC.
It's a patch file so it's quick and easy to test out other clock speeds
when building. 600Mhz is stable but it should be able to run up to
624Mhz.
This fixes 1943ead268, which accidentally
removed the dev() function that generates the mesa-git-dev package..
causing mesa-dev to be pulled in in cases where mesa-dev is required
(and failing because mesa-dev is older)
[ci:skip-build]: already built successfully in CI
This was only needed to load the ALSA PulseAudio plugin outside
the chroot when running QEMU. Now that we allow configuring the
QEMU PulseAudio backend directly this is no longer needed.
At the moment, installing the rootfs for ouya-ouya fails with:
ERROR: unsatisfiable constraints:
libdrm-grate-2.4.100_git20191221-r0:
conflicts: libdrm-2.4.100-r0[libdrm]
libdrm-2.4.100-r0[so:libdrm.so.2=2.4.0]
libdrm-2.4.100-r0[so:libdrm_tegra.so.0=0.0.0]
libdrm-2.4.100-r0[so:libkms.so.1=1.0.0]
satisfies: device-ouya-ouya-1-r12[libdrm-grate]
libvdpau-tegra-0_git20190315-r0[libdrm-grate]
.pmbootstrap-20200110.144341[libdrm-grate]
.pmbootstrap-20200110.144341[libdrm]
mesa-gl-19.3.2-r0[so:libdrm.so.2]
directfb-1.7.7-r1[so:libdrm.so.2]
directfb-1.7.7-r1[so:libkms.so.1]
mesa-dri-swrast-19.3.2-r0[so:libdrm.so.2]
mesa-19.3.2-r0[so:libdrm.so.2]
libdrm-2.4.100-r0:
conflicts: libdrm-grate-2.4.100_git20191221-r0
libdrm-grate-2.4.100_git20191221-r0[so:libdrm.so.2=2.4.0]
libdrm-grate-2.4.100_git20191221-r0[so:libdrm_tegra.so.0=0.0.0]
libdrm-grate-2.4.100_git20191221-r0[so:libkms.so.1=1.0.0]
satisfies: .pmbootstrap-20200110.144341[libdrm]
mesa-gl-19.3.2-r0[so:libdrm.so.2]
directfb-1.7.7-r1[so:libdrm.so.2]
directfb-1.7.7-r1[so:libkms.so.1]
mesa-dri-swrast-19.3.2-r0[so:libdrm.so.2]
mesa-dri-swrast-19.3.2-r0[so:libdrm_amdgpu.so.1]
mesa-dri-swrast-19.3.2-r0[so:libdrm_nouveau.so.2]
mesa-dri-swrast-19.3.2-r0[so:libdrm_radeon.so.1]
mesa-19.3.2-r0[so:libdrm.so.2]
mesa-19.3.2-r0[so:libdrm_amdgpu.so.1]
mesa-19.3.2-r0[so:libdrm_nouveau.so.2]
mesa-19.3.2-r0[so:libdrm_radeon.so.1]
Looking closer at the error we see that:
1. We want to explicitly install libdrm-grate for device-ouya-ouya.
2. libdrm-grate provides
- so:libdrm.so.2=2.4.0
- so:libdrm_tegra.so.0=0.0.0
- so:libkms.so.1=1.0.0
3. But the mesa package also builds AMD and Nouveau drivers and
therefore requires:
- so:libdrm_amdgpu.so.1
- so:libdrm_nouveau.so.2
- so:libdrm_radeon.so.1
These libraries are not provided by libdrm-grate, therefore it is impossible
to install mesa and libdrm-grate at the same time.
A simple solution to fix this problem is to let libdrm-grate provide
these additional libraries as well - the package size overhead is negligible
and the additional drivers build just fine.
[ci:skip-build]: already built successfully in CI
At the moment, every device that wants to make use of mesa-git needs
to depend on all relevant mesa-git subpackages.
We can simplify this by adding these directly as depends for the
-dri- package that most devices will be depending on. That way,
the fact that you need to depend on all relevant subpackages is
mostly hidden away as "implementation detail" in the mesa-git
package, and no special care is required when using mesa-git.
This renamed the u-boot package for Purism librem5 devices, since the
phone and devkit share the same u-boot version. It also updates the
various components to the latest versions
This updates ATF, DDR/HDMI firmmware, and u-boot versions, and generates
a unified image that can be flashed at an offset of 2KiB.
mkimage is also no longer used to generate the final image.
Some old unused functions copied when this APKBUILD was forked were also
removed.
