Re: [PATCH] gnu: Add ruby 1.8.7 package

[Mark H Weaver]

Pjotr Prins  writes:
> * gnu/packages/ruby.scm: (ruby-1.8): New variable.

I pushed this with some minor changes to the commit log, and with the
unneeded (guix hash) import removed.  I also followed it up with another
commit making some improvements to the original ruby package.

Thanks!
  Mark

Re: [PATCH 5/5] emacs: Add 'guix-pull' command.

[Alex Kost]

Ludovic Courtès (2014-10-26 21:41 +0300) wrote:

> Alex Kost  skribis:
>
>> From c117fe99830323409c0563204d45ceb0f53e1e75 Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Tue, 21 Oct 2014 11:48:28 +0400
>> Subject: [PATCH 5/5] emacs: Add 'guix-pull' command.
>>
>> * emacs/guix-base.el (guix-pull): New command.
>>   (guix-update-after-pull, guix-after-pull-hook): New variables.
>>   (guix-restart-repl-after-pull, guix-update-buffers-maybe-after-pull): New
>>   procedures.
>> * emacs/guix-main.scm: Use (guix scripts pull) module.
>> * doc/emacs.texi (Emacs Commands): Document 'guix-pull' command.
>
> Nice, looks good!
>
>> +Also you can invoke @command{guix pull} command (@pxref{Invoking guix
>
> “You can also invoke the...”
>
>> +After @command{guix pull} will be successfully performed, the Guix REPL
>> +will be restared, so you can continue using Emacs interface with an
>> +updated Guix.
>
> What about this?
>
>   Once @command{guix pull} has succeeded, the Guix REPL is restarted.
>   This allows you to keep using the Emacs interface with the updated
>   Guix.

Absolutely!  I'll fix it, thanks!

Re: [PATCH 2/5] emacs: Introduce REPL operation type.

[Alex Kost]

Ludovic Courtès (2014-10-26 21:37 +0300) wrote:

> Alex Kost  skribis:
>
>> This is an auxiliary commit for a “pull” operation added in a later patch.
>>
>>
>> From ef0414fbe738d18d33b23a67dc47c8e75dbb Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Mon, 20 Oct 2014 23:18:13 +0400
>> Subject: [PATCH 2/5] emacs: Introduce REPL operation type.
>>
>> * emacs/guix-backend.el (guix-repl-operation-type): New variable.
>>   (guix-repl-output-filter): Run type hooks after performing an operation.
>>   (guix-eval-read): Add 'operation-type' argument.
>
> [...]
>
>> +(defvar guix-repl-operation-type nil
>> +  "Type of the current operation performed by `guix-eval-in-repl'.")
>
> Could you write something about the valid values it may take and their
> meaning?
>
> Otherwise LGTM.

It's an internal variable set by ‘guix-eval-in-repl’.

The point of an “operation type” is to run some specialized actions
after finishing a REPL operation (e.g., to refresh buffers after ‘pull’
operation).

If there is ‘guix-after-foo-hook’ variable and ‘guix-eval-in-repl’ is
called with ‘foo’ operation-type, the hooks from that var will be called
after executing ‘foo’ operation.

Currently only ‘pull’ operation type is used, so ‘guix-after-pull-hook’
is called after a pull operation.

‘strip’ phase

[Ludovic Courtès]

Mark H Weaver  skribis:

>> I DO get a load of messages such as
>>
>>   
>> strip:/gnu/store/icz59y35qqmm4jcrnkqx7d73xlzsq0lq-ruby-1.8.7-p374/lib/ruby/1.8/rexml/attlistdecl.rb:
>>   File format not recognized
>>
>> is there a way to prevent files with a .rb extension or ruby shebang
>> to be stripped?
>
> In theory the default 'strip' phase could be replaced by one that's more
> selective, but please don't do that.
>
> The problem happens in almost every package, so the improvements should
> be made in the default 'strip' phase.  The relevant procedure is 'strip'
> in guix/build/gnu-build-system.scm, but beware that changing that file
> (or just about anything else in that directory) will trigger a full
> rebuild of all packages.  It would be nice to do at some point, but it's
> quite far down on our TODO list.

I think the ‘strip’ phase is fine this way: sure, it ends up invoking
‘strip’ on files that are not ELF files, but it’s harmless.  So we get
these extra warnings in the build log, but they are really harmless.

Conversely, attempts to be more selective may miss actual ELF files.

WDYT?

Ludo’.

Re: Problems with downloading from https

[Mark H Weaver]

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

> Alex Kost  skribis:
>
>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>
>>> Alex Kost  skribis:
>>>
 Yes, I installed gnutls, but it didn't work because I didn't set the
 right guile paths: “guix package --search-paths” recommends
 "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site/2.0"
 but "gnutls.scm" is actually placed in
 "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site"
 so ‘(use-modules (gnutls))’ failed for me.
>>>
>>> Oh, that’s a bug of the GnuTLS package: we should pass the right
>>> configure flag so that modules go to site/2.0.  Could you do that?

Alex committed this change, and it broke all https downloads in Guix,
leading to hydra build failures.  For example, see:

  http://hydra.gnu.org/build/132928/nixlog/1/raw

The reason is that guix/download.scm contains this code:

--8<---cut here---start->8---
  ;; Add GnuTLS to the inputs and to the load path.
  #~(eval-when (load expand eval)
  (set! %load-path
(cons (string-append #$(gnutls-package)
 "/share/guile/site")
  %load-path)))
  #~#t)
--8<---cut here---end--->8---

For now, I think we should revert this commit and discuss it further
before proceeding.

>> Yes, but I'm a little concerned.  Should it really be so?  What about
>> guile-1.8; isn't it supposed to use gnutls module as well?
>
> 1.8 has long been deprecated, so let’s not worry about it.

I think Alex was right to be concerned.  We'll have the same problem
when Guile 2.2 comes around, and then again for 2.4.  I'm reluctant to
hardcode "2.0" into the code above.  Think about what it implies for
GnuTLS in the future.  Will they be expected to install their modules
into site/2.0, site/2.2, site/2.4, etc?  Do we really want to advocate
this practice to projects that install Guile modules?

   Mark

Re: Imlib2 license

[Mark H Weaver]

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

> Alex Kost  skribis:
>
>> OK for the attached patch?
>>
>>
>> From b7564a7f68fe2d2d74d0d1bc768eb19dbab09a36 Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Sun, 26 Oct 2014 15:27:56 +0300
>> Subject: [PATCH] licenses: Add 'imlib2'.
>>
>> * guix/licenses.scm (imlib2): New variable.
>> * gnu/packages/image.scm (imlib2): Use it.
>
> OK!

FYI, this patch broke the package 'feh' and caused fatal evaluation
errors on hydra, because gnu/packages/feh.scm used the package 'imlib2'
from (gnu packages image) and also imported (guix licenses) without a
prefix.  'imlib2', used as an input to 'feh', ended up being a license
object.  I fixed it in commit 4e2f98c5394c515a5849be3aad6d06e8ad89807b.

  Mark

Re: guile ERROR: Unbound variable: sha256

[Ludovic Courtès]

Hi Pjotr,

Pjotr Prins  skribis:

> I suspect this was introduced with bags.  When I use below Guile instruction 
> running
> from the CLI I get
>
> $2 = #
> scheme@(guile-user)> (package-derivation s python)
> ERROR: In procedure memoize-variable-access!:
> ERROR: Unbound variable: sha256

[...]

> In guix/utils.scm:
>426:27  3 (derivation-hash #  2af8dc0>)
> In ice-9/eval.scm:
> 386:9  2 (eval #utf8 (derivation->string 
> <0>)))> (# . #))
>393:14  1 (eval # (#  2af8d70> () 
> (("out" . "")) (("out" . "")) . #))
> In unknown file:
>0 (memoize-variable-access! # # derivations) 27dc480>)

I can’t reproduce it.  Could it be that guix/derivations.scm was
modified in your local tree, such that it misses the
#:use-module (guix hash) line?  Is there a warning when compiling
guix/derivations.go?

Thanks,
Ludo’.

Re: Ruby gems in user land ($HOME)

[Ludovic Courtès]

Pjotr Prins  skribis:

> In the document I describe how you can install cleanly separated Ruby
> gems in $HOME using the Ruby gem command that comes with GNU Guix:
>
>   https://github.com/pjotrp/guix-notes/blob/master/RUBY#L152

Nice.

> export 
> GEM_PATH=/home/wrk/.gem/ziy7a6zib846426kprc7fgimggh8bz97-ruby-2.1.3/2.1.0 
>
> export GEM_HOME=$GEM_PATH 
>   
> export 
> GEM_SPEC_CACHE=/home/wrk/.gem/ziy7a6zib846426kprc7fgimggh8bz97-ruby-2.1.3/specs
>   

I suspect this won’t be very convenient.  ;-)  I’m not sure what can be
done to help.

> System-level gem support will come later which will support gems
> that live in the store (each gem under its own store path). That will
> be incredible useful for deployment.

Yes, I think this would be best.  And in particular, it would nicely
solve the usability problem above.

Thanks!

Ludo’.

Re: [PATCH 2/5] emacs: Introduce REPL operation type.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-26 21:37 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> This is an auxiliary commit for a “pull” operation added in a later patch.
>>>
>>>
>>> From ef0414fbe738d18d33b23a67dc47c8e75dbb Mon Sep 17 00:00:00 2001
>>> From: Alex Kost 
>>> Date: Mon, 20 Oct 2014 23:18:13 +0400
>>> Subject: [PATCH 2/5] emacs: Introduce REPL operation type.
>>>
>>> * emacs/guix-backend.el (guix-repl-operation-type): New variable.
>>>   (guix-repl-output-filter): Run type hooks after performing an operation.
>>>   (guix-eval-read): Add 'operation-type' argument.
>>
>> [...]
>>
>>> +(defvar guix-repl-operation-type nil
>>> +  "Type of the current operation performed by `guix-eval-in-repl'.")
>>
>> Could you write something about the valid values it may take and their
>> meaning?

Sorry, I meant as comment in the docstring above.  :-)

>> Otherwise LGTM.
>
> It's an internal variable set by ‘guix-eval-in-repl’.
>
> The point of an “operation type” is to run some specialized actions
> after finishing a REPL operation (e.g., to refresh buffers after ‘pull’
> operation).
>
> If there is ‘guix-after-foo-hook’ variable and ‘guix-eval-in-repl’ is
> called with ‘foo’ operation-type, the hooks from that var will be called
> after executing ‘foo’ operation.
>
> Currently only ‘pull’ operation type is used, so ‘guix-after-pull-hook’
> is called after a pull operation.

OK, thanks.  Feel free to commit with the explanation folded into the
docstring.

Ludo’.

Re: ‘strip’ phase

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>>> I DO get a load of messages such as
>>>
>>>   
>>> strip:/gnu/store/icz59y35qqmm4jcrnkqx7d73xlzsq0lq-ruby-1.8.7-p374/lib/ruby/1.8/rexml/attlistdecl.rb:
>>>   File format not recognized
>>>
>>> is there a way to prevent files with a .rb extension or ruby shebang
>>> to be stripped?
>>
>> In theory the default 'strip' phase could be replaced by one that's more
>> selective, but please don't do that.
>>
>> The problem happens in almost every package, so the improvements should
>> be made in the default 'strip' phase.  The relevant procedure is 'strip'
>> in guix/build/gnu-build-system.scm, but beware that changing that file
>> (or just about anything else in that directory) will trigger a full
>> rebuild of all packages.  It would be nice to do at some point, but it's
>> quite far down on our TODO list.
>
> I think the ‘strip’ phase is fine this way: sure, it ends up invoking
> ‘strip’ on files that are not ELF files, but it’s harmless.  So we get
> these extra warnings in the build log, but they are really harmless.

Large numbers of spurious warnings are not harmless, because they make
it unlikely that anyone will notice the warnings worth our attention.
They condition us to ignore all warnings, because it's too much work to
look through them all.

> Conversely, attempts to be more selective may miss actual ELF files.

True, but this is more harmless than the spurious warnings, IMO.  It
merely means that we failed to save some disk space.

IMO, the best solution is to check for the presence of ELF headers
ourselves.  We already have ELF code in Guile master.

What do you think?

  Mark

Re: [PATCH 0/1] Re: Problems with downloading from https

[Ian Denhardt]

Ping. Haven't heard anything about this.

Quoting Ian Denhardt (2014-10-26 01:30:05)
> Quoting Ludovic Courtès (Sat, 25 Oct 2014 23:53:25 +0200)
> > The problem is that the GnuTLS Guile bindings must be installed for
> > ‘guix download’ to work with HTTPS (the manual suggests it, but perhaps
> > not clearly enough?)
> 
> The README is probably a better place. Here's a patch.
> 
> > So just install GnuTLS, make sure ‘guile -c '(use-modules (gnutls))'’
> > succeeds, and then it’ll work.
> 
> Progress, though now I'm getting cert errors (curl is happy). *sigh*
> 
> 
> Ian Denhardt (1):
>   README: add a note about optional GnuTLS dependency.
> 
>  README | 2 ++
>  1 file changed, 2 insertions(+)
> 
> -- 
> 2.1.2


signature.asc
Description: signature

Re: ‘strip’ phase

[Ludovic Courtès]

Mark H Weaver  skribis:

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

[...]

>> I think the ‘strip’ phase is fine this way: sure, it ends up invoking
>> ‘strip’ on files that are not ELF files, but it’s harmless.  So we get
>> these extra warnings in the build log, but they are really harmless.
>
> Large numbers of spurious warnings are not harmless, because they make
> it unlikely that anyone will notice the warnings worth our attention.
> They condition us to ignore all warnings, because it's too much work to
> look through them all.

Right.

>> Conversely, attempts to be more selective may miss actual ELF files.
>
> True, but this is more harmless than the spurious warnings, IMO.  It
> merely means that we failed to save some disk space.
>
> IMO, the best solution is to check for the presence of ELF headers
> ourselves.  We already have ELF code in Guile master.

Yes, that sounds good.  Instead of relying on Guile’s ELF code, perhaps
it would be enough to check for the presence of the ELF magic bytes?

Ludo’.

Re: Problems with downloading from https

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Alex Kost  skribis:
>>
>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>
 Alex Kost  skribis:

> Yes, I installed gnutls, but it didn't work because I didn't set the
> right guile paths: “guix package --search-paths” recommends
> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site/2.0"
> but "gnutls.scm" is actually placed in
> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site"
> so ‘(use-modules (gnutls))’ failed for me.

 Oh, that’s a bug of the GnuTLS package: we should pass the right
 configure flag so that modules go to site/2.0.  Could you do that?
>
> Alex committed this change, and it broke all https downloads in Guix,
> leading to hydra build failures.  For example, see:
>
>   http://hydra.gnu.org/build/132928/nixlog/1/raw
>
> The reason is that guix/download.scm contains this code:
>
>   ;; Add GnuTLS to the inputs and to the load path.
>   #~(eval-when (load expand eval)
>   (set! %load-path
> (cons (string-append #$(gnutls-package)
>  "/share/guile/site")
>   %load-path)))
>   #~#t)

Oops, my bad.  I think this code should be changed to use site/2.0,
which is the standard search path specification.

> For now, I think we should revert this commit and discuss it further
> before proceeding.

I would just fix the above code to append (effective-version).  WDYT?

>>> Yes, but I'm a little concerned.  Should it really be so?  What about
>>> guile-1.8; isn't it supposed to use gnutls module as well?
>>
>> 1.8 has long been deprecated, so let’s not worry about it.
>
> I think Alex was right to be concerned.  We'll have the same problem
> when Guile 2.2 comes around, and then again for 2.4.  I'm reluctant to
> hardcode "2.0" into the code above.  Think about what it implies for
> GnuTLS in the future.  Will they be expected to install their modules
> into site/2.0, site/2.2, site/2.4, etc?  Do we really want to advocate
> this practice to projects that install Guile modules?

No, you’re right, of course.  However, I tend to distinguish between the
immediate issue that calls for a fix, and the design issue that has to
be addressed, but is less pressing.

Currently, there are a couple of packages that hard-code site/2.0.  They
should be changed to use:

  (string-append "--with-site-dir=.../site/" (effective-version))

That doesn’t help with 1.8, though, because 1.8 uses /site.  Perhaps a
fix would be to change 1.8 in Guix so that it uses a versioned site
directory like future versions do?  Another option would be to ignore 1.8.

WDYT?

There may be similar problems with Python, Ruby, etc., although these
haven’t come up yet, I think.  These can hopefully be addressed by
having their respective build system pass #:effective-version to the
build code.  Thoughts?

Thanks,
Ludo’.

Re: Imlib2 license

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Alex Kost  skribis:
>>
>>> OK for the attached patch?
>>>
>>>
>>> From b7564a7f68fe2d2d74d0d1bc768eb19dbab09a36 Mon Sep 17 00:00:00 2001
>>> From: Alex Kost 
>>> Date: Sun, 26 Oct 2014 15:27:56 +0300
>>> Subject: [PATCH] licenses: Add 'imlib2'.
>>>
>>> * guix/licenses.scm (imlib2): New variable.
>>> * gnu/packages/image.scm (imlib2): Use it.
>>
>> OK!
>
> FYI, this patch broke the package 'feh' and caused fatal evaluation
> errors on hydra, because gnu/packages/feh.scm used the package 'imlib2'
> from (gnu packages image) and also imported (guix licenses) without a
> prefix.  'imlib2', used as an input to 'feh', ended up being a license
> object.  I fixed it in commit 4e2f98c5394c515a5849be3aad6d06e8ad89807b.

Sorry for overlooking that, thank you!

Ludo’.

Re: Problems with downloading from https

[Ludovic Courtès]

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

> Currently, there are a couple of packages that hard-code site/2.0.  They
> should be changed to use:
>
>   (string-append "--with-site-dir=.../site/" (effective-version))

Actually this won’t work because the Guile that runs the build script is
not necessarily the same as the one used to build the thing.

So we probably need a helper function in (guix build utils) that runs
“guile -c '(display (effective-version))'” and returns that.

How does that sound?

Ludo’.

Re: [PATCH 1/1] README: add a note about optional GnuTLS dependency.

[Ludovic Courtès]

Ian Denhardt  skribis:

> * README: add a note about 'guix download''s GnuTLS dependency. This is
>   documented in the manual, but should be more prominently featured.

Thanks.  Pushed with a similar change in guix.texi.

Ludo’.

Re: Suggestion: disable offloading for texlive builds on hydra?

[Ludovic Courtès]

Mark H Weaver  skribis:

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

[...]

>> The rationale was that, in general, you just slow everything down by
>> sending several things at once.
>
> I have my doubts that it would slow things down very much, if at all.
> The number of parallel transfers would still be limited to a small
> number, typically 4 per build slave.  The expense associated with
> running multiple processes on a CPU is mainly due to cache effects, but
> I wouldn't expect that to be an issue with network connections,
> especially when those connections are between the same two hosts.  The
> practice of using multiple connections is well established in web
> browsers and imap clients, as long as the number is not too large.
>
> We're losing a huge amount of available CPU capacity in our build farm
> (probably over 30 machine-hours per texinfo rebuild) in exchange for a
> dubious increase in network efficiency.
>
> The more I think about it, the more I agree with John that we've chosen
> the wrong tradeoff here.  I think we should remove those mutexes.

Hmm OK.  I’m happy to try that (it’s a two-line change plus deployment.)

I can do it one of the next few days, but I’m happy if you do it.  :-)

>> diff --git a/gnu/packages/texlive.scm b/gnu/packages/texlive.scm
>> index e562b02..bc0ece7 100644
>> --- a/gnu/packages/texlive.scm
>> +++ b/gnu/packages/texlive.scm
>> @@ -88,7 +88,7 @@
>>("pkg-config" ,pkg-config)
>>("python" ,python-2) ; incompatible with Python 3 (print syntax)
>>("tcsh" ,tcsh)))
>> -   (outputs '("out" "data"))
>> +   (outputs '("out" "data" "doc"))
>> (arguments
>>  `(#:out-of-source? #t
>>#:configure-flags
>>
>>
>> Data point: there’s 1.6 GiB in texmf-dist/doc (which the patch above
>> splits out), and 1.4 GiB in texmf-dist/fonts.
>
> I'd definitely be in favor of splitting out the docs.

OK, I’ll test it locally and commit if nothing breaks.

>> Another option Andreas and I discussed a while back would be to use a
>> fixed-output derivation for the data, since it’s really what it is.
>> That’s a bit hacky though: we’d have to install it, compute the hash of
>> the installed files, and then use that as the derivation’s output hash.
>
> Hmm.  It is indeed a hack, but maybe worth considering.  When I think
> about Guix users downloading over 3 GiB from our humble hydra quite
> often just to have TeX, it makes me worry about our bandwidth
> requirements.

Agreed.

Ludo’.

Re: Problems with downloading from https

[Alex Kost]

Mark H Weaver (2014-10-27 12:06 +0300) wrote:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Alex Kost  skribis:
>>
>>> Ludovic Courtès (2014-10-26 16:46 +0300) wrote:
>>>
 Alex Kost  skribis:

> Yes, I installed gnutls, but it didn't work because I didn't set the
> right guile paths: “guix package --search-paths” recommends
> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site/2.0"
> but "gnutls.scm" is actually placed in
> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site"
> so ‘(use-modules (gnutls))’ failed for me.

 Oh, that’s a bug of the GnuTLS package: we should pass the right
 configure flag so that modules go to site/2.0.  Could you do that?
>
> Alex committed this change, and it broke all https downloads in Guix,
> leading to hydra build failures.  For example, see:
>
>   http://hydra.gnu.org/build/132928/nixlog/1/raw

[...]

OMG!  I'm sorry about that.  And thanks for fixing imlib2 license issue.

I'm feeling guilty and I think I shouldn't touch anything outside
"emacs" directory.  Sorry again.

-- 
Alex

Re: Problems with downloading from https

[Alex Kost]

Ludovic Courtès (2014-10-27 15:24 +0300) wrote:

> Mark H Weaver  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Alex Kost  skribis:
>>>
 Ludovic Courtès (2014-10-26 16:46 +0300) wrote:

> Alex Kost  skribis:
>
>> Yes, I installed gnutls, but it didn't work because I didn't set the
>> right guile paths: “guix package --search-paths” recommends
>> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site/2.0"
>> but "gnutls.scm" is actually placed in
>> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site"
>> so ‘(use-modules (gnutls))’ failed for me.
>
> Oh, that’s a bug of the GnuTLS package: we should pass the right
> configure flag so that modules go to site/2.0.  Could you do that?
>>
>> Alex committed this change, and it broke all https downloads in Guix,
>> leading to hydra build failures.  For example, see:
>>
>>   http://hydra.gnu.org/build/132928/nixlog/1/raw
>>
>> The reason is that guix/download.scm contains this code:
>>
>>   ;; Add GnuTLS to the inputs and to the load path.
>>   #~(eval-when (load expand eval)
>>   (set! %load-path
>> (cons (string-append #$(gnutls-package)
>>  "/share/guile/site")
>>   %load-path)))
>>   #~#t)
>
> Oops, my bad.  I think this code should be changed to use site/2.0,
> which is the standard search path specification.
>
>> For now, I think we should revert this commit and discuss it further
>> before proceeding.
>
> I would just fix the above code to append (effective-version).  WDYT?
>
 Yes, but I'm a little concerned.  Should it really be so?  What about
 guile-1.8; isn't it supposed to use gnutls module as well?
>>>
>>> 1.8 has long been deprecated, so let’s not worry about it.
>>
>> I think Alex was right to be concerned.  We'll have the same problem
>> when Guile 2.2 comes around, and then again for 2.4.  I'm reluctant to
>> hardcode "2.0" into the code above.  Think about what it implies for
>> GnuTLS in the future.  Will they be expected to install their modules
>> into site/2.0, site/2.2, site/2.4, etc?  Do we really want to advocate
>> this practice to projects that install Guile modules?
>
> No, you’re right, of course.  However, I tend to distinguish between the
> immediate issue that calls for a fix, and the design issue that has to
> be addressed, but is less pressing.
>
> Currently, there are a couple of packages that hard-code site/2.0.  They
> should be changed to use:
>
>   (string-append "--with-site-dir=.../site/" (effective-version))
>
> That doesn’t help with 1.8, though, because 1.8 uses /site.  Perhaps a
> fix would be to change 1.8 in Guix so that it uses a versioned site
> directory like future versions do?  Another option would be to ignore 1.8.
>
> WDYT?
>
> There may be similar problems with Python, Ruby, etc., although these
> haven’t come up yet, I think.  These can hopefully be addressed by
> having their respective build system pass #:effective-version to the
> build code.  Thoughts?

Why not just allow gnutls and other packages to install guile modules in
a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
suggested at
?

-- 
Alex

Re: Ruby gems in user land ($HOME)

[Pjotr Prins]

On Mon, Oct 27, 2014 at 10:23:19AM +0100, Ludovic Courtès wrote:
> > export 
> > GEM_PATH=/home/wrk/.gem/ziy7a6zib846426kprc7fgimggh8bz97-ruby-2.1.3/2.1.0   
> >  
> > export GEM_HOME=$GEM_PATH   
> > 
> > export 
> > GEM_SPEC_CACHE=/home/wrk/.gem/ziy7a6zib846426kprc7fgimggh8bz97-ruby-2.1.3/specs
> >   
> 
> I suspect this won???t be very convenient.  ;-)  I???m not sure what can be
> done to help.

Patching ruby in a few places would be enough. Alternatively have a
wrapper script that sets these default values, unless they already are
defined. Would you accept such patches?

Pj.

Re: ‘strip’ phase

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> IMO, the best solution is to check for the presence of ELF headers
>> ourselves.  We already have ELF code in Guile master.
>
> Yes, that sounds good.  Instead of relying on Guile’s ELF code, perhaps
> it would be enough to check for the presence of the ELF magic bytes?

Agreed.  The test need not be perfect, because the worst that can happen
is an _occasional_ warning from 'strip', which really will be harmless :)

Thanks,
  Mark

Re: Problems with downloading from https

[Mark H Weaver]

Alex Kost  writes:

> Mark H Weaver (2014-10-27 12:06 +0300) wrote:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Alex Kost  skribis:
>>>
 Ludovic Courtès (2014-10-26 16:46 +0300) wrote:

> Alex Kost  skribis:
>
>> Yes, I installed gnutls, but it didn't work because I didn't set the
>> right guile paths: “guix package --search-paths” recommends
>> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site/2.0"
>> but "gnutls.scm" is actually placed in
>> "/usr/local/var/guix/profiles/per-user//guix-profile/share/guile/site"
>> so ‘(use-modules (gnutls))’ failed for me.
>
> Oh, that’s a bug of the GnuTLS package: we should pass the right
> configure flag so that modules go to site/2.0.  Could you do that?
>>
>> Alex committed this change, and it broke all https downloads in Guix,
>> leading to hydra build failures.  For example, see:
>>
>>   http://hydra.gnu.org/build/132928/nixlog/1/raw
>
> [...]
>
> OMG!  I'm sorry about that.  And thanks for fixing imlib2 license issue.
>
> I'm feeling guilty and I think I shouldn't touch anything outside
> "emacs" directory.  Sorry again.

No, not at all!  We all very much appreciate your contributions, Alex,
and you only did what Ludovic asked you to do.  Anyway, it's not as
though a few missing builds on Hydra is the end of the world.  That
happens quite regularly anyway, so please don't worry about it.

  Mark

Re: Problems with downloading from https

[Mark H Weaver]

Alex Kost  writes:

> Why not just allow gnutls and other packages to install guile modules in
> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
> suggested at
> ?

In my opinion, this is the right fix.  There is plenty of Guile code
that works on both Guile 1.8 and Guile 2.0, so there's no need to put
Scheme modules in versioned directories.  We provide 'cond-expand' when
it's really needed, after all.

Guile 2 puts both "site/2.0" and "site" in its load path by default,
which signals to developers that they can choose either location.

Furthermore, if changing the installation directory of the GnuTLS
modules broke Guix, there's a non-trivial possibility that we might
break something else.

Please, let's leave the GnuTLS modules where they are, and add "site" to
the search-path-specification, as Alex suggests.

What do you think?

  Mark

Re: Problems with downloading from https

[Ludovic Courtès]

Mark H Weaver  skribis:

> Alex Kost  writes:
>
>> Why not just allow gnutls and other packages to install guile modules in
>> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
>> suggested at
>> ?
>
> In my opinion, this is the right fix.  There is plenty of Guile code
> that works on both Guile 1.8 and Guile 2.0, so there's no need to put
> Scheme modules in versioned directories.  We provide 'cond-expand' when
> it's really needed, after all.

A problem is that it would make it impossible to install the 1.8/2.1 and
the 2.0 version of something in the same profile.

Currently it’s possible to install both ‘python’ and ‘python2’ in the
same profile, as well as ‘python-foo’ and ‘python2-foo’.

With the addition of a --program-suffix configure flag, it would be
possible to do the same with Guile 1.8/2.0/2.1.

I think it’s a useful feature.  WDYT?

> Furthermore, if changing the installation directory of the GnuTLS
> modules broke Guix, there's a non-trivial possibility that we might
> break something else.

Given that the search path spec for guile-2.0 has always been site/2.0,
I think this change is unlikely to break anything else.  On the
contrary: this change brought GnuTLS in conformance with the other
Guile-using packages.

Thanks,
Ludo’.

Re: Ruby gems in user land ($HOME)

[Ludovic Courtès]

Pjotr Prins  skribis:

> On Mon, Oct 27, 2014 at 10:23:19AM +0100, Ludovic Courtès wrote:
>> > export 
>> > GEM_PATH=/home/wrk/.gem/ziy7a6zib846426kprc7fgimggh8bz97-ruby-2.1.3/2.1.0  
>> >   
>> > export GEM_HOME=$GEM_PATH  
>> >  
>> > export 
>> > GEM_SPEC_CACHE=/home/wrk/.gem/ziy7a6zib846426kprc7fgimggh8bz97-ruby-2.1.3/specs
>> >   
>> 
>> I suspect this won???t be very convenient.  ;-)  I???m not sure what can be
>> done to help.
>
> Patching ruby in a few places would be enough. Alternatively have a
> wrapper script that sets these default values, unless they already are
> defined. Would you accept such patches?

In general, I think it’s better to avoid diverging from upstream, so I’d
rather not patch Ruby itself.

As for a wrapper, I don’t know, but it doesn’t sound very nice either.
But really, the best thing to work on would be Gems as Guix packages.
:-)

Ludo’.

Re: Problems with downloading from https

[Alex Kost]

Ludovic Courtès (2014-10-27 19:24 +0300) wrote:

> Mark H Weaver  skribis:
>
>> Alex Kost  writes:
>>
>>> Why not just allow gnutls and other packages to install guile modules in
>>> a site dir (without version) and to augment GUILE_LOAD_PATH with it as I
>>> suggested at
>>> ?
>>
>> In my opinion, this is the right fix.  There is plenty of Guile code
>> that works on both Guile 1.8 and Guile 2.0, so there's no need to put
>> Scheme modules in versioned directories.  We provide 'cond-expand' when
>> it's really needed, after all.
>
> A problem is that it would make it impossible to install the 1.8/2.1 and
> the 2.0 version of something in the same profile.
>
> Currently it’s possible to install both ‘python’ and ‘python2’ in the
> same profile, as well as ‘python-foo’ and ‘python2-foo’.

[...]

But currently it's not possible to install 2 (or more) packages with the
same name.  So a user can't have guile 2.0 and guile 1.8 in the same
profile.  The same thing with python: there is no ‘python2’ package.
Both python packages have “python” name and can't be installed in the
same profile, as far as I understand.

-- 
Alex

Re: [PATCH 1/2] gnu: Add numpy

[Federico Beffa]

On Sun, Oct 26, 2014 at 7:56 PM, Ludovic Courtès  wrote:
> Can these manuals be built from source?

I get error messages that matplotlib is missing.  I started looking at
matplotlib as well, but I've found that, for the TkAgg back-end, it
needs TKinter which is part of the standard python libraries and it is
built if, during the build phase, tk is available. The current python
package does not build that library (no tk).  In fact, I would like to
add it to be able to move forward with matplotlib :-)

For the other back-ends some packages are missing (python-gtk, Qt, ...)

Another annoying problem is that matplotlib needs numpy, thereby
creating a dependency loop (although only for the documentation).

> If they can but the process is tedious, then it’s OK to leave it that
> way with a TODO, and also a comment stating what its license is.

I've not seen any license statement specific for the documentation.
But, given that the source is distributed with the code, can't we just
assume it is the same license?

>> +(inputs
>> + `(("python" ,python) ; otherwise ld does not find libpython3.3m
>
> This is because Python is not added to ‘LIBRARY_PATH’, right?
>
> I think this is fixed by this patch:
>
>
>
> Can you confirm?

Actually it does not.  The "...-python-numpy-1.9.0-guile-builder"
still shows that only the python-wrapper is imported. The wrapper does
not include the libraries.

> As discussed in the other thread, this should probably be the generic
> (unoptimized) ATLAS here.

I think that as a temporary situation this is OK.  However, in my
opinion it does not make much sense to have a separate sub-optimal
package.  I would like to propose to add specific flags to a single
atlas package and, once the new "local-build" flag will be available,
we will remove those flags.

>
>> +   (alist-replace
>> +'build
>> +(lambda* (#:key outputs inputs
>> +  #:allow-other-keys #:rest args)
>> +  (let* ((build (assoc-ref %standard-phases 'build))
>
> Use ‘alist-cons-before’ instead of calling the original ‘build’ phase (I
> think this was discussed before and there was rough consensus on that.)

OK.

> Just use (string-append ,name "-" ,version) so the ‘package-name’
> procedure isn’t needed.

that's much better :-)

> Use the ‘copy-file’ procedure instead of calling ‘cp’.

The reason that made me use 'cp' instead of 'copy-file' is that the
documentation states that the return value of the latter is not
specified and I'm still not familiar with Guile exception handling.
However, I see many places where 'copy-file' is used without any
'catch'.  In principle this should never fail.  If it is OK, I will do
the same.

>
>> + ;; Tests can only be run after the library has been installed and 
>> not
>> + ;; within the source directory.
>> + (alist-cons-after
>> +  'install 'check
>> +  (lambda _
>> +(with-directory-excursion "/tmp"
>> +  (zero? (system* "python" "-c" "import numpy; numpy.test()"
>> +  (alist-delete
>> +   'check
>> +   %standard-phases))
>
> Just (alist-replace 'check ...) ?

Actually the check phase needs to be moved after the install one (see
comment).  That's the reason for this two step approach.

Thanks for the comments.
Regards,
Fede

Re: forcing local build from a package definition

[Federico Beffa]

On Sun, Oct 26, 2014 at 2:59 PM, Ludovic Courtès  wrote:
> In the not-too-distant future, we’ll be able to mark the package as
> non-substitutable, which will be best.  There’s already a #:local-build?
> flag around, but its semantics are a bit fuzzy at the moment because it
> determines both whether to offload and whether to substitute.  I would
> like that to be improved, by having two different options, before we
> start relying on it in packages.

That sounds great!

Thanks,
Fede

Re: [PATCH 0/4] imake, xfig, and transfig packages

[Eric Bavier]

On Oct 26, 2014 4:24 PM, "Federico Beffa"  wrote:
>
> Hi,
>
> I've installed xfig, my preferred drawing utility :-). Unfortunately
> I've found that it can't find the configuration file "Fig". Without
> that I get a flat look and no bindkeys. This can be fixed, e.g., by
> defining the following environment variable:
>
>
XAPPLRESDIR=/gnu/store/ypqjij3snf40hcrdg5ffnh8vrkqmmpfk-xfig-3.2.5c/etc/X11/app-defaults
> /gnu/store/ypqjij3snf40hcrdg5ffnh8vrkqmmpfk-xfig-3.2.5c/bin/xfig
>
> Not sure if there is a way to fix this through the Imakefile.  If not
> maybe we could add a wrapper?

Thanks for the feedback. I dont use xfig often, so it's nice to hear from
someone who does.  I'll take a look at this.

`~Eric

[PATCH 2/2] gnu: Add 'ttf-liberation'.

[Alex Kost]

Not related to this patch: what about renaming ‘freefont-ttf’ package
into ‘ttf-freefont’ to make all TrueType fonts have a name "ttf-…"?

>From 5cddcfb5939bd783527194381e4a8e107fc39395 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Tue, 28 Oct 2014 09:44:16 +0300
Subject: [PATCH 2/2] gnu: Add 'ttf-liberation'.

* gnu/packages/fonts.scm (ttf-liberation): New variable.
---
 gnu/packages/fonts.scm | 65 ++
 1 file changed, 65 insertions(+)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 825395b..94bf79d 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -203,6 +203,71 @@ package provides the TrueType (TTF) files.")
 10646/Unicode UCS (Universal Character Set).")
(license license:gpl3+)))
 
+(define-public ttf-liberation
+  (package
+(name "ttf-liberation")
+(version "2.00.1")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://fedorahosted.org/releases/l/i/";
+  "liberation-fonts/liberation-fonts-ttf-"
+  version ".tar.gz"))
+  (sha256
+   (base32
+"010m4zfqan4w04b6bs9pm3gapn9hsb18bmwwgp2p6y6idj52g43q"
+(build-system trivial-build-system)
+(arguments
+ `(#:modules ((guix build utils))
+   #:builder
+   (begin
+ (use-modules (guix build utils))
+
+ (let ((tar  (string-append (assoc-ref %build-inputs "tar")
+"/bin/tar"))
+   (PATH (string-append (assoc-ref %build-inputs "gzip")
+"/bin"))
+   (font-dir (string-append %output "/share/fonts/truetype"))
+   (doc-dir  (string-append %output "/share/doc/" ,name)))
+   (setenv "PATH" PATH)
+   (system* tar "xvf" (assoc-ref %build-inputs "source"))
+   (mkdir-p font-dir)
+   (mkdir-p doc-dir)
+   (chdir (string-append "liberation-fonts-ttf-" ,version))
+   (for-each (lambda (ttf)
+   (copy-file ttf
+  (string-append font-dir "/"
+ (basename ttf
+ (find-files "." "\\.ttf$"))
+   (for-each (lambda (doc)
+   (copy-file doc
+  (string-append doc-dir "/"
+ (basename doc
+ '("AUTHORS" "ChangeLog" "LICENSE" "README" "TODO"))
+(native-inputs
+ `(("source" ,source)
+   ("tar" ,tar)
+   ("gzip" ,gzip)))
+(home-page "https://fedorahosted.org/liberation-fonts/";)
+(synopsis
+ "Fonts compatible with Arial, Times New Roman, and Courier New")
+(description
+ "The Liberation font family aims at metric compatibility with
+Arial, Times New Roman, and Courier New.
+
+There are three sets:
+
+- Sans (a substitute for Arial, Albany, Helvetica, Nimbus Sans L, and
+Bitstream Vera Sans);
+
+- Serif (a substitute for Times New Roman, Thorndale, Nimbus Roman, and
+Bitstream Vera Serif);
+
+- Mono (a substitute for Courier New, Cumberland, Courier, Nimbus Mono L,
+and Bitstream Vera Sans Mono).
+
+The Liberation Fonts are sponsored by Red Hat.")
+(license license:silofl1.1)))
+
 (define-public terminus-font
   (package
 (name "terminus-font")
-- 
2.1.2

[PATCH 1/2] licenses: Add 'silofl1.1'.

[Alex Kost]

The license for the Liberation fonts.  I named it ‘silofl1.1’ or should
it be just ‘silofl’?  Also about the title: "SIL Open Font License 1.1"
or "SILOFL 1.1" or something else?

>From ef66e2f801d5b54bb16074bea747888e6ed4e5be Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Tue, 28 Oct 2014 09:38:04 +0300
Subject: [PATCH 1/2] licenses: Add 'silofl1.1'.

* guix/licenses.scm (silofl1.1): New variable.
---
 guix/licenses.scm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/guix/licenses.scm b/guix/licenses.scm
index 8b7ea53..3f1e8b0 100644
--- a/guix/licenses.scm
+++ b/guix/licenses.scm
@@ -44,6 +44,7 @@
 psfl public-domain
 qpl
 ruby
+silofl1.1
 vim
 x11 x11-style
 zlib
@@ -267,6 +268,11 @@ which may be a file:// URI pointing the package's tree."
"http://directory.fsf.org/wiki/License:Ruby";
"https://www.ruby-lang.org/en/about/license.txt";))
 
+(define silofl1.1
+  (license "SIL Open Font License 1.1"
+   "http://scripts.sil.org/OFL_web";
+   "https://www.gnu.org/licenses/license-list#SILOFL";))
+
 (define vim
   (license "Vim"
"http://directory.fsf.org/wiki/License:Vim7.2";
-- 
2.1.2