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,12 @@
, 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.org
with a subject of unsubscribe
On 02/12/2013 11:13 PM, Dmitrijs Ledkovs wrote:
On 12 February 2013 15:08, Dmitry Shachnev mity...@gmail.com wrote:
Hi Thomas,
On Tue, Feb 12, 2013 at 7:00 PM, Thomas Goirand z...@debian.org wrote:
...
So I wonder, how is the python module packaging policy? Since this
module is marked
.
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
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
On 02/15/2013 12:41 AM, Sandro Tosi wrote:
On Thu, Feb 14, 2013 at 4:08 PM, Thomas Goirand z...@debian.org 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 not what I would
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*
On 02/15/2013 05:21 PM, Dmitry Shachnev wrote:
On Thu, Feb 14, 2013 at 10:54 PM, Thomas Goirand z...@debian.org 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) packages
-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/changelog 2013
On 02/16/2013 06:09 AM, Robert Collins wrote:
On 16 February 2013 01:52, Thomas Goirand z...@debian.org 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 attached to
this message.
Do
that SVN doesn't
work in some cases (which I already explained above and in other posts)
would be a good step on the right direction IMHO.
Cheers,
Thomas Goirand (zigo)
P.S: I'm truly sorry for breaking the thread, I was reading through the
archive, but now I'm registered to the list
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
On 02/18/2013 04:43 AM, Vincent Bernat wrote:
❦ 4 février 2013 20:00 CET, Örjan Persson ora...@fobie.net :
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
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
the
On 02/19/2013 06:08 AM, Thomas Kluyver wrote:
On 18 February 2013 20:46, Ludovic Gasc gml...@gmail.com
mailto:gml...@gmail.com 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
On 02/20/2013 01:23 AM, Dmitry Shachnev wrote:
On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand z...@debian.org 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've already expressed my opinion
On 02/20/2013 01:23 AM, Dmitry Shachnev wrote:
On Tue, Feb 19, 2013 at 9:11 PM, Thomas Goirand z...@debian.org 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've already expressed my opinion
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.
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 what upstream provides (that is, github .zip
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 should
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. make
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
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 release, or if you think
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, etc.
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
passed snapshot of the project.
In what way
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 have a full checkout of all team packages
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 which
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
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
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 is nice,
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 propose
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...@lists.debian.org
Archive: http://lists.debian.org/51271ad6.8020
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 from
Alioth, upstream source
.
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
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
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 right to have circular build-dependency
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 listmas...@lists.debian.org
Archive: http
.
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 unsubscribe. Trouble? Contact listmas
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 a statsd server
- python-statsd
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 a statsd server
- python-statsd
On 03/24/2013 01:16 AM, Jakub Wilk wrote:
* Dmitrijs Ledkovs x...@debian.org, 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
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
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
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?
Cheers,
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
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,
leading to a bit of frustration
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 document this fact in the changelog
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 z...@debian.org
Description:
python-requests - elegant and simple HTTP library for Python, built for
human being python3-requests - elegant and simple HTTP library
Subject: python-eventlet_0.12.1-2_amd64.changes REJECTED
Date: Sat, 11 May 2013 16:18:49 +
From: Debian FTP Masters ftpmas...@ftp-master.debian.org
To: Debian Python Modules Team
python-modules-t...@lists.alioth.debian.org, Thomas Goirand
z...@debian.org
There was an uncaught exception when
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.org
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. Trouble? Contact
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
--
To UNSUBSCRIBE, email to debian
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 python3-X.
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.
Rules for packaging things are normally there to solve
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
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's a good
example of a IMO badly named source package
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
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
: Julien Danjou a...@debian.org,
Thomas Goirand z...@debian.org,
Mehdi Abaakouk sil...@sileht.net
Build-Depends: debhelper (= 9), python-setuptools, python-all (= 2.6.6-3~),
openstack-pkg-tools
Standards-Version: 3.9.4
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=openstack
On 09/19/2013 12:55 AM, Thomas Kluyver wrote:
On 18 September 2013 08:41, Piotr Ożarowski pi...@debian.org
mailto:pi...@debian.org wrote:
so instead of reinventing the wheel and trying to make something that
works everywhere they should make it easier for others to convert
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) Python
On Fri Sep 20 2013 07:48:07 PM HKT, Paul R. Tagliamonte paul...@gmail.com
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,
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:
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
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 pushed to the SVN, because git-svn is producing some weird
errors. Andrey, could
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.
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 be very happy if we can tackle this one package which I need to
be ready for next week.
Cheers,
Thomas Goirand (zigo)
DEBVERS ?= $(shell dpkg
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 owner
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 package builds
completely.
With pbuilder
On 10/14/2013 07:23 PM, Jakub Wilk wrote:
* Barry Warsaw ba...@debian.org, 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
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
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.
So
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 line
On 10/15/2013 07:01 PM, Dmitry Shachnev wrote:
On Tue, Oct 15, 2013 at 1:19 PM, Thomas Goirand z...@debian.org 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-coverage
Build-Conflicts
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’ package,
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 binary
On 10/16/2013 01:52 PM, Tristan Seligmann wrote:
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
On 10/16/2013 02:05 PM, Ben Finney wrote:
Thomas Goirand z...@debian.org 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 can
obviously imagine some ways
, 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 anyone have a counter-argument for (not) doing this?
Cheers,
Thomas Goirand (zigo
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
,
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
. 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?
Cheers,
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian
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
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 Goirand wrote:
Yes, because someone found it useful to disable the git area in the team
repo on Alioth [1] !!! And this drove people to collab-maint. This was
predictable
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 orderly en mass transition? It
might
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 more
, love, flowers, etc.
Oh, and ... cheers!
Thomas Goirand (zigo)
[1] https://wiki.debian.org/Python/TransitionToDHPython2 has:
The two traditionally popular Python helpers, python-support and
python-central have both been deprecated in favor of dh_python2.
So if someone do not agree
On 01/26/2014 04:29 AM, Jakub Wilk wrote:
* Thomas Goirand z...@debian.org, 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 1st mail. This breaks the package
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
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.
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-paths
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
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,
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 the
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 I am
On 02/01/2014 04:10 PM, PICCA Frederic-Emmanuel wrote:
Hello,
I am packaging the next version of spyder which is a python IDE.
The next version will support python3
so I need to add a spyder3 binary package which will contain
/usr/bin/spyder3
the upstream script only create
instead. I would recommend that you do the
same, and that you do not rely on oauth2. Note that the API of oauthlib
is different from oauth2, even though they are supposed to do the same
kind of thing.
I hope this helps,
Cheers,
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-python-requ
of this
-examples package).
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: https://lists.debian.org/532470b7.3000...@debian.org
remove the intersphinx extension from conf.py? That's IMO much cleaner
than just blocking the connection.
I'm not sure about your binary extensions thing though...
Cheers,
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
On 04/07/2014 03:39 PM, picca wrote:
As for http_proxy='localhost', it's much better to write
http_proxy='127.0.0.1:9', as there really could be a web proxy running
on localhost, and you don't really want to use it, do you?
I just used the snipset of the wiki page explaining the library
1 - 100 of 409 matches
Mail list logo
