Until now these two actions were silently ignored.
* guix/scripts/home.scm (show-help, %options): Add "--graph-backend".
(%default-options): Add 'graph-backend' key.
(export-extension-graph, export-shepherd-graph): New procedures.
(perform-action): Add #:graph-backend parameter. Add cases for the
'extension-graph' and 'shepherd-graph' actions.
(process-action): Pass #:graph-backend to 'perform-action'.
* guix/scripts/system.scm (service-node-type)
(shepherd-service-node-type): Export
* tests/guix-home.sh: Add tests.
* doc/guix.texi (Invoking guix home): Document it.
Without this it is apparently impossible to mount file systems with the
feature, which apparently some distributions do by default now.
podiki[m]> I have an sdcard that was formatted with ext4 casefold
[by Arch Linux], cannot be mounted
* gnu/packages/aux-files/linux-libre/5.10-arm.conf,
gnu/packages/aux-files/linux-libre/5.10-arm64.conf,
gnu/packages/aux-files/linux-libre/5.10-i686.conf,
gnu/packages/aux-files/linux-libre/5.10-x86_64.conf,
gnu/packages/aux-files/linux-libre/5.15-arm.conf,
gnu/packages/aux-files/linux-libre/5.15-arm64.conf,
gnu/packages/aux-files/linux-libre/5.15-i686.conf,
gnu/packages/aux-files/linux-libre/5.15-x86_64.conf,
gnu/packages/aux-files/linux-libre/5.16-arm.conf,
gnu/packages/aux-files/linux-libre/5.16-arm64.conf,
gnu/packages/aux-files/linux-libre/5.16-i686.conf,
gnu/packages/aux-files/linux-libre/5.16-x86_64.conf,
gnu/packages/aux-files/linux-libre/5.4-arm.conf,
gnu/packages/aux-files/linux-libre/5.4-arm64.conf,
gnu/packages/aux-files/linux-libre/5.4-i686.conf,
gnu/packages/aux-files/linux-libre/5.4-x86_64.conf:
Set CONFIG_UNICODE=y.
This reverts commit 0a9e82b430, which didn't end
up fixing anything. The problem was elsewhere; namely, using
'operating-system-services' instead of 'operating-system-user-services'.
Attempting to use the 'nfs-service-type' as part of a computed
operating-system definition, the following exception would be thrown:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
1. &ambiguous-target-service-error:
service: #<<service> type: #<service-type rpcbind 7f7529853780> value: #<<rpcbind-configuration> rpcbind: #<package rpcbind@1.2.6 gnu/packages/onc-rpc.scm:87 7f75389e78f0> warm-start?: #t>>
target-type: #<service-type shepherd-root 7f7529396080>
2. &message: "more than one target service of type 'shepherd-root'"
The problem was that the rpcbind shepherd-service object was dynamically
instantiated every time the rpcbind-service-type would be called, causing
multiple objects in some situations, resulting in the above condition.
* gnu/services/nfs.scm (rpcbind-service-type): Refactor and adjust in a way to
extract...
(rpcbind-shepherd-service): ... this new procedure.
* gnu/packages/lisp-xyz.scm (sbcl-envy): Update to 26a7faa.
[native-inputs]: Uncomment test inputs and use new style.
[arguments]: Add 'asd-systems' parameter, Remove 'fix-tests' phase.
Signed-off-by: Guillaume Le Vaillant <glv@posteo.net>
Previous to this commit, we added a --with-newlib configure flag to
cross-gcc when cross-newlib?, but cross-newlib? is true only when
target-mingw?.
It turns out that specifying --with-newlib disables the
GLIBCXX_CROSSCONFIG check, which is used to detect
_GLIBCXX_HAVE__WFOPEN, which is required in C++17 std::filesystem for
mingw-w64 systems.
Additional context: In gnu/packages/embedded.scm, --with-newlib is
specified explicitly when we're actually using newlib, which seems like
the correct way of handling it.
Situation in other distros:
- Debian's gcc-mingw-w64 doesn't specify --with-newlib
- Fedora's mingw64-gcc-c++ explicitly specifies --without-newlib
Chesterton's fence: Chatting with janneke, who originally added this
mechanism, reveals that this flag is not only no longer required, but
also that removing it doesn't break his guile-mingw builds. See IRC logs
of #guix for 2022-02-15.
* gnu/packages/cross-base.scm (cross-gcc-arguments): Don't check for and
specify --with-newlib.
(cross-libc): Check for mingw and use mingw-w64 directly.
(cross-newlib?): Remove, unexport.
(native-libc): Remove.
