| Summary: | KDE proxy settings are not picked up by libproxy | ||
|---|---|---|---|
| Product: | [KDE Neon] neon | Reporter: | Malte S. Stretz <mss> |
| Component: | Packages User Edition | Assignee: | Neon Bugs <neon-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jr, neon-bugs-null, sitter |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Malte S. Stretz
2021-11-20 14:35:23 UTC
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. Thank you for your bug report! However this bug report was created/provided previous to 01/01/2023 and also has not received any updates since before 01/01/2025. Unfortunately KDE neon no longer provides updates for anything older than noble 24.04 based edition's. Please upgrade to KDE neon noble and if you can reproduce the issue after upgrading to an active version, feel free to re-open this bug report. Thanks for understanding! This was fixed in libproxy in https://github.com/libproxy/libproxy/pull/167 and the libproxy version in Ubuntu 24.04 has the required fix. |