Hi,
Mark H Weaver skribis:
> Ludovic Courtès writes:
>
>> Mark H Weaver skribis:
>>
>>> Thanks. The next evaluation got further, but eventually failed. Again,
>>> there seems no way to get any details on what went wrong from the web
>>> interface:
>>>
>>>
Hi Ludovic,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> Thanks. The next evaluation got further, but eventually failed. Again,
>> there seems no way to get any details on what went wrong from the web
>> interface:
>>
>> https://ci.guix.gnu.org/jobset/core-updates-core-updates
>>
Hi,
Mark H Weaver skribis:
> Thanks. The next evaluation got further, but eventually failed. Again,
> there seems no way to get any details on what went wrong from the web
> interface:
>
> https://ci.guix.gnu.org/jobset/core-updates-core-updates
> https://ci.guix.gnu.org/eval/7029
A
On +2019-08-27 11:38:31 +0200, Ludovic Courtès wrote:
> Hi Mark,
>
> Mark H Weaver skribis:
>
> > Ludovic Courtès writes:
> >
> >> Mark H Weaver skribis:
>
> [...]
>
> >>> commit 82eaac49ac983f28768d6623d802f41cbd7f779b
> >>> Author: Mark H Weaver
> >>> Date: Thu Aug 15 16:44:36 2019
Hi Ludovic and Ricardo,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> I pushed the revised commits to 'core-updates', but something seems to
>> have gone wrong with the new evaluation on Berlin:
>>
>> https://ci.guix.gnu.org/jobset/core-updates-core-updates
>>
Ricardo Wurmus writes:
> (Looks like the cuirass-web service still writes to the same log file,
> so I can’t actually see the message amidst all the build logs…)
It now logs to cuirass-web.log.
--
Ricardo
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> I pushed the revised commits to 'core-updates', but something seems to
>> have gone wrong with the new evaluation on Berlin:
>>
>> https://ci.guix.gnu.org/jobset/core-updates-core-updates
>> https://ci.guix.gnu.org/eval/7008
>>
>> The
Hi,
Mark H Weaver skribis:
> I pushed the revised commits to 'core-updates', but something seems to
> have gone wrong with the new evaluation on Berlin:
>
> https://ci.guix.gnu.org/jobset/core-updates-core-updates
> https://ci.guix.gnu.org/eval/7008
>
> The first URL above shows a big "X"
Hi Ludovic,
I pushed the revised commits to 'core-updates', but something seems to
have gone wrong with the new evaluation on Berlin:
https://ci.guix.gnu.org/jobset/core-updates-core-updates
https://ci.guix.gnu.org/eval/7008
The first URL above shows a big "X" in the "Success" column for
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> I could simply push the revised commits to 'core-updates' directly.
>
> That sounds good me, please do!
Done. I'm closing this bug now, but feel free to reopen if there are
remaining issues that I've overlooked.
Thanks!
Mark
Hello,
Mark H Weaver skribis:
> Ludovic Courtès wrote:
>
>> Mark H Weaver skribis:
>>
>>> Hmm, good point. Perhaps we should postpone the Bash fix until the next
>>> core-updates cycle. [...]
>>
>> Your call: if you think this Bash fix can be delayed without causing
>> problems, then please
Hi Ludovic,
Ludovic Courtès wrote:
> Mark H Weaver skribis:
>
>> Hmm, good point. Perhaps we should postpone the Bash fix until the next
>> core-updates cycle. [...]
>
> Your call: if you think this Bash fix can be delayed without causing
> problems, then please revert it and we’ll apply it
Hi Mark,
Mark H Weaver skribis:
> Ludovic Courtès writes:
>
>> Mark H Weaver skribis:
[...]
>>> commit 82eaac49ac983f28768d6623d802f41cbd7f779b
>>> Author: Mark H Weaver
>>> Date: Thu Aug 15 16:44:36 2019 -0400
>>>
>>> gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
Mark H Weaver skribis:
> I tagged 'wip-binaries' and merged it into master, but there's an
> undesirable side effect. After the merge, "git describe" from 'master'
> now returns "bootstrap-20190815-222-g32e18e9b94".
I think that’s OK.
Ideally, we’d have mentioned the commit used to build the
Hi Ludovic,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> Ludovic Courtès wrote:
>>> 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.
>>
>>
Hi Ludovic,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> Ludovic Courtès 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
Hi Mark,
Mark H Weaver skribis:
> Ludovic Courtès 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
Hi Ludovic,
Ludovic Courtès 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
Hello,
Marius Bakke skribis:
> Mark H Weaver 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'
Hello,
Mark H Weaver skribis:
> Ludovic Courtès writes:
>
>> Mark H Weaver skribis:
>>
>>> You can reproduce them with the following command from a git checkout at
>>> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
>>> 'wip-binaries' branch, based on recent 'master':
Hi Ludovic,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> You can reproduce them with the following command from a git checkout at
>> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
>> 'wip-binaries' branch, based on recent 'master':
>>
>> ./pre-inst-env guix
Hi Mark,
Mark H Weaver skribis:
> You can reproduce them with the following command from a git checkout at
> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
> 'wip-binaries' branch, based on recent 'master':
>
> ./pre-inst-env guix build --system=i686-linux
FYI, I've fully switched my entire GNOME-based Guix system to
'core-updates-next' now. Of the packages that I use, only three failed
to build: diffoscope, openimageio (needed by blender), and simple-scan.
Mark
Hi Ludovic,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> Ludovic Courtès wrote:
>>> It’s currently being evaluated:
>>>
>>> https://ci.guix.gnu.org/jobset/core-updates-next
>>
>> Thanks, although I guess all of the builds will fail, unless someone
>> manually added the new
Hi,
Mark H Weaver skribis:
> Ludovic Courtès wrote:
>> It’s currently being evaluated:
>>
>> https://ci.guix.gnu.org/jobset/core-updates-next
>
> Thanks, although I guess all of the builds will fail, unless someone
> manually added the new bootstrap tarballs to Berlin's store, or uploaded
>
Hi Ludovic,
Ludovic Courtès wrote:
> It’s currently being evaluated:
>
> https://ci.guix.gnu.org/jobset/core-updates-next
Thanks, although I guess all of the builds will fail, unless someone
manually added the new bootstrap tarballs to Berlin's store, or uploaded
them to one of the URLs in
Hi Mark,
Mark H Weaver skribis:
> You can reproduce them with the following command from a git checkout at
> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the
> 'wip-binaries' branch, based on recent 'master':
>
> ./pre-inst-env guix build --system=i686-linux
Earlier, I wrote:
> I pushed those two commits to 'core-updates-next', and am currently
> building out that branch on my X200. So far I've successfully built the
> core packages and 'hello', and am now continuing on to build the rest of
> my Guix system.
FYI, on 'core-updates-next', I've built
Hi Ludovic,
Ludovic Courtès writes:
> Marius Bakke skribis:
>
>> Mark H Weaver 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
Hello,
Marius Bakke skribis:
> Mark H Weaver 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'
Hi Marius,
Earlier I wrote:
> Marius Bakke writes:
>> I can look into adjusting the bash fix for 5.0, and updating the
>> bootstrap binary URLs and hashes.
>
> I've attached preliminary untested patches for these. I'm testing them
> now.
I pushed those two commits to 'core-updates-next', and
Marius Bakke writes:
> Mark H Weaver writes:
>
>> I rebased 'wip-binaries' on top of current master (which includes the
>> recent 'staging' merge), and excluding the update of mescc-tools to the
>> git checkout.
>>
>> I built the bootstrap-tarballs for i686-linux and got the same hashes
>> that
Mark H Weaver writes:
> I rebased 'wip-binaries' on top of current master (which includes the
> recent 'staging' merge), and excluding the update of mescc-tools to the
> git checkout.
>
> I built the bootstrap-tarballs for i686-linux and got the same hashes
> that we've previously agreed on
Hi,
Marius Bakke writes:
> I can look into adjusting the bash fix for 5.0, and updating the
> bootstrap binary URLs and hashes.
I've attached preliminary untested patches for these. I'm testing them
now.
Mark
>From e3e477c92af3b62eb8f65a5c4459f02faf60e857 Mon Sep 17 00:00:00 2001
I rebased 'wip-binaries' on top of current master (which includes the
recent 'staging' merge), and excluding the update of mescc-tools to the
git checkout.
I built the bootstrap-tarballs for i686-linux and got the same hashes
that we've previously agreed on here. I used "guix download" to load
Hi Marius,
Marius Bakke writes:
> I wanted to check that the bootstrap-tarballs machinery still worked
> after merging the branch, since it was non-trivial. Mainly to make the
> commit that created them reachable forever, but maybe we don't need it.
[...]
> [...] I will do this in a
Mark H Weaver writes:
> Hi Marius,
>
> Marius Bakke writes:
>
>> Marius Bakke writes:
>>
>>> Jan Nieuwenhuizen writes:
>>>
Mark H Weaver writes:
Hi Mark,
>> I called that `wip-binaries', @master from three weeks ago.
>
> Thank you, that was a good start. I
Hi Marius,
Marius Bakke writes:
> Marius Bakke writes:
>
>> Jan Nieuwenhuizen writes:
>>
>>> Mark H Weaver writes:
>>>
>>> Hi Mark,
>>>
> I called that `wip-binaries', @master from three weeks ago.
Thank you, that was a good start. I found that some additional patches
were
Marius Bakke writes:
> Jan Nieuwenhuizen writes:
>
>> Mark H Weaver writes:
>>
>> Hi Mark,
>>
I called that `wip-binaries', @master from three weeks ago.
>>>
>>> Thank you, that was a good start. I found that some additional patches
>>> were needed to match the bootstrap binaries that
Jan Nieuwenhuizen writes:
> Mark H Weaver writes:
>
> Hi Mark,
>
>>> I called that `wip-binaries', @master from three weeks ago.
>>
>> Thank you, that was a good start. I found that some additional patches
>> were needed to match the bootstrap binaries that 'core-updates' is
>> currently based
Mark H Weaver writes:
Hi Mark,
>> I called that `wip-binaries', @master from three weeks ago.
>
> Thank you, that was a good start. I found that some additional patches
> were needed to match the bootstrap binaries that 'core-updates' is
> currently based on.
>
> I ended up deleting and
Hi Janneke,
Jan Nieuwenhuizen writes:
> Mark H Weaver writes:
>
>> It seems to me that the best way to accomplish this is to backport the
>> new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch.
>
> I called that `wip-binaries', @master from three weeks ago.
Thank you, that
Mark H Weaver writes:
> It seems to me that the best way to accomplish this is to backport the
> new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch.
I called that `wip-binaries', @master from three weeks ago.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Hi Ludovic,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>>> I have added a very similar set of two patches to wip-cu-binaries,
>>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>>>
>>> They give the same md5sum for me as the wip-binaries branch that
>>> branched off of master; so
I wrote earlier:
> There are two bootstrap tarballs that differ:
>
> (1) static-binaries
> (2) guile-static-stripped
>
> In this message, I'll address only the 'static-binaries'.
>
> The only difference in the static-binaries is bash. It turns out that
> the bash-4.4 configure script produces an
Jan Nieuwenhuizen writes:
> Mark H Weaver writes:
>
> Hi Mark,
>
>>> I have added a very similar set of two patches to wip-cu-binaries,
>>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>>>
>>> They give the same md5sum for me as the wip-binaries branch that
>>> branched off of master; so
Hi Mark,
Mark H Weaver skribis:
> Hi Janneke,
>
>> I have added a very similar set of two patches to wip-cu-binaries,
>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>>
>> They give the same md5sum for me as the wip-binaries branch that
>> branched off of master; so mine are at
>>
Mark H Weaver writes:
Hi Mark,
>> I have added a very similar set of two patches to wip-cu-binaries,
>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>>
>> They give the same md5sum for me as the wip-binaries branch that
>> branched off of master; so mine are at
>>
Hi Janneke,
> I have added a very similar set of two patches to wip-cu-binaries,
> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>
> They give the same md5sum for me as the wip-binaries branch that
> branched off of master; so mine are at
> http://lilypond.org/janneke/guix/20190722/
I
Mark H Weaver writes:
Hi Mark,
> Actually, I have a better idea. How about starting a new branch at
> commit ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f (the commit used to
> build the current bootstrap binaries for core-updates) and applying the
> fixes there? Then you can push that new branch
Hi Janneke,
Jan Nieuwenhuizen wrote:
>> What I need is a way to build the new bootstrap tarballs without using
>> the existing 'core-updates' branch. I need a way to build them from a
>> branch that's based upon the much older bootstrap binaries that we've
>> been using for many years.
Jan Nieuwenhuizen writes:
>> What I need is a way to build the new bootstrap tarballs without using
>> the existing 'core-updates' branch. I need a way to build them from a
>> branch that's based upon the much older bootstrap binaries that we've
>> been using for many years. Preferably, they
Jan Nieuwenhuizen writes:
> Hmm, I'm not sure how much work it would be. If we're lucky then the
> recipes from gnu/packages/bootstrap.scm
*gnu/packages/make-bootstrap.scm
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®
Hi Janneke,
Thanks very much for the quick response to this issue.
Jan Nieuwenhuizen wrote:
> In any case, if store references are present in bootstrap binaries, then
> they should be reproducible. Removing store references is one way to
> make them reproducible but I'm not sure if that's the
Mark H Weaver writes:
> I'm working to independently verify the new bootstrap binaries. Toward
> that end, I locally built the new bootstrap tarballs by running the
> following command from a git checkout at commit
> ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
>
> ./pre-inst-env guix build
I'm working to independently verify the new bootstrap binaries. Toward
that end, I locally built the new bootstrap tarballs by running the
following command from a git checkout at commit
ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f.
./pre-inst-env guix build bootstrap-tarballs --system=i686-linux
56 matches
Mail list logo
