Pulseaudio module migration gconf => gsettings

Ben Cooksley bcooksley at kde.org
Wed Jun 27 12:09:32 BST 2018


On Wed, Jun 27, 2018 at 7:42 PM, Luigi Toscano <luigi.toscano at tiscali.it> wrote:
> On Wednesday, 27 June 2018 07:53:48 CEST Ben Cooksley wrote:
>> On Wed, 27 Jun 2018, 11:16 Maximiliano Curia, <maxy at gnuservers.com.ar>
>>
>> wrote:
>> > ¡Hola David!
>>
>> Hi Max,
>>
>> > El 2018-06-26 a las 08:23 +0200, David Rosca escribió:
>> > > Hi,
>> > >
>> > > On Mon, Jun 25, 2018 at 11:01 PM Martin Steigerwald
>> > > <martin at lichtvoll.de>
>> >
>> > wrote:
>> > >> Hi!
>> > >>
>> > >> The unfixed bug
>> > >>
>> > >> Bug 386665 - Drop dependency on pulseaudio-gconf
>> > >>
>> > >> makes plasma-pa uninstallable in the development versions of Debian and
>> > >> Arch.
>> > >>
>> > >> We would really appreciate an upstream fix for that one. The comment by
>> > >> Luigi points out commits for paprefs gconf => gsettings migration.
>> > >> Maybe
>> > >> something similar would work with Plasma PA?
>> > >>
>> > >> https://bugs.kde.org/show_bug.cgi?id=386665#c13
>> > >>
>> > >> Would someone help David Rosca (in Cc) in case he is unavailable or has
>> > >> no time to attend to the issue?
>> > >
>> > > We are aware of the issue and are planning to port to gsettings.
>> > > Actually, it may be added as alternative to gconf as otherwise it will
>> > > break the functionality for distros that doesn't have PulseAudio 12
>> > > yet. For now, I'll make the gconf dependency optional.
>> >
>> > You might want to use the frugalware patch [1] as a base for this. This
>> > patch
>> > is mentioned in the kde bug (although it wasn't linked), I was considering
>> > using something like that, before plasma-pa gets removed from Debian
>> > testing
>> > (if it comes to that).
>>
>> I'm not hugely happy with the inference here that if we don't address this,
>> you'll be removing the Pulseaudio applet. Given that controlling system
>> audio is a rather crucial part of the desktop experience, it's a bit
>> disappointing you're thinking of resorting to that.
>>
>> Given how the Salsa changeover was  handled (both the migration and
>> subsequent unannounced rearrangements of your repositories) along with the
>> above statement I'm considering whether the Debian KDE Team as a collective
>> needs to be referred to the CWG as the severe lack of in advance
>> communication from your side, which in turn creates unreasonable distress
>> on members of our community.
>
>
> Ben, you are shooting the messenger and there is a misunderstanding coming
> from a lack of knowledge on how Debian works.
>
> The dropping of the pulseaudio gconf subpackage It's not a decision of the
> Debian KDE Team. This is a decision of the Debian Pulseaudio packagers, and
> according the other comments from the bug, other distributions are doing
> exactly the same.

Having looked at the exchanges made by the Debian Pulseaudio
maintainer, they appear to have completely ignored plasma-pa, so their
position of refusing to support GConf (when GSettings support has only
just been introduced by Pulseaudio upstream) is quite unconscionable.
No notice has been given at all. They should be compelled to restore
that support to allow for a reasonable window for us to port.

Given how new the support in Pulseaudio is, it is unreasonable to
expect us to have support ready for it in such a short time frame.

>
> The sentence "I was considering using something like that, before plasma-pa
> gets removed from Debian testing (if it comes to that)." simply means:
> - I was planning to use that patch in case pasma-pa is *automatically* removed
> from testing because one of its dependency is missing
> which is referring to an automatic process and the availability of a solution,
> the same solution *already* applied by other distributions where the gconf
> subpackage is disappearing too. Not sure why Debian would be different and
> where the stress it.

There was no mention of automatic removal in his previous mail, which
does change the situation.

My previous understanding was based on this being a *manual* process,
which makes his statement more of a "you have to do this or we'll
remove a key part of the desktop experience".

>
>
> Regarding the communication of the issue, the upcoming removal of the package
> was mentioned exactly 3 months ago in the bug.

While that may have been the case, no option for replacing the
affected functionality was offered or available in any form at that
time, so it's quite understandable that no action was taken on our
side at that time.

>
> Please reconsider what you expressed above.
>
> --
> Luigi
>
>

Regards,
Ben



More information about the Distributions mailing list