Re: Python mkhowto and friends
As I am away the next two weeks, is somebody interested to make a patch to build such a package from the python source? Fabian Fagerholm writes: > Hi! > > I've been working on packaging Albatross, a web application toolkit for > Python (see ITP: #193574). Albatross has very nice documentation that is > written in LaTeX. The distribution includes a Makefile for generating > PostScript, PDF and HTML from the LaTeX sources. The output is in the > same style and spirit as the rest of the Python documentation. > > However, the Makefile relies on mkhowto and several other files that > exist in the Python upstream source tarball. These files are not, to my > knowledge, included in any Debian package, only in the source packages > for python2.x. Thus for the current version of my Albatross packages, I > ship a subset of these files in my diff in order to build the docs. > > My reason for approaching you with this issue is that I think it would > be useful to have these tools packaged in some manner. Since you are the > maintainer of the Debian Python packages, I thought it would be a good > idea to discuss possibilities before opening wishlist bugs or anything. > > I have two ideas: either ship an appropriate subset of the contents of > the Python Doc directory in python2.x-dev, or make a new package, > perhaps something like python2.x-doc-dev, that includes everything > needed for producing this kind of documentation. Packages that build > docs in this manner could then build-depend on the appropriate package. > > Perhaps you have better ideas, or perhaps this issue has already been > solved before? > > Thanks for your work on Debian and Python! > Cheers, > -- > Fabian Fagerholm <[EMAIL PROTECTED]> > paniq.net
Re: Bug#195846: python2.2: Core-dumps when files get large
[I'm away for two weeks, so please could somebody help?] John Goerzen writes: > Package: python2.2 > Version: 2.2.3-1 > Severity: serious > > Hello, > > I have a program that writes a logfile. It is opened with a standard > open(filename, "wt") call. > > Whenever this file approaches about 1.8GB (hmm, that's 2^31, isn't it?), no, it's 2GB. > Python segfaults. I assume it does this at the time of a write, as the > program has never gotten around to a close and does nothing else to that > file whatsoever. (That is, nothing other than fh.write()). > > The file was left as: > > -rw-r--r--1 jgoerzen jgoerzen 18609162 Jun 2 15:00 log That are 18MB, not 1,8GB. Without a stack trace, there is not much to do ...
Re: Bug#195846: python2.2: Core-dumps when files get large
On Mon, Jun 02, 2003 at 10:56:05PM +0200, Matthias Klose wrote: > That are 18MB, not 1,8GB. Oops. > Without a stack trace, there is not much to do ... Here you go: #0 0x0fd90454 in exit () from /lib/libc.so.6 #1 0x0fd9044c in exit () from /lib/libc.so.6 #2 0x0ff79884 in __pthread_sighandler () from /lib/libpthread.so.0 #3 #4 0x0fd8dfd0 in kill () from /lib/libc.so.6 #5 0x0f7d8108 in wtouchln () from /lib/libncurses.so.5 #6 0x0ff79884 in __pthread_sighandler () from /lib/libpthread.so.0 #7 #8 0x0fd8e044 in sigsuspend () from /lib/libc.so.6 #9 0x0ff74adc in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #10 0x0ff71170 in pthread_cond_wait () from /lib/libpthread.so.0 #11 0x10074a98 in PyThread_acquire_lock () #12 0x1003ecf0 in PyEval_RestoreThread () #13 0x0fd10ea4 in inittime () from /usr/lib/python2.2/lib-dynload/time.so #14 0x100bd268 in PyCFunction_Call () #15 0x1003afec in Py_MakePendingCalls () #16 0x1003bd4c in PyEval_EvalCodeEx () #17 0x1003d278 in PyEval_CallObjectWithKeywords () #18 0x1003af08 in Py_MakePendingCalls () #19 0x1003bd4c in PyEval_EvalCodeEx () #20 0x1003d278 in PyEval_CallObjectWithKeywords () #21 0x1003af08 in Py_MakePendingCalls () #22 0x1003bd4c in PyEval_EvalCodeEx () #23 0x1003d278 in PyEval_CallObjectWithKeywords () #24 0x1003af08 in Py_MakePendingCalls () #25 0x1003bd4c in PyEval_EvalCodeEx () #26 0x1003eddc in PyEval_EvalCode () #27 0x1006fd20 in PyRun_FileExFlags () #28 0x1006f458 in PyRun_SimpleFileExFlags () #29 0x1000c42c in Py_Main () #30 0x1000bea0 in main () #31 0x0fd77d04 in __libc_start_main () from /lib/libc.so.6
