SUMMARY I like the new interface to manually choose the location that will be used to choose the changing times for the night color. However, I still get the same error as in previous Plasma versions regarding the Mozilla location services. kded5[1036]: org.kde.plasma.dataengine.geolocation: error: "Host location.services.mozilla.com not found" STEPS TO REPRODUCE 1. Enable night mode at manual location 2. Reboot 3. journalctl -p err -b OBSERVED RESULT A few entries of the error mentioned above. EXPECTED RESULT I thought the latest changes would finally get rid of that problem, but is still there. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.90 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.19.9-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Manufacturer: LENOVO Product Name: 20XYCTO1WW System Version: ThinkPad X1 Yoga Gen 6
Yeah, we don't currently auto-load the geolocator daemon like we should. Will be fixed by https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1989
I'm not entirely sure that MR would fix this, tbh. Even in the current version of the locator, the creation of the Geolocator object (which is what actually requests data from the Plasma dataengine) only happens if the mode is set to Automatic (0), see https://invent.kde.org/plasma/plasma-workspace/-/blob/dcda5bdbc5174f6188181f77e58ea4c7d8e3aab5/libcolorcorrect/kded/locationupdater.cpp. I'd wonder if Plasma somehow tries to connect to MLS when it's initially setting up the dataengines, but that doesn't seem to track with previous experience from user reports, where things like OpenSnitch only detect a connection to MLS when the mode is set to Automatic. I think it might be something else. Will have to check.
Git commit 56ae8023b7fd11897ac6282d1f0930b85ea720ac by Bharadwaj Raju. Committed on 25/10/2022 at 19:49. Pushed by bharadwaj-raju into branch 'master'. Don't run colorcorrectlocationupdater unnecessarily Don't run the colorcorrectlocationupdater kded module when the user is not using Automatic location for Night Color. The module would not have attempted geolocation in that case anyway, but having it show as running would be misleading, as it would give the impression that geolocation was actually happening despite the user having disabled it, which isn't the case. FIXED-IN: 5.27 --- # Test Plan ## Case 1: Already on Automatic location 1. Change the mode to automatic *before* installing any of the changes in this MR. Ensure ~/.config/kded5rc does not have a `[Module-colorcorrectlocationupdater]` group. 2. Build and install MR. 3. Restart system. 4. Check that the "Automatic Location for Night Color" service is running and set to autoload, in System Settings > Background Services. **NOTE:** The Background Services KCM does not auto-reload changes to service status. You need to close and open the KCM for it to pick up on those. ## Case 2: Already not on automatic location 1. Change the mode to something other than automatic *before* installing any of the changes in this MR. Ensure ~/.config/kded5rc does not have a `[Module-colorcorrectlocationupdater]` group. 2. Build and install MR. 3. Restart system. 4. Check that the "Automatic Location for Night Color" service is *not* running and autoload is *disabled*, in System Settings > Background Services. **NOTE:** If you've already tested Case 1: enabling autoload of the service from System Settings > Background Services, then installing the old versions of libcolorcorrect (colorcorrectlocationupdater) and the Night Color KCM, then restarting, should give you a system which is in the "before installing this MR" state. ## Case 3: Switching back and forth 1. Build and install MR. 2. In System Settings > Night Color, change between Automatic and non-Automatic modes and apply. 3. Check that the "Automatic Location for Night Color" service is correctly running/not-running and autoload is enabled/disabled, in System Settings > Background Services. 4. Repeat for back-and-forth. M +1 -0 kcms/nightcolor/CMakeLists.txt M +19 -1 kcms/nightcolor/kcm.cpp M +3 -0 kcms/nightcolor/kcm.h M +17 -0 libcolorcorrect/kded/locationupdater.cpp M +1 -0 libcolorcorrect/kded/locationupdater.h https://invent.kde.org/plasma/plasma-workspace/commit/56ae8023b7fd11897ac6282d1f0930b85ea720ac
Please reopen if this still happens. As I said before, I'm not 100% sure my MR fixed this.
Operating System: Arch Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.6-zen1-2-zen (64-bit) Graphics Platform: Wayland Processors: 64 × AMD Ryzen Threadripper 3970X 32-Core Processor Memory: 62.6 GiB of RAM It still fails. Output of journcalctl: ene 19 08:59:38 kded5[2180]: org.kde.plasma.dataengine.geolocation: error: "Equipo location.services.mozilla.com no encontrado"
This is marked as fixed in Plasma 5.27, you are running Plasma 5.26.5. I will give it a try when the beta is out, and reopen if needed then.
I confirm this is fixed for me with Plasma 5.26.90.