Re: 01/02: gnu: Add itpp.

[John Darrington]

On Mon, Mar 20, 2017 at 02:18:39AM -0400, Leo Famulari wrote:
 On Mon, Mar 20, 2017 at 07:03:03AM +0100, John Darrington wrote:
 >  > +(source (origin
 >  > +  (method url-fetch)
 >  > +  (uri (string-append 
"mirror://sourceforge/itpp/itpp/"
 >  > +  version "/itpp-"
 >  > +  version ".tar.gz"))
 >  > +   (sha256
 >  > +(base32
 >  > + 
"14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"
 
 (sha256) should be indented from (origin).

Ahh. You are right (of course).  Emacs must have missed that one - perhaps it'll
do a better job now I have the plugin installed.

J'



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



signature.asc
Description: Digital signature

Re: Being excellent to one another

[John Darrington]

On Sun, Mar 19, 2017 at 07:57:07PM -0700, dian_ce...@zoho.com wrote:
 On Sun, 19 Mar 2017 17:40:27 -0500
 Christopher Allan Webber  wrote:
 > The important thing is to not assume someone's preferred pronouns
 > without knowing them.  Singular they isn't your only option; I also
 > happen to like Spivak pronouns:
 > 
 >   https://en.wikipedia.org/wiki/Spivak_pronoun
 
 The problem here is that I'd be suprised if many people have even heard
 about these. I used to play MUDs quite a bit and have /never/ heard any
 of those. They are certainly not a part of common usage, and I'd say
 should be avoided for something more standard (them et al). It's a nice
 idea, but overall seems like it would cause confusion, and probably
 more than a few "Hey, there is a typo in the manual"-type bugs than
 anything.

 At least, if I picked up a random bit of documentation and saw things
 like "e" used constantly, I'd assume it was a typo and not some archaic
 gender-neutral pronoun.

I tend to agree.  These invented aspects of language are kindof fun for 
informal use but out of place in a user manual.In a manual we should
stick to proper English - put yourself in the position of a person who
is learning English as a second language.  That person has spent months
attending language school and is starting to become confident then picks
up a manual and sees the words "pis" and "per".  It's enough to throw you
off your stride. (I remember something similar happening to me when learning
a foriegn language: I started reading a novel, and there was lots of dialogue
all in regional dialect. I felt like giving up.)

Fortunately in a user manual one very rarely needs a personal *definite* 
pronoun.
In GNU manuals, the long standing practise is to refer to the person using the 
program, as "you".  Occasionally a personal *indefinite* pronoun is called for 
and
luckily in English we have a perfect gender neutral one, viz: "one".

Some authors religiously avoid the whole issue altogether by writing every 
sentence in the passive voice - but that makes the manual extremely hard to 
understand even for very patient readers.

When writing texts, such as this email, and absolutely  *have* to use a personal
definite pronoun, I default to "she" because whereas vigilantes will pounce upon
you whenever they see "he" (ironically those people are invariably male), I've 
never had anyone complain when "she" occurs where the gender of the subject 
might well be masculine.


... and yes.  If an individual specifically requests to be referred to by
a partcular set of pronouns I will attempt to do so, but may occasionally
forget if that person wants feminine pronouns and is 6'4" and has an enormous
black wiry beard.


J' 

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



signature.asc
Description: Digital signature

Re: 01/02: gnu: Add itpp.

[Leo Famulari]

On Mon, Mar 20, 2017 at 07:03:03AM +0100, John Darrington wrote:
>  > +(source (origin
>  > +  (method url-fetch)
>  > +  (uri (string-append "mirror://sourceforge/itpp/itpp/"
>  > +  version "/itpp-"
>  > +  version ".tar.gz"))
>  > +   (sha256
>  > +(base32
>  > + "14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"

(sha256) should be indented from (origin).


signature.asc
Description: PGP signature

Re: 01/02: gnu: Add itpp.

[John Darrington]

On Sun, Mar 19, 2017 at 04:46:07PM -0400, Mark H Weaver wrote:
 j...@darrington.wattle.id.au (John Darrington) writes:
 
 > jmd pushed a commit to branch master
 > in repository guix.
 >
 > commit a53d6719bc6b6b4afdc58e257ac712df316c8858
 > Author: John Darrington 
 > Date:   Tue Mar 7 07:51:51 2017 +0100
 >
 > gnu: Add itpp.
 > 
 > * gnu/packages/maths.scm (itpp): New variable.
 > ---
 >  gnu/packages/maths.scm | 30 +-
 >  1 file changed, 29 insertions(+), 1 deletion(-)
 >
 > diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
 > index adc8156..fe85983 100644
 > --- a/gnu/packages/maths.scm
 > +++ b/gnu/packages/maths.scm
 > @@ -1,7 +1,7 @@
 >  ;;; GNU Guix --- Functional package management for GNU
 >  ;;; Copyright ?? 2013, 2014, 2015, 2016 Andreas Enge 
 >  ;;; Copyright ?? 2013 Nikita Karetnikov 
 > -;;; Copyright ?? 2014, 2016 John Darrington 
 > +;;; Copyright ?? 2014, 2016, 2017 John Darrington 
 >  ;;; Copyright ?? 2014, 2015, 2016 Eric Bavier 
 >  ;;; Copyright ?? 2014 Federico Beffa 
 >  ;;; Copyright ?? 2014 Mathieu Lirzin 
 > @@ -761,6 +761,34 @@ Swath).")
 >  HDF5 file is encoded according to the HDF File Format Specification.")
 >  (license (license:x11-style "file://COPYING"
 >  
 > +(define-public itpp
 > +  (package
 > +(name "itpp")
 > +(version "4.3.1")
 > +(source (origin
 > +  (method url-fetch)
 > +  (uri (string-append "mirror://sourceforge/itpp/itpp/"
 > +  version "/itpp-"
 > +  version ".tar.gz"))
 > +   (sha256
 > +(base32
 > + "14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"
 
 Please be more careful with the indentation above.
 

Do you know - I've been looking carefully at the above for about a minute now, 
and 
I cannot see anything wrong with the indentation.   I'm not saying that there 
isn't
anything wrong - but I cannot see it despite close scrutiny.   So I must ask 
myself:
can we not be a little less strict about indentation?

Anyway Rekado has made me aware of emacs-guix and of etc/indent-code.el so 
maybe I'll
set up a git hook to use that.

J'
 

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



signature.asc
Description: Digital signature

Re: 01/01: gnu: Add niftilib.

[John Darrington]

On Sun, Mar 19, 2017 at 04:42:54PM -0400, Mark H Weaver wrote:
 j...@darrington.wattle.id.au (John Darrington) writes:
 
 > jmd pushed a commit to branch master
 > in repository guix.
 >
 > commit 21122bd79e7f9b0b5349e2c146bace7205dc
 > Author: John Darrington 
 > Date:   Tue Mar 7 07:59:21 2017 +0100
 >
 > gnu: Add niftilib.
 > 
 > * gnu/packages/image.scm (niftilib): New variable.
 
 Did you post this for review?  Please see below for comments.

Yes.  One person reviewed it before I pushed.   You are the second person to 
have reviewed it afterwards - making a total of three.So it would seem
that the best way to get one's patches reviewed is to push them!

Thanks for the comments anyway.
 


signature.asc
Description: Digital signature

Re: Being excellent to one another

[dian_cecht]

On Sun, 19 Mar 2017 17:40:27 -0500
Christopher Allan Webber  wrote:
> The important thing is to not assume someone's preferred pronouns
> without knowing them.  Singular they isn't your only option; I also
> happen to like Spivak pronouns:
> 
>   https://en.wikipedia.org/wiki/Spivak_pronoun

The problem here is that I'd be suprised if many people have even heard
about these. I used to play MUDs quite a bit and have /never/ heard any
of those. They are certainly not a part of common usage, and I'd say
should be avoided for something more standard (them et al). It's a nice
idea, but overall seems like it would cause confusion, and probably
more than a few "Hey, there is a typo in the manual"-type bugs than
anything.

At least, if I picked up a random bit of documentation and saw things
like "e" used constantly, I'd assume it was a typo and not some archaic
gender-neutral pronoun.

Re: Introducing ‘guix pack’

[Ludovic Courtès]

Hi Federico,

Federico Beffa  skribis:

> Say, developer A distributes such an archive A and developer B
> distributes archive B (a different program/library) and someone C
> installs both.

Interestingly composability (what happens when you unpack both A and B
on the same system) is better than what you’d get with Docker: the
unpacked items that are identical are shared, and those parts that
differ don’t collide.

> Now developer A fixes a security hole and produces a new archive.  How
> can C remove the library with the security hole from his system?  If he
> just overlays the new version, the library with the security problem
> stays on the system and could be exploited.  Deleting everything is also
> less than ideal.
>
> This seems to me similar to encouraging the much criticized practice of
> bundling required libraries with your program.
>
> Maybe 'pack' could at least include a 'remove-myself' thing.  Or have
> you thought about the hole program life-cycle?

Good question.  There’s a fine line here.  In Guix circles we’re very
good at explaining why “app bundles” are a bad thing (composability- and
security-wise notably), and here that’s precisely what we’re producing.

The intended use case is mostly “one-off” packs where you just want
people to easily test something, as opposed to putting it in
production.  This was the case for the Guile 2.2.0 release.  In those
cases, people would essentially “rm -rf /gnu” when they’re done.

For code that is meant to be kept over time, I would recommend to either
use Guix, or to include Guix in the pack so that people can eventually
upgrade.

Thoughts?

Ludo’.

Re: Being excellent to one another

[Christopher Allan Webber]

Ludovic Courtès writes:

> Hi there,
>
> Gentlefolks, please everyone calm down.  Being rude or insulting to
> fellow hackers is not acceptable on the project’s communication
> channels, period.  When you feel unable to express your disagreement in
> a constructive and respectful manner, please delay your reply until you
> can do that.

[...]

> Besides, while I appreciate it when native English speakers provide
> corrections and guidance, I think we as a project must tolerate English
> mistakes in our communication.  The reason for this is very simple: most
> contributors are not native English speakers.  English is our
> communication medium; it shouldn’t be a hindrance to the inclusion of
> contributors who do not master it.

About English though, I do agree with ng0 about they/them... as a
default pronoun, especially when you don't know.  It's good English,
with longstanding history:

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

The important thing is to not assume someone's preferred pronouns
without knowing them.  Singular they isn't your only option; I also
happen to like Spivak pronouns:

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

... which have the delightful connection to hacker culture in their
popularity with Lambdamoo, an oldschool MUD. :)  Singular they (or even
spivak) is also acceptable as a pronoun if someone chooses that.

Of course it's possible to make mistakes, but it *is* important to try
not to misgender people... both by not making assumptions, and
especially when using the right pronouns once you do know.  I have both
seen people break down into tears and also walk away from communities
from being misgendered.  That's an important sign of respect towards the
person...  and it doesn't cost you anything to do it.

Be excellent to each other indeed... and here's one critical way to do
it.

Re: [PATCH] gnu: Add pdfgrep.

[Leo Famulari]

On Sun, Mar 19, 2017 at 03:16:04PM -0600, ren...@openmailbox.org wrote:
> Subject: [PATCH] gnu: Add pdfgrep.
> 
> * guix/gnu/packages/pdf.scm (pdfgrep): New variable.

Thanks!

I corrected this typo ...

> +   ("popple" ,poppler)))

... and pushed as e05fc441cd5528ba6c83b6371c27c1e87dd393e9


signature.asc
Description: PGP signature

Re: Being excellent to one another

[Ludovic Courtès]

Hi,

 skribis:

> On Sat, 18 Mar 2017 14:43:20 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>> Besides, while I appreciate it when native English speakers provide
>> corrections and guidance, I think we as a project must tolerate
>> English mistakes in our communication.  The reason for this is very
>> simple: most contributors are not native English speakers.  English
>> is our communication medium; it shouldn’t be a hindrance to the
>> inclusion of contributors who do not master it.
>
> Are there any guidelines as to what parts of English one should avoid
> using in documentation? If most (as you put it) contributors aren't
> native English speakers, doesn't that mean we should attempt to use a
> simpler vocabulary so users and contributors can read and understand
> things easier?

I was referring mostly to informal communications among contributors.
For the manual, I think it makes sense to stick to “correct English”.
Ideally, we’d have translations of the manual, but we’re not there yet.

Ludo’.

[PATCH] gnu: Add pdfgrep.

[rennes]

Hello,
pdfgrep is an utility to search text in PDF files, similar to GNU grep.
Lint and tested.

GreetingsFrom 169cca9c4a40040b1997da4053112e2bcd38d1be Mon Sep 17 00:00:00 2001
From: rennes 
Date: Sun, 19 Mar 2017 15:02:00 -0600
Subject: [PATCH] gnu: Add pdfgrep.

* guix/gnu/packages/pdf.scm (pdfgrep): New variable.
---
 gnu/packages/pdf.scm | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/gnu/packages/pdf.scm b/gnu/packages/pdf.scm
index 873100cd7..7095a5abe 100644
--- a/gnu/packages/pdf.scm
+++ b/gnu/packages/pdf.scm
@@ -12,6 +12,7 @@
 ;;; Copyright © 2016 Arun Isaac 
 ;;; Copyright © 2017 Leo Famulari 
 ;;; Copyright © 2017 Alex Vong 
+;;; Copyright © 2017 Rene Saavedra 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -45,6 +46,7 @@
   #:use-module (gnu packages fontutils)
   #:use-module (gnu packages game-development)
   #:use-module (gnu packages ghostscript)
+  #:use-module (gnu packages gnupg)
   #:use-module (gnu packages databases)
   #:use-module (gnu packages djvu)
   #:use-module (gnu packages gettext)
@@ -888,3 +890,31 @@ This is much like @command{poster} does for Postscript files, but working with
 PDF.  Since sometimes @command{poster} does not like your files converted from
 PDF.  Indeed @command{pdfposter} was inspired by @command{poster}.")
 (license license:gpl3+)))
+
+(define-public pdfgrep
+  (package
+(name "pdfgrep")
+(version "2.0.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://pdfgrep.org/download/";
+   name "-" version ".tar.gz"))
+   (sha256
+(base32
+ "07llkrkcfjwd3ybai9ad10ybhr0biffcplmy7lw4fb87nd2dfw03"
+(build-system gnu-build-system)
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(inputs
+ `(("libgcrypt" ,libgcrypt)
+   ("pcre" ,pcre)
+   ("popple" ,poppler)))
+(home-page "https://pdfgrep.org";)
+(synopsis "Command-line utility to search text in PDF files")
+(description
+ "Pdfgrep searches in pdf files for strings matching a regular expression.
+Support some GNU grep options as file name output, page number output,
+optional case insensitivity, count occurrences, color highlights and search in
+multiple files.")
+(license license:gpl2+)))
-- 
2.12.0

Re: 01/01: gnu: Add niftilib.

[Kei Kebreau]

Mark H Weaver  writes:

> j...@darrington.wattle.id.au (John Darrington) writes:
>
>> jmd pushed a commit to branch master
>> in repository guix.
>>
>> commit 21122bd79e7f9b0b5349e2c146bace7205dc
>> Author: John Darrington 
>> Date:   Tue Mar 7 07:59:21 2017 +0100
>>
>> gnu: Add niftilib.
>> 
>> * gnu/packages/image.scm (niftilib): New variable.
>
> Did you post this for review?  Please see below for comments.
>

It was in fact posted for review. I reviewed it.

>> +(define-public niftilib
>> +  (package
>> +   (name "niftilib")
>> +   (version "2.0.0")
>> +   (source (origin
>> +(method url-fetch)
>> +(uri (list (string-append "mirror://sourceforge/niftilib/"
>> +  "nifticlib/nifticlib_"
>> + (string-join (string-split version #\.) "_")
>> +  "/nifticlib-" version ".tar.gz")))
>
> Omit the superfluous 'list' call above.
>

I missed this somehow.

>> +(sha256
>> + (base32 "123z9bwzgin5y8gi5ni8j217k7n683whjsvg0lrpii9flgk8isd3"
>> +   (build-system gnu-build-system)
>> +   (arguments
>> +'(#:tests? #f
>> +  #:parallel-build? #f
>> +  #:phases
>> +  (modify-phases %standard-phases
>> +(replace 'install
>
> Is there a reason not to use the included "make install" target?  It
> looks like it should work, if you pass appropriate settings for
> INSTALL_{BIN,LIB,INC}_DIR in #:make-flags.
>
>> + (lambda _
>> +   (for-each
>> +(lambda (dir)
>> +  (let ((directory (assoc-ref %outputs "out")))
>
> If you were going to keep the custom 'install' phase, then instead of
> using %outputs, please accept the 'outputs' keyword argument and use
> that.
>
>> +(mkdir-p (string-append directory "/" dir))
>> +(zero? (system* "cp" "-a" dir directory
>> +'("bin" "lib" "include"
>
> We have a 'copy-recursively' procedure that you could use here.  If you
> were going to use "cp", then you should pay attention to its result code
> so that failures are not silently ignored (by using 'every' instead of
> 'for-each').
>

This is interesting. Which module contains the definition for the
'every' procedure?

>> +(replace 'configure
>> + (lambda _
>> +   (substitute* "Makefile"
>> + (("^SHELL[ \t]*=[ \t]*csh")
>> +  (string-append "SHELL = "
>> + (assoc-ref %build-inputs "bash")
>> + "/bin/sh"))
>> +
>> + (("^CFLAGS[ \t]*=[ \t]\\$\\(ANSI_FLAGS\\)")
>> +  "CFLAGS = $(ANSI_FLAGS) -fPIC")
>> +
>> + (("^ZLIB_INC[ \t]*=[ \t]*-I/usr/include")
>> +  (string-append "ZLIB_INC = -I"
>> + (assoc-ref %build-inputs "zlib")
>> + "/include"))
>> +
>> + (("^CP[ \t]*=[ \t]*cp")
>> +  (string-append "CP = "
>> + (assoc-ref %build-inputs "coreutils")
>> + "/bin/cp")))
>
> Instead of patching the Makefile, it's preferable to simply pass these
> settings in #:make-flags.  Also, within phase procedures, please accept
> the 'inputs' and 'outputs' keyword arguments instead of using
> %build-inputs and %outputs.  Finally, for purposes of Makefile settings,
> SHELL can simply be set to "bash" or "sh", since it's in the PATH.  I'm
> not sure why you changed the setting for CP.
>
>   Mark

I should keep a closer eye on details like these. Thank you for the
second review.


signature.asc
Description: PGP signature

Re: 01/02: gnu: Add itpp.

[Mark H Weaver]

j...@darrington.wattle.id.au (John Darrington) writes:

> jmd pushed a commit to branch master
> in repository guix.
>
> commit a53d6719bc6b6b4afdc58e257ac712df316c8858
> Author: John Darrington 
> Date:   Tue Mar 7 07:51:51 2017 +0100
>
> gnu: Add itpp.
> 
> * gnu/packages/maths.scm (itpp): New variable.
> ---
>  gnu/packages/maths.scm | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
> index adc8156..fe85983 100644
> --- a/gnu/packages/maths.scm
> +++ b/gnu/packages/maths.scm
> @@ -1,7 +1,7 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2013, 2014, 2015, 2016 Andreas Enge 
>  ;;; Copyright © 2013 Nikita Karetnikov 
> -;;; Copyright © 2014, 2016 John Darrington 
> +;;; Copyright © 2014, 2016, 2017 John Darrington 
>  ;;; Copyright © 2014, 2015, 2016 Eric Bavier 
>  ;;; Copyright © 2014 Federico Beffa 
>  ;;; Copyright © 2014 Mathieu Lirzin 
> @@ -761,6 +761,34 @@ Swath).")
>  HDF5 file is encoded according to the HDF File Format Specification.")
>  (license (license:x11-style "file://COPYING"
>  
> +(define-public itpp
> +  (package
> +(name "itpp")
> +(version "4.3.1")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append "mirror://sourceforge/itpp/itpp/"
> +  version "/itpp-"
> +  version ".tar.gz"))
> +   (sha256
> +(base32
> + "14ddy2xnb6sgp4hiax9v5sv4pr4l4dd4ps76nfha3nrpr1ikhcqm"

Please be more careful with the indentation above.

  Mark

Re: 01/01: gnu: Add niftilib.

[Mark H Weaver]

j...@darrington.wattle.id.au (John Darrington) writes:

> jmd pushed a commit to branch master
> in repository guix.
>
> commit 21122bd79e7f9b0b5349e2c146bace7205dc
> Author: John Darrington 
> Date:   Tue Mar 7 07:59:21 2017 +0100
>
> gnu: Add niftilib.
> 
> * gnu/packages/image.scm (niftilib): New variable.

Did you post this for review?  Please see below for comments.

> +(define-public niftilib
> +  (package
> +   (name "niftilib")
> +   (version "2.0.0")
> +   (source (origin
> +(method url-fetch)
> +(uri (list (string-append "mirror://sourceforge/niftilib/"
> +  "nifticlib/nifticlib_"
> +  (string-join (string-split version 
> #\.) "_")
> +  "/nifticlib-" version ".tar.gz")))

Omit the superfluous 'list' call above.

> +(sha256
> + (base32 
> "123z9bwzgin5y8gi5ni8j217k7n683whjsvg0lrpii9flgk8isd3"
> +   (build-system gnu-build-system)
> +   (arguments
> +'(#:tests? #f
> +  #:parallel-build? #f
> +  #:phases
> +  (modify-phases %standard-phases
> +(replace 'install

Is there a reason not to use the included "make install" target?  It
looks like it should work, if you pass appropriate settings for
INSTALL_{BIN,LIB,INC}_DIR in #:make-flags.

> + (lambda _
> +   (for-each
> +(lambda (dir)
> +  (let ((directory (assoc-ref %outputs "out")))

If you were going to keep the custom 'install' phase, then instead of
using %outputs, please accept the 'outputs' keyword argument and use
that.

> +(mkdir-p (string-append directory "/" dir))
> +(zero? (system* "cp" "-a" dir directory
> +'("bin" "lib" "include"

We have a 'copy-recursively' procedure that you could use here.  If you
were going to use "cp", then you should pay attention to its result code
so that failures are not silently ignored (by using 'every' instead of
'for-each').

> +(replace 'configure
> + (lambda _
> +   (substitute* "Makefile"
> + (("^SHELL[ \t]*=[ \t]*csh")
> +  (string-append "SHELL = "
> + (assoc-ref %build-inputs "bash")
> + "/bin/sh"))
> +
> + (("^CFLAGS[ \t]*=[ \t]\\$\\(ANSI_FLAGS\\)")
> +  "CFLAGS = $(ANSI_FLAGS) -fPIC")
> +
> + (("^ZLIB_INC[ \t]*=[ \t]*-I/usr/include")
> +  (string-append "ZLIB_INC = -I"
> + (assoc-ref %build-inputs "zlib")
> + "/include"))
> +
> + (("^CP[ \t]*=[ \t]*cp")
> +  (string-append "CP = "
> + (assoc-ref %build-inputs "coreutils")
> + "/bin/cp")))

Instead of patching the Makefile, it's preferable to simply pass these
settings in #:make-flags.  Also, within phase procedures, please accept
the 'inputs' and 'outputs' keyword arguments instead of using
%build-inputs and %outputs.  Finally, for purposes of Makefile settings,
SHELL can simply be set to "bash" or "sh", since it's in the PATH.  I'm
not sure why you changed the setting for CP.

  Mark

License Question for language packs

[Hartmut Goebel]

Hi,

I'm about to package the 55 localization packages for KDE. The licence
for these files seems to be very complicated, as it may depend on the
copyright of the translated application. Debian's Copyright file [1] says:

License: The licence for translations is the same as that of the
application or library from which they come. The lowest common
denominator is GNU GPL 2 only. Many apps are under GNU GPL 2 or later
and libraries under GNU LGPL 2 or later. See the relevant application or
library for details.

The language packs include translations for different applications, so
stating each of them might become a) cumbersome and b) of less use.

Which license should I declare in the package?

[1]
http://metadata.ftp-master.debian.org/changelogs/main/k/kde-l10n/unstable_copyright

-- 
Regards
Hartmut Goebel

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

website translations

[ng0]

One thing I like about the template of https://taler.net is the usage of
javascript free translations of text (jinja2 is used), easy to select and write.

Actually that's the only reason why I favor it right now for my project
web site launch over the haunt + guile mix Guix itself uses.

I think translations of web sites are useful, necessary and important.
It would be good if this can be provided in the long run by the Guix web
site aswell.

Re: Introducing ‘guix pack’

[Federico Beffa]

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

> Hi!
>
> Andy Wingo  skribis:
>
>> On Tue 14 Mar 2017 14:42, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> If we remove /var/guix/profiles, users will have to actually type
>>> /gnu/store/asasdfadfgsadfa-profile/bin/guile.  This is not great, but I
>>> don’t know what else could be done.  We could profile a
>>> /bin/guile → /gnu/store/asasdfadfgsadfa-profile/bin/guile symlink, but
>>> perhaps that’s risky too.
>>
>> As we were discussing in the channel, maybe it's OK for these binary
>> installs to claim "/opt/gnu".  Then we expose the profile in /opt/gnu,
>> so you would run Guile as /opt/gnu/bin/guile.  Additionally you could
>> actually build against that Guile, which would be pretty neat.  If the
>> user untars multiple guix packs, /gnu/store easily absorbs the union,
>> and /opt/gnu will adjoin any new profile directories/files and replace
>> any overwritten links.
>>
>> We would have to make sure the union directory in /opt/gnu has all real
>> directories and only symlink files, as per the recent patch on
>> guix-devel.
>
> Commit 5895ec8aa234ec9a4ce68ab8f94e795807630168 takes a slightly
> different approach (it doesn’t use the union thing).
>
> You can run:
>
>   guix pack guile-next \
> --symlink=/opt/gnu/bin/guile=bin/guile \
> --symlink=/opt/gnu/bin/guild=bin/guild
>
> and that does what you would expect.
>
> In addition, /var/guix is no longer included by default.
>
> Let me know what you think!

Say, developer A distributes such an archive A and developer B
distributes archive B (a different program/library) and someone C
installs both.

Now developer A fixes a security hole and produces a new archive.  How
can C remove the library with the security hole from his system?  If he
just overlays the new version, the library with the security problem
stays on the system and could be exploited.  Deleting everything is also
less than ideal.

This seems to me similar to encouraging the much criticized practice of
bundling required libraries with your program.

Maybe 'pack' could at least include a 'remove-myself' thing.  Or have
you thought about the hole program life-cycle?

Fede

Re: [PATCH 4/4] services: openssh: Add 'subsystems' option.

[Clément Lassieur]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Clément,
>
> Clément Lassieur  skribis:
>
>> I think there is a misunderstanding.  I didn't want to push this because
>> it was not tested, and because subsystems are often useless without
>> Match, and Match is unsupported.  The pair/list thing is not the
>> problem.
>>
>> And I was waiting for ng0 to test, because he asked for this patch (see
>> http://lists.gnu.org/archive/html/guix-devel/2017-02/msg00906.html), so
>> I thought he was able to test.
>>
>> If ng0 still needs the patch and confirms that it works well, I'm
>> willing to update it.  Otherwise, let's drop it.
>
> The patch looks like a useful addition.  It would be sad to drop it, no?
>
> If you could add a test to (gnu tests ssh) that would be perfect, but
> otherwise it LGTM.  Perhaps the default value for ‘subsystems’ should
> include internal-sftp though, as users probably expect sftp to just work.

Yes, you are right.  I changed my mind :)  And the other distributions
I've seen have SFTP enabled as well.

So I updated the service, and I did a test:
http://lists.gnu.org/archive/html/guix-patches/2017-03/msg00546.html.

> I don’t have any issue with using two-element lists; I think the syntax
> for pairs can be a bit confusing for newcomers to it’s probably better
> to avoid it in service configuration.

Ok, I used two-element lists then.

Clément

Re: [PATCH 2/2] gnu: Add GNU Mach.

[rennes]

For GNU/Linux (core-updates) works, also works in Hurd.


It builds on i686-linux so I’ve added it to ‘supported-systems’ (as 
long

as we’re on one of the CPUs that Mach supports, that’s fine I guess.)


From 2128b50a0dda9e4e6dbad74f2706aee58f81708d Mon Sep 17 00:00:00 2001
From: rennes 
Date: Thu, 16 Mar 2017 09:29:55 -0600
Subject: [PATCH 2/2] gnu: Add GNU Mach.

* gnu/packages/hurd.scm (gnumach): New variable.

Co-authored-by: Rene Saavedra 


Committed with Manolis as the author (I think that’s what you intended
to do, right?).



Yeah that's right! Thanks

Re: Being excellent to one another

[John Darrington]

On Sun, Mar 19, 2017 at 08:47:17AM -0700, dian_ce...@zoho.com wrote:
 
 Are there any guidelines as to what parts of English one should avoid
 using in documentation? 
 

There are some such guidlines.  See: 
 https://www.gnu.org/prep/standards/standards.html#Documentation

   If most (as you put it) contributors aren't
 native English speakers, doesn't that mean we should attempt to use a
 simpler vocabulary so users and contributors can read and understand
 things easier?

I think that is a good general policy.

J'
 

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



signature.asc
Description: Digital signature

Re: Mass-packaging of 300 KDE application prepared - Help required

[John Darrington]

On Sun, Mar 19, 2017 at 05:00:55PM +0100, Ludovic Court??s wrote:

 Hi John,

 > So if there is going to be a joint effort at this I suggest that somehow 
we
 > decide in advance which packages are done by whom.
 >
 > I'm not sure how best to divide them up, since the lower dependencies 
will have
 > to be done first.
 
 I???m under the impression that it???s usually difficult to assign tasks to
 us lazy volunteers.  ;-)
 
 My guess is that people will incrementally pick the packages they???re
 interested in from Hartmut???s repo.
 
Ok.  I'm just suggesting that some kind of coordination is worthwhile.  
Otherwise 2 people
might pick the same package and then time and effort will be wasted through 
duplication.

J'


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



signature.asc
Description: Digital signature

Re: Using cross-compiler and host compiler in the same package

[Ludovic Courtès]

Hi Danny,

Sorry for the delay…

Danny Milosavljevic  skribis:

> I wanted to make sunxi-tools also compile the target tools.
>
> If one is on a non-armhf architecture some of the programs need to be 
> compiled with an armhf cross compiler and some (almost all) need to be 
> compiled using the host compiler.  Since the cross compiler is called 
> "arm-linux-gnueabihf-gcc" and not "gcc" (like the host compiler) that part is 
> no problem.  However, I also require armhf libc (to be linked statically) and 
> that doesn't work since one of the gccs always seems to pick up the wrong 
> libc.
>
> How can I fix it?

[...]

> (native-inputs
>  `(("pkg-config" ,pkg-config)
>("cross-gcc" ,(cross-gcc "arm-linux-gnueabihf"

‘cross-gcc’ takes an optional ‘libc’ argument.  Would it work to do:

  (let ((triplet "arm-linux-gnueabihf"))
(cross-gcc triplet (cross-binutils triplet) (cross-libc triplet)))

?

> (Also, if I try to put that into gnu/packages/admin.scm , I get some circular 
> module dependency problem again... sigh)

Hmm, not sure why this happens.

HTH,
Ludo’.

Re: guix is the guildhall that we always wanted!

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: wi...@pobox.com,  guix-devel@gnu.org,  guile-u...@gnu.org
> Date: Sun, 19 Mar 2017 16:57:22 +0100
> 
> > I'm saying that when cross-compiling, it's easy to produce binaries
> > that are unusable on Windows because Guile is not run natively during
> > the build, and so problems inherent to the Windows port are not
> > revealed during the build.
> 
> Right; that would be a bug in Guile’s build system.  Is pthread support
> detection broken when cross-compiling to MinGW?

Not sure what you are asking here.  I never cross-built Guile, I
always build the MinGW port natively.  And pthreads detection is not
broken, the build process correctly detects that I have pthreads
installed.  But if I want to produce a working Guile (or even get the
build to run to completion, since that involves running Guile to
compile Scheme files), I need to disable threads.

Re: [PATCH 2/2] gnu: Add GNU Mach.

[Ludovic Courtès]

Hi rennes,

ren...@openmailbox.org skribis:

>> +(synopsis "Microkernel of the GNU system")
>> +(description
>> + "GNU Mach is the microkernel upon which a GNU Hurd system is
>> based.")
>> +(license gpl2+)))
>
> Does it build both on GNU/Linux and GNU/Hurd?
>
> For GNU/Linux (core-updates) works, also works in Hurd.

It builds on i686-linux so I’ve added it to ‘supported-systems’ (as long
as we’re on one of the CPUs that Mach supports, that’s fine I guess.)

> From 2128b50a0dda9e4e6dbad74f2706aee58f81708d Mon Sep 17 00:00:00 2001
> From: rennes 
> Date: Thu, 16 Mar 2017 09:29:55 -0600
> Subject: [PATCH 2/2] gnu: Add GNU Mach.
>
> * gnu/packages/hurd.scm (gnumach): New variable.
>
> Co-authored-by: Rene Saavedra 

Committed with Manolis as the author (I think that’s what you intended
to do, right?).

Thanks!

Ludo’.

Re: Mass-packaging of 300 KDE application prepared - Help required

[Ludovic Courtès]

Hi John,

John Darrington  skribis:

> On Sat, Mar 18, 2017 at 03:13:25PM +0100, Ludovic Court??s wrote:
>  Hi Hartmut,
>  
>  Hartmut Goebel  skribis:
>  
>  > as promised earlier, I prepared a repository inclusing patches for more
>  > than 300 KDE packages. I will not have time to work on them, though.
>  > Others will need to implement the packages based on this preperations.
>  
>  [...]
>  
>  > The repository can be found at
>  > , detailed description on
>  > how to work with it is available ins the README there. If you have any
>  > enhancement requests, please let me know.
>  
>  Woow, impressive piece of work!
>  
>  Thomas Danckaert is visibly interested in KDE ;-), so either Thomas or
>  others will cherry-pick from your repo.
>  
> I suggest that 300 packages is too much for one person to do.

Yeah you’re right; I didn’t mean to suggest that Thomas would handle all
of them.

> So if there is going to be a joint effort at this I suggest that somehow we
> decide in advance which packages are done by whom.
>
> I'm not sure how best to divide them up, since the lower dependencies will 
> have
> to be done first.

I’m under the impression that it’s usually difficult to assign tasks to
us lazy volunteers.  ;-)

My guess is that people will incrementally pick the packages they’re
interested in from Hartmut’s repo.

We’ll see!

Ludo’.

Re: guix is the guildhall that we always wanted!

[Ludovic Courtès]

Eli Zaretskii  skribis:

>> From: l...@gnu.org (Ludovic Courtès)
>> Cc: wi...@pobox.com,  guix-devel@gnu.org,  guile-u...@gnu.org
>> Date: Sat, 18 Mar 2017 15:04:52 +0100
>> 
>> I think Andy was referring to the possibility of cross-compiling
>> packages that use Guile to MinGW.  That is already possible thanks to
>> the work of Jan Jan Nieuwenhuizen, and since yesterday, we can create
>> “packs” that contain binaries cross-compiled for MinGW:
>> 
>>   https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00525.html
>
> I'm saying that when cross-compiling, it's easy to produce binaries
> that are unusable on Windows because Guile is not run natively during
> the build, and so problems inherent to the Windows port are not
> revealed during the build.

Right; that would be a bug in Guile’s build system.  Is pthread support
detection broken when cross-compiling to MinGW?

Thanks,
Ludo’.

Re: Being excellent to one another

[dian_cecht]

On Sat, 18 Mar 2017 14:43:20 +0100
l...@gnu.org (Ludovic Courtès) wrote:
> Besides, while I appreciate it when native English speakers provide
> corrections and guidance, I think we as a project must tolerate
> English mistakes in our communication.  The reason for this is very
> simple: most contributors are not native English speakers.  English
> is our communication medium; it shouldn’t be a hindrance to the
> inclusion of contributors who do not master it.

Are there any guidelines as to what parts of English one should avoid
using in documentation? If most (as you put it) contributors aren't
native English speakers, doesn't that mean we should attempt to use a
simpler vocabulary so users and contributors can read and understand
things easier?

Re: Install hook

[pelzflorian (Florian Pelz)]

On 03/19/2017 02:14 PM, John Darrington wrote:
> The problem as I understand it is as follows:
> 
> Two (or more) packages both contain a file: /gnu/store/.../xyz/foo
> 
> So long as those two packages are not both installed into the same profile at
> the same time, this is not a problem.  However if the user chooses to 
> install both packages concurrently, then there is a potential conflict and
> Guix "resolves" this conflict by arbitrarily choosing the xyz/foo from one
> package or the other.
> 
> One could put a "hook" on package A which (through some method) says: "When
> this package (A) is installed, then the xyz/foo file from THIS package must
> be the one installed into the profile, and not any other one."
> 
> That will work fine so long as only package A has such a hook.  But what 
> happens if package B also contains an identical hook?   Both packages' hooks
> will then insist that their xyz/foo is the one which must be installed.
> 
> Nothing will have been solved.  There will still be a conflict, just shifted
> up a level.
> 
> 
> The issue as I see it is that neither file is the "right" one to install - 
> or to put it another way - BOTH are the right ones.
> 
> The solutions which I think have been discussed previously are:
> 
> 1.  Add an option to the "guix package --install" command to allow the user
> to specify which packages' files should take priority.
> 
> 2.  Use some kind of heuristic based on date installed and other info to
> guess which one is "right".
> 
> 3.  ... probably some other suggestions which I've probably forgotten.
> 
> 
> Also, I think we talked about consolidating the warning messages when these
> conflicts occur, so that a less overwhelming number of them are emitted.
> 
> J'
> 

No, normally gschemas.compiled is one file storing information about all
GSettings application. It must thus be created from files provided by
multiple packages.

For example, gnome-calculator ships

org.gnome.calculator.gschema.xml

and gnome-maps ships

org.gnome.Maps.gschema.xml

and from both source files a file gschemas.compiled needs to be created
when gnome-calculator and gnome-maps are installed to the same profile.
This single file then stores settings of both packages.



signature.asc
Description: OpenPGP digital signature

Re: Install hook

[John Darrington]

The problem as I understand it is as follows:

Two (or more) packages both contain a file: /gnu/store/.../xyz/foo

So long as those two packages are not both installed into the same profile at
the same time, this is not a problem.  However if the user chooses to 
install both packages concurrently, then there is a potential conflict and
Guix "resolves" this conflict by arbitrarily choosing the xyz/foo from one
package or the other.

One could put a "hook" on package A which (through some method) says: "When
this package (A) is installed, then the xyz/foo file from THIS package must
be the one installed into the profile, and not any other one."

That will work fine so long as only package A has such a hook.  But what 
happens if package B also contains an identical hook?   Both packages' hooks
will then insist that their xyz/foo is the one which must be installed.

Nothing will have been solved.  There will still be a conflict, just shifted
up a level.


The issue as I see it is that neither file is the "right" one to install - 
or to put it another way - BOTH are the right ones.

The solutions which I think have been discussed previously are:

1.  Add an option to the "guix package --install" command to allow the user
to specify which packages' files should take priority.

2.  Use some kind of heuristic based on date installed and other info to
guess which one is "right".

3.  ... probably some other suggestions which I've probably forgotten.


Also, I think we talked about consolidating the warning messages when these
conflicts occur, so that a less overwhelming number of them are emitted.

J'



On Sun, Mar 19, 2017 at 01:50:08PM +0100, pelzflorian (Florian Pelz) wrote:
 On 03/19/2017 01:14 PM, Julien Lepiller wrote:
 > I think install hooks are scripts run after each package installation,
 > that are provided by the package itself. We already have a similar
 > mechanism that takes place when building the user's profile. See
 > http://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm.
 > For instance, we build a icon-theme.cache cache file for every icon
 > theme in the user's profile.
 > 
 > I have seen references to gschemas.compiled in our
 > gtk-or-glib-build-system. Currently we build the file in each package,
 > which means that only one version will be present in the user's profile
 > if they install more that one package containing this file. I believe
 > gschemas.compiled contains important information about some graphical
 > packages, and in our current system, only one package can be referenced
 > that way.
 > 
 > I think we should make sure that this file is never present in the
 > output of a package, and add a function to build it in profiles.scm.
 > 
 > Does it make any sense?
 > 
 
 Yes, exactly. These profile hooks look similar to what I meant.
 
 

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



signature.asc
Description: Digital signature

Re: Install hook

[pelzflorian (Florian Pelz)]

On 03/19/2017 01:14 PM, Julien Lepiller wrote:
> I think install hooks are scripts run after each package installation,
> that are provided by the package itself. We already have a similar
> mechanism that takes place when building the user's profile. See
> http://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm.
> For instance, we build a icon-theme.cache cache file for every icon
> theme in the user's profile.
> 
> I have seen references to gschemas.compiled in our
> gtk-or-glib-build-system. Currently we build the file in each package,
> which means that only one version will be present in the user's profile
> if they install more that one package containing this file. I believe
> gschemas.compiled contains important information about some graphical
> packages, and in our current system, only one package can be referenced
> that way.
> 
> I think we should make sure that this file is never present in the
> output of a package, and add a function to build it in profiles.scm.
> 
> Does it make any sense?
> 

Yes, exactly. These profile hooks look similar to what I meant.

Re: Install hook

[Julien Lepiller]

I think install hooks are scripts run after each package installation,
that are provided by the package itself. We already have a similar
mechanism that takes place when building the user's profile. See
http://git.savannah.gnu.org/cgit/guix.git/tree/guix/profiles.scm.
For instance, we build a icon-theme.cache cache file for every icon
theme in the user's profile.

I have seen references to gschemas.compiled in our
gtk-or-glib-build-system. Currently we build the file in each package,
which means that only one version will be present in the user's profile
if they install more that one package containing this file. I believe
gschemas.compiled contains important information about some graphical
packages, and in our current system, only one package can be referenced
that way.

I think we should make sure that this file is never present in the
output of a package, and add a function to build it in profiles.scm.

Does it make any sense?

On Sun, 19 Mar 2017 12:23:39 +0100
John Darrington  wrote:

> I agree that this is a problem.  It has been discussed before, and
> various solutions have been suggested, but I don't think install
> hooks was one of them.
> 
> Can you elaborate on your idea?  What would an install hook do, and
> how would it work?

Re: Introducing ‘guix pack’

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> And now you can do:
>
>   guix pack grep --target=i686-w64-mingw32
>
> or:
>
>   guix pack guile@2.0 --target=arm-linux-gnueabihf -f docker

...exactly what has been missing: awesome, thanks!

> Granted, this is not optimal space-wise because cross-compiled binaries
> end up pulling the whole cross toolchain (due to cross-gcc not having a
> separate “lib” output), so for instance the cross-built grep tarball
> above weighs in at 91 MiB (330 MiB uncompressed :-)).  We’ll fix that.

:-)  Oh well.

> Anyway, pretty cool!

Pretty cool!
Greetings,
janneke

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

Re: Install hook

[John Darrington]

Hello Florian,

I agree that this is a problem.  It has been discussed before, and various 
solutions have been suggested, but I don't think install hooks was one of
them.

Can you elaborate on your idea?  What would an install hook do, and how would
it work?

J'


On Sun, Mar 19, 2017 at 11:30:48AM +0100, Florian Pelz wrote:
 Hello,
 
 Currently my ~/.guix-profile/share/glib-2.0/schemas/gschemas.compiled
 file contains only GSettings from one package. Guix warns about
 ???arbitrarily choosing??? this file when installing a package. This is
 bad; gschemas.compiled should be recreated on package install to
 include all GSettings stored in the Guix profile.
 
 Arch Linux uses hooks to compile GSettings schemas after installing a
 package.
 
 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/glib-compile-schemas.hook?h=packages/glib2
 
 Am I correct in that Guix does not support install hooks? I believe
 install hooks are the proper way to solve this. This affects more
 than just GSettings.
 
 Regards,
 Florian
 

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



signature.asc
Description: Digital signature

Install hook

[Florian Pelz]

Hello,

Currently my ~/.guix-profile/share/glib-2.0/schemas/gschemas.compiled
file contains only GSettings from one package. Guix warns about
“arbitrarily choosing” this file when installing a package. This is
bad; gschemas.compiled should be recreated on package install to
include all GSettings stored in the Guix profile.

Arch Linux uses hooks to compile GSettings schemas after installing a
package.

https://git.archlinux.org/svntogit/packages.git/tree/trunk/glib-compile-schemas.hook?h=packages/glib2

Am I correct in that Guix does not support install hooks? I believe
install hooks are the proper way to solve this. This affects more
than just GSettings.

Regards,
Florian