Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

[Jonas Smedegaard]

On Wed, Jun 02, 2010 at 10:52:23PM -0400, Alexandre Quessy wrote:
>2010/6/2 Jonas Smedegaard <dr at 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
>dh_install.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100603/66b75cc3/attachment-0001.pgp>