Re: For a slimmer GHC

2015-11-02 Thread Ludovic Courtès 
Federico Beffa  skribis:

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

[...]

>> What about removing all the .a?  Would that be OK?
>>
>> On that topic I found
>>  but it’s not
>> clear to me whether this is relevant here.  At worst we can add a phase
>> that removes these files.
>
> I do not know much about this topic, but I think that the discussion at
> the link you provided is relevant, as probably is the one at
>
> https://ghc.haskell.org/trac/ghc/wiki/DynamicLinkingDebate
>
> My interpretation of the above discussions is that it is in principle OK
> to remove statically linked libraries, but: (i) you loose the
> possibility to create statically linked executables (the default; the
> discussion here is about Haskell libraries, not system libraries), (ii)
> dynamically linked executables are slower than statically linked ones
> and (iii) it may create some build systems compatibility problems.

(i) and (ii) apply to all the packages in Guix, not just Haskell
packages: most of the time we provide only shared libraries, and PIC
code includes a slight “performance penalty” (and possibly large memory
savings if several processes use the library.)

I’m not sure what (iii) means though?

> Personally I would keep them as the above discussions give me the
> impression that dynamic linking is not very mature in GHC. In any case,
> if people feel strongly about removing static libraries, then I would at
> least add an option to the build-system to easily re-enable their
> creation.

I think we could even simply move them to a different output, for those
who really need them.

>> A secondary issue is documentation: There’s a “doc” output, but
>> ‘ghc:out’ depends on ‘ghc:doc’:
>>
>> $ guix gc --references 
>> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/ | grep doc
>> /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc
>> $ du -ms /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc
>> 47/gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc
>> $ grep -r r539jrq7jk9vkmm1255i5jqs7skn4fag
>> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2
>> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/process-1.2.3.0-f0287ac288afc0705be775d1adda59ee.conf:haddock-interfaces:
>>  
>> /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/doc/ghc/html/libraries/process-1.2.3.0/process.haddock
>> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/process-1.2.3.0-f0287ac288afc0705be775d1adda59ee.conf:haddock-html:
>>  
>> /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/doc/ghc/html/libraries/process-1.2.3.0
>> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/Cabal-1.22.4.0-43c3ae30d75ac742e521d26b63721876.conf:haddock-interfaces:
>>  
>> /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/doc/ghc/html/libraries/Cabal-1.22.4.0/Cabal.haddock
>> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/Cabal-1.22.4.0-43c3ae30d75ac742e521d26b63721876.conf:haddock-html:
>>  
>> /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/doc/ghc/html/libraries/Cabal-1.22.4.0
>>
>> Any idea if we could avoid references to the “doc” output in these
>> *.conf files?  For instance, if there’s a variable like, say,
>> ‘HADDOCK_PATH’, we can certainly remove the hardcoded references
>
> As far as I understand, these full paths entries in .conf files are used
> to generate links in the HTML documentation. As one example, when you
> generate the documentation for the 'ghc-mtl' package, the generated
> documentation includes links, e.g., to the documentation of the
> 'identity' function which resides in another package. I believe that the
> location of the latter is retrieved from the .conf files.
>
> Browsing the Haddock documentation I do not see environment variables
> https://www.haskell.org/haddock/doc/html/invoking.html

OK, too bad.

Thanks for your feedback!

Ludo’.

Re: [PATCH] emacs: Enable 'guix-build-log-minor-mode' in shell buffers.

2015-11-02 Thread Ludovic Courtès 
Alex Kost  skribis:

> Ludovic Courtès (2015-11-01 20:46 +0300) wrote:
>
>> Alex Kost  skribis:
>>
> [...]
>>> But then why don't we enable 'guix-prettify-mode' by default?  As for
>>> me, I don't think all these features should be automatically enabled,
>>> dunno what is considered to be a good default: "full-featured" or "as
>>> simple as possible".
>>
>> I’m mostly in favor of full-featured.  The Emacs tradition is/was to
>> provide something that had to be explicitly configured to get the
>> features: in the old days, font-locking was disabled by default, and
>> Gnus would do absolutely nothing until you had spent a couple of days
>> configuring it.
>>
>> However, given the wealth of features now provided by guix.el, I think
>> it’s best to enable most of them by default, at least those that are not
>> controversial.  Otherwise, the risk is that people just won’t know about
>> them.
>>
>> ‘guix-build-log-minor-mode’ is clearly one of the things to enable by
>> default IMO.  The situation is less clear for ‘guix-prettify-mode’
>> because it changes the behavior of Emacs in a way that could be
>> surprising to a newcomer.
>>
>> WDYT?
>
> OK, you convinced me.  I would not be happy if Emacs was not colored
> (with disabled font-locking) when I first met it.  Thank you for the
> descriptive explanation!  Now I agree on enabling
> 'guix-build-log-minor-mode' (and not enabling 'guix-prettify-mode').

Great!  :-)

Ludo’.

Re: [PATCH] emacs: Add completions for '--type' option of 'refresh' popup.

2015-11-02 Thread Alex Kost 
Ludovic Courtès (2015-11-01 20:18 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-10-29 23:14 +0300) wrote:
>
> [...]
>
>>> You could use #:autoload, but only for ‘%updaters’ because
>>> ‘upstream-updater-name’ is a macro so it needs to be available at
>>> expansion time.
>>
>> I looked at (info "(guile) Using Guile Modules") and it has the following:
>>
>>   An autoload is a good way to put off loading a big module
>>   until it’s really needed, for instance for faster startup or
>>   if it will only be needed in certain circumstances.
>>
>>   ‘@’ can do a similar thing (see Using Guile Modules), but
>>   in that case an ‘@’ form must be written every time a binding
>>   from the module is used.
>>
>> To me it sounds like ‘@’ does the same thing as ‘#:autoload’, no?
>
> I guess I was confused.  A simple example confirms what the manual
> explains:
>
> $ guild compile t.scm
> wrote 
> `/home/ludo/.cache/guile/ccache/2.0-LE-8-2.0/home/ludo/src/guix/t.scm.go'
> $ guile t.scm
> $ cat t.scm
> (define (foo)
>   (@ (asdfasdfa) sdfsf))

Ah, good example, thank you!

>> Also #:autoload should be used inside (define-module ...), but
>> ‘guix-main.scm’ does not define a module.
>
> Oh, right, I had overlooked that.
>
> So yes, you can go ahead with your initial approach.

Great, thanks!

> Thanks, and sorry for the confusion!

No problem, pushed.

-- 
Alex

Re: [PATCH] emacs: Enable 'guix-build-log-minor-mode' in shell buffers.

2015-11-02 Thread Alex Kost 
Ludovic Courtès (2015-11-01 20:46 +0300) wrote:

> Alex Kost  skribis:
>
[...]
>> But then why don't we enable 'guix-prettify-mode' by default?  As for
>> me, I don't think all these features should be automatically enabled,
>> dunno what is considered to be a good default: "full-featured" or "as
>> simple as possible".
>
> I’m mostly in favor of full-featured.  The Emacs tradition is/was to
> provide something that had to be explicitly configured to get the
> features: in the old days, font-locking was disabled by default, and
> Gnus would do absolutely nothing until you had spent a couple of days
> configuring it.
>
> However, given the wealth of features now provided by guix.el, I think
> it’s best to enable most of them by default, at least those that are not
> controversial.  Otherwise, the risk is that people just won’t know about
> them.
>
> ‘guix-build-log-minor-mode’ is clearly one of the things to enable by
> default IMO.  The situation is less clear for ‘guix-prettify-mode’
> because it changes the behavior of Emacs in a way that could be
> surprising to a newcomer.
>
> WDYT?

OK, you convinced me.  I would not be happy if Emacs was not colored
(with disabled font-locking) when I first met it.  Thank you for the
descriptive explanation!  Now I agree on enabling
'guix-build-log-minor-mode' (and not enabling 'guix-prettify-mode').

-- 
Alex

[PATCH 1/5] gnu: Remove tabulation from luajit.

2015-11-02 Thread Leo Famulari 
* gnu/packages/lua.scm (luajit): Remove tabs.
---
 gnu/packages/lua.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm
index 87f53d1..6bedde3 100644
--- a/gnu/packages/lua.scm
+++ b/gnu/packages/lua.scm
@@ -89,8 +89,8 @@ for configuration, scripting, and rapid prototyping.")
   version ".tar.gz"))
   (sha256
(base32 "0ydxpqkmsn2c341j4r2v6r5r0ig3kbwv3i9jran3iv81s6r6rgjm"))
- (patches (list (search-patch "luajit-symlinks.patch")
-(search-patch "luajit-no_ldconfig.patch")
+  (patches (list (search-patch "luajit-symlinks.patch")
+ (search-patch "luajit-no_ldconfig.patch")
 (build-system gnu-build-system)
 (arguments
  '(#:tests? #f  ;luajit is distributed without tests
-- 
2.6.1

Re: For a slimmer GHC

2015-11-02 Thread Federico Beffa 
On Mon, Nov 2, 2015 at 3:11 PM, Ludovic Courtès  wrote:
> Federico Beffa  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>> What about removing all the .a?  Would that be OK?
>>>
>>> On that topic I found
>>>  but it’s not
>>> clear to me whether this is relevant here.  At worst we can add a phase
>>> that removes these files.
>>
>> I do not know much about this topic, but I think that the discussion at
>> the link you provided is relevant, as probably is the one at
>>
>> https://ghc.haskell.org/trac/ghc/wiki/DynamicLinkingDebate
>>
>> My interpretation of the above discussions is that it is in principle OK
>> to remove statically linked libraries, but: (i) you loose the
>> possibility to create statically linked executables (the default; the
>> discussion here is about Haskell libraries, not system libraries), (ii)
>> dynamically linked executables are slower than statically linked ones
>> and (iii) it may create some build systems compatibility problems.
>
> (i) and (ii) apply to all the packages in Guix, not just Haskell
> packages: most of the time we provide only shared libraries, and PIC
> code includes a slight “performance penalty” (and possibly large memory
> savings if several processes use the library.)
>
> I’m not sure what (iii) means though?

I'm not sure either :-) It's one of the reasons listed in the
discussion at the above link. I'm just passing on the information.

>
>> Personally I would keep them as the above discussions give me the
>> impression that dynamic linking is not very mature in GHC. In any case,
>> if people feel strongly about removing static libraries, then I would at
>> least add an option to the build-system to easily re-enable their
>> creation.
>
> I think we could even simply move them to a different output, for those
> who really need them.

That would be ideal, but I'm not sure you can simply move them. The
location of a library must be listed in the binary library cache. I do
not know if you can have more entries for a single library. I guess
that would have to be investigated experimentally.

Regards,
Fede

[PATCH 5/5] gnu: Build lua-5.1 with dynamic library support and a dynamic library.

2015-11-02 Thread Leo Famulari 
* gnu/packages/lua.scm (lua-5.1)[arguments]: Rewrite make-flags so that
  Lua is built with platform-specific instructions for shared library
  loading (dlopen).
* gnu/packages/patches/lua51-liblua-so.patch: Install liblua.so with
  execute bit set. Move "-fPIC" flag from patch to package definition.
---
 gnu/packages/lua.scm   | 14 +++-
 gnu/packages/patches/lua51-liblua-so.patch | 53 +++---
 2 files changed, 47 insertions(+), 20 deletions(-)

diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm
index 1f58751..3f45b33 100644
--- a/gnu/packages/lua.scm
+++ b/gnu/packages/lua.scm
@@ -73,7 +73,19 @@ for configuration, scripting, and rapid prototyping.")
  version ".tar.gz"))
  (sha256
   (base32 "0cskd4w0g6rdm2q8q3i4n1h3j8kylhs3rq8mxwl9vwlmlxbgqh16"))
- (patches (list (search-patch "lua51-liblua-so.patch")))
+ (patches (list (search-patch "lua51-liblua-so.patch")
+(arguments
+ '(#:phases (modify-phases %standard-phases
+  (delete 'configure))
+   #:test-target "test"
+   #:make-flags (list "PLAT= linux"
+  "CFLAGS= -O2 -Wall -fPIC $(MYCFLAGS)"
+  "MYLDFLAGS= -fPIC"
+  (string-append "INSTALL_TOP= "
+ (assoc-ref %outputs "out"))
+  (string-append "INSTALL_MAN= "
+ (assoc-ref %outputs "out")
+ "/share/man/man1"))
 
 (define-public luajit
   (package
diff --git a/gnu/packages/patches/lua51-liblua-so.patch 
b/gnu/packages/patches/lua51-liblua-so.patch
index 6795f10..6b029de 100644
--- a/gnu/packages/patches/lua51-liblua-so.patch
+++ b/gnu/packages/patches/lua51-liblua-so.patch
@@ -1,13 +1,24 @@
+From 115e612016fe615e6c895af8df7db646114a9860 Mon Sep 17 00:00:00 2001
+From: Leo Famulari 
+Date: Mon, 2 Nov 2015 03:29:47 -0500
+Subject: [PATCH] lua-5.1: Changes to Makefile patches
+
+Install liblua.so with execute bit.
+Don't set -fPIC from here. It will be set in the make flags.
 
 Patch the two Makefile to also create liblua.so
 Original patch by Allan McRae 
 for Archlinux
+---
+ Makefile |  6 +++---
+ src/Makefile | 10 +-
+ 2 files changed, 12 insertions(+), 4 deletions(-)
 
-
-diff -ruN lua-5.1.5/Makefile lua-5.1.5-new/Makefile
 lua-5.1.5/Makefile 2012-02-10 10:50:23.0 +0100
-+++ lua-5.1.5-new/Makefile 2014-09-10 20:17:28.913951433 +0200
-@@ -43,7 +43,7 @@
+diff --git a/Makefile b/Makefile
+index 209a132..653dbed 100644
+--- a/Makefile
 b/Makefile
+@@ -43,7 +43,7 @@ PLATS= aix ansi bsd freebsd generic linux macosx mingw posix 
solaris
  # What to install.
  TO_BIN= lua luac
  TO_INC= lua.h luaconf.h lualib.h lauxlib.h ../etc/lua.hpp
@@ -16,7 +27,7 @@ diff -ruN lua-5.1.5/Makefile lua-5.1.5-new/Makefile
  TO_MAN= lua.1 luac.1
  
  # Lua version and release.
-@@ -53,7 +53,7 @@
+@@ -53,7 +53,7 @@ R= 5.1.5
  all:  $(PLAT)
  
  $(PLATS) clean:
@@ -25,19 +36,20 @@ diff -ruN lua-5.1.5/Makefile lua-5.1.5-new/Makefile
  
  test: dummy
src/lua test/hello.lua
-diff -ruN lua-5.1.5/src/Makefile lua-5.1.5-new/src/Makefile
 lua-5.1.5/src/Makefile 2012-02-13 21:41:22.0 +0100
-+++ lua-5.1.5-new/src/Makefile 2014-09-10 20:16:09.982952152 +0200
-@@ -8,7 +8,7 @@
- PLAT= none
+@@ -62,7 +62,7 @@ install: dummy
+   cd src && $(MKDIR) $(INSTALL_BIN) $(INSTALL_INC) $(INSTALL_LIB) 
$(INSTALL_MAN) $(INSTALL_LMOD) $(INSTALL_CMOD)
+   cd src && $(INSTALL_EXEC) $(TO_BIN) $(INSTALL_BIN)
+   cd src && $(INSTALL_DATA) $(TO_INC) $(INSTALL_INC)
+-  cd src && $(INSTALL_DATA) $(TO_LIB) $(INSTALL_LIB)
++  cd src && $(INSTALL_EXEC) $(TO_LIB) $(INSTALL_LIB)
+   cd doc && $(INSTALL_DATA) $(TO_MAN) $(INSTALL_MAN)
  
- CC= gcc
--CFLAGS= -O2 -Wall $(MYCFLAGS)
-+CFLAGS= -O2 -Wall $(MYCFLAGS) -fPIC
- AR= ar rcu
- RANLIB= ranlib
- RM= rm -f
-@@ -34,9 +34,10 @@
+ ranlib:
+diff --git a/src/Makefile b/src/Makefile
+index e0d4c9f..ebc17e9 100644
+--- a/src/Makefile
 b/src/Makefile
+@@ -34,9 +34,10 @@ LUA_O=  lua.o
  
  LUAC_T=   luac
  LUAC_O=   luac.o print.o
@@ -49,7 +61,7 @@ diff -ruN lua-5.1.5/src/Makefile lua-5.1.5-new/src/Makefile
  ALL_A= $(LUA_A)
  
  default: $(PLAT)
-@@ -57,6 +58,13 @@
+@@ -57,6 +58,13 @@ $(LUA_T): $(LUA_O) $(LUA_A)
  $(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $@ $(MYLDFLAGS) $(LUAC_O) $(LUA_A) $(LIBS)
  
@@ -63,3 +75,6 @@ diff -ruN lua-5.1.5/src/Makefile lua-5.1.5-new/src/Makefile
  clean:
$(RM) $(ALL_T) $(ALL_O)
  
+-- 
+2.6.1
+
-- 
2.6.1

[PATCH 4/5] gnu: Use make-flags and modify-phases for lua-5.2.

2015-11-02 Thread Leo Famulari 
* gnu/packages/lua.scm (lua-5.2)[arguments]: Use make-flags and
  modify-phases to control build process, replacing use of
  'alist-' procedures.
---
 gnu/packages/lua.scm | 27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm
index bb65070..1f58751 100644
--- a/gnu/packages/lua.scm
+++ b/gnu/packages/lua.scm
@@ -43,25 +43,16 @@
 (build-system gnu-build-system)
 (inputs `(("readline", readline)))
 (arguments
- '(#:modules ((guix build gnu-build-system)
-(guix build utils)
-(srfi srfi-1))
+ '(#:phases (modify-phases %standard-phases
+  (delete 'configure))
#:test-target "test"
-   #:phases (alist-replace
- 'build
- (lambda _ (zero? (system* "make"
-   "PLAT=linux"
-   "MYCFLAGS=-fPIC"
-   "MYLDFLAGS=-fPIC")))
- (alist-replace
-  'install
-  (lambda* (#:key outputs #:allow-other-keys)
-(let ((out (assoc-ref outputs "out")))
-  (zero? (system* "make" "install"
-  (string-append "INSTALL_TOP=" out)
-  (string-append "INSTALL_MAN=" out
- "/share/man/man1")
-  (alist-delete 'configure %standard-phases)
+   #:make-flags (list "PLAT= linux"
+  "MYCFLAGS= -fPIC"
+  "MYLDFLAGS= -fPIC"
+  (string-append "INSTALL_TOP= "
+ (assoc-ref %outputs "out"))
+  (string-append "INSTALL_MAN= "
+ (assoc-ref %outputs "out")
 (home-page "http://www.lua.org/;)
 (synopsis "Embeddable scripting language")
 (description
-- 
2.6.1

[PATCH 2/5] gnu: Build lua-5.2 with dynamic library support.

2015-11-02 Thread Leo Famulari 
* gnu/packages/lua.scm (lua-5.2)[arguments]: Rewrite make-flags so that
  Lua is built with platform-specific instructions for shared library
  loading (dlopen).
---
 gnu/packages/lua.scm | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm
index 6bedde3..bbb1b8c 100644
--- a/gnu/packages/lua.scm
+++ b/gnu/packages/lua.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2014 Raimon Grau 
 ;;; Copyright © 2014 Mark H Weaver 
 ;;; Copyright © 2014 Andreas Enge 
+;;; Copyright © 2015 Leo Famulari 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -47,7 +48,10 @@
#:test-target "test"
#:phases (alist-replace
  'build
- (lambda _ (zero? (system* "make" "CFLAGS=-fPIC" "linux")))
+ (lambda _ (zero? (system* "make"
+   "PLAT=linux"
+   "MYCFLAGS=-fPIC"
+   "MYLDFLAGS=-fPIC")))
  (alist-replace
   'install
   (lambda* (#:key outputs #:allow-other-keys)
-- 
2.6.1

[PATCH 2/2] gnu: Add owncloud-client.

2015-11-02 Thread Efraim Flashner 
* gnu/packages/owncloud.scm (owncloud-client): New variable.
* gnu-system.am [GNU_SYSTEM_MODULES]: Add it.
---
 gnu-system.am |  1 +
 gnu/packages/owncloud.scm | 76 +++
 2 files changed, 77 insertions(+)
 create mode 100644 gnu/packages/owncloud.scm

diff --git a/gnu-system.am b/gnu-system.am
index 36e7b6e..ff92bf5 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -241,6 +241,7 @@ GNU_SYSTEM_MODULES =\
   gnu/packages/openstack.scm   \
   gnu/packages/orpheus.scm \
   gnu/packages/ots.scm \
+  gnu/packages/owncloud.scm\
   gnu/packages/package-management.scm  \
   gnu/packages/parallel.scm\
   gnu/packages/password-utils.scm  \
diff --git a/gnu/packages/owncloud.scm b/gnu/packages/owncloud.scm
new file mode 100644
index 000..b37b9b6
--- /dev/null
+++ b/gnu/packages/owncloud.scm
@@ -0,0 +1,76 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2015 Efraim Flashner 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages owncloud)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix build-system cmake)
+  #:use-module (guix download)
+  #:use-module (guix packages)
+  #:use-module (gnu packages compression)
+  #:use-module (gnu packages databases)
+  #:use-module (gnu packages linux)
+  #:use-module (gnu packages perl)
+  #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages qt)
+  #:use-module (gnu packages ruby)
+  #:use-module (gnu packages tls))
+
+(define-public owncloud-client
+  (package
+(name "owncloud-client")
+(version "2.0.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://download.owncloud.com/desktop/stable/;
+   "owncloudclient-" version ".tar.xz"))
+   (sha256
+(base32 "0a42nqx0gn10n7ikhxwif0lqddmb6gbvr45bqbbl30an9gixq598"
+(build-system cmake-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+(add-after 'unpack 'change-rpath-dirs
+  (lambda _
+   (substitute* '("src/libsync/CMakeLists.txt"
+  "csync/src/CMakeLists.txt")
+ (("\\/\\$\\{APPLICATION_EXECUTABLE\\}") ""))
+   (substitute* '("src/cmd/CMakeLists.txt"
+  "src/crashreporter/CMakeLists.txt"
+  "src/gui/CMakeLists.txt")
+ (("\\/\\$\\{APPLICATION_EXECUTABLE\\}\\\"") 
"\"")))
+(native-inputs `(("pkg-config" ,pkg-config)))
+(inputs
+ `(("inotify-tools" ,inotify-tools)
+   ("openssl" ,openssl)
+   ("perl" ,perl)
+   ("python-wrapper" ,python-wrapper)
+   ("qt" ,qt)
+   ("qtkeychain" ,qtkeychain)
+   ("ruby" ,ruby)
+   ("sqlite" ,sqlite)
+   ("zlib" ,zlib)))
+(home-page "https://owncloud.org;)
+(synopsis "GUI folder synchronization with an ownCloud server")
+(description "The ownCloudSync system lets you always have your latest
+files wherever you are.  Just specify one or more folders on the local machine
+to and a server to synchronize to.  You can configure more computers to
+synchronize to the same server and any change to the files on one computer will
+silently and reliably flow across to every other.")
+(license license:gpl2+)))
-- 
2.6.2

Re: [PATCHES] Mupen64Plus

2015-11-02 Thread Leo Famulari 
On Mon, Nov 2, 2015, at 17:04, Taylan Ulrich Bayırlı/Kammer wrote:
> (I can't use git-send-email with git installed from Guix for some
> reason; it says subcommand not found.)

Off-topic, but this happened to me, too. I'm still using Debian's git,
but I bet the problem is that git-send-email needs to be able to find an
SMTP client. And, of course, that clients needs to be configured.

Re: Timestamps in ...-autoloads.el files

2015-11-02 Thread Alex Kost 
Ludovic Courtès (2015-10-21 19:55 +0300) wrote:

> Alex Kost  skribis:
>
>> I like the idea to honor SOURCE_DATE_EPOCH, so I'm attaching a patch for
>> this.  But now I don't know how to make Guix set this variable during
>> the build process :-(  Need help.
>
> Ahem, eventually, we’ll have to set it in ‘gnu-build’ in (guix build
> gnu-build-system) in the next ‘core-updates’ cycle.

So would it be as simple as this (?):

diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
index ff7646b..92e15d1 100644
--- a/guix/build/gnu-build-system.scm
+++ b/guix/build/gnu-build-system.scm
@@ -576,6 +576,9 @@ in order.  Return #t if all the PHASES succeeded, #f otherwise."
   ;; Encoding/decoding errors shouldn't be silent.
   (fluid-set! %default-port-conversion-strategy 'error)
 
+  ;; Avoid non-determinism related to generated timestamps.
+  (setenv "SOURCE_DATE_EPOCH" "1")
+
   ;; The trick is to #:allow-other-keys everywhere, so that each procedure in
   ;; PHASES can pick the keyword arguments it's interested in.
   (every (match-lambda

> In the interim, we can set it in a phase of ‘emacs-build-system’, which
> would entail few rebuilds.
>
> WDYT?

I think it is not so important to make a temporary workaround for
master.  What about just fixing it in core-updates?

>> +++ b/gnu/packages/patches/emacs-source-date-epoch.patch
>> @@ -0,0 +1,20 @@
>> +Honor SOURCE_DATE_EPOCH variable to avoid non-determinism in generated
>> +"autoloads" files.
>> +
>> +--- a/lisp/emacs-lisp/autoload.el
>>  b/lisp/emacs-lisp/autoload.el
>> +@@ -378,8 +378,12 @@
>> +   "Insert the section-header line,
>> + which lists the file name and which functions are in it, etc."
>> +   (insert generate-autoload-section-header)
>> +-  (prin1 `(autoloads ,autoloads ,load-name ,file ,time)
>> +-outbuf)
>> ++  (let* ((env  (getenv "SOURCE_DATE_EPOCH"))
>> ++ (time (if env
>> ++   (seconds-to-time (string-to-number env))
>> ++ time)))
>> ++(prin1 `(autoloads ,autoloads ,load-name ,file ,time)
>> ++   outbuf))
>> +   (terpri outbuf)
>> +   ;; Break that line at spaces, to avoid very long lines.
>> +   ;; Make each sub-line into a comment.
>
> Could you also submit it upstream, Cc’ing guix-devel and
> reproducible-bui...@lists.alioth.debian.org?  Hopefully that is
> acceptable.  (I searched a bit but didn’t find a similar patch by the
> Debian Reproducible team, but patch-tracker.debian.org is unreachable.)

I'm afraid it's a too hard task for me, sorry.  I wouldn't like to mail
to so many places.

Sorry for the long delay.

-- 
Alex

[PATCH 0/2] Owncloud-client

2015-11-02 Thread Efraim Flashner 
Owncloud-client depends on qtkeychain, so both are packaged. I have learned
that if/when I write my own programs I'm not such a fan of cmake.

Efraim Flashner (2):
  gnu: Add qtkeychain.
  gnu: Add owncloud-client.

 gnu-system.am |  1 +
 gnu/packages/owncloud.scm | 76 +++
 gnu/packages/qt.scm   | 37 ++-
 3 files changed, 113 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/owncloud.scm

-- 
2.6.2

[PATCHES] Mupen64Plus

2015-11-02 Thread Taylan Ulrich Bayırlı/Kammer 
(I can't use git-send-email with git installed from Guix for some
reason; it says subcommand not found.)

So here's 11 patches that add Mupen64Plus, the console front-end, and
many essential plugins.

These packages need to be used in a somewhat peculiar way:

- install *both* mupen64plus-core and mupen64plus-ui-console in your
  profile,

- install all the plugins in your profile,

- in your config file ($XDG_CONFIG_HOME/mupen64plus/mupen64plus.cfg),
  set Core/SharedDataPath to $guix_profile/share/mupen64plus, and set
  UI-Console/PluginDir to $guix_profile/lib/mupen64plus,

- specify your input/audio/video/rsp plugins of choice (for video, the
  Glide64 ones work well for me, and the HLE one for RSP).

That yields a working setup.  I don't know if I can make it work any
better out of the box (without horrible hacks and/or substantial patches
to the C code) because the whole system seems to assume the existence of
a single "shared data" and a single "plugin" directory, so a user is
best served by installing all preferred mupen64plus-* packages into one
profile and then pointing the data and plugin directories there as
described above.  In particular, the -core package needs to be installed
too (despite ui-console already closing over it) because it also
provides a data file without which some things don't work.

By the way, some video plugins don't work out of the box, and I don't
really know how to make them work or if they're entirely broken, but
they're packaged by Debian as well (with the same kinds of breakage out
of the box) so I also packaged them.

>From 1fbd12332633093875f4272208207ab88fb4b9ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
 
Date: Mon, 2 Nov 2015 00:38:01 +0100
Subject: [PATCH 01/11] gnu: Add mupen64plus-core.

* gnu/packages/games.scm (mupen64plus-core): New variable.
---
 gnu/packages/games.scm | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 865bfca..76e5eb7 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -1215,6 +1215,52 @@ world}, @uref{http://evolonline.org, Evol Online} and
 ;; The rest is under GPL2+.
 (license (list license:gpl2+ license:zlib license:cc-by-sa4.0
 
+(define-public mupen64plus-core
+  (package
+(name "mupen64plus-core")
+(version "2.5")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"https://github.com/mupen64plus/mupen64plus-core/archive/;
+version ".tar.gz"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"0dg2hksm5qni2hcha93k7n4fqr92888p946f7phb0ndschzfh9kk"
+(build-system gnu-build-system)
+(native-inputs
+ `(("pkg-config" ,pkg-config)
+   ("which" ,which)))
+(inputs
+ `(("freetype" ,freetype)
+   ("glu" ,glu)
+   ("libpng" ,libpng)
+   ("mesa" ,mesa)
+   ("sdl2" ,sdl2)
+   ("zlib" ,zlib)))
+(arguments
+ '(#:phases
+   (modify-phases %standard-phases
+ ;; The mupen64plus build system has no configure phase.
+ (delete 'configure)
+ ;; Makefile is in a subdirectory.
+ (add-before
+  'build 'cd-to-project-dir
+  (lambda _
+(chdir "projects/unix"
+   #:make-flags (let ((out (assoc-ref %outputs "out")))
+  (list "all" (string-append "PREFIX=" out)))
+   ;; There are no tests.
+   #:tests? #f))
+(home-page "http://www.mupen64plus.org/;)
+(synopsis "Nintendo 64 emulator core library")
+(description
+ "Mupen64Plus is a cross-platform plugin-based Nintendo 64 (N64) emulator
+which is capable of accurately playing many games.  This package contains the
+core library.")
+(license license:gpl2+)))
+
 (define-public nestopiaue
   (package
 (name "nestopiaue")
-- 
2.5.0

>From 83fff41d840cfa5fc31294593c94368cca737bd7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
 
Date: Mon, 2 Nov 2015 00:38:13 +0100
Subject: [PATCH 02/11] gnu: Add mupen64plus-audio-sdl.

* gnu/packages/games.scm (mupen64plus-audio-sdl): New variable.
---
 gnu/packages/games.scm | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 76e5eb7..198f8b2 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -1261,6 +1261,52 @@ which is capable of accurately playing many games.  This package contains the
 core library.")
 (license license:gpl2+)))
 
+(define-public mupen64plus-audio-sdl
+  (package
+(name "mupen64plus-audio-sdl")
+(version "2.5")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+

Re: [PATCH] Add express-beta-diversity

2015-11-02 Thread Ludovic Courtès 
Hi Ben,

It seems this one had fallen through the cracks, sorry about that!
Don’t hesitate to ping if that happens in the future.

Ben Woodcroft  skribis:

> I noticed when packaging this that when "python" is provided as an
> input (and not python-2), then the python scripts don't get their
> shebangs fixed, because there is no python executable in the $PATH (it
> is python3). This seems not right to me - is there a reason for this,
> maybe so python 2 and 3 can coexist?

By default Python 3.x only installs a ‘python3’ command.  There’s a
‘python-wrapper’ package to provide a ‘python’ wrapper for ‘python3’.

> From 8d6f94c67df09e7830414fcf748da311a1167314 Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft 
> Date: Thu, 15 Oct 2015 22:53:31 +1000
> Subject: [PATCH] gnu: Add express-beta-diversity.
>
> * gnu/packages/bioinformatics.scm (express-beta-diversity): New variable.

Pushed.  Thanks, and apologies for the delay!

Ludo’.

Re: [PATCH] scripts: environment: Ignore user shell when spawning container.

2015-11-02 Thread Ludovic Courtès 
David Thompson  skribis:

> Cross this one off the TODO list, Ludo. ;)

I like that!  :-)

> From 655edf899710544d681acacab93f4f671962fc49 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Sun, 1 Nov 2015 18:34:53 -0500
> Subject: [PATCH] scripts: environment: Ignore user shell when spawning
>  container.
>
> * guix/scripts/environment.scm (%default-options): Remove 'exec'
>   association.
>   (guix-environment): If the user didn't specify a command, use the
>   default shell, or use /bin/sh when a container is requested.

LGTM, thanks!

Ludo’.

Re: Of sounds and locales

2015-11-02 Thread Ludovic Courtès 
matias_jose_s...@autoproduzioni.net skribis:

>> By the way, recently the service API was changed, so those service
>> definitions will not work anymore.
>
> At this point i was exploring the possibility to completely avoid
> compiling by
> defining  only-substitutes installations:
> i couldn't find any option for forcing only-substitutes; is there any?

No.  The problem is that, sometimes, substitutes are unavailable.  In
that case, there’s no solution other than building things yourself.
(Though in practice, of course, the goal is to make that situation very
rare.)

> For the powertop service definition i'll have to adapt the code to the
> new API,
> or it will be impossible to add custom services at all?

Yes it’s still possible.

It might be that Mark already has an updated version; Mark?

Ludo’.

Re: [PATCH] build: Add a scheme custom test driver using SRFI-64.

2015-11-02 Thread Ludovic Courtès 
Mathieu Lirzin  skribis:

> Mathieu Lirzin  writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>> Awesome!  Are the “inner” tests displayed by default?  Or is there some
>>> environment variable to control that?
>>
>> Yes, each test case is displayed by default.
>>
>>> I’d prefer the default to display only file names, as is currently the
>>> case (it’s more concise.)
>>
>> IMO This would be reasonable to have an option for making the output more
>> concise since there are 563 test cases in Guix.  this is not part of the
>> test driver API specification, but it does not seem too hard to add an
>> additional option to the test driver script like what the TAP driver is
>> doing:
>>
>>   
>> https://www.gnu.org/software/automake/manual/automake.html#Use-TAP-with-the-Automake-test-harness
>>
>> I think ‘--brief’ could be a good name for this option.  Default
>> verbosity would specified by adding “AM_SCM_LOG_DRIVER= --brief=yes” in
>^^^
>AM_SCM_LOG_DRIVER_FLAGS

Great.

> From 8a1f52e08c8d33a33066271f0f39d6072baf9854 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin 
> Date: Mon, 26 Oct 2015 23:47:24 +0100
> Subject: [PATCH] build: Add a scheme custom test driver using SRFI-64.
>
> This provides support for multiple scheme test cases in a unique file and
> fixes the fragmentation of '.log' files.
>
> * build-aux/test-driver.scm: New file.
> * Makefile.am (SCM_LOG_DRIVER, AM_SCM_LOG_DRIVER_FLAGS): New variables.
>   (SCM_LOG_COMPILER, AM_SCM_LOG_FLAGS): Delete variables.
>   (AM_TESTS_ENVIRONMENT): Set GUILE_AUTO_COMPILE to 0.
> * doc/guix.texi (Running the Test Suite): Reporting a bug does not
>   require to provide a specific '.log' file anymore.
> * tests/base32.scm, tests/build-utils.scm, tests/builders.scm,
>   tests/challenge.scm, tests/containers.scm, tests/cpan.scm,
>   tests/cpio.scm, tests/cran.scm, tests/derivations.scm, tests/elpa.scm,
>   tests/file-systems.scm, tests/gem.scm, tests/gexp.scm,
>   tests/graph.scm, tests/gremlin.scm, tests/hackage.scm, tests/hash.scm,
>   tests/lint.scm, tests/monads.scm, tests/nar.scm, tests/packages.scm,
>   tests/pk-crypto.scm, tests/pki.scm, tests/profiles.scm,
>   tests/publish.scm, tests/pypi.scm, tests/records.scm,
>   tests/scripts.scm, tests/services.scm, tests/sets.scm, tests/size.scm,
>   tests/snix.scm, tests/store.scm, tests/substitute.scm,
>   tests/syscalls.scm, tests/ui.scm, tests/union.scm, tests/utils.scm:
>   Don't exit at the end of each test.

Looks nice.

If you want you can push it to a wip- branch, and we’ll apply it after
the release.  Or you can keep it locally for later.

Thanks,
Ludo’.

Re: [PATCH] build: Add a scheme custom test driver using SRFI-64.

2015-11-02 Thread Ludovic Courtès 
Mathieu Lirzin  skribis:

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

[...]

>>> One caveat is that ‘tests/cpio.scm‘ is now failing.
>>
>> Why is that?  Does it relate to this change?
>
> I didn't try to debug the problem but it has appeared when I started
> messing with redirection of the output/error ports.  Here is the failure
> output.
>
> test-name: bit-identical to GNU cpio's output
> location: /home/mthl/src/gnu/guix/tests/cpio.scm:49

Is GNU cpio available in $PATH?  Which version is that?  Could you run
this test in ‘master’ to see if the problem shows up?

>>> Since this script is not intented to be exclusively used by Guix, I have
>>> used a generic copyright notice.  I guess Guix is the best place to
>>> challenge and improve it, but IMO it will be better hosted elsewhere
>>> like in Gnulib.  Opinions?
>>
>> I think we could start using it and testing it for a while in Guix, and
>> eventually submit it for inclusion in Gnulib once we are more confident.
>
> So you recommend to add ”this file is part of GNU Guix” and use “GNU
> Guix” instead of “this program” for now?

I think you can leave “this program” so nothing will need to be changed
when you move it elsewhere.

>> However, I’m unsure if we should push it now, or after the release.  On
>> one hand, I’d rather avoid potentially disrupting changes like this
>> now.  On the other hand, since it makes it easier (and different) to
>> report test failures, it’s nice.
>>
>> How confident are you?  :-)
>
> IMHO we should wait after the next release in order to make this test
> driver more bullet proof.

Sounds reasonable.

Thanks!

Ludo’.

“System” and “profile” services

2015-11-02 Thread Ludovic Courtès 
Commits d62e201 and af4c3fd add ‘system-service-type’, which is the now
the real root of the service DAG, and ‘profile-service-type’, which is
the service that populates the system profile
(aka. /run/current-system/profile.)

The latter means that services can add packages to the system profile,
which is useful in some cases.

For instance, with commit 87f4001, Wicd adds itself to the system
profile so that ‘wicd-client’ and other commands are automatically
available, without having to fiddle with the ‘packages’ field of the OS.

This should simplify things a bit.

Ludo’.

Re: 2 (possible) problems in documentation

2015-11-02 Thread Alex Vong 
Hi,

I have written a patch based on the old patch. Does it look good to
you? By the way, does anyone know how to build the guix website from
source? I want to add some labels so that librejs don't complain the
javascripts being non-free on this page
. I have cloned the
guix-artwork repo but I don't know how to set-up or build the websites
(I have zero experience on building websites.).

Cheers,
Alex

On 01/11/2015, Mathieu Lirzin  wrote:
> Hi again,
>
> Mathieu Lirzin  writes:
>
>> What do you think of the following patch?
>>
>>>From ee2f4467d84ad9516b14c7bd14f821e4bec443cc Mon Sep 17 00:00:00 2001
>> From: Mathieu Lirzin 
>> Date: Sun, 1 Nov 2015 16:27:07 +0100
>> Subject: [PATCH] doc: Add an exception in "Running Guix Before It Is
>>  Installed".
>>
>> * doc/contributing.texi (Running Guix Before It Is Installed): Add an
>>   exception footnote for `guix pull'.
>>
>> Suggested-by: Alex Vong 
>
> Please ignore this patch, my mind was confused. :)
>
> --
> Mathieu Lrzin
>
>
From e562ebc9a9e3859ecc0c1c2e8be6f39a44b5be7d Mon Sep 17 00:00:00 2001
From: Alex Vong 
Date: Mon, 2 Nov 2015 23:34:16 +0800
Subject: [PATCH] doc: To clarify `./pre-inst-env guix pull` won't upgrade
 local source tree.

* doc/contributing.texi (Running Guix Before It Is Installed): To clarify
`./pre-inst-env guix pull` won't upgrade local source tree
and add a footnote to explain why (thanks to Alex Kost).
---
 doc/contributing.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index f855daf..6423d85 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -82,6 +82,12 @@ $ sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
 $ ./pre-inst-env guix build hello
 @end example
 
+However, note that @command{./pre-inst-env guix pull} will not upgrade your
+local source tree@footnote{@code{guix pull} fetches the latest guix source,
+compiles it, put it to the store and link "~/.config/guix/latest" to it.}.
+You should run @command{git pull} instead
+if you want to upgrade your local source tree.
+
 @noindent
 Similarly, for a Guile session using the Guix modules:
 
-- 
2.1.4