unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Oleg Pykhalov <go.wigust@gmail.com>
Cc: 30647@debbugs.gnu.org
Subject: [bug#30647] [PATCH] guix build: Support '--remote-log-file=PACKAGE'.
Date: Thu, 01 Mar 2018 22:30:12 +0100	[thread overview]
Message-ID: <878tbb4h7f.fsf@gnu.org> (raw)
In-Reply-To: <87606f3it9.fsf@gmail.com> (Oleg Pykhalov's message of "Thu, 01 Mar 2018 18:40:50 +0300")

Oleg Pykhalov <go.wigust@gmail.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>>>>> ‘--remote-log-file’ allows to get a URL for a build log file on a substitute
>>>>> server regardless is it built locally.  ‘--log-file’ returns always local
>>>>> build log file.
>>>>
>>>> What did you think of having ‘--log-file’ transparently fall back to
>>>> searching for log files on substitute servers?
>>
>> To put it differently: what do you dislike about the current behavior?
>
> Suppose package build failed locally.  I want to receive a log from a
> remote server.  I could do it manually by:
>
> 1.  Removing local failed log.
> 2.  ‘wget’, but I need to know a URL.

The URL scheme is documented and easy to use (info "(guix) Invoking guix
publish").  That’s why I don’t find wget to be much of a problem.

>> No no: keep the current behavior, but print something when we’re looking
>> for a remote log file (currently it silently checks whether the remote
>> log file is available.)
>
> Still not clear to me.  If ‘guix --log-file’ checks for a remote log
> file, then it gets a valid URL to a remote build log file for free,
> doesn't it?

Correct.  See ‘log-url’ in (guix scripts build).

>>> I don't think mixing those in one output is good, because for example
>>> you cannot do like:
>>>
>>> diff -u <(guix build --log-file hello) <(guix build --remote-log-file hello)
>>
>> I see.  I guess I’ve never wanted that, or rather, when I do, I
>> explicitly wget the remote log file.  :-)
>
> Could I ask What's your workflow for ‘wget’?

Something like:

  $ guix build foo
  /gnu/store/xyz-foo
  $ wget -O log https://berlin.guixsd.org/log/xyz-foo
  
>>> As a better approach in addition to ‘--no-substitutes’, maybe we could
>>> implement ‘--only-substitutes’ (as I remember Nix has it)?  Such flag
>>> will return a remote log file and will avoid building packages locally.
>>
>> That could be an option, but that’s much more work (not limited to log
>> file handling.)
>
> Yes, but benefits (especially avoid building packages locally) are
> worth.
>
> If you don't agree with the patch, I'll not complain and will try to
> work on ‘--only-substitutes’.  :-)

Heheh.  :-)

IIRC, --only-substitutes in Nix is used together with --upgrade, no?
Some considered it questionable from a security standpoint when we last
discussed it: <https://bugs.gnu.org/26608>.

Thanks,
Ludo’.

  reply	other threads:[~2018-03-01 21:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28 14:19 [bug#30647] [PATCH] guix build: Support '--remote-log-file=PACKAGE' Oleg Pykhalov
2018-02-28 22:13 ` Ludovic Courtès
2018-03-01  4:19   ` Oleg Pykhalov
2018-03-01 13:22     ` Ludovic Courtès
2018-03-01 15:40       ` Oleg Pykhalov
2018-03-01 21:30         ` Ludovic Courtès [this message]
2018-03-01 15:16   ` Tobias Geerinckx-Rice
2018-03-01 21:23     ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878tbb4h7f.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=30647@debbugs.gnu.org \
    --cc=go.wigust@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).