Re: Guix on aarch64

[Mark H Weaver]

Leo Famulari <address@hidden> writes:

> On Tue, Aug 28, 2018 at 09:57:49AM +0200, Ricardo Wurmus wrote:
>> I commented specifically on Leo’s statement about build debugging on
>> Cuirass:
>> 
>>     “I don't actually do any build debugging with Berlin yet because I
>>      don't know how to use the interface effectively.”
>> 
>> This did not sound like a severe problem with Cuirass to me, but rather
>> a problem that could be fixed by adding minor features to Cuirass like
>> the display of build logs.  Leo, could you please tell us what missing
>> feature in the Cuirass web interface is the most urgent for you to use
>> the interface effectively?
>
> My apologies in advance if these features already exist in the Cuirass
> web interface! I didn't find them yet.
>
> I mostly use Hydra for two things:
>
> 1) I use it to manage large branch re-builds (e.g. core-updates) by
> looking at the lists of failed builds for the lastest evaluation of that
> particular "jobset" (i.e. Git branch).
>
> Hydra gives a list of tabs like this that are helpful:
>
> Aborted jobs (2)
> Newly failing jobs (2)
> Newly succeeding jobs (1)
> New jobs (29)
> Removed jobs (23)
> Still failing jobs (2425)
> Still succeeding jobs (20470)
> Queued jobs (675)
> Inputs
>
> I might also compare the evaluation to another evaluation of the same
> jobset, or against another jobset (usually master).
>
> The concept of "dependency failures" and their reporting is also really
> helpful (i.e "foo was not built because its dependency bar failed").

Right, these are all indispensible tools.

> Also, I use the Hydra web interface to start jobset evaluations and
> restart particular package builds, and to restart all builds that were
> skipped due to dependency failures.

These are too, although "restart all dependency failures", which I
hastily added, is too crude of a tool in my opinion.  I've since cooked
up a PostgreSQL transaction which does something better: restart all
dependency failures that were caused by a particular failed derivation.
That should be what we aim for in Cuirass, I think.

> 2) Checking build logs of a particular package to see if a failure or
> success is reproducible on the build farm.

Yes, this too.

       Mark