Bug 827440

Summary: qt-settings does NOT fully quallify path to lspci in /etc/profile.d/qt-graphicssystem.{csh,sh}
Product: [Fedora] Fedora Reporter: James Hartsock <hartsjc>
Component: kde-settingsAssignee: Rex Dieter <rdieter>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 17CC: andersk, ezyang, itamar, j.hoffmann, jreznik, kevin, ltinkl, mwoehlke.floss, rdieter, rh-bugzilla, rnovacek, smparrish, than
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-02 22:30:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description James Hartsock 2012-06-01 13:45:38 UTC
First Component qt-setting not found, so used qt.

Description of problem:

When using ssh,scp,rsync (via ssh) the following message is produced:
  /etc/profile.d/qt-graphicssystem.sh: line 7: lspci: command not found

Version-Release number of selected component (if applicable):
  Fedora 17

How reproducible:

Steps to Reproduce:
  $ ssh -q ale /bin/true
  /etc/profile.d/qt-graphicssystem.sh: line 7: lspci: command not found

  With PackageKit-command-not-found RPM installed
  $ ssh -q localhost /bin/true
  bash: lspci: command not found...

Actual results:
  Receive error:
    /etc/profile.d/qt-graphicssystem.sh: line 7: lspci: command not found

Expected results:
  No output should be produced

Additional info:

Showing version installed, and rep
$ ssh -q ale "yum list qt-settings"
/etc/profile.d/qt-graphicssystem.sh: line 7: lspci: command not found
Loaded plugins: langpacks, presto, priorities, refresh-packagekit
Installed Packages
qt-settings.noarch                4.8-13.fc17                    @anaconda-0

Showing that it is currently clean RPM
$ ssh -q ale "rpm -Vv qt-settings"
/etc/profile.d/qt-graphicssystem.sh: line 7: lspci: command not found
.........  c /etc/Trolltech.conf
.........  c /etc/profile.d/qt-graphicssystem.csh
.........  c /etc/profile.d/qt-graphicssystem.sh
.........    /usr/share/doc/qt-settings-4.8
.........  d /usr/share/doc/qt-settings-4.8/COPYING

And yes lspci is installed
$ ssh -q ale "rpm -qf /usr/sbin/lspci"
/etc/profile.d/qt-graphicssystem.sh: line 7: lspci: command not found

Fully qualifing lspci in the file does resolve the error message.

Comment 1 Enrico Scholz 2012-06-03 19:27:51 UTC
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.

Comment 2 Kevin Kofler 2012-06-03 20:57:07 UTC
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.)

Comment 3 Kevin Kofler 2012-06-03 21:09:36 UTC
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.

Comment 4 Enrico Scholz 2012-06-03 23:33:09 UTC
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.

Comment 5 Edward Z. Yang 2012-06-10 21:02:04 UTC
It seems like, regardless about what ends up being done, the invocation of lspci should be absolutely qualified. The error message is pretty annoying.

Comment 6 Rex Dieter 2012-06-10 21:04:24 UTC
Thanks I hadn't considered xinitrd.d before, that indeed could be a better alternative.

Comment 7 Fedora Update System 2012-06-13 15:39:30 UTC
kde-settings-4.8-15.fc17 has been submitted as an update for Fedora 17.

Comment 8 Fedora Update System 2012-06-15 00:22:55 UTC
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:
then log in and leave karma (feedback).

Comment 9 Jobst Hoffmann 2012-06-18 20:24:20 UTC
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.

Comment 10 Rex Dieter 2012-06-18 20:27:03 UTC
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)

Comment 11 Jobst Hoffmann 2012-06-18 20:42:36 UTC
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

I get the same message.

Comment 12 Rex Dieter 2012-06-18 21:07:07 UTC
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

Comment 13 Jobst Hoffmann 2012-06-18 21:14:33 UTC
I get for

# rpm -qa | grep pciutils

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

Comment 14 Rex Dieter 2012-06-18 21:26:55 UTC
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.

Comment 15 Jobst Hoffmann 2012-06-19 06:25:50 UTC
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
  echo "after"
  echo "after" >> /tmp/echo_lspci

At the login into a terminal I get messages


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...

Comment 16 Anders Kaseorg 2012-06-29 02:03:32 UTC
qt-graphicssystem.sh looks right now, but qt-graphicssystem.csh has the wrong path (/usr/bin/lspci, should be /usr/sbin/lspci).

Comment 17 Rex Dieter 2012-06-29 16:40:32 UTC
OK, qt-graphicssystem.csh typo should be fixed in kde-settings-4.8-16.fc17

Comment 18 Fedora Update System 2012-06-30 22:00:50 UTC
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:
then log in and leave karma (feedback).

Comment 19 James Hartsock 2012-07-02 04:35:11 UTC
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

Comment 20 Kevin Kofler 2012-07-02 08:41:21 UTC
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.

Comment 21 Fedora Update System 2012-07-02 22:30:12 UTC
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.