[00:44] <menn0> davecheney: i've just pushed more wrench changes again. can you have another quick look?
[00:44] <menn0> if the scanner returns an error it's logged now
[00:45] <menn0> and various other things you raised have been addressed (except where I don't think they should be :-p)
[00:45] <davecheney> menn0: yup, LGTM, thanks
[00:45] <menn0> davecheney: cheers
[01:54] <davecheney> argh
[01:54] <davecheney> thumper:
[01:54] <davecheney> all this canWatch("") stuff is only so the tests can check the error path
[01:54] <davecheney> in the real code they are hard coded to return true
[01:54] <davecheney> but in the tests we set them to return false just so we can cause an error which we can then check ...
[01:55] <thumper> hmm...
[01:55] <thumper> seems suspect
[01:55] <davecheney>         if _, ok := <-watch.Changes(); ok {
[01:55] <davecheney>                 result.NotifyWatcherId = p.resources.Register(watch)
[01:55] <davecheney> what the code wants to do is cause this line to fail
[01:55] <davecheney> but it can't, instead it causese the line above
[01:55] <davecheney>         if !canWatch("machine-0") {
[01:55] <davecheney>                 return result, common.ErrPerm
[01:55] <davecheney> to fail
[01:55] <davecheney> so it gets it's error
[01:57] <davecheney> thumper: so i can do two things
[01:57] <davecheney> 1. supply a dummy, but valid tag
[01:58] <davecheney> 2. remove the logic and the test
[01:58] <davecheney> as it can never be try in production
[01:58] <davecheney> 1. solves todays problem by pushing it off onto someone else later on
[01:58] <thumper> where is the code that always returns true?
[01:58] <davecheney> state/apiserver/provisioner:NewProvsionerApi
[01:58] <davecheney> for example
[01:59] <davecheney> the tests's don't use that function, the construct a provisioner by hand
[02:00] <thumper> all I'd want to see a test for is that the provisioner api end point can watch the environment
[02:00] <thumper> any tests for failures there is a waste IMO
[02:01] <thumper> the auth func tests the tag
[02:01] <davecheney> ok, let me prepare a proposal
[02:01] <wallyworld> axw: morning, you have a minute?
[02:01] <axw> wallyworld: heya, yep
[02:02] <thumper> although it does seem that there should be a check around whether or not the machine can read the secrets
[02:02] <thumper> davecheney: as that is dependent on the state server job
[02:02] <davecheney> thumper: yes, that is different
[02:02] <thumper> ok
[02:02] <wallyworld> axw: standup hangout?
[02:15] <davecheney> thumper: https://github.com/juju/juju/pull/533
[02:15] <davecheney> i'd appreciate your thoughts
[02:16] <thumper> ok
[02:16] <davecheney> this is option (2)
[02:16] <davecheney> which is more wholesome
[02:16] <davecheney> but more difficult to stoumach
[02:24] <davecheney> thumper: thanks for the review
[02:24] <thumper> np
[02:24] <davecheney> this resolves 80% of the outstanding problems
[02:24] <davecheney> 20% coming real soon now
[02:24] <davecheney> then this is DONE
[02:24] <davecheney> and we can change common.AuthFunc
[02:47] <davecheney> thumper: https://github.com/juju/juju/pull/534
[02:58] <davecheney> lucky(~/src/github.com/juju/juju) % juju ssh 0
[02:58] <davecheney> ERROR upgrade in progress - Juju functionality is limited
[02:58] <davecheney> grrr
[02:59] <davecheney> menn0: http://paste.ubuntu.com/8076514/
[02:59] <davecheney> why did this happen, i thought it was fixed
[03:01] <menn0> davecheney: I believe when you do --upload-tools the initial version in the machine agent's conf file is different from version.Current
[03:01] <menn0> so upgrades still happen
[03:01] <menn0> "upgrade mode" should be pretty short lived
[03:01] <davecheney> that sounds odd
[03:01] <menn0> have you got the machine agent log handy
[03:01] <menn0> ?
[03:02] <davecheney> --upload-tools derives the versino of the tools from the local juju that just did --upload-tools
[03:03] <menn0> the logs will show the previous and next version, and also when the upgrade steps worker finished
[03:03] <davecheney> menn0: http://paste.ubuntu.com/8076553/
[03:03]  * menn0 looks
[03:03] <davecheney> menn0: there should be no version difference
[03:03] <davecheney> there was no previous environment
[03:03] <davecheney> i bootstrapped it from the version of juju i just built
[03:04] <menn0> here's the clue: "starting upgrade from 1.21-alpha1-precise-amd64 to 1.21-alpha1.1-precise-amd64"
[03:04] <davecheney> menn0: this is going to generate issues from the juju deployer folks if they use --upload-tools
[03:05] <menn0> the agent started at 02:57:34 and upgrades were done at 02:58:14
[03:05] <davecheney> sure
[03:05] <davecheney> it is slow
[03:05] <menn0> so "upgrade mode" was 45s long
[03:05] <davecheney> but i was able to trigger it in 3 out of 3 cases
[03:06] <davecheney> juju bootstrap --upload-tools && juju deploy cs:mysql
[03:06] <davecheney> will fail
[03:06] <menn0> if there's an actual upgrade to perform, we need to limit the API (aka "upgrade mode")
[03:07] <davecheney> right, but why is there an upgrade
[03:07] <davecheney> ther eis nothing to upgrade from
[03:07] <menn0> no idea
[03:07] <menn0> I didn't write that
[03:07] <menn0> but I'm happy to have a look
[03:07] <davecheney> thanks
[03:07] <davecheney> i just know its going to generate more bugs from the juju installer folks
[03:07] <davecheney> will log issue
[03:08] <menn0> I suspect it's to do with some functionality that keeps giving you new patch version every time you run upgrade-juju --upload-tools
[03:08] <menn0> assign it to me
[03:08] <menn0> it would be nice if we could avoid this following bootstrap
[03:11] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1358078
[03:11] <mup> Bug #1358078: cmd/juju: juju bootstrap --upload-tools on a fresh environment triggers upgrade mode <juju-core:New> <https://launchpad.net/bugs/1358078>
[03:11] <davecheney> menn0: i know CTS always script their juju deployments and they assume if a command returned 0 then it is safe to continue with the next command
[03:16] <menn0> davecheney: although that's ok with most commands I wonder if you be 100% that the machine agent is ready to go immediately after the bootstrap client command returns
[03:17] <menn0> it's certainly worse now with the restricted API
[03:17] <menn0> so I'll try to fix that
[03:17] <davecheney> menn0: its not the machine agent
[03:17] <davecheney> it's being able to create entires in the state database
[03:17] <davecheney> maybe that is what you were asking
[03:18] <menn0> yeah but the bootstrap machine agent runs the API server
[03:18] <davecheney> did you mean machine agent == provisioner
[03:18] <menn0> sorry, I should have said state server, not machine agent
[03:18] <davecheney> iff you can connect to the api, the expectaion was it would accept commands
[03:19] <menn0> agreed.
[03:19] <menn0> I guess because the client retries API requests it does just tend to work
[03:20] <menn0> the API server doesn't come up immediately when the bootstrap machine agent comes up
[03:20] <menn0> but the client side retries mask that from the user's persepective
[03:20] <menn0> anyway... let me have a look at this problem
[03:20] <davecheney> thanks
[03:33] <wallyworld> menn0: does the above problem affect 1.20?
[03:34] <wallyworld> i would argue that we don't do upgrade steps if just the build number is different
[03:34]  * menn0 checks 1.20 tag
[03:35] <wallyworld> sorry, i could have checked too, thought you may have known ottofh
[03:35] <wallyworld> ottoyh even
[03:35] <davecheney> wallyworld: i think it only affects using --upload tools
[03:36] <wallyworld> davecheney: sure, but they use that in 1.20 :-)
[03:36] <menn0> wallyworld: yes it does affect 1.20
[03:36] <wallyworld> :-(
[03:36] <wallyworld> ok, i'll assign the bug to 1.20 also
[03:36] <davecheney> wallyworld: it only afects you if you start with an empty enviromment
[03:36] <davecheney> then bootstrap --upload-tools
[03:37] <wallyworld> which is done for local provider
[03:37] <davecheney> BALLS!
[03:37] <menn0> and it's worse there because my recent work to avoid upgrade mode to if it's not required isn't in 1.20
[03:37] <wallyworld> ooops
[03:37] <menn0> or at least it's not in 1.20.2
[03:37] <wallyworld> we are about to release 1.20.5
[03:38] <wallyworld> tomorrow
[03:38] <menn0> this problem has been there all through 1.20
[03:38] <wallyworld> but this new issue will need to be fixed for 1.20.6
[03:38] <wallyworld> there was a bug raised actually
[03:38] <wallyworld> but we closed it
[03:39] <wallyworld> i think it does need some love however
[03:40] <wallyworld> menn0: i fixed the milestones on the bug - generally juju-core is assigned to a dev milestone; you mark a bug as affecting 1.20 series and then assign to a 1.20.x milestone for work done on that series
[03:41] <thumper> waigani: a lot of problems?
[03:42] <waigani> thumper: just had to redo everything
[03:42] <menn0> wallyworld: ok thanks. I'm a launchpad newbie
[03:42] <thumper> waigani: why?
[03:42] <wallyworld> menn0: np at all, just an fyi :-)
[03:42] <davecheney> is anyone paying attention to how many times the tests fail in CI and only pass because we retry them with less load ?
[03:42] <wallyworld> davecheney: yes
[03:43] <davecheney> wallyworld: good
[03:43] <wallyworld> there will be an email this week
[03:43] <davecheney> wallyworld: right
[03:43] <davecheney> thanks, glad to know you're on top of it
[03:43] <davecheney> i dunno what you are thinking, but I'm thinking 'remove the retry'
[03:43] <davecheney> we can use humans for this
[03:43] <wallyworld> been busy, would have liked to have initiated something sooner
[03:44] <wallyworld> davecheney: the plan is to have people who wrote the tests be responsible for fixing them as a matter of priority; and yes the retry will go as soon as practical; the expectation will be that tests will pass first time, not the other way around
[03:45] <wallyworld> ie we should be surprised when they fail, not when they pass
[03:45] <wallyworld> QA have offered to do a report on the failing tests
[03:46] <wallyworld> will make it easier to see what fails and how often
[03:46] <waigani> thumper: okay it's up
[03:47] <davecheney> wallyworld: sgtm
[03:47] <waigani> thumper: shall I jump back in hanyout?
[03:48] <menn0> wallyworld, davecheney: I've targeted bug 1350111 to 1.20 too because we need something there too. It'll be a somewhat different patch however as the code has changed a lot since 1.20
[03:48] <mup> Bug #1350111: machine agent enters "upgrade mode" unnecessarily <juju-core:Fix Committed by menno.smits> <juju-core 1.20:In Progress by menno.smits> <https://launchpad.net/bugs/1350111>
[03:48] <thumper> waigani: yeah
[03:48] <wallyworld> menn0: thanks, will be good to get that sorted in 1.20 also
[03:49] <davecheney> wallyworld: did you think we'll have a 1.22 stable release for U ?
[03:50] <davecheney> supporting 1.20 for the whole of U and backported to T would be unpleasant
[03:50] <wallyworld> davecheney: i am hoping so
[03:50] <wallyworld> but there are so many bugs still to fix :-(
[03:52] <davecheney> ｡･ﾟﾟ･(>д<)･ﾟﾟ･｡
[03:59] <menn0> davecheney: there there
[04:33] <menn0> wallyworld: do you have time for a quick hangout?
[04:33] <wallyworld> sure
[04:34] <menn0> wallyworld: https://plus.google.com/hangouts/_/canonical.com/onyx-standup ?
[04:35] <wallyworld> menn0: waiting in hangout
[05:14]  * thumper sends off an email and calls it a day
[05:14] <thumper> laters
[05:18] <menn0> davecheney, wallyworld: I have a fix for bug 1350111 (for trunk anyway). Will propose shortly.
[05:18] <mup> Bug #1350111: machine agent enters "upgrade mode" unnecessarily <juju-core:Fix Committed by menno.smits> <juju-core 1.20:In Progress by menno.smits> <https://launchpad.net/bugs/1350111>
[05:18] <wallyworld> great
[05:19] <menn0> sorry, wrong number. I meant bug 1358078.
[05:19] <mup> Bug #1358078: cmd/juju: juju bootstrap --upload-tools on a fresh environment triggers upgrade mode <juju-core:In Progress by menno.smits> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1358078>
[05:27] <davecheney> menn0: sweet
[05:28] <menn0> davecheney, wallyworld: https://github.com/juju/juju/pull/535
[05:28] <wallyworld> looking
[05:32] <menn0> wallyworld: thanks for the review
[05:32] <wallyworld> thank you for the fix
[05:33] <menn0> i've tested local already and am doing EC2 now
[05:33] <wallyworld> \o/
[05:33] <menn0> I have to deal with kids for a bit but will be back later
[05:48] <axw> wallyworld: fyi, I've gone down a bit of a rabbit hole - there's lots of badness in our maas provider code. going to try and fix it a bit while I'm there
[05:48] <wallyworld> ok
[05:48] <bigjools> \o/
[05:48] <wallyworld> /o\
[05:48] <axw> we don't convert juju architectures to maas ones, so our constraints are just broken
[05:48] <wallyworld> \o/
[05:49] <axw> we don't return hardware characteristics
[05:49] <axw> we choose arbitrary tools after acquring a node of an arbitrary arch
[05:49] <axw> :|
[05:52] <bigjools> and nobody noticed?  Is any of this tested? :)
[05:53] <axw> bigjools: there's a warning and a bug, I'm surprised nobody is kicking up more of a stink. I think we're just lucky because we default to amd64, which is what most people would be using I assume.
[05:53] <bigjools> yeah agreed
[05:57] <dimitern> morning all
[05:59] <axw> morning dimitern
[06:09] <wallyworld> bigjools: it hasn't been fully tested because we have been begging for maas hardware for 9 months
[06:10] <bigjools> I offered use of our CI lab as well
[06:11] <axw> wallyworld: bigjools: actually turns out we were just not passing the subarch, and we happen to have the same arch identifiers. false alarm on that specific bit...
[06:12] <bigjools> I was gonna say, that would have been spectacular
[06:12] <wallyworld> phew
[06:12] <bigjools> not surprised about subarch
[06:12] <bigjools> you don't *need* it
[06:13] <wallyworld> axw: how complete is the bit of code to pass the tools to target nodes via cloud init?
[06:13] <axw> wallyworld: 100% functional, just fixing bits around the edge and will have a bunch of tests to update.
[06:14] <axw> wallyworld: I have tested local and ec2, I haven't tested manual yet but that shouldn't be an issue
[06:14] <axw> wallyworld: sorry, I guess not quite 100% because we still need to update metadata...
[06:14] <voidspac_> morning all
[06:14] <wallyworld> axw: i'm thinking of cherry picking just that bit for use in 1.20, because the tools url hacking i need for local to use a mounted dir is messy, plus it won't work for kvm
[06:15] <wallyworld> o/
[06:15] <axw> wallyworld: it's not something that can easily be cherrypicked. provider/maas needs updates to return the arch name, for one thing
[06:15] <axw> morning voidspac_
[06:15] <wallyworld> axw: this would just be for local provider
[06:16] <wallyworld> to eliminate the need to get tools from http server
[06:16] <axw> wallyworld: it's much more intrusive than that... I've had to move all the "EnsureTools" stuff *outside* the providers
[06:16] <axw> so it's all or none
[06:16] <wallyworld> rightio
[06:27] <axw> menn0: I'm not sure that change is right
[06:27] <axw> menn0: we always bootstrap the same version as the CLI
[06:27] <axw> then upgrade toe the desired version
[06:27] <axw> to*
[06:39] <davecheney> axw: is this the --upload-tools bug ?
[06:40] <axw> davecheney: https://github.com/juju/juju/pull/535
[06:40] <davecheney> ok
[06:40] <axw> so yes, looks like it
[06:41] <davecheney> but whern I do --upload-tools, why is there a disagreemnt between the tools I uploaded, and the tools that the env thinks it is running
[06:41] <axw> dunno, that sounds broken
[06:41] <axw> davecheney: ah, probably because upload increments the build number on the tools
[06:41] <davecheney> axw: i think we have some logic that fudges the tools version uplaoded to not match any existing tools
[06:42] <davecheney> ie, the .1 that gets stuffed in there
[06:42] <axw> yeh
[06:42] <axw> p
[06:42] <davecheney> that's the bug
[06:43] <axw> gtg get my daughter from school, bbl
[07:01] <jam> morning dimitern
[07:01] <dimitern> morning jam! welcome back :)
[07:01] <jam> thanks
[07:05] <jam> dimitern: you just hung, but it might be me, I'll try reconnecting
[07:06] <dimitern> jam, i've reconnected as well
[07:07] <dimitern> jam, you seem hung in the g+
[07:12] <dimitern> jam1, i've rejoined several times, each time it says you're in the room, but then once I'm in it says waiting for people to join
[07:12] <dimitern> jam1, wanna try juju-sapphire g+ instead?
[07:12] <jam1> dimitern: my internet just died for 10 sec
[07:13] <jam1> but I should be able to connect now
[07:35] <menn0> axw: ping?
[07:35] <axw> menn0: pong
[07:36] <menn0> axw: so this proposed fix... I think it's ok but you have concerns
[07:36] <menn0> as far as I can tell, when --upload-tools is used
[07:36] <menn0> the wrong version gets written to agent.conf
[07:37] <menn0> so that when the machine agent comes up it think it needs to run upgrade steps
[07:37] <axw> menn0: ignore --upload-tools for a moment
[07:37] <menn0> ok
[07:37] <axw> menn0: when we bootstrap, we look for the most recent tools that matches major.minor of the CLI's tools
[07:37] <axw> menn0: we bootstrap with the exact same tools the CLI is running, but set agent-version=most recent
[07:38] <axw> the effect of this is that the machine agent comes up and immediately upgrades to agent-version
[07:38] <axw> that's what we *want* to happen
[07:38] <axw> and it does happen like that now
[07:39] <axw> menn0: IIANM, your change makes it so that the machine agent thinks it's running agent-version already, and so it doesn't run the upgrade steps
[07:39] <menn0> ok
[07:39] <axw> it'll still replace the binary, it just won't run the upgrade steps
[07:39] <axw> menn0: the issue with --upload-tools is that it increments the Build number in the tools
[07:40] <menn0> yep, I understand the --upload-tools case
[07:40] <axw> so what's deployed is never the same as the CLI
[07:40] <menn0> I didn't know about the standard bootstrap case
[07:40] <menn0> I will have to rethink then
[07:40] <menn0> what we want is:
[07:40] <menn0> - normal bootstraps to work as you just described
[07:41] <menn0> - juju upgrade-juju --upload-tools which increments just the build number to still trigger upgrade steps (for developers)
[07:41] <menn0> - juju bootstrap --upload-tools to NOT trigger the upgrade steps
[07:42] <axw> yup
[07:42] <axw> menn0: I think it's as simple as not incrementing the build number on bootstrap
[07:42] <axw> I don't see why we'd ever want to do that
[07:42] <menn0> yep
[07:42] <menn0> that makes sense
[07:42]  * menn0 looks at code
[07:43]  * axw should really document bootstrap some time
[07:46] <menn0> axw: I think I know why we still increment the version on bootstrap when --upload-tools is passed
[07:46] <menn0> if the tools storage is shared between envs
[07:46] <menn0> axw: is it?
[07:47] <axw> menn0: I don't think you can do that without running into problems
[07:47] <axw> it's going to change real soon now anyway
[07:47] <menn0> ok then it should be fine
[07:47] <axw> we're getting rid of provider storage
[07:50] <menn0> axw: I've been hunting through revision history
[07:51] <menn0> do you think the incrementing the build number is done to ensure that the uploaded tools are used in preference to any tools in the public streams?
[07:52] <menn0> axw: I'm wondering about another way to skin this cat:
[07:52] <axw> menn0: ugh, that may be a problem, yeah.
[07:52] <axw> menn0: TBH, it might be worth waiting till I'm done with my changes... this may be fixed incidentally
[07:52] <menn0> if bootstrap is given --upload-tools, we get that version into the agent.conf, if not use version.Current
[07:53] <axw> except that won't fix 1.20
[07:53] <axw> menn0: can do, but sounds like it might be messy
[07:53] <axw> how will you convey that information?
[07:54] <menn0> via a field in MachineConfig perhaps?
[07:56] <menn0> axw: so is the Tools field in cloudinit.MachineConfig definitely the target agent version, not the initial one?
[07:56] <axw> menn0: until my changes go in, each provider's Bootstrap creates its own MachineConfig
[07:57] <axw> hmm
[07:57] <axw> menn0: it is the bootstrap tools, but hmmmm
[07:57] <axw> menn0: I think I may have misunderstood the change
[07:57] <axw> I'll take another look...
[07:57] <menn0> axw: np
[07:58] <axw> menn0: sorry, your original change was right :)
[07:58] <menn0> phew!
[07:58] <axw> it'll bootstrap with those tools
[07:58] <axw> then it'll see agent-version is different and upgrade
[07:58] <axw> sorry about that
[07:59] <menn0> no problems
[07:59] <menn0> I'd like to test the non-uploading case but that's kinda hard without having these changes in a official release
[08:00] <menn0> is there another way? (custom streams or something)
[08:02] <menn0> axw: ^^
[08:02] <axw> urhm
[08:03] <axw> you could use sync-tools to generate the metadata
[08:03] <axw> menn0: simplest way would probably be to tweak version.go, sync-tools, then revert version.go
[08:03] <menn0> axw: cool. I will look in to that tomorrow.
[08:03] <menn0> I also need to read simplestreams-metadata.txt
[08:04] <menn0> thanks for your help and for being concerned about my change
[08:04] <axw> no worries :)
[08:04] <menn0> I'd rather have that than bad code getting in
[08:04] <menn0> I'm EOD
[08:07] <TheMue> morning
[08:27] <dimitern> morning TheMue, voidspac_
[08:28] <TheMue> dimitern: I pushed my change to my repo on Friday, only the tests are missing. but I needed an additional API call to see if a machine is manually provisioned. looks good so far.
[08:29] <dimitern> TheMue, sweet! I'm looking forward to seeing it
[08:29] <TheMue> dimitern: the current changes are at https://github.com/TheMue/juju/compare/capability-detection-for-networker
[08:30] <voidspac_> TheMue: dimitern: morning
[08:33] <TheMue> voidspac_: hello
[08:34] <dimitern> TheMue, looking
[08:36] <dimitern> TheMue, looks nice, although for the IsManual API call, I'd implement it a bit differently
[08:37] <dimitern> TheMue, like getting the IsManual flag as part of getting the machine's live value
[08:37] <TheMue> dimitern: it’s able for bulk calls
[08:37] <dimitern> TheMue, i.e. caching it, so you can return it directly without an extra call
[08:37] <dimitern> TheMue, yeah, LifeGetter also supports bulk calls
[08:38] <TheMue> dimitern: will take a look
[08:39] <dimitern> TheMue, cheers
[09:00] <jam1> TheMue: I'm just finishing up lunch, I'll be a little bit late.
[09:00] <TheMue> jam1:  ok, just ping
[09:00] <mattyw> fwereade_, ping?
[09:22] <jam1> TheMue: I'm in the hangout
[10:18] <voidspac_> given a package name, how do I tell what files / binaries it provides?
[10:18] <dimitern> voidspac_, you can run a godoc server for that package locally
[10:19] <voidspac_> dimitern: by package I mean ubuntu package, sorry
[10:19] <dimitern> voidspac_, ah :)
[10:19] <voidspac_> dimitern: go doesn't have packages, does it?
[10:19] <voidspac_> I mean, it doesn't use that term
[10:20] <voidspac_> it has "dependencies", which can be anything pretty much
[10:20] <dimitern> voidspac_, they are packages
[10:20] <dimitern> :)
[10:20] <voidspac_> well, they're not
[10:20] <dimitern> voidspac_, for debs: $ apt-cache showsrc juju-core
[10:20] <voidspac_> they're a hodge-podge of files
[10:20] <dimitern> voidspac_, :)
[10:20] <voidspac_> dimitern: thanks
[10:21] <voidspac_> dimitern: hmmm... not quite it, I want to know what files it will put where
[10:21] <voidspac_> dimitern: is there a determinstic way of knowing that?
[10:21] <voidspac_> I guess now as the install scripts execute code
[10:23] <voidspac_> I mean, I guess not
[10:23] <dimitern> voidspac_, well, these 3 files are the only ones in the deb archive actually
[10:23] <voidspac_> dimitern: the tarballs?
[10:24] <dimitern> voidspac_, if you want to see the source itself, try apt-get source <package>
[10:24] <voidspac_> dimitern: so download the package and inspect it
[10:24] <voidspac_> fair enough
[10:24] <dimitern> voidspac_, yeah, and take a look at the debian tarball for hooks I guess
[10:25] <dimitern> voidspac_, and rules (which is as readable as any generated Makefile :)
[10:27] <voidspac_> dimitern: thanks :-)
[10:36] <wallyworld> fwereade_: morning, you up for a chat about health checks sometime?
[10:36] <fwereade_> wallyworld, heyhey
[10:38] <wallyworld> let me know when you have time and we can do a hangout
[10:38] <fwereade_> wallyworld, what time is it for you?
[10:39] <wallyworld> 20:30
[10:41] <fwereade_> wallyworld, hmm, and how early do you like to get up?
[10:41] <wallyworld> i'm up around 6 but need to take the kid to school, back around 7
[10:47] <dimitern> jam1, standup?
[12:25]  * fwereade_ restarting then hopefully with wallyworld
[13:49] <voidspac_> perrito666: ping
[13:49] <voidspac_> Command failed: mongodump --dbpath /var/lib/juju/db
[13:49] <voidspac_> Error: bash: line 9: mongodump: command not found
[13:50] <voidspac_> perrito666: do you recognise that? No mongodump on my state server.
[14:04] <ericsnow> voidspac_: /var/lib/juju/mongodump is installed as part of the tools in a local juju environment
[14:04] <voidspac_> ericsnow: this isn't local this is an openstack environment
[14:04] <voidspac_> ericsnow: and that error message was the output from "juju backup", that location is where the backup script was looking
[14:05] <voidspac_> ericsnow: but thanks :-)
[14:05] <ericsnow> voidspac_: (yeah, drop the "local" part)
[14:05] <ericsnow> voidspac_: weird
[14:06] <voidspac_> ericsnow: I just destroyed the environment and will try again
[14:06] <voidspac_> ericsnow: I think I started the backup too early
[14:06] <ericsnow> voidspac_: FYI horacio is out today
[14:06] <voidspac_> ericsnow: hmmm, installed as part of the tools?
[14:06] <ericsnow> voidspac_: ah, that makes sense
[14:07] <ericsnow> voidspac_: right
[14:07] <voidspac_> I wonder if that works when you do --upload-tools
[14:07] <voidspac_> ericsnow: I don't need upload-tools anyway, as restore is run on the client
[14:07] <voidspac_> although that might be weird...
[14:07] <voidspac_> we'll see
[14:08] <voidspac_> WARNING no prepackaged tools available
[14:08] <voidspac_> uploading tools
[14:08] <voidspac_> so I get no choice in the matter :-)
[14:09] <ericsnow> voidspac_: while restore runs on the client, most of the work is happening on the remote host
[14:09] <voidspac_> ericsnow: yeah, but it's mostly batch scripts uploaded from the client :-)
[14:10] <voidspac_> ericsnow: the part I'm *changing* runs on the client
[14:10] <voidspac_> so that's the bit I want to check works
[14:10] <ericsnow> voidspac_: disclaimer--most of what I know of restore is from working on backup :)
[14:10] <voidspac_> hah
[14:10] <voidspac_> ericsnow: I'm working on hacking a fix into the old plugin anyway
[14:10] <voidspac_> ericsnow: not touching the shiny new stuff you did :-)
[14:10] <ericsnow> voidspac_: right
[14:10] <ericsnow> voidspac_: still polishing :)
[14:11] <voidspac_> :-)
[14:19] <voidspac_> ericsnow: so when I bootstrap an openstack environment from dev I don't see a mongodump in the uploaded tools
[14:20] <voidspac_> I might have to blow away dev and try with 1.18/1.20
[14:20] <voidspac_> it might be a curiousity of upload-tools
[14:20] <ericsnow> voidspac_: not sure then
[14:21] <ericsnow> voidspac_: I never got around to figuring out for myself where mongodump, etc. came from
[14:21] <ericsnow> voidspac_: it should be in the same dir as mongod
[14:22] <voidspac_> ah right
[14:22] <voidspac_> mongod isn't in the uploaded tools directory either, must be elsewhere
[14:22] <voidspac_> I'm trying with 1.18 now
[14:22] <ericsnow> voidspac_: yeah, not the uploaded tools dir
[14:23] <ericsnow> voidspac_: pretty sure /var/lib/juju holds just the juju-built mongo binaries
[14:23] <voidspac_> ericsnow: ok, will check when this environment has bootstrapped
[14:24] <voidspac_> thanks
[14:24] <voidspac_> (again)
[14:24] <voidspac_> :-)
[14:24] <ericsnow> :)
[14:24] <ericsnow> voidspac_: yeah!  I was helpful to someone :)
[14:31] <voidspac_> ericsnow: /usr/lib/juju/bin
[14:32] <voidspac_> not /var/lib/juju
[14:32] <ericsnow> voidspac_: ah
[14:41] <voidspac_> ericsnow: ok, interesting
[14:41] <voidspac_> ericsnow: so now with a freshly bootstrapped machine from dev
[14:41] <voidspac_> I *do* have mongodump in /usr/lib/juju/bin
[14:41] <voidspac_> but it's not in path
[14:41] <ericsnow> voidspac_: right
[14:41] <voidspac_> I'm giving it a chance for bootstrap to complete before I try mongodump
[14:41] <voidspac_> looks like just a path issue then
[14:42] <ericsnow> voidspac_: if I recall correctly it tries /usr/lib/juju/bin explicitly first and then falls back to $PATH
[14:43] <voidspac_> ericsnow: backup and restore CI test is passing, so it's not broken - it just may be hard / impossible to manually test without recreating some of the CI infastructure
[14:43] <voidspac_> (they avoid using --upload-tools in tests for other reasons)
[14:43] <ericsnow> voidspac_: makes sense
[14:44] <voidspac_> brb
[15:35] <voidspac_> right
[15:35] <voidspac_> goodnight
[16:27] <katco> i need some help with facades: i see a FacadeCall("ContainerConfig",...), but i can't figure out where "ContainerConfig" is registered as a Facade...
[16:31] <ericsnow> katco: registration happens with a call to state/apiserver/common.RegisterStandardFacade() (or similar)
[16:31] <ericsnow> katco: e.g. state/apiserver/client/client.go
[16:31] <katco> ericsnow: yeah, i gathered that, but a quick grep shows no registrations for "ContainerConfig"... indeed the only _reference_ i can find to that facade is the call...
[16:31] <ericsnow> katco: I don't see one under apiserver for ContainerConfig
[16:31] <ericsnow> katco: is it a facade or something on a facade?
[16:32] <ericsnow> katco: perhaps it's dead code?
[16:33] <katco> ericsnow: perhaps... i'm trying to wind my way through a failing test
[16:33] <katco> ericsnow: it's in api/provisioner/provision.go::CreateConfig()
[16:37] <ericsnow> katco: looks like FacadeCall is just a wrapper around a facade for calling a method on that facade
[16:37] <ericsnow> katco: so ContainerConfig is a method on some facade rather than a facade itself
[16:38] <katco> ericsnow: ah ok... so i'm trying to trace down the facade that's passed in; it's probably a method on there?
[16:38] <ericsnow> katco: yep
[16:38] <katco> ericsnow: ok we'll see where this yarn ends then :)
[16:38] <katco> ericsnow: thank you
[16:39] <ericsnow> katco: apiserver/provisioner/provisioner.go defines a ContainerConfig method
[16:39] <katco> ericsnow: yeah i had been looking at that, but it looks correct. i'm probably missing something eyeballing it
[17:23] <katco> ericsnow: arrrrrrg, it was a test mocking out that call.
[17:24] <ericsnow> katco: :(
[18:01] <sinzui> katco, ericsnow: have another version increment for stable because we are releases 1.20.5 today. https://github.com/juju/juju/pull/537
[18:02] <katco> sinzui: thanks, sinzui. very exciting :) lgtm too
[18:03] <sinzui> oh, for anyone looking at recent history of CI, Hp and AWS had soem bad hours. The QA team cleanup some machines and restarted the tests. master was *never* broken
[21:01] <thumper> mramm: morning, we hanging out this morning?
[21:06] <mramm> yep
[21:06] <mramm> sorry I am late
[21:08] <mramm> thumper: you still around?
[21:08] <thumper> mramm: aye
[21:08]  * thumper jumps into hangout
[21:35] <katco> wallyworld_: no worries. emacs just crashed when you sent that >.<
[22:00] <alexisb> thumper, on and ready when you are
[22:00] <thumper> alexisb: ack, coming
[22:00] <alexisb> no rush
[22:00] <alexisb> I just have a hard stop at the top of the hour
[23:35] <menn0> thumper, davecheney, waigani_ : regarding that bootstrap version behaviour that you didn't like the sound of
[23:35] <menn0> looking at the code
[23:35] <menn0> it seems like it might be ok
[23:35] <thumper> good
[23:35] <menn0> it's asking the cloud instance itself for the tools metadata it has
[23:35] <thumper> right...
[23:35] <menn0> and therefore it's only checking through tools that are available /on that cloud/
[23:35] <thumper> yeah...
[23:36] <thumper> but does it make sense for it it automatically upgrade?  Just wondering
[23:36] <thumper> and if so, to what version?
[23:36] <menn0> so it's not going to ask the new environment to upgrade to tools that it doesn't have
[23:36] <thumper> if I bootstrap 1.18
[23:36] <thumper> what happens?
[23:36] <thumper> assuming I have a 1.18.0 client
[23:36] <menn0> from what I have gathered from the code
[23:36] <menn0> it will bootstrap 1.18.0
[23:37] <menn0> but set the env agent-version to the latest 1.18.X available on the cloud
[23:37] <menn0> so when the bootstrap machine agent comes up it will immediately upgraded to 1.18.X
[23:37] <menn0> if there is no 1.18 available on the cloud
[23:38] <menn0> it'll upload the local tools and the env will be running 1.18.0 (no upgrade)
[23:38] <menn0> does that sound reasonable?
[23:38] <menn0> if not, talk to Andrew
[23:38] <menn0> (I'm just the messenger!)
[23:38] <thumper> hmm...
[23:38] <thumper> but the initial version is the same as the client?
[23:39] <menn0> yes, but only for a short time
[23:39] <davecheney> waigani: if you want to be on call reviewer for today, that would be good, we only have brits
[23:39] <menn0> the upgrade (i.e. restart into the new version) happens almost immediately
[23:39] <thumper> and it is only the patch number that is allowed to change?
[23:39] <thumper> so major.minor have to be the same?
[23:39] <menn0> yes
[23:39] <waigani> davecheney: okay
[23:39] <menn0> it filters on major.minor
[23:40] <thumper> I suppose that is ok
[23:40] <menn0> my guess for the reasoning is to ensure the the env is running with the most bugs fixed
[23:42] <menn0> thumper, davecheney: one problem that just comes to mind is that it has the potential the break the "juju bootstrap && juju deploy foo" use case.
[23:43] <menn0> if the bootstrap machine agent comes up and then restarts soon after
[23:43] <menn0> and then goes in to "upgrade mode" soon after
[23:46] <thumper> well... hopefully the user has an up to date client :)


[08:05] <seb128> happy friday desktopers!
[08:06] <Laney> hey, happy friday!
[08:07] <seb128> Laney, to you too!
[08:07] <seb128> Laney, we got your grey&rainy weather, I'm not thanking you for that :p
[08:08] <Laney> hah
[08:08] <Laney> that's what you get for showing off earlier in the week :P
[08:08] <seb128> seems so :/
[08:08] <seb128> oh, another settings update landing in saucy
[08:09] <seb128> that and the new intel driver
[08:09] <seb128> things start looking good for release ;-)
[08:09] <Laney> ship it
[08:38] <czajkowski> good morning people
[08:38] <czajkowski> how are we all doing
[08:40] <seb128> czajkowski, hey, happy friday! we are doing well indeed ;-)
[08:41] <czajkowski> excellent glad to hear it
[08:41] <czajkowski> any plans for the weekend ?
[08:42] <seb128> celebrating didrocks getting married
[08:43] <seb128> which involves spending 6 hours in a train to go there tomorrow and then same time to come back on sunday
[08:43] <seb128> that should do for the w.e ;-)
[08:43] <seb128> czajkowski, you?
[08:45] <Laney> that is quite some train
[08:45] <sil2100> Morning! Ah, so that's the reason for Didier's holidaying, huh? ;)
[08:48] <czajkowski> seb128: dinner with my mum my bf family over the weekend
[08:48] <czajkowski> and hanging out, I've had a busy week
[08:50] <seb128> sil2100, good morning, indeed
[08:51] <seb128> Laney, yeah, the line from here to Lyon is a slow one :/
[08:51] <seb128> oh well, didrocks doesn't get married every week
[08:52] <seb128> and those trains are nice, they have a nice seats, are quiet, have power plugs ... they even have a "bar" wagon with food and drinks
[08:52] <seb128> I guess I'm going to take my laptop and play some good starcraft or something
[08:53] <Laney> nice
[08:53] <Laney> i'm sure it'll be great!
[08:53] <seb128> ;-)
[08:54] <seb128> pitti vuntz and some others are going to be there, I'm sure it's going to be fun ;-)
[08:54] <seb128> (well not in the train, but for the weeding)
[09:11] <Laney> oh noes
[09:13] <Laney> something is weird
[09:13] <Laney> http://paste.ubuntu.com/6191464/
[09:13] <Laney> oh
[09:13] <Laney> is not disabled
[09:13] <Laney> weird
[09:15] <seb128> Laney, what is weird?
[09:15] <Laney> I misread that message
[09:15] <seb128> oh ok
[09:15] <Laney> anyway I restarted my laptop and now shortcut keys don't work
[09:16] <seb128> is the plugin enable?
[09:16] <Laney> (not unity)
[09:16] <Laney> yes
[09:16] <seb128> shortcut = multimedia keys?
[09:16] <Laney> yeah, and e.g. ctrl-alt-t for terminal
[09:16] <Laney> volume
[09:17] <seb128> weird, ... do you have anything in the g-s-d log?
[09:20] <Laney> oh, didn't they stop doing media keys?
[09:20] <Laney> it might have been so long since i rebooted that i was on 3.6 before
[09:20] <seb128> they did, but darkxst reverted that
[09:20] <Laney> for unity only
[09:20] <seb128> right
[09:21] <Laney> this is panel/xmonad
[09:21] <seb128> gnome-shell handles those keys
[09:21] <seb128> oh
[09:21] <Laney> :(
[09:21] <seb128> yeah, you are probably screwed then :/
[09:21] <Laney> darkxst: is that supposed to be broken?
[09:21] <Laney> I also get some weird notification bubbles instead of osd now
[09:21] <seb128> we should change the "for unity" to be "for any non-gnome-shell session"
[09:22] <mitya57> +1, I tried to use gnome-panel and got similar issues
[09:23] <Laney> hmm, it watches for unity on dbus and turns media keys on then
[09:23] <seb128> right
[09:23] <seb128> it should watch for gnome-shell and turn it off
[09:24] <Laney> mitya57: any idea what the notification problem is?
[09:24] <seb128> Laney, what notifications do you get?
[09:24] <mitya57> I haven't yet debugged it, and on a different machine now
[09:24] <Laney> been so long since I've seen them but it might be notification-daemon ones
[09:24] <Laney> with an 'x' in the top right
[09:25] <mitya57> yes, for me those were notification-daemon ones
[09:25] <seb128> Laney, my bet is that it's due to robru changes in http://launchpadlibrarian.net/124264231/notify-osd_0.9.34-0ubuntu5_0.9.35daily12.11.28-0ubuntu1.diff.gz
[09:25] <mitya57> ... with 'x' and part of the message somewhere outside the screen :)
[09:25] <seb128> +++ notify-osd-0.9.35daily12.11.28/data/org.freedesktop.Notifications.service.in	2012-11-28 06:30:35.000000000 +0000
[09:25] <seb128> @@ -1,3 +1,3 @@
[09:25] <seb128>  [D-BUS Service]
[09:25] <seb128>  Name=org.freedesktop.Notifications
[09:25] <seb128> -Exec=/bin/sh -c 'if [ ! -x /usr/lib/notification-daemon/notification-daemon ] || [ "$GDMSESSION" = guest-restricted ] || [ "$GDMSESSION" = gnome-classic-guest-restricted ] [ "$GDMSESSION" = default -a "$(basename `readlink /etc/alternatives/x-session-manager`)" = gnome-session ] || [ "$GDMSESSION" = ubuntu ] || [ "$GDMSESSION" = ubuntu-2d ]; then exec /usr/lib/notify-osd/notify-osd; else exec /usr/lib/notification-daemon/notification-daemon;
[09:25] <meetingology> seb128: Error: "@" is not a valid command.
[09:25] <seb128>  fi'
[09:25] <seb128> +Exec=@LIBEXECDIR@/notify-osd
[09:25] <seb128> Laney, ^ he dropped our diff when putting the packaging inline upstream
[09:26] <Laney> ah
[09:26] <seb128> I saw that a bit back, but since it was not creating apparent issues we decided to not bother (we being didrocks and I, we discussed it on this channel)
[09:26] <darkxst> Laney, seb128 media keys are not supposed to be broken
[09:26] <seb128> darkxst, what is supposed to handle them in a xmonad session?
[09:27] <seb128> darkxst, it seems you made the revert specific to unity
[09:27] <Laney> darkxst: I don't think panel handles them
[09:27] <Laney> so you get broken there
[09:27] <darkxst> oh, what is xmonad even?
[09:27] <Laney> it's just a window manager
[09:27] <Laney> would be the same for metacity i guess
[09:28] <darkxst> I can re-do the patch for GNOME instead of Unity
[09:29] <Laney> Like invert it?
[09:29] <Laney> I don't know if anything else handles the keys atm, but if not that sounds like a good idea
[09:29] <darkxst> yeh like check for a GNOME session
[09:29] <darkxst> instead
[09:29]  * Laney nods
[09:29] <Laney> let me know if you want testing
[09:30] <seb128> rather than checking for unity and enable, check for gnome-shell and disable in that case only?
[09:30] <darkxst> seb128, yah
[09:30] <darkxst> might still break flashback, but thats generally just broken anyway
[09:31]  * Laney tries putting the osd dbus service file back as it was
[09:31] <mitya57> darkxst: why?
[09:31] <mitya57> (why will it break flashback and why it is broken anyway)
[09:33] <darkxst> mitya57, flashback is mostly more like Unity, but it uses the GNOME desktop session name (I believe)
[09:34] <mitya57> darkxst: can you check for some gnome-shell D-Bus interface instead of checking the session name?
[09:35] <darkxst> yes but its not reliable, because unity clones some of the gnome-shell d-bus interfaces ;(
[09:37] <darkxst> anyway there are lots of patches, across a bunch of packages that check for XDG_CURRENT_DESKTOP
[09:37] <darkxst> and in most cases the results will be wrong for flashback
[09:38] <mitya57> we can rename the flashback sessions to ubuntu-* then
[09:44] <Laney> ok the notification-daemon thing isn't because of the dbus service file
[09:44] <Laney> it's because it's now started via xdg autostart
[09:45] <mitya57> You may then want to add something like this: https://mail.gnome.org/archives/gnome-flashback-list/2013-September/msg00069.html
[09:45] <mitya57> AutostartCondition=GNOME3 unless-session
[09:45] <mitya57> gnome
[09:45] <seb128> Laney, that somewhat makes sense I guess, it makes easier to decide on what desktop it should be activated, compared to dbus activation which has no OnlyShowIn
[09:47] <Laney> I'd have thought that we always want notify-osd (if installed) on Ubuntu
[09:48] <seb128> "we"?
[09:48] <seb128> KDE and gnome-shell probably don't
[09:48] <seb128> not sure about xfce
[09:48] <Laney> don't install it then
[09:48] <Laney> indeed they do not
[09:49] <Laney> then you should get the correct one dbus activated for you
[09:50] <Laney> oh, I see
[09:50] <Laney> notification-daemon isn't dbus activated any more
[09:51] <mitya57> there are people who install "vanilla" Ubuntu and then install and use gnome-shell
[09:51] <mitya57> they shouldn't get notify-osd
[09:52] <Laney> how do you tell?
[09:54]  * mitya57 thinks gnome-shell notifications are better integrated and more consistent with other parts of the shell
[09:56] <Laney> ok, so
[09:56] <sil2100> seb128: can I ask you for some packaging change ACKs?
[09:56] <Laney> what's DESKTOP_SESSION under gnome shell?
[09:56] <seb128> sil2100, sure
[09:58] <seb128> Laney, I think the consensus, last time we discussed it on #debian-gnome was that dbus activation was wrong and that the notification agents should all use autostarts rather, so they can target their environment with ShowOnlyIn
[09:58] <darkxst> Laney, "gnome"
[09:59] <sil2100> seb128: https://jenkins.qa.ubuntu.com/view/cu2d/view/Saucy/view/Indicators/job/cu2d-indicators-saucy-3.0publish/56/artifact/packaging_changes_indicator-sound_12.10.2+13.10.20131004-0ubuntu1.diff <- this one seems sane
[09:59] <seb128> Laney, e.g the notification are part of the desktop experience
[09:59] <sil2100> seb128: https://jenkins.qa.ubuntu.com/view/cu2d/view/Saucy/view/Indicators/job/cu2d-indicators-saucy-3.0publish/56/artifact/packaging_changes_indicator-bluetooth_0.0.6+13.10.20131004-0ubuntu1.diff <- not sure about the rationale of this one, but on desktop it makes sense I guess
[09:59] <seb128> sil2100, +1 (I acked that mr for upstream ;-)
[09:59] <seb128> sil2100, it was bringing the phone settings on some other images, +1 as well
[10:00] <mitya57> darkxst, Laney: on my Debian machine it was "default" or "gnome" depending on what was selected in gdm, though I'm not sure if it's the case in Ubuntu
[10:03] <Laney> I guess if the goal is to have every "gnome" environment having n-daemon then I have to change it locally
[10:04] <Laney> It's not an explicit goal though; something changed here to make it start for me now when it didn't before
[10:04] <seb128> Laney, no, I think the goal is to have gnome-shell/kde/(xfce?) uses their own notification system
[10:05] <seb128> Laney, we should use notify-osd is gnome-panel sessions imhp
[10:05] <seb128> imho
[10:05] <seb128> that's our default implementation, if a desktop doesn't specifically specify they want something else
[10:07] <seb128> glatzor, hey
[10:10] <seb128> glatzor, have you seen https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1200775 ? is that an aptdaemon issue/something that changed there which makes port in other code needed?
[10:10] <ubot2> Launchpad bug 1200775 in apturl (Ubuntu) "apturl-gtk crashed with AttributeError in __init__(): 'InstallBackendAptdaemon' object has no attribute 'connect'" [High,Confirmed]
[10:14] <darkxst> M3e^tkj8
[10:14] <Laney> doh
[10:16] <seb128> time for a new password ;-)
[10:17] <darkxst> seems so, silly lock screen!
[10:27] <seb128> glatzor, unping, that's an update-manager/pitti issue
[10:27] <mitya57> darkxst: re patches in bug 1189309: do you know why the first one was uploaded instead of the second one?
[10:27] <ubot2> Launchpad bug 1189309 in network-manager-applet (Ubuntu) "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [Medium,Fix released] https://launchpad.net/bugs/1189309
[10:40] <seb128> glatzor, just for the record, not a pitti issue, he just happened to have uploaded the version, found the right people now and reassigned ;-)
[10:46] <cjwatson> I upgraded today and have a black screen (with mouse pointer) when I try to log in.  compiz is running, unity-panel-service is running.  Any guesses where I could start debugging?
[10:48] <cjwatson> Hmm, and gnome-control-center-unity has a greater version in raring-updates than in saucy; don't know if that's directly related but it doesn't seem good
[10:49] <seb128> cjwatson, that's specific to g-c-c, should have an impact on your session
[10:49] <cjwatson> YM shouldn't?
[10:49] <seb128> cjwatson, can you share your ~/.cache/upstart/gnome-session.log?
[10:49] <seb128> cjwatson, yes, sorry
[10:49] <seb128> cjwatson, that's just a .so for g-c-c, that's not your issue
[10:49] <seb128> but I'm going to make sure we fix the lower version issue
[10:49] <cjwatson> oh, here, now it's started, but it took forever
[10:50] <cjwatson> http://paste.ubuntu.com/6191729/
[10:50] <cjwatson> it took at least a couple of minutes to start with no visible feedback
[10:50] <seb128> those WARN  2013-10-04 11:44:19 unity.glib.dbus.server GLibDBusServer.cpp:586 Can't register object 'com.canonical.Unity.Launcher' yet as we don't have a connection, waiting for it...
[10:50] <seb128> are weird
[10:50] <seb128> Trevinho, bregma: ^ did you see that before?
[10:51] <seb128> cjwatson, I wonder if the dbus changes from xnox could create an issue...
[10:51] <cjwatson> seb128: I don't have his change yet
[10:52] <cjwatson> oh, not his latest one, but I do have a previous one
[10:52] <cjwatson> dbus 1.6.12-0ubuntu6
[10:52] <cjwatson> does seem a plausible possibility
[10:52] <seb128> cjwatson, is that reproducible? e.g if you start a guest session?
[10:53] <xnox> seb128: well, dbus --fork & expect fork, should only make "started dbus" event be emitted later. so things that e.g. "start on starting dbus" will have invalid dbus_session_bus environment variable, which only starts working after "started dbus"
[10:53]  * xnox ponders if we should be exporting dbus_session_bus only at post-start
[10:53] <cjwatson> guest session starts quickly; let me try rebooting
[10:53] <cjwatson> well, it sort of starts - I don't have indicators
[10:54] <xnox> seb128: that changed fixed unity on the phone....
[10:54] <seb128> cjwatson, that's a known issue and fixed in lightdm trunk, alt-f2 /usr/lib/unity/unity-panel-service to get them
[10:54] <cjwatson> not convinced this is running with the same session type though
[10:55] <Laney> I had those messages with previous dbus FWIW
[10:55] <seb128> or start the guest from the greeter rather than from the indicator-session
[10:55] <seb128> Laney, but no hang?
[10:55] <Laney> no
[10:55] <Laney> dist-upgrading now
[10:55] <Laney> new xorg, intel drivers too I suppose
[10:56] <seb128> k, maybe those messages are a red-hearing
[10:56] <seb128> herring
[10:56]  * Laney restarts
[10:58] <cjwatson> sigh, this time it worked fine
[11:07] <cjwatson> OK, two more reboots and it's still fine, so this doesn't seem reproducible at all.  Sorry to bother you
[11:07]  * cjwatson will clean up the cause of his accidentally slightly mixed raring/saucy system though
[11:11] <bregma> seb128, I often see that warning during startup, I don't think it means there's a problem
[11:14] <seb128> bregma, right, seemed like it could create delay, but it seems they are happening on systems which don't have delays
[11:14] <seb128> cjwatson, yeah, I don't know, maybe something hit a segfault and apport blocked stuff while processing the issue...
[12:12] <Mirv> sil2100: https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/sdk_add_libthumbnailer0/+merge/189287
[12:13] <sil2100> Mirv: done!
[12:14] <Mirv> sil2100: thanks!
[12:49] <Trevinho> seb128: yes, I saw that warning and it's just fine...
[12:49] <Trevinho> seb128: the fact is that we ask for the same name in multiple places, the first which arrives takes it
[12:50] <Trevinho> seb128: and we need to keep that way since some component are optional
[12:51] <Trevinho> seb128: ah, I misread... that's related to object registration... That's fine as well, basically we delay the obj registration on bus until we don't have a valid connection...
[13:03] <seb128> Trevinho, right, thanks
[13:08] <Trevinho> seb128: I've a question for you... Have you read around reports of not-working scroll areas (such as gedit or evolution mail composer) with mouse scroll wheel (they work with touchpad!)?
[13:08] <seb128> Trevinho, no I didn't, and I use all day long and didn't notice any issue there
[13:09] <Trevinho> seb128: so I'm unlucky.... THat's really weird... No scroll with mouse, but it works with touchpad... and it's the only place
[13:09] <Trevinho> seb128: couldn't be due to the usage of smooth scrolling not supported by my device?
[13:09] <seb128> Trevinho, did you try in gtk3-demo? could be in gtk3 textview widgets only?
[13:10] <Trevinho> seb128: not yet
[13:11] <mterry> attente, what do we need to release the indicator-stack?  Is it a manual button push or is there a problem with the autolanding for the stack, like tests failing?
[13:11] <seb128> mterry, you should ask sil2100 and Mirv about landing
[13:12] <mterry> sil2100, Mirv: ^ :)
[13:12] <sil2100> mterry: we just did the landing of indicators, does anything else need landing than just the indicators themselves?
[13:12] <seb128> mterry, https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=indicator
[13:12] <mterry> sil2100, oh, I guess they haven't hit saucy yet
[13:12] <seb128> mterry, I guess you want to nag -release then
[13:13] <sil2100> mterry: yes, they're in the unapproved queue actually
[13:21] <Trevinho> seb128: so, it doesn't work in any text widget... but also neither in the gtk3-demo app itself: so I can't scroll on the sidebar, in the source code or in the Info tab
[13:22] <Trevinho> seb128: ah, no sorry the sidebar works
[13:22] <Trevinho> (not when unfocused, though as it used to be)
[13:22] <seb128> Trevinho, is that only under unity?
[13:22] <Trevinho> seb128: let me try to switch
[13:31] <seb128> sil2100, mterry: could you please review https://code.launchpad.net/~seb128/gnome-control-center-unity/swap-color-use-gdkcolor/+merge/189309 , it's an easy one
[13:32] <seb128> sil2100, we are going to need g-c-c-unity published as well since we didn't have any landing for it since we changed the naming scheme and the raring-updates version is newer than the saucy one, which is going to create upgrade issues
[13:33] <sil2100> seb128: looking
[13:34] <Trevinho> seb128: not in a guest session... maybe i've messed up mine :/
[13:34] <sil2100> seb128: ok, add it to the Landing Asks, I'll pick it up and release anyway
[13:34] <seb128> Trevinho, could be a setting causing problems :/
[13:34] <seb128> sil2100, thanks, do we need landing ask for non touch code?
[13:35] <seb128> sil2100, that's a gnome-control-center fix, e.g desktop only
[13:35] <ogra_> only if it touches touch
[13:35] <seb128> ogra_, it doesn't, it's a gnome-control-center panel :p
[13:35] <ogra_> for other stuff the release team ius responsible as usual
[13:42] <seb128> tkamppeter_, bregma: your login issue is https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1036830 and should be fixed with https://code.launchpad.net/~robert-ancell/lightdm/handle-corrupt-xauthority/+merge/188256
[13:42] <ubot2> Launchpad bug 1036830 in lightdm (Ubuntu) "Can't log in unless remove .Xauthority or use gdm" [Undecided,Confirmed]
[13:42] <bregma> huzzah
[13:43] <sil2100> seb128: I wonder ;) Not really sure personally if we use the Landing Asks only for things related to touch or to overall now, I'm always confused
[13:43] <seb128> sil2100, ogra said only touch
[13:43] <sil2100> seb128: then let's skip that indeed - is everything merged in already that needs release?
[13:44] <seb128> sil2100, no, I need https://code.launchpad.net/~seb128/gnome-control-center-unity/swap-color-use-gdkcolor/+merge/189309 review/approved by you or mterry
[13:45] <sil2100> I'll install it and test now that it's built
[13:46] <seb128> sil2100, ok, I already that here, basically open the appearance capplet, go to color, pick a horizontal or vertical 2 color option, pick 2 colors, see that it does the effect on the background, click the swap button, see that it works
[13:47] <seb128> mterry, hey, ^ if you want to do an easy review for me (that's the same gdkcolor fix I did some months ago, but in another place of the code I forgot to change back then)
[13:47] <seb128> oh, you just did
[13:47] <seb128> mterry, thanks ;-)
[13:47] <seb128> sil2100, mterry code approved, so we should be good ;-)
[13:48] <seb128> sil2100, and I see you approved as well
[13:48] <seb128> rock on ;-)
[13:49] <sil2100> Approved!
[13:49] <sil2100> Let's get it merged and released ;p
[14:06] <bregma> mterry, I'd like to branch and release upstream unity-greeter 13.10.3 and then bump trunk to 14.01 ... any objections?
[14:07] <Trevinho> seb128: about that scrolling issue, i've also tried to log on gnome flashback session...and.... if I run it after logging out from the unity one then it doesn't work, but if I select it as my first session after boot it does work
[14:08] <Trevinho> seb128: so, do you have any idea what could be set wrong in that unity session (not pribably much unity related)?
[14:08] <Trevinho> as the unity guest session work as expected
[14:17] <seb128> sil2100, and the change is merged in trunk, so should we go with the new build
[14:17] <seb128> Trevinho, no idea, maybe ibus?
[14:17] <seb128> that would be weird though
[14:18] <seb128> Trevinho, log out, go to a vt, check what processes might still be running for your user?
[14:19] <Trevinho> ok, I'll check it... since it must be saved on something that is volatile..
[14:20] <sil2100> seb128: ok, let me spin it on
[14:24] <mterry> bregma, I just pushed 13.10.3 to saucy, so yeah, bump trunk
[14:26] <tkamppeter> seb128, thanks, is this fix already in Saucy?
[14:27] <seb128> tkamppeter, no it's not
[14:28] <tkamppeter> seb128, will it get in soon (next lightdm?)?
[14:32] <bregma> mterry, am I correct in believing unity-greeter does not have any CI or autolanding?
[14:36] <mterry> bregma, it does have autolanding, but yesterday I got in the bad habit of uploading some small fixes without it, if that's what you're looking at
[14:36] <bregma> naughty boy
[14:43] <seb128> tkamppeter, next week most likely, but you can probably build/try trunk if you want to confirm it fixes your issue
[15:06] <seb128> bregma, is christownsend  off today?
[15:06] <bregma> seb128 yes
[15:06] <seb128> bregma, hum, ok
[15:08] <seb128> bregma, I was looking at https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1201405 but I can't reproduce the issue
[15:08] <ubot2> Launchpad bug 1201405 in gsettings-desktop-schemas (Ubuntu) "[regression] Wall: keyboard bindings for 'Move up & Move down' are being set to "super+prior & super+next'" [High,In progress]
[15:09] <seb128> bregma, do you know if that's randomly happening?
[15:09] <seb128> bregma, I tried with a daily iso in a vm or with a guest session on my work machine,ctrl-alt-up/down works
[15:09] <bregma> seb128, we've never seen it happen
[15:10] <seb128> ok, the description made it seems like it would happy for everyone
[15:25] <sil2100> seb128: g-c-c-u published!
[15:25] <tkamppeter> seb128, the patch fixes the problem. Thank you very much!
[15:25] <Laney> Why do we patch some extra methods into org.gnome.SessionManager?
[15:37]  * Laney starts a T-cycle things to do list
[15:37] <Laney> they seem unnecessary now
[15:50] <seb128> sil2100, great, thanks!
[15:50] <seb128> tkamppeter, thanks for confirming!
[15:50] <seb128> Laney, what methods?
[15:50] <Laney> RequestShutdown and RequestReboot
[15:50] <seb128> Laney, T is nice, but we are not done yet with bug fixing for S :p
[15:50] <Laney> I know
[15:50] <seb128> Laney, I think chrisccoulson added those back in the days, not sure why now
[15:50] <Laney> that's why it's a to do list and not things i'm doing now
[15:50] <Laney> :P
[15:51] <Laney> I think at the time g-session didn't have anything to do that
[15:51] <seb128> https://launchpad.net/ubuntu/+source/gnome-session/2.26.0svn20090408-0ubuntu2
[15:51] <Laney> yeah, saw it
[15:52] <Laney> man we had a lot of arches back then
[15:52] <chrisccoulson> blast from the past
[15:52] <Laney> it still exists!
[15:52] <chrisccoulson> i was younger than 30 when i did that. true story!
[15:53] <seb128> Laney, chrisccoulson: https://lists.ubuntu.com/archives/ubuntu-devel/2009-April/028102.html
[15:53] <seb128> that has the explanations
[15:55] <Laney> man
[15:55] <Laney> you ubuntu archaeologist
[15:55] <seb128> lol
[15:56] <seb128> the good old times, when chrisccoulson was still a desktopers
[15:56] <chrisccoulson> hah :)
[15:57] <robru> seb128, what? i didn't make any changes to notify-osd
[15:57] <seb128> robru, you dropped our Ubuntu diff when you inlined the packaging
[15:58] <robru> seb128, when was that? that must have been forever ago, i don't even remember it
[15:58] <seb128> robru, yeah, it's almost a year ago
[15:59] <seb128> nov 2012
[15:59] <robru> seb128, hah, wow. so what problem is happening now?
[15:59] <Laney> turned out to not be to do with that
[15:59] <seb128> robru, the problem was not due to that
[15:59] <robru> ah, ok ;-)
[15:59] <seb128> robru, I just mentioned that in case
[16:00] <robru> seb128, so anyways, powersaving works fine on a guest account, and also in the VT! what dotfile can possibly be in my account that breaks powersaving??
[16:00] <seb128> robru, I noticed the change earlier this year, and discussed it with didrocks, but we decided it was not creating issues to not have it so we didn't add it back
[16:00] <seb128> robru, I would recommend to dump the gsettings config of the g-s-d power plugin and compare the values
[16:00] <seb128> maybe some gsettings key in there
[16:01] <seb128> robru, e.g "gsettings list-recursively org.gnome.settings-daemon.plugins.power > keys"
[16:01] <seb128> robru, do that for your user and guest and diff the files
[16:01] <robru> seb128, how do I do that? I looked at it with dconf-editor and it claimed there was no schema available (but i checked; of course the schema is installed, otherwise everything would crash without it)
[16:03] <robru> seb128, http://paste.ubuntu.com/6192824/ can this be it??
[16:04] <seb128> robru, shouldn't
[16:04] <seb128> robru, that's the only diff?
[16:04] <robru> seb128, yeah!
[16:05] <seb128> robru, you might want to just dump the whole db (e.g drop the org.gnome.settings-daemon.plugins.power) argument
[16:05] <seb128> robru, thank diff and grep for anything that contains power dpms, suspend etc
[16:05] <seb128> thank->then
[16:05] <robru> seb128, ok. in a meeting now, will try that shortly
[16:05] <robru> seb128, thanks
[16:06] <seb128> robru, yw
[16:35] <sil2100> robru: hello man!
[16:36] <sil2100> robru: could you take a look at this branch here? Make sure it makes sense, since there are REALLY minor nit-picks
[16:36] <sil2100> robru: https://code.launchpad.net/~sil2100/ubuntu-settings-components/small_packaging_mods/+merge/189368
[16:36] <sil2100> robru: since I think you did the packaging, and it's good ;)
[16:36] <robru> sil2100, yeah, sure
[16:36] <sil2100> I go now, have a nice weekend
[16:37] <robru> sil2100, ok, you as well
[16:38] <seb128> sil2100, thanks, you as well!
[16:38] <robru> sil2100, wait, still around?
[16:38] <robru> sil2100, why did you change the boilerplate "if you arent' a memeber..." text? that is the same in all daily released packages...
[16:39] <sil2100> robru: actually, the 'trends' changed ;)
[16:39] <Laney> what is ubuntu-settings-components?
[16:39] <sil2100> robru: it's a nitpick, but we try to get things this way from now on, check: https://wiki.ubuntu.com/DailyRelease/InlinePackaging (as it got modified)
[16:39]  * Laney perks up
[16:39] <robru> sil2100, so we have to change that for all of them? actually I like this new boilerplate, since you can copy & paste without having to change the team name
[16:40] <sil2100> robru: indeed! I think we don't have to, we might do that 'by chance' if you make some other modifications, but I would say it doesn't make sense to change that on purpose
[16:40] <sil2100> robru: I'm using this for new components for now ;)
[16:40] <sil2100> See you guys!
[16:40] <robru> sil2100, ok ok, good night!
[16:42] <robru> Laney, I don't actually know! ;-)
[16:42] <Laney> haha
[16:43] <robru> Laney, I just package it ;-)
[16:45]  * Laney eyes GunnarHj
[16:45] <Laney> you're supposed to wait for FFes to be accepted before uploading :P
[16:49] <mitya57> Laney: any update on g-s-d shortcuts stuff?
[16:50] <Laney> mitya57: darkxst is going to fix the patch
[16:51] <mitya57> Laney: ah, right, and what about notify-osd then?
[16:51] <Laney> don't know what to do
[16:52] <Laney> I uninstalled it
[16:52] <mitya57> :p
[16:52] <mitya57> why don't you like what I suggested (AutostartCondition=GNOME3 unless-session gnome)?
[16:53] <Laney> that's what it has
[16:53] <Laney> it just means that it autostarts on all non-shell sessions
[16:53] <Laney> i.e. no way to get osd on those if you have n-daemon installed
[16:54] <mitya57> ah, and your session is not managed by gnome-session?
[16:54] <Laney> it is
[16:54] <Laney> but it's called gnome-xmonad
[16:54] <Laney> so you get autostarted
[16:55] <mitya57> so notification-daemon has that AutostartCondition?
[16:55] <Laney> sure does
[16:55] <mitya57> it's probably wrong
[16:56] <Laney> what else would you have?
[16:56] <mitya57> I think on GNOME sessions we want either notify-osd or nothing
[16:56] <robru> seb128, grepping through gsettings for power/suspend/dpms, i just don't see anything like that.
[16:56] <Laney> no notifications?
[16:56] <Laney> that would be a bit bad
[16:56] <mitya57> nothing=managed by gnome-shell
[16:57] <Laney> we're talking about non-shell gnome sessions
[16:57] <Laney> all I can think of is a wrapper to exit if the dbus service file exists
[16:58] <Laney> then you get osd if it's installed and can't force daemon
[16:58] <Laney> don't know if that matters
[16:59] <robru> seb128, wait, in ...plugins.power, I have three keys that don't seem to be part of the schema. idle-dim-battery, sleep-display-ac, and sleep-display-battery. could those have caused this?
[17:01] <mitya57> Laney: we can make notification-daemon recommend notify-osd, this way notify-osd will be present on all environments that depend on notification-daemon
[17:02] <mitya57> notify-osd is anyway a successor for notification-daemon, and the latter is kind of abandoned
[17:02] <Laney> it's a part of gnome flashback
[17:03] <Laney> i don't think we could do anything as aggressive that
[17:03] <Laney> as that
[17:03] <seb128> robru, could be, but weird if they are not in the schemas, that shouldn't be possible
[17:04] <mitya57> last commit 2012-09-03
[17:04] <Laney> talk to the ubuntu-gnome guys
[17:04] <mitya57> I don't know any person that will prefer n-d to notify-osd
[17:04] <Laney> it's their thing really
[17:04] <mitya57> darkxst: ^
[17:04] <robru> seb128, dunno, do you have those keys? dconf-editor says 'no schema' when I click on them, but other keys in that same plugin have a schema. my guess would be that the schema changed, but i still have those keys lying around from before
[17:04] <seb128> Laney, they don't use it, gnome-shell has its own built in notifications
[17:05] <Laney> the flashback session does
[17:05] <Laney> I assume they care about that at least a bit
[17:05] <seb128> robru, oh, you didn't say you were using dconf(-editor), those are leftover keys indeed
[17:05] <mitya57> In Ubuntu the flashback session did always use notify-osd
[17:05] <seb128> robru, it's just that gsettings' utility shouldn't list anything that doesn't have a schemas
[17:05] <robru> seb128, so are they harmless?
[17:05] <seb128> robru, I though you were still using it/reading the diff
[17:05] <seb128> robru, yes, they can't really be used from code if they don't have a schemas
[17:05] <robru> seb128, oh, no, couldn't find anything in the diff, so went poking with dconf-editor ;-)
[17:05] <seb128> robru, they got deprecated in g-s-d 3.8
[17:06] <robru> ah
[17:06] <robru> seb128, well, I am totally stumped. I guess when saucy is released I will just format & reinstall.
[17:07] <seb128> robru, you said it works in a guest session? how formatting/reinstall is going to improve thing?
[17:07] <seb128> robru, if the issue is in your user profile, just create a new user and migrate datas over
[17:07] <seb128> robru, no need to reinstall for that
[17:07] <robru> seb128, well, I meant to imply that erasing my account and starting fresh would be part of that ;-)
[17:07] <mitya57> ok, I agree that adding a Recommends: will be too agressive for Saucy
[17:07] <seb128> well, that's the only part you need
[17:07] <robru> seb128, heh, true
[17:08] <seb128> the format/reinstall is an old win habit
[17:08] <robru> seb128, true. I should run debsums and make sure my system is in good shape ;-)
[17:09] <mitya57> Laney: as a temporary solution we can put "unless-session gnome, gnome-flashback, gnome-flashback-compiz" in n-d
[17:10] <mitya57> (does gnome-session support a syntax like that?)
[17:10] <mitya57> that will at least fix the regression for flashback users
[17:10] <Laney> no, sadly not
[17:10] <Laney> I think the bug might be that flashback gives you daemon
[17:11] <Laney> looking at its changelog it's supposed to be Ubuntu-ish
[17:11] <mitya57> "I think the bug might be that flashback gives you daemon" — what do you mean by that?
[17:11] <Laney> it depends on it
[17:11] <Laney> but that is probably not in line with what it is supposed to be
[17:12] <seb128> robru, you might want to run gnome-settings-daemon --debug (after stopping the running instance)
[17:12] <seb128> robru, https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=5c0eac4a1c8b4a891d2e45a6fc32e24d873bef6a suggests there is debug code in the power source
[17:12] <seb128> robru, you might get some useful info out of it
[17:12] <robru> seb128, ahhh, thanks
[17:21] <Laney> EOW for me
[17:21] <Laney> have a good weekend everyone!
[17:23] <mitya57> Have a great weekend too!
[17:23] <desrt> Laney: peace out, dude!
[17:27] <seb128> Laney, thanks, you as well!
[17:46] <desrt> seb128: took your advice and wrote back to the xdg list
[17:47] <desrt> this problem really is only limited to the mimeapps.list
[17:47] <desrt> which is a stupid stupid file to begin with
[17:50] <seb128> desrt, ok, I'm going to read that a thread a bit later (maybe tomorrow in the train if I get bored)
[17:50] <desrt> seb128: going on a trip?
[17:50] <seb128> desrt, going to Lyon for didrocks' weeding
[17:50] <desrt> ah right :)
[21:16] <Laney> hmm
[21:16] <Laney> why don't I have a network indicator?
[21:17] <alesage> Laney is indicator-network-service running?
[21:17] <Laney> alesage: no
[21:17] <Laney> isn't that not the desktop one though?
[21:18]  * alesage is in the wrong channel
[21:21] <Laney> I get it in unity under a guest session
[21:21] <Laney> but not in my panel session
[21:30] <Laney> hmm
[21:30] <Laney> I can run nm-applet manually to get it
[21:32] <Laney> ah
[21:32] <Laney> https://launchpadlibrarian.net/149822263/network-manager-applet_<IP_ADDRESS>-1ubuntu2_<IP_ADDRESS>-1ubuntu3.diff.gz
[21:32] <Laney> darkxst: ^
[21:32] <Laney> can that be an AutostartCondition instead?
[21:32] <darkxst> Laney, the wrong patch got uploaded ;(
[21:33] <Laney> what's the right one?
[21:34] <darkxst> the second one in Bug 1189309, but needs to be rebased
[21:34] <ubot2> Launchpad bug 1189309 in network-manager-applet (Ubuntu) "nm-applet crashed with SIGSEGV in gtk_status_icon_set_visible()" [Medium,Fix released] https://launchpad.net/bugs/1189309
[21:34] <Laney> ok
[21:35] <darkxst> I had be meaning to fix that one, but forget all about it!
[21:35] <Laney> can you re-forward it back to gnome?
[21:35] <Laney> they have it as just NotShowIn
[21:36] <darkxst> Laney, sure
[21:36] <Laney> ty
[21:37]  * Laney tries the rebase
[21:50] <Laney> yeah that works
[21:57] <Laney> darkxst: uploading
[21:59] <darkxst> Laney, thanks, I will forward upstream in a bit
[21:59] <Laney> cool, thank you


[00:52] <_mup_> Bug #996857 was filed: Local environment doesn't require opening ports <juju:New> < https://launchpad.net/bugs/996857 >
[01:30] <dpb_> I'm trying to make a charm that does some deployment testing, i.e., install from a source, deb, or similar.  How should I get the bundle over to the server in the charm?  The bundle is local to me when I'm running juju deploy.
[01:50] <marcoceppi> dpb_: what do you mean by the bundle?
[02:07] <jsalisbury> Anyone available for a quick juju deploy question?
[02:09] <jsalisbury> I'm trying to use a local repository instead of the juju store, but I get this:
[02:09] <jsalisbury> http://pastebin.ubuntu.com/977122/
[02:19] <avoine> jsalisbury: juju -v deploy --repository=/home/jsalisbury/juju/charms local:kernel-build
[02:19] <avoine> jsalisbury: and you must put the charms in a directory named with the ubuntu version
[02:19] <avoine> like precise or oneiric
[02:20] <jsalisbury> avoine, awesome, that was it!  I was missing the local:kernel-build
[02:20] <jsalisbury> avoine, this may need to be updated:
[02:20] <jsalisbury> https://juju.ubuntu.com/docs/drafts/charm-namespaces.html?highlight=juju%20deploy%20local
[02:21] <jsalisbury> I doesn't have the local:
[02:23] <dpb_> marcoceppi: Like a private build a piece of software.  a private deb.  tar.gz file, etc.
[02:27] <dpb_> marcoceppi: what I'm really wanting is to be able to test deployment from my checkout on my workstation.  I can do that with a cloud instance, but I wanted to do it through juju.
[02:28] <dpb_> All I need is a way to scp a file over there as part of charm.
[02:32] <jsalisbury> One additional question.  Am I using the --config option correctly:
[02:32] <jsalisbury> http://pastebin.ubuntu.com/977144/
[02:34] <dpb_> jsalisbury: cat out your config file if you can.
[02:34] <dpb_> jsalisbury: I can use that option, so it may be something with your file
[02:36] <jsalisbury> dpb_, This is it:
[02:36] <jsalisbury> name: kernel-build
[02:36] <jsalisbury> summary: <This charm can be used to compile the Ubuntu kernel.>
[02:36] <jsalisbury> description:
[02:36] <jsalisbury>   <Multi-line description here>
[02:36] <jsalisbury> options:
[02:36] <jsalisbury>    release:
[02:36] <jsalisbury>     default:precise
[02:36] <jsalisbury>    arch:
[02:36] <jsalisbury>     default:amd64
[02:36] <jsalisbury> ~
[02:36] <jsalisbury> This is my first charm, so I may have set this up wrong ;-)
[02:37] <dpb_> jsalisbury: oh I see what you are doing... --config is for specifying configuration options *into* your charm
[02:37] <dpb_> jsalisbury: you probably don't need it if you are just getting going
[02:37] <jsalisbury> dpb_, yes, I need to supply the release and arch
[02:38] <jsalisbury> dpb_, That tells my script which kernel to build
[02:38] <dpb_> jsalisbury: ah, ok.  ya, it would be used for that purpose then.
[02:38] <jsalisbury> dpb_, For now, I can just hardcode it to get it working :-)
[02:38] <dpb_> jsalisbury: let me give you an example that I have been doing.
[02:39] <jsalisbury> dpb_, cool.  In my script I do this:
[02:39] <jsalisbury> RELEASE=`config-get release`
[02:39] <jsalisbury> ARCH=`config-get arch`
[02:42] <dpb_> jsalisbury: http://pastebin.ubuntu.com/
[02:42] <dpb_> jsalisbury: http://pastebin.ubuntu.com/977157/
[02:43] <dpb_> jsalisbury: so, you need two files... one called "config.yaml" in your charm root folder
[02:43] <dpb_> jsalisbury: one you pass in with the params
[02:44] <jsalisbury> dpb_, ok, so I need a metadata.yaml with the basics.  Then create a second file named config.yaml with the config options
[02:44] <dpb_> jsalisbury: actually, these go in "config.yaml" in your root dir
[02:45] <dpb_> jsalisbury: metadata is separate and distinct
[02:46] <dpb_> jsalisbury: then in your charm, you use "config-get name" to retrieve a param called "name"
[02:47] <jsalisbury> dpb_, awesome I'll give it a try
[02:47] <dpb_> jsalisbury: cool. :)  This has worked for me.  I'm using the PPA version of juju, btw.
[02:47] <jsalisbury> dpb_, thanks for the help!
[02:47] <dpb_> jsalisbury: yw
[04:52] <marcoceppi> dpb_: Any file that's in the charm room will be included in the deploy, so you can copy items you want to test on to the charm, then deploy, and when you need to interact with them all of the hooks CWD are the root of the charm. so if you have this in a folder called "foo" in the charm you could just do foo/<whatever> to manipulate it
[05:04] <bkerensa> SpamapS: so I was still having issues with lxc local testing but I made the fixes
[05:04] <bkerensa> for locker ^
[05:35] <flepied> SpamapS, naxsi is WAF: http://code.google.com/p/naxsi/
[13:26] <koolhead17> anyone awake
[13:32] <SpamapS> koolhead17: just me :)
[13:32] <SpamapS> flepied: naxsi looks really cool btw
[13:32] <koolhead17> SpamapS, good morning :)
[13:35] <flepied> SpamapS, I don't fully master naxsi, it was just another try to do a charm ;-)
[13:36] <SpamapS> flepied: are you at UDS? Did we meet and I didn't realize it?
[13:36] <flepied> SpamapS, no I'm in France ;-)
[13:37] <SpamapS> flepied: ahh ok. :)
[13:39] <SpamapS> flepied: I think imbrandon is working on an nginx charm, naxsi might be an interesting add-on to that
[14:08] <flepied> SpamapS, I think it's not an addon to nginx in term of packaging
[14:09] <flepied> nginx is included in the naxsi package
[14:28] <SpamapS> flepied: It might be an addon for the charm
[14:28] <SpamapS> as in.. something you can turn on to increase security
[15:32] <SpamapS> marcoceppi: Hey, I tried my branch, with our internal "canonistack" and S3.. it worked fine
[15:32] <SpamapS> $
[15:33] <marcoceppi> SpamapS: interesting, I'll have to give it a try again, maybe using a different AWS account
[15:35] <marcoceppi> If this does work, will it land in the core? or forever be a branch?
[15:35] <SpamapS> marcoceppi: I hope we can get it into core
[15:35] <SpamapS> marcoceppi: at least as a stop-gap until we can do the right thing and de-couple storage from compute
[15:35] <marcoceppi> The second it does let me know and I'll update the Ask Ubuntu question and start pushing it out
[15:36] <SpamapS> in much the same way libcloud does
[15:36] <marcoceppi> I agree, an eventual de-coupled structure would be great
[15:37] <marcoceppi> actually, it would be sweet if I could just say USE THIS FOR THE COMPUTE, USE THIS FOR STORAGE, and have storage providers like dropbox, s3, u1, etc
[15:37] <nathwill> +1
[15:38] <marcoceppi> Though, native OSAPI would be good too ;)
[15:39] <SpamapS> marcoceppi: right, OSAPI does not define swift though. ;)
[15:39] <marcoceppi> SpamapS: http://www.nooooooooooooooo.com/
[15:39] <SpamapS> hp-cloud: { type: ec2, storage-type: swift }
[15:40] <marcoceppi> Oh, that's cool then
[15:40] <SpamapS> thats kind of how I see it working
[15:40] <SpamapS> and then have flavors that extend and default to things, so eventually hp-cloud: { type: hpcloud } would be short hand for the above.
[15:42] <marcoceppi> +1 IMPLEMENT ALL THE THINGS
[15:48] <SpamapS> we need to dive into the review queue tonight
[15:50] <SpamapS> actually there's no sessions I need to care about until 11:00
[16:04] <marcoceppi> SpamapS: I'd be be happy to dive in to the review queue, tomorrow <3
[16:04] <jcastro> hah, cute!
[16:05] <marcoceppi> Or at least after I finish ze charms
[16:06] <SpamapS> jcastro: thanks for +1'ing imbrandon. :)
[16:06] <SpamapS> imbrandon: welcome to charmers!! :)
[16:06] <SpamapS> GET REVIEWIN!
[16:06] <jcastro> http://jujucharms.com/~david-duffey/precise/ddclient
[16:07] <jcastro> isn't that awesome?
[16:07] <jcastro> ok from my count we're up to 17 entrants
[16:07] <marcoceppi> +3 from me in an hour
[16:07] <marcoceppi> or a few hours
[16:08] <marcoceppi> Wait, charms or entrants?
[16:08] <SpamapS> oh snap
[16:08] <SpamapS> thats awesome
[16:09] <marcoceppi> SpamapS: I've got a few questions about -r and relation-(get|set)
[16:09] <SpamapS> marcoceppi: fire away. Also if you're in 205 we can just have a G+ hangout w/ the room. :)
[16:10] <marcoceppi> SpamapS: I am in the room! that would be sweet
[16:10] <marcoceppi> the commands failed yesterday: relation-get private-address -r unit/# (literally translated to relation-get private-address -r gluster/2) and it failed out
[16:10] <marcoceppi> what format does -r expect?
[16:10] <marcoceppi> We're pretty light in the room now, but if we start getting a lot of questions I'll put your face on the wall
[16:11] <marcoceppi> SpamapS: also, I poked at the nginx reverseproxy and haproxy charm hooks, it looks like they were using relation-get private-address - unit/#
[16:12] <marcoceppi> Am I missing what the -r does, man pages are a little light on documentation :)
[16:13] <SpamapS> marcoceppi: -r allows you to reference a relationship from any context
[16:13] <SpamapS> marcoceppi: so you can run relation-set from a cron job for instance
[16:14] <jcastro> SpamapS: ok fixed.
[16:15] <jcastro> SpamapS: juju charm and juju contributions are the same as other membership requirements
[16:15] <SpamapS> marcoceppi: sent you a G+ invite
[16:15] <jcastro> so, interacting with the community, sustained contributions, etc.
[16:15] <jcastro> it counts the same as anything else
[16:15] <SpamapS> jcastro: sweet
[16:21] <marcoceppi> SpamapS: so what would an example of a -r value
[16:23] <SpamapS> marcoceppi: anything that 'relation-ids' spits out
[16:23] <SpamapS> marcoceppi: or that has arrived in $JUJU_RELATION_ID in a hook
[16:23] <marcoceppi> SpamapS: I wish i had a second laptop, Otherwise people will see you and you'll be staring at me the whole time
[16:23] <SpamapS> marcoceppi: so for instance, in joined, you might store $JUJU_RELATION_ID somewhere, and then re-use it to push values in later when a long running background job is finished.
[16:23] <marcoceppi> SpamapS: interesting that's what I currently do
[16:24] <koolhead17> marcoceppi, will you have sometime  today? i would like to sit with you and know what all new things have got integrated with juju. i missed last evening session :(
[16:24] <koolhead17> i want to write a simple blog putting LXC as well as ec2 in mind
[16:26] <SpamapS> marcoceppi: if you run outside the juju process, you also need to save off the socket and stuff. Check the env for the right JUJU_* variables
[16:26] <marcoceppi> SpamapS: I keep a directory or $JUJU_RELATION_ID as the file name, and it's remote address in there. So to build that I'm looping through relation-list and performing some simple tests, etc in the first few lines. It's the relation-get portion that fails http://paste.ubuntu.com/978195/
[16:26] <marcoceppi> SpamapS: It's running inside a relation-changed hook
[16:26] <marcoceppi> s/directory or/directory of/
[16:27] <SpamapS> ah ok
[16:27] <marcoceppi> the -r command fails
[16:27] <SpamapS> yeah thats wrong
[16:27] <SpamapS> you're passing unit names
[16:27] <marcoceppi> bahhhhhh
[16:27] <marcoceppi> So relation-ids is what I want to loop against?
[16:27] <SpamapS> Youmay just mean 'relation-ids' there.. but I'm not entirely sure
[16:28] <jimbaker> SpamapS, marcoceppi - you want to use relation-ids
[16:28] <SpamapS> You'll have a relation ID per *service* you are related to
[16:28] <marcoceppi> SpamapS: jimbaker gotchya!
[16:28] <SpamapS> so if you want to then also loop through the units inside each service you're related to, you need another loop for relation-list
[16:31] <marcoceppi> SpamapS: awesome jimbaker gave me the lowwwwww down
[16:31] <marcoceppi> KEEPING CALM, AND CARRYING ON
[16:34] <SpamapS> werd
[16:46] <SpamapS> reviewed ddclient
[16:49] <SpamapS> DING DING promulgated SOLR!
[16:50] <marcoceppi> Woo!
[17:13] <m_3_> SpamapS: bumped service-stacks to not conflict with bug triage
[17:14] <SpamapS> m_3_: thank you!
[17:14] <SpamapS> m_3_: IMO stacks is not something we can talk about this cycle anyway. :(
[17:15] <SpamapS> m_3_: unless we're going to make a straw-man implementation in jitsu
[17:15] <m_3_> SpamapS: yeah, I was more gonna ask if it was a core feature or not
[17:17] <SpamapS> m_3_: no features this cycle
[17:18] <SpamapS> The resource map discussion was even a bit reaching. :-/
[17:18] <m_3_> gotcha
[17:18] <SpamapS> Important to discuss, but I can't see it getting implemented.
[17:18] <m_3_> what about tomorrow?  any we should combine/rearrange/delete?
[17:19] <m_3_> SpamapS: when you get a chance... no hurry, just wanna give michelle as much notice as possible
[17:20] <SpamapS> yeah I'll review tomorrow
[17:21] <m_3_> integration's still worth keeping imo
[17:21] <m_3_> but yeah, I'll let you listen away :)
[17:44] <SpamapS> heh.. we need an environment option.. "spare machines"
[17:44] <SpamapS> I've taken to always having one machine deployed using the 'ubuntu' charm
[17:44] <SpamapS> just sitting there, waiting
[17:46] <SpamapS> marcoceppi: you know what would be awesome in charm-helper-sh? If you could build in support for scraping MD5's from sourceforge right into ch_file_get
[17:46] <marcoceppi> SpamapS: I tried that, I ended up bailing to use php :\
[17:46] <marcoceppi> Since you have to consume an XML file
[17:47] <marcoceppi> Unless there's another way to get MD5 sums from SF
[17:48] <SpamapS> marcoceppi: perhaps that is worth putting in a little helper script (I'd suggest python, not php) that gets included w/ charm helper tho
[17:48] <marcoceppi> SpamapS: if that's okay with you, I think it'd be great
[17:49] <marcoceppi> (I agree with Python for this instead of PHP, shazzer IIRC moved my php script to python in one of his charms)
[17:50] <SpamapS> marcoceppi: part of me wants to start pushing for more charms to just embed a tarball tho
[17:50] <SpamapS> marcoceppi: when we add this mythical tagging thing.. we will be tagging most of these "download the latest" charms as non-repeatable.
[17:53] <marcoceppi> https://bugs.launchpad.net/charms/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.component-empty-marker=1&field.tag=new-charm&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.o
[17:53] <marcoceppi> mit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
[17:54] <jsalisbury> Is anyone here currently using canonistack?  I seem to be having an issue starting an instance.
[17:56] <marcoceppi> http://bit.ly/lp-charms-review-q
[18:18] <marcoceppi> SpamapS: $JUJU_RELATION_ID is what you would use against -r correct?
[18:19] <SpamapS> marcoceppi: correct
[18:33] <negronjl> SpamapS: ping
[18:34] <negronjl> SpamapS: I approved puppetmaster and puppet.  Promulgate :)
[18:35] <alex88> hello, someone tried to deploy openstack with juju?
[18:42] <negronjl> SpamapS: looking at bug https://bugs.launchpad.net/charms/+bug/996576 ( reviewing ) and I see that you have this bug assigned to you.  Are you reviewing this already ?
[18:42] <_mup_> Bug #996576: VIVO charm <new-charm> <Juju Charms Collection:New for clint-fewbar> < https://launchpad.net/bugs/996576 >
[19:29]  * popey wonders if someone could review my (first attempt - be gentle) charm, that would be lovely ☺  https://bugs.launchpad.net/charms/+bug/996361
[19:29] <_mup_> Bug #996361: Charm needed: Yacy <new-charm> <Juju Charms Collection:In Progress by popey> < https://launchpad.net/bugs/996361 >
[20:47]  * marcoceppi reviews all the charms
[21:31] <marcoceppi> Hey SpamapS if you wget an asc does it *have* to be over SSL? I assume yes, but I'm not 100% certain
[21:40]  * popey hugs marcoceppi
[21:41] <SpamapS> marcoceppi: yes it would have to be
[21:41] <marcoceppi> o/ popey got a few things for you
[21:41] <popey> oh goody
[21:41] <popey> is it massively broken? :D
[21:41] <SpamapS> marcoceppi: best to embed a trusted key in the charm
[21:41] <marcoceppi> SpamapS: that's what I figured, cool
[21:42] <SpamapS> marcoceppi: then you don't have to have https for the .asc, you just need to verify the key
[21:42] <marcoceppi> popey: not that bad! just a few key items and some nitpicks
[21:42] <popey> ok
[21:42] <popey> you gonna braindump on the bug marcoceppi ?
[21:43] <marcoceppi> popey: yeah, just finishing up my reply
[21:46] <SpamapS> just -1'd VIVO
[21:46] <SpamapS> If anybody sees Nicholas Skaggs let him know he has some TODO's waiting for him in bug 996576
[21:46] <_mup_> Bug #996576: VIVO charm <new-charm> <Juju Charms Collection:Incomplete by nskaggs> < https://launchpad.net/bugs/996576 >
[21:48] <SpamapS> Same for David Duffey for ddclient bug 996905
[21:48] <_mup_> Bug #996905: New dynamic dns charm ddclient <new-charm> <Juju Charms Collection:Incomplete by david-duffey> < https://launchpad.net/bugs/996905 >
[21:48] <popey> thanks marcoceppi
[21:52] <SpamapS> imbrandon: hey, you going to finish drupal?
[22:33] <SpamapS> 90 minutes left for the laptop contest. Anybody freaking out? ;)
[22:36] <jsalisbury> SpamapS, is there a document somewhere that explains how to configure environments.yaml to use canonistack instead of AWS or local?
[22:36] <marcoceppi> SpamapS: yes
[22:37] <SpamapS> jsalisbury: yes but Its just for Canonical people.
[22:37] <komputes> marcoceppi: Could we test my charm on Openstack: https://code.launchpad.net/~komputes/charms/precise/remote-assistance/trunk
[22:37] <marcoceppi> komputes: I can do it on AWS
[22:37]  * SpamapS will test juju against trystack soon
[22:38] <jsalisbury> SpamapS, Is there info on the internal wiki?
[22:40] <lifeless> SpamapS: I'm getting the idea that jsalisbury may be 'Canonical people' :P
[22:41] <SpamapS> lifeless: indeed, I just don't want others in here thinking we're using some secret cloud. ;)
[22:41] <SpamapS> which.. canonistack sort of is. :)
[22:42] <SpamapS> looks like there are no more juju related sessions for today
[22:43] <SpamapS> at UDS I mean
[22:43] <SpamapS> so, anybody making last minute tweaks, lets get 'er done
[22:52]  * tumbleweed has no energy left for last minute tweaks (such as all the things I actually intended to do :P )
[22:53] <SpamapS> tumbleweed: reviewing ibid right now btw :)
[22:53] <tumbleweed> UDS-exhaustion :)
[22:53] <tumbleweed> SpamapS: yeah, just saw that
[22:54] <SpamapS> tumbleweed: you should move most of the config-get stuff to config-changed
[22:54] <SpamapS> tumbleweed: so it can be changed post-install
[22:55] <tumbleweed> oh, duh
[22:55]  * tumbleweed quickly does that
[22:56] <SpamapS> tumbleweed: otherwise, it looks pretty cool. I've thought for a while that we need an IRC bot charm. :)
[22:56]  * SpamapS deploys w/ --constraint mem=64M curious if that will end up with a t1.micro
[22:58] <marcoceppi> SpamapS: I realized earlier that i collided with someone elses work
[22:59] <SpamapS> marcoceppi: gitolite?
[22:59] <tumbleweed> SpamapS: pushed, but entirely untested :)
[22:59] <SpamapS> tumbleweed: mmmm.. fresh crack
[23:06] <SpamapS> tumbleweed: another nice thing would be to open the ident port
[23:09] <SpamapS> SpamsPet: are you a real person?
[23:09] <SpamsPet> SpamapS: *blink*
[23:09] <SpamapS> SpamsPet: what is ibid?
[23:09] <SpamsPet> SpamapS: I'm afraid I have no idea
[23:10] <SpamapS> SpamsPet: you respond awfully fast
[23:10] <SpamsPet> SpamapS: What?
[23:10] <marcoceppi> SpamapS: yeah, not sure what do do about that
[23:10] <SpamapS> marcoceppi: shazz has first dibs its not his fault you forgot to follow the process :)
[23:10] <SpamapS> marcoceppi: he's still within 30 days of his last activity
[23:10] <marcoceppi> right, so mines ready for submission
[23:10] <marcoceppi> just wait it out?
[23:11] <SpamapS> tumbleweed: I'm sure you've already guessed, but SpamsPet is an ibid deployed w/ your charm :)
[23:13] <SpamapS> tumbleweed: I manually installed oidentd, and just used the juju-jitsu 'open-port' command to open port 113
[23:14] <tumbleweed> SpamsPet: hi
[23:14] <SpamsPet> lo
[23:14] <SpamsPet> tumbleweed: By the way, SpamapS on irc told me "tell tumbleweed you are a genius" 6 minutes and 27 seconds ago
[23:14] <SpamsPet> tumbleweed: By the way, SpamapS on irc told me "tell tumbleweed you are a genius on #juju" 6 minutes and 17 seconds ago
[23:15] <SpamapS> tumbleweed: also in config-changed, just take the existence check out for ibid.ini ... just overwrite it every time.
[23:15] <tumbleweed> already fixed that :P
[23:15] <SpamapS> oh good :)
[23:16] <SpamapS> hah rapid iteration eh? :)
[23:16] <tumbleweed> yeah, there are many situations where one doesn't want such a simple config
[23:16] <tumbleweed> but the hacky temporary solution is to stick a local.ini in
[23:16] <tumbleweed> I see some other charms have a way to download a config / provide it at deploy. That seems the way to go for non-trivial configs
[23:17] <SpamapS> tumbleweed: perhaps look at dotdee too
[23:17] <SpamapS> tumbleweed: it allows you to emulate .d dirs for things that don't have them.
[23:18] <SpamapS> tumbleweed: automation always gets in the way of customization. Such is the nature of the beast.
[23:18] <SpamapS> ejat: hey btw, I didn't get a c hance to say hi yesterday, but, HI!
[23:21] <tumbleweed> SpamsPet: Juju is DevOps DistilledTM
[23:21] <SpamsPet> tumbleweed: I'll remember that
[23:22] <SpamapS> negronjl: thanks for +1'ing the puppet charms. PLEASE do add things to them. I think there's a ton of interesting stuff left to do.
[23:23]  * SpamapS rings the bell twice
[23:23] <SpamapS> puppet(subordinate)/puppetmaster promulgated
[23:37] <marcoceppi> fuuuuuuuuuuuuuuuu
[23:37] <jcastro> heh
[23:37] <jcastro> running out of time?
[23:37] <marcoceppi> just realized one of my charms depends on charm-helpers and I never merged the dang code for that
[23:37] <ejat> SpamapS: its ok .. hi back
[23:39] <ejat> i guess .. i didnt have time to separate the package to make it scalable .. need to extract the package and see the create db file ..
[23:39] <SpamapS> marcoceppi: its ok to embed that in your own charm. :)
[23:39] <marcoceppi> SpamapS: yeah I am, I was just ready to start celebrating :)
[23:39] <SpamapS> marcoceppi: charm-helpers is just an efficiency play. But its more important that charms work than that they are super efficient.
[23:39]  * ejat less hope to fullfill the 5 criteria ..
[23:40] <SpamapS> jcastro: where can people look to be sure their charm is submitted to the contest btw?
[23:40] <marcoceppi> http://paste.ubuntu.com/978937/
[23:40] <ejat> marcoceppi: dont forget to donate ya dv7
[23:40] <ejat> 0/
[23:41] <jcastro> marcoceppi: http://www.quickmeme.com/meme/3p7ol1/
[23:41] <marcoceppi> jcastro: ROFL
[23:42] <ejat> :)
[23:44] <ejat> jcastro @ anyone : can u answer SpamapS Q .. so i also can look into :)
[23:45] <jcastro> SpamapS: launchpad?
[23:45] <jcastro> SpamapS: all the new-charms ones since april 26.
[23:45] <SpamapS> jcastro: so, tagged w/ new-charm, commits to a linked branch by 1700 ?
[23:45] <jcastro> yeah
[23:45] <SpamapS> ok, lets make sure to snapshot that at 1701
[23:46] <jcastro> SpamapS: why? Are you working on a list of entries?
[23:46] <SpamapS> jcastro: I want to make sure we capture it is all
[23:46] <jcastro> k
[23:46] <jcastro> so how can I do that?
[23:46] <marcoceppi> I'm guessing I can't use the gitolite one for the contest?
[23:46] <jcastro> I mean, the date time is in LP already
[23:46] <SpamapS> I'm sure we can extract it w/ the lp api .. but simple to just look at the page at the entry time
[23:46] <jcastro> oh ok
[23:46] <jcastro> right right, that's easy, I can do that.
[23:47] <SpamapS> marcoceppi: I'd -1 it pretty hard since you missed the process entirely. ;)
[23:47] <marcoceppi> Cool, so I have glusterfs and no way to show it's power :)
[23:47] <bkerensa> :(
[23:47] <bkerensa> There is no way I can finish the reddit stack charm and openphot charm by 5pm
[23:47] <bkerensa> le sigh
[23:47] <SpamapS> marcoceppi: 13 minutes to add it to wordpress ;)
[23:48] <SpamapS> marcoceppi: in that case, you can use your gitolite just to support gluster's awesomeness
[23:48] <marcoceppi> ಠ_ಠ
[23:48] <marcoceppi> okay, whew
[23:48] <ejat> ok thanks
[23:49] <SpamapS> marcoceppi: but yeah, it would have been more awesomer to have a charm that uses gluster up for consideration :)
[23:49]  * marcoceppi is the saddest
[23:49] <jcastro> 10 MINUTE WARNING
[23:49] <SpamapS> marcoceppi: contact shazzner, maybe you can get him to relinquish his claim :)
[23:49] <marcoceppi> don't think that will happen in 10 mins :\
[23:49]  * ejat ...... scratching ....
[23:54] <jsalisbury> SpamapS, thanks for reviewing my charm.  I implemented all your suggestions except using secure git or implementing some form of cryptographic verification(I'm not sure I'l be able to do that in the next 5 minutes, lol).
[23:54] <SpamapS> marcoceppi: you love me
[23:55] <marcoceppi> I wish I would have checked earlier
[23:55] <SpamapS> marcoceppi: https://bugs.launchpad.net/charms/+bug/906176
[23:55] <_mup_> Bug #906176: Gitolite charm <new-charm> <Juju Charms Collection:Incomplete> < https://launchpad.net/bugs/906176 >
[23:55] <marcoceppi> I pushed my branch and emailed him
[23:55] <marcoceppi> here's to helping
[23:55] <SpamapS> marcoceppi: I got a hold of Chris
[23:55] <marcoceppi> LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
[23:55] <SpamapS> marcoceppi: note, unassigned
[23:55] <marcoceppi> :OOOOOOOOOOOOOOOOOO
[23:55]  * marcoceppi owes SpamapS ALL OF THE BEERS
[23:56]  * SpamapS deflects at least one to shazzner
[23:59]  * popey crosses his fingers