bug#54204: mumi search by date provides unexpected results

[Roman Riabenko]

This report is for the instance at issues.guix.gnu.org. The hint under
the search field and the online help documentation suggest that "date:"
filter can be used to improve the search results.[1] However, the
results are different from what is documented. For example, there is a
report submitted on 16 February 2022 and a patch submitted on 20
Fenruary 2022 both contaning the word "mumi".[2][3] I can see them at
the end of search results when searching for "mumi".[4] But I cannot
find them with any of the following:

1. mumi date:20d..now
2. mumi date:2022-02-01..2022-02-28

The first one returns older posts only.[5] The second one returns
nothing.[6]

And the last hinted filter does return links to the expected issues but
also returns other issues which are apparently out of the specified
time period and so introduces noise in the search results making
filtering less effective:[7]

3. mumi date:1m..today

---

[1] https://issues.guix.gnu.org/help#search
[2] https://issues.guix.gnu.org/54024
[3] https://issues.guix.gnu.org/54072
[4] https://issues.guix.gnu.org/search?query=mumi
[5] https://issues.guix.gnu.org/search?query=mumi+date%3A20d..now
[6]
https://issues.guix.gnu.org/search?query=mumi+date%3A2022-02-01..2022-02-28
[7] https://issues.guix.gnu.org/search?query=mumi+date%3A1m..today

---

Roman

bug#54202: [patch] update guile-wisp to 1.0.7

[Dr. Arne Babenhauserheide]

Hi,

The attached patch updates guile-wisp to version 1.0.7.

Best wishes,
Arne
From 76660ab479e952d88876acaa2591bc4315c41cc7 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide 
Date: Wed, 29 Dec 2021 23:10:31 +0100
Subject: [PATCH] gnu: guile-wisp: Update to 1.0.7.

* gnu/packages/guile-xyz.scm (guile-wisp): Update to 1.0.7.
---
 gnu/packages/guile-xyz.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index b75687cd3c..63fbf3c89f 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -1819,7 +1819,7 @@ (define-public guile-imanifest
 (define-public guile-wisp
   (package
 (name "guile-wisp")
-(version "1.0.6")
+(version "1.0.7")
 (source (origin
   (method hg-fetch)
   (uri (hg-reference
@@ -1828,7 +1828,7 @@ (define-public guile-wisp
   (file-name (git-file-name name version))
   (sha256
(base32
-"0df0vch2p6qymz3f96clrkl2gphjk6x7fbya236yzxc07hkz2j3g"
+"0fxngiy8dmryh3gx4g1q7nnamc4dpszjh130g6d0pmi12ycxd2y9"
 (build-system gnu-build-system)
 (arguments
  `(#:modules ((guix build gnu-build-system)
-- 
2.34.0



From 76660ab479e952d88876acaa2591bc4315c41cc7 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide 
Date: Wed, 29 Dec 2021 23:10:31 +0100
Subject: [PATCH] gnu: guile-wisp: Update to 1.0.7.

* gnu/packages/guile-xyz.scm (guile-wisp): Update to 1.0.7.
---
 gnu/packages/guile-xyz.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index b75687cd3c..63fbf3c89f 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -1819,7 +1819,7 @@ (define-public guile-imanifest
 (define-public guile-wisp
   (package
 (name "guile-wisp")
-(version "1.0.6")
+(version "1.0.7")
 (source (origin
   (method hg-fetch)
   (uri (hg-reference
@@ -1828,7 +1828,7 @@ (define-public guile-wisp
   (file-name (git-file-name name version))
   (sha256
(base32
-"0df0vch2p6qymz3f96clrkl2gphjk6x7fbya236yzxc07hkz2j3g"
+"0fxngiy8dmryh3gx4g1q7nnamc4dpszjh130g6d0pmi12ycxd2y9"
 (build-system gnu-build-system)
 (arguments
  `(#:modules ((guix build gnu-build-system)
-- 
2.34.0


-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

bug#52362: [PATCH v3] guix: import: go: Use correct tag for go module in subdirectory.

[Nicolas Goaziou]

Hello,

I tested v3 of this change, which looks great.

Unfortunately, when running

  ./pre-inst-env guix import go --recursive rclone

I get the following backtrace:

--8<---cut here---start->8---
following redirection to 
`https://github.com/qingstor/qingstor-sdk-go?go-get=1'...
Backtrace:
In ice-9/boot-9.scm:
  1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/import/go.scm:
   114:22 18 (_)
In guix/import/utils.scm:
   509:23 17 (recursive-import _ #:repo->guix-package _ #:guix-name _ …)
In srfi/srfi-1.scm:
   586:29 16 (map1 _)
   586:29 15 (map1 _)
   586:29 14 (map1 _)
   586:29 13 (map1 _)
   586:29 12 (map1 _)
   586:29 11 (map1 _)
   586:17 10 (map1 (("github.com/yunify/qingstor-sdk-go/v3" #f) (…) …))
In guix/import/utils.scm:
   497:33  9 (lookup-node "github.com/yunify/qingstor-sdk-go/v3" #f)
In guix/memoization.scm:
 98:0  8 (mproc "github.com/yunify/qingstor-sdk-go/v3" #:version …)
In unknown file:
   7 (_ # …)
   6 (_ # …)
In ice-9/boot-9.scm:
724:2  5 (call-with-prompt _ _ #)
  1752:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In ice-9/eval.scm:
   293:34  3 (_ #(#(#(#(#(#(#(#(#(#(#(#) …) …) …) …) …) …) …) …) …) …))
In unknown file:
   2 (substring "github.com/yunify/qingstor-sdk-go" 35 #)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1683:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Value out of range 0 to< 33: 35
--8<---cut here---end--->8---

Do you know why it is failing like this?

Regards,
-- 
Nicolas Goaziou

bug#40998: [PATCH 3/4] initrd: Use non-hyphenated kernel command-line parameter names.

[Maxim Cournoyer]

This is to make it less surprising, given the common convention sets forth by
the kernel Linux command-line parameters.

* gnu/build/linux-boot.scm (boot-system): Rename '--load', '--repl', '--root'
and '--system' to 'gnu.load', 'gnu.repl', 'root' and 'gnu.system',
respectively.  Adjust doc.
(find-long-option): Adjust doc.
* gnu/installer/parted.scm (installer-root-partition-path): Adjust accordingly.
* gnu/system.scm (bootable-kernel-arguments): Add a VERSION argument and
update doc.  Use VERSION to conditionally return old style vs new style initrd
arguments.
(%boot-parameters-version): Increment to 1.
(operating-system-boot-parameters): Adjust doc.
(operating-system-boot-parameters-file): Likewise.
* gnu/system/linux-initrd.scm (raw-initrd, base-initrd): Likewise.
* doc/guix.texi: Adjust doc.
* gnu/build/activation.scm (boot-time-system): Adjust accordingly.
* gnu/build/hurd-boot.scm (boot-hurd-system): Likewise.
* gnu/packages/commencement.scm (%final-inputs-riscv64): Adjust comment.
---
 doc/guix.texi | 12 -
 gnu/build/activation.scm  |  4 +--
 gnu/build/hurd-boot.scm   | 12 -
 gnu/build/linux-boot.scm  | 31 ---
 gnu/installer/parted.scm  |  2 +-
 gnu/machine/ssh.scm   |  5 ++--
 gnu/packages/commencement.scm |  4 +--
 gnu/system.scm| 47 ++-
 gnu/system/linux-initrd.scm   |  4 +--
 9 files changed, 68 insertions(+), 53 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 1e8b23ad7e..ce44eb3b47 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -34959,7 +34959,7 @@ honors several options passed on the Linux kernel 
command line
 @code{-append} option of QEMU), notably:
 
 @table @code
-@item --load=@var{boot}
+@item gnu.load=@var{boot}
 Tell the initial RAM disk to load @var{boot}, a file containing a Scheme
 program, once it has mounted the root file system.
 
@@ -34967,7 +34967,7 @@ Guix uses this option to yield control to a boot 
program that runs the
 service activation programs and then spawns the GNU@tie{}Shepherd, the
 initialization system.
 
-@item --root=@var{root}
+@item root=@var{root}
 Mount @var{root} as the root file system.  @var{root} can be a device
 name like @code{/dev/sda1}, a file system label, or a file system UUID.
 When unspecified, the device name from the root file system of the
@@ -34992,7 +34992,7 @@ or @code{preen} to repair problems considered safe to 
repair automatically.
 @code{preen} is the default if this option is not present or if @var{level}
 is not one of the above.
 
-@item --system=@var{system}
+@item gnu.system=@var{system}
 Have @file{/run/booted-system} and @file{/run/current-system} point to
 @var{system}.
 
@@ -35004,7 +35004,7 @@ Instruct the initial RAM disk as well as the 
@command{modprobe} command
 must be a comma-separated list of module names---e.g.,
 @code{usbkbd,9pnet}.
 
-@item --repl
+@item gnu.repl
 Start a read-eval-print loop (REPL) from the initial RAM disk before it
 tries to load kernel modules and to mount the root file system.  Our
 marketing team calls it @dfn{boot-to-Guile}.  The Schemer in you will
@@ -35025,7 +35025,7 @@ here is how to use it and customize it further.
[#:helper-packages '()] [#:qemu-networking? #f] [#:volatile-root? #f]
 Return a derivation that builds a raw initrd.  @var{file-systems} is
 a list of file systems to be mounted by the initrd, possibly in addition to
-the root file system specified on the kernel command line via @option{--root}.
+the root file system specified on the kernel command line via @option{root}.
 @var{linux-modules} is a list of kernel modules to be loaded at boot time.
 @var{mapped-devices} is a list of device mappings to realize before
 @var{file-systems} are mounted (@pxref{Mapped Devices}).
@@ -35055,7 +35055,7 @@ to it are lost.
 Return as a file-like object a generic initrd, with kernel
 modules taken from @var{linux}.  @var{file-systems} is a list of file-systems 
to be
 mounted by the initrd, possibly in addition to the root file system specified
-on the kernel command line via @option{--root}.  @var{mapped-devices} is a 
list of device
+on the kernel command line via @option{root}.  @var{mapped-devices} is a list 
of device
 mappings to realize before @var{file-systems} are mounted.
 
 When true, @var{keyboard-layout} is a @code{} record denoting
diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
index 9f6126023c..10c9045740 100644
--- a/gnu/build/activation.scm
+++ b/gnu/build/activation.scm
@@ -389,8 +389,8 @@ (define %current-system
   "/run/current-system")
 
 (define (boot-time-system)
-  "Return the '--system' argument passed on the kernel command line."
-  (find-long-option "--system" (if (string-contains %host-type "linux-gnu")
+  "Return the 'gnu.system' argument passed on the kernel command line."
+  (find-long-option "gnu.system" (if (string-contains %host-type "linux-gnu")

bug#40998: [PATCH 4/4] initrd: Honor rootfstype and rootflags command-line parameters.

[Maxim Cournoyer]

* gnu/build/linux-boot.scm (boot-system): Honor rootfstype and rootflags
arguments.  Update doc.  Error out in case there is insufficient information
with regard to the root file system.
Restore the behavior of inferring the root device from the root file system
from the operating system in case the root argument is not provided.
* doc/guix.texi (Initial RAM Disk): Document the new command-line parameters.
---
 doc/guix.texi| 10 
 gnu/build/linux-boot.scm | 55 ++--
 2 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index ce44eb3b47..dc6cb9842e 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -34973,6 +34973,16 @@ name like @code{/dev/sda1}, a file system label, or a 
file system UUID.
 When unspecified, the device name from the root file system of the
 operating system declaration is used.
 
+@item rootfstype=@var{type}
+Set the type of the root file system.  It overrides the @code{type}
+field of the root file system specified via the @code{operating-system}
+declaration, if any.
+
+@item rootflags=@var{options}
+Set the mount @emph{options} of the root file system.  It overrides the
+@code{options} field of the root file system specified via the
+@code{operating-system} declaration, if any.
+
 @item fsck.mode=@var{mode}
 Whether to check the @var{root} file system for errors before mounting
 it.  @var{mode} is one of @code{skip} (never check), @code{force} (always
diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm
index cfa1ab2fcb..7d41537652 100644
--- a/gnu/build/linux-boot.scm
+++ b/gnu/build/linux-boot.scm
@@ -500,9 +500,9 @@ (define* (boot-system #:key
 KEYMAP-FILE is true), then setting up QEMU guest networking if
 QEMU-GUEST-NETWORKING? is true, calling PRE-MOUNT, mounting the file systems
 specified in MOUNTS, and finally booting into the new root if any.  The initrd
-supports kernel command-line parameters 'gnu.load' and 'gnu.repl'.  It also
+supports the kernel command-line options 'gnu.load' and 'gnu.repl'.  It also
 honors a subset of the Linux kernel command-line parameters such as
-'fsck.mode', 'resume', 'root' and 'rootdelay'.
+'fsck.mode', 'resume', 'rootdelay', rootflags and rootfstype.
 
 Mount the root file system, specified by the 'root' command-line argument, if
 any.
@@ -538,13 +538,30 @@ (define (device-string->file-system-device device-string)
  ;; over the ‘device’ field of the root  record.
  (root-device (and=> (find-long-option "root" args)
  device-string->file-system-device))
- (root-fs (or (find root-mount-point? mounts)
-  ;; Fall back to fictitious defaults.
-  (file-system (device (or root-device "/dev/root"))
-   (mount-point "/")
-   (type "ext4"
+ (rootfstype  (find-long-option "rootfstype" args))
+ (rootflags   (find-long-option "rootflags" args))
+ (root-fs*(find root-mount-point? mounts))
  (fsck.mode (find-long-option "fsck.mode" args)))
 
+(unless (or root-fs* (and root-device rootfstype))
+  (error "no root file system or 'root' and 'rootfstype' parameters"))
+
+;; If present, ‘root’ on the kernel command line takes precedence over
+;; the ‘device’ field of the root  record; likewise for
+;; the 'rootfstype' and 'rootflags' arguments.
+(define root-fs
+  (if root-fs*
+  (file-system
+(inherit root-fs*)
+(device (or root-device (file-system-device root-fs*)))
+(type (or rootfstype (file-system-type root-fs*)))
+(options (or rootflags (file-system-options root-fs*
+  (file-system
+(device root-device)
+(mount-point "/")
+(type rootfstype)
+(options rootflags
+
 (define (check? fs)
   (match fsck.mode
 ("skip"  #f)
@@ -616,18 +633,18 @@ (define (repair fs)
 
 (setenv "EXT2FS_NO_MTAB_OK" "1")
 
-(if root-device
-(mount-root-file-system (canonicalize-device-spec root-device)
-(file-system-type root-fs)
-#:volatile-root? volatile-root?
-#:flags (mount-flags->bit-mask
- (file-system-flags root-fs))
-#:options (file-system-options root-fs)
-#:check? (check? root-fs)
-#:skip-check-if-clean?
-(skip-check-if-clean? root-fs)
-#:repair (repair root-fs))
-(mount "none" "/root" "tmpfs"))
+;; Mount the root file 

bug#40998: [PATCH 2/4] system: Streamline operating-system-boot-parameters-file a bit.

[Maxim Cournoyer]

* gnu/system.scm (operating-system-boot-parameters-file)
[SYSTEM-KERNEL-ARGUMENTS?]: Remove unused argument (it had no callers) and
adjust doc, moving the self-referential tip to...
* gnu/system.scm (operating-system-boot-parameters): ... here, reworded for
clarity.

Suggested-by: Ludovic Courtès 
---
 gnu/system.scm | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index 9ae158dea6..c6c46343cc 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -1453,7 +1453,10 @@ (define* (operating-system-boot-parameters os root-device
#:key system-kernel-arguments?)
   "Return a monadic  record that describes the boot
 parameters of OS.  When SYSTEM-KERNEL-ARGUMENTS? is true, add kernel arguments
-such as '--root' and '--load' to ."
+such as '--root' and '--load' to .  The
+SYSTEM-KERNEL-ARGUMENTS? should only be used in necessity, as the '--load' and
+'--system' values are self-referential (they refer to the system), thus
+susceptible to introduce a cyclic dependency."
   (let* ((initrd  (and (not (operating-system-hurd os))
(operating-system-initrd-file os)))
  (store   (operating-system-store-file-system os))
@@ -1494,22 +1497,13 @@ (define (device->sexp device)
 (_
  device)))
 
-(define* (operating-system-boot-parameters-file os
-#:key system-kernel-arguments?)
-   "Return a file that describes the boot parameters of OS.  The primary use of
-this file is the reconstruction of GRUB menu entries for old configurations.
-
-When SYSTEM-KERNEL-ARGUMENTS? is true, add kernel arguments such as '--root'
-and '--load' to the returned file (since the returned file is then usually
-stored into the content-addressed \"system\" directory, it's usually not a
-good idea to give it because the content hash would change by the content hash
-being stored into the \"parameters\" file)."
+(define* (operating-system-boot-parameters-file os)
+   "Return a file that describes the boot parameters of OS.  The primary use
+of this file is the reconstruction of GRUB menu entries for old
+configurations."
(let* ((root   (operating-system-root-file-system os))
   (device (file-system-device root))
-  (params (operating-system-boot-parameters
-   os device
-   #:system-kernel-arguments?
-   system-kernel-arguments?)))
+  (params (operating-system-boot-parameters os device)))
  (scheme-file "parameters"
   #~(boot-parameters
  (version #$(boot-parameters-version params))
-- 
2.34.0

bug#40998: [PATCH 1/4] system: Add a version field to the record.

[Maxim Cournoyer]

This version field exposes the (already present) version information of a boot
parameters file.

* gnu/system.scm (%boot-parameters-version): New variable.
()[version]: New field.
(read-boot-parameters): Use it.
(operating-system-boot-parameters-file): Likewise.
* tests/boot-parameters.scm (test-read-boot-parameters): Use
%boot-parameters-version as the default version value in the template.
---
 gnu/system.scm| 20 
 tests/boot-parameters.scm |  2 +-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index cc925de16f..9ae158dea6 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -9,7 +9,7 @@
 ;;; Copyright © 2020 Danny Milosavljevic 
 ;;; Copyright © 2020, 2021 Brice Waegeneire 
 ;;; Copyright © 2020 Florian Pelz 
-;;; Copyright © 2020 Maxim Cournoyer 
+;;; Copyright © 2020, 2022 Maxim Cournoyer 
 ;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
 ;;; Copyright © 2020 Efraim Flashner 
 ;;; Copyright © 2021 Maxime Devos 
@@ -161,6 +161,8 @@ (define-module (gnu system)
 boot-parameters-kernel-arguments
 boot-parameters-initrd
 boot-parameters-multiboot-modules
+boot-parameters-version
+%boot-parameters-version
 read-boot-parameters
 read-boot-parameters-file
 boot-parameters->menu-entry
@@ -295,6 +297,8 @@ (define (operating-system-kernel-arguments os root-device)
 ;;; Boot parameters
 ;;;
 
+(define %boot-parameters-version 0)
+
 (define-record-type* 
   boot-parameters make-boot-parameters boot-parameters?
   (labelboot-parameters-label)
@@ -322,7 +326,9 @@ (define-record-type* 
   (kernel   boot-parameters-kernel)
   (kernel-arguments boot-parameters-kernel-arguments)
   (initrd   boot-parameters-initrd)
-  (multiboot-modules boot-parameters-multiboot-modules))
+  (multiboot-modules boot-parameters-multiboot-modules)
+  (version  boot-parameters-version  ;positive integer
+(default %boot-parameters-version)))
 
 (define (ensure-not-/dev device)
   "If DEVICE starts with a slash, return #f.  This is meant to filter out
@@ -359,12 +365,18 @@ (define uuid-sexp->uuid
(warning (G_ "unrecognized uuid ~a at '~a'~%") x (port-filename port))
#f)))
 
+  ;; New versions are not backward-compatible, so only accept past and current
+  ;; versions, not future ones.
+  (define (version? n)
+(member n (iota (1+ %boot-parameters-version
+
   (match (read port)
-(('boot-parameters ('version 0)
+(('boot-parameters ('version (? version? version))
('label label) ('root-device root)
('kernel kernel)
rest ...)
  (boot-parameters
+  (version version)
   (label label)
   (root-device (device-sexp->device root))
 
@@ -1500,7 +1512,7 @@ (define* (operating-system-boot-parameters-file os
system-kernel-arguments?)))
  (scheme-file "parameters"
   #~(boot-parameters
- (version 0)
+ (version #$(boot-parameters-version params))
  (label #$(boot-parameters-label params))
  (root-device
   #$(device->sexp
diff --git a/tests/boot-parameters.scm b/tests/boot-parameters.scm
index b2799d0596..d4b680df2e 100644
--- a/tests/boot-parameters.scm
+++ b/tests/boot-parameters.scm
@@ -101,7 +101,7 @@ (define (quote-uuid uuid)
 ;; Call read-boot-parameters with the desired string as input.
 (define* (test-read-boot-parameters
   #:key
-  (version 0)
+  (version %boot-parameters-version)
   (bootloader-name 'grub)
   (bootloader-menu-entries '())
   (label %default-label)
-- 
2.34.0

bug#40998: Guix System's initrd doesn't honor rootflags

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>> There’s no need to have a ‘version’ field in live 
>>> records: have the ‘version’ field in the serialized format (the sexp)
>>> and make sure the deserializer correctly converts to the internal
>>> representation.
>>>
>>> Here, I think you can bump the version number in the serialized form,
>>> and have ‘read-boot-parameters’ automatically augment ‘kernel-arguments’
>>> when VERSION is 0 with “--root=XYZ”.
>>
>> I initially went that route, as this was the idea you'd given me
>> initially.  However, 'read-boot-parameters' deals with serializing the
>> parameters file only; to add 'root', 'gnu.load' and 'gnu.system', the
>> operating-system object as well as the root device are needed.
>
>  already has ‘root-device’, so that’s fine.
>
> But you’re right that the system itself is a problem because that’s
> self-referential—it’s the thing the “parameters” file is in.  Hmm!
>
> We could add a substitution mechanism where a literal “$SYSTEM” (say) in
> the ‘kernel-arguments’ of  would be substituted by the
> actual system store file name by ‘read-boot-parameters’, but maybe
> that’s overkill.
>
> So long story short: keeping the ‘version’ field in 
> sounds reasonable after all.  :-)

OK, good, thanks for having confirmed that.

>> The reason 'gnu.load' and 'gnu.system' aren't written to the
>> parameters file to start with is because they would cause the system
>> directory to no longer be content-addressable; this is explained in
>> the docstring of 'operating-system-boot-parameters-file':
>>
>> When SYSTEM-KERNEL-ARGUMENTS? is true, add kernel arguments such as 
>> 'root'
>> and 'gnu.load' to the returned file (since the returned file is then 
>> usually
>> stored into the content-addressed "system" directory, it's usually not a
>> good idea to give it because the content hash would change by the 
>> content hash
>> being stored into the "parameters" file).
>
> This comment originates in 40fad1c24ce60076e26f6dc8096e4716d31d90c3.  I
> find it a bit misleading because nothing’s “content-addressed”, but I
> guess it refers to the same problem: that this is self-referential.
>
> (There’s only one use of #:system-kernel-arguments? #t.  We can remove
> that keyword parameter from ‘operating-system-boot-parameters-file’
> since it’s not used there.)

OK, I'll address this confusing comment and extraneous argument in a
separate commit.

>>> Also, you could write the ‘match’ pattern like this:
>>>
>>>   ('boot-parameters ('version (and version (or 0 1)))
>>> ('label label) …)
>>
>> I think this patch's current form is preferable, as it means future
>> boot-parameters version bumps won't break older Guices (when
>> reconfiguring), as long as the version is an exact, non-negative integer
>> (e.g. when going from 1 to 2).
>
> That’s what we want to avoid: bumping the version number means that the
> new format is not backwards-compatible, and that older Guix versions
> won’t be able to read it.  That’s why I think ‘read-boot-parameters’
> needs to be explicit about the version(s) it expects.  (A more complete
> example of this pattern is ‘sexp->manifest’.)
>
> Breaking backwards compatibility should be avoided when possible, but
> it’s not always possible.  In ‘read-boot-parameters’, ‘bootloader-name’,
> ‘bootloader-menu-entries’, ‘kernel’, etc. are handled somewhat weirdly
> to preserve backwards-compatibility; doing this allowed us to not bump
> the file format version.

Thanks for explaining!  I initially thought the choice to break backward
compatibility could be left to the implementer of a new version, but now
I see this wouldn't work or be brittle.

I've modified the first commit like so:

--8<---cut here---start->8---
modified   gnu/system.scm
@@ -365,8 +365,10 @@ (define uuid-sexp->uuid
(warning (G_ "unrecognized uuid ~a at '~a'~%") x (port-filename port))
#f)))
 
+  ;; New versions are not backward-compatible, so only accept past and current
+  ;; versions, not future ones.
   (define (version? n)
-(and (exact-integer? n) (not (negative? n
+(member n (iota (1+ %boot-parameters-version
 
   (match (read port)
 (('boot-parameters ('version (? version? version))
--8<---cut here---end--->8---

So that there's only one thing to update when we'll bump the version
again in the future (%boot-parameters-version).

I'll be sending a v3 shortly, thanks again!

Maxim

bug#40998: Guix System's initrd doesn't honor rootflags

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> There’s no need to have a ‘version’ field in live 
>> records: have the ‘version’ field in the serialized format (the sexp)
>> and make sure the deserializer correctly converts to the internal
>> representation.
>>
>> Here, I think you can bump the version number in the serialized form,
>> and have ‘read-boot-parameters’ automatically augment ‘kernel-arguments’
>> when VERSION is 0 with “--root=XYZ”.
>
> I initially went that route, as this was the idea you'd given me
> initially.  However, 'read-boot-parameters' deals with serializing the
> parameters file only; to add 'root', 'gnu.load' and 'gnu.system', the
> operating-system object as well as the root device are needed.

 already has ‘root-device’, so that’s fine.

But you’re right that the system itself is a problem because that’s
self-referential—it’s the thing the “parameters” file is in.  Hmm!

We could add a substitution mechanism where a literal “$SYSTEM” (say) in
the ‘kernel-arguments’ of  would be substituted by the
actual system store file name by ‘read-boot-parameters’, but maybe
that’s overkill.

So long story short: keeping the ‘version’ field in 
sounds reasonable after all.  :-)

> The reason 'gnu.load' and 'gnu.system' aren't written to the
> parameters file to start with is because they would cause the system
> directory to no longer be content-addressable; this is explained in
> the docstring of 'operating-system-boot-parameters-file':
>
> When SYSTEM-KERNEL-ARGUMENTS? is true, add kernel arguments such as 'root'
> and 'gnu.load' to the returned file (since the returned file is then 
> usually
> stored into the content-addressed "system" directory, it's usually not a
> good idea to give it because the content hash would change by the content 
> hash
> being stored into the "parameters" file).

This comment originates in 40fad1c24ce60076e26f6dc8096e4716d31d90c3.  I
find it a bit misleading because nothing’s “content-addressed”, but I
guess it refers to the same problem: that this is self-referential.

(There’s only one use of #:system-kernel-arguments? #t.  We can remove
that keyword parameter from ‘operating-system-boot-parameters-file’
since it’s not used there.)

>> Also, you could write the ‘match’ pattern like this:
>>
>>   ('boot-parameters ('version (and version (or 0 1)))
>> ('label label) …)
>
> I think this patch's current form is preferable, as it means future
> boot-parameters version bumps won't break older Guices (when
> reconfiguring), as long as the version is an exact, non-negative integer
> (e.g. when going from 1 to 2).

That’s what we want to avoid: bumping the version number means that the
new format is not backwards-compatible, and that older Guix versions
won’t be able to read it.  That’s why I think ‘read-boot-parameters’
needs to be explicit about the version(s) it expects.  (A more complete
example of this pattern is ‘sexp->manifest’.)

Breaking backwards compatibility should be avoided when possible, but
it’s not always possible.  In ‘read-boot-parameters’, ‘bootloader-name’,
‘bootloader-menu-entries’, ‘kernel’, etc. are handled somewhat weirdly
to preserve backwards-compatibility; doing this allowed us to not bump
the file format version.

Thanks!

Ludo’.

bug#40998: Guix System's initrd doesn't honor rootflags

[Maxim Cournoyer]

Hi again,

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:
>
>> * gnu/build/linux-boot.scm (boot-system): Print command-line parameters to
>> standard output.
>> ---
>>  gnu/build/linux-boot.scm | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm
>> index 2f8b114806..30442ec8f8 100644
>> --- a/gnu/build/linux-boot.scm
>> +++ b/gnu/build/linux-boot.scm
>> @@ -542,6 +542,8 @@ (define (device-string->file-system-device device-string)
>>   (root-fs*(find root-mount-point? mounts))
>>   (fsck.mode (find-long-option "fsck.mode" args)))
>>  
>> +(format #t "initrd command-line parameters: ~a~%" args)
>
> I’d happily avoid being too talkative by default, but maybe we could
> honor a ‘gnu.verbosity’ parameter to get different levels of early-boot
> logging?  :-)

Eh, I've dropped it for now; I attribute my perceived need for it due to
the odd berlin boot output as seen from the serial console [0], which
was missing it (it appears to be truncated).

Thank you!

Maxim

[0]  https://elephly.net/paste/1645131411.html

bug#40998: Guix System's initrd doesn't honor rootflags

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> -(define (bootable-kernel-arguments system root-device)
>> -  "Return a list of kernel arguments (gexps) to boot SYSTEM from 
>> ROOT-DEVICE."
>> -  (list (string-append "--root="
>> +(define* (bootable-kernel-arguments system root-device version)
>> +  "Return a list of kernel arguments (gexps) to boot SYSTEM from 
>> ROOT-DEVICE.
>> +VERSION is the target version of the boot-parameters record."
>> +  ;; If the version is newer than 0, we use the new style initrd parameter
>> +  ;; names, otherwise we use the legacy ones.  This is to maintain backward
>> +  ;; compatibility when producing bootloader configurations for older
>> +  ;; generations.
>> +  (define version>0? (> version 0))
>> +  (list (string-append (if version>0? "root=" "--root=")
>> ;; Note: Always use the DCE format because that's 
>> what
>> -   ;; (gnu build linux-boot) expects for the '--root'
>> +   ;; (gnu build linux-boot) expects for the 'root'
>> ;; kernel command-line option.
>> (file-system-device->string root-device
>> #:uuid-type 'dce))
>> -#~(string-append "--system=" #$system)
>> -#~(string-append "--load=" #$system "/boot")))
>> +#~(string-append (if #$version>0? "gnu.system=" "--system=") 
>> #$system)
>> +#~(string-append (if #$version>0? "gnu.load=" "--load=")
>> + #$system "/boot")))
>
> This is the logic I was suggesting to move to ‘read-boot-parameters’.
>
> To do that, ‘read-boot-parameters’ would have to fill the
> ‘kernel-arguments’ field of  such that it already
> contains --system/gnu.system and --load/gnu.load.

As mentioned in my previous reply, that'd only be possible if we no
longer cared about having the produced system directory
content-addressable, if I understood that comment in the docstring
referred earlier correctly.

Thanks,

Maxim

bug#40998: Guix System's initrd doesn't honor rootflags

[Maxim Cournoyer]

Hi Ludovic!

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> This version field exposes the (already present) version information of a 
>> boot
>> parameters file.
>>
>> * gnu/system.scm (%boot-parameters-version): New variable.
>> ()[version]: New field.
>> (read-boot-parameters): Use it.
>> (operating-system-boot-parameters-file): Likewise.
>> * tests/boot-parameters.scm (test-read-boot-parameters): Use
>> %boot-parameters-version as the default version value in the template.
>
> [...]
>
>>  (define-record-type* 
>>boot-parameters make-boot-parameters boot-parameters?
>>(labelboot-parameters-label)
>> @@ -322,7 +326,9 @@ (define-record-type* 
>>(kernel   boot-parameters-kernel)
>>(kernel-arguments boot-parameters-kernel-arguments)
>>(initrd   boot-parameters-initrd)
>> -  (multiboot-modules boot-parameters-multiboot-modules))
>> +  (multiboot-modules boot-parameters-multiboot-modules)
>> +  (version  boot-parameters-version  ;positive integer
>> +(default %boot-parameters-version)))
>
> [...]
>
>>(match (read port)
>> -(('boot-parameters ('version 0)
>> +(('boot-parameters ('version (? version? version))
>> ('label label) ('root-device root)
>> ('kernel kernel)
>> rest ...)
>>   (boot-parameters
>> +  (version version)
>>(label label)
>>(root-device (device-sexp->device root))
>
> There’s no need to have a ‘version’ field in live 
> records: have the ‘version’ field in the serialized format (the sexp)
> and make sure the deserializer correctly converts to the internal
> representation.
>
> Here, I think you can bump the version number in the serialized form,
> and have ‘read-boot-parameters’ automatically augment ‘kernel-arguments’
> when VERSION is 0 with “--root=XYZ”.

I initially went that route, as this was the idea you'd given me
initially.  However, 'read-boot-parameters' deals with serializing the
parameters file only; to add 'root', 'gnu.load' and 'gnu.system', the
operating-system object as well as the root device are needed.  The
reason 'gnu.load' and 'gnu.system' aren't written to the parameters file
to start with is because they would cause the system directory to no
longer be content-addressable; this is explained in the docstring of
'operating-system-boot-parameters-file':

When SYSTEM-KERNEL-ARGUMENTS? is true, add kernel arguments such as 'root'
and 'gnu.load' to the returned file (since the returned file is then usually
stored into the content-addressed "system" directory, it's usually not a
good idea to give it because the content hash would change by the content 
hash
being stored into the "parameters" file).

So, unless we were to pack 'read-boot-parameters' with unrelated duties
and a 'system-kernel-arguments?' argument, it seems unavoidable to
expose the 'version' metadata.

> (It might be that you can even do that without bumping the version
> number.  Bumping is clearer but the downside is that an older Guix will
> abort when attempting to read ‘parameters’.  This could happen if you
> roll back to an earlier generation and try to run ‘guix system
> reconfigure’ or similar from there.)
>
> Also, you could write the ‘match’ pattern like this:
>
>   ('boot-parameters ('version (and version (or 0 1)))
> ('label label) …)

I think this patch's current form is preferable, as it means future
boot-parameters version bumps won't break older Guices (when
reconfiguring), as long as the version is an exact, non-negative integer
(e.g. when going from 1 to 2).

Let me know what you think!

Thank you,

Maxim

bug#41791: [Shepherd] loses track of Tor

[Attila Lendvai]

i'm not sure this is related, but it's certainly a bug in MAKE-KILL-DESTRUCTOR
that it doesn't wait for the process to quit after sending it a signal, and thus
may restart the service while the previous instance is still running.

it's also not sending it a kill -9 after a timeout if the process is not
responsive.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“[Design] Patterns mean "I have run out of language."”
— Rich Hickey

bug#54111: guile bundles (a compiled version of) UnicodeData.txt and binaries

[Maxime Devos]

Ludovic Courtès schreef op ma 28-02-2022 om 12:45 [+0100]:
> It might be easier to rewrite in Awk in build srfi-14.i.c
> unconditionally no?

I don't know any Awk and it seems to be quite different from languages
I know, so for me doing that isn't easier.  But for someone who knows
some Awk, sure!

Greetings,
Maxime.


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

bug#40998: [PATCH v2 4/4] initrd: Print its command-line parameters.

[Maxim Cournoyer]

Hi,

Tobias Geerinckx-Rice  writes:

> On 19 February 2022 07:01:55 UTC, Maxim Cournoyer  
> wrote:
>>* gnu/build/linux-boot.scm (boot-system): Print command-line parameters to
>>standard output.
>>---
>> gnu/build/linux-boot.scm | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>>diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm
>>index 2f8b114806..30442ec8f8 100644
>>--- a/gnu/build/linux-boot.scm
>>+++ b/gnu/build/linux-boot.scm
>>@@ -542,6 +542,8 @@ (define (device-string->file-system-device device-string)
>>  (root-fs*(find root-mount-point? mounts))
>>  (fsck.mode (find-long-option "fsck.mode" args)))
>> 
>>+(format #t "initrd command-line parameters: ~a~%" args)
>>+
>> (unless (or root-fs* (and root-device rootfstype))
>>   (error "no root file system or 'root' and 'rootfstype' 
>> parameters"))
>> 
>
> I suggest dropping this patch.  The kernel already does this.  It's just 
> noise.

I thought about adding it after attempting to debug initrd/kernel
problems as can be seen here: https://elephly.net/paste/1645124517.html
(this is the Berlin boot log copied from a serial console).  Not that
the initrd printing it itself would have helped here, as it appears to
be truncated from when Linux took over the initrd script, if I
understand correctly.

Anyway, I agree it's probably redundant and useless in all but more
desperate debugging cases :-), so I don't mind to drop it.

Thanks,

Maxim

bug#54192: guix gc --verify=repair,contents does not repair store

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

Hi Jack,

nckx here.  Thanks for reporting this bug, and thanks for including 
information that might help fix it.


Unfortunately — another word for ‘base64’ — this makes your message a 
whopping 20 MiB in size.  We really can't send that out to all 
subscribers, some of which might be on slow and/or expensive 
connections.


That's all right: your report is still accessible at 
, including the attachment.  It's a 
bit slow to render here but I think the extra info's worth it.


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#54111: guile bundles (a compiled version of) UnicodeData.txt and binaries

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> Ludovic Courtès schreef op zo 27-02-2022 om 14:52 [+0100]:

[...]

>> We could rewrite ‘unidata_to_charset.pl’ in Scheme, but then Guile would
>> still need to provide a pre-compiled version of srfi-14.i.c for
>> bootstrapping purposes.  Or we could rewrite it in Awk, since Guile
>> already depends on Awk anyway.
>> 
>> Thoughts?
>
> The ‘blob’ seems relatively harmless to the compilation process, so
> when there are bootstrapping problems, I think we can leave it in.
>
> However, all this Unicode is important for some other things (e.g. some
> DNS and filesystem things).  So it would be nice to validate that no
> attacker with access to the Guile repo stealthily introduced some wrong
> information in during an otherwise routine update of the Unicode
> information.

The threat model is that the repository is trusted (that’s a strong
assumption, but that’s how it is).  You cannot protect against someone
with access to the repository.

We could use ‘guix git authenticate’ to improve on that.

> Hence, the following proposal:
>
>   * Make perl an optional dependency of Guile (upstream) and add an
> '--with-unicode-data=[...]' configure flag or something like that.
>
> If perl is detected by './configure' and '--with-unicode-data=...'
> is set, then let one of the makefiles run 'unidata_to_charset.pl'
> and compare the 'new' srfi-14.i.c against the old srfi-14.i.c.
>
> In case of a mismatch, bail out.
>
> When there's no perl or --with-unicode-data, then just use the
> bundled srfi-14.i.c.
>
>   * Add 'perl' (or 'perl-boot0' because that perl is probably good
> enough?) to the native-inputs of guile.
>
> Actually, the second is already done in 'guile-final'.
> Optionally, this can be combined with rewriting it in Scheme
> or some other language.

It might be easier to rewrite in Awk in build srfi-14.i.c
unconditionally no?

We can also add ‘--with-unicode-data’, though that’s orthogonal.

Thanks,
Ludo’.

bug#54197: 404 link to Debuggs User Guide

[Roman Riabenko]

GNU Guix documentation at 17.7.2 Debuggs User Interfaces (16.7 for
1.3.0 documentation) links to Debuggs User Guide (in the last line
before footnotes). When accessed with info, the link is to the package
documentation, so, apparently, I cannot access it without debuggs
installed, which is expected behaviour. However, the online
documentation attempts to provide a link to the online resource, which
lands on 404. The relevant guix manual pages which need to be corrected
(in the stable and the latest manuals respectively):
https://guix.gnu.org/en/manual/en/html_node/Tracking-Bugs-and-Patches.html#Tracking-Bugs-and-Patches
https://guix.gnu.org/en/manual/devel/en/html_node/Debbugs-User-Interfaces.html
The broken link that they contain at the moment:
https://guix.gnu.org/en/manual/devel/en/debbugs-ug/index.html#Top
I assume that the link should be instead:
https://elpa.gnu.org/packages/doc/debbugs-ug.html

Roman