e, only 13 real bugs.
[…]
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
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
* Vincent Bernat , 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 that those
packa
OoO Pendant le journal télévisé du lundi 17 mai 2010, vers 20:01, Jakub
Wilk disait :
> 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
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
moovida-plugins-bad_1.0.9+
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: sq
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 you
On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
>
> on Thu Mar 13 2008, "Steve M. Robbins" 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 respons
on Thu Mar 13 2008, "Steve M. Robbins" 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 the compile
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 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
"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 pac
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 avoidin
"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.
> O
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
on Sat Feb 23 2008, "Steve M. Robbins" wrote:
> 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
On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
>
> on Sat Feb 23 2008, "Steve M. Robbins" wrote:
[...]
> > This produces pairs of library files such as
> >
> > bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
> > bin.v2/.../link-static/python-2.5/libboost_pytho
ld against, no ?)
That's a true statement.
Several 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
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.
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 a s
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
>
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
> > p
Debian likes to package extensions for all python versions, I tend to
> > think it will become a problem.
>
> extensions for different python installations don't conflict because
> they end up in separate directories.
The proposal above is that we provide a boost-python-2.4
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 -dev
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 -dev
> packages that confli
Hi,
Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit :
> One idea is to use a user-config.jam file containing
>
> using python : 2.4 : /usr ;
> using python : 2.5 : /usr ;
>
> Then run jam twice
>
> bjam variant= ...
> bjam
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 v
On Sat, Feb 23, 2008 at 10:45:18PM -0600, Steve M. Robbins wrote:
> The question, then, is how to distinguish them once installed?
> Should we:
[...]
> The drawback to all these approaches is that client code has to be
> adjusted to build on Debian.
Decorate only the shared library names wit
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
P
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.
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 coul
ears. One of the more important uses of this software is for
repairing things in an emergency (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.
may still ask for help.
> 2. It won't 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
f
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.
t's available at http://people.debian.org/~doko/pycentral/, including
python2.3 and python2.4 versions using pycentral, and two example
packages using pycentral. debhelper support is still in the works. My
slides from the the python BoF can be found there as well.
> We agreed to switch
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 on
Ganesan Rajagopal writes:
> > 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
> 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 wit
> 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.
>
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 means that if python-ctypes only supports py
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
> 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 exceptions.
>>
>> Then please suggest how to handle the issues th
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 exceptions.
>
> Then please suggest how to handle the issues that I raised with the new
> policy.
I don't see any issues
> 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 i
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. How about this alternate proposal for binar
> Steve Langasek <[EMAIL PROTECTED]> writes:
>> Hmm, seems a bit backward to me. What if I don't have python2.3 installed at
>> all. What's the point in keeping /usr/lib/python2.3/site-packages/foo.so
>> around?
> Nothing in policy will require that you do this. We discussed specifically
>
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 need
> 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 av
.
Great news.
For python-only modules, it has been 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 decid
On 5/16/06, Josselin Mouette <[EMAIL PROTECTED]> wrote:
Le mardi 16 mai 2006 à 13:48 -0500, Raphael Hertzog a écrit :
> 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.
I'm afraid Matthias hasn
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
Le mardi 16 mai 2006 à 13:48 -0500, Raphael Hertzog a écrit :
> 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.
I'm afraid Matthias hasn't agreed to that. He has agreed to upload
python-defaults v
we going to drop python-support
usage ? Will python-central provides 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
that later, hopefully from
someone else than me...
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 t
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
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 ha
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 tw
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?
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 reje
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,
ys or a full 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 c
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 announce this, together with some warning about
> default pytho
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 hap
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 th
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
(http://lists.debian.org/debian-deve
> 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 instea
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 informa
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, 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,
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-buil
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. How
On Fri, 2006-04-07 at 12:33 +0200, Jeroen van Wolffelaar wrote:
> zopeinterface has an unsatisfied build-dependency: python2.2-dev
This package can be removed, pythonX-zopeinterface are now built
from zope3 source package.
--
Fabio Tranchitella <[EMAIL PROTECTED]>.''`.
P
on2.2
vegastrike has an unsatisfied dependency on arm: python2.2 (>= 2.2.2)
zope-zshell has an unsatisfied dependency on alpha: python2.2
zopeinterface has an unsatisfied build-dependency: python2.2-dev
Furthermore, python 2.4 is out for quite a while now, it entered
unstable in 2004. The first
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]
fault python package only; two of these are the
wx python bindings. The others are python-uno, python-plplot and
python-nautilus. Note that python-qt, python-tk and python-gtk2 are all
available in a 2.4 flavour.
I am sorry if I stepped on toes somewhere here, I was merely asking you
to reconsider you
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 im
76 matches
Mail list logo
