Re: reproducibility
On Wed, 13 Jan 2016 09:13:25 +0100 Federico Beffawrote: > On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès wrote: > [...] > [...] > [...] > [...] > [...] > [...] > [...] > > Just out of curiosity, could you provide a concrete example where the > order is purposefully specified. > > Thanks, > Fede > I haven't had time (since reading this) to test if the order matters or not, but some of the openstack packages say they care about order: https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/test-requirements.txt?h=2.0.0 -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted pgp_V1HtrtbD9.pgp Description: OpenPGP digital signature
Re: reproducibility
On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtèswrote: > Federico Beffa skribis: > >> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès wrote: >>> Federico Beffa skribis: >>> I've noticed that a derivation is a function of the order of the inputs. As an example, the following two input orders give rise to two distinct derivations: A) (inputs `(("texlive" ,texlive) ("texinfo" ,texinfo) ("m4" ,m4) ("libx11" ,libx11)) B) (inputs `(("texinfo" ,texinfo) ("texlive" ,texlive) ("m4" ,m4) ("libx11" ,libx11)) Is this intentional? >>> >>> Yes. There are several places where order matters, most importantly >>> search paths, and these are computed from the input lists. >> >> If order matters, it would probably be more robust to force internally >> a specific order rather than relying on the (often random) order >> defined in a package recipe (possibly created by an importer, ...). > > Most of the time any order would work, but I can imagine situations > where the packager could purposefully choose a specific order. So I’d > rather not do any automatic sorting, if that’s what you have in mind. Just out of curiosity, could you provide a concrete example where the order is purposefully specified. Thanks, Fede
Re: reproducibility
Federico Beffaskribis: > On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès wrote: >> Federico Beffa skribis: >> >>> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès wrote: Federico Beffa skribis: > I've noticed that a derivation is a function of the order of the > inputs. As an example, the following two input orders give rise to two > distinct derivations: > > A) > > (inputs > `(("texlive" ,texlive) >("texinfo" ,texinfo) >("m4" ,m4) >("libx11" ,libx11)) > > B) > (inputs > `(("texinfo" ,texinfo) >("texlive" ,texlive) >("m4" ,m4) >("libx11" ,libx11)) > > Is this intentional? Yes. There are several places where order matters, most importantly search paths, and these are computed from the input lists. >>> >>> If order matters, it would probably be more robust to force internally >>> a specific order rather than relying on the (often random) order >>> defined in a package recipe (possibly created by an importer, ...). >> >> Most of the time any order would work, but I can imagine situations >> where the packager could purposefully choose a specific order. So I’d >> rather not do any automatic sorting, if that’s what you have in mind. > > Just out of curiosity, could you provide a concrete example where the > order is purposefully specified. No specific example, sorry, but it’s plausible IMO. With enough CPU power, we could try rebuilding everything with a random order and see what breaks. Thanks, Ludo’.
Re: [PATCHES] Update orfm and package test requirements.
Hi, I've been a little while responding as I intending on releasing a new OrfM version before bothering you again. I'd push all this myself but wanted to check one last thing so I don't sound too enthusiastic about my own software. + +(define-public ruby-bio-commandeer + (package +(name "ruby-bio-commandeer") +(version "0.1.2") +(source + (origin + (method url-fetch) + (uri (rubygems-uri "bio-commandeer" version)) + (sha256 +(base32 + "061jxa6km92qfwzl058r2gp8gfcsbyr7m643nw1pxvmjdswaf6ly" +(build-system ruby-build-system) +(arguments + `(#:phases + (modify-phases %standard-phases + (replace 'check + ;; Run test without calling 'rake' so that jeweler is + ;; not required as an input. + (lambda _ + (zero? (system* "rspec" "spec/bio-commandeer_spec.rb"))) +(propagated-inputs + `(("ruby-bio-logger" ,ruby-bio-logger) + ("ruby-systemu" ,ruby-systemu))) +(native-inputs + `(("bundler" ,bundler) + ("ruby-rspec" ,ruby-rspec))) +(synopsis "Simplified running of shell commands from within Ruby") +(description + "Bio-commandeer is a dead simple opinionated method of running shell +commands from within Ruby. The advantage of bio-commandeer over other methods +of running external commands is that when something goes wrong, the error +message that is reported gives extra detail to ease debugging.") I don’t really like the first sentence. How about “Bio-comandeer lets you run shell commands from within Ruby. ...” That wasn't the best sentence before, fo so. I wonder if the replacement is a little bland though. How about (as attached), + "Bio-commandeer provides an opinionated method of running shell commands +from within Ruby. The advantage of bio-commandeer over other methods of +running external commands is that when something goes wrong, the @code{STDOUT} +and @code{STDERR} are reported, giving extra detail to ease debugging.") OK? I made scattered other changes too on top of accepting your suggestions, but I don't imagine a full re-review is necessary. Thanks for the review. ben >From 5d535f5c465c947140a2917fb9c0aaa31b651102 Mon Sep 17 00:00:00 2001 From: Ben WoodcroftDate: Sat, 21 Nov 2015 10:37:34 +1000 Subject: [PATCH 3/3] gnu: orfm: Update to 0.5.3. * gnu/packages/bioinformatics.scm (orfm): Update to 0.5.3. [native-inputs]: Add inputs required for tests. [description]: Add commas. --- gnu/packages/bioinformatics.scm | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm index 82506c1..9c2223f 100644 --- a/gnu/packages/bioinformatics.scm +++ b/gnu/packages/bioinformatics.scm @@ -2079,7 +2079,7 @@ that a read originated from a particular isoform.") (define-public orfm (package (name "orfm") -(version "0.4.1") +(version "0.5.3") (source (origin (method url-fetch) (uri (string-append @@ -2087,12 +2087,16 @@ that a read originated from a particular isoform.") version "/orfm-" version ".tar.gz")) (sha256 (base32 -"05fmw145snk646ly076zby0fjav0k7ysbclck5d4s9pmgcfpijc2" +"0vb6d771gl4mix8bwx919x5ayy9pkj44n7ki336nz3rz2rx4c7gk" (build-system gnu-build-system) (inputs `(("zlib" ,zlib))) +(native-inputs + `(("ruby-bio-commandeer" ,ruby-bio-commandeer) + ("ruby-rspec" ,ruby-rspec) + ("ruby" ,ruby))) (synopsis "Simple and not slow open reading frame (ORF) caller") (description - "An ORF caller finds stretches of DNA that when translated are not + "An ORF caller finds stretches of DNA that, when translated, are not interrupted by stop codons. OrfM finds and prints these ORFs.") (home-page "https://github.com/wwood/OrfM;) (license license:lgpl3+))) -- 2.6.3 >From 4ded5e53c22ada399c976989dbe10cbf376c4e98 Mon Sep 17 00:00:00 2001 From: Ben Woodcroft Date: Sat, 21 Nov 2015 10:03:41 +1000 Subject: [PATCH 2/3] gnu: Add ruby-bio-commandeer. * gnu/packages/ruby.scm (ruby-bio-commandeer): New variable. --- gnu/packages/ruby.scm | 35 +++ 1 file changed, 35 insertions(+) diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm index 21f282a..59fe1cd 100644 --- a/gnu/packages/ruby.scm +++ b/gnu/packages/ruby.scm @@ -2958,3 +2958,38 @@ there is no danger of full pipes or threading issues hanging your process or subprocess.") (home-page "https://github.com/ahoward/systemu;) (license license:ruby))) + +(define-public ruby-bio-commandeer + (package +(name "ruby-bio-commandeer") +(version "0.1.2") +(source + (origin + (method url-fetch) + (uri (rubygems-uri "bio-commandeer" version)) + (sha256 +(base32 +
Re: [PATCH 3/4] gnu: emacs: Find packages in "~/.guix-profile".
Alex Kostskribis: > Ludovic Courtès (2016-01-10 23:28 +0300) wrote: [...] >> Also, on GuixSD, should we remove the default EMACSLOADPATH as well as >> /etc/emacs/site-start.el? > > If the goal for GuixSD is just to make Emacs packages work, then yes; > but if the intention is also to make "M-x guix-..." commands work > out-of-the-box, then we should leave it as it is now. Oh right; we should leave it as is. Thanks, Ludo’.
PulseAudio
Leo Famulariskribis: > I guess the factors are: > 1) Does GuixSD have a default audio setup that we should target? If > GuixSD uses PulseAudio, then I think it would be good for eSpeak to be > integrated into that sytem. > 2) Does this package, which launches PulseAudio, work for anyone on a > foreign distro? It’s not written anywhere, but I think most of our audio packages target PulseAudio (that’s what I use on GuixSD.) I’m in favor of consistently using it, and it would probably be best to write it down in the manual. Thoughts? Ludo’.
Re: [PATCHES] Update orfm and package test requirements.
Ben Woodcroftwrites: >> “Bio-comandeer lets you run shell commands from within Ruby. ...” > That wasn't the best sentence before, fo so. I wonder if the replacement > is a little bland though. How about (as attached), > > + "Bio-commandeer provides an opinionated method of running shell > commands > +from within Ruby. The advantage of bio-commandeer over other methods of > +running external commands is that when something goes wrong, the > @code{STDOUT} > +and @code{STDERR} are reported, giving extra detail to ease debugging.") This is almost okay, I think. I would add a couple of words to state that messages or text *printed* to STDOUT/STDERR (rather than the streams themselves) are reported. > From b7d92cbfd47fa9f4807ea72d570d703b78fb59f7 Mon Sep 17 00:00:00 2001 > From: Ben Woodcroft > Date: Sat, 21 Nov 2015 10:02:11 +1000 > Subject: [PATCH 1/3] gnu: Add ruby-systemu. > * gnu/packages/ruby.scm (ruby-systemu): New variable. [...] > +(arguments > + `(#:phases > + (modify-phases %standard-phases > + (add-before 'check 'patch-and-set-version > + (lambda _ > + (setenv "VERSION" ,version) > + #t) That’s an odd phase name; why “patch”? Is setting the environment variable the only way to set the version or would a make-flag work here, too? (I haven’t checked if the ruby-build-system respects make-flags.) The rest looks good to me. Thanks! ~~ Ricardo
gnunet-gtk (wip, open for others to debug)
As mentioned earlier in #guix, here is the most current version of gnune t-gtk I am stuck with debugging. Due to lack of time and documentation I forgot where it is failing, but it is just a matter of getting the arguments to 'make' right iirc. ricardo wanted to take this over. Something currently looks like lines are broken, so I attach the .patch itself. >From 41a4b5b4f7c3cfc4bd2afedc0da9b256eca7b16b Mon Sep 17 00:00:00 2001 From: Ni* GillmannDate: Wed, 13 Jan 2016 18:36:31 +0100 Subject: [PATCH] gnu/packages/gnunet gnunet-gtk added This is the most recent, almost building commit of gnunet-gtk Compare to https://notabug.org/anonymiss/libertad-overlay/src/master/net-misc for a building version (ebuild, on gentoo) and requirements. This patch tries to build and work with the guix provided version of gladeui, in its current state it fails and I want other people with more experience in the guix ecosystem to finish it. --- gnu/packages/gnunet.scm | 39 +++ 1 file changed, 39 insertions(+) diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm index 11e5aa8..91bbe1f 100644 --- a/gnu/packages/gnunet.scm +++ b/gnu/packages/gnunet.scm @@ -3,6 +3,7 @@ ;;; Copyright © 2014 Sree Harsha Totakura ;;; Copyright © 2015 Ludovic Courtès ;;; Copyright © 2015 Efraim Flashner +;;; Copyright © 2016 Ni* Gillmann ;;; ;;; This file is part of GNU Guix. ;;; @@ -286,3 +287,41 @@ GNUnet services, including the @dfn{identity} and @dfn{file sharing} services.") (home-page "http://gnu.org/software/guix;) (license license:gpl3+ + +(define-public gnunet-gtk + (package +(name "gnunet-gtk") +(version "0.10.1") +(source + (origin + (method url-fetch) + (uri (string-append "mirror://gnu/gnunet/gnunet-gtk-" version + ".tar.gz")) + (sha256 +(base32 + "1p38k1s6a2fmcfc9a7cf1zrdycm9h06kqdyand4s3k500nj6mb4g" +(build-system gnu-build-system) +(inputs + `(("gnunet" ,gnunet) + ("gtk+" ,gtk+-2) + ("libextractor" ,libextractor) + ("glade3" ,glade3) + ("qrencode" ,qrencode))) + ;;("libunique" ,libunique) +(native-inputs + `(("pkg-config" ,pkg-config) + ("libglade" ,libglade))) + (arguments +`(#:configure-flags '("--without-libunique" "--with-gtk+-2" + "--with-gnunet=/usr" "--with-qrencode") +%standard-phases)) +(synopsis "Graphical front-end tools for GNUnet") +(description + "Gnunet-gtk provides the gnunet-setup tool. Gnunet-setup can be used to +configure and test the network settings, choose which applications should be +run and configure databases. Other options include system-limitations +such as disk space consumption, bandwidth, etc. The resulting configuration +files are human-readable and can theoretically be created or edited by hand. +For more information, read https://gnunet.org/svn/gnunet-gtk/README;) +(license license:gpl3+) +(home-page "https://gnunet.org/;))) -- 2.6.3 -- Ni* -- https://www.libertad.pw Email is public. Talk to me in private: https://psyced.org:34443/~niasterisk privacy respecting, secure communication: BM-2cSj8qEigE3CMaLU3CwPZf7T3LvzvnttsC (bitmessage)From 41a4b5b4f7c3cfc4bd2afedc0da9b256eca7b16b Mon Sep 17 00:00:00 2001 From: Ni* Gillmann Date: Wed, 13 Jan 2016 18:36:31 +0100 Subject: [PATCH] gnu/packages/gnunet gnunet-gtk added This is the most recent, almost building commit of gnunet-gtk Compare to https://notabug.org/anonymiss/libertad-overlay/src/master/net-misc for a building version (ebuild, on gentoo) and requirements. This patch tries to build and work with the guix provided version of gladeui, in its current state it fails and I want other people with more experience in the guix ecosystem to finish it. --- gnu/packages/gnunet.scm | 39 +++ 1 file changed, 39 insertions(+) diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm index 11e5aa8..91bbe1f 100644 --- a/gnu/packages/gnunet.scm +++ b/gnu/packages/gnunet.scm @@ -3,6 +3,7 @@ ;;; Copyright © 2014 Sree Harsha Totakura ;;; Copyright © 2015 Ludovic Courtès ;;; Copyright © 2015 Efraim Flashner +;;; Copyright © 2016 Ni* Gillmann ;;; ;;; This file is part of GNU Guix. ;;; @@ -286,3 +287,41 @@ GNUnet services, including the @dfn{identity} and @dfn{file sharing} services.") (home-page "http://gnu.org/software/guix;) (license license:gpl3+ + +(define-public gnunet-gtk + (package +(name "gnunet-gtk") +(version "0.10.1") +(source + (origin + (method url-fetch) + (uri (string-append "mirror://gnu/gnunet/gnunet-gtk-" version + ".tar.gz"))
Re: [PATCH 3/6] emacs: Find packages in system profiles.
Ludovic Courtès (2016-01-12 23:28 +0300) wrote: > Alex Kostskribis: > >> For a usual profile, packages are placed in a profile directory itself, >> but for a system profile, packages are placed in 'profile' >> sub-directory. So we need to do some special cases for system profiles >> to find packages there as well. > > [...] > >> +(defun guix-packages-profile (profile generation system?) >> + "Return a directory where packages are installed for the >> +PROFILE's GENERATION. >> + >> +If SYSTEM? is non-nil, then PROFILE is considered to be a system >> +profile. Unlike usual profiles, for a system profile, packages >> +are placed in 'profile' subdirectory." >> + (let ((profile (if generation >> + (guix-generation-file profile generation) >> + profile))) >> +(if system? >> +(expand-file-name "profile" profile) >> + profile))) > > It seems you’re calling /run/current-system the system profile, which > leads to the ‘system?’ Boolean here, but the system profile really is > /run/current-system/profile. As we need to work with generations, I use "/var/guix/profiles/system" instead of a "/run/current-system" link. But you are right, I called it “system profile”. I think using "/var/guix/profiles/system/profile" wouldn't help to remove ‘system?’ boolean. For example: (guix-packages-profile "/var/guix/profiles/per-user/me/guix-profile" 3) => "/var/guix/profiles/per-user/me/guix-profile-3-link" (guix-packages-profile "/var/guix/profiles/system/profile" 3) => "/var/guix/profiles/system/profile-3-link" The first one is correct, but the second should be: => "/var/guix/profiles/system-3-link/profile" As you can see we need to distinguish system and usual profiles because packages are placed in different places for them ("system-NN-link/profile" and "usual-NN-link" without "profile" subdir), that's why I added ‘system?’ argument. I don't see how it can be avoided. > I had overlooked it, but wouldn’t it be easier if patch #2 did: > > +(defvar guix-system-profile > + (concat guix-config-state-directory "/profiles/system/profile") > + "System profile.") > > ? Not really. Both "/var/guix/profiles/system" (which I called “system profile”) and "/var/guix/profiles/system/profile" (which I called “packages profile”) are needed. The former — for finding generations, and the latter — for finding packages. I actually need "/var/guix/profiles/system" in the first place, so if ‘guix-system-profile’ is not an appropriate name for this variable, it should be renamed (what name do you suggest?). And about name confusion: now I see that “profile” should be used only for a directory (symlink) with packages. But I always thought that a directory that has generations can also be named a “profile” (apparently cannot), especially taking into account ‘profile-generations’ procedure from (guix profiles) module: (profile-generations "/var/guix/profiles/system") That's why ^^^ I called "/var/guix/profiles/system" a system profile. -- Alex
Re: [PATCH 6/6] emacs: Add interface for system generations.
Ludovic Courtès (2016-01-12 23:35 +0300) wrote: > Alex Kostskribis: > >> * emacs/guix-main.scm (system-generation-boot-parameters) >> (system-generation-param-alist, system-generation-sexps): New procedures. >> (entries): Add 'system-generation' entry type. >> * emacs/guix-messages.el (guix-result-message): Use the same messages >> for 'generation' and 'system-generation' entry types. >> * emacs/guix-ui-system-generation.el: New file. >> * emacs.am (ELFILES): Add it. >> * doc/emacs.texi (Emacs Commands): Document new commands. >> * NEWS: Mention new interface. > > [...] > >> +Analogously on GuixSD you can also display system generations: >> + >> +@table @kbd >> +@item M-x guix-system-generations >> +@item M-x guix-last-system-generations >> +@item M-x guix-system-generations-by-time >> +@end table > > As simple as this. :-) > > And I guess it’s also possible to select generations, delete them, and > switch to a specific one, as with M-x guix-generations? Well yes, but only if emacs was started with root privileges. At first I was going to remove support for deleting/switching system generations because of this, but then I left it, as I thought there might exist users who run emacs from "root" for some reason, and such manipulating system generations may be useful for them. > Though maybe it would have to use > “sudo:localhost:/run/current-system/profile” (via Tramp) to be able to > modify things. Maybe it could somehow offer to gain root privileges > when performing an action? I don't see how it can be done, since we use a guile REPL to perform such actions (for example, ‘delete-generations’ procedure from (guix scripts package) module). But the REPL is started with the same privileges as emacs. -- Alex
Re: reproducibility
On Wed, Jan 13, 2016 at 10:15 AM, Efraim Flashnerwrote: > On Wed, 13 Jan 2016 09:13:25 +0100 > Federico Beffa wrote: > >> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès wrote: >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> [...] >> >> Just out of curiosity, could you provide a concrete example where the >> order is purposefully specified. >> >> Thanks, >> Fede >> > > I haven't had time (since reading this) to test if the order matters or not, > but some of the openstack packages say they care about order: > https://git.openstack.org/cgit/openstack/python-keystoneclient/tree/test-requirements.txt?h=2.0.0 Reading the comment sounds like its because pip installs packages sequentially. Sounds like a different approach from what we are doing. Anyway, thanks for the pointer. Regards, Fede
Re: [PATCH 1/6] guix system: Export accessors.
Ludovic Courtès (2016-01-12 23:25 +0300) wrote: > Alex Kostskribis: > >> * guix/scripts/system.scm (read-boot-parameters, boot-parameters) >> (boot-parameters?, boot-parameters-label, boot-parameters-root-device) >> (boot-parameters-kernel, boot-parameters-kernel-arguments): Export. > > LGTM. > > Eventually (as a replacement of this patch or as a subsequent patch, as > you prefer) we should move these to (gnu system) since this is where we > create the ‘boot-parameters’ sexp. Great, I would like to make a replacement. OK for the attached patch? (I exported because it is used by (guix scripts system)) >From ac344e3f17741c439aa15a642f1872fd2c7bfd9f Mon Sep 17 00:00:00 2001 From: Alex Kost Date: Fri, 8 Jan 2016 02:48:17 +0300 Subject: [PATCH] Move to (gnu system). * guix/scripts/system.scm (, boot-parameters) (boot-parameters?, boot-parameters-label, boot-parameters-root-device) (boot-parameters-kernel, boot-parameters-kernel-arguments): (read-boot-parameters) Move to... * gnu/system.scm: ... here. Export them. --- gnu/system.scm | 42 ++ guix/scripts/system.scm | 33 - 2 files changed, 42 insertions(+), 33 deletions(-) diff --git a/gnu/system.scm b/gnu/system.scm index 4aedb7e..2600224 100644 --- a/gnu/system.scm +++ b/gnu/system.scm @@ -88,6 +88,15 @@ operating-system-locale-directory operating-system-boot-script + +boot-parameters +boot-parameters? +boot-parameters-label +boot-parameters-root-device +boot-parameters-kernel +boot-parameters-kernel-arguments +read-boot-parameters + local-host-aliases %setuid-programs %base-packages @@ -709,4 +718,37 @@ this file is the reconstruction of GRUB menu entries for old configurations." #$(operating-system-kernel-arguments os)) (initrd #$initrd) + +;;; +;;; Boot parameters +;;; + +(define-record-type* + boot-parameters make-boot-parameters boot-parameters? + (labelboot-parameters-label) + (root-device boot-parameters-root-device) + (kernel boot-parameters-kernel) + (kernel-arguments boot-parameters-kernel-arguments)) + +(define (read-boot-parameters port) + "Read boot parameters from PORT and return the corresponding + object or #f if the format is unrecognized." + (match (read port) +(('boot-parameters ('version 0) + ('label label) ('root-device root) + ('kernel linux) + rest ...) + (boot-parameters + (label label) + (root-device root) + (kernel linux) + (kernel-arguments + (match (assq 'kernel-arguments rest) + ((_ args) args) + (#f '()) ;the old format +(x;unsupported format + (warning (_ "unrecognized boot parameters for '~a'~%") + system) + #f))) + ;;; system.scm ends here diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm index 1407dc7..a45f07e 100644 --- a/guix/scripts/system.scm +++ b/guix/scripts/system.scm @@ -191,39 +191,6 @@ the ownership of '~a' may be incorrect!~%") ;;; -;;; Boot parameters -;;; - -(define-record-type* - boot-parameters make-boot-parameters boot-parameters? - (labelboot-parameters-label) - (root-device boot-parameters-root-device) - (kernel boot-parameters-kernel) - (kernel-arguments boot-parameters-kernel-arguments)) - -(define (read-boot-parameters port) - "Read boot parameters from PORT and return the corresponding - object or #f if the format is unrecognized." - (match (read port) -(('boot-parameters ('version 0) - ('label label) ('root-device root) - ('kernel linux) - rest ...) - (boot-parameters - (label label) - (root-device root) - (kernel linux) - (kernel-arguments - (match (assq 'kernel-arguments rest) - ((_ args) args) - (#f '()) ;the old format -(x;unsupported format - (warning (_ "unrecognized boot parameters for '~a'~%") - system) - #f))) - - -;;; ;;; Reconfiguration. ;;; -- 2.6.3
Re: reproducibility
On Wed, Jan 13, 2016 at 2:56 PM, Ludovic Courtèswrote: > Federico Beffa skribis: > >> On Tue, Jan 12, 2016 at 10:37 PM, Ludovic Courtès wrote: >>> Federico Beffa skribis: >>> On Sun, Jan 10, 2016 at 9:49 PM, Ludovic Courtès wrote: > Federico Beffa skribis: > >> I've noticed that a derivation is a function of the order of the >> inputs. As an example, the following two input orders give rise to two >> distinct derivations: >> >> A) >> >> (inputs >> `(("texlive" ,texlive) >>("texinfo" ,texinfo) >>("m4" ,m4) >>("libx11" ,libx11)) >> >> B) >> (inputs >> `(("texinfo" ,texinfo) >>("texlive" ,texlive) >>("m4" ,m4) >>("libx11" ,libx11)) >> >> Is this intentional? > > Yes. There are several places where order matters, most importantly > search paths, and these are computed from the input lists. If order matters, it would probably be more robust to force internally a specific order rather than relying on the (often random) order defined in a package recipe (possibly created by an importer, ...). >>> >>> Most of the time any order would work, but I can imagine situations >>> where the packager could purposefully choose a specific order. So I’d >>> rather not do any automatic sorting, if that’s what you have in mind. >> >> Just out of curiosity, could you provide a concrete example where the >> order is purposefully specified. > > No specific example, sorry, but it’s plausible IMO. With enough CPU > power, we could try rebuilding everything with a random order and see > what breaks. I guess that's not necessary... I was just trying to learn something. Thanks, Fede
Re: [PATCH] Build C++ cross-compiler by default.
Ricardo Wurmusskribis: > the configure flags defined in “cross-gcc-arguments” disabled the C++ > compiler to prevent an error that happens when building libstdc++-v3. > Since I needed a C++ cross-compiler for ARM I added “c++” to the list of > enabled languages and added the configure flag > “--disable-libstdc++-v3”. This is now the same as what is done in > “gcc-boot0” in “commencement.scm”. Cool. > Will this cause a rebuild of every package on ARM? Is it okay to push > this to core-updates? AFAICS, this causes a rebuild of the cross-compilation infrastructure only (for Hydra, that’s several times GCC plus a bunch of packages that we cross-build to make sure the basic functionality is alright.) So it could even go to ‘master’, but since Hydra is now building all of ‘core-updates’, it’s more energy-efficient to push it to ‘core-updates’ as well. > From 021febc7f7f35ccffe381af798e0b20d7687c94e Mon Sep 17 00:00:00 2001 > From: Ricardo Wurmus > Date: Mon, 11 Jan 2016 19:43:25 +0100 > Subject: [PATCH] gnu: cross-gcc-arguments: Enable C++, disable building of > libstdc++-v3. > > * gnu/packages/cross-base.scm (cross-gcc-arguments)[arguments]: Disable > building libstdc++-v3 and enable building C++ compiler. LGTM! Thanks, Ludo’.
Re: [PATCH 6/6] emacs: Add interface for system generations.
Alex Kostskribis: > Ludovic Courtès (2016-01-12 23:35 +0300) wrote: > >> Alex Kost skribis: >> >>> * emacs/guix-main.scm (system-generation-boot-parameters) >>> (system-generation-param-alist, system-generation-sexps): New procedures. >>> (entries): Add 'system-generation' entry type. >>> * emacs/guix-messages.el (guix-result-message): Use the same messages >>> for 'generation' and 'system-generation' entry types. >>> * emacs/guix-ui-system-generation.el: New file. >>> * emacs.am (ELFILES): Add it. >>> * doc/emacs.texi (Emacs Commands): Document new commands. >>> * NEWS: Mention new interface. >> >> [...] >> >>> +Analogously on GuixSD you can also display system generations: >>> + >>> +@table @kbd >>> +@item M-x guix-system-generations >>> +@item M-x guix-last-system-generations >>> +@item M-x guix-system-generations-by-time >>> +@end table >> >> As simple as this. :-) >> >> And I guess it’s also possible to select generations, delete them, and >> switch to a specific one, as with M-x guix-generations? > > Well yes, but only if emacs was started with root privileges. At first > I was going to remove support for deleting/switching system generations > because of this, but then I left it, as I thought there might exist > users who run emacs from "root" for some reason, and such manipulating > system generations may be useful for them. Sounds reasonable. >> Though maybe it would have to use >> “sudo:localhost:/run/current-system/profile” (via Tramp) to be able to >> modify things. Maybe it could somehow offer to gain root privileges >> when performing an action? > > I don't see how it can be done, since we use a guile REPL to perform > such actions (for example, ‘delete-generations’ procedure from (guix > scripts package) module). But the REPL is started with the same > privileges as emacs. Oh right. We could use elisp code to delete the symlink (that would allow us to use Tramp), but it’s probably not worth bothering. Thanks! Ludo’.
Re: [PATCHES] Update orfm and package test requirements.
On 13/01/16 23:50, Ricardo Wurmus wrote: Ben Woodcroftwrites: [..] +(arguments + `(#:phases + (modify-phases %standard-phases + (add-before 'check 'patch-and-set-version + (lambda _ + (setenv "VERSION" ,version) + #t) That’s an odd phase name; why “patch”? Is setting the environment variable the only way to set the version or would a make-flag work here, too? (I haven’t checked if the ruby-build-system respects make-flags.) The rest looks good to me. Thanks! Pushed, thanks. The phase name above was a bit crufty so I changed it, but had to go with setenv since the ruby-build-system doesn't support make-flags (or rake-flags). Thanks, ben
[PATCH 0/2] "M-x guix-search-by-name" and "M-x guix-packages-by-name".
I almost never use "M-x guix-search-by-name" because I need to know a real name of a package, and I rarely use "M-x guix-search-by-regexp", because along with names it also searches in synopses and descriptions (by default). But I often use another command that allows me to display packages with names matching regexp. For example, I use it when I want to look at packages with names that contain 'xml' or 'emacs'. I believe this is exactly what most people would expect from "M-x guix-search-by-name". So what about renaming 'guix-search-by-name' into 'guix-packages-by-name' and adding a real 'guix-search-by-name' command that will search for regexp in package names? So: - "M-x guix-packages-by-name guile" will display only guile packages (different versions and outputs) - "M-x guix-search-by-name guile" will display all packages with "guile" string in names (like "guile-charting" or "guile-sly").
[PATCH 1/2] emacs: Rename 'guix-search-by-name' to 'guix-packages-by-name'.
* emacs/guix-ui-package.el (guix-search-by-name): Rename to... (guix-packages-by-name): ... this. Complete package name. * doc/emacs.texi (Emacs Commands): Likewise. --- doc/emacs.texi | 2 +- emacs/guix-ui-package.el | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/emacs.texi b/doc/emacs.texi index b2a3d47..7edaedc 100644 --- a/doc/emacs.texi +++ b/doc/emacs.texi @@ -155,7 +155,7 @@ Display all installed packages. Display obsolete packages (the packages that are installed in a profile but cannot be found among available packages). -@item M-x guix-search-by-name +@item M-x guix-packages-by-name Display package(s) with the specified name. @item M-x guix-search-by-regexp diff --git a/emacs/guix-ui-package.el b/emacs/guix-ui-package.el index 7cf1a7d..0696c4b 100644 --- a/emacs/guix-ui-package.el +++ b/emacs/guix-ui-package.el @@ -912,15 +912,15 @@ See `guix-package-info-type'." "A history of minibuffer prompts.") ;;;###autoload -(defun guix-search-by-name (name profile) - "Search for Guix packages by NAME. +(defun guix-packages-by-name (name profile) + "Display Guix packages with NAME. NAME is a string with name specification. It may optionally contain a version number. Examples: \"guile\", \"guile-2.0.11\". If PROFILE is nil, use `guix-current-profile'. Interactively with prefix, prompt for PROFILE." (interactive - (list (read-string "Package name: " nil 'guix-package-search-history) + (list (guix-read-package-name) (guix-ui-read-profile))) (guix-package-get-display profile 'name name)) -- 2.6.3
[PATCH 2/2] emacs: Add 'guix-search-by-name'.
* emacs/guix-ui-package.el (guix-search-by-name): New command. * doc/emacs.texi (Emacs Commands): Document it. --- doc/emacs.texi | 5 + emacs/guix-ui-package.el | 11 +++ 2 files changed, 16 insertions(+) diff --git a/doc/emacs.texi b/doc/emacs.texi index 7edaedc..eb470ab 100644 --- a/doc/emacs.texi +++ b/doc/emacs.texi @@ -163,6 +163,11 @@ Search for packages by a specified regexp. By default ``name'', ``synopsis'' and ``description'' of the packages will be searched. This can be changed by modifying @code{guix-package-search-params} variable. +@item M-x guix-search-by-name +Search for packages with names matching a specified regexp. This +command is the same as @code{guix-search-by-regexp}, except only a +package ``name'' is searched. + @end table By default, these commands display each output on a separate line. If diff --git a/emacs/guix-ui-package.el b/emacs/guix-ui-package.el index 0696c4b..2951452 100644 --- a/emacs/guix-ui-package.el +++ b/emacs/guix-ui-package.el @@ -939,6 +939,17 @@ Interactively with prefix, prompt for PROFILE." (or params guix-package-search-params))) ;;;###autoload +(defun guix-search-by-name (regexp profile) + "Search for Guix packages matching REGEXP in a package name. +If PROFILE is nil, use `guix-current-profile'. +Interactively with prefix, prompt for PROFILE." + (interactive + (list (read-string "Package name by regexp: " + nil 'guix-package-search-history) + (guix-ui-read-profile))) + (guix-search-by-regexp regexp '(name) profile)) + +;;;###autoload (defun guix-installed-packages ( profile) "Display information about installed Guix packages. If PROFILE is nil, use `guix-current-profile'. -- 2.6.3
Re: [PATCH 3/6] emacs: Find packages in system profiles.
Alex Kostskribis: > Ludovic Courtès (2016-01-12 23:28 +0300) wrote: [...] >> It seems you’re calling /run/current-system the system profile, which >> leads to the ‘system?’ Boolean here, but the system profile really is >> /run/current-system/profile. > > As we need to work with generations, I use "/var/guix/profiles/system" > instead of a "/run/current-system" link. But you are right, I called it > “system profile”. > > I think using "/var/guix/profiles/system/profile" wouldn't help to > remove ‘system?’ boolean. For example: > > (guix-packages-profile "/var/guix/profiles/per-user/me/guix-profile" 3) > => "/var/guix/profiles/per-user/me/guix-profile-3-link" > > (guix-packages-profile "/var/guix/profiles/system/profile" 3) > => "/var/guix/profiles/system/profile-3-link" > > The first one is correct, but the second should be: > => "/var/guix/profiles/system-3-link/profile" > > As you can see we need to distinguish system and usual profiles because > packages are placed in different places for them > ("system-NN-link/profile" and "usual-NN-link" without "profile" subdir), > that's why I added ‘system?’ argument. I don't see how it can be > avoided. Oh you’re right, got it. >> I had overlooked it, but wouldn’t it be easier if patch #2 did: >> >> +(defvar guix-system-profile >> + (concat guix-config-state-directory "/profiles/system/profile") >> + "System profile.") >> >> ? > Not really. > > Both "/var/guix/profiles/system" (which I called “system profile”) and > "/var/guix/profiles/system/profile" (which I called “packages profile”) > are needed. The former — for finding generations, and the latter — for > finding packages. > > I actually need "/var/guix/profiles/system" in the first place, so if > ‘guix-system-profile’ is not an appropriate name for this variable, it > should be renamed (what name do you suggest?). Indeed, it’s confusing. I don’t have a better name to suggest, though. > And about name confusion: now I see that “profile” should be used only > for a directory (symlink) with packages. But I always thought that a > directory that has generations can also be named a “profile” (apparently > cannot), especially taking into account ‘profile-generations’ procedure > from (guix profiles) module: > > (profile-generations "/var/guix/profiles/system") > > That's why ^^^ I called "/var/guix/profiles/system" a system profile. Initially, I would have said that as long as FOO/manifest exists, FOO can be called a profile. That’s the definition of a “profile” in the sense of (guix profiles). Like a profile, /var/guix/profiles/system has generations, but unlike “real profiles”, it is not created by ‘profile-derivation’. The solution in this patch looks good, after all! Thanks for explaining, Ludo’.
Re: [PATCH 2/2] gnu: Add espeak.
On Wed, Jan 13, 2016 at 03:17:28PM +0100, Ludovic Courtès wrote: > Leo Famulariskribis: > > > * gnu/packages/audio.scm (espeak): New variable. > > If you think eSpeak-ng is not ready yet, or is sufficiently different, > it’s OK to package eSpeak. I'm looking into it. > > > +(native-inputs > > + `(("unzip" ,unzip))) > > +(inputs > > + `(("sonic" ,sonic) > > The “unzip” line is misaligned. The "unzip" line or the "sonic" line? Most of the patches I see use the former style. > > > +("pulseaudio" ,pulseaudio) > > +("portaudio" ,portaudio))) > > Dunno if it’s useful to have both, maybe someone more knowledgeable like > Ricardo can answer? I misinterpreted the configure options. It's not useful to have both. If PulseAudio is an input, then eSpeak will always use PulseAudio unless configured not to, in which case PulseAudio should not be an input. PulseAudio stopped working completely on my Debian system a while ago. I decided to keep using ALSA and never looked back (or is it forward, in this case? ;) So, if we are going to target PulseAudio, can a PulseAudio user test that this package works? This should make the computer speak "hello world": $ espeak "hello world" > > > +(synopsis "Software speech synthesizer") > > +(description "eSpeak is a compact software speech synthesizer for > > +English and other languages, for Linux and Windows. eSpeak uses a > ^-^ > Remove. Done. > > In general, we don’t mention proprietary software, and we don’t mention > other OSes, free or not, portability etc., because that’s not what > matters from the viewpoint of an OS provider. > > The rest LGTM! Again, I'll be grateful if a PulseAudio user will test! > > Thanks, > Ludo’.
Re: [PATCH 1/2] gnu: Add sonic.
On Wed, Jan 13, 2016 at 03:10:16PM +0100, Ludovic Courtès wrote: > Leo Famulariskribis: > > > * gnu/packages/audio.scm (sonic): New variable. > > [...] > > > +#:phases (modify-phases %standard-phases > > + (delete 'configure *>| > > There’s a problem here. :-) The indentation of the second line, correct? > > > +(synopsis "Speed up or slow down speech") > > +(description "Sonic is a simple algorithm for speeding up or slowing > > down > > s/is a/implements a/ > > > +speech. However, it's optimized for speed ups of over 2X, unlike previous > > +algorithms for changing speech rate. The Sonic library is a very simple > > ANSI C > > +library that is designed to easily be integrated into streaming voice > > +applications, like TTS back ends. > > I would change the last sentence to: > > Sonic is a C library designed to be easily integrated into streaming > voice applications such as text-to-speech (TTS) back ends. > > > +The primary motivation behind Sonic is to enable the blind and visually > > impaired > > +to improve their productivity with open source speech engines, like espeak. > ^‑--^ > Replace with “with speech engines such as eSpeak.” > > > +Sonic can also be used by the sighted. For example, Sonic can improve the > > +experience of listening to an audio book on an Android phone.") > > I’d remove these two sentences. > > OK with these changes. Done. > > Thanks, > Ludo’.
Re: [PATCH] gnu: bind-utils: Build and install “nsupdate”.
Hi, Ricardo Wurmuswrites: >>From ba32861728c3534be6796b6b32a9a90954b6 Mon Sep 17 00:00:00 2001 > From: Ricardo Wurmus > Date: Wed, 13 Jan 2016 16:06:36 +0100 > Subject: [PATCH] gnu: bind-utils: Build and install "nsupdate". > > * gnu/packages/dns.scm (bind-utils)[arguments]: Generalize "build" and > "install" phases. > --- > gnu/packages/dns.scm | 105 > --- > 1 file changed, 58 insertions(+), 47 deletions(-) > > diff --git a/gnu/packages/dns.scm b/gnu/packages/dns.scm > index 8357dad..0a42722 100644 > --- a/gnu/packages/dns.scm > +++ b/gnu/packages/dns.scm [...] > + (arguments > + `(#:tests? #f ; no test phase implemented > + #:configure-flags > + (list (string-append "--with-openssl=" > + (assoc-ref %build-inputs "openssl")) > + (string-append "--with-dlz-mysql=" > + (assoc-ref %build-inputs "mysql")) > + (string-append "--with-pkcs11=" > + (assoc-ref %build-inputs "p11-kit"))) What about: #:configure-flags (map (lambda (opt val) (string-append opt (assoc-ref %build-inputs val))) '("--with-openssl=" "--with-dlz-mysql=" "--with-pkcs11=") '("openssl" "mysql" "p11-kit")) > + #:modules ((srfi srfi-1) > +(srfi srfi-26) > +,@%gnu-build-system-modules) > + #:phases > + (modify-phases %standard-phases > + (replace 'build > + (lambda _ > + (fold (lambda (dir pass) > + (and pass (zero? (system* "make" "-C" dir > + #t > + (append > + (map (cut string-append "lib/" <>) > + (list ,@libs)) > + (map (cut string-append "bin/" <>) > + (list ,@bins)) > + (replace 'install > + (lambda _ > + (fold (lambda (dir pass) > + (and pass (zero? (system* "make" "-C" dir > "install" > + #t > + (map (cut string-append "bin/" <>) > + (list ,@bins and this: (let ((libs '("dns" "isc" "bind9" "isccfg" "lwres")) (bins '("dig" "nsupdate"))) (modify-phases %standard-phases (replace 'build (lambda _ (every (lambda (dir) (zero? (system* "make" "-C" dir))) (append (map (cut string-append "lib/" <>) libs) (map (cut string-append "bin/" <>) bins) (replace 'install (lambda _ (every (lambda (dir) (zero? (system* "make" "-C" dir "install"))) (map (cut string-append "bin/" <>) bins Otherwise LGTM. -- Mathieu Lirzin
Re: [PATCH 2/2] gnu: Add espeak.
Leo Famulariskribis: > * gnu/packages/audio.scm (espeak): New variable. If you think eSpeak-ng is not ready yet, or is sufficiently different, it’s OK to package eSpeak. > +(native-inputs > + `(("unzip" ,unzip))) > +(inputs > + `(("sonic" ,sonic) The “unzip” line is misaligned. > +("pulseaudio" ,pulseaudio) > +("portaudio" ,portaudio))) Dunno if it’s useful to have both, maybe someone more knowledgeable like Ricardo can answer? > +(synopsis "Software speech synthesizer") > +(description "eSpeak is a compact software speech synthesizer for > +English and other languages, for Linux and Windows. eSpeak uses a ^-^ Remove. In general, we don’t mention proprietary software, and we don’t mention other OSes, free or not, portability etc., because that’s not what matters from the viewpoint of an OS provider. The rest LGTM! Thanks, Ludo’.
Re: [PATCH 1/2] gnu: Add sonic.
Leo Famulariskribis: > * gnu/packages/audio.scm (sonic): New variable. [...] > +#:phases (modify-phases %standard-phases > + (delete 'configure There’s a problem here. :-) > +(synopsis "Speed up or slow down speech") > +(description "Sonic is a simple algorithm for speeding up or slowing down s/is a/implements a/ > +speech. However, it's optimized for speed ups of over 2X, unlike previous > +algorithms for changing speech rate. The Sonic library is a very simple > ANSI C > +library that is designed to easily be integrated into streaming voice > +applications, like TTS back ends. I would change the last sentence to: Sonic is a C library designed to be easily integrated into streaming voice applications such as text-to-speech (TTS) back ends. > +The primary motivation behind Sonic is to enable the blind and visually > impaired > +to improve their productivity with open source speech engines, like espeak. ^‑--^ Replace with “with speech engines such as eSpeak.” > +Sonic can also be used by the sighted. For example, Sonic can improve the > +experience of listening to an audio book on an Android phone.") I’d remove these two sentences. OK with these changes. Thanks, Ludo’.
[PATCH] Add audit.
Hi Guix, the tests for this package cannot easily be fixed by #:phases (modify-phases %standard-phases (add-after 'unpack 'fix-tests (lambda _ (substitute* "auparse/test/auparse_test.ref" (("\\(root\\)") "(unknown(0))")) #t))) because for *some* of them “(root)” is returned (while for *most* of them its “(unknown(0))”). Ideas on how to fix the tests are very welcome! ~~ Ricardo >From c4948bc06b30e4e55810b82cc458cd6a429b6f80 Mon Sep 17 00:00:00 2001 From: Ricardo WurmusDate: Wed, 13 Jan 2016 16:00:06 +0100 Subject: [PATCH] gnu: Add audit. * gnu/packages/admin.scm (audit): New variable. --- gnu/packages/admin.scm | 33 + 1 file changed, 33 insertions(+) diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm index fbdc26d..87dd497 100644 --- a/gnu/packages/admin.scm +++ b/gnu/packages/admin.scm @@ -6,6 +6,7 @@ ;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer ;;; Copyright © 2015 Alex Sassmannshausen ;;; Copyright © 2015 Eric Dvorsak +;;; Copyright © 2016 Ricardo Wurmus ;;; ;;; This file is part of GNU Guix. ;;; @@ -34,6 +35,7 @@ #:use-module (guix build-system trivial) #:use-module (gnu packages) #:use-module (gnu packages base) + #:use-module (gnu packages cyrus-sasl) #:use-module (gnu packages ncurses) #:use-module (gnu packages readline) #:use-module (gnu packages linux) @@ -47,6 +49,7 @@ #:use-module (gnu packages bison) #:use-module (gnu packages flex) #:use-module (gnu packages glib) + #:use-module (gnu packages openldap) #:use-module (gnu packages pkg-config) #:use-module (gnu packages popt) #:use-module (gnu packages texinfo) @@ -1317,3 +1320,33 @@ able to adapt itself dynamically to the overall system load. Children processes and threads of the specified process may optionally share the same limits.") (license license:gpl2+))) + +(define-public audit + (package +(name "audit") +(version "2.4.5") +(source (origin + (method url-fetch) + (uri (string-append "http://people.redhat.com/sgrubb/audit/; + "audit-" version ".tar.gz")) + (sha256 + (base32 +"1q1q51dvxscbi4kbakmd4bn0xrvwwaiwvaya79925cbrqwzxsg77" +(build-system gnu-build-system) +(home-page "http://people.redhat.com/sgrubb/audit/;) +(arguments + `(;; The tests expect records like "uid=0 (root)" but only get "uid=0 + ;; (unknown(0))" in most cases. + #:tests? #f + #:configure-flags (list "--with-python=no"))) +(inputs + `(("openldap" ,openldap) + ("openssl" ,openssl) + ("sasl" ,cyrus-sasl))) +(synopsis "Userspace component to the Linux auditing system") +(description + "auditd is the userspace component to the Linux auditing system. It's +responsible for writing audit records to the disk. Viewing the logs is done +with the @code{ausearch} or @code{aureport} utilities. Configuring the audit +rules is done with the @code{auditctl} utility.") +(license license:gpl2+))) -- 2.1.0
[PATCH] gnu: bind-utils: Build and install “nsupdate”.
Hi Guix, this patch is not as bad as it looks, even though most of the lines are changed. I noticed that “nsupdate” is not build as part of bind-utils and replaced the manual and repetitive “build” and “install” phases with something that can be controlled with the let-bound values “bins” and “libs” holding the names of executables and libraries, respectively. What do you think? (“nsupdate” is checked for by the build system of some SELinux libraries, which are needed for SSSD.) ~~ Ricardo >From ba32861728c3534be6796b6b32a9a90954b6 Mon Sep 17 00:00:00 2001 From: Ricardo WurmusDate: Wed, 13 Jan 2016 16:06:36 +0100 Subject: [PATCH] gnu: bind-utils: Build and install "nsupdate". * gnu/packages/dns.scm (bind-utils)[arguments]: Generalize "build" and "install" phases. --- gnu/packages/dns.scm | 105 --- 1 file changed, 58 insertions(+), 47 deletions(-) diff --git a/gnu/packages/dns.scm b/gnu/packages/dns.scm index 8357dad..0a42722 100644 --- a/gnu/packages/dns.scm +++ b/gnu/packages/dns.scm @@ -1,5 +1,6 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer +;;; Copyright © 2016 Ricardo Wurmus ;;; ;;; This file is part of GNU Guix. ;;; @@ -61,51 +62,61 @@ and BOOTP/TFTP for network booting of diskless machines.") (license (list license:gpl2 license:gpl3 (define-public bind-utils - (package -(name "bind-utils") -(version "9.10.3-P2") -(source (origin - (method url-fetch) - (uri (string-append "http://ftp.isc.org/isc/bind9/; version - "/bind-" version ".tar.gz")) - (sha256 - (base32 -"1kbfzml37sx4r2xi4gq48ji8w5kckd1f6gdn6pk6njqdmh8ijv2a" -(build-system gnu-build-system) -(inputs - ;; it would be nice to add GeoIP and gssapi once there is package - `(("libcap" ,libcap) - ("libxml2" ,libxml2) - ("mysql" ,mysql) - ("openssl" ,openssl) - ("perl" ,perl) - ("p11-kit" ,p11-kit))) -(arguments - `(#:tests? #f ; no test phase implemented - #:configure-flags - (list (string-append "--with-openssl=" -(assoc-ref %build-inputs "openssl")) - (string-append "--with-dlz-mysql=" -(assoc-ref %build-inputs "mysql")) - (string-append "--with-pkcs11=" -(assoc-ref %build-inputs "p11-kit"))) - #:phases - (alist-replace -'build -(lambda _ - (and (zero? (system* "make" "-C" "lib/dns")) - (zero? (system* "make" "-C" "lib/isc")) - (zero? (system* "make" "-C" "lib/bind9")) - (zero? (system* "make" "-C" "lib/isccfg")) - (zero? (system* "make" "-C" "lib/lwres")) - (zero? (system* "make" "-C" "bin/dig" -(alist-replace - 'install - (lambda _ (zero? (system* "make" "-C" "bin/dig" "install"))) - %standard-phases -(home-page "https://www.isc.org/downloads/bind/;) -(synopsis "Tools for querying nameservers") -(description - "These tools, included with ISC BIND, are useful for analysis of DNS + (let ((libs '("dns" "isc" "bind9" "isccfg" "lwres")) +(bins '("dig" "nsupdate"))) +(package + (name "bind-utils") + (version "9.10.3-P2") + (source (origin +(method url-fetch) +(uri (string-append "http://ftp.isc.org/isc/bind9/; version +"/bind-" version ".tar.gz")) +(sha256 + (base32 + "1kbfzml37sx4r2xi4gq48ji8w5kckd1f6gdn6pk6njqdmh8ijv2a" + (build-system gnu-build-system) + (inputs + ;; it would be nice to add GeoIP and gssapi once there is package + `(("libcap" ,libcap) + ("libxml2" ,libxml2) + ("mysql" ,mysql) + ("openssl" ,openssl) + ("perl" ,perl) + ("p11-kit" ,p11-kit))) + (arguments + `(#:tests? #f ; no test phase implemented + #:configure-flags + (list (string-append "--with-openssl=" + (assoc-ref %build-inputs "openssl")) + (string-append "--with-dlz-mysql=" + (assoc-ref %build-inputs "mysql")) + (string-append "--with-pkcs11=" + (assoc-ref %build-inputs "p11-kit"))) + #:modules ((srfi srfi-1) +(srfi srfi-26) +,@%gnu-build-system-modules) + #:phases + (modify-phases %standard-phases + (replace 'build + (lambda _ + (fold (lambda (dir pass) + (and pass (zero? (system* "make" "-C" dir + #t +
Re: Freezing core-updates soon
Hydra will start building all of ‘core-updates’ soon. Hopefully we can merge in a few days. Ludo’.