all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nils Gillmann <ng0@n0.is>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 32171@debbugs.gnu.org, Nils Gillmann <ng0@n0.is>
Subject: [bug#32171] Update: Erlang and Elixir
Date: Mon, 16 Jul 2018 20:22:48 +0000	[thread overview]
Message-ID: <20180716202248.rdhlggsy7zfw2k6w@abyayala> (raw)
In-Reply-To: <87a7qrrn2e.fsf@gnu.org>

Ludovic Courtès transcribed 660 bytes:
> Nils Gillmann <ng0@n0.is> skribis:
> 
> > Okay, before I leave I've --check build the package again, at most
> > built with make -j4... Can you try and build it with less cores?
> 
> If you suspect a parallelism issue, could you check whether other
> distros have patches along these lines, or whether
> #:parallel-builds? #f gives us something that works reproducibly?

parallel-build set to #f does gives us a reproducible elixir package.
Seems like no one who cares about these details has it patched or
noted this: Gentoo would not necessarily meet our criteria for
reliable reproducible builds as we define it. Debian has it as
an open tracker item: https://tracker.debian.org/pkg/elixir-lang

1.6.6 was released 27 days ago, so we are still early.

Pjotr noted issues in the past. I don't know if Pjotr has
more experience with Erlang and Elixir, I've just started this
month, so a second, more experience opinion would be welcome.

Seems to me as if we have to dive into the testsuite to fix this.

> > guix build: error: build failed: derivation `/gnu/store/57394p4p5l928711hzj4xg7mkcg1zmz0-elixir-1.6.6.drv' may not be deterministic: output `/gnu/store/7jshqipclwq4x3nxb735pfhpmnrjyy38-elixir-1.6.6' differs

What I get with the parallel-build #f is:

phase `compress-documentation' succeeded after 0.0 seconds
@ build-succeeded /gnu/store/z35vfzjbxi81kacm18rcs4n0jzgjl5ca-elixir-1.6.6.drv -
retrieving 1 store item from 'cult.of.n0.is'...
importing file or directory '/gnu/store/3kl7xychrzk43m1iini8mfjg1jshhnlg-elixir-1.6.6'...
found valid signature for '/gnu/store/3kl7xychrzk43m1iini8mfjg1jshhnlg-elixir-1.6.6'
done with offloaded '/gnu/store/z35vfzjbxi81kacm18rcs4n0jzgjl5ca-elixir-1.6.6.drv'
@ build-succeeded /gnu/store/z35vfzjbxi81kacm18rcs4n0jzgjl5ca-elixir-1.6.6.drv -
The following derivation will be built:
   /gnu/store/zny8qxvkbrw2yhzg2ygs4mp4pz0ji80k-elixir-1.6.6.drv
   substitute: updating substitutes from 'https://berlin.guixsd.org'... 100.0%
   substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
   guix build: error: build failed: some outputs of `/gnu/store/zny8qxvkbrw2yhzg2ygs4mp4pz0ji80k-elixir-1.6.6.drv' are not valid, so checking is not possible
   


Apparently we had this (Erlang, Elixir reproducible) fixed at some point.
Elixir depends on a long list in its entire DAG, so this would be needle
in haystack hunting now. Erlang seems not to be reproducible again (new major
version, new fun). The runpath seems logical as it is, they introduced some
changes on the SSL side in Erlang/OTP 21.0, something we possible want to patch.

stripping binaries in "/gnu/store/a3938xrgzdlwh25qfpbhrgaf9gm6231b-erlang-21.0/lib" with "strip" and flags ("--strip-debug" "--enable-deterministic-archives")
stripping binaries in "/gnu/store/a3938xrgzdlwh25qfpbhrgaf9gm6231b-erlang-21.0/bin" with "strip" and flags ("--strip-debug" "--enable-deterministic-archives")
phase `strip' succeeded after 0.8 seconds
starting phase `validate-runpath'
validating RUNPATH of 37 binaries in "/gnu/store/a3938xrgzdlwh25qfpbhrgaf9gm6231b-erlang-21.0/lib"...
/gnu/store/a3938xrgzdlwh25qfpbhrgaf9gm6231b-erlang-21.0/lib/erlang/lib/crypto-4.3/priv/lib/crypto.so: warning: RUNPATH contains bogus entries: ("/usr/local/lib" "/usr/sfw/lib" "/usr/lib" "/opt/local/lib" "/usr/pkg/lib" "/usr/local/openssl/lib" "/usr/lib/openssl/lib" "/usr/openssl/lib" "/usr/local/ssl/lib" "/usr/lib/ssl/lib" "/usr/ssl/lib" "//lib")
/gnu/store/a3938xrgzdlwh25qfpbhrgaf9gm6231b-erlang-21.0/lib/erlang/lib/crypto-4.3/priv/lib/otp_test_engine.so: warning: RUNPATH contains bogus entries: ("/usr/local/lib" "/usr/sfw/lib" "/usr/lib" "/opt/local/lib" "/usr/pkg/lib" "/usr/local/openssl/lib" "/usr/lib/openssl/lib" "/usr/openssl/lib" "/usr/local/ssl/lib" "/usr/lib/ssl/lib" "/usr/ssl/lib" "//lib")
validating RUNPATH of 8 binaries in "/gnu/store/a3938xrgzdlwh25qfpbhrgaf9gm6231b-erlang-21.0/bin"...
phase `validate-runpath' succeeded after 0.3 seconds
starting phase `validate-documentation-location'
phase `validate-documentation-location' succeeded after 0.0 seconds
starting phase `delete-info-dir-file'
phase `delete-info-dir-file' succeeded after 0.0 seconds
starting phase `patch-dot-desktop-files'
phase `patch-dot-desktop-files' succeeded after 0.0 seconds
starting phase `install-license-files'
installing 1 license files
phase `install-license-files' succeeded after 0.0 seconds
starting phase `reset-gzip-timestamps'
phase `reset-gzip-timestamps' succeeded after 0.0 seconds
starting phase `compress-documentation'
compressing documentation in '/gnu/store/a3938xrgzdlwh25qfpbhrgaf9gm6231b-erlang-21.0/share/man' with "gzip" and flags ("--best" "--no-name")
phase `compress-documentation' succeeded after 0.3 seconds
guix build: error: build failed: derivation `/gnu/store/1vaz67iwn518m8d35j98zjpy3fjw92ca-erlang-21.0.drv' may not be deterministic: output `/gnu/store/a3938xrgzdlwh25qfpbhrgaf9gm6231b-erlang-21.0' differs

>
> Once we’ve fixed the issue above, we should look into this.  :-)

It's never just one issue and one quick submission of package updates
when it works you, isn't it? :D

> Ludo’.

  reply	other threads:[~2018-07-16 20:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-16 10:07 [bug#32171] Update: Erlang and Elixir Nils Gillmann
2018-07-16 15:16 ` Ludovic Courtès
2018-07-16 15:36   ` Nils Gillmann
2018-07-16 15:53     ` Nils Gillmann
2018-07-16 16:06       ` Nils Gillmann
2018-07-16 19:35         ` Ludovic Courtès
2018-07-16 20:22           ` Nils Gillmann [this message]
2018-07-17  9:48             ` Pjotr Prins
2018-07-17 12:35             ` bug#32171: " Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180716202248.rdhlggsy7zfw2k6w@abyayala \
    --to=ng0@n0.is \
    --cc=32171@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.