(unknown),

(unknown),

[John Darrington]

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

However thanks for showing me the correct format.

Updated patches follow

[PATCH 1/3] gnu: boost: New module

[John Darrington]

* gnu/packages/boost.scm  New file
* gnu-system.am (GNU_SYSTEM_MODULES): Add boost.scm
---
 gnu-system.am          |    1 +
 gnu/packages/boost.scm |   88 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 89 insertions(+)
 create mode 100644 gnu/packages/boost.scm

diff --git a/gnu-system.am b/gnu-system.am
index e87f671..43b9457 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -40,6 +40,7 @@ GNU_SYSTEM_MODULES =				\
   gnu/packages/bdb.scm				\
   gnu/packages/bdw-gc.scm			\
   gnu/packages/bison.scm			\
+  gnu/packages/boost.scm			\
   gnu/packages/bootstrap.scm			\
   gnu/packages/cdrom.scm			\
   gnu/packages/cflow.scm			\
diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
new file mode 100644
index 0000000..3275fe0
--- /dev/null
+++ b/gnu/packages/boost.scm
@@ -0,0 +1,88 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2014 John Darrington <jmd@gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages boost)
+  #:use-module ((guix licenses)
+                #:renamer (symbol-prefix-proc 'license:))
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages tcsh)
+  #:use-module (gnu packages perl))
+
+(define-public boost
+  (package
+    (name "boost")
+    (version "1.55.0")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "mirror://sourceforge/boost/boost_"
+                    (string-map (lambda (x) (if (eq? x #\.) #\_ x)) version)
+                    ".tar.bz2"))
+              (sha256
+               (base32
+                "0lkv5dzssbl5fmh2nkaszi8x9qbj80pr4acf9i26sj3rvlih1w7z"))))
+    (build-system gnu-build-system)
+    (native-inputs
+     `(("perl" ,perl)
+       ("python" ,python-2)
+       ("tcsh" ,tcsh)))
+    (arguments
+     `(#:phases
+       (alist-replace
+        'configure 
+        (lambda* (#:key outputs #:allow-other-keys) 
+          (let ((out (assoc-ref outputs "out")))
+            (substitute* '("libs/config/configure"
+                           "libs/spirit/classic/phoenix/test/runtest.sh"
+                           "tools/build/v2/doc/bjam.qbk"
+                           "tools/build/v2/engine/execunix.c"
+                           "tools/build/v2/engine/Jambase"
+                           "tools/build/v2/engine/jambase.c")
+              (("/bin/sh") (which "sh")))
+
+            (setenv "SHELL" (which "sh"))
+            (setenv "CONFIG_SHELL" (which "sh"))
+            
+            (zero? (system* "./bootstrap.sh" 
+                            (string-append "--prefix=" out) 
+                            "--with-toolset=gcc"))))
+        (alist-replace
+         'build
+         (lambda _
+           (zero? (system* "./b2" "threading=multi" "link=shared")))
+         
+         (alist-replace
+          'check
+          (lambda _ #t)
+          
+          (alist-replace
+           'install
+           (lambda _
+             (zero? (system* "./b2" "install" "threading=multi" "link=shared")))
+           %standard-phases))))))
+    
+    (home-page "http://boost.org")
+    (synopsis "Peer-reviewed portable C++ source libraries")
+    (description  "A collection of libraries intended to be widely useful, and
+usable across a broad spectrum of applications.") 
+    (license (license:x11-style "http://www.boost.org/LICENSE_1_0.txt" 
+             "Some components have other similar licences."))))
-- 
1.7.10.4

[PATCH 2/3] gnu: inkscape: New module

[John Darrington]

* gnu/packages/inkscape.scm: New file.
* gnu-system.am (GNU_SYSTEM_MODULES): Add inkscape.scm.
---
 gnu-system.am                                   |    2 +
 gnu/packages/inkscape.scm                       |   79 +++++++++++++++++++++++
 gnu/packages/patches/inkscape-stray-comma.patch |   13 ++++
 3 files changed, 94 insertions(+)
 create mode 100644 gnu/packages/inkscape.scm
 create mode 100644 gnu/packages/patches/inkscape-stray-comma.patch

diff --git a/gnu-system.am b/gnu-system.am
index 43b9457..33b29c9 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -110,6 +110,7 @@ GNU_SYSTEM_MODULES =				\
   gnu/packages/idutils.scm			\
   gnu/packages/imagemagick.scm			\
   gnu/packages/indent.scm			\
+  gnu/packages/inkscape.scm			\
   gnu/packages/irssi.scm			\
   gnu/packages/iso-codes.scm			\
   gnu/packages/kde.scm				\
@@ -270,6 +271,7 @@ dist_patch_DATA =						\
   gnu/packages/patches/gtkglext-disable-disable-deprecated.patch \
   gnu/packages/patches/gtkglext-remove-pangox-dependency.patch  \
   gnu/packages/patches/hop-bigloo-4.0b.patch			\
+  gnu/packages/patches/inkscape-stray-comma.patch               \
   gnu/packages/patches/libevent-dns-tests.patch			\
   gnu/packages/patches/libffi-mips-n32-fix.patch		\
   gnu/packages/patches/liboop-mips64-deplibs-fix.patch		\
diff --git a/gnu/packages/inkscape.scm b/gnu/packages/inkscape.scm
new file mode 100644
index 0000000..5837c32
--- /dev/null
+++ b/gnu/packages/inkscape.scm
@@ -0,0 +1,79 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2014 John Darrington <jmd@gnu.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages inkscape)
+  #:use-module ((guix licenses)
+                #:renamer (symbol-prefix-proc 'license:))
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages aspell)
+  #:use-module (gnu packages bdw-gc)
+  #:use-module (gnu packages boost)
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages gtk)
+  #:use-module (gnu packages maths)
+  #:use-module (gnu packages perl)
+  #:use-module (gnu packages pdf)
+  #:use-module (gnu packages popt)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages xml)
+  #:use-module (gnu packages ghostscript)
+  #:use-module (gnu packages fontutils)
+  #:use-module (gnu packages libpng)
+  #:use-module (gnu packages pkg-config))
+
+(define-public inkscape
+  (package
+    (name "inkscape")
+    (version "0.48.4")
+    (source (origin
+              (method url-fetch)
+             (uri (string-append
+                   "mirror://sourceforge/inkscape/inkscape-" version ".tar.gz"))
+             (sha256
+              (base32
+               "0nhxsgrgsx6zrgpkd1akxjvmdqjp8ccnsvlwxh62l0brg84fw6bf"))
+             (patches (list (search-patch "inkscape-stray-comma.patch")))))
+    (build-system gnu-build-system)
+    (inputs 
+     `(("aspell" ,aspell) 
+       ("gtkmm" ,gtkmm-2)
+       ("gtk" ,gtk+-2)
+       ("gsl" ,gsl)
+       ("poppler" ,poppler)
+       ("libpng" ,libpng)
+       ("libxml2" ,libxml2)
+       ("libxslt" ,libxslt)
+       ("libgc" ,libgc)
+       ("freetype" ,freetype)
+       ("popt" ,popt)
+       ("python" ,python-2)
+       ("lcms" ,lcms)
+       ("boost" ,boost)))
+    (native-inputs
+     `(("intltool" ,intltool)
+       ("perl" ,perl)
+       ("pkg-config" ,pkg-config)))
+    (home-page "http://inkscape.org/")
+    (synopsis "vector graphics editor")
+    (description "Inkscape is a free vector graphics editor similar to
+proprietary competitors. What sets Inkscape apart is its use of Scalable
+Vector Graphics (SVG), an open XML-based W3C standard, as the native format.")   
+    (license license:gpl2))) ;; Somewhat ambiguous whether v2 or v2+ is intended
diff --git a/gnu/packages/patches/inkscape-stray-comma.patch b/gnu/packages/patches/inkscape-stray-comma.patch
new file mode 100644
index 0000000..0b000d9
--- /dev/null
+++ b/gnu/packages/patches/inkscape-stray-comma.patch
@@ -0,0 +1,13 @@
+This is verbatim from Upstream:        http://bazaar.launchpad.net/~inkscape.dev/inkscape/RELEASE_0_48_BRANCH/diff/9943
+--- a/src/widgets/desktop-widget.h	2011-06-06 06:43:00 +0000
++++ b/src/widgets/desktop-widget.h	2013-01-05 14:34:09 +0000
+@@ -239,7 +239,7 @@
+ private:
+     GtkWidget *tool_toolbox;
+     GtkWidget *aux_toolbox;
+-    GtkWidget *commands_toolbox,;
++    GtkWidget *commands_toolbox;
+     GtkWidget *snap_toolbox;
+ 
+     static void init(SPDesktopWidget *widget);
+
-- 
1.7.10.4

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: [PATCH 1/3] gnu: boost: New module

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> * gnu/packages/boost.scm  New file
> * gnu-system.am (GNU_SYSTEM_MODULES): Add boost.scm

Applied with trailing whitespace removed, thanks!

Ludo’.

Re: [PATCH 2/3] gnu: inkscape: New module

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> * gnu/packages/inkscape.scm: New file.
> * gnu-system.am (GNU_SYSTEM_MODULES): Add inkscape.scm.

Cool, applied (added the missing part of the log, for the patch.)

> +    (synopsis "vector graphics editor")

I capitalized this.

> +    (description "Inkscape is a free vector graphics editor similar to
> +proprietary competitors. What sets Inkscape apart is its use of Scalable
> +Vector Graphics (SVG), an open XML-based W3C standard, as the native format.")   

I removed the “free” and the reference to proprietary competitors.

> +    (license license:gpl2))) ;; Somewhat ambiguous whether v2 or v2+ is intended

It’s actually GPLv2+ since the source files do not specify the version.

Thank you!

Ludo’.

Re: [PATCH 2/3] gnu: inkscape: New module

[John Darrington]

On Wed, Feb 05, 2014 at 12:09:02AM +0100, Ludovic Court??s wrote:
     
     > * gnu/packages/inkscape.scm: New file.
     > * gnu-system.am (GNU_SYSTEM_MODULES): Add inkscape.scm.
     
     Cool, applied (added the missing part of the log, for the patch.)
     
     > +    (synopsis "vector graphics editor")
     
     I capitalized this.

Sorry for not noticising these.
     
     > +    (description "Inkscape is a free vector graphics editor similar to
     > +proprietary competitors. What sets Inkscape apart is its use of Scalable
     > +Vector Graphics (SVG), an open XML-based W3C standard, as the native format.")   
     
     I removed the ???free??? and the reference to proprietary competitors.

Fair enough.  The blurb on the website mentions them by name. I decided to drop
the names.  If you want to omit any mention altogether, I don't have any objection.
     
     > +    (license license:gpl2))) ;; Somewhat ambiguous whether v2 or v2+ is intended
     
     It???s actually GPLv2+ since the source files do not specify the version.

It kind of does indirectly. It says "Under GPL - See the file COPYING" and
COPYING contains the text for v2.   I thought it safer to assume v2 only.
     
     

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

Re: [PATCH 2/3] gnu: inkscape: New module

[Ludovic Courtès]

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

> On Wed, Feb 05, 2014 at 12:09:02AM +0100, Ludovic Court??s wrote:

[...]

>      > +    (description "Inkscape is a free vector graphics editor similar to
>      > +proprietary competitors. What sets Inkscape apart is its use of Scalable
>      > +Vector Graphics (SVG), an open XML-based W3C standard, as the native format.")   
>      
>      I removed the ???free??? and the reference to proprietary competitors.
>
> Fair enough.  The blurb on the website mentions them by name. I decided to drop
> the names.  If you want to omit any mention altogether, I don't have any objection.

Yeah, what we agreed on long ago was to not mention “free” in
descriptions (or similar), because everything is free in the distro.
Also the GCS have long recommended against referring to non-free
software, and it clearly doesn’t bring much here (the situation may be
different for software that aims for interoperability with non-free
software, like LibreDWG or Octave.)

>      > +    (license license:gpl2))) ;; Somewhat ambiguous whether v2 or v2+ is intended
>      
>      It???s actually GPLv2+ since the source files do not specify the version.
>
> It kind of does indirectly. It says "Under GPL - See the file COPYING" and
> COPYING contains the text for v2.   I thought it safer to assume v2 only.

GPLv2 reads:

  If the Program does not specify a version number of this License, you
  may choose any version ever published by the Free Software Foundation.

Thanks,
Ludo’.

Re: [PATCH 2/3] gnu: inkscape: New module

[John Darrington]

On Wed, Feb 05, 2014 at 02:49:17PM +0100, Ludovic Court??s wrote:
     GPLv2 reads:
     
       If the Program does not specify a version number of this License, you
       may choose any version ever published by the Free Software Foundation.
     
Yes. I know.  - And in this case, the program DOES (indirectly) specify a version 
number, by refering to a file which contains a specific version.   But if you want
to interpret this differently, I won't argue.

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.

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