Bug 386665

it's used.

Thanks for the response - right, I guess my point was that gconf is an old gnome technology (one which a standard gnome install doesn't even use these days), so it's odd that KDE (actually only plasma-pa) requires it.

I am reopening this, cause this is becoming an issue for Debian Sid:

plasma-pa: Depends on gconf
https://bugs.debian.org/886048

According to this bug report, gconf has been replaced by gsettings and its last release has been 5 years ago.

So there needs to be an solution in order for Debian (and likely other distributions at that time) to keep plasma-pa. Currently Debian Qt/KDE team considers removing it.

See also

pulseaudio-module-gconf: migration to a dconf PA backend
https://bugs.debian.org/757909

Port from GConf to Gsettings
https://bugs.freedesktop.org/57743

for the status of approaches to solve this issue.

I do not know what the best solution is, but upstream Pulseaudio developer Tanu recommends not using gconf at all:

https://bugs.freedesktop.org/show_bug.cgi?id=57743#c2

However that would need extensions to Pulseaudio client API:

https://bugs.freedesktop.org/show_bug.cgi?id=57743#c4

I am not sure of the current state on this, since this comment was in 2014.

I think we can make the gconf dependency optional until we find a replacement.

(In reply to David Rosca from comment #6)
> I think we can make the gconf dependency optional until we find a
> replacement.

Thanks. I guess that would be an option. What functionality would break by running plasma-pa without gconf support?

>What functionality would break by running plasma-pa without gconf support?

Setting of module settings. The two checkboxes in the advanced tab of the KCM.

>but upstream Pulseaudio developer Tanu recommends not using gconf at all:

To clarify for the bug report. He is rerferring to upstream using it, not about us using the things upstream provides.

>I think we can make the gconf dependency optional until we find a replacement.

We can do manual load module/unload module ourselves, the reason I didn't was it clashes with this module and having two systems fiddling with the same thing leads to trouble. Using a PA module also has the advantage of things being set on start.

> We can do manual load module/unload module ourselves, the reason I didn't was it clashes with this module and having two systems fiddling with the same thing leads to trouble. Using a PA module also has the advantage of things being set on start.

Sure, but the issue in Debian that Martin Steigerwald posted is that plasma-pa links to libgconf which is going to be removed. So the easiest solution would be making libgconf optional and ifdef the code using it.

The other issue, which this bug actually is about, is the pulseaudio-gconf module, but that is only runtime dependency and we already handle the case when it is not available.

I suggested makeing it optional forever but small Distros gets ignored anyway.

So I patched the whole code out from day 1 that got added ..

Here's a quote from pulseaudio-12.0 release notes (https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/12.0/):

Notes for packagers
The GConf dependency can now be avoided

paprefs has so far required module-gconf to be loaded in the PulseAudio daemon, which is bad, because the GConf project is deprecated and unmaintained. paprefs 1.0 is expected to be released shortly, and that will use GSettings instead of GConf. The new paprefs version requires module-gsettings to be loaded in the PulseAudio daemon.

PulseAudio still provides module-gconf in case there's need for it. GSettings and GConf can both be enabled when building PulseAudio, but note that both modules should not be installed at the same time, so distributions should make module-gconf conflict with module-gsettings in their packaging system. It may be useful to enable both when building PulseAudio, so that PulseAudio can be updated before paprefs. If only GSettings is enabled, PulseAudio and paprefs need to be updated at the same time.

There can be some problems for users after updating paprefs. When module-gsettings is installed along with the new paprefs version, the module won't be automatically loaded by the PulseAudio daemon that is already running during the update, so any configuration changes done with paprefs will have effect only after the daemon has been restarted. Another issue is that if the gsettings-data-convert program is not installed, the old settings from GConf won't be migrated to GSettings. gsettings-data-convert is provided by GConf, so to ensure that the program is installed, the module-gsettings package would have to depend on GConf, but since the whole point of this exercise is to get rid of GConf, such dependency may not be feasible.

(In reply to David Rosca from comment #6)
> I think we can make the gconf dependency optional until we find a
> replacement.

Any progress on that? Probably with Pulseaudio 12 if paprefs can use gsettings, plasma-pa can too?

In the meantime, the Debian packaging for pulseaudio removed the pulseaudio-
module-gconf  subpackage and it's not coming back:
https://lists.debian.org/debian-qt-kde/2018/06/msg00436.html

Apparently paprefs was patched to use gsettings, see 
https://cgit.freedesktop.org/pulseaudio/paprefs/commit/?id=f758d167b54d42a309d0fcd3c784252cd9993df0
and later commits.

(In reply to Luigi Toscano from comment #13)
> In the meantime, the Debian packaging for pulseaudio removed the pulseaudio-
> module-gconf  subpackage and it's not coming back:
> https://lists.debian.org/debian-qt-kde/2018/06/msg00436.html

Ditto for Arch

Raising severity as this is an issue for at least two distributions now.

I build with gconf support disabled since some time. I have no idea what the code actually does, because I don't have gconf installed.

https://build.opensuse.org/package/view_file/home:cfeck:branches:KDE:Unstable:Frameworks/plasma5-pa/plasma-pa.diff?expand=1

My previous stance was that we can't/shouldn't port until pulseaudio upstream has something to port to. 

That is now the case, so I'll make the port. No need to keep flooding my inbox. It won't happen before 5.14.

(In reply to David Edmundson from comment #17)
> My previous stance was that we can't/shouldn't port until pulseaudio
> upstream has something to port to.

It seems everyone seems to have different expectations here:

- Pulseaudio project appears to expect that people port over to gsettings at the *first* release with gsettings module, maybe due to technical difficulties of providing both modules (and synchronisation between them).

- Debian Pulseaudio package maintainer just uploaded Pulseaudio to upstream, instead of providing it in experimental in order to allow packages to be ported, arguing that gconf module has been deprecated (without proper replacement) since a long time.

- KDE upstream expects to have something stable to port to before starting the work.

All totally valid expectations, each with their own reasons. Just they do not go well together. Clearly communication about how to coordinate this migration has been missing. I am just trying to make up for that now as the past is how it is.

So instead of trying to point at each over in an attempt to fix the past, I think it is helpful to work constructively to resolve the issue in the here and now.

> That is now the case, so I'll make the port. No need to keep flooding my
> inbox. It won't happen before 5.14.

So that means dropping gconf module support seems to be the only valid option.

My question at what functionality would break for our users from Comment #7 remains unanswered so far. Does anyway actually now it?

Sure one can argue they are "just" Debian Testing/Sid users, but leaving important functionality broken for them for a extended period of time is not nice to their willingness to take some risk in order to test the development versions of Debian. Also depending on release schedule and Debian Qt/KDE team decision Plasma 5.14 may *not* end up in next Debian stable, meaning that the affected functionality may be broken for the next stable release. Plus all Ubuntu releases depending Debian at a certain point in time. I.e. for *years* to come.

So can anyone answer whether any important functionality breaks when building without gconf support (and any replacement for it)?

Sorry, did not proofread it immediately:

(In reply to Martin Steigerwald from comment #18)
> (In reply to David Edmundson from comment #17)
> So that means dropping gconf module support seems to be the only valid
> option.

*for now*

> My question at what functionality would break for our users from Comment #7
> remains unanswered so far. Does anyway actually now it?

anyone actually know it?

I already answered to your e-mail:

> Here's the patch: https://phabricator.kde.org/D13734

This is what will not work:

> Two checkboxes under Advanced tab in KCM:
>
> * Add virtual output device for simultaneous output on all local sound cards
> * Automatically switch all running streams when a new output becomes available
> 
> Those will be now hidden when building without GConf.

The plan how to resolve this is to make it possible to build without gconf now (see the mentioned patch), and later port to use GSettings instead of GConf (or rather GSettings in addition to GConf, as not all distros will ship with PulseAudio 12).

Is there any feature that needs gconf but not pulseaudio-gconf? In other words: once pulseaudio-gconf has been dropped from our distro, is there any reason why we would still want to build plasma-pa with gconf support?

(In reply to Antonio Rojas from comment #21)
> Is there any feature that needs gconf but not pulseaudio-gconf? In other
> words: once pulseaudio-gconf has been dropped from our distro, is there any
> reason why we would still want to build plasma-pa with gconf support?

No, gconf dependency in plasma-pa is only for interacting with pulseaudio module-gconf, so if you don't have that, there is no reason to build plasma-pa with it.

(In reply to David Rosca from comment #20)
> I already answered to your e-mail:

I think we both wrote on different channels at the same time. Sorry for having been impatient here. I got annoyed by this issue. Better to just use one channel in the future (kde-distro-packagers list in that case).

Thread in kde-distro-packagers list:
https://mail.kde.org/pipermail/kde-distro-packagers/2018-June/000332.html

Christophe Giboudeaux additionally mentioned that virtual devices in general will break:

> Virtual devices. The openSUSE maintainers for pulseaudio tried removing the
> gconf plugin and it made my virtual card to have sound both on my speakers & 
> USB card disappear.

To me it seems its dropping gconf module for now.

Anyway, things settled now, so we all can get back to work :)

In case anyone needs more confirmation, this is now also an issue on Gentoo since they marked Pulseaudio 12.0 as stable.

11.x still had the "gnome" USE-flag which pulled in the aforementioned (and now deprecated) dependencies. This has been removed from 12.0 for obvious reasons, now the plasma-pa package refuses to build against this latest Pulseaudio here. But plasma-pa is pulled in as system dependency when using the global "pulseaudio" USE-flag. The vicious cirle begins once again.

Only current workaround is to limit the package manager to only install Pulseaudio <12.0 - therefore you can have my vote :)

As Ubuntu is merging pulseaudio 12 from debian, Kubuntu is also having to follow suit with debian patches and changes dropping gconf.

Git commit c9fae1fb3f8e8a820fd480ce227d7fabf87bd045 by David Rosca.
Committed on 13/07/2018 at 11:23.
Pushed by drosca into branch 'master'.

Make GConf optional dependency

When building without GConf, Advanded Output Configuration will be hidden in KCM.
FIXED-IN: 5.13.4

Differential Revision: https://phabricator.kde.org/D13734

M  +7    -2    CMakeLists.txt
A  +3    -0    config.h.cmake
M  +13   -5    src/CMakeLists.txt
M  +4    -1    src/kcm/package/contents/ui/Advanced.qml
M  +38   -9    src/modulemanager.cpp
M  +3    -0    src/modulemanager.h

https://commits.kde.org/plasma-pa/c9fae1fb3f8e8a820fd480ce227d7fabf87bd045

Git commit e04e034c24b832fb7803c14e1f99f4b46beab831 by Nicolas Fella.
Committed on 31/03/2019 at 15:08.
Pushed by nicolasfella into branch 'master'.

Port from GConf to GSettings

Summary:

As discussed in bug 386665 GConf is deprecated and needs to be replaced by GSettings to keep features enabled.

Question: Do we need GConf as a fallback for PA versions without module-gsettings?

Test Plan:
Checkboxes in Advanced tab are enabled again.
Changed settings are shown in dconf-editor and vice versa.
Combine output checkbox shows/hides combined sink in applet

Reviewers: drosca, davidedmundson

Reviewed By: drosca

Subscribers: pino, lbeltrame, evpokp, rikmills, broulik, asturmlechner, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D14147

M  +10   -5    CMakeLists.txt
A  +72   -0    cmake/FindGIO.cmake
M  +2    -1    config.h.cmake
M  +15   -3    src/CMakeLists.txt
A  +91   -0    src/gsettingsitem.cpp     [License: LGPL (v2.1)]
A  +59   -0    src/gsettingsitem.h     [License: LGPL (v2.1)]
M  +4    -4    src/kcm/package/contents/ui/Advanced.qml
M  +54   -25   src/modulemanager.cpp
M  +8    -6    src/modulemanager.h

https://commits.kde.org/plasma-pa/e04e034c24b832fb7803c14e1f99f4b46beab831