[Pkg-octave-devel] Octaviz autobuilder problem

[Rafael Laboissiere]

After six desperate debugging releases of octaviz (0.4.0-16 to -21) I
finally discovered why some autobuilders are failing to build the
package.  For instance, see:

http://buildd.debian.org/fetch.php?&pkg=octaviz&ver=0.4.0-21&arch=ia64&stamp=1137769597&file=log&as=raw

In debian/rules, I included an update-alternatives command. Here is an
excerpt of the build log mentioned above:

#######################################################################
[...]
Selecting previously deselected package octave2.1-headers.
Unpacking octave2.1-headers (from .../octave2.1-headers_1%3a2.1.72-8_ia64.deb) ...
[...]
Setting up octave2.1 (2.1.72-8) ...
[...]
/usr/sbin/update-alternatives --display octave-config
octave-config - status is manual.
link currently points to /usr/bin/octave-config-2.1.71
/usr/bin/octave-config-2.1.72 - priority 80
slave octave-config.1.gz: /usr/share/man/man1/octave-config-2.1.72.1.gz
Current `best' version is /usr/bin/octave-config-2.1.72.
[...]
#######################################################################

The questions are: why is the octave-config alternative set to manual and
why is it pointing to octave-config-2.1.71 instead of
octave-config-2.1.72?  This must have something to do with a previous
version of the octave2.1 package that did not cleaned up properly the
alternative.

This also explains why the buildd problem seemed to happen randomly:
since each time, for a given architecture, a different machine is chosen
for the buildd, if it happened to be a machine that had never installed
octave2.1_2.1.71-* before, then the build succeeded.

I can imagine two ways of fixing this bug:

1) The "ducking approach": patch CMakeLists.txt to use
   /usr/bin/octave-config-2.1.72 explicitly. 

2) The "brute force" approach: get the autobuilder admins to clean up the
   octave-config alternative on each machine.
 
What should we do?  Should we ask this at debian-devel?

-- 
Rafael