Thanks for this - haven't had a chance to go through it all yet but at a glance it looks high quality.

I think we're ok if the flatpak is podman only.

@tulilirockz mentioned a while back that podman-remote might be the way forward for flatpak, not sure exactly what her intention was for that approach though. I don't have any real working knowledge of flatpaks nor flathubs publishing requirements.

@tulilirockz mentioned a while back that podman-remote might be the way forward for flatpak, not sure exactly what her intention was for that approach though. I don't have any real working knowledge of flatpaks nor flathubs publishing requirements.

I think, (but I'm not sure) the idea is to ship podman with the app in the flatpak, and expose the host podman socket to flatpak. Then podman inside the flatpak can use podman remote to connect to the socket.

Also it might be a good idea to wait for #515 before dealing with flatpak. I think
But nice work!

Food for thought: both docker and podman have HTTP APIs that can be used instead of their cli programs:

• https://docs.docker.com/reference/api/engine/version/v1.52/ (OpenAPI)
• https://docs.podman.io/en/latest/_static/api.html?version=latest (OpenAPI)

It's possible to generate a typescript client for those APIs and use it directly instead of relying on external CLIs:

docker run -it --rm -v "$PWD:/local" \
  openapitools/openapi-generator-cli generate \
  -i https://docs.docker.com/reference/api/engine/version/v1.52.yaml \
  -g typescript-node \
  -o /local/docker-client

Thus avoiding the need to package docker and podman altogether. The docker client will probably work for both docker and podman, as podman API is supposed to be compatible, but this needs testing (I haven't tried it yet).

Also it might be a good idea to wait for #515 before dealing with flatpak. I think But nice work!

TY for having a look Auri - this sets off a chain haha as we want to do a full refactor (and rework the UI) of the config page first. I was waiting for Lev/Tibix to do the first sub-page but I should probably just give it a go.

Food for thought: both docker and podman have HTTP APIs that can be used instead of their cli programs:

• https://docs.docker.com/reference/api/engine/version/v1.52/ (OpenAPI)
• https://docs.podman.io/en/latest/_static/api.html?version=latest (OpenAPI)

It's possible to generate a typescript client for those APIs and use it directly instead of relying on external CLIs:

docker run -it --rm -v "$PWD:/local" \
  openapitools/openapi-generator-cli generate \
  -i https://docs.docker.com/reference/api/engine/version/v1.52.yaml \
  -g typescript-node \
  -o /local/docker-client

Thus avoiding the need to package docker and podman altogether. The docker client will probably work for both docker and podman, as podman API is supposed to be compatible, but this needs testing (I haven't tried it yet).

That seemes a lot more work than just exposing the unix socket, and I don't know if it's worth it.

p.s. I can't really speak for whether any changes should be made to the flatpak packaging as I have no idea how it work.

Hey @ea7ababe - are any of these files are automatically generated/updated?

Hey @ea7ababe - are any of these files are automatically generated/updated?

go-sources.json, js-sources.json and modules.txt contain all Go and JS dependencies, and are generated by the rules in the Makefile (it's in the same directory as those files).

They aren't updated automatically though, someone would need to periodically run those rules, and commit their output into the repository - I didn't include the generation step into the CI pipeline.

The metainfo file was written manually, but if you worry about keeping it in sync with the release notes on the github page, then I imagine there would need to be a NEWS file, from which both would be generated.

Hey @ea7ababe - are any of these files are automatically generated/updated?

go-sources.json, js-sources.json and modules.txt contain all Go and JS dependencies, and are generated by the rules in the Makefile (it's in the same directory as those files).

They aren't updated automatically though, someone would need to periodically run those rules, and commit their output into the repository - I didn't include the generation step into the CI pipeline.

Thanks - I'm wondering if we can move it into the CI pipeline/general build process (for local builds) and not have them committed?

I'm wondering if we can move it into the CI pipeline/general build process (for local builds) and not have them committed?

Hey, sorry for the delay. Can you look at the commit above? I've removed the generated files, and added a docker buildx bake -based build process to generate these files and build the flatpak bundle.

Locally one would use it like this:

docker buildx create \
  --name winboat-ctx \
  --buildkitd-flags --allow-insecure-entitlement=security.insecure \
  --driver docker-container --use
docker buildx bake flatpak

And in CI just tick the "With flatpak" box, it uses the same process, essentially.

I've had to add the security.insecure entitlement due to flatpak-builder's use of bwrap and namespaces (relevant issue flatpak/flatpak#3027).

Oh cool - I'll try it when I get time, hopefully this weekend. I was half expecting it to rely on the org.flatpak.Builder flatpak - but I'm a complete newbie when it comes to this side of things.