Update to nvim v0.8.1?
liuhaowen478 opened this issue · 22 comments
I'm trying to package LunarVim so that it depends on this nvim snap and LunarVim requires nvim to be up to date. My other option would be to independently package nvim and include it in the lunarvim snap, but I feel like I'm duplicating the effort.
If you can let me know what you want help with, I can also help with this repo so that people using this snap can also benefits from my work, not just those interested in lvim.
I believe the team is currently seeking individuals to help maintain the snap. I no longer use the snap, so I am not a useful datapoint for the maintenance of this snap. Reach out to the core team on Gitter and tag me, hopefully if everyone is in agreement you can become a maintainer.
Gotcha! Will do now!
@liuhaowen478 thanks for the help! Some recent info is in
- #11 treesitter appears to be an unresolved issue for packaging the snap
- neovim/neovim#14800 is a long discussion, can skip most of it and start with the end: neovim/neovim#14800 (comment)
Thanks so much for the information!
To make sure I'm getting the correct picture, currently:
- We are using Travis to check on each commit whether a nightly deployment is necessary
- If so, Travis will trigger a webhook with a payload specifying this repo as the one to build
And we, or at least @justinmk, want to:
- Do away with Travis and move the above job to GHA.
- Move this repo to the
snapdirectory of the main directory and phase out this repo.
I agree that this would simplify a lot of things.
Obviously please correct me if the above is wrong. But the below is what I currently don't understand:
- What is the current
snap/snapcraft.ymlin the main repo doing? Is it currently unused and safe to overwrite? - What is the manual release process for stable builds? Or let's say, if I want to get v0.8.1 up there, what should I do? Manually construct a payload and trigger the webhook? How do I obtain the secret?
- Where can I read more about the treesitter thing with snap? Is that an upstream bug with snapd or treesitter or nvim-treesitter?
I just realized I was using the wrong account. Just letting you guys know I'm the same person as @liuhaowen478.
I will check the snap store and all notes and post an update tomorrow.
That will be profoundly helpful. Thank you!
Thanks so much for the information!
To make sure I'm getting the correct picture, currently:
1. We are using Travis to check on each commit whether a nightly deployment is necessary
Yes, at least that use to be the case. I have no clue anymore what is submitting the webhook.
2. If so, Travis will trigger a webhook with a payload specifying this repo as the one to build
Semi accurate. Travis submits an API webhook to snap build service, repo, branch and other details have no effect which repo and branch get build. The snap build service is very limited, you can specify one branch and one repo, in the web interface. The API call have no effect on what gets build.
And we, or at least @justinmk, want to:
1. Do away with Travis and move the above job to GHA.
Not sure if this was the final decision. I believe the conclusion was to keep the build system as is, and do manual releases for non nightly releases. Non nightly releases are a rare occurrence. I believe my suggestion was to move to GHA so as to develop an automated.
2. Move this repo to the `snap` directory of the main directory and phase out this repo. I agree that this would simplify a lot of things.
For the sake of simplifying the architecture I believe that was the suggestion I made.
Obviously please correct me if the above is wrong. But the below is what I currently don't understand:
1. What is the current `snap/snapcraft.yml` in the main repo doing? Is it currently unused and safe to overwrite?
No clue, at this point everything has change so much since the last time I looked at this. I believe that the only way forward is to break things. We also need to find what is triggering builds.
2. What is the manual release process for stable builds? Or let's say, if I want to get v0.8.1 up there, what should I do? Manually construct a payload and trigger the webhook? How do I obtain the secret?
Let me document it and add a readme to my fork.
3. Where can I read more about the treesitter thing with snap? Is that an upstream bug with snapd or treesitter or nvim-treesitter?
I will attempt to fix it. I believe it has to do with the LD_LIBRARY_PATH and the fact that with snaps you mix different versions of libc.
@justinmk should we move this conversation to neovim/neovim since this will be sunset.
Sure LD_LIBRARY_PATH is borked:
hurricane@ubuntudev:~/src/me/neovim-snap$ sudo snapp install nvim_v0.9.0-368-g5eb5f4948-nightly_arm64.snap --classic --dangerou^C
hurricane@ubuntudev:~/src/me/neovim-snap$ sudo snap install nvim_v0.9.0-368-g5eb5f4948-nightly_arm64.snap --classic --dangerous
nvim v0.9.0-368-g5eb5f4948-nightly installed
hurricane@ubuntudev:~/src/me/neovim-snap$ nvim
Starting Neovim: :/var/lib/snapd/lib/gl:/var/lib/snapd/lib/gl32:/var/lib/snapd/void
More related info: microsoft/vscode#155094
Yes, at least that use to be the case. I have no clue anymore what is submitting the webhook.
It seems to me to still be the case.
Semi accurate. Travis submits an API webhook to snap build service, repo, branch and other details have no effect which repo and branch get build. The snap build service is very limited, you can specify one branch and one repo, in the web interface. The API call have no effect on what gets build.
Interesting. Then why does snapcraft need such a complicated payload tho? It sounds that it only needs a project ID and some sort of authentication token.
Not sure if this was the final decision. I believe the conclusion was to keep the build system as is, and do manual releases for non nightly releases. Non nightly releases are a rare occurrence. I believe my suggestion was to move to GHA so as to develop an automated.
Sounds good. I can certainly look into automating stable builds as soon as I get v0.8.1 and lunarvim up there.
No clue, at this point everything has change so much since the last time I looked at this. I believe that the only way forward is to break things. We also need to find what is triggering builds.
Interesting. I'll look more into it.
Let me document it and add a readme to my fork.
Thank you! I'll keep an eye out for that.
I will attempt to fix it. I believe it has to do with the LD_LIBRARY_PATH and the fact that with snaps you mix different versions of libc.
Thank you! That would be very helpful.
@andyliuhaowen
I update my fork of neovim to update to core22, what a mess that is. Anyhow you can see it here:
https://github.com/hurricanehrndz/neovim/tree/update_snap_core22
To release to stable you have to checkout the latest release:
- Execute snapcraft remote-build with the architectures you want to update (login info will be required)
- Log into the snap store and promote the build you wish to release to stable
- Revert to changes to the edge channel
Here is my results:
hurricane@ubuntudev:~/neovim$ snapcraft --use-lxd
Launching instance...
Executed: update sources for nvim (source changed)
Executed: update sources for nvim-wrapper (source changed)
Executed: skip pull patchelf (already ran)
Executed: update overlay for nvim ('PULL' step changed)
Executed: update overlay for nvim-wrapper ('PULL' step changed)
Executed: skip overlay patchelf (already ran)
Executed: update build for nvim ('PULL' step changed)
Executed: skip pull nvim (already ran)
Executed: skip overlay nvim (already ran)
Executed: skip build nvim (already ran)
Executed: restage nvim (required to build 'nvim-wrapper')
Executed: rebuild nvim-wrapper (stage for part 'nvim' changed)
Executed: rebuild patchelf (stage for part 'nvim' changed)
Executed: skip stage nvim (already ran)
Executed: stage nvim-wrapper
Executed: stage patchelf
Executed: prime nvim
Executed: prime nvim-wrapper
Executed: prime patchelf
Executed parts lifecycle
Generated snap metadata
Lint OK:
- classic: Snap confinement is set to classic.
Lint warnings:
- classic: usr/bin/nvim: ELF interpreter should be set to '/snap/core22/current/lib/ld-linux-aarch64.so.1'.
- library: usr/bin/nvim: missing dependency 'ld-linux-aarch64.so.1'.
Created snap package nvim_v0.9.0-nightly-4-g5e33fec93_arm64.snap
hurricane@ubuntudev:~/neovim$ sudo snap install nvim
nvim nvim_v0.9.0-nightly-4-g5e33fec93_arm64.snap
hurricane@ubuntudev:~/neovim$ sudo snap install nvim_v0.9.0-nightly-4-g5e33fec93_arm64.snap --classic --dangerous
[sudo] password for hurricane:
nvim v0.9.0-nightly-4-g5e33fec93 installed
hurricane@ubuntudev:~/neovim$ readelf -p .interp /snap/
bin/ core20/ core22/ lxd/ multipass/ nvim/ README snapcraft/ snapd/
hurricane@ubuntudev:~/neovim$ readelf -p .interp /snap/nvim/current/usr/bin/nvim
String dump of section '.interp':
[ 0] /snap/core22/current/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
I opened a post on the forums:
https://forum.snapcraft.io/t/core22-and-patchelf-wrong-linter-warnings/32822
@andyliuhaowen my core22 is working. What needs to get added is the tree-sitter parsers
I have been playing around with it the past day. Still learning a lot of things, but one thing to note first here is that: for me, core22's ELF interpreter is called ld-linux.so.2 under the $interp_prefix directory. Might need to add that to the interpreter detection part of the script.
Still trying out things with the tree-sitter parsers and GLIBC. I'll follow up here when there's progress.
It is all working now! Checkout the master branch
Additionally the linter is wrong, and the developer has confirmed it.
Wow great! Thank you! I'll keep looking around anyways, so that I might be able to help more in the future.