bug#27264: gnome-shell-3.24.2 consistently dies during initialization

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Mark H Weaver]

On my x86_64-linux system running GuixSD, on my first attempt to update
my system since 'staging' was merged, GNOME Shell consistently fails to
start.  If I switch to tty1 (text console), I see this error message:

--8<---------------cut here---------------start------------->8---
(.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error: Requiring Rsvg, version none: Typelib file for namespace 'Rsvg' (any version) not found
@resource:///org/gnome/shell/ui/padOsd.js:8:7
@resource:///org/gnome/shell/ui/windowManager.js:20:7
@resource:///org/gnome/shell/ui/workspace.js:19:7
@resource:///org/gnome/shell/ui/appDisplay.js:26:7
@resource:///org/gnome/shell/ui/dash.js:13:7
@resource:///org/gnome/shell/ui/overviewControls.js:10:7
@resource:///org/gnome/shell/ui/overview.js:20:7
@resource:///org/gnome/shell/ui/legacyTray.js:12:7
@resource:///org/gnome/shell/ui/main.js:23:7
@<main>:1:31

** Message: Execution of main.js threw exception: JS_EvaluateScript() failed
gnome-session-binary[11649]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1

(.gnome-shell-real:11717): Gjs-WARNING **: JS ERROR: Error: Requiring Rsvg, version none: Typelib file for namespace 'Rsvg' (any version) not found
@resource:///org/gnome/shell/ui/padOsd.js:8:7
@resource:///org/gnome/shell/ui/windowManager.js:20:7
@resource:///org/gnome/shell/ui/workspace.js:19:7
@resource:///org/gnome/shell/ui/appDisplay.js:26:7
@resource:///org/gnome/shell/ui/dash.js:13:7
@resource:///org/gnome/shell/ui/overviewControls.js:10:7
@resource:///org/gnome/shell/ui/overview.js:20:7
@resource:///org/gnome/shell/ui/legacyTray.js:12:7
@resource:///org/gnome/shell/ui/main.js:23:7
@<main>:1:31

** Message: Execution of main.js threw exception: JS_EvaluateScript() failed
gnome-session-binary[11649]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
gnome-session-binary[11649]: WARNING: App 'org.gnome.Shell.desktop' respawning too quickly
--8<---------------cut here---------------end--------------->8---

       Mark

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error: Requiring Rsvg, version none: Typelib file for namespace 'Rsvg' (any version) not found

Looks like the librsvg JS bindings are missing.  Would it help to add
librsvg as an input to ‘gnome-shell’?

Ludo’.

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Roel Janssen]

Ludovic Courtès writes:

> Hi,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error: Requiring Rsvg, version none: Typelib file for namespace 'Rsvg' (any version) not found
>
> Looks like the librsvg JS bindings are missing.  Would it help to add
> librsvg as an input to ‘gnome-shell’?
>
> Ludo’.

Adding librsvg to gnome-shell solves this problem, however, a similar
error for Geoclue2 occurs.  I added 'geoclue' to the inputs, but that
doesn't solve the problem.

Kind regards,
Roel Janssen

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Mark H Weaver]

Roel Janssen <roel@gnu.org> writes:

> Ludovic Courtès writes:
>
>> Hi,
>>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error: Requiring Rsvg, version none: Typelib file for namespace 'Rsvg' (any version) not found
>>
>> Looks like the librsvg JS bindings are missing.  Would it help to add
>> librsvg as an input to ‘gnome-shell’?
>>
>> Ludo’.
>
> Adding librsvg to gnome-shell solves this problem, however, a similar
> error for Geoclue2 occurs.  I added 'geoclue' to the inputs, but that
> doesn't solve the problem.

Thanks.

I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
that would be useful information.  If not, I wonder why this got merged
into master.

      Mark

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Roel Janssen <roel@gnu.org> writes:
>
>> Ludovic Courtès writes:
>>
>>> Hi,
>>>
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error: Requiring Rsvg, version none: Typelib file for namespace 'Rsvg' (any version) not found
>>>
>>> Looks like the librsvg JS bindings are missing.  Would it help to add
>>> librsvg as an input to ‘gnome-shell’?
>>>
>>> Ludo’.
>>
>> Adding librsvg to gnome-shell solves this problem, however, a similar
>> error for Geoclue2 occurs.  I added 'geoclue' to the inputs, but that
>> doesn't solve the problem.
>
> Thanks.
>
> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
> that would be useful information.  If not, I wonder why this got merged
> into master.

I'm sorry, I don't actually use GNOME and should have tested it before
pushing. I have been busy lately and didn't want to hold up the branch.

It would be good to have a system test for GNOME and other DEs so we can
catch these problems earlier.

I'll try to help fixing this later today, but feel free to revert the
updates meanwhile.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Mark H Weaver]

Marius Bakke <mbakke@fastmail.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>> that would be useful information.  If not, I wonder why this got merged
>> into master.
>
> I'm sorry, I don't actually use GNOME and should have tested it before
> pushing. I have been busy lately and didn't want to hold up the branch.

In the future, I think that pushing an updated desktop environment to
master should only be performed by someone who is able and willing to
test it.  Modern desktop environments are quite complex, and many things
can go wrong even if the code compiles.

> It would be good to have a system test for GNOME and other DEs so we can
> catch these problems earlier.

I agree that it would be good to have this, but it would require a
massive effort to produce a sufficiently comprehensive test suite to
render manual testing unnecessary.  In the meantime, automated testing
is not an adequate substitute for user testing.  To my mind, only
someone who actually uses the DE in question to do real work will be
able to meaningfully judge the result as usable.

> I'll try to help fixing this later today, but feel free to revert the
> updates meanwhile.

GNOME contains a great many components, and I don't fully understand
their interdependencies.  It's not something that can be easily
reverted.

      Mark

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>>> that would be useful information.  If not, I wonder why this got merged
>>> into master.
>>
>> I'm sorry, I don't actually use GNOME and should have tested it before
>> pushing. I have been busy lately and didn't want to hold up the branch.
>
> In the future, I think that pushing an updated desktop environment to
> master should only be performed by someone who is able and willing to
> test it.  Modern desktop environments are quite complex, and many things
> can go wrong even if the code compiles.
>

I had intended to test GNOME as a whole before having it pushed to
master, but the speed of my hardware is an impediment to updating the
packages in a timely fashion. I'd be more than willing to take up
learning how GNOME works and maintenance of the GNOME packages, but
things will take longer (though that's certainly more tolerable than a
broken GNOME desktop).

>> It would be good to have a system test for GNOME and other DEs so we can
>> catch these problems earlier.
>
> I agree that it would be good to have this, but it would require a
> massive effort to produce a sufficiently comprehensive test suite to
> render manual testing unnecessary.  In the meantime, automated testing
> is not an adequate substitute for user testing.  To my mind, only
> someone who actually uses the DE in question to do real work will be
> able to meaningfully judge the result as usable.
>
>> I'll try to help fixing this later today, but feel free to revert the
>> updates meanwhile.
>
> GNOME contains a great many components, and I don't fully understand
> their interdependencies.  It's not something that can be easily
> reverted.
>
>       Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Marius Bakke]

[-- Attachment #1.1: Type: text/plain, Size: 1196 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>>> that would be useful information.  If not, I wonder why this got merged
>>> into master.
>>
>> I'm sorry, I don't actually use GNOME and should have tested it before
>> pushing. I have been busy lately and didn't want to hold up the branch.
>
> In the future, I think that pushing an updated desktop environment to
> master should only be performed by someone who is able and willing to
> test it.  Modern desktop environments are quite complex, and many things
> can go wrong even if the code compiles.

I agree completely and take full responsibility for this breakage. There
were a couple of unfortunate events leading up to this: first the
'gnome-updates' branch got "destroyed"; causing it to be merged into
'staging', which in turn was holding up the 'core-updates' progress.

In the future I won't go through with such a large update without
getting feedback from actual users.

Mark, others: Can you try these patches and see if they work for you
(extracted from Keis patch).


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: gnome-shell-fix.patch --]
[-- Type: text/x-patch, Size: 1951 bytes --]

From 66dbac1f0faa75fc60c75cb1375cd9283ef1c7ed Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Thu, 8 Jun 2017 18:00:01 +0200
Subject: [PATCH 1/2] gnu: geoclue: Create typelib files.

* gnu/packages/gnome.scm (geoclue)[native-inputs]: Add GOBJECT-INTROSPECTION.
---
 gnu/packages/gnome.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 84ae1cf2f..4069abab8 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -2634,6 +2634,7 @@ output devices.")
                          (("/bin/true") (which "true"))))))))
     (native-inputs
      `(("pkg-config" ,pkg-config)
+       ("gobject-introspection" ,gobject-introspection)
        ("intltool" ,intltool)))
     (inputs
      `(("avahi" ,avahi)
-- 
2.13.1


From 668bb232493ffa8518b6f5f43e04224ae017d062 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Thu, 8 Jun 2017 18:04:20 +0200
Subject: [PATCH 2/2] gnu: gnome-shell: Fix startup failure.

Fixes <https://bugs.gnu.org/27264>.

* gnu/packages/gnome.scm (gnome-shell)[inputs]: Add LIBRSVG and GEOCLUE.
---
 gnu/packages/gnome.scm | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 4069abab8..9ea3bb07a 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -5111,6 +5111,10 @@ properties, screen resolution, and other GNOME parameters.")
        ("startup-notification" ,startup-notification)
        ("telepathy-logger" ,telepathy-logger)
        ("upower" ,upower)
+       ;; XXX: These requirements were added in 3.24, but no mention in NEWS.
+       ;; Missing propagation? See also: <https://bugs.gnu.org/27264>
+       ("librsvg" ,librsvg)
+       ("geoclue" ,geoclue)
        ;; XXX: required by libgjs.la.
        ("readline" ,readline)))
     (synopsis "Desktop shell for GNOME")
-- 
2.13.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Mark, others: Can you try these patches and see if they work for you
> (extracted from Keis patch).

Actually, I just pushed them to 'master' since geoclue rebuilds
'webkitgtk' and Kei had already verified that gnome-shell now starts.

Let's make further adjustments as needed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

>> Mark, others: Can you try these patches and see if they work for you
>> (extracted from Keis patch).
>
> Actually, I just pushed them to 'master' since geoclue rebuilds
> 'webkitgtk' and Kei had already verified that gnome-shell now starts.
>
> Let's make further adjustments as needed.

This works for me; after running "guix pull" and reconfiguring, I can
log into GNOME3 again.  Thank you for the quick fix!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Mark H Weaver]

Marius Bakke <mbakke@fastmail.com> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Mark, others: Can you try these patches and see if they work for you
>> (extracted from Keis patch).
>
> Actually, I just pushed them to 'master' since geoclue rebuilds
> 'webkitgtk' and Kei had already verified that gnome-shell now starts.

The patches you pushed to master fix the problem for me.  Thank you for
taking care of this.  I'm closing this bug now.

      Mark

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Ben Sturmfels]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On 08/06/17 16:03, Marius Bakke wrote:
> Mark H Weaver <mhw@netris.org> writes:
>>
>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>> that would be useful information.  If not, I wonder why this got merged
>> into master.
> 
> I'm sorry, I don't actually use GNOME and should have tested it before
> pushing. I have been busy lately and didn't want to hold up the branch.
> 
> It would be good to have a system test for GNOME and other DEs so we can
> catch these problems earlier.
> 
> I'll try to help fixing this later today, but feel free to revert the
> updates meanwhile.

That aside, thanks for your all your great packaging work Marius! I
really appreciate it! :D


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[pelzflorian (Florian Pelz)]

On Wed, Jun 07, 2017 at 05:58:07PM -0400, Mark H Weaver wrote:
> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
> that would be useful information.  If not, I wonder why this got merged
> into master.
> 
>       Mark
> 

It does not work for me. I get the same error. I'm using the virtual
console for now.

Regards,
Florian

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> Roel Janssen <roel@gnu.org> writes:
>
>> Ludovic Courtès writes:
>>
>>> Hi,
>>>
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error: Requiring Rsvg, version none: Typelib file for namespace 'Rsvg' (any version) not found
>>>
>>> Looks like the librsvg JS bindings are missing.  Would it help to add
>>> librsvg as an input to ‘gnome-shell’?
>>>
>>> Ludo’.
>>
>> Adding librsvg to gnome-shell solves this problem, however, a similar
>> error for Geoclue2 occurs.  I added 'geoclue' to the inputs, but that
>> doesn't solve the problem.
>
> Thanks.

Great, could you this fix if you haven’t already?

> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
> that would be useful information.  If not, I wonder why this got merged
> into master.

I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
I suppose we just didn’t test a full GNOME setup.

Next time we should probably do that or, even better, have an automated
test that logs in, takes a screenshot, and does some OCR to check
whether we got something that looks like a GNOME screen.

WDYT?

Ludo’.

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Kei Kebreau]

[-- Attachment #1.1: Type: text/plain, Size: 1887 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Mark,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Roel Janssen <roel@gnu.org> writes:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Hi,
>>>>
>>>> Mark H Weaver <mhw@netris.org> skribis:
>>>>
>>>>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error:
>>>> Requiring Rsvg, version none: Typelib file for namespace 'Rsvg'
>>>> (any version) not found
>>>>
>>>> Looks like the librsvg JS bindings are missing.  Would it help to add
>>>> librsvg as an input to ‘gnome-shell’?
>>>>
>>>> Ludo’.
>>>
>>> Adding librsvg to gnome-shell solves this problem, however, a similar
>>> error for Geoclue2 occurs.  I added 'geoclue' to the inputs, but that
>>> doesn't solve the problem.

I've found that adding gobject-introspection as a native-input to
geoclue first allows geoclue to generate the required typelib
file. FWIW, I'm writing this in an instance of gnome-shell.

>>
>> Thanks.
>
> Great, could you this fix if you haven’t already?
>
>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>> that would be useful information.  If not, I wonder why this got merged
>> into master.
>
> I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
> I suppose we just didn’t test a full GNOME setup.
>
> Next time we should probably do that or, even better, have an automated
> test that logs in, takes a screenshot, and does some OCR to check
> whether we got something that looks like a GNOME screen.
>
> WDYT?
>
> Ludo’.

I definitely agree. To get gnome-shell running on machine required the
at least the attached patch (the librsvg upgrade is not necessary to my
knowledge). I get more warnings about gnome-shell trying and failing to
run the "ibus-daemon" command, a suggestion for geoclue to use
glib-networking for TLS/SSL support.


[-- Attachment #1.2: 0001-Fix-gnome-shell.patch --]
[-- Type: text/plain, Size: 2224 bytes --]

From ed08a066c075bf19f1ea92f4abd0d20dc61d59eb Mon Sep 17 00:00:00 2001
From: Kei Kebreau <kei@openmailbox.org>
Date: Thu, 8 Jun 2017 08:15:53 -0400
Subject: [PATCH] Fix gnome-shell.

---
 gnu/packages/gnome.scm | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 84ae1cf2f..6528221a8 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -1066,7 +1066,7 @@ dealing with different structured file formats.")
 (define-public librsvg
   (package
     (name "librsvg")
-    (version "2.40.16")
+    (version "2.40.17")
     (source (origin
               (method url-fetch)
               (uri (string-append "mirror://gnome/sources/" name "/"
@@ -1074,7 +1074,7 @@ dealing with different structured file formats.")
                                   name "-" version ".tar.xz"))
               (sha256
                (base32
-                "0bpz6gsq8xi1pb5k9ax6vinph460v14znch3y5yz167s0dmwz2yl"))))
+                "1k39gyf7f5m9x0jvpcxvfcqswdb04xhm1lbwbjabn1f4xk5wbxp6"))))
     (build-system gnu-build-system)
     (arguments
      `(#:phases
@@ -2633,7 +2633,8 @@ output devices.")
                        (substitute* "configure"
                          (("/bin/true") (which "true"))))))))
     (native-inputs
-     `(("pkg-config" ,pkg-config)
+     `(("gobject-introspection" ,gobject-introspection)
+       ("pkg-config" ,pkg-config)
        ("intltool" ,intltool)))
     (inputs
      `(("avahi" ,avahi)
@@ -5090,6 +5091,7 @@ properties, screen resolution, and other GNOME parameters.")
        ("evolution-data-server" ,evolution-data-server)
        ("gcr" ,gcr)
        ("gdm" ,gdm)
+       ("geoclue" ,geoclue)
        ("gjs" ,gjs)
        ("gnome-bluetooth" ,gnome-bluetooth)
        ("gnome-control-center" ,gnome-control-center)
@@ -5100,6 +5102,7 @@ properties, screen resolution, and other GNOME parameters.")
        ("libcanberra" ,libcanberra)
        ("libcroco" ,libcroco)
        ("libgweather" ,libgweather)
+       ("librsvg" ,librsvg)
        ("libsoup" ,libsoup)
        ("mesa-headers" ,mesa-headers)
        ("mutter" ,mutter)
-- 
2.13.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Roel Janssen]

Kei Kebreau writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Mark,
>>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Roel Janssen <roel@gnu.org> writes:
>>>
>>>> Ludovic Courtès writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> Mark H Weaver <mhw@netris.org> skribis:
>>>>>
>>>>>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error:
>>>>> Requiring Rsvg, version none: Typelib file for namespace 'Rsvg'
>>>>> (any version) not found
>>>>>
>>>>> Looks like the librsvg JS bindings are missing.  Would it help to add
>>>>> librsvg as an input to ‘gnome-shell’?
>>>>>
>>>>> Ludo’.
>>>>
>>>> Adding librsvg to gnome-shell solves this problem, however, a similar
>>>> error for Geoclue2 occurs.  I added 'geoclue' to the inputs, but that
>>>> doesn't solve the problem.
>
> I've found that adding gobject-introspection as a native-input to
> geoclue first allows geoclue to generate the required typelib
> file. FWIW, I'm writing this in an instance of gnome-shell.
>
>>>
>>> Thanks.
>>
>> Great, could you this fix if you haven’t already?
>>
>>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>>> that would be useful information.  If not, I wonder why this got merged
>>> into master.
>>
>> I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
>> I suppose we just didn’t test a full GNOME setup.
>>
>> Next time we should probably do that or, even better, have an automated
>> test that logs in, takes a screenshot, and does some OCR to check
>> whether we got something that looks like a GNOME screen.
>>
>> WDYT?
>>
>> Ludo’.
>
> I definitely agree. To get gnome-shell running on machine required the
> at least the attached patch (the librsvg upgrade is not necessary to my
> knowledge). I get more warnings about gnome-shell trying and failing to
> run the "ibus-daemon" command, a suggestion for geoclue to use
> glib-networking for TLS/SSL support.

There's also "geoclue-glib", so you may need to add that to the inputs
for gnome-shell as well.

But at least gnome-shell runs with the attached patch?  If so, then I'd
say, apply it!

>
> From ed08a066c075bf19f1ea92f4abd0d20dc61d59eb Mon Sep 17 00:00:00 2001
> From: Kei Kebreau <kei@openmailbox.org>
> Date: Thu, 8 Jun 2017 08:15:53 -0400
> Subject: [PATCH] Fix gnome-shell.
>
> ---
>  gnu/packages/gnome.scm | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 84ae1cf2f..6528221a8 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -1066,7 +1066,7 @@ dealing with different structured file formats.")
>  (define-public librsvg
>    (package
>      (name "librsvg")
> -    (version "2.40.16")
> +    (version "2.40.17")
>      (source (origin
>                (method url-fetch)
>                (uri (string-append "mirror://gnome/sources/" name "/"
> @@ -1074,7 +1074,7 @@ dealing with different structured file formats.")
>                                    name "-" version ".tar.xz"))
>                (sha256
>                 (base32
> -                "0bpz6gsq8xi1pb5k9ax6vinph460v14znch3y5yz167s0dmwz2yl"))))
> +                "1k39gyf7f5m9x0jvpcxvfcqswdb04xhm1lbwbjabn1f4xk5wbxp6"))))
>      (build-system gnu-build-system)
>      (arguments
>       `(#:phases
> @@ -2633,7 +2633,8 @@ output devices.")
>                         (substitute* "configure"
>                           (("/bin/true") (which "true"))))))))
>      (native-inputs
> -     `(("pkg-config" ,pkg-config)
> +     `(("gobject-introspection" ,gobject-introspection)
> +       ("pkg-config" ,pkg-config)
>         ("intltool" ,intltool)))
>      (inputs
>       `(("avahi" ,avahi)
> @@ -5090,6 +5091,7 @@ properties, screen resolution, and other GNOME parameters.")
>         ("evolution-data-server" ,evolution-data-server)
>         ("gcr" ,gcr)
>         ("gdm" ,gdm)
> +       ("geoclue" ,geoclue)
>         ("gjs" ,gjs)
>         ("gnome-bluetooth" ,gnome-bluetooth)
>         ("gnome-control-center" ,gnome-control-center)
> @@ -5100,6 +5102,7 @@ properties, screen resolution, and other GNOME parameters.")
>         ("libcanberra" ,libcanberra)
>         ("libcroco" ,libcroco)
>         ("libgweather" ,libgweather)
> +       ("librsvg" ,librsvg)
>         ("libsoup" ,libsoup)
>         ("mesa-headers" ,mesa-headers)
>         ("mutter" ,mutter)

LGTM.

Kind regards,
Roel Janssen

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Roel Janssen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: 0001-gnu-gnome-shell-Fix-run-time-crash.patch --]
[-- Type: text/x-patch, Size: 1554 bytes --]

From 7b5c3ce6386acf1f7a965d19cd6dd51c662ba5bb Mon Sep 17 00:00:00 2001
From: Roel Janssen <roel@gnu.org>
Date: Thu, 8 Jun 2017 20:04:04 +0200
Subject: [PATCH] gnu: gnome-shell: Fix run-time crash.

* gnu/packages/gnome.scm (gnome-shell): Add geoclue and librsvg inputs.
---
 gnu/packages/gnome.scm | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 84ae1cf2f..65f022750 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -2634,7 +2634,8 @@ output devices.")
                          (("/bin/true") (which "true"))))))))
     (native-inputs
      `(("pkg-config" ,pkg-config)
-       ("intltool" ,intltool)))
+       ("intltool" ,intltool)
+       ("gobject-introspection" ,gobject-introspection)))
     (inputs
      `(("avahi" ,avahi)
        ("glib" ,glib)
@@ -5091,6 +5092,8 @@ properties, screen resolution, and other GNOME parameters.")
        ("gcr" ,gcr)
        ("gdm" ,gdm)
        ("gjs" ,gjs)
+       ("geoclue" ,geoclue)
+       ("geocode-glib" ,geocode-glib)
        ("gnome-bluetooth" ,gnome-bluetooth)
        ("gnome-control-center" ,gnome-control-center)
        ("gnome-desktop" ,gnome-desktop)
@@ -5101,6 +5104,7 @@ properties, screen resolution, and other GNOME parameters.")
        ("libcroco" ,libcroco)
        ("libgweather" ,libgweather)
        ("libsoup" ,libsoup)
+       ("librsvg" ,librsvg)
        ("mesa-headers" ,mesa-headers)
        ("mutter" ,mutter)
        ("network-manager-applet" ,network-manager-applet)
-- 
2.13.0


[-- Attachment #2: Type: text/plain, Size: 4473 bytes --]


Kei Kebreau writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Mark,
>>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Roel Janssen <roel@gnu.org> writes:
>>>
>>>> Ludovic Courtès writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> Mark H Weaver <mhw@netris.org> skribis:
>>>>>
>>>>>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error:
>>>>> Requiring Rsvg, version none: Typelib file for namespace 'Rsvg'
>>>>> (any version) not found
>>>>>
>>>>> Looks like the librsvg JS bindings are missing.  Would it help to add
>>>>> librsvg as an input to ‘gnome-shell’?
>>>>>
>>>>> Ludo’.
>>>>
>>>> Adding librsvg to gnome-shell solves this problem, however, a similar
>>>> error for Geoclue2 occurs.  I added 'geoclue' to the inputs, but that
>>>> doesn't solve the problem.
>
> I've found that adding gobject-introspection as a native-input to
> geoclue first allows geoclue to generate the required typelib
> file. FWIW, I'm writing this in an instance of gnome-shell.
>
>>>
>>> Thanks.
>>
>> Great, could you this fix if you haven’t already?
>>
>>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>>> that would be useful information.  If not, I wonder why this got merged
>>> into master.
>>
>> I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
>> I suppose we just didn’t test a full GNOME setup.
>>
>> Next time we should probably do that or, even better, have an automated
>> test that logs in, takes a screenshot, and does some OCR to check
>> whether we got something that looks like a GNOME screen.
>>
>> WDYT?
>>
>> Ludo’.
>
> I definitely agree. To get gnome-shell running on machine required the
> at least the attached patch (the librsvg upgrade is not necessary to my
> knowledge). I get more warnings about gnome-shell trying and failing to
> run the "ibus-daemon" command, a suggestion for geoclue to use
> glib-networking for TLS/SSL support.
>
> From ed08a066c075bf19f1ea92f4abd0d20dc61d59eb Mon Sep 17 00:00:00 2001
> From: Kei Kebreau <kei@openmailbox.org>
> Date: Thu, 8 Jun 2017 08:15:53 -0400
> Subject: [PATCH] Fix gnome-shell.
>
> ---
>  gnu/packages/gnome.scm | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 84ae1cf2f..6528221a8 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -1066,7 +1066,7 @@ dealing with different structured file formats.")
>  (define-public librsvg
>    (package
>      (name "librsvg")
> -    (version "2.40.16")
> +    (version "2.40.17")
>      (source (origin
>                (method url-fetch)
>                (uri (string-append "mirror://gnome/sources/" name "/"
> @@ -1074,7 +1074,7 @@ dealing with different structured file formats.")
>                                    name "-" version ".tar.xz"))
>                (sha256
>                 (base32
> -                "0bpz6gsq8xi1pb5k9ax6vinph460v14znch3y5yz167s0dmwz2yl"))))
> +                "1k39gyf7f5m9x0jvpcxvfcqswdb04xhm1lbwbjabn1f4xk5wbxp6"))))
>      (build-system gnu-build-system)
>      (arguments
>       `(#:phases
> @@ -2633,7 +2633,8 @@ output devices.")
>                         (substitute* "configure"
>                           (("/bin/true") (which "true"))))))))
>      (native-inputs
> -     `(("pkg-config" ,pkg-config)
> +     `(("gobject-introspection" ,gobject-introspection)
> +       ("pkg-config" ,pkg-config)
>         ("intltool" ,intltool)))
>      (inputs
>       `(("avahi" ,avahi)
> @@ -5090,6 +5091,7 @@ properties, screen resolution, and other GNOME parameters.")
>         ("evolution-data-server" ,evolution-data-server)
>         ("gcr" ,gcr)
>         ("gdm" ,gdm)
> +       ("geoclue" ,geoclue)
>         ("gjs" ,gjs)
>         ("gnome-bluetooth" ,gnome-bluetooth)
>         ("gnome-control-center" ,gnome-control-center)
> @@ -5100,6 +5102,7 @@ properties, screen resolution, and other GNOME parameters.")
>         ("libcanberra" ,libcanberra)
>         ("libcroco" ,libcroco)
>         ("libgweather" ,libgweather)
> +       ("librsvg" ,librsvg)
>         ("libsoup" ,libsoup)
>         ("mesa-headers" ,mesa-headers)
>         ("mutter" ,mutter)


I attached your patch plus adding geoclue-glib to the minus the librsvg
upgrade.

I can confirm gnome-shell works again.  I don't get any geoclue-related
warnings/errors.  I do get warnings about missing a
"org.freedesktop.impl.portal.PermissionStore" service.

Kind regards,
Roel Janssen

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 4990 bytes --]

Roel Janssen <roel@gnu.org> writes:

> Kei Kebreau writes:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi Mark,
>>>
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> Roel Janssen <roel@gnu.org> writes:
>>>>
>>>>> Ludovic Courtès writes:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Mark H Weaver <mhw@netris.org> skribis:
>>>>>>
>>>>>>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error:
>>>>>> Requiring Rsvg, version none: Typelib file for namespace 'Rsvg'
>>>>>> (any version) not found
>>>>>>
>>>>>> Looks like the librsvg JS bindings are missing.  Would it help to add
>>>>>> librsvg as an input to ‘gnome-shell’?
>>>>>>
>>>>>> Ludo’.
>>>>>
>>>>> Adding librsvg to gnome-shell solves this problem, however, a similar
>>>>> error for Geoclue2 occurs.  I added 'geoclue' to the inputs, but that
>>>>> doesn't solve the problem.
>>
>> I've found that adding gobject-introspection as a native-input to
>> geoclue first allows geoclue to generate the required typelib
>> file. FWIW, I'm writing this in an instance of gnome-shell.
>>
>>>>
>>>> Thanks.
>>>
>>> Great, could you this fix if you haven’t already?
>>>
>>>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>>>> that would be useful information.  If not, I wonder why this got merged
>>>> into master.
>>>
>>> I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
>>> I suppose we just didn’t test a full GNOME setup.
>>>
>>> Next time we should probably do that or, even better, have an automated
>>> test that logs in, takes a screenshot, and does some OCR to check
>>> whether we got something that looks like a GNOME screen.
>>>
>>> WDYT?
>>>
>>> Ludo’.
>>
>> I definitely agree. To get gnome-shell running on machine required the
>> at least the attached patch (the librsvg upgrade is not necessary to my
>> knowledge). I get more warnings about gnome-shell trying and failing to
>> run the "ibus-daemon" command, a suggestion for geoclue to use
>> glib-networking for TLS/SSL support.
>>
>> From ed08a066c075bf19f1ea92f4abd0d20dc61d59eb Mon Sep 17 00:00:00 2001
>> From: Kei Kebreau <kei@openmailbox.org>
>> Date: Thu, 8 Jun 2017 08:15:53 -0400
>> Subject: [PATCH] Fix gnome-shell.
>>
>> ---
>>  gnu/packages/gnome.scm | 9 ++++++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
>> index 84ae1cf2f..6528221a8 100644
>> --- a/gnu/packages/gnome.scm
>> +++ b/gnu/packages/gnome.scm
>> @@ -1066,7 +1066,7 @@ dealing with different structured file formats.")
>>  (define-public librsvg
>>    (package
>>      (name "librsvg")
>> -    (version "2.40.16")
>> +    (version "2.40.17")
>>      (source (origin
>>                (method url-fetch)
>>                (uri (string-append "mirror://gnome/sources/" name "/"
>> @@ -1074,7 +1074,7 @@ dealing with different structured file formats.")
>>                                    name "-" version ".tar.xz"))
>>                (sha256
>>                 (base32
>> -                "0bpz6gsq8xi1pb5k9ax6vinph460v14znch3y5yz167s0dmwz2yl"))))
>> +                "1k39gyf7f5m9x0jvpcxvfcqswdb04xhm1lbwbjabn1f4xk5wbxp6"))))
>>      (build-system gnu-build-system)
>>      (arguments
>>       `(#:phases
>> @@ -2633,7 +2633,8 @@ output devices.")
>>                         (substitute* "configure"
>>                           (("/bin/true") (which "true"))))))))
>>      (native-inputs
>> -     `(("pkg-config" ,pkg-config)
>> +     `(("gobject-introspection" ,gobject-introspection)
>> +       ("pkg-config" ,pkg-config)
>>         ("intltool" ,intltool)))
>>      (inputs
>>       `(("avahi" ,avahi)
>> @@ -5090,6 +5091,7 @@ properties, screen resolution, and other GNOME parameters.")
>>         ("evolution-data-server" ,evolution-data-server)
>>         ("gcr" ,gcr)
>>         ("gdm" ,gdm)
>> +       ("geoclue" ,geoclue)
>>         ("gjs" ,gjs)
>>         ("gnome-bluetooth" ,gnome-bluetooth)
>>         ("gnome-control-center" ,gnome-control-center)
>> @@ -5100,6 +5102,7 @@ properties, screen resolution, and other GNOME parameters.")
>>         ("libcanberra" ,libcanberra)
>>         ("libcroco" ,libcroco)
>>         ("libgweather" ,libgweather)
>> +       ("librsvg" ,librsvg)
>>         ("libsoup" ,libsoup)
>>         ("mesa-headers" ,mesa-headers)
>>         ("mutter" ,mutter)
>
>
> I attached your patch plus adding geoclue-glib to the minus the librsvg
> upgrade.
>
> I can confirm gnome-shell works again.  I don't get any geoclue-related
> warnings/errors.  I do get warnings about missing a
> "org.freedesktop.impl.portal.PermissionStore" service.
>
> Kind regards,
> Roel Janssen

Marius pushed a patch covering everything so far except for the
geoclue-glib addition. Does using geoclue-glib get rid of the TLS/SSL
error? If so, I'll apply that as a separate patch.

Thanks in advance,
Kei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Mark H Weaver]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Mark,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>> that would be useful information.  If not, I wonder why this got merged
>> into master.
>
> I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
> I suppose we just didn’t test a full GNOME setup.
>
> Next time we should probably do that or, even better, have an automated
> test that logs in, takes a screenshot, and does some OCR to check
> whether we got something that looks like a GNOME screen.

I think this is unacceptable.  The test you propose above is no where
near adequate to assure that the updated desktop environment is usable
for real work.

I'm annoyed that I've been forced to either use a different desktop
environment in the meantime or else sacrifice security updates.  I would
never consider pushing such a major update to master without testing it
first.  I'm astonished that anyone thinks that this is acceptable
behavior.

I'm sorry to be harsh, but I feel justified to air my grievances because
I believe this is the kind of event that will cause GNOME users to label
GuixSD an experimental distribution that's not suitable for one's
primary work machine, but are too polite to complain.  Let me be the
canary in the coal mine.

While it's true that users can boot into an older generation of their
system in an emergency, and that's a *great* comfort, in general it's
not an acceptable fallback because it entails sacrificing security
updates.  I'm concerned that our fallback feature has caused people to
become quite careless with breaking things on our master branch.

     Thanks,
       Mark

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]

Mark H Weaver <mhw@netris.org> writes:

>>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>>> that would be useful information.  If not, I wonder why this got merged
>>> into master.

I just updated my system, and I observe the same problem.

>> an automated test that logs in, takes a screenshot, and does some OCR
>> to check whether we got something that looks like a GNOME screen.
>
> I think this is unacceptable.  The test you propose above is no where
> near adequate to assure that the updated desktop environment is usable
> for real work.

It would be better than nothing, since it would catch catastrophic
errors, but you're right: it's no substitute for thorough testing.  I
think it would be good to have basic sanity tests, and I agree that
changes to the desktop environments ought to be tested before merging.
In this case, it's clear that the final result was not tested.

> I would never consider pushing such a major update to master without
> testing it first.  I'm astonished that anyone thinks that this is
> acceptable behavior.

To really prevent bad updates, a mechanism is required (such as
automated tests).  A more disciplined release process and an increased
willingness by everyone to run the tests can help, too, but a (good)
mechanism will be the most reliable, since it wouldn't rely on humans
remembering to do the right thing.  I think a sanity test that confirms
we can at least log in to the various desktop environments would be a
good start - but not a total solution.

> I'm sorry to be harsh, but I feel justified to air my grievances
>because
> I believe this is the kind of event that will cause GNOME users to label
> GuixSD an experimental distribution that's not suitable for one's
> primary work machine, but are too polite to complain.  Let me be the
> canary in the coal mine.

I agree.

> While it's true that users can boot into an older generation of their
> system in an emergency, and that's a *great* comfort, in general it's
> not an acceptable fallback because it entails sacrificing security
> updates.  I'm concerned that our fallback feature has caused people to
> become quite careless with breaking things on our master branch.

I think you're right, but I think it's just one reason.

Based on what people are saying in this email thread, it sounds like
another reason why humans chose not to perform the tests was because the
iteration time is perceived as too slow.  Maybe if we can think of ways
to speed up the testing cycle, people will be less tempted to skip the
tests.  For example, if there were a way to build a "mostly correct"
system in half the time (presumably, by somehow avoiding the actual
builds required), that might encourage people to test their work more
frequently.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

On Thu, Jun 08, 2017 at 10:01:56AM -0400, Mark H Weaver wrote:
> I'm annoyed that I've been forced to either use a different desktop
> environment in the meantime or else sacrifice security updates.  I would
> never consider pushing such a major update to master without testing it
> first.  I'm astonished that anyone thinks that this is acceptable
> behavior.
> 
> I'm sorry to be harsh, but I feel justified to air my grievances because
> I believe this is the kind of event that will cause GNOME users to label
> GuixSD an experimental distribution that's not suitable for one's
> primary work machine, but are too polite to complain.  Let me be the
> canary in the coal mine.

I agree with your points. For complex interactive software, someone must
test it by actually using it. And we should remember that the master
branch is supposed to always be "deployable", and choose to test
breaking changes on other branches.

> While it's true that users can boot into an older generation of their
> system in an emergency, and that's a *great* comfort, in general it's
> not an acceptable fallback because it entails sacrificing security
> updates.  I'm concerned that our fallback feature has caused people to
> become quite careless with breaking things on our master branch.

It's true, we could not even think of pushing untested or lightly-tested
changes if we couldn't roll-back.

But, if we want to 1) receive updates to big software suites like GNOME,
and we want to 2) avoid breakage on the master branch, we *need* more
testers.

As somebody who has helped with a few of these branches so far, the lack
of assistance with testing and bug fixes is a major problem. I rarely
feel as confident as I'd like before pushing the merge. More than once
I've merged a major branch with the impression that only myself and 1 or
2 other people have actually deployed it on their workstation or in a
staging environment that precedes production.

There is a large number of contributors adding new packages or working
on features, but almost nobody helps test big changes or other boring
and tedious maintenance tasks. So, those things suffer, and we end up
testing on the master branch. I don't have any potential solutions in
mind. As we are mostly volunteers with limited time and computing
resources, we can only do so much.

Indeed, I had to sit out this staging cycle due to lack of free time and
computing resources.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

Leo Famulari <leo@famulari.name> writes:

>> While it's true that users can boot into an older generation of their
>> system in an emergency, and that's a *great* comfort, in general it's
>> not an acceptable fallback because it entails sacrificing security
>> updates.  I'm concerned that our fallback feature has caused people to
>> become quite careless with breaking things on our master branch.
>
> It's true, we could not even think of pushing untested or lightly-tested
> changes if we couldn't roll-back.
>
> But, if we want to 1) receive updates to big software suites like GNOME,
> and we want to 2) avoid breakage on the master branch, we *need* more
> testers.
>
> As somebody who has helped with a few of these branches so far, the lack
> of assistance with testing and bug fixes is a major problem. I rarely
> feel as confident as I'd like before pushing the merge. More than once
> I've merged a major branch with the impression that only myself and 1 or
> 2 other people have actually deployed it on their workstation or in a
> staging environment that precedes production.
>
> There is a large number of contributors adding new packages or working
> on features, but almost nobody helps test big changes or other boring
> and tedious maintenance tasks. So, those things suffer, and we end up
> testing on the master branch. I don't have any potential solutions in
> mind. As we are mostly volunteers with limited time and computing
> resources, we can only do so much.

I think the planned 'channels' facility will help a lot here. Then, we
might be able to say something like "please try to `guix pull --channel
staging` and report any failures" which lowers the barrier considerably.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

2017-06-08 19:08 GMT+02:00 Leo Famulari <leo@famulari.name>:

> On Thu, Jun 08, 2017 at 10:01:56AM -0400, Mark H Weaver wrote:
> > I'm annoyed that I've been forced to either use a different desktop
> > environment in the meantime or else sacrifice security updates.  I would
> > never consider pushing such a major update to master without testing it
> > first.  I'm astonished that anyone thinks that this is acceptable
> > behavior.
> >
> > I'm sorry to be harsh, but I feel justified to air my grievances because
> > I believe this is the kind of event that will cause GNOME users to label
> > GuixSD an experimental distribution that's not suitable for one's
> > primary work machine, but are too polite to complain.  Let me be the
> > canary in the coal mine.
>
> I agree with your points. For complex interactive software, someone must
> test it by actually using it. And we should remember that the master
> branch is supposed to always be "deployable", and choose to test
> breaking changes on other branches.
>
> > While it's true that users can boot into an older generation of their
> > system in an emergency, and that's a *great* comfort, in general it's
> > not an acceptable fallback because it entails sacrificing security
> > updates.  I'm concerned that our fallback feature has caused people to
> > become quite careless with breaking things on our master branch.
>
> It's true, we could not even think of pushing untested or lightly-tested
> changes if we couldn't roll-back.
>
> But, if we want to 1) receive updates to big software suites like GNOME,
> and we want to 2) avoid breakage on the master branch, we *need* more
> testers.
>
> As somebody who has helped with a few of these branches so far, the lack
> of assistance with testing and bug fixes is a major problem. I rarely
> feel as confident as I'd like before pushing the merge. More than once
> I've merged a major branch with the impression that only myself and 1 or
> 2 other people have actually deployed it on their workstation or in a
> staging environment that precedes production.
>
> There is a large number of contributors adding new packages or working
> on features, but almost nobody helps test big changes or other boring
> and tedious maintenance tasks. So, those things suffer, and we end up
> testing on the master branch. I don't have any potential solutions in
> mind. As we are mostly volunteers with limited time and computing
> resources, we can only do so much.
>

I'd love to help with testing the Gnome desktop

The reason why I abstain is because if the desktop environment turns out to
be broken, like in this case,  I wouldn't know how to work around that

I'm lost in the command line, I'm not even sure I could manage to access
the so called consoles or that I could open an alternative desktop
environment

If I had a spare computer I would use that.

Unless using a qemu based virtual machine is a good enough solution

If it is, then here I am

Send me an email, indicate me a branch and I'll test it

[-- Attachment #2: Type: text/html, Size: 3756 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

On Thu, Jun 08, 2017 at 07:29:06PM +0200, Catonano wrote:
> I'd love to help with testing the Gnome desktop
> 
> The reason why I abstain is because if the desktop environment turns out to
> be broken, like in this case,  I wouldn't know how to work around that

In general, you can always do a hard reboot and select an earlier GuixSD
generation from the GRUB menu if something goes wrong. It's not great to
do a hard reboot, but contemporary filesystems like ext4 tend to handle
it well enough.

> I'm lost in the command line, I'm not even sure I could manage to access
> the so called consoles or that I could open an alternative desktop
> environment
> 
> If I had a spare computer I would use that.
> 
> Unless using a qemu based virtual machine is a good enough solution
>
> If it is, then here I am

I think QEMU is a fine test environment for GNOME as long as you can use
the Kernel-based Virtual Machine in QEMU, which allows the VM to run at
near-native speed. When starting QEMU you'd pass '-enable-kvm'. Older
hardware may not offer KVM, unfortunately.

> Send me an email, indicate me a branch and I'll test it

Thanks, I'll keep you in mind :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Thu, Jun 08, 2017 at 01:08:42PM -0400, Leo Famulari wrote:
> There is a large number of contributors adding new packages or working
> on features, but almost nobody helps test big changes or other boring
> and tedious maintenance tasks. So, those things suffer, and we end up
> testing on the master branch. I don't have any potential solutions in
> mind. As we are mostly volunteers with limited time and computing
> resources, we can only do so much.

I'd like to clarify, I don't have a solution in mind because I don't
think it's reasonable to ask those adding packages and features to stop
that work and test things instead. Motivation is not fungible.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Ludovic Courtès]

Hello Mark,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Mark,
>>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
>>> that would be useful information.  If not, I wonder why this got merged
>>> into master.
>>
>> I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
>> I suppose we just didn’t test a full GNOME setup.
>>
>> Next time we should probably do that or, even better, have an automated
>> test that logs in, takes a screenshot, and does some OCR to check
>> whether we got something that looks like a GNOME screen.
>
> I think this is unacceptable.  The test you propose above is no where
> near adequate to assure that the updated desktop environment is usable
> for real work.
>
> I'm annoyed that I've been forced to either use a different desktop
> environment in the meantime or else sacrifice security updates.  I would
> never consider pushing such a major update to master without testing it
> first.  I'm astonished that anyone thinks that this is acceptable
> behavior.

I sympathize, and I agree that it sucks.

Now, I think we are all guilty.  Rather than trying to find someone to
blame, I’m more interested in seeing why we got there and what we can do
to avoid it in the future.  Of course we can call for GNOME users to
test it, and we’ll surely do that explicitly in the future.  But IMO we
should be thankful to those who worked on this upgrade branch, and I
feel it would be unwise to sit back and add more on their shoulders.

> While it's true that users can boot into an older generation of their
> system in an emergency, and that's a *great* comfort, in general it's
> not an acceptable fallback because it entails sacrificing security
> updates.  I'm concerned that our fallback feature has caused people to
> become quite careless with breaking things on our master branch.

This is wrong.  None of us is careless, and suggesting that this is the
case is really unpleasant.

Thanks to Marius, Kei, and Roel for working on the fix.

Ludo’.

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Mark H Weaver]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I'm annoyed that I've been forced to either use a different desktop
>> environment in the meantime or else sacrifice security updates.  I would
>> never consider pushing such a major update to master without testing it
>> first.  I'm astonished that anyone thinks that this is acceptable
>> behavior.
>
> I sympathize, and I agree that it sucks.
>
> Now, I think we are all guilty.  Rather than trying to find someone to
> blame, I’m more interested in seeing why we got there and what we can do
> to avoid it in the future.  Of course we can call for GNOME users to
> test it, and we’ll surely do that explicitly in the future.  But IMO we
> should be thankful to those who worked on this upgrade branch,

I agree that we should be thankful, and I'm sorry for not saying so in
my last message.  I'm very grateful to Marius and Kei for their
excellent work upgrading GNOME to 3.24.  I handled the upgrade to 3.22,
so I know how much work that is, and I'm glad to have been spared the
effort this time around.  I'm also grateful to Marius, Kei, and Roel for
their work on the final commits to get GNOME working.

Finding someone to blame is not my goal.  Like you, my goal is to avoid
this mistake in the future.  I don't see how to do that without calling
attention to the mistake and labeling it as such.  I did not mention any
names in my complaint.

>                                                                and I
> feel it would be unwise to sit back and add more on their shoulders.

It is not my intent to add more to anyone's shoulders.  I'm not asking
anyone to do anything.  I'm asking people *not* to do something.  I'm
asking people not to merge major upgrade branches without testing them
first.  Merging major upgrade branches is not something that should be
done without sufficient care.  If you aren't able to do the job
carefully, then don't do it.  That's not adding to anyone's shoulders.
No one is imposing deadlines on us, and this was not a security update.

I'm not sure why you think "we are all guilty".  Is it because we have a
collective responsibility to merge 'staging' more quickly than would be
possible if we waited for someone to test it first?  If so, I disagree.

On the contrary, I believe we have a responsibility to make sure major
upgrade branches are tested before they are merged, because a broken
'master' effectively means that we cannot deploy security updates to
users until the problem is fixed.

Does that make sense?

       Mark

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> I'm not sure why you think "we are all guilty".  Is it because we have a
> collective responsibility to merge 'staging' more quickly than would be
> possible if we waited for someone to test it first?  If so, I disagree.

Yes, I wrote “we are all guilty” because I think we are collectively
responsible.  Those who worked on it did their best to track and fix
problems on the branch before merging and simply overlooked this
problem; IOW, there was some testing, just not this particular test,
which, in hindsight, is a mistake.

> On the contrary, I believe we have a responsibility to make sure major
> upgrade branches are tested before they are merged, because a broken
> 'master' effectively means that we cannot deploy security updates to
> users until the problem is fixed.

I agree.

But again, the branch was tested.  Remember that gnome-shell is just one
of the many things this branch touched; many other things lower in stack
were upgraded.

IOW, let’s not be too harsh to ourselves.  We made an embarrassing
mistake; we fixed it in a couple of days, and the lesson we learned is
that we must test a full GNOME desktop the next time we upgrade things
in this area.

Ludo’.

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[pelzflorian (Florian Pelz)]

On Thu, Jun 08, 2017 at 02:01:22PM +0200, Ludovic Courtès wrote:
> I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
> I suppose we just didn’t test a full GNOME setup.
> 
> Next time we should probably do that or, even better, have an automated
> test that logs in, takes a screenshot, and does some OCR to check
> whether we got something that looks like a GNOME screen.
>
> WDYT?
> 
> Ludo’.
> 

Like a reftest, i.e. comparing a screenshot to what one expects the
screenshot to look like? You can probably take a screenshot of the
GNOME desktop by running gnome-screenshot or by making a D-Bus call to
org.gnome.Shell.Screenshot.Screenshot for a new user (so themes do not
affect it) and compare what is shown in the upper left corner. It says
Activities and the font and color of the top left corner will
presumably change rarely.

A simpler and possibly preferable solution would be checking if GNOME
can successfully start an application set to autostart as per the xdg
desktop specification without gnome-session crashing.

I am not sure how such a test can be run without disrupting a running
login session. Possibly GNOME can be launched on an X server
configured to use xf86-video-dummy like I once tried on a headless
server, see:

https://wiki.archlinux.org/index.php/Vino#Running_on_a_headless_server

I do not know if this can eventually be adapted to Wayland. Xdummy
probably does not support KMS which I believe is required on Wayland.

I so far have not got around to contributing code to the Guix project,
so I probably will not be implementing this either...

Regards,
Florian