I have created a nix package for Upstream that uses the AppImage to install the compiled version of Upstream. It works fine on the first launch. The problem arises when I launch for a second time. I get the following error:
> nix run ".#radicle-upstream"
(radicle-upstream:2): Gtk-WARNING **: 11:36:25.585: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
Failed to start app
[Error: EACCES: permission denied, copyfile '/nix/store/h5llgxid0nlzazxh2ndyl32h3f52q617-radicle-upstream-0.3.1-extracted/resources/upstream' -> '/home/hagen/.radicle/bin/upstream'] {
errno: -13,
code: 'EACCES',
syscall: 'copyfile',
path: '/nix/store/h5llgxid0nlzazxh2ndyl32h3f52q617-radicle-upstream-0.3.1-extracted/resources/upstream',
dest: '/home/hagen/.radicle/bin/upstream'
}
I digged a little bit, and the file native/index.ts indeed tries to copy two binaries, namely upstream and git-remote-rad to ~/.radicle/bin. When running Upstream for the first time, this works fine as the folder is empty. When running Upstream for a second time, this crashes because the files already exist.
The quick fix for me is to remove those files manually before running Upstream, e.g. rm -rf ~/.radicle/bin. A proper fix might be to check whether the files already exist before copying them. But more fundamentally, why does running Upstream copy binaries to my home folder? I run NixOS, and having binaries in my home folder violates the functional philosophy of the project.
Can someone explain to me why the binaries are copied to ~/.radicle?
Some More Explanations
Nixpkgs, the nix package repository, offers a package for Upstream version 0.3.0 (which most probably also suffers from the problem I describe above). I do not use the nixpkgs package because it installs git-remote-rad. Unfortunately, I also want to install my own package for radicle-cli and get some conflict with git-remote-rad. I instead created a dedicated package for git-remote-rad that I feed to both Upstream and radicle-cli as a dependency.
Ideally, I would compile and install from sources (as is recommended by Nix), but this is not yet possible because Upstream uses some unstable Rust features apparently (as detailed in the nixpkgs package)
Hello Radicle!
Word of Thanks
Thanks a lot for the great work you guys are up to! I think the goal of Radicle is very noble and would love to see this project succeed!
My Problem
I am trying to create nix packages for various Radicle clients as a flake.
I have created a nix package for Upstream that uses the AppImage to install the compiled version of Upstream. It works fine on the first launch. The problem arises when I launch for a second time. I get the following error:
I digged a little bit, and the file
native/index.tsindeed tries to copy two binaries, namelyupstreamandgit-remote-radto~/.radicle/bin. When running Upstream for the first time, this works fine as the folder is empty. When running Upstream for a second time, this crashes because the files already exist.The quick fix for me is to remove those files manually before running Upstream, e.g.
rm -rf ~/.radicle/bin. A proper fix might be to check whether the files already exist before copying them. But more fundamentally, why does running Upstream copy binaries to my home folder? I run NixOS, and having binaries in my home folder violates the functional philosophy of the project.Can someone explain to me why the binaries are copied to
~/.radicle?Some More Explanations
Nixpkgs, the nix package repository, offers a package for Upstream version 0.3.0 (which most probably also suffers from the problem I describe above). I do not use the nixpkgs package because it installs
git-remote-rad. Unfortunately, I also want to install my own package for radicle-cli and get some conflict withgit-remote-rad. I instead created a dedicated package forgit-remote-radthat I feed to both Upstream and radicle-cli as a dependency.Ideally, I would compile and install from sources (as is recommended by Nix), but this is not yet possible because Upstream uses some unstable Rust features apparently (as detailed in the nixpkgs package)