[00:13] <Trevinho> c-lobrano: hey, about the pngs, how did you generate those?
[01:23] <Trevinho> duflu: hey, could you review some theme MPs I've?
[01:24] <Trevinho> otherwise I'm self-approving as they're there since some time xD
[01:24] <duflu> Trevinho, I'll try to have a look today
[01:24] <Trevinho> hey btw :)
[01:35] <duflu> Trevinho, btw if you're marking bugs Fix Released then it's best to include the changelog entry showing where it's fixed. Or a comment mentioning where
[01:36] <Trevinho> duflu: for some of them they where already mentioned (I closed the upstream bug only)
[01:36] <Trevinho> while for one I didn't really know when xD
[01:39] <Trevinho> duflu: as for https://bugs.launchpad.net/ubuntu-themes/+bug/1762465 I should only change the code involving selection and mouse hover, right?
[01:39] <ubot5`> Ubuntu bug 1762465 in ubuntu-themes (Ubuntu) "Nautilus sidebar theming is confusing" [Medium,Confirmed]
[01:40] <duflu> Trevinho, not mouse hover. I think the goal is to make the label backgrounds always match the icon backgrounds
[01:41] <duflu> Because they look like tabs
[01:41] <duflu> which is incorrect
[01:42] <Trevinho> mh, I think is too late for such change. it might break screenshots or such
[01:43] <Trevinho> I'm fine with changing the hover effect, but that was approved by design
[01:45] <duflu> Trevinho, yeah I understand
[01:45] <Trevinho> I'll revisit it a bit, but not everything probably
[01:48] <duflu> I know it's too late to change 18.04, but suspect we'll hear a few duplicate bug reports after release so think about it for 18.10
[02:26] <duflu> Trevinho, heh. I noticed bionic felt smoother... didn't know you got the master clock change in
[06:03] <tjaalton> is it a known bug where some gtk windows seem as somewhat transparent, and when they're moved the contents get messy
[06:04] <tjaalton> gedit for one
[06:04] <tjaalton> I just upgraded and rebooted, thought this would've been fixed but no
[06:05] <tjaalton> hm, doesn't happen on my laptop
[06:08] <tjaalton> huh, it's some user setting messing things up
[06:19] <didrocks> good morning
[06:25] <jibel> Good morning
[06:25] <jibel> salut didrocks
[06:32] <oSoMoN> good morning desktoppesr
[06:32] <oSoMoN> desktoppers*
[06:32] <oSoMoN> and happy Friday!
[06:45] <didrocks> hey jibel, oSoMoN!
[06:47] <oSoMoN> salut didrocks, jib
[06:47] <oSoMoN> jibel*
[06:47] <oSoMoN> slow fingers today…
[06:49] <duflu> tjaalton, yeah Saviq reported that bug. Lemme find it
[06:50] <duflu> tjaalton, bug 1760818
[06:50] <ubot5`> bug 1760818 in ubuntu-themes (Ubuntu) "gedit and gnome-calculator transparency/graphics corruption issue" [Undecided,New] https://launchpad.net/bugs/1760818
[06:50] <tjaalton> ooh, thanks
[06:50] <duflu> Morning didrocks, jibel, oSoMoN
[06:54] <seb128> good morning desktopers
[06:55] <jibel> During the 1st run wizard I tried to setup livepatch but I couldn't authenticate. It kept asking for the 2nd factor. Is it a known issue?
[06:56] <seb128> not reported on https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bugs at least
[06:56] <seb128> and andyrock is off today
[06:56] <seb128> if that helps to feel better about the issue only canonical accounts are configured to use 2fa so it's not going to hit "normal users"
[06:57] <seb128> but the code is supposed to handle the 2fa, unsure why it doesn't work for you
[06:58] <jibel> and the only message is a successful authentication
[06:59] <jibel> didrocks, where do you store the telemetry data?
[06:59] <seb128> :/
[06:59] <seb128> is there anything interesting in the journal? warnings/errors?
[07:00] <jibel> no
[07:00] <jibel> didrocks, I've this message for my gpu "couldn't get GPU info: couldn't find any line matching ^.* 0300: (.*) \\(rev .*\\)$"
[07:14] <didrocks> jibel: ~/.cache/ubuntu-report/ubuntu.18.04
[07:15] <didrocks> if it's ignore, you shouldn't have the field
[07:15] <didrocks> the question is what is your lspci -n output?
[07:16] <c-lobrano> Trevinho: hi :), no I didn't generate the .pngs, Mads did that, but I said it won't probably been able to generate the svg from there :(
[07:17] <c-lobrano> and, good morning to all :)
[07:18] <didrocks> hey c-lobrano!
[07:18] <c-lobrano> hi didrocks :)
[07:20] <jibel> didrocks, I filed bug 1765614
[07:20] <ubot5`> bug 1765614 in ubuntu-report (Ubuntu) "Incorrect regex for GPU info" [Undecided,New] https://launchpad.net/bugs/1765614
[07:20] <didrocks> jibel: ah perfect! I guess that will wait for a SRU, correct?
[07:20] <didrocks> I'll add a test case for this in the tests as well
[07:22] <jibel> didrocks, sure it can wait
[07:22] <didrocks> jibel: thanks for debugging!
[07:23] <duflu> Morning seb128
[07:23] <seb128> Hey duflu, how are you?
[07:23] <seb128> I spent more time on ubiquity and understand things even less :/
[07:23] <seb128> https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L736
[07:24] <seb128> the gtk frontend does set some gsettings using the python bindings
[07:24] <duflu> seb128, I'm not feeling great today, but I think I am making some real progress on totem performance. Only a day after I said I was giving up
[07:24] <duflu> You seb128?
[07:24] <seb128> duflu, I'm tired, stayed up too late looking at ubiquity :/
[07:25] <seb128> the frontend does gsettings call to disable e.g screensaver or power management from gsd
[07:25] <seb128> but the code is root
[07:25] <seb128> and those services are user ones
[07:25] <seb128> so I don't understand how that can work
[07:25] <didrocks> seb128: check for the euid to get under what user this part of code is running: print(os.geteuid())
[07:25] <seb128> also if I gsettings get they seem to have the correct value
[07:25] <didrocks> as ubiquity is doing a lot of raise/drop priviledges
[07:25] <seb128> but like I use the session 15s/try activate the screen reader
[07:25] <seb128> and they all are back to the default value
[07:26] <seb128> not the ones set from ubiquity
[07:26] <didrocks> hum
[07:26] <didrocks> are they delayed keys by any chance?
[07:26] <seb128> delayed?
[07:26] <didrocks> (and not committed for any reason?)
[07:26] <didrocks> seb128: https://developer.gnome.org/gio/stable/GSettings.html#g-settings-delay
[07:27] <seb128> there is no mention of "delay" in the file
[07:27] <seb128> didrocks, code is like https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L589
[07:28] <seb128> I also don't understand why those previous/etc checks
[07:28] <seb128> if the function is disable why not just set to false?
[07:30] <didrocks> yeah, this looks cryptic :/
[07:30] <didrocks> can you attach some dbus monitor, or maybe a shell watching for the key?
[07:30] <didrocks> to see when it's set/unset
[07:33] <seb128> yeah, I can try
[07:34] <seb128> that diff http://paste.ubuntu.com/p/fMSsYjYWDv/ is
[07:34] <seb128> - boot in installer mode
[07:34] <seb128> - go to a vt
[07:34] <seb128> - gsettings list-recursively > boot
[07:34] <seb128> - go back to vt1/ubiquity
[07:34] <seb128> - super,alt,s to try to activate the screen reader
[07:35] <seb128> - back to vt, gsettings list-recursively > screen
[07:35] <seb128> diff the 2 files
[07:36] <didrocks> so, all keys are set to what you expect, correct?
[07:36] <didrocks> shortcuts, toolkit-accessibility to true…
[07:37] <seb128> well it's resetting all the changes ubiquity is doing
[07:38] <jibel> org.gnome.settings-daemon.plugins.media-keys screenreader should still be ''
[07:38] <jibel> it's disabled explicitly in ubiquity
[07:38] <jibel> same for the terminal
[07:38] <seb128> well, that's what that diff is
[07:39] <seb128> all the things ubiquity set are reverted to their default
[07:39] <jibel> yeah, is gnome-shell resetting the keys somehow?
[07:40] <didrocks> ahhhhhhhh, got you know
[07:40] <didrocks> now*
[07:42] <jibel> seb128, at the end of run in bin/ubiquity-dm there is this
[07:42] <jibel>             for gs_schema, gs_key, gs_value in gsettings_keys:
[07:42] <jibel>                 subprocess.call(
[07:42] <jibel>                     ['gsettings', 'reset', gs_schema, gs_key],
[07:43] <seb128> that's after the greeter exit though
[07:45] <jibel> the other reset is in unset() of gsettings.py but it is never called
[07:47] <Nafallo> morning
[07:48] <seb128> jibel, didrocks, it's not ubiquity, in fact those get reset on first gsettings write
[07:48] <seb128> I did a gsettings set of the screen-reader key manually
[07:48] <seb128> and everything did reset
[07:49] <didrocks> hey Nafallo
[07:49] <didrocks> hum… this is weird
[07:49] <didrocks> so
[07:49] <didrocks> better doing your gsettings set manually
[07:49] <seb128> hey Nafallo
[07:49] <didrocks> you should maybe try a dconf dump?
[07:50] <seb128> yes
[07:50] <seb128> I tried to strings ~/.config/dconf/user
[07:50] <seb128> the changes are in the db
[07:50] <didrocks> similar :)
[07:50] <didrocks> in the db before being reverted?
[07:50] <seb128> at least it references the keys that are modified
[07:50] <seb128> yes
[07:50] <didrocks> even more surprising…
[07:50] <seb128> I though that maybe it has in memory status not commited on disk or something
[07:50] <seb128> but no :/
[07:50] <didrocks> yeah, exactly…
[07:50] <didrocks> hence my question on dconf dump
[07:50] <didrocks> brrrr
[07:51] <seb128> also there are 2 dconf-service active for the user with different dbus session address
[07:51] <seb128> but I tried to kill the 2 and it's not making a difference
[07:51] <didrocks> can you try gsettings set on something completely unrelated to GNOME?
[07:51] <didrocks> like a key for one of our service
[07:51] <didrocks> to see if that still reverts
[07:51] <seb128> let me see
[07:51] <didrocks> can be something listening on GNOME schemas and reverting on any :change
[07:56] <willcooke> morning all
[07:56] <willcooke> how is it Friday already?
[07:56] <seb128> hey willcooke
[07:56] <seb128> puzzling friday it is
[07:57] <seb128> trying to understand the ubiquity ways
[07:57] <willcooke> jibel, have you test UEFI installs recently?
[07:58] <didrocks> hey willcooke
[07:58] <Nafallo> hi willcooke
[07:58] <willcooke> jibel, ignore, this laptop is in UEFI mode, and works fine
[08:00] <seb128> didrocks, it's any key, I tried settings com.ubuntu.update-notifier something
[08:00] <seb128> didrocks, it doesn't revert if I kill dconf-service :/
[08:01] <seb128> and let a new one be spawned
[08:01] <didrocks> well, that makes sense at least
[08:01] <Laney> moin
[08:01] <didrocks> you have the two trying to write, and one with the old memory mapping
[08:01] <didrocks> hey Laney
[08:01] <didrocks> so, the question is why 2 are launched I guess
[08:02] <teeramisu> Hello, 12 days ago I created Bug 1762200, nobody answered yet. I think it's important before final release. can you take a look at this?
[08:02] <ubot5`> bug 1762200 in xorg (Ubuntu) "[xorg.conf missing]nvidia detects 2 screen but there is no 2 screen" [Undecided,New] https://launchpad.net/bugs/1762200
[08:02] <didrocks> or do you only have an old one? You told that 2 were running, but that was maybe after you set the key already?
[08:02] <didrocks> (so maybe 2 session bus or address?)
[08:03] <seb128> it doesn't make sense
[08:03] <didrocks> seb128: why? my guess is that:
[08:04] <seb128> the second one from the env is a sudo process on a gsettings set command to set volumes-visible
[08:04] <seb128> I guess the ubiquity code is just fucked
[08:04] <seb128> it try to do set with the wrong context
[08:04] <seb128> already in the existant code
[08:04] <didrocks> seb128: look at /proc/$pid/environ for the 2 dconf process
[08:05] <seb128> I did
[08:05] <didrocks> to see what env is incorrect and why a second is spawn
[08:05] <didrocks> same?
[08:05] <seb128> no, what I just wrote
[08:05] <seb128> there is the normal one
[08:05] <seb128> and one resulting from a sudo gsettings set on that nautilus key
[08:05] <didrocks> but env variables are exactly the same in the 2?
[08:05] <didrocks> (which was my question)
[08:05] <seb128> no, the normal has the right address
[08:05] <seb128> the run/uid from the user
[08:06] <seb128> the other one has a random long checksum
[08:06] <seb128> let me pastebin those
[08:07] <didrocks> yeah, have you tried to simply remove the code where ubiquity spawn that second process? (from line 406 in bin/ubiquity-dm)
[08:07] <seb128> http://paste.ubuntu.com/p/bNQRS6MMmt/
[08:08] <seb128> vs
[08:08] <seb128> http://paste.ubuntu.com/p/rY8Tyk89St/
[08:08] <seb128> SUDO_COMMAND=/usr/bin/gsettings set org.gnome.nautilus.desktop volumes-visible false
[08:08] <seb128> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-B1qg1YXAql,guid=24adb17fe5a37f790451a8405ad99f91
[08:08] <didrocks> indeed, different session bus
[08:09] <didrocks> yeah, so I think what happens:
[08:09] <didrocks> - gsettings from ubiquity contact one of the 2, it writes the settings -> ok
[08:09] <seb128> good idea for the ubiquity-dm dconf spawn
[08:09] <didrocks> - something else set a key outside, contact the first one -> it doesn't have the new key -> write what he has in memory
[08:10] <seb128> right
[08:10] <jibel> willcooke, morning, yes on a real laptop and it worked why?
[08:10] <seb128> the second one shouldn't exist
[08:10] <didrocks> I'm worrying that actually ubiquity-dm is trying to only contact dconf-write on this "private bus"
[08:10] <didrocks> yeah
[08:10] <didrocks> but worth a try
[08:10] <jibel> willcooke, the only thing that doesn't work is users installing in bios mode on uefi hardware
[08:11] <seb128> the only code that writes that key is https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L636
[08:11] <jibel> well, "only" ...
[08:11] <didrocks> seb128: oh, it seems ubiquity tries to reuse the session bus
[08:11] <didrocks> so, it's weird it's setting a new one
[08:11] <seb128> didrocks, I'm going to check some uid checks as well, thanks for the help, I'm coming back once I get a bit more debug info/context
[08:11] <didrocks> do you have the process hanging around?
[08:11] <seb128> no, I just closed, I need to reboot
[08:11] <didrocks> seb128: yeah, just try to check ubiquity proc environ
[08:11] <didrocks> ok
[08:11] <didrocks> next time :)
[08:11] <seb128> I'm going to add debug prints and restart
[08:11] <didrocks> line 398 FYI
[08:11] <Laney> this sounds like fun
[08:12] <seb128> thx
[08:12] <seb128> Laney, it is :p
[08:13] <seb128> k, on that note I'm moving back to my desk, no point starting a new debug session from here and my battery is almost empty
[08:13] <seb128> be back in 10 min or so
[08:15] <willcooke> jibel, I saw someone on the hub saying it was broken, but in my testing it wasn't.  What's the use case for bios mode on UEFI?  Is that something people actually need to do, or are they holding it wrong?
[08:17] <jibel> willcooke, they don't need to and there is a warning when they try to do so but if they continue grub installation fails
[08:17] <willcooke> jibel, not a release blocker then?
[08:17] <jibel> willcooke, IIRC there is a bug report to completely block this path because it cannot work
[08:17] <jibel> willcooke, no
[08:18] <willcooke> jibel, thx
[08:18] <juliank> who fixed google calendar online account integration? thanks for that. it's so useful to see my meetings again in shell :)
[08:19] <jibel> willcooke, this post https://community.ubuntu.com/t/grub-efi-amd64-signed-failed-to-install/5274 ?
[08:19] <jibel> there is not much info
[08:20] <jibel> I'll check anyway to make sure nothing broke
[08:22] <willcooke> jibel, yeah that's the one.  It's fine, I just tested it, it worked
[08:22] <willcooke> it = normal install on UEFI
[08:29] <seb128> back
[08:54] <GunnarHj> Good morning all!
[08:54] <seb128> hey GunnarHj
[08:54] <seb128> how are you?
[08:54] <GunnarHj> A question, since I'd like to understand: The seeded snaps, are they on the ISO?
[08:54] <seb128> yes
[08:54] <Laney> seb128: have you seen that misc.py only looks at PKEXEC_UID and gsettings.py only looks at SUDO_USER?
[08:54] <Laney> hey GunnarHj
[08:55] <didrocks> hey GunnarHj
[08:55] <GunnarHj> seb128: The purpose is not ISO space optimizing, I suppose. ;)
[08:55] <seb128> GunnarHj, no, it's to get on with modern technologies
[08:56] <seb128> Laney, no, I didn't, in fact I didn't notice before now that gsettings.py was changing user/using sudo, that explains things
[08:57] <Laney> that part seems unusual to say the least
[08:57] <Laney> I'd think that dropping privs alone should be enough
[08:57] <seb128> yeah
[08:58] <Laney> but misc.py needs to use SUDO_UID too otherwise it doesn't work from the live session
[08:58] <Laney> that desktop file uses sudo not pkexec
[08:59] <Laney> well or change that part I guess
[08:59] <juliank> Is it intentional that gnome-initial-setup runs after initial install and relogin?
[08:59] <seb128> I wonder if we could just        misc.drop_privileges_save() and use the gsettings binding rather than the wrapper?
[08:59] <seb128> juliank, what do you mean "and relogin"?
[08:59] <juliank> seb128: Installed upgrades, logged out, and back in again.
[08:59] <seb128> you go in 2 sessions in a row?
[08:59] <seb128> got it*
[09:00] <juliank> Ran through gnome-initial-setup, it picked up my current keymap and deleted the others.
[09:00] <juliank> apart from that it did not seem harmful
[09:00] <Laney> seb128: probably apart from keeping the API
[09:00] <Laney> like this one lets you just try setting keys on schemas that aren't installed
[09:00] <Laney> gsettings is a bit opinionated about you trying that :-)
[09:01] <seb128> haha
[09:01] <seb128> juliank, you had a screen about locale/keyboard?
[09:01] <didrocks> "a bit"
[09:01] <seb128> juliank, what session do you use?
[09:01] <GunnarHj> juliank: Thought that the keymap part of gnome-initial-setup was hidden.
[09:02] <jibel> I didn't see any locale/keyboard page when I upgraded this morning
[09:02] <seb128> they are not displayed in Ubuntu sessions
[09:02] <seb128> but maybe juliank is using a GNOME session
[09:03] <juliank> oh yes I am
[09:03] <Laney> are we supposed to show g-i-s there?
[09:03]  * juliank thinks it makes sense on first install, but not on upgrades
[09:03] <seb128> robert didn't change the behaviour for !Ubuntu
[09:04] <seb128> well, even on first install
[09:04] <seb128> I guess it could be called upstream experience :p
[09:04] <juliank> well upgrades would be fine too if it did not delete additional keymaps
[09:04] <Laney> it needs integrating with the upstream install experience then
[09:04] <seb128> I don't have really an opinion on that, out of that fact that it duplicates ubiquity questions
[09:04] <Laney> I have an opinion that it shouldn't be run
[09:05] <seb128> sounds fair enough
[09:05] <seb128> we need to fix that then
[09:06] <GunnarHj> Laney, seb128: Selecting language from g-i-s won't reasonably not work well, if the code hasn't been tweaked similar to g-c-c.
[09:06] <Laney> now you have to break the upstream g-i-s experience :/
[09:06] <seb128> well we don't have the installer side so it's broken anyway on Ubuntu
[09:07] <Laney> If someone's using our g-i-s package
[09:07] <jibel> sil2100, kbd pre-selection is fixed on today's iso. Thanks!
[09:07] <seb128> Laney, you mean?
[09:07] <Laney> We remove the desktop file or whatever
[09:07] <seb128> it is in any case, it duplicates ubiquity questions
[09:08] <Laney> Some derivative that is using g-i-s gets that update
[09:08] <Laney> oh look, their gis is now broken
[09:08] <didrocks> as we have per-session XDG_CONFIG_DIRS, we can maybe ship the autostart there? (but it means, shipping for xorg, wayland, communitheme xorg, communitheme wayland)
[09:09] <Laney> it's about turning it off for other sessions though
[09:10] <Laney> Basically it's taking a package which was working if you wanted to use it and making it not work
[09:10] <Laney> Can't see another way though
[09:10] <seb128> well, hypotetical derivative needs an override then, that's part of being a derivate to need to adapt
[09:10] <seb128> for what it's worth I don't know of any using it atm
[09:10] <seb128> so I don't think it's a big deal
[09:11] <Laney> ok, Ubuntu archive Ubuntu packages to do whatever we want with
[09:11] <seb128> for what it's worth I don't think it is/was in a working state
[09:11] <seb128> as GunnarHj said that needs at least to be made to work with how we do translations
[09:12] <seb128> anyway, I agree it's suboptimal
[09:12] <seb128> and wrong in theory
[09:12] <seb128> I'm just saying that in practice it shouldn't be a disaster
[09:13] <Laney> juliank: would you mind filing a bug please?
[09:13] <Laney> I'll probably get this too if I restart but I didn't yet
[09:14] <seb128> Laney, so going back to ubiquity, I'm a bit lost
[09:14] <Laney> sure
[09:15] <seb128> Laney, you think that gsettings.py is doing something wrong with SUDO handling?
[09:15] <Laney> In the ubiquity-dm session as far as I know ubiquity is started via pkexec
[09:15] <Laney> in the *live* session it is started by sudo
[09:15] <Laney> you get PKEXEC_* variables in the first case and SUDO_* ones in the second
[09:15] <Laney> which tell you which user you came from
[09:15] <Laney> that's what ubiquity is using to know who to drop back down to
[09:16] <seb128> I'm in ubiquity-only and I dump the env from gtk_ui.py around the gsettings calls to disable screensaver
[09:16] <Laney> but the code is checking different ones in different places
[09:16] <seb128> and the env has SUDO_USER=ubuntu
[09:16] <seb128> and no PK env
[09:16] <Laney> so if it's using SUDO then the misc.drop_all_privileges thing doesn't work
[09:17] <seb128> it doesn't make sense why it's not creating issues in other places if that's the case :/
[09:18] <juliank> Laney: https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1765644
[09:18] <ubot5`> Ubuntu bug 1765644 in gnome-initial-setup (Ubuntu) "After install, runs in gnome session after logging in again, deletes alternate keymaps" [Undecided,New]
[09:19] <juliank> the title is too long
[09:19] <Laney> thx
[09:19] <juliank> I must say I liked the experience of g-i-s
[09:19] <seb128> Laney, http://paste.ubuntu.com/p/vn4tKc9S73/ is a print(os.environ) after         self.disable_screen_reader() in gtk_ui.py
[09:20] <juliank> apart from that thing
[09:20] <seb128> juliank, we don't intend to use it
[09:20] <juliank> it looked nice
[09:20] <juliank> :)
[09:20] <seb128> at least not this cycle
[09:20] <seb128> we built on it for the ubuntu welcome wizard in ubuntu session
[09:20] <seb128> we are going to look at include some of the upstream screens next though
[09:20] <seb128> like online accounts config
[09:20] <juliank> that one seemed actually useful
[09:21] <juliank> keyboard setting not so much :)
[09:21] <juliank> though just having a Welcome screen is kind of nice too :)
[09:22] <seb128> Laney, oh, there is a PKEXEC_UID as well which I didn't notice earlier, I guess pkexec just set SUDO_USER as well
[09:23] <seb128> k, I think I'm going to do the same as yesterday, early lunch and then I try to rip off that sudo use see if it's really needed
[09:24] <Laney> alright
[09:24] <Laney> how do you get a tty from the only ubiquity sessions?
[09:24] <Laney> thought that was fixed
[09:24] <seb128> it is
[09:24] <Laney> oh yeah
[09:24] <seb128> I can switch to a vt using the normal ctrl-alt-fn
[09:24] <Laney> it just takes like 10 seconds
[09:24] <seb128> right
[09:28] <Laney> seb128: https://paste.ubuntu.com/p/TBPv8pD254/ that's what I can see from /proc/ubi/environ
[09:48] <jibel> bug 1765651 should probably be fixed for the release ?
[09:48] <ubot5`> bug 1765651 in gnome-initial-setup (Ubuntu) "Do not run gnome-initial-setup during OEM preparation stage" [Undecided,New] https://launchpad.net/bugs/1765651
[09:49] <Laney> probably fixing julian_k's would fix that too
[09:49] <Laney> IMHO they could be nominated / assigned but it's not really up to me :-)
[09:50] <jibel> seb128, willcooke ^^ WDYT?
[09:53] <jibel> didrocks, I think telemetry data should include information about OEM installation and the end user setup. For example if I do an OEM install in English and the end user setup in French, it just tells me the installation is in english not the settings selected by the end user.
[09:58] <willcooke> jibel, yeah, sounds sensible
[10:00] <tseliot> Wimpress, mwilson-e: can you test the new nvidia-prime, please? (when it's built) https://launchpad.net/~albertomilone/+archive/ubuntu/deleteme-nvidia
[10:02] <mwilson-e> tseliot: Will do.
[10:02] <tseliot> thanks
[10:19] <mwilson-e> tseliot: Tested on 1 unit so far with MATE and it works. :D
[10:21] <tseliot> mwilson-e: that's good. I can't reproduce the problem here either with the new package
[10:21] <tseliot> I suppose all the other Ubuntu flavours use lightdm, that's why it was failing
[10:22] <Wimpress> tseliot: Sure thing.
[10:22] <tseliot> thanks
[10:51] <Wimpress> tseliot: I'm encountering some issues here.
[10:52] <Wimpress> I've purged all *nivia* paackages from the system.
[10:52] <Wimpress> *nvidia packages
[10:53] <Wimpress> Which also mean nvidia-prime is not installed. But your testing ppa is enabled.
[10:54] <Wimpress> Ah, found the issue.
[10:54] <Wimpress> I still had the graphics-drivers PPA enabled.
[10:58] <tseliot> Wimpress: issues with nvidia-prime?
[10:58] <Wimpress> I'm retesting again now.
[11:01] <Wimpress> I purge all nvidia packages, which means nvidia-prime is not installed and rebooted.
[11:01] <Wimpress> Install nvidia 390 drivers via Additional Drivers UI. Rebooted.
[11:02] <Wimpress> The display manager still works, but nvidia-prime was not installed and libnvidia-compute-390:i386 is a broken package.
[11:03] <tseliot> did you purge libnvidia-compute-390:i386 manually before reinstalling?
[11:03] <Wimpress> Yep
[11:04] <tseliot> neither ginggs nor I managed to reproduce that
[11:04] <tseliot> maybe try reinstalling libnvidia-compute-390:i386
[11:05] <Wimpress> I'm going to test again and make sure no cached packages exist.
[11:08] <didrocks> jibel: good point! g-i-s is runing after the OEM welcome user session, correct?
[11:08] <didrocks> jibel: so, using the current user language can be an option, no?
[11:08] <didrocks> (current == session)
[11:09] <didrocks> the location isn't an issue I guess as we are taking the user's session one
[11:18] <jibel> didrocks, yes it does. current user settings would work
[11:18] <jibel> didrocks, I reported bug 1765672
[11:18] <ubot5`> bug 1765672 in ubuntu-report (Ubuntu) "Add information about OEM installation and end user setup" [Undecided,New] https://launchpad.net/bugs/1765672
[11:21] <seb128> jibel, Laney, robert_ancell is off next week so better not count on him to fix those issues before release
[11:21] <ricotz> hey desktopers
[11:21] <seb128> hey ricotz
[11:21] <ricotz> is someone able to test a firefox package on s390x?
[11:21] <ricotz> seb128, hey
[11:22] <seb128> ricotz, try asking xnox maybe
[11:22] <seb128> Laney, right, your pastebin env is similar to the one I pastebined a bit earlier
[11:23] <Laney> wb seb128
[11:23] <Laney> yes no SUDO stuff there
[11:23] <seb128> thx
[11:23] <seb128> oh, that's a difference
[11:23] <ricotz> xnox, hi, would you like to test a firefox 60 beta build for s390x? available in https://launchpad.net/%7Emozillateam/+archive/ubuntu/firefox-next
[11:23] <seb128> Laney, http://paste.ubuntu.com/p/vn4tKc9S73/ was mine from the gtk_ui code with a print(os.environ)
[11:24] <seb128> that has PKEXEC_UID but also SUDO_USER
[11:25] <didrocks> jibel: many thanks! I'll move them to github as a reminder and this starts to build a list for the first update :)
[11:27] <didrocks> jibel: so, just to sum up, TZ shouldn't be an issue, correct? Only language
[11:27] <didrocks> (you used TZ as well in the bug report)
[11:30] <jibel> didrocks, TZ too. The end user selects his own TZ
[11:30] <jibel> didrocks, and maybe screen resolution too
[11:30] <didrocks> jibel: well, TZ and screen resolutions are taken during the session
[11:30] <didrocks> so it's already the end user selection if g-i-s runs after oem-setup second stage
[11:31] <didrocks> The only part which are OEM (taken from the install) is what is under the "Install" section
[11:31] <jibel> didrocks, it's fine then
[11:31] <didrocks> Install has Media, Type, PartitionMethod, DownloadUpdates, Language, Minimal, RestrictiedAddons,Stages
[11:32] <didrocks> I think only Language should be moved out to session, indeed
[11:32] <jibel> right, looking at the data file, only the language
[11:32] <didrocks> (I guess we can even remove it from ubiquity in the long term)
[11:32] <didrocks> yep, thanks for confirming!
[11:41] <jbicha> juliank: yes, it's intentional that gnome-initial-setup runs for upgraders who have never run it before. Ubuntu GNOME included g-i-s in 17.04 & vanilla-gnome-desktop still pulls it in
[11:41] <juliank> jbicha: well you want to talk to Laney then so he does not disable it?
[11:42] <juliank> or somebody else
[11:42] <jbicha> juliank: do you want to file a bug upstream about your particular issue (the keymap thing not that it runs on upgrades)
[11:43] <juliank> yes I can do that in an hour or so
[11:43]  * juliank goes on lunch walk
[11:47] <jibel> if I want to restart the wizard what do I reset?
[11:47] <jbicha> juliank: hmm, Fedora 28 doesn't show the keyboard page for existing users, we could possibly do that too but we'd have to take their patch and rewrite our vendor.conf
[11:48] <jbicha> jibel:    rm ~/.config/gnome-initial-setup-done
[11:48] <jbicha> (g-i-s-done is an empty file)
[11:48] <jibel> jbicha, thanks
[11:49] <jbicha> it won't ask you about livepatch if you've already configured that
[11:49] <jibel> I cannot configure it anyway. It fails on 2FA
[11:50] <jbicha> oSoMoN: congratulations 🎉
[11:53] <didrocks> worth checking livepatch is set immediately
[11:53] <didrocks> so that the report reports the enablement status :)
[11:53] <didrocks> I thought we want as well to show the report on upgrade, having a non versioned g-i-s-done stamp file will need to be revisited
[11:57] <jbicha> didrocks: oh if we want to ensure it runs for upgraders, even for those who installed g-i-s before (like those upgrading from UG 17.04), maybe we need to adjust that stamp file name *now*
[11:58] <didrocks> jbicha: oh correct…
[11:58] <didrocks> well, it's for .1 maybe at this stage
[11:58] <didrocks> but still worth considering
[11:58] <jbicha> it might be awkward to actually fix that for .1 …
[11:58] <didrocks> willcooke: seb128: thoughts? ^
[11:59] <seb128> I don't think many users installed g-i-s
[11:59] <jbicha> currently implementation is just an empty file ~/.config/gnome-initial-setup-done so it doesn't tell you what GNOME or Ubuntu version was used
[11:59] <seb128> so I don't think it matters much
[12:00] <didrocks> jbicha: was it installed by default on UB?
[12:00] <didrocks> UG*
[12:00] <seb128> I don't think many people installed UG
[12:00] <seb128> and those likely want to use a GNOME session not an Ubuntu one
[12:00] <didrocks> ok, so not having them ~ not important
[12:00] <seb128> and the wizard is not displayed there
[12:00] <jbicha> didrocks: just for 17.04; it wasn't even pacakged for xenial
[12:00] <didrocks> seb128: +1
[12:00] <didrocks> ok, so sounds we can keep it like that
[12:01] <seb128> wfm
[12:01] <didrocks> and then, for next cycle, let's put the version in the file
[12:01] <didrocks> (instead of piling up a lot of empty timestamp files)
[12:01] <Laney> you won't be able to use the AutostartCondition then
[12:01] <didrocks> we can even have different behaviors between "was it already displayed before on a previous release or not?"
[12:01] <didrocks> correct
[12:01] <didrocks> you feel piling empty files are better thus?
[12:02] <didrocks> don't really like it, but yeah, AutostartCondition worths it…
[12:02] <Laney> why piling?
[12:02] <Laney> clean up the old ones
[12:02] <didrocks> shared home between install? :p
[12:02] <didrocks> otherwise, you will keep flip-flap
[12:02] <didrocks> (I know, something people shouldn't do)
[12:03] <Laney> come on
[12:03] <Laney> most applications don't have forwards compatibility in their databases
[12:04] <didrocks> we can give it a try and see if we have angry feedbacks ;)
[12:08] <jibel> didrocks, bug 1765693
[12:08] <ubot5`> bug 1765693 in ubiquity (Ubuntu) "[telemetry] Record OEM installation mode" [Undecided,New] https://launchpad.net/bugs/1765693
[12:09] <didrocks> jibel: thanks! :)
[12:09] <didrocks> waow, you even list the debconf key
[12:09] <didrocks> royal bug report! :)
[12:10]  * didrocks feels like upgraded to 1st class now
[12:13] <oSoMoN> thanks jbicha
[12:16] <juliank> jbicha: that sounds good to me
[12:16] <juliank> but I have not looked at the patch
[12:16] <juliank> The live patch stuff only shows up in the Ubuntu session, right?
[12:18] <juliank> I was like, "just because I want GNOME does not mean I don't want livepatch", but it actually makes no sense; as you'd login to an ubuntu session first thing after install
[12:32] <jbicha> juliank: we're interested in trying to merge the GNOME and Ubuntu versions of gnome-initial-setup a bit more in the future
[12:36] <jbicha> mpt: I filed some first-login-window bugs. Who can I ping for them to get looked at sooner? https://github.com/CanonicalLtd/desktop-design/issues/101 102 105
[12:36] <ubot5-ng> CanonicalLtd bug 101 in desktop-design "First login: What's new: wording suggestions" (comments: 2) [Open]
[12:36] <ubot5`> Error: Launchpad bug 101 could not be found
[12:39] <jdstrand> didrocks: you probably noticed, but if not, apparmor with your communitheme patch is now in bionic
[12:39] <Wimpress> tseliot: OK, I have mostly good news :-)
[12:39] <jdstrand> didrocks: if you need it for other releases, please comment in the bug
[12:40] <Wimpress> Installing the nvidia drivers via the Addition Drivers UI or via `apt install nvidia-driver-390 results in a successful install, nvidia is enabled and lightdm works.
[12:42] <Wimpress> However, I still experience https://pad.lv/1765053 when installing via `ubuntu-drivers autoinstall`
[12:42] <ubot5`> Launchpad bug 1765053 in nvidia-graphics-drivers-390 (Ubuntu) "Errors were encountered while processing: /tmp/apt-dpkg-install-x8YVfC/03-libnvidia-compute-390_390.48-0ubuntu2_i386.deb" [High,In progress]
[12:43] <didrocks> jdstrand: I did notice! I just made people eagerly waiting for it aware about it! Many thanks :) This is only needed starting from 18.04, all good!
[12:43] <jdstrand> didrocks: thanks for the patch. glad we squeezed it in
[12:44] <jibel> uh, looks like we have a problem when users upgrade with an encrypted swpa
[12:44] <jibel> swap*
[12:45] <jibel> system hangs on boot when it tries to activate it
[12:45] <seb128> urg :/
[12:46] <willcooke> jibel, swap file? rather than partition?
[12:48] <jibel> swap partition
[12:48] <jibel> I cannot even enter recovery mode
[12:50] <seb128> do you know why? sounds line something foundations might understand better than us
[12:53] <jibel> not yet, I'll file a bug once I've enough info, and indeed it's a foundations thing
[13:01] <jbicha> jibel: bug 1736072 was in my history
[13:01] <ubot5`> bug 1736072 in systemd (Ubuntu) "Encrypted swap does not work" [High,Incomplete] https://launchpad.net/bugs/1736072
[13:05] <jibel> jbicha, it's very similar but this bug report is really confusing, talking about ubiquity. In my case it's an upgrade from xenial with an encrypted home. I'll file a separate report and they can always duplicate
[13:52] <Wimpress> didrocks: Do you have a few minutes to discuss ubuntu-report?
[13:53] <seb128> Wimpress, don't ask to ask just ask?
[13:53] <Wimpress> I know people are busy :-)
[13:54] <Wimpress> Too British.
[13:55] <oSoMoN> please excuse me for begging your pardon :)
[13:57] <kenvandine> lol
[13:58] <Wimpress> didrocks: ubuntu-report send is only executed via the GNOME first run wizard, correct?
[14:02] <seb128> Wimpress, atm yes, but there is a cli utility and the api can be used by derivates who want to
[14:02] <tseliot> Wimpress: I'm not sure about that, to be honest
[14:03] <didrocks> Wimpress: so yes, you can either use the C lib or the Go one or the CLI
[14:03] <didrocks> but current integration is via GNOME first run wizard
[14:03] <didrocks> you have man pages on the CLI (automatically generated)
[14:03] <didrocks> the Go API if available at https://godoc.org/github.com/ubuntu/ubuntu-report/pkg/sysmetrics
[14:04] <didrocks> and the C is at https://godoc.org/github.com/ubuntu/ubuntu-report/pkg/sysmetrics/C
[14:04] <didrocks> check the README.md of the project: https://github.com/ubuntu/ubuntu-report
[14:04] <Wimpress> I just wanted to confirm that no reports are being sent via Ubiquity.
[14:04] <didrocks> nope!
[14:04] <didrocks> you will have it writing a file
[14:04] <didrocks> as /var/log/installer/telemetry
[14:05] <didrocks> but it's not used by anything
[14:05] <Wimpress> It is therefore the responsibility of each flavour to instruct users to submit, or not, their reports as the first run wizard does in Ubuntu.
[14:05] <didrocks> exactly!
[14:05] <Wimpress> Thanks.
[14:05] <didrocks> Wimpress: upgrade will also flesh out a file
[14:05] <didrocks> in /var/log/upgrade/telemetry
[14:05] <Wimpress> Should flavours send reports to the same URL as Ubuntu?
[14:05] <didrocks> but same than ubiquity, it won't be used
[14:06] <didrocks> I think they should
[14:06] <didrocks> there is the current running session sent as info
[14:06] <didrocks> but you can't really say something is xubuntu, ubuntu or ubuntu-mate
[14:06] <Wimpress> And install media, which includes the flavour.
[14:07] <didrocks> (well, we report the install media)
[14:07] <didrocks> yes
[14:07] <didrocks> but then, what would be about ubuntu-mate where I install ubuntu-desktop? :p
[14:07] <didrocks> or the contrary
[14:07] <didrocks> this is why current session is the best IMHO
[14:07] <didrocks> (and no different URL)
[14:07] <didrocks> making sense?
[14:07] <Wimpress> So perhaps sending to the same URL as Ubuntu is fine?
[14:07] <didrocks> yep!
[14:08] <Wimpress> Cool.
[14:08] <Wimpress> Well add something to Welcome to facilitate this.
[14:08] <didrocks> Wimpress: excellent! Do not hesitate if you have any integration question
[14:08] <didrocks> do you plan to use the API or wrapping the CLI?
[14:09] <Wimpress> Just the cli for now. Simplest thing possible.
[14:09] <didrocks> yeah, so look at the various command in the manpages to automate it
[14:09] <Wimpress> Well put a similar UI to GNOME first run in front of it.
[14:09] <didrocks> (they are in the README)
[14:09] <Wimpress> Yep, I've read it 🙂
[14:10] <didrocks> \o/ at least, it's been useful for one person! :)
[14:10] <didrocks> basically, I guess, you will do:
[14:10] <didrocks> $ ubuntu show <- get the json from here
[14:10] <didrocks> $ ubuntu send yes|no
[14:11] <didrocks> (no is the optout message, yes is to send the previous report)
[14:14] <kenvandine> jibel, irt bug 1765651
[14:14] <ubot5`> bug 1765651 in gnome-initial-setup (Ubuntu Bionic) "Do not run gnome-initial-setup during OEM preparation stage" [High,Triaged] https://launchpad.net/bugs/1765651
[14:14] <kenvandine> jibel, do you know how to detect if we're in the OEM preparation stage?
[14:14] <kenvandine> or anyone ^^
[14:15] <didrocks> probably some env var? /me doesn't know much about OEM
[14:15] <jibel> kenvandine, let me check
[14:32] <jibel> kenvandine, if really you want to be sure, current user is 'oem', set to log in automatically and /home/oem/Desktop/oem-config-prepare-gtk.desktop exists
[14:32] <jibel> this user is removed on first boot after the system is prepared
[14:32] <jibel> i'll document the bug report
[14:33] <kenvandine> oh... probably just check if the current user is oem
[14:33] <kenvandine> we should never want to run in that case
[14:33] <Laney> can't the file be touched for the oem user?
[14:34] <jibel> well if your username is 'oem' then you won't see the initial setup :)
[14:35] <jibel> right we could do that too in the ubiquity hook
[14:35] <jibel> much simpler actually
[14:35] <kenvandine> jibel, that's probably the best fix
[14:36] <jibel> moving to ubiquity then
[14:36] <kenvandine> jibel, great!
[14:38] <Laney> yes in plugininstall.py when it sets up the oem user
[14:43] <jibel> unrelated to the original bug I reported but slightly worrying for the initial setup https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1765724/comments/3
[14:43] <ubot5`> Ubuntu bug 1765724 in cryptsetup (Ubuntu) "Xenial -> Bionic - System fails to boot after upgrade - <email address hidden> fails to start" [Critical,New]
[14:56] <seb128> ok, I give up trying to understand why gsettings changes signal don't work in ubiquity
[14:57] <didrocks> seb128: fresh brain on Monday might help :)
[14:58] <seb128> didrocks, Laney, jibel, the keys unsettings themself I explained, the wrapper does that
[14:58] <seb128>     subp = subprocess.Popen(
[14:58] <seb128>         ['sudo', '-H', '-u', user, 'gsettings', 'get', schema, key],
[14:58] <seb128>         stdout=subprocess.PIPE, stderr=subprocess.PIPE,
[14:58] <seb128> or sudo empty the env so the DBUS_ADDRESS... is not set and a new bus is spawned
[14:58] <seb128> adding '-E' to the arguments fix that part
[14:58] <seb128> fixes
[14:58] <didrocks> making sense
[14:58] <seb128> no extra dconf-service anymore
[14:58] <seb128> no key unset
[14:59] <didrocks> so, at least, no double service, which is a win :)
[14:59] <seb128> but I can't get the gsettings changed signal to work
[14:59] <seb128> without or without dropping priviledge
[14:59] <seb128> the dbus env is correct
[14:59] <seb128> the gsettings api documentation states "Note that settings only emits this signal if you have read key at least once while a signal handler was already connected for key ."
[14:59] <seb128> which I though could have been the issue
[14:59] <seb128> but I added a get_boolean() call to the code after the connect, no luck
[14:59] <didrocks> yeah, I was going to mention that
[15:00] <didrocks> that would have been my bet for that issue :/
[15:00] <seb128> that's my current patch
[15:00] <seb128> http://people.canonical.com/~seb128/ubiquity-screen-reader.patch
[15:01] <jibel> Laney, do we care if the owner is root?
[15:01] <didrocks> seb128: I should be free on Monday for a peer looking into that issue if you want
[15:01] <Laney> want me to look in a bit?
[15:01] <didrocks> I would say, still get that in
[15:01] <Laney> jibel: umm, probably, can't you use 'install'?
[15:01] <seb128> didrocks, Laney, help would be welcome if you guys have some idea, as said my current work is on there ^
[15:02] <didrocks> seb128: I'll go off in the next minutes, hence proposing looking at that together at that time (but still push your changes, they are valid)
[15:03] <seb128> didrocks, I'm at least going to proposed the '-E' use
[15:03] <seb128> let's see on monday
[15:03] <didrocks> seb128: yeah, the -E is safe and needed anyway
[15:03] <seb128> maybe Laney pokes a bit still today and figure out something
[15:03] <didrocks> to connect to the right bus
[15:04] <seb128> I'm pondering cleaning the ubiquity-dm dbus activation/dconf-service code
[15:04] <seb128> I wonder if that could be useful for any other derivative
[15:04] <didrocks> seb128: the impact is on flavors…
[15:04] <seb128> probably not, but there is no need to change that at this point
[15:04] <didrocks> yeah
[15:04] <didrocks> correct :/
[15:04] <didrocks> if we avoid for us spawning it that way, I don't think it worths touching
[15:04] <didrocks> (that way == -E)
[15:06] <seb128> right
[15:07] <didrocks> I don't spot anything on the connect change signal from your diff…
[15:08] <seb128> anything wrong you mean?
[15:08] <didrocks> yeah, sorry
[15:08] <seb128> thx for looking
[15:08] <seb128> as said let's forget about it for this week
[15:08] <seb128> maybe Laney sees something
[15:08] <seb128> otherwise new round on monday
[15:08] <didrocks> yeah, let's do this! :)
[15:08] <seb128> thx didrocks!
[15:09] <seb128> at least we explained the dconf unset thing
[15:09] <didrocks> yw, and nice hunting, even if not yet completely resolved ;)
[15:09] <didrocks> yep
[15:09] <seb128> thx
[15:09] <didrocks> happy the theory was correct :)
[15:09] <seb128> :)
[15:10] <didrocks> seb128: just, ubiquity-dm is using the glib mainloop, correct?
[15:10] <didrocks> to deliver signals…
[15:10] <didrocks> I guess so, just asking ;)
[15:10] <seb128> good question
[15:10] <Laney> you mean ubiquity itself?
[15:10] <Laney> it's gtk ...
[15:11] <didrocks> Laney: well, the code is in ubiquity-dm which launch ubiquity UI as a subprocess, no?
[15:11] <seb128> the callback is in gtk_ui.py
[15:11] <didrocks> ah no, that part of the code is in gtk_ui.py
[15:11] <didrocks> yep
[15:11] <seb128> which is the frontend
[15:11] <didrocks> ok, so obviously not it
[15:11] <didrocks> well, let's sleep on that
[15:12] <didrocks> and enjoy the week-end and park+sun :)
[15:12] <seb128> right
[15:12] <seb128> thx, same to you!
[15:12] <didrocks> see you on Monday guys!
[15:12] <didrocks> thx :)
[15:32] <seb128> shrug, just did a nautilus upload that got rejected
[15:32] <seb128> jbicha, you forgot to commit/push your recent changes to the vcs :/
[15:34] <seb128> ok, I guess one less fix uploaded to bionic then, I need to step out, maybe later
[15:34] <seb128> jbicha, if you fix the vcs I can retry to include those, I uncommited/force pushed back
[15:34] <jbicha> seb128: pushed now. Sorry about that. I seem to be having lots more trouble remembering to push to bzr these days :|
[15:43] <seb128> jbicha, thx
[16:04] <seb128> k have a good w.e desktopers
[16:04] <seb128> I'm out for a bit, might deal with a bit of backlog still later
[16:05] <oSoMoN> have a good one seb128 !
[16:29] <Laney> this is some weird shit
[16:57] <Laney> I tried making the GSettings an instance variable in case it was going out of scope
[16:57] <Laney> NOPE
[16:58] <Laney> I made it so that gsettings.py wasn't making a new dconf-service process spawn (hacking DBUS_SESSION_BUS_ADDRESS in the child processes)
[16:58] <Laney> NOPE
[16:58] <Trevinho> Laney: looser :-D
[16:58] <Laney> the GSettings isn't getting connected to the right dconf daemon somehow
[16:59] <Laney> this is some messed up stuff
[16:59] <Laney> if you make it write then the callback is called
[16:59] <Laney> but then there's an error that it can't commit the change "the connection is closed"
[16:59] <Trevinho> you need to define the runtime dir too
[16:59]  * Laney slaps Trevinho 
[16:59] <Trevinho> at least, not sure what you're trying though
[16:59] <Laney> why
[16:59] <Laney> dbus and dconf is already running
[16:59] <Laney> I just want to get on the existing ones
[17:00] <Trevinho> ah, yeah I mean the standard ones'
[17:00] <Trevinho> ?
[17:00] <Laney> probably XDG_RUNTIME_DIR isn't set
[17:00] <Laney> but I don't need to spawn anything new, and DBUS_SESSION_BUS_ADDRESS is ok
[17:00] <Laney> arghghghgh
[17:01] <Laney> this is the wurst
[17:01] <Laney> the bockwurst
[17:02] <Laney> I'm going
[17:02] <Laney> we're off to a pizza place for a friend's birthday
[17:02] <Laney> #trevinhocompliant
[17:02] <Trevinho> ahha
[17:03] <Trevinho> No, when it involves friends it's always ok
[17:03] <Trevinho> I even eat that horrible pizza with you guys in holland
[17:05] <oSoMoN> it's 5 past beer, I'm off to a micro-brewery
[17:05] <oSoMoN> have a good week-end everyone!
[17:30] <willcooke> righty ho, time for something else.  Happy weekend all
[18:35] <teeramisu> Hello, is this bug? should i report bug? https://gist.github.com/Parduk/790a233bbfa3b1f807c772089a671f85
[18:56] <jbicha> teeramisu: do not use sudo to run gnome-control-center
[19:04] <teeramisu> jbicha: so its not bug right?