Julien wrote:
We don't support the closed nvidia driver, sorry.
It's not a bug in the closed nvidia driver, sorry.
http://lists.x.org/archives/xorg-devel/2011-September/025062.html
Cheers,
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to
sean finney writes:
right. i suspect that the problem is not in the compiz binary but
one the libraries or plugins shipped in compiz (most likely
libcompizconfig, which is linked to by both compiz.real and ccsm)
right.
what window manager are you using? it could be that the problem
sean finney writes:
round two :)
first of all, i have to ask if you have seen my bug report against
ccsm
also ccsm dumps core on me, with the same error message, and if i hand
start compiz.real without invoking the configuration plugin, compiz
starts ok (but it doesn't do anything valuable
sean finney writes:
tags 531800 unreproducable
severity 531800 important
thanks
hi giacomo,
i can't reproduce this problem (and i'm also running 2.6.29/amd64).
i'm running an AMD cpu, but debian's architecture is i386
are you sure you don't have a compiz component installed
Package: compizconfig-settings-manager
Version: 0.8.2-2
Severity: grave
Justification: renders package unusable
when i launch ccsm, it breaks on me with the following error message
terminate called after throwing an instance of
Package: compiz-core
Version: 0.8.2-6
Severity: normal
if something goes wrong in its attempt to start compiz.real
the compiz script has a nuber of fallback options, and in my
case it goes down to the last resort of starting an xterm
alas it uses the same option that would be good for a window
Package: compiz-core
Version: 0.8.2-6
Severity: grave
Justification: renders package unusable
at the end of its grinding, the /usr/bin/compiz script tries
to execute this command
--
/usr/bin/compiz.real --ignore-desktop-hints
Package: compizconfig-settings-manager
Version: 0.8.2-1
Severity: grave
when i launch ccsm from an xterm, i read the following output
--
Backend : ini
Integration : true
Profile : default
Adding plugins
Initializing core
Julien Cristau writes:
On Wed, May 27, 2009 at 09:13:44 +0200, giacomo boffi wrote:
Package: compizconfig-settings-manager
Version: 0.8.2-1
Severity: grave
Versions of packages compizconfig-settings-manager depends on:
ii python-compizconfig 0.7.6-1
Package: compizconfig-settings-manager
Version: 0.8.2-1
Severity: normal
The bug is still present in testing
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale:
Package: xserver-xorg-core
Version: 2:1.4.2-5
Severity: wishlist
the name-color mapping mechanism built into the Xorg server is
configured at compile time to look either 1) an internal table, or 2)
the file /etc/X11/rgb.txt
at some point following
,
| commit
Package: x11-common
Version: 1:7.2-5
Severity: normal
Tags: patch
placing DebianRed in /etc/X11/rgb.txt is inane, because X does not
honor the data in that file, but only takes into account the builtin
color-names table
to be able to define new color names, you should either
change the
Giacomo Boffi writes:
Brice Goglin writes:
Hi Giacomo,
I guess this problem with the RGB database being replaced by a
static table still occurs wth latest xserver-xorg-core 1.3, right?
For the record, it looks like we could revert to the old behavior
by defining
David Nusinow writes:
I don't think that's really the method we want. Ideally, the server
will use the built-in table unless we explicitly point it to an
external file using xorg.conf. That way it just works in every
situation and no one loses.
if the rgb.txt you ship WERE ALWAYS the
Brice Goglin writes:
Hi Giacomo,
I guess this problem with the RGB database being replaced by a
static table still occurs wth latest xserver-xorg-core 1.3, right?
For the record, it looks like we could revert to the old behavior
by defining USE_RGB_BUILTIN to 0 during the build (see
Package: xserver-xorg-core
Version: 2:1.1.1-9
Followup-For: Bug #389864
to clarify the issue, i'll report to you an excerpt from
/usr/share/doc/xserver-xorg-core/changelog.gz
2006-02-15 Keith Packard [EMAIL PROTECTED]
* Makefile.am:
* Xext/Makefile.am:
[...]
Michel Dänzer writes:
On Thu, 2006-09-28 at 21:13 +0200, Giacomo Boffi wrote:
Michel Daenzer writes:
Giacomo, adding
RgbPath /etc/X11/rgb
to the xorg.conf Section Files should serve as a workaround.
sorry, but for the sake of brevity i did
Package: xserver-xorg-core
Version: 2:1.1.1-7
Severity: normal
in my debian, the X colour db is installed by x11-common, in two places,
the traditional one, /etx/X11, and the new standard, /usr/share/X11
i'm used to increment the colour db with italian names and other things
and until recently
Michel Daenzer writes:
retitle 389864 xserver-xorg-core: Default RgbPath broken
kthxbye
On Thu, 2006-09-28 at 14:18 +0200, Giacomo Boffi wrote:
5) /var/log/Xorg.0.log
[...]
(==) RgbPath set to ${prefix}/share/X11/rgb
XSF: That looks wrong...
Giacomo, adding
Package: twm
Version: 1:1.0.1-3
Severity: important
/etc/menu-methods/twm is missing from latest binary (or it is not generated
during
installation, i don't know)
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386
Package: xbase-clients
Version: 1:7.0.0-2
Severity: important
---
SUMMARY:
characters in a .Xdefaults file, when processed by cpp, ARE NOT
SYNTACTIC TOKENS, hence the NEED for the -traditional switch
Package: xutils
Version: 1:7.0.0-3
Severity: important
i got the above error message trying to xmkmf the makefile for an old window
manager --- i tried to investigate
$ apt-file search Imake.tmpl
mas-utils: usr/lib/mas/config/Imake.tmpl
ocaml-doc:
Package: xfree86-common
Version: 4.3.0-2
Severity: normal
i start X without any display manager, using startx directly from the
shell prompt
when i exit X, or i go back to the text mode console, using Alt-Fn, the
text mode is not properly restored, and i look at a mess of scrambled
chars in
23 matches
Mail list logo
