bug#27157: [PATCH] Re: bug#27157: Building Guile 2.2 "times out"

[Maxim Cournoyer]

address@hidden (Ludovic Courtès) writes:

> Maxim Cournoyer <address@hidden> skribis:
>
>> Guix build doesn't come with default option value for the
>> max-silent-time, but guix environment does, and it is set to 3600
>> s. This is defined under (guix scripts environment):
>>
>> (define %default-options
>>   `((system . ,(%current-system))
>>     (substitutes? . #t)
>>     (graft? . #t)
>>     (max-silent-time . 3600)
>>     (verbosity . 0)))
>>
>> If this is by design, I guess this issue can be closed.
>
> Good catch!
>
> However, according to ‘set-build-options’ in (guix store),
> #:max-silent-time #f is equivalent to #:max-silent-time 3600.

IIUC, this should only be true when (< (nix-server-minor-version
server) #x61), as can be seen in (guix store):

    (when (< (nix-server-minor-version server) #x61)
      (let ((max-build-jobs (or max-build-jobs 1))
            (xomax-silent-time (or max-silent-time 3600)))
        (send (integer max-build-jobs) (integer max-silent-time))))

Which seems to be matched with the following in nix-daemon.cc:

        if (GET_PROTOCOL_MINOR(clientVersion) < 0x61) {
            settings.set("build-max-jobs", std::to_string(readInt(from)));
            settings.set("build-max-silent-time", 
std::to_string(readInt(from)));
        }

Given that the the nix worker protocole PROTOCOL_VERSION was bumped to
0x161 in commit deac976d3d26c7b85b9c90efb424b0aa94f1027c last January, I
would *not* expect this condition to be evaluated.

By the way, I find it weird that these conditions be expressed in terms
of the minor version number only. The correctness of those is thus only
guaranteed as long as the major number version is not bumped; this seems
unwise.

> Perhaps the build remains silent for just about an hour and you were
> lucky on your second try?

See explanation above. I don't think this .

> At any rate, it would be good to remove ‘max-silent-time’ from all the
> ‘%default-options’ variables, for consistency.
>
> Ludo’.

I agree! In my view, interactive user commands should expect the users
to take action themselves (e.g.; user notice no output for 3 hours; hits
C-c. Or, user notice no output for 3 hours, check the process in top,
sees it's still doing something, decides to leave it running a couple
more hours).

Maxim