This is my report for the third week of Gentoo GSoC.
In my proposal it says this week will be dedicated to getting Plasma desktop and core functionality working, but it already seems to run just fine by fixing the dependencies, which was done in week 1 & 2. The topics I’ve learnt about this week has instead been more ebuild development, Rust on musl, low level DBUS C api, GLib, setting up LDAP, Linux namespaces, and some other things.
Generally speaking the first two weeks was moslty me spamming out pretty easy to fix build time patches while this week’s been moslty learning and taking my time to resolve harder ones.
To start off with I made some ebuilds for the KDE MauiKit applications. This was mostly used for me to get more comfortable with ebuild development, but I also because I kind of like the simple style of them. I’ve also been thinking about getting a PinePhone to run Gentoo musl mobile, and the MauiKit applications would be perfect for that. I have not yet published anything here though.
The second thing I’ve learnt this week is tatt. I used it for testing my libkgapi fixes before pushing to ::gentoo, I’ll use this tool going forward since it’s very nice. Another fix from last week worth commenting on is librsvg. After searching on the internet for similar issues to librsvg (building as user & installing as root segfaults) I found out that weird behaviour can come from upstream Rust not handling dynamic linking with musl and that distros usually have downstream patches for it. I was sure that I had already tried rust::musl but after double checking that was it! This issue comes from librsvg getting statically linked with musl and other dependencies, in this case libgio, being dynamically linked with musl. Libgio which is dynamically linked won’t find the symbol and jump to address 0 which is exactly what is happening when debugging with GDB. Using upstream (::gentoo) Rust with RUSTFLAGS=”-C target-feature=-crt-static” fixes this issue as well.
The most time consuming task this week has been properly fixing accountsservice. It’s a daemon that exposes dbus apis for enumerating users on the system. The issue with this was found by fgetspent_r not being defined in musl, but the real issue was that they enumerated /etc/shadow to find out users on the system. My proposed patch is to use getpwent to enumerate the passwd database (can be /etc/passwd, NIS, LDAP …) and then use getspnam to find the corresponding shadow database entry. By itself it that isn’t so hard, but getting everything to play nice with the rest of AS is a little harder. I’ve created a working test application, but doing that I needed to learn using GLib, DBus apis, and enumerating users. To test this I wanted to use LDAP just to try if it worked there too but I got a little stuck on setting up LDAP the server + NSS in a VM and I’ll continue with it next week.
I’ve also made a few small fixes to lvm2, Bubblewrap, spice-gtk and monero (::guru). I’ve talked with @Matthews about adding Monero to ::gentoo but the issue here is with bundling/vendoring dependencies. In accordance to Gentoo guidelines **thou shall not** vendor dependencies, but for crypto it’s very important to have the exact same behaviour so you don’t cause a hard fork of the network. Figuring out what can be unbundled and what should stay vendored + some other fixes are needed before getting to ::gentoo, after that I could get to proxy-maintain it.
To summarize this report I’ll say that I’ve learnt a lot this week, but because of that I also pushed out fewer patches than usual. Next week I’ll continue with accountsservice and more things related to core Qt/KDE/Plasma, also work on passing test suites. After that I’ll continue on with QtWebEngine, which seems like a monster to get upstreamed just looking at all bug reports and old patches.
I have also been re-thinking how to do the blog posts. In my opinion it would be better to blog about separate topics and summarize it in the weekly report, instead of just publishing a beefier version of it weekly. Thoughts?