Transition to python3.5 as default python3 in progress

The RT ack'ed the transition bug and I just uploaded python3-defaults with python3.5 set as the default version, so we've started. Scott K

Re: transition: python3-defaults (python3.5 as default python3) - status update

On Wednesday, January 06, 2016 03:39:15 PM you wrote: ... > 1. pygpgme is FTBFS due to test failures (#797776). There has been no > response from the maintainers and I have been unable to determine the > source of the failures. I do not believe it is python3 version related (the > package builds

Python Policy: Things to consider for Stretch

I've taken a run through the current Python Policy to see where I think it needs to be updated for Stretch. The updates largely fall into four categories: 1. Update old examples 2. Clean up old policy test that no longer applies 3. Simplify things due to there only being one python version 4

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Thursday, January 21, 2016 10:00:53 AM Donald Stufft wrote: > > On Jan 21, 2016, at 9:32 AM, Paul Tagliamonte wrote: > > > > Hey Donald! > > > > As far as using pip to do stuff system-wide, I wrote thoughts on > > http://notes.pault.ag/debian-python > I j

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Friday, January 22, 2016 10:54:54 AM Donald Stufft wrote: > > On Jan 22, 2016, at 10:36 AM, Piotr Ożarowski wrote: > > > > to be honest, I still don't know what you're asking for. What do you > > want us to do? Patch 2.7's distutils? > > Essentially, ensure that setuptools not distutils is us

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Friday, January 22, 2016 12:11:27 PM Donald Stufft wrote: ... > 3) It slipped my mind that you have to pass an additional flag to setuptools > right now to get the full file list (pip passes that flag unconditionally) > however I'm going to poke setuptools to see about getting them to add the >

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Friday, January 22, 2016 01:32:45 PM Fred Drake wrote: > On Fri, Jan 22, 2016 at 12:40 PM, Scott Kitterman wrote: > > Currently --record includes the .pyc files which is both unneeded and bad. > > Before this gets added either in setuptools or by us, this needed to be > >

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Friday, January 22, 2016 01:47:28 PM Fred Drake wrote: > On Fri, Jan 22, 2016 at 1:41 PM, Scott Kitterman wrote: > > For Debian it's bad because we don't ship the .pyc files in the package > > they are managed locally by the installed python system. They are als

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Friday, January 22, 2016 05:50:13 PM Donald Stufft wrote: ... > We already have an option like this, the —root option which will just append > a different prefix to all of the installation paths. So essentially instead > of invoking ``python setup.py install —root /tmp/something/`` which is what

Re: Amend Debian Python Proposal to Include More Python Metadata?

On January 22, 2016 6:27:08 PM EST, Donald Stufft wrote: > >> On Jan 22, 2016, at 6:04 PM, Scott Kitterman >wrote: >> >> On Friday, January 22, 2016 05:50:13 PM Donald Stufft wrote: >> ... >>> We already have an option like this, the —root option which w

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Friday, January 22, 2016 10:54:54 AM Donald Stufft wrote: > > On Jan 22, 2016, at 10:36 AM, Piotr Ożarowski wrote: > > > > to be honest, I still don't know what you're asking for. What do you > > want us to do? Patch 2.7's distutils? > > Essentially, ensure that setuptools not distutils is us

Re: Amend Debian Python Proposal to Include More Python Metadata?

On Saturday, January 23, 2016 03:13:48 AM Scott Kitterman wrote: > On Friday, January 22, 2016 10:54:54 AM Donald Stufft wrote: > > > On Jan 22, 2016, at 10:36 AM, Piotr Ożarowski wrote: > > > > > > to be honest, I still don't know what you're asking for

Re: Python Policy: Things to consider for Stretch

On Friday, January 22, 2016 05:55:19 PM Barry Warsaw wrote: > On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote: > >I've taken a run through the current Python Policy to see where I think it > >needs to be updated for Stretch. > > Thanks Scott for the badly needed

Re: Python Policy: Things to consider for Stretch

On Saturday, January 23, 2016 08:50:49 PM Barry Warsaw wrote: > On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote: > >Personally I seriously dislike the trend to call Python Python 2 (and I > >still thing approving a pep to invent /usr/bin/python2 because Arch went > >insan

Re: Python Policy: Things to consider for Stretch

On Sunday, January 24, 2016 04:46:09 PM Ben Finney wrote: > Scott Kitterman writes: > > I've taken a run through the current Python Policy to see where I > > think it needs to be updated for Stretch. The updates largely fall > > into four categories: […] > > This

Re: Python Policy: Things to consider for Stretch

On Sunday, January 24, 2016 04:33:55 PM Ben Finney wrote: > Scott Kitterman writes: > > I don't particularly agree, but if that's correct, then there's a > > large amount of change needed throughout the policy. These certainly > > aren't the only plac

Re: Python Policy: Things to consider for Stretch

On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote: > Ben Finney writes: > > Where is the Git (I assume?) repository you're using for VCS of this > > policy document? > > Found it; the source document is ‘python-policy.sgml’ in the source VCS > for ‘python3’. Currently that's a Bazaar repos

Re: Python Policy: Things to consider for Stretch

On January 24, 2016 11:59:14 PM EST, Ben Finney wrote: >Scott Kitterman writes: > >> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote: >> > Found it; the source document is ‘python-policy.sgml’ in the source >> > VCS for ‘python3’. Currently

Re: Python Policy: Things to consider for Stretch

On January 26, 2016 10:32:57 PM EST, Ben Finney wrote: >Dmitry Shachnev writes: > >> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote: >> > I'm planning to provide changes in two bundles: >> > >> > * Go through the whole document and tidy it up for consistency, >> > source style, m

Re: Python Policy: Things to consider for Stretch

On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote: ... > Once these non-semantic changes are accepted I will begin work on the > second stage of semantic changes. ... OK. Those are all accepted. Barry Warsaw had done some changes in the -whl section so I made an attempt at merging w

Re: Python Policy: Things to consider for Stretch

On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote: > Ben Finney writes: > > * Address all the language around Python 2 versus Python 3 versus > > > > Python general, and re-order or re-word to focus *primarily* on Python > > 3, with Python 2 treated as the still-supported legacy syst

Re: static analysis and other tools for checking Python code

On Wednesday, March 02, 2016 11:22:52 AM Paul Wise wrote: > Hi all, > > Some of you may have noticed I'm working on a tool called > check-all-the-things that does what it says on the tin. > > https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git > https://anonscm.debian.org/cgit/c

Re: Handling python modules collision

On Tuesday, March 22, 2016 04:55:36 PM Frederic Bonnard wrote: > Hi, > I'd like your advises concerning the following situation : I'm packaging > this python library : > https://github.com/miguelgrinberg/python-socketio > > and I see that debian already provides a library with the same name : > >

Re: Packaging Grip

On April 6, 2016 10:37:24 PM EDT, Tiago Ilieve wrote: >Hi Dmitry, > >On 6 April 2016 at 17:21, Dmitry Shachnev wrote: >> 1. Public (/usr/lib/python*/dist-packages) vs private (/usr/share/) >location >> depends on whether the module is intended to be used by third-party >packages, >> or only by

Re: Cythonized files & Debian Policy

On April 7, 2016 5:29:14 PM EDT, "Víctor Cuadrado Juan" wrote: >I have come across an upstream that ships both the cythonized .c file >and the .py source, on my ITP python-neovim-gui [1]. > >On #python @freenode I have been said that shipping both files is >standard practice, which seems to be b

Re: python-texttable -- status and interest in becoming the maintainer

On Tuesday, June 14, 2016 12:55:15 AM Sergio Durigan Junior wrote: > Hello, > > I'm a user of the python-texttable package on Debian, and I noticed that > it seems abandoned. The first and only upload happened in 2013, and > even though there is a new upstream version available the package did >

Re: python-texttable -- status and interest in becoming the maintainer

On Thursday, June 16, 2016 11:35:02 PM Sergio Durigan Junior wrote: > On Tuesday, June 14 2016, I wrote: > >> If you are interested in keeping the package up to date, please add > >> yourself to Uploaders and then get to work. Please make sure you use > >> git-dpm on any DPMT repositories. > > >

Re: Bug#829630: O: pythonqt

On Monday, July 04, 2016 10:08:47 PM Andreas Tille wrote: > Package: wnpp > Severity: normal > > Hi, > > the package pythonqt was once a dependency of a Debian Med package but > this was removed. Now pythonqt has no rdepends any more and is hard to > maintain since it needs Qt4. May be its the

Re: [Python-modules-team] RM of shiboken & pyside ?

On Tuesday, July 05, 2016 06:00:25 PM Didier 'OdyX' Raboud wrote: > Hi there, > > Now that we have PyOtherSide in Debian, and that both shiboken and > PySide are somewhat broken in sid & stretch; what about just removing > them from Debian ? > > I'm not a PySide user myself, and it's abandonned u

Re: ITP: python-prompt-toolkit -- Library for building powerful interactive command lines in Python

This is already packaged. https://tracker.debian.org/pkg/prompt-toolkit Scott K On July 21, 2016 2:30:36 AM EDT, Julien Puydt wrote: >Package: wnpp >Severity: wishlist > >* Package name : python-prompt-toolkit > Version : 1.0.3 > Upstream author : Jonathan Slenders >* URL

Re: Help for Python mock test suite needed (Was: Any help with problem of srst2 new versions tests suite failing to call bowtie2)

On Saturday, August 13, 2016 08:40:34 AM Andreas Tille wrote: > Hi, > > I've got no help on the Debian Med packaging list. Is there any hint > how I could track down a test Python suite issue what exact command > was called and failed? > > Thanks for any hint > > Andreas. > > On Tue, Aug

Re: BTS bot in #debian-python IRC channel

On Saturday, August 13, 2016 10:48:35 PM Ondrej Novy wrote: > Hi, > > I would like to add BTS bot to IRC channel #debian-python with same > notifications (uploads, bug reports) as in #debian-devel-changes filtered > to maintainer/uploaders: > Debian Python Modules Team > Python Applications Packa

Re: BTS bot in #debian-python IRC channel

On Saturday, August 13, 2016 11:50:50 PM Ondrej Novy wrote: > Hi, > > 2016-08-13 23:39 GMT+02:00 Scott Kitterman : > > I don't think there's anything you've listed that we don't already get via > > email. Personally, I don't think I need it again on

Re: BTS bot in #debian-python IRC channel

On August 14, 2016 12:51:18 PM MDT, "Piotr Ożarowski" wrote: >[Ben Finney, 2016-08-14] >> Would it be a good idea to first have it running in an analogous >> channel, ‘#debian-python-changes’? > >+1 (I'd move VCS commits messages there too) +1 for both. Scott K

Re: Joining DPMT: calculus

On Wednesday, September 14, 2016 08:48:44 PM Jerome BENOIT wrote: > Dear DPMT, > > I [0] would like to join the team to help to maintain Python modules that > are dependencies of Sage[Math] [1]. For the very moment, I am finalizing > the packaging of the Cython package cysignals [2], and I eager t

Re: can we disable the bounce kicker? Re: confirm

On Friday, September 23, 2016 04:15:23 PM Thomas Goirand wrote: > On 09/10/2016 05:34 PM, Santiago Vila wrote: > > The "[Python-modules-team]" thing in the subject is probably enough to > > break the DKIM signature. > > I don't believe DKIM signature is done on the header+body. If I'm not > mistak

Re: Salvaging pylibtiff to Debian Python team or removing it from Debian?

On Saturday, October 22, 2016 08:30:50 AM Andreas Tille wrote: > ¡Hola Maxi! > > On Sat, Oct 22, 2016 at 07:44:37AM +0200, Maximiliano Curia wrote: > > El 2016-10-21 a las 09:36 +0200, Andreas Tille escribió: > > >the former maintainer of pylibtiff inside Debian Med team Mathieu > > >Malaterre doe

Re: /usr/bin/python2 shebangs

On November 1, 2016 10:28:01 AM EDT, Barry Warsaw wrote: >Over in #834193, a user is asking for a /usr/bin/pip2 to mirror >/usr/bin/pip >because some uses cases apparently prefer pip2 over pip. That seems >like a >reasonable request on the face of it, and easy to support. > >However, I thought,

Re: /usr/bin/python2 shebangs

On Tuesday, November 01, 2016 05:14:21 PM Barry Warsaw wrote: > On Nov 01, 2016, at 11:34 AM, Scott Kitterman wrote: > >I don't think /usr/bin/python should ever point to a python3 version. It > >should be dropped when python2.7 is removed. I think the existence of >

Re: /usr/bin/python2 shebangs

On November 1, 2016 8:43:50 PM EDT, Donald Stufft wrote: > >> On Nov 1, 2016, at 6:03 PM, Scott Kitterman >wrote: >> >> Even after python2.7 is removed from Debian, there will still be >users who >> keep a local copy because they couldn't migrate thing

Re: Packaging new version of ZODB (Zope Object Database)

On November 2, 2016 6:51:56 PM EDT, Barry Warsaw wrote: >On Nov 02, 2016, at 10:46 AM, Arnaud Fontaine wrote: > >>> I write to debian-python, because some of the involved packages >are >>> not specific to Zope. Actually, I even think that ZODB itself is >not >>> specific to Zope, but well,

Re: Packaging new version of ZODB (Zope Object Database)

On Friday, November 04, 2016 10:47:32 AM Barry Warsaw wrote: > On Nov 03, 2016, at 08:36 PM, Julien Muchembled wrote: > >I'm used to gbp. I don't know git-dpm (or I forgot after seeing I would not > >like?) > > git-dpm is usually pretty easy, but it's really only used in a few cases, > such as imp

Re: /usr/bin/python2 shebangs

On Monday, November 07, 2016 10:08:25 AM Barry Warsaw wrote: > On Nov 07, 2016, at 11:44 AM, Thomas Goirand wrote: > >So, I don't agree with you, and believe that gradually using > >#!/usr/bin/python2 is a good approach to the transition. IMO, that's > >what we should start doing as much as possibl

Re: policy question: tag format for patch-less packages

On November 16, 2016 2:33:47 PM CST, "IOhannes m zmölnig (Debian/GNU)" wrote: >On 11/16/2016 06:07 AM, chrysn wrote: >> Should git-dpm be used even though no patches are present? > >how do you make sure that you will never need patches? (unless this is >a >native package) Also, git-dpm tag pro

Re: DPMT membership request

Done. I've left the -guest account in the team in case you need it for transitional purposes. Scott K On Wednesday, November 23, 2016 10:16:35 AM Christos Trochalakis wrote: > Hello, > > I am now using a new alioth username (ctrochalakis), > is it possible to add it to the group? > > Thank yo

Binary naming for Django Related Packages

I've recently done some Django related packaging for the first time and noticed that we have organically (as far as I can tell) grown a slightly different naming convention for such packages. Instead of python*-foo, we use python*-django-foo. I think this is a reasonable approach and followed

Re: Binary naming for Django Related Packages

On Monday, November 28, 2016 05:50:24 PM Piotr Ożarowski wrote: > [Scott Kitterman, 2016-11-28] > > > I've recently done some Django related packaging for the first time and > > noticed that we have organically (as far as I can tell) grown a slightly > > differe

Re: Binary naming for Django Related Packages

On Tuesday, November 29, 2016 01:52:07 PM Raphael Hertzog wrote: > On Mon, 28 Nov 2016, Scott Kitterman wrote: > > > > Please let me know what you think. I'm open to suggestions on > > > > wording. > > > > I'd like to get this done in the next

Re: Binary naming for Django Related Packages

On Tuesday, November 29, 2016 02:40:06 PM Piotr Ożarowski wrote: > [Scott Kitterman, 2016-11-29] > > > Piotr: Is there some language that acknowledges the situation as unusual, > > even if it doesn't fully bless it that you'd be comfortable with in > > policy s

Re: ITP: scandir -- Better directory iterator that returns all file info the OS provides

On January 14, 2017 6:32:07 AM EST, Julien Puydt wrote: >Control: retitle -1 ITP: scandir -- Better directory iterator that >returns all file info the OS provides > >I would like to package python-scandir, as newer versions of >python-pathlib2 now depend on it. > >As I don't want to add new dep

Re: Binary naming for Django Related Packages

On Wednesday, December 07, 2016 11:43:29 AM Raphael Hertzog wrote: > Hi, > > On Wed, 30 Nov 2016, Scott Kitterman wrote: > > Raphael, do you think that the upstream Django project might be willing to > > make some kind of best practices for naming third party django packa

Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)

On January 22, 2017 8:11:26 PM EST, Nikolaus Rath wrote: >On Jan 23 2017, Brian May wrote: >[ Convert from git-dpm to gbp ] >> Or would dgit be a better option? I confuse I don't really understand >> dgit. > >dgit can be used with both git-dpm and gbp. Moving to dgit-only would >mean to use a s

Re: Binary naming for Django Related Packages

On Wednesday, January 18, 2017 10:04:24 AM IOhannes m zmölnig wrote: > On 2017-01-18 07:46, Scott Kitterman wrote: > > +··named·django_packagename·upstream.··These·are·then·packaged·as > > +··python3-django-package·and > > please use "package" vs &q

Re: git-dpm breakage src:faker

On Sunday, January 29, 2017 08:54:57 AM Brian May wrote: > Can we switch away from git-dpm yet? Sure this is most likely user > error, however I want to try to solve an RC bug, not fix broken git-dpm > first. Much like the switch from svn to git, I think we need an agreed new workflow and tools a

Re: git-dpm breakage src:faker

On Sunday, January 29, 2017 09:39:10 AM Brian May wrote: > Scott Kitterman writes: > > On Sunday, January 29, 2017 08:54:57 AM Brian May wrote: > >> Can we switch away from git-dpm yet? Sure this is most likely user > >> error, however I want to try to solve an RC

Re: git-dpm breakage src:faker

On January 29, 2017 2:17:16 AM EST, Arto Jantunen wrote: >Scott Kitterman writes: > >> On Sunday, January 29, 2017 09:39:10 AM Brian May wrote: >>> Scott Kitterman writes: >>> > On Sunday, January 29, 2017 08:54:57 AM Brian May wrote: >>> >> C

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Tuesday, January 31, 2017 02:23:29 PM Barry Warsaw wrote: > On Jan 29, 2017, at 09:39 AM, Brian May wrote: > >I would think "gbp pq" is the most popular. > > I've used it on some of my non-team packages and while it takes a little > getting used to for the standard git-dpm workflow, it's been m

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Sunday, February 05, 2017 03:59:37 PM Brian May wrote: > Scott Kitterman writes: > > We should probably be thinking in terms of post-release for this change. > > During the pre-release freeze, the release team doesn't typically allow > > changes that extraneous to

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On February 9, 2017 10:52:04 AM PST, Nikolaus Rath wrote: >On Feb 07 2017, Barry Warsaw wrote: >> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote: >> >>>I know the discussion is leaning towards replacing usage of git-dpm >>>with gbp-pq. I have nothing against it but, since we are talking

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On February 9, 2017 8:29:32 PM PST, Nikolaus Rath wrote: >On Feb 10 2017, Scott Kitterman wrote: >>>No. You are confusing dgit with one particular way to use it. You can >>>use dgit with the maint-merge workflow mentioned above, you can use >>>dgit >>>

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On February 11, 2017 4:05:46 PM EST, Nikolaus Rath wrote: >On Feb 10 2017, Scott Kitterman wrote: >> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath >wrote: >>>On Feb 10 2017, Scott Kitterman wrote: >>>>>No. You are confusing dgit with one particular w

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Tuesday, February 14, 2017 06:23:43 PM Brian May wrote: > Scott Kitterman writes: > > We know in the DPMT context what debcheckout will produce, so for our > > purposes they don't matter. > > > > How does dgit avoid maintainer forgot to push problems

Re: Moving off of git-dpm

On Thursday, February 16, 2017 12:42:59 PM Dimitri John Ledkov wrote: > On 16 February 2017 at 11:31, Piotr Ożarowski wrote: > > Are you guys seriously considering dgit to replace anything other than > > dput in DPMT? I'd rather go back to svn-buildpackage than use something > > that will not allo

Re: Adopting OpenStack packages

On March 3, 2017 10:37:16 PM EST, Thomas Goirand wrote: ... >4/ Finally, I feel very much unwelcome by the team "leaders" of the >DPMT >(of which the "main" person happen to also be that SQLA maintainer >which >I prefer not to name). I already have, and will continue to avoid -as >much as possib

Re: Adopting OpenStack packages

On March 4, 2017 4:46:05 AM EST, Vincent Bernat wrote: > ❦ 3 mars 2017 21:42 -0800, Clint Byrum  : > >> One great thing about teams is they have many faces. Talk to me. Talk >to >> Allison. Talk to others. We're here to make sure things flow smoothly >> for OpenStack and Debian, and if you have

Re: Adopting OpenStack packages

On Saturday, March 04, 2017 09:23:28 PM Vincent Bernat wrote: > ❦ 4 mars 2017 15:04 GMT, Scott Kitterman : > > This was not about isolated mistakes. We've all made those. I do > > not, however, think it's useful to rehash the details. I do think it > > is w

Re: Adopting OpenStack packages

On March 4, 2017 6:41:13 PM EST, Thomas Goirand wrote: >On 03/04/2017 06:03 AM, Scott Kitterman wrote: >> If you don't understand why, after repeated warnings, >> you were temporarily banned from team repository access, > >I understand, but I don't agree. My vie

Re: Adopting OpenStack packages

On Sunday, March 05, 2017 01:26:19 AM Thomas Goirand wrote: > On 03/04/2017 04:04 PM, Scott Kitterman wrote: > > This was not about isolated mistakes. > > [...] > > I do not, however, think it's useful to rehash the details. > > Though that's what you're

Re: Adopting OpenStack packages

On March 5, 2017 12:33:03 AM EST, Vincent Bernat wrote: > ❦ 4 mars 2017 23:04 GMT, Scott Kitterman  : > >>> > This was not about isolated mistakes. We've all made those. I do >>> > not, however, think it's useful to rehash the details. I do think

Re: Adopting OpenStack packages

On March 5, 2017 2:57:10 PM EST, Ondrej Novy wrote: >Hi, > >2017-03-05 18:09 GMT+01:00 Allison Randal : >> >> So, getting back to more practical matters, my proposal is that we >start >> by moving alembic and python-concurrent.futures back to DPMT, since >they >> > >as alembic and python-concurr

Re: Adopting OpenStack packages

On March 5, 2017 5:09:33 PM EST, Thomas Goirand wrote: >On 03/05/2017 01:13 AM, Scott Kitterman wrote: >> On March 4, 2017 6:41:13 PM EST, Thomas Goirand >wrote: >>> On 03/04/2017 06:03 AM, Scott Kitterman wrote: >>>> If you don't understand why,

Re: Adopting OpenStack packages

On Monday, March 06, 2017 07:04:41 AM Clint Byrum wrote: > Excerpts from Brian May's message of 2017-03-06 12:30:56 +1100: > > The concept to convert from git-dpm to gbp pq is very very easy: > > > > 1. Delete debian/.git-dpm > > 2. Unapply all patches. > > 3. Commit and push. > > > > (repeat for

Transition away from git-dpm was: Re: Adopting OpenStack packages

Updated the subject, since we've drifted... On Monday, March 06, 2017 04:47:39 PM Simon McVittie wrote: > On Mon, 06 Mar 2017 at 10:32:17 -0500, Scott Kitterman wrote: > > I think it's reasonable to try this out on a branch > > Here's a maybe-stupid idea: use ht

Re: Moving a package from collab-maint to python-modules

On March 11, 2017 6:52:59 AM EST, Ghislain Vaillant wrote: >On Sat, 2017-03-11 at 11:24 +, Christopher Hoskin wrote: >> Hello, >> >> I'd like to package python-jsonpointer for Debian. The filer of the >RFP (Bug #754296) Pietro Battiston, has created a repository at >> >> https://anonscm.de

Re: PyPI source or github source?

On Monday, March 13, 2017 05:55:32 PM Thomas Goirand wrote: > On 03/12/2017 11:34 AM, Ghislain Vaillant wrote: > > On the other hand, I have seen very few pieces of software which had a > > *comprehensive* MANIFEST.in for generating a tarball suitable for > > packaging. The file is often either abs

Re: Updating Celery, Kombu, python-amqp

On Saturday, March 18, 2017 05:58:49 PM Brian May wrote: > Christopher Hoskin writes: > > python-amqp depends on vine, but when I previously packaged vine[0], I > > only built the python3 package. Is it too soon to start dropping > > python2 packages from uploads intended for Buster? > > I am har

Re: Updating Celery, Kombu, python-amqp

On Monday, March 20, 2017 07:28:47 AM Christopher Hoskin wrote: ... > A Python 2 package for the vine dependency is currently in the NEW queue. ... It was just accepted. Scott K

Re: Updating Celery, Kombu, python-amqp

On March 24, 2017 4:30:12 AM EDT, Brian May wrote: ... >Alternative: maybe I should go to the other plan of uploading the old >version of kombu with an increased epoch? Please use newversion+reallyoldverssion instead of an epoch. It's generally better to avoid epochs for temporary issues like

Re: Fwd: next version of csvkit

On April 1, 2017 3:42:50 AM EDT, Ghislain Vaillant wrote: >... > >How so? Buster will not be supporting Python 2, so the narrative of >having new source packages only provide Python 3 binary packages is >totally justified. What makes you think this is true? As far as I know, Python 2 will be a

Re: Fwd: next version of csvkit

On Saturday, April 01, 2017 05:12:38 PM Ghislain Vaillant wrote: > On Sat, 2017-04-01 at 15:55 +0000, Scott Kitterman wrote: > > On April 1, 2017 3:42:50 AM EDT, Ghislain Vaillant wrote: > > > ... > > > > > > How so? Buster will not be supporting Python 2,

Re: [Python-modules-commits] [python-cpuinfo] 02/02: Import Debian changes 3.0.0-1

On April 17, 2017 12:20:36 PM EDT, Mattia Rizzolo wrote: >On Mon, Apr 17, 2017 at 12:12:11PM -0400, Sandro Tosi wrote: >> are we really suggesting to create a separate binary package, for a >> single script, not even 400 bytes (in py-cpuinfo case, but i bet >there >> are more just like this), ma

Re: Request to join DPMT

On Thursday, May 11, 2017 10:14:12 AM Colin Watson wrote: > Hi, > > I'd like to join the Debian Python Modules Team. I maintain a couple of > module packages already that probably ought to be moved under the DPMT > umbrella (six, python-tblib), and I'm upstream for some others (e.g. > lazr.restfu

Re: PAPT git migration

On May 31, 2017 7:16:39 PM EDT, Simon McVittie wrote: >On Thu, 01 Jun 2017 at 00:16:45 +0200, Stefano Rivera wrote: >> Hi Barry (2017.05.31_23:32:20_+0200) >> > $ gbp pq export >> > - This doesn't work until you at least do a first pq import, but >now I see the >> > d/p/changlog-docs patch get

Re: Ad-hoc Debian Python BoF at PyCon US 2017

On Friday, June 09, 2017 08:32:38 PM Barry Warsaw wrote: > On Jun 06, 2017, at 10:57 AM, Sandro Tosi wrote: > >if we plan (and it looks like we do) to support and distribute 2.7 > >with buster, why not support it *properly*? what's the point of > >deprecating python2.7? either we ship it or not, bu

Python3.6 plans​ for Buster

Python3.6 is already in Unstable and I expect to see it in Testing soon after Stretch is released. I've just now uploaded a version of python3-defaults to Experimental that adds python3.6 as as supported (but not default) python3. If you have binary extensions packaged, please start testing wi

Re: Python3.6 plans​ for Buster

On Friday, June 16, 2017 10:27:34 PM Steve Langasek wrote: > On Fri, Jun 16, 2017 at 10:23:06PM -0700, Steve Langasek wrote: > > [1] pytables is a failure specific to Ubuntu armhf buildds which raise > > SIGBUS, this should not affect Debian. python-astropy rebuilds with no > > problem, but doesn'

Re: Python3.6 plans​ for Buster

On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote: > Python3.6 is already in Unstable and I expect to see it in Testing soon > after Stretch is released. > > I've just now uploaded a version of python3-defaults to Experimental that > adds python3.6 as as suppor

Bug#866335: transition: python3-defaults

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition We would like to add python3.6 as a supported python3 version along with python3.5. This is not exactly like a normal transition. Only transient unbuildability of higher level packages

Re: Python3.6 plans​ for Buster

On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote: > On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote: > > Python3.6 is already in Unstable and I expect to see it in Testing soon > > after Stretch is released. > > > > I've just now uploaded

Re: Python3.6 plans​ for Buster

On Wednesday, June 28, 2017 11:19:37 PM Scott Kitterman wrote: > On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote: > > On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote: ... > > > As a reminder (and for anyone new) we'll do the transition to python3.

Re: git-dpm: remove a patch

On Wednesday, July 05, 2017 08:51:34 AM Vincent Bernat wrote: > Hey! > > How to remove a patch with git-dpm? > > I have tried: > > git-dpm c-p > git reset --hard HEAD~1 > git-dpm u-p > > And got: > > git-dpm: Calling merge-patched-into-debian first... > git-dpm: ERROR: cowardly refusing to upd

Re: Bug#866335: Python3.6 plans​ for Buster

On Wednesday, July 05, 2017 10:24:26 AM Emilio Pozuelo Monfort wrote: > Hi Scott, > > On 05/07/17 06:25, Scott Kitterman wrote: > > On Wednesday, June 28, 2017 11:19:37 PM Scott Kitterman wrote: > >> On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote: > >&g

Re: python3 for pysrs

On July 17, 2017 8:27:45 AM EDT, "Sandro Knauß" wrote: >Hey, > >> This is work you're doing in collaboration with the ‘pysrs’ upstream >> developers, right? You are aiming to get users to test this, and get >it >> into a release, before doing any of this in Debian. Is that correct? > >well becau

Re: python3 for pysrs

On Monday, July 24, 2017 03:49:39 PM Sandro Knauß wrote: > Hey, > > > I know the upstream developer. I would recommend that you contact him. > > He's been gradually moving from Sourceforge to GitHub and I expect he'd > > move pysrs if you offered to port it. > > Okay done - mail sent, than we se

Re: MBF for deprecating Python2 usage

Dropped d-devel. On August 3, 2017 9:08:10 PM EDT, ba...@debian.org wrote: >On Aug 3, 2017, at 17:57, Matthias Klose wrote: >> >> While at DebCamp, Stefano Rivera and I sat down to analyze what needs >to be done >> to deprecate Python2 usage within the distribution. It might not be >possible to

Re: MBF for deprecating Python2 usage

On August 4, 2017 6:49:23 AM EDT, Matthias Klose wrote: >On 03.08.2017 21:08, ba...@debian.org wrote: >> On Aug 3, 2017, at 17:57, Matthias Klose wrote: >>> >>> While at DebCamp, Stefano Rivera and I sat down to analyze what >needs to be done >>> to deprecate Python2 usage within the distributi

Re: MBF for deprecating Python2 usage

On Friday, August 04, 2017 10:13:00 AM ba...@debian.org wrote: > On Aug 3, 2017, at 23:23, Scott Kitterman wrote: > > Read it. I remain completely convinced that /usr/bin/python pointing at a > > python3 version is utterly wrong and a disservice to our users. Even > > afte

Re: Uploading Python modules which drop support for Python 2?

On August 4, 2017 8:00:27 PM EDT, "W. Martin Borgert" wrote: >Hi team, > >pysolar upstream version 0.7 dropped support for Python 2, so I >did not upload it for stretch. I'm considering upload for buster >now. What do you think? > >Cheers If there are no rdepends, I think it's fine to go ahead

Re: MBF for deprecating Python2 usage

On August 4, 2017 9:37:18 PM EDT, Barry Warsaw wrote: >Scott Kitterman wrote: > >> If the primary concern is what happens when a user types "python", >then can we >> address that in command-not-found and leave /usr/bin/python out of >it? > >I'm def

Re: a few quick questions on gbp pq workflow

On August 6, 2017 11:37:51 AM EDT, Jeremy Stanley wrote: >On 2017-08-06 10:44:36 -0400 (-0400), Allison Randal wrote: >> The OpenStack packaging team has been sprinting at DebCamp, and >> we're finally ready to move all general Python dependencies for >> OpenStack over to DPMT. (We'll keep maint

<    1   2   3   4   5   6   7   8   >