[07:09] <darklight_> Any chance of seeing this fixed https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1305438 ? which is also tied to https://answers.launchpad.net/ubuntu/+question/243724
[07:13] <Saviq> darklight_, it's probably best if you post it on the ML
[07:18] <darklight_> Saviq, this one<EMAIL_ADDRESS>?
[07:18] <Saviq> darklight_, no, ubuntu-devel would be a better choice, I also added a "unity" task to the bug, as this seems to be caused by the unity plugin, not by compiz itself
[07:18] <Saviq> according to the comments
[07:21] <Saviq> MacSlow, you still had old tags in your branch, please make sure to strip all your local checkouts and any outstanding ones you have in LP
[07:21] <Saviq> paulliu, same for you ↑
[07:21] <Saviq> http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh for the rescue
[07:21] <MacSlow> Saviq, *sigh*
[07:22] <Saviq> MacSlow, remember you have to strip them on both sides - remote and local separately, as tag deletion doesn't carry over "bzr pull/push", as opposed to any new ones, which will happily get pushed all over the place...
[07:23] <MacSlow> Saviq, I know... I did all local and remote branches... will receck again
[07:23] <Saviq> MacSlow, I'm scanning the remote ones now
[07:23] <MacSlow> Saviq, ok
[07:24] <Saviq> MacSlow, but you don't have any
[07:24] <didrocks> Saviq: oh, you've done a script :p
[07:24] <Saviq> didrocks, yeah, we're *almost* there
[07:24] <MacSlow> Saviq, I'm rechecking local ones
[07:24] <didrocks> Saviq: well done man! that wasn't easy :)
[07:24] <Saviq> didrocks, yeah, on that note
[07:24] <Saviq> didrocks, any idea about "7.85+14.10.20140428.2-0ubuntu1 ?"
[07:24] <Saviq> where did that tag come from?
[07:25] <didrocks> you mean, it was never released?
[07:25] <Saviq> didrocks, it doesn't point to any revision
[07:25] <Saviq> the ?
[07:26] <Saviq> it looks like it got tagged by the train but somehow didn't actually get released
[07:26] <didrocks> Saviq: I wonder if we didn't get a rerelease after pushing to -proposed
[07:27] <didrocks> weird, doesn't seem to be the case though…
[07:27] <Saviq> didrocks, branches are scrapped on each Build, though aren't they?
[07:27] <didrocks> Saviq: yeah, they are
[07:27] <Saviq> didrocks, yeah, so it's something weird
[07:27] <Saviq> didrocks, anyway, looks like a one-off error, if I notice it again will let you know
[07:28] <didrocks> Saviq: please do, I'm quite puzzled
[07:29] <paulliu> Saviq: ok
[07:29] <Saviq> paulliu, you definitely have them in lp:~paulliu/unity8/logout
[07:29] <paulliu> Saviq: yes.
[07:33] <tsdgeos> waht, compiz is at 250% of cpu :D
[07:33] <tsdgeos> i shall reboot
[07:38] <Saviq> mzanetti, lp:~unity-team/unity8/fix-lvwph-xvfb is obsolete isn't it?
[07:39] <Saviq> dednick, lp:~nick-dedekind/unity8/indicators.hint-interval: 366 tags
[07:39] <Saviq> dednick, please strip
[07:39] <Saviq> Wellark, please use http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh on lp:~kaijanmaki/unity8/indicator-root-state-icons-fix and on any local checkout
[07:44] <MacSlow> Saviq, on lp:~macslow/unity8/sound-hint-support I've had these tags http://pastebin.ubuntu.com/7403087 still, which probably came from trunk (branched off yesterday)
[07:44] <Saviq> MacSlow, those are correct
[07:44] <MacSlow> ah ok
[07:45] <Saviq> MacSlow, we only don't like the 300 tags that came from lp:unity via our old lp:unity/8.0
[07:45] <Saviq> MacSlow, all of them will have ? in `bzr tags`
[07:45] <Saviq> there's actually one like that in trunk, but that one's current, and we don't care enough
[07:49] <tsdgeos> wtf bitcoin spam in queries :S
[07:50] <tsdgeos> karni: that bug you oepened, can you give the templates, components, cardData that is used for ot?
[07:50] <tsdgeos> it?
[07:54] <mzanetti> Saviq: right, yes, it is.
[08:09] <Saviq> MacSlow, bug #1315419 is not ours, it's the service that decides to stop waiting for the password, isn't it?
[08:09] <MacSlow> Saviq, no there's a timeout on every notification, which bites there... so it's currently ours
[08:09] <Saviq> MacSlow, ok
[08:10] <Saviq> MacSlow, please comment on the bug, I added a unity-notifications task
[08:20] <Saviq> biab
[08:43] <mhr3> dpm, ping? could we have the scopes docs updated?
[08:43] <mhr3> dpm, just grab the latest snapshot from utopic
[08:49] <dednick> Saviq: done
[08:57] <karni> tsdgeos: you mean the "image should match width" in preview bug?
[08:58] <tsdgeos> karni: yep
[08:58] <tsdgeos> maybe you did
[08:58] <tsdgeos> for some reason i seem to get only the first email of those bugs
[08:58] <tsdgeos> and not the followups
[08:59] <karni> tsdgeos: I can provide some data. And I believe template has nothing to do with the preview. I'll update the bug.
[08:59] <tsdgeos> ah it's preview?
[08:59]  * tsdgeos can't read
[08:59] <karni> "scope result preview", yes
[08:59] <karni> its not a card
[09:00] <tsdgeos> sorry :/
[09:00] <karni> tsdgeos: no need :)
[09:05] <dpm> mhr3, I'll get in touch with mhall119 to update the API site, he's taking care of that now
[09:05] <mhr3> dpm, k, thx
[09:07] <dpm> mhr3, np, sent you an e-mail to you both
[09:12] <tsdgeos> hmmm
[09:12] <tsdgeos> the .sh suffixes for build and run are unfortunate
[09:12] <tsdgeos> i need to type more now!
[09:17] <mhr3> tsdgeos, isn't it still ./r<Tab> ? :)
[09:17] <tsdgeos> mhr3: nope
[09:17] <tsdgeos> because there's builddir and run_on_device
[09:18] <mhr3> ah.. sucks indeed
[09:18] <mhr3> two more keypresses
[09:20] <tsdgeos> my productivity suddenly plumetted :D
[09:22] <tsdgeos> thanks we have ↑ so i can just still use that
[09:29] <Makay> hi
[09:35] <Makay> I wrote a short article about my "Unity redesign" idea. This is a small but very important correction in the current layout. My article is hungarian but i hope you will understand the images. http://androbit.net/articles/428/new_ubuntu_desktop_layout.html
[09:37] <seb128> Makay, hey, you should open specific bugs in launchpad
[09:37] <seb128> but things like the controls being in the corner is done for a reason
[09:38] <seb128> it's easier to access a corner than to access 15 pixels right of a corner
[09:38] <seb128> in one case you can throw the mouse in the direction, in the other one you need to aim
[09:40] <mzanetti> Makay: also, if your last image would contain the same amount of indicators than the first, I'm not sure if it would still look that good
[09:48] <Makay> mzanetti: yes, this is a problem but the current system tray (with panel) is ugly too
[09:57] <Cimi> tsdgeos, Saviq I just branched unity, I am running builddir/tools/unity-scope-tool, after having started scope-ui-starting
[09:57] <Cimi> I only have "my apps", and rest seems unresponsive
[09:57] <Cimi> no scopes
[09:58] <Cimi> file:///home/cimi/Development/unity8/carousel-shadow/qml/ScopeTool.qml:149:23: Unable to assign null to QString
[09:58] <Cimi> file:///home/cimi/Development/unity8/carousel-shadow/qml/Dash/DashContent.qml:101: TypeError: Cannot read property 'loaded' of null
[10:01] <Saviq> Cimi, "having started scope-ui-starting"?
[10:01] <Cimi> sure
[10:01] <Saviq> Cimi, you mean initctl emit?
[10:01] <Cimi> yes
[10:05] <mhr3> Cimi, unresponsive how?
[10:06] <Cimi> mhr3, that error
[10:06] <mhr3> Cimi, you see "Music" but nothing there?
[10:06] <Cimi> so no scopes
[10:06] <Cimi> yes
[10:06] <Cimi> looks like a service is not working
[10:06] <mhr3> Cimi, do `restart scope-registry`
[10:06] <mhr3> and run the tool then
[10:07] <Cimi> nope
[10:07] <Cimi> I have file:///home/cimi/Development/unity8/carousel-shadow/qml/Dash/DashContent.qml:101: TypeError: Cannot read property 'loaded' of null
[10:07] <Cimi> every time I switch
[10:09] <mhr3> Cimi, hm, pastebin ~/.cache/upstart/scope-registry.log
[10:09] <Cimi> http://paste.ubuntu.com/7403713/
[10:10] <Cimi> the death is when you asked me to restart
[10:10] <mhr3> yea, looks fine
[10:11] <mhr3> Cimi, try this `stop scope-registry && stop smart-scopes-proxy && start smart-scopes-proxy`
[10:12] <Cimi> now?
[10:12] <Cimi> start all of them?
[10:13] <mhr3> Cimi, just run the tool
[10:14] <mhr3> the last start should start everything up
[10:14] <Cimi> no
[10:14] <mhr3> Cimi, so what do you see in the tool now?
[10:15] <Cimi> same error
[10:15] <Cimi> same stuff
[10:15] <mhr3> Cimi, are you on t or u?
[10:15] <Cimi> u
[10:15] <mhr3> Cimi, latest everything?
[10:16] <Cimi> sure
[10:16] <mhr3> damn
[10:16] <Cimi> correct
[10:16] <Cimi> :)
[10:16] <mhr3> i'm running out of ideas
[10:18] <mhr3> Cimi, are you sure your changes didn't break something? ;)
[10:20] <Cimi> mhr3, if I run unity8 works
[10:20] <Cimi> mhr3, is the scope tool that doesn't
[10:20] <Cimi> I'll run whole unity... but neh
[10:22] <mhr3> i'm having issues with the header, but i guess that's cause i'm on T
[10:22] <mhr3> hmm, and ./run actually doesn't work
[10:22] <mhr3> yey me
[10:25] <Cimi> mhr3, oh sorry
[10:25] <Cimi> I am on t not u
[10:26] <Cimi> those stupid letters :)
[10:26] <Cimi> 14.04
[10:26] <tsdgeos> mhr3: there's no run anymore :D
[10:26] <tsdgeos> it's called ./run.sh
[10:26] <mhr3> tsdgeos, yea, that
[10:26] <tsdgeos> mhr3: define "doesn't work"
[10:27] <mhr3> tsdgeos, hangs
[10:27] <mhr3> i see it uses upstart now
[10:27] <tsdgeos> it does for a while yes
[10:27] <mhr3> i suppose it doesn't like something in there
[10:28] <tsdgeos> mhr3: make sure that if you have a "local" unity8.conf you update it with the contents of the file in data/
[10:28] <mhr3> tsdgeos, where do i need to install a local one?
[10:28] <tsdgeos> mhr3: you don't need to install it, i'm saying if you have a local one
[10:29] <mhr3> i dont
[10:29] <tsdgeos> are you sure?
[10:29] <mhr3> but i think it might work if i did :)
[10:29] <tsdgeos> it seems to me you're using an old one and not the new one that doesn't wait on indicators starting
[10:29] <tsdgeos> but may be something else
[10:29] <tsdgeos> anyway, you should be on U
[10:30] <mhr3> tsdgeos, wasn't the --no-wait thing an sru?
[10:30] <tsdgeos> mhr3: not sure, maybe :D
[10:30] <mhr3> but yea, it's not there
[10:31] <mhr3> i still find it weird that the scopes-ui emit works without no-wait and the indicator one doesn't
[10:31] <mhr3> what's the deal there?
[10:36] <tsdgeos> there's some indicator that hangs
[10:37] <tsdgeos> that's my understanding
[10:50] <Saviq> mhr3, yeah, it's something that reacts to indicator-services-start that doesn't return
[10:50] <Saviq> mhr3, also, we probably want to wait for the registry at least to start before starting the UI, something we don't care for indicators
[10:50] <Saviq> otherwise we might miss the 300ms mark
[10:51] <mhr3> Saviq, there's another timeout in the plugin
[10:51] <mhr3> could just make it smarter
[10:52] <Saviq> mhr3, sure, if you make it smarter to retry, we'll be able to --no wait indeed ;)
[10:53] <Saviq> or maybe even react to scope-registry started
[10:53] <mhr3> Saviq, are we delaying the startup now or something?
[10:53] <Saviq> mhr3, we're only starting unity8 after emit scope-ui-starting returns
[10:54] <Saviq> mhr3, which means that everything listening to that event completes startup
[10:54] <Saviq> mhr3, that'd be only smart-scope-proxy atm AFAICT
[10:55] <mhr3> Saviq, right, but is there actual data? that we're making the startup slower by 500ms or something?
[10:55] <Saviq> mhr3, you'd have to ask ogra
[10:55] <mhr3> otherwise, wishlist :)
[10:56] <mhr3> there were some talks to merge the two registries into one
[10:56] <mhr3> would make things better
[10:56] <mhr3> marcustomlinson, ^ right? ;)
[10:56] <marcustomlinson> mhr3: right
[11:05] <Saviq> mhr3, I never even requested it, I just explained why we do what we do, and you said that you could make it smarter ;)
[11:05] <tsdgeos> dednick: ping
[11:05] <dednick> tsdgeos: plop
[11:05] <tsdgeos> dednick: having a look at https://code.launchpad.net/~nick-dedekind/unity8/MenuContentActivator.bindingLoop/+merge/217899
[11:06] <tsdgeos> dednick: can't find anywhere the contentChanged signal is used :-S
[11:06] <tsdgeos> ah it's probably part of an assignment
[11:07] <dednick> menuActivator.content[index].active
[11:07] <mhr3> Saviq, right :) i could make the timing out smarter, but there are more correct fixes... that would take longer though
[11:07] <dednick> tsdgeos: yeah. it's one of those QMLListProperty thingos
[11:10] <tsdgeos> dednick: can i copy your comment into the commit message?
[11:11] <tsdgeos> makes things much easier if someone reads the commit log in the future
[11:11] <dednick> tsdgeos: sure
[11:12] <dednick> tsdgeos: done
[11:13] <tsdgeos> ah no
[11:13] <tsdgeos> i didn't mean that one
[11:13] <tsdgeos> i meant the other one
[11:13] <tsdgeos> :D
[11:13] <tsdgeos> "If we're already asking for the index, we know it exists already. No need to send a changeNotification on an implied creation."
[11:13] <tsdgeos> i'll add both
[11:13] <tsdgeos> :D
[11:13] <dednick> tsdgeos:  :)
[11:32] <MacSlow|lunch> Saviq, I can't mark LP #1315419 as a duplicate of LP #1295762 because of timeout-error on LP
[11:33] <MacSlow|lunch> Saviq, could you try?
[11:33] <Saviq> heh
[11:33] <MacSlow|lunch> no pun intended :)
[11:33] <Saviq> MacSlow|lunch, done, took three tries for me, too
[11:34] <MacSlow|lunch> gave up after five
[11:39] <karni> Hey guys, I'm looking at d.u.com cplusplus unity-scopes documentation - where can I find available PreviewWidget types?
[11:39] <karni> http://developer.ubuntu.com/api/devel/ubuntu-14.04/cplusplus/unity-scopes/classunity_1_1scopes_1_1_preview_widget.html
[11:40] <Saviq> MacSlow|lunch, huh, apparently you managed to dupe it in the end, just got an email ;)
[11:40] <Saviq> karni, http://developer.ubuntu.com/api/devel/ubuntu-14.04/cplusplus/unity-scopes/previewwidgets.html
[11:40] <Saviq> karni, top level "Preview widget types" ;)
[11:40] <karni> Saviq: lovely!
[11:41] <karni> Saviq: yeah.. *me hides*
[11:41] <karni> Saviq: What's the difference between pushing widgets one by one VS adding them to PreviewWidgetList and pushing that?
[11:41] <greyback> Saviq: can I ask for a volunteer to review: https://code.launchpad.net/~gerboland/unity-mir/shutdown-crash-fix3/+merge/218394
[11:42] <Saviq> karni, mhr3 can confirm, but they're sent to the UI as soon as you send them, so if you push them one by one they should get to the UI slightly faster
[11:43] <karni> Saviq: that'd make sense. wondering if there's any more magic. thanks!
[11:43] <Saviq> karni, you can also make a conscious decision, knowing that you can push a base preview straight away, and then request additional data from any service you need to ask and supplement the preview
[11:43] <mhr3> karni, sorry, irc issues, what's the problem?
[11:43] <Saviq> mhr3, no problem
[11:43] <karni> mhr3: no problem
 What's the difference between pushing widgets one by one VS adding them to PreviewWidgetList and pushing that?
[11:43] <mhr3> it's faster :)
[11:44] <mhr3> flicker-free
[11:44] <mhr3> or well.. before Saviq kicks me... it *can* be flicker-free
[11:46] <karni> :)
[11:47] <davmor2> mhr3: Flicker-free is like matrix spoons and internet cake it doesn't exist ;)
[11:47] <Saviq> tsdgeos, tests/plugins/Dash/cardcreatortest.cpp: bad whitespace in line 47
[11:47] <tsdgeos> meh
[11:47] <Saviq> tsdgeos, how are you getting that with QtC?
[11:47] <tsdgeos> i'm not using QtC
[11:47] <Saviq> I can't get my QtC to mess up whitespace ;D
[11:48] <Saviq> tsdgeos, that explains it :D
[11:48] <mhr3> karni, for clarity, adding all the widgets to a list and pushing that is flicker-free option
[11:48] <karni> davmor2: haha
[11:48] <karni> mhr3: ack
[11:49] <Saviq> mhr3, but slower, as it's sent in one go, right? so if you're requesting data from a remote API, it makes sense to send them one by one after having sent a base one for display?
[11:49] <karni> Saviq: yes
[11:50] <mhr3> Saviq, sure, if it'd take you too long to populate them all, it's better to chunk it, but if you don't have such a problem, single push is better
[11:50] <Saviq> mhr3, k
[11:51] <mhr3> Saviq, now, i need renderer for annotations
[11:52] <Saviq> mhr3, since when do we have annotations designed? :P
[11:52] <mhr3> Saviq, since forever :P
[11:52] <Saviq> mhr3, except they've been rejected by a certain gentleman
[11:53] <mhr3> alright, i'll ask mike about it
[11:54] <Saviq> mhr3, in CPT Mark said that he wanted them to be rich and context-dependent
[11:54] <dednick> tsdgeos: :)
[11:54] <Saviq> mhr3, not just plain links
[11:54] <dednick> tsdgeos: bleh. sorry
[11:54] <tsdgeos> dednick: don't be sorry for being happy :D
[11:54] <mhr3> Saviq, i thought he meant that both should be possible
[12:01] <karni> mhr3: I think Unity scopes api doc is missing instruction of how to add a preview action with *custom* uri
[12:01] <karni> as long as result uri is same as the action uri, it's easy, because you don't need to provide it
[12:03] <karni> optional  {"uri", Variant("uri")} doesn't resolve to mapped uri value, and {"uri", "uri"} doesn't compile. I suppose VariantBuilder is not the way to go if we want custom action uri?
[12:04] <mhr3> karni, what do you mean, "doesn't resolve to mapped uri"?
[12:04] <Cimi> Saviq, tsdgeos how do I export GRID_UNIT_PX for the new run script?
[12:05] <Saviq> Cimi, initctl set-env --global GRID_UNIT_PX=blah
[12:05] <karni> mhr3: if there's "uri" field in the result, that Variant("uri") action button resolves to <scope path>/uri instead of _real uri from the result_
[12:05] <Cimi> Saviq, works thx
[12:05] <karni> mhr3: it does not properly map, preview just takes hardcoded "uri", not *the* uri from the result
[12:06] <karni> mhr3: suppose, in the result I have "more_from_category_uri" and I want an action button that launches that uri
[12:07] <karni> mhr3: {"uri", Variant("more_from_category_uri")} will result in this action: <scope path>/more_from_category_uri instead, say, http://foo.shop.com/category/2
[12:07] <mhr3> karni, so just do {"uri", Variant("http://foo...")} ?
[12:08] <karni> mhr3: I thought these things should resolve. that's why we do header.add_attribute_mapping("text", "title"); and not ..._mapping("text", "THE title");
[12:09] <mhr3> but you can only map whole fields, not subfields
[12:09] <mhr3> you'd need to create an actions-like field in the result
[12:09] <mhr3> if you wanted to map that
[12:10]  * karni stares at what mhr3 is writing ;)
[12:10] <dednick> tsdgeos: bleh. sorry
[12:10] <karni> mhr3: you want something like {"uri", Variant(result["custom_uri"])} ?
[12:10] <dednick> baaaa!
[12:10] <mhr3> karni, no, when creating the result, you'd have to do:
[12:10] <karni> mhr3: can I even access the result?
[12:11] <mhr3> karni, VariantBuilder vb; vb.add_tuple({"uri", "http://..."}); result['actions'] = vb.end();
[12:11] <mhr3> karni, and then in preview w.add_attribute_mapping("actions", "actions");
[12:11] <mhr3> should have named it foo in result, then _mapping("actions", "foo")
[12:12] <karni> mhr3: I see. That sort of imposes Preview format on the result set.
[12:12] <mhr3> karni, right
[12:12] <mhr3> karni, that's the price to pay if you want to map it
[12:12] <Saviq> greyback, sorry, I looked at what you wrote and thought "sure", broken xchat-gnome didn't send my thoughts to you ;)
[12:13] <greyback> Saviq: np
[12:13] <karni> mhr3: and if I don't want to map it, is there another way? you said {"uri", Variant("http://foo...")} - how do I achieve that? can I access the result from within the preview?
[12:13] <mhr3> karni, you need to do it manually, but yea
[12:13] <karni> mhr3: I'm sorry I'm asking so many questions, but we're paving the dev story
[12:13] <mhr3> karni, ie, copy the result, in preview()
[12:14] <karni> mhr3: so 'result' is available in the scope of Preview::run?
[12:14] <karni> in the Preview, in general
[12:14] <mhr3> karni, not by default, you need to do it manually ^
[12:15] <Saviq> greyback, while working on this, did you notice unity8 taking a long time (like ½ a minute) to shut down after "initctl stop unity8"?
[12:15] <Saviq> I would expect the same on Ctrl+C actually
[12:15] <mhr3> karni, but yea, would be nice to support it out-of-box
[12:15] <mhr3> pstolowski, could we ^?
[12:15] <karni> mhr3: ok. that's way more dirty than enforcing preview format on the result. I'll go that route.
[12:16] <karni> mhr3: thank you
[12:16] <mhr3> karni, well, one has to go over the wire, one is just a mem copy... so...
[12:16] <greyback> Saviq: I notice that from time to time yes, but I didn't think it was unity8 that was blocking
[12:17] <Saviq> greyback, it is, it's just waiting for *something* on shutdown (probably the join())
[12:17] <greyback> Saviq: with that patch, worst case shutdown time is around 5 seconds (hit Ctrl+C just when Qt is starting up)
[12:17] <Saviq> greyback, ok sounds good
[12:17] <karni> mhr3: by dirty I mean the need to change scope-preview header and source file in a way that should not be needed. the less it is required to successfully write the scope, the better. so, I'll just reformat the result and map it as "actions", "actions" with add_attribute_mapping
[12:18] <Saviq> greyback, no checklist in the MP?
[12:18] <greyback> Saviq: not merging to trunk, but devel branch
[12:18] <Saviq> greyback, ah
[12:18] <Saviq> forgot about that
[12:19] <greyback> Saviq: I plan to fix bug 1305128 and then do a release
[12:19] <Saviq> greyback, glad, will help
[12:19] <Saviq> (I will)
[12:19] <greyback> ta
[12:28] <Saviq> greyback, doesn't build
[12:28] <Saviq> greyback, SIGINT, SIGTERM not declared in this scope, missing signal.h?
[12:29] <greyback> Saviq: probably. /me more curious why it builds for me
[12:29] <pstolowski> mhr3, karni we could provide result in preview's query run(), but the only backwards-compatible way of doing this that I can think of is to make it an attribute of PreviewQueryBase, and set it before calling run() (so it would only be available while inside run(), and i'm not sure I like it)
[12:29] <Saviq> greyback, FWIW same error in CI
[12:30] <mhr3> pstolowski, overloaded constructor/
[12:30] <mhr3> ?
[12:30] <pstolowski> mhr3, well, yes, but then you have a class that can be partially initialized if you use the default ctor
[12:31] <mhr3> pstolowski, mark deprecated :)
[12:32] <karni> mhr3: does this make sense to you? action works (launches browser), label does not show up: http://paste.ubuntu.com/7404288/
[12:32] <karni> mhr3: I used a vector, because I want more general code that shows you can add more than one button
[12:32] <karni> plus, mapping would expect an array there so.. VariantArray is actually std::vector<Variant> ..
[12:32] <mhr3> karni, that's what the add_tuple does
[12:33] <mhr3> karni, ie the variant builder is already creating an array
[12:33] <karni> mhr3: actions is an array, that coutains tuples that map to buttons
[12:33] <karni> [ { button attributes }, { button attributes }, ... ]
[12:34] <karni> mhr3: so, you have an array of variant builders, no?
[12:34] <mhr3> karni, no, variantbuidler is building an array already
[12:34] <karni> mhr3: I guess the preview actiono works only because it actually matches the result uri
[12:34] <mhr3> karni, if you didn't need an array you'd just use a variantmap
[12:35] <karni> okay, let me try it then :)
[12:35] <mhr3> karni, yea :)
[12:35] <greyback> Saviq: fix pushed
[12:35] <Saviq> greyback, k
[12:35] <karni> mhr3: good call, man. thanks
[12:35] <pstolowski> mhr3, I think I've reached the limit of 'mark as deprecated' for today ;)
[12:36] <karni> mhr3: I'm happy to see std::vector<Variant> go away. I love STL, but this didn't look right.
[12:37] <mhr3> karni, but if you changed the VariantBuilder to VariantMap and kept the vector, it would actually work
[12:37] <karni> mhr3: gotcha :)!
[12:38] <pstolowski> yay for loosely typed apis ;)
[12:39] <mhr3> anyway, /me lunch
[12:43] <Saviq> greyback, so any idea how you built it? dirty build?
[12:43] <greyback> Saviq: must've been
[12:44] <Saviq> greyback, kk
[12:46] <Saviq> greyback, btw, you said you were discussing with mirfolk that this whole quit architecture could use some love, that patch is then only valid until that happens, right?
[12:47] <greyback> Saviq: this was their suggestion on how it should be done
[12:47] <Saviq> greyback, ok
[12:48] <dednick> baaaa!
[12:48] <dednick> 3 times today. not going well
[12:48] <Saviq> dednick, wassup there? :D
[12:49] <Saviq> dednick, you didn't ping tsdgeos this time ;)
[12:49] <dednick> Saviq: yeah. not concentrating!
[12:56] <Saviq> greyback, awesome, this seems to fix the shutdown time indeed, will speed up autopilot tests considerably
[12:58] <greyback> Saviq: good to hear. Did you check the startup-wizard shuts down cleanly too?
[12:59] <Saviq> greyback, not yet, running the u8 suite now
[12:59] <greyback> ok
[12:59] <Saviq> Cimi, pointer on how to test welcome wizard?
[13:11] <karni> Is the organic grid only good for scope results with different text length, or can one achieve the "image organic layout" like in the gallery app?
[13:12] <Saviq> karni, organic grid is _only_ good for images
[13:12] <Saviq> karni, different text length is vertical journal
[13:13] <Saviq> MacSlow, hey, because of lp:~unity-team/unity-system-compositor u-s-c gains a dependency on libandroid-properties-dev, could that be avoided?
[13:13] <Saviq> MacSlow, otherwise we lose arm64 as an arch on which u-s-c built
[13:14] <MacSlow> Saviq, not if we want to keep having artwork-assets correctly scaled based on the provided per-device-grid-unit
[13:15] <MacSlow> Saviq, that dependency is due to having to read the grid-unit from android-properties
[13:16] <MacSlow> Saviq, it's already nasty having to do this... dropping the dependency on libandroid-properties-dev would make it worse... despite I don't know of the top off my head how to solve getting the grid-unit-value in such a case
[13:17] <Saviq> Mirv, ↑
[13:17] <Saviq> wonder if we can have optional deps...
[13:21] <Saviq> or well, maybe libandroid-properties could be built for arm64..
[13:24] <MacSlow> Saviq, why is it not available by default?
[13:24] <Saviq> MacSlow, well, it only makes sense for android... which is only available for x86 + armhf
[13:25] <Saviq> MacSlow, feels like we need to abstract it somehow
[13:26] <Saviq> MacSlow, I'll ask around
[13:26] <MacSlow> Saviq, ok
[13:45] <Cimi> Saviq, you add the upstart file
[13:45] <Cimi> Saviq, and reboot phone
[13:45] <Saviq> Cimi, "the upstart file" found where?
[13:46] <Cimi> Saviq, you might also want to remove the file from .config/ubuntu-system-settings/wizard-has-run after than
[13:46] <Cimi> Saviq, inside wizard folder of a ubuntu system settings branch
[13:46] <Saviq> Cimi, the wizard is in the image already?
[13:47] <Saviq> just without the upstart job?
[13:47] <Cimi> Saviq, yeah I think so
[13:47] <Cimi> is part of system settings
[13:47] <Saviq> k let's see
[13:47] <Cimi> I don't know which version is here
[13:48] <Saviq> Cimi, "creating surface at (0, 58) with size (768, 1222) with title 'Window 1'" doesn'
[13:48] <Saviq> t sound right
[13:48] <Cimi> I recommend https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675 or https://code.launchpad.net/~cimi/ubuntu-system-settings/wizard.privacy
[13:49] <Cimi> Saviq, wizard.wifi has the updated mir support
[13:49] <Saviq> Cimi, k
[13:49] <Cimi> Saviq, pending review since weeks..
[13:49] <Saviq> Cimi, sounds like you should bug people to review :P
[13:49] <Cimi> I did
[13:50] <Saviq> Cimi, bug them more
[13:50] <Saviq> Cimi, what're you up to today btw?
[13:50] <Cimi> seb128, my french friend
[13:50] <Saviq> Cimi, any word on new infographics?
[13:50]  * seb128 looks at Saviq
[13:50]  * Saviq is invisible to seb128
[13:50] <seb128> Saviq, I don't need more being bugged thanks :p
[13:51] <seb128> just more hours in a day
[13:51] <Saviq> seb128, sure you do! ;)
[13:51] <seb128> lol
[13:51] <seb128> ok ok, I can have a look to some u-s-s pending changes now
[13:51] <Saviq> see! :D
[13:51] <seb128> ;-)
[13:51] <Cimi> Saviq, I did the shadow of the carousel but looks bad
[13:52] <Cimi> Saviq, I think I'll wait for the new ubuntushape
[13:52] <Cimi> Saviq, can we bug zoltan more?
[13:52] <Cimi> Saviq, doing infographics this afternoon
[13:52] <Saviq> Cimi, you can bug whomever you want ;)
[13:52] <Cimi> Saviq, but like together
[13:52] <Saviq> Cimi, cool thanks
[13:52] <Cimi> Saviq, we can't wait a year for that
[13:53] <Saviq> Cimi, ok, I'll do that later today/early tomorrow, depending on when he's around
[13:54] <Cimi> Saviq, problem with the shadow and the ubuntushape is that if I add a png with the current ubuntushape
[13:54] <Cimi> Saviq, the bright/white highlight line for the inset effect at the bottom of the ubuntushape clashes with the shadow put below
[13:55] <Cimi> so looks prob 10% better and 5% worse
[13:55] <Saviq> mhm
[14:00] <Saviq> Cimi, is ofono-qt a new dependency you added in one of your branches? it's missing from debian/control apparently
[14:00] <Cimi> Saviq, mmm
[14:00] <Cimi> Saviq, let me check
[14:00] <Cimi> Saviq, we need ofono for simcard
[14:01] <Cimi> Saviq, but I believe that was already in system settings
[14:01] <Cimi> Saviq, https://code.launchpad.net/~cimi/ubuntu-system-settings/wizard.sim-detection/+merge/211976
[14:02] <Cimi> Saviq, should be already there
[14:03] <Saviq> Cimi, hmm indeed it's there, why does cmake complain then :/
[14:07] <Cimi> Saviq, maybe was simply missing from phonemanager
[14:08] <Saviq> Cimi, looks like it's a cross-building issue
[14:27] <mhall119> mhr3: ping
[14:28] <mhr3> mhall119, pong
[14:29] <mhall119> mhr3: hey, can we setup the scopes api to auto-publish new docs?
[14:31] <mhr3> mhall119, what's necessary for that?
[14:32] <mhall119> mhr3: I have a script you can run against the doxygen output, and an auth token to let you push it to the server
[14:32] <greyback> dandrader: hey, <mlankhorst> was asking about bug 1307701 on #ubuntu-desktop, perhaps you can help him?
[14:32] <mhall119> we just need to integrate that into your release process so that it runs whenever you update the packages containing them
[14:33] <dandrader> greyback, we've been talking. that's the bug I've been working on for quite a few days now
[14:33] <mhr3> mhall119, hm, need to think where that could be done, will get back to you once meeting ends :)
[14:33] <greyback> dandrader: yes that I knew. Ok, I wasn't aware you two were already talking
[14:33] <mhall119> mhr3: ok, let me know if you want to do a hangout to discuss it
[14:45] <karni> mhr3: Do you know if emblem image would work when overlay is enabled? Our team discussed that, it is a valid use case to require an overlay on the card image, to surface provider of given result. Be it music, clothes, perfumes or music equipment stores, suppose we use large cards with overlay enabled - we'd still want to show the shop/distributor logo in there.
[14:45] <karni> mhr3: If you're not the proper person to ask, I'll ping someone else :)
[14:46] <kgunn> where be mterry ?
[14:46] <Saviq> kgunn, didn't see him today yet
[14:47] <davmor2> kgunn: he's heard you were after him so wisely hid? ;)
[14:47] <kgunn> probably :)
[14:48] <Saviq> kgunn, actually IRC says he was here, last exited ~1.5h ago
[14:48] <kgunn> Saviq: he had a lightdm config change up for landing (to move the dir location)...did that get landed ? ...i didn't get silo until late friday..but i don't see it now on the ci-train backend
[14:49] <kgunn> spreadsheet still looks wonky
[14:49] <Saviq> kgunn, wrong spreadsheet
[14:49] <Saviq> kgunn, there's a new one https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=0
[14:49]  * kgunn still behind on mails
[14:50] <Saviq> kgunn, but yeah, I landed that change
[14:50] <kgunn> thanks sir!
[14:59] <Saviq> Cimi, can you please look into bug #1316629 with karni
[15:00] <Cimi> Saviq, noticed the issue, yes I can
[15:02] <dednick> greyback: hey. how does unity8 know what y position to bound apps to (ie displacement of the panel)
[15:03] <greyback> dednick: unity-mir does that, see ApplicationManager::placeSession
[15:03] <dednick> greyback: ah. manually calced panelHeight...
[15:03] <greyback> dednick: yep :(
[15:04] <Saviq> seb128, was system settings X-buildable at any point?
[15:04] <dednick> greyback: umm. possible to change to a property set by unity8?
[15:04] <greyback> dednick: sure. What's the problem you're trying to solve?
[15:05] <dednick> greyback: we have a new "active call hint" which basically displaces the panel by another 3gu (only when we have a call active)
[15:05] <Saviq> seb128, the aftermath of trying to install the deps for it looks crazy http://paste.ubuntu.com/7404996/ :D
[15:05] <seb128> Saviq, yes, for most of the trusty cycle (and in trusty release afaikà
[15:05] <greyback> dednick: oh man, that's not going to be easy - the qtcompositor work would help you a lot with that
[15:06] <seb128> Saviq, is that trusty or utopic?
[15:06] <Saviq> seb128, utopic
[15:06] <dednick> greyback: yeah. active apps are going to be a pain... not really wure what the ui story is though. If we're supposed to displace apps or what...
[15:06] <dednick> guess i should check with design
[15:06] <greyback> dednick: how urgent is this?
[15:07] <seb128> Saviq, I guess we had regressions there then :/ maybe xnox can help you
[15:07] <Saviq> seb128, indeed...
[15:07] <dednick> greyback: um. dunno. i don't thin it's on a "urgent list"
[15:07] <Saviq> xnox, another X-build log... this one's heavy http://paste.ubuntu.com/7404996/
[15:08] <dednick> greyback: i'll just put it through and log a bug for now :)
[15:08] <dednick> "undocumented feature"
[15:08] <greyback> dednick: I just don't want you working hacking on a tricky solution with the existing unity8/mir design, that the QtCompositor work will make much much easier
[15:09] <dednick> greyback: no matter. deisgn will probably change their mind and decide they just want to colourize the panel anyway....
[15:09] <greyback> dednick: :)
[15:10] <mhr3> karni, i think we wanted to add a special image_attribution attribute
[15:11] <mhr3> karni, and that would work no matter what overlay is set to
[15:11] <karni> mhr3: sounds great to me. please treat that as clear guidance from the phone delivery team this is a feature we would really want to have.
[15:11] <mhr3> Saviq,  is that right^?
[15:12] <karni> mhr3: where would the overlay be located? upper right? (bottom is taken by the overlay)
[15:12] <mhr3> don't think there are designs for that
[15:12] <Saviq> mhr3, I don't think we agreed ultimately, but yeah something like this would be needed (/!\ in the spec /!\)
[15:12] <karni> mhr3: okay, I'm happy to pull some strings
[15:13] <mhr3> mikenagle_, ^^
[15:15] <Saviq> seb128, xnox, false alarm, it looks like trunk builds fine, but the wizard branches don't
[15:15] <seb128> Saviq, ok, "good" ;-)
[15:26] <Saviq> seb128, ok no, I take that back, it's not working even in trunk, but I don't understand what's happening :|
[15:26]  * Saviq tries with a fresh chroot
[15:28] <Saviq> alecu, it'd have to be Thu or earlier than that, I can't go past 4pm UTC either tomorrow
[15:33] <karni> I have a UI question/feedback regarding Previews: I have a preview, with "More..." (collapsed 2 buttons) and "Buy" at the bottom. When I press "More...", I imagine the screen would scroll, so that I can see those additional buttons. Instead, they overflow at the bottom of the screen, and I have to manually scroll down to see them. Should I file a bug?
[15:34] <karni> Actually, I'll file it, and you guys decide what you want to do with it :)
[15:34] <Saviq> karni, yeah, the combo button is a hack, waiting for a proper SDK implementation
[15:35] <Saviq> karni, but file a bug nevertheless, please write "should use expandable components from the SDK"
[15:35] <karni> ack. then certainly will log a bug
[15:35] <karni> ok!
[15:37] <karni> https://bugs.launchpad.net/unity8/+bug/1316660
[15:48] <tsdgeos> Saviq: fginther: any idea of what's up with https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/1780/console ?
[15:48] <Saviq> tsdgeos, trusty
[15:48] <tsdgeos> ah
[15:48] <tsdgeos> obvious :D
[15:48] <tsdgeos> can we get it to utopic?
[15:49] <Cimi> karni, I think unity8 code is fine, you sure is the property properly sent? https://bugs.launchpad.net/unity8/+bug/1316629
[15:49] <fginther> tsdgeos, work to move it is in progress, it's a little more work as it requires some VM setup. I'm hoping to have it working tomorrow
[15:50] <mhr3> fginther, hey, any chance to migrate ci T->U for unity-scope-mediascanner?
[15:50] <karni> Cimi: Isn't the code that I pasted correct? If it is, and I can see the "text" field (the "price" key mapps to correct value) - I should be able to see the hardcoded "title" field (with value "Price")
[15:50] <tsdgeos> fginther: cool :)
[15:51] <Cimi> karni, I think it is, but unity might not receive this title thing
[15:51] <karni> Cimi: what do you mean by unity might not receive this title thing?
[15:51] <karni> Cimi: wouldn't that be the bug I reported?
[15:51] <Saviq> mhr3, we need to exted unity-scope-tool to understand previews
[15:51] <Saviq> ↑↑
[15:51] <Cimi> karni, http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/qml/Dash/Previews/PreviewTextSummary.qml#L45
[15:52] <karni> Cimi: I can see "3.14 EUR" as "text", but can't see "title" as "Price. so, unity receives the data, but doesn't show the title
[15:52]  * karni looks
[15:52] <fginther> mhr3, that was migrated yesterday. All projects should be building on utopic now
[15:52] <Cimi> karni, I have this widgetData["title"], maybe this property is not defined
[15:52] <Saviq> karni, sure, it might be that it's not unity8 at fault but unity-scopes-shell
[15:52] <mhr3> fginther, hmm - https://code.launchpad.net/~jamesh/unity-scope-mediascanner/scope-tests/+merge/217731
[15:52] <karni> Saviq: It might be. That's why I came here to ask for your teams opinion :)
[15:52] <Saviq> karni, can you add some debugs in there to make sure widgetData["title"] is populated?
[15:52] <mhr3> fginther, didn't cut it?
[15:53] <fginther> mhr3, i'll rerun that one now
[15:53] <mhr3> Saviq, what do you mean?
[15:53] <Cimi> Saviq, karni that is my first guess, preview is tested to dinamically add/remove title and works
[15:53] <karni> hrm
[15:53] <mhr3> Saviq, udnerstand how?
[15:53] <Saviq> mhr3, I mean that we need to display the preview data in the tool
[15:53] <Saviq> mhr3, and allow modifying it
[15:53] <Saviq> seb128, bug #1316667
[15:53] <mhr3> Saviq, hmmm
[15:53] <karni> Cimi: yeah, that code looks fine
[15:53] <mhr3> Saviq, would be nice
[15:53] <Saviq> mhr3, would be indeed! ;)
[15:53] <seb128> Saviq, thanks
[15:54] <mhr3> Saviq, should do the same for results though
[15:54] <Saviq> mhr3, sure
[15:54] <seb128> Saviq, u-s-s didn't change much, not sure it's ours
[15:54] <mhr3> Saviq, and i don't think sdk has some kind of dataview component
[15:54] <Saviq> seb128, I'm sure it's not
[15:54] <seb128> Saviq, said differently, it might stalled reported here
[15:55] <karni> Saviq: if you mean to add debug logs to unity8, I'm afraid I don't have time for that ATM to build it all. But if there's noone else to try it, I guess I have no choice.
[15:55] <Saviq> seb128, sure, but I'm actually unable to understand what did change, I can install all of those deps manually just fine (not that it builds, but that's another topic - it fails to locate some packages via pkg-config)
[15:55] <Saviq> karni, no need to build
[15:55] <Saviq> karni, just change in the qml
[15:55] <karni> Saviq: oh, that's what you mean
[15:56] <karni> sure
[15:56] <Saviq> karni, http://paste.ubuntu.com/7405273/
[15:56] <seb128> Saviq, we need xnox to help
[15:56] <seb128> or maybe Laney (but he's off today)
[15:56] <Saviq> seb128, indeed
[15:57] <Saviq> karni, there's a BUT
[15:57] <Saviq> karni, it works in the scopes scope
[15:57] <karni> ORLY
[15:57] <Saviq> karni, if you long-press Amazon, it displays Description
[15:58] <karni> Saviq: You're talking about the widget of type "header"?
[15:58] <karni> Saviq: or about what is under the "Search" button
[15:58] <Saviq> karni, what are you talking about :D
[15:58] <Saviq> karni, I thought you talked about widget type "text"
[15:58] <karni> Saviq: widget of type "text" that has "text" field required, and optional "title" field
[15:58] <karni> correct
[15:58] <Saviq> karni, yeah, under the Search button
[15:58] <karni> I'm in the preview of Amazon scope
[15:58] <Saviq> karni, "Description" is the title
[15:58] <Saviq> karni, of that widget
[15:59] <karni> Saviq: "This is an Ubuntu search...." that is the title of "text": "Online Shopping...", yes?
[15:59] <Saviq> karni, no
[15:59] <Saviq> karni, "Description", literal
[15:59] <mhr3> karni, http://developer.ubuntu.com/api/devel/ubuntu-14.04/cplusplus/unity-scopes/previewwidgets.html#text
[16:00] <karni> I see no "Description" on that page
[16:00]  * Saviq screenshots
[16:00] <karni> I flashed trusty proposed today
[16:00] <karni> mhr3: You're showing me the documentation I pointed you at :D?
[16:00] <karni> title Optional string
[16:00] <karni> text A string containing the text
[16:00] <karni> that is exactly what I'm talking about - optional "title" does not work for me, mhr3
[16:00] <Saviq> no I'm not :|
[16:00] <Saviq> karni, TRUSTY? :P
[16:00] <Saviq> karni, you're so old school
[16:00] <karni> Saviq: that was to mhr3
[16:00] <karni> Saviq: lol
[16:00] <mhr3> karni, oh did you... sorry just read the bottom :)
[16:01] <mhr3> karni, anyway, that works and is used :)
[16:01] <Saviq> screenshot no worky :|
[16:01] <karni> ok guys, let me see the amazon code, and I'll take it from there
[16:01] <karni> if I have a "text" widget with title and text, only text field shows up
[16:02] <Cimi> karni, if you not set text, what happens?
[16:02] <karni> if you want, mark the bug as incomplete, I'll make sure it's complete
[16:02] <karni> Cimi: well, I haven't tried not setting text on a text widget, but I can try
[16:02] <Saviq> karni, ah you're doing mapping
[16:02] <karni> I think nothing will show up, let me try
[16:02] <Saviq> karni, you don't want that
[16:02] <karni> Saviq: title is hardcoded, text is mapped
[16:02] <mhr3> karni, wait... it actually doesn't work
[16:02] <karni> I'm lost you guys :D
[16:02] <Cimi> karni, one mistake I can think of the backend is replacing the title settings with only the text settings
[16:03] <Cimi> karni, or rather try adding title after text
[16:03] <Saviq> karni, you're in mhr3's hands
[16:03] <karni> Cimi: I can try that
[16:03] <karni> Saviq: thanks pal
[16:03] <karni> :)
[16:03] <Saviq> karni, but, IIUC
[16:03] <Saviq> karni, you should add_attribute_value
[16:03] <Saviq> karni, not add_attribute_mapping
[16:03] <karni> :O
[16:03] <Saviq> karni, mapping maps from the result to preview
[16:04] <Saviq> karni, value sets the value
[16:04] <karni> that could have been it, and would explain why nothing showed up. f**k
[16:04] <mhr3> Saviq, do you actually see "Description" in scopes scope?
[16:04] <mhr3> cause i don't
[16:04] <Saviq> mhr3, I do
[16:04] <Saviq> mhr3, on desktop, too
[16:04] <Saviq> on phone, too
[16:04] <mhr3> maybe my version is just old
[16:04] <Saviq> I mean in tool as well
[16:04] <karni> Cimi: the code I pasted here is then incorrect https://bugs.launchpad.net/unity8/+bug/1316629
[16:04] <mhr3> and i forgot my phone at home
[16:05]  * karni tries _value()
[16:05] <Saviq> karni, IIUC price.add_attribute_mapping("title", "Price"); tries to map a "Price" attribute of the _result_ to the preview, but the result has no such attribute
[16:05] <karni> Saviq: that would be correct, Sir
[16:07] <karni> Cimi: Marked bug as Invalid
[16:07] <karni> Consider kicking me from this channel. Man I'm sneaky it took three people to notice my bug in 3 lines of code. I'm sorry!
[16:18] <Cimi> Saviq, https://code.launchpad.net/~cimi/unity8/preview-text-summary-bottom-padding/+merge/217903
[16:19] <Saviq> Cimi, good bugging! will get to it tomorrow
[16:19] <karni> Saviq: I justed asked Cimi about that very bug. I suspect there's no chance this will get into image tomorrow?
[16:20] <karni> Saviq: asking cose of demo Thu morning. If not, I can avoid using that for now.
[16:20] <Saviq> karni, yeah, no chance
[16:20] <karni> Saviq: ack, np
[16:20] <Saviq> karni, it's qml only, you could just patch it in on device ;)
[16:20] <karni> Saviq: heheheh, true
[16:21] <karni> I'm not the one doing the demo, so I'll refrain from dirty patches :) but thanks!
[16:21] <Cimi> Saviq, naybe we cab have it in a silo>?
[16:22] <karni> as far as I'm concerned, don't worry, really.
[16:25] <karni> Cimi: allow me to file a bug and link to that branch, so I can point to it from code. don't want to be pasting MP links in there :)
[16:25] <Cimi> ok
[16:27] <karni> Cimi: in lp, can you please link bug https://bugs.launchpad.net/unity8/+bug/1316683 to branch https://code.launchpad.net/~cimi/unity8/preview-text-summary-bottom-padding
[16:28] <Cimi> done
[16:28] <karni> thank you
[17:56] <mhr3> mhall119, ping?
[18:05] <mhall119> mhr3: pong
[19:08] <mterry> Saviq, another change in silo 002 please:  remove the lightdm branch and rekick USC and unity8
[19:09]  * mterry goes and tests split autopilot tests now that QA landed the change
[19:10] <mhr3> alecu, could you check out click from 005?
[19:10] <alecu> mhr3: sure thing
[19:10] <mhr3> alecu, although... i can do it, going to check the rest anyway
[19:16] <Saviq> mterry, doing, will add the egl prerequisite explicitly, too
[19:16] <mterry> Saviq, OK
[19:16] <Saviq> mterry, seen my comment on it?
[19:17] <mterry> Saviq, no?  Let me look
[19:18] <mterry> Saviq, noted.  We can respin the silo for that and whatever autopilot fixes u8 requires later
[19:18] <Saviq> mterry, yup
[19:21] <Saviq> mterry, build kicked, will not notify you about it since we'll be missing the arm64 build of u-s-c
[19:21] <Saviq> (bot will not)
[19:58] <Saviq> josharenson, hey, bugs should only get marked "fix committed" when things are in trunk (or well, maybe devel that we don't use in unity8)
[19:58] <Saviq> josharenson, so "in progress" is usually the last status before landing a change
[19:59] <josharenson> saviq, alright. Were there any bzr hooks (like putting 'fixes lp:12345' in commit) or procedural issues that I missed?
[20:00] <Saviq> josharenson, --fixes lp:12345 when committing, yeah, it would have linked automagically
[20:00] <greyback> Saviq: "UK was off, so Gerry was off, too." <- tut tut tut
[20:00] <Saviq> greyback, ;)
[20:00] <Saviq> josharenson, but even if you missed that, there's a "Link a related branch" link on the right here: https://bugs.launchpad.net/unity8/+bug/1269282
[20:01] <Saviq> josharenson, and a corresponding "Link a bug report" halfway down https://code.launchpad.net/~josharenson/unity8/doc_args
[20:02] <Saviq> josharenson, has the same effect - the bug will be marked released for the Ubuntu task
[20:02] <Saviq> when the package gets into distro
[20:03] <josharenson> saviq, so link the branch after its released?
[20:03] <Saviq> josharenson, no, link it as soon as it's up
[20:03] <Saviq> josharenson, if you commit with --fixes lp:12345
[20:03] <Saviq> josharenson, LP will link it for you
[20:03] <josharenson> ack
[20:03] <Saviq> josharenson, then, when it's released, LP will mark the bug Fix Released
[20:03] <josharenson> saviq, oh thats convenient and fancy
[20:04] <Saviq> josharenson, yeah, it will also put the changelog and info where the package was fixed in a comment
[20:04] <Saviq> josharenson, one unfortunate distinction is that LP is made for upstream projects as well as distros
[20:05] <Saviq> josharenson, which means a bug can affect the upstream project, a distro package of that project, both, or even more (like target a particular distro release)
[20:05] <Saviq> josharenson, distro generally means Ubuntu for us
[20:06] <josharenson> ok
[20:06] <Saviq> josharenson, so e.g. https://bugs.launchpad.net/unity8/+bug/1281728
[20:07] <Saviq> josharenson, actually has 4 "tasks" - upstream Mir, upstream Unity8 and Ubuntu packages for both
[20:07] <josharenson> saviq, i see
[20:07] <Saviq> josharenson, which could in theory be disjoint (they are for Mir, for example), but for unity8 there could be only one
[20:07] <Saviq> josharenson, the adverse effect is that LP only closes the package bugs, not the upstream ones
[20:08] <Saviq> josharenson, and well, we have to disjoing bug lists...
[20:08] <Saviq> josharenson, ideally we would only have Ubuntu bugs, but that'd mean some of us would need to get on https://wiki.ubuntu.com/UbuntuBugControl
[20:08] <Saviq> to get the rights to triage Ubuntu bugs
[20:08] <Saviq> but well, maybe that's a route forward, I need to think
[20:09] <Saviq> end-of-lecture :)
[20:09] <josharenson> haha thanks
[20:11] <Saviq> mterry, u-s-c and u8 built in silo 002
[20:11] <Saviq> I'm cancelling the build job
[20:19] <mhr3> alecu, i don't see any .ini translations for click, is that expected?
[20:21] <mhr3> alecu, maybe ping dobey about that :)
[20:37] <mhr3> mhall119, and ping once again?
[21:14] <mhall119> mhr3: pong once again
[21:15] <mhr3> mhall119, lucky, was about to close this window for today :)
[21:15] <mhr3> mhall119, so the doc
[21:15] <mhr3> s
[21:16] <mhr3> mhall119, i was wondering where could we hook the upload, but i don't really see any place without pushing the key to bzr or something like that
[21:16] <mhall119> mhr3: we don't want the key somewhere public
[21:17] <mhr3> figured
[21:17] <mhr3> what would you suggest?
[21:17] <mhall119> mhr3: I was thinking it would go into the jenkins configs or something internal
[21:18] <mhr3> mhall119, maybe the actual publisher that pushes stuff to distro?
[21:18] <mhr3> mhall119, then projects could just be marked as "exports_docs" and when pushing such a project, it would push the docs as well
[21:19] <mhall119> mhr3: that would work too
[21:19] <mhr3> but didier is the one who'd be able to make that happen
[21:19] <mhr3> mhall119, let's schedule a meeting with him tomorrow?
[21:19] <mhall119> as long as the doxygen output is available and it can run python with access to the internet (or at least a site on prodstack)
[21:20] <mhall119> mhr3: tomorrow is good, I have an hour block at 11am US/Easter where I'm unavailable but otherwise I'm free
[21:21] <mhr3> mhall119, my afternoon is clear too
[21:24] <mhr3> mhall119, sent invite, time ok? or too early for you?
[21:25] <mhall119> mhr3: that works for me
[21:27] <mhr3> mhall119, eh, sorry, was looking at tuesday instead of wed
[21:27] <mhr3> you got overlap there
[21:27] <mhr3> mhall119, ok to move it 30mins later?
[21:29] <mhall119> mhr3: no need, that's a core apps IRC meeting that popey runs, I'm not needed there
[21:30] <mhr3> mhall119, ok
[21:30] <mhr3> so talk to you tomorrow
[22:00] <Saviq> josharenson, did you see my comment https://code.launchpad.net/~josharenson/unity8/doc_args/+merge/217840/comments/520182 ?
[22:01] <josharenson> saviq, got it
[22:01] <Saviq> josharenson, can't merge your branch until that's done, tags in bzr are rather viral...
[22:05] <josharenson> saviq there is no change after running that script?
[22:14] <josharenson> saviq, like I removed the tags, but what is there to push now?
[22:14] <Saviq> josharenson, no pushing
[22:15] <Saviq> josharenson, you need to push it on every copy of the branch separately
[22:15] <Saviq> josharenson, tags in bzr are unfortunately orthogonal to commits
[22:15] <Saviq> josharenson, which means whenever you push / pull, you populate all the ones that didn't exist in the branch you push/pull to
[22:16] <Saviq> or maybe should I say parallel, actually
[22:16] <josharenson> saviq, sure, but how do I make lp aware of this?
[22:16] <Saviq> josharenson, you run the script on lp:~josharenson...
[22:16] <josharenson> oh duh


[12:57] <frankban> rick_h_: ping
[12:57] <rick_h_> frankban: pong
[12:58] <frankban> rick_h_: could you please take a look at my comments on https://codereview.appspot.com/52080044/ ?
[12:58] <frankban> rick_h_: (and thanks for your great QA)
[12:58] <rick_h_> frankban: looking
[12:58] <rick_h_> sorry, slow start this morning
[12:59] <frankban> rick_h_: np, just re-proposed
[13:02] <rick_h_> frankban: sounds good for the most part. I'm a very cli heavy person so I often found the quickstart very chatty overall which I ack is a personal preference kind of thing.
[13:03] <rick_h_> frankban: I'll try to dupe the one where I created reran quickstart and went to 'use' an environment and it went back through the install ppa, etc process
[13:03] <rick_h_> and very cool on "f you accidentally removed a
[13:03] <rick_h_> bootstrapped environment from the envs.yaml file
[13:03] <rick_h_> you can still destroy it passing its name to
[13:03] <rick_h_> `juju destroy-environment`. "
[13:03] <rick_h_> I wasn't aware of that
[13:03] <frankban> rick_h_: heh, I believe we are not exactly the target for quickstart ;-) or at least, it is intended to be used also by others
[13:04] <rick_h_> frankban: understood...but but but :)
[13:04] <rick_h_> frankban: on the plus side I asked jcastro and lazypower looked at it as well to try to get some more QA
[13:04] <rick_h_> and they had nothing but "Awesome!" and "shipit!" to say about it
[13:04] <frankban> rick_h_: awesome, good move! thanks!
[13:04] <rick_h_> and I was trying to be hyper critical due to 1.0 and such
[13:05] <frankban> rick_h_: could you please run the interactive session again to check UI changes (after pulling the branch)?
[13:05] <rick_h_> frankban: so let me get my coffee going and I'll try to reproduce the one issue, then update and rerun some QA on the updates. And thanks for those.
[13:05] <frankban> cool
[13:05] <frankban> thank you
[13:41] <rick_h_> frankban: ok, I can't dupe my thing with the ppa now. I'm not sure how I hit that. I did end up hanging quickstart because my lxc launch errored and quickstart hung with bringing up the gui
[13:42] <hatch> morning
[13:42] <rick_h_> frankban: not sure if we care or if this is just a corner case http://paste.ubuntu.com/6762128/
[13:42] <frankban> rick_h_: what's the last message from quickstart?
[13:43] <rick_h_> frankban: sorry, terminal is cleared when I ctrl-c'd quickstart. It was about 'bringing up juju-gui'
[13:43] <rick_h_> during the deploy the gui step
[13:43] <rick_h_> but it seemed to hang
[13:44] <rick_h_> I'm having some issues in QA as lxc and trusty have some issues atm
[13:45] <frankban> rick_h_: ok, does this happen also in a fresh lxc install?
[13:45] <frankban> rick_h_: I mean trusty + lxc
[13:50] <rick_h_> frankban: I'm not sure. I've got a few different kinds of errors I'm working around atm
[13:51] <frankban> rick_h_: could you please reproduce the error running quickstart with --debug?
[13:51] <frankban> rick_h_: and paste the output (warning: password is in the debug output)?
[13:52] <frankban> rick_h_: if that error is included in the megawatcher data it could be trivial to avoid quickstart to hang
[13:53] <rick_h_> frankban: sure thing. Let me try to set it up again
[13:53] <frankban> rick_h_: thanks
[13:57] <rick_h_> frankban: yea, looks like there is some api stuff. This is a slightly different error. I've so confused my local lxc with all this testing. https://pastebin.canonical.com/103053/
[14:04] <frankban> rick_h_: I see. So the machine is in an error state. Quickstart only watches the unit. This is not related to this branch, but it maybe should be handled by another branch before 1.0. What do you think?
[14:04] <rick_h_> frankban: sounds ok to me. Seems like this might get us too many chasing error reports.
[14:06] <frankban> rick_h_: this should not happen, but when it does, quickstart effectively hangs, because the unit will be forever in an "pending" state
[14:06] <rick_h_> frankban: right, and I've done it in two ways in an admittingly broken ways
[14:08] <frankban> rick_h_: ok, so 1.0 can wait for this to be handled, and it will be my next card. if you agree, I;ll ask you to reproduce the machine error again later, to check quickstart no longer hangs.
[14:09] <rick_h_> frankban: cool
[14:09] <rick_h_> I live to fail for you :)
[14:09] <frankban> rick_h_: :-) other comments?
[14:10] <rick_h_> frankban: going back through the email
[14:12] <rick_h_> frankban: looks good. the newline from the initial landing UI before the first bullet isn't there, but that's a tiny thing.
[14:12] <frankban> rick_h_: I see it
[14:13] <frankban> rick_h_: I mean, I see the new line here
[14:13] <frankban> rick_h_: before "automatically create and bootstrap a local environment"
[14:14] <rick_h_> frankban: correct
[14:14] <rick_h_> oh hmm, maybe terminal differences then
[14:15] <frankban> rick_h_: do you see "new Amazon EC2 environment" below?
[14:15] <frankban> (just to check I correctly pushed all the changes)
[14:17] <rick_h_> frankban: nvm, ignore me
[14:17] <rick_h_> I see it
[14:17] <frankban> rick_h_: ok
[14:34] <hatch> oo boy I love bugs that only show up on prod
[14:36] <rick_h_> wheee
[14:36] <rick_h_> the nice thing is that with the charm now you can run 'prod' but uncompressed files I think.
[14:37] <hatch> well I can dupe locally so that's nice
[14:51] <hatch> rick_h_ https://codereview.appspot.com/52790043/diff/60001/hooks/utils.py isn't git available already on juju instances?
[14:52] <rick_h_> hatch: doing reviewer comments atm
[14:52] <rick_h_> hatch: if so then it should be fine, but not 100% sure
[14:52] <rick_h_> if you create an lxc container env is it?
[14:53] <hatch> well I was pretty sure that juju used git to keep track of something-or-other
[14:53] <rick_h_> I didn't realize that at all
[14:56] <hatch> so including it probably doesn't hurt anything either :)
[14:56] <rick_h_> explicit > implicit says the Python heroes of old
[14:58] <rick_h_> jujugui so I've got the charm supporting git branch up for rewview with qa instructions and reviewer comments. https://codereview.appspot.com/52790043/
[14:58] <rick_h_> any takers? /me looks at hatch
[14:58] <hatch> Python....Python....that's the language they replaced with Ruby right?
[14:58] <hatch> :P
[14:58] <bac> rick_h_: you need one or two?  i'll do one.
[14:59] <rick_h_> bac: I think I just need one.
[14:59] <bac> rick_h_: well i'll be glad to unless you want hatch.rb to do it
[15:00] <hatch> if bac can take it that would be awesome, I'm trying to track down a bug in browser.js
[15:00] <hatch> in compressed files
[15:00] <rick_h_> bac: I appreciate a true developers insight into the review
[15:00] <hatch> lol
[15:00] <bac> rick_h_: i thought you might
[15:01] <bac> rick_h_: let me get this proposal written first (warning)
[15:01] <rick_h_> bac: np, thanks
[15:03] <hatch> ugh consolemanager code can die in a fire
[15:08] <bac> benji: is your bundle branch likely to be finished today?  i'd like to do a release of charmworld this afternoon to avoid the friday disappointment.
[15:09] <jcastro> hey rick_h_
[15:10] <jcastro> do you know the tldr on charm store pages?
[15:10] <jcastro> like how you guys were going to bust them out to be separate from the gui?
[15:10] <rick_h_> 'charm store pages'?
[15:10] <rick_h_> jcastro: tldr is that it's back burnered and possibly part of other things that will solve the problem in different ways
[15:10] <jcastro> ok
[15:10] <rick_h_> from people way high up
[15:10] <jcastro> any word on SEO/URL fixes then?
[15:10] <jcastro> here's our problem
[15:10] <rick_h_> no
[15:11] <jcastro> we're doing a charm audit, and we can't find our charms
[15:11] <jcastro> so, I end up on an out of date github imported page
[15:11] <rick_h_> understood
[15:11] <rick_h_> I think it's been thought that the cleaned up pages on manage.jujucharms.com are a 'good enough' stop
[15:11] <jcastro> hmm, should I whine to escalate? If we can't find our own charms how are users going to find them
[15:12] <rick_h_> if that's not true, you can bring it up and such, but there's nothing planned atm
[15:12] <rick_h_> at least that I'm aware of, I don't know if some other team/etc is thinking or looking into it.
[15:12] <jcastro> ok
[15:12] <jcastro> I'll bring it up at the cross team
[15:13] <rick_h_> sounds good
[15:13] <jcastro> which I think is today?
[15:13] <rick_h_> no idea, gary is out until tomorrow so if it's today he won't be there from us
[15:13] <lazypower> yeah
[15:13] <lazypower> in about an hour and a half
[15:13] <jcastro> ok no worries, it's in an hour and 15
[15:13] <bac> oh, benji isn't here today is he?
[15:13] <jcastro> rick_h_, is URL-niceness part of that work or is that a different thing?
[15:13] <rick_h_> bac: oh right, he's out until monday
[15:14] <bac> i guess his work won't land.  pfft.
[15:14] <rick_h_> jcastro: quick call?
[15:14] <rick_h_> bac: yea, sorry. he chatted with me about handing it off, but since everyone is out we thought it could wait
[15:14] <rick_h_> sorry to mess up the deploy
[15:14] <jcastro> rick_h_, yeah fire it up!
[15:14] <bac> rick_h_: not messed up.  i'll go ahead with my stuff.
[15:15] <bac> rick_h_: or i can pick up his branch this afternoon.
[15:45] <bac> rick_h_: when you have time could you review https://codereview.appspot.com/51010046/ ?
[15:45] <hatch> oh man this bug that I'm working on has existed forever
[15:45] <hatch> heh oops
[15:45] <rick_h_> bac: sure thing
[15:50] <hatch> jujugui call in 10
[15:56] <hatch> ugh yet another double dispatch bug
[15:56] <hatch> can we just start over?
[15:56] <hatch> lol
[15:58] <hatch> jujugui call in 2
[16:00] <hatch> hmm apparently hangouts hates me
[16:22] <rick_h_> hatch: hah, but we managed to keep you connected the whole time
[16:22] <rick_h_> your interwebs are strange up there in canada
[16:23] <hatch> lol
[16:23] <hatch> I just rebooted my router, running on hotspot now
[16:23] <hatch> hopefully the reboot fixes it
[16:51] <frankban> rick_h_: before I proceed, could you please check that lxc/trusty error using lp:~frankban/juju-quickstart/handle-machine-errors (it's just a prototype).
[16:52] <rick_h_> frankban: sec, yep
[16:52] <frankban> rick_h_: thanks
[16:57] <rick_h_> frankban: ever seen ERROR TLS handshake failed: x509: certificate signed by unknown authority ?
[16:59] <hatch> rick_h_ you've been h4z0r3d
[17:01] <frankban> rick_h_: never
[17:01] <rick_h_> bah, I can't fail the same way twice wheeeee
[17:02] <hatch> lol
[17:04] <frankban> rick_h_: was that handled by quickstart?
[17:05] <rick_h_> frankban: no, I had this before but got around it somehow
[17:05] <rick_h_> now I can't seem to get around it
[17:05] <rick_h_> asking in #juju about it.
[17:06] <frankban> rick_h_: maybe removing the jenv file?
[17:08] <rick_h_> juju-quickstart: error: machine 1 is in an error state: error: container "rharding-test2-machine-1" is already created
[17:08] <rick_h_> frankban: ^
[17:08] <rick_h_> looks good to me
[17:08] <frankban> rick_h_: great
[17:09] <frankban> thanks
[17:18] <jcastro> rick_h_, now that I have seen
[17:18] <jcastro> juju leaving containers around
[17:18] <rick_h_> jcastro: yep
[17:18] <rick_h_> frankban: is making quickstart watch for stuff like that so it doesn't hang for the user
[17:18] <rick_h_> but errors out properly
[17:18] <hatch> jcastro hey I have had a request for bundle level configuration options.... say you have a bundle and you want to deploy it in devel/debug/prod modes
[17:19] <hatch> anyone brought anything like that up yet?
[17:19] <hatch> right now you would need 3 bundles
[17:19] <rick_h_> bundle inheritance?
[17:19] <rick_h_> bac and benji were getting that working in proof/charmworld
[17:19] <hatch> imho it sounds like it could be doen with 'stacks'
[17:20] <hatch> how were they planning on doing it now?
[17:20] <hatch> ping a configuration server?
[17:20] <bac> hatch: it works now on staging
[17:20] <rick_h_> no, but I mean if you create a bundles.yaml with 3 bundles
[17:20] <rick_h_> and defined a base set of charms/config
[17:20] <bac> hatch: no, you have three different stanza, each inheriting from a base with mods
[17:20] <rick_h_> and override it using inheritance
[17:21] <rick_h_> so you'd have name-debug, name-devel, name-prod bundles
[17:21] <rick_h_> and pick the one you want to deploy
[17:21] <hatch> hmm I didn't know that was possible
[17:21] <hatch> to have a 'base' dundle
[17:21] <rick_h_> the bundles.yaml file can contain several bundles in there. Just have to name them differently
[17:21] <bac> any bundle can inherit from any other in a deployer config file  (basket)
[17:22] <hatch> ohh cool, what's the syntax for that?
[17:22] <bac> rick_h_: is that why it is bundles.yaml and bundle.yaml?
[17:22] <bac> inherits: other
[17:22] <rick_h_> bac: I *guess*?
[17:22] <rick_h_> oh, no idea. I thought it was always bundles.yaml
[17:22] <rick_h_> when it is bundle.yaml?
[17:22] <bac> no,never
[17:22] <jcastro> hatch, wouldn't you deploy the same bundle to 3 environments? devel/debug/prod?
[17:22] <bac> i'm just saying that's why that name was picked
[17:22] <rick_h_> jcastro: but in debug there'd only be one unit, and different config
[17:23] <jcastro> oh I see
[17:23] <rick_h_> jcastro: bug in devel it's scale out, maybe use a cache layer not in debug
[17:23] <jcastro> it would be neat to arbritrarily pass along config and units to parts of a bundle
[17:23] <jcastro> "deploy this bundle but only one of each"
[17:23] <rick_h_> right, there's a pre-deployment config story that's on the radar currently
[17:23] <rick_h_> but it's done on each bundle deploy and not part of the file itself
[17:24] <rick_h_> so not quite the same use case, but should be handy
[17:24] <jcastro> but at the same time, forking/cloning a bundle is cheap
[17:24] <jcastro> and they don't contain _too_ much logic
[17:24] <rick_h_> right, but you'd want them in the same file
[17:24] <rick_h_> fix a config bug and find all the forks fml
[17:24] <jcastro> so like myapp-prod, myapp-dev and -debug isn't too bad
[17:24] <rick_h_> right
[17:24] <jcastro> oh right
[17:24] <jcastro> yeah that does sound nice
[17:25] <hatch> bac can you link me to the bundles.yaml file which has this inherit feature?
[17:25] <bac> sure
[17:26] <bac> hatch: https://code.launchpad.net/~bac/charms/bundles/complicated/bundle
[17:26] <hatch> bac oh cool thanks I'll pass this on
[17:27] <jcastro> man, that is brutal
[17:27] <hatch> lol
[17:27] <bac> rick_h_: not to be pushy, but are you going to be able to get to my review soonish?
[17:27] <bac> jcastro: it is a cleaned up version from kapil
[17:27] <rick_h_> bac: looking at it now
[17:27] <bac> the "if you can ingest this, then ingest works" bundle
[17:27] <jcastro> I did not know about overrides
[17:27] <rick_h_> bac: yep, in progress
[17:27] <bac> ty
[17:35] <rick_h_> bac: feedback in, qa'ing now
[17:35] <bac> thanks
[17:38] <rick_h_> bac: qa-ok
[17:38] <bac> rick_h_: cool.  looking at your review now.  qa started
[17:39] <bac> jujugui: in case i forget tomorrow, i will not be able to make the noon meeting.  apologies.
[17:39] <rick_h_> bac: ack, thanks for the heads up
[17:39] <hatch> we have a noon meeting? ;)
[17:39] <bac> sure we do
[17:39]  * rick_h_ didn't realize noon meeting and looks at the calendar
[17:39] <bac> for exactly one of us
[17:39] <rick_h_> lol
[17:39] <rick_h_> you're ahead of eastern?
[17:39] <bac> would you people please get on AST
[17:40] <rick_h_> for some reason I thought you were in eastern
[17:40] <rick_h_> hah
[17:40] <bac> rick_h_: no daylight savings
[17:40] <rick_h_> bac: ah
[17:40] <bac> so US/East half teh time
[17:40] <rick_h_> that's right, we talked about that
[17:40] <rick_h_> you're just trying to be complicated
[17:40] <bac> gah, i wish we'd all ditch DST
[17:40] <rick_h_> +1
[17:41] <bac> and the goofballs here are now talking about starting up with DST!  geez, one of the best things they do they want to mess up
[17:48] <hatch> oh bisect...you rule
[17:48] <rick_h_> hatch: hah! awesome!
[17:48] <hatch> unfortunately it was me that caused the bug
[17:48] <rick_h_> yea, there are days when I go "All this moving to git stuff is paying off."
[17:48] <hatch> so I'm conflicted
[17:48] <rick_h_> double hah!
[17:48] <hatch> lol
[17:49] <rick_h_> try to tell me you need to break my feature will you
[17:49] <rick_h_> I'll shove that crap right back at you :P
[17:49] <rick_h_> j/k and all that, but glad to see we hopefully don't need to break things
[17:49] <hatch> oh sweet, I didn't CAUSE the problem, I exposed it
[17:49] <hatch> lol
[17:49] <rick_h_> hah, off the hook
[17:49] <rick_h_> kinhda
[17:49] <rick_h_> kinda
[17:49] <hatch> lol yeah kinds
[17:50] <rick_h_> "I didn't break it, I just proved it was broken"
[17:50] <hatch> haha, in math that would be the time to write a paper
[17:50] <rick_h_> in code it's time to write a pull request, same diff
[17:50] <rick_h_> :)
[17:53] <hatch> haha
[17:55] <bac> rick_h_: our dependencies branch will still be on launchpad, right?
[17:56] <hatch> rick_h_ ok another fix....enable the simulator so the next delta comes in :P
[17:56] <hatch> no? no? lol
[17:57] <bac> rick_h_: i think deploy.py setup_repository might need some fixing
[17:58] <rick_h_> bac: yea bzr is still installed
[17:58] <rick_h_> bac: looking, never seen/used that
[17:59] <rick_h_> bac: I updated the functional tests and they pass 20-functional
[17:59] <rick_h_> looking into deploy.py
[17:59] <rick_h_> but all tests pass currently
[17:59] <rick_h_> including the ec2 live functional ones
[18:02] <rick_h_> bac: ok, I've updated the rsync in there to ignore .git as well which is the only thing I can see to fix there.
[18:02] <bac> rick_h_: my 'make deploy' has been stuck at DEBUG:root:waiting for the unit to be ready
[18:02] <bac> for a long time.  i haven't run this lately.  any idea how long it should take?
[18:02] <rick_h_> pushing a new -cr
[18:02] <rick_h_> bac: 10min?
[18:02] <rick_h_> bac: can you juju status and see if something broken?
[18:02] <bac> eek
[18:03] <bac> gui is pending but all else looks fine
[18:03] <rick_h_> bac: ok cool. You can log in and check the unit log if you think there's an issue but it should get to an error if it fails
[18:04] <rick_h_> so sounds like it just needs more time
[18:04] <bac> it's been 30 minutes....
[18:05] <rick_h_> oh, then check out the unit log please
[18:05] <hatch> ugh test tracebacks that are only on chai.js
[18:05] <rick_h_> juju ssh juju-gui/0
[18:05] <rick_h_> and then tail -f -n 100 /var/log/juju/unit<tab complete>
[18:05] <rick_h_> bac: ^
[18:05] <bac> ok
[18:06] <rick_h_> hatch: web components! and the font thing seems cool http://blog.chromium.org/2014/01/chrome-33-beta-custom-elements-web.html
[18:10] <hatch> will look in a bit
[18:11] <bac> rick_h_: can't do that yet.  no public address assigned at this point
[18:11] <rick_h_> bac: you can't ssh to the machine? are you using ec2 or something else?
[18:11] <bac> local
[18:11] <bac> you can't ssh until it gets an address
[18:12] <rick_h_> bac: oh it doesn't work on local I didn't think because it requires sudo
[18:12] <rick_h_> or can you? /me didn't try I guess
[18:12] <bac> rick_h_: /home/bac/charms/precise/juju-gui> sudo juju ssh juju-gui/0
[18:12] <bac> ERROR unit "juju-gui/0" has no public address
[18:12] <rick_h_> right, I think quickstart works on local but make deploy doesn't
[18:13] <bac> rick_h_: i'll restart with ec2
[18:13] <rick_h_> bac: thanks, sorry for not specifying. It should work on any of the public clouds hp, ec2, azure
[18:13] <bac> rick_h_: i'm just frugal.  and i thought it'd be faster
[18:13] <frankban> rick_h_: are you sure? IIRC make deploy shoudl work correctly on LXC
[18:14] <frankban> rick_h_: make test/ftest does not
[18:14] <rick_h_> frankban: I thought I hit an issue and you said it wouldn't work because it required sudo?
[18:14] <rick_h_> oh, maybe that was the functional tests I'm thinking of
[18:14] <rick_h_> bah, ok. /me goes to try local lxc then with make deploy
[18:14] <frankban> rick_h_: yes, "make deploy" sould not require to bootstrap the environment, and that's the only operation requiring sudo
[18:16] <rick_h_> frankban: k, testing local out now
[18:16] <frankban> bac, rick_h_ : when using lxc, you can find info in ~/.juju/local/log (or similar) ssh is often not required
[18:17] <rick_h_> frankban: ah, I've got trusty issues with local lxc and this
[18:17] <rick_h_>     agent-state-info: '(error: symlink /var/lib/lxc/rharding-local-machine-1/config
[18:17] <rick_h_>       /etc/lxc/auto/rharding-local-machine-1.conf: no such file or directory)'
[18:17] <frankban> rick_h_: trying make deploy on trunk
[18:18] <rick_h_> agent-state-info: '(error: container "rharding-local-machine-1" is already created)'
[18:18] <rick_h_> bah, see, issues. /me goes to tear that down manually
[18:20] <rick_h_> frankban: same thing     agent-state-info: '(error: symlink /var/lib/lxc/rharding-local-machine-1/config /etc/lxc/auto/rharding-local-machine-1.conf: no such file or directory)'
[18:20] <rick_h_> on trunk
[18:22] <frankban> rick_h_: you can try lxc-destroying your containers, and then manually removing juju related stuff in /var/lib/lxc/
[18:22] <frankban> rick_h_: and in /etc/lxc/auto/
[18:22] <rick_h_> frankban: yea, its clean. It's that to write to /var/lib/lxc it needs root perms
[18:23] <frankban> rick_h_: I think that's ok
[18:23] <rick_h_> I need to try to set the alt path. It's not writing to .juju/local :/
[18:23] <rick_h_> because that machine it starts is ending up in /var/lib/lxc I think
[18:25] <frankban> rick_h_, bac: make deploy just worked here with trunk + lxc, and now I need to go, have a nice evening
[18:25] <rick_h_> frankban: cool, good to know it's just me/trusty
[18:25] <bac> thanks frankban
[18:25] <bac> rick_h_:  and me
[18:25] <rick_h_> frankban: will try on my laptop I think to see if my branch is causing bac grief
[18:26] <rick_h_> bac: worked on trunk?
[18:26] <frankban> cool
[18:26] <rick_h_> bac: not sure what the 'and me' is to?
[18:26] <bac> rick_h_: it isn't working for me
[18:26] <rick_h_> right, ok
[18:26] <rick_h_> bac: so make deploy on ec2 is or is not working either?
[18:27] <bac> rick_h_: yes, it has come up on ec2
[18:27] <rick_h_> ok cool, I'll test lxc on my laptop with trunk and my branch and see if I can dupe any local issues or not
[18:28] <hatch> rick_h_ https://github.com/hatched/juju-gui/commit/527027fbbda1fb712e62e8b8e795cbee84587700 this fixes the issue, I can't find any issues in qa but looking for input on any potential problems I may have overlooked
[18:29] <rick_h_> hatch: looking at that how are we sure that doesn't introduce another level of dispatch on 'working' cases?
[18:29] <rick_h_> hatch: I'd expect it to set/check something before and after navigate to see if it fired or not?
[18:30] <rick_h_> and if not, then check hash and force a dispatch
[18:31] <hatch> that path is only hit when the user logs in and if there is a hash in the url so it shouldn't get hit during any other case
[18:33] <rick_h_> onLogin is only triggered once per visit to the site pinky swear?
[18:34] <hatch> it's triggered when the env fires a login event
[18:34] <hatch> this.env.after('login', this.onLogin, this);
[18:34] <hatch> so it should only happen once :)
[18:34] <rick_h_> ummm, ok then. if you say so
[18:34]  * rick_h_ doesn't trust anything happening only when it's supposed to
[18:35] <hatch> haha, I'm going to try it on lxc right away
[18:35] <hatch> did you push your charm update up?
[18:35] <hatch> the pull-from-git one
[18:36] <rick_h_> yea, it's pushed. lp:~rharding/charms/precise/juju-gui/git-ify
[18:36] <rick_h_> bah, my laptop has juju .07
[18:36] <hatch> wow that's an old one
[18:37] <rick_h_> yep
[18:37] <rick_h_> go raring go
[18:43] <hatch> :/ my juju env is corrupted or something
[18:44] <rick_h_> hah! at least I'm not the only one having issues with it
[18:44] <hatch> RROR destroying environment: remove /etc/lxc/auto/hatch-local-machine-1.conf: no such file or directory
[18:44] <hatch> but it thinks it's running
[18:44] <hatch> any ideas on how to get around that?
[18:44] <rick_h_> nope, kill everything. Destroy the environment. Re-bootstrap?
[18:45] <hatch> it is killed
[18:45] <rick_h_> make sure all the old machines are gone and removed from lxc
[18:45] <hatch> it just thinks it's up
[18:45] <rick_h_> sudo lxc-ls
[18:45] <hatch> nothing
[18:45] <hatch> no machines
[18:45] <hatch> juju status shows them though
[18:46] <rick_h_> wipe the .juju/environments/xxxx?
[18:46] <rick_h_> I'm not sure there
[18:47] <hatch> I'll ask in #juju
[18:51] <bac> rick_h_: where do i find the hash for 'network-prototype', your second QA step?
[18:52] <rick_h_> bac: that is the name of a branch
[18:52] <bac> okey doke
[18:52] <bac> how do i verify version.js is correct?
[18:52] <rick_h_> bac: oh right, so to check the version in github go to that branch in the drop dow
[18:52] <rick_h_> https://github.com/juju/juju-gui/tree/network-prototype
[18:52] <rick_h_> and click on commits
[18:52] <rick_h_> to see the list and their hashes
[18:52] <bac> rick_h_: thanks, i didn't see the drop down
[18:53] <rick_h_> notice in the upper left next to the "juju-gui/+" is a drop down for branches available
[18:53] <rick_h_> cool
[18:54] <rick_h_> bac: so I got make deploy to work with local lxc. It took a bit and I tracked it was running by cat .juju/local/logs/unit.....
[18:54] <bac> rick_h_: cool
[18:57] <hatch> just plz dont merge network-prototype into develop....it will break the world
[18:57] <hatch> ;)
[18:57] <rick_h_> hatch: we're not, it's just the qa case of can you set that branch in the charm
[18:58] <hatch> cool
[18:58] <hatch> some guy kept squatting on my username until one of the others in London told me about nickserv's `enforce` option
[18:58] <hatch> now I don't have to ghost anymore
[18:58] <rick_h_> woot
[18:59] <rick_h_> I got all excited we had random github forkers
[18:59] <rick_h_> and then saw they worked for cisco in their user bios
[18:59] <rick_h_> doh!
[18:59] <hatch> haha, well they aren't RANDOM but they hopefully will be contributing
[18:59] <bac> crud, no vanguard in #webops
[19:00] <hatch> ugh why can't I `juju deploy  lp:~rharding/charms/precise/juju-gui/git-ify` LIKE FOR SERIOUS!!!!
[19:00] <rick_h_> because it's not in the story, non-trunk branches aren't deployed
[19:00] <rick_h_> or ingested that is
[19:00] <hatch> I don't care what the excuse is...it should work :P
[19:00] <hatch> I'm providing the path where everything it needs is contained
[19:01] <bac> rick_h_: sorry for the slow review/qa.  done now
[19:01] <rick_h_> bac: not a problem, I know it's been a slow process getting things working. Yay charm dev
[19:02] <hatch> oh well gues I'll just have to pull your branch down and do it local
[19:02] <rick_h_> hatch: yep
[19:02] <rick_h_> hatch: make sure to make sysdeps
[19:02] <hatch> well I'm just gona deploy it as a local charm
[19:02] <rick_h_> hmm, ok
[19:03] <bac> jujugui: anyone have a USB 3 hub that they like?  i've been through two and can't get one that reliably works
[19:03] <hatch> you don't like that approach?
[19:03] <rick_h_> hatch: no, just not tried it
[19:04] <rick_h_> I think make deploy is supposed to be faster because it skips some step, but can't recall which
[19:04] <hatch> the upload to juju
[19:04] <hatch> I htink
[19:04] <rick_h_> bac: I've got http://www.amazon.com/gp/product/B009Z9M3DY/ref=wms_ohs_product?ie=UTF8&psc=1 and it's been working for me
[19:05] <rick_h_> but there was a post about some issues with anker usb3 stuff so not sure if I can recommend
[19:05] <bac> rick_h_: i have the cousin http://www.amazon.com/gp/product/B009Z9M3DY/ref=wms_ohs_product?ie=UTF8&psc=1
[19:05] <bac> western digital externally powered hard drive frequently won't mount
[19:06] <bac> anker did contact me and send a replacement after i put a bad review on AMZN.  second one is only marginally better
[19:06] <rick_h_> yea, I'm trying to find the blog post
[19:06] <rick_h_> there's something about certain chipset versions or something
[19:06] <rick_h_> but I only have keyboard, power cable, and such on it. no drives
[19:06] <bac> did a firmware update on the WD and that seemed to help but not consistently
[19:07] <bac> an, so you're not really pushing USB 3
[19:07] <bac> s/an/ah
[19:07] <bac> s/an/ah/
[19:07] <rick_h_> yea, once in a while plug in my usb3 thumbdrive
[19:07] <rick_h_> but that's rare
[19:07] <bac> .
[19:08] <bac> ohh, i didn't think to try my thumbdrive
[19:08] <hatch> I want this....but jeesh $$ http://www.belkin.com/us/p/P-F4U055/
[19:08] <bac> yeah
[19:08] <rick_h_> thanks for the review bac
[19:09]  * bac waits for 4K apple cinema display with thunderbolt
[19:09] <hatch> hah
[19:09] <bac> because that'll be cheap
[19:09] <hatch> it'll be like $5000 lol
[19:09] <hatch> holy smokes this bzr branch is taking FOREVER!!
[19:11] <hatch> I want the belkin thing so that I only have to plug/unplug a single cable when 'docking' this thing
[19:11] <hatch> but at $300 it's gona have to wait :)
[19:11] <bac> yeah, that'd be nice.
[19:11] <bac> hatch: if i had an external monitor i'd do it
[19:11] <rick_h_> why I like thinkpad and docks
[19:12] <rick_h_> drop in dock, go
[19:12] <hatch> I have two but they are both display port which I don't think allows for chaining
[19:12] <hatch> so the $300 part is probably only one piece in the puzzle
[19:13] <bac> so the rule is now, no deploys after noon us/east on thursday...effectively
[19:13] <hatch> sounds like a plan
[19:13] <rick_h_> :/
[19:13] <bac> tuesday is a good day to deploy.  i'll shoot for tuesday.
[19:13] <hatch> 163831kB and it's still going
[19:13] <hatch> how big is your branch rick_h_  lol
[19:13] <rick_h_> hatch: get better internets :P
[19:14] <hatch> can't I branch a single revno somehow?
[19:14] <bac> hatch: i think you may have your repo malconfigured
[19:14] <bac> using shared repos?
[19:14] <hatch> I'm just pulling down a single branch, I don't realy want to set up shared repos on this box
[19:15] <bac> hatch: then you don't really mind waiting
[19:15] <bac> i mean, it can grab the common info from a local shared repo
[19:15] <bac> or you can download it again each and every time
[19:15] <hatch> kind of a shortcoming of bzr hey that I can't pull down a single revno
[19:15] <rick_h_> sure you can
[19:16] <hatch> really? it sure seems to be pulling down the entire repo still
[19:17] <rick_h_> yea, there's flags to do a shallow clone
[19:17] <jcastro> https://code.launchpad.net/~james-page/charms/bundles/openstack-on-openstack/bundle
[19:17] <jcastro> any idea why this isn't showing up on jujucharms.com?
[19:17] <rick_h_> jcastro: the fixes for supporting inheritance and self-referring relations are in progress
[19:18] <rick_h_> we can't deploy the one fix right now and the other will be fixed monday
[19:18] <jcastro> oh ok, so it'll just show up at one point
[19:18] <bac> jcastro: we've made a request to deploy
[19:18] <jcastro> gotcha
[19:18] <rick_h_> jcastro: rgr
[19:18] <rick_h_> jcastro: that found two bugs in our proofing stuff
[19:18] <rick_h_> jcastro: fixes in progress
[19:19] <rick_h_> hatch: bzr co --lightweight lp:~juju-gui-charmers/juju-gui/charm-download-cache $DOWNLOADCACHE
[19:19] <rick_h_> is an example
[19:20] <jcastro> rick_h_, ok so I'll just say it'll show up over the next few days or so
[19:20] <rick_h_> jcastro: rgr
[19:20] <jcastro> manually doing the bundle by hand seems to have worked
[19:20] <jcastro> in the mock environment anyway. :p
[19:21] <rick_h_> yea, kapil had some as well that worked but we had issues with them ingesting due to proof thinking they were invalid
[19:45] <bac> jujugui, jcastro: manage.jujucharms.com did get updated
[19:45] <bac> so inherited charms should work now or when they get ingested
[19:45] <bac> self-referential ones will have to wait until next week, jcastro
[19:47] <rick_h_> jcastro: bac so I downloaded and ran proof on it
[19:47] <rick_h_> E: openstack: The requested relation nova-ceilometer to nova-ceilometer is incompatible between services.
[19:47] <rick_h_> is the error
[19:47] <rick_h_> that's the one benji is working on and will be updated next week
[19:48] <bac> yes, the so-called 'self-referential'
[19:50] <bac> jujugui: i'm going to duck out.  dog to walk.  festivities to shoot (camera) while avoiding being shot (glock).
[19:50] <rick_h_> bac: good luck with the shooting
[19:50] <rick_h_> on both ends of it
[19:51] <bac> through in some civil rights violations, unconstitutional search and seizures, pig on a stick and it's a party.
[19:51] <jcastro> rick_h_, ok so here's a weird one.
[19:51] <rick_h_> ruh roh
[19:51]  * rick_h_ ducks
[19:51] <jcastro> rick_h_, do a search for "elastic search juju"
[19:51] <jcastro> manage.jujucharms.com/~charming-devs/precise/elasticsearch
[19:52] <jcastro> whatever ~charming-devs is, it's URL comes up before the canonical one
[19:54] <rick_h_> hmmm, well...not sure on that one
[19:54] <rick_h_> I mean I can make crap up
[19:55] <jcastro> yeah I had never even heard of ~charming-devs
[19:55] <rick_h_> "google knows that juju and the word 'charm' goes together and in this case the url has more charm in it due to the ~charming-devs in it
[19:55] <rick_h_> jcastro: it's our ES charm that we package it up for charmworld/IS. Notice sinzui is the only one with commits on it
[19:55] <rick_h_> it's purely to get into IS for charmworld
[19:56] <rick_h_> jcastro: hmm, http://manage.jujucharms.com/precise/elasticsearch/hooks/install
[19:56] <rick_h_> might be causing the page to lose points on google-fu
[19:57] <rick_h_> jcastro: maybe file a charmworld bug on the 404's
[19:57] <rick_h_> the other charm doesn't have the 404s and seems better quality
[20:45] <hatch> rick_h_ hey you around?
[20:45] <rick_h_> hatch: yea
[20:46] <hatch> so I haven't been able to deploy my branch using your charm
[20:46] <rick_h_> k, got a sec to hangout and I can walk you through getting debug info?
[20:46] <hatch> in a bit, dogs are playing lol
[20:46] <rick_h_> rgr
[20:47] <hatch> oh I think I screwed it up
[20:51] <hatch> rick_h_ is there a way I can trigger a config changed hook to run?
[20:51] <rick_h_> hatch: change hte config?
[20:51] <rick_h_> hatch: set it back to 'develop'
[20:51] <rick_h_> hatch: so you have to resolve it if it's in error first
[20:51] <rick_h_> then set it to develop
[20:52] <rick_h_> then set it to "https://.....you...repo your_branch"
[20:52] <rick_h_> watch the unit log in /var/log/juju/unit..... for what's going on
[20:52] <hatch> 2014-01-16 20:50:30 INFO juju.worker.uniter context.go:323 HOOK ValueError: u'git@github.com:hatched/juju-gui.git render-app-hash': release not found
[20:53] <hatch> no matter what I try that's the error I get
[20:53] <hatch> 'release not found'
[20:53] <rick_h_> don't use the git addres
[20:53] <rick_h_> only https
[20:53] <rick_h_> git needs ssh keys
[20:53] <rick_h_> never use those for tools/etc outside of your own work
[20:54] <rick_h_> https:// note that in all the examples/etc
[20:55] <hatch> oh there are examples?
[20:55] <hatch> lol
[20:56] <rick_h_> yea in the docs
[20:57] <rick_h_> well actually in the config.yaml there's notes on possibly values
[20:59] <hatch> blarg no luck
[20:59] <rick_h_> log?
[21:00] <hatch> looking
[21:00] <hatch> apparently it barfed on 'develop' as well
[21:01] <rick_h_> on 'just' develop?
[21:01] <rick_h_> the string?
[21:01] <hatch> yup
[21:01] <rick_h_> then I need to see the logs/etc because it's passed qa and whiel I've got a stupid functional test issue keeping me from landing it works
[21:01] <hatch> it appears to be working on the https though....
[21:02] <hatch> 2014-01-16 21:00:41 INFO juju.worker.uniter context.go:323 HOOK ValueError: u'https://github.com/hatched/juju-gui.git render-app-hash': release not found
[21:02] <hatch> 2014-01-16 20:58:30 INFO juju.worker.uniter context.go:323 HOOK ValueError: u'develop': release not found
[21:03] <rick_h_> wtf it shouldn't be trying to find a release.
[21:03] <rick_h_> what's your juju set command?
[21:04] <hatch> is there a way I can check where the charm is from?
[21:04] <rick_h_> not following
[21:04] <hatch> charm: cs:precise/juju-gui-81 is what it says
[21:05] <hatch> is that the version of your charm?
[21:05] <hatch> 81
[21:05] <rick_h_> nope, not sure where 81 comes from
[21:05] <rick_h_> version is 102
[21:05] <rick_h_> bzr rev is 150s
[21:05] <hatch> hmm wth
[21:06] <hatch> yeah revno is 159
[21:06] <rick_h_> so sounds like the charm source is out of date
[21:08] <hatch> well that's the revno from the folder `juju deploy --repository=/home/hatch/precise juju-gui`
[21:08] <rick_h_> I'm not sure
[21:08] <rick_h_> juju ssh juju-gui/0
[21:08] <rick_h_> then sudo update db
[21:08] <hatch> in the charm what should I look for?
[21:08] <rick_h_> and locate utils.py
[21:09] <rick_h_> in that should see some git stuff
[21:09] <hatch> oo lots of those
[21:10] <rick_h_> git references or utils.py?
[21:10] <rick_h_> locate utils.py | grep juju-gui
[21:10] <hatch> none
[21:11] <rick_h_> locate utils.py | grep juju
[21:11] <hatch> none
[21:11] <rick_h_> wtf
[21:11] <rick_h_> locate HACKING.md
[21:11] <hatch> none
[21:11] <hatch> maybe the db is broken
[21:11] <hatch> any idea the real location for it?
[21:11] <rick_h_> oh oh
[21:11] <rick_h_> sudo locate HACKING.md
[21:11] <rick_h_> forgot the charm is owned by the non-ubuntu user
[21:11] <hatch> there we go
[21:12] <hatch> ohh...thats odd
[21:12] <hatch> isnt it?
[21:12] <rick_h_> so go there and look for the utils.py
[21:12] <rick_h_> and look for git in that file
[21:13] <hatch> ok there is no git in this file
[21:13] <hatch> wtf
[21:14] <rick_h_> then you've got somem other source
[21:14] <rick_h_> some
[21:14] <rick_h_> and that explains everything
[21:14] <hatch> which is impossible because of how it was deployed
[21:14] <hatch> maybe I came across a bug?
[21:15] <hatch> ohhh right
[21:16] <hatch> ok so this CLI needs some help lol because it totally should have thrown an error instead of just working silently
[21:16] <rick_h_> 'this cli'
[21:16] <rick_h_> ?
[21:16] <hatch> uju
[21:16] <hatch> juju
[21:16] <rick_h_> the unit should be in an error state?
[21:16] <hatch> no it never should have deployed
[21:16] <rick_h_> because the hook should have failed
[21:16] <rick_h_> why not? it picked up something that worked. I'm not sure what you did or how you did it
[21:16] <hatch> it deployed from charmstore even though I specified a repository
[21:17] <rick_h_> did you maybe get trunk vs my branch?
[21:17] <hatch> yup
[21:17] <rick_h_> is your local repository trunk vs my branch?
[21:17] <hatch> my local repo is your branch, with git in the utils etc etc
[21:17] <rick_h_> ok
[21:17] <hatch> but because I didn't type local:precise/juju-gui it disregarded the repository flag
[21:17] <rick_h_> then like I said, I'd sure just run 'make deploy' if I were you :)
[21:18] <rick_h_> if you wanted to save time, edit the config.yaml and make your url + branch the default value
[21:18] <hatch> I don't think I know the process to pull down a charm into an instance
[21:18] <rick_h_> kill it
[21:19] <hatch> oh well I can start over haha
[21:19] <hatch> I thought you meant to pull down the charm into the instance
[21:19] <rick_h_> nope
[21:19] <rick_h_> I mean change the config.yaml in your checkout, run make deploy, enjoy
[21:20] <hatch> that could be on a tshirt
[21:20] <hatch> make, deploy, enjoy
[21:21] <hatch> I wish there was a way to list the config options and their values without the descriptions
[21:23] <hatch> *sigh* now juju is throwing errors again
[21:23] <rick_h_> wheee
[21:23] <hatch> this version is sure buggy
[21:26] <hatch> I of course am probably doing things which are not 'normal' lol
[21:27] <hatch> there we go
[21:27] <hatch> charm version 102 being deployed
[21:28] <rick_h_> hatch: https://plus.google.com/104537541227697934010/posts/Qj8R5SWAsfE
[21:29] <hatch> it's picking up steam
[21:29] <hatch> I still think the template should be loaded in from another file
[21:31] <hatch> I THINK I saw a video where one of the devs was going to say that they are putting together some functionality like that
[21:31] <hatch> but maybe I'm just making that up
[21:36] <rick_h_> hatch: ok, just pushed the charm changes to ~juju-gui trunk version
[21:36] <rick_h_> hatch: so soon it'll be in the store hopefully
[21:37] <rick_h_> just not the reviewed/released one, but the ~juju-gui one
[21:37] <hatch> ahh well it's ok now - I think I also figured out my issue with the corrupt juju instance
[21:37] <rick_h_> okie dokie
[21:37] <rick_h_> I'm giong to head out. If you need a hand let me know and I'll try to check in later.
[21:37] <hatch> if you go `juju destroy-environment local` then `sudo juju destroy-environment local` then it throws the error
[21:38] <hatch> cool, have a goood one
[21:38] <rick_h_> you too
[22:02] <huwshimi> Morning
[22:13] <hatch> morning huwshimi, sorry I haven't had a bunch of time to look at your branch again
[22:13] <hatch> but the reason your event isn't being fired is because your callback is in the wrong context
[22:15] <hatch> I just added the comment
[22:15] <huwshimi> hatch: Ah great. No problems at all
[22:19] <huwshimi> hatch: But will that event get fired if there is no CSS animation in the test?
[22:19] <hatch> umm looking
[22:22] <hatch> so the issue is that we aren't loading the css hey
[22:22] <hatch> hmm
[22:23] <huwshimi> Yeah
[22:24] <huwshimi> hatch: Even adding  style="transition: left 0.1;" to the element doesn't fix it.
[22:25] <huwshimi> hatch: Unless it needs to be vendor prefixed
[22:25] <hatch> does the event fire when it's not in a test?
[22:27] <huwshimi> hatch: Yeah, it has been working fine (even without the 'this' from your comment)
[22:28] <hatch> ok right, the 'this' comment was only to fire that event
[22:29] <hatch> ok so what's happening is that the event is not being fired in phantomjs
[22:29] <hatch> so what you want to do is know when the new tab is visible right?
[22:31] <huwshimi> Yep
[22:31] <hatch> huwshimi looks like phantom does not support transitionend
[22:32] <huwshimi> When it has animated into place
[22:32] <huwshimi> ah right
[22:33] <hatch> SO....
[22:33] <huwshimi> hatch: And I believe you can't simulate arbitrary events with YUI right?
[22:33] <hatch> you could try firing an event on the node
[22:33] <hatch> myNode.fire('transitionend')
[22:34] <hatch> but I have no idea if that's going to work
[22:37] <huwshimi> nope
[22:38] <huwshimi> I also have problems with the selectionChange event not firing, but that's probably my fault somehow
[22:41] <hatch> hmm that looks ok but I haven't pulled down the code to really take a look
[22:41] <hatch> been stuck trying to fix a bug all day
[22:42] <huwshimi> hatch: What are you working on?
[22:42] <hatch> well I just finished qa'ing and now I'm writing the last of the tests but it's the bug where it wouldn't dispatch if there is a hash in the url on prod
[22:43] <huwshimi> oh, fun
[22:44] <hatch> yeah it was a simple small fix but tracking it down and testing it was very time consuming
[22:54] <hatch> I dropped my phone on my laptop and scratched it
[22:54] <hatch> these things are sure fragile lol
[22:58] <huwshimi> heh
[23:13] <hatch> jujugui looking for a review/qa https://github.com/juju/juju-gui/pull/75 (requires qa in real env)
[23:20] <rick_h_> hatch: I'll look first thing in the morning
[23:20] <hatch> coolio, qa'ing takes a while unfortunately
[23:21] <rick_h_> yea, I'm between things so should have time


[04:24] <returnthis> I am trying to get snapd to work on my local system and I am having an ungoogable problem. Is this where I can get help with that tool?
[04:26] <returnthis> I installed snapd, then read I should have apparmor enabled first. so I uninstalled snapd, enabled apparmor and resinstalled snapd
[04:27] <returnthis> The issue is that now I get errors for snap list
[04:27] <returnthis> error: cannot list local snaps! cannot find publisher details: snap-declaration
[04:27] <returnthis>        (buPKUD3TKqCOgLEjjHx5kSiCpIs5cMuQ; series:16) not found
[04:27] <returnthis>
[04:31] <returnthis> looks like there was some left over data when I removed it
[04:31] <returnthis> snapd[1960]: snapmgr.go:247: cannot read snap info of snap "hello-world" at revision 27: cannot find installed snap "hello-world" at revision 27: missing file /var/lib/snapd/snap/hello-world/27/meta/snap.yaml
[11:52] <DonAlex> Can someone tell me what is happening here? The build seems ok but it barfs finding the binaries ? https://paste.ubuntu.com/p/YVrksKG9Cs/
[12:21] <DonAlex> Ahh ok. figured it. the preceding / needs to be left out if you are specifying /usr/local/bin.
[13:16] <cjwatson> DonAlex: Um possibly at least as relevant is that you misspelled "/usr/local/bin" as "/usr/loca/bin"
[13:16] <DonAlex> Yeah I fixed that..
[13:17] <DonAlex> but it was the leading /  that caused the issue..
[13:17] <DonAlex> has to be usr/local/bin though that is not explained anywhere
[13:17] <cjwatson> Yeah, I suppose that's what "Ensure that ... is relative to the prime directory" means
[13:18] <DonAlex> Quite..
[13:19] <DonAlex> Anyway.. am I right to include the missing libs in the staging part ?
[13:20] <cjwatson> That I can't advise on, sorry
[13:20] <DonAlex> It builds now but I am a little perturbed but that warning The 'rolisteam' part needs the following libraries that are not included in the snap or base:
[13:21] <DonAlex> Well I have added them and seeing if it gives me less warning
[13:21] <cjwatson> That does sound like you need to bundle the libraries, yes
[13:22] <DonAlex> Have you done any multiarch building btw ?
[19:42] <DonAlex> ok this makes no sense. I am getting this error. But I included libpulse0 in the stage packages ?
[19:42] <DonAlex> ideas?
[19:43] <DonAlex> \/snap/rolisteam/x2/usr/local/bin/rolisteam: error while loading shared libraries: libpulsecommon-11.1.so: cannot open shared object file: No such file or directory