-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Generate a .deb file #12453
Generate a .deb file #12453
Conversation
Brilliant! I tried it on Debian Trixie and it worked perfectly, desktop and bash completion work great. I used a fresh VM that had not had Rust or Helix on it, installed Rust and The only problem seems to be the error messages regarding the grammars. They all seem to be working/present and correct inside Warning: Failed to find dependency specification. PS Debian is built for Trixie officially and just waiting in the new queue before it passes into testing: https://salsa.debian.org/debian/hx |
Yeah, this only LOOKS scary. It would be suppressed by adding It is late for me here, but if I have some time tomorrow, I will make another commit to the workflow to really have the .deb generated during the release process. |
Well, the recommended way is to But for some reason, maybe some maintainer can explain here to me, in the official release workflow helix/.github/workflows/release.yml Line 159 in 917174e
helix doesn't use this --profile opt , I wonder why. Is it not recommended anymore? If not, it should be taken out of the manifest and the building-from-source.md
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition to what all ready exists.
Thanks for making cargo deb
possible.
649dca9
to
57f6279
Compare
Today's commit adds the Deb build step to the CI workflow and it successfully produces the file at the end of the release! I still think the optimizations in the opt profile are good and should be used in the release profile, but that is a separate issue. The publish step doesn't complete here because $GITHUB_REF_NAME looks like 12453/merge instead of a version tag. All pull request triggered publish steps fail when telling tar about the directory 12453.../ that doesn't exist. I might look into solving that too if I find time. |
One thing to note is that the CI-generated |
The highest generated dependencies for this Deb are: libc6 (>= 2.4) and libstdc++6 (>= 5.2) |
Thanks a lot. I was about to ask about glibc dependencies 😃 |
This broke the publish step for all pull request started workflows. Because this tag is used for both creating a directory and creating a tar file.
I am not sure the dependencies will be met on Debian 12:
I think the
Debian 12 is not an old distribution, Debian 13 is not out until this summer. EDIT: See this relevant discussion AppImage : no one works on debian 12 |
@David-Else You are right, that is weird... here on LinuxMint 21.3 (which is on the Jammy base), that has ldd 2.35, but the .deb installed just fine. The full line of the dependency (partially seen in the scrnshot) says:
I am not sure how that works. I assumed all have to pass, that's why I shared the 2.4 previously. But as I said, it installs just fine on Jammy and I would assume it does on Debian 12 as well. |
In the 3rd commit I fixed the workflow publish step for pull requests. So it (and future PRs) can pass if correct. |
Ok, when I run Ok, I didn't want to do this, but I will set the dependencies manually to libc6 (>= 2.34) and libstdc++6 (>= 5.2). Build it again in the helix workflow and test again on my VM. If that doesn't work, we will have to wait till helix downgrades the ubuntu image for releases. A PR is already out for that #12464 |
So I was able to install the deb with the manually setup dependencies, but it wouldn't work
The good news is, that the cargo-deb automatic dependency resolution works really really well as I can see. |
Please elaborate in on "and then just ran Update:
Update 2:
Plan: sleep first and further follow-up later, the follow-up might be deleting this comment. |
You don't even have to go to the helix-term, you can run it directly from the root helix folder workspace, because helix-term is defined as the default-members. So...
And either a)
or b) equivalent
or c) for the most optimal binary (I really hope they update their release mode)
And run the resulted .deb from the target/debian/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have made some changes to hopefully improve the wording and clarity of the documentation. I hope I didn't change any of the meaning of what you wrote, please give it a good look as I don't know much about packaging and the rust build system.
Co-authored-by: David Else <[email protected]>
Co-authored-by: David Else <[email protected]>
Co-authored-by: David Else <[email protected]>
Co-authored-by: David Else <[email protected]>
Co-authored-by: David Else <[email protected]>
Co-authored-by: David Else <[email protected]>
@the-mikedavis I guess it will take a while to get a hold of @archseer right? |
I'm OK with the extra metadata in Cargo.toml, but I'd personally prefer we didn't build custom releases for a couple blessed platforms. I was hoping we'd have official packages available but the work is currently still ongoing (kudos to @jonassmedegaard for the effort!) So my stance is, we can support |
Cargo.toml
Outdated
[profile.release] | ||
lto = "thin" | ||
# debug = true | ||
|
||
[profile.opt] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to keep two profiles: --release
is intended for quick builds of develop, and is what anyone running from develop
is using. These users will be the first to encounter bugs so we deliberately keep the backtraces on so we get usable bug reports. I also often use --release
several times per day/when testing because debug builds are much less performant.
Release builds should use --opt
to build the smallest and most performant binary, at the expense of lengthy compile times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so from the current PR, I will rename release
to opt
in both the manifest and the release CI.
I will keep a release
profile in the manifest as it was before, with just thin lto and without strip. I hope I understood you correctly there. I am glad that the release CI will use an optimized build from now on. Even though it will not be called "release".
we can support .deb releases until they're available on distributions, at which point we'll remove them
Why remove them? If Helix makes it to the Debian and Ubuntu repositories and you remove .deb from the releases, the users would have to stay on an old repository version without enjoying any of the updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, that's actually a good catch, the release CI was definitely intended to use --profile opt
, must have been oversight.
Why remove them?
I prefer to hand off packaging to distributions if we can because it's just another maintenance burden. e.g. if cargo deb
becomes out of date or unmaintained. We've already had issues with cross compilation before because the cargo-cross
images we were using were a couple years out of date with no upstream updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cargo-deb
is a dependency, that's true. Non the less I hope you can keep shipping these DEBs as long as possible. It is the best way how to install software of this kind on Debian, Ubuntu, Mint, etc.
I made the profile name changes as you wished. I still think release
should be final and the current release profile feels more like "testing", but whatever. I am happy that Helix now ships an even more performant binary 🚀️ and a well integrated Deb ❤️
I tested this latest build on Mint21 and it seams fine 👍️
If you are ok with it, merge away ^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like once Debian adds Helix, we might find ourselves back at square one for getting the latest version through Homebrew. Oh well! 🙄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like once Debian adds Helix, we might find ourselves back at square one for getting the latest version through Homebrew. Oh well! 🙄
I never used homebrew on linux and I don't plan on starting!
I really hope archseer keeps this DEB around while cargo-deb still works.
There is also the PPA maintained by Maveonair. It's just that Helix set a rust-version (in manifest) that is newer than LTS Ubuntu and so it can't be built anymore on launchepad. That was actually the cause that pushed me to make this DEB build. If Helix keeps a relatively old rust-version in the manifest, we could still get the package through the PPA.
Based on the suggestion from archseer, the release build will use opt. The release profile will be separate for testing purposes.
Co-authored-by: Michael Davis <[email protected]>
This issue might be relevant |
This PR makes it possible to generate a fully working .deb file with a one line command, thanks to
cargo-deb
which is a prerequisite for running it.The .deb integrates well into a debian/ubuntu based system
Tested installing in a VM on Mint21.3 and all looks well!
If the maintainers agree, a
cargo-deb
could be added to the release workflow to generate the .deb.Update:
Part of this PR is the integration into the CI to generate the .deb with every build (commit 2)
And fixing the workflow to complete runs initiated by PRs like this one (commit 3)