Re: [PATCHES] Add totem

[Mark H Weaver]

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

 From ba786fa3d1d7896336dca3b364bb630142c30fa1 Mon Sep 17 00:00:00 2001
 From: Mark H Weaver m...@netris.org
 Date: Sat, 20 Jun 2015 21:09:54 -0400
 Subject: [PATCH 2/3] gnu: Add grilo-plugins.

 * gnu/packages/gnome.scm (grilo-plugins): New variable.

 [...]

 + `(#:make-flags (list (string-append GRL_PLUGINS_DIR=
 + %output
 + /lib/grilo-
 + ,(version-major+minor version)))
 +   ;; XXX FIXME: Investigate test failure:
 +   ;;   TEST: test_apple_trailers... (pid=8718)
 +   ;; /apple-trailers/browse/count:
 +   ;;   ERROR:test_apple_trailers.c:88:test_browse_count: assertion 
 failed: (source)
 +   ;;   FAIL
 +   #:tests? #f))

 Would it be OK to skip just this for now?  If that’s too much, we can
 leave it for later.

make check aborts after this failure, which is the first test.  I
tried make -k check and found that _all_ tests fail with the same
assertion failure when run in the build container.

However, if I run make -k check on the failed build directory in
/tmp/nix-build-* from outside of the build container, all but one of the
tests succeeds.  This when using the precise environment variable
settings from the build and no others.  Using strace, I found that it
was accessing the system dbus, so I guess that's the problem.

 +(synopsis Framework for discovering and browsing media - Plugins)

 Maybe “Plugins for the Grilo media discovery library”?

Yes, that's better, thanks!

I'm going to hold off on pushing grilo{-plugins} and totem until the
'nettle-fix' branch is merged (it fixes gst-libav on x86_64), and also
to get more feedback on how best to handle totem's required plugins and
dbus services.

  Thanks,
Mark

Re: [PATCH] Add yaggo.

[Ricardo Wurmus]

 I must reiterate my concern about this approach to the wider
 guix-devel audience.  From what I can see, the gem archives hosted on
 rubygems.org are build artifacts and should probably be treated like
 pre-built binaries.  They are not the complete, corresponding source
 code.  Can anyone else weigh in here?

The gemspec file must list all files (either explicitly or via patterns)
that are to be distributed and thus needed at runtime.

As far as I can tell gem push name.gem can be used to upload anything
to rubygems.org that is considered a valid gem.  rubygems.org will only
extract the gemspec metadata and process them for later display[1].  The
parsed and possibly validated gemspecs are included in the gem when
doing gem build name.gemspec.  For more info on what gem build does
see [2].

This means that using standard tools (unmodified gem) the generated
gem is packaged according to the information in the gemspec file.  A gem
seems to be little more than a tar archive.  I would not consider this a
build artifact, but release tarballs.  We don't have a problem with
using release tarballs over git clones for non-Ruby applications, even
though the tarballs may contain somewhat different sources (e.g. added
ChangeLog).

Of course, a gem created with a modified tool could contain more or less
than what the gemspec file declares.  But I would treat this in much the
same manner as I would treat broken release tarballs.

~~ Ricardo

[1]: 
https://github.com/rubygems/rubygems.org/blob/master/app/models/pusher.rb#L47
[2]: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/package.rb

Re: [PATCH] Add seqtk.

[Mark H Weaver]

Ben Woodcroft b.woodcr...@uq.edu.au writes:
 I feel somewhat honoured to even be mentioned in the same thread as kseq.h

:-)

 From 48d3adae4bcada110df3fb7d8c5ddc55ad2000ff Mon Sep 17 00:00:00 2001
 From: Ben Woodcroft donttrust...@gmail.com
 Date: Wed, 24 Jun 2015 15:04:48 +1000
 Subject: [PATCH] gnu: Add seqtk.

 * gnu/packages/bioinformatics.scm (seqtk): New variable.
 ---
  gnu/packages/bioinformatics.scm | 45 
 +
  1 file changed, 45 insertions(+)

 diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
 index 8dfaff3..e4575ae 100644
 --- a/gnu/packages/bioinformatics.scm
 +++ b/gnu/packages/bioinformatics.scm
 @@ -1573,6 +1573,51 @@ any particular back-end implementation, and supports 
 use of multiple back-ends
  simultaneously.)
  (license license:public-domain)))
  
 +(define-public seqtk
 +  (let ((commit 4feb6e814))
 +(package
 +  (name seqtk)
 +  ;; version number from running 'seqtk' after installation
 +  (version (string-append 1.0-r82. commit))
 +  (source (origin
 +(method git-fetch)
 +(uri (git-reference
 +  (url https://github.com/lh3/seqtk.git;)
 +  (commit commit)))
 +(sha256
 + (base32
 +  0wdkz8chkinfm23cg95nrn797lv12n2wxglwb3s2kvf0iv3rrx01
 +  (build-system gnu-build-system)
 +  (arguments
 +   `(#:tests? #f
 +  #:phases

The misalignment of the code above in this email was caused by your use
of tabs.  Please do not use tabs anywhere in *.scm files in Guix.  (This
is also an issue in your yaggo patch.)

Please add a brief comment explaining why tests are disabled, in this
case: #:tests? #f  ;no test suite.

 +  (modify-phases %standard-phases
 +(delete 'configure)
 +(replace 'build
 + (lambda* _
 +   (zero? (system* make

Why replace the default 'build' phase of the gnu-build-system here?  The
only difference is that the default build phase adds -jN to enable a
parallel build by default.

 +(replace 'install
 + (lambda* (#:key outputs #:allow-other-keys)
 +   (let ((bin (string-append
 +   (assoc-ref outputs out)
 +   /bin/)))
 + (mkdir-p bin)
 + (copy-file seqtk (string-append
 + bin seqtk))
 + (copy-file trimadap (string-append
 + bin trimadap

Phase procedures should return a boolean indicating whether the phase
succeeded, but the return value of 'copy-file' is not specified.  Please
add #t after the last call to 'copy-file'.

 +  (native-inputs
 +   `((zlib ,zlib)))

zlib needs to be a normal input here, so please replace native-inputs
with inputs.

 +  (home-page https://github.com/lh3/seqtk;)
 +  (synopsis Toolkit for processing sequences in FASTA/Q formats)
 +  (description
 +   Seqtk is a fast and lightweight tool for processing sequences in
 +the FASTA or FASTQ format.  It seamlessly parses both FASTA and FASTQ
 +files which can also be optionally compressed by gzip.)
 +  (license (license:non-copyleft
 + file://src/LICENSE
 + See src/LICENSE in the distribution.)

It's the expat license, so just write (license license:expat).  The
author calls it The MIT License, but that term is misleading since MIT
has used many licenses for software, e.g. the X11 license.

However, there's a bigger problem here.  Some of the code is not clearly
licensed or has invalid copyright notices:

* The copyright notice on kstring.h lacks copyright dates.

* The copyright dates in seqtk.c and LICENSE are incorrect
  (20082-2012).

* ksw.h and trimadap.c lack any copyright notice at all.  The mere
  presence of a LICENSE file is not enough, especially given the lack of
  any statement about the code license in the README.

Would you be willing to ask the author to fix these issues?

   Mark

Re: [PATCH] Add yaggo.

[Thompson, David]

On Wed, Jun 24, 2015 at 1:51 AM, Pjotr Prins pjotr.publi...@thebird.nl wrote:
 On Wed, Jun 24, 2015 at 02:35:03PM +1000, Ben Woodcroft wrote:
 Actually, I lie, this patch only sort of works. The issue is that it
 only works when a ruby package is also installed, GEM_PATH does not
 get set as part of the ruby-build-system for yaggo. The lib/ files
 are copied to what I gather is the correct place, but the env isn't
 right.

 The same also appears to be true of other ruby packages e.g. ruby-hoe:
 $ guix package -i ruby-hoe
 ..
 ben@u:~/git/guix$ guix package --search-paths
 warning: failed to install locale: Invalid argument
 export PATH=/home/ben/.guix-profile/bin:/home/ben/.guix-profile/sbin
 export PYTHONPATH=/home/ben/.guix-profile/lib/python3.4/site-packages
 export 
 PKG_CONFIG_PATH=/home/ben/.guix-profile/lib/pkgconfig:/home/ben/.guix-profile/share/pkgconfig
 export GUILE_LOAD_PATH=/home/ben/.guix-profile/share/guile/site/2.0
 export 
 GUILE_LOAD_COMPILED_PATH=/home/ben/.guix-profile/share/guile/site/2.0
 export CPATH=/home/ben/.guix-profile/include
 export LIBRARY_PATH=/home/ben/.guix-profile/lib
 export ACLOCAL_PATH=/home/ben/.guix-profile/share/aclocal

 i.e. no GEM_PATH entry, hence:

 That is correct. The Ruby support system is still in development.

 Adding the GEM_PATH is on the books as well as GEM_HOME and
 GEM_SPEC_CACHE to have the gem and rspec tools work also outside GNU
 Guix.

I don't know about $GEM_SPEC_CACHE, but $GEM_HOME cannot be a native
search path that is part of our ruby packages, because native search
paths are relative to store items, which are immutable.  My feeling is
that if the user wants to use the 'gem' utility instead of using Guix
packages, they're going to have to set an environment variable or two
by themselves.

 At the moment we are working on native gems (i.e. those that contain
 C code). I am also planning for a rubygem-build-system which would
 allow us to include gems with very simple package definitions, e.g.,
 rather then

   (define-public ruby-i18n
 (package
   (name ruby-i18n)
   (version 0.6.11)
   (source (origin
 (method url-fetch)
 (uri (string-append 
 https://github.com/svenfuchs/i18n/archive/v;
 version .tar.gz))
 (file-name (string-append name - version .tar.gz))
 (sha256
  (base32
   1fdhnhh1p5g8vibv44d770z8nq208zrms3m2nswdvr54072y1m6k
   (build-system ruby-build-system)
   (synopsis Internationalization library for Ruby)
   (...)

 we get

   (define-public ruby-i18n
 (package
   (name ruby-i18n)
   (version 0.6.11)
   (source (origin
 (method gem-fetch)
 (file-name (string-append name - version .gem))
 (sha256
  (base32
   1fdhnhh1p5g8vibv44d770z8nq208zrms3m2nswdvr54072y1m6k
   (build-system rubygem-build-system)
   (synopsis Internationalization library for Ruby)
   (...)

 which would install directly from rubygems.org (including contained
 dependencies when missing in the existing environment).

Are you saying that it would bundle the dependencies if there were no
Guix packages for them?

 This would greatly facilitate adding Ruby gems to guix.

I must reiterate my concern about this approach to the wider
guix-devel audience.  From what I can see, the gem archives hosted on
rubygems.org are build artifacts and should probably be treated like
pre-built binaries.  They are not the complete, corresponding source
code.  Can anyone else weigh in here?  I understand the convenience of
using rubygems.org, but I really need some evidence that the archives
hosted there are complete, corresponding source code.

Thanks,

- Dave

[PATCH] Fix R.

[Ricardo Wurmus]

Currently, R cannot be built because the default GCC is now 4.9 but R
depends on gfortran 4.8.

These two patches add gfortran-4.9 and update the R package to use it.

From 6c25bf3435fc690c75ba7bbf2b98c60bf5261cfc Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus ricardo.wur...@mdc-berlin.de
Date: Wed, 24 Jun 2015 11:36:18 +0200
Subject: [PATCH 1/2] gnu: Add gfortran 4.9.

* gnu/packages/gcc.scm (gfortran-4.9): New variable.
---
 gnu/packages/gcc.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index c370fe8..389610d 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -394,6 +394,9 @@ using compilers other than GCC.
 (define-public gfortran-4.8
   (custom-gcc gcc-4.8 gfortran '(fortran)))
 
+(define-public gfortran-4.9
+  (custom-gcc gcc-4.9 gfortran '(fortran)))
+
 (define-public gccgo-4.8
   (custom-gcc gcc-4.8 gccgo '(go)
   ;; Suppress the separate lib output, because otherwise the
-- 
2.1.0

From 2a5f0deb7aa00be00e43f120bab8e5d97c6a9a51 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus ricardo.wur...@mdc-berlin.de
Date: Wed, 24 Jun 2015 11:37:56 +0200
Subject: [PATCH 2/2] gnu: r: Use gfortran-4.9.

* gnu/packages/statistics.scm (r)[inputs]: Replace gfortran-4.8 with
  gfortran-4.9.
---
 gnu/packages/statistics.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 9408705..8d5d4c3 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -90,7 +90,7 @@
 (inputs
  `((atlas ,atlas) ; --with-blas
(cairo ,cairo)
-   (gfortran ,gfortran-4.8)
+   (gfortran ,gfortran-4.9)
(icu4c ,icu4c)
(icedtea6 ,icedtea6 jdk)
(lapack ,lapack)
-- 
2.1.0

Re: [PATCH] Add yaggo.

[Thompson, David]

On Wed, Jun 24, 2015 at 12:35 AM, Ben Woodcroft b.woodcr...@uq.edu.au wrote:
 Actually, I lie, this patch only sort of works. The issue is that it only
 works when a ruby package is also installed, GEM_PATH does not get set as
 part of the ruby-build-system for yaggo. The lib/ files are copied to what I
 gather is the correct place, but the env isn't right.

 The same also appears to be true of other ruby packages e.g. ruby-hoe:

This is the expected, correct behavior.  The native search path
$GEM_PATH is defined in the ruby package, like so:

(native-search-paths
 (list (search-path-specification
(variable GEM_PATH)
   (files (list (string-append lib/ruby/gems/
(version-major+minor version)
.0))

Thus, you need ruby to be a part of your profile.  Perhaps ruby should
be a propagated input for packages with ruby executables, or scripts
could be wrapped in another script that set the correct environment
variables.

- Dave

Re: How to handle required plugins and dbus services for GNOME Programs?

[Ludovic Courtès]

Mark H Weaver m...@netris.org skribis:

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

[...]

 I can imagine why the plugins package need to be in the profile, but I
 find the others more surprising.  Do you know what happens?  Are Grilo,
 GStreamer, and DConf dlopened, or is it just to get the right search
 path recommendation that they are needed?

 Actually, it turns out that 'grilo' doesn't need to be in the profile,
 although if you don't have it you won't get the search path
 recommendation which is crucial for Totem to work properly.

OK.

I wonder if search path recommendations should work “deeper” somehow.
Because currently there’s always a problem when the search path
specification is attached to a library (GST_*, GRL_*) rather than to an
executable (CPATH, GUILE_LOAD_PATH, etc.)

The difficulty is that, ideally, the propagation of search path
specifications would be based on the run-time dependencies, not the
compile-time dependencies.

Thoughts?

 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
 need to explicitly install it and I'm not sure what would happen if it
 were removed.

 'dconf' apparently needs to be in the profile for both GNOME Terminal
 and Totem because of the session dbus service(s) it provides.  Without
 it, modern GNOME programs behave quite badly.  They have no way to
 access or change their own configuration settings, e.g. if you go into
 their preferences, you see checkboxes that do not change their state
 when clicked.

Really?  In Evince, I can change the state of various things (such as
whether or not to view documents continuously), but those changes are
lost across restarts.  However, changes made via dconf-editor are not
lost.  Weird no?

 I'm not sure how best to deal with issues like this, and also with
 things like grilo-plugins and gst-plugins-* that are needed for the
 proper functioning of Totem.  Should we make them propagated-inputs?

Are they required, or is it just that fewer features/file formats are
supported when they’re unavailable?

They could be propagated, but one would still need to know about these
environment variables.

 Or perhaps they should be normal inputs and we should use a wrapper to
 add those directories as suffixes to GRL_PLUGIN_PATH and
 GST_PLUGIN_SYSTEM_PATH automatically?

If they are required, that may be best.

Thanks,
Ludo’.

Re: [PATCH] import: pypi: Detect inputs.

[Cyril Roelandt]

On 06/24/2015 09:49 PM, Ludovic Courtès wrote:
 Cyril Roelandt tipec...@gmail.com skribis:
 
 WDYT?
 
 Makes sense to me.
 
 The latest version of the patch (posted on Monday 15th) LGTM;
 please push.
 

Pushed in ff986890ece06b0623a7c8b3048dea1206f076ea .


Cyril.

Re: [PATCH 2/5] build: emacs-utils: Add 'emacs-byte-compile-directory'

[Ludovic Courtès]

Federico Beffa be...@ieee.org skribis:

 From ec5fbc02e09359bf64b69efed314471e5f409fa4 Mon Sep 17 00:00:00 2001
 From: Federico Beffa be...@fbengineering.ch
 Date: Tue, 16 Jun 2015 21:09:57 +0200
 Subject: [PATCH 2/5] build: emacs-utils: Add 'emacs-byte-compile-directory'.

 * guix/build/emacs-utils.scm (emacs-byte-compile-directory): New procedure.

LGTM, thanks!

Ludo’.

Re: [PATCH] gnu: gstreamer: Add search path specification for 'GST_PLUGIN_SYSTEM_PATH'.

[Ludovic Courtès]

宋文武 iyzs...@gmail.com skribis:

 This reverts commit e53fc0c8a, which add it wrongly to gst-plugins-base.

 * gnu/packages/gstreamer.scm (gstreamer)[native-search-paths]: New field.
   (gst-plugins-base)[native-search-paths]: Remove.

LGTM!

I wonder, why is there the word “SYSTEM” in this variable name?  Does
that means there also exists GST_PLUGIN_PATH?

Thanks,
Ludo’.

Re: [PATCH] gnu/package/pv.scm (pv): New file, new variable

[韋嘉誠]

On Tue, Jun 23, 2015 at 1:43 PM, Alex Kost alez...@gmail.com wrote:

 --8---cut here---start-8---
 gnu: Add pv.

 * gnu/package/pv.scm (pv): New file.
 * gnu-system.am (GNU_SYSTEM_MODULES): Add it.
 --8---cut here---end---8---

 And you also need to add gnu/package/pv.scm to gnu-system.am.  See
 commit 741115b for example.

 IIUC you are the only author of this file, right?  Then there is no
 place for Ludovic there.

 I think we prefer 'define-public' over exporting the package variables,
 but it is probably not a strong convention.

 I would put Pipe Viewer in parentheses:

 pv (Pipe Viewer) is a terminal-based tool for monitoring the progress

 I realize that you took this description from the home page, but our
 convention is to use two spaces between sentences.


Updated accordingly!

-- 
   /c


0001-gnu-Add-pv.patch
Description: Binary data

Compile guix from git?

[韋嘉誠]

How do people compile guix directly from git source? I've been
searching around in HACKING and manual.html#Contributing and other
places, the internet in general, and haven't been able to find any
instructions.

It ought to be:

1. Get dependencies manually or with 'guix environment guix'.
2. aclocal
3. automake, maybe automake -a
4. autoconf
5. configure --sharedstatedir=/var --with-libgcrypt-prefix=wherever
6. make

But #3 fails. nix/config.h.in is missing, maybe other things too but
that's where it halts.

What I do now to make it work is I insert:

1.1. tar axf --strip-component=1 /path/to/guix-0.8.2.tar.gz
1.2. git checkout HEAD .
1.3. git clean -fd

Seems to be working, but there must be something everyone else is
doing that I missed in a document somewhere. Or maybe everyone is
working in checkouts made at some point when that file existed?

Re: [PATCH] emacs: Add 'guix-root-map'.

[Ludovic Courtès]

Alex Kost alez...@gmail.com skribis:

 This patch does not modify the current interface in any way.  I just
 realized that it is possible to make a root keymap instead of binding
 common keys in all other maps.  It became possible after commit dfeb023
 but it's better late than never :-)

:-)

 From 1888974254efc8b71d3a109926ec1a13660f3b9d Mon Sep 17 00:00:00 2001
 From: Alex Kost alez...@gmail.com
 Date: Wed, 24 Jun 2015 10:36:18 +0300
 Subject: [PATCH] emacs: Add 'guix-root-map'.

 * emacs/guix-base.el (guix-define-buffer-type): Move common key bindings
   from here...
   (guix-root-map): ... to here.  New variable.
 * emacs/guix-info.el (guix-info-mode-map): Use it.
 * emacs/guix-list.el (guix-list-mode-map): Use it.
 * doc/emacs.texi (Emacs Keymaps): Document it.

Sure, please push!

Thanks,
Ludo’.

Re: [PATCH 1/5] import: Add 'elpa' importer

[Ludovic Courtès]

Federico Beffa be...@ieee.org skribis:

 From 595befd0fb88ae00d405a727efb55b9fa456e549 Mon Sep 17 00:00:00 2001
 From: Federico Beffa be...@fbengineering.ch
 Date: Tue, 16 Jun 2015 10:50:06 +0200
 Subject: [PATCH 1/5] import: Add 'elpa' importer.

 * guix/import/elpa.scm: New file.
 * guix/scripts/import.scm: Add elpa to 'importers'.
 * guix/scripts/import/elpa.scm: New file.
 * Makefile.am (MODULES): Add 'guix/import/elpa.scm' and
   'guix/scripts/import/elpa.scm'.
   (SCM_TESTS): Add 'tests/elpa.scm'.
 * doc/guix.texi (Invoking guix import): Document it.
 * tests/elpa.scm: New file.

This looks nice!  (And you were fast!)

Below are some comments essentially nitpicking about the style.

 --- a/doc/guix.texi
 +++ b/doc/guix.texi
 @@ -3770,6 +3770,33 @@ package name by a hyphen and a version number as in 
 the following example:
  @example
  guix import hackage mtl-2.1.3.1
  @end example
 +
 +@item elpa
 +@cindex elpa
 +Import meta-data from an Emacs ELPA package repository.

Rather:

  from an Emacs Lisp Package Archive (ELPA) package repository
  (@pxref{Packages,,, emacs, The GNU Emacs Manual}).

 +Specific command-line options are:
 +
 +@table @code
 +@item --archive=@var{repo}
 +@itemx -a @var{repo}
 +@var{repo} identifies the archive repository from which to retrieve the
 +information.  Currently the supported repositories and their identifiers
 +are:
 +@itemize -
 +@item
 +@uref{http://elpa.gnu.org/packages;, GNU}, selected by the @code{gnu}
 +identifier.  This is the default.
 +
 +@item
 +@uref{http://stable.melpa.org/packages;, MELPA-Stable}, selected by the
 +@code{melpa-stable} identifier.
 +
 +@item
 +@uref{http://melpa.org/packages;, MELPA}, selected by the @code{melpa}
 +identifier.
 +@end itemize

Perhaps REPO could also be a URL, in addition to one of these identifiers?

 +(define (elpa-dependencies-names deps)
 +  Convert the list of dependencies from the ELPA format, to a list of string
 +names.

What about:

  Convert DEPS, a list of foobars à la ELPA, to a list of package names
  as strings.

 +  (map (lambda (d) (symbol-string (first d))) deps))

(match deps
  (((names _ ...) ...)
   (map symbol-string names)))

 +(define (filter-dependencies names)
 +  Remove the package names included with Emacs from the list of
 +NAMES (strings).
 +  (let ((emacs-standard-libraries
 + '(emacs cl-lib)))
 +(filter (lambda (d) (not (member d emacs-standard-libraries)))
 +names)))

In general I think it’s best to give the predicate a name, and to not
define a ‘filter-xxx’ or ‘remove-xxx’ function.  So:

  (define emacs-standard-library?
(let ((libs '(emacs cl-lib)))
  (lambda (lib)
Return true if ...
(member lib libs

and then:

  (filter emacs-standard-library? names)

wherever needed.

 +(define* (elpa-url #:optional (repo gnu))

I would rather use a symbol for REPO.

 +;; Fetch URL, store the content in a temporary file and call PROC with that
 +;; file.
 +(define fetch-and-call-with-input-file
 +  (memoize
 +   (lambda* (url proc #:optional (err-msg unavailable))
 + (call-with-temporary-output-file
 +  (lambda (temp port)
 +(or (and (url-fetch url temp)
 + (call-with-input-file temp proc))
 +err-msg))

Make the comment a docstring below ‘lambda*’.

I would call it ‘call-with-downloaded-file’ for instance.  But then
memoization should be moved elsewhere, because that’s not one would
expect from a procedure with this name.

The return value must also be documented.  Returning an error message is
not an option IMO, because the caller could hardly distinguish it from a
“normal” return value, and because that’s a very unusual convention.

Probably an error condition should be raised?

 +(define* (elpa-package-info name #:optional (repo gnu))
 +  Extract the information about the package NAME from the package archieve 
 of
 +REPO.
 +  (let* ((archive (elpa-fetch-archive repo))
 + (info (filter (lambda (p) (eq? (first p) (string-symbol name)))
 +   (cdr archive
 +(if (pair? info) (first info) #f)))

Give the predicate a name, and rather use ‘match’.

 +(define (lookup-extra alist key)
 +  Lookup KEY from the ALIST extra package information.
 +  (assq-ref alist key))

Use ‘assq-ref’ directly.

 +(define (package-home-page alist)
 +  Extract the package home-page from ALIST.
 +  (or (lookup-extra alist ':url) unspecified))

Maybe use the ‘elpa-package’ prefix instead of ‘package’ for procedures
like this one that expect an ELPA-package-as-an-alist?

 +(define (nil-empty alist)
 +  If ALIST is the symbol 'nil return the empty list.  Otherwise, return 
 ALIST.

Rather ‘ensure-list’.

Thank you!

Ludo’.

[PATCH] emacs: Add 'guix-root-map'.

[Alex Kost]

This patch does not modify the current interface in any way.  I just
realized that it is possible to make a root keymap instead of binding
common keys in all other maps.  It became possible after commit dfeb023
but it's better late than never :-)

From 1888974254efc8b71d3a109926ec1a13660f3b9d Mon Sep 17 00:00:00 2001
From: Alex Kost alez...@gmail.com
Date: Wed, 24 Jun 2015 10:36:18 +0300
Subject: [PATCH] emacs: Add 'guix-root-map'.

* emacs/guix-base.el (guix-define-buffer-type): Move common key bindings
  from here...
  (guix-root-map): ... to here.  New variable.
* emacs/guix-info.el (guix-info-mode-map): Use it.
* emacs/guix-list.el (guix-list-mode-map): Use it.
* doc/emacs.texi (Emacs Keymaps): Document it.
---
 doc/emacs.texi |  3 +++
 emacs/guix-base.el | 21 -
 emacs/guix-info.el |  2 +-
 emacs/guix-list.el |  4 +++-
 4 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/doc/emacs.texi b/doc/emacs.texi
index 0e89a11..180037a 100644
--- a/doc/emacs.texi
+++ b/doc/emacs.texi
@@ -426,6 +426,9 @@ If you want to change default key bindings, use the following keymaps
 (@pxref{Init Rebinding,,, emacs, The GNU Emacs Manual}):
 
 @table @code
+@item guix-root-map
+Parent keymap with general keys for all guix modes.
+
 @item guix-list-mode-map
 Parent keymap with general keys for ``list'' buffers.
 
diff --git a/emacs/guix-base.el b/emacs/guix-base.el
index 587288e..fe89584 100644
--- a/emacs/guix-base.el
+++ b/emacs/guix-base.el
@@ -295,6 +295,17 @@ See `guix-update-after-operation' for details.
 
 ;;; Common definitions for buffer types
 
+(defvar guix-root-map
+  (let ((map (make-sparse-keymap)))
+(define-key map (kbd l) 'guix-history-back)
+(define-key map (kbd r) 'guix-history-forward)
+(define-key map (kbd g) 'revert-buffer)
+(define-key map (kbd R) 'guix-redisplay-buffer)
+(define-key map (kbd M) 'guix-apply-manifest)
+(define-key map (kbd C-c C-z) 'guix-switch-to-repl)
+map)
+  Parent keymap for all guix modes.)
+
 (defvar-local guix-profile nil
   Profile used for the current buffer.)
 (put 'guix-profile 'permanent-local t)
@@ -440,15 +451,7 @@ following keywords are available:
   \\{ mode-map-str })
  (setq-local revert-buffer-function 'guix-revert-buffer)
  (setq-local guix-history-size ,history-var)
- (and (fboundp ',mode-init-fun) (,mode-init-fun)))
-
-   (let ((map ,mode-map))
- (define-key map (kbd l) 'guix-history-back)
- (define-key map (kbd r) 'guix-history-forward)
- (define-key map (kbd g) 'revert-buffer)
- (define-key map (kbd R) 'guix-redisplay-buffer)
- (define-key map (kbd M) 'guix-apply-manifest)
- (define-key map (kbd C-c C-z) 'guix-switch-to-repl)
+ (and (fboundp ',mode-init-fun) (,mode-init-fun))
 
 (put 'guix-define-buffer-type 'lisp-indent-function 'defun)
 
diff --git a/emacs/guix-info.el b/emacs/guix-info.el
index cbf8f46..bb21024 100644
--- a/emacs/guix-info.el
+++ b/emacs/guix-info.el
@@ -395,7 +395,7 @@ See `insert-text-button' for the meaning of PROPERTIES.
 (defvar guix-info-mode-map
   (let ((map (make-sparse-keymap)))
 (set-keymap-parent
- map (make-composed-keymap button-buffer-map
+ map (make-composed-keymap (list guix-root-map button-buffer-map)
special-mode-map))
 map)
   Parent keymap for info buffers.)
diff --git a/emacs/guix-list.el b/emacs/guix-list.el
index 26dfeac..e84d60a 100644
--- a/emacs/guix-list.el
+++ b/emacs/guix-list.el
@@ -371,7 +371,9 @@ Same as `tabulated-list-sort', but also restore marks after sorting.
 
 (defvar guix-list-mode-map
   (let ((map (make-sparse-keymap)))
-(set-keymap-parent map tabulated-list-mode-map)
+(set-keymap-parent
+ map (make-composed-keymap guix-root-map
+   tabulated-list-mode-map))
 (define-key map (kbd RET) 'guix-list-describe)
 (define-key map (kbd m)   'guix-list-mark)
 (define-key map (kbd *)   'guix-list-mark)
-- 
2.4.3

Re: [PATCH] Add yaggo.

[Ben Woodcroft]

On 24/06/15 22:19, Thompson, David wrote:

Perhaps ruby should
be a propagated input for packages with ruby executables, or scripts
could be wrapped in another script that set the correct environment
variables.
A naive question - I don't believe that this is required for e.g. python 
packages that have executables and the somewhat analogous PYTHONPATH. 
Why is Ruby different?


Thanks,
ben

Re: [PATCH] gnu: gstreamer: Add search path specification for 'GST_PLUGIN_SYSTEM_PATH'.

[宋文武]

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

 宋文武 iyzs...@gmail.com skribis:

 This reverts commit e53fc0c8a, which add it wrongly to gst-plugins-base.

 * gnu/packages/gstreamer.scm (gstreamer)[native-search-paths]: New field.
   (gst-plugins-base)[native-search-paths]: Remove.

 LGTM!

 I wonder, why is there the word “SYSTEM” in this variable name?  Does
 that means there also exists GST_PLUGIN_PATH?
Yes, you're right.  It has:

  GST_PLUGIN_SYSTEM_PATH, GST_PLUGIN_SYSTEM_PATH_1_0
  GST_PLUGIN_PATH, GST_PLUGIN_PATH_1_0

I think any one is sufficent.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html

[PATCH] gnu: gstreamer: Add search path specification for 'GST_PLUGIN_SYSTEM_PATH'.

[宋文武]

This reverts commit e53fc0c8a, which add it wrongly to gst-plugins-base.

* gnu/packages/gstreamer.scm (gstreamer)[native-search-paths]: New field.
  (gst-plugins-base)[native-search-paths]: Remove.
---
 gnu/packages/gstreamer.scm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
index 24dc41b..1832909 100644
--- a/gnu/packages/gstreamer.scm
+++ b/gnu/packages/gstreamer.scm
@@ -109,6 +109,10 @@ arrays of data.)
(perl ,perl)
(pkg-config ,pkg-config)
(python-wrapper ,python-wrapper)))
+(native-search-paths
+ (list (search-path-specification
+(variable GST_PLUGIN_SYSTEM_PATH)
+(files '(lib/gstreamer-1.0)
 (home-page http://gstreamer.freedesktop.org/;)
 (synopsis Multimedia library)
 (description
@@ -171,10 +175,6 @@ This package provides the core library and elements.)
   ;; for g-ir-scanner.
   (setenv CC gcc))
 %standard-phases)))
-(native-search-paths
- (list (search-path-specification
-(variable GST_PLUGIN_SYSTEM_PATH)
-(files '(lib/gstreamer-1.0)
 (home-page http://gstreamer.freedesktop.org/;)
 (synopsis
  Plugins for the GStreamer multimedia library)
-- 
2.2.1

Re: How to handle required plugins and dbus services for GNOME Programs?

[Mark H Weaver]

宋文武 iyzs...@gmail.com writes:
 Actually, it turns out that 'grilo' doesn't need to be in the profile,
 although if you don't have it you won't get the search path
 recommendation which is crucial for Totem to work properly.
 According to ArchLinux, grilo-plugins is used for media discovery.
 Which is optional. I'm ok to add it though.

Without the grl-bookmarks grilo plugin, attempts to add local video
files to the playlist via the GUI interface silently fail.  See:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768515

I ran into this problem before I packaged 'gom'.  So, although it is
still possible to play local videos by running totem filename, I
would say that Totem malfunctions quite badly even for basic usage
without grilo-plugins.

 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
 need to explicitly install it and I'm not sure what would happen if it
 were removed.
 It's safe to remove 'gstreamer' from inputs.

I don't understand.  Do you mean that it's safe to remove 'gstreamer'
from the inputs of some package?  Which package?

 'dconf' apparently needs to be in the profile for both GNOME Terminal
 and Totem because of the session dbus service(s) it provides.  Without
 it, modern GNOME programs behave quite badly.  They have no way to
 access or change their own configuration settings, e.g. if you go into
 their preferences, you see checkboxes that do not change their state
 when clicked.
 Yes, dconf must in profile to be known to dbus-daemon (user sesssion).
 It's loaded by dbus-daemon when needed.

 https://developer.gnome.org/dconf/unstable/dconf-service.html

 I'm not sure how best to deal with issues like this, and also with
 things like grilo-plugins and gst-plugins-* that are needed for the
 proper functioning of Totem.  Should we make them propagated-inputs?

 Or perhaps they should be normal inputs and we should use a wrapper to
 add those directories as suffixes to GRL_PLUGIN_PATH and
 GST_PLUGIN_SYSTEM_PATH automatically?
 Given that plugins only needed at runtime, how about make a 'raw' totem
 package without wrapper and propagation, and a public one wrap it with
 envs?  Thus avoid the rebuild of the raw totem package if plugins was
 changed.

I'm not sure it would be worth it.  Totem itself doesn't take very long
to build.

 Mark

Re: [PATCH 3/5] build: Add 'emacs-build-system'

[Federico Beffa]

Thanks for the review!

On Tue, Jun 23, 2015 at 1:57 PM, Alex Kost alez...@gmail.com wrote:
 Federico Beffa (2015-06-22 22:33 +0300) wrote:

 On Mon, Jun 22, 2015 at 7:59 PM, Alex Kost alez...@gmail.com wrote:

 Well, these trailing spaces are artifacts of (inaccurate) coding.  Emacs
 can't read user's mind to decide if the spaces are redundant or
 intended.

 No need to read the mind... you just look if there are characters
 other than white spaces (and possibly TABs) between newlines :-)

 But, my question was NOT: how can I see white spaces. Rather: is there
 a Guix coding style rule which states that white spaces there are
 undesired.

 I personally prefer to have them, because then, if I use M-up/down, I
 move to the beginning/end of a whole top-level block, without stopping
 at internal points and that's what I want most of the time.

 So, these spaces are not just coding artifacts, but have some use.

 Ouch, I didn't realize that you left the spaces intentionally, sorry.  I
 always thought that avoiding trailing whitespaces is a general
 convention everywhere.

 But I see your point now, that's a nice trick!

 For lisp/scheme code I use 'beginning-of-defun'/'end-of-defun' commands
 instead of 'backward-paragraph'/'forward-paragraph' (if that's what is
 bound to M-up/down for you).

 --
 Alex
From 725d42eb3e5c44bcec1bd81988d1f952e6be02a4 Mon Sep 17 00:00:00 2001
From: Federico Beffa be...@fbengineering.ch
Date: Sun, 21 Jun 2015 10:10:05 +0200
Subject: [PATCH 3/5] build: Add 'emacs-build-system'.

* Makefile.am (MODULES): Add 'guix/build-system/emacs.scm' and
  'guix/build/emacs-build-system.scm'.
* guix/build-system/emacs.scm: New file.
* guix/build/emacs-build-system.scm: New file.
* doc/guix.texi (Build Systems): Document it.
---
 Makefile.am   |   2 +
 doc/guix.texi |  11 ++
 guix/build-system/emacs.scm   | 141 +
 guix/build/emacs-build-system.scm | 212 ++
 4 files changed, 366 insertions(+)
 create mode 100644 guix/build-system/emacs.scm
 create mode 100644 guix/build/emacs-build-system.scm

diff --git a/Makefile.am b/Makefile.am
index c027fb3..a013b7a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -49,6 +49,7 @@ MODULES =	\
   guix/licenses.scm\
   guix/build-system.scm\
   guix/build-system/cmake.scm			\
+  guix/build-system/emacs.scm			\
   guix/build-system/glib-or-gtk.scm		\
   guix/build-system/gnu.scm			\
   guix/build-system/haskell.scm			\
@@ -67,6 +68,7 @@ MODULES =	\
   guix/ui.scm	\
   guix/build/download.scm			\
   guix/build/cmake-build-system.scm		\
+  guix/build/emacs-build-system.scm		\
   guix/build/git.scm\
   guix/build/glib-or-gtk-build-system.scm	\
   guix/build/gnu-build-system.scm		\
diff --git a/doc/guix.texi b/doc/guix.texi
index f8756ed..777f070 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2404,6 +2404,17 @@ Which Haskell compiler is used can be specified with the @code{#:haskell}
 parameter which defaults to @code{ghc}.
 @end defvr
 
+@defvr {Scheme Variable} emacs-build-system
+This variable is exported by @code{(guix build-system emacs)}.  It
+implements an installation procedure similar to the one of Emacs own
+packaging system.  It first creates the @code{PACKAGE-autoloads.el}
+file, then it byte compiles all Emacs Lisp files.  Differently from the
+Emacs packaging system, the @code{info} documentation files are moved to
+the standard documentation directory and the @code{dir} file is deleted.
+Each package is installed in its own directory under
+@code{share/emacs/site-lisp/guix.d}.
+@end defvr
+
 Lastly, for packages that do not need anything as sophisticated, a
 ``trivial'' build system is provided.  It is trivial in the sense that
 it provides basically no support: it does not pull any implicit inputs,
diff --git a/guix/build-system/emacs.scm b/guix/build-system/emacs.scm
new file mode 100644
index 000..03c1eb2
--- /dev/null
+++ b/guix/build-system/emacs.scm
@@ -0,0 +1,141 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2015 Federico Beffa be...@fbengineering.ch
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see http://www.gnu.org/licenses/.
+
+(define-module (guix build-system emacs)
+  #:use-module (guix store)
+  #:use-module (guix utils)
+  #:use-module (guix packages)
+  #:use-module 

Re: [PATCH 2/5] build: emacs-utils: Add 'emacs-byte-compile-directory'

[Federico Beffa]

Thanks.

On Sun, Jun 21, 2015 at 10:40 PM, Alex Kost alez...@gmail.com wrote:
 Federico Beffa (2015-06-21 11:29 +0300) wrote:

 [...]
 +(define* (emacs-byte-compile-directory dir #:optional (dependency-dirs '()))
 +  Byte compile all files in DIR and its sub-directories.  Before compiling
 +the files, add DIR and all directories in DEPENDENCY-DIRS to 'load-path'.
 +  (let ((expr `(progn
 +(add-to-list 'load-path ,dir)
 +(unless (null ,(if (null? dependency-dirs)
 +   'nil
 +   dependency-dirs))
 +  (setq load-path (append load-path ,dependency-dirs)))
 +(byte-recompile-directory (file-name-as-directory ,dir) 
 0
 +(emacs-batch-eval expr)))
 +
  (define-syntax emacs-substitute-sexps
(syntax-rules ()
  Substitute the S-expression immediately following the first occurrence 
 of

 Shouldn't there be problems with unquoted 'dependency-dirs' list?  IIUC
 the following:

   (emacs-byte-compile-directory /tmp/foo '(one two))

 will produce the following elisp expression:

 (progn
   (add-to-list (quote load-path) /tmp/foo)
   (unless (null (one two))
 (setq load-path (append load-path (one two
   (byte-recompile-directory (file-name-as-directory /tmp/foo) 0))

 but that will raise an error ‘(invalid-function one)’.  Or did I miss
 anything?

 Also I believe dependency-dirs should have a preference over other
 'load-path' directories.

 So what about the following variant:



 --
 Alex

From ec5fbc02e09359bf64b69efed314471e5f409fa4 Mon Sep 17 00:00:00 2001
From: Federico Beffa be...@fbengineering.ch
Date: Tue, 16 Jun 2015 21:09:57 +0200
Subject: [PATCH 2/5] build: emacs-utils: Add 'emacs-byte-compile-directory'.

* guix/build/emacs-utils.scm (emacs-byte-compile-directory): New procedure.
---
 guix/build/emacs-utils.scm | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/guix/build/emacs-utils.scm b/guix/build/emacs-utils.scm
index 0cff28b..fd06aad 100644
--- a/guix/build/emacs-utils.scm
+++ b/guix/build/emacs-utils.scm
@@ -22,6 +22,7 @@
 emacs-batch-eval
 emacs-batch-edit-file
 emacs-generate-autoloads
+emacs-byte-compile-directory
 emacs-substitute-sexps
 emacs-substitute-variables))
 
@@ -57,6 +58,16 @@
   (update-directory-autoloads ,directory
 (emacs-batch-eval expr)))
 
+(define* (emacs-byte-compile-directory dir #:optional (dependency-dirs '()))
+  Byte compile all files in DIR and its sub-directories.  Before compiling
+the files, add DIR and all directories in DEPENDENCY-DIRS to 'load-path'.
+  (let ((expr `(progn
+(add-to-list 'load-path ,dir)
+(when ',dependency-dirs
+  (setq load-path (append ',dependency-dirs load-path)))
+(byte-recompile-directory (file-name-as-directory ,dir) 0
+(emacs-batch-eval expr)))
+
 (define-syntax emacs-substitute-sexps
   (syntax-rules ()
 Substitute the S-expression immediately following the first occurrence of
-- 
2.2.1

Re: [PATCH 1/5] import: Add 'elpa' importer

[Federico Beffa]

Thanks.

On Sun, Jun 21, 2015 at 10:39 PM, Alex Kost alez...@gmail.com wrote:
 Hi, I've tried this elpa importer and it is great!!

 I don't have real comments on code, just some nitpicks.

 Federico Beffa (2015-06-21 11:28 +0300) wrote:

 From 8796b32a1ff8d565c3eb9874cde6a4a14d0b4f3b Mon Sep 17 00:00:00 2001
 From: Federico Beffa be...@fbengineering.ch
 Date: Tue, 16 Jun 2015 10:50:06 +0200
 Subject: [PATCH 1/5] import: Add 'elpa' importer.

 * guix/import/elpa.scm: New file.
 * guix/scripts/import.scm: Add elpa to 'importers'.
 * guix/scripts/import/elpa.scm: New file.
 * Makefile.am (MODULES): Add 'guix/import/elpa.scm' and
   'guix/scripts/import/elpa.scm'. (SCM_TESTS): Add 'tests/elpa.scm'.

 AFAIK the convention is to put (...): ... on a separate line:

   * Makefile.am (MODULES): Add 'guix/import/elpa.scm' and
 'guix/scripts/import/elpa.scm'.
 (SCM_TESTS): Add 'tests/elpa.scm'.

 [...]
 diff --git a/doc/guix.texi b/doc/guix.texi
 index 46dccb8..3ca105a 100644
 --- a/doc/guix.texi
 +++ b/doc/guix.texi
 @@ -3770,6 +3770,33 @@ package name by a hyphen and a version number as in 
 the following example:
  @example
  guix import hackage mtl-2.1.3.1
  @end example
 +
 +@item elpa
 +@cindex elpa
 +Import meta-data from an Emacs ELPA package repository.
 +
 +Specific command-line options are:
 +
 +@table @code
 +@item --archive=@var{repo}
 +@itemx -a @var{repo}
 +@var{repo} identifies the archive repository to from which to retrive

 Redundant to (before from)?  And a typo in retrieve.

 [...]
 +(define* (elpa-package-sexp pkg)

 There are some trailing spaces in this procedure:

 +  Return the `package' S-expression for the Emacs package PKG, a record of
 +type 'elpa-package'.
 +
 here^

 +  (define name (elpa-package-name pkg))
 +
 here^

 +  (define version (elpa-package-version pkg))
 +
 here^

 +  (define source-url (elpa-package-source-url pkg))
 +
 here^

 +  (define dependencies
 +(let* ((deps (elpa-package-inputs pkg))
 +   (names (filter-dependencies (elpa-dependencies-names deps
 +  (map (lambda (n)
 + (let ((new-n (elpa-name-package-name n)))
 +   (list new-n (list 'unquote (string-symbol new-n)
 +   names)))
 +
 here^

 +  (define (maybe-inputs input-type inputs)
 +(match inputs
 +  (()
 +   '())
 +  ((inputs ...)
 +   (list (list input-type
 +   (list 'quasiquote inputs))
 +
 here^

 [...]
 +;;; Command-line options.
 +;;;
 +
 +(define %default-options
 +  '((repo . gnu)))
 +
 +(define (show-help)
 +  (display (_ Usage: guix import elpa PACKAGE-NAME
 +Import the latest package named PACKAGE-NAME from an ELPA repository.\n))
 +  (display (_ 
 +  -a ARCHIVE, --archive=ARCHIVE  specify the archive repository))

 I think we don't duplicate an option argument (see guix package --help
 for example):

   -a, --archive=ARCHIVE  specify the archive repository

 --
 Alex
From 595befd0fb88ae00d405a727efb55b9fa456e549 Mon Sep 17 00:00:00 2001
From: Federico Beffa be...@fbengineering.ch
Date: Tue, 16 Jun 2015 10:50:06 +0200
Subject: [PATCH 1/5] import: Add 'elpa' importer.

* guix/import/elpa.scm: New file.
* guix/scripts/import.scm: Add elpa to 'importers'.
* guix/scripts/import/elpa.scm: New file.
* Makefile.am (MODULES): Add 'guix/import/elpa.scm' and
  'guix/scripts/import/elpa.scm'.
  (SCM_TESTS): Add 'tests/elpa.scm'.
* doc/guix.texi (Invoking guix import): Document it.
* tests/elpa.scm: New file.
---
 Makefile.am  |   3 +
 doc/guix.texi|  27 ++
 guix/import/elpa.scm | 218 +++
 guix/scripts/import.scm  |   2 +-
 guix/scripts/import/elpa.scm |  97 +++
 tests/elpa.scm   | 109 ++
 6 files changed, 455 insertions(+), 1 deletion(-)
 create mode 100644 guix/import/elpa.scm
 create mode 100644 guix/scripts/import/elpa.scm
 create mode 100644 tests/elpa.scm

diff --git a/Makefile.am b/Makefile.am
index 2b84467..c027fb3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -95,6 +95,7 @@ MODULES =	\
   guix/import/snix.scm\
   guix/import/cabal.scm\
   guix/import/hackage.scm			\
+  guix/import/elpa.scm   			\
   guix/scripts/download.scm			\
   guix/scripts/build.scm			\
   guix/scripts/archive.scm			\
@@ -111,6 +112,7 @@ MODULES =	\
   guix/scripts/import/gnu.scm			\
   guix/scripts/import/nix.scm			\
   guix/scripts/import/hackage.scm		\
+  guix/scripts/import/elpa.scm  		\
   guix/scripts/environment.scm			\
   guix/scripts/publish.scm			\
   guix.scm	\
@@ -182,6 +184,7 @@ SCM_TESTS =	\
   tests/packages.scm\
   tests/snix.scm\
   tests/hackage.scm\
+  tests/elpa.scm\
   tests/store.scm\
   tests/monads.scm\
   tests/gexp.scm\
diff --git a/doc/guix.texi b/doc/guix.texi
index 46dccb8..f8756ed 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -3770,6 +3770,33 @@ package name by a hyphen and a version number as in the following 

Re: How to handle required plugins and dbus services for GNOME Programs?

[David Hashe]

It's worth noting that these same questions appear in the Rhythmbox patch I
submitted earlier this week, so I'll be watching what we decide here for
guidance on how to improve that patch.

Thanks,
David

On Wed, Jun 24, 2015 at 12:58 AM, Mark H Weaver m...@netris.org wrote:

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

  Mark H Weaver m...@netris.org skribis:
 
  A few caveats: in order for totem to work properly, you must have
  several other packages installed in your profile.  I'm not entirely sure
  of the full set needed, but I guess it includes:
 
grilo
grilo-plugins
gstreamer
gst-plugins-base
gst-plugins-good
dconf
 
  You will also need to set the GRL_PLUGIN_PATH and GST_PLUGIN_SYSTEM_PATH
  environment variables as advised by guix package --search-paths.
 
  I can imagine why the plugins package need to be in the profile, but I
  find the others more surprising.  Do you know what happens?  Are Grilo,
  GStreamer, and DConf dlopened, or is it just to get the right search
  path recommendation that they are needed?

 Actually, it turns out that 'grilo' doesn't need to be in the profile,
 although if you don't have it you won't get the search path
 recommendation which is crucial for Totem to work properly.

 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't
 need to explicitly install it and I'm not sure what would happen if it
 were removed.

 'dconf' apparently needs to be in the profile for both GNOME Terminal
 and Totem because of the session dbus service(s) it provides.  Without
 it, modern GNOME programs behave quite badly.  They have no way to
 access or change their own configuration settings, e.g. if you go into
 their preferences, you see checkboxes that do not change their state
 when clicked.

 I'm not sure how best to deal with issues like this, and also with
 things like grilo-plugins and gst-plugins-* that are needed for the
 proper functioning of Totem.  Should we make them propagated-inputs?

 Or perhaps they should be normal inputs and we should use a wrapper to
 add those directories as suffixes to GRL_PLUGIN_PATH and
 GST_PLUGIN_SYSTEM_PATH automatically?

 What do you think?

   Mark

Re: Third party guix repositories could be used for housing guile modules and other things.

[Amirouche Boubekki]

On 2015-06-22 18:27, crocket wrote:

Guile hasn't had an official repository. That's why guile hasn't
accumulated thousands of modules.
Since the official gnu guix repository is mainly for GuixSD, it makes
sense to make another guix repository for guile modules to be used on
multiple linux distributions. I'm not sure if guix works on windows
and Mac OS, too.

If you made it possible to add third party guix repository URLs,
people would add third party repositories later without upfront
coordination with guix developers.


To be honest I could be interested to have another repository with guix
recipes where it's easier to contribute and/or dedicated to guile.

But this will still be only available only to GNU/Linux users.

Also, I'd better stay focus on guix. There is guildhall for guile, take 
it as the official Guile package manager if you


--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: [PATCH] Add yaggo.

[Pjotr Prins]

On Wed, Jun 24, 2015 at 08:32:51AM -0400, Thompson, David wrote:
 I don't know about $GEM_SPEC_CACHE, but $GEM_HOME cannot be a native
 search path that is part of our ruby packages, because native search
 paths are relative to store items, which are immutable.  My feeling is
 that if the user wants to use the 'gem' utility instead of using Guix
 packages, they're going to have to set an environment variable or two
 by themselves.

It is just a convenience. I believe GNU Guix should allow extra
package systems - like those of emacs. So point GEM_HOME to something
that is not immutable.

  which would install directly from rubygems.org (including contained
  dependencies when missing in the existing environment).
 
 Are you saying that it would bundle the dependencies if there were no
 Guix packages for them?

Exactly.

  This would greatly facilitate adding Ruby gems to guix.
 
 I must reiterate my concern about this approach to the wider
 guix-devel audience.  From what I can see, the gem archives hosted on
 rubygems.org are build artifacts and should probably be treated like
 pre-built binaries.  They are not the complete, corresponding source
 code.  Can anyone else weigh in here?  I understand the convenience of
 using rubygems.org, but I really need some evidence that the archives
 hosted there are complete, corresponding source code.

Please see it as a migration path. There are tens of thousands of
useful gems out there with complex dependencies. There is no way we
are going to replace and test those overnight. Same for Python and
Perl modules (and all those other languages with their own module
system). I do favour pure Guix packages, also for gems, so we should
aim for replacing the most important ones over time. 

Making it hard(er) to install gems from GNU Guix for normal users will
only slow down adoption. Allow using rubygems for those gems that are
not (yet) supported by us. When enough Ruby people move to using Guix
for their development we may get rid of rubygems altogether. I would
love that. I already got rid of rvm :)

Nix experimented by converting all gems to Nix packages, that is
another possibility. But I think they proved it is hard and now
defunct (correct me if I am wrong). 

Pj.

Re: [PATCH] import: pypi: Detect inputs.

[Ludovic Courtès]

Cyril Roelandt tipec...@gmail.com skribis:

 WDYT?

Makes sense to me.

The latest version of the patch (posted on Monday 15th) LGTM;
please push.

Thank you!

Ludo’.

(guix cpio)

[Ludovic Courtès]

Hello!

Commit 7a18c3c adds a simple cpio writer (for one of the various
variants of the cpio format) written in Scheme.  It is then used in (gnu
build linux-initrd) as a replacement for GNU cpio when building
initrds.

The advantages are better integration (no fork/pipe), no dependencies,
tight control over the created archives, which allows us to create them
completely deterministically (see eae5b3f.)

Comments welcome!

Ludo’.

Re: Using a shared Guix store (was RE: [Bio-packaging] testing out guix)

[Ludovic Courtès]

Hi,

Cook, Malcolm m...@stowers.org skribis:

  Can anyone elaborate a little on what are the obstacles to having
  `/gnu` mounted read-write network wide?
 
 Yes, the primary problem is that the daemon assumes that it is the only thing
 writing to the store and the localstatedir.  Any modification of profiles and
 the store goes through the daemon.
  If so, might this be mitigated using a variant off of Using the
  Offload Facility
  (http://www.gnu.org/software/guix/manual/guix.html#Daemon-Offload-
 Setu
  p) in which builds would still be offloaded (and thus subject to
  coordination), with the elimination of the need for  Missing
  prerequisites for the build are copied over SSH to the target machine,
  which then proceeds with the build; upon success the output(s) of the
  build are copied back to the initial machine since they would be done
  through the shared file system?
 
 Something like that has been suggested before: if the daemon were to
 accept authenticated connections from the outside rather than to just listen
 on a local socket we could have remote guix clients connecting to the central
 daemon.

 Hmm.  So, for now, I could just teach users to, i.e., `ssh 
 ${USER}@${GUIX_HOST}   /path/to/guix package -r lua -i guile guile-cairo` and 
 contrive for GUIX_HOST to be defined for them.

 Or, wrap it up even further, and contrive for everyone to have the following 
 in their env:

   alias guixpkg='ssh ${USER}@${GUIX_HOST} /path/to/guix package'

 ??

That’s a possibility.

Another one, which I think Ricardo has been investigating lately, would
be to have users manage their profiles via the Web user interface,
guix-web: https://git.dthompson.us/guix-web.git.  (The video
http://audio-video.gnu.org/video/misc/2015-01__GNU_Guix__The_Emacs_of_Distros.webm
has a demo starting at around 23mn.)

 Currently our users are okay with that, probably to a large part because they
 are not yet aware of all the features of Guix.  They are only used to
 management by sysadmins or manual compilation, so they are not
 inconvenienced.
 
 Ultimately, the correct fix is to allow remote guix clients to communicate 
 with
 a central guix daemon.  The daemon does not even need to be aware of
 remote connections if guix clients can transparently connect via SSH and send
 RPCs to the socket.  This is not yet implemented.

 Sounds great.  On the roadmap?

Definitely.  There are details to be sorted out (SSH vs. plain old
socket), but we should discuss it and “get it done.”

Thanks for your feedback,
Ludo’.

Re: [PATCH] guix: scripts: Add --dependencies=PACKAGE commmand

[Ludovic Courtès]

Amirouche Boubekki amirou...@hypermove.net skribis:

 From fca3a1020af9d4abe71ab8ab4e2a52011688f272 Mon Sep 17 00:00:00 2001
 From: amz3 amirou...@hypermove.net
 Date: Sat, 20 Jun 2015 18:23:26 +0200
 Subject: [PATCH] guix: scripts: add --dependencies=PACKAGE command

 exemple usage:

   guix package --dependencies=qsynth | dot -Tpng  qsynth-deps.png

 * guix/scripts/package.scm: add --dependencies command
 * guix/scripts/dependencies.scm: graph datastructure and helpers

Thanks for working on this, this is a useful tool!

Please take some time to read the “Contributing” section of the manual,
and in particular the part about commit logs and coding style.  You’ll
quickly notice several things that need to be adjusted.  ;-)

Here’s a quick review:

 +++ b/guix/scripts/dependencies.scm
 @@ -0,0 +1,312 @@
 +;; FIXME: copyright

Indeed.

 +;; FIXME: Taken from Guile, should be in (srfi srfi-99)
 +;;adapted to make it possible to declare record type like `abc' 
 and keep
 +;;field accessor bracket free. record name *must* have brackets or 
 everything
 +;;is broken
 +;;
 +;; Usage:
 +;;
 +;;   (define-record-type abc field-one field-two)
 +;;   (define zzz (make-abc 1 2))
 +;;   (abc-field-one zzz) ;; = 1
 +;;
 +;; FIXME: maybe this is less useful than the immutable record of (srfi 
 srfi-9 gnu)
 +;;Right I will use `set-field` and `set-fields`
 +(define-syntax define-record-type*

Please don’t add another ‘define-record-type’; the one from SRFI-9 will
be good enough here.

 +;;;
 +;;; Store
 +;;;
 +;;; Memory bound immutable association
 +;;;
 +
 +
 +;; XXX: It's assumed that keys are strings.
 +;;
 +;; This replace scheme assoc, because:
 +;; 1) there is no immutable `assoc-set` in scheme
 +;; 2) `acons` (and friends) can replace `assoc-set` but memory will grow 
 without bound
 +;; 3) `assoc-ref` (and friends) always return `#f` when no values is found

That’s not a sufficient argument: one could just

  (define (assoc-set alist key value)
(alist-cons key value
(alist-delete key alist)))

Regardless, it may be that vhashes would work better here.

 +;;;
 +;;; Graph
 +;;;
 +
 +(define-record-type* graph label nodes edges properties)

[...]

 +(define (graph-get-uid store)
 +  (define CHARS AZERTYUIOPQSDFGHJKLMWXCVBN1029384756)
 +
 +  (define (random-id)
 +(let loop ((count 4)
 +   (id ))
 +  (if (eq? count 0)
 +  id
 +  (loop (1- count) (format #f ~a~a id (string-ref CHARS (random 
 36)))
 +
 +  (let loop ()
 +(let ((id (random-id)))
 +  (if (null? (store-ref store id))
 +  id
 +  (loop)

What about:

  (define (graph-unique-identifier graph)
Return a unique identifier for GRAPH for use in the ‘dot’ output.”
(number-string (object-address graph) 16))

?

 +(if (package? (cadar packages))
 +(let ((dependency (package-name (cadar packages
 +  (let*-values (((graph package-uid) (maybe-create-node graph 
 (package-name package)))
 +((graph dependency-uid) (maybe-create-node graph 
 dependency)))
 +(let* ((label (string-append (package-name (cadar packages)) 
 --(depends)-- dependency))
 +   (graph (maybe-create-edge graph package-uid label 
 dependency-uid))
 +   (graph (package-dependency-graph (cadar packages) 
 graph)))
 +(loop (cdr packages) graph
 +(loop (cdr packages) graph)

car, cdr, cadar etc. are banned.  Please use ‘match’ or some specific
accessor (it may be that a record would be more appropriate here?)

 +(define (graph-dot graph port)

‘graph-dot’

 +   ;; (let-values (((name version)
 +   ;;   (package-name-name+version arg)))
 + 
 +   ;;   ;; (display-dependencies (find-packages-by-name 
 name))
 +   ;;   (values (cons #f result) #f

Leftover.

More importantly, I think this should be in a separate command, or maybe
as an option in ‘guix gc’ since ‘guix gc’ already has --references  co.

WDYT?

I think the graph part should be abstracted so that it can work on (1)
packages, (2) bags, and (3) derivations.  Ideally users would be able to
choose which of these they want to represent, from coarse-grain to
fine-grain.  (That part could be implemented as a later patch, but the
framework has to be prepared for that.)

Also, I’m not completely sure a separate graph representation (node,
edge, and graph) is needed.  Wouldn’t it be sufficient to work
directly on packages objects (or bags or derivations)?

Thanks,
Ludo’.

Re: [PATCHES] Add totem

[Ludovic Courtès]

Mark H Weaver m...@netris.org skribis:

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

 From ba786fa3d1d7896336dca3b364bb630142c30fa1 Mon Sep 17 00:00:00 2001
 From: Mark H Weaver m...@netris.org
 Date: Sat, 20 Jun 2015 21:09:54 -0400
 Subject: [PATCH 2/3] gnu: Add grilo-plugins.

 * gnu/packages/gnome.scm (grilo-plugins): New variable.

 [...]

 + `(#:make-flags (list (string-append GRL_PLUGINS_DIR=
 + %output
 + /lib/grilo-
 + ,(version-major+minor version)))
 +   ;; XXX FIXME: Investigate test failure:
 +   ;;   TEST: test_apple_trailers... (pid=8718)
 +   ;; /apple-trailers/browse/count:
 +   ;;   ERROR:test_apple_trailers.c:88:test_browse_count: assertion 
 failed: (source)
 +   ;;   FAIL
 +   #:tests? #f))

 Would it be OK to skip just this for now?  If that’s too much, we can
 leave it for later.

 make check aborts after this failure, which is the first test.  I
 tried make -k check and found that _all_ tests fail with the same
 assertion failure when run in the build container.

 However, if I run make -k check on the failed build directory in
 /tmp/nix-build-* from outside of the build container, all but one of the
 tests succeeds.  This when using the precise environment variable
 settings from the build and no others.  Using strace, I found that it
 was accessing the system dbus, so I guess that's the problem.

Ah OK.  It’s really a bug in their test framework IMO.  It’s probably OK
to punt on this one and document these findings in the comment.

Thanks,
Ludo’.