Ludovic Courtès <l...@gnu.org> writes: > Hello, > > Marius Bakke <mba...@fastmail.com> skribis: > >> Ludovic Courtès <l...@gnu.org> writes: >> >>> Hi Mark, >>> >>> Mark H Weaver <m...@netris.org> skribis: >>> >>>> I've successfully updated my x86_64 GuixSD system to my private branch >>>> based on 'core-updates' with recent 'master' and 'staging' merged into >>>> it. This system includes a full GNOME desktop environment plus a few >>>> programs based on Qt. It all works quite well. >>>> >>>> My branch includes a few draft fixes and workarounds that I haven't yet >>>> pushed, but nothing that would require many rebuilds to update later. >>>> >>>> So, I think it might be time to ask Hydra to build all of core-updates, >>>> after staging is merged into it. >>> >>> I agree. There was an issue with cross-compiling ‘bootstrap-tarballs’ >>> that Marius reported a few days ago, which I’m looking into right now. >>> I don’t expect the fix(es) to trigger a full rebuild. >>> >>> If Marius and others don’t object, I’d say go for it! >> >> No objections from me. However I do have a bunch of fairly innocent >> updates in my queue, such as SQLite, Glib and CMake. It's also tempting >> to get rid of that Perl graft. Is it too late for such changes? > > I think it’s OK for sqlite/glib/cmake, but changing Perl would further > delay things, which perhaps is not desirable.
I was running a bit late with my patches and pushed them to a separate branch before noticing the 'rhash' update on 'master'. Now there have been a couple of world-rebuilding commits on the 'core-updates-next' branch since, so I wonder how to move forward. * Start 'core-updates' as-is. * Pick all updates from the -next branch that won't rebuild the world (that is everything apart from "xz" and "file"). * Take all the -next commits, remove the Perl graft, and do a new 'core' evaluation. Any preferences? Due to the "rhash" update, I suppose we can take anything from -next that depends on CMake also with option #1. >> Hydra will be busy for a couple of days with 'master' and 'staging', so >> there's little use in starting it immediately. > > It took me a couple of days to reply :-), so maybe we can start the > evaluation now? Let's get this rolling as soon as the current Hydra queue clears!
signature.asc
Description: PGP signature
