[08:02] <Zhenech> argh
[08:03] <Zhenech> could someout please ban him?
[08:22] <Saviq> mzanetti, tsdgeos (I'm not really here), I fwd'ed you an email from bfiller about the people lens
[08:22] <tsdgeos> yeah he was complaining yesterday
[08:22] <mzanetti> hehe, about?
[08:22] <Saviq> if one of you (or greyback, when he comes online)
[08:22] <tsdgeos> there seems to be something randomly broken about the hud too
[08:22] <tsdgeos> works and then it doesn't
[08:22] <tsdgeos> and then i flash
[08:22] <Saviq> can take a look at our options
[08:22] <tsdgeos> and it doesn't and then it does
[08:22] <mzanetti> tsdgeos: ah right... I noticed the HUD breakage too yesterday
[08:23] <tsdgeos> and i can't pinpoint why or what makes it work or not work
[08:23] <Saviq> mzanetti, tsdgeos, one more option to add to bfiller's list is to just limit the amount of contacts displayed in the people lens
[08:23] <Saviq> and require to search for more
[08:24] <mzanetti> Saviq: ok... we'll check it out. go back to bed ;)
[08:24] <mzanetti> or wherever you came from :P
[08:24] <Saviq> mzanetti, tsdgeos, ping me if needed, I'll try and check in once in a while
[08:24] <mzanetti> Saviq: have a nice weekend btw
[08:26] <mzanetti> tsdgeos: not sure how much you are involved there (I guess not at all) but hud-service goes wild here all the time.
[08:27] <mzanetti> tsdgeos: who would be the right one contact on that one?
[08:27] <tsdgeos> ted
[08:27] <Saviq> mzanetti, thanks
[08:29] <mzanetti> pff... hundreds of contacts... who needs that anyways :P I use like 4 of the 30 I have in my address book :D
[08:32] <tsdgeos> +1
[08:32] <mzanetti> anyone got a dummy database I could use for testing?
[08:32] <tsdgeos> i have billions of contacts since the Z10 imports all my facebook, twitter and linkedin contacts onto the phone
[08:32] <tsdgeos> use 3 of the favorites :D
[08:33] <mzanetti> yeah... my jabber contact list is actually much longer than the phone address book (I just realized now)
[08:34] <tsdgeos> mzanetti: i'd go with Saviq's suggestion and limit the number of contacts to show to what we have now
[08:35] <mzanetti> tsdgeos: you know the LVWPH by now... couldn't we add a hack that it actually does not show in full height and only when scrolling down to lets say 80% of the visible height actually expand it at the bottom while shrinking at the top?
[08:35] <mzanetti> tsdgeos: the issue definitely memory usage because of our LVWPH
[08:35] <tsdgeos> don't touch the LVWPH
[08:36] <mzanetti> haha
[08:36] <tsdgeos> not even with a long stick
[08:36] <Saviq> can we ban morphis?
[08:36] <tsdgeos> it will stick to you and you won't know how to unstick it :D
[08:36] <tsdgeos> Saviq: if you know anyone with ops
[08:36] <Saviq> tsdgeos, mzanetti yeah, that would mean we'd maintain the most functionality
[08:36] <Saviq> you'd still be able to access all of your contacts (via search)
[08:36] <tsdgeos> and should be "easy"
[08:36] <Saviq> tsdgeos, one liner
[08:37] <Saviq> or so
[08:37] <tsdgeos> we just need a LimitProxyFilter somewhere
[08:37] <Saviq> tsdgeos, it's there already
[08:37] <Saviq> tsdgeos, but disabled
[08:37] <tsdgeos> lol :D
[08:37] <tsdgeos> ok
[08:37] <mzanetti> actually... can't we just enable that collapsing button?
[08:37] <mzanetti> I guess thats what you meant saviq
[08:37] <Saviq> mzanetti, not really, uncollapsing => all contacts, die!
[08:38] <Saviq> mzanetti, uncollapsing doesn't (yet) move the responsibility to the inner FilterGrid
[08:38] <Saviq> mzanetti, it just unfilters in place
[08:39] <mzanetti> ok...
[08:40] <Saviq> mzanetti, tsdgeos "filter: true; collapsedRowCount: 50 / columns" or similar in PeopleFilterGrid should do
[08:43] <mzanetti> nic-doffay: did you solve the bug from yesterday?
[08:43] <nic-doffay> mzanetti, yeah pete did.
[08:44] <mzanetti> nic-doffay: what was it?
[08:44] <mzanetti> nic-doffay: like I assumed?
[08:44] <nic-doffay> Some stuff had to be moved to the signals.
[08:44] <nic-doffay> mzanetti, ^
[08:44] <nic-doffay> mzanetti, I've committed a bit more code for the gradient.
[08:44] <nic-doffay> Mind taking a look later today and giving any additional comments?
[08:44] <mzanetti> nic-doffay: sure
[08:45] <nic-doffay> I think that's the last feature the infographics are going to need.
[08:45] <mzanetti> let me just fix the people lens (unless tsdgeos is already on it)
[08:47] <tsdgeos> mzanetti: all yours
[08:47] <mzanetti> tsdgeos: ack
[08:59] <mhr3> sil2100, didrocks, any idea what's wrong with the utah and powerpc builds?
[08:59] <mhr3> see http://<IP_ADDRESS>:8080/job/cu2d-unity-head-2.1build/lastBuild/console
[08:59] <mhr3> 2013-05-31 05:15:26,624 ERROR powerpc: Build powerpc build of unity-lens-music 6.9.0daily13.05.31ubuntu.unity.next-0ubuntu1 in ubuntu raring RELEASE (https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4629566) failed because of Failed to build
[08:59] <mhr3> and clicking that gives a successful build
[08:59] <didrocks> mhr3: I think sil2100 relaunched it
[08:59] <didrocks> mhr3: seems a package build issue
[09:00] <didrocks> like architecture mismatch
[09:00] <mhr3> didrocks, why are those failing in the first place though?
[09:00] <mhr3> it's not the first time
[09:00] <didrocks> mhr3: yeah, I know, I ask Mirv to investigate, there should be a arch: any/all somewhere
[09:00] <didrocks> but not in the first generation, in a deeper one
[09:00] <didrocks> liek a dep of a dep
[09:01] <mhr3> didrocks, k, good to know it's being dealt with, can someone relaunch the utah ap checking?
[09:01] <didrocks> mhr3: I think sil2100 forced the publication, let's wait for him
[09:04] <mhr3> didrocks, btw what does cu2d stand for? :)
[09:06] <didrocks> mhr3: Canonical Upstream To Distro ;)
[09:12] <mhr3> aaah :)
[09:13] <Mirv> mhr3: well I didn't find the cause or arch:any/all, but still it's the most probable explanation why the failures happen at the time of an libunity update
[09:16] <Mirv> so still needs investigation
[09:22] <greyback> mzanetti: hey there. Thoughts on the people lens bug? It's definitely not a simple fix
[09:22] <smspillaz> Mirv: sil2100: do either of you know if there's a script around somewhere to spawn autopilot in a lightdm --test-mode xeyphr session ?
[09:22] <smspillaz> I just stumbled upon that --test-mode thing, thought it could almost be extended to run the AP tests too
[09:26] <sil2100> smspillaz: hi, hm, sadly I never used --test-mode before, so no idea here - maybe thomi tried that in the past?
[09:26] <smspillaz> sil2100: try it ;-)
[09:27] <smspillaz> sil2100: you can launch a guest session of ubuntu with xephyr + llvmpipe
[09:28] <mzanetti> greyback: I'm on it... we'll just limit it to 50 people for now
[09:28] <smspillaz> sil2100: maybe I'll look into that tonight ... could be helpful for running AP tests without having to go through the install / reset settings rigamoroll
[09:30] <greyback> mzanetti: ok
[09:32] <mzanetti> greyback: https://code.launchpad.net/~mzanetti/unity/phablet-max-50-people/+merge/166729
[09:33] <greyback> mzanetti: on it
[09:38] <greyback> mzanetti: would you have time for https://code.launchpad.net/~gerboland/unity/refactor-wm-and-test/+merge/166524 ?
[09:39] <mzanetti> greyback: wow... long one. yeah. can do it
[09:40] <greyback> mzanetti: unfortunately yeah, it's a bit long. But it's mostly just moving code around, and then 2 big tests.
[09:42] <mzanetti> nic-doffay: looks fine
[09:42] <mzanetti> the gradient-thing that is
[09:43] <greyback> mzanetti: I also have this bugfix, which I need to get in today: https://code.launchpad.net/~gerboland/unity/fix-shell-focus-on-app-close/+merge/166545
[09:44] <mzanetti> greyback: yay. nice one
[09:50] <mzanetti> greyback: testing the fix-shell-focus:
[09:50] <mzanetti> greyback: the actual fix works fine, but:
[09:50] <mzanetti> greyback: when you have an app open and launch a second one, it will switch to the first one and only afterwards switch to the second one
[09:51] <mzanetti> greyback: I know that has been there before, but I have the impression it got a bit worse with your branch
[09:51] <mzanetti> not sure if its related at all tho. still quite ugly. do you think that could be fixable too?
[09:52] <Mirv> smspillaz: nope, sadly doesn't ring a bell. but thomi indeed could know.
[09:57] <greyback> mzanetti: I'll have a look
[09:58] <mzanetti> greyback: I commented on the MP too
[09:58] <greyback> mzanetti: thanks
[09:58] <smspillaz> Mirv: actually, looks not-so-workable to me
[09:58] <smspillaz> Mirv: it doesn't look like there's a straightforward way to get the services to launch with the correct environment variables
[09:58] <smspillaz> they launch in the parent x session and not the xephyr one
[09:58] <smspillaz> that's a shame though, unity works perfectly fine inside of xephyr otherwise
[10:01] <smspillaz> though you *can* hack around it by relaunching the panel service inside of the xephyr session ...
[11:05] <mzanetti> greyback: done with the review
[11:05] <greyback> mzanetti: thank you. I'm slow, need to reflash the phone
[11:07] <tsdgeos> who knows about dee stuff here?
[11:07] <tsdgeos> seems the hud problem i am having is a dee regression/behaviour change
[11:08] <seb128> tsdgeos, mhr3
[11:08] <tsdgeos> mhr3: hello
[11:08] <mhr3> tsdgeos, hey
[11:08] <tsdgeos> mhr3: so i am debugging a regression in the hud
[11:09] <tsdgeos> and have found that the model we are using for the results sometimes tells me it has 0 columns, even if synchronized says true
[11:09] <tsdgeos> and then latr if i say "come on it can't be you have 0 columns" and ask how many columns it has
[11:09] <tsdgeos> correctly tells me it has 8
[11:10] <tsdgeos> is there a new signal for number of columns changed or something we should be listening to?
[11:11] <mhr3> tsdgeos, first things first, i suppose hud is the owner of the model and you're the client
[11:11] <tsdgeos> yes
[11:11] <Saviq> paulliu, mzanetti is already on the people lens bug
[11:11] <mhr3> tsdgeos, is hud up by the time you try to synchronize the model?
[11:11] <paulliu> Saviq: ok.
[11:11] <paulliu> Saviq: Why I cannot access that bug report?
[11:12] <mhr3> tsdgeos, cause if it isn't you become the owner and you're expected to define the schema
[11:12] <Saviq> paulliu, not sure, it should be public, let me see
[11:12] <mhr3> tsdgeos, and when you do become the owner the model is considered synchronized
[11:12] <Saviq> paulliu, public now
[11:12] <tsdgeos> mhr3: it is, since it's telling me which model to use (i.e. i do a give me the results model name call first)
[11:13] <mhr3> tsdgeos, could you make sure with dee_shared_model_is_leader?
[11:13] <tsdgeos> mhr3: sure, let me try
[11:14] <mhr3> the value of that when you see 0 columns is the interesting data point
[11:16] <tsdgeos> ok, building the package
[11:16] <tsdgeos> will take 5-10 mins
[11:16] <mhr3> k
[11:19] <paulliu> Saviq: yeah. I can see it now. So my permission is a bit weird I think.
[11:19] <Saviq> paulliu, it was private and owned by a team you weren't part of it seems
[11:19] <paulliu> Saviq: ok
[11:22] <tsdgeos> mhr3: it seems i'm the leader
[11:22] <tsdgeos> DeeListModel(0x1fc9298) DeeListModelPrivate::createRoles numColumns 0
[11:22] <tsdgeos> DeeListModel(0x1fc9298) DeeListModelPrivate::createRoles isLeader 1
[11:23] <tsdgeos> that's bad, right?
[11:23] <tsdgeos> or isn't?
[11:23] <mhr3> well, yes and no
[11:23] <tsdgeos> ok :D
[11:24] <greyback> :)
[11:24] <mhr3> it's doesn't break everything, the hud will become non-leader of the model, but it can still write to it and you will get everything
[11:25] <mhr3> the only problem really is that you don't get the schema right away
[11:25] <tsdgeos> right
[11:25] <tsdgeos> so why am i the leader?
[11:25] <mhr3> so the simple fix is to set the schema yourself when you become a leader
[11:25] <tsdgeos> does it mean i'm connecting earlier than the hud to the name the hud just gave me?
[11:25] <mhr3> afterall you must know what schema you expect
[11:26] <tsdgeos> mhr3: actaully i kind of don't
[11:26] <tsdgeos> since this is an intermediate layer
[11:26] <tsdgeos> hud-client -> dee-qt -> dee
[11:26] <mhr3> hmm
[11:26] <tsdgeos> i mean i could add api in dee-qt so the users gave him the number of columns, but that defeats the point of having a get_columns call :D
[11:27] <mhr3> they changed the way names are owned in glib that made this happen in R+
[11:28] <tsdgeos> mhr3: is there any way the model can tell me the schema has changed?
[11:28] <mhr3> hmm, let me check if something is emitted
[11:34] <mhr3> tsdgeos, ok, so if you become the leader the schema will be set only once you receive a change from the other peer (that did set the schema)
[11:35] <tsdgeos> any way for me to not become the leader? other than waiting some time?
[11:38] <mhr3> tsdgeos, easiest would be for hud to not reply with the model name until it actually acquires it
[11:39] <tsdgeos> makes sense
[11:39] <tsdgeos> mhr3: is this thing new? i mean this worked forever, were we just lucky?
[11:40] <mhr3> tsdgeos, or use private (non-dbus) connection, that one should be synchronous still :)
[11:40] <mhr3> tsdgeos, as i said, glib slightly changed the way names are owned (it's more async now than it used to be)
[11:40] <tsdgeos> he he
[11:40] <tsdgeos> i see
[11:41] <tsdgeos> ted: wakeup!
[11:45] <Saviq> popey, « perl -p -i -e 's/false/true/' » yikes!
[11:46] <Saviq> ;)
[11:46] <tsdgeos> mhr3: this is what the hud does http://paste.ubuntu.com/5719648/ doesn't that guarantee it will be the leader?
[11:47] <tsdgeos> it does *before* returning query->results_name via dbus to me
[11:47] <popey> Saviq: I know, awesome isn't it ☻
[11:47] <popey> there's only one occurance and it doesn't have /g ☻
[11:47] <popey> (for now)
[11:48] <mhr3> tsdgeos, nope, it's the same thing, you can't tell unless the model gets synchronized
[11:49] <tsdgeos> mhr3: so what's the easy way to guarantee it'll be the leader? busy loop on dee_shared_model_is_leader ?
[11:50] <mhr3> tsdgeos, there's a prop that says "i *really* want to be the leader, if someone else is, steal the leadership from them"
[11:51] <tsdgeos> but that won't help me either
[11:51] <mhr3> tsdgeos, but then you'd see that you become a leader, and then loose the leadership a tiny while later
[11:51] <tsdgeos> dee-qt is basically built around the assumption that when a model is synchronized the schema is set
[11:51] <tsdgeos> and that's failing here because somehow the client is the leader
[11:51] <mhr3> well, that assumption is wrong :)
[11:52] <tsdgeos> is there no prop to say (i don't want to be the leader, wait until the leader is there) :D
[11:52] <tsdgeos> well, it seemed to work well until now :D
[11:52] <mhr3> unfortunately no, but yes maybe we should add that
[11:52] <tsdgeos> not that i'm the dee-qt original coder anyway
[11:52] <tsdgeos> i mean i can workaround the problem easily
[11:52] <tsdgeos> rechecking for the number of columns "often"
[11:53] <tsdgeos> but that's not cool :D
[11:53] <popey> Saviq: fixed ㋛ http://bazaar.launchpad.net/~popey/+junk/phablet-flash-wrapper/view/head:/add_apps.sh
[11:53] <mhr3> i do agree that dee-qt should be definitely able to tell when a model is "ready"
[11:53] <mhr3> or any dee client really
[11:54] <tsdgeos> yep, that's my main problem at the moment
[11:55] <tsdgeos> mhr3: previously you said " if you become the leader the schema will be set only once you receive a change from the other peer", that's actually fine for me (at this moment) if i get some signal that tells me the schema changed
[11:55] <tsdgeos> does such signal exist?
[11:55] <mhr3> by change i meant row-added/removed/changed
[11:55] <paulliu> Hi. Does anyone know where is the source code of ChewieUI? I need to dig into that part.
[11:56] <tsdgeos> paulliu: try asking renato_ in #ubuntu-touch
[11:56] <paulliu> tsdgeos: ok.
[11:57] <mhr3> tsdgeos, we could also try to flush the dbus connection after own_name call, that should theoretically fix it too
[11:57] <tsdgeos> mhr3: ok, so i guess i could re-check the column number on the first row-added
[11:57] <mhr3> but all of these fixes are adding blocking io, and that no good
[11:58] <mhr3> tsdgeos, the "clean" fix is really for hud to return the name only after the model is synchronized
[11:58] <tsdgeos> mhr3: agreed, but that also adds blocking io on the hud, no?
[11:59] <tsdgeos> or should the hud wait for "notify::synchronized" and then return the name?
[11:59] <tsdgeos> that makes sense
[11:59] <tsdgeos> mhr3: ↑↑↑
[11:59] <mhr3> not necessarily, it can wait for the synchronized signal asynchronously
[11:59] <mhr3> right ^^
[11:59] <tsdgeos> gotcha
[12:00] <tsdgeos> ok, let's wait for texas then
[12:01] <mhr3> hmm, was just checking gio changes and there's nothing in name owning itself, so it's either a more complex message scheduling change in gio or something even deeper (in dbus-daemon itself?)
[12:50] <dandrader> greyback, FIY: just proposed my changes to Stage.qml -> https://code.launchpad.net/~dandrader/unity/phablet_edgeDragInStage/+merge/166777
[12:50] <greyback> dandrader: thanks :)
[13:15] <mzanetti> dandrader: ping
[13:16] <dandrader> mzanetti, pong
[13:16] <mzanetti> dandrader: hey, I'm updating the launcher tests but the DDA doesn't seem to do anything. I guess I need to enable that mousetouch thingie for it to work, right?
[13:16] <dandrader> mzanetti, you have to send touch events, not mouse events
[13:17] <mzanetti> dandrader: can I enable that mouse->touch conversion for qmlscene somehow?
[13:17] <dandrader> mzanetti, no
[13:17] <mzanetti> dandrader: hmm... so the all tests involving a DDA won't work in qmlscene any more then
[13:17] <dandrader> mzanetti, to manual test on the desktop we might need to do our own qmlscene equivalent :(
[13:17] <mzanetti> ok, I see
[13:18] <dandrader> what I was doing as a quick hack was replacing Shell.qml in main.cpp with the qml I wanted to try out manually with touch events on the desktop
[13:18] <mzanetti> oh... thats useful
[13:18] <mzanetti> thanks
[13:18] <mzanetti> can you hint me how to do touch events in tests?
[13:19] <dandrader> mzanetti, http://bazaar.launchpad.net/~dandrader/unity/phablet_edgeDragInStage/revision/715
[13:19] <dandrader> mzanetti,  check tests/qmltests/Components/tst_Stage.qml  and tests/utils/modules/Unity/Test/UnityTestCase.qml  there
[13:19] <dandrader> mzanetti, and also the existing tst_Launcher test
[13:20] <dandrader> mzanetti, btw, were you able to work around that "Flickable on top of DDA" issue?
[13:20] <mzanetti> dandrader: yes... I disable the DDA as soon as the launcher is revealed
[13:20] <mzanetti> dandrader: and have a second MouseArea for hiding the launcher again
[13:21] <mzanetti> dandrader: so the DDA is only used to start revealing and then sits there being disabled
[13:21] <mzanetti> dandrader: ah... and I found a bug.
[13:22] <mzanetti> dandrader: https://code.launchpad.net/~mzanetti/unity/phablet-folding-launcher/+merge/166000
[13:22] <mzanetti> dandrader: Its fixed in there... you might want to check it to see if the fix is ok
[13:25] <dandrader> mzanetti, well, the definition of the "dragging" property is "Whether a drag gesture is taking place (regardless of whether it's a correct single-finger directional drag or not)"
[13:26] <mzanetti> dandrader: bug dragging == (Undecided || Recognized)
[13:26] <dandrader> mzanetti, which maps to "as long as DDA is holding some touch points"
[13:26] <mzanetti> dandrader: => Rejected == !dragging
[13:27] <mzanetti> dandrader: so current state in trunk is not consistent... if you're not happy with my fix you need to change dragging()
[13:27] <dandrader> mzanetti, I think that "Rejected == !dragging" would be true if DDA got rid of his touch points once reaching Rejected state, which currently doesn't happen
[13:27] <mzanetti> dandrader: if you change dragging() I would need a new property that does what dragging currently does including a signal
[13:29] <dandrader> ah, yeah the dragging() method. I recall I had the very same discussion with Saviq and he wanted it to be like you suggest
[13:29] <dandrader> mzanetti, majority wins. So please also update the documentation of the dragging property
[13:29] <mzanetti> dandrader: well, I could probably replace the usage of dragging with checks on status... but currently dragging does exactly what I need... when dragging == true, I need to show the launcher, when dragging == false I need to hide again
[13:29] <Saviq> \o/
[13:29] <mzanetti> hehe
[13:31] <dandrader> mzanetti, it might make sense to update DDA's tests to check for the emission of draggingChanged when rejected is reached....
[13:32] <mzanetti> dandrader: ok
[13:33] <greyback> Saviq: dude, you're on holiday, go away
[13:33] <Saviq> greyback, I am away
[13:33] <mzanetti> nic-doffay: standup?
[13:33] <Saviq> ← see
[13:33] <greyback> Saviq: for someone away, you're remarkably responsive
[13:34] <nic-doffay> mzanetti, one sec
[13:34] <nic-doffay> need to grab my mic and all
[13:50] <paulliu> tsdgeos: https://code.launchpad.net/~paulliu/unity/i18n/+merge/166765
[13:50]  * tsdgeos clicks
[13:57] <tsdgeos> mzanetti: i may have to do a HUD change, ping me before you do the release
[13:58] <greyback> mzanetti: updated https://code.launchpad.net/~gerboland/unity/fix-shell-focus-on-app-close/+merge/166545
[13:58] <greyback> mzanetti: expect about 30 minutes for a fix for the flicker
[14:02] <mzanetti> awesome
[14:02] <mzanetti> dandrader|afk: do you think using the DDA has also impacts on the speed you can reveal the launcher?
[14:03] <mzanetti> dandrader|afk: pmcgowan reports he's not able to reveal the launcher any more most of the times
[14:04] <mzanetti> I think he's used to drag it out with a gesture from bottom-left towards top-right which is not in the allowed angle any more
[14:04] <kgunn> mzanetti: i kind of noticed the same difficulty yesterday...wonder if its the swipe velocity value he's got in DDA
[14:04] <kgunn> felt more speed related to me as i'm an index finger user
[14:05] <mzanetti> well, now that you say it... Before I really thought I would not be able to keep the straigt direction with my thumb... but yes, it mostly happens when revealing very fast
[14:06] <mzanetti> nah... seems the direction...
[14:07] <mzanetti> maybe we need to widen the angle a little
[14:08] <dandrader> mzanetti, no, it should have no impact on the speed you can reveal the launcher
[14:08] <larsu> dednick: I see you started working on loading indicator files - do you want a shared library for that or are you fine parsing it yourself? (it's not that big of a format...)
[14:09] <dednick> larsu: is it ini format?
[14:09] <larsu> yup
[14:09] <dednick> larsu: it's ok, i've just used qsettings which supports it.
[14:09] <larsu> we added some things since oakland, a description is here: http://bazaar.launchpad.net/~larsu/libindicator/new-indicator-file-format/revision/491/README
[14:11] <dednick> larsu: thanks. i'll account those changes into what i have.
[14:42] <greyback> mzanetti: could you please try out http://pastebin.ubuntu.com/5720050/ and check it fixes the launch flicker bug?
[14:43] <mzanetti> greyback: sure... give me one minute please
[14:43] <mzanetti> dandrader: hmm... I wanted to update the tests for the dragging property
[14:43] <greyback> my internet has become very slow, pushing a branch taking ages
[14:44] <mzanetti> dandrader: what I did is to add a Q_COMPARE to the if where the gesture becomes rejected
[14:44] <mzanetti> dandrader: but I intentionally left the Q_COMPARE at the end of the function to 2, but thing is, it becomes 3
[14:45] <dandrader> greyback, are you using this bash trick? -> alias bzrpushs='bzr push --stacked-on bzr+ssh://bazaar.launchpad.net/+branch/unity/phablet/'
[14:45] <mzanetti> dandrader: which means, we emit draggingChanged even when its not changing
[14:45] <mzanetti> dandrader: +1 for shorter aliases: alias pu='bzr push --stacked-on bzr+ssh://bazaar.launchpad.net/+branch/unity/phablet/'
[14:45] <mzanetti> :)
[14:46] <mzanetti> anyways...
[14:46] <mzanetti> dandrader: do you think that is an issue? should I introduce a m_dragging var and keep track of that to only correctly emit changed signals?
[14:46] <greyback> dandrader: yep, but seems my speed gone down to 40Kbps
[14:48] <dandrader> mzanetti, that after your change, right?
[14:49] <mzanetti> dandrader: yes... my change introduces that...
[14:49] <dandrader> mzanetti, Undecided -> Rejected (draggingChanged(false)), then Rejected -> WaitingForTouch (draggingChanged(false) once again)
[14:49] <mzanetti> dandrader: exactly
[14:50] <dandrader> mzanetti, we don't need to introduce an m_dragging variable as it duplicates information and therefore it's liable to get outdated and therefore conflict with other variables
[14:50] <mzanetti> dandrader: ah... right... we can see if oldstate is !rejected before emitting
[14:51] <dandrader> mzanetti, better make setStatus() have a bit more context information, so that it knowns also the previous state before emitting the draggingChanged() signal
[14:51] <dandrader> mzanetti, that way it can differentiate between Rejected -> WaitingForTouch and Recognized -> WaitingForTouch
[14:52] <dandrader> mzanetti, in which case it will only send the draggingChanged() event for the latter
[14:52] <dandrader> mzanetti, damn, just read that you had already suggested the same thing. wrote all that for nothing :)
[14:53] <mzanetti> hehe... at least you got me to think it through once more
[14:53] <mzanetti> seems save now ;)
[14:56] <mzanetti> dandrader: Recognized -> Undecided is not possible, right? you can only go from WaitingForTouch to Undecided
[14:56] <dandrader> mzanetti, yes
[14:59] <mzanetti> dandrader: ok. tests pass again and docs. https://code.launchpad.net/~mzanetti/unity/phablet-folding-launcher/+merge/166000
[15:06] <dandrader> mzanetti, Saviq: here's the bug report https://bugreports.qt-project.org/browse/QTBUG-31491
[15:06] <mzanetti> dandrader: cheers
[15:07] <tedg> tsdgeos, A fix that you can try.  https://code.launchpad.net/~ted/hud/dee-sync/+merge/166819
[15:07] <tedg> Going to put it on my phone now.
[15:08] <dandrader> mzanetti, do you want me to review the whole thing?
[15:08] <mzanetti> dandrader: if you want
[15:09] <Saviq> dandrader, yup, confirmed, thanks
[15:10] <dandrader> mzanetti, well, it's been a while since I last reviewed anything of relevant size.
[15:10] <dandrader> mzanetti, so I'm fine on reviewing this
[15:11] <mzanetti> dandrader: ok. cool.
[15:12] <dandrader> mzanetti, now that you're familiar with DDA, would you mind reviewing https://code.launchpad.net/~dandrader/unity/phablet_edgeDragInStage/+merge/166777   :)
[15:12] <mzanetti> dandrader: sure
[15:13] <tsdgeos> tedg: ok, me me check too
[15:15] <mzanetti> tedg: is it a known issue that hud-service goes wild every once in a while?
[15:15] <mzanetti> happens sinse a week or so
[15:15] <mzanetti> since
[15:15] <tedg> mzanetti, Wild?
[15:16] <mzanetti> tedg: means, on my PC ~20% CPU usage, on the Galaxy Nexus ~80% CPU usage
[15:16] <mzanetti> unfortunately I couldn't figure yet when exactly it happens
[15:17] <mzanetti> but every once in a while my fans turn on and I check top and its the hud-service
[15:17] <tedg> mzanetti, Hmm, no, not aware of anything there.
[15:17] <mzanetti> same for the phone... every once in a while it starts getting warm and draining batteries
[15:17] <tedg> Hmm, do you use it a lot?  If nothing else it should shutdown after 10 minutes of non-use.
[15:18] <mzanetti> tedg: I don't use it at all
[15:18] <mzanetti> tedg: I have the feeling it happens when the shell goes away or so
[15:18] <mzanetti> in case it happens again here. is there anything I can do to get more information?
[15:19] <tedg> Hmm, not sure what could be happening
[15:19] <tedg> I guess give it a SEGV and generate an apport report?
[15:19] <mzanetti> tedg: ok... I'll keep an eye on it
[15:20] <mzanetti> greyback: hmm... seems not to fix the issue
[15:21] <mzanetti> greyback: do I need to apply the patch in combination of another branch of yours or is trunk fine?
[15:21] <greyback> mzanetti: on trunk
[15:22] <mzanetti> greyback: well... it seems better again...
[15:22] <mzanetti> greyback: still can reproduce it with launching first the phone app and then the gallery
[15:23] <greyback> mzanetti: let me try that
[15:23] <mzanetti> (might be related to app startup time as the gallery is the slowest one)
[15:23] <greyback> mzanetti: huh, I found phone was slowest. The delay could need tweaking.
[15:28] <greyback> mzanetti: fine on my nexus. I'll admit it's a hacky solution, but right now there's no way for shell to know if an application has drawn its first frame.
[15:28] <mzanetti> greyback: right... I had the same issue with the blur thing
[15:29] <mzanetti> greyback: anyways... most of the times your hack seems to work
[15:30] <greyback> mzanetti: I've put it in a MR https://code.launchpad.net/~gerboland/unity/phablet-fix-flicker-on-launch/+merge/166829
[15:30] <tsdgeos> tedg: i can comment indicator-appmenu in debian/control to build on the phone, right?
[15:31] <mzanetti> greyback: is that a function inside a function?
[15:31] <greyback> mzanetti: yep
[15:31]  * mzanetti needs to looka t some C++ code to come down
[15:32] <gatox> hi.... is the build of phablet working in S?? Because when trying to run the ./build -s ... some of the ppas with the dependencies couldn't be found for S
[15:32] <tedg> tsdgeos, Yup
[15:32] <tedg> tsdgeos, I drop the metacity one as well.
[15:32] <tedg> We should probably just remove that test.
[15:32] <tedg> tsdgeos, FYI, that branch works for me.
[15:32]  * tedg is cropping photos like a madman
[15:33] <tsdgeos> tedg: cool
[15:33] <tsdgeos> tedg: do you have someone to review it?
[15:33] <tsdgeos> in the unity-backend team ?
[15:34] <tsdgeos> i'm still dpkg-buildpking
[15:34] <tedg> tsdgeos, Uhm, no one in particular.  If you would that'd probably be reasonable to me.
[15:34] <tedg> Not sure that we have a "hud backend team" anymore.
[15:35] <tsdgeos> but you have a "all things backend team" :D
[15:35] <tedg> Heh
[15:35] <tsdgeos> sure, i can test it first and then have a look at the code
[15:35] <tsdgeos> should not be that hard (TM)
[15:36] <tsdgeos> tedg: actually i only need to install libhud-client2_13.10.1daily13.05.23ubuntu.unity.next-0ubuntu1_armhf.deb, no?
[15:36] <tedg> tsdgeos, Yeah, that's all you *need* but I usually do "dpkg -i *.deb" to not think about it :-)
[15:38] <tsdgeos> hmmm
[15:38] <tsdgeos> is the automerger broken?
[15:38] <tsdgeos> or just sloooow
[15:41] <tsdgeos> tedg: didn't work, i still got to be the leader of it :-/
[15:41] <tsdgeos> DeeListModel(0x186e850) DeeListModelPrivate::createRoles synchronized true
[15:41] <tsdgeos> DeeListModel(0x186e850) DeeListModelPrivate::createRoles numColumns 0
[15:41] <tsdgeos> DeeListModel(0x186e850) DeeListModelPrivate::createRoles isLeader 1
[15:41]  * tsdgeos dpkg -i *.deb just in case
[15:41] <tedg> tsdgeos, And did you reboot?
[15:41] <tsdgeos> yep
[15:41] <tedg> Hmm, not sure why it works for me then...
[15:42] <tsdgeos> well because it did already work
[15:42] <tsdgeos> randomly
[15:43] <tedg> Hmm, it never worked for me before.
[15:43]  * tedg reboots again
[15:43] <tsdgeos> oh it did work here sometimes
[15:43] <tsdgeos> maybe you just made it harder to repro
[15:44] <tsdgeos> yeah same thing :/
[15:44] <tsdgeos> which makes no sense :D
[15:46] <tsdgeos> mhr3: any input on ted's code? https://code.launchpad.net/~ted/hud/dee-sync/+merge/166819
[15:48] <tedg> tsdgeos, So it seems the values above say that it is synchronized, which is what we were checking for.
[15:49] <tedg> tsdgeos, Perhaps we need to wait for a column?
[15:49] <tsdgeos> tedg: what mhr3 commented is that you should be the leader
[15:49] <tsdgeos> i.e. dee_shared_model_is_leader should be true for you
[15:50] <tsdgeos> thing is i think he said that on synchronized you'd be that
[15:51] <tedg> Perhaps in the service side we need to wait until we get the name.
[15:51] <tedg> I think that the leader thing is a race to own the name.
[15:51] <tedg> It would make sense that the service would win.
[15:51] <tedg> But, perhaps we're getting cases where it doesn't.
[15:52] <tsdgeos> tbh i don't know, it's a bit of a pain that this changed out of the blue :-/
[15:53] <tedg> I don't think anything *changed* other than it's probably a fix or optimization or something like that.
[15:53] <tedg> Fix with side effects.
[15:54] <tsdgeos> ah
[15:54] <tsdgeos> i think i know why this doesn't help
[15:55] <tsdgeos> you are doing it in the client side :D
[15:55] <tsdgeos> what mhr3 suggested was doing in the server side
[15:55] <tsdgeos> or not
[15:55] <tsdgeos> don't know
[15:55]  * tsdgeos confused
[15:56] <tedg> I think we perhaps need both.
[15:56] <tsdgeos> damn wailing cousin on next door :D
[15:56] <tedg> Basically ensure that the service is the leader and that we know that on the other side.
[15:56] <tsdgeos> yep
[15:56] <mzanetti> someone please review this but NOT top approve yet (some changes are still pending merge) https://code.launchpad.net/~unity-team/unity/release-1.79/+merge/166840
[15:56] <mzanetti> greyback:  maybe? ^
[15:57] <tsdgeos> tedg: think you can try that?
[15:57] <mhr3> tsdgeos, tedg, right, it should be on the server side - wait for the model to synchronize before passing it's name over the bus
[15:57] <mhr3> that will fix things
[15:57] <greyback> mzanetti: I'll take
[15:57] <tedg> tsdgeos, Yup, trying.
[15:57] <tedg> mhr3, Makes sense.
[15:57] <mhr3> tedg, no need to do it on client side if server ensures that
[15:57] <tedg> Hating dbus names right now.
[15:58] <tedg> mhr3, I think it's better to do client side in general as there's less updating that way, perhaps not worth writing the code... but since I already wrote it :-)
[15:59] <mhr3> tedg, it looks a bit scary, so i'd go with smaller amount of code in this case (for the client)
[15:59] <greyback> mzanetti: approved (not top level)
[16:00] <mhr3> tedg, i have an idea - lets implement dbus mutex library ;P
[16:00] <tedg> mhr3, Heh, I'm so happy to be getting rid of some of our dbus activation stuff already.  I don't need more.
[19:22] <MCR_> Hi @all :)
[19:23] <alecu> hi!
[19:24] <MCR_> andyrock, hi - do you have a minute ?
[19:26] <MCR_> A volunteer to set up a PPA with Compiz 0.9.10-dev and Unity/nux/libunity for Raring would be needed...
[19:27] <MCR_> Since we had an ABI break, there is no way to run latest Compiz with latest Unity on Raring without self-compilation...
[19:28] <MCR_> Seems like *nothing* here builds correctly: https://code.launchpad.net/~unity-team/unity/trunk/+recipes
[19:29] <MCR_> Please see bug #1185778 for details...
[19:30] <MCR_> bregma ?
[19:31] <MCR_> Trevinho, ^^
[20:46] <eean> so I have an app that uses org.kde.StatusNotifierWatcher for the statusbar
[20:46] <eean> but it still isn't showing up in the indicator
[20:46] <eean> s/statusbar/systray/
[20:47] <eean> is there logic somewhere on what is 'allowed' in the indicator?


[12:18] <sacarde> hi
[12:19] <sacarde> can you help me to use "pinch" touch on my Touchpad ?
[12:21] <sacarde> I need:  SGS-L ?
[12:28] <sacarde> for : Pinch Zoom
[12:29] <sacarde> which packages I have to install?


[08:39] <cjwatson> tedg: Yep, it's currently confusing, sorry.  There's a branch in flight to make the UI there much clearer.
[13:18] <ricotz> tomwardill, hello, could you take a look at this build to check whether it is (nearly) stuck? https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-prereleases/+build/19777511
[13:19] <tomwardill> ricotz: hmm, build time of over a day, I'd say that looks reasonably stuck
[13:20] <tomwardill> let me see if I can see anything in the logs for you
[13:20] <ricotz> tomwardill, this build can take some while, but usually not that long
[13:21] <ricotz> (meaning 10 hours would not be surprising)
[13:26] <tomwardill> hmm, can't find any mention of it at all in the logs, going to see if anyone else can help :)
[13:28] <ricotz> tomwardill, thank you, retrying it would be waste if it can be resumed somehow
[13:52] <cjwatson> It's likely to be stuck at the builder end.  Probably the best we'll be able to do is to extract some information
[13:52] <cjwatson> (Unlikely to be buildd-manager having forgotten about it, since it was only restarted a couple of hours ago as part of a deployment)
[13:53] <ricotz> cjwatson, tomwardill, please restart it when you finished your investigation
[13:54] <cjwatson> Please restart what?
[13:54] <cjwatson> buildd-manager?  That wouldn't make sense here
[13:55] <ricotz> cjwatson, the libreoffice build
[13:55] <tomwardill> I assume the build
[13:55] <cjwatson> Oh, right
[14:09] <tomwardill> ricotz: this is the ps tree from the builder: https://pastebin.ubuntu.com/p/vs7C7t5Cdr/ it looks like the build has died to me, but do you have any suggestions beyond just restarting the build?
[14:13] <ricotz> tomwardill, sorry, no, just restart it
[14:15] <cjwatson> OK, applying fire
[14:19] <tomwardill> ricotz: restarted, thanks for your patience while we looked at that
[14:21] <ricotz> tomwardill, no problem, although cancelling != restarting
[14:22] <ricotz> should I start it myself?
[14:23] <tomwardill> oh, errr. Unsure... cjwatson did you just cancel or did you queue a rebuild too?
[14:26] <cjwatson> I cancelled and then I finished writing an email while it got around to processing the cancel.
[14:26] <cjwatson> I've retried it now.
[14:26] <tomwardill> ah, ta :)
[14:40] <ricotz> :)
[15:50] <marcustomlinson> tomwardill: any idea why this package is stuck in the queue: https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=libreoffice
[15:52] <tomwardill> hmm, not immediately, 6 hours seems a reasonable time gap
[15:53] <Laney> there's a duplicate versioned upload stuck in Accepted; that one failed due to .orig mismatch
[15:53] <Laney> this was a re-upload to fix that but both appear wedged
[15:54] <marcustomlinson> thanks Laney
[15:54] <Laney> np
[15:56] <Laney> I could try to reject the queue item in Accepted, see if that does anything ...
[15:56] <marcustomlinson> do eeet
[15:56] <Laney> actually I probably can't, no checkboxes on the UI
[15:56] <cjwatson> That surely won't do anything to the one in Unapproved though?  An upload is generally in Unapproved because it hasn't been approved yet
[15:57] <Laney> Timo tried to approve it earlier; you can see that if you expand the item
[15:57] <cjwatson> Ah, interesting
[15:57] <cjwatson> Looking in logs
[15:58] <cjwatson> Curious that it got logged as accepted even though it wasn't
[15:59] <cjwatson> Laney: Try the command line: `queue -s focal-proposed -Q accepted reject -m 'fill in some reason here' libreoffice`
[16:00] <cjwatson> Then I guess the other one will probably need to be accepted again
[16:02] <Laney> cjwatson: Yep, that did manage to get rid of it
[16:03] <ricotz> \o/
[16:03] <Laney> I'll take Timo's previous attempt as permission enough and accept it myself
[16:07] <Laney> Oh good, I got a 503
[16:08] <Laney> https://oops.canonical.com/?oopsid=3cb368e6557579d3aa354c7437da3d4a but ISTR accepting LO to be a bit timeouty so maybe this is known
[16:10] <Laney> yes ok, it worked a second time
[16:10] <marcustomlinson> oh woot thanks Laney!
[16:11] <marcustomlinson> and cjwatson :)
[16:11] <Laney> np
[16:11] <Laney> marcustomlinson: fwiw I can't usually accept SRUs, so don't ask me about them in future :p
[16:12] <marcustomlinson> haha
[16:13] <cjwatson> Laney: mm, that's an unfortunate slightly-quadratic thing due to not having an in-process way to do the equivalent of DEB_HOST_ARCH=foo dpkg-architecture -ibar
[16:13] <cjwatson> (Accepting an upload needs to work out which builds to dispatch)
[16:13] <Laney> Ah, and it's done synchronously?
[16:14] <cjwatson> Yeah


[02:10] <_stink_> heyy
[03:35] <rick_h_> party
[12:47] <tony-smlr> SMLR E174/E175 (1/3/2016) Video: http://www.youtube.com/watch?v=ZnofzckBbUA Audio: http://live.smlr.us:8000/streaming
[14:55] <cmaloney> morning
[15:18] <Scary_Guy> yar
[15:19] <cmaloney> Is it talk like a Pirate Day already?
[15:20] <Scary_Guy> it's always talk like a pirate day
[15:27] <Scary_Guy> Especially on the IRC's :P
[15:29] <Scary_Guy> http://www.lyricsmania.com/pirate_this_song_lyrics_god_ate_my_homework.html
[18:46] <jrwren> https://medium.com/maxistentialism-blog/star-trek-deep-space-nine-in-82-5-hours-10acde591fd2#.5452s4pjo
[20:37] <cmaloney> wheeee
[20:38] <cmaloney> Deep Space NIne is my favorite trek
[21:08] <jrwren> mine too.


[01:41] <hatch> If I have a multi-series subordinate, should I be able to relate that subordinate to multiple applications of different series as long as they are in the supported series list?
[02:08] <cory_fu> hatch: Unfortunately, no.  The series for a subordinate is set when it is deployed and it can then only relate to other applications with the same series
[02:39] <hatch> cory_fu: np thanks for confirming
[09:23] <rts-sander> Hello, I'm trying to get juju actions defined on my charm; but it says no actions defined: https://justpaste.it/yird
[09:24] <rts-sander> did I miss something? I added actions.yml, have a command in the actions directory...
[09:27] <rts-sander> Oh.. I've got it: actions.yml => actions.yaml :>
[10:39] <user_____> hi
[11:18] <user_____> hi! need your help
[11:18] <user_____> juju add-machine takes forever
[11:19] <user_____> : cloud-init-output.log shows “Setting up snapd (2.14.2~16.04) …” (last line in file)
[11:19] <user_____> how to fix this?
[11:49] <rock> Hi. I have MAAS 1.9.4 0n trusty. And 4 physical servers commissioned. Now I want to test our Openstack bundle on MAAS. On MAAS node I installed juju 2.0. And then I followed  https://jujucharms.com/docs/2.0/clouds-maas. MAAS cloud juju model bootstrapping failed. Issue details :  http://paste.openstack.org/show/581940/. Can anyone help me in this.
[15:08] <cholcombe> we need some docs for debugging reactive charms
[15:08] <cholcombe> everything i'm getting is stuff random people remember about how to poke at it
[15:15] <marcoceppi> cholcombe: what are you trying to debug? I gave a whole lightning talk on this at the summit ;)
[15:15] <marcoceppi> (I intend on turning that into a document)
[15:15] <cholcombe> marcoceppi, my state isn't firing and i'm trying to figure out why
[15:15] <marcoceppi> cholcombe: is it set? `charms.reactive get_states`
[15:15] <cholcombe> marcoceppi, it's not.  so i'm working backwards
[15:16] <cholcombe> marcoceppi, my interface should be setting a state i'm waiting for so i suspect one of the keys the interface is waiting on is None
[15:17] <marcoceppi> cholcombe: did you write the interface?
[15:17] <cholcombe> marcoceppi, i did.  can i breakpoint it?
[15:17] <marcoceppi> you can with pdb, sure
[15:17] <marcoceppi> cholcombe: link to it? I've gotten good at finding oddities in interface layers
[15:17] <cholcombe> marcoceppi, any idea where reactive puts the interface file?
[15:17] <marcoceppi> cholcombe: hooks/interfaces/*
[15:18] <cholcombe> cool
[15:18] <cholcombe> marcoceppi, https://github.com/cholcombe973/juju-interface-ceph-mds/blob/master/requires.py
[15:18] <cholcombe> it worked until i added admin_key
[15:18] <cholcombe> looks like hooks/interfaces doesn't exist
[15:19] <marcoceppi> cholcombe: is in hooks
[15:19] <marcoceppi> could be relations
[15:19] <marcoceppi> cholcombe: also,  admin_key  isn' tin the auto-accessors
[15:19] <cholcombe> marcoceppi, heh helps to have more eyes on it doesn't it
[15:19] <cholcombe> marcoceppi, thanks :D
[15:20] <marcoceppi> cholcombe: np, it might be better to just use get_conv instead
[15:20] <marcoceppi> which will getyou al lthe relation data, regardless of auto-accessors
[15:20] <cholcombe> marcoceppi, yeah i think i should switch to that
[15:20] <cholcombe> too much magic going on
[15:20] <marcoceppi> *magic.gif*
[15:34] <kjackal> kwmonroe: is this the revision we should be testing cs:bundle/hadoop-processing-9   ?
[15:34] <kwmonroe> yup kjackal
[15:35] <kjackal> kwmonroe: not good....
[15:35] <kwmonroe> oh?
[15:35] <kjackal> something went wrong, with ganglia
[15:35] <kjackal> let me see
[15:35] <kwmonroe> kjackal: error on the install hook with ganglia-node?
[15:35] <kwmonroe> kjackal: i saw that.. looks like it's trying to run install before the charm is unpacked.. give it a couple minutes and it should work itself out
[15:36] <kwmonroe> it's not really red unless it's red for > 5 minutes ;)
[15:36] <kjackal> Indeed!!! It recovered!
[15:36] <kwmonroe> and that, my friend, is ganglia.
[15:36] <kjackal> Selfhealing!
[15:36] <kwmonroe> :)
[15:54] <cory_fu> kjackal, kwmonroe: I was able to deploy cs:hadoop-processing-9 on GCE and run smoke-test on both namenode and resourcemanager without issue
[15:55] <kwmonroe> w00t.  thx cory_fu
[15:55] <cory_fu> admcleod_: ^
[15:55] <kjackal> kwmonroe: cory_fu: is the smoke-test doing a terasort?
[15:55] <kjackal> I thought there was a seperate action for terasort
[15:57] <cory_fu> kjackal: smoke-test does a smaller terasort.  I can run the bigger one.  One min
[15:59] <bdx> hows it going all? Can storage be provisioned via provider, and attached to an instance w/o also being mounted?
[15:59] <bdx> using `juju storage`
[16:00] <bdx> lets say I want to deploy the ubuntu charm and give it external storage, but not have the storage mount to anything
[16:01] <bdx> then, subsequently configure and deploy the lxd charm over ubuntu
[16:01] <kjackal> cory_fu: kwmonroe: admcleod_: Terasort action finished here as well. On canonistack
[16:02] <kwmonroe> oh sweet baby carrots.  thanks kjackal cory_fu.  i kinda wish i would have dug into the broken env more, but we're 3 for 3 today.. so it's ready to ship ;)
[16:07] <cory_fu> kwmonroe: How are you seeing the error manifest?  My second smoke-test on resourcemanager seems to be hung
[16:10] <cory_fu> kwmonroe: Hrm.  I seem to have lost my NodeManager on 2 of 3 slaves, too
[16:10] <kjackal> cory_fu:  if you ssh to the slave node you should find only one java process (Datanode). There should be two java processes there. THe Namenode process is missing
[16:10] <cory_fu> Ok, I'm seeing that now
[16:11] <cory_fu> No errors in the hadoop-yarn logs, though
[16:12] <cory_fu> kwmonroe: 2016-09-20 15:55:25,059 INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl: Memory usage of ProcessTree 9965 for container-id container_1474386123726_0003_01_000001: -1B of 2 GB physical memory used; -1B of 4.2 GB virtual memory used
[16:13] <cory_fu> -1B??
[16:41] <cory_fu> tvansteenburgh: You pushed the fix for the missing diff... Will it only apply if a new rev is added?
[16:42] <tvansteenburgh> cory_fu: once the fix is deployed, you'll need to close and resubmit the review
[16:42] <cory_fu> Oh.
[16:43] <tvansteenburgh> cory_fu: and to be clear, i'm not in the process of deploying it
[16:43] <cory_fu> tvansteenburgh: Also, +1 on removing that whitespace in the textarea.  :p
[16:43] <cory_fu> tvansteenburgh: Fair enough
[16:43] <tvansteenburgh> i knew you'd appreciate that
[16:55] <kjackal> kwmonroe: cory_fu: any luck on the namenode issue? I am trying different configs but with no success
[16:55] <cory_fu> kjackal: I've been focusing on InsightEdge and waiting for kwmonroe to get back.  I don't see anything useful in the logs, so I have no idea what's happening
[17:53] <kjackal> kwmonroe: I might have a set of params that seem to make namenode stable (until it breaks again)
[17:55] <cory_fu> kjackal: What were the params?
[17:56] <kjackal> just a asec
[17:57] <kjackal> cory_fu: kwmonroe: http://pastebin.ubuntu.com/23208123/ these go to the yarn-site.xml
[17:58] <kjackal> I have been running terasort with a single slave for 3-4 consequtive times
[17:58] <cory_fu> kjackal: Do we have any idea why we're seeing these failures on the Bigtop charms and not (presumably) the vanilla Apache charms?
[17:59] <kjackal> cory_fu: not yet
[18:00] <kwmonroe> kjackal: cory_fu:  we should have shipped when we had the chance
[18:00] <kwmonroe> and yes, nodemgr death is what i saw in yesterday's failure
[18:01] <kwmonroe> kjackal: do those values go into yarn-site.xml on the resourcemanager, slaves, or both?
[18:02] <kjackal> kwmonroe: I have them on the slave
[18:03] <kwmonroe> also cory_fu kjackal, i wonder if the addition of ganglia-node and rsyslogd ate enough resources to cause the slaves to run out of memory.. that's one thing different between the bigtop and vanilla bundles
[18:04] <kwmonroe> furthermore, didn't we have a card on the board to watchdog these procs?  if not, we should add one... or at least check for each proc before we report status.
[18:05] <kwmonroe> it'd be nice to see at a glance that status says "ready (datanode)" and know that something went afoul with nodemanager
[18:07] <kjackal> kwmonroe: cory_fu: nooo... it died again....after 5 terasorts...
[18:09] <cory_fu> +1.  We could have a cron job that checks for the process and uses juju-run to call update-status if it goes away
[18:13] <kjackal> yeap thi fire and forget policy we have for services could improve. kafka may also fail to start and we never report that (we have a card for this)
[18:19] <cory_fu> kwmonroe, kjackal: There's an issue with the idea of relying on the base layer to set the series.  When doing charm-build, if the series isn't defined in the top-level metadata.yaml, it will default to trusty: https://github.com/juju/charm-tools/blob/master/charmtools/build/builder.py#L190
[18:19] <kwmonroe> yup cory_fu.. the workaround is to be explicit with charm build --series foo
[18:20] <cory_fu> Yeah, but that's a bit of a hassle
[18:20] <kwmonroe> cory_fu: i'm not married to the base layer defining the series.. if we want to leave it up to each charm, i'm +1
[18:20] <kwmonroe> but let's decide that now before i make final changes to push to bigtop
[18:20] <cory_fu> I'd like to fix charm-build, but I don't see an easy way to do so
[18:21] <kjackal> cory_fu: kwmonroe: if you have a single series then it will always place the charm under buildidrectory/trusty/mycharm
[18:21] <cory_fu> Without a fix for charm-build, I don't think it's reasonable for our charms to not "just work" with `charm build` by default
[18:21] <kjackal> even if the charm is for xenial
[18:22] <cory_fu> kjackal: That's not true.  If you define a single series in the metadata.yaml, it will use that
[18:22] <kwmonroe> yeah, pretty sure that ^^ is correct, but it has to be in the top layer metadata.yaml
[18:23] <cory_fu> kjackal: Specifically, if you define *any* series in metadata.yaml, it will output to builds/.  Otherwise, it will output to trusty/
[18:24] <kjackal> cory_fu: kwmonroe: I see, so I need to set the series on the top level metadata.yaml to move the output to builds/
[18:24] <kjackal> that will not play well with the series on the base layer
[18:24] <cory_fu> kwmonroe, kjackal: Looks like a (slightly hacky) work-around is to put an empty list for series in the top-level charm layer
[18:25] <cory_fu> Ah, damnit.  Nevermind, that doesn't work, either
[18:25] <kwmonroe> 2 Ms in dammit, goose
[18:27] <cory_fu> Though, making that work-around work would be pretty easy
[18:31] <kjackal> since we are in this subject ... I tried to remove the slave we have in the bundle (juju remove-application) and  add an older one from trusty. The trusty one never started the namenode, probably never related to resource manager
[18:49] <cory_fu> kjackal: Looks like we weren't the only one to be hitting this: https://github.com/juju/charm-tools/issues/257
[18:55] <kjackal> cory_fu: Oh.. I totaly forgot to continue wit this issue. Got consumed with the hadoop thing
[18:55] <kjackal> tring now the bundle in trusty
[19:15] <cory_fu> tvansteenburgh: Have you run in to issues with charms that use_venv and the python-apt package?
[19:15] <cory_fu> marcoceppi: ^
[19:16] <tvansteenburgh> cory_fu: no
[19:17] <marcoceppi> cory_fu: I don't have a use_venv charm
[19:17] <cory_fu> grr
[19:28] <tvansteenburgh> cory_fu: i don't know what the issue actually is, but have you tried installing apt from pypi instead?
[19:37] <cory_fu> tvansteenburgh: I don't actually need python-apt but it gets pulled in automatically whenever charmhelpers.fetch is imported.  The problem with installing from pypi is that it adds a lot of dependencies into the wheelhouse that I don't need, and it's already installed on the system anyway.
[19:37] <cory_fu> tvansteenburgh: I remembered, though, that I could use include_system_packages, and that's working for me
[19:38] <tvansteenburgh> cool
[19:42] <kjackal> kwmonroe: cory_fu: I am testing the hadoop processing we have for truty. I see a different behavior there. The namenode does not die but we get some jobs failing
[19:45] <kwmonroe> kjackal: that's odd.. are they long running jobs?  can you tell from the DN or RM logs if they are being killed for a particular reason (like memory exceeds threshold)?
[19:46] <kjackal> kwmonroe: looking
[19:47] <kwmonroe> also kjackal, the failure earlier with ganglia-node was a bug.  the charm uses '#/usr/bin/python' which doesn't exist on xenial.  it "fixed" itself because rsyslog-fowarder-ha installs 'python'  (http://bazaar.launchpad.net/~charmers/charms/trusty/rsyslog-forwarder-ha/trunk/view/head:/hooks/install), so once rsyslog-fowarder finished its install hook, the subsequent ganglia install hook would succeed.
[19:48] <kwmonroe> i'm pushing a similar install hook change for ganglia-node, so we shouldn't see that again.
[19:56] <beisner> thedac, tvansteenburgh - i've been trying to figure out what changed to cause our juju-deployer + 1.25.6 machine placement to break.  it looks like 0.9.0 is causing our ci grief.  https://launchpad.net/~mojo-maintainers/+archive/ubuntu/ppa
[19:57] <beisner> basically, bundles that used to deploy to 7 machines with all sorts of lxc placement now end up asking for 18 machines, while still placing some apps in containers.  very strange.
[19:57] <beisner> is there a known issue?
[19:58] <beisner> i've found that we got deployer 0.9.0 from the mojo ppa of all places
[20:00] <tvansteenburgh> beisner: they got it from my ppa
[20:00] <tvansteenburgh> https://launchpad.net/~tvansteenburgh/+archive/ubuntu/ppa
[20:01] <tvansteenburgh> nothing has changed with placement in a quite a while
[20:01] <tvansteenburgh> feel free to file a bug on juju-deployer though
[20:01] <tvansteenburgh> https://bugs.launchpad.net/juju-deployer
[20:02] <beisner> tvansteenburgh, at a glance, here's a bundle and the resultant model: http://pastebin.ubuntu.com/23205474/
[20:03] <tvansteenburgh> beisner: sorry, i don't even have time to glance right now, can you put that paste in a bug?
[20:03] <kjackal> kwmonroe: this is odd http://pastebin.ubuntu.com/23208612/
[20:03] <beisner> tvansteenburgh, ok np.  first i need to revert to a working state and block 0.9.0 pkgs.  we're borked atm.
[20:07] <kwmonroe> kjackal: http://stackoverflow.com/questions/31780985/hive-could-not-initialize-class-java-net-networkinterface.. sounds like our old friend "datanode ip is not reverse-resolvable".  what substrate are you on?
[20:07] <kjackal> I am on canonistack
[20:07] <kjackal> kwmonroe: ^
[20:08] <kjackal> let me check the resolutions
[20:08] <kwmonroe> kjackal: can you try adding an entry to your namenode and resourcemanager /etc/hosts files that includes your slave IP and `hostname -s`?
[20:09] <kjackal> yeap just a sec
[20:16] <kjackal> kwmonroe: it seems i have a ghost slave...
[21:13] <kjackal> kwmonroe: I have 5 consecutive successfull terasorts
[21:20] <kwmonroe> kjackal: i got to 4 before my terasort hung.. http://imgur.com/a/maMAM  it's not dead yet, but i have little faith that it will return :/
[21:20] <kjackal> kwmonroe: I am on the ninth successfull now!
[21:22] <kwmonroe> kjackal: my "Lost nodes" count is rising on my RM :(  i think i'm toast.
[21:23] <kjackal> kwmonroe: 10 successfull!
[21:24] <kjackal> So here is what the setup looks like: started from hadoop-processing-6 updated the /etc/hosts to have reveres lookups
[21:25] <kjackal> I believe what makes the difference is the trusty host :(
[21:26] <kjackal> What I do not fully get is why do we still have the hosts issue, I thought we have a workaround for it.
[21:26] <kjackal> kwmonroe: ^
[21:28] <kwmonroe> right kjackal -- and especially on clouds that have proper ip/dns mapping, which aws and cstack have
[21:28] <kjackal> kwmonroe: http://imgur.com/a/VUTSZ
[21:29] <kwmonroe> however, kjackal, we have only ever worked around the NN->DN reverse ip issue with the hadoop datanode-ip-registration param set to allow non-reversible registration.. perhaps there's an issue with RM->NM that we're not considering.
[21:33] <kjackal> Ok, kwmonroe, next step for me is to force the latest charms to deploy on trusty. The fact that the namenode is not crashing on trusty is promissing
[21:34] <kjackal> kwmonroe: (even is the jobs fail)
[21:35] <kjackal> 8if
[21:35] <kjackal> *if
[21:37] <beisner> thedac, tvansteenburgh - updated with examples and attachments.  it's definitely a thing.  https://bugs.launchpad.net/juju-deployer/+bug/1625797
[21:37] <mup> Bug #1625797: (juju-deployer 0.9.0 + python-jujuclient 0.53.2 + juju 1.25.6) machine placement is broken <uosci> <juju-deployer:New> <mojo:New> <python-jujuclient:New> <https://launchpad.net/bugs/1625797>
[21:42] <kwmonroe> kjackal: what timezone are you in this week?
[21:42] <kjackal> kwmonroe: I am in DC
[21:42] <kwmonroe> ah, very good kjackal.  you can keep working ;)
[21:42] <kjackal> kwmonroe: -5 I think
[21:43] <kwmonroe> yeah -- just as long as you're not back in Greece
[21:44] <kwmonroe> cory_fu: fyi, deploying bigtop zepplin also apt installs spark-core-1.5.1
[21:44] <cory_fu> Makes sense