bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41654: Test of guix-1.1.0-4.bdc801e is failing on aarch64


From: Stefan
Subject: bug#41654: Test of guix-1.1.0-4.bdc801e is failing on aarch64
Date: Tue, 2 Jun 2020 01:14:10 +0200

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.

Attachment: 54pswxwm35kq47zk2dswvsq3nm55kb-guix-1.1.0-4.bdc801e.drv.bz2
Description: application/applefile


reply via email to

[Prev in Thread] Current Thread [Next in Thread]