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

[Jonas Smedegaard]

Hi Alexandre (and others),

On Sun, Jun 20, 2010 at 11:51:10AM -0400, Alexandre Quessy wrote:
>On 10-06-11 07:11 PM, Jonas Smedegaard wrote:
>>
>> Hmmm. I see now that your Makefile.in for the python code uses 
>> $(libdir) and not $(pythondir).  This causes the code to not use 
>> standard Python paths, so that a) it is not possible to support 
>> multiple concurrent Python versions, and b) you need to explicitly 
>> tell pysupport where the custom files are stored so that it can 
>> properly ensure Python Policy is followed.
>>
>> Right now the files are simply installed - not handled properly :-(
>>
>
>This has been fixed upstream in the release 0.6.2! I imported the new 
>tarball in the repository, and it seems to compile OK. What I didn't 
>get yet, is how to install the Python module for each binary package.
>
>The "scenic" Python module should be shipped with the "scenic" Debian 
>package; the "rtpmidi" Python module with the "midistream" .deb.
>
>I played with the debian/rules a bit and read more about dh_pysupport. 
>I am still not sure of how I should do this. Any suggestion?

  From a quick glance it seems that your latest attempts are wrong.  I had 
a go at compiling now (my earlier laptop disk space problems have been 
solved now!) but unfortunately didn't make it far enough to look at this 
issue.

I improved build-dependencies on Boost libs.  This shouldn't affect the 
buildability.

Python scripts are invoked directly, causing default Python to always be 
used, ignoring autotools $(PYTHON) variable.  This is only an issue on 
systems that wants to build for a non-default Python version (i.e. not 
currently a problem with Debian). I believe the best fix is to use the 
autotools-provided $(PYTHON) (and the related python prefix variable - I 
forgot its variable name) to compose the hashbang from a .in file of the 
scripts, instead of the current "/usr/bin/env python" construct.

Python scripts rely on local modules that are a) not declared and b) not 
yet built.  I fixed a) with a patch, but b) still fails.  I believe the 
help2man rules need to depend on module building, and the patch then 
changed to use build dir instead of source dir (which is wrong to use in 
any case).

Another issue is weak cleanup.  During build, directories and files are 
created, which are not cleaned up in the clean target.  I have worked 
around this in the packaging by forcefully removing the build directory, 
so not urgent to fix, just would improve elegancy of upstream build 
routines :-)

Another more annoying issue is that upstream autotools do not use 
AM_MAINTAINER_MODE, causing normal builds to regenerate autotools if 
"too old" which might happen accidentally, especially when using a VCS 
as we do.  The fix upstream is simple: Add AM_MAINTAINER_MODE to 
configure.am and all should be fine.  Until then we need to do a clumsy 
workaround of preserving upstream autotools and restoring in our clean 
rule.


Sorry for my silence - I have been busy with Real Life.  I am really 
excited about this package, as it seems to provide quite cool 
functionality that I am really looking forward to play with :-)

Hope this helps,

   - 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/20100621/ea32ae20/attachment.pgp>