search

neovim / neovim-snap

snap build for neovim
MIT License
16 stars 7 forks source link

Update to nvim v0.8.1? #15

Closed liuhaowen478 closed 1 year ago

liuhaowen478 commented 1 year ago

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.

hurricanehrndz commented 1 year ago

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.

liuhaowen478 commented 1 year ago

Gotcha! Will do now!

justinmk commented 1 year ago

@liuhaowen478 thanks for the help! Some recent info is in

hurricanehrndz commented 1 year ago

Let me know if you need me to share any accounts

Get Outlook for iOShttps://aka.ms/o0ukef

From: Justin M. Keyes @.> Sent: Monday, November 21, 2022 7:17:53 PM To: neovim/neovim-snap @.> Cc: Carlos Hernandez @.>; Comment @.> Subject: Re: [neovim/neovim-snap] Update to nvim v0.8.1? (Issue #15)

@liuhaowen478https://github.com/liuhaowen478 thanks for the help! Some recent info is in

— Reply to this email directly, view it on GitHubhttps://github.com/neovim/neovim-snap/issues/15#issuecomment-1322925336, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABMJBTKVJHEAKIOYBSOFOPDWJQUNDANCNFSM6AAAAAASHFSTJY. You are receiving this because you commented.Message ID: @.***>

liuhaowen478 commented 1 year ago

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
  2. 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:

  1. Do away with Travis and move the above job to GHA.
  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.

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?
  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?
  3. Where can I read more about the treesitter thing with snap? Is that an upstream bug with snapd or treesitter or nvim-treesitter?
lunacd commented 1 year ago

I just realized I was using the wrong account. Just letting you guys know I'm the same person as @liuhaowen478.

hurricanehrndz commented 1 year ago

I will check the snap store and all notes and post an update tomorrow.

lunacd commented 1 year ago

That will be profoundly helpful. Thank you!

hurricanehrndz commented 1 year ago

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.

  1. 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.

  1. 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:

  2. 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.

  3. 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.

  4. 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.

hurricanehrndz commented 1 year ago

@justinmk should we move this conversation to neovim/neovim since this will be sunset.

hurricanehrndz commented 1 year ago

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
hurricanehrndz commented 1 year ago

More related info: https://snapcraft.io/blog/the-new-classic-confinement-in-snaps-even-the-classics-need-a-change

hurricanehrndz commented 1 year ago

More related info: https://github.com/microsoft/vscode/issues/155094

lunacd commented 1 year ago

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.

hurricanehrndz commented 1 year ago

@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:

  1. Execute snapcraft remote-build with the architectures you want to update (login info will be required)
  2. Log into the snap store and promote the build you wish to release to stable
  3. Revert to changes to the edge channel
hurricanehrndz commented 1 year ago

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
hurricanehrndz commented 1 year ago

I opened a post on the forums: https://forum.snapcraft.io/t/core22-and-patchelf-wrong-linter-warnings/32822

hurricanehrndz commented 1 year ago

@andyliuhaowen my core22 is working. What needs to get added is the tree-sitter parsers

lunacd commented 1 year ago

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.

hurricanehrndz commented 1 year ago

It is all working now! Checkout the master branch

hurricanehrndz commented 1 year ago

Additionally the linter is wrong, and the developer has confirmed it.

lunacd commented 1 year ago

Wow great! Thank you! I'll keep looking around anyways, so that I might be able to help more in the future.