[04:48] <hikiko> hello
[05:03] <pitti> Good morning
[05:09] <hikiko> good morning pitti
[05:10] <pitti> hey hikiko
[05:33]  * TheMuso -> EOD, later folks.
[05:54] <didrocks> good morning
[06:01] <pitti> bonjour didrocks
[06:05] <didrocks> ça va pitti ?
[06:06] <pitti> didrocks: ça va bien, merci ! j'ai dormi à 6h30, c'est bon !
[06:07] <pitti> "bien" (no?)
[06:07] <pitti> et toi ?
[06:08] <didrocks> "bient", oui :)
[06:08] <didrocks> "bien"*
[06:08] <sarnold> much better than yesterday :)
[06:08] <didrocks> moi, ça va ;)
[06:34] <happyaron> Laney: previously we only have Chinese simplified IME preseeded in the iso, other languages are supported via m17n stuff, ibus-m17n (or we can do the same with fcitx-m17n), but people generally think the m17n IMEs does not work.
[06:35] <happyaron> ah seb is not around
[06:46] <seb128> good morning desktopers
[06:47] <pitti> bonjour seb128
[06:48] <seb128> salut pitti, wie gehts?
[06:48] <pitti> seb128: prima, danke! und Dir?
[06:49] <seb128> pitti, auch gut, danke ;-)
[06:50] <pitti> brb, trying to debug bug 1508075
[07:07] <larsu> bonjour!
[07:08] <didrocks> hey larsu !
[07:08] <larsu> hi didrocks, how goes?
[07:09] <didrocks> larsu: fine! doing some image testing, already spotted 2 bugs :p
[07:10] <didrocks> one being… decoration icons being on the right, ZOMG!
[07:10] <larsu> uh oh
[07:10] <larsu> how can that happen?
[07:11] <didrocks> larsu: ubiquity only mode
[07:12] <didrocks> where it handles window decoration
[07:12] <didrocks> the other one is really weird
[07:12] <didrocks> fresh install, first login
[07:12] <didrocks> open apps -> menus are exported
[07:12] <didrocks> included gtk3 apps
[07:12] <didrocks> but for the terminal!
[07:12] <didrocks> starting it with ctrl + alt + t or the dash
[07:12] <Sweet5hark> moin
[07:13] <larsu> didrocks: it has a "show menubar" key which might be off by default
[07:13] <larsu> moin Sweet5hark
[07:13] <didrocks> larsu: under "general"?
[07:13] <didrocks> (sorry, I was testing the system in French, obviously :p
[07:13] <larsu> didrocks: right click menu I think
[07:14] <larsu> last menu item
[07:14] <didrocks> larsu: it's on here
[07:14]  * larsu thinks didrocks understands french though
[07:14] <larsu> weird
[07:14] <larsu> than that's a different bug :)
[07:14] <didrocks> larsu: and so, I can see the menu bar
[07:14] <didrocks> and it's not exported
[07:14] <larsu> unity gtk module loaded?
[07:15] <didrocks> GTK_MODULES=unity-gtk-module
[07:15] <didrocks> in its env
[07:15] <didrocks> I have the "Terminal" entry exported
[07:16] <larsu> I do as well, until I click "Show Menubar" in the context menu
[07:16] <larsu> but you say this is already on?!
[07:16] <didrocks> yeah
[07:16] <larsu> toggle it!
[07:16] <didrocks> did turn it off
[07:16] <didrocks> then, I only have the "Terminal" entry
[07:16] <didrocks> (and it's exported ofc)
[07:16] <didrocks> but on my main laptop, the option is on
[07:17] <didrocks> and I have Terminal + other menus all exported
[07:17] <didrocks> as I would expect
[07:18] <larsu> hm...
[07:18] <larsu> so you have nothing until you turn that setting off, then you only have "Terminal"
[07:18] <Sweet5hark> seb128, willcooke: so, we found bug 1508177 yesterday from testing the ISO. Opinions? 0-day SRU worthy or wait for upstream 5.0.3 (expected to be tagged upstream this week, released next week)?
[07:19] <larsu> didrocks: what happens when you turn it back on?
[07:19] <didrocks> larsu: let me wrap that up on a bug report
[07:19] <larsu> yeah thanks
[07:19] <larsu> I'll be back in 15
[07:21] <seb128> hey larsu
[07:22] <desrt> good morning desktop
[07:22] <seb128> hey desrt
[07:23] <willcooke> Sweet5hark, so it's being fixed in our packages not upstream?  If so, can the fix go in today?
[07:23] <willcooke> morning all
[07:23] <seb128> Sweet5hark, how different do they look?
[07:23] <Sweet5hark> willcooke: morning.
[07:24]  * willcooke -> school.  brb
[07:25] <didrocks> larsu: bug #1508338
[07:25] <didrocks> hey desrt, willcooke, Sweet5hark
[07:26] <Trevinho> Morning
[07:26] <desrt> forced air > radiators
[07:26] <desrt> seb128, willcooke, didrocks, Sweet5hark, Trevinho, larsu, others: hihi =)
[07:27] <didrocks> hey Trevinho
[07:27]  * desrt enjoys the n*m thing
[07:28] <Sweet5hark> willcooke: I have a fix pushed to my PPA, Its still building. No need to wait for upstream for that -- just that LibreOffice needs to build for ~one  day anyway and the new upstream version is around the corner.
[07:30] <seb128> didrocks, http://people.canonical.com/~seb128/ubiquity.png
[07:30] <seb128> didrocks, lol, ignore that
[07:30] <didrocks> seb128: see :p
[07:30] <didrocks> seb128: I think I found something
[07:30] <seb128> I had the decoration on the left at first, they moved on the right while I was opening the screenshoter
[07:30] <didrocks> seb128: :p
[07:30] <seb128> was it like that in vivid?
[07:31] <didrocks> I don't think it was
[07:31] <seb128> anyone having a vivid iso around to try?
[07:31] <didrocks> seb128: confirmed btw
[07:31] <didrocks> it's when you open another window that they are shifted
[07:31]  * didrocks updates the bug
[07:31] <Sweet5hark> seb128: they look different -- galaxy looks more dated than human, then again human isnt looking like a master piece of modern design anymore these days either, so I dont know how noticable it really is in the end.
[07:32] <seb128> Sweet5hark, screenshots? ;-)
[07:32] <didrocks> iso tracker is buggy :/
[07:33]  * Sweet5hark creates screenies
[07:34] <didrocks> seb128: description updated, feel free to rephrase
[07:34] <seb128> didrocks, unity-settings-daemon is "<defunct>" in the ps list
[07:34] <didrocks> "nice" :/
[07:35] <didrocks> seb128: confirmed
[07:35] <seb128> oh
[07:36] <seb128> journalctl has a u-s-d segfault in libpower.so
[07:36] <seb128> indeed /var/crash has it
[07:36]  * seb128 gets bt
[07:36] <didrocks> ok, retargetting the bug meanwhile
[07:37] <Sweet5hark> seb128: http://people.canonical.com/~bjoern/galaxy.png vs. http://people.canonical.com/~bjoern/human.png
[07:38] <seb128> Sweet5hark, urg!
[07:38] <seb128> yeah, SRU-0 seems like worth it
[07:38] <seb128> willcooke, ^ opinion?
[07:39] <seb128> I would almost argue it's worth a respin :p
[07:39] <seb128> Sweet5hark, note for next cycle, test libreoffice on the iso at beta time
[07:39] <didrocks> seb128: I would argue that, basically, if you select a network from the indicator, you have this
[07:39] <didrocks> or are you on the libreoffice thingy?
[07:39] <seb128> didrocks, my comment to Sweet5hark was about libreoffice, sorry
[07:39] <didrocks> ok ;)
[07:39] <didrocks> that was the next bug I was about to open :p
[07:40] <didrocks> grrrr at that laptop
[07:40] <seb128> we should have done some iso testing in London :-/
[07:40] <didrocks> touch screen keeping giving bad inputs…
[07:40] <didrocks> so hard to test…
[07:40] <didrocks> ok, timezone is whenever is it…
[07:41] <Sweet5hark> seb128: yeah :/
[07:41] <seb128> didrocks, http://paste.ubuntu.com/12884084/
[07:41] <didrocks> hard to say if it's in glib or power plugin without debug symbols
[07:41] <Sweet5hark> seb128: on the upside, I didnt work to get the fix in until 2am yesterday in vain then ...
[07:42] <didrocks> but yeah, it's a signal it doesn't like it seems
[07:43] <seb128> didrocks, it seems similar to bug #1436861 that davmor2 reported previous cycle
[07:43] <seb128> so maybe it was already in vivid
[07:44] <seb128> Sweet5hark, yeah, good work!
[07:45]  * didrocks fights with his screen
[07:45]  * desrt finds the best phone on earth
[07:45]  * desrt discovers that it is not available in canada, nor on the frequencies used by her carrier
[07:45] <desrt> bleh.
[07:45] <didrocks> seb128: so, yeah, confirmed that it always crash after a while
[07:46] <seb128> desrt, what phone is it?
[07:46] <seb128> didrocks,
[07:46] <seb128>         array = 0x0
[07:46] <desrt> moto g 3rd gen dual sim 16gb (xt1550)
[07:46] <seb128>         for (i=0;i<array->len;i++) {
[07:46] <desrt> ie: no more swapping sim cards when i need a data plan in europe
[07:46] <didrocks> seb128: ah, I can see how this can go wrong :p
[07:46] <seb128> of course that doesn't work out well :p
[07:47] <Sweet5hark> seb128: I dont think we would have found this on the beta: FWIW I did see screenshots of LibreOffice on the beta IIRC. But because of tdf#93145, the human theme was _incomplete_ on beta. That was a known issue.
[07:48] <seb128> Sweet5hark, oh, ok :-/
[07:49] <Sweet5hark> seb128: The fix for that was also shipping galaxy, thus adding the missing icons and everything look good -- _except_ on a LibreOffice you only started the first time ever on a virgin image _after_ that fix was in.
[07:50] <Sweet5hark> seb128: so: only really discoverable with testing the final ISO from scratch from what I see. :/
[07:50] <Sweet5hark> grgrggr
[07:51] <seb128> didrocks, if I run u-s-d from vt1 it works, no segfault and decorations back on left :-/
[07:51] <seb128> with DISPLAY=:0
[07:51] <didrocks> will be nice for debugging…
[07:52] <seb128> yeah, and I had a look at that segfault before
[07:52] <seb128> it's not as easy as putting a null check
[07:52] <seb128> the devices array is supposed to never be null
[07:52] <willcooke> seb128, Sweet5hark - If a re-spin is going to happen anyway, let's get it in there.  Otherwise SRU0 will be fine.  Thanks davmor2 for spotting it
[07:53] <larsu> morning seb128 desrt willcooke
[07:53] <larsu> thanks didrocks
[07:53] <seb128> hey larsu
[07:54] <Sweet5hark> willcooke: k.
[07:54] <larsu> desrt: which one is the best one?
[07:54] <desrt> moto g 3rd gen dual sim 16gb (xt1550)
[07:54] <larsu> biggest battery life for ingress?
[07:54] <desrt> ie: no more swapping sim cards when i need a data plan in europe
[07:54] <Sweet5hark> willcooke: keep in mind that the fix is touching the LibreOffice source package, thus 24 hours build time for armhf ...
[07:55] <larsu> sounds appealing
[07:55] <desrt> nah.. it's just a cheap phone with a solid build, 2GB of ram, sdcard slot, quadcore, good camera, etc.
[07:55] <desrt> but the dualsim version is only made for use in india, it seems :(
[07:55] <Sweet5hark> and indeed: kudos to davmor2 for bringing this on the radar ...
[08:00] <willcooke> Sweet5hark, ahhh, arm builds.  Yeah, fair point.  SRU it is
[08:01] <Sweet5hark> desrt: you need to run ingress in the cloud and have the phone only as a client. Everything is going back to 1960ies style big iron mainframes, so why shouldnt you?
[08:03] <Sweet5hark> willcooke: kk, will make a SRU version then and ping seb128 once the ppa build is finished and the fix verified.
[08:03] <willcooke> thx Sweet5hark
[08:04] <Laney> morning!
[08:05] <larsu> hi Laney
[08:05] <pitti> hey Laney, good morning
[08:06] <larsu> oh hi pitti :)
[08:06] <Laney> hey larsu & pitti
[08:06] <Laney> how goes?
[08:06] <pitti> hey larsu!
[08:07] <pitti> Laney: quite fine, thanks; usual release test install/look at bugs mode
[08:07] <pitti> Laney: how is the sprint?
[08:07] <larsu> Laney: good good. Much better than last week ;) how are you?
[08:08] <davmor2> Sweet5hark: nice you got to the bottom of it then \o/
[08:14] <seb128> hey Laney
[08:17] <Laney> pitti: good thanks! heard last night that Ubuntu GNOME doesn't boot though :)
[08:17] <Laney> and there's some polkit thingy which cyphermox is looking at
[08:17] <Laney> larsu: great!
[08:17] <Laney> there's rain today!
[08:17] <seb128> Laney, what's the Ubuntu GNOME issue?
[08:17] <Laney> dunno yet
[08:17] <larsu> finally London looks like London?!
[08:17] <seb128> is that gdm not coming up?
[08:18] <pitti> Laney: I followed up to bug 1508075, I can't reproduce it
[08:18] <Laney> cyphermox made it happen
[08:18] <Laney> maybe he can post steps to the bug
[08:18] <seb128> didrocks, k, I commented some more on the bug
[08:19] <seb128> it looks similar to what mterry debugged back then https://bugzilla.gnome.org/show_bug.cgi?id=673007#c17
[08:19] <seb128> but added back since the change for new upower, http://launchpadlibrarian.net/191328719/unity-settings-daemon_15.04.0%2B15.10.20141030-0ubuntu1_15.04.1%2B15.04.20141127-0ubuntu1.diff.gz
[08:19] <didrocks> seb128: yeah, I saw that
[08:19] <seb128> I can't see what is wrong though, the g_signal_handlers_disconnect_by_data() is still there
[08:19] <seb128> needs debugging from somebody who understands signals&co better than me
[08:20]  * seb128 looks at larsu ;-)
[08:20]  * larsu looks somewhere else
[08:20] <Laney> apparently it is randomly fixed
[08:20] <Laney> awesome
[08:21] <larsu> hm? no need to look at it or are you talking about a different thing?
[08:21] <Laney> oh no, the gnome bug
[08:22] <seb128> larsu, speaking about bug #1508327
[08:22] <seb128> larsu, would welcome help
[08:23] <seb128> larsu, the source is http://bazaar.launchpad.net/~unity-settings-daemon-team/unity-settings-daemon/trunk/view/head:/plugins/power/gsd-power-manager.c
[08:23] <seb128> backtrace https://launchpadlibrarian.net/201298582/Stacktrace.txt
[08:24] <seb128> it's similar to https://bugzilla.gnome.org/show_bug.cgi?id=673007#c17 which mterry fixed and seemed to have come back in 15.04 with the new upower
[08:24] <seb128> http://launchpadlibrarian.net/191328719/unity-settings-daemon_15.04.0%2B15.10.20141030-0ubuntu1_15.04.1%2B15.04.20141127-0ubuntu1.diff.gz was that new upower changeset
[08:24] <larsu> seb128: missing NULL check/
[08:24] <seb128> larsu, ^ summary of the situation
[08:24] <larsu> array = NULL
[08:25] <seb128> larsu, well, it's not that simple, the devices array should never be null
[08:25] <larsu> I bet this function is called after cleanup or something
[08:25] <larsu> which is why the disconnect() thing was needed back then
[08:25] <seb128> back then it was happening because signals were not disconnected when the object was freed
[08:26] <seb128> right
[08:26] <seb128> I just don't see what changed that make the disconnect() not be enoguh
[08:26] <seb128> or what can trigger the callback after the cleanup
[08:28] <larsu> seb128: the disconnect is from the client...
[08:28] <larsu> the connect() to a device
[08:31] <larsu> ya this is wrong
[08:31] <larsu> and again a stupid plugin takes down all of u-s-d
[08:31] <seb128> yeah :-/
[08:33] <larsu> I'll try to reprocude this locally
[08:33] <larsu> but I think I know the patch already
[08:33] <didrocks> I think I have another transparency missing for larsu: http://people.canonical.com/~didrocks/tmp/contextmenu.png (I wonder how we missed it)
[08:33] <larsu> didrocks: → Trevinho
[08:34] <didrocks> Trevinho: ^
[08:34]  * larsu hopes this works
[08:34] <didrocks> I guess there is a bug opened for that? :)
[08:34] <didrocks> larsu: it's only gtk ones, but I guess that's due to the API change, right?
[08:34] <larsu> dunno
[08:34] <Laney> ♥ iso testers
[08:34] <seb128> larsu, right,         g_signal_handlers_disconnect_by_data (manager->priv->up_client, manager) ... the up_client is wrong there, right?
[08:34] <larsu> didrocks: api change? this is just a theme issue, no?
[08:35] <larsu> seb128: no we need that one as well, because we connect to some of up_client's signals, too
[08:35] <didrocks> larsu: yeah, well, behavior change as the previous version did have transparency
[08:35] <larsu> we need an additional one when removing devices
[08:35] <seb128> didrocks, what's the issue on that screenshot?
[08:35] <didrocks> so something broke backward compatibility (as for what happened in the greeter)
[08:35] <didrocks> seb128: look at the corners, they are black
[08:35] <didrocks> not transparent
[08:36] <larsu> didrocks: ah right ... lots of css stuff changes all the time :/
[08:36] <larsu> not considered api sadly
[08:36] <seb128> what corners?
[08:36] <didrocks> should, but you know my opinion on that
[08:36] <seb128> the tooltip you mean?
[08:36] <larsu> didrocks: could be a compiz issue as well
[08:36] <didrocks> seb128: yep
[08:36] <larsu> in which case Trevinho is the *even* better match
[08:36] <seb128> didrocks, that was rounded before?
[08:37] <didrocks> seb128: it's rounded on the corners
[08:37] <Trevinho> larsu: well, it's all related
[08:37] <didrocks> but then, you have black space between the rounded corners and the screen
[08:37] <Trevinho> so... I've the fix for unity, I need the change in GTK in order to be able to get this working
[08:37] <didrocks> look at the gradient dude :p
[08:37] <didrocks> Trevinho: do you have a bug for tracking this?
[08:37] <Trevinho> not sure, larsu?
[08:38] <larsu> Trevinho: ya, somewhere on unity
[08:38] <larsu> Trevinho: are you sure this is the same issue? This has always worked for tooltip-windows, no?
[08:38] <seb128> didrocks, my view is not good enough to see that, to me it just looks like the tooltip is rectangular ;-)
[08:39] <didrocks> seb128: you have an internal rounded corner
[08:39] <didrocks> with gradients
[08:39] <seb128> I believe you, I just can't see it
[08:39] <seb128> as said my view is not good enough for those details
[08:39] <larsu> zoom in!
[08:39] <seb128> doing so!
[08:39] <didrocks> yeah, zooming may help :)
[08:40] <larsu> they should be rounded corners
[08:40] <seb128> now I see it ;-)
[08:40] <seb128> right
[08:40] <larsu> party!
[08:40] <Trevinho> larsu: it used to work, but maybe they've moved the shadow away from the server too
[08:40] <didrocks> ok, opening a bug anyway, Trevinho, don't lose that one (affecting unity and gtk thus)
[08:41] <seb128> does that has something to do with unity?
[08:41] <larsu> compiz
[08:41] <Trevinho> I mean even for overrideRedirect windows
[08:41] <Trevinho> I bet that if we advertise to support _GTK_FRAME_EXTENTS, we'd get that right
[08:42] <desrt> Laney: hey... do you know anything about this empty.mp3 business?
[08:42] <seb128> haha
[08:42] <seb128> "told you so"
[08:43] <desrt> i got a comment from someone who provides nothing more than a theoretical reframing of the problem without telling me anything that actually broke
[08:43] <desrt> a canonical employee, no less
[08:44]  * desrt is not too impressed by that (yet)
[08:44] <didrocks> Trevinho: bug #1508357 just for your pleasure :)
[08:45] <larsu> desrt: is this about 0 byte files again?
[08:45] <desrt> yes
[08:45] <larsu> >(
[08:45] <Laney> desrt: hahahaha
[08:45] <larsu> stop caring
[08:45] <Laney> no I don't know anything about that
[08:45] <Laney> I didn't send him honest
[08:45] <desrt> Michi Henning is complaining that empty.mp3 is no longer an mp3 file
[08:45] <desrt> ...which it wasn't before, either
[08:45] <larsu> ice man!
[08:45] <desrt> ya...
[08:45] <Laney> ice him?
[08:46] <desrt> waiting to hear back on the bug
[08:46] <larsu> no violence, please :P
[08:46] <desrt> i'm getting annoyed....
[08:46] <larsu> desrt: ignore. This is stupid.
[08:46] <Laney> probably some testsuite
[08:46] <larsu> testsuite is stupid, then
[08:46] <Laney> not saying if it is or isn't
[08:46] <Laney> be calm
[08:46] <larsu> I AM CALM
[08:47] <Laney> coffee machine is fixed
[08:47] <larsu> seb128: any idea if this bug can be reproduced in another way?
[08:47] <seb128> at least something works
[08:47] <larsu> Laney: for now...
[08:48] <seb128> larsu, no, I would go for the theorical fix and get that landed and see if it works
[08:48] <didrocks> seb128: +1
[08:48] <didrocks> quite easy to reproduce anyway on the live
[08:49] <seb128> unsure why the plugin is stopped though?
[08:49] <seb128> but that's not new
[08:50] <larsu> I also wonder why we connect to these signals when colplugging
[08:50] <larsu> but not when hot
[08:51] <seb128> buggy maybe?
[08:51] <seb128> what is upstream doing?
[08:52] <larsu> the right thing
[08:53] <larsu> https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-manager.c#n281
[08:53] <seb128> good, let's do that then!
[08:53] <larsu> calls the same function
[08:53] <seb128> we should probably backport some of the work done there next cycle
[08:54] <seb128> though there was quite some refactoring so not to do for this cycle
[08:54] <larsu> it also doesn't disconnect from the signal that I think is causing the issue :/
[08:55] <larsu> seb128: ok let me try fixing this one issue first
[08:55] <larsu> all of this is blind anyway :L/
[08:55] <larsu> :/
[08:56] <seb128> larsu, thanks
[08:56] <willcooke> didrocks, that terminal bug...  seems fine here
[08:57] <didrocks> willcooke: yeah, I couldn't reproduce after another install
[08:57] <willcooke> ahh, kk
[08:57] <didrocks> but the bug is still there, I didn't fake that screenshot :p
[08:57] <larsu> race!
[08:57] <willcooke> :D
[08:58] <didrocks> larsu: well, "session race" even
[08:58] <didrocks> larsu: because I killed all terminal
[08:58] <willcooke> desktoppers:  for what it's worth, this should be a list of things to care about today:  http://pad.ubuntu.com/6aWG0SagNg
[08:58] <didrocks> and retry to start, and in that session at least, this was always the case
[08:58] <willcooke> If it's helpful, please keep it updated, if not, please ignore
[08:59]  * didrocks finishes the non english use cases first
[09:08] <larsu> didrocks: mind trying this patch? https://code.launchpad.net/~larsu/unity-settings-daemon/lp1436861
[09:10] <seb128> larsu, can you mp it so we can put it in a silo?
[09:10] <seb128> would make easier to test and put us closer from a landing
[09:10] <larsu> sure
[09:10] <didrocks> yeah, that would be easier (I'm in a middle of an install with Internet connexion, so won't be able to test before some times)
[09:11] <larsu> like I said, not sure if this even works
[09:11] <didrocks> larsu: you can easily test as well :)
[09:11] <larsu> just the first guess
[09:11] <larsu> theres a couple of other problems in this code
[09:11] <didrocks> just download the iso, start ubiquity
[09:11] <larsu> but I'd need to reproduce myself
[09:11] <didrocks> (ubiquity only mode)
[09:11] <larsu> ah, ok
[09:11] <larsu> in a vm?
[09:11] <didrocks> should be the same, check first
[09:11] <didrocks> you can play like opening text entry from the indicator
[09:12] <didrocks> seb128 confirmed it easily
[09:12] <larsu> ok will do once I'm home (can't download the iso in the cafe I'm at)
[09:12] <larsu> actually let me go there right now :)
[09:12] <larsu> but please test in between if you're doing that anyway right now
[09:12] <larsu> bbiab
[09:13] <didrocks> larsu: I'm afraid I won't be able before leaving for lunch though, but afterwards, should be possible
[09:13]  * didrocks waits on current install to download and finish
[09:14] <seb128> didrocks, is there a way to modify the iso to install the deb before starting ubiquity?
[09:14] <seb128> I couldn't get the issue by restart u-s-d by hand
[09:14] <seb128> so it needs to be the one in place on boot
[09:15] <jibel> didrocks, I couldn't reproduce. ARe you using 32 or 64bit?
[09:15] <didrocks> jibel: u-s-d crash? 64 bits
[09:15] <didrocks> jibel: ubiquity install mode (not live session)
[09:16] <seb128> didrocks, jibel, larsu, the issue was already there in vivid, like a race or depending of memory state so not a surprise it's not happening for everyone/consistently
[09:16] <didrocks> seb128: hum, I guess then stopping at casper bottom, mounting an usb
[09:16] <didrocks> seb128: I don't see better way :/
[09:17] <seb128> didrocks, let me try usb-creator/key with persistant storage
[09:17] <didrocks> maybe cyphermox would have a better clue though, as I guess he's testing also  the ubiquity only mode when making modification
[09:17] <seb128> cyphermox, Laney, ^
[09:17] <cyphermox> moo?
[09:17] <didrocks> seb128: yeah, if that works, would be the easiest, obivously
[09:17] <didrocks> obviously*
[09:18] <seb128> cyphermox, what's the best way to install a test deb on ubiquity install-only mode before it starts?
[09:18] <cyphermox> seb128: add break=casper-bottom to the command-line, chroot in and install the deb
[09:19] <didrocks> I was right \o/
[09:19] <cyphermox> either that or roll your own iso by modifying the squashfs, extracting files over it and re-squashing it, re-doing the iso
[09:19] <cyphermox> why does it need to be in ubiquity-only?
[09:20] <didrocks> cyphermox: it's the only way we found to crash u-s-d
[09:20]  * didrocks goes for an early run, just updated the iso tracker with use cases I tested
[09:20] <cyphermox> if it crashes in ubiquity-only it should crash as much in the live session -- ubiquity-only just has less crap around it, because it doesn't start the session completely.
[09:21] <didrocks> cyphermox: well, maybe this "less crap" is what results in u-s-d crashing
[09:21] <pitti> cyphermox: you are still talking about the polkit issue?
[09:21] <pitti> cyphermox: can you reproduce it?
[09:21] <cyphermox> in other words, my worry is just that if you're trying to fix a bug that was found in the session, yet you test your bug/fix in the ubiquity-only session, you might not hit quite the same thing, but you'd know better, depedning on the bug.
[09:21] <cyphermox> didrocks: exactly
[09:22] <didrocks> cyphermox: but happy if you can reproduce it in a live session, we couldn't, please check the bug report :)
[09:22] <cyphermox> pitti: no, I think it's a different thing they were talking about
[09:22] <cyphermox> pitti: I added some attachments, I still don't know why it fails/freezes/times out
[09:22] <seb128> cyphermox, the crash happens when unloading u-s-d plugins, so maybe ubiquity has less plugins active that live session
[09:22] <cyphermox> certainly doesn't look to be in ubiquity anyway
[09:22] <cyphermox> seb128: yeah
[09:22] <didrocks> yeah, bug #1508327
[09:23] <didrocks> pitti: if you are curious about what we are talking about ^
[09:23] <didrocks> ok, really going now, bbl!
[09:23] <seb128> didrocks, later!
[09:23] <pitti> cyphermox: right, the ubiquity exception is just a followup and uninteresting
[09:23] <pitti> didrocks: bien courier !
[09:23] <cyphermox> pitti: yes
[09:23] <cyphermox> pitti: but from the strace and dbus monitor logs there should be something to find in there
[09:23] <didrocks> pitti: seb128: merci !
[09:24] <cyphermox> pitti: fwiw it was about 4 unsuccessful runs of ubiquity, one after the other. and I had booted in EFI (since it won't make a difference which firmware anyway)
[09:25] <pitti> cyphermox: wow, ok; I tried on three different platforms (bios laptop, efi laptop, qemu)
[09:26] <cyphermox> pitti: is udisks2-inhibit likely to break stuff?
[09:26] <cyphermox> or to be breaking things in systemd land or whatnot?
[09:27] <pitti> cyphermox: ah, good call; possibly, as that pkills polkit
[09:27] <cyphermox> yes
[09:28] <pitti> cyphermox: so if it kills it while a request is pending, that might lead to trouble indeed; but so would restarting
[09:28] <pitti> cyphermox: that script is ancient already, though; curious that it only pops up now
[09:29] <cyphermox> yes
[09:29] <pitti> cyphermox: if you can reproduce it, can you check whether commenting out all the magic and just doing the "$@" helps?
[09:29] <cyphermox> which is why I don't see why it would be ubiquity that is at fault, or even that udisks2 script
[09:30] <pitti> SIGHUP indeed restarts it, it's not just a "reload your rules, will you"
[09:30] <cyphermox> well, we do need udisks2 to be inhibited, otherwise bad things might happen
[09:30] <pitti> cyphermox: changed timing somehwere -- it's a race
[09:30] <pitti> cyphermox: yes, I know; just seeing if that fixes the polkit issue
[09:31]  * pitti thinks how else to inhibit it
[09:31] <pitti> when I do that for other cases, I SIGSTOP gvfs-udisks2-volume-monitor in the user session
[09:31] <pitti> but that would e. g. not work for KDE
[09:32] <pitti> cyphermox: let me think about this for a bit; in the meantime, if you could confirm that this is it, that'd be great
[09:34] <cyphermox> why is it that polkit doesn't simply handle HUP?
[09:37] <pitti> cyphermox: there's normally no need to, it inotifys its policy dirs
[09:38] <pitti> cyphermox: but that won't work for udisks2-inhibit as that does a tmpfs bind mount over the real policy dir
[09:38] <pitti> to avoid changing anything on disk
[09:44] <seb128> larsu, didrocks ok, I can reproduce easily enough on my desktop env now
[09:44] <seb128> going to make easier to test
[09:45] <seb128> larsu, didrocks, basically that do it for me
[09:45] <seb128> - start u-s-d under valgrind
[09:45] <seb128> - unplug power cord from laptop
[09:45] <seb128> - gsettings set org.gnome.settings-daemon.plugins.power active false
[09:45] <seb128> valgrind is not needed but it slows down things enough that it's more easy to hit
[09:45] <seb128> I can hit it without it as well
[09:46] <seb128> basically mix power plug/unplug events with power plugin loading/unloading
[09:46] <seb128> I tick it in dconf-editor
[09:48] <seb128> sorry, better steps
[09:48] <seb128> $ /usr/lib/unity-settings-daemon/unity-settings-daemon
[09:48] <seb128> - unplug power cord
[09:49] <seb128> - disable active key
[09:49] <seb128> - then plug power cord back
[09:49] <seb128> -> segfault
[09:49] <seb128> every time ;-)
[09:49] <seb128> larsu, getting your branch now
[09:50] <cyphermox> pitti: could we not just kill udisks (or you know, stop it via systemd) and then things would work?
[09:54] <pitti> cyphermox: no, it'd just come back via dbus activation, and is likely to cause simlar trouble -- i. e. timeout in things which connected to it
[09:54] <cyphermox> pitti: it's not needed in the install AFAIK
[09:54] <pitti> cyphermox: the life session surely talks to it
[09:54] <cyphermox> well, aside from mounting other things
[09:54] <cyphermox> sure
[09:55] <cyphermox> meh
[09:55] <pitti> the thing that really causes the automounting is nautilus these days, via gvfs
[09:55] <cyphermox> the right answer is for polkit to HUP the right way
[09:55] <cyphermox> or USR1 the right way
[09:55] <pitti> and some desktop-ish counterparts
[09:56] <pitti> cyphermox: there's one thing to try -- instead of pkill -HUP you could try "systemctl try-restart polkitd.service"
[09:56] <pitti> to restart it right away and  not wait on dbus activation
[09:57]  * pitti writes that to the bug as well
[09:57] <larsu> seb128: cool thanks
[09:58] <seb128> larsu, let me know if you can reproduce using those steps?
[09:58] <larsu> seb128: fighting with virtmanager right now, but yes :)
[09:59] <seb128> larsu, you should be able to reproduce on your normal system with the steps I described
[09:59] <cyphermox> pitti: restarting it in any will just trigger the same race elsewhere
[09:59] <seb128> so no need of vm
[09:59] <cyphermox> pitti: but I'll reboot to an iso once more to try
[09:59] <pitti> cyphermox: I had something simlilar in policykit-1.postinst, where restarting worked much better than just killing
[10:00] <pitti> cyphermox: so try the restart thing first, and then the "essentially disable inhibition"
[10:00] <seb128> larsu, you worked on an outdated checkout though, I had to disable 2 plugins to test your fix because u-s-d was failing to start on missing gsettings key
[10:01] <pitti> cyphermox: the fact that you got these traces actually shows that it was *not* restarted -- otherwise the initial strace (with SIGHUP) would have been overwritten with the new one from the restart
[10:15] <larsu> seb128: argh how did this happen?!
[10:16] <seb128> larsu, the fix seems to work, can you commit on top of trunk and mp it so I can put it in a silo? we want to land it for iso respin
[10:21] <cyphermox> pitti: it doesn't look like systemd is always successful at starting polkit
[10:21] <cyphermox> sometimes it works, but sometimes you get the logs from systemd saying it's starting, yet no polkit binary running
[10:21] <pitti> cyphermox: does it attempt to? when I pkill it on my normal system, it always comes back immediately (check journalctl -f)
[10:22] <pitti> cyphermox: right, starting is the beginning, "started" is success
[10:23] <pitti> the restart in https://launchpadlibrarian.net/221777296/UbiquitySyslog.txt comes way after the timeouts
[10:28] <Laney> Oct 20 14:21:06 ubuntu dbus[1414]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkitd.service'
[10:29] <Laney> Oct 20 14:21:06 ubuntu systemd[1]: Started Authenticate and Authorize Users to Run Privileged Tasks.
[10:29] <Laney> Oct 20 14:21:06 ubuntu gnome-session[1855]: PolicyKit daemon disconnected from the bus.
[10:29] <Laney> Oct 20 14:21:06 ubuntu gnome-session[1855]: We are no longer a registered authentication agent.
[10:29] <Laney> is it this?
[10:31] <Laney> mmm
[10:32] <Laney> pitti: I just did "sudo /usr/lib/udisks2/udisks2-inhibit ls"
[10:32] <Laney> and now NM is broken
[10:32] <Laney> sorry for poking fingers in the pie if this is unhelpful
[10:33] <pitti> Laney: NM is broken how?
[10:34] <pitti> ah, "nmcli con"
[10:34] <Sweet5hark> phew, my fix into the blind yesterday at 2:00am worked.
[10:34] <Laney> ya
[10:34] <pitti> Laney: right, if one kills polkitd often enough, you hit the "respawning too fast" thing
[10:34] <Laney> it seems to have come up again now
[10:34] <pitti> and pidof polkitd is empty
[10:35] <pitti> Laney: anyway, with killing it we always have the chance of interrupting a pending call, so I'm looking for ways to avoid it
[10:36] <pitti> I have about three ideas which I need to test
[10:37] <seb128> larsu, ?:
[10:38] <seb128> larsu, is we want to respin isos we need to get going, can you do a mp or should I do it?
[10:43] <larsu> seb128: sorry!
[10:43] <larsu> seb128: doing it now (had irc in bg)
[10:44] <seb128> larsu, thanks
[10:45] <Trevinho> larsu: even creating rgba visuals in gtk, the tooltip bg is still dark, that's weird
[10:46] <larsu> Trevinho: ya... I had feared this would be the case
[10:46] <Trevinho> compiz/unity doesn't add anything different...
[10:46] <larsu> Trevinho: theme?
[10:46] <Trevinho> maybe something with the theme?
[10:46] <Trevinho> eh, in fact..
[10:46] <seb128> the theme works fine under gnome-shell
[10:46] <seb128> the tooltips are round
[10:47] <Trevinho> I've been playing a little with it, but I don't see the
[10:47] <Trevinho> ok... then it's something else
[10:47] <Trevinho> let me check inner gtk better
[10:49] <larsu> seb128: pushed it
[10:49] <seb128> larsu, danke, did you mp it as well?
[10:49] <larsu> seb128: same mp
[10:49] <seb128> there was no mp before
[10:49] <larsu> seb128: I pushed over the same branch in fact
[10:49] <larsu> seb128: https://code.launchpad.net/~larsu/unity-settings-daemon/lp1436861/+merge/275149
[10:50] <seb128> oh
[10:50] <seb128> great
[10:50] <larsu> didn't I link this before?
[10:50] <seb128> larsu, thanks!
[10:50] <larsu> you asked me to make one, so I did :)
[10:50] <seb128> I might have overlooked it
[10:50] <seb128> channel was busy
[10:50] <larsu> ya
[10:50] <larsu> I might have forgot too
[10:50] <larsu> Trevinho: tooltips do use gtkwindow, but they (obviously) sidestep all of the csd magic
[10:51] <larsu> Trevinho: is compiz seeing this as an argb window?
[10:51] <Trevinho> larsu: I don't think so, let me check
[10:51] <larsu> weird
[10:54] <Trevinho> ouch, I've to recompile the whole unity -_-, cmon ccache, work!
[10:55] <larsu> don't change CFLAGS ;)
[10:55] <Trevinho> no, I didn't... it's just that sometimes cmake decides that it's the case to rebuild the world
[10:57] <Trevinho> larsu: not ARGB for compiz, in fact it isn't.
[10:57] <Trevinho> larsu: I'm wondering which part of gtk doing thsi I missed, I think it was set just once
[10:58] <larsu> Trevinho: let me check
[11:00] <larsu> Trevinho: wow it really ties all of this to the shadow
[11:01] <Trevinho> larsu: yeah, but for some reason if I force to set the rgba visual in gtk_window_set_screen, nothing changes anyway
[11:05] <larsu> Trevinho: are you sure this is called for new windowx?
[11:05] <larsu> probably...
[11:06] <Trevinho> weird, even forcing this inside gtktooltip... same story
[11:12] <Trevinho> larsu: ok got it
[11:13] <larsu> Trevinho: what is it?
[11:14] <Trevinho> larsu: we need to change this inside gtktooltip...
[11:15] <larsu> what exactly?
[11:17] <Trevinho> larsu: I need to set the rgba visual inside gtk_tooltip_show_tooltip... not only at first call unfortunately
[11:18] <larsu> hm good to know that this works, but it sounds wrong...
[11:18] <Trevinho> larsu: yes, I agree
[11:20] <Trevinho> larsu: doing it when assigning tooltip->current_window works, but I agree this should be probably at higher level
[11:21] <Trevinho> err, at lower level.
[11:21] <Trevinho> do you have anything in mind?
[11:22] <larsu> I wonder (a) how this worked before
[11:23] <larsu> and (b) why it works in shell
[11:23] <larsu> don't have anything specific in mind yet, no
[11:23] <Trevinho> ah, wait maybe I've found something else
[11:25] <Trevinho> nope..
[11:25] <Trevinho> tooltip calls _gtk_window_request_csd, but this shouldn't be an issue
[11:28] <didrocks> larsu: seb128: I wonder if that worth a respin (the u-s-d crash), it's quite noticeable if you get it crash and not really good for a "quality" sense
[11:29] <larsu> +1
[11:29] <larsu> Trevinho: gtktooltip can use the parent window to draw...
[11:30] <larsu> Trevinho: which doesn't have a rgba visual set on unity because ... well you know :P
[11:30] <larsu> Trevinho: works on shell because that has rgba windows
[11:30] <Trevinho> no, I'm using the branch where the parent window has the rgba set
[11:30] <Trevinho> headerbar is fine, tooltip no
[11:30] <larsu> Trevinho: are you forcing a new window?
[11:31] <Trevinho> nope, I'm testing the standard case for now
[11:31]  * larsu liked that theory
[11:31] <larsu> too bad :)
[11:31] <Trevinho> Well, the parent window has rgba set... But it shouldn't matter actually as the visual is set per window, independently from the parent
[11:32] <larsu> hm, indeeed
[11:33] <seb128> didrocks, yeah, debs are in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-018/+packages
[11:33] <seb128> I'm trying those but I get some issues in my test user session
[11:33] <seb128> like u-s-d a bit slow to start
[11:34] <seb128> but seems like it's the case after downgrading as well
[11:34] <seb128> so was probably be there
[11:34] <seb128> other testers would be welcome
[11:36] <larsu> Trevinho: dude, this totally works for me
[11:36] <seb128> Trevinho, andyrock, there is an issue with unity grabs, when logging back from the greeter after an user switch, every 3 or 4 times mouse left click doesn't work anymore on unity elements (launcher, indicators)
[11:36]  * larsu should compile before reading code
[11:36] <larsu> argh
[11:37] <seb128> Trevinho, andyrock, doing a screen lock/unlock fixes it
[11:37] <Trevinho> larsu: so... everything is due to create_decoration in gtkwindow
[11:37] <Trevinho> larsu: by ensuring that gtk_window_enable_csd is called in unity, but that priv->use_client_shadow is sitll false, it works
[11:37] <Trevinho> and it covers both the case of the headerbar and of the tooltiops
[11:38] <andyrock> good morning all
[11:38] <seb128> hey andyrock
[11:38] <larsu> hi andyrock
[11:38] <andyrock> seb128: just on wili?
[11:38] <andyrock> *wily?
[11:38] <Trevinho> At this point this covers any issue we have, but..... We'd need unity fix and to introduce _UNITY_GTK_BORDER_RADIUS, which I don't know how to fill
[11:38] <seb128> andyrock, yes, it started doing that quite recently
[11:39] <andyrock> let me check, just need 4 minutes to wash the dishes :D
[11:39] <larsu> Trevinho: right - this was clear though, wasn't it?
[11:39] <seb128> didrocks, larsu, k, I'm landing the u-s-d fix, let's see if it makes into a respin
[11:39] <larsu> Trevinho: I quickly tested by enabling rgba for everything and it works like a charm
[11:39] <seb128> then going for lunch
[11:40] <larsu> seb128: thanks!
[11:40] <larsu> seb128: enjoy ;)
[11:40] <seb128> danke
[11:40] <didrocks> seb128: enjoy! I'm doing a test here as well, just in case
[11:41] <seb128> didrocks, thanks
[11:41] <didrocks> Laney: would like to have your opinion if a respin for the u-s-d crash is possible ^
[11:41] <didrocks> (bad to see at first install time decoration controls jumping randomly from left to right)
[11:43] <andyrock> seb128 do you lock the screen before switching account?
[11:43] <Laney> didrocks: definitely not for it especially
[11:43] <Trevinho> larsu: yeah, it was, but for some reason I thought I had enabled this for every window, while it wasn't the case
[11:43] <Laney> didrocks: but if we do one already
[11:43] <Laney> then yes
[11:43] <seb128> andyrock, no, just use indicator-session and pick another user
[11:43] <larsu> Trevinho: ah goit it
[11:44] <didrocks> Laney: ok, got it, still think it's a bad first noticeable user experience, but I did what I could… :p
[11:46] <Trevinho> larsu: so what's the plan? Do we fix this alltogheter?
[11:46] <Trevinho> Or just for tooltips in wily
[11:47] <larsu> Trevinho: for wily, just for tooltips. Too late for bigger chances
[11:49] <Laney> didrocks: maybe but it doesn't happen for everyone all the time, so not worth the effort of a respin just for this
[11:49] <Laney> anyway we get one anyway for udisks so taking this
[11:50] <pitti> larsu: for the future and https://launchpadlibrarian.net/221863227/unity-settings-daemon_15.04.1%2B15.10.20151012-0ubuntu1_15.04.1%2B15.10.20151021-0ubuntu1.diff.gz
[11:51] <pitti> larsu: the wily fix LGTM, but wouldn't it be more robust to use g_ptr_array_new_with_free_func() for these things, and use a custom free func which disconnects signals and free()s?
[11:51] <larsu> pitti: very nice catch ;) it's what I had before, but you cannot pass user_data into the free func
[11:52] <larsu> pitti: and we need user data becasue that's what we disconnect by
[11:52] <pitti> larsu: ewww? I thought these existed for pretty much everything :/
[11:52] <pitti> larsu: so, nevermind then, I was just wondering as remembering to do the disconnect everytime you unref sounds brittle
[11:52] <larsu> pitti: free funcs are g_free() etc ... they don't carry user data
[11:52] <larsu> pitti: yeah it does indeed.
[11:52] <larsu> not happy about this either
[11:53] <pitti> larsu: yes, the free func certainly doesn't, but I thought you'd just need the actual object for disconnecting
[11:53] <pitti> +                g_signal_handlers_disconnect_by_data (g_ptr_array_index (devices, i), manager);
[11:53] <larsu> right, the "manager" is the culprit
[11:53] <pitti> larsu: i. e. the user data you need is the "manager", and there is no ->my_manager field in the device object?
[11:54] <larsu> pitti: no, the manager is from g-s-d and the device object comes from upower
[11:54] <pitti> often (seen in udisks a lot) the objects have a back ref to their manager object
[11:54] <pitti> larsu: ack, thanks; so, "eww"..
[11:54] <larsu> oh wait... maybe I misread that
[11:54] <pitti> this just sounds unsatisfactory
[11:55]  * larsu checks and finds out he was correct :/
[11:55] <larsu> +1 on pitti's ewwwwwww
[11:55] <pitti> larsu: worst thing, poke it in with g_object_set_data("manager", manager)?
[11:56] <larsu> yeah this is what I pondered
[11:56] <larsu> but didn't in the end because I thought it wasn't worth it
[11:56] <larsu> ref cycles and all
[11:56] <larsu> and when not reffing we have the same problem again:
[11:56] <larsu> we need to clean the manager off the device on exit
[12:16] <attente> good morning
[12:16] <desrt> hi attente
[12:17] <attente> hi desrt
[12:17] <desrt> how's the weather in toronto?
[12:17] <desrt> stopped snowing, i hope :)
[12:18] <larsu> hi attente
[12:18] <attente> it snowed while we were in london apparently
[12:18] <attente> hi larsu
[12:18] <Laney> how's living under the new regime?
[12:18]  * desrt ponders lunch
[12:19] <desrt> Laney: meet the new boss.... same as the old boss...
[12:19] <attente> something like that. we'll have to see...
[12:29] <andyrock> seb128: can you open a bug about that regression?
[12:29] <andyrock> i'm not yet able to reproduce it
[12:29] <andyrock> but I'm on it
[12:30] <andyrock> I need to move to university
[12:30] <andyrock> but i'll keep working from there
[13:36] <Trevinho> seb128: https://code.launchpad.net/~3v1n0/gtk/unity-rgba-tooltips/+merge/275187
[13:37] <seb128> Trevinho, can you add some patch headers on why that's needed/bug reference?
[13:37] <Trevinho> seb128: yeah I wanted to... Then i forgot :)
[13:38] <seb128> Trevinho, also why do we need that? is that temporary until a proper fix is made?
[13:39]  * Laney screams
[13:39]  * didrocks doesn't hear anything
[13:39] <didrocks> should be silent screaming…
[13:40] <seb128> who had the left click not working bug while we were in London?
[13:40] <Laney> https://en.wikipedia.org/wiki/The_Scream#/media/File:The_Scream.jpg
[13:40] <seb128> or was it pitti?
[13:40] <Trevinho> seb128: is there
[13:40] <pitti> seb128: on the unity panel after user switching? me, yes
[13:40] <didrocks> Laney: I hate that painting btw :p
[13:41] <seb128> pitti, right, I had it several times, it's all unity elements and ctrl-alt-l->unlock fixes it ... did you open a bug?
[13:41] <Trevinho> seb128: yes, it's temporary till we add better unity gtk integration.... The unity part is done (I've done it during last day of the sprint), but the gtk one is missing, and I'd love to get larsu involved as I can't get proper radius from windows :P
[13:43] <pitti> seb128: no, I didn't; shall I?
[13:44] <seb128> pitti, I'm looking if there is one, if there are none I can file one
[13:44] <seb128> I hit it regularly when doing user switching
[13:44] <seb128> Trevinho, can you link the branch to the bug?
[13:45] <Trevinho> wasn't linked? bzr commit fail!
[13:45] <pitti> seb128: I tried to switch back and forth a few times, doesn't reproduce that easily
[13:45] <seb128> Trevinho, did you --fixes lp:<...>?
[13:45] <seb128> pitti, I just got it 3 times since yesterday using indicator session to switch users
[13:45] <Trevinho> seb128: yeah, trhough qcommit...
[13:46] <Trevinho> but since I uncommited once maybe it didn't keep that
[13:46] <Trevinho> (it generally does it=
[13:46] <Trevinho> done btw
[13:46] <seb128> Trevinho, can you write a bit more details in the bug? I'm unsure what that has to do with csd
[13:46] <seb128> or maybe larsu can review since he understands what's going on better
[13:56] <Trevinho> seb128: added the comment
[13:56] <seb128> Trevinho, thanks
[14:36] <seb128> Laney, seems like we could remove webbrowser-app from the iso, but I guess a bit late to do that for wily
[14:37]  * willcooke is back.  
[14:37] <willcooke> Anything on fire?
[14:38] <seb128> no
[14:39] <seb128> but seems like we ship webbrowser-app and some other packages from that stack on the iso for no good reason
[14:39] <seb128> seems a bit late for wily though
[14:39] <willcooke> don't the web apps use it?  Or perhaps they were *going* to, but dont
[14:39] <seb128> that was needed for webapps but was not killed when the firefox extension was removed
[14:39] <seb128> they do
[14:39] <seb128> but we install none
[14:39] <seb128> and installing one would pull that in through depends
[14:40] <seb128> so no point having the support and nothing usin git
[14:40] <seb128> using it
[14:40] <Laney> o hwell
[14:40] <Laney> commit it for x
[14:40] <willcooke> ack
[14:40] <seb128> leads to that not-so-icon https://launchpadlibrarian.net/221179905/dash.png
[14:40] <seb128> and some mb of iso space wasted
[14:41] <seb128> also can confuse users to see another webbrowser listed, which is not really ready for desktop usage
[14:41]  * seb128 is a bit annoyed to not have raised that during the sprint
[14:41] <seb128> oh well
[14:41] <seb128> room for improvement for the LTS ;-)
[14:43] <ogra_> well, just drop firefox :P
[14:44]  * willcooke can see the news article now....
[14:44] <ogra_> :D
[14:44] <willcooke> Ubuntu developer ogra_ clearly states that Firefox will be dropped from the next LTS
[14:44] <willcooke> sorry, Mr Ogra
[14:44] <ogra_> we shoudl rename the app to webbrowser-NIH ;)
[14:44] <willcooke> :D:D:D
[14:56] <jcastro> willcooke: mind if I add the controller support to the desktop section of the release notes?
[14:56] <willcooke> jcastro, oh cool, thanks.  I was going to do it once I got the email that the fix had been released, so I wonder if my filters have eaten it
[15:30] <seb128> Laney, do you know when we get respinned isos?
[15:30] <seb128> just rsynced but seems like I got the one from yesterday
[15:32] <Laney> coming soon
[15:33] <seb128> k
[15:33] <Laney> like this cycle
[15:33] <seb128> larsu, if you have any opinion on the tooltip hack can you comment on the mr?
[15:33] <seb128> larsu, also unsure what's your todolist but we might want to start looking at gtk 3.18 so it's ready for the start of next cycle ;-)
[15:53]  * Trevinho leaves for a bit, back later
[16:06] <Sweet5hark> seb128: http://people.canonical.com/~bjoern/wily/5.0.2/libreoffice-l10n_5.0.2-0ubuntu2_source.changes and http://people.canonical.com/~bjoern/wily/5.0.2/libreoffice_5.0.2-0ubuntu2_source.changes for bug 1508177 SRU.
[16:06] <seb128> Sweet5hark, thanks
[16:06] <Sweet5hark> seb128: the debdiff is at http://people.canonical.com/~bjoern/wily/5.0.2/ubuntu2.diff for your convenience.
[16:07] <larsu> seb128: hm did I miss that fly by?
[16:07] <seb128> larsu, https://code.launchpad.net/~3v1n0/gtk/unity-rgba-tooltips/+merge/275187
[16:08] <seb128> larsu, I don't understand enough about the issue to say if that's a workaround we want
[16:08] <larsu> seb128: ya, this is a good workaround
[16:09]  * larsu approves
[16:09] <seb128> k, thanks
[16:09] <larsu> can't top approve
[16:09] <seb128> I can, doing that
[16:23] <andyrock> pitti seb128 I tried to reproduce the regression
[16:23] <andyrock> but it does not happen here
[16:24] <andyrock> can you reproduce all the time
[16:24] <andyrock> ?
[16:24] <seb128> no
[16:24] <andyrock> I'm on 15.04 but with unity/compiz/nux from wily
[16:24] <seb128> but I got it 3 times in a week
[16:24] <seb128> and when it happens only the unity elements (launcher, panel) don't react to click
[16:25] <andyrock> mmm
[16:25] <seb128> when I logged back it  I saw an indicator like pressed for a second
[16:25] <seb128> doing a screen lock/unlock fixes it
[16:25] <andyrock> let me think
[16:25] <seb128> so I guess there is a grab something in unity
[16:25] <seb128> I usually see it when I use indicator-session, pick guest/another user, log out and log back in to my user
[16:25] <andyrock> well if there was a grab you could not use any element in the screen
[16:26] <seb128> sorry was about to go for sport but I can provide more details tomorrow
[16:26] <seb128> right
[16:26] <seb128> I said a grab in unity
[16:26] <seb128> not a x grab
[16:26] <seb128> dunno what can block click events for unity though
[16:27] <andyrock> yeah it can be a regression in nux
[16:55] <didrocks> good evening everyone!
[16:55] <andyrock> g' evening didrocks
[16:55] <didrocks> thanks andyrock ;)
[17:14] <Sweet5hark> and me is eod.
[18:12] <willcooke> g'night all
[18:12] <willcooke> Laney, before I go you need guys need anything?
[18:13]  * davmor2 tries to not find a LO issue again so Sweet5hark can sleep and everything :)
[18:13] <willcooke> :D
[18:23] <willcooke> right ho, off now.