Le 26/07/2012 20:45, PICCA Frédéric-Emmanuel a écrit : > maybe in that case it would be better to rebase on top of the changes > currently in the git repository > git rebase origin/master is your friend. > That way we should have a linear history. I find it much convenient that way. > But it is only me :)
Don't worry, I'm using gbp-pq now, so the only thing I have to merge is the patch (0010-adding-setup_py.patch). > how do you decide if a package need this __future__ or not ? > I am wondering also if we miss some __future__ features. > We already have divide, what else ? This *is* the divide thing. I don't know of another __future__ problem. The source of this problem is really only the fact that upstream develop and test with "-Qnew", which silently does the same thing as the __future__ import. So I add a "from __future__ import division" line to all non-empty files that don't have it already. > I do not know about this, can you explain clearly what is the problem with > thoses libtbx_env files. > Maybe document this it in the wiki, so It will be easier the day we will > discuss with the upstream. Radi can probably explain this better than me. Basically, at runtime, libtbx makes use of a serialized copy of the build environment. We need to modify this environment to correct the modules install paths. >> * I moved the scons build dir inside the distutils temporary dir (I was >> unconfortable with the idea of setup.py automatically cleaning a >> directory it doesn't own) > > you mean under the build directory ? I mean 'build/temp.linux-x86_64-2.6', which is the standard distutils place for build artefacts. >> I also made code changes for platform independence and consistency, and >> fixed an embarassing bug in find_packages_and_extensions which prevented >> the resulting python modules from working (inclusion of >> boost_python_meta_ext.so). > > for upstream ? No, it was just forgotten by my previous code and not included in the packages, which broke them. > Can you put your reflections about the test suite in the wiki. > I like this wiki too much :). I'll try to do that tomorrow. > this is not an issue in that case, a simple should do the trick > > override_dh_auto_test: > # for each version of python > python setup.py test I didn't suspect that it was so easy :-) Still, I won't include it yet, as the tests take really too long. Cheers, Baptiste -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
