bug#41034: guix info: display messed up in emacs info

[Michael Rohleder]

Hi Christopher,

Christopher Howard  writes:
> Hi, the guix info pages display fine when viewed with the normal info
> command, but when viewed with emacs (C-h i m Guix) there is strange
> issue where text between forward and backquote symbols shows up as hex
> numbers. See section 6.2 for a representative example. I get the same
> result if I run `emacs -q'. I've attached some screenshots which
> hopefully make it through the filters.

I can not reproduce this.
I think there might be something wrong with your theme or fonts or so.

Can you please try with `emacs -Q` ?
(-q still loads x-resources etc...)

-- 
I like work; it fascinates me; I can sit and look at it for hours.


signature.asc
Description: PGP signature

bug#41541: merge wip-hurd-vm

[Mathieu Othacehe]

Hello Jan,

> I have managed to completely boot-activation.  Still using the same
> patch for hurd-directives, but I've got a feeling we're getting real
> close now.

Just discovered your (gnu build hurd-boot), that's awesome! I wonder if
we could go one step further and move the "rc" script outside of the
"hurd" package (not sure where to put it though).

Thanks,

Mathieu

bug#41541: merge wip-hurd-vm

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

Hello Mathieu,

>> I have managed to completely boot-activation.  Still using the same
>> patch for hurd-directives, but I've got a feeling we're getting real
>> close now.
>
> Just discovered your (gnu build hurd-boot), that's awesome!

Thanks...yeah I was just attempting to write a mail about that,
asking/wondering if you think some commits should be collapsed
again...especially the introduction of using MAKEDEV

--8<---cut here---start->8---
Subject: [PATCH 1/9] gnu: hurd: Create minimal "runsystem" script to invoke 
"rc".
diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
@@ -329,10 +329,26 @@ boot, since this cannot be done from GNU/Linux."
[...]
+  ;; "@HURD@" and "@COREUTILS@" are a placeholders.
+  (setenv "PATH" "@HURD@/bin:@HURD@/sbin:@COREUTILS@/bin")
@@ -349,10 +374,43 @@ boot, since this cannot be done from GNU/Linux."
[...]
-  (invoke "console" "--daemonize" "-c" "/dev/vcs"
-  "-d" "vga" "-d" "pc_kbd" "-d" "generic_speaker"
+  (format #t "Creating essential device nodes...\n")
+  (with-directory-excursion "/dev"
+(invoke "MAKEDEV" "--devdir=/dev" "std")
+(invoke "MAKEDEV" "--devdir=/dev" "vcs")
+(invoke "MAKEDEV" "--devdir=/dev" "tty1""tty2" "tty3" "tty4" 
"tty5" "tty6")
+(invoke "MAKEDEV" "--devdir=/dev" "ptyp0" "ptyp1" "ptyp2")
+(invoke "MAKEDEV" "--devdir=/dev" "console"))
--8<---cut here---end--->8---

later moving it to hurd-boot, and its subsequent removal...

> I wonder if we could go one step further and move the "rc" script
> outside of the "hurd" package (not sure where to put it though).

Yes, I agree that would be great.  I briefly thought about it and gave
up, instead of asking this question...so

The "normal" (old, current master) bootstrap goes like this

/hurd/startup -> /libexec/runsystem -> /hurd/init ->
 /libexec/runsystem.hurd -> /libexec/rc

where RC is our initial Guile script.  I've managed to patch that into

/hurd/startup -> /libexec/runsystem* -> /libexec/rc

Where, /hurd is symlink to /gnu/store/*-hurd-0.9/hurd/ and runsystem*
now is a very minimal bash script, doing

exec /libexec/rc "$@"

and /libexecc is currently being substituted with the store file name,
which gives us a hurd package that does this

/hurd/startup
-> /gnu/store/xyz-hurd-0.9/libexec/runsystem
-> /gnu/store/xyz-hurd-0.9/libexec/rc

Now, how could we have runsystem run another RC?  Hmm, runsystem is
being called with --load and --system arguments too; we could even
give it an --rc=RC-FILE if that's more convenient.

Then, we would only need to add this RC-FILE to the system, maybe add a
%hurd-"something" service?

Hmm.  Please share your thoughts, I'm having a go at this.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#41541: merge wip-hurd-vm

[Mathieu Othacehe]

> Now, how could we have runsystem run another RC?  Hmm, runsystem is
> being called with --load and --system arguments too; we could even
> give it an --rc=RC-FILE if that's more convenient.
>
> Then, we would only need to add this RC-FILE to the system, maybe add a
> %hurd-"something" service?
>
> Hmm.  Please share your thoughts, I'm having a go at this.

Having an RC argument passed directly by the bootloader seems like a
good way to proceed for me. This is somehow remotely similar to what we
are doing with the "initrd" on Linux (pointing to some piece of code
that needs to be loaded before starting the init process).

You would also need to store this RC argument in the 
record, by adding a new field or stuffing it in the "initrd"
field. Then, we wouldn't need an extra service I guess.

If we are going that way, the procedures in (gnu build hurd-boot) could
be passed the "hurd" package to install, and we could maybe get rig of
the "/hurd" symlink?

Thanks,

Mathieu

bug#40806: xorg-configuration->file doesn't honor xorg-configuration-server

[Caleb Ristvedt]

If it helps, here's a patch that makes the trivial change.

- reepca

From e1071c830ce511eecd57617a3f188740fd49d703 Mon Sep 17 00:00:00 2001
From: Caleb Ristvedt 
Date: Tue, 2 Jun 2020 06:28:46 -0500
Subject: [PATCH] xorg: honor xorg-configuration-server in
 xorg-configuration->file

Previously the xorg-server package specified in the configuration was ignored
entirely in xorg-configuration->file.  This had the effect that while the X
program of the configured package would be executed, the modules of the
configured package would be ignored in favor of the default xorg-server
package's modules.  This fixes that.

* gnu/services/xorg.scm (xorg-configuration->file): honor
  xorg-configuration-server.
---
 gnu/services/xorg.scm | 161 +-
 1 file changed, 81 insertions(+), 80 deletions(-)

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 2505bde97b..ca39994516 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -180,31 +180,32 @@
 (define (xorg-configuration->file config)
   "Compute an Xorg configuration file corresponding to CONFIG, an
  record."
-  (define all-modules
-;; 'xorg-server' provides 'fbdevhw.so' etc.
-(append (xorg-configuration-modules config)
-(list xorg-server)))
-
-  (define build
-#~(begin
-(use-modules (ice-9 match)
- (srfi srfi-1)
- (srfi srfi-26))
-
-(call-with-output-file #$output
-  (lambda (port)
-(define drivers
-  '#$(xorg-configuration-drivers config))
+  (let ((xorg-server (xorg-configuration-server config)))
+(define all-modules
+  ;; 'xorg-server' provides 'fbdevhw.so' etc.
+  (append (xorg-configuration-modules config)
+  (list xorg-server)))
+
+(define build
+  #~(begin
+  (use-modules (ice-9 match)
+   (srfi srfi-1)
+   (srfi srfi-26))
+
+  (call-with-output-file #$output
+(lambda (port)
+  (define drivers
+'#$(xorg-configuration-drivers config))
 
-(define (device-section driver)
-  (string-append "
+  (define (device-section driver)
+(string-append "
 Section \"Device\"
   Identifier \"device-" driver "\"
   Driver \"" driver "\"
 EndSection"))
 
-(define (screen-section driver resolutions)
-  (string-append "
+  (define (screen-section driver resolutions)
+(string-append "
 Section \"Screen\"
   Identifier \"screen-" driver "\"
   Device \"device-" driver "\"
@@ -218,8 +219,8 @@ Section \"Screen\"
   EndSubSection
 EndSection"))
 
-(define (input-class-section layout variant model options)
-  (string-append "
+  (define (input-class-section layout variant model options)
+(string-append "
 Section \"InputClass\"
   Identifier \"evdev keyboard catchall\"
   MatchIsKeyboard \"on\"
@@ -243,69 +244,69 @@ Section \"InputClass\"
   Driver \"evdev\"
 EndSection\n"))
 
-(define (expand modules)
-  ;; Append to MODULES the relevant /lib/xorg/modules
-  ;; sub-directories.
-  (append-map (lambda (module)
-(filter-map (lambda (directory)
-  (let ((full (string-append module
- directory)))
-(and (file-exists? full)
- full)))
-'("/lib/xorg/modules/drivers"
-  "/lib/xorg/modules/input"
-  "/lib/xorg/modules/multimedia"
-  "/lib/xorg/modules/extensions")))
-  modules))
-
-(display "Section \"Files\"\n" port)
-(for-each (lambda (font)
-(format port "  FontPath \"~a\"~%" font))
-  '#$(xorg-configuration-fonts config))
-(for-each (lambda (module)
-(format port
-"  ModulePath \"~a\"~%"
-module))
-  (append (expand '#$all-modules)
-
-  ;; For fbdevhw.so and so on.
-  (list #$(file-append xorg-server
-   "/lib/xorg/modules"
-(display "EndSection\n" port)
-(display "
+  (define (expand modules)
+;; Append to MODULES the relevant /lib/xorg/modules
+;; sub-directories.
+(append-map (lambda (module)
+  (filter-map (lambda (directory)
+(let ((full (

bug#38432: dockerd is not started automatically

[Maxim Cournoyer]

Hello Danny!

The service definition here:
https://github.com/containerd/containerd/blob/master/containerd.service
uses the systemd notify mechanism to allow the application (containerd)
to message the init (systemd) that it is ready.

leoprikler on #guix had the idea to patch this away and replace it by
some code that'd write a PID file.  That's an interesting idea!  Even
nicer would be to have Shepherd listen on the socket that the sd_notify
mechanism relies on and natively support the systemd notify thing :-).

Food for thoughts...

Maxim

bug#41660: texlive-csquotes source hash mismatch

[Ludovic Courtès]

I’m observing a hash mismatch there:

--8<---cut here---start->8---
$ guix build texlive-csquotes
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
La jenaj derivoj estos konstruataj:
   /gnu/store/qr283hriqpv4w0nw5l5khf5xpsg00858-texlive-csquotes-51265.drv
   
/gnu/store/cpiwf24vyk0691wk6k0dlkq6jz61h89v-texlive-csquotes-51265-checkout.drv
building 
/gnu/store/cpiwf24vyk0691wk6k0dlkq6jz61h89v-texlive-csquotes-51265-checkout.drv...
guile: warning: failed to install locale
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LC_ALL is en_US.utf8
svn: warning: please check that your locale name is correct
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/doc/latex/csquotes
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/doc/latex/csquotes/README.md
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/doc/latex/csquotes/csquotes.pdf
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/doc/latex/csquotes/csquotes.tex
Exported revision 51265.
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LC_ALL is en_US.utf8
svn: warning: please check that your locale name is correct
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes/csq-compat.def
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes/csquotes.cfg
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes/csquotes.def
A
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes/csquotes.sty
Exported revision 51265.
r:sha256 hash mismatch for 
/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout:
  expected hash: 15hgn37zg433skn7ijqs1kl2z56fhy29cjxn01b5pjrnrkdar4i4
  actual hash:   088gvi60d7sdl6fgg68fbz30fnpqc3yrpkx80sfw7vwgar3wm3av
hash mismatch for store item 
'/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout'
build of 
/gnu/store/cpiwf24vyk0691wk6k0dlkq6jz61h89v-texlive-csquotes-51265-checkout.drv 
failed
View build log at 
'/var/log/guix/drvs/cp/iwf24vyk0691wk6k0dlkq6jz61h89v-texlive-csquotes-51265-checkout.drv.bz2'.
cannot build derivation 
`/gnu/store/qr283hriqpv4w0nw5l5khf5xpsg00858-texlive-csquotes-51265.drv': 1 
dependencies couldn't be built
guix build: error: build of 
`/gnu/store/qr283hriqpv4w0nw5l5khf5xpsg00858-texlive-csquotes-51265.drv' failed
$ guix describe
Generacio 146   Jun 02 2020 00:38:54(nuna)
  guix e7da805
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: e7da8055892510fcb5cf4b51479a0897e18a205e
--8<---cut here---end--->8---

There’s no substitute on berlin, so perhaps the hash has always been
“wrong”.

Does anyone have the expected checkout?

Ludo’.

bug#41541: merge wip-hurd-vm

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

Hi Mathieu,

> Having an RC argument passed directly by the bootloader seems like a
> good way to proceed for me. This is somehow remotely similar to what we
> are doing with the "initrd" on Linux (pointing to some piece of code
> that needs to be loaded before starting the init process).
>
> You would also need to store this RC argument in the 
> record, by adding a new field or stuffing it in the "initrd"
> field. Then, we wouldn't need an extra service I guess.

Hmm...I don't understand...probably I'm missing something.

I was thinking to just extend boot-parameters with
--rc-file=%hurd-rc-script, and then add %hurd-rc-script to the SYSTEM
service...How would I get the RC script into SYSTEM without a service?

Anyway...see working prototype attached!  To get rid of the extra sevice
that I added I'd need some help.  Please feel free to just rework it if
you like!

> If we are going that way, the procedures in (gnu build hurd-boot) could
> be passed the "hurd" package to install, and we could maybe get rig of
> the "/hurd" symlink?

Hehe, that would be nice...but IME /hurd isn't easy to get rid of.  The
Hurd code uses it "everywhere" and I seem to remember that a simple
substitute* on the Hurd archive was not enough...sadly I do not remember
the details, so maybe...

Greetings,
Janneke

>From e11e59cbcd9165e3b885c1019e19aaab471f5498 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" 
Date: Thu, 30 Apr 2020 15:40:07 +0200
Subject: [PATCH] gnu: services: Add %hurd-startup-service.

This decouples startup of the Hurd from the "hurd" package, moving the RC
script into SYSTEM.

* gnu/packages/hurd.scm (hurd)[inputs]: Remove hurd-rc-script.
[arguments]: Do not substitute it.  Update "runsystem.sh" to parse
kernel arguments and exec into --rc-file=RC-FILE.
(hurd-rc-script): Move to...
* gnu/services.scm (%hurd-rc-file): ...this new variable.
(bootable-kernel-arguments): Use it.
(%hurd-bare-metal-service): New variable.
* gnu/system.scm (hurd-default-essential-services): Use it.
---
 gnu/packages/hurd.scm | 52 ++-
 gnu/services.scm  | 40 +
 gnu/system.scm| 21 ++---
 3 files changed, 65 insertions(+), 48 deletions(-)

diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
index 5de4acb1c5..542ca1e229 100644
--- a/gnu/packages/hurd.scm
+++ b/gnu/packages/hurd.scm
@@ -310,32 +310,6 @@ Hurd-minimal package which are needed for both glibc and GCC.")
  (base32
   "0p2vhnc18cnbmb39vq4m7hzv4mhnm2l0a2s7gx3ar277fwng3hys"
 
-(define (hurd-rc-script)
-  "Return a script to be installed as /libexec/rc in the 'hurd' package.  The
-script takes care of installing the relevant passive translators on the first
-boot, since this cannot be done from GNU/Linux.  Then, it runs system
-activation; starting the Shepherd."
-
-  (define rc
-(with-imported-modules '((guix build utils)
- (gnu build hurd-boot)
- (guix build syscalls))
-  #~(begin
-  (use-modules (guix build utils)
-   (gnu build hurd-boot)
-   (guix build syscalls)
-   (ice-9 match)
-   (system repl repl)
-   (srfi srfi-1)
-   (srfi srfi-26))
-
-  (boot-hurd-system
-
-  ;; FIXME: We want the program to use the cross-compiled Guile when
-  ;; cross-compiling.  But why do we need to be explicit here?
-  (with-parameters ((%current-target-system "i586-pc-gnu"))
-(program-file "rc" rc)))
-
 (define dde-sources
   ;; This is the current tip of the dde branch
   (let ((commit "ac1c7eb7a8b24b7469bed5365be38a968d59a136"))
@@ -417,11 +391,19 @@ PATH=@PATH@
 fsck --yes --force /
 fsysopts / --writable
 settrans -c /servers/socket/1 /hurd/pflocal
-echo Starting /libexec/rc ...
-exec /libexec/rc \"$@\"
-")))
- ))
 
+# parse multiboot arguments
+for i in \"$@\"; do
+case $i in
+(--rc-file=*)
+rc=${i#--rc-file=}
+;;
+esac
+done
+
+echo Starting ${rc}...
+exec ${rc} \"$@\"
+")
  (add-before 'build 'set-file-names
(lambda* (#:key inputs outputs #:allow-other-keys)
  (let* ((out  (assoc-ref outputs "out"))
@@ -483,15 +465,6 @@ exec /libexec/rc \"$@\"
(mkdir-p datadir)
(copy-file "unifont"
   (string-append datadir "/vga-system.bdf"))
-   #t)))
- (add-after 'install 'install-rc-file
-   (lambda* (#:key inputs outputs #:allow-other-keys)
- (let* ((out  (assoc-ref outputs "out"))
-(file (string-append out "/libexec/rc"))
-(rc   (assoc-ref inputs "hurd-rc"))
-(coreutils (assoc-ref inputs "coreutils")))
-   (delete-file file)
-   (copy-file rc file)
#t
#:c

bug#41541: merge wip-hurd-vm

[Ludovic Courtès]

Hi,

Jan Nieuwenhuizen  skribis:

>> Having an RC argument passed directly by the bootloader seems like a
>> good way to proceed for me. This is somehow remotely similar to what we
>> are doing with the "initrd" on Linux (pointing to some piece of code
>> that needs to be loaded before starting the init process).
>>
>> You would also need to store this RC argument in the 
>> record, by adding a new field or stuffing it in the "initrd"
>> field. Then, we wouldn't need an extra service I guess.
>
> Hmm...I don't understand...probably I'm missing something.
>
> I was thinking to just extend boot-parameters with
> --rc-file=%hurd-rc-script, and then add %hurd-rc-script to the SYSTEM
> service...How would I get the RC script into SYSTEM without a service?

Normally, if you have the system (as returned by ‘guix system build’),
that’s enough to derive any other kind of thing you might want.

So for example, you could have a “startup” (or “rc”) entry in the
‘system’ directory by extending ‘system-service-type’.  And since the
system is known from the boot command line, bingo.

The guideline IMO should be to remain as close as possible to Guix
System on GNU/Linux.  It’s OK to depart a bit from upstream Hurd though
because those bits are not actually used (Debian does its own thing).

>> If we are going that way, the procedures in (gnu build hurd-boot) could
>> be passed the "hurd" package to install, and we could maybe get rig of
>> the "/hurd" symlink?
>
> Hehe, that would be nice...but IME /hurd isn't easy to get rid of.

Some of the /hurd names are embedded in libc, via the Hurd’s paths.h.
Some names are compared by string (!); for instance, symlink.c in libc
has:

  /* A symlink is a file whose translator is "/hurd/symlink\0target\0".  */

  memcpy (buf, _HURD_SYMLINK, sizeof (_HURD_SYMLINK));
  memcpy (&buf[sizeof (_HURD_SYMLINK)], from, len);

That makes it next to impossible to remove /hurd.

I think it should be treated like /bin/sh and /run/current-system: set
up at activation time.

>>From e11e59cbcd9165e3b885c1019e19aaab471f5498 Mon Sep 17 00:00:00 2001
> From: "Jan (janneke) Nieuwenhuizen" 
> Date: Thu, 30 Apr 2020 15:40:07 +0200
> Subject: [PATCH] gnu: services: Add %hurd-startup-service.
>
> This decouples startup of the Hurd from the "hurd" package, moving the RC
> script into SYSTEM.
>
> * gnu/packages/hurd.scm (hurd)[inputs]: Remove hurd-rc-script.
> [arguments]: Do not substitute it.  Update "runsystem.sh" to parse
> kernel arguments and exec into --rc-file=RC-FILE.
> (hurd-rc-script): Move to...
> * gnu/services.scm (%hurd-rc-file): ...this new variable.
> (bootable-kernel-arguments): Use it.
> (%hurd-bare-metal-service): New variable.
> * gnu/system.scm (hurd-default-essential-services): Use it.

[…]

> +;; XXX this won't go into SYSTEM (as system-service); the result is fine
> +;; though and it gets picked-up well by --rc-file=%hurd-rc-script
> +(define %hurd-rc-script
> +  ;; The RC script to be started upon boot.
> +  (program-file "rc"
> +(with-imported-modules '((guix build utils)
> + (gnu build hurd-boot)
> + (guix build syscalls))

Probably use ‘source-module-closure’ to be on the safe side.

> +(define (hurd-rc-entry mrc)
> +  "Return, as a monadic value, an entry for the RC script in the system
> +directory."
> +  (mlet %store-monad ((rc mrc))
> +(return `(("rc" ,rc)
> +
> +(define hurd-startup-service-type
> +  ;; The service that creates the initial RC startup file.
> +  (service-type (name 'startup)
> +(extensions
> + (list (service-extension system-service-type 
> hurd-rc-entry)))
> +(compose identity)
> +(extend (const (lower-object %hurd-rc-script)))
> +(description
> + "Produce the operating system's RC script, which is executed
> +by RUNSYSTEM.")))

Is this service really meant to be extensible?  If not, we could just do:

  (service-type (name 'startup)
(extensions
 (list (service-extension system-service-type hurd-rc-entry)))
(default-value %hurd-rc-script))

where:

  (define (hurd-rc-entry rc)
(mlet %store-monad ((rc (lower-object rc)))
  (return `(("rc" ,rc)

> +  (append
> +   (if (hurd-target?)
> +   (list #~(string-append "--rc-file=" #$%hurd-rc-script))
> +   '())
> +   (list (string-append "--root="
> +;; Note: Always use the DCE format because that's 
> what
> +;; (gnu build linux-boot) expects for the '--root'
> +;; kernel command-line option.
> +(file-system-device->string root-device
> +#:uuid-type 'dce))
> + #~(string-append "--system=" #$system)
> + #~(string-append "--load=" #$system "/boot"

So my suggestion is to avoid --rc-file sin

bug#41661: [Cuirass] Doesn't honor 'timeout' nor 'max-silent-time' leading to mising substitutes

[Brice Waegeneire]

Hello Guix,

Unlike Hydra, Curiass don't honor 'timeout' and 'max-silent-time'
properties[0]. This lead to some packages never having substitutes, in
particular for the 'armhf-linux' system for example 'linux-libre' or
'guile-static-stripped'[1]. Which mean it's really difficult to use such
systems since each users need to build thoses really long running[2]
packages. We also don't know if thoses package may fail for a reason 
other

than timing out.

[0]: https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00209.html
[1]: 
http://ci.guix.gnu.org/search?query=guile-static-stripped%20system:armhf-linux
[2]: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm?id=f51fd97ec54a98668d63c52d8a6bd75d8dc3292e#n257


- Brice

bug#41034: guix info: display messed up in emacs info

[Christopher Howard]

Hi, thank you, but problem is gone now. I can't quite recall, but I
think it went away after I ran fc-cache -f -v.

-- 
Christopher Howard
p: +1 (907) 374-0257
w: https://librehacker.com
social: https://gnusocial.club/librehacker
gpg: ADDEAADE5D607C8D (keys.gnupg.net)

On Tue, 2020-06-02 at 09:29 +0200, Michael Rohleder wrote:
> Hi Christopher,
> 
> Christopher Howard  writes:
> > Hi, the guix info pages display fine when viewed with the normal
> > info
> > command, but when viewed with emacs (C-h i m Guix) there is strange
> > issue where text between forward and backquote symbols shows up as
> > hex
> > numbers. See section 6.2 for a representative example. I get the
> > same
> > result if I run `emacs -q'. I've attached some screenshots which
> > hopefully make it through the filters.
> 
> I can not reproduce this.
> I think there might be something wrong with your theme or fonts or
> so.
> 
> Can you please try with `emacs -Q` ?
> (-q still loads x-resources etc...)
> 

bug#41541: merge wip-hurd-vm

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> Jan Nieuwenhuizen  skribis:
>
>>> Having an RC argument passed directly by the bootloader seems like a
>>> good way to proceed for me. This is somehow remotely similar to what we
>>> are doing with the "initrd" on Linux (pointing to some piece of code
>>> that needs to be loaded before starting the init process).
>>>
>>> You would also need to store this RC argument in the 
>>> record, by adding a new field or stuffing it in the "initrd"
>>> field. Then, we wouldn't need an extra service I guess.
>>
>> Hmm...I don't understand...probably I'm missing something.
>>
>> I was thinking to just extend boot-parameters with
>> --rc-file=%hurd-rc-script, and then add %hurd-rc-script to the SYSTEM
>> service...How would I get the RC script into SYSTEM without a service?
>
> Normally, if you have the system (as returned by ‘guix system build’),
> that’s enough to derive any other kind of thing you might want.
>
> So for example, you could have a “startup” (or “rc”) entry in the
> ‘system’ directory by extending ‘system-service-type’.  And since the
> system is known from the boot command line, bingo.
>
> The guideline IMO should be to remain as close as possible to Guix
> System on GNU/Linux.  It’s OK to depart a bit from upstream Hurd though
> because those bits are not actually used (Debian does its own thing).

Okay, that makes sense. Using --system=SYSTEM => SYSTEM/rc now.

>>> If we are going that way, the procedures in (gnu build hurd-boot) could
>>> be passed the "hurd" package to install, and we could maybe get rig of
>>> the "/hurd" symlink?
>>
>> Hehe, that would be nice...but IME /hurd isn't easy to get rid of.
>
> Some of the /hurd names are embedded in libc, via the Hurd’s paths.h.
> Some names are compared by string (!); for instance, symlink.c in libc
> has:
>
>   /* A symlink is a file whose translator is "/hurd/symlink\0target\0".  */
>
>   memcpy (buf, _HURD_SYMLINK, sizeof (_HURD_SYMLINK));
>   memcpy (&buf[sizeof (_HURD_SYMLINK)], from, len);
>
> That makes it next to impossible to remove /hurd.
>
> I think it should be treated like /bin/sh and /run/current-system: set
> up at activation time.

Ah right...I think this is exactly what I found (and forgot).  The file
system embeds the full file-name...that's unfortunate.

>> +(define %hurd-rc-script
>> +  ;; The RC script to be started upon boot.
>> +  (program-file "rc"
>> +(with-imported-modules '((guix build utils)
>> + (gnu build hurd-boot)
>> + (guix build syscalls))
>
> Probably use ‘source-module-closure’ to be on the safe side.

Nice!

>> +(define (hurd-rc-entry mrc)
>> +  "Return, as a monadic value, an entry for the RC script in the system
>> +directory."
>> +  (mlet %store-monad ((rc mrc))
>> +(return `(("rc" ,rc)
>> +
>> +(define hurd-startup-service-type
>> +  ;; The service that creates the initial RC startup file.
>> +  (service-type (name 'startup)
>> +(extensions
>> + (list (service-extension system-service-type 
>> hurd-rc-entry)))
>> +(compose identity)
>> +(extend (const (lower-object %hurd-rc-script)))
>> +(description
>> + "Produce the operating system's RC script, which is 
>> executed
>> +by RUNSYSTEM.")))
>
> Is this service really meant to be extensible?  If not, we could just do:

(no)

>   (service-type (name 'startup)
> (extensions
>  (list (service-extension system-service-type hurd-rc-entry)))
> (default-value %hurd-rc-script))
>
> where:
>
>   (define (hurd-rc-entry rc)
> (mlet %store-monad ((rc (lower-object rc)))
>   (return `(("rc" ,rc)

Thanks, done!

>> +  (append
>> +   (if (hurd-target?)
>> +   (list #~(string-append "--rc-file=" #$%hurd-rc-script))
>> +   '())
>> +   (list (string-append "--root="
>> +;; Note: Always use the DCE format because that's 
>> what
>> +;; (gnu build linux-boot) expects for the '--root'
>> +;; kernel command-line option.
>> +(file-system-device->string root-device
>> +#:uuid-type 'dce))
>> + #~(string-append "--system=" #$system)
>> + #~(string-append "--load=" #$system "/boot"
>
> So my suggestion is to avoid --rc-file since you know that SYSTEM/rc
> exists.

Done!

> Ludo’, who jumps in the middle of the discussion.  :-)

Very helpful indeed :-) -- attaching new version (and much tempted to
push to wip-hurd-vm now).

Any more wishes or ideas, things to be done before merging?  Not all
patches were reviewed in their current form, I think.

Janneke

>From 37c2a57d72f5678ec21a48ed4a3b733a20b71ab1 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" 
Date: Thu, 30 Apr 2020 15:40:07 +0200
Subject: [PATCH v2] gnu: ser

bug#22883: Authenticating a Git checkout

[John Soo]

Hi Ludo,

I like this idea a lot since I use a checkout which I guess constitutes
a "fork" in this scenario.  I opened bug#41604
(http://issues.guix.gnu.org/issue/41604) after having trouble with a
rebase based workflow.  Some of my problems certainly come from my lack
of understanding of the authentication process and machinery.  Would the
channel introduction allow me to use the rebase workflow in my checkout?

I am not sure I am clear on how I would setup an introduction for my
local checkout.  Heck, I am still trying to figure out how to add myself
as a signer to my patches on top of master.

Thanks as always,

John

bug#41207: accountsservice daemon lacks dbus interfaces

[L p R n d n]

Hello,

Ludovic Courtès  writes:

> Hello,
>
> L  p R n  d n skribis:
>
>> The accountsservice service hasn't access to dbus' interfaces throwing
>> an error when they're needed.The problem, at least, appears with LightDM.
>> The error looks like:
>>
>> WARNING: Error updating user /org/freedesktop/Accounts/User1000:
>> GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No such interface
>> "org.freedesktop.DisplayManager.AccountsService"
>
> Apparently this error message comes from lightdm, so the issue is that
> lightdm doesn’t find the ‘org.freedesktop.Accounts.service’, right?

Not exactly, my understanding is that *accountsservice* doesn't find
'org.freedesktop.Accounts.service' which is provided (and asked) by
lightdm. (I think the error comes from accountsservice)

> How is lightdm started?  I wonder if there’s something to be done in the
> service definition instead.
>
> Thanks,
> Ludo’.

Have a nice day,

L  p R n  d n

bug#41651: nm-applet fails: Settings schema 'org.gnome.nm-applet' is not installed

[Diego Nicola Barbato]

Hi,

Pierre Neidhardt  writes:

> Guix commit e7b86a0d88760275afefa0c44a3c30602f80aac0
>
> $ nm-applet
>
> (nm-applet:28022): GLib-GIO-ERROR **: 20:18:12.633: Settings schema 
> 'org.gnome.nm-applet' is not installed
> trace/breakpoint trap
>
> It used to work on commit afc46f22672eb3218fbd1e567f85fc6367286461.

I have the same problem (on EXWM as well).  It looks like this was
introduced by commit 4c29111232c44c84908922442abd1cd83ddc7686
(gnu: network-manager-applet: Update to 1.16.0.).  The last known good
commit is 9af90aafdfd8afd5fb7b5377ca5daf2215d38d7a (nm-applet doesn't
build between those two commits).

I was able to work around this by installing libnma in my user profile.

Regards,

Diego

bug#41034: guix info: display messed up in emacs info

[Michael Rohleder]

Christopher Howard  writes:
> Hi, thank you, but problem is gone now. I can't quite recall, but I
> think it went away after I ran fc-cache -f -v.

Ok, let's close this ;)

-- 
Programmierer sind Maschinen die Nikotin und Koffein in Programmcode umsetzen.


signature.asc
Description: PGP signature

bug#41651: nm-applet fails: Settings schema 'org.gnome.nm-applet' is not installed

[Pierre Neidhardt]

It works indeed, thanks.

We need to fix nm-applet.


signature.asc
Description: PGP signature

bug#40406: python-matplotlib fails to build on i686-linux

[Diego Nicola Barbato]

Hi,

Leo Famulari  writes:

> On Fri, Apr 03, 2020 at 05:20:08PM +0200, Diego Nicola Barbato wrote:
>> The package python-matplotlib fails to build during the check phase on
>> i686-linux.  The test failure appears to be deterministic:

I've taken a closer look at the failing test (on x86_64-linux, commit:
ebbf915) by keeping the build tree ...

--8<---cut here---start->8---
guix build --no-grafts -s i686-linux --keep-failed python-matplotlib
--8<---cut here---end--->8---

... and running python inside of it.

--8<---cut here---start->8---
cd /tmp/guix-build-python-matplotlib-3.1.2.drv-0/matplotlib-3.1.2/
. ../environment-variables
export PYTHONPATH="${PYTHONPATH}:build/lib.linux-i686-3.8"
python3
--8<---cut here---end--->8---

I retraced the steps of the failing test ...

--8<---cut here---start->8---
import matplotlib.pyplot as plt
import matplotlib.widgets as widgets
from numpy.testing import assert_allclose
fig, ax = plt.subplots()
slider = widgets.Slider(ax=ax, label='', valmin=0, valmax=24, valinit=12, 
orientation='horizontal')
slider.set_val(10)
box = slider.poly.get_extents().transformed(ax.transAxes.inverted())
assert_allclose(box.bounds, [0, 0, 10/24, 1])
--8<---cut here---end--->8---

... and was able to reproduce the failing assertion ...

--8<---cut here---start->8---
AssertionError:
Not equal to tolerance rtol=1e-07, atol=0

Mismatch: 25%
Max absolute difference: 1.11022302e-16
Max relative difference: 2.66453526e-16
 x: array([ 0.00e+00, -1.046255e-17,  4.17e-01,  1.00e+00])
 y: array([0.  , 0.  , 0.416667, 1.  ])
--8<---cut here---end--->8---

... , although the differing value wasn't exactly the same as the one
reported by the test.  As expected, the assertion did not fail when I
followed the same steps on x86_64.

--8<---cut here---start->8---
guix environment --ad-hoc python python-matplotlib -- python3
--8<---cut here---end--->8---

A closer look at the intermediate results ...

--8<---cut here---start->8---
print(slider.poly.get_extents().bounds,
  ax.transAxes.get_matrix(),
  ax.transAxes.inverted().get_matrix(),
  box.bounds,
  sep='\n')
--8<---cut here---end--->8---

... revealed that only the values of box.bounds differ.  The dimensions
of the slider are the same (as are the values of the transformation
matrices) on i686-linux ...

--8<---cut here---start->8---
(80.0, 52.8, 206.63, 369.57)
[[496.0.   80. ]
 [  0.  369.6  52.8]
 [  0.0.1. ]]
[[ 0.00201613  0. -0.16129032]
 [ 0.  0.00270563 -0.14285714]
 [ 0.  0.  1.]]
(0.0, -1.0462550964485118e-17, 0.4166, 1.0)
--8<---cut here---end--->8---

... and on x86_64-linux.

--8<---cut here---start->8---
(80.0, 52.8, 206.63, 369.57)
[[496.0.   80. ]
 [  0.  369.6  52.8]
 [  0.0.1. ]]
[[ 0.00201613  0. -0.16129032]
 [ 0.  0.00270563 -0.14285714]
 [ 0.  0.  1.]]
(0.0, 0.0, 0.41663, 1.0002)
--8<---cut here---end--->8---

Apparently there is nothing wrong with the slider.  Instead matrix
multiplication, which is used under the hood for transformations, seems
to sometimes produce incorrect results on i686-linux.  I have reported
this as a separate bug (https://debbugs.gnu.org/41665).

> I wonder if this scientific computing stuff should be tried on i686 at
> all. Should we limit it to contemporary architectures?

I was opposed to this at first (after all, if upstream supports Numpy on
i686, why shouldn't we?), but after seeing that even simple things like
matrix multiplication can produce incorrect results I'm in favour of
limiting it to contemporary architectures.  What do others think?

Regards,

Diego

bug#41665: python-numpy: incorrect results on i686-linux

[Diego Nicola Barbato]

Hi Guix,

On i686-linux Numpy produces incorrect results for some matrix
products.

This minimal reproducer ...

--8<---cut here---start->8---
python3 <8---

... should return:

--8<---cut here---start->8---
[0. 0. 1.]
[0. 0. 1.]
--8<---cut here---end--->8---

On x86_64-linux, armhf-linux, and aarch64-linux I get the correct
result.  On i686-linux I get this instead:

--8<---cut here---start->8---
[ 0.e+00 -5.55111512e-17  1.e+00]
[0. 0. 1.]
--8<---cut here---end--->8---

I came across this bug while looking into https://debbugs.gnu.org/40406,
for which it seems to be the underlying cause.

I'm surprised this wasn't caught by Numpy's test suite.

Regards,

Diego

bug#40406: python-matplotlib fails to build on i686-linux

[Leo Famulari]

On Tue, Jun 02, 2020 at 06:18:28PM +0200, Diego Nicola Barbato wrote:
> I was opposed to this at first (after all, if upstream supports Numpy on
> i686, why shouldn't we?), but after seeing that even simple things like
> matrix multiplication can produce incorrect results I'm in favour of
> limiting it to contemporary architectures.  What do others think?

I'll leave it up to you and others who are actually using these
programs. I do think it's unlikely the upstream developers use or test
the software on i686, or on anything besides x86_64.

bug#41661: [Cuirass] Doesn't honor 'timeout' nor 'max-silent-time' leading to mising substitutes

[Leo Famulari]

On Tue, Jun 02, 2020 at 01:15:19PM +, Brice Waegeneire wrote:
> Hello Guix,
> 
> Unlike Hydra, Curiass don't honor 'timeout' and 'max-silent-time'
> properties[0]. This lead to some packages never having substitutes, in
> particular for the 'armhf-linux' system for example 'linux-libre' or
> 'guile-static-stripped'[1]. Which mean it's really difficult to use such
> systems since each users need to build thoses really long running[2]
> packages. We also don't know if thoses package may fail for a reason other
> than timing out.
> 
> [0]: https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00209.html
> [1]: 
> http://ci.guix.gnu.org/search?query=guile-static-stripped%20system:armhf-linux
> [2]: 
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm?id=f51fd97ec54a98668d63c52d8a6bd75d8dc3292e#n257
> 
> - Brice

We really need to improve our CI so that it's possible to discover these
build failures. Currently it's quite hard to monitor if they get built
unless you just do `guix build foo`.

The last time this came up [0] it was said that maybe it's not really
correct to make these properties of the package, but rather of the CI
jobs. It makes sense but we need a solution, or stop supporting
underpowered architectures like armhf, because most of those machines
can't build this stuff themselves, and it's not good to advertise
support to people who will just be disappointed later.


signature.asc
Description: PGP signature

bug#41666: $INFOPATH should end with a colon

[Jonas Bernoulli]

On a foreign distro Guix installs /etc/profile.d/guix.sh, which among
other things adds the directory where it installs info pages to the
INFOPATH variable.

It takes care to not accidentally cause the value to end with a colon.
Unfortunately it should do the opposite because a trailing colon means
"... and also the default locations", which is highly desirable.

This is documented in (info "(texinfo)Other Info Directories"):

>However you set 'INFOPATH', if its last character is a colon (on
> MS-DOS/MS-Windows systems, use a semicolon instead), this is replaced by
> the default (compiled-in) path.  This gives you a way to augment the
> default path with new directories without having to list all the
> standard places.  For example (using 'sh' syntax):
>
>  INFOPATH=/home/bob/info:
>  export INFOPATH
>
> will search '/home/bob/info' first, then the standard directories.
> Leading or doubled colons are not treated specially.

I recommend you just make this simple change:

-  export INFOPATH="$_GUIX_PROFILE/share/info${INFOPATH:+:}$INFOPATH"
+  export INFOPATH="$_GUIX_PROFILE/share/info$:$INFOPATH"

If INFOPATH is already set and does not end with a colon, then that
should be left as-is; it might be intentional.

bug#41666: $INFOPATH should end with a colon

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Jonas,

Jonas Bernoulli 写道：
On a foreign distro Guix installs /etc/profile.d/guix.sh, which 
among
other things adds the directory where it installs info pages to 
the

INFOPATH variable.


Thanks for the report!

New installations (after 21 March) should not have this problem[0] 
so I've closed & merged your bug with that one.


It's safe to manually fix your local copy of ‘guix.sh’.  It was 
created by guix-install.sh, but Guix doesn't know about or touch 
it.


Kind regards,

T G-R

[0]: https://issues.guix.gnu.org/39984


signature.asc
Description: PGP signature

bug#41651: [PATCH] gnu: network-manager-applet: Propagate 'libnma'.

[Brice Waegeneire]

Fixes .

* gnu/packages/gnome.scm (network-manager-applet)[inputs]: Move 'libnma'
to …
[native-inputs]: … here.
---

Sorry for the crappy patchset.  This patch should solve that issue.


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

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 0d63579d4a..860b5223b8 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -6730,13 +6730,14 @@ Cisco's AnyConnect SSL VPN.")
("gtk-doc" ,gtk-doc)
("pkg-config" ,pkg-config)))
 (propagated-inputs
- ;; libnm-gtk.pc refers to all these.
- `(("dbus-glib" ,dbus-glib)
+ `(;; libnm-gtk.pc refers to all these.
+   ("dbus-glib" ,dbus-glib)
("gtk+" ,gtk+)
-   ("network-manager" ,network-manager)))
+   ("network-manager" ,network-manager)
+   ;; nm-applet need org.gnome.nm-applet.gschema.xml
+   ("libnma" ,libnma)))
 (inputs
  `(("gcr" ,gcr)
-   ("libnma" ,libnma)
("libgudev" ,libgudev)
("libnotify" ,libnotify)
("libsecret" ,libsecret)
-- 
2.26.2

bug#41660: texlive-csquotes source hash mismatch

[Marius Bakke]

Ludovic Courtès  writes:

> I’m observing a hash mismatch there:
>
> --8<---cut here---start->8---
> $ guix build texlive-csquotes
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> La jenaj derivoj estos konstruataj:
>/gnu/store/qr283hriqpv4w0nw5l5khf5xpsg00858-texlive-csquotes-51265.drv
>
> /gnu/store/cpiwf24vyk0691wk6k0dlkq6jz61h89v-texlive-csquotes-51265-checkout.drv
> building 
> /gnu/store/cpiwf24vyk0691wk6k0dlkq6jz61h89v-texlive-csquotes-51265-checkout.drv...
> guile: warning: failed to install locale
> svn: warning: cannot set LC_CTYPE locale
> svn: warning: environment variable LC_ALL is en_US.utf8
> svn: warning: please check that your locale name is correct
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/doc/latex/csquotes
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/doc/latex/csquotes/README.md
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/doc/latex/csquotes/csquotes.pdf
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/doc/latex/csquotes/csquotes.tex
> Exported revision 51265.
> svn: warning: cannot set LC_CTYPE locale
> svn: warning: environment variable LC_ALL is en_US.utf8
> svn: warning: please check that your locale name is correct
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes/csq-compat.def
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes/csquotes.cfg
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes/csquotes.def
> A
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout/tex/latex/csquotes/csquotes.sty
> Exported revision 51265.
> r:sha256 hash mismatch for 
> /gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout:
>   expected hash: 15hgn37zg433skn7ijqs1kl2z56fhy29cjxn01b5pjrnrkdar4i4
>   actual hash:   088gvi60d7sdl6fgg68fbz30fnpqc3yrpkx80sfw7vwgar3wm3av
> hash mismatch for store item 
> '/gnu/store/fkxwlwrydq2hzrp37qh42ash4zi6pbq6-texlive-csquotes-51265-checkout'
> build of 
> /gnu/store/cpiwf24vyk0691wk6k0dlkq6jz61h89v-texlive-csquotes-51265-checkout.drv
>  failed
> View build log at 
> '/var/log/guix/drvs/cp/iwf24vyk0691wk6k0dlkq6jz61h89v-texlive-csquotes-51265-checkout.drv.bz2'.
> cannot build derivation 
> `/gnu/store/qr283hriqpv4w0nw5l5khf5xpsg00858-texlive-csquotes-51265.drv': 1 
> dependencies couldn't be built
> guix build: error: build of 
> `/gnu/store/qr283hriqpv4w0nw5l5khf5xpsg00858-texlive-csquotes-51265.drv' 
> failed
> $ guix describe
> Generacio 146 Jun 02 2020 00:38:54(nuna)
>   guix e7da805
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: e7da8055892510fcb5cf4b51479a0897e18a205e
> --8<---cut here---end--->8---
>
> There’s no substitute on berlin, so perhaps the hash has always been
> “wrong”.

This is because it was added (on 'master') after the big TeX Live update
in 85892948bd9fb5fcc3409a60204cc8b14a4eb030 (on 'core-updates'), thus
the hash was never adjusted for the new TeX revision.

Fixed in 37465b5be0324d9c953408fe88e2509ad0891712, thanks!


signature.asc
Description: PGP signature

bug#41668: Failing test: gui-installed-desktop-os-encrypted

[Brice Waegeneire]

Hello Guix,

For some time now the system test 'gui-installed-desktop-os-encrypted'
doesn't succeed, the last time it passed was 2020-04-11[0]. This is
problematic since it exercise a lot of packages and thus can be used to
test those packages. Ludovic attempted to fixed it[1] but it didn't 
fixed

the test on my side.

[0]: 
http://ci.guix.gnu.org/search?query=gui-installed-desktop-os-encrypted+system%3Ax86_64-linux+spec%3Aguix-master+status%3Asuccess

[1]: https://issues.guix.info/40790#7

- Brice

bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible

[Chris Marusich]

Hi,

As demonstrated in the following email thread, the powerpc64-linux
bootstrap-tarballs are not reproducible when cross-compiled from an
x86_64-linux system:

https://lists.gnu.org/archive/html/guix-devel/2020-06/msg3.html

Four people attempted to invoke the following command using Guix commit
8159ce1970d91567468cf1bacac313099a009d2a:

  guix build --no-substitutes --target=powerpc64-linux-gnu bootstrap-tarballs

All of the bootstrap tarballs except for gcc-stripped were reproducible.
However, these attempts produced four different versions of
gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz.  At least two of the
attempts were performed on two different x86_64-linux systems.

The derivation that produced the differing output was:

/gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv

You can build this derivation in a variety of ways, for example:

  guix build --target=powerpc64-linux-gnu -e '(@ (gnu packages make-bootstrap) 
%gcc-bootstrap-tarball)'

or just

  guix build 
/gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv

On my x86_64-linux system, twice I tried running "guix build --check" on
this derivation, but each time it surprisingly reported no difference.
Out of paranoia, I tried deleting its output with "guix gc --delete",
and then building it again.  The new output was, indeed, identical to
the old output.  This makes me think that the non-reproducibility is
coming from something outside the immediate build logic of the
gcc-stripped-tarball-5.5.0.drv derivation itself.

I will next try to rebuild everything from scratch again.  I will also
try to get copies of the differing outputs from the people involved in
that email thread, in order to run diffoscope on them.

-- 
Chris


signature.asc
Description: PGP signature

bug#41651: [PATCH] gnu: network-manager-applet: Propagate 'libnma'.

[Efraim Flashner]

On Tue, Jun 02, 2020 at 08:38:14PM +0200, Brice Waegeneire wrote:
> Fixes .
> 
> * gnu/packages/gnome.scm (network-manager-applet)[inputs]: Move 'libnma'
> to …
> [native-inputs]: … here.

I think you mean propagated

> ---
> 
> Sorry for the crappy patchset.  This patch should solve that issue.
> 
> 
>  gnu/packages/gnome.scm | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 0d63579d4a..860b5223b8 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -6730,13 +6730,14 @@ Cisco's AnyConnect SSL VPN.")
> ("gtk-doc" ,gtk-doc)
> ("pkg-config" ,pkg-config)))
>  (propagated-inputs
> - ;; libnm-gtk.pc refers to all these.
> - `(("dbus-glib" ,dbus-glib)
> + `(;; libnm-gtk.pc refers to all these.
> +   ("dbus-glib" ,dbus-glib)
> ("gtk+" ,gtk+)
> -   ("network-manager" ,network-manager)))
> +   ("network-manager" ,network-manager)
> +   ;; nm-applet need org.gnome.nm-applet.gschema.xml
> +   ("libnma" ,libnma)))
>  (inputs
>   `(("gcr" ,gcr)
> -   ("libnma" ,libnma)
> ("libgudev" ,libgudev)
> ("libnotify" ,libnotify)
> ("libsecret" ,libsecret)
> -- 
> 2.26.2
> 
> 
> 
> 

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


signature.asc
Description: PGP signature

bug#39584: evolution: involid page id error when composing emails

[Christopher Howard]

After updating system and user to
f51fd97ec54a98668d63c52d8a6bd75d8dc3292e, I am not able to reproduce
the problem, at least with a quick test. I send a few dozen emails a
day, so I should know within a day or two if the problem is really
gone, and will let you know if it isn't.

Gnome settings is show Gnome version 3.34.2.



-Original Message-
From: Marius Bakke 
To: Christopher Howard , 
39...@debbugs.gnu.org
Subject: Re: bug#39584: evolution: involid page id error when composing
emails
Date: Sat, 30 May 2020 19:32:57 +0200

Christopher Howard  writes:
> Hi, I use evolution heavily, current 3.32.4 from Guix. I updated
> myguix user packages and guix system about a week ago. When
> composingemails, I occasionally see an error similar to this appear
> in a boxabove the message composition area:
> gdbus.error:org.freedesktop.dbus.error.invalidargs: invalid page
> id:165
> While the error is there, I cannot save the email to drafts or send
> it.To resolve, I must copy the email contents to another program,
> thenrestart evolution to create the email again. It seems to be
> veryrandom, but I'd guess it happens once about every five to ten
> emails Isend.

Does this still occur with GNOME 3.34?
-- 
Christopher Howard
Enterprise Solutions Manager
Alaska Satellite Internet
PO Box 70, Ester, AK 99725
3239 La Ree Way, Fairbanks, AK 99709
907.451.0088
1.888.396.5623
www.alaskasatelliteinternet.com


signature.asc
Description: This is a digitally signed message part

bug#39584: evolution: involid page id error when composing emails

[Marius Bakke]

Christopher Howard  writes:

> After updating system and user to
> f51fd97ec54a98668d63c52d8a6bd75d8dc3292e, I am not able to reproduce
> the problem, at least with a quick test. I send a few dozen emails a
> day, so I should know within a day or two if the problem is really
> gone, and will let you know if it isn't.
>
> Gnome settings is show Gnome version 3.34.2.

That is great news, thanks for following through.

You can close this bug yourself by sending an email to "N-done"
where N is the issue ID (39584).  The message will still be
delivered to subscribers.

Fingers crossed!  :-)


signature.asc
Description: PGP signature

bug#41651: [PATCH v2] gnu: network-manager-applet: Propagate 'libnma'.

[Brice Waegeneire]

Fixes .

* gnu/packages/gnome.scm (network-manager-applet)[inputs]: Move 'libnma'
to …
[propagated-inputs]: … here.
---

On 2020-06-02 19:12, Efraim Flashner wrote:
> On Tue, Jun 02, 2020 at 08:38:14PM +0200, Brice Waegeneire wrote:
>> Fixes .
>>
>> * gnu/packages/gnome.scm (network-manager-applet)[inputs]: Move 'libnma'
>> to …
>> [native-inputs]: … here.
>
> I think you mean propagated

Yes, tank you Efraim, it's fixed in this version.

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

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 0d63579d4a..860b5223b8 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -6730,13 +6730,14 @@ Cisco's AnyConnect SSL VPN.")
("gtk-doc" ,gtk-doc)
("pkg-config" ,pkg-config)))
 (propagated-inputs
- ;; libnm-gtk.pc refers to all these.
- `(("dbus-glib" ,dbus-glib)
+ `(;; libnm-gtk.pc refers to all these.
+   ("dbus-glib" ,dbus-glib)
("gtk+" ,gtk+)
-   ("network-manager" ,network-manager)))
+   ("network-manager" ,network-manager)
+   ;; nm-applet need org.gnome.nm-applet.gschema.xml
+   ("libnma" ,libnma)))
 (inputs
  `(("gcr" ,gcr)
-   ("libnma" ,libnma)
("libgudev" ,libgudev)
("libnotify" ,libnotify)
("libsecret" ,libsecret)
-- 
2.26.2

bug#41672: nomad build failure:

[Christopher Howard]

Am receiving a build failure went attempting to install nomad.

christopher@eowyn ~$ guix package -i nomadThe following package will be
installed:   nomad 0.1.2-alpha
substitute: updating substitutes from 'https://ci.guix.gnu.org'...
100.0%The following derivation will be
built:   /gnu/store/xmby944frgcccmmjy05dpi31pjm43jh7-nomad-0.1.2-
alpha.drvbuilding /gnu/store/xmby944frgcccmmjy05dpi31pjm43jh7-nomad-
0.1.2-alpha.drv...| 'configure' phasebuilder for
`/gnu/store/xmby944frgcccmmjy05dpi31pjm43jh7-nomad-0.1.2-alpha.drv'
failed with exit code 1build of
/gnu/store/xmby944frgcccmmjy05dpi31pjm43jh7-nomad-0.1.2-alpha.drv
failedView build log at
'/var/log/guix/drvs/xm/by944frgcccmmjy05dpi31pjm43jh7-nomad-0.1.2-
alpha.drv.bz2'.guix package: error: build of
`/gnu/store/xmby944frgcccmmjy05dpi31pjm43jh7-nomad-0.1.2-alpha.drv'
failed
Build log dies with:

checking if (gcrypt hash) is available... noconfigure: error: guile-
gcrypt is missing; please install it.command
"/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash"
"./configure"
"CONFIG_SHELL=/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-
5.0.16/bin/bash" "SHELL=/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-
bash-5.0.16/bin/bash" "
--prefix=/gnu/store/016px9wmbw30xjplh6gq5jp9cpyfs3ck-nomad-0.1.2-alpha" 
"--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with
status 1
My information:
christopher@eowyn ~$ guix describeGeneration 20 Jun 02 2020 07:18:31
(current)  guix f51fd97repository URL: 
https://git.savannah.gnu.org/git/guix.gitbranch: mastercommit:
f51fd97ec54a98668d63c52d8a6bd75d8dc3292e

christopher@eowyn ~$ neofetchchristopher@eowyn - OS:
Guix System f51fd97ec54a98668d63c52d8a6bd75d8dc3292e x86_64 Host:
Vostro 230 00 Kernel: 5.4.43-gnu Uptime: 41 mins Packages: 57 (guix-
system), 86 (guix-user) Shell: bash 5.0.16 Resolution: 1920x1200 DE:
GNOME Theme: Adwaita [GTK2/3] Icons: Adwaita [GTK2/3] Terminal: .gnome-
terminal CPU: Intel Core 2 Duo E7500 (2) @ 2.029GHz GPU: Intel 4 Series
Chipset Memory: 1645MiB / 7929MiB 



-- 
Christopher Howard
Enterprise Solutions Manager
Alaska Satellite Internet
PO Box 70, Ester, AK 99725
3239 La Ree Way, Fairbanks, AK 99709
907.451.0088
1.888.396.5623
www.alaskasatelliteinternet.com

bug#41598: [staging] calibre build failure

[Marius Bakke]

Marius Bakke  writes:

> On the 'staging' branch (commit
> 8a7a5dc7805f4628e60f90af6b2416f951d0c034), "calibre" fails to build:
>
> g++ -c -pipe -O2 -Wall -Wextra -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_PLUGIN 
> -DQT_THEME_SUPPORT_LIB -DQT_FONTDATABASE_SUPPORT_LIB -DQT_SERVICE_SUPPORT_LIB 
> -DQT_EVENTDISPATCHER_SUPPORT_LIB -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I. 
> -isystem 
> /gnu/store/3x2kak8abb6z2klch72kfff2qxzv00pj-libpng-1.6.37/include/libpng16 
> -isystem 
> /gnu/store/haaam6v8l4s75mj9xmpb9gc78xk001y9-freetype-2.10.1/include/freetype2 
> -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5 
> -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtThemeSupport
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtThemeSupport/5.14.2
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtThemeSupport/5.14.2/QtThemeSupport
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtFontDatabaseSupport
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtFontDatabaseSupport/5.14.2
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtFontDatabaseSupport/5.14.2/QtFontDatabaseSupport
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtServiceSupport
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtServiceSupport/5.14.2
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtServiceSupport/5.14.2/QtServiceSupport
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtEventDispatcherSupport
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtEventDispatcherSupport/5.14.2
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtEventDispatcherSupport/5.14.2/QtEventDispatcherSupport
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtGui/5.14.2
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtGui/5.14.2/QtGui
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtGui 
> -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtCore/5.14.2
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtCore/5.14.2/QtCore
>  -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtDBus 
> -isystem 
> /gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/include/qt5/QtCore 
> -I. -isystem 
> /gnu/store/ka6amik38awpprjmbj01pnl9zsxgjjgz-libdrm-2.4.101/include/libdrm 
> -I/gnu/store/59dq1n4wj3maa3kcar6hspj2zd82as7q-qtbase-5.14.2/lib/qt5/mkspecs/linux-g++
>  -o main.o 
> /tmp/guix-build-calibre-3.42.0.drv-0/calibre-3.42.0/src/calibre/headless/main.cpp
> /tmp/guix-build-calibre-3.42.0.drv-0/calibre-3.42.0/src/calibre/headless/headless_integration.cpp:
>  In constructor ‘HeadlessIntegration::HeadlessIntegration(const 
> QStringList&)’:
> /tmp/guix-build-calibre-3.42.0.drv-0/calibre-3.42.0/src/calibre/headless/headless_integration.cpp:61:5:
>  error: ‘screenAdded’ was not declared in this scope
>  screenAdded(mPrimaryScreen);
>  ^~~
> make: *** [Makefile:336: headless_integration.o] Error 1
>
> Presumably this can be fixed by updating to the latest version of
> Calibre (4.17.0!).  Any takers?  :-)

I started working on this.  It now needs 'python2-pyqtwebengine', but
has some trouble because PyQt apparently really wants all the components
(sip, pyqt, pyqtwebengine) to live in the same directory, and does not
respect the standard search paths.

The Calibre build script works if I run it in a 'guix environment -C',
because that would set up a single union profile with all the packages.

I tried this hack as a workaround, but now it hits a SIGTRAP somewhere:

--8<---cut here---start->8---
(define (make-pyqt+pyqtwebengine-union pyqt pyqtwebengine)
  (package
(name (string-append (package-name pyqt) "+pyqtwebengine"))
(version (package-version pyqt))
(source #f)
(inputs
 `(("pyqt" ,pyqt)
   ("pyqtwebengine" ,pyqtwebengine)))
(build-system trivial-build-system)
(arguments
 '(#:modules ((guix build union))
   #:builder (begin
   (use-modules (ice-9 match)
(guix build union))
   (let ((out (assoc-ref %outputs "out")))
 (match %build-inputs
   (((names . directories) ...)
(union-build out directories)))
 #t
(home-page (package-home-page pyqt))
(license (package-license pyqt))
(synopsis "Union of PyQt and PyQtWebEngine")
(description
 "This package provides PyQt and PyQtWeb

bug#25632: shogun: Do not upgrade before adjusting the snippet (nonfree)

[Ricardo Wurmus]

zimoun  writes:

> This bug  [1] is fixed by commit 5a14e81e413.
> If it really is, feel free to close.

Yes, it’s fixed.  Thank you for checking!  Closing.

-- 
Ricardo

bug#41675: ant-bootstrap fails to build on i686-linux

[Diego Nicola Barbato]

Hey Guix,

Since the recent core-updates merge (commit 4bdf418) ant-bootstrap fails
to build on i686-linux.  I've attached the build log.

Regards,

Diego



snb6jmz4sd0l8rga6bhnzgzxy999ay-ant-bootstrap-1.8.4.drv.bz2
Description: ant-bootstrap-1.8.4.drv.bz2

bug#22883: Channel introductions

[zimoun]

Hi Ludo,

Really cool!
Well, even if I am not enough clever to understand all that.


On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès  wrote:

> I think we need a way to “introduce” a channel to its users that goes
> beyond a mere URL.

Just to be sure to well understand, will the good ol'
~/.config/guix/channels.scm

--8<---cut here---start->8---
 ;; Tell 'guix pull' to use my own repo.
 (list (channel
 (name 'guix)
 (url "https://example.org/my-guix.git";)
 (branch "super-hacks")))
--8<---cut here---end--->8---

still work as it is now? i.e., using the current "unauthorized"
mechanism.  Or will a new keyword be added to this channel description
to say "this channel does not use authorized machinery but it is
fine"?


>  If that information were stored in ‘.guix-channel’, it would be
>  trivial for an attacker to fork the project (or push a new commit)
>  and pretend the authentication process must not take previous
>  commits into account.

What will happen to recursive '.guix-channel'?  The '.guix-channel' of
channel A contains the reference to the channel B where the
'.guix-channel' contains the reference to the channel C, etc.


>   4. When publishing a fork of a channel, one emits a new channel
>  introduction.  Users switching to the fork have to explicitly allow
>  that new channel via its introduction; flipping the URL won’t be
>  enough because ‘guix pull’ would report unauthorized commits.

I am a bit afraid by this... and I hope that a fork of a channel will
still work without emitting a new channel introduction.


>   5. The channel URL is not included in the introduction.  However, the
>  official URL is an important piece of information: it tells users
>  this is where they’ll get the latest updates.  It should be
>  possible to create mirrors, but by default users should go to the
>  official URL.  They should be aware that mirrors can be outdated.

I do not understand this paragraph.  The aim of mirrors is to avoid
the users to go to the official URL, isn't it?  And the mirrors do not
have by design the latest updates (time to propagate, etc.).


>  I think the official URL can be stored in ‘.guix-channel’ in the
>  repo (which is subject to the authentication machinery).  That way,
>  ‘guix pull’ can let the user know if they’re talking to a mirror
>  rather than to the official channel.

Why does it matter?  The user should authenticate the downloaded
content whatever the URL serving it, isn't it?
And can 'guix pull' already let the users know to who they are talking?


> This verbose interface creates an incentive to create a ‘guix channel’
> command that could make it easier to add a new channel.

Yahoga! :-)


Thank you.

All the best,
simon

bug#41598: [staging] calibre build failure

[Michael Rohleder]

Marius Bakke  writes:
> I started working on this.  It now needs 'python2-pyqtwebengine', but
> has some trouble because PyQt apparently really wants all the components
> (sip, pyqt, pyqtwebengine) to live in the same directory, and does not
> respect the standard search paths.
>
> The Calibre build script works if I run it in a 'guix environment -C',
> because that would set up a single union profile with all the packages.
>
> I tried this hack as a workaround, but now it hits a SIGTRAP somewhere:

what I found out is that the versions between 3.45 and 3.48 compiles
with our qt version, only a (stupid) html test fails.

Maybe this could be a shorter route to get it working.

-- 
Programmierer sind Maschinen die Nikotin und Koffein in Programmcode umsetzen.


signature.asc
Description: PGP signature