emacs-26.1-travis has runtime dependency on libgnutls.so.26
dajva opened this issue · comments
The garnet docker image based on trusty should have been replaced by sardonyx based on xenial here: travis-ci/packer-templates@8a3a8a5#diff-23f3ca1299f2f831c8d4c43e139457dd
xenial has libgnutls.so.30 instead of libgnutls.so.26 which makes the dynamic loader fail when starting emacs.
I just got hit by this when the docker images I use on travis switched from trusty to xenial.
So should the emacs 26.x binaries be rebuilt in sardonyx container?
I suspect there may be a general rollout of newer images on travis that may affect a lot of emacs packages.
The ideal would be to link statically with libgnutls to avoid these kind of problems but I don't know if that is supported by emacs.
I’m not following exactly - why should it have been replaced? Trusty is still the default.
Trusty has reached EOL. I did some googling after I reported this issue and this is a general switch to xenial as default: https://blog.travis-ci.com/2019-04-15-xenial-default-build-environment
Xenial is now being rolled out as the default build environment and is being rolled out incrementally (starting with 5% about two months ago) just FYI: https://changelog.travis-ci.com/xenial-as-the-default-build-environment-99476
So like.... This issue is still not addressed then?
The dependency was intentional (maybe it is possible to statically link?). Backward compatible will still be required for people using Trusty.
I don't think there's much of a consensus on building alternate binaries for different platforms right now, which would seem the obvious way forward if static linking is not possible. Maybe some -travis-xenial versions would be appropriate. But we also have to think about the workload of building/maintaining a larger variety of releases.
I did some brief investigation of static linking when I reported this but there wasn't any obvious way to do this via the configure script so I left it at that. Might be possible with some tweaking. Alternatively EVM could ship the used library and make sure it's picked up at runtime via rpath or similar.
IMHO, keeping backwards compatibility with an obsolete platform like trusty is not worth the trouble. Would be trivial to fix for most packages by just switching to xenial in the travis file anyway. Doesn't really make sense to do testing on a platform that "no one" use anymore although the difference for most emacs packages is probably insignificant.
FWIW, I am currently looking at switching to https://github.com/purcell/nix-emacs-ci. Should handle these kind of problems as I understand it.
I don't think it's possible to statically link still. I think backward-compatibility is worth it but it doesn't seem unreasonable to issue separate binaries since they are already requested for e.g. macOS also. We could map the latest -travis to match the latest default version maybe too.
(It is somewhat untrue that EVM is _un_maintained as https://github.com/purcell/nix-emacs-ci states. Most contributors do not have much time, it seems. And most people are not submitting PRs).
(It is somewhat untrue that EVM is _un_maintained as https://github.com/purcell/nix-emacs-ci states. Most contributors do not have much time, it seems. And most people are not submitting PRs).
Definitely agree that time is a problem. Also motivation could be an issue for mature packages where all the fun work has already been done. That background is part of why I suggested to drop trusty in order to keep maintainance level low.
We'll see how my experiment with nix-emacs-ci goes. If I decide to stay with EVM I can help out with fixing the packages when a conclusion about the way forward has been made.
It is somewhat untrue that EVM is _un_maintained
Not sure what started this diversion. Sorry if that was my fault.
Most contributors do not have much time, it seems. And most people are not submitting PRs
Welcome to FOSS. And here I am, not putting in a PR. 😑
Also motivation could be an issue for mature packages where all the fun work has already been done.
This is basically the developer/maintainer role transition. Every successful FOSS project enters this phase at some point. A weird kind of luxury problem?
IMHO, keeping backwards compatibility with an obsolete platform like trusty is not worth the trouble. ... That background is part of why I suggested to drop trusty in order to keep maintainance level low.
Seconded. Trusty is actually EOLed at this point.
I’m trying to build some Xenial binaries. Whilst it may not be necessary to depend on GnuTLS at some point, it was for some recent versions and other, similar requirements may evolve in the future.
Naturally, backward compatibility is unimportant for those who don’t care for it. That seems self-evident. Others will care, and I’ve already seen some saying they need Trusty. Assuming the binaries work, I think we can symlink generic versions to specific versions in a way that is useful to many:
-travis-linux-trusty/xenialif you want to be specific. Rename current recipes.-travis-linuxpointing to the latest default Travis distribution.-travispointing to-travis-linuxfor some extra backward compatibility for the people who genuinely don’t care, reducing initial breakage.
Those who currently require Trusty would initially break but have a simple fix. That seems fair. A similar pattern could be used for macOS in future.
The new binaries may also help #107.
If there is an Emacs release where we believe no specialisation is required (for example: the combination of Emacs & our supported Travis dists does not require GnuTLS), we could instead make the specific versions links to a generic version (for consistency).
In addition, any requested features such as modules and threads could be added to re-issued binaries if they do not add external dependencies. Finally, I’d think source builds with Travis caching could be used by people with more esoteric requirements.
Does that sound reasonable?
Sounds reasonable (based on keeping trusty). Since the versions pre-26 seems to work fine on both platforms, maybe just keep them as is and add just add the symlinks? There are some problems if emacsen is built with newer gnutls so might be that you run into these problems if older versions are rebuilt. See purcell/nix-emacs-ci#8.
Out of interest, the extra linux symlink. Are there plans for supporting more platforms?
Sounds reasonable (based on keeping trusty). Since the versions pre-26 seems to work fine on both platforms, maybe just keep them as is and add just add the symlinks?
Yes, exactly. I edited my comment to say exactly that - there may be periods of time where there are no real differences between the binaries (most notably if there is no need to link any dependencies at all).
There are some problems if emacsen is built with newer gnutls so might be that you run into these problems if older versions are rebuilt. See purcell/nix-emacs-ci#8.
The history of TLS support has been complicated:
- the Emacs code/defaults changed several times, (with several bugs IIRC)
- various Emacs versions/configurations were not actually verifying certificates properly, even if they appeared to be
- Emacs was often implicitly dependent on the external
gnutls-bincommand. - sometimes ELPA repositories actually had incorrect certificates
I decided to build with --with-gnutls precisely due to the lack of reliability around this - on Trusty, it fixes everything on 26.x without requiring any patching of Emacs or the user to install extra packages in their CI. I'm not sure if the Nix version is actually building with --with-gnutls. That issue says that the problem is only with older versions. I would feel a little nervous about patching Emacs itself for a CI binary - the opportunity to get passing CI and failures for users seems too high. The workaround used in EVM just saves people from installing gnutls-bin on their CI, but for users this is commonly installed anyway.
Out of interest, the extra
linuxsymlink. Are there plans for supporting more platforms?
As I said, the same system could be used for macOS. There are no concrete plans but it has been requested in the past.
My undestanding is that not patching emacs (before 27) could expose this emacs bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341
Seems to be only triggered with gnutls 3.6 or higher so for xenial this may be a non issue.
Indeed, there is no intention to build with GnuTLS 3.6 anyway.
More generally, my concern is:
- a library using EVM for CI is hitting a bug
- a fix is applied to the EVM binary
- the library thinks that everything is fine
- library users have binaries without the fix backported
It may be correct for the library to workaround the problem instead. I guess there's a chance that a large percentages of distros also backport the fix, which may remove this concern.
Please try the Xenial binaries. Aliases and some better HTTPS testing will have to wait a bit.
I tried setting up a travis job with these new EVM options, but got a 404:
https://travis-ci.org/emacs-typescript/typescript.el/jobs/588631306
Silly typos when switching to the real release URL. Please try again.
I'm not sure if the Nix version is actually building with
--with-gnutls
Hi! Yes, I'm using that build flag.
I would feel a little nervous about patching Emacs itself for a CI binary - the opportunity to get passing CI and failures for users seems too high.
Indeed, there's a tension between having a CI binary that is easily usable for the majority of testing purposes, and one that faithfully reproduces the broken behaviour of that version in certain circumstances. I'm actually not sure that the latter is universally possible, since older binaries on various systems will have been built with (or will run with) variously old and working/broken versions of GNUTLS, GPG and other tools that Emacs uses.
I think that users who still have, say, Emacs 24.4 in service on their machine will have either a binary that was built with an older GNUTLS, or they will have configured gnutls-cli or package-check-signatures accordingly.
In the nix-emacs-ci case I'm basically doing the least patching that will allow the older Emacsen to install packages from ELPA over HTTPS using the recent GNUTLS. (While older versions used the http ELPA URL, cask uses https unconditionally.) This involves applying patches for the recent E_AGAIN issue that was fixed in 26.3, plus a patch to use the default cert store location for recent OSX versions, and I'll also likely include the latest package signing GPG key rather than the expired historical version.
Silly typos when switching to the real release URL. Please try again.
Works now. Thanks.
I think the git snapshot still doesn't work on xenial, right?
No, I have new snapshots (both distros) ready that I intend to upload later. Possibly the unqualified snapshot will soon point at Xenial. This will let me see how much feedback there is that it broke for people on Trusty without making that switch for the unqualified, versioned releases.
They are up now, per #130.
Tested and works. Thanks!