| 8 Dec 2023 |
 Jan Tojnar | but that would be extreme yuck | 22:38:12 |
 piegames | We could make a flag for that. Or wait one more cycle and then throw out everything <45 | 22:38:14 |
| Jan Tojnar | I though so but I still saw the legacy imports in the official extensions | 22:39:15 |
| Jan Tojnar | never mind, I misremembered, it was GNOME Shell itself, and it is ESM, it just uses the old import style as well https://github.com/NixOS/nixpkgs/blob/a87dd3d3d9ea483ccddc51ffc300ef0f336e2b96/pkgs/desktops/gnome/core/gnome-shell/wrap-services.patch#L16 | 22:41:53 |
| Jan Tojnar | In reply to @piegames:matrix.org
After some reflection, I think that I'd like to package all extensions with buildGnomeExtension, even those not on extensions.gnome.org. This will require some modifications but it should be feasible How would that even work when an extension requires building? Does not buildGnomeExtension just unpack a tarball? | 22:44:57 |
| Jan Tojnar | In reply to @piegames:matrix.org
Also how well does this approach generealize, so that we may hook this into buildGnomeExtension in the longer term, I would probably want to make gjs support specifying the typelib path as part of the import statement | 22:46:54 |
| Jan Tojnar | similarly how it allows setting version | 22:47:09 |
| piegames | In reply to @jtojnar:matrix.org
How would that even work when an extension requires building? Does not buildGnomeExtension just unpack a tarball? You build a tarball as would be uploaded to extensions.gnome.org and then pass it as source to buildGnomeExtension. It then takes care for you of putting everything into place and fixing the dependencies and stuff. The idea is that we can then have patches etc. in extension-overrides.nix, which means less copying stuff around when extensions switch between manually packaged or not (e.g. due to early support for the next Gnome version) | 22:47:32 |
| Jan Tojnar | I still find patching the build output more annoying then patching the source | 22:51:26 |
| Jan Tojnar | I would rather be working with upstream to standardize dependency metadata to make extension builds reproducible and then we would not need to use pre-built extensions at all | 22:52:22 |
| Jan Tojnar | but I probably will not ever find time to work on that | 22:52:44 |
| Jan Tojnar | * I would rather be working with upstream to standardize dependency metadata to make extension builds reproducible and then we would not need to use pre-built extensions at all (similar to the work drupol is currently carrying out in PHP ecosystem) | 22:54:56 |
| piegames | In reply to @jtojnar:matrix.org
I would rather be working with upstream to standardize dependency metadata to make extension builds reproducible and then we would not need to use pre-built extensions at all (similar to the work drupol is currently carrying out in PHP ecosystem) I know the discussed plans about standardizing extension sources (IIRC by forcing them to create a GitLab repo in some format per extension), not sure what's the state of that | 22:57:06 |
| Jan Tojnar | yeah, I vaguely recall that, that would be ideal | 22:58:15 |
| Jan Tojnar | * yeah, I vaguely recall that, that would be cool | 23:02:34 |
| 9 Dec 2023 |
 @adham-omran:matrix.org | In reply to @vcunat:matrix.org
Isn't this a repeat of https://github.com/NixOS/nixpkgs/issues/244742 I see, I did not find this in my search.
Any work around for these issues?
| 16:27:25 |
 vcunat | The issue know better than me. | 16:27:55 |
| vcunat | * The issues know better than me. | 16:27:59 |
| @adham-omran:matrix.org | In reply to @vcunat:matrix.org
BTW for large upgrades I'd be careful that (1) you reboot and (2) don't use opengl-using apps from very far away nixpkgs version (than your OS). I did (1). As for (2) I don't know such applications since I use the most up-to-date versions | 16:28:00 |
| @adham-omran:matrix.org | Also does this happen on other GNOME distros? (e.g. Fedora) | 16:28:41 |
| @adham-omran:matrix.org | * Also does this happen on other distros that have GNOME 45? (e.g. Fedora) | 16:28:56 |
|  @git_lit_mit_ohne_dir:matrix.org changed their display name from Git Lit Mir Ohne Dir to Git Lit Mit Ohne Dir. | 20:06:26 |
| @git_lit_mit_ohne_dir:matrix.org left the room. | 21:45:36 |
| 10 Dec 2023 |
| Jan Tojnar | adham: it is unrelated to GNOME update, it was happening even before GNOME was bumped. And yes, it is distro independent. | 10:08:03 |
| Jan Tojnar | the workarounds are linked in the issue | 10:09:43 |
| @adham-omran:matrix.org | In reply to @jtojnar:matrix.org
the workarounds are linked in the issue rm -rf ~/.config/*/{Default/GPUCache,GrShaderCache,ShaderCache}?
Did not work for me | 10:12:37 |
| @adham-omran:matrix.org | In reply to @jtojnar:matrix.org
adham: it is unrelated to GNOME update, it was happening even before GNOME was bumped. And yes, it is distro independent. I switched to KDE and GIMP works again | 10:12:57 |
| Jan Tojnar | GIMP wound not be affected, only chromium and electron-based apps | 10:13:21 |
| Jan Tojnar | so perhaps you have a different issue | 10:13:28 |
| @adham-omran:matrix.org | In reply to @jtojnar:matrix.org
GIMP wound not be affected, only chromium and electron-based apps Sorry you are right this is a different matter | 10:13:43 |
