g2k18 hackathon report: Antoine Jacoutot on porting

Before winning the football world cup, the french were writing their hackathon reports. Here's the one from Antoine Jacoutot (ajacoutot@):

g2k18 was my third General Hackathon in Ljubljana, Slovenia. I love it there, it's a great place to host such an event: perfect location (city center), beautiful city, cheap yet very nice food etc.

My goal for the week was to remove a few items from my overgrowing TODO list.

First item was to find a way to update librsvg to the latest stable version. I refrained from doing it in the past because since version 2.42.0 it requires rust to build which we only support on amd64, arm64 and i386. But something needed to be done because it's a graphical library and bugs are not uncommon nor without consequences in this area. So, how should we handle a different librsvg library depending on the architecture? After a few chats over the last few weeks with naddy@, sthen@, espie@, jasper@, landry@ and robert@, 3 proposals were on the table:

• Create a librsvg MODULE that would build and install the appropriate version. I wasn't too keen about it because it would mean having to deal with things like MODRSVG_WANTLIB in dependent subpackages. It would also require a big revamp of the port with bumps and LIB_DEPENDS changes all over the ports tree.
• Create a librsvg meta-package which would only build and install the proper version based on the architecture. That would have worked as well but had more or less the same drawbacks as using a MODULE.
• Patch the existing port with "if" conditionals based on the architecture. That's the solution I choose to go with. It's the simplest (doesn't need surgery in the tree) and we can get away with WANTLIB handling for now since both versions use exactly the same set. If that changes in the future, we will iterate and see…

Anyway, of I was building the new rust-based release when it failed pretty quick because it required a snapshot version of graphics/cairo. After reading the Cairo mailing lists, it seemed that 1.16.0 was around the corner (which in all honesty may mean months…). Once again, a Desktop core library depends on some development code… gotta love the FLOSS ecosystem. Oh well, the new Cairo does bring a share amount of bug fixes and performances improvements, so let's go with it.

Back to building librsvg. *Boom!* Another problem arose: the build broke because of multiple definitions like:

librsvg-2.42.5/librsvg-2.42.5/target/release/librsvg_internals.a(moddi3.o): In function `__moddi3':
/usr/src/lib/libcompiler_rt/moddi3.c:21: multiple definition of `__moddi3'

I immediately called semarie (our rust maintainer) for help and he came up with a fix for it: he changed the way libcompiler_rt.a was included by rustc in order to avoid duplicated symbols in a .a library (some symbols from system libcompiler_rt.a, others from Rust itself). Thank you, it builds let's ship it!

Putting the new Cairo and librsvg ports in a bulk didn't yeld to any build issue and my big GNOME environment still worked fine with it. Since it was a hackathon, "commit early, commit often", one… two… three, it's in the tree \o/

My second item was to remove dependencies against the old and unmaintained www/webkit package. Why? Because this:

$ pkg_info webkit | grep -A2 'Install notice'  
Install notice:
!!! WARNING: WebKitGTK+ 2.4 is known to have many security vulnerabilities that
!!! will NOT be fixed. Avoid browsing with it.

sqlports told me only 2 ports were requiring it: cad/xtrkcad and productivity/gnucash (huh oh, I do maintain that one). So I went ahead and updated gnucash because their latest release is now using the supported webkitgtk4 library. Should be a straightforward update with only a couple of patches needed (make sure to pickup guile2 over guile1, cope with our lack of strfmon implementation…). But it blew in the middle of the build with C++ errors which no human could understand. Luckily there was a nonhuman C++ connoisseur in the room: Dr Espie! He quickly told me that the issue was due to a mismatch definition between gint64 and int64_t. gint64 is a GLib type that represents a signed integer guaranteed to be 64 bits on all platforms. In a word, gint64 == int64_t. So I went ahead and looked at our GLib header to discover that our gint64 was as follow:

typedef signed long gint64;

OHNOES! No wonder it blows! On OpenBSD, int64_t is always "signed long long" whatever the architecture. "signed long" is 64-bit on our 64-bit architectures and the problem is that GLib configure script check will match ac_cv_sizeof_long and we'll end up with this bogus definition. 32-bit architectures a not impacted obviously. Patching the configure script and adding an exception for OpenBSD fixed it. That's however not the proper way to get operating system types in the first place from GLib, but one battle at a time.

The last item was updating meson(1) to the latest release. Building is easy since it's just python code to package. I run into a bug at run-time though, it seemed that meson preferred static libs over shared ones (and that was definitely a regression from previous versions). It turned out to be a bug in the way shared libraries were looked for, there was no support for OpenBSD X.Y versioning. Upstream was very responsive on the issue and fixed it in less than a day. They asked me whether I could setup a CI pipeline for OpenBSD to detect such regressions in the future and as soon as I can find time on my plate, I'll do just that.

The rest of the week was mostly spent talking to fellow developers (still pondering when should syspatch display a "please reboot" message) and updating a few ports here and there. guile2 is now following Linux versioning for its tools so that we don't need to patch dependent ports; polkit was updated to its latest release to fix CVE-2018-1116; our hashicorp packages are now fully up-to-date (consul, packer, vault, terraform etc.). At last I ported chrome-gnome-shell which allows chromium to interact with https://extensions.gnome.org/ to add/remove gnome-shell extensions directly from the browser.

As usual I would like to thank the OpenBSD Foundation (and its generous donors) and Mitja for organizing such a great hackathon.

Thanks to Antoine for writing up his experience (and for all the work he put in over this hackathon, of course!).