Re: Foreign distro Unity desktop broken after guix update
Thorsten Wilms writes: > I since learned that setting the paths like that makes the Ubuntu-side > work, but guix stuff will fail. Gnucash bails out, Inkscape segfaults > and GIMP runs without toolbox icons. Also, with a bit of thought, > GDK_PIXBUF_MODULE_FILE must point to one file; it can’t be a chain of > paths. > > Thus at the very least GDK_PIXBUF_MODULE_FILE must be one thing for > Ubuntu and another for guix. Short of running all guix-installed stuff > from a terminal after setting the variable there, is there any > solution? Perhaps create a local copy of the .desktop file for each guix controlled application and modify it to set the correct environment variables? I've done that for certain applications where I needed to add custom arguments to the command for it to scale properly with my monitors. I placed mine in $HOME/.local/share/applications aka $XDG_DATA_HOME/applications > I also found out that plain `gdk-pixbuf-query-loaders` resolves to the > guix version. The Ubuntu version resides at > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders > > My current theory is that this pixbuf-mixup has been going on for > longer, but only a recent guix update made stuff incompatible. In > addition, some caching might complicate matters. That sounds very likely. I had a similar issue with python, where my foreign distro updated to python-3.10 but guix is still on 3.9. Things started breaking as I had missed to move everything to guix. > Thank you for your thoughts, Fredrik! No problem, I hope you can sort it out. -- s/Fred[re]+i[ck]+/Fredrik/g
Re: Foreign distro Unity desktop broken after guix update
On Tue, 28 Dec 2021 21:45:26 + Fredrik Salomonsson wrote: > > I added > > ``` > > export > > GDK_PIXBUF_MODULE_FILE=/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache:/home/thorwil/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache > > export LIBRARY_PATH=/usr/lib:/home/thorwil/.guix-profile/lib > > ``` > > to .profile. Now I have all icons back! Guess there’s a better way? > > Nice! I'm not sure there's a better way, other than having guix control > the full GNOME stack (which is probably not feasible or desirable on a > foreign distro). I since learned that setting the paths like that makes the Ubuntu-side work, but guix stuff will fail. Gnucash bails out, Inkscape segfaults and GIMP runs without toolbox icons. Also, with a bit of thought, GDK_PIXBUF_MODULE_FILE must point to one file; it can’t be a chain of paths. Thus at the very least GDK_PIXBUF_MODULE_FILE must be one thing for Ubuntu and another for guix. Short of running all guix-installed stuff from a terminal after setting the variable there, is there any solution? I also found out that plain `gdk-pixbuf-query-loaders` resolves to the guix version. The Ubuntu version resides at /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders My current theory is that this pixbuf-mixup has been going on for longer, but only a recent guix update made stuff incompatible. In addition, some caching might complicate matters. Thank you for your thoughts, Fredrik! -- Thorsten Wilms
Re: Foreign distro Unity desktop broken after guix update
Thorsten Wilms writes: > On Mon, 27 Dec 2021 22:17:22 +0100 > Thorsten Wilms wrote: > >> > env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace >> >> Interesting, but I’m puzzled about how to use that with compiz/unity. > > I noticed that some icons in GNOME-applications are missing, so any of > those might do in place of compiz. They all belong to Ubuntu, not guix. > > The result of `env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace > gnome-calculator` told me that /gnu/store paths are checked first and > exclusively for several libraries. > > LD_LIBRARY_PATH is empty and `env | grep /gnu/store` prints nothing, > but env does contain > ``` > GDK_PIXBUF_MODULE_FILE=/home/thorwil/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache > GIO_EXTRA_MODULES=/home/thorwil/.guix-profile/lib/gio/modules:/home/thorwil/.guix-profile/lib/gio/modules > LIBRARY_PATH=/home/thorwil/.guix-profile/lib:/home/thorwil/.guix-profile/lib > ``` Ok, GNOME probably have some other methods of dynamically load libraries. The GDK_PIXBUF_MODULE_FILE looks suspicious. I'm not familiar with GNOME and its tool kits. > I don’t recall ever doing anything about those; they are not defined > in .profile or .bashrc. They're defined in your guix profile. E.g I got GDK_PIXBUF_MODULE_FILE defined in both ~/.guix-profile/etc/profile and ~/.guix-home/profile/etc/profile And as far as I can tell those gets added to the profile when another package needs them. > I added > ``` > export > GDK_PIXBUF_MODULE_FILE=/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache:/home/thorwil/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache > export LIBRARY_PATH=/usr/lib:/home/thorwil/.guix-profile/lib > ``` > to .profile. Now I have all icons back! Guess there’s a better way? Nice! I'm not sure there's a better way, other than having guix control the full GNOME stack (which is probably not feasible or desirable on a foreign distro). > This is no longer looks like a guix-topic, but compiz still segfaults > after many errors for various SVGs, like: > ``` > ERROR 2021-12-28 10:50:18 nux.gltexture.resource.manager > GLTextureResourceManager.cpp:54 Invalid target, impossible to generate > a new texture. Impossible to generate a pixbuf: Couldn’t recognize the > image file format for file “/usr/share/unity/icons/search_spin.svg” > ``` > > `file` and the image viewer eog have no problem with > “/usr/share/unity/icons/search_spin.svg”. > > There’s also > ``` > compiz[8431]: WARN 2021-12-28 10:50:15 unity.glib.dbus.server > GLibDBusServer.cpp:595 Can't register object 'com.canonical.Unity.Dash' yet > as we don't have a connection, waiting for it... > compiz[8645]: WARN 2021-12-28 10:50:18 unity.glib.dbus.server > GLibDBusServer.cpp:595 Can't register object 'com.canonical.Unity.Launcher' > yet as we don't have a connection, waiting for it... > ``` Yeah, this doesn't look like something caused by guix, might be a side effect or something though. The last two warnings are about compiz not being able to communicate with Dash and Launcher from Unity over dbus. But I don't use either Ubuntu or Unity so sadly I cannot be much of a help here. -- s/Fred[re]+i[ck]+/Fredrik/g
Re: Foreign distro Unity desktop broken after guix update
On Mon, 27 Dec 2021 22:17:22 +0100 Thorsten Wilms wrote: > > env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace > > Interesting, but I’m puzzled about how to use that with compiz/unity. I noticed that some icons in GNOME-applications are missing, so any of those might do in place of compiz. They all belong to Ubuntu, not guix. The result of `env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace gnome-calculator` told me that /gnu/store paths are checked first and exclusively for several libraries. LD_LIBRARY_PATH is empty and `env | grep /gnu/store` prints nothing, but env does contain ``` GDK_PIXBUF_MODULE_FILE=/home/thorwil/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache GIO_EXTRA_MODULES=/home/thorwil/.guix-profile/lib/gio/modules:/home/thorwil/.guix-profile/lib/gio/modules LIBRARY_PATH=/home/thorwil/.guix-profile/lib:/home/thorwil/.guix-profile/lib ``` I don’t recall ever doing anything about those; they are not defined in .profile or .bashrc. I added ``` export GDK_PIXBUF_MODULE_FILE=/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache:/home/thorwil/.guix-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache export LIBRARY_PATH=/usr/lib:/home/thorwil/.guix-profile/lib ``` to .profile. Now I have all icons back! Guess there’s a better way? This is no longer looks like a guix-topic, but compiz still segfaults after many errors for various SVGs, like: ``` ERROR 2021-12-28 10:50:18 nux.gltexture.resource.manager GLTextureResourceManager.cpp:54 Invalid target, impossible to generate a new texture. Impossible to generate a pixbuf: Couldn’t recognize the image file format for file “/usr/share/unity/icons/search_spin.svg” ``` `file` and the image viewer eog have no problem with “/usr/share/unity/icons/search_spin.svg”. There’s also ``` compiz[8431]: WARN 2021-12-28 10:50:15 unity.glib.dbus.server GLibDBusServer.cpp:595 Can't register object 'com.canonical.Unity.Dash' yet as we don't have a connection, waiting for it... compiz[8645]: WARN 2021-12-28 10:50:18 unity.glib.dbus.server GLibDBusServer.cpp:595 Can't register object 'com.canonical.Unity.Launcher' yet as we don't have a connection, waiting for it... ``` -- Thorsten Wilms
Re: Foreign distro Unity desktop broken after guix update
On Mon, 27 Dec 2021 19:37:07 + Fredrik Salomonsson wrote: > printenv LD_LIBRARY_PATH Empty > env | grep /gnu/store Empty > Another reason why the runtime linker would pick up that library would > be if its path is added to the /etc/ld.so.conf configs. But I highly > doubt it's the issue. Via include, that makes for the following list: /usr/lib/x86_64-linux-gnu/libfakeroot /usr/local/lib /usr/local/lib/x86_64-linux-gnu /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu > If you want to go down the rabbit hole you can use the LD_DEBUG > environment variable to get some debug output. The libs option is > probably the most useful to you as that will print where it's looking > for stuff and why. Use: > > env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace Interesting, but I’m puzzled about how to use that with compiz/unity. > I hope that helps a bit. A good start. Thank you! -- Thorsten Wilms
Re: Foreign distro Unity desktop broken after guix update
Hi, Thorsten Wilms writes: > Unity desktop stopped working after the first ’guix pull && guix > package -u’ in maybe 2 weeks. There has been no update on the Ubuntu > side between the last succesfull run and now, as far as I can tell. > Unity desktop causes a few redraws, then exits back to the session > greeter (lightdm). > > Now I would have assumed that there is no interaction between Unity and > guix, since the former is entirely on the dpkg side. But via journalctl, > I found a whole lot of: > ``` > Dec 27 15:44:51 charly compiz[2198]: ERROR 2021-12-27 15:44:51 > nux.gltexture.resource.manager GLTextureResourceManager.cpp: > 54 Invalid target, impossible to generate a new texture. > Impossible to generate a pixbuf: Unable to load image-loading > module: > /gnu/store/2dza2psfbrrbvsni8jjqzzqx3hmm8kw8-librsvg-2.50.7/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: > /lib/x86_64-linux-gnu/libpthread.so.0: version `GLIBC_PRIVATE' not found > (required by > /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib/librt.so.1) > ``` > > It looks like compiz segfaults shortly after a bunch of those, followed > by unity7.service. > > Any ideas why dpkg-compiz tries to use guix-librsvg and what to do > about it, or what else is going on here? Could be that LD_LIBRARY_PATH is set and includs path(s) to libpixbufloader-svg.so in the guix store which is causing the streams to cross. Try: printenv LD_LIBRARY_PATH and see what it contains or: env | grep /gnu/store to see if any environment variable contains path to the store. Another reason why the runtime linker would pick up that library would be if its path is added to the /etc/ld.so.conf configs. But I highly doubt it's the issue. If you want to go down the rabbit hole you can use the LD_DEBUG environment variable to get some debug output. The libs option is probably the most useful to you as that will print where it's looking for stuff and why. Use: env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace The LD_DEBUG_OUTPUT is a must as it will print out a ton of text. This will save the output to /tmp/trace.. You can tell it to print out a help text by using: env LD_DEBUG=help cat I hope that helps a bit. -- s/Fred[re]+i[ck]+/Fredrik/g