Gnunet-0.10.0 recipe

Gnunet-0.10.0 recipe

[Sree Harsha Totakura]

Hi,

Here is the much awaited recipe for GNUnet.  The patches follow this email.

The first patch removes Gstreamer as a dependency for libextractor.
This is required as Gstreamer currently appears to be broken (see
http://lists.nongnu.org/archive/html/bug-guix/2014-01/msg00026.html) and
this prevent libextractor from building which is required for gnunet.

The second patch actually provides the recipe for gnunet.  The patches
associated with it are already pushed into upstream.  These can be
safely removed after the next release.

Regards,
Sree

[PATCH 1/2] gnu: gnunet: Remove Gstreamer dependency.

[Sree Harsha Totakura]

* gnu/packages/gnunet (libextractor): Remove Gstreamer dependency as it is currently broken.
---
 gnu/packages/gnunet.scm |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 6af9063..4a50fd7 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -76,8 +76,9 @@
       ("ffmpeg" ,ffmpeg)
       ("gettext" ,gnu-gettext)
       ("glib" ,glib)
-      ("gstreamer" ,gstreamer)
-      ("gst-plugins-base" ,gst-plugins-base)
+      ;; FIXME: Gstreamer is currently broken; add it up when it is fixed
+      ;; ("gstreamer" ,gstreamer)
+      ;; ("gst-plugins-base" ,gst-plugins-base)
       ("libjpeg" ,libjpeg)
       ("libogg" ,libogg)
       ("libtiff" ,libtiff)
-- 
1.7.10.4

[PATCH 2/2] gnu: gnunet: Add gnunet-0.10.0.

[Sree Harsha Totakura]

* gnunet/packages/gnunet.scm (gnunet): New variable.  Thanks to Zerwas for the initial recipe.
* gnu/package/patches/gnunet-fix-scheduler.patch: Patch to fix bug in Gnunet's scheduler.
* gnu/package/patches/gnunet-fix-tests.patch: Patch to fix bugs in testcases and to disable testscases which rely on name resolution.
* gnu-system.am (dist_patch_DATA): Add the above two patch files.
---
 gnu-system.am                                   |    2 +
 gnu/packages/gnunet.scm                         |   62 +++++++++++++++++++++++
 gnu/packages/patches/gnunet-fix-scheduler.patch |   13 +++++
 gnu/packages/patches/gnunet-fix-tests.patch     |   46 +++++++++++++++++
 4 files changed, 123 insertions(+)
 create mode 100644 gnu/packages/patches/gnunet-fix-scheduler.patch
 create mode 100644 gnu/packages/patches/gnunet-fix-tests.patch

diff --git a/gnu-system.am b/gnu-system.am
index 1f7327e..da35ad0 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -255,6 +255,8 @@ dist_patch_DATA =						\
   gnu/packages/patches/glibc-bootstrap-system.patch		\
   gnu/packages/patches/glibc-ldd-x86_64.patch			\
   gnu/packages/patches/glibc-make-4.0.patch			\
+  gnu/packages/patches/gnunet-fix-scheduler.patch		\
+  gnu/packages/patches/gnunet-fix-tests.patch    		\
   gnu/packages/patches/gobject-introspection-cc.patch		\
   gnu/packages/patches/grub-gets-undeclared.patch		\
   gnu/packages/patches/gstreamer-0.10-bison3.patch		\
diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 4a50fd7..cc7782f 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -17,6 +17,7 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu packages gnunet)
+  #:use-module (gnu packages)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages curl)
@@ -30,10 +31,14 @@
   #:use-module (gnu packages libidn)
   #:use-module (gnu packages libjpeg)
   #:use-module (gnu packages libtiff)
+  #:use-module (gnu packages libunistring)
+  #:use-module (gnu packages maths)
   #:use-module (gnu packages openssl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages perl)
+  #:use-module (gnu packages pulseaudio)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages sqlite)
   #:use-module (gnu packages video)
   #:use-module (gnu packages xiph)
   #:use-module ((guix licenses)
@@ -185,3 +190,60 @@ supports HTTPS, HTTPS and GnuTLS.")
    (license (license:bsd-style "file://COPYING"
                        "See COPYING in the distribution."))
    (home-page "https://gnunet.org/gnurl")))
+
+(define-public gnunet
+  (package
+   (name "gnunet")
+   (version "0.10.0")
+   (source (origin
+             (method url-fetch)
+             (uri (string-append "mirror://gnu/gnunet/gnunet-" version
+                                 ".tar.gz"))
+             (sha256 (base32
+                      "0zqpc47kywhjrpphl0palz849khv00ra2gjrfkysp6p0gfsbvd0i"))
+             (patches (list (search-patch "gnunet-fix-scheduler.patch")
+                            (search-patch "gnunet-fix-tests.patch")))
+             (patch-flags '("-p0"))))
+   (build-system gnu-build-system)
+   (inputs
+    `(("gnutls" ,gnutls)
+      ("glpk" ,glpk)
+      ("libextractor" ,libextractor)
+      ("libgcrypt" ,libgcrypt)
+      ("gnurl" ,gnurl)
+      ("libidn" ,libidn)
+      ("opus" ,opus)
+      ("libtool" ,libtool)
+      ("libunistring" ,libunistring)
+      ("pulseaudio", pulseaudio)
+      ("sqlite" ,sqlite)
+      ("zlib" ,zlib)))
+   (native-inputs
+    `(("pkg-config" ,pkg-config)
+      ("python" ,python-2)))
+   (arguments
+    '(#:phases
+      (let* ((check (assq 'check %standard-phases))
+             (alist (delete check %standard-phases))
+             (testsetup
+              (lambda* (#:key outputs #:allow-other-keys)
+                (let ((out (assoc-ref outputs "out")))
+                  (setenv "GNUNET_PREFIX" out)
+                  (setenv "PATH" (string-append (getenv "PATH") ":" out "/bin"))
+                  #t))))
+        (display %standard-phases)
+        (alist-cons-after 'testsetup (car check) (cdr check)
+                          (alist-cons-after 'install 'testsetup testsetup
+                                            alist)))))
+   (synopsis "Secure P2P networking framework with cool applications")
+   (description
+    "GNUnet is a framework for secure peer-to-peer networking that does not
+use any centralized or otherwise trusted services. Our high-level goal is to
+provide a strong free software foundation for a global network that provides
+security and in particular respects privacy.  GNUnet started with an idea for
+anonymous censorship-resistant file-sharing, but has grown to incorporate
+other applications as well as many generic building blocks for secure
+networking applications. In particular, GNUnet now includes the GNU Name
+System, a privacy-preserving, decentralized public key infrastructure")
+   (license license:gpl3+)
+   (home-page "https://gnunet.org/")))
diff --git a/gnu/packages/patches/gnunet-fix-scheduler.patch b/gnu/packages/patches/gnunet-fix-scheduler.patch
new file mode 100644
index 0000000..1e0aef2
--- /dev/null
+++ b/gnu/packages/patches/gnunet-fix-scheduler.patch
@@ -0,0 +1,13 @@
+Index: src/util/scheduler.c
+===================================================================
+--- src/util/scheduler.c	(revision 31745)
++++ src/util/scheduler.c	(working copy)
+@@ -1599,7 +1599,7 @@
+   int real_fd;
+ 
+   GNUNET_DISK_internal_file_handle_ (fd, &real_fd, sizeof (int));
+-  GNUNET_assert (real_fd > 0);
++  GNUNET_assert (real_fd >= 0);
+   return add_without_sets (
+       delay, priority,
+       on_read  ? real_fd : -1,
diff --git a/gnu/packages/patches/gnunet-fix-tests.patch b/gnu/packages/patches/gnunet-fix-tests.patch
new file mode 100644
index 0000000..1957b17
--- /dev/null
+++ b/gnu/packages/patches/gnunet-fix-tests.patch
@@ -0,0 +1,46 @@
+diff -ru a/src/peerinfo-tool/Makefile.in b/src/peerinfo-tool/Makefile.in
+--- src/peerinfo-tool/Makefile.in	2013-12-24 13:55:04.000000000 +0100
++++ src/peerinfo-tool/Makefile.in	2014-01-30 13:07:52.275965484 +0100
+@@ -335,9 +335,6 @@
+   $(top_builddir)/src/statistics/libgnunetstatistics.la \
+   $(top_builddir)/src/util/libgnunetutil.la 
+ 
+-@HAVE_PYTHON_TRUE@check_SCRIPTS = \
+-@HAVE_PYTHON_TRUE@ test_gnunet_peerinfo.py 
+-
+ @ENABLE_TEST_RUN_TRUE@TESTS = $(check_SCRIPTS)
+ do_subst = $(SED) -e 's,[@]PYTHON[@],$(PYTHON),g'
+ EXTRA_DIST = \
+diff -ru a/src/revocation/test_revocation.conf b/src/revocation/test_revocation.conf
+--- src/revocation/test_revocation.conf	2013-12-21 18:57:06.000000000 +0100
++++ src/revocation/test_revocation.conf	2014-01-30 15:00:02.841340556 +0100
+@@ -20,6 +20,9 @@
+ [transport-udp]
+ BROADCAST = NO
+ 
++[nat]
++RETURN_LOCAL_ADDRESSES = YES
++
+ [peerinfo]
+ USE_INCLUDED_HELLOS = NO
+ 
+Index: src/gns/test_gns_cname_lookup.sh
+===================================================================
+--- src/gns/test_gns_cname_lookup.sh	(revision 32117)
++++ src/gns/test_gns_cname_lookup.sh	(revision 32118)
+@@ -13,6 +13,15 @@
+ 	exit 77
+ fi
+ 
++# permissive DNS resolver we will use for the test
++DNS_RESOLVER="8.8.8.8"
++if ! nslookup gnunet.org $DNS_RESOLVER &> /dev/null
++then
++  echo "Cannot reach DNS, skipping test"
++  exit 77
++fi
++
++
+ rm -rf /tmp/test-gnunet-gns-peer-1/
+ 
+ TEST_DOMAIN_PLUS="www.gnu"
-- 
1.7.10.4

Re: [PATCH 2/2] gnu: gnunet: Add gnunet-0.10.0.

[Ludovic Courtès]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> * gnunet/packages/gnunet.scm (gnunet): New variable.  Thanks to Zerwas for the initial recipe.
> * gnu/package/patches/gnunet-fix-scheduler.patch: Patch to fix bug in Gnunet's scheduler.
> * gnu/package/patches/gnunet-fix-tests.patch: Patch to fix bugs in testcases and to disable testscases which rely on name resolution.
> * gnu-system.am (dist_patch_DATA): Add the above two patch files.

Excellent!

Can you wrap lines to ~75 chars?  Also, you can use ‘Co-authored-by:
Zerwas’ if deemed appropriate here.

s/Gnunet/GNUnet/

The .patch files above should just have “New files” in the commit log
(see other commits for examples.)  However, can you please move the
description of what the patches do at the top of the patches themselves,
possibly with a reference to the upstream commit/bug report/discussion?

> +   (arguments
> +    '(#:phases
> +      (let* ((check (assq 'check %standard-phases))
> +             (alist (delete check %standard-phases))
> +             (testsetup
> +              (lambda* (#:key outputs #:allow-other-keys)
> +                (let ((out (assoc-ref outputs "out")))
> +                  (setenv "GNUNET_PREFIX" out)
> +                  (setenv "PATH" (string-append (getenv "PATH") ":" out "/bin"))
> +                  #t))))
> +        (display %standard-phases)
> +        (alist-cons-after 'testsetup (car check) (cdr check)
> +                          (alist-cons-after 'install 'testsetup testsetup
> +                                            alist)))))

I think the ‘display’ is a leftover, right?  ;-)

I would rather write it this way:

  (let* ((check (assq-ref %standard-phases 'check))
         (pre-check
           (lambda* ...)))
    (alist-cons-after 'pre-check 'check check
                      (alist-cons-after 'install 'pre-check pre-check
                                        (alist-delete 'check
                                                       %standard-phases))))

(Woow, this ought to be simpler...)

> +   (synopsis "Secure P2P networking framework with cool applications")
> +   (description
> +    "GNUnet is a framework for secure peer-to-peer networking that does not
> +use any centralized or otherwise trusted services. Our high-level goal is to
> +provide a strong free software foundation for a global network that provides
> +security and in particular respects privacy.  GNUnet started with an idea for
> +anonymous censorship-resistant file-sharing, but has grown to incorporate
> +other applications as well as many generic building blocks for secure
> +networking applications. In particular, GNUnet now includes the GNU Name
> +System, a privacy-preserving, decentralized public key infrastructure")

Could you run ‘make sync-descriptions’ and use whatever synopsis and
description it suggests?  (That comes from the canonical GNU package
database.)

Thanks for the nice work!

Ludo’.

Re: Gnunet-0.10.0 recipe

[Andreas Enge]

Hello,

On Thu, Jan 30, 2014 at 05:36:03PM +0100, Sree Harsha Totakura wrote:
> Here is the much awaited recipe for GNUnet.  The patches follow this email.

excellent! I also worked on gnunet and think my handling of phases is
a bit simpler and clearer:

   (arguments
    `(#:phases
        ;; swap check and install phases and set paths to installed binaries
        (alist-cons-before
         'check 'set-path-for-check
         (lambda* (#:key outputs #:allow-other-keys)
          (let ((out (assoc-ref outputs "out")))
           (setenv "GNUNET_PREFIX" out)
           (setenv "PATH" (string-append (getenv "PATH") ":" out "/bin"))))
        (alist-cons-after
         'install 'check
         (assoc-ref %standard-phases 'check)
        (alist-delete
         'check
        %standard-phases)))))

(where the 'set-path-for-check phase will be made obsolete by the recent
gnunet modification I suggested in its bug tracker).

We have slightly different inputs; what is opus needed for? Apart from that,
I have additional inputs:
      ("libmicrohttpd" ,libmicrohttpd)
      ("openssl" ,openssl) ; needed for some tests creating TLS certificates

Maybe openssl is a remainder from an earlier gnunet version and not needed/
used anymore?

Andreas

[PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Sree Harsha Totakura]

    * gnunet/packages/gnunet.scm (gnunet): New variable.
    * gnu/package/patches/gnunet-fix-scheduler.patch: New file.
    * gnu/package/patches/gnunet-fix-tests.patch: New file.
    * gnu-system.am (dist_patch_DATA): Add the above two patch files.
---
 gnu-system.am                                   |    2 +
 gnu/packages/gnunet.scm                         |   67 +++++++++++++++++++++++
 gnu/packages/patches/gnunet-fix-scheduler.patch |   13 +++++
 gnu/packages/patches/gnunet-fix-tests.patch     |   46 ++++++++++++++++
 4 files changed, 128 insertions(+)
 create mode 100644 gnu/packages/patches/gnunet-fix-scheduler.patch
 create mode 100644 gnu/packages/patches/gnunet-fix-tests.patch

diff --git a/gnu-system.am b/gnu-system.am
index 1f7327e..da35ad0 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -255,6 +255,8 @@ dist_patch_DATA =						\
   gnu/packages/patches/glibc-bootstrap-system.patch		\
   gnu/packages/patches/glibc-ldd-x86_64.patch			\
   gnu/packages/patches/glibc-make-4.0.patch			\
+  gnu/packages/patches/gnunet-fix-scheduler.patch		\
+  gnu/packages/patches/gnunet-fix-tests.patch    		\
   gnu/packages/patches/gobject-introspection-cc.patch		\
   gnu/packages/patches/grub-gets-undeclared.patch		\
   gnu/packages/patches/gstreamer-0.10-bison3.patch		\
diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 4a50fd7..e3c3b45 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -17,6 +17,7 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu packages gnunet)
+  #:use-module (gnu packages)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages curl)
@@ -30,10 +31,14 @@
   #:use-module (gnu packages libidn)
   #:use-module (gnu packages libjpeg)
   #:use-module (gnu packages libtiff)
+  #:use-module (gnu packages libunistring)
+  #:use-module (gnu packages maths)
   #:use-module (gnu packages openssl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages perl)
+  #:use-module (gnu packages pulseaudio)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages sqlite)
   #:use-module (gnu packages video)
   #:use-module (gnu packages xiph)
   #:use-module ((guix licenses)
@@ -185,3 +190,65 @@ supports HTTPS, HTTPS and GnuTLS.")
    (license (license:bsd-style "file://COPYING"
                        "See COPYING in the distribution."))
    (home-page "https://gnunet.org/gnurl")))
+
+(define-public gnunet
+  (package
+   (name "gnunet")
+   (version "0.10.0")
+   (source
+    (origin
+      (method url-fetch)
+      (uri (string-append "mirror://gnu/gnunet/gnunet-" version
+                          ".tar.gz"))
+      (sha256 (base32
+               "0zqpc47kywhjrpphl0palz849khv00ra2gjrfkysp6p0gfsbvd0i"))
+      (patches
+       (list
+        ;; Patch to fix serious bug in scheduler; upstream commit: #31747
+        (search-patch "gnunet-fix-scheduler.patch")
+        ;; Patch to fix bugs in testcases:
+        ;; * Disable peerinfo-tool tests as they depend on reverse DNS lookups
+        ;; * Allow revocation testcase to run on loopback; upstream: #32130
+        ;; * Skip GNS testcases requiring DNS lookups; upstream: #32118
+        (search-patch "gnunet-fix-tests.patch")))
+      (patch-flags '("-p0"))))
+   (build-system gnu-build-system)
+   (inputs
+    `(("gnutls" ,gnutls)
+      ("glpk" ,glpk)
+      ("libextractor" ,libextractor)
+      ("libgcrypt" ,libgcrypt)
+      ("gnurl" ,gnurl)
+      ("libidn" ,libidn)
+      ("opus" ,opus)
+      ("libtool" ,libtool)
+      ("libunistring" ,libunistring)
+      ("pulseaudio", pulseaudio)
+      ("sqlite" ,sqlite)
+      ("zlib" ,zlib)))
+   (native-inputs
+    `(("pkg-config" ,pkg-config)
+      ("python" ,python-2)))
+   (arguments
+    '(#:phases
+      (let* ((check (assq-ref %standard-phases 'check))
+             (pre-check
+              (lambda* (#:key outputs #:allow-other-keys)
+                (let ((out (assoc-ref outputs "out")))
+                  (setenv "GNUNET_PREFIX" out)
+                  (setenv "PATH" (string-append
+                                  (getenv "PATH") ":" out "/bin"))
+                  #t))))
+        (alist-cons-after 'pre-check 'check check
+                          (alist-cons-after 'install 'pre-check pre-check
+                                            (alist-delete
+                                             'check %standard-phases))))))
+   (synopsis "Anonymous peer-to-peer file-sharing framework")
+   (description
+    "GNUnet is a framework for secure, peer-to-peer networking.  It works in a
+decentralized manner and does not rely on any notion of trusted services.  One
+service implemented on it is censorship-resistant file-sharing.  Communication
+is encrypted and anonymity is provided by making messages originating from a
+peer indistinguishable from those that the peer is routing.")
+   (license license:gpl3+)
+   (home-page "https://gnunet.org/")))
diff --git a/gnu/packages/patches/gnunet-fix-scheduler.patch b/gnu/packages/patches/gnunet-fix-scheduler.patch
new file mode 100644
index 0000000..1e0aef2
--- /dev/null
+++ b/gnu/packages/patches/gnunet-fix-scheduler.patch
@@ -0,0 +1,13 @@
+Index: src/util/scheduler.c
+===================================================================
+--- src/util/scheduler.c	(revision 31745)
++++ src/util/scheduler.c	(working copy)
+@@ -1599,7 +1599,7 @@
+   int real_fd;
+ 
+   GNUNET_DISK_internal_file_handle_ (fd, &real_fd, sizeof (int));
+-  GNUNET_assert (real_fd > 0);
++  GNUNET_assert (real_fd >= 0);
+   return add_without_sets (
+       delay, priority,
+       on_read  ? real_fd : -1,
diff --git a/gnu/packages/patches/gnunet-fix-tests.patch b/gnu/packages/patches/gnunet-fix-tests.patch
new file mode 100644
index 0000000..1957b17
--- /dev/null
+++ b/gnu/packages/patches/gnunet-fix-tests.patch
@@ -0,0 +1,46 @@
+diff -ru a/src/peerinfo-tool/Makefile.in b/src/peerinfo-tool/Makefile.in
+--- src/peerinfo-tool/Makefile.in	2013-12-24 13:55:04.000000000 +0100
++++ src/peerinfo-tool/Makefile.in	2014-01-30 13:07:52.275965484 +0100
+@@ -335,9 +335,6 @@
+   $(top_builddir)/src/statistics/libgnunetstatistics.la \
+   $(top_builddir)/src/util/libgnunetutil.la 
+ 
+-@HAVE_PYTHON_TRUE@check_SCRIPTS = \
+-@HAVE_PYTHON_TRUE@ test_gnunet_peerinfo.py 
+-
+ @ENABLE_TEST_RUN_TRUE@TESTS = $(check_SCRIPTS)
+ do_subst = $(SED) -e 's,[@]PYTHON[@],$(PYTHON),g'
+ EXTRA_DIST = \
+diff -ru a/src/revocation/test_revocation.conf b/src/revocation/test_revocation.conf
+--- src/revocation/test_revocation.conf	2013-12-21 18:57:06.000000000 +0100
++++ src/revocation/test_revocation.conf	2014-01-30 15:00:02.841340556 +0100
+@@ -20,6 +20,9 @@
+ [transport-udp]
+ BROADCAST = NO
+ 
++[nat]
++RETURN_LOCAL_ADDRESSES = YES
++
+ [peerinfo]
+ USE_INCLUDED_HELLOS = NO
+ 
+Index: src/gns/test_gns_cname_lookup.sh
+===================================================================
+--- src/gns/test_gns_cname_lookup.sh	(revision 32117)
++++ src/gns/test_gns_cname_lookup.sh	(revision 32118)
+@@ -13,6 +13,15 @@
+ 	exit 77
+ fi
+ 
++# permissive DNS resolver we will use for the test
++DNS_RESOLVER="8.8.8.8"
++if ! nslookup gnunet.org $DNS_RESOLVER &> /dev/null
++then
++  echo "Cannot reach DNS, skipping test"
++  exit 77
++fi
++
++
+ rm -rf /tmp/test-gnunet-gns-peer-1/
+ 
+ TEST_DOMAIN_PLUS="www.gnu"
-- 
1.7.10.4

Re: Gnunet-0.10.0 recipe

[Sree Harsha Totakura]

On 01/30/2014 11:39 PM, Andreas Enge wrote:
> On Thu, Jan 30, 2014 at 05:36:03PM +0100, Sree Harsha Totakura wrote:
>> > Here is the much awaited recipe for GNUnet.  The patches follow this email.
> excellent! I also worked on gnunet and think my handling of phases is
> a bit simpler and clearer:
> 
>    (arguments
>     `(#:phases
>         ;; swap check and install phases and set paths to installed binaries
>         (alist-cons-before
>          'check 'set-path-for-check
>          (lambda* (#:key outputs #:allow-other-keys)
>           (let ((out (assoc-ref outputs "out")))
>            (setenv "GNUNET_PREFIX" out)
>            (setenv "PATH" (string-append (getenv "PATH") ":" out "/bin"))))
>         (alist-cons-after
>          'install 'check
>          (assoc-ref %standard-phases 'check)
>         (alist-delete
>          'check
>         %standard-phases)))))
> 
Yes, this looks better, perhaps Ludo can replace the relevant part with
this.

> (where the 'set-path-for-check phase will be made obsolete by the recent
> gnunet modification I suggested in its bug tracker).
Yes, this will be made obsolete.

> 
> We have slightly different inputs; what is opus needed for? Apart from that,

We now have a new voice-chat service called conversation.  Opus is the
audio codec it requires, hence the new dependency.

> I have additional inputs:
>       ("libmicrohttpd" ,libmicrohttpd)
>       ("openssl" ,openssl) ; needed for some tests creating TLS certificates
> 
> Maybe openssl is a remainder from an earlier gnunet version and not needed/
> used anymore?

The README mentions openssl as a requirement; I forgot to add it.
Perhaps the build didn't build relevant parts or testcases.

I shall try adding the openssl dependency and see how it goes.

Sree

Re: Gnunet-0.10.0 recipe

[Sree Harsha Totakura]

Here's the new patch with Andreas' changes and Openssl included as a
dependency.

Sree

On 01/30/2014 11:56 PM, Sree Harsha Totakura wrote:
> Yes, this looks better, perhaps Ludo can replace the relevant part with
> this.
> 
>> > (where the 'set-path-for-check phase will be made obsolete by the recent
>> > gnunet modification I suggested in its bug tracker).
> Yes, this will be made obsolete.
> 
>> > 
>> > We have slightly different inputs; what is opus needed for? Apart from that,
> We now have a new voice-chat service called conversation.  Opus is the
> audio codec it requires, hence the new dependency.
> 
>> > I have additional inputs:
>> >       ("libmicrohttpd" ,libmicrohttpd)
>> >       ("openssl" ,openssl) ; needed for some tests creating TLS certificates
>> > 
>> > Maybe openssl is a remainder from an earlier gnunet version and not needed/
>> > used anymore?
> The README mentions openssl as a requirement; I forgot to add it.
> Perhaps the build didn't build relevant parts or testcases.
> 
> I shall try adding the openssl dependency and see how it goes.

[PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Sree Harsha Totakura]

    * gnunet/packages/gnunet.scm (gnunet): New variable.
    * gnu/package/patches/gnunet-fix-scheduler.patch: New file.
    * gnu/package/patches/gnunet-fix-tests.patch: New file.
    * gnu-system.am (dist_patch_DATA): Add the above two patch files.

Co-authored-by: Andreas Enge <andreas@enge.fr>
---
 gnu-system.am                                   |    2 +
 gnu/packages/gnunet.scm                         |   69 +++++++++++++++++++++++
 gnu/packages/patches/gnunet-fix-scheduler.patch |   13 +++++
 gnu/packages/patches/gnunet-fix-tests.patch     |   46 +++++++++++++++
 4 files changed, 130 insertions(+)
 create mode 100644 gnu/packages/patches/gnunet-fix-scheduler.patch
 create mode 100644 gnu/packages/patches/gnunet-fix-tests.patch

diff --git a/gnu-system.am b/gnu-system.am
index 1f7327e..da35ad0 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -255,6 +255,8 @@ dist_patch_DATA =						\
   gnu/packages/patches/glibc-bootstrap-system.patch		\
   gnu/packages/patches/glibc-ldd-x86_64.patch			\
   gnu/packages/patches/glibc-make-4.0.patch			\
+  gnu/packages/patches/gnunet-fix-scheduler.patch		\
+  gnu/packages/patches/gnunet-fix-tests.patch    		\
   gnu/packages/patches/gobject-introspection-cc.patch		\
   gnu/packages/patches/grub-gets-undeclared.patch		\
   gnu/packages/patches/gstreamer-0.10-bison3.patch		\
diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 4a50fd7..887b3d0 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -17,6 +17,7 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu packages gnunet)
+  #:use-module (gnu packages)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages curl)
@@ -30,10 +31,14 @@
   #:use-module (gnu packages libidn)
   #:use-module (gnu packages libjpeg)
   #:use-module (gnu packages libtiff)
+  #:use-module (gnu packages libunistring)
+  #:use-module (gnu packages maths)
   #:use-module (gnu packages openssl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages perl)
+  #:use-module (gnu packages pulseaudio)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages sqlite)
   #:use-module (gnu packages video)
   #:use-module (gnu packages xiph)
   #:use-module ((guix licenses)
@@ -185,3 +190,67 @@ supports HTTPS, HTTPS and GnuTLS.")
    (license (license:bsd-style "file://COPYING"
                        "See COPYING in the distribution."))
    (home-page "https://gnunet.org/gnurl")))
+
+(define-public gnunet
+  (package
+   (name "gnunet")
+   (version "0.10.0")
+   (source
+    (origin
+      (method url-fetch)
+      (uri (string-append "mirror://gnu/gnunet/gnunet-" version
+                          ".tar.gz"))
+      (sha256 (base32
+               "0zqpc47kywhjrpphl0palz849khv00ra2gjrfkysp6p0gfsbvd0i"))
+      (patches
+       (list
+        ;; Patch to fix serious bug in scheduler; upstream commit: #31747
+        (search-patch "gnunet-fix-scheduler.patch")
+        ;; Patch to fix bugs in testcases:
+        ;; * Disable peerinfo-tool tests as they depend on reverse DNS lookups
+        ;; * Allow revocation testcase to run on loopback; upstream: #32130
+        ;; * Skip GNS testcases requiring DNS lookups; upstream: #32118
+        (search-patch "gnunet-fix-tests.patch")))
+      (patch-flags '("-p0"))))
+   (build-system gnu-build-system)
+   (inputs
+    `(("gnutls" ,gnutls)
+      ("glpk" ,glpk)
+      ("libextractor" ,libextractor)
+      ("libgcrypt" ,libgcrypt)
+      ("gnurl" ,gnurl)
+      ("libidn" ,libidn)
+      ("openssl" ,openssl)
+      ("opus" ,opus)
+      ("libtool" ,libtool)
+      ("libunistring" ,libunistring)
+      ("pulseaudio", pulseaudio)
+      ("sqlite" ,sqlite)
+      ("zlib" ,zlib)))
+   (native-inputs
+    `(("pkg-config" ,pkg-config)
+      ("python" ,python-2)))
+   (arguments
+    '(#:phases
+        ;; swap check and install phases and set paths to installed binaries
+        (alist-cons-before
+         'check 'set-path-for-check
+         (lambda* (#:key outputs #:allow-other-keys)
+          (let ((out (assoc-ref outputs "out")))
+           (setenv "GNUNET_PREFIX" out)
+           (setenv "PATH" (string-append (getenv "PATH") ":" out "/bin"))))
+        (alist-cons-after
+         'install 'check
+         (assoc-ref %standard-phases 'check)
+        (alist-delete
+         'check
+        %standard-phases)))))
+   (synopsis "Anonymous peer-to-peer file-sharing framework")
+   (description
+    "GNUnet is a framework for secure, peer-to-peer networking.  It works in a
+decentralized manner and does not rely on any notion of trusted services.  One
+service implemented on it is censorship-resistant file-sharing.  Communication
+is encrypted and anonymity is provided by making messages originating from a
+peer indistinguishable from those that the peer is routing.")
+   (license license:gpl3+)
+   (home-page "https://gnunet.org/")))
diff --git a/gnu/packages/patches/gnunet-fix-scheduler.patch b/gnu/packages/patches/gnunet-fix-scheduler.patch
new file mode 100644
index 0000000..1e0aef2
--- /dev/null
+++ b/gnu/packages/patches/gnunet-fix-scheduler.patch
@@ -0,0 +1,13 @@
+Index: src/util/scheduler.c
+===================================================================
+--- src/util/scheduler.c	(revision 31745)
++++ src/util/scheduler.c	(working copy)
+@@ -1599,7 +1599,7 @@
+   int real_fd;
+ 
+   GNUNET_DISK_internal_file_handle_ (fd, &real_fd, sizeof (int));
+-  GNUNET_assert (real_fd > 0);
++  GNUNET_assert (real_fd >= 0);
+   return add_without_sets (
+       delay, priority,
+       on_read  ? real_fd : -1,
diff --git a/gnu/packages/patches/gnunet-fix-tests.patch b/gnu/packages/patches/gnunet-fix-tests.patch
new file mode 100644
index 0000000..1957b17
--- /dev/null
+++ b/gnu/packages/patches/gnunet-fix-tests.patch
@@ -0,0 +1,46 @@
+diff -ru a/src/peerinfo-tool/Makefile.in b/src/peerinfo-tool/Makefile.in
+--- src/peerinfo-tool/Makefile.in	2013-12-24 13:55:04.000000000 +0100
++++ src/peerinfo-tool/Makefile.in	2014-01-30 13:07:52.275965484 +0100
+@@ -335,9 +335,6 @@
+   $(top_builddir)/src/statistics/libgnunetstatistics.la \
+   $(top_builddir)/src/util/libgnunetutil.la 
+ 
+-@HAVE_PYTHON_TRUE@check_SCRIPTS = \
+-@HAVE_PYTHON_TRUE@ test_gnunet_peerinfo.py 
+-
+ @ENABLE_TEST_RUN_TRUE@TESTS = $(check_SCRIPTS)
+ do_subst = $(SED) -e 's,[@]PYTHON[@],$(PYTHON),g'
+ EXTRA_DIST = \
+diff -ru a/src/revocation/test_revocation.conf b/src/revocation/test_revocation.conf
+--- src/revocation/test_revocation.conf	2013-12-21 18:57:06.000000000 +0100
++++ src/revocation/test_revocation.conf	2014-01-30 15:00:02.841340556 +0100
+@@ -20,6 +20,9 @@
+ [transport-udp]
+ BROADCAST = NO
+ 
++[nat]
++RETURN_LOCAL_ADDRESSES = YES
++
+ [peerinfo]
+ USE_INCLUDED_HELLOS = NO
+ 
+Index: src/gns/test_gns_cname_lookup.sh
+===================================================================
+--- src/gns/test_gns_cname_lookup.sh	(revision 32117)
++++ src/gns/test_gns_cname_lookup.sh	(revision 32118)
+@@ -13,6 +13,15 @@
+ 	exit 77
+ fi
+ 
++# permissive DNS resolver we will use for the test
++DNS_RESOLVER="8.8.8.8"
++if ! nslookup gnunet.org $DNS_RESOLVER &> /dev/null
++then
++  echo "Cannot reach DNS, skipping test"
++  exit 77
++fi
++
++
+ rm -rf /tmp/test-gnunet-gns-peer-1/
+ 
+ TEST_DOMAIN_PLUS="www.gnu"
-- 
1.7.10.4

Re: Gnunet-0.10.0 recipe

[Andreas Enge]

On Fri, Jan 31, 2014 at 12:33:20AM +0100, Sree Harsha Totakura wrote:
> Here's the new patch with Andreas' changes and Openssl included as a
> dependency.

Thanks, I will have a look later.

Andreas

Re: Gnunet-0.10.0 recipe

[Ludovic Courtès]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> On 01/30/2014 11:39 PM, Andreas Enge wrote:

[...]

>> I have additional inputs:
>>       ("libmicrohttpd" ,libmicrohttpd)
>>       ("openssl" ,openssl) ; needed for some tests creating TLS certificates
>> 
>> Maybe openssl is a remainder from an earlier gnunet version and not needed/
>> used anymore?
>
> The README mentions openssl as a requirement; I forgot to add it.

Note for upstream: It would be great to use GnuTLS instead of OpenSSL,
especially given that OpenSSL’s license may be incompatible with the GPL
in this case.

Could you check with ‘guix gc --references $(guix build gnunet)’ if the
reference on OpenSSL is retained?  If not, that’s fine, but otherwise
that’s not cool.

Cheers,
Ludo’.

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Mark H Weaver]

Hi,

Sree Harsha Totakura <sreeharsha@totakura.in> writes:
> +    '(#:phases
> +        ;; swap check and install phases and set paths to installed binaries
> +        (alist-cons-before
> +         'check 'set-path-for-check
> +         (lambda* (#:key outputs #:allow-other-keys)
> +          (let ((out (assoc-ref outputs "out")))
> +           (setenv "GNUNET_PREFIX" out)
> +           (setenv "PATH" (string-append (getenv "PATH") ":" out "/bin"))))
> +        (alist-cons-after
> +         'install 'check
> +         (assoc-ref %standard-phases 'check)
> +        (alist-delete
> +         'check
> +        %standard-phases)))))

The indentation of this part (authored by Andreas) is misleading.  It
looks as though the calls to 'alist-*' are sibling expressions, when in
fact they are nested within each other.  I suspect this was intentional,
but IMO it's a bad idea to play such games with indentation.  I think it
should be like this:

--8<---------------cut here---------------start------------->8---
    '(#:phases
        ;; swap check and install phases and set paths to installed binaries
        (alist-cons-before
         'check 'set-path-for-check
         (lambda* (#:key outputs #:allow-other-keys)
          (let ((out (assoc-ref outputs "out")))
           (setenv "GNUNET_PREFIX" out)
           (setenv "PATH" (string-append (getenv "PATH") ":" out "/bin"))))
         (alist-cons-after
          'install 'check
          (assoc-ref %standard-phases 'check)
          (alist-delete
           'check
           %standard-phases)))))
--8<---------------cut here---------------end--------------->8---

What do you think?

      Mark

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> What do you think?

Right, we should generally stick to the “standard rule”, as noted in
‘HACKING’.

Ludo’.

Re: Gnunet-0.10.0 recipe

[Andreas Enge]

On Fri, Jan 31, 2014 at 09:54:04AM +0100, Andreas Enge wrote:
> On Fri, Jan 31, 2014 at 12:33:20AM +0100, Sree Harsha Totakura wrote:
> > Here's the new patch with Andreas' changes and Openssl included as a
> > dependency.
> Thanks, I will have a look later.

Finally I made it. For checking purposes, I disabled gstreamer and
gst-plugins-base in libextractor. gnunet built without problems and passed
all its tests - congratulations!

Just one last question: Is there a reason you did not add libmicrohttpd as
an input? Or should I add it again?

The "official" description printed with "make sync-descriptions" is different,
but in fact adds only this sentence:
   The package includes gnunet-gtk, which provides a GTK+ graphical user
   interface to the GNUnet service.
I think here the official description should be changed. First of all,
what is "the package"? And as far as I can tell, gnunet-gtk would be a
distinct package.

Andreas

Re: Gnunet-0.10.0 recipe

[Andreas Enge]

On Fri, Jan 31, 2014 at 05:05:37PM +0100, Ludovic Courtès wrote:
> Note for upstream: It would be great to use GnuTLS instead of OpenSSL,
> especially given that OpenSSL’s license may be incompatible with the GPL
> in this case.

From my trials, I think openssl is used only for "make check".
So it should probably pass into native-inputs.

> Could you check with ‘guix gc --references $(guix build gnunet)’ if the
> reference on OpenSSL is retained?  If not, that’s fine, but otherwise
> that’s not cool.

There is no reference to openssl left.

Andreas

Re: Gnunet-0.10.0 recipe

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Jan 31, 2014 at 05:05:37PM +0100, Ludovic Courtès wrote:
>> Note for upstream: It would be great to use GnuTLS instead of OpenSSL,
>> especially given that OpenSSL’s license may be incompatible with the GPL
>> in this case.
>
> From my trials, I think openssl is used only for "make check".
> So it should probably pass into native-inputs.
>
>> Could you check with ‘guix gc --references $(guix build gnunet)’ if the
>> reference on OpenSSL is retained?  If not, that’s fine, but otherwise
>> that’s not cool.
>
> There is no reference to openssl left.

OK, thanks for testing.  Then indeed, OpenSSL can be moved to
‘native-inputs’ (it won’t be used when cross-compiling anyway, right?).

Ludo’.

Re: Gnunet-0.10.0 recipe

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> The "official" description printed with "make sync-descriptions" is different,
> but in fact adds only this sentence:
>    The package includes gnunet-gtk, which provides a GTK+ graphical user
>    interface to the GNUnet service.
> I think here the official description should be changed. First of all,
> what is "the package"? And as far as I can tell, gnunet-gtk would be a
> distinct package.

Right.

For the record, patches for pkgblurbs.txt (the file containing those
descriptions in GNU Womb) should go to bug-womb@gnu.org.

Ludo’.

Re: Gnunet-0.10.0 recipe

[Sree Harsha Totakura]

On 02/03/2014 11:17 PM, Andreas Enge wrote:
> Just one last question: Is there a reason you did not add libmicrohttpd as
> an input? Or should I add it again?

I had forgotten to add it, nevertheless it should be added to the inputs
as it is a direct dependency.  But how did the build succeed if
libmicrohttpd were not listed in inputs?

> 
> The "official" description printed with "make sync-descriptions" is different,
> but in fact adds only this sentence:
>    The package includes gnunet-gtk, which provides a GTK+ graphical user
>    interface to the GNUnet service.
> I think here the official description should be changed. First of all,
> what is "the package"? And as far as I can tell, gnunet-gtk would be a
> distinct package.

The official GNU description and synopsis for GNUnet seems to be not
updated in a while.  It stresses only the file-sharing application while
it has now newer applications like GNS and Conversation.  Christian,
could you please update those?

Sree

Re: Gnunet-0.10.0 recipe

[Sree Harsha Totakura]

Hi Christian,

Does GNUnet use openssl while building or is it used only during `make
check`?

Sree

On 02/03/2014 11:57 PM, Ludovic Courtès wrote:
> Andreas Enge <andreas@enge.fr> skribis:
> 
>> > On Fri, Jan 31, 2014 at 05:05:37PM +0100, Ludovic Courtès wrote:
>>> >> Note for upstream: It would be great to use GnuTLS instead of OpenSSL,
>>> >> especially given that OpenSSL’s license may be incompatible with the GPL
>>> >> in this case.
>> >
>> > From my trials, I think openssl is used only for "make check".
>> > So it should probably pass into native-inputs.
>> >
>>> >> Could you check with ‘guix gc --references $(guix build gnunet)’ if the
>>> >> reference on OpenSSL is retained?  If not, that’s fine, but otherwise
>>> >> that’s not cool.
>> >
>> > There is no reference to openssl left.
> OK, thanks for testing.  Then indeed, OpenSSL can be moved to
> ‘native-inputs’ (it won’t be used when cross-compiling anyway, right?).
> 
> Ludo’.

Re: Gnunet-0.10.0 recipe

[Christian Grothoff]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

We use the OpenSSL binary to create a certificate from a shell script
(gnunet-transport-certificate-creation). So the dependency is on the
binary, not on the library, and thus there is no GPL licensing issue.

Now, it might be possible to do the same with gnutls-cli or some
similar tools, so if someone wants to hack the shell script to
eliminate OpenSSL entirely, that's fine with me.

Happy hacking!

Christian

On 02/04/2014 01:21 AM, Sree Harsha Totakura wrote:
> Hi Christian,
>
> Does GNUnet use openssl while building or is it used only during `make
> check`?
>
> Sree
>
> On 02/03/2014 11:57 PM, Ludovic Courtès wrote:
>> Andreas Enge <andreas@enge.fr> skribis:
>>
>>>> On Fri, Jan 31, 2014 at 05:05:37PM +0100, Ludovic Courtès wrote:
>>>>>> Note for upstream: It would be great to use GnuTLS instead of OpenSSL,
>>>>>> especially given that OpenSSL’s license may be incompatible with the GPL
>>>>>> in this case.
>>>> From my trials, I think openssl is used only for "make check".
>>>> So it should probably pass into native-inputs.
>>>>
>>>>>> Could you check with ‘guix gc --references $(guix build gnunet)’ if the
>>>>>> reference on OpenSSL is retained?  If not, that’s fine, but otherwise
>>>>>> that’s not cool.
>>>> There is no reference to openssl left.
>> OK, thanks for testing.  Then indeed, OpenSSL can be moved to
>> ‘native-inputs’ (it won’t be used when cross-compiling anyway, right?).
>>
>> Ludo’.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

Re: none

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> In my opinion the changelog conventions are achronistic, unintuitive,
> and bring benefit neither to developers nor users.

Well, opinions may vary.

It benefits me when I review other people’s patches, because it helps me
understand the structure of the change.  And it benefits me before I
commit something, because it forces me to review all of my patch, make
sure it’s consistent, make sure there’s no leftover, and giving me an
opportunity to add comments to code that appears non-obvious in
hindsight.

I think the rationale at
<http://www.gnu.org/prep/standards/standards.html#Change-Logs> still
holds.

Ludo’.

Re: none

[Mark H Weaver]

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

> John Darrington <jmd@gnu.org> skribis:
>
>> In my opinion the changelog conventions are achronistic, unintuitive,
>> and bring benefit neither to developers nor users.
>
> Well, opinions may vary.
>
> It benefits me when I review other people’s patches, because it helps me
> understand the structure of the change.  And it benefits me before I
> commit something, because it forces me to review all of my patch, make
> sure it’s consistent, make sure there’s no leftover, and giving me an
> opportunity to add comments to code that appears non-obvious in
> hindsight.

I also find them very useful when digging through (possibly ancient)
commit history.  Although all the information is in the actual patch,
when looking through many commits it is much more convenient to read a
summary of the changes.  One summary line is not enough detail.

Of course, it's extra work to write these summaries, but IMO it's
worthwhile.

      Mark

> I think the rationale at
> <http://www.gnu.org/prep/standards/standards.html#Change-Logs> still
> holds.
>
> Ludo’.

Re: Gnunet-0.10.0 recipe

[Andreas Enge]

On Tue, Feb 04, 2014 at 12:00:39AM +0100, Ludovic Courtès wrote:
> For the record, patches for pkgblurbs.txt (the file containing those
> descriptions in GNU Womb) should go to bug-womb@gnu.org.

Good to know. I could submit a small patch concerning this last sentence,
but as the gnunet developers wish to make more changes, I will let them
do so.

Currently, I cannot compile gnunet because the input gnurl fails with:
   TESTFAIL: These test cases failed: 172 
The same holds for recent builds of curl, see
   http://hydra.gnu.org/build/37634
If someone more knowledgeable could look into this, it would be very helpful.
If one can believe hydra, then Commit 2a72eee still worked, and adding
inkscape broke everything. Quite unbelievable indeed.

Meanwhile, I am holding the gnunet patch back.

Andreas

Re: none

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

On Wed, Feb 05, 2014 at 11:17:25AM -0500, Mark H Weaver wrote:
     ludo@gnu.org (Ludovic Court??s) writes:
     
     > John Darrington <jmd@gnu.org> skribis:
     >
     >> In my opinion the changelog conventions are achronistic, unintuitive,
     >> and bring benefit neither to developers nor users.
     >
     > Well, opinions may vary.
     >
     > It benefits me when I review other people???s patches, because it helps me
     > understand the structure of the change.  And it benefits me before I
     > commit something, because it forces me to review all of my patch, make
     > sure it???s consistent, make sure there???s no leftover, and giving me an
     > opportunity to add comments to code that appears non-obvious in
     > hindsight.
     
     I also find them very useful when digging through (possibly ancient)
     commit history.  Although all the information is in the actual patch,
     when looking through many commits it is much more convenient to read a
     summary of the changes.  One summary line is not enough detail.
     
     Of course, it's extra work to write these summaries, but IMO it's
     worthwhile.

I don't object to the spending time of writing changelogs.  I just think the 
information that the GCS suggests is not helpful.  It is not usefull to say 
changed file foo.scm, because using git show that is obvious.  There is even a 
perl script out in the wild somewhere to generate exactly that.  Typing it 
in is redundant. 

What would be  useful (but in general) we don't put in the changelogs is WHY a
developer changed foo.scm  Put yourself in the shoes of a person investigating a
problem in 3 years' time.  He can see that developer fred did X.  He doesn't
need fred to tell him that.  What he needs is fred to explain his reasoning for 
doing X not a statement that he has done it.  That way he can make an informed
decision about which way to take the code now.
     
J'
     

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: none

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> I don't object to the spending time of writing changelogs.  I just think the 
> information that the GCS suggests is not helpful.  It is not usefull to say 
> changed file foo.scm, because using git show that is obvious.  There is even a 
> perl script out in the wild somewhere to generate exactly that.  Typing it 
> in is redundant. 
>
> What would be  useful (but in general) we don't put in the changelogs is WHY a
> developer changed foo.scm

I disagree.  90% of the time, if something needs explanation, then the
explanation belongs as comments in the code.  Well, I’m just
paraphrasing the GCS.

If you would like to propose amendments to the GCS, please use
bug-standards@gnu.org.

(Though I would instead recommend keeping up the good packaging work. ;-))

Thanks,
Ludo’.

Re: [PATCH 1/2] gnu: gnunet: Remove Gstreamer dependency.

[Ludovic Courtès]

I’ve reported the bug at
<https://bugzilla.gnome.org/show_bug.cgi?id=724073> and temporarily
disabled tests in the meantime.

Ludo’.

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Ludovic Courtès]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

>     * gnunet/packages/gnunet.scm (gnunet): New variable.
>     * gnu/package/patches/gnunet-fix-scheduler.patch: New file.
>     * gnu/package/patches/gnunet-fix-tests.patch: New file.
>     * gnu-system.am (dist_patch_DATA): Add the above two patch files.
>
> Co-authored-by: Andreas Enge <andreas@enge.fr>

Applied.

However, gnurl fails to build for me:

--8<---------------cut here---------------start------------->8---
TESTDONE: 365 tests out of 366 reported OK: 99%
TESTFAIL: These test cases failed: 172 
TESTDONE: 911 tests were considered during 140 seconds.
Makefile:723: recipe for target 'quiet-test' failed
make[1]: *** [quiet-test] Error 1
make[1]: Leaving directory '/tmp/nix-build-gnurl-7.34.0.drv-0/gnurl-7.34.0/tests'
Makefile:1069: recipe for target 'test' failed
--8<---------------cut here---------------end--------------->8---

Ideas?

Thanks,
Ludo’.

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Andreas Enge]

Hello,

On Mon, Feb 10, 2014 at 11:15:30PM +0100, Ludovic Courtès wrote:
> Sree Harsha Totakura <sreeharsha@totakura.in> skribis:
> 
> >     * gnunet/packages/gnunet.scm (gnunet): New variable.
> >     * gnu/package/patches/gnunet-fix-scheduler.patch: New file.
> >     * gnu/package/patches/gnunet-fix-tests.patch: New file.
> >     * gnu-system.am (dist_patch_DATA): Add the above two patch files.
> >
> > Co-authored-by: Andreas Enge <andreas@enge.fr>
> 
> Applied.
> 
> However, gnurl fails to build for me:

see my message from February 5:
   https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00057.html
To summarise, I do not know what happens.

Please do not push the patch yet, as said in that message, I have the patch
in a branch with a few small modifications.

Andreas

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Ludovic Courtès]

Hi,

Andreas Enge <andreas@enge.fr> skribis:

> On Mon, Feb 10, 2014 at 11:15:30PM +0100, Ludovic Courtès wrote:
>> Sree Harsha Totakura <sreeharsha@totakura.in> skribis:
>> 
>> >     * gnunet/packages/gnunet.scm (gnunet): New variable.
>> >     * gnu/package/patches/gnunet-fix-scheduler.patch: New file.
>> >     * gnu/package/patches/gnunet-fix-tests.patch: New file.
>> >     * gnu-system.am (dist_patch_DATA): Add the above two patch files.
>> >
>> > Co-authored-by: Andreas Enge <andreas@enge.fr>
>> 
>> Applied.
>> 
>> However, gnurl fails to build for me:
>
> see my message from February 5:
>    https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00057.html
> To summarise, I do not know what happens.

Indeed.

> Please do not push the patch yet, as said in that message, I have the patch
> in a branch with a few small modifications.

Oh, sorry about that.  The thread looked stalled, so I thought I had
just forgotten to apply the patch.

Well, let’s see how we can fix things from here.

Apologies, and thanks for the heads-up.

Ludo’.

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Andreas Enge]

Hello,

On Tue, Feb 11, 2014 at 09:05:31AM +0100, Ludovic Courtès wrote:
> Well, let’s see how we can fix things from here.

finally, this was not such a big problem, I had just added libmicrohttpd
and done a bit of reformatting following Mark's suggestions (which you
have also done independently).

I could try to update curl and see whether the test problem still occurs.
It is a mystery to me how the problem occurred at the same time in curl
and gnurl when essentially we had not changed anything...

Andreas

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Sree Harsha Totakura]

Hi!

On 02/10/2014 11:33 PM, Andreas Enge wrote:
> see my message from February 5: 
> https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00057.html
>
> 
To summarise, I do not know what happens.

The testcase 172 tests cookies whose expiration value is hard-coded to
1391252187, which is Feb 1, 2014.  Hence, the testcase is failing for a
week :)

I will come up with a patch soon.

Regards,
Sree

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Andreas Enge]

On Tue, Feb 11, 2014 at 11:05:28AM +0100, Sree Harsha Totakura wrote:
> The testcase 172 tests cookies whose expiration value is hard-coded to
> 1391252187, which is Feb 1, 2014.  Hence, the testcase is failing for a
> week :)

Totally crazy!

Andreas

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, Feb 11, 2014 at 11:05:28AM +0100, Sree Harsha Totakura wrote:
>> The testcase 172 tests cookies whose expiration value is hard-coded to
>> 1391252187, which is Feb 1, 2014.  Hence, the testcase is failing for a
>> week :)
>
> Totally crazy!

In people’s mind, Feb. 2014 is so futuristic.  :-)

Ludo’.

Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.

[Andreas Enge]

On Tue, Feb 11, 2014 at 09:25:37AM +0100, Andreas Enge wrote:
> I could try to update curl and see whether the test problem still occurs.

Things are worse with curl 7.35.0 (which requires python for at least one
of its tests): Test 172 still fails, and additionally, 1221 and 1222 fail.
So a patch for 172 will be required in any case.

Andreas

[PATCH] gnu: curl, gnurl: Fix failing testcase 172.

[Sree Harsha Totakura]

* gnu/packages/patches/curl-fix-test172.patch: New file.
* gnu-system.am (dist_patch_DATA): Add the patch file.
* gnu/packages/gnunet.scm (gnurl): Apply the patch file.
* gnu/packages/curl.scm (curl): Apply the patch file.
---
 gnu-system.am                               |    1 +
 gnu/packages/curl.scm                       |    7 ++++++-
 gnu/packages/gnunet.scm                     |    5 ++++-
 gnu/packages/patches/curl-fix-test172.patch |   13 +++++++++++++
 4 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 gnu/packages/patches/curl-fix-test172.patch

diff --git a/gnu-system.am b/gnu-system.am
index 3e9108c..8229cf0 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -242,6 +242,7 @@ dist_patch_DATA =						\
   gnu/packages/patches/cdparanoia-fpic.patch			\
   gnu/packages/patches/cmake-fix-tests.patch			\
   gnu/packages/patches/cpio-gets-undeclared.patch		\
+  gnu/packages/patches/curl-fix-test172.patch			\
   gnu/packages/patches/dbus-localstatedir.patch			\
   gnu/packages/patches/diffutils-gets-undeclared.patch		\
   gnu/packages/patches/dmd-getpw.patch				\
diff --git a/gnu/packages/curl.scm b/gnu/packages/curl.scm
index 7072ed3..a9bfa76 100644
--- a/gnu/packages/curl.scm
+++ b/gnu/packages/curl.scm
@@ -22,6 +22,7 @@
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system gnu)
+  #:use-module (gnu packages)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages gnutls)
   #:use-module (gnu packages groff)
@@ -42,7 +43,11 @@
                                 version ".tar.lzma"))
             (sha256
              (base32
-              "13bhfs41yf60ys2hrikqxjwfzaj0gm91kqzsgc5fr4grzmpm38nx"))))
+              "13bhfs41yf60ys2hrikqxjwfzaj0gm91kqzsgc5fr4grzmpm38nx"))
+            (patches
+             ;; This patch fixes testcase 172 which uses a hardcoded cookie
+             ;; expiration value which is expired as of Feb 1, 2014.
+             (list (search-patch "curl-fix-test172.patch")))))
    (build-system gnu-build-system)
    (inputs `(("gnutls" ,gnutls)
              ("gss" ,gss)
diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index 1529f96..f3448a7 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -144,7 +144,10 @@ and support for SSL3 and TLS.")
                                 version ".tar.bz2"))
             (sha256
              (base32
-              "0kpi9wx9lg938b982smjg54acdwswdshs2bzf10sj5r6zmb05ygp"))))
+              "0kpi9wx9lg938b982smjg54acdwswdshs2bzf10sj5r6zmb05ygp"))
+            ;; This patch fixes testcase 172 which uses a hardcoded cookie
+            ;; expiration value which is expired as of Feb 1, 2014.
+            (patches (list (search-patch "curl-fix-test172.patch")))))
    (build-system gnu-build-system)
    (inputs `(("gnutls" ,gnutls)
              ("libidn" ,libidn)
diff --git a/gnu/packages/patches/curl-fix-test172.patch b/gnu/packages/patches/curl-fix-test172.patch
new file mode 100644
index 0000000..8f1637f
--- /dev/null
+++ b/gnu/packages/patches/curl-fix-test172.patch
@@ -0,0 +1,13 @@
+diff --git a/tests/data/test172 b/tests/data/test172
+index b3efae9..3d53418 100644
+--- a/tests/data/test172
++++ b/tests/data/test172
+@@ -36,7 +36,7 @@ http://%HOSTIP:%HTTPPORT/we/want/172 -b log/jar172.txt -b "tool=curl; name=fool"
+ 
+ .%HOSTIP	TRUE	/silly/	FALSE	0	ismatch	this
+ .%HOSTIP	TRUE	/	FALSE	0	partmatch	present
+-%HOSTIP	FALSE	/we/want/	FALSE	1391252187	nodomain	value
++%HOSTIP	FALSE	/we/want/	FALSE	2139150993	nodomain	value
+ </file>
+ </client>
+ 
-- 
1.7.10.4

Re: [PATCH] gnu: curl, gnurl: Fix failing testcase 172.

[Andreas Enge]

Thanks a lot, applied!

Andreas

Re: Gnunet-0.10.0 recipe

[Andreas Enge]

Gnunet fails its tests on my system with:

...
PASS: test_quota_compliance_http_asymmetric
Feb 11 20:42:17-420543 test_quota_compliance_https-18107 ERROR Peers got NOT connected
FAIL: test_quota_compliance_https
Feb 11 20:44:17-446106 test_quota_compliance_https_asymmetric-18138 ERROR Peers got NOT connected
FAIL: test_quota_compliance_https_asymmetric
===================================
5 of 56 tests failed

(So apparently, I missed four failures in the output...) Sree, does it pass
all tests on your machine? We will also see what happens on hydra once it
catches up.

Andreas

Re: Gnunet-0.10.0 recipe

[Sree Harsha Totakura]

On 02/11/2014 09:49 PM, Andreas Enge wrote:
> PASS: test_quota_compliance_http_asymmetric
> Feb 11 20:42:17-420543 test_quota_compliance_https-18107 ERROR Peers got NOT connected
> FAIL: test_quota_compliance_https
> Feb 11 20:44:17-446106 test_quota_compliance_https_asymmetric-18138 ERROR Peers got NOT connected
> FAIL: test_quota_compliance_https_asymmetric
> ===================================
> 5 of 56 tests failed
> 
> (So apparently, I missed four failures in the output...) Sree, does it pass
> all tests on your machine? We will also see what happens on hydra once it
> catches up.

The same tests fail for me.  I guess these tests were not enabled
earlier when libmicrohttpd was not added to the inputs.

Sree

(unknown),

[Sree Harsha Totakura]

The reason why the transport tests are failing is that gnurl is not being
built with HTTPS protocol support and these tests expect gnurl to have those.
The HTTPS support was not built into gnurl because pkg-config was not
available as native inputs during configure time.

This patch fixes the above problem and also appends an existing patch to fix
testcases to run them on local interfaces.

-
Sree

[PATCH] gnu: gnunet: Fix failing testcases.

[Sree Harsha Totakura]

* gnu/packages/gnunet.scm (gnurl): Add pkg-config.
* gnu/packages/patches/gnunet-fix-tests.patch: Append fix for integration testcases.
---
 gnu/packages/gnunet.scm                     |    8 +++++---
 gnu/packages/patches/gnunet-fix-tests.patch |   12 ++++++++++++
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index f3448a7..960a5d7 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -153,8 +153,9 @@ and support for SSL3 and TLS.")
              ("libidn" ,libidn)
              ("zlib" ,zlib)))
    (native-inputs
-    `(("perl" ,perl)
-      ("groff" ,groff)
+    `(("groff" ,groff)
+      ("perl" ,perl)
+      ("pkg-config" ,pkg-config)
       ("python" ,python-2)))
    (arguments
     `(#:configure-flags '("--enable-ipv6" "--with-gnutls" "--without-libssh2"
@@ -211,7 +212,8 @@ supports HTTPS, HTTPS and GnuTLS.")
         (search-patch "gnunet-fix-scheduler.patch")
         ;; Patch to fix bugs in testcases:
         ;; * Disable peerinfo-tool tests as they depend on reverse DNS lookups
-        ;; * Allow revocation testcase to run on loopback; upstream: #32130
+        ;; * Allow revocation and integration-tests testcases to run on
+        ;;   loopback; upstream: #32130, #32326
         ;; * Skip GNS testcases requiring DNS lookups; upstream: #32118
         (search-patch "gnunet-fix-tests.patch")))
       (patch-flags '("-p0"))))
diff --git a/gnu/packages/patches/gnunet-fix-tests.patch b/gnu/packages/patches/gnunet-fix-tests.patch
index 1957b17..4276db5 100644
--- a/gnu/packages/patches/gnunet-fix-tests.patch
+++ b/gnu/packages/patches/gnunet-fix-tests.patch
@@ -44,3 +44,15 @@ Index: src/gns/test_gns_cname_lookup.sh
  rm -rf /tmp/test-gnunet-gns-peer-1/
  
  TEST_DOMAIN_PLUS="www.gnu"
+Index: src/integration-tests/confs/test_defaults.conf
+===================================================================
+--- src/integration-tests/confs/test_defaults.conf	(revision 32320)
++++ src/integration-tests/confs/test_defaults.conf	(working copy)
+@@ -17,6 +17,7 @@
+ EXTERNAL_ADDRESS = 127.0.0.1
+ INTERNAL_ADDRESS = 127.0.0.1
+ BINDTO = 127.0.0.1
++RETURN_LOCAL_ADDRESSES = YES
+ 
+ [hostlist]
+ SERVERS =
-- 
1.7.10.4

Re: none

[Ludovic Courtès]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> The reason why the transport tests are failing is that gnurl is not being
> built with HTTPS protocol support and these tests expect gnurl to have those.
> The HTTPS support was not built into gnurl because pkg-config was not
> available as native inputs during configure time.

OK, thanks for investigating!

It would be nice if GNUnet’s ‘configure’ script would check whether
gnurl has HTTPS support.

Ludo’.

Re: [PATCH] gnu: gnunet: Fix failing testcases.

[Ludovic Courtès]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> * gnu/packages/gnunet.scm (gnurl): Add pkg-config.
> * gnu/packages/patches/gnunet-fix-tests.patch: Append fix for integration testcases.

Pushed, thanks!

Ludo’.

Re: none

[Sree Harsha Totakura]

On 02/12/2014 06:36 PM, Ludovic Courtès wrote:
> It would be nice if GNUnet’s ‘configure’ script would check whether
> gnurl has HTTPS support.

It now does. :-)

Sree

Re: none

[Andreas Enge]

On Wed, Feb 12, 2014 at 06:36:13PM +0100, Ludovic Courtès wrote:
> It would be nice if GNUnet’s ‘configure’ script would check whether
> gnurl has HTTPS support.

Concurred. Or maybe make pkg-config a mandatory input and stop when it
is not found. Ever so often I see a package that states "feature xyz
not available", when in reality it means "pkg-config not available".

I would say that either pkg-config has to be mandatory, or the feature xyz
needs to be tested in an alternative way if pkg-config is not found.

Andreas

Re: none

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Feb 12, 2014 at 06:36:13PM +0100, Ludovic Courtès wrote:
>> It would be nice if GNUnet’s ‘configure’ script would check whether
>> gnurl has HTTPS support.
>
> Concurred. Or maybe make pkg-config a mandatory input and stop when it
> is not found. Ever so often I see a package that states "feature xyz
> not available", when in reality it means "pkg-config not available".

I think this is largely because the official PKG_CHECK_MODULES Autoconf
macro doesn’t fail by default when pkg-config is not found (which may or
may not be a good idea, depending on the package.)

Ludo’.

Re: none

[Andreas Enge]

On Wed, Feb 12, 2014 at 09:30:53PM +0100, Ludovic Courtès wrote:
> I think this is largely because the official PKG_CHECK_MODULES Autoconf
> macro doesn’t fail by default when pkg-config is not found (which may or
> may not be a good idea, depending on the package.)

Then it is the authors' responsibility to either let the configuration
fail, or to include tests that do not rely on pkg_config, in my opinion.

Andreas

Re: none

[Ludovic Courtès]

Tomas Cech <sleep_walker@suse.cz> skribis:

> I tried to install Guix as alternative OS to my Gentoo and openSUSE
> installations to give a try. I tried unsupported scenario -
> installation on LVM volume and separate /boot partition until I was
> told it is unsupported. Separate boot wasn't hard as I had to just
> copy generated files so they are loaded.

OK, but there’s still an open bug on that topic.  :-)
http://bugs.gnu.org/19220

> 1] if you set device to partition (and not to disk) in your grub-configuration like this:
>
>  (bootloader (grub-configuration
>                (device "/dev/sda4")))

Why would you want to use a partition and not a disk?  I didn’t know
this was even possible.

> `guix system init' will fail on grub installation. By default Grub
> tries to fit in the beginning of partition and fails if it can't fit
> in. I asked about this behaviour on Grub mailing list and it seems
> that there are two options:
>
>   a] add `--force' to command line and use block list for keeping information about position of Grub's core.img
>   b] use filesystem which allows embedding - BtrFS or ZFS
>
> I verified both options (a] and then b] with BtrFS) and it no longer fails.
>
> But,
> ad a] - I don't feel safe passing `--force' to grub-install every
> time. So if installation fails on this point and you'd like to use
> your FS anyway, you can pass `--no-grub' to `guix system init' and
> then rung grub-install manually.
>
> ad b] - I don't feel safe using still experimental BtrFS.

OK.  I think the conclusion for Guix is to leave the defaults unchanged.
Perhaps we could add a ‘force?’ field to the ‘grub-configuration’ data
type to allow those who know what they doing to get the effect of
‘--force’.  WDYT?

> 2] current Grub version in Guix during boots generated this error:
>
> error: symbol 'grub_term_highlight_color' not found
>
> and started rescue shell.
> It seems to be a bit mystic bug:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977

Strange.  I haven’t experienced it.  Sounds like a .mod wasn’t found or
something like that?  That could be a bug related to separate /boot.

> I'm also interested in running chroot in Guix. This is something I
> like about all Linux distribution I use - I can run Linux and at the
> same time I prepare another Linux root filesystem for use. It seems
> that chrooting into Guix may be tricky.
>
> I prepared this script to be placed somewhere into Guix:
>
> ----------%<---------
> #!/run/current-system/profile/bin/bash
>
> export LIBRARY_PATH=LIBRARY_PATH=/root/.guix-profile/lib
> export CPATH=/root/.guix-profile/include
> export PATH=/run/setuid-programs:/run/current-system/profile/sbin:/root/.guix-profile/bin:/run/current-system/profile/bin
> export INFOPATH=/root/.guix-profile/share/info:/run/current-system/profile/share/info
>
> exec bash -i
> ----------%<--------
>
> for i in dev proc sys; do mount -R /$i /guix_mountpoint/$i; done
> chroot /guix_mountpoint/ /helper_script.sh

I suppose this works, right?

> Ludovic said that `guix packages --search-paths' should generate similar path configuration so it may be the right way, but it didn't work for me.

I realize ‘guix package --search-paths’ wouldn’t suffice here.  You may
want to source /etc/profile from within the chroot.

> And last thing I wanted to mention, you have kind community around Guix and Guile. It's really motivating!

Thanks for your feedback and for the kind words!

Ludo’.

Re: none

[Tomas Cech]

At Fri, 05 Dec 2014 00:04:23 +0100,
Ludovic Courtès wrote:
> 
> Tomas Cech <sleep_walker@suse.cz> skribis:
> 
> > I tried to install Guix as alternative OS to my Gentoo and openSUSE
> > installations to give a try. I tried unsupported scenario -
> > installation on LVM volume and separate /boot partition until I was
> > told it is unsupported. Separate boot wasn't hard as I had to just
> > copy generated files so they are loaded.
> 
> OK, but there’s still an open bug on that topic.  :-)
> http://bugs.gnu.org/19220

Good, I'll give a try again.

> > 1] if you set device to partition (and not to disk) in your grub-configuration like this:
> >
> >  (bootloader (grub-configuration
> >                (device "/dev/sda4")))
> 
> Why would you want to use a partition and not a disk?  I didn’t know
> this was even possible.

Because this way I can separate Grub managed by Guix and Grub from my
Gentoo. As I'm playing with that on my notebook I need for work, this
way can reduce risks.

I'm not sure how Guix installer can manipulate with grub.cfg and I'd
like to always have some working system...

> 
> > `guix system init' will fail on grub installation. By default Grub
> > tries to fit in the beginning of partition and fails if it can't fit
> > in. I asked about this behaviour on Grub mailing list and it seems
> > that there are two options:
> >
> >   a] add `--force' to command line and use block list for keeping information about position of Grub's core.img
> >   b] use filesystem which allows embedding - BtrFS or ZFS
> >
> > I verified both options (a] and then b] with BtrFS) and it no longer fails.
> >
> > But,
> > ad a] - I don't feel safe passing `--force' to grub-install every
> > time. So if installation fails on this point and you'd like to use
> > your FS anyway, you can pass `--no-grub' to `guix system init' and
> > then rung grub-install manually.
> >
> > ad b] - I don't feel safe using still experimental BtrFS.
> 
> OK.  I think the conclusion for Guix is to leave the defaults unchanged.
> Perhaps we could add a ‘force?’ field to the ‘grub-configuration’ data
> type to allow those who know what they doing to get the effect of
> ‘--force’.  WDYT?

After some more mails with help-grub ML It seems that Grub can do even better -
it can load core.img right from Guix's filesystem or just read new
configuration (multiboot, resp. config - both shown here
http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config
)... But these are just Grub chainloading Grub solutions...

From Guix perspective I don't think it is possible to do it
automatically. I think you can consider installation of Grub to
partiotion as something just for advanced users. With that in mind I
believe guix should refuse (with some warning) installing grub that
way. Advanced users can use `--no-grub' option which will prevent guix
from fail and do manually anything they desire. And in the
documentation I'd give some short notice about that with link to Grub
manual. IMHO information that "only ZFS and BtrFS can embed core.img
into boot sector" belongs there.

> > 2] current Grub version in Guix during boots generated this error:
> >
> > error: symbol 'grub_term_highlight_color' not found
> >
> > and started rescue shell.
> > It seems to be a bit mystic bug:
> > https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1289977
> 
> Strange.  I haven’t experienced it.  Sounds like a .mod wasn’t found or
> something like that?  That could be a bug related to separate /boot.

Yes, sounds like something like that. Important for me is that the
same command with same configuration worked when I used version from
Gentoo so I don't think it's bug elsewhere but in Grub version.


> > I'm also interested in running chroot in Guix. This is something I
> > like about all Linux distribution I use - I can run Linux and at the
> > same time I prepare another Linux root filesystem for use. It seems
> > that chrooting into Guix may be tricky.
> >
> > I prepared this script to be placed somewhere into Guix:
> >
> > ----------%<---------
> > #!/run/current-system/profile/bin/bash
> >
> > export LIBRARY_PATH=LIBRARY_PATH=/root/.guix-profile/lib
> > export CPATH=/root/.guix-profile/include
> > export PATH=/run/setuid-programs:/run/current-system/profile/sbin:/root/.guix-profile/bin:/run/current-system/profile/bin
> > export INFOPATH=/root/.guix-profile/share/info:/run/current-system/profile/share/info
> >
> > exec bash -i
> > ----------%<--------
> >
> > for i in dev proc sys; do mount -R /$i /guix_mountpoint/$i; done
> > chroot /guix_mountpoint/ /helper_script.sh
> 
> I suppose this works, right?

Yes :)

> 
> > Ludovic said that `guix packages --search-paths' should generate similar path configuration so it may be the right way, but it didn't work for me.
> 
> I realize ‘guix package --search-paths’ wouldn’t suffice here.  You may
> want to source /etc/profile from within the chroot.

OK, I'll play with this to improve it.


S_W

Re: none

[Ludovic Courtès]

Tomas Cech <sleep_walker@suse.cz> skribis:

> At Fri, 05 Dec 2014 00:04:23 +0100,

[...]

>> > 1] if you set device to partition (and not to disk) in your grub-configuration like this:
>> >
>> >  (bootloader (grub-configuration
>> >                (device "/dev/sda4")))
>> 
>> Why would you want to use a partition and not a disk?  I didn’t know
>> this was even possible.
>
> Because this way I can separate Grub managed by Guix and Grub from my
> Gentoo. As I'm playing with that on my notebook I need for work, this
> way can reduce risks.
>
> I'm not sure how Guix installer can manipulate with grub.cfg and I'd
> like to always have some working system...

Another option for you would be to add a ‘menu-entry’ to the
‘grub-configuration’ form that would boot the other distro.

  (grub-configuration
    (device ...)
    (menu-entries
      (list (menu-entry
              (label "Good ol' distro")
              (linux "/path/to/kernel”)
              (linux-arguments '("whatever"))
              (initrd "/path/to/initrd")))))

> After some more mails with help-grub ML It seems that Grub can do even better -
> it can load core.img right from Guix's filesystem or just read new
> configuration (multiboot, resp. config - both shown here
> http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config
> )... But these are just Grub chainloading Grub solutions...
>
> From Guix perspective I don't think it is possible to do it
> automatically. I think you can consider installation of Grub to
> partiotion as something just for advanced users. With that in mind I
> believe guix should refuse (with some warning) installing grub that
> way. Advanced users can use `--no-grub' option which will prevent guix
> from fail and do manually anything they desire. And in the
> documentation I'd give some short notice about that with link to Grub
> manual. IMHO information that "only ZFS and BtrFS can embed core.img
> into boot sector" belongs there.

OK, thanks for the info.  I’m tempted to think the GRUB manual should be
the primary source for this sort of things.

Thanks,
Ludo’.

Re: none

[Ludovic Courtès]

Tomáš Čech <sleep_walker@gnu.org> skribis:

> I haven't seen any further reaction for 12 days so I hope you don't mind that
> I resend it again.

Reaction to what?

Ludo’.

Re: none

[Tomáš Čech]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

On Thu, Mar 26, 2015 at 10:22:36PM +0100, Ludovic Courtès wrote:
>Tomáš Čech <sleep_walker@gnu.org> skribis:
>
>> I haven't seen any further reaction for 12 days so I hope you don't mind that
>> I resend it again.
>
>Reaction to what?

Reaction to the first patch version.

S_W

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: none

[Ludovic Courtès]

Hi Pjotr,

Pjotr Prins <pjotr.public12@email> skribis:

> From 5fd8f64794b27f59f6688177a7a9e532b5d57f01 Mon Sep 17 00:00:00 2001
> Date: Tue, 19 Jul 2016 11:13:27 +0000
> Subject: [PATCH] gnu: Add elixir.
> To: guix-devel@gnu.org
> From: Pjotr Prins <pjotr.public01@thebird.nl>
> References: <578e47d0.i8Ovns6KhzHqzVNC%pjotr.public12@thebird.nl>
>
> * gnu/packages/elixir.scm: New file.
> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

Thanks for the great work!

In
<https://github.com/pjotrp/guix-notes/blob/master/ELIXIR.org#the-gnu-guix-dance-of-getting-packages-accepted>,
you already identified exactly what we were going to say.  :-)

Namely, why are patches applied in a build phase rather than in
‘origin’, why is such and such test disabled (one sentence is usually
enough), what happens if we set ‘HOME’ like Ben suggests, etc.

What should we do?  :-)

Ludo’.

Re: none

[Pjotr Prins]

On Thu, Jul 21, 2016 at 02:51:38PM +0200, Ludovic Courtès wrote:
> In
> <https://github.com/pjotrp/guix-notes/blob/master/ELIXIR.org#the-gnu-guix-dance-of-getting-packages-accepted>,
> you already identified exactly what we were going to say.  :-)
> 
> Namely, why are patches applied in a build phase rather than in
> ‘origin’, why is such and such test disabled (one sentence is usually
> enough), what happens if we set ‘HOME’ like Ben suggests, etc.
> 
> What should we do?  :-)

I think I have covered that both in my writeup and in my response to
Ben. I think this work should be accepted as is.

I think this is probably the last package I am contributing to main line.
Never liked dancing that much ;)

But seriously, we should find other ways to encourage people. I wonder
how many packages are out there that never find their way into guix or
much too late. I wonder how much duplicate work is going on because of
our dance requirement. If it this hard *with* my experience in
packaging, how hard do you think it is for people *without*
experience. I know Dennis, for example, is sitting on a heap of opencl
packages which are incredibly useful to many people.

I believe we have to change our ways.

Pj.

Re: none

[Pjotr Prins]

A provocation: because of purism GNU Guix takes an elitist approach.

I am thinking that we need another project because it appears to be
impossible to combine low threshold with GNU Guix goals.

How about Alt-Guix, a packaging effort without opinion. As long as a
package builds it gets accepted. This can act as an incubator for main
line. There will be no purist views on syntax, layout, license, github
etc. The whole idea is to build on each others shoulders and anything
that starts is a great contribution. 

It would have accepted Erlang + Elixir packages half a year ago and
made it possible to get people interested in these much earlier. Maybe
they would have made it to main line already because more people got
involved and wanted that.

This is much closer to my idea of successful incremental FOSS
projects, i.e., welcome all comers. I think that is part of the appeal
of brew and conda. People need immediate gratification for work. 

I understand the need for purism, and applaud the idea, but we are
throwing up too many barriers.

Because GNU Guix is an extreme, we can have the other extreme too. It
would make it easier to invite people, train people and find packages
now hiding behind GUIX_PACKAGE_PATHs.

Pj.

Re: none

[Jookia]

On Fri, Jul 22, 2016 at 04:06:56AM +0200, Pjotr Prins wrote:
> A provocation: because of purism GNU Guix takes an elitist approach.
> 
> I am thinking that we need another project because it appears to be
> impossible to combine low threshold with GNU Guix goals.
> 
> How about Alt-Guix, a packaging effort without opinion. As long as a
> package builds it gets accepted. This can act as an incubator for main
> line. There will be no purist views on syntax, layout, license, github
> etc. The whole idea is to build on each others shoulders and anything
> that starts is a great contribution. 
> 
> It would have accepted Erlang + Elixir packages half a year ago and
> made it possible to get people interested in these much earlier. Maybe
> they would have made it to main line already because more people got
> involved and wanted that.
> 
> This is much closer to my idea of successful incremental FOSS
> projects, i.e., welcome all comers. I think that is part of the appeal
> of brew and conda. People need immediate gratification for work. 
> 
> I understand the need for purism, and applaud the idea, but we are
> throwing up too many barriers.
> 
> Because GNU Guix is an extreme, we can have the other extreme too. It
> would make it easier to invite people, train people and find packages
> now hiding behind GUIX_PACKAGE_PATHs.
> 
> Pj.

I've wanted to do something like this, but what about carrying non-package
patches? ie for bootloader support on ARM and better device-mapper support

Re: none

[Leo Famulari]

On Fri, Jul 22, 2016 at 04:06:56AM +0200, Pjotr Prins wrote:
> A provocation: because of purism GNU Guix takes an elitist approach.
> 
> I am thinking that we need another project because it appears to be
> impossible to combine low threshold with GNU Guix goals.
> 
> How about Alt-Guix, a packaging effort without opinion. As long as a
> package builds it gets accepted. This can act as an incubator for main
> line. There will be no purist views on syntax, layout, license, github
> etc. The whole idea is to build on each others shoulders and anything
> that starts is a great contribution. 

Personally, I'm sympathetic to the idea, although I'd rather see how far
we can improve our processes to make them as easy as possible without
sacrificing quality. But, if this does become a thing, I hope the
license will be compatible so that parts can be merged into GNU Guix
when they are ready.

Otherwise, the problem of duplication that you mentioned earlier will be
really bad.

Re: none

[Tobias Geerinckx-Rice]

Hiya, Pjotr,

On 2016-07-22 04:06, Pjotr Prins wrote:
> A provocation: because of purism GNU Guix takes an elitist approach.

I've honestly never felt any elitism coming from the Guix project.
Consistency, certainly. _Much_ more so than in most other free
software projects I know. I find it helps getting new users and/or
packagers started, and makes it easier and more pleasant to
contribute. It did for me and people I know.

Others are definitely having a very different experience. That's a
problem.

Discouraging proper code reviews won't do anything to solve that
problem, though.

> I am thinking that we need another project because it appears to be
> impossible to combine low threshold with GNU Guix goals.
> 
> How about Alt-Guix, a packaging effort without opinion. As long as a
> package builds it gets accepted.

As long as it's not a fork in any way: yes please!

Sounds like a QA nightmare, but I'll gladly support anything that
will encourage and test some kind of decentralised repository
management in GNU Guix in the future. *mumbles some vague desires*

And knowing myself, I'd end up using it anyway for something shiny
or other.

Mandatory code reviews for Guix: still a good thing, though, and
not the problem.

> This can act as an incubator for main line. There will be no purist
> views on syntax, layout,

In the spirit of (friendly) provocation, I'd nitpick on the term
‘purist views’ and suggest the word ‘standards’ instead. ;-)

That's most likely the intention, and it's really how I experienced
it, during several months of more or less active Guix(SD) use and
lurking on this list, and it was a breath of fresh air. Maybe I'm
weird. I've been told.

But seriously: the code reviews? Most Free software projects don't
do nearly enough. Also, most Free software projects su^W should.

> license, github etc.

I've not seen any licence purism (yet) either. Anything Free, goes.
No?

I'm curious why GitHub's in that list. Sure, the upstream Guix
repository isn't going to move there any time soon. There's no
compelling reason to do so, and not relying on someone else's
good-will is always a good idea. Not relying on someone else's
proprietary secret SaaS is simply common sense. But I haven't
seen any purist elitism towards GitHub users. I'm one.

> I understand the need for purism, and applaud the idea, but we are
> throwing up too many barriers.
> 
> Because GNU Guix is an extreme, ...

Wow. I don't see that. At all.

Sorry, that went on a bit longer than intended. I'm just wondering
what I missed, and hoping my experiences here won't hit a burn-out
threshold like it seems to do for some...

Kind regards,

T G-R

Re: none

[Roel Janssen]

Pjotr Prins writes:

> On Thu, Jul 21, 2016 at 02:51:38PM +0200, Ludovic Courtès wrote:
>> In
>> <https://github.com/pjotrp/guix-notes/blob/master/ELIXIR.org#the-gnu-guix-dance-of-getting-packages-accepted>,
>> you already identified exactly what we were going to say.  :-)
>> 
>> Namely, why are patches applied in a build phase rather than in
>> ‘origin’, why is such and such test disabled (one sentence is usually
>> enough), what happens if we set ‘HOME’ like Ben suggests, etc.
>> 
>> What should we do?  :-)
>
> I think I have covered that both in my writeup and in my response to
> Ben. I think this work should be accepted as is.
>
> I think this is probably the last package I am contributing to main line.
> Never liked dancing that much ;)

For the last twenty weeks or so I have started contributing packages to
GNU Guix mainly because Pjotr gave me the opportunity to do so.  For me,
upstreaming was part of the deal, and I'd say it has taken me at least
two times the time it took me to write a proper package definition to
get it in the upstream distribution.

You've seen the mistakes I made, and the little syntactic things that
kept going wrong over time.  Near the end of my internship, however, I
saw a positive change: Reviewers actually make little changes, instead
of leaving it up to the submitter to ``fix the indendation''.  This
change makes the burden of reviewing smaller as well as the burden to
submit a package.  Great!

One thing that really helped me in reducing the time to contribute
changes to the upstream distribution, is to have a good workflow.  I
ended up doing the following:
1. Make the changes.
2. Commit the changes.
3 git format-patch -1 --no-attach
4. git reset --hard <latest commit on origin/master>
5. Submit the patch to the mailing list
6. Wait for response and probably go back to 1.

I made all of my changes on a GNU Guix git checkout.  So, not writing
package definitions on a separate repository.

> But seriously, we should find other ways to encourage people. I wonder
> how many packages are out there that never find their way into guix or
> much too late. I wonder how much duplicate work is going on because of
> our dance requirement. If it this hard *with* my experience in
> packaging, how hard do you think it is for people *without*
> experience. I know Dennis, for example, is sitting on a heap of opencl
> packages which are incredibly useful to many people.
>
> I believe we have to change our ways.

The problem is real.  I have taken contributing back to upstream _very_
serious, and I haven't been able to get everything back into GNU Guix
either.

Packages I work(ed) on that haven't made it upstream (yet) due to
``imperfect'' patches:
* MongoDB:    Bundled source code;
* GParted:    The help function does not work without external
              documentation database tool;
* FreeBayes:  At first, licensing issues, now just a plain ugly patch to
              deal with the unbundling of its dependencies in the
              Makefiles of this project;
* VCFLib:     Same situation as FreeBayes.  To be honest, this package
              would've not ended up as a separate package if I didn't
              have to split up FreeBayes.  I consider this a positive
              effect of the review process.

Lastly, I would like to say that I think the package reviews have always
been positive and fair.  We are trying to maintain a high-quality
distribution, and this is a natural effect of trying to do so.

Maybe we could create an online course to do packaging with GNU Guix and
make it rewarding with a grading system and giving achievement points..
That might make the incentive to make the upstreaming step of packaging
more fun and more like a learning process rather than a recurrent PITA.
(This is something I could spend time at..)

Kind regards,
Roel Janssen

Re: none

[Pjotr Prins]

On Fri, Jul 22, 2016 at 06:48:47AM +0200, Tobias Geerinckx-Rice wrote:
> In the spirit of (friendly) provocation, I'd nitpick on the term
> ‘purist views’ and suggest the word ‘standards’ instead. ;-)

Alright. I concede ;)

> But seriously: the code reviews? Most Free software projects don't
> do nearly enough. Also, most Free software projects su^W should.

The number of contributors is not going up as fast as it should. I
have been quite exasparated with every package I submitted. Does that
mean I should stop packaging? Note that I actually like packaging, but
I feel mentally blocked to submit to the ML... Should we really leave
it to those that are more inclined to do the dance?

> >license, github etc.
> 
> I've not seen any licence purism (yet) either. Anything Free, goes.
> No?

Yes, but there are also non-free packages in our repo. They do not
have to go in GNU Guix. I am a great fan of the FSF and GNU. I think
GNU Guix is pure genius. I always choose free over non-free. But we
also have to be pragmatic.

> I'm curious why GitHub's in that list. Sure, the upstream Guix
> repository isn't going to move there any time soon. There's no
> compelling reason to do so, and not relying on someone else's
> good-will is always a good idea. Not relying on someone else's
> proprietary secret SaaS is simply common sense. But I haven't
> seen any purist elitism towards GitHub users. I'm one.

People don't like github because it is non-free.

> >I understand the need for purism, and applaud the idea, but we are
> >throwing up too many barriers.
> >
> >Because GNU Guix is an extreme, ...
> 
> Wow. I don't see that. At all.

Everything FSF and/or GNU is pretty extreme ;). It is a good thing. I
buy into it when I can. Barriers are there. Everyone is different, we
have to cater for that.

> As long as it's not a fork in any way: yes please!

We should consider a separate project that is aligned with trunk. I
don't want to divert, but to add to both.

Yellow-band Guix? With a Judoka embracing the Guix logo ;). 'A Guix
package project without an opinion' would be my choice of a slogan.
Judo instead of dancing.

I am not looking forward to having a separate project, but I don't see
much of an alternative. There will be a fear that actualy
contributions to GNU Guix can go down - there is that risk - but my
aim is to get more acceptance and contributors and eventually we all
gain. I am not worried about QA. Work can be self correcting - we
see that a lot.

I had a mug that said 'Stop me before I volunteer again'. This is one
of those moments... But I may just do it.

Pj.

Re: none

[Ricardo Wurmus]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Fri, Jul 22, 2016 at 06:48:47AM +0200, Tobias Geerinckx-Rice wrote:
>> In the spirit of (friendly) provocation, I'd nitpick on the term
>> ‘purist views’ and suggest the word ‘standards’ instead. ;-)
>
> Alright. I concede ;)
>
>> But seriously: the code reviews? Most Free software projects don't
>> do nearly enough. Also, most Free software projects su^W should.
>
> The number of contributors is not going up as fast as it should. I
> have been quite exasparated with every package I submitted. Does that
> mean I should stop packaging? Note that I actually like packaging, but
> I feel mentally blocked to submit to the ML... Should we really leave
> it to those that are more inclined to do the dance?

I appreciate you sharing your experiences.

I may be wrong but to me this comes down to familiarity with Git or
with having a convenient workflow.  I work on many packages and core
changes at the same time in different branches and not having to think
about Git makes this a lot easier.  Rarely ever do I feel that a
suggested change is inconvenient because I can just add a new tmp
commit, interactively rebase to reorder and squash commits, and produce
a new patches.  All of that in separate branches so that I can continue
work on other things without any impact.

What makes things easier for me personally is to not worry about
urgency.  Nothing I do is really urgent.  If I need to provide a package
for someone at the institute I don’t wait for acceptance in Guix
upstream; I just push it to our own “guix-bimsb” repo, which is used via
GUIX_PACKAGE_PATH.  Eventually, changes are polished and get accepted
upstream; at that point I remove them from the external repo.  There is
no hurry and I can choose to take my time addressing issues mentioned in
reviews.  (One of my patches for “pam_limits” went through several major
revisions over a duration of half a year or so.  I’m a sloth.)

I really don’t think we make it hard for people to contribute.  Projects
using Github or similar platforms have a more complicated workflow
(because you must work not only with your local clone but also your
online fork, and you need to force push to make revisions to a pull
request, etc).  Prior to Guix I had very little experience with a
mail-based workflow, but I’ve come to really appreciate and prefer it
over the alternatives.

>> As long as it's not a fork in any way: yes please!
>
> We should consider a separate project that is aligned with trunk. I
> don't want to divert, but to add to both.

Aren’t you already doing this with your separate package set on Github?
In my opinion there is no need for an official project like that.  We
want most changes to be made to Guix directly.  Changes there are much
more likely to benefit the majority of users.

> I am not looking forward to having a separate project, but I don't see
> much of an alternative. There will be a fear that actualy
> contributions to GNU Guix can go down - there is that risk - but my
> aim is to get more acceptance and contributors and eventually we all
> gain. I am not worried about QA. Work can be self correcting - we
> see that a lot.

Hmm, an alternative is what you’ve suggested before: have reviewers
accept more patches earlier.  Since we won’t budge on our standards this
means that subpar patches take up more work, more time.  As it stands
right now, we don’t have enough time / enough reviewers.  (I disagree
with the claim that the number of contributors doesn’t grow quickly
enough; we do have a problem with the number of reviewers.)

It should not be overlooked that some contributors started out with
patch submissions that needed a lot of revisions who now provide us with
extremely reliable contributions.  This relieves pressure from reviewers
who can spend more time on other contributions.

For sustainable growth I think it is necessary that we “train”
contributors by means of reviews.

~~ Ricardo

Re: none

[Jookia]

On Fri, Jul 22, 2016 at 02:23:42PM +0200, Ricardo Wurmus wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > On Fri, Jul 22, 2016 at 06:48:47AM +0200, Tobias Geerinckx-Rice wrote:
> >> In the spirit of (friendly) provocation, I'd nitpick on the term
> >> ‘purist views’ and suggest the word ‘standards’ instead. ;-)
> >
> > Alright. I concede ;)
> >
> >> But seriously: the code reviews? Most Free software projects don't
> >> do nearly enough. Also, most Free software projects su^W should.
> >
> > The number of contributors is not going up as fast as it should. I
> > have been quite exasparated with every package I submitted. Does that
> > mean I should stop packaging? Note that I actually like packaging, but
> > I feel mentally blocked to submit to the ML... Should we really leave
> > it to those that are more inclined to do the dance?

> I appreciate you sharing your experiences.

I've also quit Guix development because of these experiences, so forgive me for
my harsh words. See help-guix for my experiences. In general, I'm a bit sick of
this so I'm going to reiterate some of my concerns.

> What makes things easier for me personally is to not worry about
> urgency.  Nothing I do is really urgent.  If I need to provide a package
> for someone at the institute I don’t wait for acceptance in Guix
> upstream; I just push it to our own “guix-bimsb” repo, which is used via
> GUIX_PACKAGE_PATH.  Eventually, changes are polished and get accepted
> upstream; at that point I remove them from the external repo.  There is
> no hurry and I can choose to take my time addressing issues mentioned in
> reviews.  (One of my patches for “pam_limits” went through several major
> revisions over a duration of half a year or so.  I’m a sloth.)

Guuix uses a mailing list for development, like most GNU projects. Maybe this
works for those, but Guix is trying to be hip and cool and fresh compared to
most GNU projects which are stable and generally a pain to contribute to.

On top of that, the maintainers can't even use the mailing list properly:
Patches are lost, discussion doesn't happen, things are lost and it's hard for
new users to join in. Who exactly benefits from this workflow compared to
something web-based? Sure, maybe you could argue that the maintainers are best
served with it, or that you personally are attuned to that. Fine, but let's not
pretend the mailing list isn't gruelling.

> I really don’t think we make it hard for people to contribute.  Projects
> using Github or similar platforms have a more complicated workflow
> (because you must work not only with your local clone but also your
> online fork, and you need to force push to make revisions to a pull
> request, etc).  Prior to Guix I had very little experience with a
> mail-based workflow, but I’ve come to really appreciate and prefer it
> over the alternatives.

It's a complicated setup in return for being able to track what's happening in
the project. If I were to ask, 'how many patches are pending review' right now
you'd have absolutely no idea.

> Aren’t you already doing this with your separate package set on Github?
> In my opinion there is no need for an official project like that.  We
> want most changes to be made to Guix directly.  Changes there are much
> more likely to benefit the majority of users.

This is the reason why I really dislike the current attitude of the community.
You're building an operating system which by definition is meant to serve a ton
of different needs, building it slowly and not urgently at all, but then arguing
changes should be kept centralized for the benefit of all users and staging
features should be pushed to whateve personal repositories we have.

> Hmm, an alternative is what you’ve suggested before: have reviewers
> accept more patches earlier.  Since we won’t budge on our standards this
> means that subpar patches take up more work, more time.  As it stands
> right now, we don’t have enough time / enough reviewers.  (I disagree
> with the claim that the number of contributors doesn’t grow quickly
> enough; we do have a problem with the number of reviewers.)

This isn't a software project, it's an operating system. At least until there's
a Guix and GuixSD repo split. Implying the issue that patches not being accepted
is due to subpar patches or high standards sounds good, but isn't true. A lot of
the issues are design-related and require discussion that can't be known in
advance by conributors since Guix is dictated by the maintainers' preferences.
To my knowledge there's no detailed list of what to do in absolutely every
situation involved in the complexity of packaging something, especially with how
new the project is.

> It should not be overlooked that some contributors started out with
> patch submissions that needed a lot of revisions who now provide us with
> extremely reliable contributions.  This relieves pressure from reviewers
> who can spend more time on other contributions.
> 
> For sustainable growth I think it is necessary that we “train”
> contributors by means of reviews.

Sorry, do you mean contributor as in packager or contributor as in general
devleoper that works on GuixSD's non-package features? How do we train people
doing the latter?

All in all, I say we have a repo for staging patches that work but aren't as
nice looking or implemented as well as they should be. If not part of Guix, then
as a branch/fork. It should not be up to Guix as to what features users get, but
instead the users based on whichever fork they're using.

> ~~ Ricardo

Jookia.

Re: none

[Leo Famulari]

> You've seen the mistakes I made, and the little syntactic things that
> kept going wrong over time.  Near the end of my internship, however, I
> saw a positive change: Reviewers actually make little changes, instead
> of leaving it up to the submitter to ``fix the indendation''.  This
> change makes the burden of reviewing smaller as well as the burden to
> submit a package.  Great!

That's good. I think there is some value in asking submitters to correct
even small issues, so that they have a chance to learn. But, the faster
method is for the reviewer to make the correction themselves, and then
explain the difference. If there are many minor changes, the reviewer
can attach a diff to their reply.

Re: none

[Vincent Legoll]

On Fri, Jul 22, 2016 at 4:07 PM, Leo Famulari <leo@famulari.name> wrote:
>> You've seen the mistakes I made, and the little syntactic things that
>> kept going wrong over time.  Near the end of my internship, however, I
>> saw a positive change: Reviewers actually make little changes, instead
>> of leaving it up to the submitter to ``fix the indendation''.  This
>> change makes the burden of reviewing smaller as well as the burden to
>> submit a package.  Great!
>
> That's good. I think there is some value in asking submitters to correct
> even small issues, so that they have a chance to learn. But, the faster
> method is for the reviewer to make the correction themselves, and then
> explain the difference. If there are many minor changes, the reviewer
> can attach a diff to their reply.

That's a matter of taste, I prefer being told that my contribution is not good
enough and then fix it myself, but that's because I'm not doing a lot...

If the maintainer wants to do additional changes, I also prefer he does it in
a separate patch/commit, as that would enable me to git pull --ff instead of
merge...

my .02€

-- 
Vincent Legoll

Re: none

[Ludovic Courtès]

Hi Roel,

Roel Janssen <roel@gnu.org> skribis:

> For the last twenty weeks or so I have started contributing packages to
> GNU Guix mainly because Pjotr gave me the opportunity to do so.  For me,
> upstreaming was part of the deal, and I'd say it has taken me at least
> two times the time it took me to write a proper package definition to
> get it in the upstream distribution.
>
> You've seen the mistakes I made, and the little syntactic things that
> kept going wrong over time.  Near the end of my internship, however, I
> saw a positive change: Reviewers actually make little changes, instead
> of leaving it up to the submitter to ``fix the indendation''.  This
> change makes the burden of reviewing smaller as well as the burden to
> submit a package.  Great!

Thanks for your feedback.

> One thing that really helped me in reducing the time to contribute
> changes to the upstream distribution, is to have a good workflow.  I
> ended up doing the following:
> 1. Make the changes.
> 2. Commit the changes.
> 3 git format-patch -1 --no-attach
> 4. git reset --hard <latest commit on origin/master>
> 5. Submit the patch to the mailing list
> 6. Wait for response and probably go back to 1.
>
> I made all of my changes on a GNU Guix git checkout.  So, not writing
> package definitions on a separate repository.

Do you think it would help to add this as a section in the manual?

>> But seriously, we should find other ways to encourage people. I wonder
>> how many packages are out there that never find their way into guix or
>> much too late. I wonder how much duplicate work is going on because of
>> our dance requirement. If it this hard *with* my experience in
>> packaging, how hard do you think it is for people *without*
>> experience. I know Dennis, for example, is sitting on a heap of opencl
>> packages which are incredibly useful to many people.
>>
>> I believe we have to change our ways.
>
> The problem is real.  I have taken contributing back to upstream _very_
> serious, and I haven't been able to get everything back into GNU Guix
> either.
>
> Packages I work(ed) on that haven't made it upstream (yet) due to
> ``imperfect'' patches:
> * MongoDB:    Bundled source code;
> * GParted:    The help function does not work without external
>               documentation database tool;

(I think it’s OK if GParted’s documentation isn’t available; that’s
probably the case for some other GNOME apps.)

> * FreeBayes:  At first, licensing issues, now just a plain ugly patch to
>               deal with the unbundling of its dependencies in the
>               Makefiles of this project;
> * VCFLib:     Same situation as FreeBayes.  To be honest, this package
>               would've not ended up as a separate package if I didn't
>               have to split up FreeBayes.  I consider this a positive
>               effect of the review process.

Recursive bundling?  Woow.  :-)

Bundling is definitely a difficulty.  I still think there are good
reasons to unbundle software, but there are also a few exceptions in the
packages we provide.

It might be that VCFLib or the things in bundles have practically no
other user, in which case bundling makes absolutely no difference.

So I’m guessing these might be acceptable as-is.

> Maybe we could create an online course to do packaging with GNU Guix and
> make it rewarding with a grading system and giving achievement points..
> That might make the incentive to make the upstreaming step of packaging
> more fun and more like a learning process rather than a recurrent PITA.
> (This is something I could spend time at..)

Sure.  Concrete suggestions like this often help more than rants!  :-)

Thank you,
Ludo’.

Re: none

[myglc2]

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

> Hi Roel,
>
> Roel Janssen <roel@gnu.org> skribis:
>
[...]
>
>> One thing that really helped me in reducing the time to contribute
>> changes to the upstream distribution, is to have a good workflow.  I
>> ended up doing the following:
>> 1. Make the changes.
>> 2. Commit the changes.
>> 3 git format-patch -1 --no-attach
>> 4. git reset --hard <latest commit on origin/master>
>> 5. Submit the patch to the mailing list
>> 6. Wait for response and probably go back to 1.
>>
>> I made all of my changes on a GNU Guix git checkout.  So, not writing
>> package definitions on a separate repository.
>
> Do you think it would help to add this as a section in the manual?

This is a great idea!

Re: none

[Leo Famulari]

On Fri, Jul 22, 2016 at 10:50:14PM +1000, Jookia wrote:
> On top of that, the maintainers can't even use the mailing list properly:
> Patches are lost, discussion doesn't happen, things are lost and it's hard for
> new users to join in. Who exactly benefits from this workflow compared to
> something web-based? Sure, maybe you could argue that the maintainers are best
> served with it, or that you personally are attuned to that. Fine, but let's not
> pretend the mailing list isn't gruelling.

I've heard a handful of people express frustration with a mail-based
workflow. Here's what's easy for me:

1) I set up my mail provider / server to put all mail from
guix-devel@gnu.org into a Guix mailbox. This doesn't require advanced
knowledge. Even the most "user-friendly" solutions like GMail have this
feature.

2) When a message is "done", I put it in an Archive mailbox or delete
it. A message is done when it no longer requires attention. For example,
when I've replied and am waiting for the other person to reply, or when
a patch has been merged.

> It's a complicated setup in return for being able to track what's happening in
> the project. If I were to ask, 'how many patches are pending review' right now
> you'd have absolutely no idea.

I can look at my Guix mailbox to see all outstanding patches.

By the way, if someone asks the submitter to look into something or make
a change, the patch is no longer outstanding until they reply. The ball
is now in their court. I archive their message if I have nothing else to
add [0]. We all manage *our own submissions*. Nobody else is responsible
for that. Otherwise, we can't expect that the submitter will maintain
their code once it has been merged.

[0] Sometimes I don't archive messages, because I know that I will pick
up the work if the submitter drops it.

Re: none

[Tomáš Čech]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

On Fri, Jul 22, 2016 at 12:38:44PM -0400, myglc2 wrote:
>ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi Roel,
>>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>[...]
>>
>>> One thing that really helped me in reducing the time to contribute
>>> changes to the upstream distribution, is to have a good workflow.  I
>>> ended up doing the following:
>>> 1. Make the changes.
>>> 2. Commit the changes.
>>> 3 git format-patch -1 --no-attach
>>> 4. git reset --hard <latest commit on origin/master>
>>> 5. Submit the patch to the mailing list
>>> 6. Wait for response and probably go back to 1.
>>>
>>> I made all of my changes on a GNU Guix git checkout.  So, not writing
>>> package definitions on a separate repository.
>>
>> Do you think it would help to add this as a section in the manual?
>
>This is a great idea!

This reminds me:

https://cdn.meme.am/instances/500x/69604641.jpg


I ended with using topic branches or queues instead, all on top of
master.

wip - not yet finished changes
review - sent to ML and waiting for review
lvm, kernel, ... - branches with some topic changes

cherry-picking from wip to review and sending from there as described
above.

`git pull --rebase' will identify when they have been merged.

S_W

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: none

[David Craven]

> If the maintainer wants to do additional changes, I also prefer he does it in
> a separate patch/commit, as that would enable me to git pull --ff instead of
> merge...

I like fetching origin master, checking which patches made it in and then
rebase -i origin/master and drop the commits that made it in...

Re: none

[Jookia]

On Fri, Jul 22, 2016 at 05:19:42PM -0400, Leo Famulari wrote:
> I can look at my Guix mailbox to see all outstanding patches.

Can you post a list of this? Does it include my outstanding patches?

> By the way, if someone asks the submitter to look into something or make
> a change, the patch is no longer outstanding until they reply. The ball
> is now in their court. I archive their message if I have nothing else to
> add [0]. We all manage *our own submissions*. Nobody else is responsible
> for that. Otherwise, we can't expect that the submitter will maintain
> their code once it has been merged.

This is true, but this still doesn't fix the issue that reviewers sometimes
don't reply and eventually just forget about patches.

Re: none

[Leo Famulari]

On Sun, Jul 24, 2016 at 02:17:21PM +1000, Jookia wrote:
> On Fri, Jul 22, 2016 at 05:19:42PM -0400, Leo Famulari wrote:
> > I can look at my Guix mailbox to see all outstanding patches.
> 
> Can you post a list of this? Does it include my outstanding patches?

It does not include your patches. I archived the messages that included
your previously outstanding patches when you withdrew them from
consideration. Many of your patches were to parts of the system that I
don't understand. Readers of this list will recognize that I usually
reply to package patches. That's basically the current limit of my
knowledge.

The list is below. Some of these appear abandoned, some are unfinished,
some are being held for the next core-updates cycle, and some are
difficult to review (documentation patches are surprisingly hard to
review!). By the way, this list does not include my own unfinished work,
or the dozens of non-patch discussions that I am not ready to forget.

Re: [PATCH] gnu: Add libosinfo.
[PATCH] Add sonata and python-mpd2
[PATCH] URL format change for haskell.scm
[PATCH] xorg.scm fix http to https URLs.
[WIP v0.1 0/8] KDE framework 5, tier 1
Re: [PATCH] gnu: libgcrypt update to 1.7.1
Re: (pre-release) [PATCH] torsocks update to 2.2.0-rc1
Re: [PATCH] Add python-pythondialog
Re: [PATCH] gnu: Add netcat-openbsd. [v2 
[PATCH] doc: 7.6.3 example: revision
Re: [PATCH] gnu: Add fontconfig-path-max.
[PATCH] Enhance USB install
[PATCH 1/6] gnu: libgcrypt: Update to 1.7.2. et al
[PATCH 1/3] doc: Point out preference of message format.
[PATCH 2/3] doc: Send changes in your patch which are related.
[PATCH] doc: Explain when guix edit is read-only.
[PATCH] gnu: perl-io-socket-ssl: Update to 2.033 and add IDN support.
Re: [PATCH 2/3] profiles: Add fonts-dir-file hook.
[PATCH] lint: 'inputs-should-be-native' checks for intltool, itstool and glib:bin.
[PATCH] download: Add official SourceForge mirror.
[PATCH} Add RAID devices.
[PATCH] Add gnu/packages/u-boot.scm with all the boards that u-boot supports right now 
[PATCH] gnu: icecat: Install icons.
Re: [PATCH 3/3] gnu: icedtea-6: Generate keystore.

Re: none

[Jookia]

On Sun, Jul 24, 2016 at 02:35:41AM -0400, Leo Famulari wrote:
> It does not include your patches. I archived the messages that included
> your previously outstanding patches when you withdrew them from
> consideration. Many of your patches were to parts of the system that I
> don't understand. Readers of this list will recognize that I usually
> reply to package patches. That's basically the current limit of my
> knowledge.

I'm glad to hear that. It's interesting that you point this out, perhaps the
problem with my experiences I've had is that nobody wants to assign discussions
or the patches I've worked on to themselves? What should happen when nobody
wants to take up a patch or discussion?

Re: none

[Christopher Allan Webber]

Jookia writes:

>> What makes things easier for me personally is to not worry about
>> urgency.  Nothing I do is really urgent.  If I need to provide a package
>> for someone at the institute I don’t wait for acceptance in Guix
>> upstream; I just push it to our own “guix-bimsb” repo, which is used via
>> GUIX_PACKAGE_PATH.  Eventually, changes are polished and get accepted
>> upstream; at that point I remove them from the external repo.  There is
>> no hurry and I can choose to take my time addressing issues mentioned in
>> reviews.  (One of my patches for “pam_limits” went through several major
>> revisions over a duration of half a year or so.  I’m a sloth.)
>
> Guuix uses a mailing list for development, like most GNU projects. Maybe this
> works for those, but Guix is trying to be hip and cool and fresh compared to
> most GNU projects which are stable and generally a pain to contribute to.
>
> On top of that, the maintainers can't even use the mailing list properly:
> Patches are lost, discussion doesn't happen, things are lost and it's hard for
> new users to join in. Who exactly benefits from this workflow compared to
> something web-based? Sure, maybe you could argue that the maintainers are best
> served with it, or that you personally are attuned to that. Fine, but let's not
> pretend the mailing list isn't gruelling.

GNU MediaGoblin is "hip and cool" (or something) in that it uses a web
based issue tracker primarily.  (I guess it be hipper and cooler by
using something that integrated with git and had "web based pull
requests".)  Note that it hasn't saved us here.  There are times I fall
behind, and so do other contributors, and things get clogged up.  Often
I am envious these days of the speed at which Guix moves.  (A lot of the
slowness is related to me trying to advance standards work that helps
MediaGoblin in the long run, but that's an aside.)

Technological decisions can play a huge part... though even more so is
contributor bandwidth...

>> Aren’t you already doing this with your separate package set on Github?
>> In my opinion there is no need for an official project like that.  We
>> want most changes to be made to Guix directly.  Changes there are much
>> more likely to benefit the majority of users.
>
> This is the reason why I really dislike the current attitude of the community.
> You're building an operating system which by definition is meant to serve a ton
> of different needs, building it slowly and not urgently at all, but then arguing
> changes should be kept centralized for the benefit of all users and staging
> features should be pushed to whateve personal repositories we have.

Everyone else has said everything I'd like to say on this front mostly,
but I *do* think it's great that Guix is pure and has high standards.
That said, Guix probably could use some quasi-organized "guix-heresy"
external repositories that help people be "practical" where we can't.
(Heck, we won't be even able to advocate it, but the people who want it
will find it.)

To address Mark Weaver's points, yeah, that stuff will break
occasionally as in terms of internal Guix changes to the
codebase... that's the cost of doing it.

As one more aside, I'm glad to see this conversation happening but also
kind of bummed out... pretty much everyone on here I really admire.  I'm
confident things will pan out, if we listen to each other.

 - Chris

Re: none

[Andreas Enge]

Hi Chris,

thanks for your contribution!

On Sun, Jul 24, 2016 at 11:52:52AM -0500, Christopher Allan Webber wrote:
> GNU MediaGoblin is "hip and cool" (or something) in that it uses a web
> based issue tracker primarily.

Do you think we could learn from GNU MediaGoblin to be hipper and cooler?
Would you recommend your system?

Andreas

PS:
"Von der Sowjetunion lernen, heißt siegen lernen"