On Wed, Jun 09, 2010 at 09:18:14PM -0400, Alexandre Quessy wrote:
Still working on this... It's not easy, but it's likely I will work with more free projects involving multimedia, Python and the autotools for a little while again. :)


Happy to hear that these challenges haven't turned you off.


2010/6/9 Jonas Smedegaard <d...@jones.dk>:

It should be DEB_PYTHON_MODULE_PACKAGES (not DEB_PYTHON_PACKAGES)


Thanks! It seems to work now. It's nice that it takes care of deleting the .pyo files. The .pyc files are byte-compiled for Python 2.5, but it seems to work with 2.6 as well.

Good.

Not sure I read you correctly above: Do the snippet only cleanup half of the Python compiled files? If you seem to reveal weaknesses in the CDBS snippets then do tell - so I can improve them for the benefit of all (except those poor souls not seeing the light of CDBS ;-) ).


Try extend the PYTHONPATH in the check target.  Best to use make variable expansion using some of the variables calculated in /usr/share/cdbs/1/class/python-vars.mk.

If that fails to work then disable tests for now.  I find it better to properly use python-autotools.mk than running the tests.  But beware that since you know that the packaging should fail to build on certain architectures, then if for some reason some of those known failures only are discovered in the regression tests (as opposed to missing build-dependencies which is the more likely to happen) then the trick of not declaring specific supported archs but just rely on "never succesfully built before on that arch" will fail if postponing regression tests for later.


Well, since the unit tests mostly test the Python code, I disabled it for now.

I added the perl one-liner in the binary-fixup/scenic target. It doesn't replace the #! line in the scripts, though. Maybe I should add more rules or set something somewhere else?

Well, my idea was not to use it verbatim (although if relevant you can - and should - off course do that as well) but instead adapt it for use with the regression tests: I did not inspect the code, but imagined that in addition to adding a PYTHONPATH you might need to adjust hashbangs in tests as well.

If you want an example of custom PYTHONPATH export, have a look at radicale (one of my latest packagings).


Otherwise, I think this packaging stuff is going well. The upstream team will be ready for the 0.6.0 release for Friday, I think.

Sounds good. But we need not delay releasing this packaging until then: approval from ftpmasters may take time, so better get in in as soon as we feel the packaging is acceptable. Even if you know that this upstream code is flawed, we can still release but (if needed) immediately file a severe bugreport against it to block it from entering testing.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

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

Reply via email to