beside the missing /sbin path: it is a bad idea to call lspci in profile.d.  SELinux policy might prohibit execution of this command causing bogus results and ugly log messages.  Because profile.d will also be executed for forwarded x11 connections but the lspci checks local machine only, wrong values (QT_GRAPHICSSYSTEM) will be set.

1. The SELinux policy issue was already fixed, see bug #821268.
2. The check detects the cirrus hardware emulated by QEMU only.
3. It was the best thing we could do to work around bug #810161, given that our cirrus driver maintainer refuses to fix the issue which causes it. (He switched the driver from 24 bpp, which Qt supports, to 16 bpp, which Qt's default raster graphics engine does not support. He claims 24 cpp is impossible to support with llvmpipe and thus gnome-shell.)

And if you read the history of bug #810161, you'll see that we tried everything to get a proper resolution to that bug, but nobody gave a darn:
* Upstream Qt does not care at all about 16 bpp.
* The driver maintainer (ajax) wasn't of any help at all to fix the mess he caused. He didn't even try helping to fix the Qt code, nor did he reconsider his decision to switch the default bpp of cirrus.
* Fedora QA decided the issue was "only cosmetic" and thus "not a blocker" and as a result they didn't care at all. (The only concession was to declare this "Nice To Have" and thus to take a rushed workaround. NTH and non-blocker means that 1. they wouldn't have waited for a better fix and 2. they didn't do anything to coax the driver maintainer who caused the regression into fixing his mess.)

By the way, both 24 and 16 bpp are legacy modes, but the cirrus hardware does not support 32 bpp (and neither does QEMU's emulation of it). IMHO, 24 bpp is the much better mode because it's True Color and Qt fully supports it. But I guess the problem is that it's not a power of 2, which makes it harder for things like llvmpipe to work with it. Still, IMHO llvmpipe should be fixed to support 24 bpp and cirrus's default reverted, it'd help everyone, even GNOME users, because they'd get their colors back.

I do not say that grepping for 'lspci' Output is wrong. I just say it is wrong to do it at every login in /etc/profile.d.

It might be better to inject the environment variable by a script within /etc/X11/xinit/xinitrc.d.

It seems like, regardless about what ends up being done, the invocation of lspci should be absolutely qualified. The error message is pretty annoying.

Thanks I hadn't considered xinitrd.d before, that indeed could be a better alternative.

kde-settings-4.8-15.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/kde-settings-4.8-15.fc17

Package kde-settings-4.8-15.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kde-settings-4.8-15.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9374/kde-settings-4.8-15.fc17
then log in and leave karma (feedback).

I don't think that this is a KDE problem. I'm using Gnome and whenever I enter a command like

rsync -auvzC -e ssh <directory> <user>@<host>:<directory>

I get the message 

bash: lspci: Befehl nicht gefunden...

since I've installed Fedora 17.

Sure, see /etc/profile.d/qt-graphicssystem.*

Interesting to see how many people apparently don't have /usr/sbin in their $PATH (it should be there by default)

I'm sorry, but I do have /usr/sbin in my $PATH!

Even if I change /etc/profile.d/qt-graphicssystem.* and use the absolute path, i.e.

 # workarond cirrus/qt bug, http://bugzilla.redhat.com/810161
  if ( /usr/sbin/lspci | grep -qi "VGA compatible controller: Cirrus Logic GD 5446" ) ; then
    QT_GRAPHICSSYSTEM=native
    export QT_GRAPHICSSYSTEM
  fi

I get the same message.

Do you not have pciutils installed? (ie, and no /usr/sbin/lspci)?

Besides, the patched version uses:


if ( /usr/sbin/lspci 2>/dev/null | grep -qi "VGA compatible controller: Cirrus Logic GD 5446" ) ; then
...

I get for

# rpm -qa | grep pciutils
pciutils-devel-3.1.9-1.fc17.x86_64
pciutils-3.1.9-1.fc17.x86_64
pciutils-libs-3.1.9-1.fc17.x86_64

and I think 2>/dev/null only hides the error (I didn't apply the patch, I changed the code directly)

Enrico, we added this to profile.d/ so kdm would get this into it's environment, now I'm not so sure that xinitrd.d/ would help any in this case (please do correct me if I'm wrong)

Jobst, I've no explanation for your error then.  the executable is there, yet you continue to get a 'common not found' error.

I've investigated the error a little bit further and changed /etc/profile.d/qt-graphicssystem.* into 

...
  echo "before"
  echo "before" > /tmp/echo_lspci
  # workarond cirrus/qt bug, http://bugzilla.redhat.com/810161
  if ( /usr/sbin/lspci | grep -qi "VGA compatible controller: Cirrus Logic GD 5446" ) ; then
    QT_GRAPHICSSYSTEM=native
    export QT_GRAPHICSSYSTEM
  fi
  echo "after"
  echo "after" >> /tmp/echo_lspci
...

At the login into a terminal I get messages

before
after

but at executing 

rsync ...

as in comment 9 I don't get this response so I don't think the lspci message comes from /etc/profile.d/qt-graphicssystem.*. 

I don't have a clue...

qt-graphicssystem.sh looks right now, but qt-graphicssystem.csh has the wrong path (/usr/bin/lspci, should be /usr/sbin/lspci).

OK, qt-graphicssystem.csh typo should be fixed in kde-settings-4.8-16.fc17

Package kde-settings-4.8-16.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kde-settings-4.8-16.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9374/kde-settings-4.8-16.fc17
then log in and leave karma (feedback).

Perhaps you meant qt-settings, not kde-settings?


Anyway, after doing:
  # yum update --enablerepo=updates-testing qt-settings-4.8-16.fc17

I did have to manually put the files into place, as I had manually modified them:

warning: /etc/profile.d/qt-graphicssystem.csh created as /etc/profile.d/qt-graphicssystem.csh.rpmnew
warning: /etc/profile.d/qt-graphicssystem.sh created as /etc/profile.d/qt-graphicssystem.sh.rpmnew



Once manually put into place to over-ride my work-around things do seem better for me.

Thank you,
/James Hartsock

qt-settings is built as a subpackage of kde-settings, so the update is called "kde-settings" in Bodhi, but yes, you need to update the qt-settings package.

kde-settings-4.8-16.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.