This is a followup to !109 (merged). Affected packages:
* device/linux-samsung-p4wifi
* device/linux-sony-tulip
* device/linux-teclast-x80pro
* main/linux-postmarketos-allwinner
* main/linux-postmarketos-mainline
* main/linux-postmarketos-qcom
* main/linux-postmarketos-stable
[skip ci] I have confirmed that all 7 kernels still compile.
Regenerate these aports, so the test case does not complain anymore
that they are outdated. Adds armv7 to the arch lines, as that is the
aportgen change which was done in pmbootstrap!1730.
Workaround for a build error on aarch64, where the binary package
repository is currently stuck. Compiling it for aarch64 like this:
$ pmbootstrap build --strict --arch=aarch64 qemu
Resulted in:
>>> qemu: Analyzing dependencies...
ERROR: unsatisfiable constraints:
openssl-dev-1.1.1a-r0:
conflicts: libressl-dev-2.7.4-r2[pc:libcrypto=1.1.1a]
libressl-dev-2.7.4-r2[pc:libssl=1.1.1a]
libressl-dev-2.7.4-r2[pc:openssl=1.1.1a]
satisfies: curl-dev-7.62.0-r2[openssl-dev]
libssh2-dev-1.8.0-r4[pc:libcrypto]
libssh2-dev-1.8.0-r4[pc:libssl]
spice-dev-0.14.1-r3[pc:openssl]
libressl-dev-2.7.4-r2:
conflicts: openssl-dev-1.1.1a-r0[pc:libcrypto=2.7.4]
openssl-dev-1.1.1a-r0[pc:libssl=2.7.4]
openssl-dev-1.1.1a-r0[pc:openssl=2.7.4]
satisfies: world[libressl-dev]
libssh2-dev-1.8.0-r4[pc:libcrypto]
libssh2-dev-1.8.0-r4[pc:libssl]
spice-dev-0.14.1-r3[pc:openssl]
>>> ERROR: qemu: builddeps failed
Note that the only package not mentioned in both "satisfies" outputs is
curl-dev. The real questions are: why is libressl-dev getting pulled in
at all? (Alpine switched back from libressl to openssl, so this should
not happen). And why does this only happen for aarch64, but not for
x86_64 and armhf? But at least this patch unblocks the package builder.
Builds abuild-sign and abuild-tar.static without any dependencies, so
they can be used outside of an Alpine Linux system. We need this for
build.postmarketos.org.
In this CI test, we add the upstrem postmarketOS/pmaports.git
remote to the checked out git repository. Do not crash when it exists
already, so we don't need to remove it before each run when testing
locally.
* Move a comment that was after a line of code above that line. That
line was very long compared to all others in the file, and now the
file fits in 80 characters in every line, like PEP-8 recommends.
* Replace "folder" with "dir" in the comments (as I learned lately
that "folder" is only a Windows concept).
The modules wl12xx, mac80211 and cfg80211.ko are assembled as modules,
but due to the lack of the command 'make modules_install' in APKBUILD,
these modules are not included in the finished package. Because of this,
it was impossible to launch Wi-Fi on Samsung-i9003.
Modernize the APKBUILD. Load reboot mode kernel module, and uinput
kernel module (used by bluetoothd).
User facing changes:
* Uses some mainline sensor drivers.
* Fixes bluetooth audio stuttering (needs some userspace fixes though).
Various code refactoring happened. I tried to write a better looking
display panel driver rather than reuse the downstream driver. Not
quite there yet though.
Use latest sources from LineageOS, instead of the ones from andip71.
The APKBUILD is modernized to use the devicepkg-dev but unfortunately
compiling with gcc8 it doesn't boot.
The kernel config is updated with the required options to start the
lxc-android container and xf86-video-hwcomposer works
(tested with xfce4).
My plan was to add the firmware-samsung-klte with the subpackages for
the wifi blobs and a precompiled android system.img to use with
libhybris, but my device just died and I'm not able to power it on (I've
probably burnt the Power IC 😢)
As observed on UBPorts, hwcomposer implementation on Android 7 CAF (non-Nexus
Qualcomm) devices has slight differences in employed structs, which makes
them binary incompatible with AOSP headers.
Halium 7.1 android-headers extracted from LineageOS include those
modifications (e. g. https://github.com/Halium/android-headers/blob/halium-7.1/hardware/hwcomposer.h#L290),
so it is enough to add QTI_BSP/QCOM_BSP to defines of programs utilizing
those headers. In case of libhybris, only test_hwcomposer is affected so
far on 7.1 (might be not true for Android 5.1/6!).
This change avoids providing libhybris-7.1-caf package by building a
separate binary of test_hwcomposer for affected devices.
For i3 on the N900, which seems to be the only device using i3 at the
moment, I thought using Tabbed workspace layout as the default would be
best, since the screen is quite small, and having two split windows can
quickly make it impractical.
With this commit, all new windows will be created in tabbed
configuration. It is still possible to switch to stacking or standard
layout as needed, using the appropriate shortcut keys.
I noticed that some times the framebuffer driver gets configured in a
way that the ioctl performed by msm-fb-refresher returns something lower
than zero:
0ed263db09/drivers/video/fbmem.c (L877-L911)
For example when the Xorg starts I noticed it does a ioctl BLANK and
UNBLANK, but if msm-fb-refresher performs a ioctl in that moment it
stops its loop and exit.
For this reason I lost a lot of time trying to understand what was the
problem with Xorg not displaying anything until I noticed that I had
to restart the msm-fb-refresher.
With this change we don't have to care about msm-fb-refresher as it will
continue call ioctl PAN even if the framebuffer returns some negative
error code.
gcc-fix-put-user.patch doesn't apply cleanly to any kernel that
includes commit 538094 ("ARM: 8051/1: put_user: fix possible data
corruption in put_user") or a backport of it because the surrounding
lines (context) of the patch are different:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=537094b64b229bf3ad146042f83e74cf6abe59df
This commit fixes the problem by removing the context from the patch. It
also changes linux-sony-amami, linux-sony-aries, and linux-sony-taoshan
to use the shared patch.
I have confirmed that all six affected kernels still compile. [skip ci]
Ouya boots. Install instructions are being refined, but device does
boot through fastboot. Hoping to merge into master to encourage others
to contribute to the device.
This reverts commit ee659a5bb4
and increases the pkgrels of all affected linux pmaports.
I have compiled *every single kernel* that was modified with this
commit, and it worked. That took 12 hours. So I'm pretty confident that
this is a good commit. Let's roll it out and go back to stability \o/
I'll kick off the binary repo building directly after pushing this, but
it will take some time until all binary packages are available again.
[skip ci]: it wouldn't finish in time.
Add -j1 to compiling the standby code, which is compiled separately
already. This change seems to make the kernel always compile, I've
tried it 6 times, 3 times of that with pmbootstrap's "--no-ccache"
option. It got past an error about 30 seconds into the build, which
happened roughly 2 out of 10 times:
gcc6-armv6-alpine-linux-muslgnueabihf-ld: cannot find standby.o: No such file or directory
I thought, this was related to gcc6 changes, or to changes in abuild,
but both were not the case.
Grant Miller confirmed that this fixed the build, he was able to
compile the kernel ten times in a row with this commit.
The purpose of this package was to fill in until it is built in Alpine.
However, it takes forever to build the foreign arch versions. That's
due to the fact that GCC is compiling it self, and then the distcc
cross compiler magic does not work. Not worth it. [skip ci].
Further adjustments. It would have been better if I tried to build
it first, sorry for that. Another patch is coming in the pmbootstrap
repo, which makes it work even without the gcc6 pmaport.
Copy Alpine's gcc6 aport to temp. They don't have it built for aarch64
and armhf at the moment. Due to dependency checks, this means we can't
build the kernels that need gcc6, even when cross compiling with
gcc6-armhf etc. See #138 for details.
Do not add --pixman-type to the commandline, when
deviceinfo_weston_pixman_type is filled out.
--pixman-type was enabled in Weston with a custom patch, that currently
prevents us from upgrading Weston (#136).
The option allowed working around broken framebuffer drivers in
Android downstream kernels, which reported the wrong color format.
But it only works for Weston, the right way to patch this would be
patching the kernels, and we have some approaches here:
https://wiki.postmarketos.org/wiki/Troubleshooting:display#My_screen_is_red.21
When rendering on framebuffer, always do software rendering. This
should make it possible to boot up Plasma Mobile on most devices with
downstream kernels, although terribly slow. Still better than a black
screen though. Tested and working on the samsung-i9100.
We can improve the code and possibly make the rendering mode
configurable per device once we experimented more with:
* llvmpipe vs. softpipe on various devices
* armv7 (around the corner in Alpine)
* a proper display manager like lightdm
