Here's a further update on packages pertaining to the 3.3 transition:
boost1.49 Fixed
flufl.bounce builds now that zope.interface is updated
hivex FTBFS fixed, dependencies fixed, nothing further to do.
libguestfs - No longer FTBFS on amd64, but does on i386, #710545, now builds
for all python3
On Wednesday, June 19, 2013 02:47:44 PM Brian May wrote:
On 19 June 2013 14:33, Scott Kitterman deb...@kitterman.com wrote:
Patch to use the installed copy. I had to do this once before.
How do I do this? I don't see any references to objects.inv in the
upstream source code for django
On Wednesday, June 12, 2013 03:13:38 PM Scott Kitterman wrote:
On Wednesday, June 12, 2013 12:48:45 AM Scott Kitterman wrote:
On Thursday, June 06, 2013 12:46:05 PM Scott Kitterman wrote:
More updates and added all the unknown packages from the transition
tracker. Items marked as fixed
On Wednesday, June 12, 2013 12:48:45 AM Scott Kitterman wrote:
On Thursday, June 06, 2013 12:46:05 PM Scott Kitterman wrote:
More updates and added all the unknown packages from the transition tracker.
Items marked as fixed in the last update have been removed.
On Thursday, May 23, 2013
On Thursday, June 06, 2013 12:46:05 PM Scott Kitterman wrote:
Here's another update based on work I've done, noticed other people did, or
responses to the last one of these I sent. It does not include work which I
neither notice nor people told me about. Items marked as fixed in the last
On Thursday, May 23, 2013 06:19:06 PM Scott Kitterman wrote:
I've been working on this a bit ...
On Tuesday, May 07, 2013 02:01:26 PM Jakub Wilk wrote:
python3-defaults maintainer(s?) decided to make python3.3 a supported
version without prior notice. Yay. Now we have dozens of packages
I've been working on this a bit ...
On Tuesday, May 07, 2013 02:01:26 PM Jakub Wilk wrote:
python3-defaults maintainer(s?) decided to make python3.3 a supported
version without prior notice. Yay. Now we have dozens of packages
failing to build:
boost1.49 FTBFS TODO
boost1.50 FTBFS TODO
On Tuesday, May 21, 2013 11:05:30 PM Reuben Thomas wrote:
Near the start of Chapter 1, Section 1.1:
implmentation → implementation
Checked against 0.9.4.2.
Fixed in the VCS for the next python-defaults upload.
Thanks,
Scott K
--
To UNSUBSCRIBE, email to
On Friday, May 17, 2013 10:53:39 AM Daniel Kahn Gillmor wrote:
On 05/17/2013 08:22 AM, W. Martin Borgert wrote:
Quoting Scott Kitterman deb...@kitterman.com:
Package: trac-accountmanager
...
Since the package has been removed from the PAPT repository, please
remove
PAPT
On Friday, May 17, 2013 01:33:38 PM Daniel Kahn Gillmor wrote:
On 05/17/2013 01:20 PM, Thomas Kluyver wrote:
This came up recently on debian-python. It's a very long thread, but the
basic outcome was that, while quite a few people wanted to move away from
svn, there was very little
On Friday, May 17, 2013 01:50:09 PM Daniel Kahn Gillmor wrote:
On 05/17/2013 01:40 PM, Scott Kitterman wrote:
If the team moves to full source git archives, I'll just drop the team
from
all the packages I maintain.
Scott K
P.S. See, now the fun begins.
fun, indeed. it sounds
On Friday, May 17, 2013 02:13:10 PM Daniel Kahn Gillmor wrote:
On 05/17/2013 01:55 PM, Scott Kitterman wrote:
You misunderstand.
I don't think i misunderstood at all.
I'm all for having a good common environment for the team to work on. I
happen to think you suggested just about
Do you object to the dropping of 2.6 or just the lack of discussion before it
was done?
Scott K
On Monday, May 06, 2013 09:29:11 AM Sandro Tosi wrote:
Hello,
has this been discussed *and* agreed on? I can only see Luca's mail
for python plans, but no ack from other members of the debian
On Thursday, March 14, 2013 05:56:47 PM Dmitry Shachnev wrote:
Hi,
We discussed new lintian vcs-field-not-canonical check in IRC last week,
which affects *lots* of packages in our SVN (see [¹]). Now people are
recommended to use `svn://anonscm.debian.org/*` URIs instead of
On Friday, February 22, 2013 03:14:30 PM Thomas Goirand wrote:
...
The problem is that with SVN, it takes so much time and space
(as each tag will generate some files), so you might have been
fooled into thinking it would also with Git. But the reality simply
not that at all.
...
I almost
Stefano Rivera stefa...@debian.org wrote:
Hi Jakub (2013.02.22_23:48:24_+0200)
* Stefano Rivera stefa...@debian.org, 2013-02-22, 23:31:
* you can ship extensions for more than one 3.x version in the
same private directory, thanks to tags
Does dh_python3 support such setup? (I would be
Stefano Rivera stefa...@debian.org wrote:
Hi Scott (2013.02.23_00:17:30_+0200)
* you can ship extensions for more than one 3.x version in the
same private directory, thanks to tags
Does dh_python3 support such setup? (I would be very surprised if
it
did.)
You have a point. That'd be
On Saturday, February 23, 2013 12:24:16 AM Jakub Wilk wrote:
* Scott Kitterman deb...@kitterman.com, 2013-02-22, 17:56:
* you can ship extensions for more than one 3.x version in the
same private directory, thanks to tags
Does dh_python3 support such setup? (I would be very surprised
On Wednesday, February 20, 2013 04:34:05 PM Thomas Goirand wrote:
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
On Wednesday, February 20, 2013 10:14:26 PM Thomas Goirand wrote:
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 is often better,
because tags may be PGP
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 locally,
so that means if I'm going to touch
On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote:
On 21/02/2013 01:59, Scott Kitterman wrote:
I've done the boring bits enough that my fingers mostly do them without
much attention from my brain. If I were going to abandon my current
approach, I'd have to see significant
On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote:
...
That argument applies to any VCS that you don't use on a daily basis. You
use bzr on a daily basis and forget how to use git. I use git on a daily
basis and forget how to use svn/bzr and have to relearn it any time someone
On Thursday, February 21, 2013 12:08:45 PM Chow Loong Jin wrote:
On 21/02/2013 11:58, Scott Kitterman wrote:
On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote:
On 21/02/2013 01:59, Scott Kitterman wrote:
I've done the boring bits enough that my fingers mostly do them without
On Wednesday, February 20, 2013 11:46:31 PM Barry Warsaw wrote:
At least with git, you know when you've rewritten history -- you're no
longer on the same commit.
#9 on Steve Bennett's list is right on target IMHO, but I've had this
discussion so many times before, I don't have much energy
On Thursday, February 21, 2013 03:00:56 PM Charles Plessy wrote:
Le Wed, Feb 20, 2013 at 11:02:15PM -0500, Scott Kitterman a écrit :
On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote:
...
That argument applies to any VCS that you don't use on a daily basis.
You
use
On Thursday, February 21, 2013 01:52:59 PM Chow Loong Jin wrote:
(Re-posted back on list. Sorry ScottK.)
On 21/02/2013 12:37, Scott Kitterman wrote:
With git (I've never used gpb, and maybe that's my problem) I end up
having to do things like:
git clone git://git.debian.org/….git
On Thursday, February 21, 2013 02:02:09 PM Chow Loong Jin wrote:
On 21/02/2013 12:46, Barry Warsaw wrote:
#9 on Steve Bennett's list is right on target IMHO, but I've had this
discussion so many times before, I don't have much energy for it again.
9. Git history is a bunch of lies
On Tuesday, February 19, 2013 05:20:48 PM Barry Warsaw wrote:
On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
After that it gets tricky, because we'd knock E out next, but the I'm not
sure where the votes counted for E (Scott Barry) should be reallocated.
If it makes things easier, I am
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 or .tar.gz, which
isn't the best).
See devref 6.7.8.
On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote:
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).
On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote:
On 16 February 2013 09:10, Thomas Goirand z...@debian.org wrote:
It would be really stupid to only want to claim to be working as part
of the team, that's not at all what I want to do. I'd like to be able to
help when I can,
On Sunday, February 17, 2013 10:35:01 AM Robert Collins wrote:
On 17 February 2013 08:29, Dmitrijs Ledkovs x...@debian.org wrote:
On 16 February 2013 14:27, Jakub Wilk jw...@debian.org wrote:
* Scott Kitterman deb...@kitterman.com, 2013-02-16, 09:10:
On Saturday, February 16, 2013 12:43:02
On Thursday, February 14, 2013 04:53:23 PM Barry Warsaw wrote:
On Feb 14, 2013, at 08:54 PM, Thomas Kluyver wrote:
I don't think it's a particularly good example, though. Lots of packages
continue to use the older helpers, and not due to a lack of time - attempts
to move away from the
On Monday, February 11, 2013 05:05:23 PM Piotr Ożarowski wrote:
[Barry Warsaw, 2013-02-11]
On Feb 11, 2013, at 03:51 PM, Piotr Ożarowski wrote:
I'd also use python-pil and let python-imaging contain the compat code
(with Depends: python-pil)
Do you mean, get rid of the -compat
Piotr Ożarowski pi...@debian.org wrote:
[Yaroslav Halchenko, 2013-01-20]
...
wouldn't it make more sense to ship it in a separate package since it
is
relevant not only for python3? then it would also make possible to
provide backport packages
yes, it makes sense. We already talked about it
I've just uploaded a version of python3-defaults to experimental to support
testing with python3.3 and with Piotr's new pybuild script (still definitely
experimental).
Here are the significant changelog entries:
* Add Python 3.3 to the list of supported Python 3 versions and make it a
On Friday, November 09, 2012 01:32:53 PM Thomas Kluyver wrote:
On 9 November 2012 12:44, Maykel Moya mm...@mmoya.org wrote:
Even in the case of the more restrictive license applying only to
debian/* work? Could you/someone elaborate a little the implications of
this (link to fine
Jakub Wilk jw...@debian.org wrote:
* Raúl Benencia r...@kalgan.cc, 2012-10-15, 19:41:
I would very much like to join the Debian Python team. I've a bit of
experience packaging and programming python apps, and now I would like
to help with the maintainance of some of the team's packages.
...@yahoo.es
calibre
Modestas Vainius mo...@debian.org
pykde4 (U)
Python Applications Packaging Team python-apps-t...@lists.alioth.debian.org
veusz
Scott Kitterman sc...@kitterman.com
python-qt4 (U)
qscintilla2 (U)
Sune Vuorela s...@debian.org
pykde4 (U)
Torsten Marek shlo
On Friday, September 28, 2012 09:53:42 AM Yaroslav Halchenko wrote:
On Fri, 28 Sep 2012, Paul Wise wrote:
^^ this is a great idea. It'd be nice if we could prototype a flake8 /
pyflakes run against the archive, and filter for serious errors
We did do that at one point with pyflakes:
Julien Cristau julien.cris...@logilab.fr wrote:
On Fri, Jul 13, 2012 at 11:57:01 -0400, Scott Kitterman wrote:
1. python{3}-foo which is arch all and follows the current naming
convention
of foo being the name you import. It would depend on the arch any
python-foo-
ext package.
all
On Monday, July 16, 2012 10:24:18 AM Yaroslav Halchenko wrote:
On Mon, 16 Jul 2012, Scott Kitterman wrote:
1. python{3}-foo which is arch all and follows the current naming
convention
of foo being the name you import. It would depend on the arch any
python-foo-
ext
On Monday, July 16, 2012 11:06:59 AM Yaroslav Halchenko wrote:
On Mon, 16 Jul 2012, Scott Kitterman wrote:
OK. python-nipy depends on python-nipy-lib. Makes sense.
Is python-nipy-lib useful on it's own?
nope -- moreover it might be somewhat detrimental -- module might
appear
On Friday, July 13, 2012 11:48:57 AM Barry Warsaw wrote:
On Jul 12, 2012, at 09:00 PM, Piotr Ożarowski wrote:
can we agree on a common suffix for such¹ packages and add a suggestion
to Debian Python Policy?
+1
I use -ext (python-sqlalchemy-ext) but now I see that there are also
-accel
debian-de...@liska.ath.cx wrote
Jakub Wilk jw...@debian.org writes:
* Olе Streicher debian-de...@liska.ath.cx, 2012-07-10, 12:14:
I: python-astropy: arch-dep-package-has-big-usr-share 4137kB 87%
How do I create an arch independend package that contains these
files?
[...] I'd rather not do
Toni Mueller t...@debian.org wrote:
Hi,
On Mon, Jun 18, 2012 at 01:09:55PM +0200, Jakub Wilk wrote:
* Toni Mueller t...@debian.org, 2012-06-18, 12:55:
debian/control:
...
X-Python-Version: = 2.5, 2.8
In any case, I'd get rid of the 2.8 part. Surely roundup cannot
be incompatible
On Tuesday, June 12, 2012 02:13:14 PM nore...@alioth.debian.org wrote:
I would like to join the python-apps team for the following reasons.
* short term: take care of pdfposter, update it to version 0.5.0, try to
close the existing bugs. * mid term: if the Maintainer of pdfposter
continues
Yaroslav Halchenko deb...@onerussian.com wrote:
On Tue, 12 Jun 2012, Denis Laxalde wrote:
Policy-compliant package name would be python-numpydoc, but that
could be easily confused with python-numpy-doc. So I agree with
your assessment: python-numpydoc-sphinx is a better for the
binary
On Friday, June 01, 2012 01:52:09 AM Nicolas Dandrimont (dandrimont-guest)
wrote:
Hello,
I'd like to join the PAPT to adopt and maintain the hellanzb package, that I
use and which needs some love.
I'm a DM and already a member of DPMT.
Thanks in advance,
Nicolas
Welcome to the
On Friday, May 18, 2012 11:48:07 AM Ana Guerrero wrote:
Hi,
I'm considering how feasible is removing Qt3 from wheezy. Even if
we freeze soon, removing packages is never a problem :-)
One of the big parts of the effort would be removing python-qt3, there are
only 6 packages in the archive
On Saturday, May 12, 2012 09:46:55 AM Sandro Tosi wrote:
On Fri, Apr 13, 2012 at 3:26 PM, Scott Kitterman deb...@kitterman.com
wrote:
On Friday, April 13, 2012 08:37:26 AM Sandro Tosi wrote:
On Thu, Apr 12, 2012 at 23:35, Scott Kitterman deb...@kitterman.com
wrote:
On Thursday, April 12
On Friday, May 04, 2012 06:38:30 PM Dmitrijs Ledkovs wrote:
On 04/05/12 18:23, Sandro Tosi wrote:
On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk jw...@debian.org wrote:
or in setuptools.
Ideally, by burning it with fire.
CPython upstreams are developing a new module to replace distutils
On Tuesday, May 01, 2012 10:45:24 AM Barry Warsaw wrote:
...
The ipaddr library is as well, though that might get the provisional
tag.
...
This is one I'll need to keep an eye on as ipaddr is packaged in dpmt as a
seperate module (maintained by me). Upstream has a separate release that's
On Wednesday, April 18, 2012 10:35:04 AM Paul Elliott wrote:
On Wednesday, April 18, 2012 10:12:24 AM Barry Warsaw wrote:
On Apr 18, 2012, at 03:09 AM, Paul Elliott wrote:
I am not a expert python packager. I am dubious about a bunch of cargo
cult packagers all writing seperate but similar
On Wednesday, April 18, 2012 02:35:20 PM Paul Elliott wrote:
On Wednesday, April 18, 2012 10:49:34 AM Scott Kitterman wrote:
Alternately you could invest a little time in understanding what Barry's
written up and build both sets of binaries from one source. This is the
usual method
On Wednesday, April 18, 2012 03:09:35 PM Paul Elliott wrote:
On Wednesday, April 18, 2012 02:46:33 PM Scott Kitterman wrote:
No. You'd need overrides for a python3 only source package as well. The
fundamental problem is debhelper doesn't know about building for python3.
That doesn't
On Saturday, April 14, 2012 05:12:54 PM Paul Wise wrote:
On Fri, Apr 13, 2012 at 9:26 PM, Scott Kitterman wrote:
times when the only 'solution' available is a short term hack that's
needed
for Ubuntu's time based release schedule that isn't appropriate to
Debian's
approach of doing
On Friday, April 13, 2012 08:37:26 AM Sandro Tosi wrote:
On Thu, Apr 12, 2012 at 23:35, Scott Kitterman deb...@kitterman.com wrote:
On Thursday, April 12, 2012 11:04:33 PM Sandro Tosi wrote:
On Thu, Apr 12, 2012 at 22:50, Scott Kitterman deb...@kitterman.com
wrote:
On Thursday, April 12
On Thursday, April 12, 2012 11:25:07 AM Stefano Zacchiroli wrote:
On Tue, Apr 03, 2012 at 10:36:58AM +0200, Stefano Zacchiroli wrote:
Allow me be blunt then: do we have volunteers to maintain the pythonX.Y
packages? Can those volunteers manifest themselves on this list?
So, ~10 days later
On Thursday, April 12, 2012 09:12:23 PM Sandro Tosi wrote:
On Thu, Apr 12, 2012 at 16:13, Scott Kitterman deb...@kitterman.com wrote:
I don't think that the *-defaults packages and the interpreter packages
fundamentally require the same maintainer, but I expect it to be
problematic to have
On Thursday, April 12, 2012 10:20:04 PM Sandro Tosi wrote:
To give a (fresh) example and what I meant above, you can try to
answer this provocative question: Why Ubuntu has Python 2.7.3 since
more than 2 days (even before it was publicly announced) while Debian
is still stuck with a RC,
On Thursday, April 12, 2012 11:04:33 PM Sandro Tosi wrote:
On Thu, Apr 12, 2012 at 22:50, Scott Kitterman deb...@kitterman.com wrote:
On Thursday, April 12, 2012 10:20:04 PM Sandro Tosi wrote:
To give a (fresh) example and what I meant above, you can try to
answer this provocative question
On Monday, March 19, 2012 12:20:18 PM Jakub Wilk wrote:
* Scott Kitterman deb...@kitterman.com, 2012-03-17, 14:29:
Upon reflection, this could be better stated something like this:
The generated minumum dependency may be different than the lowest
version currently supported. In such cases, X
On Thursday, March 15, 2012 12:02:42 PM Scott Kitterman wrote:
Last night I uploaded an updated python3-defaults package to fix a problem
where dh_python3 was not honoring version requirements set the -V option in
debian/rules or X-Python3-Version in debian/control.
If you have a python3
I've attached a patch (it's built on the last one I sent) that attempts to
clarify policy around packages that only work with specific versions of
Python/Python3. Here's what I attempted to do:
- Changed should support the default version to should support all supported
versions.
- Dropped
When Squeeze was nearing freeze, the definition of some aspects of python3
support were still new. There were some packages that used XS-Python-Version
in debian control, instead of X-Python3-Version.
There are now none (one package still has it in debian/control, but it's not
actually
I've worked on a couple of dh_python3 bugs in the last few days and as a
result, gotten my hands dirty on the Python 3 dependency generation code.
This caused me to consider the question of specifying which Python 3 versions
are supported by a package a little more closely. I have generally
Last night I uploaded an updated python3-defaults package to fix a problem
where dh_python3 was not honoring version requirements set the -V option in
debian/rules or X-Python3-Version in debian/control.
If you have a python3 module package that set a minumum version of python3 to
3.2 using
On Wednesday, March 14, 2012 12:41:32 PM Thomas Kluyver wrote:
On 14 March 2012 04:13, Scott Kitterman deb...@kitterman.com wrote:
I did have to make some additional changes, such as using a policy
compliant
binary name in python3, as we did for PyQt4 (python3-pyqt4.qsci) and
using
On Wednesday, March 14, 2012 04:02:40 PM Simon McVittie wrote:
On 14/03/12 15:40, Barry Warsaw wrote:
It would be nice to build for all supported Python 3 versions. Python
3.3 is currently scheduled for August of this year, but I'm hoping
we'll start seeing it show up in Debian around the
On Tuesday, March 13, 2012 11:27:01 PM Thomas Kluyver wrote:
Following on from tornado, the attached patch updates the packaging for
qscintilla2 to build Python 3 bindings. It's roughly following the
python-qt4 packaging (which it depends on).
Except for the Python/Python 2 parts (it's a
On Tuesday, March 13, 2012 11:27:01 PM Thomas Kluyver wrote:
Following on from tornado, the attached patch updates the packaging for
qscintilla2 to build Python 3 bindings. It's roughly following the
python-qt4 packaging (which it depends on).
I did have to make some additional changes, such
From the discussion in Bug #662965:
...packages sharing the same namespace must use the same helper.
They can use different helpers if the package that is earlier in
sys.path uses this trick:
http://docs.python.org/library/pkgutil.html#pkgutil.extend_path
The multiple helper path issue
Arthur de Jong adej...@debian.org wrote:
Hello lists,
I've been seeing what it would take to remove python-central from my
system and it wasn't actually that much so I sent patches to the BTS
for
the remaining packages and fixed a few python-apps-team and
python-modules-team packages in SVN.
On Sunday, January 29, 2012 12:28:22 AM Scott Kitterman wrote:
I just uploaded a new python-qt4 revision to experimental (it's arrival will
be delayed since it has to go through new.
It is experimental for at least three reasons:
1. It is changed to build with a multiarched Qt as qt4-x11
Piotr Ożarowski pi...@debian.org wrote:
[Scott Kitterman, 2012-01-29]
2. It builds a new python3-pyqt4-dbus (and dbg) package that needs
python3-
dbus which is only available in experimental at the moment.
why not python3-dbus.mainloop.qt?
Because I didn't think it through when naming
I just uploaded a new python-qt4 revision to experimental (it's arrival will
be delayed since it has to go through new.
It is experimental for at least three reasons:
1. It is changed to build with a multiarched Qt as qt4-x11 4.8 in
experimental is.
2. It builds a new python3-pyqt4-dbus
On Tuesday, January 17, 2012 07:14:23 PM Sandro Tosi wrote:
On Tue, Jan 17, 2012 at 18:12, kitter...@users.alioth.debian.org wrote:
Date: Tuesday, January 17, 2012 @ 17:12:00
Author: kitterman
Revision: 20032
* Team upload
...
* Switch to dh_python2
I think changing the
python-qt4 is currenlty broken in Unstable (See #653293) due to incompatible
changes in the new sip4 uploaded last week (thanks upstream). Upgrading
python-qt4 resolves this issue, but it is a major new release. I've rebuilt
some of the packages (like pykde4) the build-depend on it without
See #647210 for the most recent instance of these checks causing
problems. python-sip will raise a RuntimeError if the upstream version
of python-qt4 (specifically PyQt4.QtCore) used at runtime is different
than the one the package was built with.
RuntimeError: the PyQt4.QtCore module is
On 10/29/2011 05:23 PM, Bernd Zeimetz wrote:
On 10/29/2011 08:05 PM, Thomas Kluyver wrote:
Hi,
I've been having a go at repackaging some Python modules where I know the
same codebase can be compiled for Python 3. So far, that's pyzmq and
python-qt4. I've not done any packaging before, so I've
On Monday, October 03, 2011 09:56:21 PM Jakub Wilk wrote:
BTW, I'm slightly disturbed by the fact, that so many people believe
that a Python helper does code inspection (or maybe use some magical
means...) to generate python:Depends. It seems to be a new phenomenon, I
don't recall any
On Sunday, October 02, 2011 09:38:37 PM Miguel Landaeta wrote:
On Sat, Oct 1, 2011 at 9:25 AM, Thomas Waldmann tw-pub...@gmx.de wrote:
So, is anybody working on putting python2.7 into squeeze-backports or do
I need to work on that myself? (I don't have much experience with debian
packaging
The release team has given us a transition slot and python-defaults is ready
for upload, so we'll be starting the transition shortly. We're currently
looking into 642601. We're not aware of any other issues that might cause us
to delay.
Scott K
--
To UNSUBSCRIBE, email to
On Tuesday, September 27, 2011 08:07:09 PM Luca Falavigna wrote:
Il 27/09/2011 19:35, Scott Kitterman ha scritto:
We're currently looking into 642601.
It seems some uploaders have been asked to provide an update. If they
don't react, I could prepare a team upload myself.
I'm not aware
Currently python-qt4 is uninstallable due to breaks put in for python-dbus
when it switched. There's a proposed change to switch python-qt4 in DPMT svn.
Since switching sip4 to dh_python2 will break approximately the same packages
as switching python-qt4, I'm going to switch it too (working
On Thursday, July 07, 2011 01:30:48 AM Scott Kitterman wrote:
I've just uploaded 2.7.2-2 to experimental. It's mostly about dh_python2
improvements from POX, but also has some minor updates to Python Policy
that I think improve the currency of it a bit. Please review the changes
and I'll fix
On Sunday, July 10, 2011 06:53:34 PM Jakub Wilk wrote:
* Matthias Klose d...@debian.org, 2011-07-10, 19:34:
Changes:
python-defaults (2.7.2-3) experimental; urgency=low
.
* python: Provide python profiler.
* Provide a python2 symlink according to PEP 394.
Excuse me, what?
On Thursday, July 07, 2011 04:27:32 AM Piotr Ożarowski wrote:
[Scott Kitterman, 2011-07-07]
B.Packaging Tools
- B.1. distutils
- B.2. python-support
- B.3. python-central
- B.4. CDBS
+ B.1. dh_python2 and dh_python3
On Thursday, July 07, 2011 08:43:29 AM Jakub Wilk wrote:
* Scott Kitterman deb...@kitterman.com, 2011-07-07, 01:30:
I've just uploaded 2.7.2-2 to experimental. It's mostly about
dh_python2 improvements from POX, but also has some minor updates to
Python Policy that I think improve
On Thursday, July 07, 2011 11:23:13 AM Brian Sutherland wrote:
On Thu, Jul 07, 2011 at 09:18:19AM -0400, Scott Kitterman wrote:
On Thursday, July 07, 2011 04:27:32 AM Piotr Ożarowski wrote:
[Scott Kitterman, 2011-07-07]
B.Packaging Tools
- B.1
+16,7 @@
Scott Kitterman sc...@kitterman.com
- version 0.9.3.0
+ version 0.9.4.0
---
@@ -94,10 +94,11 @@
A.Build Dependencies
On Sunday, June 12, 2011 10:24:51 AM Yaroslav Halchenko wrote:
On Sun, 12 Jun 2011, Tshepang Lekhonkhobe wrote:
I am asking because I have a few packages which use pysupport now and
it seems to work (so it is the mighty for me)... not sure if I am
ready to invest time into doing a
Nikolaus Rath nikol...@rath.org wrote:
Hello,
What should I put into X-Python3-Version for a package that does not
support Python 3? According to
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html,
not providing that header would mean that the package is compatible
Barry Warsaw ba...@python.org wrote:
On May 15, 2011, at 11:57 PM, Scott Kitterman wrote:
http://pkgme.net/
Which is rather less complete for Python packaging than stdeb and I'd
prefer
we don't recommend.
Perhaps, but I think it's a good project to contribute to if you want
to make
package
Sandro Tosi mo...@debian.org wrote:
On Mon, May 16, 2011 at 16:43, Scott Kitterman deb...@kitterman.com
wrote:
I think it's deeply unfortunate that the pkgme authors chose
duplicate
something for which there is already a reasonably complete solution
rather
than focus on areas where
Sandro Tosi mo...@debian.org wrote:
On Mon, May 16, 2011 at 16:43, Scott Kitterman deb...@kitterman.com
wrote:
I think it's deeply unfortunate that the pkgme authors chose
duplicate
something for which there is already a reasonably complete solution
rather
than focus on areas where
On Sunday, May 15, 2011 06:24:47 PM Barry Warsaw wrote:
On May 15, 2011, at 10:40 PM, Piotr Ożarowski wrote:
[Janne Snabb, 2011-05-13]
I assume that pypi-install is the most sensible way to install
Python packages which have not been packaged for Debian.
true
[...]
How do I tell
On Wednesday, May 04, 2011 02:23:58 AM nore...@alioth.debian.org wrote:
Johannes Ring has requested to join your project.
Comments by the user:
Hi,
I am currently a member of the DPMT, but now I have started working on some
packages that fits better under the umbrella of PAPT. Therefore, I
501 - 600 of 683 matches
Mail list logo
