bug#45351: Wrong URL in guix import crate --help

2020-12-21 Thread Nathan Dehnel
guix import crate --help mentions crate.io, whereas it should be crates.io.





bug#45352: Same derivation listed twice in the output of "guix build --dry-run"

2020-12-21 Thread Mark H Weaver
I've just observed that the output of "guix build -n " may
contain duplicates, as witnessed by the following shell transcript in
which "/gnu/store/c4wgkfsc209g954c56jdzy4wmn42688f-git-2.29.2.drv"
occurs twice in the list of derivations that would be built.

(This is my crude method of seeing how much remains to be built, as my
local build of the 'ungrafting' branch is currently in progress).

   Mark


--8<---cut here---start->8---
mhw@jojen ~$ guix build -n $(readlink 
.guix-gcroots/UNGRAFTING-profile-in-progress.drv)
The following derivations would be built:
   /gnu/store/93g8fcbj94r7j1ppllb6hwb00735nnpr-profile.drv
   /gnu/store/0fwhngq74psica4xsw75bm02zr544crn-youtube-dl-2020.12.12.drv
   /gnu/store/1k038cx4f5czv0m3mx5svb2hibgqj5g6-xrandr-1.5.1.drv
   /gnu/store/2ssbhgcjlqcm44gricgbsq81728a3shv-emacs-magit-2.90.1-6.7f486d4.drv
   /gnu/store/c4wgkfsc209g954c56jdzy4wmn42688f-git-2.29.2.drv
   /gnu/store/zi7nvwndscq24x9b166d1g1v65l61yaa-subversion-1.14.0.drv
   /gnu/store/4l137g01xh3isn3ipm3hd0q4xdqxz4d6-mpv-0.33.0.drv
   /gnu/store/xk5b34867smr6yrlmyvdnw4ckvyw5b4n-vulkan-loader-1.2.148.drv
   /gnu/store/6gg2d0macbffqmmqbsxzqi1szq960b9w-gst-plugins-good-1.18.1.drv
   /gnu/store/6j5pmphv2wmb8hyib8hy5f4sg8xwr175-taglib-1.12-beta-1.drv
   /gnu/store/wc36xcakbgdbnd8qp52vwvjl7rlp3xb3-v4l-utils-1.16.6.drv
   /gnu/store/6k5agc0jgh26br10kwgnxgk4vhsnmk69-zathura-0.4.7.drv
   /gnu/store/8069zdj7i5ks6n6al8lawqmiqq25xqs8-wterm-0.7.drv
   /gnu/store/9hx39bgcb3b68i7kgkafh6camaxlpq6b-vorbis-tools-1.4.0.drv
   /gnu/store/c4wgkfsc209g954c56jdzy4wmn42688f-git-2.29.2.drv
   /gnu/store/dl1gyl03406k71w7r4789d6bfc4f7q48-wget-1.20.3.drv
   /gnu/store/fb0a8nkch1jl16vkplflcxklmwhms9sk-xsetroot-1.1.2.drv
   /gnu/store/kfnwnp04jl2pmnq09n4anqsyyd7xn38h-transmission-3.00.drv
   /gnu/store/mylly55ijs2jxmqzp6p0ys7vdvljs5kf-units-2.21.drv
   /gnu/store/nc5wjsyg18p7f89fjmf22k6l1z5f4kh3-zathura-ps-0.2.6.drv
   /gnu/store/p8aw5qzaknga762fbjkrpic45i2qnv1j-openssh-8.4p1.drv
   /gnu/store/ha891q25qbksm2rgc6m152bn43nxbcp1-xauth-1.1.drv
   /gnu/store/q7c92xp3n7px3wc5f8yh72nhg10f2mfp-notmuch-0.31.2.drv
   /gnu/store/2nq0a627cd0ygjpsjgiahvch081wasxw-talloc-2.3.1.drv
   /gnu/store/rmymfld6k1yagq80s3bjm0znmsc9kgzw-gajim-1.1.3.drv
   /gnu/store/lsgfqqkfj4z1zbg99ym53zp6p32p3f2h-enchant-2.2.13.drv
   /gnu/store/7lmwh5v3ld0nc3f37hcnmfnyh6h88xnm-unittest-cpp-2.0.0.drv
   /gnu/store/lzs3wmj2zis78c83v33qijidk4fahgnp-gtkspell3-3.0.10.drv
   /gnu/store/qsbv0r11mq47badlqj322b0a5xiwpr74-gnome-keyring-3.34.0.drv
   /gnu/store/sp8wiazpdbqnyjf9vdg8m4qpi7i1nga7-i3-wm-4.18.3.drv
   /gnu/store/79lc6kwvimpbyya8vgff3hcyychc0zn3-xcb-util-cursor-0.1.3.drv
   /gnu/store/k5p8ryjddplpk7xb6g6fckvizlkw410c-xcb-util-xrm-1.3.drv
   /gnu/store/vqni7fg9i4b7vsyld9scmg4p2v19j06i-xorg-server-xwayland-1.20.10.drv
   /gnu/store/yb5x2s2iamnzabxc383y15bysirrq2hn-sway-1.5.1.drv
   /gnu/store/43q81l7bmcdzqf42fradbp17bi9anrdq-xcb-util-errors-1.0-1.5d660eb.drv
   /gnu/store/5w45zfs3c6mwhraqcwd39z7cykh8jy7d-swaybg-1.0.drv
   /gnu/store/w0sa0lk2n7cpcl337mpw8sb5bz5jxhai-wlroots-0.12.0.drv
   /gnu/store/yb735cgrb617nqy4jfzgbza768i3f6sg-zathura-pdf-mupdf-0.3.6.drv
   /gnu/store/zrs5sz0ncrmkg8vz5rqdm3z2vi6a73bw-termite-15.drv
   /gnu/store/6m53dhbc7qgmhlsj510zi1f4zaswdxby-vte-ng-0.58.2.a.drv
The following profile hooks would be built:
   /gnu/store/49hbif4dmfyqrni1a5qn6fjkvpvwhx05-xdg-mime-database.drv
   /gnu/store/fp3m217x5y3s8gba84ckalzjwlzfiypy-ca-certificate-bundle.drv
   /gnu/store/havqnghqv9qvggxbc6gs1kapnpn7a3bq-info-dir.drv
   /gnu/store/jhd48khzr3sdnqs0pyass84izvz02hsv-gtk-im-modules.drv
   /gnu/store/kh0qfgpc24708nvc0aixjl2wyxf4yfnl-xdg-desktop-database.drv
   /gnu/store/l33bg9yk2cmq9dg1fb0zgm6h8i0mr6gy-gtk-icon-themes.drv
   /gnu/store/lrj7km148nxvwdka2mx0zx6940a1q01n-glib-schemas.drv
   /gnu/store/sc9w9vc6445zvzfv4prshl5wfpld23hw-manual-database.drv
   /gnu/store/zbdrg5g7q1kf569q682ky36s97jsikdv-fonts-dir.drv
mhw@jojen ~$ readlink .guix-gcroots/UNGRAFTING-profile-in-progress.drv
/gnu/store/93g8fcbj94r7j1ppllb6hwb00735nnpr-profile.drv
mhw@jojen ~$ cat $(readlink .guix-gcroots/UNGRAFTING-profile-in-progress.drv); 
echo
Derive([("out","/gnu/store/fr53fs3z282s74ypzsayhjm15jam4yc5-profile","","")],[("/gnu/store/01y92lavcgi61izrqk7br75gdadw3pjq-libxrandr-1.5.2.drv",["out"]),("/gnu/store/03i3ihf9mjzc79fyrz52jk69dk45nf7s-emacs-async-1.9.4.drv",["out"]),("/gnu/store/03xvac5bfv8ndxr4nbbryxp4n2wyy7ki-st-0.8.4.drv",["out"]),("/gnu/store/05il7cciqsdcvnh6bf5s5zv5igsc10iw-wayland-1.18.0.drv",["out"]),("/gnu/store/0fwhngq74psica4xsw75bm02zr544crn-youtube-dl-2020.12.12.drv",["out"]),("/gnu/store/0gjxz9z3ixdl0fkajb2n79syn2y9hh3b-icu4c-66.1.drv",["out"]),("/gnu/store/0h1hd3zfm5r416qd4vmdac6ph5dhjm9j-ratpoison-1.4.9.drv",["out"]),("/gnu/store/0ir4a2zwm8sx5l9il8nkw1bl47jcj4wr-man-pages-5.09.drv",["out"]),("/gnu/store/0n23mvbqgk5h3g88z4vw5wznxkxzm54q-libvdpau-1.4.drv",["out"]),("/gnu/store/0p65rvwavp7w1358j72yb4w3pccp2kp6-libxdamage-1.1.5.drv",["out"]),("/gnu/stor

bug#45326: Include curl/wget (and git?) to the installation image

2020-12-21 Thread zimoun
Hi Pierre,

On Sat, 19 Dec 2020 at 21:57, Pierre Neidhardt  wrote:

> Additionally, including git (maybe git minimal?) would be great so
> synchronize Git repositories which may contain installation scripts,
> Guix configs and other dotfiles.

Somehow, it is already the case. :-)  What do you need exactly?  Because
this minimal thing could be exposed via “guix git ” via Guile-Git.
WDYT?


All the best,
simon





bug#45326: Include curl/wget (and git?) to the installation image

2020-12-21 Thread Pierre Neidhardt
zimoun  writes:

> Somehow, it is already the case. :-)  What do you need exactly?  Because
> this minimal thing could be exposed via “guix git ” via Guile-Git.
> WDYT?

`guix git' only has the `authenticate' action.  Would be great if we
could have `clone'! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature


bug#45326: Include curl/wget (and git?) to the installation image

2020-12-21 Thread zimoun
Hi,

On Mon, 21 Dec 2020 at 11:14, Pierre Neidhardt  wrote:
> zimoun  writes:
>
>> Somehow, it is already the case. :-)  What do you need exactly?  Because
>> this minimal thing could be exposed via “guix git ” via Guile-Git.
>> WDYT?

> `guix git' only has the `authenticate' action.

Yeah for now… :-D


> Would be great if we
> could have `clone'! :)

Does something as “guix git clone https://example.com --output=foo” make
sense?

Cheers,
simon





bug#45326: Include curl/wget (and git?) to the installation image

2020-12-21 Thread Pierre Neidhardt
zimoun  writes:

> Does something as “guix git clone https://example.com --output=foo” make
> sense?

For me, yes! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature


bug#37737: Documentation should mention that source checkout must be readable by the guixbuild group if guix-daemon is run from there

2020-12-21 Thread zimoun
Hi,

Sorry for the long delay.

On Sun, 13 Oct 2019 at 15:54, David Truby  wrote:

> When following the Contributing section of the manual in my home
> directory, I was unable to use the built guix to do anything as I hit
> upon a message saying "error: failed to run download program
> '/home/truby/src/guix/scripts/guix': Permission denied​"
>
> After some debugging I realised this was because my home directory was
> not world readable. I think to avoid other people having this problem
> it might be worth mentioning in the manual that the source directory
> needs to be readable by the guixbuild group for the users in that
> group to be able to actually build anything. (In hindsight, this seems
> obvious to me. But it wasn't when I first ran through that section of
> the manual!)

Since it appears to me obvious, I am not sure to see how to improve.
Because you ran into the problem, do you want to give a try in rewording
somewhere in the manual?


All the best,
simon





bug#37583: Documentation needed: pam-services in operating-system structure

2020-12-21 Thread zimoun
Hi,

Sorry for the long delay.

On Wed, 02 Oct 2019 at 07:46, Jesse Gibbons  wrote:
> The manual has no documentation about how to use pam-services in the
> operating-system configuration. Information about how to use the pam-service 
> data structure and an example of how to use it would be helpful to
> administrators who need to use non-default settings, and will help us squash
> the bugs we find in the future related to how guix implements pam.

There is the subsection «PAM Mount Service» [1] in the manual.  Is it
not enough?  If enough, feel free to close this bug report.

If not enough, do you want to give a try?  Or could you describe what
you are expecting?


All the best,
simon


1: 





bug#37523: Print hint if build fails due to invalid character in package source base name

2020-12-21 Thread zimoun
Hi,

On Thu, 26 Sep 2019 at 18:01, Hartmut Goebel  
wrote:

> guix shall print a hint if building fails due to the package source base
> name containing a character invalid in a store filename (e.g. "@" or "%").
>
> Currently, when building such a package, one gets an error message like:
>
> guix build: error: invalid character `@' in name 
> `kde-l10n...@valencia-14.11.80.tar.xz.drv'
>
>
> guix build should catch this error and print a hint like:
>
> You may add a ‘file-name’ field to the package source to work around
> this.
>
>
> Ludovic Courtès wrote on Sun Sep 08 22:07:10+0200 2019
>
>> Unfortunately it cannot really be caught. I mean, you could catch
>> ‘&store-protocol-error’ error conditions, but then the error message is
>> just a string, there’s no error code you can compare against.

If I read correctly, the error is raised by nix/libstore/store-api.cc:

--8<---cut here---start->8---
void checkStoreName(const string & name)
{
string validChars = "+-._?=";
/* Disallow names starting with a dot for possible security
   reasons (e.g., "." and ".."). */
if (string(name, 0, 1) == ".")
throw Error(format("invalid name: `%1%'") % name);
foreach (string::const_iterator, i, name)
if (!((*i >= 'A' && *i <= 'Z') ||
  (*i >= 'a' && *i <= 'z') ||
  (*i >= '0' && *i <= '9') ||
  validChars.find(*i) != string::npos))
{
throw Error(format("invalid character `%1%' in name `%2%'")
% *i % name);
}
}
--8<---cut here---end--->8---

Therefore, I am missing if this message “invalid character” should be
improved or if the check of the name should be done before on the Scheme
side.  Well, I am missing what could be the path to improve the
situation, if it needs.


All the best,
simon






bug#37005: Add ability of modifying connection before full installation

2020-12-21 Thread zimoun
Hi,

Sorry for the long delay.


On Sun, 11 Aug 2019 at 06:31, bo0od  wrote:

> Im trying to install Guix over Qubes and to do so it needs manually
> adding of IP,DNS,Gateway (because its installed over xen virtualization)
>
> But im always facing the issue of not connection failed and reback to
> the older step and then again and again with no success to bypass this
> step.

I think this is fixed in the installer at least v1.2.  Could you
confirm?


All the best,
simon





bug#45300: [PATCH] Add option --with-patch

2020-12-21 Thread Ludovic Courtès
Hi Philippe,

Philippe SWARTVAGHER  skribis:

> We already have `--with-branch=`, `with-commit=`, ... An additional
> option could be `--with-patch=package=add-extra-feature.patch` which
> would apply the patch file `add-extra-feature.patch` located in the my
> current directory to the sources of `package` before Guix starts
> building `package`.

Good idea!  The patch below does that.

Feedback welcome.  :-)

Ludo’.

>From 12c8df7c61537e3834fac4bf0e8e340cbac2d2df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Mon, 21 Dec 2020 14:52:38 +0100
Subject: [PATCH] transformations: Add '--with-patch'.

Suggested by Philippe Swartvagher .

* guix/transformations.scm (transform-package-patches): New procedure.
(%transformations): Add it as 'with-patch'.
(%transformation-options, show-transformation-options-help/detailed):
Add '--with-patch'.
* tests/transformations.scm ("options->transformation, with-patch"): New
test.
* doc/guix.texi (Package Transformation Options): Document it.
---
 doc/guix.texi | 18 +++
 guix/transformations.scm  | 63 ++-
 tests/transformations.scm | 24 +++
 3 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 392baf5910..c172a898cd 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -10357,6 +10357,24 @@ This is similar to @option{--with-branch}, except that it builds from
 @var{commit} rather than the tip of a branch.  @var{commit} must be a valid
 Git commit SHA1 identifier or a tag.
 
+@item --with-patch=@var{package}=@var{file}
+Add @var{file} to the list of patches applied to @var{package}, where
+@var{package} is a spec such as @code{python@@3.8} or @code{glibc}.
+@var{file} must contain a patch; it is applied with the flags specified
+in the @code{origin} of @var{package} (@pxref{origin Reference}), which
+by default includes @code{-p1} (@pxref{patch Directories,,, diffutils,
+Comparing and Merging Files}).
+
+As an example, the command below rebuilds Coreutils with the GNU C
+Library (glibc) patched with the given patch:
+
+@example
+guix build coreutils --with-patch=glibc=./glibc-frob.patch
+@end example
+
+In this example, glibc itself as well as everything that leads to
+Coreutils in the dependency graph is rebuilt.
+
 @cindex test suite, skipping
 @item --without-tests=@var{package}
 Build @var{package} without running its tests.  This can be useful in
diff --git a/guix/transformations.scm b/guix/transformations.scm
index d49041cf59..2385d3231e 100644
--- a/guix/transformations.scm
+++ b/guix/transformations.scm
@@ -41,6 +41,7 @@
   #:use-module (srfi srfi-34)
   #:use-module (srfi srfi-37)
   #:use-module (ice-9 match)
+  #:use-module (ice-9 vlist)
   #:export (options->transformation
 manifest-entry-with-transformations
 
@@ -456,6 +457,60 @@ to the same package but with #:strip-binaries? #f in its 'arguments' field."
 (rewrite obj)
 obj)))
 
+(define (transform-package-patches specs)
+  "Return a procedure that, when passed a package, returns a package with
+additional patches."
+  (define (package-with-extra-patches p patches)
+(if (origin? (package-source p))
+(package/inherit p
+  (source (origin
+(inherit (package-source p))
+(patches (append (map (lambda (file)
+(local-file file))
+  patches)
+ (origin-patches (package-source p)))
+p))
+
+  (define (coalesce-alist alist)
+;; Coalesce multiple occurrences of the same key in ALIST.
+(let loop ((alist alist)
+   (keys '())
+   (mapping vlist-null))
+  (match alist
+(()
+ (map (lambda (key)
+(cons key (vhash-fold* cons '() key mapping)))
+  (delete-duplicates (reverse keys
+(((key . value) . rest)
+ (loop rest
+   (cons key keys)
+   (vhash-cons key value mapping))
+
+  (define patches
+;; Spec/patch alist.
+(coalesce-alist
+ (map (lambda (spec)
+(match (string-tokenize spec %not-equal)
+  ((spec patch)
+   (cons spec (canonicalize-path patch)))
+  (_
+   (raise (formatted-message
+   (G_ "~a: invalid package patch specification")
+   spec)
+  specs)))
+
+  (define rewrite
+(package-input-rewriting/spec
+ (map (match-lambda
+((spec . patches)
+ (cons spec (cut package-with-extra-patches <> patches
+  patches)))
+
+  (lambda (obj)
+(if (package? obj)
+(rewrite obj)
+obj)))
+
 (define %transformations
   ;; Transformations that can be applied to things to build.  The car is the
   ;; key used in the option alist, and the cdr is the transformation
@@ -469,7 +524,8 @@ 

bug#37523: Print hint if build fails due to invalid character in package source base name

2020-12-21 Thread Hartmut Goebel

Hi,,

thanks for picking this up.


Therefore, I am missing if this message “invalid character” should be
improved or if the check of the name should be done before on the Scheme
side.  Well, I am missing what could be the path to improve the
situation, if it needs.


Since this check is done also for other store-items, I assume it does 
not make much sense to change the message in the C-code.


So I assume the patch to improve this is to check the name on the Scheme 
side. (Or to make the da)emon return some meaningful error object. 
Anyhow I assume this is much more complicated and not a solution for now.


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |






bug#45272: [PATCH v3] gnu: gnome-builder: Disable jedi plugin.

2020-12-21 Thread Ludovic Courtès
Hi,

Leo Prikler  skribis:

> As pointed out in #45272, it is broken.
>
> * gnu/packages/gnome.scm (gnome-builder)[#:configure-flags] Add
> -Dplugin_jedi=false.

Perfect.  :-)

Applied, thanks!

Ludo’.





bug#31977: clone tests fail on CentOS 7

2020-12-21 Thread Paul Garlick
Hi Simon,

> If I understand well your message:
> 
> Files:
> a) '/proc/self/ns/user' exists
> b) '/proc/sys/kernel/unprivileged_userns_clone' does not exist.

Yes, this is the case on CentOS.  

So testing for the existence of the unprivileged_userns_clone file is
an insufficent test for unprivileged user namespaces.  We have learnt
that trying to create the file as a dummy file does not work, since the
/proc/sys/kernel directory is read-only even for root.

So the current 'unprivileged-user-namespace-supported?' function in
gnu/build/linux-container.scm really only works for Debian-derived
systems.  Other systems, that co not create the
unprivileged_userns_clone file, differ in their default configurations.
CentOS, for example, disables the feature.  However, Guix System
enables it.

It has been suggested that the feature itself should be tested, instead
of relying on the /proc filesystem.  This could well be a better idea
and I gather from the thread that this idea is being worked on.  I can
test on CentOS when a new patch is available.

Best regards,

Paul. 






bug#25305: bug#37851: bug#25305: bug#37851: Grub installation only checks for encrypted /boot folder

2020-12-21 Thread Miguel Ángel Arruga Vivas
Hi Ludo,

First of all, thanks for your review. :-)

Ludovic Courtès  writes:

> Hi Miguel,
>
> Miguel Ángel Arruga Vivas  skribis:
>> +  (define (crypto-devices)
>> +(define (crypto-device->cryptomount dev)
>> +  (if (uuid? dev)
>> +  #~(format port "cryptomount -u ~a~%"
>> +;; cryptomount only accepts UUID without the hypen.
>> +#$(string-delete #\- (uuid->string dev)))
>> +  ;; Other type of devices aren't implemented.
>> +  #~()))
>> +(let ((devices (map crypto-device->cryptomount store-crypto-devices))
>> +  ;; XXX: Add luks2 when grub 2.06 is packaged.
>> +  (modules #~(format port "insmod luks~%")))
>> +  (if (null? devices)
>> +  devices
>> +  (cons modules devices
>
> What I don’t get is why we’re able to use an encrypted root right now
> without emitting “cryptomount” GRUB commands?

The grub boot process goes more or less like this:

1. Firmware loads the initial image.
1.1. If that image is not the final one, it contains a "pointer" to the
 final one, which is loaded by it; this chain can be viewed as part
 of the firmware loading for this purpose.
2. The image code reads an initial configuration file, which is usually
   generated by grub-install/grub-mkstandalone.  Here Grub is placing
   the needed the cryptomount lines for the devices needed to mount
   target in order to read grub.cfg and other modules.
3. grub.cfg is read (a.k.a. normal mode) and the usual boot process
   follows.

The first configuration file is generated automatically by grub-install,
which physically scans the target location (still /boot in our case) and
inserts the needed insmod and cryptomount calls.  When the target and
the store don't share the device, the calls leading to the store must be
inserted manually into grub.cfg.

It could be easier to remove completely /boot and use a directory from
the store, but that leads to more writes of the image, as each
reconfiguration involving a change on the devices used for the store
must end up returning a different store file name too.  Nonetheless,
that would leave /boot untouched if anybody wants to install their
version of grub there for other purposes...

>> +(_
>> + ;; No crypto-devices found
>> + '(
>> + (_
>> +  ;; No store found, old format.
>> +  '(
>
> s/No store found/No crypto devices found/ ?

The first comment is reached when crypto-devices isn't found in a
(boot-parameters ... (store ...) ...) form.  The second one is reached
when (boot-parameters ...) form doesn't even contain a tag store in it.
It follows the same pattern as store-device, as the old format didn't
have a store element.

On the other hand, I added a period to the first sentence as it was
missing. 0:)

>> +(define (operating-system-bootloader-crypto-devices os)
>> +  "Return the subset of mapped devices that the bootloader must open.
>> +Only devices specified by uuid are supported."
>> +  (map mapped-device-source
>> +   (filter (match-lambda
>> + ((and (= mapped-device-type type)
>> +   (= mapped-device-source source))
>> +  (and (eq? luks-device-mapping type)
>> +   (or (uuid? source)
>> +   (begin
>> + (warning (G_ "\
>> +mapped-device '~a' won't be mounted by the bootloader.~%")
>> +  source)
>> + #f)
>> +   ;; XXX: Ordering is important, we trust the returned one.
>> +   (operating-system-boot-mapped-devices os
>
> You can use ‘filter-map’ here.

Thanks for the pointer!  I've modified a bit tests/boot-parameters.scm
to be extra-sure that I was doing that change OK, as I moved the or to a
internal function for readability too.

> The rest LGTM!  Make sure the “installed-os” and “encrypted-root-os”
> system tests are still fine, and if they are, I guess you can go ahead.

Pushed to master as f00e68ace0 with these changes, after running the
tests and booting up my system.

Happy hacking!
Miguel





bug#44872: GuixSD 1.2.0 installer fails with exception when formatting drive

2020-12-21 Thread Tim Magee via web
I previously had GNU Guix installed with an encrypted home partition but the 
main partition unencrypted.






bug#45302: Avahi substitute discovery keeps trying to ping unaccessible servers

2020-12-21 Thread Maxim Cournoyer
Hello,

Pierre Neidhardt  writes:

> I've set up my desktop and laptop to use the new substitute discovery
> feature, it's awesome!
>
> However, when I put my desktop to sleep and run a Guix command on my
> laptop that requires access to a sbustitute server, I see this:
>
> $ guix build ncdu
> substitute: guix substitute: warning: 10.0.0.5: connection failed: No route 
> to host
> substitute: updating substitutes from 'http://ci.guix.gnu.org'... 100.0%
> 0.0 MB will be downloaded:
>/gnu/store/p70r4maqgh6ghl25h5a99w7sf1jidap8-ncdu-1.15.1
> substituting /gnu/store/p70r4maqgh6ghl25h5a99w7sf1jidap8-ncdu-1.15.1...
>
>
> The warning
>
> substitute: guix substitute: warning: 10.0.0.5: connection failed: No route 
> to host
>
>
> pops up on every download, which adds some 2s delay each time.  This
> makes the whole process much slower.
>
> For your information, Avahi does not find my desktop:
>
> $ sudo avahi-browse -al
> Password: 
> + wlp2s0 IPv6 FOO___s MacBook Pro_companion-link._tcp 
> local
> + wlp2s0 IPv4 FOO___s MacBook Pro_companion-link._tcp 
> local
>   C-c C-cGot SIGINT, quitting.

This reminds me of https://issues.guix.gnu.org/30290.  Perhaps if we can
fix that one it'd make this one go away too?.  I was thinking of having
a simple mean to reduce the request attempts on servers down for a long
while, such as entering dead periods (breaks): "I've tried X times, it
doesn't respond, I give up for the next Y minutes"; allowing for X and Y
to be configured via the  record.

Do you think this would help?

Maxim