gnome: Package all the Gnome extensions … again?! #118232
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
6.topic: GNOME
10 tasks
ofborg
bot
added
8.has: package (new)
|
Result of 83 packages failed to build:
6 packages skipped due to time constraints:
215 packages built successfully:
2 suggestions:
Note that build failures may predate this PR, and could be nondeterministic or hardware dependent. |
|
Can somebody please validate the results from the bot? It shows some hash mismatches, but works for me … |
|
Most errors due to hash mismatches AFAICT. Result of 90 packages failed to build:
214 packages built:
|
|
Okay, I can reproduce after a garbage collect. The URLs changed their hash, wtf? |
|
@ofborg eval |
ofborg
bot
added
2.status: merge conflict
|
Please exclude fuzzy-app-search, it has a patch which is needed for it to work. Edit: arcmenu needs a patch as well, maybe exclude the ones which have patches or other special dependencies. |
|
Thanks for the notice. The current approach is to package all of them in a hit-or-miss style ( |
|
I finally found the root cause for the hash mismatches. The description can be updated at any point it time through the web site, and that is reflected in the |
piegamesde
force-pushed
the
gnome-extensions
branch
4 times, most recently
from
180c939 to
f89ac30
Compare
|
It's really ugly, but I think the hash mismatches are now finally and completely resolved. |
jtojnar
reviewed
May 10, 2021
| # hash. | ||
| extraPostFetch = let | ||
| # The replacement of \\u -> \u is to undo a workaround we do in update-extensions.py which does the opposite operation, | ||
| # because Nix can't handle unicode in JSON. The other substitutions are fallout from the previous. |
There was a problem hiding this comment.
Just a note that it should be in the next release: NixOS/nix#4368
There was a problem hiding this comment.
@andir told me (IIRC) that this was not enough, one cannot simply depend on the currently released version do to upgrade compatibility or something like that. Especially, all the build tooling (Hydra, Ofborgs) needs to be updated or otherwise things will break ^^. But if I get a "go" on that one, I'll be happy to change it.
There was a problem hiding this comment.
Yeah, it is still too soon to get rid of this. Just adding a note for future reference.
github-actions
bot
removed
the
6.topic: GNOME
piegamesde
force-pushed
the
gnome-extensions
branch
2 times, most recently
from
fcf589e to
b9df287
Compare
jtojnar
reviewed
May 11, 2021
| @@ -0,0 +1,74 @@ | |||
| { | |||
There was a problem hiding this comment.
Why are we committing this? Is not this easily derivable from extensions.json?
We might want to add assertion that all collisions are handled in renames either way since instruction in a comment will get easily ignored.
There was a problem hiding this comment.
I am committing this because the diff is really useful when doing updates. I thought about adding a test that checks for collision handling, but I personally don't need it for maintaining.
piegamesde
force-pushed
the
gnome-extensions
branch
2 times, most recently
from
bcccc50 to
0de59fa
Compare
piegamesde
force-pushed
the
gnome-extensions
branch
from
0de59fa to
d4616c6
Compare
github-actions
bot
added
the
6.topic: GNOME
|
But since you asked about the run time, here's the |
|
@jtojnar I've had a look at But I won't push these changes right now, because I wouldn't want to accidentally cause a regression in the code just before the merge window closes. All changes and improvements that are not a merge blocker will have go in a future pull request. |
jtojnar
reviewed
May 21, 2021
| for shell_version in shell_version_map.keys(): | ||
| if pname in package_name_registry[shell_version]: | ||
| logging.warning(f"Package name '{pname}' is colliding.") | ||
| package_name_registry[shell_version][pname] += [uuid] |
There was a problem hiding this comment.
Not fond of globals but we can change that later.
|
We also need to document the updating procedure (README.md with steps describing the procedure would suffice). User docs in the newly added GNOME section would be also nice but would not block on that. |
piegamesde
force-pushed
the
gnome-extensions
branch
from
d4616c6 to
74c281a
Compare
jtojnar
reviewed
May 21, 2021
jtojnar
reviewed
May 21, 2021
piegamesde
force-pushed
the
gnome-extensions
branch
from
74c281a to
b95fc9d
Compare
jtojnar
reviewed
May 21, 2021
piegamesde
force-pushed
the
gnome-extensions
branch
from
0898e80 to
4d03204
Compare
piegamesde
changed the title
piegamesde
force-pushed
the
gnome-extensions
branch
3 times, most recently
from
1f2c444 to
042f746
Compare
|
Thanks for bearing with me. Great work. Let me just quickly rebase it and then let’s merge it. |
An automatic way to do this that scales up and requires little manual intervention is really needed. It works by scraping extensions.gnome.org with a python script, that writes all relevant information into the `extensions.json`. Every attribute of besaid file can be built into a package using `buildShellExtension`. Extensions are grouped by GNOME Shell version for practical reasons. Only extensions for GNOME 40 and 3.38 were added, as we don't support legacy GNOME versions. The extensions are exposed as an attrset, `pkgs.gnome40Extensions` and `pkgs.gnome38Extensions` respectively. The package name of each extensions is generated automatically from its UUID. The attribute `pkgs.gnomeExtensions` contains the officially packaged and supported extensions set. It contains all the automatically packaged extensions for the current GNOME Shell version, which are overwritten by manually packaged ones where needed. Unlike gnomeXYExtensions, the names are not UUIDs, but automatically generated human-friendly names. Naming collisions – which are tracked in collisions.json – need to be manually resolved in the `extensionRenames` attrset.
jtojnar
added a commit
that referenced
this pull request
May 21, 2021
This was referenced Jun 9, 2021
|
Thank you, much appreciated. |
|
No, GNOME 40 does not support extensions for older versions. There already are some extensions compatible with GNOME 40 in |
This was referenced Jul 14, 2021
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/easy-way-to-add-paths-to-gi-typelib-path/15240/2 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Take II, aka "Revert #118184" CC @mweinelt @maralorn
Motivation for this change
An automatic way to do this that scales up and requires little manual intervention is really needed. It works by scraping extensions.gnome.org with a python script,
that writes all relevant information into the
extensions.json. Every attribute of besaid file can be built into a package usingbuildShellExtension.Extensions are grouped by Gnome shell version for practical reasons. Only extensions for Gnome 3.36 and 3.38 were added for now. If desired, we can always add older versions later on.
The extensions are exposed as an attrset,
pkgs.gnome36Extensionsandpkgs.gnome38Extensionsrespectively. The extension's UUID is used as attribute name.pkgs.gnomeExtensionsis now enhanced with automatically generated extensions, taken from the set matching the currently packaged Gnome Shell. It is manually curated and all attributes have a proper human-friendly name. Manual conflict resolution has to be done when there are multiple extensions that share the same human-friendly name. The previously packaged extensions are left as-is, but in the future we can remove those who don't require manual packaging in the future.Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review pr 108414"./result/bin/)nix path-info -Sbefore and after)