-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
feat: init appimage #1
base: master
Are you sure you want to change the base?
Conversation
I'd be against forcefully providing a desktop entry. Graphical applications should always ship a .desktop file, which should be used. (For command line applications, generating a default desktop file based on the executable name is fine though.) |
@piegamesde agreed. Can you add the logic necessary to detect and find the desktop entry that may already be in the package? |
Probably not, sorry. |
This seems to break if packages contain broken relative symlinks. I wasn't able to build a package that used python3.10.5 because I was getting this error:
both |
Seems like this needs a |
This would be great. However, I expect it to inherit the same issues as |
identity = drv: drv; | ||
} | ||
)) // { | ||
x86_64-linux.toAppImage = (import ./appimage.nix { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AppimageKit does support packaging for i686-linux
and aarch64-linux
. Is there a reason to only allow x86_64-linux
AppImage bundling?
buildEnv { | ||
name = "hello"; | ||
paths = [drv ( | ||
runCommand "appdir" {buildInputs = [imagemagick];} '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
runCommand "appdir" {buildInputs = [imagemagick];} '' | |
runCommand "appdir" {nativeBuildInputs = [imagemagick];} '' |
Creating an arbitrary appimage. Needs more ability to encode icons and other parameters.