[07:29] <tsdgeos> mzanetti: ota6 is out? can we prepare the landing of all the big branches?
[07:33] <tsdgeos> mzanetti: pstolowski: did you land unity8 in silo 44?
[07:35] <pstolowski> tsdgeos, i marked it ready for qa, it hasn't landed yet
[07:35] <tsdgeos> ah ok
[07:40] <tsdgeos> mzanetti: is tagger you thing?
[07:41] <tsdgeos> seems it is
[08:55] <mzanetti> tsdgeos, yes
[08:56] <mzanetti> tsdgeos, can you check out this one when you have some time? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1489309
[08:56] <ubot5> Ubuntu bug 1489309 in unity8 (Ubuntu) "Names in Favorite Contacts are cut at the bottom" [Undecided,New]
[08:56] <mzanetti> tsdgeos, what up with tagger?
[08:56] <tsdgeos> so today i've found the first use case in history for it
[08:56] <mzanetti> hahaha
[08:56] <tsdgeos> though i guess our "security model" won't allow it
[08:56] <mzanetti> and it failed
[08:56] <mzanetti> :D
[08:56] <mzanetti> obviously
[08:56] <tsdgeos> my router has a tag beind it
[08:56] <mzanetti> tell me
[08:56] <tsdgeos> that you scan it
[08:56] <mzanetti> right
[08:56] <mzanetti> wifi
[08:56] <tsdgeos> and if you have an android or iphone will connect to that wifi with the password
[08:57] <tsdgeos> i got the text that i had to copy&paste
[08:57] <tsdgeos> was not horrible
[08:57] <mzanetti> I had that working on the N9[00|50]
[08:57] <mzanetti> but yes, apparmor
[08:57] <tsdgeos> yeah
[08:57] <tsdgeos> i said
[08:57] <tsdgeos> secure!
[08:57] <tsdgeos> it echo'ed trough the empty rooms of my apartment :D
[08:58] <mzanetti> :)
[08:59] <mzanetti> I'll start a mail thread... wanted to add this feature for a while already
[08:59] <tsdgeos> anyhow, do you think it' worth opening a bug against tagger+something else?
[09:00] <mzanetti> yes
[09:00] <mzanetti> I just need to highlight that the format how the wifi information is stored in the code was invented by google. that seems to confinve most people that it must be a good thing :D
[09:01] <tsdgeos> hmmm
[09:01] <tsdgeos> mzanetti: that's the today scope?
[09:01] <mzanetti> tsdgeos, yes
[09:01] <tsdgeos> i don't see that carousel
[09:02] <tsdgeos> home many contacts in favorites do i need?
[09:02] <tsdgeos> i've 4
[09:02] <tsdgeos> let's see if rebooting helps
[09:02] <mzanetti> no clue... I've just one
[09:02] <tsdgeos> and you see it in the today scope?
[09:02] <mzanetti> yes, but not as carousel
[09:02] <mzanetti> maybe you need to enable it in the settings of the scope
[09:02] <tsdgeos> i don't have anyting
[09:02] <tsdgeos> i have it enabled
[09:03] <mzanetti> up-to-date?
[09:03] <mzanetti> aparently there was an update to the today scope the other day
[09:03] <mzanetti> oh, I didn't mean to enable the scope, but the category in the scope. "Show entries from Contacts" or so
[09:04] <tsdgeos> yes yes
[09:05] <tsdgeos> ah, i needed to press the "skip and setup later"
[09:05] <tsdgeos> right i don't have a carousel either
[09:05] <tsdgeos> let me check the code i think we have some carousel auto conversion to list if < X
[09:07] <tsdgeos> hmmm not really, we fallback to grid
[09:07] <tsdgeos> which is weird
[09:07] <tsdgeos> maybe it's the scope doing the fallback
[09:07]  * tsdgeos adds more favourites
[09:34] <dandrader> greyback, this is the qtmir one-liner I need you to review: https://code.launchpad.net/~dandrader/qtmir/resizeSuspending/+merge/269207
[09:34] <tsdgeos> pstolowski: do you know where the code for the today scope/contacts subsection is?
[09:35] <tsdgeos> or who could know?
[09:35] <pstolowski> tsdgeos, cwayne?
[09:35] <greyback> dandrader: ok, LP reporting merge conflict tho
[09:36] <tsdgeos> pstolowski: k, tx
[09:36] <dandrader> greyback, saw that. seems false alarm. it's because of the mirSurface prerequisite
[09:36] <greyback> dandrader: okay
[09:37] <tsdgeos> mzanetti: i can't seem to get a carousel there
[09:37] <mzanetti> tsdgeos, the reporter says he has 6 contacts
[09:38] <mzanetti> in favorites
[09:41] <tsdgeos> i've 16 :D
[09:41] <tsdgeos> let me go back to 6
[09:49] <tsdgeos> nah no carousel
[09:49] <tsdgeos> maybe we killed it in ota6
[09:49] <tsdgeos> ?
[09:52] <mzanetti> tsdgeos, nope. have the carousel here now
[09:52] <mzanetti> tsdgeos, I just had to update the today scope tho
[09:52] <tsdgeos> update it on the store?
[09:53] <tsdgeos> or systemsettings :D
[09:54] <tsdgeos> ouch
[09:54] <tsdgeos> i need my 2FA that i left at the other house
[09:54] <mzanetti> tsdgeos, set up authenticator ;)
[09:55] <mzanetti> tsdgeos, in systemsettings
[09:55] <tsdgeos> mzanetti: but i'll still need the 2FA to do that no?
[09:55] <tsdgeos> anyway i was planning to go back before lunch
[09:55] <tsdgeos> may as well do it now
[09:55] <mzanetti> tsdgeos, well, this is not totally critical
[09:57] <tsdgeos> sure i understand
[09:58] <tsdgeos> still i need to go back for food, so can do it now or in ~1 hour :D may as well time it with the bus
[10:47] <mzanetti> dandrader, hey, saw your comment about the DeviceConfiguration
[10:47] <dandrader> mzanetti, which of the two?
[10:48] <mzanetti> dandrader, before he just had "property int ignoredMice: deviceConfiguration & deviceConfiguration.ignoredMice"
[10:48] <mzanetti> dandrader, that was reaching out of context so I asked him to fix
[10:48] <mzanetti> dandrader, the other option would be to pass a pointer to the deviceconfiguration (or an integer of the ignoredMice) around throughout the whole notifications system
[10:49] <mzanetti> what would be your favorite?
[10:50] <mzanetti> imo the singleton is quite nice for this... I also think we'll need deviceConfig stuff in more places in the near future
[10:50] <mzanetti> but you can obviously propose something nicer...
[10:51] <mzanetti> in regard to move vs delete/add, you're obviously right
[10:51] <dandrader> mzanetti, maybe it could have the higher level info it wants, intead of going into the nasty details of checking how many mouse devices are available and how many should be ignored
[10:52] <mzanetti> dandrader, yeah... thought about that too
[10:52] <dandrader> mzanetti, I didn't properly review it. that's why it's just a comment withou a review decision
[10:52] <mzanetti> but then I'm not really sure what
[10:52] <dandrader> mzanetti, but on a first look I didn't like this
[10:53] <dandrader> mzanetti, is in it couples the Notificaions component to both DeviceInfo and DeviceConfiguration
[10:53] <mzanetti> mhm
[10:54] <mzanetti> but passing those things through a chain of files kinda sucks too
[10:54] <dandrader> mzanetti, but I would need some time to try to come up with a proposal
[10:54] <mzanetti> I'm not saying you're wrong... just that I'm not sure about something better right now
[10:54] <mzanetti> yeah..
[10:54] <mzanetti> maybe lukas has an idea
[10:55] <tsdgeos> mzanetti: so next silo has the big MRs of sdk13, quick24?
[10:56] <mzanetti> tsdgeos, no :(
[10:56] <tsdgeos> oh :/
[10:56] <tsdgeos> why?
[10:57] <mzanetti> tsdgeos, didn't get the "ok, let's move to 1.3 yet"
[10:57] <mzanetti> but will poke people about it again now
[10:57] <tsdgeos> grrr
[10:57] <tsdgeos> ok, correct, the updated today scope gives me a carousel
[10:57] <tsdgeos> which is weird since i remember design saying they didn't seem to like carousels anymore
[11:00] <tsdgeos> anyway off to debug
[11:03] <dandrader> mzanetti, it's like sweeping the problem under the carpet
[11:04] <dandrader> mzanetti, by accessing stuff over various singletons you're giving the illusion that your component is modular
[11:04] <dandrader> mzanetti, "hey, I can just add Notifications {} to my shell and it just works!"
[11:04] <mzanetti> dandrader, fair point, yes
[11:05] <dandrader> mzanetti, whereas in reality it needs a bunch of info from the context that it's getting by other means
[11:05] <dandrader> mzanetti, and if this context changes, it will break the component
[11:06] <dandrader> mzanetti, not very diffent from accessing variables from some parent that are available in the context
[11:06] <mzanetti> hmm... a bit better I'd say
[11:06] <mzanetti> because if it's not there it'll fail to compile
[11:06] <mzanetti> with the other it just breaks at runtime, maybe
[11:07] <mzanetti> but sure, I see your point
[11:07] <dandrader> mzanetti, yes, it's better. that's why I said "not very different" instead of "the same as"
[11:11] <dandrader> mzanetti, exposing the info in properties makes the dependencies obvious and exposes how modular you component truly is. hopefully making it easier to refactor APIs, so you could rearrange responsibilities to have a better, more modular, design
=== MacSlow is now known as MacSlow|lunch
=== alan_g is now known as alan_g|lunch
[12:44] <tsdgeos> food!
=== alan_g|lunch is now known as alan_g
[13:48] <mzanetti> dandrader, so... I've tested the mirSurface branch again, and the orientation thing is worse than with trunk. and it is one of the reasons why QA rejected it the first time.
[13:48] <mzanetti> do you have a fix for that handy?
[13:48] <mzanetti> greyback, other than that, are you happy with the mirSurface branches?
[13:48] <greyback> mzanetti: yeah I am
[13:49] <dandrader> mzanetti, lp:~dandrader/qtubuntu/resizeCatchUp and lp:~dandrader/qtmir/resizeSuspending
[13:49] <mzanetti> greyback, can you approve them ?
[13:50] <greyback> mzanetti: yep, going through them again now
[13:51] <mzanetti> greyback, please include those last two. I'll add them to the same silo
[13:51] <greyback> ack
=== MacSlow|lunch is now known as MacSlow
[14:12] <tsdgeos> greyback: ping
[14:17] <greyback> tsdgeos: pong
[14:18] <tsdgeos> greyback: do you know what sets the mir host-socket to /run/mir_socket ?
[14:18] <greyback> tsdgeos: that is unity-system-compositor's socket, set in its upstart job
[14:19] <greyback> tsdgeos: the unity8 socket is $XDG_RUNTIME_DIR/mir_socket
[14:19] <greyback> also set in its upstart file
[14:21] <tsdgeos> greyback: can't find usc upstart job, know the name?
[14:27] <Saviq> tsdgeos, not upstarted, it's in the session
[14:28] <Saviq> tsdgeos, dpkg -L ubuntu-touch-session
[14:28] <tsdgeos> k tx
[14:28] <Saviq> /usr/share/ubuntu-touch-session/usc-wrapper is what launches usc
[14:30] <greyback> tsdgeos: what Saviq said, my apologies
[14:30] <tsdgeos> sure, no worries
[14:31] <greyback> tsdgeos: if it's not set, mir does choose either /run/.. or /tmp/.. as the socket
[14:31] <greyback> dednick: ping!
[14:32] <dednick> greyback: hey
[14:32] <greyback> dednick: hey, welcome back. When you're caught up, ping me
[14:33] <greyback> you have a bunch of pre-holiday branches I've reviewed
[14:33] <dednick> greyback: cool. i'll take a look and get back to you
[14:33] <greyback> dednick: cheers
[14:39] <greyback> tsdgeos: I've a theory on the unity8 restart problem. You're in the right direction with the socket being wrong.
[14:40] <tsdgeos> it is wrong
[14:40] <tsdgeos> i've verified that
[14:40] <tsdgeos> i *just* need to know where it gets wrong :D
[14:40] <greyback> I think it's possible for upstart to restart the unity8 job *before* the "stopping" phase of the previous unity8 job has run
[14:41] <greyback> as the stopping phase does the env var cleanup, it would mean the new unity8 gets old env vars
[14:42] <tsdgeos> greyback: ted told me that's not possible, but might happen :D
[14:45] <ted> tsdgeos, I think I might have been wrong, it seems that post-stop isn't run on a restart: http://upstart.ubuntu.com/cookbook/#restart
[14:45] <tsdgeos> oh
[14:45] <tsdgeos> that'd be bad
[14:45] <ted> tsdgeos, And probably more important to unity8, no pre-start or post-start
[14:50] <dednick> greyback: hm. don't know what the hell happened with my touch tracing branch. looks like it didnt push properly...
[14:50] <greyback> dednick: uh oh
[14:51] <dednick> greyback: i've re-pushed it. seems ok now.
[14:51] <greyback> coolio
[14:51] <dednick> greyback: what other branches did you review?
[14:52] <greyback> dednick: the polite app close stuff I think had open comments - and I suspect merging trunk will cause you pain
[14:52] <dednick> greyback: oh hang on. i forgot i moved the touch tracing to unity-team. was looking at old one..
[14:55] <dandrader> greyback, could you please trigger a rebuild of qtmir in silo0?
[14:55] <dandrader> or can I do it myself?
[14:55] <greyback> dandrader: are you on the landing team?
[14:56] <dandrader> greyback, don't think so
[14:56] <greyback> I'd better do it then
[14:57] <greyback> dandrader: why does it need a rebuild? You've just added a debug output. If you're debugging, build it locally please
[14:59] <greyback> mzanetti: you tested the mirSurface stuff then? I just need to check the code again?
[15:02] <dandrader> greyback, because of this https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1488417/comments/13
[15:02] <ubot5> Ubuntu bug 1488417 in qtmir (Ubuntu) "nexus4 window mode mouse motion bounded incorrectly" [Undecided,In progress]
[15:03] <dandrader> greyback, make it easier for others to reproduce
[15:03] <dandrader> greyback, and duflu has been denying it's a mir issue
[15:04] <tsdgeos> ted: funnily that doc is wrong and they get executed
[15:04] <tsdgeos> since the echos i've added get printed
[15:04] <tsdgeos> confusion!
[15:05] <ted> tsdgeos, Uhg, fun!
[15:08] <greyback> dandrader: reasons I hesitate are: (1) train will try to merge lp:qtmir into silo0, which fails as there's conflicts and I don't want to waste time on that (2) you're adding a debug flag to help you prove a point, when there should be a much easier way to reproduce the bug
[15:10] <dandrader> greyback, don't agree with the "there should be a much easier way to reproduce the bug" part
[15:10] <dandrader> greyback, but ok, let duflu build qtmir himself if he wants to follow those steps
[15:11] <dandrader> greyback, and this log should go to trunk at some point
[15:11] <greyback> dandrader: sure
[15:12] <seb128> ted, I opened mps for the indicators/unity8 https://code.launchpad.net/~seb128/indicator-session/unity8-system-settings https://code.launchpad.net/~seb128/indicator-bluetooth/unity8-system-settings https://code.launchpad.net/~seb128/indicator-power/unity8-system-settings https://code.launchpad.net/~seb128/indicator-datetime/unity8-system-settings https://code.launchpad.net/~seb128/indicator-sound/unity8-system-settings
[15:12] <seb128> ted, would be nice if you have a glance, would like review so I can fix today before being on vac if needed
[15:13] <ted> seb128, K, we should make sure charles is in the loop as well.
[15:13] <charles> woo
[15:13] <charles> in a meeting at the moment, will look at the mps rsn
[15:22] <charles> seb128, LGTM, thanks for the patches
[15:28] <seb128> charles, yw! thanks for looking
[15:30] <mzanetti> dandrader, greyback: this is tag-infected: https://code.launchpad.net/~dandrader/qtmir/resizeSuspending/+merge/269207
[15:31] <mzanetti> I cleaned qtmir trunk yesterday night
[15:31] <mzanetti> still not entirely clear how it is possible for those tags to jump repositories
[15:32] <dandrader> mzanetti, it's a virus!
[15:32] <mzanetti> it's like the bird-virus starts infecting cats now...
[15:32] <dandrader> mzanetti, cleaning up the tags now
[15:32] <mzanetti> dandrader, tested the silo. IMO good. as soon as the last qtubuntu branch is approved I'll submit to QA
[15:36] <ted> Man, charles is too fast!
[15:37] <dandrader> mzanetti, done the tag cleaning
[15:37] <mzanetti> ta
[15:41] <dandrader> greyback, updated https://code.launchpad.net/~dandrader/qtubuntu/resizeCatchUp/+merge/269195
[15:43] <greyback> dandrader: there's still lots of unnecessary changes. DASSERT/Q_ASSERT, removing DLOG.. yes they're good to fix up, but in a separate MR.
[15:43] <greyback> as this resizeCatchUp stuff is a workaround, ideally we'll just revert this branch when mir is fixed
[15:50] <dandrader> greyback, done
[15:55] <tsdgeos> greyback: mzanetti: ted: don't ask me why, but this fixes it https://code.launchpad.net/~aacid/unity8/fix_upstart_restart/+merge/269399
[15:56] <mzanetti> interesting
[16:00] <ted> Not sure I understand that.
[16:01] <ted> Perhaps a "sleep .1" too ;-)
[16:01] <greyback> tsdgeos: yeah I'm not clear on it either, but if it improves things, let's just take it
[16:02] <tsdgeos> ted: ...
[16:02] <ted> …
[16:15] <greyback> mzanetti: all MRs for silo23 are approved, qtubuntu needs a rebuild tho
[16:16] <mzanetti> greyback, ack, thanks
=== alan_g is now known as alan_g|EOD