On Wed, Jun 02, 2010 at 10:52:23PM -0400, Alexandre Quessy wrote:
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: http://wiki.debian.org/DebianMultimedia/DevelopPackaging

Done. Everything seems to be OK, as far as I know.

Looks ok to me too. You should probably add a debian/gbp.conf file to ensure pristine-tar is used in the future too. See e.g. morituri package for an example of that.

(it is not that morituri is the most excellent package out there, I just picked one that is tiny and has little unusual stuff - I generally seek to evolve all packagings that I am invovled in into examples for others to reuse, so tell me if you want an example of some specific quirk and I'll try find a package demonstrating it!).

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.

Generally for all Debian packaging we should bump the release number only when actually releasing as packaging in Debian. So the answer is "No!".

As a related not, there are several ways to keep track of packaging changes, common ones being dch+dcommit and git+git-dch.

Probably the most common one generally in Debian is to make your packaging change, add a changelog entry using dch, and commit both the actual change and the changelog update using dcommit.

I prefer the alternative of making packaging changes, commit the actual change, and only occationally (and at minimum right before a packaging release) do a git-dch, maybe adjust the changelog file by hand (e.g. I prefer to add a newline before bug-closures for improved readability), and then commit the changelog update separately from the actual code changes.

One thing I like about that git+git-dch approach is the code changes being separate, which eases potential later reverts or cherry-picking across branches.

Another related note is how to handle Debian-based non-Debian packaging releases. I prefer to treat Debian as the master, do variations off of that, and not include "noise" from derived packaging in the main Debian branch. If I borrow from e.g. an Ubuntu packaging not done by myself, then I cherry-pick the actual packaging code changes but do not preserve the derived changelog entries: Debian IMO have no use of documenting version numbers not ever being released in a Debian context!

Long descriptions should be line-wrapped at 72 chars.

Done. (I thought it was 80)

The classic terminal width is 80 chars. A common line-wrapping length is 72 chars to leave some chars for e.g. quoting in MUAs.

So yes, I wouldnt be surprised if the Debian Policy limit is 80 chars, but I will nevertheless still recommend to use 72 chars in reality :-)

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

Yes, I looked at the packaging that you originally provided a URL for, which indeed was 0.5.10-2.

Now we are both tracking same Git and you are right, it is gone :-)

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?

Yes, in my experience underlying directories are automagically created when installing files through debhelper. Not sure what version of debhelper started doing so, but I am pretty confident that at least version 5 is safe.

On a related note, I see that you bumped to debhelper 7. Beware that this might provide no benefits over debhelper 6, and may make it more difficult to backport, if you happen to care about that.

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-*?

I don't know what you mean by uclinux-*.

What is common to do is to replace "any" in "Architecture: any" with all known-to-work Debian targets that is supported by the project.

I dislike such hardcoded lists, however, and prefer to instead semi-automatically resolve it, either through dependent package (see e.g. calf for an example of that) or using type-handling (can't find an example of that right now).

It does seem, however, from a quick glance, that some parts of the project is not arch-limited. It might be a good idea to split packaging to provide most possible to all 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.

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.

I am no expert in the area. Tell me if you would find it useful that I try dig out the relevant ML thread at the Sugar project.

Thanks a lot for you help!!

As Harry Tuttle says in the movie "Brazil":
Listen, kid, we're all in it together.


I will get back to you when I will work more on this tomorrow and the days after. This is very appreciated.

Looking forward to that!

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to