Re: propagating inputs in ghc-* packages

[Ricardo Wurmus]

Federico Beffa  writes:

> Ricardo Wurmus  writes:
>
>> Hi Guix,
>>
>> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
>> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
>>
>> I noticed that upgrading Haskell packages is a pain in the neck because
>> of propagated inputs.  It seems that not all packages have fully
>> declared dependencies and just work accidentally because of propagated
>> inputs of a related package.  This also makes upgrades more difficult
>> because I can get substitutes from Hydra that depend on older versions
>> of some Haskell packages.
>>
>> It looks like Haskell binaries actually embed references to other
>> Haskell packages, so I’m not sure we actually need to propagate anything
>> at all.  Could someone please confirm this?
>
> From what I recall, binary executables include references to packages,
> but libraries do not.  So, at least at the time I wrote the first
> version of the haskell-build-system, propagated inputs seemed to be
> necessary for packages providing libraries, but not for ones providing
> applications.

Thanks for this comment.  With Eric Bavier’s patch this seems no longer
necessary.  I’ve already rebuilt a lot of Haskell packages without any
propagation (and some added inputs), and I’ve got working libraries and
executables.  I’m still rebuilding remaining Haskell packages but I’m
now convinced that propagation is no longer needed with the current
version of the build system.

I’m preparing a patch to remove propagation from all Haskell packages.
Now the question is only whether to do this all in one patch or in one
patch per package… :)

~~ Ricardo

Re: propagating inputs in ghc-* packages

[Federico Beffa]

>> Ricardo Wurmus  writes:
>>
>>> Hi Guix,
>>>
>>> I’m in the middle of upgrading our Haskell packages.  (Actually, I’m
>>> just yak shaving.  I need “pandoc-citeproc” for “r-knitr”…)
>>>
>>> I noticed that upgrading Haskell packages is a pain in the neck because
>>> of propagated inputs.  It seems that not all packages have fully
>>> declared dependencies and just work accidentally because of propagated
>>> inputs of a related package.  This also makes upgrades more difficult
>>> because I can get substitutes from Hydra that depend on older versions
>>> of some Haskell packages.
>>>
>>> It looks like Haskell binaries actually embed references to other
>>> Haskell packages, so I’m not sure we actually need to propagate anything
>>> at all.  Could someone please confirm this?
>>
>> From what I recall, binary executables include references to packages,
>> but libraries do not.  So, at least at the time I wrote the first
>> version of the haskell-build-system, propagated inputs seemed to be
>> necessary for packages providing libraries, but not for ones providing
>> applications.
>
> Thanks for this comment.  With Eric Bavier’s patch this seems no longer
> necessary.  I’ve already rebuilt a lot of Haskell packages without any
> propagation (and some added inputs), and I’ve got working libraries and
> executables.  I’m still rebuilding remaining Haskell packages but I’m
> now convinced that propagation is no longer needed with the current
> version of the build system.
>
> I’m preparing a patch to remove propagation from all Haskell packages.
> Now the question is only whether to do this all in one patch or in one
> patch per package… :)

That sounds great! Just to be sure: you are saying that if you install
any library (call it A) and the GHC compiler into your profile then you
are able to compile your program (making use of library A) without
also having to manually install any input of library A?

Regards,
Fede

question about license of unofficial translation of GPL as a sample text in dbacl (Re: notmuch users: how do you filter debbugs?)

[ng0]

ng0  writes:

> Hi,
>
> "Patricia J. Hawkins"  writes:
>
>> I'm just getting started setting up to use notmuch (your message
>> attracted my attention to it!) but looks like the afew script is
>> designed to do this, as a companion processer ("initial tagging") for
>> notmuch.
>>
>> https://github.com/teythoon/afew
>
> I actually have that as a work in progress package, but I can no longer
> work on it.. if I really do have it, there might be further dependencies
> which are needed or a massive amount of tests which need to be patched.
> Are you interested in taking this over?

I just checked out the repository and branch I had on this, I was
failing at the test suite of dbacl which is used by afew as a
dependency.
Fixing it after not looking at it for half a year is easy. It will be
even easier when this qestion can be solved:

all sample texts have declared licenses, I delete "sample6.txt" (license
unknown, forwarded email) and "japanese.txt" (unofficial translation of
GPL). For japanese.txt I'm not sure which copyright form applies.. same
for this unclear document sample6, deleting was just to be on the safe
side.

Let me quote myself:

509;; The software is licensed as GPLv3 or later, but 
510;; includes various sample texts in the doc dir:   
511;; - sample1.txt, sample3 and sampe5.txt are in the public domain, 
512;;   by Mark Twain.
513;; - sample2.txt, sample4.txt are in the public domain, by Aristotle.  
514;; - sample6.txt is a forwarded email, copyright unknown.  
515;;   Guix does exclude sample6.txt.
516;; - japanese.txt is a Japanese unoffical translation of the   
517;;   GNU General Public License, (c) by the Free Software Foundation.  
518;;   XXX: uncertain of license to apply. Left out for now. 
519(license '(license:gpl-3 license:public-domain  
-- 

Re: question about license of unofficial translation of GPL as a sample text in dbacl (Re: notmuch users: how do you filter debbugs?)

[John Darrington]

The GPL itself is not Free (!)

It's license is: 

 "Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed."

PLUS some extra permissions regarding translation which are 
given at https://www.gnu.org/licenses/translations.html

Note that these extra permissions come with a number of conditions,
including:

 "The translation is not hosted on a commercial site."

So this means that if the package includes japanse.txt nobody can
make a commercial version of our hydra repository.  I think this
would be a restriction which we don't want to impose.  Hence, I 
thing the decision to remove japanese.txt is correct.

J'



On Sat, Oct 01, 2016 at 09:21:41AM +, ng0 wrote:
 ng0  writes:
 
 > Hi,
 >
 > "Patricia J. Hawkins"  writes:
 >
 >> I'm just getting started setting up to use notmuch (your message
 >> attracted my attention to it!) but looks like the afew script is
 >> designed to do this, as a companion processer ("initial tagging") for
 >> notmuch.
 >>
 >> https://github.com/teythoon/afew
 >
 > I actually have that as a work in progress package, but I can no longer
 > work on it.. if I really do have it, there might be further dependencies
 > which are needed or a massive amount of tests which need to be patched.
 > Are you interested in taking this over?
 
 I just checked out the repository and branch I had on this, I was
 failing at the test suite of dbacl which is used by afew as a
 dependency.
 Fixing it after not looking at it for half a year is easy. It will be
 even easier when this qestion can be solved:
 
 all sample texts have declared licenses, I delete "sample6.txt" (license
 unknown, forwarded email) and "japanese.txt" (unofficial translation of
 GPL). For japanese.txt I'm not sure which copyright form applies.. same
 for this unclear document sample6, deleting was just to be on the safe
 side.
 
 Let me quote myself:
 
 509;; The software is licensed as GPLv3 or later, but  
   
 510;; includes various sample texts in the doc dir:
   
 511;; - sample1.txt, sample3 and sampe5.txt are in the public domain,  
   
 512;;   by Mark Twain. 
   
 513;; - sample2.txt, sample4.txt are in the public domain, by 
Aristotle.  
 514;; - sample6.txt is a forwarded email, copyright unknown.   
   
 515;;   Guix does exclude sample6.txt. 
   
 516;; - japanese.txt is a Japanese unoffical translation of the
   
 517;;   GNU General Public License, (c) by the Free Software 
Foundation.  
 518;;   XXX: uncertain of license to apply. Left out for now.  
   
 519(license '(license:gpl-3 license:public-domain  
 -- 

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

CPU-specific builds

[Ben Woodcroft]

Hi,

Currently, we build a single set of x86_64 packages assuming SSE but not 
SSE2 instructions, but sometimes it would be nice to use more recent 
instructions like AVX. So I'm wondering if there is some way to specify 
a system more specific than 'X86_64'? I tried simply adding 
'--with-arch=haswell' as a configure argument in gcc-4.9 so that flag 
became the default for gcc usage and saw some performance improvements, 
though I did have to disable tests in gnutls.


Hardcoding that configure flag is definitely less than ideal, I'm 
wondering if there is some better way that would enable us to share 
package updates and even substitutes for these systems? My initial 
thought is extending the triplet 'x86_64-unknown-linux-gnu' somehow, but 
I suspect others have better ideas?


Thanks, ben.

Re: [PATCH] guix: gnu-build-system: add new phase patch-dot-desktop-files

[Ludovic Courtès]

John Darrington  skribis:

> From: John Darrington 
>
>
> New patch as requested.
>
>
>
>
> * guix/build/gnu-build-system.scm (patch-dot-desktop-files): New procedure.

I pushed a modified version of this patch as
d31860b9de07810e114490db5cc160a8b078c58d, essentially making it more
concise and adding ‘format’ statements so people have some information
in their build log.

Thanks!

Ludo’.

Re: Boostrap tar cannot exec xz

[Ludovic Courtès]

Hi!

csanchez...@gmail.com (Carlos Sánchez de La Lama) skribis:

>> In ‘raw-build’ in bootstrap.scm, we run:
>>
>>   xz -dc thing.tar.xz | tar xv
>
> If I have understood correctly the code, raw-build is only used for
> %bootstrap-guile. However, the problem arises when building make (I do
> not have access to that machine righg now, so I am unsure of the exact
> package). i guess one option would be to create bootstrap versions of
> all packages on which tar depends (most probably already exist) and use
> xz | tar on them, until the requirements for a new non-bootstrap tar
> build can be met.

The question is how ‘tar’ in the ‘bootstrap-binaries’ we use on other
arches differs from the one you just built.

--8<---cut here---start->8---
$ guix build bootstrap-binaries --fallback
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0
ludo@pluto ~/src/guix$ 
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar 
--version
tar (GNU tar) 1.27
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
$ strings 
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar |grep 
bin/sh
/bin/sh
$ touch foo.tar.xz
$ strace -e execve -f 
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar xf 
foo.tar.xz
execve("/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar",
 ["/gnu/store/zh914iy23h97fwskh12vl"..., "xf", "foo.tar.xz"], [/* 63 vars */]) 
= 0
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: This 
does not look like a tar archive
Process 28766 attached
[pid 28766] execve("/home/ludo/.guix-profile/bin/xz", ["xz", "-d"], [/* 63 vars 
*/]) = 0
xz: (stdin): File format not recognized
[pid 28766] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=28766, si_status=1, 
si_utime=0, si_stime=0} ---
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: Child 
returned status 1
/gnu/store/zh914iy23h97fwskh12vl3py1frkhrqn-bootstrap-binaries-0/bin/tar: Error 
is not recoverable: exiting now
+++ exited with 2 +++
--8<---cut here---end--->8---

So apparently, tar 1.27 did not execute xz via /bin/sh, but current tar
does not either:

--8<---cut here---start->8---
$ strace -e execve -f tar xf ~/src/guix/foo.tar.gz 
execve("/run/current-system/profile/bin/tar", ["tar", "xf", 
"/home/ludo/src/guix/foo.tar.gz"], [/* 63 vars */]) = 0
Process 29347 attached
[pid 29347] execve("/home/ludo/soft/bin/gzip", ["gzip", "-d"], [/* 63 vars */]) 
= -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.opam/system/bin/gzip", ["gzip", "-d"], [/* 63 
vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.guix-profile/bin/gzip", ["gzip", "-d"], [/* 63 
vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/home/ludo/.guix-profile/sbin/gzip", ["gzip", "-d"], [/* 63 
vars */]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/run/setuid-programs/gzip", ["gzip", "-d"], [/* 63 vars 
*/]) = -1 ENOENT (No such file or directory)
[pid 29347] execve("/run/current-system/profile/bin/gzip", ["gzip", "-d"], [/* 
63 vars */]) = 0
[pid 29347] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29347, si_status=0, 
si_utime=0, si_stime=0} ---
+++ exited with 0 +++
$ tar --version
tar (GNU tar) 1.29
Copyright (C) 2015 Free Software Foundation, Inc.
Permeso GPLv3+: GNU GPL versio 3 aŭ posta .
Tio ĉi estas libera programaro: vi estas libera por ŝanĝi kaj redisdoni ĝin.
Ekzistas NENIU GARANTIO, laŭ plej amplekse permesate de la leĝoj.

Verkita de John Gilmore kaj Jay Fenlason.
--8<---cut here---end--->8---

Could you check exactly what’s going on and send more details?

> Another option that just csme to my mind is replacing all the nuked
> store referenced in the static binaries with references to the unpacked
> store path after extraction. As the nuked references can be easily
> identified by the "ee..." fake path, this should be doable.

That’s not doable because we don’t know the hash in advance.

Thanks,
Ludo’.

Re: kdesu security update needed

[Ludovic Courtès]

Leo Famulari  skribis:

> On Thu, Sep 29, 2016 at 08:52:34PM +0200, David Craven wrote:
>> Ah just checked our linter doesn't flag a CVE, so I think we're ok...
>
> The linter is a good tool for catching things that we miss, but it's not
> a substitute for manual investigation :)

+1

> First, our package's name might not match the name used by the Common
> Platform Enumeration [0], which is the name that the linter looks up. We
> can give packages a cpe-name property [1], which tells the linter to use
> something besides the package's name.
>
> Second, I've noticed that sometimes bugs are publicized on oss-sec or
> elsewhere, but then they don't show up in the CVE database for a while.

Often, vulnerabilities and CVE IDs are publicized when the CVE ID is
still marked as “reserved” without additional info; reserved CVE IDs
don’t show up in the CVE database that ‘guix lint’ fetches.

> An aside, the CVE linter gives false positives for grafted packages. For
> example, try `guix lint -c cve openssl@1.0`.

That’s been annoying me for some time so I’d like to see if we can
improve grafting in a way that would allow us to use a different version
number in the package replacement, which in turn would allow ‘guix lint’
to see the right version number of the replacement.

Ludo’.

Re: libgd security CVE-2016-7568

[Ludovic Courtès]

Leo Famulari  skribis:

> This patches fixes an integer overflow in libgd:
>
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7568
> http://seclists.org/oss-sec/2016/q3/639
>
> From b125d20c4e60cfd204a99fd7df174de73df067a2 Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Thu, 29 Sep 2016 11:32:34 -0400
> Subject: [PATCH] gnu: gd: Fix CVE-2016-7568.
>
> * gnu/packages/patches/gd-CVE-2016-7568.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/gd.scm (gd)[source]: Use it.

LGTM, thanks!

Ludo'.

[PATCH 1/2] gnu: Add gsound.

[rennes]

Hello,
this patch is gsound library required for gnome-clocks application.

Built and linted.

Thank youFrom 1d8368a12295c223626a3638d45e50a2043b980c Mon Sep 17 00:00:00 2001
From: Rene Saavedra 
Date: Sat, 1 Oct 2016 07:17:34 -0500
Subject: [PATCH 1/2] gnu: Add gsound.

	* gnu/packages/gsound.scm (gsound): New variable.
	
---
 gnu/packages/gsound.scm | 53 +
 1 file changed, 53 insertions(+)
 create mode 100644 gnu/packages/gsound.scm

diff --git a/gnu/packages/gsound.scm b/gnu/packages/gsound.scm
new file mode 100644
index 000..6894bbe
--- /dev/null
+++ b/gnu/packages/gsound.scm
@@ -0,0 +1,53 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Rene Saavedra 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages gsound)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix build-system gnu)
+  #:use-module (guix download)
+  #:use-module (guix packages)
+  #:use-module (guix utils)
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages libcanberra)
+  #:use-module (gnu packages pkg-config))
+
+(define-public gsound
+  (package
+(name "gsound")
+(version "1.0.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "mirror://gnome/sources/" name "/"
+   (version-major+minor version) "/"
+   name "-" version ".tar.xz"))
+   (sha256
+(base32
+ "0lwfwx2c99qrp08pfaj59pks5dphsnxjgrxyadz065d8xqqgza5v"
+(build-system gnu-build-system)
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(inputs
+ `(("glib" ,glib) ; for gio-2.0.
+   ("libcanberra" ,libcanberra)))
+(home-page "https://wiki.gnome.org/Projects/GSound";)
+(synopsis "Small library for playing system sounds")
+(description
+ "Designed to be used via GObject Introspection,
+and is a thin wrapper around the libcanberra C library.")
+(license license:lgpl2.1)))
-- 
2.10.0

[PATCH 2/2] gnu: Add gnome-clocks.

[rennes]

Hello,
this patch is gnome-clocks application.

Built, linted and tested.

Thank youFrom fd784203294523120f09312ffe9699a4983e6156 Mon Sep 17 00:00:00 2001
From: Rene Saavedra 
Date: Sat, 1 Oct 2016 07:22:39 -0500
Subject: [PATCH 2/2] gnu: Add gnome-clocks.

	* gnu/packages/gnome-clocks.scm (gnome-clocks): New variable.

---
 gnu/packages/gnome-clocks.scm | 62 +++
 1 file changed, 62 insertions(+)
 create mode 100644 gnu/packages/gnome-clocks.scm

diff --git a/gnu/packages/gnome-clocks.scm b/gnu/packages/gnome-clocks.scm
new file mode 100644
index 000..5da4f76
--- /dev/null
+++ b/gnu/packages/gnome-clocks.scm
@@ -0,0 +1,62 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Rene Saavedra 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages gnome-clocks)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix build-system gnu)
+  #:use-module (guix download)
+  #:use-module (guix packages)
+  #:use-module (guix utils)
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages gnome)
+  #:use-module (gnu packages gsound)
+  #:use-module (gnu packages gtk)
+  #:use-module (gnu packages pkg-config))
+
+(define-public gnome-clocks
+  (package
+(name "gnome-clocks")
+(version "3.20.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "mirror://gnome/sources/" name "/"
+   (version-major+minor version) "/"
+   name "-" version ".tar.xz"))
+   (sha256
+(base32
+ "05rnf4r9mn8zfwypalm6rkm34dri02cqaavp933wwclnxc3i5c3x"
+(build-system gnu-build-system)
+(native-inputs
+ `(("glib" ,glib "bin") ; for glib-compile-schemas.
+   ("intltool" ,intltool)
+   ("itstool" ,itstool)
+   ("pkg-config" ,pkg-config)))
+(inputs
+ `(("geoclue" ,geoclue)
+   ("geocode-glib" ,geocode-glib)
+   ("gnome-desktop" ,gnome-desktop)
+   ("gsound" ,gsound)
+   ("gtk+" ,gtk+)
+   ("libgweather" ,libgweather)))
+(home-page "https://wiki.gnome.org/Apps/Clocks";)
+(synopsis "Clocks applications for GNOME")
+(description
+ "Simple clock application for GNOME.  It includes world clocks,
+alarms, a stopwatch and a timer.")
+(license license:gpl2)))
-- 
2.10.0

Re: question about license of unofficial translation of GPL as a sample text in dbacl (Re: notmuch users: how do you filter debbugs?)

[Adonay Felipe Nogueira]

If I'm not mistaken, translations of the GNU GPL are not legally binding
if they are presented by themselves.

One must note that when the translation text is preceded by a section
written in the license's original language that instructs the reader to
take the original one as valid, then the project does become under that
license.

Distinction must also be made between the license and its notice below
copyright notice. As far as my limited knowledge goes, the license
notice of the GNU GPL can be translated.

However, translating license notices for other licenses that don't
implement short notices is risky because you would be translating the
license itself.

Examples of licenses that allow short license notices: Almost all
licenses from the GNU project, Apache License.

After the license notice, of course, the project can take the time and
space to write more elaborated text on what are the rights and
obligations of the user, as long as the writer warns that this
explanation isn't legally binding too, and that the reader must read the
original license to know more.


signature.asc
Description: This is a digitally signed message part

Re: kdesu security update needed

[David Craven]

Thank you for the info @Leo and @Ludo, just noticed that it's
mentioned in the manual.

One question that wasn't answered yet in your description and the
manual is how the linter detects when a package is patched. I assume
it looks at the applied patch names see if they contain a CVE code?

Re: question about license of unofficial translation of GPL as a sample text in dbacl (Re: notmuch users: how do you filter debbugs?)

[Adonay Felipe Nogueira]

I **guess** that restriction on modifying the GPL was made because of
the problem of license proliferation that could arise from translations
not accepted as such (that is: not accepted as translations).


signature.asc
Description: This is a digitally signed message part

Re: question about license of unofficial translation of GPL as a sample text in dbacl (Re: notmuch users: how do you filter debbugs?)

[ng0]

Adonay Felipe Nogueira  writes:

> [ Unknown signature status ]
> If I'm not mistaken, translations of the GNU GPL are not legally binding
> if they are presented by themselves.
>
> One must note that when the translation text is preceded by a section
> written in the license's original language that instructs the reader to
> take the original one as valid, then the project does become under that
> license.
>
> Distinction must also be made between the license and its notice below
> copyright notice. As far as my limited knowledge goes, the license
> notice of the GNU GPL can be translated.
>
> However, translating license notices for other licenses that don't
> implement short notices is risky because you would be translating the
> license itself.
>
> Examples of licenses that allow short license notices: Almost all
> licenses from the GNU project, Apache License.
>
> After the license notice, of course, the project can take the time and
> space to write more elaborated text on what are the rights and
> obligations of the user, as long as the writer warns that this
> explanation isn't legally binding too, and that the reader must read the
> original license to know more.

Does this even apply when the license serves as a sample text?
The source we are talking about:
http://dbacl.sourceforge.net/ | https://github.com/krig/dbacl
https://github.com/krig/dbacl/blob/master/doc/japanese.txt (might not
represent what I have in the tarball)
and sample6 I deleted is this one:
https://github.com/krig/dbacl/blob/master/doc/sample6.txt
-- 

Re: [PATCH 2/2] gnu: perl: Enable threading support.

[Ludovic Courtès]

Hi Ben,

Ben Woodcroft  skribis:

> From c61c799da21f349c739f9d094d348ae429a91ffc Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft 
> Date: Sat, 24 Sep 2016 22:44:55 +1000
> Subject: [PATCH 1/2] gnu: perl: Use configure-flags.
>
> * gnu/packages/perl.scm (perl)[arguments]: Use configure-flags.

[...]

> From d382e48d801406897c27b045ab1feb20cfec6db4 Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft 
> Date: Sat, 24 Sep 2016 23:22:54 +1000
> Subject: [PATCH 2/2] gnu: perl: Enable threading support.
>
> * gnu/packages/perl.scm (perl)[arguments]: Configure with '-Dusethreads'.
> * gnu/packages/commencement.scm (perl-boot0)[arguments]: Omit inherited
> '-Dusethreads' flag during configure.

I pushed simplified versions of these two patches as
56ee1d2015e9b2c55d34f19c70b06eefe8a20c76 and
156c0810e936413ac554e2883343b3b40695cfdc.

I think this was the last non-bug-fix change for this core-updates
cycle.  :-)

Thanks!

Ludo’.

Re: question about license of unofficial translation of GPL as a sample text in dbacl (Re: notmuch users: how do you filter debbugs?)

[ng0]

John Darrington  writes:

> [ Unknown signature status ]
> The GPL itself is not Free (!)
>
> It's license is: 
>
>  "Everyone is permitted to copy and distribute verbatim copies
>   of this license document, but changing it is not allowed."
>
> PLUS some extra permissions regarding translation which are 
> given at https://www.gnu.org/licenses/translations.html
>
> Note that these extra permissions come with a number of conditions,
> including:
>
>  "The translation is not hosted on a commercial site."
>
> So this means that if the package includes japanse.txt nobody can
> make a commercial version of our hydra repository.  I think this
> would be a restriction which we don't want to impose.  Hence, I 
> thing the decision to remove japanese.txt is correct.

Okay, I agree with this.
I don#t know how much is expected (from the test suite), but couldn't we
just delete the content and replace it with

# original sample text removed by Guix due to legal problems
こんにちは世界

or something like that, hopefully double checked by someone who actually
knows the language - for me it's been a 'todo' for years now :/

That would still enable the test to parse some text.

> J'
>
>
>
> On Sat, Oct 01, 2016 at 09:21:41AM +, ng0 wrote:
>  ng0  writes:
>  
>  > Hi,
>  >
>  > "Patricia J. Hawkins"  writes:
>  >
>  >> I'm just getting started setting up to use notmuch (your message
>  >> attracted my attention to it!) but looks like the afew script is
>  >> designed to do this, as a companion processer ("initial tagging") for
>  >> notmuch.
>  >>
>  >> https://github.com/teythoon/afew
>  >
>  > I actually have that as a work in progress package, but I can no longer
>  > work on it.. if I really do have it, there might be further 
> dependencies
>  > which are needed or a massive amount of tests which need to be patched.
>  > Are you interested in taking this over?
>  
>  I just checked out the repository and branch I had on this, I was
>  failing at the test suite of dbacl which is used by afew as a
>  dependency.
>  Fixing it after not looking at it for half a year is easy. It will be
>  even easier when this qestion can be solved:
>  
>  all sample texts have declared licenses, I delete "sample6.txt" (license
>  unknown, forwarded email) and "japanese.txt" (unofficial translation of
>  GPL). For japanese.txt I'm not sure which copyright form applies.. same
>  for this unclear document sample6, deleting was just to be on the safe
>  side.
>  
>  Let me quote myself:
>  
>  509;; The software is licensed as GPLv3 or later, but
>  
>  510;; includes various sample texts in the doc dir:  
>  
>  511;; - sample1.txt, sample3 and sampe5.txt are in the public 
> domain, 
>  512;;   by Mark Twain.   
>  
>  513;; - sample2.txt, sample4.txt are in the public domain, by 
> Aristotle.  
>  514;; - sample6.txt is a forwarded email, copyright unknown. 
>  
>  515;;   Guix does exclude sample6.txt.   
>  
>  516;; - japanese.txt is a Japanese unoffical translation of the  
>  
>  517;;   GNU General Public License, (c) by the Free Software 
> Foundation.  
>  518;;   XXX: uncertain of license to apply. Left out for now.
>  
>  519(license '(license:gpl-3 license:public-domain  
>  -- 
>
> -- 
> 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.
>

-- 

Re: [PATCH 0/2] Add quickswitch for i3 (third try)

[Ivan Vilata i Balaguer]

宋文武 (2016-10-01 10:59:14 +0800) wrote:

> Ivan Vilata i Balaguer  writes:
> 
> > Ivan Vilata i Balaguer (2016-09-21 11:18:47 +0200) wrote:
> >
> >> Hi, this is my third try at packaging [quickswitch][] for the i3
> >> window manager. […]
> >> 
> >> [quickswitch]: https://github.com/proxypoke/quickswitch-for-i3/
> >> 
> >> Thanks to Brendan Tildesley, Leo Famulari, Hartmut Goebel and Alex
> >> Kost for testing, advice and patience!
> >
> > Hi, a week has passed without any input about these.  Do you think
> > the patches are ok now?  (The ones from Sep 21st, sorry but signing
> > the first message with Mutt broke the mail thread).
> 
> Applied (with adding a copyright header for you), thanks!

Cool, thank you very much for the merge and the missing changes!`:)`

-- 
Ivan Vilata i Balaguer -- https://elvil.net/

[PATCH 1/2] gnu: Do not propagate inputs in haskell.scm.

[Ricardo Wurmus]

* gnu/packages/haskell.scm
(ghc-streaming-commons)[propagated-inputs]: Move ghc-random...
[inputs]: ...to here; remove ghc-async, add ghc-directory, add
ghc-transformers; move ghc-quickcheck, ghc-hspec...
[native-inputs]: ...to here; add hspec-discover.

(ghc-test-framework)[propagated-inputs]: Move all from here...
[inputs]: ...to here; move ghc-hunit and ghc-quickcheck...
[native-inputs]: ...to here.

(ghc-attoparsec)[propagated-inputs]: Move ghc-scientific...
[inputs]: ...to here; move ghc-quickcheck, ghc-quickcheck-unicode,
ghc-test-framework, ghc-test-framework-quickcheck2, ghc-vector...
[native-inputs]: ...to here.

(ghc-zip-archive)[propagated-inputs]: Move all inputs from here...
[inputs]: ...to here; move ghc-hunit from here...
[native-inputs]: ...to here.

(ghc-network-uri)[inputs]: Add ghc-parsec; move ghc-hunit from here...
[native-inputs]: ...to here.
[propagated-inputs]: Remove.

(ghc-wai)[propagated-inputs]: Move all inputs from here...
[inputs]: ...to here; move ghc-quickcheck, ghc-hunit, and ghc-hspec from
here...
[native-inputs]: ...to here.  Add hspec-discover.

(ghc-wai-extra)[propagated-inputs]: Remove ghc-hspec and ghc-hunit; move
all other inputs from here...
[inputs]: ...to here.
[native-inputs]: Add hspec-discover, ghc-hspec, and ghc-hunit.

(ghc-resourcet, ghc-xss-sanitize, ghc-parsec, ghc-vector, ghc-http,
ghc-base-compat, ghc-base-orphans, ghc-word8)[inputs]: Move all inputs
from here...
[native-inputs]: ...to here.

(ghc-haddock-library, ghc-hspec-contrib, ghc-base-compat,
ghc-base-orphans, ghc-fast-logger, ghc-word8, ghc-aeson-qq,
ghc-logging-facade, ghc-mockery, ghc-yaml, ghc-hslua)[native-inputs]:
Add hspec-discover.

(ghc-fast-logger)[inputs]: Move ghc-hspec from here...
[native-inputs]: ...to here.

(ghc-data-default,
ghc-data-default-instances-base,
ghc-data-default-instances-containers,
ghc-data-default-instances-dlist,
ghc-haddock-api,
ghc-happy,
ghc-haskell-src-exts,
ghc-resourcet,
ghc-xss-sanitize,
ghc-sdl-mixer,
ghc-sdl-image,
ghc-glut,
ghc-gluraw,
ghc-opengl,
cpphs,
ghc-old-time,
ghc-data-default-instances-old-locale,
cabal-install,
ghc-x11,
ghc-x11-xft,
ghc-hashable,
ghc-test-framework-hunit,
ghc-test-framework,
ghc-tf-random,
ghc-transformers-base,
ghc-unix-time,
ghc-http-types,
ghc-iproute,
ghc-regex-base,
ghc-regex-posix,
ghc-regex-tdfa-rc,
ghc-parsers,
ghc-trifecta,
ghc-distributive,
ghc-comonad,
ghc-polyparse,
ghc-profunctors,
ghc-reducers,
ghc-xml,
ghc-exceptions,
ghc-temporary,
ghc-temporary-rc,
ghc-smallcheck,
ghc-tasty-ant-xml,
ghc-quickcheck-instances,
ghc-quickcheck,
ghc-case-insensitive,
ghc-chasingbottoms,
ghc-unordererd-containers,
ghc-uniplate,
ghc-ansi-wl-pprint,
ghc-parsec,
ghc-vector,
ghc-vector-binary-instances,
ghc-http,
ghc-hspec,
ghc-hspec-contrib,
ghc-hspec-core,
ghc-hspec-meta,
ghc-vault,
ghc-monad-control,
ghc-blaze-builder,
ghc-blaze-markup,
ghc-blaze-html,
ghc-async,
ghc-optparse-applicative,
ghc-charset,
ghc-void,
ghc-kan-extensions,
ghc-statevar,
ghc-lens,
ghc-cheapskate,
ghc-semigroupoids,
ghc-contrvariant,
ghc-semigroups,
ghc-free,
ghc-adjunctions,
ghc-fast-logger,
ghc-doctest,
ghc-lifted-base,
ghc-tasty-quickcheck,
ghc-tasty-golden,
ghc-tasty,
ghc-cookie,
ghc-scientific,
ghc-aeson,
ghc-wai-logger,
ghc-pandoc-types,
ghc-texmath,
ghc-regex-pcre-builtin,
ghc-highlighting-kate,
ghc-cmark,
ghc-enclosed-exceptions,
ghc-th-lift,
ghc-th-expand-syns,
ghc-th-reify-many,
ghc-th-orphans,
ghc-haskell-src-meta,
ghc-aeson-qq,
ghc-conduit,
ghc-mockery,
ghc-yaml,
ghc-filemanip,
ghc-juicypixels,
ghc-hslua,
ghc-mime-types,
ghc-http-client,
ghc-hourglass,
ghc-pem,
ghc-asn1-types,
ghc-asn1-encoding,
ghc-asn1-parse,
ghc-tasty-kat,
ghc-cryptonite,
ghc-x509,
ghc-x509-store,
ghc-x509-validation,
ghc-x509-system,
ghc-tls,
ghc-socks,
ghc-connection,
ghc-http-client-tls,
ghc-pandoc)[propagated-inputs]: Move inputs from here...
[inputs]: ...to here.
---
 gnu/packages/haskell.scm | 543 ++-
 1 file changed, 257 insertions(+), 286 deletions(-)

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index 3bd3e14..d79dfd6 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -342,7 +342,7 @@ reduce @code{UndecidableInstances}.")
(sha256
 (base32 "0d1hm0l9kim3kszshr4msmgzizrzha48gz2kb7b61p7n3gs70m7c"
 (build-system haskell-build-system)
-(propagated-inputs
+(inputs
  `(("ghc-data-default-class"
 ,ghc-data-default-class)
("ghc-data-default-instances-base"
@@ -394,7 +394,7 @@ packages.")
(sha256
 (base32 "1832nq6by91f1iw73ycvkbgn8kpra83pvf2q61hy47xffh0zy4pb"
 (build-system haskell-build-system)
-(propagated-inputs
+(inputs
  `(("ghc-data-default-class" ,ghc-data-default-class)))
 (home-page 
"https://hackage.haskell.org/package/data-default-instances-base";)
 (synopsis "Default instances for types in base")
@@ -417,7 +417,7 @@ package.")
(sha256
 (base32 "06h8xka031w752a7cjlzghvr8adqbl95x

[PATCH 2/2] gnu: ghc-process: Replace reference to /bin/sh.

[Ricardo Wurmus]

* gnu/packages/haskell.scm (ghc-process)[arguments]: Add phases
"patch-reference-to-/bin/sh" to replace reference to /bin/sh.
---
 gnu/packages/haskell.scm | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index d79dfd6..cf17c4f 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -6918,6 +6918,7 @@ supported.  A module of colour names 
(\"Data.Colour.Names\") is provided.")
 files and directories in a portable way.")
 (license license:bsd-3)))
 
+;; Do not use this as an input.  It is part of GHC.
 (define-public ghc-process
   (package
 (name "ghc-process")
@@ -6932,6 +6933,14 @@ files and directories in a portable way.")
 (base32
  "1v1bav5isqxq9fc4lw714x94qbfsjbm2nn12kjp69r1ql8jaaaqw"
 (build-system haskell-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'patch-reference-to-/bin/sh
+   (lambda _
+ (substitute* "System/Process/Posix.hs"
+   (("/bin/sh") (which "sh")))
+ #t)
 (home-page "http://hackage.haskell.org/package/process";)
 (synopsis "System process libraries")
 (description
-- 
2.10.0

Re: libgd security CVE-2016-7568

[Leo Famulari]

On Sat, Oct 01, 2016 at 02:20:35PM +0200, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > This patches fixes an integer overflow in libgd:
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7568
> > http://seclists.org/oss-sec/2016/q3/639
> >
> > From b125d20c4e60cfd204a99fd7df174de73df067a2 Mon Sep 17 00:00:00 2001
> > From: Leo Famulari 
> > Date: Thu, 29 Sep 2016 11:32:34 -0400
> > Subject: [PATCH] gnu: gd: Fix CVE-2016-7568.
> >
> > * gnu/packages/patches/gd-CVE-2016-7568.patch: New file.
> > * gnu/local.mk (dist_patch_DATA): Add it.
> > * gnu/packages/gd.scm (gd)[source]: Use it.
> 
> LGTM, thanks!

Pushed!

Re: propagating inputs in ghc-* packages

[Leo Famulari]

On Sat, Oct 01, 2016 at 09:45:21AM +0200, Ricardo Wurmus wrote:
> I’m preparing a patch to remove propagation from all Haskell packages.
> Now the question is only whether to do this all in one patch or in one
> patch per package… :)

I'd say whichever method is easiest :) And then we can test it with
Hydra on a ghc-updates branch.

Re: kdesu security update needed

[Leo Famulari]

On Sat, Oct 01, 2016 at 02:19:05PM +0200, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> > An aside, the CVE linter gives false positives for grafted packages. For
> > example, try `guix lint -c cve openssl@1.0`.
> 
> That’s been annoying me for some time so I’d like to see if we can
> improve grafting in a way that would allow us to use a different version
> number in the package replacement, which in turn would allow ‘guix lint’
> to see the right version number of the replacement.

That would be nice. The current situation (with misleading package
versions) is a huge improvement over what we had before, but I think
that users should not need to understand the implementation details of
grafting to determine the version of packages.

I always figured this quirky limitation was a side-effect of rushing to
implement recursive grafting before OpenSSL 1.0.2g was released.

Core-updates timeline (was: Re: [PATCH 2/2] gnu: perl: Enable threading support.)

[Leo Famulari]

On Sat, Oct 01, 2016 at 03:22:36PM +0200, Ludovic Courtès wrote:
> I pushed simplified versions of these two patches as
> 56ee1d2015e9b2c55d34f19c70b06eefe8a20c76 and
> 156c0810e936413ac554e2883343b3b40695cfdc.
> 
> I think this was the last non-bug-fix change for this core-updates
> cycle.  :-)

Cool :)

I've been waiting for libarchive 3.2.2 [0] so that I can graft it on
master and ungraft it on core-updates. But, I can try cherry-picking the
most important changes today. When do you hope to freeze core-updates?
Do you want me to try cherry-picking?

https://github.com/libarchive/libarchive/milestone/4

[PATCH 1/2] gnu: Do not propagate inputs in haskell.scm.

[Federico Beffa]

Ricardo Wurmus  writes:

> * gnu/packages/haskell.scm
> (ghc-streaming-commons)[propagated-inputs]: Move ghc-random...
> [inputs]: ...to here; remove ghc-async, add ghc-directory, add
> ghc-transformers; move ghc-quickcheck, ghc-hspec...
> [native-inputs]: ...to here; add hspec-discover.
>
> (ghc-test-framework)[propagated-inputs]: Move all from here...
> [inputs]: ...to here; move ghc-hunit and ghc-quickcheck...
> [native-inputs]: ...to here.
>
> (ghc-attoparsec)[propagated-inputs]: Move ghc-scientific...
> [inputs]: ...to here; move ghc-quickcheck, ghc-quickcheck-unicode,
> ghc-test-framework, ghc-test-framework-quickcheck2, ghc-vector...
> [native-inputs]: ...to here.
>
> (ghc-zip-archive)[propagated-inputs]: Move all inputs from here...
> [inputs]: ...to here; move ghc-hunit from here...
> [native-inputs]: ...to here.
>
> (ghc-network-uri)[inputs]: Add ghc-parsec; move ghc-hunit from here...
> [native-inputs]: ...to here.
> [propagated-inputs]: Remove.
>
> (ghc-wai)[propagated-inputs]: Move all inputs from here...
> [inputs]: ...to here; move ghc-quickcheck, ghc-hunit, and ghc-hspec from
> here...
> [native-inputs]: ...to here.  Add hspec-discover.
>
> (ghc-wai-extra)[propagated-inputs]: Remove ghc-hspec and ghc-hunit; move
> all other inputs from here...
> [inputs]: ...to here.
> [native-inputs]: Add hspec-discover, ghc-hspec, and ghc-hunit.
>
> (ghc-resourcet, ghc-xss-sanitize, ghc-parsec, ghc-vector, ghc-http,
> ghc-base-compat, ghc-base-orphans, ghc-word8)[inputs]: Move all inputs
> from here...
> [native-inputs]: ...to here.
>
> (ghc-haddock-library, ghc-hspec-contrib, ghc-base-compat,
> ghc-base-orphans, ghc-fast-logger, ghc-word8, ghc-aeson-qq,
> ghc-logging-facade, ghc-mockery, ghc-yaml, ghc-hslua)[native-inputs]:
> Add hspec-discover.
>
> (ghc-fast-logger)[inputs]: Move ghc-hspec from here...
> [native-inputs]: ...to here.
>
> (ghc-data-default,
> ghc-data-default-instances-base,
> ghc-data-default-instances-containers,
> ghc-data-default-instances-dlist,
> ghc-haddock-api,
> ghc-happy,
> ghc-haskell-src-exts,
> ghc-resourcet,
> ghc-xss-sanitize,
> ghc-sdl-mixer,
> ghc-sdl-image,
> ghc-glut,
> ghc-gluraw,
> ghc-opengl,
> cpphs,
> ghc-old-time,
> ghc-data-default-instances-old-locale,
> cabal-install,
> ghc-x11,
> ghc-x11-xft,
> ghc-hashable,
> ghc-test-framework-hunit,
> ghc-test-framework,
> ghc-tf-random,
> ghc-transformers-base,
> ghc-unix-time,
> ghc-http-types,
> ghc-iproute,
> ghc-regex-base,
> ghc-regex-posix,
> ghc-regex-tdfa-rc,
> ghc-parsers,
> ghc-trifecta,
> ghc-distributive,
> ghc-comonad,
> ghc-polyparse,
> ghc-profunctors,
> ghc-reducers,
> ghc-xml,
> ghc-exceptions,
> ghc-temporary,
> ghc-temporary-rc,
> ghc-smallcheck,
> ghc-tasty-ant-xml,
> ghc-quickcheck-instances,
> ghc-quickcheck,
> ghc-case-insensitive,
> ghc-chasingbottoms,
> ghc-unordererd-containers,
> ghc-uniplate,
> ghc-ansi-wl-pprint,
> ghc-parsec,
> ghc-vector,
> ghc-vector-binary-instances,
> ghc-http,
> ghc-hspec,
> ghc-hspec-contrib,
> ghc-hspec-core,
> ghc-hspec-meta,
> ghc-vault,
> ghc-monad-control,
> ghc-blaze-builder,
> ghc-blaze-markup,
> ghc-blaze-html,
> ghc-async,
> ghc-optparse-applicative,
> ghc-charset,
> ghc-void,
> ghc-kan-extensions,
> ghc-statevar,
> ghc-lens,
> ghc-cheapskate,
> ghc-semigroupoids,
> ghc-contrvariant,
> ghc-semigroups,
> ghc-free,
> ghc-adjunctions,
> ghc-fast-logger,
> ghc-doctest,
> ghc-lifted-base,
> ghc-tasty-quickcheck,
> ghc-tasty-golden,
> ghc-tasty,
> ghc-cookie,
> ghc-scientific,
> ghc-aeson,
> ghc-wai-logger,
> ghc-pandoc-types,
> ghc-texmath,
> ghc-regex-pcre-builtin,
> ghc-highlighting-kate,
> ghc-cmark,
> ghc-enclosed-exceptions,
> ghc-th-lift,
> ghc-th-expand-syns,
> ghc-th-reify-many,
> ghc-th-orphans,
> ghc-haskell-src-meta,
> ghc-aeson-qq,
> ghc-conduit,
> ghc-mockery,
> ghc-yaml,
> ghc-filemanip,
> ghc-juicypixels,
> ghc-hslua,
> ghc-mime-types,
> ghc-http-client,
> ghc-hourglass,
> ghc-pem,
> ghc-asn1-types,
> ghc-asn1-encoding,
> ghc-asn1-parse,
> ghc-tasty-kat,
> ghc-cryptonite,
> ghc-x509,
> ghc-x509-store,
> ghc-x509-validation,
> ghc-x509-system,
> ghc-tls,
> ghc-socks,
> ghc-connection,
> ghc-http-client-tls,
> ghc-pandoc)[propagated-inputs]: Move inputs from here...
> [inputs]: ...to here.
> ---
>  gnu/packages/haskell.scm | 543 
> ++-
>  1 file changed, 257 insertions(+), 286 deletions(-)
>
> diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
> index 3bd3e14..d79dfd6 100644
> --- a/gnu/packages/haskell.scm
> +++ b/gnu/packages/haskell.scm
> @@ -342,7 +342,7 @@ reduce @code{UndecidableInstances}.")
> (sha256
>  (base32 "0d1hm0l9kim3kszshr4msmgzizrzha48gz2kb7b61p7n3gs70m7c"
>  (build-system haskell-build-system)
> -(propagated-inputs
> +(inputs
>   `(("ghc-data-default-class"
>  ,ghc-data-default-class)
> ("ghc-data-default-instances-base"
> @@ -394,7 +394,7 @@ packages.")
> (sha256
>  (base32 "1832nq6by91f1iw73ycvkbgn8kpra83pvf2q6

[PATCH] Add Vc

[Leo Famulari]

This is a depend of Krita.
From 808b47b3b7a9d769f3a6a873d19a0051f64720f7 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Fri, 30 Sep 2016 13:38:20 -0400
Subject: [PATCH] gnu: Add Vc.

* gnu/packages/maths.scm (vc): New variable.
---
 gnu/packages/maths.scm | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 0401cd3..c033123 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -2629,3 +2629,37 @@ the same amount of space as the original point 
representation.  This is useful
 when using the Gilbert curve as a space filling curve through a
 high-dimensional space where not all demensions have the same cardinality.")
 (license license:lgpl2.1+)))
+
+(define-public vc
+  (package
+(name "vc")
+(version "1.2.0")
+(source
+  (origin (method url-fetch)
+  (uri (string-append "https://github.com/VcDevel/Vc/releases/";
+  "download/" version "/Vc-" version 
".tar.gz"))
+  (sha256
+   (base32
+"1rh6dhqar3y07n4xqyml0sa0v48qv3ch9dc3yc2in855hlh4vnqi"
+(build-system cmake-build-system)
+(arguments
+ '(#:configure-flags
+   '("-DBUILD_TESTING=ON"))) ; Is this the test suite we want?
+(synopsis "SIMD Vector Classes for C++ ")
+(description "Vc provides portable, zero-overhead C++ types for explicitly
+data-parallel programming.  It is a library designed to ease explicit
+vectorization of C++ code.  Its types enable explicitly stating data-parallel
+operations on multiple values. The parallelism is therefore added via the type
+system.  Vc has an intuitive API and provides portability between different
+compilers and compiler versions as well as portability between different vector
+instruction sets. Thus, an application written with Vc can be compiled for:
+@enumerate
+@item AVX and AVX2
+@item SSE2 upto SSE4.2 or SSE4a
+@item Scalar
+@item MIC
+@item NEON (in development)
+@item NVIDIA GPUs / CUDA (in development)
+@end enumerate\n")
+(home-page "https://github.com/VcDevel";)
+(license license:bsd-3)))
-- 
2.10.0



signature.asc
Description: PGP signature

Re: [PATCH] Add Vc

[Leo Famulari]

On Sat, Oct 01, 2016 at 06:24:12PM -0400, Leo Famulari wrote:
> This is a depend of Krita.

... dependency

> From 808b47b3b7a9d769f3a6a873d19a0051f64720f7 Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Fri, 30 Sep 2016 13:38:20 -0400
> Subject: [PATCH] gnu: Add Vc.
> 
> * gnu/packages/maths.scm (vc): New variable.

> +(arguments
> + '(#:configure-flags
> +   '("-DBUILD_TESTING=ON"))) ; Is this the test suite we want?

I didn't mean to leave this comment in the patch. I do think this is the
right way to run the tests.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add libdispatch.

[Leo Famulari]

On Fri, Sep 16, 2016 at 10:50:09AM +, ng0 wrote:
> Subject: [PATCH 1/4] gnu: Add libkqueue.
> 
> * gnu/local.mk: Include gnu/packages/libdispatch.scm .
> * gnu/packages/libdispatch.scm: Add new file.
> * gnu/packages/libdispatch.scm (libkqueue): New variable.

LGTM

> Subject: [PATCH 2/4] gnu: Add libpthread_workqueue.
> 
> * gnu/packages/libdispatch.scm (libpthread_workqueue): New variable.

> +(version "0.9.1")

0.9.2 is available upstream:
https://github.com/mheily/libpwq/releases

Can you try using that?

> Subject: [PATCH 3/4] gnu: Add libblocks-runtime.
> 
> * gnu/packages/libdispatch.scm (libblocks-runtime): New variable.

> + (add-after 'unpack 'autogen
> +   (lambda _
> + (zero? (system* "autoreconf" "--install" "--symlink" 
> "--verbose")))

Why use --symlink?

> Subject: [PATCH 4/4] gnu: Add libdispatch.
> 
> * gnu/packages/libdispatch.scm (libdispatch): New variable.

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

The tests can be run with `ctest` [0].

The test suite can be built by setting "-DDISPATCH_ENABLE_TEST_SUITE=1"
in #:configure-flags. However, when I tried that, the build log included
"No compiler support for Blocks; test suite will not be built.", and the
tests were indeed not built.

Does that mean that libblocks-runtime is not working?

Also, the libdispatch tarball bundles Click [0] at 'thirdparty/click'. We
should remove that and use our Click package.

[0]
https://github.com/nickhutchinson/libdispatch#testing-with-ctest

[1]
http://click.pocoo.org/5/


signature.asc
Description: PGP signature

Re: [PATCH 1/4] gnu: Add perl-net-psyc.

[Leo Famulari]

On Thu, Sep 29, 2016 at 10:38:07AM +, ng0 wrote:
> * gnu/packages/psyc.scm: New file.
> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "http://perl.psyc.eu/";
> +   "perlpsyc-" version ".zip"))
> +   (file-name (string-append name "-" version ".zip"))
> +   (sha256
> +(base32
> + "1lw6807qrbmvzbrjn1rna1dhir2k70xpcjvyjn45y35hav333a42"))

This is the wrong hash.
http://lists.gnu.org/archive/html/guix-devel/2016-09/msg02076.html

Adding packages with vulnerabilities (was Re: [PATCH 1/2] gnu: Add perl-net-psyc. [pcre])

[Leo Famulari]

On Thu, Sep 29, 2016 at 08:58:29AM +, ng0 wrote:
> Leo Famulari  writes:
> > On Wed, Sep 21, 2016 at 06:46:31PM +, ng0 wrote:
> >> Subject: [PATCH 1/2] gnu: Add psyclpc.
> >> 
> >> * gnu/packages/psyc.scm (psyclpc): New variable.

> >> +(inputs
> >> + `(("zlib" ,zlib)
> >> +   ("openssl" ,openssl)))
> >> +;; pcre is bundled to ensure the version is compatible. XXX: look into
> >> +;; unbundling it. Upstream should update from pcre 4.5 to 8.38. For
> >> +;; functionality reasons we can not unbundle it now.
> >> +;; ("pcre" ,pcre)))
> >
> > That version of PCRE was released in 2003. We might want to add a
> > warning to the package description...
> >
> > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pcre
> 
> Update on this: the pcre bundling was inherited from ldmud, current
> ldmud has unbundled pcre, so we will be able to unbundle pcre.
> 
> I'd still like to have the patches in their current form and update
> psyclpc when the next version without pcre is out.

I'd like some more opinions on this. Should we add this package even
though we know it contains some security bugs (linked above)?

Re: [PATCH] gnu: Add sunxi-tools.

[Leo Famulari]

On Thu, Sep 29, 2016 at 01:02:04PM +0200, Danny Milosavljevic wrote:
> 
> * gnu/packages/admin.scm (sunxi-tools): New variable.

What's the story with the 'bin/' [0] directory? I'm not familiar with
these file types.

The tarball includes:

bin/fel-pio.bin
bin/fel-pio.nm
bin/fel-sdboot.sunxi
bin/jtag-loop.sunxi
bin/ramboot.scr
bin/ramboot.uboot-sh

[0]
https://github.com/linux-sunxi/sunxi-tools/tree/master/bin

Re: [PATCH] Add tinycm.

[Leo Famulari]

On Thu, Sep 29, 2016 at 08:35:04AM +, ng0 wrote:
> Hi,
> 
> thanks for reviewing this.
> 
> Should I wait until the updates to the python buildsystem harmut sent
> are merged? Including this now would require one more set of python2
> packages to be changed.
> I want this off my todo list and the branch deleted, but waiting until
> this is merged sounds more reasonable to me.

Okay, remind us about these packages when the Python build system is
ready.

Re: [PATCH 00/14] Change python-build-system (fixes bug 20765)

[Leo Famulari]

On Wed, Sep 28, 2016 at 03:58:13PM +0200, Hartmut Goebel wrote:
> this is a patch-series fixing bug 20765.
> 
> Bug 20765 is about problems caused by python packages being installed as
> "zipped eggs" (basically these are zip-files).

Thanks for taking this on!

I will read it more thoroughly tomorrow.

I will test a few packages and, if they work, I plan to create a
python-build-system job on Hydra and try building it the entire package
tree (assuming that Hydra has the capacity).

> This series implements what I proposed in
>   .
> 
> A) For python2 include python2-setuptools as a native-input by default.

Do all python-2 packages require setuptools, or just most of them?

> B) Install Python packages using --single-version-externally-managed

Okay.

> C) Strip python-setuptools and python2-setuptools from all native-inputs
>defined in packages.

Hydra will test this :)

>  * update Python to 2.7.12 and 3.4.5.

Python 2.7.12 and 3.5.2 are on core-updates. Should I cherry-pick those
changes will testing these patches? Or should they work with the Python
packages that we have on master?

Re: [PATCH 00/14] Change python-build-system (fixes bug 20765)

[Leo Famulari]

On Sat, Oct 01, 2016 at 10:27:54PM -0400, Leo Famulari wrote:
> On Wed, Sep 28, 2016 at 03:58:13PM +0200, Hartmut Goebel wrote:
> > this is a patch-series fixing bug 20765.
> > 
> > Bug 20765 is about problems caused by python packages being installed as
> > "zipped eggs" (basically these are zip-files).
> 
> Thanks for taking this on!
> 
> I will read it more thoroughly tomorrow.
> 
> I will test a few packages and, if they work, I plan to create a
> python-build-system job on Hydra and try building it the entire package
> tree (assuming that Hydra has the capacity).

I underestimated the impact of this change. Just looking at libxcb,
which depends on python-minimal-wrapper, I see that ~2500 packages will
be rebuilt. So, depending on the status of core-updates, this should
wait until after core-updates is mostly built.