Open soumyaDghosh opened 3 months ago
It would definitely be a great thing to finally have a Pipewire implementation that actually works with Snaps!
Are you sure about pipewire? I mean: pipewire runs outside, in the "host" operating system, and in 24.04 the patch is applied, those permissions are being enforced (just checked again right now, just in case). It doesn't have to be added in gnome-46-2404-sdk.
I also just learned that the hosts pipewire is being used by the JVM inside the snap.
What I can say with certainty, however, is that the current version of pipewire1.0.5 which comes with Ubuntu Noble 23.04.1 does not work with snaps running an openJDK 21 based JRE.
Could not load native libraries for ScreencastHelper
https://forum.snapcraft.io/t/pipewire-doesnt-work-in-snaps/40235/24
Oh, ok... but that problem is different, and my patches have nothing to do with that.
Are you sure about pipewire? I mean: pipewire runs outside, in the "host" operating system, and in 24.04 the patch is applied, those permissions are being enforced (just checked again right now, just in case). It doesn't have to be added in gnome-46-2404-sdk.
I didn't actually created this PR for the issue mentioned above, but rather for some other reasons
To have up to date pipewire in the sdk also, as the sdk lacked the development libraries.
For the patches you made. (Not an expert so didn't know those things will work even without them not in the snap)
Gnome Apps that use Camera will never work without libcamera ,latest pipewire and gstreamer pipewire built using that latest pipewire. Snaps like Snapshot, Decoder (or others which also uses the libaperture library created by Gnome for snapshot) will never work properly without a very shiny gstreamer pipewire and latest libcamera+pipewire.
But still, what is the problem in building it from the source? Is there really any downside of it?
The downside is that it will be included inside your snap, occupying a lot of space for no reason. Also, it's easier to just add an entry with
build-packages:
- libpipewire-0.3-dev
than to build the complete pipewire. Or, at least, that's my opinion...
To reiterate some context on the JVM bug linked above, Java is being weird in requiring libpipewire
itself, because in most applications you'd call the XDG Desktop Portals directly exclusively which operate through DBus alone. The problem in that thread is exclusively to the interactions between Java and Snap, and isn't reflective of any other programming language / environment. And we've not even confirmed it's actually libpipewire
even throwing that error, there's more than one way that error message in the thread could come about even if libpipewire
itself is correctly being linked.
From the concept of the portals, the whole pipewire
aspect is an implementation detail that could be swapped out in the future at any point; while practically speaking Java isn't wrong in assuming Pipewire will stick around for a while and can integrate further with it.
Pipewire isn't anymore special than e.g Pulseaudio, which you don't bundle the full stack with snaps either because it's a client server/model where the server lives on the host, just like Pipewire, X11, Wayland, etc. (All of this is ignoring Ubuntu Core).
The downside is that it will be included inside your snap, occupying a lot of space for no reason. Also, it's easier to just add an entry with
build-packages: - libpipewire-0.3-dev
than to build the complete pipewire. Or, at least, that's my opinion...
Why will this be in a snap? And also the content anyways have pipewire in it. So, just replacing the repo pipewire with pipewire from source, I don't think will create much difference.
https://github.com/ubuntu/gnome-sdk/blob/gnome-46-2404/snapcraft.yaml#L183
The pipewire in the repos doesn't have the pipewire with snap support that @sergio-costas recently added. Also builds libcamera from source, as they are not in the repos with their latest releases.
https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.1.81