Add Sanctify #540
Add Sanctify #540
Conversation
|
Does this work on the final release of OS8 with pipewire as the default audio server? Not sure if that forces any change to the flatpak permissions necessary |
|
In your appdata, in the name tag, you misspelled Sanctify as Santify (though that fits the festive time of year here in the US :P) Since your oars rating is all none I believe if you'd like you can simply use |
|
You should update the flatpak yml to grab 1.0 instead of 0.9.9! |
|
I have been using pipewire for sometime now. I don't have os8 yet but it might work. Will fix the typo. I can't set the release to the current one because of how the pipeline works. The flatpak pipeline uses build artifacts from Godot pipeline uploaded in a prior release. So for flatpak pipeline to work there has to be a release containing the files. Essentially here 0.9.9 is the same as 1.0.0 |
Okay, mostly just curious if the portals work properly with pipewire. If it works on OS7 it probably works on OS8 as well. And now that I think about it I did swap over to pipewire myself on OS7 and that is what I am testing with lol
Woo!
I see. Okay! I kind of want to poke at things with flatpak to see if there is something a little simpler you can update the manifest to. |
|
Fixed the typo and the oars stuff. |
|
@danirabbit Do we want to worry about passing ARM builds with games, or bypass that requirement? |
|
Dani did mention on Discord that arm is still experimental, it's good to have and not an absolute requirement. Also currently I dont have the pipeline setup to build arm and I have no way of testing arm builds. |
There was a problem hiding this comment.
You should not have - '--system-talk-name=org.freedesktop.Accounts' in your flatpak manifest. This is not required for system wide dark mode. Your app should use the portal for this
Is there a reason you have - '--filesystem=home'? That's a pretty broad permission
I'm also really really hesitant to allow a pre-built binary here. We've always required things to be built on our server to make sure the source code you present and we've reviewed is actually what's in the package. This would break our promise of AppCenter apps being auditable
|
At the moment it's not known how to access portals from the Godot Engine, without upstream support for it. So, that system talk is only thing the engine is recognizing for it's built-in dark mode support. Building the game in the flatpak pipeline would required either building the engine or having the engine preinstalled in the image. I tried building the Godot engine from source in the flatpak pipeline, but it didn't work. Also, if you want to audit the code, it's all opensource anyway. File system home is being used for Godot's save game system. https://docs.godotengine.org/en/stable/tutorials/io/data_paths.html |
|
Touching acccountservice here is a hack and will probably break in future versions. Is there really no way to access dbus? Well I know that for you it's probably true that the source in your GitHub repository is the source used to create your binary. But as a rule for an App Store, how can we verify this for other people? If we set a precedent to allow people to upload binaries I think that's really dangerous. We could maybe make like a rule that you can upload a binary if your app is 100% sandboxed but with broad permissions like home I don't think that's workable. It feels like people could really abuse that to cause big problems |
|
Let me try some ways. |
|
I have made some changes to the manifest but first we need to add the Godot base app to the repo for it to work. |
|
Updated release signature to one which is compatible with AppCenter flow. Thanks @davidmhewitt and Cassidy for helping with this. |
Review Checklist
AppData
Flatpak