Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#2120] fix TLS related errors in Travis CI #2128

Merged
merged 1 commit into from
Dec 11, 2017

Conversation

gonewest818
Copy link
Contributor

Fixes the Travis CI build errors reported in #2120.

Diffs to .travis.yml are as follows:

(1) I've added some explicit package dependencies into addons.apt.packages. This is basically the compiler toolchain needed to build gnutls from source

(2) Configured $HOME/local to be cached by Travis between subsequent builds. This is done with the setting cache.directories.

See Travis documentation for further information about the caching of data. Basically, the contents of that folder are rolled up into a tar ball and saved to an S3 bucket whenever the contents change. The tarball is retrieved and installed prior to the start of your CI job.

(3) Added a utility script named travis-ci/travis-gnutls.sh which handles the downloading and compiling of the sources.

The script is organized so that the version of gnutls can be easily updated whenever needed. Just edit the version numbers in that script and push the change. The script is able to detect when it doesn't have the specific version requested, and when that happens it deletes the cache and rebuilds gnutls.

(4) While I was at it, I added emacs 25.3-travis and 26-pretest-travis to the build matrix. Note that git-snapshot-travis now reports itself as being version 27. (Also note, emacs 26 and 27 are still broken builds, but at least now it's not because of the build script itself.)

global:
- PATH=$HOME/local/bin:$PATH
matrix:
- EMACS_BINARY=emacs-24.4-travis MAKE_TEST=test
Copy link
Member

@xiongtx xiongtx Dec 14, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bbatsov Magit recently announced that it will stop supporting Emacs 24.4. Perhaps we can do that as well after the next release; the test matrix is getting rather large.

@tarsius any reason you've decided to stop supporting Emacs 24.4 recently? Emacs versions don't have a formal EOL AFAIK.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking when it comes to bugfix releases, we should have in the matrix just the most recent. The matrix is indeed pretty big already.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually I will have to do it anyway. For the upcoming release I have concentrated on doing many things that don't require major refactorings and new abstractions. After the release I will concentrate on things that are new abstractions that depend on features only available in > 25.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do older Emacs versions even get any fixes? Or is it fix-forward only? Since CIDER is an Emacs package, we should maintain support only to the extent that Emacs does, and no more.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once or twice every decade a security fix is backported. Or not - the latest fix only resulted in the release of 25.3, but I don't know if that's because 24 wasn't affected or because it is no longer supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants