[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#75205: guix package test failure on i686-linux (kexec-load-file test
From: |
Ian Eure |
Subject: |
bug#75205: guix package test failure on i686-linux (kexec-load-file test) |
Date: |
Tue, 31 Dec 2024 20:17:09 -0800 |
User-agent: |
mu4e 1.12.7; emacs 29.4 |
This is failing for me on aarch64-linux also:
test-name: kexec-load-file
location:
/tmp/guix-build-guix-1.4.0-31.121e96d.drv-0/source/tests/syscalls.scm:688
source:
+ (test-equal
+ "kexec-load-file"
+ EPERM
+ (catch 'system-error
+ (lambda ()
+ (let ((fd1 (open-fdes "/dev/null" O_RDONLY))
+ (fd2 (open-fdes "/dev/null" O_RDONLY)))
+ (kexec-load-file fd1 fd2 "gnu.repl=yes")))
+ (lambda args (system-error-errno args))))
expected-value: 1
actual-value: 38
result: FAIL
If I downgrade to commit 96cd163c14e68c66c6a4cf0b18261fc454f8c1ba,
guix tests pass again -- the failing test was added in the next
commit. I’m not sure what the issue here, it seems like that
syscall shouldn’t be arch-dependent, and the errnos in the
failures are unhelpful. 38 is ERANGE, 14 is EFAULT, neither of
those seem applicable here. EPERM is 1, and 38 doesn’t have its
LSB set, so it can’t be a bitmask.
I’m encountering the issue using Guix as a foreign package manager
on top of Debian 12 "bookworm" in a VM. Perhaps there’s an
implicit dependency on the host system’s kernel in the test, which
Debian’s fails to meet.
Ludo’, any thoughts?
-- Ian