SUMMARY libproxy has support for KDE5/KF5 since 2016 or so. But on KDE neon it seems to ignore the KDE proxy settings whatever I do. The actual issue which made me look into this is because the Chromium flatpak package doesn't pick up my proxy settings properly even though I have the proper portal installed. I am not sure if that portal actually uses libproxy but the KDE neon libproxy is "broken" anyway. I have the bad feeling that this is some kind of rabbit hole and the bug is actually within the Debian libproxy package. But since I use KDE neon and you probably have better means of debugging this and better connections to Debian/Ubuntu than me, I start here. The reason I think this issue might be in the Debian packages are * There exists and additional package is called "libproxy1-plugin-kconfig" and its description was not updated for quite a while (still talks about KDE 4 only) * The version is not the newest but there are no relevant changes in https://github.com/libproxy/libproxy/compare/0.4.15...0.4.17?diff=split#diff-3dbb675e161f4d417c91967f12d5a0040becc75023d2931c890cce78d64e6eac (at least regarding the file libproxy/modules/config_kde.cpp) * Official support for KDE5/KF5 is already present in the version installed Side note: Shouldn't KDE neon install libproxy1-plugin-kconfig per default? (Assuming it works of course.) STEPS TO REPRODUCE 1. Install the libproxy tools and KConfig backend via `sudo apt install libproxy-tools libproxy1-plugin-kconfig` 2. Configure a proxy in KDE, for simplicity: 2.1 Use manually specific proxy configuration 2.2 HTTP Proxy: 127.0.0.1 Port: 8080 2.3 [x] Use this proxy server for all protocols 3. Open Konsole 3.1 Execute `proxy <<< example.org` OBSERVED RESULT Output is direct:// EXPECTED RESULT It should probably be something like http://127.0.0.1:8080 SOFTWARE/OS VERSIONS Operating System: KDE neon 5.23 KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-40-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-6300U CPU @ 2.40GHz Memory: 19.4 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 520 ADDITIONAL INFORMATION
Duh. As so often, I found that part of the issue is actually sitting in front of the screen: libproxy picks up the KDE settings totally fine as long as (a) the additonal package is installed and (b) the `proxy` test tool is executed properly. The following command actually gives me the proper result (a full URL is required, not only a hostname): proxy <<< https://example.com Feel free to close this report but there are two things I noticed while debugging this: (a) That additional package is required. I think it would make sense to install it (at least via a recommends dependency) on KDE neon per default (b) While stracing and looking at the code I saw that `qtpaths` is called at some point and some cache is maintained based on the result, if any. On my machine there is a `qtpaths` executable available but it seems to be some kind of multiplexer which doesn't find its actual implementation, cf. below. I didn't modify any global Qt related configs, this a standard KDE neon in regards to that (though upgraded from 18.04 at some point). # qtpaths --paths GenericConfigLocation /usr/lib/qt5/bin/qtpaths: command not found qtpaths: could not find a Qt installation of ''
qtpaths is a developer tool, it really shouldn't be called by runtime code. seeing as it appears not functionally required I guess we can just ignore it.
(In reply to Harald Sitter from comment #2) > qtpaths is a developer tool, it really shouldn't be called by runtime code. > seeing as it appears not functionally required I guess we can just ignore it. If that's the case I guess I'll open a libproxy issue then. If I read the historical issues correctly while debugging this it looks like somebody once reported a performance issue with libproxy (because it calls kreadconfig5 for each request) and the output from qtpaths is used to find the kioslaverc file and invalidate the cache if it changes (or not cache at all if none was found): https://github.com/libproxy/libproxy/blob/49bc258fd56db6ee0518058129f8fdc7f35a57e8/libproxy/modules/config_kde.cpp#L49 https://github.com/libproxy/libproxy/blob/49bc258fd56db6ee0518058129f8fdc7f35a57e8/libproxy/modules/config_kde.cpp#L201 https://github.com/libproxy/libproxy/blob/49bc258fd56db6ee0518058129f8fdc7f35a57e8/libproxy/modules/config_kde.cpp#L210
Seems excessive to fork a binary for that. They'd only need to construct paths from $XDG_CONFIG_HOME:$XDG_CONFIG_DIRS vars, shouldn't be too much code to implement that natively. Alternatively they could just ask us to provide a helper binary kfindconfigs5 to list the paths ;)
I opened https://github.com/libproxy/libproxy/pull/166 and asked it to be switched over to kf5-config instead of qtpaths. I guess the reason this is used is that the plugin wants to pick up the global config in /etc/xdg as well and doesn't want to hard code a default path. Since it is executed only once and kreadconfig5 is called lots of times without it this should be an improvement already. I the end I think a call to D-Bus would be the best approach but this should be a low-hanging fruit.