GNU bug report logs - #41654
Test of guix-1.1.0-4.bdc801e is failing on aarch64

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan <stefan-guix <at> vodafonemail.de>
To: bug-guix <at> gnu.org
Subject: Test of guix-1.1.0-4.bdc801e is failing on aarch64
Date: Tue, 2 Jun 2020 01:14:10 +0200

[Message part 1 (text/plain, inline)]

Hi!

Building guix-1.1.0-4.bdc801e is failing on aarch64 since about two weeks on ci.guix.gnu.org. 

http://ci.guix.gnu.org/search?query=guix-1.1.0-4.bdc801e+system%3Aaarch64-linux

There is always the same failure during the test. See for example the raw log from http://ci.guix.gnu.org/build/2794788/details:

test-name: network-interface-names
…
actual-error:
+ (wrong-type-arg
+   "list-tail"
+   "Wrong type argument in position ~A (expecting ~A): ~S"
+   (1 "pair" ())
+   (()))
result: FAIL


When building locally this particular test is passing (after about three days on an SBC with 1 GB RAM). 

But unfortunately building locally I get two different failures instead:

FAIL: tests/store.scm
FAIL: tests/guix-package.sh

Here are some more details:


test-name: verify-store + check-contents
location: /tmp/guix-build-guix-1.1.0-4.bdc801e.drv-0/source/tests/store.scm:972
…
actual-error:
+ (%exception
+   #<&store-protocol-error message: "path `dtmp/guix-tests/store/bpl866rgsjyzdczlngfw8ss2lkld6bim-mirrors' is not in the store" status: 1>)
result: FAIL

Note the “dtmp/” instead of “/tmp/”. I saw the same error some weeks ago already, but shortly after that was happening, there was a substitute available. But it seems this error is reproducible in my case.


guix install: error: profile t-guix-package-541/profile is locked by another process
+ true
+ kill 1387
+ rm -f t-profile-541 t-profile-541.lock t-profile-541-1-link t-guix-package-file-541
+ rm -rf t-guix-package-541 t-home-541
rm: cannot remove 't-guix-package-541': Directory not empty
FAIL tests/guix-package.sh (exit status: 1)


This may be due to a deleted but still opened file on an NFS share. There may be an intermediate hidden .nfs… file, which may get created in such a case (“delete on last close”, “silly rename”), However, the RFC-5661 for NFS demands even if OPEN4_RESULT_PRESERVE_UNLINKED is supported, that the directory entry of an open file must not be removed in this case, thus preventing a directory removal.

[54pswxwm35kq47zk2dswvsq3nm55kb-guix-1.1.0-4.bdc801e.drv.bz2 (application/applefile, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.