bug#66510: `this-package' references reintroduce pre-transformation packages.

[Ulf Herrman]

Suppose you have a package that is using a gexp in its argument list
and, like a good citizen of the gexp world, it uses this-package-input
to refer to its own input packages.  In fact, let's suppose that it's
the model citizen depicted in
https://guix.gnu.org/en/blog/2021/the-big-change/ under the
"G-expressions and self-referential records" heading:

(define hello
  (package
(name "hello")
;; …
(arguments
 (list #:configure-flags
   #~(list (string-append "--with-gawk="
  #$(this-package-input "gawk")
(inputs `(("gawk" ,gawk)

If we define a variant like so:

(define hello-variant
  (package
(inherit hello)
(name "hello-variant")
(inputs `(("gawk" ,gawk-4.0)

it will work just fine.  But if we define a variant like SO:

(define hello-variant
  (package
(inherit hello)
(name "hello-variant")
(inputs `(("gawk" ,gawk-4.0)))
(arguments
 (substitute-keyword-arguments (package-arguments hello)
   ((#:configure-flags flags #~'())
#~(cons "--with-hospitality=ice-cream"
#$flags))

it will NOT work just fine.  When (package-arguments hello) is
evaluated, it will execute the field definition for `hello' with
`this-package' bound to `hello', rather than `hello-variant'.
Consequently, `this-package-input' will return gawk rather than
gawk-4.0.  We need a way to access the "parent" package's fields while
keeping `this-package' bound to its current value.  The most general
form of this would look something like this:

(define (package-arguments-with-package p0 p)
  (match p0
(($  _ _ _ _ arguments-proc)
 (arguments-proc p

Then hello-variant could be changed to use
(package-arguments-with-package hello this-package)
instead of (package-arguments hello).  This may be needlessly general,
though; the problem could also be solved with an interface more along
the lines of

(parent-package-arguments hello)

which expands into the aforementioned package-arguments-with-package
call.

Another option would be to, yet again, extend the record syntax.  It's
always bugged me a bit to have to explicitly reference the original
record in more than one place when using derived fields, so this might
be generally useful as well:

(define hello-variant
  (package
(inherit hello
 (arguments hello-arguments))
(name "hello-variant")
(inputs `(("gawk" ,gawk-4.0)))
(arguments
 (substitute-keyword-arguments hello-arguments
   ((#:configure-flags flags #~'())
#~(cons "--with-hospitality=ice-cream"
#$flags))

This would create a macro named `hello-arguments' within the scope of
the (package ...) form which expands into something equivalent to a
`parent-package-arguments' call.  Adjust syntax to taste.

Thoughts?

- Ulf


signature.asc
Description: PGP signature

bug#66027: [PATCH v3 2/3] gnu: patman: Apply patch for new Change-Id setting.

[Maxim Cournoyer]

* gnu/packages/bootloaders.scm (u-boot) [source]: Apply patch.
* gnu/packages/patches/u-boot-patman-change-id.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
* .patman (keep_change_id): Use it.

Change-Id: I33c03013f6a260b5f5d80212b7b6ebe8a3f97efa
---

Changes in v3:
 - New commit

 .patman   |   1 +
 gnu/local.mk  |   1 +
 gnu/packages/bootloaders.scm  |   3 +-
 .../patches/u-boot-patman-change-id.patch | 232 ++
 4 files changed, 236 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/u-boot-patman-change-id.patch

diff --git a/.patman b/.patman
index 13fa4d0fab..efc42144a2 100644
--- a/.patman
+++ b/.patman
@@ -8,3 +8,4 @@ add_signoff: False
 # TODO: enable check_patch
 check_patch: False
 ignore_bad_tags: True
+keep_change_id: True
diff --git a/gnu/local.mk b/gnu/local.mk
index 13c2b94944..39d833cee0 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -2052,6 +2052,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/u-boot-fix-build-python-3.10.patch  \
   %D%/packages/patches/u-boot-fix-u-boot-lib-build.patch   \
   %D%/packages/patches/u-boot-nintendo-nes-serial.patch\
+  %D%/packages/patches/u-boot-patman-change-id.patch   \
   %D%/packages/patches/u-boot-rockchip-inno-usb.patch  \
   %D%/packages/patches/u-boot-sifive-prevent-reloc-initrd-fdt.patch\
   %D%/packages/patches/u-boot-rk3399-enable-emmc-phy.patch \
diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index 1124eca837..fb20ba0efa 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -654,7 +654,8 @@ (define u-boot
  %u-boot-sifive-prevent-relocating-initrd-fdt
  %u-boot-rk3399-enable-emmc-phy-patch
  (search-patch "u-boot-fix-build-python-3.10.patch")
- (search-patch "u-boot-fix-u-boot-lib-build.patch")))
+ (search-patch "u-boot-fix-u-boot-lib-build.patch")
+ (search-patch "u-boot-patman-change-id.patch")))
   (method url-fetch)
   (uri (string-append
 "https://ftp.denx.de/pub/u-boot/;
diff --git a/gnu/packages/patches/u-boot-patman-change-id.patch 
b/gnu/packages/patches/u-boot-patman-change-id.patch
new file mode 100644
index 00..354aee2755
--- /dev/null
+++ b/gnu/packages/patches/u-boot-patman-change-id.patch
@@ -0,0 +1,232 @@
+Upstream status: 
https://patchwork.ozlabs.org/project/uboot/patch/20231013030633.7191-1-maxim.courno...@gmail.com/
+
+From f83a5e07b0934e38cbee923e0c5b7fc0a890926c Mon Sep 17 00:00:00 2001
+From: Maxim Cournoyer 
+Date: Thu, 12 Oct 2023 17:04:25 -0400
+Subject: [PATCH] patman: Add a 'keep_change_id' setting
+
+A Change-Id can be useful for traceability purposes, and some projects
+may wish to have them preserved.  This change makes it configurable
+via a new 'keep_change_id' setting.
+
+Series-version: 2
+Series-changes: 2
+- Add missing argument to send parser
+---
+ tools/patman/__main__.py|  2 ++
+ tools/patman/control.py | 12 +---
+ tools/patman/patchstream.py | 17 -
+ tools/patman/patman.rst | 11 ++-
+ tools/patman/test_checkpatch.py | 16 
+ 5 files changed, 45 insertions(+), 13 deletions(-)
+
+diff --git a/tools/patman/__main__.py b/tools/patman/__main__.py
+index 8eba5d3486..197ac1aad1 100755
+--- a/tools/patman/__main__.py
 b/tools/patman/__main__.py
+@@ -103,6 +103,8 @@ send.add_argument('--no-signoff', action='store_false', 
dest='add_signoff',
+   default=True, help="Don't add Signed-off-by to patches")
+ send.add_argument('--smtp-server', type=str,
+   help="Specify the SMTP server to 'git send-email'")
++send.add_argument('--keep-change-id', action='store_true',
++  help='Preserve Change-Id tags in patches to send.')
+ 
+ send.add_argument('patchfiles', nargs='*')
+ 
+diff --git a/tools/patman/control.py b/tools/patman/control.py
+index 916ddf8fcf..b292da9dc2 100644
+--- a/tools/patman/control.py
 b/tools/patman/control.py
+@@ -16,11 +16,14 @@ from patman import gitutil
+ from patman import patchstream
+ from u_boot_pylib import terminal
+ 
++
+ def setup():
+ """Do required setup before doing anything"""
+ gitutil.setup()
+ 
+-def prepare_patches(col, branch, count, start, end, ignore_binary, signoff):
++
++def prepare_patches(col, branch, count, start, end, ignore_binary, signoff,
++keep_change_id=False):
+ """Figure out what patches to generate, then generate them
+ 
+ The patch files are written to the current directory, e.g. 0001_xxx.patch
+@@ -35,6 +38,7 @@ def prepare_patches(col, branch, count, start, end, 
ignore_binary, signoff):
+ end (int): End patch to use (0=last one in series, 1=one 

bug#66027: [PATCH v3 3/3] etc: teams: Parse 'From' commit more leniently.

[Maxim Cournoyer]

When a Change-Id is used, patman prepends a Message-Id field on the first line
of the patch, which broke the assumption that the 'From $commit' line must
appear on the first line.

* etc/teams.scm.in (git-patch->commit-id): Loop each line of the file until a
match is found.  Update doc.

Change-Id: I20400f87469ffb761ffc82dd32e34cd06f619043
---

Changes in v3:
 - New commit

 etc/teams.scm.in | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/etc/teams.scm.in b/etc/teams.scm.in
index 55242caad1..703d76fe8d 100644
--- a/etc/teams.scm.in
+++ b/etc/teams.scm.in
@@ -770,13 +770,16 @@ (define (diff-revisions rev-start rev-end)
 files))
 
 (define (git-patch->commit-id file)
-  "Parse the commit ID from the first line of FILE, a patch produced with git."
+  "Parse the commit ID from FILE, a patch produced with git."
   (call-with-input-file file
 (lambda (port)
-  (let ((m (string-match "^From ([0-9a-f]{40})" (read-line port
-(unless m
-  (error "invalid patch file:" file))
-(match:substring m 1)
+  (let loop ((line (read-line port)))
+(when (eof-object? line)
+  (error "could not find 'from' commit in patch" file))
+(let ((m (string-match "^From ([0-9a-f]{40})" line)))
+  (if m
+   (match:substring m 1)
+   (loop (read-line port
 
 (define (git-patch->revisions file)
   "Return the start and end revisions of FILE, a patch file produced with git."
-- 
2.41.0

bug#66027: [PATCH v3 1/3] build: Add a commit-msg hook that embeds Change-Id in commit messages.

[Maxim Cournoyer]

Partially implements .

This will make it possible to track a merged commit back to its original
posting on the mailing list, and open the door to new opportunities such as
closing fully merged series automatically.

* Makefile.am (COMMIT_MSG_MAGIC): New variable.
(.git/hooks/commit-msg): New target.
* etc/git/commit-msg: New file.
* doc/contributing.texi (Configuring Git): Document Change-Id.

Change-Id: Ia92fa958eae600fdd4e180bad494c85db8bb4dd6
Reviewed-by: Simon Tournier 
---

Changes in v3:
 - Clarify documentation text, as suggested by Simon

 Makefile.am   | 12 +-
 doc/contributing.texi | 10 -
 etc/git/commit-msg| 94 +++
 3 files changed, 114 insertions(+), 2 deletions(-)
 create mode 100755 etc/git/commit-msg

diff --git a/Makefile.am b/Makefile.am
index 310a231259..b860af7258 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1172,7 +1172,17 @@ cuirass-jobs: $(GOBJECTS)
git config --add include.path ../etc/git/gitconfig; \
fi
 
-nodist_noinst_DATA = .git/hooks/pre-push .git/config
+COMMIT_MSG_MAGIC = VGhpcyBpcyB0aGUgY29tbWl0LW1zZyBob29rIG9mIEd1aXg=
+.git/hooks/commit-msg: etc/git/commit-msg
+   $(AM_V_at)if test -d .git; then \
+   if test -f $@  && ! grep -qF $(COMMIT_MSG_MAGIC) $@; then \
+ mkdir -p $@.d && mv $@ $@.d && \
+   @ echo user commit-msg hook moved to $@.d/commit-msg; \
+   fi; \
+   cp etc/git/commit-msg $@; \
+   fi
+
+nodist_noinst_DATA = .git/hooks/pre-push .git/config .git/hooks/commit-msg
 
 # Downloading up-to-date PO files.
 
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 864190b119..43cfae26c4 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -1575,8 +1575,16 @@ Configuring Git
 use @command{git config --local}, or edit @file{.git/config} in the
 repository instead of @file{~/.gitconfig}.
 
+@cindex commit-msg hook
 Other important Git configuration will automatically be configured when
-building the project (@pxref{Building from Git}).
+building the project (@pxref{Building from Git}).  A
+@file{.git/hooks/commit-msg} hook will be installed that embeds
+@samp{Change-Id} Git @emph{trailers} in your commit messages for
+traceability purposes.  It is important to preserve these when editing
+your commit messages, particularly if a first version of your proposed
+changes was already submitted for review.  If you have a
+@file{commit-msg} hook of your own you would like to use with Guix, you
+can place it under the @file{.git/hooks/commit-msg.d/} directory.
 
 @node Sending a Patch Series
 @subsection Sending a Patch Series
diff --git a/etc/git/commit-msg b/etc/git/commit-msg
new file mode 100755
index 00..dfa07918bb
--- /dev/null
+++ b/etc/git/commit-msg
@@ -0,0 +1,94 @@
+#!/bin/sh
+# From Gerrit Code Review 3.6.1
+#
+# Part of Gerrit Code Review (https://www.gerritcodereview.com/)
+#
+# Copyright (C) 2009 The Android Open Source Project
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+### Guix modifications start
+COMMIT_MSG_MAGIC=VGhpcyBpcyB0aGUgY29tbWl0LW1zZyBob29rIG9mIEd1aXg=
+top=$(git rev-parse --show-toplevel)
+if test -d "$top/.git/hooks/commit-msg.d/"; then
+for msg_hook in "$top/.git/hooks/commit-msg.d/"*; do
+if ! sh "$msg_hook"; then
+echo "error while running $msg_hook"
+exit 1
+fi
+done
+fi
+### Guix modifications end
+
+set -u
+
+# avoid [[ which is not POSIX sh.
+if test "$#" != 1 ; then
+  echo "$0 requires an argument."
+  exit 1
+fi
+
+if test ! -f "$1" ; then
+  echo "file does not exist: $1"
+  exit 1
+fi
+
+# Do not create a change id if requested
+if test "false" = "$(git config --bool --get gerrit.createChangeId)" ; then
+  exit 0
+fi
+
+if git rev-parse --verify HEAD >/dev/null 2>&1; then
+  refhash="$(git rev-parse HEAD)"
+else
+  refhash="$(git hash-object -t tree /dev/null)"
+fi
+
+random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } | git 
hash-object --stdin)
+dest="$1.tmp.${random}"
+
+trap 'rm -f "${dest}"' EXIT
+
+if ! git stripspace --strip-comments < "$1" > "${dest}" ; then
+   echo "cannot strip comments from $1"
+   exit 1
+fi
+
+if test ! -s "${dest}" ; then
+  echo "file is empty: $1"
+  exit 1
+fi
+
+reviewurl="$(git config --get gerrit.reviewUrl)"
+if test -n "${reviewurl}" ; then
+  if ! git interpret-trailers --parse < "$1" | grep -q 
'^Link:.*/id/I[0-9a-f]\{40\}$' ; then
+if ! git 

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Ulf Herrman]

Ludovic Courtès  writes:

> Ulf Herrman  skribis:
>
>> -(define (build-system-with-package-mapping bs rewrite)
>> +(define (build-system-with-package-mapping bs rewrite-input 
>> rewrite-argument)
>>"Return a variant of BS, a build system, that rewrites a bag's inputs by
>>  passing them through REWRITE, a procedure that takes an input tuplet and
>>  returns a \"rewritten\" input tuplet."
>> @@ -1442,9 +1442,10 @@ (define (build-system-with-package-mapping bs rewrite)
>>  (let ((lowered (apply lower args)))
>>(bag
>>  (inherit lowered)
>> -(build-inputs (map rewrite (bag-build-inputs lowered)))
>> -(host-inputs (map rewrite (bag-host-inputs lowered)))
>> -(target-inputs (map rewrite (bag-target-inputs lowered))
>> +(build-inputs (map rewrite-input (bag-build-inputs lowered)))
>> +(host-inputs (map rewrite-input (bag-host-inputs lowered)))
>> +(target-inputs (map rewrite-input (bag-target-inputs lowered)))
>> +(arguments (map rewrite-argument (bag-arguments lowered))
>
> Aah, now I understand.  :-)
>
> It’s indeed the case that arguments can capture references to packages
> that won’t be caught by ‘package-mapping’.  For instance, if you write:
>
>   (package
> …
> (arguments (list … #~(whatever #$coreutils
>
> … then ‘coreutils’ here cannot be replaced.
>
> To address this, the recommendation is to always add dependencies to
> input fields and to use self-references within arguments.  The example
> above should be written like this:
>
>   (package
> …
> (arguments
>  (list … #~(whatever #$(this-package-input "coreutils")
>
> It’s just a recommendation and one can perfectly ignore it, and I
> suppose that was the impetus for this patch.

That and a growing thirst for a nuclear option for package rewriting
brought about by trying to debug deep transformations while
simultaneously experimenting with rewriting a manifest of around 270
packages.

There are really several distinct issues at play here:
1. The case of #:qtbase and #:guile being invisible to package-mapping.
   This is what I first noticed, and cannot be fixed without modifying
   the build systems.  This is what prompted looking for packages in
   package and bag arguments, and recursing into lists therein (just in
   case an argument took a list of packages).
2. The (perceived) case of packages hiding inside arguments.  In
   hindsight, this was probably actually (3) causing this, though it's
   hard to tell because I discovered it last.  I attempted to resolve
   this by recursing through s and s.
3. `this-package' referring to the inherited package in thunked fields,
   rather than the package inheriting them.  This is what prompted the
   use of package-{inputs,arguments,etc}-with-package.

(1) could be resolved in several ways.  I'm partial to looking for
arguments whose values are packages and transforming them (when #:deep?
#t is specified), and adjusting the build systems to make that work
consistently, which is what I've done.

(2) is probably not an issue, though it occurs to me that the technique
of recursively searching through arguments looking for packages could be
used to implement a sort of automated "transformability" check, which
could help a lot when trying to debug transformations.

(3) is a major issue; the entire strategy of using `this-package-input'
to enable transformations breaks because of it.  My fix works for me at
least, though it requires exposing additional low-level procedures and
transformation authors using them.  I'll open another bug about it, as
requested.

> This is one of the things discussed while designing this change:
>
>   https://guix.gnu.org/en/blog/2021/the-big-change/
>   (search for “self-referential records”)
>
>   https://issues.guix.gnu.org/49169
>
> My take was and still is that it’s an acceptable limitation.  Packagers
> need to follow the guideline above if they want proper support for
> rewriting, ‘guix graph’, and other tools.
>
> WDYT?

I think it's probably reasonable, though I would like it if there were
tooling in place to detect cases where said guidelines are not
followed, so as to aid in debugging and verifying that a transformation
worked as intended.

- Ulf


signature.asc
Description: PGP signature

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Ulf Herrman]

Maxim Cournoyer  writes:

> Any build system accepting package as arguments are subject to this
> problem, if I understand correctly.

It's not quite everywhere a package is accepted as an argument: there
are many cases where a package is passed as a package argument but
doesn't end up in the arguments list of the corresponding bag.  This is
usually the case because that argument is only overriding a default
package that is just added as an input to the bag, with no special
treatment aside from being an implicit input.  For example, #:cmake in
cmake-build-system works this way.

This is however not the case for #:qtbase in qt-build-system, and, much
more prominently, for #:guile.  Neither qtbase nor guile are added to
bag inputs implicitly, but they do end up in the final builder, even if
not specified.

Concretely, this looks like this:
-
(use-modules (guix packages)
 (guix profiles)
 (gnu packages base))

(define guile-named-lyle
  (package
(inherit (default-guile))
(name "lyle")))

;; contrived example that only replaces hello's immediate dependencies
(define hello-transformer
  (package-mapping (lambda (p0)
 (if (eq? p0 (default-guile))
 guile-named-lyle
 p0))
   (lambda (p)
 (not (eq? p hello)))
   #:deep? #t))

(define hello-with-lyle
  (hello-transformer hello))

(packages->manifest (list hello hello-with-lyle))

;; $ guix build --derivations --manifest=THISFILE
;; Expectation: build for hello-with-lyle is done with guile-named-lyle.
;; Reality: derivation for hello-with-lyle is the same as hello.
-
(and I have confirmed that the above results in guile-named-lyle being
used with the proposed patches applied)

A similar problem manifests when one tries replacing (default-qtbase) in
a package using qt-build-system.  Both it and guile are in bag arguments
and not inputs because it's not enough that they be included as inputs,
the builder must also know which one is considered "used by the build
system" if there are multiple.  One could argue that this ambiguity also
exists with other build systems - "which cmake should be used, which gcc
should be used", etc - but they choose to resolve it with "eh, whatever
shows up first in PATH matching the required name is probably fine".
It's not unimaginable that there could be cases where explicitly
specifying which package should be used for a particular role would be
necessary, though.

- Ulf


signature.asc
Description: PGP signature

bug#58497: opam import doesn't work with ocaml_intrinsics among others

[Csepp]

Simon Tournier  writes:

> Hi,
>
> It is about bug#58497 [1], and I cannot reproduce.  I think the reported
> bug had been fixed.  I am in favor to close.  WDYT?
>
> 1: https://issues.guix.gnu.org/issue/58497
>
> On Thu, 13 Oct 2022 at 18:07, Csepp  wrote:
>
>> guix import opam ocaml_intrinsics
>> Backtrace:
>
> Using Guix 6113e05, I get:
>
> --8<---cut here---start->8---
> $ guix import opam ocaml_intrinsics
> (package
>   (name "ocaml-intrinsics")
>   (version "0.16.0")
>   (source no-source-information)
>   (build-system dune-build-system)
>   (propagated-inputs (list ocaml-dune-configurator))
>   (properties `((upstream-name . "ocaml_intrinsics")))
>   (home-page "https://github.com/janestreet/ocaml_intrinsics;)
>   (synopsis "Intrinsics")
>   (description
>"This package provides functions to invoke amd64 instructions (such as
> clz,popcnt,rdtsc,rdpmc) when available, or compatible software implementation 
> on
> other targets.")
>   (license license:expat))
> --8<---cut here---end--->8---
>
>
> Cheers,
> simon

Yup, seems to "work" now, although that no-source-information thing is
still pretty irritating, but it happens infrequently enough to not
matter too much.

bug#66033: Package name conflict for "helm"

[John Kehayias via Bug reports for GNU Guix]

Hi Panos,

On Sat, Sep 16, 2023 at 05:39 PM, Panos Alevropoulos wrote:

> Hi,
>
> There seems to be a recently introduced package name conflict.
> There are two packages named "helm". One is is the package manager for
> Kubernetes and the other is a synthesizer. I noticed after upgrading
> and helm suddenly jumped from 0.9.0 to 3.12.3. `guix install
> helm@0.9.0` restores helm-lv2 as a temp fix.
>
> I suggest the latter be renamed "helm-lv2" to fix the issue.
>
> Panos

Turns out this is due to another channel adding a package by the same
name. It should now be fixed in that channel. Thanks for reporting!

John

bug#64856: guix shell cache doesn't consider grafts

[Ludovic Courtès]

Hello,

Maxim Cournoyer  skribis:

> While investigating https://issues.guix.gnu.org/64836, I discovered that
> the cache of 'guix shell' doesn't take into account grafts for
> subsequent invocations.

Fixed in 75bdf8e06a325b90bf387a03f88726d338acbbf6.

Thanks,
Ludo’.

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Ulf Herrman  skribis:
>
>> -(define (build-system-with-package-mapping bs rewrite)
>> +(define (build-system-with-package-mapping bs rewrite-input 
>> rewrite-argument)
>>"Return a variant of BS, a build system, that rewrites a bag's inputs by
>>  passing them through REWRITE, a procedure that takes an input tuplet and
>>  returns a \"rewritten\" input tuplet."
>> @@ -1442,9 +1442,10 @@ (define (build-system-with-package-mapping bs rewrite)
>>  (let ((lowered (apply lower args)))
>>(bag
>>  (inherit lowered)
>> -(build-inputs (map rewrite (bag-build-inputs lowered)))
>> -(host-inputs (map rewrite (bag-host-inputs lowered)))
>> -(target-inputs (map rewrite (bag-target-inputs lowered))
>> +(build-inputs (map rewrite-input (bag-build-inputs lowered)))
>> +(host-inputs (map rewrite-input (bag-host-inputs lowered)))
>> +(target-inputs (map rewrite-input (bag-target-inputs lowered)))
>> +(arguments (map rewrite-argument (bag-arguments lowered))
>
> Aah, now I understand.  :-)
>
> It’s indeed the case that arguments can capture references to packages
> that won’t be caught by ‘package-mapping’.  For instance, if you write:
>
>   (package
> …
> (arguments (list … #~(whatever #$coreutils
>
> … then ‘coreutils’ here cannot be replaced.
>
> To address this, the recommendation is to always add dependencies to
> input fields and to use self-references within arguments.  The example
> above should be written like this:
>
>   (package
> …
> (arguments
>  (list … #~(whatever #$(this-package-input "coreutils")
>
> It’s just a recommendation and one can perfectly ignore it, and I
> suppose that was the impetus for this patch.
>
> This is one of the things discussed while designing this change:
>
>   https://guix.gnu.org/en/blog/2021/the-big-change/
>   (search for “self-referential records”)
>
>   https://issues.guix.gnu.org/49169
>
> My take was and still is that it’s an acceptable limitation.  Packagers
> need to follow the guideline above if they want proper support for
> rewriting, ‘guix graph’, and other tools.
>
> WDYT?

But not all packages found in a bag come from inputs; they may be
provided as an argument to the build system (cmake, meson, qt, etc. all
allow for this).

-- 
Thanks,
Maxim

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Ulf,
>
> Ulf Herrman  skribis:
>
>> In short, the current approach of having the build-system lower
>> procedure leave the arguments mostly unchanged and letting the
>> bag->derivation procedure (the "bag builder") fill in lots of defaults
>> means that there are implicit inputs that cannot be touched at the
>> package level without adding special logic for every single build system
>> that does something like this.
>
> Could you share an example of what is fixed by these changes?

Ulf had mentioned the problems they were facing in the original post of
this issue:

> The problem with this approach is that it doesn't affect the bag
> arguments.  This means that packages passed in as arguments may still
> end up being used without being transformed.  Worse still, packages
> *not* passed in as arguments may end up being used *unless one is
> explicitly passed in as an argument*, as is the case with
> qt-build-system's #:qtbase argument.

Examples would be an Qt packages, or packages using #:meson
meson-variant.

Any build system accepting package as arguments are subject to this
problem, if I understand correctly.

I hope that helps,

-- 
Thanks,
Maxim

bug#64858: ~guix shell -C -f guix.scm …~ should not always need ~--rebuild-cache~ option to build the expected environment.

[Ludovic Courtès]

Hi Pierre-Henry,

Pierre-Henry Fröhring  skribis:

> $ guix shell -C -f guix.scm ripgrep fd coreutils emacs

[...]

> This very file (~pkgex.el.org~) is updated with this content then the
> package is
> built again.
>
> #+begin_example
> $ make build # equivalent to: guix build -f guix.scm
> …
> /gnu/store/8k18bghzcijbps8kix3wqp34x4smfc5l-pkgex-1
> #+end_example
>
>
> ** pkgex-1 -> /gnu/store/0yk3xz85…
>
> Unexpectedly, the package linked from within the container using the same
> command as above is not updated, we observe:

I don’t fully understand the setup, but I can at least explain what you
can expect.

When using ‘-f guix.scm’, ‘guix shell’ caches based on the mtime of
‘guix.scm’: if ‘guix.scm’ is modified, then the cache is invalidated,
otherwise the cache is considered up-to-date and used.

IIUC, you’re modifying a different file, ‘pkgex.el.org’.  ‘guix shell’
does not know about it and thus goes ahead and reuses the previous
value.

I guess the current behavior is good when you’re doing:

  guix shell -D -f guix.scm

which is the primary use case that comes to mind, but it’s inappropriate
when doing:

  guix shell -f guix.scm

in cases where ‘guix.scm’ defines a package with $PWD as its source.

I guess we could maybe try to special-case that in
‘profile-cached-gc-root’.

Ludo’.

bug#66380: Derivation pb with curl on aarch64-linux

[Ludovic Courtès]

Hello! :-)

Pierre Ramet  skribis:

> Please find the following backtrace obtained on Debian virtual machine 
> aarch64 (from a Mac M1 host) :

[...]

>>   message: "build of 
>> `/gnu/store/m819aix1w6b6x1dki7fhnizmy45fipw9-curl-8.3.0a.drv' failed"

AFAICS there are now substitutes for this particular derivation:

--8<---cut here---start->8---
$ guix build -n /gnu/store/m819aix1w6b6x1dki7fhnizmy45fipw9-curl-8.3.0a.drv
[…]
substituting /gnu/store/w9cclrdxlqrd3jjsi36kw4lzwcgydp75-curl-8.3.0a...
downloading from 
https://bordeaux.guix.gnu.org/nar/zstd/w9cclrdxlqrd3jjsi36kw4lzwcgydp75-curl-8.3.0a
 ...
 curl-8.3.0a  453KiB
 4.8MiB/s 
00:00 ▕██▏ 100.0%
--8<---cut here---end--->8---

However, you’re running Guix 1.3.0, which did not enable substitutes
from bordeaux.guix.gnu.org.  You could enable them or wait until they
show up on ci.guix.gnu.org.

In the meantime, there’s been another cURL security update anyway…

HTH,
Ludo’.

bug#57878: Emacs native compilation on startup can crash the system

[Ludovic Courtès]

Hello,

Konrad, Emacs team: is this bug still happening today?

  https://issues.guix.gnu.org/57878

TIA,
Ludo’.

Liliana Marie Prikler  skribis:

> Am Samstag, dem 17.09.2022 um 17:45 +0200 schrieb Konrad Hinsen:
>> Konrad Hinsen  writes:
>> 
>> > Here is a minimal containerized example that
>> > creates a process avalanche:
>> > 
>> >     guix shell -C emacs emacs-ido-completing-read+ \
>> >    -- emacs --batch --eval="(print load-path)"
>> 
>> I went through all my emacs packages. The only one that starts
>> the process avalanche is emacs-ido-completing-read+.
> I think you can prevent native-compilation entirely by setting no-
> native-compile to t in your early-init.el (I'm playing with the idea of
> doing this anyway, because I'm annoyed by the clutter that falls
> through the cracks).  That being said, this looks like a real breakage
> in the emacs-ido-completing-read package, does it not?  Should we add
> "no-native-compile" to some local variables?
>
> WDYT?

bug#65665: [PATCH] Really get all the implicit inputs.

[Simon Tournier]

Hi Maxim,

On Thu, 05 Oct 2023 at 22:36, Maxim Cournoyer  wrote:

> I've reviewed it, and it makes sense to me.  I'd like to apply it to the
> core-updates branch.  Core team, what say you?

Well, I am not sure to deeply understand some details to get all the
implications here, so I have nothing relevant to say.  For instance,
from my understanding, the core change is:

--8<---cut here---start->8---
+  (define (rewrite-argument arg)
+(match arg
+  ((? package? p)
+   (replace p))
+  ((? gexp-input? gi)
+   (gexp-input (rewrite-argument (gexp-input-thing gi))
+   (gexp-input-output gi)
+   #:native? (gexp-input-native? gi)))
+  ((? gexp? gxp)
+   (make-gexp (map rewrite-argument (gexp-references gxp))
+  (gexp-self-modules gxp)
+  (gexp-self-extensions gxp)
+  (gexp-proc gxp)
+  (%gexp-location gxp)))
+  ((lst ...)
+   (map rewrite-argument lst))
+  (_
+   arg)))
--8<---cut here---end--->8---

--8<---cut here---start->8---
+ (arguments
+  (match p
+   (($  _ _ _ _ args-proc)
+;; If we let ARGS-PROC be passed its original package,
+;; we somehow end up in an infinite (or maybe just
+;; exponential? Never seen it end...) loop.  Should
+;; probably figure out what's causing that at some
+;; point.
+(let ((args (args-proc this-package)))
+  (if deep?
+  (map rewrite-argument args)
+  args)
--8<---cut here---end--->8---

and I do not feel enough skilled here for getting the implications.
Equally for this kind of changes:

--8<---cut here---start->8---
- (arguments (strip-keyword-arguments private-keywords arguments)
+ (arguments
+  (substitute-keyword-arguments
+  (strip-keyword-arguments private-keywords arguments)
+((#:guile _ #t) guile))
--8<---cut here---end--->8---

Therefore, I trust other opinions or I need some time for diving and
filling some gaps.

Cheers,
simon

bug#66027: [PATCH v2] build: Add a commit-msg hook that embeds Change-Id in commit messages.

[Simon Tournier]

Hi,

On Mon, 09 Oct 2023 at 11:03, Maxim Cournoyer  wrote:

> +  particularly if a first version of your proposed
> +changes was already published.

Sorry if my English is not good enough.  Here, it is not clear for me
what “published” means.  Does it mean “tracked” by Debbugs?  If yes, I
would suggest:

particularly if a previous version of your proposed changes was
already submitted for review.

Cheers,
simon

bug#63331: Guile-GnuTLS/Git circular dependency

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> The longer-term solution is to add a “builtin:git-download” derivation
>> builder, just like we have “builtin:download”.  The implementation
>> should be relatively easy, but we’ll have to be able to deal with
>> daemons that lack this builtin possibly for several years.
>
> Patch available!
>
>   https://issues.guix.gnu.org/65866

This was applied in the meantime.  Closing!

bug#66305: Error with recursive git checkout

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Pushed as 762fdbdef52b4c17df578478cadc8655d56171a4.
>
> Now to update ‘guix’…

Done last week in 16fd9d6e3d626fc624c38cb3096331905a4161e4.

Closing!

bug#66419: Incorrect handling of -L flag on guix system commands

[Ludovic Courtès]

Hi,

Sergio Pastor Pérez  skribis:

> λ guix system build -L . bordercollie.scm 
> error: %useful-gnome-extensions: unbound variable
> hint: Did you forget `(use-modules (base-system))'?
>
> /gnu/store/gf21yc9ii1cfd3ki9hnn8ac5d65923ir-system

‘-L’ does more than setting ‘GUILE_LOAD_PATH’; it’s equivalent to ‘-L’
in other ‘guix’ commands, meaning that it changes ‘%package-search-path’
(like the ‘GUIX_PACKAGE_PATH’ environment variable).

In doing so, it causes package lookup by name to traverse all the .scm
files in $PWD in this case.  In other words, ‘guix system -L.’ ends up
loading ./*.scm.  This is probably the source of confusion.

HTH,
Ludo’.

bug#66472: Wrong ‘glibc-utf8-locales’ package used on GNU/Hurd

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hey!

> We discussed it briefly on IRC the other day: our packages get built on
> i586-gnu with the wrong ‘glibc-utf8-locales’ package (2.35 instead of
> 2.37), which causes Coreutils among others to fail to build:
>
> environment variable `GUIX_LOCPATH' set to 
> `/gnu/store/sq6w1nfi59askjfq6b1nqq6z8ld5zh1l-glibc-utf8-locales-2.35/lib/locale'
> phase `set-paths' succeeded after 0.0 seconds
> starting phase `install-locale'
> warning: failed to install 'en_US.utf8' locale: Invalid argument
> phase `install-locale' succeeded after 0.0 seconds
> […]
> starting phase `remove-tests'
> error: in phase 'remove-tests': uncaught exception:
> decoding-error "decode-char" "input decoding error" 1073741930 # tests/misc/ls-misc.pl 15> 
> phase `remove-tests' failed after 0.1 seconds
> […]
> builder for `/gnu/store/vvp0yxvyxsrwmmzli7dsxinr6p9ba3mj-coreutils-9.1.drv' 
> failed with exit code 1
>
> (This is from , made with
> commit cdbd81ce144f17644ceebd3d08723aa244696a05.)
>
> So we need a better fix than the local workaround in
> 21deb89e287b5821975544118bf137562a91d4e1.
>
> Thoughts?  Perhaps you’ve looked into it already?

Hmm.  I've briefly looked at this but failed to reproduce it.  I've
tried building coreutils, and coreutils-final in a childhurd created
from "a recent" hurd-team branch.

--8<---cut here---start->8---
root@guixydevel ~/src/guix/hurd-team [env]# ./pre-inst-env guix build 
--keep-failed -e '(@@ (gnu packages commencement) coreutils-final)' 
--without-tests=coreutils
[..]
environment variable `GUIX_LOCPATH' set to 
`/gnu/store/sq6w1nfi59askjfq6b1nqq6z8ld5zh1l-glibc-utf8-locales-2.35/lib/locale'
[..]
phase `unpack' succeeded after 10.4 seconds
starting phase `remove-tests'
phase `remove-tests' succeeded after 0.5 seconds
starting phase `bootstrap'
[..]
successfully built /gnu/store/zryfw42ayqpmk3s15a7s2cn231xsyjf0-coreutils-9.1.drv
/gnu/store/zbdppljxvvw3vc6lz64h5ic3fvihdr7q-coreutils-9.1
--8<---cut here---end--->8---

and similar for coreutils.

I've seen a similar error before trying to build guile-avahi a while ago
(before 21deb89e287b5821975544118bf137562a91d4e1) and it really puzzled
me.  The idea that a mismatch between GUIX_LOCPATH's glibc version for
locales (2.35) and the glibc actually used (2.37) would cause this
mysterious bug, is kind of a relief...

...although I've got no idea what causes this mismatch or how to fix it
;)

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Ludovic Courtès]

Ulf Herrman  skribis:

> -(define (build-system-with-package-mapping bs rewrite)
> +(define (build-system-with-package-mapping bs rewrite-input rewrite-argument)
>"Return a variant of BS, a build system, that rewrites a bag's inputs by
>  passing them through REWRITE, a procedure that takes an input tuplet and
>  returns a \"rewritten\" input tuplet."
> @@ -1442,9 +1442,10 @@ (define (build-system-with-package-mapping bs rewrite)
>  (let ((lowered (apply lower args)))
>(bag
>  (inherit lowered)
> -(build-inputs (map rewrite (bag-build-inputs lowered)))
> -(host-inputs (map rewrite (bag-host-inputs lowered)))
> -(target-inputs (map rewrite (bag-target-inputs lowered))
> +(build-inputs (map rewrite-input (bag-build-inputs lowered)))
> +(host-inputs (map rewrite-input (bag-host-inputs lowered)))
> +(target-inputs (map rewrite-input (bag-target-inputs lowered)))
> +(arguments (map rewrite-argument (bag-arguments lowered))

Aah, now I understand.  :-)

It’s indeed the case that arguments can capture references to packages
that won’t be caught by ‘package-mapping’.  For instance, if you write:

  (package
…
(arguments (list … #~(whatever #$coreutils

… then ‘coreutils’ here cannot be replaced.

To address this, the recommendation is to always add dependencies to
input fields and to use self-references within arguments.  The example
above should be written like this:

  (package
…
(arguments
 (list … #~(whatever #$(this-package-input "coreutils")

It’s just a recommendation and one can perfectly ignore it, and I
suppose that was the impetus for this patch.

This is one of the things discussed while designing this change:

  https://guix.gnu.org/en/blog/2021/the-big-change/
  (search for “self-referential records”)

  https://issues.guix.gnu.org/49169

My take was and still is that it’s an acceptable limitation.  Packagers
need to follow the guideline above if they want proper support for
rewriting, ‘guix graph’, and other tools.

WDYT?

Thanks,
Ludo’.

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Ludovic Courtès]

Hi Ulf,

Ulf Herrman  skribis:

> In short, the current approach of having the build-system lower
> procedure leave the arguments mostly unchanged and letting the
> bag->derivation procedure (the "bag builder") fill in lots of defaults
> means that there are implicit inputs that cannot be touched at the
> package level without adding special logic for every single build system
> that does something like this.

Could you share an example of what is fixed by these changes?

Let’s take ‘python-itsdangerous’ as an example.  It has zero inputs,
only implicit dependencies, yet I can do this:

--8<---cut here---start->8---
$ guix build python-itsdangerous -n
substitute: updating substitutes from 'http://192.168.1.48:8123'... 100.0%
0.0 MB would be downloaded:
  /gnu/store/yhvhrmqd5znjs7vsq8kc55nc3rkg4w6x-python-itsdangerous-2.0.1

$ guix build python-itsdangerous --with-input=python=python2 -n
The following derivations would be built:
  /gnu/store/b1hji2qzdiwfg2wx11l1fyjrgiy0f50v-python-itsdangerous-2.0.1.drv
  /gnu/store/5gibs6x75acc6j0g0rh8m66191l9wq12-python-wrapper-3.10.7.drv
0.1 MB would be downloaded:
  /gnu/store/b2qv97jbih850zn35b2j84n2acj079cv-itsdangerous-2.0.1.tar.gz

$ guix gc --references 
/gnu/store/5gibs6x75acc6j0g0rh8m66191l9wq12-python-wrapper-3.10.7.drv |grep 
python
/gnu/store/n0snl506x5bbs5c2496blh79yil3pf44-python2-2.7.18.drv
/gnu/store/whwrah24q7syyiqra16sm9mjvdxld1pv-python-wrapper-3.10.7-builder
--8<---cut here---end--->8---

‘python’ above is an implicit dependency, yet it was suitably replaced
by ‘--with-input’.

In what cases does ‘package-mapping #:deep? #t’ miss implicit inputs?

Thanks,
Ludo’.

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Ludovic Courtès]

Hi,

Ulf Herrman  skribis:

> I've also been using this patch, which rebinds `this-package' within
> package variants to refer instead to the variant rather than the
> original.

Could you send it as a separate issue?

(I think I once reported a bug for this issue, but I can’t find it.)

Ludo’.

bug#66254: "guix --version | head -1" crashes most of the time

[Clément Lassieur]

Simon Tournier  writes:

> Hi Clément,

Hey Simon,

[...]

> Anyway.  The issue is from leave-on-EPIPE.  This patch fixes the issue,
> I guess.
>
> diff --git a/guix/ui.scm b/guix/ui.scm
> index 6f2d4fe245..507bc67f1d 100644
> --- a/guix/ui.scm
> +++ b/guix/ui.scm
> @@ -2309,7 +2309,7 @@ (define (run-guix . args)
>((or ("-h") ("--help"))
> (leave-on-EPIPE (show-guix-help)))
>((or ("-V") ("--version"))
> -   (show-version-and-exit "guix"))
> +   (leave-on-EPIPE (show-version-and-exit "guix")))
>(((? option? o) args ...)
> (format (current-error-port)
> (G_ "guix: unrecognized option '~a'~%") o)
>
>
> Does it fix the issue?

Yes indeed!  Thanks :)

Clément

bug#66358: Can't import package using archive command

[Simon Tournier]

Hi,

On Mon, 09 Oct 2023 at 14:25, Tobias Geerinckx-Rice via Bug reports for GNU 
Guix  wrote:

> I think it would be less surprising if these ‘single, mutually exclusive 
> actions’ should always be (sub)subcommands, e.g., ‘guix archive import’, 
> ‘guix archive authorize’, …

I am proposing to error for ambiguous cases as,

$ ./pre-inst-env guix archive --import --authorize hello < /tmp/hello.nar
guix archive: error: ambiguous options: "authorize" with "import"

See attached patch.  WDYT?

Please note that it errors when at least 2 options are ambiguous.  So if
there is 3, you get the “two first ones“.

--8<---cut here---start->8---
$ ./pre-inst-env guix archive --import --export --authorize hello < 
/tmp/hello.nar
guix archive: error: ambiguous options: "export" with "import"
--8<---cut here---end--->8---

Well, if the idea is fine, then maybe it could be worth to add one or
two sentences in the manual.

Cheers,
simon

>From 673afe0384427bc92fa47870e1dfa092e04aec0b Mon Sep 17 00:00:00 2001
Message-Id: <673afe0384427bc92fa47870e1dfa092e04aec0b.1697066456.git.zimon.touto...@gmail.com>
From: Simon Tournier 
Date: Thu, 12 Oct 2023 01:16:53 +0200
Subject: [PATCH] scripts: archive: Check compatibility of command line
 options.

Fixes .
Reported by Perry, Daniel J .

* guix/scripts/archive.scm (compatible-option): New procedure.
(%options): Use it.
---
 guix/scripts/archive.scm | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/guix/scripts/archive.scm b/guix/scripts/archive.scm
index e32f22ec99..65932ae152 100644
--- a/guix/scripts/archive.scm
+++ b/guix/scripts/archive.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2019, 2020, 2021 Ludovic Courtès 
 ;;; Copyright © 2020 Tobias Geerinckx-Rice 
+;;; Copyright © 2023 Simon Tournier 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -115,6 +116,18 @@ (define %key-generation-parameters
   "(genkey (ecdsa (curve Ed25519) (flags rfc6979)))"
   "(genkey (rsa (nbits 4:4096)))"))
 
+(define (compatible-option action result other-actions)
+  "Return the RESULT if ACTION is compatible with the list of OTHER-ACTIONS."
+  (let ((other-action (fold (lambda (other answer)
+  (if (assoc-ref result (string->symbol other))
+  other
+  answer))
+#f
+other-actions)))
+(if other-action
+(leave (G_ "ambiguous options: ~s with ~s~%") action other-action)
+(alist-cons (string->symbol action) #t result
+
 (define %options
   ;; Specifications of the command-line options.
   (cons* (option '(#\h "help") #f #f
@@ -126,13 +139,13 @@ (define %options
(show-version-and-exit "guix archive")))
  (option '("export") #f #f
  (lambda (opt name arg result)
-   (alist-cons 'export #t result)))
+   (compatible-option "export" result (list "import" "authorize"
  (option '(#\r "recursive") #f #f
  (lambda (opt name arg result)
(alist-cons 'export-recursive? #t result)))
  (option '("import") #f #f
  (lambda (opt name arg result)
-   (alist-cons 'import #t result)))
+   (compatible-option "import" result (list "export" "authorize"
  (option '("missing") #f #f
  (lambda (opt name arg result)
(alist-cons 'missing #t result)))
@@ -158,7 +171,7 @@ (define %options
   (error-string err))
  (option '("authorize") #f #f
  (lambda (opt name arg result)
-   (alist-cons 'authorize #t result)))
+   (compatible-option "authorize" result (list "import" "export"
 
  (option '(#\S "source") #f #f
  (lambda (opt name arg result)

base-commit: 0024ef320eed89468369ece3df05064a2afaabd1
-- 
2.38.1

bug#66254: "guix --version | head -1" crashes most of the time

[Simon Tournier]

Hi Clément,

On Thu, 28 Sep 2023 at 12:20, Clément Lassieur  wrote:
>> guix --version | cat | head -1
> works

Not for me.

--8<---cut here---start->8---
$ guix --version | cat | head -1
guix (GNU Guix) 6113e0529d61df7425f64e30a6bf77f7cfdfe5a5
Backtrace:
   3 (primitive-load "/home/simon/.config/guix/current/bin/guix")
In guix/ui.scm:
   2312:7  2 (run-guix . _)
563:2  1 (show-version-and-exit _)
In unknown file:
   0 (display "License GPLv3+: GNU GPL version 3 or later 
\nThis is free software: you are free to 
change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by 
law.\n" #)

ERROR: In procedure display:
In procedure fport_write: Broken pipe
--8<---cut here---end--->8---

>> guix --version | head -1
> crashes most of the time

And note that:

--8<---cut here---start->8---
$ guix --version | head -2
guix (GNU Guix) 6113e0529d61df7425f64e30a6bf77f7cfdfe5a5
Copyright (C) 2023 the Guix authors
--8<---cut here---end--->8---

Well, I do not know if it is related, please note:

--8<---cut here---start->8---
(define* (show-version-and-exit #:optional (command (car (command-line
  "Display version information for COMMAND and `(exit 0)'."
  (simple-format #t "~a (~a) ~a~%"
 command %guix-package-name %guix-version)
  (format #t "Copyright ~a 2023 ~a"
--8<---cut here---end--->8---

Anyway.  The issue is from leave-on-EPIPE.  This patch fixes the issue,
I guess.

diff --git a/guix/ui.scm b/guix/ui.scm
index 6f2d4fe245..507bc67f1d 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -2309,7 +2309,7 @@ (define (run-guix . args)
   ((or ("-h") ("--help"))
(leave-on-EPIPE (show-guix-help)))
   ((or ("-V") ("--version"))
-   (show-version-and-exit "guix"))
+   (leave-on-EPIPE (show-version-and-exit "guix")))
   (((? option? o) args ...)
(format (current-error-port)
(G_ "guix: unrecognized option '~a'~%") o)

Does it fix the issue?

Cheers,
simon

bug#66297: guix-daemon not starting after boot

[Ludovic Courtès]

Hi Sharlatan,

Sharlatan Hellseher  skribis:

> I think I just get used to kick it manually and forgot to replay on
> this issue =)

Ouch.  :-)

>  sudo grep -i "shepherd\|herd" /var/log/messages  | tail
> grep: /var/log/messages: binary file matches

Looks like grep didn’t actually output matches, did it?

Could you screen the file, starting from the latest boot, in search of
references to guix-daemon?

> There this no track of guix-daemon was starting in herd log
>
> herd log | grep daemon
> 10 Oct 2023 00:03:30service upower-daemon is being started
> 10 Oct 2023 00:03:30service upower-daemon is running
> 10 Oct 2023 00:03:30service ssh-daemon is being started
> 10 Oct 2023 00:03:30service ssh-daemon is running

What about ‘sudo herd status’?  Does guix-daemon show up there?

Also, could you check:

  guix system shepherd-graph /run/current-system/configuration.scm | \
guix shell xdot -- xdot -

to make sure guix-daemon actually is in your config, to be 100% sure?

Thanks,
Ludo’.

bug#65665: [PATCH] Really get all the implicit inputs.

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Ulf Herrman  writes:
>
>> This patch series causes package-mapping to recurse into package and bag
>> arguments when #:deep? #t is given.  It also recurses into gexps and
>> gexp inputs in search of packages to devour.  It also ensures that build
>> systems leave all of their implicit package arguments in the bag
>> arguments, ready to be found by package-mapping.  It also fixes a couple
>> build system errors I came across while modifying 40+ build systems and
>> testing a deep package transformation.
>
> Nice series!
>
> I've reviewed it, and it makes sense to me.  I'd like to apply it to the
> core-updates branch.  Core team, what say you?

Sorry for the delay, I’ll provide feedback within a couple of days.

Ludo’.