Examples of making *.pyc files in postinst
Hello! I'm looking for an example of how to correctly make and remove *.pyc and/or *.pyo files in postinst and prerm. There's a large thread about it in November, but the most practical advice says: "That is why most of us prefer to follow Gregor Hoffleit's method (see postinst and prerm samples in /usr/share/doc/python-base) i.e py are compiled at postinst time and revoed at prerm time." I can't find these examples anywhere! They aren't in that directory, in any package in the Debian archive. Thanks for your help, Francis (packaging pygame) -- Home: [EMAIL PROTECTED] Web: www.flourish.org
Re: Examples of making *.pyc files in postinst
On Wed, Jan 24, 2001 at 09:34:58AM +0100, [EMAIL PROTECTED] wrote: > On Tue, Jan 23, 2001 at 11:27:47PM +0000, Francis Irving wrote: > > I can't find these examples anywhere! They aren't in that directory, > > in any package in the Debian archive. > Look in /var/lib/dpkg/info/python-base.postinst. > The 'locate' command can scan for files. Great, that's what I needed. I also had a look at the one for gadfly, which was simpler. compileall.py rules! Francis -- Home: [EMAIL PROTECTED] Web: www.flourish.org
Re: debian-python: cvs module & cvs libraries.
On Wed, Jan 24, 2001 at 06:22:51PM +1100, Brendan J Simon wrote: > I am writing a cross-platform cvs gui client using wxPython (a python > module to the wxWindows cross platform GUI framework). I would like to > use a cvs python module to implement the core cvs functionality but I > can't find one (is there any out there ???). Bizarre ;-) I've written and maintain a CVS gui client written using wxWindows (TortoiseCVS, it is a Windows Explorer plugin). I think I might have seen you on the wxWindows mailing list. > I am willing to write such a module (need to learn how) but I would like > to base this on a cvs library. I was hoping debian's cvs was split into > the cvs command line client and a cvs shared library (libcvs.so) but > this is not the case. I think there is a case for having a cvs shared > (and static) library so that other cvs clients can use the common > functionality. How would I go about requesting such a thing for Debian > ?? I know that WinCvs (MSW), gCvs (gtk) and macCvs (Macintosh), all > written by the same author, uses some kind of cvs library but it is > statically linked into each application. Yes! A libcvs would be excellent. There are increasingly many GUI CVS clients, and it would make a lot of sense for them to share a library. I guess people integrate Python with CVS at the moment by launching the command line client with a pipe. WinCVS et al don't really use a clean library. They have custom code to parse CVS/Entries to decide how to render local files, and they have a DLL which is just the CVS command line client compiled with a special interface. A libcvs would need to: - Have functions to extract all information from the local file system about CVS without going to the server. e.g. Is this file modified? Can you find all files recursively - Allow access to the server in various ways. Ideally it would call the server and parse the requests into useful programmatic data structures. e.g. "cvs status" would return structs for each file of the status. I'd be very impressed to see a libcvs which moved away from the command line client which overwhelms the existing GUI interfaces. I think that would be a hard and large project though. It might be better just to expose the command line client in libcvs, with some of the local filesystem scanning, and the parsing described above. Anyway, this is getting off topic for Python... You can email me if you like, or perhaps [EMAIL PROTECTED], or a CVS mailing list. Francis -- Home: [EMAIL PROTECTED] Web: www.flourish.org
Re: Python 2.x and GPL (official blurb form 2.1a1)
On Fri, Jan 26, 2001 at 10:58:13AM +1100, Peter Eckersley wrote:
> On Wed, Jan 24, 2001 at 11:01:17PM +0100, [EMAIL PROTECTED] wrote:
> > So it seems that 2.1 will be GPL compatible :)
>
> Alas, not for certain ("We will also attempt to get the ownership
> in previous versions transfered"). Unless CNRI and BeOpen.com play
> ball, there will still be slabs of non-GPL compatible code (all the
> changes from 1.5.2 -> 2.0) in Python :(
Tangentially related question: Am I correct in thinking that the current
Python 2 in the Debian archive is LGPL (Lesser GPL) compatible?
Pygame, which I am packaging, is licensed with LGPL, and I want to be sure
that it would be allowed in the Debian archive.
Francis
--
Home: [EMAIL PROTECTED] Web: www.flourish.org
Sponsor for pygame
I've packaged pygame, a set of SDL multimedia/games bindings for Python, and I am looking for a sponsor to upload it to the Debian archive. The ITP is bug #83446. The license is LGPL (not GPL), so the issues mentioned in the bug report don't apply. Description: SDL bindings for games development in Python A multimedia development kit for Python. Pygame provides modules for you to access the video display, play sounds, track time, read the mouse and joystick, control the CD player, render true type fonts and more. It does this using mainly the cross-platform SDL library, which is similar in purpose to DirectX under Windows. Home page is http://pygame.seul.org/ The deb's have been on the pygame web site for a few weeks now, and I've had some testing and feedback. I would be grateful if someone can offer to sponsor this package. Thanks, Francis -- Home: [EMAIL PROTECTED] Web: www.flourish.org
Packaging PyGame
PyGame is a set of bindings for SDL, to make games development in Python easy. http://www.pygame.org/ PyGame has just reached version 1.1 is very stable, has an active community, and a good reception in the media. I've maintained Debian packages of it for six months, and they are very stable and easy to maintain. I would like these to go in the main Debian archive. I could not honestly become a Debian maintainer, and carry out the job as well as I should, at the present time. Is any maintainer interested in taking on this package, or in sponsoring uploading of it? It's an important package as it opens up Python to a whole new audience. Python is increasingly used as an educational programming language, and being able to do fast graphics is useful in that setting. It's ITP #83446. If you would like to help, please let me know. Francis -- Home: [EMAIL PROTECTED] Web: www.flourish.org
