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