Tracking issue of problems/solutions/etc regarding Unity 8 on postmarketOS:
Current status:
Unity 8 can be manually launched as root in QEMU x86_64.
Issues:
arch field was made x86_64-only because of build problems in QEMU - the build works fine on aarch64 for all packages but apparently not in QEMU (tests are failing, hanging, etc)
LightDM integration needs to be tested ("launch unity8 without root permissions")
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
GraphQL error: The resource that you are attempting to access does not exist or you don't have permission to perform this action
No child items are currently open.
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
@z3ntu I got nerd sniped by the ubuntu-app-launch issue and spent way too much time looking into it. It seems g-ir-scanner fails due to be a bug in QEMU's handling of pthread_cancel (of all things).
The saddest part is that ubuntu-app-launch doesn't even export any GIR functions, as far as I can tell: the functions.txt is entirely blank. Maybe just disabling the GIR part would get that package building.
Manually running the GIR command lets me keep the temporary files, including the executable that exited with the strange signal.
Thread 1 hit Breakpoint 8, 0x00000040008571c4 in pthread_kill () from /lib/ld-musl-aarch64.so.1(gdb) bt#0 0x00000040008571c4 in pthread_kill () at /lib/ld-musl-aarch64.so.1#1 0x0000004000855d68 in pthread_cancel () at /lib/ld-musl-aarch64.so.1#2 0x0000004000cf22cc in lttng_ust_exit () at /usr/lib/liblttng-ust.so.0#3 0x000000400085eef0 in () at /lib/ld-musl-aarch64.so.1#4 0x0000000000000000 in ()
lttng_ust_exit uses pthread_cancel. So a minimal reproduction of the issue would be:
Using strace outside the chroot on qemu shows qemu didn't pass through the sigaction, suggesting that QEMU handles sigaction itself, and that code didn't support signal 33:
Lol good job 😄
Did you try removing the qemu patch and see if that solves the issue? Edit: I guess you just didn't get to that part yet, continue uninterrupted until you fix everything 😉
@z3ntu I did try it with Ubuntu's qemu-user-static, which didn't have the patch; it instead caused qemu to exit with an error. I'm guessing QEMU just doesn't support that signal at all.
Anyways, no, this is probably as far as I can go with this, because
I'm not too familiar with QEMU internals.
This doesn't explain the barf of fortify-related messages. The GIR command has no output other than the signal 33 error. Then what's printing it?!
Adding CPPFLAGS, CFLAGS, and CXXFLAGS variables lets me reproduce the flood of fortify errors. But it seems that error is actually non-fatal: the command dies on the signal 33 thing instead.
But I hope that this is somewhat helpful.
(If you have an idea on what's causing the fortify issue, I'll be happy to try it though!)
@ollieparanoid@z3ntu We can also try patching lttng to not call pthread_cancel if QEMU user mode is detected, or to use LD_PRELOAD to override lttng or musl's functions to do the same.
I tried to install it on nexu5, as mentioned in the wiki. I get:
pparent@pierre-laptop:~/git/pmbootstrap$ ./pmbootstrap.py install --add unity8[11:50:45] *** (1/5) PREPARE NATIVE CHROOT ***[sudo] Mot de passe de pparent : [11:50:53] *** (2/5) CREATE DEVICE ROOTFS ("lg-hammerhead") ***[11:51:03] (rootfs_lg-hammerhead) install[11:51:06] NOTE: You can edit the 'arch=' line inside the APKBUILD[11:51:06] ERROR: Can't build 'unity8' for architecture armv7[11:51:06] See also: <https://postmarketos.org/troubleshooting>Run 'pmbootstrap log' for details.
I'm afraid this will eat up quite some time (which you likely don't have considering all the work you put in ubports, but maybe you know somebody who has time?), but in theory:
@z3ntu started porting the interface to postmarketOS and has already done an impressive amount of upstreaming with everything he fixed along the way. Unity 8 boots up so far, ubuntu-app-launch is working enough that applications can launch but everything locks up easily at this point. We need to package some actual apps as well, right now there is only the system settings app (in the picture).
I have a relatively well maintained state in the branch "feature/unity8_arches" which I rebase and fix every couple of months, the last hiccup was qtmir not compiling iirc because of mir upstream changes and I didn't cherry-pick patches from the xenial wayland branch to bionic yet.
@z3ntu Anything I can help. What is the status of this issue. I would really love using Lomiri(Ubuntu Touch) in pmOS. Big fan of C++/Qt. Now using Phosh with GNOME Shell.
Sorry if this isnt the right place to ask, but I'm getting an error building android-tools it seems near the end of pmbootstrap install with a samsung-a3. The exact error I get is here, but probably not enough to actually debug. Just looking to try out lomiri really:
/home/pmos/build/src/android-tools-31.0.0p1/vendor/boringssl/crypto/fipsmodule/sha/sha512.c:164:10: note: referencing argument 1 of type 'uint8_t *' {aka 'unsigned char *'}/home/pmos/build/src/android-tools-31.0.0p1/vendor/boringssl/crypto/fipsmodule/sha/sha512.c:234:5: note: in a call to function 'SHA512_Final' 234 | int SHA512_Final(uint8_t out[SHA512_DIGEST_LENGTH], SHA512_CTX *sha) { | ^~~~~~~~~~~~cc1: all warnings being treated as errorsmake[2]: *** [vendor/boringssl/crypto/fipsmodule/CMakeFiles/fipsmodule.dir/build.make:256: vendor/boringssl/crypto/fipsmodule/CMakeFiles/fipsmodule.dir/bcm.c.o] Error 1make[1]: *** [CMakeFiles/Makefile2:1292: vendor/boringssl/crypto/fipsmodule/CMakeFiles/fipsmodule.dir/all] Error 2make: *** [Makefile:156: all] Error 2
[23:49:02] ERROR: Command failed (exit code 1): (native) % cd /home/pmos/build; busybox su pmos -c CARCH=x86_64 SUDO_APK='abuild-apk --no-progress' HOME=/home/pmos abuild -D postmarketOS -d[23:49:02] See also: <https://postmarketos.org/troubleshooting>Run 'pmbootstrap log' for details.