Hi Ludovic, Ludovic Courtès <[email protected]> wrote: > I don’t think we explicitly discussed it, but my assumption is that > we’re delaying merging of ‘core-updates’ into ‘master’ until > ‘core-updates-next’ becomes ‘core-updates’. Is this what you had in > mind? (I’m asking because ‘core-updates’ was almost entirely built > IIRC.)
My preference would be to merge 'core-updates-next' into 'core-updates', or equivalently, to apply the following 3 commits to 'core-updates': --8<---------------cut here---------------start------------->8--- commit d4bc93abe59e8ffcb8304050c05e727fe0230651 Author: Mark H Weaver <[email protected]> Date: Thu Aug 15 15:39:30 2019 -0400 gnu: bootstrap: Update to the 20190815 bootstrap binaries. * gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update the download URL. (%bootstrap-mescc-tools, %bootstrap-mes): Update the download URL and hash. commit 82eaac49ac983f28768d6623d802f41cbd7f779b Author: Mark H Weaver <[email protected]> Date: Thu Aug 15 16:44:36 2019 -0400 gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems. * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/bash.scm (bash)[source]: Add the patch. commit 47fcdfac44c5bf236299679781133468be6f0207 Author: Ludovic Courtès <[email protected]> Date: Thu Aug 22 11:47:27 2019 +0200 gnu: bootstrap: Add ftp.gnu.org to '%bootstrap-base-urls'. * gnu/packages/bootstrap.scm (%bootstrap-base-urls): Add ftp.gnu.org/gnu/guix/bootstrap. --8<---------------cut here---------------end--------------->8--- These commits are the only difference between 'core-updates' and 'core-updates-next'. I'm confident that this will make no difference to the set of packages that build successfully, modulo non-determistic build failures. The only additional time it should require is the time needed for Berlin to rebuild the branch. Otherwise, 'core-updates-next' seems to be in good shape, and possibly almost ready to merge into 'master'. I admit that this assessment is based solely on the fact that I'm currently using it on my own machine, and it works well. Without Hydra's interface for comparing evaluations, I'm mostly blind to the status of the branch beyond of the set of packages I use myself. In my opinion, 'core-updates' in its current form should never be merged into 'master', because it's built upon non-deterministic bootstrap tarballs that cannot be independently verified. What do you think? > Also, what’s the next step for ‘wip-binaries’? Good question! First, I think we should tag it with a name that indicates that it was used to build the 20190815 bootstrap binaries. Optionally, I would advocate merging 'wip-binaries' into 'master'. What do you think? Thanks, Mark
