[PATCH] Add support for 'cvs-fetch' method in origins

[Mark H Weaver]

The motivation for this is libffcall, which hasn't been released in such
a long time that http://gnu.org/s/libffcall doesn't even link to the
last release, but just says to download it from CVS.

guix/cvs-download.scm is based so heavily on guix/svn-download.scm that
I copied the copyright notices from svn-download.scm.

  Mark

>From 118c8b739f368e4e5f691e119618568dcda0e12b Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Sat, 17 Jan 2015 22:11:45 -0500
Subject: [PATCH] Add support for 'cvs-fetch' method in origins.

* guix/cvs-download.scm, guix/build/cvs.scm: New files.
* Makefile.am (MODULES): Add them.
---
 Makefile.am   |  2 ++
 guix/build/cvs.scm| 65 +++
 guix/cvs-download.scm | 84 +++
 3 files changed, 151 insertions(+)
 create mode 100644 guix/build/cvs.scm
 create mode 100644 guix/cvs-download.scm

diff --git a/Makefile.am b/Makefile.am
index 67367d6..2e0da77 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -60,6 +60,7 @@ MODULES =	\
   guix/gnupg.scm\
   guix/elf.scm	\
   guix/store.scm\
+  guix/cvs-download.scm\
   guix/svn-download.scm\
   guix/ui.scm	\
   guix/build/download.scm			\
@@ -76,6 +77,7 @@ MODULES =	\
   guix/build/union.scm\
   guix/build/pull.scm\
   guix/build/rpath.scm\
+  guix/build/cvs.scm\
   guix/build/svn.scm\
   guix/build/syscalls.scm			\
   guix/build/emacs-utils.scm			\
diff --git a/guix/build/cvs.scm b/guix/build/cvs.scm
new file mode 100644
index 000..18b138c
--- /dev/null
+++ b/guix/build/cvs.scm
@@ -0,0 +1,65 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2015 Mark H Weaver 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (guix build cvs)
+  #:use-module (guix build utils)
+  #:use-module (ice-9 regex)
+  #:use-module (ice-9 ftw)
+  #:export (cvs-fetch))
+
+;;; Commentary:
+;;;
+;;; This is the build-side support code of (guix cvs-download).  It allows a
+;;; CVS repository to be checked out at a specific revision or date.
+;;;
+;;; Code:
+
+(define (find-cvs-directories)
+  (define (enter? path st result)
+(not (string-suffix? "/CVS" path)))
+  (define (leaf path st result) result)
+  (define (down path st result) result)
+  (define (up   path st result) result)
+  (define (skip path st result)
+(if (and (string-suffix? "/CVS" path)
+ (eqv? 'directory (stat:type st)))
+(cons path result)
+result))
+  (define (error path st errno result)
+(format (current-error-port) "cvs-fetch: ~a: ~a~%"
+path (strerror errno)))
+  (file-system-fold enter? leaf down up skip error '() "." lstat))
+
+(define* (cvs-fetch cvs-root-dir module revision directory
+#:key (cvs-command "cvs"))
+  "Fetch REVISION from MODULE of CVS-ROOT-DIR into DIRECTORY.  REVISION must
+either be a date in ISO-8601 format (e.g. \"2012-12-21\") or a CVS tag.
+Return #t on success, #f otherwise."
+  (and (zero? (system* cvs-command "-z3"
+   "-d" cvs-root-dir
+   "checkout"
+   (if (string-match "^[0-9]{4}-[0-9]{2}-[0-9]{2}$" revision)
+   "-D" "-r")
+   revision
+   module))
+   (rename-file module directory)
+   (with-directory-excursion directory
+ (for-each delete-file-recursively (find-cvs-directories)))
+   #t))
+
+;;; cvs.scm ends here
diff --git a/guix/cvs-download.scm b/guix/cvs-download.scm
new file mode 100644
index 000..e3d8ad1
--- /dev/null
+++ b/guix/cvs-download.scm
@@ -0,0 +1,84 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2014, 2015 Ludovic Courtès 
+;;; Copyright © 2014 Sree Harsha Totakura 
+;;; Copyright © 2015 Mark H Weaver 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTI

[PATCH] gnu: Add libffcall

[Mark H Weaver]

>From c5fb3c2dafedaa9ceab55992bd994c9aff313528 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 3 Feb 2015 03:45:39 -0500
Subject: [PATCH] gnu: Add libffcall.

* gnu/packages/libffcall.scm: New file.
* gnu-system.am (GNU_SYSTEM_MODULES): Add it.

Co-Authored-By: Joshua S. Grant 
---
 gnu-system.am  |  1 +
 gnu/packages/libffcall.scm | 49 ++
 2 files changed, 50 insertions(+)
 create mode 100644 gnu/packages/libffcall.scm

diff --git a/gnu-system.am b/gnu-system.am
index 0fb4571..9aa202e 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -157,6 +157,7 @@ GNU_SYSTEM_MODULES =\
   gnu/packages/libcanberra.scm			\
   gnu/packages/libdaemon.scm			\
   gnu/packages/libevent.scm			\
+  gnu/packages/libffcall.scm			\
   gnu/packages/libffi.scm			\
   gnu/packages/libftdi.scm			\
   gnu/packages/libidn.scm			\
diff --git a/gnu/packages/libffcall.scm b/gnu/packages/libffcall.scm
new file mode 100644
index 000..4d46764
--- /dev/null
+++ b/gnu/packages/libffcall.scm
@@ -0,0 +1,49 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2015 Joshua S. Grant 
+;;; Copyright © 2015 Mark H Weaver 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages libffcall)
+  #:use-module ((guix licenses) #:prefix l:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix cvs-download)
+  #:use-module (guix build-system gnu))
+
+(define-public libffcall
+   (package
+(name "libffcall")
+(version "1.10+cvs-2015-01-15")
+(source
+ (origin
+   (method cvs-fetch)
+   (uri (cvs-reference
+ (root-dir
+  ":pserver:anonym...@cvs.savannah.gnu.org:/sources/libffcall")
+ (module "ffcall")
+ (revision "2015-01-15")))
+   (sha256
+(base32
+ "1lwdskc2w4rr98x9flr2726lmj4190l16r0izg7gqxy50801wwgd"
+(build-system gnu-build-system)
+(arguments `(#:parallel-build? #f))
+(synopsis "Foreign function call libraries")
+(description
+ "GNU Libffcall is a collection of libraries that can be used to build
+foreign function call interfaces in embedded interpreters.")
+(home-page "http://www.gnu.org/software/libffcall/";)
+(license l:gpl2)))
-- 
2.2.1

Re: [PATCH] gnu: Add urwid

[Omar Radwan]

>I'm sorry, but we are failing to >communicate, and I don't have any >more
>time to spend on this.  I have pushed >commit e99f421185 based on your
>preliminary work.  It adds two >packages: python-urwid for Python 3, >and
>python2-urwid for Python 2.

Sorry for the miscommunication. I'll do better next time. Thanks for the
commit push. I can start working on wicd
On Feb 2, 2015 9:37 PM, "Mark H Weaver"  wrote:

> Omar Radwan  writes:
>
> >>What was the error? I tested the >package with all of the
> > modifications
> >>I suggested, including this one, and it >built successfully on my
> > i686
> >>machine.
> > It didn't build on my 64bit machine. And just to be clear. I tried to
> > substitute it for inputs and that didn't work. Was I supposed to put
> > it inside inputs?
>
> I'm sorry, but we are failing to communicate, and I don't have any more
> time to spend on this.  I have pushed commit e99f421185 based on your
> preliminary work.  It adds two packages: python-urwid for Python 3, and
> python2-urwid for Python 2.
>
>  Thanks,
>Mark
>

Re: guix environment

[Ludovic Courtès]

David Thompson  skribis:

> Ludovic Courtès  writes:
>
>> On closer inspection, I see two issues:
>>
>>   (define (packages->transitive-inputs packages)
>> "Return a list of the transitive inputs for all PACKAGES."
>> (define (transitive-inputs package)
>>   (filter-map (match-lambda
>>((_ (? package? package)) package)
>>(_ #f)); < !
>>   (bag-transitive-inputs
>>(package->bag package
>> (delete-duplicates
>>  (append-map transitive-inputs packages)))
>>
>> Here only inputs of the form ("foo" PKG) are considered; things like
>> ("glib" ,glib "bin") are discarded.
>>
>>   (define (for-each-search-path proc inputs derivations pure?)
>> (let ((paths (map derivation->output-path derivations))) ; <-- !
>>   [...]
>>
>> Above, ‘derivation->output-path’ considers only the “out” output,
>> ignoring others if they are needed.
>
> Here's a patch.  WDYT?
>
>
> From 9609806fb78557d74cf5b3fb47802898ef9d1ecf Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Thu, 29 Jan 2015 17:53:17 -0500
> Subject: [PATCH] guix: environment: Consider all package outputs.
>
> * guix/scripts/environment.scm (for-each-search-path): Iterate over all
>   derivation output paths.
>   (packages->transitive-inputs): Process inputs that specify an output, too.

[...]

> --- a/guix/scripts/environment.scm
> +++ b/guix/scripts/environment.scm
> @@ -40,7 +40,12 @@
>  Use the output paths of DERIVATIONS to build each search path.  When PURE? is
>  #t, the existing search path value is ignored.  Otherwise, the existing 
> search
>  path value is appended."
> -  (let ((paths (map derivation->output-path derivations)))
> +  (let ((paths (append-map (lambda (drv)
> + (map (match-lambda
> +   ((_ . output)
> +(derivation-output-path output)))
> +  (derivation-outputs drv)))
> +   derivations)))
>  (for-each (match-lambda
> (($ 
> variable directories separator)
> @@ -177,7 +182,9 @@ packages."
>"Return a list of the transitive inputs for all PACKAGES."
>(define (transitive-inputs package)
>  (filter-map (match-lambda
> - ((_ (? package? package)) package)
> + ((or (_ (? package? package))
> +  (_ (? package? package) _))
> +  package)
>   (_ #f))

LGTM, please push!

There’s another problem, though.  When a dependency is a multiple-output
package, all its outputs are added to the environment, because
‘package->transitive-inputs’ discards the information of which output is
needed.

So for instance, both the ‘out’ and the ‘debug’ output of Coreutils end
up being downloaded and added to the environment, even though only ‘out’
is an input.

Now, the problem is that ‘build-derivations’ can only build *all* the
outputs of the given derivation.  This could be worked around either:

  1. by creating a “sink” derivation, for instance with
 ‘profile-derivation’, that could refer precisely to the output(s)
 needed; not ideal.

  2. by using (build-things (list "/the/output/path")) and resorting to
 ‘build-derivations’ only if the ‘build-things’ call did nothing
 (when passed a non-.drv store item, ‘build-things’ tries to
 substitute and does nothing if that fails.)

Thoughts?

Ludo’.

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Ludovic Courtès]

Mark H Weaver  skribis:

> From 02bdf748b4c515d6dfc9c264fd48936bd29e04cb Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Tue, 18 Feb 2014 21:30:53 -0500
> Subject: [PATCH] gnu: gnutls: Configure location of system-wide trust store.
>
> * gnu/packages/gnutls.scm (gnutls): Configure the location of the system-wide
>   trust store.

I support it, OK to push.

The next question will be which certificate bundles should we provide
there in the system distro?  I know NixOS takes them from the cURL web
site, and Debian maintains its own (IIRC.)  Any ideas?

Thank you!

Ludo’.

Re: ignore trailing slash for `guix gc -d' /gnu/store/...something/

[Ludovic Courtès]

sleep_wal...@suse.cz skribis:

> Package: guix
> Version: 0.8.1
>
> When I invoke `guix gc -d /path', success of the command depends whether 
> /path ends with slash or not:
>
> $ guix gc -d /gnu/store/mgqk0kv5jckrd7l5cwj68fp7cz2l4qqj-luajit-2.0.3/
> guix gc: error: build failed: path 
> `/gnu/store/mgqk0kv5jckrd7l5cwj68fp7cz2l4qqj-luajit-2.0.3/' is not in the Nix 
> store
>
> $ guix gc -d /gnu/store/mgqk0kv5jckrd7l5cwj68fp7cz2l4qqj-luajit-2.0.3
> finding garbage collector roots...
> cannot read potential root `/var/guix/manifests'
> deleting `/gnu/store/73b760g2nr9syhznydgly8r7vl2k9z11-profile'
> deleting `/gnu/store/mgqk0kv5jckrd7l5cwj68fp7cz2l4qqj-luajit-2.0.3'
> deleting `/gnu/store/trash'
> deleting unused links...
> note: currently hard linking saves 247.60 MiB
>
>
> * with the misleading error message it is usability bug
> * it should be safe always try to remove slash from the end
> * other commands may be affected too and the behaviour should be consistent 
> for all commands

What behavior do you think would be appropriate when running, say:

  guix gc -d /gnu/store/mgqk0kv5jckrd7l5cwj68fp7cz2l4qqj-luajit-2.0.3/bin/lua

Should it be equivalent to:

  guix gc -d /gnu/store/mgqk0kv5jckrd7l5cwj68fp7cz2l4qqj-luajit-2.0.3

I would think so, but I’d like to have feedback.

Thanks,
Ludo’.

PS: Make sure to use bug-g...@gnu.org for bug reports.

Re: [PATCH] gnu: luajit: install symlinks for libluajit library

[Ludovic Courtès]

Tomáš Čech  skribis:

> * gnu/packages/lua.scm (luajit): don't require ldconfig - add "LDCONFIG=true"
>   to make command line, add luajit-2.0.3-symlink.patch so both symlinks are 
> created
> * gnu/packages/patches/luajit-2.0.3-symlink.patch: New file
> * gnu-system.am (dist_patch_DATA): Adjust accordingly.
>
> Install phase of luajit contained:
>
> ldconfig /gnu/store/…-luajit-2.0.3/lib && \
> ln -sf libluajit-5.1.so.2.0.3 /gnu/store/…-luajit-2.0.3/lib/libluajit-5.1.so 
> && \
> ln -sf libluajit-5.1.so.2.0.3 /gnu/store/…-luajit-2.0.3/lib/libluajit-5.1.so 
> || :
>
> 1) When ldconfig is missing, symlinks are not created but whole expression
>returns no error. This cause linker not to find proper library when
>building package against luajit and libluajit-5.1.a is used instead. With
>'LDCONFIG=true' it ommits the problem.
>
> 2) same symlink is created twice, luajit-2.0.3-symlink.patch fixes that.

Good catch, thanks for investigating!

>  (arguments
>   '(#:tests? #f  ;luajit is distributed without tests
> #:phases (alist-delete 'configure %standard-phases)
> -   #:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs 
> "out")
> +   ; poorly formulated expression doesn't create symlinks for dynamic 
> library on ldconfig failure
> +   ; ldconfig is useless anyway so success always with `true'
> +   #:make-flags (list "LDCONFIG=true" (string-append "PREFIX=" 
> (assoc-ref %outputs "out")

Some nitpicking: please use double-colon for block comments, capitalize
sentences, add periods at the end of sentences, and wrap lines to 80
chars.

s/poorly formulated expression/The Makefile/

And perhaps add something like: “Set LDCONFIG=true to work around it.”,
to make it clear what the solution is and how it relates to the problem.

> diff --git a/gnu/packages/patches/luajit-2.0.3-symlink.patch 
> b/gnu/packages/patches/luajit-2.0.3-symlink.patch
> new file mode 100644
> index 000..c6b4eec
> --- /dev/null
> +++ b/gnu/packages/patches/luajit-2.0.3-symlink.patch
> @@ -0,0 +1,12 @@
> +diff -up LuaJIT-2.0.3/Makefile.orig LuaJIT-2.0.3/Makefile
> +--- LuaJIT-2.0.3/Makefile.orig   2014-03-12 13:10:00.0 +0100
>  LuaJIT-2.0.3/Makefile2015-02-02 23:52:30.774723789 +0100
> +@@ -56,7 +56,7 @@ INSTALL_PCNAME= luajit.pc
> + INSTALL_STATIC= $(INSTALL_LIB)/$(INSTALL_ANAME)
> + INSTALL_DYN= $(INSTALL_LIB)/$(INSTALL_SONAME)
> + INSTALL_SHORT1= $(INSTALL_LIB)/$(INSTALL_SOSHORT)
> +-INSTALL_SHORT2= $(INSTALL_LIB)/$(INSTALL_SOSHORT)
> ++INSTALL_SHORT2= $(INSTALL_LIB)/$(INSTALL_SOSHORT).$(MAJVER)

Please add a comment above the hunk explaining what the patch does, why,
and what its upstream status is.

Could you send an updated patch?

Thanks!

Ludo’.

Re: [PATCH] gnu: Add urwid

[Ludovic Courtès]

Omar Radwan  skribis:

>>I'm sorry, but we are failing to >communicate, and I don't have any >more
>>time to spend on this.  I have pushed >commit e99f421185 based on your
>>preliminary work.  It adds two >packages: python-urwid for Python 3, >and
>>python2-urwid for Python 2.
>
> Sorry for the miscommunication. I'll do better next time. Thanks for the
> commit push. I can start working on wicd

Cool.  Thanks for urwid, and thanks to Mark for helping out!

One way to avoid miscommunication in the future would be to read the
“Submitting Patches” section in ‘HACKING’ and to look at existing
commits for the conventions to follow.  Another thing would be to avoid
HTML emails and top-posting, which are inconvenient for the reader.

Ludo’.

Re: [PATCH] Add support for 'cvs-fetch' method in origins

[Ludovic Courtès]

Mark H Weaver  skribis:

> The motivation for this is libffcall, which hasn't been released in such
> a long time that http://gnu.org/s/libffcall doesn't even link to the
> last release, but just says to download it from CVS.

OK.

> From 118c8b739f368e4e5f691e119618568dcda0e12b Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Sat, 17 Jan 2015 22:11:45 -0500
> Subject: [PATCH] Add support for 'cvs-fetch' method in origins.
>
> * guix/cvs-download.scm, guix/build/cvs.scm: New files.
> * Makefile.am (MODULES): Add them.

[...]

> +(define (find-cvs-directories)
> +  (define (enter? path st result)
> +(not (string-suffix? "/CVS" path)))
> +  (define (leaf path st result) result)
> +  (define (down path st result) result)
> +  (define (up   path st result) result)
> +  (define (skip path st result)
> +(if (and (string-suffix? "/CVS" path)
> + (eqv? 'directory (stat:type st)))
> +(cons path result)
> +result))
> +  (define (error path st errno result)
> +(format (current-error-port) "cvs-fetch: ~a: ~a~%"
> +path (strerror errno)))
> +  (file-system-fold enter? leaf down up skip error '() "." lstat))

Might be best to sort the result to make it deterministic.

[...]

> +(define-record-type* 
> +  cvs-reference make-cvs-reference
> +  cvs-reference?
> +  (root-dir cvs-reference-root-dir)   ; string
> +  (module   cvs-reference-module) ; string
> +  (revision cvs-reference-revision))  ; string

s/root-dir/root-directory/ maybe?

> +(gexp->derivation (or name "cvs-checkout") build
> +  #:system system
> +  ;; FIXME: See .
> +  ;;#:local-build? #t

[...]

> +  #:local-build? #t)))

To #:local-build? or not to #:local-build?, that is the question.  :-)

LGTM modulo these little things.

Thank you,
Ludo’.

Re: guix environment

[David Thompson]

Ludovic Courtès  writes:

> LGTM, please push!

Pushed.

> There’s another problem, though.  When a dependency is a multiple-output
> package, all its outputs are added to the environment, because
> ‘package->transitive-inputs’ discards the information of which output is
> needed.

Yes, I had thought about this, but couldn't think of a way to preserve
that information throughout the program.

> So for instance, both the ‘out’ and the ‘debug’ output of Coreutils end
> up being downloaded and added to the environment, even though only ‘out’
> is an input.
>
> Now, the problem is that ‘build-derivations’ can only build *all* the
> outputs of the given derivation.  This could be worked around either:
>
>   1. by creating a “sink” derivation, for instance with
>  ‘profile-derivation’, that could refer precisely to the output(s)
>  needed; not ideal.
>
>   2. by using (build-things (list "/the/output/path")) and resorting to
>  ‘build-derivations’ only if the ‘build-things’ call did nothing
>  (when passed a non-.drv store item, ‘build-things’ tries to
>  substitute and does nothing if that fails.)
>
> Thoughts?

I don't like option #1.  I haven't fully grokked option #2, but I guess
that will be the next thing to try.

Thanks for the nudge in the right direction.

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

Re: [PATCH] gnu: Add libffcall

[Ludovic Courtès]

Mark H Weaver  skribis:

> From c5fb3c2dafedaa9ceab55992bd994c9aff313528 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Tue, 3 Feb 2015 03:45:39 -0500
> Subject: [PATCH] gnu: Add libffcall.
>
> * gnu/packages/libffcall.scm: New file.
> * gnu-system.am (GNU_SYSTEM_MODULES): Add it.
>
> Co-Authored-By: Joshua S. Grant 

[...]

> +(license l:gpl2)))

I think this is gpl2+ (really, any version) because the license headers
to not specify any particular version.

LGTM, thanks!

Ludo’.

Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store

[Marek Benc]

On 02/03/2015 09:53 PM, Ludovic Courtès wrote:

Mark H Weaver  skribis:


 From 02bdf748b4c515d6dfc9c264fd48936bd29e04cb Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Tue, 18 Feb 2014 21:30:53 -0500
Subject: [PATCH] gnu: gnutls: Configure location of system-wide trust store.

* gnu/packages/gnutls.scm (gnutls): Configure the location of the system-wide
   trust store.


I support it, OK to push.

The next question will be which certificate bundles should we provide
there in the system distro?  I know NixOS takes them from the cURL web
site, and Debian maintains its own (IIRC.)  Any ideas?


If I recall correctly, at one point, the idea was to extract the 
certificates from Icecat, but we were waiting for quidam to update it 
first (it was long stuck on a single version, 24 I think?)




Thank you!

Ludo’.



--
Marek.

Re: [PATCH 0/5]: Add even more LV2 libraries

[Ricardo Wurmus]

Ludovic Courtès writes:
>> - serd
>> - sord
>> - sratom
>
> I think these should go to rdf.scm, no?

Yes, I think that would be better.

>> - suil
>
> Its ‘description’ is bit long, IMO.

Agreed.  I'll shorten the description and post an updated patch set.

> Thanks!

Thanks for taking the time for the review!

~~ Ricardo

Re: [PATCH] Add 'waf-build-system'.

[rekado]

Ludovic Courtès writes:

> Ricardo Wurmus  skribis:
>
>> Unlike the Python build system, however, there is a configure phase, and
>> not everything important happens during the install phase.
>
> OK.  Did you find it more appropriate to extend ‘gnu-build-system’
> rather than ‘python-build-system’?

The way I see it the waf-build-system is a descendant of the
gnu-build-system in that it has the same phases; it only uses a
different tool (namely the waf script).  The python-build-system on the
other hand concentrates everything in the install "phase".

The waf-build-system looks similar to the python-build-system only
because the waf script needs to be run with a python interpreter, and it
could be either version 2 or 3.  This is why I extended the
gnu-build-system (as a "parent") and imported the default-python
procedures from python-build-system (as a "cousin").

Does this make any sense?

>
>> From adc52a74fb12943fd77c97bf75a2092e839f9024 Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus 
>> Date: Wed, 28 Jan 2015 22:39:03 +0100
>> Subject: [PATCH] Add 'waf-build-system'.
>>
>> * guix/build-system/waf.scm, guix/build/waf-build-system.scm: New files.
>> * Makefile.am (MODULES): Add them.
>
> Could you add a few lines to guix.texi, under “Build Systems”?  Other
> than that this looks good to me.

I'll try and send an updated patch.

~~ Ricardo

We need to generalize 'package-with-python2'

[Mark H Weaver]

The 'python-dbus' package (called 'dbus-python' upsteam) uses the
'gnu-build-system', and like most other python libraries, there will be
two variants: 'python-dbus' and 'python2-dbus'.  Unfortunately,
'package-with-python2' only works on packages that use
'python-build-system'.  This is a problem.

It wouldn't be so bad to use 'inherit' to create 'python2-dbus' from
'python-dbus', but the more serious problem is that unless we generalize
'package-with-python2', it won't work properly on any package that uses
'python-dbus' as an input.

On the other hand, I realize that 'package-with-explicit-python'
intentionally avoids traversing into packages unless they use
'python-build-system', and that this is important for efficiency.

Any thoughts on how best to solve this?

  Mark

Re: [PATCH] gnu: inkscape: Update to 0.91.

[Daniel Pimentel]

On 2015-02-02 22:41, David Thompson wrote:

Mark H Weaver  writes:


Looks good to me.  Please push!


Pushed, thanks!

Allright, I did upgrade and it's work, thanks.
--
Daniel Pimentel (d4n1)

Re: 0.8.1 kernel panics

[Omar Radwan]

I think I know your problem. In your filesystems declaration,

(file-systems (cons (file-system
(device "root")
(title 'label)
(mount-point "/")
(type "ext4"))
  %base-file-systems))

You left the default pseudo entry for (device), you need to enter your
hdd partition label that you plan installing GSD on. For example it
should be like this:

(file-systems (cons (file-system
(device "/dev/sda1")
(title 'label)
(mount-point "/")
(type "ext4"))
  %base-file-systems))

On Tue, Feb 3, 2015 at 6:50 PM, Kete Foy  wrote:
> Hello, a couple of us are having kernel panics after installing 0.8.1 and
> getting past Grub. I installed on a laptop, but attached is someone's
> picture of a Qemu installation. I am having the same Call Trace. The
> installer booted, but the first boot failed. I also notice an error flash in
> between the words "loading grub" and seeing Grub, but it disappears before I
> can read it. I am sure that the partition has the suggested label root:
> checked with e2label. Also attached is my /etc/config.scm.