found this problem when rebuilding a local package that iterates on
"py3versions -s" (that just gained python3.7 in addition to python3.6)
Will the python3-numpy pacakge be fixed by an automatic rebuild ?
(ie I just have to wait for a few days)
Do I need to fill a bug report on py
On 04/09/2011 23:39, Josselin Mouette wrote:
> Heya,
>
> Le dimanche 04 septembre 2011 à 23:24 +0200, Vincent Danjean a écrit
> :
>> One of my package is building a python extension (with swig). I
>> would like to know what is the right way to find the correct
>> li
ow better, please tell me.
Regards,
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.
can probably be adapted for packages needing it.
Regards,
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
AP
oad of extensions by default as users cannot easily disable
them) as discussed with upstream a few month ago (a few weeks after the
lenny freeze)
For myself, I'm using git (with git-svn) to maintain mercurial with
branches for backport. If you want to take over (or even help with)
this package,
Steve Langasek a écrit :
> On Wed, Jan 03, 2007 at 01:04:37PM +0100, Pierre Habouzit wrote:
>> he does not needs to, having run hg as root is enough to produce the
>> *.pyc if your package (even against the previous policy) did not managed
>> them.
>
> Um, isn't this only the case if the user wa
Wouter Cloetens a écrit :
> On Wed, Jan 03, 2007 at 01:04:37PM +0100, Pierre Habouzit wrote:
>> To Wouter: to resolve your problem, just rm -rf
>> /usr/lib/python*/site-packages/mercurial. You can do that safely,
>> that'll solve your problem.
>
> Success! Many thanks!
You need to remove /usr/lib
Josselin Mouette a écrit :
> mdiff.py does "import bdiff" which looks for bdiff.so in the same
> directory. On your system, mdiff.py is is
> in /var/lib/python-support/python2.4/mercurial/ which is the correct
> place for packages handled by python-support, while on the user's system
> it is in /us
Hi,
I'm the maintainer of mercurial. At least one of the users has a
problem with loading python modules.
Can someone look at bug #382252 ?
In short,
echo 'import sys; print sys.path; from mercurial import bdiff' | python2.4
works on my system, but not on its one.
Both have '/var/lib/pyth
Hi,
Can someone that know how python loads binary modules
look at the bug #382252.
I cannot reproduce it on my system but two different users report it.
It seems that under some circumstances/environment python2.4 does not
load one binary module whereas python2.3 load it (and both binary
modul
Josselin Mouette wrote:
> Le mardi 04 juillet 2006 à 09:25 +0200, Vincent Danjean a écrit :
>> What would be the interest for an application to be present (compiled)
>> several times on the same system ?
>
> This is the whole point of the new policy. It allows for several py
Josselin Mouette wrote:
> I think you should patch the package so that the binary blob is put in
> a .py module that you can import. Then, you can build this .py once for
> each python version, install it in /usr/lib/pythonX.Y/site-packages,
> after which it can be handled by python-support. (It wi
Hi,
I'm converting one of my package (commit-tool) to the new policy.
I was thinking it will be easy, but I found several difficulties.
I'm able to deal with them so that I will be conformed to the new
policy, but I would like to do the Right Things.
Here is the situation.
My package has
Raphael Hertzog wrote:
> On Tue, 13 Jun 2006, Raphael Hertzog wrote:
>> Here's a list of sources packages that need to be updated (266 packages):
>> http://people.debian.org/~hertzog/python/sources-by-maint
>
> Pierre Habouzit (Madcoder) did the mass-bug filing:
> http://bugs.debian.org/submitter:
14 matches
Mail list logo
