Hello Sergey :) I thank you for making this package, as I needed it to build the latest versions of pipewire. I branched your package to my home repo for this purpose, since upstream official builds do not have anything newer than 0.3.1. So, thank you for leading the charge!

In my repo, I only made a few minor changes to the service file, to use the 1.3 tag (rather than latest tip of the tree as in your build) and automatically generate the changes file from the sources.

I had a conversation with the pipewire developers who are using this new version of the library now, rather than the old 0.3.x versions. Here is a link to that convo: https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1f1c308c9766312e684f0b53fc2d1422c7414d31

We discussed the naming of the module, as it was not clear if I should be using "webrtc-audio-processing", "webrtc-audio-processing1" (as seen in another user's OBS build), or "webrtc-audio-processing-1" (as seen in pipewire's source). They clarified that, in order to enable concurrent parallel installations of both versions of the library, the naming schema would change for 1.x, and it should be "webrtc-audio-processing-1". I thought this would be useful information for you, as I notice your package is still providing "webrtc-audio-processing", but it is commented out, perhaps I was not the only one unsure as to what I should be 'Provide'ing :)

Hope this helps you, and thanks again!

Sergey Kondakov (X0F) - 12 months ago

You're welcome. It seems upstream package did a lot of changes to spec-file, so I have to reconcile them now. I think the convention is to let packaging system to get for 'provides' whatever package itself declares in its devel-files and then only add stuff that is expected by some other packages for some reason (like it having dumb or missing data out of the box or changing naming/versioning rules). The current package itself should always have most generic name and only static, unupdated 'legacy' duplicate branch-outs should have a suffix. And libs are supposed to change their 'soname' only when public API breaks which I don't think it did, so I'm not sure why they changed it this time.

---

pallas wept (pallaswept) - 12 months ago

Yes you're right, upstream OBS made a lot of changes, it looks like the new version will hit factory very soon. They had to patch the source from upstream pulse, so that it would build on other architectures with gcc (instead of using clang like our builds which wouldn't work on ppc or ARM - not that I cared, but I guess it's important for factory to be portable) and also some other patches that upstream pulse haven't merged yet... But they did the naming schema change, so I can build pipewire/wireplumber against that build, and it looks to be working out OK.

Thanks for the education about how the soname is meant to work, I have some programming experience, but not with libraries, and I'm really new to packaging, so advice like that means a lot to me. Now that I'm an end-user and not coding for work, I want to help contribute to the tools I use, and people like you with more experience with this kind of thing have been really helpful. I appreciate it a lot mate, thanks!