Hello!

In the last two days I’ve spent my time getting Gentoo musl to run on my PinePhone Pro. I asked Sam if I could spend a few days on it as a side project and it was fine.

I installed it using postmarketOS as a “livecd” and did the usual chroot-based install. I’ve made some ebuilds for mauikit apps, as well as Plasma mobile. They work but I really need to fix things like DEPENDS-array, add appropriate USE-flags, etc, before pushing somewhere.

It was definitely not painless and I had to debug some runtime issues, like the mauikit media player Clip not playing any media files. This was because of gstreamer plugins and qtmultimedia needing +gstreamer. I still wonder if it’s a good idea to just depend on gst-plugins-meta and let users enable their wanted codecs by changing USE on that? I also had some issues with the bootloader and some other things but all-in-all I’ve learnt a lot and enjoyed it! (unlike the Konsole zsh test failure :D)

I’ll continue with it tomorrow and probably a bit on thursday. In my schedule I had taken two weeks for fixing various KDE applications but they mostly seem to “just work”, but later this week and next I’ll run test suites to ensure that applications properly work.

Today worked on some different things. The first one was making another libexecinfo based on libunwind. The issue was that the current libexecinfo (resslinux/libexecinfo on github) sometimes segfaults. For me it segfaulted when emerging Emacs because temacs (Emacs bootstrap) used it, and I think it backtraced too far (into libc). After reading some GitHub issues/ML posts it seemed like everyone recommended libunwind instead, and there were some issues with libexecinfo due to __builtin_frame_address. Because the execinfo interface is so simple: basically one function that returns a list of pointers to previous function calls, and two other functions that retrieves the symbol names for these addresses, I thought it would be neat to just use libunwind for the backtrace()-function (the one that returns list of ptrs) and then just copy paste the symbol lookup funcs. I tried it and it “just works” without the __builtin_* hackery! The current version is improved over libexecinfo in 4 ways:

1. Uses meson so that a .pc file gets generated automatically.
2. Doesn’t generate source files with a Python script (https://github.com/resslinux/libexecinfo/blob/master/gen.py).
3.  Doesn’t segfault (yay).
4. Includes various fixes for backtrace_symbols https://git.alpinelinux.org/aports/tree/main/libexecinfo/10-execinfo.patch.

ebuild: https://github.com/alfredfo/catcream_repo/blob/master/sys-libs/libexecinfo/libexecinfo-1.0.0.ebuild
source: https://github.com/alfredfo/libexecinfo-unw

see: https://github.com/mikroskeem/libexecinfo/issues/2, https://www.openwall.com/lists/musl/2019/08/22/2.

I’ve also learnt how to set up clean musl build systems with ebuildtester.
Example: ebuildtester --portage-dir /home/cat/gentoo --atom sys-process/htop --docker-image gentoo/stage3:musl
Spent some time with Docker images before I realized that there was already a gentoo/stage3:musl image ready.

I have continued to research the Konsole test thing from monday. The TerminalInterfaceTest only fails when using zsh and ebuild konsole-ver.ebuild test (not executing test manually). I still don’t know really what causes it but when using bash it works.

currentDirectory = QStringLiteral("/tmp");
terminal->sendInput(QStringLiteral("cd") + currentDirectory + QLatin1Char('\n')); <- THIS
stateSpy.wait(2000);
QCOMPARE(stateSpy.count(), 1);

This code fails, but changing it to
currentDirectory = QStringLiteral("/tmp");
terminal->sendInput(QStringLiteral("\ncd") + currentDirectory + QLatin1Char('\n'));
stateSpy.wait(2000);
QCOMPARE(stateSpy.count(), 1);
or
currentDirectory = QStringLiteral("/tmp");
terminal->sendInput(QStringLiteral(";cd") + currentDirectory + QLatin1Char('\n'));
stateSpy.wait(2000);
QCOMPARE(stateSpy.count(), 1);

works just fine. Really weird! It acts like there’s some garbage text inputted at the start.

I also never posted anything yesterday because I was up really late working on gsoc and just went to sleep :). Yesterday I messed around with Emacs to figure out the libexecinfo bug and I also looked into how to use libunwind, which got me the idea to implement libexecinfo using it. I also spent some time with the Konsole test thing.

The first thing I did today was fixing my accountsservice patch, I used #ifndef on a function and it caused the package to not be buildable on glibc since #ifdef-checking only applies to macros, so the check was skipped causing fgetspent_r to be redefined and that caused an error. Accountsservice still needs a rewrite, since the program itself enumerates /etc/shadow which is wrong, but at the moment this fix is fine. Worth noting is that I also set up a glibc chroot to test building accountsservice, and I’ll continue testing patches on it going forward so I don’t make similar mistakes.

I also learned that you can run ebuild *.ebuild [args…] as a user to make your local user owner of WORKDIR. I’ve always ran it as root and had perm issues even though I was in portage group and was stuck wondering what I could do instead of chown:ing.

I then started with QtWebEngine, and spent the rest of the day fixing that. It’s a huge project with bundled libs inside bundled libs and properly upstreaming will be very hard. For example the bundled Chromium is at version 87, while the newest release is ~103.

Just to show, here’s one of the first issues I came across:
qtwebengine-5.15.5_p20220618/src/3rdparty/chromium/base/third_party/libevent/event.c:42:10: fatal error: sys/queue.h: No such file or directory
Fixing it is pretty easy, either rewrite the code that uses sys/queue.h, or attach a compatibility header (ugly). However, upstreaming this so it gets into QtWebEngine would be a nightmare. First get it into libevent. After that we need to get Chromium to use the newer libevent, and then finally wait for Qt to use the new Chromium release.

For QtWebEngine I’ll try to just get it to build at first, and then see what patches make sense to send upstream and what can go into KDE’s Qt5PatchCollection. Because QMake is being phased out for CMake it doesn’t really make sense spending a lot of time upstreaming and polishing build system patches, therefore that can instead go to Qt5PatchCollection or ::gentoo if appropriate.