[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#30647] [PATCH] guix build: Support '--remote-log-file=PACKAGE'.
From: |
Ludovic Courtès |
Subject: |
[bug#30647] [PATCH] guix build: Support '--remote-log-file=PACKAGE'. |
Date: |
Thu, 01 Mar 2018 22:30:12 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Oleg Pykhalov <address@hidden> skribis:
> address@hidden (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’.