Re: [PATCH 0/1] QEMU 2.9.0-rc1

[Leo Famulari]

On Thu, Mar 30, 2017 at 09:27:54PM +0200, Marius Bakke wrote:
> Leo Famulari  writes:
> >   gnu: qemu: Update to 2.9.0-rc1 [security fixes].
> 
> I think it would be nice to have this in Guix proper (as a separate
> variable), so users don't have to apply this patch and build it
> manually. The downside is that it would land in users' profiles unless
> they take steps to prevent it, but I'm not sure how much of a problem
> that is given how easy it is to roll-back or exclude it. Thoughts?

I'm unsure if we should add it. QEMU usually goes through 4 or 5 release
candidates.

Does anyone have experience using these heavily? Are they stable or can
we expect them to be buggier than a real release?


signature.asc
Description: PGP signature

[Fwd: Guile @ FSM?]

[ng0]

Hi,

forwarding this message as Guix was also mentioned but just guile
addressed. In any case I think most people are subscribed to both lists.

- Forwarded message from hellekin  -

Date: Thu, 30 Mar 2017 19:10:54 +0200
From: hellekin 
To: guile-u...@gnu.org
Subject: Guile @ FSM?
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 
Icedove/45.2.0

Hey there Guilers!

We're only one day away from the closure of the CFP* for Free Software
Meeting 2017 in Saint-Étienne, France, and I didn't see any proposal
from the Guile - GuixSD community.  I'm sure there are very interesting
things to present, either in French or English, and I'd be delighted to
see Guile represented.

This way: https://2017.rmll.info/cfp

Thank you for your attention,

==
hk

* There's an extension, of course ;o)


- End forwarded message -

Re: [PATCH 0/1] QEMU 2.9.0-rc1

[Marius Bakke]

Leo Famulari  writes:

> This is just a release candidate, but it does boot the GuixSD release
> image.
>
> I'm sharing it so that people can get early access to the bug fixes it
> includes.
>
> Leo Famulari (1):
>   gnu: qemu: Update to 2.9.0-rc1 [security fixes].

I think it would be nice to have this in Guix proper (as a separate
variable), so users don't have to apply this patch and build it
manually. The downside is that it would land in users' profiles unless
they take steps to prevent it, but I'm not sure how much of a problem
that is given how easy it is to roll-back or exclude it. Thoughts?


signature.asc
Description: PGP signature

Re: On merging the npm importer

[Jan Nieuwenhuizen]

Jelle Licht writes:

Hi Jelle!

> As one of these people living in the "real world", this is exactly how
> I have been using the importer up till now.  I like and agree with
> most of your changes as they make the code much more robust in the
> face of inevitable failure.

Great!

> Nonetheless, one could say that we should not make it too easy to
> inadvertently create package specifications for 'binaries'.

Is the --binary flag not obvious enough?  Do you have a suggestion?

> One tiny improvement might be to use `spdx-string->license` from (guix
> import utils), instead of duplicating this effort in the npm importer.

That sounds like an improvement, would you like to help with that?

> How would you propose we get to reviewing your code? Would you care to
> send some patches, or should we bother you via gitlab a bit more?

I think review should be done here, with patches.  I thought it might be
just a bit too early for that and was hoping others [you] would want to
make some changes first...and maybe pulling my git would be handier
then.

I'm happy to send the patches here, whatever is convenient.

Greetings, janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: [PATCH] profiles: Generate database file for manpages

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> I've managed to finalize a profile hooks which takes care of generating
> the manpages database file. This file is used by apropos or man -k to
> provide results.

Awesome!  I’ve been willing to have this for some time.

> I've tested and found it to be working for the regular user profile. To
> try it, apply the patch and use a guix command that causes a new profile
> generation.
>
> For example: guix package -r git -i git
> Then: "apropos git" should return plenty of results.

For some reason I have to use “man -K” (capital):

--8<---cut here---start->8---
~$ apropos guile
guile: nothing appropriate.
~$ man -k guile
guile: nothing appropriate.
~$ man -K guile
--Man-- next: skribilo(1) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]
--Man-- next: guile(1) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]
--Man-- next: guix-pull(1) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]
--Man-- next: guix-package(1) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]
--Man-- next: gv(3guile) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]
~$ env | grep MANPATH
MANPATH=/home/ludo/.guix-profile/share/man:/run/current-system/profile/share/man:/home/ludo/.guix-profile/share/man:/run/current-system/profile/share/man:/home/ludo/.opam/system/man
--8<---cut here---end--->8---

Any idea why?

> It requires extra processing time to do the work since the complete
> database (on my system, there are thousands or manpages being indexed)
> is recreated everytime a new profile is generated.

On my laptop (with an SSD), I found it to be reasonable:

--8<---cut here---start->8---
$ time guix build 
/gnu/store/rkri628apz2a2i2jvav11ylv2736fvv3-manual-database.drv --check
@ build-started /gnu/store/rkri628apz2a2i2jvav11ylv2736fvv3-manual-database.drv 
- x86_64-linux 
/var/log/guix/drvs/rk//ri628apz2a2i2jvav11ylv2736fvv3-manual-database.drv.bz2
/gnu/store/g7qxdk1cn7fwkamkaisi4428k6ijg0w2-manual-database

real0m2.647s
user0m0.116s
sys 0m0.004s
$ guix package -I |wc -l
229
--8<---cut here---end--->8---

> For now it doesn't work for guix environments (yet), but this should be
> easy to fix (it seems the $GUIX_ENVIRONMENT/share/man should be merged
> with $HOME/.guix-profile/share/man, but I need to look at it more
> carefully).

It seems to work but only with capital -K:

--8<---cut here---start->8---
$ ./pre-inst-env guix environment --ad-hoc guile man-db --pure -- man -K guile
man: can't execute cat: No such file or directory
man: command exited with status 255: sed -e '/^[[:space:]]*$/{ N; 
/^[[:space:]]*\n[[:space:]]*$/D; }' | (cd  && LESS=-ix8RmPm Manual page 
guile(1) ?ltline %lt?L/%L.:byte %bB?s/%s..?e (END):?pB %pB\%.. (press h for 
help or q to quit)$PM Manual page guile(1) ?ltline %lt?L/%L.:byte %bB?s/%s..?e 
(END):?pB %pB\%.. (press h for help or q to quit)$ MAN_PN=guile(1) cat)
--8<---cut here---end--->8---

(And we should hard-code the file name of ‘cat’ in ‘man’…)

> From dbbe6894919164cd34572a28bfbbf6d4d681e35b Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer 
> Date: Tue, 28 Mar 2017 09:25:21 -0700
> Subject: [PATCH] profiles: Generate database file for manpages
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The mandb database file (index.db) is used by the "apropos" (whatis) or
> "man -k" commands. This change introduces a profile hook to generate
> such database file.
>
> Co-authored by Ludovic Courtès
>
> * guix/profiles.scm (manual-database): New procedure.
> (%default-profile-hooks): Add it.

I made some simplifications to the patch.  WDYT?

Thanks,
Ludo’.

diff --git a/guix/profiles.scm b/guix/profiles.scm
index 795c9447f..f565f358b 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2016 Ricardo Wurmus 
 ;;; Copyright © 2016 Chris Marusich 
 ;;; Copyright © 2017 Huang Ying 
+;;; Copyright © 2017 Maxim Cournoyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -946,10 +947,73 @@ files for the fonts of the @var{manifest} entries."
 #:local-build? #t
 #:substitutable? #f))
 
+(define (manual-database manifest)
+  (define man-db  ;lazy reference
+(module-ref (resolve-interface '(gnu packages man)) 'man-db))
+
+  (define build
+#~(begin
+(use-modules (guix build utils)
+ (srfi srfi-1))
+
+(define entries
+  (filter-map (lambda (directory)
+(let ((man (string-append directory "/share/man")))
+  (and (directory-exists? man)
+   man)))
+  '#$(manifest-inputs manifest)))
+
+(define manpages-collection-dir
+  (string-append (getenv "PWD"

Re: On merging the npm importer

[Ludovic Courtès]

Hello!

Christopher Allan Webber  skribis:

> Jan Nieuwenhuizen writes:

[...]

>> We have a working importer for npm packages written by Jelle that I have
>> been using for about half a year.  It can use some improvements and
>> that's why I think we should merge it.
>>
>> Have alook at my npm branch here, rebased on master
>>
>> https://gitlab.com/janneke/guix
>
> Would like to review soon, though I'll say that I think unless there are
> serious problems, we should probably merge it.  Avoiding bitrot is prety
> important, and at the very least I don't think it will hurt to have it
> merged.

Agreed.  If there are tests and doc and it’s all “reasonable”, which I
think it is, I second that!

>> I suggest to not add any npm package to Guix that is the result of using
>> the --binary option and to build a base of full-source/sanitized npm
>> packages.
>
> Cool... makes sense to me to have this as something we don't use for
> Guix packages, but which might make Guix more useful for people who have
> to use npm in the awkward "real world" that is the current state of npm.

How terrible must it be to live in the “real world”!  :-)

Ludo’.

Re: Another cli interface for guix/sd

[Ludovic Courtès]

Hi!

Amirouche Boubekki  skribis:

> This is a reply to a previous conversation that was started last year
> http://lists.gnu.org/archive/html/guix-devel/2016-04/msg00724.html

[...]

> So I summed things in the following cli mockup:
>
> xote container attach NAME
> xote container init NAME SPEC
> xote container start NAME
>
> xote helper download URL
> xote helper hash FILE
>
> xote package archive export [-r] PACKAGE
> xote package archive import
> xote package build PACKAGE
> xote package challenge PACKAGE
> xote package edit PACKAGE
> xote package graph PACKAGE
> xote package import IMPORTER ARGS
> xote package lint PACKAGE
> xote package pack PACKAGE
> xote package size PACKAGE
> xote package search PACKAGE
>
> xote profile delete-generations
> xote profile enter
> xote profile init
> xote profile install
> xote profile leave
> xote profile list-generations
> xote profile list-installed
> xote profile manifest
> xote profile rebase
> xote profile refresh
> xote profile remove
> xote profile rollback
> xote profile switch-generations
>
> xote publish
>
> xote pull
>
> xote store gc
>
> xote system build
> xote system container
> xote system disk-image
> xote system extension-graph
> xote system init
> xote system reconfigure
> xote system refresh
> xote system rollback
> xote system shepherd-graph
> xote system switch-generation
> xote system vm
> xote system vm-image
>
> In particular:
>
> - guix environement is gone, because it can be replaced with guix profile
> - I think the cli should reflect the underlying inner working but also the
> usage. For instance, one might argue that containers are just systems (or
> profiles) but for the user it makes a great difference to have the commands
> spread as several multiple commands instead of a single command that does
> everything required.
> - There is surely missing commands in the "store" section, input welcome!
> - There is two single commands without subcommands called "pull" and
> "publish". I am not sure where to put them.

I think this does not address one of my main concerns in the previous
discussion, which is that we’re talking about a interface for users, and
that this should obey different rules and an API or a formal
categorization.

One of these rules is conciseness.  ‘guix helper download’ and ‘guix
package edit’ are good examples of what I think should be avoided.  :-)

Another rule IMO is to have commands that remind users of use cases,
rather than internal implementation aspects.  For instance, I find ‘guix
profile enter’ to be potentially less clear than ‘guix environment’ in
that respect.

Another thing that makes strict categorization inappropriate in my eye
is that many commands can take either a package name or a store file
name.  That’s the case of ‘guix build’, ‘guix size’, ‘guix graph’, and
probably others.  Thus putting them under the ‘package’ category is not
quite accurate; they’d need to appear in a second directory as well.


For a start, I think we should focus on ‘guix package’ since there’s
consensus that it does too much.  What do we leave in it?  What do we
take out?  Should we add a ‘guix profile’ command to deal with
generations, but not to install/remove/upgrade packages?

Similarly, as has been discussed before, we should probably add ‘guix
install’, ‘guix remove’, and ‘guix upgrade’ aliases that do what we
would expect.

Thoughts?

Thanks,
Ludo’.

Re: On merging the npm importer

[Jelle Licht]

2017-03-29 19:39 GMT+02:00 Christopher Allan Webber 
:

> Jan Nieuwenhuizen writes:
>
> > Hi,
>
> Hi Jan!
>

Hello Jan and Christopher!

>
> > We have a working importer for npm packages written by Jelle that I have
> > been using for about half a year.  It can use some improvements and
> > that's why I think we should merge it.
> >
> > Have alook at my npm branch here, rebased on master
> >
> > https://gitlab.com/janneke/guix
>
> Would like to review soon, though I'll say that I think unless there are
> serious problems, we should probably merge it.  Avoiding bitrot is prety
> important, and at the very least I don't think it will hurt to have it
> merged.
>

> > I added a patch with several fixes for the importer and and build
> > system.  So far, so good.
> >
> > There's a problem however with the --recursive option and the build
> > system.  To quote Jelle[1]
> >
> >To start of with something that did not work out as well as I had
> >hoped, getting a popular build system (e.g. Gulp, Grunt, Broccoli and
> >others) packaged.  As mentioned in my earlier mails, the list of
> >transitive dependencies of any of these suffer from at least the
> >following:
> >
> >- It is a list with more than 4000 packages on it
> >- It is a list with at some point the package itself on it
> >
> > Most nontrivial npm packages use a build system, and all build systems
> > have circular development dependencies.  Not all development
> > dependencies are always required to build a package, but some certainly
> > are nd there's no way to tell which is which, afaik.
> >
> > That's why I added a --binary option to the importer: it will not
> > try to use the build system and instead mimick `what npm does.'  This
> > does provide, however, an amazing reproducibility feature to the
> > dependency woes that npm hackers are familar with.
> >
> > I suggest to not add any npm package to Guix that is the result of using
> > the --binary option and to build a base of full-source/sanitized npm
> > packages.
>
> Cool... makes sense to me to have this as something we don't use for
> Guix packages, but which might make Guix more useful for people who have
> to use npm in the awkward "real world" that is the current state of npm.
>

As one of these people living in the "real world", this is exactly how I
have been using the importer up till now.
I like and agree with most of your changes as they make the code much more
robust in the face of inevitable failure.

Nonetheless, one could say that we should not make it too easy to
inadvertently create package specifications for 'binaries'.

One tiny improvement might be to use `spdx-string->license` from (guix
import utils), instead of duplicating this effort in the npm importer.

How would you propose we get to reviewing your code? Would you care to send
some patches, or should we bother you via gitlab a bit more?

>
> > Greetings, janneke
> >
> > [1] https://lists.gnu.org/archive/html/guix-devel/2016-08/msg01567.html
>
>
Regards,

jlicht

Re: My recent appalling behaviour on this list.

[Catonano]

John,

2017-03-23 6:46 GMT+01:00 John Darrington :

>
> In my mistaken belief that ng0 was trying to impose upon the world new
> rules of English grammar, I considered this to be an assault on
> freedom of speech.   I told ng0 I would refuse to comply, having
> completely misunderstood (and failed to clarify) the request.
>
> Ng0's angry response, I attributed to wounded pride, an over-inflated
> ego and a childish temperament on ng0's part.   I now see that this was
> totally unfounded.  Under the circumstances, ng0 had every right to
> feel extremely insulted and very angry at what I said.   The people who
> sprang to his defence are commendable.
>
>
[...]


I apologise to ng0 without reservation.
>

as far as I'm concerned, I appreciate the apology and the clarification.

Admittedly, I also had misunderstood your motivations. Knowing that I was
wrong about those is a relief.

In this regard, I'd like to point out that you observed how these gender
based objections are often raised by male cisgender people about
mislabeling transgender women but not as often by cisgender women about
mislabeling transgender men.

Was that just an unfortunate rhetoric tool ?

Or did you already run in such clashes in the past, maybe in different
communities ?

If it was a rhetoric accident, then ok

But if you already run into this this kind of misunderstanding before, my
suggestion is to go to those people and clarify your motivation to them too

In fact, mistaking your motivations for political ones can turn out to be
bitter to lgbt people.

Some say that this could hurt software projects in keeping some people
away, but I prefer to focus on feelings and moods.

Life is what it is, there's no need to let badly formulated sentences to
leave back more sour than it is necessary

If I ever have cause to discuss ng0 in the third person, I will of course
> do so using their pronoun of choice.
>

Please, remember not offering alternative views when ng0 asks people to use
the singular they/them for them ;-)


>
> I apologise too, to the rest of this list for wasting time and resources,
> on a completely unnecessary flame-war, which could have been avoided
> if only I had fully read a post before replying.
>

The good part of this is that the community as a whole had an opportunity
to elaborate the issue and some important points were made in the process.

The appropriateness of the discussion for the mailing list, the invitation
to read about the subject, the statement of priorities for this project.

I want to thank Ludo and Ricardo. Their position is not easy, managing
conflicts is a thankless job, probably more so than reviewing patches ;-)

But in my view they did the right thing.

[PATCH] gnu: node: Update to 7.8.0.

[Jelle Licht]

Hi,

Attached you will find a (simple) patch to update Node.js to the latest
released version.

Regards,
jlicht
From fe46d754e61c776e46d59f72f5fc2bed5a0a177e Mon Sep 17 00:00:00 2001
From: Jelle Licht 
Date: Thu, 30 Mar 2017 15:57:59 +0200
Subject: [PATCH] gnu: node: Update to 7.8.0.

* gnu/packages/node.scm (node): Update to 7.8.0.
---
 gnu/packages/node.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/node.scm b/gnu/packages/node.scm
index 2df7816b59..ed8e7338bf 100644
--- a/gnu/packages/node.scm
+++ b/gnu/packages/node.scm
@@ -38,14 +38,14 @@
 (define-public node
   (package
 (name "node")
-(version "6.8.0")
+(version "7.8.0")
 (source (origin
   (method url-fetch)
   (uri (string-append "http://nodejs.org/dist/v"; version
   "/node-v" version ".tar.gz"))
   (sha256
(base32
-"0lj3250hglz4w5ic4svd7wlg2r3qc49hnasvbva1v69l8yvx98m8"))
+"1nkngdjbsm81nn3v0w0c2aqx9nb7mwy3z49ynq4wwcrzfr9ap8ka"))
   ;; https://github.com/nodejs/node/pull/9077
   (patches (search-patches "node-9077.patch"
 (build-system gnu-build-system)
@@ -62,6 +62,7 @@
  ;; Fix hardcoded /bin/sh references.
  (substitute* '("lib/child_process.js"
 "lib/internal/v8_prof_polyfill.js"
+"test/parallel/test-child-process-spawnsync-shell.js"
 "test/parallel/test-stdio-closed.js")
(("'/bin/sh'")
 (string-append "'" (which "sh") "'")))
-- 
2.11.1

Planning for the next release

[Ludovic Courtès]

Hello Guix!

It’s time to plan for the next release!  Here’s what we maintainers
think should be done for the next release, which would hopefully happen
within less than a month:

   1. ‘core-updates’ merged.  We’re almost there!

   2. ‘wip-installer’ retested, and probably merged.

  I think the prerequisite for it would be to do some more testing.
  Last time people reported glitches here and there but John has
  done quite a bit of work since then.  John: what about doing
  another round of tests?

  In the installation image, we should probably make the installer
  optional and mark it as “beta” or something like that.  That will
  leave us time to iron out remaining issues, and will avoid having
  people expect a rock-solid Debian-style installer.

  As far as review is concerned, we can probably do a quick and
  lightweight review process since that’s quite a big chunk of code
  and we don’t want the branch to block indefinitely.  So we can do
  that quick process, and then incrementally improve it if needed.
  I think it’s a reasonable approach given that the installer is
  mostly an independent component.

  John, everyone: thoughts?

   3. UEFI support documented and possibly improved.

  We can certainly document the UEFI setup and add the /boot/efi
  partition in some of the ‘operating-system’ examples.

  The more difficult part is the installation: do we need to make a
  second, UEFI-specific, installation image?  When I installed
  GuixSD on UEFI, I booted our installation image as “legacy”, but
  then GRUB would default to a legacy install, not a UEFI install:

https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html

  I’m not sure exactly what needs to be done.  Thoughts?

   4. Fix low-hanging fruits at ; your help
  welcome!

Please share your thoughts!

Ludo’.


signature.asc
Description: PGP signature

[PATCH -v2] services: dict.scm: Support more dicod configuration

[Huang Ying]

* gnu/services/dict.scm (): Add handlers to configure
  handlers (module instances).
  (): Add new record type to describe handler (module instance).
  (): Add more fields.
  (dicod-configuration-file): Support convert handlers and enhanced databases
  configuration to config file.

* doc/guix.text: Add description of newly added dicod configuration.
---
 doc/guix.texi | 57 ++-
 gnu/services/dict.scm | 52 ++
 2 files changed, 96 insertions(+), 13 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 57595b95e..f1a063581 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -14370,25 +14370,49 @@ This is the list of IP addresses and ports and 
possibly socket file
 names to listen to (@pxref{Server Settings, @code{listen} directive,,
 dico, GNU Dico Manual}).
 
+@item @code{handlers} (default: @var{'()})
+List of @code{} objects denoting handlers (module instances).
+
 @item @code{databases} (default: @var{(list %dicod-database:gcide)})
 List of @code{} objects denoting dictionaries to be served.
 @end table
 @end deftp
 
-@deftp {Data Type} dicod-database
-Data type representing a dictionary database.
+@deftp {Data Type} dicod-handler
+Data type representing a dictionary handler (module instance).
 
 @table @asis
 @item @code{name}
-Name of the database, will be used in DICT commands.
+Name of the handler (module instance).
 
-@item @code{module}
-Name of the dicod module used by this database
+@item @code{module} (default: @var{#f})
+Name of the dicod module of the handler (instance).  If it is @code{#f},
+the module has the same name as the handler.
 (@pxref{Modules,,, dico, GNU Dico Manual}).
 
 @item @code{options}
 List of strings or gexps representing the arguments for the module handler
+@end table
+@end deftp
+
+@deftp {Data Type} dicod-database
+Data type representing a dictionary database.
+
+@table @asis
+@item @code{name}
+Name of the database, will be used in DICT commands.
+
+@item @code{handler}
+Name of the dicod handler (module instance) used by this database
 (@pxref{Handlers,,, dico, GNU Dico Manual}).
+
+@item @code{complex} (default: @var{#f})
+Whether the database configuration complex.  The complex configuration
+will need a corresponding @code{} object, otherwise not.
+
+@item @code{options}
+List of strings or gexps representing the arguments for the database
+(@pxref{Databases,,, dico, GNU Dico Manual}).
 @end table
 @end deftp
 
@@ -14397,6 +14421,29 @@ A @code{} object serving the GNU 
Collaborative International
 Dictonary of English using the @code{gcide} package.
 @end defvr
 
+The following is an example @code{dicod-service} configuration.
+
+@example
+(dicod-service #:config
+ (dicod-configuration
+  (handlers
+   (list
+(dicod-handler
+ (name "wordnet")
+ (module "dictorg")
+ (options
+  '("dbdir=/gnu/store/-wordnet")
+  (databases
+   (list
+(dicod-database
+ (name "wordnet")
+ (complex #t)
+ (handler "wordnet")
+ (options
+  '("database=wn")))
+%dicod-database:gcide
+@end example
+
 @subsubsection Version Control
 
 The @code{(gnu services version-control)} module provides the following 
services:
diff --git a/gnu/services/dict.scm b/gnu/services/dict.scm
index 303067037..596f901f3 100644
--- a/gnu/services/dict.scm
+++ b/gnu/services/dict.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016 Sou Bunnbu 
 ;;; Copyright © 2016 Ludovic Courtès 
+;;; Copyright © 2017 Huang Ying 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -32,6 +33,7 @@
   #:export (dicod-service
 dicod-service-type
 dicod-configuration
+dicod-handler
 dicod-database
 %dicod-database:gcide))
 
@@ -46,21 +48,30 @@
   (dicodicod-configuration-dico   (default dico))
   (interfaces  dicod-configuration-interfaces ;list of strings
(default '("localhost")))
-  (databases   dicod-configuration-databases
-   ;; list of 
+  (handlersdicod-configuration-handlers   ;list of 
+   (default '()))
+  (databases   dicod-configuration-databases  ;list of 
(default (list %dicod-database:gcide
 
+(define-record-type* 
+  dicod-handler make-dicod-handler
+  dicod-handler?
+  (namedicod-handler-name)
+  (module  dicod-handler-module  (default #f))
+  (options dicod-handler-options (default '(
+
 (define-record-type* 
   dicod-database make-dicod-database
   dicod-database?
   (namedicod-database-name)
-  (module  dicod-database-module)
+  (handler dicod-database-handler)
+  (complex dicod-database-complex(default #f))
   (options dicod-database-options(default '(
 
 (define %dicod-database:gcide
   (dicod-database
(name "gcide")
-   (module "gcide")
+   (handler "gcide")
(options (list 

Re: Let’s freeze and build ‘core-updates’!

[Thomas Danckaert]

From: Marius Bakke 
Subject: Re: Let’s freeze and build ‘core-updates’!
Date: Wed, 29 Mar 2017 15:41:56 +0200


For the rest.. please share your findings!


Perhaps this is not a “finding”, but just a positive anecdote: I 
reconfigured on core-updates and it's working fine (after an 
afternoon of building nss and webkitgtk).


I'm also happy with jmd's util-linux patch d9804e501 which allows 
mount to find helper programs “mount.”.  (I needed that to mount 
cifs/samba shares easily, don't know if anyone else has managed this 
on master?)


Thomas

[PATCH] profiles: Generate database file for manpages

[Maxim Cournoyer]

Hello Guix!

I've managed to finalize a profile hooks which takes care of generating
the manpages database file. This file is used by apropos or man -k to
provide results.

Thanks to Ludovic for providing me with a patch I could start from, this
greetly speeded things up!

I've tested and found it to be working for the regular user profile. To
try it, apply the patch and use a guix command that causes a new profile
generation.

For example: guix package -r git -i git
Then: "apropos git" should return plenty of results.

It requires extra processing time to do the work since the complete
database (on my system, there are thousands or manpages being indexed)
is recreated everytime a new profile is generated.

For now it doesn't work for guix environments (yet), but this should be
easy to fix (it seems the $GUIX_ENVIRONMENT/share/man should be merged
with $HOME/.guix-profile/share/man, but I need to look at it more
carefully).

Maxim
From dbbe6894919164cd34572a28bfbbf6d4d681e35b Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Tue, 28 Mar 2017 09:25:21 -0700
Subject: [PATCH] profiles: Generate database file for manpages
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The mandb database file (index.db) is used by the "apropos" (whatis) or
"man -k" commands. This change introduces a profile hook to generate
such database file.

Co-authored by Ludovic Courtès

* guix/profiles.scm (manual-database): New procedure.
(%default-profile-hooks): Add it.
---
 guix/profiles.scm | 76 +++
 1 file changed, 76 insertions(+)

diff --git a/guix/profiles.scm b/guix/profiles.scm
index 795c9447fe..eb746c125a 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2016 Ricardo Wurmus 
 ;;; Copyright © 2016 Chris Marusich 
 ;;; Copyright © 2017 Huang Ying 
+;;; Copyright © 2017 Maxim Cournoyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -946,10 +947,85 @@ files for the fonts of the @var{manifest} entries."
 #:local-build? #t
 #:substitutable? #f))
 
+(define (manual-database manifest)
+  (define man-db;lazy reference
+(module-ref (resolve-interface '(gnu packages man)) 'man-db))
+
+  (define build
+#~(begin
+(use-modules (guix build utils)
+ (srfi srfi-1))
+
+(define entries
+  (filter-map (lambda (directory)
+(let ((man (string-append directory "/share/man")))
+  (and (directory-exists? man)
+   man)))
+  '#$(manifest-inputs manifest)))
+
+(define manpages-collection-dir
+  (string-append (getenv "PWD") "/manpages-collection"))
+
+(define man-directory
+  (string-append #$output "/share/man"))
+
+(define man-db-config-orig
+  (string-append #+man-db "/etc/man_db.conf"))
+
+(define man-db-config
+  (string-append (getenv "PWD") "/man_db.conf"))
+
+(define (get-manpage-tail-path manpage-path)
+  (let ((index (string-contains manpage-path "/share/man/")))
+(substring manpage-path (+ index (string-length "/share/man/")
+
+(define (populate-manpages-collection-dir entries)
+  (let ((manpages (append-map (lambda (manpath)
+(find-files manpath))
+  entries)))
+(for-each (lambda (manpage)
+(let* ((dest-path (string-append
+   manpages-collection-dir "/"
+   (get-manpage-tail-path manpage)))
+   (dest-dir (dirname dest-path)))
+  (unless (file-exists? dest-dir)
+(mkdir-p dest-dir))
+  (catch 'system-error
+(lambda ()
+  (symlink manpage dest-path))
+(lambda args
+  ;; Different packages may contain the same
+  ;; manpage. Simply ignore the symlink error.
+  #t
+  manpages)))
+
+(mkdir-p manpages-collection-dir)
+(populate-manpages-collection-dir entries)
+
+;; Create a mandb config file which contains a custom made
+;; manpath. The associated catpath is the location where the database
+;; gets generated.
+(copy-file man-db-config-orig man-db-config)
+(substitute* man-db-config
+  (("MANDB_MAP	/usr/man		/var/cache/man/fsstnd")
+   (string-append "MANDB_MAP " manpages-collection-dir " "
+  man-directory)))
+
+(mkdir-p man-directory)
+(setenv "MANPATH" (string-join entries ":"))
+(zero? (syste

Re: Let’s freeze and build ‘core-updates’!

[Ricardo Wurmus]

The following packages are now fixed in core-updates:

* discrover
* hugs
* powertabeditor
* stringtie

-- 
Ricardo

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