Hello Jonas and the team!
2010/6/2 Jonas Smedegaard <d...@jones.dk>:
> 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:
Done. Everything seems to be OK, as far as I know. I push the 0.5.11-1
I had made, and then committed some changes according to your advices.
I pushed my changes again to alioth. Should I update the vesion number
to 0.5.11-2 now? I know that when it's ready to upload we should keep
only the last entry - with the "Initial packaging" message - closing
the ITP bug.
> 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).
Was already done. :)
> Long descriptions should be line-wrapped at 72 chars.
Done. (I thought it was 80)
> 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.
I removed them.
> 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.
I removed them. They were non-free packages. I think they are on
Ubuntu, but not on Debian. They are not needed for a successful build,
so I removed them. I might add some suggests in a future version of
> 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.
I assume this in the rules file. I changed it according to your advice:
DEB_CONFIGURE_EXTRA_FLAGS = --enable-mt
> It is bad style to invoke dh_install again (in addition to the included
> debhelper.mk snippet). Instead either add a debian/scenic.install file, or
> set DEB_DH_INSTALL_ARGS.
I am not sure where you found this. Was it in scenic 0.5.10-2? I am
now editing starting from 0.5.11-1, in which I can't find any
> Are you sure you need to build-depend on bash-completion?
No. :) Removed it. I assume the /etc/bash_completion.d/ directory will
be created? If not, I should create it?
> The binary package is arch: any, but the configure.ac 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.
Well, for now, Scenic relies heavily on the GNU/Linux kernel. (For the
dc1394 module and V4L2) Should we put something like uclinux-*?
> 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.
Ok. Being the main upstream author for the Python in Scenic, I will
try check if switching to python-cjson is seemless. Note that in the
Python code, I check if the "json" module is the same as the former
"simplejson" module. Simplejson is part of the standard Python library
as "json" since Python 2.6. I could depend on either python >= 2.6 or
python-simplejson. See http://docs.python.org/library/json.html ... I
don't know why Python named the module the same name as the former
json module.... but replaced it by a new - different one.
> 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 .
Done. They're all passed here. :)
> Have a look at e.g. morituri package for some modern CDBS enhancements -
> like upstream tarball processing, and copyright and licensing tracking.
I'll check that tomorrow.
> Please don't hesitate to ask if any of this is not clear to understand for
Thanks a lot for you help!! I will get back to you when I will work
more on this tomorrow and the days after.
This is very appreciated.
> Kind regards,
> - Jonas
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
> [x] quote me freely [ ] ask before reusing [ ] keep private
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----
> pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers mailing list