Re: [PATCH 1/7] gnu: gobject-introspection: Update to 1.44.0.

[Mark H Weaver]

Andreas Enge <address@hidden> writes:

> On Tue, Apr 21, 2015 at 06:18:48PM -0400, Mark H Weaver wrote:
>> We shouldn't ask Hydra to build it until all of the relevant patches are
>> pushed.  Therefore, I have deleted the 'wip-glib' jobset for now, since
>> it was about to rebuild 1335 builds based on the libidn-1.30 update,
>
> These were shared with master anyway, so the argument does not apply.

Well, fair enough :)  However, since I reverted the libidn-1.30 update
and cancelled all the associated jobs on Hydra, the argument actually
does apply, although that was not clear from this message alone.

> I still think we should evaluate once without the patches in the new
> branch (which causes only little work, modulo the problems with the
> virtual machine...)

If evaluations were as cheap as they should be, then I think this would
be a reasonable thing to do.  Unfortunately, evaluations are currently
quite expensive on hydra.

> so that we can see under "newly failing builds" what
> problems have been caused by the patches.
>
> Currently, all packages in wip-glib are listed under "new jobs", so
> the successful and the (currently close to 500) failed builds are
> mixed up [...]

There's an easy solution for this: click on the little "Compare to..."
button near the top right corner of the evaluation page, and select
"Jobset gnu:master".  More generally, visit:

  http://hydra.gnu.org/eval/<XXXXXX>?compare=<YYYYYY>

where <XXXXXX> and <YYYYYY> are evaluation IDs.

>> I also have an libxfont security update to add to the branch as well.
>
> Well, in an ideal world, these two patch sets would be built separately,
> so that any failure could be attributed to one or the other. So I would
> not call two rebuilds "wasted work" in such a context.

Agreed.  If our build farm had enough capacity, this would be ideal.
I should not have said "wasted work".

Unfortunately, our build farm capacity is quite limited, and its master
machine is currently lacking in RAM and has extraordinarily poor disk
performance.  For these reasons, at present, it requires a great deal of
hand-holding to keep it from becoming overloaded to the point of being
unusuable.  I do a lot of that work myself, so I'm sensitive to the
issue.

I'm currently working on building the new hydra.gnu.org which will
hopefully perform much better, although we will still need to work
within our build capacity constraints until we have many more build
slaves.

Does this make sense?

       Mark