Mark H Weaver <m...@netris.org> writes: > Mark H Weaver <m...@netris.org> writes: > >> Marius Bakke <mba...@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. Hopefully the most recent 'mesa' commit solves this issue, and rest assured I won't merge a broken package with ~800 dependents again. Humbly, Marius
signature.asc
Description: PGP signature
