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

Thu Mar 31 07:48:31 UTC 2016

Hello Andreas (and everyone!)

The new version of CamiTK (4.0.0) was just release yesterday. It is now 
based on up-to-date Qt, VTK, ITK, gdcm and cmake, which should fix a lot 
of the bug and current problems. We are switching to git to manage the 
upstream version.

I was wondering how to proceed for the packaging. Andreas mentioned that 
it would be possible to switch to git as well. Or I think he mentioned 
that, but I am not sure (see my post [1]).

Any advice welcome!

Mahnu

[1] 
http://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-March/040535.html 
(and below)

On 23/03/16 18:53, Emmanuel Promayon wrote:
> 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/20160331/594c14ff/attachment.bin>