Re: 01/04: gnu: mesa: Disable imx driver for armhf-linux.

[ludo@gnu.org (Ludovic Courtès)]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> Marius Bakke <mbakke@fastmail.com> writes:
>>>
>>>> Note that mesa and libdrm did not build any drivers at all on armhf
>>>> until recent commits on 'staging'.  I tried cross-compiling libdrm
>>>> to update etnaviv symbols instead, but failed some packages before it.
>>>>
>>>> So currently it's a trial-and-error process to find flags to make mesa
>>>> build on armhf.  This means armhf users are currently unable to build
>>>> *any* graphical packages, actually.  Given how expensive evaluations
>>>> are, I figured we might as well deal with it on 'master'.
>>>
>>> Thanks for explaining.  I think this should have been dealt with on the
>>> 'staging' branch before merging into 'master'.  This is a pretty bad
>>> situation now for anyone using Guix on armhf.
>>
>> Didn't we already talk about this when you merged an earlier 'staging'
>> branch into 'master' that contained a major GNOME upgrade that was
>> untested, and broke GNOME desktops for all platforms?
>>
>> Do you think it should be acceptable to merge a major branch into
>> 'master' where *all* graphical packages are broken on armhf?
>
> I naively assumed that disabling the etnaviv driver was enough, but
> concede that it was short-sighted.  Unfortunately I did not notice the
> armhf failures until late in the cycle due to manually restarting all
> 'gobject-introspection' dependents on i686 and x86_64.  And learned that
> "new job" failures are not listed in the "newly failing" tab.
>
> I feel terrible for gambling with armhf users' convenience and security
> and can only offer a sincere apology.

Thank you, Marius.

As much as I sympathize with Mark’s frustration, and that of anyone
using Guix on ARM, I also understand how hard it is to do the work that
you’ve been doing Marius.

As Leo pointed out, the feedback loop is really slow for ARM if you
don’t have the hardware yourself (we’re doing discontinuous
integration!), which makes things even harder.  It would be ideal if, in
addition to Hydra, ARM users would chime in and report problems before
merges.

From the maintainer’s viewpoint, it just stresses that we must keep
going with the efforts to improve our build infrastructure.  Currently
that has only benefited x86, but perhaps now is a good time to plug our
ARM boxes behind berlin.guixsd.org, for a start.

Thoughts?

Ludo’.