Re: [PATCH] nls: Update 'de' translation.

[Hartmut Goebel]

Am 05.09.2016 um 00:16 schrieb Ludovic Courtès:
> Yes, it’s handled by the Translation Project (TP).
>  has some information.

It's long ago that I cheked that page :-)

> Could you submit this patch to the German translation team?  See
>  and
> .

It took me 10 minutes, just to find out, where to send the patch. This
was a discouraging experience :-( The Translation Project's website does
not invite casuals helpers, it is quite demanding: "2. Become part of a
team", and "3. Filling out the disclaimer" . I wrote a mail there.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Display diffs between generations.

[Hartmut Goebel]

Am 05.09.2016 um 00:12 schrieb Ludovic Courtès:
> I agree with this as a general principle, of course.  However, my
> experience is that currently -l is hardly usable in practice, because it
> spits out way too many lines.

+1

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/digitale-burgerrechte-in-der-ara-snowden
Kolumne: http://www.cissp-gefluester.de/2010-07-passwoerter-lieben-lernen



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH] gnu: git: Update to 2.10.0.

[Ludovic Courtès]

Leo Famulari  skribis:

> On Sun, Sep 04, 2016 at 02:14:47PM -0400, Leo Famulari wrote:
>> > On Sun, Sep 04, 2016 at 12:02:49PM -0400, Mark H Weaver wrote:
>> >  This update seems to have broken 'cgit' and maybe also 'ruby-puma'.
>> Relevant upstream discussion:
>> https://lists.zx2c4.com/pipermail/cgit/2016-August/003243.html
>
> Updated patch:
> https://lists.zx2c4.com/pipermail/cgit/2016-September/003295.html

As discussed on IRC, given that the patch is not so small, I’d suggest
re-introducing Git 2.9 (with ‘inherit’) and using it for cgit (and maybe
‘ruby-puma’?).

John, could you look into it?

Thanks Leo for finding out the upstream thread!

Ludo’.

Re: (guix modules) and ‘source-module-closure’

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hi!
>
> Commit 7ca87354db53fd1e1a7a3dfeddb9a598ea064bbe adds (guix module),
> which provides a way to compute the closure of a Scheme module by
> looking at its source code.
>
> This has to do with typical ‘with-imported-modules’ usage, as explained
> in the manual:
>
> --8<---cut here---start->8---
>Usually you want the _closure_ of the module to be imported—i.e., the
> module itself and all the modules it depends on—rather than just the
> module; failing to do that, attempts to use the module will fail because
> of missing dependent modules.  The ‘source-module-closure’ procedure
> computes the closure of a module by looking at its source file headers,
> which comes in handy in this case:
>
>  (use-modules (guix modules))   ;for 'source-module-closure'
>
>  (with-imported-modules (source-module-closure
>   '((guix build utils)
> (gnu build vm)))
>(gexp->derivation "something-with-vms"
>  #~(begin
>  (use-modules (guix build utils)
>   (gnu build vm))
>  ...)))
> --8<---cut here---end--->8---
>
> The benefit can be seen in the next commit:
>
>   
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=239c6e276214813f59f761c9dc5cc0e9d266b49b

Ah, very nice!

Why is it necessary to read the file and parse the define-module
expression?  Does Guile not keep any of this information?  Should it?
Will something like this become part of Guile eventually?

~~ Ricardo

Re: Removing the attic package

[Ludovic Courtès]

Hi!

Leo Famulari  skribis:

> I don't want to steer new users towards this broken software, and I
> think removing the package is a safe choice. Current Attic users could
> continue to use it, because it won't be removed from their profile
> unless they do `guix package --remove attic`.

Since, AIUI, Borg is a compatible “continuation” of Attic, it makes
sense to remove Attic.

I had an idea to use a ‘superseded’ entry in ‘properties’ that would
tell ‘guix package’ et al. to upgrade to the new package:

  (package
(name "attic")
;; …
(properties `((superseded . ,borg

ENOSYS, though.

> And Borg can convert Attic repos for users who are interested in
> moving on, so these users will not lose access to their data even if
> they do uninstall Attic on their machines.
>
> Do we have any guidelines about "retiring" packages?

Not yet!

Of course there’s a fine line here: we cannot systematically retire
packages “just” because they have bugs (all of them do ;-)).  So we have
to be cautious.  In this case, it can be considered a serious bug in the
package’s core functionality, *and* there’s a fix provided by a fork, so
I see no obstacle in removing it.

What do people think?

Thanks,
Ludo’.

Re: [PATCH 1/5] gnu: module-init-tools: Prevent line wrapping.

[Ludovic Courtès]

David Craven  skribis:

> * gnu/packages/linux.scm (module-init-tools): Break line.

OK!

Re: [PATCH] gnu: linux-libre-headers: Use modify-phases.

[Ludovic Courtès]

David Craven  skribis:

> * gnu/packages/linux.scm (linux-libre-headers): Use modify phases.

LGTM!  This must go to ‘core-updates’ though, because it triggers a full
rebuild.

Thanks,
Ludo’.

Re: [PATCH 2/5] gnu: linux-libre: Use modify-phases.

[Ludovic Courtès]

David Craven  skribis:

> * gnu/packages/linux.scm (linux-libre): Use modify-phases.

LGTM.  This one is OK for master.

Ludo’.

Re: [PATCH 3/5] gnu: linux-libre: Use system->architecture.

[Ludovic Courtès]

David Craven  skribis:

> * gnu/packages/linux.scm (linux-libre): Use system->architecture.
> ---
>  gnu/packages/linux.scm | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
> index dc7ea78..19851d2 100644
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -286,7 +286,7 @@ for SYSTEM and optionally VARIANT, or #f if there is no 
> such configuration."
> (modify-phases %standard-phases
>   (delete 'configure)
>   (replace 'build
> -   (lambda* (#:key system inputs #:allow-other-keys #:rest args)
> +   (lambda* (#:key inputs #:allow-other-keys #:rest args)
>   ;; Avoid introducing timestamps
>   (setenv "KCONFIG_NOTIMESTAMP" "1")
>   (setenv "KBUILD_BUILD_TIMESTAMP" (getenv "SOURCE_DATE_EPOCH"))
> @@ -295,12 +295,12 @@ for SYSTEM and optionally VARIANT, or #f if there is no 
> such configuration."
>   (system* "patch" "-p1" "--force"
>"-i" (assoc-ref inputs "patch/freedo+gnu"))
>  
> - (let ((arch (car (string-split system #\-
> -   (setenv "ARCH"
> -   (cond ((string=? arch "i686") "i386")
> - ((string=? arch "mips64el") "mips")
> - (else arch)))
> -   (format #t "`ARCH' set to `~a'~%" (getenv "ARCH")))
> + (let ((arch ,(system->linux-architecture
> +   (or (%current-target-system)
> +   (%current-system)
> +   (setenv "ARCH" arch))

Important note: (%current-target-system) returns a GNU triplet such as
“arm-linux-gnueabihf”, whereas (%current-system) returns a “system type”
such as “armhf-linux”.

In practice it works here, and ‘linux-libre-headers’ already does that,
so this patch is OK (can go to master).

However, we should augment the docstring of ‘system->linux-architecture’
to clarify that it accepts both a triplet and a system string.  Could
you do that?

Thanks,
Ludo’.

Re: [PATCH 4/5] gnu: kernel-config: Add armhf kernel config.

[Ludovic Courtès]

David Craven  skribis:

> * gnu/packages/linux.scm (kernel-config): Add armhf.
> * gnu/packages/linux-libre-4.7-armhf.conf

Cool!  Make sure to add the file to gnu/local.mk too.

I wonder if it makes sense to have a single “armhf” configuration.  My
understanding is that the config is often tweaked for the specific ARM
board that is targeted.  Did you have a chance to test this kernel on a
real ARM machine?

Thanks,
Ludo’.

Re: [PATCH 5/5] gnu: linux-libre: Add support for cross-compilation.

[Ludovic Courtès]

David Craven  skribis:

> * gnu/packages/linux.scm (linux-libre): Add support for
>   cross-compilation.

Awesome!  I suppose you tested it with:

  guix build --target=arm-linux-gnueabihf linux-libre

right?

Once this is committed, I’ll add it as a build job for Hydra.

> Sorry about this. I hadn't checked that cross compilation doesn't
> break native compiles. It should be (unless target (setenv ...

Right, don’t break native compiles.  :-)

Other than that the patch LGTM.  OK to commit if it works natively and
with the arm-linux-gnueabihf cross-compilation target!

> Also the patch with the arm config should also add armhf-linux to
> supported-systems

Good point.

Thank you!

Ludo’.

Re: Removing the attic package

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> Do we have any guidelines about "retiring" packages?
>
> Not yet!
>
> Of course there’s a fine line here: we cannot systematically retire
> packages “just” because they have bugs (all of them do ;-)).  So we have
> to be cautious.  In this case, it can be considered a serious bug in the
> package’s core functionality, *and* there’s a fix provided by a fork, so
> I see no obstacle in removing it.

This seems reasonable.

~~ Ricardo

Re: [PATCH 8/9] services: Add sddm service.

[Ludovic Courtès]

David Craven  skribis:

>> Could you instead pass the configuration file via a command-line option
>> or environment variable?
>
> I already opened a bug report - no it's not currently possible...

Ah OK.  In that case there’s no choice indeed.  Could you add the URL of
the upstream bug report next to this etc-service-type extension, so we
can eventually revisit this?

Thanks!

Ludo’.

Re: [PATCH 3/9] services: Export initrc.

[Ludovic Courtès]

David Craven  skribis:

> Yes, the sddm service uses it.

OK, I’m fine with this patch then!

Ludo’.

Re: [PATCH 8/9] services: Add sddm service.

[Ludovic Courtès]

David Craven  skribis:

>> +  (sddm   sddm-configuration-sddm
>> +  (default sddm))
>
>> +  (faces-directorysddm-configuration-faces-directory
>> +  (default #~(string-append #$sddm 
>> "/share/sddm/faces")))
>
> Is sddm bound to the above sddm?

It is bound to the global variable ‘sddm’, which is not what you want
here.

So maybe you should have:

  (faces-directory … (default #f))

and then down the line:

  (or (sddm-configuration-faces-directory config)
  #~(string-append #$(sddm-configuration-sddm config)
   "/share/sddm/faces"))

Ludo’.

Re: [PATCH 1/9] system: vm: Remove -net user flag.

[Ludovic Courtès]

David Craven  skribis:

>> I sympathize with this; what problems are you referring to?
>>
>> The reason for “-net user” is that it allows me to run “dhclient -v
>> eth0” in the VM and get access to the network, which is often what I
>> want.
>
> I usually have the need to add my own flags most of the time anyway.
>
> This is the script I usually use - the line marked > doesn't take
> effect when a -net user flag was already provided:
>
> $($HOME/guix/pre-inst-env guix system vm server-configuration.scm) \
>>-net user,hostfwd=tcp::10022-:22 \

I see, thanks for explaining.

OK for this patch!

Ludo’.

[PATCH] scripts: hash: Add --exclude-.git option.

[Jan Nieuwenhuizen]

Hi!

Added an -g/--exclude-.git option for guix hash.  It is very specific:
it skips toplevel .git directory.  WDYT?

Greetings,
Jan

>From 86a580840f21f858b757cb7f421b0ba1c169e09d Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Mon, 5 Sep 2016 10:27:19 +0200
Subject: [PATCH] scripts: hash: Add --exclude-.git option.

* guix/scripts/hash.scm (show-help): Add help text for --exclude-.git option.
(%options): Add --exclude-.git option.
(guix-hash): Handle exclude-.git option.
* doc/guix.texi ("invoking guix hash"): Update doc.
* tests/guix-hash.sh: Add test.
---
 doc/guix.texi | 11 ++-
 guix/scripts/hash.scm | 14 --
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 5330238..3393a1f 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4616,10 +4616,14 @@ The general syntax is:
 guix hash @var{option} @var{file}
 @end example
 
-@command{guix hash} has the following option:
+@command{guix hash} has the following options:
 
 @table @code
 
+@item --exclude-.git
+@itemx -g
+Exclude the @var{.git} directory when computing a recursive hash.
+
 @item --format=@var{fmt}
 @itemx -f @var{fmt}
 Write the hash in the format specified by @var{fmt}.
@@ -4655,6 +4659,11 @@ $ cd foo
 $ rm -rf .git
 $ guix hash -r .
 @end example
+@noindent
+or simply use the -g (--exclude-.git) option
+@example
+$ guix hash -r -g .
+@end example
 @end table
 
 @node Invoking guix import
diff --git a/guix/scripts/hash.scm b/guix/scripts/hash.scm
index d440953..2933011 100644
--- a/guix/scripts/hash.scm
+++ b/guix/scripts/hash.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014 Ludovic Courtès 
 ;;; Copyright © 2013 Nikita Karetnikov 
+;;; Copyright © 2016 Jan Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -51,6 +52,8 @@ and 'hexadecimal' can be used as well).\n"))
   (format #t (_ "
   -f, --format=FMT   write the hash in the given format"))
   (format #t (_ "
+  -g, --exclude-.git exclude .git directory"))
+  (format #t (_ "
   -r, --recursivecompute the hash on FILE recursively"))
   (newline)
   (display (_ "
@@ -78,6 +81,10 @@ and 'hexadecimal' can be used as well).\n"))
 
   (alist-cons 'format fmt-proc
   (alist-delete 'format result
+(option '(#\g "exclude-.git") #f #f
+(lambda (opt name arg result)
+  (alist-cons 'exclude-.git #t result)))
+
 (option '(#\r "recursive") #f #f
 (lambda (opt name arg result)
   (alist-cons 'recursive? #t result)))
@@ -113,7 +120,10 @@ and 'hexadecimal' can be used as well).\n"))
  value)
 (_ #f))
(reverse opts)))
- (fmt  (assq-ref opts 'format)))
+ (fmt  (assq-ref opts 'format))
+ (select? (if (assq-ref opts 'exclude-.git)
+  (lambda (f s) (not (string= f "./.git")))
+  (const #t
 
 (define (file-hash file)
   ;; Compute the hash of FILE.
@@ -121,7 +131,7 @@ and 'hexadecimal' can be used as well).\n"))
   (with-error-handling
 (if (assoc-ref opts 'recursive?)
 (let-values (((port get-hash) (open-sha256-port)))
-  (write-file file port)
+  (write-file file port #:select? select?)
   (flush-output-port port)
   (get-hash))
 (call-with-input-file file port-sha256
-- 
2.9.3


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

Re: [PATCH 6/9] gnu: Add greenisland.

[Ludovic Courtès]

David Craven  skribis:

> It says:
>
> GNU General Public License version 2.0 or (at your option) version 3.0
> or any later version approved by the KDE Free Qt Foundation.
>
> This means that it's only gpl3+ if the KDE free qt foundation approve it.

So that translates to:

  (list license:gpl3 license:gpl2)

(No LGPL here.)  Could you do that and add the above explanation as a
comment above the ‘license’ field?

OK with these changes, thanks!

Ludo’.

Re: Linux kernel config maintainablility

[Ludovic Courtès]

Hi!

David Craven  skribis:

> So I'm trying to get a linux-libre-kernel for arm going. For arm there
> is a multi_v7_defconfig we can use. I looked at the existing kernel
> configs we have and can't make heads or tails of them. My question is
> are any kernel options needed specifically for guixsd? And can we make
> it more readable/explicit by using a defconfig + adding the guixsd
> specific configs separately? This would allow people like me to
> understand what's actually needed to get guixsd working ;-)

guix-daemon needs CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and that’s about
it.  GuixSD doesn’t have any unusual requirements.

Now, I agree that storing full config files makes it hard to understand
what non-default settings are used.  NixOS has a nicer way to express
this, but long ago people thought it might be fragile:

  https://lists.gnu.org/archive/html/guix-devel/2014-06/msg00108.html
  https://lists.gnu.org/archive/html/guix-devel/2014-09/msg00370.html
  https://lists.gnu.org/archive/html/guix-devel/2014-07/msg00044.html
  
https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/linux-4.7.nix
  
https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/generic.nix
  
https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/generate-config.pl

Thoughts?

Ludo’.

Re: [PATCH] gnu: Add ola

[Ludovic Courtès]

John J Foerch  skribis:

> From d4738938d325dcf0452346f48f0bf02c020bd6d2 Mon Sep 17 00:00:00 2001
> From: "John J. Foerch" 
> Date: Wed, 3 Aug 2016 21:36:52 -0500
> Subject: [PATCH] gnu: Add ola.
>
> * gnu/packages/ola.scm (ola): New variable.

Applied, thanks!

Ludo’.

[PATCH 3/3] gnu: Remove now useless #:tests? #f from java-packages.

[Hartmut Goebel]

With the last commit, when #:jar-name is given, a dummy test-target
always exists.

* gnu/packages/java.scm (java-junit, java-swt, java-xz): Remove
  build-argument `#:tests?'.
---
 gnu/packages/java.scm | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index 7387235..e8d09dd 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -84,7 +84,6 @@
 (build-system ant-build-system)
 (arguments
  `(#:jar-name "swt.jar"
-   #:tests? #f ; no "check" target
#:phases
(modify-phases %standard-phases
  (replace 'unpack
@@ -1054,8 +1053,7 @@ build process and its dependencies, whereas Make uses 
Makefile format.")
"0x6vn9dp9kxk83x2fp3394n95dk8fx9yg8jns9371iqsn0vy8ih1"
(build-system ant-build-system)
(arguments
-`(#:tests? #f ; There are no tests to run.
-  #:jar-name ,(string-append "xz-" version  ".jar")
+`(#:jar-name ,(string-append "xz-" version  ".jar")
   #:phases
   (modify-phases %standard-phases
 ;; The unpack phase enters the "maven" directory by accident.
@@ -1248,8 +1246,7 @@ testing frameworks, mocking libraries and UI validation 
rules.")
   #t
 (build-system ant-build-system)
 (arguments
- `(#:tests? #f ; no tests
-   #:jar-name "junit.jar"))
+ `(#:jar-name "junit.jar"))
 (inputs
  `(("java-hamcrest-core" ,java-hamcrest-core)))
 (home-page "http://junit.org/";)
-- 
2.7.4

Re: QEMU update (security)

[Efraim Flashner]

On Sun, Sep 04, 2016 at 04:20:44PM -0400, Leo Famulari wrote:
> This updates QEMU to the latest release, 2.7.0.
> 
> It fixes at least one security bug (I think that every new QEMU release
> fixes security bugs):
> http://seclists.org/oss-sec/2016/q3/394
> 
> Tested on x86-64.

> From a46d80d697e2ed93596a69b9f170b645f8b608a0 Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Sun, 4 Sep 2016 02:53:37 -0400
> Subject: [PATCH] gnu: qemu: Update to 2.7.0 [fixes CVE-2016-7116].
> 
> * gnu/packages/qemu.scm (qemu): Update to 2.7.0.
> [arguments]: Adjust path in 'disable-test-qga' phase.
> ---
>  gnu/packages/qemu.scm | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/packages/qemu.scm b/gnu/packages/qemu.scm
> index 1b9f0ad..aee6a75 100644
> --- a/gnu/packages/qemu.scm
> +++ b/gnu/packages/qemu.scm
> @@ -69,14 +69,14 @@
>  (define-public qemu
>(package
>  (name "qemu")
> -(version "2.6.1")
> +(version "2.7.0")
>  (source (origin
>   (method url-fetch)
>   (uri (string-append 
> "http://wiki.qemu-project.org/download/qemu-";
>   version ".tar.bz2"))
>   (sha256
>(base32
> -   "1l88iqk0swqccrnjwczgl9arqsvy77bis862zxajy7z3dqdzshj9"
> +   "0lqyz01z90nvxpc3nx4djbci7hx62cwvs5zwd6phssds0sap6vij"
>  (build-system gnu-build-system)
>  (arguments
>   '(;; Running tests in parallel can occasionally lead to failures, like:
> @@ -125,7 +125,7 @@
>   (setenv "V" "1")))
>   (add-before 'check 'disable-test-qga
> (lambda _
> - (substitute* "tests/Makefile"
> + (substitute* "tests/Makefile.include"
> ;; Comment out the test-qga test, which needs /sys and
> ;; fails within the build environment.
> (("check-unit-.* tests/test-qga" all)
> -- 
> 2.10.0
> 

I haven't tested it but it looks good.



-- 
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: Add mb2md

[Ludovic Courtès]

Clément Lassieur  skribis:

> ---
>  gnu/packages/mail.scm | 52 
> +--
>  1 file changed, 50 insertions(+), 2 deletions(-)

Pushed as 24262239da96eeabb0840c178ac6c80792e405c5 with a commit log
that matches our conventions.

Thank you!

Ludo’.

Re: Removing the attic package

[Efraim Flashner]

On Mon, Sep 05, 2016 at 10:20:36AM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Leo Famulari  skribis:
> 
> >
> > Do we have any guidelines about "retiring" packages?
> 
> Not yet!
> 
> Of course there’s a fine line here: we cannot systematically retire
> packages “just” because they have bugs (all of them do ;-)).  So we have
> to be cautious.  In this case, it can be considered a serious bug in the
> package’s core functionality, *and* there’s a fix provided by a fork, so
> I see no obstacle in removing it.
> 
> What do people think?
> 
> Thanks,
> Ludo’.
> 

I think it makes sense to change the description that this package is
slated for eventual removal. Another example is pinentry. We now have 4
pinentry packages, and the original pinentry package just points to
pinentry-gtk. I think it would make sense in that case to change the
description to something like `the pinentry package in guix is
depreciated, please remove it and install pinentry-gtk to retain the
same functinality' or something along those lines.

In this case something about attic having serious unpatched flaws, is
unmaintained, and that borg is a fork & continuation of it, would be a
good change.

That might keep new people from installing it, but how would we get
people who have already installed it to uninstall it? Or to see the
message?

-- 
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] system: grub: Use librsvg to convert SVG to PNG

[Vincent Legoll]

And I also now tested back the other way, if I guix pull (so the patch is
not in effect anymore) now I get inkscape (& al.) back into the store...

-- 
Vincent Legoll

Re: [PATCH] gnu: Add Infernal.

[Efraim Flashner]

On Fri, Sep 02, 2016 at 04:12:21PM +0200, Ricardo Wurmus wrote:
> 
> Thompson, David  writes:
> 
> > On Fri, Sep 2, 2016 at 9:35 AM, Ricardo Wurmus
> >  wrote:
> >> * gnu/packages/bioinformatics.scm (infernal): New variable.
> >> ---
> >>  gnu/packages/bioinformatics.scm | 27 +++
> >>  1 file changed, 27 insertions(+)
> >>
> >> diff --git a/gnu/packages/bioinformatics.scm 
> >> b/gnu/packages/bioinformatics.scm
> >> index 08c2545..1652f71 100644
> >> --- a/gnu/packages/bioinformatics.scm
> >> +++ b/gnu/packages/bioinformatics.scm
> >> @@ -4835,6 +4835,33 @@ data in the form of VCF files.")
> >>  ;; at https://vcftools.github.io/license.html
> >>  (license license:lgpl3)))
> >>
> >> +(define-public infernal
> >> +  (package
> >> +(name "infernal")
> >> +(version "1.1.2")
> >> +(source (origin
> >> +  (method url-fetch)
> >> +  ;; There are no versioned tarballs
> >
> > But the version appears in the URL?
> 
> Sorry, this comment was supposed to be removed before sending out the
> patch.  Noticed it too late.
> 
> >> +  (uri (string-append "http://eddylab.org/software/infernal/";
> >> +  "infernal-" version ".tar.gz"))
> >> +  (sha256
> >> +   (base32
> >> +"0sr2hiz3qxfwqpz3whxr6n82p3x27336v3f34iqznp10hks2935c"
> >> +(build-system gnu-build-system)
> >> +(native-inputs
> >> + `(("perl" ,perl))) ; for tests
> >> +(home-page "http://eddylab.org/infernal/";)
> >> +(synopsis "Inference of RNA alignments")
> >> +(description "Infernal (\"INFERence of RNA ALignment\") is a tool for
> >> +searching DNA sequence databases for RNA structure and sequence 
> >> similarities.
> >> +It is an implementation of a special case of profile stochastic 
> >> context-free
> >> +grammars called @dfn{covariance models} (CMs).  A CM is like a sequence
> >> +profile, but it scores a combination of sequence consensus and RNA 
> >> secondary
> >> +structure consensus, so in many cases, it is more capable of identifying 
> >> RNA
> >> +homologs that conserve their secondary structure more than their primary
> >> +sequence.")
> >> +(license license:bsd-3)))
> >> +
> >>  (define-public r-vegan
> >>(package
> >>  (name "r-vegan")
> >> --
> >> 2.9.3
> >>
> >>
> >
> > LGTM overall.
> 
> Okay, will push in a moment (after removing the wrong comment).
> Thanks for taking a look!
> 
> ~~ Ricardo
> 

After checking the hydra logs I removed support for armhf and mips,
since they lack the necessary hardware features to build the package.

-- 
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: Building for Android and F-Droid

[Efraim Flashner]

On Thu, Sep 01, 2016 at 03:57:13PM +0200, Ricardo Wurmus wrote:
> 
> Thompson, David  writes:
> 
> > Does anyone know what we are missing to be able to package android
> > tools?
> 
> Given the current state of our support for Java I’d say we mostly need
> more Java packages in Guix.  A first big step would be to package enough
> to be able to build Maven from source (no cheating).
> 
> ~~ Ricardo
> 
> 

If anyone wants to play around with f-droid, I have it packaged in my
GUIX_PACKAGE_PATH, waiting to be tested more before breaking it down
into patches and submitting it. Of course currently building apks
doesn't work, and I haven't really tested much of the functionality yet.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
;;; Copyright © 2016 Efraim Flashner 
;;;
;;; This file is an addendum to 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 (wip fdroid)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix download)
  #:use-module (guix packages)
  #:use-module (guix build-system python)
  #:use-module (gnu packages python))

(define-public fdroidserver
  (package
(name "fdroidserver")
(version "0.6.0")
(source
  (origin
(method url-fetch)
(uri (pypi-uri "fdroidserver" version))
(sha256
 (base32
  "1fi4kkgi59gd9nssy9zc86b8rki3m47pd29vc821jgsa89lgjqf5"
(build-system python-build-system)
(arguments
 `(#:phases
   (modify-phases %standard-phases
 ;; this prevents the examples from being installed
 ;; we want to fix this later
 (add-before 'install 'patch-install-locations
   (lambda _
 (substitute* "setup.py"
  (("\\(data_prefix\\ \\+\\ 
'/share/doc/fdroidserver/examples',") "")
  (("\\['buildserver") "'buildserver")
  (("'\\]\\)") "'")
  )
 #t)))
   #:python ,python-2)) ; after 0.6.0 it switches to python3
(inputs
 `(("python2-apache-libcloud" ,python2-apache-libcloud)
   ("python2-mwclient" ,python2-mwclient)
   ("python2-paramiko" ,python2-paramiko)
   ("python2-pillow" ,python2-pillow)
   ("python2-pyasn1" ,python2-pyasn1)
   ("python2-pyasn1-modules" ,python2-pyasn1-modules)
   ("python2-pyyaml" ,python2-pyyaml)
   ("python2-requests" ,python2-requests)))
(propagated-inputs
 `(("python2-crypto" ,python2-crypto))) ; not sure this is the right one
(home-page "https://f-droid.org";)
(synopsis "F-Droid Server Tools")
(description "F-Droid Server Tools")
(license license:agpl3+)))

(define-public python-mwclient
  (package
 (name "python-mwclient")
 (version "0.8.1")
 (source
   (origin
 (method url-fetch)
 (uri (pypi-uri "mwclient" version))
 (sha256
  (base32
   "1r322v6i6xps9xh861rbr4ggshydcgp8cycbdlmgy8qbrh8jg2az"
(build-system python-build-system)
(arguments
 `(#:phases
   (modify-phases %standard-phases
 (replace 'check
   (lambda _
 (zero? (system* "py.test")))
(native-inputs
 `(("python-pytest-cache" ,python-pytest-cache)
   ("python-pytest-cov" ,python-pytest-cov)
   ("python-pytest-pep8" ,python-pytest-pep8)))
(inputs
 `(("python-funcsigs" ,python-funcsigs)
   ("python-mock" ,python-mock)
   ("python-requests" ,python-requests)
   ("python-responses" ,python-responses)
   ("python-six" ,python-six)))
(home-page "https://github.com/mwclient/mwclient";)
(synopsis "MediaWiki API client")
(description "MediaWiki API client")
(license license:expat)
(properties `((python2-variant . ,(delay python2-mwclient))

(define-public python2-mwclient
  (let ((base (package-with-python2
(strip-python2-variant python-mwclient
(package (inherit base)
  (native-inputs
   `(("python2-setuptools" ,python2-setuptools)
 ,@(package-native-inputs base))

(define-public python-funcsigs
  (package
(name "python-funcsigs")
(version "1.0.2")
(source
  (origin
(method url-fetch)
(uri (pypi-uri "funcsigs" version))
(sha256

[PATCH 1/3] guix: ant-build-system: put dummy project-name into default build.xml.

[Hartmut Goebel]

Without this, ant reported error messages like
Target "tests" does not exist in the project "null".
Simple using the jar-name is a good compromise.

* guix/build/ant-build-system.scm (default-build.xml): Add attribute
  to sxml expression.
---
 guix/build/ant-build-system.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/guix/build/ant-build-system.scm b/guix/build/ant-build-system.scm
index 00a4a46..fe7bae5 100644
--- a/guix/build/ant-build-system.scm
+++ b/guix/build/ant-build-system.scm
@@ -40,7 +40,8 @@
   (call-with-output-file "build.xml"
 (lambda (port)
   (sxml->xml
-   `(project (@ (basedir "."))
+   `(project (@ (basedir ".")
+(name ,jar-name))
  (property (@ (name "classes.dir")
   (value "${basedir}/build/classes")))
  (property (@ (name "jar.dir")
-- 
2.7.4

Re: Why was "gnu: wrap-python3: Create more symlinks." reverted?

[Hartmut Goebel]

Hi Leo,
> I reverted the commit in response to this request from Andreas:
> http://lists.gnu.org/archive/html/guix-devel/2016-07/msg00011.html

IC. (I would not even have recognised if you'd CC me, since neither the
subject nor the content strikes me.)

So we have a dilemma now: not adding `python-config` (at al.) to the
wrapper will make packaging more complicated for those Python packages
not caring about python resp. python3 in their Makeifles (or what ever
they use). OTOH, as these problems with cflags show, this may not work
anyway.

I *may* have a look into it, but this will not happen any-time soon.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/filmgesprach-zu-201ecitizenfour201c-in-herrsching

Kolumne: http://www.cissp-gefluester.de/2010-01-hinterturen-allen-ortes



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Hartmut Goebel]

Am 05.09.2016 um 10:43 schrieb Jan Nieuwenhuizen:
> Added an -g/--exclude-.git option for guix hash.  It is very specific:
> it skips toplevel .git directory.  WDYT?

+1.

What about make i the default?

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/filmgesprach-zu-201ecitizenfour201c-in-herrsching

Kolumne: http://www.cissp-gefluester.de/2010-01-hinterturen-allen-ortes



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH 2/3] guix: ant-build-system: add empty `tests` target to default build.xml.

[Hartmut Goebel]

This avoids the need to set #:tests? #f whenever using #:jar-name
(and thus using the default build.xml).

* guix/build/ant-build-system.scm (default-build.xml): Add attribute
  to sxml expression.
---
 guix/build/ant-build-system.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/guix/build/ant-build-system.scm b/guix/build/ant-build-system.scm
index fe7bae5..2cc6bb9 100644
--- a/guix/build/ant-build-system.scm
+++ b/guix/build/ant-build-system.scm
@@ -70,6 +70,7 @@
(arg (@ (line ,(string-append "-cf ${jar.dir}/" 
jar-name
  " -C 
${classes.dir} ."))
 
+ (target (@ (name "tests")))
  (target (@ (name "install"))
  (copy (@ (todir "${dist.dir}"))
(fileset (@ (dir "${jar.dir}"))
-- 
2.7.4

Re: [PATCH] gnu: Add python-pypump

[Efraim Flashner]

On Fri, Aug 19, 2016 at 06:17:47PM -0400, Leo Famulari wrote:
> On Mon, Aug 15, 2016 at 03:17:57PM -0700, Dylan Jeffers wrote:
> > On Mon, 15 Aug 2016 14:41:28 -0400
> > Leo Famulari  wrote:
> > 
> > > On Sun, Aug 14, 2016 at 04:07:11PM -0700, Dylan Jeffers wrote:
> > > > > The latest upstream version 0.7. Is there a reason not to use the
> > > > > latest version in this case?  
> > > > 
> > > > For my immediate purposes, I need pypump 0.6, since thats the
> > > > version used in my projects. Since the versions are quite
> > > > different, maybe we include both of them?  
> > > 
> > > I think we should package the latest version, at least.
> > > 
> > > Maybe we could also package 0.6 with a package 'python-pypump-0.6'
> > > that inherits from python-pypump. Or, you could keep that inherited
> > > python-pypump-0.6 in a private package repo, and use
> > > GUIX_PACKAGE_PATH.
> > > 
> > > I'd prefer the latter option. I don't think we have a precedent of
> > > adding old releases, although we do sometimes keep them around for
> > > compatibility. But I could be mistaken.
> > > 
> > > What do people think we should do?
> > 
> > Yes I agree with the second alternative as well.
> 
> Okay, will you send a patch for it?
> 

I tried to apply the original patch but it failed. Can you send an
updated patch set? I've also included the pypump-0.7 patch that I wrote.
I have no real way to test it, but maybe you do.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 584228d422f8b3ddfda6f04486e1360d7b4820aa Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Sun, 24 Jul 2016 18:00:25 +0300
Subject: [PATCH 2/2] gnu: Add python-pypump.

* gnu/packages/pumpio.scm (python-pypump): New variable.
---
 gnu/packages/pumpio.scm | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/gnu/packages/pumpio.scm b/gnu/packages/pumpio.scm
index a74d474..f834884 100644
--- a/gnu/packages/pumpio.scm
+++ b/gnu/packages/pumpio.scm
@@ -23,7 +23,9 @@
   #:use-module (guix download)
   #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system python)
   #:use-module (gnu packages aspell)
+  #:use-module (gnu packages python)
   #:use-module (gnu packages qt)
   #:use-module (gnu packages web))
 
@@ -66,3 +68,40 @@
 (description "Pumpa is a simple pump.io client written in C++ and Qt.")
 (home-page "https://pumpa.branchable.com/";)
 (license gpl3+)))
+
+(define-public python-pypump
+  (package
+(name "python-pypump")
+(version "0.7")
+(source
+  (origin
+(method url-fetch)
+(uri (pypi-uri "PyPump" version))
+(sha256
+ (base32
+  "0100b8r76hwh4lbiwb2dji6jccpi4hgi2ns7qdgb3lwfidnya3ha"
+(build-system python-build-system)
+(arguments `(#:tests? #f)) ; FIXME: can't find test directory.
+(inputs
+ `(("python-dateutil-2" ,python-dateutil-2)
+   ("python-requests" ,python-requests)
+   ("python-requests-oauthlib" ,python-requests-oauthlib)))
+(home-page "https://github.com/xray7224/PyPump";)
+(synopsis "Python Pump.io library")
+(description "Python Pump.io library")
+(license gpl3+)
+(properties `((python2-variant . ,(delay python2-pypump))
+
+(define-public python2-pypump
+  (let ((pypump (package-with-python2
+  (strip-python2-variant python-pypump
+(package (inherit pypump)
+  (inputs
+   `(("python2-ndg-httpsclient" ,python2-ndg-httpsclient)
+ ("python2-pyasn1" ,python2-pyasn1)
+ ("python2-pyopenssl" ,python2-pyopenssl)
+ ,@(package-inputs pypump)))
+  (native-inputs
+   `(("python2-mock" ,python2-mock)
+ ("python2-setuptools" ,python2-setuptools)
+ ,@(package-native-inputs pypump))
-- 
2.10.0



signature.asc
Description: PGP signature

[PATCH 0/3] Emhancements to the ant-build-system

[Hartmut Goebel]

Enclosed please find two minor enhancments to the ant-build-system and a
small clean-up resulting from these.

Hartmut Goebel (3):
  guix: ant-build-system: put dummy project-name into default build.xml.
  guix: ant-build-system: add empty `tests` target to default build.xml.
  gnu: Remove now useless #:tests? #f from java-packages.

 gnu/packages/java.scm   | 7 ++-
 guix/build/ant-build-system.scm | 4 +++-
 2 files changed, 5 insertions(+), 6 deletions(-)

-- 
2.7.4

Re: [PATCH] gnu: Add Infernal.

[Ricardo Wurmus]

Efraim Flashner  writes:

> On Fri, Sep 02, 2016 at 04:12:21PM +0200, Ricardo Wurmus wrote:
>> 
>> Thompson, David  writes:
>> 
>> > On Fri, Sep 2, 2016 at 9:35 AM, Ricardo Wurmus
>> >  wrote:
>> >> * gnu/packages/bioinformatics.scm (infernal): New variable.

[...]

> After checking the hydra logs I removed support for armhf and mips,
> since they lack the necessary hardware features to build the package.

Thank you.  My apologies for not detecting this earlier.

~~ Ricardo

Re: Removing the attic package

[ng0]

Efraim Flashner  writes:

> [ Unknown signature status ]
> On Mon, Sep 05, 2016 at 10:20:36AM +0200, Ludovic Courtès wrote:
>> Hi!
>> 
>> Leo Famulari  skribis:
>> 
>> >
>> > Do we have any guidelines about "retiring" packages?
>> 
>> Not yet!
>> 
>> Of course there’s a fine line here: we cannot systematically retire
>> packages “just” because they have bugs (all of them do ;-)).  So we have
>> to be cautious.  In this case, it can be considered a serious bug in the
>> package’s core functionality, *and* there’s a fix provided by a fork, so
>> I see no obstacle in removing it.
>> 
>> What do people think?
>> 
>> Thanks,
>> Ludo’.
>> 
>
> I think it makes sense to change the description that this package is
> slated for eventual removal. Another example is pinentry. We now have 4
> pinentry packages, and the original pinentry package just points to
> pinentry-gtk. I think it would make sense in that case to change the
> description to something like `the pinentry package in guix is
> depreciated, please remove it and install pinentry-gtk to retain the
> same functinality' or something along those lines.
>
> In this case something about attic having serious unpatched flaws, is
> unmaintained, and that borg is a fork & continuation of it, would be a
> good change.
>
> That might keep new people from installing it, but how would we get
> people who have already installed it to uninstall it? Or to see the
> message?

Gentoo handles this via an internal message system which might or might
not be connected to one of their email lists. This way they announce
security upgrades, updates, removal notices, etc. Archlinux handles this
via an announcement email list as far as I know. Maybe we could
implement something similar, maybe file based?

I could imagine an mbox/maildir message parser where we could commit
message files into the (sub)directory and it gets posted to an
announce-g...@gnu.org list AND is also made available via some way
associated with the guix package list of current profile or in general
via some guix args to be read by everyone, mandatory to keep on track
with guix updates etc..

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

-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: (guix modules) and ‘source-module-closure’

[Andy Wingo]

On Mon 05 Sep 2016 10:13, Ricardo Wurmus  writes:

> Ah, very nice!
>
> Why is it necessary to read the file and parse the define-module
> expression?  Does Guile not keep any of this information?  Should it?
> Will something like this become part of Guile eventually?

If you have the module loaded, there is "live-module-closure" which uses
the information Guile has at run-time.  I guess Ludovic wanted to get
this information without loading the module, for some reason :)

Andy

Re: Building for Android and F-Droid

[Hartmut Goebel]

Am 05.09.2016 um 11:35 schrieb Efraim Flashner:
> Of course currently building apks
> doesn't work, and I haven't really tested much of the functionality yet.

Well, building apks actually works :-) (I have not tested your code,
though).

fdroid is building it's own build-server VM (this is what
fdroidbuildserver does). And the apks are build in there. For actually
building an apk you'll need the fdroiddata package (which to have
package for guix is quite useless IMHO). See the manual at
 and my updates to the manual
.

So the vision I expressed in my first posting on this thread is: Change
the fdroid-server to use GuixSD (in a container?) instead of a VM :-)

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/filmgesprach-zu-201ecitizenfour201c-in-herrsching

Kolumne: http://www.cissp-gefluester.de/2010-01-hinterturen-allen-ortes



signature.asc
Description: OpenPGP digital signature

go-build-system

[ng0]

Yet another "sidequest" because I keep running into walls with
everything:

I've started working on Gogs which requires so many go
dependencies[0] that I started working on a Go build-system.

The resulting packages which will use the go-build-system I would move
into gnu/packages/golang.scm where the language is located. Go is
established and used enough to include this in guix.

Is this something everyone is okay with?

[0]: https://github.com/gogits/gogs/blob/master/.gopmfile
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Removing the attic package

[ng0]

ng0  writes:

> Efraim Flashner  writes:
>
>> [ Unknown signature status ]
>> On Mon, Sep 05, 2016 at 10:20:36AM +0200, Ludovic Courtès wrote:
>>> Hi!
>>> 
>>> Leo Famulari  skribis:
>>> 
>>> >
>>> > Do we have any guidelines about "retiring" packages?
>>> 
>>> Not yet!
>>> 
>>> Of course there’s a fine line here: we cannot systematically retire
>>> packages “just” because they have bugs (all of them do ;-)).  So we have
>>> to be cautious.  In this case, it can be considered a serious bug in the
>>> package’s core functionality, *and* there’s a fix provided by a fork, so
>>> I see no obstacle in removing it.
>>> 
>>> What do people think?
>>> 
>>> Thanks,
>>> Ludo’.
>>> 
>>
>> I think it makes sense to change the description that this package is
>> slated for eventual removal. Another example is pinentry. We now have 4
>> pinentry packages, and the original pinentry package just points to
>> pinentry-gtk. I think it would make sense in that case to change the
>> description to something like `the pinentry package in guix is
>> depreciated, please remove it and install pinentry-gtk to retain the
>> same functinality' or something along those lines.
>>
>> In this case something about attic having serious unpatched flaws, is
>> unmaintained, and that borg is a fork & continuation of it, would be a
>> good change.
>>
>> That might keep new people from installing it, but how would we get
>> people who have already installed it to uninstall it? Or to see the
>> message?
>
> Gentoo handles this via an internal message system which might or might
> not be connected to one of their email lists. This way they announce
> security upgrades, updates, removal notices, etc. Archlinux handles this
> via an announcement email list as far as I know. Maybe we could
> implement something similar, maybe file based?
>
> I could imagine an mbox/maildir message parser where we could commit
> message files into the (sub)directory and it gets posted to an
> announce-g...@gnu.org list AND is also made available via some way
> associated with the guix package list of current profile or in general
> via some guix args to be read by everyone, mandatory to keep on track
> with guix updates etc..

Immediate solution with even less work: make it part of the website
repository, which displays an rss feed "package news" or something like
that.

>
>> -- 
>> Efraim Flashner  אפרים פלשנר
>> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
>> Confidentiality cannot be guaranteed on emails sent or received unencrypted
>
> -- 
> ng0
> For non-prism friendly talk find me on http://www.psyced.org
>

-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Display diffs between generations.

[Vincent Legoll]

Hello,

On Mon, Sep 5, 2016 at 9:52 AM, Hartmut Goebel
 wrote:
> I agree with this as a general principle, of course.  However, my
> experience is that currently -l is hardly usable in practice, because it
> spits out way too many lines.
>
> +1

Ah, I don't have a lot of packages in my profiles because I'm not using it as my
distro, only experimenting, so I didn't see the problem... So maybe the default
needs to change.

-- 
Vincent Legoll

Re: ghc 8

[ng0]

Ludovic Courtès  writes:

> ng0  skribis:
>
>> should we package ghc 8 in core-updates? It was released in May:
>> https://ghc.haskell.org/trac/ghc/blog/ghc-8.0.1-released
>
> Probably a good idea.  :-)
>
> This can be done in ‘master’, or, if we change to default GHC, to a
> dedicated ‘ghc-update’ branch.
>
> Ludo’.

Should this replace current ghc? I don't know how much of our current
(gnu packages haskell) would break.
For example we have this[0] bug for a current package[1] I am working
on.

Solution A would be to go multiversion, keep ghc7 around for all
packages which do not support ghc8 yet.
Solution B is just update the version and see what breaks on hydra build
of all of haskell.

I'll start this with solution B in a master-ghc8 branch to just take a
look at ghc8 build and see if something fails.

It's contraproductive to my haskell work, but I can't figure out at the
moment why darcs fails in the middle of the build.

[0]: http://bugs.darcs.net/issue2505
[1]: https://gitlab.com/packaging-guix/guix-darcs (mirror)
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Vincent Legoll]

Hello, here are my 2 cts

On Mon, Sep 5, 2016 at 11:20 AM, Hartmut Goebel
 wrote:
> Am 05.09.2016 um 10:43 schrieb Jan Nieuwenhuizen:
>
> Added an -g/--exclude-.git option for guix hash.  It is very specific:
> it skips toplevel .git directory.  WDYT?

I'd rather name it "--exclude-git" or something less strange than
--exclude-.git,
even --exclude-dot-git...

> +1.
>
> What about make i the default?

OK with defaulting

-- 
Vincent Legoll

Re: [PATCH 2/3] guix: ant-build-system: add empty `tests` target to default build.xml.

[Vincent Legoll]

Hello,

On Mon, Sep 5, 2016 at 11:24 AM, Hartmut Goebel
 wrote:
> This avoids the need to set #:tests? #f whenever using #:jar-name
> (and thus using the default build.xml).

Isn't it a bit misleading to have a test target that does no real
testing, or am I
misunderstanding this patch ?

-- 
Vincent Legoll

Re: [PATCH 2/3] guix: ant-build-system: add empty `tests` target to default build.xml.

[Hartmut Goebel]

Hi,

Am 05.09.2016 um 12:59 schrieb Vincent Legoll:
> On Mon, Sep 5, 2016 at 11:24 AM, Hartmut Goebel
>  wrote:
>> This avoids the need to set #:tests? #f whenever using #:jar-name
>> (and thus using the default build.xml).
> Isn't it a bit misleading to have a test target that does no real
> testing, or am I
> misunderstanding this patch ?

When specifying #:jar-file, the ant-builder will create a build.xml.
This build.xml did not include a test-target at all. So one *always* had
to include "#:tests? #f" to disable calling the (non-existing)
test-target - otherwise build would fail. But adding "#:tests? #f" is
just redundant.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Jan Nieuwenhuizen]

Vincent Legoll writes:

>> Added an -g/--exclude-.git option for guix hash.  It is very specific:
>> it skips toplevel .git directory.  WDYT?
>
> I'd rather name it "--exclude-git" or something less strange than
> --exclude-.git,
> even --exclude-dot-git...

>> What about make i the default?
>
> OK with defaulting

Drop the option altogether, or make it --include-git?

Greetings,
Jan

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

Re: [PATCH 6/9] gnu: Add greenisland.

[David Craven]

Done. FYI, it also contains lgpl licenses, it just wasn't relevant to
the gpl vs gpl+ thing...

Re: [PATCH 15/43] gnu: Add ghc-transformers.

[ng0]

This is a complete new language for me.
Through updating ghc to 8.0.1 I learned this is part of ghc itself, is
this correct?

Installing library in
/tmp/guix-build-ghc-8.0.1.drv-0/ghc-8.0.1/ghc-bin/usr/lib/ghc-8.0.1/transformers-0.5.2.0
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/xhtml 
dist-install "strip" '' '/tmp/guix-build-ghc-8.0.1.drv-0/ghc-8.0.1/ghc-bin/usr' 
'/tmp/guix-build-ghc-8.0.1.drv-0/ghc-8.0.1/ghc-bin/usr/lib/ghc-8.0.1' 
'/tmp/guix-build-ghc-8.0.1.drv-0/ghc-8.0.1/ghc-bin/usr/share/doc/ghc-8.0.1/html/libraries'
 'v p dyn'  

ng0  writes:

> * gnu/packages/haskell.scm (ghc-transformers): New variable.
> ---
>  gnu/packages/haskell.scm | 29 +
>  1 file changed, 29 insertions(+)
>
> diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
> index 8236ddb..7e65b52 100644
> --- a/gnu/packages/haskell.scm
> +++ b/gnu/packages/haskell.scm
> @@ -6766,4 +6766,33 @@ permissions are not preserved.  It also provides 
> features for random access
>  to archive content using an index.")
>  (license license:bsd-3)))
>  
> +(define-public ghc-transformers
> +  (package
> +(name "ghc-transformers")
> +(version "0.5.2.0")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + "https://hackage.haskell.org/package/transformers/transformers-";
> + version ".tar.gz"))
> +   (sha256
> +(base32
> + "1qkhi8ssf8c4jnmrw9dzym3igqbzq7h48iisaykdfzdsm09qfh3c"
> +(build-system haskell-build-system)
> +(home-page "http://hackage.haskell.org/package/transformers";)
> +(synopsis "Concrete functor and monad transformers")
> +(description
> + "A portable library of functor and monad transformers, inspired by the 
> paper
> +'Functional Programming with Overloading and Higher-Order Polymorphism',
> +by Mark P Jones.  This package contains the monad transformer class and IO 
> monad class,
> +concrete functor and monad transformers, each with associated operations and 
> functions
> +to lift operations associated with other transformers.  The package can be 
> used on
> +its own in portable Haskell code, in which case operations need to be 
> manually lifted
> +through transformer stacks.  Alternatively, it can be used with the
> +non-portable monad classes in the @code{mtl} or @code{monads-tf} packages,
> +which automatically lift operations introduced by monad transformers through
> +other transformers.")
> +(license license:bsd-3)))
> +
>  ;;; haskell.scm ends here
> -- 
> 2.9.3
>

-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Linux kernel config maintainablility

[David Craven]

Hi Ludo,

> I was hoping we could come up with a way to generate a kernel config,
> either based on ‘allmodconfig’ or something like what NixOS does [0],
> but I’ve become pretty convinced that this would be difficult at best.

What difficulties did you encounter with using allmodconfig as a basis?

> NixOS has a nicer way to express this, but long ago people thought it might 
> be fragile.

I agree that how nixos does it seems a little fragile. From what I've
heard the kernel settings and their defaults change frequently with
each release. This is why I think relying on the kernel devs to
provide reasonable defaults makes more sense IMO.

I'd like to make it easy to build custom kernels, I remember using an
auto detect config feature a while back when using arch. But before
working on that I need to actually transition to guixsd...

Re: Tracking package submissions with Debbugs

[Alex Kost]

David Craven (2016-09-04 20:09 +0300) wrote:

> Why is the gitlab not including the rebase feature a deal breaker?

I'm wondering too.

> It's open source, so disabling the merge button in the ui isn't a big
> deal. We can continue using git push like we've been doing so far...

I also don't see a problem, it's just a missing button in the web
interface, and it doesn't prevent us from using "git rebase" or whatever
is needed to adjust a patch before pushing it to the guix repo.

-- 
Alex

Re: Shepherd redirect stdout/stderr to syslog

[David Craven]

> Is redirecting stdout/stderr to syslog something that
> make-forkexec-constructor could/should do?

I looked into what would be involved. I included a diff that I didn't
test and don't expect to work.

The reason why I don't expect this to work is that running echo
"hello" > /dev/log errors. stracing logger "hello" shows that it makes
use of the socket and sendmsg syscalls instead of the usual open and
write syscalls. I don't understand why though, since what's the point
of everything being a file if they don't share the same interface?

diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index 49f6e8b..69c1cc2 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -712,12 +712,18 @@ false."

  ;; Close all the file descriptors except stdout and stderr.
  (let ((max-fd (max-file-descriptors)))
+   ;; Redirect stdin to use /dev/null
(catch-system-error (close-fdes 0))
-
;; Make sure file descriptor zero is used, so we don't end up reusing
;; it for something unrelated, which can confuse some packages.
(dup2 (open-fdes "/dev/null" O_RDONLY) 0)

+   ;; Redirect stout and stderr to use /dev/log
+   (catch-system-error (close-fdes 1))
+   (catch-system-error (close-fdes 2))
+   (dup2 (open-fdes "/dev/log" O_WRONLY) 1)
+   (dup2 (open-fdes "/dev/log" O_WRONLY) 2)
+
(let loop ((i 3))
  (when (< i max-fd)
(catch-system-error (close-fdes i))

Re: [PATCH 4/5] gnu: kernel-config: Add armhf kernel config.

[Danny Milosavljevic]

> I wonder if it makes sense to have a single “armhf” configuration.  My
> understanding is that the config is often tweaked for the specific ARM
> board that is targeted.

Even worse, it used to be the case that ARM kernels only worked on one specific 
ARM board.

However, the multi configuration is an effort to make it work on any ARM board 
that uses the given architecture. I didn't try these, however.

The multi defconfigs are: multi_v4t_defconfig  multi_v5_defconfig  
multi_v7_defconfig

Re: [PATCH 4/5] gnu: kernel-config: Add armhf kernel config.

[David Craven]

Nixos uses multi_v7_defconfig as a default. It should work at least on
the beaglebone black and raspberry pi 2 - which are probably the most
common boards?

[0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/platforms.nix

Re: [PATCH] Patchseries: perl-www-opensearch and dependencies.

[Efraim Flashner]

On Thu, Aug 18, 2016 at 11:09:23AM +, ng0 wrote:
> Hi,
> 
> Eric Bavier  writes:
> 
> > On Sun, 14 Aug 2016 17:19:10 +
> > ng0  wrote:
> >
> >> This patch series adds perl-www-opensearch and the 13 patches leading to
> >> it (the dependencies).
> >
> > Thanks for all the patches!  Comments dispersed throughtout:
> >
> >> 
> [...]
> >
> > Otherwise LGTM!
> >
> > `~Eric
> 
> Thanks for reviewing. All the problems are addressed, and some
> additional changes to move comments when no test can be run are moved to
> save lines.
> 
> 
> -- 
> ng0
> For non-prism friendly talk find me on http://www.psyced.org

Patches pushed!


-- 
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: lua-5.1: install pkg-config file.

[Efraim Flashner]

On Tue, Aug 16, 2016 at 08:05:12PM +0200, Danny Milosavljevic wrote:
> gnu: lua-5.1: install pkg-config file.
> 
> * gnu/packages/lua.scm (lua-5.1): Modified.
> * gnu/packages/patches/lua51-pkgconfig.patch: New file.
> ---
>  gnu/local.mk   |   1 +
>  gnu/packages/lua.scm   |   3 +-
>  gnu/packages/patches/lua51-pkgconfig.patch | 101 
> +
>  3 files changed, 104 insertions(+), 1 deletion(-)
>  create mode 100644 gnu/packages/patches/lua51-pkgconfig.patch
> 

> diff --git a/gnu/local.mk b/gnu/local.mk
> index 7416850..8d2f754 100644
> --- a/gnu/local.mk
> +++ b/gnu/local.mk
> @@ -648,6 +648,7 @@ dist_patch_DATA = 
> \
>%D%/packages/patches/lua-CVE-2014-5461.patch  \
>%D%/packages/patches/lua-pkgconfig.patch  \
>%D%/packages/patches/lua51-liblua-so.patch\
> +  %D%/packages/patches/lua51-pkgconfig.patch\
>%D%/packages/patches/lua52-liblua-so.patch\
>%D%/packages/patches/luajit-no_ldconfig.patch  \
>%D%/packages/patches/luajit-symlinks.patch \
> diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm
> index b4b5dee..9f72c7c 100644
> --- a/gnu/packages/lua.scm
> +++ b/gnu/packages/lua.scm
> @@ -80,7 +80,8 @@ for configuration, scripting, and rapid prototyping.")
>   (sha256
>(base32 
> "0cskd4w0g6rdm2q8q3i4n1h3j8kylhs3rq8mxwl9vwlmlxbgqh16"))
>   (patches (search-patches "lua51-liblua-so.patch"
> -  "lua-CVE-2014-5461.patch"))
> +  "lua-CVE-2014-5461.patch"
> +  "lua51-pkgconfig.patch"))
>  
>  (define-public luajit
>(package
> diff --git a/gnu/packages/patches/lua51-pkgconfig.patch 
> b/gnu/packages/patches/lua51-pkgconfig.patch
> new file mode 100644
> index 000..5b03ada
> --- /dev/null
> +++ b/gnu/packages/patches/lua51-pkgconfig.patch
> @@ -0,0 +1,101 @@
> +Enables generating Lua's pkg-config file.
> +
> +http://lua-users.org/lists/lua-l/2015-03/msg00338.html
> +
> +--- a/Makefile   2016-08-16 19:44:27.363614964 +0200
>  b/Makefile   2016-08-16 19:49:22.623070005 +0200
> +@@ -13,6 +13,7 @@
> + INSTALL_BIN= $(INSTALL_TOP)/bin
> + INSTALL_INC= $(INSTALL_TOP)/include
> + INSTALL_LIB= $(INSTALL_TOP)/lib
> ++INSTALL_PC= $(INSTALL_LIB)/pkgconfig
> + INSTALL_MAN= $(INSTALL_TOP)/man/man1
> + #
> + # You probably want to make INSTALL_LMOD and INSTALL_CMOD consistent with
> +@@ -41,9 +42,12 @@
> + PLATS= aix ansi bsd freebsd generic linux macosx mingw posix solaris
> + 
> + # What to install.
> +-TO_BIN= lua luac
> ++INTERPRETER= lua
> ++COMPILER= luac
> ++TO_BIN= $(INTERPRETER) $(COMPILER)
> + TO_INC= lua.h luaconf.h lualib.h lauxlib.h ../etc/lua.hpp
> + TO_LIB= liblua.a liblua.so liblua.so.${V}
> ++TO_PC= lua-$(V).pc
> + TO_MAN= lua.1 luac.1
> + 
> + # Lua version and release.
> +@@ -52,17 +56,22 @@
> + 
> + all:$(PLAT)
> + 
> +-$(PLATS) clean:
> ++$(PLATS):
> + cd src && $(MAKE) $@ V=$(V) R=$(R)
> + 
> ++clean:
> ++cd src && $(MAKE) $@
> ++$(RM) $(TO_PC)
> ++
> + test:   dummy
> + src/lua test/hello.lua
> + 
> +-install: dummy
> +-cd src && $(MKDIR) $(INSTALL_BIN) $(INSTALL_INC) $(INSTALL_LIB) 
> $(INSTALL_MAN) $(INSTALL_LMOD) $(INSTALL_CMOD)
> ++install: dummy $(TO_PC)
> ++cd src && $(MKDIR) $(INSTALL_BIN) $(INSTALL_INC) $(INSTALL_LIB) 
> $(INSTALL_PC) $(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_DATA) ../$(TO_PC) $(INSTALL_PC)
> + cd doc && $(INSTALL_DATA) $(TO_MAN) $(INSTALL_MAN)
> + 
> + ranlib:
> +@@ -95,6 +104,7 @@
> + @echo "INSTALL_BIN = $(INSTALL_BIN)"
> + @echo "INSTALL_INC = $(INSTALL_INC)"
> + @echo "INSTALL_LIB = $(INSTALL_LIB)"
> ++@echo "INSTALL_PC = $(INSTALL_PC)"
> + @echo "INSTALL_MAN = $(INSTALL_MAN)"
> + @echo "INSTALL_LMOD = $(INSTALL_LMOD)"
> + @echo "INSTALL_CMOD = $(INSTALL_CMOD)"
> +@@ -111,6 +121,7 @@
> + @echo "TO_BIN = $(TO_BIN)"
> + @echo "TO_INC = $(TO_INC)"
> + @echo "TO_LIB = $(TO_LIB)"
> ++@echo "TO_PC = $(TO_PC)"
> + @echo "TO_MAN = $(TO_MAN)"
> + 
> + # echo config parameters as Lua code
> +@@ -122,7 +133,29 @@
> + @$(MAKE) echo | grep = | sed -e 's/= /= "/' -e 's/$$/"/' #-e 's/""/nil/'
> + @echo "-- EOF"
> + 
> ++pc:
> ++@echo 'prefix=$(INSTALL_TOP)'
> ++@echo 'libdir=$(INSTALL_LIB)'
> ++@echo 'includedir=$(INSTALL_INC)'
> ++@echo 'bindir=$(INSTALL_BIN)'
> ++@echo
> ++@echo 'INSTALL_LMOD=$(INSTALL_LMOD)'
> ++@echo 'INSTALL_CMOD=$(INSTALL_CMOD)'
> ++@echo 'INTERPRETER=$${bindir}/$(INTERPRETER)'
> ++@ech

[PATCH] gnu: Add rpc-daemon service

[John Darrington]

Try this patch


* gnu/services/nfs.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
---
 doc/guix.texi| 16 +++
 gnu/local.mk |  1 +
 gnu/services/nfs.scm | 55 
 3 files changed, 72 insertions(+)
 create mode 100644 gnu/services/nfs.scm

diff --git a/doc/guix.texi b/doc/guix.texi
index b6ca34a..7e3fbfc 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -9975,6 +9975,22 @@ directories are created when the service is activated.
 @node Various Services
 @subsubsection Various Services
 
+@cindex rpcbind
+@subsubheading Rpcbind Service
+
+The @code{(gnu services rpcbind)} module provides the following service.
+
+@deffn {Scheme Procedure} rpcbind-service [#:rpcbind rpcbind] @
+   [#:warm-start? #t]
+Return a service that runs @command{rpcbind}, a server which converts RPC
+program numbers to universal addresses.
+
+Optionally, the package where the daemon is to be found, @var{rpcbind}, may be
+specified.
+If @var{warm-start?} is true (the default), then it will read a state file on
+startup and thus reload state information saved saved by the previous instance.
+@end deffn
+
 @cindex lirc
 @subsubheading Lirc Service
 
diff --git a/gnu/local.mk b/gnu/local.mk
index 50363ef..9d284da 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -389,6 +389,7 @@ GNU_SYSTEM_MODULES =\
   %D%/services/mail.scm\
   %D%/services/mcron.scm   \
   %D%/services/networking.scm  \
+  %D%/services/nfs.scm \
   %D%/services/shepherd.scm\
   %D%/services/herd.scm\
   %D%/services/spice.scm   \
diff --git a/gnu/services/nfs.scm b/gnu/services/nfs.scm
new file mode 100644
index 000..6084f69
--- /dev/null
+++ b/gnu/services/nfs.scm
@@ -0,0 +1,55 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 John Darrington 
+;;;
+;;; 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 services nfs)
+  #:use-module (gnu)
+  #:use-module (gnu services shepherd)
+  #:use-module (gnu packages onc-rpc)
+  #:use-module (guix)
+  #:use-module (guix records)
+  #:export (rpcbind-service-type
+rpcbind-configuration
+rpcbind-configuration?))
+
+(define-record-type* 
+  rpcbind-configuration make-rpcbind-configuration
+  rpcbind-configuration?
+  (rpcbind rpcbind-configuration-rpcbind
+   (default rpcbind))
+  (warm-start? rpcbind-configuration-warm-start?
+   (default #t)))
+
+(define (rpcbind-shepherd-service config)
+  (define pkg
+(rpcbind-configuration-rpcbind config))
+
+  (define rpcbind-command
+#~(list (string-append #$pkg "/bin/rpcbind") "-f"
+#$@(if (rpcbind-configuration-warm-start? config) '("-w") '(
+  
+  (list (shepherd-service
+ (provision '(rpcbind-daemon))
+ (requirement '(networking))
+ (start #~(make-forkexec-constructor #$rpcbind-command))
+ (stop #~(make-kill-destructor)
+
+(define rpcbind-service-type
+  (service-type
+   (name 'rpcbind)
+   (extensions (list (service-extension shepherd-root-service-type
+rpcbind-shepherd-service)
-- 
2.1.4

Re: [PATCH] gnu: vlc: Add inputs.

[Efraim Flashner]

On Sat, Sep 03, 2016 at 06:15:48PM +0200, David Craven wrote:
> Hi Alex,
> 
> I'm not sure we need all those dependencies =) Can you explain what
> they are for? If you are adding dependencies to vlc why did you leave
> libinput-minimal off the list? ;)
> 
> > 3. Our vlc was built with fast-math disabled as explained in the
> > comment. However, this is actually not necessary, vlc would built with
> > '-ffast-math -fno-finite-math-only'.
> 
> This should probably be a separate patch, and will probably have a
> easier path to master...
> 
> Thanks!
> 

also check the closure size with and without samba. A long time ago we
removed samba from mpv and it drastically slimmed down the size of the
closure. IIRC it meant we could no longer do `mpv smb://...'

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

wip u-boot support

[Danny Milosavljevic]

Hi David,

I thought I'd post a minimal version for U-Boot support without any renames 
that aren't absolutely necessary. In this way, the patch is quite small.

I think I also figured out how to pass the name of the bootloader installation 
executable - that's also included.

Let's see whether it works.

See attachement...

I assume that gnu/system/u-boot.scm already exists.

If it doesn't, I've also attached the latest version of it.

As you can see it's no big deal.

Note that the only reasons  is distinct from 
 are:
- The field "board" which contains the board name is necessary in 
 but not .
- The system config's "operating-system" definition contains a "bootloader" 
field that is actually a bootloader-configuration (rather than the actual 
bootloader package or similar). Hence there would be no way to find out which 
bootloader to install if the configuration wasn't a different data structure.

I'm not sure those are good enough reasons to justify distinguishing them.

It would also be possible to change the system config to something like

(operating-system
  (bootloader grub (bootloader-configuration ...)))

and

(operating-system
  (bootloader (make-u-boot-package "my_great_system") (bootloader-configuration 
...)))

and then drop "board". In that case,  would be the same 
as  - but grub-configuration supports theming which 
u-boot-configuration doesn't. We could just ignore the theme parts in that 
case, though.
diff --git a/gnu.scm b/gnu.scm
index 932e4cd..9207e38 100644
--- a/gnu.scm
+++ b/gnu.scm
@@ -35,6 +35,7 @@
 (gnu system mapped-devices)
 (gnu system file-systems)
 (gnu system grub) ; 'grub-configuration'
+(gnu system u-boot)   ; 'u-boot-configuration'
 (gnu system pam)
 (gnu system shadow)   ; 'user-account'
 (gnu system linux-initrd)
diff --git a/gnu/build/install.scm b/gnu/build/install.scm
index 7431a09..92740d5 100644
--- a/gnu/build/install.scm
+++ b/gnu/build/install.scm
@@ -21,7 +21,7 @@
   #:use-module (guix build store-copy)
   #:use-module (srfi srfi-26)
   #:use-module (ice-9 match)
-  #:export (install-grub
+  #:export (install-bootloader
 populate-root-file-system
 reset-timestamps
 register-closure
@@ -36,28 +36,49 @@
 ;;;
 ;;; Code:
 
-(define* (install-grub grub.cfg device mount-point)
+(define* (install-bootloader-config source target)
+  (let* ((pivot  (string-append target ".new")))
+(mkdir-p (dirname target))
+
+;; Copy bootloader config file instead of just symlinking it, because symlinks won't
+;; work when /boot is on a separate partition.  Do that atomically.
+(copy-file source pivot)
+(rename-file pivot target)))
+
+(define* (install-grub grub-name grub.cfg device mount-point)
   "Install GRUB with GRUB.CFG on DEVICE, which is assumed to be mounted on
-MOUNT-POINT.
+MOUNT-POINT. FIXME is that correct?
 
 Note that the caller must make sure that GRUB.CFG is registered as a GC root
 so that the fonts, background images, etc. referred to by GRUB.CFG are not
 GC'd."
-  (let* ((target (string-append mount-point "/boot/grub/grub.cfg"))
- (pivot  (string-append target ".new")))
-(mkdir-p (dirname target))
-
-;; Copy GRUB.CFG instead of just symlinking it, because symlinks won't
-;; work when /boot is on a separate partition.  Do that atomically.
-(copy-file grub.cfg pivot)
-(rename-file pivot target)
-
+  (let ((target (string-append mount-point "/boot/grub/grub.cfg")))
+(install-bootloader-config grub.cfg target)
 (unless (zero? (system* "grub-install" "--no-floppy"
 "--boot-directory"
 (string-append mount-point "/boot")
 device))
   (error "failed to install GRUB"
 
+(define* (install-u-boot u-boot-name extlinux.conf device mount-point)
+  "Install U-Boot with EXTLINUX.CONF on DEVICE, which is assumed to be mounted on
+MOUNT-POINT. FIXME is that correct?"
+(install-bootloader-config extlinux.conf
+   (string-append mount-point
+  "/extlinux.conf"))
+(unless (zero? (system* (string-append u-boot-name "/bin/u-boot-install")
+(string-append "--boot-directory=" mount-point)
+device))
+  (error "failed to install U-Boot")))
+
+(define* (install-bootloader package-output-name config-filename device mount-point)
+  "Install bootloader with CONFIG-FILENAME on DEVICE, which is assumed to be
+mounted on MOUNT-POINT."
+  (let* ((grub? (string-contains package-output-name "grub"))
+ (bootloader-installer (if grub? install-grub
+ install-u-boot)))
+(bootloader-installer package-output-name config-filename device mount-point)))
+
 (define (evaluate-populate-directive directive target)
   "Eval

Re: [PATCH] Add scratch

[Ludovic Courtès]

Hi Nicolas,

Nicolas Goaziou  skribis:

> The following patch adds Scratch to the Guix packages.

Woohoo, nice work!

> There are some caveats:
>
> - it is not the latest version of scratch (1.4 instead of 2.0) as this
>   one required Adobe Air for the offline editor and Flash plugin online.

Yeah.  :-/

> - it freezes when returning from fullscreen execution of a script. Note
>   that the same happens with the Debian package, so there's probably
>   little I can do.

OK.

> - the installation merely copies Scratch.image, which is an image of the
>   VM. It is not a binary blob. You can inspect and modify code from
>   within the application. See
>    for details.

I’m not too familiar with Smalltalk, but still, a VM image is a binary,
right?  It’s a binary that may contain source code, but it’s a binary.
Can it be reproduced?

> - "/usr/share/scratch" directory is hard-coded. As a consequence Scratch
>   cannot find translation files or artwork. You can still import artwork
>   from the store directory but it is not a great out-of-the box
>   experience.
>
>   I notified the issue to the developers
>   (https://github.com/LLK/Scratch_1.4/issues) but, considering other
>   issues there are years old, I have little hope about it.
>
>   If there's an idea on how to fake the "/usr/share/scratch" directory,
>   I'm all ears.

It’s hard-coded in the VM image, right?  If we could rebuild the VM
image “from source”, then we could easily change this file name.

Otherwise we probably have to fiddle with the binary, but since our own
directory name is going to be longer, this is probably not possible.

Some minor comments:

> +(description "Scratch is an easy, interactive, collaborative
> +programming environment designed for creation of interactive stories,
> +animations, games, music, and art -- and sharing these on the web.

For an em dash, write “art---and sharing” (info "(texinfo) Conventions").

> +(home-page "http://scratch.mit.edu";)
> +;; Source is GPL2 licensed, Plugins are MIT licensed and Artwork 
> (sprites,
> +;; backgrounds, sounds...) is CC-BY-SA3.0 licensed.
> +(license (list license:gpl2 license:x11 license:cc-by-sa3.0

So GPLv2-only and X11 (not Expat), right?  Just to make sure.  :-)

> diff --git a/gnu/packages/patches/scratch-desktopfile-semicolon.patch 
> b/gnu/packages/patches/scratch-desktopfile-semicolon.patch
> new file mode 100644
> index 000..b013193
> --- /dev/null
> +++ b/gnu/packages/patches/scratch-desktopfile-semicolon.patch

Please add a line at the beginning of the patch to explain what it does
and what its upstream status is.

Other than that it looks great.

Thanks!

Ludo’.

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Efraim Flashner]

On Mon, Sep 05, 2016 at 01:36:43PM +0200, Jan Nieuwenhuizen wrote:
> Vincent Legoll writes:
> 
> >> Added an -g/--exclude-.git option for guix hash.  It is very specific:
> >> it skips toplevel .git directory.  WDYT?
> >
> > I'd rather name it "--exclude-git" or something less strange than
> > --exclude-.git,
> > even --exclude-dot-git...
> 
> >> What about make i the default?
> >
> > OK with defaulting
> 
> Drop the option altogether, or make it --include-git?
> 
> Greetings,
> Jan
> 

Can this be generalized? `grep \\-download\) gnu/packages/*scm' shows also
svn-download, cvs-download and a lone hg-download.

-- 
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: Tracking package submissions with Debbugs

[Ludovic Courtès]

Hello!

Alex Kost  skribis:

> David Craven (2016-09-04 20:09 +0300) wrote:
>
>> Why is the gitlab not including the rebase feature a deal breaker?
>
> I'm wondering too.
>
>> It's open source, so disabling the merge button in the ui isn't a big
>> deal. We can continue using git push like we've been doing so far...
>
> I also don't see a problem, it's just a missing button in the web
> interface, and it doesn't prevent us from using "git rebase" or whatever
> is needed to adjust a patch before pushing it to the guix repo.

What I would like to ensure is that:

  1. Our commit history is not full of merges of tiny branches, which is
 what GitHub (and I thought Gitlab) encourages.

  2. Contributors can revise their patch series (by rewriting history of
 that series), and committers can incorporate the final patch set,
 rather than the whole sequence of iterations.  This is what we
 currently do; Gitlab should be able to recognize such patterns and
 notice that the “merge request” can be closed, for instance.

  3. People (especially, ahem, me!) can work from the comfort of their
 favorite editor/terminal, or at least without having to run lots of
 JS code and clicking around all day long.

I haven’t used Gitlab so I don’t know whether these requirements are
satisfied.  If you set up an instance of Gitlab-free-software-edition
and we do not have these problems, I’m happy!  :-)

Ludo’.

Re: [PATCH 2/3] guix: ant-build-system: add empty `tests` target to default build.xml.

[Danny Milosavljevic]

Hi Hartmut,

On Mon, 5 Sep 2016 13:32:44 +0200
Hartmut Goebel  wrote:

> When specifying #:jar-file, the ant-builder will create a build.xml.
> This build.xml did not include a test-target at all. So one *always* had
> to include "#:tests? #f" to disable calling the (non-existing)
> test-target - otherwise build would fail. But adding "#:tests? #f" is
> just redundant.

I see what you mean. But is it still possible to easily find out which packages 
have tests and which haven't after your patch?

I think being able to know that is important since it's prudent to trust a 
package without tests (much) less.

Also, would it be possible to auto-discover jUnit tests instead?

Re: Offloading to a VM

[Ludovic Courtès]

David Craven  skribis:

>> The “build hook” is the mechanism by which the daemon asks an external
>> program whether it can build a derivation for some system.
>
>> Our (guix scripts offload) is such a program; it replies positively if
>> there’s a machine that matches the target system.
>
>> What I was suggesting is to have another build hook that would reply
>> positively as long as the target system can be emulated by QEMU.
>
> So I thought about this some more. guix offload uses guix build to
> build a derivation which again uses a different nix-daemon to build
> it. I'm not sure that guix offload can help us here.

Above, I was not suggesting to use ‘guix offload’.  Instead, I was
suggesting to write a new “build hook” that would run qemu-arm,
mentioning (guix scripts offload) as an example of a build hook.

> If it is possible to build a derivation using only qemu-arm instead of
> qemu-system-arm - which I'm still not convinced - I think it's the
> nix-daemon that would have to support this. In build.cc it sets up a
> chroot and then executes the builder. I think it's that builder that
> needs to be run with qemu-arm. But I don't think it's going to be as
> easy as that =)

guix-daemon can be extended via this “build hook” mechanism.  What I’m
proposing is to extend guix-daemon via an external build hook, which
means that guix-daemon itself can remain unchanged.

A derivation is essentially the file name of a “builder” along with its
argv and the needed dependencies.  For a given derivation, the hook
would roughly run:

   qemu-arm /gnu/store/…-builder arg1 arg2 …

Hope this clarifies things!

Ludo’.

wip v2 u-boot support

[Danny Milosavljevic]

Whoops, now with the correct u-boot.scm

On Mon, 5 Sep 2016 21:58:03 +0200
Danny Milosavljevic  wrote:

> Hi David,
> 
> I thought I'd post a minimal version for U-Boot support without any renames 
> that aren't absolutely necessary. In this way, the patch is quite small.
> 
> I think I also figured out how to pass the name of the bootloader 
> installation executable - that's also included.
> 
> Let's see whether it works.
> 
> See attachement...
> 
> I assume that gnu/system/u-boot.scm already exists.
> 
> If it doesn't, I've also attached the latest version of it.
> 
> As you can see it's no big deal.
> 
> Note that the only reasons  is distinct from 
>  are:
> - The field "board" which contains the board name is necessary in 
>  but not .
> - The system config's "operating-system" definition contains a "bootloader" 
> field that is actually a bootloader-configuration (rather than the actual 
> bootloader package or similar). Hence there would be no way to find out which 
> bootloader to install if the configuration wasn't a different data structure.
> 
> I'm not sure those are good enough reasons to justify distinguishing them.
> 
> It would also be possible to change the system config to something like
> 
> (operating-system
>   (bootloader grub (bootloader-configuration ...)))
> 
> and
> 
> (operating-system
>   (bootloader (make-u-boot-package "my_great_system") 
> (bootloader-configuration ...)))
> 
> and then drop "board". In that case,  would be the same 
> as  - but grub-configuration supports theming which 
> u-boot-configuration doesn't. We could just ignore the theme parts in that 
> case, though.
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2013, 2014, 2015, 2016 Ludovic Courtès 
;;; Copyright © 2016 Danny Milosavljevic 
;;;
;;; 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 system u-boot)
  #:use-module (guix store)
  #:use-module (guix packages)
  #:use-module (guix derivations)
  #:use-module (guix records)
  #:use-module (guix monads)
  #:use-module (guix gexp)
  #:use-module (guix download)
  #:use-module (gnu artwork)
  #:use-module (gnu system file-systems)
  #:autoload   (gnu packages u-boot) (make-u-boot-package)
  #:use-module (gnu system grub) ; 
  #:use-module (ice-9 match)
  #:use-module (ice-9 regex)
  #:use-module (srfi srfi-1)
  #:export (u-boot-configuration
u-boot-configuration?
u-boot-configuration-board
u-boot-configuration-package
u-boot-configuration-device
u-boot-configuration-file))

;;; Commentary:
;;;
;;; Configuration of U-Boot.
;;;
;;; Code:

(define-record-type* 
  u-boot-configuration make-u-boot-configuration
  u-boot-configuration?
  (board   u-boot-configuration-board)   ; string ; not optional!
  (u-boot  u-boot-configuration-u-boot   ; package
   (default #f)) ; will actually default to (make-u-boot-package board)
  (device  u-boot-configuration-device); string
  (menu-entriesu-boot-configuration-menu-entries   ; list
   (default '()))
  (default-entry   u-boot-configuration-default-entry  ; integer
   (default 0))
  (timeout u-boot-configuration-timeout; integer
   (default 5)))



(define (u-boot-configuration-package config)
  (or (u-boot-configuration-u-boot config)
  (make-u-boot-package (u-boot-configuration-board config

;;;
;;; Configuration file.
;;;

(define* (u-boot-configuration-file config store-fs entries
  #:key
  (system (%current-system))
  (old-entries '()))
  "Return the U-Boot configuration file corresponding to CONFIG, a
 object, and where the store is available at STORE-FS, a
 object.  OLD-ENTRIES is taken to be a list of menu entries
corresponding to old generations of the system."
  (define linux-image-name
(if (string-prefix? "mips" system)
"vmlinuz"
"bzImage"))

  (define all-entries
(append entries (u-boot-configuration-menu-entries config)))

  (define entry->gexp
(match-lambda
 (($  label linux arguments initrd)
  ;; TODO MENU LABEL hotkeys (using caret)
  #~(format port "LABEL ~s
  MENU LABEL ~a
  KERNEL ~a/~a ~a
  INITRD ~a
 

Re: [PATCH] system: grub: Use librsvg to convert SVG to PNG

[Leo Famulari]

On Fri, Sep 02, 2016 at 04:02:46AM -0400, Mark H Weaver wrote:
> From a50f358b083cff4d156cd7116fee516952fc9bcf Mon Sep 17 00:00:00 2001
> From: Mark H Weaver 
> Date: Fri, 2 Sep 2016 02:26:43 -0400
> Subject: [PATCH] system: grub: Use librsvg to convert SVG to PNG.
> 
> * guix/build/svg.scm: New file.
> * Makefile.am (MODULES): Add it.
> * gnu/system/grub.scm (svg->png): Add 'width' and 'height' arguments.
> Reimplement using (guix build svg).  Drop references to 'inkscape' and
> 'imagemagick'.
> (resize-image): Remove.
> (grub-background-image): Adapt to the incorporation of scaling into
> 'svg->png'.

This works as expected for me on x86_64.

Re: Offloading to a VM

[Ludovic Courtès]

David Craven  skribis:

> The other problem I forgot to mention is that many architectures that
> qemu supports don't support a "kernel emulation" but only a "system
> emulation".

I think we can leave this concern aside as a first approximation:

--8<---cut here---start->8---
$ (cd ~/.guix-profile/bin/ ; ls -1 qemu-* |grep -v system-)
qemu-aarch64
qemu-alpha
qemu-arm
qemu-armeb
qemu-cris
qemu-ga
qemu-i386
qemu-img
qemu-io
qemu-m68k
qemu-microblaze
qemu-microblazeel
qemu-mips
qemu-mips64
qemu-mips64el
qemu-mipsel
qemu-mipsn32
qemu-mipsn32el
qemu-nbd
qemu-or32
qemu-ppc
qemu-ppc64
qemu-ppc64abi32
qemu-ppc64le
qemu-s390x
qemu-sh4
qemu-sh4eb
qemu-sparc
qemu-sparc32plus
qemu-sparc64
qemu-tilegx
qemu-unicore32
qemu-x86_64
--8<---cut here---end--->8---

:-)

Ludo’.

Re: [PATCH 0/1] OpenSSL 1.1.0

[Ludovic Courtès]

Leo Famulari  skribis:

> From 2e6f500c7876733206e231fd98ebe7419d9b076f Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Fri, 2 Sep 2016 16:07:29 -0400
> Subject: [PATCH] gnu: Add openssl-next.
>
> * gnu/packages/tls.scm (openssl-next): New variable.
> * gnu/packages/patches/openssl-1.1.0-c-rehash-in.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.

[...]

> +(arguments
> + `(#:disallowed-references (,perl)
> +   #:parallel-build? #f
> +   #:parallel-tests? #f
> +   #:test-target "test"
> +
> +   ;; Changes to OpenSSL sometimes cause Perl to "sneak in" to the 
> closure,
> +   ;; so we explicitly disallow it here.
> +   #:disallowed-references ,(list (canonical-package perl))
> +   #:phases

Seems like most of the arguments and phases are shared with ‘openssl’,
right?  What about using ‘substitute-keyword-arguments’ to reduce
duplication?  Or are you concerned about potential breakage when one
series or the other changes?

  (arguments
   (substitute-keyword-arguments (package-arguments openssl)
 ((#:phase phases)
  `(modify-phases ,phases
 (add-after 'something 'some-openssl-1.1-specific-phase …)

Thanks!

Ludo’.

Re: [PATCH 36/43] gnu: Add ghc-chell-quickcheck-bootstrap.

[Leo Famulari]

On Sun, Sep 04, 2016 at 04:17:35PM +, ng0 wrote:
> * gnu/packages/haskell.scm (ghc-chell-quickcheck-bootstrap): New variable.

> +(arguments
> + `(#:tests? #f)) 

This will need a comment explaining why.

Re: [PATCH 19/43] gnu: Add ghc-bytestring.

[Leo Famulari]

On Sun, Sep 04, 2016 at 04:17:18PM +, ng0 wrote:
> * gnu/packages/haskell.scm (ghc-bytestring): New variable.

> +(arguments
> + `(#:tests? #f)) ; Test number two becomes non-responsive for 20+ minutes

I have used `strace -f` to check if long-running quiet tests are
actually working or if they are stuck. That could help here.

And, if it's stuck, can you ask upstream if it's a bug?

Re: [PATCH] gnu: Add rpc-daemon service

[Ludovic Courtès]

John Darrington  skribis:

>  Also, the preferred way now is to expose service-type objects and not
>  provide procedures like the one above.  So you can omit this procedure
>  and instead make sure to #:export (rpcbind-service-type).
>
> So what do I then put in /etc/config.scm ?

(operating-system
  ;; …
  (services (cons (service rpcbind-service-type
   (rpcbind-configuration …))
  %base-services)))

>  If you’re willing to play a bit, it would be nice to have a system test
>  that spawns a GuixSD with this service, and then makes sure that, say,
>  the ‘rpcinfo’ program is able to connect to the daemon.  But that’s
>  bonus.  :-)
>  
> Are there some examples of existing system tests?

Yes, in gnu/tests/*.scm.

See also  and
.

HTH!
Ludo’.

Re: Tracking package submissions with Debbugs

[David Craven]

> 1. Our commit history is not full of merges of tiny branches, which is
> what GitHub (and I thought Gitlab) encourages.

Yes, that is right. But as I mentioned in a different thread, there
are many projects where the maintainers agree to not use the merge
button because of this. Since we are using gitlab we can actually go
further than an agreement and disable the merge button entirely.

>   2. Contributors can revise their patch series (by rewriting history of
>  that series), and committers can incorporate the final patch set,
>  rather than the whole sequence of iterations.  This is what we
>  currently do; Gitlab should be able to recognize such patterns and
>  notice that the “merge request” can be closed, for instance.

It depends on how much modification the maintainers make before
pushing. It's git that has to recognize the commits as being the same.
If a contributor can rebase his branch after the PR was merged without
getting any conflicts, gitlab will also recognize that the PR was
merged. Since it's a lot easier to iterate without spamming the
mailing list we can in practice ask contributors to fix issues like
indentation themselves, and if the worst case happens, PR can be
closed manually (in the web interface).

>   3. People (especially, ahem, me!) can work from the comfort of their
>  favorite editor/terminal, or at least without having to run lots of
>  JS code and clicking around all day long.

That's what we all want. The only time it's required to use the web
interface is when creating a new issue or a new PR. After that you can
reply via email, rebase and push via git.

> I haven’t used Gitlab so I don’t know whether these requirements are
> satisfied.  If you set up an instance of Gitlab-free-software-edition
> and we do not have these problems, I’m happy!  :-)

Some adjustments to the workflow might have to be made, but I think we
have to give it a test run of at least a week or two before throwing
the towel ;-)

Who wants to take on this? Any volunteers?

Re: [PATCH] gnu: Add rpc-daemon service

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/services/nfs.scm: New file.
> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

[...]

> +@cindex rpcbind
> +@subsubheading Rpcbind Service

s/Rpcbind/RPC Bind/
Also move the @cindex line after @subsubheading.

> +The @code{(gnu services rpcbind)} module provides the following service.
> +
> +@deffn {Scheme Procedure} rpcbind-service [#:rpcbind rpcbind] @
> +   [#:warm-start? #t]

This procedure no longer exists.  :-)

So instead, you need to add an @defvr for ‘rpcbind-service-type’ and an
@deftp for ‘rpcbind-configuration’, and a couple of sentences to glues
them together (see “Scheduled Job Execution” for an example.)

> +(define (rpcbind-shepherd-service config)
> +  (define pkg
> +(rpcbind-configuration-rpcbind config))
> +
> +  (define rpcbind-command
> +#~(list (string-append #$pkg "/bin/rpcbind") "-f"
> +#$@(if (rpcbind-configuration-warm-start? config) '("-w") '(
> +  
> +  (list (shepherd-service
> + (provision '(rpcbind-daemon))
> + (requirement '(networking))
> + (start #~(make-forkexec-constructor #$rpcbind-command))
> + (stop #~(make-kill-destructor)
> +
> +(define rpcbind-service-type
> +  (service-type
> +   (name 'rpcbind)
> +   (extensions (list (service-extension shepherd-root-service-type
> +rpcbind-shepherd-service)

Better use ‘shepherd-service-type’ here, as noted at
.

And then we’re done.  Could you send an updated patch?

Thank you for your patience!

Ludo’.

Re: [PATCH 4/5] gnu: kernel-config: Add armhf kernel config.

[Leo Famulari]

On Mon, Sep 05, 2016 at 04:29:13PM +0200, David Craven wrote:
> Nixos uses multi_v7_defconfig as a default. It should work at least on
> the beaglebone black and raspberry pi 2 - which are probably the most
> common boards?

I'd expect the Allwinner A20 (Cortex-A7) to be another very popular
system on a chip.

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Danny Milosavljevic]

Hi Jan,

On Mon, 05 Sep 2016 10:43:28 +0200
Jan Nieuwenhuizen  wrote:
> Added an -g/--exclude-.git option for guix hash.  It is very specific:
> it skips toplevel .git directory.  

Why?

Re: Offloading to a VM

[David Craven]

> I think we can leave this concern aside as a first approximation:

Ah interesting. The only architecture other than arm I'm interested in
is riscv. The riscv qemu port doesn't include a syscall emulation. But
I guess the riscv ecosystem still has a long way to go...

> A derivation is essentially the file name of a “builder” along with its
> argv and the needed dependencies.  For a given derivation, the hook
> would roughly run:

>   qemu-arm /gnu/store/…-builder arg1 arg2 …

> Hope this clarifies things!

Yes this does clarify things. Thanks!

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Leo Famulari]

On Mon, Sep 05, 2016 at 01:36:43PM +0200, Jan Nieuwenhuizen wrote:
> Vincent Legoll writes:
> 
> >> Added an -g/--exclude-.git option for guix hash.  It is very specific:
> >> it skips toplevel .git directory.  WDYT?
> >
> > I'd rather name it "--exclude-git" or something less strange than
> > --exclude-.git,
> > even --exclude-dot-git...
> 
> >> What about make i the default?
> >
> > OK with defaulting
> 
> Drop the option altogether, or make it --include-git?

One way or another, we should have a way to `guix hash -r` .git directories
if we really want to.

Re: Graph an operating-system derivation

[Ludovic Courtès]

David Craven  skribis:

>> What info would you like to see on the graph?
>
> Just trying to better understand how guix works.

‘guix system extension-graph’ is an attempt to help with that, by
showing how pieces are connected together, but it doesn’t show the whole
story…

> I wanted to find out where the locale-2.24.drv comes from, but I found
> it (it's in gnu/system/locale.scm obviously :)

:-)

> Maybe guix edit could also work for derivations? It's nice to be able
> to find the source that created/caused the derivation.

Unfortunately derivations are comparable to assembly without debugging
info, so there’s no way to link back to the source.

(There’s no easy way to fix that, notably because .drv live in the same
global store and different sources can lead to the same .drv.)

Ludo’.

Re: [PATCH 2/3] guix: ant-build-system: add empty `tests` target to default build.xml.

[Vincent Legoll]

Hello

On Mon, Sep 5, 2016 at 10:26 PM, Danny Milosavljevic
 wrote:
> I think being able to know that is important since it's prudent to trust a 
> package without tests (much) less.

That's my feeling too

-- 
Vincent Legoll

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Leo Famulari]

On Mon, Sep 05, 2016 at 10:49:23PM +0200, Danny Milosavljevic wrote:
> Hi Jan,
> 
> On Mon, 05 Sep 2016 10:43:28 +0200
> Jan Nieuwenhuizen  wrote:
> > Added an -g/--exclude-.git option for guix hash.  It is very specific:
> > it skips toplevel .git directory.  
> 
> Why?

To calculate the hash of a source that is a Git repository, one clones
the Git repository, checks out the desired commit, removes the '.git'
metadata directory, and then runs `guix hash -r` on the remaining Git
tree.

If the Git repository is very large, it's tedious to make a copy or
re-clone it in order to experiment with different commits. It would be
easier if `guix hash` could skip the '.git' metadata in that case.

Re: Using a function as build-step?

[Ludovic Courtès]

Hi!

Hartmut Goebel  skribis:

> while packaging some java apache common packages, I found myself adding
> some build steps over and over again, like this one:
>
>  (replace 'install
>(lambda* (#:key outputs #:allow-other-keys)
>  (let ((share (string-append (assoc-ref outputs "out")
>  "/share/java")))
>(for-each (λ (f) (install-file f share))
>  (find-files "target" "\\.jar$")
>
> Now I tried replacing this by a simple line like
>
>  (add-after 'install 'install-javadocs install-javadocs)
>
> and of course some function:
>
>   (define* (install-javadoc #:key outputs #:allow-other-keys)
> (let ((docs (string-append (assoc-ref outputs "doc")
>"/share/doc/" ,name "-" ,version "/")))
>   (mkdir-p docs)
>   (copy-recursively "target/apidocs" docs)
>   ))

Note that the commas here (aka. “unquote”) mean that this expression
must be enclosed in a ` (aka. “quasiquote”).  See
.

> I did not manage this - not even if not using "name" and "version" and
> not using any function parameters.
>
> What is the correct code?

Like David, I would suggest creating a build-side module, say, (guix
build java-utils), or maybe augmenting (guix build ant-build-system),
and putting ‘install-javadoc’ in there (Ricardo?).

The code in there will not be in a quasiquote context, so you won’t be
able to use “,name” and “,version” to get at the package name and
version.

Instead, you could use ‘package-name->name+version’ from (guix build
utils):

  (define* (install-javadoc #:key outputs …)
(let ((out (assoc-ref outputs "out")))
  (call-with-values
  (lambda ()
(package-name->name+version (strip-store-file-name out)))
(lambda (name version)
  …

HTH!

Ludo’.

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Jan Nieuwenhuizen]

Efraim Flashner writes:

> Can this be generalized? `grep \\-download\) gnu/packages/*scm' shows also
> svn-download, cvs-download and a lone hg-download.

Okay.  What about simply having non-default

   --exclude=FILE

See attached.  (Missing test included this time).

Greetings,
Jan

>From ae738ad845f6d9e7576c42c53db6f7036b006e6c Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Mon, 5 Sep 2016 10:27:19 +0200
Subject: [PATCH] scripts: hash: Add --exclude option.

* guix/scripts/hash.scm (show-help): Add help text for --exclude option.
(%options): Add --exclude option.
(guix-hash): Handle exclude option.
* doc/guix.texi ("invoking guix hash"): Update doc.
* tests/guix-hash.sh: Add test.
---
 doc/guix.texi | 14 +-
 guix/scripts/hash.scm | 18 +++---
 tests/guix-hash.sh| 17 +
 3 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 5330238..b5c0a7d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4616,10 +4616,17 @@ The general syntax is:
 guix hash @var{option} @var{file}
 @end example
 
-@command{guix hash} has the following option:
+@command{guix hash} has the following options:
 
 @table @code
 
+@item --exclude=@var{file}
+@itemx -e @var{file}
+Exclude @var{file} when computing a recursive hash, e.g.:
+@example
+$ guix hash -r -e .git .
+@end example
+
 @item --format=@var{fmt}
 @itemx -f @var{fmt}
 Write the hash in the format specified by @var{fmt}.
@@ -4655,6 +4662,11 @@ $ cd foo
 $ rm -rf .git
 $ guix hash -r .
 @end example
+@noindent
+or simply use the -e (--exclude) option
+@example
+$ guix hash -r -e .git .
+@end example
 @end table
 
 @node Invoking guix import
diff --git a/guix/scripts/hash.scm b/guix/scripts/hash.scm
index d440953..642e1c0 100644
--- a/guix/scripts/hash.scm
+++ b/guix/scripts/hash.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014 Ludovic Courtès 
 ;;; Copyright © 2013 Nikita Karetnikov 
+;;; Copyright © 2016 Jan Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -49,6 +50,8 @@ Return the cryptographic hash of FILE.
 Supported formats: 'nix-base32' (default), 'base32', and 'base16' ('hex'
 and 'hexadecimal' can be used as well).\n"))
   (format #t (_ "
+  -e, --exclude=FILE exclude FILE when computing hash"))
+  (format #t (_ "
   -f, --format=FMT   write the hash in the given format"))
   (format #t (_ "
   -r, --recursivecompute the hash on FILE recursively"))
@@ -62,7 +65,10 @@ and 'hexadecimal' can be used as well).\n"))
 
 (define %options
   ;; Specification of the command-line options.
-  (list (option '(#\f "format") #t #f
+  (list (option '(#\e "exclude") #t #f
+(lambda (opt name arg result)
+  (alist-cons 'exclude arg result)))
+(option '(#\f "format") #t #f
 (lambda (opt name arg result)
   (define fmt-proc
 (match arg
@@ -78,6 +84,7 @@ and 'hexadecimal' can be used as well).\n"))
 
   (alist-cons 'format fmt-proc
   (alist-delete 'format result
+
 (option '(#\r "recursive") #f #f
 (lambda (opt name arg result)
   (alist-cons 'recursive? #t result)))
@@ -113,7 +120,12 @@ and 'hexadecimal' can be used as well).\n"))
  value)
 (_ #f))
(reverse opts)))
- (fmt  (assq-ref opts 'format)))
+ (fmt  (assq-ref opts 'format))
+ (exclude (assq-ref opts 'exclude))
+ (select? (if exclude
+  (lambda (f s)
+(not (string= f (string-append (car args) "/" exclude
+  (const #t
 
 (define (file-hash file)
   ;; Compute the hash of FILE.
@@ -121,7 +133,7 @@ and 'hexadecimal' can be used as well).\n"))
   (with-error-handling
 (if (assoc-ref opts 'recursive?)
 (let-values (((port get-hash) (open-sha256-port)))
-  (write-file file port)
+  (write-file file port #:select? select?)
   (flush-output-port port)
   (get-hash))
 (call-with-input-file file port-sha256
diff --git a/tests/guix-hash.sh b/tests/guix-hash.sh
index 23df01d..b59939e 100644
--- a/tests/guix-hash.sh
+++ b/tests/guix-hash.sh
@@ -1,5 +1,6 @@
 # GNU Guix --- Functional package management for GNU
 # Copyright © 2013, 2014 Ludovic Courtès 
+# Copyright © 2016 Jan Nieuwenhuizen 
 #
 # This file is part of GNU Guix.
 #
@@ -20,6 +21,7 @@
 # Test the `guix hash' command-line utility.
 #
 
+set -x
 guix hash --version
 
 tmpdir="guix-hash-$$"
@@ -46,4 +48,18 @@ then false; else true; fi
 # the archive format doesn't support.
 if guix hash -r /dev/null
 then false; else true; fi
+
+# Adding a .git directory
+mkdir "$tmpdir/.git"
+touch "$tmpdir/.git/foo"
+
+# ...changes the hash
+test `gu

Re: [PATCH] gnu: Add ding.

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/dictionaries.scm (ding): New variable.

Please add a copyright line for yourself.

> +   ;; It seems that substitute* cannot handle this file.
> +   ;; ISO-8859-1 encoding ?
> +   (zero? (system*
> +   "sed" "-i" "-e"
> +   (string-append
> +"s%exec wish%" "exec " wish "%" ) "ding"))

Should work with:

  (with-fluids ((%default-port-encoding "ISO-8859-1"))
(substitute* …))

> +   (copy-file "ding.desktop"
> +  (string-append sharedir "/ding.desktop"))

Rather: (install-file "ding.desktop" sharedir).

> +   (copy-file "ding.png"
> +  (string-append sharedir "/ding.png"))

Likewise.

> +   (zero?
> +(system* "./install.sh"
> +(synopsis "Dictionary lookup program with a German-English dictionary")
> +(description "Ding is a dictionary lookup program for the X window 
> system.
> +It comes with a German-English dictionary with approximately 270,000 
> entries.")
> +(home-page  "http://www-user.tu-chemnitz.de/~fri/ding/";)
> +(license gpl2+)))

OK with these changes.

Thank you!

Ludo’.

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Leo Famulari]

On Mon, Sep 05, 2016 at 11:04:11PM +0200, Jan Nieuwenhuizen wrote:
> Efraim Flashner writes:
> 
> > Can this be generalized? `grep \\-download\) gnu/packages/*scm' shows also
> > svn-download, cvs-download and a lone hg-download.
> 
> Okay.  What about simply having non-default
> 
>--exclude=FILE

I like this way the best. Hashing source code checkouts is still rare
enough in my experience that it makes sense to take a generalized
approach like this, in my opinion.

> 
> See attached.  (Missing test included this time).
> 
> Greetings,
> Jan
> 

> From ae738ad845f6d9e7576c42c53db6f7036b006e6c Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen 
> Date: Mon, 5 Sep 2016 10:27:19 +0200
> Subject: [PATCH] scripts: hash: Add --exclude option.
> 
> * guix/scripts/hash.scm (show-help): Add help text for --exclude option.
> (%options): Add --exclude option.
> (guix-hash): Handle exclude option.
> * doc/guix.texi ("invoking guix hash"): Update doc.
> * tests/guix-hash.sh: Add test.
> ---
>  doc/guix.texi | 14 +-
>  guix/scripts/hash.scm | 18 +++---
>  tests/guix-hash.sh| 17 +
>  3 files changed, 45 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 5330238..b5c0a7d 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -4616,10 +4616,17 @@ The general syntax is:
>  guix hash @var{option} @var{file}
>  @end example
>  
> -@command{guix hash} has the following option:
> +@command{guix hash} has the following options:
>  
>  @table @code
>  
> +@item --exclude=@var{file}
> +@itemx -e @var{file}
> +Exclude @var{file} when computing a recursive hash, e.g.:
> +@example
> +$ guix hash -r -e .git .
> +@end example
> +
>  @item --format=@var{fmt}
>  @itemx -f @var{fmt}
>  Write the hash in the format specified by @var{fmt}.
> @@ -4655,6 +4662,11 @@ $ cd foo
>  $ rm -rf .git
>  $ guix hash -r .
>  @end example
> +@noindent
> +or simply use the -e (--exclude) option
> +@example
> +$ guix hash -r -e .git .
> +@end example
>  @end table
>  
>  @node Invoking guix import
> diff --git a/guix/scripts/hash.scm b/guix/scripts/hash.scm
> index d440953..642e1c0 100644
> --- a/guix/scripts/hash.scm
> +++ b/guix/scripts/hash.scm
> @@ -1,6 +1,7 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2012, 2013, 2014 Ludovic Courtès 
>  ;;; Copyright © 2013 Nikita Karetnikov 
> +;;; Copyright © 2016 Jan Nieuwenhuizen 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -49,6 +50,8 @@ Return the cryptographic hash of FILE.
>  Supported formats: 'nix-base32' (default), 'base32', and 'base16' ('hex'
>  and 'hexadecimal' can be used as well).\n"))
>(format #t (_ "
> +  -e, --exclude=FILE exclude FILE when computing hash"))
> +  (format #t (_ "
>-f, --format=FMT   write the hash in the given format"))
>(format #t (_ "
>-r, --recursivecompute the hash on FILE recursively"))
> @@ -62,7 +65,10 @@ and 'hexadecimal' can be used as well).\n"))
>  
>  (define %options
>;; Specification of the command-line options.
> -  (list (option '(#\f "format") #t #f
> +  (list (option '(#\e "exclude") #t #f
> +(lambda (opt name arg result)
> +  (alist-cons 'exclude arg result)))
> +(option '(#\f "format") #t #f
>  (lambda (opt name arg result)
>(define fmt-proc
>  (match arg
> @@ -78,6 +84,7 @@ and 'hexadecimal' can be used as well).\n"))
>  
>(alist-cons 'format fmt-proc
>(alist-delete 'format result
> +
>  (option '(#\r "recursive") #f #f
>  (lambda (opt name arg result)
>(alist-cons 'recursive? #t result)))
> @@ -113,7 +120,12 @@ and 'hexadecimal' can be used as well).\n"))
>   value)
>  (_ #f))
> (reverse opts)))
> - (fmt  (assq-ref opts 'format)))
> + (fmt  (assq-ref opts 'format))
> + (exclude (assq-ref opts 'exclude))
> + (select? (if exclude
> +  (lambda (f s)
> +(not (string= f (string-append (car args) "/" 
> exclude
> +  (const #t
>  
>  (define (file-hash file)
>;; Compute the hash of FILE.
> @@ -121,7 +133,7 @@ and 'hexadecimal' can be used as well).\n"))
>(with-error-handling
>  (if (assoc-ref opts 'recursive?)
>  (let-values (((port get-hash) (open-sha256-port)))
> -  (write-file file port)
> +  (write-file file port #:select? select?)
>(flush-output-port port)
>(get-hash))
>  (call-with-input-file file port-sha256
> diff --git a/tests/guix-hash.sh b/tests/guix-hash.sh
> index 23df01d..b59939e 100644
> --- a/tests/guix-hash.sh
> +++ b/tests/guix-hash.sh
> @@ -1,5 +1,6 @@
>  # GNU Guix --- Functional package 

Re: Shepherd redirect stdout/stderr to syslog

[Ludovic Courtès]

David Craven  skribis:

>> Is redirecting stdout/stderr to syslog something that
>> make-forkexec-constructor could/should do?
>
> I looked into what would be involved. I included a diff that I didn't
> test and don't expect to work.
>
> The reason why I don't expect this to work is that running echo
> "hello" > /dev/log errors. stracing logger "hello" shows that it makes
> use of the socket and sendmsg syscalls instead of the usual open and
> write syscalls. I don't understand why though, since what's the point
> of everything being a file if they don't share the same interface?

The important thing is the special format, which includes the date:

  sendto(3, "<13>Sep  5 23:09:51 ludo: foo", 29, 0, NULL, 0) = 29

misc/syslog.c:193 in glibc implements this.

So we would need to pipe each daemon’s stdout/stderr to the Shepherd
itself, which would select(2) on all these, prepend the right prefix,
and write that to /dev/log, I think.

Ludo’.

Re: [PATCH 9/9] gnu: Add weston.

[Ludovic Courtès]

David Craven  skribis:

> Is this ok as a description? I don't think the term display server is
> commonly used for wayland compositors, so I left the synopsis.
>
> (description "Weston is the reference implementation of a Wayland
> compositor, and a useful compositor in its own right.
>
> A Wayland compositor allows applications to render to a shared offscreen
> buffer using opengles.  The compositor then culls the hidden parts and
> composes the final output.  A Wayland compositor is essentially a
> multiplexer to the KMS/DRM kernel devices.")

s/opengles/OpenGL ES/ and s/kernel/Linux kernel/ but otherwise it’s
perfect, thanks!  :-)

> I renamed xwayland to xorg-server-xwayland and added cairo-xcb to
> gtk.scm, xorg-server-xwayland to xorg.scm and weston to
> freedesktop.scm.

OK!

Ludo’.

Re: [PATCH] gnu: Add teximpatient.

[Ludovic Courtès]

John Darrington  skribis:

> * gnu/packages/tex.scm (teximpatient): New variable.

[...]

> +   (install-file
> +(string-append
> + (assoc-ref inputs "automake")
> + "/share/automake-1.15/install-sh")
> +srcdir)

To prevent eventual breakage, I’d do:

  (install-file (car (find-files (assoc-ref inputs "automake")
 "^install-sh$"))
srcdir)

> +(synopsis "Book on TeX, plain TeX and Eplain")
> +(description "TeX for the Impatient is a ~350 page book on TeX, plain 
> TeX,

Probably @i{@TeX{} for the Impatient}.

OK with these changes, thank you!

Ludo’.

Re: (guix modules) and ‘source-module-closure’

[Ludovic Courtès]

Andy Wingo  skribis:

> On Mon 05 Sep 2016 10:13, Ricardo Wurmus  
> writes:
>
>> Ah, very nice!
>>
>> Why is it necessary to read the file and parse the define-module
>> expression?  Does Guile not keep any of this information?  Should it?
>> Will something like this become part of Guile eventually?
>
> If you have the module loaded, there is "live-module-closure" which uses
> the information Guile has at run-time.  I guess Ludovic wanted to get
> this information without loading the module, for some reason :)

Exactly.  Most of the time “build-side” module are not loaded in the
Guile process that uses ‘with-imported-modules’.

It’s a bit of hack but it’s necessary.  Guile could provide this
functionality, but (guix modules) bakes in a few assumptions, notably
that all the source files start with ‘define-module’.

Ludo’.

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Ludovic Courtès]

Hello!

Jan Nieuwenhuizen  skribis:

> Added an -g/--exclude-.git option for guix hash.  It is very specific:
> it skips toplevel .git directory.  WDYT?

Good idea!

> From 86a580840f21f858b757cb7f421b0ba1c169e09d Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen 
> Date: Mon, 5 Sep 2016 10:27:19 +0200
> Subject: [PATCH] scripts: hash: Add --exclude-.git option.
>
> * guix/scripts/hash.scm (show-help): Add help text for --exclude-.git option.
> (%options): Add --exclude-.git option.
> (guix-hash): Handle exclude-.git option.
> * doc/guix.texi ("invoking guix hash"): Update doc.
^
Capital I.  :-)

> * tests/guix-hash.sh: Add test.
>  @table @code
>  
> +@item --exclude-.git
> +@itemx -g

What about --exclude-vcs/-x?  Tar uses that name, although with slightly
different semantics (info "(tar) exclude").

> + (select? (if (assq-ref opts 'exclude-.git)
> +  (lambda (f s) (not (string= f "./.git")))

Rather make the lambda a top-level procedure, like:

  (define (vcs-file? file stat)
(case (stat:type stat)
  ((directory)
   (member (basename file) '(".git" ".svn" "CVS" …)))
  (else
   #f)))

… and then:

  (if (assq-ref opts 'exclude-vcs?)
  (negate vcs-file?)
  (const #t))

Could you send an updated patch?

Thank you for making our lives easier!  :-)

Ludo’.

Re: [PATCH 0/1] OpenSSL 1.1.0

[Leo Famulari]

On Mon, Sep 05, 2016 at 10:35:09PM +0200, Ludovic Courtès wrote:
> Seems like most of the arguments and phases are shared with ‘openssl’,
> right?  What about using ‘substitute-keyword-arguments’ to reduce
> duplication?  Or are you concerned about potential breakage when one
> series or the other changes?

I've attached an updated patch using 'substitute-keyword-arguments'.

BTW, my previous patch made a one-line change to 'move-man3-pages',
deleting the leftover empty man3 directory in the main output after
copying the manpages to the 'doc' output. Is this change desired?

We can deal with breakage when it breaks :)
>From 83405a4ea3628cababd2ee5904c8d0628a002d05 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Fri, 2 Sep 2016 16:07:29 -0400
Subject: [PATCH] gnu: Add openssl-next.

* gnu/packages/tls.scm (openssl-next): New variable.
* gnu/packages/patches/openssl-1.1.0-c-rehash-in.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
---
 gnu/local.mk   |  1 +
 .../patches/openssl-1.1.0-c-rehash-in.patch| 19 
 gnu/packages/tls.scm   | 35 ++
 3 files changed, 55 insertions(+)
 create mode 100644 gnu/packages/patches/openssl-1.1.0-c-rehash-in.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 50363ef..eb8476a 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -701,6 +701,7 @@ dist_patch_DATA =   
\
   %D%/packages/patches/openjpeg-CVE-2015-6581.patch\
   %D%/packages/patches/openjpeg-use-after-free-fix.patch   \
   %D%/packages/patches/openssl-runpath.patch   \
+  %D%/packages/patches/openssl-1.1.0-c-rehash-in.patch \
   %D%/packages/patches/openssl-c-rehash-in.patch   \
   %D%/packages/patches/openssl-CVE-2016-2177.patch \
   %D%/packages/patches/openssl-CVE-2016-2178.patch \
diff --git a/gnu/packages/patches/openssl-1.1.0-c-rehash-in.patch 
b/gnu/packages/patches/openssl-1.1.0-c-rehash-in.patch
new file mode 100644
index 000..e3a982b
--- /dev/null
+++ b/gnu/packages/patches/openssl-1.1.0-c-rehash-in.patch
@@ -0,0 +1,19 @@
+This patch removes the explicit reference to the 'perl' binary,
+such that OpenSSL does not retain a reference to Perl.
+
+The 'c_rehash' program is seldom used, but it is used nonetheless
+to create symbolic links to certificates, for instance in the 'nss-certs'
+package.
+
+diff --git a/tools/c_rehash.in b/tools/c_rehash.in
+index 2fef627..9d40eae 100644
+--- a/tools/c_rehash.in
 b/tools/c_rehash.in
+@@ -1,4 +1,6 @@
+-#!{- $config{hashbangperl} -}
++eval '(exit $?0)' && eval 'exec perl -wS "$0" ${1+"$@"}'
++  & eval 'exec perl -wS "$0" $argv:q'
++if 0;
+ 
+ # {- join("\n# ", @autowarntext) -}
+ # Copyright 1999-2016 The OpenSSL Project Authors. All Rights Reserved.
diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 4b87150..efc1190 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -323,6 +323,41 @@ required structures.")
(license license:openssl)
(home-page "http://www.openssl.org/";)))
 
+(define-public openssl-next
+  (package
+(inherit openssl)
+(name "openssl")
+(version "1.1.0")
+(source (origin
+ (method url-fetch)
+ (uri (list (string-append "ftp://ftp.openssl.org/source/";
+   name "-" version ".tar.gz")
+(string-append "ftp://ftp.openssl.org/source/old/";
+   (string-trim-right version 
char-set:letter)
+   "/" name "-" version ".tar.gz")))
+  (patches (search-patches "openssl-1.1.0-c-rehash-in.patch"))
+  (sha256
+   (base32
+"10lcpmnxap9nw8ymdglys93cgkwd1lf1rz4fhq5whwhlmkwrzipm"
+(outputs '("out"
+   "doc";1.3MiB of man3 pages
+   "static"))   ; 5.5MiB of .a files
+(arguments
+ (substitute-keyword-arguments (package-arguments openssl)
+   ((#:phases phases)
+`(modify-phases ,phases
+   (delete 'patch-tests)  ; These two phases are not needed by
+   (delete 'patch-Makefile.org)   ; OpenSSL 1.1.0.
+
+   (add-after 'configure 'patch-runpath
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let ((lib (string-append (assoc-ref outputs "out") "/lib")))
+ (substitute* "Makefile.shared"
+   (("\\$\\$\\{SHAREDCMD\\} \\$\\$\\{SHAREDFLAGS\\}")
+(string-append "$${SHAREDCMD} $${SHAREDFLAGS}"
+   " -Wl,-rpath," lib)))
+ #t)
+
 (define-public libressl
   (package
 (name "libressl")
-- 
2.10.0

Re: Tracking package submissions with Debbugs

[ng0]

David Craven  writes:

>> 1. Our commit history is not full of merges of tiny branches, which is
>> what GitHub (and I thought Gitlab) encourages.
>
> Yes, that is right. But as I mentioned in a different thread, there
> are many projects where the maintainers agree to not use the merge
> button because of this. Since we are using gitlab we can actually go
> further than an agreement and disable the merge button entirely.
>
>>   2. Contributors can revise their patch series (by rewriting history of
>>  that series), and committers can incorporate the final patch set,
>>  rather than the whole sequence of iterations.  This is what we
>>  currently do; Gitlab should be able to recognize such patterns and
>>  notice that the “merge request” can be closed, for instance.
>
> It depends on how much modification the maintainers make before
> pushing. It's git that has to recognize the commits as being the same.
> If a contributor can rebase his branch after the PR was merged without
> getting any conflicts, gitlab will also recognize that the PR was
> merged. Since it's a lot easier to iterate without spamming the
> mailing list we can in practice ask contributors to fix issues like
> indentation themselves, and if the worst case happens, PR can be
> closed manually (in the web interface).
>
>>   3. People (especially, ahem, me!) can work from the comfort of their
>>  favorite editor/terminal, or at least without having to run lots of
>>  JS code and clicking around all day long.
>
> That's what we all want. The only time it's required to use the web
> interface is when creating a new issue or a new PR. After that you can
> reply via email, rebase and push via git.
>
>> I haven’t used Gitlab so I don’t know whether these requirements are
>> satisfied.  If you set up an instance of Gitlab-free-software-edition
>> and we do not have these problems, I’m happy!  :-)
>
> Some adjustments to the workflow might have to be made, but I think we
> have to give it a test run of at least a week or two before throwing
> the towel ;-)
>
> Who wants to take on this? Any volunteers?

How would we proceed with this? One of us sets up a gitlab instance on a
server under their control?
I could volunteer for a test run.
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: ghc 8

[ng0]

ng0  writes:

> Ludovic Courtès  writes:
>
>> ng0  skribis:
>>
>>> should we package ghc 8 in core-updates? It was released in May:
>>> https://ghc.haskell.org/trac/ghc/blog/ghc-8.0.1-released
>>
>> Probably a good idea.  :-)
>>
>> This can be done in ‘master’, or, if we change to default GHC, to a
>> dedicated ‘ghc-update’ branch.
>>
>> Ludo’.
>
> Should this replace current ghc? I don't know how much of our current
> (gnu packages haskell) would break.
> For example we have this[0] bug for a current package[1] I am working
> on.
>
> Solution A would be to go multiversion, keep ghc7 around for all
> packages which do not support ghc8 yet.
> Solution B is just update the version and see what breaks on hydra build
> of all of haskell.
>
> I'll start this with solution B in a master-ghc8 branch to just take a
> look at ghc8 build and see if something fails.
>
> It's contraproductive to my haskell work, but I can't figure out at the
> moment why darcs fails in the middle of the build.
>
> [0]: http://bugs.darcs.net/issue2505
> [1]: https://gitlab.com/packaging-guix/guix-darcs (mirror)
> -- 
> ng0
> For non-prism friendly talk find me on http://www.psyced.org
>

I was told haskell users expect to use the latest version always.

https://gitlab.com/packaging-guix/guix-haskell8/commit/24262239da96eeabb0840c178ac6c80792e405c5
this is what I have now, still needs to be debugged.
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Tracking package submissions with Debbugs

[ng0]

> Who wants to take on this? Any volunteers?

On second note, my server is intentionally very minimal, so I have to
look at if gitlab will be fully functional (email etc).
-- 
ng0
For non-prism friendly talk find me on http://www.psyced.org

Re: Tracking package submissions with Debbugs

[David Craven]

> How would we proceed with this?

I think that someone needs to write a service for gitlab first, since
we probably want to deploy it using guixsd ;) Then probably Ludo will
take over this. To give this a fair shot it has to be at least as much
effort to revert to the old way of things as to continue with the new
system.

Re: Tracking package submissions with Debbugs

[Ben Woodcroft]

Hi ng0,

On 06/09/16 09:17, ng0 wrote:

Who wants to take on this? Any volunteers?

On second note, my server is intentionally very minimal, so I have to
look at if gitlab will be fully functional (email etc).


Did you have any success working with Kallithea? It seems on the face of 
it to be the most free-software and appropriate of the tools listed at 
the below Wikipedia link, but I don't have any experience with it.

https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities

ben

Re: Tracking package submissions with Debbugs

[Alex Vong]

Andreas Enge  writes:

> Hello,
>
> using debbugs corresponds to a suggestion I made a while ago, so I am
> obviously in favour of it...
>
> On Sun, Sep 04, 2016 at 10:37:02AM +0800, Alex Vong wrote:
>> > I think it would make sense to have the one bug report for the "target
>> > package" and then all the packages that get pulled in along the way get
>> > tacked on also.
>> Hmm, but what if we have 2 target packages (A, B) pulling the same
>> package (C) in? Then it is not obvious if C should live in A's or B's
>> bug report. What do you think?
>
> I do not quite understand the problem with relating bug reports to packages.
> The discussion sounds as if we considered one constantly open bug report per
> package, which is maybe a misunderstanding on my part. I would say that bug
> reports should correspond roughly to our current discussion threads on
> guix-devel: Someone sends in a patch or patch series, which opens a new bug
> (there seems to be the problem of git-sendmail still); there are replies back
> and forth; in the end the patch is applied (or, from time to time, retracted),
> and the bug is closed. In this way, we have an overview of pending patches
> and are less likely to forget one.
>
My original thought is to have a bug report per version, so people can
easily search for the packaging history for a particular version. But it
sounds like your idea is better than mine, having an overview of pending
patches is more important.

> As for the non-emacs users, I intend to work as before: Subscribe to all the
> bugs and have them end up in my mailbox, reply, and potentially close them
> by mail.
>
I think per-bug subsciption is not working right now[0]. Do you know of
any good alternatives?

> Andreas

[0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439

Re: [PATCH 07/43] gnu: Add ghc-haskeline.

[Eric Bavier]

On Sun,  4 Sep 2016 16:17:06 +
ng0  wrote:

> * gnu/packages/haskell.scm (ghc-haskeline): New variable.
> ---
>  gnu/packages/haskell.scm | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
> index f3d43c4..8c6aee0 100644
> --- a/gnu/packages/haskell.scm
> +++ b/gnu/packages/haskell.scm
> @@ -6558,4 +6558,29 @@ via bindings to the curses library.  Terminfo allows 
> POSIX systems
>  to interact with a variety of terminals using a standard set of 
> capabilities.")
>  (license license:bsd-3)))
>  
> +(define-public ghc-haskeline
> +  (package
> +(name "ghc-haskeline")
> +(version "0.7.2.3")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + "https://hackage.haskell.org/package/haskeline/haskeline-";
> + version ".tar.gz"))
> +   (sha256
> +(base32
> + "09wd6sxgn65xxpk7dhy1cg3ywlbk0ccqq7xylycwk4zazy3gjgkd"
> +(build-system haskell-build-system)
> +(inputs
> + `(("ghc-terminfo" ,ghc-terminfo)))
> +(home-page "https://github.com/judah/haskeline";)
> +(synopsis "A command-line interface for user input, written in Haskell.")
  ^
Could you run these packages through 'guix lint'?  It should warn about
the "A" at the beginning of a synopsis.

> +(description
> + "Haskeline provides a user interface for line input in command-line
> +programs.  This library is similar in purpose to readline, but since it
> +is written in Haskell it is (hopefully) more easily used in other Haskell
> +programs.")
> +(license license:bsd-3)))
> +
>  ;;; haskell.scm ends here

While adding ghc packages in the past, I've tried to keep the packages
alphabetically sorted.  I'm not sure whether there's concensus on doing
that.  We have 'guix edit', but for catch-all modules like (gnu
packages haskell) I think it's still nice to have some semblance of
order. We added a plea message at the top of gnu/packages/python.scm;
maybe we should add one to gnu/packages/haskell.scm.  What do others
think?

`~Eric

Re: State of maven build system, gradle and Apache commens

[Björn Höfling]

Hi Hartmut and Ricardo,

On Thu, 1 Sep 2016 14:03:10 +0200
Ricardo Wurmus  wrote:

> 
> Hartmut Goebel  writes:
> 
> > is anyone working on this? (I'm lacking knowledge to help with maven
> > or gradle, but could help with commons.)
> 
> We are still a long way off before get to a working maven build
> system. I have a few more Java packages sitting here, but it’s not
> much.
> 
> We first need to recursively package all dependencies of Maven.  The
> next packages on my list are “java-javax-mail” (done) and
> “java-log4j-core”, which needs the following packages:
> 
> javax-persistence
> javax-jms
> java-zeromq
> kafka
> apache-commons
> 
> These might have unpackaged dependencies of their own.  If you took
> over “apache-commons” that would be very helpful.  You should be able
> to use the “ant-build-system” to get started, even if it doesn’t
> result in the prettiest packages.
> 
> Once we actually have Maven packaged (completely from source without
> cheating) we should take a look at the existing packages again and see
> if we should install jars with a directory layout that Maven expects.
> Until then I wouldn’t bother trying to anticipate all these issues.

I'm interested in which version of maven do you start to create? Which
version(s) of the dependencies/plugins are you rebuilding?

Here is my experience so far: Last month I started looking at the maven
build-process too. I know that it wouldn't be that easy, but it's
harder than expected.

First, I asked on maven-devel [0], but I had the feeling they don't
understand the philosophy behind working with source dependencies
instead of binary ones.

Then I looked for myself at different versions of Maven and decided to
go with version 1.1 and bootstrap me up. But even this has hard and
funny dependencies:

For example, dom4j-1.7-20060614.jar has in it's META-INF written:
"*Note* that this is a custom-built version for the Maven project. It
was built from dom4j cvs trunk as of 2006-06-08 with the branch
DOM4J_1_X_BRANCH merged in."

OK, the branch is still there on SourceForge, but can I really be sure
to get the source code they used to build the jar-file? Or is that
ultimately lost in Java/Apache history?

Next, dom4j and others use forehead-1.0-beta-5.jar. The original
project is no longer there. Luckily I found a copy on a Gentoo mirror
[1].

Other dependencies, even relatively old ones need Maven in order to
compile (at least they use Maven originally, maybe it's possible to
build them with some Ant task too). That is the case for
commons-jelly/1.0.1-20060717, which by the way is again a patched
version ("*Note* that this is a custom-built version for the Maven
project. It was built from svn trunk as of 2006-07-17 (r 422982) but
with the fixes for JELLY-213 and JELLY-214 reverted").

How do you proceed? Do you have an issue raised where we can share
knowledge/coordinate next steps?

Björn


[0] https://www.mail-archive.com/dev@maven.apache.org/msg110304.html
(Post from Björn Höfling at Mon, 22 Aug 2016 23:26:10 -0700 on dev at
maven dot apache dot org)

[1] http://ftp.fi.debian.org/gentoo/distfiles/forehead-1.0_beta5.tbz2

[PATCH] gnu: Add mpop.

[Arun Isaac]

* gnu/packages/mail.scm (mpop): New variable.
---
 gnu/packages/mail.scm | 32 
 1 file changed, 32 insertions(+)

diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
index 3c29a95..e397c26 100644
--- a/gnu/packages/mail.scm
+++ b/gnu/packages/mail.scm
@@ -17,6 +17,7 @@
 ;;; Copyright © 2016 Troy Sankey 
 ;;; Copyright © 2016 ng0 
 ;;; Copyright © 2016 Clément Lassieur 
+;;; Copyright © 2016 Arun Isaac 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1356,3 +1357,34 @@ in Perl.")
  "Mb2md is a Perl script that takes one or more mbox format files and
 converts them to maildir format directories.")
 (license public-domain)))
+
+(define-public mpop
+  (package
+(name "mpop")
+(version "1.2.5")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "http://downloads.sourceforge.net/mpop/mpop-";
+  version ".tar.xz"))
+   (sha256
+   (base32
+"0n0ij258kn8lfa6nyr6l6plc4hf1wvyf1hkwicvdbjqdqrgjnq81"
+(build-system gnu-build-system)
+(inputs
+ `(("gnutls" ,gnutls)
+   ("libidn" ,libidn)))
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(arguments
+ `(#:configure-flags (list "--with-tls=gnutls")))
+(home-page "http://mpop.sourceforge.net/";)
+(synopsis "POP3 mail client")
+(description "mpop is a small and fast POP3 client suitable as a
+fetchmail replacement.
+
+mpop supports multiple accounts, header based mail filtering, delivery
+to mbox files, maildir folders or a Mail Delivery Agent (MDA),
+TLS/SSL, several authentication methods, Internationalized Domain
+Names (IDN) and SOCKS proxies.")
+(license gpl3+)))
-- 
2.10.0

Prototype for using Guix with python packages

[Christopher Baines]

For a few months now, I've been assembling a prototype for how packages
could be produced for software released as Python source distributions
(sdists) [1].

I wanted to build something that was as useful as any similar tool. The
functionality offered by pip [2] was something I looked at, as through
it you can use a large amount of software from the main PyPI [3],
including many different versions of the same project and use the
setuptools feature of extras [4] which allow for optional dependencies.

This differs from the functionality currently offered by the python
packages found in the Guix repository currently, as the number is much
smaller than available on PyPI, and typically only one release is available.

I've now managed to build a system which in a very automated way can
acquire sdists, determine there dependencies, use a full dependency
resolver to determine exactly what version of each dependency to use
across the entire build graph, and convert that graph in to Guix package
records, which can then be built.

Due to the wonderful power of Guix, this should be reasonably easy to
try out. I have imported a piece of software called sentry (as it was
something I was interested in using at the time) and all of its
dependencies in to the repository at [5]. You can find the instructions
here [5] for generating a package for sentry from this information.

My plan was to work towards something that could be run automatically to
stay up to date with a PyPI, so I tried to even automatically solve as
many issues as possible, e.g.  dependency looks, so if you look at the
build graph for sentry (attached, and the command to generate it is here
[5]), you should be able to see that the tests are run for setuptools,
something that is not even done for the package in the Guix repository.

I don't view this as a good long term approach, as I'm really hoping
that maybe one day, Guix could help to reduce the specific nature in
which software written in different languages is packaged/released. But
until that happens, I think something like this could be very useful at
getting some of the value that Guix provides quickly, without lots of
manual effort.

The code is very rough as I took a lot of shortcuts to get things
working, and I have lots of ideas for things I would like to change and
improve, but as I have been working on this for so long, I thought it
was time to publish it.

I will also try to look at how what I have been doing could be used to
improve the Guix PyPI importer and the Python build system, as well as
submit the packages that are currently just in the guix-env.scm file in
the repository (pyguile, libsolv) for inclusion in Guix.

I'm quite excited by the possibilities offered by approaches like this,
and was wondering if anyone has feedback, questions, opinions, or if
anyone is working on something similar?

Thanks,

Chris

1: https://docs.python.org/2/distutils/sourcedist.html
2: https://pypi.python.org/pypi/pip
3: https://pypi.python.org/pypi
4:
http://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies
5: http://git.cbaines.net/guix-python-integration-project/about/


sentry-graph.pdf
Description: Adobe PDF document


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] scripts: hash: Add --exclude-.git option.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

>> Added an -g/--exclude-.git option for guix hash.  It is very specific:
>> it skips toplevel .git directory.  WDYT?
>
> Good idea!

Thanks...

> What about --exclude-vcs/-x?  Tar uses that name, although with slightly
> different semantics (info "(tar) exclude").

Yes, I like this even better than my 2nd --exclude=FILE patch.

> Rather make the lambda a top-level procedure, like:
>
>   (define (vcs-file? file stat)
> (case (stat:type stat)
>   ((directory)
>(member (basename file) '(".git" ".svn" "CVS" …)))
>   (else
>#f)))

Nice!

> Could you send an updated patch?

Sure, attached.

> Thank you for making our lives easier!  :-)

:-)  Exactly, the mv .git ../dot-git ... drill was getting boring.

Greetings,
Jan

>From 060f9123acd4c6771e976c5442361285f8c8bc89 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen 
Date: Tue, 6 Sep 2016 08:28:33 +0200
Subject: [PATCH] scripts: hash: Add --exclude-vcs option.

* guix/scripts/hash.scm (show-help): Add help text for --exclude-vcs option.
(%options): Add --exclude-vcs option.
(guix-hash): Handle exclude-vcs option.
* doc/guix.texi ("Invoking guix hash"): Update doc.
* tests/guix-hash.sh: Add test.
---
 doc/guix.texi | 15 ++-
 guix/scripts/hash.scm | 25 -
 tests/guix-hash.sh| 16 
 3 files changed, 50 insertions(+), 6 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 5330238..68a0707 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4616,10 +4616,18 @@ The general syntax is:
 guix hash @var{option} @var{file}
 @end example
 
-@command{guix hash} has the following option:
+@command{guix hash} has the following options:
 
 @table @code
 
+@item --exclude-vcs
+@itemx -x
+Exclude version control system-directories (.bzr, .git, .hg, .svn, CVS)
+when computing a recursive hash, e.g.:
+@example
+$ guix hash -r -x .
+@end example
+
 @item --format=@var{fmt}
 @itemx -f @var{fmt}
 Write the hash in the format specified by @var{fmt}.
@@ -4655,6 +4663,11 @@ $ cd foo
 $ rm -rf .git
 $ guix hash -r .
 @end example
+@noindent
+or simply use the -x (--exclude-vcs) option
+@example
+$ guix hash -r -x .
+@end example
 @end table
 
 @node Invoking guix import
diff --git a/guix/scripts/hash.scm b/guix/scripts/hash.scm
index d440953..a57602a 100644
--- a/guix/scripts/hash.scm
+++ b/guix/scripts/hash.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014 Ludovic Courtès 
+;;; Copyright © 2012, 2013, 2014, 2016 Ludovic Courtès 
 ;;; Copyright © 2013 Nikita Karetnikov 
+;;; Copyright © 2016 Jan Nieuwenhuizen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -49,6 +50,8 @@ Return the cryptographic hash of FILE.
 Supported formats: 'nix-base32' (default), 'base32', and 'base16' ('hex'
 and 'hexadecimal' can be used as well).\n"))
   (format #t (_ "
+  -x, --exclude-vcs  exclude version control directories"))
+  (format #t (_ "
   -f, --format=FMT   write the hash in the given format"))
   (format #t (_ "
   -r, --recursivecompute the hash on FILE recursively"))
@@ -62,7 +65,10 @@ and 'hexadecimal' can be used as well).\n"))
 
 (define %options
   ;; Specification of the command-line options.
-  (list (option '(#\f "format") #t #f
+  (list (option '(#\x "exclude-vcs") #f #f
+(lambda (opt name arg result)
+  (alist-cons 'exclude-vcs? #t result)))
+(option '(#\f "format") #t #f
 (lambda (opt name arg result)
   (define fmt-proc
 (match arg
@@ -81,7 +87,6 @@ and 'hexadecimal' can be used as well).\n"))
 (option '(#\r "recursive") #f #f
 (lambda (opt name arg result)
   (alist-cons 'recursive? #t result)))
-
 (option '(#\h "help") #f #f
 (lambda args
   (show-help)
@@ -107,13 +112,23 @@ and 'hexadecimal' can be used as well).\n"))
   (alist-cons 'argument arg result))
 %default-options))
 
+  (define (vcs-file? file stat)
+(case (stat:type stat)
+  ((directory)
+   (member (basename file) '(".bzr" ".git" ".hg" ".svn" "CVS")))
+  (else
+   #f)))
+
   (let* ((opts (parse-options))
  (args (filter-map (match-lambda
 (('argument . value)
  value)
 (_ #f))
(reverse opts)))
- (fmt  (assq-ref opts 'format)))
+ (fmt  (assq-ref opts 'format))
+ (select? (if (assq-ref opts 'exclude-vcs?)
+  (negate vcs-file?)
+  (const #t
 
 (define (file-hash file)
   ;; Compute the hash of FILE.
@@ -121,7 +136,7 @@ and 'hexadecimal' can be used as well).\n"))
   (with-error-handling
 (if (assoc-ref opts 'recursive?)
 (let-values (((port get-hash) (open-sha256-port)))
-  (w