Re: RFS: decibel-audio-player (Adoption, new upstream release)

On 09/20/2011 06:26 AM, Leonardo Marín wrote: > Hi, > This was what I did, > > ljmarin@LM trunk $ svn diff > Index: debian/control > === > --- debian/control(revisión: 7520) > +++ debian/control(copia de trabajo) > @@ -4,11 +4,

Re: RFS: decibel-audio-player (Adoption, new upstream release)

On 09/20/2011 09:13 PM, Piotr Ożarowski wrote: > > python binary package provides dh_python2 helper and that's why Leonardo > bumped minimum required python version. See also > http://wiki.debian.org/Python/TransitionToDHPython2 > Thanks for the pointer. However, I don't understand this: "All p

Re: Comments regarding xen-api_1.3-14_amd64.changes

On 01/07/2012 08:44 PM, Luca Falavigna wrote: > Hi, > > it seems python files in python-xenapi package aren't byte-compiled properly. > You may want to refine dh_python2 call to fix that. > > Cheers, > Luca Hi Luca, Good catch, thanks for noticing it and letting me know! I was doing "dh_python2

How does team maintenace of python module works?

esh the package, and upload version 1.0 in debian experimental? Or do I need approval from current uploaders? What does it mean for a package to be team maintained in the python packaging team? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.o

Re: How does team maintenace of python module works?

On 02/12/2013 11:13 PM, Dmitrijs Ledkovs wrote: > On 12 February 2013 15:08, Dmitry Shachnev wrote: >> Hi Thomas, >> >> On Tue, Feb 12, 2013 at 7:00 PM, Thomas Goirand wrote: >>> ... >>> So I wonder, how is the python module packaging policy? Since this

Re: How does team maintenace of python module works?

t this rule may be reconsidered? It'd be really nice, as I'm sure I wouldn't be the only one happy with such decision. Cheers, and thanks for the many replies, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511cd4a7.6000...@debian.org

Re: How does team maintenace of python module works?

who might also help. Do you think that we should form another Alioth project for that? Wouldn't that be silly? What are the alternatives that you see, if we are a lot of people willing to do python module team maintenance using Git? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511cfe0b.1020...@debian.org

Re: How does team maintenace of python module works?

On 02/15/2013 12:41 AM, Sandro Tosi wrote: > On Thu, Feb 14, 2013 at 4:08 PM, Thomas Goirand wrote: >> Sandro, I have some problems with such an answer, especially when I >> tried to remain polite. This is an incentive so that I change my tone as >> well, and that's no

Re: How does team maintenace of python module works?

On 02/15/2013 02:04 AM, Dmitry Shachnev wrote: > I'm not against switching to Git Hi Dmitry, I believe there's some misunderstanding, so I must make it square. Again, I'm *not* asking for a full switch (or any switch at all) of all (or even some) packages of the python module team. I have *NEVER*

Re: How does team maintenace of python module works?

On 02/15/2013 05:21 PM, Dmitry Shachnev wrote: > On Thu, Feb 14, 2013 at 10:54 PM, Thomas Goirand wrote: >> I believe there's some misunderstanding, so I must make it square. >> Again, I'm *not* asking for a full switch (or any switch at all) of all >> (or even some

New upstream release of python-testtools

llab-maint BZR (since we agreed on it for python-fixtures, probably you would like this to be done as well for this package)? Cheers, Thomas Goirand (zigo) diff -u -N -r e/python-testtools-0.9.21/debian/changelog python-testtools-0.9.29/debian/changelog --- e/python-testtools-0.9.21/debian/chang

Re: [Openstack-devel] New upstream release of python-testtools

On 02/16/2013 06:09 AM, Robert Collins wrote: > On 16 February 2013 01:52, Thomas Goirand wrote: >> Hi Robert & Jelmer, >> >> I would like to upload a new upstream version of python-testtools. I >> have worked out some changes in the packaging, which I have attach

Re: How does team maintenace of python module works?

ixtures!). I do understand why some would like to keep a single VCS though. But maybe it could be a more relaxed rule not written into a stone, where some exceptions would be allowed at least. Recognizing that SVN doesn't work in some cases (which I already explained above and in other posts) wo

Re: How does team maintenace of python module works?

On 02/16/2013 08:36 PM, Tristan Seligmann wrote: > But this is exactly the point; if team members are doing work in SVN, > then your packages in Git are not benefitting from this work. Let's be practical for a bit. Some members of the team already said they like to use Git. So we wont have everyo

Re: Package adoptions

On 02/18/2013 04:43 AM, Vincent Bernat wrote: > ❦ 4 février 2013 20:00 CET, Örjan Persson : > >> I don't have the time to maintain my packages anymore. I just wanted to >> check with you guys first if you're interested in adopting the packages >> before I RFA them. The packages are python-setpro

Re: [Openstack-devel] New version of python-fixtures for debian experimental

On 02/15/2013 03:23 PM, Robert Collins wrote: > +1 on what you've done and what you propose. If you want to set > Maintainer to DPMT and commit it to the DPMT svn repository at the > same time, that would be awesome. Robert, Both python-fixtures and python-testtools are now stored in the SVN of t

Re: How does team maintenace of python module works?

On 02/19/2013 06:08 AM, Thomas Kluyver wrote: > On 18 February 2013 20:46, Ludovic Gasc > wrote: > > I vote D, and I can handle the migration from SVN to Git, I've > done this several times for my work and WYMeditor. > > Are you interested? > > I'm interested p

Re: How does team maintenace of python module works?

On 02/20/2013 01:23 AM, Dmitry Shachnev wrote: > On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand wrote: >> So far, those who could have vote C or D (this shows in previous reply >> that some could have voted that) didn't bother answering the "poll". > I'v

Re: How does team maintenace of python module works?

On 02/20/2013 01:23 AM, Dmitry Shachnev wrote: > On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand wrote: >> So far, those who could have vote C or D (this shows in previous reply >> that some could have voted that) didn't bother answering the "poll". > I'v

Re: How does team maintenace of python module works?

On 02/20/2013 06:20 AM, Barry Warsaw wrote: > * Figure out whether full-source or debian/ only works better (maybe give us > both repos so we can play with them and discuss the pros and cons from > actual working examples). What is important, I believe, is that git-buildpackage always works.

Re: How does team maintenace of python module works?

On 02/20/2013 12:38 PM, Scott Kitterman wrote: > On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote: >> The idea to use "git archive" was mostly from Julien Danjou. It's >> very nice because that way, we can use xz compression, instead >> of wha

Re: How does team maintenace of python module works?

On 02/20/2013 12:41 PM, Scott Kitterman wrote: > This all seems to assume full source branches which is not something I'm > interested in participating in at all. I've tried it and I find it very > difficult to work with. > > Currently we have one VCS and one package layout. In the end, we shou

Re: How does team maintenace of python module works?

On 02/20/2013 04:31 PM, Luca BRUNO wrote: > This may suit well for the openstack scenario, however in general I > could see at least two shortcomings: > * pristine upstream tarballs are not used (see the first "should" in > devref §6.7.8.2) > * it assumes that no tarball generation process (eg. m

Re: How does team maintenace of python module works?

On 02/20/2013 04:57 PM, Matthias Klose wrote: > So there would be no way anymore to build using upstream tarballs? Upstream tarballs, in some cases, is a concept of the past. When they are released (sometimes, they simply don't exist), it may only an image based on a git tag. Then using Git tags i

Re: How does team maintenace of python module works?

On 02/20/2013 10:23 PM, Barry Warsaw wrote: > On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote: > >> If sticking to our old habits is not the only valid point, that there >> are real technical reasons why we should never be using a git tag >> as the key for an upstream

Re: How does team maintenace of python module works?

On 02/20/2013 10:43 PM, Scott Kitterman wrote: > First, full source repositories are much larger than debian only > repositories. > I don't have a full checkout of all team packages locally, so that means if > I'm going to touch a package I don't have to download, it's more time, > bandwidth,

Re: How does team maintenace of python module works?

On 02/20/2013 11:09 PM, Barry Warsaw wrote: > On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote: > >>> You better be darn sure that upstream has excellent QA then, and that you >>> know for sure that a tag is correctly assigned to a buildable, tested, QA >>> pass

Re: How does team maintenace of python module works?

On 02/20/2013 11:45 PM, Scott Kitterman wrote: > On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote: >> On 02/20/2013 10:43 PM, Scott Kitterman wrote: >>> First, full source repositories are much larger than debian only >>> repositories. I don't

Re: How does team maintenace of python module works?

On 02/21/2013 12:32 PM, Barry Warsaw wrote: > On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote: > >> It is to a degree, but the learning curve for git is subtantially steeper >> than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or >> another and there is no question in my mind

Re: How does team maintenace of python module works?

On 02/21/2013 01:36 PM, Scott Kitterman wrote: > Agreed. > > I always liked this one http://netsplit.com/2009/02/17/git-sucks/ (enough to > be able to find it 4 years later). > > Scott K Lucky, 4 years later, the error messages of Git are much much more helpful than they used to be (in fact, since

Re: How does team maintenace of python module works?

On 02/21/2013 02:29 PM, Scott Kitterman wrote: > I've tried doing this. Then I looked back and noticed that I was spending a > LOT of time making the VCS pretty, just in case and rarely had to revert > anything. It turned out I was spending a lot of time to save a little time > and that's just

Re: How does team maintenace of python module works?

On 02/21/2013 02:26 PM, Scott Kitterman wrote: > >> I undertand that learning Git after BZR is hard, because learning BZR after >> Git is equally painful. I think that the key difficulty is whether a >> system is learned first or second, not the system itself. >> >> This is where git-buildpackage

Re: How does team maintenace of python module works?

On 02/21/2013 04:55 PM, Piotr Ożarowski wrote: > Can we go back to DPMT/PAPT workflow? Git vs. Bzr vs. Hg war is not > that relevant (and we already know which VCS won, at least in Debian ;P) > > Can we focus on what we want (without taking VCS into account if > possible) so that those who will pro

Re: How does team maintenace of python module works?

to your point that having an upstream source branch type of repository is too slow and too big. It's just simply not the case. Cheers, Thomas Goirand -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@list

Re: How does team maintenace of python module works?

On 02/22/2013 03:57 PM, Piotr Ożarowski wrote: > [Thomas Goirand, 2013-02-22] >> From a server in a data center in Seattle, it took me 90 seconds >> to download the packaging sources of python-eventlet. Compare >> this to the 4 seconds it takes me to clone python-warlock fro

Re: RFS: Fix for #678169 (python-mysqldb)

m at all to sponsor such an upload in SID. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513ea0ff.5000...@debian.org

Circular build-dependency in python-webob

Hi, When doing apt-get build-dep python-webob --no-install-recommends, I was surprised to see in the list, python-webob itself: root@GPLHost>_ ~# apt-get build-dep python-webob --no-install-recommends Reading package lists... Done Building dependency tree Reading state information... Done The fol

Re: Circular build-dependency in python-webob

On 03/13/2013 01:44 AM, Julien Cristau wrote: > On Wed, Mar 13, 2013 at 00:59:42 +0800, Thomas Goirand wrote: >> There must be something wrong here. > What makes you think that? Well, I know that's arch all that we're talking about, but still, it doesn't feel r

Re: RFS: Fix for #678169 (python-mysqldb)

e make a new debdiff between -1 and -2, and deal with the release team for having this change unblocked. Thanks for your contribution in Debian, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact lis

Re: statsd + voluptuous packaged!

-maintain the package with you. What do you think? My nick is "zigo" on OFTC and Freenode. Please ping me. I'm French as well (though I live in China currently). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of &qu

Re: statsd + voluptuous packaged!

On 03/22/2013 06:19 AM, Antoine Musso wrote: > Le 21/03/13 19:21, Thomas Goirand a écrit : >> I happen to also have worked on statsd: >> http://anonscm.debian.org/gitweb/?p=openstack/statsdpy.git > Bonjour =) > > It seems they are different packages: > - statsdpy is

Re: statsd + voluptuous packaged!

On 03/22/2013 06:19 AM, Antoine Musso wrote: > Le 21/03/13 19:21, Thomas Goirand a écrit : >> I happen to also have worked on statsd: >> http://anonscm.debian.org/gitweb/?p=openstack/statsdpy.git > Bonjour =) > > It seems they are different packages: > - statsdpy is

Re: About canonical Vcs fields

On 03/24/2013 01:16 AM, Jakub Wilk wrote: > * Dmitrijs Ledkovs , 2013-03-23, 13:01: >>> Okay. Unless I hear objections, I'll do mass-commit to switch to >>> anonscm.d.o in ~2 weeks. >> Can you do such commit simply after wheezy is out the door? > > I don't mind if we release in two weeks. ;P > Sure

Re: RFS: bunch, kitchen, grapefruit, fabulous, stomper, txws, txzmq, moksha.common, moksha.hub

On 05/08/2013 02:04 AM, Simon Chopin wrote: > bunch: Dot-accessible Python dictionary (a la JavaScript objects) > kitchen: Cornucopia of useful Python code > grapefruit: Python module to manipulate color information easily > fabulous: Makes your terminal output totally fabulous I thought these were

Is subgit for migrating from Git to SVN?

Hi, I came accross http://subgit.com/ Could it be of any help for us? Thomas P.S: This seems to be a server tool, not a git plugin for SVN, which I was searching for, seeing how lame git-svn is... -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscri

Re: Upload of python-mock 1.0.1 to Debian unstable

On 05/08/2013 01:46 PM, Michael Fladischer wrote: > On 2013-05-07 22:32, Simon Chopin wrote: > > I'd like to know if/when you plan to upload python-mock 1.0.1 in > > unstable (it sits at the moment in experimental). > > I'm preparing it right now in SVN. > > @Stefanor: Could you sponsor me again? >

Upload of python-eventlet to experimental without SVN commits

Hi Laszlo, I noticed that python-eventlet 0.12.1-1 has been uploaded to experimental, with the last changelog entry being from you. on the 02 Mar 2013. However, the packaging source hasn't been modified on the SVN, leading to a bit of frustration on my side, seeing that I worked on the package and

Re: Upload of python-eventlet to experimental without SVN commits

On 05/11/2013 01:33 PM, Thomas Goirand wrote: > Hi Laszlo, > > I noticed that python-eventlet 0.12.1-1 has been uploaded to > experimental, with the last changelog entry being from you. on the 02 > Mar 2013. However, the packaging source hasn't been modified on the SVN, &

Re: Upload of python-eventlet to experimental without SVN commits

On 05/11/2013 01:42 PM, Thomas Goirand wrote: > When I'm at it, how come the Uploaders: has been changed, with > only you in it, and all of the previous uploaders being removed, > > 1/ Have you asked the maintainers you removed if they wished to do that? > 2/ Please docum

Re: Accepted requests 1.2.0-2 (source all)

On 05/11/2013 07:32 PM, Daniele Tricoli wrote: > Hello, > > On Saturday 11 May 2013 06:33:00 you wrote: >> Changed-By: Thomas Goirand >> Description: >> python-requests - elegant and simple HTTP library for Python, built for >> human being python3-requests - el

Fwd: python-eventlet_0.12.1-2_amd64.changes REJECTED

Original Message Subject: python-eventlet_0.12.1-2_amd64.changes REJECTED Date: Sat, 11 May 2013 16:18:49 + From: Debian FTP Masters To: Debian Python Modules Team , Thomas Goirand There was an uncaught exception when processing your upload: Traceback (most recent cal

Re: Is subgit for migrating from Git to SVN?

On 05/12/2013 04:26 PM, Dmitry Shachnev wrote: > “SubGit is a closed source software.” Oh! Missed that. Thanks for taking the time to look at it. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.o

Update of python-anyjson 0.3.3

Hi Michael, I've seen that you've updated the debian/changelog in order to upload the new upstream version. Is it ok if I upload it to Sid right now? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe&quo

Re: Update of python-anyjson 0.3.3

On 06/26/2013 02:10 PM, Thomas Goirand wrote: > Hi Michael, > > I've seen that you've updated the debian/changelog in order to upload > the new upstream version. Is it ok if I upload it to Sid right now? > > Thomas Goirand (zigo) FYI, this has been done. Thomas

Inconsistency in source package naming for python modules

rewards), but I wanted to raise this topic to check if others have the same opinion, and to make sure we have this in the python policy (in one way or the other). Thoughts anyone? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject

Re: Inconsistency in source package naming for python modules

On 07/08/2013 10:10 PM, Scott Kitterman wrote: > There is no policy on this either way, so there's no "mistake". Well, the mistake is precisely to have no rule, IMO. On 07/08/2013 11:37 PM, Barry Warsaw wrote: > Hopefully, it will become more and more common to have at least > python-X and python

Re: Inconsistency in source package naming for python modules

On 07/10/2013 10:30 PM, Stuart Prescott wrote: > Thomas Goirand wrote: >> On 07/08/2013 10:10 PM, Scott Kitterman wrote: >>> There is no policy on this either way, so there's no "mistake". >> >> Well, the mistake is precisely to have no rule, IMO. >

Re: Inconsistency in source package naming for python modules

On 07/11/2013 03:59 AM, Bradley M. Froehle wrote: > I think a recommendation (for new packages) would be helpful, but I'm > against any source naming requirements or strict rules. Then we agree! That's all what I'm asking for. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debi

Re: Inconsistency in source package naming for python modules

On 07/11/2013 04:07 AM, Piotr Ożarowski wrote: > [Thomas Goirand, 2013-07-10] >> And then, finally, it's called "migrate" instead of "sqlalchemy-migrate" >> like upstream called it... :) >> (this never happened to me with python-migrate, though that&#

Re: Inconsistency in source package naming for python modules

On 07/11/2013 09:07 PM, Stuart Prescott wrote: > >> Oh, I need this pyX package... Let's download it. > > You're using a python module name because you need to import it. If you want > to import modules, you want the binary package name; if you want to work on > the source package then you need

Re: PyCon 2013 -- anyone submitted/planing to go?

On 09/05/2013 09:10 PM, Yaroslav Halchenko wrote: > and present what > to expect in upcoming stable (wheezy) release of Debian You may want to update that part! :) Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listma

Re: PEP 453 affects Debian packaging of Python packages

DEB_PKG_NAME}-${VERSION_STRING} echo "===> Creating debian folder for ${DEB_PKG_NAME}" if [ ! -d ${DEB_PKG_NAME}-${VERSION_STRING}/debian/source ] ; then mkdir -p ${DEB_PKG_NAME}-${VERSION_STRING}/debian/source fi cd ${DEB_PKG_NAME}-${VERSION_STRING} echo "Source: ${D

Re: PEP 453 affects Debian packaging of Python packages

On 09/19/2013 12:55 AM, Thomas Kluyver wrote: > On 18 September 2013 08:41, Piotr Ożarowski > wrote: > > so instead of reinventing the wheel and trying to make something that > works everywhere they should make it easier for others to convert > whatever they p

Re: Disabling pip for root?

On 09/19/2013 05:26 PM, W. Martin Borgert wrote: > On 2013-09-18 09:36, Paul Tagliamonte wrote: >> 1) pip isn't for global package management, for this is stupid. If we >> disabled root use of pip, I think we'd all be a bit happier. > > Very quick and very dirty patch attached. > >> 4) P

Re: Disabling pip for root?

On Fri Sep 20 2013 07:48:07 PM HKT, Paul R. Tagliamonte wrote: > Why not see if upstream pip wants to add an optional dpkg install method > when using root on a dpkgey system? Slightly hackish but at least itd > reduce suck. Very good idea indeed! Thomas -- To UNSUBSCRIBE, email to debian-p

Re: PEP 453 affects Debian packaging of Python packages

PLEASE everyone, I'm registered to the list, and adding me as Cc: is breaking my filters... Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523d1d76.60...@deb

Packaging wheel

Hi, I came across this in the OpenStack global-requirements.txt file: https://pypi.python.org/pypi/wheel Is this of any interest for Debian? Has anyone used it? Would it be nice to have it packaged? Your thoughts? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ

Re: Python-babel 1.3 available from Sid

On 10/08/2013 03:34 AM, Sebastian Ramacher wrote: > Hi > > On 2013-10-08 00:50:27, Thomas Goirand wrote: >> Hi, >> >> FYI, I have uploaded python-babel 1.3 in Sid. I couldn't wait for more, >> so I did the work... >> >> I haven't pus

Re: Python-babel 1.3 available from Sid

On 10/08/2013 07:28 PM, Sebastian Ramacher wrote: >> He wrote that on Wed, 28th of Aug 2013. That's a long time ago, and as I >> couldn't wait for more, as some or my packages for OpenStack >> (build-)depends on Babel 1.3. > > For a package that had to go through NEW anyway that's really no excuse

Re: Program shebang line with specific ‘/usr/bin/pythonX.Y’ interpreter

n the BZR repository? That's because currently, even if debian/changelog says version 3.7, there's differences with upstream tarball which makes FTBFS, so I can't work correctly on the packaging... Then when done, I'll be able to test it more, and see if I can sponsor it. I'll

Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems

On 10/12/2013 01:26 AM, Barry Warsaw wrote: > On Oct 11, 2013, at 07:23 PM, Julian Taylor wrote: > >> It is better if one disables internet access of package builds completely. >> With pbuilder and iptables this is very easy, just run this when booting: >> >> iptables -I OUTPUT ! -d 127.0.0.1 -m o

Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems

On 10/12/2013 11:33 AM, Scott Kitterman wrote: > On Saturday, October 12, 2013 11:26:28 Thomas Goirand wrote: >> On 10/12/2013 01:26 AM, Barry Warsaw wrote: >>> On Oct 11, 2013, at 07:23 PM, Julian Taylor wrote: >>>> It is better if one disables internet access of

Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems

On 10/14/2013 07:23 PM, Jakub Wilk wrote: > * Barry Warsaw , 2013-10-11, 11:03: >> The point of this recommendation is so that missing Build-Depends are >> exposed when you are testing your package builds locally. > > ACK > >> If you omit them, your package will still properly FTBFS, but only on

Using update-alternatives for /usr/bin provided binaries

ngs here? Please let both Ben and I know your view. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525cb199.2010...@debian.org

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

On 10/15/2013 02:39 PM, Ben Finney wrote: > My disagreement is several-fold: > > * The binary package ‘python-coverage’ is for Python 2, and > ‘python3-coverage’ is for Python 3. These are, as I understand it, > deliberately treated as distinct runtime systems in Debian's Python > world. >

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

On 10/15/2013 07:04 PM, Jakub Wilk wrote:> Apparently two (mostly orthogonal) problems have been squeezed into a > single bug report: > > 1) Is the name /usr/bin/coverage appropriate? > 2) Can the alternatives mechanism be used to switch between the two > implementations of the coverage command lin

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

On 10/15/2013 07:01 PM, Dmitry Shachnev wrote: > On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand wrote: >> If we have update-alternatives, then it's very easy for a maintainer to >> choose which one of the 2 implementation it wants: >> >> Build-Depends: python-cove

Re: Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool

On 10/16/2013 07:32 AM, Ben Finney wrote: >> Nearly all OpenStack projects are using testrepository. All of them >> are using python-coverage. > > That sounds like an excellent central point to make the command name > parameterisable: fix it in one place to match the Debian > ‘python-coverage’ pac

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

On 10/16/2013 02:20 PM, Robert Collins wrote: > I think it's reasonable to get OpenStack to look for python-coverage > to run it's tests when using a system package. Or use python -m > coverage. 'coverage' is indeed super generic and the precedent within > Debian for the package is to call the bina

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

On 10/16/2013 01:52 PM, Tristan Seligmann wrote: > 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 t

Re: Claiming ‘/usr/bin/coverage’ for a Python-specific programmer tool

On 10/16/2013 02:05 PM, Ben Finney wrote: > Thomas Goirand writes: > >> 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

Re: Best practice: .egg-info with pybuild from git

" in debian/source/options. That's just a one liner, and it solves all problems. I've found this in a package, and I now use it. Probably there's a better regular expression, I didn't investigate, though that one above works well. Comments on it are welcome. Does anyo

Re: Trim out Ubuntu entries in d/changelog?

ourse, the above is what *I* would do, and there's no Debian policy regarding this. Though I think it does make sense. Your thoughts? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52a3de3d.3040...@debian.org

python-networkx 1.8 in Sid

d? Let me know, Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bc0b97.7030...@debian.org

Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto

-setuptools Hi, Just reacting on the above change. It's my understanding that we do need to add dh-python explicitly if we want clean backports (eg: unchanged from Sid). Am I right? If that's the case, shouldn't we advise to write dh-python explicitly for until Jessie is released? Cheer

Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto

ny others, I am hoping for the Debian PPAMAIN repositories to be available to start doing that. That's the only way, or we'd have to change the backports policy, which I don't see happening anytime soon. Thoughts on this would be very much welcome! Cheers, Thomas Goi

Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto

On 12/28/2013 10:47 PM, Piotr Ożarowski wrote: > [Thomas Goirand, 2013-12-28] >> python3 depends on dh-python. As much as I can see, that's the only >> package with a direct dependency on dh-python. Therefore, for Jessie, it >> is perfectly valid to omit dh-python in buil

Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

On 01/14/2014 09:24 PM, Alexandre Rossi wrote: > I also found out that some packages maintained > by the team are hosted on alioth in collab-maint (src: bugz, > dajaxice). Yes, because someone found it useful to disable the git area in the team repo on Alioth [1] !!! And this drove people to colla

Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

tices in this mailing list over time, but it's really important > to put a stake in the ground. If you can't decide which of two ways is > better, do one package one way and another the other way. I do believe in freedom as well! :) > On Jan 22, 2014, at 11:51 AM, Thomas Goiran

Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access

On 01/22/2014 07:39 PM, Matthias Klose wrote: > Am 22.01.2014 08:28, schrieb Thomas Goirand: >> On 01/22/2014 12:24 PM, Barry Warsaw wrote: >>> Do you really think that it's unfeasible for git proponents on this team to >>> find the necessary resources to plan an

Re: Indeed, python-concurrent.futures is the same

On 01/25/2014 06:01 PM, Sandro Tosi wrote: > Sorry, what? and you didn't think to contact me first to almost > rewrite the package? If there's problems, open bugs. Revert your > changes or I'll do at the first occasion. and mainly, why don't you go > away from DPMT once and for all? you're doing mo

Re: Indeed, python-concurrent.futures is the same

Also, I believe a vast majority inside Debian also agrees with me that Git is better. Sticking to SVN has, and will continue, to drive people away from the team (there's numerous examples of this already, including these TEAM modules on collab-maint). So, I really wonder who's doing fan

Re: Indeed, python-concurrent.futures is the same

On 01/26/2014 04:29 AM, Jakub Wilk wrote: > * Thomas Goirand , 2014-01-26, 03:50: >> - No file shipped into /usr/lib/python2.x/dist-packages (well, 2.7 for >> Sid, and 2.x if you consider an eventual backport). Now, I'm saying: >> "sorry what?" like on your 1

Re: Indeed, python-concurrent.futures is the same

On 01/26/2014 01:21 AM, Sandro Tosi wrote: >> if you don't want the package to be team maintained, perhaps take >> it out of team maintenance? > > lecturing is not required, thanks Actually, it seems it's required here. From this page: https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin on

Re: Indeed, python-concurrent.futures is the same

Thanks for your comments Jakub, On 01/26/2014 05:47 AM, Jakub Wilk wrote: > $ PYTHONWARNINGS=d python -c 'import futures' > /usr/lib/python2.7/dist-packages/futures/__init__.py:24: > DeprecationWarning: The futures package has been deprecated. Use the > concurrent.futures package instead. >Dep

Re: Indeed, python-concurrent.futures is the same

On 01/26/2014 05:52 AM, Andrew Starr-Bochicchio wrote: > Also from Python Policy: > >> > Modules managed by python-support are installed in another directory >> > which is added to the sys.path using the .pth mechanism. > https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-

Re: Making packaging Python modules fun again

On 01/27/2014 11:23 PM, Matthias Klose wrote: > Am 27.01.2014 00:14, schrieb Nicolas Dandrimont: >> - Adding Python 3 support when upstream has it > > I think this should make it into the python policy. > > Matthias I agree. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.de

Re: Is python-django still maintained in DPMT svn?

On 01/28/2014 10:03 PM, Barry Warsaw wrote: > Cool. I may also take a look at #736878 (Python 3 support). This would be much much much appreciated if someone took care of that one indeed! :) And the sooner the better, so that reverse dependencies we maintain can also support Python 3. Cheers,

Re: Indeed, python-concurrent.futures is the same

On 01/31/2014 03:20 PM, Vincent Bernat wrote: > [...] > > Sandro has orphaned python-concurrent.futures: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736714 > > Since it is team maintained, I don't think it really makes sense. Should > we just close the bug report and remove Sandro from th

Re: python-future: clean single-source support for Python 2/3

On 02/05/2014 06:04 AM, Brian May wrote: > Hello, > > Has anybody considered packaging python-future for Debian? > > No, I am not talking about python-futures, python-concurrency.futures, > or anything relating to #736523 (the first message in this bug had > rather confused at first). > > Rather

  1   2   3   4   5   6   >