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

Sat Jun 5 07:51:41 UTC 2010

On Sat, Jun 05, 2010 at 12:55:32AM -0400, Alexandre Quessy wrote:
>I just thought about an issue that makes my package 33% unusable. :) 
>The MIDI streaming feature (which would be provided by the new 
>midistream package) relies on either python-portmidi or python-pygame
>>= 1.9.1. Those two packages are not in Debian yet!
>
>Actually, python-pygame 1.9.1 is in Ubuntu Lucid, but not in Debian
>Sid. I have been trying to contact the maintainer, and later answered
>to a bug about this. See
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544347 ... Maybe it
>is too late before the the release of Squeeze? There might be quite a
>few packages that depend on python-pygame. I also have an other
>package - toonloop 1.2.8 - that needs python-pygame, for its V4L2
>video input feature and the MIDI feature.
>
>For the MIDI feature, which is our main interest for scenic, an other
>package could provide it. It's python-portmidi. I packaged it, but did
>not contribute it yet, since the original author thought it would be
>nice to send it upstream, but it's taking time. It's not there yet:
>http://sourceforge.net/apps/trac/portmedia/browser/portmidi/trunk (4
>months with no activity) My changes to the upstream along with my
>packaging files are at http://bitbucket.org/aalex/pyportmidi/wiki/Home
>
>So, either we ask the maintainers of the pygame package to update it,
>or we package python-portmidi. I think that merging the pyportmidi
>code with portmidi0 would take too much time and effort for now.
>(before Squeeze) Anyways, the python-portmidi should be a separate
>package from portmidi0, so ... should fill a ITP and package it now?
>:)
>
>Note that the scenic application can still run, it's only that the
>MIDI features will be disabled.

Lower that package relation to suggests, and document the benefit of 
installing that suggestion (without explaining the reason it is only 
suggested, that is development-grade info IMO) in both long description 
(i.e. in debian/control) and in a debian/README.Debian file (which CDBS 
then automagically includes in the binary packages).

And try post to bug#544347 again - cc'ing menucci who seem to have 
somewhat taken over maintainership and perhaps haven't noticed that old 
bug.

A valuable place for extracting such info is this: 
http://packages.qa.debian.org/p/pygame.html

>2010/6/4 Jonas Smedegaard <dr at jones.dk>:

>Maybe it would be nice to also create the scenic-doc package, to 
>separate the doc from the Python code. (though both are architecture: 
>all)

Certainly - if there is documentation of a reasonable amount then it 
should be in a separate binary package.

>For now, the docbook documentation (viewable with yelp) are in an 
>unusual location. (/usr/share/scenic/docbook) It should probably go to 
>/usr/share/gnome/help/scenic/C/scenic.xml like all gnome docs. Our 
>docbook doc is made of several XML files and images, though, and we 
>have two manuals...

I am not very familiar with yelp, but seems to me that if the project is 
not otherwise tied specifically to Gnome and if yelp supports reading 
from non-gnome directories, then you shouldn't jump through hoops to 
install the documentation Gnome-style, but instead jump through hoops to 
get yelp to recognize it.  More importantly you should register with 
doc-base (which might be all that is needed for yelp integration too?).

>>> The easiest way would be to create 3 *.install files. The quick 
>>> benefit to this, is that we will have a few packages that are 
>>> architecture-independant, namely the two Python-only binary 
>>> packages: scenic and midistream. That totally makes sense.
>>
>> Yes, that seems sensible (from reading it alone - I must admit that I 
>> have not yet tried compiling the project and looking at the results).
>>
>
>It's rather complex to actually use it to its fullest - it needs two
>computers - but the GUI should work right away. For the command-line
>lovers, the "advanced" tutorials in the "User manual" under the "Help"
>menu are a good intro to the "milhouse" command-line tool.

Well, my excuses currently is a) I have too little time (developing and 
setting up sms service in the field for an experimental theater group), 
and b) I cannot do clean-room package compilations due to a major part 
of my laptop being readonly (heating problem caused a power outage 
during a partition resize - all data seems fine but I cannot know for 
sure, and every time I try fsck'ing that heating problem strikes again).

In other words: my trouble is unrelated to the code quality :-)

>>> I am looking for an example of doing this... (which uses cdbs and 
>>> the autotools, if possible) Got any?
>>
>> sugar-0.88
>>
>> That one also demonstrates quite well IMO how a large amount of 
>> package dependencies are easier to track indirectly declared in 
>> debian/rules, as they they can be grouped and comments added as 
>> needed.
>>
>
>This is very interesting and am I looking forward to learn more about 
>this. I will make some tests soon.

I am happy to hear that you are interested in those features.  They are 
some of my newest additions to CDBS :-)

  - 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/20100605/3826cd3d/attachment-0001.pgp>