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.