[Python-modules-team] Bug#891865: src:python-cffi: please ship a python-cffi-doc package

Package: src:python-cffi Version: 1.11.5-1 Severity: wishlist cffi has nice docs, nicely formatted. It'd be great to be able to ship them in debian so that developers could have a local version that matches the version they have installed, and wouldn't have to rely on being online to read

[Python-modules-team] Bug#876761: python3-ipython depends on python-pexpect instead of python3-pexpect

On Mon 2017-09-25 11:44:25 -0400, Daniel Kahn Gillmor wrote: > python3-ipython should Depend: python3-pexpect, not python-pexpect. > > It looks like this is due to be fixed already in packaging commit > 467513c63897c3182ffdc942a03355066d940706, so hopefully it will get > fixed an

[Python-modules-team] Bug#876761: python3-ipython depends on python-pexpect instead of python3-pexpect

Package: python3-ipython Version: 5.1.0-3 Severity: normal Control: tags -1 pending python3-ipython should Depend: python3-pexpect, not python-pexpect. It looks like this is due to be fixed already in packaging commit 467513c63897c3182ffdc942a03355066d940706, so hopefully it will get fixed and

[Python-modules-team] Bug#836555: Bug#836555: marked as done (kivy: docs describe short gpg key usage)

Control: reopen 836555 Control: tags 836555 + upstream Control: forwarded 836555 https://github.com/kivy/kivy/pull/4582 vincent cheng wrote: > On Sat, Sep 3, 2016 at 3:40 PM, D Haley wrote: >> Source: kivy >> Version: 1.9.1-1 >> Severity: normal >> >> Dear Maintainer, >> >> Your

Re: [Python-modules-team] python-xdo vs. python-libxdo

On Thu 2016-01-28 08:53:22 -0500, Samuele Santi wrote: > +1 from me great :) > If this is going to be packaged in Debian, I'll take some time to give the > project a better structure / make sure tests work properly / document all > the implemented & tested functionality (so it's clear what can

[Python-modules-team] python-xdo vs. python-libxdo

hi folks-- i'm the upstream author of python-xdo, which is a minimalist C implementation of bindings atop libxdo, a toolkit for simulating/generating X11 events. It's not currently widely used. (i'm a contributor to the only reverse-dependency in debian). I recently discovered

[Python-modules-team] Bug#810260: Bug#810260: python-getdns: FTBFS: error: "GETDNS_TRANSPORT_STARTTLS" undeclared

Control: reassign 810260 getdns Control: affects 810260 python-getdns Control: retitle backward-incompatible API change in getdns 0.9.0 In https://bugs.debian.org/810260, Chris Lamb wrote: > Source: python-getdns > Version: 0.5.0-1 > Severity: serious > Justification: fails to build from source >

[Python-modules-team] Bug#771794: Bug#771794: Bug#771794: pip silently removes/updates system provided python packages

On 12/02/2014 11:51 AM, Donald Stufft wrote: I'd very much prefer it if you didn't do this. This *is* going to break things for people and it's going to cause a bunch of confusion. It's not clear to me which side you're arguing for. can you clarify which action is going to break things for

[Python-modules-team] Bug#771794: Bug#771794: pip silently removes/updates system provided python packages

On 12/02/2014 10:38 PM, Scott Kitterman wrote: On Tuesday, December 02, 2014 19:28:20 Donald Stufft wrote: So what if Debian just patched python-pip so that it doesn’t remove the files from /usr/lib (but it would remove files from /usr/local etc). This would have the effect of pip not touching

[Python-modules-team] Bug#736525: python-gnutls: please rebuild python-gnutls against newer GnuTLS API (libgnutls28-dev)

Package: python-gnutls Version: 1.2.5-1 Followup-For: Bug #736525 python-gnutls 2.0 was recently released, and it only builds against gnutls 3 (the libgnutls28 API). If we can get this into debian, then this bug will be resolved :) If it would be useful, i can provide a patch. Thanks,

Re: [Python-modules-team] python-levenshtein

Thanks Stuart for pointing this stuff out, and to Stuart and Sandro for offering to work on it. I'm happy that we'll be seeing python3-levenshtein in debian soon. On 02/01/2014 07:57 AM, Stuart Prescott wrote: That was just information for interested readers who were wondering where the

[Python-modules-team] Bug#736525: python-gnutls: please rebuild python-gnutls against newer GnuTLS API (libgnutls28-dev)

Package: python-gnutls Version: 1.2.4-1 Severity: normal libgnutls26 is an older API that is unsupported upstream. Please rebuild python-gnutls against libgnutls28-dev, which is the upstream-supported API. Thanks, --dkg -- System Information: Debian Release: jessie/sid APT prefers

[Python-modules-team] Bug#736525: Bug#736525: python-gnutls: please rebuild python-gnutls against newer GnuTLS API (libgnutls28-dev)

On 01/24/2014 10:32 AM, Dimitri John Ledkov wrote: Please see all the discussion around license incompatibilities of gnutls28 vs 26, and openssl. I'm aware of that discussion, thanks :) GnuTLS 28 is GPLv3 only, and if python-gnutls is rebuild against 28, then all reverse-dependencies must be

[Python-modules-team] Bug#736247: Fwd: Bug#736247: python-xdg: get_runtime_dir(strict=False): insecure use of /tmp

as reported by Jakub Wilk in http://bugs.debian.org/736247, there is a TOCTOU failure in python's xdg module (see attached message). Could a CVE be assigned to this? --dkg ---BeginMessage--- Package: python-xdg Version: 0.25-3 Severity: important Tags: security

Re: [Python-modules-team] [Openstack-devel] ITP: python-gear -- python-gear: pure python async library to interact with, gearman

On 10/01/2013 05:01 PM, Scott Kitterman wrote: Julien Danjou a...@debian.org wrote: This is not OpenStack related at all, there's no reason to limit its maintenance to the OpenStack team. I don't think the Python module team aims to switch to Git, so collab-maint would be a good choice if git

Re: [Python-modules-team] Bug#709138: Bug report contains non-free content and cannot be processed

On 05/21/2013 03:15 PM, Clint Byrum wrote: On 2013-05-21 09:59, Jakub Wilk wrote: * Scott Kitterman sc...@kitterman.com, 2013-05-21, 06:20: What do you mean by non-free content? The reporter specified the bug report was covered by non-free license. Oh come on. Sure, it's silly to release a

Re: [Python-modules-team] Bug#709138: Bug report contains non-free content and cannot be processed

On 05/21/2013 10:23 PM, Scott Kitterman wrote: On Tuesday, May 21, 2013 03:30:06 PM Daniel Kahn Gillmor wrote: For clarity: the original poster of #709138 asked no such thing; the poster merely asserted a CC BY-NC license in the .sig of their e-mail. No, they said, My quotes in this email

Re: [Python-modules-team] Sponsor needed for python-itsdangerous

On 04/06/2013 02:30 PM, Jakub Wilk wrote: Insisting that all binary packages should have ${python:Depends} will cause tons of false positives; let's not go that way. I think Lintian should emit the tag only if none of the binary packages have ${python:Depends}. This is not bulletproof, but

Re: [Python-modules-team] Sponsor needed for python-itsdangerous

On 04/05/2013 11:07 AM, Jakub Wilk wrote: Lintian has already this: http://lintian.debian.org/tags/python-depends-but-no-python-helper.html Implementing the reverse, i.e. python-helper-but-no-python-depends, should be very straight-forward and give good results. how should the reverse test

Re: [Python-modules-team] Sponsor needed for python-itsdangerous

On 04/02/2013 12:49 PM, Jakub Wilk wrote: ${python:Depends} is missing from your Depends line. This is a serious bug. the built package has the minimum python dependencies already, but you're right that it doesn't include the maximum deps (e.g. Depends: doesn't say python ( 2.8) ). This seems

Re: [Python-modules-team] Sponsor needed for python-itsdangerous

Hi Simon-- On 04/01/2013 04:52 PM, Simon Fondrie-Teitler wrote: In anticipation of mediagoblin needing itsdangerous starting with the next release, I've created a package for itsdangerous. I've uploaded it here: https://mentors.debian.net/package/python-itsdangerous This packaging looks very

Re: [Python-modules-team] python-xdo (http://bugs.debian.org/698020)

On 01/22/2013 10:52 AM, Jakub Wilk wrote: * Daniel Kahn Gillmor d...@fifthhorseman.net, 2013-01-21, 18:35: Is maintaining modules in svn a requirement for putting them under the python-modules-team umbrella? Yes, that's the status quo. hm, ok, i'll leave python-xdo outside of the python

Re: [Python-modules-team] python-xdo (http://bugs.debian.org/698020)

On 01/21/2013 06:20 PM, Jakub Wilk wrote: * Daniel Kahn Gillmor d...@fifthhorseman.net, 2013-01-12, 19:33: Any objections to my setting up a git repository for python-xdo under python-modules-team's section on alioth? Well, we use Subversion as VCS... not for everything, apparently: 0 dkg

Re: [Python-modules-team] python-xdo (http://bugs.debian.org/698020)

On 01/21/2013 06:29 PM, Paul Tagliamonte wrote: $ apt-cache show git-svn i'm aware of git-svn. i've never seen it work reasonably well with multi-branch repositories, though it's entirely possible that was due to bugs in the usage on my part. Is maintaining modules in svn a requirement for

[Python-modules-team] python-xdo (http://bugs.debian.org/698020)

hi folks-- I just uploaded python-xdo to experimental, closing ITP #698020. It provides some bindings for libxdo, a library to generate X11 input events and generally manipulate an X session. I'm the upstream for the python bindings, and i'm the debian maintainer for xdotool (the source of

Re: [Python-modules-team] python-xlrd update; and: make python-modules git repos public?

On 12/04/2012 04:28 PM, Daniel Kahn Gillmor wrote: I'm a new member of the python-modules team (thanks Piotr) coming over here from the python-apps team. I just ran into a need for an updated python-xlrd, and i've updated the packaging for it. Any objections to my python-xlrd 0.8.0-1 upload

[Python-modules-team] python-xlrd update; and: make python-modules git repos public?

Hi folks-- I'm a new member of the python-modules team (thanks Piotr) coming over here from the python-apps team. I just ran into a need for an updated python-xlrd, and i've updated the packaging for it. However, i work and collaborate more comfortably in git these days than svn, so if

[Python-modules-team] Bug#551958: python-openssl should document permission for name from OpenSSL project

Package: pyopenssl The OpenSSL license says: * 5. Products derived from this software may not be called OpenSSL *nor may OpenSSL appear in their names without prior written *permission of the OpenSSL Project. pyopenssl (and derived binary packages) seem to fall under the scope of