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

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.

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

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,

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

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 >

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

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

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.

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

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

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,

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

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, <mithra...@mithrandi.net> wrote: > On Thu, 21 Apr 2016 at 19:34 Barry Warsaw <ba...@debian.org> wrote: > >> I also don't particularly like relying on GitHub genera

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

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

Package: wnpp Severity: wishlist Owner: Tristan Seligmann <mithra...@mithrandi.net> * Package name: python-attrs Version : 15.2.0 Upstream Author : Hynek Schlawack <h...@ox.cx> * URL : https://github.com/hynek/attrs * License : MIT Programming

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

Package: wnpp Severity: wishlist Owner: Tristan Seligmann <mithra...@mithrandi.net> * Package name: python-genty Version : 1.3.0 Upstream Author : Box <o...@box.com> * URL : https://github.com/box/genty * License : Apache 2.0 Programming

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

Package: wnpp Severity: wishlist Owner: Tristan Seligmann <mithra...@mithrandi.net> * Package name: python-flaky Version : 3.0.1 Upstream Author : Box <o...@box.com> * URL : https://github.com/box/flaky * License : Apache License Programming

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

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 >

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

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 <z...@debian.org> 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

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

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: 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 > >

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 mithra...@mithrandi.net 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 recent call last): File stdin, line 1, in module File

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 deb...@kitterman.com 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

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

On 22 May 2015 at 15:43, Donald Stufft don...@stufft.io 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

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

On 22 May 2015 at 16:06, Tristan Seligmann mithra...@mithrandi.net 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* impossible

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 deb...@kitterman.com 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

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

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

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

On 14 May 2015 at 06:04, Scott Kitterman deb...@kitterman.com 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

Re: Sample DPMT SVN-GIT migration

On 1 May 2015 at 16:46, Barry Warsaw ba...@debian.org 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

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

On 5 February 2015 at 22:59, Piotr Ożarowski pi...@debian.org 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 UNSUBSCRIBE

Re: PyPI and debian/watch

On 4 February 2015 at 10:05, Ben Finney ben+deb...@benfinney.id.au wrote: Tristan Seligmann mithra...@mithrandi.net 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

Re: Status of pythondialog in Debian

On 22 October 2014 09:47, Florent Rougon f.rou...@free.fr 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

Re: How to solve #751375, file clash

On 16 October 2014 23:55, Brian May br...@microcomaustralia.com.au 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

Re: Keeping upstream commits separate from Debian packaging commits

On 16 October 2014 20:12, Hans-Christoph Steiner h...@at.or.at 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 would generally be a bad idea

Re: Keeping upstream commits separate from Debian packaging commits

On 13 October 2014 00:19, Barry Warsaw ba...@debian.org 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

Re: Keeping upstream commits separate from Debian packaging commits

On 16 October 2014 18:01, Thomas Goirand z...@debian.org 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

Re: Keeping upstream commits separate from Debian packaging commits

On 12 October 2014 08:49, Thomas Goirand z...@debian.org 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

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

On 12 October 2014 12:36, W. Martin Borgert deba...@debian.org 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

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 mithra...@mithrandi.net * Package name: isort Version : 3.9.0 Upstream Author : Timothy Crosley * URL : https://github.com/timothycrosley/isort * License

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

On 9 September 2014 16:53, Konstantin Khomoutov flatw...@users.sourceforge.net 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

Re: dh_python3 inocrrect dependancy

On 5 July 2014 02:44, Brian May br...@microcomaustralia.com.au 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:

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

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

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

On Tue, Oct 15, 2013 at 1:47 PM, Thomas Goirand z...@debian.org 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 ways this might happen

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

On Tue, Oct 15, 2013 at 11:19 AM, Thomas Goirand z...@debian.org 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

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 ba...@debian.org wrote: On Sep 25, 2013, at 06:15 PM, W. Martin Borgert wrote: Quoting Barry Warsaw ba...@python.org: Sounds a lot like `virtualenv --system-site-packages` right? IMHO, --system-site-packages should be the default. IIRC, it

Re: python-virtualenv 0.10.1-1

On Wed, Aug 14, 2013 at 8:14 PM, Barry Warsaw ba...@debian.org 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

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

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

Re: How does team maintenace of python module works?

On Sat, Feb 16, 2013 at 11:10 AM, Thomas Goirand z...@debian.org 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

Re: How does team maintenace of python module works?

On Thu, Feb 14, 2013 at 5:08 PM, Thomas Goirand z...@debian.org 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

Re: Second round of advise on packaging python-csb

On Wed, Nov 14, 2012 at 5:42 PM, Tomás Di Domenico td...@tdido.com.ar 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

Re: Build-Depends-Indep dependencies

On Tue, Oct 26, 2010 at 6:16 PM, anatoly techtonik techto...@gmail.com wrote: On Tue, Oct 26, 2010 at 7:09 PM, Tristan Seligmann mithra...@mithrandi.net wrote: On Tue, Oct 26, 2010 at 5:35 PM, anatoly techtonik techto...@gmail.com wrote: many places outdated (email-based bug-trackers, ML

Re: Packages whith “except” overwriting builtins

On Tue, Aug 3, 2010 at 11:47 PM, Paul Wise p...@debian.org wrote: 2010/8/3 Jakub Wilk jw...@debian.org: 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

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

On Thu, Jun 24, 2010 at 12:35 PM, Piotr Ożarowski pi...@debian.org 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

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 rbtho...@pobox.com 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:

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

On Fri, Jan 29, 2010 at 1:50 AM, Ben Finney ben+deb...@benfinney.id.au wrote: Elliot Murphy ell...@canonical.com 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

Re: XS-Python-Version vs pyversions

On Tue, Sep 8, 2009 at 6:45 PM, anatoly techtonik techto...@gmail.com 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

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

On Wed, Mar 18, 2009 at 11:21 PM, Vincent Bernat ber...@debian.org 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,

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

On Wed, Mar 18, 2009 at 11:37 PM, Vincent Bernat ber...@debian.org 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

Re: Major update of python-support

* Josselin Mouette j...@debian.org [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

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

* Ondrej Certik ond...@certik.cz [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

Re: numpy 1.2.1, switching to git?

* Ondrej Certik ond...@certik.cz [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

Re: numpy 1.2.1, switching to git?

On Thu, Dec 18, 2008 at 9:07 PM, Monty Taylor mo...@inaugust.com 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

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) change to the upstream tarball, so I wanted

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

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

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 the

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)elementtree,

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 there

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’m going

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 python2.5 and

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

Re: debian/pycompat usage?

* Josselin Mouette [EMAIL PROTECTED] [2006-08-26 11:18:15 +0200]: Le vendredi 25 août 2006 à 17:09 -0700, Steve Langasek a écrit : This decision was not unilateral, sorry. It was a decision, made by you as python-support maintainer, in direct contradiction to what Matthias and I had

Re: Orphaning Python packages

* Joe Wreschnig [EMAIL PROTECTED] [2006-06-19 12:48:22 -0500]: I've orphaned feedparser and the GStreamer Python bindings (the 0.8 and I've also put python-mutagen up for adoption. I'm upstream for this to a regression in Pygame/SDL) or quodlibet please let me know. I would be interested in