On NixOS 20, I installed calibre (via home-manager), and it worked perfectly. Since I have updated to NixOS 21, when I click on the “Add Book” button, it freezes for a few seconds, then crashes.
Here is the output:
/nix/store/fwzgpr17cjsp5c7ax8sr10dpcqvb93p6-glib-networking-2.68.1/lib/gio/modules/libgiognutls.so: undefined symbol: g_tls_channel_binding_error_quark
Failed to load module: /nix/store/fwzgpr17cjsp5c7ax8sr10dpcqvb93p6-glib-networking-2.68.1/lib/gio/modules/libgiognutls.so
[Click on "Add Button"]
(python:3141): Gtk-WARNING **: 09:29:34.794: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /run/current-system/sw/share/icons/Adwaita/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /run/current-system/sw/share/icons/Adwaita/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Aborted (core dumped)
I have googled this issue, and I have found that on other distros, the solution would simply be to run sudo update-mime-database /usr/share/mime, but of course there is no such directory on NixOS. And, I also guess this should be part of some installation / update script, I shouldn’t have to run it.
To quote a maintainer of gtk-pixbuf (the discussion):
The PNG loader not being found is a side effect of updating your system and the package manager not running gdk-pixbuf-query-loaders . Which is why re-generating the loaders.cache (either directly or indirectly) fixes the issue.
This has been solved by making the PNG loader built into the gdk-pixbuf shared library; in general, though, either you or your OS should rebuild the loaders.cache file every time gdk-pixbuf (or a package that provides a gdk-pixbuf shared module) is updated.
I guess in the case of NixOS, it should be the OS, but I might be wrong.
In any case, how can I fix this?
On NixOS, this is generally solved by wrappers, see Packaging GNOME applications section of the Nixpkgs manual. This is complicated by the fact that non-GNOME applications like do use GNOME components only on some desktop environments and wrapping them makes their closure bigger for everyone. But the dependencies are so widespread that we usually do it rather than have the apps crash for portion of users.
It is also possible to have global loaders cache but that might cause issues if your apps are built against a different version of gdk-pixbuf than the cache so I would not recommend it.
Hopefully, programs will gradually switch to XDG desktop portals for file chooser dialogues, which will allow them to use dialogues native to the user’s desktop environment without having to wrap each application with every library it might possibly load dynamically.
Looks like Calibre will try to use zenity on GNOME when available (which should be wrapped), and when it fails it will use the file dialogue provided by Qt:
And it appears Qt will use the portal for file chooser if you set QT_QPA_PLATFORMTHEME=xdgdesktopportal environment variable.
Maybe we should do that by default in GNOME/when xdg-desktop-portal is enabled – but it might conflict with adwaita-qt. Edit: qgnomeplatform is the component to worry about and it already uses portals when available. It would probably be best to just enable the theme like Pantheon does. Edit 2: Opened nixos/gnome: enable platform integration for Qt by jtojnar · Pull Request #136071 · NixOS/nixpkgs · GitHub.
Actually, after a recent upgrade I don’t have this issue any more, even though the PR was not accepted yet. Strange…
It is really environment dependent. And wrappers are not exactly hermetic, unfortunately. Perhaps you have invoked calibre from a gnome-terminal, which is wrapped. Or maybe gnome-shell sets the variable.
1 Like
The bug occurred both when launching calibre with Gnome, and via the terminal (hence the error message).
Now, it also works both ways…
Thanks for that! It seems that running a application (I was running obsidian appimage) from gnome-terminal was causing that issue.
Though, may I ask, how can we unwrapped gnome-terminal and would it be wise to run it like that?
The wrappers are there for a reason – the app would most likely crash without them. In theory, it should be possible to use a patch to hardcode all the relevant dependencies and then, the wrapper would not be necessary. But you would also need to apply this to your shell and every other parent process, which would be very labour intensive.
1 Like