From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#29363: Single test failure building Guix Date: Tue, 21 Nov 2017 08:47:52 +0100 Message-ID: <871sksoyxj.fsf@gnu.org> References: <89edb4cc307bfae5db7812abe3b4a37a@mykolab.com> <87a7zgtquv.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eH3Hq-0006t7-Rh for bug-guix@gnu.org; Tue, 21 Nov 2017 02:48:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eH3Hl-0008Tq-VK for bug-guix@gnu.org; Tue, 21 Nov 2017 02:48:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:41130) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eH3Hl-0008TQ-R4 for bug-guix@gnu.org; Tue, 21 Nov 2017 02:48:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eH3Hl-0004vh-K9 for bug-guix@gnu.org; Tue, 21 Nov 2017 02:48:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87a7zgtquv.fsf@fastmail.com> (Marius Bakke's message of "Tue, 21 Nov 2017 01:31:04 +0100") 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, Rutger Helling Hello, Marius Bakke skribis: > Rutger Helling writes: > >> when building Guix with 'guix build guix' I keep running into a single=20 >> 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/stor= e.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 =3D=3D 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 substi= tution > to disable "dead path can be explicitly collected" test. Alternately, we could comment out (> freed 0) if that=E2=80=99s enough, wit= h a comment explaining why, and do =E2=80=9Cmake update-guix-package=E2=80=9D. = That way we=E2=80=99d avoid the extra build phase. WDYT? Thanks for finding out the root cause! Ludo=E2=80=99.