Flatpak release?

[MysteriousRSA]

I was just curious, that if the code was all cleaned up and any potential issues removed, would there be a possibility of a flatpak release to make it easier to install for more people?

I am also not sure if a flatpak release would even function properly or have the ability to work at all.

Thank you.

[Rififia]

It's only my opinion, but I think that the first thing to do in order to facilitate installs would be to add it to the major distributions' packages managers. People having just to apt install or use Discover or equivalent is in my opinion the simplest. Then we can think about flatpack or snap or AppImage if we want.

[MysteriousRSA]

The point of flatpak, if it's even possible, would be to Not have 5 different versions and instead have one universal version that'll work on all distros.

But with the little bit of knowledge I do have, I'm genuinely not sure if flatpak would work since it's containerised.

It's be nice to just... Open flathub and grab it, or an appimage as well

[Rififia]

one universal version that'll work on all distros.

Only if people have flatpak installed, which isn't necessarily the case. For the AppImage, yes it works without adding anything AFAIK, and the problem of updating might even not be an issue since there is an internal update system.

[Technetium1]

The Chaotic-AUR will build the package again once I'm satisfied again with the safety of the project. It was temporarily removed in chaotic-aur/packages@c370895.

[principis]

I have a Fedora copr repository for Noisetorch. (copr is like the AUR for Fedora)

It's sadly too much work to package NoiseTorch for Fedora. The packaging guidelines for Fedora require that everything is build from source, and all dependencies should be packaged. Since this project is using many dependencies which are not packaged for Fedora, all of them have to be packaged. The second difficult part is that most of them don't have a release schedule. I don't have the time to package all of them, so the copr repo should be sufficient for now.

golang(github.com/BurntSushi/toml) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/BurntSushi/xgbutil) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/BurntSushi/xgbutil/ewmh) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/BurntSushi/xgbutil/icccm) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/aarzilli/nucular) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/aarzilli/nucular/font) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/aarzilli/nucular/label) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/aarzilli/nucular/style) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/blang/semver/v4) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/lawl/pulseaudio) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(github.com/syndtr/gocapability/capability) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64
golang(golang.org/x/crypto/ed25519) is needed by golang-github-noisetorch-0.12.0-1.fc35.x86_64

[cova-fe]

If someone is interested, I'm working on a Gentoo ebuild, as I was not able to find one already made. Flatpak (or appimage ofc) is not exactly fitting with Gentoo approach, so the need to have an ebuild. It will not cause any burden to developers though, as it relies only on the tar.gz or even github repo. (but if someone already did that ebuild, please let me know :) )

[mackshot]

I was just curious, that if the code was all cleaned up and any potential issues removed, would there be a possibility of a flatpak release to make it easier to install for more people?

I am also not sure if a flatpak release would even function properly or have the ability to work at all.

Thank you.

Yesterday the same questions popped up for me as well. Having NoiseTorch as flatpak would also add some new layer of security here assuming we have at least some trust in flatpak containerization.
I personally feel having NoiseTorch as flatpak release should be 1) easy to do for the project owner @ZyanKLee (https://docs.flatpak.org/en/latest/first-build.html), 2) handy for many users thus, widen popularity of this project and thus active users and hopefully reviewers and 3) lower especially complexity for update process and may helps to get rid of some go reference like (if I get it right) untar.go and depending.
Of course having releases for all non-flatpak persons should be still considered, but maybe going for manual updating could be an option.

[Technetium1]

helps to get rid of some go reference like (if I get it right) untar.go and depending

I have no idea why there'd be a preference to use untar.go over GNU tar or bsdtar, which is almost absolutely installed on whatever machine is about to have NoiseTorch, and is actually actively developed and audited, alongside it's underlying libraries. It seems rather silly to use Go simply for the sake of it being Go.

[mackshot]

Please note, some thoughts of lawl regarding flatpak, snap and AppImage can be found in this issue #39.

[TheDukeofErl]

One thing worth noting here is that for a flatpak distribution of NoiseTorch pulseaudio support may have to removed (or made into a build option for inclusion). It seems that there may not be a good way to set the necessary capabilities for pulseaudio functionality within flatpak. I'm basing this off of discussion in #157.

If anybody knows of a way around the capabilities issue packaging this up in flatpak format for distribution would be a more-easily approached task. After things are back off the ground here, I think that this is a good thing to look into in the longer term, especially as an immutable root filesystem (Fedora Silverblue, SteamOS 3) seems to be a far more prevalent thing on the horizon.