Publish AppImage to appimage.github.io/

[hiran]

Just like the Microsoft Store or FlatHub, AppImages can be registered on https://appimage.github.io/ so they get more popular.

While I tried to follow this guide
https://github.com/AppImage/appimage.gi ... he-catalog

I had to find out that all tests failed. What exactly is failing?

- I think we are not following the naming pattern

Code: Select all

Application name, hyphen, version, hyphen, architecture, dot, AppImage suffix

- I received a WARNING: No appdata file present. Please provide one in the AppImage as per the instructions on https://www.freedesktop.org/software/ap ... esktopApps



BTW: these appimages are following a very similar pattern as we are running for OXPs...

[mcarans]

Just like the Microsoft Store or FlatHub, AppImages can be registered on https://appimage.github.io/ so they get more popular.

While I tried to follow this guide
https://github.com/AppImage/appimage.gi ... he-catalog

I had to find out that all tests failed. What exactly is failing?

- I think we are not following the naming pattern

Code: Select all

Application name, hyphen, version, hyphen, architecture, dot, AppImage suffix

- I received a WARNING: No appdata file present. Please provide one in the AppImage as per the instructions on https://www.freedesktop.org/software/ap ... esktopApps

BTW: these appimages are following a very similar pattern as we are running for OXPs...

AI suggested something which if true would be a better bet for attracting interest: https://itch.io/

"Itch.io (Best for Games)

Since Oolite is a game, Itch.io is arguably your best bet.

Why: Itch has an excellent Linux community. You can upload your Oolite-Portable-x86_64 binary directly.

The "Butler" Advantage: If you use the butler CLI tool, you can push updates to your wrappe file that only download the changed "bits" (delta-updates), which saves bandwidth for your players."

I think both Windows and Linux versions could be put there.

[hiran]

Grant. Itch.io is a good site for publishing.
Butler to transfer differences is a nice thing also.
You mention wrappe again.

Is this wrappe vs AppImage? Or is there a reason not to stick to conventions to make the AppImage go into the appimage github repo?

[mcarans]

Grant. Itch.io is a good site for publishing.
Butler to transfer differences is a nice thing also.
You mention wrappe again.

Is this wrappe vs AppImage? Or is there a reason not to stick to conventions to make the AppImage go into the appimage github repo?

At the moment I'm leaning towards AnyLinux AppImage based on lack of recent updates of wrappe and the fact it has fallbacks for when there's no fuse2. It could be published on the AppImage GitHub repo but not sure how much that repo is actually used. I have never downloaded an AppImage from there before.

[hiran]

At the moment I'm leaning towards AnyLinux AppImage based on lack of recent updates of wrappe and the fact it has fallbacks for when there's no fuse2. It could be published on the AppImage GitHub repo but not sure how much that repo is actually used. I have never downloaded an AppImage from there before.

Having read the docs there is an attempt to standardize appimages such that an AppImage manager can offer a catalog of applications in a meaningful way. This github repo does not claim to be the only one, but it collects AppImage locations already.

Consider it's functionality for AppImages to be the same as our own https://github.com/OoliteProject/oolite ... on-catalog related to OXPs.

But our AppImage build is lacking some metadata. Just like an OXP cannot go into the expansion manager without manifest.plist the AppImage cannot go into appimage.github.io/ without being compliant to some rules.

All I want to achieve is to tweak the images we have so they are compliant. From then on they can be still e offered for download as we do today but potentially get listed in more locations.

[mcarans]

...
But our AppImage build is lacking some metadata. Just like an OXP cannot go into the expansion manager without manifest.plist the AppImage cannot go into appimage.github.io/ without being compliant to some rules.

All I want to achieve is to tweak the images we have so they are compliant. From then on they can be still e offered for download as we do today but potentially get listed in more locations.

Flatpak is similar. What metadata is needed?

[hiran]

...
But our AppImage build is lacking some metadata. Just like an OXP cannot go into the expansion manager without manifest.plist the AppImage cannot go into appimage.github.io/ without being compliant to some rules.

All I want to achieve is to tweak the images we have so they are compliant. From then on they can be still e offered for download as we do today but potentially get listed in more locations.

Flatpak is similar. What metadata is needed?

Let's fix the file naming pattern and provide the appdata.
Links are in the first post.

[mcarans]

...
But our AppImage build is lacking some metadata. Just like an OXP cannot go into the expansion manager without manifest.plist the AppImage cannot go into appimage.github.io/ without being compliant to some rules.

All I want to achieve is to tweak the images we have so they are compliant. From then on they can be still e offered for download as we do today but potentially get listed in more locations.

Flatpak is similar. What metadata is needed?

Let's fix the file naming pattern and provide the appdata.
Links are in the first post.

Conveniently the expected metadata is pretty much identical to what FlatHub expects - they use the same AppStream format: https://github.com/mcarans/oolite/blob/ ... l.template

eg.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<component type="desktop-application">
  <id>space.oolite.Oolite</id>
  
  <name>Oolite</name>
  <summary>Open-world space opera</summary>
  
  <metadata_license>MIT</metadata_license>
  <project_license>GPL-2.0-or-later</project_license>
  <url type="homepage">https://oolite.space</url>
  <url type="bugtracker">https://github.com/OoliteProject/oolite/issues</url>
  <url type="contribute">https://wiki.alioth.net/index.php/Contributing_to_the_project</url>
  <url type="vcs-browser">https://github.com/OoliteProject/oolite</url>
  <url type="faq">https://wiki.alioth.net/index.php/Oolite_FAQ</url>

  <developer id="space.oolite">
    <name>Giles Williams, Jens Ayton, and contributors</name>
  </developer>

  <branding>
    <color type="primary" scheme_preference="light">#bbbbce</color>
    <color type="primary" scheme_preference="dark">#1c1a2e</color>
  </branding>

  <content_rating type="oars-1.1">
    <content_attribute id="violence-fantasy">moderate</content_attribute>
    <content_attribute id="drugs-alcohol">mild</content_attribute>
    <content_attribute id="drugs-narcotics">mild</content_attribute>
  </content_rating>
  
  <description>
    <p>
      Oolite is inspired by the 8-bit classic Elite, and many aspects of gameplay will be familiar to players of that game. In the tradition of open-world games, there&apos;s no overall story: you can be a millionaire trader, a veteran combateer, a feared pirate, a lonely miner, a notorious smuggler, or all of them, or something else entirely, based on your own actions.
    </p>
  </description>

  <requires>
    <control>keyboard</control>
    <control>pointing</control>
    <display_length compare="ge">768</display_length>
  </requires>
  
  <launchable type="desktop-id">space.oolite.Oolite.desktop</launchable>

  <screenshots>
    <screenshot type="default">
      <image>https://raw.githubusercontent.com/OoliteProject/oolite/1.92-maintenance/installers/flatpak/oolite-999.png</image>
      <caption>The universe awaits. Go explore and seek your fortune!</caption>
    </screenshot>
    <screenshot>
      <image>https://raw.githubusercontent.com/OoliteProject/oolite/1.92-maintenance/installers/flatpak/oolite-008.png</image>
      <caption>Choose from a diverse range of interstellar craft. </caption>
    </screenshot>
    <screenshot>
      <image>https://raw.githubusercontent.com/OoliteProject/oolite/1.92-maintenance/installers/flatpak/oolite-064.png</image>
      <caption>Find safety in massive orbital stations.</caption>
    </screenshot>
    <screenshot>
      <image>https://raw.githubusercontent.com/OoliteProject/oolite/1.92-maintenance/installers/flatpak/oolite-001.png</image>
      <caption>Access the expansion pack manager and quick reference guides on the start screen.</caption>
    </screenshot>
    <screenshot>
      <image>https://raw.githubusercontent.com/OoliteProject/oolite/1.92-maintenance/installers/flatpak/oolite-002.png</image>
      <caption>Learn to fly with the tutorial covering piloting, combat, and travel.</caption>
    </screenshot>
    <screenshot>
      <image>https://raw.githubusercontent.com/OoliteProject/oolite/1.92-maintenance/installers/flatpak/oolite-004.png</image>
      <caption>Fly to Maraus, a wealthy industrial world, one of 2000 systems to be discovered.</caption>
    </screenshot>
  </screenshots>

  <releases>
    <release version="1.92.1" date="2026-03-12">
      <description>
        <p>This stable release fixes these bugs:</p>
        <ul>
          <li>Centre main window after showing splash.</li>
          <li>Smooth resizing of game window.</li>
          <li>Fix for crash when no network.</li>
        </ul>
      </description>
    </release>
    <release version="1.92" date="2026-02-03">
      <description>
        <p>First Flatpak release of Oolite.</p>
      </description>
    </release>
  </releases>
</component>

As far as I can tell it is exactly what AppImageHub expects. Can you see anything wrong or missing?

As for the AppImage name, rules are:

AppImage filename consists of pieces: Application name, hyphen, version, hyphen, architecture, dot, AppImage suffix

• First piece of the AppImage filename, "App" == name of the repo

• Blanks in the app name become _

• Respect uppercase. If the app is called "App", do NOT use "app"

Example: App-1.1-x86_64.AppImage in a repo called "App"

I think that would be something like "oolite-1.92.1-x86_64.AppImage". Given our current release is named "Oolite_1.92-x86_64.AppImage", the only changes seem to be to make the first letter of the name lowercase and replace the _ with a -. Do you agree?

[hiran]

Conveniently the expected metadata is pretty much identical to what FlatHub expects - they use the same AppStream format: https://github.com/mcarans/oolite/blob/ ... l.template

I am not surprised. That file format is defined by freedesktop.org. It is cool to be used by both image formats.

I think that would be something like "oolite-1.92.1-x86_64.AppImage". Given our current release is named "Oolite_1.92-x86_64.AppImage", the only changes seem to be to make the first letter of the name lowercase and replace the _ with a -. Do you agree?

We have more than one appimage. The first hyphen must denote the version. So oolite-test-1.92 should become oolite_test-1.92. Otherwise I agree.

I have not yet read/verified the full xml you presented. Appimagehub has some linter that goes through that all. IIRC it checked the prerelease, so changing the master branch is sufficient for me to test again.

Once that passes we can think of backporting to the release.

[mcarans]

Conveniently the expected metadata is pretty much identical to what FlatHub expects - they use the same AppStream format: https://github.com/mcarans/oolite/blob/ ... l.template

I am not surprised. That file format is defined by freedesktop.org. It is cool to be used by both image formats.

I think that would be something like "oolite-1.92.1-x86_64.AppImage". Given our current release is named "Oolite_1.92-x86_64.AppImage", the only changes seem to be to make the first letter of the name lowercase and replace the _ with a -. Do you agree?

We have more than one appimage. The first hyphen must denote the version. So oolite-test-1.92 should become oolite_test-1.92. Otherwise I agree.

I have not yet read/verified the full xml you presented. Appimagehub has some linter that goes through that all. IIRC it checked the prerelease, so changing the master branch is sufficient for me to test again.

Once that passes we can think of backporting to the release.

I think that like FlatHub only the deployment release will be published to AppImageHub so the test or dev version naming won't affect things.

[another_commander]

Code: Select all

<release version="1.92" date="2026-02-03">
      <description>
        <p>First Flatpak release of Oolite.</p>
      </description>
    </release>

Is this description OK for upload to the AppImage repo? Maybe not mentioning Flatpak would be better but up to you.

[hiran]

I have not yet read/verified the full xml you presented. Appimagehub has some linter that goes through that all. IIRC it checked the prerelease, so changing the master branch is sufficient for me to test again.

Once that passes we can think of backporting to the release.

I think that like FlatHub only the deployment release will be published to AppImageHub so the test or dev version naming won't affect things.

I thought similar as you do. But the CI chain shows different:
https://github.com/AppImage/appimage.gi ... 6220048737

In the logs you can find that this AppImage has been downloaded:
https://github.com/OoliteProject/oolite ... 4.AppImage
So the preleases count as well.

But then there is something that I do not understand at all. The build I just referenced failed, and this was the trigger for me to open the thread. Apart from discussions we did nothing, did we? Now I can see another build, and it is successful:
https://github.com/AppImage/appimage.gi ... 6852182296

So if we did not change anything, why was the build successful?
And what would be the next step, as my PR looks clean now?
https://github.com/AppImage/appimage.gi ... /pull/3705

[hiran]

[...]
The "Butler" Advantage: If you use the butler CLI tool, you can push updates to your wrappe file that only download the changed "bits" (delta-updates), which saves bandwidth for your players."
[...]

I just stumbled over https://github.com/AppImageCommunity/AppImageUpdate
It advertizes as

AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself. No central repository is involved. This enables upstream application projects to release AppImages that can be updated easily. Since AppImageKit uses delta updates, the downloads are very small and efficient.
[...]
- Only the parts that have changed since the original version are downloaded.

But it requires again metadata to be configured:

Update information overview

In order for AppImageUpdate to do its magic, Update information must be embedded inside the AppImage. Update information is what tells AppImageUpdate vital data such as:

How can I find out the latest version (e.g., the URL that tells me the latest version)?
How can I find out the delta (the portions of the applications that have changed) between my local version and the latest version?
How can I download the delta between my local version and the latest version (e.g., the URL of the download server)?

While all of this information could simply be put inside the AppImage, this could be a bit inconvenient since that would mean changing the download server location would require the AppImage to be re-created. Hence, this information is not put into the file system inside the AppImage, but rather embedded into the AppImage in a way that makes it very easy to change this information should it be required, e.g., if you put the files onto a different download server. As you will probably know, an AppImage is both an ISO 9660 file (that you can mount and examine) and an ELF executable (that you can execute). We are using the ISO 9660 Volume Descriptor #1 field "Application Used" to store this information.

[mcarans]

Code: Select all

<release version="1.92" date="2026-02-03">
      <description>
        <p>First Flatpak release of Oolite.</p>
      </description>
    </release>

Is this description OK for upload to the AppImage repo? Maybe not mentioning Flatpak would be better but up to you.

I'm refactoring to make a shared metadata file for AppImage and Flatpak and that is something I have changed locally. I added AppImage so it mentions both.

[mcarans]

I have not yet read/verified the full xml you presented. Appimagehub has some linter that goes through that all. IIRC it checked the prerelease, so changing the master branch is sufficient for me to test again.

Once that passes we can think of backporting to the release.

I think that like FlatHub only the deployment release will be published to AppImageHub so the test or dev version naming won't affect things.

I thought similar as you do. But the CI chain shows different:
https://github.com/AppImage/appimage.gi ... 6220048737

In the logs you can find that this AppImage has been downloaded:
https://github.com/OoliteProject/oolite ... 4.AppImage
So the preleases count as well.

But then there is something that I do not understand at all. The build I just referenced failed, and this was the trigger for me to open the thread. Apart from discussions we did nothing, did we? Now I can see another build, and it is successful:
https://github.com/AppImage/appimage.gi ... 6852182296

So if we did not change anything, why was the build successful?
And what would be the next step, as my PR looks clean now?
https://github.com/AppImage/appimage.gi ... /pull/3705

I am puzzled. Did you upload a new AppImage or is it pulling artifacts from the Oolite repo?