Hello,
19 packages uses syntax constructs specific to Python 2.5+ in their
public modules but don't declare that minimum supported version is 2.5.
I'm looking for volunteers to do MBF.
Packages:
calibre_0.5.14+dfsg-1
elyxer_0.98-1
epigrass_2.0.1~dfsg-1
idjc_0.8.2-2
* Vincent Bernat ber...@debian.org, 2010-05-17, 21:43:
19 packages uses syntax constructs specific to Python 2.5+ in their
public modules but don't declare that minimum supported version is
2.5. I'm looking for volunteers to do MBF.
Out of curiosity, what method did you use to determine
Hi Jakub (2010.05.17_20:01:25_+0200)
19 packages uses syntax constructs specific to Python 2.5+ in their
public modules but don't declare that minimum supported version is 2.5.
I'm looking for volunteers to do MBF.
Done, only 13 real bugs.
calibre_0.5.14+dfsg-1 False positive
.
[…]
Thanks for filing those, Stefano.
All the bugs were just errors thrown in the python-support hook,
[…]
I admit to being surprised that it was attempting to compile for Python
2.4 when that version isn't supported any longer.
Do we consider it a bug that ‘python-support’ is attempting
once Python 2.4 is removed from the
list of support Python versions.
While you're there, you might also migrate from python-central to
python-support (this is the advice of the debian-python list):
http://wiki.debian.org/DebianPython/central2support
-- System Information:
Debian Release: squeeze
on Thu Mar 13 2008, Steve M. Robbins steve-AT-sumost.ca wrote:
Actually, the only thing about Boost that causes grief to packagers is
that the toolset name (e.g. gcc42) is embedded in the library
filename. I just wrote a response on Boost.Build outlining this in
some detail [1]. Embedding
On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
on Thu Mar 13 2008, Steve M. Robbins steve-AT-sumost.ca wrote:
Actually, the only thing about Boost that causes grief to packagers is
that the toolset name (e.g. gcc42) is embedded in the library
filename. I just wrote a
Steve,
Steve M. Robbins wrote:
It turns out to be simpler than that. With a small tweak to boost's
Jamroot file, I'm now generating libraries without the toolset and
without the Boost version decorations. I will use this for the
upcoming Boost 1.35.0 Debian packages.
By all means, could
On Fri, Mar 21, 2008 at 12:18:17PM -0500, Steve M. Robbins wrote:
I wrote about three weeks ago [1] that I'm trying to get Boost's
Python extension helper library building with multiple Python
versions. Several very helpful suggestions were made, for which I am
grateful.
I have been
On Mon, Mar 24, 2008 at 05:52:47PM +, Dominic Hargreaves wrote:
However, it looks to be like the shlibs file needs updating.
Yes, and thanks for the bug report. Upload is being prepared now.
-Steve
signature.asc
Description: Digital signature
On Fri, Mar 21, 2008 at 03:59:30PM -0400, Aaron M. Ucko wrote:
I do, however, see a couple of concrete issues with your script:
if [ $1 = -d ]; then
debug=-d
shift
fi
Shouldn't you fix that at build time à la $version?
You noticed a complication I was avoiding. There are
Steve M. Robbins [EMAIL PROTECTED] writes:
libraries, including the Boost.Python libraries. The only difference
in names is that the debug libraries have -d in them. So I was
avoiding two scripts by this parameterization.
Ah, thanks for clarifying; I had forgotten about the -dbg package,
Hello,
I wrote about three weeks ago [1] that I'm trying to get Boost's
Python extension helper library building with multiple Python
versions. Several very helpful suggestions were made, for which I am
grateful.
I have been plugging away, very slowly, ever since. I'm hoping to
upload it later
Steve M. Robbins [EMAIL PROTECTED] writes:
This allows extension builders to select either the default Python
version, or a specific version, without knowing the Boost
and GCC versions [2].
Yep; so far so good.
I'd like to ask about intended behaviour if a bad action is supplied.
Or if an
On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
on Sat Feb 23 2008, Steve M. Robbins steve-AT-sumost.ca wrote:
[...]
This produces pairs of library files such as
bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
On Tue, Feb 26, 2008 at 10:04:26PM -0600, Steve M. Robbins wrote:
On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
Decorate only the shared library names with the python versions, and retain
the current names for the .a files and .so symlinks - with two separate -dev
Hi,
On Tue, Feb 26, 2008 at 10:04:26PM -0600, Steve M. Robbins wrote:
On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote:
The solution is to keep the names decorated with both python versions,
but to maintain a farm of symbolic links pointing to the current python
Le mardi 26 février 2008 à 22:04 -0600, Steve M. Robbins a écrit :
The idea is to create a single -dev package that contains the
following in /usr/lib:
libboost_python-py24-gcc42-1_34_1.so
libboost_python-py24-gcc42-1_34_1.a
libboost_python-py25-gcc42-1_34_1.so
extension modules will, in fact, build for both Python 2.4 and
2.5. Now imagine an extension module that uses Boost.Python. As
mentioned, it must have the relevant build-deps. To support this, the
relevant boost-python development packages must be co-installable
(i.e. not conflict with each other
Steve M. Robbins wrote:
Hi,
Thanks to Steve, Bernd, and Josselin for ideas.
On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
Decorate only the shared library names with the python versions, and retain
the current names for the .a files and .so symlinks - with two separate
they end up in separate directories.
The proposal above is that we provide a boost-python-2.4-dev and a
boost-python-2.5-dev package that conflict with one another (because
they would contain files of the same name). This prevents a source
package from depending on both for a build, and therefore
Hi,
I'd suggest to do
3. Put the libraries in different subdirectories, e.g.
/usr/lib/python2.4/libboost_python-gcc42-1_34_1.a
/usr/lib/python2.5/libboost_python-gcc42-1_34_1.a
and add a symlink to /usr/lib which points to the library version for
the current default python
Hi,
I'm part of the Debian Boost packaging team, seeking some guidance on
how to build and install Boost.Python so that it is usable with all
Python versions shipped in Debian. Debian currently ships Python 2.4
and 2.5.
When reading the following, keep in mind that Boost.Python is not a
Python
in
Python 2.4 and up
if _lsbStrToInt(buffer[:4]) != 0x950412de:
/usr/lib/python2.3/site-packages/PyPlucker/helper/gettext.py:176:
FutureWarning: hex/oct constants sys.maxint will return positive values in
Python 2.4 and up
f.write(_intToLsbStr(0x950412de))# magic number
/usr/lib/python2.3/site
Matthias,
On Tue, Jun 13, 2006, Matthias Klose wrote:
We will prepare the transition in experimental by an upload of the
python, python-dev packages
I tried testing my rtupdates scripts by installing python version
2.4.3-5 from experimental, but they didn't seem to run, and I
Hi,
With the upcoming releases of the last packages which
didn't support 2.4 yet (Plone on the Zope application server) we may
be able to drop support for 2.3 in sid and etch as well.
For reference, decompyle still needs python2.3. There are two issues:
1. It won't build under python2.4.
decompile python2.4 bytecode. This will be somewhat harder
to fix (and I haven't done it yet).
If it is not able to decompile recent python version, then it is a kind
of useless one. Python 2.4 is out since a while, what are upstream plans
for their software ?
--
Marc Dequènes (Duck
(e.g., rm *.py, oops), which is why I
want to keep it around.
Python 2.4 is out since a while, what are upstream plans for their software ?
Upstream went commercial back in the 2.2 days. The debian packages
forked and essentially became the de-facto upstream source when 2.3
decompilation
Steve Langasek [EMAIL PROTECTED] writes:
That much is obvious. The point is wouldn't it be confusing to the user to
call the package python-ctypes when it doesn't support the current python
version? Oh well, I guess I can put in something in the description to
explain this.
A package named
Josselin Mouette [EMAIL PROTECTED] writes:
Le jeudi 18 mai 2006 à 00:11 -0500, Steve Langasek a écrit :
A package named python-ctypes must support the current python version: it
must ensure this by having a versioned dependency on the versions of python
that it is compatible with.
That
Steve Langasek writes:
On Wed, May 17, 2006 at 10:03:15AM +0530, Ganesan Rajagopal wrote:
Josselin Mouette [EMAIL PROTECTED] writes:
In short, the main decision has been to drop entirely python2.x-foo
packages. They will, however, be provided as virtual packages, but only
if
On Wed, May 17, 2006 at 10:03:15AM +0530, Ganesan Rajagopal wrote:
Josselin Mouette [EMAIL PROTECTED] writes:
In short, the main decision has been to drop entirely python2.x-foo
packages. They will, however, be provided as virtual packages, but only
if something actually needs them.
Josselin Mouette [EMAIL PROTECTED] writes:
Le mercredi 17 mai 2006 à 14:12 +0530, Ganesan Rajagopal a écrit :
I understand the upgrade issues that pythonX.Y packages cause with multiple
versions of python in Debian. However, for binary modules I don't really see
an alternative in some cases.
On Thu, May 18, 2006 at 10:06:59AM +0530, Ganesan Rajagopal wrote:
Josselin Mouette [EMAIL PROTECTED] writes:
Le jeudi 18 mai 2006 à 08:17 +0530, Ganesan Rajagopal a écrit :
There's no point in simplifying python packaging if in fact it becomes
more complicated because we allow
On 5/13/06, Raphael Hertzog [EMAIL PROTECTED] wrote:
On Fri, 12 May 2006, Andreas Barth wrote:
How about, right now, just a statement this is what the issues are.
Or even, this [URL here] is the mailing list post where the issues
are outlined.
I forgot about them. So, I need to collect
...
Matthias has some updates on python-central on his laptop and he should
upload it somewhere so that we can take a look.
We agreed to switch to python-2.4 in the week following debconf (next week
that is) and go on with whatever we have at that time.
Cheers,
--
Raphaël Hertzog
Premier livre français sur
python-support ? Can we
technically keep using both (we shouldn't IMHO!) ?
We agreed to switch to python-2.4 in the week following debconf (next week
that is) and go on with whatever we have at that time.
Great news, i just want to have an idea now, how much work we will
need to put dpmt packages
Le mardi 16 mai 2006 à 17:04 -0300, Gustavo Franco a écrit :
Matthias has some updates on python-central on his laptop and he should
upload it somewhere so that we can take a look.
Ok, but what's the point here? Are we going to drop python-support
usage ? Will python-central provides
decided to use python-support. The
python modules team already knows it and won't have anything to change
in such packages. The necessary code for dh_python will be back soon.
Well, i'm part of the dpmt and it wasn't really decided to stick with
python-support after/while moving to python 2.4. I've
Josselin Mouette [EMAIL PROTECTED] writes:
In short, the main decision has been to drop entirely python2.x-foo
packages. They will, however, be provided as virtual packages, but only
if something actually needs them.
...
For C extensions, it was decided to build them for all available
On Fri, 12 May 2006, Andreas Barth wrote:
How about, right now, just a statement this is what the issues are.
Or even, this [URL here] is the mailing list post where the issues
are outlined.
I forgot about them. So, I need to collect them again. Even release
managers don't have a
On Wed, 2006-04-12 at 22:58 +0200, Jeroen van Wolffelaar wrote:
zope2.9 is simply still sitting in NEW, and is not rejected. I see there
was a clarification requested over the weekend about the big number of
zope versions in the archive (2.9 would be the 4th), and Fabio replied.
This was two
week for some: nothing problematic. Please go
ahead with the python 2.4 change ASAP.
Unfortunately FTP masters did reject the Zope2.x upload, which uses
python2.4. Any reasons for that? Zope2.7 already was scheduled for
removal.
I'm not ftpmaster so I can't comment, but usually they give a reason
On Wed, Apr 12, 2006 at 04:33:35PM +0200, Matthias Klose wrote:
Jeroen van Wolffelaar writes:
On Wed, Apr 12, 2006 at 12:41:13AM +0200, Jeroen van Wolffelaar wrote:
So, because there were no objections to the python 2.1/2.2 removal,
I'll be proceeding with that.
Done now, I'd like to
Jeroen van Wolffelaar writes:
Unfortunately FTP masters did reject the Zope2.x upload, which uses
python2.4. Any reasons for that? Zope2.7 already was scheduled for
removal.
Can you please be more specific? And/or reply to the REJECT mail, as it
states at the bottom of every reject? That
On Wed, Apr 12, 2006 at 10:32:28PM +0200, Matthias Klose wrote:
Jeroen van Wolffelaar writes:
Unfortunately FTP masters did reject the Zope2.x upload, which uses
python2.4. Any reasons for that? Zope2.7 already was scheduled for
removal.
Can you please be more specific? And/or reply
Matthias Klose wrote:
Jeroen van Wolffelaar writes:
The first freezes are already closing in fast,
did I miss something? There's no update since
http://lists.debian.org/debian-devel-announce/2005/10/msg4.html
Yes. At least the January, 3rd one
On Fri, Apr 07, 2006 at 01:49:52PM +0200, Matthias Klose wrote:
Jeroen van Wolffelaar writes:
The first freezes are already closing in fast,
did I miss something? There's no update since
http://lists.debian.org/debian-devel-announce/2005/10/msg4.html
We're roughly 16 weeks from the
On Wed, Apr 12, 2006 at 12:41:13AM +0200, Jeroen van Wolffelaar wrote:
So, because there were no objections to the python 2.1/2.2 removal,
I'll be proceeding with that.
Done now, I'd like to announce this, together with some warning about
default python version changes, if they're going to
decompyle2.2 has an unsatisfied build-dependency: python2.2-dev
This is a legacy package, and it requires python 2.2 (it will not work
with 2.3 or newer). I have just filed an ftp.d.o bug asking for it to
be removed. Users should have no problem switching to the newer decompyle
package
On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote:
python-pylibacl has an unsatisfied build-dependency: python2.2-dev
python-pyxattr has an unsatisfied build-dependency: python2.2-dev
I've already re-built these two packages, removing 2.1 and 2.2 support
and adding 2.4.
On Fri, Apr 07, 2006 at 01:38:43PM +0200, Iustin Pop wrote:
On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote:
python-pylibacl has an unsatisfied build-dependency: python2.2-dev
python-pyxattr has an unsatisfied build-dependency: python2.2-dev
I've already re-built
On Fri, 07 Apr 2006, Iustin Pop wrote:
On Fri, Apr 07, 2006 at 12:33:11PM +0200, Jeroen van Wolffelaar wrote:
python-pylibacl has an unsatisfied build-dependency: python2.2-dev
python-pyxattr has an unsatisfied build-dependency: python2.2-dev
I've already re-built these two packages,
Jeroen van Wolffelaar writes:
The first freezes are already closing in fast,
did I miss something? There's no update since
http://lists.debian.org/debian-devel-announce/2005/10/msg4.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Fri, Apr 07, 2006 at 01:38:43PM +0200, Iustin Pop wrote:
I've already re-built these two packages, removing 2.1 and 2.2 support
and adding 2.4. However, I've been unable to find a sponsor.
Thanks everyone for the suggestions. Will update the bug reports later
today with the relevant
hi,
i asked a similar question in september :
http://lists.debian.org/debian-python/2005/09/msg4.html
Any news ?
cheers,
Fathi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi Matthias,
What's the status of the Python 2.4 transition? During January you said
you were waiting on feedback from Steve Langasek and Josselin Mouette,
but Steve said he hasn't heard anything from you in a while, and thinks
that the transition outweighs whatever other Python improvements
57 matches
Mail list logo
