Foreign distro Unity desktop broken after guix update

Foreign distro Unity desktop broken after guix update

[Thorsten Wilms]

Hi!

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?


-- 
Thorsten Wilms <t_w_@freenet.de>

Re: Foreign distro Unity desktop broken after guix update

[Fredrik Salomonsson]

Hi,

Thorsten Wilms <t_w_@freenet.de> 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 <executable>

The LD_DEBUG_OUTPUT is a must as it will print out a ton of text. This
will save the output to /tmp/trace.<pid>.

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

Re: Foreign distro Unity desktop broken after guix update

[Thorsten Wilms]

On Mon, 27 Dec 2021 19:37:07 +0000
Fredrik Salomonsson <plattfot@posteo.net> 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 <executable>

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 <t_w_@freenet.de>

Re: Foreign distro Unity desktop broken after guix update

[Thorsten Wilms]

On Mon, 27 Dec 2021 22:17:22 +0100
Thorsten Wilms <t_w_@freenet.de> wrote:

> > env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace <executable>
> 
> 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 <t_w_@freenet.de>

Re: Foreign distro Unity desktop broken after guix update

[Fredrik Salomonsson]

Thorsten Wilms <t_w_@freenet.de> writes:

> On Mon, 27 Dec 2021 22:17:22 +0100
> Thorsten Wilms <t_w_@freenet.de> wrote:
>
>> > env LD_DEBUG=libs LD_DEBUG_OUTPUT=/tmp/trace <executable>
>> 
>> 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

[Thorsten Wilms]

On Tue, 28 Dec 2021 21:45:26 +0000
Fredrik Salomonsson <plattfot@posteo.net> 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 <t_w_@freenet.de>

Re: Foreign distro Unity desktop broken after guix update

[Fredrik Salomonsson]

Thorsten Wilms <t_w_@freenet.de> 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