Re: RE : cctbx debian package [HEADS UP]
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
Reply to: