Re: [PATCH] gnu: Add Nmap.

[Taylan Ulrich Bayırlı/Kammer]

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

> This is normally dealt with by using multiple outputs (info "(guix)
> Packages with Multiple Outputs").  An example of that is Git: the Tcl
> GUIs are moved to a separate output, and so is git-svn support, such
> that the main output does not depend on Tcl, libx11, Subversion, etc.

OK, will have a go at this.

It seems Zenmap doesn't need X11/GTK libraries (rather headers) at build
time because it only uses a Python GTK module.  This raises two general
questions for me:

1) Is it OK if users have to install additional packages for a given
   component of a package to work, or should all dependencies, even if
   purely run-time, be inputs?

2) If purely-run-time dependencies are inputs, won't that trigger
   unnecessary rebuilds of the package when a run-time dependency is
   updated?

(In this special case only question 2 applies, because the whole of
Zenmap is useless without GTK, not just a component of it.)

After some pondering, I would say:

1) There should be a way to run-time-depend on another package without
   it being a build input at all.  (The installation of these needn't be
   forced on the user, though in some cases like Zenmap it's senseless
   not to do so; we could have "dependencies" and "recommendations" and
   possibly more, like in Debian.)

2) When interface files of a dylib are needed during compilation of a
   static lang (e.g. C headers), a special for-building package should
   be used as input, thus the actual dylib can be updated without
   causing rebuilds.  (Until ABI compatibility breaks I guess.)

3) Similarly, when a program is needed purely at build-time, like Bash
   or SCons, a special for-building package should be used as input,
   thus the actual program can be updated without causing rebuilds.
   (The for-building package would be updated only when doing so will
   improve the builds, like when a newer GCC version optimizes better.)

4) The for-building packages in #3 should obviously not be installed on
   the user's machine (unless they build locally instead of using binary
   substitutes), meaning "build inputs" and "run-time dependencies" are
   fully orthogonal.

In the Nix manual I see the following, which possibly fixes #4 without
needing to separate build inputs from run-time dependencies in recipes:

"Runtime dependencies are found by scanning binaries for the hash parts
of Nix store paths (such as r8vvq9kq…). This sounds risky, but it works
extremely well."

Perhaps we already do that?  But otherwise, it seems like we could save
gigawatts of electricity over time with #1-3.  Please tell me if I'm
missing something obvious. :-)

Taylan

Re: [PATCH] HACKING: Mention 'guix environment'.

[David Thompson]

Ludovic Courtès  writes:

> David Thompson  skribis:
>
>> Just today I used 'guix environment guix' to quickly create a
>> development environment for Guix hacking.  I figured it should be
>> mentioned in the HACKING file to assist developers that happen to
>> already by using a Guix system.
>>
>> WDYT?
>
> Sure, please commit!  I thought I had done it, but no.
>
>> +If you are building Guix on a system that already runs Guix, you can use 
>> 'guix
>> +environment' to spawn a shell whose environment contains all of the 
>> necessary
>> +packages without installing them to your user profile:
>> +
>> +  guix environment guix
>
> This is true only when ‘guix’ refers to the development version, which
> has the autotools etc. as inputs.

Okay, so that's not always the case?  In that case, we could say:

  guix environment -e '(@@ (gnu packages package-management) guix-devel)'

> I think it would be nice to have a ‘--install’ option to specify
> additional packages to add to the environment, so that one could do
> (say):
>
>   guix environment mpc -i autoconf automake libtool
>
> and get a really complete development environment.
>
> (We discussed this on IRC some time ago, but I think we had overlooked
> this simple solution.)

I think that is a good idea in general, so I will work on adding it.

For this case, since there is already a guix-devel package, is it okay
to just refer to that?  It's simpler that needing to add '-i autoconf
automake libtool graphviz gettext'. Alternatively, we could maintain a
'development.scm' file specifically for this purpose, then you would
run:

  guix environment -l development.scm

Thoughts?

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

Re: Advice needed on gcc error

[Adam Pribyl]

On Sun, 23 Nov 2014, Ludovic Courtès wrote:


Adam Pribyl  skribis:


Great, this is it! I had
  (services (cons (dhcp-client-service)
   %base-services))
  (services (cons (lsh-service #:port-number 22 #:root-login? #t)
   %base-services))


Oh, OK.  Ideally an error would be raised in such a case.


Did not noticed any... guix system reconfigure just finished OK.



Just for the lsh - by default it expects a key under
/etc/lsh_host_key, while this service definition changes it to
/etc/ls/host-key.


OK.  Perhaps this should be mentioned in the manual?


/etc/lsh/host-key

Well it is mostly there as there is and option
[#:host-key "/etc/lsh/host-key"]
Just when one tries to start lshd manually it first prints it needs 
the yarrow seed, then host key in proper location etc. Host key location 
is different.


I would suggest improving the
http://www.gnu.org/software/guix/manual/guix.html#Using-the-Configuration-System
example and incorporating most of the options in the configuration example 
as e.g. starting lsh-service without [#:initialize? #f] for the first 
time makes no sense. Also it could be present in the config template in 
the distribution itself.


This would help most of us not very familiar with all the details to do a 
fluent installation.



Ludo’.


Regards

Adam Pribyl

Re: [PATCH] Hotfix (repeat)

[Ludovic Courtès]

Deck Pickard  skribis:

> From 8e297904d80b39cd510ba0cced37acdb9b1aeb89 Mon Sep 17 00:00:00 2001
> From: nebuli 
> Date: Sat, 22 Nov 2014 19:58:24 +0100
> Subject: [PATCH 2/4] guix build: Add --max-jobs option (without handling
>  code).
>
> * doc/guix.texi: Mention in the docs.
> * guix/scripts/build.scm: Extend (show-build-options-help) and
>   (%standard-build-options) functions.

Actually I had overlooked that this patch does nothing.   :-)

Could you send an updated version that passes the right option to
‘set-build-options’?

TIA,
Ludo’.

Re: Optional runtime dependencies in Guix

[Ludovic Courtès]

Hello,

Gammel Holte  skribis:

> Nix doesn't have a good decoupling between packages and their optional
> runtime dependencies. You can disable them, but this would lead to a
> different package hash, and thus a different build (negating the use of
> prebuilt binaries).
>
> Therefore, the culture seems to have all default package builds with all
> optional runtime dependencies on. This leads to situations such as
> installing mutt, and getting python as a dependency (via mutt -> gpgme ->
> glib -> python), which is quite ugly.

That’s indeed undesirable.

As I just wrote to Taylan Ulrich, this is currently handled on a
case-by-case basis using multiple outputs (which I think Nixpkgs doesn’t
use a lot yet.)

For instance, GLib has a separate “bin” output for this very reason (see
.)  Git, as I wrote, has separate outputs for
git-svn and Tcl stuff.  Same for WordNet.  There are also separate
outputs for debugging symbols.

So I wouldn’t claim this is a solved problem, because it really gets
fixed when we discover a problematic case, and we certainly overlook
some of them.  Yet, that’s something I pay attention to, and I think we
must clearly look to address more of such issues.

WDYT?

Thanks,
Ludo’.

Running X on Guix 0.8

[Omar Radwan]

I'm running Guix on one of my computers, I've installed icecat, xorg, and
windowmaker. I was wondering whether it was possible to run X.

Re: [PATCH] gnu: Add Nmap.

[Ludovic Courtès]

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> Andreas Enge  writes:
>
>> On Sat, Nov 22, 2014 at 11:05:35PM +0100, "Taylan Ulrich Bayırlı/Kammer" 
>> wrote:
>>> Many distros separate Zenmap from the Nmap package.  Should we do the
>>> same?  If yes, I'll need some help.  This recipe builds it together
>>> with the rest of the suite.
>>
>> Our general policy is to build as intended by upstream with as little
>> changes as possible. So unless there is a compelling reason to
>> separate the two, I would not do it.
>
> Hm, zenmap would pull in X.Org and all sorts of GUI things, which would
> be very annoying for someone who wants nmap on a headless server,
> embedded system, or the like.

Indeed.

This is normally dealt with by using multiple outputs (info "(guix)
Packages with Multiple Outputs").  An example of that is Git: the Tcl
GUIs are moved to a separate output, and so is git-svn support, such
that the main output does not depend on Tcl, libx11, Subversion, etc.

Would it work here?

Thanks,
Ludo’.

Re: [PATCH] doc: Add a section on naming conventions for font packages.

[Andreas Enge]

On Sun, Nov 23, 2014 at 11:12:21PM +0300, Alex Kost wrote:
> > +In the case where several formats of the same font family or font 
> > collection
> > +are packaged separately, a short form of the format, prepended by a dash,
> > +is added to the package name. We use @code{-ttf} for TrueType fonts,
> There should double space here  ↑ I think.

Thanks, added.

Periods at the end of a line are okay without extra spaces?

Andreas

Re: [PATCH] doc: Add a section on naming conventions for font packages.

[Ludovic Courtès]

Andreas Enge  skribis:

> I finally got around to word Ludovic's suggestion on names for font packages,
> which I think we agreed upon. Corrections are welcome.

This looks good to me.

Thanks for taking the time to write it down!

Ludo’.

Re: [PATCH] HACKING: Mention 'guix environment'.

[Ludovic Courtès]

David Thompson  skribis:

> Just today I used 'guix environment guix' to quickly create a
> development environment for Guix hacking.  I figured it should be
> mentioned in the HACKING file to assist developers that happen to
> already by using a Guix system.
>
> WDYT?

Sure, please commit!  I thought I had done it, but no.

> +If you are building Guix on a system that already runs Guix, you can use 
> 'guix
> +environment' to spawn a shell whose environment contains all of the necessary
> +packages without installing them to your user profile:
> +
> +  guix environment guix

This is true only when ‘guix’ refers to the development version, which
has the autotools etc. as inputs.

I think it would be nice to have a ‘--install’ option to specify
additional packages to add to the environment, so that one could do
(say):

  guix environment mpc -i autoconf automake libtool

and get a really complete development environment.

(We discussed this on IRC some time ago, but I think we had overlooked
this simple solution.)

WDYT?

Ludo’.

Re: Advice needed on gcc error

[Ludovic Courtès]

Adam Pribyl  skribis:

> Great, this is it! I had
>   (services (cons (dhcp-client-service)
>%base-services))
>   (services (cons (lsh-service #:port-number 22 #:root-login? #t)
>%base-services))

Oh, OK.  Ideally an error would be raised in such a case.

> Just for the lsh - by default it expects a key under
> /etc/lsh_host_key, while this service definition changes it to
> /etc/ls/host-key.

OK.  Perhaps this should be mentioned in the manual?

Ludo’.

Re: [PATCH] doc: Fix typos.

[Ludovic Courtès]

Alex Kost  skribis:

> I think I've noticed a couple of typos in the manual.
>
>
> From 68770c75ae8417807e58701e6537f552d7108bad Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sun, 23 Nov 2014 11:46:38 +0300
> Subject: [PATCH] doc: Fix typos.
>
> * doc/guix.texi (Base Services): Fix 'lsh-service' name.
>   (Networking Services): Fix (gnu services networking) module name.

Indeed, please push.

Thanks,
Ludo’.

Re: [PATCH] Hotfix (repeat)

[Ludovic Courtès]

Deck Pickard  skribis:

> Because google sucks, this time attaching the patches...

Indeed, this is much better than the mangled HTML version.  :-)

> From 5ad37d9ab4febcbec8bbae8f7c14d7a49683c771 Mon Sep 17 00:00:00 2001
> From: nebuli 
> Date: Sat, 22 Nov 2014 19:16:51 +0100
> Subject: [PATCH 1/4] store: default to serial "scheduler"
> Status: RO
> Content-Length: 1172
> Lines: 28
>
> * guix/store.scm (set-build-options): exchange default argument values

Applied.

> From 8e297904d80b39cd510ba0cced37acdb9b1aeb89 Mon Sep 17 00:00:00 2001
> From: nebuli 
> Date: Sat, 22 Nov 2014 19:58:24 +0100
> Subject: [PATCH 2/4] guix build: Add --max-jobs option (without handling
>  code).
>
> * doc/guix.texi: Mention in the docs.
> * guix/scripts/build.scm: Extend (show-build-options-help) and
>   (%standard-build-options) functions.

Applied; I adjusted guix.texi to use a description similar to that in
“Invoking guix-daemon”.

> From 49d5d2c5e60e10566b8e87ea7956e8775b1325bc Mon Sep 17 00:00:00 2001
> From: nebuli 
> Date: Sat, 22 Nov 2014 20:13:07 +0100
> Subject: [PATCH 3/4] guix: Add schedule module.
>
> * guix/schedule.scm: New file. To handle --cores and --max-jobs
>   options in 'guix build'.
> * Makefile.am (MODULES): Add *this.

[...]

> +(define-module (guix schedule)

[...]

> From d22504209d43080d04d798c960bd29f3d4891bd4 Mon Sep 17 00:00:00 2001
> From: nebuli 
> Date: Sat, 22 Nov 2014 20:25:11 +0100
> Subject: [PATCH 4/4] guix build: Try to handle --cores and --max-jobs in a

[...]

> +  (let ((sched (make-schedule-sane #:max-cores (assoc-ref opts 'cores)
> +   #:max-jobs  (assoc-ref opts 'max-jobs
> +(set-build-options store
> +   #:keep-failed? (assoc-ref opts 'keep-failed?)
> +   #:build-cores (schedule-max-cores sched)
> +   #:max-build-jobs (schedule-max-jobs sched)

I’m not sure what the goal is.  Should use be prevented from frying
their laptop even when that’s what they ask for?  I don’t think so.  :-)
WDYT?

Thank you!

Ludo’.

PS: I left “nebuli ” as the author of the commits under the
assumption that you preferred not to use your real name.  If I
that’s not the case, make sure to configure Git to use the name you
want to see there.

[PATCH] gnu: Add 'font-liberation'.

[Alex Kost]

Alex Kost (2014-11-20 10:09 +0300) wrote:

> Ludovic Courtès (2014-11-19 12:01 +0300) wrote:
>
>> I think there were a couple of packages submitted, notably the
>> Liberation font.
>>
>> What about resubmitting them following the agreed-upon naming
>> convention, Alex?
>
> Sure, I'm just waiting for the existing packages to be updated, because
> I don't fully understand how the liberation package should be named now.
> “font-liberation”?

Andreas "confirmed" this name in his font convention patch, so I am
resending the updated patch.

>From 93cf792c9ced8763251780cfa159fd999500c307 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Tue, 28 Oct 2014 09:44:16 +0300
Subject: [PATCH] gnu: Add 'font-liberation'.

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

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

Re: [PATCH] doc: Add a section on naming conventions for font packages.

[Alex Kost]

Thanks!

Andreas Enge (2014-11-23 20:27 +0300) wrote:

> I finally got around to word Ludovic's suggestion on names for font packages,
> which I think we agreed upon. Corrections are welcome.

[...]
> +In the case where several formats of the same font family or font collection
> +are packaged separately, a short form of the format, prepended by a dash,
> +is added to the package name. We use @code{-ttf} for TrueType fonts,
There should double space here  ↑ I think.

-- 
Alex

Claws-mail

[Julien Lepiller]

Hello,

here is the patch I was invited to write for claws-mail.

Julien Lepiller.

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


0002-gnu-Add-claws-mail.patch
Description: Binary data

Re: Gluglug X60 Guix howto

[David Thompson]

Alex Sassmannshausen  writes:

> Hello,
>
> I received a request for instructions on how to get Guix running as
> standalone on the Gluglug X60 — my work is ongoing (I haven't
> reconfigured the Grub BIOS, nor have I got wireless working yet), but
> a first draft may help other owners.
>
> You can read my experience at http://glean.eu/guix-gluglug.html.

Awesome!  The Gluglug X60 was the laptop I tested the Guix 0.7 release
image on.  I didn't document the process, so I'm glad that you are!

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

Re: 01/01: gnu: xf86-video-openchrome: Patch to correct build failure.

[Andreas Enge]

On Sun, Nov 23, 2014 at 06:13:59PM +0100, Ludovic Courtès wrote:
> Thanks for working on it!  In the future please use the same format as
> commit 1d18d87f to refer to the bug that is fixed; having a uniform way
> for that makes it easier to search for bug fixes, notably when preparing
> NEWS.

Okay! I must admit I saw it, but what I do not like about it is that when
you are on a bug with your web browser, you cannot just copy and paste
its address. For instance, the
   http://bugs.gnu.org/19119
of the bug report is redirected to
   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19119

I find it weird to need to type a URL by hand and potentially introduce
errors.

Andreas

[PATCH] doc: Add a section on naming conventions for font packages.

[Andreas Enge]

I finally got around to word Ludovic's suggestion on names for font packages,
which I think we agreed upon. Corrections are welcome.

Andreas


* doc/guix.texi (Fonts): New section.
  (Package naming): Reference the new section.
---
 doc/guix.texi | 40 
 1 file changed, 40 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index c0b9668..11ae2e9 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4745,6 +4745,7 @@ needed is to review and apply the patch.
 * Version Numbers::  When the name is not enough.
 * Python Modules::   Taming the snake.
 * Perl Modules:: Little pearls.
+* Fonts::Fond of fonts.
 @end menu
 
 @node Software Freedom
@@ -4796,6 +4797,8 @@ already part of the official project name.  But 
@pxref{Python
 Modules} and @ref{Perl Modules} for special rules concerning modules for
 the Python and Perl languages.
 
+Font package names are handled differently, @pxref {Fonts}.
+
 
 @node Version Numbers
 @subsection Version Numbers
@@ -4871,6 +4874,43 @@ are also prepended by @code{perl-}.  Such modules tend 
to have the word
 prefix.  For instance, @code{libwww-perl} becomes @code{perl-libwww}.
 
 
+@node Fonts
+@subsection Fonts
+
+For fonts that are in general not installed by a user for typesetting
+purposes, or that are distributed as part of a larger software package,
+we rely on the general packaging rules for software; for instance, this
+applies to the fonts delivered as part of the X.Org system or fonts that
+are part of TeX Live.
+
+To make it easier for a user to search for fonts, names for other packages
+containing only fonts are constructed as follows, independently of the
+upstream package name.
+
+The name of a package containing only one font family starts with
+@code{font-}; it is followed by the foundry name and a dash @code{-}
+if the foundry is known, and the font family name, in which spaces are
+replaced by dashes (and as usual, all upper case letters are transformed
+to lower case).
+For example, the Gentium font family by SIL is packaged under the name
+@code{font-sil-gentium}.
+
+For a package containing several font families, the name of the collection
+is used in the place of the font family name.
+For instance, the Liberation fonts consist of three families,
+Liberation Sans, Liberation Serif and Liberation Mono.
+These could be packaged separately under the names
+@code{font-liberation-sans} and so on; but as they are distributed together
+under a common name, we prefer to package them together as
+@code{font-liberation}.
+
+In the case where several formats of the same font family or font collection
+are packaged separately, a short form of the format, prepended by a dash,
+is added to the package name. We use @code{-ttf} for TrueType fonts,
+@code {-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
+fonts.
+
+
 
 @node Bootstrapping
 @section Bootstrapping
-- 
2.1.2

Gluglug X60 Guix howto

[Alex Sassmannshausen]

Hello,

I received a request for instructions on how to get Guix running as
standalone on the Gluglug X60 — my work is ongoing (I haven't
reconfigured the Grub BIOS, nor have I got wireless working yet), but
a first draft may help other owners.

You can read my experience at http://glean.eu/guix-gluglug.html.

HTH,

Alex

Re: 01/01: gnu: xf86-video-openchrome: Patch to correct build failure.

[Ludovic Courtès]

Andreas Enge  skribis:

> commit bc0b89bb3eca3adf35230d1fe7f89664762be4e8
> Author: Andreas Enge 
> Date:   Sun Nov 23 15:41:30 2014 +0100
>
> gnu: xf86-video-openchrome: Patch to correct build failure.
> 
> * gnu/packages/xorg.scm (xf86-video-openchrome): Add patch for build 
> failure
> with glibc-2.20. Fixes bug #18740.

Thanks for working on it!  In the future please use the same format as
commit 1d18d87f to refer to the bug that is fixed; having a uniform way
for that makes it easier to search for bug fixes, notably when preparing
NEWS.

Cheers,
Ludo’.

[PATCH] HACKING: Mention 'guix environment'.

[David Thompson]

Just today I used 'guix environment guix' to quickly create a
development environment for Guix hacking.  I figured it should be
mentioned in the HACKING file to assist developers that happen to
already by using a Guix system.

WDYT?

>From e03345616cd4325cec928d6a6c5f35cbc47eb330 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sun, 23 Nov 2014 08:06:21 -0500
Subject: [PATCH] HACKING: Mention 'guix environment'.

---
 HACKING | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/HACKING b/HACKING
index 0231c7d..ad816aa 100644
--- a/HACKING
+++ b/HACKING
@@ -21,6 +21,12 @@ addition to those mentioned in the installation instructions:
   - [[http://www.gnu.org/software/gettext/][GNU Gettext]]
   - [[http://www.graphviz.org/][Graphviz]]
 
+If you are building Guix on a system that already runs Guix, you can use 'guix
+environment' to spawn a shell whose environment contains all of the necessary
+packages without installing them to your user profile:
+
+  guix environment guix
+
 Run ‘./bootstrap’ to download the Nix daemon source code and to generate the
 build system infrastructure using autoconf.  It reports an error if an
 inappropriate version of the above packages is being used.
-- 
2.1.2


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

Re: [PATCH] gnu: Add Nmap.

[Taylan Ulrich Bayırlı/Kammer]

Andreas Enge  writes:

> On Sat, Nov 22, 2014 at 11:05:35PM +0100, "Taylan Ulrich Bayırlı/Kammer" 
> wrote:
>> Many distros separate Zenmap from the Nmap package.  Should we do the
>> same?  If yes, I'll need some help.  This recipe builds it together
>> with the rest of the suite.
>
> Our general policy is to build as intended by upstream with as little
> changes as possible. So unless there is a compelling reason to
> separate the two, I would not do it.

Hm, zenmap would pull in X.Org and all sorts of GUI things, which would
be very annoying for someone who wants nmap on a headless server,
embedded system, or the like.

Well, I didn't need to add any such inputs, and it built zenmap anyway,
but of course it won't run without those.  Does that mean I made a
mistake, or is it fine that users have to know what run-time
dependencies to install for certain components of packages to work?

It seems Debian recently split of ndiff as well, after which the nmap
package itself won't depend on Python either, and only has very slim
dependencies.  (I *did* have to input python-2 for it to build ndiff and
zenmap...)

This topic seems to tie in well with Gammel Holte's recent post on the
ML regarding how optional run-time dependencies will be handled in Guix.
Maybe we should wait for the outcome of that.  Or at least I'll need to
read up on Nix/Guix dependency handling, because I'm confused on what
should and shouldn't be an input.

Taylan

Re: Installing Guix with VirtualBox

[白熊]

On 2014年11月22日 18:27:51 GMT+03:00, David Thompson  
wrote:
>Check the output of 'ifconfig -a' to see what the device name is.  On
>my
>machine, it was 'enp5s0', not 'eth0'.

Thanks for the tip, that helped, it was also named differently in my case. 
--
白熊

Re: Advice needed on gcc error

[Adam Pribyl]

On Sat, 22 Nov 2014, Ludovic Courtès wrote:


Adam Pribyl  skribis:

Could you post your configuration?

I have something like this:

--8<---cut here---start->8---
 (services (cons* (slim-service)

  (avahi-service)
  (dbus-service (list avahi))

  ;; [...]

  (lsh-service #:root-login? #t)
  (dhcp-client-service)

  %base-services))
--8<---cut here---end--->8---

and ‘deco status networking’ shows the actual service.



Great, this is it! I had
  (services (cons (dhcp-client-service)
   %base-services))
  (services (cons (lsh-service #:port-number 22 #:root-login? #t)
   %base-services))

I understand now it was a nonsence. Using cons* and defining both under 
single service section works now.


Just for the lsh - by default it expects a key under /etc/lsh_host_key, 
while this service definition changes it to /etc/ls/host-key.



Thanks,
Ludo’.


Thanks a lot

Adam Pribyl

Re: [PATCH] gnu: Add Nmap.

[Andreas Enge]

On Sat, Nov 22, 2014 at 11:05:35PM +0100, "Taylan Ulrich Bayırlı/Kammer" wrote:
> Many distros separate Zenmap from the Nmap package.  Should we do the
> same?  If yes, I'll need some help.  This recipe builds it together
> with the rest of the suite.

Our general policy is to build as intended by upstream with as little changes
as possible. So unless there is a compelling reason to separate the two,
I would not do it.

Andreas

[PATCH] doc: Fix typos.

[Alex Kost]

I think I've noticed a couple of typos in the manual.

>From 68770c75ae8417807e58701e6537f552d7108bad Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Sun, 23 Nov 2014 11:46:38 +0300
Subject: [PATCH] doc: Fix typos.

* doc/guix.texi (Base Services): Fix 'lsh-service' name.
  (Networking Services): Fix (gnu services networking) module name.
---
 doc/guix.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index c0b9668..3fdab82 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -3904,7 +3904,7 @@ system, you will want to append services to @var{%base-services}, like
 this:
 
 @example
-(cons* (avahi-service) (lshd-service) %base-services)
+(cons* (avahi-service) (lsh-service) %base-services)
 @end example
 @end defvr
 
@@ -3967,7 +3967,7 @@ Run @var{udev}, which populates the @file{/dev} directory dynamically.
 @node Networking Services
 @subsubsection Networking Services
 
-The @code{(gnu system networking)} module provides services to configure
+The @code{(gnu services networking)} module provides services to configure
 the network interface.
 
 @cindex DHCP, networking service
-- 
2.1.3

Optional runtime dependencies in Guix

[Gammel Holte]

Hello,

I'm glad to see all interesting ideas from Nix being implemented as a DSL
on top of Scheme, which makes an awesome combination.

That said, I would like to bring up an issue I've faced multiple times
while using Nix, hoping that Guix can adopt a better solution here:
optional runtime dependencies.

Nix doesn't have a good decoupling between packages and their optional
runtime dependencies. You can disable them, but this would lead to a
different package hash, and thus a different build (negating the use of
prebuilt binaries).

Therefore, the culture seems to have all default package builds with all
optional runtime dependencies on. This leads to situations such as
installing mutt, and getting python as a dependency (via mutt -> gpgme ->
glib -> python), which is quite ugly.

Installing many unneeded packages in your system is undesirable for many
reasons. It has bothered me when using Nix in small embedded systems due to
resource limitations.

I haven't come up with any solution that also preserves purity. Perhaps one
needs to draw a line between what is a package dependency and what isn't.
In my option, a glib build is the same in the presence or absence of
python, just like firefox is the same whether you have flash installed or
not.

Alex.