From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: 02/02: services: Add Gitolite. Date: Sun, 30 Sep 2018 15:25:08 -0400 Message-ID: <87h8i6bxez.fsf@netris.org> References: <20180928200104.10056.60968@vcs0.savannah.gnu.org> <20180928200105.E0B4F20476@vcs0.savannah.gnu.org> <871s9b69mg.fsf@netris.org> <87d0sv7001.fsf@cbaines.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g6hLO-00088y-HL for guix-devel@gnu.org; Sun, 30 Sep 2018 15:25:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g6hLN-0005IJ-MI for guix-devel@gnu.org; Sun, 30 Sep 2018 15:25:30 -0400 In-Reply-To: <87d0sv7001.fsf@cbaines.net> (Christopher Baines's message of "Sun, 30 Sep 2018 11:28:14 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Christopher Baines Cc: guix-devel@gnu.org Hi Christopher, Christopher Baines writes: > Mark H Weaver writes: > >> mail@cbaines.net (Christopher Baines) writes: >> >>> cbaines pushed a commit to branch master >>> in repository guix. >>> >>> commit 258a6d944ed891fa92fa87a16731e5dfe0bac477 >>> Author: Christopher Baines >>> Date: Fri Jul 13 20:39:46 2018 +0100 >>> >>> services: Add Gitolite. >>> >>> * gnu/services/version-control.scm (, >>> ): New record types. >>> (gitolite-accounts, gitolite-activation): New procedures. >>> (gitolite-service-type): New variables. >>> * gnu/tests/version-control.scm (%gitolite-test-admin-keypair, %gitolite-os, >>> %test-gitolite): New variables. >>> (run-gitolite-test): New procedure. >>> * doc/guix.texi (Version Control): Document the gitolite service. >> >> This commit has a flaw which broke evaluations on Hydra, so I reverted >> it for now. >> >>> +(define-gexp-compiler (gitolite-rc-file-compiler >>> + (file ) system target) >>> + (match file >>> + (($ umask git-config-keys roles enable) >>> + (apply text-file* "gitolite.rc" >>> + `("%RC = (\n" >>> + " UMASK => " ,(format #f "~4,'0o" umask) ",\n" >> >> The problem is here, in the call to 'format'. Guile has two variants of >> the 'format' procedure: a very simple one which is always available >> (also known as 'simple-format'), and a much more complex and featureful >> variant in (ice-9 format). In the code above, you are assuming that >> (ice-9 format) has been loaded, but you have not arranged for that to >> happen. During the Hydra evaluation, this led to the following error: >> >> --8<---------------cut here---------------start------------->8--- >> 0 (simple-format #f "~4,'0o" 63) >> >> ERROR: In procedure simple-format: >> In procedure simple-format: FORMAT: Unsupported format option ~4 - use (ice-9 format) instead >> --8<---------------cut here---------------end--------------->8--- > > Thanks for looking at this Mark, do you know where I can find out what > Hydra is doing when it encounters this error? I tried looking around the > web interface, but the latest evaluation I could find was from 2017 > apparently. Hydra's web interface is the wrong place to look for information on this problem. I guess the error happens when Hydra tries to create a derivation for the system test '%test-gitolite'. The relevant code that Hydra runs to generate an evaluation is in build-aux/hydra/gnu-system.scm. Specifically, 'system-test-jobs', which calls (all-system-tests) from gnu/tests.scm, which looks for public variables bound to 'system-test' records. That includes '%test-gitolite'. >> I guess that the fix will involve 'with-imported-modules'. Could you >> take a look? > > Sure. The confusing thing to me here is that this code works when using > the service, including the system test (at least when I run it > locally). Also, as far as I understand, even though the code is within a > gexp-compiler, it doesn't even involve the store, as the call to format > happens before the g-expression is generated. > > It sounds to me like adding #:use-modules (ice-9 format) to (gnu > services version-control) would fix this, but I'll wait until I can > reproduce the failure before re-adding the service. I'm not yet sufficiently familiar with gexp compilation to know where the call to 'format' is ultimately being executed, and I don't have time right now to investigate further, so I hoping that Ludovic can chime in here with a definitive answer on how to fix this properly. Mark