After fixing #225015 I noticed that kdenlive would not save my projects (no error at all) and I tried the workaround mentioned in comment 7 on #188626. After running "mv /usr/share/mimelnk/application/vnd.kde.kdenlive.* /usr/kde/3.5/share/mimelnk/application/" everything worked fine. btw. comment 5 on the same page is pretty much the description of the whole problem Reproducible: Always Steps to Reproduce: 1. emerge kdenlive 2. try to save a project
Created attachment 155635 [details] emerge --info
/usr/share/mimelnk/ is the correct path. Relates to bug 209371, maybe. What does `kde-config --path mime` print?
Ah, missed to assign.
(In reply to comment #3) > Ah, missed to assign. > it gives "/home/flyser/.kde3.5/share/mimelnk/:/usr/share/mimelnk/:/usr/kde/3.5/share/mimelnk/" this might be the issue: $ ls /usr/share/mimelnk/ ls: cannot open directory /usr/share/mimelnk/: Permission denied so its a different bug? should I recreate it?
ah forgot this one: # ls -ld /usr/share/mimelnk drwx------ 5 root root 4096 20. Mai 19:31 /usr/share/mimelnk
Yes, that's it. Permissions should be 755 of course. Maybe a local issue, or the first ebuilds you installed which created the path used the wrong permissions. I do not feel tempted to put such a check into kde.eclass, but you could put the following: -- if [[ "$EBUILD_PHASE" == "preinst" && -n "${KDEDIR}" && -d "${D}/usr/share" ]] ; then bashrc_temp=`find "${D}"/usr/share -type d ! -perm 755` if [[ -n "${bashrc_temp}" ]] ; then eerror "Directories found below /usr/share/ not matching permissions 775:" echo ${bashrc_temp} | tr ' ' '\n' die fi fi -- into /etc/portage/bashrc, do `qlist /usr/share/mimelnk` to find the suspectible ebuilds, and reemerge these ebuilds. But be careful, Portage bashrc is a nasty hack. ;)
Well ... I have fixed the permissions and its working now but neither `qlist /usr/share/mimilnk` nor `find /usr/share/mimelnk -exec qlist {} \;` gives any result
Sorry, meant qfile instead qlist of course.
I recompiled every item in the list, but the permissions stayed 755 so I assume the bug is closed now...
O.k., assuming local issue then.
