geiser-xref-callers does not seem to work

[Chris Marusich]

Hi,

It seems that geiser-xref-callers does not work for me.  I believe I've
configured Geiser correctly, since other commands like
geiser-edit-symbol-at-point and geiser-doc-symbol-at-point do work in
some cases.

Here is a specific example where it fails for me:

* Clone the Guix Git repository (for commit
  9e111db4535b3cd5729e37294ae51d95240334b4 if you want to be precise):

git clone https://git.savannah.gnu.org/git/guix.git

* Configure Geiser for Guix as described in Guix's manual ((guix) The
  Perfect Setup).

* Open gnu/system/vm.scm in the Guix source tree, and run
  switch-to-geiser-module for the (gnu system vm) module.

* Place point on symbol expression->derivation-in-linux-vm on line 203
  (in the definition of the iso9660-image procedure), and press "C-c <".

When I do this, I receive the following message in the minibuffer:

  No callers found for ’expression->derivation-in-linux-vm’

And yet, if I run "M-x rgrep" on the same symbol, there are obviously
many call sites:

  ./gnu/system/vm.scm:68:  #:export (expression->derivation-in-linux-vm
  ./gnu/system/vm.scm:105:(define* (expression->derivation-in-linux-vm name exp
  ./gnu/system/vm.scm:203:  (expression->derivation-in-linux-vm
  ./gnu/system/vm.scm:274:  (expression->derivation-in-linux-vm

What might the problem be?  When I run "M-x geiser-doc-symbol-at-point"
on this symbol, it also claims that there is no documentation
available.  I feel like maybe I've misconfigured something, but I don't
know what.

Here are the Geiser-specific things I've added to my ~/.emacs file:

--8<---cut here---start->8---
;; Tell geiser where guix checkout lives
(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/guix"))

(add-hook 'geiser-repl-mode-hook 'enable-paredit-mode)

;; Keybind customizations
(add-hook 'geiser-mode-hook
  (lambda ()
(local-set-key (kbd "C-c m") 'switch-to-geiser-module)))
(add-hook 'geiser-mode-hook
  (lambda ()
(local-set-key (kbd "C-c i") 'geiser-repl-import-module)))
--8<---cut here---end--->8---

-- 
Chris


signature.asc
Description: PGP signature

Re: Snippets for working on Guix

[Arun Isaac]

>> to avoid the need to type out boilerplate I wrote a couple of snippets
>> that can be used with yasnippet in Emacs, and I thought I should share
>> them with you.
>>
>> These snippets are available:
>>
>>   ./scheme-mode/guix-package
>>   ./scheme-mode/guix-origin
>>   ./scheme-mode/guix-git-reference
>>   ./scheme-mode/guix-hg-reference
>>   ./scheme-mode/guix-cvs-reference
>>   ./scheme-mode/guix-svn-reference
>>   ./text-mode/guix-commit-message-add-package
>>   ./text-mode/guix-commit-message-update-package
>
> That looks really useful!

Indeed, this is very useful! :-)

> Do you think we could add them under etc/emacs in the repo, and somehow
> have them automatically available?  Or should it be in Emacs-Guix?

It would be nice if this was available automatically through emacs-guix.

Apart from the snippets, it would also be nice to somehow automatically
update a package definition -- that is, change the version number,
download the new source, and update the hash. I was trying to work this
out. I was able to get the Guix REPL to download the new source tarball,
but couldn't figure out how to retrieve the new hash from the Guix
REPL. Any pointers?

Re: [bug#29708] Update s-shell

[宋文武]

ng0  writes:

> Ludovic Courtès transcribed 0.4K bytes:
>> ng0  skribis:
>> 
>> > From cf2cbe9e9e525aa9dd697fcedb255a0fbc194ac9 Mon Sep 17 00:00:00 2001
>> > From: ng0 
>> > Date: Thu, 14 Dec 2017 13:22:58 +
>> > Subject: [PATCH] s-shell: Update to commit
>> >  da2e5c20c0c5f477ec3426dc2584889a789b1659.
>> >
>> > * gnu/packages/shells.scm (s-shell): Update to commit 
>> > da2e5c20c0c5f477ec3426dc2584889a789b1659.
>> > (version): Use 'git-version'.
>> 
>> I adjusted the commit log and pushed.
>
> Why is it [version]? Shouldn't it be (version)?
> Even though [version] now makes sense, I've seen
> mostly [] when it followed a () - and that's why
> I've been using ()[] and never(?) [] on its own.

Here the top level is the same as previous line, so it can be ommited:

  * ... (s-shell): ...
  [version]: ...

is same as:

  * ... (s-shell): ...
  (s-shell)[version]: ...

Re: Snippets for working on Guix

[Maxim Cournoyer]

Hi Ricardo!

Ricardo Wurmus  writes:

> Hi Guix,
>
> to avoid the need to type out boilerplate I wrote a couple of snippets
> that can be used with yasnippet in Emacs, and I thought I should share
> them with you.
>
> These snippets are available:
>
>   ./scheme-mode/guix-package
>   ./scheme-mode/guix-origin
>   ./scheme-mode/guix-git-reference
>   ./scheme-mode/guix-hg-reference
>   ./scheme-mode/guix-cvs-reference
>   ./scheme-mode/guix-svn-reference
>   ./text-mode/guix-commit-message-add-package
>   ./text-mode/guix-commit-message-update-package
>

This is pretty fun and useful too! It seems a cleaner approach to the
copy-pasting of previous packages I'm sure many of us are doing ;).

Thanks for sharing!

Maxim

How to customize the kernel

[Chris Marusich]

Hi,

Suppose you want to compile a custom kernel.  Suppose you want to use a
custom kernel configuration.  Currently, none of the logic that builds
linux-libre kernels in Guix is public,, so the implication is that
nobody should be using that to customize their kernel builds.

Is anyone building custom kernels?  How are you doing it?  Are you just
using the "make-linux-libre" procedure anyway, despite the fact that it
supposedly isn't public?  Did you copy it and just modify it to suit
your needs?  Or did you do something totally different?

I am new to compiling the Linux kernel, so it is doubly difficult to
learn how I should do it using Guix.  Any tips would be greatly
appreciated.  I'm guessing one tip might be, "Try building a few Linux
kernels on a more normal distribution, not using Guix, a few times to
get the hang of doing it the 'traditional' way first."  I have not
really done that yet.

-- 
Chris


signature.asc
Description: PGP signature

Re: Building Docker images of GuixSD

[Chris Marusich]

Christopher Baines  writes:

> Unfortunately, while I could get a shell using "docker exec ...", I had
> to start the guix-daemon manually as the shepherd service didn't seem to
> work, at least initially. Also, when I had started it, I tried
> installing a package, and there was some promising output to start off
> with, but then it failed with:
>
>   guix package: error: build failed: cloning builder process: Operation
>   not permitted
>
> Anyway, this is all pretty great! Awesome work getting this far. I'm
> very excited to see what services will run this way, as Docker could
> provide, albeit with some overhead, a layer of interoperability between
> software that can handle Docker containers, and Guix.

I tried making the changes you suggested.  I launched a container
without using docker's --privileged option.  However, the "boot" script
failed because something couldn't mount something in the container.  I
am not excited about the idea of trying to figure out which esoteric
combination of capabilities [1] are needed to run without the
--privileged option, but I suppose that is necessary if I want to
minimize the container's access to the host system.

To be honest, I find it puzzling that Docker requires me to think so
much about the capabilities in the first place.  Perhaps I'm naive, but
I had hoped that within a Docker container, everything would be
"private" in the sense that, as root in the container, I can do anything
and everything, including mounting, including creating device nodes, and
no changes will be visible outside of the container.  The fact that that
is not the case (at least by default) comes as quite a surprise to me.

I also noticed that some services, like nscd, failed to start.  No error
messages anywhere except Shepherd saying something like "could not start
service nscd".  How do I begin to debug something like that?  All I can
think of is to inspect the Guix code that runs the service, and the
Shepherd code, commit time to learning about it, and then hopefully find
a way to insert debug statements of some kind that give me a hint about
what's going wrong.  Is there a faster, better way?

[1] https://docs.docker.com/engine/security/security/#linux-kernel-capabilities

-- 
Chris


signature.asc
Description: PGP signature

Re: GRUB LUKS support is slow?

[Adam Van Ymeren]

On December 15, 2017 8:10:24 PM EST, Tobias Geerinckx-Rice  
wrote:
>Guix,
>
>I'm afraid you'll all be somewhat disappointed by the answer...
>
>Adam Van Ymeren wrote on 16/12/17 at 00:25:
>> On December 15, 2017 5:53:15 PM EST, Mark H Weaver  
>> wrote:
>>> l...@gnu.org (Ludovic Courtès) writes:
>>> 
 I have an encrypted root.  When GRUB asks me for my passphrase, 
 it takes 5–10 seconds after I hit enter before it displays the
 menu; then, once I've selected an entry, it takes another 5 seconds
 or so to boot.
 
 It’s always been this way for me (that’s on UEFI), but I’m
 sufficiently annoyed to write this message today.  :-)
 
 Are others experiencing this as well?  Any hints?
>>> 
>>> I also use a LUKS-encrypted root partition, and the same thing 
>>> happens to me.  I would guess that the cryptographic operations in 
>>> GRUB are not well optimized, but I haven't looked closely.
>>> 
>>> Mark
>> 
>> Even unoptimized 5-10s seems pretty long.  It's not like it has a
>> lot of data to process.
>
>Alas, you'd be wrong :-)
>
>The whole point of the key derivation function (PBKDF2 in this case) is
>to take a long time — i.e., generate *a lot* of data — before deriving
>the actual encryption key from your passphrase. It's basically a slow
>hash, run many times over. That's the delay we're talking about here.
>
>PBKDF2 is designed to be ‘impossible’ to optimise, parallelise, or cut
>short[0], so there's no way around running several seconds of busy work
>before you can even check a passphrase.
>
>On GuixSD, the default run time is:
>
>  $ cryptsetup --help | grep iteration
>  -i, --iter-time=msecsPBKDF2 iteration time for LUKS (in ms)
>  Default PBKDF2 iteration time for LUKS: 2000 (ms)
>
>However, this run time is measured at volume creation time, with all
>fancy CPU features available. It wouldn't surprise me if real-mode[1]
>GRUB and the early kernel code are badly optimised and take longer to
>complete the same number of iterations to obtain the key.
>
>Furthermore, as Ludo' discovered, it's very likely that both GRUB *and*
>Linux will have to re-calculate the key, doubling the total time.
>
>> I have an encrypted root as well, I don't think it takes 5s after I 
>> enter the passphrase to get the grub men, maybe 1 or 2.  Next time I 
>> reboot I'll make a note of it.
>
>It takes about ~7s on my systems (rough guess; they're all servers
>so I'm not that impatient). It should *never* take less than 2 seconds
>unless you or your distro changed ‘--iter-time’, or your volumes were
>encrypted on a different, slower machine, or something's just wrong.
>
>* * *
>
>TLDR: unfortunately, these delays sound quite normal. Aside from
>writing
>optimised PBKDF2 implementations that can run in whatever CPU modes
>GRUB
>does[1], the only way to significantly reduce the wait is to use a
>lower
>‘--iter-time’ when creating volumes.
>
>It's probably not worth it. Your box will boot a few seconds faster;
>your attacker just saw their brute-force speeds double — or worse.
>
>Kind regards,
>
>T G-R
>
>[0]: This is from memory, but should be correct for all practical
> purposes.
>[1]: I presume real-mode; don't ask me how UEFI affects all this.

Ah I definitely didn't think it through, using a key derivation function on the 
passphrase makes sense and definitely explains the slowness.  Thanks for the 
explanation!

Re: GRUB LUKS support is slow?

[Clément Lassieur]

Ludovic Courtès  writes:

> Hello Guix,
>
> I have an encrypted root.  When GRUB asks me for my passphrase, it takes
> 5–10 seconds after I hit enter before it displays the menu; then, once
> I’ve selected an entry, it takes another 5 seconds or so to boot.
>
> It’s always been this way for me (that’s on UEFI), but I’m sufficiently
> annoyed to write this message today.  :-)
>
> Are others experiencing this as well?  Any hints?

I experience the same, and it's very annoying.  I thought it was because
of Libreboot, I'm glad to know it's not (assuming you don't use
Libreboot).

Re: GRUB LUKS support is slow?

[Tobias Geerinckx-Rice]

Guix,

I'm afraid you'll all be somewhat disappointed by the answer...

Adam Van Ymeren wrote on 16/12/17 at 00:25:
> On December 15, 2017 5:53:15 PM EST, Mark H Weaver  
> wrote:
>> l...@gnu.org (Ludovic Courtès) writes:
>> 
>>> I have an encrypted root.  When GRUB asks me for my passphrase, 
>>> it takes 5–10 seconds after I hit enter before it displays the
>>> menu; then, once I've selected an entry, it takes another 5 seconds
>>> or so to boot.
>>> 
>>> It’s always been this way for me (that’s on UEFI), but I’m
>>> sufficiently annoyed to write this message today.  :-)
>>> 
>>> Are others experiencing this as well?  Any hints?
>> 
>> I also use a LUKS-encrypted root partition, and the same thing 
>> happens to me.  I would guess that the cryptographic operations in 
>> GRUB are not well optimized, but I haven't looked closely.
>> 
>> Mark
> 
> Even unoptimized 5-10s seems pretty long.  It's not like it has a
> lot of data to process.

Alas, you'd be wrong :-)

The whole point of the key derivation function (PBKDF2 in this case) is
to take a long time — i.e., generate *a lot* of data — before deriving
the actual encryption key from your passphrase. It's basically a slow
hash, run many times over. That's the delay we're talking about here.

PBKDF2 is designed to be ‘impossible’ to optimise, parallelise, or cut
short[0], so there's no way around running several seconds of busy work
before you can even check a passphrase.

On GuixSD, the default run time is:

  $ cryptsetup --help | grep iteration
  -i, --iter-time=msecsPBKDF2 iteration time for LUKS (in ms)
  Default PBKDF2 iteration time for LUKS: 2000 (ms)

However, this run time is measured at volume creation time, with all
fancy CPU features available. It wouldn't surprise me if real-mode[1]
GRUB and the early kernel code are badly optimised and take longer to
complete the same number of iterations to obtain the key.

Furthermore, as Ludo' discovered, it's very likely that both GRUB *and*
Linux will have to re-calculate the key, doubling the total time.

> I have an encrypted root as well, I don't think it takes 5s after I 
> enter the passphrase to get the grub men, maybe 1 or 2.  Next time I 
> reboot I'll make a note of it.

It takes about ~7s on my systems (rough guess; they're all servers
so I'm not that impatient). It should *never* take less than 2 seconds
unless you or your distro changed ‘--iter-time’, or your volumes were
encrypted on a different, slower machine, or something's just wrong.

* * *

TLDR: unfortunately, these delays sound quite normal. Aside from writing
optimised PBKDF2 implementations that can run in whatever CPU modes GRUB
does[1], the only way to significantly reduce the wait is to use a lower
‘--iter-time’ when creating volumes.

It's probably not worth it. Your box will boot a few seconds faster;
your attacker just saw their brute-force speeds double — or worse.

Kind regards,

T G-R

[0]: This is from memory, but should be correct for all practical
 purposes.
[1]: I presume real-mode; don't ask me how UEFI affects all this.

Re: GRUB LUKS support is slow?

[Adam Van Ymeren]

On December 15, 2017 5:53:15 PM EST, Mark H Weaver  wrote:
>l...@gnu.org (Ludovic Courtès) writes:
>
>> I have an encrypted root.  When GRUB asks me for my passphrase, it
>takes
>> 5–10 seconds after I hit enter before it displays the menu; then,
>once
>> I’ve selected an entry, it takes another 5 seconds or so to boot.
>>
>> It’s always been this way for me (that’s on UEFI), but I’m
>sufficiently
>> annoyed to write this message today.  :-)
>>
>> Are others experiencing this as well?  Any hints?
>
>I also use a LUKS-encrypted root partition, and the same thing happens
>to me.  I would guess that the cryptographic operations in GRUB are not
>well optimized, but I haven't looked closely.
>
>  Mark

Even unoptimized 5-10s seems pretty long.  It's not like it has a lot of data 
to process.

I have an encrypted root as well, I don't think it takes 5s after I enter the 
passphrase to get the grub men, maybe 1 or 2.  Next time I reboot I'll make a 
note of it.

Re: GRUB LUKS support is slow?

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> I have an encrypted root.  When GRUB asks me for my passphrase, it takes
> 5–10 seconds after I hit enter before it displays the menu; then, once
> I’ve selected an entry, it takes another 5 seconds or so to boot.
>
> It’s always been this way for me (that’s on UEFI), but I’m sufficiently
> annoyed to write this message today.  :-)
>
> Are others experiencing this as well?  Any hints?

I also use a LUKS-encrypted root partition, and the same thing happens
to me.  I would guess that the cryptographic operations in GRUB are not
well optimized, but I haven't looked closely.

  Mark

GRUB LUKS support is slow?

[Ludovic Courtès]

Hello Guix,

I have an encrypted root.  When GRUB asks me for my passphrase, it takes
5–10 seconds after I hit enter before it displays the menu; then, once
I’ve selected an entry, it takes another 5 seconds or so to boot.

It’s always been this way for me (that’s on UEFI), but I’m sufficiently
annoyed to write this message today.  :-)

Are others experiencing this as well?  Any hints?

Ludo’.

Re: Snippets for working on Guix

[Ricardo Wurmus]

Hi Ludo,

> Ricardo Wurmus  skribis:
>
>> to avoid the need to type out boilerplate I wrote a couple of snippets
>> that can be used with yasnippet in Emacs, and I thought I should share
>> them with you.
>>
>> These snippets are available:
>>
>>   ./scheme-mode/guix-package
>>   ./scheme-mode/guix-origin
>>   ./scheme-mode/guix-git-reference
>>   ./scheme-mode/guix-hg-reference
>>   ./scheme-mode/guix-cvs-reference
>>   ./scheme-mode/guix-svn-reference
>>   ./text-mode/guix-commit-message-add-package
>>   ./text-mode/guix-commit-message-update-package
>
> That looks really useful!
>
> Do you think we could add them under etc/emacs in the repo, and somehow
> have them automatically available?  Or should it be in Emacs-Guix?

Sure.  To use them you’d only have to add the directory to
“yas-snippets-dirs”.  I’ll document this in contributing.texi.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: [PATCH] gnu: python2-pyicu: Disable failing test.

[Tobias Geerinckx-Rice]

Mark,

Mark Meyer wrote on 15/12/17 at 13:30:
> However, for some reason python2-vobject fails to pick up this change
> and fails to build :(

Nuts. You're right.

Long story and 2 drafts short: I had some mystical (and wrong) ideas
about package-with-python2 that have now been set straight and pushed to
master.

It can do magic all right, but only if you slowly put the rabbit in the
hat while it's watching and loudly say ‘Loook! Rabbit!’.

Like a dog wizard,

T G-R

Re: [WIP][PATCH] profiles: info-dir-file: Don't consider unwanted manifest entries

[Martin Castillo]

Hi,

in the second patch file:
> +  ;; We only need to build the 'dir' file for inputs that does
containing info
> +  ;; manuals.
s/containing/contain

On 15.12.2017 16:12, 宋文武 wrote:> Hello!
>
> Currently we run profile hooks for all manifest inputs, so if you
> install a new package to your profile, all profile hooks will be run
> again, even if the new package doesn't provide info manuals, man pages,
> etc.  Ideally only interested hooks need to be run, eg: if the new
> package has info manuals, then the 'info-dir-file' hook will run.

One would need to filter man-pages too, right?
+ (define interested
+(eval-gexp
+ #~(filter
+(lambda (input)
+  (or (file-exists? (string-append input "/share/info"))
+  (file-exists? (string-append input "/share/man"
+'#$(manifest-inputs manifest

>
> I get it works somehow, but breaks the '--dry-run' functionality which I
> have no idea how to preserve...
>
>
>
>
>
> Needing help and directions, thanks!
>

I can barely write scheme. I can't help much, sorry.

Martin

-- 
GPG: 7FDE 7190 2F73 2C50 236E  403D CC13 48F1 E644 08EC

[WIP][PATCH] profiles: info-dir-file: Don't consider unwanted manifest entries

[宋文武]

Hello!

Currently we run profile hooks for all manifest inputs, so if you
install a new package to your profile, all profile hooks will be run
again, even if the new package doesn't provide info manuals, man pages,
etc.  Ideally only interested hooks need to be run, eg: if the new
package has info manuals, then the 'info-dir-file' hook will run.

I get it works somehow, but breaks the '--dry-run' functionality which I
have no idea how to preserve...

>From 3fd19f5f59c28689e55b3a7dede942014f9b7fb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Fri, 15 Dec 2017 22:20:38 +0800
Subject: [PATCH 1/2] gexp: Add 'eval-gexp'.

* guix/gexp.scm (eval-gexp): New procedure.
---
 guix/gexp.scm | 16 
 1 file changed, 16 insertions(+)

diff --git a/guix/gexp.scm b/guix/gexp.scm
index 1929947d9..678e0c1e6 100644
--- a/guix/gexp.scm
+++ b/guix/gexp.scm
@@ -76,6 +76,7 @@
 gexp->derivation
 gexp->file
 gexp->script
+eval-gexp
 text-file*
 mixed-text-file
 file-union
@@ -1161,6 +1162,21 @@ and '%load-compiled-path' to honor EXP's imported modules."
  #:local-build? #t
  #:substitutable? #f)
 
+(define* (eval-gexp exp #:optional (name "value"))
+  "Return as a monadic value the EXP (a gexp) evaluate to.  This is
+implemented by building a store file NAME that contains the textual
+representation of EXP's value, and then @code{read} from it."
+  (mlet* %store-monad
+  ((drv (gexp->derivation
+ name
+ (gexp (with-output-to-file (ungexp output)
+ (lambda ()
+   (write (eval (quote (ungexp exp)) (current-module))
+ #:local-build? #t
+ #:substitutable? #t))
+   (_   (built-derivations (list drv
+(return (call-with-input-file (derivation->output-path drv) read
+
 (define* (text-file* name #:rest text)
   "Return as a monadic value a derivation that builds a text file containing
 all of TEXT.  TEXT may list, in addition to strings, objects of any type that
-- 
2.13.3

>From ca6aecb94455c6e009d94bf6a0780a8f876bc85d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Fri, 15 Dec 2017 22:38:41 +0800
Subject: [PATCH 2/2] profiles: info-dir-file: Don't consider unwanted manifest
 entries.

* guix/profiles.scm (info-dir-file): Use 'eval-gexp' to filter out those
manifest inputs that doesn't have info manuals.
---
 guix/profiles.scm | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/guix/profiles.scm b/guix/profiles.scm
index cedf9faa8..14b6c4253 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -683,7 +683,22 @@ MANIFEST."
   (define gzip;lazy reference
 (module-ref (resolve-interface '(gnu packages compression)) 'gzip))
 
-  (define build
+  ;; We only need to build the 'dir' file for inputs that does containing info
+  ;; manuals.
+  ;;
+  ;; XXX: This breaks '--dry-run', all manifest inputs will be built before
+  ;; returning the profile derivation...
+  (define interested
+(eval-gexp
+ #~(filter
+(lambda (input)
+  (file-exists? (string-append input "/share/info")))
+'#$(manifest-inputs manifest
+
+  ;; XXX: We have to pass paths of inputs instead of paths of info files,
+  ;; because 'gexp-inputs' only adds inputs for strings which satisfies
+  ;; 'direct-store-path?'.
+  (define (build inputs)
 (with-imported-modules '((guix build utils))
   #~(begin
   (use-modules (guix build utils)
@@ -707,12 +722,12 @@ MANIFEST."
 
   (mkdir-p (string-append #$output "/share/info"))
   (exit (every install-info
-   (append-map info-files
-   '#$(manifest-inputs manifest)))
+   (append-map info-files '#$inputs))
 
-  (gexp->derivation "info-dir" build
-#:local-build? #t
-#:substitutable? #f))
+  (mlet* %store-monad ((inputs interested))
+(gexp->derivation "info-dir" (build inputs)
+  #:local-build? #t
+  #:substitutable? #f)))
 
 (define (ghc-package-cache-file manifest)
   "Return a derivation that builds the GHC 'package.cache' file for all the
-- 
2.13.3



Needing help and directions, thanks!

Re: Snippets for working on Guix

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> to avoid the need to type out boilerplate I wrote a couple of snippets
> that can be used with yasnippet in Emacs, and I thought I should share
> them with you.
>
> These snippets are available:
>
>   ./scheme-mode/guix-package
>   ./scheme-mode/guix-origin
>   ./scheme-mode/guix-git-reference
>   ./scheme-mode/guix-hg-reference
>   ./scheme-mode/guix-cvs-reference
>   ./scheme-mode/guix-svn-reference
>   ./text-mode/guix-commit-message-add-package
>   ./text-mode/guix-commit-message-update-package

That looks really useful!

Do you think we could add them under etc/emacs in the repo, and somehow
have them automatically available?  Or should it be in Emacs-Guix?

Thanks,
Ludo’.

Re: Dualbooting with guixsd not handling grub installation

[Ludovic Courtès]

Hello,

Martin Castillo  skribis:

> I realised a third option for dualbooting:
> menuentry "GuixSD - grub core.img loader" {
>   search --set root --label guix-root --hint hd0,gpt3
>   multiboot /boot/grub/i386-pc/core.img
> }

Indeed, that should always work.

Note that if all you want is dual-boot, this should already be possible
by defining new menu entries in the GuixSD config:

  
https://www.gnu.org/software/guix/manual/html_node/Bootloader-Configuration.html#index-dual-boot

HTH,
Ludo’.

Re: emacs-25.3 aborted

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> I can reproduce this on i686.  After installing Emacs with “guix package
> --no-grafts -u emacs”, however, there is no crash.
>
> The crash only happens with the grafted Emacs.

Indeed:

--8<---cut here---start->8---
$ ./pre-inst-env guix environment -s i686-linux --ad-hoc emacs --pure -- emacs 
-Q

** (emacs-25-3:10005): WARNING **: Error retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not 
provided by any .service files
Fatal error 6: Aborted
Backtrace:
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x81393ec]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8121e63]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x813947c]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e75]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176cce]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176c9e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176cce]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x817705f]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176c9e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176c9e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176c9e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176c9e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176c9e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176c9e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176c9e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176cce]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x817705f]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176cce]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x817705f]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x81770fd]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x817841e]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e7f]
/gnu/store/d39xg06h35k91syyp7k3lhiprwxii2ii-emacs-25.3/bin/emacs-25.3[0x8176e5d]
...
$ git describe
v0.14.0-234-g583016820
--8<---cut here---end--->8---

The backtrace shows that it crashed during the mark phase:

--8<---cut here---start->8---
#0  0xf7f01df9 in __kernel_vsyscall ()
#1  0xf5fdd1d1 in raise () from 
/gnu/store/kzkgc8avgnanrv3ab2g3g8yj7l4bcavj-glibc-2.25/lib/libpthread.so.0
#2  0x08121e91 in terminate_due_to_signal ()
#3  0x0813947c in emacs_abort ()
#4  0x08176e75 in mark_object ()
#5  0x08176e5d in mark_object ()
#6  0x08176cce in mark_object ()
#7  0x08176e5d in mark_object ()
#8  0x08176c9e in mark_object ()
#9  0x08176e5d in mark_object ()
#10 0x08176e5d in mark_object ()
#11 0x08176cce in mark_object ()
#12 0x0817705f in mark_vectorlike ()
#13 0x08176e5d in mark_object ()

[...]

#167 0x0817748a in Fgarbage_collect ()
#168 0x081bf73a in exec_byte_code ()
#169 0x0818d87b in funcall_lambda ()
#170 0x0818dc39 in Ffuncall ()
#171 0x081bf42d in exec_byte_code ()
#172 0x0818d87b in funcall_lambda ()
--8<---cut 

Re: Reproducible installation images

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver  skribis:
>>
>>> l...@gnu.org (Ludovic Courtès) writes:
>>>
 Mark H Weaver  skribis:

> To enable independent verification of these installer images, it would
> be helpful to include the precise commands needed to reproduce these
> images, and the git commit to run them on.
>
> What do you think?

 The manual already gives those commands:

   
 https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html
  (bottom)
   
 https://www.gnu.org/software/guix/manual/html_node/Building-the-Installation-Image.html
>>>
>>> They give the commands, but they do not provide the git commit that you
>>> ran these commands on.
>>
>> True.  So the announcements could say something like:
>>
>>   See the “Binary Installation” and “Building the Installation Image”
>>   sections of the manual on how to recreate these binary images.  The
>>   ‘guix-binary’ tarballs were created from the ‘v0.14.0’ Git tag; the
>>   ‘guixsd-’ images were created from the tip of the ‘version-0.14.0’
>>   branch.
>
> This looks good, except for the "tip of the ‘version-0.14.0’ branch"
> reference, which may change over time.  Ideally, the commit references
> should be reliably immutable.
>
> What do you think?

Yes, you’re right.

This reminds me we should probably automate the announcement generation
entirely (à la Gnulib announce-gen but customized).

Ludo’.

Re: java: switch to icedtea-8 as default JDK

[Gábor Boskovits]

It seems, that it is aslo safe to apply this on master.
This is the patch:

>From 8a4f7bcbbbefe282c15447907a67f81c5bb60aae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
Date: Fri, 15 Dec 2017 15:22:03 +0100
Subject: [PATCH] gnu: Clean up depencies of java-asm.

* gnu/packages/java.scm(java-asm)[native-inputs]: Remove java-junit. (Not used)
* gnu/packages/java.scm(java-asm): Remove native-inputs: became empty.
---
 gnu/packages/java.scm | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 547cc2dc1..6317d21e8 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -2696,8 +2696,6 @@ archives (jar).")
  "-C" "output/build/tmp" "."
  (replace 'install
(install-jars "dist")
-(native-inputs
- `(("java-junit" ,java-junit)))
 (home-page "http://asm.ow2.org/;)
 (synopsis "Very small and fast Java bytecode manipulation framework")
 (description "ASM is an all purpose Java bytecode manipulation and


2017-12-15 15:21 GMT+01:00 Gábor Boskovits :

> Ok, it seems, that java-asm does not currently uses test anyway, so I can
> remove the junit native input.
> Will check if it is also true on master...
>
> 2017-12-15 14:52 GMT+01:00 Gábor Boskovits :
>
>> I've found the problem with java-hamcrest-core.
>> The root cause of this is that java-jarjar uses a bundled copy of asm,
>> version 4.0.
>> This asm version does not support icedtea8.
>>
>> I propose to use java-asm instead of the bundled one.
>>
>> In my opinion the best course of action should be:
>> 1. create a package: java-asm-notest with tests diabled to break the
>> dependency cycle on java-hamcrest-core
>> 2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
>> 3. test if java-hamcrest-core now builds.
>>
>> It is a question if we want to iterate this cycle once more, with a
>> tests-enabled java-asm.
>> WDYT?
>>
>>
>> 2017-12-13 23:50 GMT+01:00 Gábor Boskovits :
>>
>>> I've built the whole covering on my wip-change-default-java8 branch.
>>> The covering is 42 packages.
>>> 19 builds fine.
>>> 19 does not build because java-hamcrest-core does not build.
>>> I'll have a look at this first, this is the most critical.
>>> This is the issue link for reference:
>>> https://github.com/Boskovits/guix/issues/16
>>>
>>> 2017-12-13 19:04 GMT+01:00 Gábor Boskovits :
>>>
 The patches I made:

 This is the trivial:

 From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
 Date: Mon, 11 Dec 2017 21:18:37 +0100
 Subject: [PATCH] Change java toolchain defaults to use java8.

 * gnu/packages/java.scm(icedtea): Point to icedtea-8.
 * gnu/packages/java.scm(ant): Point to ant/java8.
 ---
  gnu/packages/java.scm | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
 index 6dfe554f3..547cc2dc1 100644
 --- a/gnu/packages/java.scm
 +++ b/gnu/packages/java.scm
 @@ -1691,7 +1691,7 @@ IcedTea build harness.")
   '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" 
 "jaxws-drop"
 "jdk-drop" "langtools-drop" "hotspot-drop")))

 -(define-public icedtea icedtea-7)
 +(define-public icedtea icedtea-8)

  
  (define-public ant/java8
 @@ -1754,7 +1754,7 @@ IcedTea build harness.")
  (native-inputs
   `(("jdk" ,icedtea-7 "jdk")

 -(define-public ant ant/java7)
 +(define-public ant ant/java8)

  (define-public ant-apache-bcel
(package


 This is what I'd like to have your opinions on, is it ok to do it this 
 way, or should I rethink it

 (I like this, because this way we can leave ant-build-system alone, and 
 handling of

 default version in java.scm became consistent):

 From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
 From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
 Date: Mon, 11 Dec 2017 21:13:58 +0100
 Subject: [PATCH] gnu:add ant/java7.

 * gnu/packages/java.scm(ant/java7): New variable.
 * gnu/packages/java.scm(ant): Changed variable semantics to point to 
 default ant.
 ---
  gnu/packages/java.scm | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
 index 0be488dec..6dfe554f3 100644
 --- a/gnu/packages/java.scm
 +++ b/gnu/packages/java.scm
 @@ -1741,7 +1741,7 @@ IcedTea build harness.")

  ;; The 1.9.x series is the last that can be built with GCJ.  The 1.10.x 
 series
  ;; requires Java 8.
 -(define-public ant
 +(define-public 

Re: java: switch to icedtea-8 as default JDK

[Gábor Boskovits]

Ok, it seems, that java-asm does not currently uses test anyway, so I can
remove the junit native input.
Will check if it is also true on master...

2017-12-15 14:52 GMT+01:00 Gábor Boskovits :

> I've found the problem with java-hamcrest-core.
> The root cause of this is that java-jarjar uses a bundled copy of asm,
> version 4.0.
> This asm version does not support icedtea8.
>
> I propose to use java-asm instead of the bundled one.
>
> In my opinion the best course of action should be:
> 1. create a package: java-asm-notest with tests diabled to break the
> dependency cycle on java-hamcrest-core
> 2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
> 3. test if java-hamcrest-core now builds.
>
> It is a question if we want to iterate this cycle once more, with a
> tests-enabled java-asm.
> WDYT?
>
>
> 2017-12-13 23:50 GMT+01:00 Gábor Boskovits :
>
>> I've built the whole covering on my wip-change-default-java8 branch.
>> The covering is 42 packages.
>> 19 builds fine.
>> 19 does not build because java-hamcrest-core does not build.
>> I'll have a look at this first, this is the most critical.
>> This is the issue link for reference:
>> https://github.com/Boskovits/guix/issues/16
>>
>> 2017-12-13 19:04 GMT+01:00 Gábor Boskovits :
>>
>>> The patches I made:
>>>
>>> This is the trivial:
>>>
>>> From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
>>> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
>>> Date: Mon, 11 Dec 2017 21:18:37 +0100
>>> Subject: [PATCH] Change java toolchain defaults to use java8.
>>>
>>> * gnu/packages/java.scm(icedtea): Point to icedtea-8.
>>> * gnu/packages/java.scm(ant): Point to ant/java8.
>>> ---
>>>  gnu/packages/java.scm | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>>> index 6dfe554f3..547cc2dc1 100644
>>> --- a/gnu/packages/java.scm
>>> +++ b/gnu/packages/java.scm
>>> @@ -1691,7 +1691,7 @@ IcedTea build harness.")
>>>   '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" 
>>> "jaxws-drop"
>>> "jdk-drop" "langtools-drop" "hotspot-drop")))
>>>
>>> -(define-public icedtea icedtea-7)
>>> +(define-public icedtea icedtea-8)
>>>
>>>  
>>>  (define-public ant/java8
>>> @@ -1754,7 +1754,7 @@ IcedTea build harness.")
>>>  (native-inputs
>>>   `(("jdk" ,icedtea-7 "jdk")
>>>
>>> -(define-public ant ant/java7)
>>> +(define-public ant ant/java8)
>>>
>>>  (define-public ant-apache-bcel
>>>(package
>>>
>>>
>>> This is what I'd like to have your opinions on, is it ok to do it this way, 
>>> or should I rethink it
>>>
>>> (I like this, because this way we can leave ant-build-system alone, and 
>>> handling of
>>>
>>> default version in java.scm became consistent):
>>>
>>> From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
>>> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
>>> Date: Mon, 11 Dec 2017 21:13:58 +0100
>>> Subject: [PATCH] gnu:add ant/java7.
>>>
>>> * gnu/packages/java.scm(ant/java7): New variable.
>>> * gnu/packages/java.scm(ant): Changed variable semantics to point to 
>>> default ant.
>>> ---
>>>  gnu/packages/java.scm | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>>> index 0be488dec..6dfe554f3 100644
>>> --- a/gnu/packages/java.scm
>>> +++ b/gnu/packages/java.scm
>>> @@ -1741,7 +1741,7 @@ IcedTea build harness.")
>>>
>>>  ;; The 1.9.x series is the last that can be built with GCJ.  The 1.10.x 
>>> series
>>>  ;; requires Java 8.
>>> -(define-public ant
>>> +(define-public ant/java7
>>>(package (inherit ant/java8)
>>>  (version "1.9.9")
>>>  (source (origin
>>> @@ -1754,6 +1754,8 @@ IcedTea build harness.")
>>>  (native-inputs
>>>   `(("jdk" ,icedtea-7 "jdk")
>>>
>>> +(define-public ant ant/java7)
>>> +
>>>  (define-public ant-apache-bcel
>>>(package
>>>  (inherit ant/java8)
>>>
>>>
>>> 2017-12-13 12:07 GMT+01:00 Gábor Boskovits :
>>>
 Hello!

 It was getting quite intractable to see what I was doing, so I started
 to fill my github issue tracker. Issues are labeled with
 change-default-java8.


 2017-12-13 11:32 GMT+01:00 Efraim Flashner :

> On Tue, Dec 12, 2017 at 06:06:52PM -0800, Chris Marusich wrote:
> > Gábor Boskovits  writes:
> >
> > > I will wait for your results for now...
> >
> 
> >
> > * kodi@18.0_alpha-7-67fd70f: failed because of "potential infinite
> >   recursion"; also it seems that it's looking for a DTD on the
> Internet
> >   when instead it should be looking to find it in the inputs.
> >
> > --8<---cut here---start->8---
> > [3684/3799] Linking 

Re: java: switch to icedtea-8 as default JDK

[Gábor Boskovits]

I've found the problem with java-hamcrest-core.
The root cause of this is that java-jarjar uses a bundled copy of asm,
version 4.0.
This asm version does not support icedtea8.

I propose to use java-asm instead of the bundled one.

In my opinion the best course of action should be:
1. create a package: java-asm-notest with tests diabled to break the
dependency cycle on java-hamcrest-core
2. modify java-jarjar to use java-asm-notest instead of the bundled asm.
3. test if java-hamcrest-core now builds.

It is a question if we want to iterate this cycle once more, with a
tests-enabled java-asm.
WDYT?


2017-12-13 23:50 GMT+01:00 Gábor Boskovits :

> I've built the whole covering on my wip-change-default-java8 branch.
> The covering is 42 packages.
> 19 builds fine.
> 19 does not build because java-hamcrest-core does not build.
> I'll have a look at this first, this is the most critical.
> This is the issue link for reference:
> https://github.com/Boskovits/guix/issues/16
>
> 2017-12-13 19:04 GMT+01:00 Gábor Boskovits :
>
>> The patches I made:
>>
>> This is the trivial:
>>
>> From f53ad84059786e0769a21a3a90a15189bcf2d61f Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
>> Date: Mon, 11 Dec 2017 21:18:37 +0100
>> Subject: [PATCH] Change java toolchain defaults to use java8.
>>
>> * gnu/packages/java.scm(icedtea): Point to icedtea-8.
>> * gnu/packages/java.scm(ant): Point to ant/java8.
>> ---
>>  gnu/packages/java.scm | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>> index 6dfe554f3..547cc2dc1 100644
>> --- a/gnu/packages/java.scm
>> +++ b/gnu/packages/java.scm
>> @@ -1691,7 +1691,7 @@ IcedTea build harness.")
>>   '("jdk" "openjdk-src" "corba-drop" "jaxp-drop" "jaxws-drop"
>> "jdk-drop" "langtools-drop" "hotspot-drop")))
>>
>> -(define-public icedtea icedtea-7)
>> +(define-public icedtea icedtea-8)
>>
>>  
>>  (define-public ant/java8
>> @@ -1754,7 +1754,7 @@ IcedTea build harness.")
>>  (native-inputs
>>   `(("jdk" ,icedtea-7 "jdk")
>>
>> -(define-public ant ant/java7)
>> +(define-public ant ant/java8)
>>
>>  (define-public ant-apache-bcel
>>(package
>>
>>
>> This is what I'd like to have your opinions on, is it ok to do it this way, 
>> or should I rethink it
>>
>> (I like this, because this way we can leave ant-build-system alone, and 
>> handling of
>>
>> default version in java.scm became consistent):
>>
>> From 1629a53ac5122d229b157a33806264772f18f6bc Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?G=C3=A1bor=20Boskovits?= 
>> Date: Mon, 11 Dec 2017 21:13:58 +0100
>> Subject: [PATCH] gnu:add ant/java7.
>>
>> * gnu/packages/java.scm(ant/java7): New variable.
>> * gnu/packages/java.scm(ant): Changed variable semantics to point to default 
>> ant.
>> ---
>>  gnu/packages/java.scm | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
>> index 0be488dec..6dfe554f3 100644
>> --- a/gnu/packages/java.scm
>> +++ b/gnu/packages/java.scm
>> @@ -1741,7 +1741,7 @@ IcedTea build harness.")
>>
>>  ;; The 1.9.x series is the last that can be built with GCJ.  The 1.10.x 
>> series
>>  ;; requires Java 8.
>> -(define-public ant
>> +(define-public ant/java7
>>(package (inherit ant/java8)
>>  (version "1.9.9")
>>  (source (origin
>> @@ -1754,6 +1754,8 @@ IcedTea build harness.")
>>  (native-inputs
>>   `(("jdk" ,icedtea-7 "jdk")
>>
>> +(define-public ant ant/java7)
>> +
>>  (define-public ant-apache-bcel
>>(package
>>  (inherit ant/java8)
>>
>>
>> 2017-12-13 12:07 GMT+01:00 Gábor Boskovits :
>>
>>> Hello!
>>>
>>> It was getting quite intractable to see what I was doing, so I started
>>> to fill my github issue tracker. Issues are labeled with
>>> change-default-java8.
>>>
>>>
>>> 2017-12-13 11:32 GMT+01:00 Efraim Flashner :
>>>
 On Tue, Dec 12, 2017 at 06:06:52PM -0800, Chris Marusich wrote:
 > Gábor Boskovits  writes:
 >
 > > I will wait for your results for now...
 >
 
 >
 > * kodi@18.0_alpha-7-67fd70f: failed because of "potential infinite
 >   recursion"; also it seems that it's looking for a DTD on the
 Internet
 >   when instead it should be looking to find it in the inputs.
 >
 > --8<---cut here---start->8---
 > [3684/3799] Linking default/source3/modules/libvfs_module_worm.so
 > [3685/3799] Linking default/source3/modules/libvfs
 _module_crossrename.so
 > [3686/3799] Linking default/source3/modules/libvfs_module_cap.so
 > [3687/3799] Linking default/source3/modules/libvfs_module_catia.so
 > [3688/3799] pidl.1: pidl/pidl -> bin/default/pidl/pidl.1
 > [3689/3799] Parse::Pidl::Dump.3: 

Re: [PATCH] gnu: python2-pyicu: Disable failing test.

[Mark Meyer]

However, for some reason python2-vobject fails to pick up this change
and fails to build :(

On Fri, Dec 15, 2017, at 12:17, Tobias Geerinckx-Rice wrote:
> Mark,
> 
> Mark Meyer wrote on 15/12/17 at 11:58:
> > thanks for the patch, this works for me :)
> Wonderful! Pushed as d65854bdda4ad5464fcd8fe6289eedc13ea82ba1.
> 
> (Just FYI: if you post to bug-g...@gnu.org next time, you'll get the
>  visceral satisfaction of closing yet another bug. ;-)
> 
> Kind regards,
> 
> T G-R


-- 
  Mark Meyer
  m...@ofosos.org

Re: [PATCH] gnu: python2-pyicu: Disable failing test.

[Tobias Geerinckx-Rice]

Mark,

Mark Meyer wrote on 15/12/17 at 11:58:
> thanks for the patch, this works for me :)
Wonderful! Pushed as d65854bdda4ad5464fcd8fe6289eedc13ea82ba1.

(Just FYI: if you post to bug-g...@gnu.org next time, you'll get the
 visceral satisfaction of closing yet another bug. ;-)

Kind regards,

T G-R

Re: [PATCH] gnu: python2-pyicu: Disable failing test.

[Mark Meyer]

Tobias,
thanks for the patch, this works for me :)

Cheers, Mark

On Fri, Dec 15, 2017, at 11:47, Tobias Geerinckx-Rice wrote:
> * gnu/packages/python.scm (python2-pyicu)[arguments]: Add
> ‘delete-failing-test’ phase.
> ---
> 
> Mark,
> 
> ...of course it finishes right after I send that previous e-mail.
> 
> This patch makes the build pass for me. Could you confirm whether it
> works for you?
> 
> Kind regards,
> 
> T G-R
> 
>  gnu/packages/python.scm | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index e36056d45..372b5afe3 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -1130,7 +1130,20 @@ Python 3.3+.")
>  (license license:x11)))
>  
>  (define-public python2-pyicu
> -  (package-with-python2 python-pyicu))
> +  (let ((base (package-with-python2
> +(strip-python2-variant python-pyicu
> +(package
> +  (inherit base)
> +  (arguments
> +   `(,@(package-arguments base)
> + #:phases
> + (modify-phases %standard-phases
> +   (add-before 'check 'delete-failing-test
> + (lambda _
> +   ;; XXX: This fails due to Unicode issues unique to Python
> 2,
> +   ;; it seems:
> .
> +   (delete-file "test/test_Script.py")
> +   #t
>  
>  (define-public python2-dogtail
>;; Python 2 only, as it leads to "TabError: inconsistent use of tabs
>and
> -- 
> 2.15.0
> 


-- 
  Mark Meyer
  m...@ofosos.org

[PATCH] gnu: python2-pyicu: Disable failing test.

[Tobias Geerinckx-Rice]

* gnu/packages/python.scm (python2-pyicu)[arguments]: Add
‘delete-failing-test’ phase.
---

Mark,

...of course it finishes right after I send that previous e-mail.

This patch makes the build pass for me. Could you confirm whether it
works for you?

Kind regards,

T G-R

 gnu/packages/python.scm | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index e36056d45..372b5afe3 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1130,7 +1130,20 @@ Python 3.3+.")
 (license license:x11)))
 
 (define-public python2-pyicu
-  (package-with-python2 python-pyicu))
+  (let ((base (package-with-python2
+(strip-python2-variant python-pyicu
+(package
+  (inherit base)
+  (arguments
+   `(,@(package-arguments base)
+ #:phases
+ (modify-phases %standard-phases
+   (add-before 'check 'delete-failing-test
+ (lambda _
+   ;; XXX: This fails due to Unicode issues unique to Python 2,
+   ;; it seems: .
+   (delete-file "test/test_Script.py")
+   #t
 
 (define-public python2-dogtail
   ;; Python 2 only, as it leads to "TabError: inconsistent use of tabs and
-- 
2.15.0

Re: Build failure in pyicu

[Tobias Geerinckx-Rice]

Mark Meyer wrote on 15/12/17 at 10:26:
> Hi,
> I've got a build failure in PyICU (python2-pyicu) during the test phase:
> 
> ==
> FAIL: testSurrogatePairs (test.test_Script.TestScript)
> --

Hrm, this looks like another encoding- or locale-related failure[0] —
although I guess with packages like these, all failures look that way.

I suggest simply deleting the test, like we previously did with
test_DateTimeParserGenerator.py. I'm testing that now, but slowly...

Kind regards,

T G-R

[0]: https://github.com/ovalhub/pyicu/issues/61

Build failure in pyicu

[Mark Meyer]

Hi,
I've got a build failure in PyICU (python2-pyicu) during the test phase:

==
FAIL: testSurrogatePairs (test.test_Script.TestScript)
--
Traceback (most recent call last):
  File
  "/tmp/guix-build-python2-pyicu-1.9.8.drv-0/PyICU-1.9.8/test/test_Script.py",
  line 48, in testSurrogatePairs
self.assertEqual(['Latn', 'Deva', 'Hani', 'Zzzz', 'Zzzz'], names)
AssertionError: Lists differ: ['Latn', 'Deva', 'Hani', 'Zzzz... !=
['Latn', 'Deva', 'Hani', 'Zyyy...

First differing element 3:
'Zzzz'
'Zyyy'

- ['Latn', 'Deva', 'Hani', 'Zzzz', 'Zzzz']
?^^^ ^^^

+ ['Latn', 'Deva', 'Hani', 'Zyyy', 'Zyyy']
?^^^ ^^^


--
Ran 39 tests in 0.458s

FAILED (failures=1)
phase `check' failed after 0.9 seconds
builder for
`/gnu/store/s62yr0llv2f2yf7m36p4dq7r45ciy46b-python2-pyicu-1.9.8.drv'
failed with exit code 1
@ build-failed
/gnu/store/s62yr0llv2f2yf7m36p4dq7r45ciy46b-python2-pyicu-1.9.8.drv - 1
builder for
`/gnu/store/s62yr0llv2f2yf7m36p4dq7r45ciy46b-python2-pyicu-1.9.8.drv'
failed with exit code 1
cannot build derivation
`/gnu/store/1s0wa8lq3xgmjaf3zv9d3limwyh5538w-virtaal-0.4.1.drv': 1
dependencies couldn't be built
guix build: error: build failed: build of
`/gnu/store/1s0wa8lq3xgmjaf3zv9d3limwyh5538w-virtaal-0.4.1.drv' failed

Cheers, Mark
-- 
  Mark Meyer
  m...@ofosos.org