Hello,
Excellent, thank you James and Jaromír for the very quick response!
Best regards,
-Christian
Package: gwc
Version: 0.21.19~dfsg0-6
Severity: important
Running 'gnome_wave_cleaner' from the testing package version
(0.21.19~dfsg0-6) crashes immediately at startup:
$ gnome_wave_cleaner
Current stack limit: 8388608 bytes
Segmentation fault
This is reproducible when building from sources:
-sphinxdoc 1.4.9-2
pn python:any
python-ws4py recommends no packages.
Versions of packages python-ws4py suggests:
ii python-cherrypy3 3.5.0-2
-- no debconf information
>From 5fe4dda90cb98f7bf54e28aa9fd9b8e179f59f67 Mon Sep 17 00:00:00 2001
From: Christian Grigis <gl...@grigri.org
Hello,
I ran into this as well, and after some investigation I found out this
only happens when using the verbose flag -v:
netcat.c, lines 609-616:
%-
if (vflag) {
/* For UDP, make sure we are
Package: autofs
Version: 5.0.8-1
Severity: normal
When upgrading from 5.0.7-3 to 5.0.8-1, my remote shares accessed via
the machine name using -hosts no longer work:
mooch:[~] ls /net/nuvola
ls: cannot access /net/nuvola: No such file or directory
Setting the logging to debug shows the
Package: toolame
Version: 02l-6
Severity: important
Tags: patch
Hello,
When encoding a mono/16-bit/48kHz WAV file, the resulting file is
sometimes corrupted in the 'padding' information of the headers, which
renders it unplayable by a decoder:
% file test.wav
test.wav: RIFF (little-endian)
Package: toolame
Version: 02l-6
Severity: important
Tags: patch
When reading the sample frequency of the WAV header (a 32-bit
value), a pointer to an unsigned long is used on little-endian
platforms. Unfortunately, unsigned long is 64-bit on 64-bit platforms:
% file audio.wav
audio.wav: RIFF
Package: tree
Version: 1.5.2.1-1
Severity: normal
Tags: patch l10n
It seems that the current locale is not taken into account when displaying
file names:
% mkdir tmp
% touch tmp/eeeéee
% tree tmp
tmp
`-- eee\303\251ee
0 directories, 1 file
By examining the sources, my understanding is that
Package: iso-codes
Version: 1.5-1
Severity: normal
Tags: l10n
The file iso_639_3.xml is encoded in ISO 8859-1, despite being declared as
UTF-8:
% head -1 /usr/share/xml/iso-codes/iso_639_3.xml
?xml version=1.0 encoding=UTF-8 ?
For example:
% od -Ax -tx1a /usr/share/xml/iso-codes/iso_639_3.xml
Package: abcde
Version: 2.3.99.3-1
Severity: normal
Tags: patch
Hello,
When encoding to multiple formats (OUTPUTTYPE=ogg,mp3, for example),
the output file name of the formats after the first one is incorrect
(.ogg even for the mp3 file, in our example).
I believe it is just a missed namechange
Package: abcde
Version: 2.3.99-1
Severity: minor
As indicated in the release notes, BATCH has been split in BATCHNORM
and NOGAP; however, the default configuration file 'abcde.conf' still
references BATCH.
Thanks, and best regards!
-Christian
-- System Information:
Debian Release:
Package: lyx-common
Version: 1.3.6-1
Severity: normal
'lyxview.sh' is lacking execute permission:
% ls -l /usr/share/lyx/scripts/lyxview.sh
-rw-r--r-- 1 root root 392 2005-09-25 07:55 /usr/share/lyx/scripts/lyxview.sh
This prevents the View-DVI [C-d] menu option to work properly.
With
Package: evince
Version: 0.1.5-2
Severity: normal
The package is missing some mime information, such as a file to be put
in /usr/lib/mime/packages/ . This prevents update-mime(8) from adding
an entry for evince in /etc/mailcap .
Using a file very similar to the one used by gpdf worked fine for
Package: abcde
Version: 2.2.5-1
Severity: normal
Tags: patch
I ran into a problem using abcde with a multi-artist CD that contains
'*' in a track name (cddb ID f610ea12):
(...)
TTITLE14=M83 / *
(...)
In this case, it seems do_tag() and do_move() are using a shell-expanded
version of the title,
14 matches
Mail list logo
