Bug#291494: cron mail from removed package
Package: chkrootkit Version: Even though chkrootkit is removed (though not purged) I get the following mail from cron: /etc/cron.daily/chkrootkit: /etc/cron.daily/chkrootkit: line 10: chkrootkit: command not found run-parts: /etc/cron.daily/chkrootkit exited with return code 127 /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man1/javah.1.gz is a dangling symlink It would seem the last two lines are due to java, but the first three lines are due to chkrootkit. Please can you fix the script to test that the command exists before trying to run it. Package: chkrootkit Status: deinstall ok config-files Priority: optional Section: misc Installed-Size: 652 Maintainer: lantz moore <[EMAIL PROTECTED]> Architecture: i386 Version: 0.44-2 Config-Version: 0.44-2 Depends: libc6 (>= 2.3.2.ds1-4), binutils, net-tools, debconf Conffiles: /etc/cron.daily/chkrootkit 8ff5aa1a5324ff308a5734d227e3635d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291510: dangling symlink
Package: kaffe Version: 2:1.1.4.PRECVS6-1 I get the following output from cron.daily: /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man1/javah.1.gz is a dangling symlink It seems your package is at fault, and the man page has gone away: [EMAIL PROTECTED]:~$ ls -l /usr/share/man/man1/javah.1.gz lrwxrwxrwx 1 root root 28 2005-01-13 17:05 /usr/share/man/man1/javah.1.gz -> /etc/alternatives/javah.1.gz [EMAIL PROTECTED]:~$ ls -l /etc/alternatives/javah.1.gz lrwxrwxrwx 1 root root 36 2005-01-13 17:05 /etc/alternatives/javah.1.gz -> /usr/share/man/man1/javah.kaffe.1.gz [EMAIL PROTECTED]:~$ ls -l /usr/share/man/man1/javah.kaffe.1.gz ls: /usr/share/man/man1/javah.kaffe.1.gz: No such file or directory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295205: metapost figures in xdvi with tex text
Package: tetex-bin
Version: 2.0.2-26
If you put tex text in a metapost figure, and preview with xdvi, then
not only does the text not display, but subsequent pictures don't
either.
What seems to happen is that the figure is passed directly to
ghostscript, which then can't interpret the picture.
The figure prints out perfectly fine if dvips followed by ghostview is
used.
Ideal solution would be to display the text - but, failing that, not
crashing the underlying ghostscript would be nice.
Here is a simple example of the effect:
mpost withtex.mp
latex xdvibug.tex
xdvi xdvibug
will show the problem (recompile and when you refresh the xdvi window,
the picture disappears) if you use the files below.
withtex.mp contains the following:
beginfig(1);
numeric u ; u=2cm;
drawarrow (-u,0)--(u,0);
drawarrow (0,-u)--(0,u);
%comment out line below and it runs fine.
label.bot(btex $Si(1\bar11)$ etex, (u,0));
endfig;
end
And you can include it in the following basic latex article:
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}
%\thispagestyle{empty}
\includegraphics{withtex.1}
\end{figure}
\end{document}
Thanks,
Chris
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295205: metapost figures in xdvi with tex text
On Tue, Feb 15, 2005 at 01:00:03PM +0100, Frank K?ster wrote: > Stefan Ulrich <[EMAIL PROTECTED]> wrote: > > > There doesn't seem to be an easy way for Xdvi to detect that it's not > > a standalone PS file. (Paul, you know more about Postscript than I do > > - is the problem that the PS file doesn't define any fonts? Is this > > the way Metapost works? Does it work with dvips since the font will be > > already present in the `main' file?) http://www.tex.ac.uk/cgi-bin/texfaq2html?label=mpprologues implies that this is the case. > > > > If there's no way for xdvi to detect/fix this font problem, maybe we > > should switch to displaying a placeholder/bounding box for Metapost > > files - I don't know much about Metapost either; can we assume that > > files missing an `.(e)ps' extension are Metapost, or would we need > > to scan all files in 'PSfile' specials for a `%%Creator: MetaPost' > > comment? > > Shouldn't LaTeX indicate properly what it included? I don't guarantee that my example uses the correct way of including the metapost LaTeX - but if I've got it wrong, it wasn't obvious from the faq answers I've read -and it seemed to work in dvips. Chris PS Not directly relevant to the bug, but the molecular structures example at http://matagalatlante.org/nobre/featpost/doc/featexamples.html is the reason I'm using metapost. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295205: metapost figures in xdvi with tex text
On Tue, Feb 15, 2005 at 01:45:24PM -0800, Paul Vojta wrote: > On Tue, Feb 15, 2005 at 01:00:03PM +0100, Frank K?ster wrote: > > Stefan Ulrich <[EMAIL PROTECTED]> wrote: > > > > > There doesn't seem to be an easy way for Xdvi to detect that it's not > > > a standalone PS file. (Paul, you know more about Postscript than I do > > > - is the problem that the PS file doesn't define any fonts? Is this > > > the way Metapost works? Does it work with dvips since the font will be > > > already present in the `main' file?) > > > > > > If there's no way for xdvi to detect/fix this font problem, maybe we > > > should switch to displaying a placeholder/bounding box for Metapost > > > files - I don't know much about Metapost either; can we assume that > > > files missing an `.(e)ps' extension are Metapost, or would we need > > > to scan all files in 'PSfile' specials for a `%%Creator: MetaPost' > > > comment? > > metapost files are not .eps, although they're very close. They require > special processing, which I haven't implemented yet. I should check what > dvips does, and mimic that. That, or whatever pdflatex uses to iterpret metapost files. It would be great if you could fix this. Thanks, Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295957: Cheetah 0.9.16a2 available
Package: cheetah-comon Version: 0.9.15-5 A new version of cheetah is available (0.9.16a2). Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295958: test failures when not in /tmp
Package: cheetah-common
Version: 0.9.15-5
If you run
cheetah test
in a directory other than /tmp, you get 16 failures and 3 errors
in /tmp, you get 16 failures, but no errors.
The directory is writable, but the first error is:
**
ERROR Cheetah.Tests.SyntaxAndOutput.ExtendsDirective.test4 (#extends
SampleBaseClass without #import)
--
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/Cheetah/Tests/SyntaxAndOutput.py",
line 1986, in test4
'\n')
File "/usr/lib/python2.3/site-packages/Cheetah/Tests/SyntaxAndOutput.py",
line 146, in verify
self._gen(input)
File "/usr/lib/python2.3/site-packages/Cheetah/Tests/SyntaxAndOutput.py",
line 154, in _gen
settings=self.settings(),
File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line 156, in
__init__
self.compile(source, file)
File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line 245, in
compile
compiler.compile()
File "/usr/lib/python2.3/site-packages/Cheetah/Compiler.py", line 1086, in
compile
self.parse()
File "/usr/lib/python2.3/site-packages/Cheetah/Parser.py", line 1036, in parse
self.eatDirective()
File "/usr/lib/python2.3/site-packages/Cheetah/Parser.py", line 1150, in
eatDirective
self.directiveEaters[directiveKey]()
File "/usr/lib/python2.3/site-packages/Cheetah/Parser.py", line 1470, in
eatExtends
mod =
self._templateObj._importAsDummyModule('\n'.join(self._importStatements))
File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line 454, in
_importAsDummyModule
mod = self._impModFromDummyPackage(packageName, tmpFilename)
File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line 496, in
_impModFromDummyPackage
moduleDir, forceReload=1)
File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line 526, in
_importModuleFromDirectory
module = imp.load_module(fullModuleName, fp, pathname, stuff)
File "/tmp/__CheetahTemp_2005021919454929608.py", line 13, in ?
from SampleBaseClass import SampleBaseClass
ImportError: No module named SampleBaseClass
**
Chris
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295958: test failures when not in /tmp
On Sun, Feb 20, 2005 at 12:00:48PM -0600, Chad Walstrom wrote: > Chris Walker wrote: > > Package: cheetah-common > > Version: 0.9.15-5 > > > > If you run > > cheetah test > > > > in a directory other than /tmp, you get 16 failures and 3 errors > > > > > > in /tmp, you get 16 failures, but no errors. > > Release of 0.9.16a1 indicates that these errors are a result of running > "test" in a directory that isn't writable. In 0.9.15, it also occurs in a directory that IS writable. Which I should have said more clearly in the initial bug report. Sorry. This is why I reported the bug. > > - Abort with a helpful error message if user runs 'cheetah test' in a > directory without write permission. (Kludge in CheetahWrapper.py; > we should probably move the temp files under the system tmp > directory.) [MO] > > Now, the fix in 0.9.16a1 is obviously a "helpful error message". So, if > the cheetah team isn't going to do more than add an error message, > > I plan on changing the severity of this bug to "minor" and tagging it > "wont-fix". I could possibly back-port the "fix", but would you really > benefit all that much with an additional error message? If it is fixed in 0.9.16a1, then I don't think it is worth backporting the fix. "minor" is fine. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295957: Cheetah 0.9.16a2 available
On Sun, Feb 20, 2005 at 11:52:46AM -0600, Chad Walstrom wrote: > Chris Walker wrote: > > A new version of cheetah is available (0.9.16a2). > > Should we be upgrading to alpha quality software as a target for sarge? Possibly not. I'd missed the fact that it was alpha - though I should have guessed from the filename. > It does look like 0.9.16a1 fixed quite a few bugs and added a few > features, but the fact that the cheetah team released the software as > "alpha" indicates to me that it may not be ready for the stable target > of Debian. > > I could package it and mark it sid-only. *shrug* Or indeed experimental. A python2.4 package might also be worth considering (and AIUI needs to be manually approved by ftpmaster, which will clearly take some time). As you are aware of the new package, and making a positive decision not to upgrade, then I'm happy to trust your judgement. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
