Hi Christopher, Christopher Baines <m...@cbaines.net> writes:
> Maxim Cournoyer <maxim.courno...@gmail.com> writes: > >> Christopher Baines <m...@cbaines.net> writes: >> >>> guix-comm...@gnu.org writes: >>> >>>> apteryx pushed a commit to branch master >>>> in repository guix. >>>> >>>> commit 0be7838105806819f4586ec9130382a66a22880e >>>> Author: Kaelyn Takata <kaelyn.al...@protonmail.com> >>>> AuthorDate: Thu May 4 20:12:46 2023 +0000 >>>> >>>> gnu: mesa: Update to 23.0.3. >>>> >>>> * gnu/packages/gl.scm (mesa): Update to 23.0.3. >>>> [source]: Remove obsolete patch and update HTTPS url. >>>> [arguments]: Enable the crocus gallium driver. >>>> * gnu/packages/patches/mesa-fix-sporadic-test-failures.patch: Delete >>>> file. >>>> * gnu/local.mk (dist_patch_DATA): Remove it. >>>> --- >>>> gnu/local.mk | 1 - >>>> gnu/packages/gl.scm | 14 ++++------- >>>> .../patches/mesa-fix-sporadic-test-failures.patch | 27 >>>> ---------------------- >>>> 3 files changed, 5 insertions(+), 37 deletions(-) >>> >>> → guix refresh -l mesa >>> Building the following 1954 packages would ensure 4257 dependent >>> packages are rebuilt ... >>> >>> >>> I know there's been some discussion about changing processes regarding >>> changes like this that impact lots of packages, but as far as I'm aware, >>> the documented process hasn't changed yet. So should this have gone to >>> core-updates, and not been directly pushed to master? >> >> There isn't currently a core-updates branch, and I need to spend some >> time documenting the authorization process for how to create short lived >> Cuirass branches. I think ideally we would have created a >> 'graphics-team' or similar branch (even the team has yet to be formed) >> and let it build. >> >> Seeing the build machines were idling in the European night, I figured I >> could get away with it for this time. > > Some build machines may have been idle, but I'm not sure what you mean > by "get away with it"? I meant that I believed there was enough capacity to process the 4K rebuilds (per architecture) in a way that wouldn't negatively affect users too much. > While the berlin bulid farm has managed to catch back up for > x86_64-linux and i686-linux within 24 hours, I think these changes > impact other systems as well. > > Also, the bordeaux build farm has a lot fewer machines to do these > builds, so while the substitute availability had caught up (and > surpassed ci.guix.gnu.org for x86_64-linux) prior to these changes, it's > going to be several days at least I think before substitute availability > is looking good again. > > I was watching the substitute availability recover after the > core-updates merge as I'd like to re-enable testing patches on the > qa-frontpage, but now that'll have to wait some more for all these new > builds to complete. Hm, sorry about that. Cuirass seems to have mostly caught up already (was 64% before, 62% now for the master specification). >> But the situation will repeat; I'd like to push some xorg updates that >> fix a CVE; we'll nead a 'xorg-team' branch or similar. Should we create >> these branches from the maintenance repository (permanent branches) ? > > I don't really understand the question, surely the branches would be in > the guix Git repository? Yes, the branch would be in the Guix repository, but I meant regarding the Cuirass specifications affecting which branches it builds; sorry for being unclear. > Anyway, package replacements+grafts can be used for security issues so > that shouldn't need to be on a branch as it won't involve lots of > rebuilds. For this case I think so yes, since it's a patch-level update that should be safe. > When it comes to handling changes involving lots of rebuilds though, I > think that this has been and continues to be difficult, but in my mind > that's a reason to slow down and try and work on tooling and processes > to help. One of the things that has been bothered me has been the lack of documentation/tooling to recreate TLS user certificates for Cuirass so that I can configure branches via its web interface again, or retry failed builds. I'm currently working on documenting (in Cuirass's manual) a script Ricardo's made for that task. But building lots of packages will still require a lot of processing power, probably more so when it happens in focused team branches compared to grouped together as it used to be the case for e.g. core-updates. -- Thanks, Maxim
