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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
