Bug#639656: xorg-server: debian/rules references unknown configuration options
Package: src:xorg-server Followup-For: Bug #639656 With versions 1.11.99.*, the --enable-mitshm option is documented correctly in './configure --help'. One issue resolved. You still seem to be pondering the issue with the docs, so maybe you want to leave this bug open? (If not, I consider this resolved.) Thanks, Dave W. -- 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/20120113195949.7496.90115.reportbug@localhost.localdomain
Bug#639656: xorg-server: debian/rules references unknown configuration options
Source: xorg-server Version: 1.11.0-1 Severity: minor I do my own local builds of the X stack, and I have been noticing warnings like this when building the X server for a while: configure: WARNING: unrecognized options: --disable-builddocs, --disable-xcalibrate Curious, I investigated a little: $ ./configure --help | grep -- -docs --enable-docs Enable building the documentation (default: yes) --enable-devel-docs Enable building the developer documentation $ ./configure --help | grep calibrate There is no output in the second case. Looking in debian/rules, I see confflags += \ [...] --disable-builddocs \ [...] --enable-mitshm \ [...] --disable-xcalibrate \ [...] It looks like the rules file has gotten a bit crufty over time, and --disable-builddocs should be replaced by --disable-docs and --disable-devel-docs, and --disable-xcalibrate should be dropped. I left --enable-mitshm quoted there because './configure --help' doesn't mention such an option (instead it mentions --disable-shm), but reading the 'configure' script itself reveals that --enable-mitshm is correct (and there is no such thing as --enable-shm). Does the X Strike Force know anything about this last issue? Would you like me to report it upstream as a bug in the help text, or is it not a bug? HTH, Dave W. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (350, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.2-1dwlocal (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20110829005852.24113.8353.reportbug@localhost.localdomain
Bug#617739: xorg: xdm fails to start X during boot
Peter, Looks like you'll have a quick fix! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617208 HTH, Dave W. -- 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/4d7988a7.70...@sbcglobal.net
Bug#614512: FTBFS in version 8.0.1-2
Source: mesa-demos
Version: 8.0.1-2
Severity: minor
Tags: patch
I am getting a FTBFS when making a local build of mesa-demos using
version 8.0.1-2. I was able to build 8.0.1-1 from your git repo on
Feb. 6 (before it was released), but my latest build attempt failed.
I was able to resolve the problem after doing a bit of research. I
found that 'xeglgears.c' and 'xeglthreads.c' (in 'src/egl/opengl') both
depend on libX11, and 'xeglthreads.c' also depends on libpthreads.
This apparently is a problem that has struck mesa-demos in the past,
before its sources were separated from mesa itself this past year. I
found this online info, for example:
http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg12679.html
I marked the severity as minor because I have a massively altered
graphics stack installed -- many packages built locally instead of
obtained from Debian servers -- and the problem may only affect me.
IOW, you may wish to dismiss this report out of hand.
My purpose of filing the bug is to provide an early warning to the
Debian XSF in case something has changed recently that is uncovering an
underlying bug. As I mentioned before, I was able to build mesa-demos
before; tonight I could not.
I have attached a patch using 'reportbug -A'. (If that fails to work,
let me know, and I will resend it.) It is a two-liner which adds
*_LDADD specs for xegl{gears,threads} in 'Makefile.am' (dir:
'src/egl/opengl'); the build works fine for me with this patch applied.
HTH,
Dave W.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (990, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.37.1+drm2.6.38+df110216.9f4283f4.110220.desktop.kms (SMP w/4
CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u a/src/egl/opengl/Makefile.am b/src/egl/opengl/Makefile.am
--- a/src/egl/opengl/Makefile.am 2010-07-07 13:57:15.0 -0400
+++ b/src/egl/opengl/Makefile.am 2011-02-21 19:55:40.0 -0500
@@ -67,3 +67,6 @@
eglgears_x11_LDADD = ../eglut/libeglut_x11.la
egltri_x11_LDADD = ../eglut/libeglut_x11.la
+
+xeglgears_LDADD = $(X11_LIBS)
+xeglthreads_LDADD = $(X11_LIBS) -lpthread
Bug#572405: crashes X when compiz is started
Package: xserver-xorg-video-radeonhd Version: 1.3.0-0+git6387ab4c-091112+vidabi7 Severity: normal I am not a Debian Maintainer or a Debian Developer, but I _am_ a Debian user who has been experimenting with 2D/3D acceleration and kernel mode setting with Radeon HD 4850 since November. Please be aware that radeonhd seems to be dead or dying, and many distributions are proactively steering their users away from radeonhd. The radeon driver (Debian package: xserver-xorg-radeon; upstream source: xf86-video-radeon) is being developed at a very high rate, and it supports mostly feature-complete 2D/3D acceleration on r600 (Radeon HD 4XXX) hardware. Also, radeon supports kernel mode setting (KMS) where radeonhd does not; all Linux distributions are rapidly moving toward KMS, which is a Very Good Thing. The graphics corruption you are describing on HD 4850 when using HD 4850 is known: http://bugs.freedesktop.org/show_bug.cgi?id=25309 The radeonhd lacked the hardware to test and troubleshoot, and lacked the developer worker-hours even if they had the hardware, back when I reported this bug. The unidentified card log spam is harmless. Neither radeon nor radeonhd currently can access more video RAM than is mapped by the PCI bar. Support for unmapped VRAM is in the works, and may appear in kernel 2.6.34; failing that, I expect it to arrive by 2.6.35... unless unforeseen problems delay it longer. Compiz should work well on radeon. My advice is for you to get a kernel with KMS support enabled, a new enough libdrm with support for radeon DRM enabled, and mesa and radeon built against that new-enough libdrm-dev package. These are all available in Debian experimental and unstable thanks to recent efforts by the Debian X Strike Force, especially Brice Goglin. You should be much happier with this combination of packages than you are right now! HTH, Dave W. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (350, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33-drt100223-383be5d.100225.desktop.kms (SMP w/4 CPU cores; PREEMPT) 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 xserver-xorg-video-radeonhd depends on: ii libc62.10.2-6Embedded GNU C Library: Shared lib ii libdrm2 2.4.18+dw2.6.32.9+drt-1 Userspace interface to kernel DRM ii libpciaccess00.11.0-1Generic PCI access library for X ii xserver-xorg-cor 2:1.7.5-0upstream Xorg X server - core server -- 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/20100304033801.8199.46664.report...@localhost.localdomain
Bug#570045: x11proto-gl-dev: Version 1.4.11 available
Package: x11proto-gl-dev Version: 1.4.10-1 Severity: wishlist Just a heads up: people wanting to build Mesa from the upstream git tree will be needing a newer version of glproto: checking Xm/PrimitiveP.h usability... configure: error: Package requirements (glproto = 1.4.11) were not met: Requested 'glproto = 1.4.11' but version of GLProto is 1.4.10 Found that out today when trying to cure the heckling I was getting from kernel 2.6.33-rc8 about the latest Debian packages in upstream and experimental: radeon: You have old broken userspace please consider updating mesa xf86-video-ati Geez, those Debian packages were only a few days old! ;) This is just a heads up, though, and not a request for an update: I don't need an updated package for myself because I was able to quickly and easily make my own DEB of 1.4.11 by using the 'debian' directory from your 1.4.10 sources. Thanks, Dave W. -- 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/20100216032901.16826.75772.report...@localhost.localdomain
Bug#569919: compizconfig-settings-manager: Please remove recommends dependency on python-sexy
Package: compizconfig-settings-manager Version: 0.8.4-1 Severity: minor Package 'python-sexy' has been removed from unstable: http://bugs.debian.org/568546 Please update the dependencies for 'ccsm'. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (350, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33-rc8-git.100213.desktop.kms (SMP w/4 CPU cores; PREEMPT) 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 compizconfig-settings-manager depends on: ii librsvg2-common 2.26.0-1 SAX-based renderer library for SVG ii python2.5.4-9An interactive high-level object-o ii python-compizconfig 0.8.4-2Compizconfig bindings for python ii python-gtk2 2.16.0-2 Python bindings for the GTK+ widge ii python-support1.0.6 automated rebuilding support for P Versions of packages compizconfig-settings-manager recommends: ii python-sexy 0.1.9-1+b1 python language bindings for libse compizconfig-settings-manager suggests no packages. -- 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/20100215032343.14123.10824.report...@localhost.localdomain
[kudos] Radeon HD 4850 (r600) 2D/3D acceleration now completely supported by Debian packages
I would like to thank the Debian X Strike Force for its efforts --
especially including those of the workhorses named Julien Cristau and
Brice Goglin.
I bought a Radeon HD 4850 in the fall, and began experimenting with
acceleration for the R600 GPU used in that card. Debian had no packages
which would support such acceleration back in November and December, so
I had to learn how to make DEBs from upstream sources. I cheated by
using Debianized sources from the X Strike Force, and updating patches
(or creating new ones), and generally relying on the 'debian/rules' file
from the older Debian packages.
I was having to build 'libdrm', 'mesa', 'xf86-video-ati', 'xorg-server',
and kernels for myself, with the proper support enabled for r600 GPUS.
In December, I started using kernel mode setting as well, which required
a few more alterations to my custom kernel config.
It was a real learning experience, so I'm actually glad that Debian
didn't have all of the packages I needed for several months. I'm hoping
to use what I've learned to become more seriously involved with Debian,
including bug triage, bug fixes, and (eventually) applying to be a New
Maintainer. I see how thinly stretched many (most?) of the volunteer
Teams in Debian are, and wish I was already more able to contribute on
those levels.
At any rate, I was updating from kernel 2.6.32.2 to 2.6.32.{7,8}
yesterday and today, and preparing to try out 2.6.33-rc7. Before doing
that, I thought I should try out libdrm-2.4.17 and the new radeon
package in experimental to see if they are working. I assumed there
would be problems, and was going to build more recent versions of all of
the packages I mentioned above, but after testing the latest Debian
packages of ...
xserver-xorg-video-radeon
xserver-xorg-input-evdev
xserver-common
xserver-xorg-core
libdrm2
libdrm-radeon1
libgl1-mesa-dri
libgl1-mesa-glx
libglu1-mesa
... I can't find any reason to build my own DEBs any more! Your work is
much appreciated here.
My next step is to try out 2.6.33-rc7, which has IRQ support for r600.
If things go haywire, I may have to build my own packages after all --
but after last Fall at least I know how!
Thanks,
Dave W.
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561733: libgl1-mesa-dri: Applications die due to failed DMA assertion
Package: libgl1-mesa-dri Version: 7.7~rc2-1 Severity: important There has been a bug in Mesa hitting some people since August. As an example, here is a dropping left by Extreme Tux Racer in ~/.xsession-errors after its window suddenly disappears while you are playing: Extreme TuxRacer SVN Development -- http://www.extremetuxracer.com (c) 2007 The ETRacer team (c) 2004-2005 The PPRacer team (c) 1999-2001 Jasmin F. Patryjfpa...@sunspirestudios.com ETRacer comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See http://www.gnu.org/copyleft/gpl.html for details. IRQ's not enabled, falling back to busy waits: 2 0 %%% etracer warning: Attempt to bind to Texture unloaded texture: `b-herring_run_icon' bo(0x1fee820, 4431872) is mapped (-1) can't valide it. invalid bo(0x1fee820) [0xE0357000, 0xE0358000] etracer: radeon_dma.c:210: radeonRefillCurrentDmaRegion: Assertion `dma_bo-bo-cref == 1' failed. Since November, I have been experimenting with 2D/3D acceleration using open source drivers for my Radeon HD 4850. I have been trying to help track down and provide info for all bugs which I am experiencing before I switch to experimenting with KMS. This bug is... was... the last one I was trying to solve, but it looks like it is fixed upstream now. My experiments have involved enabling r600 support in Mesa, so I was unable to report this bug on the Debian BTS because Debian's Mesa packages had such support disabled. With the recent upload of Mesa 7.7~rc2-1 (which enabled r600 support) this bug can now be reported here. All versions of Mesa I have used with r600 -- either self-built or from Debian servers -- have exhibited this bug, including 7.7~rc2. Last night I built my own DEBs of 7.7-rc3: they failed as well, with ETRacer dying the same way. Today, I updated my Mesa git repo and found this commit: commit 1c28073fdfb56a241424c739b57845f47fa05002 Author: Dave Airlie airl...@redhat.com Date: Thu Dec 17 14:19:27 2009 +1000 radeon: drop assert accessing cref which is meant to be hidden There had been some earlier commits on Nov. 24 which looked promising, so I have been patching my local Mesa builds with those as well. I rebuilt 7.7-rc3 patched with two commits -- bd13e6e5... and 1c28073... (was trying for 2176b3e... as well, but other recent changes significantly altered the code it would have applied to) -- and built new DEBs from that. Now ETRacer runs as much as I want without dying! I believe that some (all?) of the Debian X Strike Force also works on Ubuntu. If that is correct -- and if this commit works as well for everyone else as it does for me -- then you will want to pass the news along to the readers of this Launchpad bug report, https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/459961 and the fellow who posted comment #24 here: https://bugs.launchpad.net/ubuntu/+source/celestia/+bug/30970 I emailed David Airlie to thank him for this commit, and provided him with, more or less, the same info. This included reference to this upstream freedesktop.org bug report which also may be solved by the new commit: https://bugs.freedesktop.org/show_bug.cgi?id=23781 Please note this Debian 'extremetuxracer' bug report may be involved with this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557750 Compare the OP's error message warning about the unloaded texture to the error messages I quoted at the top. I will post a reply to that bug report after I send this report, but there will be nothing that user can test (for now) unless provided with a patched version of Mesa. HTH, Dave Witbrodt -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561058: libgl1-mesa-dri: libdrm dependency needs updating
Package: libgl1-mesa-dri Version: 7.7~rc2-1 Severity: minor Tags: patch First, I would like to thank the Debian X Strike Force for this release of Mesa, which includes r600 support. Over the past 6 weeks I have been experimenting with building my own DEBs of Mesa from upstream, because until recently the version of Mesa in Debian unstable was not including r600 support. (I have a Radeon RV770 GPU, so I've been playing around with getting accelerated 2D/3D working in X.) Now, please forgive my reporting of this bug against 'libgl1-mesa-dri': I really wanted to file against the 'mesa' source package itself. (I couldn't find any information about filing bugs against source packages, except for a couple of items in the BTS -- #560230 and #540430 -- which seem unresolved.) The first time I built custom DEBs of Mesa 7.7-rc1 (a few weeks ago), I had version 2.4.14 of 'libdrm2' installed. I am new to building DEBs, and had stolen the 'debian' directory from the Debianized sources of mesa-7.6-1 to give myself a head start. The build failed in the configure script because Mesa 7.7 had increased its libdrm dependency to 2.4.15. I built my own DEBs of libdrm 2.4.15 (also stealing the 'debian' directory from 2.4.14) first, then made the following change to 'debian/control' in the Mesa sources: diff -r a/debian/control b/debian/control 8c8 libdrm-dev (= 2.4.3) [!hurd-i386], libx11-dev, xutils-dev, --- libdrm-dev (= 2.4.15) [!hurd-i386], libx11-dev, xutils-dev, The build succeeded with the new version of libdrm, so this change seems appropriate. I also faced a problem with whitespace that caused the build to jump to my home directory looking for the next Makefile, luckily causing the build to fail. (Note to self: never keep a Makefile in the home directory!) There was a change in the Mesa sources from 7.6 to 7.7-devel that subtly caused your '03_optional-progs-and-install.patch' to stop working for me, though I see you haven't changed it... which probably means you are not seeing the same problem I did. Well, FYI, the following diff shows my changes to your patch versus your original version: diff -r mesa-7.7-rc2-dw/debian/patches/03_optional-progs-and-install.patch mesa-7.7~rc2-debian/debian/patches/03_optional-progs-and-install.patch 48,54c48,52 + @if test -n $(SUBDIRS) ; then \ + for dir in $(SUBDIRS) ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir ; $(MAKE) install) ; \ + fi \ + done \ + fi --- + @for dir in $(SUBDIRS) ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir ; $(MAKE) install) ; \ + fi \ + done This solves the issue I was having on my system, and makes the code in the install target of 'progs/Makefile' more similar to the surrounding code. Since your 7.7-rc2 incorporates more recent changes than the 7.7-rc2 I had built, I have now switched to the Debian XSF version. Thanks! One last issue to mention -- probably nothing to worry about, since I am a noob to Mesa and to building DEBs. I noticed that after the install target of 'debian/rules' is run, there are two copies of a file called 'gl.pc': one is in 'debian/tmp/usr/lib/glx/pkgconfig' and the other is in 'debian/tmp/usr/lib/pkgconfig'. Only one ends up being packaged -- the one build by the software rasterization config -- while the version created by the dri config is left unused. Now I don't truly understand what gl.pc is for but, as far as I have been able to gather, it is is used by 'pkg-config' to determine dependency information about libraries installed on the build system. Won't 'pkg-config' get confused if I want to build software against a DRI version of libGL.so, but the installed gl.pc contains dependency information about a (completely different) software rasterizing version of libGL.so? I have to plead ignorance here, and I am literally just seeking to satisfy my curiosity about this. The man page for 'pkg-config' indicates that more than one *.pc file can be used in a system for very similar libraries, so I was just wondering if it would be better to use both copies of gl.pc somehow. Thanks again to the XSF for your efforts! Dave W. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (350, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-0git091206.desktop.vesa (SMP w/4 CPU cores; PREEMPT) 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-dri depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libdrm-intel1 2.4.15-0upstream091008 Userspace interface to intel-speci ii libdrm2 2.4.15-0upstream091008 Userspace interface to kernel DRM ii libexpat1 2.0.1-6XML parsing C library - runtime li libgl1-mesa-dri recommends
Bug#559527: xserver-xorg-input-evdev: Could you modify the dependencies to reflect the need for X server 1.7.2?
Package: xserver-xorg-input-evdev Version: 1:2.3.1-1 Severity: normal I also experienced the loss of input function when upgrading to this version of evdev in experimental. I was going to git-bisect the issue today, but now I see in this bug report that the maintainers are indicating that a higher version of xserver-xorg-core is required. If that is the case, please modify 'debian/control' to enforce that dependency! Thanks, Dave W. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (350, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-rc8-0git091120.desktop.uvesafb (SMP w/4 CPU cores; PREEMPT) 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 xserver-xorg-input-evdev depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries ii xserver-xorg-core 2:1.7.0-1 Xorg X server - core server xserver-xorg-input-evdev recommends no packages. xserver-xorg-input-evdev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556435: possible missed symlink in libgl1-mesa-glx.install
Package: libgl1-mesa-glx Version: 7.0.3-7 Severity: wishlist I have been investigating the way that Debian X Strike Force packages Mesa because I needed to build a newer version of Mesa from upstream sources in order to play with 2D/3D acceleration on a Radeon RV770 GPU. (This requires that Mesa be rebuilt with r600 DRI support.) My understanding of Debian packaging protocols and workflows is limited, maybe nonexistant. However, I was eventually able to figure out how 'debian/rules' actually builds all of the sources, then installs them to 'debian/tmp', and then the *.install files are used to piece together the 19 separate DEB files produced by this Debianized source package. One of those files is 'debian/libgl1-mesa-glx.install', which contains this line: usr/lib/glx/libGL.so.* usr/lib However, there are actually 3 'libGL.so*' files/symlinks in 'debian/tmp/usr/lib/glx' after the sources are built: libGL.so libGL.so.1 libGL.so.1.2 The 'libgl1-mesa-glx.install' contents fail to match the 'libGL.so' symlink. Is this intentional? All three files/symlinks could be matched by changing 'libgl1-mesa-glx.install' to this: usr/lib/glx/libGL.so* usr/lib On my Sid machine, I actually have a symlink at '/usr/lib/libGL.so', and I'm not quite sure where it came from. (Running 'dpkg -S' on it reveals that it belongs to no package; I may have produced it accidentally while trying to rebuild the upstream sources into DEB files.) On the Lenny machine, there is no such symlink (as expected). I discovered this while looking at Mesa-7.6 sources on Sid, and I have a Lenny server box where I checked out the sources for this version. I am filing this wishlist bug from the Lenny machine because I currently have a development version of Mesa installed on the Sid machine, and didn't want an unsupported version of this package to be listed in my bug report. Also, is debian-x@lists.debian.org open to non-bug-related traffic, or is it for bugs and maintainer issues only? I have a couple of questions besides this one (which cannot even be pretended to pertain to bugs) about building and updating Mesa sources locally. HTH, Dave W. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-0git.090921.webserver.uvesafb (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/bash Versions of packages libgl1-mesa-glx depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libdrm2 2.3.1-2Userspace interface to kernel DRM ii libx11-6 2:1.1.5-2 X11 client-side library ii libxdamage1 1:1.1.1-4 X11 damaged region extension libra ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxfixes31:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l libgl1-mesa-glx recommends no packages. libgl1-mesa-glx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471738: compiz-core: Latest version resolves issue... please close this bug
Package: compiz-core Severity: normal I have installed the latest version, and '/usr/bin/compiz' seems to work fine under Xfce without having to make manual changes to the script. Nice job! The only issue I face now is #513639, the permissions problem with '/var/log/Xorg.0.log'. Once that issue is resolved, I may switch to 'compiz' as my permanent window manager. (I still haven't tested support for video playback, though, which was a showstopper for me in the past.) Thanks, Dave W. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable'), (350, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-2s13145.090321.desktop.uvesafb (SMP w/2 CPU cores; PREEMPT) 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 compiz-core depends on: ii libc6 2.9-7GNU C Library: Shared libraries ii libgl1-mesa-glx [libgl1]7.4-2A free implementation of the OpenG ii libice6 2:1.0.5-1X11 Inter-Client Exchange library ii libsm6 2:1.1.0-2X11 Session Management library ii libstartup-notification00.10-1 library for program launch feedbac ii libx11-62:1.2.1-1X11 client-side library ii libxcomposite1 1:0.4.0-3X11 Composite extension library ii libxcursor1 1:1.1.9-1X cursor management library ii libxdamage1 1:1.1.1-4X11 damaged region extension libra ii libxext62:1.0.4-1X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxinerama12:1.0.3-2X11 Xinerama extension library ii libxml2 2.7.3.dfsg-1 GNOME XML library ii libxrandr2 2:1.3.0-2X11 RandR extension library ii libxslt1.1 1.1.24-2 XSLT processing library - runtime ii mesa-utils 7.4-2Miscellaneous Mesa GL utilities Versions of packages compiz-core recommends: ii compiz-plugins0.8.2-4OpenGL window and compositing mana Versions of packages compiz-core suggests: pn nvidia-glxnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
