From: Oleg Pykhalov <go.wigust@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 30647@debbugs.gnu.org
Subject: [bug#30647] [PATCH] guix build: Support '--remote-log-file=PACKAGE'.
Date: Thu, 01 Mar 2018 18:40:50 +0300 [thread overview]
Message-ID: <87606f3it9.fsf@gmail.com> (raw)
In-Reply-To: <874lm06ic9.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 01 Mar 2018 14:22:46 +0100")
[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]
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.
3. Hydra web interface, which is slow (especially multiple packages).
> 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?
>> 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’?
> So I guess I’m unconvinced about the need for a separate
> ‘--remote-log-file’ option.
>
> What do people think? Ricardo?
Maybe CC him? Or is it a bad etiquette for a mailing list, because he
is subscribed?
>> 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’. :-)
Oleg.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2018-03-01 15:42 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 [this message]
2018-03-01 21:30 ` Ludovic Courtès
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=87606f3it9.fsf@gmail.com \
--to=go.wigust@gmail.com \
--cc=30647@debbugs.gnu.org \
--cc=ludo@gnu.org \
/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).