[06:03] <pitti> Good morning
[07:35] <mlankhorst> Hello, world!\n
[07:46] <darkxst> seb128, hey!
[07:47] <seb128> good morning desktopers
[07:47]  * seb128 thinks it's monday morning and when IRC start blinking in the minute you run it, that can't be good
[07:47] <seb128> hey darkxst
[07:48]  * darkxst just got internet again! sorry :)
[07:48] <seb128> no worry ;-)
[07:49] <cking> cyphermox, ping
[07:50] <darkxst> seb128, so what will happen with the gnome-desktop transition for U?
[07:50] <seb128> cking, it's like 3am on a sunday night for him, you might want to let some context for later
[07:51] <seb128> darkxst, dunno, we didn't discuss U and what we do with GNOME components yet
[07:51] <cking> i'll pop him an email
[07:51] <mvo> seb128: I know its monday morning when I feel extraordinary sleepy ;)
[07:51] <seb128> we said we would discuss it tomorrow at the meeting
[07:51] <seb128> mvo, good morning ;-)
[07:51] <mvo> seb128: and GOOD MORNING (in best jdub voice)
[07:51] <darkxst> seb128, when is the meeting?
[07:51] <seb128> mvo, you forgot the freedom lover part!
[07:51] <seb128> darkxst, weekly meeting, 15:30utc
[07:52] <mvo> seb128: haha, very true
[07:52] <seb128> but it's the weekly team roundtable, I expect us to discuss a bit what we do but we are probably going to continue discussions on lists after that
[07:53] <darkxst> seb128, right thats pretty impossible for me to attend..
[07:53] <darkxst> but I am sure you know by now, how much we are blocked by the old gnome-desktop!
[07:56] <darkxst> then there are the CSD issues as well I guess
[07:57] <seb128> we know about gnome-desktop
[07:57] <seb128> we can probably go ahead with that transition in U
[07:57] <seb128> but I think we are going to clean out some bugs through SRUs first and do Debian merges
[07:58] <seb128> e.g usual start of the cycle tiding up work
[07:58] <seb128> before starting with new transitions/changes
[07:58]  * darkxst notices cogl transition has already started ;) 
[07:58] <seb128> what are the issue with CSD (out of the fact that they don't work out of gnome-shell, which is an issue but one for everybody but you)
[07:59] <seb128> yeah, we autosynced with Debian
[07:59] <seb128> which is sort of my point
[07:59] <darkxst> seb128, exactly that, most 3.12 apps are using CSD's now
[07:59] <seb128> we already have transitions started through the Debian syncing
[07:59] <darkxst> part of it can be solved by making Unity ignore the WM hints
[07:59] <seb128> so we need to clear those out before adding new ones
[07:59] <seb128> the issue is not specific to Unity
[08:00] <seb128> try running one of those under xfce
[08:01] <darkxst> then xfce should ignore the hints as well I Guess, either way upstream won't take patches to disable via themeing in GTK
[08:03] <seb128> CSD or "let's make things incompatible with everything existing and give the finger to everyone telling them to go change their code" :/
[08:04] <darkxst> seb128, that said I did semi-play with this and have some half-baked patches, if you really want to disable CSD's from gtk and carry as distro patches
[08:04] <Laney> hallo
[08:04] <seb128> Laney, hey, how are you?
[08:05] <darkxst> hey Laney
[08:05] <seb128> darkxst, we didn't define what to do yet, but yeah we are going to need to decide on something
[08:05] <seb128> I think we are going to end up patching the default apps to not use CSD at least under Unity
[08:05] <seb128> same we patched them to have menus
[08:05] <seb128> that's the only way to have them not regress in user experience
[08:06] <darkxst> seb128, not sure how you guys can criticise gnome for going off in there own direction, which is exactly what you guys are doing! just a slightly different direction
[08:06] <darkxst> seb128, you can't patch the apps, you either need to patch GTK or WM
[08:07] <seb128> darkxst, we can patch the apps to not use a gtkheaderbar
[08:07] <darkxst> Everything is using GTKHeaderBar now
[08:08] <darkxst> you would be better off patching GTKHeaderBar to not display window controls
[08:08] <seb128> darkxst, I don't criticise GNOME for going their own direction, I criticize app writers to not think about their users on non gnome-shell desktops
[08:08] <seb128> darkxst, in their defence they were used to have GTK working on any desktop without effort
[08:08] <seb128> which is not true anymore, and most app writer didn't notice
[08:09] <darkxst> GNOME is a desktop! and only the official GNOME apps are using CSD's?
[08:10] <seb128> official ?
[08:10] <seb128> like gthumb
[08:10] <seb128> or d-feet ?
[08:10] <seb128> I'm also unsure that e.g file-roller is "an official GNOME app"
[08:10] <seb128> it's a standalone app and it probably has as many users out of GNOME desktop that it has there
[08:11] <seb128> it's just that GNOME like to call everything hosted on their git as "part of GNOME"
[08:11] <seb128> same for gnome-calculator
[08:11] <seb128> that was gcalctool and a standalone app, long before there was a notion of GNOME apps
[08:11] <seb128> those are just GTK apps that happen to have been historically hosted on the GNOME infrastructure
[08:13] <darkxst> seb128, I suppose GTK could be redifined GNOME toolkit now and then everything makes sense!
[08:13] <seb128> right
[08:14] <seb128> what is let to know if app writers are still wanting to use it then
[08:14] <seb128> because most have users out of GNOME
[08:14] <darkxst> QT is just as alien!
[08:15] <seb128> you can resize and move qt apps on any desktop though ;-)
[08:16] <ochosi> +1
[08:16] <darkxst> seb128, you can disable lack of titlebar on any desktop by ignoring the WM hint in the window manager
[08:16] <ochosi> (while gtk might in fact be the gnome toolkit, xfce still uses it)
[08:17] <darkxst> ochosi, gtk was once GIMP toolkit
[08:17] <seb128> darkxst, "you" is not the apps writers nor the users in that case
[08:17] <ochosi> darkxst: i know, are you making a point?
[08:18] <darkxst> seb128, what does it have to do with the app writers?
[08:18] <seb128> well, the situation currently is that app writers using gtkheaderbars end up having a buggy experience for their users on a variety of desktops
[08:18] <seb128> sure you can claim that those desktop could patch that wm
[08:19] <desrt> seb128: hi!  how are you today?
[08:19] <seb128> but reality is that there are plenty of desktop which behave buggy currently with new gtk widgets
[08:19] <seb128> desrt, hey, very good ;-) how are you? had a good w.e ?
[08:19] <desrt> seb128: yup.  weather in berlin is very nice :)
[08:19] <seb128> great
[08:19] <desrt> we had a whiskey tasting last night :)
[08:19] <seb128> they forecast rain for weeks here, still didn't get it
[08:20] <seb128> lol
[08:20] <chrisccoulson> *ears prick up*
[08:20] <desrt> don't complain :p
[08:20] <seb128> was that a dholbach plan? ;-)
[08:20] <chrisccoulson> hi seb128, desrt
[08:20] <desrt> no.  kat, dave, claudia and claudia's husband(?)
[08:20] <seb128> k
[08:20] <seb128> chrisccoulson, hey, how are you?
[08:20] <desrt> larsu was supposed to join but he bailed at the last minute.  boo.
[08:20] <seb128> chrisccoulson, do you highlight on whiskey? ;-)
[08:21] <chrisccoulson> seb128, not bad thanks. and you?
[08:21] <seb128> good thanks!
[08:21] <chrisccoulson> hah, not quite. i'd just sat down when I noticed it ;)
[08:21] <seb128> ;-)
[08:21] <Laney> oh I didn't reply
[08:21] <Laney> weekend was playing mgs and climbing = good ;-)
[08:21] <seb128> ;-)
[08:22] <darkxst> seb128, point being, window decorations can be re-enabled by ignoring the XWM hints, everything else can be controlled via themes and/or xsettings
[08:23] <darkxst> (in 3.12)
[08:23] <seb128> darkxst, is "ignoring the XWM hints" correct or a workaround hack?
[08:23] <darkxst> i.e. you can make the CSD's display, minimise, maximise and close
[08:24] <darkxst> or nothing
[08:24] <darkxst> seb128, correct, not just a hack, that is how upstream expect things to work
[08:24] <seb128> "ignoring" doesn't seem proper behaviour
[08:24] <seb128> if there is an hint it's probably for a reason and not to be ignored?
[08:25] <darkxst> seb128, its a "hint" not a "demand"
[08:25] <seb128> well, if somebody bothered adding hint that's probably for a reason
[08:25] <darkxst> seb128, right, but that is for GNOME reasons
[08:26] <desrt> darkxst: did you also have a good weekend? :)
[08:26]  * seb128 has the feeling desrt is trying to stop that discussion
[08:26] <desrt> seb128: too early on monday morning for pointless trolls
[08:26] <seb128> desrt, it's not really a troll, we need to figure out what we do with CSD this cycle
[08:26] <desrt> it seems this conversations tends to go around in circles...
[08:27] <seb128> though it drifted to "who is to blame" which is probably not useful
[08:27] <larsu> seb128: there is a very simple solution to this problem: add frame extents to compiz
[08:27] <seb128> larsu, shrug
[08:27] <seb128> it's not about compiz
[08:27] <seb128> xfce has the same issue
[08:27] <seb128> wmaker has the same issue
[08:27] <desrt> ...and back to 'who to blame' :)
[08:27] <seb128> and I can go on if you want
[08:28] <darkxst> desrt, I had a good 10 day climbing trip :)
[08:28] <darkxst> ^Laney :)
[08:29] <darkxst> seb128, from my discussion upstream, "hints" are more like recommends in apt
[08:29] <seb128> larsu, also I'm not sure that even if compiz was to have proper decoration/border for those we wouldn't have an UI "regression" for Unity users in consistency/behaviour
[08:29] <seb128> darkxst, right, and the reply to "packages have buggy recommends" is not "make apt ignore recommends"
[08:31] <desrt> "_GTK_FRAME_EXTENTS"
[08:31] <desrt> looks like a pretty universally-supported and well-specified hint
[08:31] <desrt> i mean... why hasn't everyone else done this already?
[08:31] <larsu> seb128: fair enough - this is a gtk extension and gtk ought to have a better fallback if it doesn't exist
[08:31] <larsu> desrt <- sarcastic
[08:31] <desrt> larsu <- benefit of being in the same room
[08:32] <larsu> I didn't figure it out until I asked - it is even harder for people on irc
[08:33] <darkxst> seb128, hmm, this is not buggy, its intentional
[08:33] <darkxst> seb128, If some WM wants window decorations, it should ignore the hints
[08:33] <seb128> darkxst, so an hint was invented/added in the goal of making wms ignore it?
[08:34] <seb128> well the default behaviour should be to have decoration
[08:34] <chrisccoulson> which hint? turning off window decorations? what about if I change chrome to not use the system titlebar?
[08:34] <seb128> so the code works everywhere
[08:34] <chrisccoulson> i don't think you can just ignore the hints
[08:34] <seb128> now if gnome-shell is to do something new and specific, they can have an hint to opt in for that
[08:35] <seb128> that would be the logical way to do things imho
[08:35] <larsu> so gtk only checks whether the screen is composited and has rgba visuals to decide whether to enable csd
[08:35] <darkxst> seb128, maybe, but 3.12 is well past freeze now, so good luck changing anything there!
[08:35] <larsu> is there a way for the wm to advertise the things it supports?
[08:35] <larsu> we could make gtk check that...
[08:36] <larsu> Trevinho: ^
[08:36] <desrt> _GTK_FRAME_EXTENTS is in _NET_SUPPORTED under metacity
[08:36] <desrt> gtk should just check this....
[08:37] <darkxst> larsu, I played with this ages ago, let me dig up my patches
[08:37] <desrt> s/metacity/mutter/
[08:37] <larsu> it is not in compiz (obviously=)
[08:38] <desrt> this is mega-easy
[08:38] <desrt> gdk already has code for reading this list and storing it on the screen
[08:39] <darkxst> desrt, with 3.12 its just the window decorations
[08:41] <darkxst> you have GtkHeaderBar:decoration-layout to see the window control within the buttons
[08:56] <larsu> seb128: is there a bug open about the can't-resize-csd-windows?
[08:57] <desrt> (upstream, ideally...)
[09:00] <seb128> desrt, larsu: not that I know, darkxst might know better, he has been working with upstream on those issues
[09:01] <seb128> to be honest- I didn't spend much energy on that since the plan for the LTS was to just avoid those
[09:03] <darkxst> larsu, I don't think so, well I haven't seen one
[09:05] <larsu> thanks
[09:05] <darkxst> larsu, is that just a theming issue though? adwaita has invisible borders to make grabbing the handles easier I believe
[09:08] <larsu> darkxst: it's both. You need the extension so that resizing a borderless window works and theming to draw the shadow
[09:08] <larsu> (which is drawn client side, oddly enough)
[09:15] <desrt> larsu: http://ur1.ca/h77j3
[09:15] <darkxst> larsu, not sure why that is odd? CSD's are client side ;)
[09:17] <desrt> news flash: resizing maybe not related to csd...
[09:20] <larsu> darkxst: just seems like it should be done in the compositor
[09:20] <larsu> so that stacking shadows can be dealt with properly
[09:29] <desrt> larsu: http://ur1.ca/h77me
[09:37] <Trevinho> larsu: yes, as said the _NET_SUPPORTED on root window can define that
[09:37] <Trevinho> larsu, desrt: the problem is that I don't see any app on gtk 3.10 (speaking of trusty SRUs) to export that... Thus I didn't implement on new decos
[09:38] <desrt> so there is a bug in gtk and also a bug in compiz
[09:38] <desrt> the bug in gtk is that it doesn't properly check for frame extents
[09:38] <desrt> but bug in compiz is that it doesn't resize windows that have borders
[09:38] <Trevinho> desrt: the bug is in unity now... Compiz doesn't handle decorations anymore
[09:39] <desrt> i'm gonna install xfce and check what happens there
[09:39] <Trevinho> desrt: but, well it's true we need to add an input border to these as well
[09:39] <larsu> desrt: ask seb128
[09:39] <larsu> he tests on xfce all the time
[09:40] <desrt> seb128: can you test something for me?
[09:42] <seb128> desrt, yes?
[09:43] <desrt> seb128: nvm.  installed it myself.
[09:43] <desrt> xfce has a totally different issue
[09:43] <seb128> k
[09:43] <desrt> it _always_ draws the titlebar, ignoring the hint
[09:43] <desrt> seems that gnome-shell is the only good WM here
[09:43] <desrt> (...and even gtk gets it wrong there)
[09:44]  * desrt tries kwin
[09:44] <Trevinho> anyway, back to the general problem, I don't the we can just ignore the headerbar hint on non-gnome desktops, as the header bar might also include elements (such as non-window-buttons) that might be not shown anywhere else..
[09:44] <seb128> desrt, right, xfce is what gives you https://lh4.googleusercontent.com/-YlXpA1jR3O0/UpMsjN5c_OI/AAAAAAAAAXo/ZKPUsRLr-5s/w480-h500-k/xfcecalc.png
[09:44] <seb128> well, at least you know it's the calculator ;-)
[09:44] <desrt> this is xfce's fault, for sure
[09:45] <Trevinho> lol
[09:45] <Trevinho> that's a nice way to save vertical space
[09:45] <darkxst> Trevinho, ignoring the hint still leaves the GtkHeaderBar in place
[09:45] <darkxst> so you have a titlebar and the header bar
[09:45] <darkxst> it is possible to override appmenu and window controls from theming/xsettings
[09:45] <Trevinho> darkxst: mh, so making it act like a toolbar without wm buttons, right?
[09:46] <darkxst> Trevinho, exactly
[09:46] <darkxst> atleast in gtk 3.12
[09:46] <seb128> so if you use adwaita on gnome-classic you loose?
[09:47] <desrt> seb128: probably...
[09:47] <desrt> well... gnome-fallback, you mean
[09:47] <seb128> right
[09:47] <desrt> gnome classic works, obviously
[09:47] <seb128> gnome-panel+compiz
[09:47] <seb128> whatever that is called
[09:47] <desrt> compiz is borked
[09:47] <seb128> gnome-panel + ion
[09:47] <desrt> gtk + metacity will be broken right now for stupid reasons (gtk bug)
[09:47] <seb128> if you prefer :p
[09:47] <desrt> after my patch, gtk+metacity would work
[09:47] <desrt> since metacity is a good WM
[09:48] <desrt> compiz, on the other hand... ;)
[09:48] <larsu> s/a/the
[09:48]  * larsu hides
[09:48] <seb128> lol
[09:48] <seb128> what about "awesome"? ;-)
[09:48] <seb128> or whatever Laney is using
[09:48] <seb128> that frame based wm
[09:48] <Trevinho> desrt: it's quite trivial to fix *unity* as well ;)
[09:48] <larsu> that's not good, obviously. It's awesome
[09:48] <seb128> larsu, ;-)
[09:48] <desrt> Trevinho: please fix it :)
[09:49] <desrt> kwin does the same as xfce....
[09:49] <desrt> seems that these hints (from *motif*) are not yet supported in these modern WMs :)
[09:49] <Trevinho> desrt: I will, but since we're focusing on T still, I will do that once gtk is exporting the atom
[09:49] <desrt> Trevinho: doesn't work that way.
[09:49] <desrt> Trevinho: you export the atom.
[09:49] <Trevinho> ah, ok
[09:49] <desrt> or rather, you don't
[09:49] <desrt> and then gtk sees that you don't and changes its behaviour
[09:50] <desrt> what you need to do is to support the 'border' hint properly
[09:50] <desrt> ie: i want a border on this window, but no titlebar
[09:50] <Trevinho> I see...
[09:50] <desrt> and if the user's unity/compiz/etc. theme has 0-width borders then you need to figure out how resizing will work...
[09:51] <Laney> xmonad
[09:51] <Laney> I don't have decorations
[09:52] <desrt> MWM_DECOR_BORDER is the name of the motif hint
[09:53] <desrt> _MOTIF_WM_HINTS
[09:53] <desrt> long live legacy!
[09:57] <darkxst> desrt, yes that is it! hardly a new invention!
[10:00] <desrt> darkxst: do you know an upstream bug link for this issue?
[10:01] <Trevinho> desrt: would this recent change impact on us https://git.gnome.org/browse/gtk+/commit/?id=fb9a6bb6d8d6b60b25c9b9853decbc As it seems related to other WMs with duplicated borders
[10:02] <desrt> Trevinho: interesting......
[10:02] <desrt> i was just about to add this check back in
[10:02] <desrt> i think maybe this was the wrong fix....
[10:03]  * desrt will talk to mclasen about this later....
[10:03]  * desrt feels like he just wasted a lot of time
[10:05] <darkxst> desrt, there was a bug regarding titlebars, I will see if I can find it later (cooking dinner now)
[10:06] <darkxst> and pretty sure it was mclasen who said the WM should ignore hints
[10:07] <Laney> vala-0.24, any objections?
[10:07] <desrt> i hate wms
[10:08] <Laney> wichard stallman
[10:08] <larsu> lol
[10:08] <davmor2> seb128: on settings on the desktop.  The brightness bar appears for a split second and then vanishes I'm pretty sure there is already a bug I've seen for it I was wondering if you knew if there was a fix knocking about I can try at all
[10:08] <seb128> davmor2, no idea
[10:08] <seb128> Laney, is that a new parallel source?
[10:08] <Laney> yes as normal, switches the default
[10:08] <Laney> Debian already did it
[10:09] <seb128> I guess it works fine with gtk 3.10?
[10:09] <seb128> well, let's go for it
[10:09] <seb128> we can rollback if it turns out to be needed
[10:10] <Laney> nod, ta
[10:12] <darkxst> hmm, brightness api changed for 3.10, but that hasnt landed in archives yet
[10:12] <darkxst> davmor2, are you using a ppa?
[10:13] <davmor2> darkxst: Nope default trusty
[10:13] <Laney> haha yeah I see that too
[10:14] <darkxst> no idea then, the brightness changes have not landed yet
[10:14]  * darkxst had to patch them out of gnome-shell...
[10:15] <Laney> Error getting brightnesS: Timeout was reached
[10:16] <darkxst> Laney, the api changes (I know off) are in g-s-d 3.10 and maybe gnome-desktop 3.10
[10:17] <Laney> Probably not relevant
[10:17] <darkxst> Laney, yes I gathered, just saying
[10:18] <Laney> Nod, thanks
[10:27] <Laney> yeah not sure you can fix this without the new API
[10:27] <Laney> it's "see if the GetPercentage method times out" to determine whether to hide the row
[10:43] <darkxst> Laney, good luck with that ;)
[10:46] <Laney> I suggest the best way to fix this is to take the new properties from g-s-d 3.10 :-)
[10:47] <Laney> I see they've replaced the 'screen' panel upstream
[10:57] <darkxst> Laney, that would require my displayconfig daemon, but that would work
[10:57] <darkxst> and gnome-desktop 3.10 of course
[10:58] <Laney> we can probably manage that this cycle
[10:58] <Laney> couple of weeks of merging fun first though
[10:59] <darkxst> Laney, right, dbus activation is broken right now due to glib changes, but thats easy enough to fix
[11:00] <darkxst> Laney, mind you I would like to go straight to 3.12
[11:01] <Laney> haha
[11:01] <darkxst> 3.10 -> 3.12 was somewhat less disruptive I believe
[11:02] <seb128> they always say that?
[11:03] <darkxst> seb128, I am saying that, although I haven't dug too deeply on it, so not sure how it might affect all the legacy stuff you guys are carrying, but I think it might be minimal
[11:03] <seb128> there is at least an abi/api change on keyboard stuff
[11:03] <seb128> I think we should do it by steps
[11:04] <seb128> start with 3.10, stabilize that and then see what's next
[11:05] <darkxst> seb128, I certainly won't have to time to work on a double transition this cycle
[11:05] <darkxst> seb128, and you little steps, generally end up in us missing out on various bits
[11:06] <seb128> well, the alternative is too land more than we can chew in a cycle and take an hit in quality
[11:06] <seb128> which we decided to stop doing
[11:06] <seb128> quality first nowadays
[11:06] <darkxst> seb128, for gnome-desktop then?
[11:06] <darkxst> ^fork
[11:06] <darkxst> have a libunity-desktop ;)
[11:07] <darkxst> I would like to land gnome-desktop, gnome-setting-daemon (vanillised) and gnome-control-centre (vanillised) all at the same time
[11:07] <seb128> that wouldn't work for the reasons we already mentioned
[11:08] <seb128> then we would need to build e.g nautilus and eog with one of the 2 libs
[11:08] <seb128> which would lead to "fork or dual build any consumer of the library that got forked"
[11:08] <darkxst> seb128, apps can all build off the fork
[11:09] <seb128> hum
[11:10] <seb128> well, let's see how the cycle shapes, I doubt we are going to have free cycles for that
[11:10] <darkxst> most of the app-side stuff apart from the thumbnailer is dead now
[11:10] <seb128> we said we would land 3.10 this cycle, you can get g-s-d and g-c-c vanillised with it
[11:10] <seb128> that should be a good start
[11:10] <Laney> seb128: would you reject valabind please https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
[11:10] <Laney> stupid wrong target
[11:10]  * Laney needs to dist-upgrade already
[11:11] <seb128> Laney, done
[11:11] <Laney> ty
[11:11] <seb128> yw
[11:11] <seb128> I wonder what to do here
[11:11] <seb128> I'm tempted to stay on the LTS until .1
[11:11] <darkxst> seb128, not exactly, you forked g-s-d/g-c-c to unblock us, but it wasn't enough
[11:11] <Laney> i bet you have multiple machines
[11:12] <seb128> not that I use
[11:12] <seb128> like I've my old laptop and a netbook
[11:12] <seb128> but I boot them once a week as test machines
[11:13] <seb128> darkxst, right, it's a step in the right direction, but we manage to do only so much each cycle
[11:13] <darkxst> seb128, which is why I think we should skip g-d 3.10
[11:14] <seb128> I fail to see the logic there
[11:15] <seb128> 3.10 is <some work>, 3.12 is <some extra work>
[11:15] <seb128> if we directly go to 3.12 we sign for the extra work
[11:15] <seb128> it makes more sense to do it by steps and see how things go and how busy everyone is
[11:15] <Laney> hmm, not sure about that
[11:15] <darkxst> seb128, no, 3.10 was <lots of work>, 3.12 is <a little extra>
[11:15] <Laney> it assumes 3.12 is going to be much more difficult
[11:16] <Laney> but doing the work twice is certainly going to be harder than doing it at once
[11:16] <seb128> I don't assume anything without having looked
[11:16] <seb128> but that means I don't assume it's going to be trivial work either
[11:16] <seb128> Laney, if you want to asset the work for 3.12 and "own" the transition feel free
[11:16] <Laney> I think we need to know what the api changes are
[11:16] <seb128> we just need somebody who commits to do the work
[11:16] <seb128> and I'm not that somebody
[11:17] <seb128> but I'm not stopping others ;-)
[11:17] <Laney> well I wouldn't mind assisting if -gnome wants to drive it
[11:17] <seb128> we need somebody to lead/commit to do it
[11:17] <seb128> I don't mind assisting either
[11:17] <seb128> but that's the typical "no real owner" that leads to "nobody has cycles to do the bulk of the work"
[11:18] <darkxst> seb128, seriously, you just drive away all assistance, right?
[11:18] <Laney> sure, those who want the change can work for it
[11:18] <seb128> darkxst, ?
[11:18] <darkxst> I have put in countless hours on work that ultimately gets knocked back each cycle
[11:20] <seb128> there has been for sure some friction between stability/updates, especially with everybody being busy and the LTS coming
[11:20] <seb128> we spent quite some work previous cycle to lower those frictions/resolve it
[11:20] <darkxst> seb128, this goes back well before the LTS
[11:20] <seb128> (e.g with u-s-d u-c-c)
[11:21] <darkxst> seb128, right and then you  basically abandoned g-c-c? and desktop-team never uploaded by g-c-c 3.8 branch
[11:21] <seb128> well, bottom line is that we working on resolving those issues, even if it takes time
[11:22] <seb128> well, g-c-c is yours, yes we mostly stopped working on it (though robert_ancell did some fixing before release for e.u.c ranked issues)
[11:22] <darkxst> seb128, while I agree you are working on resolving the issues, your methodology just makes more work for us
[11:23] <seb128> hum, g-c-c 3.8 was ready? the situation got a bit confused, there was nothing in the sponsoring queue and you guys were aiming for 3.10
[11:23] <Laney> Personally I'm happy to work with you on gnome-desktop 3.12 if you want to do that, I tend to agree that doing it twice makes it more unlikely to happen
[11:23] <seb128> you have been without internet at the same time as well
[11:23] <seb128> which was unfortunate
[11:23] <darkxst> seb128, only a 3 or so weeks
[11:23] <seb128> well, not sure why g-c-c 3.8 fall through the cracks then
[11:24] <seb128> it was not listed on the sponsoring queue
[11:24] <seb128> and nobody pinged back to remind us about it
[11:24] <darkxst> seb128, there was definately a MP for it
[11:24] <darkxst> anyway the point of all this, Is i want to go straight to 3.12 this cycle for g-d, g-s-d, g-c-c
[11:24] <seb128> there were 2, and they were not based on current trunk
[11:24] <seb128> k
[11:24] <seb128> fair enough
[11:25] <seb128> let's work on getting gnome-desktop 3.12 then
[11:25] <darkxst> seb128, yes
[11:25] <seb128> g-s-d g-c-c are all yours
[11:25] <seb128> Laney, thanks for proposing to help there
[11:25] <Laney> sure
[11:26] <Laney> also I patched cheese 3.12 to have a conditional header bar ;-)
[11:26] <darkxst> seb128, happy to deal with those
[11:26] <Laney> #bleedingedge
[11:26] <darkxst> Laney, cheese is not using GTKHeaderBar?
[11:27] <Laney> sure it is
[11:28] <darkxst> Laney, seems really wrong to patch individual apps in that case
[11:28] <seb128> how did we get cheese 3.12 ?!
[11:28] <Laney> we didn't
[11:28] <seb128> k
[11:28] <Laney> (yet)
[11:28] <seb128> because we didn't have the discussions on what we do with GNOME/apps this cycle (yet)
[11:28] <darkxst> seb128, are you ok with g-s-d and g-c-c getting added to the ubuntu-gnome packageset?
[11:29] <seb128> darkxst, yes
[11:29] <seb128> darkxst, btw does anyone plan to SRU g-c-c to list the correct OS version in trusty?
[11:29] <pitti> seb128: seems I earned the libnotify merge (https://merges.ubuntu.com/libn/libnotify/libnotify_0.7.6-1ubuntu3.patch) -- do you remember why we needed to revert the gir api?
[11:29] <darkxst> seb128, noskcaj was supposed to be on that
[11:30] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=709524 summarize it well
[11:30] <ubot2> Gnome bug 709524 in general "API/ABI change to due recent add_action changes?" [Normal,Unconfirmed]
[11:31] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=702390#c13
[11:31] <ubot2> Gnome bug 702390 in general "NotifyNotification: fix annotation for add_action()" [Normal,Resolved: fixed]
[11:31] <seb128> (that bug has the discussion we had by then)
[11:32] <pitti> seb128: ah, thanks; so check apt-cache rdepends gir1.2-notify-0.7 for which ones use that API?
[11:32] <pitti> (and update them)
[11:33] <seb128> pitti, it's not that easy, we should imho do a proper transition/change the binary name
[11:33] <seb128> pitti, we ended up reverting because updating made unity8's CI tests go red iirc
[11:34] <seb128> pitti, not sure how we can update all rdepends/tests in locked steps without a rename/proper transition
[11:35] <pitti> well, we can't really
[11:35] <pitti> that would involve adding code to all reverse depends to select a particular version of the ABI in GI
[11:35] <pitti> which would again be a permanent delta
[11:35] <seb128> well, if we rename the binary at least britney would keep in proposed until the archive is ported
[11:36] <pitti> seb128: so in all cases we end up with a permanent delta against debian or upstream
[11:36] <seb128> rename binary = changing the name of the .deb
[11:36] <seb128> well, no upstream delta
[11:36] <darkxst> seb128, maybe I will just get our artwork team to make a new image,but I still wonder which genius decided to embed the version within the image!
[11:37] <pitti> seb128: the only dependency that seems relevant for that is unity-mail, or is there another one?
[11:37] <pitti> (for making CI red, I mean)
[11:37] <seb128> darkxst, nobody wrote code to generate a logo including the version at runtime
[11:37] <darkxst> seb128, there were upstream patches for that
[11:37] <seb128> pitti, I think it was unity8 by then when we reverted
[11:38] <darkxst> hmm, or maybe sidestream (as in fedora patches)
[11:38] <seb128> darkxst, those would generate text, not an logo that is compliant with our trademark
[11:38] <seb128> iirc
[11:38] <attente> Trevinho, hi, what do you think about https://code.launchpad.net/~attente/unity/1291461/+merge/215848? is it ok for merging?
[11:38] <seb128> pitti, they had notification-in-unity8 tests somewhere
[11:38] <seb128> pitti, Saviq might remember the specifics
[11:39] <darkxst> seb128, why can't the version number be text?
[11:39] <seb128> pitti, see https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/1223401 , Saviq had a branch there
[11:39] <ubot2> Launchpad bug 1223401 in libnotify (Ubuntu) "[0.7.6] the add_action api changed creating issues for clients" [High,Confirmed]
[11:39] <Saviq> but it's gone now, too...
[11:40] <Saviq> but it was just adding the None param or so
[11:40] <seb128> darkxst, they can, we just need a logo/layout that looks good ... anyway, xnox improved things for trusty, we generate the logo at build-time now
[11:40] <seb128> Saviq, right, the question was rather "which test went red when the api changed"
[11:41] <seb128> because pitti wants to drop the revert
[11:41] <Saviq> yeah, all the notification ones
[11:41] <seb128> so we need to "fix" the rdepends
[11:41] <darkxst> seb128, ok I will take a look and try merge into g-c-c
[11:41] <Saviq> maybe not all, but some of unity8.shell.tests.test_notifications.py
[11:41] <seb128> thanks
[11:42]  * Saviq looks up smokeng results around that time
[11:44] <darkxst> seb128, last question before I go to sleep, are you ok with SRU on https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+files/gobject-introspection_1.39.3-0ubuntu1%7Etrusty1_1.40.0-1ubuntu1%7Etrusty1.diff.gz
[11:45] <darkxst> that is need for gjs 1.40.1 which fixes (well should) all the GC re-entrancy issues causing some crashes
[11:45] <darkxst> in gjs apps
[11:46] <seb128> darkxst, pitti is the person to ask about g-i
[11:46] <seb128> no objection from my part
[11:46] <darkxst> ^pitti?
[11:47] <pitti> darkxst: that diff is unreadable; what does it do?
[11:48] <pitti> i. e. it certainly needs to be stripped down, unless that's just the .1 upstream release
[11:48] <Laney> looks like a merge
[11:48] <Laney> but it doesn't make sense, 1.39.3 isn't what trusty has
[11:48] <pitti> and tursty has 1.40.0 already
[11:48] <Laney> oh it's some previous version in the ppa
[11:49] <darkxst> https://git.gnome.org/browse/gobject-introspection/commit/?id=21e51026d74bca48b814ace73eb588e6542a27cd
[11:49] <pitti> oh, debian/patches/git_tests_implementation_interface.patch
[11:49] <pitti> darkxst: yes, absolutely fine for SRU -- this is gimarshallingtests only
[11:49] <darkxst> pitti, yes
[11:50] <darkxst> jenkins will blow up without it ;)
[11:53]  * darkxst slowly realises launchpad is incredibly dumb ;( 
[11:54] <Laney> I think it calculates the diffs at upload time
[11:54] <Laney> no that doesn't make sense
[11:54] <Laney> yeah it just picked a weird base
[11:56] <darkxst> Laney, yeh it picked the old old ppa version, that was before we uploaded it into trusty, way back when mozjs24 landed
[11:58] <darkxst> most likely that package was deleted in the meantime as well
[11:58] <darkxst> although I have noticed deletions don't show up on my version scraper ;(
[12:00] <darkxst> or just keep on showing up always
[12:02] <Trevinho> attente: Hi, I quickly looked at it last week, and it's mostly ok, but really can't you remove the goto? Adding another simple method is just better, than it
[12:02] <Trevinho> attente: I also had other small comments, but I'll be back on that soon
[12:12] <attente> Trevinho, sure, i can remove the goto, it'll just be a bit more duplicated code
[12:13] <Trevinho> attente: if you use a quick method, you can just call something like "return activate()"...
[12:15] <attente> Trevinho, isn't that effectively like using goto?
[12:27] <Saviq> pitti, seb128, FWIW here's where the unity8 tests failed: http://ci.ubuntu.com/smokeng/saucy/touch/mako/20130910/4122/unity8-autopilot/
[12:27] <Trevinho> attente: yes, but just more adapt to higher level code
[12:28] <attente> Trevinho, no problem
[12:39] <Sweet5hark> moin!
[12:39] <Laney> 13:39:08 NOPE!
[12:40] <xnox> haha
[12:40] <Laney> hey Sweet5hark, how's it going? ;-)
[12:42] <Sweet5hark> fine, its a bit cloudy here so one can sit on the balcony above the playa des las canteras and still read the screen ;)
[12:43] <Sweet5hark> Laney: Also note that "moin" is an all day greeting not limited to the morning hours as any northern german might tell you ;)
[12:44] <Laney> it's always moin somewhere :P
[12:44] <Sweet5hark> https://en.wikipedia.org/wiki/Moin confirms ;)
[12:44] <seb128> Sweet5hark, still hacking in canary islands?!
[12:45] <Laney> Although many people think that moin derives from (Guten) Morgen ("Good Morning"), the word actually derives from the Dutch, Frisian, and Low German word mo(o)i, meaning "beautiful" or "good"
[12:45] <Laney> w@w!
[12:45] <Sweet5hark> seb128: staying a bit longer, results in a cheaper return flight.
[12:46] <seb128> k
[12:46] <seb128> enjoy ;-)
[12:47] <Trevinho> ah, attente the other thing you shouldo do, is to get rid of ReloadAccelerators, and doing that instead in the constructor... then initialize the accelerator_controller_ just exaclty as we do for indicators_ (in LauncherController)
[12:49] <attente> Trevinho, i did that because the object persists between locks, and the user might change those keybindings in between
[12:49] <Trevinho> attente: yes, but we don't need to monitor the changes, do we?
[12:50] <Trevinho> attente: I mean, if you initialize the Accelerators before each lock, we should get the new ones, isn't it?
[12:51] <attente> but the LockScreenController needs a reference to the AcceleratorController so that we can handle opening the panel via Alt+F10
[12:52] <Trevinho> attente: yes, in fact you can keep the reference...
[12:52] <Trevinho> attente: just keep it around only during the lokscreen life
[12:52] <Trevinho> attente: exaclty as we do for indicators
[12:54] <attente> Trevinho, EnsureShields will only create the shields one time over the entire Unity session
[12:54] <Trevinho> attente: nope, we destroy them when the lockscreen is hidden
[12:55] <Trevinho> attente: check fade_animator_.finished.connect([this] { cb
[12:57] <attente> Trevinho, ah, ok. for some reason, i thought i tried it, and the keybindings seemed to persist between locks.
[14:41] <xnox> Laney: seb128: http://paste.ubuntu.com/7352829/ ?
[14:42] <Laney> --start
[14:45] <Laney> That start on condition is wrong
[14:45] <Laney> you need to block I think
[14:49] <Laney> looks like the secrets one times out after a little bit
[14:58] <xnox> Laney: per docs it's "--start" just "start" works here as well, will change for consistentcy.
[14:58] <Laney> xnox: 'start' is just a random string which makes it spawn a new instance
[14:59] <Laney> I think you need 'starting xsession-init' or something to block it early enough, sadly
[14:59] <Laney> with your one I got normal ssh-agent
[15:00] <xnox> Laney: that's... helpful... so the trouble is that something else is already starting the gnome-keyring, so i just want to query the existing variables, not actually spawn and manage gnome-keyring daemon.
[15:00] <Laney> xnox: yeah, pam as you said isn't it?
[15:00] <Laney> so it'll already be there
[15:00] <xnox> Laney: maybe i should override and disable xdg/autostart .desktop jobs, and actually spawn the main process from upstart job similar to how ssh-agent does it and kill gnome-keyring pid in post-stop?
[15:01] <xnox> so with "--start" it will not relaunch
[15:01]  * xnox goes to count my gnome-keyring daemons
[15:01] <Laney> I have the pam one only, after the secrets one times out
[15:02] <Laney> the secrets one does not come from xdg autostart btw
[15:19] <Sweet5hark> xnox: aha! Ur in my base, recompiling LibreOffice against boost  bumps!
[15:20] <xnox> Sweet5hark: =))) did powerpc finish yet?!
[15:20] <xnox> Sweet5hark: i did a local rebuild on amd64 and it looked harmless enough.
[15:21] <Sweet5hark> xnox: seems all are finished and green.
[15:24] <xnox> Laney: this looks.... odd... http://paste.ubuntu.com/7353086/
[15:24] <xnox> it does run, it does propagate, but it's post-gui being up, and hence e.g. my terminal doesn't have the right vars =(
[15:24] <Laney> with what start on?
[15:25] <xnox> Laney: http://paste.ubuntu.com/7353091/
[15:25] <Laney> I think xsession is racy
[15:26] <xnox> true.
[15:26] <Laney> try starting xsession-init
[15:26] <xnox> yet, i don't see where i can hook into from "after ssh/gpg agents" but before "xsession-init"
[15:26] <xnox> cause that's where I want to be.
[15:26] <Laney> after?
[15:26] <Laney> why?
[15:27] <xnox> but ssh-agent & gpg-agent are also "start start on starting xsession-init"
[15:28] <xnox> or rather before them, cause otherwise they'd spawn non-gnome-keyring base agents and export them to the environment.
[15:28] <xnox> (ugly gtk dialog for ssh for example)
[15:28] <Laney> I think gnome-keyring will clobber them
[15:28] <Laney> but yes you get stray processes
[15:28] <Laney> that's what I see here
[15:29] <xnox> should gnome-keyring ship overrides to disable ssh-agent/gpg-agent?
[15:29] <tkamppeter> qengho, hi
[15:30] <xnox> in non-upstart world, did gnome-keyring just clobber and leave stray processes?
[15:31] <xnox> stgraber: how should gnome-keyring trump ssh-agent/gpg-agent jobs to provide agents the way we did before upstart started to manage desktop sessions?
[15:31] <xnox> "echo manual" > ssh-agent.override ?
[15:41] <qengho> tkamppeter: hi
[15:43] <xnox> http://paste.ubuntu.com/7353195/ <- fix to make sure gpg-agent doesn't spawn if there is one already available.
[15:43] <xnox> and then http://paste.ubuntu.com/7353198/ should do it nicely.
[15:45] <Laney> will you get started up to three times?
[15:45] <Laney> i.e. guard against -z GNOME_KEYRING_CONTROL?
[15:46] <xnox> yeap, good point.
[15:47] <Laney> not that it matters since you'll get the same values
[15:47] <Laney> still good to do
[15:47] <xnox> well, doesn't everything have gnome_keyring_control from before upstart starts?!
[15:47]  * xnox tests
[15:47] <Laney> hmm maybe
[15:50] <xnox> Laney: yeah keyring control is there without setting it, so i'll just drop that.
[15:50] <xnox> Laney: guard against both ssh-agent & gpg-agent?
[15:50] <xnox> [ -z "$SSH_AUTH_SOCK" ] || [ -z "GPG_AGENT_INFO" ] || { stop; exit 0; }
[15:52] <Laney> that hurts my head
[15:53] <xnox> http://paste.ubuntu.com/7353267/
[15:54] <Laney> you're missing a $
[15:54] <xnox> ture.
[15:55]  * xnox not type write today
[15:55] <xnox> *right
[15:55] <tkamppeter> qengho, earlier I had talked to you about opening .m3u files in Chromium and ended up opening bug 1311322. With seb128's instructions of comment #2 I was able to make Chromium use VLC for the .m3u files but there is still a small issue: Instead of directly opening the .m3u files with VLC it downloads them and lists them at the bottom. I have to click the file there to open it. How canm I configure Chromium t
[15:55] <tkamppeter> o get the files directly opened.
[15:55] <ubot2> Launchpad bug 1311322 in unity-control-center (Ubuntu) "There is no easy way to associate a program to a specific mimetype (out of using nautilus)" [Wishlist,Triaged] https://launchpad.net/bugs/1311322
[15:55] <Laney> other than that I think it's good
[16:02]  * xnox must resist ice-cream truck music
[16:03] <Laney> don't
[16:03] <Laney> 99 flake calls you
[16:04] <mlankhorst> high priority mails at the end of a workday with a short deadline are the best :P
[16:04] <Laney> "Laney needs ice cream by 6pm"?
[16:05] <mlankhorst> haha
[16:05] <xnox> =)))))))))
[16:10] <stgraber> xnox: I suspect we'd want a gnome-keyring job that'd be made in a way that it always starts before the other two, then have the other two check if the environment is already set
[16:11] <xnox> stgraber: ack, that's what i've ended up doing. uploaded gnupg and gnome-keyring again.
[16:11] <stgraber> xnox: we need gnome-keyring to be upstart-managed anyway since otherwise some processes won't have the environment variables set, so this should be reasonably easy
[16:38] <Sweet5hark> grumble, were do I get a password reset for canonicaladmin.com?
[16:42] <seb128> Sweet5hark, not sure, ask the is channel or file a rt?
[16:49] <Sweet5hark> seb128: thanks.
[16:49] <seb128> yw!
[18:07] <tkamppeter> qengho, still there?
[18:07] <qengho> tkamppeter: yes!
[18:17] <tkamppeter> qengho, have you seen my question to you?
[18:19] <qengho> tkamppeter: no, I didn't until now.
[18:20] <qengho> tkamppeter: I don't know, offhand. You might try #chromium-support .
[18:28] <tkamppeter> qengho, thanks anyway.
[20:15] <mdeslaur> Trevinho: have you seen bug 1313885 ?
[20:15] <ubot2> Launchpad bug 1313885 in unity (Ubuntu) "lock screen bypass" [Undecided,New] https://launchpad.net/bugs/1313885
[20:16] <mdeslaur> Trevinho: can I assign you to it?
[20:48] <mdeslaur> also, we need a fix for bug 1313910
[20:48] <ubot2> Launchpad bug 1313910 in indicator-datetime (Ubuntu) "can launch evolution from the greeter in 13.10" [Undecided,New] https://launchpad.net/bugs/1313910
[21:48] <bschaefer> mdeslaur, hey, i can't actually type anything in for bug 1313885
[21:48] <ubot2> Launchpad bug 1313885 in unity (Ubuntu) "lock screen bypass" [Critical,Confirmed] https://launchpad.net/bugs/1313885
[21:49] <bschaefer> mdeslaur, but ill get a fix for the command lens coming up at all
[21:49] <bschaefer> as thats really the issue here...
[22:15] <mdeslaur> bschaefer: awesome, thanks...let me know when you have a patch ready, and I'll push it out as a security update
[22:15] <bschaefer> mdeslaur, sounds good, looks like theres a few other shortcuts causing issue (only when right clicking that top bar)
[22:15] <bschaefer> looking at fixing those as well...
[22:15] <bschaefer> (such as alt+f1, super+tab)
[22:16] <mdeslaur> bschaefer: FYI, I can type in the command lens in a vm
[22:16] <bschaefer> mdeslaur, interesting, well i've a fix that'll stop the commands lens from popping up :)
[22:17] <mdeslaur> awesome :)
[22:17]  * bschaefer is just checking all other shortcuts atm
[22:29] <bschaefer> mdeslaur, alright, so this will be a work around for right now, as the real issue is the fact you can right click enough to get the windows menu to pop up
[22:29] <bschaefer> but that alone doesn't cause problems, but allows the command lens to pop up
[22:29] <bschaefer> ill have to talk with Trevinho  for the real fix
[22:29] <bschaefer> lp:~brandontschaefer/unity/lp.1313885-fix
[22:30] <bschaefer> mdeslaur, https://code.launchpad.net/~brandontschaefer/unity/lp.1313885-fix/+merge/217516
[22:30] <bschaefer> sadly, no one else on the unity7 team is around for a review :(
[22:31] <bschaefer> opps, i need to fix that branch...(another branch got mixed in)
[22:33] <bschaefer> mdeslaur, https://code.launchpad.net/~brandontschaefer/unity/lp.1313885-fix/+merge/217519 (fixed MP)
[22:33] <sarnold> bschaefer: why is the IsLocked() check removed from the SetUpAndShowSwitcher() method?
[22:33] <bschaefer> sarnold, its just moved up a function
[22:33] <bschaefer> sarnold, it looks iffy, but the SetUpSwitcher() before handle takes the cursor away
[22:33] <bschaefer> i suppose thats not 100% needed for this branch though
[22:34] <bschaefer> theres function A() which function A() calls B(), and function A() is the only function that calls function B(), and i just moved the check from B() to A()
[22:35] <sarnold> bschaefer: good good :)
[22:35] <bschaefer> yeah i had the same reaction when i saw the diff :)
[22:35] <sarnold> :)
[22:36] <sarnold> I figured it was just hauled up in the call chain but the diff doesn't have sufficient context to judge that. hehe.
[22:36] <bschaefer> yeah it doesn't show that :)
[22:36] <bschaefer> but theres was some other code that was being ran then skipped, that should just be skipped, if we are skipping
[22:36] <bschaefer> (like hiding the cursor)
[22:45] <mdeslaur> hrm, the unity currently in trusty-proposed has a security fix in it too
[22:46] <mdeslaur> that really should go through trusty-security
[22:47] <sarnold> mdeslaur: hrm, based solely on the changelog description that sounds like a partial attempt to fix unity's role in 49579 -- it doesn't feel like a complete enough 'fix' to call it a security update, imho
[22:48] <mdeslaur> sarnold: if it prevents the hud/dash from appearing over the lock screen in certain scenarios, sounds like a security fix to me
[22:50] <sarnold> mdeslaur: hrm. I figured they'd just prevent the screen from locking at all..
[22:50] <sarnold> it could be security then :) heh
[22:54] <mdeslaur> sarnold: ah, yes, you're right
[22:55] <mdeslaur> sarnold: actually, no, it's putting the dash _above_ the locked screen
[22:55] <mdeslaur> anyone, no biggie
[22:58] <mdeslaur> ok, building package now with bschaefer's merge proposal and r3789 patch for testing as security update
[22:59] <bschaefer> mdeslaur, it also looks like Trevinho might have a different fix, he just got back to his laptop
[22:59]  * bschaefer is testing that out atm
[22:59] <mdeslaur> ok
[23:02] <Trevinho> bschaefer: I mean, your changes should be there anyway, but that might force things even more
[23:02] <bschaefer> Trevinho, alright sounds good
[23:03] <bschaefer> mdeslaur, yeah lets push mine there a sanity check
[23:03] <bschaefer> as it'll force things to be even more correct
[23:04] <Trevinho> bschaefer: if you can fix the style of the first if(... (just a minor style fix, but it caught my eyes :D)
[23:04] <bschaefer> opps
[23:04] <mdeslaur> Trevinho: do you have an additional fix over what bschaefer<s got?
[23:04] <Trevinho> mdeslaur: bschaefer is testing it, as it should avoid any view to be put over the lockscreen anyway
[23:05] <bschaefer> Trevinho, dam pch files... need to recompoile
[23:05] <mdeslaur> ok, I'll let you two sort it out, let me know when the final patch is available
[23:05] <bschaefer> recompile*
[23:05] <Trevinho> (for good, hopefully)
[23:05] <bschaefer> mdeslaur, will do thanks!
[23:05]  * mdeslaur shakes fist at unity building in schroot killing his keyboard layout