On Sat, Mar 8, 2025, at 10:42 AM, Scott Robbins wrote:
On Sat, Mar 08, 2025 at 06:23:07AM -0800, Michel Lind wrote:
On Fri, Mar 7, 2025, at 2:40 PM, Scott Robbins wrote:
On Fri, Mar 07, 2025 at 04:15:33PM -0500, Scott Robbins wrote:
Spoiler alert--alacritty is solved. User error.
I installed F42 from the nightly builds last night. I almost always choose a minimal install and build from there.
I ran into two issues, both of which I guess are edge cases, since I suspect most people use one of the included desktops. But I tend to install openbox.
The first issue is that I found there is no longer a tint2 rpm. Tint2 is a panel that goes well with openbox. I guess I've been upgrading various installs which is why I didn't notice that there hasn't been a tint2 rpm in a while. (The last I found was from F39, on rpmfind). It installed on the F42 with no problems.
The second issue is the alacritty terminal. I installed from rpm which seemed fine, but when I tried to open it, I got a message of
thread 'main' panicked at /usr/share/cargo/registry/xkbcommon-dl-0.4.2/src/x11.rs:59:28: Library libxkbcommon-x11.so could not be loaded. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
It turns out that I hadn't installed xkbcommon. I was *sure* that I had, but hadn't, once it was installed, alacritty was fine. Sorry to waste people's time.
That still sounds like a packaging bug - any dependency should be explicitly listed rather than implicitly depended on
I suspect xkbcommon is dlopen()ed which is why the RPM build process doesn't automatically flag it as a dependency
Cheers,
I mentioned the issue on Fedora forums, where someone with more knowledge than myself pointed out that rpm -Qr alacritty showed no dependency of libxkbcommon-x11, though strings /usr/bin/alacritty did include a message of "strings /usr/bin/alacritty" included "library libxkbcommon-x11.so could not be loaded"
Looks like this is opened via xkbcommon-dl - which is transitively required via winit (see Cargo.lock). so ... hmm. cc:ing the Rust packaging list to see if we can figure out what's the best way to address this.
https://github.com/search?q=repo%3Aalacritty%2Falacritty+xkbcommon&type=...
Best regards,
On Sun, Mar 9, 2025 at 1:22 AM Michel Lind via Rust rust@lists.fedoraproject.org wrote:
On Sat, Mar 8, 2025, at 10:42 AM, Scott Robbins wrote:
On Sat, Mar 08, 2025 at 06:23:07AM -0800, Michel Lind wrote:
On Fri, Mar 7, 2025, at 2:40 PM, Scott Robbins wrote:
On Fri, Mar 07, 2025 at 04:15:33PM -0500, Scott Robbins wrote:
Spoiler alert--alacritty is solved. User error.
I installed F42 from the nightly builds last night. I almost always choose a minimal install and build from there.
I ran into two issues, both of which I guess are edge cases, since I suspect most people use one of the included desktops. But I tend to install openbox.
The first issue is that I found there is no longer a tint2 rpm. Tint2 is a panel that goes well with openbox. I guess I've been upgrading various installs which is why I didn't notice that there hasn't been a tint2 rpm in a while. (The last I found was from F39, on rpmfind). It installed on the F42 with no problems.
The second issue is the alacritty terminal. I installed from rpm which seemed fine, but when I tried to open it, I got a message of
thread 'main' panicked at /usr/share/cargo/registry/xkbcommon-dl-0.4.2/src/x11.rs:59:28: Library libxkbcommon-x11.so could not be loaded. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
It turns out that I hadn't installed xkbcommon. I was *sure* that I had, but hadn't, once it was installed, alacritty was fine. Sorry to waste people's time.
That still sounds like a packaging bug - any dependency should be explicitly listed rather than implicitly depended on
I suspect xkbcommon is dlopen()ed which is why the RPM build process doesn't automatically flag it as a dependency
Cheers,
I mentioned the issue on Fedora forums, where someone with more knowledge than myself pointed out that rpm -Qr alacritty showed no dependency of libxkbcommon-x11, though strings /usr/bin/alacritty did include a message of "strings /usr/bin/alacritty" included "library libxkbcommon-x11.so could not be loaded"
Looks like this is opened via xkbcommon-dl - which is transitively required via winit (see Cargo.lock). so ... hmm. cc:ing the Rust packaging list to see if we can figure out what's the best way to address this.
https://github.com/search?q=repo%3Aalacritty%2Falacritty+xkbcommon&type=...
I don't think there's a *good* way to handle dlopen'd shared libraries ... *period*. There would be no (feasible) way to inject this dependency based on whether xkbcommon-dl is in the dependency tree or not.
So the best we can do is probably add "Requires" to packages that dlopen stuff on an as-needed basis ... unless it would be possible to do proper linking instead, that is. That's much better supported ...
Fabio
-
Fabio Valentini -
Michel Lind