Package: axiom
Version: 20050201-1
Severity: grave
Tags: security
Justification: user security hole
The following binaries were statically linked agains libXpm.a from
a version of libxpm-dev predating 4.3.0.dfsg.1-14.
/usr/lib/axiom-20050201/bin/hypertex
/usr/lib/axiom-20050201/lib/view2D
As
Package: axiom-hypertex-data
Version: 20050201-1
Severity: normal
With the axiom-hypertex-{,data} and axiom-graphics-{,data} packages
installed, axiom opens the HyperDoc welcome screen by default.
Selecting first the Reference and then the Search options, one is faced
with a search prompt.
It solves many kinds of problems such as ...
Thanks.
Igor Khavkine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Since there was no response to the bug report, I decided to rumage
through some sources to find the memory hog. It turns out that the
problem was with my local configuration. Somehow, the file
/etc/pango/pango.modules got corrupted and was padded with zeros to
about 500MB in size. Which explains
Package: libgtk2.0-0
Version: 2.6.9-1
Severity: important
When running any gtk2 app, the app's virtual memory usage goes up to
more than 500MB, stays there for a bit, then returns to normal, and
after that the app's window appears on the screen. I have 192MB of
physical RAM and 500MB of swap. The
Package: liboil0.3
Version: 0.3.2-1
Severity: normal
Whenever liboil0.3 is invoked (by swfdec-mozilla-player) I get the
following error message:
OIL: ERROR liboiltest.c 247: (): illegal instruction in idct8x8_s16_mmx
GDB says that the offending instruction is `pshufw' at
0xb7490424
- Original Message -
From: David Schleef [EMAIL PROTECTED]
To: Igor Khavkine [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Bug#312325: liboil0.3: Illegal instruction in idct8x8_s16_mmx
Date: Tue, 7 Jun 2005 12:14:29 -0700
On Tue, Jun 07, 2005 at 09:13:57AM -0400, Igor Khavkine
- Original Message -
From: Ilya Baran [EMAIL PROTECTED]
To: Steve M. Robbins [EMAIL PROTECTED]
Subject: Re: Bug#297657: kseg: Locus drawn incorrectly
Date: Sun, 03 Apr 2005 20:04:45 -0400
Hi, Steve and Igor,
The locus is being drawn incorrectly because the blue point is
supposed to
Package: kseg
Version: 0.4-1
Severity: normal
See attached .seg file and .png screenshot illustrating the bug. The red
point is the control point, the blue point is the one that generates the
locus. The locus itself is also highlighted in blue.
Igor
-- System Information:
Debian Release: 3.1
Package: texmacs
Version: 1:1.0.4-R3-5
Severity: normal
The Maple interface fails because of improper quoting in
/usr/lib/texmacs/TeXmacs/bin/tm_maple. Correct quoting is given by
tm_maple
#!/bin/sh
exec maple_in_filter | maple -ll -l p=calc -c
Package: texmacs
Version: 1:1.0.4-R3-5
Severity: normal
Open an Octave session. Produce a plot
plot(sin(0:.1:pi))
Go back to to the *same line*, and change it to produce a different plot
plot(cos(0:.1:pi))
The two different plots will overlap in the same image. Pressing Enter
on the above
Package: nvidia-kernel-source
Version: 1.0.6629+1-2
Followup-For: Bug #292543
When X is started, the graphics become garbled. Windows are partially
undrawn and leave residue on the screen when moved. Switching to another
virtual console locks the machine. Downgrading to 1.0.6111-2 fixes the
12 matches
Mail list logo
