Closed jongough closed 3 years ago
So sorry, perehaps I should drop doing the rpi?
Could we just postpone it a little, say to after Xmas?
Yes, of course.
I have started the attempts to set up a "cloud" for opencpn downloads, with focus on redundancy, availabilty and possibilities to handle stuff not easily hosted on traditional web services.
The first step is that that there is now two independent servers. End goal is more servers accessible in a transparent way using DNS which just picks a reandom, available server. However, we are not there. For now, the duplicated two servers are mumin.crabdance.com and gafsan.crabdance.com. Both offers http access:
http://xxx.crabdance.com/opencpn-dl
is the plugin downloader (https://github.com/OpenCPN/OpenCPN/issues/1865)http://xxx.crabdance.com/opencpn-flatpak-beta
is, despite it's name, the flatpak nightly builds repository.@jongough : It might make sense to add code in the build chain to use one of these server as fallback if the current fails. Eventually, this should be transparent, but setting up these things needs time.
@rgleason: We need more servers in the cloud, and after the holidays I will be able to talk more on this,.
mumin and gafsan are on the same MAN but have different ISPs and physical addresses around 1 km apart.
Ok, I think I will order a rpi and start.
@rgleason: I you have a need for a rPI for you own needs, that's of course up to you. But when it comes to a role in the anticipated cloud nothing can be said until at earliest after the holidays.
Alec, not a problem if you decide not to use it, however I will try to get it ready. Its a project I want to do anyway.
hm...
was now time to create a more 'formal' process for access to these files
In short: yes, we need a better solution. But cloudsmith, or anything like that doesn't fit the bill. I'll try to explain why, but this will likely become a too long post.
The flatpak build process creates a repository. This is based on ostree, which in many ways is similar to git. In particular, each build doesn't create a new file as other builds. It just creates a commit and tag in the repo. When you as user "downloads" an application you basically clone a repo, similar to a git clone.
The repo is quite large, currently about 300M.
Building opencpn flatpak plugins means that you need to install the opencpn flatpak application so you can link to it during the build. This is done by dowloading an opencpn.flatpakref or opencpn.flatpakrepo file. These are just pointers to the repo which makes it easy for users to easily add an application or repo to their own software. The basic contract is that if you can access these files you can also access the repo they refer to.
Storing the flatpakref/flatpakrepo file on cloudsmith would easily break this contract: since the repo might be unavailable while the files isn't. There will also be a synchronization problem. In short: we should IMHO keep the flatpakrepo/flatpakref files in the same server as the repo to keep the deployment simple and sane. More to come...
You might be interested to know that Flatpak is on the roadmap for Cloudsmith. So that might help in the near future if we support it as a native format. We already support other formats that are "git-like" (e.g. Cargo for Rust, and CocoaPods). It's meant to be a semantic repository after all, with intelligent support for formats so they work with native tooling like apt
and flatpak
, and not just a file dump (which is probably the least useful way to use Cloudsmith imho). :)
Thanks Lee!
Vote for flatpak support on the Cloudsmith development path. Only 2 votes so far. You need to register an account on https://trello.com/b/IhvGx4aN/cloudsmith-roadmap
Once you've voted you can "Watch"
Flatpak PackagesAlso see Formats for inclusion roadmap https://help.cloudsmith.io/docs/supported-formats#format-roadmap
Hi, hope you've had a nice Christmas
According to the Trello kanban link above, work on a cloudsmith flatpak integration will not start until at earliest Q2 2021. Even if it eventually becomes a viable alternative we IMHO need a solution sooner than that. So, while an interesting piece of info, it probably doesn't affect us right now.
To be frank, I also see challenges when it comes to hosting flatpak repos on a service like Cloudsmith. The combination of missing push support in ostree, very large repositories and an open-source offer without fees is, well, interesting.
EDIT: Remove link inserted by my touchpad. It wasn't me, for sure...
Merry Christmas and Happy Holidays to y'all too!
Sure, I get it. You'll appreciate that we drive development based on demand and that's why I mention it. In terms of the challenges, other than timeliness I don't see any issues with the others? Push would be supported (note: I realise you mean that a remote OSTree itself has issues, but we'd figure it out; since that's our job). Plenty of our repositories for others are well into the TBs range. OSS projects don't have fees. 😄
See https://github.com/OpenCPN/OpenCPN/issues/2296 Alec says " In general, production plugins should be built against the flatpak version available in flathub, this is users actually use.' (...not his little development server). (:-)
It appeared to me that Jon, in Testplugin, was using some circleci resources with a docker image, so that is possibly why Alec's server is used. Flatpak has a history with plugins and they are not completely resolved.
I don't believe we have access to that image (is this in "master.zip" perhaps? - later: no that is for android), and Jon is being denied access to circleci by US Treasury right now.
Flatpak Builder And as Alec suggested Available Flatpak Runtimes
I would like to get weatherrouting_pi and other plugins built and done for the summer with Flatpak and RPI builds and it is more involved to do this piecemeal.
The second try worked, but testplugin_pi FE Flatpak builds need to be changed to use the flatpak versions.
The core issue here is that my home servers are not fully reliable. However, to build flatpak plugins these servers are not required any more. In fact, using my servers should be considered deprecated. This is because my servers represents the development branch, not the stable branch used by users.
The stable branch is these days available on flathub (this was not the case when we started the flatpak builds). Thus, today the flathub servers should be used instead of my home server, see examples in the shipdriver repo. Given this, the original issue here is IMHO moot and should be closed
Jon, perhaps this can be closed now?
There is an issue with
http://opencpn.duckdns.org/opencpn/opencpn.flatpakref
, flatpak builds keep failing because this website does not respond and a timeout occurs. The file it is trying to get contains:Which refers to
Url=http://opencpn.duckdns.org/opencpn/repo
. The error that turns up in the flatpak build is:Is there some other way to install the required files for flatpak?