Contributed by Peter N. M. Hansteen on from the packaged frogs dept.
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!
(Comments are closed)
By Edward Ahlsen-Girard (Ed) eagirard@cox.net on
Firefox speed is much improved. Many thanks.
Comments
By Anonymous Coward (79.113.102.13) on
Try Chromium for speed!