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 readthe
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
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 re
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 package appears t
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 be
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 https://github.com
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
>
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 to
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 p
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,
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
> upda
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
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 testing
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
--- Begin Message ---
Package: python-xdg
Version: 0.25-3
Severity: important
Tags: security
xdg.BaseDirectory.get_
On 10/01/2013 05:01 PM, Scott Kitterman wrote:
> Julien Danjou 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 is ret
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 sai
On 05/21/2013 03:15 PM, Clint Byrum wrote:
> On 2013-05-21 09:59, Jakub Wilk wrote:
>> * Scott Kitterman , 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 bug
On 04/08/2013 12:17 PM, Jakub Wilk wrote:
> * Daniel Kahn Gillmor , 2013-04-06, 15:05:
>>> Insisting that all binary packages should have ${python:Depends} will
>>> cause tons of false positives; let's not go that way.
>>>
>>> I think Lintian sh
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, b
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 tes
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 seem
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 ve
On 01/22/2013 10:52 AM, Jakub Wilk wrote:
> * Daniel Kahn Gillmor , 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 out
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 put
On 01/21/2013 06:20 PM, Jakub Wilk wrote:
> * Daniel Kahn Gillmor , 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, appar
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 libxd
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
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 possible,
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
29 matches
Mail list logo
