[Debian-med-packaging] Bug#817163: [sanvila at debian.org: Bug#817163: camitk: FTBFS when built with dpkg-buildpackage -A (191 tests failed out of 191)]

[Andreas Tille]

Hi Emmanuel,

I'm keeping the bug report in CC.

On Mon, Mar 21, 2016 at 07:40:56AM +0100, Emmanuel Promayon wrote:
> 
> Thank you for your email. Sorry about not keeping in touch about everything.
> I was about to contact you very soon (with some good news), but I now seize
> this opportunity to communicate a bit better!

:-)
 
> Here are the state of the CamiTK development upstream:
> - version 3.5 was released a few weeks ago. It was mainly a bug fixing
> release for version 3.4, using the same dependencies as version 3.4 (Qt4,
> Vtk5, Itk3)
> - we are currently working on camitk 4.0, that should be released hopefully
> very soon (the target is before the end of March).
> CamiTK 4.0 has the exact same features as CamiTK 3.5 but updates the
> dependencies to Qt5, Vtk6, Itk4 and cmake 3, and make sure it is compatible
> with gcc5/cxx-11. Code written with the 3.4 or 3.5 API would have to be
> alter a bit to take the dependency updates into account, but apart from few
> include differences, should work with 4.0

All sounds very good.

> We are also moving to git for upstream development.

Just let me know if you intend to follow this move for the packaging
(which would sound consequently to me).  I'd volunteer to move the
current state since it is not much work if you have some routine in it
and it is not so much to learn since you will not need this knowledge
later again. :-)

> Moving to itk4 is not the main problem, the main problem is to move to Qt5
> and VTK6 (moving to VTK6 implies moving to Qt5 and we package our own
> version of qtpropertybrowser from Qt Solution that need to be updated to Qt5
> as well)

I think all migrations are important and it is good to know that these
are under way.

> - we have noticed bug #817163 (as well as bug #816805 about Qt4 WebKit
> removal).

If you notice such bugs please be so kind to reply as soon as possible
with relevant information.  This mail helps bug reporters a lot to
adjust their todo list.  Since you are actively working on a solution
it could be set to pending and nobody needs to bother looking at the
issue in the near future.
 
> Here is what we are intending to do:
> - leave camitk 3 branch live the end of its software life (3.3.2 on stable)
> - update the camitk debian package to support the 4.0 branch

Sounds sensible.
 
> Here are where all your (and everyone's!) advice and guidance are sought:
> - What is the easiest way for us and safest way for the users?
> It seems better to us to create a new "camitk4" project (preferably on git)
> and specify that "camitk" project is not going to be supported after jessie.
> But do you agree? And if yes, how to do that?

There is no point in creating a new project.  As I said I'd volunteer to
migrate camitk from svn to Git and you keep on working on this
repository.  There should be no separate project and also no extra
branch for continued development.  May be you intend to support a
backport for version 4 for stable - than an extra branch would be
needed.  But you should have "good reasons" for such a backport.

> - Concerning bug #817163, yes, I would like some advice! I did not really
> understand what it meant exactly. It seams to me (let me know if I am wrong)
> that it is a consequence of a problematic build of 3.4 on sid.

No.  It just means that you need to be able to create the binary
packages which are "Architecture: all" without relying on files /
directories that are only created if "Architecture: any" is built at the
same time.  In your case these are libcamitk3-data and libcamitk3-doc.
You should make sure that all files and dir you want to install do exist
when doing simply `dpkg-buildpackage -A` to build.  Since the tests
seem to be the problem you probably want to avoid the testing in this
case which should be done inside debian/rules by the statements:


# No tests needed for docs
override_dh_auto_test-indep:

# a selection of relevant tests
override_dh_auto_test:
        # Use the CamiTK test suite
        # Note: all tests require an X server, xvfb-run is needed to have a virtual one
        # Another way: xvfb-run --auto-servernum $(MAKE) -C camitk-build ARGS="-V" test
        (cd camitk-build && xvfb-run --auto-servernum ctest -V --timeout 600)


You just need to replace

  override_dh_auto_test:

by

  override_dh_auto_test-arch:

and you should be done.

> I tried to
> update d/rules to check if 3.5 can be packaged (at least in unstable), but,
> amthought it builds, there is a problem when loading the qt plugins that
> crashed any camitk application. I did not give it too much attention as the
> main idea is to let camitk3 RIP and move to 4.0.

That's perfectly fine.  Please just let your team know this. ;-)

> Do you think that waiting to see if the problem remains in 4.0 is a good
> idea? Or am I mistaken with my analysis?

The problem will vanish for any version if yoou append the missing '-arch'
string (untested - but I'm pretty sure).
 
> And last question: we noticed that VTK7 is out, do anyone knows if there are
> plans to package it, and if yes is there any targeted date for a package?

As far as I remember vtk maintainers will not undertake the migration from
vtk6 to vtk7 for the next stable release.

Kind regards

    Andreas.

-- 
http://fam-tille.de