=== _thumper_ is now known as thumper [05:53] duflu: thanks for that bug :) [06:32] Trevinho, you're welcome. Although it reminded me how unsure about upstream's fix I am [06:37] good morning [06:41] Morning didrocks [06:45] hey duflu [07:19] hey Trevinho duflu didrocks [07:19] Hi seb128 [07:19] morning seb128 [07:19] and didrocks [07:19] hey Trevinho, seb128 :) [07:26] I quite recently (since the libinput upgrade?) see the following bug: When I type, it sometimes gives a short hang, and then the char i'm typing is repeated like 5-15 times [07:31] do you use wayland? [07:32] yes [07:32] don't :p [07:33] https://bugzilla.gnome.org/show_bug.cgi?id=777693 [07:33] Gnome bug 777693 in general "Input event (e. g. typing on keyboard) is sent repeatedly during high load" [Normal,Needinfo] [07:33] bugzilla.gnome.org bug 777693 in general "Input event (e. g. typing on keyboard) is sent repeatedly during high load" [Normal, Needinfo] - Assigned to gnome-shell-maint [07:33] bug 777693 in PernillaSYS "Crash-bug when trying to view registrations if none of the users conferences is locked" [Medium,Fix released] https://launchpad.net/bugs/777693 [07:34] seb128: so, ubiquity on 16.04 a11y support is even worse: it's in english both in the installer and in the live session [07:34] here, we would have it in english only the installer mode, not in the live session [07:37] and... night time here, bye [07:37] bye bye Trevinho [07:38] night Trevinho [07:38] didrocks, Laney managed to make the callback work yesterday [07:38] oh? [07:38] * didrocks bzr pull [07:38] seb128: got the mail? [07:38] hum, not in bzr [07:38] * didrocks looks at logs [07:38] Trevinho, yes, you forgot the status of your milestoned bugs again :p [07:39] didrocks, workaround, not fix [07:39] seb128: I didn't forget... there's no news :-D [07:39] didrocks, https://irclogs.ubuntu.com/2018/04/23/%23ubuntu-desktop.html#t19:35 [07:39] better than the subprocess I guess? [07:39] thx! [07:39] Night Trevinho [07:39] Trevinho, we are supposed to include those anyway, even if you say "no news, planned for SRU" [07:40] seb128: hehe :) Xorg doesn't allow scaling 1 screen, but not the other I guess? :) So thats why I need wayland [07:41] unsure about that, it might be the case [07:41] morning [07:41] hey Nafallo [07:41] didrocks, so yeah, at least that helps understanding the issue, now for how to workaround in a nice way... [07:42] seb128: well, this is what we understood yesterday basically… being root and dbus rejecting sending the message [07:42] right, but I didn't understand why the drop privileges calls were not working [07:43] Trevinho, thanks! and have a good night :) [07:43] seb128: because the uid stays the same [07:43] :) [07:43] you keep being 0 [07:43] only the euid is changed [07:43] when you drop priviledges without subprocessing [07:44] (as ubiquity wants to gain again root privileges later on) [07:44] * duflu is also seeing error messages that tell me I am uid 0 [07:44] the whole issue is that ubiquity is one process gaining/dropping privileges as needed. And we start to get the limitation of that architecture IMHO [07:47] didrocks, sorry, door bell... [07:47] so [07:48] morning all [07:48] didrocks, yeah, I was just puzzled at why the drop privilege is not working for dbus but it is, we just regain the privilege before the check is done in an async way [07:48] Hi willcooke [07:48] didrocks, that explains the bit I didn't understand [07:48] hey willcooke [07:48] seb128: hem, I mentioned that yesterday to you :) [07:49] hey willcooke [07:49] hi duflu - was justing thinking about the mem leak patches.. I dont think we've had any problems with it. Worst case feedback seems to be "no change", a few people have said it helps. [07:49] didrocks, I didn't understood properly/realize that a sleep before the restore would be enough [07:49] you think we can release it? [07:49] willcooke, I think we already released it(?) [07:50] didrocks, you said that the callback was probably coming after we restored the privilege and such discarded [07:50] seb128: I'm a little bit vary about a sleep… What happens if the user press Super + Alt + S later on? [07:50] yeah [07:50] though now I'm unsure [07:50] isn't what you said? [07:50] does the signal register needs to happen during that time [07:50] or does the change need to happen? [07:50] ah [07:50] my theory for #2 [07:50] not #1 [07:50] I understand from L_aney's comment that the register was enough [07:50] let me test [07:50] willcooke, I changed the bug to in progress the other day, awaiting more fixes. But definitely an improvement already [07:51] seb128: that would be better, I'm worried if it's #2, as it can happen anytime [07:51] right, let me see [07:51] also, are we sure nothing else happens in parallel which can gain privileges? [07:51] tell me if you need any help [07:51] sup [07:51] willcooke, duflu, we "failed" at blocking the gjs update in proposed so it went to bionic proper directly on thursday [07:52] Yeah, 5 days ago [07:52] All good [07:52] right [07:52] hey Laney [07:52] ah, "problem" "solved" then :) [07:52] morning Laney, how's London? [07:52] willcooke, Lucaks probably didn't see your request on the email, but yeah, that solves a problem for us [07:52] willcooke, just as well because bug 1763878 was desperate for the release [07:52] bug 1763878 in gjs (Ubuntu) "[regression] Many programs crashing at exit with assert failure: ../../../../src/cairo-hash.c:217: _cairo_hash_table_destroy: Assertion `hash_table->live_entries == 0' failed. Called from cairo_debug_reset_static_data()" [High,Fix released] https://launchpad.net/bugs/1763878 [07:53] hey didrocks willcooke [07:53] yeah it's alright [07:53] seems to be a nice looking coffee shop across the road now [07:53] will check it out later [07:53] duflu, the other one on my radar was classic snaps crashing the session in Wayland, I think that's related to the xwayland issue. Less pressing for release. [07:53] duflu, was that on your list, or should we find someone to look at it? [07:54] Laney, there was talk of free coffee to Blue Fin residents, might be worth asking Stef [07:54] willcooke, it wasn't no. The reason is that we have many much noisier issues. Probably hundreds. I didn't mean to be rude [07:54] duflu, np [07:54] iiiiiiiiiiiiiiiiinteresting [07:55] willcooke, duflu, I asked tjaalton if he could upstream/handle the xwayland one, unsure what's the status [07:55] Heh. Which Xwayland one, seb128? [07:56] mesa 18.0.1 was released, best to test that first [07:56] duflu, the one willcooke was asking about, classic snaps making xwayland segfault [07:56] duflu, https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1754693 [07:56] Ubuntu bug 1754693 in mesa (Ubuntu) "Xwayland crashed with SIGABRT in st_renderbuffer_delete()" [High,Confirmed] [07:56] Oh yes. I recall he assigned it to Mesa [07:56] tjaalton, do you have that update in a ppa? [07:56] not yet [07:57] can you let us know once you do? [07:57] some people didn't understand that it's a bot posting the snap: https://github.com/ubuntu/gnome-shell-communitheme/pull/122#issuecomment-383327290 :) [07:57] ubuntu bug (Pull request) 122 in gnome-shell-communitheme "enhance selected day" (comments: 2) [Closed] [07:57] I'm sure willcooke would be happy to give it a try :) [07:57] willcooke, right? ;) [07:57] at least, people are trying the PR snap and confirming! [07:57] sure [07:57] thx [07:57] didrocks, :) [07:58] the xwayland crashing classic snaps - yes indeed - will test that [07:58] oh, didrocks, using communitheme, can you open gnome calculator and tell me what you see? ;) [07:58] I think you'll say "nothing at all" [07:58] willcooke, transparent bg? [07:58] yeah [07:58] darn, I thought I'd found something new [07:58] bug #1760818 [07:58] bug 1760818 in ubuntu-themes (Ubuntu) "gedit and gnome-calculator transparency/graphics corruption issue" [Undecided,Confirmed] https://launchpad.net/bugs/1760818 [07:59] well that one is with our current/old themes [07:59] but likely the same issue [08:00] Laney, your ubiquity changes work in -dm, no reset of keys or second dconf-service anymore [08:01] thx! [08:01] thank you for the fix! [08:01] willcooke: I worked on it for some times and that was part of my weekly report :) [08:02] discussed on the hub, snapcraft forum, and bug reports ;) [08:02] basically, gtk-common-themes now has communitheme in as a workaround (never got an answer from the snapd team to have a proper theme support :/) [08:02] and kenvandine, when he will have time, need to update the snaps to use the theme plugs [08:03] but it means that any snap not declaring and supporting the theme plugs will be transparent… [08:03] didrocks, was that about the transparent bg? [08:03] yeah [08:03] are you sure about that? [08:03] yes [08:03] we have transparent bg issues with the old theme as well [08:03] see the bug reference I gave [08:03] I'm not sure it's snap specific? [08:04] we had reports with the deb as well (at least on the old theme) [08:04] there might be a snap issue on top? [08:04] well, it's different [08:04] here, the whole UI is transparent [08:04] not part of it [08:04] and switching themes make it works [08:04] basically, you have apparmor denials on /snap/communitheme/current… [08:04] ah ok, sounds different indeed then [08:04] yes [08:05] shame, I though it could help us to understand the issue with ambiance :p [08:05] ;) [08:05] I still think the "gtk-common-theme" + special plug won't address the bigger issue with themes and snaps [08:05] as not all snaps will declare those plugs [08:05] and thus, will render transparently :/ [08:05] tried to get the snapd team on it, but never got a respond… [08:05] yeah, if that's not handled on the snapd level it's not going to be great [08:06] yeah, once kenvandine updates our default snaps, at least, those works [08:06] until someone start a another snap and will trigger the bug [08:07] https://forum.snapcraft.io/t/snap-application-and-snap-themes/4946/9?u=didrocks [08:07] see my last comment [08:10] willcooke, k, well known issue in any case :) [08:11] yep [08:11] thx [08:11] Different note, I think the u7 theme is pulling in g-calculator deb [08:11] s/theme/packages [08:12] session [08:12] ubuntu-unity-desktop [08:12] is a reverse dep [08:12] so yeah [08:12] yeah, that makes sense [08:12] (also unity-scope-calculator) [08:13] willcooke: tip of the day for you: apt rdepends gnome-calculator ;) [08:13] it's nicer since the move from apt-cache to apt, shows you if it's a recommends, deps, suggests… [08:13] with --show-installed=yes if you want to limit to what is installed [08:14] which usually makes easier to understand your local install situation [08:14] ah, not on apt show though… [08:15] * didrocks doesn't find an equivalent in the manpage… [08:17] hi all [08:17] thanks didrocks! [08:18] hey c-lobrano [08:18] didrocks: thank you for taking time to repeat again and again the same snap story every time someone asks :D [08:19] c-lobrano: see, it was a combo this time, github AND here ;) [08:19] too bad github doesn't have aliases for messages :) [08:19] I was just typing the answer when I got the question on that channel :p [08:19] yeah [08:19] I'll make a stock response soon :p [08:20] kenvandine: FYI, I can't assign it to you, but as we discussed theming in snap: https://github.com/ubuntu/gtk-communitheme/issues/354#issuecomment-383845039 [08:20] ubuntu bug 354 in gtk-communitheme "None of the default provided snaps in 18.04 work properly with the snap community theme" (comments: 3) [Snap, Open] [08:20] Ubuntu bug 354 in gnomad2 (Ubuntu) "gnomad2 needs superuser access" [Medium,Fix released] https://launchpad.net/bugs/354 [08:20] at least, now, people won't mix it up with the evince issue anymore (even if both are due to the same root case: apparmor denials) [08:20] :D [08:27] RAOF: hey, if you are around, I would love to chat about 1763266 (the mountinfo bug) a) does it still prevent snapd from starting with 2.32.5? b) do you see more ill effects, like snaps stop working when you try to run them? [08:27] RAOF: also I added some more info (and a potential kernel patch) in the bug, would love to hear if that helps [08:29] seb128: ummmmmmmmmmmmmmmmmmm [08:29] didrocks, Laney, so, back to this screen reader issue [08:29] lol, good timing :p [08:29] think we might have figured it [08:29] oh? [08:29] not sure you need to drop there ... [08:29] think the regain was actually causing problems [08:29] how so? [08:30] well, without the drop/restore the callback is never called either, we tried that [08:30] on_screen_reader_enabled_changed [08:30] time to rewrite ubiquity to be an user process and call to polkit to privileged actions? :p [08:31] that was printed [08:31] interested, what did you do exactly? [08:31] self.a11y_settings = Gio.Settings.new("org.gnome.desktop.a11y.applications") [08:31] self.a11y_settings.connect("changed::screen-reader-enabled", on_screen_reader_enabled_changed) [08:31] print("current value is: %s" % self.a11y_settings.get_boolean("screen-reader-enabled")) [08:32] in gtk_ui.py? [08:32] yeah [08:33] I'm not sure how that's different from what I do in http://people.canonical.com/~seb128/ubiquity-screen-reader.patch [08:33] you do drop and regain [08:34] and it's not an instance variable, maybe that matters [08:34] in a second blob [08:34] + settings_a11y1 = Gio.Settings.new("org.gnome.desktop.a11y.applications") [08:34] + settings_a11y1.connect("changed", on_a11y_changed1) [08:34] + print(settings_a11y1.get_boolean("screen-reader-enabled")) [08:34] then [08:34] + misc.drop_privileges_save() [08:34] + settings_a11y = Gio.Settings.new("org.gnome.desktop.a11y.applications") [08:34] the *1 variant is not under drop/Restore [08:34] ok [08:34] well give that a try please [08:34] yours? [08:34] sure [08:34] there's also a self.a11y_settings = None at the top [08:35] * didrocks doesn't see the difference apart from only listening to one key and not the whole schema subfolder [08:36] what if settings_a11y1 goes out of scope and the handlers are disconnected [08:36] that could well be [08:36] hum, interesting idea [08:37] shrug, maybe lost days of poking around due something as stupîd :/ [08:37] stupid [08:37] well, it's stupid in some way, but as you have an handler, gobject-introspection python bindings should get an hold on the reference… [08:38] but yeah, not a bad idea at all if this is the cause [08:44] mvo: sure! [08:45] That bug doesn't prevent me from using snaps *until* something tries to run `snap refresh`, at which point all snaps irreparably break. [08:46] (that something might be the systemd unit that runs `snap refresh` around boot time 😀) [08:47] Bug #1763266 [08:47] bug 1763266 in snapd (Ubuntu) "Snapd fails to start (failed to parse /proc/self/mountinfo)" [Undecided,Incomplete] https://launchpad.net/bugs/1763266 [08:48] apw: hey, apparently nvidia-driver-390 is in the "libs" section rather than in "restricted/misc" (I tested this with python-apt). This causes the Additional Drivers tool to see it as "open source". Can you fix this, please? [08:48] tseliot, looking [08:49] thanks [08:51] tseliot, restricted/libs/optional/100% it is in restricted, but as you say restricted/libs [08:51] RAOF: ok, so you can run snaps and interact with snapd until a refresh happens. and at that point you get an error from snapd (it stops running?) and when you "snap run test-snapd-tools.echo hello" it will fail? if so, I would love to get the error message from snap run (assuming you have test-snapd-tools installed) and the output of "journalctl -u snapd" after it starts failing. I think we need to make it more rob [08:51] ust :) however the underlying issue is a bcachefs bug (see LP bug) [08:51] apw: I suspect that moving it to restricted/misc would solve the problem [08:51] tseliot, is it not the restricted bit which tells us it is a dangerous thing ? [08:52] mvo: sure! I'll get that info next time I trigger it, and forward that patch upstream. Thanks! [08:53] apw: python-apt doesn't really return the "restricted" part from restricted/libs, but it does return the full "restricted/misc" for some reason [08:53] tseliot, you mean because it is libs it is '' sort of thing, and restricted is lost ? [08:54] RAOF: thank you! woah, if you forward it, let me just fix the one tiny issue I noticed in it [08:54] apw: I'll show you with a python script [08:55] tseliot, /me trusts you ... lets try moving it [08:55] apw: thanks [08:55] tseliot, the publisher is grinding hard, so it will be a while for sure [08:55] I won't do anything with it until tomorrow, so you've got like 12 hours before I touch it again 😀 [08:55] Hello all [08:56] apw: that would be fine. Still less work than me changing the detection code again [08:57] seb128: pushed mesa-18.0.1 to ppa:canonical-x/x-staging, building now [08:57] tjaalton, nice, thanks [08:57] willcooke, ^ [08:57] installing [08:58] still building [08:58] not available yet [08:58] ack, will watch it [08:58] maybe in 20min [09:00] hey alexarnaud [09:01] didrocks, Laney, so yeah, it works with the self.a11y_settings = None definition... [09:02] Hmm. Is this meant to take zero time? [09:02] Apr 24 17:01:34 haz systemd[1]: Starting Stop ureadahead data collection... [09:02] Apr 24 17:01:34 haz systemd[1]: Started Stop ureadahead data collection. [09:02] well, I'm trying https://paste.ubuntu.com/p/ZWww3TFdNy/ but I'm having some weird issue now, the dconf/user in /run is owned by root and gsettings is unhappy, trying without the misc.py changes [09:03] seb128: \o/ [09:03] good call Laney ;) [09:03] Laney: hey, any chance you can have a look at this? It would be good to have a working Additional Drivers tool in time for the 18.04 release: https://code.launchpad.net/~albertomilone/software-properties/software-properties/+merge/343882 [09:03] duflu: I think ureadahead is disabled on ssd? [09:04] * duflu shrugs. "never trust log messages" [09:05] seb128, those login problems are suddenly gone btw. I was trying to get detailed logs. Plus I can't reproduce on other machines [09:06] :/ [09:06] I had a login problem this morning. not sure what happened. [09:06] heisenbug [09:07] after login I just had a purple screen, and could move the bluetooth mouse [09:07] did you had a failed login first? [09:07] Nafallo, bug 1766137 [09:07] bug 1766137 in gnome-shell (Ubuntu) "[regression] Login fails when preceded by incorrect password" [High,Incomplete] https://launchpad.net/bugs/1766137 [09:07] nope. pretty sure it wasn't a failed login... [09:07] but then again, perhaps. [09:08] Nafallo, sorry bad bug description [09:08] jbicha: Do you plan to add a symlink on the sane package to avoid work around describe on this bug: https://bugs.launchpad.net/bugs/1707352 [09:08] Ubuntu bug 1707352 in sane-backends (Debian) "the change from libsane to libsane1 broke many (all?) 3rd party plug-ins for sane" [Unknown,New] [09:08] once I did the ctrl+alt dance to a different terminal and back, gdm came back with a login screen. [09:08] after that it worked :-) [09:08] bug 1766137 :) [09:08] bug 1766137 in gnome-shell (Ubuntu) "[regression] Login fails (blank purple screen and mouse pointer only)" [High,Incomplete] https://launchpad.net/bugs/1766137 [09:08] * Nafallo takes a look [09:09] didrocks, Laney, k, so that works in the sense the callback is called but it's screwed. I'm going to try again the drop/restore priviledge but keeping the definition so it doesn't get out of scope. [09:09] I thought the interesting thing was that the bluetooth mouse was already working, but perhaps that happens earlier on a system level? [09:09] seb128: don't, I tried that [09:09] didrocks, Laney, with that current change the dconf user file is root owned and the callback always return" false" [09:09] that is what I was describing yesterday [09:10] so I think it spawns a dconf-service as root [09:10] Nafallo, yes the BT mouse will work system-wide [09:10] and fails to read the user value [09:10] it gets the changed signal [09:10] but it always read as "false" [09:10] probably due to different $HOME as well [09:10] (/root) [09:11] so the wrong value is probably my fault [09:11] I used "gsettings.get_value(key).unpack()" in the callback [09:11] I should probably use the wrapper [09:11] that does the sudo/gsettings cmd dance to get from the correct user [09:11] yeah… [09:11] but that's not going to resolve the fact that /run/...dconf/user is owned by root [09:12] and that makes gsettings unhappy/complaining about the permissions [09:12] Nafallo, in fact you can use your Bluetooth mouse in a VT too (if gpm is installed) [09:12] :-) [09:12] on_screen_reader_enabled_changed: False [09:12] on_screen_reader_enabled_changed: True [09:12] it works here [09:12] I don't have that root thing [09:12] let me reboot to a clean environment [09:13] Laney, https://paste.ubuntu.com/p/ZWww3TFdNy/ ... something is probably wrong in my diff [09:13] Laney, do you read the value using the wrapper? [09:13] it's like settings.get_boolean("screen-reader-changed") in the callback [09:13] enabled [09:14] duflu: thanks for pointing me in the right direction. I'll subscribe, but you seem able to reproduce this so no further action needed? [09:15] Nafallo, actually I can't reproduce it or the other bug today [09:15] It's not a midweek bug [09:16] duflu: okay. just let me know if I should do something then :-) === jhernandez is now known as jhernandez_ [09:18] Laney, well it's not the callback, because I boot, go to a tty and do a gsettings get and get the dconf permission error, without trying to activate the callback in -dm first [09:18] * seb128 doesn't understand [09:19] Nafallo, maybe enable debug in /etc/gdm3/custom.conf, reboot, start watching 'journalctl -f' from an ssh login, then try and login and reproduce it. [09:19] Nafallo, because upstream wants more info: https://gitlab.gnome.org/GNOME/gnome-shell/issues/227 [09:20] GNOME bug 227 in gnome-shell "Login fails when preceded by incorrect password" (comments: 7) [Opened] [09:20] Error: Gnome bug 227 could not be found [09:21] the dconf perm error is on the tty with a simple get? [09:21] yes [09:21] same I've been doing since I started testing [09:21] weird, I'm pretty sure I didn't see that yesterday [09:21] the file is indeed root owned [09:21] ok, so no patch at all on ubiquity? [09:21] didrocks, https://paste.ubuntu.com/p/ZWww3TFdNy/ [09:21] just doing a get on a tty [09:21] that patch [09:22] booting in rescue.target, applying the patch [09:22] ctrl-D === jhernandez is now known as jhernandez_ [09:22] waiting for -dm to be loaded [09:22] * didrocks fires up vm [09:22] going to a tty [09:22] paste.ubuntu.com is annoying for copying raw patch, as requires login :/ [09:23] didrocks, Laney, k, I changed back the sudo calls to use -E instead of '--preserve-env=DBUS_SESSION_BUS_ADDRESS' and no root problem anymore [09:23] weird, I tried the patch with '--preserve-env=DBUS_SESSION_BUS_ADDRESS' this morning and it seemed fine [09:23] I'm a bit puzzled now :/ [09:23] but I tried 3 boots with the diff from pastebin before and I had the issue 3 times [09:24] seb128: try to pass HOME [09:24] now I loaded the same diff but changed for -E [09:24] yeah [09:24] -H sets HOME [09:24] oh right [09:24] k, I don't understand :/ [09:24] what exactly are the steps to get this? [09:24] duflu: hmm. looks like we may not have confirmed this is actually a wrong login issue, right? [09:25] Laney, mine is [09:25] - pick "install" on the syslinux menu [09:25] - f6 [09:25] systemd.unit=rescue.target [09:25] dhclient to have internet [09:25] wget the patch from people page (using the ip, I've no dns) [09:25] patch -p0 in /usr/lib/ubiquity [09:25] ctrl-D [09:25] -> ubiquity-dm loaded [09:26] then ctrl-alt- and gsettings get or look at at the log [09:26] Nafallo, I'm not going to comment in there further while I can't reproduce it. But when I could reproduce it I did confirm authentication is successful (as other people confirmed too). Only the gnome-shell process is missing [09:26] ok, thx [09:26] Also no crash file [09:26] Laney, didrocks, I need to go pick somebody, back in a bit and I re-do another testing round [09:26] duflu: excellent. that was the only part I thought was odd :-) [09:27] Laney, didrocks, what I tried now is http://people.canonical.com/~seb128/new ... that version gives me the root owned error, I did a try where I changed the --preserve-env to -E before applying the patch and that worked [09:27] orca started and read screen [09:27] anyway, bbiab [09:28] * didrocks starts a vm [09:33] ok, confirming what seb128 says [09:33] it tries to create /run/user/999/user [09:34] I thought that was dconf-service would would try to create that file [09:34] which is with the correct perms and id [09:35] (and the folder 999 as well [09:35] knowing we already have ~/.config/dconf/user with correct perm and ownership [09:37] (also, we don't use XDG_RUNTIME_DIR for dconf here…) [09:37] so something makes dconf fallback to XDG_RUNTIME_DIR maybe? [09:38] duflu: it will probably take a while. my other laptop was quite outdated and doing updates now ;-) [09:38] HOME=/home/ubuntu in spawn dconf-service process, as expected by -H [09:44] Laney: confirming laney? [09:44] yeah [09:44] it's probably XDG_RUNTIME_DIR [09:44] try adding that [09:44] it's in the process… [09:45] if you look at dconf-service [09:45] but can try [09:45] you can't see what the gsettings calls had though [09:45] yeah [09:45] it's weird that setting XDG_RUNTIME_DIR would have it using $HOME instead of XDG_RUNTIME_DIR though [09:45]