New package: zed-0.156.1

[SpidFightFR]

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. ✌️

[SpidFightFR]

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.

[SpidFightFR]

Also i noted the duplicate (#49019 (comment)) 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.

[classabbyamp]

template dir and pkgname should be the same case

[SpidFightFR]

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

[SpidFightFR]

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.

[SpidFightFR]

desktop-file-validate shows nothing. I'm legit confused.

[SpidFightFR]

okay found it: Tryexec entry.

[SpidFightFR]

PR made at upstream: zed-industries/zed#12218

[Calandracas606]

exec:zed could be problematic, since it may try running zed the ZFS Event Daemon

[meator]

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.

[classabbyamp]

TryExec does serve a purpose, don't remove it, just fix the case

[SpidFightFR]

TryExec does serve a purpose, don't remove it, just fix the case

yep, it's done.

[SpidFightFR]

Any idea why the aarch64 build fails ? It looks like mold's presence and llvm regardless of the versions, don't help...

[someone13574]

Any idea why the aarch64 build fails ? It looks like mold's presence and llvm regardless of the versions, don't help...

Just patch .cargo/config.toml to not use clang as the linker. The reason it uses mold in clang in the first place was that it was slightly faster to compile.

[build]
# v0 mangling scheme provides more detailed backtraces around closures
rustflags = ["-C", "symbol-mangling-version=v0", "--cfg", "tokio_unstable"]

[alias]
xtask = "run --package xtask --"

-[target.x86_64-unknown-linux-gnu]
-linker = "clang"
-rustflags = ["-C", "link-arg=-fuse-ld=mold"]

-[target.aarch64-unknown-linux-gnu]
-linker = "clang"
-rustflags = ["-C", "link-arg=-fuse-ld=mold"]

# This cfg will reduce the size of `windows::core::Error` from 16 bytes to 4 bytes
[target.'cfg(target_os = "windows")']
rustflags = ["--cfg", "windows_slim_errors"]

Relevant PR: zed-industries/zed#12944

---

If you want to continue using clang, you might need to have the clang package as well (not 100% sure if this is correct).

[Calandracas606]

if you want to use clang, it will need to go in hostmakedepends

currently it is only in makedepends, as it is being pulled in by llvm18-devel

[SpidFightFR]

I guess, Except if we have a reason not to use clang, we can always add it ?

Or should i take the minimalist route and get rid of it? What would be the preferred choice for void maintainers?

EDIT: also if llvm18-devel pulls clang, if i need clang in hostmakedepends, can i just move llvm18-devel there? Or should I pull clang entirely?

[Calandracas606]

I guess, Except if we have a reason not to use clang, we can always add it ?

I don't see a reason not to. it's simpler to include clang and mold rather than to patch it out. probably improves build times quite a bit. gnu ld is very slow compared to mold, especially when linking large static binaries (rust)

Or should i take the minimalist route and get rid of it? What would be the preferred choice for void maintainers?

I'm not a maintainer, this is my personal opinion: void is not a "minimal" distro. having clang in hostmakedepends is fine.

also if llvm18-devel pulls clang, if i need clang in hostmakedepends, can i just move llvm18-devel there? Or should I pull clang entirely?

If clang is only needed as a compiler, it's best to simply put clang18 in hostmakedepends, and remove llvm18-devel. generally, you only need llvm18-devel when building project which links against libllvm, or needs other low level llvm tooling.

its possible that zed does need llvm, in that case you would put back llvm18-devel

[SpidFightFR]

Btw how does zed look so far? Would it be suitable for void repos as of today?

[Calandracas606]

again, I'm not a maintainer, this is my personal opinion:

zed is unacceptable until they fix the "downloads binaries without the user's consent" issue

[SpidFightFR]

again, I'm not a maintainer, this is my personal opinion:

zed is unacceptable until they fix the "downloads binaries without the user's consent" issue

That's understandable tbf, even though i'm not completely aware of the issue and its details as of now... Is it through the extension?

[Calandracas606]

again, I'm not a maintainer, this is my personal opinion:
zed is unacceptable until they fix the "downloads binaries without the user's consent" issue

That's understandable tbf, even though i'm not completely aware of the issue and its details as of now... Is it through the extension?

zed-industries/zed#12589

[SpidFightFR]

again, I'm not a maintainer, this is my personal opinion:
zed is unacceptable until they fix the "downloads binaries without the user's consent" issue

That's understandable tbf, even though i'm not completely aware of the issue and its details as of now... Is it through the extension?

zed-industries/zed#12589

Damn so that was it!
I use zed at work, and as part of the IT team, i noticed the EDR flagged zed because of node.

I thought it was a false positive (and it is in a way) but it's zed doing stuff in the background...!

[SpidFightFR]

I added cmake to the hostmakedepends list, as the absence of it makes this error:

error: failed to run custom build command for `wasmtime-c-api-impl v24.0.0`

Caused by:
  process didn't exit successfully: `/builddir/zed-0.154.2/target/release/build/wasmtime-c-api-impl-b5ca9d93c2559904/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=cmake/features.cmake
  cargo:rerun-if-changed=cmake/install-headers.cmake
  cargo:rerun-if-changed=include

  --- stderr
  thread 'main' panicked at /host/cargo/registry/src/index.crates.io-6f17d22bba15001f/wasmtime-c-api-impl-24.0.0/build.rs:41:33:
  failed to spawn `cmake`: Os { code: 2, kind: NotFound, message: "No such file or directory" }
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...