[Debian-med-packaging] camitk autopkgtest failing

[Emmanuel Promayon]

Dear Andreas,

Thanks to what you and Sascha did in the njplot autopkgtest [1], I think 
I managed to fix the autopkgtest bug in camitk.

My machine is running jessie, and I unfortunately did not manage to 
setup a proper lxc container as you suggested. But I managed to setup a 
docker container to run the tests as if they was done on a "clean" sid 
(well I think).

If that is ok with you, the package is ready to upload (unless you want 
to test using lxc firts). Thanks again!

(the following section is describing the problems there was in 
autopkgtet in details and can be skipped, it is just here for future 
reference)
There was three problems :
1. when using xvfb-run the first line was an OpenGL message ("libEGL 
warning: DRI2: failed to open swrast"). As the "config" test captures 
the output of camitk-config command (which "introspect" which version is 
installed), the installed camitk version was not correctly detected. As 
the config test was faulty, it still pass the test, but that was due to 
a bug in the "config" test. I fix this bug and then had to add a 
dependency to libgl1-mesa-dri to avoid the OpenGL message
2. that led to a dbus problem ("D-Bus library appears to be incorrectly 
set up"), I had to add a dependency to the dbus package. That done, 
running the Xvfb server and then running the camitk-config command, as 
it is done in [1], finished to resolve all the problems
3. the "wizard" test is testing that the dev package can be used to 
develop a new extension. It generates C++ code, try to build the 
extension, and check that the new extension is recognized by 
camitk-config (i.e., that the new extension works). This time the wizard 
test was not verbose enough to detect the real problem, as you 
suggested. Once modified it appears that the test needed g++ dependency. 
Once added to tests/control the problem seemed solved.

autopkgtest is truly a very good system and it is worth the effort 
fixing all of this. It does not mean the upstream package is empty of 
any bugs (if that is possible), but it is a very good way of checking 
that the final environment is what you think it should be!

(the following "rambling" section can also be skipped, my apologies if 
it is just due to my lack of understanding of the packaging/dependency 
process)
Problem #3 means, as libcamitk-dev is listed as a autopkgtest 
dependency, that
- either libcamitk-dev does not depends on g++, which means that all the 
-dev packages required to build libcamitk-dev do not depend on g++ either
- or that I forgot something in d/control
I am nearly sure it is the latter, as the first explanation seems a bit 
strange. It might be due to my very narrow vision on the 
packaging/dependency process, but even if I agree that, per se, there is 
no dependency between a development package (e.g., qtbase5-dev) and the 
compiler required to build something with it once it is installed, I am 
wondering if there is a use-case where someone will need to install a 
development package without using the compiler required to develop with 
it (it would a bit like having screws and no screwdriver!).
If someone can clarify that for me, that would be great! (if it is total 
nonsense, or if it just that I forgot something in d/control or 
d/tests/control, do not hesitate to tell me!)

Have a nice week-end,

Emmanuel

[1] https://anonscm.debian.org/cgit/debian-med/njplot.git/tree/debian/tests