diff mbox

[2/3] gnu: Add ledger.

Message ID 1463070674.3638408.605951137.5C3DB897@webmail.messagingengine.com
State New
Headers show

Commit Message

Alex Griffin May 12, 2016, 4:31 p.m. UTC
On Thu, May 12, 2016, at 04:12 AM, Alex Kost wrote:
> Hello, was this package built successfully for you?  I tried it but the
> build phase failed (I'm attaching the last part of the build process [1]
> just in case).  I don't know, maybe I just don't have enough memory
> (3GB) to build it (I had such problems with cmake before).

Yes, it builds fine for me. It looks like the important line in your
build log is "c++: internal compiler error: Killed (program cc1plus)",
which could be from running out of memory. Does it still happen if you
add `#:parallel-build? #f` to the build system arguments?

> Every phase should return non-false value if it succeeded.  So since the
> returned value of 'install-file' is not specified, we add #t to the end
> of such phases.  Please add #t to all phases except the following
> (build-doc) because zero? returns #t if succeeded.

OK, done.

> Unlike configure-flags where we can use only %build-inputs, in phases,
> it is better to use a functional style using 'inputs' passed to a phase
> as argument:

Done.

> It doesn't matter but usually we put #:configure-flags before #:phases.

Done. Attached is an updated patch.

Thanks,

Comments

Leo Famulari May 12, 2016, 7:03 p.m. UTC | #1
On Thu, May 12, 2016 at 11:31:14AM -0500, Alex Griffin wrote:
> On Thu, May 12, 2016, at 04:12 AM, Alex Kost wrote:
> > Hello, was this package built successfully for you?  I tried it but the
> > build phase failed (I'm attaching the last part of the build process [1]
> > just in case).  I don't know, maybe I just don't have enough memory
> > (3GB) to build it (I had such problems with cmake before).
> 
> Yes, it builds fine for me. It looks like the important line in your
> build log is "c++: internal compiler error: Killed (program cc1plus)",
> which could be from running out of memory. Does it still happen if you
> add `#:parallel-build? #f` to the build system arguments?

I can build it on x86_64 with 8 GB RAM.

I monitored resource usage, and saw peak usage of > 4 GB RAM.
4.16s user 0.18s system 0% cpu 7:49.75 total

When #:parallel-build? was #f, I saw peaks of ~1 GB RAM.
4.08s user 0.16s system 0% cpu 15:12.48 total
Alex Kost May 13, 2016, 7:16 p.m. UTC | #2
Alex Griffin (2016-05-12 19:31 +0300) wrote:

> On Thu, May 12, 2016, at 04:12 AM, Alex Kost wrote:
>> Hello, was this package built successfully for you?  I tried it but the
>> build phase failed (I'm attaching the last part of the build process [1]
>> just in case).  I don't know, maybe I just don't have enough memory
>> (3GB) to build it (I had such problems with cmake before).
>
> Yes, it builds fine for me. It looks like the important line in your
> build log is "c++: internal compiler error: Killed (program cc1plus)",
> which could be from running out of memory. Does it still happen if you
> add `#:parallel-build? #f` to the build system arguments?

Oh indeed, if parallel-build is disabled, it is built successfully.
Thank you (and Leo)!

So I don't know, should ‘#:parallel-build? #f’ be used in the final
package recipe?  I guess not, as it looks like a problem on my side (not
enough memory for parallel-build).

>> Every phase should return non-false value if it succeeded.  So since the
>> returned value of 'install-file' is not specified, we add #t to the end
>> of such phases.  Please add #t to all phases except the following
>> (build-doc) because zero? returns #t if succeeded.
>
> OK, done.
>
>> Unlike configure-flags where we can use only %build-inputs, in phases,
>> it is better to use a functional style using 'inputs' passed to a phase
>> as argument:
>
> Done.
>
>> It doesn't matter but usually we put #:configure-flags before #:phases.
>
> Done. Attached is an updated patch.

Thank you!  Overall the patch looks good to me, I have only a couple of
comments more (I'm sorry I didn't notice it before :-)).  But no need to
resent the patch, I can fix it on my side and commit it.  The only thing
that is unclear for me is whether this parallel-build should be disabled
or not.

> From 0090f1d526f35a72144a3d32158cbad987ef4d10 Mon Sep 17 00:00:00 2001
> From: Alex Griffin <a@ajgrf.com>
> Date: Sat, 7 May 2016 12:20:47 -0500
> Subject: [PATCH 2/2] gnu: Add ledger.
>
> * gnu/packages/finance.scm (ledger): New variable.
[...]
> +(define-public ledger
> +  (package
> +    (name "ledger")
> +    (version "3.1.1")
> +    (source (origin
> +              (method url-fetch)
> +              (uri (string-append "https://github.com/ledger/ledger/archive/v"
> +                                  version
> +                                  ".tar.gz"))
> +              (file-name (string-append name "-" version ".tar.gz"))
> +              (sha256
> +               (base32
> +                "12jlv3gsjhrja25q9hrwh73cdacd2l3c2yyn8qnijav9mdhnbw4h"))))
> +    (build-system cmake-build-system)
> +    (arguments
> +     `(#:configure-flags
> +       `("-DBUILD_DOCS:BOOL=ON"
> +         "-DBUILD_WEB_DOCS:BOOL=ON"
> +         "-DBUILD_EMACSLISP:BOOL=ON"
> +         "-DUSE_PYTHON:BOOL=ON"
> +         "-DCMAKE_INSTALL_LIBDIR:PATH=lib"
> +         ,(string-append "-DUTFCPP_INCLUDE_DIR:PATH="
> +                         (assoc-ref %build-inputs "utfcpp")
> +                         "/include"))
> +       #:phases
> +       (let* ((out (assoc-ref %outputs "out"))
> +              (examples (string-append out "/share/doc/ledger/examples"))
> +              (site-lisp (string-append out "/share/emacs/site-lisp")))
> +         (modify-phases %standard-phases

I only notice just now that you have 'modify-phases' inside this let.  I
would rather make local 'let'-s with necessary variables inside phases.
I mean 'examples' directory is needed only inside 'install-examples'
phase; 'site-lisp' inside 'relocate-elisp' phase.  Also it is better to
use 'outputs' argument passed to phases instead of the global %outputs.

> +           (add-before 'configure 'install-examples
> +             (lambda _
> +               (install-file "test/input/sample.dat" examples)
> +               (install-file "test/input/demo.ledger" examples)
> +               #t))
> +           (add-after 'build 'build-doc
> +             (lambda _ (zero? (system* "make" "doc"))))
> +           (add-before 'check 'check-setup
> +             ;; one test fails if it can't set the timezone
> +             (lambda* (#:key inputs #:allow-other-keys)
> +               (setenv "TZDIR"
> +                       (string-append (assoc-ref inputs "tzdata")
> +                                      "/share/zoneinfo"))
> +               #t))
> +           (add-after 'install 'relocate-elisp
> +             (lambda _
> +               (mkdir-p (string-append site-lisp "/guix.d"))
> +               (rename-file (string-append site-lisp "/ledger-mode")
> +                            (string-append site-lisp "/guix.d/ledger-mode"))
> +               #t))))))

It is also good to generate "ledger-autoloads.el" file.  This allows a
user to have "M-x ledger-mode" available by default without any
additional settings.  This can be done by calling:

  (emacs-generate-autoloads "ledger" "<elisp-dir>")

However it is a bit tricky: 'emacs-generate-autoloads' procedure is
placed in (guix build emacs-utils) module which is not available for
cmake build system by default, so this module should be:

1) imported (via #:imported-modules argument), i.e. available for using
2) used (via #:modules argument).

Overall, here is how I would write 'arguments' field of this package:

    (arguments
     `(#:modules ((guix build cmake-build-system)
                  (guix build utils)
                  (guix build emacs-utils))
       #:imported-modules (,@%cmake-build-system-modules
                           (guix build emacs-utils))
       #:configure-flags
       `("-DBUILD_DOCS:BOOL=ON"
         "-DBUILD_WEB_DOCS:BOOL=ON"
         "-DBUILD_EMACSLISP:BOOL=ON"
         "-DUSE_PYTHON:BOOL=ON"
         "-DCMAKE_INSTALL_LIBDIR:PATH=lib"
         ,(string-append "-DUTFCPP_INCLUDE_DIR:PATH="
                         (assoc-ref %build-inputs "utfcpp")
                         "/include"))
       #:parallel-build? #f  ; needed?
       #:phases
       (modify-phases %standard-phases
         (add-before 'configure 'install-examples
           (lambda* (#:key outputs #:allow-other-keys)
             (let ((examples (string-append (assoc-ref outputs "out")
                                            "/share/doc/ledger/examples")))
               (install-file "test/input/sample.dat" examples)
               (install-file "test/input/demo.ledger" examples))
             #t))
         (add-after 'build 'build-doc
           (lambda _ (zero? (system* "make" "doc"))))
         (add-before 'check 'check-setup
           ;; One test fails if it can't set the timezone.
           (lambda* (#:key inputs #:allow-other-keys)
             (setenv "TZDIR"
                     (string-append (assoc-ref inputs "tzdata")
                                    "/share/zoneinfo"))
             #t))
         (add-after 'install 'relocate-elisp
           (lambda* (#:key outputs #:allow-other-keys)
             (let* ((site-dir (string-append (assoc-ref outputs "out")
                                             "/share/emacs/site-lisp"))
                    (guix-dir (string-append site-dir "/guix.d"))
                    (orig-dir (string-append site-dir "/ledger-mode"))
                    (dest-dir (string-append guix-dir "/ledger-mode")))
               (mkdir-p guix-dir)
               (rename-file orig-dir dest-dir)
               (emacs-generate-autoloads ,name dest-dir))
             #t)))))

The rest looks good to me, so if there will be no other comments, I will
commit it (without ‘#:parallel-build? #f’).

> +    (inputs `(("boost" ,boost)
> +              ("gmp" ,gmp)
> +              ("libedit" ,libedit)
> +              ("mpfr" ,mpfr)
> +              ("python" ,python-2)
> +              ("tzdata" ,tzdata)
> +              ("utfcpp" ,utfcpp)))
> +    (native-inputs `(("emacs-no-x" ,emacs-no-x)
> +                     ("groff" ,groff)
> +                     ("texinfo" ,texinfo)))
> +    (home-page "http://ledger-cli.org/")
> +    (synopsis "Command-line double-entry accounting program")
> +    (description
> +     "Ledger is a powerful, double-entry accounting system that is
> +accessed from the UNIX command-line.  This may put off some users, since
> +there is no flashy UI, but for those who want unparalleled reporting
> +access to their data there are few alternatives.
> +
> +Ledger uses text files for input.  It reads the files and generates
> +reports; there is no other database or stored state.  To use Ledger,
> +you create a file of your account names and transactions, run from the
> +command line with some options to specify input and requested reports, and
> +get output.  The output is generally plain text, though you could generate
> +a graph or html instead.  Ledger is simple in concept, surprisingly rich
> +in ability, and easy to use.")
> +    ;; There are some extra licenses in files which do not presently get
> +    ;; installed when you build this package.  Different versions of the GPL
> +    ;; are used in the contrib and python subdirectories.  The bundled version
> +    ;; of utfcpp is under the Boost 1.0 license. Also the file
> +    ;; `tools/update_copyright_year` has an Expat license.
> +    (license (list license:bsd-3
> +                   license:asl2.0     ; src/strptime.cc
> +                   (license:non-copyleft
> +                    "file://src/wcwidth.cc"
> +                    "See src/wcwidth.cc in the distribution.")
> +                   license:gpl2+))))  ; lisp/*
Alex Griffin May 13, 2016, 9:05 p.m. UTC | #3
I don't know whether parallel builds should be enabled or disabled. My
initial thought was that it makes sense if it allows ledger to build on
more machines. On the other hand, the more general fix (one that will
also work on lots of other packages) is simply to allocate more swap on
those machines.

On Fri, May 13, 2016, at 02:16 PM, Alex Kost wrote:
> Overall, here is how I would write 'arguments' field of this package: [...]

Since I wrote this package largely by copying other packages I found,
I'm curious how I would ever learn some of this stuff. How do I know
which variables are available in different parts of the package
definition, and similar details? I could probably just continue diving
deeper into the source, but since it's guile I suspect there's some way
to explore interactively. I'm just not sure how; my REPL fu is weak.
Leo Famulari May 14, 2016, 2:49 a.m. UTC | #4
On Fri, May 13, 2016 at 10:16:29PM +0300, Alex Kost wrote:
> Alex Griffin (2016-05-12 19:31 +0300) wrote:
> > Yes, it builds fine for me. It looks like the important line in your
> > build log is "c++: internal compiler error: Killed (program cc1plus)",
> > which could be from running out of memory. Does it still happen if you
> > add `#:parallel-build? #f` to the build system arguments?
> 
> Oh indeed, if parallel-build is disabled, it is built successfully.
> Thank you (and Leo)!
> 
> So I don't know, should ‘#:parallel-build? #f’ be used in the final
> package recipe?  I guess not, as it looks like a problem on my side (not
> enough memory for parallel-build).

My opinion is that 3 or 4 GB is not a very small amount of RAM for a
personal computer.

I think that allowing users with "only" 4 GB RAM to build our ledger
package is worth it taking twice as long for the rest of us.

Or, users with ≤ 4 GB RAM could make a private variant of ledger that
disables parallel building. We sometimes suggest that users with
esoteric requirements or restrictions do something like this, but I
don't think this is one of those cases.

Thoughts?
Alex Kost May 16, 2016, 3:03 p.m. UTC | #5
Leo Famulari (2016-05-14 05:49 +0300) wrote:

> On Fri, May 13, 2016 at 10:16:29PM +0300, Alex Kost wrote:
>> Alex Griffin (2016-05-12 19:31 +0300) wrote:
>> > Yes, it builds fine for me. It looks like the important line in your
>> > build log is "c++: internal compiler error: Killed (program cc1plus)",
>> > which could be from running out of memory. Does it still happen if you
>> > add `#:parallel-build? #f` to the build system arguments?
>> 
>> Oh indeed, if parallel-build is disabled, it is built successfully.
>> Thank you (and Leo)!
>> 
>> So I don't know, should ‘#:parallel-build? #f’ be used in the final
>> package recipe?  I guess not, as it looks like a problem on my side (not
>> enough memory for parallel-build).
>
> My opinion is that 3 or 4 GB is not a very small amount of RAM for a
> personal computer.
>
> I think that allowing users with "only" 4 GB RAM to build our ledger
> package is worth it taking twice as long for the rest of us.
>
> Or, users with ≤ 4 GB RAM could make a private variant of ledger that
> disables parallel building. We sometimes suggest that users with
> esoteric requirements or restrictions do something like this, but I
> don't think this is one of those cases.

I have commited this patch without ‘#:parallel-build? #f’.  Let's see if
hydra can build it or not :-)
Christopher Allan Webber May 16, 2016, 5:45 p.m. UTC | #6
Leo Famulari writes:

> On Fri, May 13, 2016 at 10:16:29PM +0300, Alex Kost wrote:
>> Alex Griffin (2016-05-12 19:31 +0300) wrote:
>> > Yes, it builds fine for me. It looks like the important line in your
>> > build log is "c++: internal compiler error: Killed (program cc1plus)",
>> > which could be from running out of memory. Does it still happen if you
>> > add `#:parallel-build? #f` to the build system arguments?
>> 
>> Oh indeed, if parallel-build is disabled, it is built successfully.
>> Thank you (and Leo)!
>> 
>> So I don't know, should ‘#:parallel-build? #f’ be used in the final
>> package recipe?  I guess not, as it looks like a problem on my side (not
>> enough memory for parallel-build).
>
> My opinion is that 3 or 4 GB is not a very small amount of RAM for a
> personal computer.
>
> I think that allowing users with "only" 4 GB RAM to build our ledger
> package is worth it taking twice as long for the rest of us.
>
> Or, users with ≤ 4 GB RAM could make a private variant of ledger that
> disables parallel building. We sometimes suggest that users with
> esoteric requirements or restrictions do something like this, but I
> don't think this is one of those cases.
>
> Thoughts?

I guess I'm of a different view... it was only very recently that I
upgraded to a machine that had > 4GB ram.  And not too long ago I had a
machine with 2GB of ram for a long time.

Which, yes maybe that's living in the past... I dunno :)
Efraim Flashner May 16, 2016, 6:05 p.m. UTC | #7
On Mon, May 16, 2016 at 12:45:57PM -0500, Christopher Allan Webber wrote:
> Leo Famulari writes:
> 
> > On Fri, May 13, 2016 at 10:16:29PM +0300, Alex Kost wrote:
> >> Alex Griffin (2016-05-12 19:31 +0300) wrote:
> >> > Yes, it builds fine for me. It looks like the important line in your
> >> > build log is "c++: internal compiler error: Killed (program cc1plus)",
> >> > which could be from running out of memory. Does it still happen if you
> >> > add `#:parallel-build? #f` to the build system arguments?
> >> 
> >> Oh indeed, if parallel-build is disabled, it is built successfully.
> >> Thank you (and Leo)!
> >> 
> >> So I don't know, should ‘#:parallel-build? #f’ be used in the final
> >> package recipe?  I guess not, as it looks like a problem on my side (not
> >> enough memory for parallel-build).
> >
> > My opinion is that 3 or 4 GB is not a very small amount of RAM for a
> > personal computer.
> >
> > I think that allowing users with "only" 4 GB RAM to build our ledger
> > package is worth it taking twice as long for the rest of us.
> >
> > Or, users with ≤ 4 GB RAM could make a private variant of ledger that
> > disables parallel building. We sometimes suggest that users with
> > esoteric requirements or restrictions do something like this, but I
> > don't think this is one of those cases.
> >
> > Thoughts?
> 
> I guess I'm of a different view... it was only very recently that I
> upgraded to a machine that had > 4GB ram.  And not too long ago I had a
> machine with 2GB of ram for a long time.
> 
> Which, yes maybe that's living in the past... I dunno :)
> 

I wish I could remember, but we do have another build that has a test
disabled because it uses ~4GB of memory.
Leo Famulari May 16, 2016, 6:06 p.m. UTC | #8
On Mon, May 16, 2016 at 12:45:57PM -0500, Christopher Allan Webber wrote:
> Leo Famulari writes:
> > My opinion is that 3 or 4 GB is not a very small amount of RAM for a
> > personal computer.
> >
> > I think that allowing users with "only" 4 GB RAM to build our ledger
> > package is worth it taking twice as long for the rest of us.
> >
> > Or, users with ≤ 4 GB RAM could make a private variant of ledger that
> > disables parallel building. We sometimes suggest that users with
> > esoteric requirements or restrictions do something like this, but I
> > don't think this is one of those cases.
> >
> > Thoughts?
> 
> I guess I'm of a different view... it was only very recently that I
> upgraded to a machine that had > 4GB ram.  And not too long ago I had a
> machine with 2GB of ram for a long time.

Don't we agree? I think we should not parellelize the tests, since 4 GB
RAM is too high to be a minimum requirement.
Leo Famulari May 16, 2016, 6:45 p.m. UTC | #9
On Mon, May 16, 2016 at 02:06:51PM -0400, Leo Famulari wrote:
> On Mon, May 16, 2016 at 12:45:57PM -0500, Christopher Allan Webber wrote:
> > Leo Famulari writes:
> > > My opinion is that 3 or 4 GB is not a very small amount of RAM for a
> > > personal computer.
> > >
> > > I think that allowing users with "only" 4 GB RAM to build our ledger
> > > package is worth it taking twice as long for the rest of us.
> > >
> > > Or, users with ≤ 4 GB RAM could make a private variant of ledger that
> > > disables parallel building. We sometimes suggest that users with
> > > esoteric requirements or restrictions do something like this, but I
> > > don't think this is one of those cases.
> > >
> > > Thoughts?
> > 
> > I guess I'm of a different view... it was only very recently that I
> > upgraded to a machine that had > 4GB ram.  And not too long ago I had a
> > machine with 2GB of ram for a long time.
> 
> Don't we agree? I think we should not parellelize the tests, since 4 GB
> RAM is too high to be a minimum requirement.

I mean the entire build, not just the tests.
diff mbox

Patch

From 0090f1d526f35a72144a3d32158cbad987ef4d10 Mon Sep 17 00:00:00 2001
From: Alex Griffin <a@ajgrf.com>
Date: Sat, 7 May 2016 12:20:47 -0500
Subject: [PATCH 2/2] gnu: Add ledger.

* gnu/packages/finance.scm (ledger): New variable.
---
 gnu/packages/finance.scm | 95 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)

diff --git a/gnu/packages/finance.scm b/gnu/packages/finance.scm
index e9487d4..0fb0534 100644
--- a/gnu/packages/finance.scm
+++ b/gnu/packages/finance.scm
@@ -1,6 +1,7 @@ 
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015 Andreas Enge <andreas@enge.fr>
 ;;; Copyright © 2016 Efraim Flashner <efraim@flashner.co.il>
+;;; Copyright © 2016 Alex Griffin <a@ajgrf.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -23,13 +24,21 @@ 
  #:use-module (guix download)
  #:use-module (guix build utils)
  #:use-module (guix build-system gnu)
+ #:use-module (guix build-system cmake)
+ #:use-module (gnu packages base)
  #:use-module (gnu packages boost)
  #:use-module (gnu packages databases)
+ #:use-module (gnu packages emacs)
+ #:use-module (gnu packages groff)
+ #:use-module (gnu packages libedit)
  #:use-module (gnu packages linux)
+ #:use-module (gnu packages multiprecision)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages protobuf)
  #:use-module (gnu packages python)
  #:use-module (gnu packages qt)
+ #:use-module (gnu packages texinfo)
+ #:use-module (gnu packages textutils)
  #:use-module (gnu packages tls)
  #:use-module (gnu packages upnp))
 
@@ -81,3 +90,89 @@  collectively by the network.  Bitcoin Core is the reference implementation
 of the bitcoin protocol.  This package provides the Bitcoin Core command
 line client and a client based on Qt.")
     (license license:expat)))
+
+(define-public ledger
+  (package
+    (name "ledger")
+    (version "3.1.1")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "https://github.com/ledger/ledger/archive/v"
+                                  version
+                                  ".tar.gz"))
+              (file-name (string-append name "-" version ".tar.gz"))
+              (sha256
+               (base32
+                "12jlv3gsjhrja25q9hrwh73cdacd2l3c2yyn8qnijav9mdhnbw4h"))))
+    (build-system cmake-build-system)
+    (arguments
+     `(#:configure-flags
+       `("-DBUILD_DOCS:BOOL=ON"
+         "-DBUILD_WEB_DOCS:BOOL=ON"
+         "-DBUILD_EMACSLISP:BOOL=ON"
+         "-DUSE_PYTHON:BOOL=ON"
+         "-DCMAKE_INSTALL_LIBDIR:PATH=lib"
+         ,(string-append "-DUTFCPP_INCLUDE_DIR:PATH="
+                         (assoc-ref %build-inputs "utfcpp")
+                         "/include"))
+       #:phases
+       (let* ((out (assoc-ref %outputs "out"))
+              (examples (string-append out "/share/doc/ledger/examples"))
+              (site-lisp (string-append out "/share/emacs/site-lisp")))
+         (modify-phases %standard-phases
+           (add-before 'configure 'install-examples
+             (lambda _
+               (install-file "test/input/sample.dat" examples)
+               (install-file "test/input/demo.ledger" examples)
+               #t))
+           (add-after 'build 'build-doc
+             (lambda _ (zero? (system* "make" "doc"))))
+           (add-before 'check 'check-setup
+             ;; one test fails if it can't set the timezone
+             (lambda* (#:key inputs #:allow-other-keys)
+               (setenv "TZDIR"
+                       (string-append (assoc-ref inputs "tzdata")
+                                      "/share/zoneinfo"))
+               #t))
+           (add-after 'install 'relocate-elisp
+             (lambda _
+               (mkdir-p (string-append site-lisp "/guix.d"))
+               (rename-file (string-append site-lisp "/ledger-mode")
+                            (string-append site-lisp "/guix.d/ledger-mode"))
+               #t))))))
+    (inputs `(("boost" ,boost)
+              ("gmp" ,gmp)
+              ("libedit" ,libedit)
+              ("mpfr" ,mpfr)
+              ("python" ,python-2)
+              ("tzdata" ,tzdata)
+              ("utfcpp" ,utfcpp)))
+    (native-inputs `(("emacs-no-x" ,emacs-no-x)
+                     ("groff" ,groff)
+                     ("texinfo" ,texinfo)))
+    (home-page "http://ledger-cli.org/")
+    (synopsis "Command-line double-entry accounting program")
+    (description
+     "Ledger is a powerful, double-entry accounting system that is
+accessed from the UNIX command-line.  This may put off some users, since
+there is no flashy UI, but for those who want unparalleled reporting
+access to their data there are few alternatives.
+
+Ledger uses text files for input.  It reads the files and generates
+reports; there is no other database or stored state.  To use Ledger,
+you create a file of your account names and transactions, run from the
+command line with some options to specify input and requested reports, and
+get output.  The output is generally plain text, though you could generate
+a graph or html instead.  Ledger is simple in concept, surprisingly rich
+in ability, and easy to use.")
+    ;; There are some extra licenses in files which do not presently get
+    ;; installed when you build this package.  Different versions of the GPL
+    ;; are used in the contrib and python subdirectories.  The bundled version
+    ;; of utfcpp is under the Boost 1.0 license. Also the file
+    ;; `tools/update_copyright_year` has an Expat license.
+    (license (list license:bsd-3
+                   license:asl2.0     ; src/strptime.cc
+                   (license:non-copyleft
+                    "file://src/wcwidth.cc"
+                    "See src/wcwidth.cc in the distribution.")
+                   license:gpl2+))))  ; lisp/*
-- 
2.7.4