[PATCH] gnu: Add woof.

[Clément Lassieur]

---
 gnu/packages/web.scm | 37 +
 1 file changed, 37 insertions(+)

diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index 6ac03fc..7fae9ab 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -12,6 +12,7 @@
 ;;; Copyright © 2016 Efraim Flashner 
 ;;; Copyright © 2016 Rene Saavedra 
 ;;; Copyright © 2016 Ben Woodcroft 
+;;; Copyright © 2016 Clément Lassieur 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -41,6 +42,7 @@
   #:use-module (guix build-system perl)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system r)
+  #:use-module (guix build-system trivial)
   #:use-module (gnu packages)
   #:use-module (gnu packages apr)
   #:use-module (gnu packages documentation)
@@ -3350,3 +3352,38 @@ you'd expect.")
 HTTPS.  It provides a library, libuhttpmock, which implements recording and
 playback of HTTP request/response traces.")
 (license l:lgpl2.1+)))
+
+(define-public woof
+  (package
+(name "woof")
+(version "2012-05-31")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"http://www.home.unix-ag.org/simon/woof-;
+version ".py"))
+  (sha256
+   (base32
+"0wjmjhpg6xlid33yi59j47q2qadz20sijrqsjahj30vngz856hyq"
+(build-system trivial-build-system)
+(arguments
+ '(#:modules ((guix build utils))
+   #:builder
+   (begin
+ (use-modules (guix build utils))
+ (let* ((source (assoc-ref %build-inputs "source"))
+(out(assoc-ref %outputs "out"))
+(bin(string-append out "/bin"))
+(python (assoc-ref %build-inputs "python")))
+   (mkdir-p bin)
+   (with-directory-excursion bin
+ (copy-file source "woof")
+ (patch-shebang "woof" (list (string-append python "/bin")))
+ (chmod "woof" #o555))
+(inputs `(("python" ,python-2)))
+(home-page "http://www.home.unix-ag.org/simon/woof.html;)
+(synopsis "Single file webserver")
+(description "Woof (Web Offer One File) is a small simple stupid webserver
+that can easily be invoked on a single file. Your partner can access the file
+with tools he trusts (e.g. wget).")
+(license l:gpl2+)))
-- 
2.8.3

Fwd: Re: [Patch] ruby-byebug@9.0.5

[Ben Woodcroft]

This got bounced from the list for being over the attachment size limit, 
so sending again with gzipped build.log


On 06/06/16 07:22, Matthew Jordan wrote:

Good Day Ben Woodcroft,

This is what I have so far, although I'm not that familiar with byebug
though. I'll try to dig a bit deeper to get a better understanding of
what's going on.


Thanks for looking into it.

[..]

I had a go at re-enabling tests which were disabled in the original
package - see the attached patch. Unfortunately it is still failing a
few tests. Would you like to take a look into why this might be?

Here a summary of test info. The test
"Byebug::SaveTest#test_save_shows_a_success_message" seems to fail cause
it's looking for a file in a home directory that doesn't exist. Setting
the HOME variable seems to solve that.


Good plan. I'm not sure how you set HOME in your package, but setting it
to /tmp seems to give less errors, though there is still 4 of them.

The first one seems to be due to "File.realpath" returning a form the
test isn't expecting:

e.g. expected;
  "--> #0 Byebug::ByebugTest201606081021q3p5qfClass.to_int(str#String)
at
/tmp/nix-build-ruby-byebug-9.0.5.drv-0/byebug_test20160608-102-1q3p5qf.rb:16
observed
  "--> #0 Byebug::ByebugTest201606081021q3p5qfClass.to_int(str#String)
at
.../tmp/nix-build-ruby-byebug-9.0.5.drv-0/byebug_test20160608-102-1q3p5qf.rb:16",

This might be fixable by patching line 76 of this file:
https://github.com/deivid-rodriguez/byebug/blob/24ad09b8f84531a7d5b112e6e7932bbc13fb7086/test/support/test_case.rb

I've not had time to look at the other tests, some are the same as the
errors you found. Are you able to take a look please?

Thanks,
ben



>From c323ab6c9d1e9d8cfa7f6b879e17826f7e1ef62e Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Thu, 2 Jun 2016 22:06:46 +1000
Subject: [PATCH] gnu: ruby-byebug: Update to 9.0.5.

* gnu/packages/ruby.scm (ruby-byebug): Update to 9.0.5.
[source]: Use 'GitHub' source.
[arguments]: Enable tests.
[native-inputs]: Add dependencies for tests.
---
 gnu/packages/ruby.scm | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 527f76b..327a6a4 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -2757,17 +2757,49 @@ with PostgreSQL 8.4 and later.")
 (define-public ruby-byebug
   (package
 (name "ruby-byebug")
-(version "6.0.2")
+(version "9.0.5")
 (source
  (origin
(method url-fetch)
-   (uri (rubygems-uri "byebug" version))
+   (uri (string-append
+ "https://github.com/deivid-rodriguez/byebug/archive/v; version
+ ".tar.gz"))
+   (file-name (string-append name "-" version ".tar.gz"))
(sha256
 (base32
- "0537h9qbhr6csahmzyn4lk1g5b2lcligbzd21gfy93nx9lbfdnzc"
+ "0apgk5d2s68rzmzli09ryqigbk2nx7k5r01qw0iz51pp7m7hm34l"
 (build-system ruby-build-system)
 (arguments
- '(#:tests? #f)) ; no tests
+ `(#:phases
+   (modify-phases %standard-phases
+ ;; Most of the dependencies are not needed for building and testing,
+ ;; so remove them.
+ (add-before 'build 'remove-dependencies
+   (lambda _
+ (substitute* "Gemfile"
+   (("gem .*") ""))
+ (substitute* "Rakefile"
+   (("require 'chandler/tasks'") ""))
+ #t))
+ ;; Tests require an installed gem, so run tests after install phase.
+ (delete 'check)
+ (add-after 'install 'check-after-install
+   (lambda* (#:key outputs #:allow-other-keys)
+ (setenv "HOME" "/tmp")
+ (setenv "GEM_PATH"
+ (string-append
+  (getenv "GEM_PATH")
+  ":"
+  (gem-home (assoc-ref outputs "out")
+,(package-version ruby
+ (and (system* "rake" "compile")
+  (zero? (system* "rake" "test"
+(native-inputs
+ `(("bundler" ,bundler)
+   ("ruby-yard" ,ruby-yard)
+   ("ruby-rake-compiler" ,ruby-rake-compiler)
+   ("ruby-simplecov" ,ruby-simplecov)
+   ("ruby-pry" ,ruby-pry)))
 (synopsis "Debugger for Ruby 2")
 (description "Byebug is a Ruby 2 debugger implemented using the Ruby 2
 TracePoint C API for execution control and the Debug Inspector C API for call
-- 
2.7.4




build.log.gz
Description: application/gzip

Re: [PATCH] gnu: Add nethack.

[Leo Famulari]

On Wed, Jun 08, 2016 at 02:05:32PM -0400, Kei Kebreau wrote:
> I'm not so sure. Is there a way that I can explicitly access the
> home directory of the user that invokes guix? That is, something
> clearer than "~/.nethack"?

Do we have any package definitions that write to '/home/$USER'? I would
rather we didn't do that as a side effect of installing the package.

It's really the responsibility of the packaged software to set this up
when the user first runs it. If it can't, the user can copy the
"template" state files from '/gnu/store/...-nethack/whatever' into their
home directory.

Have you asked the NetHack maintainers for advice?

Re: [PATCH] gnu: Add guile-gnome

[David Pirotte]

Hello Patrick,

> ...
> +(modify-phases %standard-phases
> +  (add-before 'configure 'pre-configure
> +   (lambda* (#:key outputs #:allow-other-keys)
> + (let ((out (assoc-ref outputs "out")))
> +   (substitute* (find-files "." "^Makefile.in$")
> + (("guilemoduledir =.*guile/site" all)
> + (string-append all "/2.0")))
> +  #t))
> ...

Just curious: why do you (string-append all "/2.0")? Is this a guix guideline 
maybe?

IMO, G-wrap, Guile-Cairo and Guile-Gnome should all be installed in the
directory returned by (%global-site-dir)

Cheers,
David


pgpEZWbaK85H1.pgp
Description: OpenPGP digital signature

Re: [PATCH] gnu: Add nethack.

[Kei Kebreau]

On Wed, 08 Jun 2016 14:59:35 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> Leo Famulari  skribis:
> 
> > On Mon, Jun 06, 2016 at 04:25:41PM -0400, Kei Kebreau wrote:  
> >> l...@gnu.org (Ludovic Courtès) wrote:  
> >> > > + (add-after 'move-state-files 'wrap-program  
> >> > 
> >> > Do we really need this wrapper?  Can’t we instead take it as a
> >> > patch from Debian or something?  I’m not a fan of inline Bash
> >> > code, and not very confident of scripts that do ‘rm -rf’.  :-)
> >> >   
> >> Unfortunately, Debian doesn't have any related patches because it's
> >> state files are writable in the equivalent of our store
> >> directories. It seems like the bash script will have to stay for
> >> the sake of functionality unless someone comes up with something
> >> cleaner, though I prefer to avoid them. Long ago, I lost a
> >> GNU/Linux installation to "rm -rf"...  
> >
> > If Nethack lacks the ability to configure the location of the state
> > files, there is still a string (or several) in the source code that
> > looks like '/usr/share/nethack'. I think we should change this
> > string to something more appropriate instead of wrapping Nethack.  
> 
> Yeah, I would also prefer something along these lines.
> 
> What do you think, Kei?  Does that sound doable?
> 
> Thanks,
> Ludo’.

I'm not so sure. Is there a way that I can explicitly access the
home directory of the user that invokes guix? That is, something
clearer than "~/.nethack"?

-- 
Kei (GPG Key: 4096R/E6A5EE3C19467A0D)


pgpZYqQjOOdDt.pgp
Description: OpenPGP digital signature

Re: [PATCH] gnu: Add guile-gnome

[Patrick Hetu]

Ludovic Courtès @ 2016-06-08 09:19 EDT:

> Patr>From 66baa02e5683a309588ae0a68a7d1b918ad72d8e Mon Sep 17 00:00:00 2001
From: Patrick Hetu 
Date: Wed, 8 Jun 2016 13:18:07 -0400
Subject: [PATCH] gnu: g-wrap: Fix installation path

* gnu/packages/guile.scm (g-wrap): Add 2.0/ to the installation path
---
 gnu/packages/guile.scm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 74e58c4..04c3f03 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -939,6 +939,16 @@ capabilities.")
("guile-lib" ,guile-lib)))
 (inputs
  `(("libffi" ,libffi)))
+(arguments
+  `(#:phases
+(modify-phases %standard-phases
+  (add-before 'configure 'pre-configure
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+   (substitute* (find-files "." "^Makefile.in$")
+ (("guilemoduledir =.*guile/site" all)
+ (string-append all "/2.0")))
+  #t))
 (synopsis "Generate C bindings for Guile")
 (description "G-Wrap is a tool and Guile library for generating function
 wrappers for inter-language calls.  It currently only supports generating Guile
-- 
2.7.4

ick Hetu  skribis:
>
>> Ludovic Courtès @ 2016-05-28 12:06 EDT:
>>
>>> Pushed as 9b381643f009025d97dfc0b82d2c00800c204380 with a few minor
>>> changes:
>> [...]
>> Still, the current g-wrap package needs a new patch to fix his Makefile.in
>> because the native-search-paths hooks won't find it for Guile 2.0.
>
> But it works well to build guile-gnome AFAICS.  When is it a problem?

I'm getting this error in a simple test script:

In ice-9/boot-9.scm:
2951: 3 [define-module* (gnome gw gtk) #:filename ...]
2926: 2 [resolve-imports ((#) (#) (#) (#) ...)]
2867: 1 [resolve-interface (g-wrap gw standard) #:select ...]
In unknown file:
   ?: 0 [scm-error misc-error #f ...]

ERROR: In procedure scm-error:
ERROR: no code for module (g-wrap gw standard)

because the g-wrap code is under:

/gnu/store/...-g-wrap-1.9.15/share/guile/site
/gnu/store/...-g-wrap-1.9.15/share/guile/site/g-wrap.scm
/gnu/store/...-g-wrap-1.9.15/share/guile/site/g-wrap
/gnu/store/...-g-wrap-1.9.15/share/guile/site/g-wrap/compat.scm
/gnu/store/...-g-wrap-1.9.15/share/guile/site/g-wrap/config.scm

and not /gnu//share/guile/2.0/g-wrap/...

> But yeah, patching it to match the native-search-paths is a good idea.

ok, I've attached the patch.

>> Also, should I rename it to guile-g-wrap at the same time?
>
> I don’t think so, because it’s both a program and a library, not just a
> library (I see that this rule mine and is not spelled out in “Packaging
> Guidelines”; it probably should, if there’s consensus.)

ok.

Patrick

Re: Question: purging a package from the store

[Pjotr Prins]

On Wed, Jun 08, 2016 at 03:33:50PM +0200, Ludovic Courtès wrote:
> Good to see you’re running your own service!

It is used for GeneNetwork - a complex web service. It uses git for
byte-identical installs and a Guix server for distributing the
binaries. This is my current way to making sure everyone is running
the exact same software tree and get binary installs.

The installation notes are here:

  
https://github.com/pjotrp/genenetwork2/blob/paper/doc/README.org#quick-installation-recipe

It is not as easy as 'guix package -i genenetwork2'. But then, it
works (TM). People are installing it this way.

Pj.
-- 

Re: Adding wc to Bournish

[Ludovic Courtès]

Efraim Flashner  skribis:

> On Sun, Jun 05, 2016 at 10:37:12PM +0200, Ludovic Courtès wrote:

[...]

>> I’ll commit a couple of fixes for bugs I just found and that prevent us
>> from doing:
>> 
>>   (compile "ls" #:from %bournish-language #:to 'scheme).

(This should be be ‘read-and-compile’, not ‘compile’.)

Done in f82c58539e1f7b9b864e68ea2ab0c6a17c15fbb5.  Take a look at
tests/bournish.scm for examples of what is expected.

> From ebce5076177314bfd17a53019b3f6b6888762b01 Mon Sep 17 00:00:00 2001
> From: Efraim Flashner 
> Date: Sun, 22 May 2016 14:56:06 +0300
> Subject: [PATCH] bournish: Add `wc' command.
>
> * guix/build/bournish.scm (file-size, wc-c-command, wc-l-command,
> lines+chars, wc-command, wc-command-implementation): New variables.
> (%commands): Add wc command.

[...]

> +(define* (wc-command-implementation filelist #:optional args)

‘files’, not ‘filelist’.

> +  (let ((files (filter (lambda (file)
> + (catch 'system-error
> +   (lambda ()
> + (lstat file))
> +   (lambda args
> +  (let ((errno (system-error-errno args)))
> +   (format (current-error-port) "~a: ~a~%"
> +   file (strerror errno))
> +   #f

‘stat’ rather than ‘fstat’.

> +(for-each
> +  (lambda (file)
> +(let-values (((lines chars)
> +  (call-with-input-file file lines+chars)))
> +(match args
> +  (#\l
> +   (format #t "~a ~a~%" lines file))
> +  (#\c
> +   (format #t "~a ~a~%" chars file))
> +  (_
> +   (format #t "~a ~a ~a~%" lines chars file)
> +  files)))

OK.

> +(define (wc-command args . rest)
> +  (let* ((flags (cond ((string=? args "-l") #\l)
> +  ((string=? args "-c") #\c)
> +  (else #\nul; no flags, "args" is a file

I’d rather make it:

  (define (wc-commands . args)
(cond ((member "-l" args) …)
  ((member "-c" args) …)
  (else …)))

Instead of the #\nul thing, I think it’d be best to have separate
procedures for -l, -c, and the other case.

> +((@@ (guix build bournish) wc-command-implementation)
> + (if (char=? flags #\nul) (cons args rest) rest) flags)))

This is still not emitting code.  :-)  IOW, there should be a quasiquote
here.

You can see that by running:

  (use-modules (system base compile) (guix build bournish))
  (read-and-compile (open-input-string "wc -l foo")
#:from %bournish-language #:to 'scheme)

This should return something like:

  `((@ (guix build bournish) wc-l-command-implementation) '("foo"))

Makes sense?  We’re almost done.

Please take a look at

to make the last review super fast.  ;-)

Thank you!

Ludo’.

Re: [PATCH] gnu: Add higan.

[Ludovic Courtès]

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

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

[...]

>> In what sense is it unsuitable?  It’s OK to have a couple of patches,
>> but it’s not quite OK to host a fork of the upstream package, IMO (at
>> the very least, it can create confusion and make it harder to see how it
>> differs from the “real” package.)
>
> The repo is just for having a consistent place from which the source can
> be fetched, as the author doesn't want source bundles to be downloaded
> from his website.  No changes to the code are made.
>
> The repo at GitLab didn't seem to tag releases properly.  That being
> said, now that I look at it, it seems more like an oversight for v098.
> Other releases seem to be tagged quite consistently:
>
> https://gitlab.com/higan/higan/tags
>
> Should we use that repo instead?  It's a bit more official than mine.

Yes, I think it would be more appropriate.

>>>   * The program insists on looking in ~/.local/share for some data files
>>> that are actually installed in $prefix/share; does my strategy here
>>> look OK, in that I wrap the executable to copy the data files into
>>> ~/.local/share every time the program is run?
>>
>> Sounds like a sledgehammer no?  :-)
>>
>> If those files are immutable, what about patching Higan to look for
>> those files in $datadir instead?
>
> Apparently, the files that are part of the distribution are pure data
> files, i.e. fine to be read-only.  However, the directory hierarchy of
> which they're a part needs to be writable, as higan creates further
> files there.  With that cp -r, the directory hierarchy is made sure to
> be there, and the data files made sure to be up to date.
>
> Although I didn't look too closely at the sources, patching higan to do
> things differently would presumably be a nontrivial task, since it seems
> bent on doing things in terms of this directory structure that contains
> both pure data and read-write data files.

Hmm OK.  What do other distros do?

Thank you!

Ludo’.

Re: 01/01: gnu: vlc: Update to 2.2.4 [fixes CVE-2016-5108].

[Ludovic Courtès]

efr...@flashner.co.il (Efraim Flashner) skribis:

> commit a134cc8e93428bf6f309de54e5c944705d30418f
> Author: Efraim Flashner 
> Date:   Wed Jun 8 17:11:06 2016 +0300
>
> gnu: vlc: Update to 2.2.4 [fixes CVE-2016-5108].
> 
> * gnu/packages/video.scm (vlc): Update to 2.2.4.
> [inputs]: Remove qt, add qtbase.

IMO it would have been best to make it two separate patches.

> [arguments]: Add phase to disable display test.

> + (add-before 'configure 'remove-visual-tests
> +   ;; Some of the tests require using the display to test out VLC,
> +   ;; which fails in our sandboxed build system

Usually this is addressed by starting Xvfb (there are several examples
of that.)  Would it work here?

> + (substitute* "test/run_vlc.sh"
> +  (("./vlc --ignore-config") "echo"))

What happened with indentation?  :-)

Thanks for the security update!

Ludo’.

[PATCH] gnu: cross-libc: Cross build the correct libc for GNU/Hurd systems.

[Manolis Ragkousis]

Hello everyone,

This is a simplified version of the patch from wip-hurd for core-updates.

I want to point some things out.

In this version we only have one cross-libc which inherits from the
correct libc in base.scm through the use of the glibc-macro.  This
simplifies things a lot.

-(propagated-inputs `(("kernel-headers" ,xlinux-headers)))
+(propagated-inputs `(("kernel-headers" ,(cross-kernel-headers
target

The correct headers are determined by (cross-kernel-headers target).

 (native-inputs `(("cross-gcc" ,xgcc)
  ("cross-binutils" ,xbinutils)
+ ,@(if (string-match (or "i586-pc-gnu" "i586-gnu")
target)
+   `(("cross-mig" ,xmig))
+   '())
  ,@(package-inputs glibc) ;FIXME: static-bash
  ,@(package-native-inputs glibc)

cross-mig is added only when target is i586-gnu or i586-pc-gnu.

@@ -343,12 +483,14 @@ XBINUTILS and the cross tool chain."
   "CROSS_CPLUS_INCLUDE_PATH"
   "CROSS_OBJC_INCLUDE_PATH"
   "CROSS_OBJCPLUS_INCLUDE_PATH"))
+  ;; We need this for GNU/Hurd.
+  (setenv "CROSS_LIBRARY_PATH" (string-append kernel "/lib"))
   #t))
   ,phases

When target is Hurd, we need to setup CROSS_LIBRARY_PATH for libpthread
to find libihash from hurd-core-headers/lib. The way I did it works for
Hurd and doesn't create any problems when targeting Linux.

-   ,@(package-arguments glibc))
+   ;; Package-arguments does not use the correct libc, so we use
+   ;; (cross-libc-for-target ...) to determine the correct one.
+   ,@(package-arguments (cross-libc-for-target target)))

,@(package-arguments glibc)) was not detecting the correct libc so I
used (cross-libc-for-target target) to fix that. Maybe there is a better
solution for this.

WDYT?

Thank you,
Manolis
From 63749df1aabfbceeefd500208bb66fb85a013e82 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis 
Date: Wed, 8 Jun 2016 17:15:00 +0300
Subject: [PATCH] gnu: cross-libc: Cross build the correct libc for GNU/Hurd
 systems.

* gnu/packages/cross-base.scm (cross-libc): Add xgnumach-headers, xmig,
  xhurd-headers, xglibc/hurd-headers, xhurd-minimal, xhurd-core-headers,
  cross-kernel-headers and cross-libc-for-target.
  [arguments]: Set "CROSS_LIBRARY_PATH".
  [propagated-inputs]: Use "cross-kernel-headers" to determine the correct headers.
  [native-inputs]: Use "cross-mig" when target is GNU/Hurd.
---
 gnu/packages/cross-base.scm | 149 +++-
 1 file changed, 147 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 58cd38b..db2e104 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2013, 2014, 2015, 2016 Ludovic Courtès 
 ;;; Copyright © 2014, 2015 Mark H Weaver 
 ;;; Copyright © 2016 Jan Nieuwenhuizen 
+;;; Copyright © 2016 Manolis Fragkiskos Ragkousis 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -25,6 +26,7 @@
   #:use-module (gnu packages base)
   #:use-module (gnu packages commencement)
   #:use-module (gnu packages linux)
+  #:use-module (gnu packages hurd)
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix utils)
@@ -33,6 +35,7 @@
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26)
   #:use-module (ice-9 match)
+  #:use-module (ice-9 regex)
   #:export (cross-binutils
 cross-libc
 cross-gcc))
@@ -311,6 +314,141 @@ XBINUTILS and the cross tool chain."
("cross-binutils" ,xbinutils)
,@(package-native-inputs linux-libre-headers)
 
+  (define xgnumach-headers
+(package (inherit gnumach-headers)
+  (name (string-append (package-name gnumach-headers)
+   "-cross-" target))
+
+  (native-inputs `(("cross-gcc" ,xgcc)
+   ("cross-binutils" ,xbinutils)
+   ,@(package-native-inputs gnumach-headers)
+
+  (define xmig
+(package (inherit mig)
+  (name (string-append "mig-cross"))
+  (arguments
+   `(#:modules ((guix build gnu-build-system)
+(guix build utils)
+(srfi srfi-26))
+ #:phases (alist-cons-before
+   'configure 'set-cross-headers-path
+   (lambda* (#:key inputs #:allow-other-keys)
+ (let* ((mach (assoc-ref inputs "cross-gnumach-headers"))
+(cpath (string-append mach "/include")))
+   (for-each (cut setenv <> cpath)
+ '("CROSS_C_INCLUDE_PATH"
+   "CROSS_CPLUS_INCLUDE_PATH"
+   

[PATCH] gnu: cross-gcc-arguments: Add Hurd-core-headers lib directory to the "CROSS_LIBRARY_PATH".

[Manolis Ragkousis]

Hello everyone,

Thanks to the previous patch for cross-libc, this patch is the only
change needed for cross-gcc to work properly when targeting GNU/Hurd.

Thank you,
Manolis

>From 77b12cc2aa1a79a2f15b96d80a14d76e3501aeb1 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis 
Date: Wed, 8 Jun 2016 17:46:19 +0300
Subject: [PATCH] gnu: cross-gcc-arguments: Add Hurd-core-headers lib directory
 to the "CROSS_LIBRARY_PATH".

* gnu/packages/cross-base.scm (cross-gcc-arguments)[arguments]: Add Hurd-core-headers lib
directory to the "CROSS_LIBRARY_PATH".
---
 gnu/packages/cross-base.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index db2e104..fd2fc4e 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -187,7 +187,9 @@ may be either a libc package or #f.)"
   "CROSS_OBJC_INCLUDE_PATH"
   "CROSS_OBJCPLUS_INCLUDE_PATH")))
 (setenv "CROSS_LIBRARY_PATH"
-(string-append libc "/lib"))
+(string-append libc "/lib"
+   ;; We need this for GNU/Hurd.
+   ":" kernel "/lib"))
 (for-each
  (lambda (var)
(and=> (getenv var)
-- 
2.8.2

Re: Question: purging a package from the store

[Ludovic Courtès]

Hello!

Pjotr Prins  skribis:

> Our caching server gives a consistent failure for one package. It
> exists in the store and 'guix gc checks' pass.
>
>   guix substitute: error: download from
>   
> 'http://guix.genenetwork.org:8080/nar/sqd3q1xq5fsbga00bwhghi9shi7xdaac-gtk+-3.18.2'
>   failed: 404, "Not Found"

It looks a lot like , which we should really
fix now.

Good to see you’re running your own service!

Ludo’.

Re: [PATCH 2/3] gnu: Remove unused patch.

[Ludovic Courtès]

Leo Famulari  skribis:

> * gnu/packages/patches/expat-CVE-2015-1283-refix.patch: Delete file.
> * gnu/local.mk (dist_patch_DATA): Remove it.

OK!

Re: [PATCH 0/3] Expat and libxslt changes for core-updates

[Ludovic Courtès]

Efraim Flashner  skribis:

> FWIW debian's expat-2.1.1(-3) still has the cve-2015-1283 applied. Also,
> there's 2 new cves, cve-2012-6702 and cve-2016-5300
> https://www.debian.org/security/2016/dsa-3597
> https://sources.debian.net/src/expat/2.1.1-3/debian/patches/

Oh, good catch.

Ludo’.

Re: [PATCH 3/3] gnu: libxslt: Update to 1.1.29.

[Ludovic Courtès]

Leo Famulari  skribis:

> * gnu/packages/patches/libxslt-CVE-2015-7995.patch,
> gnu/packages/patches/libxslt-remove-date-timestamps.patch: Delete files.
> * gnu/packages/xml.scm: Update to 1.1.29.
> [source]: Remove patches.

LGTM, thanks!

Ludo'.

Re: [PATCH 1/3] gnu: expat: Fix CVE-2016-0718.

[Ludovic Courtès]

Leo Famulari  skribis:

> This "cherry-picks" part of 119b83989dd9edd1e8ba6cd379d159d024cbc61d
> from the master branch to core-updates.
>
> * gnu/packages/xml.scm (expat)[source]: Use patch.

LGTM, but is expat-CVE-2016-0718.patch still in core-updates?

Did I mess things up when I merged master into core-updates yesterday?

Thank you for paying attention.  :-)

Ludo’.

Re: CFP: GNU Hacker Meeting 2016

[Ludovic Courtès]

Efraim Flashner  skribis:

> I'll be there! Just booked my plane ticket. Come and be one of the first
> to sign my gpg key!

Jelle Licht  skribis:

> That looks very interesting. Getting there is feasible for me, so I have
> a reservation of some bus tickets. This is probably a good opportunity
> to get into the whole gpg key deal as well :-).

Awesome, I’m glad we can meet there!

Please consider submitting a talk about what you’re doing as part of
GSoC.  It doesn’t have to be formal, it can be 15mn if you think that’s
enough or 45mn if you have a lot of (intelligible to a non-expert
audience ;-)) things to say, and demos are certainly welcome.

Cheers,
Ludo’.

Re: [PATCH] gnu: Add higan.

[Taylan Ulrich Bayırlı/Kammer]

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

> taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> Some things to note about this package & questions:
>>
>> - There's no official VCS repo and the author doesn't want automated
>>   tools to download files from his homepage; there's an unofficial git
>>   repo at GitLab but I found it unsuitable so I'm hosting the sources
>>   specifically for Guix at GitHub now:
>>
>>   https://github.com/TaylanUB/higan
>
> In what sense is it unsuitable?  It’s OK to have a couple of patches,
> but it’s not quite OK to host a fork of the upstream package, IMO (at
> the very least, it can create confusion and make it harder to see how it
> differs from the “real” package.)

The repo is just for having a consistent place from which the source can
be fetched, as the author doesn't want source bundles to be downloaded
from his website.  No changes to the code are made.

The repo at GitLab didn't seem to tag releases properly.  That being
said, now that I look at it, it seems more like an oversight for v098.
Other releases seem to be tagged quite consistently:

https://gitlab.com/higan/higan/tags

Should we use that repo instead?  It's a bit more official than mine.

>>   * The program insists on looking in ~/.local/share for some data files
>> that are actually installed in $prefix/share; does my strategy here
>> look OK, in that I wrap the executable to copy the data files into
>> ~/.local/share every time the program is run?
>
> Sounds like a sledgehammer no?  :-)
>
> If those files are immutable, what about patching Higan to look for
> those files in $datadir instead?

Apparently, the files that are part of the distribution are pure data
files, i.e. fine to be read-only.  However, the directory hierarchy of
which they're a part needs to be writable, as higan creates further
files there.  With that cp -r, the directory hierarchy is made sure to
be there, and the data files made sure to be up to date.

Although I didn't look too closely at the sources, patching higan to do
things differently would presumably be a nontrivial task, since it seems
bent on doing things in terms of this directory structure that contains
both pure data and read-write data files.

> Thanks, and sorry for the delay!

No problem, thanks for the review. :-)

> Ludo’.

Taylan


P.S.: I already pushed a patch yesterday, but can push fixes as desired.

Re: [PATCH] gnu: Add guile-gnome

[Ludovic Courtès]

Patrick Hetu  skribis:

> Ludovic Courtès @ 2016-05-28 12:06 EDT:
>
>> Pushed as 9b381643f009025d97dfc0b82d2c00800c204380 with a few minor
>> changes:
>>
>>> +(define-public guile-g-wrap
>>
>> This one is already available in (gnu packages guile).  :-)
>
> Oops, I was looking for guile-g-wrap instead of g-wrap...
>
> Still, the current g-wrap package needs a new patch to fix his Makefile.in
> because the native-search-paths hooks won't find it for Guile 2.0.

But it works well to build guile-gnome AFAICS.  When is it a problem?

But yeah, patching it to match the native-search-paths is a good idea.

> Also, should I rename it to guile-g-wrap at the same time?

I don’t think so, because it’s both a program and a library, not just a
library (I see that this rule mine and is not spelled out in “Packaging
Guidelines”; it probably should, if there’s consensus.)

Thanks!

Ludo’.

Re: [PATCH 2/2] gnu: Add ruby-puma.

[Thompson, David]

On Wed, Jun 8, 2016 at 8:55 AM, Ben Woodcroft  wrote:
> gnu/packages/ruby.scm (ruby-puma): New variable.
> gnu/packages/patches/ruby-puma-ignore-broken-test.patch: New file.
> gnu/local.mk (dist_patch_DATA): Add it.
> ---
>  gnu/local.mk   |  1 +
>  .../patches/ruby-puma-ignore-broken-test.patch | 13 +++
>  gnu/packages/ruby.scm  | 41 
> ++
>  3 files changed, 55 insertions(+)
>  create mode 100644 gnu/packages/patches/ruby-puma-ignore-broken-test.patch
>
> diff --git a/gnu/local.mk b/gnu/local.mk
> index ff476be..5ff5075 100644
> --- a/gnu/local.mk
> +++ b/gnu/local.mk
> @@ -733,6 +733,7 @@ dist_patch_DATA = 
>   \
>%D%/packages/patches/rpm-CVE-2014-8118.patch \
>%D%/packages/patches/rsem-makefile.patch \
>%D%/packages/patches/ruby-concurrent-ignore-broken-test.patch\
> +  %D%/packages/patches/ruby-puma-ignore-broken-test.patch   \
>%D%/packages/patches/ruby-symlinkfix.patch\
>%D%/packages/patches/ruby-tzinfo-data-ignore-broken-test.patch\
>%D%/packages/patches/rush-CVE-2013-6889.patch\
> diff --git a/gnu/packages/patches/ruby-puma-ignore-broken-test.patch 
> b/gnu/packages/patches/ruby-puma-ignore-broken-test.patch
> new file mode 100644
> index 000..fb653dc
> --- /dev/null
> +++ b/gnu/packages/patches/ruby-puma-ignore-broken-test.patch
> @@ -0,0 +1,13 @@
> +diff --git a/test/test_integration.rb b/test/test_integration.rb
> +index d9b189c..6e21180 100644
> +--- a/test/test_integration.rb
>  b/test/test_integration.rb
> +@@ -115,7 +115,7 @@ class TestIntegration < Test::Unit::TestCase
> + assert_kind_of Thread, t.join(1), "server didn't stop"
> +   end
> +
> +-  def test_phased_restart_via_pumactl
> ++  def no_test_phased_restart_via_pumactl
> + if Puma.jruby? || Puma.windows?
> +   assert true
> +   return
> diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
> index d2b49ba..add5a32 100644
> --- a/gnu/packages/ruby.scm
> +++ b/gnu/packages/ruby.scm
> @@ -3939,6 +3939,47 @@ part of the Prawn PDF generator.")
>  ;; for details."
>  (license (list license:gpl2 license:gpl3 license:ruby
>
> +(define-public ruby-puma
> +  (package
> +(name "ruby-puma")
> +(version "3.4.0")
> +(source
> + (origin
> +   (method url-fetch)
> +   ;; Fetch from GitHub because distributed gem does not contain tests.
> +   (uri (string-append "https://github.com/puma/puma/archive/v;
> +   version ".tar.gz"))
> +   (file-name (string-append name "-" version ".tar.gz"))
> +   (sha256
> +(base32
> + "10svyj2jk949y1dmkxyzipk1ddzl4iz9limrcws1zhpganpvq3j8"))
> +   ;; Ignore broken test reported upstream.
> +   ;; https://github.com/puma/puma/issues/995
> +   (patches (search-patches "ruby-puma-ignore-broken-test.patch"
> +(build-system ruby-build-system)
> +(arguments
> + `(#:phases
> +   (modify-phases %standard-phases
> + (add-before 'build 'fix-gemspec
> +   (lambda _
> + (substitute* "puma.gemspec"
> +   (("git ls-files") "find * |sort"))
> + #t)

Food for thought: With the prevalence of "git ls-files" in gemspecs
(thanks to Bundler), maybe we should consider adding a phase to
ruby-build-system that performs this substitution.

> +(native-inputs
> + `(("ruby-hoe" ,ruby-hoe)
> +   ("ruby-rake-compiler" ,ruby-rake-compiler)
> +   ("ruby-hoe-git" ,ruby-hoe-git)
> +   ("ruby-rack" ,ruby-rack)))

Why are these native inputs?  rake-compiler makes sense because it's
build-time only, but rack is most definitely a runtime dependency that
should be in propagated-inputs.  What environment have you been using
to test these packages?

> +(synopsis "Simple, concurrent HTTP server for Ruby/Rack")
> +(description
> + "Puma is a simple, fast, threaded, and highly concurrent HTTP 1.1 server
> +for Ruby/Rack applications.  Puma is intended for use in both development and
> +production environments.  In order to get the best throughput, it is highly
> +recommended that you use a Ruby implementation with real threads like 
> Rubinius
> +or JRuby.")
> +(home-page "http://puma.io;)
> +(license license:expat)))
> +
>  (define-public ruby-hoe-git
>(package
>  (name "ruby-hoe-git")
> --
> 2.7.4
>
>

Re: [GSoC] Integrating npm into the Guix ecosystem

[Ludovic Courtès]

Hello!

Jelle Licht  skribis:

> It has been some time since my last mail to this list, so I wanted to
> share what I have been up to. For the people who might want to watch
> along after today, I will be posting the changes that should not break
> everything immediately to [1].

Glad to see there’s already a build system and an importer!

I think it’s indeed a good idea to have them in master early.  That will
hopefully allow others to give it a try and provide feedback.

As a pre-review ;-), could be make sure you add a bunch of tests for the
importer (see tests/{cran,cpan,elpa,gem,hackage}.scm for examples), and
mention ‘node-build-system’ under “Build Systems” in doc/guix.texi?

> The current importer functions as expected for the "90%" of packages
> that I tried. A problem that I ran into that I could not recognize as
> easily in other importers is the fact that the npm community only
> distributes the artifacts that you need to run the npm modules, but not
> to build them. In most trivial cases, there are literally no
> differences, but especially for more complicated packages involving
> transpilation steps, this poses a problem.
>
> As such, the importer can not actually 'know' of the location of the
> source. Right now it uses some limited heuristics to probe GitHub
> repositories for a tarball release, and if these are not found or the
> sources are hosted at non-GH sites, it tries to check out a tag
> according to the npm packaging conventions (SemVer).

Interesting.

> The most important thing that needs to happen right now would be to
> extend the range of packages that are buildable by the build system. A
> combination of working towards having working 'large' packages and test
> frameworks should help me quickly identify problems. This will be my
> main focus for the next week.

Sounds like you’re on the right track.  :-)

I’m not qualified to comment on the specific npm issues.  I think you
may be interested in the recursive importer that Ricardo recently
submitted for CRAN, because recursive imports probably makes a lot of
sense for a report as big as npm (as in ‘guix import npm -r jquery’).

Thanks for the update!

Ludo’.

Re: [PATCH 1/2] gnu: Add ruby-hoe-git.

[Thompson, David]

On Wed, Jun 8, 2016 at 8:55 AM, Ben Woodcroft  wrote:
> * gnu/packages/ruby.scm (ruby-hoe-git): New variable.
> ---
>  gnu/packages/ruby.scm | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
> index 527f76b..d2b49ba 100644
> --- a/gnu/packages/ruby.scm
> +++ b/gnu/packages/ruby.scm
> @@ -3939,6 +3939,28 @@ part of the Prawn PDF generator.")
>  ;; for details."
>  (license (list license:gpl2 license:gpl3 license:ruby
>
> +(define-public ruby-hoe-git
> +  (package
> +(name "ruby-hoe-git")
> +(version "1.6.0")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (rubygems-uri "hoe-git" version))
> +   (sha256
> +(base32
> + "10jmmbjm0lkglwxbn4rpqghgg1ipjxrswm117n50adhmy8yij650"
> +(build-system ruby-build-system)
> +(native-inputs
> + `(("ruby-hoe" ,ruby-hoe)))

Why is this a native input?

Also, I would have expected git to be an input.  How does this gem
interact with git?

> +(synopsis "Hoe plugins for tighter Git integration")
> +(description
> + "This package provides a set of Hoe plugins for tighter Git integration.
> +It provides tasks to automate release tagging and pushing and changelog
> +generation.")
> +(home-page "http://github.com/jbarnette/hoe-git;)
> +(license license:expat)))
> +
>  (define-public ruby-sequel
>(package
>  (name "ruby-sequel")
> --
> 2.7.4
>
>

- Dave

Re: [PATCH] gnu: Add nethack.

[Ludovic Courtès]

Leo Famulari  skribis:

> On Mon, Jun 06, 2016 at 04:25:41PM -0400, Kei Kebreau wrote:
>> l...@gnu.org (Ludovic Courtès) wrote:
>> > > + (add-after 'move-state-files 'wrap-program
>> > 
>> > Do we really need this wrapper?  Can’t we instead take it as a patch
>> > from Debian or something?  I’m not a fan of inline Bash code, and not
>> > very confident of scripts that do ‘rm -rf’.  :-)
>> > 
>> Unfortunately, Debian doesn't have any related patches because it's
>> state files are writable in the equivalent of our store directories. It
>> seems like the bash script will have to stay for the sake of
>> functionality unless someone comes up with something cleaner, though I
>> prefer to avoid them. Long ago, I lost a GNU/Linux installation to
>> "rm -rf"...
>
> If Nethack lacks the ability to configure the location of the state
> files, there is still a string (or several) in the source code that
> looks like '/usr/share/nethack'. I think we should change this string to
> something more appropriate instead of wrapping Nethack.

Yeah, I would also prefer something along these lines.

What do you think, Kei?  Does that sound doable?

Thanks,
Ludo’.

[no subject]

[Ben Woodcroft]

Thanks in advance.
ben

[PATCH 1/2] gnu: Add ruby-hoe-git.

[Ben Woodcroft]

* gnu/packages/ruby.scm (ruby-hoe-git): New variable.
---
 gnu/packages/ruby.scm | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 527f76b..d2b49ba 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -3939,6 +3939,28 @@ part of the Prawn PDF generator.")
 ;; for details."
 (license (list license:gpl2 license:gpl3 license:ruby
 
+(define-public ruby-hoe-git
+  (package
+(name "ruby-hoe-git")
+(version "1.6.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (rubygems-uri "hoe-git" version))
+   (sha256
+(base32
+ "10jmmbjm0lkglwxbn4rpqghgg1ipjxrswm117n50adhmy8yij650"
+(build-system ruby-build-system)
+(native-inputs
+ `(("ruby-hoe" ,ruby-hoe)))
+(synopsis "Hoe plugins for tighter Git integration")
+(description
+ "This package provides a set of Hoe plugins for tighter Git integration.
+It provides tasks to automate release tagging and pushing and changelog
+generation.")
+(home-page "http://github.com/jbarnette/hoe-git;)
+(license license:expat)))
+
 (define-public ruby-sequel
   (package
 (name "ruby-sequel")
-- 
2.7.4

[PATCH 2/2] gnu: Add ruby-puma.

[Ben Woodcroft]

gnu/packages/ruby.scm (ruby-puma): New variable.
gnu/packages/patches/ruby-puma-ignore-broken-test.patch: New file.
gnu/local.mk (dist_patch_DATA): Add it.
---
 gnu/local.mk   |  1 +
 .../patches/ruby-puma-ignore-broken-test.patch | 13 +++
 gnu/packages/ruby.scm  | 41 ++
 3 files changed, 55 insertions(+)
 create mode 100644 gnu/packages/patches/ruby-puma-ignore-broken-test.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index ff476be..5ff5075 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -733,6 +733,7 @@ dist_patch_DATA =   
\
   %D%/packages/patches/rpm-CVE-2014-8118.patch \
   %D%/packages/patches/rsem-makefile.patch \
   %D%/packages/patches/ruby-concurrent-ignore-broken-test.patch\
+  %D%/packages/patches/ruby-puma-ignore-broken-test.patch   \
   %D%/packages/patches/ruby-symlinkfix.patch\
   %D%/packages/patches/ruby-tzinfo-data-ignore-broken-test.patch\
   %D%/packages/patches/rush-CVE-2013-6889.patch\
diff --git a/gnu/packages/patches/ruby-puma-ignore-broken-test.patch 
b/gnu/packages/patches/ruby-puma-ignore-broken-test.patch
new file mode 100644
index 000..fb653dc
--- /dev/null
+++ b/gnu/packages/patches/ruby-puma-ignore-broken-test.patch
@@ -0,0 +1,13 @@
+diff --git a/test/test_integration.rb b/test/test_integration.rb
+index d9b189c..6e21180 100644
+--- a/test/test_integration.rb
 b/test/test_integration.rb
+@@ -115,7 +115,7 @@ class TestIntegration < Test::Unit::TestCase
+ assert_kind_of Thread, t.join(1), "server didn't stop"
+   end
+ 
+-  def test_phased_restart_via_pumactl
++  def no_test_phased_restart_via_pumactl
+ if Puma.jruby? || Puma.windows?
+   assert true
+   return
diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index d2b49ba..add5a32 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -3939,6 +3939,47 @@ part of the Prawn PDF generator.")
 ;; for details."
 (license (list license:gpl2 license:gpl3 license:ruby
 
+(define-public ruby-puma
+  (package
+(name "ruby-puma")
+(version "3.4.0")
+(source
+ (origin
+   (method url-fetch)
+   ;; Fetch from GitHub because distributed gem does not contain tests.
+   (uri (string-append "https://github.com/puma/puma/archive/v;
+   version ".tar.gz"))
+   (file-name (string-append name "-" version ".tar.gz"))
+   (sha256
+(base32
+ "10svyj2jk949y1dmkxyzipk1ddzl4iz9limrcws1zhpganpvq3j8"))
+   ;; Ignore broken test reported upstream.
+   ;; https://github.com/puma/puma/issues/995
+   (patches (search-patches "ruby-puma-ignore-broken-test.patch"
+(build-system ruby-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-before 'build 'fix-gemspec
+   (lambda _
+ (substitute* "puma.gemspec"
+   (("git ls-files") "find * |sort"))
+ #t)
+(native-inputs
+ `(("ruby-hoe" ,ruby-hoe)
+   ("ruby-rake-compiler" ,ruby-rake-compiler)
+   ("ruby-hoe-git" ,ruby-hoe-git)
+   ("ruby-rack" ,ruby-rack)))
+(synopsis "Simple, concurrent HTTP server for Ruby/Rack")
+(description
+ "Puma is a simple, fast, threaded, and highly concurrent HTTP 1.1 server
+for Ruby/Rack applications.  Puma is intended for use in both development and
+production environments.  In order to get the best throughput, it is highly
+recommended that you use a Ruby implementation with real threads like Rubinius
+or JRuby.")
+(home-page "http://puma.io;)
+(license license:expat)))
+
 (define-public ruby-hoe-git
   (package
 (name "ruby-hoe-git")
-- 
2.7.4

Re: [PATCH 4/5] gnu: Add AqBanking.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * gnu/packages/gnucash.scm (aqbanking): New variable.

Nothing to add to what Leo wrote.  :-)

Re: [PATCH 5/5] gnu: gnucash: Add support for AqBanking.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * gnu/packages/gnucash.scm (gnucash)[inputs]: Add aqbanking.
> [arguments]: Add configure flag to enable aqbanking.

LGTM!

Thanks,
Ludo'.

Re: [PATCH 3/5] gnu: Add gwenhywfar.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * gnu/packages/gnucash.scm (gwenhywfar): New variable.

[...]

> +(inputs
> + `(("libgcrypt" ,libgcrypt)
> +   ("gnutls" ,gnutls)
> +   ("openssl" ,openssl)

Do all three libraries show up in ‘guix gc --references’?  In particular
are there programs linked against both OpenSSL and GnuTLS?  That seems a
bit crazy to me, but if it needs to be, then that’s fine!

Otherwise the package LGTM.

Thank you!

Ludo’.

Re: [PATCH 1/5] gnu: gnucash: Add "license:" prefix.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * gnu/packages/gnucash.scm: Import licenses with "license:" prefix.
> (gnucash)[license]: Add prefix.

OK!

Re: [PATCH 2/5] gnu: xmlsec: Enable gnutls support.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> * gnu/packages/xml.scm (xmlsec)[native-inputs]: Add pkg-config.

Good catch.  LGTM!

Ludo’.

Re: [PATCH] Quick-start guide

[Ludovic Courtès]

Hello!

yoo...@gmail.com skribis:

> +@node Quick Setup
> +@section Quick Setup
> +
> +So you just want the quick-and-dirty guide? Assuming you have some
> familiarity
> +with GNU/Linux systems in general and have installed one several times
> before
> +you can probably get started with a few notes while citing
> +@pxref{GNU Distribution} as necessary. As this is a quick-setup guide
> we'll use
> +some example defaults.
> +
> +The general idea is that you will:
> +@itemize
> +@item @uref{https://gnu.org/software/guix/download/, Download} the USB
> installer
> +@item Transfer the image to a USB stick (@pxref{USB Stick Installation})
> +using dd
> +@item Boot the USB stick
> +@item Configure @pxref{Preparing for Installation,Networking}
> +@item Set your @xref{Preparing for Installation,Disk Partitioning}
> +(using an msdos label instead of a gpt label might be easier at the moment)
> +@item Mount your partitions (e.g. /mnt)
> +@item Run (again, e.g. /mnt) @command{herd start cow-store /mnt}
> +@item Create a system configuration file using
> +@xref{Proceeding with the Installation} and
> +@xref{Using the Configuration System} as guides. It is suggested to start
> +with the bare-bones template as you can easily re-configure your system
> +once it is up.
> +@item Using /mnt/root/guix_configs/config00.scm as the example config file
> +and /mnt as the example install mount point, run
> +@command{guix system init /mnt/root/guix_configs/config00.scm /mnt}
> +@item Cross your fingers and grab a beer
> +@item If you're using reasonably new hardware and a bare-bones config
> +then guix should be done before your beverage and you can run
> +@command{reboot}
> +@end itemize

[...]

At first sight this seems redundant with the “System Installation”
section, no?

What shortcoming are you trying to address?

Thanks for helping out!

Ludo’.

Re: GuixSD Manual - Preparing for Installation - Networking

[Ludovic Courtès]

Kete Foy  skribis:

> Hello, in the GuixSD documentation, in section 7.1.4.2, under the
> *Wireless connection* heading, I needed to put quotes around /my-ssid/
> to get the wireless service started.

Fixed, thanks!

Ludo’.

Re: Solving the ‘package-name->name+version’ name conflict.

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> David Thompson  writes:
>
>> * guix/build/emacs-build-system.scm (gnu:unpack)
>> (store-file->elisp-source-file, unpack): New procedures.
>> (%standard-phases): Use the new unpack procedure.
>> ---
>>  guix/build/emacs-build-system.scm | 23 +++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/guix/build/emacs-build-system.scm 
>> b/guix/build/emacs-build-system.scm
>> index f0a9a6e..4fd36d1 100644
>> --- a/guix/build/emacs-build-system.scm
>> +++ b/guix/build/emacs-build-system.scm
>> @@ -21,6 +21,7 @@
>>#:use-module (guix build utils)
>>#:use-module (guix build emacs-utils)
>>#:use-module (srfi srfi-1)
>> +  #:use-module (srfi srfi-11)
>>#:use-module (srfi srfi-26)
>>#:use-module (ice-9 rdelim)
>>#:use-module (ice-9 regex)
>> @@ -39,6 +40,27 @@
>>  ;; archive signature.
>>  (define %install-suffix "/share/emacs/site-lisp/guix.d")
>>  
>> +(define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
>> +
>> +(define (store-file->elisp-source-file file)
>> +  "Convert file, a store file name for an Emacs Lisp source file, into a 
>> file
>> +name that has been stripped of the hash and version number."
>> +  (let-values (((name version)
>> +(package-name->name+version
> ^^^
>
> This is the old ‘package-name->name+version’ from (guix build utils)
> which has been replaced when possible by a new one in (guix utils) using
> '@' as a delimiter.  While I think it was OK to use it to fix previously
> written code, I don't want Guix to build upon the old one.

We kept this procedure in (guix build utils) because it’s still used.
In this case, we have “foo-1.2”, and we want to get the values “foo” and
“1.2”, so using this procedure is the right thing to do.

> Time has come to resolve this ugly and confusing name conflict.  The
> problem is that I don't fully understand the rationale behind this
> temporary solution, so I can't help much.
>
> Ludo: Since you are the mind behind it, I think you are in the best
> position to figure this out or at least explain to us “mere mortals”
> what is possible and what is not.  :)

Naming is one of the hardest problems in programming, you know!  :-)

So we have:

  (guix build utils):package-name->name+version
which expects “foo-1.2”

  (guix utils):package-name->name+version
which expects “foo@1.2”

There’s no doubt we need to keep both, so what we can do is rename one
of them.

What about renaming the one in (guix utils) to
‘package-specification->name+version’?

Bonus points if you provide a patch!  :-)

Thanks,
Ludo’.

Re: [Patch] ruby-byebug@9.0.5

[Ben Woodcroft]

On 06/06/16 07:54, Matthew Jordan wrote:

In general, Guix handles this just fine. But somebody has to maintain
all those versions ;) We often suggest that if one user needs some old
version of a package, they maintain the package privately. For example,
using $GUIX_PACKAGE_PATH.

Ah okay, that makes sense. Does this also also apply to compilers and
runtime environments? As I have two pachtes for the current versions of
node (JavaScript runtime), one is the reccomended version and the other
represents the latest stable version.


There are some examples of multiple versions being included in Guix e.g. 
Ruby itself, GCC, etc, and we do tend to more commonly keep multiple 
versions of compilers and runtime environments.



Although I have not submitted them yet.


Good luck. there are others working on node you may be able to 
coordinate with.


Thanks,
ben

Re: [PATCH] gnu: Add higan.

[Ludovic Courtès]

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

> Some things to note about this package & questions:
>
> - There's no official VCS repo and the author doesn't want automated
>   tools to download files from his homepage; there's an unofficial git
>   repo at GitLab but I found it unsuitable so I'm hosting the sources
>   specifically for Guix at GitHub now:
>
>   https://github.com/TaylanUB/higan

In what sense is it unsuitable?  It’s OK to have a couple of patches,
but it’s not quite OK to host a fork of the upstream package, IMO (at
the very least, it can create confusion and make it harder to see how it
differs from the “real” package.)

> - I forgot if there's a guideline for this: the release versions are
>   called 'v097', 'v098' etc. with always a 'v' in front.  Should that
>   'v' appear in the version field of the package or should it be
>   stripped?

I’d strip it.

> - As seems to be tradition among emulator developers, the build system
>   and the program's handling of the file system are a big pile of poo,
>   so:
>
>   * Is it principally OK to reuse the standard `build' and `install'
> phase procedures a second time, just with the CWD changed, as I do
> here?

It’s OK, though I often find it clearer to use
‘with-directory-excursion’ so that we can more easily reason about the
current directory.

>   * The program insists on looking in ~/.local/share for some data files
> that are actually installed in $prefix/share; does my strategy here
> look OK, in that I wrap the executable to copy the data files into
> ~/.local/share every time the program is run?

Sounds like a sledgehammer no?  :-)

If those files are immutable, what about patching Higan to look for
those files in $datadir instead?

Thanks, and sorry for the delay!

Ludo’.

Re: [PATCH 0/3] Expat and libxslt changes for core-updates

[Leo Famulari]

On Wed, Jun 08, 2016 at 07:50:25AM -0400, Leo Famulari wrote:
> On Wed, Jun 08, 2016 at 01:10:16PM +0300, Efraim Flashner wrote:
> > On Tue, Jun 07, 2016 at 08:54:05PM -0400, Leo Famulari wrote:
> > > Leo Famulari (3):
> > >   gnu: expat: Fix CVE-2016-0718.
> > >   gnu: Remove unused patch.
> > >   gnu: libxslt: Update to 1.1.29.
> > 
> > FWIW debian's expat-2.1.1(-3) still has the cve-2015-1283 applied. Also,
> > there's 2 new cves, cve-2012-6702 and cve-2016-5300
> > https://www.debian.org/security/2016/dsa-3597
> > https://sources.debian.net/src/expat/2.1.1-3/debian/patches/
> 
> Thanks for the review!
> 
> Okay, later today I'll revise this patchset, and also try patching the
> master branch's expat against the newly disclosed bugs.

As always, if somebody wants to handle patching expat on the master
branch sooner than I can, I won't mind :)

Re: [PATCH 0/3] Expat and libxslt changes for core-updates

[Leo Famulari]

On Wed, Jun 08, 2016 at 01:10:16PM +0300, Efraim Flashner wrote:
> On Tue, Jun 07, 2016 at 08:54:05PM -0400, Leo Famulari wrote:
> > Leo Famulari (3):
> >   gnu: expat: Fix CVE-2016-0718.
> >   gnu: Remove unused patch.
> >   gnu: libxslt: Update to 1.1.29.
> 
> FWIW debian's expat-2.1.1(-3) still has the cve-2015-1283 applied. Also,
> there's 2 new cves, cve-2012-6702 and cve-2016-5300
> https://www.debian.org/security/2016/dsa-3597
> https://sources.debian.net/src/expat/2.1.1-3/debian/patches/

Thanks for the review!

Okay, later today I'll revise this patchset, and also try patching the
master branch's expat against the newly disclosed bugs.

Re: [PATCH 2/4] gnu: ruby-activesupport: Add 'ruby-tzinfo-data' propagated input.

[Ben Woodcroft]

On 06/06/16 18:12, Ludovic Courtès wrote:

Ben Woodcroft  skribis:


* gnu/packages/ruby.scm (ruby-activesupport)[propagated-inputs]: Add
'ruby-tzinfo-data'.

This one LGTM, thanks.  :-)


To be fair, so did Dave, but he left the list of his reply. Thanks you two.

I took all your comments on board Dave, made a few more small changes 
and pushed.

ben

Re: [PATCH 0/3] Expat and libxslt changes for core-updates

[Efraim Flashner]

On Tue, Jun 07, 2016 at 08:54:05PM -0400, Leo Famulari wrote:
> It was not that simple to make these changes for core-updates, so I'm
> sending the patches for review.
> 
> For expat, I "re-fix" a bug that was fixed on master already. This
> bug-fix is actually reachable from the HEAD of core-updates, but for
> some reason doesn't exist at HEAD. According to MITRE the bug does
> affect all currently released versions of expat:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0718
> 
> I noticed a "left-over" patch for a bug that is apparently fixed in the
> version of expat on core-updates (2.1.1), so it is deleted:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1283
> 
> For libxslt, I update to the latest version and remove patches that are
> no longer needed. The timestamp issue was addressed upstream [0] and the
> bug has been fixed in this version. These patches were strangely no
> longer listed in 'gnu/local.mk'.
> 
> [0]
> https://git.gnome.org/browse/libxslt/commit/?id=e57df303eca25a2a3f9e0625c29f4b20177858cc
> 
> Leo Famulari (3):
>   gnu: expat: Fix CVE-2016-0718.
>   gnu: Remove unused patch.
>   gnu: libxslt: Update to 1.1.29.
> 
>  gnu/local.mk   |  1 -
>  .../patches/expat-CVE-2015-1283-refix.patch| 42 --
>  gnu/packages/patches/libxslt-CVE-2015-7995.patch   | 29 --
>  .../patches/libxslt-remove-date-timestamps.patch   | 66 
> --
>  gnu/packages/xml.scm   |  9 ++-
>  5 files changed, 4 insertions(+), 143 deletions(-)
>  delete mode 100644 gnu/packages/patches/expat-CVE-2015-1283-refix.patch
>  delete mode 100644 gnu/packages/patches/libxslt-CVE-2015-7995.patch
>  delete mode 100644 gnu/packages/patches/libxslt-remove-date-timestamps.patch
> 
> -- 
> 2.8.3
> 

FWIW debian's expat-2.1.1(-3) still has the cve-2015-1283 applied. Also,
there's 2 new cves, cve-2012-6702 and cve-2016-5300
https://www.debian.org/security/2016/dsa-3597
https://sources.debian.net/src/expat/2.1.1-3/debian/patches/

-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Question: purging a package from the store

[Pjotr Prins]

Our caching server gives a consistent failure for one package. It
exists in the store and 'guix gc checks' pass.

  guix substitute: error: download from
  
'http://guix.genenetwork.org:8080/nar/sqd3q1xq5fsbga00bwhghi9shi7xdaac-gtk+-3.18.2'
  failed: 404, "Not Found"

Now I want to purge it without running a full gc. Next reinstall it
and see if it gets fixed.

What is the suggested method for fully purging a package from the store?

Pj.