| SpamapS | marcoceppi: put your email address (the more precise, the better), but yes, otherwise good. | 00:02 |
|---|---|---|
| m_3 | aren't we ok with a copyright for the whole charm-tools project applying to the whole thing? | 00:04 |
| SpamapS | m_3: IMO no. Put a header on every file. Especially files full of code that people will be tempted to copy/paste into their charms. ;) | 00:05 |
| m_3 | gotcha, yeah if they're gonna be real snippets | 00:06 |
| SpamapS | m_3: the more explicit one is about their licensing, the less they have to deal with it later on. | 00:06 |
| m_3 | cool | 00:06 |
| SpamapS | ambiguity is the enemy of license due dilligence. ;) | 00:06 |
| marcoceppi | SpamapS: Thanks! pushed up | 00:09 |
| SpamapS | marcoceppi: looks good. :) | 00:12 |
| marcoceppi | awesome | 00:13 |
| SpamapS | marcoceppi: so, if you wanted to get your feet wet on packaging.. lp:~charmers/charm-tools/packaging | 00:13 |
| marcoceppi | SpamapS: <3 wet feet | 00:14 |
| SpamapS | marcoceppi: the idea would be to add a charm-helpers-sh to debian/control ... | 00:14 |
| SpamapS | (ignore everything outside of debian/ in that branch) | 00:14 |
| marcoceppi | I'll take a look and branch | 00:15 |
| SpamapS | marcoceppi: and then a charm-tools-sh.install file which puts the files in /usr/lib/charm-helpers/sh | 00:15 |
| SpamapS | actually | 00:16 |
| SpamapS | they should be in /usr/share/charm-helpers/sh | 00:16 |
| SpamapS | /usr/lib should only have binaries | 00:16 |
| marcoceppi | how do I get the file into the environment? | 00:16 |
| SpamapS | like, in your charm? | 00:17 |
| SpamapS | . /usr/share/charm-helpers/sh/net.sh | 00:18 |
| marcoceppi | Sure, for instance. | 00:18 |
| marcoceppi | Would I need to source it | 00:18 |
| marcoceppi | ah, k | 00:18 |
| SpamapS | simplest way | 00:18 |
| _mup_ | Bug #894362 was filed: orchestra launch failure can "lose" machines <juju:In Progress by fwereade> < https://launchpad.net/bugs/894362 > | 12:26 |
| === TeTeT_ is now known as TeTeT | ||
| rog | fwereade_: if you want a distraction for a bit: https://codereview.appspot.com/5433056/ | 14:20 |
| fwereade_ | cheers rog | 14:20 |
| rog | fwereade_: unfortunately the diffs include the diffs from the previous merge request which only changed the error type | 14:21 |
| fwereade_ | rog: don't worry about it :) | 14:21 |
| rog | fwereade_: it's an interesting thing though that i hadn't previously - merge requests are submitted against a moving target... | 14:22 |
| rog | s/ously/ously appreciated/ | 14:22 |
| fwereade_ | rog: yeah, I find that the regular merge-test-pushes become a bit tedious when I have more than two or 3 branches pending | 14:23 |
| rog | fwereade_: i can see why some people choose a more linear model | 14:24 |
| fwereade_ | rog, I feel like I've adapted quite well, and am content | 14:25 |
| fwereade_ | rog, it's only really something I notice when i have multiple branches out | 14:25 |
| rog | fwereade_: cool. i'm aiming for that state of mind :-) | 14:25 |
| fwereade_ | rog, otherwise when I'm working it's just a regular work-merge-work-merge-work-merge thing and it fades into the mental background | 14:25 |
| rog | fwereade_: that's easier when reviews are timely, i guess | 14:26 |
| fwereade_ | rog, well, maybe wok-merge-work-merge-work-merge-dammit,conflict-fiddle-fiddle | 14:26 |
| fwereade_ | rog, definitely | 14:27 |
| rog | anyone know of a way to change a repo's default push location without actually using push? | 14:45 |
| therve | rog, you can set something for your branch in the locations.conf? | 14:48 |
| rog | therve: do you mean branch.conf? | 14:49 |
| rog | therve: if that's the definitive source for the info, that's a good idea, thanks. | 14:50 |
| therve | I meant ~/.bazaar/locations.conf, but branch.conf sounds good too :) | 14:51 |
| rog | therve: hmm, except it's stored there in full URL form rather than short lp:... form. i wonder if it'll work anyway. | 14:52 |
| hazmat | rog, its worthwhile looking up the docs for location.conf, it has lots of options.. appendpath is the most useful, you can set for the parent directory and your subdirs (branches) all pickup the appropriate push path | 15:12 |
| rog | hazmat: i'll have a look, but it's only for a branch temporarily created by a script, so maybe not appropriate in this case. | 15:15 |
| hazmat | rog, its worth looking/setting up regardless of an individual branch | 15:15 |
| * hazmat wanders off to enjoy the holiday | 15:16 | |
| rog | hazmat: useful, yes, but in this case branch.conf is what i needed. | 15:34 |
| rog | fwereade_: next review in stack: https://codereview.appspot.com/5431067/ | 15:39 |
| fwereade_ | rog, cheers again | 15:39 |
| rog | oh bugger, it's got two prerequisites | 15:40 |
| fwereade_ | rog, sorry, I've been finding it a bit tricky to engage with reviewing today | 15:40 |
| rog | fwereade_: that's fine, it's just a FYI | 15:40 |
| fwereade_ | rog, ha, I find it very irritating that multiple prereqs aren't handled by lp | 15:40 |
| rog | fwereade_: i couldn't push without a nod from gustavo anyway | 15:40 |
| rog | fwereade_: aren't they? | 15:40 |
| fwereade_ | rog not that I'm aware of | 15:41 |
| fwereade_ | rog, if C depends on B depends on A, fine | 15:41 |
| fwereade_ | if C depends on both A and B I don't think that can be expressed | 15:41 |
| rog | ah, so i see. oh well, i won't have to start yet again then | 15:41 |
| rog | yeah, this review relies on two parallel changes to two different repositories | 15:41 |
| rog | s/review/merge request/ | 15:42 |
| rog | i'll just put it in the comments | 15:42 |
| fwereade_ | rog, I found making sure the branch with the bigger diff-from-trunk was the one marked as the prereq was helpful to people | 15:43 |
| rog | hmm, let me see | 15:43 |
| rog | the diffs come to 980 vs 1257 lines respectively. i've chosen the wrong one, but it's probably not too bad. | 15:45 |
| rog | is there some definitive documentation on cloudinit somewhere? this only seems to give some examples: https://help.ubuntu.com/community/CloudInit | 17:38 |
| george_e | jcastro: Please, oh please be here... | 20:07 |
| george_e | I ran into some problems polishing up my ThinkUp charm. | 20:08 |
| SpamapS | george_e: anything I can help with? | 22:18 |
| SpamapS | rog: the package puts some good stuff in /usr/share/doc/cloud-init.. I think | 22:18 |
| rog | SpamapS: i'd looked at that. nothing like definitive docs there. | 22:22 |
| george_e | SpamapS: Possibly - I am writing a charm for ThinkUp and I have a question about config. data. | 22:22 |
| rog | i ended up going through the source codee | 22:23 |
| SpamapS | george_e: fire away.. :) | 22:23 |
| george_e | If in config.yaml I do not specify a default value for a particular option, what is the value of that option when I look it up with 'config-get'? | 22:23 |
| SpamapS | rog: I think the best docs are just the example cloud config yaml | 22:24 |
| SpamapS | george_e: I believe its "" | 22:24 |
| SpamapS | george_e: as in, empty | 22:24 |
| george_e | Okay, thanks. | 22:24 |
| george_e | I was just wondering about that. | 22:24 |
| SpamapS | george_e: best to always specify a default though. :) | 22:24 |
| SpamapS | I think we talked about making some values required, which would mean you couldn't deploy the charm, and there was a lot of resistance to that idea. | 22:24 |
| george_e | Well, not in this case: it's for a username and password and email address :) | 22:25 |
| george_e | All the other options have defaults though. | 22:25 |
| rog | SpamapS: i just went through cloudinit/CloudConfig/cc_*.py and looked for occurrences of "cfg" | 22:41 |
| rog | SpamapS: which gave a pretty good idea of what fields there are and what types are expected | 22:41 |
| rog | (which is what i wanted to know, as i was making a Go package for generating cloud-init config) | 22:41 |
| rog | off to bed. | 22:43 |
| SpamapS | george_e: in the past I've used the empty string in the yaml file as the explicit default, and acted accordingly. :) | 22:47 |
| george_e | So just "default:" will suffice? | 22:47 |
| SpamapS | george_e: I did default: "" | 23:32 |
| george_e | With quotes? Does that work? | 23:32 |
| SpamapS | yes it is type: string | 23:32 |
| george_e | Okay, thanks. | 23:35 |
| george_e | SpamapS: Does config-get return the same data in each hook? | 23:35 |
| george_e | For example, can I access the DB config data in the config-changed hook? | 23:36 |
| SpamapS | george_e: relation-get is only available in *-relation-* hooks | 23:38 |
| SpamapS | george_e: config-get is always available | 23:38 |
| george_e | Oh right. | 23:39 |
| george_e | Okay, thanks. | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!