bug#31711: closing

[Tom Zander via Bug reports for GNU Guix]

Installing fonts fixed this.

bug#40553: closing

[Tom Zander via Bug reports for GNU Guix]

Installing fonts fixed this.

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Jan Nieuwenhuizen]

Hello!

The wip-hurd-vm branch cross-builds a VM for the Hurd.  It uses some
dedicated hacks to build the system packages, services, system profile
and shepherd configuration and cross-build them into a qemu image.

We did this to avoid too much struggle up front with parameterizing,
working around, or removing Linux-specifics from "guix system
--target=i586-pc-gnu build,vm,..."

One problem that still remains is that the shepherd's activation .GO
files are not cross-compiled.  Currently, wip-hurd-vm works around that
by having the Shepherd load .SCM files instead of the (wrongly compiled)
.GO files.

After some discussion on IRC, I decided to find out if guix system build
--target=... might not have this bug.  That would make a great case to
start migrating some custom gnu/system/hurd.scm code to "guix system
--target=i586-pc-gnu ..."; we will have to do that some times soon
anyway.

guix system ..., however, shows has the same bug.  You can see that by
doing something like

--8<---cut here---start->8---
10:31:10 janneke@dundal:~/src/guix/core-updates [env]
$ timeout 5 ./pre-inst-env guix system build --target=arm-linux-gnueabihf 
--no-bootloader --no-grafts --verbosity=1 gnu/system/examples/bare-bones.tmpl 
|& grep shepherd.*go.drv
   /gnu/store/08brf243p0zfkz2d5imsy2swy1pzhpvb-shepherd-networking.go.drv
   /gnu/store/0wyzan9dmv23i4bjv6vlrq9h0zfph6gx-shepherd-console-font-tty4.go.drv
   /gnu/store/0x2mscizw7bhv3da3njhr6h37jmisk7r-shepherd-console-font-tty1.go.drv
   /gnu/store/2r2rc2kp3wfvrlkz7gkhz06ggy0x3g9i-shepherd-term-tty1.go.drv
   /gnu/store/3845nr3gczx6pia83d796r56a89ihhwq-shepherd-term-auto.go.drv
   /gnu/store/3a7mivzyr5cx9kgkxl2g2flv6z9mnb16-shepherd-console-font-tty5.go.drv
   
/gnu/store/5190cy2n0kcil0w1ln5f5z7rhnbp0m98-shepherd-file-system--dev-pts.go.drv
   /gnu/store/571pfgfi3q6ql0g1qadpm4ka06w1ckl1-shepherd-syslogd.go.drv
   /gnu/store/5j18jk5x33nkw4fdfdi4wwk03264sc1i-shepherd-nscd.go.drv
   /gnu/store/5kaacb0amw3k7avjj9xahbw50cchs4gc-shepherd-term-tty2.go.drv
   
/gnu/store/67idmlz2b4dsbj4s9x2733q4d2vlhql5-shepherd-ssh-daemon-ssh-sshd.go.drv
   /gnu/store/6n8pmflgqpkdcs02876n9f0nd51iggh3-shepherd-term-tty5.go.drv
   /gnu/store/9zrvxc2ii85zczv6yiq0h6z8xbsr69ny-shepherd-term-tty4.go.drv
   /gnu/store/blfzip72s4zwg8rwbs5n5x4m0jamlxzi-shepherd-user-homes.go.drv
   /gnu/store/bwks8ydmfcc4ig47qriwz02ja86lrpkn-shepherd-console-font-tty2.go.drv
   /gnu/store/fgimk2w6zfd11fn1mk1kzab2wh4f548g-shepherd-term-tty3.go.drv
   /gnu/store/g6dy6yqgn5rn6p0vza964kjsrnxymm4r-shepherd-term-tty6.go.drv
   
/gnu/store/hhmsgh0plqhb5448kdjjg6cl66l8fnqv-shepherd-file-system--dev-shm.go.drv
   /gnu/store/hhvs8400445b8gs7nfp8sya9c32k3h0q-shepherd-user-processes.go.drv
   /gnu/store/ihnl0bqhz0x88a393bbpxiq52rf0rd5w-shepherd-console-font-tty6.go.drv
   /gnu/store/ki7n8gg54mc9dbzw3i7drpzys2w15033-shepherd-guix-daemon.go.drv
   /gnu/store/nxnzrh2pbhnk2pxw8iggc28096p0vyqk-shepherd-root-file-system.go.drv
   /gnu/store/pw8p4ywnbamfz4ikr6zw9m4clszxakap-shepherd-console-font-tty3.go.drv
   /gnu/store/s3f030pywqps9fmdp0mnldyvmdkmm9d9-shepherd-file-systems.go.drv
   /gnu/store/vkafkq4qpnsijv7my0pw8qdg46ya206y-shepherd-user-file-systems.go.drv
   /gnu/store/vv25y5a8vga2syi716ph75x2xp0pjj7f-shepherd-mcron.go.drv
   /gnu/store/vxp0855svszgk8wix0mml2ahw48jdphx-shepherd-host-name.go.drv
   /gnu/store/x6s7b4il8a8lnwj8sshx786sq1l0mxsm-shepherd-loopback.go.drv
   /gnu/store/xnpg23wpxwyqjmh9vssp29kw2pwaq04x-shepherd-udev.go.drv
   
/gnu/store/y5nv3pplsbf9i1mzpg5p0ry0qv1qxq7c-shepherd-file-system--gnu-store.go.drv
   /gnu/store/z0a48zsv23pgy5d89ywj1sm9nwxdrwbq-shepherd-urandom-seed.go.drv
   /gnu/store/znn7813x9p1zn6bdywciqm6yk1qm7r0q-shepherd-virtual-terminal.go.drv
Terminated
[143]10:31:15 janneke@dundal:~/src/guix/core-updates [env]
$ ./pre-inst-env guix build --target=arm-linux-gnueabihf --no-grafts 
--verbosity=1 
/gnu/store/vxp0855svszgk8wix0mml2ahw48jdphx-shepherd-host-name.go.drv
...
/gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
$ 11:27:25 janneke@dundal:~/src/guix/core-updates [env]
$ file /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
/gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go: ELF 64-bit 
LSB shared object no machine, version 1 (embedded), dynamically linked, with 
debug_info, not stripped
--8<---cut here---end--->8---

Greetings,
janneke

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

bug#40842: uwsgi python plugin not found

[John D. Boy]

Here's what happens when I try to run an uwsgi process with the Python plugin.

$ guix environment --pure --ad-hoc python uwsgi uwsgi:python
$ uwsgi --ini uwsgi.ini 
[uWSGI] getting INI configuration from uwsgi.ini
open("/gnu/store/xmc67azy4vk3mcpyg3qy6vc2wq3v127w-uwsgi-2.0.18/lib/uwsgi/python_plugin.so"):
 No such file or directory [core/utils.c line 3724]
!!! UNABLE to load uWSGI plugin: 
/gnu/store/xmc67azy4vk3mcpyg3qy6vc2wq3v127w-uwsgi-2.0.18/lib/uwsgi/python_plugin.so:
 cannot open shared object file: No such file or directory !!!

The problem is that uwsgi looks for the plugin in the wrong place. The uwsgi 
package has two outputs ("out" and "python"), and the Pyton plugin goes into 
the latter (/gnu/store/...-uwsgi-2.0.18-python/lib/uwsgi). 

Unfortunately my packaging skills aren't (yet) good enough to figure out how to 
make the package aware of the proper plugin path. 

John

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Mathieu Othacehe]

Hello Jan,

> /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
> $ 11:27:25 janneke@dundal:~/src/guix/core-updates [env]
> $ file /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go
> /gnu/store/dbmj8ls2bwn0vbwi6qzng56rgrza3z0i-shepherd-host-name.go: ELF 64-bit 
> LSB shared object no machine, version 1 (embedded), dynamically linked, with 
> debug_info, not stripped

I strongly suspect this is because we would need to wrap the
"compile-file" call in "scm->go" procedure of (gnu services shepherd)
inside a "with-target".

That would look like:

--8<---cut here---start->8---
(if target
(with-target target
 (compile-file #$file #:output-file #$output
   #:env env))
  (compile-file #$file #:output-file #$output
#:env env))
--8<---cut here---end--->8---


Now, the tricky part is the value of target, because
#$(%current-target-system) might not be correct in that context.

Mathieu

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Mathieu Othacehe]

> The wip-hurd-vm branch cross-builds a VM for the Hurd.  It uses some
> dedicated hacks to build the system packages, services, system profile
> and shepherd configuration and cross-build them into a qemu image.
>
> We did this to avoid too much struggle up front with parameterizing,
> working around, or removing Linux-specifics from "guix system
> --target=i586-pc-gnu build,vm,..."

I have not followed really closely the recent progress on the Hurd, but
I think we may need to synchronize at some point :)

As you have noticed our image creation is very tied to Linux and Intel
x86 compatible machines. I would like in the future that producing images
for other architectures/kernels could be less hacky.

My idea is to:

* Speed up image creation by removing the need to use VM to produce
  images.

* Augment the operating-system record, or provide a new record, that
  encapsulates information related to image layout (partitions,
  bootloader location), target architecture (i586-pc-gnu,
  aarch64-linux, ...).

  This way, one would just have to run `guix system disk-image
  my-board.scm' or `guix system disk-image --board=xxx config.scm', and
  not have to worry about specifying the correct target triplet, kernel
  and bootloader packages.

On the wip-disk-image, I propose the creation of an "image" record in
(gnu image), but I'm still not sure how to interface it.

Thanks,

Mathieu

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

Hello Mathieu,

> I strongly suspect this is because we would need to wrap the
> "compile-file" call in "scm->go" procedure of (gnu services shepherd)
> inside a "with-target".

> That would look like:
>
> (if target
> (with-target target
>  (compile-file #$file #:output-file #$output
>#:env env))
>   (compile-file #$file #:output-file #$output
> #:env env))

Thank you!  I have tried this in the attached patch, and it seems to
work for me.

I was so puzzled why wrapping scm->go

--8<---cut here---start->8---
(use-modules (system base target))
(define (scm->go file)
  (with-target "i586-pc-gnu"
(lambda _
 ((@@ (gnu services shepherd) scm->go) file
--8<---cut here---end--->8---

did not work; actually reading scm->go makes that pretty clear :-)

> Now, the tricky part is the value of target, because
> #$(%current-target-system) might not be correct in that context.

I did read this, but wanted to try it first anyway.  So, what are you
seeing here, when would this not be OK?  Any other ideas of how to
address this further?

Greetings,
janneke

>From cc9259a87c46cfa0dc2c59dc425b3656c9eecb13 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen" 
Date: Sat, 25 Apr 2020 15:20:04 +0200
Subject: [PATCH] services: shepherd: Cross-compilation fix.

Fixes .
Reported by Jan (janneke) Nieuwenhuizen 
Fix suggested by Mathieu Othacehe 

* gnu/services/shepherd.scm (scm->go): Use `with-target' when cross-compiling.
---
 gnu/services/shepherd.scm | 40 +++
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index 2f30c6c907..ca4edd80ab 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -25,6 +25,7 @@
   #:use-module (guix store)
   #:use-module (guix records)
   #:use-module (guix derivations) ;imported-modules, etc.
+  #:use-module (guix utils)
   #:use-module (gnu services)
   #:use-module (gnu services herd)
   #:use-module (gnu packages admin)
@@ -260,22 +261,29 @@ stored."
 (define (scm->go file)
   "Compile FILE, which contains code to be loaded by shepherd's config file,
 and return the resulting '.go' file."
-  (with-extensions (list shepherd)
-(computed-file (string-append (basename (scheme-file-name file) ".scm")
-  ".go")
-   #~(begin
-   (use-modules (system base compile))
-
-   ;; Do the same as the Shepherd's 'load-in-user-module'.
-   (let ((env (make-fresh-user-module)))
- (module-use! env (resolve-interface '(oop goops)))
- (module-use! env (resolve-interface '(shepherd service)))
- (compile-file #$file #:output-file #$output
-   #:env env)))
-
-   ;; It's faster to build locally than to download.
-   #:options '(#:local-build? #t
-   #:substitutable? #f
+  (let ((target (%current-target-system)))
+(with-extensions (list shepherd)
+  (computed-file (string-append (basename (scheme-file-name file) ".scm")
+".go")
+ #~(begin
+ (use-modules (system base compile)
+  (system base target))
+
+ ;; Do the same as the Shepherd's 'load-in-user-module'.
+ (let ((env (make-fresh-user-module)))
+   (module-use! env (resolve-interface '(oop goops)))
+   (module-use! env (resolve-interface '(shepherd service)))
+   (if #$target
+   (with-target #$target
+ (lambda _
+   (compile-file #$file #:output-file #$output
+ #:env env)))
+   (compile-file #$file #:output-file #$output
+ #:env env
+
+ ;; It's faster to build locally than to download.
+ #:options '(#:local-build? #t
+ #:substitutable? #f)
 
 (define (shepherd-configuration-file services)
   "Return the shepherd configuration file for SERVICES."
-- 
2.26.0


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

bug#40848: doc: chapter "Building from Git" in "Contributing" misses to list required packages

[Stefan]

Hi!

The chapter "Building form Git" starts with two git commands to clone and 
verify the code. Unfortunately it misses to mention before that two packages 
are required for this to be working: git and gnupg.

While the former is obvious, the gnupg package is not that obvious. If you 
missed to install it, then the "git verify-commit" prints some error messages 
with "error: cannot run gpg". And unfortunately gpg is not the package name to 
install to solve this error.

It would be beneficial, if the two required packages git (or git-minimal?) and 
gnupg would be mentioned before starting with commands which would fail 
otherwise.

It would further help to repeat the wget command from the installation section 
to fetch the keys necessary for this verification, as there are other numbers 
printed beside the mentioned 3CE4645…

However that wget command requires yet another package to be installed: wget.

Finally trying to verify commit f84b0363053e5479464f6ce6ded45f80360d90fc it 
leaves this unresolved key: 

gpg: Signatur vom Sa 28 Mär 2020 21:30:07 CET
gpg:mittels RSA-Schlüssel 
39B33C8D94480D2DDCC2A4988B44A0CDC7B956F2
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel

The next command mentioned then is "make authenticate". It fails because the 
make package first needs to be installed. But even if this is done, it fails 
with "make: *** Keine Regel, um „authenticate“ zu erstellen.  Schluss." There 
has yet no Makefile been created.

Further down the commands "./bootstrap" and ".configure" are mentioned, which 
are both required to create the needed Makefile. But to be able to run this, 
all the listed dependencies need to be installed. 

Only after struggling down to the failing "make authenticate" there is the 
finally helpful command "guix environment guix —pure".

So to sum it all up: the packages to install and missed to mention are

 • git (or git-minimal?)
 • gnupg
 • wget 

The wget command to download the key should ideally be repeated. The "make 
authenticate" command is not helpful at all to be mentioned that early.

It would instead be very helpful, if first "guix environment guix —pure" would 
be mentioned, and if this (or a similar command) would also provide git, gnupg 
and wget to be able to fetch and verify the source code of guix as described by 
the first two commands "git clone …" and "git verify-commit …".

The "make authenticate" command must not be mentioned before but only after the 
"./bootstrap" and "./configure" commands.  Both "./bootstrap" and "./configure" 
should ideally be boxed like the other commands. This boxing would also help 
the important argument "--localstatedir=/var" to not be overseen.

In my case after all this and running ".configure" successfully, "make 
authenticate" still failed, because I relied on "guix environment guix —pure" 
to have a dependency to gnupg to have the gpg command accessible, which is 
unfortunately not the case.

I then exited the environment and started a new one with "guix environment guix 
--pure --ad-hoc gnupg" and ran "make authenticate" now with this result:

stefan@guix ~/development/guix [env]$ make authenticate
Authenticating Git checkout...
Authenticating d68de95 to f84b036 (14629 commits)...
[###   
]Backtrace:
  12 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2 11 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 10 (_ #(#(#)))
   293:34  9 (_ #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
142:2  8 (dynamic-wind _ _ #)
152:2  7 (with-fluid* _ _ _)
In srfi/srfi-1.scm:
   466:18  6 (fold # ?)
In ice-9/eval.scm:
   293:34  5 (_ #(#(# # ?) ?))
619:8  4 (_ #(#(#(#) # ?) ?))
   626:19  3 (_ #(#(#(#) # ?) ?))
In ice-9/boot-9.scm:
152:2  2 (with-fluid* _ _ _)
142:2  1 (dynamic-wind # ?)
142:2  0 (dynamic-wind # ?)

ice-9/boot-9.scm:142:2: In procedure dynamic-wind:
Throw to key `srfi-34' with args `(#)'.
make: *** [Makefile:5895: authenticate] Error 1

The documentation then finally suggest to run "make check". Isn't the actual 
build step with "make" missing?


I'm currently using 

guix describe
Generation 528. März 2020 18:44:49  (aktuell)
  guix e425713
Repository-URL: https://git.savannah.gnu.org/git/guix.git
Branch: master
Commit: e4257138fe1d924c56c9979b75319585b9251fb7

My profile is empty, no installed packages – I removed all packages again after 
obtaining the source code and before running "guix environment guix --pure 
--ad-hoc gnupg".


Bye

Stefan

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Ludovic Courtès]

Hey ho!

Mathieu Othacehe  skribis:

> That would look like:
>
> (if target
> (with-target target
>  (compile-file #$file #:output-file #$output
>#:env env))
>   (compile-file #$file #:output-file #$output
> #:env env))
>
>
> Now, the tricky part is the value of target, because
> #$(%current-target-system) might not be correct in that context.

Yes, that brings us back to .
Time flies!  But now we really need to address it.

Jan Nieuwenhuizen  skribis:

> +  (let ((target (%current-target-system)))
> +(with-extensions (list shepherd)
> +  (computed-file (string-append (basename (scheme-file-name file) ".scm")
> +".go")
> + #~(begin

The problem here is that ‘%current-target-system’ is not resolved in the
right context.  Though in practice, it’s “good enough” when using ‘guix
system build --target’ though, because ‘%current-target-system’ is bound
once and for all at the beginning.

What about applying this patch, but adding a FIXME comment above ‘let’
pointing at ?

Also, you can avoid duplicating the ‘compile-file’ call by writing it
like this:

  (with-target #$(or target #~%host-type)
(compile-file …))

Thanks!

Ludo’.

bug#40851: core-updates: GNOME Web: Application icon is rendered incorrectly

[sirgazil via Bug reports for GNU Guix]

It seems this bug was reported and fixed upstream 
(https://gitlab.gnome.org/GNOME/epiphany/-/issues/979). I'm filing this bug 
anyway, for the record.

The problem is reproducible in "guix system vm" too.


## Steps to reproduce

1. guix pull --branch=core-updates
2. sudo guix system reconfigure --fallback gnome.scm
3. Reboot
4. Log in to the GNOME desktop
5. Click on Activities
6. Click on the Applications button (the one with 9 dots)
7. Look for GNOME Web icon


## Unexpected result

The icon looks wrong:

https://multimedialib.files.wordpress.com/2020/04/guix-gnome-web-icon-bug-2020-04-24.png


## Expected result

The icon should look like this one:

https://multimedialib.files.wordpress.com/2020/04/gnome-web-icon-2020-04-25.png



## System information

GNOME Web 3.34.2

$ LANG=C guix describe
Generation 77   Apr 24 2020 19:03:47(current)
  guix 6ac6c1d
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: core-updates
commit: 6ac6c1d28d8a89d0f9b0f15e7df2a011f24aa091
  sirgazil-x ef6ac93
repository URL: https://gitlab.com/sirgazil/guix-channel-x.git
branch: master
commit: ef6ac9331a7847fdec6f0eb199524b1b755ba0d


---
https://sirgazil.bitbucket.io/

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

>> Now, the tricky part is the value of target, because
>> #$(%current-target-system) might not be correct in that context.
>
> Yes, that brings us back to .
> Time flies!  But now we really need to address it.

Oh!  Yes, I guess we need that as soon as we unify the hurd VM with the
guix system build?

> Jan Nieuwenhuizen  skribis:
>
>> +  (let ((target (%current-target-system)))
>> +(with-extensions (list shepherd)
>> +  (computed-file (string-append (basename (scheme-file-name file) 
>> ".scm")
>> +".go")
>> + #~(begin
>
> The problem here is that ‘%current-target-system’ is not resolved in the
> right context.  Though in practice, it’s “good enough” when using ‘guix
> system build --target’ though, because ‘%current-target-system’ is bound
> once and for all at the beginning.
>
> What about applying this patch, but adding a FIXME comment above ‘let’
> pointing at ?

Pushed to core-updates as d2fc76462e72268ee5b04fe53805efc05c35e139,
with...

> Also, you can avoid duplicating the ‘compile-file’ call by writing it
> like this:
>
>   (with-target #$(or target #~%host-type)

...this change too.  Nice, that works (I tried (%current-system), which
did not work).

Thanks!
janneke

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

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Jan Nieuwenhuizen]

Mathieu Othacehe writes:

>> We did this to avoid too much struggle up front with parameterizing,
>> working around, or removing Linux-specifics from "guix system
>> --target=i586-pc-gnu build,vm,..."
>
> I have not followed really closely the recent progress on the Hurd, but
> I think we may need to synchronize at some point :)

Oh no! :)

I haven't been following either...but I did notice that "guix system
reconfigure" may be tricky on the Hurd, given that it does not have
Qemu.  I was actively trying not to think about that, hoping some
solution would present itself.

> As you have noticed our image creation is very tied to Linux and Intel
> x86 compatible machines. I would like in the future that producing images
> for other architectures/kernels could be less hacky.

Yes...the Intel bit isn't really hurting the Hurd efforts yet (sadly),
but I see what you mean.

> My idea is to:
>
> * Speed up image creation by removing the need to use VM to produce
>   images.
>
> * Augment the operating-system record, or provide a new record, that
>   encapsulates information related to image layout (partitions,
>   bootloader location), target architecture (i586-pc-gnu,
>   aarch64-linux, ...).
>
>   This way, one would just have to run `guix system disk-image
>   my-board.scm' or `guix system disk-image --board=xxx config.scm', and
>   not have to worry about specifying the correct target triplet, kernel
>   and bootloader packages.
>
> On the wip-disk-image, I propose the creation of an "image" record in
> (gnu image), but I'm still not sure how to interface it.

Thanks for the ping and the summary: I should really look into that!

I am currently still looking to consolidate all the cross build fixes,
and how to migrate the Shepherd and services hacks into the regular
framework.  I'm guessing that's all stuff that wip-disk-image does not
touch/change.

Greetings,
janneke

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

bug#40744: guile-2.2.4 (integer-length 0) erroneously returns 0, not 1

[Bengt Richter]

Apologies for my faux pas ;-/

This was not a guix bug, and you have rightly ignored my report.
(now submitted to bug-guile, with hopes of nz human acks :)

(I guess it will get a new number, so 40744 can be closed?)

(BTW, no offense intended in addressing you as "guix/guile bug-squashers" ;-/)
On +2020-04-21 15:03:44 +0200, Bengt Richter wrote:
> Hello guix/guile bug-squashers,
> 
> The tl;dr is:
> (integer-length 0) should agree with:
> (string-length (number->string 0 2)) =-> 1
> -- and not:   (integer-length 0) =-> 0
-- 
Regards,
Bengt Richter

bug#40837: core-updates: epiphany web process crashes

[sirgazil via Bug reports for GNU Guix]

I can reproduce this bug. I can't load any page and see the same messages in 
the terminal.

bug#40858: Cargo in Guix

[Jan Ole Zabel]

Hi,

I just installed the rust package on guix-system and realized I have no
idea of how to use `cargo` to build something. First, cargo is not in my
search path after installing `rust`, because there is no link in
`.guix-profile`. There is no dedicated package either. Second, the
cargo binary installed in `/gnu/store/` throws the following:

$ /gnu/store/*-rust-1.39.0-cargo/bin/cargo install ripgrep
error: failed to download from
`https://crates.io/api/ripgrep/12.0.1/download`

Caused by:
  [60] SSL peer certificate or SSH remote key not found (server
certificate verification failed. CAfile: none CRLFile: none)

A `curl https://crates.io` works normally, so it's not an issue with the
system certificates.

Am I doing something wrong? Is this even the right place to report or ask?

bug#40837: core-updates: epiphany web process crashes

[Jack Hill]

On Sat, 25 Apr 2020, sirgazil via Bug reports for GNU Guix wrote:


I can reproduce this bug. I can't load any page and see the same messages in 
the terminal.


Thanks, as a fist step it is helpful to know that the problem can be 
reproduced.


The second step is to figure out why this is happening. My suspicion is 
that the bwrap invocation by webkitgtk is not sharing some paths into the 
new namespace it creates that it should be, because the paths are 
different on Guix System than they are on FHS systems.


Stracing epiphany, I've turned up the bwrap invocation to be:

execve("/gnu/store/kzq4v5fvjbdbbwah74k10pf698xkbdpr-bubblewrap-0.4.1/bin/bwrap", 
["/gnu/store/kzq4v5fvjbdbbwah74k10pf698xkbdpr-bubblewrap-0.4.1/bin/bwrap", 
"--args", "36", "--", 
"/gnu/store/1skpd1p64x982c52anh4a5yhlp05paa6-webkitgtk-2.28.1/libexec/webkit2gtk-4.0/WebKitWebProcess", 
"11", "31"]


File descriptor 36, which hold the bwrap arguments is

write(36, 
"--die-with-parent\0--unshare-pid\0--unshare-uts\0--unshare-net\0--ro-bind\0/etc\0/etc\0--dev\0/dev\0--proc\0/proc\0--tmpfs\0/tmp\0--unsetenv\0TMPDIR\0--dir\0/run\0--symlink\0../run\0/var/run\0--symlink\0../tmp\0/var/tmp\0--ro-bind\0/sys/block\0/sys/block\0--ro-bind\0/sys/bus\0/sys/bus\0--ro-bind\0/sys/class\0/sys/class\0--ro-bind\0/sys/dev\0/sys/dev\0--ro-bind\0/sys/devices\0/sys/devices\0--ro-bind-try\0/usr/share\0/usr/share\0--ro-bind-try\0/usr/local/share\0/usr/local/share\0--ro-bind-try\0/gnu/store/1skpd1p64x982c52anh4a5yhlp05paa6-webkitgtk-2.28.1/share\0/gnu/store/1skpd1p64x982c52anh4a5yhlp05paa6-webkitgtk-2.28.1/share\0--ro-bind-try\0/lib\0/lib\0--ro-bind-try\0/usr/lib\0/usr/lib\0--ro-bind-try\0/usr/local/lib\0/usr/local/lib\0--ro-bind-try\0/gnu/store/1skpd1p64x982c52anh4a5yhlp05paa6-webkitgtk-2.28.1/lib\0/gnu/store/1skpd1p64x982c52anh4a5yhlp05paa6-webkitgtk-2.28.1/lib\0--ro-bind-try\0/lib64\0/lib64\0--ro-bind-try\0/usr/lib64\0/usr/lib64\0--ro-bind-try\0/usr/local/lib64\0/usr/local/lib64\0--ro-bind-try\0/gnu/store/1skpd1p64x982c52anh4a5yhlp05paa6-webkitgtk-2.28.1/libexec/webkit2gtk-4.0\0/gnu/store/1skpd1p64x982c52anh4a5yhlp05paa6-webkitgtk-2.28.1/libexec/webkit2gtk-4.0\0--ro-bind-try\0/gnu/store/h6pd8k3glp23k868i0ij5x2v5kzfgsrv-gdk-pixbuf+svg-2.40.0/lib\0/gnu/store/h6pd8k3glp23k868i0ij5x2v5kzfgsrv-gdk-pixbuf+svg-2.40.0/lib\0--ro-bind-try\0/gnu/store/9s7khsp79c223jvbbv0icyn5fdm7v6cb-gnome-bluetooth-3.34.0/lib\0/gnu/store/9s7khsp79c223jvbbv0icyn5fdm7v6cb-gnome-bluetooth-3.34.0/lib\0--ro-bind-try\0/gnu/store/ry4zm4c39nz78h42hmbq6rb6mg6axxzg-librsvg-2.40.21/lib\0/gnu/store/ry4zm4c39nz78h42hmbq6rb6mg6axxzg-librsvg-2.40.21/lib\0--ro-bind-try\0/gnu/store/y37h19fz5pr3m99aw8g9hksz2pv1xr1f-libgweather-3.34.0/lib\0/gnu/store/y37h19fz5pr3m99aw8g9hksz2pv1xr1f-libgweather-3.34.0/lib\0--setenv\0LD_LIBRARY_PATH\0/gnu/store/h6pd8k3glp23k868i0ij5x2v5kzfgsrv-gdk-pixbuf+svg-2.40.0/lib:/gnu/store/9s7khsp79c223jvbbv0icyn5fdm7v6cb-gnome-bluetooth-3.34.0/lib:/gnu/store/ry4zm4c39nz78h42hmbq6rb6mg6axxzg-librsvg-2.40.21/lib:/gnu/store/y37h19fz5pr3m99aw8g9hksz2pv1xr1f-libgweather-3.34.0/lib\0--ro-bind-data\00033\0/.flatpak-info\0--bind-try\0/tmp/.X11-unix/X1\0/tmp/.X11-unix/X1\0--ro-bind-try\0/run/user/1000/gdm/Xauthority\0/run/user/1000/gdm/Xauthority\0--ro-bind-try\0/tmp/epiphany-jackhill-hoj0lD\0/tmp/epiphany-jackhill-hoj0lD\0--ro-bind-try\0/home/jackhill/.local/share/epiphany\0/home/jackhill/.local/share/epiphany\0--ro-bind-try\0/home/jackhill/.cache/epiphany\0/home/jackhill/.cache/epiphany\0--ro-bind-try\0/home/jackhill/.config/epiphany\0/home/jackhill/.config/epiphany\0--bind-try\0/home/jackhill/.cache/epiphany/applications\0/home/jackhill/.cache/epiphany/applications\0--bind-try\0/home/jackhill/.local/share/webkitgtk/mediakeys\0/home/jackhill/.local/share/webkitgtk/mediakeys\0--bind-try\0/home/jackhill/.local/share/epiphany/databases\0/home/jackhill/.local/share/epiphany/databases\0--bind-try\0/run/user/1000/pulse\0/run/user/1000/pulse\0--ro-bind-try\0/etc/pulse/client.conf\0/etc/pulse/client.conf\0--ro-bind-try\0/home/jackhill/.config/pulse\0/home/jackhill/.config/pulse\0--ro-bind-try\0/home/jackhill/.pulse\0/home/jackhill/.pulse\0--ro-bind-try\0/home/jackhill/.asoundrc\0/home/jackhill/.asoundrc\0--dev-bind-try\0/dev/snd\0/dev/snd\0--ro-bind-try\0/home/jackhill/.config/fontconfig\0/home/jackhill/.config/fontconfig\0--ro-bind-try\0/home/jackhill/.fontconfig\0/home/jackhill/.fontconfig\0--bind-try\0/home/jackhill/.cache/fontconfig\0/home/jackhill/.cache/fontconfig\0--ro-bind-try\0/home/jackhill/.fonts.conf\0/home/jackhill/.fonts.conf\0--ro-bind-try\0/home/jackhill/.config/.fonts.conf.d\0/home/jackhill/.config/.fonts.conf.d\0--ro-bind-try\0/home/jackhill/.local/share/fonts\0/home/jackhill/.local/share/fonts\0--ro-bind-try\0/home/jackhill/.fonts\0/home/jackhill/.fonts\0--ro-bind-try\0/var/cache/fontconfig\0/var/cache/fontconfig\0--ro-bind-try\0/home/jackhill/.guix-profile/lib/gstreamer-1.0\0/home/jackhill/.guix-profile/lib/gstreamer-1.0\0--ro-bind-try\0/home/jackhill/.guix-profile/lib/gstreame

bug#40837: core-updates: epiphany web process crashes

[Jack Hill]

I now think what is being shared with bubblewrap is on the write track.

After seeing

"""
const char* pulseConfig = g_getenv("PULSE_CLIENTCONFIG");
if (pulseConfig)
bindIfExists(args, pulseConfig);
"""

in Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp of 
WebKitGTK, I set the PULSE_CLIENTCONFIG environemnt variable to the store 
path rather than /etc/pulse/client.conf, which is what it was set to 
before.


That allowed epiphany to get past the problem with client.conf. However, 
it then hits another problem with something not being shared as seen in 
this session:


"""
$ env |grep PULSE
PULSE_CLIENTCONFIG=gnu/store/zc4dsmvdabi00nvisrjhi9w00ff4igs7-client.conf
PULSE_CONFIG=/etc/pulse/daemon.conf
$ epiphany

** (epiphany:11528): CRITICAL **: 21:38:10.896: void 
webkit_web_context_register_uri_scheme(WebKitWebContext*, const char*, 
WebKitURISchemeRequestCallback, gpointer, GDestroyNotify): assertion 
'g_ascii_strcasecmp(scheme, "ftp") != 0' failed
bwrap: execvp 
/gnu/store/1skpd1p64x982c52anh4a5yhlp05paa6-webkitgtk-2.28.1/libexec/webkit2gtk-4.0/WebKitWebProcess:
 No such file or directory
^C
"""

Best,
Jack

bug#40837: core-updates: epiphany web process crashes

[Jack Hill]

On Sat, 25 Apr 2020, Jack Hill wrote:

in Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp of WebKitGTK, 
I set the PULSE_CLIENTCONFIG environemnt variable to the store path rather 
than /etc/pulse/client.conf, which is what it was set to before.


That allowed epiphany to get past the problem with client.conf. However, it 
then hits another problem with something not being shared as seen in this 
session:


I tried patching webkitgtk to share the whole /gnu/store in the new mount 
namespace (see attached patch). Unfortunately, when I ran epiphany with 
that patch applied and PULSE_CLIENTCONFIG set to /etc/pulse/client.conf, 
the "bwrap: Can't create file at /etc/pulse/client.conf: No such file or 
directory" error returned.


Via strace, I saw that my patch was having an effect on the arguments to 
bwrap. Could it be that the order of the --bind/--ro-bind arguments 
matters?


Thoughts?
JackFrom f8901a83e2abc2c6ab34f5883663315b8d715e2f Mon Sep 17 00:00:00 2001
From: Jack Hill 
Date: Sat, 25 Apr 2020 22:03:48 -0400
Subject: [PATCH] gnu: webkitgtk: Patch to share store via bwarp

* gnu/packages/patches/webkitgtk-share-store.patch: New File.
* gnu/local.mk: Add here.
* gnu/packages/webkit.scm (webkitgtk)[source]: Apply patch.
---
 gnu/local.mk   |  1 +
 .../patches/webkitgtk-share-store.patch| 18 ++
 gnu/packages/webkit.scm|  4 +++-
 3 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/webkitgtk-share-store.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 2780434455..6c11a07c24 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1554,6 +1554,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/vte-CVE-2012-2738-pt1.patch			\
   %D%/packages/patches/vte-CVE-2012-2738-pt2.patch			\
   %D%/packages/patches/weasyprint-library-paths.patch		\
+  %D%/packages/patches/webkitgtk-share-store.patch		\
   %D%/packages/patches/websocketpp-fix-for-boost-1.70.patch	\
   %D%/packages/patches/wicd-bitrate-none-fix.patch		\
   %D%/packages/patches/wicd-get-selected-profile-fix.patch	\
diff --git a/gnu/packages/patches/webkitgtk-share-store.patch b/gnu/packages/patches/webkitgtk-share-store.patch
new file mode 100644
index 00..b927ab7b0a
--- /dev/null
+++ b/gnu/packages/patches/webkitgtk-share-store.patch
@@ -0,0 +1,18 @@
+Author: Jack Hill 
+Tell bubblewrap to share the store
+---
+diff --git a/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp b/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
+index ad301ab2..d53b680e 100644
+--- a/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
 b/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
+@@ -737,6 +737,10 @@ GRefPtr bubblewrapSpawn(GSubprocessLauncher* launcher, const Proces
+ "--ro-bind-try", "/usr/local/share", "/usr/local/share",
+ "--ro-bind-try", DATADIR, DATADIR,
+ 
++   // TESTING: bind moutn /gnu/store
++   // This should be improved
++   "--ro-bind", "/gnu/store", "/gnu/store",
++
+ // We only grant access to the libdirs webkit is built with and
+ // guess system libdirs. This will always have some edge cases.
+ "--ro-bind-try", "/lib", "/lib",
diff --git a/gnu/packages/webkit.scm b/gnu/packages/webkit.scm
index 377fc0dfaf..fcfd28666b 100644
--- a/gnu/packages/webkit.scm
+++ b/gnu/packages/webkit.scm
@@ -128,7 +128,9 @@ engine that uses Wayland for graphics output.")
   "webkitgtk-" version ".tar.xz"))
   (sha256
(base32
-"1n7k4yriqhr38f4fgy8pzdn1nm60m53z8p478sgg64swxnijdg5c"
+"1n7k4yriqhr38f4fgy8pzdn1nm60m53z8p478sgg64swxnijdg5c"))
+  (patches
+   (search-patches "webkitgtk-share-store.patch"
 (build-system cmake-build-system)
 (outputs '("out" "doc"))
 (arguments
-- 
2.26.2