octave-control 2.6.5-1 is missing the compiled file __control_slicot_functions__.oct

The package octave-control in Ubuntu 14.10 is missing the compiled file /usr/lib/x86_64-linux-gnu/octave/packages/control-2.6.5/x86_64-pc-linux-gnu-api-v49+/__control_slicot_functions__.oct. Compare the file list between 14.04, 14.10, and 15.04 to see that the file is only missing in the utopic build. The missing file should have been a build error, but a separate error in Octave 3.8.1 masks the exit status of a linker error when building oct-file extensions for Octave.

The reason for the build failure looks like there may have been a temporary problem with the libgfortran library at the time that octave-control was built for utopic. Rebuilding the source package in a clean chroot now results in the correct package contents.

I believe a rebuild of the source package should be suitable for an SRU for utopic.

[Impact]

 * The missing file contains many low-level functions supporting the rest
   of the octave-control package. Some portion of the package may work, but
   much of it is completely non-functional.

 * The fix is a no-change rebuild, which should result in the missing file
   being correctly compiled and installed. The reason it is missing in the
   current package was a link error against libgfortran at the time it was
   built. That error does not occur when the source package is rebuilt now.

 * This package is a leaf package, only affecting itself, octave, and other
   octave-* packages that depend on it. This bug is a moderately severe
   regression from trusty. The package may not be completely unusable, but
   much of its functionality is affected.

[Test Case]

 * As described in bug #1410542, run the following octave test case:

   $ octave -q --persist --eval "more off; s=tf('s'); h=1/((s-1)*(s-10));
     step(h)"

   With the bug present, this will result in

   warning: autoload: '__control_slicot_functions__.oct' is not an absolute file name
   warning: autoload: '__control_slicot_functions__.oct' is not an absolute file name
   ...
   warning: autoload: '__control_slicot_functions__.oct' is not an absolute file name
   error: '__sl_td04ad__' undefined near line 121 column 14

   When the bug is fixed, octave will produce a plot, either graphical or
   ascii art, depending on your environment.

 * Another test case is to run the following:

   $ sudo update-alternatives --set libblas.so.3 \
        /usr/lib/libblas/libblas.so.3
   $ sudo update-alternatives --set liblapack.so.3 \
        /usr/lib/lapack/liblapack.so.3
   $ octave -q --eval "more off; test_control"

   With the bug present, this will result in lots of error output showing
   the contents of data arrays and structs, with "!!!!! test failed" and
   "undefined near" messages sprinkled throughout.

   When the bug is fixed, the same command will result in a clean list of
   several "PASSES # out of # tests".

   The reason for ensuring the BLAS and LAPACK libraries are selected instead
   of ATLAS is described in the test_control.m script being run, see
   /usr/share/octave/packages/control-2.6.5/test_control.m.

[Regression Potential]

 * As the fix for this bug is a no-change rebuild, the regression risk is
   quite low. There is no source diff, so there is no risk from inadvertent
   code changes being introduced.

 * The intent of this fix is to produce an updated binary package that is
   identical to the current package with the addition of the one missing
   file. There are 5 other compiled files in the package that are much
   simpler and have no external dependencies other than octave.