[19:35] <tobias47n9e_> Is there any chance we will still see a fix for this issue in 14.10? https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1297302
[19:35] <tobias47n9e_> I am developing a GTK program on Ubuntu and not being able to see a clean TreeView makes testing the UI really annoying.


[00:13] <paultag> jrgifford: unknown :)
[00:13] <paultag> jrgifford: if you send PRs, I know the ruby guy, he's my dude.
[02:10] <jrgifford> paultag:  looking at it, you guys all use sinatra.
[02:10] <paultag> jrgifford: yeah, that's right
[02:10] <paultag> we don't have rails anything
[02:10] <paultag> oh right, duh
[02:11] <jrgifford> hey, i wasn't sure.
[02:15] <paultag> jrgifford: I wasn't sure until you mentioned that :)
[02:15] <paultag> yeah! thanks for asking!
[02:15] <paultag> you rock all my socks
[02:15] <paultag> duh was @ me
[02:16] <jrgifford> paultag: was just trying to make sure we're all covered.
[02:16] <jrgifford> i mean, 6 years.
[02:16] <jrgifford> ouch.
[02:16] <paultag> aye!
[02:16] <paultag> someone made tender love to rails
[02:16] <paultag> (ha!)
[02:16] <jrgifford> lol


[01:53] <j4m3s_> i have an upstart script that doesn't appear to be setting the limit stack size, i have a pre-start script that sets the limits but my startup script throws a warning when the limit isn't set properly
[01:53] <SpamapS> j4m3s_: pre-start does not share process space/group w/ the main process
[01:53] <SpamapS> j4m3s_: you can just put that in script/end script with the main process
[01:56] <j4m3s_> SpamapS: http://pastie.org/private/nhapxgtg2qzzxzpjkjptg
[01:59] <SpamapS> ahh limit stanza
[02:00] <SpamapS> j4m3s_: http://pastie.org/4751117
[02:01] <SpamapS> j4m3s_: forgot to make it private.. but.. that might work
[02:01] <j4m3s_> i tried that too
[02:02] <j4m3s_> SpamapS: just confirmed still getting the same error
[02:03] <SpamapS> j4m3s_: what version of upstart is this btw? 1.4 and later will log stdout/stderr to /var/log/upstart/$jobname.log
[02:03] <SpamapS> j4m3s_: hm, with the numeric value, you need the soft and the hard
[02:03] <j4m3s_> 0.9
[02:05] <j4m3s_> SpamapS: i tried changing it to<PHONE_NUMBER>99, still getting same warning
[02:11] <SpamapS> j4m3s_: just to be sure, are you doing a full 'stop' then 'start' or just 'restart' ?
[02:11] <j4m3s_> restart
[02:11] <SpamapS> j4m3s_: ok, stop/start are needed to reload the job file
[02:12] <j4m3s_> SpamapS: start freeswitch   start: Unknown job: freeswitch
[02:15] <SpamapS> j4m3s_: check syslog, its probably got a syntax error
[02:15] <SpamapS> j4m3s_: if you have init-checkconf you can use that too
[02:27] <j4m3s_> SpamapS: http://pastie.org/private/knrpjsuz6nl84cojzx4tng
[02:29] <SpamapS> j4m3s_: thats after you fixed whatever was causing the "unknown job" ?
[02:29] <SpamapS> j4m3s_: KILL is sent 5 seconds after TERM when you stop a job
[02:29] <j4m3s_> i forgot the expect daemon
[02:29] <j4m3s_> sorry
[02:30] <SpamapS> still weird htt it would say KILL
[02:30] <SpamapS> usually it would just say that it exitted with status 1 or 0 or something
[02:33] <j4m3s_> SpamapS: it's still not working, it says it's running but it's not running
[02:49] <j4m3s_> SpamapS: it appears that upstart loses it whenever i put the limit stanza with the exec, if i put it in pre-start it tracks it fine and everything starts up fine
[02:51] <j4m3s_> SpamapS: the only way it succeeds is if the limit lines are commented out or in pre-start
[02:54] <j4m3s_> SpamapS: got it to work ;)
[03:08] <SpamapS> j4m3s_: perhaps your daemon only forks once, so 'expect fork' is more appropriate?
[03:08] <SpamapS> j4m3s_: what was the trick?
[09:44] <tohava> If I want to have shell code run SYNCHRONOUSLY before a service, should I put it in pre-start?
[09:56] <jodh> tohava: yes, that is guaranteed to be run before that jobs main ('exec' or 'script') stanza.
[09:57] <tohava> jodh, thanks
[09:58] <jodh> tohava: this is covered in the Upstart Cookbook here: http://upstart.ubuntu.com/cookbook/#job-lifecycle and is also in upstart-events(7) after all the tables :)


[12:32] <Kilos> hi guys how do i contact someone in the loco council please
[12:39] <dholbach> mail any of these people: https://launchpad.net/~ubuntu-lococouncil/+members#active
[12:39] <dholbach> or mail<EMAIL_ADDRESS>[12:40] <Kilos> ty dholbach , i just mailed the main link


[11:41] <kosaidpo> hello guys
[11:41] <kosaidpo> when is the first claas please ??
[11:42] <kosaidpo> oh theres none today
[11:42] <kosaidpo> okay


[05:49] <Kilos> morning africa
[10:51] <Kilos> hi ongolaBoy
[10:52] <Kilos> when are there going to be more mameroonians here??
[10:53] <Kilos> cameroonians as well


[00:02] <SpamapS> marcoceppi: put your email address (the more precise, the better), but yes, otherwise good.
[00:04] <m_3> aren't we ok with a copyright for the whole charm-tools project applying to the whole thing?
[00:05] <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:06] <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:09] <marcoceppi> SpamapS: Thanks! pushed up
[00:12] <SpamapS> marcoceppi: looks good. :)
[00:13] <marcoceppi> awesome
[00:13] <SpamapS> marcoceppi: so, if you wanted to get your feet wet on packaging.. lp:~charmers/charm-tools/packaging
[00:14] <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:15] <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:16] <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:17] <SpamapS> like, in your charm?
[00:18] <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
[12:26] <_mup_> Bug #894362 was filed: orchestra launch failure can "lose" machines <juju:In Progress by fwereade> < https://launchpad.net/bugs/894362 >
[14:20] <rog> fwereade_: if you want a distraction for a bit: https://codereview.appspot.com/5433056/
[14:20] <fwereade_> cheers rog
[14:21] <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:22] <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:23] <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:24] <rog> fwereade_: i can see why some people choose a more linear model
[14:25] <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:26] <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:27] <fwereade_> rog, definitely
[14:45] <rog> anyone know of a way to change a repo's default push location without actually using push?
[14:48] <therve> rog, you can set something for your branch in the locations.conf?
[14:49] <rog> therve: do you mean branch.conf?
[14:50] <rog> therve: if that's the definitive source for the info, that's a good idea, thanks.
[14:51] <therve> I meant ~/.bazaar/locations.conf, but branch.conf sounds good too :)
[14:52] <rog> therve: hmm, except it's stored there in full URL form rather than short lp:... form. i wonder if it'll work anyway.
[15:12] <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:15] <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:16]  * hazmat wanders off to enjoy the holiday
[15:34] <rog> hazmat: useful, yes, but in this case branch.conf is what i needed.
[15:39] <rog> fwereade_: next review in stack: https://codereview.appspot.com/5431067/
[15:39] <fwereade_> rog, cheers again
[15:40] <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:41] <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:42] <rog> s/review/merge request/
[15:42] <rog> i'll just put it in the comments
[15:43] <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:45] <rog> the diffs come to 980 vs 1257 lines respectively. i've chosen the wrong one, but it's probably not too bad.
[17:38] <rog> is there some definitive documentation on cloudinit somewhere? this only seems to give some examples: https://help.ubuntu.com/community/CloudInit
[20:07] <george_e> jcastro: Please, oh please be here...
[20:08] <george_e> I ran into some problems polishing up my ThinkUp charm.
[22:18] <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:22] <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:23] <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:24] <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:25] <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:41] <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:43] <rog> off to bed.
[22:47] <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?
[23:32] <SpamapS> george_e: I did  default: ""
[23:32] <george_e> With quotes? Does that work?
[23:32] <SpamapS> yes it is type: string
[23:35] <george_e> Okay, thanks.
[23:35] <george_e> SpamapS: Does config-get return the same data in each hook?
[23:36] <george_e> For example, can I access the DB config data in the config-changed hook?
[23:38] <SpamapS> george_e: relation-get is only available in *-relation-* hooks
[23:38] <SpamapS> george_e: config-get is always available
[23:39] <george_e> Oh right.
[23:39] <george_e> Okay, thanks.