[PATCH] gnu: Add r-randomforest.

[Raoul Bonnal]

From: Raoul Jean Pierre Bonnal 

* gnu/packages/statistics.scm (r-randomforest): New variable.
---
 gnu/packages/statistics.scm | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 596c2baf5..de934ff08 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -6,7 +6,7 @@
 ;;; Copyright © 2016 Pjotr Prins 
 ;;; Copyright © 2016 Roel Janssen 
 ;;; Copyright © 2016 Ben Woodcroft 
-;;; Copyright © 2016 Raoul Bonnal 
+;;; Copyright © 2017 Raoul Bonnal 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -4145,3 +4145,25 @@ regression.")
 perform @dfn{independent component analysis} (ICA) and projection pursuit.")
 ;; Any GPL version.
 (license license:gpl3+)))
+
+(define-public r-randomforest
+  (package
+(name "r-randomforest")
+(version "4.6-12")
+(source
+ (origin
+   (method url-fetch)
+   (uri (cran-uri "randomForest" version))
+   (sha256
+(base32
+ "1i43idaihhl6nwqw42v9dqpl6f8z3ykcn2in32lh2755i27jylbf"
+(properties `((upstream-name . "randomForest")))
+(build-system r-build-system)
+(home-page "https://www.stat.berkeley.edu/~breiman/RandomForests/;)
+(native-inputs
+ `(("gfortran" ,gfortran)))
+(synopsis "Breiman and Cutler's random forests for classification and 
regression")
+(description
+"This package provides algorithm for classification and regression based on a 
forest
+of trees using random inputs.")
+(license license:gpl2+)))
-- 
2.11.0

Re: “Future of Guix” panel

[Pjotr Prins]

Heh. Long list.

On Fri, Feb 03, 2017 at 12:11:15AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> We’ll close FOSDEM with a discussion on the future of Guix and GuixSD:
> 
>   https://fosdem.org/2017/schedule/event/futureofguix/
> 
> Attached is a semi-structured list of topics that came to mind.  Please
> feel free to bring your own, either at the event (this Sunday), or on
> this list, or on IRC during the event maybe?
> 
> Ludo’.
> 

> #+TITLE: Future of Guix (panel)
> #+STARTUP: content hidestars
> 
> https://fosdem.org/2017/schedule/event/futureofguix/
> Sunday, 16:30, K.4.601
> 
> * Organization
> 
> ** sharing the work load
> 
> *** security updates
> 
> *** build farm
> 
> *** web site, posts, videos, etc.
> 
> *** handling branches: starting & merging ‘core-updates’, ‘staging’
> 
> *** release management: setting a date, choosing what goes in, publishing
> 
> *** GSoC mentoring
> 
> ** review
> 
> *** getting more reviewers
> 
> *** facilitating the process
> 
> *** encouraging newcomers
> 
> ** funding
> 
> *** development
> 
>   - how do we get core & maintenance work funded?
>   - how do we get funding for new areas (like ‘guix deploy’)?
> 
> *** infrastructure (build farm)
> 
>   - sustaining infrastructure growth and maintenance
>   - Jan. 2016 crowdfunding was enough for a start
> 
> * Publicity, outreach
> 
> ** high-performance computing (HPC)
> 
> *** competition: EasyBuild, Spack, Singularity, Shifter
> 
> *** stories: MDC, Utrecht, Brisbane
> 
> *** possible cooperation in the near future
> 
> ** reproducible science
> 
> *** how to help projects such as [[https://rescience.github.io/][ReScience]]?
> 
> *** make reproducible free software stacks the obvious choice
> 
> ** containers, deployment
> 
> *** competition: Docker, Kubernetes, NixOps
> 
> *** stories: gov.uk (Chris Baines), bayfront.guixsd.org
> 
> ** hold Guix User Gatherings (GUGs)?
> 
> * Code
> 
> ** 1.0 in 2017! (see roadmap in 
> [[https://www.gnu.org/software/guix/guix-ghm-20160818.pdf][GHM 2016 talk]])
> 
> *** ‘guix pull’ and channels
> 
> *** Git checkout authentication
> 
> *** performance & usability improvements
> 
> *** GuixSD graphical installer (John)
> 
> *** self-hosted infrastructure
> 
>  Cuirass
> 
>  ‘guix publish’ improvements
> 
>  build machines running GuixSD
> 
> *** bug fixes
> 
> ** next big thing: ‘guix deploy’
> 
> ** scalability
> 
> *** better importers & updaters
> 
> *** better ‘guix lint -c cve’
> 
> ** reproducibility: reach 90% or so, and measure
> 
> ** bootstrapping
> 
> *** reduce the size of our bootstrap binaries (Bournish? Mes? …)
> 
> *** “do something” about compilers that cannot be bootstrapped


-- 

Re: [PATCH] gnu: Add no-more-secrets.

[Eric Bavier]

On Thu,  2 Feb 2017 14:32:14 +
contact@cryptolab.net wrote:

> From: ng0 
> 
> * gnu/packages/games.scm (no-more-secrets): New variable.
> ---
>  gnu/packages/games.scm | 38 +-
>  1 file changed, 37 insertions(+), 1 deletion(-)

Pushed in 345504c79d2b412f1036ff0cbd964e344a24b162

Thanks!
`~Eric

“Future of Guix” panel

[Ludovic Courtès]

Hello Guix!

We’ll close FOSDEM with a discussion on the future of Guix and GuixSD:

  https://fosdem.org/2017/schedule/event/futureofguix/

Attached is a semi-structured list of topics that came to mind.  Please
feel free to bring your own, either at the event (this Sunday), or on
this list, or on IRC during the event maybe?

Ludo’.

#+TITLE: Future of Guix (panel)
#+STARTUP: content hidestars

https://fosdem.org/2017/schedule/event/futureofguix/
Sunday, 16:30, K.4.601

* Organization

** sharing the work load

*** security updates

*** build farm

*** web site, posts, videos, etc.

*** handling branches: starting & merging ‘core-updates’, ‘staging’

*** release management: setting a date, choosing what goes in, publishing

*** GSoC mentoring

** review

*** getting more reviewers

*** facilitating the process

*** encouraging newcomers

** funding

*** development

  - how do we get core & maintenance work funded?
  - how do we get funding for new areas (like ‘guix deploy’)?

*** infrastructure (build farm)

  - sustaining infrastructure growth and maintenance
  - Jan. 2016 crowdfunding was enough for a start

* Publicity, outreach

** high-performance computing (HPC)

*** competition: EasyBuild, Spack, Singularity, Shifter

*** stories: MDC, Utrecht, Brisbane

*** possible cooperation in the near future

** reproducible science

*** how to help projects such as [[https://rescience.github.io/][ReScience]]?

*** make reproducible free software stacks the obvious choice

** containers, deployment

*** competition: Docker, Kubernetes, NixOps

*** stories: gov.uk (Chris Baines), bayfront.guixsd.org

** hold Guix User Gatherings (GUGs)?

* Code

** 1.0 in 2017! (see roadmap in [[https://www.gnu.org/software/guix/guix-ghm-20160818.pdf][GHM 2016 talk]])

*** ‘guix pull’ and channels

*** Git checkout authentication

*** performance & usability improvements

*** GuixSD graphical installer (John)

*** self-hosted infrastructure

 Cuirass

 ‘guix publish’ improvements

 build machines running GuixSD

*** bug fixes

** next big thing: ‘guix deploy’

** scalability

*** better importers & updaters

*** better ‘guix lint -c cve’

** reproducibility: reach 90% or so, and measure

** bootstrapping

*** reduce the size of our bootstrap binaries (Bournish? Mes? …)

*** “do something” about compilers that cannot be bootstrapped

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

Hi Danny,

> For example, let's say Intel had non-updateable microcode on its CPUs and it 
> included a backdoor. If anyone *ever* found it, nobody would trust Intel ever 
> again - and Intel couldn't sweep it under the rug because millions of 
> physical chips that include the backdoor would be in the hands of different 
> people. What could they do?
>
> On the other hand, if firmware is updateable by a (possibly automated) 
> program, that program could easily check whether it's running on *your* 
> computer specifically and then give you a special firmware. Now nobody but 
> you has a chance to find it. Not to mention checking the date etc.
>
> With all the spying going on that's a *real* possibility. Also, many people 
> already found backdoors in BIOS updates for example - so it's not theoretical.

But you can check the hash of the firmware. If a device doesn't have
internal flash we at least know that it's running the firmware we are
giving it. If the device has internal storage and if someone wanted to
target you and did have the resources to do so, they could reflash the
chip and you'd never know. Isn't human error just as scary as the NSA?

Re: postorius, v2

[ng0]

Hartmut Goebel writes:

> Hi,
>
> I just found that I did not verify the inputs carefully enough. Sorry.
> Here are my comments:
>
>   * python-defusedxml: okay
>   * python-openid: okay
>   * python-django-allauth:
>   o openid, request-oauthlib requests ought to be propagated inputs
>   o mock is native, okay, but only required for the python2 variant
>   o Why is django a native input? See below for discussion
>   * python-django-gravatar2, may be okay, see below for discussion.
>   *  python-django-mailman3
>   o All "inputs" except django need to be propagated inputs.
>   o Regarding django: see below
>   * * postorius: okay (this is an application, so no propagated inputs
> are required)
>
>
> And as we just learned about the licenses: python-django-mailman3 should
> be gpl3+
>
>
> I'm unsure about the correct handling of django in django-XXX. Can we
> find rules for this to make future packager's life easier?
>
> Should django be a "normal" input or a "native" one? What does this
> depend on?
>

For now I will go with (input) and not (native-input). If that's
not okay, we can still fix it afterwards?
I will send the new patchseries tomorrow.

Thanks!

> Clear is: django-XXX should not "propagate" django:
>
>   * django is a framework, django-XXX is an extension for this framework.
>   * If some application is using django-XXX, I'd expect it to have
> django specified as "input", too, since primary it is a django
> application. Maybe even djangoXXX is an optional component
>
>
> Just for the records:
>
>   * django-XXX should propagate other django extension it requires.
>   o If some application is using django-XXX, if should not care
> about other django extensions django-XXX requires. This is the
> same like as it does not have to care about other python
> packages django-XXX requires.


-- 
ng0 . https://www.inventati.org/patternsinthechaos/

Re: [PATCH 1/2] gnu: Add python-lz4.

[Hartmut Goebel]

Am 02.02.2017 um 16:16 schrieb contact@cryptolab.net:
> * gnu/packages/compression.scm (python-lz4): New variable.

LGTM

-- 
Regards
Hartmut Goebel

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



0xBF773B65.asc
Description: application/pgp-keys

Re: [PATCH 2/2] gnu: Add python-lzo.

[Hartmut Goebel]

Am 02.02.2017 um 16:16 schrieb contact@cryptolab.net:
> +(string-append "include_dirs.append(\""
> +   (assoc-ref %build-inputs "lzo") 
> "/include/lzo" "\")

You could use single quotes for teh python string to make it more readable:


string-append "include_dirs.append('" + (assoc-ref %build-inputs "lzo")
"/include/lzo" "')


> +"

Also this line-break is confusing. I suggest either using "\n" or to
change the substitute into something like:


+ (substitute* "setup.py"
+   (("include_dirs.append\(.*\)")  ;; match up to the trailing 
parent only, not the new-line
+(string-append "include_dirs.append('"
+   (assoc-ref %build-inputs "lzo") "/include/lzo"
+   "')"   ;; put these last few characters 
on the next line

Otherwise LGTM.

-- 
Regards
Hartmut Goebel

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



0xBF773B65.asc
Description: application/pgp-keys

Re: [PATCH 1/7] guix: git: Support shallow git clones if a tag is available

[ng0]

Ludovic Courtès writes:

> Andy Wingo  skribis:
>
>> * guix/build/git.scm (git-fetch): Instead of cloning the remote repo, use the
>>   lower-level "init" / "fetch" / "checkout" operations.  This lets us make a
>>   shallow checkout if we are checking out a tag.
>>
>> * guix/git-download.scm (): Add tag field.
>>   (git-fetch): Support git references with tags but no commits.
>
> This sounds like a nice improvement.  Please move the “This lets us”
> sentence to a comment, and drop the newline between entries.
>
>> --- a/guix/build/git.scm
>> +++ b/guix/build/git.scm
>
> Make sure to add a copyright line in there.
>
> [...]
>
>>git-reference make-git-reference
>>git-reference?
>>(urlgit-reference-url)
>> -  (commit git-reference-commit)
>> +  (commit git-reference-commit (default #f))
>> +  (taggit-reference-tag (default #f))
>
> So far we’ve been using ‘commit’ to denote commits or tags.  I guess a
> bunch of packages will need to be updated.
>
> There’s the issue that one could erroneously specify both ‘commit’ and
> ‘tag’, and then one of them would be ignored.
>
> What about doing something like:
>
>   1. renaming ‘commit’ to ‘spec’;
>   2. adding a ‘type’ field which would default to 'commit and could be
>  changed to 'tag
>
> ?

Was the idea here to change the code to make use of spec inside
the package definitions and other modules which use git-fetch, so
that all instances of "commit" have to be replaced?

I have Andy's patch applied now, but to debug the outcome of this
(commit is no longer a bound variable), I need to know what the
intention was.

>> +   ;; FIXME: Pass #:tag when fixed daemons are widely
>> +   ;; deployed.
>> +   ;; #:tag '#$(git-reference-tag ref)
>
> The daemon is not involved here, AFAICS, so you can uncomment the line.
>
> Thanks,
> Ludo’.


-- 
ng0 . https://www.inventati.org/patternsinthechaos/

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

> I don't think the firmware needs to be uploaded at all to the AR9285 device.

I don't understand:

1. free firmware - anyone can update the firmware
2. binary blob - the vendor can update the firmware
3. fixed at manufacturing time - no one can update the firmware

Option 1 is obviously superior to the other two. But how is option 3
better than option 2?

Re: [PATCH] gnu: dub: Patch pkg-config name.

[Danny Milosavljevic]

Hi Ludo,

On Wed, 01 Feb 2017 23:22:32 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> Is it necessary?  It might be a case where picking whatever’s in $PATH
> (“late binding”) is good enough; for instance, ‘gcc’ picks ‘ld’ from
> $PATH, and that’s fine.

I don't know. What's the policy for pkg-config in general?

I did it that way now because

(1) pkg-config is not a native-input of anything D - so if the user didn't 
install pkg-config into his profile by chance, the build of some D packages 
will fail.
(2) pkg-config itself is very seldomly updated so it doesn't matter if dub pins 
it to one specific version - that would even be what I would expect to happen.

I'm fine with adding it someway else (especially if it's the same way it's 
usually added).

So either

(a) dub needs it as input (like this patch would do) or
(b) every D package needs it as native-input (maybe the build system would 
auto-add it as native-input to every D package - like it does add ldc and dub)

- otherwise it will break.

(dub uses pkg-config in order to find the library flags to add when importing a 
given library)

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[Danny Milosavljevic]

Hi David,

I have an Atheros AR9285 in GuixSD and it works. 
/sys/class/net/wlp2s0/device/driver says it's using the driver ath9k PCI.

On Thu, 2 Feb 2017 18:07:22 +0100
David Craven  wrote:

> I'm having trouble finding information. The opened atheros firmware is
> only for the AR7010 and AR9271 USB dongles if I understand correctly?
> The other thing that was opened are the C headers including the
> register definitions for a subset of the AR9300 chipset, but it would
> still require implementing the firmware to be useful to linux-libre?

I don't think the firmware needs to be uploaded at all to the AR9285 device.

It probably does have a firmware on-chip - I don't know.

Anyway, it worked out of the box without any extra firmware files on my 
computer.

Re: [PATCH] gnu: Add emacs-mew.

[Thomas Danckaert]

From: Alex Kost 
Subject: Re: [PATCH] gnu: Add emacs-mew.
Date: Thu, 02 Feb 2017 11:56:22 +0300

OK, I see.  We can just patch "mew-key.el" file by putting the 
following

line there:

  (add-to-list 'image-load-path 'mew-icon-directory)

WDYT?


Yes, that would be fine!  I added a patch file, don't know if there's 
a more elegant way to achieve the same result?



[...]

Also you seem to overlook my comment about autoloads.  My version of
your patch (attached in my previous message) contains a phase to
generate "mew-autoloads.el".  This file is really needed to have 
"M-x

mew" command available by default.  Otherwise, a user has to put:

  (autoload 'mew "mew" nil t)

in his/her emacs config.


Yes, sorry, I just agreed and then forgot to comment on that part.  I 
didn't know about 'emacs-generate-autoloads and think it's great  :)


Thanks for your help!

Thomas
From 3179514335f61e29f93994f4dc0f59c30b59e876 Mon Sep 17 00:00:00 2001
From: Thomas Danckaert 
Date: Tue, 24 Jan 2017 09:41:42 +0100
Subject: [PATCH] gnu: Add emacs-mew.

* gnu/packages/mail.scm (emacs-mew): New variable.
* gnu/packages/patches/mew-add-icons-to-load-path.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.

Co-authored-by: Alex Kost 
---
 gnu/local.mk   |  1 +
 gnu/packages/mail.scm  | 52 ++
 .../patches/mew-add-icons-to-load-path.patch   | 14 ++
 3 files changed, 67 insertions(+)
 create mode 100644 gnu/packages/patches/mew-add-icons-to-load-path.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 59fc1a8..c9a5a3a 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -744,6 +744,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/mcrypt-CVE-2012-4527.patch			\
   %D%/packages/patches/mesa-wayland-egl-symbols-check-mips.patch	\
   %D%/packages/patches/metabat-remove-compilation-date.patch	\
+  %D%/packages/patches/mew-add-icons-to-load-path.patch		\
   %D%/packages/patches/mhash-keygen-test-segfault.patch		\
   %D%/packages/patches/mingw-w64-5.0rc2-gcc-4.9.3.patch		\
   %D%/packages/patches/mpc123-initialize-ao.patch		\
diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
index 2318ae9..c6aa820 100644
--- a/gnu/packages/mail.scm
+++ b/gnu/packages/mail.scm
@@ -20,6 +20,7 @@
 ;;; Copyright © 2016 Arun Isaac 
 ;;; Copyright © 2016 John Darrington 
 ;;; Copyright © 2016 Marius Bakke 
+;;; Copyright © 2017 Thomas Danckaert 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -79,6 +80,7 @@
   #:use-module (gnu packages flex)
   #:use-module (gnu packages gdb)
   #:use-module (gnu packages man)
+  #:use-module (gnu packages ruby)
   #:use-module (gnu packages samba)
   #:use-module (gnu packages screen)
   #:use-module (gnu packages tls)
@@ -377,6 +379,56 @@ can read the same mailbox from multiple computers.  It supports IMAP as REMOTE
 repository and Maildir/IMAP as LOCAL repository.")
 (license gpl2+)))
 
+(define-public emacs-mew
+  (package
+(name "emacs-mew")
+(version "6.7")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://mew.org/Release/mew-;
+  version ".tar.gz"))
+  (patches (search-patches "mew-add-icons-to-load-path.patch"))
+  (sha256
+   (base32
+"03fzky2kz73vgx4cbps2psbbnrgqgkk5q7jwfldisymkzr9iz03y"
+(inputs
+ `(("emacs" ,emacs-minimal)))
+(propagated-inputs
+ `(("ruby-sqlite3" ,ruby-sqlite3) ; optional for the database of messages
+   ("ruby" ,ruby))) ; to set GEM_PATH so ruby-sqlite3 is found at runtime
+(build-system gnu-build-system)
+(arguments
+ (let ((elisp-dir "/share/emacs/site-lisp/guix.d/mew")
+   (icon-dir  "/share/mew"))
+   `(#:modules ((guix build gnu-build-system)
+(guix build utils)
+(guix build emacs-utils))
+ #:imported-modules (,@%gnu-build-system-modules
+ (guix build emacs-utils))
+ #:configure-flags
+ (list (string-append "--with-elispdir=" %output ,elisp-dir)
+   (string-append "--with-etcdir=" %output ,icon-dir))
+ #:phases
+ (modify-phases %standard-phases
+   (add-after 'configure 'patch-mew-icon-directory
+ (lambda* (#:key outputs #:allow-other-keys)
+   (emacs-substitute-variables "mew-key.el"
+ ("mew-icon-directory"
+  (string-append (assoc-ref outputs "out") ,icon-dir)))
+   #t))
+   (add-after 'install 'generate-autoloads
+ (lambda* (#:key outputs #:allow-other-keys)
+   (emacs-generate-autoloads
+"mew" (string-append (assoc-ref outputs "out") ,elisp-dir))
+   #t)))
+ #:tests? #f)))
+

Re: FOSDEM social dinner

[Marius Bakke]

Alex Sassmannshausen  writes:

> Hello,
>
> To confirm, I've now placed a reservation for Saturday 4 February at
> 19:30 at a Lebanese restaurant called Al Jannah.  I haven't been there
> before, but the menu looks diverse, the prices good and the location
> relatively central.
>
> https://www.tripadvisor.com/Restaurant_Review-g188644-d2039550-Reviews-Al_Jannah-Brussels.html
>
> Address:
> Rue Blaes 59, Brussels 1000, Belgium
>
> There is a direct tram line from ULB to Louise, and then it's a 5-10 min
> walk.  From there it's probably around 15 min walk to the central
> station where there are trains to Antwerp.
>
> List of attendees:
> Leo, Catonano, Amirouche, Efraim, Tomáš, Thomas, Tobias, Christopher
> Baines, Manolis, Ludo, Ricardo, Matias and myself.
>
> Let me know if I missed you, or if you have questions!

Good news everyone! I'll be there, food or not! :D


signature.asc
Description: PGP signature

Re: Sway - a wayland i3 compatible compositor [RFC]

[Maxim Cournoyer]

Hi ng0,

contact@cryptolab.net writes:

> Right now I'm stuck at the manpage generation of sway, the dependencies are 
> alright.
>
> Error message below. Help is welcome :)
>
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /tmp/guix-build-sway-0.11.drv-0/build
> phase `configure' succeeded after 2.8 seconds
> starting phase `patch-generated-file-shebangs'
[...]
> /tmp/guix-build-sway-0.11.drv-0/build/bin
> /tmp/guix-build-sway-0.11.drv-0/sway-0.11/sway/sway.1.txt
> a2x: WARNING: --destination-dir option is only applicable to HTML based 
> outputs
> a2x: WARNING: --destination-dir option is only applicable to HTML based 
> outputs
> a2x: ERROR: "xsltproc" --stringparam callout.graphics 0 --stringparam

Is xsltproc available in a "guix environment sway" environment? If not,
you should add it as a native-input to your sway package definition. We
have a couple examples where xsltproc is used to generate manpages. One
example I'm familiar with is the udisks package, in (gnu packages freedesktop).

Good luck!

Maxim


signature.asc
Description: PGP signature

Re: [PATCH 5/5] gnu: libextractor: Move .a files to output "static".

[Maxim Cournoyer]

Hi ng0,

contact@cryptolab.net writes:

> From: ng0 
>
> * gnu/packages/gnunet.scm (libextractor): Move .a files to "static" output.
> [arguments](phases): New phase for moving .a files to output "static".
> ---
>  gnu/packages/gnunet.scm | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
> index f7da12ad5..a4514a7f4 100644
> --- a/gnu/packages/gnunet.scm
> +++ b/gnu/packages/gnunet.scm
> @@ -115,13 +115,30 @@
>("zlib" ,zlib)))
> (native-inputs
>  `(("pkg-config" ,pkg-config)))
> +   (outputs '("out"
> +  "static")) ; 396 KiB .a files
> (arguments
>  `(#:configure-flags
>(list (string-append "--with-ltdl="
> (assoc-ref %build-inputs "libltdl"))
>  (string-append "--with-tidy="
> (assoc-ref %build-inputs "tidy-html")))
> -  #:parallel-tests? #f))
> +  #:parallel-tests? #f
> +  #:phases
> +  (modify-phases %standard-phases
> +(add-after 'install 'move-static-libraries
> +  (lambda* (#:key outputs #:allow-other-keys)
> +;; Move static libraries to the "static" output.
> +(let* ((out(assoc-ref outputs "out"))
> +   (lib(string-append out "/lib"))
> +   (static (assoc-ref outputs "static"))
> +   (slib   (string-append static "/lib")))
> +  (mkdir-p slib)
> +  (for-each (lambda (file)
> +  (install-file file slib)
> +  (delete-file file))
> +(find-files lib "\\.a$"))
> +  #t))
> (synopsis "Library to extract meta-data from media files")
> (description
>  "GNU libextractor is a library for extracting metadata from files.  It

I've reviewed this patch series and didn't see anything wrong. Looking
at how often you strip the ".a" static libraries into a separate output,
maybe it'd be worth the effort of adding an automatic way of doing so in
the gnu build system? I'm thinking it could work in a way similar to
adding debug symbols: simply add a "static" output and the rest is taken
care of automagically.

Thanks for all the packaging work!

Maxim


signature.asc
Description: PGP signature

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

> I was surprised that linux-libre works on the dell xps 13. I'm
> considering buying an atheros wifi card, since that's the only thing
> that does not work. Does anyone know how to find out if there is a
> BIOS whitelist/blacklist? So it's just ARM boards that don't work with
> linux-libre?

I'm having trouble finding information. The opened atheros firmware is
only for the AR7010 and AR9271 USB dongles if I understand correctly?
The other thing that was opened are the C headers including the
register definitions for a subset of the AR9300 chipset, but it would
still require implementing the firmware to be useful to linux-libre?

Re: 02/02: gnu: gstreamer: Update to 1.10.3.

[Leo Famulari]

On Thu, Feb 02, 2017 at 12:50:22AM -0500, Mark H Weaver wrote:
> Unfortunately, gst-plugins-base-1.10.3 has failed its test suite on i686
> three times in a row on Hydra, which leaves i686 users in a very bad
> spot, since modern web browsers, media players, and desktop environments
> become dependency failures.
> 
>   https://hydra.gnu.org/build/1824127
> 
> If we can't find a proper fix soon, we may need to revert this change.

Gstreamer 1.10.3 fixed a large number of bugs with potential security
implications:

http://seclists.org/oss-sec/2017/q1/258

So, hopefully we can find a fix for i686 platforms quickly so users can
get those changes.


signature.asc
Description: PGP signature

[PATCH 2/2] gnu: Add python-lzo.

[contact . ng0]

From: ng0 

* gnu/packages/compression.scm (python-lzo): New variable.

Co-authored-by: Danny Milosavljevic 
---
 gnu/packages/compression.scm | 36 
 1 file changed, 36 insertions(+)

diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 64518fb6b..2545c4517 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -365,6 +365,42 @@ LZO is written in ANSI C.  Both the source code and the 
compressed data
 format are designed to be portable across platforms.")
 (license license:gpl2+)))
 
+(define-public python-lzo
+  (package
+(name "python-lzo")
+(version "1.11")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "python-lzo" version))
+   (sha256
+(base32
+ "11p3ifg14p086byhhin6azx5svlkg8dzw2b5abixik97xd6fm81q"
+(build-system python-build-system)
+(arguments
+ `(#:test-target "check"
+   #:phases
+   (modify-phases %standard-phases
+ (add-after 'unpack 'patch-setuppy
+   (lambda _
+ (substitute* "setup.py"
+   (("include_dirs.append.*")
+(string-append "include_dirs.append(\""
+   (assoc-ref %build-inputs "lzo") "/include/lzo" 
"\")
+"
+(inputs
+ `(("lzo" ,lzo)))
+(home-page "https://github.com/jd-boyd/python-lzo;)
+(synopsis "Python bindings for the LZO data compression library")
+(description
+ "Python-LZO provides Python bindings for LZO, i.e. you can access
+the LZO library from your Python scripts thereby compressing ordinary
+Python strings.")
+(license license:gpl2+)))
+
+(define-public python2-lzo
+  (package-with-python2 python-lzo))
+
 (define-public lzop
   (package
 (name "lzop")
-- 
2.11.0

Re: [PATCH 7/7] gnu: Enable CONFIG_HOTPLUG_PCI.

[David Craven]

I was surprised that linux-libre works on the dell xps 13. I'm
considering buying an atheros wifi card, since that's the only thing
that does not work. Does anyone know how to find out if there is a
BIOS whitelist/blacklist? So it's just ARM boards that don't work with
linux-libre?

Re: 02/02: gnu: gstreamer: Update to 1.10.3.

[Marius Bakke]

Marius Bakke  writes:

> Mark H Weaver  writes:
>
>> Hi,
>>
>> mba...@fastmail.com (Marius Bakke) writes:
>>
>>> mbakke pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit 3e32eeb2478a9d3b46a2e858fdc416420bffe302
>>> Author: Marius Bakke 
>>> Date:   Wed Feb 1 15:16:07 2017 +0100
>>>
>>> gnu: gstreamer: Update to 1.10.3.
>>> 
>>> * gnu/packages/gstreamer.scm (gstreamer): Update to 1.10.3.
>>> (gst-plugins-base): Likewise.
>>> (gst-plugins-good): Likewise.
>>> (gst-plugins-bad): Likewise.
>>> (gst-plugins-ugly): Likewise.
>>> (gst-libav): Likewise.
>>> (python-gst): Likewise.
>>
>> Unfortunately, gst-plugins-base-1.10.3 has failed its test suite on i686
>> three times in a row on Hydra, which leaves i686 users in a very bad
>> spot, since modern web browsers, media players, and desktop environments
>> become dependency failures.
>>
>>   https://hydra.gnu.org/build/1824127
>>
>> If we can't find a proper fix soon, we may need to revert this change.
>
> I can reproduce it with `guix build --system=i686-linux` on x86_64.

This was fixed upstream a few hours ago:

https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=5e2e111627871c566ffc6607eda8f4ef4699d040

I pushed this patch as fe241868e39d102f074805b38d6621435f25.


signature.asc
Description: PGP signature

Re: 02/02: gnu: gstreamer: Update to 1.10.3.

[Marius Bakke]

Mark H Weaver  writes:

> Hi,
>
> mba...@fastmail.com (Marius Bakke) writes:
>
>> mbakke pushed a commit to branch master
>> in repository guix.
>>
>> commit 3e32eeb2478a9d3b46a2e858fdc416420bffe302
>> Author: Marius Bakke 
>> Date:   Wed Feb 1 15:16:07 2017 +0100
>>
>> gnu: gstreamer: Update to 1.10.3.
>> 
>> * gnu/packages/gstreamer.scm (gstreamer): Update to 1.10.3.
>> (gst-plugins-base): Likewise.
>> (gst-plugins-good): Likewise.
>> (gst-plugins-bad): Likewise.
>> (gst-plugins-ugly): Likewise.
>> (gst-libav): Likewise.
>> (python-gst): Likewise.
>
> Unfortunately, gst-plugins-base-1.10.3 has failed its test suite on i686
> three times in a row on Hydra, which leaves i686 users in a very bad
> spot, since modern web browsers, media players, and desktop environments
> become dependency failures.
>
>   https://hydra.gnu.org/build/1824127
>
> If we can't find a proper fix soon, we may need to revert this change.

I can reproduce it with `guix build --system=i686-linux` on x86_64.

Reverting is not a good option due to:

http://seclists.org/oss-sec/2017/q1/284

Will try to figure out what's going on.


signature.asc
Description: PGP signature

LZ4 + LZO python bindings

[contact . ng0]

This adds python-lz4 and python-lzo, received some QA/review back in september. 
I rebased and applied changes for the current (new) python build-system.

[PATCH 1/2] gnu: Add python-lz4.

[contact . ng0]

From: ng0 

* gnu/packages/compression.scm (python-lz4): New variable.
---
 gnu/packages/compression.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index 73a35030e..64518fb6b 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -14,6 +14,7 @@
 ;;; Copyright © 2016 David Craven 
 ;;; Copyright © 2016 Kei Kebreau 
 ;;; Copyright © 2016 Marius Bakke 
+;;; Copyright © 2017 ng0 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -38,6 +39,7 @@
   #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system perl)
+  #:use-module (guix build-system python)
   #:use-module (gnu packages)
   #:use-module (gnu packages assembly)
   #:use-module (gnu packages autotools)
@@ -45,6 +47,7 @@
   #:use-module (gnu packages base)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages python)
   #:use-module (gnu packages valgrind)
   #:use-module (ice-9 match)
   #:use-module ((srfi srfi-1) #:select (last)))
@@ -633,6 +636,31 @@ time for compression ratio.")
 ;; line interface programs (lz4, fullbench, fuzzer, datagen) are GPL2+.
 (license (list license:bsd-2 license:gpl2+
 
+(define-public python-lz4
+  (package
+(name "python-lz4")
+(version "0.8.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "lz4" version))
+   (sha256
+(base32
+ "1irad4sq4hdr30fr53smvv3zzk4rddcf9b4jx19w8s9xsxhr1x3b"
+(build-system python-build-system)
+(native-inputs
+ `(("python-nose" ,python-nose)))
+(home-page "https://github.com/python-lz4/python-lz4;)
+(synopsis "LZ4 Bindings for Python")
+(description
+ "This package provides python bindings for the lz4 compression library
+by Yann Collet.  The project contains bindings for the LZ4 block format and
+the LZ4 frame format.")
+(license license:bsd-3)))
+
+(define-public python2-lz4
+  (package-with-python2 python-lz4))
+
 (define-public squashfs-tools
   (package
 (name "squashfs-tools")
-- 
2.11.0

no-more-secrets, v2

[contact . ng0]

Moved from art.scm to games.scm

[PATCH] gnu: Add no-more-secrets.

[contact . ng0]

From: ng0 

* gnu/packages/games.scm (no-more-secrets): New variable.
---
 gnu/packages/games.scm | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 98a4d6901..c3514feac 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -17,7 +17,7 @@
 ;;; Copyright © 2015 Taylan Ulrich Bayırlı/Kammer 
 ;;; Copyright © 2016 Rodger Fox 
 ;;; Copyright © 2016 Manolis Fragkiskos Ragkousis 
-;;; Copyright © 2016 ng0 
+;;; Copyright © 2016, 2017 ng0 
 ;;; Copyright © 2016 Albin Söderqvist 
 ;;; Copyright © 2016 Kei Kebreau 
 ;;; Copyright © 2016 Alex Griffin 
@@ -3102,3 +3102,39 @@ inspired by the history of human civilization.  The game 
commences in
 prehistory and your mission is to lead your tribe from the Stone Age
 to the Space Age.")
(license license:gpl2+)))
+
+(define-public no-more-secrets
+  (package
+(name "no-more-secrets")
+(version "0.3.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://github.com/bartobri/no-more-secrets/;
+   "archive/v" version ".tar.gz"))
+   (file-name (string-append name "-" version ".tar.gz"))
+   (sha256
+(base32
+ "038flwqr0kqv55im2v76xjn01zbvvkb3nzb5ridwm2kbnk9cgg4v"
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f
+   #:make-flags (list "CC=gcc" "all-ncurses"
+  (string-append "prefix="
+ (assoc-ref %outputs "out")))
+   #:phases
+   (modify-phases %standard-phases
+ (delete 'configure
+(inputs
+ `(("ncurses" ,ncurses)))
+(home-page "https://github.com/bartobri/no-more-secrets;)
+(synopsis "Recreation of data decryption effect in \"Sneakers\"")
+(description
+ "@code{No More Secrets} provides a command line tool called \"nms\"
+that recreates the famous data decryption effect seen on screen in the 1992
+movie \"Sneakers\".
+
+This command works on piped data.  Pipe any ASCII or UTF-8 text to nms, and
+it will apply the hollywood effect, initially showing encrypted data, then
+starting a decryption sequence to reveal the original plaintext characters.")
+(license license:expat)))
-- 
2.11.0

Re: [PATCH 3/7] gnu: Add python2-ruamel.ordereddict

[Tobias Geerinckx-Rice]

Maxim,

On 02/02/17 05:53, Maxim Cournoyer wrote:
> Also, there are 2 spaces following the period.
> 2 spaces following the period here also. Is this intended?

Worse: it's mandatory ;-)

Kind regards,

T G-R



signature.asc
Description: OpenPGP digital signature

Python packaging rules again (was: postorius, v2)

[Hartmut Goebel]

Hi,

I'm reposting this with a different subject, since this question is not
only related to postorius:

What do others think about the central question:

Should django be a "normal" input or a "native" one? What does this
depend on? What are the rules for?



> I'm unsure about the correct handling of django in django-XXX. Can we
> find rules for this to make future packager's life easier?
>
> Should django be a "normal" input or a "native" one? What does this
> depend on?
>
>
> Clear is: django-XXX should not "propagate" django:
>
>   * django is a framework, django-XXX is an extension for this framework.
>   * If some application is using django-XXX, I'd expect it to have
> django specified as "input", too, since primary it is a django
> application. Maybe even djangoXXX is an optional component
>
>
> Just for the records:
>
>   * django-XXX should propagate other django extension it requires.
>   o If some application is using django-XXX, if should not care
> about other django extensions django-XXX requires. This is the
> same like as it does not have to care about other python
> packages django-XXX requires.


-- 
Regards
Hartmut Goebel

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

Re: postorius, v2

[ng0]

Hartmut Goebel writes:

> Hi,
>
> I just found that I did not verify the inputs carefully enough. Sorry.
> Here are my comments:

No problem. Thanks for checking again, I have no previous
experience with django.

>   * python-defusedxml: okay
>   * python-openid: okay
>   * python-django-allauth:
>   o openid, request-oauthlib requests ought to be propagated inputs
>   o mock is native, okay, but only required for the python2 variant
>   o Why is django a native input? See below for discussion
>   * python-django-gravatar2, may be okay, see below for discussion.
>   *  python-django-mailman3
>   o All "inputs" except django need to be propagated inputs.
>   o Regarding django: see below
>   * * postorius: okay (this is an application, so no propagated inputs
> are required)
>
>
> And as we just learned about the licenses: python-django-mailman3 should
> be gpl3+

Ok.

>
> I'm unsure about the correct handling of django in django-XXX. Can we
> find rules for this to make future packager's life easier?
>
> Should django be a "normal" input or a "native" one? What does this
> depend on?
>
>
> Clear is: django-XXX should not "propagate" django:
>
>   * django is a framework, django-XXX is an extension for this framework.
>   * If some application is using django-XXX, I'd expect it to have
> django specified as "input", too, since primary it is a django
> application. Maybe even djangoXXX is an optional component
>
>
> Just for the records:
>
>   * django-XXX should propagate other django extension it requires.
>   o If some application is using django-XXX, if should not care
> about other django extensions django-XXX requires. This is the
> same like as it does not have to care about other python
> packages django-XXX requires.

I'm waiting for further input on the django-XXX issue, then I
will rebase and send updated patches.
This will be important for the next step, hyperkitty, too.

Thanks!
-- 
ng0 . https://www.inventati.org/patternsinthechaos/

Re: postorius, v2

[Hartmut Goebel]

Hi,

I just found that I did not verify the inputs carefully enough. Sorry.
Here are my comments:

  * python-defusedxml: okay
  * python-openid: okay
  * python-django-allauth:
  o openid, request-oauthlib requests ought to be propagated inputs
  o mock is native, okay, but only required for the python2 variant
  o Why is django a native input? See below for discussion
  * python-django-gravatar2, may be okay, see below for discussion.
  *  python-django-mailman3
  o All "inputs" except django need to be propagated inputs.
  o Regarding django: see below
  * * postorius: okay (this is an application, so no propagated inputs
are required)


And as we just learned about the licenses: python-django-mailman3 should
be gpl3+


I'm unsure about the correct handling of django in django-XXX. Can we
find rules for this to make future packager's life easier?

Should django be a "normal" input or a "native" one? What does this
depend on?


Clear is: django-XXX should not "propagate" django:

  * django is a framework, django-XXX is an extension for this framework.
  * If some application is using django-XXX, I'd expect it to have
django specified as "input", too, since primary it is a django
application. Maybe even djangoXXX is an optional component


Just for the records:

  * django-XXX should propagate other django extension it requires.
  o If some application is using django-XXX, if should not care
about other django extensions django-XXX requires. This is the
same like as it does not have to care about other python
packages django-XXX requires.


-- 
Regards
Hartmut Goebel

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



0xBF773B65.asc
Description: application/pgp-keys

Re: [PATCH 3/7] gnu: Add python2-ruamel.ordereddict

[Hartmut Goebel]

Am 02.02.2017 um 05:53 schrieb Maxim Cournoyer:
> Maybe the comment should say "No ordereddict python3 build available" ?

This should be something like "No Python 3 implementation of this
package available.", otherwise it would be very confusing.
"Collections.OrderedDict" is part of the Python standard library since
2.7 and 3.1. Further there is a package "ordereddict".

-- 
Regards
Hartmut Goebel

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

Re: [PATCH 6/7] gnu: Add python-ruamel.yaml.

[Hartmut Goebel]

Am 02.02.2017 um 05:42 schrieb Maxim Cournoyer:
> I've looked at this patch series and it looks good so far

The inputs need to be adjusted to become either native or propagated.

-- 
Regards
Hartmut Goebel

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

Re: [PATCH 3/7] gnu: Add python2-ruamel.ordereddict

[ng0]

Hi,

Maxim Cournoyer writes:

> Hi,
>
> I have a few of comments for this one too.
>
> contact@cryptolab.net writes:
>
>> From: ng0 
>>
>> * gnu/packages/python.scm (python2-ruamel.ordereddict): New variable.
>> ---
>>  gnu/packages/python.scm | 28 
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
>> index f6516d26b..cef9d2a8c 100644
>> --- a/gnu/packages/python.scm
>> +++ b/gnu/packages/python.scm
>> @@ -583,6 +583,34 @@ the Python logging module that outputs records using 
>> terminal colors.")
>>(native-inputs
>> `(("python2-setuptools" ,python2-setuptools))
>>  
>> +(define-public python2-ruamel.ordereddict
>> +  (package
>> +(name "python2-ruamel.ordereddict")
>> +(version "0.4.9")
>> +(source
>> + (origin
>> +   (method url-fetch)
>> +   (uri (pypi-uri "ruamel.ordereddict" version))
>> +   (sha256
>> +(base32
>> + "1xmkl8v9l9inm2pyxgc1fm5005yxm7fkd5gv74q7lj1iy5qc8n3h"
>> +(build-system python-build-system)
>> +;; XXX: https://bitbucket.org/ruamel/ordereddict/issues/2
>
> Maybe the comment should say "No ordereddict python3 build available" ?
>
>> +(arguments
>> + `(#:python ,python-2))
>> +(inputs
>> + `(("python2-setuptools" ,python2-setuptools)))
>
> Unnecessary, part of our Python2 package.

Yes, as I wrote I did not review it again. This is from back in
September, before the build system was changed. I forgot about
tinycm in the list-email: This is dropped too. I have no way to
fix this. The patches will still apply (rebased on master), so
anyone who wants to fix this can fix these python packages.

>> +(home-page "https://bitbucket.org/ruamel/ordereddict;)
>> +(synopsis "Version of @code{dict} that keeps keys in insertion
>> +resp. sorted order")
>> +(description
>> + "This is an implementation of an ordered dictionary with Key
>> +Insertion Order and Key Value Insertion Order.  The standard library
>
> Is the capitalization of Key Insertion Order/Key Value Insertion Order
> really necessary? Also, there are 2 spaces following the period.
>
>> +module OrderedDict, implemented later, implements a subset of
>> +ordereddict functionality.  Sorted dictionaries are also provided.
>
> 2 spaces following the period here also. Is this intended?
>
>> +Currently only with Key Sorted Order.")
>
> Again, I'm not sure about the proper capitalization here.
>
> Thanks,
>
> Maxim


-- 
ng0 . https://www.inventati.org/patternsinthechaos/

Re: [PATCH] gnu: Add no-more-secrets.

[ng0]

Eric Bavier writes:

> On Wed,  1 Feb 2017 02:07:28 +
> contact@cryptolab.net wrote:
>
>> * gnu/packages/art.scm: New file.
>> * gnu/local.mk (GNU_SYSTEM_MODULES): Add art.
>
> Would gnu/packages/games.scm or gnu/packages/graphics.scm be a suitable
> location for no-more-secrets?
>
> `~Eric

I think it could be considered a game, not an interactive one,
but it qualifies as a game in my opinion.

I will move it to (gnu packages games).
-- 
ng0 . https://www.inventati.org/patternsinthechaos/

Re: Structured list of my patches

[ng0]

Pjotr Prins writes:

> Thanks ng0,
>
> Embarrassing.

I don't agree, but okay.

> At FOSDEM I'll bring up the topic again of our submission system. Good
> topic for the 'Future of Guix' panel.

I have ideas, as I made some further investigations over the last
months into source code managements and issue/bug tracking
systems, but I think at this point it's better a discussion that
we should have in an meeting (AFK/IRL) and not per email/irc
discussion. It requires no immediate solution, but we could meet
this summer?
I'm also curious about the input and results from chats and
discussions at FOSDEM, can you (or someone else) try to make an
protocol or some other quick format of notes to publish?

Among other things I discovered features of Mantis 2.0 (close
bugs via some keyword in git commits!), I discovered tuleap
(https://www.tuleap.org/), pagure (https://pagure.io/pagure ,
https://fedoramagazine.org/pagure-diy-git-project-hosting/ ) and
thought a bit more about the review situation which is also
rooted in the fact that much more people contribute than review.
My personal contribution to help the current review situation is
to do at least one review per week now.

Now for this long list of patches (I know I don't have to explain
myself, but it's probably appropriate in this case): I evaluate
what I do regulary, and the result was that realized that I got
off the road(map) a bit. This chaos is the reason everything
roadmap related is at 80% but the last 20% were suffering from
distraction.

> Pj.
>
> On Thu, Feb 02, 2017 at 12:26:08AM +, ng0 wrote:
>> Recently I started to sent 3 classes of patches, and hoped that
>> the coverletters description would help. Apparently it doesn't.
>> 
>> I will add the lists.gnu.org archive links as I don't think the
>> majority of people here can search for mailids with their mail
>> readers.
>> 
>> I am pretty sure I missed some patches, but that's it for now.
>> Looking at the public[0] part of my branches, I have about 15-20
>> more batches of packages I must drop/finish/get rid off so that I
>> can focus on my work again.
>> 
>> * Patches which need QA review (considered DONE from my side)
>> 
>>   * no-more-secrets
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02365.html
>>   * sedsed
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02336.html
>>   * libextractor inputs
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02319.html
>>   * blists
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02316.html
>>   * tinycm
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02308.html
>>   * python-pykka (I won't debbug the testsuite and will drop this
>> at the end of the month, but I am willing apply small
>> changes)
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02272.html
>>   * mbedtls, hiawatha
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02105.html
>>   * Murmur (mumble server)
>> https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00021.html
>>   * emacs-pretty-mode
>> https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00017.html
>>   * lush2
>>   * scsh
>>   * shadow (update)
>> 
>> * Patches which are dropped from my tree (ie: deleted), free for
>>   others to pick up
>> 
>>   * supercollider
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02284.html
>>   * Krita
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02294.html
>>   * GNOME evolution
>> 
>> * Patches which are status: RFC
>> 
>>   * sway
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02345.html
>>   * debbugs (currently debbuging this, but comments are welcome)
>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg02110.html
>> 
>> 
>> 
>> 
>> [0]: https://pagure.io/guix-dev
>> -- 
>> ng0 . https://www.inventati.org/patternsinthechaos/
>> 


-- 
ng0 . https://www.inventati.org/patternsinthechaos/

Re: [PATCH] gnu: Add emacs-pretty-mode.

[Alex Kost]

contact@cryptolab.net (2017-02-01 18:08 +) wrote:

> From: ng0 
>
> * gnu/packages/emacs.scm (emacs-pretty-mode): New variable.
> ---
>  gnu/packages/emacs.scm | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index df7f7869d..a51b5de1d 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -3778,3 +3778,26 @@ customizable by the user.")
>  Additionally it can display the number of unread emails in the
>  mode-line.")
>  (license license:gpl3+)))
> +
> +(define-public emacs-pretty-mode
> +  (let ((commit "500085206e25b98d00b9ec996f91c87ba569c4ce")
> +(revision "1"))
> +  (package
> +(name "emacs-pretty-mode")
> +(version (string-append "2.0.3-" revision "." (string-take commit 7)))
> +(source
> + (origin
> +   (method git-fetch)
> +   (uri (git-reference
> + (url "https://github.com/akatov/pretty-mode;)
> + (commit commit)))

Why git commit, and not the latest snapshot?

https://github.com/akatov/pretty-mode/archive/2.0.3.tar.gz

> +   (file-name (string-append name "-" version "-checkout"))
> +   (sha256
> +(base32
> + "0m7ii971zxlz8a9yx2ljf9fmd8k6hc9w1q8mi5xi32v9viccjabs"
> +(build-system emacs-build-system)
> +(home-page "https://github.com/akatov/pretty-mode;)
> +(synopsis "Redisplay parts of the buffer as pretty Unicode symbols.")
> +(description
> + "Emacs minor mode for redisplaying parts of the buffer as pretty 
> symbols.")
> +(license license:gpl3+


-- 
Alex

Re: [PATCH v2] gnu: Add dub-build-system.

[Danny Milosavljevic]

Hi Ludo,

> Do you have experience using it on real DUB packages?  IOW, how complete
> is it?  :-)

Yeah, I've tested it on a small subset of all code.dlang.org packages. About 
half of the ones I tested work fine. This is my log:

OK: (define-public d-taggedalgebraic
OK: (define-public d-memutils
NOT: (define-public d-libasync unittest failure
NOT: (define-public d-eventcore by libasync
OK: (define-public tsv-utils-dlang [bin directory?!]
OK: (define-public d-lapack
OK: (define-public d-cblas
OK: (define-public d-money
NOT: (define-public d-units-d unit tests fail
OK: (define-public d-libevent
NOT anymore: (define-public d-llvm-d
OK: (define-public d-htmld
OK: (define-public d-cssd
OK: (define-public d-openssl
NOT: (define-public d-mail can't find [d-]openssl
NOT: (define-public d-secured can't find [d-]openssl
NOT: (define-public d-botan-math [tests crash]
NOT: (define-public d-botan [dependency on d-botan-math - which will fail]
OK: (define-public d-urld
OK: (define-public isitthere
NOT: (define-public d-imaged ; dependency on undead which is probably bad.
OK: (define-public d-matplotlib-d [huge deps]
NOT: (define-public d-universal ; tests fail
NOT: (define-public d-future ; requires d-universal - which will fail
OK: (define-public d-docopt
NOT: (define-public d-requests ; depends on d-vibe-d - which will fail
OK: (define-public d-concepts
OK: (define-public d-gtk-d ; missing gdata
NOT: (define-public d-pyd ; Python 2 should be UCS-4 but isn't.
NOT: (define-public d-vibe-core ; depends on libasync - which will fail
NOT: (define-public d-vibe-d ; depends on d-libevent 2.0.1 - which it can't 
find for some reason
OK: (define-public d-derelict-util
NOT: (define-public d-derelict-sdl2 ; tries to write into d-derelict-util's 
immutable directory
NOT: (define-public d-derelict-ft ; tries to write into d-derelict-util's 
immutable directory
NOT: (define-public d-bdb2d ; unknown error 6995216
NOT: (define-public unde ; depends on d-bdb2d - which will fail
OK: (define-public d-wave-d
OK: (define-public d-assert-that
OK: (define-public d-compile-time-unittest
NOT: (define-public d-tcenal ; requires d-compile-time-unittest 0.0.3 but can't 
find it for some reason
NOT: (define-public d-libdparse ; requires newer ldc (requires ldc 1.1.0)
NOT: (define-public dfmt ; requires d-libdparse - which will fail.
???: (define-public d-antispam
???: (define-public d-userman
???: (define-public vibenews
OK: (define-public d-syscall-d
OK: (define-public d-quantities

And I've attached the actual package definitions (these are WIP).

>For the final patch, could you add a short description under “Build Systems” 
>in guix.texi?

Sure.

>You can remove keyword parameters that don’t make sense like this one.

Yeah, but maybe I should use them instead. Will investigate :)

>s/Rust/DUB/  :-)

Whoops, thanks :)

>Rather: (chmod "." #o755).

Thanks. Note that it's a workaround because git-download leaves the build 
directory read-only for some reason. Should the problem be found and fixed 
there? Or is it on purpose?

>“vendor”?

Yeah, a Rust term which I reused here. It means a directory with all the 
bundled dependencies (here we symlink the dependencies from our store 
dynamically).

>Could you add a comment above explaining why this needs to be done?

Sure. (it prepares a directory which can be used to find all the (D) 
dependencies by going just one level down; earlier versions just used 
/gnu/store directly but that would mean if you put such a package (without any 
subdirs in it) into your profile it would pollute the root)

I'm just thinking out loud about the comment :)

Something like this?

;; Prepare one new directory with all the required dependencies.
;; It's necessary to do this (instead of just using /gnu/store as the 
directory) because we want to hide the libraries in subdirectories lib/dub/... 
instead of polluting the user's profile root.

>> +  ;(setenv "CC" (string-append (assoc-ref inputs "gcc") "/bin/gcc"))  
>Remove.

Ok.

>If HOME is relied on, please add a comment explaining why.

The dub build system uses it to find or create the .dub directory wherein it 
puts everything it built. I've found the place in DUB where one could patch 
that out: In source/dub/dub.d it says:

private void init()
{
import std.file : tempDir;
version(Windows) {
m_dirs.systemSettings = 
Path(environment.get("ProgramData")) ~ "dub/";
m_dirs.userSettings = Path(environment.get("APPDATA")) 
~ "dub/";
} else version(Posix){
m_dirs.systemSettings = Path("/var/lib/dub/");
m_dirs.userSettings = Path(environment.get("HOME")) ~ 
".dub/";
if (!m_dirs.userSettings.absolute)
m_dirs.userSettings = Path(getcwd()) ~ 
m_dirs.userSettings;
}

m_dirs.temp = Path(tempDir);

m_config = new 

Re: [PATCH] gnu: magit: Update to 2.10.1.

[Alex Kost]

Ludovic Courtès (2017-02-01 23:52 +0100) wrote:

> Clément Lassieur  skribis:
>
>> * gnu/packages/emacs.scm (magit): Update to 2.10.1.
>
> Applied, thanks!

No, no, arrgh!  I didn't update magit to 2.10.1 because it has a bug
that makes "C" key in COMMIT_EDITMSG buffer unusable, as discussed at
.

Also note that along with magit, 'emacs-magit-popup' should be updated
(this time it wasn't needed as "magit-popup.el" wasn't touched in this
release), and it is also good to update 'emacs-with-editor' as this
library was written specifically for magit (it was a part of magit in
the past).

-- 
Alex

Re: [PATCH] gnu: Add emacs-mew.

[Alex Kost]

Thomas Danckaert (2017-02-01 11:56 +0100) wrote:

>> Also I see that by default it puts image files into
>> "share/emacs/site-lisp/mew/etc".  I don't think this is a good
>> place, I would rather move them to "share/mew" as most packages do
>> with various additional files.
>
> Yes, that would be cleaner.  Is there also a clean way to add
> share/mew to emacs' image-load-path?  The problem is that the package
> needs various *.xpm icon's, which are opened with “find-image” (via
> “tool-bar-add-item”), which looks on image-load-path, whereas
> “Mew-icon.png” is looked up in mew-icon-directory.

OK, I see.  We can just patch "mew-key.el" file by putting the following
line there:

  (add-to-list 'image-load-path 'mew-icon-directory)

WDYT?

> My patch as originally intended (now attached) puts everything in
> share/emacs/site-lisp/guix.d/mew, where find-image will find it, and
> patches mew-key.el so it also looks in that directory.  Not clean, but
> it works :-)

I think it's rather messy having all elisp and image files in a single
directory, I would prefer to modify 'image-load-path', and to put these
images either in "share/mew" on in a sub-dir of the mew elisp dir.

> From 175d5b859c5615157db51ab79fa059e397a7f2b9 Mon Sep 17 00:00:00 2001
> From: Thomas Danckaert 
> Date: Tue, 24 Jan 2017 09:41:42 +0100
> Subject: [PATCH] gnu: Add emacs-mew.
>
> * gnu/packages/mail.scm (emacs-mew): New variable.
> ---
>  gnu/packages/mail.scm | 38 ++
>  1 file changed, 38 insertions(+)
>
> diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
> index 2318ae9b6..80a61a141 100644
> --- a/gnu/packages/mail.scm
> +++ b/gnu/packages/mail.scm
> @@ -20,6 +20,7 @@
>  ;;; Copyright © 2016 Arun Isaac 
>  ;;; Copyright © 2016 John Darrington 
>  ;;; Copyright © 2016 Marius Bakke 
> +;;; Copyright © 2017 Thomas Danckaert 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -79,6 +80,7 @@
>#:use-module (gnu packages flex)
>#:use-module (gnu packages gdb)
>#:use-module (gnu packages man)
> +  #:use-module (gnu packages ruby)
>#:use-module (gnu packages samba)
>#:use-module (gnu packages screen)
>#:use-module (gnu packages tls)
> @@ -377,6 +379,42 @@ can read the same mailbox from multiple computers.  It 
> supports IMAP as REMOTE
>  repository and Maildir/IMAP as LOCAL repository.")
>  (license gpl2+)))
>  
> +(define-public emacs-mew
> +  (package
> +  (name "emacs-mew")
> +  (version "6.7")
> +  (source
> +(origin
> +  (method url-fetch)
> +  (uri (string-append "http://mew.org/Release/mew-; version ".tar.gz"))
> +  (sha256
> +   (base32
> +"03fzky2kz73vgx4cbps2psbbnrgqgkk5q7jwfldisymkzr9iz03y"
> +  (inputs
> +   `(("emacs" ,emacs-minimal)))
> +  (propagated-inputs
> +   `(("ruby-sqlite3" ,ruby-sqlite3) ; optionally uses an sqlite database of 
> messages
> + ("ruby" ,ruby))) ; to set GEM_PATH so ruby-sqlite3 is found at runtime
> +  (build-system gnu-build-system)
> +  (arguments
> +   `(#:configure-flags
> + (let ((elispdir (string-append (assoc-ref %outputs "out")
> + "/share/emacs/site-lisp/guix.d/mew")))
> +   (list (string-append "--with-elispdir=" elispdir)
> + (string-append "--with-etcdir=" elispdir)))
> + #:phases (modify-phases %standard-phases
> +(add-after 'configure 'patch-mew-icon-path ; ensure 
> "Mew-icon.png" is found.
> +   (lambda _
> + (substitute* "mew-key.el"
> +   (("\\(expand-file-name \"etc\" path\\)") 
> "path")

I insist on patching 'mew-icon-directory' instead as I suggested.  Or
are there any problems with it?

Also you seem to overlook my comment about autoloads.  My version of
your patch (attached in my previous message) contains a phase to
generate "mew-autoloads.el".  This file is really needed to have "M-x
mew" command available by default.  Otherwise, a user has to put:

  (autoload 'mew "mew" nil t)

in his/her emacs config.

> + #:tests? #f))
> +  (home-page "http://www.mew.org;)
> +  (synopsis "Emacs e-mail client")
> +  (description "Mew (Messaging in the Emacs World) is a user interface
> +for text messages, multimedia messages (MIME), news articles and
> +security functionality including PGP, S/MIME, SSH, and SSL.")
> +  (license bsd-3)))
> +
>  (define-public mu
>(package
>  (name "mu")

-- 
Alex

Re: [PATCH 0/2] Add load-path support to cuirass.

[Ludovic Courtès]

Hello,

Mathieu Othacehe  skribis:

> The point of the serie is to add load-path support to cuirass.
> The first patch is updating cuirass to a version containing this commit :
>
> https://notabug.org/mthl/cuirass/commit/5127c6797ca6eb5782f96f44c7c1d38263927f2b
>
> The second patch adds support for load-path option in guix's cuirass service
> configuration.
>
> Thanks,
>
> Mathieu
>
> Mathieu Othacehe (2):
>   gnu: cuirass: Update to 0.0.1 revision 4.
>   services: cuirass: Add load-path to cuirass configuration

Applied both.  Good to see improvements in this area!

Thank you!

Ludo’.