Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Package: sponsorship-requests
Severity: wishlist

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "vcmi"

Package name : vcmi
Version : 0.95-1
Upstream Author : Micha³ Urbañczyk <***@gmail.com> and others
URL : http://forum.vcmi.eu/portal.php
License : GPL2+
Section : games

It builds those binary packages:

vcmi - Rewrite of the Heroes of Might and Magic 3 game engine
cmi-dbg - Debug symbols for vcmi package

To access further information about this package, please visit the following URL:

http://mentors.debian.net/package/vcmi

Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/v/vcmi/vcmi_0.95-1.dsc

VCMI is a free implementation of the Heroes of Might and Magic 3 game
engine as well as a platform for mods. VCMI is a turn-based strategy
game where the player controls a number of heroes commanding an army of
creatures. It extends the original capabilities of the game by
supporting maps of any size, greater display resolutions.

I'm also working on a project which allows to easily replace the proprietary
graphics of the original game by a free version at https://github.com/josch/lodextract

More information is available in the respective ITP bug#741640 which
includes some discussion on the debian-devel-games list.

cheers, josch

[Jakub Wilk]

[I don't intend to sponsor this package. Sorry!]
We don't have "³" or "ñ" in the Polish alphabet. :-P
It should be: Michał Urbańczyk.
Please update debian/copyright accordingly.

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-03-18 23:58:19)

Post by Jakub Wilk
[I don't intend to sponsor this package. Sorry!]

dont worry, I'm happy for any help that can improve my packaging! :)

Post by Jakub Wilk
We don't have "³" or "ñ" in the Polish alphabet. :-P It should be: Michał
Urbańczyk. Please update debian/copyright accordingly.

Oh awesome! That makes lots of sense! It seems that the AUTHORS file is not
utf8 but either windows-1250 or iso-8859-2

Thanks!

cheers, josch

[Jakub Wilk]

Post by Johannes Schauer

Post by Jakub Wilk
[I don't intend to sponsor this package. Sorry!]

dont worry, I'm happy for any help that can improve my packaging! :)

All right… :-P

I wouldn't repack the .orig.tar just to remove debian/. If you're using
the "3.0 (quilt)" format, dpkg-source removes upstream debian/ for you
at unpack time.

But if you choose to repack .orig.tar anyway, then please consider using
.xz for compression, to save a few megabytes. :-)

codespell(1) reports tons of typos. You might want to report them
upstream.

I didn't have patients to wait until cppcheck(1) completes, but it
reports at least:

[lib/CObjectHandler.h:898]: (style) Class 'IQuestObject' is unsafe, 'IQuestObject::quest' can leak by wrong usage.
[AI/FuzzyLite/FuzzyException.cpp:76]: (error) Dangerous usage of c_str(). The value returned by c_str() is invalid after this call.

Post by Johannes Schauer
It seems that the AUTHORS file is not utf8 but either windows-1250 or
iso-8859-2

Indeed.

[Jakub Wilk]

Post by Johannes Schauer
http://mentors.debian.net/debian/pool/main/v/vcmi/vcmi_0.95-1.dsc

Another remark:

I don't think that the “After installing this package, …” instructions
belong in the package description. I'd rather put them in README.Debian.

But if you decide to keep them, the enumerated list should be indented
by two spaces (see Policy §5.6.13).

[Johannes Schauer]

Hi Jakub,

Quoting Jakub Wilk (2014-03-23 20:11:17)

I don't think that the “After installing this package, …” instructions belong
in the package description. I'd rather put them in README.Debian.

Personally I didnt find myself reading README.Debian after package installation
very often. I read the package description much more regularly. Though I could
put a hint into the description that directs the user to README.Debian for
further instructions.

But if you decide to keep them, the enumerated list should be indented by two
spaces (see Policy §5.6.13).

A very useful read! Thanks, I wasnt aware of the description format other than
lines with a full stop.

I also investigated your other remarks and submitted solutions to them
upstream. Some of them are already fixed. Your comments also made me remember
https://wiki.debian.org/HowToPackageForDebian as a very helpful first stop.

I wouldn't repack the .orig.tar just to remove debian/. If you're using
the "3.0 (quilt)" format, dpkg-source removes upstream debian/ for you at
unpack time.

Ah, I didnt know that either, thanks! It seems that repacking the original
tarball is necessary nevertheless though because there is an osx directory
which contains some mac binaries. Upstream doesnt do the osx packaging and the
person who does didnt respond yet.

Thanks for your help!

cheers, josch

[Eriberto]

tags 742077 moreinfo
thanks


Hi Johannes,

I saw your package in mentors.debian.org and it has several Lintian messages.

IMHO, to get a sponsor you must, at least, clear your package removing
all possible messages.

PS: to improve your Lintian, please, see http://bit.ly/lintian

Regards,

Eriberto

Post by Johannes Schauer
Package: sponsorship-requests
Severity: wishlist
Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]
Dear mentors,
I am looking for a sponsor for my package "vcmi"
Package name : vcmi
Version : 0.95-1
URL : http://forum.vcmi.eu/portal.php
License : GPL2+
Section : games
vcmi - Rewrite of the Heroes of Might and Magic 3 game engine
cmi-dbg - Debug symbols for vcmi package
http://mentors.debian.net/package/vcmi
dget -x http://mentors.debian.net/debian/pool/main/v/vcmi/vcmi_0.95-1.dsc
VCMI is a free implementation of the Heroes of Might and Magic 3 game
engine as well as a platform for mods. VCMI is a turn-based strategy
game where the player controls a number of heroes commanding an army of
creatures. It extends the original capabilities of the game by
supporting maps of any size, greater display resolutions.
I'm also working on a project which allows to easily replace the proprietary
graphics of the original game by a free version at https://github.com/josch/lodextract
More information is available in the respective ITP bug#741640 which
includes some discussion on the debian-devel-games list.
cheers, josch
--

[Johannes Schauer]

Hi Eriberto,

Quoting Eriberto (2014-08-18 16:55:20)

Post by Eriberto
I saw your package in mentors.debian.org and it has several Lintian messages.
IMHO, to get a sponsor you must, at least, clear your package removing
all possible messages.

which Lintian messages are you referring to?

There is one pedantic warning 'debian-watch-may-check-gpg-signature' which I
cannot fulfill because upstream does not use gpg.

There is 'binary-without-manpage' which I could fulfill but that would be a
very empty man page because the game does not have any commandline options.

There is 'hardening-no-fortify-functions' which is a false positive.

And there is 'spelling-error-in-binary' which is a false positive as well.

cheers, josch

[Eriberto Mota]

Post by Johannes Schauer
Hi Eriberto,

Hi Johannes. Thanks for your reply.

Post by Johannes Schauer
Quoting Eriberto (2014-08-18 16:55:20)

Post by Eriberto
I saw your package in mentors.debian.org and it has several Lintian messages.
IMHO, to get a sponsor you must, at least, clear your package removing
all possible messages.

which Lintian messages are you referring to?
There is one pedantic warning 'debian-watch-may-check-gpg-signature' which I
cannot fulfill because upstream does not use gpg.

Yeap. So, I wrote 'removing all possible messages' because I thought about it.

Post by Johannes Schauer
There is 'binary-without-manpage' which I could fulfill but that would be a
very empty man page because the game does not have any commandline options.

I understand your POV. However, from Debian Policy[1]:

"Each program, utility, and function should have an associated manual
page included in the same package. It is suggested that all
configuration files also have a manual page included as well. Manual
pages for protocols and other auxiliary things are optional.

If no manual page is available, this is considered as a bug and should
be reported to the Debian Bug Tracking System (the maintainer of the
package is allowed to write this bug report themselves, if they so
desire). Do not close the bug report until a proper man page is
available."

I have some very long manpages and short manpages too. When an user
see a command but he don't know what is this, he always tries '$man
command' to get an explanation.

[1] https://www.debian.org/doc/debian-policy/ch-docs.html

Post by Johannes Schauer
There is 'hardening-no-fortify-functions' which is a false positive.

Ok, the same case of the GPG signature.

Post by Johannes Schauer
And there is 'spelling-error-in-binary' which is a false positive as well.

It is a classical Lintian override case.

In your package, please:

1. I suggest you add a d/README.source explaining why it is DFSG and
telling which files have been removed. I saw it in d/copyright but I
suggest a detailed README too.

2. d/copyright: I suggest put the range of years to 'Files: *'. Can be
a unique range for all authors (2007-2014). I think that there are
files with copyright not listed at d/copyright. I found
lib/minizip/mztools.h. You can use 'grep -sri copyright *' to see all
files.

3. d/docs: the README.linux is useless because a Debian final user
doesn't compile codes. Please, remove it.

4. A doubt: why you didn't make a separated package for shared libraries?

5. You need lintian overrides to 'I: vcmi: spelling-error-in-binary
usr/games/vcmilauncher tEH the' and to 'I: vcmi:
spelling-error-in-binary usr/lib/x86_64-linux-gnu/vcmi/libvcmi.so tEH
the'.

6. Please, add a simple manpage to usr/games/vcmilauncher and
usr/games/vcmiserver.

Thanks a lot for your work.

Regards,

Eriberto

[Johannes Schauer]

Hi Eriberto,

Quoting Eriberto Mota (2014-08-19 14:29:34)

Post by Eriberto Mota
Hi Johannes. Thanks for your reply.

sorry for my late reply but I was at the Debian Bootstrap sprint in Paris over
the weekend and am moving to Sweden tomorrow, so I'm a bit tight on free time
right now :)

Post by Eriberto Mota
"Each program, utility, and function should have an associated manual
page included in the same package. It is suggested that all
configuration files also have a manual page included as well. Manual
pages for protocols and other auxiliary things are optional.
If no manual page is available, this is considered as a bug and should
be reported to the Debian Bug Tracking System (the maintainer of the
package is allowed to write this bug report themselves, if they so
desire). Do not close the bug report until a proper man page is
available."
I have some very long manpages and short manpages too. When an user
see a command but he don't know what is this, he always tries '$man
command' to get an explanation.
[1] https://www.debian.org/doc/debian-policy/ch-docs.html

Thank you for elaborating on this and sorry for my dismissive last message. At
the time of writing I had just finished writing man pages for 43 applications
and at that point I couldn't see man pages anymore XD

I added a man page to vcmiserver by patching the program to do the commandline
parsing before other initialization which would fail if vcmi is not yet
installed. Then I use help2man to generate the man page like for the other
applications.

For vcmilauncher I wrote a custom man page in `debian/vcmilauncher.1`.

Post by Eriberto Mota

Post by Johannes Schauer
There is 'hardening-no-fortify-functions' which is a false positive.

Ok, the same case of the GPG signature.

I actually think they are different cases.

Checking for the GPG signature would be a pedantic warning that I would like to
receive every time I package a new upstream version because it reminds me to
check whether upstream still does not provide GPG signatures. If I override the
warning, then I will forget doing this.

Checking with blhc showed that the flags -fstack-protector and
--param=ssp-buffer-size=4 are not passed. But instead -fstack-protector-strong
is used. So things showd be fine, no?

Post by Eriberto Mota

Post by Johannes Schauer
And there is 'spelling-error-in-binary' which is a false positive as well.

It is a classical Lintian override case.

Right.

Post by Eriberto Mota
1. I suggest you add a d/README.source explaining why it is DFSG and telling
which files have been removed. I saw it in d/copyright but I suggest a
detailed README too.

I added a d/README.source. Does it contain everything you think it needs to
contain?

Post by Eriberto Mota
2. d/copyright: I suggest put the range of years to 'Files: *'. Can be a
unique range for all authors (2007-2014).

I figured out that the range 2002-2014 seems to be correct.

Post by Eriberto Mota
I think that there are files with copyright not listed at d/copyright. I
found lib/minizip/mztools.h. You can use 'grep -sri copyright *' to see all
files.

I added "Xavier Roche" as the author of lib/minizip/mztools.h and added further
sections for cmake_modules/cotire.cmake and cmake_modules/FindFFmpeg.cmake. I
hope I caught them all now.

Post by Eriberto Mota
3. d/docs: the README.linux is useless because a Debian final user doesn't
compile codes. Please, remove it.

That's right. I removed it.

Post by Eriberto Mota
4. A doubt: why you didn't make a separated package for shared libraries?

Upstream does not care about others using the shared library and will break ABI
and API with every release. The shared library is not intended to have any
users besides vcmi itself. There is a warning about this:

dpkg-shlibdeps: warning: can't extract name and version from library name 'libvcmi.so'

hat's why I put it in the vcmi subdirectory in /usr/share/<triplet>. Should the
library be put somewhere different in this case?

Post by Eriberto Mota
5. You need lintian overrides to 'I: vcmi: spelling-error-in-binary
usr/games/vcmilauncher tEH the' and to 'I: vcmi: spelling-error-in-binary
usr/lib/x86_64-linux-gnu/vcmi/libvcmi.so tEH the'.

I added those lintian overrides.

Post by Eriberto Mota
6. Please, add a simple manpage to usr/games/vcmilauncher and
usr/games/vcmiserver.

Done.

Post by Eriberto Mota
Thanks a lot for your work.

Thanks a lot for your feedback. It is very much appreciated!

I also refreshed the date in debian/changelog and uploaded the result to
mentors.

cheers, josch

[Dariusz Dwornikowski]

Hi Johannes,

Thanks for your work, but I think that your package should go to
contrib, because in order to work it needs HoMM game, so it depends on
something non free [1].

Installation instruction from upstream's web page clearly state that
you need to install Heroes data files [2]

I also found info on this game on Debian Games suggested games
website [3] stating the above.

I am CCing the Debian Games list too.

[1] https://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib
[2] http://wiki.vcmi.eu/index.php?title=Installation_on_Linux
[3] https://wiki.debian.org/Games/Suggested#VCMI
--
Dariusz Dwornikowski,
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. [phone]

[Eriberto]

Post by Johannes Schauer
Hi Eriberto,

Hi Johannes,

Post by Johannes Schauer
Quoting Eriberto Mota (2014-08-19 14:29:34)

Post by Eriberto Mota
Hi Johannes. Thanks for your reply.

sorry for my late reply but I was at the Debian Bootstrap sprint in Paris over
the weekend and am moving to Sweden tomorrow, so I'm a bit tight on free time
right now :)

No problem. The life is hard. I hope you enjoyed it.

Post by Johannes Schauer

Post by Eriberto Mota
[1] https://www.debian.org/doc/debian-policy/ch-docs.html

Thank you for elaborating on this and sorry for my dismissive last message.

Ok. I just want help you. If you let me do it I will be grateful.

Post by Johannes Schauer
At
the time of writing I had just finished writing man pages for 43 applications
and at that point I couldn't see man pages anymore XD

I understand you. A very hard work. Do you know txt2man?

Post by Johannes Schauer
I added a man page to vcmiserver by patching the program to do the commandline
parsing before other initialization which would fail if vcmi is not yet
installed. Then I use help2man to generate the man page like for the other
applications.

Good!

Post by Johannes Schauer
For vcmilauncher I wrote a custom man page in `debian/vcmilauncher.1`.

Ok. Thanks.

Post by Johannes Schauer

Post by Eriberto Mota

Post by Johannes Schauer
There is 'hardening-no-fortify-functions' which is a false positive.

Ok, the same case of the GPG signature.

I actually think they are different cases.
Checking for the GPG signature would be a pedantic warning that I would like to
receive every time I package a new upstream version because it reminds me to
check whether upstream still does not provide GPG signatures.

Yes. You can suggest to upstream to provide a GPG signature.

Post by Johannes Schauer
If I override the
warning, then I will forget doing this.

Maybe I was misunderstood. I think you shouldn't use an override here.
I don't use.

Post by Johannes Schauer
Checking with blhc showed that the flags -fstack-protector and
--param=ssp-buffer-size=4 are not passed. But instead -fstack-protector-strong
is used. So things showd be fine, no?

Not ideal but appears acceptable.

Post by Johannes Schauer

Post by Eriberto Mota

Post by Johannes Schauer
And there is 'spelling-error-in-binary' which is a false positive as well.

It is a classical Lintian override case.

Right.

Ok.

Post by Johannes Schauer

Post by Eriberto Mota
1. I suggest you add a d/README.source explaining why it is DFSG and telling
which files have been removed. I saw it in d/copyright but I suggest a
detailed README too.

I added a d/README.source. Does it contain everything you think it needs to
contain?

Yes. All right.

I found a problem in d/changelog. For the first upload, the priority
must be 'low'.

Post by Johannes Schauer

Post by Eriberto Mota
2. d/copyright: I suggest put the range of years to 'Files: *'. Can be a
unique range for all authors (2007-2014).

I figured out that the range 2002-2014 seems to be correct.

I didn't found 2002 in the upstream code. Can you point me this
information? You said about 2014 but wrote 2012 in d/copyright...

I suggest you to use this format (clean):

Files: *
Copyright:
2007-2014 Andrea Palmate <***@amigasoft.net>
Benjamin Gentner
Frank Zago <***@zago.net>
Ivan Savenko <***@gmail.com>
Lukasz Wychrystenko <***@czlug.icis.pcz.pl>
Mateusz B. <***@gmail.com>
Michał Urbańczyk <***@gmail.com>
Rafal R. <***@wp.pl>
Rickard Westerlund <***@gmail.com>
Stefan Pavlov <***@gmail.com>
Tom Zielinski <***@vp.pl>
Trevor Standley
Vadim Glazunov <***@gmail.com>
Xiaomin Ding <***@gmail.com>
Yifeng Sun <***@gmail.com>
License: GPL-2+

Post by Johannes Schauer

Post by Eriberto Mota
I think that there are files with copyright not listed at d/copyright. I
found lib/minizip/mztools.h. You can use 'grep -sri copyright *' to see all
files.

You put ' 2010 Juan Rada-Vilela' in last block. However, all files in
AI/FuzzyLite/ is under Apache 2. It is a problem. See
http://www.gnu.org/licenses/license-list.en.html#apache2 and
http://www.apache.org/licenses/GPL-compatibility.html. So, in current
stage, I think that the source code is undistributable.

Post by Johannes Schauer
I added "Xavier Roche" as the author of lib/minizip/mztools.h and added further
sections for cmake_modules/cotire.cmake and cmake_modules/FindFFmpeg.cmake. I
hope I caught them all now.

Post by Eriberto Mota
3. d/docs: the README.linux is useless because a Debian final user doesn't
compile codes. Please, remove it.

That's right. I removed it.

Post by Eriberto Mota
4. A doubt: why you didn't make a separated package for shared libraries?

Upstream does not care about others using the shared library and will break ABI
and API with every release. The shared library is not intended to have any
dpkg-shlibdeps: warning: can't extract name and version from library name 'libvcmi.so'
hat's why I put it in the vcmi subdirectory in /usr/share/<triplet>. Should the
library be put somewhere different in this case?

I think that it is another problem. I don't know a case of shared
libraries put outside */lib or packaged with a non lib code. You also
must consider the comment made by Dariusz.

Thanks for your work.

Cheers,

Eriberto

[Johannes Schauer]

Hi Eriberto,

Quoting Eriberto (2014-08-24 07:09:20)

Post by Eriberto

Post by Johannes Schauer
Thank you for elaborating on this and sorry for my dismissive last message.

Ok. I just want help you. If you let me do it I will be grateful.

your help is very much appreciated! My packaging can only get better with your
help :)

Post by Eriberto

Post by Johannes Schauer
At the time of writing I had just finished writing man pages for 43
applications and at that point I couldn't see man pages anymore XD

I understand you. A very hard work. Do you know txt2man?

I used pod2man.

Post by Eriberto
Yes. You can suggest to upstream to provide a GPG signature.

I did: http://bugs.vcmi.eu/view.php?id=1883

Post by Eriberto

Post by Johannes Schauer
Checking with blhc showed that the flags -fstack-protector and
--param=ssp-buffer-size=4 are not passed. But instead
-fstack-protector-strong is used. So things showd be fine, no?

Not ideal but appears acceptable.

Jakub Wilk suggested that my blhc version was outdated and indeed after
upgrading from the version in testing to the version from unstable, there are
no warnings at all with "blhc --all"

Post by Eriberto
I found a problem in d/changelog. For the first upload, the priority must be
'low'.

You probably mean urgency instead of priority?

I cannot find anything in the devref or policy that states this:

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Urgency
https://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog

Not that I don't trust you about it but if it is like that then there could
be:

- a devscripts bug against dch that `dch --new` defaults to urgency=low
(currently the default is urgency=medium which is how the value got there)
- a lintian warning if the first entry in debian/changelog is not urgency=low

I changed the urgency to low in debian/changelog.

Post by Eriberto

Post by Johannes Schauer

Post by Eriberto Mota
2. d/copyright: I suggest put the range of years to 'Files: *'. Can be a
unique range for all authors (2007-2014).

I figured out that the range 2002-2014 seems to be correct.

I didn't found 2002 in the upstream code. Can you point me this
information? You said about 2014 but wrote 2012 in d/copyright...

That's odd... I was sure I read 2002 somewhere but I cannot find it. The
upstream vcs has 2007 as the first commit date so I'll use that.

Post by Eriberto
Files: *
Benjamin Gentner
Trevor Standley
License: GPL-2+

Okay, done.

Post by Eriberto

Post by Johannes Schauer

Post by Eriberto Mota
I think that there are files with copyright not listed at d/copyright. I
found lib/minizip/mztools.h. You can use 'grep -sri copyright *' to see
all files.

You put ' 2010 Juan Rada-Vilela' in last block. However, all files in
AI/FuzzyLite/ is under Apache 2.

Correct. I created a new block for "Juan Rada-Vilela" and added Apache2.

Post by Eriberto
It is a problem. See http://www.gnu.org/licenses/license-list.en.html#apache2
and http://www.apache.org/licenses/GPL-compatibility.html. So, in current
stage, I think that the source code is undistributable.

But vcmi itself is GPL-2+ and both resources agreed that Apache2 is compatible
with GPL3. So could vcmi in Debian thus not be shipped as GPL3+ instead of
GPL2+?

I submitted the problem to the upstream bugtracker.

http://bugs.vcmi.eu/view.php?id=1884

Post by Eriberto

Post by Johannes Schauer
Upstream does not care about others using the shared library and will break
ABI and API with every release. The shared library is not intended to have
dpkg-shlibdeps: warning: can't extract name and version from library name 'libvcmi.so'
hat's why I put it in the vcmi subdirectory in /usr/share/<triplet>. Should the
library be put somewhere different in this case?

I think that it is another problem. I don't know a case of shared libraries
put outside */lib or packaged with a non lib code.

Well, as by FHS, /usr/lib seems to be the only place they could go, right? So I
cannot imagine where else they should be put.

Post by Eriberto
You also must consider the comment made by Dariusz.

I responded to that email separately, though strangely, vcmi still shows as
"Section: games" on mentors. That's probably a bug in the mentors.d.n web
interface?

I uploaded a new version of the vcmi package with the fixes from above.

Thanks!

cheers, josch

[Johannes Schauer]

Hi,

Quoting Eriberto (2014-08-29 17:08:37)

Please ask vmci upstream to remove the embedded copy of fuzzylite and
depend on the system version.
https://wiki.debian.org/EmbeddedCodeCopies

I thought about it too. This is the best option.

I started packaging fuzzylite 5.0 and found out that they do not offer
versioned SONAMES (I reported that and seven other bugs I found to fuzzylite
upstream).

At the same time I asked on debian-legal and it seems to be possible to
distribute vcmi (gpl2+) together with fuzzylite (apache2) because gpl2+ implies
gpl3 which is compatible with apache2.

So the only remaining problem seems to be the embedded copy of fuzzylite in
vcmi.

I agree that embedded copies are not nice but given the following:

- vcmi upstream uses an outdated copy of fuzzylite and is hesitating to
upgrade to 5.0 because of api changes
- fuzzylite upstream does not version their SONAME so it would be hard to
maintain it in Debian
- the fuzzylite version in vcmi contains their own set of patches which are
unknown because when fuzzylite was imported into their version control
system, their custom patches were already applied.
- nobody else in Debian uses fuzzylite

would letting vcmi include the embedded fuzzylite copy be an acceptable option
given the other tradeoffs?

cheers, josch

[Eriberto]

Hi Johannes,

vcmi (GPL-2+) with fuzzylite (Apache 2.0) can't be distributed from
upstream. It is the problem. IMHO, you can't make a -dfsg version
because the source code is 'improper', can't be distributed. But, if
the upstream distribute the source code without fuzzylite 4, then you
can package vcmi and fuzzylite 4 (you need use fuzzylite4 as name to
avoid an upgrade to 5). This is my idea.

What is your oppinion, Pabs?

Thank you for your willingness to make the package and contribute to Debian.

Cheers,

Eriberto

Post by Johannes Schauer
Hi,
Quoting Eriberto (2014-08-29 17:08:37)

Please ask vmci upstream to remove the embedded copy of fuzzylite and
depend on the system version.
https://wiki.debian.org/EmbeddedCodeCopies

I thought about it too. This is the best option.

I started packaging fuzzylite 5.0 and found out that they do not offer
versioned SONAMES (I reported that and seven other bugs I found to fuzzylite
upstream).
At the same time I asked on debian-legal and it seems to be possible to
distribute vcmi (gpl2+) together with fuzzylite (apache2) because gpl2+ implies
gpl3 which is compatible with apache2.
So the only remaining problem seems to be the embedded copy of fuzzylite in
vcmi.
- vcmi upstream uses an outdated copy of fuzzylite and is hesitating to
upgrade to 5.0 because of api changes
- fuzzylite upstream does not version their SONAME so it would be hard to
maintain it in Debian
- the fuzzylite version in vcmi contains their own set of patches which are
unknown because when fuzzylite was imported into their version control
system, their custom patches were already applied.
- nobody else in Debian uses fuzzylite
would letting vcmi include the embedded fuzzylite copy be an acceptable option
given the other tradeoffs?
cheers, josch

[Johannes Schauer]

Hi,

Quoting Eriberto (2014-09-02 13:52:11)

vcmi (GPL-2+) with fuzzylite (Apache 2.0) can't be distributed from upstream.
It is the problem. IMHO, you can't make a -dfsg version because the source
code is 'improper', can't be distributed.

These two emails suggest otherwise:

http://lists.debian.org/***@bitmessage.ch
http://lists.debian.org/***@debian.org

It can only not be distributed as (gpl2 and apache2) but since vcmi is gpl2+ it
can be distributed as (gpl3+ and apache2).

The vcmi authors let us freely choose which version of the gpl we want to
comply with by saying gpl2+. Since we cannot possible comply with gpl2 since it
conflicts with apache2, we choose to comply with gpl3 instead.

But, if the upstream distribute the source code without fuzzylite 4, then you
can package vcmi and fuzzylite 4 (you need use fuzzylite4 as name to avoid an
upgrade to 5). This is my idea.

The fuzzylite version used by vcmi predates fuzzylite version in its git
repository. Therefore, the fuzzylite version used by vcmi must be earlier than
fuzzylite 1.5.

I looked into how hard it is to port vcmi to fuzzylite 5.0 and it seems to be
quite an undertaking because fuzzylite did a number of major refactorings
between 1.5 and 5.0.

Packaging the fuzzylite version prior to 1.5 which vcmi uses seems the wrong
thing to do in my eyes because nobody else will use this outdated version.

What is your oppinion, Pabs?
Thank you for your willingness to make the package and contribute to Debian.

Thanks for mentoring me :)

cheers, josch

[Eriberto]

Yes! Thanks. We need wait now.

Cheers,

Eriberto

Hi,
iyou dropped the ITP bug as a recipient - was that intended?
In case it was I only quoted the small part below. I hope that's okay?
Quoting Eriberto (2014-08-25 16:01:36)

Post by Johannes Schauer
But vcmi itself is GPL-2+ and both resources agreed that Apache2 is compatible
with GPL3. So could vcmi in Debian thus not be shipped as GPL3+ instead of
GPL2+?

I think that no. You can ask about this issue in mentors. However, I
think that this code is, currently, undistributable. I already had a
similar case and the upstream wrote a new code to drop an reused GPLed
code. The software is Yara.

Post by Johannes Schauer
I submitted the problem to the upstream bugtracker.
http://bugs.vcmi.eu/view.php?id=1884

Ok. I hope you get a solution.

the upstream of fuzzylite relicensed from apache 2.0 to LGPL 3.0 with the
release of fuzzylite 5.0 (but not the versions prior to that). So if upstream
should upgrade their copy of the embedded fuzzylite, then the license problem
should go away.
cheers, josch

[Johannes Schauer]

Hi,

Quoting Paul Wise (2014-08-29 17:02:35)

the upstream of fuzzylite relicensed from apache 2.0 to LGPL 3.0 with the
release of fuzzylite 5.0 (but not the versions prior to that). So if
upstream should upgrade their copy of the embedded fuzzylite, then the
license problem should go away.

Please ask vmci upstream to remove the embedded copy of fuzzylite and
depend on the system version.
https://wiki.debian.org/EmbeddedCodeCopies

Would this solve the license incompatibility between fuzzylite (apache 2.0) and
vcmi (gpl2+)?

I asked upstream whether they can remove the embedded copy and depend on the
system version instead: http://bugs.vcmi.eu/view.php?id=1886

Currently, fuzzylite is not in Debian nor does any other software in Debian
carry an embedded copy of it (at least according to codesearch.d.n). This is
why I did not consider packaging fuzzylite separately yet.

But if it would solve the licensing problem, then I will certainly see if I can
get fuzzylite packaged.

A problem might be that vcmi as the only user of that library uses the old 4.0
version while upstream just released 5.0. Vcmi upstream expressed that
migration to fuzzylite 5.0 would be very troublesome here:
http://bugs.vcmi.eu/view.php?id=1884#c4932

Would it be okay to package fuzzylite 4.0 even though upstream is at 5.0?

cheers, josch

[Paul Wise]

Post by Johannes Schauer
Would this solve the license incompatibility between fuzzylite (apache 2.0) and
vcmi (gpl2+)?

Yes because the latest version (5.0) of fuzzylite (LGPLv3) is
compatible with vmci (GPLv2+).

Post by Johannes Schauer
I asked upstream whether they can remove the embedded copy and depend on the
system version instead: http://bugs.vcmi.eu/view.php?id=1886

...

Post by Johannes Schauer
A problem might be that vcmi as the only user of that library uses the old 4.0
version while upstream just released 5.0. Vcmi upstream expressed that
http://bugs.vcmi.eu/view.php?id=1884#c4932
Would it be okay to package fuzzylite 4.0 even though upstream is at 5.0?

Since it is not GPLv2+ compatible, that wouldn't solve the problem.

Perhaps fuzzylite upstream would be willing to apply the license
change to 4.0 too?

The code copy should be removed in any case, if that proves impossible
(perhaps it is patched), please contact the security team to report
the issue.
--
bye,
pabs

https://wiki.debian.org/PaulWise

[Johannes Schauer]

Hi,

Quoting Paul Wise (2014-08-29 17:47:10)

Post by Paul Wise

Post by Johannes Schauer
Would this solve the license incompatibility between fuzzylite (apache 2.0)
and vcmi (gpl2+)?

Yes because the latest version (5.0) of fuzzylite (LGPLv3) is
compatible with vmci (GPLv2+).

I'm confused. I asked whether removing fuzzylite from vcmi and making it a
shared library instead would solve the license incompatibility. I am aware that
using fuzzylite 5.0 will solve the issue but not using the embedded copy is a
different issue than upgrading the code to be compatible with version 5.0.

So the answer is: "No, but switching to 5.0 will"?

Post by Paul Wise

Post by Johannes Schauer
I asked upstream whether they can remove the embedded copy and depend on
the system version instead: http://bugs.vcmi.eu/view.php?id=1886

...

Post by Johannes Schauer
A problem might be that vcmi as the only user of that library uses the old 4.0
version while upstream just released 5.0. Vcmi upstream expressed that
http://bugs.vcmi.eu/view.php?id=1884#c4932
Would it be okay to package fuzzylite 4.0 even though upstream is at 5.0?

Since it is not GPLv2+ compatible, that wouldn't solve the problem.

Okay. Thank you for clarifying this.

Post by Paul Wise
Perhaps fuzzylite upstream would be willing to apply the license change to
4.0 too?

I sent off an email to ask about that.

Post by Paul Wise
The code copy should be removed in any case, if that proves impossible
(perhaps it is patched), please contact the security team to report the
issue.

It turns out that their embedded code copy is patched but I am in the process
of clarifying with upstream which parts they patched. Maybe no patching is
necessary anymore with fuzzylite 5.0 or maybe upstream can integrate their
patches into the 4.0 branch.

Thanks!

cheers, josch

[Johannes Schauer]

Hi,

Quoting Dariusz Dwornikowski (2014-08-23 11:04:09)

Thanks for your work, but I think that your package should go to contrib,
because in order to work it needs HoMM game, so it depends on something non
free [1].
Installation instruction from upstream's web page clearly state that
you need to install Heroes data files [2]
I also found info on this game on Debian Games suggested games
website [3] stating the above.
I am CCing the Debian Games list too.

you are right, vcmi is a classical case for a game in contrib as its assets
(graphics, music, sounds, text) are non-free. That debian/control said it was
for "main" is an artifact from when I started packaging it. I developed a tool
with which I made it possible to play the game with colorful rectangle graphics
instead of the original sprites. Here is the email thread about this:

http://lists.debian.org/***@hoothoot

While this makes the game playable, upstream disliked that their engine could
be abused in such a way so I stopped doing this. Thus I changed the Section to
contrib/games now. Thanks for noticing this!

cheers, josch