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