-----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----- _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
