[00:14] <huwshimi> hatch: Here we go: https://github.com/juju/juju-gui/pull/193
[00:41] <hatch> huwshimi looking
[00:41] <hatch> lookin good
[00:41] <hatch> I'll do the review in a bit
[00:42] <hatch> huwshimi the ci failed
[00:43] <huwshimi> hatch: Yeah, was just looking at that. It's as if I didn't get the module-debug.js update...
[00:43] <hatch> you need to add the extension file into merge-files
[00:43] <hatch> bin/merge-files
[00:43] <hatch> you'll see a huge list of them
[00:44] <huwshimi> Ah I see
[00:44] <huwshimi> hatch: I've got another change to make before you can do a full review anyway, so hold off on that.
[00:44] <hatch> yes it's sad that I knew these things
[00:44] <hatch> lol
[00:45] <hatch> yeah no problem
[00:46] <huwshimi> haha
[01:13] <hatch> huwshimi ready for review?
[01:14] <huwshimi> hatch: Not quite, just adding tests for events
[01:14] <hatch> ok np, I may not get to a review for tonight then
[01:15] <huwshimi> hatch: It might be done it two mins...
[01:15] <hatch> oh ok
[01:15] <hatch> well ping me and I'll try and get to it :)
[01:20] <huwshimi> hatch: Just rebase and pushing now.
[01:22] <huwshimi> hatch: Ready! https://github.com/juju/juju-gui/pull/193
[01:22] <hatch> ohhh kay
[01:22] <hatch> on it
[01:23] <huwshimi> Thanks!
[01:44] <huwshimi> hatch: Just going to have lunch so I'll fix up after that.
[01:44] <huwshimi> hatch: Thanks heaps for reviewing
[01:45] <hatch> huwshimi no problem - it's a pretty nit picky review :P
[01:45] <hatch> I'm just doing a qa now
[01:50] <huwshimi> hatch: That's fine, happy to have that kind of review
[01:51] <hatch> cool :) I should do more of them lying on the couch hah
[01:51] <hatch> huwshimi ohh, I'm nto sure if you noticed but we upgraded node while youw ere gone
[01:53] <huwshimi> hatch: Ah right, means we can move to sass right?
[01:53] <hatch> I believe that was the holdup you mentioned - so I'm taking your word on it
[01:53] <hatch> :P
[01:54] <huwshimi> hatch: Nice, thanks!
[01:54] <rick_h_> hatch: thanks for hanging on and reviewing appreciate it
[01:54] <rick_h_> hatch: but don't run too long
[01:54] <rick_h_> thanks for the awesome updates huwshimi, I think this will work out much nicer to build on top of
[01:55] <rick_h_> really nice base
[01:56] <huwshimi> rick_h_: Great!
[01:57] <hatch> party on!
[01:57] <huwshimi> rick_h_: I'm going to fix up this branch and then would you be happy for me to get scss working again?
[01:58] <huwshimi> I guess my next branch to work on is "create machine panel view" which requires the header to have landed.
[01:59] <huwshimi> But, not sure if I can tackle that without an imp call
[02:00] <rick_h_> huwshimi: as much as I <3 scss > less the machine view/inspector stuff is priority
[02:00] <rick_h_> huwshimi: I assigned a small bug your way from luca today or last night if you get a chance to look
[02:00] <huwshimi> rick_h_: No problems. I'll take a look at the bug.
[02:00] <rick_h_> huwshimi: and then yea, the machine panel view I think would be next to go, it fits in somewhat with what hatch is working on
[02:03] <rick_h_> huwshimi: noticed you had hte wrong card there for your task
[02:03] <rick_h_> swapped those over
[02:04] <rick_h_> huwshimi: so yea, there's two other machine view component cards after this one.
[02:04] <rick_h_> huwshimi: but please feel free to add a scss conversion to the slack lane and if you get stuck on something sometime it'd be a cool background task
[02:05] <huwshimi> OK sure
[02:05] <rick_h_> night all, sleepy techie...
[02:05] <huwshimi> rick_h_: Night!
[12:27]  * frankban lunches
[12:36] <rick_h_> frankban: thanks for looking into that issue. I'm glad the original assignee has spoken up now
[13:26] <jcastro> rick_h_, rails/example-scalable is missing from the web UI
[13:26] <jcastro> exists in the store afaict
[13:26] <rick_h_> jcastro: k, looking
[13:27] <rick_h_> jcastro: full url?
[13:27] <jcastro> https://code.launchpad.net/~charmers/charms/bundles/rails/bundle
[13:31] <rick_h_> jcastro: added a card to try to get it investigated. I'm out on an intro sprint this week so might be a day/two to get a good look.
[13:31] <rick_h_> jcastro: nothing obvious wrong, proof's, etc
[13:32] <rick_h_> jcastro: but it loads on staging so it's something with production and the awesome black box there
[13:32] <rick_h_> http://staging.jujucharms.com/bundle/~charmers/rails/example-scalable
[13:33] <jcastro> cool
[13:51] <rick_h_> bwuhahaha http://comingsoon.jujucharms.com/:flags:/il/mv/
[13:51] <rick_h_> starting to look like something
[13:51] <rick_h_> that doesn't do anything at all, but it looks :)
[14:02] <hatch> haha
[14:03] <hatch> with these short names we have to be sure we grep for flags.il
[14:06] <frankban> and the fiber connection appears to be working (he said)
[14:09] <hatch> OOoooOoo
[14:16] <frankban> rick_h_: 1.17.6 is in trusty. I am starting quickstart QA on it
[14:21] <jcastro> rick_h_, don't forget to remove ~charmers from bundles too!
[14:23] <frankban> ... and it failed
[14:24] <frankban> guihelp trusty users: have you encountered this issue before? http://pastebin.ubuntu.com/7151411/
[14:33] <hatch> I've run into quite a few odd issues with juju-core in the 1.17.x branches - hoping they all get resolved before 1.18 :)
[14:34] <frankban> hatch: yeah, I am trying to figure out if this should block the quickstart release
[14:35] <hatch> it doesn't look like a quickstart bug
[14:35] <hatch> it looks like a core bug
[14:36] <frankban> hatch: precisely
[14:36] <frankban> asked on #juju-dev
[14:39] <hatch> frankban the first thing they will ask is 'is there anything in the logs' so you might as well check there first :)
[14:40] <frankban> hatch: I am checking if this also affects saucy
[14:40] <hatch> early access "Go In Action" http://manning.com/ketelsen/ looks like there are only two chapters available so far
[14:41] <jcastro> rick_h_, does drag and dropping a bundle with multiple stanzas work yet?
[14:41] <jcastro> basically, the design people need to get updated pictures for the juju flyer
[14:41] <hatch> george co....stanza?
[14:42] <hatch> jcastro do you mean stanza wrt multiple bundles in one deployer file?
[14:42] <jcastro> yeah
[14:42] <hatch> if so, no it's not supported yet
[14:42] <jcastro> ugh
[14:42] <jcastro> so basically, the rails bundle is undeployable
[14:43] <hatch> well I thought that the charmstore splits them up?
[14:43] <jcastro> yeah but the design people are likely using the GUI
[14:44] <hatch> I mean - I was under the impression that the charmstore splits them up so the search results should show multiple bundles in the result list
[14:45] <jcastro> oh hey
[14:45] <jcastro> does it work on comingsoon?
[14:46] <hatch> when I search for rails there is a single recommended bundle
[14:46] <jcastro> right, but the 2nd one is missing
[14:46] <hatch> ahh so it only takes the first one
[14:46] <jcastro> rails:example-simple is there, rails:example-scalable is not
[14:47] <hatch> yeah looks like a charmworld feature isn't there
[14:47] <hatch> the gui just shows what it's given
[14:50] <Makyo> jujugui call in 10
[14:51] <hatch> man that call comes up quick now
[14:58] <Makyo> jujugui callin 2
[15:07] <benji> I was just kicked out of the call.  Trying to reconnect.
[15:13] <Makyo> afk a few minutes
[15:16] <hatch__> benji since you switched to this new camera you have been having a lot of video issues
[15:17] <hatch> new and unimproved? :)
[15:17] <benji> hatch: yep (but today's camera was the old one)
[15:17] <hatch> ohh interesting, it seemed to freeze just like the 'new' one
[15:18] <hatch> maybe a trusty driver issue?
[15:19] <rick_h_> jcastro: yes, it's undeployable atm. We won't have multiple dropping support for a while
[15:19] <rick_h_> jcastro: we should be able to start looking at it later today/tomorrow.
[15:37] <hatch> new HTC One
[15:37] <hatch> ooooo
[15:37]  * hatch looks at mine.....looks at the new one
[15:48] <frankban> jujugui: http://jujugui.wordpress.com/2014/03/25/juju-quickstart-1-2-0-released/
[15:48] <hatch> w00t
[15:48] <frankban> hazmat, marcoceppi: I just updated the juju stable PPA with the backported packages of deployer (0.3.4) and jujuclient (0.17.5)
[15:49] <marcoceppi> \o/
[15:49] <kadams54> Nice
[15:50] <hatch> ahhhh my brain does not work like browser.js
[15:50] <hatch> must....not....rewrite.....routes.....
[15:54] <rick_h_> frankban: woot!
[15:54] <rick_h_> frankban: once it hits pypi can you ping james page and look into getting an updated upload to trusty and talk to him about closing out our FFE bug for it
[15:54] <rick_h_> hatch: :P
[15:55] <rick_h_> hatch: ignore routes, they don't exist
[15:55] <rick_h_> it's magic :)
[15:55] <frankban> rick_h_: it's already on pypi, pinged rbasak about that
[15:55] <rick_h_> as soon as you touch routes you get hit in the head by double dispatch and life sucks
[15:55] <rick_h_> frankban: ok awesome thanks
[15:55] <frankban> mp
[15:55] <hatch> sounds like we should fix double dispatch :)
[15:56] <rick_h_> hatch: it's already fixed for you as long as you stay away from routes
[15:56] <rick_h_> hatch: mission accomplished, plus we need more state than a url/route can handle so you can't get rid of it anyway
[15:57] <rick_h_> jcastro: that quickstart release removes ~charmers
[15:57] <rick_h_> jcastro: and we've updated the deploy instructions in the gui and should be release later this week
[15:57] <hatch> I guess I prefer the router to be explicit '/inspector/:service/:unit' for example
[15:57] <rick_h_> that's fine
[15:57] <rick_h_> but don't think route, it's state
[15:58] <hatch> right but the route can call a single method instead of one who's 100 lines long and has way too many responsibilities
[15:58] <rick_h_> which 100 line method?
[15:58] <rick_h_> *cough* there isn't one *cough*
[15:58] <hatch> sidebar + routeView is over 100 lines
[15:58] <rick_h_> that's two functions :)
[15:58] <hatch> sidebar is only 4 lines shorter than 100 lines
[15:58] <hatch> :)
[15:58] <rick_h_> and I admit that the sidebar function can be broken up into smaller bits
[15:59] <rick_h_> hatch: heh, yea and it's commented to high heaven
[15:59] <rick_h_> shall I go look at other methods in other bits of the code? 100 lines eh?
[15:59] <hatch> I still think that the router should be the source of truth
[15:59] <rick_h_> hatch: and that can't happen
[15:59] <rick_h_> it's not smart enough
[16:00] <hatch> why can't the router call a method which updates the state?
[16:00] <rick_h_> hatch: we can chat about it if you want. I'll tell you where the router falls short for our uses and why state still needs to be there even in a non-double dispatch world
[16:00] <rick_h_> because not every thing we draw is/should/can be in the url
[16:01] <hatch> right but anything touching the router is from the url
[16:01] <rick_h_> what tab is selected in the inspector? How about which tab in the service details popout?
[16:01] <rick_h_> man, the router isn't official in any other code in the GUI. Why is it NOW a problem? I mean what in the inspector, service view, etc deals with it?
[16:01] <hatch> right, and those can be separate methods which update the state and don't need to touch the router
[16:01] <rick_h_> right, so forget the route and just deal with state. Have one source of truth.
[16:02] <rick_h_> if you split up into a bunch of routes with state and async renders for those route callbacks it'll be hell
[16:02] <rick_h_> I've been down that road with the browser
[16:02] <rick_h_> that's even before double dispatch
[16:03] <rick_h_> it's more complex then a todo app :)
[16:03] <hatch> right but right now it's impossible to tell what routes are support or, looking at a url, what is supposed to happen without parsing through many lines of code
[16:03] <rick_h_> ok, I'll give you that's fair.
[16:04] <hatch> I think a lot of what we are doing can be done with 'middleware' routes and then specific ones with defined methods
[16:04] <rick_h_> the discoverabiity/etc isn't as easy with routes, but it wouldn't be anyway.
[16:04] <rick_h_> hatch: right, if we rewrite everything, remove double disptach, and get to some ideal state it might be cool and work out better.
[16:04] <rick_h_> but it's a LONG way from where the world is now
[16:04] <hatch> but I think we can handle double dispatch with middleware
[16:04] <rick_h_> and it's not something we've got the bandwidth to fix between now and vegas
[16:04] <hatch> is what I'm saying
[16:04] <rick_h_> that's what the state does
[16:05] <hatch> exactly
[16:05] <rick_h_> it already deals with double dispatch as a middle layer
[16:05] <rick_h_> so why is it so bad to work with?
[16:05] <hatch> I think that the routes should call specific methods to update the state, then a middleware layer to check if it's the same, if it is, then don't next()
[16:06] <hatch> so then we maintain the state funcitonality
[16:06] <hatch> which we both agree is necessary
[16:06] <hatch> but we have meaningful routes
[16:08] <rick_h_> hatch: maybe, we can talk about it
[16:08] <rick_h_> hatch: I've got to get ready to head out to lunch with ramm
[16:08] <hatch> yeah np I'm implementing it as it is
[16:09] <rick_h_> hatch: I don't mean to be a pita, but it seems that rewriting what's working and is well documented and tested and not a complete mental nightmare seems a bit overkill but maybe I'm too close to it
[16:09] <rick_h_> hatch: we can try to setup some time to look at a proof of concept for reworking it some, but we just spent 2 weeks fixing the inspector to be easier to work with and I don't think we've got the bandwidth to do the same to the browser.js
[16:09] <hatch> yeah that's fine
[16:10] <hatch> it would probably take us at least a week if not two to rewrite this too
[16:10] <hatch> we definitely can't do it before vegas
[16:11] <kadams54> Alrighty, rick_h_ and I are afk for lunch
[16:24] <hatch> I still have two more keybase.io invites if anyone wants
[16:40] <hatch> good nuf? https://www.evernote.com/shard/s219/sh/9a098cc5-6ee6-4770-928c-b44856f06eca/4b02fa5abc7f79a5c0266ceb527c9639
[16:42] <hatch> Makyo do you know if we could have a url for the ghost inspector?
[16:42] <hatch> I'm trying to figure out the best way to update the state and it seems like a url would be the best
[16:42] <Makyo> hatch, Not sure I think that's a very good idea.
[16:43] <Makyo> It's not a bad one, it's just showing transient local state in the URL (which can be shared)
[16:43] <hatch> so here is the issue...the user drags and drops a charm on the canvas, the drop event comes form the canvas
[16:43] <Makyo> So if you have a ghost inspector open and try to share the URL with someone else, it'll fail.
[16:43] <hatch> it now needs to go up to the browser subapp to render the inspector
[16:44] <Makyo> Mmhm.
[16:44] <hatch> well...it would open a inspector to deploy that charm
[16:44] <Makyo> With no drop position info.
[16:44] <hatch> ahh right
[16:44] <Makyo> Or any changes the user has made to config
[16:44] <hatch> the path from the canvas to the browser sidebar is not a clear one :)
[16:44] <Makyo> Yeah, that's fair :/
[16:44] <Makyo> Events? :D
[16:44]  * Makyo ducks
[16:44] <hatch> could fire an event but that's a long way
[16:44] <hatch> lol
[16:45] <hatch> could pass a method down
[16:45] <hatch> but not sure if that's any better than an event
[16:45] <hatch> it's like using a really long stick to poke a switch heh
[16:46] <hatch> updating the url could 'just work' but I see what you're saying
[16:46] <hatch> we could include positional information in the url
[16:47] <hatch> but I guess that would be weird back-button functionality
[16:48] <hatch> we could pop it out of the history heh
[16:48] <hatch> ok I think I know what i'll do
[16:49] <Makyo> Using the URL as an event dispatcher? :P
[16:49] <hatch> lol
[16:50] <hatch> I'll move the inspector creation code from environment.js into browser.js and then fire an event from the canvas > app > browser
[16:50] <hatch> the event targets should allow that pretty trivially right now
[16:50] <hatch> oh...wait
[16:50] <hatch> there are a bunch of events from the canvas to the inspector
[16:50] <hatch> hmmm
[16:52] <hatch> we need a better transport mechanism
[16:59] <hatch> events it is
[17:13] <hatch> we need a indexdb juju environment so we can test this new inspector stuff without being in a real env
[17:14] <hatch> it's impossible right now to see /inspector/:service work in the simulator
[17:14] <hatch> I wonder how hard that would be....
[17:14] <hatch> hmmmmm
[17:14] <hatch> probably not horrible
[17:18] <arosales> rick_h_: re the rails bundle error. If trunk is working correctly and you have that running locally can you help us get a screen shot of the rails bundle with all green?
[17:19] <arosales> rick_h_: the need here is to get a design a good screen shot for the flyers going to GopherCon and OSCON
[17:23] <hatch> arosales he is out for lunch atm
[17:23] <hatch> should be back rather soonish
[17:24] <arosales> hatch: thanks for the info.
[17:48] <hatch> heh - showing the service relation menu has been creating inspectors
[17:48] <hatch> stealth bug....
[17:53] <kadams54> back
[17:53] <hatch> squished
[17:53] <hatch> kadams54 good lunch?
[17:54] <kadams54> Yeah. Yelp did not lead us astray.
[17:54] <hatch> I get left overs
[17:54] <kadams54> Chinese leftovers?
[18:00] <rick_h_> arosales: k, yes. We can get a screenshot. Will take a few
[18:01] <rick_h_> hatch: I don't think that the ghost inspector would be url-able?
[18:01] <hatch> kadams54 home made stir fry...so sort of asiany
[18:01] <rick_h_> hatch: sorry catching up on log
[18:01] <hatch> rick_h_ yeah I've done some uglyness to get the topology into the browser
[18:01] <hatch> I think it's just something we will have to deal with
[18:01] <rick_h_> hatch: k, these are the pain points for sure.
[18:01] <hatch> it's all commented up
[18:02] <rick_h_> hatch: this is where I was expecting the main work in the move to be
[18:02] <rick_h_> hatch: k
[18:02] <hatch> rick_h_ current wip https://github.com/hatched/juju-gui/compare/prep-charmbrowser?expand=1
[18:03] <hatch> in case you were curious
[18:03] <rick_h_> hatch: k, looking while I get a gui up for arosales
[18:03] <arosales> rick_h_: thanks. I also sent a mail with instructions and needs
[18:04] <arosales> jcastro: ^
[18:04] <jcastro> rick_h_, we need one of each bundle, mongodb:cluster and rails:example:scalable
[18:05] <rick_h_> jcastro: ok, but you've got the mongodb cluster right?
[18:05] <jcastro> rails:example-scalable rather
[18:05] <jcastro> not with the new sidebar no
[18:05] <rick_h_> new sidebar?
[18:05] <jcastro> on the left
[18:05] <jcastro> the inspector
[18:05] <rick_h_> well that doesn't exist yet
[18:05] <rick_h_> that's WIP
[18:05] <jcastro> yeah it's for the flyer so we want it to be as close to the future as possible
[18:06] <rick_h_> jcastro: k
[18:07] <arosales> rick_h_: in the email Spencer had some examples of the sidebar bits
[18:07] <rick_h_> arosales: yes, he's designing stuff but we don't have it implemented. It's what we're doing for 14.05 right now
[18:07] <rick_h_> arosales: do you have this email? I'm not seeing it
[18:08] <rick_h_> arosales: sorry found it
[18:08] <arosales> rick_h_: email subj = "Fwd: Images for flyer"
[18:09] <rick_h_> arosales: yes, there's no pic in there though. I don't know what spencer is sending you
[18:10] <arosales> rick_h_: sent w/ attachment
[18:10] <rick_h_> heh yea see it. Those are pure design mock ups. I can't recreate that with a bundle and such and live data
[18:13] <rick_h_> arosales: jcastro http://uploads.mitechie.com/lp/rails-bundle-screenshot.png chop and use it as you see fit.
[18:13] <rick_h_> arosales: jcastro since it loads on staging I just deployed the gui into a lxc environment and changed the config for "charmworld-url"  juju set juju-gui charmworld-url="http://staging.jujucharms.com/"
[18:13] <rick_h_> for reference if you need something like this and I'm afk/etc
[18:14] <hatch> rick_h_ if you zoom out does it show the bottom of the bundle vis?
[18:15] <arosales> rick_h_: ok so jcastro you should be able to do this for mongo with the config settings
[18:15] <hatch> that's one heck of a bundle heh
[18:15] <rick_h_> arosales: we shouldn't need it for mongodb. That one is ingested and working fine
[18:15] <rick_h_> you can do that on comingsoon or jujucharms.com
[18:17] <jcastro> yeah mongodb isn't a problem
[18:17] <jcastro> it's rails that was the problem
[18:18] <arosales> jcastro: but you still need the new sidebar for mongo, which sounds like we can get a comingsoon
[18:18] <rick_h_> arosales: that is not true
[18:19] <arosales> rick_h_: /me just going off what jcastro sayd he has in terms of side bars
[18:29] <marcoceppi> rick_h_: if we delete a branch from launchpad will the charm be removed from charmworld?
[18:29] <rick_h_> marcoceppi: no, but we're getting a removal UI in charmworld to help with this
[18:30] <rick_h_> marcoceppi: it's committed but not deployed yet
[18:30] <rick_h_> marcoceppi: should get a deploy out this week with it
[18:30] <marcoceppi> rick_h_: anything we can do in the mean time?
[18:30] <rick_h_> marcoceppi: what's the details around it?
[18:30]  * hatch stepping out for some lunch errands
[18:30] <hatch> bbiab
[18:42] <jcastro> rick_h_, fixed that cassandra README issue, I'm going to file a bug on charm-tools to check for that
[18:45] <rick_h_> jcastro: k thanks. Sorry to punt on it
[18:46] <jcastro> it's fine, it's a subtle thing that we should be enforcing in policy anyway
[19:06] <hatch> rick_h_ I'm replying to your comments - which one is `il` again? lol (the problem with too short flags)
[19:09] <Makyo> Inspector Left
[19:10] <rick_h_> hatch: ok cool, chat after you go through them?
[19:10] <hatch> ohh
[19:10] <hatch> ok then yes
[19:10] <hatch> :)
[19:10] <rick_h_> hatch: sorry, pm'd you in invisible space :)
[19:10] <hatch> ahh dinging all over the place
[19:11] <hatch> rick_h_ yep, you made some good points here
[19:13] <hatch> rick_h_ https://plus.google.com/hangouts/_/76cpj84oalco0dv6t5k2st3lgk?hl=en
[19:14] <hatch> there is a warning on ABS glue "do not smoke"
[19:14] <hatch> w t h
[19:19] <rick_h_> hatch: joining
[19:48] <hatch> rick_h_ what article is jc talking about?
[19:48] <hatch> on the tweeters
[19:49] <rick_h_> hatch: sec otp
[19:51] <hatch> sure np
[20:07] <kadams54> rick_h_ mentioned a utility for quickly injecting HTML fixtures into the container; I need a reminder what that is?
[20:08] <rick_h_> kadams54: makeContainer
[20:08] <kadams54> thanks
[20:21] <Makyo> jujugui feeling wretched, going to sit on the deck for a few, won't be around for pings.
[20:21] <hatch> okee cya
[20:21] <kadams54> rest up
[20:21] <rick_h_> Makyo: hope you feel better
[20:25] <rick_h_> hatch: benji did you guys have the LoC numbers you were chatting about the other day still?
[20:26] <rick_h_> actually, should have those in the irc log
[20:27] <hatch> not sure what you're referring to
[20:28] <rick_h_> hatch: weren't you and benji looking at how many lines of code was in the gui
[20:28] <rick_h_> hatch: oh, your blog post! that's right
[20:29] <hatch> ohh yeah
[20:29] <hatch> :)
[20:29] <benji> I can find them in my IRC log, but apparently you found them
[20:29] <rick_h_> thanks guy, I just nabbed them from hatch's blog post
[20:29] <rick_h_> guys
[20:29] <rick_h_> bah
[20:29] <rick_h_> EOD bring me home
[20:57] <kadams54_> Ditto
[21:59] <hatch> man the internet is trippin that FB bought Oculus
[22:02] <hatch> morning huwshimi
[22:02] <huwshimi> Morning
[22:08] <huwshimi> rick_h_: Do you know what the card "create machine panel header view/widget" is? It sounds very much like the card I just completed. I know you switched them over because I took the wrong card.
[22:15] <huwshimi> hatch: Any ideas ^
[22:15] <hatch> umm looking
[22:16] <hatch> not a clue
[22:16] <hatch> they look the same-ish
[22:17] <huwshimi> :)
[22:18] <hatch> huwshimi the blocked card in Project 1 is no longer blocked
[22:18] <hatch> you could do that?
[22:19] <huwshimi> hatch: Yeah, that's my plan, I just wanted to know if I should do that other card first as it seems related...
[22:19] <hatch> yeah I can't figure out what it's pointing to that's not what you just did
[22:19] <hatch> I don't see any other 'header' in the mockups
[22:20] <huwshimi> yeah.
[22:21] <huwshimi> hatch: Your official EOD is not for a couple of hours right?
[22:22] <hatch> 38mins
[22:23] <rick_h_> huwshimi: that one is the header control in the machine view panel
[22:23] <rick_h_> huwshimi: that's at the top of all 3 columns in the machine view
[22:23] <rick_h_> huwshimi: let me know if you want to chat on it
[22:23] <hatch> there is no header for the three columns
[22:24] <huwshimi> rick_h_: Yeah, an imp call would be good.
[22:24] <huwshimi> rick_h_: Want me to invite you?
[22:24] <hatch> mind if I join?
[22:24] <rick_h_> huwshimi: k sec
[22:24] <rick_h_> sure
[22:24] <hatch> ohh NOW i see the header
[22:25]  * hatch doesn't think this is a very good ux
[22:25]  * hatch hopes he is reading it wrong
[22:25]  * hatch probably is
[22:25] <rick_h_> huwshimi: link?
[22:26] <huwshimi> Trying...
[22:26] <hatch> he has to invite bcus he is from his tablet
[22:26] <rick_h_> k
[22:26] <huwshimi> rick_h_: https://docs.google.com/a/canonical.com/file/d/0B5yaFXSrLF38aVk4ZXJZY0tJZWJTUy1GVXlScmZRS21rUFJv/edit
[22:43] <hatch> I wonder if the machine view would be a good candidate for another instance of the viewlet-manager. With the header as a view and each column could be it's own view
[22:44] <hatch> then it would be another `new machineView()` to make the whole thing
[22:46] <hatch> that can be pieced together at a later time
[22:57] <huwshimi> hatch: What approach would you take to get other views to render to the new content panel?
[22:58] <hatch> maybe now would be a good time to do the viewlet manager
[22:58] <hatch> hmm
[22:58] <hatch> let me stare at this mockup for a bit
[23:00] <hatch> ok so I have a different idea on how to do this
[23:01] <hatch> each column, including the header is a view (it will likely share a bunch of code via extensions)
[23:01] <hatch> those views would be rendered and instantiated by a viewlet-manager instance much like the inspector instances are
[23:02] <hatch> there would be a 'right hand panel' subclass of viewlet-manager and then the machine view and charm details would subclass that again
[23:02] <hatch> (identical to how the inspector viewlet managers work)
[23:02] <hatch> yep that's how I'd do it
[23:03] <hatch> ^ huwshimi  does that mean anything to you? you weren't here for that stuff :)
[23:03] <huwshimi> hatch: It doesn't mean much :)
[23:04] <hatch> hmm ok ok - well...
[23:05] <hatch> I would like another opinion on this before I send you down this path
[23:05] <rick_h_> hatch: we can take the view that huwshimi has and work with it. The viewlet-manager idea is interesting. I'm not up on what's left in the manager vs not so we should look into it
[23:06] <huwshimi> hatch: Well, I understand what you're saying, I just don't know how to implement it :)
[23:06] <rick_h_> hatch: so I'd suggest huw just work on the skeleton views
[23:06] <rick_h_> and then we'd pull it in/incorporate for full interaction/switching/etc
[23:06] <hatch> right....ok umm
[23:06]  * hatch thinks
[23:06] <rick_h_> hatch: but I don't think the viewlet manager would do well with multiple views available at the same time on the same slot
[23:06] <rick_h_> hatch: as it is now
[23:06] <rick_h_> hatch: so there's some things to think through and I would think they don't need to block huw up
[23:06] <hatch> well each column would be it's own slot
[23:07] <hatch> oh yeah for sure
[23:07] <rick_h_> hatch: right, but how would you layer for animation the views in the slots?
[23:07] <rick_h_> anyway, it's well past EOD and I need to go away before my family shoots me
[23:07] <hatch> huwshimi ok make three views which represent each column
[23:07] <rick_h_> but my thought on the matter since you bring it up :)
[23:07] <hatch> rick_h_ :) thx we can chat soon on it
[23:08] <hatch> huwshimi quick call?
[23:08] <hatch> easier than typing :)
[23:10] <huwshimi> hatch: I'm a little hesitant to put too much work into it until you and rick have bashed it all out...
[23:11] <huwshimi> hatch: I think I'll create a base view for now and get the header widgets working etc.
[23:11] <huwshimi> hatch: And then hopefully by the time I'm done there will be a better picture of how the rest should be structured...
[23:11] <huwshimi> Sound OK?
[23:12] <hatch> so build it in a way that each header is separate and not a row
[23:12] <hatch> else we won't be able to split it up into three columns
[23:12] <huwshimi> hatch: Well, each header will be an instance of a widget
[23:13] <huwshimi> widget/view?
[23:13] <hatch> hmm
[23:13] <hatch> I'd go view in this case
[23:13] <huwshimi> Ok
[23:13] <huwshimi> I have a bug I need to fix before I work on this stuff anyway
[23:14] <hatch> alright, I'm going to step away for a bit but ping if you want to chat
[23:15] <huwshimi> hatch: Thanks :)
[23:17]  * huwshimi heads to the coffee shop for a bit.
[23:48] <rick_h_> hatch: https://algorithms.rdio.com/post/make/ is the article I RT on twitter that someone eles saw


[03:18] <wxl> oh no not a new version of keepassx
[03:18] <wxl> !info keepassx trusty
[03:18] <wxl> arrrrrrrgh
[03:18] <wxl> !info keepassx trusty-updates
[03:19] <wxl> !info keepassx trusty-backports
[03:19] <wxl> !info keepassx trusty-proposed
[03:19] <wxl> siiiiiiiiiiiiiiiiiigh
[03:23] <tsimonq2> wxl: see lubuntu-devel
[03:23] <tsimonq2> wxl: pinging because it looked like you were around :)
[03:24]  * tsimonq2 goes to bed
[03:24] <wxl> tsimonq2: nothing i can do about it anyways
[03:25] <tsimonq2> wxl: alright, have a good night :) :P
[03:25] <wxl> night
[03:27] <wxl> !info keepassx2 trusty
[03:27] <wxl> !info keepassx2
[03:27] <wxl> !info keepass2
[03:27] <wxl> ah ha


[01:59] <mup> PR snapd#3205 closed: tests: add openvswitch interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3205>
[05:56] <mup> PR snapcraft#1282 opened: parts: remove the deprecated snap keyword from the internal parts representation <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1282>
[06:18] <mup> PR snapd#3138 closed: interfaces/mount: add Change.Perform <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3138>
[06:39] <pedronis> mvo_: morning, I need 2nd reviews of snapd#3192 and snapd#3239
[06:39] <mup> PR snapd#3192: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192>
[06:39] <mup> PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239>
[06:51] <mvo_> pedronis: thank, I have a look
[07:18] <pstolowski> morning
[07:30] <zyga> good morning
[07:30] <zyga> mvo_: sorry for being late, I will focus on code reviews the whole day
[07:31] <mvo_> zyga: hey, good morning. and no worries
[07:34] <zyga> mvo_: did you see this error<EMAIL_ADDRESS>[07:34] <zyga> + dpkg --purge --force-depends snapd
[07:35] <zyga> dpkg: error processing package snapd (--purge):
[07:37] <mvo_> zyga: I have not seen this error yet. pre-removal script returned 1 is really not helpful :(
[07:38] <zyga> mvo_: are those logged in any dpkg specific log file?
[07:39] <mvo_> zyga: unfortunately not, the best info we have is "Job for snapd.service canceled." right before that
[08:12] <mup> PR snapd#3197 closed: store: retry on connection reset too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3197>
[08:20] <mup> PR snapd#3192 closed: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3192>
[08:24] <pedronis> mvo_: static checks are failing on the refresh scheduling branch, and thanks for bearing with me about naming stuff
[08:25] <pedronis> mvo_: also thanks for the other review
[08:28] <mup> PR snapd#3240 opened: snap: add `snap refresh --time` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/3240>
[08:28] <mvo_> pedronis: thank, looking
[08:29] <mvo_> thanks even
[08:37] <ogra_> zyga, do you have access to https://travis-ci.org/profile/snapcore  i would like to get the core-build branch turned on
[08:37] <ogra_> (or mvo_ ^^)
[08:37] <zyga> ogra_: looking
[08:38] <zyga> my github token is in poland so... fingers crossed
[08:38] <zyga> I have
[08:38] <zyga> ah, no
[08:38] <ogra_> whee
[08:38] <zyga> You require admin rights to enable these repositories
[08:38] <ogra_> :(
[08:38] <zyga> so that's gustavo or mvo perhaps
[08:38] <mvo_> ogra_: I can not
[08:38] <zyga> or JamieBennett
[08:38] <zyga> it's pretty terrible that we don't even know who controls this apart from gustavo
[08:39] <JamieBennett> zyga: I do not have admin rights there, I would defer to niemeyer
[08:39] <ogra_> yes, spoiled by LP team management :)
[08:39] <ogra_> ok, then i'll wait
[08:39] <zyga> thanks for checking JamieBennett
[08:40] <pedronis> Chipaca: hi, maybe you can give a 2nd review to snapd#3239 (it's smallish and has already a +1)
[08:40] <mup> PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239>
[08:41]  * zyga is sorry about the lack of reviews
[08:42] <zyga> I'll spend my whole day reading code, no writing today
[08:42] <Chipaca> pedronis— perhaps I could
[08:44] <ogra_> hey, seeing suddenly each and ever project switch to meson ... do we have support for that in snapcraft yet
[08:44] <ogra_> *every
[08:44] <ogra_> seems to be the next famous thing
[08:44] <Chipaca> http://mesonbuild.com/ ?
[08:44] <ogra_> yep
[08:45] <pedronis> Chipaca: thx
[08:48] <pedronis> mvo_: once #3239 lands I'm down to two PRs, one should be ok but needs  re-review/reviews, the other needs a little bit of further work
[08:55] <mvo_> pedronis: great, thank you
[08:56] <ogra_> sigh,. what changed in the store ... the core builds constantly fail uploading with a proxy error
[08:57] <mvo_> Chipaca: I like your suggestion about the --time help output. how about "Only show refresh time information" or "Only show refresh times information but not perform any refresh"?
[08:57] <ogra_> cjwatson, did anything change over night ? i did hit the retry button 3 times for 5 snaps already, all fail
[08:58] <ogra_> cjwatson, https://launchpad.net/~snappy-dev/+snap/core/+build/34833 or https://launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/34849
[08:59] <zyga> mvo_: maybe `snap refresh --query`
[08:59]  * zyga reads that branch now
[08:59] <Chipaca> mvo_— ( show refresh schedule information | list packages that would be refreshed ) but do not perform a refresh ?
[09:00] <Chipaca> zyga— --query is weird, as you might expect its output to be that of --list
[09:02] <zyga> Chipaca: hmm, I agree
[09:02] <zyga> Chipaca: but --time is also weird in this context
[09:02] <Chipaca> zyga— remove all flags, add a single --dwim
[09:02] <zyga> Chipaca: I don't like it when "command --option" does something that more feels like "command subcommand"
[09:02] <zyga> Chipaca: --dwim?
[09:02] <zyga> dowhatimean?
[09:02]  * Chipaca nods
[09:03] <zyga> no, wait, blue WHAAAM
[09:03] <mvo_> Chipaca: works for me, thanks for the suggestion!
[09:07] <Chipaca> mvo_— and i notice its prereq is gtg once green
[09:07] <mvo_> Chipaca: indeed :)
[09:16] <zyga> mvo_: added one question about 3240
[09:18] <pedronis> notice that we already have snap refresh ---list
[09:18] <pedronis> so that boat has sailed I think
[09:19] <zyga> yes, it is somewhat unavoidable, and I suspect nobody is really bothered by this (just software being software)
[09:22] <mvo_> zyga: uh, nice catch! thank yu
[09:23] <zyga> mvo_: ah, I wasn't sure if this is some deliberate design!
[09:23] <pstolowski> mvo_, added a test to #3235
[09:23] <zyga> mvo_: I'll read the rest (I oftne start from the bottom for no other reason than that it feels less daunting) :-)
[09:24] <cjwatson> ogra_: 502 means a problem within click-updown
[09:24] <cjwatson> ogra_: so if something changed it was on the store side, not LP
[09:24] <mvo_> pstolowski: \o/
[09:29] <cjwatson> ogra_: raised on the OLS channel since our failure rate has definitely got a lot worse in the last day or two
[09:30] <ogra_> cjwatson, yeah, it started around easter that i saw the first failures in a while, but it got massively worse during this week
[09:30] <morphis> zyga: did you rebase my branch?
[09:32] <morphis> zyga: the interesting thing is that I don't have tests/main/interfaces-openvswitch  in my tree
[09:32] <zyga> morphis: no, I commented on what is in the PR
[09:32] <zyga> morphis: I didn't even clone it locally
[09:32] <zyga> morphis: merge master, fix the test and push
[09:33] <zyga> morphis: maybe travis tests the merged branch as well as the branch itself
[09:35] <morphis> zyga: done
[09:35] <pedronis> "The job exceeded the maximum time limit for jobs, and has been terminated." is a bit frustrating :/
[09:35] <zyga> yes, indeed
[09:36] <zyga> especially since travis is there only to hand-hold spread and its army of VMs
[09:37] <cjwatson> ogra_: There was a previous incident that was due to a large volume of logs being shovelled around within prodstack and swamping internal bandwidth, but that was fixed
[09:38] <cjwatson> (we should possibly detect 502 and retry, but with the current failure rate I don't know that it'd make a whole lot of difference)
[09:46] <Trevinho> jdstrand: can you try use snapcraft-preload from this branch https://github.com/3v1n0/snapcraft-preload/tree/string-appends-fixes ?
[09:46] <Trevinho> it should fix the issues you were facing...
[09:54] <Trevinho> jdstrand: applying http://pastebin.ubuntu.com/24459277/ should be enough
[09:55] <jacekn> hello. How to "unpublish" snap from all channels?
[09:56] <zyga> jacekn: "snapcraft close" I think
[09:58] <jacekn> zyga: hmm ok, I may have to log in to do that (I was trying to avoid that)
[09:59] <zyga> jacekn: I suspect you can do that from the web UI too
[09:59] <zyga> jacekn: just not sure as I didn't try
[10:00] <jacekn> zyga: does not look like it, when I untick all channels web UI says "This field is required"
[10:02] <jacekn> zyga: ah alright so look like it's because the store must have something in edge and beta. I used snapcraft close and that just switched beta and edge to the same revision as candidate
[10:06] <pstolowski> Chipaca, added 1 comment to your tab-completion
[10:06] <Chipaca> woo
[10:07] <pstolowski> chances are it's nonsense ;)
[10:07] <Chipaca> oh the _other_ tab completion one
[10:07] <Chipaca> :-)
[10:07] <pstolowski> (my comment, not your PR)
[10:08] <Chipaca> good question about empty :. Let me check.
[10:09] <ogra_> cjwatson, well, the failure seems pretty reliable now ... in case anyone needs reproducers ... let me know ...
[10:10] <pedronis> pstolowski: made a small comment in one of your interface hooks PRs
[10:10] <zyga> mvo_: added one more comment to https://github.com/snapcore/snapd/pull/3240
[10:10] <mup> PR snapd#3240: snap: add `snap refresh --time` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/3240>
[10:10] <Chipaca> pstolowski— basically parts[0] would be "", meaning we'll suggest any and all plugs :-(
[10:10] <pstolowski> pedronis, yes, just saw them thanks!
[10:10] <pstolowski> Chipaca, ha!
[10:11] <Chipaca> pstolowski— i'll confirm this empirically in a moment
[10:12] <pstolowski> Chipaca, should be easy to handle and make "" into "core" I guess, and let all the remaining logic do the job?
[10:12] <mvo_> zyga: aha, another nice catch, thank you again
[10:12]  * zyga is super slow with reviews, needs to switch into review mood
[10:16] <Chipaca> pstolowski— ah, we don't offer everything, we offer nothing instead
[10:16] <Chipaca> slightly better
[10:16] <Chipaca> still, I'll force it to 'core' if empty
[10:20] <pstolowski> Chipaca, :)
[10:22]  * zyga breaks for some lunch and coffee
[10:22] <zyga> brb
[10:23] <niemeyer> Mornings
[10:25] <mvo_> hey niemeyer, good morning!
[10:27] <pstolowski> hey niemeyer
[10:31] <mup> PR snapd#3241 opened: snap: make `snap prepare-image` read .assert files for local snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3241>
[10:32] <mup> PR snapd#2895 closed: client,cmd/snap: first pass at client messaging around modes <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2895>
[10:35] <jacekn> anybody knows what the problem could be? http://pastebin.ubuntu.com/24459530/ if I revert to tag v1.5.2 it builds fine so must be someting on prometheus side but still snapcraft should allow me to build it?
[10:36] <Chipaca> pstolowski— addressed
[10:37] <pstolowski> 👍👍
[10:37] <niemeyer> mvo_, pstolowski: Mornings!
[10:38] <niemeyer> mvo_: Seeing the recent change in snapd#2833, isn't there a test missing there?
[10:38] <mup> PR snapd#2833: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
[10:38] <Chipaca> jacekn— looks like a bug in prometheus indeed
[10:38] <Chipaca> jacekn— it's importing "context" from the wrong place
[10:38] <Chipaca> jacekn— that is an error from Go itself
[10:39] <Chipaca> jacekn— “package context: unrecognized import path "context" (import path does not begin with hostname)” i mean
[10:39] <Chipaca> it is a strange one though
[10:42] <mup> PR snapd#3239 closed: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3239>
[10:42] <jacekn> Chipaca: coudl the fact that snapcraft prepends improt-path with "./" ahve anythihng to do with it? 'go', 'get', '-t', '-d', './github.com/prometheus/prometheus/...']'
[10:43] <Chipaca> jacekn— it shouldn't, but it might
[10:43] <Chipaca> jacekn— give me a bit
[10:44] <morphis> niemeyer: anything left to get https://github.com/snapcore/spread-images/pull/1 merged?
[10:44] <mup> PR spread-images#1: Add debian-unstable-64 base image <Created by morphis> <https://github.com/snapcore/spread-images/pull/1>
[10:47] <Chipaca> jacekn— what happens if you run that by hand, adding a -v to it?
[10:49] <jacekn> Chipaca: it will fail I'm pretty sure because of missing GO env variables but I can try setting it up
[10:51] <pedronis> niemeyer: hi, snapd#3237 can be reviewed again
[10:51] <mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
[10:52] <Chipaca> pstolowski— hm, re-reading your comment, is it only ever :<slot>, never :<plug>?
[10:56] <pstolowski> Chipaca, I think so yes, would need to check Resolve* methods again
[10:57] <Chipaca> then i've got this wrong. amending.
[10:58] <pstolowski> Chipaca, please double check in repo.go
[10:58] <niemeyer> morphis: It's in
[10:58] <morphis> niemeyer: thanks
[11:00] <niemeyer> morphis: np
[11:00] <niemeyer> pedronis: Looking
[11:00] <morphis> niemeyer: another one for fedora is coming soon
[11:01] <Chipaca> pstolowski— in connect, empty means core only for the slot; in disconnect, it's either
[11:02] <mup> PR snapcraft#1281 closed: core: switch to version git <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1281>
[11:09] <Chipaca> popey— about https://forum.snapcraft.io/t/broken-snap-breaking-snapd/401 zyga seemed to know what it was about (and there was a pr to address it)
[11:09] <Chipaca> popey— i'll give him a shout to have him comment in there when he's around
[11:10] <pstolowski> Chipaca, right
[11:11] <popey> Chipaca: thanks
[11:15] <niemeyer> pedronis: LGTM
[11:15] <pedronis> niemeyer: thx
[11:17] <ogra_> niemeyer, could you please enable travis for the core-build branch ?
[11:17] <niemeyer> ogra_: Done
[11:17] <ogra_> thanks :)
[11:18] <niemeyer> Any time
[11:18] <Chipaca> zyga— hey
[11:19] <Chipaca> zyga— we're seeing more and more panics in the wild with the nil map
[11:19] <Chipaca> zyga— what is the status of that fix?
[11:19] <zyga> Chipaca: let me see
[11:19] <Chipaca> zyga— and can you comment about it on https://forum.snapcraft.io/t/broken-snap-braking-snapd/401
[11:19] <zyga> Chipaca: yes
[11:20] <zyga> Chipaca: so the fix was merged by mvo long ago
[11:20] <zyga> Chipaca: we should also review and merge https://github.com/snapcore/snapd/pull/3208 to stay proactive for future issues
[11:20] <mup> PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <https://github.com/snapcore/snapd/pull/3208>
[11:21] <zyga> Chipaca: done
[11:22] <Chipaca> zyga— what is the snap doing wrong such that it breaks snapd?
[11:23] <zyga> Chipaca: just make a snap that has a "content" plug
[11:23] <zyga> Chipaca: without anything else
[11:24] <zyga> Chipaca: we go and sanitize that, notice the content type is empty so we go and say it is the same as the interface name
[11:24] <mup> PR snapd#3242 opened: tests: tweak time for econnreset test a bit more <Created by mvo5> <https://github.com/snapcore/snapd/pull/3242>
[11:24] <zyga> Chipaca: but then whaam, attr is a nil map
[11:24] <zyga> Chipaca: I fixed that quite some time ago
[11:24] <ahayzen> zyga, hey, you state to install the edge core snap to 'see the error go away', but i can't install the one from edge as the snapd service crashes as soon as it starts :-) is there anyway i can manually stop it trying to do the security profiles step ?
[11:25] <zyga> ahayzen: aha, when you already have that snap installed
[11:25] <zyga> ahayzen: I'm not sure actually
[11:25] <zyga> ahayzen: (eventually, like in two weeks) the change will garbage collect and won't run anymore
[11:25] <zyga> ahayzen: but I assume you meant for something better
[11:25] <ahayzen> like it failed to install and there is a pending task that never completes todo the security profiles (which then crashes each time the service starts)
[11:26] <ahayzen> zyga, right, yeah i was looking for a way to 'fix' my system :-) anyway i can force the garbage collect or something?
[11:26] <zyga> Chipaca, mvo_: ^ any ideas?
[11:26]  * zyga has none apart from moving the needle of time a little bit forward
[11:27] <ahayzen> :-)
[11:27] <zyga> mvo_: perhaps curious input to the repair assertion
[11:28] <niemeyer> morphis: Do you have the fixes for the PR we discussed lined up?
[11:28] <zyga> mvo_: I'd say that it would be good if we could send a repair assertion that repairs the state without sending 10MB binary
[11:28] <niemeyer> morphis: Want to include in the board
[11:28] <morphis> niemeyer: not yet
[11:29] <niemeyer> morphis: Okay, can you put that up in the pipeline so we don't risk releasing without the fixes?
[11:32] <pedronis> Chipaca: mvo_: snapd#3237 needs a 2nd review
[11:32] <mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
[11:33] <mup> PR snapd#3208 closed: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3208>
[11:40] <sil2100> Hello! We seem to be haunted today by sha mismatches today when getting the pc-kernel snap from the store - almos all our autopkgtests for ubuntu-image failed with this error:
[11:40] <sil2100> error: sha3-384 mismatch for "pc-kernel": got 7873b5723739ece72e102f518ba4c3e4c8e656ea2f64f80759a4fcda0e0737ca1d13459ac97221a4a059fce357a2ca46 but expected 33d383ce8f59a0cc43905da29208d6152d8204dd7a90500d4dfd2f1586d440359796374f17778a88948561c002cc563a
[11:40] <sil2100> Does anyone know if there are any outages/issues that could cause this?
[11:40] <ogra_> sil2100, i wonder if thats related to the upload errors i see for the core snaps (proxy error)
[11:41] <niemeyer> sil2100: Can you please open a topic in the forum under the store category?
[11:42] <niemeyer> sil2100: Actually, I suspect we even already have a topic for that particular error
[12:00] <Chipaca> pstolowski— pushed a thing to handle : in connect better
[12:02] <Chipaca> sil2100— i'm willing to bet one of those hashes is the hash of '503 Service Unavailable'
[12:02] <Chipaca> sil2100— or sth like that
[12:03] <zyga> Chipaca: 504 Cure For Cancer Follows, but we only have the hash
[12:06]  * ogra_ wonders if he needs to swing another magic wand to make https://travis-ci.org/snapcore/core-build/builds/225967248 start
[12:06] <ogra_> sits there since ages
[12:09] <ogra_> hah !
[12:10] <ogra_> complaining here helps it seems :)
[12:10] <Son_Goku> ogra_, hitting it with a hammer helps too :)
[12:10]  * Son_Goku hates Travis CI
[12:10] <ogra_> well, once it runs it is fine
[12:11] <mup> PR snapcraft#1283 opened: core: predetermine the magic path when a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1283>
[12:14] <pstolowski> Chipaca, thanks
[12:15] <pedronis> ogra_: we were pinged here
[12:15] <ogra_> yeah
[12:15] <pedronis> but there's a forum topic
[12:16] <ogra_> yeah
[12:16] <pedronis> so any suggestion will go there
[12:46] <facubatista> question, does build.snapcraft.io build for several architectures?
[12:46] <ogra_> armhf and amd64 i think
[12:48] <facubatista> ogra_, thanks
[12:57] <Chipaca> jdstrand— thinking of changing the cat in complete.sh to \grep -v '[[:cntrl:];?*{}]'
[12:58] <ogra_> poor cat
[12:59] <zyga> Chipaca: does [[:cntrl:]] in any insane way depend on locale?
[12:59] <zyga> (just checking)
[12:59] <ogra_> nope
[13:00] <Chipaca> zyga— if it does, it's not insane :-)
[13:00]  * zyga reads the aliases branch
[13:00] <zyga> Chipaca: in nort korea space is a control character because they have little space
[13:00] <Chipaca> zyga— and way too much control
[13:06] <jdstrand> Chipaca: that seems like a reasonable start (I've not started looking at the branch yet today)
[13:06] <jdstrand> again yet...
[13:07] <Chipaca> jdstrand— I'm looking for something that's good enough to merge (so it can be in 2.25) even if we then make it better later
[13:07]  * jdstrand nods
[13:08] <jdstrand> I'll be getting back to this btw. just tending to review tools updates for the bad snap issue
[13:09] <Chipaca> np
[13:14] <niemeyer> morphis: not sure if you've seen that message: can you put that up in the pipeline so we don't risk releasing without the fixes?
[13:29] <mup> PR snapd#2833 closed: many: allow core refresh.schedule setting <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2833>
[13:32] <pedronis> mvo_: yay ^ !
[13:36] <fgimenez> mvo_: while working on an extension of the system-observe interface test i've found that any snap, even if they don't declare any plug, can read /proc/meminfo, this can't be intended, right?
[13:39] <mvo_> pedronis: \o/ indeed
[13:41] <mvo_> fgimenez: hm, that is curious
[13:41]  * mvo_ looks
[13:43] <Chipaca> zyga, jdstrand, why am i getting “hsearch_r failed” for things that used to work?
[13:44] <fgimenez> mvo_: thanks, a simple snap like this is enough to check http://paste.ubuntu.com/24460232/, with that installed "system-observe-consumer cat /proc/meminfo" shows the contents (the name of the snap can be misleading, no interface involved)
[13:44] <mvo_> fgimenez: I can confirm with hello-world.sh that I can read /proc/meminfo without special permissions. this is curious because "git grep meminfo" only shows an allow rule in the system-observer. maybe jdstrand knows more?
[13:48] <pedronis> zyga: sounds like out of sync snap-confine vs sepcomp bits in snapd
[13:48] <pedronis> sorry
[13:48] <pedronis> Chipaca: ^
[13:48] <pedronis> * in/from
[13:49] <pedronis> Chipaca: we should have ways to avoid that but if you running things manually I suppose it can happen
[13:54] <mup> PR snapd#3171 closed: snapstate: normalize gadget defaults <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3171>
[13:56] <mup> Bug #1619154 changed: Cannot adjust systemd service definition <Snapcraft:Opinion> <Snappy:Opinion> <https://launchpad.net/bugs/1619154>
[14:07] <Chipaca> a'ight
[14:07] <Chipaca> jdstrand— I added https://github.com/snapcore/snapd/pull/3150/commits/6dcbcded52192f57dedb980872e6ad22a84a93e8 and all tests passed just the same
[14:07] <mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
[14:21] <mvo_> morphis: do you need a hand with the xauthority PRs comments from gustavo? we need those for 2.25 (or revert the PR) so I'm keen to get things addressed  asap
[14:24] <jdstrand> Chipaca: nice
[14:53] <morphis> mvo_: no, working on them now
[14:53] <morphis> mvo_: had to leave for a fire accident as I am a fire fighter; already started with them earlier today
[14:53] <morphis> mvo_: sorry for the delay
[14:54] <ogra_> another attempt of blowing up your city hall ?
[14:56] <morphis> ogra_: not really .. we already had a bigger ship on fire on tuesday really early in the morning ..
[14:56] <morphis> and today somebody decided to get light his shed :-)
[14:57] <ogra_> oh my
[14:57]  * niemeyer will feel safer with morphis around from now on
[14:58] <morphis> :-)
[14:58]  * ogra_ makes a note to not move to verden if not owning fireproof underwear
[14:58] <mup> PR snapd#3243 opened: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
[14:58] <morphis> ogra_: hehe, however I guess the rate of fire accidents is quite similar anywhere else too :-)
[14:59] <ogra_> yeah
[14:59] <morphis> we have about 20-30 alarms per year were only ~5 are real fires
[14:59] <ogra_> the guy trying to blow up the city hall was unique though ... enough to make the news :)
[14:59] <zyga> jdstrand: I made a small branch to fix a bug that was uncovered by CE
[14:59] <zyga> jdstrand: added you as a reviewer
[15:01] <morphis> ogra_: yeah ..
[15:01] <ogra_> crazy germans ... :)
[15:01] <morphis> ogra_: http://www.nonstopnews.de/galerie/25062 is what we had yesterday
[15:02] <ogra_> oh man
[15:03] <niemeyer> Lunch!
[15:04] <pedronis> Chipaca: mvo_: I need a 2nd review of snapd#3237
[15:04] <mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
[15:04] <Chipaca> on it
[15:04] <pedronis> Chipaca: it's a small one
[15:07] <mvo_> morphis: no worries, just wanted to make a friendly offer for help :)
[15:07] <morphis> mvo_: thanks!
[15:08] <mvo_> pedronis: I have a look as well
[15:09] <Chipaca> pedronis— what's the “! snap aliases | MATCH ... ” thing?
[15:10] <Chipaca> pedronis— more exactly, what's the start-command-with-bang thing
[15:10] <pedronis> Chipaca: it negates the whole pipeline, it succeed if the pipeline files
[15:10] <pedronis> s/files/fails/
[15:11] <Chipaca> TIL
[15:11] <pedronis> it's an obscure bit
[15:11] <pedronis> admittedly
[15:11] <pedronis> Chipaca: man bash and search pipelines,  there's option [!] bit in there
[15:12] <Chipaca> will do
[15:14] <pedronis> Chipaca: thx
[15:14] <mup> PR snapd#3237 closed: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3237>
[15:17] <mvo_> pedronis: 3220 has test failures that look unrelated (mirror on linode issues?). do you mind if I restart the test?
[15:18] <pedronis> mvo_: I'm about to push a merged anyway
[15:18] <mvo_> pedronis: even better
[15:20] <pedronis> not that it will make it smaller, it's big mostly because of tests
[15:22] <mvo_> pedronis: ok :)
[15:22] <pedronis> I mean it's main prereq was already merged
[15:25] <pedronis> mvo_: pushed now
[15:27] <zyga> mvo_: can you consider https://github.com/snapcore/snapd/pull/3243 for 2.25 as a fix for CE, assuming that jdstrand gives it a +1
[15:27] <mup> PR snapd#3243: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
[15:28] <mvo_> zyga: we need input from jamie here, but yeah, I think thats ok. this really feels like we need the "snapd controls how snpa-confine behaves" changes we talked about
[15:28] <zyga> mvo_: yes but this is just a bugfix, not related to any re-architecture
[15:29] <zyga> mvo_: it was supposed to work like that but this was missed
[15:29] <morphis> niemeyer, mvo_: https://github.com/snapcore/snapd/pull/3244
[15:29] <mup> PR snapd#3244: many: fix review comments from PR #3177 <Created by morphis> <https://github.com/snapcore/snapd/pull/3244>
[15:29] <mup> PR snapd#3244 opened: many: fix review comments from PR #3177 <Created by morphis> <https://github.com/snapcore/snapd/pull/3244>
[15:35] <mup> PR snapcraft#1283 closed: core: predetermine the magic path when a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1283>
[16:05] <mup> PR snapd#3245 opened: many: aliases v2 cleanups <Created by pedronis> <https://github.com/snapcore/snapd/pull/3245>
[16:08] <pedronis> mvo_: ^ this is the small cleanups branch I mentioned at the standup, anyway current blocker is reviews for snapd#3220
[16:08] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[16:18] <pedronis> mvo_: niemeyer: seems we are hitting archive or network fun in the tests now, I got:
[16:20] <pedronis> https://travis-ci.org/snapcore/snapd/builds/226053803
[16:22] <mvo_> pedronis: :(   Unable to connect to mirrors.linode.com:http:
[16:25] <mvo_> pedronis, niemeyer: it looks like we should open a support ticket on linode if their mirror times out?
[16:27] <niemeyer> pedronis: Where did you see that message?
[16:28] <niemeyer> mvo_: ^
[16:28] <niemeyer> Looking at the error there I couldn't find it
[16:28] <pedronis> niemeyer: last run for snapd#3220
[16:28] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[16:28] <pedronis> niemeyer: some project prepare have "unable to locate pkg foo" and some have a bunch of those mirror errors
[16:29] <niemeyer> pedronis: Yeah, sorry.. was looking at the Travis error and wondering about the message mvo_ pasted above
[16:29] <niemeyer> Aha
[16:30] <niemeyer> pedronis, mvo_: Mirror seems up now
[16:31] <pedronis> I went through the list of PRs, I think I commented on the ones I could, some have feedback that nees acting on, some I think need niemeyer input/opinion
[16:31] <pedronis> I mean the PRs in the sprint post
[16:32] <niemeyer> pedronis: Thanks!
[16:33] <pedronis> niemeyer: snapd#3220 should be ready for reviewes btw,  also I pushed the small cleanup PR I mentioned in the standup
[16:33] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[16:33] <niemeyer> pedronis: Thanks, will look into it next
[16:34] <Chipaca> jdstrand— how's it going?
[16:35]  * pedronis going afk for a while, will check on things later
[17:08] <morphis> Pharaoh_Atem: https://paste.ubuntu.com/24461436/ .. we're moving :-)
[17:10] <Pharaoh_Atem> :D
[17:15] <morphis> Pharaoh_Atem: still quite hacky but it works
[17:15] <Pharaoh_Atem> it's a start!
[17:18] <cjwatson> ogra_: LP->store uploads may be better now after IS stopped some swift migration jobs
[17:22] <ogra_>  heh, ok, i'll try a re-upload
[17:22] <ogra_> cjwatson, thanks!
[17:26] <pedronis> linode:ubuntu-14.04-64:tests/main/econnreset is really quite flaky
[17:40] <jdstrand> Chipaca: hey, going to get back to it just a sec
[17:48] <jdstrand> mvo_: fyi, I approved https://github.com/snapcore/snapd/pull/3243
[17:48] <mup> PR snapd#3243: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
[18:02] <mup> PR snapcraft#1284 opened: extra verbose tests  <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1284>
[18:08] <mup> PR snapcraft#1284 closed: extra verbose tests  <Created by cprov> <Closed by cprov> <https://github.com/snapcore/snapcraft/pull/1284>
[18:47] <pedronis> niemeyer: I tried to address or answer the comments to snapd#3220
[18:47] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[18:57] <niemeyer> pedronis: Cheers!
[19:15] <pedronis> niemeyer: was the review sprint forum post synced recently ? I see some branches that were merged not marked as such
[19:21] <mvo_> a second review for 3240 would be great
[19:35] <niemeyer> pedronis: No, need to update.. currently running an errand but will update shortly
[19:56] <niemeyer> pedronis: Updating, and also integrating a few of the new PRs that were pushed in the last two days
[20:08] <niemeyer> pedronis: Updated
[20:16] <niemeyer> pedronis: LGTM, thanks for the changes!
[20:16] <jdstrand> Chipaca: ok, it took a while to get all the way through it to my satisfaction, but I've left my review feedback
[20:17] <Chipaca> jdstrand— thank you!
[20:17] <Chipaca> niemeyer— do you know if mvo is cutting the release tonight?
[20:17] <jdstrand> Chipaca: it's going to look like a lot, but it is almost all requesting adding comments here and there. I tried to give comments you can copy/paste to help
[20:17] <niemeyer> Chipaca: I don't think so.. aliases are still not in
[20:17] <Odd_Bloke> I'm talking to someone who's trying to build images but they don't yet have an account ID because they haven't uploaded a snap; is there an easy way for them to generate one without messing around with actually building/registering a snap?
[20:17] <Chipaca> niemeyer— ah ok
[20:18] <Chipaca> then i'm going to not address the review and instead sleep :-)
[20:18] <niemeyer> Chipaca: Sounds like a good plan
[20:18] <Chipaca> jdstrand— appreciated. I'll get to them in my morn.
[20:18] <jdstrand> Chipaca: goodnight! I feel like I can talk fairly intelligently about this now. hopefully it won't atrophy by morning :)
[20:18] <Chipaca> jdstrand— will you want to once-over it once I do so, or are you ok with it landing?
[20:19] <jdstrand> Chipaca: I said 'request changes', so feel free to ping me when you do the changes and I'll go through it real quick
[20:19] <Chipaca> ah ok
[20:19] <niemeyer> Odd_Bloke: I suggest asking the question in the forum under the store category.. I know where we want to be, but I don't know what the status of account names is just now
[20:21] <Chipaca> jdstrand— and yes \foo in bash is a way to make sure you call the builtin (or external program) and not a function or alias
[20:21] <jdstrand> Chipaca: a comment stating that would be cool :)
[20:22] <jdstrand> Chipaca: do you sense a theme?
[20:22] <Chipaca> jdstrand— no
[20:22] <Chipaca> no theme sensing
[20:22] <jdstrand> hehe
[20:22]  * jdstrand is big on commenting
[20:22]  * Chipaca sucks at commenting almost as badly as he sucks at naming things
[20:22] <jdstrand> Chipaca: you've won some sort of best/worst of with etelpmoc.sh
[20:23] <Chipaca> \o/ <- winning!
[20:23] <jdstrand> I mean it is brilliantly terrible
[20:23] <jdstrand> it's perfect, yet horrible
[20:23] <jdstrand> please take that as a compliment :)
[20:28] <pedronis> niemeyer: thanks, should we rename refresh-aliases to refresh-auto-aliases?
[20:47] <niemeyer> pedronis: I think refresh-aliases is fine
[20:47] <niemeyer> pedronis: It may end up growing up some activity about manual aliases, even if it doesn't today
[20:50] <pedronis> ok
[21:35] <pedronis> ok, snapd#3220 needs a 2nd review and then we just have #3245 which after the former should be small and hopefully uncontroversial
[21:35] <mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
[21:35]  * pedronis -> rest