On 01/10/2015 08:47 PM, Friedrich W. H. Kossebau wrote:
Am Sonntag, 4. Januar 2015, 20:24:26 schrieb Jos van den Oever:
On 01/04/2015 07:43 PM, Friedrich W. H. Kossebau wrote:
thanks for the quick and workloaden reaction, great :)
It was some needed work. Happy to help.
Am Sonntag, 4. Januar 2015, 17:06:26 schrieb Jos van den Oever:
On Sunday 04 January 2015 02:04:09 Friedrich W. H. Kossebau wrote:
Am Donnerstag, 23. Oktober 2014, 23:17:48 schrieb Raúl Sánchez Siles:
Java jar files
==============
jar files are binary files, as such, in Debian we need the source code
of
those files and generate them on package build (or removing the files
from
the tarball and adding dependencies on the packages that provide these
files).
In the jar case, there are some pointers on where the jar comes from,
but
still bundling a generated binary is not desirable.
The fixes for that from the licensing point of view are:
- Removing the feature
- If the jar generates code needed at build time, adding the required
(source) files which are generated from the jar. But not the jar. Also
include a script or document a procedure how to get those files.
- If the jar is required as a runtime dependency, you could either add
a
run time dependency on a separate package providing that jar or
generate
the jar at build time.
filters/libmso/generated/mso.jar
As per README in that directory this jar generates some code that's
used
later.
PROPOSAL: Describe (or script) the procedure to generate the code and
remove the jar file.
The README refers to http://www.gitorious.org/msoscheme as the source of
mso.jar. Which still exists (good) and seems to be basically done by
you,
Jos, once upon a time at least. Just, there is no README there and,
worse,
also no obvious license for msoscheme.
And for recursive fun for the good Debian License checking people there
is
another binary blob inside those sources, from poi.apache.org ;)
I've added a Readme.md with license information for MSOScheme and POI to
the repository of MSOscheme now.
https://www.gitorious.org/msoscheme/msoscheme/
The POI code is only there for testing the generated java code. This is
not
used by Calligra at all.
I have updated MSOScheme: it now writes the version of MSOScheme into the
generated files. The version contains the sha1. So it is always possible
to
find the exact version of MSOScheme to recreate the files simpleParser.h
and simpleParser.cpp. This means the mso.jar does not need to be part of
the Calligra source code any more.
I put up a review request to add the better documentation to calligra.
https://git.reviewboard.kde.org/r/121837/
If the mso.jar should not be part of the Calligra repository, then it
should be replaced by mso.xml.
Hm. Usually a repo contains only sources, and all tools needed for creating
products from those sources are outside the repo. At least those shared with
others. rng2cpp is an example where the tool is inside the Calligra repo (are
there more like that here?).
mso.xml could be considered the real source of the generated files which are
then used by Calligra. Just, those files (in theory) could be useful to other
projects as well. So mso.xml is currently not really specific to Calligra (and
thus also not a Calligra source). And the created files simpleParser.{h,cpp}
are also not Calligra-specific.
In a perfect world there would be some package which installs simpleParser.a
and simpleParser.h & leinputstream.h, and Calligra would require that package
and use it during build-time.
Instead, for convenience, we have copies of the intermediate products in the
Calligra repo.
So to make Debian happy, we possibly could add a switch to not use the
convenience-copies in the Calligra repo, but require some msosimpleparser
package and compile and link against that. A package which would be created
from running msoscheme and installing those files.
Such a package might perhaps also make it more interesting to use for others,
BTW. Would be willing to assist any needed work.
I disagree that packaging msoscheme is useful. Currently only Calligra
uses msoscheme and I do not expect that to change. MSOSchem could be
useful to projects like Document Liberation. But also there, they would
probably prefer to simply copy the two files.
MSOScheme encourages writing a custom code generator. So the files
generated would often be different, optimized for each project.
Have not yet looked in detail, but already impressed :)
One things though still bugs me: there is no released version of
msoscheme,
right? So when gitorious disappears one day (hopefully not) and you have
turned evil (more hopefully not), is there any other location where the
sources of msoscheme might be around? If there would be a release, and at
least Debian picks the tarball up for generating mso.jar as it seems they
want to instead of relying on the spyware-loaden^Wfree binary blob there
is in Calligra repo, chances are higher someone one day could pick up and
continue work on msoscheme.
So could you perhaps tag the version used for the current mso.jar with a
release version, for some more official statement? Not sure the commit id
is nice enough as a reference, as it binds to git as version system.
I've now tagged a new/first release: 1.0.0.
The code can be downloaded here:
https://www.gitorious.org/msoscheme/msoscheme/archive/1.0.0.tar.gz
The version number that is embedded in the generated files is now:
1.0.0-0-g8c6d5941f11a7667b0f915b0e94ef72eb8c42938
This is generated by git:
git describe --abbrev=40 --always --long --dirty --tags
(The arguments are sorted for maximum comic effect.)
;) K, thanks, that might be really sufficient (not knowing Debian's rules,
though :P ).
I'm fine with mirroring this on kde. Everyone is welcome to clone the
repo of course.
(Cloning only still has the danger of missing updates)
Given that msoscheme has not yet seen and Calligra is the only user, it might
make sense to host it closer to Calligra. Not sure about the real benefits,
besides only dying together with Calligra repo in case of KDE goes /dev/null.
Any 3rd-party ever shown interest? (hm, the mso.xsd still might be interesting
to look at for some old WIP project for the Structures tool in Okteta, you
might remember a discussion, but unrelated to central repo location),
Yes, MSOScheme is, despite the name, not specific to binary microsoft
office files. It would be great if it grows into a general grammar for
binary files.
In the recent past Matus Uzak and Brijesh Patel have worked on mso.xml,
so the bus factor is > 1.
Ah, good.
/me removes bus rerouting rules based on jos' phone coordinates
Cheers,
Jos
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
