[Debian-med-packaging] FW4SPL package

Thu Nov 24 08:30:02 UTC 2016

Le 23/11/2016 à 15:08, Andreas Tille a écrit :
> Hi Flavien,
> 
> On Wed, Nov 23, 2016 at 12:40:17PM +0100, Flavien Bridault wrote:
>> Thanks again for your valuable help. I finally succeeded to build the
>> camp and fw4spl packages. For fw4spl there is a big version bump, since
>> I updated to 0.11.0.2. A major part of the patches in the previous
>> packages were already fixed in this branch. So I removed some patches
>> and updated other ones.
> 
> Sounds quite promising.
>  
>> Though, I have few questions left.
>>
>> 1. I noticed in history that Corentin restricted fw4spl to "amd64" for a
>> while and then he switched to "all". I think he was wrong and wanted to
>> switch to "any" instead, am I correct ?
> 
> Yes, "any" is the correct architecture field.
> 
>> Then honestly, I can't ensure
>> that fw4spl can compile and work on other architectures since we never
>> tested it (we have an android build, so with arm, but it works with a
>> complete different toolchain build). So I feel a bit embarrassed by
>> letting this flag to "any" and then pray for the build to succeed. So I
>> would argue to restrict to amd64. Do you have any advice ?
> 
> In principle it is correct to leave any.  Autobuilders will grab the
> code and try to build - if the build fails there will be no package
> created.  Sometimes you get patches from porters to make it build which
> could be of some value for you as upstream.  A bad thing would be if
> the package builds on some architecture but the resulting package just
> does not work.  So some sensible test suite should be run (as well at
> runtime - currently the test is disabled which is also not good - as
> as autopkgtest for the installable package).

Ok so that's probably a next step, I have to figure out how to run the
tests, for now I only verified that the vrrender application works
correctly.

> 
>> 2. Lintian reports me some errors in fw4spl for each of the libraries we
>> put in share/ :
>>
>> E: fw4spl: arch-dependent-file-in-usr-share
>> usr/share/fw4spl/activities_0-1/libactivities_0-1.so.0.1
>>
>> I guess that this is because we are not supposed to put binaries in
>> /usr/share.
> 
> Yes.  This belongs to /usr/lib/fw4spl.
> 
>> However this is an annoying case for us because we use the
>> concept of "Bundles" that can be loaded at runtime, and inside these
>> bundles, there is a mix of binaries and resource files. We could
>> consider to split libraries and resources that so that instead of having
>> this :
>>
>> /usr/share/fw4spl/activities_0-1
>> activities.xsd
>> libactivities_0-1.so
>> libactivities_0-1.so.0
>> libactivities_0-1.so.0.1
>> plugin.xml
>>
>> we would have:
>>
>> /usr/lib/fw4spl/activities_0-1
>> libactivities_0-1.so
>> libactivities_0-1.so.0
>> libactivities_0-1.so.0.1
>>
>> /usr/share/fw4spl/activities_0-1
>> activities.xsd
>> plugin.xml
> 
> Why not simply putting xsd and xml in /usr/lib as well.  Its not
> mandatary that architecture indpendent files need to go to /usr/share -
> but architecture dependant files need to go to /usr/lib per policy (and
> FHS). 
> 
>> But this demand us to modify deeply our bundle loading code to support
>> this. This is feasible, but maybe not immediately. Do you think the
>> current situation is acceptable ?
> 
> Definitely not - simply move everything to /usr/lib.  If for some reason
> some files need to reside in /usr/share you can use symlinks.
>  

Ok thanks for the clarification, some at IRCAD thought it was in
/usr/share, there was a misunderstanding somewhere. :) Hopefully this
was quite easy to switch to /usr/lib. That's why I just pushed this morning.

>>
>> 3. I have the following lintian error:
>> E: fw4spl source: source-is-missing
>> Apps/VRRender/doc/source/_static/jquery.js line length is 694 characters
>> (>512)
>>
>> This file is present in the source but not used in the final package,
>> shall I put it in "debian/missing-sources" ?
> 
> I'm not sure whether I understand the issue correctly.  It would be
> easier to give advise if you would commit your current status to Git.
> As far as I can see the best idea would be to rather Depend from package
> libjs-jquery and use symlinks to the system provided jquery.  Except
> there are very good reasons to use your own code copy I'd recommend to
> do this.
>  
>> 4. I have not tackled the reopening of the bugs, could you please
>> confirm that I have to do that through the mailing-list and then mention
>> the bugs in the debian/changelog to close them ?
> 
> I admit I'm not sure if the bugs can be reopened for a not (yet)
> existing package.  For simplicity I think its sufficient to add
> 
>    Closes: #bugnumber, #bugnumber
> 
> in debian/changelog for documentation reasons.  If the upload is
> closing the bug and the bug was closed before that's OK IMHO.
>  

Ok so I mentioned all the fixed bugs in the changelog, but I still have
one opened about dbus-x11 :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836094

I'm not sure what to do there, should I reopen the bug to discuss about
the fix on the correct channel ?

>> 5. Depending on your answer on the previous points, can I push my
>> modifications on camp and fw4spl repos ?
> 
> Yes, please do in any case.  May be my answers would be even better. :-)
>  
>> Thanks a lot for your time and your advice. :)
> 
> Thanks to you for your cooperation
> 
>        Andreas.
> 

That's pushed !

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20161124/15916d9e/attachment.sig>