Bug#635039: further data
Forgot to say that I turn off the nvidia GPU using acpi-call to extend battery life and that works. The laptop has, of course, two GPU using nvidia optimus technology. Rgds jss -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/blu0-smtp1875f5738578dfc65d54953d0...@phx.gbl
Bug#635059: libgl1-mesa-glx: incorrect renderType in GLX fbconfigs (w/ patch)
Package: libgl1-mesa-glx
Version: 7.7.1-4
Severity: important
Tags: upstream patch
GLX routines may report and use incorrect FBConfigs due to bug
in protocol parsing - renderType should not be computed from (uninitialized)
GLX_RGBA property when server sent it explicitely (with GLX 1.3+)
-- System Information:
Debian Release: 6.0.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libgl1-mesa-glx depends on:
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libdrm22.4.21-1~squeeze3 Userspace interface to kernel DRM
ii libx11-6 2:1.3.3-4 X11 client-side library
ii libxdamage11:1.1.3-1 X11 damaged region extension libra
ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar
ii libxfixes3 1:4.0.5-1 X11 miscellaneous 'fixes' extensio
ii libxxf86vm11:1.1.0-2 X11 XFree86 video mode extension l
Versions of packages libgl1-mesa-glx recommends:
ii libgl1-mesa-dri 7.7.1-4A free implementation of the OpenG
libgl1-mesa-glx suggests no packages.
-- no debconf information
--- mesa.orig/src/glx/x11/glxext.c 2011-07-21 14:47:20.719908125 +0200
+++ mesa/src/glx/x11/glxext.c 2011-07-21 14:50:53.535908287 +0200
@@ -268,6 +268,7 @@
Bool fbconfig_style_tags)
{
int i;
+ int renderTypeSet = 0;
if (!tagged_only) {
/* Copy in the first set of properties */
@@ -389,6 +390,7 @@
break;
case GLX_RENDER_TYPE:
config->renderType = *bp++;
+ renderTypeSet = 1;
break;
case GLX_X_RENDERABLE:
config->xRenderable = *bp++;
@@ -452,6 +454,7 @@
}
}
+ if (!renderTypeSet)
config->renderType =
(config->rgbMode) ? GLX_RGBA_BIT : GLX_COLOR_INDEX_BIT;
Bug#635060: libgl1-mesa-glx: libGL does not fallback to indirect rendering automatically (w/ patch)
Package: libgl1-mesa-glx
Version: 7.7.1-4
Severity: normal
Tags: upstream patch
libGL does not fallback to indirect rendering automatically when necessary,
setting LIBGL_ALWAYS_INDIRECT environment variable is usually required
(application fails with "Error: couldn't find RGB GLX visual or fbconfig"
or similar error otherwise).
The patch fixes handling of incompatible visuals and fbconfigs between
local DRI driver and remote GLX display, fallback driver is used instead
of useless empty configuration.
-- System Information:
Debian Release: 6.0.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libgl1-mesa-glx depends on:
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libdrm22.4.21-1~squeeze3 Userspace interface to kernel DRM
ii libx11-6 2:1.3.3-4 X11 client-side library
ii libxdamage11:1.1.3-1 X11 damaged region extension libra
ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar
ii libxfixes3 1:4.0.5-1 X11 miscellaneous 'fixes' extensio
ii libxxf86vm11:1.1.0-2 X11 XFree86 video mode extension l
Versions of packages libgl1-mesa-glx recommends:
ii libgl1-mesa-dri 7.7.1-4A free implementation of the OpenG
libgl1-mesa-glx suggests no packages.
-- no debconf information
--- mesa.orig/src/glx/x11/drisw_glx.c 2011-07-21 19:35:46.819907934 +0200
+++ mesa/src/glx/x11/drisw_glx.c 2011-07-21 22:35:05.767907534 +0200
@@ -349,6 +349,7 @@
psc->__driScreen = NULL;
if (psc->driver)
dlclose(psc->driver);
+ psc->driver = NULL;
}
static __GLXDRIscreen *
@@ -359,6 +360,7 @@
const __DRIconfig **driver_configs;
const __DRIextension **extensions;
const char *driverName = "swrast";
+ __GLcontextModes *visuals, *configs;
int i;
psp = Xcalloc(1, sizeof *psp);
@@ -398,10 +400,19 @@
goto handle_error;
}
+ configs = driConvertConfigs(psc->core, psc->configs, driver_configs);
+ visuals = driConvertConfigs(psc->core, psc->visuals, driver_configs);
+
+ if (configs == NULL || visuals == NULL) {
+ driDestroyScreen(psc);
+ ErrorMessageF("driver supports no visual or config\n");
+goto handle_error;
+ }
+
driBindExtensions(psc, 0);
- psc->configs = driConvertConfigs(psc->core, psc->configs, driver_configs);
- psc->visuals = driConvertConfigs(psc->core, psc->visuals, driver_configs);
+ psc->configs = configs;
+ psc->visuals = visuals;
psc->driver_configs = driver_configs;
--- mesa.orig/src/glx/x11/dri_common.c 2011-07-21 23:03:42.471907705 +0200
+++ mesa/src/glx/x11/dri_common.c 2011-07-22 09:51:46.207906621 +0200
@@ -331,7 +331,7 @@
tail = tail->next;
}
- _gl_context_modes_destroy(modes);
+ /* _gl_context_modes_destroy(modes); */
return head.next;
}
--- mesa.orig/src/glx/x11/dri_glx.c 2011-07-21 23:08:01.888032664 +0200
+++ mesa/src/glx/x11/dri_glx.c 2011-07-21 23:17:43.692033344 +0200
@@ -316,6 +316,7 @@
int junk;
const __DRIconfig **driver_configs;
__GLcontextModes *visual;
+ __GLcontextModes *visuals, *configs;
/* DRI protocol version. */
dri_version.major = driDpy->driMajor;
@@ -424,8 +425,20 @@
goto handle_error;
}
- psc->configs = driConvertConfigs(psc->core, psc->configs, driver_configs);
- psc->visuals = driConvertConfigs(psc->core, psc->visuals, driver_configs);
+ configs = driConvertConfigs(psc->core, psc->configs, driver_configs);
+ visuals = driConvertConfigs(psc->core, psc->visuals, driver_configs);
+
+ if (configs == NULL || visuals == NULL) {
+ if (configs != NULL) _gl_context_modes_destroy(configs);
+ if (visuals != NULL) _gl_context_modes_destroy(visuals);
+ ErrorMessageF("driver supports no visual or config\n");
+ goto handle_error;
+ }
+
+ _gl_context_modes_destroy(psc->configs);
+ _gl_context_modes_destroy(psc->visuals);
+ psc->configs = configs;
+ psc->visuals = visuals;
psc->driver_configs = driver_configs;
--- mesa.orig/src/glx/x11/dri2_glx.c 2011-07-21 23:23:34.147907316 +0200
+++ mesa/src/glx/x11/dri2_glx.c 2011-07-21 23:27:07.319907259 +0200
@@ -308,6 +308,10 @@
(*psc->core->destroyScreen) (psc->__driScreen);
close(psc->fd);
psc->__driScreen = NULL;
+ if (psc->driver)
+ dlclose(psc->driver);
+ psc->driver = NULL;
+
}
/**
@@ -425,6 +429,7 @@
const __GLXDRIdisplayPrivate *const pdp = (__GLXDRIdisplayPrivate *)
priv->dri2Display;
__GLXDRIscreen *psp;
+ __GLcontextModes *visuals, *configs;
char *driverName, *deviceName;
drm_magic_t magic;
int i;
@@ -496,10 +501,22 @@
goto handle_error;
}
- driBindExtensions(psc, 1);
+ configs = d
Bug#635060: libgl1-mesa-glx: libGL does not fallback to indirect rendering automatically (w/ patch)
On Fri, Jul 22, 2011 at 11:52:50 +0200, Zdenek Salvet wrote: > Package: libgl1-mesa-glx > Version: 7.7.1-4 > Severity: normal > Tags: upstream patch > > libGL does not fallback to indirect rendering automatically when necessary, > setting LIBGL_ALWAYS_INDIRECT environment variable is usually required > (application fails with "Error: couldn't find RGB GLX visual or fbconfig" > or similar error otherwise). > > The patch fixes handling of incompatible visuals and fbconfigs between > local DRI driver and remote GLX display, fallback driver is used instead > of useless empty configuration. > Is that change included upstream? If not, please update it for the current tree and send to mesa-...@lists.freedesktop.org. If yes, what's the relevant git commit? Thanks, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110722163022.ge32...@radis.liafa.jussieu.fr
Bug#79381: x11-xserver-utils: bug almost clsoed, just need a little more doc
Package: x11-xserver-utils Version: 7.5+3 Severity: normal Dear Debian developpers and maintainers, erayo@ said (in 2001) that xhost was working properly on redhat systems while logged in as root. It is not the case in squeeze. xhost user@host seems to work (which was I believe fix the complaint of the first bug reporter). The OPTIONS section of the man page is misleading. I quote: "[+]name The given name (the plus sign is optional) is added to the list allowed to connect to the X server. The name can be a host name or a user name." The important part is "The name can be a host name or a user name". This statement also appear in the next line of the man page and is incorrect since running "xhost foo" is always interpreted as the host foo. Actually even "xhost -help" reports this. One can use the complete name syntax to provide a username by running "xhost si:localuser:foo". I suggest changing the man page to reflect this such as: "The name can be a host name or a complete name (see NAMES for more details)." I also believe adding an example of the syntax "xhost + si:localuser:foo" or a hint of its existance in the section NAMES would be useful. Adding a sentence such as : "The server interpreted addresses can also be used to specify a local user using si:localuser:login." before the "For more information on the available forms of server interpreted addresses, see the Xsecurity(7) manual page." would I believe be useful. Thank you Erik -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages x11-xserver-utils depends on: ii cpp 4:4.4.5-1 The GNU C preprocessor (cpp) ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libx11-6 2:1.3.3-4 X11 client-side library ii libxau6 1:1.0.6-1 X11 authorisation library ii libxaw7 2:1.0.7-1 X11 Athena Widget library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxi62:1.3-6X11 Input extension library ii libxmu6 2:1.0.5-2 X11 miscellaneous utility library ii libxmuu1 2:1.0.5-2 X11 miscellaneous micro-utility li ii libxrandr22:1.3.0-3 X11 RandR extension library ii libxrender1 1:0.9.6-1 X Rendering Extension client libra ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii libxxf86vm1 1:1.1.0-2 X11 XFree86 video mode extension l x11-xserver-utils recommends no packages. Versions of packages x11-xserver-utils suggests: pn cairo-5c (no description available) pn nickle (no description available) ii xorg-docs-core1:1.5-1Core documentation for the X.org X -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110722170009.3816.83273.report...@powell.bmi.ohio-state.edu
Bug#79381: x11-xserver-utils: bug almost clsoed, just need a little more doc
On Fri, Jul 22, 2011 at 13:00:09 -0400, Erik Saule wrote: > Package: x11-xserver-utils > Version: 7.5+3 > Severity: normal > > > Dear Debian developpers and maintainers, > > erayo@ said (in 2001) that xhost was working properly on redhat > systems while logged in as root. It is not the case in squeeze. > > xhost user@host seems to work (which was I believe fix the complaint > of the first bug reporter). > > The OPTIONS section of the man page is misleading. I quote: > > "[+]name The given name (the plus sign is optional) is added to the > list allowed to connect to the X server. The name can be a host name > or a user name." > > The important part is "The name can be a host name or a user > name". This statement also appear in the next line of the man page and > is incorrect since running "xhost foo" is always interpreted as the > host foo. Actually even "xhost -help" reports this. > > One can use the complete name syntax to provide a username by running > "xhost si:localuser:foo". > > I suggest changing the man page to reflect this such as: > > "The name can be a host name or a complete name (see NAMES for more > details)." > > I also believe adding an example of the syntax "xhost + > si:localuser:foo" or a hint of its existance in the section NAMES > would be useful. Adding a sentence such as : "The server interpreted > addresses can also be used to specify a local user using > si:localuser:login." before the "For more information on the available > forms of server interpreted addresses, see the Xsecurity(7) manual > page." would I believe be useful. > Sounds like useful suggestions to me. Would you be willing to write a patch against the manpage and send it to xorg-de...@lists.x.org for review? Thanks, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110722173833.gf32...@radis.liafa.jussieu.fr
Bug#79381: x11-xserver-utils: bug almost clsoed, just need a little more doc
> > I suggest changing the man page to reflect this such as: > > > > [...] > > > Sounds like useful suggestions to me. Would you be willing to write a > patch against the manpage and send it to xorg-de...@lists.x.org for > review? I never wrote man pages before. But there is a start for everything :) I will have a look at it. -- Dr Erik Saule Post Doc in BioMedical Informatics in OSU +1 (614) 366-2438 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110722174948.ga5...@powell.bmi.ohio-state.edu
Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations
On Thu, Jul 21, 2011 at 19:11:56 +0200, Andreas Beckmann wrote: > Hi, > > currently there are multiple vendor implementations for > libGL.so.1/libglx.so and soon there will be vendor implementations for > libEGL.so.1/libGLES*.so.*, too. > The GL part is currently being handled by diversions and alternatives, > and the upcoming EGL part is planning to do this similar. > Unfortunately the diversions require quite some knowledge about the > files shipped by the MESA packages. > Therefore I suggest the following new layout to be used by the MESA > packages to simplify diversions and alternatives: > So in principle I dislike the idea of making the mesa packages messier to make the closed driver packages' life easier. One thing that's been a source of countless bug in the current system is diversions, because they're evil, and people keep getting them wrong, and users don't understand/expect them, and all kinds of fun ensues. If mesa were to not ship the /usr/lib/$arch/libGL.so.1 (and friends) symlink, but instead ship an alternative itself, would that be enough to put an end to the diversions? Not that I think alternatives are ideal either, but if we're going to have to put up with something I'd rather it wasn't *both* alternatives and diversions. Not sure what other X people think. Cheers, Julien -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110722183025.gh32...@radis.liafa.jussieu.fr
Bug#635109: xauth: needs cookie handling warnings in man page
package: xauth severity: normal version: 1:1.0.6-1 tags: security,patch Insecure xauth usage has lead to a few security bugs (#526678, #529306, #625868, and probably others instances that haven't been discovered yet). Man page warnings may guide maintainers toward more secure usages. See attached patch for a possible solution. Best wishes, Mike diff -u xauth-1.0.6/debian/changelog xauth-1.0.6/debian/changelog --- xauth-1.0.6/debian/changelog +++ xauth-1.0.6/debian/changelog @@ -1,3 +1,9 @@ +xauth (1:1.0.6-1.1) unstable; urgency=low + + * Add insecure cookie handling warnings to xauth man page. + + -- Michael Gilbert Fri, 22 Jul 2011 14:48:17 -0400 + xauth (1:1.0.6-1) unstable; urgency=low * New upstream release. only in patch2: unchanged: --- xauth-1.0.6.orig/man/xauth.man +++ xauth-1.0.6/man/xauth.man @@ -90,6 +90,10 @@ A protocol name consisting of just a single period is treated as an abbreviation for \fIMIT-MAGIC-COOKIE-1\fP. +WARNING: This usage is considered insecure since the secret magic cookie +will be displayed in command histories and for example the output of ps. +One should use the "merge" command (as described below) instead. Pay +attention to it's warning as well. .TP 8 .B "generate \fIdisplayname protocolname\fP \fR[\fPtrusted|untrusted\fR]\fP" .B \fR[\fPtimeout \fIseconds\fP\fR]\fP \fR[\fPgroup \fIgroup-id\fP\fR]\fP \fR[\fBdata \fIhexdata\fR] @@ -155,6 +159,11 @@ the \fInmerge\fP command is used, the numeric format given in the description of the \fIextract\fP command is used. If a filename consists of just a single dash, the standard input will be read if it hasn't been read before. + +WARNING: Be careful with the single dash version as depending on the +command chain (for example a combination using sudo), the secret key +could be exposed to prying eyes in command histories and for example +in the output of ps. .TP 8 .B "remove \fIdisplayname\fR..." Authorization entries matching the specified displays are removed from the
Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations
Julien Cristau (22/07/2011): > So in principle I dislike the idea of making the mesa packages messier > to make the closed driver packages' life easier. One thing that's been > a source of countless bug in the current system is diversions, because > they're evil, and people keep getting them wrong, and users don't > understand/expect them, and all kinds of fun ensues. If mesa were to > not ship the /usr/lib/$arch/libGL.so.1 (and friends) symlink, but > instead ship an alternative itself, would that be enough to put an end > to the diversions? Not that I think alternatives are ideal either, but > if we're going to have to put up with something I'd rather it wasn't > *both* alternatives and diversions. > > Not sure what other X people think. I'd rather avoid the mess of diversions *AND* alternatives indeed. If adding alternative support to mesa is the price to pay, I guess we could work something out. Please note I'm very busy right now, consequently far behind on anything X-related; sorry for that. Mraw, KiBi. signature.asc Description: Digital signature
xorg: Changes to 'ubuntu'
debian/changelog |9 +
debian/control |1 -
2 files changed, 9 insertions(+), 1 deletion(-)
New commits:
commit 3b637af274603c0b4fbc66fd495e5795bbb09633
Author: Bryce Harrington
Date: Fri Jul 22 13:34:05 2011 -0700
Drop xdiagnose as a direct dependency of xorg
Since it depends on gtk, this pulls gtk in for kubuntu which they
dislike. This will exclude derivative distros from X diagnostics,
unless xdiagnose is manually installed.
diff --git a/debian/changelog b/debian/changelog
index d6b1dbf..ea7a16b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+xorg (1:7.6+7ubuntu6) oneiric; urgency=low
+
+ * debian/control: Remove Recommends on xdiagnose as well; apparently it
+still causes gtk3 to be included for kubuntu. Derivitive distros will
+need to opt-in with their seeds if they wish to have X diagnostics
+included.
+
+ -- Bryce Harrington Fri, 22 Jul 2011 13:30:15 -0700
+
xorg (1:7.6+7ubuntu5) oneiric; urgency=low
* debian/control: Move xdiagnose dependency to ubuntu-desktop.
diff --git a/debian/control b/debian/control
index 2e69ccd..1363381 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,6 @@ Package: x11-common
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}, lsb-base (>= 1.3-9ubuntu2)
-Recommends: xdiagnose
Description: X Window System (X.Org) infrastructure
x11-common contains the filesystem infrastructure required for further
installation of the X Window System in any configuration; it does not
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qkms9-0004h3...@vasks.debian.org
xorg: Changes to 'ubuntu'
debian/changelog |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
New commits:
commit f03328fe66ae59da131dde14437dee08b8fa7456
Author: Bryce Harrington
Date: Fri Jul 22 13:37:27 2011 -0700
Sp.
diff --git a/debian/changelog b/debian/changelog
index ea7a16b..73fb79e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,9 @@
xorg (1:7.6+7ubuntu6) oneiric; urgency=low
* debian/control: Remove Recommends on xdiagnose as well; apparently it
-still causes gtk3 to be included for kubuntu. Derivitive distros will
+still causes gtk3 to be included for kubuntu. Derivative distros will
need to opt-in with their seeds if they wish to have X diagnostics
-included.
+included, or users will have to manually install xdiagnose themselves.
-- Bryce Harrington Fri, 22 Jul 2011 13:30:15 -0700
commit e37c5fc67f8508b250a0282864f869c6fa57d660
Author: Bryce Harrington
Date: Fri Jul 22 13:34:05 2011 -0700
Drop xdiagnose as a direct dependency of xorg
Since it depends on gtk, this pulls gtk in for kubuntu which they
dislike. This will exclude derivative distros from X diagnostics,
unless xdiagnose is manually installed.
diff --git a/debian/changelog b/debian/changelog
index d6b1dbf..ea7a16b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+xorg (1:7.6+7ubuntu6) oneiric; urgency=low
+
+ * debian/control: Remove Recommends on xdiagnose as well; apparently it
+still causes gtk3 to be included for kubuntu. Derivitive distros will
+need to opt-in with their seeds if they wish to have X diagnostics
+included.
+
+ -- Bryce Harrington Fri, 22 Jul 2011 13:30:15 -0700
+
xorg (1:7.6+7ubuntu5) oneiric; urgency=low
* debian/control: Move xdiagnose dependency to ubuntu-desktop.
diff --git a/debian/control b/debian/control
index 2e69ccd..1363381 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,6 @@ Package: x11-common
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}, lsb-base (>= 1.3-9ubuntu2)
-Recommends: xdiagnose
Description: X Window System (X.Org) infrastructure
x11-common contains the filesystem infrastructure required for further
installation of the X Window System in any configuration; it does not
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qkmtf-0004kb...@vasks.debian.org
Bug#635137: Sometimes hangs after suspend & resume
Package: compiz Version: 0.8.4-4 Severity: important After suspending and resuming my laptop (Thinkpad T61 with Intel GM965 GPU) compiz sometimes appears to hang, leaving the X display blank except for the mouse pointer. The kernel, GPU and X server are still working: the mouse pointer is responsive and I can switch between virtual consoles. I can recover by stopping compiz (kill -9) and starting it again. Next time this happens, I will try to attach to compiz with gdb. It might be helpful to build a debug symbol package so that I can provide more details. Ben. -- System Information: Debian Release: wheezy/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'oldstable-proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages compiz depends on: ii compiz-core 0.8.4-4OpenGL window and compositing mana ii compiz-gnome 0.8.4-4OpenGL window and compositing mana ii compiz-gtk0.8.4-4OpenGL window and compositing mana ii compiz-plugins0.8.4-4OpenGL window and compositing mana compiz recommends no packages. Versions of packages compiz suggests: ii compizconfig-settings-manager 0.8.4-2Compizconfig Settings Manager -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011071127.15192.32358.reportbug@localhost
