Bug#1086668: pulseaudio: New upstream release v17.0

[Alper Nebi Yasak]

I had found the changes from previous NMUs in js/webrtc-audio-processing
and continued on top of that. I opened merge requests for all now, but
salsa is having a hard time processing things:

[1] pulseaudio: Update to version 17.0
https://salsa.debian.org/pulseaudio-team/pulseaudio/-/merge_requests/29

[2] pavucontrol: Update to version 6.1
https://salsa.debian.org/pulseaudio-team/pavucontrol/-/merge_requests/6

[3] webrtc-audio-processing: Import NMU changes originally from js/
https://salsa.debian.org/pulseaudio-team/webrtc-audio-processing/-/merge_requests/2

[4] webrtc-audio-processing: Update to version 1.3
https://salsa.debian.org/pulseaudio-team/webrtc-audio-processing/-/merge_requests/3

Thanks,
Alper


On 2024-12-11 15:40 +03:00, Sebastien Bacher wrote:
> Thanks for pointing out that webrtc-audio-processing is also team 
> maintained, I will start reviewing those updates then. Did you work 
> based on the packaging vcs and if so could you propose merge requests 
> for your changes?
> 
> Cheers,
> Sébastien Bacher
> 
> Le 10/12/2024 à 23:44, Alper Nebi Yasak a écrit :
>> Hi Sebastien,
>>
>> On 2024-12-11 00:48 +03:00, Sebastien Bacher wrote:
>>> Hey Alper,
>>>
>>> I would be happy to help on the pulseaudio side since I've access to the
>>> Vcs and did update for that package before but we need to unblock the
>>> webrtc-audio-processing frsit. That package isn't team maintained and
>>> the new version would require a rename of the binaries/transition so
>>> that's not really something I feel confortable NMUing unless we get an
>>> ack from the maintainer...
>>>
>>> Perhaps we could get pulseaudio 17 in experimental without the
>>> webrtc-audio-processing option enabled as a first step?
>> I already have a patch to build it with webrtc-audio-processing = 0.3 as
>> that's in unstable, by using an older version of the single file that
>> uses the library. I think that's enough to unblock things? Then I think,
>> dropping the patch and updating a Build-Depends would be enough to allow
>> pulseaudio to go through a potential webrtc-audio-processing transition.
>>
>> (FYI: I see "Maintainer: Pulseaudio maintenance team" in
>> webrtc-audio-processing d/control, and last non-NMU upload was in 2016.
>> But it's OK if you still don't want to go forward with it.)