gnome-sdk icon indicating copy to clipboard operation
gnome-sdk copied to clipboard

Build pipewire and libcamera from source

Open soumyaDghosh opened this issue 1 year ago • 10 comments

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

soumyaDghosh avatar May 24 '24 15:05 soumyaDghosh

It would definitely be a great thing to finally have a Pipewire implementation that actually works with Snaps!

RetGal avatar May 25 '24 12:05 RetGal

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.

sergio-costas avatar May 27 '24 10:05 sergio-costas

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

RetGal avatar May 27 '24 16:05 RetGal

Oh, ok... but that problem is different, and my patches have nothing to do with that.

sergio-costas avatar May 27 '24 17:05 sergio-costas

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

  1. To have up to date pipewire in the sdk also, as the sdk lacked the development libraries.

  2. For the patches you made. (Not an expert so didn't know those things will work even without them not in the snap)

  3. 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.

soumyaDghosh avatar May 27 '24 22:05 soumyaDghosh

  1. Just use the corresponding -dev package in the "build-packages" section. The wire protocol is stable, so there shouldn't be problems by using a different version from what is in "outside".
  2. Don't worry. Containerized systems like Snap and Flatpak are complex beasts. It's easy to begin with them, but the subtle details require time.
  3. In those cases, you should include your own libcamera in the snap, I presume. There is a limit in what a containerized system can do: if the "outside" has an old pipewire, there's little a snap or flatpak can do.

sergio-costas avatar May 28 '24 08:05 sergio-costas

But still, what is the problem in building it from the source? Is there really any downside of it?

soumyaDghosh avatar May 28 '24 17:05 soumyaDghosh

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...

sergio-costas avatar May 29 '24 07:05 sergio-costas

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).

JGCarroll avatar May 29 '24 11:05 JGCarroll

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

soumyaDghosh avatar May 29 '24 13:05 soumyaDghosh