Skip to content

CentOS 7 64-bit metadata file issue #8

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

Closed
kapitainsky opened this issue Nov 21, 2019 · 9 comments
Closed

CentOS 7 64-bit metadata file issue #8

kapitainsky opened this issue Nov 21, 2019 · 9 comments
Labels
bug Something isn't working upstream bug

Comments

@kapitainsky
Copy link

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.

@kapitainsky kapitainsky changed the title CentOS 7 64-bit CentOS 7 64-bit metadata file issue Nov 21, 2019
@TheAssassin
Copy link
Member

Like #9 an issue for AppImageKit.

@TheAssassin TheAssassin reopened this Nov 23, 2019
@TheAssassin TheAssassin added bug Something isn't working upstream bug labels Nov 23, 2019
@TheAssassin
Copy link
Member

Please open an issue upstream at https://github.com/AppImage/AppImageKit.

@probonopd
Copy link
Contributor

Actually, as the message says,

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

@TheAssassin
Copy link
Member

I think at some point appimagetool should just warn about failed validation but not exit... It's getting increasingly annoying to remain compatible.

@TheAssassin
Copy link
Member

Anyway, not the plugin's fault. You'll have to adjust your AppStream config. (Or just uninstall appstreamcli.)

@kapitainsky
Copy link
Author

Anyway, not the plugin's fault. You'll have to adjust your AppStream config. (Or just uninstall appstreamcli.)

There is no appstreamcli on centos 7. I tried to compile it from source but it is not doable. At least not easy as they moved with dev to tools versions not available on this OS. So appimage is trying to use appstream-util. This is why it works on Ubuntu. And appstream-util is showing very stupid error message that my screenshots urls are not reachable. They are.

Now what I don’t get why don’t you bundle tool like appstream cli in your tool AppImage? I thought this is the key concept. To avoid missing dependencies.

@TheAssassin
Copy link
Member

Because appstream-cli yields different results in different versions. It's really, really annoying. Maybe open an issue about including it over at AppImageKit? This plugin just bundles appimagetool internally, it's a shallow wrapper.

@kapitainsky
Copy link
Author

This would be an ideal solution. It is nightmare where tools produce different outputs out of the blue.

@probonopd
Copy link
Contributor

Yes @TheAssassin, please see AppImage/AppImageKit#1011 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working upstream bug
Projects
None yet
Development

No branches or pull requests

3 participants