p2k17 Hackathon report: Antoine Jacoutot on ports+packages progress

Another p2k17 hackathon report is just in, from Antoine Jacoutot (ajacoutot@), who writes:

TL;DR
Nothing fancy, just ports work, but my first time in Berlin was a blast!

It's been a while since I attended a ports hackathon where I ended up
exclusively working on ports, and P2K17 was one of them.

A couple of weeks before attending I started updating the base GNOME libraries (GLib, GTK+, etc.) in preparation for the upcoming GNOME 3.26.2 update that jasper@ and I planned on working during the week. I often do that to save us time and allow us to work on other things than GNOME…

Well this time it didn't go as planned.

First batch of updates were pretty straight forward but we got stuck on
devel/spidermonkey52 (the C/C++ Mozilla's JavaScript engine implementation)
which is a requirement for x11/gnome/gjs and subsequently gnome-shell. The
javascript console would basically hang and put the cpu in an infinite loop.

After some digging, I found a patch in Fedora that fixed that particular issue
(Disable MOZ_GLUE_IN_PROGRAM in stand-alone builds on all platforms). I didn't
spot it right away because the original commit message was not very informative.

Anyway, thank you Fedora on that one!

Another time consuming task required for the GNOME update was devel/meson. The
GNOME project is slowly changing build system from autotools to meson. Meson
looks a bit like cmake but has a much friendlier and easier user interface.

Under the hood it uses ninja so parallel builds work very reliably.
While it works out-of-the-box on OpenBSD, it does not follow our shared
libraries naming scheme. On Linux, shared libraries are often provided as a symlink trail:

libfoo.so -> libfoo.so.1 -> libfoo.so.1.0.0

On OpenBSD, we version our libraries using the X.Y format (i.e. libfoo.so.1.0).
Not a huge deal to teach meson about our needs but I did not want to change the
default behavior so I ended up implementing our scheme only if we provide a
corresponding LIBfoo_VERSION environment variable, which we do in our ports
tree. While here I also added support for writing a shared_libs.log file in the
build directory like our libtool(1) implementation does. It's useful to compare
upstream solib version against ours. Yes, on OpenBSD we are in control of the
versioning.

Once that was done, I extended the meson and gnome ports modules to bring a bit
more automation in the way things are built. For example, we explicitly add LDFLAGS to g-ir-scanner(1) (C metadata sources and headers extraction tool for
gobject-introspection) because while it uses pkg-config(1) to get its flags, it
only appends -L/-l and not the extra ones like -Wl,wxneeded which may be
required by some ports (typically when using WebKitGTK introspection).

Finishing the work on meson, I realized that there were a lot of patches and
workarounds for our lack of python2 and python3 links. Historically we only
installed python as pythonX.Y (e.g. python2.7). This gives users the choice of
defining their default python binary (by linking it to the proper versioned
one). While it was understandable for /path/to/bin/python, a lot of upstream
projects stopped hardcoding their shebang since python3 came out and use env
which is more portable (i.e. #!/usr/bin/env python2). So I modified our python
ports to install the proper symlinks and we will be able to drop several patches
and MODPY_ADJ_FILES from the tree.

After that I went on doing some ports housekeeping: updated quite a lot, fixed a
few, imported a batch and removed a couple. I worked around a build failure in
gnumeric on the i386 architecture by skipping the generation of one of the
translations (I was too lazy to figure out the root cause). I sub-packaged and
added a bootstrap FLAVOR to lang/vala to prevent a dependency loop when building
vala and valadoc: lang/vala -> math/graphviz -> x11/gnome/librsvg -> lang/vala.

At last, I changed the cupsd rc.d(8) script to fix the ownership of the
/etc/printcap -> /etc/cups/printcap symlink to please security(8).

During the entire week, I ran continuous ports bulk builds to catch any failure
introduced by the hackathon ports rampage. Thanks to Exoscale
(https://www.exoscale.ch/) donating 8 peachy VMs, I can run a complete bulk in
about 11.5 hours. Status, packages and logs are always available at:
http://exopi.bsdfrog.org/

As usual I really enjoyed chatting with fellow hackers about the horrible
ecosystem we live in. Thanks to everyone involved in making this event an
awesome experience, Berlin is a must-see!