Re: none

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

(unknown)

[Unknown, Pjotr Prins]

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.
---
 gnu/local.mk                                       |   1 +
 gnu/packages/elixir.scm                            |  91 ++++++++++++
 .../patches/elixir-disable-failing-tests.patch     | 108 +++++++++++++++
 .../patches/elixir-disable-mix-tests.patch         | 152 +++++++++++++++++++++
 gnu/packages/ruby.scm                              |   1 -
 5 files changed, 352 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/elixir.scm
 create mode 100644 gnu/packages/patches/elixir-disable-failing-tests.patch
 create mode 100644 gnu/packages/patches/elixir-disable-mix-tests.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 536ecef..7a9a820 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -104,6 +104,7 @@ GNU_SYSTEM_MODULES =				\
   %D%/packages/ebook.scm			\
   %D%/packages/ed.scm				\
   %D%/packages/elf.scm				\
+  %D%/packages/elixir.scm			\
   %D%/packages/emacs.scm			\
   %D%/packages/enchant.scm			\
   %D%/packages/engineering.scm			\
diff --git a/gnu/packages/elixir.scm b/gnu/packages/elixir.scm
new file mode 100644
index 0000000..c1bbab3
--- /dev/null
+++ b/gnu/packages/elixir.scm
@@ -0,0 +1,91 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Leo Famulari <leo@famulari.name>
+;;; Copyright © 2016 Pjotr Prins <pjotr.public12@thebird.nl>
+;;;
+;;; 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 elixir)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix build-system gnu)
+  #:use-module (guix download)
+  #:use-module (guix packages)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages base)  ; for patch
+  #:use-module (gnu packages erlang)
+  #:use-module (gnu packages version-control))
+
+(define-public elixir
+  (package
+   (name "elixir")
+   (version "1.3.2")
+   (source (origin
+            (method url-fetch)
+            (uri (string-append
+                  "https://github.com/elixir-lang/elixir/archive/v"
+                  version ".tar.gz"))
+            (file-name (string-append name "-" version ".tar.gz"))
+            (sha256
+             (base32
+              "0jsc6kl7f74yszcypdv3w3vhyc9qfqav8nwc41in082m0vpfy95y"))))
+   (build-system gnu-build-system)
+   (native-inputs
+    `(("patch" ,patch)
+      ("patch/elixir-disable-failing-tests"
+       ,(search-patch "elixir-disable-failing-tests.patch"))
+      ("patch/elixir-disable-mix-tests"
+       ,(search-patch "elixir-disable-mix-tests.patch"))))
+   (inputs
+    `(("erlang" ,erlang)
+      ("git" ,git)))
+   (arguments
+    `(#:phases (modify-phases %standard-phases
+      (add-after 'unpack 'replace-git-path
+        (lambda _
+          (substitute* '("lib/elixir/lib/system.ex"
+                         "lib/mix/lib/mix/scm/git.ex")
+                       (("cmd\\('git") (string-append "cmd('" (which "git")))
+                       (("cmd\\(\"git") (string-append "cmd(\"" (which "git"))))
+          #t))
+      (delete 'configure)
+      (add-before 'build 'rewrite-path
+        (lambda* (#:key inputs #:allow-other-keys)
+                 (substitute* "bin/elixir"
+                              (("ERL_EXEC=\"erl\"")
+                               (string-append "ERL_EXEC=" (which "erl"))))))
+      (add-after 'build 'disable-breaking-elixir-tests
+        ;; when patching tests as part of source the build breaks, so we do
+        ;; it after the build phase
+        (lambda* (#:key inputs #:allow-other-keys)
+          (and
+           (zero? (system* "patch" "--force" "-p1" "-i"
+                           (assoc-ref inputs "patch/elixir-disable-failing-tests")))
+           (zero? (system* "patch" "--force" "-p1" "-i"
+                           (assoc-ref inputs "patch/elixir-disable-mix-tests")))
+           ;; Tests currently fail in these two files:
+           (delete-file "./lib/mix/test/mix/tasks/deps.git_test.exs")
+           (delete-file "./lib/mix/test/mix/shell_test.exs"))))
+      (replace 'check
+               (lambda _
+                 (zero? (system* "make" "test"))))) ;; 3124 tests, 0 failures, 11 skipped
+      #:make-flags (list (string-append "PREFIX=" %output))))
+   (home-page "http://elixir-lang.org/")
+   (synopsis "The Elixir programming language")
+   (description "Elixir is a dynamic, functional language used to
+build scalable and maintainable applications.  Elixir leverages the
+Erlang VM, known for running low-latency, distributed and
+fault-tolerant systems, while also being successfully used in web
+development and the embedded software domain.")
+   (license license:asl2.0)))
diff --git a/gnu/packages/patches/elixir-disable-failing-tests.patch b/gnu/packages/patches/elixir-disable-failing-tests.patch
new file mode 100644
index 0000000..802cb1e
--- /dev/null
+++ b/gnu/packages/patches/elixir-disable-failing-tests.patch
@@ -0,0 +1,108 @@
+diff --git a/lib/elixir/test/elixir/kernel/cli_test.exs b/lib/elixir/test/elixir/kernel/cli_test.exs
+index 3ffd56c..1232d19 100644
+--- a/lib/elixir/test/elixir/kernel/cli_test.exs
++++ b/lib/elixir/test/elixir/kernel/cli_test.exs
+@@ -39,6 +39,7 @@ end
+ defmodule Kernel.CLI.OptionParsingTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "properly parses paths" do
+     root = fixture_path("../../..") |> to_charlist
+     list = elixir('-pa "#{root}/*" -pz "#{root}/lib/*" -e "IO.inspect(:code.get_path, limit: :infinity)"')
+@@ -57,6 +58,7 @@ end
+ defmodule Kernel.CLI.AtExitTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "invokes at_exit callbacks" do
+     assert elixir(fixture_path("at_exit.exs") |> to_charlist) ==
+            'goodbye cruel world with status 1\n'
+@@ -66,6 +68,7 @@ end
+ defmodule Kernel.CLI.ErrorTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "properly format errors" do
+     assert :string.str('** (throw) 1', elixir('-e "throw 1"')) == 0
+     assert :string.str('** (ErlangError) erlang error: 1', elixir('-e "error 1"')) == 0
+@@ -86,6 +89,7 @@ defmodule Kernel.CLI.CompileTest do
+     {:ok, [tmp_dir_path: tmp_dir_path, beam_file_path: beam_file_path, fixture: fixture]}
+   end
+ 
++  @tag :skip
+   test "compiles code", context do
+     assert elixirc('#{context[:fixture]} -o #{context[:tmp_dir_path]}') == ''
+     assert File.regular?(context[:beam_file_path])
+@@ -96,6 +100,7 @@ defmodule Kernel.CLI.CompileTest do
+     Code.delete_path context[:tmp_dir_path]
+   end
+ 
++  @tag :skip
+   test "fails on missing patterns", context do
+     output = elixirc('#{context[:fixture]} non_existing.ex -o #{context[:tmp_dir_path]}')
+     assert :string.str(output, 'non_existing.ex') > 0, "expected non_existing.ex to be mentioned"
+@@ -103,6 +108,7 @@ defmodule Kernel.CLI.CompileTest do
+     refute File.exists?(context[:beam_file_path]), "expected the sample to not be compiled"
+   end
+ 
++  @tag :skip
+   test "fails on missing write access to .beam file", context do
+     compilation_args = '#{context[:fixture]} -o #{context[:tmp_dir_path]}'
+ 
+diff --git a/lib/elixir/test/elixir/kernel/dialyzer_test.exs b/lib/elixir/test/elixir/kernel/dialyzer_test.exs
+index 801d852..40fc5bc 100644
+--- a/lib/elixir/test/elixir/kernel/dialyzer_test.exs
++++ b/lib/elixir/test/elixir/kernel/dialyzer_test.exs
+@@ -60,16 +60,19 @@ defmodule Kernel.DialyzerTest do
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on rewrites", context do
+     copy_beam! context, Dialyzer.Rewrite
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on raise", context do
+     copy_beam! context, Dialyzer.Raise
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on macrocallback", context do
+     copy_beam! context, Dialyzer.Macrocallback
+     copy_beam! context, Dialyzer.Macrocallback.Impl
+diff --git a/lib/elixir/test/elixir/node_test.exs b/lib/elixir/test/elixir/node_test.exs
+index d1f1fe6..5c2d469 100644
+--- a/lib/elixir/test/elixir/node_test.exs
++++ b/lib/elixir/test/elixir/node_test.exs
+@@ -6,8 +6,10 @@ defmodule NodeTest do
+   doctest Node
+ 
+   test "start/3 and stop/0" do
+-    assert Node.stop == {:error, :not_found}
+-    assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
+-    assert Node.stop() == :ok
++    IO.puts "Skipping test because GNU Guix does not allow the HOME environment variable."
++
++    # assert Node.stop == {:error, :not_found}
++    # assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
++    # assert Node.stop() == :ok
+   end
+ end
+diff --git a/lib/elixir/test/elixir/system_test.exs b/lib/elixir/test/elixir/system_test.exs
+index aafa559..0f9c178 100644
+--- a/lib/elixir/test/elixir/system_test.exs
++++ b/lib/elixir/test/elixir/system_test.exs
+@@ -53,7 +53,8 @@ defmodule SystemTest do
+     assert System.endianness in [:little, :big]
+     assert System.endianness == System.compiled_endianness
+   end
+-
++ 
++  @tag :skip
+   test "argv/0" do
+     list = elixir('-e "IO.inspect System.argv" -- -o opt arg1 arg2 --long-opt 10')
+     {args, _} = Code.eval_string list, []
diff --git a/gnu/packages/patches/elixir-disable-mix-tests.patch b/gnu/packages/patches/elixir-disable-mix-tests.patch
new file mode 100644
index 0000000..649a916
--- /dev/null
+++ b/gnu/packages/patches/elixir-disable-mix-tests.patch
@@ -0,0 +1,152 @@
+diff --git a/lib/mix/test/mix/dep_test.exs b/lib/mix/test/mix/dep_test.exs
+index fff3351..d6ed1b3 100644
+--- a/lib/mix/test/mix/dep_test.exs
++++ b/lib/mix/test/mix/dep_test.exs
+@@ -244,6 +244,7 @@ defmodule Mix.DepTest do
+     end
+   end
+ 
++  @tag :skip
+   test "remote converger" do
+     deps = [{:deps_repo, "0.1.0", path: "custom/deps_repo"},
+             {:git_repo, "0.2.0", git: MixTest.Case.fixture_path("git_repo")}]
+@@ -301,6 +302,7 @@ defmodule Mix.DepTest do
+     end
+   end
+ 
++  @tag :skip
+   test "remote converger is not invoked if deps diverge" do
+     deps = [{:deps_repo, "0.1.0", path: "custom/deps_repo"},
+             {:git_repo, "0.2.0", git: MixTest.Case.fixture_path("git_repo"), only: :test}]
+diff --git a/lib/mix/test/mix/rebar_test.exs b/lib/mix/test/mix/rebar_test.exs
+index d2dd098..12cef15 100644
+--- a/lib/mix/test/mix/rebar_test.exs
++++ b/lib/mix/test/mix/rebar_test.exs
+@@ -120,6 +120,7 @@ defmodule Mix.RebarTest do
+     assert Enum.all?(deps, &(&1.manager == :rebar3))
+   end
+ 
++  @tag :skip
+   test "Rebar overrides" do
+     Mix.Project.push(RebarOverrideAsDep)
+ 
+@@ -150,6 +151,7 @@ defmodule Mix.RebarTest do
+     end
+   end
+ 
++  @tag :skip
+   test "get and compile dependencies for Rebar" do
+     Mix.Project.push(RebarAsDep)
+ 
+@@ -180,6 +182,7 @@ defmodule Mix.RebarTest do
+     end
+   end
+ 
++  @tag :skip
+   test "get and compile dependencies for rebar3" do
+     Mix.Project.push(Rebar3AsDep)
+ 
+diff --git a/lib/mix/test/mix/shell/io_test.exs b/lib/mix/test/mix/shell/io_test.exs
+index 9bfb6b4..d982ef3 100644
+--- a/lib/mix/test/mix/shell/io_test.exs
++++ b/lib/mix/test/mix/shell/io_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Shell.IOTest do
+     assert capture_io("", fn -> refute yes?("Ok?") end)
+   end
+ 
++  @tag :skip
+   test "runs a given command" do
+     assert capture_io("", fn -> assert cmd("echo hello") == 0 end) == "hello\n"
+ 
+diff --git a/lib/mix/test/mix/shell/quiet_test.exs b/lib/mix/test/mix/shell/quiet_test.exs
+index 626429b..99fab35 100644
+--- a/lib/mix/test/mix/shell/quiet_test.exs
++++ b/lib/mix/test/mix/shell/quiet_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Shell.QuietTest do
+     assert capture_io("", fn -> refute yes?("Ok?") end)
+   end
+ 
++  @tag :skip
+   test "runs a given command" do
+     assert capture_io("", fn -> assert cmd("echo hello") == 0 end) == ""
+ 
+diff --git a/lib/mix/test/mix/tasks/cmd_test.exs b/lib/mix/test/mix/tasks/cmd_test.exs
+index db4bf06..4d441f7 100644
+--- a/lib/mix/test/mix/tasks/cmd_test.exs
++++ b/lib/mix/test/mix/tasks/cmd_test.exs
+@@ -3,6 +3,7 @@ Code.require_file "../../test_helper.exs", __DIR__
+ defmodule Mix.Tasks.CmdTest do
+   use MixTest.Case
+ 
++  @tag :skip
+   test "runs the command for each app" do
+     in_fixture "umbrella_dep/deps/umbrella", fn ->
+       Mix.Project.in_project(:umbrella, ".", fn _ ->
+diff --git a/lib/mix/test/mix/tasks/deps.tree_test.exs b/lib/mix/test/mix/tasks/deps.tree_test.exs
+index 4f09ff3..c371997 100644
+--- a/lib/mix/test/mix/tasks/deps.tree_test.exs
++++ b/lib/mix/test/mix/tasks/deps.tree_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Tasks.Deps.TreeTest do
+     end
+   end
+ 
++  @tag :skip
+   test "shows the dependency tree", context do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -109,6 +110,7 @@ defmodule Mix.Tasks.Deps.TreeTest do
+     end
+   end
+ 
++  @tag :skip
+   test "shows the dependency tree in DOT graph format", context do
+     Mix.Project.push ConvergedDepsApp
+ 
+diff --git a/lib/mix/test/mix/tasks/deps_test.exs b/lib/mix/test/mix/tasks/deps_test.exs
+index b061777..cc45cf8 100644
+--- a/lib/mix/test/mix/tasks/deps_test.exs
++++ b/lib/mix/test/mix/tasks/deps_test.exs
+@@ -409,6 +409,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "fails on diverged dependencies by requirement" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -440,6 +441,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "fails on diverged dependencies even when optional" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -469,6 +471,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "works with converged dependencies" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -491,6 +494,7 @@ defmodule Mix.Tasks.DepsTest do
+     purge [GitRepo, GitRepo.Mixfile]
+   end
+ 
++  @tag :skip
+   test "works with overridden dependencies" do
+     Mix.Project.push OverriddenDepsApp
+ 
+diff --git a/lib/mix/test/mix/umbrella_test.exs b/lib/mix/test/mix/umbrella_test.exs
+index 69f9428..406668a 100644
+--- a/lib/mix/test/mix/umbrella_test.exs
++++ b/lib/mix/test/mix/umbrella_test.exs
+@@ -98,6 +98,7 @@ defmodule Mix.UmbrellaTest do
+     end
+   end
+ 
++  @tag :skip
+   test "loads umbrella child dependencies in all environments" do
+     in_fixture "umbrella_dep/deps/umbrella", fn ->
+       Mix.Project.in_project :umbrella, ".", fn _ ->
-- 
2.6.3

[PATCH] gnu: Add elixir.

[Pjotr Prins]

Sorry for the new thread. But this time the patch is readable from all
mailers (supporting UTF8). Please comment. 

Pj.

Re: [PATCH] gnu: Add elixir.

[Ben Woodcroft]

On 21/07/16 11:42, Pjotr Prins wrote:
> Sorry for the new thread. But this time the patch is readable from all
> mailers (supporting UTF8). Please comment.

Maybe to fix the $HOME issues by including a phase to set environment 
variables during testing as in e.g. blast+ ? i.e.

(setenv "HOME" "/tmp")

Is there a reason to include 'patch' as a native-dependency, rather than 
include them in the origin in 'patches' as usual?

I'm left confused why the mix tests fail. If they run git say, git is 
present and able to be used. Why doesn't it find it if it is in the 
PATH? Is it because it attempts to use the network?

Thanks for your work on this and please excuse any naivety as I am 
completely ignorant of elixir.
ben

Re: [PATCH] gnu: Add elixir.

[Pjotr Prins]

Hi Ben,

On Thu, Jul 21, 2016 at 09:43:57PM +1000, Ben Woodcroft wrote:
> On 21/07/16 11:42, Pjotr Prins wrote:
> >Sorry for the new thread. But this time the patch is readable from all
> >mailers (supporting UTF8). Please comment.
> 
> Maybe to fix the $HOME issues by including a phase to set
> environment variables during testing as in e.g. blast+ ? i.e.
> 
> (setenv "HOME" "/tmp")

So we can assume /tmp is there?

> Is there a reason to include 'patch' as a native-dependency, rather
> than include them in the origin in 'patches' as usual?

If you read my writeup on the packaging process at

  https://github.com/pjotrp/guix-notes/blob/master/ELIXIR.org

you can see the build phase fails on introducing *any* patch at
source. I am in the dark on the *why*, but my guess is that the mix
build tool does some dark magic checking.

> I'm left confused why the mix tests fail. If they run git say, git
> is present and able to be used. Why doesn't it find it if it is in
> the PATH? Is it because it attempts to use the network?

Some of it is git - which I patched, see the writeup - but there also
may be some network stuff going on.

> Thanks for your work on this and please excuse any naivety as I am
> completely ignorant of elixir.

We are working on fixing texts, see

  https://github.com/elixir-lang/elixir/issues/5043

meanwhile I would like the package accepted as is. Only 11 tests out of
2000+ are skipped and we know they are minor. That means Elixir passes
pretty much as is.

33 Mix tests are skipped, not much either (mostly git stuff). Mix is a
package manager so I am not too concerned. In fact it is working fine
in our development environments.

We'll work with the community on closing these tests. Meanwhile it
would be a good thing to accept the package so we can move forward in
deployments.

Pj.

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: [PATCH] gnu: Add elixir.

[Leo Famulari]

On Thu, Jul 21, 2016 at 09:43:57PM +1000, Ben Woodcroft wrote:
> On 21/07/16 11:42, Pjotr Prins wrote:
> > Sorry for the new thread. But this time the patch is readable from all
> > mailers (supporting UTF8). Please comment.
> 
> Maybe to fix the $HOME issues by including a phase to set environment
> variables during testing as in e.g. blast+ ? i.e.
> 
> (setenv "HOME" "/tmp")

The test passes when run with this variable set, as attached.

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: [PATCH] gnu: Add elixir.

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Jul 21, 2016 at 09:43:57PM +1000, Ben Woodcroft wrote:
>> On 21/07/16 11:42, Pjotr Prins wrote:
>> > Sorry for the new thread. But this time the patch is readable from all
>> > mailers (supporting UTF8). Please comment.
>> 
>> Maybe to fix the $HOME issues by including a phase to set environment
>> variables during testing as in e.g. blast+ ? i.e.
>> 
>> (setenv "HOME" "/tmp")
>
> The test passes when run with this variable set, as attached.

Not attached.  :-)

Ludo’.

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: [PATCH] gnu: Add elixir.

[Leo Famulari]

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

On Fri, Jul 22, 2016 at 02:55:55PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Thu, Jul 21, 2016 at 09:43:57PM +1000, Ben Woodcroft wrote:
> >> On 21/07/16 11:42, Pjotr Prins wrote:
> >> > Sorry for the new thread. But this time the patch is readable from all
> >> > mailers (supporting UTF8). Please comment.
> >> 
> >> Maybe to fix the $HOME issues by including a phase to set environment
> >> variables during testing as in e.g. blast+ ? i.e.
> >> 
> >> (setenv "HOME" "/tmp")
> >
> > The test passes when run with this variable set, as attached.
> 
> Not attached.  :-)

I'd forget my head if it wasn't already attached ;)

[-- Attachment #2: 0001-gnu-Add-elixir.patch --]
[-- Type: text/x-diff, Size: 15366 bytes --]

From 3f9ce99471d94422d3e74e2d67815e924b06974d Mon Sep 17 00:00:00 2001
From: Pjotr Prins <pjotr.public12@email>
Date: Thu, 21 Jul 2016 03:39:03 +0200
Subject: [PATCH] gnu: Add elixir.

* gnu/packages/elixir.scm,
gnu/packages/patches/elixir-disable-failing-tests.patch,
gnu/packages/patches/elixir-disable-mix-tests.patch: New files.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add package module.
(dist_patch_DATA): Add patches.

Signed-off-by: Leo Famulari <leo@famulari.name>
---
 gnu/local.mk                                       |   5 +-
 gnu/packages/elixir.scm                            |  91 ++++++++++++
 .../patches/elixir-disable-failing-tests.patch     |  90 ++++++++++++
 .../patches/elixir-disable-mix-tests.patch         | 152 +++++++++++++++++++++
 4 files changed, 337 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/elixir.scm
 create mode 100644 gnu/packages/patches/elixir-disable-failing-tests.patch
 create mode 100644 gnu/packages/patches/elixir-disable-mix-tests.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 31a4d58..8637a04 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -104,6 +104,7 @@ GNU_SYSTEM_MODULES =				\
   %D%/packages/ebook.scm			\
   %D%/packages/ed.scm				\
   %D%/packages/elf.scm				\
+  %D%/packages/elixir.scm			\
   %D%/packages/emacs.scm			\
   %D%/packages/enchant.scm			\
   %D%/packages/engineering.scm			\
@@ -478,8 +479,10 @@ dist_patch_DATA =						\
   %D%/packages/patches/doxygen-test.patch			\
   %D%/packages/patches/duplicity-piped-password.patch		\
   %D%/packages/patches/duplicity-test_selection-tmp.patch	\
-  %D%/packages/patches/elfutils-tests-ptrace.patch		\
   %D%/packages/patches/einstein-build.patch			\
+  %D%/packages/patches/elfutils-tests-ptrace.patch		\
+  %D%/packages/patches/elixir-disable-failing-tests.patch	\
+  %D%/packages/patches/elixir-disable-mix-tests.patch		\
   %D%/packages/patches/emacs-exec-path.patch			\
   %D%/packages/patches/emacs-fix-scheme-indent-function.patch	\
   %D%/packages/patches/emacs-scheme-complete-scheme-r5rs-info.patch	\
diff --git a/gnu/packages/elixir.scm b/gnu/packages/elixir.scm
new file mode 100644
index 0000000..873d0c2
--- /dev/null
+++ b/gnu/packages/elixir.scm
@@ -0,0 +1,91 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Leo Famulari <leo@famulari.name>
+;;; Copyright © 2016 Pjotr Prins <pjotr.public12@thebird.nl>
+;;;
+;;; 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 elixir)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix build-system gnu)
+  #:use-module (guix download)
+  #:use-module (guix packages)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages base)  ; for patch
+  #:use-module (gnu packages erlang)
+  #:use-module (gnu packages version-control))
+
+(define-public elixir
+  (package
+   (name "elixir")
+   (version "1.3.2")
+   (source (origin
+            (method url-fetch)
+            (uri (string-append
+                  "https://github.com/elixir-lang/elixir/archive/v"
+                  version ".tar.gz"))
+            (file-name (string-append name "-" version ".tar.gz"))
+            (sha256
+             (base32
+              "0jsc6kl7f74yszcypdv3w3vhyc9qfqav8nwc41in082m0vpfy95y"))))
+   (build-system gnu-build-system)
+   (native-inputs
+    `(("patch" ,patch)
+      ("patch/elixir-disable-failing-tests"
+       ,(search-patch "elixir-disable-failing-tests.patch"))
+      ("patch/elixir-disable-mix-tests"
+       ,(search-patch "elixir-disable-mix-tests.patch"))))
+   (inputs
+    `(("erlang" ,erlang)
+      ("git" ,git)))
+   (arguments
+    `(#:phases (modify-phases %standard-phases
+      (add-after 'unpack 'replace-git-path
+        (lambda _
+          (substitute* '("lib/elixir/lib/system.ex"
+                         "lib/mix/lib/mix/scm/git.ex")
+                       (("cmd\\('git") (string-append "cmd('" (which "git")))
+                       (("cmd\\(\"git") (string-append "cmd(\"" (which "git"))))
+          #t))
+      (add-after 'unpack 'set-env
+        (lambda _ (setenv "HOME" "/tmp")))
+      (delete 'configure)
+      (add-before 'build 'rewrite-path
+        (lambda* (#:key inputs #:allow-other-keys)
+                 (substitute* "bin/elixir"
+                              (("ERL_EXEC=\"erl\"")
+                               (string-append "ERL_EXEC=" (which "erl"))))))
+      (add-after 'build 'disable-breaking-elixir-tests
+        ;; when patching tests as part of source the build breaks, so we do
+        ;; it after the build phase
+        (lambda* (#:key inputs #:allow-other-keys)
+          (and
+           (zero? (system* "patch" "--force" "-p1" "-i"
+                           (assoc-ref inputs "patch/elixir-disable-failing-tests")))
+           (zero? (system* "patch" "--force" "-p1" "-i"
+                           (assoc-ref inputs "patch/elixir-disable-mix-tests")))
+           ;; Tests currently fail in these two files:
+           (delete-file "./lib/mix/test/mix/tasks/deps.git_test.exs")
+           (delete-file "./lib/mix/test/mix/shell_test.exs")))))
+      #:test-target "test" ;; 3124 tests, 0 failures, 11 skipped
+      #:make-flags (list (string-append "PREFIX=" %output))))
+   (home-page "http://elixir-lang.org/")
+   (synopsis "The Elixir programming language")
+   (description "Elixir is a dynamic, functional language used to
+build scalable and maintainable applications.  Elixir leverages the
+Erlang VM, known for running low-latency, distributed and
+fault-tolerant systems, while also being successfully used in web
+development and the embedded software domain.")
+   (license license:asl2.0)))
diff --git a/gnu/packages/patches/elixir-disable-failing-tests.patch b/gnu/packages/patches/elixir-disable-failing-tests.patch
new file mode 100644
index 0000000..59db8db
--- /dev/null
+++ b/gnu/packages/patches/elixir-disable-failing-tests.patch
@@ -0,0 +1,90 @@
+diff --git a/lib/elixir/test/elixir/kernel/cli_test.exs b/lib/elixir/test/elixir/kernel/cli_test.exs
+index 3ffd56c..1232d19 100644
+--- a/lib/elixir/test/elixir/kernel/cli_test.exs
++++ b/lib/elixir/test/elixir/kernel/cli_test.exs
+@@ -39,6 +39,7 @@ end
+ defmodule Kernel.CLI.OptionParsingTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "properly parses paths" do
+     root = fixture_path("../../..") |> to_charlist
+     list = elixir('-pa "#{root}/*" -pz "#{root}/lib/*" -e "IO.inspect(:code.get_path, limit: :infinity)"')
+@@ -57,6 +58,7 @@ end
+ defmodule Kernel.CLI.AtExitTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "invokes at_exit callbacks" do
+     assert elixir(fixture_path("at_exit.exs") |> to_charlist) ==
+            'goodbye cruel world with status 1\n'
+@@ -66,6 +68,7 @@ end
+ defmodule Kernel.CLI.ErrorTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "properly format errors" do
+     assert :string.str('** (throw) 1', elixir('-e "throw 1"')) == 0
+     assert :string.str('** (ErlangError) erlang error: 1', elixir('-e "error 1"')) == 0
+@@ -86,6 +89,7 @@ defmodule Kernel.CLI.CompileTest do
+     {:ok, [tmp_dir_path: tmp_dir_path, beam_file_path: beam_file_path, fixture: fixture]}
+   end
+ 
++  @tag :skip
+   test "compiles code", context do
+     assert elixirc('#{context[:fixture]} -o #{context[:tmp_dir_path]}') == ''
+     assert File.regular?(context[:beam_file_path])
+@@ -96,6 +100,7 @@ defmodule Kernel.CLI.CompileTest do
+     Code.delete_path context[:tmp_dir_path]
+   end
+ 
++  @tag :skip
+   test "fails on missing patterns", context do
+     output = elixirc('#{context[:fixture]} non_existing.ex -o #{context[:tmp_dir_path]}')
+     assert :string.str(output, 'non_existing.ex') > 0, "expected non_existing.ex to be mentioned"
+@@ -103,6 +108,7 @@ defmodule Kernel.CLI.CompileTest do
+     refute File.exists?(context[:beam_file_path]), "expected the sample to not be compiled"
+   end
+ 
++  @tag :skip
+   test "fails on missing write access to .beam file", context do
+     compilation_args = '#{context[:fixture]} -o #{context[:tmp_dir_path]}'
+ 
+diff --git a/lib/elixir/test/elixir/kernel/dialyzer_test.exs b/lib/elixir/test/elixir/kernel/dialyzer_test.exs
+index 801d852..40fc5bc 100644
+--- a/lib/elixir/test/elixir/kernel/dialyzer_test.exs
++++ b/lib/elixir/test/elixir/kernel/dialyzer_test.exs
+@@ -60,16 +60,19 @@ defmodule Kernel.DialyzerTest do
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on rewrites", context do
+     copy_beam! context, Dialyzer.Rewrite
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on raise", context do
+     copy_beam! context, Dialyzer.Raise
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on macrocallback", context do
+     copy_beam! context, Dialyzer.Macrocallback
+     copy_beam! context, Dialyzer.Macrocallback.Impl
+diff --git a/lib/elixir/test/elixir/system_test.exs b/lib/elixir/test/elixir/system_test.exs
+index aafa559..0f9c178 100644
+--- a/lib/elixir/test/elixir/system_test.exs
++++ b/lib/elixir/test/elixir/system_test.exs
+@@ -53,7 +53,8 @@ defmodule SystemTest do
+     assert System.endianness in [:little, :big]
+     assert System.endianness == System.compiled_endianness
+   end
+-
++ 
++  @tag :skip
+   test "argv/0" do
+     list = elixir('-e "IO.inspect System.argv" -- -o opt arg1 arg2 --long-opt 10')
+     {args, _} = Code.eval_string list, []
diff --git a/gnu/packages/patches/elixir-disable-mix-tests.patch b/gnu/packages/patches/elixir-disable-mix-tests.patch
new file mode 100644
index 0000000..649a916
--- /dev/null
+++ b/gnu/packages/patches/elixir-disable-mix-tests.patch
@@ -0,0 +1,152 @@
+diff --git a/lib/mix/test/mix/dep_test.exs b/lib/mix/test/mix/dep_test.exs
+index fff3351..d6ed1b3 100644
+--- a/lib/mix/test/mix/dep_test.exs
++++ b/lib/mix/test/mix/dep_test.exs
+@@ -244,6 +244,7 @@ defmodule Mix.DepTest do
+     end
+   end
+ 
++  @tag :skip
+   test "remote converger" do
+     deps = [{:deps_repo, "0.1.0", path: "custom/deps_repo"},
+             {:git_repo, "0.2.0", git: MixTest.Case.fixture_path("git_repo")}]
+@@ -301,6 +302,7 @@ defmodule Mix.DepTest do
+     end
+   end
+ 
++  @tag :skip
+   test "remote converger is not invoked if deps diverge" do
+     deps = [{:deps_repo, "0.1.0", path: "custom/deps_repo"},
+             {:git_repo, "0.2.0", git: MixTest.Case.fixture_path("git_repo"), only: :test}]
+diff --git a/lib/mix/test/mix/rebar_test.exs b/lib/mix/test/mix/rebar_test.exs
+index d2dd098..12cef15 100644
+--- a/lib/mix/test/mix/rebar_test.exs
++++ b/lib/mix/test/mix/rebar_test.exs
+@@ -120,6 +120,7 @@ defmodule Mix.RebarTest do
+     assert Enum.all?(deps, &(&1.manager == :rebar3))
+   end
+ 
++  @tag :skip
+   test "Rebar overrides" do
+     Mix.Project.push(RebarOverrideAsDep)
+ 
+@@ -150,6 +151,7 @@ defmodule Mix.RebarTest do
+     end
+   end
+ 
++  @tag :skip
+   test "get and compile dependencies for Rebar" do
+     Mix.Project.push(RebarAsDep)
+ 
+@@ -180,6 +182,7 @@ defmodule Mix.RebarTest do
+     end
+   end
+ 
++  @tag :skip
+   test "get and compile dependencies for rebar3" do
+     Mix.Project.push(Rebar3AsDep)
+ 
+diff --git a/lib/mix/test/mix/shell/io_test.exs b/lib/mix/test/mix/shell/io_test.exs
+index 9bfb6b4..d982ef3 100644
+--- a/lib/mix/test/mix/shell/io_test.exs
++++ b/lib/mix/test/mix/shell/io_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Shell.IOTest do
+     assert capture_io("", fn -> refute yes?("Ok?") end)
+   end
+ 
++  @tag :skip
+   test "runs a given command" do
+     assert capture_io("", fn -> assert cmd("echo hello") == 0 end) == "hello\n"
+ 
+diff --git a/lib/mix/test/mix/shell/quiet_test.exs b/lib/mix/test/mix/shell/quiet_test.exs
+index 626429b..99fab35 100644
+--- a/lib/mix/test/mix/shell/quiet_test.exs
++++ b/lib/mix/test/mix/shell/quiet_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Shell.QuietTest do
+     assert capture_io("", fn -> refute yes?("Ok?") end)
+   end
+ 
++  @tag :skip
+   test "runs a given command" do
+     assert capture_io("", fn -> assert cmd("echo hello") == 0 end) == ""
+ 
+diff --git a/lib/mix/test/mix/tasks/cmd_test.exs b/lib/mix/test/mix/tasks/cmd_test.exs
+index db4bf06..4d441f7 100644
+--- a/lib/mix/test/mix/tasks/cmd_test.exs
++++ b/lib/mix/test/mix/tasks/cmd_test.exs
+@@ -3,6 +3,7 @@ Code.require_file "../../test_helper.exs", __DIR__
+ defmodule Mix.Tasks.CmdTest do
+   use MixTest.Case
+ 
++  @tag :skip
+   test "runs the command for each app" do
+     in_fixture "umbrella_dep/deps/umbrella", fn ->
+       Mix.Project.in_project(:umbrella, ".", fn _ ->
+diff --git a/lib/mix/test/mix/tasks/deps.tree_test.exs b/lib/mix/test/mix/tasks/deps.tree_test.exs
+index 4f09ff3..c371997 100644
+--- a/lib/mix/test/mix/tasks/deps.tree_test.exs
++++ b/lib/mix/test/mix/tasks/deps.tree_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Tasks.Deps.TreeTest do
+     end
+   end
+ 
++  @tag :skip
+   test "shows the dependency tree", context do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -109,6 +110,7 @@ defmodule Mix.Tasks.Deps.TreeTest do
+     end
+   end
+ 
++  @tag :skip
+   test "shows the dependency tree in DOT graph format", context do
+     Mix.Project.push ConvergedDepsApp
+ 
+diff --git a/lib/mix/test/mix/tasks/deps_test.exs b/lib/mix/test/mix/tasks/deps_test.exs
+index b061777..cc45cf8 100644
+--- a/lib/mix/test/mix/tasks/deps_test.exs
++++ b/lib/mix/test/mix/tasks/deps_test.exs
+@@ -409,6 +409,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "fails on diverged dependencies by requirement" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -440,6 +441,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "fails on diverged dependencies even when optional" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -469,6 +471,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "works with converged dependencies" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -491,6 +494,7 @@ defmodule Mix.Tasks.DepsTest do
+     purge [GitRepo, GitRepo.Mixfile]
+   end
+ 
++  @tag :skip
+   test "works with overridden dependencies" do
+     Mix.Project.push OverriddenDepsApp
+ 
+diff --git a/lib/mix/test/mix/umbrella_test.exs b/lib/mix/test/mix/umbrella_test.exs
+index 69f9428..406668a 100644
+--- a/lib/mix/test/mix/umbrella_test.exs
++++ b/lib/mix/test/mix/umbrella_test.exs
+@@ -98,6 +98,7 @@ defmodule Mix.UmbrellaTest do
+     end
+   end
+ 
++  @tag :skip
+   test "loads umbrella child dependencies in all environments" do
+     in_fixture "umbrella_dep/deps/umbrella", fn ->
+       Mix.Project.in_project :umbrella, ".", fn _ ->
-- 
2.9.1

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

Review process

[Ludovic Courtès]

Howdy,

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

> 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 find this unfair.  You are not a newcomer, as proved by the fact that
you’ve already identified weaknesses in the work you submit.

Thus, that you post it anyway can be understood as “I know this and that
should be done, but I’d rather let you do it on my behalf, kthxbye”.

Or perhaps you’re suggesting that reviews are unnecessary, or that the
points we insist on make little sense?

Well, I can tell you that as a user, I very much prefer that people who
add packages to the distro have taken their time to make it lean and
clean.  This QA work that you dislike is a service that we developers do
to users; it’s not something we do for the sake of elitism.

I hope this can clear misunderstandings!

Thanks for your feedback,
Ludo’.

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: Review process

[Pjotr Prins]

On Fri, Jul 22, 2016 at 06:02:48PM +0200, Ludovic Courtès wrote:
> > 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 find this unfair.  You are not a newcomer, as proved by the fact that
> you’ve already identified weaknesses in the work you submit.

Exactly. 

> Thus, that you post it anyway can be understood as “I know this and that
> should be done, but I’d rather let you do it on my behalf, kthxbye”.
> 
> Or perhaps you’re suggesting that reviews are unnecessary, or that the
> points we insist on make little sense?

If have explained things why they are as they are with the Elixir
package. I have done my utmost to get the package to this stage. There
is some work pending fixing tests with upstream. All that is in the
open and happening.

> Well, I can tell you that as a user, I very much prefer that people who
> add packages to the distro have taken their time to make it lean and
> clean.  This QA work that you dislike is a service that we developers do
> to users; it’s not something we do for the sake of elitism.
> 
> I hope this can clear misunderstandings!

Thanks Ludo. As it stands I am no longer submitting packages to ML. I
did my utmost to make the package lean and clean. This package is not
going in.

But, I suggest you listen. I know at least 4 people here who say they
have trouble submitting to Guix. Good people.

You know I love Guix and I am a great admirer of all of you and I
certainly appreciate the energy you put into developing Guix and
reviews. I won't go away, but I am making clear why I am quitting
working in this way. Mind, I saw this coming. I actually quit
submitting packages half a year ago and instead worked through others.
I was interested to see if I would survive this one last attempt. In
the end my opinion on the state of the package conflicts with yours -
even though I am the expert on Elixir here and the conflict is not
about knowledge of Guix itself. Please read this last sentence again.

I'll have a think on how to proceed from here. I want to work with
those 4 people. And I want to attract more people from conda, brew
etc. I am convinced we need to change our ways. This state of affairs
does not sit well with me. To call it elitist was a provocation, but I
actually think there is some truth to it. The world is divided in
people who can do the dance, and those who can't (for whatever
reason). We need to find a way where the lesser people (like me) can
contribute.

Now, THAT would make it a brilliant project.

Pj.

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: Review process

[Alex Kost]

Pjotr Prins (2016-07-23 05:24 +0300) wrote:

> Thanks Ludo. As it stands I am no longer submitting packages to ML. I
> did my utmost to make the package lean and clean. This package is not
> going in.
>
> But, I suggest you listen. I know at least 4 people here who say they
> have trouble submitting to Guix. Good people.

5 including me :-) I always feel big inconveniences sending patches, and
I don't like that the development happens on mailing list.  However
unlike Pjotr and Jookia I think it's my problem, not the one of the Guix
community.

I just wrote this because I'm almost sure that some day I will maintain
emacs interface separately from Guix again.  I've been regretting all
the time that it became a part of Guix.

-- 
Alex

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: Review process

[Mathieu Lirzin]

Alex Kost <alezost@gmail.com> writes:

> Pjotr Prins (2016-07-23 05:24 +0300) wrote:
>
>> Thanks Ludo. As it stands I am no longer submitting packages to ML. I
>> did my utmost to make the package lean and clean. This package is not
>> going in.
>>
>> But, I suggest you listen. I know at least 4 people here who say they
>> have trouble submitting to Guix. Good people.
>
> 5 including me :-) I always feel big inconveniences sending patches, and
> I don't like that the development happens on mailing list.  However
> unlike Pjotr and Jookia I think it's my problem, not the one of the Guix
> community.
>
> I just wrote this because I'm almost sure that some day I will maintain
> emacs interface separately from Guix again.  I've been regretting all
> the time that it became a part of Guix.

I am interested to know what do you miss from that the period you were
maintaining it separately?

-- 
Mathieu Lirzin

A registry for distributed sources and binaries

[Pjotr Prins]

After some thought I am coming to the following: my primary goals are
to lower the barrier to entry, scale out development of Guix packages
and have people collaborate on each others packages without some
centralized 'opinion'.

The main problems with the current GUIX_PACKAGE_PATH approach are

1. People are not aware about the work of others
2. Slightly complicated (you need a Guix source tree etc.)
3. No binary distribution

My immediate idea was to have a separate project, i.e. a fast and lossy
tree next to the current 'strict' tree. With a distribution server
'guix publish' that could work for those who are inclined to use a
lossy server (call it experimental or agile package definitions).

After some thought I decided there is still a major downside - it will
depend on central people to manage this second tree - even if it is
only for merging packages and git trees. That competes with the main
effort too which is inefficient.

Now I think we may better solve this with something akin to a plugin
system that we have with Rubygems, Python pip etc. A plugin system
that is truly distributed from source (you just need to provide a
registry). One example I worked on before is http://biogems.info/ for
Ruby packages in bioinformatics.

How about the following:

1. Separate from the GNU project, we create a number of registries of
   online git repos without opinion (i.e., anything goes, it is up to
   the authors). A registry can contain the work of multiple packages
   and multiple authors.

2. Each repo in the registry can create package definitions online

3. When someone wants to use a registry, run guix with

   guix package --registry http://biogems.info/bioinformatics.scm -A ruby

   i.e. to list all packages that have ruby, including the ones in
   that registry. Likewise for an incubator registry:

   guix package --registry http://incubator-guix.org/unstable.scm -A ruby

   generates a different list.

4. At install of a registry package, the entry can (optionally) point to a Guix
   publish server with its key, so we can do 'add key' and 'install
   binary or source package' for the registry. This way we get trusted
   binary distribution for distributed packages in registries.

This would also compete nicely with the likes of Docker, especially
when using containers, in a more secure way.

Registries solve the mentioned problems of GUIX_PACKAGE_PATH:

1. People are not aware about the work of others
2. Slightly complicated (you need a Guix source tree etc.)
3. No binary distribution

It also takes away the centralized approach of GNU Guix for those who
don't want that - though the main tree will still be developed against
for building a solid distribution etc. I.e., the core stuff continues,
but people are free to try other routes. All a registry needs to
provide is a guile file containing information of the package(s) whith
a pointer to online pointers of documentation, overview, guix publish
server and key.

Personally I think this will be very exciting. We can have a
metaregistry that lists all these packages so everyone can track them.

Scalability. Less opinion, less duplication of work. True incubators.

Pj.

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: A registry for distributed sources and binaries

[Tobias Geerinckx-Rice]

Pjotr,

On 24/07/2016 5:30, Pjotr Prins wrote:
> After some thought I am coming to the following: my primary goals are
> to lower the barrier to entry, scale out development of Guix packages
> and have people collaborate on each others packages without some
> centralized 'opinion'.

I've also been thinking about this a lot, which I hope will become a
less frustrating affair the more I become familiar with Guix internals.

> The main problems with the current GUIX_PACKAGE_PATH approach are
> [...]you need a Guix source tree[...]

Oh. Really? That seems like something that shouldn't be.

> My immediate idea was to have a separate project, i.e. a fast and lossy
> tree next to the current 'strict' tree. With a distribution server
> 'guix publish' that could work for those who are inclined to use a
> lossy server (call it experimental or agile package definitions).
> 
> After some thought I decided there is still a major downside - it will
> depend on central people to manage this second tree - even if it is
> only for merging packages and git trees. That competes with the main
> effort too which is inefficient.
> 
> Now I think we may better solve this with something akin to a plugin
> system that we have with Rubygems, Python pip etc. A plugin system
> that is truly distributed from source (you just need to provide a
> registry). One example I worked on before is http://biogems.info/ for
> Ruby packages in bioinformatics.

I have no experience with those languages. What do you see a ‘registry’
for Guix being, exactly?

A long time ago — at least it seems like it[1] — I did run Exherbo, a
source-based distribution based in part on Gentoo. Unlike Gentoo, it had
no concept of a centralised package repository.

Instead, there were a few repositories maintained by core developers
(something akin to ‘core’, ‘net’, ‘x11’...) and some others maintained
by random developers/userst (‘alice’, ‘bob’, ...). It didn't really
matter, though: they were distributed and managed in the same way.

It reminds me of Guix's (gnu package ...) collections, actually.

Package repositories were simply git/svn/... trees hosted wherever. The
only difference between the core repository and the others was that it
was configured/trusted by default. You could remove it just like any
other, if you liked fixing your system.

I was able to run the equivalent of, in Guix pseudocode:

  ~# guix package --install footools
  guix package: error: footools: unknown package
  [maybe it even suggested a list of repositories with packages
  named ‘footools’, I don't remember]

  ~# guix repository --add my-cool-repository
  [what is currently gnu/packages would be just another repository]

  ~# guix pull
  [fetches all repositories from their own URI, no central point]

  ~# guix package --install footools
  [footools is now installed]

  ~# guix package --install bar
  guix package: error: ‘bar’ requires ‘(input "blah")’ which isn't in
  any of your trusted repositories, try adding one of the following: ...

It was an almost perfect system, IMO. Anyway, I'm definitely rambling.

> Personally I think this will be very exciting. We can have a
> metaregistry that lists all these packages so everyone can track them.

Definitely count me as excited, too. :-)

Though if it's a fork, I'll cry.

Kind regards,

T G-R

[1]: Some details may be wrong. My brain has an eager garbage collector.

Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Sun, Jul 24, 2016 at 07:10:44AM +0200, Tobias Geerinckx-Rice wrote:
> > The main problems with the current GUIX_PACKAGE_PATH approach are
> > [...]you need a Guix source tree[...]
> 
> Oh. Really? That seems like something that shouldn't be.

You are right. I am using this to fixate the Guix tree against
packages. Guix itself is a moving target.

> I have no experience with those languages. What do you see a ‘registry’
> for Guix being, exactly?

Just a scheme or JSON file containg package info.

> A long time ago — at least it seems like it[1] — I did run Exherbo, a
> source-based distribution based in part on Gentoo. Unlike Gentoo, it had
> no concept of a centralised package repository.

I already like that ;)

> Package repositories were simply git/svn/... trees hosted wherever. The
> only difference between the core repository and the others was that it
> was configured/trusted by default. You could remove it just like any
> other, if you liked fixing your system.

Exactly.

> I was able to run the equivalent of, in Guix pseudocode:
> 
>   ~# guix package --install footools
>   guix package: error: footools: unknown package
>   [maybe it even suggested a list of repositories with packages
>   named ‘footools’, I don't remember]
> 
>   ~# guix repository --add my-cool-repository
>   [what is currently gnu/packages would be just another repository]
> 
>   ~# guix pull
>   [fetches all repositories from their own URI, no central point]
> 
>   ~# guix package --install footools
>   [footools is now installed]
> 
>   ~# guix package --install bar
>   guix package: error: ‘bar’ requires ‘(input "blah")’ which isn't in
>   any of your trusted repositories, try adding one of the following: ...
> 
> It was an almost perfect system, IMO. Anyway, I'm definitely rambling.

No no, you are getting my idea.

> > Personally I think this will be very exciting. We can have a
> > metaregistry that lists all these packages so everyone can track them.
> 
> Definitely count me as excited, too. :-)
> 
> Though if it's a fork, I'll cry.

No fork. A fork does not scale.

Pj.

Re: A registry for distributed sources and binaries

[Pjotr Prins]

Another interesting thought would be to even generalize the idea of
plugins:

  guix package --plugin http://URL/registry-plugin.scm -A ruby -- --registry http://my-registry/list.scm
  guix package --plugin http://URL/registry-plugin.scm -i ruby-package -- --registry http://my-registry/list.scm

I.e. the implementation of registry support does not even have to be
part of GNU Guix. The plugin would get access to the full args list
and be invoked from guix.

This would open up the road to other plugins and new inventions
outside the core tree, and simplify the core.

I can add plugin support and the registry support.

Pj.

Re: A registry for distributed sources and binaries

[Mark H Weaver]

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

> How about the following:
>
> 1. Separate from the GNU project, we create a number of registries of
>    online git repos without opinion (i.e., anything goes, it is up to
>    the authors). A registry can contain the work of multiple packages
>    and multiple authors.
>
> 2. Each repo in the registry can create package definitions online

The major problem with this proposal is that, to the extent it became
popular, it would drastically reduce the freedom we have to change Guix
itself.  We would need to start considering whether our changes might
break externally maintained packages.  A large proportion of our
internal procedures and macros would effectively become a public API.
We would no longer be able to freely make changes to the way packages
are specified, or make incompatible changes to the procedures and macros
used in package definitions on the client or build sides.  We would be
greatly constrained in our ability to make changes to the default phases
in our build systems.

Our core packages and most of our library packages would also
effectively be part of this API.  We would no longer be able to freely
do things like split packages into smaller pieces or multiple outputs.

Long ago, the Linux developers made a conscious decision to not support
out-of-tree drivers, for much the same reasons.  Many times over the
years, they have made changes to their internal APIs that required
corresponding changes to a large number of drivers.  As a result, they
have been able to keep their internal interfaces clean and free of
backward-compatibility cruft.

It's crucially important to the future vitality of this project that we
retain our freedom to evolve the design of Guix, the way packages are
specified in Guix, as well as the set of core packages.  These freedoms
will be drastically curtailed if we support a decentralized system of
externally-managed repositories.  Therefore, we must not do this.

What do other people think?

      Mark

Re: A registry for distributed sources and binaries

[Jookia]

On Sun, Jul 24, 2016 at 01:29:20AM -0400, Mark H Weaver wrote:
> It's crucially important to the future vitality of this project that we
> retain our freedom to evolve the design of Guix, the way packages are
> specified in Guix, as well as the set of core packages.  These freedoms
> will be drastically curtailed if we support a decentralized system of
> externally-managed repositories.  Therefore, we must not do this.
> 
> What do other people think?
> 
>       Mark

The problem we have is that people want to experiment and have custom versions
of Guix that people can use, with the common intent for coming to a conesnsus
later down the track and eventually have things merged in to upstream, or
perhaps not at all if it's for something like nonfree.

Nobody wants to fork, nobody wants to make enemies. We're all a bit frustrated
with each other at the moment because we have different goals.

I think the clearest system is a way to have multiple guixes installed at once.
Other package managers need not do this, but as long as the daemon compatiblity
is kept it should be fine. There could be a guix-jookia, guix-nonfree for those
that really want to run it on their nonfree systems. These would have their own
internal system with maximum freedom for experimentation. Getting users to
install these systems would be the hard part.

I think it's still worthwhile to remember that this is a political problem with
contributing upstream to Guix, so people are naturally trying to make
downstreams which Guix doesn't support.

Jookia.

Re: A registry for distributed sources and binaries

[Tobias Geerinckx-Rice]

Mark,

On 24/07/2016 7:29, Mark H Weaver wrote:
> Long ago, the Linux developers made a conscious decision to not 
> support out-of-tree drivers, for much the same reasons.  Many times 
> over the years, they have made changes to their internal APIs that 
> required corresponding changes to a large number of drivers.  As a 
> result, they have been able to keep their internal interfaces clean 
> and free of backward-compatibility cruft.

As well they should. As well should Guix. If anything, I consider
Linux's misguided ABI stability fetish to be an embarrassment, and hope
Guix never makes the same mistake, binary or not. 1.0 or not.

> It's crucially important to the future vitality of this project that 
> we retain our freedom to evolve the design of Guix, the way packages 
> are specified in Guix, as well as the set of core packages.

Absolutely.

> These freedoms will be drastically curtailed...

...if Guix chooses to impose misguided stability guarantees upon itself.

> if we support a decentralized system of externally-managed 
> repositories.

No. Break them.

If you're running an external Guix repository and don't bother to follow
the main development branch(es) with some attention, your users deserve
to get regular breakage warnings as a subtle hint that maybe they
shouldn't be trusting you with their software.

...provocation being the genesis of this thread and all :-)

> Therefore, we must not do this.

There seem to be two different meanings of ‘support’ at play here:
   - adding decentralised repository support to Guix so it can at least
     be done in a clean user-friendly way, which I think is excellent
vs.
   - promising some kind of API stability to those repositories, which
     I think is terrible.

It is quite possible that you can't have one without the other, or that
there's no sane way to coordinate API updates and their distribution to
users, or that it would make reproducibility a nightmare, or that it
would make Guix look bad when $randomthirdpartyrepository breaks. I
haven't sat down to sketch out all corner cases; I just write things on
the Internet.

I'm just not convinced by ‘X is bad, so we mustn't do Y’ until its
absolutely certain X requires Y.

> What do other people think?

More voices would be nice indeed! This thread has clarified several
interesting viewpoints.

Kind regards,

T G-R

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: A registry for distributed sources and binaries

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 811 bytes --]

OK, one more...

On 24/07/2016 7:48, Jookia wrote:
> I think the clearest system is a way to have multiple guixes 
> installed at once. Other package managers need not do this, but as 
> long as the daemon compatiblity is kept it should be fine. There 
> could be a guix-jookia, guix-nonfree for those that really want to 
> run it on their nonfree systems.

Eeh. IMO, let's not drag unfree software into this. It's not the
motivation, and I can't see it helping anyone's cause or mood.

> These would have their own internal system with maximum freedom for 
> experimentation.

Freedom! \o/

> Getting users to install these systems would be the hard part.

That's what gets me. This is Guix, for Stallman's sake. If anyone should
be able to pull it off... :-)

Kind regards,

T out


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

Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Sun, Jul 24, 2016 at 08:28:30AM +0200, Tobias Geerinckx-Rice wrote:
> > if we support a decentralized system of externally-managed 
> > repositories.
> 
> No. Break them.
> 
> If you're running an external Guix repository and don't bother to follow
> the main development branch(es) with some attention, your users deserve
> to get regular breakage warnings as a subtle hint that maybe they
> shouldn't be trusting you with their software.

Exactly. 

I am thinking plugins themselves can be part of the Guix package tree
and come with tests. That way we can keep an eye on 'infrastructure'
code.

Pulling in packages from elsewhere - it is up to the registries to
test things and maintain compatibility.

> There seem to be two different meanings of ‘support’ at play here:
>    - adding decentralised repository support to Guix so it can at least
>      be done in a clean user-friendly way, which I think is excellent
> vs.
>    - promising some kind of API stability to those repositories, which
>      I think is terrible.

Yeah. I am not looking for that. I think it is good to break stuff for
future considerations. That is one advantage FOSS has. The code is out
in the open...

I also agree that we should encourage freedom and exploration.

Pj.
-- 

Re: A registry for distributed sources and binaries

[Leo Famulari]

On Sun, Jul 24, 2016 at 01:29:20AM -0400, Mark H Weaver wrote:
> Long ago, the Linux developers made a conscious decision to not support
> out-of-tree drivers, for much the same reasons.  Many times over the
> years, they have made changes to their internal APIs that required
> corresponding changes to a large number of drivers.  As a result, they
> have been able to keep their internal interfaces clean and free of
> backward-compatibility cruft.

If we did choose to present a stable API, we would need people to
maintain it.

There is so much "grunt work" required already. Upstream URLs are
changed, security bugs are disclosed, core package updates break a big
part of the package tree, etc. Most of this work requires little
knowledge, but lots of time and attention. Not to mention patch
review, which is hard work...

Not enough people are paying attention to this "boring stuff", in my
opinion.

On the other hand, there are many new packages and features, which is
*awesome*! But, if the boring stuff is ignored, the distro will fall
apart, and nobody would want to use this hypothetical API anyways.

By the way, I have a small set of private packages. I haven't needed to
adapt them to changes in GNU Guix so far. Breakage of external repos may
be rare enough that GNU Guix developers could ignore it entirely.

Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Sun, Jul 24, 2016 at 03:29:49AM -0400, Leo Famulari wrote:
> If we did choose to present a stable API, we would need people to
> maintain it.

In my mind we don't need much of an API. We need a way for plugins to
tell what hooks they provide and then call into these hooks. That is
all. Plugins don't get access to Guix internals per se - though we
could run them in the same space.

At least for packages I agree we don't need much support. But maybe I
got it wrong ;)

Pj.

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: A registry for distributed sources and binaries

[Jookia]

On Sun, Jul 24, 2016 at 08:37:34AM +0200, Tobias Geerinckx-Rice wrote:
> Eeh. IMO, let's not drag unfree software into this. It's not the
> motivation, and I can't see it helping anyone's cause or mood.

It's the only example I can think of easily that Guix will not merge in any
case, yet users may still want to use.

> Kind regards,
> 
> T out

Jookia.

Re: Review process

[Alex Kost]

Mathieu Lirzin (2016-07-23 12:51 +0300) wrote:

> Alex Kost <alezost@gmail.com> writes:
>
>> Pjotr Prins (2016-07-23 05:24 +0300) wrote:
>>
>>> Thanks Ludo. As it stands I am no longer submitting packages to ML. I
>>> did my utmost to make the package lean and clean. This package is not
>>> going in.
>>>
>>> But, I suggest you listen. I know at least 4 people here who say they
>>> have trouble submitting to Guix. Good people.
>>
>> 5 including me :-) I always feel big inconveniences sending patches, and
>> I don't like that the development happens on mailing list.  However
>> unlike Pjotr and Jookia I think it's my problem, not the one of the Guix
>> community.
>>
>> I just wrote this because I'm almost sure that some day I will maintain
>> emacs interface separately from Guix again.  I've been regretting all
>> the time that it became a part of Guix.
>
> I am interested to know what do you miss from that the period you were
> maintaining it separately?

Oh, this is easy: if I maintain something myself, I don't ask anyone, I
just commit whatever seems appropriate to me, and that's it.  When I
send patches for emacs UI to the mailing list, it's like I ask
permissions to modify a part of code I wrote.

Also I always have a bad feeling that I load Ludovic (who is the only
person reviewing these patches) with a useless additional work.

Finally, I feel like I clog the mailing list with my patches.  Sometimes
I want to make some small change, but then I think: «Ah, it's not so
big, no one will ever notice it anyway, so I wouldn't bother people with
it.»  (although recently myglc2 noticed several such things :-))

-- 
Alex

Re: A registry for distributed sources and binaries

[Mathieu Lirzin]

Hi,

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

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>> How about the following:
>>
>> 1. Separate from the GNU project, we create a number of registries of
>>    online git repos without opinion (i.e., anything goes, it is up to
>>    the authors). A registry can contain the work of multiple packages
>>    and multiple authors.
>>
>> 2. Each repo in the registry can create package definitions online
>
> The major problem with this proposal is that, to the extent it became
> popular, it would drastically reduce the freedom we have to change Guix
> itself.  We would need to start considering whether our changes might
> break externally maintained packages.  A large proportion of our
> internal procedures and macros would effectively become a public API.
> We would no longer be able to freely make changes to the way packages
> are specified, or make incompatible changes to the procedures and macros
> used in package definitions on the client or build sides.  We would be
> greatly constrained in our ability to make changes to the default phases
> in our build systems.
>
> Our core packages and most of our library packages would also
> effectively be part of this API.  We would no longer be able to freely
> do things like split packages into smaller pieces or multiple outputs.
>
> Long ago, the Linux developers made a conscious decision to not support
> out-of-tree drivers, for much the same reasons.  Many times over the
> years, they have made changes to their internal APIs that required
> corresponding changes to a large number of drivers.  As a result, they
> have been able to keep their internal interfaces clean and free of
> backward-compatibility cruft.
>
> It's crucially important to the future vitality of this project that we
> retain our freedom to evolve the design of Guix, the way packages are
> specified in Guix, as well as the set of core packages.  These freedoms
> will be drastically curtailed if we support a decentralized system of
> externally-managed repositories.  Therefore, we must not do this.
>
> What do other people think?

I fully agree with everything you said.

When acknowledging all the consequences of providing a public API for
package definitions, the main goal of lowering the barrier to entry is
missed because everything becomes more complex.

-- 
Mathieu Lirzin

Re: Review process

[Mathieu Lirzin]

Alex Kost <alezost@gmail.com> writes:

> Mathieu Lirzin (2016-07-23 12:51 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> writes:
>>
>>> Pjotr Prins (2016-07-23 05:24 +0300) wrote:
>>>
>>>> Thanks Ludo. As it stands I am no longer submitting packages to ML. I
>>>> did my utmost to make the package lean and clean. This package is not
>>>> going in.
>>>>
>>>> But, I suggest you listen. I know at least 4 people here who say they
>>>> have trouble submitting to Guix. Good people.
>>>
>>> 5 including me :-) I always feel big inconveniences sending patches, and
>>> I don't like that the development happens on mailing list.  However
>>> unlike Pjotr and Jookia I think it's my problem, not the one of the Guix
>>> community.
>>>
>>> I just wrote this because I'm almost sure that some day I will maintain
>>> emacs interface separately from Guix again.  I've been regretting all
>>> the time that it became a part of Guix.
>>
>> I am interested to know what do you miss from that the period you were
>> maintaining it separately?
>
> Oh, this is easy: if I maintain something myself, I don't ask anyone, I
> just commit whatever seems appropriate to me, and that's it.  When I
> send patches for emacs UI to the mailing list, it's like I ask
> permissions to modify a part of code I wrote.

Sure, I understand this can feel frustrating.

> Also I always have a bad feeling that I load Ludovic (who is the only
> person reviewing these patches) with a useless additional work.

I am confident that Ludovic doesn't think of your patches that way.

> Finally, I feel like I clog the mailing list with my patches.  Sometimes
> I want to make some small change, but then I think: «Ah, it's not so
> big, no one will ever notice it anyway, so I wouldn't bother people with
> it.»  (although recently myglc2 noticed several such things :-))

Maybe you could view your patches for emacs UI has a buffer with an
"LGTM" default that you can push for example 1 week later.  It gives
others a chance to comment on potential controversial changes and gives
you a chance to improve them, without feeling that you are asking
permission.  What do others think?

Even if I am not very active in reviewing/commenting your patches, I
appreciate the fact that Emacs UI is included in Guix source tree
because it feels integrated and is ready to hack for any Guix
contributor.  I hope this will continue.

Thanks for sharing your thoughts.

-- 
Mathieu Lirzin

Re: A registry for distributed sources and binaries

[Andreas Enge]

Hello,

On Sun, Jul 24, 2016 at 05:30:27AM +0200, Pjotr Prins wrote:
> 2. Slightly complicated (you need a Guix source tree etc.)

as far as I understand it, our "data is code" approach makes it necessary
to have the Guix tree around in any case. "guix package -i ruby" looks
up the package variable with name "ruby" in the local Guix tree, which
may be installed in ways different from using git ("guix pull" comes to mind).

On Sun, Jul 24, 2016 at 09:41:49AM +0200, Pjotr Prins wrote:
> In my mind we don't need much of an API. We need a way for plugins to
> tell what hooks they provide and then call into these hooks. That is
> all. Plugins don't get access to Guix internals per se - though we
> could run them in the same space.

So when your registry defines a package that depends on ruby, it somehow
needs to import the scheme variable of the same name, which resides in,
say, the central Guix tree. So it is not a matter of simply adding hooks.
(Of course, I suppose that external scheme files could be "added" to the
local tree as the files in GUIX_PACKAGE_PATH are, but I am not sure whether
this is what you mean).

> After some thought I am coming to the following: my primary goals are
> to lower the barrier to entry
> 1. People are not aware about the work of others
> 3. No binary distribution

One of my main concerns with your suggestion (besides the technical one) is
that I do not think it lowers the barrier to entry, but it diverts the
efforts. With package repositories full of packages around, where a half-
baked recipe can simply be dropped for the world to use, what would be the
incentive of contributing back into the main project?

My impression is that it is extraordinarily easy to contribute to Guix:
Anybody can post packages to the mailing list, and after a bit of back
and forth, they are usually added. No copyright assignment, no need to
become a "Guix maintainer". Making it even easier essentially means dropping
quality control. Then packages of bad quality floating around Guix would
mean bad publicity.

A problem, as mentioned in another reply, is the lack of people doing code
review, which is not a very rewarding task. That can be changed by everyone
of us :-)

And I think we need to work on our tooling and processes; the approach of
submitting patches to this mailing list is not set in stone. Apart from that,
I do not think that the claim of patch loss is justified: This may happen
from time to time, but not on a regular basis.

On Sun, Jul 24, 2016 at 05:30:27AM +0200, Pjotr Prins wrote:
> have people collaborate on each others packages without some
> centralized 'opinion'.
On Sun, Jul 24, 2016 at 03:48:48PM +1000, Jookia wrote:
> We're all a bit frustrated
> with each other at the moment because we have different goals.
> There could be a guix-jookia, guix-nonfree for those
> that really want to run it on their nonfree systems.

Is this the elephant in the room? Besides quality control, which is
necessary to make a distribution with thousands of packages maintainable
by just a few people, our only "restrictive" opinion is supporting only
free software - anything that is free software can go in. But this is
central to the project and a point where no compromises can be made.
Our goal is to support free software and only free software, which is
a promise to our users, supporters and ourselves.

Andreas

Re: Review process

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Mathieu Lirzin (2016-07-23 12:51 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> writes:

[...]

>>> I just wrote this because I'm almost sure that some day I will maintain
>>> emacs interface separately from Guix again.  I've been regretting all
>>> the time that it became a part of Guix.
>>
>> I am interested to know what do you miss from that the period you were
>> maintaining it separately?
>
> Oh, this is easy: if I maintain something myself, I don't ask anyone, I
> just commit whatever seems appropriate to me, and that's it.  When I
> send patches for emacs UI to the mailing list, it's like I ask
> permissions to modify a part of code I wrote.

Let’s make it crystal clear: to me, you have full authority over the
guix.el code.

I’ve stated it several times, but maybe not clearly enough.  Apologies!

IOW, I think it’s fine if you commit directly changes to these parts of
the code.  Of course, I appreciate discussion when making non-trivial
feature changes—discussion not with me specifically, but with users.

It would be a great loss and a technical hindrance if guix.el was moved
out of Guix.  I don’t want that to happen, so let me know what the
ransom should be!  ;-)

Ludo’.

Re: A registry for distributed sources and binaries

[Jookia]

On Sun, Jul 24, 2016 at 03:58:28PM +0200, Andreas Enge wrote:
> One of my main concerns with your suggestion (besides the technical one) is
> that I do not think it lowers the barrier to entry, but it diverts the
> efforts. With package repositories full of packages around, where a half-
> baked recipe can simply be dropped for the world to use, what would be the
> incentive of contributing back into the main project?

It's starting to sound like this is a self-preservation tactic to make Guix a
single project that aims for a target audience with certain quality rather than
an ecosystem with many variants. Is it really a bad thing if that happens? Maybe
for the project, but not for the people or world at large.

> My impression is that it is extraordinarily easy to contribute to Guix:
> Anybody can post packages to the mailing list, and after a bit of back
> and forth, they are usually added. No copyright assignment, no need to
> become a "Guix maintainer". Making it even easier essentially means dropping
> quality control. Then packages of bad quality floating around Guix would
> mean bad publicity.

Okay, I'll bite: Contributing at all to any formal project gives me sickness,
worries and the feeling of panic. IRC with certain people gives me the same
feelings. It's especially worse with projects where it uses Git and mailing
lists. There's so many places things can go wrong, from misconfiguring your mail
client, to accidentally only single replying, to sending updated patches and not
knowing how to explain the differences since you're sending a patch.

Even worse, if I want to reply to an issue on a mailing list that I'm not
subscribed to, it's difficult. I still haven't figured it out, maybe you can go
to the archive and download an mbox and look at the reference and ask your mail
client to reply to it? I don't know.

An issue tracker that you can reply to by the web would be much much better,
because there's less things to go wrong and less ways to be shamed for. I've
suggested this many times and the only responses I've heard are 'no' and 'let me
tell you how easy you can use mailing lists', so I give up.

> Is this the elephant in the room? Besides quality control, which is
> necessary to make a distribution with thousands of packages maintainable
> by just a few people, our only "restrictive" opinion is supporting only
> free software - anything that is free software can go in. But this is
> central to the project and a point where no compromises can be made.
> Our goal is to support free software and only free software, which is
> a promise to our users, supporters and ourselves.

It doesn't have to be nonfree software, it could be offensive/controversial
content (just think about whatever offends you the most then picture it in
software form). The point is that a single Guix isn't going to please everyone,
so it'd be nice to have a way to have branches and communication rather than
branches and walls. Is it too much to ask for this?

To the contray, the elephant in the room (at least in this thread) seems to be
that Guix also can be used to build an OS: GuixSD. Perhaps it'd be a wise idea
to mark GuixSD as 'maintainer-only' until there's enough reviewers to have the
public contribute to it? Then we can go back to arguing about packages.

Look, I really like Guix- that's why I'm so upset and hurt over this. I'm not
trying to troll or provoke arguments, that's just frustration. But when I've
seen people complaining about their system broken with bugs that I've had fixed
*months ago* and tried to upstream to no avail, where am I supposed to go from
here? Short of a fork, there's absolutely nothing I can do to even get people to
TRY changes and use that to iron out bugs. This isn't the first GNU/FSF
project that I've attempted to contribute to after seeing contributions were
needed then have those contributions ignored/forgotten about. There's always
reasons, but it's painful each time.

I think I'm done for now. No amount of writing has even started a discussion on
how to fix things, only that things aren't broken.

> Andreas

Jookia.

Re: A registry for distributed sources and binaries

[Andreas Enge]

Hello again,

On Mon, Jul 25, 2016 at 01:21:50AM +1000, Jookia wrote:
> An issue tracker that you can reply to by the web would be much much better,
> because there's less things to go wrong and less ways to be shamed for. I've
> suggested this many times and the only responses I've heard are 'no' and 'let me
> tell you how easy you can use mailing lists', so I give up.

let us start from here. As said, I think we could/should improve our tooling
and processes. And it would certainly be best if those who are most unhappy
with our current ways could make concrete suggestions, that are also
compatible with the ways in which people work who are happy with the current
situation.

There was a trial with patch/patches/patchwork or whatever it is called
(so the complaints have not been ignored!), but I do not feel like this
has been of much use and help.

> Even worse, if I want to reply to an issue on a mailing list that I'm not
> subscribed to, it's difficult. I still haven't figured it out, maybe you can go
> to the archive and download an mbox and look at the reference and ask your mail
> client to reply to it? I don't know.

This is worse with most web based issue trackers, which require you to sign up
and, in the worst case, agree to terms and conditions. For mailing lists, at
least you can sign up without terms and conditions and easily unsubscribe.

Personally, I think that debbugs could also be used to handle patch
submissions. That would make it easier to track the status of patches.
"Bugs" containing applied patches could be closed as "fixed", others
where the submitter disappears could be closed after a while as "wont-fix".
The guix-devel mailing list could be subscribed to the bug tracker, so that
the complete discussion would appear in the list. Also, "bugs" can be
treated (and in particularly closed when the patch is applied, which should
be the most frequent outcome) easily by e-mail. But as far as I know, debbugs
has no web interface.

So do you know a concrete solution? I think it needs to/should satisfy the
following requirements:
1) It must be free software that we can install on our own servers.
   (And it should represent almost zero maintenance burden, so we can
   concentrate on the work rather than on the tools.)
2) It should have a web interface :-), but also be usable from the command
   line; maybe by mail, preferably with some kind of emacs integration.
3) It should be usable without signing up.
There may be more requirements that I do not think of.

> I think I'm done for now. No amount of writing has even started a discussion on
> how to fix things, only that things aren't broken.

I hope that I am starting a discussion with the above. Still I think that
the main problem is that we do not have enough people willing to do enough
boring work. If we find ways to make contributing to the boring and exciting
tasks easier and more pleasant, then I am all for it.

Andreas

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"

replying to a message of a mailing list you were not subscribed to

[Danny Milosavljevic]

> Even worse, if I want to reply to an issue on a mailing list that I'm not
> subscribed to, it's difficult. I still haven't figured it out, maybe you can go
> to the archive and download an mbox and look at the reference and ask your mail
> client to reply to it? I don't know.

You read the (X-)"Message-Id" header field from the archive (for Guix, it's in a HTML comment - for example in <http://lists.gnu.org/archive/html/guix-devel/2016-07/msg01127.html>). Then you add an "In-Reply-To" header with the same value to your E-Mail (if your E-Mail client doesn't add angle brackets, add them manually - but for example git send-email adds angle brackets automatically).

I'd suggest to make this field a text in the archive instead of a comment. Is that possible?

Re: replying to a message of a mailing list you were not subscribed to

[Danny Milosavljevic]

On Sun, 24 Jul 2016 19:18:39 +0200
Danny Milosavljevic <dannym@scratchpost.org> wrote:

> > Even worse, if I want to reply to an issue on a mailing list that I'm not
> > subscribed to, it's difficult. I still haven't figured it out, maybe you can go
> > to the archive and download an mbox and look at the reference and ask your mail
> > client to reply to it? I don't know.  
> 
> You read the (X-)"Message-Id" header field from the archive (for Guix, it's in a HTML comment - for example in <http://lists.gnu.org/archive/html/guix-devel/2016-07/msg01127.html>). Then you add an "In-Reply-To" header with the same value to your E-Mail (if your E-Mail client doesn't add angle brackets, add them manually - but for example git send-email adds angle brackets automatically).
> 
> I'd suggest to make this field a text in the archive instead of a comment. Is that possible?

Also, it would be user-friendlier to add a "mailto:" link there which has this header in the first place.

This would work via:

mailto:guix-devel@gnu.org?subject=foobar&In-Reply-To=xxxx
.

Note that this would increase spam to the list almost immediately. (If that's a problem, I can suggest to make it harder to automatically read by using Javascript instead of plain HTML in order to make it build this URL only if a human is at the client)

Re: A registry for distributed sources and binaries

[John Darrington]

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

On Mon, Jul 25, 2016 at 01:21:50AM +1000, Jookia wrote:

     Even worse, if I want to reply to an issue on a mailing list that I'm not
     subscribed to, it's difficult. I still haven't figured it out, maybe you can go
     to the archive and download an mbox and look at the reference and ask your mail
     client to reply to it? I don't know.


Normally, if you are not subscribed to a mailing list, then you would 
not be aware of what was being said.  

However, if, somehow you do become aware of that discussion,  and if you
want to participate in that discussion, then the answer is simple: 
Subscribe; then reply.

If you do manage to reply without subscribing, then in my opinion it is
extremely rude.  It is like butting into a conversation that you overhear
at the next table in a restaurant.  If somebody did that to me, I would
probably ignore them.

Just my $0.03

J'

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


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

Re: A registry for distributed sources and binaries

[Ricardo Wurmus]

Jookia <166291@gmail.com> writes:

> I think the clearest system is a way to have multiple guixes installed at once.
> Other package managers need not do this, but as long as the daemon compatiblity
> is kept it should be fine. There could be a guix-jookia, guix-nonfree for those
> that really want to run it on their nonfree systems. These would have their own
> internal system with maximum freedom for experimentation. Getting users to
> install these systems would be the hard part.

Maybe I’m missing something, but this seems to work for me at the MDC.
Before the mercurial downloader was merged, for example, I just added it
to the repository that was referred to in GUIX_PACKAGE_PATH.   It sat
there for a while until I had cleaned it up enough to submit it for
review as a patch.

Users can already do all these things with GUIX_PACKAGE_PATH, in
particular they can

* install non-free stuff
* define packages with procedures that are not in Guix upstream

Anyone can use “guix publish” to *trivially* share binaries on demand
with people who might want them.

This mechanism is *already* supported by Guix.

Although I agree with Mark that Guix should not freeze its API, I don’t
consider this a problem in practice.

For the MDC I have a separate repository with packages and supporting
infrastructure that we have been using since at least March 2015.  We
never had any problems with API stability.  One package’s inputs had to
be changed when a package in Guix upstream was renamed.

For anyone going through the effort to distribute an additional set of
packages and features it really should not be a problem to make these
minor adjustments once in a long while.

~~ Ricardo

Re: A registry for distributed sources and binaries

[Ricardo Wurmus]

Hi Pjotr,

> Registries solve the mentioned problems of GUIX_PACKAGE_PATH:
>
> 1. People are not aware about the work of others
> 2. Slightly complicated (you need a Guix source tree etc.)
> 3. No binary distribution

When I first read your email I thought you proposed a mechanism that
extends GUIX_PACKAGE_PATH.  What you actually proposed seems a little
too big and complicated from my point of view, but I am interested in
discussing the idea of extending GUIX_PACKAGE_PATH.

Currently, GUIX_PACKAGE_PATH depends on some manual work to be done
first.  Finding a third-party repository, downloading it, updating it
separately from Guix itself (it won’t get updated via “guix pull”),
setting the variable.

When binary substitutes are involved some more steps are required: find
and download the public key of the distributor (who might be running
hydra or something like “guix publish”) and authorise it.

Taken together it may seem a little too cumbersome compared to what
other package managers do.  To enable a third-party repository for
Ubuntu, for example, I only need to run one command.  When downloading
packages I may also need to verify and accept a GPG key.

Could it be enough if Guix offered a simpler way to fetch package
definitions and (optionally) binary substitutes from a third party who
maintains both the package definitions and (optionally) distributes
pre-built binary substitutes?

Here are some concrete proposals:

* Add a “guix config” command, which allows users to modify the
  behaviour of their instance of Guix.

* Support adding repositories via “guix config”.  A “repository” is a
  remote set of Guile modules and (optionally) an public endpoint of
  “guix publish” through which substitutes of only those packages that
  are defined in the repository’s modules can be downloaded.

* The first time a repository is accessed, the specified modules are
  cloned and stored in a per-user state directory
  (“~/.cache/guix/<domain>” maybe?).  Guix is automatically configured
  to use the modules from “~/.cache/guix/<domain>” in addition to what
  is on GUIX_PACKAGE_PATH.  Additionally, the distribution public key
  for binary substitutes is fetched from a well-known location (if
  applicable) and users are asked to confirm.

* When a user runs “guix pull” all enabled repositories are also
  updated.  Otherwise the cached copy from last access is used.

* Update “guix --version” to also return the version of each configured
  repository.

* Add a command line switch “--vanilla” (or similar) to disable any
  custom configuration and any configured repositories.

With the mechanism described above it would be less intimidating for
users to add sources of Guix packages (or Guix features) and download
binary substitutes.

Third parties can distribute package descriptions (or experimental
features) along with binary substitutes by simply hosting the modules
and running “guix publish”.  The Guix project doesn’t need to care.
Exactly how third-party collections are managed is completely up to the
respective maintainers.

While I feel strongly that we should focus our efforts on Guix upstream
I also think that it may be useful and convenient to expand the
GUIX_PACKAGE_PATH feature.

What do you think about that?  Does this align with your vision?

What do others think?  Is this something that would benefit the Guix
project and its audience?

~~ Ricardo

Re: A registry for distributed sources and binaries

[Ludovic Courtès]

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

Hi,

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

> It's crucially important to the future vitality of this project that we
> retain our freedom to evolve the design of Guix, the way packages are
> specified in Guix, as well as the set of core packages.  These freedoms
> will be drastically curtailed if we support a decentralized system of
> externally-managed repositories.  Therefore, we must not do this.

We never made any API stability guarantee and we won’t make any such
guarantee in the foreseeable future, for the reasons you give.

Nevertheless, external package repos have worked reasonably well in
practice so far, because things don’t change that much.  And it’s great
that people can maintain their own package sets like this.

A large external package tree may run into problems more easily though,
because it would necessarily depend on a larger subset of “our” packages
and features.

Someone starting such a project should be aware of these risks.  Guix
APIs may change anytime, because we want to be able to reorganize
packages, to improve Guix’s design, and so on.  Maintaining stable APIs
is not a goal, at least not at this stage.

Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Sun, Jul 24, 2016 at 10:35:43PM +0200, Ricardo Wurmus wrote:
> Could it be enough if Guix offered a simpler way to fetch package
> definitions and (optionally) binary substitutes from a third party who
> maintains both the package definitions and (optionally) distributes
> pre-built binary substitutes?

Thanks Ricardo, that is exactly what I am proposing.

> Here are some concrete proposals:
> 
> * Add a “guix config” command, which allows users to modify the
>   behaviour of their instance of Guix.
> 
> * Support adding repositories via “guix config”.  A “repository” is a
>   remote set of Guile modules and (optionally) an public endpoint of
>   “guix publish” through which substitutes of only those packages that
>   are defined in the repository’s modules can be downloaded.
> 
> * The first time a repository is accessed, the specified modules are
>   cloned and stored in a per-user state directory
>   (“~/.cache/guix/<domain>” maybe?).  Guix is automatically configured
>   to use the modules from “~/.cache/guix/<domain>” in addition to what
>   is on GUIX_PACKAGE_PATH.  Additionally, the distribution public key
>   for binary substitutes is fetched from a well-known location (if
>   applicable) and users are asked to confirm.
> 
> * When a user runs “guix pull” all enabled repositories are also
>   updated.  Otherwise the cached copy from last access is used.
> 
> * Update “guix --version” to also return the version of each configured
>   repository.
> 
> * Add a command line switch “--vanilla” (or similar) to disable any
>   custom configuration and any configured repositories.
> 
> With the mechanism described above it would be less intimidating for
> users to add sources of Guix packages (or Guix features) and download
> binary substitutes.

Yes.

> Third parties can distribute package descriptions (or experimental
> features) along with binary substitutes by simply hosting the modules
> and running “guix publish”.  The Guix project doesn’t need to care.
> Exactly how third-party collections are managed is completely up to the
> respective maintainers.
> 
> While I feel strongly that we should focus our efforts on Guix upstream
> I also think that it may be useful and convenient to expand the
> GUIX_PACKAGE_PATH feature.
> 
> What do you think about that?  Does this align with your vision?

That is it.

> What do others think?  Is this something that would benefit the Guix
> project and its audience?

I think it would make Guix cooler than anything out there. We already
do distributed binary distribution (awesome!), now we could do
federated source distribution. Key thing is that we make people
*autonomous* and encourage *diversity*.

Andreas: this is not about non-free software.  We *are* using
GUIX_PACKAGE_PATH for deployment. We have 140+ free bioinformatics
packages sitting in a tree. I am totally happy using that. We have
trouble getting to install our software. I don't have the stamina
getting these packages into core (an estimated another 40 days of work
and back-and-forths? It does not scale).

Ricardo: the one thing I would like to add is package discovery. In a
federated environment we want to avoid duplication of work and say I
had an Elixir package in my tree, it could be a good starting point
for someone wanting to bring it into core.

Support for multiple GUIX_PACKAGE_PATH's would be first priority.
Binary support second and discovery third. 

Thanks again for your constructive suggestion,

Pj.
-- 

Re: A registry for distributed sources and binaries

[Tobias Geerinckx-Rice]

Pjotr,

On 2016-07-25 04:10, Pjotr Prins wrote:
> Support for multiple GUIX_PACKAGE_PATH's would be first priority.

I'm taking it you're not talking about colon-separation (which
is already supported, though I haven't tried it) but something
more?

I'm interested :-)

Kind regards,

T G-R

-- 
Sent from a web browser. Excuse my brevity.

Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Mon, Jul 25, 2016 at 05:42:20AM +0200, Tobias Geerinckx-Rice wrote:
> Pjotr,
> 
> On 2016-07-25 04:10, Pjotr Prins wrote:
> >Support for multiple GUIX_PACKAGE_PATH's would be first priority.
> 
> I'm taking it you're not talking about colon-separation (which
> is already supported, though I haven't tried it) but something
> more?
> 
> I'm interested :-)

I should have written 'Support for multiple remote (or federated)
GUIX_PACKAGE_PATHs'

I know it is easy to raise feature requests. I/we are actually
interested in helping to add this functionality. I scratches multiple
itches on my end.

Pj.

Re: replying to a message of a mailing list you were not subscribed to

[Ricardo Wurmus]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Sun, 24 Jul 2016 19:18:39 +0200
> Danny Milosavljevic <dannym@scratchpost.org> wrote:
>
>> > Even worse, if I want to reply to an issue on a mailing list that I'm not
>> > subscribed to, it's difficult. I still haven't figured it out, maybe you can go
>> > to the archive and download an mbox and look at the reference and ask your mail
>> > client to reply to it? I don't know.  
>> 
>> You read the (X-)"Message-Id" header field from the archive (for Guix, it's in a HTML comment - for example in <http://lists.gnu.org/archive/html/guix-devel/2016-07/msg01127.html>). Then you add an "In-Reply-To" header with the same value to your E-Mail (if your E-Mail client doesn't add angle brackets, add them manually - but for example git send-email adds angle brackets automatically).
>> 
>> I'd suggest to make this field a text in the archive instead of a comment. Is that possible?
>
> Also, it would be user-friendlier to add a "mailto:" link there which has this header in the first place.
>
> This would work via:
>
> mailto:guix-devel@gnu.org?subject=foobar&In-Reply-To=xxxx
> .

Unless I misunderstood what you mean: this already exists.  On the page
you linked to above look for “reply via email to”.  It’s followed by a
button.  When you click on it you get a “mailto”-Link.

~~ Ricardo

[PATCH] Add Elixir (was: )

[Ricardo Wurmus]

Hi Pjotr

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

back to the original patch, which I didn’t look at as the ensuing
discussion on review process and registry proposals took up more time
than I anticipated.

I’m a little uncertain on how to proceed.  I have a couple of things
here that I’d like to change before commiting.  I’ll add some comments
below.  Indentation changes won’t be mentioned ;)

If you are okay with the proposed changes I can apply them on top of
your patch and resubmit the squashed patch to the ML for a final
look-over.  Deal?

> +   (native-inputs
> +    `(("patch" ,patch)
> +      ("patch/elixir-disable-failing-tests"
> +       ,(search-patch "elixir-disable-failing-tests.patch"))
> +      ("patch/elixir-disable-mix-tests"
> +       ,(search-patch "elixir-disable-mix-tests.patch"))))

This has been mentioned already and I’d like to move these to the
“source” field after identifying the reason why the build fails
otherwise.  I see that you’re doing this in order to patch after the
build phase.  Let’s see if this can be avoided.

> +      (add-after 'build 'disable-breaking-elixir-tests
> +        ;; when patching tests as part of source the build breaks, so we do
> +        ;; it after the build phase
> +        (lambda* (#:key inputs #:allow-other-keys)
> +          (and
> +           (zero? (system* "patch" "--force" "-p1" "-i"
> +                           (assoc-ref inputs "patch/elixir-disable-failing-tests")))
> +           (zero? (system* "patch" "--force" "-p1" "-i"
> +                           (assoc-ref inputs "patch/elixir-disable-mix-tests")))
> +           ;; Tests currently fail in these two files:
> +           (delete-file "./lib/mix/test/mix/tasks/deps.git_test.exs")
> +           (delete-file "./lib/mix/test/mix/shell_test.exs"))))

“delete-file” has an unspecified return value, so chaining it up in
“and” isn’t guaranteed to work.  Should this patch-after-build business
turn out to be unavoidable I suggest just deleting the files first, then
and-ing the “zero?” expressions.

> +      (replace 'check
> +               (lambda _
> +                 (zero? (system* "make" "test"))))) ;; 3124 tests, 0 failures, 11 skipped

We can use “#:test-target "test"” instead of replacing the “check” phase.

> +      #:make-flags (list (string-append "PREFIX=" %output))))
> +   (home-page "http://elixir-lang.org/")
> +   (synopsis "The Elixir programming language")

s/The//

> +   (description "Elixir is a dynamic, functional language used to
> +build scalable and maintainable applications.  Elixir leverages the
> +Erlang VM, known for running low-latency, distributed and
> +fault-tolerant systems, while also being successfully used in web
> +development and the embedded software domain.")
> +   (license license:asl2.0)))

Looks good!

> diff --git a/gnu/packages/patches/elixir-disable-failing-tests.patch b/gnu/packages/patches/elixir-disable-failing-tests.patch
> new file mode 100644
> index 0000000..802cb1e
> --- /dev/null
> +++ b/gnu/packages/patches/elixir-disable-failing-tests.patch

While I’m generally okay with disabling failing tests (see the
embarassing situation we have with the “icedtea” packages), I think
these can be fixed with little effort.  Many of them seem to be related
to the location of the temp directory.

> +diff --git a/lib/elixir/test/elixir/node_test.exs b/lib/elixir/test/elixir/node_test.exs
> +index d1f1fe6..5c2d469 100644
> +--- a/lib/elixir/test/elixir/node_test.exs
> ++++ b/lib/elixir/test/elixir/node_test.exs
> +@@ -6,8 +6,10 @@ defmodule NodeTest do
> +   doctest Node
> + 
> +   test "start/3 and stop/0" do
> +-    assert Node.stop == {:error, :not_found}
> +-    assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
> +-    assert Node.stop() == :ok
> ++    IO.puts "Skipping test because GNU Guix does not allow the HOME environment variable."
> ++
> ++    # assert Node.stop == {:error, :not_found}
> ++    # assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
> ++    # assert Node.stop() == :ok
> +   end
> + end

This was already addressed earlier.  We can probably just setenv HOME
before the tests.

Some of the remaining tests don’t seem to have any obvious fixes, so
I’ll get to them after making the above changes first.  Maybe the
failures disappear then.

Thanks again for the patch.  I hope you are willing to provide some
guidance when I have some problems understanding certain bits of the
build.

~~ Ricardo


PS: Elixir is big and getting it accepted in Guix upstream is a
precondition for more Elixir packages.  This is why I think it’s worth
picking this up.  For other patches this amount of effort may not be
justified (as I cannot get other stuff done at the same time).  I do
hope that we can find a way to upstream the 140+ bioinfo packages you
have locally, even it it’s at a trickle rate :)

Re: [PATCH] Add Elixir (was: )

[Pjotr Prins]

On Mon, Jul 25, 2016 at 08:13:33AM +0200, Ricardo Wurmus wrote:
> back to the original patch, which I didn’t look at as the ensuing
> discussion on review process and registry proposals took up more time
> than I anticipated.

:)

> I’m a little uncertain on how to proceed.  I have a couple of things
> here that I’d like to change before commiting.  I’ll add some comments
> below.  Indentation changes won’t be mentioned ;)
> 
> If you are okay with the proposed changes I can apply them on top of
> your patch and resubmit the squashed patch to the ML for a final
> look-over.  Deal?

Sure. I have no ego in this. I am happy if you take over.

> > +   (native-inputs
> > +    `(("patch" ,patch)
> > +      ("patch/elixir-disable-failing-tests"
> > +       ,(search-patch "elixir-disable-failing-tests.patch"))
> > +      ("patch/elixir-disable-mix-tests"
> > +       ,(search-patch "elixir-disable-mix-tests.patch"))))
> 
> This has been mentioned already and I’d like to move these to the
> “source” field after identifying the reason why the build fails
> otherwise.  I see that you’re doing this in order to patch after the
> build phase.  Let’s see if this can be avoided.

I tried and failed. Elixir people do not know either:

  https://github.com/elixir-lang/elixir/issues/5043

I think it is Mix magic. Probably tracking files in some way.

> > +      (add-after 'build 'disable-breaking-elixir-tests
> > +        ;; when patching tests as part of source the build breaks, so we do
> > +        ;; it after the build phase
> > +        (lambda* (#:key inputs #:allow-other-keys)
> > +          (and
> > +           (zero? (system* "patch" "--force" "-p1" "-i"
> > +                           (assoc-ref inputs "patch/elixir-disable-failing-tests")))
> > +           (zero? (system* "patch" "--force" "-p1" "-i"
> > +                           (assoc-ref inputs "patch/elixir-disable-mix-tests")))
> > +           ;; Tests currently fail in these two files:
> > +           (delete-file "./lib/mix/test/mix/tasks/deps.git_test.exs")
> > +           (delete-file "./lib/mix/test/mix/shell_test.exs"))))
> 
> “delete-file” has an unspecified return value, so chaining it up in
> “and” isn’t guaranteed to work.  Should this patch-after-build business
> turn out to be unavoidable I suggest just deleting the files first, then
> and-ing the “zero?” expressions.

Cool.

> > +      (replace 'check
> > +               (lambda _
> > +                 (zero? (system* "make" "test"))))) ;; 3124 tests, 0 failures, 11 skipped
> 
> We can use “#:test-target "test"” instead of replacing the “check” phase.

Yes, I forgot.

> > +      #:make-flags (list (string-append "PREFIX=" %output))))
> > +   (home-page "http://elixir-lang.org/")
> > +   (synopsis "The Elixir programming language")
> 
> s/The//
> 
> > +   (description "Elixir is a dynamic, functional language used to
> > +build scalable and maintainable applications.  Elixir leverages the
> > +Erlang VM, known for running low-latency, distributed and
> > +fault-tolerant systems, while also being successfully used in web
> > +development and the embedded software domain.")
> > +   (license license:asl2.0)))
> 
> Looks good!
> 
> > diff --git a/gnu/packages/patches/elixir-disable-failing-tests.patch b/gnu/packages/patches/elixir-disable-failing-tests.patch
> > new file mode 100644
> > index 0000000..802cb1e
> > --- /dev/null
> > +++ b/gnu/packages/patches/elixir-disable-failing-tests.patch
> 
> While I’m generally okay with disabling failing tests (see the
> embarassing situation we have with the “icedtea” packages), I think
> these can be fixed with little effort.  Many of them seem to be related
> to the location of the temp directory.

Note we are talking a rather small minority of tests. 11 out of 2000+
for Elixir. For Mix 10% fails, mostly because of git. The Elixir
people wrote there should be no network access involved.

> > +diff --git a/lib/elixir/test/elixir/node_test.exs b/lib/elixir/test/elixir/node_test.exs
> > +index d1f1fe6..5c2d469 100644
> > +--- a/lib/elixir/test/elixir/node_test.exs
> > ++++ b/lib/elixir/test/elixir/node_test.exs
> > +@@ -6,8 +6,10 @@ defmodule NodeTest do
> > +   doctest Node
> > + 
> > +   test "start/3 and stop/0" do
> > +-    assert Node.stop == {:error, :not_found}
> > +-    assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
> > +-    assert Node.stop() == :ok
> > ++    IO.puts "Skipping test because GNU Guix does not allow the HOME environment variable."
> > ++
> > ++    # assert Node.stop == {:error, :not_found}
> > ++    # assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
> > ++    # assert Node.stop() == :ok
> > +   end
> > + end
> 
> This was already addressed earlier.  We can probably just setenv HOME
> before the tests.
> 
> Some of the remaining tests don’t seem to have any obvious fixes, so
> I’ll get to them after making the above changes first.  Maybe the
> failures disappear then.
> 
> Thanks again for the patch.  I hope you are willing to provide some
> guidance when I have some problems understanding certain bits of the
> build.

I am happy to help out if you take the lead.

> PS: Elixir is big and getting it accepted in Guix upstream is a
> precondition for more Elixir packages.  This is why I think it’s worth
> picking this up.  

Yes, very visible language and rapidly growing community.

Pj.

-- 

Re: A registry for distributed sources and binaries

[Tomáš Čech]

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

On Sun, Jul 24, 2016 at 10:35:43PM +0200, Ricardo Wurmus wrote:
>What do you think about that?  Does this align with your vision?
>
>What do others think?  Is this something that would benefit the Guix
>project and its audience?

I like the idea a lot.

I'm only concerned with security of such thing. When the number of
other package sources will grow, it should be ensured that some
package definition will not touch core/library without user
consent. If they will take packages from random sources (as they are
careful when downloading applications for windows from various sources
or reading licenses), it may easily become security threat to whole
system.

I'd be glad if we can stop using GUIX_PACKAGE_PATH environment
variable (which is a bit clumsy) and have support for multiple source,
with priorities (for cases of collisions) and maybe in future support
for some digital signatures.

\o/

S_W

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

icecat "mailto" handler does not work - and cannot be reconfigured by user

[Danny Milosavljevic]

> Unless I misunderstood what you mean: this already exists.  On the page
> you linked to above look for “reply via email to”.  It’s followed by a
> button.  When you click on it you get a “mailto”-Link.

Whoops. I should have read the page better.

However, clicking on that button in icecat does not send E-Mail for me. 

Monitoring the network interface I can see that it redirects to a mailto: URL. So that's nice.

Checking the application preferences of icecat, it only gives "always ask" (note: it doesn't ask) and not an application for "mailto". (in GuixSD)

Creating my own HTML page with a mailto link doesn't work either.

Therefore, I reported a bug to Guix too.

Bug report follows:

"mailto:" links don't work in icecat.

Checking the icecat source code, there are several ways to handle E-Mail. One of them is as "external helper app". One of those (not sure whether it's the correct one) uses gio's g_app_info_launch_default_for_uri in order to launch helper applications.

There is a test icecat-38.8.0/uriloader/exthandler/tests/unit/test_handlerService.js that does:

  let isLinux = ("@mozilla.org/gio-service;1" in Components.classes);
  if (isLinux) {
    // Check mailto handler from GIO
    // If there isn't one, then we have no mailto handler
    let gIOSvc = Cc["@mozilla.org/gio-service;1"].
                 createInstance(Ci.nsIGIOService);
    try {
      gIOSvc.getAppForURIScheme("mailto");
      noMailto = false;
    } catch (ex) {
      noMailto = true;
    }
  }

And this ./toolkit/system/gnome/nsGIOService.cpp uses g_app_info_launch_default_for_uri .

Therefore, I tried it out:

#include <glib.h>
#include <gio/gio.h>
#include <stdlib.h>

int main() {
        GError* error;
        g_app_info_launch_default_for_uri("mailto:foo@example.com", NULL, &error);
        // g_app_info_launch_default_for_uri("http://www.google.at/", NULL, &error);
        if (error) {
                g_warning("err %s", error->message);
                g_error_free(error);
                return 1;
        } else
                return 0;
}

I get:

** (process:12464): WARNING **: err Operation not supported

If I debug it some more I get:

$ strace -f ./g 2>&1 |grep open |grep -v ENOENT

open("/home/dannym/.local/share//mime/mime.cache", O_RDONLY) = 3
open("/home/dannym/.guix-profile/share/mime/mime.cache", O_RDONLY) = 3
open("/run/current-system/profile/share/mime/mime.cache", O_RDONLY) = 3
open("/home/dannym/.guix-profile/share/mime/mime.cache", O_RDONLY) = 3
open("/run/current-system/profile/share/mime/mime.cache", O_RDONLY) = 3
open("/home/dannym/.guix-profile/lib/gio/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/dannym/.guix-profile/lib/gio/modules/giomodule.cache", O_RDONLY) = 4
open("/home/dannym/.guix-profile/lib/gio/modules/libdconfsettings.so", O_RDONLY|O_CLOEXEC) = 4
open("/run/current-system/profile/lib/gio/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/run/current-system/profile/lib/gio/modules/giomodule.cache", O_RDONLY) = 4
open("/gnu/store/6qrijb6cfyvs8svacr0l9a75vcpypr5f-glib-2.48.0/lib/gio/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/gnu/store/4lbgxvsk8xl75hlkjqgrqvmpq74app73-dconf-0.26.0/lib/gio/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/gnu/store/4lbgxvsk8xl75hlkjqgrqvmpq74app73-dconf-0.26.0/lib/gio/modules/giomodule.cache", O_RDONLY) = 4
open("/home/dannym/.guix-profile/lib/gio/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/dannym/.guix-profile/lib/gio/modules/giomodule.cache", O_RDONLY) = 4
open("/run/current-system/profile/lib/gio/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/run/current-system/profile/lib/gio/modules/giomodule.cache", O_RDONLY) = 4
open("/gnu/store/m3py3rk71ihlfgvj2kss7054hwfqwkpq-glib-2.48.0/lib/gio/modules", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid 12632] open("/usr/share/locale/locale.alias", O_RDONLY <unfinished ...>
[pid 12632] open("/home/dannym/.config/mimeapps.list", O_RDONLY) = 5
[pid 12632] open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = 5
[pid 12632] open("/home/dannym/.local/share/applications", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] open("/home/dannym/.local/share/applications/mimeapps.list", O_RDONLY) = 5
[pid 12632] open("/home/dannym/.local/share/applications/mimeinfo.cache", O_RDONLY) = 5
[pid 12632] open("/home/dannym/.guix-profile/share/applications", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] open("/run/current-system/profile/share/applications", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] open("/run/current-system/profile/share/applications/mimeinfo.cache", O_RDONLY) = 5
[pid 12632] open("/home/dannym/.guix-profile/share/applications", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] open("/run/current-system/profile/share/applications", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] open("/run/current-system/profile/share/applications/mimeinfo.cache", O_RDONLY) = 5

There would be g_app_info_set_as_default_for_type () to set a new default application in nsGIOService - which is exposed and used by ./browser/components/shell/nsGNOMEShellService.cpp on setting icecat up as default browser (so not always).

I'm using Fluxbox.

Re: A registry for distributed sources and binaries

[Andy Wingo]

On Sun 24 Jul 2016 15:58, Andreas Enge <andreas@enge.fr> writes:

> A problem, as mentioned in another reply, is the lack of people doing code
> review, which is not a very rewarding task. That can be changed by everyone
> of us :-)

Could we just focus on this problem perhaps?

One of the issues is that there's no clear reviewer -- anyone just
pitches in.  We could try to have a culture of asking for particular
reviewers, perhaps via the IRC channel.  If you build up a relationship
with a particular reviewer then they can be your default reviewer, more
or less.  You put them in the Cc of your mails to the list.  This
approach has worked well in some other projects I have been involved in.

Another is to get Guix to suggest a reviewer.  For example if you modify
a package, Guix could look at the git history of that file in those
lines and see who changed it recently, and suggest a person to Cc.

I think Pjotr's example of Elixir was perhaps a bad one.  Languages are
tricky because they are not leaf nodes in the tree.   It's natural for a
Guix maintainer to have an opinion on how a language should be
integrated into Guix, even if they are not an expert.

A fully distributed system sounds nice but it has costs too.  In my mind
for a project of Guix's target size the best situation would be having
around 100 committers or so who have internalized the coding style and
patterns of Guix so that they can work more or less directly on the
parts they feel comfortable with, posting patches to the list as
necessary for feedback.  An incoming patch would be assigned to one of
those people based on automatic tooling.  In that way Guix can scale to
the next step while remaining a consistent, hackable project.

Andy

Replying to bug reports

[Ludovic Courtès]

Hi,

Jookia <166291@gmail.com> skribis:

> Even worse, if I want to reply to an issue on a mailing list that I'm not
> subscribed to, it's difficult.

To reply to a bug report listed at <http://bugs.gnu.org/guix>, email
N@debbugs.gnu.org, where N is the bug number.

For mailing lists in general, another option is to use Gmane’s NNTP
interface:

  http://dir.gmane.org/gmane.comp.gnu.guix.devel

HTH,
Ludo’.

Re: A registry for distributed sources and binaries

[Ludovic Courtès]

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Currently, GUIX_PACKAGE_PATH depends on some manual work to be done
> first.  Finding a third-party repository, downloading it, updating it
> separately from Guix itself (it won’t get updated via “guix pull”),
> setting the variable.
>
> When binary substitutes are involved some more steps are required: find
> and download the public key of the distributor (who might be running
> hydra or something like “guix publish”) and authorise it.
>
> Taken together it may seem a little too cumbersome compared to what
> other package managers do.  To enable a third-party repository for
> Ubuntu, for example, I only need to run one command.  When downloading
> packages I may also need to verify and accept a GPG key.

That’s a two-step process (or one-step if there are no binaries).

Honestly, I don’t find it intimidating (definitely not a showstopper),
but I agree it’s even better if it can be simplified.

> Could it be enough if Guix offered a simpler way to fetch package
> definitions and (optionally) binary substitutes from a third party who
> maintains both the package definitions and (optionally) distributes
> pre-built binary substitutes?
>
> Here are some concrete proposals:
>
> * Add a “guix config” command, which allows users to modify the
>   behaviour of their instance of Guix.
>
> * Support adding repositories via “guix config”.  A “repository” is a
>   remote set of Guile modules and (optionally) an public endpoint of
>   “guix publish” through which substitutes of only those packages that
>   are defined in the repository’s modules can be downloaded.
>
> * The first time a repository is accessed, the specified modules are
>   cloned and stored in a per-user state directory
>   (“~/.cache/guix/<domain>” maybe?).  Guix is automatically configured
>   to use the modules from “~/.cache/guix/<domain>” in addition to what
>   is on GUIX_PACKAGE_PATH.  Additionally, the distribution public key
>   for binary substitutes is fetched from a well-known location (if
>   applicable) and users are asked to confirm.
>
> * When a user runs “guix pull” all enabled repositories are also
>   updated.  Otherwise the cached copy from last access is used.
>
> * Update “guix --version” to also return the version of each configured
>   repository.
>
> * Add a command line switch “--vanilla” (or similar) to disable any
>   custom configuration and any configured repositories.

I like the idea!  (With the caveat that, again, external repos can break
anytime.)

Partly related to that:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22629>.

Ludo’.

Reviewer assignment

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@igalia.com> skribis:

> A fully distributed system sounds nice but it has costs too.  In my mind
> for a project of Guix's target size the best situation would be having
> around 100 committers or so who have internalized the coding style and
> patterns of Guix so that they can work more or less directly on the
> parts they feel comfortable with, posting patches to the list as
> necessary for feedback.

Agreed.  That’s the spirit of the text in ‘HACKING’.

> An incoming patch would be assigned to one of those people based on
> automatic tooling.  In that way Guix can scale to the next step while
> remaining a consistent, hackable project.

That sounds like a good approach to me.

With the upcoming libgit2 bindings, we could cook up a tool that gives
people a list of likely reviewers that submitters could Cc, and suggest
it in
<https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html>.

Thanks,
Ludo’.

Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Mon, Jul 25, 2016 at 11:21:43AM +0200, Ludovic Courtès wrote:
> I like the idea!  (With the caveat that, again, external repos can break
> anytime.)
>
> Partly related to that:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22629>.

Actually very much related because a git pull attached to a git tree
can be tied with a remote repo - allowing for elegant API transitions.

guix channel add genenetwork git://git.sv.gnu.org/guix.git master HASHTAG
guix channel pull genenetwork
guix channel set genenetwork

Do the Ricardo stuff...

Pretty much solves the API problem.

Pj.

Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Tue, Jul 26, 2016 at 05:40:49AM +0200, Pjotr Prins wrote:
> On Mon, Jul 25, 2016 at 11:21:43AM +0200, Ludovic Courtès wrote:
> > I like the idea!  (With the caveat that, again, external repos can break
> > anytime.)
> >
> > Partly related to that:
> > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22629>.

And I think we can use a much smaller git package for this. No need to
include the kitchen sink!

Re: [PATCH] Add Elixir (was: )

[Ricardo Wurmus]

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

> On Mon, Jul 25, 2016 at 08:13:33AM +0200, Ricardo Wurmus wrote:
>> Thanks again for the patch.  I hope you are willing to provide some
>> guidance when I have some problems understanding certain bits of the
>> build.
>
> I am happy to help out if you take the lead.

Thank you.  I applied the patch to my copy of master, but Elxir fails to
compile reliably.  Most of the times it fails with this error:

   == Compilation error on file lib/system.ex ==
   ** (exit) :epipe
   Makefile:77: recipe for target 'lib/elixir/ebin/Elixir.Kernel.beam' failed
   make: *** [lib/elixir/ebin/Elixir.Kernel.beam] Error 1

This is without any changes to your patch.  I wonder if this indicates a
lack of resources on my laptop.

Occasionally it does work and gets past the compilation of
“Elixir.Kernel.beam”.  Did you encounter this error before?

Before I can make some changes on top of your patch I need Elixir to
build (as a baseline).

~~ Ricardo

Re: [PATCH] Add Elixir (was: )

[Vincent Legoll]

On Thu, Jul 28, 2016 at 9:27 AM, Ricardo Wurmus <rekado@elephly.net> wrote:
> I wonder if this indicates a lack of resources on my laptop.
>
> Occasionally it does work and gets past the compilation of
> “Elixir.Kernel.beam”.  Did you encounter this error before?

Maybe it got OOM-killed

-- 
Vincent Legoll

Re: [PATCH] Add Elixir (was: )

[Pjotr Prins]

On Thu, Jul 28, 2016 at 09:27:22AM +0200, Ricardo Wurmus wrote:
> 
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > On Mon, Jul 25, 2016 at 08:13:33AM +0200, Ricardo Wurmus wrote:
> >> Thanks again for the patch.  I hope you are willing to provide some
> >> guidance when I have some problems understanding certain bits of the
> >> build.
> >
> > I am happy to help out if you take the lead.
> 
> Thank you.  I applied the patch to my copy of master, but Elxir fails to
> compile reliably.  Most of the times it fails with this error:
> 
>    == Compilation error on file lib/system.ex ==
>    ** (exit) :epipe
>    Makefile:77: recipe for target 'lib/elixir/ebin/Elixir.Kernel.beam' failed
>    make: *** [lib/elixir/ebin/Elixir.Kernel.beam] Error 1
> 
> This is without any changes to your patch.  I wonder if this indicates a
> lack of resources on my laptop.
> 
> Occasionally it does work and gets past the compilation of
> “Elixir.Kernel.beam”.  Did you encounter this error before?

I may have seen it.

> Before I can make some changes on top of your patch I need Elixir to
> build (as a baseline).

I'll take a look over the weekend. Flying home right now.

Pj.

Re: [PATCH] Add Elixir (was: )

[Ricardo Wurmus]

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

> On Thu, Jul 28, 2016 at 09:27:22AM +0200, Ricardo Wurmus wrote:
>> 
>> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>> 
>> > On Mon, Jul 25, 2016 at 08:13:33AM +0200, Ricardo Wurmus wrote:
>> >> Thanks again for the patch.  I hope you are willing to provide some
>> >> guidance when I have some problems understanding certain bits of the
>> >> build.
>> >
>> > I am happy to help out if you take the lead.
>> 
>> Thank you.  I applied the patch to my copy of master, but Elxir fails to
>> compile reliably.  Most of the times it fails with this error:
>> 
>>    == Compilation error on file lib/system.ex ==
>>    ** (exit) :epipe
>>    Makefile:77: recipe for target 'lib/elixir/ebin/Elixir.Kernel.beam' failed
>>    make: *** [lib/elixir/ebin/Elixir.Kernel.beam] Error 1
>> 
>> This is without any changes to your patch.  I wonder if this indicates a
>> lack of resources on my laptop.
>> 
>> Occasionally it does work and gets past the compilation of
>> “Elixir.Kernel.beam”.  Did you encounter this error before?
>
> I may have seen it.

Never mind.  It was as Vincent thought.  Closing all applications except
for Emacs makes it work.

>> Before I can make some changes on top of your patch I need Elixir to
>> build (as a baseline).
>
> I'll take a look over the weekend. Flying home right now.

Have a good trip!

~~ Ricardo

Re: [PATCH] Add Elixir (was: )

[Pjotr Prins]

On Thu, Jul 28, 2016 at 10:35:29PM +0200, Ricardo Wurmus wrote:
> Never mind.  It was as Vincent thought.  Closing all applications except
> for Emacs makes it work.

Be interesting to see what increasing swap space does. I think we
ought to file it as an issue if that does not help:

  http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

Pj.

Re: [PATCH] Add Elixir (was: )

[Vincent Legoll]

On Fri, Jul 29, 2016 at 3:38 AM, Pjotr Prins <pjotr.public12@thebird.nl> wrote:
> On Thu, Jul 28, 2016 at 10:35:29PM +0200, Ricardo Wurmus wrote:
>> Never mind.  It was as Vincent thought.  Closing all applications except
>> for Emacs makes it work.
>
> Be interesting to see what increasing swap space does. I think we
> ought to file it as an issue if that does not help:

I was recently bit by the same problem, I put swap space and it was ok,
but slower...

I only have 3GB RAM for 3 cores in the VM, so it's a bit tight when
making -j3...

-- 
Vincent Legoll

Re: [PATCH] Add Elixir

[Ricardo Wurmus]

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


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

> On Mon, Jul 25, 2016 at 08:13:33AM +0200, Ricardo Wurmus wrote:
>> > +   (native-inputs
>> > +    `(("patch" ,patch)
>> > +      ("patch/elixir-disable-failing-tests"
>> > +       ,(search-patch "elixir-disable-failing-tests.patch"))
>> > +      ("patch/elixir-disable-mix-tests"
>> > +       ,(search-patch "elixir-disable-mix-tests.patch"))))
>> 
>> This has been mentioned already and I’d like to move these to the
>> “source” field after identifying the reason why the build fails
>> otherwise.  I see that you’re doing this in order to patch after the
>> build phase.  Let’s see if this can be avoided.
>
> I tried and failed. Elixir people do not know either:
>
>   https://github.com/elixir-lang/elixir/issues/5043
>
> I think it is Mix magic. Probably tracking files in some way.

The reason seems to be that Elixir doesn’t compile files when the
timestamp is the epoch.  There is a staleness check before compilation.
When you patch files in a build phase their timestamps are changed, and
that leads to successful compilation.

To fix this when patching in the “source” expression I added a phase to
change the timestamps of all files to something more recent, recent
enough to also pass the staleness tests that check against a date of Jan
1, 2000.

>> Note we are talking a rather small minority of tests. 11 out of 2000+
>> for Elixir. For Mix 10% fails, mostly because of git. The Elixir
>> people wrote there should be no network access involved.

This one is weird and I haven’t been able to track it down.  During the
testing phase the “git_repo” fixture seems to be missing.  This causes
all the git tests to fail.  I don’t know at what point it is generated
and at what point it disappears, but I documented that this appears to
be the problem, so that it can be fixed at a later point.

>> > +diff --git a/lib/elixir/test/elixir/node_test.exs b/lib/elixir/test/elixir/node_test.exs
>> > +index d1f1fe6..5c2d469 100644
>> > +--- a/lib/elixir/test/elixir/node_test.exs
>> > ++++ b/lib/elixir/test/elixir/node_test.exs
>> > +@@ -6,8 +6,10 @@ defmodule NodeTest do
>> > +   doctest Node
>> > + 
>> > +   test "start/3 and stop/0" do
>> > +-    assert Node.stop == {:error, :not_found}
>> > +-    assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
>> > +-    assert Node.stop() == :ok
>> > ++    IO.puts "Skipping test because GNU Guix does not allow the HOME environment variable."
>> > ++
>> > ++    # assert Node.stop == {:error, :not_found}
>> > ++    # assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
>> > ++    # assert Node.stop() == :ok
>> > +   end
>> > + end
>> 
>> This was already addressed earlier.  We can probably just setenv HOME
>> before the tests.
>> 
>> Some of the remaining tests don’t seem to have any obvious fixes, so
>> I’ll get to them after making the above changes first.  Maybe the
>> failures disappear then.
>> 
>> Thanks again for the patch.  I hope you are willing to provide some
>> guidance when I have some problems understanding certain bits of the
>> build.
>
> I am happy to help out if you take the lead.

I documented the most common test errors, but there don’t seem to be any
quick fixes.  Attached is a new patch based on yours.  If this looks
good to you I’ll push it with you as the commit author and with a
“Co-authored-by: Ricardo Wurmus” line in the commit summary.

What do you think?

~~ Ricardo


[-- Attachment #2: 0001-gnu-Add-Elixir.patch --]
[-- Type: text/x-patch, Size: 15698 bytes --]

From 638cb3b45f09ccf7f93de0229c4f6906cf90ff62 Mon Sep 17 00:00:00 2001
From: Pjotr Prins <pjotr.public12@email>
Date: Thu, 21 Jul 2016 03:39:03 +0200
Subject: [PATCH] =?UTF-8?q?=EF=BB=BFgnu:=20Add=20Elixir.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* gnu/packages/elixir.scm: New file.
* gnu/packages/patches/elixir-disable-failing-tests.patch: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add module.
(dist_patch_DATA): Add patch.

Co-authored-by: Ricardo Wurmus <rekado@elephly.net>
---
 gnu/local.mk                                       |   2 +
 gnu/packages/elixir.scm                            |  99 ++++++++
 .../patches/elixir-disable-failing-tests.patch     | 261 +++++++++++++++++++++
 3 files changed, 362 insertions(+)
 create mode 100644 gnu/packages/elixir.scm
 create mode 100644 gnu/packages/patches/elixir-disable-failing-tests.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index ea63453..9b85445 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -104,6 +104,7 @@ GNU_SYSTEM_MODULES =				\
   %D%/packages/ebook.scm			\
   %D%/packages/ed.scm				\
   %D%/packages/elf.scm				\
+  %D%/packages/elixir.scm			\
   %D%/packages/emacs.scm			\
   %D%/packages/enchant.scm			\
   %D%/packages/engineering.scm			\
@@ -479,6 +480,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/duplicity-piped-password.patch		\
   %D%/packages/patches/duplicity-test_selection-tmp.patch	\
   %D%/packages/patches/elfutils-tests-ptrace.patch		\
+  %D%/packages/patches/elixir-disable-failing-tests.patch	\
   %D%/packages/patches/einstein-build.patch			\
   %D%/packages/patches/emacs-exec-path.patch			\
   %D%/packages/patches/emacs-fix-scheme-indent-function.patch	\
diff --git a/gnu/packages/elixir.scm b/gnu/packages/elixir.scm
new file mode 100644
index 0000000..4e430b3
--- /dev/null
+++ b/gnu/packages/elixir.scm
@@ -0,0 +1,99 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Leo Famulari <leo@famulari.name>
+;;; Copyright © 2016 Pjotr Prins <pjotr.public12@thebird.nl>
+;;; Copyright © 2016 Ricardo Wurmus <rekado@elephly.net>
+;;;
+;;; 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 elixir)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix build-system gnu)
+  #:use-module (guix download)
+  #:use-module (guix packages)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages erlang)
+  #:use-module (gnu packages version-control))
+
+(define-public elixir
+  (package
+    (name "elixir")
+    (version "1.3.2")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "https://github.com/elixir-lang/elixir"
+                                  "/archive/v" version ".tar.gz"))
+              (file-name (string-append name "-" version ".tar.gz"))
+              (sha256
+               (base32
+                "0jsc6kl7f74yszcypdv3w3vhyc9qfqav8nwc41in082m0vpfy95y"))
+              ;; FIXME: Some tests had to be disabled as they fail in the
+              ;; build environment.  Common failures are:
+              ;; - Mix.Shell.cmd() fails with error 130
+              ;; - The git_repo fixture cannot be found
+              ;; - Communication with spawned processes fails with EPIPE
+              ;; - Failure to copy files
+              (patches (search-patches "elixir-disable-failing-tests.patch"))))
+    (build-system gnu-build-system)
+    (arguments
+     `(#:test-target "test"
+       #:make-flags (list (string-append "PREFIX="
+                                         (assoc-ref %outputs "out")))
+       #:phases
+       (modify-phases %standard-phases
+         (add-after 'unpack 'replace-paths
+           (lambda* (#:key inputs #:allow-other-keys)
+             (substitute* '("lib/elixir/lib/system.ex"
+                            "lib/mix/lib/mix/scm/git.ex")
+               (("(cmd\\(['\"])git" _ prefix)
+                (string-append prefix (which "git"))))
+             (substitute* "bin/elixir"
+               (("ERL_EXEC=\"erl\"")
+                (string-append "ERL_EXEC=" (which "erl"))))
+             #t))
+         (add-after 'unpack 'fix-or-disable-tests
+           (lambda* (#:key inputs #:allow-other-keys)
+             ;; Some tests require access to a home directory.
+             (setenv "HOME" "/tmp")
+
+             ;; FIXME: These tests fail because the "git_repo" fixture does
+             ;; not exist or cannot be found.
+             (delete-file "lib/mix/test/mix/tasks/deps.git_test.exs")
+
+             ;; FIXME: Mix.Shell.cmd() always fails with error code 130.
+             (delete-file "lib/mix/test/mix/shell_test.exs")
+             #t))
+         (add-before 'build 'make-current
+           ;; The Elixir compiler checks whether or not to compile files by
+           ;; inspecting their timestamps.  When the timestamp is equal to the
+           ;; epoch no compilation will be performed.  Some tests fail when
+           ;; files are older than Jan 1, 2000.
+           (lambda _
+             (for-each (lambda (file)
+                         (let ((recent 1400000000))
+                           (utime file recent recent 0 0)))
+                       (find-files "." ".*"))
+             #t))
+         (delete 'configure))))
+    (inputs
+     `(("erlang" ,erlang)
+       ("git" ,git)))
+    (home-page "http://elixir-lang.org/")
+    (synopsis "Elixir programming language")
+    (description "Elixir is a dynamic, functional language used to build
+scalable and maintainable applications.  Elixir leverages the Erlang VM, known
+for running low-latency, distributed and fault-tolerant systems, while also
+being successfully used in web development and the embedded software domain.")
+    (license license:asl2.0)))
diff --git a/gnu/packages/patches/elixir-disable-failing-tests.patch b/gnu/packages/patches/elixir-disable-failing-tests.patch
new file mode 100644
index 0000000..0c67562
--- /dev/null
+++ b/gnu/packages/patches/elixir-disable-failing-tests.patch
@@ -0,0 +1,261 @@
+Most of these tests fail for unknown reasons when run in the chroot
+environment of a Guix build process.
+
+Common failures are:
+
+ * Mix.Shell.cmd() fails with error 130
+ * The git_repo fixture cannot be found
+ * Communication with spawned processes fails with EPIPE
+ * Failure to copy files
+
+
+diff --git a/lib/elixir/test/elixir/kernel/cli_test.exs b/lib/elixir/test/elixir/kernel/cli_test.exs
+index 3ffd56c..1232d19 100644
+--- a/lib/elixir/test/elixir/kernel/cli_test.exs
++++ b/lib/elixir/test/elixir/kernel/cli_test.exs
+@@ -39,6 +39,7 @@ end
+ defmodule Kernel.CLI.OptionParsingTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "properly parses paths" do
+     root = fixture_path("../../..") |> to_charlist
+     list = elixir('-pa "#{root}/*" -pz "#{root}/lib/*" -e "IO.inspect(:code.get_path, limit: :infinity)"')
+@@ -57,6 +58,7 @@ end
+ defmodule Kernel.CLI.AtExitTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "invokes at_exit callbacks" do
+     assert elixir(fixture_path("at_exit.exs") |> to_charlist) ==
+            'goodbye cruel world with status 1\n'
+@@ -66,6 +68,7 @@ end
+ defmodule Kernel.CLI.ErrorTest do
+   use ExUnit.Case, async: true
+ 
++  @tag :skip
+   test "properly format errors" do
+     assert :string.str('** (throw) 1', elixir('-e "throw 1"')) == 0
+     assert :string.str('** (ErlangError) erlang error: 1', elixir('-e "error 1"')) == 0
+@@ -86,6 +89,7 @@ defmodule Kernel.CLI.CompileTest do
+     {:ok, [tmp_dir_path: tmp_dir_path, beam_file_path: beam_file_path, fixture: fixture]}
+   end
+ 
++  @tag :skip
+   test "compiles code", context do
+     assert elixirc('#{context[:fixture]} -o #{context[:tmp_dir_path]}') == ''
+     assert File.regular?(context[:beam_file_path])
+@@ -96,6 +100,7 @@ defmodule Kernel.CLI.CompileTest do
+     Code.delete_path context[:tmp_dir_path]
+   end
+ 
++  @tag :skip
+   test "fails on missing patterns", context do
+     output = elixirc('#{context[:fixture]} non_existing.ex -o #{context[:tmp_dir_path]}')
+     assert :string.str(output, 'non_existing.ex') > 0, "expected non_existing.ex to be mentioned"
+@@ -103,6 +108,7 @@ defmodule Kernel.CLI.CompileTest do
+     refute File.exists?(context[:beam_file_path]), "expected the sample to not be compiled"
+   end
+ 
++  @tag :skip
+   test "fails on missing write access to .beam file", context do
+     compilation_args = '#{context[:fixture]} -o #{context[:tmp_dir_path]}'
+ 
+diff --git a/lib/elixir/test/elixir/kernel/dialyzer_test.exs b/lib/elixir/test/elixir/kernel/dialyzer_test.exs
+index 801d852..40fc5bc 100644
+--- a/lib/elixir/test/elixir/kernel/dialyzer_test.exs
++++ b/lib/elixir/test/elixir/kernel/dialyzer_test.exs
+@@ -60,16 +60,19 @@ defmodule Kernel.DialyzerTest do
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on rewrites", context do
+     copy_beam! context, Dialyzer.Rewrite
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on raise", context do
+     copy_beam! context, Dialyzer.Raise
+     assert_dialyze_no_warnings! context
+   end
+ 
++  @tag :skip
+   test "no warnings on macrocallback", context do
+     copy_beam! context, Dialyzer.Macrocallback
+     copy_beam! context, Dialyzer.Macrocallback.Impl
+diff --git a/lib/elixir/test/elixir/system_test.exs b/lib/elixir/test/elixir/system_test.exs
+index aafa559..0f9c178 100644
+--- a/lib/elixir/test/elixir/system_test.exs
++++ b/lib/elixir/test/elixir/system_test.exs
+@@ -53,7 +53,8 @@ defmodule SystemTest do
+     assert System.endianness in [:little, :big]
+     assert System.endianness == System.compiled_endianness
+   end
+-
++ 
++  @tag :skip
+   test "argv/0" do
+     list = elixir('-e "IO.inspect System.argv" -- -o opt arg1 arg2 --long-opt 10')
+     {args, _} = Code.eval_string list, []
+diff --git a/lib/mix/test/mix/dep_test.exs b/lib/mix/test/mix/dep_test.exs
+index fff3351..d6ed1b3 100644
+--- a/lib/mix/test/mix/dep_test.exs
++++ b/lib/mix/test/mix/dep_test.exs
+@@ -244,6 +244,7 @@ defmodule Mix.DepTest do
+     end
+   end
+ 
++  @tag :skip
+   test "remote converger" do
+     deps = [{:deps_repo, "0.1.0", path: "custom/deps_repo"},
+             {:git_repo, "0.2.0", git: MixTest.Case.fixture_path("git_repo")}]
+@@ -301,6 +302,7 @@ defmodule Mix.DepTest do
+     end
+   end
+ 
++  @tag :skip
+   test "remote converger is not invoked if deps diverge" do
+     deps = [{:deps_repo, "0.1.0", path: "custom/deps_repo"},
+             {:git_repo, "0.2.0", git: MixTest.Case.fixture_path("git_repo"), only: :test}]
+diff --git a/lib/mix/test/mix/rebar_test.exs b/lib/mix/test/mix/rebar_test.exs
+index d2dd098..12cef15 100644
+--- a/lib/mix/test/mix/rebar_test.exs
++++ b/lib/mix/test/mix/rebar_test.exs
+@@ -120,6 +120,7 @@ defmodule Mix.RebarTest do
+     assert Enum.all?(deps, &(&1.manager == :rebar3))
+   end
+ 
++  @tag :skip
+   test "Rebar overrides" do
+     Mix.Project.push(RebarOverrideAsDep)
+ 
+@@ -150,6 +151,7 @@ defmodule Mix.RebarTest do
+     end
+   end
+ 
++  @tag :skip
+   test "get and compile dependencies for Rebar" do
+     Mix.Project.push(RebarAsDep)
+ 
+@@ -180,6 +182,7 @@ defmodule Mix.RebarTest do
+     end
+   end
+ 
++  @tag :skip
+   test "get and compile dependencies for rebar3" do
+     Mix.Project.push(Rebar3AsDep)
+ 
+diff --git a/lib/mix/test/mix/shell/io_test.exs b/lib/mix/test/mix/shell/io_test.exs
+index 9bfb6b4..d982ef3 100644
+--- a/lib/mix/test/mix/shell/io_test.exs
++++ b/lib/mix/test/mix/shell/io_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Shell.IOTest do
+     assert capture_io("", fn -> refute yes?("Ok?") end)
+   end
+ 
++  @tag :skip
+   test "runs a given command" do
+     assert capture_io("", fn -> assert cmd("echo hello") == 0 end) == "hello\n"
+ 
+diff --git a/lib/mix/test/mix/shell/quiet_test.exs b/lib/mix/test/mix/shell/quiet_test.exs
+index 626429b..99fab35 100644
+--- a/lib/mix/test/mix/shell/quiet_test.exs
++++ b/lib/mix/test/mix/shell/quiet_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Shell.QuietTest do
+     assert capture_io("", fn -> refute yes?("Ok?") end)
+   end
+ 
++  @tag :skip
+   test "runs a given command" do
+     assert capture_io("", fn -> assert cmd("echo hello") == 0 end) == ""
+ 
+diff --git a/lib/mix/test/mix/tasks/cmd_test.exs b/lib/mix/test/mix/tasks/cmd_test.exs
+index db4bf06..4d441f7 100644
+--- a/lib/mix/test/mix/tasks/cmd_test.exs
++++ b/lib/mix/test/mix/tasks/cmd_test.exs
+@@ -3,6 +3,7 @@ Code.require_file "../../test_helper.exs", __DIR__
+ defmodule Mix.Tasks.CmdTest do
+   use MixTest.Case
+ 
++  @tag :skip
+   test "runs the command for each app" do
+     in_fixture "umbrella_dep/deps/umbrella", fn ->
+       Mix.Project.in_project(:umbrella, ".", fn _ ->
+diff --git a/lib/mix/test/mix/tasks/deps.tree_test.exs b/lib/mix/test/mix/tasks/deps.tree_test.exs
+index 4f09ff3..c371997 100644
+--- a/lib/mix/test/mix/tasks/deps.tree_test.exs
++++ b/lib/mix/test/mix/tasks/deps.tree_test.exs
+@@ -29,6 +29,7 @@ defmodule Mix.Tasks.Deps.TreeTest do
+     end
+   end
+ 
++  @tag :skip
+   test "shows the dependency tree", context do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -109,6 +110,7 @@ defmodule Mix.Tasks.Deps.TreeTest do
+     end
+   end
+ 
++  @tag :skip
+   test "shows the dependency tree in DOT graph format", context do
+     Mix.Project.push ConvergedDepsApp
+ 
+diff --git a/lib/mix/test/mix/tasks/deps_test.exs b/lib/mix/test/mix/tasks/deps_test.exs
+index b061777..cc45cf8 100644
+--- a/lib/mix/test/mix/tasks/deps_test.exs
++++ b/lib/mix/test/mix/tasks/deps_test.exs
+@@ -96,6 +96,7 @@
+     end
+   end
+ 
++  @tag :skip
+   test "prints list of dependencies and their lock status" do
+     Mix.Project.push DepsApp
+ 
+@@ -409,6 +409,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "fails on diverged dependencies by requirement" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -440,6 +441,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "fails on diverged dependencies even when optional" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -469,6 +471,7 @@ defmodule Mix.Tasks.DepsTest do
+     end
+   end
+ 
++  @tag :skip
+   test "works with converged dependencies" do
+     Mix.Project.push ConvergedDepsApp
+ 
+@@ -491,6 +494,7 @@ defmodule Mix.Tasks.DepsTest do
+     purge [GitRepo, GitRepo.Mixfile]
+   end
+ 
++  @tag :skip
+   test "works with overridden dependencies" do
+     Mix.Project.push OverriddenDepsApp
+ 
+diff --git a/lib/mix/test/mix/umbrella_test.exs b/lib/mix/test/mix/umbrella_test.exs
+index 69f9428..406668a 100644
+--- a/lib/mix/test/mix/umbrella_test.exs
++++ b/lib/mix/test/mix/umbrella_test.exs
+@@ -98,6 +98,7 @@ defmodule Mix.UmbrellaTest do
+     end
+   end
+ 
++  @tag :skip
+   test "loads umbrella child dependencies in all environments" do
+     in_fixture "umbrella_dep/deps/umbrella", fn ->
+       Mix.Project.in_project :umbrella, ".", fn _ ->
-- 
2.8.4

Re: [PATCH] Add Elixir (was: )

[Ricardo Wurmus]

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

> On Thu, Jul 28, 2016 at 10:35:29PM +0200, Ricardo Wurmus wrote:
>> Never mind.  It was as Vincent thought.  Closing all applications except
>> for Emacs makes it work.
>
> Be interesting to see what increasing swap space does. I think we
> ought to file it as an issue if that does not help:
>
>   http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

I increased swap space to 12G and it compiled most of the time.  It’s a
bit odd.  Sometimes it would fail with

    == Compilation error on file lib/system.ex ==
    ** (exit) :epipe

Other times it would get stuck compiling “lib/elixir/lib/system.ex”.
But with enough swap space it mostly compiles Elixir just fine.

~~ Ricardo

Re: [PATCH] Add Elixir

[Pjotr Prins]

On Tue, Aug 02, 2016 at 10:44:11AM +0200, Ricardo Wurmus wrote:
> I documented the most common test errors, but there don’t seem to be any
> quick fixes.  Attached is a new patch based on yours.  If this looks
> good to you I’ll push it with you as the commit author and with a
> “Co-authored-by: Ricardo Wurmus” line in the commit summary.
> 
> What do you think?

Effing awesome. Especially the time stamp find - I would never have
thought of that. You'd think setting the time stamps to epoch happens
after install phase. Please push, as far as I am concerned.

Pj.

Re: [PATCH] Add Elixir (was: )

[Pjotr Prins]

On Tue, Aug 02, 2016 at 10:56:27AM +0200, Ricardo Wurmus wrote:
> 
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > On Thu, Jul 28, 2016 at 10:35:29PM +0200, Ricardo Wurmus wrote:
> >> Never mind.  It was as Vincent thought.  Closing all applications except
> >> for Emacs makes it work.
> >
> > Be interesting to see what increasing swap space does. I think we
> > ought to file it as an issue if that does not help:
> >
> >   http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html
> 
> I increased swap space to 12G and it compiled most of the time.  It’s a
> bit odd.  Sometimes it would fail with
> 
>     == Compilation error on file lib/system.ex ==
>     ** (exit) :epipe
> 
> Other times it would get stuck compiling “lib/elixir/lib/system.ex”.
> But with enough swap space it mostly compiles Elixir just fine.

I'll post it as an issue. Swap space does not always act rational ;)

But they should not use so much RAM for compilation.

Pj.
-- 

Re: [PATCH] Add Elixir

[Ludovic Courtès]

Hello!

Ricardo Wurmus <rekado@elephly.net> skribis:

> I documented the most common test errors, but there don’t seem to be any
> quick fixes.  Attached is a new patch based on yours.  If this looks
> good to you I’ll push it with you as the commit author and with a
> “Co-authored-by: Ricardo Wurmus” line in the commit summary.

Woow, congratulation, and a big thanks for taking the time to
investigate the issues!

> +++ b/gnu/packages/patches/elixir-disable-failing-tests.patch
> @@ -0,0 +1,261 @@
> +Most of these tests fail for unknown reasons when run in the chroot
> +environment of a Guix build process.
> +
> +Common failures are:
> +
> + * Mix.Shell.cmd() fails with error 130

Could it be that this method relies on /bin/sh?  We have
patches/substitutions for similar functions in libc, gawk, and Guile,
for instance.

> + * The git_repo fixture cannot be found
> + * Communication with spawned processes fails with EPIPE

It might be that processes are spawned with /bin/sh too, and thus fail
instantly.

Cheers,
Ludo’.

Re: [PATCH] Add Elixir

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> I documented the most common test errors, but there don’t seem to be any
>> quick fixes.  Attached is a new patch based on yours.  If this looks
>> good to you I’ll push it with you as the commit author and with a
>> “Co-authored-by: Ricardo Wurmus” line in the commit summary.
>
> Woow, congratulation, and a big thanks for taking the time to
> investigate the issues!
>
>> +++ b/gnu/packages/patches/elixir-disable-failing-tests.patch
>> @@ -0,0 +1,261 @@
>> +Most of these tests fail for unknown reasons when run in the chroot
>> +environment of a Guix build process.
>> +
>> +Common failures are:
>> +
>> + * Mix.Shell.cmd() fails with error 130
>
> Could it be that this method relies on /bin/sh?  We have
> patches/substitutions for similar functions in libc, gawk, and Guile,
> for instance.

It uses “sh -c” and even after replacing “sh” with the result of “(which
"sh")” the errors remained, so I removed the change again.

>> + * The git_repo fixture cannot be found
>> + * Communication with spawned processes fails with EPIPE
>
> It might be that processes are spawned with /bin/sh too, and thus fail
> instantly.

I’m not familiar enough with Erlang/Elixir to understand exactly what’s
going on.  As far as I could see there are no explicit references to
“/bin/sh” in the code.

I pushed the commit as 0a4ebe01481d8f899bfc8849a27c1cf33c271c24.
Thanks, Pjotr, for the work!

~~ Ricardo

Re: [PATCH] Add Elixir

[Pjotr Prins]

On Tue, Aug 02, 2016 at 11:25:30PM +0200, Ricardo Wurmus wrote:
> > It might be that processes are spawned with /bin/sh too, and thus fail
> > instantly.
> 
> I’m not familiar enough with Erlang/Elixir to understand exactly what’s
> going on.  As far as I could see there are no explicit references to
> “/bin/sh” in the code.

I'll discuss with upstream.

> I pushed the commit as 0a4ebe01481d8f899bfc8849a27c1cf33c271c24.
> Thanks, Pjotr, for the work!

Thank you Ricardo for mentoring.

Pj.

Re: [PATCH] Add Elixir

[Pjotr Prins]

GNU Guix is mentioned on the Elixir installation page:

  http://elixir-lang.org/install.html

Pj.

Re: [PATCH] Add Elixir

[Alex Sassmannshausen]

Pjotr Prins writes:

> GNU Guix is mentioned on the Elixir installation page:
>
>   http://elixir-lang.org/install.html
>
> Pj.

Neat!  Congrats to both of your hard work on this!

Alex

Re: bug#24066: icecat "mailto" handler does not work - and cannot be reconfigured by user

[Maxim Cournoyer]

Hello Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

[...]

> Checking the application preferences of icecat, it only gives "always
> ask" (note: it doesn't ask) and not an application for "mailto". (in
> GuixSD)

Testing in latest IceCat, there's a 'Use other...' entry in the mailto
applications configuration.  I also saw 'Emacs' in the list of potential
applications to open mailto URIs, tried it and it opened Emacs.

Does that work for you?

To get the applications recognized as supporting this URI scheme, they
must provide a .desktop file which mentions support for it, for example
via a MimeType=x-scheme-handler entry:

--8<---------------cut here---------------start------------->8---
$ grep -rin 'x-scheme-handler' $(guix build weechat)
/gnu/store/...-weechat-2.9/share/applications/weechat.desktop:17:MimeType=x-scheme-handler/irc;x-scheme-handler/ircs;--8<---------------cut here---------------end--------------->8---

This information gets compiled into a MIME database by a profile hook
under:

--8<---------------cut here---------------start------------->8---
$ grep 'x-scheme-handler/ircs' ~/.guix-profile/share/applications/mimeinfo.cache 
x-scheme-handler/ircs=weechat.desktop;
--8<---------------cut here---------------end--------------->8---

And Icecat picks its up to show ircs:// URIs and shows the application
as registered for this type in its Applications settings view.

Maxim