| 2008-11-10 01:18:21 |
Uwe Geuder |
bug |
|
|
added bug |
| 2008-11-10 01:20:48 |
Uwe Geuder |
description |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace if found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreet queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrwoser" in gdmsetup) |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrwoser" in gdmsetup) |
|
| 2008-11-10 01:21:57 |
Uwe Geuder |
description |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrwoser" in gdmsetup) |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in gdmsetup) |
|
| 2008-11-10 01:23:48 |
Uwe Geuder |
description |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in gdmsetup) |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to the X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in gdmsetup) |
|
| 2008-11-10 08:07:29 |
Uwe Geuder |
description |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to the X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in gdmsetup) |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be the culprit: (only lines looking important to me copied here)
open("/usr/share/X11/XErrorDB", O_RDONLY) = 6
read(6, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 37949) = 37949
close(6) = 0
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
exit_group(1)
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
(earlier)
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to the X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in gdmsetup) |
|
| 2008-11-10 08:07:29 |
Uwe Geuder |
title |
gdmgreeter exits on RandR v1.1 |
gdmgreeter exits if Xserver supports only RandR v1.1 |
|
| 2008-11-10 08:08:52 |
Uwe Geuder |
description |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be the culprit: (only lines looking important to me copied here)
open("/usr/share/X11/XErrorDB", O_RDONLY) = 6
read(6, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 37949) = 37949
close(6) = 0
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
exit_group(1)
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
(earlier)
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to the X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in gdmsetup) |
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the current v1.2) gdmgreeter exits before displaying anything. There is no error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be the culprit: (only lines looking important to me copied here)
open("/usr/share/X11/XErrorDB", O_RDONLY) = 6
read(6, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 37949) = 37949
close(6) = 0
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
exit_group(1)
However fd 2 seems to be /dev/null and I didn't find any information how to turn on logging.
(earlier)
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to the X server is RandR opcode 8. My X server replies with BadRequest. The Xserver is correct, because it supports only RandR v1.1 and opcode 8 was added for protocol version 1.2 (see http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad request, but obviously it does not use the version information appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support for the old protocol doesn't seem to be worth the effort, some better logging should be added. Alternatively, could gdmgreeter "fall back" to gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in gdmsetup) |
|
| 2008-11-10 08:11:55 |
Uwe Geuder |
title |
gdmgreeter exits if Xserver supports only RandR v1.1 |
gdmgreeter exits if remote Xserver supports only RandR v1.1 |
|
| 2009-01-14 16:33:38 |
Sebastien Bacher |
gdm: importance |
Undecided |
Medium |
|
| 2009-01-14 16:33:38 |
Sebastien Bacher |
gdm: assignee |
|
desktop-bugs |
|
| 2009-01-14 16:33:38 |
Sebastien Bacher |
gdm: statusexplanation |
|
Thank you for your bug report |
|
| 2009-07-24 11:59:08 |
Sebastien Bacher |
gdm (Ubuntu): status |
New |
Fix Released |
|
