[lug] Tracing Permission Problems

stimits at comcast.net stimits at comcast.net
Thu Dec 10 09:28:14 MST 2015


Hi,
 
I recently installed Fedora 23 with the KDE spin. One of the applications I've added and would like to use is kicad. Unfortunately, there seems to be a package install permissions issue, or else a system permissions issue. The gist is that when the mouse hovers over an icon in kicad, the tool tip text appears...but unless I'm running as root, the color is white on white. It isn't readable.
 
I noticed that if I run OpenBox without KDE, there is no issue. Running Plasma or OpenBox on KDE causes the tool tips of kicad to ignore KDE tool tip settings. Running as root fixes the issue and tool tip colors are normal. Other applications display tool tips correctly on KDE, so I'm inclined to believe something about the kicad package installed with invalid permissions.
 
I tried to delete and rebuild all possible cache entries, including deleting my entire KDE desktop setup and starting from scratch, along with customizing specific tool tip color settings in KDE. No difference. I figured if it was a file permission, then strace might point it out. Unfortunately, after going through a LOT of log text, I never found a permission denied.
 
What I did notice under strace while moving the mouse over icons to pop up tool tip text that there were a lot of "EAGAIN" returns (resource temporarily unavailable via recvmsg calls). I did this as root as well, but never saw anything obviously limited to my non-root user. The actual data on the recvmsg calls is binary, and not visible text (perhaps it is UTF8 or UTF16 encoding), so I can't be sure any of the "resource temporarily unavailable" messages had anything to do with tool tip color.
 
I am convinced that since this only happens with kicad that KDE itself is installed with correct permissions...but how would I trace the source of kicad tool tip text color failing? Would I need to actually run a debug version of kicad in gdb? It seems like there should be something more obvious and simple to test before going to that length.
 
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20151210/11876626/attachment.html>


More information about the LUG mailing list