<moreentropy>
I'm more of a cloud/infrastructure person, but sometimes I tinker with microcontrollers. As I have a siglent scope, I wanted to play with ngscopeclient. I'm a fedora silverblue user, and the only/best way to run 3rd party software on this kind of distribution is flatpaks. So I used ngscopeclient as a learning excercise on how to build flatpaks.
<moreentropy>
long story short, now I have a seemingly working flatpak manifest for ngscopeclient. Would this be a welcome contribution?
<azonenberg>
I know very little about flatpak but gearing up towards the v0.1 release in the next few months we do want to make it usable on as many platforms/distros as possible via whatever packaging format people like
<moreentropy>
short history: It's one of those application sandbox systems (Canonical's snap and "appimages" being the other two). Compared to snaps which rely on a proprietary "app store", flatpaks can be distributed as single file downloads, in a self-hosted repo or the https://flatpak.org platform - which is where everyone is looking for them. Technically
<moreentropy>
flatpaks build on one of a few defined userland / sdks ("freedesktop sdk" and derived of that are a gnome and kde sdk) which is updated once per year and contains a baseline of libraries. everything not included is supposed to be built into the individual flatpak. the flatpak mainfests are yaml files defining a list of modules to be included by
<moreentropy>
referring a source locating and build system / parameters (meson/cname/you name it). the tooling to install/use flatpaks is included or available in about any distribution.
<azonenberg>
Yeah i knew that much. I definitely prefer native packages but if this is an alternative to not being usable at all on distros we don't have native packages for
<azonenberg>
i dont see why not
<moreentropy>
Just not sure right now what's the best way to actually include a flatpak manifest into a project - if that's supposed to live in the project repo and a pull request is appropriate or if flatpak manifests are best hosted in a separate repo. looking into this.
<azonenberg>
That I dont know
<azonenberg>
I know distro packaging normally is done within the scope of the distro and not the project
<azonenberg>
I do want to have CPack based packaging scripts in the project eventually so we can make unofficial .deb, .rpm, etc packages for nightly builds
<moreentropy>
so they would strongly prefer for the upstream project to submit and have commit access to their manifest
<azonenberg>
Makes sense
<azonenberg>
Well, this is definitely something we'll look into, i'm planning to have a developer meeting soonish and we can talk about packaging in general then
<azonenberg>
(it was planned for before christmas then I got sick, then everyone was gone for the holidays, and i'm just getting back on top of things now)
<moreentropy>
I could put the manifest & small patch I have into a temporary repo to hand it to you - I don't really have any intentions to be involved in maintaining this, just happy to contribute - or hand over the manifest in any other preferred way - its just a yaml file & small .diff
<azonenberg>
Yeah sounds worth playing with. I just dont have any time to spend on it right now
<moreentropy>
no worries. I'll just put it into my github in a sec and leave it there for you to tinker when/if you want to if that's ok