Allow Organic Maps beta channel to track latest upstream

[bam80]

We pretend our master is good enough for testing by end users, so we would like to be able track upstream for flathub-beta channel.

Currently have error if commit is not mentioned:
https://buildbot.flathub.org/#/builders/26/builds/6014

This is the similar situation as flathub/flathub#3588

@biodranik @barthalion

[hfiguiere]

flathub beta is NOT for nightly builds either. Build MUST be reproducible which mean bare branches are not allowed.

[bam80]

But that's about exception, right? And it was accepted for Totem. We are at the same position I guess.

[barthalion]

See, that's the problem with making exceptions. When you agree to do something once, it's only the matter of time before someone else reaches out. I'd rather rescind the Totem's exception that allow a new one.

[barthalion]

It's not a big deal to update the hash of a commit to be built; it's no more work than having to go to buildbot and starting a new build. I will be contacting Totem maintainer about it.

[bam80]

Do you know if we have similar concept as edge channels on Snaps? Or maybe it was requested somewhere?

[hfiguiere]

the examples you give is operated by for profit companies... Flathub is still run on a shoe string budget, and mostly operated by volunteers.

(edit: I misread edge, because naming is hard)

[barthalion]

We're slowly opening up to builds uploaded from external CI systems, but even with that, disk space and bandwidth don't come for free (and I don't mean money here, we don't want regular use cases to be bottlenecked by nightly builds).

As opposed to Snap, anyone can host a Flatpak repo.

[biodranik]

We publish releases of Organic Maps from the master branch and try to keep it always releasable. It would be great to automate testing as there is a plan to make a great desktop/mobile Linux UI.

[bam80]

disk space and bandwidth don't come for free

FWIW, ostree stores deltas only so it should be negligible?

[nanonyme]

@bam80 no, deltas are mostly for in-transit optimization. ostree does store all data (deduplicated) normally.

[bam80]

@nanonyme I'm not an expert but I'm not sure ostree stores the data duplicated, at least until you didn't install both (mostly duplicated) flatpaks. Could you elaborate?

[nanonyme]

@bam80 ostree stores same file exactly once assuming you handle metadata correctly. This allows you to have files stored only once if you have gnome, freedesktop-sdk and kde runtimes installed with matching base runtime.

[bam80]

@nanonyme that's what I expected.
What I mean is the repo(on server) probably tries to hold deltas only so there should be no concerns if we have extra builds there which are mostly duplicated.

Having that, I'm not opposing anyone.
If what has been suggested in OP is not going to happen, let's close this issue.

[nanonyme]

The thing is, there is such a concept in ostree as deltas. They are a delivery optimization method. They are not used for storage optimization.

[bam80]

So if you have two mostly the same files, they occupy twice storage in the repo on server anyway?

[nanonyme]

Yes. You need to reproducibly produce exactly same files for deduplication.

[bam80]

OK, I didn't know it (however, it's strange. I hope you know what you are saying).
But if you changed a few lines of code, the reproducibility won't help here, as the binary will be duplicated and it's clear now why this request can't be satisfied.
Probably we can close it then, thanks.

[bbhtt]

Probably we can close it then, thanks.

Closing as per above.