Nabble - debian-python

Re: Request for review/sponsorship of python-lzma

2009-11-21T08:02:23Z

Dear Richard,

On Sat, Nov 21, 2009 at 08:26:00AM -0500, Richard Darst wrote:
> I worked with kmap last night to get my package of python-lzma (in
> DPMT svn) in shape. We think it's good, and he suggested I email here
> for further review and possibly sponsorship (to experimental since it
> depends on 2.6).
>
> If there's anything else I can/should do, please let me know.

We missed the following points:

Luca Falavigna pointed out these issues:

debian/control:
* "Maintainer:" doubled. (I fixed this)

debian/copyright:
* Licensed under LGPLv3+
* Please add license headers too.

debian/rules:
* debhelper >= 7.3.5 has automatic support for building extensions for
every supported Python version, so overriding dh_auto_* should be
omitted.
* Why overriding dh_pysupport?

In addition, I observed that the package, when built, is currently
uninstallable, even with the Python from experimental. The reason is
that ${python:Depends} expands to python (>= 2.6), which is currently
unsatisfiable, as the version of the "python" package in experimental
is 2.5.4-3:

http://packages.debian.org/experimental/python

Others can chip in with more advice; including whether to wait till
Python 2.6 is uploaded to unstable, or whether this can be worked
around.

Thanks.

Kumar
--
Less is more or less more
-- Y_Plentyn on #LinuxGER

signature.asc (853 bytes) Download Attachment

Request for review/sponsorship of python-lzma

2009-11-21T05:26:00Z

Hello,

I worked with kmap last night to get my package of python-lzma (in
DPMT svn) in shape. We think it's good, and he suggested I email here
for further review and possibly sponsorship (to experimental since it
depends on 2.6).

If there's anything else I can/should do, please let me know.

Thank you,

- Richard

--
| Richard Darst - rkd@ - boltzmann: up 123 days, 10:18
| http://rkd.zgib.net - pgp 0xBD356740
| "Ye shall know the truth and -- the truth shall make you free"

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#557293: polybori: FTBFS without Python 2.4

2009-11-20T16:08:48Z

Package: polybori
Version: 0.5~rc1-2
Severity: important
User: debian-python@...
Usertags: python2.6 ftbfs

polybori hardcodes Python version it uses at build time in
python-polybori.install, despite have a build-depends on python-all-dev. This
means that polybori will fail to build 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/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#557288: libkml: manipulates site-packages/ directly, failing with Python 2.6

2009-11-20T15:10:34Z

Package: libkml
Version: 1.0.1-3
Severity: important
User: debian-python@...
Usertags: python2.6 ftbfs

Package fails to build from source with python2.6, here's the build log tail:

| # removes build-time rpaths
| for version in python2.5 python2.4; \
| do \
| chrpath --delete /tmp/buildd/libkml-1.0.1/debian/python-kml/usr/lib/$version/site-packages/*.so ; \
| done
| open: No such file or directory
| elf_open: Invalid argument
| make: *** [binary-install/python-kml] Error 1

(debian-python: caution, this package has large build-dependencies and takes a
very long time to build)

-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

backporting Python 2.6

2009-11-20T05:50:20Z

Hi,

while trying to backport Python 2.6 to Lenny, I discovered that it
conflicts with python-xml, which is required by several other packages
in conjunction with earlier versions of Python.

I don't understand why this module has to conflict, though, but rather
see this conflict as an artifact of our ways to express dependencies in
Debian packages. If one could arrange for this pacakge to not install
into pyshared, things could be fine, right?

TIA!

--
Kind regards,
--Toni++

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Zope 2.12 now requires Python 2.6

2009-11-20T03:44:19Z

Hi,

while I was trying to play with the upcoming Plone 4.0, which is
technically vastly different from earlier releases, I found out that
recent versions, or at least trunk, of Zope 2.12, appears to absolutely
require Python 2.6. Or at least that's the way Andreas Jung, the Zope2
release manager, put it.

I thought that this information should be less hidden than it is right
now...

--
Kind regards,
--Toni++

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Solved] importing modules at IDLE startup

2009-11-18T07:53:21Z

Le lundi 16 novembre 2009 à 16:09 -0800, Mark Voorhies a écrit :

> A good way to test the environment that python/idle is seeing is:
> import os
> os.environ["PYTHONSTARTUP"]
Here are the results:

>>> import os
>>> os.environ["PYTHONSTARTUP"]
'/home/fred/.pythonrc.py'

So for me the variable is correctly initialized at login.

> When you start a bash terminal session (e.g., via gnome-terminal) ~/.bashrc is
> sourced and the resulting environment is passed to any programs started from
> that terminal session. I believe that the environment seen by programs
> launched from the gnome menu is set up through some combination of your login
> manager (e.g., gdm) and Xsession, in a fairly distro dependent way. In my
> hands, this means that I can see my ~/.bashrc environment from python or idle
> launched from a bash shell, but not from the gnome menu.
OK, so in my case it seems that my .bashrc is executed at login and
known by gnome.

> If you don't want to muck around with Xsession config files, and you're
> hacking the idle-python2.5 script anyway, you can modify the environment from
> within the script:
>
> ----------------------------------------------------
> #! /usr/bin/python2.5 -Qnew
> import os
> os.environ["PYTHONSTARTUP"] = "/home/fred/.pythonrc.py"
> from idlelib.PyShell import main
> if __name__ == '__main__':
> main()
> -----------------------------------------------------

OK

So, now my problem is entirely solved under linux. I went into XP to see
if I could analogously solve it. Here are the things I did:

1) I created a C:\Python26\pythonrc.py file containing the two lines
from __future__ import division
from math import *

2) I created an environment variable PYTHONSTARTUP pointing to
pythonrc.py

3) I changed the program associated to .py files so that they are now
associated with the command

C:\Python26\pythonw.exe -Qnew C:\Python26\Lib\idlelib\idle.pyw -n -e -s

4) I created a C:\Python26\pythonw.bat file containing the line

start C:\Python26\pythonw.exe -Qnew C:\Python26\Lib\idlelib\idle.pyw -n
-e -s

5) I added a new link in menu Start-->Programs-->Python26 which points
to the .bat file (I renamed the name of the link and changed its icon)

Note that step 4) and 5) where only to give the user a possibility to
start IDLE "alone", without double-clicking (or right-clicking) on a
file. I'm not sure if there is a simpler way than steps 4)-5).

So globally my problem is solved.

By the way, I also asked myself whether I could also indicate, at IDLE
startup, whitch coding system is to be used, so that students never have
to add the line

# -*- coding: cp1252 -*-

at the top of their script file (on the PCs we have in my high school).
Do you know if I can do this (maybe with the os module)?

Thank's a lot for your precious help!
Gratefully,
Frédéric.

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

RFS: python-slimmer

2009-11-18T07:47:22Z

Dear mentors,

I am looking for a sponsor for my package "python-slimmer".

* Package name : python-slimmer
Version : 0.1.30-1
Upstream Author : Peter Bengtsson <peter@...>
* URL : http://pypi.python.org/pypi/slimmer/
* License : Python Software Foundation License
Section : python

It builds these binary packages:

python-slimmer - HTML, XHTML, CSS, JavaScript optimizer

The package appears to be lintian clean.

The upload would fix these bugs: 556604

My motivation for maintaining this package is: python replace for YUM
CSS, JavaScript optimizer.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/python-slimmer

- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/p/python-slimmer/python-slimmer_0.1.30-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
Janos Guljas

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: PEP 345 - request for comments

2009-11-18T07:46:37Z

On Wed, Nov 18, 2009 at 04:03:32PM +0100, Josselin Mouette wrote:

> Le mercredi 18 novembre 2009 à 10:02 +0100, Wolodja Wentland a écrit :
> > PEP 345 [1] describes version 1.2 of the PKG-INFO file that will be
> > shipped with Python distributions in the future.
>
> > Requires-External: C
> > Requires-External: libpng (>=1.5)
>
> > Would Debian maintainers use this field to extract dependencies of a
> > Python package that have to be handled by the system's package manager?
>
> No, it is clearly not possible to automate such a thing.
>
> You should use pkg-config, possibly extending it with Python fields,
> instead of reinventing the wheel.
>
> > Does the proposed format match your requirements? Are there any changes
> > your would like to see incorporated, so that this field eases your
> > packaging work?
>
> If upstream maintainers update this field correctly, it would ease
> packaging work, but not automate it. With the proposal as is, it is
> strictly similar to making mandatory the documentation of dependencies.

That is indeed how distutils-sig consensus currently sees that field,
at least in my understanding.

Regards
Floris

--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: PEP 345 - request for comments

2009-11-18T07:23:00Z

On Wed, Nov 18, 2009 at 16:03 +0100, Josselin Mouette wrote:
> Le mercredi 18 novembre 2009 à 10:02 +0100, Wolodja Wentland a écrit :
> > PEP 345 [1] describes version 1.2 of the PKG-INFO file that will be
> > shipped with Python distributions in the future.
>
> > Requires-External: C
> > Requires-External: libpng (>=1.5)
>
> > Would Debian maintainers use this field to extract dependencies of a
> > Python package that have to be handled by the system's package manager?

> No, it is clearly not possible to automate such a thing.
> You should use pkg-config, possibly extending it with Python fields,
> instead of reinventing the wheel.

I agree. Automation based on this information is clearly only possible
if the requirements were listed specifically for each Linux distribution
and would use the actual package names used by, for example, Debian.
Even then this field might only serve as a hint to, say dh_make, in the
initial debianisation of the original source archive.

> > Does the proposed format match your requirements? Are there any changes
> > your would like to see incorporated, so that this field eases your
> > packaging work?

> If upstream maintainers update this field correctly, it would ease
> packaging work, but not automate it. With the proposal as is, it is
> strictly similar to making mandatory the documentation of dependencies.

The documentation is not mandatory and I guess that a lot of upstream
authors will not even bother to list these external dependencies. I just
wanted to ask if you actually see any benefit in including this field in
the PEP.

There are a couple of other proposals and PEPs that you might be
interested in. You can find a - incomplete - overview at:

[1] http://wiki.python.org/moin/Distutils/DiscussionOverview

It would be great if you could have a look at the PEPs and proposals and
point out anything that you would like to see changed or included.

thanks a lot!

P.S. I am subscribed to this list, so there is no need to CC me.

--
.''`. Wolodja Wentland <wentland@...>
: :' :
`. `'` 4096R/CAF14EFC
`- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC

signature.asc (853 bytes) Download Attachment

Re: PEP 345 - request for comments

2009-11-18T07:03:32Z

Le mercredi 18 novembre 2009 à 10:02 +0100, Wolodja Wentland a écrit :
> PEP 345 [1] describes version 1.2 of the PKG-INFO file that will be
> shipped with Python distributions in the future.

> Requires-External: C
> Requires-External: libpng (>=1.5)

> Would Debian maintainers use this field to extract dependencies of a
> Python package that have to be handled by the system's package manager?

No, it is clearly not possible to automate such a thing.

You should use pkg-config, possibly extending it with Python fields,
instead of reinventing the wheel.

> Does the proposed format match your requirements? Are there any changes
> your would like to see incorporated, so that this field eases your
> packaging work?

If upstream maintainers update this field correctly, it would ease
packaging work, but not automate it. With the proposal as is, it is
strictly similar to making mandatory the documentation of dependencies.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling

signature.asc (196 bytes) Download Attachment

PEP 345 - request for comments

2009-11-18T01:02:28Z

Dear Maintainers,

PEP 345 [1] describes version 1.2 of the PKG-INFO file that will be
shipped with Python distributions in the future.

Among other fields it also includes a 'Requires-External' field, which
is, as of now, defined like this:

--- snip ---
Each entry contains a string describing some dependency in the system that the
package is to be used. This field is intended to serve as a hint to downstream
package maintainers, and has no semantics which are meaningful to the distutils
package.

The format of a requirement string is a name of an external dependency,
optionally followed by a version declaration within parentheses.

A version declaration is a series of conditional operators and version numbers,
separated by commas. Conditional operators must be one of "<", ">", "<=", ">=",
"==", and "!=". If no operator is provided with a version, the "==" operator is
used by default.

Because they refer to non-Python software releases, version numbers for this
field are not required to conform to the format specified in PEP 386 [3]: they
should correspond to the version scheme used by the external dependency.

Any number of conditional operators can be specified, e.g. the string ">1.0,
!=1.3.4, <2.0" is a legal version declaration.

Notice that there's is no particular rule on the strings to be used.

Examples:

Requires-External: C
Requires-External: libpng (>=1.5)
--- snip ---

Would Debian maintainers use this field to extract dependencies of a
Python package that have to be handled by the system's package manager?

Does the proposed format match your requirements? Are there any changes
your would like to see incorporated, so that this field eases your
packaging work?

There are no plans to normalise entries in this field to a canonical
name by PyPii [2], which basically means that the mapping between the
identifiers used by upstream and Debian's package names has to be
handled by Debian and/or done by the upstream authors.

It would be great if you could provide some comments, suggestions or
criticism on this topic.

kind regards

[1] http://www.python.org/dev/peps/pep-0345/
[2] http://mail.python.org/pipermail/distutils-sig/2009-November/014617.html
--
.''`. Wolodja Wentland <wentland@...>
: :' :
`. `'` 4096R/CAF14EFC
`- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC

signature.asc (853 bytes) Download Attachment

Re: Request to join Python Modules Packaging Team

2009-11-17T13:54:31Z

On Tue, Nov 17, 2009 at 10:50 PM, Piotr Ożarowski <piotr@...> wrote:

> Hi Janos,
>
> [Janos Guljas, 2009-11-17]
>> Thanks to Sandro Tosi, I request to join the Python Modules Team. I am
>> not a DD, but there is one active package (python-django-squeeze) that
>> could be in python-modules repository. I also seek a sponsor for
>> python-slimmer (currently in
>> http://mentors.debian.net/debian/pool/main/p/python-slimmer).
>>
>> My Alioth login name is janos-guest.
>
> I added you to the team, welcome :-)

Thank you. :-)

> --
> Piotr Ożarowski Debian GNU/Linux Developer
> www.ozarowski.pl www.griffith.cc www.debian.org
> GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

--
Janoš Guljaš <janos@...>
WWW: http://www.janos.in.rs
GPG: public key http://www.janos.in.rs/F3E9D498.asc
68EA 9490 579A 1D80 C3AB E50F 9216 C8D5 F3E9 D498

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Request to join Python Modules Packaging Team

2009-11-17T13:50:08Z

Hi Janos,

[Janos Guljas, 2009-11-17]
> Thanks to Sandro Tosi, I request to join the Python Modules Team. I am
> not a DD, but there is one active package (python-django-squeeze) that
> could be in python-modules repository. I also seek a sponsor for
> python-slimmer (currently in
> http://mentors.debian.net/debian/pool/main/p/python-slimmer).
>
> My Alioth login name is janos-guest.

I added you to the team, welcome :-)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

signature.asc (853 bytes) Download Attachment

Request to join Python Modules Packaging Team

2009-11-17T13:39:38Z

Hi,

Thanks to Sandro Tosi, I request to join the Python Modules Team. I am
not a DD, but there is one active package (python-django-squeeze) that
could be in python-modules repository. I also seek a sponsor for
python-slimmer (currently in
http://mentors.debian.net/debian/pool/main/p/python-slimmer).

My Alioth login name is janos-guest.

--
Janoš Guljaš <janos@...>
WWW: http://www.janos.in.rs
GPG: public key http://www.janos.in.rs/F3E9D498.asc
68EA 9490 579A 1D80 C3AB E50F 9216 C8D5 F3E9 D498

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Python 2.6 in unstable

2009-11-17T09:05:51Z

On Sun, Nov 08, 2009 at 03:22:09PM -0600, Kumar Appaiah wrote:
> With the last upload of python-central, only a few issues with
> python-central remain, before python 2.6 can be uploaded to unstable,
> as has been outlined by Piotr here:
>
> http://lists.debian.org/debian-python/2009/11/msg00014.html

I think the last maintainer upload undid these, causing more
problems:

http://lists.debian.org/debian-python/2009/11/msg00070.html

> Given this, could you please let me know when Python 2.6 can be
> uploaded to unstable? I'd really like to see it in unstable quickly,
> so that we have enough time for testing all Python applications and
> modules, and handle bug reports and troubles with a lot of time to
> spare. I fear that delaying the upload to close to the freeze might
> not provide sufficient time for testing.

Are there any hopes of getting a date for this? November is going to
end soon, and that leaves only 4 months to the freeze. I really don't
see the need to find a more auspicous time[1] for uploading Python 2.6
to unstable, but could we have your reasoning/schedule on when the
uupload is going to happen, please?

Thanks.

Kumar

[1]: http://en.wikipedia.org/wiki/Muhurta

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: importing modules at IDLE startup

2009-11-16T16:09:54Z

On Monday 16 November 2009 2:27 pm Frederic Baldit wrote:

> Le lundi 16 novembre 2009 à 13:15 -0800, Mark Voorhies a écrit :
>
> > One such hackish solution is to use a modified version
> > of /usr/bin/idle-python2.5 that invokes the python interpreter with "new"
> > division, e.g.:
> > ------------------------------------
> > #!/usr/bin/python2.5 -Qnew
> >
> > from idlelib.PyShell import main
> > if __name__ == '__main__':
> > main()
> > --------------------------------------
> > idlelib.PyShell.main will parse command line arguments, so invoking

with -s
> > will still see your PYTHONSTARTUP script.
> OK, now I have the "new" division active, both when starting idle
> through the command line and with gnome menu! Unfortunately, when
> starting idle with gnome menu, I cannot use sqrt(2) (but it works when
> runing idle in a command line with -s option). I hardly believe that
> PYTHONSTARTUP is not set up, because according to env PYTHONSTARTUP is
> set to /home/fred/.pythonrc.py.

A good way to test the environment that python/idle is seeing is:
import os
os.environ["PYTHONSTARTUP"]

> I tried to create an .xsession file in
> my home (after reading the link you gave), but had to remove it because
> X could not start.
>
> I really don't understand this difference between running idle-python2.5
> through command line (which works) and through gnome menu.

When you start a bash terminal session (e.g., via gnome-terminal) ~/.bashrc is
sourced and the resulting environment is passed to any programs started from
that terminal session. I believe that the environment seen by programs
launched from the gnome menu is set up through some combination of your login
manager (e.g., gdm) and Xsession, in a fairly distro dependent way. In my
hands, this means that I can see my ~/.bashrc environment from python or idle
launched from a bash shell, but not from the gnome menu.

> Fixing this
> would definitively solve my problem... I still try to fix this point.

If you don't want to muck around with Xsession config files, and you're
hacking the idle-python2.5 script anyway, you can modify the environment from
within the script:

----------------------------------------------------
#! /usr/bin/python2.5 -Qnew
import os
os.environ["PYTHONSTARTUP"] = "/home/fred/.pythonrc.py"
from idlelib.PyShell import main
if __name__ == '__main__':
main()
-----------------------------------------------------

--Mark

>
> Thank you very much for your help. I fully understand that it is best to
> teach students setting up the environment at the beginning of their
> script, but here my goal is really not to teach programming, only the
> first steps in a introductory (and very basic) course on algorithmic.
>
> Frédéric.
>

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: python-central NMU (python2.6 related)

2009-11-16T15:23:50Z

[Matthias Klose, 2009-11-16]
> Fyi, I replaced your NMU with my merge from Ubuntu, which already had
> these changes. I may have missed the "indentation problems", please
> file separate bug reports for these.

Indentation problems and typos were so obvious that I know now that you
didn't even read my debdiff. The most important change (srctop related)
is gone as well.

/me wasted lots of time testing these few lines :-(
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

signature.asc (853 bytes) Download Attachment

importing modules at IDLE startup

2009-11-16T14:27:29Z

Le lundi 16 novembre 2009 à 13:15 -0800, Mark Voorhies a écrit :

> One such hackish solution is to use a modified version
> of /usr/bin/idle-python2.5 that invokes the python interpreter with "new"
> division, e.g.:
> ------------------------------------
> #!/usr/bin/python2.5 -Qnew
>
> from idlelib.PyShell import main
> if __name__ == '__main__':
> main()
> --------------------------------------
> idlelib.PyShell.main will parse command line arguments, so invoking with -s
> will still see your PYTHONSTARTUP script.

OK, now I have the "new" division active, both when starting idle
through the command line and with gnome menu! Unfortunately, when
starting idle with gnome menu, I cannot use sqrt(2) (but it works when
runing idle in a command line with -s option). I hardly believe that
PYTHONSTARTUP is not set up, because according to env PYTHONSTARTUP is
set to /home/fred/.pythonrc.py. I tried to create an .xsession file in
my home (after reading the link you gave), but had to remove it because
X could not start.

I really don't understand this difference between running idle-python2.5
through command line (which works) and through gnome menu. Fixing this
would definitively solve my problem... I still try to fix this point.

Thank you very much for your help. I fully understand that it is best to
teach students setting up the environment at the beginning of their
script, but here my goal is really not to teach programming, only the
first steps in a introductory (and very basic) course on algorithmic.

Frédéric.

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

mercurial: python-docutils builddep should? be (>= 0.5)

2009-11-16T14:26:46Z

Mercurial 1.4 adds a builddep on python-docutils, which has been added
in PAPT svn. Owing to the use of --strip-elements-with-class, this
actually requires >= 0.5.

Given that 0.5 is already present in all but oldstable, I'm not sure
whether the builddep _should_ be changed, but I would imagine
backporters would thank you if you did give it an accurate version.

Max.

signature.asc (204 bytes) Download Attachment

PING: mercurial: Fixing quilt dependency

2009-11-16T14:17:38Z

[I posted this a few months ago, but no one responded. Reposting.]

Hi Vincent (and others),

Regarding your change to the mercurial packaging:

+mercurial (1.3.1-2) UNRELEASED; urgency=low
+
+ * adjust quilt dependency so that it works with backports
+ (ie quilt >> 0.46-6 instead of quilt >= 0.46-7)
+
+ -- Vincent Danjean <vdanjean@...> Tue, 18 Aug 2009 12:44:51 +0200
+

It is better to use quilt (>= 0.46-7~) for this sort of thing - quilt
(>> 0.46-6) is too loose.

Using the ~-suffixed form will allow backports, whilst avoiding being
satisfied by versions looking like 0.46-6rebuild1, which would be wrong.
It more clearly communicates the actual important version too.

Max.

signature.asc (204 bytes) Download Attachment

Re: python-central NMU (python2.6 related)

2009-11-16T13:49:09Z

[Matthias Klose, 2009-11-16]
> Fyi, I replaced your NMU with my merge from Ubuntu, which already had
> these changes. I may have missed the "indentation problems", please
> file separate bug reports for these.

srctop related lines were broken in Ubuntu, if you used Luca's merge
then it's fine, though (he even ported my changes in -dbg hack)

Did you upload new version somewhere?
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

signature.asc (853 bytes) Download Attachment

Re: importer des modules au démarrage d'IDLE

2009-11-16T13:15:07Z

On Monday 16 November 2009 9:15 am Kumar Appaiah wrote:

> > idle-python2.5 -n -s test.py
> >
> > et que j'exécute avec F5 je n'ai pas d'erreur mais la division n'est pas
> > flottante:
> >
> > IDLE 1.2.2 ==== No Subprocess ====
> > >>>
> > >>>
> > 1.41421356237
> > 0
>
> I would guess the same thing would happen even in this case. The
> reason why this is NOT possible in Python is because if you effect
> such changes, the moment the script is run on another machine, it'll
> break. So, other than a hackish solution which someone could suggest,
> I can't think of a way to achieve this effect (elegantly).

One such hackish solution is to use a modified version
of /usr/bin/idle-python2.5 that invokes the python interpreter with "new"
division, e.g.:
------------------------------------
#!/usr/bin/python2.5 -Qnew

from idlelib.PyShell import main
if __name__ == '__main__':
main()
-------------------------------------
idlelib.PyShell.main will parse command line arguments, so invoking with -s
will still see your PYTHONSTARTUP script.

To have PYTHONSTARTUP set correctly in Gnome on Lenny, I think you need to
edit ~/.xsession rather than ~/.bashrc, c.f.:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=242507
(I don't have a desktop copy of Lenny, so I can't verify directly).

I do agree with Kumar that it might be best to teach students to do set up the
environment themselves at the top of their scripts.

--Mark

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: python-central NMU (python2.6 related)

2009-11-16T12:50:19Z

Fyi, I replaced your NMU with my merge from Ubuntu, which already had these
changes. I may have missed the "indentation problems", please file separate bug
reports for these.

Matthias

On 03.11.2009 16:07, Piotr Ożarowski wrote:

> Hi Matthias,
>
> You uploaded new python-central package that fixed one indentation error
> in pycentral.py (which is ok, this bug had Severity=important in BTS).
> Since my NMU of python-central was still waiting in DELAYED (queue was
> disabled by ftpmasters) at that time, it didn't make it into unstable.
> Please let me know if it was just a coincidence and I can upload my
> changes again (I assume that if you would want to reject it, you'd add a
> comment over a month ago when I sent you my patch or you'd upload a new
> version before Thursday, when my 0.6.11+nmu1 was supposed to be uploaded
> to unstable). If it's ok with you, I'll upload my changes again this
> Thursday.
>
> Please note that when python-central will be fixed, we will be almost
> ready for your upload of python2.6 to unstable - the only remaining
> changes will be python-central based packages that do not define
> XB-Python-Version - let me know if you want me to change python-central
> to detect such packages and fix it in pycentral instead - I'll send you
> a patch.

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: importing modules at IDLE strartup

2009-11-16T11:15:20Z

Hi,
first of all sorry for writing my first post in french. Hereafter is the
english version of my text:

I'm using python (version 2.5.2, under debian lenny for personnal use on
my notebook, and version 2.6 under Windows XP with my students) for
teaching an introduction to algorithmic at High School (in France). I'm
also using IDLE as IDE.
Here is my problem (I try to solve it under linux fisrt):

1) I wrote a .pythonrc.py file with the two lines

from __future__ import division
from math import *

2) in my .bashrc file I wrote

PYTHONSTARTUP = "/home/fred/.pythonrc.py"
export PYTHONSTARTUP

3) when invoking python interactively in a terminal, it works fine:

>>> 1/3
0.33333333333333331
>>> sqrt(5)
2.2360679774997898

4) I wrote a small script file test.py which contains

print sqrt(2)
print 1/3

Editing/testing this file with IDLE with the following command line:

idle-python2.5 -n -s test.py

and executing it with F5 gives the lines

IDLE 1.2.2 ==== No Subprocess ====
>>>
>>>
1.41421356237
0

So I have here a first problem with 1/3 division that should give a
float result (according to the startup file import from __future__).

5) More annoying yet, when launching IDLE through the menu (under
gnome), even the sqrt(2) command is not accepted (NameError: name 'sqrt'
is not defined). I have checked that IDLE is launched with the
command /usr/bin/idle-python2.5 -n -s

Does anyone know how to solve this ? (of course I know that I could
write 1.0/3, or also I could migrate to python 3). I simply want to
"simplify" the python syntax for my students, so that "/" operator is
always for them the usual (float) division, and usual math functions are
available, this WITHOUT having to write any import at the top of their
script. I also know that such scripts could easily be broken when
changing the environment. This is not indeed a problem for me, since I'm
not here teaching how to produce good programs.

Thank's in advance for any valuable help.
Frederic.

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: importer des modules au démarrage d'IDLE

2009-11-16T09:15:28Z

Hi! This is an English list, so please frame your queries in
English. But since I could translate your query, I'll try to answer
below, please translate if needed.

On Mon, Nov 16, 2009 at 05:43:09PM +0100, Frederic Baldit wrote:

> je travaille sous lenny et gnome avec python 2.5.2 et IDLE, que
> j'utilise pour une introduction à l'algorithmique au lycée (en maths).
> Voilà mon problème:
>
> 1) J'ai créé un fichier .pythonrc.py file contenant les deux lignes
>
> from __future__ import division
> from math import *
>
> 2) Dans mon .bashrc j'ai rajouté
>
> PYTHONSTARTUP = "/home/fred/.pythonrc.py"
> export PYTHONSTARTUP
>
> 3) Quand je lance python de façon interactive dans une console tout va
> bien:
>
> >>> 1/3
> 0.33333333333333331
> >>> sqrt(5)
> 2.2360679774997898
>
> 4) J'ai écrit un petit script test.py qui contient
>
> print sqrt(2)
> print 1/3
>
> Quand j'édite/teste ce script avec IDLE en lancant IDLE en ligne de
> commande par

Sadly, python --help says this:

PYTHONSTARTUP: file executed on interactive startup (no default)

So, this implies that the file is executed ONLY if Python is started
interactively as:

python<Enter>

rather than Python <scriptname>

> idle-python2.5 -n -s test.py
>
> et que j'exécute avec F5 je n'ai pas d'erreur mais la division n'est pas
> flottante:
>
> IDLE 1.2.2 ==== No Subprocess ====
> >>>
> >>>
> 1.41421356237
> 0

I would guess the same thing would happen even in this case. The
reason why this is NOT possible in Python is because if you effect
such changes, the moment the script is run on another machine, it'll
break. So, other than a hackish solution which someone could suggest,
I can't think of a way to achieve this effect (elegantly).

> 5) Plus embêtant, si je lance IDLE par la souris en utilisant le menu
> gnome Applications-->Programmation-->IDLE, puis que j'ouvre mon fichier
> test.py et que je l'exécute (F5) j'ai une erreur avec sqrt(2) qui n'est
> pas connu (NameError: name 'sqrt'is not defined). Pourtant j'ai vérifié
> (Système-->Préférences-->Menu Principal) que l'application est lancée
> par la commande /usr/bin/idle-python2.5 -n -s qui devrait donc exécuter
> mon fichier de démarrage.
>
> Quelqu'un peut-il m'aider?? Je sais que je pourrais (pour la division)
> faire 1./3, ou passer à la version 3. Mais de toute façon je veux aussi
> une solution permettant d'avoir par défaut accès aux fonctions
> mathématiques usuelles, sans que les élèves aient à écrire la ligne from
> math import * en tête de leur script.

Someone else might have better suggestions, but when I asked a Python
expert, I was told NOT to do this; the students should write the
import lines at the top; consider it something akin to including
headers in C programs! (Yes, I know I am not giving useful
suggestions, but just trying to explain why this "feature" isn't
really present in Python.).

Sorry for not being much help.

Kumar

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

importer des modules au démarrage d'IDLE

2009-11-16T08:43:09Z

Bonjour,
je travaille sous lenny et gnome avec python 2.5.2 et IDLE, que
j'utilise pour une introduction à l'algorithmique au lycée (en maths).
Voilà mon problème:

1) J'ai créé un fichier .pythonrc.py file contenant les deux lignes

from __future__ import division
from math import *

2) Dans mon .bashrc j'ai rajouté

PYTHONSTARTUP = "/home/fred/.pythonrc.py"
export PYTHONSTARTUP

3) Quand je lance python de façon interactive dans une console tout va
bien:

>>> 1/3
0.33333333333333331
>>> sqrt(5)
2.2360679774997898

4) J'ai écrit un petit script test.py qui contient

print sqrt(2)
print 1/3

Quand j'édite/teste ce script avec IDLE en lancant IDLE en ligne de
commande par

idle-python2.5 -n -s test.py

et que j'exécute avec F5 je n'ai pas d'erreur mais la division n'est pas
flottante:

IDLE 1.2.2 ==== No Subprocess ====
>>>
>>>
1.41421356237
0

5) Plus embêtant, si je lance IDLE par la souris en utilisant le menu
gnome Applications-->Programmation-->IDLE, puis que j'ouvre mon fichier
test.py et que je l'exécute (F5) j'ai une erreur avec sqrt(2) qui n'est
pas connu (NameError: name 'sqrt'is not defined). Pourtant j'ai vérifié
(Système-->Préférences-->Menu Principal) que l'application est lancée
par la commande /usr/bin/idle-python2.5 -n -s qui devrait donc exécuter
mon fichier de démarrage.

Quelqu'un peut-il m'aider?? Je sais que je pourrais (pour la division)
faire 1./3, ou passer à la version 3. Mais de toute façon je veux aussi
une solution permettant d'avoir par défaut accès aux fonctions
mathématiques usuelles, sans que les élèves aient à écrire la ligne from
math import * en tête de leur script.

Merci d'avance pour toute aide.
Cordialement,
Frédéric.

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Python 2.6 in unstable [symeig: resolved]

2009-11-16T06:48:53Z

On Sat, 14 Nov 2009, Jakub Wilk wrote:
> 3) These packages failed likely because one of build-deps didn't
> support python2.6:
> ... symeig

symeig functionality was absorbed into scipy.

Thanks to the kind reminder/pointer made by upstream (Tiziano Zito) I've
just uploaded -2 revision of symeig which has nothing in binary packages
besides NEWS and description adjustments to point to this fact, so
anyone using it (do not see explicit Depends/Recommends within Debian
packages, mdp was adjusted long ago).

So you can consider 'symeig' python-2.6 issue resolved ;)

Thanks!
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Request to join PMPT and add python-lzma

2009-11-16T06:48:42Z

Hello,

I'd like to join the DPMT. My alioth username is mrbeige-guest.

This is in response to #556451, an ITP I just filed for python-lzma
(https://launchpad.net/pyliblzma). Thanks to the help of Kumar
Appaiah, Clint Adams, and others in #debian-nyc, I have a package
ready here:
http://rkd.zgib.net/debian/

They've gone over it fairly thoroughly, but please let me know any
other comments on the package. I'd like to add this to group
maintenance, with maintainer set to DPMT (but I will still take
responsibility for keeping it up to date).

I know, at the least, that the copyright file needs the special form
added.

Thank you,

- Richard

--
| Richard Darst - rkd@ - boltzmann: up 118 days, 11:22
| http://rkd.zgib.net - pgp 0xBD356740
| "Ye shall know the truth and -- the truth shall make you free"

signature.asc (852 bytes) Download Attachment

Distutils-SIG - Comments and ideas on current PEP drafts

2009-11-16T05:05:44Z

Dear Debian Python maintainers,

the distutils SIG is currently working on a number of PEPs that will
determine how Python distributions will be packaged in the future. One
goal of the PEPs is to make the life of linux distribution package
maintainers a little easier. :-)

Have a look at [1] where you can find an overview of the PEP drafts that
are related to Python packaging and some proposals that are currently
under consideration. The page is pretty new and incomplete, but you are
welcome to add whatever proposal/idea you have.

Most of the proposals right now are related to the way data files will
be installed and handled once the PEPs are accepted and implemented.

It would be great if you could:

* Review the PEPs and proposals and provide comments

* Describe use cases or ideas that you would like to see implemented in
distutils/Distribute

Especially problems you have in your daily work with
distutils/distribute/setuptools packaged distributions are of
interest and now is the time to voice a proposal on how to handle this
in the future.

Essentially: What has to change to make your packaging experience an
even better one?

[1] http://wiki.python.org/moin/Distutils/DiscussionOverview
--
.''`. Wolodja Wentland <wentland@...>
: :' :
`. `'` 4096R/CAF14EFC
`- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC

signature.asc (853 bytes) Download Attachment

Bug#556364: pycxx: FTBFS with Python 2.6

2009-11-15T06:34:11Z

Package: pycxx
Version: 5.5.0-1
Severity: important
User: debian-python@...
Usertags: python2.6 ftbfs

pycxx fails to build from source with python2.6, with this log:

| Writing /tmp/buildd/pycxx-5.5.0/debian/python-cxx/usr/local/lib/python2.6/dist-packages/CXX-5.3.egg-info
| find debian/python-cxx -name '*.egg-info' | xargs -r rm -f
| mkdir -p debian/python-cxx-dev/usr/share/
| mv debian/python-cxx/usr/share/python2.6 \
| debian/python-cxx-dev/usr/share/
| mkdir -p debian/python-cxx-dev/usr/include
| mv debian/python-cxx/usr/include/python2.6 debian/python-cxx-dev/usr/include/
| mv: cannot stat `debian/python-cxx/usr/include/python2.6': No such file or directory
| make: *** [install-python2.6] Error 1

-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Python 2.6 in unstable

2009-11-15T00:11:32Z

2009/11/14 Jakub Wilk <ubanus@...>:

> * Piotr Ożarowski <piotr@...>, 2009-11-14, 01:29:
>>
>> After rebuilding most packages that build depend on
>> python-all{,-dev,-dbg}[0], I reported few more bugs. Packages that
>> didn't FTBFS but ship files in /usr/local are now listed on that page as
>> well (with "usr-local" usertag).
>>
>> If someone wants to help with checking build logs and reporting bugs,
>> please download failed.tar.xz from [1] and file bugs for packages
>> not listed on tiny.pl/hqwjz yet.
>
> I've triaged most of these build failures.
>
> 1) These packages fail in sid, too:
>
> clientcookie dynagen euca2ools pyspi python-bibtex python-clientform
> python-dmidecode python-mechanize qtiplot wxwidgets2.8
>
> Bugs are already filed. (Maybe we should usertag them python2.6 anyway?)
>
> 2) These packages failed because of (temporarily?) broken build-deps:
>
> gnuradio libkate petsc4py pycg python-kde3 subversion
>
> 3) These packages failed likely because one of build-deps didn't support
> python2.6:
>
> babel jppy pyexiv2 pymvpa pysparse python-biopython python-edje
> python-qt4 renpy tagpy creoleparser kaa-imlib2 pygtk pynifti pysvn
> python-chaco python-enable python-scipy revelation twisted-calendarserver
> freej kaa-metadata pyicu pyqwt3d pytables python-djvulibre python-evas
> pyvorbis swftools html5lib necpp pykaraoke pyqwt5 pytagsfs python-ecore
> python-qt3 qscintilla2 symeig
>
> 4) These are probably real python2.6-related failures:
>
> 4.1) These packages seems to hardcode a Python version somewhere:
>
> boost1.38 boost1.39 boost1.40 distribute libkml polybori pykcs11
> python-bsddb3 python-multiprocessing python-stdlib-extensions

pykcs11: fixed in 1.2.1-3 I just uploaded to unstable.

Bye

--
Dr. Ludovic Rousseau

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Python 2.6 in unstable

2009-11-14T13:51:29Z

2009/11/14 Jakub Wilk <ubanus@...>:

Re: Bug#556148: installs files into /usr/local for Python >= 2.6

2009-11-14T11:44:39Z

On Sat, Nov 14, 2009 at 01:21:30PM -0600, Dirk Eddelbuettel wrote:
> | I have sent a patch, which should work. I've tested it in my chroot,
> | and it does seem to work; others can verify and let you know.
>
> Two words: You rock!

Thanks; just do my best! :-)

> The bug repotr only went to -submitter, so I never saw it. The result set
> (three files in /usr/bin) looks good and is what we had before the 2.6
> transition.

I think I'll restart sending to the bug report as well; I was told by
Piotr that mailing -submitter should send a copy to you as well...

> I will apply your patch and upload. Many thanks!

Sounds perfect. Thanks!

Kumar
--
Kumar Appaiah

signature.asc (853 bytes) Download Attachment

Re: Bug#556148: installs files into /usr/local for Python >= 2.6

2009-11-14T11:21:30Z

On 14 November 2009 at 12:57, Kumar Appaiah wrote:
| On Sat, Nov 14, 2009 at 11:25:02AM -0600, Dirk Eddelbuettel wrote:
| > I am swamped.
| >
| > I will not be able to get it soon.
| >
| > You guys have working 'experimental' pbuilders.
| >
| > Can you help?
| >
| > as the original bug report suggested that I may want to ask for help on
| > debian-python@....
| >
| > So, with that out of the way:
| >
| > I anybody able to quickly review and test this with me?
| >
| > I am available via email/irc/chat/... if I get a heads up and get work
| > with one of you guys on this, but I may not be able to foreground this task
| > otherwise for a little as I have travel and a presentation coming up.
|
| I have sent a patch, which should work. I've tested it in my chroot,
| and it does seem to work; others can verify and let you know.

Two words: You rock!

The bug repotr only went to -submitter, so I never saw it. The result set
(three files in /usr/bin) looks good and is what we had before the 2.6
transition.

I will apply your patch and upload. Many thanks!

Dirk

--
Three out of two people have difficulties with fractions.

--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...