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.
Neil Hopcroft
A digital misfit
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.
Build break in of-divand #196
The log reads:
[of-divand] $ hg pull –rev default
abort: HTTP Error 500: Internal Server Error
Which looks like a problem with the mercurial server that I doubt I will be able to fix. I shall leave this project active for the moment and hope it resolves itself.
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.
Build break in of-video #210
The of-video project has failed with these errors:
In file included from AVHandler.cc:25:0:
AVHandler.h:244:12: error: expected ‘;’ at end of member declaration
AVFrame *create_frame(PixelFormat fmt);
^
AVHandler.h:244:37: error: expected ‘)’ before ‘fmt’
AVFrame *create_frame(PixelFormat fmt);
^
AVHandler.cc: In member function ‘int AVHandler::setup_write()’:
AVHandler.cc:117:39: error: ‘CODEC_ID_NONE’ was not declared in this scope
av_output->oformat->audio_codec = CODEC_ID_NONE;
^
AVHandler.cc:146:49: error: expression cannot be used as a function
frame = create_frame(vstream->codec->pix_fmt);
^
AVHandler.cc:147:29: error: ‘PIX_FMT_RGB24’ was not declared in this scope
rgbframe = create_frame(PIX_FMT_RGB24);
^
AVHandler.cc:147:42: error: expression cannot be used as a function
rgbframe = create_frame(PIX_FMT_RGB24);
^
These are some more things missing their AV prefix following some configuration changes. I have made some local fixes for these.
Fixed in build #220.
Adding yocto project
There seems to be a number of people using Yocto Project for their embedded systems builds, indeed, I have experimented with it for the Intel Galileo board I dabbled with a couple of years ago.
To add this to the CI build server I am going to use the Jethro branch. First step is to to clone the code and manually try some builds from the command line. This gives me an error:
libsdl-native is set to be ASSUME_PROVIDED but sdl-config can’t be found in PATH. Please either install it, or configure qemu not to require sdl.
I will add libsdl to the CI build server and see if that resolves the problem – it doesn’t. The latest code there installs libSDL2 and sdl2-config, which doesn’t resolve the dependency problem. Instead removing the SDL lines from the yocto/build/conf/local.conf file does resolve the problem.
The next problem is the sheer size of the build – it is, after all, a system to build a complete image – I aborted the ‘bitbake world’ build at about 20% completion when it threatened to consume all available disk space. ‘bitbake core-image-minimal’ is probably manageable. Then there is the question of how long a build will take – the 20% of the ‘world’ build had taken nearly 2 days, so it isn’t something we want to do clean rebuilds of on a regular basis.
Now the build is failing with
build/genattrtab /usr/share/tomcat7/.jenkins/workspace/yocto/build/tmp/work-shared/gcc-5.2.0-r0/gcc-5.2.0/gcc/common.md /usr/share/tomcat7/.jenkins/workspace/yocto/build/tmp/work-shared/gcc-5.2.0-r0/gcc-5.2.0/gcc/config/i386/i386.md insn-conditions.md \
-Atmp-attrtab.c -Dtmp-dfatab.c -Ltmp-latencytab.c
make[1]: *** [s-attrtab] Killed
A quick search reveals that this is likely caused by running out of memory. Applying the suggested fix there, to add some swap space, resolves this problem.
Now the build runs to completion, taking 37 hours to complete even though I had already allowed 200-odd of the tasks to run in a shell.
The next question is how updates occur, I have launched a few more builds since this completion and there have been no changes, leaving the build with no tasks requiring rerunning. I’ll put this on a weekly rebuild schedule and see what happens.