Rebuildability of various binaries and shipped libraries for Debian packaging

[Obey Arthur Liu]

Hi,

I have a few more licensing issues to clarify.

kupu/sarissa : appsrc/ODS-Wiki/kupu/common
The LICENSE file is not present.

binsrc/oat/toolkit
The LICENSE file is not present and several files have dubious
licensing status. For example webclip.js is licensed under CC
Attribution-ShareAlike 2.5, which is not DFSG compliant and ymapapi.js
which has no licensing at all.

binsrc/samples/schemaview/xmlsource/schema/README.html:
This doesn't appear to be clearly free.

binsrc/ws/wsrm/policy.xsd:
Same as above but doesn't seem to be used.

binsrc/yacutia/ie7/:
cc-by-2.0 is not DFSG compliant, but current upstream licenses with
MIT so it should be fixable

docsrc/stylesheets/docbook
This is 4clause bsd which is non-dfsg.

libsrc/Wi/sha.h is not DFSG compliant, but doesn't seem to be used.

Cheers

Arthur

On Tue, Dec 29, 2009 at 1:19 PM, Obey Arthur Liu <arthur at milliways.fr> wrote:
> Hi,
>
> I'm continuing the work on various aspects of the debian virtuoso
> packages and I have a few new issues I'd need your help on.
> The following refers to the 20091210 6.0.1-rc1 tarball.
>
> PCRE
> ====
> libsrc/util/pcrelib/
> Virtuoso ships and links to a modified version of PCRE 7.9 (with some
> additional debugging features). I tested it and vanilla PCRE 7.8 (the
> most recent version in Debian) works fine. Could you add a build
> option to use the system version instead, like you did for zlib?
>
> Tidy
> ====
> libsrc/Tidy
> Virtuoso ships, links to and re-exports an obsolete version of the
> Tidy library. There seems to be some switchable code to accommodate
> the different API of the newer Tidy but since its interface is
> re-exported, the switch doesn't seem that simple. Can you look into
> this? While Tidy seems to be less security-critical than zlib or pcre,
> it's always better to rely on system libraries.
>
> Tutorial VAD
> ============
> binsrc/tutorial
> The tutorial VAD ships numerous pre-built mono .dlls that can't be
> rebuilt (or I haven't figured out how). How can I rebuild them from
> source ? The .net virtuoso client in binsrc/VirtuosoClient.Net builds
> fine with mono.
>
> All JARs
> ========
> *.jar
> Virtuoso ships numerous pre-built java .jars built on source that is
> not included in the tarball. README.sesame2/3 and README.jena explain
> that the user has to get them manually. Because they are BSD-licensed,
> you are allowed to do this but this won't work for the Debian archive.
> Could you look into the possibility of using system installed versions
> of sesame, jena, slf4j... directly into the build system? Otherwise
> I'll have to patch one into the source code and I'll rather have you
> decide how you prefer to do it.
> Note that sesame and jena are not in Debian yet (but slf4j is, so you
> can try it with that) but I'm considering packaging them.
>
> Parallel building
> =================
> I still have trouble with parallel building (make -j). It works better
> now, but still not all the time. I attached a patch
> (build-generated-code-multiple-outputs.patch) that solves one point of
> failure for me, there are still many more.
>
> Use of gmake
> ============
> There are a few uses of 'gmake' in makefiles. gmake is not present in
> Debian. $(MAKE) should be used instead.
>
> That's all for now.
>
> Cheers
>
> Arthur
>