please nmu python-orbit
Hello, can someone please nmu python-orbit to comply with the new python policy? The bug is #373331. I'm too buzy, and going on vacation now. If someone want to adopt the package, they are welcome to take it. -- Tom Cato Amundsen [EMAIL PROTECTED] http://www.solfege.org/ GNU Solfege - free ear traininghttp://www.gnu.org/software/solfege/ signature.asc Description: Digital signature
Re: Special i18n policy for python scripts?
On Tue, Oct 21, 2003 at 01:13:30AM +0200, Igor Stroh wrote: Hi all, is there some special policy regarding the placement of i18n stuff (.mo files) for python-enabled programs? I checked various packages, some of them put the file into /usr/share/package/locale, other into /usr/share/locale directly. There are no special policy for python programs about this. I'd place the files in /usr/share/locale where other apps does it. Igor P.S.: btw, is there a reliable way to use distutils to build and install locale stuff appropriately? I haven't. I hate distutils :-) -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
python2.2-dev depends on gcc-3.2. WHY?
Why does python2.2-dev 2.2.1-9 depend on gcc-3.2 ? -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
Re: python bindings for orbit 2
On Wed, 2002-06-19 at 09:52, Roland Mas wrote: Also, this is a pre-RFA: if someone (possibly Tom Cato Amundsen, possibly someone else) wishes to adopt python-orbit, please go ahead. There is currently one reported bug, which has been forwarded to upstream. Unfortunately it seems that said upstream (including myself) is, well, dead. Should someone find a fix for this problem and wish to adopt it, it's fine by me. Just drop me a note. I'd even be glad to sponsor you if you're not an official DD yet. I haven't found a fix for #123848, but I can take the package. I have uploaded a new package to http://klecker.debian.org/~tca/ . Just say GO and I'll get it ready and upload it. From python-orbit-0.3.1-5 rules file: build-stamp: dh_testdir # Add here commands to compile the package. # The package is no longer compiled here. # Look at the install target. # If you wonder why that is, think about it. If you still wonder why # I did it this way and not insert cleverer way here, please contact # me and tell me of your idea. I'd be very happy to hear about it. Check http://klecker.debian.org/~tca/python-orbit2_1.99.0-0.2.diff.gz for my solution ;-) Roland. -- Roland Mas The cherry blossom / Tumbles from the highest tree / One needs more petrol -- in Good Omens (Terry Pratchett and Neil Gaiman) -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
slightly update python-gnome2 and python-gtk2 package
I just uploaded a slightly updated python-gnome2 and python-gtk2 packages to http://klecker.debian.org/~tca . They are apt-get'able using: deb http://klecker.debian.org/~tca unstable main deb-src http://klecker.debian.org/~tca unstable main -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging decompyle - policy question
On Mon, 2001-11-12 at 18:22, Ben Burton wrote: Hi. So I'm packaging decompyle which decompiles a .pyc bytecode file and converts it back to python source. No offense, but when would you need such a tool? I'm not critical to packaging this for debian, just wondering when I would need it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
lintian and new python policy
Has anyone started modifying lintian? If I remember correctly, packages that generate lintian errors will be rejected... At the moment, lines like Depends: python1.5 cause an error, E: python-script-but-no-python-dep Also, someone else reported that lintian complains against Depends: python (= 2.1), python ( 2.2) Should the policy be changed to recommend: Depends: python (= 2.1) Conflicts: python (= 2.2) instead two deps on python? Or is two deps on python not a problem with new dpkg, apt etc? -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/ pgpKI6Ssn8AaT.pgp Description: PGP signature
Re: python-2.1 for unstable?
On 21 May 2001 20:57:34 +0200, Matthias Klose wrote: I really would like to see 2.1 in the next Debian release. I'd like to ask Gregor (the maintainer) for an upload schedule, so that other maintainers can rely on this to get their packages ready for the next release as well. Are there still license issues which will be resolved in upcoming releases? Should we skip 2.1 and hope that 2.2 gets I don't think 2.1 is much better than 2.0 when it comes to GPL compatibility. But the roumurs say that there will be a 2.1.1 release that is fixes this and a few other bugs. I think the new (2.1.1) license was blessed by rms... Sorry, I don't remember where I read this. released upstream before the woody freeze? Thanks, Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Tom Cato Amundsen [EMAIL PROTECTED] GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
