bug#71160: --fallback and (fallback #t) do not apply when receiving a corrupt nar
Richard Sent writes: > Trying to pass --fallback on the command line has no effect, even though > both the documentation and [1] imply that should work. This issue might have some spiciness to it. I have two machines with identical guix commits and --fallback works on one but not the other. --8<---cut here---start->8--- # Failing machine: root@lifeline ~# guix describe Generation 2May 25 2024 21:03:46(current) guix 94c8cec repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 94c8cec99969fe9f65777637fde1f05e1c576a3f # Good machine: Generation 3May 25 2024 21:58:15(current) guix 94c8cec repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 94c8cec99969fe9f65777637fde1f05e1c576a3f --8<---cut here---end--->8--- On the failing machine, I get an error like this: --8<---cut here---start->8--- root@lifeline ~# guix build linux-libre-arm64-generic --system=aarch64-linux --fallback # snip downloading from https://bordeaux.guix.gnu.org/nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz ... linux-libre-6.8.10-guix.tar.xz 136.5MiB 19.0MiB/s 00:07 ▕█▉▏ 99.9%guix substitute: error: corrupt input while restoring '/gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz' from # substitution of /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz failed guix build: error: corrupt input while restoring archive from # root@lifeline ~# logout --8<---cut here---end--->8--- whereas on the good machine: --8<---cut here---start->8--- root@gibraltar ~# guix build linux-libre-arm64-generic --system=aarch64-linux --fallback # snip downloading from https://bordeaux.guix.gnu.org/nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz ... linux-libre-6.8.10-guix.tar.xz 136.5MiB 19.6MiB/s 00:07 ▕█▊▏ 98.8%guix substitute: error: corrupt input while restoring '/gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz' from # substitution of /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz failed building /gnu/store/ny56fdcig9cd9bd3pssmlraz2c1q10q8-linux-libre-6.8.10-guix.tar.xz.drv... --8<---cut here---end--->8--- I thought perhaps there was some hyper-odd race condition going on here (lifeline is consistently at a higher percent than gibraltar when the error is detected), but I just had a outlier that seems to disprove that, where lifeline had the same error with a 97.2% download progress bar. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71139: herd unresponsive on new 1.4.0 install
> Perhaps we should consider using Fibers 1.1 for all architectures? This > problem occurred on a x86-64 machine. This issue reverted Fibers 1.3 > just for ARM: > https://issues.guix.gnu.org/64966#6 With https://issues.guix.gnu.org/70892#3 Fibers is also reverted to 1.1 on RISC-V 64. -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#66248: ghc: stale versions
Hi, > The latest GHC version available in the main channel is 9.2.5, released > in November 2022. Latest 9.2.x is now 9.2.8. I would also like to > mention that no GHC versions matching 9.4.x and 9.6.x are available either. I’m updating GHC to 9.2.8 on the haskell-team branch, 9.4.4 is packaged as ghc-next and there’s a patch-set to bump to 9.4.8 and add 9.6 here: https://issues.guix.gnu.org/67921#8 Lars
bug#71193: Shepherd fails to start a system when given an incorrect form to the start field of any service
Hey Guix,
I'm facing a pretty annoying Shepherd 0.10.4 bug.
If a service start script gets provided an incorrect form, such as an
empty quoted list, Shepherd hangs during its early startup and bricks
the overall Guix system.
I think the following snippet is a good minimal reproducer for this. Add
this service to a guix system configuration:
--8<---cut here---start->8---
(simple-service
'shepherd-bug-repro
shepherd-root-service-type
(list (shepherd-service
(documentation "shepherd hang minimal repro")
(provision '(shepherd-bug-repro))
(requirement '())
(start #~('())
u--8<---cut here---end--->8---
⚠ DO NOT BOOT ON A CRITICAL SYSTEM WITH THIS SERVICE, IT'LL BRICK IT ⚠
You can create a VM for this system and start it. The VM hangs after the
log line "creating /etc/machine-id...", before any shepherd service gets
started.
You get the same behaviour if you end up booting by misfortune a "real"
system having this service.
Instead of having the whole system to freeze, I'd expect shepherd to
fail the particular service having an incorrect start form.
I'm not sure what's happening here. I did not manage to diagnose this further,
the shepherd does not seem to be super chatty at this stage of the boot.
Tested on Shepherd 0.10.4 with the Guix revision
c5e63e19ac672f9e63fc8ee98fa9a16f978ce19c.
bug#71011: [BUG] Fail to buidl latest kitty
I believe go-github-com-alecthomas-chroma-v2-13 is being compiled at the moment of failure no? I am new to go and it~s compilation, perhaps there are no embadable files in the embedded directory in chroma/lexers/ because they all produce the same problem that abap.xml does. Perhaps it is due to permissions, I could not find the "cannot embed irregular file" error quickly from a search engine search but will look again.
bug#71169: emacs-minimal: substituting "find" breaks mpc.el
Currently, the string "find" is substituted with the path to the find executable in mpc.el. The correct value in this file is the literal string "find", because it refers to an MPD command, not the program. $ guix describe Generation 15 May 23 2024 14:20:47(current) guix aeba484 repository URL:https://git.savannah.gnu.org/git/guix.git branch: master commit: aeba4849b42b4d3ac75341ac4b61843c1fe48181 nonguix 34935b4 repository URL:https://gitlab.com/nonguix/nonguix branch: master commit: 34935b49ae20d236b0fc89943f0b1d0d5dea3a33
bug#71174: libb2 fails to build during cross-compilation
Hi!
The package libb2 in `(gnu packages crypto)` fails during
cross-compilation from `x86_64-linux-gn` to `aarch64-linux-gnu`, but
possible more combinations are broken.
Steps to reproduce:
> git log --oneline HEAD^..HEAD
> 9901416233 (origin/master, origin/HEAD) gnu: ctl: Update to 1.5.3.
> ./pre-inst-env guix build libb2 --system=x86_64-linux >
> --target=aarch64-linux-gnu --no-substitutes --no-grafts
> [...]
> checking for objdir... .libs
> checking if aarch64-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no
> checking for aarch64-linux-gnu-gcc option to produce PIC... -fPIC -DPIC
> checking if aarch64-linux-gnu-gcc PIC flag -fPIC -DPIC works... yes
> checking if aarch64-linux-gnu-gcc static flag -static works... yes
> checking if aarch64-linux-gnu-gcc supports -c -o file.o... yes
> checking if aarch64-linux-gnu-gcc supports -c -o file.o... (cached) yes
> checking whether the aarch64-linux-gnu-gcc linker
> (/gnu/store/kh7kl57h5i3vzx9hbbairnkkgnx7kf61-gcc-cross-aarch64-linux-gnu-11.3.0/libexec/gcc/aarch64-linux-gnu/ld)
> supports shared libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> checking whether C compiler accepts -O3... yes
> checking whether C compiler accepts -msse2... no
> configure: error: Compiler does not know -msse2.
> error: in phase 'configure': uncaught exception:
> %exception #< program:
> "/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash"
> arguments: ("./configure" "CC_FOR_BUILD=gcc"
> "CONFIG_SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash"
>
> "SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash"
> "--prefix=/gnu/store/5cy4lw70ilgwbrmav12xli0lyqzwvmk5-libb2-0.98.1"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu"
> "--host=aarch64-linux-gnu" "--enable-fat" "--disable-native") exit-status: 1
> term-signal: #f stop-signal: #f>
> phase `configure' failed after 1.2 seconds
> command
> "/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash"
> "./configure" "CC_FOR_BUILD=gcc"
> "CONFIG_SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash"
>
> "SHELL=/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/bash"
> "--prefix=/gnu/store/5cy4lw70ilgwbrmav12xli0lyqzwvmk5-libb2-0.98.1"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu"
> "--host=aarch64-linux-gnu" "--enable-fat" "--disable-native" failed with
> status 1
> builder for `/gnu/store/rlhm80fld1h2xszn3yh7x5fvr295x6qh-libb2-0.98.1.drv'
> failed with exit code 1
> build of /gnu/store/rlhm80fld1h2xszn3yh7x5fvr295x6qh-libb2-0.98.1.drv failed
> Could not find build log for
> '/gnu/store/rlhm80fld1h2xszn3yh7x5fvr295x6qh-libb2-0.98.1.drv'.
> guix build: error: build of >
> `/gnu/store/rlhm80fld1h2xszn3yh7x5fvr295x6qh-libb2-0.98.1.drv' failed
Root-cause:
The `configure-flags` in the package definition of libb2 are broken for
cross-compilation.
> `(#:configure-flags
>(list
> ,@(if (any (cute string-prefix? <> (or (%current-system)
>(%current-target-system)))
>'("x86_64" "i686"))
> ;; fat only checks for Intel optimisations
> '("--enable-fat")
> '())
> "--disable-native"))
Shot-circuit evaluation of the `or` operator leads to enabling of `fat`
as long as `%current-system` is set to `x86_64/i686` regardless of the
value of `%current-target-system`. If `%current-target-system` is set
for example to the `aarch64-linux-gnu` triplet, `--enable-fat` is added
to the configure flags which in turn will break compilation. I am not
entirley sure, what `enable-fat` does. From my understanding this flag
enables fat binaries (or multiarchitecture binaries), which seems to
require the `sse2` instruction set. The cross compile toolchain for
aarch64-linux-gnu (and mostlikey other toolchains as well) does not
support this instruction set.
As a quick workaround, i came up with the following patch:
> `(#:configure-flags
>(list
> ,@(let ((check-x86 (lambda (triplet) (any (cute string-prefix? <>
> triplet) '("x86_64" "i868")
> (if (%current-target-system)
> (if (check-x86 (%current-target-system))
> '("--enable-fat")
> '())
> (if (check-x86 (%current-system))
> '("--enable-fat")
> '(
> "--disable-native"))
This enables fat binaries if the target system is set to `x86_64/i868`
regardless of the value of
bug#71011: [BUG] Fail to buidl latest kitty
Ok this works now but needs a lot of cleaning One issue was that a dependant package `x-exp` needed to be compiled by go-1.22 It would probably be good to build them all off 1.22 I apply-ed the patch you sent The function to make the symlink-s real would be better off as build utils or in some other standard location that can be pulled in Perhaps they could be real-ise-ed in the go build system `setup-go-environment` which is where they are created There are some runtime dependency-s such as libcanberra that are loaded with dlopen, they have been pointed to in `( invoke "python" "setup.py" ...)`, perhaps there is some guix mechanism to give kitty a custom environment which allows auto detection with no absolute path. (define-module (pantheon packages terminals) #:use-module ((guix licenses) #:prefix license:) #:use-module ((guix build utils) #:select (alist-replace)) #:use-module (guix build-system cargo) #:use-module (guix build-system cmake) #:use-module (guix build-system gnu) #:use-module (guix build-system glib-or-gtk) #:use-module (guix build-system go) #:use-module (guix build-system meson) #:use-module (guix build-system pyproject) #:use-module (guix build-system python) #:use-module (guix download) #:use-module (guix git-download) #:use-module (guix gexp) #:use-module (guix packages) #:use-module (guix utils) #:use-module (gnu packages) #:use-module (gnu packages autotools) #:use-module (gnu packages assembly) #:use-module (gnu packages base) #:use-module (gnu packages bash) #:use-module (gnu packages check) #:use-module (gnu packages compression) #:use-module (gnu packages crates-io) #:use-module (gnu packages crates-graphics) #:use-module (gnu packages crypto) #:use-module (gnu packages curl) #:use-module (gnu packages dlang) #:use-module (gnu packages digest) #:use-module (gnu packages docbook) #:use-module (gnu packages fontutils) #:use-module (gnu packages freedesktop) #:use-module (gnu packages fribidi) #:use-module (gnu packages gettext) #:use-module (gnu packages ghostscript) #:use-module (gnu packages gl) #:use-module (gnu packages glib) #:use-module (gnu packages gnome) #:use-module (gnu packages golang) #:use-module (gnu packages golang-build) #:use-module (gnu packages golang-check) #:use-module (gnu packages golang-xyz) #:use-module (gnu packages gtk) #:use-module (gnu packages image) #:use-module (gnu packages libcanberra) #:use-module (gnu packages libevent) #:use-module (gnu packages libunwind) #:use-module (gnu packages linux) #:use-module (gnu packages man) #:use-module (gnu packages ncurses) #:use-module (gnu packages pcre) #:use-module (gnu packages perl) #:use-module (gnu packages perl-check) #:use-module (gnu packages pkg-config) #:use-module (gnu packages popt) #:use-module (gnu packages protobuf) #:use-module (gnu packages python) #:use-module (gnu packages python-build) #:use-module (gnu packages python-check) #:use-module (gnu packages python-xyz) #:use-module (gnu packages qt) #:use-module (gnu packages serialization) #:use-module (gnu packages sphinx) #:use-module (gnu packages ssh) #:use-module (gnu packages textutils) #:use-module (gnu packages tls) #:use-module (gnu packages version-control) #:use-module (gnu packages xdisorg) #:use-module (gnu packages xml) #:use-module (gnu packages xorg) #:use-module (srfi srfi-26)) (define-public python-furo (package (name "python-furo") (version "2024.5.6") (source (origin (method url-fetch) (uri (pypi-uri "furo" version)) (sha256 (base32 "02rb7mdh8nglw5hjzj8v7pfrc08whfs3411mhfwcpg2yc2k0bwl1" (build-system pyproject-build-system) (propagated-inputs (list python-beautifulsoup4 python-pygments python-sphinx python-sphinx-basic-ng python-sphinx-theme-builder )) (home-page "") (synopsis "A clean customisable Sphinx documentation theme.") (description "This package provides a clean customisable Sphinx documentation theme.") (license #f))) (define-public python-sphinx-inline-tabs (package (name "python-sphinx-inline-tabs") (version "2023.4.21") (source (origin (method url-fetch) (uri (pypi-uri "sphinx_inline_tabs" version)) (sha256 (base32 "1g5yhdk208i8maippnbnijd1knpai809wl3cbwzqy59cc0zz3wjx" (build-system pyproject-build-system) (propagated-inputs (list ;python-furo python-myst-parser python-flit-core python-pytest python-pytest-cov python-pytest-xdist python-sphinx)) ( arguments ( list #:tests? #f)) (home-page "https://github.com/pradyunsg/sphinx-inline-tabs;) (synopsis "Add inline tabbed content to your
bug#71099: retried_compile_better_bug_report_here
Retried the same compile, it's much more brief error report is attached. retried_compile_better_bug_report_here Description: Binary data
bug#71197: visionfive2-barebones-os fails to boot Linux from MMC2
Z572 writes: > hello!, can you try boot from mmc1, and do setenv and saveenv on mmc1 > uboot, then reset and boot from mmc2? Hi! Sorry for not mentioning that. Those setenv + saveenv commands were run with MMC1 (SPI) boot selected, not MMC2. I confirmed the printenv fdtfile output matched starfive/jh7110-starfive-visionfive-2-v1.3b.dtb on both MMC1 and MMC2. However, I ran the commands again just now and suddenly it can boot from MMC2. I have no idea idea what could have happened (Originally entered from MMC1, no typos, and printenv matched the expected values after rebooting), but it boots now. Very strange, but seemingly the issue is resolved. I wonder if anyone else will encounter it in the future. Thanks! -- Take it easy, Richard Sent Making my computer weirder one commit at a time.
bug#71144: Interactive prompt opened upon shepherd config file error
Christopher Baines skribis: > That looks good to me, the "Arrange to spawn a REPL if something goes > wrong" comment needs removing/updating, but that's the only thing I > spotted. Cool. I updated the comment and pushed it as cca25a67693bb68a1884a081b415a43fad1e8641. Thanks! Ludo’.
bug#70826: luks-device-mapping-with-options breaks bootloader
That unfortunately doesn't fix the problem, `luks-device-mapping-with-options` is a routine that returns the `mapped-device-kind` so it won't check by equality. A possible solution is to check whether the `mapped-device-kind-close` routines are the same as these are shared. diff --git a/gnu/system.scm b/gnu/system.scm index cb6e719ca6..b564bf3788 100644 --- a/gnu/system.scm +++ b/gnu/system.scm @@ -661,10 +661,12 @@ (define (operating-system-boot-mapped-devices os) (define operating-system-bootloader-crypto-devices (mlambdaq (os);to avoid duplicated output "Return the sources of the LUKS mapped devices specified by UUID." +(define (luks-device? m) + (eq? (mapped-device-kind-close (mapped-device-type m)) + (mapped-device-kind-close luks-device-mapping))) + ;; XXX: Device ordering is important, we trust the returned one. -(let* ((luks-devices (filter (lambda (m) - (eq? luks-device-mapping -(mapped-device-type m))) +(let* ((luks-devices (filter luks-device? (operating-system-boot-mapped-devices os))) (uuid-crypto-devices non-uuid-crypto-devices (partition (compose uuid? mapped-device-source) (I apologize if my email client is adding line wraps to the diffs, I will look into it after sending this) I tried to implement this initially but it didn't work on my previous attempt so I abandoned trying to submit a patch, but this version does do the trick even if it seems inelegant. On 2024-05-25 5:47 a.m., Ludovic Courtès wrote: Hi, Tadhg McDonald-Jensen skribis: using the `luks-device-mapping-with-options` mapped device type defined in (gnu system mapped-devices) causes grub or other bootloaders to not properly attempt to mount the encrypted drive. This is caused by the commit 39a9404 which identifies luks mapped devices by checking if the type is equal to `luks-device-mapping`, so by using a different routine that is a proxy to that one it doesn't forward it to grub in the store-crypto-devices list. Ouch, indeed. The immediate fix is: diff --git a/gnu/system.scm b/gnu/system.scm index c76f4d7c502..bb851b1b75f 100644 --- a/gnu/system.scm +++ b/gnu/system.scm @@ -667,10 +667,13 @@ (define (operating-system-boot-mapped-devices os) (define operating-system-bootloader-crypto-devices (mlambdaq (os);to avoid duplicated output "Return the sources of the LUKS mapped devices specified by UUID." +(define (luks-device? m) + (memq (mapped-device-type m) +(list luks-device-mapping-with-options + luks-device-mapping))) + ;; XXX: Device ordering is important, we trust the returned one. -(let* ((luks-devices (filter (lambda (m) - (eq? luks-device-mapping -(mapped-device-type m))) +(let* ((luks-devices (filter luks-device? (operating-system-boot-mapped-devices os))) (uuid-crypto-devices non-uuid-crypto-devices (partition (compose uuid? mapped-device-source) Not ideal, but it fixes the problem. I’ll go ahead with this patch if there are no objections. Thanks! Ludo’.
bug#71154: slim: Two regressions on v.1.4.1
André Batista writes: > Hi Guix, > > I've found two regressions after upgrading to v. 1.4.1 of slim. > > The first one is that it is no longer possible to use a secondary monitor > with it. If it is connected at the same time as a the primary one, only > the later gets to show the slim greater. If the primary one is disabled > via kernel command line (eg. "video=LVDS-1:d"), slim does not start and > the xorg-server crashes. Shepherd keeps trying to restart it to no avail. > > Curiously enough the changelog for the current version mentions that > there has been some change to "how/when the pseudo-root window is created > and removed, in preparation for handling multiple monitors"[*]. I, for one, > have been using multiple monitors without issue until now. maybe you can report it to upstream? > > The second regression is more subtle and annoying. After logging in with > one account, sometimes, in what appears to be related to have used any > gtk application, the user session is not properly terminated on logout > and herd looses track of xorg-server. If one tries to stop it with herd, > the session remais alive and there is only one bit on slim.log: I'm not exactly familiar with shepherd, maybe replacing fork+exec-command with make-forkexec-constructor would solve this problem?. > > 'WaitForServer: Not seen SigUSR1 from Xserver' > > and nothing useful on Xorg.log. > > Only by manually killing the xorg process, I've been able to get back > to a sane state again. > > Any thoughts? We can revert this commit or add a slim-1.4.0 package? > > For now I have reverted the upgrade to its current upstream version. > > 1. https://sourceforge.net/projects/slim-fork/files/ signature.asc Description: PGP signature
bug#71197: visionfive2-barebones-os fails to boot Linux from MMC2
Richard Sent writes: > Hi Guix! > > When generating a VisionFive2 system image via $ guix system image > gnu/system/images/visionfive2.scm --no-grafts --target=riscv64-linux-gnu > and attempting to boot from MMC2, the SD card U-boot fails to boot > Linux. > > (Pretty sure --target= is gratuitous but I kept it.) > > This occurs despite setting and saving the ftdfile variable as described > in the instructions: > > --8<---cut here---start->8--- > ;;; Commentary: > ;;; > ;;; VisionFive2 can boot from MMC1 (SPI flash) or MMC2 (SD card) selected > ;;; by DIP switches MSEL[1:0], you may want boot from MMC2 to use the > ;;; U-Boot from Guix System instead of the vendor U-Boot in MMC1. Before > ;;; doing so, make sure you have a correct 'fdtfile' in the environment: > ;;; > ;;; uboot> setenv fdtfile starfive/jh7110-starfive-visionfive-2-v1.3b.dtb > ;;; uboot> saveenv > --8<---cut here---end--->8--- > > --8<---cut here---start->8--- > # Confirming the variable is set after reboot using the U-boot console: > StarFive # printenv fdtfile > fdtfile=starfive/jh7110-starfive-visionfive-2-v1.3b.dtb > --8<---cut here---end--->8--- hello!, can you try boot from mmc1, and do setenv and saveenv on mmc1 uboot, then reset and boot from mmc2? > > The system /does/ boot into Linux if SPI Flash is selected as a boot > source, although since the onboard bootloader is outdated the system > only sees 4 GiB of RAM [1]. > > Attached is the full failing boot log. Here are the highlights: > > --8<---cut here---start->8--- > U-Boot SPL 2024.01 (Jan 01 1970 - 00:00:01 +) > DDR version: dc2e84f0. > Trying to boot from MMC2 > > OpenSBI v1.3 > > SNIP > > U-Boot 2024.01 (Jan 01 1970 - 00:00:01 +) > > CPU: rv64imafdc_zba_zbb > Model: StarFive VisionFive 2 v1.3B > DRAM: 8 GiB > Core: 134 devices, 26 uclasses, devicetree: board > WDT: Not starting watchdog@1307 > MMC: mmc@1601: 0, mmc@1602: 1 > Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size > 256 Bytes, erase size 4 KiB, total 16 MiB > OK > StarFive EEPROM format v2 > > SNIP > > starfive_7110_pcie pcie@2b00: Starfive PCIe bus probed. > starfive_7110_pcie pcie@2c00: Starfive PCIe bus probed. > In:serial@1000 > Out: serial@1000 > Err: serial@1000 > Net: eth0: ethernet@1603, eth1: ethernet@1604 > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Card did not respond to voltage select! : -110 > Card did not respond to voltage select! : -110 > bootmode flash device 0 > Card did not respond to voltage select! : -110 > Hit any key to stop autoboot: 0 > Card did not respond to voltage select! : -110 > ** Bad device specification mmc 0 ** > Couldn't find partition mmc 0:3 > Can't set block device > Importing environment from mmc0 ... > ## Warning: Input data exceeds 1048576 bytes - truncated > ## Info: input data size = 1048578 = 0x12 > Can't set block device > ## Warning: defaulting to text format > ## Error: "boot2" not defined > Card did not respond to voltage select! : -110 > ethernet@1603 Waiting for PHY auto negotiation to complete. > TIMEOUT ! > phy_startup() failed: -110FAILED: -110ethernet@1604 Waiting for PHY auto > negotiation to complete. TIMEOUT ! > phy_startup() failed: -110FAILED: -110ethernet@1603 Waiting for PHY auto > negotiation to complete. TIMEOUT ! > phy_startup() failed: -110FAILED: -110ethernet@1604 Waiting for PHY auto > negotiation to complete. TIMEOUT ! > phy_startup() failed: -110FAILED: -110StarFive # > StarFive # > --8<---cut here---end--->8--- > > Guix Describe: > > --8<---cut here---start->8--- > Generation 77 May 24 2024 00:15:41(current) > guix 9901416 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 9901416233867233192b63fde7f616751127b189 > --8<---cut here---end--->8--- > > [2. VisionFive2 U-boot failure --- text/plain; > visionfive2-u-boot-failure.log]... > > > [1]: https://github.com/starfive-tech/VisionFive2/issues/20 signature.asc Description: PGP signature
bug#70999: [PATCH] build-system/meson: Add #:out-of-source? argument to build system.
Meson currently supports only out-of-source builds. Add the argument
out-of-source? with default to #t such that the install-license-files phase
searches for the license files in the source directory.
* guix/build-system/meson.scm (meson-build): Add out-of-source? argument.
(meson-cross-build): Likewise.
Change-Id: Ib59d9d93b34fd567f05f5f9a10293f6ab924e399
---
I have tested this with the tio package (both natively building and cross
compiling) and seems to work. This will cause a lot of rebuild!
For the position of the argument I've put it above build-type to match the
order in cmake-build-system.
guix/build-system/meson.scm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/guix/build-system/meson.scm b/guix/build-system/meson.scm
index bf9ca15ecc..6c085fa1fe 100644
--- a/guix/build-system/meson.scm
+++ b/guix/build-system/meson.scm
@@ -176,6 +176,7 @@ (define* (meson-build name inputs
(outputs '("out"))
(configure-flags ''())
(search-paths '())
+ (out-of-source? #t)
(build-type "debugoptimized")
(tests? #t)
(test-options ''())
@@ -225,6 +226,7 @@ (define* (meson-build name inputs
#$(if (pair? configure-flags)
(sexp->gexp configure-flags)
configure-flags)
+ #:out-of-source? #$out-of-source?
#:build-type #$build-type
#:tests? #$tests?
#:test-options #$(sexp->gexp test-options)
@@ -257,7 +259,7 @@ (define* (meson-cross-build name
(configure-flags ''())
(search-paths '())
(native-search-paths '())
-
+(out-of-source? #t)
(build-type "debugoptimized")
(tests? #f)
(test-options ''())
@@ -338,6 +340,7 @@ (define* (meson-cross-build name
,@#$(if (pair? configure-flags)
(sexp->gexp configure-flags)
configure-flags))
+ #:out-of-source? #$out-of-source?
#:build-type #$build-type
#:tests? #$tests?
#:test-options #$(sexp->gexp test-options)
base-commit: 9756d9d6345fb142944261174453ab0a597cc2e7
--
2.41.0
bug#71197: visionfive2-barebones-os fails to boot Linux from MMC2
Hi Guix! When generating a VisionFive2 system image via $ guix system image gnu/system/images/visionfive2.scm --no-grafts --target=riscv64-linux-gnu and attempting to boot from MMC2, the SD card U-boot fails to boot Linux. (Pretty sure --target= is gratuitous but I kept it.) This occurs despite setting and saving the ftdfile variable as described in the instructions: --8<---cut here---start->8--- ;;; Commentary: ;;; ;;; VisionFive2 can boot from MMC1 (SPI flash) or MMC2 (SD card) selected ;;; by DIP switches MSEL[1:0], you may want boot from MMC2 to use the ;;; U-Boot from Guix System instead of the vendor U-Boot in MMC1. Before ;;; doing so, make sure you have a correct 'fdtfile' in the environment: ;;; ;;; uboot> setenv fdtfile starfive/jh7110-starfive-visionfive-2-v1.3b.dtb ;;; uboot> saveenv --8<---cut here---end--->8--- --8<---cut here---start->8--- # Confirming the variable is set after reboot using the U-boot console: StarFive # printenv fdtfile fdtfile=starfive/jh7110-starfive-visionfive-2-v1.3b.dtb --8<---cut here---end--->8--- The system /does/ boot into Linux if SPI Flash is selected as a boot source, although since the onboard bootloader is outdated the system only sees 4 GiB of RAM [1]. Attached is the full failing boot log. Here are the highlights: --8<---cut here---start->8--- U-Boot SPL 2024.01 (Jan 01 1970 - 00:00:01 +) DDR version: dc2e84f0. Trying to boot from MMC2 OpenSBI v1.3 SNIP U-Boot 2024.01 (Jan 01 1970 - 00:00:01 +) CPU: rv64imafdc_zba_zbb Model: StarFive VisionFive 2 v1.3B DRAM: 8 GiB Core: 134 devices, 26 uclasses, devicetree: board WDT: Not starting watchdog@1307 MMC: mmc@1601: 0, mmc@1602: 1 Loading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK StarFive EEPROM format v2 SNIP starfive_7110_pcie pcie@2b00: Starfive PCIe bus probed. starfive_7110_pcie pcie@2c00: Starfive PCIe bus probed. In:serial@1000 Out: serial@1000 Err: serial@1000 Net: eth0: ethernet@1603, eth1: ethernet@1604 libfdt fdt_check_header(): FDT_ERR_BADMAGIC Card did not respond to voltage select! : -110 Card did not respond to voltage select! : -110 bootmode flash device 0 Card did not respond to voltage select! : -110 Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 ** Bad device specification mmc 0 ** Couldn't find partition mmc 0:3 Can't set block device Importing environment from mmc0 ... ## Warning: Input data exceeds 1048576 bytes - truncated ## Info: input data size = 1048578 = 0x12 Can't set block device ## Warning: defaulting to text format ## Error: "boot2" not defined Card did not respond to voltage select! : -110 ethernet@1603 Waiting for PHY auto negotiation to complete. TIMEOUT ! phy_startup() failed: -110FAILED: -110ethernet@1604 Waiting for PHY auto negotiation to complete. TIMEOUT ! phy_startup() failed: -110FAILED: -110ethernet@1603 Waiting for PHY auto negotiation to complete. TIMEOUT ! phy_startup() failed: -110FAILED: -110ethernet@1604 Waiting for PHY auto negotiation to complete. TIMEOUT ! phy_startup() failed: -110FAILED: -110StarFive # StarFive # --8<---cut here---end--->8--- Guix Describe: --8<---cut here---start->8--- Generation 77 May 24 2024 00:15:41(current) guix 9901416 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9901416233867233192b63fde7f616751127b189 --8<---cut here---end--->8--- U-Boot SPL 2024.01 (Jan 01 1970 - 00:00:01 +) DDR version: dc2e84f0. Trying to boot from MMC2 OpenSBI v1.3 _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|___/_| | | |_| Platform Name : StarFive VisionFive 2 v1.3B Platform Features : medeleg Platform HART Count : 5 Platform IPI Device : aclint-mswi Platform Timer Device : aclint-mtimer @ 400Hz Platform Console Device : uart8250 Platform HSM Device : --- Platform PMU Device : --- Platform Reboot Device: --- Platform Shutdown Device : --- Platform Suspend Device : --- Platform CPPC Device : --- Firmware Base : 0x4000 Firmware Size : 234 KB Firmware RW Offset: 0x2 Firmware RW Size : 106 KB Firmware Heap Offset : 0x3 Firmware Heap Size: 42 KB (total), 2 KB
bug#70932: FAIL tests/guix-shell.sh
Christopher Baines skribis: >> “make check TESTS=tests/guix-shell.sh” passes for me though with >> 9c3a8a380bcfebdb77af61532e7bfec523d7bde8. > > I can just about see what's happening on this line now, I'm still not > sure why the exit status means the test fails. > > I think I knew when I submitted the issue that the test was flaky as it > passed on the second attempt. I don’t think how this particular test is flaky: checking whether a package’s ‘supported-systems’ matches the current system is fully deterministic AFAICS. But, who knows, it would be interesting to see if it eventually fails when ran in a loop. Closing? Ludo’.
bug#71144: Interactive prompt opened upon shepherd config file error
Ludovic Courtès writes: > Ludovic Courtès skribis: > >> I think we should change the above to log and gracefully handle failure >> to load an individual service file. > > With the change below, every service except the offending one is loaded > and started as expected: > > --8<---cut here---start->8--- > [ 22.450515] shepherd[1]: Service root running with value #t. > [ 22.454624] shepherd[1]: Service root has been started. > [ 22.711738] shepherd[1]: Exception caught while loading > '/gnu/store/fjis6iqpjfcnr90fy8rsg9v4j828jslv-shepherd-gwl-web.go': > #< components: (#<> #< origin: > #f> #< message: "Unbound variable: ~S"> #< irri > [ 22.711839] tants: (make-forkexec-constructor/container)> > #< kind: unbound-variable args: (#f "Unbound > variable: ~S" (make-forkexec-constructor/container) #f)>)> > [ 22.755146] shepherd[1]: starting services... > [ 22.756491] shepherd[1]: Configuration successfully loaded from > '/gnu/store/mq7y31xnjcjwjkyf6w7qiaq61g6n9f5x-shepherd.conf'. > Uncaught exception in task: > In fibers.scm: > 172:8 7 (_) > In ice-9/exceptions.scm: >406:15 6 (_) > In ice-9/boot-9.scm: > 1752:10 5 (with-exception-handler _ _ #:unwind? _ # _) > In shepherd/service.scm: >824:39 4 (_) > In oop/goops.scm: > 1567:11 3 (cache-miss #f) >1585:2 2 (_ _ _) > 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: > No applicable method for #< one-shot-service? (1)> in call > (one-shot-service? #f) > [ 22.798737] shepherd[1]: Starting service user-file-systems... > [ 22.800361] shepherd[1]: Starting service root-file-system... > [ 22.802015] shepherd[1]: Starting service host-name... > [ 22.803688] shepherd[1]: Starting service pam... > [ 22.805372] shepherd[1]: Starting service sysctl... > [ 22.806926] shepherd[1]: Starting service loopback... > [ 22.808225] shepherd[1]: Starting service firewall... > --8<---cut here---end--->8--- > > (There’s still this scary-looking but harmless backtrace in the middle: > that’s because (start-in-the-background '(something-that-does-not-exist)) > throws like that as of 0.10.4.) > > Once booted, shepherd is fine and you can interact normally with it; the > only thing missing is, in this case, the ‘gwl-web’ service, which we > failed to load. > > I think that’s a significant improvement. > > Thoughts? That looks good to me, the "Arrange to spawn a REPL if something goes wrong" comment needs removing/updating, but that's the only thing I spotted. signature.asc Description: PGP signature
bug#70932: FAIL tests/guix-shell.sh
Ludovic Courtès writes: > Christopher Baines skribis: > >> ++ guile -c '(use-modules (guix utils)) >> (display (%current-system))' >> + this_system=x86_64-linux >> ++ guile -c '(use-modules (guix utils)) >> (display (if (string=? "riscv64-linux" (%current-system)) >> "x86_64-linux" >> "riscv64-linux"))' >> + other_system=riscv64-linux >> + cat >> + guix shell -D -f t-guix-shell-19847/some-package.scm -n >> hint: Consider passing the `--check' option once to make sure your shell >> does not >> clobber environment variables. >> >> + false > > This is in ‘tests/guix-shell.sh’ a test that checks that unsupported > packages are rejected. The ‘guix shell -D -f -t …’ command above is > supposed to fail (non-zero exit code), but in your case it succeeded, > hence the test failure. > > “make check TESTS=tests/guix-shell.sh” passes for me though with > 9c3a8a380bcfebdb77af61532e7bfec523d7bde8. I can just about see what's happening on this line now, I'm still not sure why the exit status means the test fails. I think I knew when I submitted the issue that the test was flaky as it passed on the second attempt. signature.asc Description: PGP signature
bug#70932: FAIL tests/guix-shell.sh
Hi, Christopher Baines skribis: > ++ guile -c '(use-modules (guix utils)) > (display (%current-system))' > + this_system=x86_64-linux > ++ guile -c '(use-modules (guix utils)) > (display (if (string=? "riscv64-linux" (%current-system)) > "x86_64-linux" > "riscv64-linux"))' > + other_system=riscv64-linux > + cat > + guix shell -D -f t-guix-shell-19847/some-package.scm -n > hint: Consider passing the `--check' option once to make sure your shell does > not > clobber environment variables. > > + false This is in ‘tests/guix-shell.sh’ a test that checks that unsupported packages are rejected. The ‘guix shell -D -f -t …’ command above is supposed to fail (non-zero exit code), but in your case it succeeded, hence the test failure. “make check TESTS=tests/guix-shell.sh” passes for me though with 9c3a8a380bcfebdb77af61532e7bfec523d7bde8. Ludo’.
bug#70826: luks-device-mapping-with-options breaks bootloader
Hi, Tadhg McDonald-Jensen skribis: > using the `luks-device-mapping-with-options` mapped device type defined in > (gnu system mapped-devices) causes grub or other bootloaders to not > properly attempt to mount the encrypted drive. This is caused by the > commit 39a9404 which identifies luks mapped devices by checking if the type > is equal to `luks-device-mapping`, so by using a different routine that is > a proxy to that one it doesn't forward it to grub in the > store-crypto-devices list. Ouch, indeed. The immediate fix is: diff --git a/gnu/system.scm b/gnu/system.scm index c76f4d7c502..bb851b1b75f 100644 --- a/gnu/system.scm +++ b/gnu/system.scm @@ -667,10 +667,13 @@ (define (operating-system-boot-mapped-devices os) (define operating-system-bootloader-crypto-devices (mlambdaq (os);to avoid duplicated output "Return the sources of the LUKS mapped devices specified by UUID." +(define (luks-device? m) + (memq (mapped-device-type m) +(list luks-device-mapping-with-options + luks-device-mapping))) + ;; XXX: Device ordering is important, we trust the returned one. -(let* ((luks-devices (filter (lambda (m) - (eq? luks-device-mapping -(mapped-device-type m))) +(let* ((luks-devices (filter luks-device? (operating-system-boot-mapped-devices os))) (uuid-crypto-devices non-uuid-crypto-devices (partition (compose uuid? mapped-device-source) Not ideal, but it fixes the problem. I’ll go ahead with this patch if there are no objections. Thanks! Ludo’.
bug#70999: Meson-build system fails to install license files
Hi Dariqq, Dariqq skribis: > The install-license-files function has an argument for specifying > out-of-source builds and calling it with that set to #t seems to be > able to find license files in the source directory in my limited > testing. Yes, ‘meson-build-system’ should pass #:out-of-source? #t exactly like ‘cmake-build-system’ does. That should solve the problem. Thanks, Ludo’.
bug#70243: The substitute authorization warning is displayed when it shouldn't be
Hi Leo, Leo Famulari skribis: > I just saw this on Debian: > > -- > $ guix shell -D guix -- ./pre-inst-env guix weather linux-libre > computing 1 package derivations for x86_64-linux... > looking for 1 store items on https://ci.guix.gnu.org... > guix weather: warning: substitutes from 'https://ci.guix.gnu.org' are > unauthorized > hint: To authorize all substitutes from `https://ci.guix.gnu.org' to be > downloaded, the following command needs to be run as root: > [...] > -- > > But, I do have the given key in my '/etc/guix/acl', and this works: Are /etc/guix/acl and /etc/guix world-readable? ‘check-narinfo-authorization’ in (guix scripts weather) is supposed to properly handle this case, but I think that fails if /etc/guix is not accessible. Thanks, Ludo’.
bug#70349: Clang fails to communicate RUNPATH?
Hi Liliana,
Liliana Marie Prikler skribis:
> I've noticed a strange error when attempting to build my software
> against clang-toolchain. I've attached a minimally breaking example,
> but the gist of it is that RUNPATH validation fails as shown below.
>
> starting phase `validate-runpath'
> validating RUNPATH of 1 binaries in
> "/gnu/store/sd1zjjf13mi448qbqaphhcvf9ap5jxji-why-hello-0/bin"...
> /gnu/store/sd1zjjf13mi448qbqaphhcvf9ap5jxji-why-hello-0/bin/hello:
> error: depends on 'libfmt.so.9', which cannot be found in RUNPATH
> ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib")
>
> Is this expected? I know that the -for-system have historically
> disregarded the existence of clang-toolchain and hence led to issues,
> but I think this is something else…
Could this be an issue specific to ‘meson-build-system’?
For instance, this works fine (both mpfr and mpc use
‘gnu-build-system’):
guix build mpc --with-c-toolchain=mpfr=clang-toolchain
If we add this to the example you posted:
(arguments
(list #:phases #~(modify-phases %standard-phases
(add-after 'unpack 'debug-ld-wrapper
(lambda _
(setenv "GUIX_LD_WRAPPER_DEBUG" "yes"))
… we see:
--8<---cut here---start->8---
ld-wrapper: library search path:
("/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0"
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib"
"/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.."
"/gnu/store/inpy5mz35fwvclynpag5gsp6d1hflfsz-meson-1.1.0/lib"
"/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib"
"/gnu/store/j8wlfmlmfvpbza6is9wv9xsd8psrxn00-bzip2-1.0.8/lib"
"/gnu/store/gr0sy0m1mv36qv54idm6cn10l3mngshq-file-5.44/lib"
"/gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1/lib"
"/gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8/lib"
"/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-2.35/lib"
"/gnu/store/0irvg0gvvfwagdjckigvr4g8xap94y1j-clang-toolchain-18.1.5/lib")
ld-wrapper: libraries linked:
("/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib/libfmt.so"
"/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libstdc++.so"
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libm.so"
"/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libgcc_s.so"
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so"
"/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libgcc_s.so")
ld-wrapper: invoking
`/gnu/store/zh4x65snfis7svs6906gj1z8i7dx2j3m-binutils-2.38/bin/ld' with
("--eh-frame-hdr" "-m" "elf_x86_64" "-pie" "-dynamic-linker"
"//gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2"
"-o" "hello"
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/Scrt1.o"
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/crti.o"
"/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/crtbeginS.o"
"-L/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0"
"-L/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib"
"-L/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.."
"-L/gnu/store/inpy5mz35fwvclynpag5gsp6d1hflfsz-meson-1.1.0/lib"
"-L/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib"
"-L/gnu/store/j8wlfmlmfvpbza6is9wv9xsd8psrxn00-bzip2-1.0.8/lib"
"-L/gnu/store/gr0sy0m1mv36qv54idm6cn10l3mngshq-file-5.44/lib"
"-L/gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1/lib"
"-L/gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8/lib"
"-L/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-2.35/lib"
"-L/gnu/store/0irvg0gvvfwagdjckigvr4g8xap94y1j-clang-toolchain-18.1.5/lib"
"hello.p/hello.cpp.o" "--as-needed" "--no-undefined"
"-rpath=/gnu/store/g9wxj9a27jhnxa40zafh0ff33dd8906y-why-hello-0/lib" "-rpath"
"/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib" "-rpath-link"
"/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib" "--start-group"
"/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib/libfmt.so"
"--end-group" "-lstdc++" "-lm" "-lgcc_s" "-lgcc" "-lc" "-lgcc_s" "-lgcc"
"/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/crtendS.o"
"/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/crtn.o" "-rpath"
"/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib" "-rpath"
"/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.."
"-rpath" "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "-rpath"
bug#71144: Interactive prompt opened upon shepherd config file error
Ludovic Courtès skribis: > I think we should change the above to log and gracefully handle failure > to load an individual service file. With the change below, every service except the offending one is loaded and started as expected: --8<---cut here---start->8--- [ 22.450515] shepherd[1]: Service root running with value #t. [ 22.454624] shepherd[1]: Service root has been started. [ 22.711738] shepherd[1]: Exception caught while loading '/gnu/store/fjis6iqpjfcnr90fy8rsg9v4j828jslv-shepherd-gwl-web.go': #< components: (#<> #< origin: #f> #< message: "Unbound variable: ~S"> #< irri [ 22.711839] tants: (make-forkexec-constructor/container)> #< kind: unbound-variable args: (#f "Unbound variable: ~S" (make-forkexec-constructor/container) #f)>)> [ 22.755146] shepherd[1]: starting services... [ 22.756491] shepherd[1]: Configuration successfully loaded from '/gnu/store/mq7y31xnjcjwjkyf6w7qiaq61g6n9f5x-shepherd.conf'. Uncaught exception in task: In fibers.scm: 172:8 7 (_) In ice-9/exceptions.scm: 406:15 6 (_) In ice-9/boot-9.scm: 1752:10 5 (with-exception-handler _ _ #:unwind? _ # _) In shepherd/service.scm: 824:39 4 (_) In oop/goops.scm: 1567:11 3 (cache-miss #f) 1585:2 2 (_ _ _) 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: No applicable method for #< one-shot-service? (1)> in call (one-shot-service? #f) [ 22.798737] shepherd[1]: Starting service user-file-systems... [ 22.800361] shepherd[1]: Starting service root-file-system... [ 22.802015] shepherd[1]: Starting service host-name... [ 22.803688] shepherd[1]: Starting service pam... [ 22.805372] shepherd[1]: Starting service sysctl... [ 22.806926] shepherd[1]: Starting service loopback... [ 22.808225] shepherd[1]: Starting service firewall... --8<---cut here---end--->8--- (There’s still this scary-looking but harmless backtrace in the middle: that’s because (start-in-the-background '(something-that-does-not-exist)) throws like that as of 0.10.4.) Once booted, shepherd is fine and you can interact normally with it; the only thing missing is, in this case, the ‘gwl-web’ service, which we failed to load. I think that’s a significant improvement. Thoughts? Ludo’. diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm index 455e972535d..f13c52c37ba 100644 --- a/gnu/services/shepherd.scm +++ b/gnu/services/shepherd.scm @@ -380,8 +380,7 @@ (define (shepherd-configuration-file services shepherd) (scm->go (cute scm->go <> shepherd))) (define config #~(begin - (use-modules (srfi srfi-34) - (system repl error-handling)) + (use-modules (srfi srfi-1)) (define (make-user-module) ;; Copied from (shepherd support), where it's private. @@ -417,17 +416,22 @@ (define (shepherd-configuration-file services shepherd) ;; Arrange to spawn a REPL if something goes wrong. This is better ;; than a kernel panic. - (call-with-error-handling -(lambda () - (register-services - (parameterize ((current-warning-port - (%make-void-port "w"))) - (map (lambda (file) -(save-module-excursion - (lambda () - (set-current-module (make-user-module)) - (load-compiled file - '#$(map scm->go files)) + (register-services + (parameterize ((current-warning-port (%make-void-port "w"))) + (filter-map (lambda (file) + (with-exception-handler + (lambda (exception) + (format #t "Exception caught \ +while loading '~a': ~s~%" + file exception) + #f) + (lambda () + (save-module-excursion +(lambda () + (set-current-module (make-user-module)) + (load-compiled file + #:unwind? #t)) + '#$(map scm->go files (format #t "starting services...~%") (let ((services-to-start
bug#64734: Recursive hackage import fails
Hi, > $ guix import hackage linear-generics --recursive have you ever figured out what caused this? I cannot reproduce it currently – probably because ghc-th-abstraction is part of Guix already and no recursion actually happens. Lars
bug#38946: guix import fails for cabal-helper
Hi, > I've been trying to improve the Haskell tooling we have here on Guix, but > I ran into this problem: if I try to do ~guix import hackage > cabal-helper~ it fails with: Guix has had support for the `common` stanza for quite a while now and importing cabal-helper works. Closing. Lars
