Bug#510961: Intent to NMU nvidia-graphics-drivers-legacy-96xx_96.43.13-0.1_i386.changes
Dixit Yaroslav Halchenko deb...@onerussian.com : Dear Maintainers and Samuel, Hello, Since there were no progress on this bug I've decided to prep NMU. Since we have already 2.6.30 and upload is into unstable, I've taken Samuel's version, boosted with drivers of 96.43.13, tested on i386 Doing so seems to work, though I noticed that in version 96.43.11 (the version I packaged) nvidia introduced hooks into the scripts so as to make integration into packaging systems easier. I think it is mentioned somewhere in the changelog, as far as I remember. Thus I guess the maintainer of this package shall look into it when he does the next upload -- just my 2 cents. I haven't done 'overhaul' maintainership (lintian is screaming ;)), just minimal changes to get it rolling I would appreciate testing from the users/interested parties ;) or reaction from the maintainers -- I will upload to delayed queue in 2 days. I will be able to test it in a month only, the machine on which I used these packages is at work. But I shall test it nonetheless, for what it's worth. Thanks for NMUing this new version, as I will not have much access to the aforementioned machine after that and I did not see myself proposing packages I could not test :-P -- Samuel Colin E-mail: scolin-spa...@hivernal.org Informations: http://hivernal.org/static/about/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510961: nvidia-kernel-legacy-96xx-source: Confirmed, built personal packages for the impatient
Package: nvidia-kernel-legacy-96xx-source Version: 96.43.07-2 Severity: normal Hi, I had the same problem with a machine with a 2.6.28 kernel I custom-compiled. Still wanting to get some graphic acceleration with this kernel, I went ahead, took a look at the source of the package and built a personal version. It is here: http://hivernal.org/resources/debian/ Usual instructions for adding a third-party repository: http://hivernal.org/static/debian/ (in french, but you should know what you are doing anyway). In a nutshell, I just had to change the version number in upstream_info, change the xen patch in patches and it compiled ok. I installed the package, compiled against my kernel, a few warnings were displayed (nvidia is most likely the culprit, for these), rebooted and it seems to work (glxgears was fast, blender did not complain). I propose them only for the impatient, I shall remove them as soon as a new version enters testing. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.28 Locale: LANG=C, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nvidia-kernel-legacy-96xx-source depends on: ii debhelper 7.2.7 helper programs for debian/rules ii dpatch2.0.31 patch maintenance system for Debia ii make 3.81-5 The GNU version of the make util ii sed 4.1.5-8The GNU sed stream editor Versions of packages nvidia-kernel-legacy-96xx-source recommends: ii devscripts2.10.47scripts to make the life of a Debi ii kernel-package11.017 A utility for building Linux kerne ii nvidia-glx-legacy-96xx96.43.07-2 NVIDIA binary Xorg driver (96xx le nvidia-kernel-legacy-96xx-source suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#498713: No why-related *.vo files in coq/user-contrib
Package: why Version: 2.15-1.1 Severity: important Hi, compiling why 2.15 with the debian/ from pkg-ocaml-maint in svn.debian.org prevents *.vo files from being put in /usr/lib/coq/user-contrib. This is because (see install-coq-v8 in Makefile.in) the makefile tests for the existence and writeability of COQDIR, which at package compilation is debian/why/usr/lib/coq but actually does not exists. Hence the *.vo are put in $(LIBDIR)/why/coq (with a warning message). I think this makes using why out-of-the-box difficult with Coq. I tried for my own version of the package (hence the Version above) by adding the following line in debian/rules (with some context): ## dh_installdirs + mkdir -p $(CURDIR)/debian/why/usr/lib/coq $(MAKE) prefix=$(CURDIR)/debian/why/usr install COQLIB=$(CURDIR)/debian/why/usr/lib/coq mkdir -p $(CURDIR)/debian/why/usr/lib/coq ## I suspect adding usr/lib/coq to a debian/dirs file would also do the trick, but I did not test this solution. Regards, Samuel Colin -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25 (PREEMPT) Locale: LANG=C, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages why depends on: ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libc6 2.7-13 GNU C Library: Shared libraries ii libcairo2 1.6.4-6The Cairo 2D vector graphics libra ii libglib2.0-0 2.16.5-1 The GLib library of C routines ii libgtk2.0-0 2.12.11-3 The GTK+ graphical user interface ii libpango1.0-0 1.20.5-2 Layout and rendering of internatio why recommends no packages. Versions of packages why suggests: ii coq8.1.pl3+dfsg-1+b2 proof assistant for higher-order l -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488482: genisoimage: Patch for correcting the issue
Dixit Roman Rakus [EMAIL PROTECTED] : Steve McIntyre wrote: On Sat, Jul 05, 2008 at 08:30:47PM +0200, Samuel Colin wrote: Thanks very much for the analysis here - it looks very useful. The change that went in in the last release was from a patch by Roman to preserve directory permissions. Maybe he can comment on the effects here... Hi. I'm sorry for introducing this bug. When I was porting the patch I do some changes and forgot to turn back this change. What is the goal of and-ing the file mode to 777 ? I more or less understood that it cleared specific modes (the file is a link, or things like that) and that it may have a role in writing files into the index of the iso fs. Actually I may be wrong-headed in my understanding, and if it is not possible to explain what happens here in just a few sentences, don't bother :-P It's just that I had some difficulties tracking the role of the statbuf variable here and it was the introduced change that made the less sense in the proposed patch, hence it could be said that I found the bug almost by sheer luck. Anyway, thanks for the quick reply :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488482: genisoimage: Patch for correcting the issue
Package: genisoimage Version: 9:1.1.8-1 Followup-For: Bug #488482 Hi, it's-a-me again, I found some courage and tried to look for what specific change might have introduced the problem. You will find the attached patch which seems to solve it. A few more details: - I tested the patch by comparing versions 1.1.7 and 1.1.8 with the patch with -v -v parameter and both versions compiled with -DDEBUG for genisoimage: Except for the version number and the X% done, estimate finish..., there is no difference - The ISO image was produced with -R (not -r or -xa, thus they might need testing too). By mounting it with -o loop and exploring the deep directories I could access the files - I have no clue why this patch works except that it was among default value settings and it made my coder-sense tingle. diff --git a/genisoimage/tree.c b/genisoimage/tree.c index a11098a..7805888 100644 --- a/genisoimage/tree.c +++ b/genisoimage/tree.c @@ -1994,7 +1994,7 @@ insert_file_entry(struct directory *this_dir, char *whole_path, s_entry1-filedir = this_dir; statbuf.st_size = (off_t)0; -// statbuf.st_mode = 0777; + statbuf.st_mode = 0777; set_733((char *) s_entry-isorec.size, 0); s_entry-realsize=0; s_entry-size = 0;
Bug#488482: genisoimage: This actually might be a new behaviour
Package: genisoimage Version: 9:1.1.8-1 Followup-For: Bug #488482 Hi, just bumping to confirm the bug and stating that it might actually be new. I regularly do (from every two weeks to one month) backups through genisoimage of a directory with often deeply nested subdirectories and the problem did not appear before this version. Thus the bug has probably been introduced by one of the latest changes. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages genisoimage depends on: ii libbz2-1.0 1.0.5-0.1 high-quality block-sorting file co ii libc6 2.7-10GNU C Library: Shared libraries ii libmagic1 4.24-2File type determination library us ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime genisoimage recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488482: Info received (genisoimage: This actually might be a new behaviour)
Hello, I have additional information about the bug. As it was the opportunity to try git bisect I tried to find the commit that introduced the regression this way. I took the 1.1.7 version as the good version (I tested, it created the iso with a deep directory structure ok) and 1.1.8 as the bad version, in git terms. I used a small test.sh script that rebuilt genisoimage each time git switched commits, and created a small deep directory structure to test genisoimage on it. Here are the last lines of running git bisect run ./test.sh: ### ./build/genisoimage/genisoimage: Directories too deep for 'youpi/1/2/3/4/5/6/7/8' (7) max is 6. cf36ca94fbd5c523dd8d106f528da97c1eec55d4 is first bad commit commit cf36ca94fbd5c523dd8d106f528da97c1eec55d4 Author: 93sam [EMAIL PROTECTED] Date: Sun May 25 21:00:55 2008 + genisoimage: Applied patch from Roman Rakus [EMAIL PROTECTED] to preserve directory permissions. git-svn-id: svn://svn.debian.org/debburn/cdrkit/[EMAIL PROTECTED] a95a6be8-091b-0410-adaf-d31e6857962f :100644 100644 74442af32ede6b33be80fe31ebc536a7e0dc8d66 cbe6b76b4ec8cd4d9a3bd84c2cb32dd71534cb59 M Changelog :04 04 e731a720a0890204ca23d2da37603bb6204cd879 c94c52da9968e242e963db771397a4f06d72d4a8 M genisoimage bisect run success # Hence the problematic revision seems to be the 807th one if I am to believe git. Taking a look at the source shows many changes into genisoimage, but I'm not familiar enough with the codebase to take a guess :-( Hope this helps, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477670: sed --posix non posix-compliant wrt backslashes in replacement string of the 's' command
Package: sed Version: 4.1.5-6 Severity: normal Hello, I think the --posix option might be too aggressive wrt the \ character in the replacement string of the 's' command. Some examples: [14:07:17] - [EMAIL PROTECTED]:~$ echo foobar | sed --posix -e 's/\(o\)/\1/g' foobar Works OK (using a newline too -- hence it is posix-compliant). But the following behaviour might not: Exhibit 1: [14:07:34] - [EMAIL PROTECTED]:~$ echo foobar | sed --posix -e 's/\(o\)/\/g' fbar Exhibit 2: [14:07:27] - [EMAIL PROTECTED]:~$ echo foobar | sed --posix -e 's/\(o\)/\\1/g' f11bar Exhibit 3: [14:07:30] - [EMAIL PROTECTED]:~$ echo foobar | sed --posix -e 's/\(o\)/\\/g' fbar Now let me take the relevant part of the POSIX spec for sed, where I put [x] to pinpoint where the spec seems not to be respected: The replacement string shall be scanned from beginning to end. An ampersand ( '' ) appearing in the replacement shall be replaced by the string matching the BRE. The special meaning of '' in this context can be suppressed by preceding it by a backslash. The characters \n, where n is a digit, shall be replaced by the text matched by the corresponding backreference expression. The special meaning of \n where n is a digit in this context, can be suppressed by preceding it by a backslash[2]. For each other backslash ( '\' ) encountered, the following character shall lose its special meaning (if any). The meaning of a '\' immediately followed by any character other than ''[1], '\'[3], a digit, or the delimiter character used for this command, is unspecified. If my reading of the spec is correct, the tests above shall return: Exhibit 1: fbar (special meaning of is suppressed, hence actual s) Exhibit 2: f\1\1bar (special meaning of \1 suppressed) Exhibit 3: f\\bar (special meaning of \ suppressed) Though I might agree that the behaviour for \\ is more implicit in the spec, as it is deduced from the spec of [2]. I stated in the beginning that it was too aggressive for \ as in the sources, characters other than numbers fall into a default in a switch statement without taking \ or into account, as I remember. Is my understanding of the spec correct and is this indeed a bug of the --posix option ? Regards, Samuel Colin -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24 (PREEMPT) Locale: LANG=C, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sed depends on: ii libc6 2.7-10 GNU C Library: Shared libraries sed recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477670: sed --posix non posix-compliant wrt backslashes in replacement string of the 's' command
Dixit Paolo Bonzini [EMAIL PROTECTED] : Paolo Bonzini wrote: Fixed by commit 4c4207c in the upstream git repository. Sorry -- by commit f11ba2ae Just tested the patch against the sed sources of Debian unstable, it works. What surprised me was : [17:14:27] - [EMAIL PROTECTED]:~/tmp/test/sed-4.1.5/sed$ echo foobar | ./sed --posix 's/\(o\)/\n/g' f bar The behaviour of posix sed is unspecified if it is anything other than \, \\, \number, thus it is not a problem to have a newline here. I remarked it because the sed of FreeBSD (for instance) prints n instead of newlines, hence it would be fnnbar above. But I suppose in general it is a bad idea to behave the same way as other implementations for unspecified behaviours. Anyway the patch works for me, the bug can be closed when the package is updated with the latest upstream revision. Thanks for the quick reply solution :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451701: grub: A small bit of additional information
Package: grub
Followup-For: Bug #451701
Hi,
I was just bitten by the aforementioned bug.
The machine where I saw the problem appear ran a 2.6.18 kernel with very old
grub stage files (timestamp showed something like March 2003).
I updated to a 2.6.24 kernel ('cause of the vmsplice problem), rebooted, and
couldn't see a thing because the machine is actually my gateway at home,
with no screen attached.
Making a grub-install with the grub version from Lenny solved the bug.
But the conditions in which I discovered the problem make me suggest to add
to the installation scripts of kernels =2.6.23 a warning (mine was built
with kernel-package and linux-source-2.6.24)
Oh well, no rebooting-remotely-with-a-new-kernel-and-fingers-crossed for me
today :-D
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.24
Locale: LANG=C, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages grub depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libncurses5 5.6+20080308-1 Shared libraries for terminal hand
grub recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467082: bibtex2html: Accents lexing/parsing
Package: bibtex2html
Version: 1.91-1
Severity: minor
Hi,
in my use of bib2bib I discovered that the õ character was not handled. Thus
I added it to latex_accents.mll.
I also made the following changes to it:
- Other latin-1 diacritics (Ç, Ã, etc)
- I removed the \\I letters: to my knowledge only \i exists so as to
remove the point above the i. No need of a \I as it already lacks this
point
- I added \\i} because it was not able to handle entries like:
author = {Col{\\i}n},
for instance. The first { is taken by next_char but once \\ has been
lexed quote_char does not know about \\i}, hence my addition
- I also added the {I} char
I hoped I did not misinterpret the inner workings of latex_accents.mll, see
the attached diff.
On that note, I also discovered that fields like:
author = {Tr{\ e}ma and Cl{\' e}s},
were not correctly matched by a regex condition. One of the cause seems to
come from the fact that latex_accents.mll does not take inner spaces into
account. Other experiments seem to also suggest something in condition_lexer
and/or bibtex_lexer, although I'm far from sure.
I got very confused between the OCaml escapings of characters, the escapings
I had to do in my shell and the escapings in the regex, and all the lexers,
thus I will not attempt to touch it and trust upstream here :-)
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.22
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages bibtex2html depends on:
ii ocaml-base-nox [ocaml-base-no 3.10.0-13 Runtime system for ocaml bytecode
ii perl 5.8.8-12 Larry Wall's Practical Extraction
ii texlive-base 2007-13TeX Live: Essential programs and f
bibtex2html recommends no packages.
-- no debconf information
--- latex_accents.mll.backup2008-02-22 19:09:59.0 +0100
+++ latex_accents.mll 2008-02-22 20:03:46.0 +0100
@@ -37,7 +37,13 @@
| '{' { next_char lexbuf }
| '}' { next_char lexbuf }
| 'ç' { add_string ccedil; ; next_char lexbuf }
+ | 'Ç' { add_string Ccedil; ; next_char lexbuf }
| 'ñ' { add_string ntilde;; next_char lexbuf }
+ | 'Ñ' { add_string Ntilde;; next_char lexbuf }
+ | 'ã' { add_string atilde;; next_char lexbuf }
+ | 'Ã' { add_string Atilde;; next_char lexbuf }
+ | 'õ' { add_string otilde;; next_char lexbuf }
+ | 'Õ' { add_string Otilde;; next_char lexbuf }
| 'ä' { add_string auml;; next_char lexbuf }
| 'ö' { add_string ouml;; next_char lexbuf }
| 'ü' { add_string uuml;; next_char lexbuf }
@@ -90,25 +96,27 @@
| '`'{ left_accent lexbuf }
| '^'{ hat lexbuf }
| c{c} { add_string ccedil; ; next_char lexbuf }
+| c{C} { add_string Ccedil; ; next_char lexbuf }
| 'v'{ czech lexbuf }
-| (~n|~{n}) { add_string ntilde;; next_char lexbuf }
+| '~'{ tilde lexbuf }
| _ { add_string \\ ; add lexbuf ; next_char lexbuf }
| eof{ add_string \\ }
(* called when we have seen \\\ *)
and quote_char = parse
- ('a'|{a}) { add_string auml; ; next_char lexbuf }
-| ('o'|{o}) { add_string ouml; ; next_char lexbuf }
-| ('u'|{u}) { add_string uuml; ; next_char lexbuf }
-| ('e'|{e}) { add_string euml; ; next_char lexbuf }
-| ('A'|{A}) { add_string Auml; ; next_char lexbuf }
-| ('O'|{O}) { add_string Ouml; ; next_char lexbuf }
-| ('U'|{U}) { add_string Uuml; ; next_char lexbuf }
-| ('E'|{E}) { add_string Euml; ; next_char lexbuf }
-| (\\i space+|{\\i}){ add_string iuml; ; next_char lexbuf }
-| ('I'|\\I space+|{\\I}){ add_string Iuml; ; next_char lexbuf }
-| _ { add_string \\\ ; add lexbuf }
-| eof { add_string \\\ }
+ ('a'|{a}) { add_string auml; ; next_char lexbuf }
+| ('o'|{o}) { add_string ouml; ; next_char lexbuf }
+| ('u'|{u}) { add_string uuml; ; next_char lexbuf }
+| ('e'|{e}) { add_string euml; ; next_char lexbuf }
+| ('A'|{A}) { add_string Auml; ; next_char lexbuf }
+| ('O'|{O}) { add_string Ouml; ; next_char lexbuf }
+| ('U'|{U}) { add_string Uuml; ; next_char lexbuf }
+| ('E'|{E}) { add_string Euml; ; next_char lexbuf }
+| ('i'|{i}|\\i space+|{\\i}|\\i})
+{ add_string iuml; ; next_char lexbuf }
+| ('I'|{I}) { add_string Iuml; ; next_char lexbuf }
+| _ { add_string \\\ ; add lexbuf }
+| eof { add_string \\\ }
(* called when we have seen \\' *)
and right_accent = parse
@@ -120,9 +128,10 @@
| ('O'|{O}) { add_string Oacute; ; next_char lexbuf }
| ('U'|{U}) { add_string Uacute; ; next_char lexbuf }
| ('E'|{E}) { add_string
Bug#466524: bibtex2html: bib2bib fails for field = text {}emphase{} text
Package: bibtex2html
Version: 1.90-2
Severity: normal
Hello,
bib2bib does not like bib files with the following format:
@InProceedings{somekey,
author = Samuel Colin,
title =A title that {}confuses{} bib2bib,
}
bib2bib -c 'author : Colin' this file
stopped on the first {}.
The -delimited fields are a legitimate alternative to {}-delimited
fields. Furthermore, bibclean seems to prefer the -delimitation.
I believe this is because the lexer of bib2bib (and of bibtex2html) does not
handle braces when it has started to read a -delimited field.
I propose the attached patch to solve the problem.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.22 (PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages bibtex2html depends on:
ii ocaml-base-nox [ocaml-base-no 3.10.0-13 Runtime system for ocaml bytecode
ii perl 5.8.8-12 Larry Wall's Practical Extraction
ii texlive-base 2007-13TeX Live: Essential programs and f
bibtex2html recommends no packages.
-- no debconf information
--- bibtex_lexer.mll.backup 2008-02-19 10:11:52.0 +0100
+++ bibtex_lexer.mll2008-02-19 10:34:19.0 +0100
@@ -105,6 +105,12 @@
| _ { token lexbuf }
and string = parse
+ | '{'
+ { store_string_char '{';
+ brace lexbuf;
+ store_string_char '}';
+ string lexbuf
+ }
| ''
{ () }
| \\\
Bug#437923: xserver-xorg-input-synaptics: Similar symptoms after a kernel upgrade
Package: xserver-xorg-input-synaptics Version: 0.14.7~git20070517-2 Followup-For: Bug #437923 My touchpad stopped working after a kernel upgrade, too. My kernels are built from linux-source-2.6.* with make-kpkg. With the latest 2.6.18 kernel, touchpad works OK. With 2.6.21 and 2.6.22 (from unstable), the touchpad doesn't work. I can be more specific, though: it actually isn't detected by the synaptics driver. When it works, here is the relevant part of Xorg.0.log: # (II) Synaptics touchpad driver version 0.14.6 (1406) (--) Generic Mouse auto-dev sets device to /dev/input/event1 (**) Option Device /dev/input/event1 (**) Option LeftEdge 1700 (**) Option RightEdge 5300 (**) Option TopEdge 1700 (**) Option BottomEdge 4200 (**) Option VertScrollDelta 100 (**) Option FingerLow 25 (**) Option FingerHigh 30 (**) Option MaxTapTime 180 (**) Option MaxTapMove 220 (--) Generic Mouse touchpad found (**) Option CorePointer (**) Generic Mouse: Core Pointer (II) XINPUT: Adding extended input device Generic Mouse (type: MOUSE) (II) XINPUT: Adding extended input device Configured Mouse (type: MOUSE) (II) XINPUT: Adding extended input device Generic Keyboard (type: KEYBOARD) Synaptics DeviceInit called SynapticsCtrl called. (II) Configured Mouse: ps2EnableDataReporting: succeeded Synaptics DeviceOn called (--) Generic Mouse auto-dev sets device to /dev/input/event1 (**) Option Device /dev/input/event1 (--) Generic Mouse touchpad found Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! (**) RADEON(0): RADEONSaveScreen(2) (**) RADEON(0): RADEONSaveScreen(2) SynapticsCtrl called. # When it does not work (simply using the newly compiled kernel 2.6.21 or 2.6.22): ## (II) Synaptics touchpad driver version 0.14.6 (1406) Generic Mouse no synaptics event device found (checked 14 nodes) (**) Option Device /dev/input/mouse0 (**) Option LeftEdge 1700 (**) Option RightEdge 5300 (**) Option TopEdge 1700 (**) Option BottomEdge 4200 (**) Option VertScrollDelta 100 (**) Option FingerLow 25 (**) Option FingerHigh 30 (**) Option MaxTapTime 180 (**) Option MaxTapMove 220 Query no Synaptics: 6003C8 (EE) Generic Mouse no synaptics touchpad detected and no repeater device (EE) Generic Mouse Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device Generic Mouse (II) UnloadModule: synaptics (WW) No core pointer registered (II) XINPUT: Adding extended input device Configured Mouse (type: MOUSE) (II) XINPUT: Adding extended input device Generic Keyboard (type: KEYBOARD) (II) Configured Mouse: ps2EnableDataReporting: succeeded No core pointer Fatal server error: failed to initialize core devices As I put my touchpad as a core device, X refused to start, hence I realized it quickly. Nonetheless, with these kernels, cat /dev/input/mouse0 shows that the touchpad events are recognized, i.e. moving the finger on the touchpad makes something appear on the console. The evdev driver of XOrg is loaded, and the evdev kernel module in compiled in the kernel (putting it as an independent module yielded the same result, anyway). Hence I think the problem lies somewhere in the detection of the touchpad and the kernel. Googling the problem directed me also to this page: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89517 While not totally similar, the symptoms seem related. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18 (PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xserver-xorg-input-synaptics depends on: ii libc6 2.6-2 GNU C Library: Shared libraries ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxi6 2:1.1.2-1 X11 Input extension library ii xserver-xorg-core 2:1.3.0.0.dfsg-11 X.Org X server -- core server xserver-xorg-input-synaptics recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436423: subversion: svn export with arobase @ in filename
Package: subversion Version: 1.4.4dfsg1-1 Severity: normal Hello, I found that I was unable to export a directory of a svn local repository if this directory contains an arobase @. To reproduce, in any local repository managed with svn: mkdir [EMAIL PROTECTED] svn add [EMAIL PROTECTED] svn -m ci svn export [EMAIL PROTECTED] ~/tmp/test-error svn: Erreur de syntaxe sur la révision 'error' (I suppose the error message in english is svn: syntax error on revision 'error' or something like that). I guess that a patch would be to extract the full filename of the argument before using the @ to extract the wanted revision. This bug seems similar with: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359145 but this bug has been already solved. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18 (PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages subversion depends on: ii libapr1 1.2.7-8.2The Apache Portable Runtime Librar ii libc6 2.6-2GNU C Library: Shared libraries ii libsvn1 1.4.4dfsg1-1 Shared libraries used by Subversio subversion recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436423: subversion: svn export with arobase @ in filename
Dixit Peter Samuelson [EMAIL PROTECTED] : [Samuel Colin] mkdir [EMAIL PROTECTED] svn add [EMAIL PROTECTED] svn -m ci svn export [EMAIL PROTECTED] ~/tmp/test-error svn: Erreur de syntaxe sur la révision 'error' Yeah, this is known. You can work around it: svn export [EMAIL PROTECTED]@HEAD ~/tmp/test-error Ah, thanks. Googling it did not yield good result wrt this problem (I understood why it was so when reading svn help export). If anything, people encoutering the problem and googling it will find this bugreport and the solution above. I don't think this is a bug; it is expected consequence of a feature (the @ syntax for peg revisions). Yes, I can see which cornercases would cause a problem if wanting to solve this little oddity, such as the [EMAIL PROTECTED] filename and foo in the branch branch or something like that. Anyway, thanks for the quick reply, I guess you can close the bug, then.
Bug#339035: sylpheed-claws-gtk2: Signature insertion as the result of a command
Dixit Ricardo Mones [EMAIL PROTECTED] : Hi! Hello [environment variables not interpreted anymore] Sorry, but I think I've overlooked this (minor) bug too much ;-) Oh yeah, I forgot about this :-) Is this still happening in current sylpheed-claws-gtk2? (2.5.6) I just tested on a more up-to-date machine with the 2.5.6 version (not the one I'm writing this message with), the bug is still happening. I used double-quotes because it is less a bug and more like a change of behaviour. I guess the passage from sylpheed-claws 1.x to 2.5.x would only surprise Sarge users when doing the upgrade, and still, only if they use envt variables and shell-interpretable characters in the command producing the signature. So, in summary, the bug is still there, and a workaround is for instance calling a shell with the command. For instance, if the command was (I just tested) : cat $HOME/.signature cat ~/.signature2 echo $USER it becomes : bash -c cat $HOME/.signature cat ~/.signature2 echo $USER if you use bash. The problem with this workaround can be that the shell launched from sylpheed-claws might not have all the variables sylpheed-claws sees, and it might not even be the default shell of the user. Regards, Samuel Colin -- Nice cat BTW, Neo looks a bit like a norvegian or a maine coon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375497: inkscape: New upstream version 0.44
Package: inkscape Version: 0.43-5 Severity: wishlist Hello, the new 0.44 version of inkscape was released a few days ago. The Debian upgrade might take care of some the known problems, at the end of http://wiki.inkscape.org/wiki/index.php/ReleaseNotes044, more specifically : - Linking with libgc 1:6.7-2 or more to avoid some of the crashes described by users - Crash when the composite extension of Xorg is activated is also solved. The impressive list of new features alone is a good incentive for an upgrade as well. Regards, Samuel Colin -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages inkscape depends on: ii libatk1.0-01.11.4-2 The ATK accessibility toolkit ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library ii libc6 2.3.6-13 GNU C Library: Shared libraries ii libcairo2 1.0.4-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-7 generic font configuration library ii libfreetype6 2.2.1-2 FreeType 2 font engine, shared lib ii libgc1c2 1:6.7-2 conservative garbage collector for ii libgcc11:4.1.0-4 GCC support library ii libgconf2-42.14.0-1 GNOME configuration database syste ii libglib2.0-0 2.10.2-1 The GLib library of C routines ii libglibmm-2.4-1c2a 2.10.4-1 C++ wrapper for the GLib toolkit ( ii libgnomevfs2-0 2.14.2-1 GNOME virtual file-system (runtime ii libgtk2.0-02.8.18-1 The GTK+ graphical user interface ii libgtkmm-2.4-1c2a 1:2.8.8-1 C++ wrappers for GTK+ 2.4 (shared ii liborbit2 1:2.14.0-1.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.12.3-1 Layout and rendering of internatio ii libperl5.8 5.8.8-4 Shared Perl library ii libpng12-0 1.2.8rel-5.1 PNG library - runtime ii libpopt0 1.10-2lib for parsing cmdline parameters ii libsigc++-2.0-0c2a 2.0.16-3 type-safe Signal Framework for C++ ii libstdc++6 4.1.0-4 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.0-6 X11 client-side library ii libxcursor11.1.5.2-5 X cursor management library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxfixes3 1:3.0.1.2-4 X11 miscellaneous 'fixes' extensio ii libxft22.1.8.2-8 FreeType-based font drawing librar ii libxi6 1:1.0.0-5 X11 Input extension library ii libxinerama1 1:1.0.1-4 X11 Xinerama extension library ii libxml22.6.26.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender11:0.9.0.2-4 X Rendering Extension client libra ii libxslt1.1 1.1.17-1 XSLT processing library - runtime ii zlib1g 1:1.2.3-11compression library - runtime Versions of packages inkscape recommends: pn dia | dia-gnomenone(no description available) ii imagemagick7:6.2.4.5-0.8 Image manipulation programs pn libwmf-bin none(no description available) ii perlmagick 7:6.2.4.5-0.8 A perl interface to the libMagick ii pstoedit 3.44-1PostScript and PDF files to editab pn sketch none(no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357420: tuareg-mode: Toplevel frame won't update itself in Emacs but does in Xemacs
Hello, OK, I found the package that causes the problem: x-symbol If not installed, the scrolling in the toplevel frame is OK, and when installed, the described behaviour happens. Note that x-symbol is auto-loaded (I answered yes at the installation of the package). I did the test this time with only emacs21 (no xemacs21 installed), tuareg-mode and x-symbol. I guess I will have to disable the autoloading of x-symbol (the formulas-heavy documents I write are not OCaml sources :-P), but I'm wondering what kind of odd redefinitions x-symbol does so that it affects tuareg-mode... Unfortunately I'm no emacs-lisp hacker :-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357420: tuareg-mode: Toplevel frame won't update itself in Emacs but does in Xemacs
Dixit Ralf Treinen [EMAIL PROTECTED] : Hi, Hi, I cannot reproduce this (with the same versions of tuareg-mode and emacs21 as you have). For instance, I start emacs, enter tuareg-mode, type let id x =x, and then hit several times C-x e. This starts an ocaml toplevel in a second window, and as I feed copies of the same phrase the cursor in the second window stays at the end of the ocaml toplevel output, and the window scrolls down when the screen is full. Same for me, except for the cursor and scrolling part. The cursor stays at the first evaluated phrase (but transparent, because the focus stays in the frame with the OCaml code), and the toplevel frame doesn't scroll. Might it have something to do with the settings in your .emacs? Do you have the same behaviour when you launch emacs without interpreting your .emacs file? Yes, unfortunately. It might have something to do with the loaded emacs modes, I will try to remove them and see if one of them has an effect. Just FYI, the other emacs modes installed (some are loaded at the start of emacs, others when editing a relevant file): css-mode nxml-mode tuareg-mode (obviously :-P ) emacs-goodies-el auctex whizzytex php-elisp x-symbol And a lua-mode installed in a local directory. But this one is not auto-loaded at all. I'll try to find if one of them might affect some variable in tuareg-mode. I'll keep you informed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357420: tuareg-mode: Toplevel frame won't update itself in Emacs but does in Xemacs
Package: tuareg-mode Version: 1.45.3-1 Severity: minor Hello, when testing a function with evaluate phrase (or C-x e), or when evaluating the whole buffer, the toplevel frame won't move to the answer of the OCaml toplevel. In other words, if I evaluate let id x = x, the toplevel indeed displays val id : 'a - 'a = fun, but the toplevel frame won't put itself so that the cursor appears in the middle (I have to scroll down -- test with a bigger function, of course :-P ) The problem appears with emacs, but not with Xemacs. This is minor, mostly cosmetic but annoying. Thanks in advance, keep up the good packaging work :-) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages tuareg-mode depends on: ii emacs21 [emacsen] 21.4a-3The GNU Emacs editor ii xemacs21-nomule [emacsen] 21.4.18-3 highly customizable text editor -- Versions of packages tuareg-mode recommends: ii ocaml 3.09.1-3 ML language implementation with a -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357255: pgfnodebox misplacement
Package: pgf
Version: 1.00-1
Severity: important
The pgf package seems to misplace \pgfnodebox{...} boxes (or arrows)
when defining nodes and connecting them. The problem is easy to
reproduce, here is an example:
%
\documentclass[a4paper,12pt]{article}
\usepackage[T1]{fontenc}
\usepackage{pgf}
\begin{document}
\begin{pgfpicture}
\pgfsetxvec{\pgfpoint{8cm}{0cm}}
\pgfsetyvec{\pgfpoint{0cm}{8cm}}
\pgfnodebox{ltype}[virtual]{\pgforigin}{$\lambda_{\rightarrow}$}{1pt}{1pt}
\pgfnodebox{lpi}[virtual]{\pgfrelative{\pgfxy(1,0)}{\pgfnodecenter{ltype}}}{$\lambda
\Pi $}{1pt}{1pt}
\pgfnodebox{lombarre}[virtual]{\pgfrelative{\pgfxy(0.3,0.3)}{\pgfnodecenter{ltype}}}{$\lambda{\underline{\omega}}$}{1pt}{1pt}
\pgfnodebox{lpiombarre}[virtual]{\pgfrelative{\pgfxy(1.3,0.3)}{\pgfnodecenter{ltype}}}{$\lambda\Pi{\underline{\omega}}$}{1pt}{1pt}
\pgfnodebox{sysF}[virtual]{\pgfrelative{\pgfxy(0,1)}{\pgfnodecenter{ltype}}}{$F$}{1pt}{1pt}
\pgfnodebox{lpi2}[virtual]{\pgfrelative{\pgfxy(1,1)}{\pgfnodecenter{ltype}}}{$\lambda
\Pi 2$}{1pt}{1pt}
\pgfnodebox{Fom}[virtual]{\pgfrelative{\pgfxy(0.3,1.3)}{\pgfnodecenter{ltype}}}{$F_{\omega}$}{1pt}{1pt}
\pgfnodebox{CC}[virtual]{\pgfrelative{\pgfxy(1.3,1.3)}{\pgfnodecenter{ltype}}}{$\lambda
C$}{1pt}{1pt}
\pgfsetendarrow{\pgfarrowto}
\pgfnodeconnline{ltype}{lombarre}
\pgfnodeconnline{ltype}{lpi}
\pgfnodeconnline{ltype}{sysF}
\pgfnodeconnline{lpi}{lpiombarre}
\pgfnodeconnline{lpi}{lpi2}
\pgfnodeconnline{lombarre}{lpiombarre}
\pgfnodeconnline{lombarre}{Fom}
\pgfnodeconnline{lpiombarre}{CC}
\pgfnodeconnline{sysF}{Fom}
\pgfnodeconnline{sysF}{lpi2}
\pgfnodeconnline{lpi2}{CC}
\pgfnodeconnline{Fom}{CC}
\end{pgfpicture}
\end{document}
%
The Changelog of pgf-1.01 on sourceforge mentions a bugfix for
misplaced boxes in compatibility mode. I will try to see if this bug
is indeed the culprit, but I guess it is a good idea to put the pgf
package in sync with the latest upstream version.
Thanks in advance.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages pgf depends on:
ii latex-xcolor 2.00-2 Easy driver-independent TeX class
ii tetex-base3.0-15 Basic library files of teTeX
pgf recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339035: sylpheed-claws-gtk2: Signature insertion as the result of a command
Package: sylpheed-claws-gtk2 Version: 1.9.14-1 Severity: normal Hello, I found what looks like a regression wrt sylpheed-claws. For an account, let us suppose I set up as a signature the result of the execution of a command : /usr/games/fortune ~/my_fortune_database Under sylpheed-claws, the command worked, whereas with sylpheed-claws-gtk2, it doesn't do anything. The problem lies probably in how such a command should be interpreted. IMHO, the command for signature insertion should be environment-aware, i.e. the command showed upper should work, as should a command such as: /usr/games/fortune $HOME/my_fortune_database which does not work either with sylpheed-claws-gtk2. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages sylpheed-claws-gtk2 depends on: ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libaspell150.60.3-5 GNU Aspell spell-checker runtime l ii libatk1.0-01.10.3-1 The ATK accessibility toolkit ii libc6 2.3.5-6 GNU C Library: Shared libraries an ii libcompfaceg1 1989.11.11-24 Compress/decompress images for mai ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [ ii libetpan3 0.39.1-1 mail handling library ii libfontconfig1 2.3.2-1 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcrypt111.2.2-1 LGPL Crypto library - runtime libr ii libglib2.0-0 2.8.3-1 The GLib library of C routines ii libgnomecanvas2-0 2.10.2-2 A powerful object-oriented display ii libgnomeprint2.2-0 2.10.3-3 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.10.2-2 GNOME 2.2 print architecture User ii libgnutls121.2.8-1 the GNU TLS library - runtime libr ii libgpg-error0 1.1-4 library for common error values an ii libgpgme11 1.1.0-1 GPGME - GnuPG Made Easy ii libgtk2.0-02.6.10-1 The GTK+ graphical user interface ii libldap2 2.1.30-12 OpenLDAP libraries ii liblockfile1 1.06 NFS-safe locking library, includes ii libpango1.0-0 1.8.2-3 Layout and rendering of internatio ii libpisock8 0.11.8-12 Library for communicating with a P ii libsasl2 2.1.19-1.7Authentication abstraction library ii libssl0.9.70.9.7g-5 SSL shared libraries ii libtasn1-2 0.2.13-1 Manage ASN.1 structures (runtime) ii libxml22.6.22-2 GNOME XML library ii zlib1g 1:1.2.3-4 compression library - runtime Versions of packages sylpheed-claws-gtk2 recommends: ii sylpheed-claws-gtk2-i18n 1.9.14-1 Locale data for Sylpheed Claws (i1 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339036: sylpheed-claws-gtk2: Actions behaviour wrt Reply or Forward commands
Package: sylpheed-claws-gtk2 Version: 1.9.14-1 Severity: wishlist Hello, I put it as a wish request, but it could be filed as a normal bug, because of a regression wrt sylpheed-claws. Let us suppose I define an action, such as rot13 encryption, as |tr a-zA-Z n-za-mN-ZA-M|. Under claws, activating this action and replying or forwarding the mail presented the composition windows with the altered text, whereas under claws-gtk2, the original text is displayed. Thus, why did I put it as a wish instead of a normal bug ? Because the documentation doesn't specify anything (at least, clearly) about what happens to the altered text when replying/forwarding in the composition window. Hence the two described behaviours are valid. Therefore I would like that either this behaviour becomes documented, or the behaviour of claws is restored, i.e. that this is the altered text that shows up in the composition window, not the original text. Thanks in advance. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages sylpheed-claws-gtk2 depends on: ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libaspell150.60.3-5 GNU Aspell spell-checker runtime l ii libatk1.0-01.10.3-1 The ATK accessibility toolkit ii libc6 2.3.5-6 GNU C Library: Shared libraries an ii libcompfaceg1 1989.11.11-24 Compress/decompress images for mai ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [ ii libetpan3 0.39.1-1 mail handling library ii libfontconfig1 2.3.2-1 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcrypt111.2.2-1 LGPL Crypto library - runtime libr ii libglib2.0-0 2.8.3-1 The GLib library of C routines ii libgnomecanvas2-0 2.10.2-2 A powerful object-oriented display ii libgnomeprint2.2-0 2.10.3-3 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.10.2-2 GNOME 2.2 print architecture User ii libgnutls121.2.8-1 the GNU TLS library - runtime libr ii libgpg-error0 1.1-4 library for common error values an ii libgpgme11 1.1.0-1 GPGME - GnuPG Made Easy ii libgtk2.0-02.6.10-1 The GTK+ graphical user interface ii libldap2 2.1.30-12 OpenLDAP libraries ii liblockfile1 1.06 NFS-safe locking library, includes ii libpango1.0-0 1.8.2-3 Layout and rendering of internatio ii libpisock8 0.11.8-12 Library for communicating with a P ii libsasl2 2.1.19-1.7Authentication abstraction library ii libssl0.9.70.9.7g-5 SSL shared libraries ii libtasn1-2 0.2.13-1 Manage ASN.1 structures (runtime) ii libxml22.6.22-2 GNOME XML library ii zlib1g 1:1.2.3-4 compression library - runtime Versions of packages sylpheed-claws-gtk2 recommends: ii sylpheed-claws-gtk2-i18n 1.9.14-1 Locale data for Sylpheed Claws (i1 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338111: zinf-plugin-alsa: lcdui time field display not updated
Package: zinf-plugin-alsa Version: 2.2.5-5.1 Severity: normal Hello, once I saw that the time display field of the lcdui failed to progress (forwards or backwards, depending whether I was in time passed or time remaining mode). I tracked down the problem to the audio output plugins : if I use the core soundcard.pmo plugin, the time field is OK, while using the alsa.pmo plugin leaves the time field frozen, showing only 0:00 (time passed mode) or the length of the song preceded by a minus sign (time remaining mode). Thus I guess the problem comes from zinf-plugin-alsa. I don't know how the other plugins (arts, esd) behave, though. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages zinf-plugin-alsa depends on: ii libasound21.0.9-3ALSA library ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-2 GCC support library ii libstdc++64.0.2-2The GNU Standard C++ Library v3 ii zinf 2.2.5-5.1 Extensible, cross-platform audio p zinf-plugin-alsa recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
