Re: Python in the Debian infrastructure
On Fri, Aug 19, 2022 at 10:25:25AM -0300, Antonio Terceiro wrote: > On Fri, Aug 19, 2022 at 09:29:40AM -0300, Emmanuel Arias wrote: > > Hi, > > > > I'm very interested :-) > > > > > > On Wed, Aug 17, 2022 at 9:23 PM Louis-Philippe Véronneau > > wrote: > [...] > > > - patching tracker.debian.org (Django) to show pending MRs [10] [11] > > > > > I'm just curious, we know or it's easy to know if there're more parts of > > the Debian > > infrastructure where Python is used and we can help? > > Lots of it. I made a talk about contributing with the Debian > infrastructure in 2020 online minidebconf, and here is the contents of > my summary slide: > > > ## Summary > > Project | Ruby | OCaml | Python | Shell | Perl | JS > -|::|:-:|:--:|:-:|::|:--- > [ci.debian.net][]| x | || x | | > [dose3][]| | x || | | > [botch][]| | x || | | > [devscripts][] | | | x| x | x | > [licensecheck][] | | || | x | > [Debian Keyring][] | x | | x| x | | > [sources.debian.org][] | | | x| | | > [contributors.debian.org][] | | | x| | | > [Security Team][]| | | x| | | > [debtags.debian.org][] | | | x| | | x > [moinmoin][] | | | x| | | > [nm.debian.org][]| | | x| | | > [sso.debian.org][] | | | x| | | > [tracker.debian.org][] | | | x| | | > I'll add a few: - dak / ftp-master - snapshot - pybuildd - planet - security-tracker - release tools (britney, transitions, queue-viewer, ...) - udd - userdir-ldap - piuparts - mirror-status - veyepar.debian.org - debconf websites - debdelta Cheers, Julien
Re: python3-pysnmp4 forked upstream
On Thu, Apr 07, 2022 at 01:22:49PM +0200, Luiz Amaral wrote: > Hello Python Team, > > It looks like the current upstream[1] of pysnmp has been unmaintained > for a while and got forked [2]. > > FreeBSD has done some adjustments to pysnmp and the related packages > because of that [3][4], as the current version seems broken in Python 3.9. > > What is your opinion on updating these packages to use the forked upstream? > > I cced Julien specifically because I saw he was working on pyasn1 > yesterday. > Hi Luiz, Sorry, I've got no knowledge of / interest in pysnmp at the moment. (I only did a drive-by upload of pyasn1-modules yesterday because I was looking at RFC3161 and that was missing in the version in sid.) Cheers, Julien
Re: python-anyio failing testsuite on buildd, not locally
Hi, x86-conova-01 has no ipv4 address other than loopback. That causes getaddrinfo with the AI_ADDRCONFIG flag to not return ipv4 addresses. See also https://lists.debian.org/debian-devel/2020/07/msg00070.html Cheers, Julien On Fri, Jan 21, 2022 at 09:43:40AM -0300, Emmanuel Arias wrote: > Hi, > > Most of the tests that fail use *-ipv4 parameter. With ipv6 seems to be ok. > I don't know if that can give us some clues. > > Cheers, > > On Wed, Jan 19, 2022 at 12:52 PM Julien Puydt wrote: > > Hi, > > I check my packages in a schroot on my computer before uploading ; that > way I detect problems like missing deps or network access, and I'm > pretty confident things will go well on the buildd network. > > But today's upload of python-anyio is broken... and I'm clueless as to > why. From the repeated error, it looks like 'localhost' isn't known, > which doesn't make sense. > > Here is a link to the full log: > https://buildd.debian.org/status/fetch.php?pkg=python-anyio=all= > 3.5.0-1=1642600026=0 > > and a sample error: > > __ TestTCPListener.test_accept[asyncio-ipv4] > ___ > tests/test_sockets.py:464: in test_accept > async with await create_tcp_listener(local_host='localhost', > family=family) as multi: > anyio/_core/_sockets.py:236: in create_tcp_listener > gai_res = await getaddrinfo(local_host, local_port, family=family, > # type: ignore[arg-type] > anyio/_core/_sockets.py:419: in getaddrinfo > gai_res = await get_asynclib().getaddrinfo(encoded_host, port, > family=family, type=type, > anyio/_backends/_asyncio.py:1570: in getaddrinfo > result = await get_running_loop().getaddrinfo( > /usr/lib/python3.9/asyncio/base_events.py:856: in getaddrinfo > return await self.run_in_executor( > /usr/lib/python3.9/concurrent/futures/thread.py:58: in run > result = self.fn(*self.args, **self.kwargs) > /usr/lib/python3.9/asyncio/base_events.py:839: in _getaddrinfo_debug > addrinfo = socket.getaddrinfo(host, port, family, type, proto, > flags) > /usr/lib/python3.9/socket.py:954: in getaddrinfo > for res in _socket.getaddrinfo(host, port, family, type, proto, > flags): > E socket.gaierror: [Errno -2] Name or service not known > > If someone has a lead on the issue... > > Thanks, > > J.Puydt > >
Re: Bug#913976: ITP: python-hgapi -- module providing a pure-Python API to Mercurial
On 11/17/18 9:23 PM, Nick Morrott wrote: > Package: wnpp > Owner: Nick Morrott > Severity: wishlist > X-Debbugs-CC: debian-de...@lists.debian.org > > * Package name: python-hgapi > Version : 1.7.3 > Upstream Author : Fredrik Håård > * URL : https://github.com/haard/hgapi > * License : Expat > Programming Lang: Python > Description : module providing a pure-Python API to Mercurial > > hgapi is a pure-Python API to the Mercurial command-line, instead of the > internal Mercurial API. > > hgapi works for all versions of Mercurial, and will instantly reflect any > changes to the repository (including hgrc). > > hgapi is a dependency of yotta [1] > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908781 > Is there a particular reason yotta needs to use this instead of hglib, which: - is already in debian - is maintained by mercurial upstream - has pretty much the exact same package description as the above ? This seems like useless duplication. Thanks, Julien
Re: on keep providing python 2 packages
On Fri, Aug 19, 2016 at 08:19:46 +0100, Sandro Tosi wrote: > I got a feeling we are somehow discouraging the introduction of > python2 package in unstable (it was also discussed at the BoF). > > while i can see why we dont want to introduce new python2-only > package, i feel that just providing a py3k pkg while the module is > also py2 compatible is a disservice to our users: wether we like it or > not, python 2 is the de facto interpreter for python and not having a > module available will not just make everyone switch to py3k (i already > faced it a couple of times already, where i needed a module to extend > an already existing project, and it was not there) > > does anyone else agrees with this view? should we clarify that, when > available, python2 modules must be provided (along with their py3k)? > > apps/scripts are fine being py3k by default, but the underlying > modules has to be provided by for py2 if compatible. > Very much agree. Cheers, Julien
Re: Packaging/installing jupyter kernels
On Fri, Aug 5, 2016 at 14:07:51 +0200, Gordon Ball wrote: > Jupyter has been in experimental for a while and presumably will make it > to unstable in the not too distant future. > > Once that is done, what is the correct way for packages providing a > jupyter kernel to install it? > > * manually install kernel.json in /usr/share/jupyter/kernels/? > * build-depend on python3-jupyter-core and call `jupyter kernelspec > install` during build? > * runtime-depend and install in postinst instead? > * (something else) > The 'build-depend on jupyter-core and call kernelspec install during build' thing is what I've done for ipykernel, IIRC. Cheers, Julien
Re: Status of ipython-qtconsole
On Thu, May 19, 2016 at 18:53:29 +, PICCA Frederic-Emmanuel wrote: > Hello, > Hi Frederic-Emmanuel, > I saw that a bunch of jupyter projects were uploaded into experimental. > It would be nice to have also the qtconsole part. > > I would like to know if there is already an effort in order to package the > current > ipython-qtconsole. > > I would be glade to help package this module. > > One of my package (spyder) depends on this module > Not as far as I know. I'd be happy to review a package if that would help. Cheers, Julien
Re: CPython hash randomization makes some Python packages unreproducible
On Sat, Apr 9, 2016 at 13:25:39 -0400, Cara wrote: > I think a better solution is disabling hash randomization by setting > PYTHONHASHSEED=0 when building Python packages with CPython for Debian, > probably somewhere in dh-python. Note that this isn't necessary for > PyPy, which doesn't have hash randomization[7]. Hash randomization was > implemented to prevent, "[H]ash collisions [being] exploited to DoS a > web framework that automatically parses input forms into > dictionaries"[8]. This shouldn't be an issue at build-time, as any > time CPython is run to read in the files written during the build, hash > randomization will be enabled again. > FWIW I think that's a bad idea. A number of packages run their test suite at build time, and running the tests with hash randomization enabled seems to me like something we shouldn't give up. Couldn't packages where the binary packages contents depend on the hash seed just set one themselves? Cheers, Julien
Re: New, updated pip coming
On Fri, Jan 29, 2016 at 18:28:53 -0500, Barry Warsaw wrote: > I don't actually know whether Built-Using *does* anything useful[*], but IWBNI > (maybe) some kind of notification or auto-rebuild happened. I don't think it > does, but Donald's right. It's the same problem that Go or statically linked > C/C++ has. > ATM there's no automatic rebuild for out of date built-using. Its main use is to force the archive software to keep the source packages listed as Built-Using in the archive, to comply with GPL requirements. Cheers, Julien -- Julien Cristau <julien.cris...@logilab.fr> Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances
Re: mkdocs locale error building djangorestframework
On Mon, Jan 25, 2016 at 23:13:49 -0500, Barry Warsaw wrote: > On Jan 26, 2016, at 01:12 AM, Ben Hutchings wrote: > > >That's not the problem at all. Read the error message again. Read the > >source line it points to. Now look at where rv comes from: > > > import subprocess > rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE, > >... stderr=subprocess.PIPE).communicate()[0] > type(rv) > > > > For Python 3, try adding `universal_newlines=True` to any subprocess call. > You'll get back a str. > Or a UnicodeDecodeError. Cheers, Julien
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On Tue, Sep 29, 2015 at 12:26:44 +0100, Sandro Tosi wrote: > Once again, the python policy about Maintainer/Uploaders has been ignored > > http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership > https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin > > either policy changes or this has to stop at some point. > OTOH, this is experimental. It's not like this upload has any effect on anyone except to let Thomas work on packages that depend on it. Are there any specific changes you object to, and that can't be easily reverted before an upload to unstable? Cheers, Julien -- Julien Cristau <julien.cris...@logilab.fr> Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances
Re: Packaging the Jupyter project suite
Hi Julien,
On Fri, Sep 25, 2015 at 07:48:30 +0200, Julien Puydt wrote:
> There is also something else to discuss since it used to be only IPython :
> how to transition.
>
> Indeed, the current src:ipython package provides several binary packages:
> ipython (shell for Python 2), ipython3 (shell for Python 3),
> ipython-qtconsole (Qt shell for Python 2), ipython3-qtconsole (Qt shell for
> Python 3), ipython-notebook-common (data for the HTML IPython notebook),
> ipython-notebook (HTML IPython notebook for Python 2), ipython3-notebook
> (HTML IPython notebook for Python 3) and ipython-doc (documentation).
>
> But now, IPython upstream contains (afaik) what used to be in ipython and
> ipython3. There is an upstream qtconsole which should correspond to
> ipython-qtconsole and ipython3-qtconsole. And there is an upstream notebook
> which should correspond to ipython-notebook-common, ipython-notebook and
> ipython3-notebook.
>
> So, how does one do so users of those packages get the future new ones
The future qtconsole or jupyter-qtconsole source package will likely
have to build transitional ipython-qtconsole and ipython3-qtconsole
packages so user systems get upgraded. Likewise, the future
jupyter-notebook package should probably build transitional
ipython{,3}-notebook packages.
> (I'm sure a transition bug to release.debian.org will be needed)?
I don't believe so.
> What does one do to the bugs in the current src:ipython package?
The ones that are still relevant can be marked as found in the jupyter
packages as well, or reassigned, I don't think that's an issue.
Cheers,
Julien
--
Julien Cristau <julien.cris...@logilab.fr>
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances
Re: Bug #751908, tox, and bin-only Python packages
On Thu, Aug 6, 2015 at 17:08:35 +0200, Piotr Ożarowski wrote: [Barry Warsaw, 2015-08-06] Should there be a naming convention for Python packages which only provide an executable? everything that doesn't match python[\d.]*- is fine IMHO. If tox is too generic, use tox-python If tox is too generic, then that would also apply to /usr/bin/tox IMO. (Collisions over command names are even worse than collision over package names, since they have way more impact on users.) Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20150806152150.gk5...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20150720072935.ga1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Mon, Jul 20, 2015 at 09:56:55 +0200, Piotr Ożarowski wrote: [Julien Cristau, 2015-07-20] On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. dh_py* tools then No, since that would break sharing a namespace with parts installed as a debian package and parts using the normal python tools. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20150720080015.gb1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Mon, Jul 20, 2015 at 11:58:07 +0100, Dimitri John Ledkov wrote: On 20 July 2015 at 09:00, Julien Cristau julien.cris...@logilab.fr wrote: On Mon, Jul 20, 2015 at 09:56:55 +0200, Piotr Ożarowski wrote: [Julien Cristau, 2015-07-20] On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. dh_py* tools then No, since that would break sharing a namespace with parts installed as a debian package and parts using the normal python tools. And why should debian-python support that? Is that a serious question? Why should debian-python, for no good reason, break things that work just fine? Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20150720111214.gc1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Mon, Jul 20, 2015 at 13:12:14 +0200, Julien Cristau wrote: On Mon, Jul 20, 2015 at 11:58:07 +0100, Dimitri John Ledkov wrote: On 20 July 2015 at 09:00, Julien Cristau julien.cris...@logilab.fr wrote: On Mon, Jul 20, 2015 at 09:56:55 +0200, Piotr Ożarowski wrote: [Julien Cristau, 2015-07-20] On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: Should we patch distutils/setuptools to not generate them? It generates them even for Python 3.X (which has PEP420 implemented) Please don't. Using an pkg_resources-style vs PEP420 namespace should be an upstream decision made individually for each namespace. dh_py* tools then No, since that would break sharing a namespace with parts installed as a debian package and parts using the normal python tools. And why should debian-python support that? Is that a serious question? Why should debian-python, for no good reason, break things that work just fine? My point being, pkg_resources-style namespaces and PEP420-style namespaces are different beasts. Trying to (partly/automagically) convert one style to the other is disruptive and unwelcome. If you want to improve setuptools to support PEP420 namespaces then by all means do that, upstream, without breaking things that work fine today. Thanks, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20150720111819.gd1...@sh76.dev.logilab.fr
Re: -nspkg.pth and .pth files - should we get rid of them?
On Mon, Jul 20, 2015 at 07:58:13 -0400, Barry Warsaw wrote: On Jul 20, 2015, at 01:12 PM, Julien Cristau wrote: Is that a serious question? Why should debian-python, for no good reason, break things that work just fine? Because it doesn't really work well when you are supporting both Python 2 and Python 3. For example, if you have the 'foo' namespace with submodules 'bar' and 'baz', you can't write a foo/__init__.py that supports old-style namespaces for Python 2 and PEP 420 style namespaces for Python 3 because in the latter *you can't have an __init__.py at all*. That's exactly why Debian shouldn't mess with it. If upstream is python3-only, they can remove __init__.py and go PEP420. If not, they can use old-style namespaces on both python versions, and there's no reason for Debian to break that IMO. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20150720120404.ge1...@sh76.dev.logilab.fr
Re: Attempting to remove python-support?
On Sun, Apr 26, 2015 at 21:09:16 +0200, Vincent Bernat wrote: I am also in favor of removing python-support. It doesn't have any obvious bugs but having several helpers is confusing. pybuild + dh should be used for most packages. pybuild+dh is entirely orthogonal to python-support. I guess you meant dh_python2... Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20150427092011.gc1...@sh76.dev.logilab.fr
Re: About requests.packages.urllib3 in Debian
On Wed, Nov 5, 2014 at 07:52:55 +0100, Matthias Urlichs wrote: Hi, Daniele Tricoli: Due to #753578 I added a stub (technically I just used a symlink) to make import requests.packages.urllib3 works. I'd add a stub _file_ which just contains from urllib3 import *. Would that work for submodules? (I'm guessing no.) Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20141105090145.gc19...@crater2.logilab.fr
Re: python-openssl unavailable in sid
On Mon, Sep 8, 2014 at 09:57:36 +1000, Brian May wrote: As far as I can tell, this problem has been fixed. ftp-master didn't respond, maybe it come good by itself? No, they fixed it last week. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20140908082836.ga24...@crater2.logilab.fr
Re: python-pandocfilters_1.2.1-1_amd64.changes ACCEPTED into unstable, unstable
On Mon, Jul 28, 2014 at 17:33:48 +0200, Sebastian Humenda wrote: Hello Matthias, Matthias Klose schrieb am 28.07.2014, 14:27 +0200: Am 28.07.2014 um 14:00 schrieb Debian FTP Masters: Accepted: Format: 1.8 Date: Mon, 30 Jun 2014 10:04:06 +0200 Source: python-pandocfilters Binary: python-pandocfilters python3-pandocfilters Architecture: source all Version: 1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian Python Team debian-python@lists.debian.org Changed-By: Sebastian Humenda shume...@gmx.de please can we avoid using debian-python@lists.debian.org as a maintainer list for packages? Please tell me an alternate address and I'll fix it with the next upload. Before requesting the upload, I had asked on the list for someone to have a look at the package. After not receiving any comments after a while, I thought my package to be ok, including the maintainer address. See https://lists.debian.org/debian-python/2014/07/msg00097.html Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20140728153526.ga7...@crater1.logilab.fr
Bug#750638: ITP: ndg-httpsclient -- enhanced HTTPS support for httplib and urllib2 using PyOpenSSL
Package: wnpp Severity: wishlist Owner: Julien Cristau julien.cris...@logilab.fr * Package name: ndg-httpsclient Version : 0.3.2 Upstream Author : Science Technology Facilities Council (STFC) * URL : https://pypi.python.org/pypi/ndg-httpsclient * License : BSD Programming Lang: Python Description : enhanced HTTPS support for httplib and urllib2 using PyOpenSSL ndg-httpsclient is a HTTPS client implementation for httplib and urllib2 based on PyOpenSSL. PyOpenSSL provides a more fully featured SSL implementation over the default provided with Python and importantly enables full verification of the SSL peer. My main interest is to be able to talk to websites using SNI with scripts using python-requests. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20140605102621.ga17...@crater1.logilab.fr
Re: Bug#750638: ITP: ndg-httpsclient -- enhanced HTTPS support for httplib and urllib2 using PyOpenSSL
On Thu, Jun 5, 2014 at 10:24:48 -0400, Donald Stufft wrote: On Jun 5, 2014, at 7:09 AM, Daniele Tricoli er...@mornie.org wrote: Hello Julien, thanks for packaging ndg-httpsclient! On Thursday 05 June 2014 12:26:22 Julien Cristau wrote: My main interest is to be able to talk to websites using SNI with scripts using python-requests. Once in the archive I will also add ndg-httpsclient into python-requests' Suggests. Kind regards, P.S. I'll do the same for python-urllib3: https://github.com/shazow/urllib3/pull/156 -- Daniele Tricoli 'Eriol' http://mornie.org You need pyasn1, pyopenssl, and ndg-httpsclient in order for the requests/urllib3 stuff to kick in. It’d probably be a sane idea to use recommends, at least on Python 2.x since using that also prevents CRIME and the like which Python 2.x is vulnerable to else wise IIRC. My plan is for the ndg-httpsclient package to depend on pyopenssl and recommend pyasn1. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20140605143302.ga2...@crater1.logilab.fr
Re: Bug#736721: Incorrect dependencies
On Fri, Feb 7, 2014 at 15:04:47 +0100, Jonas Borgström wrote:
On 2014-02-07 12:12 , Jakub Wilk wrote:
What attic/crypto.py currently does is:
libcrypto = cdll.LoadLibrary(find_library('crypto'))
But there is no guarantee that find_library('crypto') returns a library
that is ABI-compatible with the Python code. For the Debian package, a
quickdirty fix is to replace the find_library() call with
'libcrypto.so.1.0.0', then hardcode libssl1.0.0 in Depends. But that of
course means that the package would need a sourceful upload by the next
OpenSSL transition.
You're right. The find_library('crypto') line itself won't guarantee
any ABI-compatibility but a Depends: libssl1.0.0 (= 1.0.0) line will.
No, because it doesn't guarantee that libssl1.1 is not installed, and
find_library('crypto') may well pick that one instead of the expected
libcrypto.so.1.0.0.
Cheers,
Julien
--
Julien Cristau julien.cris...@logilab.fr
Logilab http://www.logilab.fr/
Informatique scientifique gestion de connaissances
--
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/20140207140855.ga16...@crater1.logilab.fr
Re: usr/bin/ scripts for console_scripts which lead to binaries-have-file-conflict when python 2 + 3
On Mon, Dec 16, 2013 at 14:19:32 +0100, Olivier Berger wrote: Jakub Wilk jw...@debian.org writes: * Olivier Berger olivier.ber...@telecom-sudparis.eu, 2013-12-16, 13:24: - add a python-rdflib-tools package that contains shell scripts of the form : #!/bin/sh exec /usr/bin/python -m rdflib.tools.csv2rdf $* I can't see how that's better than a script with #!/usr/bin/python shebang... Well... it's essentially easier than altering the modules to provide them with a sheebang, making them executable and shipping symlinks... whose targets wouldn't be the same in the v2 and v3 package... - make this package depend on python-rdflib | python3-rdflib /usr/bin/python can't use the modules shipped by python3-rdflib. Ah, thanks for spotting this... I thought it was a bit too easy indeed ;) Hmmm... Maybe this is better : #!/bin/sh /usr/bin/python3 -c 'import rdflib.tools.csv2rdf' 2/dev/null if [ $? = 0 ] then exec /usr/bin/python3 -m rdflib.tools.csv2rdf $* else exec /usr/bin/python -m rdflib.tools.csv2rdf $* fi What do you think ? FWIW I think it's terrible and you should just pick one, and ship that. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20131216132452.gb6...@crater1.logilab.fr
Re: [PATCH] Support :any architecture qualifiers for multiarch
On Wed, Sep 18, 2013 at 14:33:00 -0500, Steve Langasek wrote: On Wed, Sep 18, 2013 at 06:24:13PM +0200, Jakub Wilk wrote: Following the “if it didn't happen on a mailing list, it didn't happen”, I repeat here what I said on IRC: 12:26 kwilk So I rebuilt src:python-aalib, and I ended up these Depends: python3:any (= 3.3.2-2~), libaa1. 12:27 kwilk This is wrong; the package only works if the interpreter architecture is the same as libaa1 architecture. 12:27 kwilk Please revert this :any mess. 12:30 kwilk In general, just because a script or a module is pure-Python doesn't mean it doesn't care about interpreter's architecture. 12:30 kwilk And there's no way to determine automatically whether it cares or not. Nonsense. It's not in the purview of the script/module to care about the architecture of the interpreter. There are cases for which a package that ships a python script / pure python module *does* care about the architecture of the interpreter, but this is *not* because of the script / module itself - it's only because of architecture-specific python extensions included in the same package, which is expressed via a separate arch-specific dependency on libpython; or because of restrictions on the architecture-availability of the other python modules the package depends on, which should be handled by the package manager and *not* hard-coded in the dependencies of the package in question. Well, in Jakub's case the module does dlopen(libaa.so.1), so while it doesn't care about the interpreter's architecture, it does need the libaa1 and python3 packages to be of the same architecture. AIUI Depends: python3:any, libaa1 doesn't express that? Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20130919073926.ga31...@crater1.logilab.fr
Re: [PATCH] Support :any architecture qualifiers for multiarch
On Thu, Sep 19, 2013 at 14:55:17 +0200, Piotr Ożarowski wrote:
[Julien Cristau, 2013-09-19]
Well, in Jakub's case the module does dlopen(libaa.so.1), so while it
doesn't care about the interpreter's architecture, it does need the
libaa1 and python3 packages to be of the same architecture. AIUI
Depends: python3:any, libaa1 doesn't express that?
as I mentioned on IRC, I think the solution for that is detecting lib*
or ${shlibs:Depends} in Depends (even in arch:all packages, see
pyenchant) and disable :any dependencies for such packages, at least
until we find a better solution for ctypes packages.
Oh $DEITY please please no.
Cheers,
Julien
--
Julien Cristau julien.cris...@logilab.fr
Logilab http://www.logilab.fr/
Informatique scientifique gestion de connaissances
--
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/20130919130506.gb31...@crater1.logilab.fr
Re: PEP 453 affects Debian packaging of Python packages
On Wed, Sep 18, 2013 at 09:38:57 +0200, Paul Wise wrote: We don't do private copies or bundled copies in Debian, so I guess the right way to go for Debian is to have python depend on python-pip and python3 depend on python3-pip? We don't do dependency loops without a good reason either (and no, this isn't one). Make it Recommends if you like, though I'd question the value of even that. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20130918074822.ga13...@crater2.logilab.fr
Re: dh-python in unstable
On Fri, Aug 2, 2013 at 15:15:36 +0200, Piotr Ożarowski wrote: Note that adding dh-python to Build-Depends enables multiarch support in dh_python2 What does that mean? Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20130802132340.gb15...@crater2.logilab.fr
Re: dh-python in unstable
On Fri, Aug 2, 2013 at 15:39:57 +0200, Piotr Ożarowski wrote: [Julien Cristau, 2013-08-02] On Fri, Aug 2, 2013 at 15:15:36 +0200, Piotr Ożarowski wrote: Note that adding dh-python to Build-Depends enables multiarch support in dh_python2 What does that mean? that means dh_python2 will rename /usr/lib/python2.7/dist-packages/foo/bar.so /usr/lib/python2.7/dist-packages/foo/bar_d.so into /usr/lib/python2.7/dist-packages/foo/bar.multiarch.so /usr/lib/python2.7/dist-packages/foo/bar.multiarch_d.so So it will rename stuff or not based on the Build-Depends field? That seems... wrong. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20130802135651.gc15...@crater2.logilab.fr
Re: how could I help?
On Fri, Jun 21, 2013 at 11:00:42 +0800, Paul Wise wrote: On Sat, Jun 15, 2013 at 6:40 PM, Stéphane Blondon wrote: Do you think I could help? If yes, how? A number of parts of Debian infrastructure are written in python, if you wanted to help out our core teams by writing python that would be great. There are dak (ftp team), ud (sysadmin team), various QA bits, the security tracker (security team) and probably more that I can't think of right now. Britney (-release) :) Cheers, julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20130625095118.gb31...@crater2.logilab.fr
Re: Circular build-dependency in python-webob
On Wed, Mar 13, 2013 at 00:59:42 +0800, Thomas Goirand wrote: There must be something wrong here. What makes you think that? Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20130312174412.gb26...@crater2.logilab.fr
Re: Removing /usr/bin/nosetests-3.x scripts
On Tue, Feb 26, 2013 at 10:32:56 -0500, Barry Warsaw wrote: On Feb 22, 2013, at 11:51 PM, Stefano Rivera wrote: 1. Status quo: Provide a nosetests-3.X script for the default version at build time. Pros: None Cons: - This potentially breaks unit tests if there are two supported 3.x versions. 2. Drop all nosetsts-3.X scripts. Pros: - Maintainers who were aware of the problems with 1 had to manually call python3.X /usr/bin/nostests3 anyway, so this doesn't cause them any harm. - Don't accidentally end up with dependencies on all python3.Xs Cons: - Maintainers who weren't needed their packages patched. 3. Apply a messy patch to generate scripts based on py3verions -s at build time. Pros: - Neat Cons: - It's ugly as hell - Have to do a sourceful upload for each python3 supported versions change - Will accidentally end up with dependencies on all python3.Xs 4. Use .rtinstall, .rtremove, postinst, and prerm scripts to maintain all the nosetsets-3.X scripts (pytest does this) Pros: - Neat - No accidental dependencies on all python3.Xs Cons: - You are creating and deleting things in /usr/bin in maintainer scripts - this made some people cringe. I wish we would do #4. I suppose it's a little cringe worthy, especially because (as you later point out) you'd probably also want to add versions for the -dbg flavors too. But that bothers me less than not having those scripts available, since I think users will expect them to be there. For example, the tox documentation example suggests calling nosetests (albeit, for Python 2) directly. http://tox.readthedocs.org/en/latest/example/nose.html?highlight=nose nosetests isn't going away, and this page doesn't seem to mention a versioned script. Is #4 really that horrible? IMO, yes. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20130226155240.gc21...@crater1.logilab.fr
Re: Solving the multiarch triplet once and for all
On Tue, Dec 18, 2012 at 10:40:56 -0500, Andrew Starr-Bochicchio wrote: On Tue, Dec 18, 2012 at 10:24 AM, Barry Warsaw ba...@python.org wrote: On Dec 18, 2012, at 02:22 PM, Julien Cristau wrote: Having some explanation of what's going on would definitely help. Is there a wiki or mailing list url that I missed and that describes what this is about? I don't think you missed anything specific to Python. The Debian multiarch effort is described in this wiki page (with lots of sub-links): This is the only thing I've come across: http://wiki.debian.org/Python/MultiArch Thanks, that helps (a little, anyway). Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20121220090108.ga23...@crater1.logilab.fr
Re: suffix for packages with (optional?) Python extensions
On Fri, Jul 13, 2012 at 11:57:01 -0400, Scott Kitterman wrote:
1. python{3}-foo which is arch all and follows the current naming convention
of foo being the name you import. It would depend on the arch any python-foo-
ext package.
all - any package dependencies are often icky, if you want them to be
strictly versioned. Probably not a showstopper, but something to be
aware of.
Cheers,
Julien
--
Julien Cristau julien.cris...@logilab.fr
Logilab http://www.logilab.fr/
Informatique scientifique gestion de connaissances
--
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/20120716075759.ga7...@crater1.logilab.fr
Re: suffix for packages with (optional?) Python extensions
On Mon, Jul 16, 2012 at 11:37:17 -0400, Scott Kitterman wrote: I think at least suggests, but I think recommends is better if it doesn't behave as a dependency loop. I haven't looked into how this gets handled yet. Anyone? Recommends should be fine AFAIK, since they don't impose any unpack/configuration ordering on the package manager. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20120716155806.gf7...@crater1.logilab.fr
Re: warning: package python-gdcm: unused substitution variable ${python:Versions}
On Mon, May 14, 2012 at 12:57:17 +0200, Piotr Ożarowski wrote:
[Jakub Wilk, 2012-05-14]
I do wonder however if there is a good reason for dh_python{2,3} to
still generate *:Version substitution variables.
is it safe to drop it? (i.e. is it used only in XB-Python-Version, as it
should?)
Some grepping in the lintian lab should be able to answer that.
Cheers,
Julien
--
Julien Cristau julien.cris...@logilab.fr
Logilab http://www.logilab.fr/
Informatique scientifique gestion de connaissances
--
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/20120514165118.ga20...@crater2.logilab.fr
Re: to distribute_setup() or not, that is the question
On Fri, Jan 27, 2012 at 11:14:18 -0500, Barry Warsaw wrote: On Jan 27, 2012, at 03:07 PM, Julien Cristau wrote: I think a build system downloading random stuff from random places on the internet is just as insane upstream as in debian... For upstream development, it's handy. I don't doubt it's handy. I just think it's insane. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20120127162036.gb27...@crater1.logilab.fr
Re: Alternate way to contact Python-modules-team mailing list?
On Wed, Oct 19, 2011 at 04:27:36 -0500, Paul Elliott wrote: Can someone please give me an alternate way to contact Python-modules-team mailing list. I am subscribed to this list. But my messages to the list bouce because of blacklist. I can not even send email to list-owner. I need to find some way to get myself un-blacklisted. The actual bounce message would probably help... Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20111019093515.ga23...@crater2.logilab.fr
Re: python2.7 as default: where are we? (Was: Bug#641207: ITP: ordereddict)
On Sun, Sep 18, 2011 at 23:58:26 +0200, Luca Falavigna wrote: Il 12/09/2011 09:53, Julien Cristau ha scritto: So out of these, I'd expect that libimobiledevice, gobject-introspection and pygobject (and maybe hplip?) need to be fixed, and the rest can hopefully be removed if they stay broken. libimobiledevice, pygobject and hplip are fixed, gobject-introspection just needs a binNMU after switching default. libimobiledevice is bumping SONAME, should be done in about a week. pygobject should also get into testing next week. hplip doesn't move to testing because of #635486, filed 2 months ago and with 0 reply. Here's a quick summary of the outstanding bugs [1]: UPLOADED TO DELAYED * lilypond (#606642) * revelation (#628852) * pychess (#635356) PATCHES AVAILABLE * poker-network (#629145) * setools (#631800) * pypoker-eval (#632234) * shogun (#632249) WITHOUT PATCHES * setools (#625678) * freevo (#629085) * openmeeg (#631856) * subvertpy (#632225) subvertpy is now fixed. [1] #622279 produces a 500 error, so this is based on data I previously collected in the bug report. And Don fixed this yesterday on the bts side. Cheers, Julien -- 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/20110920095907.ga22...@crater2.logilab.fr
Re: it's Python time now
On Wed, Mar 30, 2011 at 16:02:56 +0200, Piotr Ożarowski wrote: FYI: I plan to upload python-sphinx, python-defaults (without Python 2.5, with Python 2.7) and python3-defaults (with Python 3.2 instead of Python 3.2) tomorrow. Please report bug against tech-ctte and CC me if you think it's not a good idea. I think it's not a good idea. Cheers, Julien -- 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/20110330142256.gs3...@radis.liafa.jussieu.fr
Re: python transition incomplete
On Mon, Oct 4, 2010 at 12:08:04 +0200, Alessio Treglia wrote: On Sun, Sep 26, 2010 at 11:53 PM, Jakub Wilk jw...@debian.org wrote: pyliblo 0.8.1-2 Agreed, looks broken. Fixed in 0.8.1-3. Please unblock. Done. Cheers, Julien signature.asc Description: Digital signature
Re: Upload permission for PySide
On Sat, Sep 11, 2010 at 21:49:33 +0200, Didier 'OdyX' Raboud wrote: So from here I see some options (with my opinion in parentheses) i) Removing PySide from Squeeze (I think it would be sad). ii) Keeping the current PySide in Squeeze and request the maintainer (me) to provide patched versions (This option needs hard work for me, with unknown success chances. The fallback being the removal (i) doesn't help.) iii) Allow the PySide version currently in experimental to unstable-squeeze (This is IMHO the easiest way to fix the RCs while still being zero-risk and also implies an almost-1.0 PySide for Squeeze, which would be satisfactory for both upstream and myself.) iv) Allow me to upload the latest upstream releases to experimental and report the discussion to later times, with more recent upstream releases (This is obviously the preferred solution for upstream who doesn't want outdated versions in distributions. I very much understand why allowing this could not be possible. Furthermore, two updates that upstream wanted in are already in as patches [0,1], with one cheated in (it breaks the API, but I kept the SOVERSION) So personally I would rank the options from latter to first: iv) is preferable, i) is the least preferable. I would rank them pretty much the opposite way. It seems to me that if the bindings are still fast moving then whatever version we ship will be too old when users for them appear. Cheers, Julien signature.asc Description: Digital signature
Re: python transition incomplete
On Sun, Sep 26, 2010 at 21:49:28 +0200, Matthias Klose wrote: The easier solution would be to remove python2.5 from the list of supported python versions and rebuild. NAK. The solution to an incomplete python transition is not to introduce yet another one. Cheers, Julien signature.asc Description: Digital signature
Re: seeking advice for xcb-proto packaging
On Tue, Nov 4, 2008 at 19:06:57 +0100, Adeodato Simó wrote: (1) You should of course use python-central or python-support so that the xcbgen Python package is always available for all installed python versions. Hope that was your intention. :-) Yeah, I think I got that working. (2) If you do that, then AFAICS no more meddling is strictly required for things to work: the -p argument of c_client.py only appends the given path to the list of directories Python searchs for modules. Since it is appended at the end, the correct directory will be searched first. That was the missing piece, thanks. (3) The fact that xcb-proto.pc hardcodes a Python path is, uhm, bad. xcb-proto instalation script should take care of installing the Python files somewhere importable (e.g. the $prefix/lib/python2.5/... path you mentioned), and assume the 'import xcbgen' statement in c_client.py will work in any system with xcb-proto installed (the -p flag could still be supported, that's orthogonal). I'll sed the pythondir to /nonexistent in the .pc file, to avoid any problem with this. Putting a Python path in the .pc file means xcb-proto has to be recompiled whenever the default Python version changes. Maybe somebody on the list can take care of educating upstream about this, if this analysis is correct, which I believe it is. Was that clear enough? :-) It was, thanks again! Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
seeking advice for xcb-proto packaging
Hi, xcb-proto upstream installs a few python files[1], which are then used at build time by libxcb[2]. Using the upstream build system, these files get installed to $prefix/lib/python2.5/site-packages/xcbgen, and that path is set in xcb-proto.pc's pythondir variable. The libxcb build then uses that variable to look for xcbgen[3,4]. Now that seems bad to me, because it means the python version gets hardcoded in the pkgconfig file, and when we switch to python 2.6 c_client.py will still look in the python2.5 dir, and presumably find the .pyc files there. Can anyone here suggest a way to fix this, either by working around it in the packaging or as a patch that I could send upstream? python is very much an unknown beast to me, so hopefully you'll have some ideas :) Note that none of this is in the debian xcb-proto and libxcb packages yet, but I'm looking at packaging the next version and this issue is sort of blocking progress. Thanks in advance, Julien [1] http://cgit.freedesktop.org/xcb/proto/tree/xcbgen [2] http://cgit.freedesktop.org/xcb/libxcb/tree/src/c_client.py [3] http://cgit.freedesktop.org/xcb/libxcb/tree/configure.ac#61 [4] http://cgit.freedesktop.org/xcb/libxcb/tree/src/Makefile.am#265 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
