linuxdeploy / linuxdeploy-plugin-appimage Goto Github PK
View Code? Open in Web Editor NEWPlugin for linuxdeploy. Creates AppImages from AppDirs.
Home Page: https://github.com/linuxdeploy/linuxdeploy
Plugin for linuxdeploy. Creates AppImages from AppDirs.
Home Page: https://github.com/linuxdeploy/linuxdeploy
Hi,
The creation of appimage aborts because of a simple warning in the appdata.xml file:
appimagetool, continuous build (commit 0880085), build 2133 built on 2020-07-09 12:25:52 UTC
Using architecture x86_64
/home/kybos/Projects/muse-fork/appimage/appdir should be packaged as MusE-master-x86_64.AppImage
AppStream upstream metadata found in usr/share/metainfo/org.musesequencer.Muse3.appdata.xml
Trying to validate AppStream information with the appstreamcli tool
In case of issues, please refer to https://github.com/ximion/appstream
W - org.musesequencer.Muse3.appdata.xml:org.musesequencer.Muse3:9
Found empty 'content_rating' tag.
Validation failed: warnings: 1, pedantic: 5
Failed to validate AppStream information with appstreamcli
Can this be circumvented or changed somehow? I guess this kind of warning shouldn't cause the whole process to abort.
The problem is that the content_rating tag is required by FlatHub (even empty, as no rating is applicable in our case), so it's quite a deadlock.
Thanks
Kybos
There's no longer a downloadable AppImage, only source code
https://github.com/linuxdeploy/linuxdeploy-plugin-appimage/releases
Using Fedora 31 with all the latest patches (dnf -y upgrade --refresh):
[appimage/stderr] Using architecture x86_64
[appimage/stderr] AppStream upstream metadata found in usr/share/metainfo/org.kde.kstars.appdata.xml
[appimage/stderr] /usr/bin/appstreamcli: symbol lookup error: /lib64/libappstream.so.4: undefined symbol: g_ptr_array_steal_index_fast
[appimage/stderr] Failed to validate AppStream information with appstreamcli
ERROR: Failed to run plugin: appimage
DEBUG: Exited with return code: 1
from Fedora @System repo:
Installed Packages
Name : appstream
Version : 0.12.7
Release : 2.fc31
Architecture : x86_64
Size : 1.1 M
Source : appstream-0.12.7-2.fc31.src.rpm
Repository : @System
From repo : fedora
Summary : Utilities to generate, maintain and access the AppStream database
URL : https://github.com/ximion/appstream
License : GPLv2+ and LGPLv2+
Description : AppStream makes it easy to access application information from the
: AppStream database over a nice GObject-based interface.
execution:
./linuxdeploy-x86_64.AppImage --appdir kstars-appimage --output appimage -v0
The Appdir kstars-appimage
is successful in that AppRun is properly linked and when ran, everything works fine, it just won't create the final executable bundle.
This plugin should simply be built on CentOS 6.
Builds are broken with ERROR: Could not find dependency: libffi.so.5
.
Note that squashfs-root/usr/lib/libffi.so.5
is already deployed. https://travis-ci.org/linuxdeploy/linuxdeploy-plugin-appimage/jobs/417058047#L665
There are situations when we are trying to sign but there is no key (for example, when we are on git pull requests). In this case, a warning should be printed and the AppImage creation should continue/fall back without signature.
We are getting
ERROR: gpg2 command did not succeed, could not sign, continuing
but it fails nevertheless:
[appimage/stderr] gpg2 and sha256sum are installed and user requested to sign, hence signing
[appimage/stderr] /usr/bin/sha256sum appimaged-x86_64.AppImage
[appimage/stderr] /usr/bin/gpg2 --batch --detach-sign --armor appimaged-x86_64.AppImage.digest
[appimage/stderr] gpg: no default secret key: No secret key
[appimage/stderr] gpg: signing failed: No secret key
[appimage/stderr] ERROR: gpg2 command did not succeed, could not sign, continuing
[appimage/stdout] Desktop file: /tmp/appimaged-build-GixH5p/appdir/appimaged.desktop
[appimage/stdout] /tmp/appimaged-build-GixH5p/appdir should be packaged as appimaged-x86_64.AppImage
[appimage/stdout] Size of the embedded runtime: 187976 bytes
[appimage/stdout] updateinformation type: gh-releases-zsync
[appimage/stdout] ui_offset: 175304
[appimage/stdout] ui_length: 1024
[appimage/stdout] sha256sum: 5f18fbcf147a2ae66c70ae229a7e562035527defde782f11535d2fdad88e82b1
ERROR: Failed to run plugin: appimage
References:
I meet this issue when use appimage plugin:
[appimage/stderr]
[appimage/stderr] appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:33 UTC
[appimage/stderr] Using architecture x86_64
[appimage/stderr] AppStream upstream metadata found in usr/share/metainfo/org.qbittorrent.qBittorrent.appdata.xml
[appimage/stdout] org.qbittorrent.qBittorrent.appdata.xml
[appimage/stdout] E: org.qbittorrent.qBittorrent:19: description-para-markup-invalid ul
[appimage/stdout] E: org.qbittorrent.qBittorrent:27: description-para-markup-invalid ul
[appimage/stdout] E: org.qbittorrent.qBittorrent:39: description-para-markup-invalid ul
[appimage/stdout] I: org.qbittorrent.qBittorrent:71: url-not-secure http://bugs.qbittorrent.org/
[appimage/stdout] I: org.qbittorrent.qBittorrent:73: url-not-secure http://forum.qbittorrent.org/
[appimage/stdout] W: org.qbittorrent.qBittorrent:73: url-not-found http://forum.qbittorrent.org/ - HTTP 503: Service Unavailable
[appimage/stdout]
[appimage/stdout] 验证失败:错误:3, 警告:1, 信息:2, pedantic: 4
[appimage/stdout] run_external: subprocess exited with status 3[appimage/stderr] Failed to validate AppStream information with appstreamcli
ERROR: Failed to run plugin: appimage (exit code: 1)
Thanks.
In log files, the lines are prefixed with annoying and misleading [appimage/stdout]
and [appimage/stderr]
strings which make it hard to read an messy.
https://travis-ci.org/azubieta/appimage-info/builds/420875629#L2904-L2905
[appimage/stdout] /home/travis/build/azubieta/appimage-info/AppDir should be packaged as AppImage_Info-x86_64.AppImage
[appimage/stderr] appimagetool, continuous build (commit 56ebd56), build 1818 built on 2018-08-03 15:20:41 UTC
Please always use the latest appimagetool
.
linuxdeploy as of today uses a very outdated one, d18552 from October(!)
me@host:~$ Downloads/linuxdeploy-x86_64.AppImage --appimage-version
Version: d18552
Leading to errors we have long since fixed:
AppImage/appimage.github.io#1025 (comment)
When I create an AppImage the tool is stuck forever at the AppStream metadata checking process. I need to manually create it with appimagetool using the "--no-appstream" argument. Is there any way to run linuxdeploy with the appimage output plugin and the "--no-appstream" argument?
When running on Fedora and including appstream metadata, the linuxdeploy appimage (indirectly?) attempts to run appstreamcli
with the environment set to resolve glib from inside the appimage.
However, since it is running a binary installed by the host system, the LD_LIBRARY_PATH causes runtime linker errors for the glib symbols referenced by appstreamcli
.
I've worked around this in wez/wezterm@90de55f by deploying a little appstreamcli
wrapper script early in the PATH to clean its environment.
It would be great to resolve this correctly; I'd suggest either making sure that the plugin cleans the environment first, or alternatively, by bundling the needed utilities in the linuxdeploy appimage and running them from there.
Thank you for this excellent tool which we use to regularly build portable linux executables for our app.
Since recently, the release seems to be gone in the url we've been using before and I cannot find a new one
https://github.com/linuxdeploy/linuxdeploy-plugin-appimage/releases/download/continuous/linuxdeploy-plugin-appimage-x86_64.AppImage:
2022-07-16 06:07:59 ERROR 404: Not Found.
Is there another (stable) url where this can be downloaded?
The readme says the variable is called LDAI_APPIMAGE_COMP, but in the code it's actually handled as LDAI_COMP.
Apaprently, if the NO_CLEANUP env variable is set, the AppImage infrastructure is supposed to not remove the unpacked files and reuse the existing files.
This is really important as we aim to use AppImage packaging in production deployments where we could manage a single unpacking delay, but do not want this delay each and every time the AppImage is run.
Why does this feature appear not to work?
I did try to build the appimagetool from the latest git repo, but still have not yet succeeded in doing so, so I took latest released binaries.
foot@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin# ./linuxdeploy-aarch64.AppImage --version
linuxdeploy version 1-alpha (git commit ID 2b73a21), <local dev build> built on 2024-02-12 13:22:56 UTC
root@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin# ./linuxdeploy-plugin-appimage --version
Failed to parse arguments: Flag could not be matched: version
./linuxdeploy-plugin-appimage {OPTIONS}
linuxdeploy-plugin-appimage
OPTIONS:
--appdir=[AppDir] AppDir to package as AppImage
--plugin-type Return plugin type and exit
--plugin-api-version Return plugin type and exit
root@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin# ./linuxdeploy-plugin-qt-aarch64.AppImage --version
./linuxdeploy-plugin-qt-aarch64.AppImage {OPTIONS}
linuxdeploy Qt plugin
OPTIONS:
--appdir=[appdir path] Path to an existing AppDir
-p[plugin...],
--extra-plugin=[plugin...] Extra Qt plugin to deploy (specified by
name, filename or path)
--plugin-type Print plugin type and exit
--plugin-api-version Print plugin API version and exit
--plugin-version Print plugin version and exit
Bundles Qt resources. For use with an existing AppDir, created by
linuxdeploy.
root@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin# ./appimagetool --version
appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:29 UTC
root@qemuarm64:/home/ccs/Qt/Projects/CortexBuilds/bin#
ccs@v700:~/Downloads$ export NO_CLEANUP=1
ccs@v700:~/Downloads$ sudo ./Dice-aarch64.AppImage
/tmp/.mount_Dice-a5QqLk2/AppRun.wrapped: error while loading shared libraries: libglapi.so.0: cannot open shared object file: No such file or directory
ccs@v700:~/Downloads$ ls /tmp/.mount*
ls: cannot access '/tmp/.mount*': No such file or directory
ccs@v700:~/Downloads$
Hi,
I have multiple GPG keys on my machine and I want to be able to choose which one AppImageKit uses for signing. There is a --sign-key
flag for appimagetool for this purpose, however when using linuxdeploy
, this flag is not exposed. It would be great if we could set it using linuxdeploy
.
I find an AppImage with simple desktop integration implement: https://dl.motrix.app/release/Motrix-1.4.1-x86_64.AppImage
I think it's cool to support this feature.
It works but only when I remove metadata xml file. Otherwise it fails as below:
Found appimagetool: /tmp/.mount_linuxdCqqmwp/usr/bin/appimagetool
Running command: /tmp/.mount_linuxdCqqmwp/usr/bin/appimagetool "AppDir" "-g"
appimagetool, continuous build (commit fef038a), build 2093 built on 2019-07-07 12:07:34 UTC
WARNING: appstreamcli command is missing, please install it if you want to use AppStream metadata
Using architecture x86_64
/dev/shm/rclone-browser-1.6.0-d9e3ebe.AppImage/AppDir should be packaged as Rclone_Browser-1.6.0-d9e3ebe-x86_64.AppImage
Deleting pre-existing .DirIcon
Creating .DirIcon symlink based on information from desktop file
AppStream upstream metadata found in usr/share/metainfo/rclone-browser.appdata.xml
Trying to validate AppStream information with the appstream-util tool
In case of issues, please refer to https://github.com/hughsie/appstream-glib
/dev/shm/rclone-browser-1.6.0-d9e3ebe.AppImage/AppDir/usr/share/metainfo/rclone-browser.appdata.xml: FAILED:
• url-not-found : <screenshot> failed to connect: SSL handshake failed [https://github.com/kapitainsky/RcloneBrowser/wiki/images/IMGdefault.png]
• url-not-found : <screenshot> failed to connect: SSL handshake failed [https://github.com/kapitainsky/RcloneBrowser/wiki/images/IMGtransfer.png]
Validation of files failed
Failed to validate AppStream information with appstream-util
rename: Rclone_Browser*: rename to rclone-browser* failed: No such file or directory
cp: cannot stat ‘*AppImage’: No such file or directory
the same metadata xml file works perfectly on Ubuntu 16.04.
Both urls it complains about are valid.
Trying to sign AppImage with my pgp keys:
Embedding MD5 digest
gpg2 and sha256sum are installed and user requested to sign, hence signing
Error: cannot embed key in AppImage: size exceeds reserved ELF section size
Could not find any information about what keys are permitted, obviously mine is too long (4096 bits). Any details on this somewhere?
Hello,
I'm cross-compiling on an x86_64 build VM for an i.MX8 cortexa-35-poky-linux platform. Does this tool work in this environment ?
If not, are there any plans to enable this support?
A minor point here, I notice the AppImage produced is in the current working directory, and in my case I'm always moving it to a desired destination / deployment directory.
Having an option that will give the output directory and/or output filename would be much appreciated.
Thanks for creating versions for arm.
We've been targeting glibc 2.17 for x86 for a while....but the aarch64 version is seemingly looking for at least 2.25:
[appimage/stderr] appimagetool: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /tmp/appimage_extracted_a6dc6e7d0c1514c8714921f9e2e39fc1/plugins/linuxdeploy-plugin-appimage/appimagetool-prefix/usr/lib/libgcrypt.so.20)
Intentional? Otherwise?
If so, please update the readme.
Thanks.
The binaries should be updated on every appimagetool update.
Can an option be added to linuxdeploy so the AppImage won't be compressed when it's created?
I am experimenting with creating my first AppImage, and I'm facing the following issue. When I supply an AppStream metadata file and try to build my AppImage, it fails with the following error:
[appimage/stderr] AppStream upstream metadata found in usr/share/metainfo/test.appdata.xml
[appimage/stderr] /usr/bin/appstreamcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1: undefined symbol: g_file_info_get_modification_date_time
[appimage/stderr] Failed to validate AppStream information with appstreamcli
I am new to this ecosystem, but I suspect what's happening is that the appimagetool
bundled into linuxdeploy
is somehow incompatible with the version of appstreamcli
I have on my machine. Is this a possible root cause?
test
(in my example I copied /usr/bin/xargs
) and dummy icon called test.svg
test.desktop
(contents below)./linuxdeploy-x86_64.AppImage --appdir AppDir -e ./test -d ./test.desktop -i ./test.svg
test.appdata.xml
(contents below) and copy it into AppDir/usr/share/metainfo
./linuxdeploy-x86_64.AppImage --appdir AppDir --output appimage
linuxdeploy version 1-alpha (git commit ID 04d5321), Travis build 485 built on 2020-09-25 12:21:53 UTC
-- Creating basic AppDir structure --
Creating directory AppDir/usr/bin/
Creating directory AppDir/usr/lib/
Creating directory AppDir/usr/share/applications/
Creating directory AppDir/usr/share/icons/hicolor/
Creating directory AppDir/usr/share/icons/hicolor/16x16/apps/
Creating directory AppDir/usr/share/icons/hicolor/32x32/apps/
Creating directory AppDir/usr/share/icons/hicolor/64x64/apps/
Creating directory AppDir/usr/share/icons/hicolor/128x128/apps/
Creating directory AppDir/usr/share/icons/hicolor/256x256/apps/
Creating directory AppDir/usr/share/icons/hicolor/scalable/apps/
-- Deploying dependencies for existing files in AppDir --
Deploying dependencies for ELF file AppDir/usr/bin/test
Skipping deployment of blacklisted library /lib/x86_64-linux-gnu/libc.so.6
-- Copying files into AppDir --
Setting rpath in ELF file AppDir/usr/bin/test to $ORIGIN/../lib
-- Copying files into AppDir --
-- Deploying files into AppDir root directory --
WARNING: No desktop file specified, using first desktop file found: AppDir/usr/share/applications/test.desktop
Deploying files to AppDir root using desktop file: AppDir/usr/share/applications/test.desktop
Deploying desktop file to AppDir root: AppDir/usr/share/applications/test.desktop
Creating symlink for file AppDir/usr/share/applications/test.desktop in/as AppDir
Deploying icon to AppDir root: AppDir/usr/share/icons/hicolor/scalable/apps/test.svg
Creating symlink for file AppDir/usr/share/icons/hicolor/scalable/apps/test.svg in/as AppDir
WARNING: Existing AppRun detected, skipping deployment of symlink
-- Running output plugin: appimage --
[appimage/stdout] Found appimagetool: /tmp/.mount_linuxdhqPhgm/plugins/linuxdeploy-plugin-appimage/usr/bin/appimagetool
[appimage/stdout]
[appimage/stderr] Running command: /tmp/.mount_linuxdhqPhgm/plugins/linuxdeploy-plugin-appimage/usr/bin/appimagetool "AppDir" "-g"
[appimage/stderr]
[appimage/stdout] /home/balazs/testcase/AppDir should be packaged as test-test-x86_64.AppImage
[appimage/stdout] Trying to validate AppStream information with the appstreamcli tool
[appimage/stdout] In case of issues, please refer to https://github.com/ximion/appstream
[appimage/stderr] appimagetool, continuous build (commit 0880085), build 2133 built on 2020-07-09 12:25:52 UTC
[appimage/stderr] Using architecture x86_64
[appimage/stderr] AppStream upstream metadata found in usr/share/metainfo/test.appdata.xml
[appimage/stderr] /usr/bin/appstreamcli: symbol lookup error: /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1: undefined symbol: g_file_info_get_modification_date_time
[appimage/stderr] Failed to validate AppStream information with appstreamcli
ERROR: Failed to run plugin: appimage (exit code: 1)
test.desktop
:
[Desktop Entry]
Type=Application
Name=test
Icon=test
Exec=test
Categories=Development;
test.appdata.xml
:
<?xml version="1.0" encoding="UTF-8"?>
<component>
<id>test</id>
<name>Test</name>
<summary>Test</summary>
<metadata_license>MIT</metadata_license>
</component>
Versions:
$ appstreamcli --version
AppStream version: 0.12.10
$ which appstreamcli
/usr/bin/appstreamcli
$ ./linuxdeploy-x86_64.AppImage --version
linuxdeploy version 1-alpha (git commit ID 04d5321), Travis build 485 built on 2020-09-25 12:21:53 UTC
Thanks for looking into this.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.