GNOME Bugzilla – Bug 779591
Ubuntu GNOME 17.04 doesn't show gnome-shell extensions in Software 3.22.5 app
Last modified: 2017-05-04 10:38:15 UTC
Created attachment 347233 [details] log gnome-software 3.22.5+really-3.22.5-0ubuntu1 Ubuntu GNOME 17.04 gnome-shell 3.21.91 Happens when running GNOME with or without Wayland. On Ubuntu, I am missing the Addons category on the home page. All I see are the other 9 categories (Audio & Video, Communications & News, Productivity, Games, Graphics & Photography, Developer Tools, Education, Science, Utilities). verbose log attached.
Hmm, I've had a few reports of this acting strangely. On a system where you can reproduce this, can you run "gnome-software-cmd refresh --verbose" and grab the log pls.
I have now upgraded to gnome-software 3.22.6-0ubuntu1 which still has the bug. This version does not have gnome-software-cmd available. Do you need me to try to upgrade to 3.23.91? (Ubuntu 17.04 will stick with 3.22)
Can you try master locally, and specifically do make check in plugins/shell-extensions? I added that today as a sanity check.
Created attachment 347674 [details] gnome-software-cmd refresh --verbose I can duplicate with jhbuild master. But I suspect the problem here is that I'm running gnome-shell 3.23.91 and https://extensions.gnome.org/ doesn't show any extensions for my current version. See also https://bugzilla.gnome.org/776460
Created attachment 347675 [details] make check output Here's the make check output you requested. I had to copy the latest gnome-software gsettings schema to my system for it to work.
My installed extensions do show up in the Installed tab when I'm running gnome-shell so it looks like the gnome-shell plugin is generally working. Here's the contents of my ~/.cache/gnome-software/3.22/extensions/gnome.json {"numpages": 1, "total": 0, "extensions": []}
(In reply to Jeremy Bicha from comment #4) > > But I suspect the problem here is that I'm running gnome-shell 3.23.91 and > https://extensions.gnome.org/ doesn't show any extensions for my current > version. > There are currently 3 issues here: 1. extensions.gnome.org does not show to you extensions, that did not declared compatibility with your version of Shell despite your "disable-extension-version-validation" setting. This issue should be splitted to separate bug report. Jeremy, if you are interested in tracking it, please fill new bug report. 2. GNOME Shell does not installs "incompatible" extensions from e.g.o. despite your "disable-extension-version-validation" setting. This is tracked in bug 776460 - I provided patch for this issue, but it was not reviewed yet. 3. GNOME Software always provide Shell version to e.g.o. because of that it does not showing "incompatible" extensions despite of "disable-extension-version-validation" setting. Richard, you should check "disable-extension-version-validation" setting and if it is enabled (by default since Shell 3.22) you should provide "shell_version=all" here [1]. But keep in mind that users will not be able to install extensions until (2) will not be fixed. P.S.: Richard, I found also that you are using "n_per_page=1000". This causing high load on e.g.o. server - with Andrea Veri we limited items count per page to 25 several months ago. Please split extensions to pages. [1] https://git.gnome.org/browse/gnome-software/tree/plugins/shell-extensions/gs-plugin-shell-extensions.c#n658
(In reply to Yuri Konotopov from comment #7) > 3. GNOME Software always provide Shell version to e.g.o. because of that it > does not showing "incompatible" extensions despite of > "disable-extension-version-validation" setting. Wouldn't it be better if this check was relaxed serverside? I mean, we're providing the exact shell version to e.g.o so the logic could be applied there. > P.S.: Richard, I found also that you are using "n_per_page=1000". This > causing high load on e.g.o. server - with Andrea Veri we limited items count > per page to 25 several months ago. Please split extensions to pages. Err, so you'd rather me query the web service multiple times from each client for each cache refresh than getting it the information in one go? Isn't that much more inefficient, increasing load further? Richard
> Wouldn't it be better if this check was relaxed serverside? I mean, we're > providing the exact shell version to e.g.o so the logic could be applied there. It would be better for those Shell versions that doesn't provide "disable-extension-version-validation" setting. But there are no such versions exists yet. We know that since Shell 3.22 "disable-extension-version-validation" is default to true, but what if user will disable this setting? From e.g.o. side this will be API break. However this may be further discussed with GNOME Shell devs - I'm not against such change if all will be agreed. In any case this will depend on bug 776460 since currently Shell will not install such extensions at all. > Err, so you'd rather me query the web service multiple times from each client > for each cache refresh than getting it the information in one go? No, no, no! I want you to provide pagination (Next/Prev buttons or so) to users, that will be controlled by users, eg request to e.g.o. will be produced when user choose another page. Just like e.g.o. currently does. That way server load will be distributed.
(In reply to Yuri Konotopov from comment #9) > > Err, so you'd rather me query the web service multiple times from each client > > for each cache refresh than getting it the information in one go? > No, no, no! I want you to provide pagination (Next/Prev buttons or so) to > users, that will be controlled by users, eg request to e.g.o. will be > produced when user choose another page. Just like e.g.o. currently does. > That way server load will be distributed. That's not how gnome-software presents extensions to the user. In GNOME software we match search terms and show extensions alongside other applications. To do this quickly (and to avoid network requests when searching) we download the entire list of compatible extensions once per week and convert them to an AppStream document that we can use for matching and installing. This way we can return full results within the 20ms window required for search-as-you-type. See https://git.gnome.org/browse/gnome-software/tree/plugins/shell-extensions/gs-plugin-shell-extensions.c#n694 for the code.
(In reply to Richard Hughes from comment #10) > That's not how gnome-software presents extensions to the user. I see. I will profile query that you are using. As a quick fix I can add cron job to generate proper json file with all extensions for GNOME Software and save it to static directory. That way we can avoid high load issue and ensure that GNOME Software users will get actual and full extensions list. I also can redirect all "n_per_page=1000" requests to such static file.
(In reply to Yuri Konotopov from comment #11) > As a quick fix I can add cron job to generate proper json file with all > extensions for GNOME Software and save it to static directory. I'm happy to change the URL we're using to get that file if that's easier, although it would take a few weeks to roll out to people using the stable versions of gnome-software. If you really want to be super heawesomelpful, the actual format the software centers are using is AppStream, and it would be even better if we could just download an .XML file directly. https://people.freedesktop.org/~hughsient/temp/extensions-web.xml is an example, although I'd happily talk about what e.g.o could do. There exists a python-appstream package if that helps.
(In reply to Yuri Konotopov from comment #7) > 1. extensions.gnome.org does not show to you extensions, that did not > declared compatibility with your version of Shell despite your > "disable-extension-version-validation" setting. > This issue should be split to separate bug report. https://bugzilla.gnome.org/779925
Hi, My extension : https://extensions.gnome.org/extension/1031/topicons/ Has the proper versions declared in metadata.json and yet does not appear. Why?
(In reply to jc from comment #14) > Has the proper versions declared in metadata.json and yet does not appear. From what I can see, your extension is compatible with 3.24 but not explicitly 3.23.92. But 3.24 will be released next week so I wouldn't bother changing it now. Also, I think the Addons>Shell Extensions won't show up unless there are enough extensions but I don't know how many "enough" is. Note that the extension list is only downloaded by GNOME Software once per week unless you manually clear ~/.cache/gnome-software/ according to comment #10.
But it does not show in 3.22 either, so I think there is another issue. > Also, I think the Addons>Shell Extensions won't show up unless there are enough extensions but I don't know how many "enough" is. What does it mean? I was not aware of this classification, where and how is it done?
> the actual format the software centers are using is AppStream, and it > would be even better if we could just download an .XML file directly. I don't think it will be hard to implement. Please fill new issue for this change.
Richard, static json file is available now at [1], so please use this in GNOME Software. Also [2] is redirected now to [1]. For now I generated this file by hand and asked Andrea Veri at IRC to enable generator script as cron job every night. I also will look into AppStream, but it will take some time since there are more important tasks exists. [1] https://extensions.gnome.org/static/extensions.json [2] https://extensions.gnome.org/extension-query/?n_per_page=1000
Created attachment 349697 [details] [review] shell-extensions: Use static URI to fetch extensions data As requested by the extensions.gnome.org maintainer Today, when I opened GNOME Software>Add-ons>Shell Extensions, I saw the big long list of extensions. I successfully installed an old extension that didn't have its metadata bumped. So my original issue is fixed now. That just leaves this minor issue to address from comment #18.
Comment on attachment 349697 [details] [review] shell-extensions: Use static URI to fetch extensions data LGTM, thanks.
Attachment 349697 [details] pushed as d3086a8 - shell-extensions: Use static URI to fetch extensions data
Also pushed to the 3.22 and 3.24 branches. I'm closing this bug since there's nothing else to do here.