New package: zed-0.140.5
Testing the changes
- I tested the changes in this PR: briefly
New package
- This new package conforms to the package requirements: YES
Local build testing
- I built this PR locally for my native architecture, (x64-GlibC)
Just me making a PR for Zed, it's evolving fast, the PR is not ready, but the template does work. This PR's purpose is for others to keep track of the tests i'm doing.
Take care, i'm all ears for suggestions of course. :v:
ah also, checks will fail. For some reasons the checks require a certain font to be install, on the IRC (thanks to the ones who helped me, you guys rock) we made tests with xorg-fonts nothing promising atm.
Also i noted the duplicate (https://github.com/void-linux/void-packages/pull/49019#issuecomment-2087960452) but i'm willing to continue the great work made by the original request author.
To the author, your work helped me a lot for this, thank you.
template dir and pkgname should be the same case
template dir and pkgname should be the same case
wait i forgot to upload my new template, my mistake.. It should be better in a while
There is something seriously wrong with their .desktop file at upstream.
It doens't work on plasma, no reasons given. When in dolphin, there's a warning next to it:
(screenshot taken on my main pc, where zed isn't installed, but the issue remains the same on my laptop where zed is installed).
- I put the exact same content as i did, modifying the base thing: Doesn't work
- Erase the content, replacing it with what i wrote: It works (not a file type issue)
Then i checked the encoding: all good. Made a diff check: nothing is different.
Mine with the same content weights 200 bytes, the other 400 more or less.
desktop-file-validate shows nothing. I'm legit confused.
okay found it: Tryexec entry.
PR made at upstream: https://github.com/zed-industries/zed/pull/12218
exec:zed could be problematic, since it may try running zed the ZFS Event Daemon
If TryExec=zed is failing because it tries to access zed instead of Zed, I don't think that removing TryExec altogether is a good solution. It should be changed to Zed instead.
TryExec does serve a purpose, don't remove it, just fix the case
TryExec does serve a purpose, don't remove it, just fix the case
yep, it's done.
i'm going to rest a bit, thanks everyone for the help today.
You might need to add archs="x86_64-* aarch64-*" because those are the only architectures which wasmtime supports and it seems that there aren't any easy fixes to allow it to run on other architectures beyond disabling extensions at compile time upstream. I'll see if I can get a PR merge which does this.
You might need to add
archs="x86_64-* aarch64-*"because those are the only architectures which wasmtime supports and it seems that there aren't any easy fixes to allow it to run on other architectures beyond disabling extensions at compile time upstream. I'll see if I can get a PR merge which does this.
Hey !
Yeah ngl we thought abt the same thing. I was working on it on a local repo but since yesterday i didn't have the time to finish that. Imma see what i can do to finish today.
I'll see if I can get a PR merge which does this.
Keep me in touch on that !
I'll see if I can get a PR merge which does this.
Keep me in touch on that !
Actually, thinking about it some more, cutting out wasmtime would mean cutting out all tree sitter and lsp support, so it’s a none starter. May as well disable builds for armv6l and 7l. i686 support might be fixable.
Alright, i found a solution for the checks, i think.
Turns out that xorg-font didn't include the required fonts (either Courier or any of the fallbacks: Zed Mono, Helvetica, Cantarell, Ubuntu, Noto Sans), so i installed noto-fonts-ttf as a checkdep. It solves the check for my arch, i hope it will work as well for aarch64.
What do you guys think ?
Shouldn't it wait until Zed is releasing stable builds for linux? They only are shipping preview builds at the moment.
Shouldn't it wait until Zed is releasing stable builds for linux? They only are shipping preview builds at the moment.
I can maintain the PR until then i guess. Looks stable-enough for my personal usage.
would it make sense to depends="git noto-fonts-ttf" ?
If it needs some of the fonts for do_check, it probably needs them at runtime too
looking at the upstream, i see the bundle-linux script bundling something called cli
cargo build --release --target "${target_triple}" --package zed --package cli
not sure what this cli thing is, why it exists or if it is needed
looking at the upstream, i see the bundle-linux script bundling something called
clicargo build --release --target "${target_triple}" --package zed --package clinot sure what this
clithing is, why it exists or if it is needed
It lets you do some nifty things from the command line in terms of workspace management, but you can totally run without it.
looking at the upstream, i see the bundle-linux script bundling something called
clicargo build --release --target "${target_triple}" --package zed --package clinot sure what this
clithing is, why it exists or if it is neededIt lets you do some nifty things from the command line in terms of workspace management, but you can totally run without it.
in that case it should probably be part of the package.
might want to rename the binary to something else though
would it make sense to
depends="git noto-fonts-ttf"?If it needs some of the fonts for
do_check, it probably needs them at runtime too
Nope. Zed Mono and Zed Sans are embedded into the binary. The tests need the other font however because the builtin ones aren't available for the tests.
Edit: wrong link
in that case it should probably be part of the package. might want to rename the binary to something else though
I think it would be best to leave it out. One of the devs also said they were considering merging their functionality into a single binary so it wouldn't make much sense if its just going to get removed anyways.
would it make sense to
depends="git noto-fonts-ttf"?If it needs some of the fonts for
do_check, it probably needs them at runtime too
Well tbf i don't think so, lemme explain:
Zed by default will bring its own font, Zed. At this point the end user can switch to another font if they want to.
Only problem is, checks don't seem to detect that said font for some reason...
in that case it should probably be part of the package. might want to rename the binary to something else though
I think it would be best to leave it out. One of the devs also said they were considering merging their functionality into a single binary so it wouldn't make much sense if its just going to get removed anyways.
Let's see what they planned. I guess it's another reason why we shouldn't ship Zed into the repos, right now.
Only problem is, checks don't seem to detect that said font for some reason...
Because it’s only embedded in release builds. See https://docs.rs/rust-embed/latest/rust_embed/trait.RustEmbed.html