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 08:31:59 +0100 Message-ID: <265e7019513d69adc9be947d5a59fc13@mykolab.com> References: <89edb4cc307bfae5db7812abe3b4a37a@mykolab.com> <87a7zgtquv.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_e955f3cf4e611184717e3a47aaac3edd" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eH33I-00049w-1X for bug-guix@gnu.org; Tue, 21 Nov 2017 02:33:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eH33H-0002Su-25 for bug-guix@gnu.org; Tue, 21 Nov 2017 02:33:04 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:41116) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eH33G-0002Sg-V0 for bug-guix@gnu.org; Tue, 21 Nov 2017 02:33:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eH33G-0004ZB-Fj for bug-guix@gnu.org; Tue, 21 Nov 2017 02:33:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87a7zgtquv.fsf@fastmail.com> 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: Marius Bakke Cc: 29363@debbugs.gnu.org --=_e955f3cf4e611184717e3a47aaac3edd Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Marius, your patch did the trick, thanks! I'm indeed on Btrfs (with LUKS), no SSD though. On 2017-11-21 01:31, Marius Bakke wrote: > Hi Rutger, > > 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. > > 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? > > Ludo, WDYT? --=_e955f3cf4e611184717e3a47aaac3edd Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Marius,

your patch did the trick, thanks!

I'm indeed on Btrfs (with LUKS), no SSD though.

On 2017-11-21 01:31, Marius Bakke wrote:

= Hi Rutger,

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.

I susp= ect 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 you= r system?

=
Ludo, WDYT?


--=_e955f3cf4e611184717e3a47aaac3edd--