[08:02] <Laney> xnox: "once"? what about UIF?
[08:02] <Laney> p.s. hi
[09:25] <darkxst> Hey Laney
[09:40] <asac> anyone can look at [09:40] <asac> and tell me if that changes anything in the ui?
[09:40] <asac> those are staged and just wanted to punt them in the archive... just double checking because of the freezes
[09:42] <Laney> hi darkxst
[09:42] <Laney> asac: I guess #ubuntu-unity would know more
[09:42] <asac> ok thought you were the integration experts :)
[09:43] <Laney> well, certainly not /me/, at least for that stuff :P
[09:43] <Laney> but the CI guys should be in unity anyway
[09:50] <darkxst> Laney, so T will move to 3.10?
[09:50] <Laney> darkxst: I'd expect so
[09:50] <Laney> might have similar time problems as we had this cycle though
[09:50] <darkxst> ok, right now there is big problem with the xrandr stuff being moved into mutter
[09:50] <darkxst> probably it will need to be copied into Unity
[09:51] <darkxst> the changes to gnome-desktop will be incredibly messy to revert for unity only
[09:52] <Laney> oh, what did they do?
[09:52] <darkxst> all the display config stuff is now a dbus api in mutter
[09:52] <Laney> ah, guess this is some abstraction over X/Wayland
[09:53] <darkxst> yeh mutter abstracts all that away, so gnome-desktop neednt have any idea whether running X or wayland
[09:53] <Laney> I suppose unity (or something) wants to implement this interface too then
[09:53] <darkxst> yup
[09:53] <Laney> fun
[09:54] <darkxst> it would be cleanest in Unity I guess
[09:55] <Laney> I suppose file a bug at least
[09:56] <Laney> seems like it'll lead to a lot of duplication
[09:57] <darkxst> Laney, I'm guessing Mir doesnt use xrandr etc?
[09:57] <darkxst> although Xmir might?
[09:58] <Laney> xmir will need to, sure
[11:15] <davmor2> Daft Question time.  Empathy, with google moving to it's own system, microsoft moving to sykpe, and facebook only working some of the time, isn't it just a poor irc client now?
[11:17] <jpds_> davmor2: Have some empathy.
[11:18] <davmor2> jpds_: :)
[11:41] <Mirv> ogra: can you check/ack content-hub packaging changes? http://pastebin.ubuntu.com/6132295/
[11:42] <Mirv> comes down to adding glib/gsetings/libnih dependenies
[11:58] <ogra> Mirv, shipit
[11:58] <Mirv> ogra: ok
[12:26] <pitti> Good morning
[12:27] <desrt> pitti: hello!
[12:27] <pitti> it's a desrt! hey mate, how are you?
[12:27] <RAOF> desrt, pitti: Good morning.
[12:27] <desrt> still down in the delta?
[12:28] <pitti> hey desrt
[12:28] <pitti> desrt: yes, last conf day; will fly back tomorrow
[12:28] <desrt> pop quiz: pitti and RAOF both wish you good morning.  which one uses the word 'mate' in his greeting?
[12:28] <desrt> RAOF: hi :)
[12:28] <desrt> pitti: what kind of swanky events did they have this year?
[12:29]  * desrt sort of regrets not coming
[12:31] <pitti> desrt: we had a "Mardi Gras" parade on Wednesday evening, right through the city (with police escort)
[12:31] <pitti> desrt: right into the "House of Blues" where they had an awesome band (and buffet and bar, of course)
[12:31] <desrt> figures :p
[12:32] <desrt> linuxcon events are getting ridiculous :p
[12:33] <desrt> was it fun? :)
[12:34] <pitti> desrt: yes, much
[12:34] <desrt> last year's campfire-on-the-beach thing was pretty sweet too
[12:34] <pitti> desrt: I've hung out in bars with life music three times this week now, it's just an amazing place for that
[12:35] <desrt> ya... we have some pretty good jazz clubs in toronto with live music every night... but i just can't imagine what it's like down there
[12:35] <desrt> probably completely off the charts
[13:10] <xnox> Laney: i think it all landed on time.
[13:41] <attente> mterry, hi
[13:41] <mterry> attente, hello
[13:42] <attente> mterry, do you have time to do a review of https://code.launchpad.net/~attente/unity-greeter/indicator-keyboard/+merge/179057 ?
[13:42] <Laney> xnox: I don't think so, because it's now UIF and there is no upload
[13:43] <xnox> Laney: right, sorry. ubuntu-themes upload happened in time for UIF, but not wallpapers.
[13:44] <Laney> ho hum!
[13:44] <Laney> kenvandine: do you have default wallpaper news? ;-)
[13:45] <kenvandine> Laney, no... i was just looking to see if he emailed me again
[13:45]  * kenvandine pings 
[13:45] <Laney> roxor
[13:45] <kenvandine> not on irc... jounih emailed me yesterday saying it was ready and what format i needed it in
[13:46] <kenvandine> i told him and asked him to email it to me asap... and nothing
[13:49] <mterry> attente, does that need an FFe?
[13:50] <attente> mterry, too be honest, i'm not sure
[13:50] <attente> should i file one anyways?
[13:50] <mterry> attente, and maybe we should convert any values of "ug-keyboard" we see into "keyboard" and drop our custom ug-keyboard code, if it's not useful anymore
[13:50] <mterry> attente, probably?
[13:51] <attente> mterry, sure
[14:40] <kenvandine> Laney, i got the wallpaper and updated it
[14:40] <kenvandine> Laney, but... the package fails to build with --fail-missing, which was already there
[14:41] <kenvandine> missing the translations
[14:41] <Laney> those are new
[14:41] <Laney> it's conceivable there could be problems there :-)
[14:41] <kenvandine> oh... the translations are new?
[14:41] <Laney> ya
[14:41] <Laney> well, I just turned it on in LP
[14:41] <kenvandine> i see
[14:41] <Laney> so they'll be newly exported to the branch now
[14:46] <kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-wallpapers/13_10/+merge/186813
[14:46] <kenvandine> Laney, ^^
[14:46] <kenvandine> mind giving that a review?
[14:46] <Laney> hah
[14:46] <Laney> I was getting ready to blame glib for a bug
[14:46] <Laney> but it turned out to be me :)
[14:46] <kenvandine> haha
[14:46] <kenvandine> there are no bugs in glib
[14:46] <kenvandine> :)
[14:47] <Laney> jbicha: who is ubuntu-docs now?
[14:49] <Laney> woo, proper space listing in u-s-s
[14:49] <Laney> desrt: what a GREAT API!
[14:50] <desrt> Laney: can i see the patch?
[14:50] <Laney> not yet
[14:51] <desrt> ah.  you're working on it?
[14:51] <Laney> yeah, need to report when it's in progress
[14:51]  * desrt is happy to see the fruits of his labours appreciated so rapidly
[14:51] <Laney> I don't think the way I used the async api from c++ is very nice
[14:51] <desrt> ah.  nice.  you're gonna do the progress?
[14:51] <Laney> just in progress/not
[14:51] <desrt> ah.  fair enough.
[14:52]  * desrt likes to see the counters go up as a form of progress reporting
[14:52] <Laney> could do that I suppose
[14:52] <Laney> but it'd be annoying to make that work with the bar thing
[14:52] <desrt> ya... seb said he didn't want progress reporting this way
[14:52] <jbicha> Laney: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-docs/saucy
[14:53] <desrt> i only added it because they want to use this API in nautilus and sushi now
[14:53] <Laney> fair enough
[14:54] <Laney> so I made a struct to pass as user_data to the callback function which contains the 'this' pointer, and a counter so we know when all of the operations are finished to emit the signal which updates the UI
[14:54] <Laney> seems janky
[14:58] <desrt> you're doing it for all of the user's documents/downloads/photos/videos/etc. folders?
[14:58] <Laney> videos/audio/pictures
[14:58] <desrt> if you want to report those as a single consolidated size, that's pretty much what you have to do, i figure
[14:59] <Laney> nah, individually
[14:59] <Laney> https://wiki.ubuntu.com/AboutThisDevice#phone-storage
[15:00] <desrt> interesting.
[15:00] <desrt> so do you show progress for the whole thing until you know all the answers?
[15:00] <desrt> or do you fill in each category as you find it?
[15:00] <Laney> I'm doing it all at once
[15:01] <desrt> i assume you also dispatch the async ops at the same time
[15:01] <Laney> ya
[15:01] <desrt> (which is a great idea from a performance standpoint btw)
[15:01] <desrt> you're pretty much doing it the correct way, then
[15:01] <Laney> I just keep a counter and when they're all in then fire off the event
[15:01] <Laney> which makes QML fetch the values again
[15:02] <Laney> ok, thanks
[15:02] <Laney> you can see the reality in a little while
[15:02] <desrt> i'll be happy to take a look.  gimme a ping.
[15:13] <tedg> desrt, Do you know of an easy way to go from PID to DBus bus name?
[15:13] <desrt> tedg: no.
[15:13] <tedg> I mean, clearly I can get the list and go through getting PIDs, but I was looking for something more elegant.
[15:13] <desrt> mostly because a given PID could have multiple bus names
[15:13] <tedg> Hmm, okay.
[15:14] <tedg> True, I'd take an array :-)
[15:14] <desrt> (and not just multiple well-known names.... but there could be multiple DBus libraries involved)
[15:14] <desrt> tedg: i think you'd pretty much need to iterate over all the names on the bus, asking for PIDs and do the reverse mapping
[15:14] <desrt> tedg: the good news is that it's only two roundtrips to do that...
[15:15] <tedg> desrt, ?  GetConnectionUnixProcessID only takes a string?
[15:15] <desrt> tedg: dispatch all of them at the same time
[15:15] <tedg> desrt, Seems I'd have to call it for each.
[15:15] <tedg> Oh, yes.
[15:15] <desrt> the art of dbus: look for ways to decrease roundtrips
[15:15] <tedg> I was thinking reducing messages.
[15:15] <desrt> ya.  you're stuck on that point, unfortunately
[15:15] <tedg> Still n messages.
[15:16] <desrt> messages don't matter as much as context switches
[15:16] <desrt> and in this case you're in luck, because you'll end up with fewer context switches than messages _and_ because you're talking to the bus daemon, so the number of switches is already halved
[15:16] <tedg> Multi-core FTW!  ;-)
[15:16] <desrt> ie: it's not that bad...
[15:17] <tedg> Naw, it's not.  But it's a little brute force.  Was hoping there was a lookup I didn't know about.
[15:17] <desrt> you could maybe propose a new API
[15:17] <desrt> what are you trying to do with it?
[15:17] <tedg> Unfortunately this is a "done by Tuesday" type of thing.
[15:17] <desrt> lol
[15:17] <tedg> Not time for that in v1.0
[15:18] <desrt> looking up bus names for PIDs seems slightly suspect...
[15:18] <tedg> It's okay, according the apparmor I'm "trusted" ;-)
[15:18]  * desrt needs to have a chat with apparmor
[15:18] <desrt>  (( "psst... don't you know this guy works for the NSA?" ))
[15:19] <tedg> It's clear Ubuntu needs to switch to SELinux so I'll be trusted again!
[15:19] <desrt> tedg: i mean it seems suspect from a code-smell standpoint
[15:20] <tedg> desrt, I agree, and I think we should add API for it.
[15:20] <tedg> desrt, But that'll obviously take longer than I have right now.
[15:20] <desrt> tedg: no... i mean the desire to map PIDs to busnames is suspect
[15:20] <tedg> desrt, But it can be hidden from users.
[15:20] <desrt> what are you trying to do?
[15:21] <tedg> desrt, Basically implement the org.freedeskop.Application calling on secondary activation for confined apps.
[15:21] <tedg> desrt, But I only know PIDs
[15:21] <desrt> why not just send a message to the well-known name?
[15:22] <tedg> Confined apps can't have well known names.
[15:22] <desrt> O_o
[15:22] <ochosi> robert_ancell: we tried to debug the restart-menuitem-missing bug in lightdm a bit more, it seems to return "challange" instead of "yes"
[15:22] <desrt> okay.  i don't want to know :)
[15:22] <ochosi> robert_ancell: when querying "gdbus call --system --dest org.freedesktop.login1 --object-path  /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanReboot"
[15:23] <robert_ancell> ochosi, huh, mine returns yes
[15:23] <robert_ancell> ochosi, it might be a PolicyKit issue
[15:23] <ochosi> robert_ancell: that call was run when logged out
[15:24] <ochosi> robert_ancell: when logged in, it also returns "yes" for me
[15:25] <desrt> tedg: how are you going to deal with processes that have multiple DBus connections?  introspection?
[15:26] <tedg> desrt, Haven't decided.  Trying to decide how evil it would be to just send the message to all and have them reject.
[15:26] <desrt> tedg: this is what i was talking about when i mentioned code smell :)
[15:28] <tedg> desrt, I think that this is probably something we could also add to the dbus daemon, a way to query the filters of a another process.  Then we'd get "introspection" at least enough to avoid many of these cases.  Though, definitely need to think about it more.
[15:28] <desrt> tedg: i think you should allow each confined app to own exactly one well-known bus name
[15:28] <desrt> ie: its ID
[15:29] <desrt> way easier to avoid these types of hacks this way
[15:29] <tedg> desrt, We can't because we don't want confined apps to see other confined apps on the system.  Also, which connection gets to be "the" connection?
[15:29] <desrt> tedg: whichever one claims the name first
[15:29] <desrt> same as normal dbus rules
[15:30] <desrt> except that you'd reject name ownership requests for anything but the one name that is allowed
[15:30] <tedg> But then for instance my HUD might not work because it's gdbus because my qtdbus connection was faster.
[15:30] <desrt> tedg: dbus doesn't work like that....
[15:30] <desrt> the connection that wants to have the well-known name has to request it
[15:31] <tedg> Sure, but if both of them need to be "the" connection.  Then they'll both request it.
[15:31] <desrt> no...
[15:31] <desrt> in the gapplication case if you have qtdbus coming up as well, only the gdbus connection will try to grab the app's well-known name
[15:31] <desrt> the qtdbus connection won't -- it will remain as having only the unique name
[15:31] <desrt> it doesn't matter which one comes up first
[15:31] <desrt> this is already happening in (probably) dozens of apps running on your system today
[15:31] <tedg> Sure, but let's say you're using GApplication and libubuntufoobar,which happens to want to be on "the connection" too.
[15:32] <tedg> The problem is identity.
[15:32] <tedg> They all want to be on "the" connection then.
[15:32] <desrt> tedg: well-known names are added to the connection _after_ it is opened (and maybe after it has been used for a while, by other parts of the process)
[15:32] <desrt> so it doesn't matter who brings up which connections, or by which library
[15:32] <desrt> the name won't be acquired until GApplication tries to grab it
[15:33] <tedg> I understand the dbus part here.  The issue is that both libubuntufoo and libubuntubar want to be on the connection with the well known name.
[15:33] <desrt> tedg: why?
[15:33] <tedg> If libubuntufoo uses a different dbus implementation than libubuntubar they can't both be there.
[15:33] <desrt> tedg: that's already a problem in existing dbus
[15:33] <tedg> Correct.  It is.
[15:33] <desrt> and it's not a problem that we've ever really .... had a problem with
[15:34] <tedg> So that's why having a wellknown name per-app doesn't help.
[15:34] <desrt> tedg: unless you're doing _exceptionally_ strange things with well-known names, this just isn't a problem
[15:34] <tedg> Well, there are work arounds in thing like libdee to deal with it...
[15:34] <desrt> tedg: not afaik?
[15:35] <desrt> libdee does fall into what i would consider an exceptionally strange use of well-known names, but it is pretty elegant, actually
[15:35] <tedg> Look at how libdee registers well known names... crazy.
[15:35] <desrt> libdee shares a wellknown name between multiple processes as a token
[15:35] <tedg> Yes.  I know.  And it gets a lot of robustness there as well.
[15:35] <desrt> indeed.  very elegant
[15:35] <desrt> but certainly not the sort of thing that GApplication is doing
[15:36] <desrt> and if you're forbidding well-known names entirely, you're going to break the dee case anyway
[15:36] <desrt> (which may be appropriate.  i'm not commenting on that)
[15:36] <tedg> Yup.  So anyway.  We're blocking well known names.  And I have to work around that in this case. :-)
[15:37] <tedg> Trying to make that not suck as much as possible.
[15:37] <desrt> it's going to suck lots :)
[15:37] <desrt> it's also going to be super-racy
[15:37] <desrt> but i guess that's the design choice you made....
[15:38] <tedg> We should a NoSQL-like thing where we upload javascript snipets to the dbus-daemon to execute to make things less racy.
[15:38]  * tedg solves all the problems
[15:38] <tedg> ;-)
[15:38] <desrt> we already have name activation.  it's pretty much the perfect tool to take care of what you're trying to take care of.
[15:39]  * desrt doesn't really feel like discussing this further
[17:54] <desrt> Laney: your use of a uint pointer is very strange here
[17:55] <desrt> also: it's evil how the list of 4 directories is coded in one place and the number (4) is elsewhere
[17:55] <desrt> rather you should have 'uint outstanding;' and do outstanding++ each time you issue a new async
[17:55] <desrt> then outstanding-- when each comes in
[17:58] <attente> mterry, i filed the FFe, do we basically just wait for someone from the release team to look at it?
[17:58] <mterry> attente, yeah.  I suppose I can review your branch in the mean time
[17:58] <attente> mterry, ok, thanks for your help
[17:59] <mterry> attente, you need to handle upgrade path in case someone set gsettings and ug-keyboard is still there
[18:00] <mterry> attente, and we no longer grab layouts from LightDM.  How does indicator-keyboard grab its list of available layouts?
[18:02] <attente> mterry, indicator-keyboard goes to accountsservice for the user's input sources
[18:03] <attente> for the upgrade path, i-keyboard is also taking the user's old keyboard layout settings and moving them to the correct gsettings key
[18:04] <attente> it shouldn't be possible for the user to have both ug-keyboard and i-keyboard together at the same time, if that's what you mean?
[18:04] <mterry> attente, sorry, when I said upgrade I meant with the unity-greeter patch  (i.e. please make "ug-keyboard" -> "keyboard"
[18:04] <mterry> attente, someone might end up with ug-keyboard in their indicator list still
[18:04] <attente> mterry, oh, ok, i misunderstood you, sorry
[18:04] <attente> i'll fix it
[18:06] <mterry> attente, menubar.vala:237.5-237.33: warning: method `MenuBar.cmp_layout' never used
[18:10] <mterry> attente, and add it to Recommends
[18:10] <attente> mterry, ok
[18:12] <Laney> desrt: that is a good idea
[18:12] <Laney> I knew it was evil but somehow didn't think of that
[18:19] <desrt> Laney: also not sure why you used a pointer there at all
[18:19] <Laney> instead of a class variable?
[18:25] <desrt> Laney: no... it should ... i'm confused :)
[18:26] <desrt> Laney: why didn't you just use 'uint' instead of 'uint*'?
[18:34] <Laney> desrt: it goes out of scope, or do you mean why not use uint in the struct? because I want to only emit the signal once so I'm sharing the counter
[18:34]  * Laney is off for now, maybe back later :-)
[18:35] <Laney> have good weekends