[06:41] <didrocks> good morning
[06:42] <jibel> good morning didrocks
[06:43] <didrocks> salut jibel
[06:50] <jibel> didrocks, ça va ?
[07:15] <seb128> good morning desktopers
[07:30] <didrocks> salut seb128, ça va jibel, et toi ?
[07:30] <seb128> lut didrocks, en forme ?
[07:30] <seb128> didrocks, cf #u-r
[07:33] <didrocks> seb128: ça va, je reboot rapidement pour tester un snap (j'ai lu #u-r, urgh, mais bon, au moins, on sait comment gardinenner ce code)
[07:33] <didrocks> gardienner?
[07:33]  * didrocks brb
[07:34] <didrocks> at least, my snap fix works :)
[07:34] <didrocks> seb128: need a hand for ubiquity?
[07:35] <seb128> so repeating here, since it's more of a desktop issue
[07:35] <seb128>  the code does
[07:35] <seb128>          if gnome_session:
[07:35] <seb128>              manager = session.get_object('org.gnome.SessionManager',
[07:35] <seb128>                                           '/org/gnome/SessionManager')
[07:35] <seb128>              manager.RequestReboot()
[07:35] <seb128>  so it's using dbus to talk directly to gnome-session
[07:35] <seb128>  which gives
[07:35] <seb128>  No such interface '(null)' on object at path /org/gnome/SessionManager
[07:35] <seb128> didrocks, any idea how that could lead to a (null) interface error?
[07:36] <seb128> I guess RequestReboot() is a method of the manager dbus object
[07:37] <seb128> k, I've the iso, booting to the live session, let's see
[07:37] <didrocks> running d-feet currently
[07:37] <didrocks> while updating the iso
[07:38] <seb128> I especially don't understand how that can be a new/ubiquity issue
[07:38] <seb128> if anything I would have say a gnome-session issue
[07:38] <seb128> but that component didn't change
[07:38] <didrocks> yeah, not related to anything we changed…
[07:38] <didrocks> session.get_object -> there is no iface parameter, correct?
[07:39] <didrocks> only name and object path
[07:40] <didrocks>     `bus_name` : str
[07:40] <didrocks>     `object_path` : str
[07:41] <seb128> I can confirm that the code is buggy in a python3 interpreter on the live CD
[07:41] <seb128> as an user
[07:41] <didrocks> not only on the live
[07:41] <didrocks> on my session as well
[07:41] <seb128> so not ubiquity, sudio, weird env or anything
[07:41] <seb128> right
[07:41] <seb128> why did that start today?
[07:41] <seb128> jibel, when did you see that dialog working last?
[07:41] <willcooke> hey seb128 didrocks
[07:42] <didrocks> I wonder if it really started today
[07:42] <didrocks> hey willcooke
[07:42] <seb128> hey willcooke
[07:42] <didrocks> the puzzling part is that you normally say on which interface you have the method attached
[07:42] <willcooke> I'm heading in to the office in a mo with my test laptop for x_nox to fix the hang on reboot of the live session
[07:42] <didrocks> and here, we never did
[07:42] <seb128> great
[07:46] <seb128> didrocks,
[07:46] <seb128> $ gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager --method org.gnome.SessionManager.RequestReboot
[07:46] <seb128> gives a method not implemented on interface org.gnome.SessionManager
[07:47] <didrocks> seb128: it works for me in a ipython3
[07:47] <didrocks> like:
[07:47] <seb128> I guess I'm doing something wrong :p
[07:47] <didrocks> manager = session.get_object('org.gnome.SessionManager',
[07:47] <didrocks>                              '/org/gnome/SessionManager')
[07:47] <didrocks> iface = dbus.Interface(manager, "org.gnome.SessionManager")
[07:47] <didrocks> iface.IsSessionRunning()
[07:47] <didrocks> for instance
[07:48] <didrocks> doesn't work with RequestReboot though???
[07:49] <didrocks> why IsSessionRunning, which is on the same object and interface works (while it doesn't work on "manager" along without an interface specified) and not RequestReboot…
[07:51] <didrocks> CanShutdown() works as well, for instance (once you execute it against the interface)
[07:51] <didrocks> isn't there some polkit thing which would hide the method?
[07:52] <didrocks> nothing in /usr/share/polkit-1
[07:52] <jibel> just to confirm, the same test passes with previous image.
[07:52] <seb128> it doesn't make any sense
[07:52] <didrocks>  /o\
[07:52] <seb128> didrocks, same in d-feet, I can't trigger RequestReboot
[07:52] <seb128> while it's listed
[07:52] <seb128> but same on xenial
[07:52] <didrocks> 1. I don't understand how this code could have worked *ever*
[07:52] <seb128> same
[07:52] <didrocks> as you don't specify an interface
[07:53] <didrocks> 2. I don't understand why specifying the interface, you can access some methods, and not others…
[07:53] <didrocks> while*
[07:53] <seb128> I wonder if it always failed to use the session codepath for some reason that we might have fixed
[07:53] <didrocks> if gnome_session being False, you mean?
[07:54] <seb128> I know
[07:54] <seb128> Laney broke it
[07:54] <didrocks> ?
[07:54] <seb128> -Exec=sudo sh -c 'ubiquity gtk_ui'
[07:54] <seb128> +Exec=sudo --preserve-env=DBUS_SESSION_BUS_ADDRESS,XDG_RUNTIME_DIR sh -c 'ubiquity gtk_ui'
[07:54] <seb128> without the DBUS ADDRESS env it wasn't finding the session object
[07:54] <seb128> so it never used that code
[07:54] <didrocks> ohhhhhhh
[07:54] <didrocks> so fixing the dbus addressing, we trigger that issue :p
[07:55] <seb128> right
[07:55] <didrocks> "fun fun fun"
[07:55] <seb128> which was not needed in the session
[07:55] <seb128> that's the .desktop change
[07:55] <didrocks> yep
[07:55] <didrocks> still doesn't explain 1. and 2.
[07:55] <seb128> that Laney did because it's the right thing to do
[07:55] <seb128> it explains 1
[07:55] <didrocks> well, maybe this code was never triggered ever
[07:55] <seb128> right
[07:55] <didrocks> I thought people implementing it would have tried it :p
[07:55] <seb128> that's what I think
[07:55] <didrocks> but why 2. ?
[07:55] <seb128> that's a good question
[07:55] <seb128> ok, now we understand the problem, let's fix it
[07:56] <seb128> it behaves the same on xenial
[07:56] <didrocks> yep
[07:56] <seb128> so not a new problem in gnome-session or co
[07:56] <didrocks> right
[07:56] <didrocks> good to know how it started :)
[07:56] <didrocks> so, even if we do the correct fix with using the iface
[07:56] <didrocks> we need to understand 2.
[07:56] <didrocks> it's not even "you can't execute", it's really "doesn't exist"…
[07:57] <seb128> easy fix is to delete that code
[07:57] <didrocks> wait
[07:57] <seb128> it has always been using the else case
[07:57] <didrocks> maybe it's really not implemented
[07:57] <seb128> we could keep doing so
[07:57] <didrocks> on gnome-session side
[07:57] <didrocks> and return this error
[07:57] <didrocks> seb128: agreed
[07:57] <seb128> those APIs were distro patch added
[07:58] <seb128> 95_dbus_request_shutdown.patch
[07:58] <seb128> in the debian dir
[07:59] <seb128> I wonder if something changed in gnome-session since those were added which make the implementation needing an update
[07:59] <didrocks> yeah, like it's declared but not wired up to the function
[07:59] <didrocks> the patch itself isn't enough to see where it's wired up
[08:00] <didrocks> yep
[08:00] <didrocks> there is a registration
[08:01] <didrocks> on the g_dbus_interface_skeleton_export
[08:01] <didrocks> and we don't do that for own methods
[08:01] <didrocks> our*
[08:01] <didrocks> so that explains 2.
[08:01] <didrocks> :q
[08:02] <didrocks> seb128: gnome-session/gsm-manager.c, line 3208 and so on
[08:02] <didrocks> anyway, not going to change that, I think we should fallback to the current behavior
[08:02] <didrocks> (current == until today)
[08:03] <didrocks> seb128: I would just ditch the broken code in ubiquity
[08:04] <seb128> +1
[08:04] <seb128> do you want to mp it?
[08:04] <didrocks> I can, sure
[08:04] <seb128> thx
[08:04] <didrocks> that's one a funny very well intended side-effect :p
[08:04] <didrocks> unintended*
[08:04] <didrocks> can't type today…
[08:04] <seb128> teaching us for changing more than needed :p
[08:04] <didrocks> but I guess I can press del!
[08:04] <didrocks> yeah ;)
[08:05] <didrocks> there are others import dbus…
[08:05] <didrocks> I hope we won't have similar issues that we don't notice at first
[08:06] <didrocks> (most of them are using the single SystemBus, so, should be ok)
[08:06] <didrocks> should I do the minimal part?
[08:07] <didrocks> delete the code or just force gnome_session = False?
[08:07] <didrocks> (so that we fix it later)
[08:07] <didrocks> depends, if we want to remove the distro-patch anyway… hum
[08:07] <didrocks> wdyt?
[08:07] <seb128> I would fix the distro patch
[08:07] <didrocks> ok, so let's keep the code
[08:07] <seb128> according to codesearch.debian.net some projects do call to that API
[08:07] <didrocks> and just force gnome_session=False?
[08:08] <seb128> +1
[08:08] <didrocks> with a FIXME
[08:08] <seb128> with a code comment
[08:08] <didrocks> doing
[08:08] <didrocks> sure :p
[08:08] <seb128> thx
[08:08] <didrocks> "# FIXME: please ping seb128"
[08:08] <didrocks> :)
[08:09] <seb128> lol
[08:09] <seb128> PING
[08:13] <didrocks> jibel: seb128: testing with http://paste.ubuntu.com/p/zcgbM59pZQ/
[08:16] <seb128> didrocks, looks good to me from a reading-the-diff perspective
[08:16] <didrocks> yeah, let's get it executed
[08:16] <seb128> didrocks, maybe include a reference to the lp bug?
[08:16] <didrocks> also ./tests/run-pep8 works :)
[08:17] <didrocks> I did it in the changelog, can do on the FIXME as well
[08:18] <seb128> need a full install to test
[08:18]  * seb128 starts one
[08:18] <didrocks> seb128: can you do in ubiquity-dm?
[08:18] <didrocks> testing on live right now
[08:19] <seb128> k, though it shouldn't have an impact in -dm
[08:19] <didrocks> shouldn't
[08:19] <seb128> but best to test, we had enough of uuupso cases this week
[08:19] <didrocks> but we didn't think about those kind of side-effect :)
[08:19] <didrocks> yeah
[08:19] <seb128> :)
[08:19] <didrocks> like the oem config key was THERE on the oem install
[08:19] <didrocks> and it's checked multiple times in the code :p
[08:19] <Laney> moin
[08:19] <didrocks> (install in progress)
[08:20] <didrocks> Hey Laney! Today is Wednesday and as everyday, we have an ubiquity upload to do!
[08:20] <Laney> fun
[08:21] <jibel> didrocks, thx, let me test it too
[08:21] <didrocks> thanks jibel!
[08:21] <seb128> hey Laney
[08:21] <Laney> hey
[08:22] <Nafallo> morning
[08:22] <Nafallo> or well. late late morning.
[08:23] <Nafallo> had to take morphine, so feel asleep again for an hour or so.
[08:23] <didrocks> hey Nafallo
[08:26]  * willcooke -> train station 
[08:26] <didrocks> jibel: seb128: Laney: no crash clicking on reboot
[08:26] <didrocks> do you want me to perform another test?
[08:26]  * didrocks MP meanwhile
[08:26] <seb128> beefy machine you have :)
[08:26] <didrocks> it never had a 32 bits system on it! :)
[08:27]  * seb128 does get used as "power off" being used in the gnome-shell menu to "disconnect" eth
[08:27] <seb128> lol
[08:27] <jibel> huh, kdb selection broken again?!
[08:27] <seb128> doesn't*
[08:27] <jibel> to be confirmed ...
[08:27] <didrocks> oh, didn't notice
[08:27] <seb128> how so?
[08:28] <seb128> it picked azerty for me
[08:28] <seb128> but I didn't try to change it
[08:28] <didrocks> yeah, same here
[08:28] <jibel> maybe I did something weird
[08:28] <didrocks> I selected my language in syslinux though
[08:28] <seb128> same
[08:28] <seb128> which was the case which was always working
[08:28] <seb128> what wasn't was to change in the UI
[08:28] <didrocks> let me try it in -dm without doing anything at boot
[08:31] <didrocks> works here
[08:31] <didrocks> in -dm, picked French
[08:31] <didrocks> default sectrion in Français/Français (variante obselete)
[08:31] <didrocks> and typing is azerty
[08:31] <didrocks> changing selection and back to French layout works
[08:32] <didrocks> hum, when you don't have an Internet connexion (seems it failed to detect it), the checkbox is grey
[08:32] <didrocks> for updates
[08:32] <didrocks> but selected
[08:32] <didrocks> which is puzzling
[08:34] <seb128> we should probably uncheck it before setting it unsensitive
[08:34] <seb128> should be easy to fix
[08:34]  * seb128 adds to the list of cleanups
[08:34] <didrocks> do you want to do more changes? :)
[08:34] <seb128> that week poking at ubiquity made me want to clean some things at least while I'm looking at it
[08:35] <seb128> not for release :p
[08:35] <seb128> but for +1 or .10
[08:35] <seb128> .1 or .10
[08:35] <didrocks> yeah ;)
[08:35] <didrocks> https://code.launchpad.net/~didrocks/ubiquity/fix-crash-on-reboot/+merge/344215
[08:35] <didrocks> please provide your testing feedback here ^
[08:36] <seb128> installation is still ongoing but almost there
[08:37] <jibel> ah what does not work is to select english in ubiquity-dm then boot to the live session and select french
[08:37] <jibel> "doesn't work" is arguable
[08:38] <didrocks> ah…
[08:38] <Laney> anywayssssssssssss
[08:38] <Laney> this RequestReboot thing got broken basically?
[08:38] <didrocks> was never working rather :p
[08:39] <didrocks> 1. the code was never executed as lacking correct DBUS_ address
[08:39] <didrocks> 2. now that it executes, the code is broken in ubiquity: you don't call a method on a dbus proxy, but need using the interface
[08:39] <didrocks> 3. the RequestReboot() and RequestShutdown() are broken (not wired up) in gnome-session
[08:39] <didrocks> unsure since then those methods don't work
[08:40] <Laney> ok, well these days you can use logind for that anyway
[08:40] <Laney> so don't need to fix 3
[08:41] <Laney> (and that's on the system bus ^_^)
[08:41] <seb128> Laney, we should, codesearch.debian shows that there are a bunch of users of that API
[08:42] <seb128> and there might be third party code/admin scripts
[08:43] <seb128> we should fix/get those commited upstream imho
[08:43] <Laney> how can things be using it in debian?
[08:45] <seb128> Laney, https://sources.debian.org/src/italc/1:3.0.3+dfsg1-3/ica/src/LocalSystemIca.cpp/?hl=193#L193
[08:46] <Laney> the patch isn't there
[08:46] <seb128> Laney, I'm unsure what type of answer you want from me?
[08:46] <seb128> right
[08:46] <seb128> but it exists in Ubuntu and maybe it's enough for some upstream to have started using it?
[08:46] <seb128> well I don't know
[08:46] <Laney> ah whatever, if you want to fix it just do it
[08:48] <seb128> it's probably not important, i'm trying to see if upstream maybe wants it
[08:48] <seb128> I would feel better not removing an API that existed if it's easy to keep for compatibility reasons
[08:48] <seb128> but no big deal either way
[08:51] <Laney> didrocks: any reason to keep the code rather than just adding an XXX: this should use logind comment?
[08:52] <Laney> doesn't *really* matter, but we could avoid a bit of dbus traffic
[08:53] <didrocks> Laney: we decided to restore it, but we can later rather switch to logind
[08:54] <didrocks> Laney: I don't think that matters, whoever is going to change it afterwards will pick the best decision IMHO
[08:54] <Laney> but now we're doing a GetNameOwner that we ignore the result of
[08:54] <seb128> we have a mp ready/up for merging/tested in live and -dm mode
[08:54] <seb128> so depends how much you want to delay landing/respin I guess
[08:55] <didrocks> yeah
[08:55] <Laney> :/
[08:55] <seb128> either way it doesn't matter much
[08:55] <Laney> this isn't a nice way to approach reviews
[08:55] <seb128> ?
[08:55] <seb128> that was stating the situation
[08:55] <seb128> we can tweak/restest which delays a bit
[08:56] <seb128> or we can merge than, land and line up another mp to be merged directly on friday
[08:56] <seb128> it's up to you as a r-t member to tell us what is best from those who handle the isos respsins perspective
[08:56] <seb128> I don't think anyone is being unreasonable?
[08:57] <Laney> ok it sounded like you were saying "ship this thing, making us change it is busy work"
[08:57] <seb128> no, sorry it sounded like that
[08:57] <seb128> I'm fine doing the change, now or post respin/release is your call
[08:58] <jibel> I don't mind retesting if you change it now. It'd delay the merge by 1h or so
[08:59] <seb128> right, same
[08:59] <seb128> time to write the change and retest should burn 1 or 2 hours
[08:59] <seb128> so r-t call
[09:00] <seb128> I'm moving location, back in 7-8 minutes
[09:02] <jibel> didrocks, can you update your mp to drop the broken code completely? I don't think 1h or 2 impacts the release much
[09:03] <didrocks> ok, we decided against it to revive it later on, but fine…
[09:03] <didrocks> I don't see what it gives us TBH
[09:03] <didrocks> but meh
[09:05] <didrocks> ok, removing the dbus import completely thus
[09:07] <didrocks> Laney: jibel: pushed to lp:~didrocks/ubiquity/fix-crash-on-reboot, need retesting
[09:08] <jibel> thanks, retesting
[09:08] <didrocks> doing it on live
[09:08] <didrocks> Laney: helping as well retesting?
[09:09] <seb128> (back)
[09:10] <didrocks> seb128: so, pushed code removal, need retesting, jibel is doing it, I'm doing on the live and ask Laney for helping as well
[09:11] <seb128> didrocks, sounds good, thanks
[09:11] <seb128> that way everyone is happy :)
[09:12] <Laney> thx
[09:13] <didrocks> and ubiquity crashed…
[09:14] <seb128> one change too much?
[09:14] <didrocks> well, I removed the unused now dbus import
[09:14] <seb128> just delete the
[09:14] <seb128>         try:
[09:14] <seb128>             session = dbus.Bus.get_session()
[09:14] <seb128>             gnome_session = session.name_has_owner('org.gnome.SessionManager')
[09:14] <didrocks> because I'm sure then someone will come and say "we import something not used in that file"
[09:15] <didrocks> maybe the mainloop binding was only done by that file
[09:15] <seb128> from dbus.mainloop.glib import DBusGMainLoop is the mainloop one
[09:15] <seb128> what's the error?
[09:15] <didrocks> I don't have a traceback
[09:15] <didrocks> just a regular segfault
[09:15] <seb128> journal?
[09:16] <didrocks> so, let's readd the mainloop
[09:16] <jibel> didrocks, when did it crahs?
[09:16] <didrocks> jibel: after partionning
[09:16] <Trevinho> oh hey guys
[09:16] <didrocks> not for you?
[09:17] <seb128> hey Trevinho, how are you?
[09:17] <jibel> be patient, the iso is still building ...
[09:17] <didrocks> jibel: well, I can reliably crash it
[09:17] <didrocks> anyway, I'm readding the mainloop, if someone then wants to do that in the correct file calling dbus, he can, ensuring there is no impact on flavors
[09:17] <seb128> nothing in the journal?
[09:18] <didrocks> avril 25 11:16:55 ubuntu kernel: traps: ubiquity[8130] trap int3 ip:7f30e9c67c41 sp:7fff937d7f20 error
[09:18] <seb128> right, let's stick to the minimum
[09:18] <seb128> delete try: snippet
[09:18] <didrocks> the minimum would be to not remove the call
[09:18] <seb128> to remove the get_session
[09:18] <didrocks> but meh
[09:18] <seb128> well, removing that call makes L_aney happy
[09:18] <seb128> and shouldn't create an issue?
[09:18] <didrocks> will see
[09:19] <seb128> what did you delete exactly in the buggy version?
[09:19] <seb128> just the import dbus?
[09:19] <seb128> or also the DBusGMainLoop bits?
[09:19] <didrocks> well, you need to delete as it's from the dbus import
[09:19] <didrocks> I guess that binding shouldbe done where dbus is called
[09:20] <didrocks> which it isn't anymore on that file
[09:20] <seb128> k, I guess that's needed
[09:20] <seb128> too much change indeed
[09:20] <didrocks> but as said, that's enough for me, let's readd it
[09:20] <seb128> let's stick to the minimal bits
[09:20] <seb128> right
[09:20] <seb128> we can do better cleanups next cycle
[09:20] <didrocks> if r-t wants to argue that's an uneeded import, they will figure out where adding it back
[09:20] <seb128> "we" being whoever works on the installer
[09:20] <didrocks> well
[09:20] <seb128> I don't think it's going to be an issue
[09:20] <seb128> let's just do that
[09:20] <didrocks> there are 23 FIXME in the installer
[09:21] <seb128> seems it's a middle ground that makes everyone happy
[09:22] <didrocks> pushed a new rev
[09:22] <didrocks> please test
[09:22]  * didrocks does as well
[09:23] <Laney> don't see it
[09:24] <Laney> to be clear, I didn't say that having a FIXME is bad, in fact I said "rather than just adding an XXX: this should use logind comment"
[09:24] <didrocks> Laney: refresh
[09:25] <didrocks> at least, we won't have divergent code path anymore, just one
[09:25] <Laney> thx
[09:27] <Trevinho> seb128: good... Sorry, speaking with Jonas, as we were discussing about one crash fix, and we just landed it :)
[09:28] <Trevinho> seb128: so far I think the shell reports are basically reduced to low volumes on e.u.c
[09:28] <didrocks> what? another ubiquity crash…
[09:28] <didrocks> with http://paste.ubuntu.com/p/D7VnTnTqHM/
[09:30] <didrocks> nice, unpacking and apport-unpack crashes
[09:30] <seb128> Trevinho, great work Marco!
[09:30] <Trevinho> :)
[09:33] <seb128> didrocks, code diff looks fine, I'm unsure
[09:33] <didrocks> I don't know as well
[09:33] <seb128> jibel, Laney, can you test didrocks change and see if it creates issues for you as well?
[09:33] <didrocks> ok, at least, there is the previous rev which was tested and working
[09:33] <didrocks> not sure about that one, I'll let you test as it's obviously crashing here
[09:34] <seb128> I need to step out again for early lunch today, I'm back around 1pm and can help again then
[09:34] <didrocks> me too
[09:34] <seb128> k, so let's call that an early french lunch
[09:34] <seb128> hopefully Laney is able to test by the time we are back
[09:34] <seb128> bbiab
[09:34] <didrocks> yeah ;)
[09:34] <didrocks> bbl! ++
[09:36] <Laney> yes I'm checking it, no worries
[09:37] <willcooke> train wifi = 15 kbps
[09:38] <willcooke> seb128, I'm seeing g-i-s segfault when I use the quit menu suddenly.  Could be related to slow network
[09:38] <willcooke> Will test more in the office
[09:48] <Mirv> ah, here's where the fix is happening
[10:01] <jibel> seb128, on it. I removed the dbus import to make pep8 happy
[10:02] <Laney> jibel: nein
[10:02] <Laney> they were worried that's required for some reason
[10:02] <Laney> I'll add an assert to shut pyflakes up
[10:11] <jibel> ok
[10:16] <Laney> ok we just did a live and a DM install, no crash
[10:16] <Laney> going to merge/upload
[10:22] <jibel> same here
[10:22] <jibel> no crash
[10:24] <Laney> ♥
[10:24] <Laney> adam's approving it
[10:49] <popey> didrocks: https://twitter.com/itsfoss2/status/989076064734457857
[10:49] <popey> is this known?
[10:58] <willcooke> Works here
[11:08] <willcooke> ah, suggestion on that tweet that it's people upgrading from 16.04
[11:08] <willcooke> which, erm, does not compute
[11:16] <seb128> Laney, jibel, great, thanks
[11:21] <seb128> willcooke, Laney, didrocks, btw I wonder if the fact that we go through that "hackish" reboot of killing xorg and doing a "sudo reboot" could be on of the reason reboot is not reliable, it might be better/resolve those issues once we use the proper logind API (but for .1 at this point)
[11:23] <willcooke> xnox is looking at my test machine right now to see why the live session isnt rebooting
[11:23] <seb128> k, good
[11:23] <seb128> there is an issue there for sure
[11:24] <seb128> but it doesn't help we do things the hackish way, our issue from the morning is that we discovered that the "proper way" has never been working
[11:24] <seb128> fixing the env issues for gsettings/screen reader made it success to contact the session service and start using the "better codepath" which turned out to be buggy
[11:25] <seb128> popey, not a known issue afaik and a tweet is not a proper bug report, we can't do much from that
[11:27] <kenvandine> yeah, the tweet doesn't actually say what doesn't work
[11:28] <seb128> my bet is that it's rather something like https://gitlab.gnome.org/GNOME/gnome-shell/issues/227
[11:29] <ubot5-ng> GNOME bug 227 in gnome-shell "Login fails when preceded by incorrect password" (comments: 9) [Opened]
[11:29] <ubot5`> Error: Gnome bug 227 could not be found
[11:29] <seb128> Trevinho, ^ didn't you teach the bot about those?
[11:29] <seb128> "Login fails when preceded by incorrect password"
[11:32] <didrocks> popey: it works hereon 18.04, lack details? I don't see anything wrong on the screenshot. Snaps app will be transparent, but I think you saw that one on the forum (and due to snapd not having proper theme support)
[11:33] <willcooke> @ tweet - I replied and asked for more info
[11:33] <ubot5-ng> willcooke: Error: "tweet" is not a valid command.
[11:35] <didrocks> keep me posted
[11:39] <seb128> kenvandine, did you get any news from jamesh about those gnome-software segfaults bugs?
[11:39] <kenvandine> no...
[11:40] <seb128> :(
[12:06] <popey> didrocks: seb128 i have just uprgaded a vm from 16.04 to 18.04 and install the theme snap then logged out/in and it works, and the original session works too
[12:06] <seb128> good!
[12:06] <didrocks> phew ;)
[12:15] <willcooke> thanks popey
[12:18] <kenvandine> didrocks, GTK_THEME=Communitheme /snap/bin/gedit
[12:18] <kenvandine> didrocks, seems like i'm just getting Adwaita?
[12:19] <kenvandine> do i have to login with the communitheme session?
[12:21] <didrocks> kenvandine: you have to login with communitheme session
[12:21] <didrocks> it's in a snap path, not a standard one :)
[12:21] <didrocks> as snapd doesn't have theme support for the platform
[12:22] <kenvandine> didrocks, even with the interface connected?
[12:22] <kenvandine> with gtk-common-themes
[12:22] <didrocks> kenvandine: ah, indeed, shouldn't be relevant. hum, I don't know oh you implemented the theme plug, maybe a bug in it?
[12:22] <didrocks> try with another theme shipped by gtk-common-themes, maybe?
[12:23] <kenvandine> other themes work
[12:23] <didrocks> weird, do you have any log/strace ?
[12:23] <didrocks> I don't see why this would be any different
[12:23] <seb128> look if the theme is available under /usr/share/themes/<name> in the snap env?
[12:23] <didrocks> yep
[12:25] <kenvandine> oh, it's working for themes provided by the platform snap :)
[12:25] <kenvandine>     target: $SNAP/share/themes
[12:25] <kenvandine> perhaps the target should be $SNAP/usr/share/themes
[12:25] <didrocks> ah, so not with the ones from gtk-common-themes?
[12:25] <kenvandine> it's in both :)
[12:25] <didrocks> I guess you will remove the ones from the platform snap soon and only rely on gtk-common-themes?
[12:25] <kenvandine> if i choose EvoPop it doesn't work either
[12:26] <didrocks> ok, at least, that explains the difference on behavior :)
[12:26] <kenvandine> didrocks, i won't remove it from gnome-3-26-1604
[12:26] <kenvandine> but maybe 1804
[12:26] <didrocks> yeah
[12:28] <kenvandine> ok, changing the target fixed it
[12:28] <didrocks> ;)
[12:35] <didrocks> kenvandine: do you plan to do a post on community.ubuntu.com once published post-release with some examples on how to install/connect manually until we get autodownload support?
[12:37] <willcooke> didrocks, what's a good screenshot to show off spice vd agent?
[12:37] <kenvandine> didrocks, i'd rather just get the auto-connect ack'd before releasing these to stable
[12:41] <didrocks> kenvandine: yeah, then you only publish the installation instruction
[12:41] <didrocks> willcooke: not sure to get you, spice vdagent is nothing graphical…
[12:41] <didrocks> upstream homepage is https://www.spice-space.org/
[12:43] <willcooke> re: communitheme "bug":  """I used fresh installations in dual boot with Win 10. Installed communitheme snap apps. Restarted and at login when Comunnitheme session is selected, and login is presses, it stucks there."""
[12:44] <seb128> would need to report a bug with the journal log
[12:44] <seb128> it could be https://gitlab.gnome.org/GNOME/gnome-shell/issues/227
[12:44] <ubot5-ng> GNOME bug 227 in gnome-shell "Login fails when preceded by incorrect password" (comments: 9) [Opened]
[12:44] <ubot5`> Error: Gnome bug 227 could not be found
[12:44] <seb128> you can ask if it does it after a first login on reboot
[12:46] <willcooke> seb128, done
[12:59] <sil2100> tkamppeter: hey! Is LP: #1721839 still an issue on bionic?
[12:59] <ubot5`> Launchpad bug 1721839 in systemd (Ubuntu) "[REGRESSION] Services asked for by UDEV do not get triggered" [Low,Confirmed] https://launchpad.net/bugs/1721839
[13:16] <ads20000> kenvandine: I can only see up to 13:00 but on lack of autodownload for the gnome content snap, we could get autoconnect but aiui autodownload still isn't a thing? So people need to know to install the relevant GNOME content snap when they install a GNOME app snap?
[13:16] <ads20000> Since they won't have the GNOME content snap if upgrading from an earlier release?
[13:16] <kenvandine> ads20000, that's for the refresh case
[13:17] <kenvandine> for install it will auto-download
[13:17] <ads20000> Oh nice I didn't know that was a thing
[13:17] <kenvandine> yup
[13:17] <kenvandine> but it doesn't work for refresh
[13:17] <ads20000> I'm guessing the snapd team are on it?
[13:17] <kenvandine> yes
[13:31] <seb128> Laney, thanks for debugging that g-s not starting after a wrong login issue
[13:36] <ads20000> Yes thank you!!! <3
[13:38] <willcooke> anyone got any thunderbolt devices to show bolt doing its thing?
[13:41] <jbicha> willcooke: we didn't land the gnome-control-center GUI yet so there's not a lot to see
[13:42] <jbicha> I think I very briefly see the activity indicator when logging in. I believe my computer support Thunderbolt but I don't have any devices to plug in
[13:42] <jbicha> see also https://christian.kellner.me/2018/04/23/the-state-of-thunderbolt-3-in-fedora-28/
[13:46] <willcooke> thanks jbicha, I'll leave that for now then
[13:49] <seb128> jbicha, the panel is not needed, the important part is that the shell prompt you to auth the device so it can be used
[13:49] <seb128> the panel only let you revisit those permissions later
[13:49] <seb128> which you can do from the cli
[13:51] <Laney> seb128: np, didn't really understand it tho but maybe Ray will get a clue from the log
[13:52] <seb128> Laney, right, he seemed interested so it's good that we provide at least the info he asked for
[13:52] <jbicha> willcooke: feel free to crop https://bicha.net/i/bionic-bolt.png
[13:54] <seb128> jbicha, so you are not getting the auth prompt?
[13:54] <seb128> that's the important part :/
[13:54] <jbicha> seb128: unless you guys want me to go to the store and buy a device…
[13:55] <seb128> jbicha, k, you mean you didn't actual test it with a device, that makes sense :)
[13:55] <seb128> ah you said that earlier :/
[13:55] <seb128> sorry I didn't read/register that part
[13:55] <jbicha> np :)
[14:45] <seb128> hum, we still get some reports of the gnome-menus/trigger loop issue :/
[14:49] <jibel> seb128, bug # ?
[14:49] <seb128> jibel, bug #1766890
[14:49] <ubot5`> bug 1766890 in gnome-menus (Ubuntu) "package gnome-menus 3.13.3-6ubuntu3.1 failed to install/upgrade: triggers looping, abandoned" [Undecided,New] https://launchpad.net/bugs/1766890
[14:51] <seb128> we have some others like bug #1764078 but they seems 17.10 issues
[14:51] <ubot5`> bug 1764078 in gnome-menus (Ubuntu) "package gnome-menus 3.13.3-6ubuntu5 failed to install/upgrade: triggers looping, abandoned" [Undecided,Confirmed] https://launchpad.net/bugs/1764078
[14:51] <seb128> yeah, the other ones in the list are 17.10
[14:53] <jibel> I didn't find a way to reproduce it anymore
[16:28] <seb128> have a nice evening desktopers
[16:29] <Laney> bye seb128!
[16:29] <willcooke> see ya seb128
[16:33] <didrocks> same seb128
[16:43] <Trevinho> Morning
[16:53] <ads20000> I think I just triggered bug 1766137 by logging out, changing the session to Ubuntu with communitheme snap (non-Wayland), then logging in again (without an incorrect password). Idk if that's reproducible though
[16:53] <ubot5`> bug 1766137 in gnome-shell (Ubuntu) "[regression] Password accepted but login fails (blank purple screen and mouse pointer only)" [High,Confirmed] https://launchpad.net/bugs/1766137
[18:04] <kenvandine> jdstrand, did you see the auto-connect request for themes?  https://forum.snapcraft.io/t/auto-connection-of-gtk3-themes-icon-themes-and-sound-themes-interfaces/5118
[18:08] <jdstrand> kenvandine: I did and will circle back around to it. note, there is a one week voting period so it isn't late yet
[18:08] <kenvandine> jdstrand, thx
[18:09] <kenvandine> jdstrand, any way we can fast track that?  i've gotten updates to all the gnome snaps in candidate that add those and it would be nice if users installing those snaps on their shiny new 18.04 install get them connected
[19:26] <jbicha> willcooke: I'm looking at https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Desktop do we still have an issue with the User panel in Settings being slow sometimes?
[19:28] <willcooke> jbicha, lemme check, but I think that's fine now
[19:35] <willcooke> bah, machine test b0rked
[19:35] <willcooke> yeah, I'm sure it's fixed
[19:35] <willcooke> It works on my 17.10 machine, and it didnt used to
[19:35] <willcooke> I think that can be dropped
[19:37] <willcooke> gotta go and check in
[19:37] <willcooke> bbl
[20:47] <jdstrand> kenvandine: done