Bug 806180 – sushi doesn't start in nautilus.

Bug 806180 - sushi doesn't start in nautilus.

Summary:	sushi doesn't start in nautilus.

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	sushi (Show other bugs)
Sub Component:
Version:	17
Hardware:	x86_64 Linux

Priority	unspecified Severity high
Target Milestone:	---
Target Release:	---
Assigned To:	Elad Alfassa
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2012-03-23 02:05 EDT by sangu
Modified:	2012-10-10 00:01 EDT (History)
CC List:	2 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2012-10-10 00:01:27 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
GNOME Bugzilla	673136	None	None	None	Never

Groups: None (edit)

Description sangu 2012-03-23 02:05:01 EDT

Description of problem:
sushi doesn't start in nautilus.
or
$ sushi

(sushi-start:4664): Clutter-CRITICAL **: Unable to initialize Clutter: Unable to find suitable fbconfig for the GLX context: Failed to find any compatible fbconfigs


Version-Release number of selected component (if applicable):
0.3.92-2.fc17.x86_64


How reproducible:
always

Steps to Reproduce:
1. launch nautilus
2. move a media file (like a jpg file)
3. click space key
  
Actual results:


Expected results:


Additional info:
nautilus-3.3.92-1.fc17.x86_64
clutter-1.9.16-1.fc17.x86_64
cogl-1.10.0-1.fc17.x86_64

Comment 1 sangu 2012-03-30 01:35:46 EDT

This issue still happens in sushi 0.4.0

Comment 2 sangu 2012-04-18 21:11:08 EDT

This bug still happens in sushi-0.4.1-1.fc17.x86_64.

Maybe, sushi seem to find  wrong GL lib.

$ ldd /usr/libexec/sushi-start |grep GL
    libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f4664b62000) <-- wrorng

Because this linux system is using nvidia closed source driver. 
# ldconfig -v
/usr/lib64/nvidia:
[...]
        libGL.so.1 -> libGL.so.290.10

In another gl program.
$ ldd /usr/bin/glxgears | grep GL
    libGLEW.so.1.6 => /lib64/libGLEW.so.1.6 (0x00007fa98451a000)
    libGLU.so.1 => /lib64/libGLU.so.1 (0x00007fa9842ac000)
    libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x00007fa983f95000) <--- Rright

Comment 3 sangu 2012-04-30 21:45:07 EDT

After recent updating packages in test repo, this issue is fixed.

$ ldd /usr/libexec/sushi-start |grep GL
	libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x00007f0689006000)

Note You need to log in before you can comment on or make changes to this bug.