Hi,
Vagrant Cascadian skribis:
> I've noticed there is some trailing whitespace in /etc/guix/acl ... some
> of it comes from the keys in etc/substitutes/ci.guix.gnu.org.pub ... but
> some of it comes from whatever code assembles /etc/guix/acl (or rather,
> whatever the symlink
I've noticed there is some trailing whitespace in /etc/guix/acl ... some
of it comes from the keys in etc/substitutes/ci.guix.gnu.org.pub ... but
some of it comes from whatever code assembles /etc/guix/acl (or rather,
whatever the symlink points to in /gnu/store).
I noticed this by trying t
BTW, attached it the script I used to retrieve the signing keys of all
the build nodes of the build farm so we can have them declared in the
config of the head node. You may find it handy if you have a similar
setup!
Ludo’.
(use-modules (guix scripts offload)
(guix ssh)
-SERVER}}
(@pxref{Substitutes}).
-When @code{authorize-keys?} is true, @file{/etc/guix/acl} cannot be
+When @code{authorize-key?} is true, @file{/etc/guix/acl} cannot be
changed by invoking @command{guix archive --authorize}. You must
instead adjust @code{guix-configuration} as you wish and
On 2020-10-21, Ludovic Courtès wrote:
> diff --git a/doc/guix.texi b/doc/guix.texi
> index c161012da5..50d2d9a730 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
...
> @@ -14583,6 +14598,27 @@ Whether to use substitutes.
> @item @code{substitute-urls} (default: @code{%default-substitute-urls})
Fixes <https://bugs.gnu.org/39819>.
Reported by Maxim Cournoyer .
* gnu/services/base.scm (substitute-key-authorization): Symlink
DEFAULT-ACL to /etc/guix/acl unconditionally. Add code to optionally
back up /etc/guix/acl if it was possibly modified by hand.
* doc/guix.texi (Base Se
Ludovic Courtès writes:
Hello,
> Jan Nieuwenhuizen skribis:
>
>> Ludovic Courtès writes:
>
>> However, if you have your own substitute server, you now can run guix
>> archive --authorize < ..., e.g. at bootstrap/install time. For such
>> cases, IWBN to have a --authorized-key argument to guix b
Hi,
Jan Nieuwenhuizen skribis:
> Ludovic Courtès writes:
>
> Hello!
>
>> For some reason, /etc/guix/acl is not declarative on Guix System: we let
>> users modify it and assume it’s stateful, which can surprise users as in
>> <https://issues.guix.gnu.or
Ludovic Courtès writes:
Hello!
> For some reason, /etc/guix/acl is not declarative on Guix System: we let
> users modify it and assume it’s stateful, which can surprise users as in
> <https://issues.guix.gnu.org/39819>.
>
> Should we make it declarative, just like most of /e
On Sun, Oct 11, 2020 at 12:39:17PM +0200, Ludovic Courtès wrote:
> Hi!
>
> For some reason, /etc/guix/acl is not declarative on Guix System: we let
> users modify it and assume it’s stateful, which can surprise users as in
> <https://issues.guix.gnu.org/39819>.
>
> Sh
Hi!
For some reason, /etc/guix/acl is not declarative on Guix System: we let
users modify it and assume it’s stateful, which can surprise users as in
<https://issues.guix.gnu.org/39819>.
Should we make it declarative, just like most of /etc? I think so. For
a build farm like berlin, it
d new systems from
>>> that because the filename for the "Berlin ACL key" changed. (Or at
>>> least, I couldn't run "guix system vm".)
>>>
>>> I pushed out a "fix" for this. I hope it's ok.
>>
>> Thanks for the
Dear Marius,
On Sun, 12 Jul 2020 at 14:33, Marius Bakke wrote:
> One possible solution that has been discussed before is to have the CI
> continously merge master to a 'stable' branch when lights are green.
> There are quite a few challenges to solve with that approach though.
>
> We could make
Hi Jonathan,
On Sun, 12 Jul 2020 at 13:42, Jonathan Brielmaier
wrote:
> As I ran into all those little errors with `guix pull` this week-end, I
> wonder if we can do better.
>
> So maybe some pre-checkin CI which tests that a commit/commit series
> doesn't break `guix pull`. What do you think?
Jonathan Brielmaier writes:
> On 12.07.20 03:44, Christopher Lemmer Webber wrote:
>> Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
>> of Guix, and it looks like it wasn't possible to build new systems from
>> that because the filename for th
On 12.07.20 03:44, Christopher Lemmer Webber wrote:
> Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
> of Guix, and it looks like it wasn't possible to build new systems from
> that because the filename for the "Berlin ACL key" changed. (Or at
Christopher Lemmer Webber writes:
> Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
> of Guix, and it looks like it wasn't possible to build new systems from
> that because the filename for the "Berlin ACL key" changed. (Or at
> least, I c
Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
of Guix, and it looks like it wasn't possible to build new systems from
that because the filename for the "Berlin ACL key" changed. (Or at
least, I couldn't run "guix system vm".)
I pushed out
l...@gnu.org (Ludovic Courtès) writes:
> Hello Kei,
>
> Kei Kebreau skribis:
>
>> I discovered that the Acl tests are failing partly because the coreutils
>> seemingly aren't compiled with Acl support before the tests are run
>> (even though acl is an input t
I discovered that the Acl tests are failing partly because the coreutils
seemingly aren't compiled with Acl support before the tests are run
(even though acl is an input to coreutils). The tests are written with
the assumption that the coreutils are built with Acl support. An example
is i
* gnu/packages/freedesktop.scm (elogind) [inputs]: Add acl.
---
gnu/packages/freedesktop.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/freedesktop.scm b/gnu/packages/freedesktop.scm
index 37707796e..ddbac762a 100644
--- a/gnu/packages/freedesktop.scm
+++ b
; same.
> From c85bc49b864570b27af95260bb7e59d7db660b36 Mon Sep 17 00:00:00 2001
> From: Manolis Ragkousis
> Date: Sat, 25 Apr 2015 18:18:53 +0300
> Subject: [PATCH] gnu: acl: Fix i686-gnu build.
>
> * gnu/packages/patches/acl-hurd-path-max.patch: New file.
> * gnu-system.am (d
Hello guix
This is a patch that allows acl to be built when hurd is targeted.
Is it okay to push to wip-hurd?
I have rebased wip-hurd on top of master locally and I have removed
some things from commit ea44aa1b33933328aa0b7b33f36dfcc90aaa8c74
that were no longer needed.
I will resend that patch
l...@gnu.org (Ludovic Courtès) writes:
> ndreas Enge skribis:
>
>> Adding optional inputs to kdelibs, I notice that acl is not recognised.
>> The reason is that the header files are not installed. Would that be easy
>> to modify? Maybe by changing the line
>> (
On Fri, Nov 07, 2014 at 10:15:12AM +0100, Ludovic Courtès wrote:
> OK. Could you create the ‘core-updates’ branch and commit it?
Done. I have also worked a bit on tests and got them to execute at least.
Now a few of the first ones fail like this:
[16] $ ls -dl d | awk '{print $1}' | sed 's/.$//g
Andreas Enge skribis:
> From 34f1cd18d14a0a75d73e7f4b57f76495edae56d8 Mon Sep 17 00:00:00 2001
> From: Andreas Enge
> Date: Thu, 6 Nov 2014 22:56:32 +0100
> Subject: [PATCH] gnu: acl: Also install header files.
>
> * gnu/packages/acl.scm (acl): Install header files. D
The attached patch should do the job.
Andreas
>From 34f1cd18d14a0a75d73e7f4b57f76495edae56d8 Mon Sep 17 00:00:00 2001
From: Andreas Enge
Date: Thu, 6 Nov 2014 22:56:32 +0100
Subject: [PATCH] gnu: acl: Also install header files.
* gnu/packages/acl.scm (acl): Install header files. Drop unnee
There is no occurrence of the string "SHELL"
in include/buildmacros for the current version.
> Anyway, this is depended on by Coreutils, so changes should go to
> core-updates.
Okay. Should we open the branch?
> In the meantime, you can always add a fixed version of ACL for use
Andreas Enge skribis:
> Adding optional inputs to kdelibs, I notice that acl is not recognised.
> The reason is that the header files are not installed. Would that be easy
> to modify? Maybe by changing the line
> (zero? (system* "make" "install" "i
Adding optional inputs to kdelibs, I notice that acl is not recognised.
The reason is that the header files are not installed. Would that be easy
to modify? Maybe by changing the line
(zero? (system* "make" "install" "install-lib")))
to
(zero? (system* "make
"Jason Self" skribis:
> From 2f4f94c660c58b3c46c1ce485c22017eebe255ad Mon Sep 17 00:00:00 2001
> From: Jason Self
> Date: Sat, 19 Jul 2014 13:24:47 -0700
> Subject: [PATCH 1/1] gnu: acl: Update to 2.2.52.
>
> * gnu/packages/acl.scm (acl): Update to version 2.2.52.
* gnu/packages/acl.scm (acl): Update to version 2.2.52.
From 2f4f94c660c58b3c46c1ce485c22017eebe255ad Mon Sep 17 00:00:00 2001
From: Jason Self
Date: Sat, 19 Jul 2014 13:24:47 -0700
Subject: [PATCH 1/1] gnu: acl: Update to 2.2.52.
* gnu/packages/acl.scm (acl): Update to version 2.2.52.
Signed
32 matches
Mail list logo
