[00:02] <davecheney> mwhudson: /me looks
[00:03] <davecheney> hmm, it was working fine up til last night
[00:03]  * davecheney steps into phone box, enables vpn
[00:04] <anastasiamac_> davecheney: i thought u were stepping into phone booth to change into ur super outfit...
[00:04] <davecheney> anastasiamac_: it's the same thing
[00:04] <davecheney> mwhudson: looks like the builder _is_ running
[00:05] <mwhudson> davecheney: hm
[00:05] <davecheney> i'll keep an eye on it
[00:05] <davecheney> the proxy might have screwed up
[00:05] <davecheney> and migth be throwing away the calls to the dashboard that report results
[00:06] <mwhudson> yummy proxies
[00:08] <davecheney> mwhudson: you saw the note about go 1.5 last night ?
[00:08] <davecheney> i'd say it'll ship in august
[00:08] <davecheney> well
[00:08] <davecheney> before september :)
[00:11] <mwhudson> davecheney: yeah
[00:12] <davecheney> mwhudson: how much of a problem will that be ?
[00:12] <mwhudson> don't know
[00:12] <davecheney> should I be talking to tim and alexis now
[00:12] <davecheney> and issuing dire warnings ?
[00:13] <mwhudson> argh i've forgotten when feature freeze is
[00:13] <davecheney> aug 20
[00:13] <mwhudson> hmm
[00:14] <davecheney> alpha 2 was yesterday
[00:14] <mwhudson> i guess that's getting close
[00:14] <mwhudson> davecheney: it might be worth getting alexis to talk to steve l about dates, yeah
[00:14] <davecheney> i can see the timeline being an issue
[00:16] <mwhudson> yeah, it's getting to 'uneasy' i think, a few notches below 'panic' or 'give up and start mowing lawns'
[00:20] <davecheney> mwhudson: done
[00:20] <davecheney> i've been here before and excessive planning and overcommunication is the path to success
[00:21] <mwhudson> definitely
[00:21] <mwhudson> talking of planning, i'll see about doing another rebuild test using real go for arm64 and ppc64le
[00:49] <davecheney> mwhudson: what was that site you used that decoded instructions ?
[00:49] <mwhudson> davecheney: https://www.onlinedisassembler.com/odaweb/
[02:04] <mwhudson> davecheney: i like the new contender for most useless bug reporter ever
[02:04] <mwhudson> (https://github.com/golang/go/issues/11957)
[02:04] <natefinch> ahh the old "it doesn't work" bug
[02:05] <natefinch> lol
[02:05] <natefinch> insane amounts indeed
[02:05] <mwhudson> perhaps not as quite as useless as the "can't bootstrap with gccgo" guy
[02:06] <natefinch> It's amazing how even people who work in development can fail to post even the most basic information about a bug.  I can't tell you how often I've had to tell even the same people in an org inside my own company to include the damn logs when reporting a bug.  It's not rocket science.
[02:08] <natefinch> Gah, people, if you're going to have a field which is a map[string]someStruct  ... you gotta explain WTF the string is
[02:09] <davecheney> yup,
[02:09] <natefinch> ...this is why I hate using maps for things which should probably just be slices... because the most important field in the whole struct *isn't in the struct*
[02:10] <davecheney> natefinch: yup
[03:24] <natefinch> lol @ omitempty on non-pointer struct fields
[04:04] <axw> natefinch: why? omitempty works for non-pointer values
[04:07] <natefinch> axw: for non-pointer struct values?  I was just seeing it not work
[04:08] <axw> natefinch: http://play.golang.org/p/Q9C5yKHhqi
[04:09] <natefinch> axw: I mean this: http://play.golang.org/p/rVw_82ZOl8
[04:10] <axw> natefinch: ah, fields of struct type. gotcha.
[04:10] <natefinch> right, sorry, didn't explain it well
[08:21] <mwhudson> davecheney: i take it back, i think this might be the most clueless reporter ever
[08:51] <alexisb> jam, thumper if you guys are watching your screens we could use you upstairs
[09:29] <thumper> hey mgz
[09:30] <thumper> mgz: the 1.24 branch didn't get blessed due to an intermittent failure on the i386 tests
[09:30] <thumper> mgz: can you just run them again to check?
[09:33] <thumper> mgz: failing that, we need someone to pick this up
[09:34] <thumper> dimitern: can you please keep on top of this?
[09:34] <thumper> it is super important
[09:37] <dimitern> thumper, ok, will see what I can do
[09:37] <thumper> dimitern: cheers
[10:08] <dimitern> thumper, by "super important" I guess you won't mind skipping that test for i386 for the time being - it looks like a timeout issue
[10:09] <thumper> dimitern: if it is obviously broken...
[10:09] <thumper> then we should not run it
[10:10] <thumper> I'm ok with skipping it on "i386" only if we can do that
[10:10] <thumper> as long as we file a bug
[10:10] <dimitern> thumper, yes we can :)
[10:10] <thumper> hopefully this test will be rewritten as part of the uniter sprint upcoming
[10:10] <dimitern> thumper, my point exactly, yeah
[10:12] <thumper> dimitern: do it!
[10:22] <katco> fwereade: how great is this, we already have james flagged as the "C" in RACI for min version
[10:29] <dimitern> thumper, done - stamp it! http://reviews.vapour.ws/r/2286/
[10:30] <thumper> dimitern: stamped
[10:31] <thumper> later folks, lunch time here
[10:31] <thumper> then we're done
[10:31] <dimitern> thumper, thanks and enjoy :)
[11:44] <thumper> hey dimitern
[11:44] <thumper> dimitern: you have been volunteered to make sure 1.24 gets blessed :)
[11:44] <thumper> we are all done here and people are stopping looking at laptops
[11:44] <thumper> I'm hoping that it will all be good
[11:44] <thumper> the only blocker would be another intermittent failure
[11:44] <thumper> fingers crossed, we're good
[11:44] <dimitern> thumper, oh is that right :)
[11:45] <dimitern> thumper, I'll keep an eye on the builds and status
[11:45] <thumper> but someone needs to hold the token :)
[11:45] <thumper> if you hit EOD, make sure someone in the US gets the token
[11:45] <dimitern> thumper, hopefully should be fine and I'd nudge it if needed
[11:45] <thumper> sound good?
[11:45] <dimitern> thumper, yes, wilco ;)
[11:45] <thumper> awesome
[11:46] <thumper> see y'all next week
[11:46] <dimitern> safe travels!
[11:46]  * thumper closes laptop
[13:21] <mup> Bug #1480298 opened: unknown object type "Charms" <blocker> <ci> <compatibility> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1480298>
[13:57] <TheMue> dimitern: in your review when I'm registering the watcher you mentioned a possible failure detection and watcher stopping. how to detect an error during registering? or did you mean when above the mapping returns an error?
[13:57] <mup> Bug #1480310 opened: dbus link request failed for service FOO: Unit name FOO is not valid. <blocker> <ci> <systemd> <wily> <juju-core:Triaged> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1480310>
[15:43] <bhundven> https://github.com/juju/juju/blob/master/container/kvm/kvm.go#L158   -- This line does not print the constraints
[15:43] <bhundven> machine-0: 2015-07-31 15:36:54 TRACE juju.container.kvm kvm.go:158 create the container, constraints:
[16:02] <bhundven> I think it's because %+v outputs multiple lines?
[16:02] <bhundven> er, %v
[16:02] <perrito666> does it? what is the ouput you get there?
[16:03] <bhundven> 08:43:32 <bhundven> machine-0: 2015-07-31 15:36:54 TRACE juju.container.kvm kvm.go:158 create the container, constraints:
[16:03] <bhundven> the next line is the next log message, and the kvm container is being created with the default constraints
[16:03] <bhundven> instead of the ones I passed.
[16:03] <perrito666> duh, I am so used to another channel that I ignore all the lines next to links
[16:05] <bhundven> I'm debugging the issue by doing: logger.Debugf("Params passing to container. Arch: %s : Memory: %d : Cores: %d : RootDisk: %d", startParams.Arch, startParams.Memory, startParams.CpuCores, startParams.RootDisk)
[16:05] <bhundven> before it parses the hardware
[16:08] <bhundven> https://bugs.launchpad.net/juju-core/+bug/1399613
[16:08] <mup> Bug #1399613: juju-core not using constraints when creating KVM  unit on maas machine <constraints> <kvm> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1399613>
[16:10] <bhundven> I've tested the issue with 1.22 through current 1.25 alpha
[16:15] <bhundven> http://paste.ubuntu.com/11974200/
[16:16] <bhundven> juju machine add kvm:0 --constraints "cpu-cores=2 mem=2G root-disk=20G"
[16:16] <bhundven> is what I'm passing
[16:34] <cherylj> anyone want to help me in crafting an error message?  I think I'm over thinking things and trying to make things way too complicated.
[16:34] <cherylj> it's for bug 1480298
[16:34] <mup> Bug #1480298: unknown object type "Charms" <blocker> <ci> <compatibility> <regression> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1480298>
[16:35] <cherylj> basically, we're using a new juju client with an older version of juju
[16:35] <cherylj> and we try to register the charm for metering, and can't since it's not supported in earlier versions of juju
[16:37] <cherylj> What I have is: "current state server version does not support charm metering" as a warning, but don't return an error.
[16:37] <cherylj> thoughts?
[16:37] <cherylj> mattyw ^^  (if you're still around)
[16:38] <mattyw> cherylj, hey hey
[16:56] <bhundven> the maas provider doesn't call CreateContainer?
[16:57]  * bhundven is stumped
[17:00] <bhundven> ah, it uses instanceBroker
[17:52] <mup> Bug #1479931 changed: Juju 1.22.6 cannot upgrade to 1.24.3/1.24.4 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Fix Released by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1479931>
[19:09] <bhundven> Well, the instanceConfig passed to CreateMachine in containers/kvm/kvm.go doesn't contain the constraints.
[19:10] <bhundven> http://paste.ubuntu.com/11975150/
[19:11] <bhundven> http://paste.ubuntu.com/11975152/
[19:17] <bhundven> iow, instanceConfig.Constraints doesn't exist
[19:58] <sinzui> cherylj: ericsnow wwitzel3 : this befuddles me. I cannot find a dupe, but it looks familar. Is this a new bug? Do we need to fix this in 1.25? https://bugs.launchpad.net/juju-core/+bug/1478762
[19:58] <mup> Bug #1478762: juju bootstrap failed to connect to environment  with error "discarding API open error"  <juju-core:New> <https://launchpad.net/bugs/1478762>
[19:58] <ericsnow> sinzui: doesn't sound familiar
[20:01] <lazyPower> natefinch-afk: status update on our convo - i have the branch built and living locally in a container. I'm looking at way to do this that would apply to any feature branches we want to track, and get those added as nightly builds, and yield a container that isnt 2gb - should have something for you by early next week say tuesdayish
[20:05] <natefinch> lazyPower: cool
[20:07] <natefinch> lazyPower: I think sinzui can point you to binaries created by the CI system that could easily be just copied wherever you need them.
[20:07] <lazyPower> so our CI is already building/archiving branches?
[20:08] <sinzui> lazyPower: Ci tests every revision, the binaries built are places in s3, and reports.vapourr.ws can list them for you
[20:08] <sinzui> lazyPower: are you interested in 1.24.4 or 1.25-alpha1?
[20:09] <lazyPower> sinzui: feature-proc-mgmt branch
[20:09] <sinzui> lazyPower: http://reports.vapour.ws/releases lists that branch and the last build tested (2928)
[20:10] <sinzui> lazyPower: http://reports.vapour.ws/releases/2928 has a link to binaries (faster than scanning the jobs)...http://reports.vapour.ws/releases/2928/binaries
[20:17] <cherylj> sinzui: it looks familiar to me too.  I can try to find if there is a dup, or if we're both going crazy
[20:18] <sinzui> cherylj: maybe I saw issues like this because of maas setup, and the bug was moved from juju-cire to maas?
[20:19] <cherylj> sinzui: I see bug 1477920 which was marked as a dup of 1321212
[20:19] <mup> Bug #1477920: juju bootstrap failed with "discarding API open error" <bootstrap> <cloud-installer> <maas-provider> <juju-core:New> <https://launchpad.net/bugs/1477920>
[20:22] <cherylj> sinzui: but I thought that thumper had done some work around that to retry the connection while bringing up the bootstrap node...  hmmm
[20:22] <cherylj> maybe I'm going crazy
[20:29] <cherylj> cmars: could you take a look: http://reviews.vapour.ws/r/2287/
[21:07] <bhundven> Well, I'm not sure what to do. It seems that this (https://code.launchpad.net/~thumper/juju-core/kvm-constraints/+merge/197815) was an attempt to fix constraints passing to kvm containers. Without being able to set constraints on the kvm I need to deploy, I can't move forward with my evaluation of juju. I've tried to figure it out on my own. \o/
[21:11]  * bhundven stops talking to rocks...
[21:48]  * perrito666 decides to test a worker with unittests and see if someone gets mad