-
-
Notifications
You must be signed in to change notification settings - Fork 757
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
textures broken on NixOS master branch #5990
Comments
Try |
Oh, cool! I had no idea that was added. Unfortunately, it gives me about the same effect as trying other versions from nixpkgs branches:
Incidentally, I found this issue also mentioned by the folks over at nixpkgs. SuperSandro2000's workaorund of But since the underlying problem is still there, I'll keep this issue open to track it. |
@crabdancing What I'm doing in the meantime is That's general advice btw: if a regular pkg breaks on unstable, you can always try to run the one from the currently stable channel. |
Yeah, that's not bad advice! I have quite a few packages in my
|
I fixed this error linking the wezterm' flake input the same as my primary nixpkgs:
|
sorry for the noob question, but how do I pass the I have tried the following, but unfortunately it didn't work for me.
And in my darwin.nix (snippet of it...)
I got the error
|
You're pretty close! It looks like it would be Edit: I wrote up a quick tutorial and put it here if you wanna figure out how you can find out this stuff. :3 |
@crabdancing this works perfectly, unfortunately I miss the Wezterm.app to start Wezterm from my Mac. Do I need to add some extra settings? |
TBH, I haven't touched a Mac machine in over a decade, and have very little clue how they work, or how |
Any idea what is going on here? Presumably this is an incompatibility with a newer version of GL library? |
|
@fr13ndxd That's odd. I would expect those commands to yield more or less the same result for every user, so this is definitely strange. |
Neither work for me either |
oh, it doesnt work for me anymore after a reboot... |
That is a pretty good indicator that it has something to do with the graphics driver loaded because they are not replaced on updates. So maybe a mesa update broke things? |
Loading the Flake without setting a specific frontend and not disabling wayland gives this output: $> nix run 'github:wez/wezterm/main?dir=nix'
ERROR env_bootstrap > panic at /build/cargo-vendor-dir/wgpu-hal-0.18.1/src/gles/egl.rs:798:88 - called `Option::unwrap()` on a `None` value
0: env_bootstrap::register_panic_hook::{{closure}}
1: std::panicking::rust_panic_with_hook
2: std::panicking::begin_panic_handler::{{closure}}
3: std::sys_common::backtrace::__rust_end_short_backtrace
4: rust_begin_unwind
5: core::panicking::panic_fmt
6: core::panicking::panic
7: core::option::unwrap_failed
8: <wgpu_hal::gles::egl::Instance as wgpu_hal::Instance<wgpu_hal::gles::Api>>::init
9: wgpu_core::instance::Instance::new
10: wgpu::Instance::new
11: wezterm_gui::termwindow::TermWindow::new_window::{{closure}}
12: <async_task::runnable::Builder<M>::spawn_local::Checked<F> as core::future::future::Future>::poll
13: async_task::raw::RawTask<F,T,S,M>::run
14: window::spawn::SpawnQueue::run
15: <window::os::x11::connection::XConnection as window::connection::ConnectionOps>::run_message_loop
16: wezterm_gui::run_terminal_gui
17: wezterm_gui::main
18: std::sys_common::backtrace::__rust_begin_short_backtrace
19: std::rt::lang_start::{{closure}}
20: std::rt::lang_start_internal
21: main
22: __libc_start_call_main
23: __libc_start_main@@GLIBC_2.34
24: _start
thread 'main' panicked at /build/cargo-vendor-dir/wgpu-hal-0.18.1/src/gles/egl.rs:798:88:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Using $> nix run 'github:wez/wezterm/main?dir=nix'
ERROR env_bootstrap > panic at /build/cargo-vendor-dir/wgpu-hal-0.18.1/src/gles/egl.rs:798:88 - called `Option::unwrap()` on a `None` value
0: env_bootstrap::register_panic_hook::{{closure}}
1: std::panicking::rust_panic_with_hook
2: std::panicking::begin_panic_handler::{{closure}}
3: std::sys_common::backtrace::__rust_end_short_backtrace
4: rust_begin_unwind
5: core::panicking::panic_fmt
6: core::panicking::panic
7: core::option::unwrap_failed
8: <wgpu_hal::gles::egl::Instance as wgpu_hal::Instance<wgpu_hal::gles::Api>>::init
9: wgpu_core::instance::Instance::new
10: wgpu::Instance::new
11: wezterm_gui::termwindow::TermWindow::new_window::{{closure}}
12: <async_task::runnable::Builder<M>::spawn_local::Checked<F> as core::future::future::Future>::poll
13: async_task::raw::RawTask<F,T,S,M>::run
14: window::spawn::SpawnQueue::run
15: <window::os::wayland::connection::WaylandConnection as window::connection::ConnectionOps>::run_message_loop
16: wezterm_gui::run_terminal_gui
17: wezterm_gui::main
18: std::sys_common::backtrace::__rust_begin_short_backtrace
19: std::rt::lang_start::{{closure}}
20: std::rt::lang_start_internal
21: main
22: __libc_start_call_main
23: __libc_start_main@@GLIBC_2.34
24: _start
thread 'main' panicked at /build/cargo-vendor-dir/wgpu-hal-0.18.1/src/gles/egl.rs:798:88:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
panicked at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/thread/local.rs:262:26:
thread panicked while processing panic. aborting.
zsh: IOT instruction (core dumped) nix run 'github:wez/wezterm/main?dir=nix Using $> nix run 'github:wez/wezterm/main?dir=nix'
ERROR wezterm_gui::frontend > Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory, with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory Just with $> nix run 'github:wez/wezterm/main?dir=nix'
ERROR wezterm_gui::frontend > Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory, with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory |
Oh, very interesting. As mentioned by davidsierradz it works if you include WezTerm as a flake but let it use the system's nixpks. Then you no longer need this configuration in front_end = "WebGpu",
enable_wayland = false, It then doesn't matter whether you didn't specify System Flake: {
description = "Your NixOS Flake";
inputs = {
# Official NixOS package source, using nixos-unstable branch here
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
# custom flakes
wezterm = {
url = "github:wez/wezterm/main?dir=nix";
inputs.nixpkgs.follows = "nixpkgs";
};
# …
};
outputs = { self, nixpkgs, ... } @inputs:
# more configuration
} configuration.nix: environment.systemPackages = with pkgs; [
# custom remote flakes
inputs.wezterm.packages.${pkgs.system}.default
# official system packages
# …
]; Here are the current revisions for my nixpkgs and WezTerm from the metadata of my system flake. $> nix flake metadata
├───nixpkgs: github:NixOS/nixpkgs/8a3354191c0d7144db9756a74755672387b702ba
└───wezterm: github:wez/wezterm/30345b36d8a00fed347e4df5dadd83915a7693fb?dir=nix
├───flake-utils: github:numtide/flake-utils/b1d9ab70662946ef0850d488da1c9019f3a9752a
│ └───systems: github:nix-systems/default/da67096a3b9bf56a91d16901293e51ba5b49a27e
├───freetype2: github:wez/freetype2/e4586d960f339cf75e2e0b34aee30a0ed8353c0d
├───harfbuzz: github:harfbuzz/harfbuzz/63973005bc07aba599b47fdd4cf788647b601ccd
├───libpng: github:glennrp/libpng/8439534daa1d3a5705ba92e653eda9251246dd61
├───nixpkgs follows input 'nixpkgs'
├───rust-overlay: github:oxalica/rust-overlay/b7996075da11a2d441cfbf4e77c2939ce51506fd
│ └───nixpkgs follows input 'wezterm/nixpkgs'
└───zlib: github:madler/zlib/cacf7f1d4e3d44d871b605da3b647f07d718623f @rgruyters Before WezTerm broke during an attempted update of nixpkgs, my system flake was at revision Before davidsierradz' workaround to use Wezterm directly from the repo as a flake, I simply used the WezTerm package directly from the revision I knew to be working in the system packages, like this: environment.systemPackages = with pkgs; [
# packages from a specific nixpkgs version
(import
(builtins.fetchTarball {
url = "https://github.com/NixOS/nixpkgs/archive/957d95fc8b9bf1eb60d43f8d2eba352b71bbf2be.tar.gz";
sha256 = "sha256:0jkxg1absqsdd1qq4jy70ccx4hia3ix891a59as95wacnsirffsk";
})
{ inherit system; }).wezterm
# official system packages
# … (invalidate sha256, Usually, previous package versions can be found with this website for Nix package versions. Since WezTerm must be very closely coordinated with the graphics driver in this case, the versions listed on the website unfortunately didn't work either. So I stuck with the revision I knew, which worked as long as I didn't activate |
We now collected all workarounds and downgrades. Please don't double post them. Also I am unwilling to provide any support when using https://lazamar.co.uk/nix-versions, as it is basically a very big hack. Please keep this issue on topic. |
I have run into the same issue; setting config.front_end = "WebGpu" fixed it for me. Let me know if any logs or other information would be useful to you, and I can provide it. |
I have two MacOS and one NixOS machines which build from different host definitions of the same flake (albeit with some branching config per-host), and I have hit this issue today on all three machines after a |
@eblume for what it's worth, updating my nix-darwin stuff today caused me to run into this also. I have no linux+nix machines, just an arm mac. |
Changing |
That was already bumped to 0.34 in 36ff6d5 and for me the issue also exists for nightly. |
Then the issue I observe must be somewhat different, as I don't have it in nightly. |
… 0x0.st instance for file upload
For me this issue got fixed on nixos-unstable without any changes to Wezterm. Maybe a mesa/driver update? |
As of this morning, the issue still persists for me on MacOS Sonoma 14.6.1 (aarch64) using nixos-unstable. |
The issue still persists on Plasma 6 and nixos-unstable for me.
|
Fixes the font rendering issues on master. wez/wezterm#5990
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
kwin 6.1.4 (NixOS)
WezTerm version
wezterm 20240203-110809-5046fc22
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
No, and I'll explain why below
Describe the bug
Wezterm no longer displays meaningful characters. All characters are rendered as blocks.
To Reproduce
Configuration
Expected Behavior
Expected to display meaningful characters, not blocks
Logs
N/A
Anything else?
Methodology & notes
/run/user/1000/wezterm
, and then re-closing and re-opening wezterm, there are still no logs in the directory -- just socket files & X11 symlink.wezterm
stock. This did not work either.Since
wezterm ls-fonts
might be relevant, here you go:Screenshots
After typing some random commands:
Emoji picker:
Versioning constraints
Did not try nightly because Wezterm does not have a Nix flake, and thus, is difficult to run nightly without writing a custom overlay. I have however tried building & running the version shipped by nixpkgs master (
nix run 'nixpkgs/master#wezterm'
) to the same effect. Earlier versions do not seem to work, though:The text was updated successfully, but these errors were encountered: