Closed DamienCassou closed 6 years ago
I know that at least 25.3 was built using --without-all
but perhaps this doesn't cover X for some reason?
so it seems:
root@25e97d593866:/# evm install emacs-25.3-travis --use
Successfully installed emacs-25.3-travis
root@25e97d593866:/# emacs --version
/tmp/emacs-25.3-travis/bin/emacs: error while loading shared libraries: libXaw.so.7: cannot open shared object file: No such file or directory
root@25e97d593866:/# ldd /tmp/emacs-25.3-travis/bin/emacs
linux-vdso.so.1 => (0x00007fff92bf9000)
libXaw.so.7 => not found
libXmu.so.6 => not found
libXt.so.6 => not found
libSM.so.6 => not found
libICE.so.6 => not found
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f4e4d0e0000)
libX11-xcb.so.1 => not found
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f4e4cebe000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4e4ccb6000)
libXfixes.so.3 => not found
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f4e4ca8d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4e4c870000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4e4c567000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4e4c19e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4e4bf9a000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f4e4bd96000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f4e4bb90000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4e4d41a000)
Of course, the Travis binaries are intended for Travis so it's not really a priority to make them work elsewhere. That said, I don't really see a drawback to simplifying the build further and making them more widely usable (or perhaps in the future bringing back the -bin
versions for local testing/general use). A slight concern would be anybody depending on auxiliary functions provided in the X components.
I propose re-releasing the 26-pretest version — without further changes (so no GnuTLS support per #101 , no version bump to .91) — and seeing if this works for you. If it does, proceed also with a snapshot. If there are no complaints for a while we can potentially re-release previous releases (also gradually — although I'm leaning against doing this a little). I expect this to work, since my new output is:
travis@9f751859e6dd:~$ ldd /tmp/emacs-26-pretest-travis/bin/emacs
linux-vdso.so.1 => (0x00007fff869da000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f136c48e000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f136c265000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f136c047000)
libanl.so.1 => /lib/x86_64-linux-gnu/libanl.so.1 (0x00007f136be43000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f136bb3d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f136b774000)
/lib64/ld-linux-x86-64.so.2 (0x00007f136c696000)
Re-opening this; can mark as fixed when either the Git snapshot or all versions are confirmed working. Please verify.
I have tested build with gitlab ci and the new no-X Emacs 26 with success. Thank you so much.
For our infrastructure, we need all supported EVM binaries to be built without X. I understand that's quite some work and you might not want to go that direction. I can build all/most/some binaries myself and upload them if you want.
My concern wouldn't so much be about the work involved but about changing past releases and breaking things. Will think about it a bit - maybe @rejeep has an opinion?
I'll anyway issue a new 26 and snapshot regarding #101, and make no-X11 the default going forward.
@sambrightman What is it that you would be breaking?
In principle, it could break something (I've seen people depend on utility functions in unrelated modules), and its rather counter to reproducible builds. Practically speaking, it seems very unlikely and probably worth it to help out people without X.
I don’t understand how the builds are different (the one that was broken versus the one you swapped in with #104). What changed in the build that required backing out?
@damiencassou does Gitlab CI allow customer to provide a docker image for their tests to run? If so, there’s another (arguably cleaner) way to handle your particular test case, which is to compile and run Emacs in an Ubuntu image like Silex/docker-emacs
I don't understand what you don't understand ;)
As described above, --without-all
(recommended way to build Travis binaries from README) doesn't disable X support, so existing binaries have/had it. The build added in #104 has some extra build flags to disable X. It seems like a reasonable way forward regardless of this use-case.
I just meant the commit in #104 doesn't document how the build was configured. For instance, if I wanted to update #102 to contain the proper recipe.
Yes, it's for testing. There are a couple of other things I want to get out before you need to update #102, and we should discuss that in the ticket when the time comes.
I'm leaning towards just re-issuing all the previous binaries, since the risk of breakage seems quite small.
yup, I'm okay to wait on #102.
@DamienCassou does Gitlab CI allow customer to provide a docker image for their tests to run?
it does
If so, there’s another (arguably cleaner) way to handle your particular test case, which is to compile and run Emacs in an Ubuntu image like Silex/docker-emacs
Thanks for the link. Except for the workdir
at the end (which won't exist because gitlab won't mount it), I think we could use this approach and maybe this container.
We are currently using this docker file and this GitLab CI configuration which uses EVM to provide all Emacs versions in the same container. Having only one container with every Emacs version has the advantage of consuming less disk space on the CI runners (I guess).
May I suggest we take that discussion into a ticket in that other project? To keep on-topic here.
On Feb 21, 2018, at 9:14 AM, Damien Cassou notifications@github.com wrote:
@DamienCassou https://github.com/damiencassou does Gitlab CI allow customer to provide a docker image for their tests to run?
it does
If so, there’s another (arguably cleaner) way to handle your particular test case, which is to compile and run Emacs in an Ubuntu image like Silex/docker-emacs
Thanks for the link. Except for the workdir at the end (which won't exist because gitlab won't mount it), I think we could use this approach and maybe this container.
We are currently using this docker file https://hub.docker.com/r/nicolaspetton/emacs-docker and this GitLab CI configuration https://gitlab.petton.fr/mpdel/mpdel/blob/master/.gitlab-ci.yml which uses EVM to provide all Emacs versions in the same container. Having only one container with every Emacs version has the advantage of consuming less disk space on the CI runners (I guess).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rejeep/evm/issues/103#issuecomment-367400444, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWM9pVQb_Upqf7MY8wAhG-FSJAK7rO3ks5tXE8AgaJpZM4SKXvs.
Both new snapshots are using this method, and I have a 25.3 ready to re-release soon. If that doesn't see new issues for a few days I'll do the rest.
Please see #107.
Is it still worth re-releasing earlier releases (without GnuTLS, since it isn't necessary) like this, given the conclusion in #107?
Is it still worth re-releasing earlier releases (without GnuTLS, since it isn't necessary) like this, given the conclusion in #107?
not for me. Thanks for asking.
Okay, well snapshots are updated and build recommendations for the future. We can revisit if necessary.
Is it normal that travis builds require xorg libs? Here is an output from a docker running ubuntu (not related to travis at all):