Closed Hex-4 closed 4 weeks ago
On my Arch-based EndeavorOS, this executable is located in /usr/bin
. Is that the same for you?
@ivan-hc @Samueru-sama Sorry to ping you, but are you aware of any reason why an app in an AppImage may not be able to call a binary which is available in the outer shell? Can this be some $PATH issues? Or is there anything else going on which could cause this?
@Hex-4 try to run kando like this
GDK_BACKEND=x11 kando
On my Arch-based EndeavorOS, this executable is located in
/usr/bin
. Is that the same for you?
NixOS does not use the FHS standard:
which kwin_wayland /run/wrappers/bin/kwin_wayland
try to run kando like this:
Same error.
$ GDK_BACKEND=x11 kando
Running on Linux (KDE on wayland).
Loading settings from /home/hexatron/.config/kando/config.json
Loading settings from /home/hexatron/.config/kando/menus.json
Kando failed to start: Command failed: kwin_wayland --version
failed to inherit capabilities: Operation not permitted
@Hex-4 Maybe try with buldFHSEnv
in your package script?
I think wrapType2
does that already.
https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-appimageTools
Do you have this issue when running other electron appimages in nix?
The Obsidian (which uses Electron) AppImage runs just fine.
The Obsidian AppRun contains this line:
export LD_LIBRARY_PATH="${APPDIR}/usr/lib:${LD_LIBRARY_PATH}"
And in that location the following libraries were added:
libappindicator.so.1
libgconf-2.so.4
libindicator.so.7
libnotify.so.4
libXss.so.1
libXtst.so.6
Can you try this appimage in nix? that one doesn't contain said libraries.
That one works.
Can it be that /run/wrappers/bin
is not in the search path when Kando is run from the AppImage?
It looks like another place that kwin_wayland is located in is /run/current-system/sw/bin/kwin_wayland
Well, maybe /run/current-system/sw/bin/
or /run/wrappers/bin
needs to be added to the PATH? Could anybody try to build the appimage on NixOS and modify the script before so that the paths are added to the PATH before running Kando?
I guess that an export PATH=$PATH:/run/current-system/sw/bin/:/run/wrappers/bin
before this line could be sufficient.
git clone https://github.com/kando-menu/kando.git
cd kando
npm install
npm run package
tools/make-app-image.sh
The app image should then be in out/make/appimage
.
Well, maybe
/run/current-system/sw/bin/
or/run/wrappers/bin
needs to be added to the PATH? Could anybody try to build the appimage on NixOS and modify the script before so that the paths are added to the PATH before running Kando?I guess that an
export PATH=$PATH:/run/current-system/sw/bin/:/run/wrappers/bin
before this line could be sufficient.git clone https://github.com/kando-menu/kando.git cd kando npm install npm run package tools/make-app-image.sh
The app image should then be in
out/make/appimage
.
I tried that while attempting to compile the application in a Fedora distrobox (Because Nix doesn't use traditional building methods for packages, and there's already a ticket saying that compiling it on Nix itself is challenging), and I didn't have much success building the package.
There's a issue ticket on Nixpkgs here.
I tried running the path command before running the regular AppImage in the releases section, and it still results in the same thing happening.
Kando is now available as a Nix package: https://search.nixos.org/packages?channel=unstable&show=kando
Does this work for you?
Yep, it works! Looks like the package does some dependency patching and builds directly from source.
Thanks for the help!
Short Summary
Kando fails to start on NixOS Plasma 6 (wayland) with the error
Kando failed to start: Command failed: kwin_wayland --version
, butkwin_wayland --version
worksSteps to Reproduce the Issue
kando
Kando Version
1.2.0
Installation Method
Another method (specify in the comments below)
Desktop Environment
KDE on Wayland
Environment Version
KDE Plasma 6.1 on NixOS unstable (24.11)
Additional Information
Installed by adding AppImage to home-manager config. When I run the portable executable with
steam-run ./kando
after unzipping I get the same error. Possibly related to #359.