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

[Jonas Smedegaard]

On Mon, Jun 21, 2010 at 10:58:47AM -0400, Alexandre Quessy wrote:
>On 10-06-21 06:38 AM, Jonas Smedegaard wrote:
>>
>>  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.
>>
>
>Sad I was wrong. Happy your disk is back. :)
>
>What I know for sure, is that the Python modules are not shipped with 
>any Debian package anymore. :(

Yeah, I did not dispute that, and do not even claim to know for sure 
that your attempts are wrong, only that they _seem_ wrong from a quick 
glance.

When the below build problems have been solved or worked around, I can 
actually build some packages and _then_ help figure out how to solve 
above issue.


>I don't know yet how to create patches like that. I gues
>git-buildpackage should provide some tools to ease that?

If you mean the patch I have now added below debian/patches, then read 
the manpage of quilt for info on that.

Personally I simply used "diff -ruN" and "patch -p 1" for many years, 
and only very recently started looking at quilt as a convenience 
wrapper.


>> 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.
>>
>
>Reading the automake manual (#1) I guess it could be $(PYTHON_VERSION).
>
>#1: http://www.gnu.org/software/hello/manual/automake/Python.html
>
>Since the scripts have some automake variables already expanded, I 
>could put #!/usr/bin/python@@PYTHON_VERSION@@ there, or something 
>similar?

I am no expert in autotools, so do not know what is the most proper or 
elegant approach.  I just wanted to point out that to me it seems the 
problem lies somewhere in the autotools files.

If (as is seems) you are not familiar with (Python-specific parts of) 
autotools either, then I suggest looking at other project for 
inspiration on how they do things, and use official documentation only 
for reference and verification rather than as educational tool.

...but that's just me.  I know for sure that not all of my working 
methods are most effective ;-)


>> 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).
>>
>
>I think this is the most critical issue right now.

Indeed: This is what made me give up for now trying to actually fully 
build packages so that I could help figure out how to most properly 
include the Python parts.


>Help2man calls the Python scripts, which it turn makes Python 
>byte-compile the modules with the wrong Python version. (?) To fix 
>this, the man page rule in man/Makefile.am should depend on building 
>the Python modules.
>
>What target would that be ? scenic_PYTHON and rtpmidi_PYTHON ?

Sorry - don't know :-( .  But sounds like you are looking in the right 
direction (if that is of any help or at least of some encouragement).


>> 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 :-)
>>
>
>Yes, I am aware of that. Meanwhile, I am building with 
>`git-buildpackage - --git-export-dir=../build-area`.

Ah, yes.  That's a good workaround.  One that I seldom take, but that's 
just because I am massochistic and insist that all cleanup must be 
perfect for my packages.

For the above (but not the below) you need no longer do that workaround 
as we use a separate build dir which is forcefully removed from now on.


>> 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.
>>
>
>I just filled a bug (#2) report upstream about it. It will be in the 
>next release.

Excellent!


  - 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/56be027c/attachment.pgp>