bug#1809: 23.0.60; epa-encrypt-file corrupts files

bug#1809: 23.0.60; epa-encrypt-file corrupts files

[Juri Linkov]

Test case:

1. Create a file `test' with the following 3 lines:

Test.
Test2.
Test3.

2. Save it.

3. Call `epa-encrypt-file' to encrypt it with no key
using symmetric encryption giving the password "test".

4. Visit the file `test.gpg' using the password "test".

5. The decoded buffer has the corrupted content:

^@est.
Test2.
Test3.

where ^@ is a NULL control character.

GNU Emacs 23.0.60 (x86_64-pc-linux-gnu) of 2009-01-06

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1809: decode-coding-inserted-region corrupts files

[Juri Linkov]

Below is a shorter test case simplified from `epa-file-decode-and-insert':

1. emacs -Q

2. Evaluate

(progn
  (switch-to-buffer "test")
  (insert "Test.\nTest2.\nTest3.\n")
  (decode-coding-inserted-region
   (point-min) (point-max) "/tmp/test" t nil nil nil))

3. The first character becomes the NULL control character:

^@est.
Test2.
Test3.

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1809: decode-coding-inserted-region corrupts files

[Juanma Barranquero]

On Thu, Jan 15, 2009 at 02:12, Juri Linkov <juri@jurta.org> wrote:

> (progn
>  (switch-to-buffer "test")
>  (insert "Test.\nTest2.\nTest3.\n")
>  (decode-coding-inserted-region
>   (point-min) (point-max) "/tmp/test" t nil nil nil))

(with-temp-buffer
   (insert (make-string 20 ?.))
   (decode-coding-region 1 (point-max) 'raw-text)
   (buffer-string))

 => "^@..................."

It only happens for a string of length 20 bytes.

    Juanma

bug#1809: decode-coding-inserted-region corrupts files

[Juri Linkov]

>> (progn
>>  (switch-to-buffer "test")
>>  (insert "Test.\nTest2.\nTest3.\n")
>>  (decode-coding-inserted-region
>>   (point-min) (point-max) "/tmp/test" t nil nil nil))
>
> (with-temp-buffer
>    (insert (make-string 20 ?.))
>    (decode-coding-region 1 (point-max) 'raw-text)
>    (buffer-string))
>
>  => "^@..................."
>
> It only happens for a string of length 20 bytes.

Does this mean I was lucky discovering the exact length where the bug
manifests itself?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#1809: decode-coding-inserted-region corrupts files

[Juanma Barranquero]

On Fri, Jan 16, 2009 at 00:02, Juri Linkov <juri@jurta.org> wrote:

>> It only happens for a string of length 20 bytes.
>
> Does this mean I was lucky discovering the exact length where the bug
> manifests itself?

Yes, at least up to 10,000  :-)

For extra fun, you can try with length = 10 and multibyte chars like á, ç or ñ.

BTW, testing this I triggered an assertion failure, but it was on
redisplay_code and likely unrelated.

    Juanma


xdisp.c: 6066 => xassert (IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it)));

#0  0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
#1  0x011ff651 in w32_abort () at w32fns.c:7295
#2  0x010313b7 in set_iterator_to_next (it=0x82dc74, reseat_p=1) at xdisp.c:6066
#3  0x0103144e in set_iterator_to_next (it=0x82dc74, reseat_p=1) at xdisp.c:6113
#4  0x0103bd55 in display_line (it=0x82dc74) at xdisp.c:16926
#5  0x01040694 in try_window (window=67652100, pos={charpos = 1,
bytepos = 1}, check_margins=1) at xdisp.c:14054
#6  0x01054dc7 in redisplay_window (window=67652100,
just_this_one_p=1) at xdisp.c:13677
#7  0x01056f79 in redisplay_window_1 (window=67652100) at xdisp.c:12281
#8  0x010190f1 in internal_condition_case_1 (bfun=0x1056f53
<redisplay_window_1>, arg=67652100, handlers=47871253,
    hfun=0x1023ce8 <redisplay_window_error>) at eval.c:1559
#9  0x01048077 in redisplay_internal (preserve_echo_area=<value
optimized out>) at xdisp.c:11899
#10 0x0108ebdb in read_char (commandflag=1, nmaps=6, maps=0x82fb50,
prev_event=47888385, used_mouse_menu=0x82fc24, end_time=0x0)
    at keyboard.c:2666
#11 0x0109327a in read_key_sequence (keybuf=0x82fcc4, bufsize=30,
prompt=47888385, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9365
#12 0x010963d1 in command_loop_1 () at keyboard.c:1631
#13 0x01019376 in internal_condition_case (bfun=0x1096143
<command_loop_1>, handlers=47952065, hfun=0x108d371 <cmd_error>) at
eval.c:1511
#14 0x0108c802 in command_loop_2 () at keyboard.c:1348
#15 0x01019420 in internal_catch (tag=47948185, func=0x108c7df
<command_loop_2>, arg=47888385) at eval.c:1247
#16 0x0108d1b2 in command_loop () at keyboard.c:1327
#17 0x0108d509 in recursive_edit_1 () at keyboard.c:942
#18 0x0108d675 in Frecursive_edit () at keyboard.c:1004
#19 0x01002fb1 in main (argc=2, argv=0xa93cf8) at emacs.c:1786

bug#2416: 23.0.60; decode-coding-region

[mj]

I have been having this problem since I switched to Emacs 23 several
weeks ago. I'm using VM to read my mails. There seems to be a problem
in decode-coding-region when VM tries to decode a string. When VM
tries to decode a region or a string, it uses a temporary buffer and
basically runs the following lisp code:

(apply 'decode-coding-region (point-min) (point-max)  'us-ascii nil)

The original buffer  content would be something like this:

B7040400-12
some text here

after decode-coding-region is executed, the buffer content became:

^@7040450-12
some text here

Where ^@ is actually binary code \0 (not ascii ^ and @). There is another instance
that a string was decoded and the result is  ^@ prefixed. 

I could not reproduce this with "Emacs -Q". But it always happens when
thsoe particular messages were processed by VM. 

Strangely enough, if I inserted a few spaces at the beginning of
buffer: (one space in the following buffer)

 B7040400-12
some text here

And, the decoding was done correctly. In another instance mentioned
above, one space is not enough. I had to put several spaces to get the
decoding working. 

I saw another bug report just yesterday regarding decode-coding-region
crashing. I applied the patch, but it did not help in the
decoding. 

Please let me know if you need other information to help understand
the problem. Thanks. 

-----
Emacs version: "GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2009-01-29 on T42"

Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -I../../GnuWin32/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: chinese-big5
  default-enable-multibyte-characters: t

Major mode: Shell

Minor modes in effect:
  auto-image-file-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

bug#2416: 23.0.60; decode-coding-region

[Eli Zaretskii]

> Date: Fri, 20 Feb 2009 13:13:01 -0800 (PST)
> From: mj <mj54590@gmail.com>
> Cc: 
> 
> I have been having this problem since I switched to Emacs 23 several
> weeks ago. I'm using VM to read my mails. There seems to be a problem
> in decode-coding-region when VM tries to decode a string. When VM
> tries to decode a region or a string, it uses a temporary buffer and
> basically runs the following lisp code:
> 
> (apply 'decode-coding-region (point-min) (point-max)  'us-ascii nil)
> 
> The original buffer  content would be something like this:
> 
> B7040400-12
> some text here
> 
> after decode-coding-region is executed, the buffer content became:
> 
> ^@7040450-12
> some text here
> 
> Where ^@ is actually binary code \0 (not ascii ^ and @). There is another instance
> that a string was decoded and the result is  ^@ prefixed. 
> 
> I could not reproduce this with "Emacs -Q". But it always happens when
> thsoe particular messages were processed by VM. 

Could you please see if the problem still persists in the current CVS?
Your Emacs seems to be about a month old (Jan 29), and a couple of
related bugs were fixed in coding.c since then.

bug#2416: 23.0.60; decode-coding-region

[MJ]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

Thanks for the reply. I just tried with the latest CVS version and the
problem still persists:

"GNU Emacs 23.0.90.1 (i386-mingw-nt5.1.2600) of 2009-02-21 on T42"

On Sat, Feb 21, 2009 at 4:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Fri, 20 Feb 2009 13:13:01 -0800 (PST)
> > From: mj <mj54590@gmail.com>
> > Cc:
> >
> > I have been having this problem since I switched to Emacs 23 several
> > weeks ago. I'm using VM to read my mails. There seems to be a problem
> > in decode-coding-region when VM tries to decode a string. When VM
> > tries to decode a region or a string, it uses a temporary buffer and
> > basically runs the following lisp code:
> >
> > (apply 'decode-coding-region (point-min) (point-max)  'us-ascii nil)
> >
> > The original buffer  content would be something like this:
> >
> > B7040400-12
> > some text here
> >
> > after decode-coding-region is executed, the buffer content became:
> >
> > ^@7040450-12
> > some text here
> >
> > Where ^@ is actually binary code \0 (not ascii ^ and @). There is another
> instance
> > that a string was decoded and the result is  ^@ prefixed.
> >
> > I could not reproduce this with "Emacs -Q". But it always happens when
> > thsoe particular messages were processed by VM.
>
> Could you please see if the problem still persists in the current CVS?
> Your Emacs seems to be about a month old (Jan 29), and a couple of
> related bugs were fixed in coding.c since then.
>

[-- Attachment #2: Type: text/html, Size: 1962 bytes --]

bug#2416: 23.0.60; decode-coding-region

[Juanma Barranquero]

On Fri, Feb 20, 2009 at 22:13, mj <mj54590@gmail.com> wrote:

> (apply 'decode-coding-region (point-min) (point-max)  'us-ascii nil)
>
> The original buffer  content would be something like this:
>
> B7040400-12
> some text here
>
> after decode-coding-region is executed, the buffer content became:
>
> ^@7040450-12
> some text here
>
> Where ^@ is actually binary code \0 (not ascii ^ and @). There is another instance
> that a string was decoded and the result is  ^@ prefixed.

Could it be related to bug#1809?

(with-temp-buffer
  (insert (make-string 20 ?.))
  (decode-coding-region 1 (point-max) 'raw-text)
  (buffer-string))

=> "^@..................."

    Juanma

bug#2416: 23.0.60; decode-coding-region

[MJ]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

Juanma, thank you for the lisp code that reproduces the same problem that I
am having.

If a space is inserted at the beginning of the buffer, then the result is
correct (as stated in my bug report):

(with-temp-buffer
 (insert " ")
 (insert (make-string 20 ?.))
 (decode-coding-region 2 (point-max) 'us-ascii)
 (buffer-string))
" ...................."

(I use 'us-ascii just to show the coding does not matter).

Now, hopefully emacs developers will  be able to understand and fix the
problem.


On Sat, Feb 21, 2009 at 9:47 PM, Juanma Barranquero <lekktu@gmail.com>wrote:

> On Fri, Feb 20, 2009 at 22:13, mj <mj54590@gmail.com> wrote:
>
> > (apply 'decode-coding-region (point-min) (point-max)  'us-ascii nil)
> >
> > The original buffer  content would be something like this:
> >
> > B7040400-12
> > some text here
> >
> > after decode-coding-region is executed, the buffer content became:
> >
> > ^@7040450-12
> > some text here
> >
> > Where ^@ is actually binary code \0 (not ascii ^ and @). There is another
> instance
> > that a string was decoded and the result is  ^@ prefixed.
>
> Could it be related to bug#1809?
>
> (with-temp-buffer
>  (insert (make-string 20 ?.))
>  (decode-coding-region 1 (point-max) 'raw-text)
>  (buffer-string))
>
> => "^@..................."
>
>    Juanma
>

[-- Attachment #2: Type: text/html, Size: 1951 bytes --]

bug#2416: 23.0.60; decode-coding-region

[Juanma Barranquero]

On Sun, Feb 22, 2009 at 06:07, MJ <mj54590@gmail.com> wrote:

> If a space is inserted at the beginning of the buffer, then the result is
> correct (as stated in my bug report):

If you look at #1809, you'll see that the problem seems to be
sensitive to string length. Assuming you're using ASCII, do you see it
with strings of length != 20?

    Juanma

bug#2416: 23.0.60; decode-coding-region

[MJ]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

Indeed, including newline, the buffer length is exactly 20 bytes in two
cases where they are ascii. In another case, it's BIG5 Chinese (each BIG5
code is two bytes), and the total is also 20 bytes. Thanks for pointing it
out.

On Sun, Feb 22, 2009 at 12:13 AM, Juanma Barranquero <lekktu@gmail.com>wrote:

> On Sun, Feb 22, 2009 at 06:07, MJ <mj54590@gmail.com> wrote:
>
> > If a space is inserted at the beginning of the buffer, then the result is
> > correct (as stated in my bug report):
>
> If you look at #1809, you'll see that the problem seems to be
> sensitive to string length. Assuming you're using ASCII, do you see it
> with strings of length != 20?
>
>    Juanma
>

[-- Attachment #2: Type: text/html, Size: 1098 bytes --]

bug#2416: 23.0.60; decode-coding-region

[Juanma Barranquero]

merge 1809 2416
quit

> Indeed, including newline, the buffer length is exactly 20 bytes in two
> cases where they are ascii. In another case, it's BIG5 Chinese (each BIG5
> code is two bytes), and the total is also 20 bytes. Thanks for pointing it
> out.

OK, so this is #1809 then. I'm merging the bugs.

  Juanma

Processed: Re: bug#2416: 23.0.60; decode-coding-region

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> merge 1809 2416
bug#1809: 23.0.60; epa-encrypt-file corrupts files
bug#2416: 23.0.60; decode-coding-region
Merged 1809 2416.

> quit
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#2416: 23.0.60; decode-coding-region

[Juanma Barranquero]

On Sun, Feb 22, 2009 at 06:13, Juanma Barranquero <lekktu@gmail.com> wrote:

> If you look at #1809, you'll see that the problem seems to be
> sensitive to string length. Assuming you're using ASCII, do you see it
> with strings of length != 20?

A clue: the bug is sensitive to the value of the BUF_GAP_SIZE set in
`get-buffer-create', at buffer.c:364.

If you change

  BUF_GAP_SIZE (b) = 20;

to another size, so does the bug's triggering length.

    Juanma

bug#2416: 23.0.60; decode-coding-region

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> Could it be related to bug#1809?
>
> (with-temp-buffer
>   (insert (make-string 20 ?.))
>   (decode-coding-region 1 (point-max) 'raw-text)
>   (buffer-string))
>
> => "^@..................."

I've installed a fix.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#2416: marked as done (23.0.60; decode-coding-region)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]


Your message dated Sun, 22 Feb 2009 13:15:35 -0500
with message-id <87eixqz6bc.fsf@cyd.mit.edu>
and subject line Re: bug#1809: decode-coding-inserted-region corrupts files
has caused the Emacs bug report #1809,
regarding 23.0.60; decode-coding-region
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1809: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1809
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 5749 bytes --]

From: mj <mj54590@gmail.com>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; decode-coding-region
Date: Fri, 20 Feb 2009 13:13:01 -0800 (PST)
Message-ID: <499f1cdd.050cc00a.4267.ffffc0ce@mx.google.com>

I have been having this problem since I switched to Emacs 23 several
weeks ago. I'm using VM to read my mails. There seems to be a problem
in decode-coding-region when VM tries to decode a string. When VM
tries to decode a region or a string, it uses a temporary buffer and
basically runs the following lisp code:

(apply 'decode-coding-region (point-min) (point-max)  'us-ascii nil)

The original buffer  content would be something like this:

B7040400-12
some text here

after decode-coding-region is executed, the buffer content became:

^@7040450-12
some text here

Where ^@ is actually binary code \0 (not ascii ^ and @). There is another instance
that a string was decoded and the result is  ^@ prefixed. 

I could not reproduce this with "Emacs -Q". But it always happens when
thsoe particular messages were processed by VM. 

Strangely enough, if I inserted a few spaces at the beginning of
buffer: (one space in the following buffer)

 B7040400-12
some text here

And, the decoding was done correctly. In another instance mentioned
above, one space is not enough. I had to put several spaces to get the
decoding working. 

I saw another bug report just yesterday regarding decode-coding-region
crashing. I applied the patch, but it did not help in the
decoding. 

Please let me know if you need other information to help understand
the problem. Thanks. 

-----
Emacs version: "GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2009-01-29 on T42"

Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -I../../GnuWin32/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: chinese-big5
  default-enable-multibyte-characters: t

Major mode: Shell

Minor modes in effect:
  auto-image-file-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t




[-- Attachment #3: Type: message/rfc822, Size: 1399 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Andreas Schwab  <schwab@linux-m68k.org>
Cc: Juri Linkov <juri@jurta.org>, mj <mj54590@gmail.com>, Juanma Barranquero <lekktu@gmail.com>, 1809-done@emacsbugs.donarmstrong.com
Subject: Re: bug#1809: decode-coding-inserted-region corrupts files
Date: Sun, 22 Feb 2009 13:15:35 -0500
Message-ID: <87eixqz6bc.fsf@cyd.mit.edu>

> 2009-02-22  Andreas Schwab  <schwab@linux-m68k.org>
>
>    * insdel.c (del_range_2): Don't modify gap contents when
>      called from decode_coding_object.  (Bug#1809)

Thanks for fixing this bug.

bug#1809: marked as done (decode-coding-inserted-region corrupts files)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]


Your message dated Sun, 22 Feb 2009 13:15:35 -0500
with message-id <87eixqz6bc.fsf@cyd.mit.edu>
and subject line Re: bug#1809: decode-coding-inserted-region corrupts files
has caused the Emacs bug report #1809,
regarding decode-coding-inserted-region corrupts files
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1809: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1809
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3028 bytes --]

From: Juri Linkov <juri@jurta.org>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; epa-encrypt-file corrupts files
Date: Tue, 06 Jan 2009 19:32:12 +0200
Message-ID: <87eizgxrn8.fsf@jurta.org>

Test case:

1. Create a file `test' with the following 3 lines:

Test.
Test2.
Test3.

2. Save it.

3. Call `epa-encrypt-file' to encrypt it with no key
using symmetric encryption giving the password "test".

4. Visit the file `test.gpg' using the password "test".

5. The decoded buffer has the corrupted content:

^@est.
Test2.
Test3.

where ^@ is a NULL control character.

GNU Emacs 23.0.60 (x86_64-pc-linux-gnu) of 2009-01-06

-- 
Juri Linkov
http://www.jurta.org/emacs/



[-- Attachment #3: Type: message/rfc822, Size: 1399 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Andreas Schwab  <schwab@linux-m68k.org>
Cc: Juri Linkov <juri@jurta.org>, mj <mj54590@gmail.com>, Juanma Barranquero <lekktu@gmail.com>, 1809-done@emacsbugs.donarmstrong.com
Subject: Re: bug#1809: decode-coding-inserted-region corrupts files
Date: Sun, 22 Feb 2009 13:15:35 -0500
Message-ID: <87eixqz6bc.fsf@cyd.mit.edu>

> 2009-02-22  Andreas Schwab  <schwab@linux-m68k.org>
>
>    * insdel.c (del_range_2): Don't modify gap contents when
>      called from decode_coding_object.  (Bug#1809)

Thanks for fixing this bug.

bug#2416: 23.0.60; decode-coding-region

[MJ]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

Andreas, thank you for the quick fix, which indeed solves the problem I was
having. -- mj

On Sun, Feb 22, 2009 at 9:31 AM, Andreas Schwab <schwab@suse.de> wrote:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
> > Could it be related to bug#1809?
> >
> > (with-temp-buffer
> >   (insert (make-string 20 ?.))
> >   (decode-coding-region 1 (point-max) 'raw-text)
> >   (buffer-string))
> >
> > => "^@..................."
>
> I've installed a fix.
>
> Andreas.
>
> --
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>

[-- Attachment #2: Type: text/html, Size: 1235 bytes --]