From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:34433) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmeU2-0006eO-6N for guix-patches@gnu.org; Sun, 14 Jul 2019 09:24:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmeU0-0001OW-WD for guix-patches@gnu.org; Sun, 14 Jul 2019 09:24:06 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:35174) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hmeU0-0001OL-S0 for guix-patches@gnu.org; Sun, 14 Jul 2019 09:24:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hmeTy-0002c5-H9 for guix-patches@gnu.org; Sun, 14 Jul 2019 09:24:04 -0400 Subject: [bug#36555] [PATCH 1/2] guix system: Add 'reconfigure' module. Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <87imsci9sj.fsf@sdf.lonestar.org> <87ef30i9fl.fsf@sdf.lonestar.org> <87y3129qsn.fsf@gnu.org> <87sgr9bziq.fsf@sdf.lonestar.org> Date: Sun, 14 Jul 2019 15:23:06 +0200 In-Reply-To: <87sgr9bziq.fsf@sdf.lonestar.org> (Jakob L. Kreuze's message of "Sat, 13 Jul 2019 13:44:13 -0400") Message-ID: <87pnmc7nt1.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: "Jakob L. Kreuze" Cc: 36555@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello! zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis: > Ludovic Court=C3=A8s writes: [...] >> Can we remove =E2=80=98with-output-to-string=E2=80=99? I=E2=80=99d rathe= r see what=E2=80=99s going on. >> :-) >> >> If that=E2=80=99s too verbose, we can use =E2=80=98invoke/quiet=E2=80=99. > > I'm not too concerned with verbosity; rather, in the case for 'guix > deploy', the script's output mixes with the REPL output and that causes > 'remote-eval' to fail with a match error. I think it would be better to > continue using 'with-output-to-string', but to preseve its return value > so we can show it to the user from 'guix deploy' or 'guix system > reconfigure'. Users of 'guix deploy' would also be able to see the > script's output this way. Oh, I see. So in a way the problem is that =E2=80=98remote-eval=E2=80=99 d= oesn=E2=80=99t do anything sensible with the output and error ports of that remote evaluation. Ultimately we should probably fix (guix inferior) and (guix remote) so that stdout and stderr are properly transmitted. In the meantime, what about this patch? --=-=-= Content-Type: text/x-patch Content-Disposition: inline diff --git a/guix/remote.scm b/guix/remote.scm index e503c76167..8ada5c0957 100644 --- a/guix/remote.scm +++ b/guix/remote.scm @@ -76,8 +76,14 @@ result to the current output port using the (guix repl) protocol." (with-imported-modules (source-module-closure '((guix repl))) #~(begin (use-modules (guix repl)) - (send-repl-response '(primitive-load #$program) + + ;; We use CURRENT-OUTPUT-PORT for REPL messages, so redirect PROGRAM's + ;; output to CURRENT-ERROR-PORT so that it does not interfere. + (send-repl-response '(with-output-to-port (current-error-port) + (lambda () + (primitive-load #$program))) (current-output-port)) + (force-output)))) (define* (remote-eval exp session --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> It seems that this sort-of inlines parts of =E2=80=98shepherd-service-up= grade=E2=80=99 >> but without traversing the service dependency graph to determine the >> compilete set of obsolete services, no? I feel that we should be >> reusing =E2=80=98shepherd-service-upgrade=E2=80=99 or similar bits. (I r= ealize this is >> already in =E2=80=98master=E2=80=99 for =E2=80=98guix deploy=E2=80=99, b= ut since this is going to be >> shared with =E2=80=98guix system=E2=80=99, we=E2=80=99d rather be extra = cautious.) > > Does 'live-service-requirement' not encompass the full service > dependency graph? Regardless, I'll look into reusing > 'shepherd-service-upgrade' as it's well-testsed. =E2=80=98live-service-requirement=E2=80=99 gives you the graph of the curre= ntly loaded services, but you also need the target service graph to determine what to upgrade; that seems to be missing currently. Thanks, Ludo=E2=80=99. --=-=-=--