Re: [PATCH] Fix gfortran (?)

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> with this patch applied I can build randomjungle without having to add
> the “lib” output of gfortran to the package inputs.
>
> This is related to the changes I pushed in commit 82f145e to fix
> bug#19733, which seems to have broken the build of randomjungle and
> slepc, among others.
>
> Is this acceptable?  Should we do this for all gfortran variants then?

Ping :)

This seems to be the easiest way to fix gfortran.

~~ Ricardo

Re: On my way to my first patch, need review

[Ricardo Wurmus]

vinc...@cloutier.co writes:

>> and it built fine but when I tried to run it I got this error:
>>
>>
>> ~$ wayback_machine_downloader
>> /gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/dependency.rb:319:in
>>  
>> `to_specs': Could not find 'wayback_machine_downloader' (>= 0.a) among 11 
>> total gem(s) (Gem::LoadError)
>> Checked in 
>> 'GEM_PATH=/home/rain/.gem/ruby/2.3.0:/gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/gems/2.3.0',
>>  
>> execute `gem env` for more information
>>  from 
>> /gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/dependency.rb:328:in
>>  
>> `to_spec'
>>  from 
>> /gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:65:in
>>  
>> `gem'
>>  from /home/rain/.guix-profile/bin/wayback_machine_downloader:22:in 
>> `'
>>
>> I'm not sure what the fix would be.
>
>
>
>
> It worked for me when I added `export 
> GEM_PATH="/home/vincent/.guix-profile/lib/ruby/gems/2.3.0"
> ` to my bashrc. I run Guix on top of Debian, so there might be subtle 
> difference with ruby gems on GuixSD.

In that case the executable should be wrapped with the appropriate
GEM_PATH.  There are a couple of packages under “gnu/packages/” that
have a “wrap-programs” phase doing the same.

~~ Ricardo

Re: On my way to my first patch, need review

[Chris Marusich]

Ben Woodcroft  writes:

> 5) I speak fluent French, can I add a description and summary in
> French?
> 
>
> I'm not sure on this sorry.

I think Guix uses GNU Gettext [1] to localize strings, including those
used in package descriptions, but I don't know very much about it.
Since Ludo has committed over 80% of the commits involving the guix/po
directory, he's probably the one who can answer your questions about how
to add a translation.

[1] https://www.gnu.org/software/gettext/manual/index.html

-- 
Chris


signature.asc
Description: PGP signature

Re: ffmpeg package update

[Efraim Flashner]

On Thu, 24 Mar 2016 16:58:43 +
ra...@openmailbox.org wrote:

> Hello,
> 
> Our ffmpeg package is old (version 2.8.6 but 3.0 is available now).
> 
> I noticed this because I found a segfault in a program that uses mpv: 
> mkdir -p a ; mpv a. Updating ffmpeg fixes this.
> 
> Removed libquvi from it as that has been removed from mpv and is not 
> being updated.
> 
> Changed a configure flag --disable-mipsdspr1 to --disable-mipsdsp - this 
> is just a rename. You can read about this here 
>  
> since it's just a rename I do not think this will break ffmpeg on MIPS.

Like Leo said, patch looks good.

Don't forget to add yourself to the copyright line at the top :)

The commit message, it doesn't match up with the rest of the commit messages. 
There are many examples to copy from in the repo, and there's also the GNU 
manual here[0] which covers this also. Feel free to ask here or in irc if you 
need help with it, and can you send an updated patch?

Thanks!


[0] 
https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs

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


pgp10Jk8SDkcQ.pgp
Description: OpenPGP digital signature

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Chris Marusich]

Leo Famulari  writes:

> On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
>> Thomas Ingram  writes:
>> 
>> > On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
>> >> Personally, I would like to view the “wizard” as a helper, and not as
>> >> something that hides everything and turns people into “end users.”
>> 
>> Wow, Ludo, what do you have against "end users"?
>
> Speaking for myself, one thing that I like about Guix and GuixSD are
> that they make it relatively easy to learn and alter the system, at
> least compared to some other GNU / Linux operating systems.
>
> By encouraging users to learn how to alter their system, they will
> unwittingly become computer programmers, which I think is beneficial for
> software freedom. I'd prefer that to a world where only 1% of people
> have the ability to effect change in software (the current situation).
>
> I understand the situation is not a dichotomy; our system should not be
> unnecessarily difficult to use.

I couldn't agree more!

-- 
Chris


signature.asc
Description: PGP signature

Re: ffmpeg package update

[Efraim Flashner]

On Sun, 27 Mar 2016 19:20:54 -0400
Leo Famulari  wrote:

> On Thu, Mar 24, 2016 at 04:58:43PM +, ra...@openmailbox.org wrote:
>  [...]  
> 
> Upstream commit 2d40a09b6 removed support for libquvi:
> https://github.com/FFmpeg/FFmpeg/commit/2d40a09b6e73230b160a505f01ed1acf169e1d9f
> 
>  [...]  
> 
> $ guix refresh -l ffmpeg
> Building the following 15 packages would ensure 20 dependent packages
> are rebuilt: mplayer-1.2.1 emotion-generic-players-1.17.0 obs-0.13.2
> mpv-0.16.0 cmus-2.7.1 pianobar-2015.11.22 mpd-0.19.12 kodi-16.0
> gst-libav-1.6.3 blender-2.76b guile-gnunet-0.0.383eac2 gnunet-gtk-0.10.1
> retroarch-1.3.1 audacity-2.1.0 synfigstudio-1.0.2
> 
> Does anyone want to check if some of those still work with this change,
> or should we just apply the update?
> 

I can build out mpv to make sure it still works.

Rain1- looks like you forgot to add yourself to the copyright at the top

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


pgp9NHMnUx_0s.pgp
Description: OpenPGP digital signature

Re: On my way to my first patch, need review

[Ben Woodcroft]

Hi Vincent, thanks for the contribution.

On 26/03/16 15:49, vinc...@cloutier.co wrote:

[..]


First some comments on the patch. In general we try to keep line lengths 
below 80 chars, and not leave blank lines within package definitions.




(define-public wayback-machine-downloader
  (package
(name "wayback-machine-downloader")
(version "0.2.1")
(source
  (origin
(method url-fetch)
(uri (rubygems-uri
   "wayback_machine_downloader"
   version))


Please put the above 3 lines on the same line.


(sha256
  (base32
"1nrwm5bc7vqm02m2x0lylxyya446kg0spg6ksi7dfkrad0l9jq8y"
(build-system ruby-build-system)
(arguments
   `(#:tests? #f ; no rakefile
  ))


Stylistically, we don't leave empty braces alone like this.

It seems there is a Rakefile with a test task defined in the github 
repository, but not in the gem itself. So in this case I would point 
guix to download the source from the github page not rubygems.org, as is 
currently done for ruby-nokogumbo for example:


(define-public ruby-nokogumbo
  (package
(name "ruby-nokogumbo")
(version "1.4.6")
(source (origin
  ;; We use the git reference, because there's no Rakefile 
in the

  ;; published gem and the tarball on Github is outdated.
  (method git-fetch)
  (uri (git-reference
(url "https://github.com/rubys/nokogumbo.git";)
(commit "d56f954d20a")))
  (file-name (string-append name "-" version "-checkout"))
  (sha256
   (base32
"0bnppjy96xiadrsrc9dp8y6wvdwnkfa930n7acrp0mqm4qywl2wl"



(native-inputs
 `(("ruby-rake-compiler" ,ruby-rake-compiler)


Is this really needed?


("ruby-minitest" ,ruby-minitest)))

(synopsis
  "Download website from archive.org's Wayback Machine")


Maybe "Download a website ..." ? Also, please put on one line.


(description
  "Download any website from the Wayback Machine.  Wayback Machine 
by Internet Archive (archive.org) is an awesome tool to view any 
website at any point of time but lacks an export feature.  Wayback 
Machine Downloader brings exactly this.")


I would remove "awesome" as being too opinionated. I think it would also 
make sense to comment on the fact that it is a command line tool.



(home-page
  "https://github.com/hartator/wayback-machine-downloader";)
(license expat)))


Then I ran: `guix package -i wayback-machine-downloader -f 
~/Documents/ruby` and it successfully installed.


So my questions are:

1) Do you guys and gals have a better workflow that includes the git 
repo, so I can send a patch? All I saw in the documentation was about 
building guix itself. I guess I could clone somewhere and use `guix 
package -f`,  but will this be a reliable way of testing? And will 
this make my guix less stable on the long run?


My personal workflow for this situation would be something like this:

$ git checkout -b wayback-machine-downloader origin/master
$ make -j4
... modify gnu/packages/ruby.scm adding the package definition ...
$ ./pre-inst-env guix build -K wayback-machine-downloader
... modify further as necessary until I am happy ...
... run through the checklist of things to do (e.g. list) when 
submitting a package at 
https://www.gnu.org/software/guix/manual/guix.html#Submitting-Patches
$ git diff #check that I'm committing the right code and only the one 
package's code

$ git commit
... edit commit message ...
$ git format-patch -1
... send to guix-devel ...

hope that helps.



2) Should I add "ruby-" before the name of the package? I know 
technically all gems should have "ruby-" before the name, but this is 
designed to be use independently. Could it have multiple names, or is 
it a bad idea?


In this case I would say no, leave it as wayback-machine-downloader 
since it is not intended to be used as a library, rather a command line 
tool.




3) Where does this package belong in the directory?


My guess would be web.scm not ruby.scm.



4) Is the package declaration itself all right? Are packages sorted or 
organized in any way?


This depends on the file being modified, in ruby.scm we just add it to 
the end of the file.




5) I speak fluent French, can I add a description and summary in French?


I'm not sure on this sorry.

Would you mind submitting an updated patch please?
Thanks,
ben

[v2 2/2] gnu: Add nmap.

[Leo Famulari]

From: Taylan Ulrich Bayırlı/Kammer 

* gnu/packages/admin.scm (nmap): New variable.

Co-authored-by: Leo Famulari 
---
 gnu/packages/admin.scm | 81 +-
 1 file changed, 80 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 0d15dd5..377d0c7 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -3,7 +3,7 @@
 ;;; Copyright © 2013 Cyril Roelandt 
 ;;; Copyright © 2014, 2015, 2016 Mark H Weaver 
 ;;; Copyright © 2014, 2015, 2016 Eric Bavier 
-;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer 
+;;; Copyright © 2015, 2016 Taylan Ulrich Bayırlı/Kammer 

 ;;; Copyright © 2015 Alex Sassmannshausen 
 ;;; Copyright © 2015 Eric Dvorsak 
 ;;; Copyright © 2016 Leo Famulari 
@@ -42,8 +42,10 @@
   #:use-module (gnu packages ncurses)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages linux)
+  #:use-module (gnu packages lua)
   #:use-module (gnu packages guile)
   #:use-module (gnu packages gettext)
+  #:use-module (gnu packages pcre)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages tcl)
   #:use-module (gnu packages compression)
@@ -1529,3 +1531,80 @@ 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+)))
+
+(define-public nmap
+  (package
+(name "nmap")
+(version "7.11")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://nmap.org/dist/nmap-"; version
+  ".tar.bz2"))
+  (sha256
+   (base32
+"0jlmq1w0gjqpa7qa523kdj73ndm1xzww2wjvb94hxh6yalargyhk"))
+  (modules '((guix build utils)))
+  (snippet
+   '(map delete-file-recursively
+ ;; Remove bundled lua, pcap, and pcre libraries.
+ ;; FIXME: Remove bundled liblinear once packaged.
+ '("liblua"
+   "libpcap"
+   "libpcre"
+   ;; Remove pre-compiled binares.
+   "mswin32")
+(build-system gnu-build-system)
+(inputs
+ `(("openssl" ,openssl)
+   ("libpcap" ,libpcap)
+   ("pcre" ,pcre)
+   ("lua" ,lua)
+   ;; For 'ndiff'.
+   ("python" ,python-2)))
+
+;; TODO Add zenmap output.
+(outputs '("out" "ndiff"))
+(arguments
+ '(#:configure-flags '("--without-zenmap")
+   #:phases
+   (modify-phases %standard-phases
+ (replace 'install
+   (lambda* (#:key outputs #:allow-other-keys)
+ (define (make out . args)
+   (unless (zero? (apply system* "make"
+ (string-append "prefix=" out)
+ args))
+ (error "make failed")))
+ (define (python-path dir)
+   (string-append dir "/lib/python2.7/site-packages"))
+ (let ((out (assoc-ref outputs "out"))
+   (ndiff (assoc-ref outputs "ndiff")))
+   (for-each mkdir-p (list out ndiff))
+   (make out
+ "install-nmap"
+ "install-nse"
+ "install-ncat"
+ "install-nping")
+   (make ndiff "install-ndiff")
+   (wrap-program (string-append ndiff "/bin/ndiff")
+ `("PYTHONPATH" prefix
+   (,(python-path ndiff)))
+ ;; These are the tests that do not require network access.
+ (replace 'check
+   (lambda _ (zero? (system* "make"
+ "check-nse"
+ "check-ndiff"
+ "check-dns")
+   ;; Nmap can't cope with out-of-source building.
+   #:out-of-source? #f))
+(home-page "https://nmap.org/";)
+(synopsis "Network discovery and security auditing tool")
+(description
+ "Nmap (\"Network Mapper\") is a network discovery and security auditing
+tool.  It is also useful for tasks such as network inventory, managing service
+upgrade schedules, and monitoring host or service uptime.  It also provides an
+advanced netcat implementation (ncat), a utility for comparing scan
+results (ndiff), and a packet generation and response analysis tool (nping).")
+;; This package uses nmap's bundled modified version of libdnet, and
+;; liblinear, which both use a 3-clause BSD license.
+(license (list license:nmap license:bsd-3
-- 
2.7.3

[v2 0/2] Nmap

[Leo Famulari]

Here is another take on adding Nmap to our distribution.

I have built on Taylan's WIP patch, so he retains the bulk of the credit
for his nice use of Nmap's build system to install things into different
outputs.  Taylan, what do you think?

I still can't get Zenmap to work, although I have made a little
progress, so I've left it out for now. So, this uses the
gnu-build-system, rather than glib-or-gtk.

I enabled only the tests that don't require network access.

Feedback?

BTW, Nmap builds reproducibly :)

Leo Famulari (1):
  licenses: Add the nmap license.

Taylan Ulrich Bayırlı/Kammer (1):
  gnu: Add nmap.

 gnu/packages/admin.scm | 81 +-
 guix/licenses.scm  |  6 
 2 files changed, 86 insertions(+), 1 deletion(-)

-- 
2.7.3

[v2 1/2] licenses: Add the nmap license.

[Leo Famulari]

* guix/licenses.scm (nmap): New variable.
---
 guix/licenses.scm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/guix/licenses.scm b/guix/licenses.scm
index 71c0736..265f048 100644
--- a/guix/licenses.scm
+++ b/guix/licenses.scm
@@ -57,6 +57,7 @@
 mpl1.0 mpl1.1 mpl2.0
 ms-pl
 ncsa
+nmap
 openldap2.8 openssl
 psfl public-domain
 qpl
@@ -360,6 +361,11 @@ at URI, which may be a file:// URI pointing the package's 
tree."
"http://directory.fsf.org/wiki/License:IllinoisNCSA";
"https://www.gnu.org/licenses/license-list#NCSA";))
 
+(define nmap
+  (license "Nmap license"
+   "https://svn.nmap.org/nmap/COPYING";
+   "https://fedoraproject.org/wiki/Licensing/Nmap";))
+
 (define openssl
   (license "OpenSSL"
"http://directory.fsf.org/wiki/License:OpenSSL";
-- 
2.7.3

Patches to add s3cmd and python-magic

[Chris Marusich]

Hi,

I've packaged python-magic and s3cmd.  The former provides Python
bindings for libmagic.  It's an alternative to python-file, which is an
existing package that also provides Python bindings for libmagic.  The
latter is a command-line tool for Amazon S3 and CloudFront, which
expects python-magic (not python-file) to be available.

Please refer to the attached patches for details.  Guix lint says the
following about python-magic: "the source file name should contain the
package name".  However, I think maybe that's a bug in guix lint, since
the URI clearly contains the name "python-magic".

Just to be safe, I've tested python2-magic and python-magic, and
confirmed that module "magic" was importable from Python 2 (for the
former case) and Python 3 (for the latter case).  I've also confirmed
that python2-s3cmd installs fine and that I can use it for rudimentary
tasks, like uploading and downloading to/from S3.

I wasn't sure about a few things, so if you have feedback, I would love
to hear it:

* Do I need to provide setuptools as a native input, or will it be
  pulled in automatically?

* Does setuptools really need to be a native input, or can it be a
  regular input?  I understand that native inputs are important for
  cross-compiling, but does this apply to a language like Python which
  compiles to bytecode for a virtual machine?

* In the package definition for python2-s3cmd, should python2-magic be a
  propagated input instead of a regular input?  It seems to work as a
  normal input, so I think the answer is "no", but I understand that
  sometimes this matters for python packages.

Thank you,

-- 
Chris
From d0c858b6b717b837eb2eac95db2fb2f19ca4112a Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Sun, 27 Mar 2016 19:10:48 -0700
Subject: [PATCH 1/2] gnu: add python-magic

* gnu/packages/python.scm (python-magic, python2-magic): New variables.
---
 gnu/packages/python.scm | 67 +++--
 1 file changed, 65 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 88aef9d..f2ef901 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -16,7 +16,7 @@
 ;;; Copyright © 2015, 2016 Erik Edrosa 
 ;;; Copyright © 2015, 2016 Efraim Flashner 
 ;;; Copyright © 2015 Kyle Meyer 
-;;; Copyright © 2015 Chris Marusich 
+;;; Copyright © 2015, 2016 Chris Marusich 
 ;;; Copyright © 2016 Danny Milosavljevic 
 ;;;
 ;;; This file is part of GNU Guix.
@@ -6056,7 +6056,10 @@ Python's @code{ctypes} foreign function interface (FFI).")
 #t))
 (inputs `(("file" ,file)))
 (self-native-input? #f)
-(synopsis "Python bindings to the libmagic file type guesser")))
+(synopsis "Python bindings to the libmagic file type guesser.  Note that
+this module and the python-magic module both provide a \"magic.py\" file;
+these two modules, which are different and were developed separately, both
+serve the same purpose: provide Python bindings for libmagic.")))
 
 (define-public python2-file
   (package-with-python2 python-file))
@@ -8490,3 +8493,63 @@ is made as zipfile like as possible.")
 
 (define-public python2-rarfile
   (package-with-python2 python-rarfile))
+
+(define-public python-magic
+  (package
+(name "python-magic")
+(version "0.4.3")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://github.com/ahupp/python-magic/archive/";
+   version ".tar.gz"))
+   (sha256
+(base32
+ "17bgy92i7sb021f2s4mw1dcvpm6p1mi9jihridwy1pyn8mzvpjgk"
+(build-system python-build-system)
+(arguments
+ ;; The tests are unreliable, so don't run them.  The tests fail
+ ;; under Python3 because they were written for Python2 and
+ ;; contain import statements that do not work in Python3.  One of
+ ;; the tests fails under Python2 because its assertions are
+ ;; overly stringent; it relies on comparing output strings which
+ ;; are brittle and can change depending on the version of
+ ;; libmagic being used and the system on which the test is
+ ;; running.  In my case, under GuixSD 0.10.0, only one test
+ ;; failed, and it seems to have failed only because the version
+ ;; of libmagic that is packaged in Guix outputs a slightly
+ ;; different (but not wrong) string than the one that the test
+ ;; expected.
+ '(#:tests? #f
+   #:phases (modify-phases %standard-phases
+ ;; Replace a specific method call with a hard-coded
+ ;; path to the necessary libmagic.so file in the
+ ;; store.  If we don't do this, then the method call
+ ;; will fail to find the libmagic.so file, which in
+ ;; turn will cause any application using
+ ;; python-magic to fail.
+ (add-before 'build 'hard-code-path-to-libmagic
+   (lambda* (#:key inputs #:allow-other-keys)
+ (let ((file (assoc-ref inputs "file")))
+

[PATCH] environment: Set a default value for PS1.

[David Thompson]

Here's a hopefully uncontroversial patch that sets PS1 in 'guix
environment' containers to something more friendly than what bash shows
by default when PS1 is unset.  OK to push?

>From 10741ce4e09c5990e70c94f5ed650b3561d042a0 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sun, 27 Mar 2016 21:20:19 -0400
Subject: [PATCH] environment: Set a default value for PS1.

* guix/scripts/environment.scm (launch-environment/container): Set PS1
  during container initialization.
---
 guix/scripts/environment.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index fc75d78..6aa5ad0 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -425,6 +425,9 @@ host file systems to mount inside the container."
 (mkdir-p "/bin")
 (symlink bash "/bin/sh")
 
+;; Set a reasonable default PS1.
+(setenv "PS1" "[ENV] \\u@\\h \\w\\$ ")
+
 ;; Setup directory for temporary files.
 (mkdir-p "/tmp")
 (for-each (lambda (var)
-- 
2.7.3


-- 
David Thompson

Re: On my way to my first patch, need review

[vincent]

27. Mar 2016 16:29 by ra...@openmailbox.org:


> On 2016-03-26 22:49, > vinc...@cloutier.co>  wrote:
>> Even though I don't know if I am accepted for GSoC yet, I thought it
>> would be nice to start contributing now! :)
>>
>> I started by adding the gem wayback_machine_downloader (a very useful
>> piece of software by the way).
>>
>> So I used `guix edit ruby` and I copied it in the Documents folder.
>> Then I added somewhere in the middle of the file:
>>
>> (define-public wayback-machine-downloader
>>  (package
>>  (name "wayback-machine-downloader")
>>  (version "0.2.1")
>>  (source
>>  (origin
>>  (method url-fetch)
>>  (uri (rubygems-uri
>>  "wayback_machine_downloader"
>>  version))
>>  (sha256
>>  (base32
>>  "1nrwm5bc7vqm02m2x0lylxyya446kg0spg6ksi7dfkrad0l9jq8y"
>>  (build-system ruby-build-system)
>>  (arguments
>>  `(#:tests? #f ; no rakefile
>>  ))
>>
>>  (native-inputs
>>  `(("ruby-rake-compiler" ,ruby-rake-compiler)
>>  ("ruby-minitest" ,ruby-minitest)))
>>
>>  (synopsis
>>  "Download website from archive.org's Wayback Machine")
>>  (description
>>  "Download any website from the Wayback Machine. Wayback Machine by
>> Internet Archive (archive.org) is an awesome tool to view any website
>> at any point of time but lacks an export feature. Wayback Machine
>> Downloader brings exactly this.")
>>  (home-page
>>  ">> https://github.com/hartator/wayback-machine-downloader>>  [1]")
>>  (license expat)))
>>
>> Then I ran: `guix package -i wayback-machine-downloader -f
>> ~/Documents/ruby` and it successfully installed.
>>
>> So my questions are:
>>
>> 1) Do you guys and gals have a better workflow that includes the git
>> repo, so I can send a patch? All I saw in the documentation was about
>> building guix itself. I guess I could clone somewhere and use `guix
>> package -f`, but will this be a reliable way of testing? And will this
>> make my guix less stable on the long run?
>>
>> 2) Should I add "ruby-" before the name of the package? I know
>> technically all gems should have "ruby-" before the name, but this is
>> designed to be use independently. Could it have multiple names, or is
>> it a bad idea?
>>
>> 3) Where does this package belong in the directory?
>>
>> 4) Is the package declaration itself all right? Are packages sorted or
>> organized in any way?
>>
>> 5) I speak fluent French, can I add a description and summary in
>> French?
>>
>> Thanks!
>> Vincent
>>
>>
>> Links:
>> --
>> [1] >> https://github.com/hartator/wayback-machine-downloader
>
> Hello!
>
> I tested this out on guixsd, I changed (license expat) to (license 
> license:expat)




Going to fix it.




> and it built fine but when I tried to run it I got this error: 
>
>
> ~$ wayback_machine_downloader
> /gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/dependency.rb:319:in
>  
> `to_specs': Could not find 'wayback_machine_downloader' (>= 0.a) among 11 
> total gem(s) (Gem::LoadError)
> Checked in 
> 'GEM_PATH=/home/rain/.gem/ruby/2.3.0:/gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/gems/2.3.0',
>  
> execute `gem env` for more information
>   from 
> /gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/dependency.rb:328:in
>  
> `to_spec'
>   from 
> /gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:65:in
>  
> `gem'
>   from /home/rain/.guix-profile/bin/wayback_machine_downloader:22:in 
> `'
>
> I'm not sure what the fix would be.




It worked for me when I added `export 
GEM_PATH="/home/vincent/.guix-profile/lib/ruby/gems/2.3.0"
` to my bashrc. I run Guix on top of Debian, so there might be subtle 
difference with ruby gems on GuixSD.

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Thompson, David]

On Sun, Mar 27, 2016 at 1:43 PM, Ludovic Courtès  wrote:

> I cannot reproduce the problem with this minimum test case (the two
> ‘mount’ call succeed):
>
> --8<---cut here---start->8---
> (use-modules (guix build syscalls)
>  (gnu build linux-container))
>
> (chdir "/tmp")
> (false-if-exception (delete-file "foo"))
> (false-if-exception (umount "bar"))
> (false-if-exception (delete-file "bar"))
>
> (symlink "/etc/resolv.conf" "foo")
> (close-port (open-output-file "bar"))
> (mount "/tmp/foo" "/tmp/bar" "none" (logior MS_BIND MS_RDONLY))
> (mount "/tmp/foo" "/tmp/bar" "none" (logior MS_BIND MS_RDONLY MS_REMOUNT))
> --8<---cut here---end--->8---
>
> Maybe we should try to throw in ‘call-with-container’ somewhere in there
> to be closer to the actual problem, dunno.
>
> It’s a bit frustrating that we don’t understand the situation.  If you
> wish, I think it’s fine to commit this patch, but please make sure to
> mention that the problem occurs when /etc/resolv.conf is a symlink, and
> add a link to this discussion.

I found the culprit!  This problem occurs with *any* file remounted
read-only from a tmpfs.  In Ubuntu, /etc/resolv.conf is a symlink to
/run/resolvconf/resolv.conf, and /run is a tmpfs.  I did this to
confirm the issue with another file on GuixSD:

echo foobar > /run/user/foo
guix environment --container --expose=/run/user/foo --ad-hoc coreutils

Where /run/user is a tmpfs.  It should fail with an exit status of 1.
I don't know why tmpfs is an issue, nor do I know how work around it.
I've been searching around for answers but haven't found any leads
yet.  Any thoughts?

> (FWIW I’m planning to push have the release ready on Monday night.)

Maybe we'll have to punt on this for the release, but I really hope it
can be fixed in time!  This is the last thing I need to make networked
containers "just work" on Ubuntu-based distros.

- Dave

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Leo Famulari]

On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
> Thomas Ingram  writes:
> 
> > On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
> >> Personally, I would like to view the “wizard” as a helper, and not as
> >> something that hides everything and turns people into “end users.”
> 
> Wow, Ludo, what do you have against "end users"?

Speaking for myself, one thing that I like about Guix and GuixSD are
that they make it relatively easy to learn and alter the system, at
least compared to some other GNU / Linux operating systems.

By encouraging users to learn how to alter their system, they will
unwittingly become computer programmers, which I think is beneficial for
software freedom. I'd prefer that to a world where only 1% of people
have the ability to effect change in software (the current situation).

I understand the situation is not a dichotomy; our system should not be
unnecessarily difficult to use.

Re: ffmpeg package update

[Leo Famulari]

On Thu, Mar 24, 2016 at 04:58:43PM +, ra...@openmailbox.org wrote:
> Hello,
> 
> Our ffmpeg package is old (version 2.8.6 but 3.0 is available now).
> 
> I noticed this because I found a segfault in a program that uses mpv: mkdir
> -p a ; mpv a. Updating ffmpeg fixes this.
> 
> Removed libquvi from it as that has been removed from mpv and is not being
> updated.

Upstream commit 2d40a09b6 removed support for libquvi:
https://github.com/FFmpeg/FFmpeg/commit/2d40a09b6e73230b160a505f01ed1acf169e1d9f

> 
> Changed a configure flag --disable-mipsdspr1 to --disable-mipsdsp - this is
> just a rename. You can read about this here
>  since
> it's just a rename I do not think this will break ffmpeg on MIPS.

$ guix refresh -l ffmpeg
Building the following 15 packages would ensure 20 dependent packages
are rebuilt: mplayer-1.2.1 emotion-generic-players-1.17.0 obs-0.13.2
mpv-0.16.0 cmus-2.7.1 pianobar-2015.11.22 mpd-0.19.12 kodi-16.0
gst-libav-1.6.3 blender-2.76b guile-gnunet-0.0.383eac2 gnunet-gtk-0.10.1
retroarch-1.3.1 audacity-2.1.0 synfigstudio-1.0.2

Does anyone want to check if some of those still work with this change,
or should we just apply the update?

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[myglc2]

Jookia <166...@gmail.com> writes:

> On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
>> Wow, Ludo, what do you have against "end users"?
>
> I think what Ludovic's getting at is that we'd rather have people know their
> tools and experiment, much like Emacs.

OK. But there is a huge community of free software users that suffer
daily from issues that are beautifully addressed by Guix.  Once Guix is
installed and they learn how to select and install software they may not
need, or want, to know anything else.

Don't we want these people to use Guix?

Re: [PATCH 13/13] gnu: Add beets.

[Leo Famulari]

On Sun, Mar 27, 2016 at 05:36:19PM -0400, Leo Famulari wrote:
> On Sat, Mar 26, 2016 at 09:58:32AM -0500, Alex Griffin wrote:
> > I tried building with --rounds=4 on my GuixSD machine, but it errored
> > out after the first build with the same error. Then I tried building
> > with --check on my Debian machine and it succeeded.
> > 
> > Last night on IRC we were discussing this more and I think Leo was going
> > to try incorporating something from the nixos beets package, or else
> > wait until the beets developers could help him.
> 
> On IRC, (the user who I think is) Alex said that they were able to build
> beets with the attached patch.
> 
> All the patch does is invoke the tests with `nosetests -v` instead of
> `python setup.py test`, making use of python2-nose. This is what is done
> by Nixpkgs.
> 
> Is there anybody else who could not build beets before? Would you like
> to test the patch?

And now I see that the beets wiki says that the tests are to be run with
nose:
https://github.com/beetbox/beets/wiki/Testing

So, I applied the patch as 36c2c8c82.

> 
> > -- 
> > Alex Griffin
> > 
> > 
> > On Sat, Mar 26, 2016, at 06:41 AM, Ludovic Courtès wrote:
> > > Leo Famulari  skribis:
> > > 
> > > > Can you try building with '#:parallel-tests? #f', as shown in this link?
> > > 
> > > I was also going to suggest something along these lines.
> > > 
> > > Could you try building with with --rounds=4, say, on your machine?  (Or
> > > --check if it’s already there.)
> > > 
> > > Thanks,
> > > Ludo’.

> From ba2cb8403ab9340ab8a6da534e9db4cc3f2fbb84 Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Sat, 26 Mar 2016 17:53:59 -0400
> Subject: [PATCH] gnu: beets: Run tests with python-nose.
> 
> * gnu/packages/music.scm (nose)[native-inputs]: Add python-nose.
> [arguments]: Replace 'check' and use python-nose.
> ---
>  gnu/packages/music.scm | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
> index 89f49c6..48d6214 100644
> --- a/gnu/packages/music.scm
> +++ b/gnu/packages/music.scm
> @@ -1274,13 +1274,16 @@ websites such as Libre.fm.")
> #:phases
> (modify-phases %standard-phases
>   (add-after 'unpack 'set-HOME
> -   (lambda _ (setenv "HOME" (string-append (getcwd) "/tmp")))
> +   (lambda _ (setenv "HOME" (string-append (getcwd) "/tmp"
> + (replace 'check
> +   (lambda _ (zero? (system* "nosetests" "-v")))
>  (native-inputs
>   `(("python2-beautifulsoup4" ,python2-beautifulsoup4)
> ("python2-flask" ,python2-flask)
> ("python2-setuptools" ,python2-setuptools)
> ("python2-mock" ,python2-mock)
> ("python2-mpd2" ,python2-mpd2)
> +   ("python2-nose" ,python2-nose)
> ("python2-pathlib" ,python2-pathlib)
> ("python2-pyxdg" ,python2-pyxdg)
> ("python2-pyechonest" ,python2-pyechonest)
> -- 
> 2.7.3
> 

Re: [PATCH 0/3] Fix letsencrypt

[Leo Famulari]

On Tue, Mar 22, 2016 at 09:46:09PM -0400, Leo Famulari wrote:
> Earlier today I found that I could not build letsencrypt.
> 
> The recent update to python-hypothesis broke python-pyopenssl, which
> blocked the build of letsencrypt.
> 
> This patch series seems to be the minimum required to get letsencrypt
> building again. I built letsencrypt on these patches and used it to
> issue certificates for a new server.
> 
> The update to python-pytest and python2-pytest will require ~200
> rebuilds [0].

With these changes, libreoffice continues to build successfully for me
on x86-64. I'm currently attempting to cross-build to i686.

> 
> This does not update python-pytest to the latest version, 2.9.1. I could
> not get that to work, and I suspect it will require updates to some core
> Python packages such as python-setuptools.
> 
> In the meantime, I'd like to do this intermediate update to get
> letsencrypt building again. Any objections? If it's okay, should it go
> on master, or onto a staging branch?
> 
> [0] I have re-wrapped this for readability:
> 
> $ guix refresh -l python2-pytest python-pytest 
> Building the following 66 packages would ensure 194 dependent packages
> are rebuilt: python2-pickleshare-0.5 python2-scikit-image-0.11.3
> python2-statsmodels-0.6.1 python2-seaborn-0.5.1 python2-numexpr-2.4.4
> enblend-enfuse-4.1.3 libreoffice-5.0.5.2 seqmagick-0.6.1 pepr-1.0.9
> grit-2.0.2 pbtranscript-tofu-2.2.3.8f5467fe6 macs-2.1.0.20151222
> crossmap-0.2.1 rseqc-2.6.1 pyicoteo-2.0.7 python2-warpedlmm-0.21
> clipper-0.3.0 deeptools-2.1.1 miso-0.5.3 couger-1.8.2 gourmet-0.17.4
> python2-rq-0.5.2 python2-urllib3-1.13.1 python2-ndg-httpsclient-0.4.0
> gajim-0.16.5 python2-docopt-0.6.2 python2-pytest-subtesthack-0.1.1
> python2-alembic-0.8.4 letsencrypt-0.4.2 python2-rauth-0.7.2
> python2-ipython-3.2.1
> simp-le-2015-12-07T040251Z-01afa8c64264a7674e51471ea4bf7ce524d8b77e
> python2-botocore-1.3.17 python2-bandit-0.13.2 python2-swiftclient-2.6.0
> python2-pytest-xdist-1.14 beets-1.3.17 python-flask-0.10.1
> python-pickleshare-0.5 python-numexpr-2.4.4 python-h5py-2.4.0
> shogun-4.0.0 python-biopython-1.66 python-statsmodels-0.6.1
> python-seaborn-0.5.1 python-scikit-learn-0.16.1
> python-scikit-image-0.11.3 idr-2.0.0 python-jellyfish-0.5.3
> python-rq-0.5.2 python-urllib3-1.13.1 python-bandit-0.13.2
> python-pytest-xdist-1.14 awscli-1.9.17 python-alembic-0.8.4
> python-pytest-xprocess-0.9.1 livestreamer-1.12.2 python-acme-0.4.2
> python-responses-0.5.1 python-ipython-3.2.1 git-annex-remote-hubic-0.3.1
> docker-compose-1.5.2 diffoscope-49 python-pylast-1.5.1 khal-0.7.0
> autojump-22.2.4
> 
> Leo Famulari (3):
>   gnu: python-pytest: Update to 2.7.3.
>   gnu: python-cryptography, python-cryptography-vectors: Update to
> 1.3.1.
>   gnu: python-pyopenssl: Update to 16.0.0.
> 
>  gnu/packages/python.scm | 37 -
>  1 file changed, 8 insertions(+), 29 deletions(-)
> 
> -- 
> 2.7.3
> 

Re: [PATCH 0/5] Automake custom test driver using SRFI-64.

[Mathieu Lirzin]

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

> Mathieu Lirzin  skribis:
>
>> this is the debugged version of a patch previously sent here:
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00024.html
>>
>> It is possible to directly checkout 'origin/wip-check' branch to review these
>> patches.  Thanks.
>
> Awesome!  FYI I’m delaying review until after the release, hope that’s
> fine!  (I’m slightly concerned about losing the stdout/stderr of
> guix-daemon and others, but I haven’t looked closely yet.)

No problem.  Thanks for notifying it.

-- 
Mathieu Lirzin

Re: [PATCH 0/2] Add nmap

[Leo Famulari]

On Sun, Mar 27, 2016 at 11:36:23PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Leo Famulari  skribis:
> 
> > This package provides nmap [0].
> 
> Did it fall through the cracks?  :-)

I actually revisited Taylan's version last night. The only problem with
his patch is that the nmap GUI 'zenmap' doesn't run, presumably due to
some search path issues. I made a little progress but it still doesn't
work.

I am going to submit a revision of his patch that leaves 'zenmap' for
later.

> 
> > The nmap source distribution comes with a bunch of its dependencies
> > bundled. This package deletes most of them and replaces them with
> > external libraries.
> >
> > This package currently uses the bundled copies of liblinear and libdnet.
> > Liblinear should be packaged separately [1], but I think that the
> > bundled libdnet should be used, because apparently this bundled version
> > is modified [2] enough that Debian has chosen to use it [3].
> 
> Does liblinear have users outside of nmap?  In practice, if it has no
> life outside of nmap and is developed by the same people, it’s fine to
> keep it inside nmap (it’s not really bundling, or at least not the form
> that is problematic.)

I don't know how often it's used. It seems to me that if it was used by
many projects, it would have a proper build system by now. I spent a
while trying to build nmap with an external copy of the library, but so
far without success.

Re: NEWS for 0.10.0

[Leo Famulari]

On Sun, Mar 27, 2016 at 07:45:48PM +0200, Ludovic Courtès wrote:
> Hello!
> 
> I’ve looked at the 2,200+ commits since 0.9.0 (!) to update ‘NEWS’,
> trying to keep it high-level and readable (nobody’s gonna read it if
> it’s too long ;-)).
> 
> You’re welcome to check what’s in there, making sure your favorite
> feature or bug-fix appears, and posting changes!

There is a typo in this line:

*** ‘guix environment --container’ gracefully handles abnormal exists

s/exists/exits

> 
> The goal is to have everything ready on Monday evening.
> 
> Thanks,
> Ludo’.
> 

Re: [PATCH 0/5] Automake custom test driver using SRFI-64.

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> this is the debugged version of a patch previously sent here:
>
>   https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00024.html
>
> It is possible to directly checkout 'origin/wip-check' branch to review these
> patches.  Thanks.

Awesome!  FYI I’m delaying review until after the release, hope that’s
fine!  (I’m slightly concerned about losing the stdout/stderr of
guix-daemon and others, but I haven’t looked closely yet.)

Ludo’.

Re: NEWS for 0.10.0

[Mathieu Lirzin]

Ludovic Courtès  writes:

> diff --git a/NEWS b/NEWS
> index ec92990..0e907ba 100644
> --- a/NEWS
> +++ b/NEWS
[...]
> -* Changes in 0.9.1 (since 0.9.0)
> +* Changes in 0.10.0 (since 0.9.0)
> +
> +GNU Guix adopted a contributor code of conduct, see ‘CODE-OF-CONDUCT’ in the
> +source tree.

I think it would be reasonable to integrate this news in the current
scheme by not making it top level.  What about moving this news in a
category "Contribution" or "Community"?

While speaking about code of conducts I have found sometimes ago an
alternative version which achieves the same expected effect as the
current one but in a more consensual way:

  
https://wiki.gnome.org/action/show/Foundation/CodeOfConduct?action=show&redirect=CodeOfConduct

Even if I know I belong to the minority who disagree with the
“Contributor Covenant” ideas, I think GNOME code of conduct would fit
better in Guix because it will not associate GNU with a movement using
the term “Open Source” and promoting Github usage.

WDYT?

Thanks,

-- 
Mathieu Lirzin

Re: [PATCH 13/13] gnu: Add beets.

[Leo Famulari]

On Sat, Mar 26, 2016 at 09:58:32AM -0500, Alex Griffin wrote:
> I tried building with --rounds=4 on my GuixSD machine, but it errored
> out after the first build with the same error. Then I tried building
> with --check on my Debian machine and it succeeded.
> 
> Last night on IRC we were discussing this more and I think Leo was going
> to try incorporating something from the nixos beets package, or else
> wait until the beets developers could help him.

On IRC, (the user who I think is) Alex said that they were able to build
beets with the attached patch.

All the patch does is invoke the tests with `nosetests -v` instead of
`python setup.py test`, making use of python2-nose. This is what is done
by Nixpkgs.

Is there anybody else who could not build beets before? Would you like
to test the patch?

> -- 
> Alex Griffin
> 
> 
> On Sat, Mar 26, 2016, at 06:41 AM, Ludovic Courtès wrote:
> > Leo Famulari  skribis:
> > 
> > > Can you try building with '#:parallel-tests? #f', as shown in this link?
> > 
> > I was also going to suggest something along these lines.
> > 
> > Could you try building with with --rounds=4, say, on your machine?  (Or
> > --check if it’s already there.)
> > 
> > Thanks,
> > Ludo’.
>From ba2cb8403ab9340ab8a6da534e9db4cc3f2fbb84 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Sat, 26 Mar 2016 17:53:59 -0400
Subject: [PATCH] gnu: beets: Run tests with python-nose.

* gnu/packages/music.scm (nose)[native-inputs]: Add python-nose.
[arguments]: Replace 'check' and use python-nose.
---
 gnu/packages/music.scm | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
index 89f49c6..48d6214 100644
--- a/gnu/packages/music.scm
+++ b/gnu/packages/music.scm
@@ -1274,13 +1274,16 @@ websites such as Libre.fm.")
#:phases
(modify-phases %standard-phases
  (add-after 'unpack 'set-HOME
-   (lambda _ (setenv "HOME" (string-append (getcwd) "/tmp")))
+   (lambda _ (setenv "HOME" (string-append (getcwd) "/tmp"
+ (replace 'check
+   (lambda _ (zero? (system* "nosetests" "-v")))
 (native-inputs
  `(("python2-beautifulsoup4" ,python2-beautifulsoup4)
("python2-flask" ,python2-flask)
("python2-setuptools" ,python2-setuptools)
("python2-mock" ,python2-mock)
("python2-mpd2" ,python2-mpd2)
+   ("python2-nose" ,python2-nose)
("python2-pathlib" ,python2-pathlib)
("python2-pyxdg" ,python2-pyxdg)
("python2-pyechonest" ,python2-pyechonest)
-- 
2.7.3

Re: [PATCH 0/2] Add nmap

[Ludovic Courtès]

Hi!

Leo Famulari  skribis:

> This package provides nmap [0].

Did it fall through the cracks?  :-)

> The nmap source distribution comes with a bunch of its dependencies
> bundled. This package deletes most of them and replaces them with
> external libraries.
>
> This package currently uses the bundled copies of liblinear and libdnet.
> Liblinear should be packaged separately [1], but I think that the
> bundled libdnet should be used, because apparently this bundled version
> is modified [2] enough that Debian has chosen to use it [3].

Does liblinear have users outside of nmap?  In practice, if it has no
life outside of nmap and is developed by the same people, it’s fine to
keep it inside nmap (it’s not really bundling, or at least not the form
that is problematic.)

Thanks,
Ludo’.

Re: [PATCH 1/3] licenses: Add beerware license.

[Leo Famulari]

On Sun, Mar 27, 2016 at 02:02:11PM -0700, Christopher Allan Webber wrote:
> Efraim Flashner writes:
> 
> > On Sat, 26 Mar 2016 18:50:53 -0700
> > Christopher Allan Webber  wrote:
> >
> >> Leo Famulari writes:
> >> 
> >>  [...]  
> >> 
> >> Now there's a license name bound to cause some confusion!
> >> 
> >> It looks free... I think it would be okay to push.  But maybe if only
> >> one or two packages use it it would be better to just use the
> >> non-copyleft license option?
> >> 
> >
> > I went and doublechecked the license, because I've heard in the past it's 
> > not
> > actually a copyleft license. According to wikipedia[0], it is not copyleft,
> > but is GPL compatable, and recognized by the FSF. The language of the 
> > license
> > does allow for not buying the author a beer.
> >
> >
> > [0] https://en.wikipedia.org/wiki/Beerware
> 
> It's not a copyleft license, right.  That's why I suggested non-copyleft
> :)
> 
> For example, in unzip:
> 
> (license (license:non-copyleft "file://LICENSE"
>"See LICENSE in the distribution."))

I'll do whatever the consensus says.

But what about the IBM license on the base64 component of signify? What
should I do about that?

Re: About collision encountered arbitrarily choosing ...

[Ludovic Courtès]

ra...@openmailbox.org skribis:

> A bad package could sneakily replace a core system library with, for
> example, insecure crypto code. So I think it is something that should
> be dealt with.

That’s really out of the threat model.  The problem here is the
installation of an evil package in the first place, not the shadowing.

> I had a look at past discussions on this:
>
> * https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00437.html
> * https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00106.html
> * https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00213.html
> * https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00668.html
>
> one idea was a whitelist to reduce the amount of errors displayed.
>
> I've made a list of the collisions I see on my system:
>
> * [gnome] /share/icons/hicolor/icon-theme.cache
> * [gnome] /lib/gio/modules/giomodule.cache
> * [gnome] /share/glib-2.0/schemas/gschemas.compiled
> * [gnome] /bin/gtk-update-icon-cache # because there are 2 versions of
> gtk
> * [python] /bin/coverage
> * [python] /bin/.coverage3-wrap-01
> * [python] /bin/py.test-3.4
> * [python] /bin/.py.test-wrap-01
> * [python] /bin/.py.test-3.4-wrap-01
>
> A suggestion I have for helping reduce this is there could be a post
> install phase in gtk build system to delete those specific .cache
> files. There could also be a similar one in those python libraries.
>
> Do people agree that this is a potential problem? If so I could
> attempt to add such an phase. Or maybe there are other solutions that
> would solve this better?

These warnings are definitely a problem, but they’re a user interface
problem.

For GNOME/GLib cache files, I think the solution may be to generate them
at profile-creation time.

I’ve never seen the pytest collisions before, so I can’t tell.

Ricardo also suggested that ‘guix package’ should warn about or error
out when propagated inputs conflict with each other, or conflict with
explicitly-installed packages.  I think we should do that.

Ludo’.

Re: Call for testing

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi,

> Please consider the following GuixSD installation image for testing, and
> report any issues or successes!
>
>   
> https://www.fdn.fr/~lcourtes/software/guix/guixsd-usb-install-0.10.0pre.x86_64-linux.xz

I tried this.

  + Booting and instructions are great
  - Please provide and suggest tested desktop.scm and server.scm
  - It seems that network is mandatory.  If that is so, you may want
to stress that.  guix system init failed on me several times with

   guix system: error: build failed: while setting up the build environment: 
getting attributes of path `/etc/resolv.conf': No such file or directory.

It would be nice if an install was possible without network, e.g.
server.scm/minimal.scm.

  - It seems that after this error, grub still got (half-) installed,
because i could not boot anymore :-( Fell into grub rescue> which
used to be just great once, but now I could not load a kernel there,
because of "error: symbol 'grub_term_highlight_color" not found" :-(

Greetings,
Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: security-updates merged

[Ludovic Courtès]

Mark H Weaver  skribis:

> Danny Milosavljevic  writes:
>> guix$ git pull # master branch
>> guix$ guix environment guix
>> guix$ make
>> ...
>> configure: error: Package requirements (sqlite3 >= 3.6.19) were not met:
>
> l...@gnu.org (Ludovic Courtès) writes:
>> Please see:
>>
>>   https://www.gnu.org/software/guix/manual/html_node/Requirements.html
>
> Did you notice that according to Danny's transcript above, this error
> occurred within a shell spawned by "guix environment guix"?

Oh sorry, I had overlooked that.

I just tried in ‘guix environment guix --container’ and cannot
reproduce.

Danny: could you check with either --container or --pure?  It could be
that some other settings from the outside environment were interfering.

Thanks,
Ludo’.

Re: [PATCH 1/3] licenses: Add beerware license.

[Christopher Allan Webber]

Efraim Flashner writes:

> On Sat, 26 Mar 2016 18:50:53 -0700
> Christopher Allan Webber  wrote:
>
>> Leo Famulari writes:
>> 
>>  [...]  
>> 
>> Now there's a license name bound to cause some confusion!
>> 
>> It looks free... I think it would be okay to push.  But maybe if only
>> one or two packages use it it would be better to just use the
>> non-copyleft license option?
>> 
>
> I went and doublechecked the license, because I've heard in the past it's not
> actually a copyleft license. According to wikipedia[0], it is not copyleft,
> but is GPL compatable, and recognized by the FSF. The language of the license
> does allow for not buying the author a beer.
>
>
> [0] https://en.wikipedia.org/wiki/Beerware

It's not a copyleft license, right.  That's why I suggested non-copyleft
:)

For example, in unzip:

(license (license:non-copyleft "file://LICENSE"
   "See LICENSE in the distribution."))

Re: [PATCH] gnu: Add cgit.

[Thompson, David]

On Sun, Mar 27, 2016 at 10:14 AM, 宋文武  wrote:
> I get it built, but haven't run it.
>
> For a cgit service, which CGI runner should we use?
> IIUC, typical setup are:
>   - nginx + fcgiwrap (or uwsgi)
>   - apache httpd
>   - lighttpd

I'm partial to nginx, and it's the only one we have a service for, but
it could be made sufficiently generic that it can use any web server
that a user supplied a handler for.  The nginx service is currently
missing a way to extend it with additional configuration.  I posted a
patch for this awhile ago but it never made it to master due to some
issues.  Once we make nginx extensible, writing a cgit service should
be easy.

BTW, have you verified that cgit does not distribute any minified
JavaScript files?

- Dave

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[Jookia]

On Sun, Mar 27, 2016 at 02:30:22PM -0400, myglc2 wrote:
> Wow, Ludo, what do you have against "end users"?

I think what Ludovic's getting at is that we'd rather have people know their
tools and experiment, much like Emacs.

Re: On my way to my first patch, need review

[rain1]

On 2016-03-26 22:49, vinc...@cloutier.co wrote:

Even though I don't know if I am accepted for GSoC yet, I thought it
would be nice to start contributing now! :)

I started by adding the gem wayback_machine_downloader (a very useful
piece of software by the way).

So I used `guix edit ruby` and I copied it in the Documents folder.
Then I added somewhere in the middle of the file:

(define-public wayback-machine-downloader
 (package
 (name "wayback-machine-downloader")
 (version "0.2.1")
 (source
 (origin
 (method url-fetch)
 (uri (rubygems-uri
 "wayback_machine_downloader"
 version))
 (sha256
 (base32
 "1nrwm5bc7vqm02m2x0lylxyya446kg0spg6ksi7dfkrad0l9jq8y"
 (build-system ruby-build-system)
 (arguments
 `(#:tests? #f ; no rakefile
 ))

 (native-inputs
 `(("ruby-rake-compiler" ,ruby-rake-compiler)
 ("ruby-minitest" ,ruby-minitest)))

 (synopsis
 "Download website from archive.org's Wayback Machine")
 (description
 "Download any website from the Wayback Machine. Wayback Machine by
Internet Archive (archive.org) is an awesome tool to view any website
at any point of time but lacks an export feature. Wayback Machine
Downloader brings exactly this.")
 (home-page
 "https://github.com/hartator/wayback-machine-downloader [1]")
 (license expat)))

Then I ran: `guix package -i wayback-machine-downloader -f
~/Documents/ruby` and it successfully installed.

So my questions are:

1) Do you guys and gals have a better workflow that includes the git
repo, so I can send a patch? All I saw in the documentation was about
building guix itself. I guess I could clone somewhere and use `guix
package -f`, but will this be a reliable way of testing? And will this
make my guix less stable on the long run?

2) Should I add "ruby-" before the name of the package? I know
technically all gems should have "ruby-" before the name, but this is
designed to be use independently. Could it have multiple names, or is
it a bad idea?

3) Where does this package belong in the directory?

4) Is the package declaration itself all right? Are packages sorted or
organized in any way?

5) I speak fluent French, can I add a description and summary in
French?

Thanks!
Vincent


Links:
--
[1] https://github.com/hartator/wayback-machine-downloader


Hello!

I tested this out on guixsd, I changed (license expat) to (license 
license:expat) and it built fine but when I tried to run it I got this 
error:


~$ wayback_machine_downloader
/gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/dependency.rb:319:in 
`to_specs': Could not find 'wayback_machine_downloader' (>= 0.a) among 
11 total gem(s) (Gem::LoadError)
Checked in 
'GEM_PATH=/home/rain/.gem/ruby/2.3.0:/gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/gems/2.3.0', 
execute `gem env` for more information
	from 
/gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/dependency.rb:328:in 
`to_spec'
	from 
/gnu/store/jaf2s3paa3fswfpzi6amlqjxd3fwiw9x-ruby-2.3.0/lib/ruby/2.3.0/rubygems/core_ext/kernel_gem.rb:65:in 
`gem'
	from /home/rain/.guix-profile/bin/wayback_machine_downloader:22:in 
`'


I'm not sure what the fix would be.

Re: RFC: Install Wizard considerations

[myglc2]

Thomas Ingram  writes:

> On 03/25/2016 03:35 PM, myglc2 wrote:
>> o) Since GuixSD is much more bleeding-edge than Guix, if we make it
>> easier to install GuixSD, we make it easier for new users to bleed.
>>
>> o) The fact of the matter is that GuixSD hardware support is weak
>> (examples: no boot from MDADM, missing solutions for non-free
>> hardware). If we make it easy for new users to go in this direction
>> by making it easy to install, we know that many will hit these issues
>> and become discouraged.
>
> I agree that GuixSD is currently limited and still beta software, but
> when GuixSD is more feature complete do we want it to be approachable
> to general users or do we want it limited to Guix power users?

It seems clear that current users are mostly 'Guix power users'. As a
metric, take a look at how active the user list is.

On the other hand my GuixSD and GUIX/Debian installs have been rock
solid and indistinguishable from my Debian installs from a reliability
point of view. And, they have the later versions of software I want --
so I am a very happy user ;)

The primary reason I would not recommend GUIX to someone is the horrible
amount of time it took me to understand Guix concepts. But end users
that just want software probably don't care about Guix Concepts.

So it seems to me that an installer that helps the user get up and
running with a good install and workable config goes a long way to
making Guix available to "general users." And even for a prospective
power user it will for sure save time.

> My thinking was one day we would want a general user to be able to
> easily use GuixSD, so at some point we'll need a nice friendly
> installer. Maybe I'm misunderstanding the end goals of GuixSD though.

I certainly don't represent the current community. I am a noobie, using
Guix for just the last 2 months. So the install/setup experience is
fresh in my mind which is why I am being vocal. 

A bigger issue for the community is that when you make it easy to
install Guix the pressure for support will increase
dramatically. E.g. Imagine that to install ubuntu you had to run zile to
edit ubuntu.scm. How many people would be using it? Now, imagine there
is a push-button install, now how many people will try it and and ask
for support?

>> So, IMO, if we want to make it easier for new users to try Guix, right
>> now we need a Guix/GNU/Linxu install wizard much more than we need a
>> GuixSD install wizard.
>>
>> Looking at the big picture, the ideal installer would seamlessly handle
>> Guix/GNU/Linux and GuixSD installs. It might do something like the
>> following:
>>
>> Examine the environment & determine the possible ways that Guix and/or
>> GuixSD can be installed, then walk the user through choices, for
>> example:
>>
>> - netboot?
>>   - fdisk & GuixSD?
>> - GNU/Linux system?
>>   - ?root user?
>>- install Guix?
>>- put GuixSD netboot on USB?
>>- install GuixSD to disk?
>>- install GuixSD dual boot?
>>   - running in user space?
>>- guix installed?
>> - set up git clone?
>>- guix not present?
>> - can you sudo?
>>  - yes - got to '?root user' above
>>  - no
>>   - install Guix in user space?
>>   - put GuixSD netboot on USB?
>>
>> In any event, the end user should end up with a functioning Guix setup
>> in which all guix features described in the manual are working, (except
>> those requiring root, e.g. guix system reconfigure).
> I completely agree that to expand Guix's user base we need to get more
> people using it on any GNU/Linux. I really appreciate the feedback
> although I'm worried I'm a bit too inexperienced, I don't know if I
> have the skill to write something to handle such a diverse set of
> installs.

I agree the scenario above is too much. But if it can be thought about
when you set your direction you might end up with more flexible tools.

> This is why I've been aiming to write the GuixSD installer where much
> of it can be easily automated through the lovely operating-system
> declaration which (it's my understand that) is exclusive to
> GuixSD. Perhaps Dyan, who also proposed for GSoC a Guix installer
> could work on this general Guix installer and I could focus on a
> installer for GuixSD, he seems more experienced than me so he would
> probably have a better shot at handling a more complicated install
> process on other distros.

As noted in my other post, setting up config.scm only gets GuixSD
running. For a user to actually do anything cool they also need to do
some package management. I know this from experience because at first I
tried to configure all my packages into config.scm. This amounts to
trying to use Guix system configuration as a replacement for the Debian
package manager. As it turns out, this is not a good way to use Guix. So
it would be a bad idea to start new users down this path with the
installer.

Maybe the way to think about this is as two wizards, one for GuixSD
system configuration (

About collision encountered arbitrarily choosing ...

[rain1]

I was just thinking about the warnings you get after installing 
packages:


warning: collision encountered
warning: arbitrarily choosing

because there are a lot of them and they generally don't matter or cause 
problems I have learned to ignore them.. but I just spotted this 
collision today:


/gnu/store/...-lsh-2.1/share/man/man8/sftp-server.8.gz
/gnu/store/...-openssh-7.2p2/share/man/man8/sftp-server.8.gz

That's only a man page substitution but really any package can shadow 
any file with 50% chance (can probably make it 100% by setting up the 
hash to come lexically first, not sure).


A bad package could sneakily replace a core system library with, for 
example, insecure crypto code. So I think it is something that should be 
dealt with.


---

I had a look at past discussions on this:

* https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00437.html
* https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00106.html
* https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00213.html
* https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00668.html

one idea was a whitelist to reduce the amount of errors displayed.

I've made a list of the collisions I see on my system:

* [gnome] /share/icons/hicolor/icon-theme.cache
* [gnome] /lib/gio/modules/giomodule.cache
* [gnome] /share/glib-2.0/schemas/gschemas.compiled
* [gnome] /bin/gtk-update-icon-cache # because there are 2 versions of 
gtk

* [python] /bin/coverage
* [python] /bin/.coverage3-wrap-01
* [python] /bin/py.test-3.4
* [python] /bin/.py.test-wrap-01
* [python] /bin/.py.test-3.4-wrap-01

A suggestion I have for helping reduce this is there could be a post 
install phase in gtk build system to delete those specific .cache files. 
There could also be a similar one in those python libraries.


Do people agree that this is a potential problem? If so I could attempt 
to add such an phase. Or maybe there are other solutions that would 
solve this better?

Re: [GSoC] Draft proposal for an Install Wizard for Guix

[myglc2]

Thomas Ingram  writes:

> On 03/26/2016 07:39 AM, Ludovic Courtès wrote:
>> Personally, I would like to view the “wizard” as a helper, and not as
>> something that hides everything and turns people into “end users.”

Wow, Ludo, what do you have against "end users"?

>> I don’t know how this could translate in the design of the tool.
>> Perhaps showing the ‘operating-system’ declaration as you suggest is one
>> thing, and making it easy to view the section of the manual that
>> corresponds to a particular item, or to jump to the code that defines a
>> specific service (say), would be helpful too.
> Yes as much as it is an installer it should also be an
> introduction. Something that not only lets a user easily input their
> options but also shows them how their settings will be put into
> config.scm, I'm trying to come up with some clever ideas of how to do
> this in a graceful way.

I disagree about teaching config.scm. When I install Debian all I care
about is:

1) does it let me do what I want?
2) how long does it take?
3) does it leave my machine in a "good" state?

I don't really care how it does it. config.scm is a thing of beauty, but
how important is it really for a GuixSD user to learn? Once GuixSD is
installed, will they ever look at it again? Won't they be using package
management to install the software they want?

A more fundamental issue you need to think about is that the Debian
installer installs packages globally for all users whereas "Guix-style"
is to not address the user-level package needs in config.scm. This means
that a GuixSD installer needs to get the machine up and running on
GuixSD and then come back for a second pass to help the user install
some packages.

> Thinking about this has lead me to think more about Danny
> Milosavljevic's suggestion
>> Yeah, personally I'd like to have an emacs form which just displays
>> config.scm (and stores it as a normal file) and has some inline
>> documentation on what is what and maybe a treeview instead of
>> visible S-Expression parens - and a validation process whether the
>> stuff makes sense. When you exit, it just instantiates the system.
>>
>> The partitioning & file system type should also be specified in a
>> declarative way in the config [and arguably it already is].
>>
>> Basically not a lot different from now but just more user-friendly
>> and catching more mistakes before instantiation.
>>
>> ncurses actually isn't as flexible - although it has the benefit that
>> the average user is familiar with how it looks.
> Basically I was thinking of doing that with an ncurses UI that shows
> the user their config.scm with some documentation and then walks users
> through changing each option. But maybe an emacs installer makes more
> sense as this is the type of interface emacs does very well.

I encourage you to pursue the emacs approach.

> The reason I had avoided proposing an emacs installer previously is I
> worry about confusion from users who are unfamiliar with emacs and how
> to use it.

People are unfamiliar with emacs, but have you used aptitude? No one
started out familiar with aptitude, but it is happily used by Debian
admins (many of which, by the way, hate emacs).

> Should we be concerned with that when so many of Guix's
> great features that can be accessed through emacs.

IMO the Guix emacs interface already exceeds aptitude's, so leverage it
rather than re-inventing any of it.

> Perhaps there could be a simple introduction to emacs in the installer
> as well?

Don't try to teach emacs to the user. And what ever you do, DO NOT tell
them to type C-h!

Instead create a top-level menu that drops them into various guix-
functions to get the job done. An example of this is the notmuch emacs
interface.

Then, make sure each "guix-" you use supports typing "?" to
figure out what the heck is going and and how to get stuff done.

By going this route, you will leverage what is already developed,
enhance the usablity of the Guix emacs interface, and probably end up
with a dynamite installer. - George

> On the
> other hand if a user has no experience with emacs throwing that at
> them along with config.scm could be overwhelming.

Agreed. An IMO not necessary as stated above.

NEWS for 0.10.0

[Ludovic Courtès]

Hello!

I’ve looked at the 2,200+ commits since 0.9.0 (!) to update ‘NEWS’,
trying to keep it high-level and readable (nobody’s gonna read it if
it’s too long ;-)).

You’re welcome to check what’s in there, making sure your favorite
feature or bug-fix appears, and posting changes!

The goal is to have everything ready on Monday evening.

Thanks,
Ludo’.

Re: [PATCH] environment: container: Do not remount network files as read-only.

[Ludovic Courtès]

"Thompson, David"  skribis:

> On Sat, Mar 26, 2016 at 2:43 PM, Ludovic Courtès  wrote:
>> "Thompson, David"  skribis:
>>
>>> On Fri, Mar 18, 2016 at 4:51 PM, Ludovic Courtès  wrote:
 "Thompson, David"  skribis:

> I noticed that 'guix environment --container --network' didn't work on
> an Ubuntu machine I was on, and the culprit was remounting things like
> /etc/resolv.conf read-only after the initial bind mount.

 [...]

>  (file-system-mapping
>   (source file)
>   (target file)
> - (writable? #f
> + ;; An unpriviliged user 
> might not
> + ;; be able to remount
> + ;; /etc/resolv.conf as 
> read-only,
> + ;; so we say that it is 
> writable
> + ;; here, even though in 
> practice
> + ;; it is not.
> + (writable? #t
>   %network-configuration-files)

 Not sure I understand: why would bind-mounting /etc/resolv.conf
 read-only fail?
>>>
>>> I haven't figured out the exact reason yet, but here's a strace
>>> snippet as proof:
>>>
>>> [pid 11334] mount("/etc/resolv.conf",
>>> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23da000,
>>> MS_RDONLY|MS_BIND, NULL) = 0
>>> [pid 11334] mount("/etc/resolv.conf",
>>> "/tmp/guix-directory.Rc4nc6//etc/resolv.conf", 0x23e4080,
>>> MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1 EPERM (Operation not
>>> permitted)
>>>
>>> Another Ubuntu user was able to reproduce this as well.
>>
>> Looking at the resolvconf man page that Drew mentioned, it seems that
>> /etc/resolv.conf is a symlink when resolvconf is in used, right?
>>
>> If yes, does this make a difference:
>
> /etc/resolv.conf is a symlink, but the patch doesn't work.
>
>> It may be that the result after this is that you get /etc/resolv.conf in
>> the container, but it’s a dangling symlink.  But isn’t it the case
>> already with the patch you propose?
>
> No,  /etc/resolv.conf appears as a regular file inside the container,
> even though it's a symlink outside.  The mount namespace does the
> right thing and I can read the contents of it from within the
> container.  No dangling symlink! :D
>
> I tried using --expose with a symlink as an attempt to replicate the
> problem with another file, but things went fine!  I'm confused.
> What's the correct patch here now? :)

I cannot reproduce the problem with this minimum test case (the two
‘mount’ call succeed):

--8<---cut here---start->8---
(use-modules (guix build syscalls)
 (gnu build linux-container))

(chdir "/tmp")
(false-if-exception (delete-file "foo"))
(false-if-exception (umount "bar"))
(false-if-exception (delete-file "bar"))

(symlink "/etc/resolv.conf" "foo")
(close-port (open-output-file "bar"))
(mount "/tmp/foo" "/tmp/bar" "none" (logior MS_BIND MS_RDONLY))
(mount "/tmp/foo" "/tmp/bar" "none" (logior MS_BIND MS_RDONLY MS_REMOUNT))
--8<---cut here---end--->8---

Maybe we should try to throw in ‘call-with-container’ somewhere in there
to be closer to the actual problem, dunno.

It’s a bit frustrating that we don’t understand the situation.  If you
wish, I think it’s fine to commit this patch, but please make sure to
mention that the problem occurs when /etc/resolv.conf is a symlink, and
add a link to this discussion.

(FWIW I’m planning to push have the release ready on Monday night.)

Thanks!

Ludo’.

Re: [PATCH] scripts: environment: Properly handle SIGINT.

[Ludovic Courtès]

"Thompson, David"  skribis:

> On Sat, Mar 26, 2016 at 2:33 PM, Thompson, David
>  wrote:
>> On Sat, Mar 26, 2016 at 2:23 PM, Ludovic Courtès  wrote:
>>> David Thompson  skribis:
>>>
 * tests/guix-environment-container.sh: Remove obsolete test.
>>>
>>> [...]
>>>
 -if guix environment --bootstrap --container \
 - --ad-hoc bootstrap-binaries -- kill -SEGV 2
 -then false;
 -else
 -test $? -gt 127
 -fi
>>>
>>> This test was added in light of .  We want to
>>> make sure we don’t lose that property.
>>>
>>> What happens exactly when a signal is sent to PID 1?  I would expect
>>> that its parent process, which is outside the container in a waitpid
>>> call, would simply get its exit value in the normal way, and thus,
>>> changing “2” to “1” in this test should do the trick.  Am I naïve?  :-)
>>
>> The problem is that a process within the container cannot just kill
>> PID 1 since its the init process and the kernel protects it, so
>> changing "2" to "1" doesn't work.  The exit status of the environment
>> command is 0 in that case because PID 1 never received the signal and
>> thus exits normally.
>>
>> I'll try to come up with a replacement test case, thanks for giving me
>> the context in which it was added.  (I should've used 'git blame'
>> first.)
>
> Coming up with a replacement test has proved very difficult.  Since
> PID 1 is unkillable, I'm having a hell of time coming up with a clever
> way to kill a Guile process via a signal.

Would it help to change the test to:

  guix environment --bootstrap --container \
 --ad-hoc bootstrap-binaries -- sh -c 'exec kill -SEGV 2'

essentially mimicking previous behavior?

Ludo’.

Re: [PATCH] gnu: pspp: Update to 0.10.0

[Ludovic Courtès]

John Darrington  skribis:

> ncurses is optional for pspp - the terminal behaviour is nicer if you have it.
>
> perl-text-diff is not used by pspp except in its self tests.  There is one 
> test
> which needs it.  If you don't have it that test is skipped.
>
> Postgres ships with a client interface library called libpq - using it is 
> optional
> in pspp.  If you have it, it allows pspp to directly connect to postgres 
> databases.

Could you post an updated patch?

I guess the PostgreSQL dependency might be debatable since it would
probably significantly increase the closure size.  Could you check ‘guix
size’ and decide whether adding this dependency is a good thing, based
on its size/benefit ratio?   :-)

TIA!

Ludo’.

Re: [RFCv2] build: i686-w64-mingw32: new cross target.

[Pjotr Prins]

On Sun, Mar 27, 2016 at 04:20:13PM +0200, Jan Nieuwenhuizen wrote:
> Jan Nieuwenhuizen writes:
> 
> > I'm working on a cross target in an effort to get rid of GUB 1) in
> > favour of Guix and could do with some help.
> 
> It now builds fully from source.  See
> https://github.com/janneke/guix/tree/wip-mingw32 or attached patch.
> 
> 16:15:25 janneke@drakenvlieg:~/src/mingw-guix
> $ ./pre-inst-env guix build --keep-failed --target=i686-w64-mingw32 hello
> /gnu/store/2j8qaqbc9q1w3z6k054nmp7j432yxfq7-hello-2.10
> 16:15:29 janneke@drakenvlieg:~/src/mingw-guix
> $ ./pre-inst-env guix environment --ad-hoc wine -- wine 
> /gnu/store/2j8qaqbc9q1w3z6k054nmp7j432yxfq7-hello-2.10/bin/hello.exe
> Hello, world!
> 16:15:40 janneke@drakenvlieg:~/src/mingw-guix
> $ 
> 
> The gcc-cross-core package needs some cleanups and I still need to
> figure out to remove the i686-w64-mingw32 special casing, i.e, find
> a way to handle the libc/#f/newlib case.

Awesome work Jan :). Next up are the BSDs. 

Pj.

[RFCv2] build: i686-w64-mingw32: new cross target.

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

> I'm working on a cross target in an effort to get rid of GUB 1) in
> favour of Guix and could do with some help.

It now builds fully from source.  See
https://github.com/janneke/guix/tree/wip-mingw32 or attached patch.

16:15:25 janneke@drakenvlieg:~/src/mingw-guix
$ ./pre-inst-env guix build --keep-failed --target=i686-w64-mingw32 hello
/gnu/store/2j8qaqbc9q1w3z6k054nmp7j432yxfq7-hello-2.10
16:15:29 janneke@drakenvlieg:~/src/mingw-guix
$ ./pre-inst-env guix environment --ad-hoc wine -- wine 
/gnu/store/2j8qaqbc9q1w3z6k054nmp7j432yxfq7-hello-2.10/bin/hello.exe
Hello, world!
16:15:40 janneke@drakenvlieg:~/src/mingw-guix
$ 

The gcc-cross-core package needs some cleanups and I still need to
figure out to remove the i686-w64-mingw32 special casing, i.e, find
a way to handle the libc/#f/newlib case.

Greetings,
Jan

1) GUB -- http://lilypond.org/gub/

>From 7a58b7d85c798e1ca2f11d61e0b344cf2e3bcb10 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Sun, 27 Mar 2016 16:00:36 +0200
Subject: [PATCH] build: i686-w64-mingw32: new cross target.

* gnu/packages/cross-base.scm (gcc-cross-core, mingw-w64,
  xgcc-i686-w64-mingw32): New variables.
  (cross-gcc): Use them to support i686-w64-mingw32 target.
* gnu/packages/bootstrap.scm (glibc-dynamic-linker): Add i686-mingw.
* guix/build-system/gnu.scm (standard-cross-packages): Set libc to #f
  for i686-w64-mingw32.
---
 gnu/packages/bootstrap.scm  |   1 +
 gnu/packages/cross-base.scm | 276 +---
 guix/build-system/gnu.scm   |   4 +-
 3 files changed, 263 insertions(+), 18 deletions(-)

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index f5bf069..979ab1d 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -171,6 +171,7 @@ successful, or false to signal an error."
 ;; here just so we can keep going.
 ((string=? system "xtensa-elf") "no-ld.so")
 ((string=? system "avr") "no-ld.so")
+((string=? system "i686-mingw") "no-ld.so")
 
 (else (error "dynamic linker name not known for this system"
  system
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 8bd599c..be2f4c0 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -18,12 +18,16 @@
 ;;; along with GNU Guix.  If not, see .
 
 (define-module (gnu packages cross-base)
-  #:use-module (guix licenses)
+  #:use-module ((guix licenses) #:prefix license:)
   #:use-module (gnu packages)
-  #:use-module (gnu packages gcc)
   #:use-module (gnu packages base)
+  #:use-module (gnu packages bash)
+  #:use-module (gnu packages gawk)
+  #:use-module (gnu packages gcc)
   #:use-module (gnu packages commencement)
+  #:use-module (gnu packages compression)
   #:use-module (gnu packages linux)
+  #:use-module (gnu packages multiprecision)
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix utils)
@@ -101,7 +105,7 @@ may be either a libc package or #f.)"
 `(append (list ,(string-append "--target=" target)
,@(if libc
  `( ;; Disable libcilkrts because it is not
-;; ported to GNU/Hurd. 
+;; ported to GNU/Hurd.
"--disable-libcilkrts")
  `( ;; Disable features not needed at this stage.
"--disable-shared" "--enable-static"
@@ -120,20 +124,32 @@ may be either a libc package or #f.)"
"--disable-libquadmath"
"--disable-decimal-float" ;would need libc
"--disable-libcilkrts"
-   )))
+))
+,@(if (equal? target "i686-w64-mingw32")
+  '("--with-newlib"
+"--without-headers")
+  '()))
 
  ,(if libc
   flags
   `(remove (cut string-match "--enable-languages.*" <>)
,flags
((#:make-flags flags)
-(if libc
+ (cond
+  ((equal? target "i686-w64-mingw32")
+   `(append (let ((runtime (assoc-ref %build-inputs "mingw-w64")))
+  (if runtime
+  (list
+   (string-append "FLAGS_FOR_TARGET=-B" runtime "/lib"))
+  '()))
+,flags))
+  (libc
 `(let ((libc (assoc-ref %build-inputs "libc")))
;; FLAGS_FOR_TARGET are needed for the target libraries to receive
;; the -Bxxx for the startfiles.
(cons (string-append "FLAGS_FOR_TARGET=-B" libc "/lib")
- ,flags))

Re: [PATCH] Add MilkyTracker to Guix

[Nils Gillmann]

Forwarded mail, from an offlist message by kei.
Please CC the mailinglist next time or configure your email
client to do so :)





I think this is a bit better. I don't know how to run the tests
required in the link you provided from within my local copy of the guix
source code tree.
(https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html)>From 3f804b74cadc2c343b9592afdee6142d3d5bc131 Mon Sep 17 00:00:00 2001
From: Kei Yamashita 
Date: Sat, 26 Mar 2016 17:26:49 -0400
Subject: [PATCH 2/2] Define MilkyTracker in music.scm

---
 gnu/packages/music.scm | 24 
 1 file changed, 24 insertions(+)

diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
index 672f55d..878603d 100644
--- a/gnu/packages/music.scm
+++ b/gnu/packages/music.scm
@@ -78,6 +78,7 @@
   #:use-module (gnu packages rdf)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages rsync)
+  #:use-module (gnu packages sdl)
   #:use-module (gnu packages tcl)
   #:use-module (gnu packages texinfo)
   #:use-module (gnu packages texlive)
@@ -1304,3 +1305,26 @@ once and for all.  It catalogs your collection, automatically improving its
 metadata as it goes using the MusicBrainz database.  Then it provides a variety
 of tools for manipulating and accessing your music.")
 (license license:expat)))
+
+(define-public milkytracker
+  (package
+(name "milkytracker")
+(version "0.90.86")
+(source (origin
+	  (method url-fetch)
+	  (uri
+	   (string-append "http://milkytracker.org/files/milkytracker-";
+  name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"0mqjkhvjyp5hnzm1ln3b2qjclviayxylcyml96pjdxgbaqcqa2zz"
+(build-system gnu-build-system)
+(arguments
+ '(#:configure-flags `("--without-alsa" "--without-jack")))
+(inputs
+ `(("sdl" ,sdl)
+   ("zlib" ,zlib)))
+(synopsis "Multi-platform music tracker for composing music in the MOD and XM module file formats")
+(description "MilkyTracker is a free software, multi-platform music application for creating .MOD and .XM module files. It attempts to recreate the module replay and user experience of the popular DOS program Fasttracker II, with special playback modes available for improved Amiga ProTracker 2/3 compatibility.")
+(home-page "http://milkytracker.org/";)
+(license license:gpl3)))
-- 
2.7.3


-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

Re: [PATCH] gnu: Add cgit.

[宋文武]

I get it built, but haven't run it.

For a cgit service, which CGI runner should we use?
IIUC, typical setup are:
  - nginx + fcgiwrap (or uwsgi)
  - apache httpd
  - lighttpd

[PATCH] gnu: Add cgit.

[宋文武]

* gnu/packages/version-control.scm (cgit): New variable.
---
 gnu/packages/version-control.scm | 60 
 1 file changed, 60 insertions(+)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 7d7276a..498885d 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -364,6 +364,66 @@ write native speed custom Git applications in any language 
with bindings.")
 ;; GPLv2 with linking exception
 (license gpl2)))
 
+(define-public cgit
+  (package
+(name "cgit")
+(version "0.12")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"https://git.zx2c4.com/cgit/snapshot/cgit-";
+version ".tar.xz"))
+  (sha256
+   (base32
+"1dx54hgfyabmg9nm5qp6d01f54nlbqbbdwhwl0llb9imjf237qif"
+(build-system gnu-build-system)
+(arguments
+ '(#:tests? #f ;
+   #:test-target "test"
+   #:make-flags '("CC=gcc" "SHELL_PATH=sh")
+   #:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'unpack-git
+   (lambda* (#:key inputs #:allow-other-keys)
+ ;; Unpack the source of git into the 'git' directory.
+ (zero? (system*
+ "tar" "--strip-components=1" "-C" "git" "-xf"
+ (assoc-ref inputs "git:src")
+ (delete 'configure) ; no configure script
+ (add-after 'build 'build-man
+   (lambda* (#:key make-flags #:allow-other-keys)
+ (zero? (apply system* `("make" ,@make-flags "doc-man")
+ (replace 'install
+   (lambda* (#:key make-flags outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+   (and (zero? (apply system*
+  `("make" ,@make-flags
+,(string-append "prefix=" out)
+,(string-append
+  "CGIT_SCRIPT_PATH=" out "/share/cgit")
+"install" "install-man")))
+;; Move the platform-dependent 'cgit.cgi' into lib
+;; to get it stripped.
+(rename-file (string-append out "/share/cgit/cgit.cgi")
+ (string-append out "/lib/cgit/cgit.cgi"))
+#t)))
+(native-inputs
+ `(("asciidoc" ,asciidoc)
+   ("xmllint" ,libxml2)
+   ("xsltprot" ,libxslt)))
+(inputs
+ `(("docbook-xml" ,docbook-xml)
+   ("docbook-xsl" ,docbook-xsl)
+   ("git:src" ,(package-source git))
+   ("openssl" ,openssl)
+   ("zlib" ,zlib)))
+(home-page "https://git.zx2c4.com/cgit/";)
+(synopsis "Web frontend for git repositories")
+(description
+ "CGit is an attempt to create a fast web interface for the Git SCM, using
+a built-in cache to decrease server I/O pressure.")
+(license gpl2)))
+
 (define-public shflags
   (package
 (name "shflags")
-- 
2.6.3

New Danish PO file for 'guix-packages' (version 0.9.1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-packages' has been submitted
by the Danish team of translators.  The file is available at:

http://translationproject.org/latest/guix-packages/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

http://translationproject.org/latest/guix-packages/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/guix-packages.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New Danish PO file for 'guix' (version 0.9.1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix' has been submitted
by the Danish team of translators.  The file is available at:

http://translationproject.org/latest/guix/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

http://translationproject.org/latest/guix/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/guix.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] Add MilkyTracker to Guix

[Efraim Flashner]

On Fri, Mar 25, 2016 at 07:54:40PM -0400, k...@openmailbox.org wrote:
> The attached is a patch to gnu/packages/music.scm that allows a minimal and
> functional build of MilkyTracker. I'm unsure if this is formatted correctly,
> but I'm willing to learn. :-)

> --- music.scm.bak 2016-03-25 17:39:35.959715114 -0400
> +++ music.scm 2016-03-25 19:39:44.754396091 -0400
> @@ -78,6 +78,7 @@
>#:use-module (gnu packages rdf)
>#:use-module (gnu packages readline)
>#:use-module (gnu packages rsync)
> +  #:use-module (gnu packages sdl)
>#:use-module (gnu packages tcl)
>#:use-module (gnu packages texinfo)
>#:use-module (gnu packages texlive)
> @@ -1305,3 +1306,26 @@
>  of tools for manipulating and accessing your music.")
>  (license license:expat)))
>  
> +(define-public milkytracker
> +  (package
> +(name "milkytracker")
> +(version "0.90.86")
> +(source (origin
> +   (method url-fetch)
> +   (uri
> +(string-append "http://milkytracker.org/files/milkytracker-";
> +   version
> +   ".tar.gz"))
> +  (sha256
> +   (base32
> +"0mqjkhvjyp5hnzm1ln3b2qjclviayxylcyml96pjdxgbaqcqa2zz"
> +(build-system gnu-build-system)
> +(arguments
> + '(#:configure-flags `("--without-alsa" "--without-jack")))
> +(inputs
> + `(("sdl" ,sdl)
> +   ("zlib" ,zlib)))
> +(synopsis "MilkyTracker is a free software multi-platform music tracker 
> for composing music in the MOD and XM module file formats.")
> +(description "MilkyTracker is a free software, multi-platform music 
> application for creating .MOD and .XM module files. It attempts to recreate 
> the module replay and user experience of the popular DOS program Fasttracker 
> II, with special playback modes available for improved Amiga ProTracker 2/3 
> compatibility.")
> +(home-page "http://milkytracker.org/";)
> +(license license:gpl3)))

In addition to Nil's comments, I was wondering about the configure
flags. Wouldn't it make sense to have either alsa or jack as an input?

-- 
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

Re: [PATCH] gnu: pspp: Update to 0.10.0

[John Darrington]

On Sun, Mar 27, 2016 at 10:00:04AM +0300, Efraim Flashner wrote:

 I pushed an update to pspp last night and I had the changes from gtk2 to
 gtk3, but I don't have the ncurses, postgresql or perl-text-diff additions.
 Are they all related to the libpq interface, and what is it?

ncurses is optional for pspp - the terminal behaviour is nicer if you have it.

perl-text-diff is not used by pspp except in its self tests.  There is one test
which needs it.  If you don't have it that test is skipped.

Postgres ships with a client interface library called libpq - using it is 
optional
in pspp.  If you have it, it allows pspp to directly connect to postgres 
databases.


J'
 

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: [PATCH 1/3] licenses: Add beerware license.

[Efraim Flashner]

On Sat, 26 Mar 2016 18:50:53 -0700
Christopher Allan Webber  wrote:

> Leo Famulari writes:
> 
>  [...]  
> 
> Now there's a license name bound to cause some confusion!
> 
> It looks free... I think it would be okay to push.  But maybe if only
> one or two packages use it it would be better to just use the
> non-copyleft license option?
> 

I went and doublechecked the license, because I've heard in the past it's not
actually a copyleft license. According to wikipedia[0], it is not copyleft,
but is GPL compatable, and recognized by the FSF. The language of the license
does allow for not buying the author a beer.


[0] https://en.wikipedia.org/wiki/Beerware

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


pgpV2c0EaW_sK.pgp
Description: OpenPGP digital signature

Re: [PATCH] gnu: pspp: Update to 0.10.0

[Efraim Flashner]

On Sun, 27 Mar 2016 08:24:52 +0200
John Darrington  wrote:

> * gnu/packages/math.scm (pspp): Update to 0.10.0
> ---
>  gnu/packages/maths.scm | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
> index 6d3d134..659d8a2 100644
> --- a/gnu/packages/maths.scm
> +++ b/gnu/packages/maths.scm
> @@ -43,6 +43,8 @@
>#:use-module (gnu packages check)
>#:use-module (gnu packages cmake)
>#:use-module (gnu packages compression)
> +  #:use-module (gnu packages databases)
> +  #:use-module (gnu packages ncurses)
>#:use-module (gnu packages curl)
>#:use-module (gnu packages elf)
>#:use-module (gnu packages flex)
> @@ -204,15 +206,14 @@ LP/MIP solver is included in the package.")
>  (define-public pspp
>(package
>  (name "pspp")
> -(version "0.8.5")
> +(version "0.10.0")
>  (source
>   (origin
>(method url-fetch)
> -  (uri (string-append "mirror://gnu/pspp/pspp-"
> -  version ".tar.gz"))
> +  (uri (string-append "mirror://gnu/pspp/pspp-" version ".tar.gz"))
>(sha256
> (base32
> -"0c8326yykidi94xi7jn27j8iqxc38vc07d4wf5zyk0l8lpzx5vz7"
> + "1nwnxr8mvf8y4lc8h8sd2xn2njwjk42x8mzj91zzv92m2z3vyggg"
>  (build-system gnu-build-system)
>  (inputs
>   `(("cairo" ,cairo)
> @@ -220,14 +221,18 @@ LP/MIP solver is included in the package.")
> ("gettext" ,gnu-gettext)
> ("gsl" ,gsl)
> ("libxml2" ,libxml2)
> +   ("ncurses" ,ncurses)
> ("pango" ,pango)
> +   ("postgresql",postgresql) ; for the libpq interface
> ("readline" ,readline)
> -   ("gtk" ,gtk+-2)
> -   ("gtksourceview" ,gtksourceview-2)
> +   ("gtk" ,gtk+)
> +   ("gtksourceview" ,gtksourceview)
> ("zlib" ,zlib)))
>  (native-inputs
>   `(("glib" ,glib "bin") ;for glib-genmarshal
> ("perl" ,perl)
> +   ("perl-text-diff" ,perl-text-diff)
> +   ("postgresql",postgresql) ; Need a postgres server to test the libpq 
> interface
> ("texinfo" ,texinfo)
> ("pkg-config" ,pkg-config)))
>  (home-page "http://www.gnu.org/software/pspp/";)

I pushed an update to pspp last night and I had the changes from gtk2 to
gtk3, but I don't have the ncurses, postgresql or perl-text-diff additions.
Are they all related to the libpq interface, and what is it?

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


pgpngX5WarPpL.pgp
Description: OpenPGP digital signature