Build flatpak via github runner

[razzeee]

Description

This copies the flatpak from flathub https://github.com/flathub/tv.kodi.Kodi does some small changes and adds a github workflow to build it.

Motivation and context

Flatpak at flathub get's out of sync and breaks, due to upstream changes. This would help catching stuff earlier and hopefully allow to work on updating better.

How has this been tested?

Hasn't I need the github pipeline.

What is the effect on users?

Better flatpak

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[razzeee]

Not sure why building samba would fail, that part of the code is an exact copy of the flathub build

[jenkins4kodi]

I've made some formatting changes to meet the current code style. The diffs are available in the following links:

• PR24887.diff

For more information please see our current code style guidelines.

[razzeee]

Should be good to go. In theory we could also run flatpak-builder-lint, but I've failed to set it up

[fuzzard]

My concern is the sheer amount of individual hashes to be maintained going forward. whats the expectations on updating them?
I think some sort of script needs to be created that retrieves and populates such hashes, unless the expectation is when an addon release is tagged, the addon author needs to PR an update to core as well to update this. Thats a bad workflow, that just wont happen in the long run i think.

Also, is there a reason not to use our mirrors for the source tarballs?

[fuzzard]

There was also discussion/work at Devcon regarding this in parallel to your work.

Essentially for PR builds we were looking to not build addons (ie reduce build times). @flole988 was running up a GHA yaml file to enable it. Im not sure if he finished it, but the goals were a script that could add/remove addons dynamically from your existing flathub build yml file.

I dont think this was his latest, but the following commit was a point in time over the weekend. Flole998@9d4ae7d

This was all sort of looked at being based on discussions around release change periods.

Edit:

A question we had at one point was, can flathub build from a non flathub repo (ie from our repo?). Does bring ALL of the flathub data like this just double someones (ie your) effort to keep in sync, or can the flathub builds just be pointing at the xbmc repo and the flathub one just isnt used any more?

[razzeee]

My concern is the sheer amount of individual hashes to be maintained going forward. whats the expectations on updating them? I think some sort of script needs to be created that retrieves and populates such hashes, unless the expectation is when an addon release is tagged, the addon author needs to PR an update to core as well to update this. Thats a bad workflow, that just wont happen in the long run i think.

For everything addon related, there is a shell script included (you will need a .env with a github secret) that's also linked from the make file. There is one addon that get's changed build instructions by that (inputstream I think?) that I always change back, but it updates the hashes fine.

I usually only update them when doing a kodi release or if someone complains (not sure that actually happened)

Also, is there a reason not to use our mirrors for the source tarballs?

Not sure, in general that would be better especially if we can detect new versions and get it to auto update via https://github.com/flathub-infra/flatpak-external-data-checker but not sure the mirrors are nice for that.

[razzeee]

A question we had at one point was, can flathub build from a non flathub repo (ie from our repo?). Does bring ALL of the flathub data like this just double someones (ie your) effort to keep in sync, or can the flathub builds just be pointing at the xbmc repo and the flathub one just isnt used any more?

In theory we can get a secret and push our builds to flathub (that's not available for everyone yet, but I have connections) but it would mean we need to do everything else here.

So ideally we would then also need to run:

• the flatpak external data checker
• flatpak builder lint

(obs or firefox could be used as a reference, as they do the same)

[wsnipex]

we should add a script that updates all source urls and hashes with the ones from our depends VERSION files. Ideally this would be done automatically on each build. That way (at least existing) dependencies would be in sync with other platforms.