[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Release!
From: |
Ricardo Wurmus |
Subject: |
Re: Release! |
Date: |
Fri, 06 Oct 2017 20:30:10 +0200 |
User-agent: |
mu4e 0.9.18; emacs 25.3.1 |
Hi Ludo,
>> Here are some important items I can think of:
[…]
>> • Guile 2.2 compiler terrible issue:
>> <https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.
One way to side-step this issue for the upcoming release is to use one
Guile process per file when running “guix pull”. This will make it run
a lot slower, but that would be better than the current situation.
Maybe we could make parallel compilation within the same Guile process
an option, so that it won’t be needlessly slow on machines within the
RAM goldilocks zone.
I’ve reverted f07041f7d25badb7d74b8fad6ee446a12af04f63 locally on my
i686 netbook with 1GB RAM and tested it with “guix pull
--url=/path/to/guix”. This seems to work — it’s still running… :)
One annoyance is that after compiling one file it prints this message:
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
I suppose we should suppress this for “guix pull”.
Do you want to make this behaviour optional, e.g. through a command line
switch like “--sloth”? Or should this be the default until the problem
in Guile/libgc is fixed?
>> • Prepare to migrate to the new build farm: the hardware of
>> bayfront.guixsd.org has been fixed (it was unreliable until we
>> changed its CPUs), so now we need to fix a couple of issues in
>> Cuirass and generally improve it so we can, via its HTTP interface,
>> add new jobsets and so on. Of course we’ll have to work
>> on that incrementally.
I guess we’ll be using berlin.guixsd.org instead of bayfront, no? I’m
currently installing additional servers (we’re now at 13 build servers,
I’ll get this up to 18 this week).
>> • Merge the potluck! <https://bugs.gnu.org/26645>
About that… We now have a JSON importer, so maybe it’s worth using the
even simpler JSON package format instead of the simplified S-expression
format that Andy proposed. What do you think? Should we discuss this
at <https://bugs.gnu.org/26645>?
Who would like to help us squash some bugs before the release? Let’s
try to fix at least 5 more bugs!
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
- Release!, Ludovic Courtès, 2017/10/04
- Re: Release!,
Ricardo Wurmus <=
[PATCH] DRAFT: build: Compile scheme modules in batches (was Re: Release!), Mark H Weaver, 2017/10/07