GNOME Bugzilla – Bug 704509
Can't install extensions from extensions.gnome.org via iceweasel in debian wheezy
Last modified: 2021-07-05 14:43:40 UTC
On debian wheezy, with iceweasel 10.0.12. If I go to extensions.gnome.org, and try to install an extension, the on/off slider moves to "on", there is a prompt if I want to install the extension, I answer yes, but then nothing happens, and nothing is created in ~/.local/share/gnome-shell/extensions. Reloading the page shows the on/off slider in "off" position. If I install an extension by hand in ~/.local/share/gnome-shell/extensions it works. I have unzip installed. My proxy is configured in both the navigator and gnome settings. Nothing is created in .xsession_errors, nor in looking glass errors. It does not appear in looking glass extension panel. I think that (what?) tries to install it to /usr/share/gnome-shell/extensions, where there already are several extensions. The problem is that this directory is "root" access, I do not have permissions on it (computer at work). Could you solve the problem, or help me identify what component is responsible for it ? My guess is that the faulty thing is the "gnome shell integration" plugin, but not sure at all. Thanks
I tried with epiphany, same problem. So this might not be linked with the browser, more with the distribution. why does it try to save it in "/usr/share/gnome-shell/extensions", and not in "~/.local/share/gnome-shell/extensions/" ?
Actually, in debian, the gnome-shell's "user extension directory" is configured to be /usr/share/gnome-shell/extensions/. As only root can access this, and I do not have the root access, installation through the plugin would never succeed. What would be cool is in gnome-shell/js/ui/extensionsSystem.js, function gotExtensionZipFile, to : - try unzip in the ExtensionUtils.userExtensionsDir (eg /usr/share/gnome-shell/extensions/ in debian) - if it does not work, try the local dir (eg ~/.local/gnome-shell/extensions/)
in newer version of Gnome-shell (3.8.3), the concerned file is gnome-shell/js/ui/extensionDownloader.js, the code to improve is in _onInstallButtonPressed that shall try to call a second time gotExtensionZipFile if failed with the first directory taken from global.userdatadir
(In reply to comment #2) > Actually, in debian, the gnome-shell's "user extension directory" is configured > to be /usr/share/gnome-shell/extensions/. As only root can access this, and I > do not have the root access, installation through the plugin would never > succeed. We write to that directory a lot, not just for extensions, so that's Debian's packaging bug.
thanks for the information. In order to solve this bug, what option do debian people need to change to package correctly gnome-shell regarding this ? can they reconfigure gnome-shell extension directory to be : ~/.local/share/gnome-shell/extensions (user access) and not : /usr/share/gnome-shell/extensions (root access) ? if they do so, how can gnome shell : - use the local directory ~/.local/share/gnome-shell/extensions - but still read the directory /usr/share/gnome-shell/extensions that contains packaged gnome-shell extensions? I'll report this to debian. Thanks
We use the standard environment variable $XDG_DATA_HOME to get the user data directory at runtime. Make sure nothing is setting that.
As of today it is still a bug. And I confirm that XDG_DATA_HOME is still not set under Debian stretch/sid, but adding this line in /etc/profile solves the problem after restarting the session: export XDG_DATA_HOME="$HOME/.local/share" So after setting that, extensions are installed nicely. Some thoughts: 1) There should be an error in $HOME/.xsession-errors when this happens - permission denied should be logged. 2) Why gnome-shell does not fallback to $GNOME/.local/share as the official specification states[1]? > $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. 3) Why debian does not set XDG_DATA_HOME? This is outside of this bug scope though. [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Edit: actually this was not the reason of extensions failing to install for me. It was for other reasons (see Bug 776940). It was mainly missing system deps. Gnome-shell actually does fallback to $HOME/.local/share.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab-test.gnome.org/fmuellner/gnome-shell-extensions/issues/105.
Sorry for the noise, I "found" a bug in the migration script: https://gitlab.gnome.org/External/bugzilla-to-gitlab-migrator/issues/2
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.