diff mbox series

[bug#37912] gnu: elixir: Update to 1.9.2.

Message ID LrzW39---3-1@maatriks.ee
State Accepted
Headers show
Series [bug#37912] gnu: elixir: Update to 1.9.2. | expand

Commit Message

Oskar Köök Oct. 24, 2019, 8:45 p.m. UTC

Comments

Mathieu Othacehe Oct. 25, 2019, 12:16 p.m. UTC | #1
Hello,

When building elixir with this patch, I have the following error:

--8<---------------cut here---------------start------------->8---
Finished in 363.7 seconds (2.5s on load, 361.1s on tests)
9 doctests, 625 tests, 6 failures

Randomized with seed 237287
make: *** [Makefile:113: test_mix] Error 1

Test suite failed, dumping logs.
command "make" "test" "PREFIX=/gnu/store/q95v9n7c0nhrkqmn1xhr785zqi4mp81k-elixir-1.9.2" failed with status 2
builder for `/gnu/store/clqdccpnxbz4wg4c37shsn59d1y4b9wq-elixir-1.9.2.drv' failed with exit code 1
build of /gnu/store/clqdccpnxbz4wg4c37shsn59d1y4b9wq-elixir-1.9.2.drv failed
View build log at '/var/log/guix/drvs/cl/qdccpnxbz4wg4c37shsn59d1y4b9wq-elixir-1.9.2.drv.bz2'.
guix build: error: build of `/gnu/store/clqdccpnxbz4wg4c37shsn59d1y4b9wq-elixir-1.9.2.drv' failed
--8<---------------cut here---------------end--------------->8---

any idea why?

Thanks,

Mathieu
Oskar Köök Oct. 31, 2019, 2:35 p.m. UTC | #2
Sorry, first time using Guix.

Some Elixir tests are failing, caused by a new feature. I have locally fixed most of the issues related to this (I can now manually run the Makefile in the generated Guix folder without any tests failing), but I am stuck on a part where the tests spawn binaries and wait for a certain file to be created in a certain location. This does not work during the Guix build.

I will examine further over the weekend. If I can not fix these tests, is it acceptable to disable them? I can verify that the behaviour being tested works manually.

Oskar
Marius Bakke Oct. 31, 2019, 10:54 p.m. UTC | #3
Oskar Köök <oskar@maatriks.ee> writes:

> Sorry, first time using Guix.
>
> Some Elixir tests are failing, caused by a new feature. I have locally fixed most of the issues related to this (I can now manually run the Makefile in the generated Guix folder without any tests failing), but I am stuck on a part where the tests spawn binaries and wait for a certain file to be created in a certain location. This does not work during the Guix build.

Perhaps it requires a network connection?  Or /bin/sh?  Those are the
most common sources of things failing in the build container but not on
a "regular" system.

> I will examine further over the weekend. If I can not fix these tests, is it acceptable to disable them? I can verify that the behaviour being tested works manually.

We should find out why they are failing in either case.  :-)
Oskar Köök Nov. 1, 2019, 2:09 p.m. UTC | #4
Although I must note that the end-result ends up ruining the whole point of Elixir Releases.

The point of an Elixir release is that you can package an application into a stand-alone item. It will copy elixir & erlang (etc) as well as your application into a single package, so you can run it without having elixir & erlang installed on your system.

I guess the single dependency here is /bin/sh: as long as it exists, you can run the application from any system.

If you were to generate a release with Guix, you would end up with scripts that depend on the Guix store. So you can not run the stand-alone without Guix.

What is the solution to this? I would personally prefer to keep the actual behaviour (if possible) and if needed, disable the tests.

Oskar
Marius Bakke Nov. 3, 2019, 4:52 p.m. UTC | #5
Oskar Köök <oskar@maatriks.ee> writes:

> Although I must note that the end-result ends up ruining the whole point of Elixir Releases.
>
> The point of an Elixir release is that you can package an application into a stand-alone item. It will copy elixir & erlang (etc) as well as your application into a single package, so you can run it without having elixir & erlang installed on your system.
>
> I guess the single dependency here is /bin/sh: as long as it exists, you can run the application from any system.
>
> If you were to generate a release with Guix, you would end up with scripts that depend on the Guix store. So you can not run the stand-alone without Guix.
>
> What is the solution to this? I would personally prefer to keep the actual behaviour (if possible) and if needed, disable the tests.

The typical solution here is to reset the shebang after running the
tests.  I know there are a couple of packages doing this, but can't
recall which at the moment.

Can you try that?  Thanks for working on it!
diff mbox series

Patch

From bfbd16af6aaf3d2685f01fa8059a220485e830ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Oskar=20K=C3=B6=C3=B6k?= <oskarkook@maatriks.ee>
Date: Thu, 24 Oct 2019 23:37:38 +0300
Subject: [PATCH] gnu: elixir: Update to 1.9.2.

* gnu/packages/elixir.scm (elixir): Update to 1.9.2.
---
 gnu/packages/elixir.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/elixir.scm b/gnu/packages/elixir.scm
index 88ada71aea..d3f30c624e 100644
--- a/gnu/packages/elixir.scm
+++ b/gnu/packages/elixir.scm
@@ -33,7 +33,7 @@ 
 (define-public elixir
   (package
     (name "elixir")
-    (version "1.8.2")
+    (version "1.9.2")
     (source
      (origin
        (method git-fetch)
@@ -42,7 +42,7 @@ 
              (commit (string-append "v" version))))
        (file-name (git-file-name name version))
        (sha256
-        (base32 "1n77cpcl2b773gmj3m9s24akvj9gph9byqbmj2pvlsmby4aqwckq"))
+        (base32 "19yn6nx6r627f5zbyc7ckgr96d6b45sgwx95n2gp2imqwqvpj8wc"))
        (patches (search-patches "elixir-path-length.patch"))))
     (build-system gnu-build-system)
     (arguments
-- 
2.21.0