Daily blog 4 aug by Catcream

Today I’ve been working some more on my PinePhone and I’m basically done.

An issue I ran into was the phone not booting when I compiled a custom kernel. It has no display output, but apparently you can use the headphone jack to connect via serial. So I took apart a 3.5mm audio cable and tested if each wire corresponded to its own connector “part” using a multimeter. It did, so I then soldered my serial to usb adapter onto the 3.5mm cable and I got serial output. However when connecting TX so I could send input to the device all the output got messed up and I have no idea why. I debugged it for quite a long time and also asked in #pinephone IRC but ultimately I gave up, didn’t need input right now anyways.

Looking at the boot output I saw that the kernel crashed and complained about not having EFI stub enabled. Enabling it and creating an initramfs with dracut solved it. Now it boots just fine!

I’ve emerged a bunch of packages and very soon I should have a fully working device, hopefully done by tomorrow. I’ll also PR my mauikit ebuilds to ::kde tomorrow.

PS. Now all my devices run Gentoo musl: desktop, laptop, server, router, and phone, woohoo!

Posted in musl KDE | Leave a comment

Daily blog 3 aug by Catcream


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.

Posted in Uncategorized | Leave a comment

Week 7 Report for RISC-V Support for Gentoo Prefix

Hello all, hope everyone is doing good.

This is my report for the seventh week of my GSoC project. This week we submitted mit-term evaluations and received feedbacks from mentors. I have also done some testing and documentation this week.

This week I worked on documentation of “Porting Prefix to new Architecture” and I tested all packages in `app-portage` for RISC-V. Also the pull request [1] has been merged.
Here is the list of packages:

* app-portage/diffmask
* app-portage/unsymlink-lib
* app-eselect/eselect-package-manager
* app-portage/repo-commit
* app-portage/portpeek
* app-portage/porticron
* app-portage/overlint
* app-portage/metagen
* app-portage/gverify
* app-portage/distpatch
* dev-util/diffball
* app-portage/emerge-delta-webrsync
* app-portage/g-octave
* app-portage/fetchcommandwrapper
* app-python/sexpdata
* app-python/epkg
* app-python/gander


Talking about the evaluations, I have passed the mid-term evaluations. The feedback stated that all main objectives have been accomplished already, and the second half will be spent on stretch goals of the proposal.

Talking about the delieverables, they are almost completed and we are left with testing and documentation. So I will be spending rest of the weeks doing these and adding features, if any.

[1] https://github.com/gentoo/gentoo/pull/26679


Posted in RISC-V Prefix | Leave a comment

Gentoo musl Support Expansion for Qt/KDE Week 7

This week has mostly been spent on testing applications and some further fixes to QtWebEngine.

QtWebEngine is now PR:ed to ::gentoo and I’m waiting for comments. It seems to work just fine and all tests for Qutebrowser pass! (https://github.com/gentoo/gentoo/pull/26611). Another thing that has taken a lot of time this week is getting the TerminalInterfaceTest to run on Konsole. I also ran into an issue compiling Emacs, I found out it was because of libexecinfo and I decided to reimplement glibc’s execinfo using libunwind because it’s such a simple interface. It also avoids me using the error prone __builtin_* stuff.

My weekly schedule says that all core apps like Ark, Dolphin and Konsole should pass tests, and except for Konsole and a RAR issue with Ark they do! The RAR issue is because app-arch/rar downloads a binary that depends on glibc.
Continue reading

Posted in musl KDE, RISC-V Prefix, Uncategorized | Leave a comment

Daily blog july 28 by Catcream

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
QCOMPARE(stateSpy.count(), 1);

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

currentDirectory = QStringLiteral("/tmp");
terminal->sendInput(QStringLiteral(";cd") + currentDirectory + QLatin1Char('\n'));
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.

Posted in Uncategorized | Leave a comment

Daily blog july 26 by Catcream

Today I’ve done pretty much the exact same thing as yesterday. I continued to fix some things with QtWebEngine and sent a PR to ::gentoo (yay!). I also tested a few more applications on my laptop but got really stuck on a Konsole test. It fails when using zsh, but not other shells. It executes “cd /tmpdir \n” and checks for state. Just figuring out it was a shell issue was pretty hard and required us to dig up ~8 year old KDE bugs. I’ll hopefully figure it out tomorrow.

I also have some mariadb tests failing which I’ll look back to as well.

Posted in musl KDE | Leave a comment

Daily blog july 25 by Catcream

Today I’ve filled in the midterm evaluation and continued to work on QtWebEngine to make it ::gentoo-ready. I’m pretty happy with most of the patches and I only need someone to look through them. I’ve also tested some core KDE applications.

Konsole passed all tests except TerminalInterfaceTest.

17/18 Test #16: TerminalInterfaceTest ............***Failed    2.20 sec

Looking at the test log we can see:

16/18 Testing: TerminalInterfaceTest
16/18 Test: TerminalInterfaceTest
Command: "/var/tmp/portage/kde-apps/konsole-22.04.3/work/konsole-22.04.3_build/bin/TerminalInterfaceTest"
FAIL! : Konsole::TerminalInterfaceTest::testTerminalInterface() Compared values are not the same
Actual (stateSpy.count()): 0
Expected (1) : 1

But when running bin/TerminalInterfaceTest in a normal shell manually it passes?

Another package I tested was kde-apps/ark. If using tests it depends on app-arch/rar, which in turn depends on glibc because it’s distributed as a binary. To work around this I just removed the dep in ark’s ebuild and ran the tests, and it passed everything :). Other notable applications that have passed test suites are Dolphin and Qutebrowser (QtWebEngine browser).

Tomorrow I’ll continue testing packages and see if I can find a more efficient way of testing a whole group of packages like kde-apps.

Posted in musl KDE | Leave a comment

Week 6 Report for RISC-V Support for Gentoo Prefix

Hello All!

Hope everyone is doing good, this is my report for the sixth week of Gentoo GSoC.
After having a working prefix this week I dedicated on testing packages on prefix for EESSI package set. I also sent quite some time setting up package testing environment on prefix. Also I learned more about Arch testing on Gentoo. I collected all the required packages [1] and then tested them with `FEATURES=”true”` and `tatt` .
A lot of packages had already been tested and had RISC-V keyword. I have tested the following packages in gentoo repository [2] and [3] and pull requests have been merged as well:
– dev-util/hermes
– sys-cluster/lmod
– dev-util/patchelf
– dev-lua/luajson
– dev-lua/lua-bit32
– dev-lua/luaposix
Tests were failing for `lmod-8.6.14`, with `lmod-8.5.6` tests passed successfully so only that has been keyworded.
As most of the packages from EESSI overlay have been moved to gentoo repository, there are only major ones left in the overlay.Following patches were added in EESSI overlay:
– sys-cluster/reframe [4]
– sys-apps/archspec [5]
There are `sys-fabric/opa-psm2` isnt needed for RISC-V yet so it has been skipped. There is also `sys-libs/pam` in the overlay to add pam support to prefix but it wont be further required [7] as I had added a patch in official repository [6].
The `sys-cluster/reframe` had a lot of dependencies while testing but all tests passed successfully. The `sys-apps/archspec` is no more usable as it depends on `<dev-python/click-8.0` and we have `dev-python/click-8.1.3` in official repository. So it is being decided whether to bump the version or to use the latest click version, it will be merged soon.
All the packages except `sys-apps/archspec` have been keyworded and merged. We can soon test RISC-V for EESSI project. Also all the delieverables are complete, although some work on documentation needs to be done so I will focus more on keywording and documentation.
Mentors also coordinated a lot and helped me with EESSI packages and testing. To summarize the report, this week was spend on learning more about testing and keywording packages for EESSI.


Posted in RISC-V Prefix | Leave a comment

Gentoo musl Support Expansion for Qt/KDE Week 6


This week has been mostly dedicated to QtWebEngine, a package that bundles Chromium, which in turn bundles a bunch of libraries (:D). It took a lot longer than I initially thought while planning GSoC, but nonetheless I finished all my weekly goals. Those being (1) get most of my previous work upstreamed & (2) get qutebrowser running fine. I’ve been writing daily blogs up until Thursday, since it would just be: “yesterday I did $thing, today I also did $thing… aaand tomorrow I’ll continue with $thing”. But I’ll continue with them next week. Continue reading

Posted in musl KDE | Leave a comment

Daily blog july 18 by Catcream

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.

Posted in Uncategorized | Leave a comment