[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: leechcraft (closes ITP bug, 33 days have passed)

While I think this package is interesting, I do not intend to sponsor it.

That said, here is a review of the source package:

I'm not sure it is appropriate to change the ABI names used by
upstream to a Debian-specific one. If you want to change the library
names that should be done upstream.

Please talk to upstream about how to make your patches unnecessary.

Please add DEP-3 headers to your patches:


qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox,
hunspell/myspell (and anything else in 3rdparty or third-party dirs)
are either already in Debian or should be packaged separately, you
should not include them in the binary package or tarball.

Some of the icons were created in Inkscape but the source code (SVG
files) is missing.

There are some pre-compressed audio files, I guess the preferred form
for modification for those is missing and therefore we cannot
distribute them since they are probably GPL licensed. In addition
there is DFSG item 2.

Your version number and your debian/rules get-orig-source do not
indicate the reason for the tarball repacking.

You can use wildcards in .install files like these:


Some of the files have the incorrect FSF address in them, you might
want to report that upstream.

P: leechcraft source: unversioned-copyright-format-uri

There are some .DS_Store files in the tarball, these are a waste of
space, you might want to ask upstream to remove them.

cppcheck finds some issues:

qxmpp/src/QXmppTransferManager.cpp:423]: (error) Memory leak: buffer
(error) Possible null pointer dereference: entry - otherwise it is
redundant to check if entry is null at line 53
[src/plugins/bittorrent/tabwidget.cpp:705]: (error) instance of
"Applier" object destroyed immediately
[src/plugins/bittorrent/tabwidget.cpp:715]: (error) instance of
"Applier" object destroyed immediately
[src/plugins/eiskaltdcpp/dcpp/PerFolderLimit.cpp:92]: (error) Possible
null pointer dereference: message - otherwise it is redundant to check
if message is null at line 84
I stopped it that this point but there might be more issues.



Reply to: