[12:27] <bac> hey rick_h_
[12:28] <rick_h_> bac: morning
[12:29] <bac> rick_h_: so, it turns out mjc still had a cronjob to do queueing.  that should've been removed in a version of the charm a few back.
[12:29] <bac> rick_h_: once it was turned off manually everything is normal
[12:29] <bac> rick_h_: so, i have some charm oddities to investigate.  1) why didn't the config file get written properly and 2) why wasn't the new cron entry written?
[12:34] <rick_h_> bac: hmm, could it be like a migration story?
[12:35] <rick_h_> when the charm upgrades it needs to go back and remove the old files it no longer needs
[12:35] <rick_h_> like dropping tables in a db no longer used 
[12:35] <rick_h_> staging gets 'rebuilt' more often, though not recently. It does get manually touched and farther from the base charm path I'd guess. 
[12:42] <bac> rick_h_: the hooks in the charm should handle re-writing those files.
[12:43] <bac> rick_h_: the only thing i can think of is that I.S. has made some modifications since they muck with the charm before deploying.
[12:43] <bac> rick_h_: another reason we need a prodstack-based staging server...
[12:43] <rick_h_> bac: right, but if we drop a file in /etc/cron.d we have to manually remove it on upgrade right?
[12:43] <rick_h_> the charm doesn't follow old written files to clean up 
[12:44] <bac> rick_h_: there is a template for creating that file.  it should get re-written based on the changed template
[12:44] <rick_h_> ok, so it was not 100% removed from existance then?
[12:44] <bac> rick_h_: no, just one entry was to be removed and another added
[12:44] <rick_h_> gotcha
[12:44] <bac> rick_h_: but the version of cron.d/charmworld on prod was the old one
[12:45] <bac> rick_h_: makes me suspect their novel version has changed something
[12:45] <bac> perhaps they maintain a modified version of the template
[12:45] <rick_h_> layers of invisible bug points wheeee
[12:49] <bac> data centre nightmare: http://www.bbc.co.uk/news/uk-england-london-25873252
[12:49] <bac> add that to your contingency plans
[13:25] <hatch> morning all
[13:25] <gary_poster> hiya
[13:34] <hatch> lastnight I set my laptop up on my monitor finally....wow my monitor resolution sucks compared to the retina screen lol
[13:34] <hatch> I need rick_h_ 's 4k 
[13:34]  * frankban lunches
[13:35] <rick_h_> hatch: :P
[13:35] <hatch> as long as I place my monitor far enough away it's ok
[13:35] <hatch> so that's cheaper I suppose
[13:35] <hatch> lol
[13:37] <gary_poster> I want the 4k too.  Kinda tempted to see what Apple comes out with for that though
[13:38] <rick_h_> yea, why I got this ultrasharp. the dell US and apple displays generally share the same panels
[13:38] <rick_h_> though I'm sure the apply will be nice with lightning connectors/etc
[13:38] <rick_h_> while I got usb3
[13:39] <hatch> I noticed that the laptop screen has horrible glare while my monitor has a matte finish
[13:39] <rick_h_> matte or bust!
[13:39] <hatch> yeah, not sure I'd enjoy a 30" glossy screen
[13:39] <hatch> unless they have better glare reduction than the laptop screen
[13:40] <rick_h_> some of it's the size I bet as well. lot more surface to catch it
[13:40] <hatch> yeah, and the window and lights are behind me so that just compounds it
[13:40] <hatch> buuuut sitll, matte doesn't have the issue :P
[13:41] <hatch> is the 4k matte?
[13:41] <rick_h_> yea, I only do matte
[13:41] <gary_poster> heh
[13:41] <rick_h_> I got one glossy and it's been in my closet for a long time
[13:41] <rick_h_> should sell it
[13:41] <hatch> does it have a 'sparkle' look to it? 
[13:41] <hatch> on a white screen I can see these little sparkles in the monitor 
[13:42] <rick_h_> not sure 
[13:42] <hatch> the internet claims it's from the matte coating
[14:12] <hatch> frankban any questions re the putcharm stuff?
[14:43] <frankban> hatch: hey, so what's the target URL? https://{state-server-address}/charms/? what port?
[14:44] <hatch> dimitern are you around?
[14:45] <hatch> frankban dimitern wrote the juju-core implementation. so he would know best. From the docs I would assume the state server address on 17070
[14:45] <hatch> in the email I sent it had the structure of the url 
[14:46] <frankban> hatch: cool, so 1111 is just something you use for debugging, right?
[14:47] <hatch> frankban yes sorry, that's just the port I use for my tunnel 
[14:48] <frankban> hatch: ok thank you. starting the branch now, will ping you later for any questions
[14:48] <marcoceppi> rick_h_ or bac are either of you guys running trusty?
[14:49] <bac> marcoceppi: i have a trusty vm but had to stop using it temporarily. can fire it up if needed.
[14:49] <bac> marcoceppi: but in general i'm running saucy
[14:49] <hatch> frankban thanks!
[14:49] <marcoceppi> bac: no, that's fine. there's a dep for amulet that's not building on trusty but builds on all other series
[14:50] <marcoceppi> wanted to know how to prioritize it for today's test writing sprint
[14:50] <gary_poster> jujugui call in 10
[14:50] <gary_poster> wait no
[14:50] <hatch> I was wondering :D
[14:50] <gary_poster> what is the calendar reminding me of now :-P
[14:50] <bac> timewarp
[14:50] <gary_poster> ah, um.  charm testing writing sprint in 9 :-P
[14:53] <rick_h_> benji: got a sec?
[14:54] <benji> rick_h_: sure, want to coopt the dialy meeting hangout?
[14:54] <rick_h_> marcoceppi: I'm on trusty
[14:54] <rick_h_> marcoceppi: what dep, I can peek at it?
[14:54] <hatch> ugh native events are so clunky
[14:54] <rick_h_> benji: here please https://plus.google.com/hangouts/_/72cpjkbrct4593pml722lph0vo?authuser=1&hl=en
[14:54] <hatch> I'm spoiled by YUI's event system
[14:54] <rick_h_> hatch: +1
[14:54] <marcoceppi> rick_h_: sure, I jsut asked for another build but it's charmworldlib
[14:55] <marcoceppi> rick_h_: when/if it errors out in the next few mins I'll send it your way
[14:55] <marcoceppi> it was saying it couuldn't download setuptools.py from the internet
[14:56] <frankban> hatch: is putCharm already implemented in core trunk?
[14:56] <rick_h_> marcoceppi: k
[14:58] <hatch> frankban in trunk yes,
[14:58] <hatch> you'll have to build it
[14:58] <frankban> hatch: ack
[14:59] <hatch> frankban http://bazaar.launchpad.net/~go-bot/juju-core/trunk/revision/2155 the merge
[15:02] <frankban> hatch: cool thanks
[15:09] <dimitern> hatch, frankban , sorry, i'm here now
[15:11] <frankban> hatch: what's the best way in git to get your GUI branch locally? git remote add jeff .. + git checkout -b something + ??
[15:11] <frankban> dimitern: hey, so the URL for putCharm is https://{state-server}:17070/charms/, correct?
[15:12] <dimitern> frankban, yes
[15:12] <frankban> dimitern: cool thanks
[15:13] <dimitern> fwereade, it's actually https://{apiserver:ip}/charms?url={series}
[15:13] <dimitern> frankban, sorry, ?series={series}
[15:14] <frankban> dimitern: ack
[15:18] <hatch> frankban sorry I missed the ding
[15:18] <hatch> one sec I'll paste the git commands
[15:18] <frankban> hatch: cool thanks
[15:21] <hatch> git checkout -b hatch-local-zip-upload develop && git pull git@github.com:hatched/juju-gui.git local-zip-upload
[15:22] <hatch> ^ frankban  I'm pretty sure that's the right command
[15:23] <frankban> hatch: what about the following:
[15:23] <frankban> $ git remote add hatch git@github.com:hatched/juju-gui.git
[15:23] <frankban> $ git fetch hatch
[15:23] <frankban> $ git checkout -b local-zip-upload hatch/local-zip-upload
[15:24] <hatch> yeah I think that'll also work
[15:24] <frankban> yeah, and "git fetch hatch" is cool
[15:24] <frankban> ;-)
[15:24] <hatch> lol
[15:24] <hatch> agreed
[15:26] <frankban> hatch: it worked. so, does your branch work in theory? e.g. I can zip a charm and drop it to the canvas, correct?
[15:27] <hatch> frankban you bet, it should even console.log the progress, error, and loaded events
[15:29] <frankban> hatch: cool. now in theory, when in the future I want to test/review one of your branches, I suppose all I have to do is " git fetch hatch" and git checkout ..., correct?
[15:29] <rick_h_> frankban: yes, you've not setup a new remote that allows you to see what he's got up on github
[15:30] <frankban> rick_h_: and fetch will always update that remote to what's present in github
[15:30] <rick_h_> frankban: yes
[15:30] <rick_h_> frankban: and a normal git fetch should check all remotes
[15:31] <rick_h_> makefile experts, can I change a variable from within a target block somehow?
[15:31] <frankban> rick_h_: makes sense, and what's the difference between pull and fetch? pull is for just one branch?
[15:31] <rick_h_> benji: gary_poster ^
[15:32] <hatch> frankban pull merges
[15:32] <rick_h_> frankban: fetch will not pull down any source/code/etc. It's just a fetch of 'metadata' as I understand it
[15:32] <hatch> fetch just pulls it down
[15:32] <hatch> the metadata
[15:32] <benji> rick_h_: environment variable or make variable?
[15:32] <hatch> yeah
[15:32] <hatch> :)
[15:32] <rick_h_> benji: makefile variable
[15:32] <frankban> cool thanks
[15:33] <benji> rick_h_: is the value static or does it change (like in a loop)?
[15:33] <hatch> frankban here is a very simple comparison http://stackoverflow.com/a/292359
[15:34] <rick_h_> benji: http://paste.ubuntu.com/6808881/
[15:34] <frankban> hatch: ic
[15:35] <rick_h_> benji: the nose path can be in one of two places. If it's missing we pip install it and I want to run that check again and update it
[15:36] <benji> rick_h_: I would probably just re-run the make file (i.e., have make run make)
[15:36] <rick_h_> ooh, it can do that? /me never thought to try that
[15:37] <rick_h_> so at the end of $(NOSE): $(PY) block just run make test?
[15:37]  * rick_h_ is confused how this would work
[15:39] <rick_h_> ok, so it both works and then doesn't because after it re-runs itself and runs the tests, it goes back to the original test target and runs it with the bad path value
[15:39] <benji> oh, you want to depend on nose in order to run test... 
[15:39] <rick_h_> I guess I should just evaluate it in the test block itself
[15:39] <rick_h_> benji: right
[15:40]  * rick_h_ looks if I can create a 'locate_nose' function in the makefile and just use that vs $(NOSE)
[15:40] <benji> that might be an option
[15:40] <hatch> there was a windchill warning in Orlando yesterday....it was +9C lol
[15:41] <benji> doing it recusively shouldn't be too bad, you can have a test target that depends on nose like you have now, then have the body of that test target be just "make post-nose-test" which has no prereqs but has the body of your current test target
[15:41] <rick_h_> benji: ah, gotcha
[15:41] <rick_h_> good call
[15:45] <benji> hatch: I was a little surprised it was so cold here this morning, I had to go to my dad's office to fax something early and it was -18C.
[15:45] <hatch> really? wow I had no idea it got that cold there
[15:45] <rick_h_> polar vortex of doom!
[15:45] <rick_h_> canada, quit sending us your cold air
[15:45] <benji> it doesn't very often :)
[15:46] <rick_h_> benji: bingo, this works nicely. Thanks
[15:46] <benji> I just wish we would get 20 inches of snow to go with it.
[15:46] <hatch> rick_h_ lol, "polar vortex of common place but sensationalized by media"
[15:46] <benji> rick_h_: cool
[15:46] <rick_h_> hatch: no, it's darn colder than the past few winters here
[15:46] <hatch> rick_h_ right, but a polar vortex is not anything special
[15:47] <hatch> every planet has 2 of them and they change in size throughout the year
[15:47] <rick_h_> we get some 0F stuff. but not every day for weeks
[15:47]  * rick_h_ misses 20F and sunny with some snow on the ground
[15:47] <hatch> this year has had low pressures below the polar region so it allowed the north polar vortex to influence the lower weather patterns
[15:47] <rick_h_> when his nose hairs didn't freeze getting the mail
[15:50] <gary_poster> ooh ooh!
[15:50] <gary_poster> jujugui, call in ten *now*
[15:52] <hatch> lol
[15:53] <hatch> TIL: XMLHttpRequests do not throw errors for anything above a total network failure :/
[15:53] <rick_h_> hatch: no, you have to watch them
[15:53] <hatch> if (status > 400 && status < 500) { throw!!!!! }
[15:53] <hatch> such lamesauces
[15:54] <hatch> erll
[15:54] <hatch> well
[15:54] <hatch> if (status > 399 && status < 500) { throw!!!!! }
[15:54] <rick_h_> if status doens't start with 20 throw
[15:54] <rick_h_> heh
[15:55] <hatch> their events are so weird
[15:55] <hatch> the 'load' event handles everything besides 'progress'
[15:58] <gary_poster> jujugui call in 2
[16:05] <mhall119> hi everyone, I need help from somebody who's dealt with webops, I have a django charm that keeps running into problems when I deploy updates
[16:12] <rick_h_> mhall119: howdy, we're on a team call atm, but happy to see if we can help
[16:15] <mhall119> thanks rick_h_ 
[16:18] <hatch> frankban I used `go get` to pull down trunk so I have no idea what revno. Does bzr store the revno in the .bzr folder somewhere?
[16:18] <frankban> hatch: run "bzr revno" in the branch
[16:19] <hatch> *facepalm* 2247
[16:19] <frankban> cool, mine is 2253
[16:20] <hatch> you were saying that you were having issues with it?
[16:20] <frankban> hatch: yes
[16:21] <hatch> hmm, it's working for me, do you have the charm pushed up somewhere?
[16:21] <hatch> I can test it here
[16:21] <hatch> if you like
[16:21] <frankban> hatch: I was having issues to deploy the charm: http://pastebin.ubuntu.com/6808945/
[16:21] <frankban> hatch: I'll try reverting to your revno
[16:22] <hatch> permission denied...that's odd,
[16:22] <hatch> ohh they are working on removing sudo
[16:22] <hatch> maybe it's broken
[16:52] <marcoceppi> rick_h_: buildlog for charmworldlib on trusty https://launchpadlibrarian.net/163611830/buildlog_ubuntu-trusty-i386.charmworldlib_0.2.2-0ubuntu2~ubuntu14.04.1~ppa1_FAILEDTOBUILD.txt.gz
[16:53] <marcoceppi> seems to build fine on all the other series
[16:53] <rick_h_> marcoceppi: k, will look in a bit
[17:01] <hatch> frankban were you able to get the charm to deploy? (not sure if you were doing it on the call or not)
[17:02] <frankban> hatch: yes, it seems to work well now
[17:03] <frankban> hatch: the path will be /juju-core/charms/?series=xxx . the idea is to expose a /juju-charm/ namespace which proxies all requests (GET, POST) to and from core
[17:04] <rick_h_> gary_poster: going into delete the trunk series gives me a lot of scary looking warnings. In particular The associated branch will be unlinked: lp:juju-gui
[17:04] <gary_poster> rick_h_: uh. :-)
[17:04] <rick_h_> gary_poster: can you +1 that it's just scary and press the button?
[17:04] <gary_poster> heh ok, will go look
[17:04] <rick_h_> gary_poster: thanks
[17:06] <rick_h_> marcoceppi: do the builders not have external network access then? It can't download setuptools?
[17:06] <rick_h_> marcoceppi: do you have a successful log for me to compare against? 
[17:06] <marcoceppi> rick_h_: why would it fail for trusty and not others
[17:06] <hatch> frankban yeah that's what I was thinking too, so do you mean that it will expose a /juju-core/ namespace?
[17:07] <hatch> rick_h_ downside to deleting it is that we loose all that history and what-not
[17:07] <hatch> do we need to delete it? :)
[17:07] <rick_h_> marcoceppi: yea that's why I want to compare
[17:07] <hatch> maybe if it's scary we just leave it hah
[17:07] <rick_h_> hatch: yea, I'm wondering as well. I guess it's just confusing for others
[17:07] <rick_h_> but we know enough
[17:07] <rick_h_> so meh
[17:08] <rick_h_> marcoceppi: I want to see if the others downloaded setuptools or if it was something already available to that build.
[17:08] <marcoceppi> rick_h_: https://launchpadlibrarian.net/163199754/buildlog_ubuntu-saucy-i386.charmworldlib_0.2.2-0ubuntu2~ubuntu13.10.1~ppa1_UPLOADING.txt.gz looks like it's not trying to download. Maybe what comes in trusty py3 vs saucy differs and doesn't include 
[17:08] <frankban> hatch: basically https://{guiaddress}/juju-core/* --> https://{api-address}:17070/*
[17:08] <hatch> frankban right ok cool that's exactly what I was thinking
[17:09] <gary_poster> rick_h_: six deletion attempts, six timeout errors.  how about I rename "trunk" series to "experimental"?
[17:09] <rick_h_> gary_poster: works for me
[17:10] <marcoceppi> rick_h_: I see python3-setuptools in saucy but not in trusty
[17:10]  * marcoceppi looks at pkg
[17:11] <gary_poster> rick_h_: https://launchpad.net/juju-gui/experimental , marked obsolete
[17:11] <rick_h_> gary_poster: hah, I went to hit submit and got "lost something?"
[17:11] <rick_h_> gary_poster: thanks
[17:11] <gary_poster> welcome, sorry for confusion
[17:12] <rick_h_> marcoceppi: hmm, it exists. http://packages.ubuntu.com/trusty/python3-setuptools
[17:12] <marcoceppi> rick_h_: I don't think python3-all pulls it down
[17:12] <rick_h_> marcoceppi: all ok
[17:12] <marcoceppi> I dont' explicitly require python3-setuptools
[17:12]  * marcoceppi fixes
[17:13] <rick_h_> marcoceppi: so that looks like the failure though. It tries to download it and can't from the builder
[17:14] <marcoceppi> ta
[17:18] <rick_h_> jujugui really cool article with some handy 'say you want to do xx' git commands/notes. http://pypix.com/tools-and-tips/pro-git-workflow/
[17:18] <hatch> it's missing the "say you want to smash it to itty bitty pieces"
[17:19] <rick_h_> I like the standup one
[17:19] <rick_h_> "wtf did I do? Hmm, git standup"
[17:22] <frankban> hatch: localCharmHelpers is undefined in services.js
[17:23] <hatch> frankban run in devel/debug mode
[17:23] <hatch> that branch doesn't have it included in prod (sorry)
[17:23] <frankban> hatch: ok
[17:31] <rick_h_> hatch: here you go
[17:31] <rick_h_> * wind chill values will fall to between 15 and 25 degrees 
[17:31] <rick_h_>    below zero this morning. The wind chill readings will remain 
[17:31] <rick_h_>    around 15 degrees below zero during the afternoon. 
[17:31] <rick_h_> * Southwest winds will increase to 20 to 30 mph this 
[17:31] <rick_h_>    afternoon... gusting at times to 35 to 40 mph. 
[17:32] <rick_h_> there's our wind chill warning that I just got
[17:32] <hatch> that's quite the warning
[17:32] <hatch> ours is Temperature -10C, Windchill -30C
[17:32] <hatch> you get a lot more information haha
[17:34] <mhall119> rick_h_: do you have time now to help?
[17:35] <mhall119> https://launchpad.net/ubuntu-api-website is the project, you'll see one branch for the app itself and another for the charm
[17:35] <mhall119> the charm works fine in LXC, but in stagingstack it keeps getting db credentials for a user that can't read or write anything to the db
[17:36] <mhall119> even after webops manually adds permissions/roles, on the next deployment they're erased again
[17:36] <rick_h_> mhall119: what db is it talking to? 
[17:37] <mhall119> I just added the grant_perms.py script that is called before doing any DB managment by the charm, but even that can't connect to the DB and set the permissions for the role
[17:37] <mhall119> rick_h_: postgresql
[17:37] <mhall119> using pg_bouncer in prodstack, but not stagingstack (unless they've added it now
[17:37] <mhall119> )
[17:37] <rick_h_> so the db hook is sending bad data to the charm? Does the user/pass it sends exist?
[17:38] <mhall119> yes, and it can *connect*, it just has no permissions to do anything
[17:39] <rick_h_> mhall119: hmm, I've not used the postgres charm so not sure how it creates the users and such. I'd ping someone that's hacked on that. Or find another charm that uses it and compare the db hooks between your app and their to see if it requests/passes anything extra?
[17:40] <mhall119> rick_h_: I've forked the certification website charm to make mine, it uses the same db hooks
[17:40] <rick_h_> mhall119: maybe ping stub and see if he's run into it before. I know he's worked on the pgsql charm some
[17:41] <mhall119> already did, he suggested I add the grant_perms.py from certification charm but that fails because of lack of permissions too
[17:42] <rick_h_> huh, yea it seems to me you'd have to get a user account that can do something
[17:43] <mhall119> stub says postgres sets up a role for the user, and it's my charm's job to grant perms to the role (which is what grant_perms.py does), but the user it's given doesn't have permission to grant permissions to the role that was created
[17:43] <rick_h_> mhall119: heh, chicken meet egg
[17:44] <rick_h_> mhall119: looked at using the db-admin relation to get a user with super access to create the user for you?
[17:45] <rick_h_> mhall119: looking at https://jujucharms.com/precise/postgresql-59/#bws-readme there's notes about using db-admin to get a superuser and that user should then have access to grant/do things to create an app user to the database created for use?
[17:47] <rick_h_> mhall119: given nothing there says why it works locally but not in the stagestack
[17:52] <mhall119> huh, I didn't know there was a separate user account created by postgresql
[17:53] <mhall119> oh wait, does it depend on the relation type added?
[17:55] <mhall119> so, rick_h_, they have 2 instances of my site, one has an added ADMIN_MODE flag set that tells it to run syncdb and migrate and some other db-management stuff, should that node have been given the postgresql:db-admin relation instead of postgresql:db relation?
[17:56] <rick_h_> mhall119: looking at https://github.com/charms/postgresql/blob/master/hooks/hooks.py#L1110 the roles is pulled from the relation_get('roles'). What does the db-relation-joined hook symlink to? I cant' tell from http://bazaar.launchpad.net/~api-website-devs/ubuntu-api-website/api-website-canonical-is-charm/files/head:/hooks/
[17:57] <marcoceppi> rick_h_: it was a dep issue, latest build shows it as resolved
[17:57] <marcoceppi> re charmworldlib
[17:57] <mhall119> rick_h_: it symlinks to db-relation-changed
[17:57] <rick_h_> mhall119: no idea as to your question about ADMIN_NODE stuff. I'm just looking at the pgsql charm for the first time myself tbh.
[17:58] <rick_h_> marcoceppi: yay
[17:58] <rick_h_> mhall119: hmm, is something setting relation-set roles=$DB_ROLE
[17:58] <rick_h_> ?
[17:58] <mhall119> rick_h_: admin_mode is on my charm, it just tells it whether or not to run manage.py commands against the DB when the charm runs
[17:58] <mhall119> rick_h_: yes, db-relation-changed is setting that now
[17:58] <rick_h_> mhall119: ok, so that seems a different issue
[17:59] <rick_h_> mhall119: is that in a fork or something then?
[17:59] <rick_h_> are they running the right source that sets it?
[17:59] <mhall119> they have the right source as far as I can tell
[18:00] <mhall119> I'm thinking now that the admin_mode instance might also be using the regular postgresql:db relation, instead of :db-admin
[18:00] <rick_h_> well I think a script that assigns roles would need to be a db-admin user in order to run
[18:00] <mhall119> I've asked for a 'juju status' pastebin in #webops to know
[18:00] <rick_h_> mhall119: about it not working as is, it seems that the role passed in relation-set needs to be good/valid and I'd question that based on reading https://github.com/charms/postgresql/blob/master/hooks/hooks.py#L1126
[18:01] <mhall119> what do you mean by good/valid?
[18:01] <rick_h_> mhall119: all I got though :/
[18:03] <rick_h_> well what is pgsql expecting to get as a 'role' in there. That roles gets passed to grant_roles function. So that it must be the right name/value for the db to have access to? 
[19:05] <hatch> nanananana writing-test-man writing-test-man
[19:05] <rick_h_> hah
[19:20] <bac> anyone here ever install nagios?
[19:20] <rick_h_> bac: long time ago we used it at my last job
[19:20] <bac> rick_h_: where is it on the simple-to-horror scale to get up and running?
[19:21] <rick_h_> bac: from packages, it's simple to get started. It's horror to manage and use since the UI is awful and so much is scripts/plugin stuff
[19:39] <hatch> holy smokes that's a lot of loc for some tests
[19:41] <hatch> 390line diff....yuss I only need one reviewer
[19:41] <hatch> lol
[19:43] <rick_h_> hatch: lol
[19:51] <hatch> hey rick_h_  I appear to have messed something up with my rebase -f in my branch
[19:51] <hatch> https://github.com/hatched/juju-gui/compare/juju:develop...hatched:local-zip-upload?expand=1
[19:51] <hatch> it's picked up a previous commit and applying it in this diff
[19:52] <hatch> any idea how I fix that?
[19:52] <hatch> create a new branch and apply the hash from the proper one maybe?
[19:53] <rick_h_> hatch: sec looking
[19:54] <rick_h_> hatch: so the commit is from your branch?
[19:54] <hatch> no it's already been merged into develop
[19:54] <rick_h_> hatch: if it's just in your branch you can always rebase -i HEAD~~~ to tweak it more
[19:54] <rick_h_> oh
[19:54] <hatch> somehow it was pulled 'up' or whatever
[19:54] <rick_h_> sec, I want to figure this out then
[19:55] <rick_h_> there's supposed to be a way to remove every commit in your branch, update from origin, and then re-layer your commits down again
[19:55] <rick_h_> and I think that's the way to work with these
[19:55] <rick_h_> hatch: but yea, I'd just update develop, new branch, cherry-pick your commit you want, and repush
[19:55] <rick_h_> as far as speed goes
[19:57] <rick_h_> hatch: try this please
[19:57] <rick_h_> git checkout develop
[19:57] <rick_h_> git juju-sync
[19:57] <rick_h_> git checkout local-zip-upload
[19:57] <hatch> I don't have juju-sync, I'm just resolving the conflicts in the cherry-pick right now
[19:57] <rick_h_> git rebase develop
[19:57] <rick_h_> bah
[19:58] <rick_h_> well, fine. just git pull juju (or whatever you call it) develop
[19:58] <rick_h_> and the key is to run in your branch `git rebase develop`
[19:58] <rick_h_> and see what it does with that
[19:58] <rick_h_> https://www.atlassian.com/git/tutorial/remote-repositories#!pull
[19:58] <rick_h_> as well
[19:59] <rick_h_> git pull --rebase develop maybe?
[20:01] <hatch> bah, no matter what it keeps pulling in that new one
[20:01] <hatch> even with a cherry pick of the specific hash
[20:01] <hatch> hmm
[20:02] <rick_h_> you broke it
[20:02] <hatch> damn rebase
[20:03] <rick_h_> lol
[20:03] <hatch> oh I think I know how I broke it
[20:03] <rick_h_> stop doing that then
[20:03] <hatch> rebase re-stacks commits
[20:03] <rick_h_> right
[20:03] <rick_h_> that's the point
[20:03] <hatch> so when I 'picked' one even though it was older
[20:03] <rick_h_> you can move commit saround with an interactive rebase
[20:03] <hatch> it re-applied it
[20:03] <hatch> instead of leaving it
[20:03] <rick_h_> huh? pick just means to keep it
[20:03] <rick_h_> it shouldn't reapply it
[20:04] <hatch> maybe it does
[20:04] <hatch> I don't see how else it could have shown up
[20:05] <rick_h_> no, because you can remove the commit and it should go away
[20:05] <rick_h_> do you have it in there twice? is that commit in your git log twice?
[20:05] <rick_h_> with two diff hashes?
[20:05] <hatch> I think I've got it
[20:05] <hatch> pushing
[20:05] <hatch> victory
[20:07] <rick_h_> did you create a new branch from that existing one?
[20:07] <rick_h_> instead of from develop?
[20:07] <hatch> jujugui lf a review https://github.com/juju/juju-gui/pull/86 no qa needed
[20:07] <rick_h_> looking
[20:07] <hatch> rick_h_ I updated develop so it's most recent branch wasn't the 'extra' one and then the cherry pick worked without conflicts
[20:07] <gary_poster> on it hatch
[20:08] <gary_poster> oh rick_h_has it
[20:08] <hatch> I think it's about time for lunch
[20:08] <rick_h_> hatch: yea, it looks like you created the branch from the other feature branch and then did a pull request that contained both changes
[20:13] <hatch> now to do some Python
[20:13] <hatch> bring on the semicolons!
[20:13] <hatch> er.... :P
[20:15] <gary_poster> semicolons? :-P
[20:37] <bac> rick_h_: the tickle to run config-changed on mjc stomped all over the cowboyed changes.  that's actually good.  but it wrote out bad data, so my theory seems to be right.
[20:37] <bac> working with deej to see exactly what they do and how to make it work
[20:37] <rick_h_> bac: the theory that they're not running the scripts and cowboying things?
[20:38] <bac> rick_h_: no, that their modified local copy of the charm is not merging in changes we make to the actual charm
[20:38] <rick_h_> oh ok
[21:03] <hatch> my cable box goes to channel 41 when I type in 0330
[21:52] <bac> rick_h_:  sorry i missed deej's last statement.  all good and reconvene on monday?
[21:55] <rick_h_> bac: sorry, was afk /me looks at history
[21:55] <rick_h_> 21:44       deej| That's all fixed
[21:55] <rick_h_> 21:44       deej| The charm's getting updated
[21:55] <rick_h_> 21:44       deej| It's not getting its new template files though