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 <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+
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
Reply to: