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 must consider the comment made by Dariusz. Thanks for your work. Cheers, Eriberto -- 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/cap+dxjfrvun2xtunx1khhjugeshi_pb1z_uwmxdi2msyc_+...@mail.gmail.com
