Hash: SHA1

Hello Jonas and the team,

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

> I improved build-dependencies on Boost libs.  This shouldn't affect the
> buildability.

Ok. I'm taking notes. ;)

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

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

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

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

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

#2: https://svn.sat.qc.ca/trac/scenic/ticket/589

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

Happy to read this. :)

Our team really care about improving audio-video tools offer for
GNU/Linux. We hope this package will be useful, and believe it really
answers a need. (especially for live events and installations)

Thanks for your help!
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


pkg-multimedia-maintainers mailing list

Reply via email to