Re: [PATCH] doc: Improve guile load path recommendation.

[myglc2]

On 04/15/2017 at 16:20 Chris Marusich writes:

> myglc2  writes:
>
>> Using geiser-guile-load-path as currently recommended results in source
>> that was already compiled by the guix build being recompiled :-(
>>
>> This patch avoids that. It also moves the configuration to
>> '~/.bash_profile' so it applies when guile is used directly.
>>
>> From 4585499f99336dc3e626c3105f0539ef3b5ce33c Mon Sep 17 00:00:00 2001
>> From: George Clemmer 
>> Date: Sat, 15 Apr 2017 14:21:09 -0400
>> Subject: [PATCH] doc: Improve guile load path recommendation.
>>
>> * doc/contributing.texi (The Perfect Setup): Advise setting GUILE_LOAD_PATH 
>> and
>> GUILE_LOAD_COMPILED_PATH in .bash_profile rather than emacs init.
>> ---
>>  doc/contributing.texi | 19 +++
>>  1 file changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/doc/contributing.texi b/doc/contributing.texi
>> index bbc93424b..d23f55a6b 100644
>> --- a/doc/contributing.texi
>> +++ b/doc/contributing.texi
>> @@ -171,14 +171,17 @@ Emacs: code compilation and evaluation from within 
>> buffers, access to
>>  on-line documentation (docstrings), context-sensitive completion,
>>  @kbd{M-.} to jump to an object definition, a REPL to try out your code,
>>  and more (@pxref{Introduction,,, geiser, Geiser User Manual}).  For
>> -convenient Guix development, make sure to augment Guile’s load path so
>> -that it finds source files from your checkout:
>> -
>> -@lisp
>> -;; @r{Assuming the Guix checkout is in ~/src/guix.}
>> -(with-eval-after-load 'geiser-guile
>> -  (add-to-list 'geiser-guile-load-path "~/src/guix"))
>> -@end lisp
>> +convenient Guix development, make sure to augment Guile’s load paths so
>> +that it finds source and compiled files from your checkout. Assuming the
>> +Guix checkout is in @code{~/src/guix}, add the following lines to your
>> +‘~/.bash_profile’ (*note (bash)Bash Startup Files::):
>> +
>> +@verbatim
>> +export GUILE_LOAD_PATH=\
>> +"$HOME/src/guix${GUILE_LOAD_PATH:+:$GUILE_LOAD_PATH}"
>> +export GUILE_LOAD_COMPILED_PATH=\
>> +"$HOME/src/guix${GUILE_LOAD_COMPILED_PATH:+:$GUILE_LOAD_COMPILED_PATH}"
>> +@end verbatim
>>  
>>  To actually edit the code, Emacs already has a neat Scheme mode.  But in
>>  addition to that, you must not miss
>
> How does this change avoid the recompilation you mentioned?  It looks to
> me like before this change, Geiser would find Guix modules in
> ~/src/guix, and after this change, Geiser will still find Guix modules
> in ~/src/guix.  So from that perspective, it seems like it won't change
> the way Geiser behaves.

Hi Chris, thank you for the comments ;-)

I can report that this has a big, positive effect on the geiser user
experience.  Before this change guile didn't find the compiled files in
the git checkout work tree and so it compiled everything it touched
(putting compiled files in '~/.cache/guile/ccache/'). This produced big
delays and it just felt broken.

> However, before this change, other Guile processes (e.g., launched via
> "guix package -i foo") would not see the modules in ~/src/guix, and
> after this change, it looks to me like they will see the modules in
> ~/src/guix.

I believe the guix commands find compiled files in the git work tree
because '~/.config/guix/latest' points there ...

  /home/g1/.config/guix/latest -> /home/g1/src/guix/

> If the intended goal is just to let Geiser know where the
> Guix source lives, then this method might not be the best solution,
> since it will affect programs outside of Geiser, too.
>
> If I'm mistaken, please help me understand what I'm missing.

The geiser doc says ...

   You can also specify a couple more initialisation parameters.  For
Guile, 'geiser-guile-load-path' is a list of paths to add to its load
path (and its compiled load path) when it's started, ...

... which implies that geiser sets the compiled load path to the
geiser-guile-load-path. But it does not seem to be doing that. I guess
that could be a bug.

Regarding our other guile apps ...

The guix makefile unsets GUILE_LOAD_COMPILED_PATH, so the guix build is
unaffected.

With the proposed change, a guile user exploring guix via the REPL has a
better experience than before.

Are there other guile apps you have in mind?

HTH, please let me know. - George

A simple workflow for adding apps guix

[Feng Shu]

The below is the workflow I used current, any other
simpler workflow exists?  comments are welcome!

* I want to add emacs-exwm to emacs.scm

* Fetch newest code
#+BEGIN_EXAMPLE
cd ~/project/guix/  # my guix repo dir
git pull --rebase
#+END_EXAMPLE

* Install newest guix
#+BEGIN_EXAMPLE
guix pull
#+END_EXAMPLE

* Set GUIX_PACKAGE_PATH
#+BEGIN_EXAMPLE
export GUIX_PACKAGE_PATH=${HOME}/guix # I put it to ~/.bashrc :-)
mkdir ~/guix
#+END_EXAMPLE

* Privatize emacs.scm file
#+BEGIN_EXAMPLE
cd ~/guix
mkdir -p gnu/packages
cd gnu/packages
ln -s ~/project/guix/gnu/packages/emacs.scm  # guix repo's emacs.scm file
#+END_EXAMPLE

* Hack -> test -> hack -> test 

edit ~/project/guix/gnu/packages/emacs.scm
...

Build:   guix build emacs-exwm
Rebuild: guix build emacs-exwm --check
Install: guix package -i emacs-exwm


-- 

Re: bug#26339: problem with commit abae042

[Danny Milosavljevic]

It has been reverted.

Re: [PATCH] doc: Improve guile load path recommendation.

[Chris Marusich]

myglc2  writes:

> Using geiser-guile-load-path as currently recommended results in source
> that was already compiled by the guix build being recompiled :-(
>
> This patch avoids that. It also moves the configuration to
> '~/.bash_profile' so it applies when guile is used directly.
>
> From 4585499f99336dc3e626c3105f0539ef3b5ce33c Mon Sep 17 00:00:00 2001
> From: George Clemmer 
> Date: Sat, 15 Apr 2017 14:21:09 -0400
> Subject: [PATCH] doc: Improve guile load path recommendation.
>
> * doc/contributing.texi (The Perfect Setup): Advise setting GUILE_LOAD_PATH 
> and
> GUILE_LOAD_COMPILED_PATH in .bash_profile rather than emacs init.
> ---
>  doc/contributing.texi | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/doc/contributing.texi b/doc/contributing.texi
> index bbc93424b..d23f55a6b 100644
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -171,14 +171,17 @@ Emacs: code compilation and evaluation from within 
> buffers, access to
>  on-line documentation (docstrings), context-sensitive completion,
>  @kbd{M-.} to jump to an object definition, a REPL to try out your code,
>  and more (@pxref{Introduction,,, geiser, Geiser User Manual}).  For
> -convenient Guix development, make sure to augment Guile’s load path so
> -that it finds source files from your checkout:
> -
> -@lisp
> -;; @r{Assuming the Guix checkout is in ~/src/guix.}
> -(with-eval-after-load 'geiser-guile
> -  (add-to-list 'geiser-guile-load-path "~/src/guix"))
> -@end lisp
> +convenient Guix development, make sure to augment Guile’s load paths so
> +that it finds source and compiled files from your checkout. Assuming the
> +Guix checkout is in @code{~/src/guix}, add the following lines to your
> +‘~/.bash_profile’ (*note (bash)Bash Startup Files::):
> +
> +@verbatim
> +export GUILE_LOAD_PATH=\
> +"$HOME/src/guix${GUILE_LOAD_PATH:+:$GUILE_LOAD_PATH}"
> +export GUILE_LOAD_COMPILED_PATH=\
> +"$HOME/src/guix${GUILE_LOAD_COMPILED_PATH:+:$GUILE_LOAD_COMPILED_PATH}"
> +@end verbatim
>  
>  To actually edit the code, Emacs already has a neat Scheme mode.  But in
>  addition to that, you must not miss

How does this change avoid the recompilation you mentioned?  It looks to
me like before this change, Geiser would find Guix modules in
~/src/guix, and after this change, Geiser will still find Guix modules
in ~/src/guix.  So from that perspective, it seems like it won't change
the way Geiser behaves.

However, before this change, other Guile processes (e.g., launched via
"guix package -i foo") would not see the modules in ~/src/guix, and
after this change, it looks to me like they will see the modules in
~/src/guix.  If the intended goal is just to let Geiser know where the
Guix source lives, then this method might not be the best solution,
since it will affect programs outside of Geiser, too.

If I'm mistaken, please help me understand what I'm missing.

-- 
Chris


signature.asc
Description: PGP signature

Re: bug#26339: problem with commit abae042

[Leo Famulari]

On Sat, Apr 15, 2017 at 08:17:59PM +0200, Mathieu Othacehe wrote:
> 
> I think there's a problem with commit abae042 :
> 
> * profile-grub-entries become unused and is still present.
> * When using switch-generation, operating-system-bootcfg is not
> * called. So, the kernel arguments are not correctly set (--root,
> * --system and --load), and the resulting entries in grub.cfg are broken.

This should be reverted immediately, since the master branch is what
users get from `guix pull`, so we really must not break it.


signature.asc
Description: PGP signature

Re: Services can now have a default value

[ng0]

Ludovic Courtès transcribed 0.4K bytes:
> Hello Guix!
> 
> With commit 1bb895eabf74a1e571887eb1521915e668a5c28d, service types can
> declare a default value for their instances.  After this one can write:
> 
>   (service openssh-service-type)
> 
> instead of:
> 
>   (service openssh-service-type (openssh-configuration))
> 
> A bit of typing saved!
> 
> Note that this changes breaks the ABI for services, so make sure to run
> “make clean-go && make”.
> 
> Feedback welcome!
> 
> Ludo’.
> 

Before I lock myself out, this is the definition for defaults.
So:
 (service openssh-service-type
  (openssh-configuration
(port-number 12121)))

becomes:
  (service openssh-service-type
  (port-number 12121))

or is this just a definition for defaults and not the configuration, and
when the configuration is specified it is still like before this commit?
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Services can now have a default value

[Ludovic Courtès]

Hello Guix!

With commit 1bb895eabf74a1e571887eb1521915e668a5c28d, service types can
declare a default value for their instances.  After this one can write:

  (service openssh-service-type)

instead of:

  (service openssh-service-type (openssh-configuration))

A bit of typing saved!

Note that this changes breaks the ABI for services, so make sure to run
“make clean-go && make”.

Feedback welcome!

Ludo’.

bootloader and kernel arguments "--root", "--system", "--load"

[Danny Milosavljevic]

Ok, I'm in the process of reverting the patches to grub.

--

Problem analysis:

- (profile-boot-parameters ...) doesn't pick up the correct kernel-arguments.  
It's reading them from a parameters file for the system generation back then, 
for example from /gnu/store/x8ymiksnhfyvjdi8ms38ysc4yr92lyk9-system/parameters, 
which contains:

(boot-parameters
  (version 0)
  (label "GNU with Linux-Libre 4.5.1 (beta)")
  (root-device "/dev/sda1")
  (kernel "/gnu/store/h977riqrp7c3w2v0mcpp48ldcapy09gx-linux-libre-4.5.1")
  (kernel-arguments ("crashkernel=256M" "modprobe.blacklist=pcspkr,snd_pcsp" 
"quiet" "acpi_osi=Linux" "clocksource=acpi_pm"))
  (initrd (string-append 
"/gnu/store/8w1abpwlhnilibiamcp6j01rhjh9k5ix-base-initrd" "/initrd")))

, which indeed doesn't contain the correct kernel arguments for it to boot.

Why not?  Shouldn't we just store the correct arguments in there eventually?

Those kernel arguments should include (in the front):

linux-arguments
let root = (boot-parameters-root-device params) or #f
let root-device = (if (bytevector? root) (uuid->string root) root)
let system = "/gnu/store/x8ymiksnhfyvjdi8ms38ysc4yr92lyk9-system" in
"--root="
"--system="
"--load=/boot"
.

Or is it something grub-specific?

Or is it because we don't know system's own hash value in order to be able to 
write it there?

Would it be good to (later) replace the kernel-arguments accessor by a 
procedure that also takes system and root and prepends them on-the-fly?

i.e.

(define (boot-parameters-all-kernel-arguments params system root)
  (cons
(string-append "--root=" root)
(cons
  (string-append "--system=" system)
  ... load etc
  (boot-parameters-kernel-arguments params

... and only use this one, never boot-parameters-kernel-arguments anywhere else?

Re: Guix command line flag consistency

[Mike Swierczek]

On 04/15/2017 01:43 PM, Hartmut Goebel wrote:


Am 14.04.2017 um 22:57 schrieb Mike Swierczek:

I'd much prefer if both the short and long command line arguments
accepted their argument in any arrangement.

I also stumbled over "--show=foo" failing. I suggest guix should follow
the GNU command lien parsing conventions. Maybe this could be extended
with the possibility to unambiguous shorten long options.


Good idea on unambiguous shortening of long options.  That sounds good too.

I don't mind trying to implement all of this, I just want to make sure 
the team likes the idea first.


-Mike

[PATCH] doc: Improve guile load path recommendation.

[myglc2]

Using geiser-guile-load-path as currently recommended results in source
that was already compiled by the guix build being recompiled :-(

This patch avoids that. It also moves the configuration to
'~/.bash_profile' so it applies when guile is used directly.

>From 4585499f99336dc3e626c3105f0539ef3b5ce33c Mon Sep 17 00:00:00 2001
From: George Clemmer 
Date: Sat, 15 Apr 2017 14:21:09 -0400
Subject: [PATCH] doc: Improve guile load path recommendation.

* doc/contributing.texi (The Perfect Setup): Advise setting GUILE_LOAD_PATH and
GUILE_LOAD_COMPILED_PATH in .bash_profile rather than emacs init.
---
 doc/contributing.texi | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index bbc93424b..d23f55a6b 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -171,14 +171,17 @@ Emacs: code compilation and evaluation from within buffers, access to
 on-line documentation (docstrings), context-sensitive completion,
 @kbd{M-.} to jump to an object definition, a REPL to try out your code,
 and more (@pxref{Introduction,,, geiser, Geiser User Manual}).  For
-convenient Guix development, make sure to augment Guile’s load path so
-that it finds source files from your checkout:
-
-@lisp
-;; @r{Assuming the Guix checkout is in ~/src/guix.}
-(with-eval-after-load 'geiser-guile
-  (add-to-list 'geiser-guile-load-path "~/src/guix"))
-@end lisp
+convenient Guix development, make sure to augment Guile’s load paths so
+that it finds source and compiled files from your checkout. Assuming the
+Guix checkout is in @code{~/src/guix}, add the following lines to your
+‘~/.bash_profile’ (*note (bash)Bash Startup Files::):
+
+@verbatim
+export GUILE_LOAD_PATH=\
+"$HOME/src/guix${GUILE_LOAD_PATH:+:$GUILE_LOAD_PATH}"
+export GUILE_LOAD_COMPILED_PATH=\
+"$HOME/src/guix${GUILE_LOAD_COMPILED_PATH:+:$GUILE_LOAD_COMPILED_PATH}"
+@end verbatim
 
 To actually edit the code, Emacs already has a neat Scheme mode.  But in
 addition to that, you must not miss
-- 
2.12.2

Re: problem with commit abae042

[Mathieu Othacehe]

> Too bad this is such a huge changeset - it's quite difficult to find a safe 
> path.

Yes, and my split between commit isn't great, sorry about that.

> Do you have an idea how to fix it? 

Nothing trivial. Plus I didn't notice before that
profile-bootloader-entries and operating-system-bootcfg had parts that
could have been factorized.

>
> Would it be good to press forward with the other patches or should I back it 
> out?

Maybe the safer approch would be to revert this commit. I'll publish new
patches and try to find a better approach for
profile-bootloader-entries, if you're ok ?

Thank you,

Mathieu

Re: problem with commit abae042

[Danny Milosavljevic]

Hi,

On Sat, 15 Apr 2017 20:17:59 +0200
Mathieu Othacehe  wrote:

> I think there's a problem with commit abae042 :
> 
> * profile-grub-entries become unused and is still present.

I know, I can't remove it without review, far too dangerous.

> * When using switch-generation, operating-system-bootcfg is not
> * called. So, the kernel arguments are not correctly set (--root,
> * --system and --load), and the resulting entries in grub.cfg are broken.

Yes, indeed.  I'm working on it.  If I can't get it to work today I'll back it 
out again.

Too bad this is such a huge changeset - it's quite difficult to find a safe 
path.

Do you have an idea how to fix it? 

Would it be good to press forward with the other patches or should I back it 
out?

Re: Getting rid of alpha label

[Pjotr Prins]

On Fri, Apr 14, 2017 at 09:50:01AM -0500, Christopher Allan Webber wrote:
> >   1. on the “TEST” button on the home page;
> >   2. under GuixSD at .
> >
> > I think we can remove #1.  Is this what you had in mind?
> >
> > Cheers,
> > Ludo’.
> 
> +1

ACK

-- 

problem with commit abae042

[Mathieu Othacehe]

I think there's a problem with commit abae042 :

* profile-grub-entries become unused and is still present.
* When using switch-generation, operating-system-bootcfg is not
* called. So, the kernel arguments are not correctly set (--root,
* --system and --load), and the resulting entries in grub.cfg are broken.

Mathieu

Re: Guix command line flag consistency

[Hartmut Goebel]

Am 14.04.2017 um 22:57 schrieb Mike Swierczek:
> I'd much prefer if both the short and long command line arguments
> accepted their argument in any arrangement. 

I also stumbled over "--show=foo" failing. I suggest guix should follow
the GNU command lien parsing conventions. Maybe this could be extended
with the possibility to unambiguous shorten long options.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH 05/20] gnu: Add python-sphinx-1.3.3

[Hartmut Goebel]

Am 15.04.2017 um 19:28 schrieb Hartmut Goebel:
> Am 14.04.2017 um 12:13 schrieb Muriithi Frederick Muriuki:
>>  (define-public python2-sphinx-rtd-theme-0.1.9
>>(package-with-python2 python-sphinx-rtd-theme-0.1.9))
>> +
>> +(define-public python-sphinx-1.3.3
>> +  ;; python-httpretty has a hard requirement for
>> +  ;; sphinx == 1.3.3
> Please test if it works with an up-to-date version of sphinx, too. There
> are very few reasons for requiring strict version of a tool like sphinx
> or sphinx-rtd-them. And we should avoid adding versions over versions of
> packages.
https://github.com/gabrielfalcao/HTTPretty/blob/0.8.14/requirements.txt
says:

# HTTPretty doesn't have any requirements per se so far. yay!

So I assume you take the version definitions in "development.txt" as
"hard requirement" - but this file only defines *one* valid set of
dependencies. So please review *all* the packages you say
"python-httpretty has a hard requirement" and try to get rid of them. It
may be even better to patch or "substitute" httpretty to make it work
with our set of versions instead of piling of version of packages used
only for this one. Thanks.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: http://www.goebel-consult.de/blog/verschlusselte-mailingslisten
Kolumne:
http://www.cissp-gefluester.de/2011-08-horrorszenario-bring-your-own-device

Re: [PATCH 06/20] gnu: Add python-coverage-4.0.3

[Hartmut Goebel]

Am 14.04.2017 um 12:13 schrieb Muriithi Frederick Muriuki:
> +  ;; httpretty has a hard requirement for coverage==4.0.3

Same here.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH 05/20] gnu: Add python-sphinx-1.3.3

[Hartmut Goebel]

Am 14.04.2017 um 12:13 schrieb Muriithi Frederick Muriuki:
>  (define-public python2-sphinx-rtd-theme-0.1.9
>(package-with-python2 python-sphinx-rtd-theme-0.1.9))
> +
> +(define-public python-sphinx-1.3.3
> +  ;; python-httpretty has a hard requirement for
> +  ;; sphinx == 1.3.3

Please test if it works with an up-to-date version of sphinx, too. There
are very few reasons for requiring strict version of a tool like sphinx
or sphinx-rtd-them. And we should avoid adding versions over versions of
packages.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH 01/20] gnu: Add python-radon

[Hartmut Goebel]

Am 14.04.2017 um 12:13 schrieb Muriithi Frederick Muriuki:
> +   ("python-flake8-polyfill"
> +,python-flake8-polyfill)
I assume this should be a native-input, shouldn't it.

Also please write this in a single line.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH] gnu: add meson

[Marius Bakke]

Corentin Bocquillon  writes:

> * gnu/packages/meson.scm (meson.scm) Add meson package.

Hello! Thanks for this patch. See comments inline.

Could you send the updated patch to "guix-patc...@gnu.org"?

Please also create the patch with `git format-patch` and either send it
as attachment or through `git send-email` so the formatting is
preserved. Thanks in advance!

> ---
>  gnu/packages/meson.scm | 47
> +++ 1 file changed, 47 
> insertions(+)
> create mode 100644 gnu/packages/meson.scm

Maybe this could go in "build-tools.scm" instead of creating a new module.

> +(define-public meson
> +  (package
> +(name "meson")
> +(version "0.39.1")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append
> "https://github.com/mesonbuild/meson/";
> +  "archive/" version ".tar.gz"))
> +  (file-name (string-append name "-" version ".tar.gz"))
> +  (sha256
> +   (base32
> +
> "1jwgd6sl7zl7h16id3405gwk6vlkk86ggwrp0k47njwkxmryq8d4"
> +(build-system python-build-system)
> +(inputs `(("python" ,python)

"python" is an implicit input when using python-build-system, so that
can be omitted.

> +  ("ninja", ninja)))
> +(home-page "https://mesonbuild.com/";)
> +(synopsis "Meson build system")
> +(description
> + "The meson build system is focused on user-friendliness and
> speed.")

Can you expand on this a little? What makes it different, what are the
use cases etc? It would also be good to see a package that uses it, but
I guess that is coming later ;-)

Looks good otherwise, apart from the formatting!


signature.asc
Description: PGP signature

Re: ld-wrapper is broken in core-updates due to guile-2.2 (host running guile-2.0)

[Sergei Trofimovich]

On Fri, 14 Apr 2017 21:59:47 +0100
Sergei Trofimovich  wrote:

> Efraim noticed core-updates breakage on package libgpg-error.
> 
> TL;DR:
> 
>   ld-wrapper package embeds guile-2.2 interpreter
>   to interpret ld.go bytecode built by guile-2.0.
>   I have no idea how to fix it but still decided to
>   share my findings so far.

Confirmed guile-2.2 is triggering failure:

reverting commit 34d624cef51f0e4eb4e888622b60fc2befe31fa7
("gnu: Build derivations with Guile 2.2 by default.") fixes libgpg-error build.

Another less obvious problem caused by guile-2.2 is triggered in bash-static:

  guix-core-updates $ ./pre-inst-env guix build bash-static
  The following derivation will be built:
 /gnu/store/hr3g5avmb9fmgr047990r9mc6gmnq674-bash-static-4.4.12.drv
  @ build-started 
/gnu/store/hr3g5avmb9fmgr047990r9mc6gmnq674-bash-static-4.4.12.drv - 
x86_64-linux 
/var/log/guix/drvs/hr//3g5avmb9fmgr047990r9mc6gmnq674-bash-static-4.4.12.drv.bz2
  ice-9/psyntax.scm:1534:32: In procedure expand-macro:
  ice-9/psyntax.scm:1534:32: Syntax error:
  
/gnu/store/bc7pyl426zaa2489qp97bqaycv2ir2v1-bash-static-4.4.12-guile-builder:1:2300:
 source expression failed to match any pattern in form (%modify-phases phases* 
(delete (quote move-development-files)))
  builder for 
`/gnu/store/hr3g5avmb9fmgr047990r9mc6gmnq674-bash-static-4.4.12.drv' failed 
with exit code 1
  @ build-failed 
/gnu/store/hr3g5avmb9fmgr047990r9mc6gmnq674-bash-static-4.4.12.drv - 1 builder 
for `/gnu/store/hr3g5avmb9fmgr047990r9mc6gmnq674-bash-static-4.4.12.drv' failed 
with exit code 1
  guix build: error: build failed: build of 
`/gnu/store/hr3g5avmb9fmgr047990r9mc6gmnq674-bash-static-4.4.12.drv' failed

It looks like guile-2.2 has different syntax checking rules which
is triggered by the following modify-phases call site:

[ http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bash.scm#n204 ]
  ...
 ((#:phases phases)
  `(modify-phases ,phases
 ;; No loadable modules.
 (delete 'move-development-files

[ http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/utils.scm#n550 ]
  ...
  (define-syntax-rule (modify-phases phases mod-spec ...)
"Modify PHASES sequentially as per each MOD-SPEC, which may have one of the
  following forms:

(delete )
(replace  )
(add-before   )
(add-after   )

  Where every <*-phase-name> is an expression evaluating to a symbol, and
   an expression evaluating to a procedure."
(let* ((phases* phases)
   (phases* (%modify-phases phases* mod-spec))
   ...)
  phases*))

  (define-syntax %modify-phases
(syntax-rules (delete replace add-before add-after)
  ((_ phases (delete old-phase-name))
   (alist-delete old-phase-name phases))
  ((_ phases (replace old-phase-name new-phase))
   (alist-replace old-phase-name new-phase phases))
  ((_ phases (add-before old-phase-name new-phase-name new-phase))
   (alist-cons-before old-phase-name new-phase-name new-phase phases))
  ((_ phases (add-after old-phase-name new-phase-name new-phase))
   (alist-cons-after old-phase-name new-phase-name new-phase phases

CCed Andy in case it's an obvious bug in guix or guile syntax rewriter.

Reverting commit 34d624cef51f0e4eb4e888622b60fc2befe31fa7
("gnu: Build derivations with Guile 2.2 by default.") fixes bash-static as well.

-- 

  Sergei


pgpHeBSzGTiOX.pgp
Description: Цифровая подпись OpenPGP