Pushing Open Sankore into Wheezy...

[Miriam Ruiz]

2012/6/12 Mike Gabriel <mike.gabriel at das-netzwerkteam.de>:
> Hi Miriam,

Hi!

>> W: sankore-data: duplicate-font-file usr/share/open-sankore/customizations
>> /fonts/Andika-R.ttf also in fonts-sil-andika
>
> What shall I do with the duplicate-font-file? Simply drop it? Never had such
> a case.

My proposal is to add a dependency on fonts-sil-andika, and replace
the file by a symlink to the fonts file included in that package.

>> W: sankore-data: embedded-javascript-library
>> usr/share/open-sankore/library
>> /applications/Edit Html.wgt/jquery.pack.js
>> W: sankore-data: embedded-javascript-library
>> usr/share/open-sankore/library>
>> /applications/Nuancier.wgt/js/jquery.js
>> W: sankore-data: embedded-javascript-library
>> usr/share/open-sankore/library
>> /applications/Wikipedia.wgt/script/jquery.min.js
>> W: sankore-data: embedded-javascript-library
>> usr/share/open-sankore/library
>> /applications/Wiktionnaire.wgt/script/jquery.min.js
>
> What do you reckon... is it save to drop these and symlink to jquery.js in
> libjs-jquery & co?

I'd leave them as they are, just in case. I'm not sure if replacing
them with a symlink is gonna be safe, especially regarding future
evolution of the packages. Thoughts?

>> W: sankore-data: script-not-executable usr/share/open-sankore/linux/run.sh
>
> For this I placed a lintian-override into the package. Another option can be
> to remove it again after dh_install is through. Comment?

Well, either remove it (if it is not needed) or set mode +x so that
the script is executable, if it needs to be :)

>> W: sankore: hardening-no-fortify-functions
>> usr/lib/open-sankore/x86_64-linux-
>> gnu/libCFF_Adaptor.so.1
>> W: sankore: hardening-no-fortify-functions
>> usr/lib/open-sankore/x86_64-linux-
>> gnu/libCFF_Adaptor.so.1.0
>> W: sankore: hardening-no-fortify-functions
>> usr/lib/open-sankore/x86_64-linux-
>> gnu/libCFF_Adaptor.so.1.0.0
>
> Bart Martens and others currently recommended to leave these untouched (if
> we are sure the build flags have been hardened, which they have).

Yup, I agree

>> E: sankore: possible-gpl-code-linked-with-openssl
>
> Normally, we need a statement from (sankore) upstream here that it is ok to
> link sankore (GPL) against openssl (OpenSSL/SSLeay license). This license
> has to be placed in /debian/copyright. Do we have such a statement?

This is the toughest one. No, as far as I know, we don't have that
statement yet, so we should get in contact with them and politely ask
them about it. That's the best possible solution.

>> W: sankore: binary-without-manpage usr/bin/Open-Sankore
>
> I will put a dummy man page into the package. I guess we do not have any
> known cmdline options...

Well, at least a man page that briefly describe what the binary is
about, without having to run it to find out, is in my opinion enough.
Thanks :)

>> Finished running lintian.
>
> :-)
>
> Mike

Cool!!

The only big point we have to fix is the GPL - SSL stuff. The rest are
easy to fix, or can be safely ignored (IMHO). We should get in contact
with upstream, explain clearly and briefly the problem, suggest them
what I think is the best and easiest solution (the statement allowing
us to link it against SSL), and hope they will be helpful enough to do
it. Do you want to send them an email, do you prefer me to do it, or
does anyone else volunteers? :)

Greetings and lots of thanks,
Miry