Closed sambrightman closed 6 years ago
The main issue I think is that by default you get a lot of crap when building Emacs that requires dependencies. You are welcome to change this if you find something that works.
I believe these contribution instructions were likely made in the interest of reducing build times and complexity. Hopefully @DamienCassou can confirm this?
--without-all
was introduced way before I rewrote the instructions. I just copied this part.
Ok I will have a go at rebuilding the snapshots and reissuing them with TLS support. I’ll want to see if it makes the build harder and whether it fixes common issues.
Well, this has been an interesting journey. Add GnuTLS support does not seem to overly complicate the build, and I'll file a PR to update the instructions once the below adventures are confirmed to be over:
gnutls-available-p
is simply broken for GnuTLS <3, returning nil
. Rather annoying. New releases will need to move forward in addition to adding the config option.Once confirmed/fixed, will proceed. Currently fixing only 1) will pop up the interactive network security manager, which is only worse than a quick fail.
Regarding the second issue listed above... I noticed the same thing when working on a Travis CI setup in the clojure-emacs/cider
project. For now it's being handled with a custom script that downloads and compiles a more modern gnutls
from sources.
See https://github.com/clojure-emacs/cider/pull/2128
And the current version of the install-gnutls.sh script for reference. Note that cider
is configured such that the directory containing the compiled version of gnutls is cached by Travis CI between builds. There's logic in the script to skip building if a suitable version is already found at that path.
I’m in touch with gnu.org sysadmins. Hopefully it will be fixed.
Ok, I’ll keep watching these tickets for news. I’d like to back out the gnutls-bin in Travis for those projects where I’ve introduced it.
Yeah, I don't think that's the way forward. I also added it in a couple of places, and subsequently also had problems that I think were possibly due to it (looked like files had been cut-off half-way through download). It shouldn't be a requirement for all users to add that.
@gonewest818 I believe the issue with elpa.gnu.org is fixed now.
I'll wait for confirmation of #103 being fixed, then proceed with this and #102.
Good to hear. Did the FSF server admins make an announcement of that change somewhere?
Not sure what the appropriate place would be but I was CCd on this: http://lists.gnu.org/archive/html/bug-gnu-emacs/2018-02/msg00774.html after pointing them at this: https://community.letsencrypt.org/t/incorrect-order-and-extra-certificate-error/8759/2
Mailing list is good enough! I just used the same link in another ticket elsewhere. Thanks.
On Feb 20, 2018, at 1:54 PM, Sam Brightman notifications@github.com wrote:
Not sure what the appropriate place would be but I was CCd on this: http://lists.gnu.org/archive/html/bug-gnu-emacs/2018-02/msg00774.html http://lists.gnu.org/archive/html/bug-gnu-emacs/2018-02/msg00774.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rejeep/evm/issues/101#issuecomment-367133517, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWM9ppJUFyS1tFXdPiFyDlRLX-RahXMks5tWz8ogaJpZM4RqW6Z.
I believe these contribution instructions were likely made in the interest of reducing build times and complexity. Hopefully @DamienCassou can confirm this?
I also believe- but am not confident - that adding TLS support would reduce issues being seen, especially with Emacs 26+. If so, we should re-issue the pretest/snapshot releases (seems totally acceptable for unofficial releases) before a full 26 is released in a way that causes people to struggle or use workarounds. I’ve been installing gnutls-bin in some Travis builds already and that is probably a less than ideal path forward.