Qt 5.11 is in the testing repositories. I'm not a testing repo user, so this is for the information of anyone affected who is (as well as a general update to anyone affected, since the workaround will hopefully no longer be required in the not-too-distant future).
]]>I should probably file a bug report somewhere at kde.
]]>As a workaround you can do this:
Create new directory
mkdir ~/.local/share/applications/plasma_icons
Move your files from old directory to new directory
mv ~/.local/share/plasma_icons/* ~/.local/share/applications/plasma_icons
Remove old directory
rm ~/.local/share/plasma_icons
Make symlink from old directory to new directory
ln -s ~/.local/share/applications/plasma_icons ~/.local/share/plasma_icons
Now clicking on panel icon should work. You can do all those things from dolphin instead of using console.
]]>Then came another issue related to this update that disabling the cache does not fix.
When using the "add to panel (Widget)" from the applications menu, the icon is correctly added but clicking on it fails to run said application.
First it open a windows xp like warning windows telling me to click cancel if I do not trust this program which is a mild annoyance I'd be happy to disable.
Then clicking continues raises an error "Service '/home/username/.local/share/plasma_icons/firefox.desktop' must be executable to run." about the lack of execution right on the .desktop file
-edit-
removed image as issue is now fixed
-/edit-
Is someone else experiencing the same ? Any idea how to fix it ? Where should I file a bug report ?
]]>I found a bug report upstream about this (QTBUG-58508 qmlcache: apps need execution rights at every startup), however it appears the creator closed it with the workaround, so it's unclear if anything (e.g. gracefully degrading) will happen with Qt itself.
That's really unfortunate. They should handle this case more gracefully instead of just crashing.
]]>I found a bug report upstream about this (QTBUG-58508 qmlcache: apps need execution rights at every startup), however it appears the creator closed it with the workaround, so it's unclear if anything (e.g. gracefully degrading) will happen with Qt itself.
I've updated the Grsecurity, Qt and Security articles on ArchWiki under the appropriate headings; hopefully those affected in future will be able to find it there.
]]>nail wrote:arojas wrote:export QML_DISABLE_DISK_CACHE=1
Thanks. Fixed it!
I think this option should be added by default in QT 5.8.Seriously? One of the biggest selling points of Qt 5.8 should be off because it doesn't work in some very particular setups?
Ok. Maybe we can add some notes about that here https://wiki.archlinux.org/index.php/Qt#Troubleshooting ?
Because some of us don't want to remove 'noexec' option )
arojas wrote:export QML_DISABLE_DISK_CACHE=1
Thanks. Fixed it!
I think this option should be added by default in QT 5.8.
Seriously? One of the biggest selling points of Qt 5.8 should be off because it doesn't work in some very particular setups?
]]>export QML_DISABLE_DISK_CACHE=1
Thanks. Fixed it!
I think this option should be added by default in QT 5.8.
I'd like to echo @QuackDonkey's sentiments; not much point having 'noexec' or TPE available if things like Qt won't work with them. Hopefully there's a way to change the (new?) behaviour; if I can get some time in a few days I'll try and have a look (though I warn in advance that I know very little about configuring Qt).
export QML_DISABLE_DISK_CACHE=1
]]>I'd like to echo @QuackDonkey's sentiments; not much point having 'noexec' or TPE available if things like Qt won't work with them. Hopefully there's a way to change the (new?) behaviour; if I can get some time in a few days I'll try and have a look (though I warn in advance that I know very little about configuring Qt).
]]>