Consider to bundle appstreamcli in the appimagetool AppImage

[kapitainsky]

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.

The issue is in reference to linuxdeploy/linuxdeploy-plugin-appimage#8

[probonopd]

As the message says,

In case of issues, please refer to https://github.com/hughsie/appstream-glib

[kapitainsky]

It is not so simple:) what about to bundle working appstreamcli within your tool?

[kapitainsky]

Isn’t all AppImage idea about providing working bundle? Not just telling me that your version of OS cli whatever tool is not what we like. Tough.

[TheAssassin]

Not just telling me that your version of OS cli whatever tool is not what we like. Tough.

Well, then you have a really old version, and even if your file is valid with the bundled appstream-cli version, it might break on newer systems.

AppStream is broken by design...

[kapitainsky]

Yes it is old because I try to follow AppImage guidance and build my app on the oldest still supported distro. And I prefer this way. I want to make my AppIamge app working on as many Linux versions as possible. I am not criticising here. Just looking for solution.

…

On 25 Nov 2019, at 21:41, TheAssassin ***@***.***> wrote:  Not just telling me that your version of OS cli whatever tool is not what we like. Tough. Well, then you have a really old version, and even if your file is valid with the bundled appstream-cli version, it might break on newer systems. AppStream is broken by design... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[TheAssassin]

Well, you're not the only one to have problems with this stuff... xournalpp/xournalpp#1618

[probonopd]

Agree with @kapitainsky - the tools to validate AppStream are not easy to use because a) there are two different tools which don't always agree, and b) it's hard to get a version that validates AppStream against a recent spec to run on systems that are less than recent.

Something needs to happen indeed. I am considering to build appstreamcli in a way that uses nothing from the target system (e.g., build with musl like the one linked below) and perhaps include it in the appimagetool AppImage?

In the meantime, here is a build that should be able to do the trick:
https://github.com/probonopd/static-tools/releases/download/continuous/appstreamcli.tar.gz

[kapitainsky]

Ta. Obviously it is something you should find the way forward. What’s the point of having something which sounds like is not going to work. In my small case not so important. I just drop all these meta info and will carry on:)

…

On 25 Nov 2019, at 21:49, TheAssassin ***@***.***> wrote:  Well, you're not the only one to have problems with this stuff... xournalpp/xournalpp#1618 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[probonopd]

Please check out the appstreamcli that I linked. It should do the trick.

[kapitainsky]

In the meantime, here is a build that should be able to do the trick:
https://github.com/probonopd/static-tools/releases/download/continuous/appstreamcli.tar.gz

Thank you for trying but on CentOS it does not work:

[db@localhost appcli]$ ./appstreamcli 
bash: ./appstreamcli: /lib/ld-musl-x86_64.so.1: bad ELF interpreter: No such file or directory

[TheAssassin]

Using the latest version of this tool doesn't make any sense. Neither does bundling. It seems it's possible to bundle an extremely old version, files it validates might be used with newer AppStream tools as well. The other way round is apparently broken. See the Xournal++ issue I linked. That file validates just fine with the latest available version, but broke on the not so old Ubuntu bionic.

Edit: this is just an observation I made recently for some very specific projects. It doesn't mean that it applies globally. But, thinking about it, it makes some sense, right? One should assume that newer versions of the tool remain backwards compatible, i.e., once a file can be validated with a specific version, it'll be able to validate it with any newer version.