Hello! Ricardo Wurmus <rek...@elephly.net> skribis:
> Danny Milosavljevic <dan...@scratchpost.org> writes: > >>> I propose that “guix publish” should also convey information about >>> failed builds. The Guix client can then abort right away without >>> wasting time and power to attempt a doomed build. Users may override >>> this with “--fallback” or a new option. Good idea! The difficulty is that the protocol between ‘guix substitute --query’ and the daemon is currently very much Boolean: either ‘guix substitute’ provides the binary or it doesn’t. We’d have to adjust it. >> As long as we distinguish transient build machine errors (disk full, can't >> resolve hostname, too many names in directory, no inodes left etc) from >> actual >> errors in the source code, +1. > > I was thinking of something very simple. The daemon is already capable > of caching build failures; I think it may be good to simply pass that > information on to clients. The daemon tries to cache only “persistent” failures. In particular, local failures likely due to lack of space are not cached. However, the daemon currently doesn’t distinguish between ENOSPC and actual failures for offloaded builds. We may be able to fix this by having ‘guix offload’ check the available disk space upon failure. Then there’s the problem of non-deterministic failures. For these it would be nicer to let the user build stuff anyway. There’s no good solution here. Ludo’.