bob issueshttps://gitlab.idiap.ch/bob/bob/-/issues2019-06-24T13:44:12Zhttps://gitlab.idiap.ch/bob/bob/-/issues/82No Windows port2019-06-24T13:44:12ZAndré AnjosNo Windows port*Created by: anjos*
Currently, we have no Windows port of Bob. This is a major problem as most researchers still use Windows. Let's put here information on how to create one and close this once a port is available.
Current status:
> T...*Created by: anjos*
Currently, we have no Windows port of Bob. This is a major problem as most researchers still use Windows. Let's put here information on how to create one and close this once a port is available.
Current status:
> The most promising solution for a *quicker* porting is to use [cygwin](http://www.cygwin.com/).v2.0https://gitlab.idiap.ch/bob/bob/-/issues/59ImageMagick 6.7.7 issues on OSX (MacPorts)2016-08-04T09:28:50ZAndré AnjosImageMagick 6.7.7 issues on OSX (MacPorts)*Created by: anjos*
We just found out that the version of ImageMagick currently shipped with MacPorts (6.7.7) presents a runtime problem related to https://bugs.archlinux.org/task/30122?project=1&openedfrom=-1+week. Until that gets upgr...*Created by: anjos*
We just found out that the version of ImageMagick currently shipped with MacPorts (6.7.7) presents a runtime problem related to https://bugs.archlinux.org/task/30122?project=1&openedfrom=-1+week. Until that gets upgraded in MacPorts, avoid using that version. If you upgraded and things became unstable, downgrade with the following recipe:
```sh
$ wget --no-check-certificate https://trac.macports.org/export/93199/trunk/dports/graphics/ImageMagick/Portfile
$ sudo port uninstall ImageMagick
$ sudo port install
```
6.7.6 and 6.7.7 are API and ABI compatible. You **don't** need to recompile your build of Bob after downgrading or upgrading.v1.1https://gitlab.idiap.ch/bob/bob/-/issues/2Put in place tools to create releases in a snap2016-08-04T09:26:49ZAndré AnjosPut in place tools to create releases in a snap*Created by: anjos*
We need tools to build releases out of bob check-outs. The tool needs to be simple to use so we can just specify a tag on the tree and the rest happens automatically.*Created by: anjos*
We need tools to build releases out of bob check-outs. The tool needs to be simple to use so we can just specify a tag on the tree and the rest happens automatically.v1.0https://gitlab.idiap.ch/bob/bob/-/issues/5CMake Cleanup2016-08-04T09:26:55ZAndré AnjosCMake Cleanup*Created by: anjos*
This ticket keeps track of needed CMake script updates to tackle the following:
1. Clean-up the PCH support by removing this
2. Find a way to keep the "package" support, but do not depend on the "install" directo...*Created by: anjos*
This ticket keeps track of needed CMake script updates to tackle the following:
1. Clean-up the PCH support by removing this
2. Find a way to keep the "package" support, but do not depend on the "install" directory to find headers. This tends to work badly with template files and in other special cases.
3. Maybe port Cmake stuff to Scons?
4. Try other build systems?https://gitlab.idiap.ch/bob/bob/-/issues/12FindOpenCV not available with stock cmake 2.82016-08-04T09:27:07ZAndré AnjosFindOpenCV not available with stock cmake 2.8*Created by: laurentes*
There is a problem with the current OpenCV dependence: FindOpenCV is not found on any platform and, therefore, even if opencv development files are installed, the bindings to opencv DAQ will not be built.
Coul...*Created by: laurentes*
There is a problem with the current OpenCV dependence: FindOpenCV is not found on any platform and, therefore, even if opencv development files are installed, the bindings to opencv DAQ will not be built.
Could you please include [FindOpenCV](http://opencv.willowgarage.com/wiki/FindOpenCV.cmake) with Bob's build so that OpenCV detection works properly?
Thanks,v1.0https://gitlab.idiap.ch/bob/bob/-/issues/145RPM Packages, OBS and Koji2016-08-04T12:27:46ZAndré AnjosRPM Packages, OBS and Koji*Created by: anjos*
> This issue was migrated from bug #104
Like we have Ubuntu packages being built for a variety of Ubuntu platforms, it would be nice to have packages built for OpenSuse and Fedora distros as well.
Here is a pl...*Created by: anjos*
> This issue was migrated from bug #104
Like we have Ubuntu packages being built for a variety of Ubuntu platforms, it would be nice to have packages built for OpenSuse and Fedora distros as well.
Here is a place to start:
For Fedora: http://koji.fedoraproject.org/koji/
For Suse: https://build.opensuse.org/
Furthermore, we already have a prototypical RPM skeleton for Bob at https://github.com/bioidiap/bob.rpm
The person that tackles this bug should develop that package with instructions and modifications so we can upload package build requests to one of the above services.https://gitlab.idiap.ch/bob/bob/-/issues/58OpenCV 2.4.x has problems with pkg-config2016-08-04T09:28:48ZAndré AnjosOpenCV 2.4.x has problems with pkg-config*Created by: anjos*
The following bug in the OpenCV tracker affects us (at least our OSX builds with MacPorts): http://code.opencv.org/issues/1925. Avoid upgrading to OpenCV 2.4.x until that is fixed. The last know version to work prope...*Created by: anjos*
The following bug in the OpenCV tracker affects us (at least our OSX builds with MacPorts): http://code.opencv.org/issues/1925. Avoid upgrading to OpenCV 2.4.x until that is fixed. The last know version to work properly is 2.3.1a.
Here is a recipe to revert your Mac Ports installation to OpenCV 2.3.1a in case you need it:
```sh
$ wget --no-check-certificate https://trac.macports.org/export/90303/trunk/dports/graphics/opencv/Portfile https://trac.macports.org/export/90303/trunk/dports/graphics/opencv/files/patch-CMakeLists.txt.diff https://trac.macports.org/export/90303/trunk/dports/graphics/opencv/files/patch-install_name.diff https://trac.macports.org/export/90303/trunk/dports/graphics/opencv/files/patch-pch-CMakeLists.txt.diff
$ mkdir files
$ mv patch-*.diff files
$ sudo port install
```v1.1https://gitlab.idiap.ch/bob/bob/-/issues/25cblas, clapack and LAPACK2016-08-04T09:27:32ZAndré Anjoscblas, clapack and LAPACK*Created by: laurentes*
In the early years, we've got rid of the usage of C functions from cblas and clapack, calling the Fortran functions from LAPACK directly. This is not reflected in the external/cblasConfig.cmake, which still requi...*Created by: laurentes*
In the early years, we've got rid of the usage of C functions from cblas and clapack, calling the Fortran functions from LAPACK directly. This is not reflected in the external/cblasConfig.cmake, which still requires cblas.h and clapack.h to exist.v1.0https://gitlab.idiap.ch/bob/bob/-/issues/38VLFeat is not detected despite installation2016-08-04T09:28:03ZAndré AnjosVLFeat is not detected despite installation*Created by: anjos*
From my understanding of the cmake file, we should see a printout when VLFeat is detected on the system:
```
Found VLFeat: /usr/lib/libvlfeat.so
```
But we don't seem to see this line ever. Could you make sur...*Created by: anjos*
From my understanding of the cmake file, we should see a printout when VLFeat is detected on the system:
```
Found VLFeat: /usr/lib/libvlfeat.so
```
But we don't seem to see this line ever. Could you make sure that it is properly detected and reported?v1.0https://gitlab.idiap.ch/bob/bob/-/issues/43Writing external code that depends on Bob2016-08-04T09:28:15ZAndré AnjosWriting external code that depends on Bob*Created by: anjos*
Sometime ago we had the ability to compile external projects against Bob using CMake. Our CMake development environment does export its properties and all those files get installed properly. Remains untested though:
...*Created by: anjos*
Sometime ago we had the ability to compile external projects against Bob using CMake. Our CMake development environment does export its properties and all those files get installed properly. Remains untested though:
1. How to compile C++ extensions using Bob libraries
2. How to compile Python C++ bindings using Bob libraries and extensions to boost.python (e.g. const_ndarray objects)
This bug should remain opened until we get this functionality back.https://gitlab.idiap.ch/bob/bob/-/issues/48Bob, RPATH policy and versions on shared objects2016-08-04T09:28:26ZAndré AnjosBob, RPATH policy and versions on shared objects*Created by: anjos*
The current infrastructure does not use the properties VERSION (build) and SOVERSION (api) for marking the C++ libraries. I'm not sure the same should be done for python bindings written with Boost.Python.
Further...*Created by: anjos*
The current infrastructure does not use the properties VERSION (build) and SOVERSION (api) for marking the C++ libraries. I'm not sure the same should be done for python bindings written with Boost.Python.
Furthermore, when installing Bob globally, the RPATH mechanism should be disabled as it is totally useless.https://gitlab.idiap.ch/bob/bob/-/issues/49On any Ubuntu version, bob gets linked to libvl.so2016-08-04T09:28:28ZAndré AnjosOn any Ubuntu version, bob gets linked to libvl.so*Created by: anjos*
The problem is that the pre-compiled Ubuntu versions are now depending on libvl.so instead of depending on libvl.so.0
If you have a 12.04 somewhere, you can test this. Just uninstall libvl0.
Now, install bob from...*Created by: anjos*
The problem is that the pre-compiled Ubuntu versions are now depending on libvl.so instead of depending on libvl.so.0
If you have a 12.04 somewhere, you can test this. Just uninstall libvl0.
Now, install bob from our ppa. Fire-up python and then try to import bob. You will get the error:
```sh
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bob
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/pymodules/python2.6/bob/__init__.py", line 16, in <module>
from . import ip
File "/usr/lib/pymodules/python2.6/bob/ip/__init__.py", line 1, in <module>
from ._ip import *
ImportError: libvl.so: cannot open shared object file: No such file or directory
```
This can be (temporarily) fixed with the following commands:
```sh
$ sudo apt-add-repository ppa:biometrics/vlfeat
$ sudo apt-get update
$ sudo apt-get install libvl-dev
```
Besides, our packages do not (yet) depend on the packages libvl0 or libblitz1ldbl. They should.https://gitlab.idiap.ch/bob/bob/-/issues/50Solving/Simplifying the RPATH or INSTALL_DIR2016-08-04T09:28:29ZAndré AnjosSolving/Simplifying the RPATH or INSTALL_DIR*Created by: anjos*
Currently, to build our Ubuntu or OSX packages, we need to disable the setting of these variables as files get moved during installation using `debuild` or `MacPorts`. Here is a strategy to get rid of this annoyance:...*Created by: anjos*
Currently, to build our Ubuntu or OSX packages, we need to disable the setting of these variables as files get moved during installation using `debuild` or `MacPorts`. Here is a strategy to get rid of this annoyance:
1. Move the library `_core_array.so` to the `<prefix>/lib` directory and version it properly
2. Make all other python bindings depend on that instead of a library hidden at python directories
3. Make the python bindings use the RPATH by default (this is disabled when the user passes `-DCMAKE_SKIP_BUILD_RPATH=TRUE` to CMake. Under OSX, have a similar mechanism that will do that for the INSTALL_DIR property.
Notes:
1. The RPATH functionality is only required for the python bindings
2. The python bindings only require that functionality if the libraries they depend on are not installed in a standard location.https://gitlab.idiap.ch/bob/bob/-/issues/67Video support broken with ffmpeg 0.9 and superior2016-08-04T09:29:00ZAndré AnjosVideo support broken with ffmpeg 0.9 and superior*Created by: anjos*
Cannot read AVI files with ffmpeg 0.10 or 0.11. The last frames of long sequences seem all be set to zeros or cannot be read at all. To reproduce this problem, compile Bob against any of the above mentioned versions ...*Created by: anjos*
Cannot read AVI files with ffmpeg 0.10 or 0.11. The last frames of long sequences seem all be set to zeros or cannot be read at all. To reproduce this problem, compile Bob against any of the above mentioned versions and try to read and verify that an AVI file can be read as it is supposed to be.https://gitlab.idiap.ch/bob/bob/-/issues/79cmake complains about BLAS library not found even after installing BLAS and L...2016-08-04T09:29:18ZAndré Anjoscmake complains about BLAS library not found even after installing BLAS and LAPACK libraries (Fedora 14)*Created by: thelinuxmaniac*
In Fedora Core 14, cmake complains about BLAS library not found even after installing BLAS and LAPACK libraries.
$ cmake -DCMAKE_BUILD_TYPE=Release ../git/bob/
.....
CMake Error at src/math/cxx/CMakeLists.tx...*Created by: thelinuxmaniac*
In Fedora Core 14, cmake complains about BLAS library not found even after installing BLAS and LAPACK libraries.
$ cmake -DCMAKE_BUILD_TYPE=Release ../git/bob/
.....
CMake Error at src/math/cxx/CMakeLists.txt:18 (message):
BLAS library not found!
The BLAS and LAPACK libraries were installed using
$ yum install blas-devel.x86_64 blas.x86_64 lapack-devel.x86_64 lapack.x86_64
https://gitlab.idiap.ch/bob/bob/-/issues/88Bob opportunistically links against Qt42016-08-04T09:29:40ZAndré AnjosBob opportunistically links against Qt4*Created by: anjos*
The current way the build is structured, there is no flag that allows us switching off ~~OpenCV and~~ Qt4 dependences. If they are available on the target system, they are compiled and linked into the final binaries....*Created by: anjos*
The current way the build is structured, there is no flag that allows us switching off ~~OpenCV and~~ Qt4 dependences. If they are available on the target system, they are compiled and linked into the final binaries.
This behavior is incompatible with packaging tools in which you can describe to which packages another package may depend on. If Bob opportunistically links against what is available, the packaging system will not detect real dependences and avoid, for example, OpenCV to be removed without Bob being removed first.
For the time being, a solution would be to make the build systems always install all dependencies.
This bug was triggered by a bug reported to us on MacPorts: https://trac.macports.org/ticket/36491v1.2https://gitlab.idiap.ch/bob/bob/-/issues/90Version of Bob at configuration time is not trasmitted to setup.py2012-10-09T20:56:56ZAndré AnjosVersion of Bob at configuration time is not trasmitted to setup.py*Created by: anjos*
If I start Idiap's Bob:
```python
>>> import pkg_resources
>>> pkg_resources.require('bob')[0]
bob 1.1.0a0 (/usr/lib/pymodules/python2.6)
```
This needs fixing before release 1.1.1.*Created by: anjos*
If I start Idiap's Bob:
```python
>>> import pkg_resources
>>> pkg_resources.require('bob')[0]
bob 1.1.0a0 (/usr/lib/pymodules/python2.6)
```
This needs fixing before release 1.1.1.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/99blitz include error on multilib installations2016-08-04T09:30:02ZAndré Anjosblitz include error on multilib installations*Created by: ozancaglayan*
Fedora installs architecture dependent blitz/gnu/bzconfig.h header into /usr/lib64/blitz/include. This path should be included when building the project. This is already indicated in the pkgconfig file of blit...*Created by: ozancaglayan*
Fedora installs architecture dependent blitz/gnu/bzconfig.h header into /usr/lib64/blitz/include. This path should be included when building the project. This is already indicated in the pkgconfig file of blitz package in Cflags:
```
Name: blitz
Description: blitz Library
Version: 0.9
Requires:
Libs: -L${libdir} -lblitz
Cflags: -I${includedir} -I${libdir}/blitz/include
```
but CMake is not aware of that. I've adjusted src/blitz.cmake and added the following line to fix this:
```
include_directories(/usr/lib64/blitz/include)
```
This can probably be done in a more elegant way but I don't know how.
Thanks.https://gitlab.idiap.ch/bob/bob/-/issues/100Honor multilib distributions when installing libraries2016-08-04T09:30:08ZAndré AnjosHonor multilib distributions when installing libraries*Created by: ozancaglayan*
Hi,
Current build system installs shared libraries and pkgconfig files under /usr/lib but python site-package under /usr/lib64 on a multilib x86_64 distro like F17.
The correct directory is /usr/lib64 for bo...*Created by: ozancaglayan*
Hi,
Current build system installs shared libraries and pkgconfig files under /usr/lib but python site-package under /usr/lib64 on a multilib x86_64 distro like F17.
The correct directory is /usr/lib64 for both. I've created a patch for taking care of the library suffix using CMake. This also fixed nosetests and sphinx-doctest targets which were failing on the current tree on my system.
The patch is at:
https://gist.github.com/4246783
Thanks!https://gitlab.idiap.ch/bob/bob/-/issues/102Cleaning the builds on MacOSX fails2016-08-04T09:30:14ZAndré AnjosCleaning the builds on MacOSX fails*Created by: siebenkopf*
The clean-up on *MacOSX* in the buildbot seems not to work. Apparently, the directories where it is executed:
/idiap/group/torch5spro/scratch/buildbot-slave/ekhoury-x86_64/idiap-10.04-x86_64-incremental+stable/...*Created by: siebenkopf*
The clean-up on *MacOSX* in the buildbot seems not to work. Apparently, the directories where it is executed:
/idiap/group/torch5spro/scratch/buildbot-slave/ekhoury-x86_64/idiap-10.04-x86_64-incremental+stable/build
and
/idiap/group/torch5spro/scratch/buildbot-slave/ekhoury-x86_64/idiap-10.04-x86_64-incremental+stable/extras/tools
are wrong in the clean scripts.
@André: Could you fix that?
Cheers
Manuelhttps://gitlab.idiap.ch/bob/bob/-/issues/106Blitz++ misdetection does not stop the build2013-03-07T11:10:47ZAndré AnjosBlitz++ misdetection does not stop the build*Created by: anjos*
Testing this unexpected feature of our build system on Arch Linux's buggy Blitz++ installation (no pkg-config for Blitz++ was available), made me realize that, at no times, we have a provision for a failed Bltiz++ de...*Created by: anjos*
Testing this unexpected feature of our build system on Arch Linux's buggy Blitz++ installation (no pkg-config for Blitz++ was available), made me realize that, at no times, we have a provision for a failed Bltiz++ detection or that it is not working adequately. A fix must be inserted before the next release.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/108Libavutil PixelFormat C-style macro conflicts with bob daq PixelFormat enum2016-08-04T09:30:26ZAndré AnjosLibavutil PixelFormat C-style macro conflicts with bob daq PixelFormat enum*Created by: laurentes*
This bug was initially reported on [macports](https://trac.macports.org/ticket/37833).
The problem has occured after a libavutil update on macports, which now defines a C macro PixelFormat in /opt/local/include/...*Created by: laurentes*
This bug was initially reported on [macports](https://trac.macports.org/ticket/37833).
The problem has occured after a libavutil update on macports, which now defines a C macro PixelFormat in /opt/local/include/libavutil/pixfmt.h:307:21
```C
#define PixelFormat AVPixelFormat
```
As the macro seems to be used in src/io/cxx/VideoUtilities.cc, we can't undefine it just after the inclusion of the libavutil header. One solution would be to undefine it in the fundamental headers of the DAQ submodule, include/bob/daq/Camera.h and include/bob/daq/Controller.hhttps://gitlab.idiap.ch/bob/bob/-/issues/146bob-config.cmake2016-08-04T09:31:37ZAndré Anjosbob-config.cmake*Created by: neodark*
Hello,
It's a great idea to have the bob-config.cmake in the <install_folder>/lib/bob/bob-config.cmake
There's just a small bug at the generation of this 2 lines in the file (I have spotted the error with <This p...*Created by: neodark*
Hello,
It's a great idea to have the bob-config.cmake in the <install_folder>/lib/bob/bob-config.cmake
There's just a small bug at the generation of this 2 lines in the file (I have spotted the error with <This path is not correct>):
get_filename_component(bob_INCLUDE_DIRS "<This path is not correct>" ABSOLUTE)
get_filename_component(bob_LIBRARY_DIRS "<This path is not correct>" ABSOLUTE)
<This path is not correct> should be replaced by <path to installed bob folder>/include for the first line and <path to installed bob folder>/lib for the second line
Cheers,
Flaviov1.2https://gitlab.idiap.ch/bob/bob/-/issues/156Build should fail if pkg-config is not installed2019-04-19T22:41:24ZAndré AnjosBuild should fail if pkg-config is not installed*Created by: anjos*
The build should fail if CMake cannot find pkg-config:
```
-- Bob version '1.2.0' (macosx-x86_64-release)
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE
```*Created by: anjos*
The build should fail if CMake cannot find pkg-config:
```
-- Bob version '1.2.0' (macosx-x86_64-release)
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE
```v2.0https://gitlab.idiap.ch/bob/bob/-/issues/160Build should fail if Blitz++ <0.10 is detected2016-08-04T09:31:58ZAndré AnjosBuild should fail if Blitz++ <0.10 is detected*Created by: anjos*
There seems to be on guard in case an older version of Blitz is installed at the system. This can be easily fixed by a pkg-config check.*Created by: anjos*
There seems to be on guard in case an older version of Blitz is installed at the system. This can be easily fixed by a pkg-config check.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/180bob nosetest fails on Mac OS 10.8.52016-08-04T09:32:33ZAndré Anjosbob nosetest fails on Mac OS 10.8.5*Created by: tcgeophysics*
I am running into an error with the ``` make nosetests ``` step of the compiling from source process.
I am using a Mac OS Mountain Lion 10.8.5 (64bits) and installing bob with homebrew.
The following is in...*Created by: tcgeophysics*
I am running into an error with the ``` make nosetests ``` step of the compiling from source process.
I am using a Mac OS Mountain Lion 10.8.5 (64bits) and installing bob with homebrew.
The following is installed:
Homebrew
HOMEBREW_VERSION: 0.9.5
CPU: 8-core 64-bit ivybridge
OS X: 10.8.5-x86_64
Xcode: 5.0.2
CLT: 5.0.1.0.1.1377666378
X11: 2.7.5
Python: 2.7.6
Nose: 1.3.0
VLFEAT is not installed and ``` -DWITH_VLFEAT=OFF ``` is specified
I wrote a homebrew formula to install bob and it seems to work for now without the nosetests step. [bob.q formula here](https://gist.github.com/tcgeophysics/8156717)
To repeat the problem
1 - install homebrew,
2 - Create a bob formula: ```brew create http://www.idiap.ch/software/bob/packages/bob-1.2.2.tar.gz```
3 - Edit the bob formula: ```brew edit bob```
delete everything and paste the contents of the [bob.q formula here](https://gist.github.com/tcgeophysics/8156717)
4 - Run ```brew install -v bob``` to install in debug mode
The install process does not complete with nosetests and exit with the following message:
```
======================================================================
ERROR: bob.io.test.test_video.test_frameskip_format_mov_codec_wmv1
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/test/utils.py", line 108, in wrapper
return test(*args, **kwargs)
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/io/test/test_video.py", line 71, in check_format_codec
orig, framerate, encoded = function(shape, framerate, format, codec, fname)
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/io/utils.py", line 145, in frameskip_detection
fontsize = estimate_fontsize(height, width, text_format)
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/io/utils.py", line 32, in estimate_fontsize
font = ImageFont.truetype(DEFAULT_FONT, best_size)
File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/ImageFont.py", line 218, in truetype
return FreeTypeFont(filename, size, index, encoding)
File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/ImageFont.py", line 134, in __init__
self.font = core.getfont(file, size, index, encoding)
File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/ImageFont.py", line 34, in __getattr__
raise ImportError("The _imagingft C module is not installed")
ImportError: The _imagingft C module is not installed
======================================================================
FAIL: test01_plda_EM_vs_Python (bob.trainer.test.test_plda.PLDATrainerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/tmp/bob-OifB/bob-1.2.2/build/lib/python2.7/site-packages/bob/trainer/test/test_plda.py", line 391, in test01_plda_EM_vs_Python
self.assertTrue(numpy.allclose(m.f, m_py.f))
AssertionError: False is not true
-------------------- >> begin captured logging << --------------------
bob.c++: INFO: # EMTrainer:
bob.c++: INFO: # Iteration 1
bob.c++: INFO: # Iteration 2
bob.c++: INFO: # Iteration 3
bob.c++: INFO: # Iteration 4
bob.c++: INFO: # Iteration 5
bob.c++: INFO: # Iteration 6
bob.c++: INFO: # Iteration 7
bob.c++: INFO: # Iteration 8
bob.c++: INFO: # Iteration 9
bob.c++: INFO: # Iteration 10
bob.c++: INFO: # EM terminated: maximum number of iterations reached.
--------------------- >> end captured logging << ---------------------
----------------------------------------------------------------------
Ran 467 tests in 133.735s
FAILED (SKIP=4, errors=100, failures=1)
make[3]: *** [python/CMakeFiles/nosetests] Error 1
make[2]: *** [python/CMakeFiles/nosetests.dir/all] Error 2
make[1]: *** [python/CMakeFiles/nosetests.dir/rule] Error 2
make: *** [nosetests] Error 2
```
The full nosetests output can be found on this gist:
https://gist.github.com/tcgeophysics/8286521
Any advices on how to solves the issues pointed out by the nose output? Are they critical for bob?
It seems there is a problem with PIL which might not be maintained anymore.
Could PILLOW work instead?
https://gitlab.idiap.ch/bob/bob/-/issues/183-DWITH_PERFTOOLS option does not work2019-04-19T22:41:25ZAndré Anjos-DWITH_PERFTOOLS option does not work*Created by: laurentes*
It seems that this option does not work anymore on the master branch.
I don't know yet if this also affect the 1.2 branch.
The problems seems to be caused by the use of WITH_PERFTOOLS as a C-like defined vari...*Created by: laurentes*
It seems that this option does not work anymore on the master branch.
I don't know yet if this also affect the 1.2 branch.
The problems seems to be caused by the use of WITH_PERFTOOLS as a C-like defined variable, whereas this is initially a cmake variable.
The easiest solution is to perform the inclusion check at the cmake level rather than by the C preprocessor. A good example is what was done for libsvm.v2.0