I can confirm this bug too. First seen it on an Ubuntu system,
then got it on Debian after upgrade from etch to lenny.
Guest system is Windows 98 SE, disk images are in qcow2 format.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Monday 27 October 2008, Hilmar Preusse wrote:
Frank analyszed that bug and found out that the problem only occurs
if TEXMFSYSVAR is nor part of SYSTEXMF. Actually (TL 2007) this is
not the case any more and I couldn't reproduce your bug any more.
[EMAIL PROTECTED]:~ $ mktexpk --mfmode
Package: dpkg-dev
Version: 1.13.25
Severity: wishlist
Debian source packages are hard to deal with when it comes to local
modifications.
Suppose I want to build a package with a custom patch applied. In theory it is
supposed to work like this: run dpkg-source -x (or unpack an .orig.tar.gz
and
On Friday 02 March 2007 18:21, Frank Küster wrote:
Okay, I've investigated this a bit further.
When the cyrtex format is created, some fonts are needed. No matter
whether we are using teTeX or TeX Live, as long as HOME is set and
exists, the fonts are placed in $TEXMFVAR (i.e.
On Tuesday 27 February 2007 12:01, Frank Küster wrote:
retitle 412242 fonts generated upon format creation are placed in
TEXMFSYSVAR
[...]
/var/lib/texmf/fonts is and never was supposed to contain pk fonts, if I
remember correctly.
I still think that the issue is about maketexpk. If
On Sunday 25 February 2007 17:12, Frank Küster wrote:
/var/lib/texmf/fonts is and never was supposed to contain pk fonts, if I
remember correctly.
So maybe we should rather find out how these fonts got there. If it is
something that might have happened to more users, we may need to cater
Package: tetex-bin
Version: 3.0-29
Severity: normal
On my system, the command
mktexpk --mfmode ljfour --bdpi 600 --mag 1+120/600 --dpi 720 lhr10
places the resulting file lhr10.720pk in the current working directory.
(The font lhr10 is a cyrillic version of cmr10, I think it belongs
to
Package: module-init-tools
Version: 3.2-pre1-2
Severity: normal
Modprobe seems to include all files found in /etc/modprobe.d,
maybe except specials like *.dpkg-dist.
This is a problem if a user changes a file and wants to keep
a backup copy. He probably would not call it `something.dpkg-dist'.
Package: alsaplayer
Version: 0.99.76-0.2
Severity: important
On my system, if 'no.mp3' does not exist, I get:
~$ alsaplayer no.mp3
mad_open() failed
mad_open() failed
...done playing
Segmentation fault
~$ alsaplayer --verbose no.mp3
AlsaPlayer 0.99.76
(C) 1999-2003 Andy Lo A Foe [EMAIL
Package: alsa-base
Version: 1.0.8-4
Severity: normal
Tags: patch
The alsa initscript uses
eval $1 --help || ...
to test the presence of a command $1. However the behavior
of `eval foo || bar' after `set -e' is shell-dependent,
see Bug#268944.
If /bin/sh is dash, and the command in
to dpkg-deb.
Could you drop me a note on whether the feature is worth considering
for inclusion to dpkg, at some point in the future? (I don't know,
maybe I'm the only one who finds fakeroot inconvenient.)
Best regards,
Sergei Ivanov
--- dpkg-1.10.26/dpkg-deb/main.c.-rootowner 2005-01-11 19:55
Package: dpkg-dev
Version: 1.10.25
Severity: wishlist
Hello,
It would be nice if dpkg-deb could produce .deb archives where all
files are owned by root:root, ignoring the ownership attributes from
the filesystem.
This seems easy to implement - maybe using GNUtar --owner...,
or rewriting the
12 matches
Mail list logo
