Bug#756222: src:vlfeat: appears to ignore errors from mkoctfile

[Dima Kogan]

Hi.

This is two separate issues. First the easy one:

The "No such file or directory" errors you are seeing on amd64 are
benign; the generated packages are not negatively affected. The issue is
that the mkoctfile tool changed its behavior from liboctave-dev 3.6.x
(in stable) to liboctave-dev 3.8.x (testing, unstable). In 3.6.x

 mkoctfile -M SOMEDIR/SOMEFILE.c

would create SOMEDIR/SOMEFILE.d. This is the behavior vlfeat was
assuming. In 3.8.x SOMEFILE.d is created in the current directory
instead. I'll fix it when I update this package, but its benign in the
meantime.



The issue you're seeing on armhf looks more serious, but I don't have
porterbox access, so I can't debug it directly. Looking at the armhf
package in the archive, it looks fine. Looking at the buildd logs that
produced the packages in the archive, it looks fine too:

 https://buildd.debian.org/status/fetch.php?pkg=vlfeat&arch=armhf&ver=0.9.17%2Bdfsg0-6%2Bb1&stamp=1393709508

Here you can see that things built just fine on armhf, including the
mkoctfile commands. Could you simply be running out of memory, and the
slowness is simply swapping?

If you want, you can run the command in your bug report by itself on
your armhf box to see if it is problematic. The command is

 /usr/bin/mkoctfile -I. -I./toolbox -M "./toolbox/slic/vl_slic.c"

Run that from the root of the vlfeat tree. If you see the issues
(std::bad_alloc or slowness), then you can try to see if you're hitting
memory limits or other issues. Since it worked for the buildhost, I
suspect it's not a bug in the vlfeat package. Let me know if this
remains mysterious, and I'll ask for porterbox access and look into it
myself.

dima