Bug#742077: RFS: vcmi/0.95-1 [ITP]
Hi, Quoting Eriberto (2014-08-29 17:08:37) 2014-08-29 12:02 GMT-03:00 Paul Wise p...@debian.org: 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
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 2014-09-02 7:02 GMT-03:00 Johannes Schauer j.scha...@email.de: Hi, Quoting Eriberto (2014-08-29 17:08:37) 2014-08-29 12:02 GMT-03:00 Paul Wise p...@debian.org: 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
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/54038d81.4050...@bitmessage.ch http://lists.debian.org/54039338.7090...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
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) 2014-08-24 17:22 GMT-03:00 Johannes Schauer j.scha...@email.de: 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. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
Yes! Thanks. We need wait now. Cheers, Eriberto 2014-08-29 10:52 GMT-03:00 Johannes Schauer j.scha...@email.de: 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) 2014-08-24 17:22 GMT-03:00 Johannes Schauer j.scha...@email.de: 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. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
On Fri, Aug 29, 2014 at 6:52 AM, Johannes Schauer wrote: 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 -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
I thought about it too. This is the best option. Cheers, Eriberto 2014-08-29 12:02 GMT-03:00 Paul Wise p...@debian.org: Please ask vmci upstream to remove the embedded copy of fuzzylite and depend on the system version. https://wiki.debian.org/EmbeddedCodeCopies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
Hi, Quoting Paul Wise (2014-08-29 17:02:35) On Fri, Aug 29, 2014 at 6:52 AM, Johannes Schauer wrote: 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
On Fri, Aug 29, 2014 at 8:16 AM, Johannes Schauer wrote: 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 asked upstream whether they can remove the embedded copy and depend on the system version instead: http://bugs.vcmi.eu/view.php?id=1886 ... 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? 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
Hi, Quoting Paul Wise (2014-08-29 17:47:10) On Fri, Aug 29, 2014 at 8:16 AM, Johannes Schauer wrote: 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? 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 ... 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? Since it is not GPLv2+ compatible, that wouldn't solve the problem. Okay. Thank you for clarifying this. Perhaps fuzzylite upstream would be willing to apply the license change to 4.0 too? I sent off an email to ask about that. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
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/20140317153554.1302.95390@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
Hi Eriberto, Quoting Eriberto (2014-08-24 07:09:20) 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 :) 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. Yes. You can suggest to upstream to provide a GPG signature. I did: http://bugs.vcmi.eu/view.php?id=1883 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 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. 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. I suggest you to use this format (clean): Files: * Copyright: 2007-2014 Andrea Palmate and...@amigasoft.net Benjamin Gentner Frank Zago fr...@zago.net Ivan Savenko saven.i...@gmail.com Lukasz Wychrystenko t...@czlug.icis.pcz.pl Mateusz B. matc...@gmail.com Michał Urbańczyk imp...@gmail.com Rafal R. ambt...@wp.pl Rickard Westerlund onionkn...@gmail.com Stefan Pavlov mail...@gmail.com Tom Zielinski warmon...@vp.pl Trevor Standley Vadim Glazunov newea...@gmail.com Xiaomin Ding dingding...@gmail.com Yifeng Sun pkusunyif...@gmail.com License: GPL-2+ Okay, done. 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. 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 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? 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. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
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. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
2014-08-22 15:30 GMT-03:00 Johannes Schauer j.scha...@email.de: Hi Eriberto, Hi Johannes, Quoting Eriberto Mota (2014-08-19 14:29:34) 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. [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. 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 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! For vcmilauncher I wrote a custom man page in `debian/vcmilauncher.1`. Ok. Thanks. 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. 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. 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. And there is 'spelling-error-in-binary' which is a false positive as well. It is a classical Lintian override case. Right. Ok. 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. 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'. 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 and...@amigasoft.net Benjamin Gentner Frank Zago fr...@zago.net Ivan Savenko saven.i...@gmail.com Lukasz Wychrystenko t...@czlug.icis.pcz.pl Mateusz B. matc...@gmail.com Michał Urbańczyk imp...@gmail.com Rafal R. ambt...@wp.pl Rickard Westerlund onionkn...@gmail.com Stefan Pavlov mail...@gmail.com Tom Zielinski warmon...@vp.pl Trevor Standley Vadim Glazunov newea...@gmail.com Xiaomin Ding dingding...@gmail.com Yifeng Sun pkusunyif...@gmail.com License: GPL-2+ 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. 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. 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. 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? 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
Bug#742077: RFS: vcmi/0.95-1 [ITP]
Hi Eriberto, Quoting Eriberto Mota (2014-08-19 14:29:34) 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 :) 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 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`. 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? And there is 'spelling-error-in-binary' which is a false positive as well. It is a classical Lintian override case. Right. 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. I added a d/README.source. Does it contain everything you think it needs to contain? 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 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. 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. 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? 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. 6. Please, add a simple manpage to usr/games/vcmilauncher and usr/games/vcmiserver. Done. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
2014-08-18 12:47 GMT-03:00 Johannes Schauer j.scha...@email.de: Hi Eriberto, Hi Johannes. Thanks for your reply. Quoting Eriberto (2014-08-18 16:55:20) 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. 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 There is 'hardening-no-fortify-functions' which is a false positive. Ok, the same case of the GPG signature. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
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 2014-03-18 19:38 GMT-03:00 Johannes Schauer j.scha...@email.de: 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 imp...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140318223806.12867.34343.reportbug@hoothoot -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
Hi Eriberto, Quoting Eriberto (2014-08-18 16:55:20) 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
* Johannes Schauer j.scha...@email.de, 2014-03-18, 23:38: 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). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
* Johannes Schauer j.scha...@email.de, 2014-03-19, 06:31: [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. It seems that the AUTHORS file is not utf8 but either windows-1250 or iso-8859-2 Indeed. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
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 imp...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
[I don't intend to sponsor this package. Sorry!] * Johannes Schauer j.scha...@email.de, 2014-03-18, 23:38: Upstream Author : Micha³ Urbañczyk imp...@gmail.com and others We don't have ³ or ñ in the Polish alphabet. :-P It should be: Michał Urbańczyk. Please update debian/copyright accordingly. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742077: RFS: vcmi/0.95-1 [ITP]
Hi, Quoting Jakub Wilk (2014-03-18 23:58:19) [I don't intend to sponsor this package. Sorry!] dont worry, I'm happy for any help that can improve my packaging! :) 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
