[Bug 1810688] Re: Snap-installed .desktop items cannot be overridden

2019-01-07 Thread Radoslaw Ejsmont
oops - wrong place - sorry :\ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1810688 Title: Snap-installed .desktop items cannot be overridden To manage notifications about this bug go to: https://b

[Bug 1810688] Re: Snap-installed .desktop items cannot be overridden

2019-01-07 Thread Radoslaw Ejsmont
The .desktop files for snaps are located in /var/lib/snapd/desktop. And their names are in the following format: snap-package-name_original- name.desktop. This explains why overrides with original-name.desktop in ~/.local/share/applications/ did not work. When renamed to snap-package- name_original

[Bug 1810688] Re: Snap-installed .desktop items cannot be overridden

2019-01-07 Thread Radoslaw Ejsmont
Hi John, thank you for the information. The .desktop files are indeed located in /var/lib/snapd/desktop. And their names are in the following format: snap-package-name_original-name.desktop. This explains why overrides with original-name.desktop in ~/.local/share/applications/ did not work. When re

[Bug 1810688] Re: Snap-installed .desktop items cannot be overridden

2019-01-07 Thread Radoslaw Ejsmont
In such a case, there should be an option to hide .desktop items for a particular app from the launcher. There are cases when fixes in .desktop items are the only sane way of fixing stuff, and the camera issue is a great example of this. That camera model is mounted upside-down in some laptop mo

[Bug 1810688] [NEW] Snap-installed .desktop items cannot be overridden

2019-01-06 Thread Radoslaw Ejsmont
Public bug reported: Snaps for GUI applications provide .desktop items via files in ${SNAP}/meta/gui/*.desktop files. These are picked up by the gnome launcher that lists them accordingly. However, unlike .desktop files from /usr/share/applications, these cannot be overridden by copying .desktop f

[Bug 810732] Re: Netatalk shows kernel panic in syslog when trying to connect to server in OS X 10.6.8. Worked fine before upgrade to ocelot

2012-02-06 Thread Radoslaw Ejsmont
I have run into exactly the same issue, yet I have a different workaround. Since I am using centralized LDAP user database I had to use uams_dhx2_pam.so. I have figured out, that disabling pam module for Samba password sync fixed the issue. I have created copies of common- auth (common-auth-nosmb)