From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rutger Helling Subject: bug#29363: Single test failure building Guix Date: Tue, 21 Nov 2017 10:10:12 +0100 Message-ID: <4464438fc18e9ae461ab8d8a9959b04c@mykolab.com> References: <89edb4cc307bfae5db7812abe3b4a37a@mykolab.com> <87a7zgtquv.fsf@fastmail.com> <871sksoyxj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2d1bd5f77cd67f12ba6f744abb8f9d2b" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eH4a9-0006dR-AF for bug-guix@gnu.org; Tue, 21 Nov 2017 04:11:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eH4a6-00036B-3f for bug-guix@gnu.org; Tue, 21 Nov 2017 04:11:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:41185) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eH4a6-000363-0O for bug-guix@gnu.org; Tue, 21 Nov 2017 04:11:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eH4a5-0000OO-J0 for bug-guix@gnu.org; Tue, 21 Nov 2017 04:11:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <871sksoyxj.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: ludo@gnu.org Cc: 29363@debbugs.gnu.org --=_2d1bd5f77cd67f12ba6f744abb8f9d2b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Commenting out that line still made the test fail for me. On 2017-11-21 08:47, ludo@gnu.org wrote: > Hello, > > Marius Bakke skribis: > > Rutger Helling writes: > > when building Guix with 'guix build guix' I keep running into a single > test failure. I've attached the test-suite.log. > Is this a Btrfs system by any chance, possibly on an SSD? > > test-name: dead path can be explicitly collected > location: /tmp/guix-build-guix-0.13.0-10.0b4c385.drv-0/source/tests/store.scm:178 > source: > + (test-assert > + "dead path can be explicitly collected" > + (let ((p (add-text-to-store > + %store > + "random-text" > + (random-text) > + '()))) > + (let-values > + (((paths freed) (delete-paths %store (list p)))) > + (and (equal? paths (list p)) > + (> freed 0) > + (not (file-exists? p)))))) > actual-value: #f > result: FAIL > I can reproduce this error on two different systems that have > Btrfs+LUKS+SSD, and the problem is that freed == 0. If you comment out (> freed 0), does the test pass? > I suspect it's related to Btrfs' "lazy" reporting of disk space, but > haven't dug very far. > > Until we figure out what's going on, I suggest applying the patch > below. Can you confirm that it works on your system? > > From bdc7b5310111e21801529ea57e290f6eb72ac6ed Mon Sep 17 00:00:00 2001 > From: Marius Bakke > Date: Tue, 21 Nov 2017 00:27:08 +0100 > Subject: [PATCH] gnu: guix: Disable test that fails on Btrfs. > > Works around . > Reported by Rutger Helling . > > * gnu/packages/package-management.scm (guix)[arguments]: Rename > 'disable-container-tests' phase to 'disable-failing-tests' and add substitution > to disable "dead path can be explicitly collected" test. Alternately, we could comment out (> freed 0) if that's enough, with a comment explaining why, and do "make update-guix-package". That way we'd avoid the extra build phase. WDYT? Thanks for finding out the root cause! Ludo'. --=_2d1bd5f77cd67f12ba6f744abb8f9d2b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Commenting out that line still made the test fail for me.

On 2017-11-21 08:47, ludo@gnu.org wrote:

= Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

Rutger Helling <rhelling@mykolab.com> writes:

when building Guix with 'guix build guix' I keep runni= ng into a single
test failure. I've attached the test-suite.log.
Is this a Btrfs system by any chance, possibly on an SSD?

test-name: dead path can be explicitly collected
= location: /tmp/guix-build-guix-0.13.0-10.0b4c385.drv-0/source/tests/store= =2Escm:178
source:
+ (test-assert
+   "dead pat= h can be explicitly collected"
+   (let ((p (add-text-to-st= ore
+           &nb= sp;  %store
+        &nb= sp;     "random-text"
+    &n= bsp;         (random-text)
+            &nbs= p; '())))
+     (let-values
+  &n= bsp;    (((paths freed) (delete-paths %store (list p)))= )
+       (and (equal? paths (list p))<= br /> +            (= > freed 0)
+          = ;  (not (file-exists? p))))))
actual-value: #f
result= : FAIL

I can reproduce this error on two different systems that have
= Btrfs+LUKS+SSD, and the problem is that freed =3D=3D 0.

If you comment out (> freed 0), does the test pass?

I suspect it's related to Btrfs' "lazy" reporting of d= isk space, but
haven't dug very far.

Until we figure out= what's going on, I suggest applying the patch
below.  Can you c= onfirm that it works on your system?

From bdc7b5310111e2180152= 9ea57e290f6eb72ac6ed Mon Sep 17 00:00:00 2001
From: Marius Bakke <= mbakke@fastmail.com>
Da= te: Tue, 21 Nov 2017 00:27:08 +0100
Subject: [PATCH] gnu: guix: Disab= le test that fails on Btrfs.

Works around <https:= //bugs.gnu.org/29363>.
Reported by Rutger Helling <rhelling@mykolab.com>.

= * gnu/packages/package-management.scm (guix)[arguments]: Rename
'dis= able-container-tests' phase to 'disable-failing-tests' and add substitution=
to disable "dead path can be explicitly collected" test.
Alternately, we could comment out (> freed 0) if that's enough, w= ith a
comment explaining why, and do "make update-guix-package". &nbs= p;That way
we'd avoid the extra build phase.

WDYT?
=
Thanks for finding out the root cause!

Ludo'.


--=_2d1bd5f77cd67f12ba6f744abb8f9d2b--