Re: Running X on Guix 0.8
On Sun, 23 Nov 2014, Omar Radwan wrote: 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. I did not test it on 0.8 yet, but for 0.7 you have to start Xorg with module path to your profile like Xorg -modulepath /root/.guix-profile/lib/xorg/modules/ not sure if there is some more elegant way, but this worked. Adam Pribyl
make polkit work
IIUC, our `polkit' can't see actions/rules from other packages.
In NixOS[0], the hardcoded ${out}/share/polkit-1 is overwrited to
/var/run/current-system/sw/share/polkit-1, provided by system
packages.
Instead of take a similar path,
can we make a proper patch which will be accepted upstream?
The goal: (polkit-service (list udisks))
[0]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/polkit/default.nix
Installing the system from another distro
Hello, I've tried to install the Guix system from my current system (Arch Linux) where I use the Guix package manager: ./pre-inst-env guix system init /path/to/my-os-config.scm /mnt/guix Unfortunately it failed (os-config and the backtrace are attached). So I wonder: is installing from another distro supported? or the only right way is to use an usb image? Thanks in advance. (use-modules (gnu)) (operating-system (host-name hn) (timezone Europe/Paris) (bootloader (grub-configuration (device /dev/sda))) (file-systems (cons (file-system (device /dev/sda7) (mount-point /) (type ext4)) %base-file-systems)) (users (list (user-account (name al) (home-directory /home/al) (group users) (supplementary-groups '(wheel audio video)) Backtrace: In ice-9/boot-9.scm: 157: 17 [catch #t #catch-closure 85f7c10 ...] In unknown file: ?: 16 [apply-smob/1 #catch-closure 85f7c10] In ice-9/boot-9.scm: 63: 15 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 14 [eval # #] In ice-9/boot-9.scm: 2401: 13 [save-module-excursion #procedure 8606ca0 at ice-9/boot-9.scm:4045:3 ()] 4050: 12 [#procedure 8606ca0 at ice-9/boot-9.scm:4045:3 ()] 1724: 11 [%start-stack load-stack ...] 1729: 10 [#procedure 860c708 ()] In unknown file: ?: 9 [primitive-load /media/storage/src/guix/scripts/guix] In guix/ui.scm: 776: 8 [run-guix-command system init ...] In ice-9/boot-9.scm: 157: 7 [catch srfi-34 #procedure 8f7ceb0 at guix/ui.scm:217:2 () ...] 157: 6 [catch system-error ...] In guix/monads.scm: 469: 5 [run-with-store # ...] In guix/scripts/system.scm: 309: 4 [#procedure 92a7e10 at guix/scripts/system.scm:309:2 (store) #] In gnu/system.scm: 702: 3 [#procedure 9781150 at gnu/system.scm:702:2 (store) #] 449: 2 [#procedure 9781168 at gnu/system.scm:449:2 (store) #] 455: 1 [#procedure 8fd76e0 at gnu/system.scm:449:2 (services) (# # # # ...)] In unknown file: ?: 0 [concatenate (() () () () () () () () () ...)] ERROR: In procedure concatenate: ERROR: In procedure append: Wrong type argument in position 19 (expecting empty list): #f
Re: [PATCH] gnu: Add Nmap.
taylanbayi...@gmail.com (Taylan Ulrich Bayırlı/Kammer) skribis: 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. Thanks, that seems like the best option. 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? Yes. (There may be rare exceptions, but this is not one of them.) Here you want users to be able to run ‘zenmap’ (or whatever the command is called) and have it Just Work, regardless of whether they happen to have installed Python and Python-GTK as well. So that means that the zenmap (or nmap) package basically needs to “close over” these inputs, probably using ‘wrap-program’. 2) If purely-run-time dependencies are inputs, won't that trigger unnecessary rebuilds of the package when a run-time dependency is updated? It’s rarely be “purely run-time”. Normally, at the very least there’s a configure script that makes sure at build-time that the dependencies are satisfied, and a test suite that makes sure things work. 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 whole functional approach things means that bindings are static (again, there may be exceptions, but zenmap has nothing exceptional here.) 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.) You’re describing an imperative packaging system. This is fine, but it defeats the whole idea of functional packaging. :-) See http://nixos.org/docs/papers.html and http://gnu.org/s/guix/#documentation for the rationale. 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.) Build tools are listed in ‘native-inputs’. 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? Yes. That means that run-time dependencies are a strict subset of build-time dependencies. I hope this clarifies things. Otherwise let me know! Thanks, Ludo’.
Re: make polkit work
宋文武 iyzs...@gmail.com skribis:
IIUC, our `polkit' can't see actions/rules from other packages.
In NixOS[0], the hardcoded ${out}/share/polkit-1 is overwrited to
/var/run/current-system/sw/share/polkit-1, provided by system
packages.
Instead of take a similar path,
can we make a proper patch which will be accepted upstream?
Yes, I think it would best to have it honor $POLKIT_RULES_PATH and
$POLKIT_ACTIONS_PATH. Apparently this would have to be done in
src/polkitbackend/polkitbackendjsauthority.c and
src/polkitbackend/polkitbackendinteractiveauthority.c.
Could you try to do this?
Once we have this patch, we can start using it, and submit it upstream
for inclusion.
The goal: (polkit-service (list udisks))
Yes, that sounds like the right approach.
Thanks for looking into this!
Ludo’.
Re: [PATCH] Hotfix (repeat)
On 23 Nov 2014 21:49, Ludovic Courtès l...@gnu.org wrote: Deck Pickard deck.r.pick...@gmail.com skribis: From 8e297904d80b39cd510ba0cced37acdb9b1aeb89 Mon Sep 17 00:00:00 2001 From: nebuli nebu@kipple 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’? No. Using '-c 0 -M 0' fails with cryptic message. On a four core system innocent (and logically consistent, I mean, from the description of those options, one expects the daemon to do some load balancing) '-c 4 -M 4' ends up with the same annoying N^2 behaviour. As it is now, not using one of the options leads to sub-optimal saturation of the through-output by default. Not very impressive, if you want to attract hackers who are willing to spend their time and resources to actually build locally from source. After all it's the only way to test and find possible bugs on a wide set of possible configurations. If you want it right, either fix it yourself (and please think hard and carefully what to put in '-from-commandline' function if you want to expose both options to the user) or stop with the antics and apply the patch. I can live with constant branch rebasing, but will end users appreciate their machines locking up? I mean every proper Linux user is expected to tail their logs... Unimpressed, drp -- .sig place holder
[PATCH] gnu: xfig: Add 'wrap-xfig phase.
I would like to propose the attached patch for xfig. It makes xfig find its resource file so that it works properly. On a side note: I've noticed that wrap-program generates two wrappers. In fact I find the following files in .../bin/: xfig, .xfig-real and .xfig-wrap-01. What is the purpose of the latter? (This happens with all packages using wrap-program.) Regards, Fede From b420b54a2dc5b2f39bb439b900b178e24b6f4d80 Mon Sep 17 00:00:00 2001 From: Federico Beffa be...@fbengineering.ch Date: Mon, 24 Nov 2014 14:22:16 +0100 Subject: [PATCH] gnu: xfig: Add 'wrap-xfig phase. * gnu/packages/xfig.scm (xfig): Set XAPPLRESDIR environment variable to help xfig find the app-defaults resource files. --- gnu/packages/xfig.scm | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/gnu/packages/xfig.scm b/gnu/packages/xfig.scm index b154074..b637db7 100644 --- a/gnu/packages/xfig.scm +++ b/gnu/packages/xfig.scm @@ -1,5 +1,6 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2014 Eric Bavier bav...@member.fsf.org +;;; Copyright © 2014 Federico Beffa be...@fbengineering.ch ;;; ;;; This file is part of GNU Guix. ;;; @@ -118,7 +119,14 @@ (close-pipe in) (close-port out))) (zero? (system* make install.doc - %standard-phases) + (alist-cons-after + 'install 'wrap-xfig + (lambda* (#:key outputs #:allow-other-keys) + (let ((out (assoc-ref outputs out))) + (wrap-program (string-append out /bin/xfig) + `(XAPPLRESDIR suffix + (,(string-append out /etc/X11/app-defaults)) + %standard-phases)) (home-page http://xfig.org/;) (synopsis Interactive drawing tool) (description -- 1.8.4
Re: Running X on Guix 0.8
Can't I just use deco? On Nov 24, 2014 6:25 AM, Ludovic Courtès l...@gnu.org wrote: Currently the easiest way to get X running is to use ‘slim-service’: http://www.gnu.org/software/guix/manual/guix.html#X-Window Add it to the operating system declaration, like: (operating-system ;; ... (services (cons (slim-service) %base-services))) Then ‘guix system reconfigure config.scm’, restart, and the system should get straight to the graphical log-in screen (SLiM). HTH! Ludo’.
Re: [PATCH] gnu: xfig: Add 'wrap-xfig phase.
Federico Beffa writes: I would like to propose the attached patch for xfig. It makes xfig find its resource file so that it works properly. Thanks for looking into it. + (wrap-program (string-append out /bin/xfig) + `(XAPPLRESDIR suffix + (,(string-append out /etc/X11/app-defaults)) Could you align the arguments to wrap-program here? On a side note: I've noticed that wrap-program generates two wrappers. In fact I find the following files in .../bin/: xfig, .xfig-real and .xfig-wrap-01. What is the purpose of the latter? (This happens with all packages using wrap-program.) See commit de61113, and the discussion at https://lists.gnu.org/archive/html/guix-devel/2014-09/msg00190.html -- Eric Bavier Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
Libreoffice building (sort of)
Well currently the libreoffice package in wip-libreoffice branch, builds, installs and seems to work ok. Slightly worrying is that the first few builds crashed in one of LO's unittests. I added the line (setenv CPPUNITTRACE gdb --args) which I expected just to give me a backtrace to help me diagnose the problem. I was very surprised doing this, caused the package to build, test and install without error! -- A Heisenbug. Anyway, like I say, the package works, but is a bit rough. I suggest that some of the dependencies are tidied up, reviewed and pushed to master, and the deeper issues investigated later. Help doing this is welcome. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: Digital signature
Re: [PATCH] gnu: xfig: Add 'wrap-xfig phase.
On Mon, Nov 24, 2014 at 6:04 PM, Eric Bavier ericbav...@gmail.com wrote: Could you align the arguments to wrap-program here? Does this correspond to the expected alignment? (This is formatted by emacs. Indeed in the previous version I forgot to press TAB on a line.) See commit de61113, and the discussion at https://lists.gnu.org/archive/html/guix-devel/2014-09/msg00190.html OK Thanks, Fede From 608884dfbf6cf2995531dcfb16986ab972803db3 Mon Sep 17 00:00:00 2001 From: Federico Beffa be...@fbengineering.ch Date: Mon, 24 Nov 2014 14:22:16 +0100 Subject: [PATCH] gnu: xfig: Add 'wrap-xfig phase. * gnu/packages/xfig.scm (xfig): Set XAPPLRESDIR environment variable to help xfig find the app-defaults resource files. --- gnu/packages/xfig.scm | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/gnu/packages/xfig.scm b/gnu/packages/xfig.scm index b154074..6436e52 100644 --- a/gnu/packages/xfig.scm +++ b/gnu/packages/xfig.scm @@ -1,5 +1,6 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2014 Eric Bavier bav...@member.fsf.org +;;; Copyright © 2014 Federico Beffa be...@fbengineering.ch ;;; ;;; This file is part of GNU Guix. ;;; @@ -118,7 +119,14 @@ (close-pipe in) (close-port out))) (zero? (system* make install.doc - %standard-phases) + (alist-cons-after + 'install 'wrap-xfig + (lambda* (#:key outputs #:allow-other-keys) + (let ((out (assoc-ref outputs out))) + (wrap-program (string-append out /bin/xfig) + `(XAPPLRESDIR suffix + (,(string-append out /etc/X11/app-defaults)) + %standard-phases)) (home-page http://xfig.org/;) (synopsis Interactive drawing tool) (description -- 1.8.4
Re: [PATCH] gnu: xfig: Add 'wrap-xfig phase.
Federico Beffa writes: On Mon, Nov 24, 2014 at 6:04 PM, Eric Bavier ericbav...@gmail.com wrote: Could you align the arguments to wrap-program here? Does this correspond to the expected alignment? (This is formatted by emacs. Indeed in the previous version I forgot to press TAB on a line.) LGTM! Ok to push. -- Eric Bavier Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
Re: Libreoffice building (sort of)
John Darrington j...@darrington.wattle.id.au skribis: Well currently the libreoffice package in wip-libreoffice branch, builds, installs and seems to work ok. Wo0t! Excellent! Slightly worrying is that the first few builds crashed in one of LO's unittests. I added the line (setenv CPPUNITTRACE gdb --args) which I expected just to give me a backtrace to help me diagnose the problem. I was very surprised doing this, caused the package to build, test and install without error! -- A Heisenbug. How is $CPPUNITTRACE used exactly? If it’s used as in: sh -c $CPPUNITTRACE test-program then I’m surprised it works at all, because ‘gdb --args test-program’ just spawns an interactive GDB session. Any idea what happens? Anyway, like I say, the package works, but is a bit rough. I suggest that some of the dependencies are tidied up, reviewed and pushed to master, and the deeper issues investigated later. Help doing this is welcome. Sounds like a good plan! Ludo’.
Re: Libreoffice building (sort of)
On Mon, Nov 24, 2014 at 07:03:58PM +0100, Ludovic Court??s wrote: John Darrington j...@darrington.wattle.id.au skribis: Well currently the libreoffice package in wip-libreoffice branch, builds, installs and seems to work ok. Wo0t! Excellent! Slightly worrying is that the first few builds crashed in one of LO's unittests. I added the line (setenv CPPUNITTRACE gdb --args) which I expected just to give me a backtrace to help me diagnose the problem. I was very surprised doing this, caused the package to build, test and install without error! -- A Heisenbug. How is $CPPUNITTRACE used exactly? If it???s used as in: sh -c $CPPUNITTRACE test-program then I???m surprised it works at all, because ???gdb --args test-program??? just spawns an interactive GDB session. Any idea what happens? Yes, I was suprised too. Maybe it runs some preprepared script. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: Digital signature
Re: [PATCH 1/2] gnu: Add numpy
On Sat, Nov 22, 2014 at 6:21 PM, Ludovic Courtès l...@gnu.org wrote: Sounds like a good plan. Please find attached the first step with initial (bootstrap) numpy versions. I've tested that the packages build before changing define-public to define. Regards, Fede From 9be3873522b2c4b642a467e421bd8684068feb40 Mon Sep 17 00:00:00 2001 From: Federico Beffa be...@fbengineering.ch Date: Mon, 24 Nov 2014 20:51:29 +0100 Subject: [PATCH] gnu: Add numpy-bootstrap. * gnu/packages/python.scm (python-numpy-bootstrap, python2-numpy-bootstrap): New file-local variables. --- gnu/packages/python.scm | 59 + 1 file changed, 59 insertions(+) diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm index 3786604..7967201 100644 --- a/gnu/packages/python.scm +++ b/gnu/packages/python.scm @@ -35,6 +35,8 @@ #:use-module (gnu packages readline) #:use-module (gnu packages openssl) #:use-module (gnu packages elf) + #:use-module (gnu packages maths) + #:use-module (gnu packages gcc) #:use-module (gnu packages pkg-config) #:use-module (gnu packages databases) #:use-module (gnu packages zip) @@ -1873,3 +1875,60 @@ writing C extensions for Python as easy as Python itself.) (name python2-cython) (inputs `((python-2 ,python-2) ; this is not automatically changed + +;; This version of numpy is missing the documentation and is only used to +;; build matplotlib which is required to build numpy's documentation. +(define python-numpy-bootstrap + (package +(name python-numpy-bootstrap) +(version 1.9.1) +(source + (origin + (method url-fetch) + (uri (string-append mirror://sourceforge/numpy + /numpy- version .tar.gz)) + (sha256 +(base32 + 070ybfvpgfmiz2hs94x445hvkh9dh52nyi0m8jp5kdihgvhbnx80 +(build-system python-build-system) +(inputs + `((python-nose ,python-nose) + (atlas ,atlas))) +(native-inputs + `((gfortran ,gfortran-4.8))) +(arguments + `(#:phases + (alist-cons-before +'build 'set-environment-variables +(lambda* (#:key inputs #:allow-other-keys) + (let* ((atlas-threaded + (string-append (assoc-ref inputs atlas) + /lib/libtatlas.so)) + ;; On single core CPUs only the serial library is created. + (atlas-lib + (if (file-exists? atlas-threaded) + atlas-threaded + (string-append (assoc-ref inputs atlas) + /lib/libsatlas.so +(setenv ATLAS atlas-lib))) +;; Tests can only be run after the library has been installed and not +;; within the source directory. +(alist-cons-after + 'install 'check + (lambda _ + (with-directory-excursion /tmp + (zero? (system* python -c import numpy; numpy.test() + (alist-delete + 'check + %standard-phases) +(home-page http://www.numpy.org/;) +(synopsis Fundamental package for scientific computing with Python) +(description NumPy is the fundamental package for scientific computing +with Python. It contains among other things: a powerful N-dimensional array +object, sophisticated (broadcasting) functions, tools for integrating C/C++ +and Fortran code, useful linear algebra, Fourier transform, and random number +capabilities.) +(license bsd-3))) + +(define python2-numpy-bootstrap + (package-with-python2 python-numpy-bootstrap)) -- 1.8.4
Re: [PATCH] HACKING: Mention 'guix environment'.
David Thompson dthomps...@worcester.edu skribis: Ludovic Courtès l...@gnu.org writes: David Thompson dthomps...@worcester.edu 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)' You’re right that it will always work in practice, because there’ll always be a ‘guix-devel’ more recent than ‘guix’. So the wording above is OK. The problem I was raising does not really apply here; I’m shamelessly sidetracking, I admit. ;-) 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. OK. Ludo’.
Re: Advice needed on gcc error
Adam Pribyl pri...@lowlevel.cz skribis:
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.
I was uneasy having #:initialize? default to #t. That would work, but
I’d rather have people create key handle that explicitly by themselves,
because it’s pretty sensitive, #:initialize? runs ‘lsh-make-seed’ with
--sloppy, which is not so great, and they might want to reuse existing
keys, etc.
To begin with, I’ve clarified the documention, with links to the lsh
manual (patch below.)
Thanks for the suggestion,
Ludo’.
commit aba747bda84d99fc7dc7b5ff40562217d6d304dc (HEAD, refs/heads/master)
Author: Ludovic Courtès l...@gnu.org
Date: Mon Nov 24 21:15:40 2014 +0100
doc: Add xrefs to the lsh manual.
Suggested by Adam Pribyl pri...@lowlevel.cz.
* gnu/services/ssh.scm (lsh-service): Update docstring with xrefs to
the lsh manual. Fix typos.
* doc/guix.texi (Networking Services): Synchronize.
Modified doc/guix.texi
diff --git a/doc/guix.texi b/doc/guix.texi
index a2f881f..3d49f7d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4033,12 +4033,17 @@ When @var{initialize?} is true, automatically create the seed and host key
upon service activation if they do not exist yet. This may take long and
require interaction.
+When @var{initialize?} is false, it is up to the user to initialize the
+randomness generator (@pxref{lsh-make-seed,,, lsh, LSH Manual}), and to create
+a key pair with the private key stored in file @var{host-key} (@pxref{lshd
+basics,,, lsh, LSH Manual}).
+
When @var{interfaces} is empty, lshd listens for connections on all the
network interfaces; otherwise, @var{interfaces} must be a list of host names
or addresses.
-@var{allow-empty-passwords?} specifies whether to accepts log-ins with empty
-passwords, and @var{root-login?} specifies whether to accepts log-ins as
+@var{allow-empty-passwords?} specifies whether to accept log-ins with empty
+passwords, and @var{root-login?} specifies whether to accept log-ins as
root.
The other options should be self-descriptive.
Modified gnu/services/ssh.scm
diff --git a/gnu/services/ssh.scm b/gnu/services/ssh.scm
index 5fc98e9..2b52c77 100644
--- a/gnu/services/ssh.scm
+++ b/gnu/services/ssh.scm
@@ -91,12 +91,17 @@ When @var{initialize?} is true, automatically create the seed and host key
upon service activation if they do not exist yet. This may take long and
require interaction.
+When @var{initialize?} is false, it is up to the user to initialize the
+randomness generator (@pxref{lsh-make-seed,,, lsh, LSH Manual}), and to create
+a key pair with the private key stored in file @var{host-key} (@pxref{lshd
+basics,,, lsh, LSH Manual}).
+
When @var{interfaces} is empty, lshd listens for connections on all the
network interfaces; otherwise, @var{interfaces} must be a list of host names
or addresses.
-@var{allow-empty-passwords?} specifies whether to accepts log-ins with empty
-passwords, and @var{root-login?} specifies whether to accepts log-ins as
+@var{allow-empty-passwords?} specifies whether to accept log-ins with empty
+passwords, and @var{root-login?} specifies whether to accept log-ins as
root.
The other options should be self-descriptive.
Re: Claws-mail
Julien Lepiller jul...@lepiller.eu skribis: here is the patch I was invited to write for claws-mail. Thanks for honoring the invitation. ;-) From b920081174eb3f4e0a04157efb6f83e1b984dd68 Mon Sep 17 00:00:00 2001 From: Julien Lepiller jul...@lepiller.eu Date: Sat, 22 Nov 2014 10:34:07 +0100 Subject: [PATCH 1/2] gnu: Add libetpan. * gnu/packages/mail.scm (libetpan): New variable. Applied, with a comment explaining why inputs need to be propagated. From 1ca24d2a820034b3c75261807f73c4770c9fe2f7 Mon Sep 17 00:00:00 2001 From: Julien Lepiller jul...@lepiller.eu Date: Sun, 23 Nov 2014 01:48:53 +0100 Subject: [PATCH 2/2] gnu: Add claws-mail. * gnu/packages/mail.scm (claws-mail): New variable. Applied. Thanks! Ludo’.
Re: [PATCH] gnu: Add Nmap.
l...@gnu.org (Ludovic Courtès) writes: So that means that the zenmap (or nmap) package basically needs to “close over” these inputs, probably using ‘wrap-program’. Thanks for the pointer; I'll look into 'wrap-program'. 2) If purely-run-time dependencies are inputs, won't that trigger unnecessary rebuilds of the package when a run-time dependency is updated? It’s rarely be “purely run-time”. Normally, at the very least there’s a configure script that makes sure at build-time that the dependencies are satisfied, and a test suite that makes sure things work. You're right; now that I think of it, it's probably a bug that Nmap's build process doesn't check for the presence of a GTK module. I'll talk to their developers to clarify. (ML thread should pop up at the bottom of http://seclists.org/nmap-dev/2014/q4/index.html soon.) 1) There should be a way to run-time-depend on another package without it being a build input at all. The whole functional approach things means that bindings are static That's a neat analogy. :-) However, we needn't recompile C code when there's an update to some dynlang library the program uses, do we? Then again, we want to re-run a potential test suite that might be using that library. I guess it's OK to be conservative for now, until One Day™ we can be more precise and separate testing from building... (If that day comes though, we better find a way to automatically discern run-time-only inputs. (Regarding test suites to be run-time too.) Otherwise we'll have a lot to do.) Also, configure scripts that check for such dynlang libraries' presence might become a problem. I imagine one could provide some for-building version of said library that's merely of the same major version, to shut up the configure script, since it only gets in the way in this case. (Complaining about the lack of a run-time dependency, at build-time... Yes, above I said *not* doing this is probably a bug in Nmap's build process, but for us it would become an annoyance.) Alternatively, the script might simply take a flag telling it to enable a feature even if it can't find a run-time dependency; I don't how many configure scripts have this. 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.) You’re describing an imperative packaging system. This is fine, but it defeats the whole idea of functional packaging. :-) See http://nixos.org/docs/papers.html and http://gnu.org/s/guix/#documentation for the rationale. Same thing as above really. Until the ABI of a dylib changes, updates to it needn't ignite recompilation of C code which uses that lib; it won't affect the compiler output anyway. (Tell me if I'm technically wrong; not an expert on C compilation etc.) But again, test suites... It does sound like breaking functional purity, but is it really so when an input has *no* effect on a build process other than the test suite? Once the test suite is separated, the real package and for-building package become operationally equivalent under the given build process, so providing one in place of the other would be a correctness preserving optimization. :-) 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.) Build tools are listed in ‘native-inputs’. Ah, thanks for clarifying. (BTW 'native-inputs' seems undocumented.) In that case, we should already be able to do at least this, no? (The other ideas are sadly high up in the air.) It could have prevented world-rebuilds upon the bash security patches, for example. (Given it's acceptable to use a buggy (even security-holy) Bash for some ./configure scripts and the like, so long as it doesn't break specifically them.) 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? Yes. That means that run-time dependencies are a strict subset of build-time dependencies. I see. One confusion remains: wouldn't that mean it would drop a dependency such as the Python GTK module in our case, because its hash doesn't appear anywhere, and instead it's only referenced by module name which is expected to be in some Python load path at run-time? Thanks a lot and sorry for taking your time! I might be dumping out many dubious ideas. Taylan
Re: [PATCH] gnu: Add rtorrent and libtorrent.
taylanbayi...@gmail.com (Taylan Ulrich Bayırlı/Kammer) skribis: From 608d40907185b70bb4256ee48afecc3cc93e771b Mon Sep 17 00:00:00 2001 From: Taylan Ulrich B taylanbayi...@gmail.com Date: Sat, 22 Nov 2014 15:49:07 +0100 Subject: [PATCH 1/2] gnu: Add libTorrent. * gnu/packages/bittorrent.scm (libtorrent): New variable. Applied. [...] +(home-page http://libtorrent.rakshasa.no/;) +(license l:gpl2))) I changed it to ‘gpl2+’ since that’s what the file headers say. Thanks, Ludo’.
Re: [PATCH 1/2] gnu: Add numpy
Federico Beffa be...@ieee.org skribis: Please find attached the first step with initial (bootstrap) numpy versions. I've tested that the packages build before changing define-public to define. OK. Note that you can also test once it’s private, with guix build -e '(@@ (gnu packages python) python-numpy-bootstrap)' From 9be3873522b2c4b642a467e421bd8684068feb40 Mon Sep 17 00:00:00 2001 From: Federico Beffa be...@fbengineering.ch Date: Mon, 24 Nov 2014 20:51:29 +0100 Subject: [PATCH] gnu: Add numpy-bootstrap. * gnu/packages/python.scm (python-numpy-bootstrap, python2-numpy-bootstrap): New file-local variables. LGTM, please push. Thank you, Ludo’.
Re: [PATCH 1/2] gnu: Add numpy
On Mon, Nov 24, 2014 at 10:06 PM, Ludovic Courtès l...@gnu.org wrote: OK. Note that you can also test once it’s private, with guix build -e '(@@ (gnu packages python) python-numpy-bootstrap)' OK, thanks. Will keep in mind for the future. LGTM, please push. Pushed.Thanks. Fede
Re: Gluglug X60 Guix howto
Alex Sassmannshausen alex.sassmannshau...@gmail.com wrote .. 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 This it great - Thanks! Can you please make it available under an appropriate Free license [0]? [0] http://freedomdefined.org/Licenses#Comparison_of_Licenses signature.asc Description: PGP signature
Re: [PATCH 01/13] gnu: subversion: Propagate env variables to hooks.
On Sat, Nov 22, 2014 at 5:02 AM, Ludovic Courtès l...@gnu.org wrote: Eric Bavier ericbav...@gmail.com skribis: On Fri, Nov 21, 2014 at 4:24 PM, Eric Bavier ericbav...@gmail.com wrote: Ludovic Courtès writes: Eric Bavier ericbav...@gmail.com skribis: * gnu/packages/patches/subversion-propagate-env-to-hooks.patch: New patch. * gnu-system.am (dist_patch_DATA): Add it. * gnu/packages/version-control.scm (subversion): Use it. [...] +++ b/gnu/packages/patches/subversion-propagate-env-to-hooks.patch @@ -0,0 +1,14 @@ +* Hooks need to inherit environment variables such as PATH, otherwise simple + things like `ls` might fail in a hook. That looks good, but I want to make sure we’re not changing something that was purposefully made this way. If the behavior is similar in 1.8.10, I'll get in contact with the developers. According to the subversion documentation, the desired behavior is to execute hooks in an empty environment for security reasons (see http://svnbook.red-bean.com/en/1.7/svn.reposadmin.create.html#svn.reposadmin.create.hooks ). OK, so I think it’s important to stick to this behavior. Agreed. So it looks like this is a small bug in libtool. The wrapper scripts libtool generates for programs use `ls' to resolve symbolic links and is the only utility program invoked without an absolute file name (the only other utility being sed). If such a wrapper script is executed with no PATH set, then we get ls: command not found errors. I don't think it's unreasonable to expect libtool's wrappers to be able to execute in an empty environment. I see. So the patch is there “just” to allow tests to run, right? Only for tests to pass, yes. Second, the problem should affect everyone, including FHS systems, no? The culprit, I think, is a small difference in behavior of bash. If PATH is unset (such as within svn's hook environment), then `bash -c 'echo $PATH'` on an FHS system prints something like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, but Guix's bash prints /no-such-path. In the first case, `ls` will resolve to /bin/ls, but will not be found in the second. How do people work around it? Given that behavior, people have nothing to work around. Does Nix's bash behave differently? I'm not sure that our bash needs to be changed in any way. It's current behavior seems in line with Guix's way of things. I was able to get the tests to pass by simply patching the references to ls that libtool emits in its wrappers. I think this might be the way to go for now, while also submitting a bug to libtool. Thoughts? `~Eric -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
