| hatch | Makyo I found the culprit | 04:08 |
|---|---|---|
| Makyo | hatch, oh yeah? | 04:09 |
| hatch | yep it's the tokens | 04:09 |
| hatch | the delay was so odd because it was locking up the UI layer | 04:09 |
| Makyo | What was causing the problem within the tokens? | 04:09 |
| hatch | I haven't quite narrowed it down but the Widget/WidgetParent/WidgetChild stuff seems to be draining a ton of cycles | 04:10 |
| hatch | these will probably need to be converted to views | 04:10 |
| hatch | it takes up to 300ms per token to render | 04:12 |
| hatch | instantiation is fast though so it might not be related to the widget bits | 04:13 |
| hatch | still need to do more digging there | 04:13 |
| Makyo | Yikes, yeah. I was wondering where those cycles were disappearing, since it didn't seem to be any of the blobs I'd debugged. Lets sync up tomorrow morning after the call or something to try and nail this down further. | 04:13 |
| hatch | 1.21s PER frame when it's doing that lol | 04:15 |
| hatch | high perf man | 04:15 |
| hatch | haha | 04:15 |
| hatch | yeah definitely, we now have a starting point | 04:16 |
| Makyo | Yep! | 04:18 |
| Makyo | I'm crashing, though, damn meds. Catch up tomorrow morning? | 04:18 |
| hatch | fo sho! | 04:23 |
| hatch | I'm also done for the night | 04:24 |
| rogpeppe | hmm, i'm getting this from the canonical irc servers: | 07:53 |
| rogpeppe | The certificate authority's certificate is invalid | 07:53 |
| rogpeppe | The root certificate authority's certificate is not trusted for this purpose | 07:53 |
| rogpeppe | The certificate cannot be verified for internal reasons | 07:53 |
| rogpeppe | anyone else seeing the same thing? | 07:54 |
| huwshimi | rogpeppe: I'm seeing the same thing, but I've asked a couple of other people and they seem to connecting be ok. | 07:56 |
| rogpeppe | huwshimi: ok. so it's not just me. the bad guys are selectively targeting us :-) | 07:56 |
| huwshimi | :) | 07:56 |
| rogpeppe | huwshimi: so did you just continue to connect anyway? | 07:56 |
| huwshimi | rogpeppe: I can't connect at all. | 07:57 |
| rogpeppe | huwshimi: hmm, i have a "Continue" option, but I don't want to use it, as it potentially gives a middle man total access to canonical IRC | 07:57 |
| huwshimi | rogpeppe: I've just done without today. | 07:58 |
| rogpeppe | huwshimi: the odd thing is this line "The root certificate authority's certificate is not trusted for this purpose" | 07:59 |
| rogpeppe | huwshimi: i wonder what purpose it's trying to verify against | 08:00 |
| rogpeppe | huwshimi: what IRC client do you use? | 08:00 |
| huwshimi | rogpeppe: xchat-gnome | 08:00 |
| rogpeppe | huwshimi: hmm, bang goes that theory :-) | 08:00 |
| huwshimi | rogpeppe: Which tells me the certificate may have expired. | 08:01 |
| rogpeppe | huwshimi: the cert is valid until 2015 | 08:01 |
| huwshimi | rogpeppe: Oh :) | 08:01 |
| * rogpeppe wishes that certificates were more humanly readable, rather than entirely obscure ASN.1 | 08:02 | |
| huwshimi | Well, I'm done for the day, hopefully they resolve it tonight! | 08:05 |
| huwshimi | rogpeppe: Have a good day :) | 08:05 |
| rogpeppe | huwshimi: see ya :-) | 08:05 |
| frankban | rogpeppe: morning, git migration completed! could you please move the card you are working on in the code lane? oh, also, the card from yesterday (http.go) should be moved to daily accomp. thanks. FWIW, I used this quick and dirty script to check packages' deps: http://pastebin.ubuntu.com/7586126/ | 09:07 |
| rogpeppe | frankban: just FYI, you could do {{join .$2 "\n"}} rather than the range loop (well, modulo some quoting issues :-]) | 09:10 |
| rogpeppe | frankban: nice script BTW | 09:11 |
| frankban | rogpeppe: thanks, it seems I have to work on a JS branch this morning, hope to be able to switch back to our migration plan asap this afternoon. | 09:13 |
| rogpeppe | frankban: ok | 09:13 |
| hazmat | woot, bzr installable via pip | 12:33 |
| hazmat | iotl == internet of things light ;-) | 12:40 |
| redir | morning | 13:08 |
| kadams54 | morning | 13:09 |
| rogpeppe | frankban: your script didn't quite do what i was after (i wanted it a little more scriptable), so i took 30 minutes to write a slightly different version. http://paste.ubuntu.com/7587381/ | 13:10 |
| frankban | rogpeppe: nice! bash also looks better in your version ;-) | 13:11 |
| bac | hi frankban. did you see my change to quickstart re: tls? | 13:12 |
| frankban | bac: yeah, that's awesome, good to see the solution was that simple. thank you! | 13:13 |
| bac | frankban: i wish it were so simple for jujuclient... it uses websocket.create_connection, which has no sslopt. | 13:14 |
| bac | not sure how much surgery would be required to replace with WebSocket object use | 13:14 |
| bac | s/WebSocket/WebSocketConnection/ | 13:14 |
| frankban | bac: it should be similar to what we do in quickstart (and originally we did that for other reasons, logging stuff IIRC). perhaps we can contribute upstream by adding the sslopt to create_connection | 13:16 |
| bac | frankban: that's a thought... | 13:16 |
| jcsackett | morning (or afternoon) all. | 13:17 |
| frankban | bac: actually it seems you can already pass sslopt to create_connection: https://github.com/liris/websocket-client/blob/v0.12.0/websocket.py#L198 | 13:21 |
| bac | frankban: silly me, i believed the docstring | 13:23 |
| bac | options: current support option is only "header". | 13:23 |
| bac | if you set header as dict value, the custom HTTP headers are added. | 13:23 |
| bac | and didn't think the sslopt was part of the headers | 13:24 |
| frankban | bac: yeah that docstring was never updated :-/ and no longer reflects reality: it seems it used to in a very old version: https://github.com/liris/websocket-client/blob/v0.9.0/websocket.py#L172 | 13:28 |
| frankban | bac: so it actually seems your solution can also fix jujuclient \o/ | 13:29 |
| bac | frankban: so it should be quite easy to update jujuclient. i'll update the bug and make a slack card. it is no longer directly affecting us, afaict. | 13:30 |
| frankban | bac: no, since we use a customized way to establish the ws connection it doesn't affect us now | 13:31 |
| frankban | bac: so +1 | 13:31 |
| hatch | bac can you kick comingsoon? It's not updating the css again | 13:53 |
| bac | hatch: i will. should i not be around recall that you can too. | 13:54 |
| hatch | oh? | 13:54 |
| hatch | are instructions in the wiki? | 13:54 |
| bac | hatch: instructions? | 13:55 |
| bac | hatch: try it now. is it still messed up? | 13:55 |
| hatch | yeah - like how to log into the server and whatnot | 13:56 |
| bac | it's the whatnot that always bites you | 13:56 |
| hatch | bac yesh it's still broken | 13:56 |
| bac | urhg. | 13:56 |
| bac | hatch: ok, doing a make clean build-prod now | 13:57 |
| hatch | thanks | 13:57 |
| hatch | any idea why it does this? | 13:57 |
| bac | hatch: now? | 13:57 |
| hatch | bac yep fixed, thanks | 13:58 |
| hatch | luca comingsoon is ready | 13:58 |
| bac | hatch: we're missing some dependency in the css generation part of the makefile | 13:59 |
| bac | hatch: i'll make a card | 13:59 |
| luca | hatch: thanks | 13:59 |
| hatch | bac great thanks | 13:59 |
| hatch | luca there are a couple known bugs - no databdinging on unit details breakout, and slow rendering when switching between views in the sidebar, anything else that you find that should block release lemme know! | 14:00 |
| hatch | databinding | 14:01 |
| luca | hatch: thanks | 14:03 |
| luca | hatch: I’ll check it out | 14:03 |
| * rogpeppe goes to grab some lunch | 14:04 | |
| frankban | guihelp: I need two reviews and QA for https://github.com/juju/juju-gui/pull/363 . Anyone available? thanks! | 14:05 |
| hatch | on it | 14:05 |
| kadams54 | frankban: I can take a look. | 14:05 |
| hatch | thanks for picking this up frankban! | 14:05 |
| frankban | thank you both! | 14:05 |
| bac | hatch: hey, it was already there. including the whatnot: https://wiki.canonical.com/CDO/Juju/GUI/CI?highlight=%28comingsoon%29 | 14:05 |
| hatch | oh look I have access | 14:06 |
| hatch | lol | 14:06 |
| bac | hatch: give it a run sometime and let me know if that doc is incomplete | 14:06 |
| hatch | sure I'll try and get to it today | 14:06 |
| frankban | rogpeppe: are you migrating utils? | 14:11 |
| rick_h_ | Makyo: around? | 14:14 |
| rogpeppe | frankban: yup | 14:17 |
| rogpeppe | just trying to figure out how filter-branch works | 14:18 |
| redir | rogpeppe: what are you trying to do? | 14:19 |
| rogpeppe | redir: factor utils out of juju-core | 14:19 |
| redir | what have you tried? | 14:19 |
| redir | or what are you trying | 14:19 |
| hatch | rick_h_ not sure if you saw the scrollback but last night I found the perf issue | 14:21 |
| rogpeppe | redir: this (suggested by frankban) seems to have worked: git filter-branch --subdirectory-filter utils -- --all | 14:23 |
| redir | rogpeppe: http://pastebin.ubuntu.com/7587828/ notes from my brief look at removing store | 14:23 |
| rogpeppe | redir: i just wanted to have some idea of what it was actually doing | 14:24 |
| hatch | frankban comments made - could you check them out and reply before I hop on QA'ing | 14:24 |
| frankban | rogpeppe: great! redir: yeah that's the same command, and we no longer need bzr-export since we start from a git repo | 14:25 |
| rogpeppe | hmm, apparently i no longer have permission to create repos in github.com/juju | 14:26 |
| redir | right so clone, promote, add remote, push | 14:26 |
| frankban | rogpeppe: could you please take notes while doing the migration, so that we can follow those when moving other parts (and eventually also merge those notes in juju docs)? Also, when you actually start, could you please send an email to juju-dev saying we are migrating a utils/*? | 14:27 |
| redir | oh, I missed something | 14:27 |
| redir | clone, promote, add remote, push promoted, whatnot in core, commit, push updated core | 14:29 |
| redir | the all important whatnot | 14:29 |
| frankban | redir, rogpeppe: I imagine it would be 1) create juju/utils in github, 2) fork in github 3) clone the fork 4) add juju/utils/ as remote upstrem 5) create a new local branch 6) migrate 7) push to origin 8) propose the branch | 14:29 |
| frankban | then remove the moved parts and fix imports in core | 14:30 |
| frankban | (and also update dependencies | 14:30 |
| luca | hatch: the charm details link in the IotL doesn’t work | 14:33 |
| redir | frankban: can you rewtrite history only in a local branch? won't that affect the whole repo? | 14:33 |
| hatch | luca what does IotL stand for? | 14:33 |
| hatch | I know it means Inspector Left but the letters are all garbled | 14:33 |
| hatch | lol | 14:33 |
| luca | hatch: Inspector on the Left | 14:34 |
| hatch | luca, confirmed - can you create a bug plz | 14:34 |
| luca | not…garbled… | 14:34 |
| hatch | ohhh :) | 14:34 |
| hatch | brb | 14:35 |
| frankban | hatch: replied on your comments | 14:35 |
| rogpeppe | so, a git weirdness - i thought git checkout updates all the files in the current working directory, but after doing the above filter-branch command (in a new branch), i did "git checkout master" to revert to the original juju master, and no files changed | 14:38 |
| frankban | redir: not sure if I understood your question: we need to split the juju/juju history, then create a juju/utils branch with the history obtained by splitting out utils. At that point we just propose a local juju/utils branch (with the history) to be merged into the newly created (and empty) upstream, right? | 14:38 |
| rogpeppe | i then tried removing all the files other than .git, and it is still not checking out the files | 14:39 |
| frankban | rogpeppe: git reset --hard? | 14:39 |
| * frankban bbiab | 14:39 | |
| redir | rogpeppe: that may only have an effect on the INDEX so you may need to reset --hard to make the directory reflect the changes to the index | 14:40 |
| redir | like frankban said | 14:40 |
| rogpeppe | pwd | 14:41 |
| redir | rogpeppe: /irc | 14:41 |
| rogpeppe | hmm, git reset --hard did bring some files back (why didn't checkout do that?) but it brought back the files from the new branch, not master | 14:41 |
| * rogpeppe doesn't understand the subtle difference between checkout and reset | 14:42 | |
| hatch | frankban thanks | 14:42 |
| rogpeppe | redir: i don't know about INDEX | 14:43 |
| rogpeppe | redir: is that a manifest of files on disk? | 14:43 |
| redir | frankban: I think we are saying the same thing. I was interpreting your steps as all in the same repo with different local branches and remotes for different upstream repos, which I don't think would work. However, reading your clarification I understand you are working in two repos | 14:43 |
| hatch | frankban I was under the impression that the ghost service callback converted the ghost service into a real service | 14:44 |
| redir | rogpeppe: something like that, I don't really get into git that deeply usually as I don't need to | 14:44 |
| rogpeppe | redir: i was just trying to understand the git-reset help page, which mentioned the "index" all over the place | 14:45 |
| redir | rogpeppe: index is like the staging area | 14:45 |
| redir | so you make changes in the directory | 14:45 |
| rogpeppe | redir: ah, that's where "git add" puts stuff to i guess | 14:46 |
| redir | then you git 'add' it and that tells the index to stage the change | 14:46 |
| redir | so a lot of the filter-branch and fast-import and other bits actuall just update the index | 14:47 |
| redir | letting you commit later | 14:47 |
| redir | also impying that your directory isn't up to date when only the index is altered | 14:47 |
| redir | or something like that | 14:47 |
| rogpeppe | redir: i don't think that can be the case with filter-branch, because it's rewriting all of history | 14:48 |
| rogpeppe | redir: so it surely must update HEAD and everything it points to? | 14:48 |
| redir | rogpeppe: idk, because I haven't had to use filterbranch much -- mostly only to remove sensitive info from repos:) | 14:49 |
| redir | and usually I am in a panic at that point, so not much sticks other than get it out get it out | 14:49 |
| Makyo | jujugui call in 10 | 14:50 |
| redir | but I think head is just like a sticky note pointing at the place you are working (most recent commit) | 14:50 |
| redir | rogpeppe: ^^ | 14:50 |
| redir | so adding a commit just moves the sticky note to point at then newly added commit (new head) | 14:51 |
| rogpeppe | redir: yeah, but if i do "git checkout master", it should bring me back to where i was | 14:51 |
| redir | rogpeppe: if you rewrote history it would bring you back to where you were rewritten to | 14:52 |
| redir | or somehtign | 14:52 |
| redir | rogpeppe: I try hard not to peek under the git porcelin | 14:52 |
| rogpeppe | hmm | 14:54 |
| rogpeppe | the odd thing is, i haven't done a single commit | 14:54 |
| rogpeppe | and everything seems to have changed on master and on my checked-out branch | 14:54 |
| rogpeppe | this is what my reflog looks like | 14:55 |
| rogpeppe | http://paste.ubuntu.com/7587997/ | 14:55 |
| redir | rogpeppe: I think you noted that if you fitler-branch --some-filter it rewrites history for you. If you want to pair for a minute, I can pretend to know more about git than I really do | 14:55 |
| rogpeppe | redir: let's do that after the standup | 14:56 |
| redir | ok | 14:56 |
| rogpeppe | redir: or actually, let's join the standup now and see how far we get :-) | 14:56 |
| rick_h_ | hatch: didn't see it. What was up? | 14:57 |
| rick_h_ | Makyo: reping | 14:57 |
| Makyo | rick_h_, oops, missed the earlier one, what's up? | 14:57 |
| rick_h_ | Makyo: got a sec for a call? | 14:57 |
| hatch | rick_h_ the perf issue is somewhere in the token widget parent/child rendering | 14:57 |
| Makyo | Sure | 14:57 |
| redir | brt, biobreak pre stanup | 14:58 |
| bac | jujugui: was my audio less awful today via the phone? | 15:11 |
| rogpeppe | redir: i fixed the issue by manually resetting to a revid i found in the reflog | 15:12 |
| rogpeppe | redir: but i have no idea how i ended up in the state i did | 15:12 |
| redir | rogpeppe: cool | 15:12 |
| redir | rogpeppe: that will prolly happen several more times:) | 15:13 |
| rogpeppe | redir: it looks like filter-branch changed two branches at once | 15:13 |
| redir | rogpeppe: I think it does | 15:13 |
| rogpeppe | redir: really?! | 15:13 |
| redir | rogpeppe: have you read this http://bit.ly/1i0DBcw | 15:14 |
| rogpeppe | redir: i've read something pretty similar in the past. nice summary. | 15:16 |
| redir | rogpeppe: right so if you rewrite a commit, that commit is used in several branches -- because it is all one graph -- then both branches h ave changed | 15:17 |
| rogpeppe | redir: i don't think that quite gets into why filter-branch changes two branches at once rather than just affecting the current branch | 15:17 |
| rogpeppe | redir: um, i was under the impression that commits weren't really rewritten, but just that a whole new history was fabricated and HEAD changed to point to that new history | 15:18 |
| redir | history rewritten equal new different commits in the graph and new trees under those commits | 15:19 |
| redir | rogpeppe: so why wouldn't it affect all branches? | 15:20 |
| redir | they aren't clones like in bzr | 15:20 |
| rogpeppe | redir: but doesn't each branch have an associated revid? | 15:20 |
| redir | I think revid is a bzr term | 15:20 |
| rogpeppe | redir: SHA-1 hash | 15:20 |
| rogpeppe | redir: whatever the term is | 15:20 |
| redir | ahh | 15:20 |
| redir | a sha1 hash its a commit | 15:21 |
| frankban | rogpeppe, redir: so the lesson here is that when we split packages we have to use an ad-hoc juju clone right? | 15:21 |
| redir | which points at a tree (dir structure) | 15:21 |
| redir | rogpeppe: ^^ | 15:21 |
| redir | frankban: yes I think so | 15:21 |
| frankban | thanks redir | 15:22 |
| rogpeppe | redir: what's the right git name for the SHA hash that you see | 15:23 |
| rogpeppe | ? | 15:23 |
| redir | rogpeppe: I think they are just ids for commit objects that you are dealing with | 15:24 |
| rogpeppe | redir: right | 15:25 |
| redir | so they are just commiits | 15:25 |
| rogpeppe | redir: so each branch points to a particular commit object, right? | 15:25 |
| redir | right but more than one branch can point at the same commit object | 15:25 |
| rogpeppe | redir: and if you operate on a branch, it updates the commit object pointed to by that branch, yes? | 15:25 |
| rogpeppe | redir: but the branch points to the commit object via its id, no? | 15:26 |
| redir | it should create a new commit object pointing at the associated tree and blob objects | 15:26 |
| rogpeppe | redir: rather than pointing to a mutable thing | 15:26 |
| redir | the id is a hash of the object and an header (commit msg, etc) | 15:26 |
| redir | each commit updates the graph and points the branch at the new commit | 15:27 |
| redir | fo rthat branch | 15:27 |
| redir | but if you change an existing commit it changes it for anything in the graph that uses that commit | 15:28 |
| redir | hopefully I am making some sense | 15:28 |
| rogpeppe | redir: the point i'm finding odd is "changing an existing commit" | 15:29 |
| rogpeppe | redir: that implies that branches have some kind of a symbolic reference to the commit rather than just storing a hash of it | 15:29 |
| redir | rogpeppe: rewriting history updates the graph, the blobs, trees, commits, and tags | 15:30 |
| hatch | frankban should I be able to drag and drop a token on a container with a service in it? | 15:30 |
| rogpeppe | redir: and if so, that turns everything i *thought* i knew about git on its head | 15:30 |
| rogpeppe | redir: but it doesn't *change* any of the existing blobs, does it? | 15:30 |
| rogpeppe | redir: it just adds new ones, no? | 15:30 |
| redir | rewriting history changes them | 15:30 |
| redir | depending on what is rewritten | 15:31 |
| rogpeppe | redir: i'm not sure how it's possible to change a blob, because everything is content-addressed | 15:31 |
| frankban | hatch: drag a token on a container? | 15:32 |
| redir | well if you want to remove a password from a file you rewite history | 15:32 |
| redir | which changes a file | 15:32 |
| hatch | frankban yeah so drag and deploy mysql to a machine, confirm, then drag another token to the bare metal on that machine | 15:32 |
| hatch | it throws an error notification now | 15:33 |
| redir | rogpeppe: and that blob then hash a different hash value | 15:33 |
| rogpeppe | redir: so if i do "git branch --list -v", i see the branches and the hashes of their commit objects | 15:33 |
| hatch | this may have always been broken but I'm pretty sure you can deploy to a container | 15:33 |
| hatch | with something else in it | 15:33 |
| rogpeppe | redir: are you saying that if i do a filter-branch on one branch, the hash of the commit object for another branch can change? | 15:33 |
| frankban | hatch: it does not work, and needs to be fixed | 15:34 |
| redir | rogpeppe: that is my understanding | 15:34 |
| hatch | frankban but that's out of scope of this branch right? | 15:34 |
| redir | because it is not it's own repo | 15:34 |
| frankban | hatch: is it a regression introduced by this branch? | 15:34 |
| redir | rogpeppe: should be easy enough to do an experiment:) | 15:35 |
| rogpeppe | redir: wow. so even though i've done "checkout -b" to try and isolate my changes, the original branch gets mutated anyway. | 15:35 |
| rogpeppe | redir: so if you use filter-branch, you'd *always* need to use the reflog to rewind that other branch | 15:35 |
| redir | rogpeppe: if you do it in one repo yes | 15:36 |
| hatch | frankban ahh I don't know - yours makes it error, whereas before it would just create a new machine haha | 15:36 |
| hatch | I'm going to say - out of scope for your branch :) | 15:36 |
| frankban | hatch: ok cool then :-) | 15:36 |
| redir | rogpeppe: if I am understanding everyting we are talking about correctly I think the answer is yes | 15:37 |
| hatch | +1'd | 15:37 |
| frankban | hatch: now that a pattern is established, it shouldn't be hard to fix all the variations | 15:37 |
| hatch | frankban yeah true true | 15:37 |
| hatch | who knew ECS would end up being so complex :) | 15:38 |
| * rick_h_ raises hand | 15:38 | |
| rick_h_ | :P | 15:38 |
| rogpeppe | redir: wow, you're right. | 15:38 |
| redir | rogpeppe: there's a first | 15:38 |
| rogpeppe | redir: that is so counter-intuitive | 15:38 |
| redir | quick record this moment! | 15:38 |
| rogpeppe | :-) | 15:38 |
| rogpeppe | so i guess a branch must be more than just a (SHA hash) pointer | 15:39 |
| redir | rogpeppe: when you do those kinds of perations it does tore a back up somewhere in .git but I don't know the details of the top of my head | 15:39 |
| redir | rogpeppe: just different from bzr | 15:40 |
| rogpeppe | redir: when i did the operation again, it said this: | 15:40 |
| rogpeppe | Cannot create a new backup. | 15:40 |
| rogpeppe | A previous backup already exists in refs/original/ | 15:40 |
| rogpeppe | Force overwriting the backup with -f | 15:40 |
| redir | yeah there | 15:40 |
| redir | I usually do rewrites in a whole seperate clone | 15:40 |
| redir | and keep a pristine copy in case something happens later | 15:41 |
| redir | and I need it | 15:41 |
| redir | at least for a reasonable period | 15:41 |
| rogpeppe | ah! i got it! | 15:41 |
| rogpeppe | i think | 15:41 |
| * rogpeppe checks | 15:41 | |
| frankban | rogpeppe: git supports both clones a-la bzr and branches. IIUC with checkout you just navigate the tree, and that's why they are so fast, and maybe that's also the reason why when you rewrite history you really rewrite history. it does not seem that weird to me. in our case, we need to use clones | 15:42 |
| redir | rogpeppe: branches with different histories in bzr don't make sense to me | 15:42 |
| redir | it is very rare that I need a seperate clone (bzr branch) | 15:43 |
| redir | rogpeppe: frankban nailed it there | 15:43 |
| redir | I htink | 15:43 |
| rogpeppe | redir: actually, i think i was right :-) | 15:43 |
| rogpeppe | redir: the culprit was the --all argument to the filter-branch command | 15:44 |
| redir | I thought I was wrong, turns out I was right | 15:44 |
| redir | ah all branches | 15:44 |
| rogpeppe | redir: which was specifically asking to rewrite history on *all branches* | 15:44 |
| frankban | redir: in bzr some of us works with lightweight checkouts which mimic named branches and allow us to always work in the same directory | 15:44 |
| rogpeppe | redir: if you just specify the current branch, it works just as i'd thought | 15:44 |
| rogpeppe | phew | 15:44 |
| redir | frankban: yes but it still creates real branches in real directories somewhere else | 15:45 |
| rogpeppe | frankban: FWIW when you rewrite history, you don't really rewrite history | 15:46 |
| frankban | redir: yes, that's true, well, real branches, you can init your repo with --no-tree so that no files are written on disk, but yes, they are not as lightweight as git ones | 15:46 |
| hatch | kadams54 I | 15:46 |
| hatch | bah | 15:46 |
| rogpeppe | frankban: you just rewrite the history of the current branch | 15:46 |
| hatch | kadams54 I'm thinking that the cards you created should probably go in On Deck or Pool until we put a priority on them | 15:46 |
| rogpeppe | frankban: or whatever branches you've specified | 15:46 |
| hatch | thoughts? | 15:46 |
| kadams54 | Sure | 15:46 |
| frankban | rogpeppe: cool even better then | 15:47 |
| redir | rogpeppe: I'd be wary of thinking that you are at the bottom of it:) | 15:47 |
| rogpeppe | redir: i am still very wary :-) | 15:47 |
| rogpeppe | redir: but at least experiment seems to support that point of view :-) | 15:48 |
| Makyo | jujugui tiny branch https://github.com/juju/juju-gui/pull/364 | 15:48 |
| frankban | rogpeppe: I'd be still inclined to use a disposable clone for this kind of work ;-) | 15:48 |
| redir | rogpeppe: I think you are right, but I can imagine scenarios where things end up different than you expect | 15:49 |
| hatch | Makyo on it | 15:49 |
| rogpeppe | frankban: BTW, what was the reason you gave the --all flag to filter-branch? | 15:49 |
| redir | also in the case of promoting a sub project I would want all branches to be done | 15:49 |
| * rogpeppe tries to understand " | 15:50 | |
| rogpeppe | Pretend as if all the refs in refs/ are listed on the command line | 15:50 |
| rogpeppe | as <commit>. | 15:50 |
| rogpeppe | " | 15:50 |
| * redir tries to understand quote | 15:50 | |
| rogpeppe | ah, got it! | 15:50 |
| frankban | rogpeppe: heh, I don't remember, maybe because I was converting from bzr and I had just a single branch in the target | 15:51 |
| rogpeppe | jeeze, they don't write for people that don't understand the internals, do they?" | 15:51 |
| rogpeppe | so the "refs/" there is referring to the .git/refs directory, where branch references are held (amongst other things) | 15:51 |
| redir | rogpeppe: perl people | 15:52 |
| hatch | Makyo +1'd | 15:53 |
| kadams54 | frankban: QA and review finished on your PR. Didn't have anything to add to what hatch had. | 15:53 |
| redir | rogpeppe: I was using all because I wanted to capture the tags and anything else that came over from bzr | 15:53 |
| frankban | kadams54: thanks | 15:54 |
| redir | maybe that isn't necessary for working solely within git but I think I'd still want tags and branches preserved in the new repo | 15:54 |
| redir | rogpeppe: ^^ | 15:54 |
| redir | bbiab | 15:55 |
| rogpeppe | redir: i can see why --all would be useful if you *really* wanted to rewrite history, rather (say) creating a new repo | 15:55 |
| redir | rogpeppe: TMTOWTDI | 16:05 |
| rogpeppe | redir: that is a severe understatement when talking about git :-) | 16:06 |
| rick_h_ | Makyo: lint issue, any reason it's faster to remove the cache than to tie the indicator into there? | 16:10 |
| Makyo | rick_h_, Yeah, fixed the lint issue. Re the cache - the entire UI thread is hanging, so the indicator would hang as well. | 16:10 |
| rick_h_ | but a hanging spinner > odd non readable ui | 16:11 |
| redir | rogpeppe: frankban http://pastebin.ubuntu.com/7588475/ are aliases I use a lot. Particularly tr and missing | 16:11 |
| rick_h_ | Makyo: ok cool, just curious | 16:11 |
| redir | rogpeppe: dunno if the colors work without bash and don't know about acme and shells... | 16:12 |
| rogpeppe | redir: colours are for colouring books :) | 16:12 |
| Makyo | rick_h_, The spinner was being put in there, but was hanging before it could even render. We're looking at ways to lighten the render load on charm tokens. | 16:13 |
| hatch | this is coming from the guy who doesn't even use syntax highlighting rogpeppe ;) | 16:13 |
| rick_h_ | Makyo: gotcha. | 16:13 |
| rogpeppe | hatch: you gottit :-) | 16:14 |
| hatch | haha | 16:14 |
| redir | rogpeppe: tell that to tufte | 16:14 |
| hatch | rick_h_ the solution may be to write them as Views or remove the Parent/Child bit (still too early to tell) | 16:15 |
| hatch | that'll be post release though | 16:15 |
| redir | rogpeppe: replace --pretty with --no-color | 16:17 |
| rick_h_ | frankban: http://ci.jujugui.org:8080/job/juju-gui-merge/376/ test failure. Odd one, not see it before. It's not one fo the usual temp errors | 16:18 |
| hatch | noooo more renderTo!!!! | 16:18 |
| redir | rogpeppe: nm that doesn't work you'd need to remore the colors from the foramtting | 16:18 |
| hatch | I thought I got rid of youuuuu | 16:18 |
| rick_h_ | hatch: ugh and ugh. The parent child has worked out so well and worked when we had a cache. | 16:18 |
| hatch | rick_h_ we are just too fast now :) | 16:18 |
| rogpeppe | redir: thought so | 16:18 |
| rick_h_ | hatch: will take a look in a bit | 16:18 |
| rick_h_ | hatch: then it's easy to slow things down in a smooth way :P | 16:18 |
| rick_h_ | hatch: or even just cache the rendereted html node tree and replace it on home. There's got to be a better way to move forward than rewrite all the code | 16:19 |
| frankban | rick_h_: weird this comes after two passes, without no changes other than rebasing | 16:20 |
| rick_h_ | frankban: yea, not sure. | 16:20 |
| hatch | it's too early to tell what the actual problem is - but it's definitely in the token rendering - it might be as simple as blowing away the old list and re-rendering, it spends a ton of time in rendering/gc | 16:20 |
| rick_h_ | hatch: huh? isn't that what it does now? | 16:21 |
| rick_h_ | I guess what is getting cached? It should just be the model list | 16:21 |
| hatch | the json is being cached | 16:21 |
| rick_h_ | the api json? | 16:21 |
| hatch | yeah | 16:21 |
| rick_h_ | then what's not 'blown away'? | 16:21 |
| hatch | the DOM when switching from search results to curated | 16:22 |
| rick_h_ | the old cache was the models generated. There was the _cache and _cache.interesting | 16:22 |
| hatch | right | 16:22 |
| hatch | Makyo and I decided that making the view caching aware was odd and that it should just be sent data and render it. We know that the model caching bit needs to be done, but the quickest way was to cache the response | 16:23 |
| rick_h_ | yea, not a fan of the api layer caching at all | 16:23 |
| rick_h_ | that's at the browser/web service layer | 16:23 |
| rick_h_ | the view isn't, it's the application (browser.js) | 16:24 |
| rick_h_ | or the state | 16:24 |
| rick_h_ | which is a fine place to cache data that is used across state renders/etc | 16:24 |
| hatch | right - the view shouldn't be concerned about the data - it should request it from the same place - that place should return the data, be it cached or not | 16:24 |
| rick_h_ | well, the view is updated with new data, and should destroy/redraw based on the new data. /me goes to look at what the view does | 16:25 |
| rick_h_ | Makyo: I'd vote to not comment that out but kill it | 16:25 |
| rick_h_ | we know it doesn't work well and isn't a good path forward | 16:25 |
| rick_h_ | it doesn't address the caching of individual charm models and doesn't fit the cards on the board for a new cache module that could be shared across views in the app | 16:26 |
| rick_h_ | it looks like a single purpose hack to speed up the home button click but fails to do that | 16:26 |
| hatch | that is a valid point - however a proper cache will take time to implement | 16:26 |
| hatch | it speeds it up dramatically if you remove the rendering issue | 16:27 |
| rick_h_ | sure, but we've commented out this anyway | 16:27 |
| rick_h_ | so what does leaving this in help us with? | 16:27 |
| hatch | like 300ms response time | 16:27 |
| hatch | once we solve the render issue we can re-implement this cache and not have to schedule the proper one right away if time doesn't permit | 16:27 |
| rick_h_ | but the only reason we're seeing a rendering issue is that teh cache isn't working correctly it seems to me? | 16:28 |
| rick_h_ | you've traded one chunk of work for two | 16:28 |
| hatch | no it's the rendering, if you comment out the rendering of the tokens it's very fast | 16:28 |
| rick_h_ | ok fine, but those same tokens rendered with a browser.js cache of ._cache and ._interesting didn't exhibit an issue that I recall | 16:29 |
| rick_h_ | you're still trading two problems for one | 16:29 |
| hatch | the rendering needs to be fixed regardless - we 'can' push caching off with the api cache 'hack' | 16:29 |
| rick_h_ | it seems to me the rendering iss, and some 400ms delay during a change of state is something that can be smoothed over much easier | 16:29 |
| hatch | the state change is instant, <10ms | 16:30 |
| rick_h_ | ok, I understand that, but there's no useful 10ms UI update for users | 16:30 |
| hatch | maybe we should have a hangout :) it'll be much easier to discuss haha | 16:30 |
| rick_h_ | sure thing :) | 16:30 |
| hatch | sec | 16:30 |
| hatch | https://plus.google.com/hangouts/_/canonical.com/daily-standup | 16:31 |
| rick_h_ | Makyo: ^ | 16:31 |
| frankban | rick_h_: another branch, similar failure: http://ci.jujugui.org:8080/job/juju-gui-merge/377/console | 16:34 |
| redir | rogpeppe: frankban you guys using precise or trusty? | 16:45 |
| rogpeppe | redir: i'm using trusty | 16:45 |
| frankban | redir: trusty | 16:45 |
| redir | for splitting out the juju-core bits? | 16:46 |
| redir | rogpeppe: frankban ? | 16:46 |
| frankban | redir: git version 1.9.1 here, on trusty | 16:47 |
| frankban | redir: git tr is very cool | 16:47 |
| redir | frankban: it is like a you are here directory for the repo:) | 16:48 |
| bac | hey frankban, i'm trying to create a brew recipe based on the lastest tgz we have released. | 16:53 |
| bac | frankban: but 1.3.2 has the problem with not specifying the 0.12 for websocket-client, thus it grabs the wrong one | 16:54 |
| bac | frankban: so, any chance of cutting a release soonish? | 16:54 |
| frankban | bac: looking | 16:55 |
| frankban | bac: we can release a 1.3.3 if required, after a proper QA with the new juju stable (1.18.4 IIRC). Why are we working on the brew formula now? I supposed that's the very final step for osx support. If that's not the case, I'll try to prepare a new release tomorrow | 17:00 |
| hatch | not going to lie.....every breakout panel shouldn't be working right now heh | 17:02 |
| hatch | that might mean this card won't be huge | 17:02 |
| hatch | :) | 17:02 |
| rogpeppe | redir: ok, another little git question... | 17:12 |
| hatch | uh oh | 17:12 |
| redir | rogpeppe: I'm ready to provide another wrong answer:) | 17:12 |
| hatch | lol | 17:13 |
| hatch | teamwork! | 17:13 |
| redir | partially wrong answer... | 17:13 |
| rogpeppe | redir: if i want to take a subdirectory out of an existing project (juju/juju), keep its history and the same directory, then merge it with another project, essentially merging two different branches with no shared root | 17:13 |
| rogpeppe | redir: is that possible? | 17:13 |
| redir | rogpeppe: yes | 17:13 |
| redir | wait | 17:14 |
| redir | me rereads | 17:14 |
| rogpeppe | redir: i want to take juju/juju/testing/filetesting and add it to juju/testing, with all its history intact | 17:14 |
| redir | so | 17:14 |
| rogpeppe | redir: i guess i could use filter-branch twice | 17:14 |
| redir | I think the answer is yes | 17:14 |
| rogpeppe | redir: once with --subdirectory-filter, then with --tree-filter moving the directory back to its original place | 17:15 |
| rogpeppe | redir: and then kinda hope that git merge works when the two branches share no common history | 17:15 |
| rogpeppe | hatch: does that sound like a feasible approach? | 17:16 |
| redir | rogpeppe: I know that you can have more than one commit with no parent | 17:16 |
| rogpeppe | redir: ok, that's good | 17:17 |
| hatch | rogpeppe no idea I've never needed to do that | 17:17 |
| hatch | sorry | 17:17 |
| redir | rogpeppe: which means that two projects merged and have separate starting points | 17:17 |
| redir | but I don't know what that means for keeping the full history of the branch being merged in | 17:17 |
| redir | rogpeppe: | 17:17 |
| redir | rogpeppe: I think I would add repo getting merged in as a remote for the one being added to | 17:19 |
| redir | then work out how I wanted them to be merged | 17:20 |
| redir | they don't share a time line so you might just cherry-pick commits | 17:21 |
| redir | or do a subtree merge | 17:21 |
| redir | rogpeppe: | 17:21 |
| rogpeppe | redir: ok, we'll see | 17:22 |
| redir | yeah so | 17:22 |
| redir | rogpeppe: something like | 17:23 |
| redir | rogpeppe: http://pastebin.ubuntu.com/7589025/ | 17:28 |
| * redir googles for magic incantation | 17:28 | |
| redir | rogpeppe: in the filter-branch man page | 17:37 |
| redir | http://pastebin.ubuntu.com/7589077/ | 17:37 |
| redir | rogpeppe: NB: I haven't done that before and it seems very magical | 17:38 |
| rogpeppe | redir: ah, update-index is not a command i've come across before | 17:39 |
| redir | rogpeppe: index-filter only updates the index not everything | 17:40 |
| redir | also see subtree merges | 17:40 |
| redir | I don't know if that will keep history how you want though | 17:40 |
| rogpeppe | redir: yeah, update-index seems to be magic that allows us to manipulate stuff without actually checking things out | 17:40 |
| redir | rogpeppe: http://bit.ly/1kCOYwh | 17:41 |
| rogpeppe | redir: what's a "tree-ish" | 17:42 |
| rogpeppe | ? | 17:42 |
| redir | rogpeppe: a branch I think | 17:43 |
| * rogpeppe thinks git would be quite a bit simpler without the index concept | 17:44 | |
| redir | rogpeppe: I don't think that keeps full history though | 17:44 |
| redir | rogpeppe: I haven't ever needed most of this stuff before this. | 17:45 |
| redir | filter-branch for removing things from history is about it | 17:45 |
| redir | rogpeppe: from the read-tree man page it looks to me like you won't get history just a merge, so I think if you want history you need filter-branch with magic | 17:47 |
| rogpeppe | redir: i think filter-branch with the update-index --index-info magic seems like it might do the trick | 17:48 |
| rogpeppe | redir: i'm guessing that it's expecting me to set $GIT_INDEX_FILE to my_repo/.git/index | 17:50 |
| redir | rogpeppe: note that I think that will change the hashes in history which is bad if other people have it checked out... | 17:50 |
| redir | rogpeppe: git might do that itself | 17:50 |
| rogpeppe | redir: i'm not quite sure what you mean there | 17:50 |
| redir | rogpeppe: I would guess it would | 17:50 |
| redir | when you run the git command it reads the repo it is in and sets env variables | 17:51 |
| redir | rogpeppe: maybe | 17:51 |
| redir | git env | 17:51 |
| rogpeppe | redir: ah, so that command will have the env var set | 17:52 |
| redir | rogpeppe: maybe | 17:52 |
| * redir is guessing | 17:52 | |
| * rogpeppe misses the inferno shell, which did commands-as-arguments with no quoting necessary | 17:52 | |
| redir | damn, where'd the day go | 18:07 |
| rogpeppe | redir: hey, it seems to have worked! | 18:28 |
| redir | angels sing, trumpets blare! | 18:29 |
| redir | world peace is at hand | 18:29 |
| rogpeppe | redir: my specific version of the update-index magic was this: http://paste.ubuntu.com/7589371/ | 18:30 |
| rogpeppe | i actually feel like i understood most of what was going on there | 18:30 |
| rogpeppe | except i still get confused around remote branches and fetch vs checkout vs reset | 18:31 |
| redir | hehe | 18:32 |
| redir | git fetch, uh, fetches named heads or branches, tags, and the associated trees, blobs, commits etc | 18:35 |
| redir | and puts them into .git/FETCH_HEAD | 18:35 |
| redir | git merge merges them into a local branch | 18:36 |
| redir | git pull does both | 18:36 |
| redir | fetch then merge | 18:36 |
| rogpeppe | redir: what's the significance of .git/FETCH_HEAD there? | 18:36 |
| redir | rogpeppe: it is non local copies of stuff | 18:36 |
| rogpeppe | redir: anyway, review appreciated: https://github.com/juju/testing/pull/11 | 18:37 |
| redir | or copies of non local stuff | 18:37 |
| rogpeppe | hmm, it's a pity that none of the resulting history includes the commit comments that are actually important | 18:40 |
| redir | checkout (and reset) update the files in the working tree to match the index or a specified tree (specified by a commit) | 18:40 |
| redir | git reset has --soft, --mixed and --hard | 18:40 |
| redir | I think --soft updates the index to match some specified tree | 18:41 |
| redir | and --hard updates the working directory and index | 18:41 |
| redir | rogpeppe: ^^ | 18:42 |
| rogpeppe | redir: i still haven't got my head around the difference between reset and checkout | 18:42 |
| rogpeppe | i'm done for the day | 18:42 |
| rogpeppe | gotta go and make chicken and wild mushroom and tarragon pie | 18:42 |
| redir | rogpeppe: that sounds tasty | 18:43 |
| redir | later | 18:43 |
| rogpeppe | redir: hopefully :-) | 18:43 |
| redir | don't git reset your oven | 18:43 |
| kadams54 | guihelp: looking for review and QA on https://github.com/juju/juju-gui/pull/365 | 18:58 |
| kadams54 | guihelp: Bueller?… Bueller?… anyone?… anyone?… --^ | 19:10 |
| kadams54 | ;-) | 19:10 |
| Makyo | kadams54, on it. | 19:10 |
| kadams54 | Thanks :-) | 19:10 |
| hatch | nice the footer is FINALLY being used | 19:10 |
| kadams54 | lol | 19:10 |
| hatch | I added it in in the beginning....thinking that it will probably be used at some point haha | 19:11 |
| kadams54 | Gotta run to pick up my kids from school, but will be back in about 30 minutes. | 19:11 |
| redir | rogpeppe: LGTM, all the tests pass with your PR merged, but I don't know the QA or merge process for it | 19:11 |
| bac | this is a nice touch i'd never noticed. when brew successfully installs something you get a little mug o' beer: | 20:28 |
| bac | 🍺 /usr/local/Cellar/juju-quickstart/1.3.3: 2 files, 40K, built in 2 second | 20:28 |
| rick_h_ | bac: :) | 20:29 |
| hatch | :) | 20:33 |
| hatch | rebooting | 22:13 |
| huwshimi | Morning | 23:17 |
| rick_h_ | morning huwshimi | 23:29 |
| huwshimi | rick_h_: Hey | 23:31 |
| rick_h_ | having fun huwshimi ? | 23:34 |
| huwshimi | rick_h_: Today, I'm writing tests... yes, lot's of fun! :) | 23:34 |
| hatch | huwshimi hey, frankban landed the branch to fix that bug | 23:40 |
| huwshimi | hatch: Yay! | 23:41 |
| hatch | huwshimi you can pretty much follow the same pattern for doing the container stuff if you end up going that far | 23:42 |
| hatch | here is the pr https://github.com/juju/juju-gui/pull/363 | 23:43 |
| huwshimi | hatch: I'm not sure what you mean about following the pattern for container stuff. This looks like it handles machines and containers. | 23:47 |
| hatch | huwshimi there is an issue with placing a unit on an existing container | 23:48 |
| hatch | I wasn't really sure where your cards were taking you | 23:48 |
| huwshimi | Ah I see | 23:48 |
| hatch | I got to run but hopefully that gets you un blocked | 23:51 |
| huwshimi | hatch: Thanks, looks like it. Thanks! | 23:52 |
| hatch | no probelm | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!