Bug#738683: RFS: hexchat/2.9.6.1-1 [ITP]
On Mon, Feb 17, 2014 at 11:41 AM, Jesse Rhodes <drubo@drubo.net> wrote:
> On Mon, Feb 17, 2014 at 1:19 AM, Vincent Cheng <vcheng@debian.org> wrote:
>> Control: tag -1 + moreinfo
>>
>> On Tue, Feb 11, 2014 at 2:43 PM, sney <drubo@drubo.net> wrote:
>>> Package: sponsorship-requests
>>> Severity: wishlist
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for my package "hexchat"
>>
>> Comments:
>>
>> - debian/copyright is incomplete: e.g.
>> src/dirent/dirent-win32.h: Toni Ronkko, Expat
>> intl/*.{c,h}: Free Software Foundation, Inc., LGPL-2.1+
>>
>> I find licensecheck (from devscripts) to be a very useful tool to dig
>> through license headers in each file. Of course, it's not perfect, so
>> you still have to do some manual work. Anyways, there may be more
>> undocumented license headers, I just gave a few examples above.
>
> There were several. All done now, I'm 99% sure.
Another issue with the licensing that I neglected to mention in my
last email is the fact that you claim in d/copyright that the source
is licensed under GPL + openssl exception, but I cannot find any
mention of this within the source tarball (there is no COPYING/LICENSE
file in the top-level directory, and none of the GPL headers in the
source files acknowledge the openssl linking exception). This needs to
be documented somewhere in the source tarball itself.
Can you ask upstream to release a new tarball with either a top-level
COPYING file (like what is currently in their github repo, except it
doesn't acknowledge the openssl exception either...ask them to fix
that too), and/or to add the openssl exception to their per-file
license headers?
(FWIW I don't think ftpmasters will let hexchat through the NEW queue
without the above being fixed, so consider this a blocker for an
upload.)
>> - debian/control:
>>
>> Package: hexchat-common
>> Architecture: all
>> Recommends: xchat
>>
>> ^ shouldn't that be "hexchat"?
>
> Oops. Done.
This is somewhat pedantic, but can you move the Recommends: line just
below the Depends: line (like it was before), and not after the long
description?
>> Also, please consider using "wrap-and-sort -s" to sort your
>> build-depends and depends field alphabetically and one per line; it
>> makes reviewing diffs to debian/control much easier to read later on.
>
> Done.
>
>> - debian/changelog: collapse all unreleased entries into a single
>> entry (i.e. just retain your 2.9.6.1-1 entry and delete everything
>> else)
>
> Done.
>
>> - debian/paste.txt: remove this
>
> And done.
>
>
> Let me know if there's anything else.
- Documentation should be rebuilt during the build process with doxygen.
- Lintian complains about hardening-no-fortify-functions, but your
build is non-verbose (so you can't actually see if the source is
compiled with -D_FORTIFY_SOURCE=2 in the build log). You can enable
verbose build with autotools using "--disable-silent-rules", e.g.
override_dh_auto_configure:
dh_auto_configure -- --disable-silent-rules
That brings me to another point; why not use override_dh_* targets
instead of defining build: and misc: like you're doing now in d/rules?
- debian/watch can be made more robust if you check for other possible
filenames, e.g.
http://dl.hexchat.net/hexchat/hexchat-(.*)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
Regards,
Vincent
Reply to: