Release 0.14.0 suffers from gnutls issue

[DamienCassou]

With both Emacs 26 pretest and Emacs git snapshot:

$ emacs --version
/tmp/emacs-26-pretest-travis/bin/emacs: error while loading shared libraries: libgnutls.so.26: cannot open shared object file: No such file or directory

[DamienCassou]

To reproduce, use this Dockerfile:

FROM ubuntu:16.04

RUN apt-get update --quiet

# Make sure dpkg does not ask questions (such as which keyboard layout to configure)
ENV DEBIAN_FRONTEND noninteractive

# Install misc dependencies:
# - curl, git, make: used by many scripts
# - python: used by Cask
# - ruby, xorg: used by EVM
RUN apt-get install --quiet --assume-yes curl git make python ruby gnutls-bin

# Install evm
RUN curl -fsSkL https://raw.github.com/rejeep/evm/master/go | bash
ENV PATH /root/.evm/bin:$PATH

# Install all versions of Emacs available with EVM
RUN evm config path /tmp

RUN evm install emacs-26-pretest-travis
RUN evm install emacs-git-snapshot-travis

# Activate latest Emacs release
RUN evm use emacs-26-pretest-travis

[sambrightman]

It is intentional to support built-in GnuTLS, since this appears to be the most reliable way forward for correct HTTPS on Travis. These binaries are intended for Travis. It sounds like GnuTLS is not installed in your Docker image - is that right?

[DamienCassou]

As you can see at the end of the RUN apt-get install line above, gnutls-bin is indeed installed:

# gnutls-cli --version
gnutls-cli 3.4.10
Copyright (C) 2000-2016 Free Software Foundation, and others, all rights reserved.
This is free software. It is licensed for use, modification and
redistribution under the terms of the GNU General Public License,
version 3 or later <http://gnu.org/licenses/gpl.html>

Please send bug reports to:  <bugs@gnutls.org>

Is that too old? The docker image is from Ubuntu 16.04. Some packages seem to build a new gnutls: https://github.com/clojure-emacs/cider/blob/master/travis-ci/install-gnutls.sh.

[DamienCassou]

Also, I have libgnutls30 installed.

[sambrightman]

That package is the external binary (perhaps it is statically linked? I think there is another package for the libs, which is installed by default on Travis). When built-support is available it is used in preference. I suggest checking that.

I believe that project built a newer version as a temporary workaround because of elpa.gnu.org misconfiguration, discussed here https://github.com/rejeep/evm/issues/101#issuecomment-361032793 and now fixed.

[sambrightman]

The error is for 2.6 - does 3.0 install both?

[DamienCassou]

Ubuntu LTS doesn't provide libgnutls 2.6. Travis is using an old Ubuntu version which still provides libgnutls 2.6. I think what this shows is that EVM travis builds are not suitable for other virtualization environments.

[gonewest818]

Confirming yes, installing gnutls in the cider build was a temporary thing until the FSF admins fix the TLS cert on elpa.gnu.org (which appears to have been done).

[sambrightman]

Yes, the aim of #105/#106 is to get the Travis binaries working smoothly on Travis, not on other platforms. As previously discussed, it seems good to reduce dependencies and increase applicability when there is a common benefit but other solutions may be required for other environments. I don't think it's reasonable to have all Travis users install gnutls-bin just because Emacs has become stricter from 26 onwards (and using built-in support feels cleaner). It's maybe not so much about "not suitable for other virtualisation environments" as much as "building universal binaries is painful".

It's probably better not to open bugs like this for now against the existing versions, but consider what the best way forward might be for other use-cases (and how much maintenance that adds). For example, I've often wanted pre-built OS X binaries - but it's more of a convenience than a necessity. Doesn't that also apply to your Docker images? You could build each versions from source to fit exactly in your environment. The user of the environment then only needs to evm use the correct one, right?

[DamienCassou]

I agree with everything you say. We can close the issue.

The user of the environment then only needs to evm use the correct one, right?

I didn't know it was possible to use evm without evm binaries.

[sambrightman]

Okay, closing. If pre-building in the container doesn't work for some reason then let's rethink later.