After a nice meal I now have some comments on your packaging:

First of all: Please package using git-buildpackage and upload to the pkg-multimedia repository - more info here:

When you have switched to Git, then add Vcs-Git and Vcs-Browser stanzas to the control file.

Set the Multimedia team as Maintainer and yourself as Uploader (yeah, technically you cannot upload, but in this team we use that field as a hint of whom is mainly working on the package).

Long descriptions should be line-wrapped at 72 chars.

Avoid stray spaces at end of lines (noticed in long description, but should be avoided everywhere).

Your Suggests: seem odd: do the project really make direct use of those tools? If it is just that you happen to find those tools nice to have installed on same hosts as you use this project, then I suspect they should simply be dropped, or alternatively (but I find it a bad style) in a separate metapackage depending on the actual project package and those add-ons that you find relevant to have installed together.

There are no packages in Debian named linux-rt or linux-headers-rt. Please package for Debian, and then secondary - if needed - adjust for derived distributions like Ubuntu using alternative Git branches.

You have some commented out dependency lines in the control file. It works, but is bad style IMO. When using CDBS, you can instead declare dependencies in the rules file, allowing both commenting out, grouping of relations with added explanatory comments, and conditional relations (e.g. arch-dependent or when compiling with a certain build flag set). See e.g. the morituri package for an example of this.

Please use recursively expanded variables in the rules file whenever possible. That is, instead of := use = which mean the content gets resolved when used rather than when read by make. In most cases there are no differences but in some cases there are, which can cause surprises if unaware of the differences.

It is bad style to invoke dh_install again (in addition to the included snippet). Instead either add a debian/scenic.install file, or set DEB_DH_INSTALL_ARGS.

Are you sure you need to build-depend on bash-completion?

The binary package is arch: any, but the checks for linux/videodev2.h which I suspect means that the package will only succesfully compile on Linux architectures. If correct, then the best would probably be to fix it upstream to avoid Linux-specific parts when on non-linux archs, or alternatively to tighten to package only on Linux archs.

Either json or simplejson is used upstream. Are you aware that those implementations are not fully interchangeable (one of them - I forgot which - do not follow JSON specs!), and they might be slow too? The Sugar project switched to python-cjson for these reasons.

It seems some subprojects provide regression tests. If usable then please enable them. Most elegant approach - if workable - is to set DEB_MAKE_CHECK_TARGET = check .

Have a look at e.g. morituri package for some modern CDBS enhancements - like upstream tarball processing, and copyright and licensing tracking.

Please don't hesitate to ask if any of this is not clear to understand for you.

Kind regards,

- Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website:

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to