Re: Python versions for Ubuntu 10.10 (Maverick Meerkat)
On Tue, May 18, 2010 at 11:38:23AM -0400, Barry Warsaw wrote: First, let me thank the DPL Stefano Zacchiroli for coming to UDS-M and representing the Debian community. It was really great meeting and having a chance to talk with him. He's encouraged me to apply for DD status and I think I'll take him up on that challenge. :) It's also wonderful to see the commitment he and Ubuntu Community Manager Jono Bacon have made in making our two communities real partners in all this fun and excellent work we're doing. I don't know how many Debian Python people are directly involved with Python upstream, but it would be fantastic to have someone in the intersection of both sets. Thanks. Kumar -- One tree to rule them all, One tree to find them, One tree to bring them all, and to itself bind them. -- Gavin Koch ga...@cygnus.com -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100518155206.gc6...@146653177.ece.utexas.edu
Re: Skip Python 2.6 and use 2.7 as default in Squeeze?
On Tue, Apr 20, 2010 at 02:42:37AM +0200, Cyril Brulebois wrote: Python 2.7 is faster than 2.6 (in my limited tests from a few percents to more than 7 times faster, the latter with a small CPU-intensive math program), it has a few cool new toys, for many years in the future it will be THE Python 2 version (it's the last one) and, most importantly it has several new features to make the transition to Python 3 easier. For any software, new versions always have new shiny features and of course no regressions. Of course, Cyril meant new regressions, I guess. ;-) Including it in Debian now should make many Python programmers happier in the next few years. Including it and making it the default are two different topics. TIA for any feedback to this crazy idea. You named it. :) And, JFTR, I'd go with Cyril's one-step-at-a-time approach, as would most other in the list, I'd guess. But it would be nice to see Python 2.7 in Debian soon. :-) Kumar -- Actually, typing random strings in the Finder does the equivalent of filename completion. -- Discussion on file completion vs. the Mac Finder signature.asc Description: Digital signature
Re: Bug#524176: AM_PATH_PYTHON should honor python's idea about the site directory
Dear Jonathan, On Sat, Mar 27, 2010 at 10:57:01PM +, Jonathan Wiltshire wrote: On Tue, Mar 23, 2010 at 11:34:42PM +0100, Matthias Klose wrote: it is fixed upstream in automake 1.11 (and in Debian), so you could use this version; I doubt that it will allow more binNMUs, as autoconf isn't called during the build for many packages. I don't see automake1.11 in the archive. Can you give me a pointer? Thanks. http://packages.debian.org/source/sid/automake1.11 (I think this is what you want?). HTH. Kumar -- ...you might as well skip the Xmas celebration completely, and instead sit in front of your linux computer playing with the all-new-and-improved linux kernel version. (By Linus Torvalds) signature.asc Description: Digital signature
Re: Requesting review of python-ctypeslib
Dear Richard,
On Tue, Feb 02, 2010 at 12:33:25PM -0500, Richard Darst wrote:
Hello,
I would like to request a review of my new packages python-ctypeslib:
http://hcoop.net/~rkd/debian/python-ctypeslib_0.0.0+svn20100125-1.dsc
or via PMPT:
svn+ssh://svn.debian.org/svn/python-modules/packages/python-ctypeslib/trunk
There are two executables which need manual pages still, otherwise it
is lintian clean.
Since the package is in good condition, I've sponsored the package
without the man pages. As we discussed, you can prepare the man pages
for the next release, which we can make once it clears NEW.
Thanks for the contribution!
Kumar
--
if (argc 1 strcmp(argv[1], -advice) == 0) {
printf(Don't Panic!\n);
exit(42);
}
(Arnold Robbins in the LJ of February '95, describing RCS)
signature.asc
Description: Digital signature
Re: Would like a sponsor to upload the new version of python-foolscap
On Sat, Jan 30, 2010 at 12:15:43AM +1100, Ben Finney wrote: I was under the impression that the ‘#debian-python’ channel was a resource for use equally by anyone for discussion of maintaining Python packages in Debian. When did it become an in-group-versus-out-group club house, with credentials required for entry? Perhaps that should be announced better. #debian-python is very much for general purpose discussion related to Python packages/packaging in Debian, for everyone, whether they are in the DPMT/PAPT or not. However, since the overwhelming majority of people hanging around there are encouraged to / seem to prefer being in those teams, I think the number of people who find the topic useful for sponsorship requests would outnumber the number who would consider such usage inappropriate. Kumar -- Intel engineering seem to have misheard Intel marketing strategy. The phrase was Divide and conquer not Divide and cock up -- Alan Cox, iia...@www.linux.org.uk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PyGTK and Python 2.6
Dear David, (Others: please verify that all I've said below is correct). On Wed, Dec 16, 2009 at 10:56:22PM +, David D Lowe wrote: Epidermis is programmed in Python 2.6. I was surprised to find that Python 2.6 is not included in Debian unstable, but only in the experimental repositories. Unfortunately, Epidermis still doesn't work on Debian. It seems python-gtk2 and other essential packages for Epidermis have not been upgraded to Python 2.6 in any of Debian's repositories. Am I missing something? Can I get import gtk to work under Python 2.6 on Debian? Should I try to port Epidermis back to Python 2.5 or should I wait for Python 2.6 to be fully supported in Debian experimental or unstable? I'm not looking for a definitive answer, (unless there is one!), just advice. Thank you. Your analysis is totally correct. Should you want to use python-gtk2 based programs with Python 2.6, you would have to successively build all of it's reverse dependencies with Python 2.6, and then build python-gtk2 and use these custom built packages for your program. To make it more clear, $ apt-cache depends python-gtk2 [snipped output] Depends: python-cairo Depends: python-gobject Depends: python-numpy So, you would at least need to rebuild the above packages with Python 2.6, and then use these custom built package to allow Epidermis to work. If porting Epidermis to Python 2.5 would be an easier task, it would obviate the need to rebuild the above packages. Please do ask if you have further questions; I'll do my best to help. Kumar -- Writing non-free software is not an ethically legitimate activity, so if people who do this run into trouble, that's good! All businesses based on non-free software ought to fail, and the sooner the better. -- Richard Stallman signature.asc Description: Digital signature
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Tue, Dec 08, 2009 at 09:24:05PM +0100, Loïc Minier wrote: To resurrect the Python Policy as a document reflecting required and recommended Python packaging practices, we prepared a set of patches. We started in private to provide a complete set of changes and avoid flames as much as possible, but now we'd like the whole Debian Python community to send comments, feedback, or additional patches. The goal of this set of patches is only to reflect what's de facto being done in the archive, and update various bit-rotted sections of the Python Policy. It's only a first step, but also a prerequisite for other changes. Hi! From what I can see, the current document seems to codify what seems to be happening already. I've read through the document, and, with my limited understanding of the procedures involved, I would guess that the document is now in sync with the current, albeit unwritten, standards followed in Python packages. Naturally, someone who knows more than me voice their opinions/concerns. I was wondering what the subsequent steps have in store, and what the likely changes you propose would involve. If I'd have to wait and watch, that would be fine. Thank you for working on this. Kumar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for review/sponsorship of python-lzma
On Mon, Nov 23, 2009 at 07:43:59AM -0500, Richard Darst wrote:
I removed the extra non-DEP5 stuff at the top, and tried to tighten it
up to strictly match what it says. There were some quirks, such as
the required Format-Specification field not being present in any
examples... I think that I've interpreted it strictly enough now that
it should be correct. Here is the latest:
http://svn.debian.org/wsvn/python-modules/packages/python-lzma/trunk/debian/copyright
I would guess that the last few lines should be like this:
License: LGPL-3+
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
.
On Debian systems the full text of the GNU Lesser General Public
License can be found in the `/usr/share/common-licenses/LGPL-3'
file.
Anything else I can do to the package?
Other than that, I don't really think there's much to add; I'm just
hoping someone else might suggest what to do about the
${python:Depends} expanding to python (= 2.6) issue; if people can
suggest a workaround, then we can upload it, else we'd have to wait
for Python 2.6 to become the default.
This issue does bring forth a question, though. If a module is
supported on python $current_default_version + 1, but not on
$current_default_version, there currently seems to be no way of
installing it. Is there an elegant way around this, or is it that
we're not really interested in supporting modules which don't work
with the $current_default_version?
Thanks!
Kumar
--
We all know Linux is great... it does infinite loops in 5 seconds.
- Linus Torvalds about the superiority of Linux on the Amsterdam
Linux Symposium
signature.asc
Description: Digital signature
Re: Request for review/sponsorship of python-lzma
On Mon, Nov 23, 2009 at 07:52:19AM -0600, Kumar Appaiah wrote:
Other than that, I don't really think there's much to add; I'm just
hoping someone else might suggest what to do about the
${python:Depends} expanding to python (= 2.6) issue; if people can
suggest a workaround, then we can upload it, else we'd have to wait
for Python 2.6 to become the default.
Josselin was kind enough to point out that this happens only if I use
a chroot which uses Python 2.6 as default, which I was using. If one
doesn't fool around with the default Python settings in experimental,
no problems occur, since I get python (= 2.6) | python2.6 in the
depends line.
Thanks for clarifying.
Kumar
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for review/sponsorship of python-lzma
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
Description: Digital signature
Re: Python 2.6 in unstable
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: importer des modules au démarrage d'IDLE
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.1 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: pythonEnter 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#556148: installs files into /usr/local for Python = 2.6
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-pyt...@l.d.o. 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. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Bug#556148: installs files into /usr/local for Python = 2.6
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 Description: Digital signature
Re: Python 2.6 in unstable
Dear Piotr,
On Sat, Nov 14, 2009 at 01:29:56AM +0100, Piotr Ozarowski wrote:
[Kumar Appaiah, 2009-11-08]
http://tiny.pl/hqwjz
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).
Thanks for doing this.
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. Please remember to use:
User: debian-python@lists.debian.org
Usertags: python2.6 ftbfs
[0] grep-dctrl -n -FBuild-Depends,Build-Depends-Indep python-all -sPackage
Sources
[1] http://people.debian.org/~piotr/python2.6/
I plan to attack these during the next few days, as my free time
permits.
PS if someone wants to prepare NMU for one of python2.6 tagged bugs,
don't wait too long with sending RFS mail to me - Kumar wants to steal
all of them from you again, don't let him! ;-)
Any help is welcome; this is a race we all can win!
Kumar (revving up his python 2.6 chroot for more builds ;-))
--
Kumar Appaiah
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Python 2.6 in unstable
Dear Debian Python, Most of the Python 2.6 transition bugs have been fixed, and the remaining ones are only some leaf packages, as can be seen here: http://tiny.pl/hqwjz 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 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. Thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Python 2.6 transition update
Dear Yaroslav, On Tue, Oct 20, 2009 at 10:01:05PM -0400, Yaroslav Halchenko wrote: Wow... no replies in this imho important thread... Yes, even I was a tad surprised. Thanks for the message. Thanks for starting the roll. Imho numpy/scipy and then any other python- with binary modules and not absent rdepends should be indeed rebuilt with 2.6 and installed in the (ch)root to verify if any other 2.6 package dependent on them not only builds but at least imports. I did that. I rebuilt these packages with python 2.6, and used them in my chroot for the test. numpy.test() works fine using Python 2.6. Module name should be easy to figure out in many cases - for most of them since due to policy's should iirc rule module name should be actual suffix of the python- package name. If it does imports fine I would look for module.test and if present -- run it. That would imho be very valuable information for package maintainers... it might even be worth to setup some temporary repository with builds of the packages with binary extensions (e.g numpy) for 2.6 so that anyone willing to troubleshoot his dependent package for 2.6 compatibility could use prebuilt packages from there instead of manual redoing what you are doing ;-) If needed, I can offer builds of python-numpy (or whatever package) with python 2.6. Unfortunately, I am using a custom python-central as well in my chroot, since python-numpy and python-imaging seem to be affected by bug #547565; some other workarounds might work, I am not sure. In any case, there are only 9 packages remaining with patches, and 4 without patches (of which one has been uploaded and actually supports python 2.6), and one pending upload. I think it's time we uploaded python 2.6 to main, and binNMU the important packages mentioned above and proceed to fix the remaining issues. So, Debian Python, could you please upload python2.6 to unstable? Thanks! Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python 2.6 transition update
On Tue, Oct 20, 2009 at 09:31:30PM -0500, Kumar Appaiah wrote: On Tue, Oct 20, 2009 at 10:01:05PM -0400, Yaroslav Halchenko wrote: Thanks for starting the roll. Imho numpy/scipy and then any other python- with binary modules and not absent rdepends should be indeed rebuilt with 2.6 and installed in the (ch)root to verify if any other 2.6 package dependent on them not only builds but at least imports. I did that. I rebuilt these packages with python 2.6, and used them in my chroot for the test. numpy.test() works fine using Python 2.6. Oh, and just to be sure, the rdepends also were able to import numpy and use it... just in case I wasn't clear. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Python 2.6 transition update
Dear Debian Python, As you may be aware, I have been making quite a bit of hue and cry about the Python 2.6 transition blocking bugs[1]. I have managed to submit patches for most of the packages to _make them build_ with Python 2.6. However, as Paul Wise righly points out[2], my patches merely make the packages build; I haven't really tested any of these packages with Python 2.6 (In fact, I observe that fonttools is dependent on python-numpy, which is not yet built with python 2.6, so I shouldn't have sent that patch at all!). So, in my opinion, it would be best if the maintainer, or someone who can invest time into verifying that these packages do work with Python 2.6, performs uploads to fix the blocking bugs. Thanks! Kumar [1]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org;tag=python2.6 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547821#20 -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
2.6 transition: packages with binary modules?
Dear Debian Python, I was trying to get some of the low hanging fruit in the list of bugs which need to be attacked for the Python 2.6 transition. I ran into some trouble, so was wondering if you could help me out. Some packages, such as python-gnuplot, depend on python-numpy. Since the python-numpy builds are not available for python2.6, do I have to rebuild python-numpy myself, with python2.6, and include it in the chroot where I test out stuff? Or can I be lazy and just wait for the python2.6 upload to unstable, and get the other bugs made RC and then use an updated (possibly binNMUed?) python-numpy to fix further bugs? If my assessment is incorrect, please do point out what I have misunderstood. Otherwise, please advise me on a suitable approach. Thanks! Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Endianness detection change on numpy
Dear Debian Pythoners, Due to a change in the endianness detection in Python, several new problems have started to occur. Initially, it refused to build on several architectures due to the new detection scheme, which failed to handle some CPU cases[0]; this was fixed by forcing it to use endian.h. Now, the reverse dependencies do not build on the same architectures due to the same reason (see #544291[1] for example). The fix is simple: either their new npy_endian.h method is broken, since it does not attempt to find the endian.h present on all Debian machines, or I have not figured out how to force the use of endian.h. A simple workaround I'd suggest is to path the npy_endian.h provided to force the use of endian.h, for that is the most general way and sure to work on all Debian systems. However, before resorting to patching, I wanted know if someone can suggest a more elegant method to get around this problem, which I haven't been able to figure out. Thanks. Kumar [0]. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543538 [1]. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544291 -- Kumar Appaiah signature.asc Description: Digital signature
Re: Getting stuck into apps-team and modules-team
On Thu, Aug 13, 2009 at 03:00:15PM +0100, Jonathan Wiltshire wrote: I've looked at a few packages in the repositories for these teams, but I'm reluctant to start making changes without making sure it's not going to upset anybody :) If I am the sole maintainer/uploader, feel free to make changes and (even) upload my packages. You can also ask me for sponsorship. :-) As for others, you would want to just check with them to be sure, though I doubt that most people would really mind accepting help... Thanks. Kumar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
On Sun, Jan 25, 2009 at 12:53:05AM -0800, Ondrej Certik wrote: Hi, I finally packaged the newest uptream and committed all fixes into our svn repo for numpy. Kumar (or others), do you think you could please test the package? There is a problem with documentation, that it depends on sphinx-0.5, which is currently only in experimental. And also upstream doesn't have it in the tarball. I originally fixed that by adding a new target into debian/rules, that downloaded the upstream tgz, unpacked, eported the doc/ directory from upstream svn and then packaged it again. But since it still doesn't build in pure sid, I rather fixed the build with the current upstream tarball. Thanks Ondrej, and sorry for not helping out with this earlier. I built the package and tested it, and it seems fine; I ran some of my matplotlib+SciPy examples, and they seemed to run all right. numpy.test() also seemed OK. I guess this can be uploaded to experimental with the new Sphinx documentation, as Piotr says. Thanks again. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: numpy 1.2.1, switching to git?
On Mon, Dec 08, 2008 at 06:55:10PM +0100, Ondrej Certik wrote: So if anyone (Kumar?) have time to work on this, it'd be awesome. For others, if you just need the package, apply the patch and it will build. Since you pulled me in, I'll have a look some time next week, unless someone else does it earlier. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-matplotlib_0.98.1-1+lenny3_i386.deb
Confirmed. I have the same error with your script (Yikes!). And, the
error doesn't appear on the unstable version. So, it's time to do some
bug-hunting!
I'll get in touch with the matplotlib maintainers and see where the
mistake could be, if I can't figure it out myself.
For now, I suggest a workaround. Add this to the top of the code, you
can add the following to force TeX use:
rc('text', usetex=True)
Please tell me if this helps. I shall probe further then.
Thanks.
Kumar
--
Kumar Appaiah
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-matplotlib_0.98.1-1+lenny3_i386.deb
On Sat, Nov 08, 2008 at 11:23:54AM -0800, Tom Kuiper wrote:
For now, I suggest a workaround. Add this to the top of the code, you
can add the following to force TeX use:
rc('text', usetex=True)
That works! Thanks you.
Thanks for the quick response, Tom. I always use TeX fonts for the
math stuff, so you might get away this time with using that. But
there's some font conversion issue which I am really unable to figure
out which caused the original problem. Since it works in the sid
matplotlib, due to some change, I guess we have to hunt it. But I've
drawn a blank, since I can't really spot the change which could have
caused this. I can have a closer look later, unless someone else
comes in before me.
Thanks.
Kumar
--
Kumar Appaiah
signature.asc
Description: Digital signature
Re: Debian lenny update : nxutils.so: undefined symbol: __gxx_personality_v0
On Wed, Oct 08, 2008 at 01:46:49PM +0200, Eike Nicklas wrote: On Wed, 8 Oct 2008 12:08:46 +0200 Piotr Ożarowski wrote: [oc-spam66, 2008-10-08 11:55] I went back to the former python-matplotlib package (0.98.1-1) and could import pylab again. So I think there is a problem with python-matplotlib 0.98.1-1+lenny1.1 could you please try unstable one? (0.98.3-3) 0.98.3-3 works fine here (as did 0.98.1-1, but with 0.98.1-1+lenny1.1 I had the same problems as O.C.) I was responsible for the upload of 0.98.1-1+lenny1.1 , and I'll see what the problem is, though it seems to work for me... Thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Debian lenny update : nxutils.so: undefined symbol: __gxx_personality_v0
On Wed, Oct 08, 2008 at 08:33:28AM -0500, Kumar Appaiah wrote: On Wed, Oct 08, 2008 at 01:46:49PM +0200, Eike Nicklas wrote: On Wed, 8 Oct 2008 12:08:46 +0200 Piotr Ożarowski wrote: [oc-spam66, 2008-10-08 11:55] I went back to the former python-matplotlib package (0.98.1-1) and could import pylab again. So I think there is a problem with python-matplotlib 0.98.1-1+lenny1.1 could you please try unstable one? (0.98.3-3) 0.98.3-3 works fine here (as did 0.98.1-1, but with 0.98.1-1+lenny1.1 I had the same problems as O.C.) I was responsible for the upload of 0.98.1-1+lenny1.1 , and I'll see what the problem is, though it seems to work for me... Confirmed. I have no idea what causes this, but I am sure I shouldn't be mucking around with g++ building all files. I'll see what I can do to solve this. Piotr, your help would be appreciated too. Thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Debian lenny update : nxutils.so: undefined symbol: __gxx_personality_v0
On Wed, Oct 08, 2008 at 08:39:15AM -0500, Kumar Appaiah wrote: I was responsible for the upload of 0.98.1-1+lenny1.1 , and I'll see what the problem is, though it seems to work for me... Confirmed. I have no idea what causes this, but I am sure I shouldn't be mucking around with g++ building all files. I'll see what I can do to solve this. Piotr, your help would be appreciated too. OK, so compiling it with gcc resolves the issue. I am now befuddled at what I can do to fix this problem. Here's the diff: Index: debian/rules === --- debian/rules(revision 6644) +++ debian/rules(working copy) @@ -26,7 +26,7 @@ build-stamp-%: dh_testdir - CC=g++ python$* ./setup.py build $(PY_BUILD_FLAGS) + python$* ./setup.py build $(PY_BUILD_FLAGS) touch $@ Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Changes in sys.platform affects some packages?
On Wed, Oct 08, 2008 at 06:18:08PM -0500, Kumar Appaiah wrote: Dear Debian Python, I just discovered (the hard way) that the recent change in Python[1] to display sys.platform on mips, mipsel, alpha, sparc, powerpc and hppa as linux2-mips, linux2-mips, linux2-alpha, linux2-sparc, linux2-powerpc and linux2-hppa respectively may cause several packages in sid and Lenny to FTBFS. For example, see: Actually, that powerpc thing was wrong. It's only mips, mipsel, alpha and sparc. Sorry. http://buildd.debian.org/~jeroen/status/package.php?p=matplotlibsuite=testing While I can fix matplotlib my just editing the build_fix.patch file to add these entries, I wanted an approval that this is what I have to do. Note that this may affect other packages in both sid and Lenny, though I am not sure how many packages are sensitive to sys.platform during their build. Thanks. Kumar [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500383 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499132 -- Kumar Appaiah Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: matplitlib build problems
On Thu, Sep 18, 2008 at 9:42 AM, Cyril Brulebois wrote: Kumar Appaiah [EMAIL PROTECTED] (18/09/2008): Now, this shouldn't really happen, since g++ is supposed to be present during the build, right? Also, note that the g++ package is being installed on arm and ia64, but not on mips and powerpc. At least on ia64 (didn't check the others), looks like broken chroot: | Toolchain package versions: libc6.1-dev_2.7-6 gcc-4.3_4.3.1-9 g++-4.3_ binutils_2.18.1~cvs20080103-7 libstdc++6_4.3.1-9 libstdc++6-4.3-dev_ Note the x_ packages (as opposed to x_y), they are missing. It appears that the chroot is outdated, and this is being fixed. But the problem stems from the fact that the versions of gcc and g++ on these buildds seem mismatched, and the build system tries to build C++ using gcc, which fails. I have reported the problem upstream as well. Thanks. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
matplitlib build problems
Dear Debian Python, I recently uploaded a backported fix for matplotlib to t-p-u. Unfortunately, it failed to build on four architectures, and the errors can be found here: http://buildd.debian.org/~jeroen/status/package.php?p=matplotlibsuite=testing Now, they all end with the cc1plus missing problem, i.e. gcc: error trying to exec 'cc1plus': execvp: No such file or directory Now, this shouldn't really happen, since g++ is supposed to be present during the build, right? Also, note that the g++ package is being installed on arm and ia64, but not on mips and powerpc. I'd appreciate it if someone could please help me understand this problem. Thanks in advance. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
RFS: pkpgcounter
(Cross posted to debian-mentors and debian-python) Dear Debian Mentors, I have packaged pkpgcounter, whose description reads this: Language: Python License: GPL description pkpgcounter is a generic Page Description Language parser which can either count the number of pages or compute the percent of ink coverage needed to print various types of documents. It is written in Python. . It currently recognizes the following file formats : . * PostScript (both DSC compliant and binary) * PDF * PCL3/4/5 * (And some more) . Homepage: http://www.pykota.com/software/pkpgcounter /description I was wondering if someone would be interested in packaging it. It is available at: http://mentors.debian.net/debian/pool/main/p/pkpgcounter/pkpgcounter_2.18-1.dsc It's lintian clean (I guess :-), but if you have suggestions for improving or correcting the package, please do tell me. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: pkpgcounter
On Sat, Jul 28, 2007 at 10:31:16PM +0200, Christoph Haas wrote: Sponsored. Thanks a lot, Christoph! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
RFS: Harvestman web crawler - updated Python Version to current
Dear Debian developers, I have updated the Python version in the HarvestMan web crawler to reflect the transtion of the Python version; instead of 2.4, it is now current, as unstable uses Python 2.4. Please find the package here, and check and upload it when you have the time: http://kumar.travisbsd.org/debpackages/harvestman_1.4.6-4.dsc Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: harvestman web crawler - needs updation!
Piotr Ozarowski ozarow at gmail.com writes: dh_fixperms will do the job Removed. Hmm... I pasted one line too much - config.xml file is installed with dh_installexamples and thus permissions are not changed, please change them manually as you did before (I hope you're not mad at me that I didn't test it further; `find ...|chmod ...` changed permissions in upstream sources as well, and thats why I didn't notice that before, sorry) I remember that I went through all this initially, and that is why I had that line. I'm was not too sure why you asked me to remove it, but didn't realise that it caused this because I forgot that it was needed! I have put it back now. use: find ./debian/harvestman/usr/ -name '*\.py' | xargs sed -i -e '1 s|^#\!.*python.*|#!/usr/bin/$(PYTHON)|' (you used python2.4 again, with $(PYTHON) it will be easier when current python will be greater than 2.4) Ah, missed that! It's OK now. You're now making link to /usr/share/pycentral/..., please use: dh_link -i /usr/lib/$(PYTHON)/site-packages/HarvestMan/harvestman.py /usr/bin/harvestman instead (compiled files will be placed in /usr/lib/...) Done. Please get back to me for corrections. It's not very important, but if I were you, I would remove configure* rules (they're not used) and collapse build-$(PYTHON), build-common and build-common-stamp into build-stamp, same with install-$(PYTHON) / install-prereq Done. One more thing: please bump debhelper version in Build-Depends to 5.0.37.3 (fixed python version in XS-Python-Version parsing issue) Done. Now, I think there aren't too many things that need to be changed. But tell me if anything else is needed, and I shall do the needful. This discussion was fruitful, for two reasons. One is, I cleaned up rules. Two, the new policy takes time getting used to, but solves a lot of the problems with the old way of building Python packages, I feel. Thanks a lot. Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: harvestman web crawler - needs updation!
Piotr Ozarowski ozarow at gmail.com writes: Looks very good to me. As I said before, I'm not a DD so I can't sponsor it. Debian developers, please chip in! If you want, you can also add these 2 lines to long description: . Homepage: http://harvestman.freezope.org/ ^- don't miss this extra space (dev. ref. 6.2.4) Done that as well! With that space! :-) PS Please remember to change XS-Python-Version from 2.4 to current and python-all-dev to python-dev in Build-Depends-Indep after python2.4 will become current (with next upstream version upload, package will work without any changes with python2.4 as current so no need to extra upload) I'll keep that in mind. Thanks. Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: harvestman web crawler - needs updation!
Piotr Ozarowski ozarow at gmail.com writes:
$ lintian --version
Lintian v1.23.22
$ lintian ../harvestman_1.4.6-3.dsc
E: harvestman source: debian-rules-missing-required-target binary-arch
I have added it.
These lines are not needed:
find ./doc |xargs chmod 644
find -name 'config.xml' | xargs chmod 644
dh_fixperms will do the job
Removed.
Line (install-$(PYTHON) rule)
find debian/harvestman -name '*.py[co]' -exec rm -f {} \;
is also not needed, python-central will remove *.py[co] files automatically
(please don't remove the one from clean rule)
Done.
I don't know why, but dh_python didn't set hashbangs correctly (it's not
changing them at all). I will try to investigate it later, for now please use
sed again, sorry.
Done.
* please update DH_COMPAT var. in debian/rules (you still have 4 there):
(I recommend using debian/compat file instead, you will not have to export
DH_COMPAT=5 in order to run dh_* manually without warnings/errors)
Done.
* remove debian/harvestman.links file and use dh_link in debian/rules
(you have hardcoded python2.4 there)
Sorry, missed that! Set it right now.
* dh_installchangelogs, dh_installdocs and dh_installexamples are called
twice, see
install-$(PYTHON) and binary-indep rules
They are now run only once.
BTW: it would be easier (at least for me ;-P) if you could provide direct link
to .dsc file in your mails (I use dget to download all necessary files)
Done.
http://kumar.travisbsd.org/debpackages/harvestman_1.4.6-3.dsc
And many thanks for your patient response. The rules file looks a lot better
now!
Please get back to me for corrections.
Kumar
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: harvestman web crawler - needs updation!
Dear Debian developers, My package, harvestman, has been marked with a severe bug related to the new Python policy. I have made the necessary updation. Please check it out at: http://kumar.travisbsd.org/debpackages (1.4.6-3 is what you should get...) In case there are problems, please let me know, so that I can correct them as necessary. Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Updation of my packages to conform to the new Python policy
Hello Debian Python! I maintain python-goopy and harvestman packages, which (may) need to be updated to conform to the new Python policy. Unfortunately, I won't be back at my Sid machine till August, and I can't do anything about it before that! In any case, I thing goopy will take no tiem to be converted, and it isn't that important either. So, if someone thinks it's worthwhile, please do an NMU. Thank you very much! Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
RFS: python-harvestman - a multithreaded web crawler
(Though I realize that Debian Mentors is the right place to look for sponsors, I thought that it wouldn't be wrong to look for someone having interest on this list. Sorry if this is a mistake.) I'd like you to see HarvestMan (http://harvestman.freezope.org) (ITP bug #352012): Description: quote HarvestMan can be used to download files from websites, according to a number of user-specified rules. The latest version of HarvestMan supports as much as 60 plus customization options. HarvestMan is a console (command-line) application. HarvestMan is the only public-domain, multithreaded web-crawler program written in the Python language. HarvestMan is released under the GNU General Public License. /quote The package is quite small and simple. The current tarball is available at http://download.berlios.de/harvestman/HarvestMan-1.4.6.tar.bz2 ( 100KB) and my diff is at: http://www.ee.iitm.ac.in/~ee03b091/debpkgs/python-harvestman_1.4.6-1.diff.gz and other files are in the same directory http://www.ee.iitm.ac.in/~ee03b091/debpkgs/ The current status is, that I have a source package which generates python2.3-harvestman, python2.4-harvestman and python-harvestman. python-harvestman depends on the 2.3 version and ships with a symbolic link to the executable script present in the site-packages directory. I have also outlined the advantage of using the 2.4 package in README.Debian. I have also spent a LOT of time in writing a man page for the software from the documentation available online in a Word document. Now, the only issue which irks me is that the man page is written using the latest available docs, which is outdated. Though all stuff remains same, the configuration is now an XML file, while the documentation assumes that it is in a plain text file. Though one can adapt to the required settings from the manual, and the software has reverse compatibility, I just wanted to make sure. I have mentioned this in the README.Debian, and suggested ways of getting over this. If any other issues arise, please tell me, so that I can make corrections as appropriate. Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Packaging an application with multiple Python versions.
Dear Debian-Pythoners, I want to package HarvestMan for the near future. From the website: http://harvestman.freezope.org HarvestMan is the only public-domain, multithreaded web-crawler program written in the Python language. HarvestMan is released under the GNU General Public License. Now, I have packages ready: python-harvestman, python2.3-harvestman and python2.4-harvestman. I have not filed an ITP yet, because I would like to get two things clarified. 1.The install script provided in the package adds a symbolic link to the executable script present in /usr/lib/python2.x/site-packages/HarvestMan/harvestman.py in /usr/bin/harvestman. Should I do this in my package? If so, how do I handle the case where the Python 2.3 and 2.4 packages both want to be installed simultaneouly? 2.The Python 2.3 and 2.4 packages do the same thing, but use of Python 2.4 allows the program to function with performance improvement. Do I need to take this into account? Advice the user? Also, I do not think it would be correct to add them as Conflicts, as both can peacefully coexist. Comments on this? Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Packaging an application with multiple Python versions.
On Tue, Feb 07, 2006 at 02:00:40PM +0100, Josselin Mouette wrote: Le mardi 07 f?vrier 2006 ? 18:31 +0530, Kumar Appaiah a ?crit : 1.The install script provided in the package adds a symbolic link to the executable script present in /usr/lib/python2.x/site-packages/HarvestMan/harvestman.py in /usr/bin/harvestman. Should I do this in my package? If so, how do I handle the case where the Python 2.3 and 2.4 packages both want to be installed simultaneouly? Maybe you can simply ship this symbolic link in the python-harvestman package. Thanks for the suggestion, but how do I do this? Do I do this from the rules file itself or do I use preinst/postrm? If it is from the rules, how do I add the ln command the right way? Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Packaging an application with multiple Python versions.
On Tue, Feb 07, 2006 at 02:24:48PM +0100, Josselin Mouette wrote: Le mardi 07 f?vrier 2006 ? 19:03 +0530, Kumar Appaiah a ?crit : Maybe you can simply ship this symbolic link in the python-harvestman package. Thanks for the suggestion, but how do I do this? Do I do this from the rules file itself or do I use preinst/postrm? If it is from the rules, how do I add the ln command the right way? Just add the link in debian/python-harvestman.links, see dh_link(1). Thanks. I guess that settles almost everything. One more thing, do I need to tell the users that quote It is preferred to run HarvestMan with the latest stable release of Python, to get the benefits of all features and for optimal performance. Right now this is Python 2.4.1 /quote like the Readme says? And finally, the documentation is available separately as a (hold your breath) M$ Word document! Now, what do I do with that, given that it is not part of the main package? It is my view that a separate package for it would serve no purpose for a single document. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
