Neil Hopcroft

A digital misfit

Platform updates causing build errors

Recently there was a significant number of package updates following a kernel update for the AWS instance I’m using. This has caused a number of build errors, which I think are the result of permissions reverting back to default rather than those I’ve changed to allow the build process to install files too – of course this isn’t the right solution, I should put the build user into a group allowed to make those changes by default, but that would require a bit more thinking about permissions than I can bring to bear at the moment. In the meantime, here are the projects affected by this problem:

  • alabaster
  • ffc
  • fiat
  • instant
  • snowball
  • sphinx_rtd_theme
  • ufl

I have updated the site-packages permissions and rebuilt all of these packages, which has resolved all of these problems.


Dabbling with github and build automation

Github provides an API to search for repositories – this can be used directly from wget. As an experiment I have set up a simple script that gets the 30 most recently updated projects on github, clones them to a local directory, examines the code received, classifies it by build mechanism and, for some mechanisms, attempts to build it.
Here are the build mechanisms I have found:

  • Python setup.py
  • Dockerfile
  • bootstrap.sh
  • configure
  • Makefile
  • Vagrantfile
  • build.gradle
  • Gruntfile.js
  • gulpfile.js
  • package.json
  • composer.json
  • custom script based on project name
  • Cartfile
  • Rakefile

There are, I’m sure, more active build mechanisms and I will add those when I encounter them. From my experiments so far the above list covers about 90% of the currently active projects. Notably missing from the list are some of the Java build systems, like ant and maven, which suggests there might be other places for projects using those to live.


Adding Osmosis build

To get the event finder build back up to date I need to bring the version of Osmosis it uses up to the latest version. To do this I have added an Osmosis project to the Jenkins CI server. This is a Gradle build publishing to an Artifactory server, requiring installation of the Artifactory plugin to Jenkins.
An initial attempt to make this build gives me this error:

Execution failed for task ‘:artifactoryPublish’.
File ‘/usr/share/tomcat7/.jenkins/workspace/osmosis/osmosis-apidb/build/libs/osmosis-apidb-0.44.1-2-ge9b3ea5-SNAPSHOT.jar.asc’ does not exists, and need to be published!

This is a signature file, and is probably missing because task “:osmosis-apidb:signArchives SKIPPED”, as are all the other sign tasks – I haven’t configured the Gradle signing plugin yet. After a bit of messing around finding a version of gpg that wouldn’t complain when it came to entering the passphrase (cygwin to the rescue), installing and configuring the keys makes the build complete and publish the build result to Artifactory.


Setting up freetype

Harfbuzz needs the latest version of Freetype – I’ve added this to the CI build. This is again a standard ./autogen.sh ./configure make make install build.
Upgrading to the latest freetype fixes the harfbuzz build but breaks the octave build – fontconfig is still using the original freetype installed by yum, in /usr/ rather than the newly built one in /usr/local. Rebuilding fontconfig resolves this problem but causes the fltk build to fail. Setting fltk to look for the fontconfig.pc file in /usr/local/lib/pkgconfig resolves this.


Setting up HarfBuzz

I’ve added a CI build for HarfBuzz, this is a standard ./autogen.sh ./configure make make install sequence. It has dependency upon:

The build works from build 3 onward – set to poll daily.
However, the default build is missing Freetype support, required for pango. The config.log for harfbuzz says “Requested ‘freetype2 >= 12.0.6’ but version of FreeType 2 is 9.22.3”, so we need a newer version of freetype. I’ve added freetype to the CI build.


Build breaks during set up of of-* projects

While I’ve been messing around with the of-* projects there have been a number of projects suffering code rot.
ImageMagick has encountered a subversion server error, which seems like it is probably beyond my control.
Mesa broke in build 123 with a compilation error, then in 124 reported that it requires libdrm > 2.4.60, but libdrm should be in the CI build setup, so there’s a spurious pkgconfig file somewhere. Fixed in build 164.
obd android lost gradle – I think there was a path change that took it off the default path, setting the path to include gradle fixes build in build 41.
pango is reporting a build error following some changes to how it deals with HarfBuzz versioning. I’ve added HarfBuzz to the CI build.
qhull is hosted on gitorious, which has died and is now moving to archive.org, project disabled for the moment – I don’t see any updates to the project website to explain anything.


More fixing of-fem-fenics build

When we last left this build there was a link error on boost::mpi::communicator::operator ompi_communicator_t*() const, there is a mailing list discussion describing a similar problem on Sparc. That discussion hints at there being multiple mpi implementations and that boost has been linked against OpenMPI while the linker has found a different implementation first.
Building libboost_mpi (and, actually, all of boost) resolves this problem.
Fixed in build 91.


Fixing of-video

The of-video project gives “warning: package video is empty”. This project also has a bootstrap script which creates a configure script which creates a Makefile. Running ./configure gives “error: Octave-Forge video package requires libavformat from FFmpeg”. A quick check shows that ffmpeg is generating only static linkage libraries, adding –enabled-shared to the ffmpeg build, adding a dependency from of-video upon ffmpeg then rebuilding ffmpeg.
However, ffmpeg now fails with “/usr/bin/ld: libavutil/color_utils.o: relocation R_X86_64_32S against `.rodata’ can not be used when making a shared object; recompile with -fPIC”. Checking the build configuration I notice that the ffmpeg build is not cleaned – cleaning the build resolves this problem, although it seems like a change to such an option should force all code to be recompiled?
Now of-video is looking in libavcodec for av_malloc, but it looks like it has been moved to libavutil, adding a patch to the configure script to pass ‘-lavutil’ to test program allows ./configure to run to completion.
Next the compilation fails:

AVHandler.cc:125:42: error: ‘av_set_parameters’ was not declared in this scope
if (av_set_parameters(av_output, NULL) < 0) { ^ AVHandler.cc:135:53: error: ‘URL_WRONLY’ was not declared in this scope if (avio_open(&av_output->pb, filename.c_str(), URL_WRONLY) < 0) { ^

These two are deprecated in ffmpeg.
I have added patches:

  • AVHandler.cc: remove call to av_set_parameters()
  • AVHandler.cc: update URL_WRONLY to AVIO_FLAG_WRITE
  • oct-avifile.h: remove DECLARE_OCTAVE_ALLOCATOR
  • oct-avifile.cc: remove DEFINE_OCTAVE_ALLOCATOR

Fixed in build 36.


Fixing of-stk

The of-stk project is a bit unusual as octave packages go, since it is intended to be usable directly on Matlab too. I have encountered and addressed some of these problems before.
I have now brought the changes I made to the original octave-packages build for stk into the of-stk project. But I don’t think they do what we need – there is a Makefile in the project directory which looks like it makes packages, but it relies upon octave being in the path, which isn’t the case in this context. I have taken the instructions generated by the makefile and put them into the of-stk build script.
Fixed in build 21.


Fixing of-optiminterp

The of-optiminterp project gives this error:
*** mkoctfile lacks Fortran 90 support
Again, there is an autogen.sh script in the src/ directory. Running this before the build gets us a bit further, but now configure reports
config.status: error: cannot find input file: `Makeconf.in’
Copying Makeconf.in from of-audio allows configure to complete, but leads to a syntax error in Makeconf where there is an unexpected DEFHAVE_LINUX_SOUNDCARD, which isn’t relevant to this project. I have added a patch to remove this.
The build then fails with a message “*** mkoctfile lacks Fortran 90 support”. Looking at the Makefile, it needs MKOCTFILE_FORTRAN_90=yes otherwise it will give this message. But MKOCTFILE_FORTRAN_90 is not set anywhere, it should be in the Makeconf file, but, probably because I’m using Makeconf from of-audio, isn’t. Adding it to the end of the file allows the make to complete and the package to install.
Fixed in build 38