Since https://bugzilla.redhat.com/show_bug.cgi?id=2234330 was fixed, it looks like geolocation in gnome-initial-setup's prelogin mode still does not work (it still asks me to manually search for my city, on the timezone page). I no longer see any SELinux denials, but I do see this in the journal, which looks suspcious: Sep 05 13:56:53 localhost-live gnome-shell[2228]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation Tested with Fedora-Workstation-Live-x86_64-Rawhide-20230905.n.0.iso . I'd expect the same in F39 once we land the selinux-policy update there. Reproducible: Always Steps to Reproduce: 1. Boot Fedora-Workstation-Live-x86_64-Rawhide-20230905.n.0.iso and install 2. Reboot to installed system 3. Proceed through gnome-initial-setup Actual Results: It asks me to enter my city manually Expected Results: It should guess my location
Note I see the same warning on booting the live image (before install), and g-i-s preselects English (US) as the locale, even though I'm in Canada, so I think this probably affects that too?
I'm always greeted with "English (US)" in the gnome-initial-setup on F39 Workstation Live, even though I live in Europe. The city is also not detected in the installed system. This works just fine with F38 Workstation. The Location Services are off by default on both images, so I guess Anaconda had some exception from the policy, and gnome-initial-setup now doesn't.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/1278 , marking accepted FE.
As webUI has been deferred to F40 and this bug is webUI-specific, deferring blocker/FE status for this bug.
The problem is still present in current Rawhide, though I don't think it involves SELinux now. The first screen of gnome-initial-setup on Rawhide Workstation live always defaults to "English (US)" for me even though I'm in Canada - both when booting live and on first boot after install - and the Time Zone page when booting after install does not guess a location, it requires me to type one. I can't find any kinds of errors in the journal related to this. There's a line like the one in my initial report up there: Feb 07 12:14:41 fedora gnome-shell[2270]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation but that is long *after* g-i-s ran, it's from the session for the user g-i-s created. geoclue starts up shortly before gnome-initial-setup runs, and there don't seem to be any errors from it. It starts at 12:12:56 and then shuts down at 12:14:02 reporting "Service not used for 60 seconds" (which kind of implies it *was* used at 12:13:02, I guess). So everything seems to be correct, but...geolocation clearly just didn't work, for some reason.
Looking through the g-i-s source, it looks like it isn't written to use geolocation to guess locale at all (unlike anaconda). So that part is expected. It *is* supposed to used geolocation to guess the time zone location, though.
Aha, so I worked on this a bit today, and figured something out. `g_info` logs from g-i-s do not make it to the journal. I don't know where they go, if anywhere, but it's not the journal. So, we're actually failing at a point where we should be getting a log message, but it's a `g_info` one so it never shows up. I patched it to a `g_warning` and this is what we get: Failed to connect to GeoClue2 service: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled for UID 974 UID 974 is the gnome-initial-setup user. So the problem here is that the user we're running g-i-s as does not have geolocation enabled. I guess what we should do is enable it for the g-i-s user *if* the user enabled it on the permissions screen (which comes directly before the timezone screen)?
This bug, while it technically does exist in all releases, is only really significant for the webUI flow. g-i-s' timezone page is suppressed on other workflows (non-webUI live install, and network install), so this really isn't an issue. thus, bumping to Rawhide and dropping F40 FE metadata.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.