Re: Remove python 2.7.3-13 (experimental)?
Am 11.06.2013 08:18, schrieb Arnaud Fontaine: > Hello, > > No reply so I guess it should be ok. Therefore, I will request the > removal of python from experimental. please wait until the upload in NEW reaches unstable, and then it will be removed automatically. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b6ce18.5020...@debian.org
Re: RFS: python-keyring 1.4-1
On Sun, Jun 9, 2013 at 10:05 PM, Sebastian Ramacher wrote: > If nobody beats me to it, I'll take a look at it later next weak. Did > you have a look at the open bugs? Also, 1.0 dropped support for the > auto-conversion of pre-0.9 Crypto based backends. Although wheezy has > the code to convert the the storage, I think it'd be a good idea to > at least mention the fact in NEWS.Debian and maybe also provide a script > to convert old keyrings. Done (though needs someone else to test it, as discussed in IRC). Note that it fails to build when python3-secretstorage is installed (see upstream #102), but there is no problem when you are building in chroot. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakimphv2tzoazx_s_rk3ywe6wrgo8tftyc80004sfxlgc2k...@mail.gmail.com
dh_python2+dh_python3
Hi! I just converted a package to add a Python3 package. I expected this to be as simple as: 1. Declaring the package in debian/control and add the appropriate dependency stuff. 2. Use dh --with python2,python3 $@. However, this is more tricky: - dh_auto_build has to be overrided to also call each supported Python 3 version "python setup.py build". - dh_auto_install has to be overrided for the same reason. - Ditto for dh_auto_clean. - python-.install and python3-.install needs to be defined. I was wondering why this is not automatically done by the various helpers. Is there a bug tracking this issue? Is it an issue with dh_python3? Or with debhelper? -- Use the fundamental control flow constructs. - The Elements of Programming Style (Kernighan & Plauger) pgp9jXxh3XVQd.pgp Description: PGP signature
Re: dh_python2+dh_python3
Vincent Bernat wrote: >Hi! > >I just converted a package to add a Python3 package. I expected this to >be as simple as: > > 1. Declaring the package in debian/control and add the appropriate >dependency stuff. > 2. Use dh --with python2,python3 $@. > >However, this is more tricky: > > - dh_auto_build has to be overrided to also call each supported Python > 3 version "python setup.py build". > - dh_auto_install has to be overrided for the same reason. > - Ditto for dh_auto_clean. > - python-.install and python3-.install needs to be defined. > >I was wondering why this is not automatically done by the various >helpers. Is there a bug tracking this issue? Is it an issue with >dh_python3? Or with debhelper? Debhelper. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/dd89e825-2f20-4365-93c6-16b498bc9...@email.android.com
Re: dh_python2+dh_python3
On 11 June 2013 20:58, Vincent Bernat wrote:
> - dh_auto_build has to be overrided to also call each supported Python
>3 version "python setup.py build".
> - dh_auto_install has to be overrided for the same reason.
> - Ditto for dh_auto_clean.
> - python-.install and python3-.install needs to be defined.
>
This should be somewhat easier using the new pybuild system. Piotr
described it as:
"with pybuild in unstable it should be a lot easier to add python3-foo
packages (just add binary package in debian/control, build depend on
python3-all-dev, use --buildsystem=pybuild in debian/rules and add some
.install files / export PYBUILD_DESTDIR_python{2,3})"
http://lists.debian.org/debian-python/2013/05/msg00017.html
Thomas
Re: dh_python2+dh_python3
On Jun 11, 2013, at 09:17 PM, Thomas Kluyver wrote: >This should be somewhat easier using the new pybuild system. Piotr >described it as: Old school non-pybuild way: http://wiki.debian.org/Python/LibraryStyleGuide http://wiki.debian.org/Python/AppStyleGuide (We should really update these guides to describe pybuild.) -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611162559.731ddbf3@anarchist
Re: dh_python2+dh_python3
[Vincent Bernat, 2013-06-11]
> I just converted a package to add a Python3 package. I expected this to
> be as simple as:
>
> 1. Declaring the package in debian/control and add the appropriate
> dependency stuff.
> 2. Use dh --with python2,python3 $@.
you're missing "--buildsystem=pybuild" here... probably because pybuild
is still only in experimental (I didn't want it to be uploaded to
unstable as I started to move pybuild (and dh_python{2,3} but not
py{3,}c{lean,ompile}) to a separate package few weeks ago and still
didn't find time to finish it. I'll try to do it soon.
See "DEBHELPER COMMAND SEQUENCER INTEGRATION" section in pybuild(1) for
more info
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
signature.asc
Description: Digital signature
Re: RFS: python-keyring 1.4-1
On 2013-06-11 18:47:12, Dmitry Shachnev wrote:
> On Sun, Jun 9, 2013 at 10:05 PM, Sebastian Ramacher
> wrote:
> > If nobody beats me to it, I'll take a look at it later next weak. Did
> > you have a look at the open bugs? Also, 1.0 dropped support for the
> > auto-conversion of pre-0.9 Crypto based backends. Although wheezy has
> > the code to convert the the storage, I think it'd be a good idea to
> > at least mention the fact in NEWS.Debian and maybe also provide a script
> > to convert old keyrings.
>
> Done (though needs someone else to test it, as discussed in IRC).
I'd put the script in /usr/share/doc/python-keyring or
/usr/share/python-keyring. There's no need to put it in /usr/bin. Also,
I wouldn't copy the the master password from the old keyring to the new one. If
the user already created a new Crypto keyring with a different password,
this would destroy it. I'd also make it more explicit when asking for
the password that it's the password for the old keyring.
> Note that it fails to build when python3-secretstorage is installed
> (see upstream #102), but there is no problem when you are building in
> chroot.
So either
- get ImportKiller fixed,
- disable ImportKiller based tests for Python 3.3 for now or
- add python3-secretstorage and python3-gi to Build-Conflicts.
What's the status of all the other tests? Many tests are skipped because
of missing dependencies.
The version from PyPI is versioned as 1.4. The version from bitbucket as
1.4dev. 1.4dev is not PEP 386 compatible version and breaks anything
having a requirment on keyring >= 1.4 in setup.py or using
pkg_resources.require:
| >>> import pkg_resources as p; p.require("keyring >= 1.4")
| Traceback (most recent call last):
| File "", line 1, in
| File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 696, in
require
| needed = self.resolve(parse_requirements(requirements))
| File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 598, in
resolve
| raise VersionConflict(dist,req) # XXX put more info here
| VersionConflict: (keyring 1.4dev (/usr/lib/python2.7/dist-packages),
Requirement.parse('keyring>=1.4'))
Regards
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Re: python3.3 status
On Thursday, June 06, 2013 12:46:05 PM Scott Kitterman wrote: Here's another update based on work I've done, noticed other people did, or responses to the last one of these I sent. It does not include work which I neither notice nor people told me about. Items marked as fixed in the last update have been removed. > On Thursday, May 23, 2013 06:19:06 PM Scott Kitterman wrote: > > I've been working on this a bit ... > > > > On Tuesday, May 07, 2013 02:01:26 PM Jakub Wilk wrote: > > > python3-defaults maintainer(s?) decided to make python3.3 a supported > > > version without prior notice. Yay. Now we have dozens of packages > > > failing to build: > > > boost1.49 FTBFS TODO (could not find an open bug) boost1.50 Resolved - package has been removed. > > > cairosvg FTBFS, needs fixed py3cairo distribute Fixed. > > > flufl.bounce FTBFS #707086, needs new zope.interface germinate Fine now > > > hivex FTBFS fixed, but still doesn't generate dependencies right #709516 > > > libguestfs FTBFS TODO mdp Fine now. mpi4py OK nuitka FTBFS unrepoducible objgraph Fixed now pyepr builds successfully, but puts dbg extensions into wrong package: #708011 pyfits binNMUed successfully pyopencl FTBFS, #711926 > > > pyside FTBFS TODO pystemmer OK python-apt Fixed python-astropy Builds fine, but doesn't actually put the python3 build in a binary. > > > python-cffi FTBFS TODO > > > python-csb FTBFS TODO > > > python-distutils-extra FTBFS needs rebuilt pygobject python-llfuse OK python-numpy Fixed in unstable python-scipy FTBFS with new Cython/Numpy: #707315 Needs new, new cython which is ready in svn > > > python-stem FTBFS TODO > > > python-wadllib FTBFS #686332 > > > shiboken FTBFS TODO > > > yapsy FTBFS TODO yp-svipc fixed - binNMUed zope.interface - Needs update to 4.0.2 or later, needs updated zope.exceptions zope.exceptions needs updated to 4.0.1 morse-simulator - Builds, but depends are FUBAR: #712014 Many of the FTBFS packages above could probably stand to be rebuilt again to see if they build now (most of the ones I've tried do). Getting zope.interface/exceptions updated would be helpful as well, but seems to need sponsoring. Arnaud Fontaine is looking into this. All of the red in http://release.debian.org/transitions/html/python3.3.html is due to open bugs (except pyside, I didn't get to look at that yet). The binNMUs that could be done after python-numpy was uploaded are done except those blocked by bugs. It would still be worth doing some investigation of the unknown packages to see if they are generating dependencies correctly. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2366362.9uueqvkskS@scott-latitude-e6320
