Bug#742077: RFS: vcmi/0.95-1 [ITP]
2014-08-22 15:30 GMT-03:00 Johannes Schauer <j.schauer@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 <andrea@amigasoft.net>
Benjamin Gentner
Frank Zago <frank@zago.net>
Ivan Savenko <saven.ivan@gmail.com>
Lukasz Wychrystenko <t0@czlug.icis.pcz.pl>
Mateusz B. <matcio1@gmail.com>
Michał Urbańczyk <impono@gmail.com>
Rafal R. <ambtrip@wp.pl>
Rickard Westerlund <onionknigh@gmail.com>
Stefan Pavlov <mailste@gmail.com>
Tom Zielinski <Warmonger@vp.pl>
Trevor Standley
Vadim Glazunov <neweagle@gmail.com>
Xiaomin Ding <dingding303@gmail.com>
Yifeng Sun <pkusunyifeng@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
must consider the comment made by Dariusz.
Thanks for your work.
Cheers,
Eriberto
Reply to: