Test under gnome-shell 3.36 needed #321
Comments
|
If I try installing it via extensions.gnome.org I am getting an error... |
E.G.O. is out of date. Please install from source, as described in README.rst. And if you want someone to fix it, please provide logs ( |
I thought that the problem was known, therefore I was not posting any Error logs. Would be nice to have it installed via the official extensions page. |
|
Could you try the code from #316, please, my master branch? It seems you were using sufiyan's version from E.G.O. I said already, it's outdated. If you must try E.G.O, please use @jasuarez' version, it's the one that's closest to our code here.
Sure. We're actively working on it. See #316. GNOME 3.36 support is currently the open question, thus this issue. Are you using 3.36? |
Hello @xMordax, For your information (and that of others):
Looking forward to your further feedback! |
|
Hey @mwilck @DirkHoffmann, first of all, thanks for your responses. Yes I am using 3.36, when I try to install the @mwilck fix I am getting the following error: Any Idea why? |
|
@xMordax,
Because you are using some other code, not mine. This is not code from my master branch. This code has been removed in two steps, first eea1424, and then 52dd4c1. |
|
@mwilck maybe as a side note, I am using Wayland. |
|
Thanks, this looks much more helpful. The error message that matters is this: I don't think Wayland matters here. It's yet another JS incompatibilty. |
|
Could the problem be that the older extension is still installed? If it is one from ego, it might have a different id so not be removed when installing this one? Just guessing here, though. |
|
@matthijskooijman, good hint. @xMordax, please make sure you wipe the old extension(s) you had used, at least temporarily, and cleanly restart the GNOME shell. |
Right. I am using wayland (and gnome-shell 3.34). It's without problems for me.
You mean it is an update in gnome-shell 3.36, which makes another update on our (hamster-extension) side necessary?
Good point! @xMordax, you may want to manually remove all hamster extensions from your |
|
@mwilck @DirkHoffmann |
|
This seems to affect other extensions, too. |
|
@xMordax, this is just a shot in the dark, but could you try replacing with in |
|
@mwilck I did the change and tried to disable and enable the extension and get the following error: |
|
|
It seems that this version of the shell deletes an extension that causes an error from disk. Nice. |
|
I seem to have fixed two minor issues, so that now I don't observe any error messages from GNOME shell 3.36 regarding the hamster extension any more. I can actually see "no activity" showing up for a moment on the panel. Than it vanishes, and in the log I see only "Shutting down hamster-shell-extension.". After that, my extension directory is wiped from disk. WTH. |
|
Stack: So the shell is actively trying to disable our extension. |
|
It looks as if the GNOME shell checks https://extensions.gnome.org/extension-info and obtains the info that |
|
@elbenfreund, have you done something to set our extension to "blacklisted" on extensions.gnome.org? I just tried to change the UUID from |
|
@mwilck can you tell how to change the UUID to get it working? I am getting the same error also after renaming the directory after the uuid configuration in the metadata.json. |
|
@xMordax , please check out #323. Note the special instructions. |
Check out #323. Changing the UUID is not all you need to do. In #323, I changed the Makefile to make it possible to change the UUID. I used |
|
The GNOME shell code that's responsible for auto-disabling and deleting the extension So far I've found no human-accessible way to figure out this status information for a given UUID on extensions.gnome.org. Strangely, out of the 4 extensions that are listed on E.G.O. when searching for "hamster", none acutally uses the This leaves me pretty puzzled. I also don't understand why this effect is only observed on GNOME 3.36, as the JS code linked above is anything but new. |
Given that you send the gnome-shell version, maybe the online service only returns blacklist for 3.36? If so, then maybe this code is somehow tied in with automated feedback from users? E.g. they can push an extension to users on a newer gnome-shell than is reported supported and when they get errors or problem reports back, the extension is blacklisted or something? It's a bit of a bummer that this also applies to locally installed versions and seems to apply regardless of the extension version... |
|
Looking at the client code, that has been in place for 7 years and the discussion about it focuses about the code and updates, so no clue what the blacklist is for: https://bugzilla.gnome.org/show_bug.cgi?id=679099
It actually sends to https://extensions.gnome.org/update-info/ it seems? The code for that endpoint is here: https://gitlab.gnome.org/Infrastructure/extensions-web/-/blob/master/sweettooth/extensions/views.py#L111-157 It looks like this can return 'blacklist' when e.g.o has no version available for your shell version, i.e. I suspect that the usecase here is when you upgrade from e.g. 3.34 to 3.36, that it can uninstall the extension if it is not supported there. However, this situation should not actually happen:
|
I played with the versions first, no success. Then I changed the UUID, immediate success.
the question being feedback towards WHAT?, as no extension with the
Indeed. The first half-a-dozen times my extension dir had been wiped I thought I was dreaming.
Right, copy-n-paste mistake. Thanks for spotting it.
Thanks for figuring that out, very helpful 👍 But that has never happened to me before. As you knowl, hamster shell extension has been broken with every new GNOME shell version, but it has never before been auto-uninstalled. Perhaps it's because 3.36 isn't public yet?
GNOME bug report ... ?
yes, most definitely. I checked yesterday, and today again, using dconf-editor. |
Well, it is public now. We don't have it in openSUSE yet though, as I said I was using 3.35.96. Perhaps that explains it, no idea. I'll retest when 3.36 hits openSUSE repos, shouldn't be long any more. |
Hm, that might be relevant. If the extension exists, but it has no version at all, then that might be the one corner case the triggers I tried getting info about the extension through the ajax API, but this failed (https://extensions.gnome.org/extension-info/[email protected] returns 404 and https://extensions.gnome.org/extension-query/[email protected] returns an empty list). Both urls worked with antoher UUID, so the syntax is ok. It looks like this means the uuid is not known at all, or it is an extension with visible=False and/or only invisible versions.... Did you already try dumping the exact parameters used, maybe by adding some prints? I tried reproducing this, but this just returns an empty response as expected: https://extensions.gnome.org/update-info/?shell_version=3.35.92&disable_version_validation=1&installed={%22uuid%22:{%22version%22:%[email protected]%22}} |
But
Have you found an email address or other possible way to contact the maintainers of the E.G.O. data base and figure it out? I have not, so far.
AFAIK this requires recompiling GNOME shell, so far I shied away from that.
Wow, cool. I tried to do this, but I couldn't figure it out. |
|
@mwilck I checked out your branch and followed the instructions and it works on Arch GNOME 3.36 with Wayland... |
|
@xMordax , thanks a lot for the feedback. Stay, tuned, we'll continue looking into the "blacklilst" issue. |
|
I updated to GNOME shell 3.36.0 now, and I'm still seeing the same issue with the extension being auto-blacklisted and removed. So using 3.35.96 was not the reason. |
No, I hadn't changed the version of the extension. But I just tried now (set it to 3.36), and it makes no difference, the extension is still auto-blacklisted. Typical logs look like this:
with no visible error messages from the extension before this. |
|
FTR, the extension as present in mwilck/GNOME-3.36 is working fine for me in GNOME 3.36 in Debian Unstable. Thanks for your work on this! |
|
Fixed with the merge of #323. |
Originally posted by @mwilck in #319 (comment)
Please feel free to add any (positive or negative) feedback here.
The text was updated successfully, but these errors were encountered: