Request to join DPMT team
Hello, My name is Corey Bryant. https://alioth.debian.org/users/coreycb-guest I'm writing to request membership to the DPMT team. I primarily work on OpenStack packaging and with that comes the need to touch some of the python packages that do not fall under the openstack team. For example I currently have some updates to python-cliff that I'd like to push. Thank you. -- Regards, Corey
Re: Sphinx 1.3 in Debian experimental
Hi Tomasz, On Tue, 30 Jun 2015 21:59:00 +0200, Tomasz Rybak wrote: According to Sphinx documentation http://sphinx-doc.org/config.html#confval-html_last_updated_fmt when html_last_updated_fmt is set, Last updated on ... should be added to the bottom. Is this omission on purpose, or does it suggest some problem with my packages? It is not a problem with your packages, I can confirm it. Looks like it is an issue with Alabaster theme: it overrides the footer and does not add support for last_updated property. With classic theme everything works as expected. Anyway, for us not having that feature is even better, because that means the build will be reproducibile. Maybe I will even talk to upstream about disabling it for other themes as well (by default). -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Joining the DPMT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi All I've been skulking around on this ML and on the #debian-python IRC channel for a while now so thought it was about time I put in my request to join the DPMT. I've been working across Debian and Ubuntu for the last 4.5 years; I started doing Java packaging, then my job at Canonical changed and I now mainly work on packaging Python bits and pieces now - specifically OpenStack (I'm the tech lead of the OpenStack engineering team at Canonical). Corey Bryant and I have started working more closely with Thomas in the PKG OpenStack team in the last month or so - but its evident that we can make some valuable contribution across Python modules generally. Cheers James - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVlUXXAAoJEL/srsug59jDoJ8P/3XY23D+uYzewKdWAnlpRT5K LPaBPf8P4wJcn2plLtGWSRWnWD1sfLiJmqBCYfEqyxE6KO/mERf74j7SNkdHYiyp kbBAMIOzLWd+EFCTpY/oAChS7y3fw/XnPwhQOsgoiZIRN5DZgjDja4F/LC3RZa/J Nn/FkIs/pVlWeurc0tNr1IwgwbFKadFvR7wng3BHukQLVbJuprqzzCcMHq/QgV7t 6XNGIFvbqHsiNlMobzJf8AYMqvesiksJQDjngCSR+OzGpctWahEc743cZw0UMihG 1OWAT/HBM4nlVAx5mNxHr//V73DeWMND4Uef3ymWCDOgZ4vIQIqyFta1llPLNRtd ieGwAhLZmAGMT9jgNTLBfkzcF5LIuKMIJNi9F9V+wsu5ApvNSt8AkqmBY1gVRuDV xC6XHlMjTIyh4AhNG/kbtmpt2/gzm4p+IzxKs55zqwYiGRPaJZHzgldgiFn9E84p Fryxpi4JKdkfRduwEKeG0o+GOKnvhrLh6oRM49as4i1ADv1/Xhlqtp2MXITZFMCm C9VsBVeFpHNaT2TNEsOJPs31kL7fOxlR6djK/9xPfiFfrDwi6BYcNnZwMw12W4jW 2gE6u5oyPuKPARai1sWhSiWXW6oh8OfhlJvii+Kr0sjz/GVnKfBSYaWu/Ses5Xmd 76m+ao6Vu4PencHJMyoJ =C8ji -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559545d7.7080...@ubuntu.com
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. So I'd argue that ‘python3-mock’ and the like do have a place in Debian: they make it easier to follow the recommended strategy of having a code base run unchanged on Python2 and Python 3. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/can-kwu1os1+grzrbcx41jsbs2uqgwxukmw2usgmgfo4safd...@mail.gmail.com
Re: Removing some python3-* packages
On 3 July 2015 at 11:44, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. So I'd argue that ‘python3-mock’ and the like do have a place in Debian: they make it easier to follow the recommended strategy of having a code base run unchanged on Python2 and Python 3. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. See my prior mail. I will be backporting all the changes in mock from the stdlib to the mock standalone lib in the near future. I have upload acls from Michael Foord for PyPI and I'm not afraid to use them to fix it up - if you wanted to prep a narrow patch to fix 3.4 then please do so here - https://github.com/testing-cabal/mock -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj3hoz1emwkf5st9wburfxv0ffe-ufn+jkugcvvd2ttarnn...@mail.gmail.com
Re: Removing some python3-* packages
On 3 July 2015 at 09:53, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 2:55 PM, Barry Warsaw ba...@debian.org wrote: As part of the 3.5 test rebuild I noticed an incompatibility with python3-enum, which I reported upstream. The response was: there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. Since that's all we have now, maybe it makes more sense to just remove the python3-enum package from Debian. There may be similar packages which are fairly straight backports of Python 3 packages. For those that are no longer necessary, what do you think about removing the python3-* version of the binary package? It seems like a bit of a regression given that we want Python 3 versions of our libraries, but in cases like this it probably makes sense. Thoughts? -Barry Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. Is that being packaged for python3 on Debian as well? I know it's nice to have the libraries available on both, but mock for example stopped working on python3.4 since it's solely maintained in the stdlib now. It doesn't make sense to package that for both. (Keep in mind, I'm just an observer and I haven't checked if those examples are already packaged for Py3) So, unittest2 is *explicitly* targeted at 3.5, 3.4, 3.3, 3.2, 2.7, 2.6. Its not 'unittest for 2.6', its unittest for not-running-from-hg. Same for traceback2, linecache2, and shortly, when I get a day to fix it up, mock. All those IMO should remain packaged, because the stdlib is moving on them, and folk like being able to use the new shiny without waiting years. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj3hoz1l2x-w0sx4igypngxorh6-wrn+bciducntjrpnvk+...@mail.gmail.com
Re: Removing some python3-* packages
Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. So I'd argue that ‘python3-mock’ and the like do have a place in Debian: they make it easier to follow the recommended strategy of having a code base run unchanged on Python2 and Python 3. -- \ “Nullius in verba” (“Take no-one's word for it”) —motto of the | `\ Royal Society, since 1663-06-30 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85lheyqgb3@benfinney.id.au
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 11:44, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. So I'd argue that ‘python3-mock’ and the like do have a place in Debian: they make it easier to follow the recommended strategy of having a code base run unchanged on Python2 and Python 3. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. See my prior mail. I will be backporting all the changes in mock from the stdlib to the mock standalone lib in the near future. I have upload acls from Michael Foord for PyPI and I'm not afraid to use them to fix it up - if you wanted to prep a narrow patch to fix 3.4 then please do so here - https://github.com/testing-cabal/mock Will do in the next couple weeks. I had chatted with Michael about it on Twitter and he expressed no interest in supporting it. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAN-Kwu1cv9BxZWb3TAte_WXe2QEkabZe8ZOd32BAL3u8=4g...@mail.gmail.com
Re: Removing some python3-* packages
On 3 July 2015 at 11:40, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. I hope you mean 'import unittest2' - and great, thats the intent. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. unittest2 also has new features in it for python 3.2, 3.3, 3.4, and will soon have new features for 3.5 as well. So I'd argue that ‘python3-mock’ and the like do have a place in Debian: they make it easier to follow the recommended strategy of having a code base run unchanged on Python2 and Python 3. +1. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ3HoZ04F=s8af224xl6bceapg8hqeo+tpv+cdfvgkyowji...@mail.gmail.com
Re: Removing some python3-* packages
On 3 July 2015 at 15:05, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 11:44, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. So I'd argue that ‘python3-mock’ and the like do have a place in Debian: they make it easier to follow the recommended strategy of having a code base run unchanged on Python2 and Python 3. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. See my prior mail. I will be backporting all the changes in mock from the stdlib to the mock standalone lib in the near future. I have upload acls from Michael Foord for PyPI and I'm not afraid to use them to fix it up - if you wanted to prep a narrow patch to fix 3.4 then please do so here - https://github.com/testing-cabal/mock Will do in the next couple weeks. I had chatted with Michael about it on Twitter and he expressed no interest in supporting it. AIUI he's pretty busy stuck in golang land these days, so that doesn't surprise me. He added me to PyPI etc specifically so I can do / facilitate this :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj3hoz3bpqwfwfda3hec93_2krx1ccvaweyhezelnsugtqx...@mail.gmail.com
joining the team
hi all, i would like to join the python modules team, mainly to maintain a few python-modules (who would have guessed that?), that I need as dependencies for other packages I maintain. I'm a long-term Debian user, and have become involved in packaging as late as ~2010, when I joined the pkg-multimedia team; since 2014 i'm a DD. I'm currently maintaining a few python related packages, namely: - assimp (an 3d-model importer library that also provides python bindings) - pysoundfile (libsndfile wrapper for python/python3) I'm currently trying to get python-easywebdav (ITP #790872) into Debian, and would like to do this under the python-modules team umbrella. my alioth username is umlaeute. fgmrds IOhannes signature.asc Description: OpenPGP digital signature
Removing some python3-* packages
As part of the 3.5 test rebuild I noticed an incompatibility with python3-enum, which I reported upstream. The response was: there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. Since that's all we have now, maybe it makes more sense to just remove the python3-enum package from Debian. There may be similar packages which are fairly straight backports of Python 3 packages. For those that are no longer necessary, what do you think about removing the python3-* version of the binary package? It seems like a bit of a regression given that we want Python 3 versions of our libraries, but in cases like this it probably makes sense. Thoughts? -Barry pgpFaj8FPL6Dr.pgp Description: OpenPGP digital signature
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 2:55 PM, Barry Warsaw ba...@debian.org wrote: As part of the 3.5 test rebuild I noticed an incompatibility with python3-enum, which I reported upstream. The response was: there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. Since that's all we have now, maybe it makes more sense to just remove the python3-enum package from Debian. There may be similar packages which are fairly straight backports of Python 3 packages. For those that are no longer necessary, what do you think about removing the python3-* version of the binary package? It seems like a bit of a regression given that we want Python 3 versions of our libraries, but in cases like this it probably makes sense. Thoughts? -Barry Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. Is that being packaged for python3 on Debian as well? I know it's nice to have the libraries available on both, but mock for example stopped working on python3.4 since it's solely maintained in the stdlib now. It doesn't make sense to package that for both. (Keep in mind, I'm just an observer and I haven't checked if those examples are already packaged for Py3) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAN-Kwu0t=SKW=9gH6HYGLZZNW76rvchnZVzp8Hm6C1T=ux4...@mail.gmail.com
