Courtesy of my employer, Endless (we’re hiring), I’m at the GTK+ hackfest in Brussels, which is acting as my warm up for FOSDEM 2018. I’m representing the assorted GLib maintainers, aiming to look at the roadmap for GLib 2.58, and what we need to do to finish off GLib 2.56. If you’ve got suggestions for new features or changes to GLib, get in touch or file a bug!
Inspired by others, I thought doing a retrospective on 2017 would be an interesting thing to look back on in a year’s time and see what’s changed.
December 2017 marked a year of me working for Endless. It’s been twelve months of fixing small bugs, maintaining some OS components, poking my nose into lower parts of the OS than I’m used to, and taking on one or two big projects. I spent a significant amount of time on a project to add new distribution features to libostree and flatpak. That’s something which will hopefully be rolling out in early 2018. It was good to be able to get fairly deeply involved with a new component at a lower level in the stack. More of that in 2018!
I also spent some of my time in 2017 picking up a bit more of the GLib maintenance workload. I’m not sure how much of a difference it’s made to the bug backlog, but it’s kept me occupied anyway.
For most of my working life, I’ve had the luxury of being able to work on FOSS software (mostly in the GNOME ecosystem) as my day job, and as a result, quite a few of my hobby projects are actually maintained during the day. The ones which aren’t have suffered during 2017, because time and energy are limited. I’ve been thinking of ways to ensure that code gets maintained, but haven’t come up with any good solutions in 2017. That’s one to carry over into 2018.
2017 was a bit less of a plane-heavy year than 2016, but some trips still happened:
- FOSDEM, catching up with old friends and colleagues, and where the start of the current phase of GLib maintenance started.
- A week of caving in South Wales, including a trip down the fantastic Dan-yr-Ogof cave (the short round), which included floating down an underground canal on an inflatable swimming pool ring.
- A week of walking in the Glencoe area, where the weather was uncharacteristically cooperative, and the views were, predictably, pretty good.
- A party in London to celebrate Endless’ 5th birthday. As always, it was good to spend quality time with my Endless colleagues in endless pubs.
- Two weeks of caving in Austria, finding some new cave, and exploring further into existing cave. This is something I’m hoping to repeat in future.
- GUADEC in Manchester, right on the back of the Austria trip (including some fun in posting a laptop to myself so I could have it at the conference). I gave a talk, which some people listened to. We also went on a walk in the Peak District, which was good fun (even if the weather was a bit grey).
- Two weeks of long-distance trekking in the Svaneti region of Georgia. An excellent destination, with excellent cheese bread. We derived continual amusement from the guide’s dry humour, and the ‘helpful’ comments left by others on the trek information we were using. I did not get struck by lightning.
- A long weekend in Stockholm to explore the city and catch up with friends. Stockholm has good running!
2017 has definitely been a year of taking advantage of living in the north of England.
- Around 40 caving trips on weeknights and weekends, which have been interesting and (mostly) fun.
- 12 fell races, a fun run along with a friend for part of their Bob Graham round, and my first ultra.
- Running really took off for me: around 1300km run in total (and 57km of ascent), and about 150 hours of 2017 spent running.
Reading and listening
Gigs were a bit thin on the ground: despite there being plenty on in my local area, I always had something else to do. Despite that:
- Insomnium were good, though I had to leave before the end because of trains.
- Breabach were very good, and a band I hadn’t heard before going to the gig. Now a favourite.
- Kreator sounded uncannily like their last live album, but were otherwise enjoyable.
- Opeth were pretty fantastic, playing a good variety of new and old stuff.
I managed to read only 13 books in 2017, though that number is largely padded out by some short stories I read just to reach my yearly target. That’s not quite fair, though; I read 3250 pages in total. Most recommenable: Where Late the Sweet Birds Sang; most disappointing: Hiroshima.
Inspired by the talk at FOSDEM, I’ve just enabled GitLab’s continuous integration (CI) for building
make distcheck for Walbottle, and it was delightfully easy. The results are on Walbottle’s GitLab page.
- Create a
cibranch to contain the mess you’ll make while iterating over the correct compile steps.
- Create and push a
.gitlab-ci.ymlfile containing build rules similar to the following:
image: debian:unstable before_script: - apt update -qq - apt install -y -qq build-essential autoconf automake pkg-config libtool m4 autoconf-archive gtk-doc-tools libxml2-utils gobject-introspection libgirepository1.0-dev libglib2.0-dev libjson-glib-dev stages: - build # FIXME: Re-enable valgrind once running the tests under it doesn’t take forever (it causes timeouts). # Re-add valgrind to apt-install line above build-distcheck: stage: build script: - mkdir build - cd build - ../autogen.sh --disable-valgrind - make V=1 VERBOSE=1 - DISTCHECK_CONFIGURE_FLAGS=--disable-valgrind make distcheck V=1 VERBOSE=1 # The files which are to be made available in GitLab artifacts: paths: - build/*
- Iterate a few times until you get all the dependencies right.
- Fix any problems you find (because this might well find problems with your dependency declaration in
configure.ac, or other
distcheckproblems in your project).
masterand profit from CI results on every branch and master commit.
Looking at the
For information on the overall layout of the YAML file, and the phases available, you’re best off looking at the comprehensive GitLab documentation. Here are some notes about the autotools-and-C–specific bits of it:
imageis a Docker image; I picked a Debian one from the Docker hub.
- Package installation seems to need to be done in the
before_scriptphase, or the packages can’t be found (which is presumably a protection against rogue build systems).
- I chose to build
distcheckin my build rule because that runs the build, runs the tests, and tries various
builddirconfigurations. You can add other build targets (like
build-distcheckto try other build setups).
V=1 VERBOSE=1to get verbose build and test log output in your CI build logs, otherwise you will struggle to work out what is causing any failures.
- Note that
configureflags passed to
./configureare not automatically passed in again when
./configureis run as part of
distcheck— so use
DISTCHECK_CONFIGURE_FLAGSfor that. Ideally, your project will be less fragile than mine, and hence not need any of this.
- Export the whole
builddirectory as an artifact on success, so you can look at any of the build objects, or the generated tarball, or documentation. You could limit this (for example, to just the tarball) if you’re sure you’ll never need the rest of it.
I’m going to FOSDEM 2017!
I’ll have a spare, unopened, Nitrokey Pro with me to give to anyone who’s got a good plan for improving the user experience for them in GNOME. That might mean making the setup seamless; it might mean working on the rewrite of Seahorse; it might mean integrating them with LUKS; or something else. Contact me if you’re interested and have a plan.
By this time tomorrow, the 2016 edition of the GNOME developer experience hackfest will have started. This year, it’s in Brussels, kindly hosted by betacowork and ICAB.
We will be spending 3 days looking at a variety of things on the agenda to improve the lives of developers on GNOME, and make plans for the rest of the year. Watch out for updates on planet.gnome.org.
Collabora is sponsoring snacks throughout, and is sending 5 of us along for the hackfest. Thank you also to the other companies who are sending or letting people come — I know of Red Hat, Endless Mobile, Codethink and Canonical (please let me know if I’ve forgotten anyone!).
See people at FOSDEM afterwards?