Re: [PATCH 5/5] guix: python-build-system: Fix an outdated comment.

[Hartmut Goebel]

Am 12.10.2016 um 18:03 schrieb Leo Famulari:
>> >  (define %standard-phases
>> > -  ;; 'configure' and 'build' phases are not needed.  Everything is done 
>> > during
>> > -  ;; 'install'.
>> > +  ;; 'configure' phase is not needed.
> I have no real comment because I don't know the python-build-system well
> enough. Is the sentence about 'install' no longer accurate?

The python-build-system uses the build and the install phase, but not
the configure phase. So the old comment was plain wrong. I assume once
only the install phase was used[*] and the comment has had been correct :-)

Which is possible and much like running "make install" without prior run
to "make".

-- 
Regards
Hartmut Goebel

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

Re: [WIP v3 0/5] Update Sphinx to 1.4.8

[Danny Milosavljevic]

On Thu, 13 Oct 2016 08:45:51 +0200
Danny Milosavljevic  wrote:
> Upstream issue: https://github.com/sphinx-doc/sphinx/issues/3044

There's a newer version of Matplotlib which has a reference cycle matplotlib <- 
ipython <- matplotlib. Sigh...

Re: [PATCH] gnu: mail: Add notifymuch.

[Hartmut Goebel]

Am 12.10.2016 um 20:17 schrieb Christopher Baines:
>>> +(description "notifymuch displays desktop notifications for
>>> messages in
>>> +the notmuch database.  The notifications are sent using libnotify to a
>>
>> May I ask you to ass some words about what notmuch is? This saves the
>> ingenuous reader to recherché what notmuch is. Thanks.
>
> I'm not quite sure how to improve on this. Copying in the full package
> description for notmuch looks out of place to me, and I'm not sure if
> just saying "the notmuch email database" instead of "the notmuch
> database" is sufficient?
>

IC, this is a complicated one, since notmuch seems to be a framework. I
have to admit that I did not know about notmuch until just now.
Explaining about what notmuch is would indeed disrupt the description.
So I'd say your suggestion is okay, since it give the ingenuous reader
at least a hint.

(synopsis "Displays notifications for changes in the notmuch email
database")


-- 
Regards
Hartmut Goebel

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

Re: Please set up Hydra channel for new python-build-system (was: [PATCH 00/14] Change python-build-system (fixes bug 20765))

[Vincent Legoll]

Hello,

On Wed, Oct 12, 2016 at 4:51 PM, Leo Famulari  wrote:
> The core Python packages are *extremely* tangled up in each other. Help
> wanted

Can you explain a bit what that would involve, what one can do to help, etc...

-- 
Vincent Legoll

Adding rottlog service in ‘%base-services’?

[Ludovic Courtès]

Hello Guix!

Should we add rottlog-service and thus mcron-service to
‘%base-services’?  Is log rotation a basic feature that people expect?
WDYT?

If we do so, we would need to document a way to add mcron jobs from the
‘operating-system’ declaration.  People would no longer be able to write
something like this in the ‘services’ field:

  (service mcron-service-type
   (mcron-configuration (jobs (list job1 job2 …

Instead, they’d write something like:

  (mcron-jobs (list job1 job2 …))

where:

  (define (mcron-jobs jobs)
(simple-service 'user-mcron-jobs mcron-service-type jobs))

Thoughts?

Ludo’.

Re: [PATCH 4/5] gnu: python.scm: Update some home-page urls and descriptions.

[Hartmut Goebel]

Am 12.10.2016 um 18:01 schrieb Leo Famulari:
> On Mon, Oct 10, 2016 at 03:10:02PM +0200, Hartmut Goebel wrote:
>> > * gnu/packages/python.scm (python-keyring, python-pylockfile): Update
>> >   home-page url. (python-pathlib): Update description.
> This should really be separate commits :)
>

How many? Three?

-- 
Regards
Hartmut Goebel

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

Re: Adding rottlog service in ‘%base-services’?

[ng0]

Ludovic Courtès  writes:

> Hello Guix!
>
> Should we add rottlog-service and thus mcron-service to
> ‘%base-services’?  Is log rotation a basic feature that people expect?
> WDYT?

What's the size of mcron and its dependency graph of unique packages
which aren't already pulled in through %base-services?

> If we do so, we would need to document a way to add mcron jobs from the
> ‘operating-system’ declaration.  People would no longer be able to write
> something like this in the ‘services’ field:
>
>   (service mcron-service-type
>(mcron-configuration (jobs (list job1 job2 …
>
> Instead, they’d write something like:
>
>   (mcron-jobs (list job1 job2 …))
>
> where:
>
>   (define (mcron-jobs jobs)
> (simple-service 'user-mcron-jobs mcron-service-type jobs))
>
> Thoughts?
>
> Ludo’.
>
>

-- 

Re: Adding rottlog service in ‘%base-services’?

[Vincent Legoll]

Hello,

On Thu, Oct 13, 2016 at 10:24 AM, Ludovic Courtès  wrote:
> Should we add rottlog-service and thus mcron-service to ‘%base-services’?

I'd say no, or do like OS configurations and provide a %bare-bones-services,
or do it the other way, provide an optional %default-services which adds to
%base-services...

> Is log rotation a basic feature that people expect?

I'd say yes, probably only the embeded people would like a bare-bones system...

-- 
Vincent Legoll

Re: Adding rottlog service in ‘%base-services’?

[David Craven]

> Should we add rottlog-service and thus mcron-service to
> ‘%base-services’?  Is log rotation a basic feature that people expect?
> WDYT?

Why not. There's two sorts of people. The ones that don't care/know
will be happy when things just work and the ones that care/know are
probably defining their own %base-services anyway...

> If we do so, we would need to document a way to add mcron jobs from the
> ‘operating-system’ declaration.  People would no longer be able to write
> something like this in the ‘services’ field.

Mmh... If we do something like this we shouldn't call it mcron-jobs,
otherwise we'll have the same problems like with grub - where all
variables are named grub or grub? or grub.cfg. How about just calling
it jobs?

[PATCH] gnu: Add hdf-eos2.

[Thomas Danckaert]

Hi guix,

this patch adds HDF-EOS2 (which, somewhat confusingly, is completely 
independent from HDF-EOS5).


I'm not sure what the best version name is.  The tarball is
HDF-EOS2.19v1.00.tar.Z, but documentation sometimes refers to it as
“version 2.19”.  The 2 is part of the library name, though, so I went
with (version "19.1.0") in the end :-).  Is there a policy for version
labeling in Guix, and would (version "19v1.00") be ok?

Thomas
>From 53f69f5b4f0931b259ddd41ef25fc88a2ec6c26a Mon Sep 17 00:00:00 2001
From: Thomas Danckaert 
Date: Fri, 30 Sep 2016 09:59:08 +0200
Subject: [PATCH] gnu: Add hdf-eos2.

* gnu/packages/maths.scm (hdf-eos2): New variable.
* gnu/packages/patches/hdf-eos2-build-shared.patch: New file.
* gnu/packages/patches/hdf-eos2-remove-gctp.patch: New file.
* gnu/packages/patches/hdf-eos2-fortrantests.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add patches.
---
 gnu/local.mk |   3 +
 gnu/packages/maths.scm   |  35 +++
 gnu/packages/patches/hdf-eos2-build-shared.patch |  23 ++
 gnu/packages/patches/hdf-eos2-fortrantests.patch | 329 +++
 gnu/packages/patches/hdf-eos2-remove-gctp.patch  |  55 
 5 files changed, 445 insertions(+)
 create mode 100644 gnu/packages/patches/hdf-eos2-build-shared.patch
 create mode 100644 gnu/packages/patches/hdf-eos2-fortrantests.patch
 create mode 100644 gnu/packages/patches/hdf-eos2-remove-gctp.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 521ba2d..3e1348d 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -581,6 +581,9 @@ dist_patch_DATA =		\
   %D%/packages/patches/hdf4-shared-fortran.patch 		\
   %D%/packages/patches/hdf4-reproducibility.patch 		\
   %D%/packages/patches/hdf5-config-date.patch			\
+  %D%/packages/patches/hdf-eos2-build-shared.patch 		\
+  %D%/packages/patches/hdf-eos2-remove-gctp.patch		\
+  %D%/packages/patches/hdf-eos2-fortrantests.patch		\
   %D%/packages/patches/hdf-eos5-build-shared.patch 		\
   %D%/packages/patches/hdf-eos5-remove-gctp.patch		\
   %D%/packages/patches/hdf-eos5-fix-szip.patch			\
diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 07934e3..fd096b7 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -543,6 +543,41 @@ extremely large and complex data collections.")
 (license (license:x11-style
   "http://www.hdfgroup.org/ftp/HDF5/current/src/unpacked/COPYING";
 
+(define-public hdf-eos2
+  (package
+(name "hdf-eos2")
+(version "19.1.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri "ftp://edhs1.gsfc.nasa.gov\
+/edhs/hdfeos/latest_release/HDF-EOS2.19v1.00.tar.Z")
+   (sha256
+(base32 "0c9fcz25s292ldap12wxmlrvnyz99z24p63d8fwx51bf8s0s1zrz"))
+   (patches (search-patches "hdf-eos2-remove-gctp.patch"
+"hdf-eos2-build-shared.patch"
+"hdf-eos2-fortrantests.patch"
+(build-system gnu-build-system)
+(native-inputs
+ `(("gfortran" ,gfortran)))
+(inputs
+ `(("hdf4" ,hdf4-alt) ; assume most HDF-EOS2 users won't use the HDF4 netCDF API
+   ("zlib" ,zlib)
+   ("libjpeg" ,libjpeg)
+   ("gctp" ,gctp)))
+(arguments
+ `( #:configure-flags '("--enable-install-include" "--enable-shared"
+"CC=h4cc -Df2cFortran" "LIBS=-lgctp")
+#:parallel-tests? #f))
+(home-page "http://hdfeos.org/software/library.php#HDF-EOS2";)
+(synopsis "HDF4-based data format for NASA's Earth Observing System")
+(description "HDF-EOS2 is a software library built on HDF4 which supports
+the construction of data structures used in NASA's Earth Observing
+system (Grid, Point and Swath).")
+
+;; Source files carry a permissive license header.
+(license (license:non-copyleft home-page
+
 (define-public hdf-eos5
   (package
 (name "hdf-eos5")
diff --git a/gnu/packages/patches/hdf-eos2-build-shared.patch b/gnu/packages/patches/hdf-eos2-build-shared.patch
new file mode 100644
index 000..2197296
--- /dev/null
+++ b/gnu/packages/patches/hdf-eos2-build-shared.patch
@@ -0,0 +1,23 @@
+diff --git a/src/Makefile.in b/src/Makefile.in
+index 9534473..12411bf 100644
+--- a/src/Makefile.in
 b/src/Makefile.in
+@@ -73,7 +73,7 @@ LTCOMPILE = $(LIBTOOL) --mode=compile --tag=CC $(CC) $(DEFS) \
+ 	$(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
+ 	$(AM_CFLAGS) $(CFLAGS)
+ CCLD = $(CC)
+-LINK = $(LIBTOOL) --mode=link --tag=CC $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++LINK = HDF4_USE_SHLIB=yes $(LIBTOOL) --mode=link --tag=CC $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
+ 	$(AM_LDFLAGS) $(LDFLAGS) -o $@
+ SOURCES = $(libhdfeos_la_SOURCES)
+ DIST_SOURCES = $(libhdfeos_la_SOURCES)
+@@ -125,8 +125,6 @@ INSTALL_PROGRAM = @INSTALL_PROGRAM@
+ INSTALL_SCRIPT = @INSTALL_SCRIPT@
+ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
+ 
+-# Set LDFLAGS to alow the HDF-EOS library to use extern variables from HDF4
+-LDFLAGS = -Wl,-single_module
+ LIBO

[PATCH v2 4/7] gnu: python-pylockfile: Update home-page url.

[Hartmut Goebel]

* gnu/packages/python.scm (python-pylockfile, python2-pylockfile): Update
  home-page url.
---
 gnu/packages/python.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index ec56c85..a1c2088 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -763,7 +763,7 @@ concepts.")
 (arguments '(#:test-target "check"))
 (native-inputs
  `(("python-pbr" ,python-pbr)))
-(home-page "http://code.google.com/p/pylockfile/";)
+(home-page "https://launchpad.net/pylockfile";)
 (synopsis "Platform-independent file locking module")
 (description
  "The lockfile package exports a LockFile class which provides a simple
-- 
2.7.4

[PATCH v2 5/7] gnu: python-keyring: Update home-page url.

[Hartmut Goebel]

* gnu/packages/python.scm (python-keyring, python2-keyring): Update home-page
  url.
---
 gnu/packages/python.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index a1c2088..c890c68 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -900,7 +900,7 @@ etc.).  The package is structured to make adding new 
modules easy.")
  `(("python-pycrypto" ,python-pycrypto)))
 (arguments
  `(#:tests? #f))  ;TODO: tests require pytest
-(home-page "http://bitbucket.org/kang/python-keyring-lib";)
+(home-page "https://github.com/jaraco/keyring";)
 (synopsis "Store and access your passwords safely")
 (description
  "The Python keyring lib provides a easy way to access the system keyring
-- 
2.7.4

[PATCH v2 0/7] Updated: Some simple or even trivial changes.

[Hartmut Goebel]

Hi,

hopefully I got all requested changes.

 * The updates for urls and descriptions I split into three commits. Hope this
   is wat you wanted.
 * I added to remove the duplicate definition of python2-msgpack, too. I uses
   one commit for, hope this is okay, too.

Hartmut Goebel (7):
  gnu: python2-pytest-runner, python2-msgpack: Remove duplicate
definitions.
  gnu: python-pytest-xdist: Remove python byte-code files from source.
  gnu: python-zope-testing: Strip byte-code and backup-files from
source.
  gnu: python-pylockfile: Update home-page url.
  gnu: python-keyring: Update home-page url.
  gnu: python-pathlib: Update description.
  guix: python-build-system: Fix an outdated comment.

 gnu/packages/python.scm| 35 ---
 guix/build/python-build-system.scm |  3 +--
 2 files changed, 25 insertions(+), 13 deletions(-)

-- 
2.7.4

[PATCH] gnu: Add python2-pathlib2.

[Hartmut Goebel]

Adding only the Python 2 variant, since for Python 3 our minimum version
is 3.4 which already includes this package as part of the standard library.

gnu/packages/python.scm (python2-pathlib2): New variable.
---
 gnu/packages/python.scm | 36 
 1 file changed, 36 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 6207896..a4c0b92 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -8860,6 +8860,42 @@ anymore.")
 (define-public python2-pathlib
   (package-with-python2 python-pathlib))
 
+(define-public python2-pathlib2
+  (package
+(name "python2-pathlib2")
+(version "2.1.0")
+(source (origin
+  (method url-fetch)
+  (uri (pypi-uri "pathlib2" version))
+  (sha256
+   (base32
+"0p050msg5c8d0kadv702jnfshaxrb0il765cpkgnhn6mq5hakcyy"
+(build-system python-build-system)
+(arguments
+ `(#:python ,python-2))
+(native-inputs
+ `(("python2-setuptools" ,python2-setuptools)
+   ("python2-six" ,python2-six)))
+(home-page "http://pypi.python.org/pypi/pathlib2/";)
+(synopsis "Object-oriented file system paths - backport of standard
+pathlib module")
+(description "The goal of pathlib2 is to provide a backport of standard
+pathlib module which tracks the standard library module, so all the newest
+features of the standard pathlib can be used also on older Python versions.
+
+Pathlib offers a set of classes to handle file system paths.  It offers the
+following advantages over using string objects:
+
+@enumerate
+@item No more cumbersome use of os and os.path functions.  Everything can
+be done easily through operators, attribute accesses, and method calls.
+@item Embodies the semantics of different path types.  For example,
+comparing Windows paths ignores casing.
+@item Well-defined semantics, eliminating any inconsistencies or
+ambiguities (forward vs. backward slashes, etc.).
+@end enumerate")
+(license license:expat)))
+
 (define-public python-jellyfish
   (package
 (name "python-jellyfish")
-- 
2.7.4

[PATCH v2 2/7] gnu: python-pytest-xdist: Remove pre-compiled .pyc files from source.

[Hartmut Goebel]

* gnu/packages/python.scm (python-pytest-xdist,
  python2-pytest-xdist)[source]: Add snippet.
---
 gnu/packages/python.scm | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 3c3a00c..eca60bc 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1764,7 +1764,15 @@ same arguments.")
(uri (pypi-uri "pytest-xdist" version ".zip"))
(sha256
 (base32
- "08rn2l39ds60xshs4js787l84pfckksqklfq2wq9x8ig2aci2pja"
+ "08rn2l39ds60xshs4js787l84pfckksqklfq2wq9x8ig2aci2pja"))
+   (modules '((guix build utils)))
+   (snippet
+'(begin
+   ;; Remove pre-compiled .pyc files from source.
+   (for-each delete-file-recursively
+ (find-files "." "__pycache__" #:directories? #t))
+   (for-each delete-file (find-files "." "\\.pyc$"))
+   #t
 (build-system python-build-system)
 (native-inputs
  `(("unzip" ,unzip)
-- 
2.7.4

[PATCH v2 7/7] guix: python-build-system: Fix an outdated comment.

[Hartmut Goebel]

The python-build-system uses phases the build and install, but not
configure. So the old comment was plain wrong since Sept. 2013, when the build
phase has been added.
---
 guix/build/python-build-system.scm | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/guix/build/python-build-system.scm 
b/guix/build/python-build-system.scm
index 9109fb4..e906e60 100644
--- a/guix/build/python-build-system.scm
+++ b/guix/build/python-build-system.scm
@@ -137,8 +137,7 @@ installed with setuptools."
 #t))
 
 (define %standard-phases
-  ;; 'configure' and 'build' phases are not needed.  Everything is done during
-  ;; 'install'.
+  ;; 'configure' phase is not needed.
   (modify-phases gnu:%standard-phases
 (add-after 'unpack 'ensure-no-mtimes-pre-1980 ensure-no-mtimes-pre-1980)
 (delete 'configure)
-- 
2.7.4

[PATCH v2 1/7] gnu: python2-pytest-runner, python2-msgpack: Remove duplicate definitions.

[Hartmut Goebel]

* gnu/packages/python.scm (python2-pytest-runner): Was defined twice, remove
  duplicate definition. (python2-msgpack): Was defined twice, but differently,
  remove the obviously wrong second definition.
---
 gnu/packages/python.scm | 6 --
 1 file changed, 6 deletions(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index a9fd8eb..3c3a00c 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1715,9 +1715,6 @@ supports coverage of subprocesses.")
   (native-inputs `(("python2-setuptools" ,python2-setuptools)
,@(package-native-inputs base))
 
-(define-public python2-pytest-runner
-  (package-with-python2 python-pytest-runner))
-
 (define-public python-pytest-mock
   (package
 (name "python-pytest-mock")
@@ -5754,9 +5751,6 @@ reading and writing MessagePack data.")
 (native-inputs
  `(("python2-setuptools" ,python2-setuptools)
 
-(define-public python2-msgpack
-  (package-with-python2 python-msgpack))
-
 (define-public python-netaddr
   (package
 (name "python-netaddr")
-- 
2.7.4

[PATCH v2 3/7] gnu: python-zope-testing: Strip byte-code and backup-files from source.

[Hartmut Goebel]

* gnu/package/python.scm (python-zope-testing, python2-zope-testing)[source]:
  Add snippet to strip byte-code and backup-files.
---
 gnu/packages/python.scm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index eca60bc..ec56c85 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -6644,7 +6644,13 @@ that have uses outside of the Zope framework.")
"/zope.testing/zope.testing-" version ".tar.gz"))
(sha256
 (base32
- "1yvglxhzvhl45mndvn9gskx2ph30zz1bz7rrlyfs62fv2pvih90s"
+ "1yvglxhzvhl45mndvn9gskx2ph30zz1bz7rrlyfs62fv2pvih90s"))
+   (modules '((guix build utils)))
+   (snippet
+'(begin
+   ;; Remove pre-compiled .pyc files backup files from source.
+   (for-each delete-file (find-files "." "(\\.pyc|~)$"))
+   #t
 (build-system python-build-system)
 (native-inputs
  `(("python-zope-exceptions" ,python-zope-exceptions)))
-- 
2.7.4

[PATCH v2 6/7] gnu: python-pathlib: Update description.

[Hartmut Goebel]

* gnu/packages/python.scm (python-pathlib, python2-pathlib): Update
  description.
---
 gnu/packages/python.scm | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index c890c68..6207896 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -8849,7 +8849,12 @@ be done easily through operators, attribute accesses, 
and method calls.
 comparing Windows paths ignores casing.
 @item Well-defined semantics, eliminating any inconsistencies or
 ambiguities (forward vs. backward slashes, etc.).
-@end enumerate\n")
+@end enumerate
+
+Note: In Python 3.4, pathlib is now part of the standard library.  For other
+Python versions please consider python-pathlib2 instead, which tracks the
+standard library module.  This module (python-pathlib) isn't maintained
+anymore.")
 (license license:expat)))
 
 (define-public python2-pathlib
-- 
2.7.4

Re: More duplicate package definitions

[Hartmut Goebel]

Hi Danny,

thanks for pointing this out.
> python2-msgpack has a duplicate too. 

I removed this one, too.

> And so do ruby-arel, r-codetools, r-gtable.


These have different versions and are not defined just below each other.
Somebody else needs to work on this.

-- 
Regards
Hartmut Goebel

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

Re: [PATCH v2] doc: Add guide how to specify dependencies for Python packages

[Hartmut Goebel]

Hi Ludo,

> I’ve rewritten parts of it, mostly to provide more context to a
> non-Pythonista like me.

Yes, that's fine. Thanks.

-- 
Regards
Hartmut Goebel

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

Re: [PATCH v2 0/7] Updated: Some simple or even trivial changes.

[Danny Milosavljevic]

Hi,

all LGTM!

Re: Where is qtwebkit?

[Roel Janssen]

ng0 writes:

> I am currently packaging supercollider, and it would be nice to have
> qtwebkit... but I can't find it for Guix. How do I use it in a packaging
> defition? Do we have it at all? Is someone working on it? I've read a
> thread where someone pointed out it was moved but that was of no help
> either.
>
> * Qt >= 5.3 (+ qtwebkit)
>* http://qt-project.org
>* cross-platform graphical user interface library, for Qt IDE and sclang's 
> Qt GUI kit

I think QtWebkit has been removed from Qt in favor of the QtWebEngine
(based on Chromium?).

>From https://blog.qt.io/blog/2016/03/16/qt-5-6-released/:
> With 5.6, Qt WebKit and Qt Quick 1 will no longer be supported and are
> dropped from the release. The source code for these modules will still
> be available. You can continue to compile and use these modules, but
> we will not be supporting them any longer.

So it should still be possible to compile the source code.  I downloaded
the source code and tried to compile it but I couldn't find any 'find
. -name "*webkit*"' at all!

Kind regards,
Roel Janssen

Re: [PATCH 1/1] services: ntpd: Make large clock adjustments if necessary.

[Leo Famulari]

On Thu, Oct 13, 2016 at 07:06:50AM +0200, John Darrington wrote:
> I think that this should be a configuration item in the service, so that the
> user can decide whether to have it or not.  I don't think we should force it
> on the user.   Some applications break if the clock makes large jumps.

I agree. This is really something that the system administrator should
evaluate and fix on a case-by-case basis.
  
> The ntpd authors decided that the default behaviour is not to make large jumps
> so I think we should respect that unless there is a good reason to do 
> otherwise.
> So I think this should be configurable in /etc/config.scm and the default 
> should
> be not to use -g

For me, I have to do this so rarely (and never on the machines I
currently use) that I am fine with having to run `ntpd -g ...` by hand.

So, if we want to make this configurable in the OS configuration,
volunteers are welcome to work on it :)


signature.asc
Description: PGP signature

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

[宋文武]

Leo Famulari  writes:

> On core-updates, from 6671ce93 (gnu: ath9k-htc-firmware: Update binutils
> patch for binutils 2.27), I can't build gtk+@3.20 because the daemon
> finds a cycle in the references:
>
> --
> starting phase `validate-runpath'
> validating RUNPATH of 17 binaries in 
> "/gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/lib"...
> validating RUNPATH of 10 binaries in 
> "/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin"...
> phase `validate-runpath' succeeded after 0.2 seconds
> starting phase `validate-documentation-location'
> phase `validate-documentation-location' succeeded after 0.0 seconds
> starting phase `delete-info-dir-file'
> phase `delete-info-dir-file' succeeded after 0.0 seconds
> starting phase `patch-dot-desktop-files'
> adjusting 3 '.desktop' files in 
> "/gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/applications"
> phase `patch-dot-desktop-files' succeeded after 0.0 seconds
> starting phase `compress-documentation'
> compressing documentation in 
> '/gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/man' with 
> "gzip" and flags ("--best" "--no-name")
> phase `compress-documentation' succeeded after 0.0 seconds
> cycle detected in the references of 
> `/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin'
> cannot build derivation 
> `/gnu/store/8mpv03c557g56q1vmym53pm0apxj6p30-gtk-icon-themes.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/wd7lz1x2jqfj1z46872fc2lh5ga13gzx-profile.drv': 1 dependencies 
> couldn't be built
> killing process 31697
> cannot build derivation 
> `/gnu/store/0id6isvf9ljkgx7kf58w5mnhwh805apl-system.drv': 1 dependencies 
> couldn't be built
> guix system: error: build failed: build of 
> `/gnu/store/0id6isvf9ljkgx7kf58w5mnhwh805apl-system.drv' failed
> --
>
> And here are the references. I didn't check if there were any in the doc
> output since I didn't see it in the build log.
>
> --
> $ grep -r dsnckvh133ndivnnbspg2yziqmlg1c4p 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-query-immodules-3.0
>  matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-demo-application
>  matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-builder-tool
>  matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-query-settings
>  matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-icon-browser
>  matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-update-icon-cache
>  matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-widget-factory
>  matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-demo 
> matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-launch 
> matches
> Binary file 
> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-encode-symbolic-svg
>  matches
> $ grep -r 28mzpkx23h4cnrhc2ijkp46hiiz06na0 
> /gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9
> /gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/applications/gtk3-demo.desktop:Exec=/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-demo
> /gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/applications/gtk3-widget-factory.desktop:Exec=/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-widget-factory
> /gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/applications/gtk3-icon-browser.desktop:Exec=/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-icon-browser
> --
>
> It works if I remove the 'bin' output from gtk+@3.

Oh, I added the 'bin' output to gtk+ without moving its desktop files.
And now the 'patch-dot-desktop-files' phase in gnu-build-system gives
absolute paths to desktop files, so it fails with cycle references.

Move all the 3 desktop files into 'bin' output should work.  (I could
patch that next day, but won't be able to test it due to slow
substitute/download/build speed though.)

Re: [PATCH v2 0/7] Updated: Some simple or even trivial changes.

[Hartmut Goebel]

Am 13.10.2016 um 15:27 schrieb Danny Milosavljevic:
> all LGTM!

commited. Thanks for the review.

-- 
Regards
Hartmut Goebel

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

Re: [PATCH] gnu: Add jack-keyboard.

[Kei Kebreau]

Ricardo Wurmus  writes:

> * gnu/packages/music.scm (jack-keyboard): New variable.
> ---
>  gnu/packages/music.scm | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
> index 7452052..9c8de9e 100644
> --- a/gnu/packages/music.scm
> +++ b/gnu/packages/music.scm
> @@ -1521,6 +1521,31 @@ synths, microtonal capabilities, custom envelopes, 
> effects, etc.  Yoshimi
>  improves on support for JACK features, such as JACK MIDI.")
>  (license license:gpl2)))
>  
> +(define-public jack-keyboard
> +  (package
> +(name "jack-keyboard")
> +(version "2.5")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append 
> "mirror://sourceforge/jack-keyboard/jack-keyboard/"
> +   version "/jack-keyboard-" version ".tar.gz"))
> +   (sha256
> +(base32
> + "0mzmg8aavybcfdlq2yd9d0vscqd6is5p6jzrgfpfm5j3xdcvh2s3"
> +(build-system gnu-build-system)
> +(inputs
> + `(("jack" ,jack-1)
> +   ("lash" ,lash)
> +   ("gtk+" ,gtk+-2)))
> +(native-inputs
> + `(("pkg-config" ,pkg-config)))
> +(home-page "http://jack-keyboard.sourceforge.net/";)
> +(synopsis "Virtual MIDI keyboard")
> +(description "Jack-keyboard is a virtual MIDI keyboard, a program that
> +allows you to send JACK MIDI events (i.e. play) using your PC keyboard.")
> +(license license:bsd-2)))
> +
>  (define-public cursynth
>(package
>  (name "cursynth")

Looks and works fine for me!


signature.asc
Description: PGP signature

Re: Where is qtwebkit?

[ng0]

Roel Janssen  writes:

> ng0 writes:
>
>> I am currently packaging supercollider, and it would be nice to have
>> qtwebkit... but I can't find it for Guix. How do I use it in a packaging
>> defition? Do we have it at all? Is someone working on it? I've read a
>> thread where someone pointed out it was moved but that was of no help
>> either.
>>
>> * Qt >= 5.3 (+ qtwebkit)
>>* http://qt-project.org
>>* cross-platform graphical user interface library, for Qt IDE and 
>> sclang's Qt GUI kit
>
> I think QtWebkit has been removed from Qt in favor of the QtWebEngine
> (based on Chromium?).

Like I was told in IRC freenode. I wonder if supercollider really needs
qt4 instead of qt5 or if qtwebkit is the MIT-license of the webkits:
they say qtwebkit, but what they really mean is qtwebengine.
I'll ask on their mailinglist.

> From https://blog.qt.io/blog/2016/03/16/qt-5-6-released/:
>> With 5.6, Qt WebKit and Qt Quick 1 will no longer be supported and are
>> dropped from the release. The source code for these modules will still
>> be available. You can continue to compile and use these modules, but
>> we will not be supporting them any longer.
>
> So it should still be possible to compile the source code.  I downloaded
> the source code and tried to compile it but I couldn't find any 'find
> . -name "*webkit*"' at all!
>
> Kind regards,
> Roel Janssen
>

Thanks for the reply

Re: 07/07: guix: python-build-system: Fix an outdated comment.

[Mark H Weaver]

h.goe...@crazy-compilers.com (Hartmut Goebel) writes:

> htgoebel pushed a commit to branch master
> in repository guix.
>
> commit 635a7af45d6e2105ad65d1a9531126cc232a2a50
> Author: Hartmut Goebel 
> Date:   Sun Oct 2 18:48:56 2016 +0200
>
> guix: python-build-system: Fix an outdated comment.
> 
> The python-build-system uses phases the build and install, but not
> configure. So the old comment was plain wrong since Sept. 2013, when the 
> build
> phase has been added.
> ---
>  guix/build/python-build-system.scm |3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/guix/build/python-build-system.scm 
> b/guix/build/python-build-system.scm
> index 9109fb4..e906e60 100644
> --- a/guix/build/python-build-system.scm
> +++ b/guix/build/python-build-system.scm
> @@ -137,8 +137,7 @@ installed with setuptools."
>  #t))
>  
>  (define %standard-phases
> -  ;; 'configure' and 'build' phases are not needed.  Everything is done 
> during
> -  ;; 'install'.
> +  ;; 'configure' phase is not needed.
>(modify-phases gnu:%standard-phases
>  (add-after 'unpack 'ensure-no-mtimes-pre-1980 ensure-no-mtimes-pre-1980)
>  (delete 'configure)

This change triggered over 6300 rebuilds on 'master'.  I reverted it.
Please beware that changing some files in guix/build/*.scm can trigger a
large number of rebuilds, because some of these files are implicitly
used as inputs to a large number of builds.

Regards,
  Mark

Re: [PATCH 1/2] gnu: Add emacs-goto-chg.

[Alex Kost]

ng0 (2016-10-12 23:00 +) wrote:

> * gnu/packages/emacs.scm (emacs-goto-chg): New variable.
> ---
>  gnu/packages/emacs.scm | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index 1b345db..f04b71d 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -12,7 +12,7 @@
>  ;;; Copyright © 2016 David Thompson 
>  ;;; Copyright © 2016 Matthew Jordan 
>  ;;; Copyright © 2016 Roel Janssen 
> -;;; Copyright © 2016 ng0 
> +;;; Copyright © 2016 ng0 
>  ;;; Copyright © 2016 Alex Griffin 
>  ;;; Copyright © 2016 Nicolas Goaziou 
>  ;;; Copyright © 2016 Alex Vong 
> @@ -2981,6 +2981,30 @@ Lua programing language}.")
>  news items, openrc and runscripts.")
>  (license license:gpl2+)))
>  
> +(define-public emacs-goto-chg
> +  (package
> +(name "emacs-goto-chg")
> +(version "20131228.659")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + "http://melpa.org/packages/goto-chg-";
> + version ".el"))

Although the source of this package is the emacswiki, I used it here as
well, also I changed the version to "1.6" (according to source).

> +   (sha256
> +(base32
> + "1763qs6xprbb86bsxs4sh35rdcnb3v1zam4pc2akkd4wimg83k2l"
> +(build-system emacs-build-system)
> +;; This is correct, the source/www is a wiki.
> +(home-page "http://www.emacswiki.org/emacs/goto-chg.el";)
> +(synopsis "Go to last change")
> +(description
> + "Goto-Chg goes to the point of the most recent edit in the
> +buffer.  When repeated, go to the second most recent edit, etc.
> +Negative argument, C-u -, for reverse direction.  Works by
> +looking into buffer-undo-list to find points of edit.")

I rephrased the description a bit to mention 'goto-last-change' command.

> +(license license:gpl3+)))

This is actually gpl2+

> +
>  (define-public emacs-writegood-mode
>(package
>  (name "emacs-writegood-mode")

Applied as ce74e520115a6d51b237a953fdf1468bc2b54d44, thanks!

-- 
Alex

Re: 07/07: guix: python-build-system: Fix an outdated comment.

[Leo Famulari]

On Thu, Oct 13, 2016 at 03:32:09PM -0400, Mark H Weaver wrote:
> h.goe...@crazy-compilers.com (Hartmut Goebel) writes:
> 
> > htgoebel pushed a commit to branch master
> > in repository guix.
> >
> > commit 635a7af45d6e2105ad65d1a9531126cc232a2a50
> > Author: Hartmut Goebel 
> > Date:   Sun Oct 2 18:48:56 2016 +0200
> >
> > guix: python-build-system: Fix an outdated comment.
> > 
> > The python-build-system uses phases the build and install, but not
> > configure. So the old comment was plain wrong since Sept. 2013, when 
> > the build
> > phase has been added.
>
> This change triggered over 6300 rebuilds on 'master'.  I reverted it.
> Please beware that changing some files in guix/build/*.scm can trigger a
> large number of rebuilds, because some of these files are implicitly
> used as inputs to a large number of builds.

Sorry, I didn't realize that altering comments here would have an
effect; I would have warned Hartmut if I had.

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

[Alex Kost]

Arun Isaac (2016-10-13 11:19 +0530) wrote:

> * gnu/packages/emacs.scm (emacs-nginx-mode): New variable.
> ---
>  gnu/packages/emacs.scm | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index 1b345db..176be62 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -3183,3 +3183,24 @@ display and edit the text.
>  
>  This package contains the library runtime.")
>  (license license:lgpl2.1+)))
> +
> +(define-public emacs-nginx-mode
> +  (package
> +(name "emacs-nginx-mode")
> +(version "1.1.4")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + "https://github.com/ajc/nginx-mode/archive/v";
> + version ".tar.gz"))
> +   (file-name (string-append name "-" version ".tar.gz"))
> +   (sha256
> +(base32
> + "1lvkj07kq0jkskr2f61vqb5rlrbnaz9a76ikq40w6925i2r970rr"
> +(build-system emacs-build-system)
> +(home-page "https://github.com/ajc/nginx-mode";)
> +(synopsis "Emacs major mode for editing nginx config files")
> +(description "This package provides an Emacs major mode for
> +editing nginx config files.")
> +(license license:gpl2+)))

Applied as commit 71d3ee1, thanks!

http://git.savannah.gnu.org/cgit/guix.git/commit/?id=71d3ee1cbbccdf984c8f53d4b9596a4e06489769

-- 
Alex

Re: [PATCH 2/2] gnu: Add emacs-evil.

[Alex Kost]

ng0 (2016-10-12 23:00 +) wrote:

> * gnu/packages/emacs.scm (emacs-evil): New variable.
> ---
>  gnu/packages/emacs.scm | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index f04b71d..7ea7035 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -2981,6 +2981,30 @@ Lua programing language}.")
>  news items, openrc and runscripts.")
>  (license license:gpl2+)))
>  
> +(define-public emacs-evil
> +  (package
> +(name "emacs-evil")
> +(version "20160827.1510")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "https://melpa.org/packages/evil-";
> +   version ".tar"))

We don't use tarballs from MELPA.  The problem is: when there will be a
new commit in the upstream repo, the tarball on melpa will be changed,
and the old source will be removed, and this package could not be built
anymore.  So I replaced it with the tarball from bitbucket.

> +   (sha256
> +(base32
> + "1lq8b3yf4z6h0pgy80jk22q922d4l4pazbcrfyqyq9rfl34g8jvi"
> +(build-system emacs-build-system)
> +(inputs

These should be 'propagated-inputs'.

> + `(("emacs-undo-tree" ,emacs-undo-tree)
> +   ("emacs-goto-chg" ,emacs-goto-chg)))
> +(home-page "https://bitbucket.com/lyro/evil";)
> +(synopsis "Extensible Vi layer for Emacs.")

"guix lint" tells about this period ---^

> +(description
> + "Evil is an extensible vi layer for Emacs.  It emulates the
> +main features of Vim, and provides facilities for writing custom
> +extensions.")
> +(license license:gpl3+)))
> +
>  (define-public emacs-goto-chg
>(package
>  (name "emacs-goto-chg")

Applied as 2edbfbf58843f20114d555445d38f6e0ffd1f4e7, thanks!

-- 
Alex

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

[Ludovic Courtès]

iyzs...@member.fsf.org (宋文武) skribis:

> Leo Famulari  writes:
>
>> On core-updates, from 6671ce93 (gnu: ath9k-htc-firmware: Update binutils
>> patch for binutils 2.27), I can't build gtk+@3.20 because the daemon
>> finds a cycle in the references:
>>
>> --
>> starting phase `validate-runpath'
>> validating RUNPATH of 17 binaries in 
>> "/gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/lib"...
>> validating RUNPATH of 10 binaries in 
>> "/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin"...
>> phase `validate-runpath' succeeded after 0.2 seconds
>> starting phase `validate-documentation-location'
>> phase `validate-documentation-location' succeeded after 0.0 seconds
>> starting phase `delete-info-dir-file'
>> phase `delete-info-dir-file' succeeded after 0.0 seconds
>> starting phase `patch-dot-desktop-files'
>> adjusting 3 '.desktop' files in 
>> "/gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/applications"
>> phase `patch-dot-desktop-files' succeeded after 0.0 seconds
>> starting phase `compress-documentation'
>> compressing documentation in 
>> '/gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/man' with 
>> "gzip" and flags ("--best" "--no-name")
>> phase `compress-documentation' succeeded after 0.0 seconds
>> cycle detected in the references of 
>> `/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin'
>> cannot build derivation 
>> `/gnu/store/8mpv03c557g56q1vmym53pm0apxj6p30-gtk-icon-themes.drv': 1 
>> dependencies couldn't be built
>> cannot build derivation 
>> `/gnu/store/wd7lz1x2jqfj1z46872fc2lh5ga13gzx-profile.drv': 1 dependencies 
>> couldn't be built
>> killing process 31697
>> cannot build derivation 
>> `/gnu/store/0id6isvf9ljkgx7kf58w5mnhwh805apl-system.drv': 1 dependencies 
>> couldn't be built
>> guix system: error: build failed: build of 
>> `/gnu/store/0id6isvf9ljkgx7kf58w5mnhwh805apl-system.drv' failed
>> --
>>
>> And here are the references. I didn't check if there were any in the doc
>> output since I didn't see it in the build log.
>>
>> --
>> $ grep -r dsnckvh133ndivnnbspg2yziqmlg1c4p 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-query-immodules-3.0
>>  matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-demo-application
>>  matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-builder-tool
>>  matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-query-settings
>>  matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-icon-browser
>>  matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-update-icon-cache
>>  matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-widget-factory
>>  matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-demo 
>> matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-launch 
>> matches
>> Binary file 
>> /gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk-encode-symbolic-svg
>>  matches
>> $ grep -r 28mzpkx23h4cnrhc2ijkp46hiiz06na0 
>> /gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9
>> /gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/applications/gtk3-demo.desktop:Exec=/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-demo
>> /gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/applications/gtk3-widget-factory.desktop:Exec=/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-widget-factory
>> /gnu/store/dsnckvh133ndivnnbspg2yziqmlg1c4p-gtk+-3.20.9/share/applications/gtk3-icon-browser.desktop:Exec=/gnu/store/28mzpkx23h4cnrhc2ijkp46hiiz06na0-gtk+-3.20.9-bin/bin/gtk3-icon-browser
>> --
>>
>> It works if I remove the 'bin' output from gtk+@3.
>
> Oh, I added the 'bin' output to gtk+ without moving its desktop files.
> And now the 'patch-dot-desktop-files' phase in gnu-build-system gives
> absolute paths to desktop files, so it fails with cycle references.

Good catch!

> Move all the 3 desktop files into 'bin' output should work.  (I could
> patch that next day, but won't be able to test it due to slow
> substitute/download/build speed though.)

That should work.  You can post the patch here so we can test, if you
want.

Thanks in advance.  :-)

Ludo’.

Re: [PATCH 5/5] guix: python-build-system: Fix an outdated comment.

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 12.10.2016 um 18:03 schrieb Leo Famulari:
>>> >  (define %standard-phases
>>> > -  ;; 'configure' and 'build' phases are not needed.  Everything is done 
>>> > during
>>> > -  ;; 'install'.
>>> > +  ;; 'configure' phase is not needed.
>> I have no real comment because I don't know the python-build-system well
>> enough. Is the sentence about 'install' no longer accurate?
>
> The python-build-system uses the build and the install phase, but not
> the configure phase. So the old comment was plain wrong. I assume once
> only the install phase was used[*] and the comment has had been correct :-)
>
> Which is possible and much like running "make install" without prior run
> to "make".

Indeed, I think this has been the case since commit
b191f88ee34576a6908b9b5e94cb7664e88c7e79.

Note however that Mark reverted this patch from master because it would
have caused a rebuild of all things Python.  However feel free to apply
it to wip-python-build-system.

Thanks,
Ludo’.

Re: [core-updates]: cycle detected in the references of ...gtk+-3.20.9-bin

[Ludovic Courtès]

Leo Famulari  skribis:

> On Thu, Oct 13, 2016 at 01:24:47AM -0400, Leo Famulari wrote:
>> It works if I remove the 'bin' output from gtk+@3.
>
> I think I was mistaken. If I don't use a separate 'bin' output, I can
> build the package, but I still get an error with `guix system build`:
>
> guix system: error: reference to invalid output 'bin' of derivation 
> '/gnu/store/hb07mzbrn4nqwdlimjbbbdkm2nnvbsvz-gtk+-3.20.9.drv'

This is expected: it means that some packages or gexps refer to the
“bin” output of GTK+, which no longer exists.  For instance, the
‘gtk-icon-themes’ procedure in (guix profile) does exactly that.

If we remove “bin”, these will have to be updated.

Thanks,
Ludo’.

Re: [PATCH] gnu: mail: Add notifymuch.

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 12.10.2016 um 20:17 schrieb Christopher Baines:
 +(description "notifymuch displays desktop notifications for
 messages in
 +the notmuch database.  The notifications are sent using libnotify to a
>>>
>>> May I ask you to ass some words about what notmuch is? This saves the
>>> ingenuous reader to recherché what notmuch is. Thanks.
>>
>> I'm not quite sure how to improve on this. Copying in the full package
>> description for notmuch looks out of place to me, and I'm not sure if
>> just saying "the notmuch email database" instead of "the notmuch
>> database" is sufficient?
>>
>
> IC, this is a complicated one, since notmuch seems to be a framework. I
> have to admit that I did not know about notmuch until just now.
> Explaining about what notmuch is would indeed disrupt the description.
> So I'd say your suggestion is okay, since it give the ingenuous reader
> at least a hint.
>
> (synopsis "Displays notifications for changes in the notmuch email
> database")

Sounds good (without the newline though).

Hartmut, since the rest of the patch looked non controversial, and if
‘guix lint’ doesn’t complain, you can push to ‘master’ with the synopsis
above.

The ‘license’ field may also need to be fixed: it says ‘gpl3’, which
means GPLv3-only, but the odds are that it’s in fact GPLv3-or-later,
aka. ‘gpl3+’.

Thanks,
Ludo’.

Re: [PATCH] guxi: cmake-build-system: Enable output for failing test-cases.

[Ludovic Courtès]

Hartmut Goebel  skribis:

> * guix/build/cmake-build-system.scm (cmake-build-system): Set
>   environment variable CTEST_OUTPUT_ON_FAILURE to an non-empty value.

It’s a good idea, but it would entail a rebuild of 1,000+ packages.  Can
you save it for the next big-rebuild cycle?

Thanks,
Ludo’.

Re: [PATCH 4/5] gnu: python.scm: Update some home-page urls and descriptions.

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 12.10.2016 um 18:01 schrieb Leo Famulari:
>> On Mon, Oct 10, 2016 at 03:10:02PM +0200, Hartmut Goebel wrote:
>>> > * gnu/packages/python.scm (python-keyring, python-pylockfile): Update
>>> >   home-page url. (python-pathlib): Update description.
>> This should really be separate commits :)
>>
>
> How many? Three?

Yes, one patch for each logical change.  See the last item at
.

Thanks,
Ludo’.

Re: [PATCH 0/1] Dbus update 1.10.12 for core-updates

[Ludovic Courtès]

Leo Famulari  skribis:

> On Mon, Oct 10, 2016 at 10:57:47PM +0200, Ludovic Courtès wrote:
>> Yeah, seems hard to exploit.  Apparently even if we’re not using systemd
>> activations we could be vulnerable, because it’s about how specific
>> messages are processed, IIUC.
>> 
>> > What do you think? Should we update this on core-updates?
>> 
>> I think so.
>
> Okay. Just to clarify, this will trigger >1000 rebuilds.

Well the answer was valid on Oct. 10th ;-), but at this point of the
build progress I agree that it’s kinda problematic would probably
recommend grafting.

What are your thoughts?
>> 
>> > Should we graft it on master?
>> 
>> Unless there are possible ABI incompatibilies, it probably doesn’t hurt
>> to do that.
>
> According to the dbus README, the offer a stable ABI within each stable
> release series:
>
> https://dbus.freedesktop.org/doc/README
>
> But, I found that the regular approach to grafting does not work for our
> dbus package. Presumably, it's because (gnu packages glib) exports dbus
> before defining it.

The #:export at the top shouldn’t make any difference.  In what way does
it not work?  :-)

Could it be an instance of ?

Ludo’.

Re: locales gone

[Ludovic Courtès]

Hi!

Danny Milosavljevic  skribis:

> I read the docs you pointed me to - however, previously this worked fine 
> as-is. Also, I have a database that is inaccessible because the locale 
> suddenly (sometimes) doesn't work anymore. It's not like I can change what 
> locale it was created in without a time machine :)
>
> $ psql -U postgres template1
> psql: FATAL:  database locale is incompatible with operating system
> DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which 
> is not recognized by setlocale().
> HINT:  Recreate the database with another locale or install the missing 
> locale.

What does this return:

  ldd $(which psql) | grep glibc

?

If it says 2.22, then you need to add the 2.22 locale data to your OS,
as per
.

HTH,
Ludo’.

Re: locales gone

[Danny Milosavljevic]

On Thu, 13 Oct 2016 22:22:47 +0200
l...@gnu.org (Ludovic Courtès) wrote:

>   ldd $(which psql) | grep glibc

$ ldd $(which psql) |grep glibc
libm.so.6 => 
/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libm.so.6 
(0x7fc4b8c49000)
libc.so.6 => 
/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 
(0x7fc4b8691000)
libpthread.so.0 => 
/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libpthread.so.0 
(0x7fc4b8474000)

/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 
(0x7fc4b93be000)

Re: 07/07: guix: python-build-system: Fix an outdated comment.

[Danny Milosavljevic]

> Sorry, I didn't realize that altering comments here would have an
> effect; I would have warned Hartmut if I had.

Out of curiousity, why does it have an effect?

Finding dependency cycles

[Danny Milosavljevic]

Hi,

so I'm trying to untangle the matplotlib -> ipython dependency cycle.

Unfortunately, guix error message isn't really helpful in finding out what it 
was.

It says


guix/base32.scm:104:4: In procedure #:
guix/base32.scm:104:4: Throw to key `vm-error' with args `(vm-run "VM: Stack 
overflow" ())'.
Backtrace:
In guix/packages.scm:
 838: 19 [expand-input # # # ...]
 793: 18 [cache! # # # ...]
1097: 17 [thunk]
1029: 16 [bag->derivation # # #]
In srfi/srfi-1.scm:
 578: 15 [map # #]
In guix/packages.scm:
 853: 14 [expand-input # # # ...]
In guix/store.scm:
1182: 13 [run-with-store # ...]
In guix/packages.scm:
1199: 12 [# #]
In guix/gexp.scm:
 582: 11 [# #]
In guix/store.scm:
1105: 10 [# #]
In guix/derivations.scm:
 842: 9 [derivation # "module-import" ...]
 740: 8 [add-output-paths #  62e6460>]
In srfi/srfi-1.scm:
 578: 7 [map # (#)]
In guix/derivations.scm:
 744: 6 [# ("out" . #)]
 669: 5 [store-path "output:out" ...]
In guix/base32.scm:
 142: 4 [# #vu8(120 134 169 
141 131 9 168 9 255 14 95 77 50 123 239 139 107 100 105 6)]
 137: 3 [bytevector-quintet-fold-right # ...]
 104: 2 [# #vu8(120 134 
169 141 131 9 168 9 255 14 95 77 50 123 239 139 107 100 105 6) ...]
In ice-9/boot-9.scm:
 105: 1 [# 
vm-error ...]
  65: 0 [abort-to-prompt catch7 vm-error vm-run "VM: Stack overflow" ()]

ice-9/boot-9.scm:65:2: In procedure abort-to-prompt:
ice-9/boot-9.scm:65:2: Throw to key `vm-error' with args `(vm-run "VM: Stack 
overflow" ())'.

.

Is there a way to improve this error message? Alternatively, is there a command 
to manually find the problem?

Re: Guile 2.0.13

[Ludovic Courtès]

Leo Famulari  skribis:

> On Wed, Oct 12, 2016 at 10:13:32PM +0200, Ludovic Courtès wrote:

[...]

>> Yeah.  I was thinking that we’d want to finish this core-updates cycle
>> and then later do an ungrafting round or something.
>> 
>> WDYT?
>
> That sounds good. I think we should try doing some more specific
> "updates" branches in between releases, assuming we have the compute
> power and the motivation.
>
> And we could also have some periodic ungrafting rebuilds when necessary
> and feasible.

Yes, definitely.

More generally, we could try to have a “staging” branch for safe changes
that involve a rebuild of between ~300 and ~1200 packages, that we’d
merge more frequently than ‘core-updates’ (I think the Nix folks do
that).  By “safe” I mean things like ungrafting, minor upgrades and
improvements; the goal would be to reduce the latency for such changes.

Things that rebuild more than ~1200 packages would still go to
‘core-updates’.

WDYT?

> So, we would graft guile-2.0, make guile-2.0/fixed use 2.0.12, and set
> replacement #f in guile-next? Anything else?

Yes, and a couple of related changes.  Pushed as
c62a31ca802c2b225279c4b0360a4cfc2723ad28.

Thanks!

Ludo’.

Re: [WIP v3 0/5] Update Sphinx to 1.4.8

[Danny Milosavljevic]

> There's a newer version of Matplotlib which has a reference cycle matplotlib 
> <- ipython <- matplotlib. Sigh...

If I remove "ipython requires matplotlib" (according to matplotlib upstream it 
doesn't - at least they imply that), then still this remains:

python-numpy requires python-matplotlib
python-matplotlib requires python-numpy-bootstrap
python-matplotlib requires python-ipython
python-ipython requires python-numpy

Therefore, there's a cycle

python-ipython requires python-numpy requires python-matplotlib requires 
python-ipython

.

Re: [PATCH 00/13] Add a bunch of LV2 audio effects!

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Kei Kebreau  writes:
>
>> Ricardo Wurmus  writes:
>>
>>> Hi Guix,
>>>
>>> here's a simple patch set to add 13 new LV2 audio plugins.
>>> Have fun!
>>>
>>> ~~ Ricardo
>>>
>>>
>>> Ricardo Wurmus (13):
>>>   gnu: Add gx-guvnor-lv2.
>>>   gnu: Add gx-vbass-preamp-lv2.
>>>   gnu: Add gx-overdriver-lv2.
>>>   gnu: Add gx-tone-mender-lv2.
>>>   gnu: Add gx-push-pull-lv2.
>>>   gnu: Add gx-suppa-tone-bender-lv2.
>>>   gnu: Add gx-saturator-lv2.
>>>   gnu: Add gx-hyperion-lv2.
>>>   gnu: Add gx-voodoo-fuzz-lv2.
>>>   gnu: Add gx-super-fuzz-lv2.
>>>   gnu: Add gx-vintage-fuzz-master-lv2.
>>>   gnu: Add gx-slow-gear-lv2.
>>>   gnu: Add gx-switchless-wah-lv2.
>>>
>>>  gnu/packages/music.scm | 286 
>>> +
>>>  1 file changed, 286 insertions(+)
>>
>> Patches 01 through 10 are clean according to "guix lint" and
>> reproducible. "git am" complains about 11 through 13 being corrupt for
>> some reason.
>
> Huh, weird.  Maybe a bug in git am?
>
> FWIW, “guix lint” doesn’t complain about any of these packages.

I pushed these patches to master.  Thanks for the review!

~~ Ricardo

Re: [PATCH] gnu: Add jack-keyboard.

[Ricardo Wurmus]

Kei Kebreau  writes:

> Ricardo Wurmus  writes:
>
>> * gnu/packages/music.scm (jack-keyboard): New variable.
>> ---
>>  gnu/packages/music.scm | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
>> index 7452052..9c8de9e 100644
>> --- a/gnu/packages/music.scm
>> +++ b/gnu/packages/music.scm
>> @@ -1521,6 +1521,31 @@ synths, microtonal capabilities, custom envelopes, 
>> effects, etc.  Yoshimi
>>  improves on support for JACK features, such as JACK MIDI.")
>>  (license license:gpl2)))
>>  
>> +(define-public jack-keyboard
>> +  (package
>> +(name "jack-keyboard")
>> +(version "2.5")
>> +(source
>> + (origin
>> +   (method url-fetch)
>> +   (uri (string-append 
>> "mirror://sourceforge/jack-keyboard/jack-keyboard/"
>> +   version "/jack-keyboard-" version ".tar.gz"))
>> +   (sha256
>> +(base32
>> + "0mzmg8aavybcfdlq2yd9d0vscqd6is5p6jzrgfpfm5j3xdcvh2s3"
>> +(build-system gnu-build-system)
>> +(inputs
>> + `(("jack" ,jack-1)
>> +   ("lash" ,lash)
>> +   ("gtk+" ,gtk+-2)))
>> +(native-inputs
>> + `(("pkg-config" ,pkg-config)))
>> +(home-page "http://jack-keyboard.sourceforge.net/";)
>> +(synopsis "Virtual MIDI keyboard")
>> +(description "Jack-keyboard is a virtual MIDI keyboard, a program that
>> +allows you to send JACK MIDI events (i.e. play) using your PC keyboard.")
>> +(license license:bsd-2)))
>> +
>>  (define-public cursynth
>>(package
>>  (name "cursynth")
>
> Looks and works fine for me!

Thanks for the review!
Pushed as a9f55bf21864d91c001b96750bf231e0bb381388.

~~ Ricardo

dropping vmpk in favour of jack-keyboard

[Ricardo Wurmus]

Hi Guix,

a while ago I noticed that the software provided by the “vmpk” package
doesn’t work.  It is supposed to create a window displaying a MIDI
keyboard that can be used to send MIDI messages to other applications
via JACK, but it does nothing at all.  I tried to debug this but I
cannot seem to find the cause.

Now that we have “jack-keyboard”, which works just fine, I’m thinking
about just removing “vmpk”.  What do you think?  Any objections?

~~ Ricardo

Re: dropping vmpk in favour of jack-keyboard

[Leo Famulari]

On Thu, Oct 13, 2016 at 11:21:25PM +0200, Ricardo Wurmus wrote:
> Hi Guix,
> 
> a while ago I noticed that the software provided by the “vmpk” package
> doesn’t work.  It is supposed to create a window displaying a MIDI
> keyboard that can be used to send MIDI messages to other applications
> via JACK, but it does nothing at all.  I tried to debug this but I
> cannot seem to find the cause.
> 
> Now that we have “jack-keyboard”, which works just fine, I’m thinking
> about just removing “vmpk”.  What do you think?  Any objections?

I don't have any opinions about vmpk, but I think it would be good to
ask upstream for advice about the buggy behaviour, if there is active
upstream maintenance.

But, I know that means doing more work for a package you don't need
anymore. So I understand if you prefer to remove the package.

Re: More duplicate package definitions

[Leo Famulari]

On Thu, Oct 13, 2016 at 03:17:54PM +0200, Hartmut Goebel wrote:
> Hi Danny,
> 
> thanks for pointing this out.
> > python2-msgpack has a duplicate too. 
> 
> I removed this one, too.
> 
> > And so do ruby-arel, r-codetools, r-gtable.
> 
> 
> These have different versions and are not defined just below each other.
> Somebody else needs to work on this.

We should CC whoever added those second patches to get their input. At
least, we can add comments to the package definitions to explain why we
need to keep multiple versions around.

node is failing

[ng0]

So node is failing on hydra[0] and building it locally brought equal
results. As I'm not familiar with node at all I don't know if my
inclusion of node is not necessary for mastodon, so I will give it a try
without node.

I know many things are failing right now, but I do not have enough
knowledge of node to understand why the test suite fails suddenly. Maybe
some dependency needed only for the test which is failing before node?


This is the local node output after the build phase succeeded:

phase `build' succeeded after 350.4 seconds
starting phase `check'
make -C out BUILDTYPE=Release V=1
make[1]: Entering directory '/tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/out'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/out'
ln -fs out/Release/node node
Running main() from gtest_main.cc
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from UtilTest
[ RUN  ] UtilTest.ListHead
[   OK ] UtilTest.ListHead (0 ms)
[--] 1 test from UtilTest (0 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test case ran. (0 ms total)
[  PASSED  ] 1 test.
/gnu/store/vcx1n5nj4gr52xx5m6gvi7zrwngy06s3-python-2.7.11/bin/python 
tools/test.py --mode=release message parallel sequential -J
=== release test-tls-alpn-server-client ===
Path: parallel/test-tls-alpn-server-client
assert.js:90
  throw new assert.AssertionError({
  ^
AssertionError: 'first-priority-unsupported' === false
at checkResults 
(/tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/test/parallel/test-tls-alpn-server-client.js:32:10)
at 
/tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/test/parallel/test-tls-alpn-server-client.js:101:5
at TLSSocket. 
(/tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/test/parallel/test-tls-alpn-server-client.js:66:9)
at TLSSocket.g (events.js:286:16)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket. (_tls_wrap.js:1072:16)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket._finishInit (_tls_wrap.js:580:8)
Command: out/Release/node 
/tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/test/parallel/test-tls-alpn-server-client.js
[01:28|% 100|+ 1077|-   1]: Done   
make: *** [Makefile:118: test] Error 1
phase `check' failed after 89.5 seconds
builder for `/gnu/store/x4x6j7d4sgf888iijkf9brjb38b94h8z-node-6.0.0.drv' failed 
with exit code 1
@ build-failed /gnu/store/x4x6j7d4sgf888iijkf9brjb38b94h8z-node-6.0.0.drv - 1 
builder for `/gnu/store/x4x6j7d4sgf888iijkf9brjb38b94h8z-node-6.0.0.drv' failed 
with exit code 1
guix build: error: build failed: build of 
`/gnu/store/x4x6j7d4sgf888iijkf9brjb38b94h8z-node-6.0.0.drv' failed
Cannot open display "default display"
derivation '/gnu/store/x4x6j7d4sgf888iijkf9brjb38b94h8z-node-6.0.0.drv' 
offloaded to '192.168.1.198' failed with exit code 1
@ build-failed /gnu/store/x4x6j7d4sgf888iijkf9brjb38b94h8z-node-6.0.0.drv - 1 
builder for `/gnu/store/x4x6j7d4sgf888iijkf9brjb38b94h8z-node-6.0.0.drv' failed 
with exit code 100
cannot build derivation 
`/gnu/store/11sh5qwmp7a0pbb8hccmlymhc6l3i588-mastodon-0.7.drv': 1 dependencies 
couldn't be built
guix build: error: build failed: build of 
`/gnu/store/11sh5qwmp7a0pbb8hccmlymhc6l3i588-mastodon-0.7.drv' failed




[0]: http://hydra.gnu.org/job/gnu/core-updates/node-6.0.0.x86_64-linux

Developing libraries for the GNU system with Guix

[sbaugh]

Hi guix-devel,

When I am hacking on some library Z, I continuously want to test the
effects that my changes to Z have on packages A/B/C which depend on
Z. The same applies, in general, when hacking on any package Z which
other packages A/B/C depend on: While developing, I want to be able to
rapidly mutate Z and see how this affects A/B/C.

I am not sure how to best achieve this. Here are some solutions:

- When you change Z, rebuild A/B/C.
  This is much too slow at present.

- Use grafts to update A/B/C through binary patching.
  This is also too slow, and AFAIK it can't really be sped up.

- Use LD_LIBRARY_PATH to cause A/B/C to search for Z in a mutable place.
  This works for C libraries, but not generically; there are equivalent
  variables for some other languages but it's not a full solution.

- Before starting to hack on Z, build a new version of Z which includes
  a random hash and which A/B/C depend on; then bind-mount a mutable
  directory on top of that. (suggested by mark_weaver on IRC)
  This is the most palatable hack, but still a hack. The inclusion of a
  random hash prevents collision with other packages and the use of
  bind-mounting means we aren't actually mutating the store. This
  unfortunately also requires privileges: it's not usable by
  unprivileged users.

Here are some not currently available possibilities:

- Create some kind of GUIX_LIBRARY_PATH in which packages are looked up
  first before looking at the compiled-in hash.
  This would be an attempt to make a generic equivalent of
  LD_LIBRARY_PATH. This could theoretically be implemented with variant
  symlinks, if they were available: https://lwn.net/Articles/680705/

- Currently every dependency is located at a well known globally unique
  and globally meaningful path; add some kind of "variant package"
  construct which specifies a package which is "passed in" to the
  environment (maybe by bind-mounting it in a filesystem namespace;
  implementation specifics aren't important). To put this in a
  programming language sense, one of these packages being present would
  turn a Guix distribution from a value into a function.

- Massively speed up rebuilding A/B/C by performing incremental
  builds. Not sure how exactly this could work, it's just a thought.

What do you think, guix-devel?

By the way, I think this is a pretty important feature overall (though
it's described in fairly abstract terms in this email). I think this is
one of the last missing features to make the Guix approach a clear and
uncontroversial improvement over existing widespread practices.

Re: [PATCH 1/2] gnu: Add emacs-goto-chg.

[ng0]

Hi,

thanks for the review.

Alex Kost  writes:

> ng0 (2016-10-12 23:00 +) wrote:
>
>> * gnu/packages/emacs.scm (emacs-goto-chg): New variable.
>> ---
>>  gnu/packages/emacs.scm | 26 +-
>>  1 file changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
>> index 1b345db..f04b71d 100644
>> --- a/gnu/packages/emacs.scm
>> +++ b/gnu/packages/emacs.scm
>> @@ -12,7 +12,7 @@
>>  ;;; Copyright © 2016 David Thompson 
>>  ;;; Copyright © 2016 Matthew Jordan 
>>  ;;; Copyright © 2016 Roel Janssen 
>> -;;; Copyright © 2016 ng0 
>> +;;; Copyright © 2016 ng0 
>>  ;;; Copyright © 2016 Alex Griffin 
>>  ;;; Copyright © 2016 Nicolas Goaziou 
>>  ;;; Copyright © 2016 Alex Vong 
>> @@ -2981,6 +2981,30 @@ Lua programing language}.")
>>  news items, openrc and runscripts.")
>>  (license license:gpl2+)))
>>  
>> +(define-public emacs-goto-chg
>> +  (package
>> +(name "emacs-goto-chg")
>> +(version "20131228.659")
>> +(source
>> + (origin
>> +   (method url-fetch)
>> +   (uri (string-append
>> + "http://melpa.org/packages/goto-chg-";
>> + version ".el"))
>
> Although the source of this package is the emacswiki, I used it here as
> well, also I changed the version to "1.6" (according to source).

Oh.. thanks!

>> +   (sha256
>> +(base32
>> + "1763qs6xprbb86bsxs4sh35rdcnb3v1zam4pc2akkd4wimg83k2l"
>> +(build-system emacs-build-system)
>> +;; This is correct, the source/www is a wiki.
>> +(home-page "http://www.emacswiki.org/emacs/goto-chg.el";)
>> +(synopsis "Go to last change")
>> +(description
>> + "Goto-Chg goes to the point of the most recent edit in the
>> +buffer.  When repeated, go to the second most recent edit, etc.
>> +Negative argument, C-u -, for reverse direction.  Works by
>> +looking into buffer-undo-list to find points of edit.")
>
> I rephrased the description a bit to mention 'goto-last-change' command.
>
>> +(license license:gpl3+)))
>
> This is actually gpl2+

Don't rely on what other services/sites point out I'd say. Thanks for
correction.

>> +
>>  (define-public emacs-writegood-mode
>>(package
>>  (name "emacs-writegood-mode")
>
> Applied as ce74e520115a6d51b237a953fdf1468bc2b54d44, thanks!
>
> -- 
> Alex
>

-- 
♥Ⓐ  ng0

Re: [PATCH 0/1] Dbus update 1.10.12 for core-updates

[Leo Famulari]

On Thu, Oct 13, 2016 at 10:19:56PM +0200, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> > But, I found that the regular approach to grafting does not work for our
> > dbus package. Presumably, it's because (gnu packages glib) exports dbus
> > before defining it.
> 
> The #:export at the top shouldn’t make any difference.  In what way does
> it not work?  :-)

I think I must have made some mistake before — it works for me now and I
just pushed it to master and core-updates.

> Could it be an instance of ?

I did a quick test with the package 'lash' and lash does refer to the
grafted dbus:

$ ./pre-inst-env guix build dbus --no-grafts
/gnu/store/bmlkg9mbqj1k0y7kdq2rdll42aicglyk-dbus-1.10.8
$ ./pre-inst-env guix build dbus
/gnu/store/j8zrqkcdp849q391hj9wrbz3a98zs128-dbus-1.10.8
$ guix gc --references $(./pre-inst-env guix build lash) | grep dbus
/gnu/store/j8zrqkcdp849q391hj9wrbz3a98zs128-dbus-1.10.8   


signature.asc
Description: PGP signature

Re: node is failing

[Pjotr Prins]

On Thu, Oct 13, 2016 at 10:55:26PM +, ng0 wrote:
> I know many things are failing right now, but I do not have enough
> knowledge of node to understand why the test suite fails suddenly. Maybe
> some dependency needed only for the test which is failing before node?
> 
> 
> === release test-tls-alpn-server-client ===   
>  
> Path: parallel/test-tls-alpn-server-client
> assert.js:90
>   throw new assert.AssertionError({
>   ^
> AssertionError: 'first-priority-unsupported' === false
> at checkResults 
> (/tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/test/parallel/test-tls-alpn-server-client.js:32:10)
> at 
> /tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/test/parallel/test-tls-alpn-server-client.js:101:5
> at TLSSocket. 
> (/tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/test/parallel/test-tls-alpn-server-client.js:66:9)
> at TLSSocket.g (events.js:286:16)
> at emitNone (events.js:86:13)
> at TLSSocket.emit (events.js:185:7)
> at TLSSocket. (_tls_wrap.js:1072:16)
> at emitNone (events.js:86:13)
> at TLSSocket.emit (events.js:185:7)
> at TLSSocket._finishInit (_tls_wrap.js:580:8)
> Command: out/Release/node 
> /tmp/guix-build-node-6.0.0.drv-0/node-v6.0.0/test/parallel/test-tls-alpn-server-client.js
> [01:28|% 100|+ 1077|-   1]: Done  
>  
> make: *** [Makefile:118: test] Error 1

libtls updates have been cause for more errors the last months. I suggest
disabling this test for now. Someone posted a patch for a node update
earlier, but that also has errors - trying to use network sockets in a
test.

The sane thing to do here is upgrade to the latest patch and disable
the few failing tests. Node has been broken in Guix since late July -
and that is not good. This is an important package.

Pj.