Neil Hopcroft

A digital misfit

Setting up the navit build

After installing the dbus-devel package, the navit build fails with this error:

In file included from /usr/share/tomcat7/.jenkins/workspace/navit/navit/binding/dbus/binding_dbus.c:22:0:
/usr/include/dbus-1.0/dbus/dbus.h:29:33: fatal error: dbus/dbus-arch-deps.h: No such file or directory
#include
^
compilation terminated.

Looking at the cmake/FindDBus.cmake file shows that it is checking in /usr/lib/include but not in /usr/lib64/include, where the dbus directory can be found. Adding another check to look in lib64 allows the build to continue.
Next to add some dependencies

  • libosso and liblocation are from the Maemo project, where there isn’t an awful lot going on, so I’m going to ignore those for the moment as I believe them to be no longer maintained
  • imlib2 is added as a project
  • libgarmin is added as a project

Segfault is oftests #24

Test stk_example_kb09 failed with a segfault. Looks like this might be related to a problem that has been discussed on the octave mailing list, although my symptoms are significantly worse than those described in that report. I’ll rerun the tests once the build machine is a bit more quiescent.
Following a further couple of builds, this appears to be resolved, or at least a random failure. I’ll not investigate any further.


Build break in of-video #234

There are some more FFMPEG errors in the of-video build, ironically they appear to be introduced by

Changeset 50:73e26dc9bd9a by Andreas Weber :
Fix compiler warnings, replace deprecated functions, bump version

…or maybe my previous changes were undone by this change.
Once again, this is some missing AV_ prefixes.
Fixed in build #244.


Fixing the mesa build

At long last I’ve gotten around to fixing the mesa build – there were a couple of problems:

nouveau_screen.c: In function ‘nouveau_init_screen2’:
nouveau_screen.c:105:2: error: implicit declaration of function ‘nouveau_drm_new’ [-Werror=implicit-function-declaration]
ret = nouveau_drm_new(dri_screen->fd, &screen->drm);
^
nouveau_screen.c:111:2: error: implicit declaration of function ‘nouveau_device_new’ [-Werror=implicit-function-declaration]
ret = nouveau_device_new(&screen->drm->client, NV_DEVICE,
^
nouveau_screen.c:111:39: error: dereferencing pointer to incomplete type
ret = nouveau_device_new(&screen->drm->client, NV_DEVICE,
^
nouveau_screen.c: In function ‘nouveau_destroy_screen’:
nouveau_screen.c:229:2: error: implicit declaration of function ‘nouveau_drm_del’ [-Werror=implicit-function-declaration]
nouveau_drm_del(&screen->drm);
^

I spent a little while tracking this down, it turns out that I had three sets of pkgconfig .pc files for drm nouveau, one in /usr/lib/pkgconfig, one in /usr/lib64/pkgconfig and one in /usr/local/lib64/pkgconfig – the version being built by Jenkins being the one in /usr/local/lib64 while the others represented versions installed by the package manager. Removing those from /usr/lib and /usr/lib64 got the build looking at the latest version. However the error remained unchanged.

Looking at the build log, I notice this from the configure output:

DRI platform: drm
DRI drivers: i915 i965 nouveau r200 radeon swrast
DRI driver dir: ${libdir}/dri
GLX: DRI-based

The error occurs during the compilation of the nouveau DRI driver, so setting “–with-dri-drivers=i915,i965,r200,radeon,swrast” on the configure command line removes the driver from the build.
This leaves me with

../../src/loader/.libs/libloader_dri3_helper.a(loader_dri3_helper.o): In function `dri3_wait_for_event’:
/usr/share/tomcat7/.jenkins/workspace/mesa/src/loader/loader_dri3_helper.c:280: undefined reference to `xcb_wait_for_special_event’
../../src/loader/.libs/libloader_dri3_helper.a(loader_dri3_helper.o): In function `dri3_find_back’:
/usr/share/tomcat7/.jenkins/workspace/mesa/src/loader/loader_dri3_helper.c:380: undefined reference to `xcb_wait_for_special_event’
../../src/loader/.libs/libloader_dri3_helper.a(loader_dri3_helper.o): In function `dri3_flush_present_events’:
/usr/share/tomcat7/.jenkins/workspace/mesa/src/loader/loader_dri3_helper.c:613: undefined reference to `xcb_poll_for_special_event’
../../src/loader/.libs/libloader_dri3_helper.a(loader_dri3_helper.o): In function `dri3_update_drawable’:
/usr/share/tomcat7/.jenkins/workspace/mesa/src/loader/loader_dri3_helper.c:986: undefined reference to `xcb_register_for_special_xge’
/usr/share/tomcat7/.jenkins/workspace/mesa/src/loader/loader_dri3_helper.c:1030: undefined reference to `xcb_unregister_for_special_event’
../../src/loader/.libs/libloader_dri3_helper.a(loader_dri3_helper.o): In function `loader_dri3_drawable_fini’:
/usr/share/tomcat7/.jenkins/workspace/mesa/src/loader/loader_dri3_helper.c:122: undefined reference to `xcb_unregister_for_special_event’
collect2: error: ld returned 1 exit status

Again there are multiple pkgconfig .pc files for xcb in /usr/lib/pkgconfig, /usr/lib64/pkgconfig and /usr/local/lib64/pkgconfig. Removing those installed by the package manager and leaving those from the libxcb build resolves this problem.
Fixed in build #438.


Adding id3lib project

The id3lib project is required for the imlib2 project, it lives in cvs at sourceforge. It is built with ./configure, make and make install.
This project appears not to be under active maintenance in the sourceforge CVS repository.


Adding Navit to the build server

Since I’m considering changing my car, I’m having a look at some potential in-car computing systems. Navit looks like it might provide some interesting functionality for open source navigation based on OSM maps. So I’m adding Navit to my Jenkins build server. The project lives in Git and is built with CMake. Adding this build is easy and, while the build completes successfully (installation is another matter, but that is because I built sudo root from the command line which doesn’t give user tomcat permissions to overwrite some of the files…that’ll take a little sorting out, but shouldn’t cause any significant problems), there are some missing dependencies:

  • dbus
  • dbus-glib
  • liblocation
  • libosso
  • libgps
  • libgarmin
  • imlib
  • gypsy
  • fontconfig
  • libspeechd
  • fribidi
  • freeimage

Some of these should be resolved by installing the -devel packages:

  • dbus-devel
  • dbus-glib-devel

The rest will probably need projects added to the build server.


Setting up a Xamarin build in Jenkins

I recently had a look at a Xamarin Studio build running on a Mac, with the idea of adding the build to a Jenkins server.
The build originally failed claiming that the Xamarin licence wasn’t valid (it was only a starter licence when the machine had a business licence installed). There are two options to resolve this, either bring the licence to the Jenkins build or make the Jenkins build be the licensed user. I would generally prefer to keep the CI builds under a different user to contain any wayward builds, but in this case we chose to make the Jenkins server run as the licensed user.
The build had already been set up under the jenkins user, so I needed to pull that job into the new users configuration. This was just a question of copying the job files into the new tree.
I didn’t really get my hands dirty with Xamarin itself, it looks like a neat idea, allowing easy writing and subsequent porting of applications from one mobile platform to another.


Refactoring OBD diagnostics page

The original version of the OBD ‘wheres Neil?’ page was created as a Perl script generating HTML/Javascript on the fly, this was made as a proof of concept to get something on the web. It does leave a lot to be desired, though. For a start, in its current form it will only display the journeys from the last day for which there is data. This is adequate for answering the question “Where’s Neil?”, when live data is arriving that will be the latest, but it doesn’t really allow access to the full power of the collected data. There are some interesting things that might be worth trying to display:

  • Historic data for a particular piece of road
  • Locations of high-revs or high-speeds
  • Locations of sudden acceleration and braking
  • Maps of engine load/RPM and throttle position
  • Locations of good and bad fuel economy

And, I’m sure, there will be others.
To do this I want to bring in an Ajax interface to dynamically get data from the server. Fortunately (and one of the major advantages to this approach) this simplifies the code rather than complicates it. The currently auto-generated HTML/Javascript can be replaced with a static page which requests data using an Ajax request. Then the server need only serve an appropriate JSON object for the required data. This removes the need for the current mishmash of Perl, Javascript and HTML.