Re: python-cryptography, Rust, and OpenSSL 3.0

> python-cryptography_3.4.8-1_source.changes uploaded successfully to localhost On Wed, 1 Dec 2021 at 21:38, Tristan Seligmann wrote: > On Wed, 1 Dec 2021 at 21:34, Stefano Rivera wrote: > >> Hi Simon (2021.12.01_12:31:20_+) >> > Now that the OpenSSL 3 transition

Re: python-cryptography, Rust, and OpenSSL 3.0

On Wed, 1 Dec 2021 at 21:34, Stefano Rivera wrote: > Hi Simon (2021.12.01_12:31:20_+) > > Now that the OpenSSL 3 transition has started in Ubuntu, I plan on > > uploading this package to our archive as I lack the time to do the > > necessary work for the Rust enablement, but I'm wondering if

Re: upstream python concerns, python3-full package for bullseye

On Fri, 12 Feb 2021 at 02:43, wrote: > From your arguments above, it doesn't sound like the python3-full solves > a problem you experience. So, I'm not sure why you'd be using it. > > If it doesn't include distutils, venv, lib2to3, etc. then it doesn't > solve any problem we currently have, and w

mercurial-git

Hi all, Regarding #961245: > Ideally this should be fixed by renaming the hg-git's module back to what > upstream uses. But of course this is going to break all hg-git users' > configurations. :-/ I've gone ahead with this change in hg-git 0.9.0-1, with a NEWS.Debian entry alerting users. Brea

Re: Bug#916682: python-cryptography: build from source fails with libssl-dev_1.1.0j-1~deb9u1 amd64

I suspect this is fixed upstream but I am unable to take care of uploading a new version for the next few weeks. An NMU / team upload would be appreciated!

Re: Bug#902592: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

On Fri, 29 Jun 2018 at 14:40 Andreas Tille wrote: > Would you mind filing an according bug report we could refer to? > I've filed this as #902784 although I haven't had the chance to investigate the cause further. (Probably some minor packaging error)

Re: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

On Fri, 29 Jun 2018 at 14:20 Andreas Tille wrote: > Hi Tristan, > > On Fri, Jun 29, 2018 at 01:31:31PM +0200, Tristan Seligmann wrote: > > This is a cython bug; cython-dbg fails to ship the StringIOTree extension > > module, so the regular non-debug module is found whe

Re: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

This is a cython bug; cython-dbg fails to ship the StringIOTree extension module, so the regular non-debug module is found when doing a debug build but fails to load. On Fri, 29 Jun 2018 at 13:18 Andreas Tille wrote: > Control: tags -1 help > > I agree with Ghislain that the issue below might be

Re: Next python-mote pre-condition test issue: python-jsondiff trows ModuleNotFoundError: No module named 'nose_random'

On Tue, 16 Jan 2018 at 22:45 Andreas Tille wrote: > My web search for a module named 'nose_random' remained empty. > I found this package, which seems to match, from the same organization: https://github.com/ZoomerAnalytics/nose-random Unfortunately it seems to be unreleased, so I think you wou

Re: Please help with test suite error and installation problem of python-aws-xray-sdk (Was: If there is no response in debian-python then debian-science might be the right team)

On Mon, 15 Jan 2018 at 13:59 Andreas Tille wrote: >SyntaxError: invalid syntax > !!! Interrupted: 4 errors during collection > > All of these syntax errors relate to syntax that only exist on Python 3, thus I would conclude that this package does not supp

Re: /usr/bin/python2 in shebangs?

On Thu, 14 Dec 2017 at 15:39 Piotr Ożarowski wrote: > I plan to prepare new dh-python upload soon and hence a question about > a bit controversial change: should dh_python2 (as we discussed during > last DebConf's Python BoF) replace /usr/bin/python shebangs with > /usr/bin/python2? > Since on a

Bug#884064: ITP: jsonrpclib-pelix -- This project is an implementation of the JSON-RPC v2.0 specification (backwards-

Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: jsonrpclib-pelix Version : 0.3.1 Upstream Author : Thomas Calmant * URL : http://github.com/tcalmant/jsonrpclib/ * License : Apache License 2.0 Programming Lang: Python Description

Re: Question about binary sphinx inventory files

On Sat, 26 Aug 2017 at 00:20 W. Martin Borgert wrote: > I believe that a small number of Python module doc packages use > binary Sphinx inventory (.inv) files during build, that are just > downloaded from python.org by the package maintainer. I don't > know anything about Sphinx nor how to encode

Re: removing python3-trollius

On Mon, 10 Jul 2017 at 11:45 Michael Hudson-Doyle < michael.hud...@canonical.com> wrote: > > python3-trollius fails tests with Python 3.6 and rather than think about > why, I think it makes more sense to stop building trollius for Python 3. > Sounds reasonable to me!

Re: Bug#866668: src:python-cryptography: Misbuild with more than one supported python3 version

Control: severity -1 important On Fri, 30 Jun 2017 at 19:33 Scott Kitterman wrote: > Technically, it builds, but in a way that's not useful. It would actually > be > better if it had failed (I noticed this from reviewing build logs after the > python3 interpreter depends weren't generated corre

Re: No longer uploading mercurial

On Sat, 20 May 2017 at 12:39 Javi Merino wrote: > I have been uploading mercurial for some years, but since November I'm > struggling to find time to work on the package. I don't think I will > have time to keep up with mercurial's release schedule when stretch is > released. > I'm listed in Up

Re: python-modules-commits ml not receiving all commits?

On Wed, 5 Apr 2017 at 15:08 Sandro Tosi wrote: > Hello there, > it looks like > http://lists.alioth.debian.org/pipermail/python-modules-commits/2017-April/thread.html > is not receiving all the commits to our repo, f.e. i know numpy has > been updated yday and today, but none of the commits area

Re: Problems upgrading r-cran-fastcluster due to failed test in Python module

On Thu, 17 Nov 2016 at 12:25 Gard Spreemann wrote: > The weird thing is that this error does not occur when building on my > ordinary system (outside of the pbuilder chroot). Does pbuilder not > allow non-ASCII output or something? > Pbuilder is probably defaulting the locale to C, whereas your

Re: Joining

Hi all, I think this email slipped through the cracks; could one of the alioth admins look at this? (I have been working with / sponsoring Richard on such packages as python-trezor) On Tue, 2 Feb 2016 at 22:30 Richard Ulrich wrote: > Hi, > > I would like to join the team, in order to maintain

Re: pypy pakages

On Tue, 10 May 2016 at 23:29 Stefano Rivera wrote: > Hi Michael (2016.05.10_19:23:33_+0200) > > is there a specific reason why there are so few pypy-* packages in the > > archive? Is it just a lack of interest or are any practical reasons not > > to have them? > > I think we're all kind of waitin

Re: Test suite in github but missing from pypi tarballs

Resending to the list since I accidentally replied off-list! On Thu, 21 Apr 2016, 20:14 Tristan Seligmann, wrote: > On Thu, 21 Apr 2016 at 19:34 Barry Warsaw wrote: > >> I also don't particularly like relying on GitHub generated tarballs. >> Despite >> popular bel

Re: Test suite in github but missing from pypi tarballs

On Thu, 21 Apr 2016 at 16:47 Edward Betts wrote: > Debian binary packages don't normally include the test suite. Some Python > library developers are treating the pypi releases in a similar way, as if > they're just for deployment. They think anybody who needs the test suite is > doing developmen

Bug#815387: ITP: python-attrs -- Python attributes without boilerplate

Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: python-attrs Version : 15.2.0 Upstream Author : Hynek Schlawack * URL : https://github.com/hynek/attrs * License : MIT Programming Lang: Python Description : Python attributes

Bug#811386: ITP: python-genty -- Python library for test generation

Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: python-genty Version : 1.3.0 Upstream Author : Box * URL : https://github.com/box/genty * License : Apache 2.0 Programming Lang: Python Description : Python library for test

Bug#808605: ITP: python-flaky -- Plugin for nose or py.test that automatically reruns flaky tests

Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: python-flaky Version : 3.0.1 Upstream Author : Box * URL : https://github.com/box/flaky * License : Apache License Programming Lang: Python Description : Plugin for nose or

Re: Help with pytest 2.8.5

On Thu, 17 Dec 2015, 14:16 Piotr Ożarowski wrote: > > I didn't test it but... why is override_dh_auto_test needed at all? > Did you try with: > Ah sorry, my diff was against the old debian/rules which didn't use pybuild. However the same problem may happen if pybuild chdir()s to the build direc

Re: Help with pytest 2.8.5

On Thu, 17 Dec 2015 at 02:17 Barry Warsaw wrote: I've made some significant changes to the packaging by switching it to > pybuild. That's not the problem though. ;) The problem is that I can't > get > the test suite to run cleanly during package build. I'm seeing two > failures > in testing/te

Re: Pushing a bunch of packages to jessie-backports

On Thu, 26 Nov 2015 at 10:32 Piotr Ożarowski wrote: > > This is not the policy for backports. Amend the policy if you > > disagree. It's not fair to kick Zigo because he didn't follow the rules > > and consider oneself above them when he respects them. > > fix it yourself, I'm getting all the bug

Re: [Python-modules-team] django-ajax-selects is marked for autoremoval from testing

The date in the mail is the date on which the package will be removed from testing if the cause for it being marked for autoremoval is not rectified; in other words, you would still have until 2015-11-05 to resolve the problem. In this case, the cause is the RC bug which is fixed in 1.3.6-4. Howev

Re: RFS updating the setuptools-scm and mistune packages

On Wed, 30 Sep 2015 at 13:55 Julien Puydt wrote: > ssh://git.debian.org/git/python-modules/packages/mistune.git > ssh://git.debian.org/git/python-modules/packages/setuptools-scm.git > Uploaded.

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

On Wed, 30 Sep 2015 at 10:45 Thomas Goirand wrote: > On 09/29/2015 04:02 PM, Tristan Seligmann wrote: > > but I'm not sure that having someone > > blindly upload my packages if they haven't worked on them before is a > > good idea. > > If this is what you t

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

On Tue, 29 Sep 2015 at 15:48 Barry Warsaw wrote: > The wiki says that the general rule of thumb is to set the team as > Maintainer, > to which I agree. I may not have been as deliberate about my own > packages, so > I plan on reviewing them, and will fix any that aren't "special". > After readi

Re: RFS: ipython-genutils -- IPython vestigial utilities

On Sat, 12 Sep 2015 at 18:46 Julien Puydt wrote: > The package is now available here: > Vcs-Git: > git://anonscm.debian.org/python-modules/packages/ipython-genutils.git > Vcs-Browser > > : > http://anonscm.debian.

Re: RFS: path.py -- module wrapper for os.path

On Thu, 17 Sep 2015 at 16:11 Julien Puydt wrote: > Hi, > > I'm looking for a sponsor for: > > * Package name: path.py > Uploaded and tagged.

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

On Mon, 8 Jun 2015 at 15:27 Tristan Seligmann wrote: > >>> import ipaddr, ipaddress > >>> ipaddress.ip_address(b'\x7f\x00\x00\x01') > IPv4Address(u'127.0.0.1') > >>> ipaddr.IPAddress(b'\x7f\x00\x00\x01') > Traceback (most

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

Control: tag -1 - wontfix On Fri, 22 May 2015 at 17:06 Scott Kitterman wrote: > There are far more users of ipaddr than ipaddress. There's exactly two > API differences. I'm willing to look at pip and propose a patch to work > with either. > I've discovered yet another API incompatibility whi

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

On 22 May 2015 at 16:06, Tristan Seligmann wrote: > Or are you saying that the ipaddress backport is not compatible with > python3 stdlib's ipaddress? (This would be a very unfortunate state of > affairs, but impossible to imagine) This should have been "*not* imp

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

On 22 May 2015 at 15:43, Donald Stufft wrote: > I'm not sure if I was looking at the wrong ipaddr or something but the > documentation I found was pretty crappy and looking at it I didn't see how to > actually use ipaddr the same way I was using ipaddress in pip. In addition to > that, the API doe

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

Control: tag -1 + wontfix On 14 May 2015 at 13:45, Scott Kitterman wrote: > Is this 100% compatible with ipaddress from upstream now? The problem I ran > into before is that when importing ipaddress and it turned out to be this one > and not the upstream one, the API was different, so it didn't

Re: Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

On 14 May 2015 at 06:04, Scott Kitterman wrote: > Why can't python-cryptography use python-ipaddr that's already in the archive? cryptography is python2/3 dual-source. Carrying a Debian-specific patch[1] that introduces a slew of fallback imports to ipaddr, solely to avoid uploading a new package

Bug#785275: ITP: python-ipaddress -- Backport of the ipaddress module from Python 3.3

Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: python-ipaddress Version : 1.0.7 Upstream Author : Philipp Hagemeister * URL : https://github.com/phihag/ipaddress * License : PSF Programming Lang: Python Description : Backport

Re: Sample DPMT SVN-GIT migration

On 1 May 2015 at 16:46, Barry Warsaw wrote: > Also, I just saw that git-buildpackage(1) has gone away. It seem like all we > have now is gbp(1) but that has a different cli, and I think it has pq > built-in. `gbp buildpackage` and `git-buildpackage` have identical options and behaviour. The latt

Re: git packaging (was: Python packaging help.)

On 31 March 2015 at 17:46, Zygmunt Krynicki wrote: > > Is there a way to use git but build with sbuild. I kind of don't want > to go back to pbuilder and IIRC git-buildpackage requires it. I build packages with --git-builder=sbuild all the time, and haven't had any issues. You can also build sour

Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)

On 5 February 2015 at 22:59, Piotr Ożarowski wrote: > [Tristan Seligmann, 2015-02-05] >> Now add an option to make it do pgpsigurlmangle ;P > > done (only if last release has a signature, though) Awesome, thanks! -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBS

Re: Debian uscan redirector for PyPI (was: PyPI and debian/watch)

On 5 February 2015 at 01:12, Piotr Ożarowski wrote: >> http://pypi.debian.net/hy.watch > > or better: http://pypi.debian.net/hy/watch Oooh, nice! Now add an option to make it do pgpsigurlmangle ;P -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBSCRIBE, email to debian-python-requ..

Re: PyPI and debian/watch

On 4 February 2015 at 10:05, Ben Finney wrote: > Tristan Seligmann writes: > >> The debian/watch file I wrote for python-nacl (which also verifies the >> PGP signature) seems to work. > > I can't get PGP signature retrieval to rowk (“uscan warning: > pgpsig

Re: PyPI and debian/watch

On 4 February 2015 at 00:40, Barry Warsaw wrote: > Unfortunately, I've not been able to get either the one described here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776267#10 > > or another one that came up in #debian-python to work. The debian/watch file I wrote for python-nacl (whic

Re: Status of pythondialog in Debian

On 22 October 2014 09:47, Florent Rougon wrote: > It is in unstable, thank you! I wonder if the new package > (python3-dialog) should not have Conflicts and Replaces with > python-dialog. Although I suppose both packages can be installed at the > same time, the current situation may leave the old,

Re: Keeping upstream commits separate from Debian packaging commits

On 20 October 2014 19:55, Barry Warsaw wrote: > It occurs to me too that the switch from svn to git (e.g. git-dpm) is already > a large change to current team workflow, and dropping pristine-tar might just > be too big a move to also do right now. We're not using pristine-tar with svn, right now;

Re: Status of pythondialog in Debian

On 19 October 2014 23:21, Florent Rougon wrote: > Thank you very much, that was quick! I have subscribed using: > > > http://packages.qa.debian.org/cgi-bin/pts.cgi?what=advanced&package=source_package_name&email=y...@email.com > > The package is already uploaded, right? It is, and processed th

Re: Status of pythondialog in Debian

On 19 October 2014 14:40, Florent Rougon wrote: > would be glad to be co-maintainer of the package. (I am a former DD, so > maybe there is some account (frn) to reuse instead of creating a new > one...) Looks like your Debian account is marked emeritus; if you wish to re-activate it you could fol

Re: Status of pythondialog in Debian

On 17 October 2014 17:59, Florent Rougon wrote: > Barry Warsaw wrote: > >> Please note that this is not a team-maintained package. We could do a >> non-maintainer upload of it, but I'd rather see either 1) Adam, the current >> maintainer CC'd here, update the package, or 2) have Adam move the pa

Re: Keeping upstream commits separate from Debian packaging commits

On 17 October 2014 17:19, Dimitri John Ledkov wrote: > There are different tag types in git. "Soft" are just named commit > references and indeed can be renamed at will / point to new commits, > however signed tags encode: > object SHA1id > type type-of-above > tag tag-name > tagger normal user na

Re: Keeping upstream commits separate from Debian packaging commits

On 16 October 2014 20:12, Hans-Christoph Steiner wrote: > > > Tristan Seligmann wrote: >> If you are fetching the upstream revisions / tags into your packaging >> repository, you can use the upstream tag exactly as-is, no need to >> re-tag (and indeed re-tagging wo

Re: How to solve #751375, file clash

On 16 October 2014 23:55, Brian May wrote: > Is the configparser.py supplied by python-pies2overrides different from the > file supplied by python-configparser? > > If it is the same file, you could delete it from python-pies2overrides and > depend on python-configparser. The pies2overrides conf

Re: Keeping upstream commits separate from Debian packaging commits

On 16 October 2014 18:01, Thomas Goirand wrote: > Using pristine-tar and pulling from upstream VCS is silly. If you do > like this, then why not just doing tag-based packaging? That's a lot > safer than just re-tagging on top of what upstream does (ie: no risk to > introduce any difference). If y

Re: Keeping upstream commits separate from Debian packaging commits

On 13 October 2014 00:19, Barry Warsaw wrote: > Maybe not mutually exclusive, but what's the point? I certainly would not > base the Debian packaging on anything but the upstream tarball, and most git > workflows provide those as an unpacked upstream source branch. Does upstream > vcs add value?

Re: Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)

On 12 October 2014 12:36, W. Martin Borgert wrote: > Isn't pristine-tar deprecated by its author? I read > https://bugs.debian.org/737871 and That's interesting, I didn't know about that. I'm not really sure I understand how dgit replaces pristine-tar, unless you assume that every tarball you wan

Re: Keeping upstream commits separate from Debian packaging commits

On 12 October 2014 08:49, Thomas Goirand wrote: > Also, during the Debconf discussion, we decided we would use the > pristine-tar workflow, *not* using upstream VCS merge. A > "git-import-orig" normally goes into a single commit, which I don't > think would bother anyone (not on the list, or on IR

Bug#761167: ITP: isort -- utility / library for sorting Python imports

X-Debbugs-CC: debian-python@lists.debian.org Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: isort Version : 3.9.0 Upstream Author : Timothy Crosley * URL : https://github.com/timothycrosley/isort * License : MIT (Expat-style

Re: When packaging a library, should I prevent its test suite from being packaged

On 9 September 2014 16:53, Konstantin Khomoutov wrote: > Having the test suite packaged along with the code looks like having > not much sense to me, so should I try to exclude this subdirectory from > packaging? Is it considered a bad practice? I don't have much > familiarity with Python, let a

Re: dh_python3 inocrrect dependancy

On 5 July 2014 02:44, Brian May wrote: > I assumed it wasn't valid to have a line with only one value in that file. > Then again, not sure where this file is documented. Would have thought maybe > the dh_python2 man page, it isn't there. >From the dh_python2 man page: dependencies dh_p

Bug#737356: ITP: cryptography -- a Python library which exposes cryptographic recipes and primitives.

Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: cryptography Version : 0.1 Upstream Author : Alex Gaynor, Hynek Schlawack, Donald Stufft, Laurens Van Houtven, Jean-Paul Calderone, Christian Heimes, Paul Kehrer, and

Re: Using update-alternatives for /usr/bin provided binaries

On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand wrote: > On 10/15/2013 06:21 PM, Tristan Seligmann wrote: >> What sort of upstream "source code" would be using the /usr/bin >> wrapper at all? (I ask this question without prejudice; I can >> obviously imagine some

Re: Using update-alternatives for /usr/bin provided binaries

On Tue, Oct 15, 2013 at 11:19 AM, Thomas Goirand wrote: > You will *not* find any upstream source code that will be using > /usr/bin/python2-coverage or /usr/bin/python3-coverage. Absolutely all > of them will be using /usr/bin/coverage (if they need the command line > tool). Thinking that you wil

Re: virtualenv --system-site-packages (was: PEP 453 affects Debian packaging of Python packages)

On Wed, Sep 25, 2013 at 6:21 PM, Barry Warsaw wrote: > On Sep 25, 2013, at 06:15 PM, W. Martin Borgert wrote: > > >Quoting "Barry Warsaw" : > >> Sounds a lot like `virtualenv --system-site-packages` right? > > > >IMHO, --system-site-packages should be the default. > >IIRC, it was the default in s

Re: python-virtualenv 0.10.1-1

On Wed, Aug 14, 2013 at 8:14 PM, Barry Warsaw wrote: > > This one was on my list, so thanks for getting to it before I did. :) > > I did some minimal testing. It built fine, and I could create Python 2.7 and > 3.3 virtualenvs, and pip install a few packages into both. A cursory look at > the dif

python-virtualenv 0.10.1-1

I've updated python-virtualenv in DPMT SVN for the latest upstream release (0.10.1). Among other things, this fixes an issue where running tox with $PYTHONDONTWRITEBYTECODE set would fail with an error from virtualenv. The changes were fairly straightforward (dropping an obsolete patch, and some r

Bug#719458: ITP: python-contextlib2 -- Backported utilities for context management

Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: python-contextlib2 Version : 0.4.0 Upstream Author : Nick Coghlan * URL : http://contextlib2.readthedocs.org/ * License : PSF License Programming Lang: Python Description

Re: How does team maintenace of python module works?

On Sat, Feb 16, 2013 at 11:10 AM, Thomas Goirand wrote: > Oh! Are you *sure* this is what you think of me? It's quite shocking to > read that. It's not that at all. It's: It's what I think are the practical consequences of what you propose. > team)! Well, if I'm not allowed to use Git within the

Re: How does team maintenace of python module works?

On Thu, Feb 14, 2013 at 5:08 PM, Thomas Goirand wrote: > During these exchanges, I have already found that there's at least 4 > people (including myself) who would like to use Git. And that's without > including all the members of the Openstack packaging team, who might > also help. Do you think t

Re: Second round of advise on packaging python-csb

On Wed, Nov 14, 2012 at 5:42 PM, Tomás Di Domenico wrote: > Another blurry point. I'm having a hard time understanding the > separation of tasks between the tarball packaging done by upstream I > described before, and my Debian packaging. Similar to the docs, the > tests are run by upstream when t

Re: Build-Depends-Indep dependencies

On Tue, Oct 26, 2010 at 6:16 PM, anatoly techtonik wrote: > On Tue, Oct 26, 2010 at 7:09 PM, Tristan Seligmann > wrote: >> On Tue, Oct 26, 2010 at 5:35 PM, anatoly techtonik >> wrote: >>> many places outdated (email-based bug-trackers, ML without search, >>

Re: Build-Depends-Indep dependencies

On Tue, Oct 26, 2010 at 5:35 PM, anatoly techtonik wrote: > many places outdated (email-based bug-trackers, ML without search, FWIW: http://lists.debian.org/search.html -- mithrandi, i Ainil en-Balandor, a faer Ambar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a su

Re: Packages whith “except” overwriting builtins

On Tue, Aug 3, 2010 at 11:47 PM, Paul Wise wrote: > 2010/8/3 Jakub Wilk : >> You might be easily mislead into thinking that this code > ... >> will catch both IOError and OSError exceptions. In fact, it will not, as it >> is more or less equivalent to: > ... >> There are about 50 packages in the a

Re: Proposed Email to the release team about XS/B-P-V

On Thu, Jun 24, 2010 at 12:35 PM, Piotr Ożarowski wrote: >> * A module that works perfectly with every Python >= 2.5, but its >> documentation generation system required Python 2.6. Build-dep on python >> (>= 2.6) is needed, which doesn't mean that modules shouldn't be >> byte-compiled for 2.5. >

Re: python-twisted-core not getting updated on i386, but is updated on amd64 [was Re: Increasing number of conflicts]

On Wed, Apr 21, 2010 at 7:41 AM, Rick Thomas wrote: > The reason seems to be that python-twisted-core version 10.0.0-3 is > available on amd64 Sid, but on i386 Sid it's only available at version > 10.0.0-2 . > > Maybe it needs to be rebuilt for i386 ? python-twisted-core is an Arch: all package,

Re: Would like a sponsor to upload the new version of python-foolscap

On Fri, Jan 29, 2010 at 1:50 AM, Ben Finney wrote: > Elliot Murphy writes: > >> I've added foolscap to the /topic in #debian-python > > That strikes me as a rather obnoxious thing to do. Why change the topic > for the whole channel, rather than just communicating as an individual > asking for ass

Re: direct-changes-in-diff-but-no-patch-system foo.egg-info/SOURCES.txt

On Wed, Jan 27, 2010 at 1:05 PM, Ben Finney wrote: > Adam writes: > >> >> I think "setup.py clean" (which gets called by dh_auto_clean) really >> should just delete SOURCES.txt. I just filed a bug upstream against >> python-distribute: >> >> http://bitbucket.org/tarek/distribute/issue/122/setuppy

Re: XS-Python-Version vs pyversions

On Tue, Sep 8, 2009 at 6:45 PM, anatoly techtonik wrote: > Mailing lists are not documentation. Wiki is some kind of docs, but it > still bears a high degree of uncertainty. This is missing the point. The original point of contention was whether or not certain communication occurred; the mailing

Re: r7926 - in packages/python-axiom/trunk/debian (5 files)

On Wed, Mar 18, 2009 at 11:37 PM, Vincent Bernat wrote: > As a work-around, in commit 7928,  I have just skipped unittests for the > whole test/historic directory. This  is just a suggestion, maybe someone > has a better idea? I think that's fine for now; we can probably leave it like that until

Re: r7926 - in packages/python-axiom/trunk/debian (5 files)

On Wed, Mar 18, 2009 at 11:21 PM, Vincent Bernat wrote: >> The patch is not complete: upgrading from old databases still fail. Please don't upload a package based on this patch; it's highly likely that the patch that will be applied upstream will involve quoting all column names, not just "indexe

Re: Developer workflow and DVCS (was: Leaving DPMT?)

* Ondrej Certik [2009-03-02 11:07:25 -0500]: > > If you don't want the project history, then you can use lightweight > > checkouts, which are essentially equivalent to SVN checkouts (you get a > > local working copy, but no local branch or repository). > > Ah, so you basically only get the local

Re: Major update of python-support

* Josselin Mouette [2009-03-02 16:21:20 +0100]: > Le lundi 02 mars 2009 à 15:48 +0100, Vincent Bernat a écrit : > > I ask this because I have many packages that use unittests after the > > build. I add /var/lib/python-support to PYTHONPATH and launch those > > tests. Because the path has

Re: Developer workflow and DVCS (was: Leaving DPMT?)

* David Cournapeau [2009-02-28 20:22:46 +0900]: > I have never used stacked branches, but are you sure you can only > branch the repository data related to a subset of the working tree > only ? My understanding is that bzr stacked branches are useful to > avoid downloading the whole history, but

Re: numpy 1.2.1, switching to git?

* Ondrej Certik [2008-12-21 00:08:18 +0100]: > As to mercurial Tristan, I don't know if you actually ever used > hg-buildpackage, but it is written in Haskell (!) and see my blog post > here: I've used it; being written in Haskell isn't something I consider a problem. It works just fine for

Re: numpy 1.2.1, switching to git?

> On Thu, Dec 18, 2008 at 9:07 PM, Monty Taylor wrote: > > /me whinges that switching to bzr for packaging in general would be a > > much nicer thing overall, since then ubuntu downstream is pretty well > > bzr... > > > > (note: I use bzr for all of my other projects, so I have a vested interest)

Re: Bug#477454: RFS: quodlibet (1.0.ds1-1)

* Joey Hess <[EMAIL PROTECTED]> [2008-06-03 22:51:16 -0400]: > Tristan Seligmann wrote: > > Well, fair enough; I suppose the README.Debian note should not be quite > > as explicit as I made it. I'm just not very happy with the gratuitous > > (in my view) chan

Re: RFS: quodlibet (1.0.ds1-1)

* Joey Hess <[EMAIL PROTECTED]> [2008-06-03 17:53:23 -0400]: > If the presense of this buried in an internal source file is so > vile/illegal/unlike other profanity in software in Debian that you have to > *repackage* the upstream tarball to hide it from the tender eyes of our users > (with all th

RFS: quodlibet (1.0.ds1-1)

Source package is here: http://mithrandi.net/debian/pool/main/q/quodlibet/quodlibet_1.0.ds1-1.dsc Fixes #477454 which is an RC bug; changelog as follows: quodlibet (1.0.ds1-1) unstable; urgency=low . * Ship modified upstream tarball, removing insulting source code, and put a note i

RFS: mutagen (1.14-1)

Source package is here: http://mithrandi.net/debian/pool/main/m/mutagen/mutagen_1.14-1.dsc I've just packaged a new upstream version, the delta in the debian diff is trivial. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature

Re: Bugs that'll block python 2.5

* Josselin Mouette <[EMAIL PROTECTED]> [2008-04-15 12:28:00 +0200]: > On lun, 2008-04-14 at 22:57 +0200, Adeodato Simó wrote: > > Finally, and quite importantly, there is what to do with modules that > > have been added to the standard library in 2.5 (ctypes, celementtree, > > wgsiref). These use

Re: Bugs that'll block python 2.5

* Raphael Hertzog <[EMAIL PROTECTED]> [2008-04-15 14:56:40 +0200]: > On Tue, 15 Apr 2008, Adeodato Simó wrote: > > * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]: > > > The solution is really simple, just add them to python’s Provides: list. > > > > Plus, uhm, can't really be done for (c)el

Re: free profiler in python

* Ondrej Certik <[EMAIL PROTECTED]> [2008-02-09 00:01:52 +0100]: > the python-profile is in non-free, so what free tool do you use for > profiling your python programs? There is cProfile in python2.5, which > seems to be free, but for showing > the result I need pstat, which is again non-free. Is

Re: On team maintainership of DPMT (PAPT) packages

* Piotr Ożarowski <[EMAIL PROTECTED]> [2008-03-09 19:27:01 +0100]: > Unless I'm wrong[0], I don't see a need to change the policy. INAL, but > I think the policy allows me to do above (nasty) things :-) I don't really think any of this is a problem, providing people stick to common sense; for exa

Re: [python-odtwriter] package name wrong?

* Michael Schutte <[EMAIL PROTECTED]> [2008-02-10 09:17:54 +0100]: > On Sat, Feb 09, 2008 at 02:20:26PM +0100, Bernd Zeimetz wrote: > > So python-docutils-writers-odtwriter would be the right name in theory, > > but this doesn't make sense, indeed. > > Does anybody insist on that name? If not, I

Re: [Vincent Bernat] Re: [Python-modules-team] python-axiom REMOVED from testing

* Vincent Bernat <[EMAIL PROTECTED]> [2008-01-25 19:45:04 +0100]: > I have posted this message in python-modules-team mailing list but got > no answer. Looking at the archives, it seems that posting to this list > is pretty rare (except for BTS). So, I post this message here too. Thanks for t

Re: Proposed update to the python policy

* Pierre Habouzit <[EMAIL PROTECTED]> [2007-03-21 21:49:00 +0100]: > On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote: > > it's useful for Python applications that need specific Python version. > > > > f.e. if current Python version is 2.4 and my app. will work only with > > python

PMPT / Alioth

Hi, I'd like to be added to the PMPT project on Alioth; my account name is mithrandi-guest. I'll probably be comaintaning various Divmod packages with Stefano Zacchiroli. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature

Re: python-support 0.6

* Arnaud Fontaine <[EMAIL PROTECTED]> [2007-02-19 15:32:29 +0100]: > In addition, I wonder why python2.5-setuptools doesn't exist? Is there > something wrong with setuptools and python2.5? Package: python-setuptools Provides: python2.4-setuptools, python2.5-setuptools -- mithrandi, i Ainil en-

  1   2   >