Mark H Weaver writes:
> After we switch to using 'invoke' everywhere, or more precisely, after
> we arrange to never return #false from any phase or snippet, then
> there should be one more step before removing the vestigial #true
> returns: we should change the code that calls phases or snippets
Hey Ludo,
> And! This brings a whole set of new bugs that I’m hunting notably on
> berlin (which may thus lag behind…). Overall I think it’ll make Cuirass
> easier to work with and more “introspectable”.
I went through your recent Cuirass commits and it seems awesome. I'll
try yo update Cuiras
BTW, when I try to access berlin's Cuirass HTTP API, I have the following
error:
--8<---cut here---start->8---
curl -i -H "Accept: application/json"
http://berlin.guixsd.org/api/latestbuilds?nr=10
HTTP/1.1 502 Bad Gateway
Server: nginx/1.12.2
Date: Thu, 25 Jan
Mathieu Othacehe skribis:
> BTW, when I try to access berlin's Cuirass HTTP API, I have the following
> error:
Yeah, a few things are still brittle and I’m starting/stopping Cuirass
on berlin quite frequently.
Don’t upgrade your server yet. :-)
Ludo’.
Hello Guix!
In December, Richard Henwood of ARM Holdings kindly donated two SoftIron
OverDrive 1000:
https://softiron.com/development-tools/overdrive-1000/
These are 4-core, pretty fast machines. Both are currently at my place
and I recently added one to the berlin.guixsd.org build farm. It
Hello Fis,
Fis Trivial writes:
[...]
> * Add --pure option to `guix environment`
This is what I do even on GuixSD for Guix's Git repository, too.
> Then I tried again the added --pure option to `guix environment`:
> $ guix environment guix --ad-hoc help2man git strace --pure
>
> During the p
Dear Roel,
Thank you for your comments.
I was imaging your point 2. And the softwares come from Guix.
The added benefit was: a controlled and reproducible environment.
In other words, the added benefit came from the GuixWorkflow (the
engine of workflow), and not from the Language (lisp EDSL).
But
Hi Guix,
attached is a patch that adds an SELinux policy for the guix-daemon.
The policy defines the guix_daemon_t domain and specifies what labels
may be accessed and how by processes running in that domain.
These file labels are defined:
* guix_daemon_conf_t
for Guix configuration files (in
Replying to self:
If I had waited another minute, I would have found:
https://hydra.gnu.org/jobset/gnu/master
This looks like it is testing x86_64 only?
Are other architectures available somewhere else?
best regards,
Richard
On Thu, 2018-01-25 at 09:41 -0600, Richard Henwood wrote:
> Hi Ludo'
Hi Ludo',
Thanks for this update and your efforts to get Guix building on
AArch64! Do you perform any automated testing continuously or on
releases? I am interested to see if anything is failing on different
architectures.
I haven't forgotten that you are down one machine. It sounds like
you'll b
Hi Richard,
Richard Henwood skribis:
> Replying to self:
>
> If I had waited another minute, I would have found:
> https://hydra.gnu.org/jobset/gnu/master
>
> This looks like it is testing x86_64 only?
>
> Are other architectures available somewhere else?
hydra.gnu.org is actually building for
Hello!
Ricardo Wurmus skribis:
> attached is a patch that adds an SELinux policy for the guix-daemon.
> The policy defines the guix_daemon_t domain and specifies what labels
> may be accessed and how by processes running in that domain.
Impressive! I know nothing about SELinux so I can’t comme
Jonathan Brielmaier skribis:
> * website/apps/base/templates/donate.scm (donate-t): Add table row for
> overdrive1.guixsd.org.
Applied (without the “hosting” part since it’s not hosted at the MDC.)
Thanks! :-)
Ludo’.
On Thu, Jan 25, 2018 at 09:17:38AM -0500, Oleg Pykhalov wrote:
> wigust pushed a commit to branch master
> in repository guix.
>
> commit 45b486984d8ab092cf002cd0b500df4dc62e186b
> Author: Oleg Pykhalov
> Date: Thu Jan 25 16:58:35 2018 +0300
>
> gnu: gource: Fix the hashes of mutated GitHu
Arun Isaac writes:
> Mark H Weaver writes:
>
>> After we switch to using 'invoke' everywhere, or more precisely, after
>> we arrange to never return #false from any phase or snippet, then
>> there should be one more step before removing the vestigial #true
>> returns: we should change the code t
Hi,
zimoun writes:
> In this context, since 'lispy' syntax is not mainstream (and will
> never be), it appears to me as a hard position.
We’ve got you covered here: the GWL has built-in support for Wisp, a
pretty language extension for Guile. It also comes with a bunch of
extra syntax support
Sorry for the really late reply.
>
> Installing a missing package by guessing from non-existing command is a
> Fedora's “feauture” of Bash. I believe this is a reason of following
> failures. You probably could avoid this by starting a Bash process with
>
> bash --noprofile
>
> [...]
>
It wo
Hi Ludo,
> Over the last few days, out of frustration ;-), I hacked Cuirass to
> improve several things:
Oh yeah! That’s great.
> • Logging is improved: useful events are logged, including build
> started/succeeded/failed (using a variant of what I proposed in the
> Guix ‘wip-ui’ bra
I’ve posted a news item here:
https://www.gnu.org/software/guix/blog/2018/aarch64-build-machines-donated/
Notice the neat stickers courtesy of Chris Baines. :-)
Ludo’.
zimoun writes:
> Dear Roel,
>
> Thank you for your comments.
>
> I was imaging your point 2. And the softwares come from Guix.
> The added benefit was: a controlled and reproducible environment.
> In other words, the added benefit came from the GuixWorkflow (the
> engine of workflow), and not fro
Hi,
Watching this thread and trying to take the pulse of GWL.
Where should I look?
https://git.roelj.com/guix/gwl has little documentation - it does say " GWL has
a built-in getting-started guide. To use it, run: guix workflow
--web-interface" - but supposing we just want to read some document
Hmmm... is it down right now? I've written a HTML frontend and I always get
504 or timeout from
https://berlin.guixsd.org/api/latestbuilds?nr=20
or similar.
Sorry if I'm too impatient :-)
Might want this:
$ git diff
diff --git a/build-aux/guix.scm b/build-aux/guix.scm
index c2f6cdb..4075806 100644
--- a/build-aux/guix.scm
+++ b/build-aux/guix.scm
@@ -81,6 +81,7 @@
"guile-json"
"guile-sqlite3"
"guile-git"
+ "guile-fibers"
"guix")
On 01/20/2018 06:40 PM, Danny Milosavljevic wrote:
> Hi Leo,
>
>> Although native-inputs are typically things that are only required while
>> building [0], there's nothing that prevents a built package from keeping
>> references to native-inputs.
>
> We should change that in core-updates-next,
Hullo,
On Fri, 2018-01-26 at 00:56 +, Fis Trivial wrote:
> On 01/20/2018 06:40 PM, Danny Milosavljevic wrote:
> > I think that native-inputs shouldn't end up in the final binary as
> > a
> > reference, especially when cross-compiling
> > (but we don't do cross-compilation much in Guix - usuall
I've just been pointed at this:
https://github.com/jerry40/guile-kernel
Recall that Jupyter is a web-based interactive framework meant for
collaborative creation of research diaries, journals, presentations & etc.
where the researcher/author can embed snippets of code that graph stuff, do
stuff,
Andy Wingo writes:
> On Thu 25 Jan 2018 06:31, Maxim Cournoyer writes:
>
>> Where does this `invoke' comes from? Geiser is unhelpful at finding it,
>> and it doesn't seem to be documented in the Guile Reference?
>
> https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00163.html
OK, so `inv
27 matches
Mail list logo
