bug#41625: [PATCH v2] offload: Handle a possible EOF response from read-repl-response.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

[...]

>>  (define* (read-repl-response port #:optional inferior)
>>"Read a (guix repl) response from PORT and return it as a Scheme object.
>>  Raise '' when an exception is read from PORT."
>> @@ -241,6 +246,10 @@ Raise '' when an exception is read 
>> from PORT."
>>(match (read port)
>>  (('values objects ...)
>>   (apply values (map sexp->object objects)))
>> +;; Unexpectedly read EOF from the port.  This can happen for example 
>> when
>> +;; the underlying connection for PORT was lost with Guile-SSH.
>> +(? eof-object?
>> +   (raise (condition (
>
> The match clause syntax is incorrect; should be:
>
>  ((? eof-object?)
>   (raise …))

Good catch, fixed.

>> +(info (G_ "Testing ~a build machines defined in '~a'...~%")
>>(length machines) machine-file)
>> -(let* ((names(map build-machine-name machines))
>> -   (sockets  (map build-machine-daemon-socket machines))
>> -   (sessions (map (cut open-ssh-session <> %short-timeout) 
>> machines))
>> -   (nodes(map remote-inferior sessions)))
>> -  (for-each assert-node-has-guix nodes names)
>> -  (for-each assert-node-repl nodes names)
>> -  (for-each assert-node-can-import sessions nodes names sockets)
>> -  (for-each assert-node-can-export sessions nodes names sockets)
>> -  (for-each close-inferior nodes)
>> -  (for-each disconnect! sessions
>> +(par-for-each check-machine-availability machines)))
>
> Why not!  IMO this should go in a separate patch, though, since it’s not
> related.

For me, it is related in that retrying all the checks of *every* build
offload machine would be too expensive; it already takes 32 s for my 4
offload machines; retrying this for up to 3 times would mean waiting for
a minute and half, which I don't find reasonable (imagine on berlin!).

>> +(define (check-machine-availability machine)
>> +  "Check whether MACHINE is available.  Exit with an error upon failure."
>> +  ;; Sometimes, the machine remote port may return EOF, presumably because 
>> the
>> +  ;; connection was lost.  Retry up to 3 times.
>> +  (let loop ((retries 3))
>> +(guard (c ((inferior-connection-lost? c)
>> +   (let ((retries-left (1- retries)))
>> + (if (> retries-left 0)
>> + (begin
>> +   (format (current-error-port)
>> +   (G_ "connection to machine ~s lost; 
>> retrying~%")
>> +   (build-machine-name machine))
>> +   (loop (retries-left)))
>> + (leave (G_ "connection repeatedly lost with machine 
>> '~a'~%")
>> +(build-machine-name machine))
>
> I’m afraid we’re papering over problems here.

I had that thought too, but then also realized that even if this was
papering over a problem, it'd be a good one to paper over as this
problem can legitimately happen in practice, due to the network's
inherently shaky nature.  It seems better to be ready for it.  Also, my
hopes in being able to troubleshoot such a difficult to reproduce
networking issue are rather low.

> Is running ‘guix offload test /etc/guix/machines.scm overdrive1’ on
> berlin enough to reproduce the issue?  If so, we could monitor/strace
> sshd on overdrive1 to get a better understanding of what’s going on.

It's actually difficult to trigger it; it seems to happen mostly on the
first try after a long time without connecting to the machine; on the
2nd and later tries, everything is smooth.  Waiting a few minutes is not
enough to re-trigger the problem.

I've managed to see the problem a few lucky times with:

--8<---cut here---start->8---
while true; do guix offload test /etc/guix/machines.scm overdrive1; done
--8<---cut here---end--->8---

I don't have a password set for my user on overdrive1, so can't attach
strace to sshd, but yeah, we could try to capture it and see if we can
understand what's going on.

Attached is v2 of the patch, with the match clause fixed.

>From c52172502749a4d194dc51db9d2c394cb15e8d07 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Tue, 25 May 2021 08:42:06 -0400
Subject: [PATCH] offload: Handle a possible EOF response from
 read-repl-response.

Fixes .

* guix/scripts/offload.scm (check-machine-availability): Refactor so that it
takes a single machine object, to allow for retrying a single machine.  Handle
the case where the checks raised an exception due to the connection to the
build machine having been lost, and retry up to 3 times.  Ensure the cleanup
code is run in all situations.
(check-machines-availability): New procedure.  Call
CHECK-MACHINES-AVAILABILITY in parallel, which improves performance (about
twice as fast with 4 build machines, from ~30 s to ~15 s).
* guix/inferior.scm (): New 

bug#48636: Gajim does not load the "close" icon on the chat window

[Joshua Branson via Bug reports for GNU Guix]

"bdju"  writes:

> On Mon May 24, 2021 at 6:19 PM CDT, Joshua Branson via Bug reports for GNU 
> Guix wrote:
>> It also doesn't remember my password. I have to type it in again
>> everytime I open Gajim.
>
> You can work around this part by going to Gajim menu -> Preferences ->
> Advanced and toggling "Use System Keyring" to off. In theory setting up
> something like gnome keyring or similar should also work with the
> default setting and then save/access passwords that way. I could not
> figure it out after hours of trying stuff, but if you toggle that
> setting, it will save your passwords without relying on a keyring. I'm
> not sure if it's less secure or something in exchange.
>

Thanks!  That worked!


--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

bug#41625: [PATCH] offload: Handle a possible EOF response from read-repl-response.

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Fixes .
>
> * guix/scripts/offload.scm (check-machine-availability): Refactor so that it
> takes a single machine object, to allow for retrying a single machine.  Handle
> the case where the checks raised an exception due to the connection to the
> build machine having been lost, and retry up to 3 times.  Ensure the cleanup
> code is run in all situations.
> (check-machines-availability): New procedure.  Call
> CHECK-MACHINES-AVAILABILITY in parallel, which improves performance (about
> twice as fast with 4 build machines, from ~30 s to ~15 s).
> * guix/inferior.scm (): New condition type.
> (read-repl-response): Raise a condition of the above type when reading EOF
> from the build machine's port.

[...]

> +(define-condition-type  
> +  inferior-connection-lost?)
> +
>  (define* (read-repl-response port #:optional inferior)
>"Read a (guix repl) response from PORT and return it as a Scheme object.
>  Raise '' when an exception is read from PORT."
> @@ -241,6 +246,10 @@ Raise '' when an exception is read 
> from PORT."
>(match (read port)
>  (('values objects ...)
>   (apply values (map sexp->object objects)))
> +;; Unexpectedly read EOF from the port.  This can happen for example when
> +;; the underlying connection for PORT was lost with Guile-SSH.
> +(? eof-object?
> +   (raise (condition (

The match clause syntax is incorrect; should be:

 ((? eof-object?)
  (raise …))

> +(info (G_ "Testing ~a build machines defined in '~a'...~%")
>(length machines) machine-file)
> -(let* ((names(map build-machine-name machines))
> -   (sockets  (map build-machine-daemon-socket machines))
> -   (sessions (map (cut open-ssh-session <> %short-timeout) machines))
> -   (nodes(map remote-inferior sessions)))
> -  (for-each assert-node-has-guix nodes names)
> -  (for-each assert-node-repl nodes names)
> -  (for-each assert-node-can-import sessions nodes names sockets)
> -  (for-each assert-node-can-export sessions nodes names sockets)
> -  (for-each close-inferior nodes)
> -  (for-each disconnect! sessions
> +(par-for-each check-machine-availability machines)))

Why not!  IMO this should go in a separate patch, though, since it’s not
related.

> +(define (check-machine-availability machine)
> +  "Check whether MACHINE is available.  Exit with an error upon failure."
> +  ;; Sometimes, the machine remote port may return EOF, presumably because 
> the
> +  ;; connection was lost.  Retry up to 3 times.
> +  (let loop ((retries 3))
> +(guard (c ((inferior-connection-lost? c)
> +   (let ((retries-left (1- retries)))
> + (if (> retries-left 0)
> + (begin
> +   (format (current-error-port)
> +   (G_ "connection to machine ~s lost; 
> retrying~%")
> +   (build-machine-name machine))
> +   (loop (retries-left)))
> + (leave (G_ "connection repeatedly lost with machine 
> '~a'~%")
> +(build-machine-name machine))

I’m afraid we’re papering over problems here.

Is running ‘guix offload test /etc/guix/machines.scm overdrive1’ on
berlin enough to reproduce the issue?  If so, we could monitor/strace
sshd on overdrive1 to get a better understanding of what’s going on.

WDYT?

Thanks,
Ludo’.

bug#46330: Guile-provided GMP allocators interfere with GnuTLS

[Ludovic Courtès]

Hi Marius,

Marius Bakke  skribis:

> Ludovic Courtès  skriver:
>
>> Ludovic Courtès  skribis:
>>
>>> One of the solutions is to set:
>>>
>>>   scm_install_gmp_memory_functions = 0;
>>
>> Done in a53f711422f63d7e32b8639b968cf00bcc69ffea, followed by an update
>> of the ‘guix’ package in 63d4b74420563c4e2dbdfa29b3816d1dad9cd723.
>>
>> This mostly solves the problem on the Guix side, but the issue remains
>> in GnuTLS.  I practical terms, we could experience random test failures
>> in the guile-gnutls test suite, like the Debian folks did.
>>
>> At the very least we’ll need to work around that possibility in
>> ‘core-updates’.  We could skip them, or add ‘gc-disable’ calls there.
>> Or we could build GnuTLS against Nettle-with-mini-GMP when that becomes
>> an option.
>>
>> The other option coming up is to build Guile against mini-GMP.  Mike
>> Gran just started looked into it and it may be that 3.0.6 will offer it.
>>
>> I’m keeping the bug open until this is sorted out.
>
> I believe this was sorted with the mini-gmp in Guile 3.0.6.  Please
> reopen if I'm mistaken.  :-)

Definitely; it’s wonderful.  :-)

I adjusted ‘guile-launcher.c’ accordingly in
d92ee0a8bdc324726e737bf4ef099d75724ce8c9.

Thanks,
Ludo’.

bug#48636: Gajim does not load the "close" icon on the chat window

[bdju]

On Mon May 24, 2021 at 6:48 PM CDT, Joshua Branson via Bug reports for GNU Guix 
wrote:
>
> Other clues that the chat on irc disclosed:
> (org.gajim.Gajim:6250): Gtk-WARNING **: 14:31:46.574: Could not find the
> icon 'org.gajim.Gajim'. The 'hicolor' theme
> was not found either, perhaps you need to install it.
> 05/21/2021 14:31:46 (W) gajim.plugin_system Error while loading module:
> gtk-icon-theme-error-quark: Icon 'preferences-system' not present in
> theme Adwaita (0)
I have adwaita-icon-theme and hicolor-icon-theme in my system profile,
which I think makes some gtk stuff play nicer. I would suggest
installing them if you don't have them. Especially hicolor, since it's
mentioned in your error output. I also have gnome-themes-standard and
gnome-themes-extra, so those may also be worth installing if the other
things don't do the trick. IIRC some gtk themes don't stand completely
on their own, and so they'll have missing bits if you don't have some of
the basic ones like adwaita. It's also possible you don't have any icon
themes at all.
Perhaps the hicolor icons should be made a dependency so users don't
have to figure this out on their own. I recall another package getting
that treatment a while back.

bug#48636: Gajim does not load the "close" icon on the chat window

[bdju]

On Mon May 24, 2021 at 6:19 PM CDT, Joshua Branson via Bug reports for GNU Guix 
wrote:
> It also doesn't remember my password. I have to type it in again
> everytime I open Gajim.

You can work around this part by going to Gajim menu -> Preferences ->
Advanced and toggling "Use System Keyring" to off. In theory setting up
something like gnome keyring or similar should also work with the
default setting and then save/access passwords that way. I could not
figure it out after hours of trying stuff, but if you toggle that
setting, it will save your passwords without relying on a keyring. I'm
not sure if it's less secure or something in exchange.

P.S. If you need to close Gajim, ctrl-q will do it, or the sway keybind
(default super-shift-q) can close it too. Not a fix for the button being
gone, but maybe it'll help.

bug#47823: Hardenize Guix website TLS/DNS

[bo0od]

If the server configured DNSSEC in a bad way then for surely it wont 
work and thats what happened with gnu.org if you read this ticket:


https://github.com/systemd/systemd/issues/9867

This ticket show clearly that the operators of gnu.org didnt fix their 
bad DNSSEC configuration despite being pointed out to them.


https://danwin1210.me

e.g This domain use DNSSEC where is the problem connecting to it?


Julien Lepiller:

No, resolved is on the client side. This means that they managed to set up 
dnssec, but some clients who use systemd (most Linux users) can't connect to 
gnu.org domains anymore. I don't think this is acceptable :)

Le 25 mai 2021 08:51:29 GMT-04:00, bo0od  a écrit :

Then dont use systemd to do that. There many other methods/tools to
achieve having it.

Marius Bakke:

Julien Lepiller  skriver:


Le 16 avril 2021 12:15:25 GMT-04:00, Leo Famulari

 a écrit :

On Fri, Apr 16, 2021 at 11:00:05AM +, bo0od wrote:

Scanning Guix website gave many missing security features which

modern

security needs them to be available:

* TLS and DNS:

looking at:

https://www.hardenize.com/report/guix.gnu.org/1618568751

https://www.ssllabs.com/ssltest/analyze.html?d=guix.gnu.org


Thanks!


- DNS: DNSSEC support missing (important)


Hm, is it important? My impression is that it's an idea whose time

has

passed without significant adoption.

But maybe we could enable it if the costs are not too great.


gnu.org does not have dnssec, so we'd need them to work on that

first.


gnu.org used to have DNSSEC, but disabled it because it gave NXDOMAIN
on machines with systemd-resolved:

https://github.com/systemd/systemd/issues/9867

bug#41625: [PATCH] offload: Handle a possible EOF response from read-repl-response.

[Maxim Cournoyer]

Fixes .

* guix/scripts/offload.scm (check-machine-availability): Refactor so that it
takes a single machine object, to allow for retrying a single machine.  Handle
the case where the checks raised an exception due to the connection to the
build machine having been lost, and retry up to 3 times.  Ensure the cleanup
code is run in all situations.
(check-machines-availability): New procedure.  Call
CHECK-MACHINES-AVAILABILITY in parallel, which improves performance (about
twice as fast with 4 build machines, from ~30 s to ~15 s).
* guix/inferior.scm (): New condition type.
(read-repl-response): Raise a condition of the above type when reading EOF
from the build machine's port.
---
 guix/inferior.scm|  9 
 guix/scripts/offload.scm | 50 +---
 2 files changed, 45 insertions(+), 14 deletions(-)

diff --git a/guix/inferior.scm b/guix/inferior.scm
index 7c8e478f2a..4ac1ea3484 100644
--- a/guix/inferior.scm
+++ b/guix/inferior.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2018, 2019, 2020, 2021 Ludovic Courtès 
+;;; Copyright © 2021 Maxim Cournoyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -70,6 +71,7 @@
 inferior-exception-arguments
 inferior-exception-inferior
 inferior-exception-stack
+inferior-connection-lost?
 read-repl-response
 
 inferior-packages
@@ -228,6 +230,9 @@ equivalent.  Return #f if the inferior could not be 
launched."
   (inferior   inferior-exception-inferior); | #f
   (stack  inferior-exception-stack))  ;list of (FILE COLUMN LINE)
 
+(define-condition-type  
+  inferior-connection-lost?)
+
 (define* (read-repl-response port #:optional inferior)
   "Read a (guix repl) response from PORT and return it as a Scheme object.
 Raise '' when an exception is read from PORT."
@@ -241,6 +246,10 @@ Raise '' when an exception is read from 
PORT."
   (match (read port)
 (('values objects ...)
  (apply values (map sexp->object objects)))
+;; Unexpectedly read EOF from the port.  This can happen for example when
+;; the underlying connection for PORT was lost with Guile-SSH.
+(? eof-object?
+   (raise (condition (
 (('exception ('arguments key objects ...)
  ('stack frames ...))
  ;; Protocol (0 1 1) and later.
diff --git a/guix/scripts/offload.scm b/guix/scripts/offload.scm
index 835078cb97..7c6d38b218 100644
--- a/guix/scripts/offload.scm
+++ b/guix/scripts/offload.scm
@@ -1,7 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014, 2015, 2016, 2017, 2018, 2019, 2020 Ludovic Courtès 

 ;;; Copyright © 2017 Ricardo Wurmus 
-;;; Copyright © 2020 Maxim Cournoyer 
+;;; Copyright © 2020, 2021 Maxim Cournoyer 
 ;;; Copyright © 2020 Julien Lepiller 
 ;;;
 ;;; This file is part of GNU Guix.
@@ -53,6 +53,7 @@
   #:use-module (ice-9 regex)
   #:use-module (ice-9 format)
   #:use-module (ice-9 binary-ports)
+  #:use-module (ice-9 threads)
   #:export (build-machine
 build-machine?
 build-machine-name
@@ -684,7 +685,7 @@ daemon is not running."
   (leave (G_ "failed to import '~a' from '~a'~%")
  item name)
 
-(define (check-machine-availability machine-file pred)
+(define (check-machines-availability machine-file pred)
   "Check that each machine matching PRED in MACHINE-FILE is usable as a build
 machine."
   (define (build-machine=? m1 m2)
@@ -696,18 +697,39 @@ machine."
   (let ((machines (filter pred
   (delete-duplicates (build-machines machine-file)
  build-machine=?
-(info (G_ "testing ~a build machines defined in '~a'...~%")
+(info (G_ "Testing ~a build machines defined in '~a'...~%")
   (length machines) machine-file)
-(let* ((names(map build-machine-name machines))
-   (sockets  (map build-machine-daemon-socket machines))
-   (sessions (map (cut open-ssh-session <> %short-timeout) machines))
-   (nodes(map remote-inferior sessions)))
-  (for-each assert-node-has-guix nodes names)
-  (for-each assert-node-repl nodes names)
-  (for-each assert-node-can-import sessions nodes names sockets)
-  (for-each assert-node-can-export sessions nodes names sockets)
-  (for-each close-inferior nodes)
-  (for-each disconnect! sessions
+(par-for-each check-machine-availability machines)))
+
+(define (check-machine-availability machine)
+  "Check whether MACHINE is available.  Exit with an error upon failure."
+  ;; Sometimes, the machine remote port may return EOF, presumably because the
+  ;; connection was lost.  Retry up to 3 times.
+  (let loop ((retries 3))
+(guard (c ((inferior-connection-lost? c)
+   (let ((retries-left (1- retries)))
+ (if (> retries-left 0)
+ 

bug#48331: [PATCH draft] build-system: emacs: Generate -pkg.el file in case it is missing

[Leo Prikler]

Am Dienstag, den 25.05.2021, 16:40 +0300 schrieb Andrew Tropin:
> ---
> Thank you for the patches, tested, works for me!  The solution is
> much more precise than mutating package-directory-list variable, good
> job.  I don't see any major problems in the implementation (but I'm
> not very fluent elisp dev and maybe missing something).
Don't worry, I can wait for a proper review by some of our experts,
since we shouldn't mess with emacs-build-system all too often anyway :P

> I drafted a simple build phase, which generates -pkg.el in case it is
> missing.
> 
> There are at least a few problems with this implementation:
> 
> 1. There is no information about package record available during
> build, which makes it hard to get package name and package
> version.  I can't use any regexp to obtain this information from name
> or elpa-name-ver, because  package name and version can have
> arbitrary form: comment-dwim-2-1.0, cyberpunk-2019-theme-20191008-
> alpha or something like that.
> 2. It's also not so easy to extract description of the package from
> somewhere, the first option is to pass package record to build phases
> somehow, another is to parse PACKAGE-NAME.el file comments section.
> 3. This one I consider as a minor flaw: there is no generic solution
> for packages built with build systems other than emacs-build-system.
3. is easy -- just have those packages call the phase through emacs-
build-system.  There already exist packages which do that, and it
should be pretty straightforward to do.

For 1. and 2. I think you're thinking a little too complicated.  We can
call Emacs at build time.  In particular, we can use all of the lisp-
mnt stuff, that I used in emacs-dpd at build time, we just need to
write the (define-package ...) form to disk.
In order to pick the right file, we can either use package-name (see
discussion below) or the name of the pkg-file without -pkg.  Come to
think about it, we might also provide #:pkg-file-name as a keyword and
only generate the package file if it's set to a value other than #f,
i.e. let the packager choose whether they want to generate a -pkg.el
file.  Something along this line is done with the build.xml of ant-
build-system.

>  So, this patch is very dirty and I publish it only for future
> reference.
> 
> The intuition says that we should split name and version in build
> phase arguments, also it seems that it will be useful to provide
> other information about package during build time for cases like this
> one.  I'll learn this area a bit more and probably will make another
> thread someday.
IIRC, there's a demand for having package-name and package-version
available during build (which might get through next core-updates or
might not -- we'll see), but I don't think we can argue for
description, especially when the Guix description might not be the
thing package.el wants here.

>  guix/build/emacs-build-system.scm | 60
> ++-
>  1 file changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/guix/build/emacs-build-system.scm
> b/guix/build/emacs-build-system.scm
> index f13162d6c4..2bb102b4be 100644
> --- a/guix/build/emacs-build-system.scm
> +++ b/guix/build/emacs-build-system.scm
> @@ -116,6 +116,63 @@ environment variable\n" source-directory))
>  (parameterize ((%emacs emacs))
>(emacs-byte-compile-directory (elpa-directory out)
> 
> +
> +(define* (add-pkg-file-if-missing #:key name outputs #:allow-other-
> keys
> +  #:rest args)
> +  "Generate simple -pkg.el in case package doesn't have it in source
> code."
> +  (define (file-contains-nul-char? file)
> +(call-with-input-file file
> +  (lambda (in)
> +(let loop ((line (read-line in 'concat)))
> +  (cond
> +   ((eof-object? line) #f)
> +   ((string-index line #\nul) #t)
> +   (else (loop (read-line in 'concat))
> +  #:binary #t))
> +
> +  (let* ((out (assoc-ref outputs "out"))
> + (el-dir (elpa-directory out))
> + (elpa-name-ver (store-directory->elpa-name-version out))
> + (el-files (remove file-contains-nul-char?
> +   (find-files (getcwd) "\\.el$")))
> + (el-names (map (lambda (x) (basename x ".el")) el-files))
> +
> + (possible-names
> +  (fold (lambda (x acc)
> +  (cons
> +   (string-append
> +(if (not (null? acc)) (string-append (first acc)
> "-") "")
> +x)
> +   acc))
> +'()
> +(string-split elpa-name-ver #\-)))
> +
> + (package-names (append-map
> + (lambda (name)
> +   (let ((m (member name el-names)))
> + (if m (list (car m)) '(
> + possible-names))
> +
> + (package-name (if (null? package-names) "" (car package-
> names)))
> + (package-version 

bug#46333: sbcl-common-lisp-jupyter does not install kernel.json

[Guillaume Le Vaillant]

Sharlatan Hellseher  skribis:

> I played with cl-jupyter:install but it heavily depends on Quicklisp
> but what basically does - generates simple JSON with CL implementation
> https://github.com/yitzchak/common-lisp-jupyter/issues/78
>
> First I tried to do the same during build phase by evaluationg
> arbitrary Lisp but could not manged it to work.
> Then after checking the kernel.json I just simply formated it with
> right %lispt-type path and copied with the same evaluation as R
> Jupyter package, but I've got some error during coping into Jupyter
> directory:
>
> --8<---cut here---start->8---
> phase `generate-kernelspec' succeeded after 0.0 seconds
> starting phase `install-kernelspec'
> command "jupyter" "kernelspec" "install" "--name" "cl-jupyter"
> "--prefix" 
> "/gnu/store/xjqxskiqjlzirlg478gnlp7x6w2jcz63-sbcl-common-lisp-jupyter-0.1.0-4.ba9f0e7"
> "/gnu/store/xjqxskiqjlzirlg478gnlp7x6w2jcz63-sbcl-common-lisp-jupyter-0.1.0-4.ba9f0e7/share/cl-jupyter/kernelspec"
> failed with status 127
> builder for 
> `/gnu/store/azl65q1bl2pv920fmgw6d8k0brsx6hdg-sbcl-common-lisp-jupyter-0.1.0-4.ba9f0e7.drv'
> failed with exit code 1
> build of 
> /gnu/store/azl65q1bl2pv920fmgw6d8k0brsx6hdg-sbcl-common-lisp-jupyter-0.1.0-4.ba9f0e7.drv
> failed
> [...]
> --8<---cut here---end--->8---

I think this error comes from the fact that the jupyter package is
missing as native input, therefore the 'jupyter ...' command can't work.

It lools like the 'install-kernelspec' phase just copies the kernel you
generated in "share/cl-jupyter/kernelspec/" to
"share/jupyter/kernels/cl-jupyter/". Wouldn't it be easier to generate
the kernel in the final directory directly? Then the
'install-kernelspec' phase would not be necessary.


signature.asc
Description: PGP signature

bug#48331: [PATCH draft] build-system: emacs: Generate -pkg.el file in case it is missing

[Andrew Tropin]

---
 Thank you for the patches, tested, works for me!  The solution is much more
 precise than mutating package-directory-list variable, good job.  I don't see
 any major problems in the implementation (but I'm not very fluent elisp dev
 and maybe missing something).


 I drafted a simple build phase, which generates -pkg.el in case it is missing.

 There are at least a few problems with this implementation:

 1. There is no information about package record available during build, which
 makes it hard to get package name and package version.  I can't use any
 regexp to obtain this information from name or elpa-name-ver, because
 package name and version can have arbitrary form: comment-dwim-2-1.0,
 cyberpunk-2019-theme-20191008-alpha or something like that.
 2. It's also not so easy to extract description of the package from
 somewhere, the first option is to pass package record to build phases somehow,
 another is to parse PACKAGE-NAME.el file comments section.
 3. This one I consider as a minor flaw: there is no generic solution for
 packages built with build systems other than emacs-build-system.

 So, this patch is very dirty and I publish it only for future reference.

 The intuition says that we should split name and version in build phase
 arguments, also it seems that it will be useful to provide other information
 about package during build time for cases like this one.  I'll learn this
 area a bit more and probably will make another thread someday.

 guix/build/emacs-build-system.scm | 60 ++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/guix/build/emacs-build-system.scm
b/guix/build/emacs-build-system.scm
index f13162d6c4..2bb102b4be 100644
--- a/guix/build/emacs-build-system.scm
+++ b/guix/build/emacs-build-system.scm
@@ -116,6 +116,63 @@ environment variable\n" source-directory))
 (parameterize ((%emacs emacs))
   (emacs-byte-compile-directory (elpa-directory out)

+
+(define* (add-pkg-file-if-missing #:key name outputs #:allow-other-keys
+  #:rest args)
+  "Generate simple -pkg.el in case package doesn't have it in source code."
+  (define (file-contains-nul-char? file)
+(call-with-input-file file
+  (lambda (in)
+(let loop ((line (read-line in 'concat)))
+  (cond
+   ((eof-object? line) #f)
+   ((string-index line #\nul) #t)
+   (else (loop (read-line in 'concat))
+  #:binary #t))
+
+  (let* ((out (assoc-ref outputs "out"))
+ (el-dir (elpa-directory out))
+ (elpa-name-ver (store-directory->elpa-name-version out))
+ (el-files (remove file-contains-nul-char?
+   (find-files (getcwd) "\\.el$")))
+ (el-names (map (lambda (x) (basename x ".el")) el-files))
+
+ (possible-names
+  (fold (lambda (x acc)
+  (cons
+   (string-append
+(if (not (null? acc)) (string-append (first acc) "-") "")
+x)
+   acc))
+'()
+(string-split elpa-name-ver #\-)))
+
+ (package-names (append-map
+ (lambda (name)
+   (let ((m (member name el-names)))
+ (if m (list (car m)) '(
+ possible-names))
+
+ (package-name (if (null? package-names) "" (car package-names)))
+ (package-version (string-drop elpa-name-ver
+   (1+ (string-length package-name
+ (package-description "description should be here")
+ (pkg-file (string-append el-dir "/" package-name "-pkg.el")))
+
+(when (not (file-exists? pkg-file))
+  (with-output-to-file pkg-file
+(lambda ()
+  (format
+   #t
+   "\
+(define-package
+  ~s
+  ~s
+  ~s
+  nil)"
+   package-name package-version package-description
+#t))
+
 (define* (patch-el-files #:key outputs #:allow-other-keys)
   "Substitute the absolute \"/bin/\" directory with the right location in the
 store in '.el' files."
@@ -293,8 +350,9 @@ for libraries following the ELPA convention."
 (add-after 'make-autoloads 'enable-autoloads-compilation
   enable-autoloads-compilation)
 (add-after 'enable-autoloads-compilation 'patch-el-files patch-el-files)
+(add-after 'patch-el-files 'add-pkg-file-if-missing
add-pkg-file-if-missing)
 ;; The .el files are byte compiled directly in the store.
-(add-after 'patch-el-files 'build build)
+(add-after 'add-pkg-file-if-missing 'build build)
 (add-after 'build 'validate-compiled-autoloads validate-compiled-autoloads)
 (add-after 'validate-compiled-autoloads 'move-doc move-doc)))

-- 
2.31.1

bug#48649: Guix doesn't boot with LUKS root partition

[Juraj Hlista]

I installed Guix again, there is just single 2TB encrypted partition with ext4 
on top.

When booting, there is a prompt asking for a password to decrypt the partition, 
then there is the boot menu. When hitting enter the laptop gets stuck again 
just like before.

Seems like an issue with grub?


‐‐‐ Original Message ‐‐‐
On Tuesday, May 25, 2021 1:19 PM, Tobias Geerinckx-Rice  wrote:

> Juraj,
>
> Juraj Hlista 写道：
>
> > mount LABEL=system-root /mnt
> > mkdir /mnt/etc /mnt/boot
> > mount LABEL=system-boot /mnt/boot
>
> Guix System doesn't support a separate /boot partition. 
> Seehttp://issues.guix.gnu.org/48172.
>
> I'll leave this bug unmerged with that one until we're sure that's your only 
> issue:
>
> > I also tried to use unencrypted root partition (basically the > same as 
> > above, but without LUKS) and it works.
>
> Also with separate /boot? If so, maybe GRUB happens to look in the wrong 
> right place (/ instead of /boot), or something else is going on.
>
> Kind regards,
>
> T G-R

bug#47823: Hardenize Guix website TLS/DNS

[Julien Lepiller]

No, resolved is on the client side. This means that they managed to set up 
dnssec, but some clients who use systemd (most Linux users) can't connect to 
gnu.org domains anymore. I don't think this is acceptable :)

Le 25 mai 2021 08:51:29 GMT-04:00, bo0od  a écrit :
>Then dont use systemd to do that. There many other methods/tools to 
>achieve having it.
>
>Marius Bakke:
>> Julien Lepiller  skriver:
>> 
>>> Le 16 avril 2021 12:15:25 GMT-04:00, Leo Famulari
> a écrit :
 On Fri, Apr 16, 2021 at 11:00:05AM +, bo0od wrote:
> Scanning Guix website gave many missing security features which
 modern
> security needs them to be available:
>
> * TLS and DNS:
>
> looking at:
>
> https://www.hardenize.com/report/guix.gnu.org/1618568751
>
> https://www.ssllabs.com/ssltest/analyze.html?d=guix.gnu.org

 Thanks!

> - DNS: DNSSEC support missing (important)

 Hm, is it important? My impression is that it's an idea whose time
>has
 passed without significant adoption.

 But maybe we could enable it if the costs are not too great.
>>>
>>> gnu.org does not have dnssec, so we'd need them to work on that
>first.
>> 
>> gnu.org used to have DNSSEC, but disabled it because it gave NXDOMAIN
>> on machines with systemd-resolved:
>> 
>>https://github.com/systemd/systemd/issues/9867
>> 

bug#47823: Hardenize Guix website TLS/DNS

[bo0od]

Then dont use systemd to do that. There many other methods/tools to 
achieve having it.


Marius Bakke:

Julien Lepiller  skriver:


Le 16 avril 2021 12:15:25 GMT-04:00, Leo Famulari  a écrit :

On Fri, Apr 16, 2021 at 11:00:05AM +, bo0od wrote:

Scanning Guix website gave many missing security features which

modern

security needs them to be available:

* TLS and DNS:

looking at:

https://www.hardenize.com/report/guix.gnu.org/1618568751

https://www.ssllabs.com/ssltest/analyze.html?d=guix.gnu.org


Thanks!


- DNS: DNSSEC support missing (important)


Hm, is it important? My impression is that it's an idea whose time has
passed without significant adoption.

But maybe we could enable it if the costs are not too great.


gnu.org does not have dnssec, so we'd need them to work on that first.


gnu.org used to have DNSSEC, but disabled it because it gave NXDOMAIN
on machines with systemd-resolved:

   https://github.com/systemd/systemd/issues/9867

bug#48649: Guix doesn't boot with LUKS root partition

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

Juraj,

Juraj Hlista 写道：

mount LABEL=system-root /mnt
mkdir /mnt/etc /mnt/boot
mount LABEL=system-boot /mnt/boot


Guix System doesn't support a separate /boot partition.  See 
.


I'll leave this bug unmerged with that one until we're sure that's 
your only issue:


I also tried to use unencrypted root partition (basically the 
same as above, but without LUKS) and it works.


Also with separate /boot?  If so, maybe GRUB happens to look in 
the wrong right place (/ instead of /boot), or something else is 
going on.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#48588: infamous-plugins build fails with invalid conversion from ‘void*

[Efraim Flashner]

Thanks. Fixed with 03eb0b1be2cfedd0d9a66fef0edc53a17f7653a5.

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