Re: 01/04: gnu: mesa: Disable imx driver for armhf-linux.
Mark H Weaver writes: > Mark H Weaver writes: > >> Marius Bakke 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
Re: 01/04: gnu: mesa: Disable imx driver for armhf-linux.
On Fri, Oct 13, 2017 at 08:38:13PM -0400, Mark H Weaver wrote: > Do you think it should be acceptable to merge a major branch into > 'master' where *all* graphical packages are broken on armhf? I think we all agree that we should not do this. As somebody who also works on merging these branches, I'd like to point out that the continuous integration process for armhf is difficult to use effectively. The core of the problem is that the feedback loop for armhf is unreliable and slow. Similar problems exist with Hydra for x86_64 and i686, but they are mitigated because most of us have access to our own x86_64 machines where we can test changes quickly before asking Hydra to verify a positive result. It would be great to have access to an armhf machine where we could do the same thing, testing changes directly without going through Hydra. Maybe if one has a fast enough x86_64 computer, they could virtualize an armhf test machine. signature.asc Description: PGP signature
Re: Adopt a patch!
Ludovic Courtès transcribed 1.0K bytes: > Hi Thomas, > > I understand and sympathize with your arguments. In fact, this has been > a long running theme, and we discussed it at last year’s FOSDEM at > length. :-) > > Thomas Danckaert skribis: > > > So I do see the appeal of something like gitlab, but I also wonder how > > it could be integrated in the current workflow. I think it could help > > a lot if debbugs took some ideas from github/gitlab, but I don't think > > debbugs is actively worked on? > > At FOSDEM, while we have having a drink late at night, someone said > “Let’s just write a nice Web interface to Debbugs in Guile!”, and we > were all like “Yeah, let’s do that!”. But of course on the next > morning, we were all thinking about something else already. ;-) > > So, I don’t know! I’m still open to experimenting with a local > GitLab/Kallithea/whatever instance. If someone writes packages and a > GuixSD service, that could be easy. Hint, hint! :-) > > Ludo’. > > I would not bet on Kallithea. I hope it changes, but it seemed not very active. Responsive (the team), but last time I tried working on it was 6 months ago. Pagure is a Fedora/Red-Hat project. Seems promising, although a bit early. It seems functional enough for Fedora, and so far it's the only one I would use. There's a ton more we looked at. Building Gitlab from source is supposedly harder than pagure, as pagure just depends on python modules. I should pick up this branch again. If you don't mind the wait, I could arrange this after the majority of the current task is done. Of course anyone could pull from my remote and work on pagure ;) -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
