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

Tue Jul 20 16:07:54 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Jonas and the team,

I'm finally managing to put some more time on this. I spent a few weeks
without much Internet access. Meanwhile, we applied you patch upstream
and made a new release. There are issues to fix, though, since we
changed the way the Python is packaged with autotools.

On 10-06-21 12:04 PM, Jonas Smedegaard wrote:
> On Mon, Jun 21, 2010 at 10:58:47AM -0400, Alexandre Quessy wrote:
>>
>> 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.
> 

Hmmm. Actually, our release doesn't quit fix these. I guess it's better
to apply patches and then push them upstream. (remove my author hat, and
wear the packager one) You were right about this.

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

I will ask around for help on this.

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

Ah! We thought about putting the call to help2man in the make dist
target, not "make". We would put them in the tarball, but they would not
be rebuilt when running git-buildpackage. That would solve this issue.
(the *.pyc files are not distributed in the tarball)

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

Fixed in upstream 0.6.3.

Ok, so we have two major bugs to fix.
 1) Call help2man in the make dist target and distribute the man pages
in the tarball.
 2) Replace the shebang by the proper Python version

It seems to me that packaging Python stuff is so difficult that it's
what is actually slowing down the whole release of the next stable
Debian. At least, that's my impression reading
http://en.wikipedia.org/wiki/Debian#Release_history

Not giving up!

Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMRcnWAAoJEJQ0pOgl2qx1iTUP+wfk66Z0apOjQ+mO84KbU/8U
tNuMD2Vzabzo+aWvQ+m/wgbQGaNJHAPTfN2nx0puWwR7R5AeBehkZVD37kq+BGmM
CfOvznxMrZfiriJZvlrx+sF7uVIciDVbXmh/9oo/XhS/Ps59cHBIx0e4hA+BF7E6
v+U8ufPlD79tZR7Rxyg+4sT5tj/fOWDD0Od+y5RnNCNB/tlVxDOhgac00sUhiMUA
PvUwRnLpykwPRdtUq1Rmu4pJriKolc1kPSuFcyP6h3IUz58iHRxXl0LxGvOnBnge
8mXorXsExhBFgzhZepDR1iYaGob67ADd/Bp9G/922EGEeZK7X/YJBjuVmonmEuzj
JNs71gj9hAn1We8XoRQAaWJ+reDlGxjzFvSx2y4gOs68so2xhnQuJti4UsxMoLCL
tYDnUzASz8QiACJzzF2ioOGRyvwhTNGd+kY5qkw9JWDX5+FhoYl/q+fV360qjHkE
pVPVSjHH7QSIn2YIYuTLnziyDlcvQam18id8xk2/ACUTIwNj/QUBr8A+FK1BBzuy
79MqO2bBfpgs3hie0RyU5hUuLOLBOkx1FnZRobm4O0FI4EU/FXVKm5PZB/rtntc2
fYcCStmrMOpm26+TrNqASWzJPA02JpPsSP6e0BSQFNb5CiGjiy2KmzlgGm36ZR5w
kIheWJX3yBXO9jIuThow
=UZ4/
-----END PGP SIGNATURE-----