search

ubuntu / gnome-sdk

GNOME SDK/Platform snap
22 stars 21 forks source link

Build pipewire and libcamera from source #216

Open soumyaDghosh opened 3 months ago

soumyaDghosh commented 3 months ago

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

RetGal commented 3 months ago

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

sergio-costas commented 3 months ago

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.

RetGal commented 3 months ago

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

sergio-costas commented 3 months ago

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

soumyaDghosh commented 3 months ago

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.

sergio-costas commented 3 months ago
  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.
soumyaDghosh commented 3 months ago

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

sergio-costas commented 3 months ago

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

JGCarroll commented 3 months ago

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

soumyaDghosh commented 3 months ago

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