A high-performance, multiplayer code editor
Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
-
3
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout editors/zed && cd $_ - Create Badge
Refresh
Refresh
Source Files
| Filename | Size | Changed |
|---|---|---|
| _constraints | 0000000206 206 Bytes | |
| _service | 0000000923 923 Bytes | |
| _servicedata | 0000000223 223 Bytes | |
| vendor.tar.zst | 0127199484 121 MB | |
| zed-0.170.4.tar.zst | 0012356199 11.8 MB | |
| zed.changes | 0000218465 213 KB | |
| zed.obsinfo | 0000000094 94 Bytes | |
| zed.spec | 0000004150 4.05 KB |
Comments 7
Regarding the webrtc-sys causing build to fail: I have found a workaround for this. The build can be completed fully offline.
Thankfully, Livekit developers added a custom directory support as a fallback when building webrtc-sys. The gist is to include the SDKs in the build package itself.
Add
LK_CUSTOM_WEBRTCenvironment variable inzed/.cargo/config.tomlto force webrtc-sys to use the pre-downloaded files. Then, determine the arch to use (Zed's patched for x64, Livekit's for arm64) and copy the files to the path set in the environment variable.We can do this without touching Zed or the vendor files by adding the environment variable during build.
I made a branch of the package here for reference: https://build.opensuse.org/package/show/home:hzu/zed
Using pre-built binaries is not an option, we need to wait for upstream to fix this issue or provide a solution that works with sources only.
Looking at webrtc-sys, in the build.rs code, downloading prebuilt binaries is exactly what they do. I don't think they're going to change this any time soon. I'm already looking at another solution.
A second solution I can think of is to download both sources of the webrtc via _service and build those first before before building Zed. Essentially building two at the same time. Or provide them via another package and at to BuildRequires? Then we can point them to Cargo's build env.
Which one do you think is best?
The thing that we need to build is: https://github.com/zed-industries/webrtc
I have managed to build the whole thing completely from source, including WebRTC which takes a whopping 8GB of space (excluding Zed and vendor) when unpacked since as it requires the whole Chromium build toolchain to build it.
You can take a look and see if it's good or if there's any other way: https://build.opensuse.org/projects/home:hzu/packages/zed/repositories/openSUSE_Tumbleweed/binaries
The only thing that I'm still figuring out is why the
depot_toolsisn't working onarm64. I don't have an ARM64 system to debug the build issues, therefore I have decided to disableaarch64in my repository for now.Secondly, since the source takes over 4GB,
rpmlintonopenSUSE:Tumbleweed/standardandopenSUSEL:Factory/snapshotwill always fail as it's not using the most up to daterpmlint. It might be possible to skip it by ignoringrpmlintaltogether in the specfile, which is something I noticed is what the official openSUSE Chromium packages does as well. For now, I have decided to useopenSUSE:Factory/standardas it has the most up to daterpmlintthat supports 4GB.I now understand why they use pre-built binaries of the WebRTC. I highly doubt they will stop downloading pre-built binaries as it requires as much storage to build Chromium itself. I'll keep my repo up to date as long as I use Zed.
https://en.opensuse.org/Zed could do with an update since it talks about using the Factory package that was deleted two weeks ago.
Delete reason, for someone interested as me:
https://build.opensuse.org/requests/1254095
Is it feasible to disable the functionality that depends on webrtc? Just ship the editor without it?