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

Wed Mar 23 17:53:31 UTC 2016

Dear Andreas,

I remove the bug report in CC (I posted separate smaller more focused 
messages to each of them)

On 21/03/16 09:18, Andreas Tille wrote:
> 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.
Hopefully everything is going to go according to plan!
>> 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. :-)
See my question and answer below about moving to git for packaging.

>> 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.
Migration to VTK6 implies migration to Qt5 which is not completely 
straightforward. But yes, it is on its way upstream!

>> - 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.
>   
Sorry about that, I am not very good with dealing with the BTS. I will 
try to be better from now on. I have tagged "pending" all the bugs that 
will be closed in the next release.

>> 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.

If I understand well, you advice is to:
- keep only one camitk package (named camitk)
- move it to git
- when 4.0 is ready upstream, update the debian/* files

If yes, that sounds perfect to me. I will indeed have to follow a 
learning curve for git (but using it both upstream and for packaging 
makes perfect sense).
I just commit on svn the last changes that I made locally to check the 
state of 3.5.0 out of the box (this was not very conclusive as I got a 
segfault when loading Qt Plugins, but not to linger on as we will have 
4.0 soon that should be better).
You can move the package repository to git, when you want/can.

>   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.

I don't think a backport is really needed in our case. We prefer to 
spent more energy on having a more stable version 4.x in stretch.

>> - 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.

Thank you, now I understand this bug report.
I applied your patch to debian/rules and marked the bug pending too!
>> 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. ;-)
Yes. Agreed. I will try my best to be better at communicating...

>> 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).
>   
OK. Thanks for the explanation.

>> 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.
>
OK. Lets face one move at a time then!

Kind regards,
Emmanuel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160323/b7430b5d/attachment-0001.bin>