gnome-shell-3.24.2 consistently dies during initialization

Done

Details

10 participants

Ben Sturmfels
Catonano
Chris Marusich
Kei Kebreau
Leo Famulari
Ludovic Courtès
Marius Bakke
Mark H Weaver
pelzflorian (Florian Pelz)
Roel Janssen

Owner: unassigned

Submitted by: Mark H Weaver

Severity: normal

Mark H Weaver wrote on 6 Jun 2017 06:59

Recipients:(address . bug-guix@gnu.org)

Message-ID:87o9u13e4i.fsf@netris.org

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:

Toggle snippet (32 lines)(.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

Mark

Ludovic Courtès wrote on 7 Jun 2017 12:37

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)(address . 27264@debbugs.gnu.org)

Message-ID:8760g8t769.fsf@gnu.org

Hi,

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

Toggle quote (2 lines)

> (.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’.

Roel Janssen wrote on 7 Jun 2017 15:15

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:rbushjcey6n.fsf@gnu.org

Ludovic Courtès writes:

Toggle quote (11 lines)> 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

Mark H Weaver wrote on 7 Jun 2017 23:58

Recipients:(name . Roel Janssen)(address . roel@gnu.org)

Message-ID:87shjbwjdc.fsf@netris.org

Roel Janssen <roel@gnu.org> writes:

Toggle quote (17 lines)> 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

Marius Bakke wrote on 8 Jun 2017 08:03

Recipients:(address . 27264@debbugs.gnu.org)

Message-ID:8760g7nhhx.fsf@fastmail.com

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

Toggle quote (25 lines)> 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.

Mark H Weaver wrote on 8 Jun 2017 08:29

Recipients:(name . Marius Bakke)(address . mbakke@fastmail.com)

Message-ID:878tl3q9g1.fsf@netris.org

Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (9 lines)

> 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.

Toggle quote (3 lines)

> 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.

Toggle quote (3 lines)

> 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

pelzflorian (Florian Pelz) wrote on 8 Jun 2017 08:48

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:20170608064821.GA476@floriannotebook

On Wed, Jun 07, 2017 at 05:58:07PM -0400, Mark H Weaver wrote:

Toggle quote (7 lines)

> 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

Ben Sturmfels wrote on 8 Jun 2017 09:39

Recipients:(address . 27264@debbugs.gnu.org)

Message-ID:5938FF18.2090706@stumbles.id.au

On 08/06/17 16:03, Marius Bakke wrote:

Toggle quote (15 lines)> 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: signature.asc

Ludovic Courtès wrote on 8 Jun 2017 14:01

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87ink6zo19.fsf@gnu.org

Hi Mark,

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

Toggle quote (21 lines)> 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?

Toggle quote (4 lines)

> 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’.

Kei Kebreau wrote on 8 Jun 2017 14:23

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87y3t2eki4.fsf@openmailbox.org

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

Toggle quote (25 lines)> 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.

Toggle quote (20 lines)>>
>> 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

---

gnu/packages/gnome.scm | 9 ++++++---

1 file changed, 6 insertions(+), 3 deletions(-)

Toggle diff (50 lines)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

Kei Kebreau wrote on 8 Jun 2017 14:35

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87tw3qejxf.fsf@openmailbox.org

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

Toggle quote (17 lines)> 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).

Toggle quote (18 lines)>> 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

Roel Janssen wrote on 8 Jun 2017 15:09

Recipients:(name . Kei Kebreau)(address . kei@openmailbox.org)

Message-ID:rbud1aeaan0.fsf@gnu.org

Kei Kebreau writes:

Toggle quote (57 lines)> 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!

Toggle quote (59 lines)>
> 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

Mark H Weaver wrote on 8 Jun 2017 16:01

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 27264@debbugs.gnu.org)

Message-ID:87vao6poh7.fsf@netris.org

Hi Ludovic,

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

Toggle quote (15 lines)> 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

pelzflorian (Florian Pelz) wrote on 8 Jun 2017 16:20

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:20170608142028.GA441@eduroam-ipv4-3-0836.triple-a.uni-kl.de

On Thu, Jun 08, 2017 at 02:01:22PM +0200, Ludovic Courtès wrote:

Toggle quote (12 lines)> 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

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

Chris Marusich wrote on 8 Jun 2017 16:54

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:871squ8r8i.fsf@gmail.com

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

Toggle quote (4 lines)

>>> 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.

Toggle quote (7 lines)

>> 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.

Toggle quote (4 lines)

> 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.

Toggle quote (7 lines)

> 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.

Toggle quote (6 lines)

> 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

Marius Bakke wrote on 8 Jun 2017 18:13

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87vao6mp8j.fsf@fastmail.com

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

Toggle quote (16 lines)> 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).

From 66dbac1f0faa75fc60c75cb1375cd9283ef1c7ed Mon Sep 17 00:00:00 2001

* gnu/packages/gnome.scm (geoclue)[native-inputs]: Add GOBJECT-INTROSPECTION.

---

gnu/packages/gnome.scm | 1 +

1 file changed, 1 insertion(+)

Toggle diff (45 lines)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

Marius Bakke wrote on 8 Jun 2017 18:29

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)

Message-ID:87shjamoiw.fsf@fastmail.com

Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (3 lines)

> 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.

Leo Famulari wrote on 8 Jun 2017 19:08

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)(address . 27264@debbugs.gnu.org)

Message-ID:20170608170842.GB27164@jasmine

On Thu, Jun 08, 2017 at 10:01:56AM -0400, Mark H Weaver wrote:

Toggle quote (12 lines)> 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.

Toggle quote (6 lines)

> 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.

Marius Bakke wrote on 8 Jun 2017 19:19

Recipients:(address . 27264@debbugs.gnu.org)

Message-ID:87poeemm7s.fsf@fastmail.com

Leo Famulari <leo@famulari.name> writes:

Toggle quote (27 lines)>> 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.

Catonano wrote on 8 Jun 2017 19:29

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:CAJ98PDx7jnf1Wdfst4FqB3zr62GAiNXco_7OBtTHLbapK25EOw@mail.gmail.com

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

Toggle quote (46 lines)> 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: file

Leo Famulari wrote on 8 Jun 2017 19:45

Recipients:(name . Catonano)(address . catonano@gmail.com)(address . 27264@debbugs.gnu.org)

Message-ID:20170608174541.GA2313@jasmine

On Thu, Jun 08, 2017 at 07:29:06PM +0200, Catonano wrote:

Toggle quote (5 lines)

> 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.

Toggle quote (10 lines)> 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.

Toggle quote (2 lines)

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

Thanks, I'll keep you in mind :)

Roel Janssen wrote on 8 Jun 2017 20:08

Recipients:(name . Kei Kebreau)(address . kei@openmailbox.org)

Message-ID:87lgp2fj3u.fsf@gnu.org

From 7b5c3ce6386acf1f7a965d19cd6dd51c662ba5bb Mon Sep 17 00:00:00 2001

* gnu/packages/gnome.scm (gnome-shell): Add geoclue and librsvg inputs.

---

gnu/packages/gnome.scm | 6 +++++-

1 file changed, 5 insertions(+), 1 deletion(-)

Toggle diff (33 lines)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

Kei Kebreau writes:

Toggle quote (116 lines)> 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

Leo Famulari wrote on 8 Jun 2017 20:12

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)(address . 27264@debbugs.gnu.org)

Message-ID:20170608181253.GA2996@jasmine

On Thu, Jun 08, 2017 at 01:08:42PM -0400, Leo Famulari wrote:

Toggle quote (7 lines)

> 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.

Kei Kebreau wrote on 8 Jun 2017 20:34

Recipients:(name . Roel Janssen)(address . roel@gnu.org)

Message-ID:87ink6e3by.fsf@openmailbox.org

Roel Janssen <roel@gnu.org> writes:

Toggle quote (128 lines)> 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

Ludovic Courtès wrote on 8 Jun 2017 22:47

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)(address . 27264@debbugs.gnu.org)

Message-ID:87lgp2p5pv.fsf@gnu.org

Hello Mark,

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

Toggle quote (27 lines)> 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.

Toggle quote (6 lines)

> 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’.

Chris Marusich wrote on 9 Jun 2017 08:23

Recipients:(name . Marius Bakke)(address . mbakke@fastmail.com)

Message-ID:87r2ytznkd.fsf@gmail.com

Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (8 lines)

>> 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

Mark H Weaver wrote on 9 Jun 2017 09:02

Recipients:(name . Marius Bakke)(address . mbakke@fastmail.com)

Message-ID:87vao5myoa.fsf@netris.org

Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (8 lines)

> 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

Closed

Mark H Weaver wrote on 11 Jun 2017 10:57

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 27264@debbugs.gnu.org)

Message-ID:874lvm52bn.fsf@netris.org

Hi Ludovic,

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

Toggle quote (16 lines)> 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.

Toggle quote (3 lines)

> 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

Ludovic Courtès wrote on 11 Jun 2017 15:16

Recipients:(name . Mark H Weaver)(address . mhw@netris.org)(address . 27264@debbugs.gnu.org)

Message-ID:87zidevf5b.fsf@gnu.org

Hi Mark,

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

Toggle quote (4 lines)

> 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.

Toggle quote (5 lines)

> 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’.

Your comment

This issue is archived.

To comment on this conversation send an email to 27264@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date