bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

[Ludovic Courtès]

Hello,

Marius Bakke <address@hidden> skribis:

> Mark H Weaver <address@hidden> writes:

[...]

>> I think what needs to be done is the following:
>>
>> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries'
>>     should be reverted, to downgrade mescc-tools to the 0.5.2 release.
>>
>> (2) The 'wip-binaries' tarballs should be uploaded to a new subdirectory
>>     of <https://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/>, along
>>     with digital signatures, of course.  I'm talking about these in
>>     particular:
>>
>>     3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b  
>> guile-static-stripped-2.2.4-i686-linux.tar.xz
>>     1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a  
>> linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz
>>     021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330  
>> mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz
>>     fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0  
>> mes-minimal-stripped-0.19-i686-linux.tar.xz
>>     c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7  
>> static-binaries-0-i686-linux.tar.xz
>>
>> (3) The following bootstrap packages in 'core-updates' bootstrap.scm
>>     should be updated to use the new binaries above:
>>
>>      (a) %bootstrap-linux-libre-headers
>>      (b) %bootstrap-mescc-tools
>>      (c) %bootstrap-mes
>>
>> (4) Berlin should start rebuilding 'core-updates'.
>>
>> If desired, steps (3) and (4) could come before (2) if someone
>> temporarily uploads the new binaries somewhere else, and adjusts
>> '%bootstrap-base-urls' accordingly.  The key is for the hashes and file
>> names to match what we've agreed on here, as I listed in (2) above.
>>
>> What do you think?
>
> Thank you for the excellent summary.  I can look into adjusting the bash
> fix for 5.0, and updating the bootstrap binary URLs and hashes.  I will
> do this in a 'core-updates-next' branch.  I would also like to merge
> wip-binaries into it as a final step, unless someone has objections.

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.)

Also, what’s the next step for ‘wip-binaries’?

Thanks,
Ludo’.