[PATCH 2/2] emacs: Add interface for comparing generations.

[Alex Kost]

In short, now (with this patch) after marking 2 generations (by pressing
"m" in a “generation-list” buffer), you can perform diff/ediff on
generation packages or manifests.  Thanks to Ludovic for the idea.

>From 2b98ab3243e5d79f9787442bd1bfdceb76bf72a8 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Sun, 2 Nov 2014 13:58:21 +0300
Subject: [PATCH 2/2] emacs: Add interface for comparing generations.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested by Ludovic Courtès.

* doc/emacs.texi (Emacs List buffer): Document new key bindings.
* emacs/guix-base.el (guix-generation-packages-buffer-name-function): New
  variable.
  (guix-generation-file, guix-manifest-file, guix-generation-packages,
  guix-generation-packages-buffer-name-default,
  guix-generation-packages-buffer-name-long,
  guix-generation-packages-buffer-name, guix-generation-packages-buffer,
  guix-profile-generation-manifest-file,
  guix-profile-generation-packages-buffer): New procedures.
* emacs/guix-list.el: Add key bindings for comparing generations.
  (guix-generation-list-generations-to-compare,
  guix-generation-list-show-added-packages,
  guix-generation-list-show-removed-packages, guix-generation-list-compare,
  guix-generation-list-ediff-manifests, guix-generation-list-diff-manifests,
  guix-generation-list-ediff-packages, guix-generation-list-diff-packages,
  guix-generation-list-ediff, guix-generation-list-diff): New procedures.
* emacs/guix-messages.el (guix-messages): Add 'generation-diff' messages.
* emacs/guix-utils.el (guix-diff-switches): New variable.
  (guix-diff): New procedure.
* emacs/guix-main.scm (package/output-sexps): Handle 'generation-diff' search
  type.
  (manifest-entry->package-specification,
  manifest-entries->package-specifications, generation-package-specifications,
  generation-difference): New procedures.
---
 doc/emacs.texi | 15 +
 emacs/guix-base.el | 72 ++
 emacs/guix-list.el | 85 +-
 emacs/guix-main.scm| 33 ++--
 emacs/guix-messages.el | 18 ++-
 emacs/guix-utils.el| 10 ++
 6 files changed, 229 insertions(+), 4 deletions(-)

diff --git a/doc/emacs.texi b/doc/emacs.texi
index 17440e4..5fd9e61 100644
--- a/doc/emacs.texi
+++ b/doc/emacs.texi
@@ -239,6 +239,21 @@ Mark the current generation for deletion (with prefix, mark all
 generations).
 @item x
 Execute actions on the marked generations---i.e., delete generations.
+@item e
+Run Ediff (@pxref{Top,,, ediff, Ediff}) on package outputs installed in
+the 2 marked generations.  With prefix argument, run Ediff on manifests
+of the marked generations.
+@item D
+@itemx =
+Run Diff (@pxref{Diff Mode,,, emacs, The Emacs Editor}) on package
+outputs installed in the 2 marked generations.  With prefix argument,
+run Diff on manifests of the marked generations.
+@item +
+List package outputs added to the latest marked generation comparing
+with another marked generation.
+@item -
+List package outputs removed from the latest marked generation comparing
+with another marked generation.
 @end table
 
 @node Emacs Info buffer
diff --git a/emacs/guix-base.el b/emacs/guix-base.el
index eb88f37..abbd523 100644
--- a/emacs/guix-base.el
+++ b/emacs/guix-base.el
@@ -650,6 +650,78 @@ This function will not update the information, use
guix-search-type guix-search-vals))
 

+;;; Generations
+
+(defvar guix-generation-packages-buffer-name-function
+  #'guix-generation-packages-buffer-name-default
+  "Function used to define name of a buffer with generation packages.
+This function is called with 2 arguments: PROFILE (string) and
+GENERATION (number).")
+
+(defun guix-generation-file (profile generation)
+  "Return the file name of a PROFILE's GENERATION."
+  (format "%s-%s-link" profile generation))
+
+(defun guix-manifest-file (profile &optional generation)
+  "Return the file name of a PROFILE's manifest.
+If GENERATION number is specified, return manifest file name for
+this generation."
+  (expand-file-name "manifest"
+(if generation
+(guix-generation-file profile generation)
+  profile)))
+
+(defun guix-generation-packages (profile generation)
+  "Return a list of sorted outputs installed in PROFILE's GENERATION."
+  (let ((outputs (guix-eval-read (guix-make-guile-expression
+  'generation-package-specifications
+  profile generation
+(sort outputs #'string<)))
+
+(defun guix-generation-packages-buffer-name-default (profile generation)
+  "Return name of a buffer for displaying GENERATION's package outputs.
+Use base name of PROFILE path."
+  (let ((profile-name (file-name-base (directory-file-name profile
+(format "*Guix %s: generation %s*"
+profile-name generation)))
+
+(defun guix-generation-packages-b

[PATCH 1/2] emacs: Improve minibuffer messages.

[Alex Kost]

I think that moving "message system" from “guix-base.el” to
“guix-messages.el” would be more convenient.  I also made the messages
more verbose (by mentioning a used profile).

>From 6811c72ea7b3135de1bbe4230f5b012edbfd092b Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Sun, 2 Nov 2014 13:50:27 +0300
Subject: [PATCH 1/2] emacs: Improve minibuffer messages.

* emacs/guix-base.el (guix-messages, guix-result-message): Move to
  'guix-messages.el'.
  (guix-set-buffer, guix-history-call, guix-redisplay-buffer): Adjust for
  the modified 'guix-result-message'.
* emacs/guix-messages.el: New file.
  (guix-messages): Add 'profile' argument.
---
 emacs/guix-base.el | 113 +++-
 emacs/guix-messages.el | 154 +
 2 files changed, 161 insertions(+), 106 deletions(-)
 create mode 100644 emacs/guix-messages.el

diff --git a/emacs/guix-base.el b/emacs/guix-base.el
index 9583d49..eb88f37 100644
--- a/emacs/guix-base.el
+++ b/emacs/guix-base.el
@@ -30,6 +30,8 @@
 (require 'cl-lib)
 (require 'guix-backend)
 (require 'guix-utils)
+(require 'guix-history)
+(require 'guix-messages)
 

 ;;; Profiles
@@ -565,7 +567,8 @@ If NO-DISPLAY is non-nil, do not switch to the buffer."
  (guix-make-history-item)))
   (or no-display
   (guix-switch-to-buffer buf
-  (guix-result-message entries entry-type search-type search-vals))
+  (guix-result-message profile entries entry-type
+   search-type search-vals))
 
 (defun guix-show-entries (entries buffer-type entry-type)
   "Display ENTRY-TYPE ENTRIES in the current BUFFER-TYPE buffer."
@@ -583,7 +586,8 @@ If NO-DISPLAY is non-nil, do not switch to the buffer."
   (guix-show-entries entries buffer-type entry-type)
   (guix-set-vars profile entries buffer-type entry-type
  search-type search-vals)
-  (guix-result-message entries entry-type search-type search-vals))
+  (guix-result-message profile entries entry-type
+   search-type search-vals))
 
 (defun guix-make-history-item ()
   "Make and return a history item for the current buffer."
@@ -642,113 +646,10 @@ This function will not update the information, use
 \"\\[revert-buffer]\" if you want the full update."
   (interactive)
   (guix-show-entries guix-entries guix-buffer-type guix-entry-type)
-  (guix-result-message guix-entries guix-entry-type
+  (guix-result-message guix-profile guix-entries guix-entry-type
guix-search-type guix-search-vals))
 

-;;; Messages
-
-(defvar guix-messages
-  '((package
- (id
-  (0 "Packages not found.")
-  (1 "")
-  (many "%d packages." count))
- (name
-  (0 "The package '%s' not found." val)
-  (1 "A single package with name '%s'." val)
-  (many "%d packages with '%s' name." count val))
- (regexp
-  (0 "No packages matching '%s'." val)
-  (1 "A single package matching '%s'." val)
-  (many "%d packages matching '%s'." count val))
- (all-available
-  (0 "No packages are available for some reason.")
-  (1 "A single available package (that's strange).")
-  (many "%d available packages." count))
- (newest-available
-  (0 "No packages are available for some reason.")
-  (1 "A single newest available package (that's strange).")
-  (many "%d newest available packages." count))
- (installed
-  (0 "No installed packages.")
-  (1 "A single package installed.")
-  (many "%d packages installed." count))
- (obsolete
-  (0 "No obsolete packages.")
-  (1 "A single obsolete package.")
-  (many "%d obsolete packages." count))
- (generation
-  (0 "No packages installed in generation %d." val)
-  (1 "A single package installed in generation %d." val)
-  (many "%d packages installed in generation %d." count val)))
-(output
- (id
-  (0 "Package outputs not found.")
-  (1 "")
-  (many "%d package outputs." count))
- (name
-  (0 "The package output '%s' not found." val)
-  (1 "A single package output with name '%s'." val)
-  (many "%d package outputs with '%s' name." count val))
- (regexp
-  (0 "No package outputs matching '%s'." val)
-  (1 "A single package output matching '%s'." val)
-  (many "%d package outputs matching '%s'." count val))
- (all-available
-  (0 "No package outputs are available for some reason.")
-  (1 "A single available package output (that's strange).")
-  (many "%d available package outputs." count))
- (newest-available
-  (0 "No package outputs are available for some reason.")
-  (1 "A single newest available package output (that's strange).")
-  (many "%d newest available package outputs." count))
- (installed
-  (0 "No installed package outputs.")
-  (1 "A single package output installed.")
-  (many "%d package outputs installed." count))
- (obsolete
-  (0 "No obsolete package output

BUG in librsvg-2.40.2

[Federico Beffa]

librsvg provides a cache file for gdk-pixbuf modules:

/gnu/store/...librsvg-2.40.2/lib/gdk-pixbuf-2.0/2.0.10/loaders.cache

However, the cache does not include the SVG module created by librsvg
itself.  The full cache should be generated with:

/gnu/store/...-gdk-pixbuf-2.28.2/bin/gdk-pixbuf-query-loaders \
/gnu/store/...-librsvg-2.40.2/lib/gdk-pixbuf-2.0/2.0.10/loaders/libpixbufloader-svg.so
\
/gnu/store/...-gdk-pixbuf-2.28.2/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-*.so

Regards,
Fede

Re: Patch-shebangs phase and created binaries

[Ludovic Courtès]

Andreas Enge  skribis:

> should the final patch-shebangs phase not include the generated output
> path (well, the bin subdirectory) in its $PATH?

It already does.

> In texlive I see lines such as
> patch-shebang: ./texmf-dist/tex/luatex/lualibs/lualibs-compat.lua: warning: 
> no binary for interpreter `texlua' found in $PATH

(And the mention of $PATH in this message is misleading.)

> The file starts with 
> #!/usr/bin/env texlua
> and texlua is a binary created in the texlive output (actually, bin/texlua is
> a symbolic link to the elf binary bin/luatex).

Could it be that the symlink doesn’t exist yet at the time the
‘patch-shebangs’ phase runs?

HTH,
Ludo’.

[sr #108678] Creating extra repository guix/artwork.git

[Ludovic Courtès]

Follow-up Comment #2, sr #108678 (project administration):

Hi Assaf,

Thank you for the quick action!

guix/artwork.git (rather than guix/guix-artwork.git) would have been enough,
but perhaps it's too late/inconvenient to rename?

Thanks,
Ludo'.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[PATCH 0/2] gnu: Add sdl-union and guile-sdl

[David Thompson]

Hello all,

The following patch set adds two new packages:

1) sdl-union: A union-build of SDL and it's utility libraries
2) guile-sdl: A Guile wrapper for SDL

Neither of these patches are ready for upstream.  I'm posting them now
because I need some help to fix the remaining issues.

Regarding sdl-union:

* This package isn't useful for users, only developers.  Should I keep it
private so that it doesn't show up in package searches?

* I wasn't sure how to fill out the metadata fields.  Thoughts on what
  they should be?

Regarding guile-sdl:

* This package doesn't build.  However, if I build with --keep-failed
and run `make clean && make` in /tmp/nix-.../guile-sdl-0.5.1, the build
is successful.  Does anyone have any thoughts about why this might be?
I really need some help here.

The motivation for these patches (and my previous freeimage) patch, are
to finish up packaging all of the dependencies for Sly, my game engine.

Thanks in advance for the help/feedback!

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

[PATCH 1/2] gnu: Add sdl-union.

[David Thompson]

>From db0ee9ba8666d1f5b2cd080f837fdae3e1ee329b Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sun, 2 Nov 2014 11:54:20 -0500
Subject: [PATCH 1/2] gnu: Add sdl-union.

* gnu/packages/sdl.scm (sdl-union): New variable.
---
 gnu/packages/sdl.scm | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/gnu/packages/sdl.scm b/gnu/packages/sdl.scm
index b9b5262..fc374c0 100644
--- a/gnu/packages/sdl.scm
+++ b/gnu/packages/sdl.scm
@@ -22,6 +22,7 @@
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system trivial)
   #:use-module ((gnu packages fontutils) #:prefix font:)
   #:use-module (gnu packages image)
   #:use-module (gnu packages linux)
@@ -240,3 +241,28 @@ SDL.")
 (description "SDL_ttf is a TrueType font rendering library for SDL.")
 (home-page "www.libsdl.org/projects/SDL_ttf/")
 (license zlib)))
+
+(define-public sdl-union
+  (package
+(name "sdl-union")
+(version (package-version sdl))
+(source #f)
+(build-system trivial-build-system)
+(arguments
+ '(#:modules ((guix build union))
+   #:builder (begin
+   (use-modules (ice-9 match)
+(guix build union))
+   (match %build-inputs
+ (((names . directories) ...)
+  (union-build (assoc-ref %outputs "out")
+   directories))
+(inputs `(("sdl" ,sdl)
+  ("sdl-gfx" ,sdl-gfx)
+  ("sdl-image" ,sdl-image)
+  ("sdl-mixer" ,sdl-mixer)
+  ("sdl-ttf" ,sdl-ttf)))
+(synopsis "Union of all SDL libraries.")
+(description "Union of all SDL libraries.")
+(home-page (package-home-page sdl))
+(license (package-license sdl
-- 
2.1.1

[PATCH 2/2] gnu: Add guile-sdl.

[David Thompson]

>From bde00797a13304f69e61b1cd87033b75a6174bba Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sun, 2 Nov 2014 11:55:21 -0500
Subject: [PATCH 2/2] gnu: Add guile-sdl.

* gnu/packages/sdl.scm (guile-sdl): New variable.
---
 gnu/packages/sdl.scm | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/gnu/packages/sdl.scm b/gnu/packages/sdl.scm
index fc374c0..8f78b90 100644
--- a/gnu/packages/sdl.scm
+++ b/gnu/packages/sdl.scm
@@ -24,6 +24,7 @@
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system trivial)
   #:use-module ((gnu packages fontutils) #:prefix font:)
+  #:use-module (gnu packages guile)
   #:use-module (gnu packages image)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages mp3)
@@ -266,3 +267,37 @@ SDL.")
 (description "Union of all SDL libraries.")
 (home-page (package-home-page sdl))
 (license (package-license sdl
+
+(define-public guile-sdl
+  (package
+(name "guile-sdl")
+(version "0.5.1")
+(source (origin
+  (method url-fetch)
+  (uri
+   (string-append "mirror://gnu/guile-sdl/guile-sdl-"
+  version ".tar.xz"))
+  (sha256
+   (base32
+"126n4rd0ydh6i2s11ari5k85iivradlf12zq13b34shf9k1wn5am"
+(build-system gnu-build-system)
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(inputs
+ `(("guile" ,guile-2.0)
+   ("sdl-union" ,sdl-union)))
+(arguments
+ '(#:configure-flags
+   (list (string-append "--with-sdl-prefix="
+(assoc-ref %build-inputs "sdl-union")))
+   #:phases
+   (alist-cons-before
+'configure 'disable-guile-auto-compile
+(lambda _
+  (setenv "GUILE_AUTO_COMPILE" "0"))
+%standard-phases)))
+(synopsis "SDL bindings for GNU Guile.")
+(description "Guile-SDL is a set of modules that provide bindings for SDL
+to enable Guile programmers to do all the nice things you can do with SDL.")
+(home-page "http://gnu.org/s/guile-sdl";)
+(license gpl3+)))
-- 
2.1.1

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge  skribis:

> On Fri, Oct 31, 2014 at 10:30:24PM +0100, Ludovic Courtès wrote:
>> Furthermore, unlike software packages, what matters here is the actual
>> name of the font or font collection, not the “system name” or “tarball
>> name.”
>> Here’s a possible answer to the above questions, informally:
>>   • Use ‘font-FOUNDRY-FAMILY’ or ‘font-FAMILY’ or
>> ‘font-FOUNDRY-COLLECTION’ or ‘font-COLLECTION’ as the name.
>> Examples: ‘font-bitstream-vera’, ‘font-liberation’, ‘font-unifont’.
>>   • Use ‘font-.*-FORMAT’ only when there happens to be separate packages
>> for separate formats.  FORMAT would be the format short name, like
>> ‘ttf’, ‘otf’, ‘type1’.
>> WDYT, fellow nitpickers?  :-)
>
> This sounds like quite an interesting solution - so we would completely drop
> the upstream package name and only go for the font name (which would normally
> be some part of the upstream package name, I suppose).
>
> What would be the role of FOUNDRY? Should we try to find it out for most
> fonts, or would it only be there to avoid confusions for fonts such as
> Garamond?

Some fonts are created by hobbyists rather than a foundry.

Some of the fonts created by foundries are often referred to it using
the foundry’s name, such as “Bitstream Vera”; there are also
counter-examples, like Gentium, Charis, etc. (by SIL.)

So, again very informally, I would suggest to use the foundry name in
cases where people expect to see it, and in cases where it removes
ambiguity with similarly-named fonts.

What do people think?

>> IMO the goal should be to find something convenient for users.
>> Sometimes, maybe, there will be several valid choices for the package
>> name, but that’s fine, I think.
>
> Maybe we could refine the rules once an ambiguity occurs and see if we can
> lift it.

Sure.

> One suggestion: I would like to keep the names of the x.org fonts as they
> are, following the software package guidelines. I think they are more software
> than fonts that actual users would employ to typeset their documents.

Yes, I agree.

Thanks,
Ludo’.

[PATCH 1/2] gnu: librsvg: Generate complete loaders.cache including support for SVG.

[Federico Beffa]

As mentioned in a previous email, the cache generated by default does
not include support for SVG provided by librsvg itself.  With this
patch we generate a full cache file.

Regards,
Fede
From 36c6d59180bdb2d80e169938097efca39431c122 Mon Sep 17 00:00:00 2001
From: Federico Beffa 
Date: Sun, 2 Nov 2014 18:01:08 +0100
Subject: [PATCH 1/2] gnu: librsvg: Generate complete loaders.cache including
 support for SVG.

* gnu/packages/gnome.scm (librsvg): Add 'generate-full-chage phase.
---
 gnu/packages/gnome.scm | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index f1f1918..22b73f9 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -594,7 +594,10 @@ dealing with different structured file formats.")
 "071959yjb2i1bja7ciy4bmpnd6fn2is9jjqsvvvnsqwl69j9n128"
 (build-system gnu-build-system)
 (arguments
- `(#:phases
+ `(#:modules ((srfi srfi-1)
+  (guix build gnu-build-system)
+  (guix build utils))
+   #:phases
(alist-cons-before
 'configure 'augment-gir-search-path
 (lambda* (#:key inputs #:allow-other-keys)
@@ -608,7 +611,22 @@ dealing with different structured file formats.")
 ;; Likewise, create a separate 'loaders.cache' file.
 (("gdk_pixbuf_cache_file = .*$")
  "gdk_pixbuf_cache_file = $(gdk_pixbuf_moduledir).cache\n")))
-%standard-phases)))
+   (alist-cons-after
+'install 'generate-full-cache
+(lambda* (#:key inputs outputs #:allow-other-keys)
+  (let ((loaders-directory 
+ (string-append (assoc-ref outputs "out")
+"/lib/gdk-pixbuf-2.0/2.0.10/loaders")))
+(zero?
+ (system 
+  (string-append 
+   "gdk-pixbuf-query-loaders " 
+   loaders-directory "/libpixbufloader-svg.so "
+   (fold (lambda (s p) (string-append s " " p))  "" 
+ (find-files (assoc-ref inputs "gdk-pixbuf") 
+ "libpixbufloader-.*\\.so"))
+   "> " loaders-directory ".cache")
+%standard-phases
 (native-inputs
  `(("pkg-config" ,pkg-config)
("glib" ,glib "bin")   ; glib-mkenums, etc.
-- 
1.8.4

[PATCH 2/2] gnu: Add gnome-themes-standard.

[Federico Beffa]

Package for GNOME 3 default theme.

Regards,
Fede
From 7439f19c1f2966466da88554478b796c3bfca429 Mon Sep 17 00:00:00 2001
From: Federico Beffa 
Date: Sun, 2 Nov 2014 18:09:33 +0100
Subject: [PATCH 2/2] gnu: Add gnome-themes-standard.

* gnu/packages/gnome.scm (gnome-themes-standard): New variable.
---
 gnu/packages/gnome.scm | 44 
 1 file changed, 44 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 22b73f9..d8a4fe0 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -1219,3 +1219,47 @@ engineering.")
 (license
 ;; Dual licensed under GPLv2 or GPLv3 (both without "or later")
  (list license:gpl2 license:gpl3
+
+;; The version of this package should be the same as the version of
+;; gnome-desktop.
+(define-public gnome-themes-standard
+  (package
+(name "gnome-themes-standard")
+(version "3.10.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "mirror://gnome/sources/" name "/" 
+   (string-take version 4) "/" name "-"
+   version ".tar.xz"))
+   (sha256
+(base32
+ "0f2b3ypkfvrdsxcvp14ja9wqj382f1p46yrjvhhxkkjgagy6qb41"
+(build-system gnu-build-system)
+(inputs
+ `(("gtk+" ,gtk+)
+   ("gtk+-2" ,gtk+-2)
+   ("librsvg" ,librsvg)
+   ("libxml2" ,libxml2)
+   ("glib" ,glib)))
+(native-inputs
+ `(("intltool" ,intltool)
+   ("glib:bin" ,glib "bin")
+   ("pkg-config" ,pkg-config)))
+(arguments
+ `(#:phases
+   (alist-cons-before
+'build 'use-full-cache
+;; Use librsvg's loaders.cache instead of the one provided by
+;; gdk-pixbuf because the latter does not include support for SVG
+;; files.
+(lambda* (#:key inputs #:allow-other-keys)
+  (setenv "GDK_PIXBUF_MODULE_FILE" 
+  (car (find-files (assoc-ref inputs "librsvg") 
+   "loaders\\.cache"
+%standard-phases)))
+(home-page "https://launchpad.net/gnome-themes-standard";)
+(synopsis "Default GNOME 3 themes")
+(description
+ "The default GNOME 3 themes (Adwaita and some accessibility themes).")
+(license license:lgpl2.1+)))
-- 
1.8.4

Re: Different versions of a package in the same profile?

[Ludovic Courtès]

Andreas Enge  skribis:

> On Fri, Oct 31, 2014 at 12:07:14AM +0100, Ludovic Courtès wrote:
>> Technically it would be easy to allow the installation of different
>> versions of a package in the same profile, but I wonder about the
>> implications.
>> 
>> For instance, ‘-u foo’ would upgrade all the installed versions of
>> ‘foo’, so you would end up with exactly the same version twice.
>
> Good catch (or rather "bad feature"?).
>
> So should we indeed rename version 2 of the python package to python2, to
> allow easy installation together with python version 3?
>
> We could do the same for Qt, but if anyway versions 4 and 5 are not
> installable together, there does not seem to be a need.

I don’t think so.  In this thread, I rather wanted to discuss the
implications of allowing same-named packages to be installed in the same
profile, should we decide to go that route.

> In any case, the outcome of installation should not depend on whether we
> do them in one or in several commands.

Agreed.

> Another idea: How about letting "guix package -u foo" upgrade only the
> package with name foo and the latest version if there are several with the
> same name?

That’s a possibility, yes.

But I wonder if there are other issues beyond -u.

Ludo’.

Re: [PATCH] emacs: Add a name/version/synopsis heading in package-info buffers

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-31 02:20 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> OK, I'm attaching a patch.  Is “Co-authored-by …” enough or should you
>>> be credited in some other way?
>>
>> It’s enough.
>>
 I’m thinking perhaps we should do something similar for the description
 itself, like display it right below the synopsis.  Thoughts?
>>>
>>> I think a simple heading may consist of just "name version" and other
>>> parameters may be specified by a user.  For this purpose I added
>>> ‘guix-package-info-heading-params’ variable.  Do you think a description
>>> should also be displayed in the heading by default?
>>
>> Yes, I like it this way.

I meant: I tried this patch, and I like what it does.

>> Thanks!
>
> Sorry, I didn't get it: may I commit that patch?

Yes please!  :-)

Thanks,
Ludo’.

Re: [PATCH] gnu: Add freeimage.

[Ludovic Courtès]

David Thompson  skribis:

> Andreas Enge  writes:

[...]

>>> +'unpack
>>> +(lambda* (#:key source #:allow-other-keys)
>>> +  (and (zero? (system* "unzip" source))
>>> +   (chdir "FreeImage")))
>>
>> I wonder if this should not be moved to the standard unpack phase. Can we
>> determine the file format and use the appropriate tool, unzip or tar,
>> automatically? (Assuming that there are no .tar.zip out there, of
>> course.)
>
> I've been thinking about this, too.  I don't think I would like the GNU
> build system to depend on unzip since very few packages require it and
> it's not a format that GNU uses, but maybe a procedure that replaced the
> standard unpack phase with one that uses unzip would be nice.  I think
> that work could/should be saved for a future patch.

I think we could change ‘unpack’ in gnu-build-system.scm to invoke unzip
when the file name ends in .zip, while letting it the user’s
responsibility to add unzip as an input when needed (as is already the
case for lzip.)

But yes, this would be for core-updates.

> From 2972e6e41d7c13dd619f0dd7fbda7b2a4ec0c6cc Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Wed, 25 Jun 2014 19:50:30 -0400
> Subject: [PATCH] gnu: Add freeimage.
>
> * gnu/packages/image.scm (freeimage): New variable.

LGTM, OK to push!

Ludo’.

[PATCH] gnu: Add docbook-xml-4.2

[Federico Beffa]

Add version 4.2.  It is needed by dconf.

Regards,
Fede
From 9d2aebbaa396c2143666f171833d79efeefa4746 Mon Sep 17 00:00:00 2001
From: Federico Beffa 
Date: Sun, 2 Nov 2014 18:23:32 +0100
Subject: [PATCH] gnu: Add docbook-xml-4.2

* gnu/packages/docbook.scm (docbook-xml-4.2): New variable.
---
 gnu/packages/docbook.scm | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gnu/packages/docbook.scm b/gnu/packages/docbook.scm
index dc2e3da..3ec0377 100644
--- a/gnu/packages/docbook.scm
+++ b/gnu/packages/docbook.scm
@@ -94,6 +94,17 @@ by no means limited to these applications.)  This package provides XML DTDs.")
(base32
 "0r1l2if1z4wm2v664sqdizm4gak6db1kx9y50jq89m3gxaa8l1i3"))
 
+(define-public docbook-xml-4.2
+  (package (inherit docbook-xml)
+   (version "4.2")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://www.docbook.org/xml/"; version
+  "/docbook-xml-" version ".zip"))
+  (sha256
+   (base32
+"18hgwvmywh6a5jh38szjmg3hg2r4v5lb6r3ydc3rd8cp9wg61i5c"))
+
 (define-public docbook-xsl
   (package
 (name "docbook-xsl")
-- 
1.8.4

Re: [PATCH 1/2] emacs: Improve minibuffer messages.

[Ludovic Courtès]

Alex Kost  skribis:

> I think that moving "message system" from “guix-base.el” to
> “guix-messages.el” would be more convenient.  I also made the messages
> more verbose (by mentioning a used profile).
>
>
> From 6811c72ea7b3135de1bbe4230f5b012edbfd092b Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sun, 2 Nov 2014 13:50:27 +0300
> Subject: [PATCH 1/2] emacs: Improve minibuffer messages.
>
> * emacs/guix-base.el (guix-messages, guix-result-message): Move to
>   'guix-messages.el'.
>   (guix-set-buffer, guix-history-call, guix-redisplay-buffer): Adjust for
>   the modified 'guix-result-message'.
> * emacs/guix-messages.el: New file.
>   (guix-messages): Add 'profile' argument.

LGTM!

Ludo'.

Re: [PATCH] gnu: Add docbook-xml-4.2

[Andreas Enge]

On Sun, Nov 02, 2014 at 06:26:59PM +0100, Federico Beffa wrote:
> Add version 4.2.  It is needed by dconf.

This looks very safe (although we will end up with four versions of it!).

Andreas

Re: [PATCH] gnu: Add freeimage.

[David Thompson]

Ludovic Courtès  writes:

> David Thompson  skribis:
>
>> Andreas Enge  writes:
>
> [...]
>
 +'unpack
 +(lambda* (#:key source #:allow-other-keys)
 +  (and (zero? (system* "unzip" source))
 +   (chdir "FreeImage")))
>>>
>>> I wonder if this should not be moved to the standard unpack phase. Can we
>>> determine the file format and use the appropriate tool, unzip or tar,
>>> automatically? (Assuming that there are no .tar.zip out there, of
>>> course.)
>>
>> I've been thinking about this, too.  I don't think I would like the GNU
>> build system to depend on unzip since very few packages require it and
>> it's not a format that GNU uses, but maybe a procedure that replaced the
>> standard unpack phase with one that uses unzip would be nice.  I think
>> that work could/should be saved for a future patch.
>
> I think we could change ‘unpack’ in gnu-build-system.scm to invoke unzip
> when the file name ends in .zip, while letting it the user’s
> responsibility to add unzip as an input when needed (as is already the
> case for lzip.)
>
> But yes, this would be for core-updates.

Okay, that does sound like a good idea.

>> From 2972e6e41d7c13dd619f0dd7fbda7b2a4ec0c6cc Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Wed, 25 Jun 2014 19:50:30 -0400
>> Subject: [PATCH] gnu: Add freeimage.
>>
>> * gnu/packages/image.scm (freeimage): New variable.
>
> LGTM, OK to push!

Pushed.  Thanks!

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: Different versions of a package in the same profile?

[Andreas Enge]

On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
> I don’t think so.  In this thread, I rather wanted to discuss the
> implications of allowing same-named packages to be installed in the same
> profile, should we decide to go that route.
> 
> > Another idea: How about letting "guix package -u foo" upgrade only the
> > package with name foo and the latest version if there are several with the
> > same name?
> That’s a possibility, yes.
> But I wonder if there are other issues beyond -u.

Good question, I do not know. But if we allow several packages with the same
name in a profile, I do not see another possibility for "guix package -u"
than my suggestion.

There is also the question of conflicts with identical file names. They are
already there now, but their probability should be higher with identical
package names. Maybe we need to rethink the handling of conflicts also.

Andreas

Re: Changing python-wrapper to handle lib/ etc.

[Andreas Enge]

On Thu, Oct 30, 2014 at 02:12:58PM +0100, Ludovic Courtès wrote:
> We’ll also need the patch from
>  in
> this branch.

Maybe not, we will see. Once the python library is propagated, should it not
appear automatically in the LIBRARY_PATH?

I created the branch, see its progress at
   http://hydra.gnu.org/jobset/gnu/wip-python
Personally, I would like to go slowly with one modification at a time, but
each of them rebuilds about a quarter of the archive. If this poses problems,
we might wish to disable building it on mipsel64 up to the last step.

Andreas

Re: [PATCH] gnu: Add freeimage.

[Andreas Enge]

On Sat, Nov 01, 2014 at 01:21:55PM -0400, David Thompson wrote:
> +'(#:phases (alist-replace
> +'unpack
> +(lambda* (#:key source #:allow-other-keys)
> +  (and (zero? (system* "unzip" source))
> +   (chdir "FreeImage")))
> +(alist-delete
> + 'configure
> + (alist-cons-before
> +  'build 'patch-makefile
> +  (lambda* (#:key outputs #:allow-other-keys)
> +(substitute* "Makefile.gnu"
> +  (("/usr") (assoc-ref outputs "out"))
> +  (("-o root -g root") "")))
> +  %standard-phases)))

I think that instead of adding patch-makefile before build, I would let it
replace configure. But this is just a matter of taste, so please do as you
please.

Andreas

Re: Patch-shebangs phase and created binaries

[Andreas Enge]

On Sun, Nov 02, 2014 at 05:54:09PM +0100, Ludovic Courtès wrote:
> Andreas Enge  skribis:
> > should the final patch-shebangs phase not include the generated output
> > path (well, the bin subdirectory) in its $PATH?
> It already does.

Hm.

> > The file starts with 
> > #!/usr/bin/env texlua
> > and texlua is a binary created in the texlive output (actually, bin/texlua 
> > is
> > a symbolic link to the elf binary bin/luatex).
> Could it be that the symlink doesn’t exist yet at the time the
> ‘patch-shebangs’ phase runs?

I think it already exists; the only thing between patch-shebangs and strip is
 (setenv "PATH" (string-append (getenv "PATH") ":" out "/bin"))
 (system* "updmap-sys" "--nohash" "--syncwithtrees")
 (system* "mktexlsr")
 (system* "fmtutil-sys" "--all")))

Andreas

Re: Font package naming convention

[Andreas Enge]

On Sun, Nov 02, 2014 at 06:18:19PM +0100, Ludovic Courtès wrote:
> Some of the fonts created by foundries are often referred to it using
> the foundry’s name, such as “Bitstream Vera”; there are also
> counter-examples, like Gentium, Charis, etc. (by SIL.)
> 
> So, again very informally, I would suggest to use the foundry name in
> cases where people expect to see it, and in cases where it removes
> ambiguity with similarly-named fonts.
> 
> What do people think?

I think it would be nice to add the foundry when it is know, such as
sil-gentium etc.; personally I find it an interesting information to have
(we would get a complete list of all packages sil fonts, for instance).

Andreas

Re: [PATCH] gnu: Add freeimage.

[David Thompson]

Andreas Enge  writes:

> On Sat, Nov 01, 2014 at 01:21:55PM -0400, David Thompson wrote:
>> +'(#:phases (alist-replace
>> +'unpack
>> +(lambda* (#:key source #:allow-other-keys)
>> +  (and (zero? (system* "unzip" source))
>> +   (chdir "FreeImage")))
>> +(alist-delete
>> + 'configure
>> + (alist-cons-before
>> +  'build 'patch-makefile
>> +  (lambda* (#:key outputs #:allow-other-keys)
>> +(substitute* "Makefile.gnu"
>> +  (("/usr") (assoc-ref outputs "out"))
>> +  (("-o root -g root") "")))
>> +  %standard-phases)))
>
> I think that instead of adding patch-makefile before build, I would let it
> replace configure. But this is just a matter of taste, so please do as you
> please.

That's a fair point, though I have already pushed.  Thanks, anyhow. :)

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: [PATCH 2/2] emacs: Add interface for comparing generations.

[Ludovic Courtès]

Alex Kost  skribis:

> In short, now (with this patch) after marking 2 generations (by pressing
> "m" in a “generation-list” buffer), you can perform diff/ediff on
> generation packages or manifests.  Thanks to Ludovic for the idea.

I just tried it, and I like it!

There are cases where the output of ‘=’ is slightly confusing: the
buffers being compared don’t include the directory name of the packages,
so, when packages have been upgraded (different directory names, but
same version), it just says “no differences.”

Perhaps the fix would be to add the directory names in the buffers being
diffed, in a format similar to that of ‘guix package -I’?

I have another case where C-u = shows that the only difference is the
addition of one package, but = shows a diff with only minuses, as if
everything had been removed.  Any idea what could be wrong?

> +++ b/doc/emacs.texi
> @@ -239,6 +239,21 @@ Mark the current generation for deletion (with prefix, 
> mark all
>  generations).
>  @item x
>  Execute actions on the marked generations---i.e., delete generations.
> +@item e
> +Run Ediff (@pxref{Top,,, ediff, Ediff}) on package outputs installed in
> +the 2 marked generations.  With prefix argument, run Ediff on manifests
> +of the marked generations.
> +@item D
> +@itemx =
> +Run Diff (@pxref{Diff Mode,,, emacs, The Emacs Editor}) on package
> +outputs installed in the 2 marked generations.  With prefix argument,
> +run Diff on manifests of the marked generations.
> +@item +
> +List package outputs added to the latest marked generation comparing
> +with another marked generation.
> +@item -
> +List package outputs removed from the latest marked generation comparing
> +with another marked generation.

Likewise, ‘u’ (for ‘upgraded’) could be added (possibly in a future
patch.)

Also, s/The Emacs Editor/GNU Emacs Manual/, which is the real title of
the Emacs manual as it appears in the texi source.

Thanks,
Ludo’.

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

[Ludovic Courtès]

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

> This is because Python is not added to ‘LIBRARY_PATH’, right?
>
> I think this is fixed by this patch:
>
> --- a/guix/build-system/python.scm
> +++ b/guix/build-system/python.scm
> @@ -110,10 +110,11 @@ prepended to the name."
>'())
>  ,@inputs
>  
> +("python" ,python)
> +
>  ;; Keep the standard inputs of 'gnu-build-system'.
>  ,@(standard-packages)))
> - (build-inputs `(("python" ,python)
> - ,@native-inputs))
> + (build-inputs native-inputs)
>   (outputs outputs)
>   (build python-build)
>   (arguments (strip-keyword-arguments private-keywords arguments)

FTR, this patch isn’t needed at all.  What mattered here was to fix
‘python-wrapper’ to have a lib/ sub-directory, which Andreas has just
done in ‘wip-python’.

Ludo’.

Re: Different versions of a package in the same profile?

[Federico Beffa]

Andreas Enge  writes:

> On Sun, Nov 02, 2014 at 06:22:28PM +0100, Ludovic Courtès wrote:
> There is also the question of conflicts with identical file names. They are
> already there now, but their probability should be higher with identical
> package names. Maybe we need to rethink the handling of conflicts also.

In the past I did use the packaging system called SEPP

http://oss.oetiker.ch/op-sepp/

It allow installing several versions of a program on a single system.
The way they use to avoid naming conflicts it to systematically add a
suffix to binary names, with the suffix corresponding to the version of
the package.  They even went one step further and they added a suffix
with the initials of the administrator who packaged the application.

Each program was available with several names. For program foo:
- foo
- foo-1.2.3
- foo-1.2.3-fb
Obviously if more foo versions were installed, only one would be
referred to by foo.  The others were available with versioned names.

As a user, the system did work very well.

To handle updating, specifying foo should update the version owning
the name foo.  To update another version one would give the versioned
name "foo-1.2.3".

Regards,
Fede

Re: Grafts

[Ludovic Courtès]

I went ahead and merged the guts of ‘wip-grafts’.  This changes the ABI,
so make sure to run:

  make clean-go && make

> However, the ‘graft-derivation’ procedure is not recursive: it grafts
> the derivation you give it, but doesn’t graft its dependencies.

This problem is not addressed yet, but I decided to postpone it,
probably until after 0.8 (I have the beginnings of a fix, but nothing
baked yet), so we can move forward.

To summarize, we can already use grafts, via the ‘replacement’ field of
a package, but there are some cases where it will not do exactly what we
want.  Please send a message if you want to use it and are unsure.

Ludo’.

Re: [PATCH] gnu: add atlas

[Federico Beffa]

On Sun, Oct 26, 2014 at 3:17 PM, Ludovic Courtès  wrote:
> BTW, if you want, you can create a Savannah account so you have commit
> access, under the rules given in ‘HACKING’.

Thanks for the offer!  I've created an account.  My knowledge of git
is very limited and I've never pushed any change with it.  I will
therefore need some guidance.  I'm reading Git Pro
http://git-scm.com/book/en/v2
Do you have any other pointer, possibly more concise and in line with
guix's use?

Regards,
Fede

Re: [PATCH] gnu: Add freeimage.

[Andreas Enge]

Unfortunately, it fails to build on mips:
   http://hydra.gnu.org/build/136438
Could you have a look? To me it looks as if there is bad assembly code
in the source:
/tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s: Assembler messages:
/tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s:360: Error: opcode not 
supported on this processor: mips3 (mips3) `madd $24,$10'
...

Andreas

Re: Changing python-wrapper to handle lib/ etc.

[Andreas Enge]

The first problem occurs. Swig does not compile any more:
   http://hydra.gnu.org/build/134889/log/raw

There are lots of error messages of the form:
checking testcase namespace_nested under python
namespace_enum_wrap.cxx:154:21: fatal error: Python.h: No such file or directory
 # include 

If one compares with the version in master:
   http://hydra.gnu.org/build/131472/log/raw
one realises that there python was simply not found, so the tests were
probably not executed:
checking for Python header files... 
checking for Python library... Not found
checking for python3... no

With the new python wrapper, something is found:
checking for python3-config... python3-config
checking for Python 3.x prefix... 
/gnu/store/r6614z0w2inxn78wzaa7ic5sai8s7l9f-python-3.3.5
checking for Python 3.x exec-prefix... 
/gnu/store/r6614z0w2inxn78wzaa7ic5sai8s7l9f-python-3.3.5
checking for Python 3.x version... python3.3
checking for Python 3.x lib dir... lib
checking for Python 3.x header files... 
-I/gnu/store/r6614z0w2inxn78wzaa7ic5sai8s7l9f-python-3.3.5/include/python3.3m 
-I/gnu/store/r6614z0w2inxn78wzaa7ic5sai8s7l9f-python-3.3.5/include/python3.3m
checking for Python 3.x library... Not found

Whatever this means! The header files are correctly located in the python3.3m
subdirectory of the include directory. However, the CPATH includes only
the include/ directory itself (logic!). And apparently the tests do not
use the correct include path.

Could maybe a swig specialist have a look?

Andreas

Re: [PATCH] gnu: Add freeimage.

[David Thompson]

Andreas Enge  writes:

> Unfortunately, it fails to build on mips:
>http://hydra.gnu.org/build/136438
> Could you have a look? To me it looks as if there is bad assembly code
> in the source:
> /tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s: Assembler messages:
> /tmp/nix-build-freeimage-3.16.0.drv-0/cc1WaZEm.s:360: Error: opcode not 
> supported on this processor: mips3 (mips3) `madd $24,$10'
> ...

When I get the chance, I will just disable mips support for freeimage
and post a patch.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: [PATCH 2/2] emacs: Add interface for comparing generations.

[Alex Kost]

Ludovic Courtès (2014-11-02 20:59 +0300) wrote:

> Alex Kost  skribis:
>
>> In short, now (with this patch) after marking 2 generations (by pressing
>> "m" in a “generation-list” buffer), you can perform diff/ediff on
>> generation packages or manifests.  Thanks to Ludovic for the idea.
>
> I just tried it, and I like it!
>
> There are cases where the output of ‘=’ is slightly confusing: the
> buffers being compared don’t include the directory name of the packages,
> so, when packages have been upgraded (different directory names, but
> same version), it just says “no differences.”
>
> Perhaps the fix would be to add the directory names in the buffers being
> diffed, in a format similar to that of ‘guix package -I’?

Indeed, I added the store paths, thanks (the modified patch is attached).

> I have another case where C-u = shows that the only difference is the
> addition of one package, but = shows a diff with only minuses, as if
> everything had been removed.  Any idea what could be wrong?

No idea, sorry (unless you manually erased "*Guix :
generation *" buffer).  Make sure that the following works in
Guix REPL:

  (generation-package-specifications "/your/profile" gen-number)

Also, kill "*Guix : generation *" buffer and try
again.

Or maybe: did you experiment with different profiles with the same name?
I mean "/some/path/to/foo-profile" and "/another/path/to/foo-profile".

>> +++ b/doc/emacs.texi
>> @@ -239,6 +239,21 @@ Mark the current generation for deletion (with prefix, 
>> mark all
>>  generations).
>>  @item x
>>  Execute actions on the marked generations---i.e., delete generations.
>> +@item e
>> +Run Ediff (@pxref{Top,,, ediff, Ediff}) on package outputs installed in
>> +the 2 marked generations.  With prefix argument, run Ediff on manifests
>> +of the marked generations.
>> +@item D
>> +@itemx =
>> +Run Diff (@pxref{Diff Mode,,, emacs, The Emacs Editor}) on package
>> +outputs installed in the 2 marked generations.  With prefix argument,
>> +run Diff on manifests of the marked generations.
>> +@item +
>> +List package outputs added to the latest marked generation comparing
>> +with another marked generation.
>> +@item -
>> +List package outputs removed from the latest marked generation comparing
>> +with another marked generation.
>
> Likewise, ‘u’ (for ‘upgraded’) could be added (possibly in a future
> patch.)

Probably in the future, as that "upgraded" thing has a different nature
comparing with "added" and "removed".

> Also, s/The Emacs Editor/GNU Emacs Manual/, which is the real title of
> the Emacs manual as it appears in the texi source.

Oh, I thought it should be the title which appears in the info (I mean
the first line in the Top node).

Perhaps "s/The Emacs Editor/The GNU Emacs Manual/"?  As it's the most
common (but not the one) variant in the Emacs Lisp manual, for example here:


Also I used "The Emacs Editor" several times in “emacs.texi”.  Should I
replace all instances in this patch or make a separate commit for that?


Just out of curiosity.  Do you usually prefer "diff" over "ediff"?
(I find the latter much convenient)

>From f63e575bc765c26494baa6bb1ec06f65bb05d007 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Sun, 2 Nov 2014 13:58:21 +0300
Subject: [PATCH] emacs: Add interface for comparing generations.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested by Ludovic Courtès.

* doc/emacs.texi (Emacs List buffer): Document new key bindings.
* emacs/guix-base.el (guix-generation-packages-buffer-name-function,
  guix-output-path-column): New variables.
  (guix-generation-file, guix-manifest-file, guix-generation-packages,
  guix-generation-packages-buffer-name-default,
  guix-generation-packages-buffer-name-long,
  guix-generation-packages-buffer-name, guix-generation-packages-buffer,
  guix-generation-insert-package, guix-profile-generation-manifest-file,
  guix-profile-generation-packages-buffer): New procedures.
* emacs/guix-list.el: Add key bindings for comparing generations.
  (guix-generation-list-generations-to-compare,
  guix-generation-list-show-added-packages,
  guix-generation-list-show-removed-packages, guix-generation-list-compare,
  guix-generation-list-ediff-manifests, guix-generation-list-diff-manifests,
  guix-generation-list-ediff-packages, guix-generation-list-diff-packages,
  guix-generation-list-ediff, guix-generation-list-diff): New procedures.
* emacs/guix-messages.el (guix-messages): Add 'generation-diff' messages.
* emacs/guix-utils.el (guix-diff-switches): New variable.
  (guix-diff): New procedure.
* emacs/guix-main.scm (package/output-sexps): Handle 'generation-diff' search
  type.
  (manifest-entry->package-specification,
  manifest-entries->package-specifications, generation-package-specifications,
  generation-package-specifications+paths, generation-difference): New
  procedures.
---
 doc/emacs.texi | 15 +