bug#27264: gnome-shell-3.24.2 consistently dies during initialization
On 08/06/17 16:03, Marius Bakke wrote: > Mark H Weaver 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 signature.asc Description: OpenPGP digital signature
bug#27284: Memory leak in 'guix pull' or 'make' in guix source
This has been discussed on IRC and on guix-devel mailinglist but so far I haven't seen a formal bug report to make this visible. I can't find the right threads or timestamps for this bug, so take it as is and extend with facts. At the moment of writing, guix pull has the minimum requirement of 3 GB RAM. Before this started, I was able to run Guix on as little as 512MB RAM. People are currently finding out about this bug the hard way, so we should point this out. Didn't really happen so I guess someone is working on this already. -- ng0 OpenPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 signature.asc Description: PGP signature
bug#27007: [PATCH v2 2/2] doc: Adapt to multiple bootloader support.
* doc/guix.texi (GRUB configuration): Rename to "Bootloader
configuration".
Remove device-mount-point field from menu-entry description.
Adapt occurences of "GRUB" in other sections.
---
doc/guix.texi | 177 --
1 file changed, 98 insertions(+), 79 deletions(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index f69c84dea..00bf24d3f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -199,7 +199,7 @@ System Configuration
* X.509 Certificates:: Authenticating HTTPS servers.
* Name Service Switch:: Configuring libc's name service switch.
* Initial RAM Disk::Linux-Libre bootstrapping.
-* GRUB Configuration:: Configuring the boot loader.
+* Bootloader Configuration::Configuring the boot loader.
* Invoking guix system::Instantiating a system configuration.
* Running GuixSD in a VM:: How to run GuixSD in a virtual machine.
* Defining Services:: Adding new service definitions.
@@ -7797,7 +7797,7 @@ instance to support new system services.
* X.509 Certificates:: Authenticating HTTPS servers.
* Name Service Switch:: Configuring libc's name service switch.
* Initial RAM Disk::Linux-Libre bootstrapping.
-* GRUB Configuration:: Configuring the boot loader.
+* Bootloader Configuration::Configuring the boot loader.
* Invoking guix system::Instantiating a system configuration.
* Running GuixSD in a VM:: How to run GuixSD in a virtual machine.
* Defining Services:: Adding new service definitions.
@@ -7980,7 +7980,7 @@ system, should you ever need to.
Speaking of roll-back, each time you run @command{guix system
reconfigure}, a new @dfn{generation} of the system is created---without
modifying or deleting previous generations. Old system generations get
-an entry in the GRUB boot menu, allowing you to boot them in case
+an entry in the bootloader boot menu, allowing you to boot them in case
something went wrong with the latest generation. Reassuring, no? The
@command{guix system list-generations} command lists the system
generations available on disk. It is also possible to roll back the
@@ -8036,7 +8036,7 @@ List of strings or gexps representing additional
arguments to pass on
the command-line of the kernel---e.g., @code{("console=ttyS0")}.
@item @code{bootloader}
-The system bootloader configuration object. @xref{GRUB Configuration}.
+The system bootloader configuration object. @xref{Bootloader Configuration}.
@item @code{initrd} (default: @code{base-initrd})
@cindex initrd
@@ -15711,32 +15711,52 @@ upon booting. All the derivations referenced by
@var{exp} are
automatically copied to the initrd.
@end deffn
-@node GRUB Configuration
-@subsection GRUB Configuration
+@node Bootloader Configuration
+@subsection Bootloader Configuration
-@cindex GRUB
+@cindex bootloader
@cindex boot loader
-The operating system uses GNU@tie{}GRUB as its boot loader
-(@pxref{Overview, overview of GRUB,, grub, GNU GRUB Manual}). It is
-configured using a @code{grub-configuration} declaration. This data type
-is exported by the @code{(gnu system grub)} module and described below.
+The operating system supports multiple bootloaders. The bootloader is
+configured using @code{bootloader-configuration} declaration. All the
+fields of this structure are bootloader agnostic except for one field,
+@code{bootloader} that indicates the bootloader to be configured and
+installed.
-@deftp {Data Type} grub-configuration
-The type of a GRUB configuration declaration.
+Some of the bootloaders do not honor every field of
+@code{bootloader-configuration}. For instance, the extlinux
+bootloader does not support themes and thus ignores the @code{theme}
+field.
+
+@deftp {Data Type} bootloader-configuration
+The type of a bootloader configuration declaration.
@table @asis
+@item @code{bootloader}
+@cindex EFI, bootloader
+@cindex UEFI, bootloader
+@cindex BIOS, bootloader
+The bootloader to use, as a @code{bootloader} object. For now
+@code{grub-bootloader}, @code{grub-efi-bootloader} and
+@code{extlinux-bootloader} are supported. @code{grub-efi-bootloader},
+allows to boot on modern systems using the @dfn{Unified Extensible
+Firmware Interface} (UEFI).
+
+Available bootloaders are described in @code{(gnu bootloader @dots{})}
+modules.
+
@item @code{device}
This is a string denoting the boot device. It must be a device name
-understood by the @command{grub-install} command, such as
-@code{/dev/sda} or @code{(hd0)} (@pxref{Invoking grub-install,,, grub,
+understood by the bootloader @command{installer} command, such as
+@code{/dev/sda} or @code{(hd0)} (for GRUB, @pxref{Invoking grub-install,,,
grub,
GNU GRUB Manual}).
@item @code{menu-entries} (default: @code{()})
A possibly empty list of @code{menu-entry} objects (see below), denoting
-entries to appear in the GRUB boot menu, in addition to the current
+entries to a
bug#27007: [PATCH v2 1/2] bootloader: Use menu-entry to define custom bootloader entries.
* gnu/bootloader.scm (): New variable. Export associated getters, This record is extracted from grub module. * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Use menu-entry->boot-parameters to convert menu-entry records to boot-parameters. * gnu/bootloader/grub.scm (): Remove. (boot-parameters->menu-entry): Remove. (grub-configuration-file): Use boot-parameters to create configuration entries. * gnu/system.scm (menu-entry->boot-parameters): New exported procedure. --- gnu/bootloader.scm | 26 ++- gnu/bootloader/extlinux.scm | 3 +- gnu/bootloader/grub.scm | 77 ++--- gnu/system.scm | 14 + 4 files changed, 71 insertions(+), 49 deletions(-) diff --git a/gnu/bootloader.scm b/gnu/bootloader.scm index 4e77974d3..d5fcf30f0 100644 --- a/gnu/bootloader.scm +++ b/gnu/bootloader.scm @@ -23,7 +23,15 @@ #:use-module (guix records) #:use-module (guix ui) #:use-module (srfi srfi-1) - #:export (bootloader + #:export (menu-entry +menu-entry? +menu-entry-label +menu-entry-device +menu-entry-linux +menu-entry-linux-arguments +menu-entry-initrd + +bootloader bootloader? bootloader-name bootloader-package @@ -50,6 +58,22 @@ ;;; +;;; Menu-entry record. +;;; + +(define-record-type* + menu-entry make-menu-entry + menu-entry? + (label menu-entry-label) + (device menu-entry-device ; file system uuid, label, or #f + (default #f)) + (linux menu-entry-linux) + (linux-arguments menu-entry-linux-arguments + (default '())) ; list of string-valued gexps + (initrd menu-entry-initrd)) ; file name of the initrd as a gexp + + +;;; ;;; Bootloader record. ;;; diff --git a/gnu/bootloader/extlinux.scm b/gnu/bootloader/extlinux.scm index 67b8815d4..0a1263aed 100644 --- a/gnu/bootloader/extlinux.scm +++ b/gnu/bootloader/extlinux.scm @@ -37,7 +37,8 @@ corresponding to old generations of the system." (define all-entries -(append entries (bootloader-configuration-menu-entries config))) +(append entries (map menu-entry->boot-parameters + (bootloader-configuration-menu-entries config (define (boot-parameters->gexp params) (let ((label (boot-parameters-label params)) diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm index 49616b716..f1cc3324d 100644 --- a/gnu/bootloader/grub.scm +++ b/gnu/bootloader/grub.scm @@ -66,12 +66,15 @@ (define (strip-mount-point mount-point file) "Strip MOUNT-POINT from FILE, which is a gexp or other lowerable object denoting a file name." - (if (string=? mount-point "/") - file - #~(let ((file #$file)) - (if (string-prefix? #$mount-point file) - (substring #$file #$(string-length mount-point)) - file + (match mount-point +((? string? mount-point) + (if (string=? mount-point "/") + file + #~(let ((file #$file)) + (if (string-prefix? #$mount-point file) + (substring #$file #$(string-length mount-point)) + file +(#f file))) (define-record-type* grub-image make-grub-image @@ -103,19 +106,6 @@ denoting a file name." (color-highlight '((fg . yellow) (bg . black))) (color-normal'((fg . light-gray) (bg . black) ;XXX: #x303030 -(define-record-type* - menu-entry make-menu-entry - menu-entry? - (label menu-entry-label) - (device menu-entry-device ; file system uuid, label, or #f - (default #f)) - (device-mount-point menu-entry-device-mount-point - (default "/")) - (linux menu-entry-linux) - (linux-arguments menu-entry-linux-arguments - (default '())) ; list of string-valued gexps - (initrd menu-entry-initrd)) ; file name of the initrd as a gexp - ;;; ;;; Background image & themes. @@ -312,16 +302,6 @@ code." (#f #~(format #f "search --file --set ~a" #$file) -(define (boot-parameters->menu-entry conf) - "Convert a instance to a corresponding ." - (menu-entry - (label (boot-parameters-label conf)) - (device (boot-parameters-store-device conf)) - (device-mount-point (boot-parameters-store-mount-point conf)) - (linux (boot-parameters-kernel conf)) - (linux-arguments (boot-parameters-kernel-arguments conf)) - (initrd (boot-parameters-initrd conf - (define* (grub-configuration-file config entries #:key (system (%current-system)) @@ -331,33 +311,36 @@ code." STORE-FS, a object. OLD-ENTRIES is taken to be a list of menu entries corresponding to old generations of the system." (define all-entries -(map boot-parameters->menu-entry -
bug#27007: [PATCH 2/2] doc: Adapt to multiple bootloader support.
Hi, Just sent a v2 addressing your remarks ! Thanks, Mathieu > I think it would make sense to be explicit about this in the manual. > > Ludo’.
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Hi Mark, Mark H Weaver skribis: > Roel Janssen writes: > >> Ludovic Courtès writes: >> >>> Hi, >>> >>> Mark H Weaver 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
l...@gnu.org (Ludovic Courtès) writes:
> Hi Mark,
>
> Mark H Weaver skribis:
>
>> Roel Janssen writes:
>>
>>> Ludovic Courtès writes:
>>>
Hi,
Mark H Weaver 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
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
signature.asc
Description: PGP signature
bug#27282: Perl 5.26.0 "dotless @INC" [was Re: bug#27227: [PATCH] gnu: perl: Update to 5.26.0.]
Leo Famulari skribis: > Building locally, I found that SWIG fails to build with this new Perl > release due to the removal of the current directory from @INC. This > change is mentioned in the Perl release notes: > > "We removed the current directory from @INC > > We consider this a security change, and although it might cause > discomfort to some users, we had to do it. Both Perl 5 Porters and the > Toolchain Gang put effort into easing the transition to a dot-less > @INC. > > If you want to load a module from the current directory, you can still > do this in one the following ways: > > [...] > > # Use the environment variable > PERL_USE_UNSAFE_INC=1" > > http://blogs.perl.org/users/sawyer_x/2017/05/perl-5260-is-now-available.html > > It doesn't look like this has been addressed by the SWIG maintainers > yet. > > We should set this PERL_USE_UNSAFE_INC variable in the SWIG package > definition, right? Probably we will need to set it in several other > packages as well. We can do that, but probably there will be (or there is already) a patch for SWIG to not rely on having “.” in @INC, no? Thanks for the heads-up, Ludo’.
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Mark H Weaver writes: > Marius Bakke writes: > >> Mark H Weaver 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 signature.asc Description: PGP signature
bug#27007: [PATCH v2 1/2] bootloader: Use menu-entry to define custom bootloader entries.
Hi! Mathieu Othacehe skribis: > * gnu/bootloader.scm (): New variable. Export associated getters, > This record is extracted from grub module. > * gnu/bootloader/extlinux.scm (extlinux-configuration-file): Use > menu-entry->boot-parameters to convert menu-entry records to > boot-parameters. > * gnu/bootloader/grub.scm (): Remove. > (boot-parameters->menu-entry): Remove. > (grub-configuration-file): Use boot-parameters to create configuration > entries. > * gnu/system.scm (menu-entry->boot-parameters): New exported procedure. LGTM! Ludo’.
bug#27007: [PATCH v2 2/2] doc: Adapt to multiple bootloader support.
Mathieu Othacehe skribis: > * doc/guix.texi (GRUB configuration): Rename to "Bootloader > configuration". > Remove device-mount-point field from menu-entry description. > Adapt occurences of "GRUB" in other sections. LGTM. In the future, I think it’ll be preferable to commit code/tests/doc together. That is, in the commit that changes the API from being GRUB-specific to supporting multiple bootloaders, we include not only the code but also the doc update. This simplifies review, makes sure each commit is self-contained, and ensure that users get consistent documentation. Thanks again! Ludo’.
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Kei Kebreau writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Mark,
>>
>> Mark H Weaver skribis:
>>
>>> Roel Janssen writes:
>>>
Ludovic Courtès writes:
> Hi,
>
> Mark H Weaver 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
> 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
Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Hi Mark, > > Mark H Weaver 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
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
bug#27222: [PATCH] emacs-build-system install phase doesn't honor directory hierarchy
Pushed! :-) Made a few minor modifications to the commit message...
bug#27007: [PATCH v2 2/2] doc: Adapt to multiple bootloader support.
> In the future, I think it’ll be preferable to commit code/tests/doc > together. That is, in the commit that changes the API from being > GRUB-specific to supporting multiple bootloaders, we include not only > the code but also the doc update. This simplifies review, makes sure > each commit is self-contained, and ensure that users get consistent > documentation. Yes I noticed this has confused some users, sorry for that :(. I pushed the two commits. Thanks, Mathieu
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Mark H Weaver 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 signature.asc Description: PGP signature
bug#27222: [PATCH] emacs-build-system install phase doesn't honor directory hierarchy
Arun Isaac writes: > Pushed! :-) > > Made a few minor modifications to the commit message... Thank you, Arun! Maxim
bug#27287: gnome-tweak-tool fails to start
Hi, I recently did a "guix pull" and upgraded the software installed in my profile. Since then, gnome-tweak-tool has failed to start. Before that, it started up successfully. Here's the error: --8<---cut here---start->8--- $ gnome-tweak-tool (..gnome-tweak-tool-real-real:2030): GLib-GIO-ERROR **: Settings schema 'org.gnome.shell' does not contain a key named 'disable-user-extensions' Trace/breakpoint trap --8<---cut here---end--->8--- Here's the bad version: /gnu/store/6zgb18rbi8r4lhvpa38jym6c36xxb2r2-gnome-tweak-tool-3.24.0/bin/gnome-tweak-tool Here's the last good version I had installed on my system: /gnu/store/9i80nasg0z8dn88qdskmhcvzs5vkkfd7-gnome-tweak-tool-3.22.0/bin/gnome-tweak-tool Any idea how to debug this or fix this? I wonder if it's related to the recent merge from staging into master (f484a50d5), which seems to have caused other bugs (e.g., bug 27264). -- Chris signature.asc Description: PGP signature
bug#27282: Perl 5.26.0 "dotless @INC" [was Re: bug#27227: [PATCH] gnu: perl: Update to 5.26.0.]
On Thu, Jun 08, 2017 at 02:28:54PM +0200, Ludovic Courtès wrote: > Leo Famulari skribis: > > We should set this PERL_USE_UNSAFE_INC variable in the SWIG package > > definition, right? Probably we will need to set it in several other > > packages as well. > > We can do that, but probably there will be (or there is already) a patch > for SWIG to not rely on having “.” in @INC, no? I hoped so, but I couldn't find any discussion on the SWIG bug tracker or mailing list, nor a commit in their source repo. I guess I should bring it up on their bug tracker :) signature.asc Description: PGP signature
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Mark H Weaver writes:
> Marius Bakke writes:
>
>> Mark H Weaver 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
From: Marius Bakke
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
Date: Thu, 8 Jun 2017 18:04:20 +0200
Subject: [PATCH 2/2] gnu: gnome-shell: Fix startup failure.
Fixes .
* 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:
+ ("librsvg" ,librsvg)
+ ("geoclue" ,geoclue)
;; XXX: required by libgjs.la.
("readline" ,readline)))
(synopsis "Desktop shell for GNOME")
--
2.13.1
signature.asc
Description: PGP signature
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Marius Bakke 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. signature.asc Description: PGP signature
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
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. signature.asc Description: PGP signature
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Leo Famulari 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. signature.asc Description: PGP signature
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
2017-06-08 19:08 GMT+02:00 Leo Famulari : > 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
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
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 :) signature.asc Description: PGP signature
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
>From 7b5c3ce6386acf1f7a965d19cd6dd51c662ba5bb Mon Sep 17 00:00:00 2001
From: Roel Janssen
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
Kei Kebreau writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Mark,
>>
>> Mark H Weaver skribis:
>>
>>> Roel Janssen writes:
>>>
Ludovic Courtès writes:
> Hi,
>
> Mark H Weaver 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
> 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 @@ propertie
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
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. signature.asc Description: PGP signature
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Roel Janssen writes:
> Kei Kebreau writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi Mark,
>>>
>>> Mark H Weaver skribis:
>>>
Roel Janssen writes:
> Ludovic Courtès writes:
>
>> Hi,
>>
>> Mark H Weaver 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
>> 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
signature.asc
Description: PGP signature
bug#26006: [Website] Integral update proposal
Hi, I have an incomplete implementation (https://bitbucket.org/sirgazil/guixsd-website) of a static website that includes the features illustrated in the mockups (the features that fit in a static website). Compared to the current website, this code has a different organization (see the "Framework" section below). I'm sending this message because I think this is as far as I can go with the implementation (found some problems I haven't figured out how to solve, and I'm not skilled enough to manipulate packages). This implementation is missing the following parts: 1. New screenshots 2. Packages pages 1. Package detail page 2. Packages issues page 3. Packages reproducibility page 4. Packages JSON file To complete part (1) someone could provide the screenshots (ideally 1920×1080 px) in JPG and add them to the "static/media/img" directory, and update the list of screenshots in "apps/base/data.scm". To complete (2), there are some package related procedures missing (https://bitbucket.org/sirgazil/guixsd-website/issues?status=new&status=open). I tried to use the code that is already in the current website, but couldn't figure things out. To complete part (2.1), there is an issue to solve: package pages go in paths like "/packages/blender-3.0/", but running "haunt build" with pages on paths that include "." will render the pages with all the HTML content inside a pre element. David, the maintainer of Haunt, does not know yet why this would happen. If this issue is solved, there are already helper builders in "apps/packages/builders.scm" to generate all the pages. So, for now, the packages pages are working as in the current website, but not using tables (to make it easier to adapt the page to several screen widths), and packages are distributed in numbered pages to avoid big HTML pages that take too long to load. Also, the JavaScript code that gets package build status is not integrated (couldn't figure this one out either). To complete (2.2), (2.3), and (2.4) someone could add helper builders to the packages app, and recycle the related SXML pages already used in the current website. Framework = The website is composed by apps; for example, a base app, a blog app, a packages app. An app is a directory with Scheme modules that *usually* look like this: apps/abc ├── builder.scm ├── types.scm ├── data.scm ├── utils.scm └── templates ├── components.scm ├── some-page.scm └── another-page.scm The builder file contains a Haunt builder procedure and helper builders that build the web resources of an app. In the types file there are data type definitions for the app (for example: screenshot, download, lint-issue, etc.). The data file contains instances of the defined data types. The utils file contains helper procedures for an application. The template directory contains SHTML, SXML, SATOM, SJSON templates to build the web resources provided by an application. The components module in the templates directory has template components that are used in several templates or even in other apps. All apps are "plugged" to the website by adding their builders to the site object in the "haunt.scm" file. Currently, there is also an aux app that contains procedures not particular to any app. If you have some time, take a look at it and let me know what you think. I can change *anything* that you think is inefficient, horrible or whatever. I hope it is not a mess :) Best, -- https://sirgazil.bitbucket.io/
bug#27264: gnome-shell-3.24.2 consistently dies during initialization
Hello Mark, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Hi Mark, >> >> Mark H Weaver 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
Marius Bakke 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 signature.asc Description: PGP signature
bug#27294: R importer fails to create a list for multiple licenses
For example, 'guix cran import RgoogleMaps' generates this line: (license (gpl2+ gpl3+)). Build fails unless changing the line to: (license (list gpl2+ gpl3+)). -- Joshua Sierles jos...@joshua.si
