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

[Jonas Smedegaard]

On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:

>Done. I will have to add your license to the copyright of some of the 
>Debian packaging.

What I do is maintain packaging licensing in debian/rules.  And I 
(ideally, when not too lazy) do not add licensing info of others but 
instead request them to add it themselves. ;-)


>Actually, git-buildpackage doesn't work anymore with this. I removed
>it locally... I am missing some point on how to use pristine-tar. It
>needs the upstream tarball in the parent directory, or so... working
>on this.

No, the whole point of pristine-tar is that the Git is fully 
self-contained: You need not put a tarball anywhere, git-buildpackage 
regenerates it as needed.

What fails now for you is that you simply grabbed by gbp.conf file 
wich contained not only what you needed but also a hint to use bzip2 
compressed tarballs.  The tarball actually contained in the Git 
currently is a good old gzip-compressed one so is ignored when you tell 
git-buildpackage to instead use bzip2 :-P


>> 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.
>>
>
>That would be nice, but it's probably going to be difficult. The
>jack-info, dc-ctl and midistream utilities could be packages
>separately, and should be useful for the multimedia-loving masses.
>Since scenic relies on milhouse, they could be packaged together.
>Again, I am a close-to-beginner in packaging, so I am not sure where
>to start, especially that the current build process is unified and
>using a single autotools configure.ac script. It would imply splitting
>it upstream, no?

Packaging typically goes like this:

  1. Prepare
  2. configure
  3. build
  4. install
  5. reinstall into package area
  6. tune packaging

Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.

So splitting into multiple packages is (more or less) a simple matter of 
adding more binary packages in debian/control and hinting in 
debian/*.install which autotools-installed parts each of them should 
contain.



>>>> 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.

>Wouldn't it be simpler to depend on python (>= 2.6) | python-simplejson 
>? If not, I'll try with cjson.

Sure, if it works.

What I warned about is that it those JSON implementations might not 
behave equally.  And that I do not remember the details, but know for 
sure that the Sugar developers ended up switching to cjson and only 
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/20100604/1d563173/attachment.pgp>