Flatpak Maintainer Needed
Anyone willing to maintain a Flatpak version? Doesn't have to be a lot of maintenance since we don't release new versions as often.
If yes, please let me know and I'll add you to the Upscayl team.
Thanks!
@PranavBhattarai has stated that they'd like to.
I could also help.
Yes, I am just wondering why I cannot find it on flathub
@dtantono see https://github.com/upscayl/flathub
it pointed different app

no, i mean it hasn't been merged by falthub yet
@JanDeDinoMan Would you happen have time for something like this?
Is there a tutorial or a blog that I can read in order to maintain this?! I don't know how to do this.
https://docs.flatpak.org/en/latest/first-build.html
If nobody is working on it I could have a look on it on my free time.
If nobody is working on it I could have a look on it on my free time.
That would be amzing :D
So currently me, PranavBhattari, and luca-denma have volunteered yo help, to sum it up
@aaronliu0130 I'll add you to the team
@aaronliu0130 @luca-demma I've given you access to https://github.com/upscayl/flathub/ :)
@NayamAmarshe I have contributed to the https://github.com/upscayl/flathub/tree/org.upscayl.app branch of the flathub repository because the contributing guidelines required adding the manifests in a separate branch named by the ID. I recently noticed that you and someone else duplicated some changes in the master branch. What should we do? Should I just ditch that branch and change the master branch to the separate branch?
@NayamAmarshe I have contributed to the https://github.com/upscayl/flathub/tree/org.upscayl.app branch of the flathub repository because the contributing guidelines required adding the manifests in a separate branch named by the ID. I recently noticed that you and someone else duplicated some changes in the master branch. What should we do? Should I just ditch that branch and change the master branch to the separate branch?
There are several issues with our flathub PR. Firstly, some files need to be in the release zip. Secondly, our ID is completely wrong, they don't allow domains that we don't own. So we need to release a new version just for flathub, which I don't think is worth it.
It's a lot of work, I'm holding off the flathub release for now. I wish it could've been simple like snap, maybe we should release a snap package instead.
Please, preserve the flatpak package. Multiple GNU/Linux distributions move to immutable OS, like Fedora Silverblue, OpenSuse MicroOS, EndlessOS, Vanilla OS or even ChromeOS. On theses, the flatpak is the prefered installation method and some time there is no other option at all to not add layer to your host OS. From my point of view, immutability will surely dominate the market in the future for security / reliability reasons. Thank you so much for your time on the project, and on doing the flatpak package!
@lakano IMO the entire concept of these self contained managers is just JVM all over again, for all I know things like apt yum rpm and pacman are preferred. Plus even if we’re restricted to the domain of portable managers, doesn’t appimage still exist? It’s much less of a chore and accomplished everything about flatpaks
@aaronliu0130 I think you misunderstood how works immutable OS, because JVM need to interpret is own bytes-code, so it's a waste of performances indeed, but Immutable OS uses kernel virtualisation (cgroups) to isolate / limit resources of each programs, there is no waste of performances like with JVM. In a immutable OS, the repository of the distribution stills exists but only for the core packages, because the main goal is to have a safe OS than can't be destroy ( your root filesystem is read-only, after a reboot everything is clean like the last upgrade ).
The goal of flatpak, is to permit to have everything inside the package, including for example the codecs, and reduce all the random dependencies for the core packages of the "host" system.
Between Flatpak and appimage there is big differences too, appimage is more like an executable zip, but even if they claim to be portable, they require sometimes dependencies on the host system, so it's not 100% portable. AppImage doesn't have isolation like flatpak, so the security is better in Flatpak. Fedora have converted a lot of their packages in Flatpak too, and with MicroOS of OpenSuse (the one I'm using) I suppose OpenSuse will may be help to increase the number of Flatpak packages too.
You should may be try one of theses one day if you're interested :-)
I'm waiting for the Flatpak release (I want the sandboxing), but what I see, even in the new manifest, no Wayland support is there (so it means effectively no sandboxing), is anyone interested in working on this, or it's abandoned right now?
It's basically abandoned, see NayamAmarshe's comment on Jan 11
Ok, I see.
1a. upscayl.org is currently open to registration, I would HIGHLY recommend to register it, since it's cool domain and also it improves the credibility of the project
1b. you can change id of application to the org.github.upscayl (which I don't think is the best way to roll, but ...)
3. flatpak can use zip, tar, git, whatever.
If you need a bit help, ping me.
We currently have upscayl.github.io which is free. The domain is open to registration but that would need money and it is unlikely for another project to take over it. Still a good point of contention though.
@aaronliu0130 well then, you can risk it and sent it with current appid to the Flathub. Since the domain isn't currently utilized, it shouldn't cause any troubles. The Flathub requirement is there to prevent rogue projects to pretend they're something else (I assume).
We don't have every file we need in the release zip yet.
Ok, if you prepare it on release side, I'll try to give you hand with the flatpak stuff :)
Thanks for the help @okias I am currently working on Upscayl v2.5, will let you know when we're close to release.
I can buy the domain, it's not a problem. It's just that I don't want the domain to go to waste in a few years and just end up with a 404.
@NayamAmarshe if you don't plan to abandon the project, then I think it make sense :laughing: also you can be sure no-one buy the domain and take your SW, inject some malware and publish it.
@NayamAmarshe if you don't plan to abandon the project, then I think it make sense :laughing: also you can be sure no-one buy the domain and take your SW, inject some malware and publish it.
Ok, I'll think about it
you don't need a domain. Just use io.github.upscayl.Upscayl like many other projects do.
you don't need a domain. Just use
io.github.upscayl.Upscayllike many other projects do.
I bought the domain upscayl.org