Re: ‘staging’ and GNOME updates

[Giovanni Biscuolo]

Hello Timothy and Ricardo,

Timothy Sample  writes:

[...]

> Or, maybe I could pull Epiphany out of our GNOME package, and avoid
> WebKitGTK (now that GNOME Shell doesn’t need it).

this will not fix any problem but please do it anyway before merging to
master :-)

thanks for working on this!

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Timothy Sample  writes:

> Ricardo Wurmus  writes:
>
>>> After running GNOME 3.28 for a while, I’ve had several crashes.  It used
>>> to crash whenever I opened a URL from Emacs, but fiddling with dconf has
>>> fixed that.  It currently crashes every time I run ERC (I’ve turned on
>>> notifications there), and I can’t seem to fix it.
>>>
>>> Interestingly, there is a discussion about this on the Arch Linux forums
>>> .  I’m not sure if
>>> there’s anything useful for us in there, though.
>>
>> This message seems relevant:
>>
>> https://bbs.archlinux.org/viewtopic.php?pid=1778640#p1778640
>>
>> My issue was caused by using ubuntu-cairo. It was incompatible with
>> librsvg 2.42.3, which caused a crash when gnome attempted to load an
>> SVG when trying to display the notification. It also caused the
>> close window button to not appear in the overview.
>
> I did see this, but I couldn’t really connect it to the problem at hand.
> It is interesting that the close window buttons in the overview are a
> problem for us, too .
>
>>> It looks like GNOME Shell passes some bad icon data into GTK+, which
>>> results in a null filename that gets dereferenced.  (GNOME Shell is not
>>> in the backtrace – it tells GTK+ to run this thread from the
>>> “load_texture_async” function in “st-texture-cache.c”.
>>>
>>> I think the “bad” user files are not the root cause here.  There’s
>>> definitely something wrong with notifications.  (I just plugged in a USB
>>> drive and, sure enough, GNOME Shell crashed.)  The notification daemon
>>> code is written in JavaScript (“js/ui/notificationDaemon.js”).  I
>>> glanced at it and its Git history, but couldn’t find anything.
>>
>> I don’t think it’s notifications per se, but rendering SVGs.  When
>> application_state exists, GNOME shell tries to restore application
>> windows and their icons are likely SVG files that should be rendered.
>>
>> Chris reported elsewhere that GNOME sometimes crashes when the Activity
>> tab is accessed — that’s where the application starter is, which
>> displays icons.
>>
>> I believe we should be using librsvg-next in the closure of gnome-shell.
>> We may also want to use gdk-pixbuf+svg instead of just gdk-pixbuf, but
>> again replacing librsvg with librsvg-next throughout.  I’m guessing that
>> the problem is entirely due to using an outdated variant of librsvg.
>>
>> What do you think?
>
> To be honest, I don’t know.  From my side, I haven’t seen anything that
> suggests SVGs might be the problem.  I just checked an application that
> no longer has an icon since the update, and it doesn’t provide an SVG.
> On the other hand, Emacs, which does provide an SVG, is fine.  I can’t
> find anything in the backtrace that suggests SVG problems either.
>
> That said, software is complicated and this is best lead we have.  Maybe
> the crash I’m seeing is fallback code that gets called when SVGs aren’t
> quite working.  I did try patching GTK+ the other day (for testing
> something else), but gave up when I realized that it means recompiling
> WebKitGTK, which takes forever.  I’ll try and patch everything later and
> leave my computer to compile overnight.  Or, maybe I could pull Epiphany
> out of our GNOME package, and avoid WebKitGTK (now that GNOME Shell
> doesn’t need it).  Either way, I will try and test this.  If nothing
> else, it might fix the bug linked above.

I built the VM with this diff:

--8<---cut here---start->8---
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 5583af576b..98e2a75777 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -2189,7 +2189,7 @@ engineering.")
 (inputs
  `(("gtk+" ,gtk+)
("gtk+-2" ,gtk+-2)
-   ("librsvg" ,librsvg)
+   ("librsvg" ,librsvg-next)
("libxml2" ,libxml2)
("glib" ,glib)))
 (native-inputs
@@ -3278,7 +3278,7 @@ services for numerous locations.")
("cups" ,cups)
("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
("libwacom" ,libwacom)
-   ("librsvg" ,librsvg)
+   ("librsvg" ,librsvg-next)
("xf86-input-wacom" ,xf86-input-wacom)
("wayland" ,wayland)
("network-manager" ,network-manager)))
@@ -3864,7 +3864,7 @@ for application developers.")
("libxml2" ,libxml2)
("libsoup" ,libsoup)
("libpeas" ,libpeas)
-   ("librsvg" ,librsvg)
+   ("librsvg" ,librsvg-next)
("lirc" ,lirc)
("gnome-desktop" ,gnome-desktop)
("gstreamer" ,gstreamer)
@@ -4072,7 +4072,7 @@ supports playlists, song ratings, and any codecs 
installed through gstreamer.")
   ("libexif" ,libexif)
   ("libpeas" ,libpeas)
   ("libjpeg" ,libjpeg)
-  ("librsvg" ,librsvg)
+  ("librsvg" ,librsvg-next)
   ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
   ("gtk+" ,gtk+)))
(home-page 

Re: ‘staging’ and GNOME updates

[Timothy Sample]

Ricardo Wurmus  writes:

>> After running GNOME 3.28 for a while, I’ve had several crashes.  It used
>> to crash whenever I opened a URL from Emacs, but fiddling with dconf has
>> fixed that.  It currently crashes every time I run ERC (I’ve turned on
>> notifications there), and I can’t seem to fix it.
>>
>> Interestingly, there is a discussion about this on the Arch Linux forums
>> .  I’m not sure if
>> there’s anything useful for us in there, though.
>
> This message seems relevant:
>
> https://bbs.archlinux.org/viewtopic.php?pid=1778640#p1778640
>
> My issue was caused by using ubuntu-cairo. It was incompatible with
> librsvg 2.42.3, which caused a crash when gnome attempted to load an
> SVG when trying to display the notification. It also caused the
> close window button to not appear in the overview.

I did see this, but I couldn’t really connect it to the problem at hand.
It is interesting that the close window buttons in the overview are a
problem for us, too .

>> It looks like GNOME Shell passes some bad icon data into GTK+, which
>> results in a null filename that gets dereferenced.  (GNOME Shell is not
>> in the backtrace – it tells GTK+ to run this thread from the
>> “load_texture_async” function in “st-texture-cache.c”.
>>
>> I think the “bad” user files are not the root cause here.  There’s
>> definitely something wrong with notifications.  (I just plugged in a USB
>> drive and, sure enough, GNOME Shell crashed.)  The notification daemon
>> code is written in JavaScript (“js/ui/notificationDaemon.js”).  I
>> glanced at it and its Git history, but couldn’t find anything.
>
> I don’t think it’s notifications per se, but rendering SVGs.  When
> application_state exists, GNOME shell tries to restore application
> windows and their icons are likely SVG files that should be rendered.
>
> Chris reported elsewhere that GNOME sometimes crashes when the Activity
> tab is accessed — that’s where the application starter is, which
> displays icons.
>
> I believe we should be using librsvg-next in the closure of gnome-shell.
> We may also want to use gdk-pixbuf+svg instead of just gdk-pixbuf, but
> again replacing librsvg with librsvg-next throughout.  I’m guessing that
> the problem is entirely due to using an outdated variant of librsvg.
>
> What do you think?

To be honest, I don’t know.  From my side, I haven’t seen anything that
suggests SVGs might be the problem.  I just checked an application that
no longer has an icon since the update, and it doesn’t provide an SVG.
On the other hand, Emacs, which does provide an SVG, is fine.  I can’t
find anything in the backtrace that suggests SVG problems either.

That said, software is complicated and this is best lead we have.  Maybe
the crash I’m seeing is fallback code that gets called when SVGs aren’t
quite working.  I did try patching GTK+ the other day (for testing
something else), but gave up when I realized that it means recompiling
WebKitGTK, which takes forever.  I’ll try and patch everything later and
leave my computer to compile overnight.  Or, maybe I could pull Epiphany
out of our GNOME package, and avoid WebKitGTK (now that GNOME Shell
doesn’t need it).  Either way, I will try and test this.  If nothing
else, it might fix the bug linked above.


-- Tim

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Hey Tim,

>   (services (append (list (service gnome-desktop-service-type)
>   (set-xorg-configuration
>(xorg-configuration
> (keyboard-layout keyboard-layout)))
>   (service (service-type
> (name 'break-gnome)
> (extensions
>  (list (service-extension
> activation-service-type
> (lambda _
>   #~(let* ((pw (getpw "bob"))
>(uid (passwd:uid pw))
>(gid (passwd:gid pw)))
>   (mkdir-p 
> "/home/bob/.local/share/gnome-shell")
>   (chown "/home/bob" uid gid)
>   (chown "/home/bob/.local" 
> uid gid)
>   (chown 
> "/home/bob/.local/share" uid gid)
>   (chown 
> "/home/bob/.local/share/gnome-shell" uid gid)
>   (copy-file #$(local-file 
> "notifications")
>  
> "/home/bob/.local/share/gnome-shell/notifications")
>   (chown 
> "/home/bob/.local/share/gnome-shell/notifications" uid gid)
>   )
> (default-value #t

I have almost exactly the same, except that I used a generated
notifications file (a text file containing the string “garbage”) —
without problems.

> After running GNOME 3.28 for a while, I’ve had several crashes.  It used
> to crash whenever I opened a URL from Emacs, but fiddling with dconf has
> fixed that.  It currently crashes every time I run ERC (I’ve turned on
> notifications there), and I can’t seem to fix it.
>
> Interestingly, there is a discussion about this on the Arch Linux forums
> .  I’m not sure if
> there’s anything useful for us in there, though.

This message seems relevant:

https://bbs.archlinux.org/viewtopic.php?pid=1778640#p1778640

My issue was caused by using ubuntu-cairo. It was incompatible with
librsvg 2.42.3, which caused a crash when gnome attempted to load an
SVG when trying to display the notification. It also caused the
close window button to not appear in the overview.

> It looks like GNOME Shell passes some bad icon data into GTK+, which
> results in a null filename that gets dereferenced.  (GNOME Shell is not
> in the backtrace – it tells GTK+ to run this thread from the
> “load_texture_async” function in “st-texture-cache.c”.
>
> I think the “bad” user files are not the root cause here.  There’s
> definitely something wrong with notifications.  (I just plugged in a USB
> drive and, sure enough, GNOME Shell crashed.)  The notification daemon
> code is written in JavaScript (“js/ui/notificationDaemon.js”).  I
> glanced at it and its Git history, but couldn’t find anything.

I don’t think it’s notifications per se, but rendering SVGs.  When
application_state exists, GNOME shell tries to restore application
windows and their icons are likely SVG files that should be rendered.

Chris reported elsewhere that GNOME sometimes crashes when the Activity
tab is accessed — that’s where the application starter is, which
displays icons.

I believe we should be using librsvg-next in the closure of gnome-shell.
We may also want to use gdk-pixbuf+svg instead of just gdk-pixbuf, but
again replacing librsvg with librsvg-next throughout.  I’m guessing that
the problem is entirely due to using an outdated variant of librsvg.

What do you think?

--
Ricardo

Re: ‘staging’ and GNOME updates

[Timothy Sample]

Hi Ricardo,

Ricardo Wurmus  writes:

> Argh, it’s unfortunately incorrect.  The problem here is that
> “/home/bob” ends up being owned by root, which is the sole problem.
>
> I’m trying to find another reproducer.

I think I’ve found one.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop xorg)
(use-package-modules certs gdb gnome linux)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")
  (keyboard-layout (keyboard-layout "us" "altgr-intl"))
  (bootloader (bootloader-configuration
   (bootloader grub-efi-bootloader)
   (target "/boot/efi")
   (keyboard-layout keyboard-layout)))
  (file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
  %base-file-systems))
  (users (cons (user-account
(name "bob")
(comment "Alice's brother")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video")))
   %base-user-accounts))
  (packages (append (list nss-certs gdb gvfs strace)
%base-packages))
  (services (append (list (service gnome-desktop-service-type)
  (set-xorg-configuration
   (xorg-configuration
(keyboard-layout keyboard-layout)))
  (service (service-type
(name 'break-gnome)
(extensions
 (list (service-extension
activation-service-type
(lambda _
  #~(let* ((pw (getpw "bob"))
   (uid (passwd:uid pw))
   (gid (passwd:gid pw)))
  (mkdir-p 
"/home/bob/.local/share/gnome-shell")
  (chown "/home/bob" uid gid)
  (chown "/home/bob/.local" uid 
gid)
  (chown 
"/home/bob/.local/share" uid gid)   
   
  (chown 
"/home/bob/.local/share/gnome-shell" uid gid)
  (copy-file #$(local-file 
"notifications")
 
"/home/bob/.local/share/gnome-shell/notifications")
  (chown 
"/home/bob/.local/share/gnome-shell/notifications" uid gid)
  )
(default-value #t
%desktop-services))
  (name-service-switch %mdns-host-lookup-nss))

The notification file is attached (it’s the one that was originally
causing me problems).



notifications
Description: Binary data

After running GNOME 3.28 for a while, I’ve had several crashes.  It used
to crash whenever I opened a URL from Emacs, but fiddling with dconf has
fixed that.  It currently crashes every time I run ERC (I’ve turned on
notifications there), and I can’t seem to fix it.

Interestingly, there is a discussion about this on the Arch Linux forums
.  I’m not sure if
there’s anything useful for us in there, though.

I did get a backtrace of the crash.

#0  0x7f5b368666b6 in __strlen_sse2 () from 
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
#1  0x7f5b37718318 in do_lookup.isra () from 
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#2  0x7f5b3771890b in g_resource_get_info () from 
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#3  0x7f5b37718e8d in g_resources_get_info () from 
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#4  0x7f5b36533e15 in _gdk_pixbuf_new_from_resource_try_pixdata ()
   from 
/gnu/store/fnna82d4mjfw8qmnr5l0g3rlr07jw134-gdk-pixbuf-2.38.1/lib/libgdk_pixbuf-2.0.so.0
#5  0x7f5b36533f64 in gdk_pixbuf_new_from_resource () from 
/gnu/store/fnna82d4mjfw8qmnr5l0g3rlr07jw134-gdk-pixbuf-2.38.1/lib/libgdk_pixbuf-2.0.so.0
#6  0x7f5b37012a99 in icon_info_ensure_scale_and_pixbuf () from 
/gnu/store/4ls7vk12bckr2d74492abg81am6nz3br-gtk+-3.24.7/lib/libgtk-3.so.0
#7  0x7f5b37012d4c in load_icon_thread () from 
/gnu/store/4ls7vk12bckr2d74492abg81am6nz3br-gtk+-3.24.7/lib/libgtk-3.so.0
#8  0x7f5b3772d4cd in g_task_thread_pool_thread () from 
/gnu/store/cgy82g6yv8l1chawgch47zh23b0jll3l-glib-2.56.3/lib/libgio-2.0.so.0
#9  

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>>   (service (service-type
>> (name 'break-gnome)
>> (extensions
>>  (list (service-extension
>> activation-service-type
>> (lambda _
>>   #~(mkdir-p 
>> "/home/bob/.local/share/gnome-shell")
>> (default-value #t
>> %desktop-services))
>>   (name-service-switch %mdns-host-lookup-nss))
>>
>> Note the “break-gnome” service.  When the service does not exist,
>> everything is fine.  It seems to me that the contents of the directory
>> really do not matter after all.
>
> Nice reproducer!

Argh, it’s unfortunately incorrect.  The problem here is that
“/home/bob” ends up being owned by root, which is the sole problem.

I’m trying to find another reproducer.

--
Ricardo

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

>   (service (service-type
> (name 'break-gnome)
> (extensions
>  (list (service-extension
> activation-service-type
> (lambda _
>   #~(mkdir-p 
> "/home/bob/.local/share/gnome-shell")
> (default-value #t
> %desktop-services))
>   (name-service-switch %mdns-host-lookup-nss))
>
> Note the “break-gnome” service.  When the service does not exist,
> everything is fine.  It seems to me that the contents of the directory
> really do not matter after all.

Nice reproducer!

> Now I wonder how this affects the gnome-shell startup, because once the
> upgrade is complete things do work fine.  I wonder if there may be a
> dconf setting that is flipped after initialization.

I see that ‘shell_global_init’ in gnome-shell fiddles with “userdatadir”
(aka. ~/.local/share/gnome-shell).  At first sight it looks like it
should be idempotent, but who knows…  Perhaps we could strace it to see
what happens.

Ludo’.

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> With this system definition I cannot log into GNOME:
>
> --8<---cut here---start->8---
> (use-modules (gnu) (gnu system nss))
> (use-service-modules desktop xorg)
> (use-package-modules certs gnome)
>
> (operating-system
>   (host-name "antelope")
>   (timezone "Europe/Paris")
>   (locale "en_US.utf8")
>   (keyboard-layout (keyboard-layout "us" "altgr-intl"))
>   (bootloader (bootloader-configuration
> (bootloader grub-efi-bootloader)
> (target "/boot/efi")
> (keyboard-layout keyboard-layout)))
>   (file-systems (cons (file-system
>  (device (file-system-label "my-root"))
>  (mount-point "/")
>  (type "ext4"))
>   %base-file-systems))
>   (users (cons (user-account
> (name "bob")
> (comment "Alice's brother")
> (group "users")
> (supplementary-groups '("wheel" "netdev"
> "audio" "video")))
>%base-user-accounts))
>   (packages (append (list nss-certs gvfs)
> %base-packages))
>   (services (append (list (service gnome-desktop-service-type)
>   (set-xorg-configuration
>(xorg-configuration
> (keyboard-layout keyboard-layout)))
>   (service (service-type
> (name 'break-gnome)
> (extensions
>  (list (service-extension
> activation-service-type
> (lambda _
>   #~(mkdir-p 
> "/home/bob/.local/share/gnome-shell")
> (default-value #t
> %desktop-services))
>   (name-service-switch %mdns-host-lookup-nss))
> --8<---cut here---end--->8---

I used “./pre-inst-env guix system vm broken-gnome-vm.scm” on the
staging branch.  The resulting script needs to be run with “-m 1024” (or
higher) or else GNOME won’t work.

--
Ricardo

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello,
>
> Ludovic Courtès  skribis:
>
>> Timothy Sample  skribis:
>>
>>> Ricardo Wurmus  writes:
>>>
 Ludovic Courtès  writes:
> I removed pretty both .cache directories, moved .config sub-directories
> around, etc., and yet I am still unable to log in into the GNOME account
> (logging in to a non-GNOME account from GDM is fine.)
>
> I even tried upgrading the user’s profile just in case is contained
> incompatible schemas or who knows what, but that didn’t help.
>
> What extra bit of state am I missing?

 Do you have ~/.local?  In my earlier tests this contained binary
 notification data that when loaded would lead to a crash.
>>>
>>> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
>>> okay, but I could not login).  I fixed it by deleting
>>> “~/.local/share/gnome-shell/notifications”.  I left everything else in
>>> my home directory as it was.
>>
>> That’s the one!  I moved ~/.local/share/gnome-shell out of the way and
>> after that I could log in.  \o/
>
> So I’d really like to merge that branch, but this GNOME upgrade issue is
> holding us back.
>
> Does anyone have ideas on how to address it?

With this system definition I cannot log into GNOME:

--8<---cut here---start->8---
(use-modules (gnu) (gnu system nss))
(use-service-modules desktop xorg)
(use-package-modules certs gnome)

(operating-system
  (host-name "antelope")
  (timezone "Europe/Paris")
  (locale "en_US.utf8")
  (keyboard-layout (keyboard-layout "us" "altgr-intl"))
  (bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")
(keyboard-layout keyboard-layout)))
  (file-systems (cons (file-system
 (device (file-system-label "my-root"))
 (mount-point "/")
 (type "ext4"))
  %base-file-systems))
  (users (cons (user-account
(name "bob")
(comment "Alice's brother")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video")))
   %base-user-accounts))
  (packages (append (list nss-certs gvfs)
%base-packages))
  (services (append (list (service gnome-desktop-service-type)
  (set-xorg-configuration
   (xorg-configuration
(keyboard-layout keyboard-layout)))
  (service (service-type
(name 'break-gnome)
(extensions
 (list (service-extension
activation-service-type
(lambda _
  #~(mkdir-p 
"/home/bob/.local/share/gnome-shell")
(default-value #t
%desktop-services))
  (name-service-switch %mdns-host-lookup-nss))
--8<---cut here---end--->8---

Note the “break-gnome” service.  When the service does not exist,
everything is fine.  It seems to me that the contents of the directory
really do not matter after all.

Now I wonder how this affects the gnome-shell startup, because once the
upgrade is complete things do work fine.  I wonder if there may be a
dconf setting that is flipped after initialization.

-- 
Ricardo

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> Timothy Sample  skribis:
>
>> Ricardo Wurmus  writes:
>>
>>> Ludovic Courtès  writes:
 I removed pretty both .cache directories, moved .config sub-directories
 around, etc., and yet I am still unable to log in into the GNOME account
 (logging in to a non-GNOME account from GDM is fine.)

 I even tried upgrading the user’s profile just in case is contained
 incompatible schemas or who knows what, but that didn’t help.

 What extra bit of state am I missing?
>>>
>>> Do you have ~/.local?  In my earlier tests this contained binary
>>> notification data that when loaded would lead to a crash.
>>
>> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
>> okay, but I could not login).  I fixed it by deleting
>> “~/.local/share/gnome-shell/notifications”.  I left everything else in
>> my home directory as it was.
>
> That’s the one!  I moved ~/.local/share/gnome-shell out of the way and
> after that I could log in.  \o/

So I’d really like to merge that branch, but this GNOME upgrade issue is
holding us back.

Does anyone have ideas on how to address it?

Thanks,
Ludo’.

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Howdy,

Timothy Sample  skribis:

> Ricardo Wurmus  writes:
>
>> Ludovic Courtès  writes:
>>> I removed pretty both .cache directories, moved .config sub-directories
>>> around, etc., and yet I am still unable to log in into the GNOME account
>>> (logging in to a non-GNOME account from GDM is fine.)
>>>
>>> I even tried upgrading the user’s profile just in case is contained
>>> incompatible schemas or who knows what, but that didn’t help.
>>>
>>> What extra bit of state am I missing?
>>
>> Do you have ~/.local?  In my earlier tests this contained binary
>> notification data that when loaded would lead to a crash.
>
> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
> okay, but I could not login).  I fixed it by deleting
> “~/.local/share/gnome-shell/notifications”.  I left everything else in
> my home directory as it was.

That’s the one!  I moved ~/.local/share/gnome-shell out of the way and
after that I could log in.  \o/

~/.local/share/gnome-shell contained a single file, “application_state”.
It’s an XML file that looks exactly like the one created by the newer
GNOME: same schema, same attributes, etc.

The weird thing: if after successfully logging in, I log out, move the
old ~/.local/share/gnome-shell into place, and log in again, it works.

Perhaps the mere presence of ~/.local/share/gnome-shell causes it to
take a different path?

Thoughts?

Thank you!

Ludo’.

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Timothy Sample  writes:

> Ricardo Wurmus  writes:
[…]
>> Do you have ~/.local?  In my earlier tests this contained binary
>> notification data that when loaded would lead to a crash.
>
> I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
> okay, but I could not login).  I fixed it by deleting
> “~/.local/share/gnome-shell/notifications”.

Yes, that’s the file that caused me trouble in the past.  I cannot be
100% certain, though, that other files also needed removing.  (At least
for the GDM user it worked fine to delete the whole directory.)

> The newer GNOME seems much nicer, so this is pretty cool.  The only
> problems I see so far are that I lost my background picture,

This appears to expected when using “guix gc”.  I get this also without
a major upgrade to GNOME.  The background picture then reverts to white.

> there’s no
> icons or text for NetworkManager on the status bar

Oh, hadn’t seen this one before.

> and icons aren’t
> working for applications in my user profile.

Are these icons refered to by absolute file name?  Might they have been
garbage collected?

> Thanks Ricardo for doing the update!

Thanks for testing it!  We still have the other GNOME upgrade that’s
waiting for a rebase, which would also require some testing.

--
Ricardo

Re: ‘staging’ and GNOME updates

[Timothy Sample]

Hi Ricardo and Ludo,

Ricardo Wurmus  writes:

> Ludovic Courtès  writes:
>> I removed pretty both .cache directories, moved .config sub-directories
>> around, etc., and yet I am still unable to log in into the GNOME account
>> (logging in to a non-GNOME account from GDM is fine.)
>>
>> I even tried upgrading the user’s profile just in case is contained
>> incompatible schemas or who knows what, but that didn’t help.
>>
>> What extra bit of state am I missing?
>
> Do you have ~/.local?  In my earlier tests this contained binary
> notification data that when loaded would lead to a crash.

I’m testing GNOME on ‘staging’ now, and had the same problem (GDM worked
okay, but I could not login).  I fixed it by deleting
“~/.local/share/gnome-shell/notifications”.  I left everything else in
my home directory as it was.

The newer GNOME seems much nicer, so this is pretty cool.  The only
problems I see so far are that I lost my background picture, there’s no
icons or text for NetworkManager on the status bar, and icons aren’t
working for applications in my user profile.  I haven’t updated my
profile yet, so that might help the icons.  We’ll see.

Thanks Ricardo for doing the update!


-- Tim

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès  writes:
> I removed pretty both .cache directories, moved .config sub-directories
> around, etc., and yet I am still unable to log in into the GNOME account
> (logging in to a non-GNOME account from GDM is fine.)
>
> I even tried upgrading the user’s profile just in case is contained
> incompatible schemas or who knows what, but that didn’t help.
>
> What extra bit of state am I missing?

Do you have ~/.local?  In my earlier tests this contained binary
notification data that when loaded would lead to a crash.

-- 
Ricardo

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> Turns out that the problem was with a stale /var/lib/gdm – which makes
> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
> account’s home directory.  But it’s not like this really needs to be
> persistent, I think.

Yes, I wonder if it’s supposed to be persistent in the first place.  I
guess ~gdm/.cache can help speed things up maybe, and perhaps there are
persistent settings too, like the a18n stuff?

> I moved it out of the way and the gdm login prompt appeared within a few
> seconds.  After restarting xorg-server the directory was recreated.

So I moved ~gdm/.cache and ~/.cache out of the way and restarted
‘xorg-server’.  After that, I was still unable to log in

You removed all of ~gdm, right?

~/.cache/gdm/session.log shows this (the important bit is “killed by
signal 11” :-)):

--8<---cut here---start->8---
dbus-daemon[2867]: [session uid=30011 pid=2867] Activating service 
name='org.gtk.vfs.Daemon' requested by ':1.1' (uid=3
0011 pid=2878 comm="gsettings get org.gnome.system.locale region ")
dbus-daemon[2867]: [session uid=30011 pid=2867] Successfully activated service 
'org.gtk.vfs.Daemon'

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.032: 
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (obje
ct_type)' failed

(process:2887): GLib-GIO-CRITICAL **: 13:46:37.036: 
g_volume_monitor_get_mounts: assertion 'G_IS_VOLUME_MONITOR (volume
_monitor)' failed

(process:2887): GLib-GObject-WARNING **: 13:46:37.036: invalid (NULL) pointer 
instance

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.036: g_signal_connect_data: 
assertion 'G_TYPE_CHECK_INSTANCE (instan
ce)' failed

(process:2887): GLib-GObject-WARNING **: 13:46:37.036: invalid (NULL) pointer 
instance

(process:2887): GLib-GObject-CRITICAL **: 13:46:37.036: g_signal_connect_data: 
assertion 'G_TYPE_CHECK_INSTANCE (instan
ce)' failed

[...]

dbus-daemon[2867]: [session uid=30011 pid=2867] Successfully activated service 
'org.gtk.vfs.AfcVolumeMonitor'
GNOME Shell-Message: 13:46:38.700: No permission to trigger offline updates: 
Polkit.Error: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action 
org.freedesktop.packagekit.trigger-offline-update is not registered

(.gnome-shell-real:2928): mutter-WARNING **: 13:46:38.911: Failed to load 
background 
'file:///gnu/store/ga4arkrdndyv52cs062n2l9hgnqfjyaq-gsettings-desktop-schemas-3.28.0/share/backgrounds/gnome/adwaita-lock.jpg':
 Erreur lors de l’ouverture du fichier 
/gnu/store/ga4arkrdndyv52cs062n2l9hgnqfjyaq-gsettings-desktop-schemas-3.28.0/share/backgrounds/gnome/adwaita-lock.jpg
 : Aucun fichier ou dossier de ce type
GNOME Shell-Message: 13:46:38.917: Error loading calendars: Erreur lors de 
l’appel de StartServiceByName pour org.gnome.Shell.CalendarServer : 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.gnome.Shell.CalendarServer exited with status 1

(gsd-rfkill:3033): rfkill-plugin-WARNING **: 13:46:38.951: Error setting up 
rfkill: Could not open RFKILL control device, please verify your installation

(gsd-rfkill:3033): rfkill-plugin-WARNING **: 13:46:38.974: Could not open 
RFKILL control device, please verify your installation

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit 
service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit 
service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.063: Failed to StopUnit 
service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.systemd1 was not provided by any .service files

(gsd-sharing:3036): sharing-plugin-WARNING **: 13:46:39.070: Failed to StopUnit 
service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.systemd1 was not provided by any .service files
gnome-session-binary[2872]: WARNING: Application 'org.gnome.Shell.desktop' 
killed by signal 11

(gsd-xsettings:3007): xsettings-plugin-WARNING **: 13:46:39.193: Failed to get 
current display configuration state: 
GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected 
from message bus without replying

(gsd-power:3026): power-plugin-WARNING **: 13:46:39.193: Could not create 
GnomeRRScreen: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gnome.Mutter.DisplayConfig was not provided by any .service files


(gsd-media-keys:3022): GLib-CRITICAL **: 13:46:39.199: g_variant_get_va: 
assertion 'value != NULL' failed

(gsd-media-keys:3022): GLib-CRITICAL **: 13:46:39.199: g_variant_unref: 
assertion 'value != NULL' failed
--8<---cut here---end--->8---

> Yup, after moving /home/rekado/.cache 

Re: ‘staging’ and GNOME updates

[Ludovic Courtès]

Heya!

Ricardo Wurmus  skribis:

>> The X.org logs all end up in that directory, so it might a little
>> frustrating for someone having X.org issues if we delete that directory
>> all the time.  I don’t remember if they get copied anywhere else.
>
> Can we cause the logs to be put in /var/log with all the other logs?

I’m not sure because GDM X logs are fundamentally per-user: GDM spawns X
as a normal user, not as root (which is pretty cool!).

Ludo’.

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Hey Tim,

>> Turns out that the problem was with a stale /var/lib/gdm – which makes
>> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
>> account’s home directory.  But it’s not like this really needs to be
>> persistent, I think.
>>
>> I moved it out of the way and the gdm login prompt appeared within a few
>> seconds.  After restarting xorg-server the directory was recreated.
>>
>> Now, I *still* cannot actually log in, but the problem is likely very
>> similar.
>>
>> [two minutes pass]
>>
>> Yup, after moving /home/rekado/.cache out of the way, everything is fine
>> and I can log in.
>>
>> What should we do about this?  For gdm I think it would make sense to
>> add an activation service extension that clears the gdm user’s home
>> directory.  And more generally, maybe we should offer a generic cache
>> cleaner service.
>>
>> Thoughts?
>
> I had a similar issue where the UID of the “gdm” user had changed
> between reconfigures.  I think it happened because I removed the GDM
> service for a while and then brought it back.  It took me a while to
> figure it out, because of course everything looks fine at first glance.
> However, GDM could no longer access “/var/lib/gdm”, and I had to remove
> it to fix the problem.
>
> The X.org logs all end up in that directory, so it might a little
> frustrating for someone having X.org issues if we delete that directory
> all the time.  I don’t remember if they get copied anywhere else.

Can we cause the logs to be put in /var/log with all the other logs?

> Maybe it would make more sense to delete the “/var/lib/gdm/.cache”
> folder and ensure the permissions of the rest of it in an activation
> script.  WDYT?

That would work, too, though the .local directory (this time in my own
user’s home directory) has proven to be harmful in my past work on GNOME
upgrades.

--
Ricardo

Re: ‘staging’ and GNOME updates

[Timothy Sample]

Hi Ricardo,

Ricardo Wurmus  writes:

> Turns out that the problem was with a stale /var/lib/gdm – which makes
> me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
> account’s home directory.  But it’s not like this really needs to be
> persistent, I think.
>
> I moved it out of the way and the gdm login prompt appeared within a few
> seconds.  After restarting xorg-server the directory was recreated.
>
> Now, I *still* cannot actually log in, but the problem is likely very
> similar.
>
> [two minutes pass]
>
> Yup, after moving /home/rekado/.cache out of the way, everything is fine
> and I can log in.
>
> What should we do about this?  For gdm I think it would make sense to
> add an activation service extension that clears the gdm user’s home
> directory.  And more generally, maybe we should offer a generic cache
> cleaner service.
>
> Thoughts?

I had a similar issue where the UID of the “gdm” user had changed
between reconfigures.  I think it happened because I removed the GDM
service for a while and then brought it back.  It took me a while to
figure it out, because of course everything looks fine at first glance.
However, GDM could no longer access “/var/lib/gdm”, and I had to remove
it to fix the problem.

The X.org logs all end up in that directory, so it might a little
frustrating for someone having X.org issues if we delete that directory
all the time.  I don’t remember if they get copied anywhere else.
Taking a closer look, I see that stuff like whether the on-screen
keyboard should be displayed gets saved there, too.

Maybe it would make more sense to delete the “/var/lib/gdm/.cache”
folder and ensure the permissions of the rest of it in an activation
script.  WDYT?


-- Tim

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> I just tested the new(er) GNOME on staging and unfortunately it is *not*
>> working.  I reconfigured my workstation which previously also used
>> GNOME.
>>
>> I see a mouse pointer appearing, but gnome-shell never seems to properly
>> start.  (I’m using auto-login, so I don’t see the GDM login prompt first.)
[…]
> Everything in the VM seems to work, as discussed on IRC.
>
> So this suggests that the problem may have to do with state kept
> somewhere in GSettings or who knows what.
>
> Could you share logs from /var/log/messages, /var/log/gdm/greeter.log,
> and anything that may be relevant?

The logs are not helpful at all.  I even went through an strace of gdm
and couldn’t find anything interesting amidst all the noise.

Turns out that the problem was with a stale /var/lib/gdm – which makes
me wonder: we do we have this at all?  “/var/lib/gdm” is the “gdm” user
account’s home directory.  But it’s not like this really needs to be
persistent, I think.

I moved it out of the way and the gdm login prompt appeared within a few
seconds.  After restarting xorg-server the directory was recreated.

Now, I *still* cannot actually log in, but the problem is likely very
similar.

[two minutes pass]

Yup, after moving /home/rekado/.cache out of the way, everything is fine
and I can log in.

What should we do about this?  For gdm I think it would make sense to
add an activation service extension that clears the gdm user’s home
directory.  And more generally, maybe we should offer a generic cache
cleaner service.

Thoughts?

--
Ricardo

Re: ‘staging’ and GNOME updates

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> The other GNOME upgrade that I worked on months ago still awaits a
>> rebase onto staging.  I’ll try to get it into good shape to have the
>> build farm build it out, so that more people can test it and provide
>> fixes where needed.
>
> Perhaps we can first merge ‘staging’ in its current form, then make this
> branch the new ‘staging’ and aim for a merge as is (with only fixes
> committed there.)  How does that sound?

Sounds good.

I just tested the new(er) GNOME on staging and unfortunately it is *not*
working.  I reconfigured my workstation which previously also used
GNOME.

I see a mouse pointer appearing, but gnome-shell never seems to properly
start.  (I’m using auto-login, so I don’t see the GDM login prompt first.)

It would be good to see if this can be reproduced in a stateless system,
e.g. a virtual machine.

I already removed ~/.config/gnome-* and ~/.local/share/gnome-shell*, but
this did not change the behaviour.

Help is very welcome!

--
Ricardo

Re: ‘staging’ and GNOME updates

[Efraim Flashner]

On Sun, Mar 31, 2019 at 10:52:49PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Ricardo Wurmus  skribis:
> 
> > Ludovic Courtès  writes:
> >
> >>> I don't think we should release 1.0 until at least
> >>>  and  are
> >>> fixed.  Trying a new distribution only to find your favourite programs
> >>> are crashing would be a _terrible_ first impression.
> >>
> >> Do we have any leads on this IceCat issue?  I use IceCat daily and never
> >> have any problems of this sort, FWIW.
> >
> > I’ve seen something like this before, but *only* on i686 machines.  I
> > never managed to figure out why.
> 
> It looks like Mark fixed this in
> bc91562939ee002e84c95d13c907482b6d1e9339.  \o/
> 
> > One of the GNOME update branches (for 2.28?) has already been merged
> > into staging.  There are rumours of crashes, though, so this will
> > require testing by more people.
> 
> OK, so I guess we should first focus on getting ‘staging’ tested and
> merged.
> 
> x86_64 substitutes on ci.guix.info cover 60% of the packages right now.
> The main issue is that libdrm has one test failure (see
> ):
> 
> --8<---cut here---start->8---
> starting phase `check'
> [0/1] Running all tests.
>  1/16 kms-symbol-checkOK   0.12 s 
>  2/16 gen4-3d.batch   OK   0.04 s 
>  3/16 gen45-3d.batch  OK   0.04 s 
>  4/16 gen5-3d.batch   OK   0.04 s 
>  5/16 gen6-3d.batch   OK   0.04 s 
>  6/16 gen7-3d.batch   OK   0.04 s 
>  7/16 gen7-2d-copy.batch  OK   0.02 s 
>  8/16 intel-symbol-check  OK   0.67 s 
>  9/16 nouveau-symbol-checkOK   0.32 s 
> 10/16 radeon-symbol-check OK   0.37 s 
> 11/16 amdgpu-symbol-check OK   0.52 s 
> 12/16 threadedSKIP 0.01 s 
> 13/16 random  TIMEOUT 240.01 s 
> 14/16 hashOK   0.02 s 
> 15/16 drmsl   OK   1.23 s 
> 16/16 drmdevice   SKIP 0.01 s 
> 
> Ok:   13
> Expected Fail: 0
> Fail:  1
> Unexpected Pass:   0
> Skipped:   2
> Timeout:   1
> 
> 
> The output from the failed tests:
> 
> 13/16 random  TIMEOUT 240.01 s 
> --8<---cut here---end--->8---
> 
> > The other GNOME upgrade that I worked on months ago still awaits a
> > rebase onto staging.  I’ll try to get it into good shape to have the
> > build farm build it out, so that more people can test it and provide
> > fixes where needed.
> 
> Perhaps we can first merge ‘staging’ in its current form, then make this
> branch the new ‘staging’ and aim for a merge as is (with only fixes
> committed there.)  How does that sound?
> 
> Ludo’.
> 

This libdrm test suite timeout looks a lot like the error I was having
in the past on armhf. For armhf it's fixed on staging in fe7c6f91dda,
but it can easily be extended to other/all architectures.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

‘staging’ and GNOME updates

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>>> I don't think we should release 1.0 until at least
>>>  and  are
>>> fixed.  Trying a new distribution only to find your favourite programs
>>> are crashing would be a _terrible_ first impression.
>>
>> Do we have any leads on this IceCat issue?  I use IceCat daily and never
>> have any problems of this sort, FWIW.
>
> I’ve seen something like this before, but *only* on i686 machines.  I
> never managed to figure out why.

It looks like Mark fixed this in
bc91562939ee002e84c95d13c907482b6d1e9339.  \o/

> One of the GNOME update branches (for 2.28?) has already been merged
> into staging.  There are rumours of crashes, though, so this will
> require testing by more people.

OK, so I guess we should first focus on getting ‘staging’ tested and
merged.

x86_64 substitutes on ci.guix.info cover 60% of the packages right now.
The main issue is that libdrm has one test failure (see
):

--8<---cut here---start->8---
starting phase `check'
[0/1] Running all tests.
 1/16 kms-symbol-checkOK   0.12 s 
 2/16 gen4-3d.batch   OK   0.04 s 
 3/16 gen45-3d.batch  OK   0.04 s 
 4/16 gen5-3d.batch   OK   0.04 s 
 5/16 gen6-3d.batch   OK   0.04 s 
 6/16 gen7-3d.batch   OK   0.04 s 
 7/16 gen7-2d-copy.batch  OK   0.02 s 
 8/16 intel-symbol-check  OK   0.67 s 
 9/16 nouveau-symbol-checkOK   0.32 s 
10/16 radeon-symbol-check OK   0.37 s 
11/16 amdgpu-symbol-check OK   0.52 s 
12/16 threadedSKIP 0.01 s 
13/16 random  TIMEOUT 240.01 s 
14/16 hashOK   0.02 s 
15/16 drmsl   OK   1.23 s 
16/16 drmdevice   SKIP 0.01 s 

Ok:   13
Expected Fail: 0
Fail:  1
Unexpected Pass:   0
Skipped:   2
Timeout:   1


The output from the failed tests:

13/16 random  TIMEOUT 240.01 s 
--8<---cut here---end--->8---

> The other GNOME upgrade that I worked on months ago still awaits a
> rebase onto staging.  I’ll try to get it into good shape to have the
> build farm build it out, so that more people can test it and provide
> fixes where needed.

Perhaps we can first merge ‘staging’ in its current form, then make this
branch the new ‘staging’ and aim for a merge as is (with only fixes
committed there.)  How does that sound?

Ludo’.