Re: Python 3.7 in testing/experimental
Le 08/06/2018 à 19:32, Matthias Klose a écrit : > The Python 3.7 beta 5 packages are now in testing, and experimental has > python3-defaults packages which add 3.7 as a supported version. The release > candidate is expected next week, only adding Unicode 11 support, and the > final release is expected at the end of June. > > I would appreciate it, if somebody could run a test rebuild using the > python3-defaults from experimental. Else, please test your packages using > python3.7. python3-numpy do not work with python3.7 in sid currently. In a up-to-date sid chroot: $ python3.7 Python 3.7.0 (default, Jun 27 2018, 14:40:03) [GCC 8.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import numpy Traceback (most recent call last): File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 16, in from . import multiarray ImportError: cannot import name 'multiarray' from 'numpy.core' (/usr/lib/python3/dist-packages/numpy/core/__init__.py) During handling of the above exception, another exception occurred: [...] I 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 python3-numpy ? Regards, Vincent > Matthias -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Re: Bug#548392: debhelper: python_distutils buildsystem and, setuptools entry_points don't use default python
Andrew Straw wrote: setuptools doesn't modify the shebang in the script -- it constructs the entire script when told to, at install time, on the basis of its entry_points declaration and the version of python actually being run (see get_script_header() in setuptools/commands/easy_install.py ). Therefore order-of-python-running is important for setuptools script installation, because the last one wins. So, the default python should run last during the install stage. In the mercurial package, I call sed to ensure a good shebang line: == override_dh_auto_install: $(PYVERS:%=install-python%) install-python%: build-python% python$* setup.py install --root $(CURDIR)/debian/tmp # Do not hardcode the python interpreter sed -i '1c#!/usr/bin/python' debian/tmp/usr/bin/hg == This setup 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 APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: mercurial 1.1.2
Hi, Vernon Tang wrote: On 8 Jan, 2009, at 6:52 AM, Piotr Ożarowski wrote: PAPT is in Maintainer field, but you've made many changes so I'm CCing guys listed in Uploaders hoping that they will take a look (if you'll add yourself to Uploaders, I will not wait for their reply) Thanks for this CC: I do not check papt ml very regularly. I would like to help actively maintain this package, so I'll add myself to Uploaders, but I'd still like to wait for the current Uploaders' opinions regardless. You are very welcome. I'added mercurial in papt as I (the initial packager) was not really still using mercurial so I do not give enough attention to this package. My previous call for help on debian-devel dis not lead to some real improvements after the packaging of the 1.0 version :-(. I'm very glad to see someone interesting in the packaging of mercurial. [lots of changes] I will lot at them this WE (no free time at this moment) * why not use trunk (IMHO there's no need to use new branch) Seeing as my changes were pretty extensive I wanted to wait for a review before committing them to trunk. Besides, I'm used to a branchy development style, hence why I chose to update the mercurial package :) Just committed the aforementioned changes. You can use trunk... Before uploading the 1.1 release, I would like to cleanup the default conffile (no load 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, I will send you all my works. Regards, Vincent Thanks! Vernon -- 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://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Python PATH problem
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/python-support/python2.4' in sys.path Both have /var/lib/python-support/python2.4/mercurial/bdiff.so a symlink to /usr/lib/python-support/mercurial/python2.4/mercurial/bdiff.so that is a ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped I do not know python enough to know what to do now. Does someone have any idea ? Can someone else reproduce the bug ? Happy new year Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python PATH problem
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 /usr/lib/python2.4/site-packages/mercurial/. Therefore you need to understand how the file ended up in this place. Thank for your help (and Pierre too). Wouter, can you give me the results of : $ dpkg -S mercurial $ ls -l /usr/lib/python*/site-packages/mercurial/ Can you also tell me if you have installed mercurial from upstream sources ? Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#382252: Python PATH problem
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/python*/site-packages/hgext, too. I just upload a new version of the package that will do that automatically. You can find it on my repo[1] now or on all debian mirrors in a few hours. Best regards Vincent [1]: http://people.debian.org/~vdanjean/debian/pool/main/m/mercurial -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#382252: Python PATH problem
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 was upgrading from an old version of the package that's no longer in the archive? If so, there's nothing RC about this because mercurial wasn't included in sarge. Even if it is not RC, it would be great if the fix were included in etch. This would allow me to remove this hack in lenny. I submitted a 0.9.1-1+etch1 to testing-proposed-updates with only this fix that I hope it will be accepted. Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HELP] new policy with a compiled python program and generic python plugin module
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 python versions to be installed at once. For a module, yes, but for an application ? By the way, I prepared an update to the new python policy for my 3 python packages. You can look at them here : http://dept-info.labri.fr/~danjean/deb.html#commit-tool This one doesn't look good. You are explicitly hardcoding python2.3 which is exactly the wrong thing to do if you want smooth upgrades. I hardcode python2.3 (and depend on it) so that my package still work when the python package will provide another default python interpreter. Note that it is not python2.3 that I hardcode when building, but pyversion -d. So that, when a new default python version will be uploaded, a simple binary rebuild of my package will make it working with the new python interpreter. And my package will not be broken in the time between the upload of the new python package and the binary rebuild of my package. Note: It that case, the python program includes binary blobs so it only works with the same python interpreter used at built time. This is why using #!/usr/bin/env python would lead to breakage when switching the default python version. Also, you have left some autogenerated files as postinst and prerm. Oups, I will remove them. Thanks. http://dept-info.labri.fr/~danjean/deb.html#mercurial I don't understand why you are hardcoding python2.4 in the scripts. Do they not work with python2.3 ? I use cdbs which calls pythonX.Y setup.py build in turn for each supported python versions. I saw a previous thread on this ML telling that cdbs should end with a build with python (and not pythonX.Y). My (source) script has #!/usr/bin/env python. The substitution is not from me here. You are also making complicated things like hand-made symbolic links in the python-support directories while dh_pysupport should handle them automatically. I was already doing that before the new policy (to move arch indep files from /usr/lib to /usr/share where as upstream puts all in /usr/lib) If dh_pysupport handles that automatically, I will let him doing it :-) Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[HELP] new policy with a compiled python program and generic python plugin module
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 mainly one program gct. This is a compiled python
script (ie it begins with #!/usr/bin/python but it has binary blobs few
lines latter).
It is built from the upstream source (several python source
files) with the help of an upstream program builder (a python script
called buildMain.py).
It seems that gct can be built with any version of python
(python2.3, python2.4, ...), but it must run with the same version
it has been built.
So, if I build gct with the current python version, I have sereral
choice :
A) manually choose a python version and hardcode what is needed:
- replace the first line by #!/usr/bin/python2.3 and hardcode
a dependency on python2.3
- (use a build-depend on python2.3 and patch the build system to use
python2.3) or (use a build-depend on python (=2.3), python (2.4)
and do not patch the build system)
B) try to use the default python version present at built time
B1) using /usr/bin/python
- let the first line of gct to be #!/usr/bin/python
- generate a depend on python (=current), python (current+1)
[with current replaced with the correct value]
- build-depend on python
B2) using /usr/bin/$(pyversions -d)
- replace the first line of gct with /usr/bin/$(pyversions -d)
- generate a depend on $(pyversions -d)
- build-depend on python
C) other thing I did not think about...
I know how to do A. However, the package will need modifications at each
python transition.
B seems better to me as a simple binary-NMU would generate a package for
the current default python version. It seems to me that B2 is better
than B1 as it is less annoying when a transition occurs (I would welcome
advices/comments on this point).
In any case, can you tell me how I can generate the dependencies for B1
or B2 at built time. Are dh_python{,central,support} able to help me
here ?
I tried with dh_pythoncentral with XS-Python-Version: current
but ${python:Depends} do not expand to what I would like
(not (=current), python (current+1), nor $(pyversions -d))
And when all of this will be solved, I have another problem :
commit-tool also provide a small python module (hct.py) that will
be a plugin for another package (mercurial). hct.py calls gct
as a binary program, so the python version used for hct.py is
independent of the one for gct. As mercurial provides public modules
(used by the tailor program for example), hct.py will need to be
available to any supported python version. So the solution for my
previous problem (generating correct depends for B) must be compatible
with the fact that I also provide a module for any python version.
So, I would be glad to get help/comments/advices on this, in
particular on the way to generate dependencies for my B (B1 or B2)
proposal.
Best regards,
Vincent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bugs have been filed, work can begin
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:[EMAIL PROTECTED] http://bugs.debian.org/usertag:debian-python@lists.debian.org And a wiki page to coordinate the NMUing: http://wiki.debian.org/DebianPython/BSP Do you know why my python applications do not have such bug ? There are mercurial and tailor (both of them depending on python2.4 and not python as 2.3 did not work). If my packages have not been caught by the mass-bug filing, others can have also been missed. As I am using cdbs, I will wait for a new cbds package before adapting and uploading these two packages. Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
