[00:09] _thumper_: seen mramm ? [00:10] <_thumper_> davecheney: yeah [00:10] * davecheney waits on mramm for our 1-on-1 === _thumper_ is now known as thumper [02:33] davecheney: I'm trying to do a go get on github.com/andelf/go-curl and go says "cannot find package", yet it seems to work for others. Any ideas? [02:35] ok we worked it out [02:35] FFS [02:35] my GOPATH started with a : [02:35] ridiculous [03:38] bigjools: O_O!! [03:39] ahh, there is a long story about that [03:39] which isn't (all) go's fault [03:40] davecheney: I see :) [03:41] for example, did you know that PATH=$PATH:: is short hand for [03:41] PATH=$PATH:. [03:42] ! [03:43] davecheney: so when I do a perfectly reasonable line like this in my .bashrc, I am screwed then: export GOPATH="$GOPATH":/my/path [03:43] yup, that isn't awesome [03:44] that says GOPATH=.:/somethign/else [03:44] where . is the first element, and will be the target for go get [03:44] if it is of any consolation, i have fixed many of these usability problems in 1.1 [03:45] bigjools: thumper do you two have time to talk about the mongo problem ? [03:45] sire [03:45] sure even [03:46] so, latest i have is everyone is working really hard to get mongo into at least raring by 13.04 [03:46] but I think we need a backup [03:47] bigjools: what I would like to do is move from the tarball to your ppa for getting mongo for the bootstrap nodes [03:47] the current raring packaging has a bug when it tries to build with ssl, fwiw [03:47] \o/ [03:47] how about an official PPA [03:48] I just did mine as I don't trust unsigned binaries :) [03:48] bigjools: sounds fine by me, i'd really like your guidence on this [03:48] ok [03:48] the trick is we need P, Q and R, amd64 as a must [03:48] 386 and arm as a maybe [03:48] thumper was saying that the 2.2.3 build didn't work for him [03:48] shitter [03:48] 2.2.2 was defo ok [03:48] I built 2.2.3 in the same way so I dunno what's up [03:49] bigjools: how do I, or you [03:49] i think you'd be faster [03:49] get a PPA location setup so I can then reference that in the cloud init scripts ? [03:50] activate a new PPA for the juju devs? [03:50] bigjools: full disclosure, i'm a launchpad numpty [03:50] you'll have to walk me through this [03:50] heh [03:50] np [03:50] which team should own the ppa? [03:50] i think htere is a juju team now [03:50] it used to be ~gophers [03:50] perfect [03:50] but that was changed recently [03:50] * davecheney checks [03:51] bigjools: if you are not a member [03:51] i can fix that [03:51] so if you are an admin of the team you can activate a ppa for it [03:51] once you do that you can't rename the team [03:51] not sure I need to be a member [03:51] * davecheney goes to look [03:51] https://launchpad.net/~juju [03:51] ^ i can create a new ppa [03:52] on the left mid way down, yes [03:52] so I suggest making one called devel, one called staging and one called stable [03:53] or perhaps s/devel/experimental/ [03:53] then we can test packages and copy them later to the stable ppa [03:53] bigjools: sounds reasonable [03:53] i'm goig to be adding this ppa to the cloudinit script [03:53] the forms on LP are pretty self-explanatory I hope [03:54] how will having dev/stage/stable play into this [03:54] yeah then it does need a production PPA that is stable :) [03:54] ok, done devel and stable [03:54] that'll do for the moment [03:55] bigjools: also, because i'm a lp numpty, i'm not setup with all the pkg signing aparatus [03:55] easy to sort [03:55] ok [03:55] on the cmd line just type "add-apt-repository ppa:account/ppa-name" [03:56] oh yeah, i've done that side [03:56] it won't work until the 1st package is in the PPA though [03:56] but the publishing part will probably involve more steps [03:56] packaging is tricky, yes [03:56] I can help there [03:56] sweet, thanks [03:56] I suggest that once you have the experimental PPA up, you copy my 2.2.3 package into there [03:57] ok, experimental created [03:57] i copied your ppa once before [03:57] * davecheney looks [03:57] so visit my PPA's packages page [03:58] and click copy packages [03:58] then your experimental PPA will be in the destination drop down [03:58] copy to same series and copy source + binary [04:00] https://launchpad.net/~julian-edwards/+archive/mongodb [04:00] why is it always a sonofabitch to find the copy link ? [04:00] click "view packages" [04:00] it's on that page [04:00] gotcha [04:02] ok, wheels are grinding now [04:02] while that is baking i shall make a branch to use it [04:05] will be interesting to see why it fails [04:05] or at least thumper said it fails :) [04:05] bigjools: can I use copy package to change the series to quantal, etc ? [04:05] davecheney: not a good idea to go backwards [04:05] ok [04:05] davecheney: I did a 2.2.2 for quantal [04:05] it works fine [04:06] that is ok [04:06] once we get _one_ working mongo [04:06] i can use default-series to boot an environment that matches [04:06] you can promote 2.2.2 from quantal to raring [04:06] bigjools: is there anyone I should talk to about using ppa's in cloudinit ? [04:06] smoser [04:07] of course [04:07] da man [04:31] bigjools: are you on juju-dev ? [04:31] ML [04:31] davecheney: yes I think so [04:31] ok, just announced my intentions for this packaging bollocks there [04:32] please comment and/or throw fruit [04:32] seems ok [04:32] didnt' expect it to be contraversial [04:32] I don't understand juju well enough to comment really [04:33] writing the python maas provider was enough for me :) [04:33] i can give you more background [04:33] but you probably don't want to know [04:34] thumper: seen this test failure ? [04:34] ... obtained *net.OpError = &net.OpError{Op:"write", Net:"tcp", Addr:(*net.TCPAddr)(0xc200245d50), Err:0x68} ("write tcp [::1]:46014: connection reset by peer") [04:34] ... expected *rpc.ServerError = &rpc.ServerError{Message:"transformed: message", Code:"transformed: code"} ("server error: transformed: message (transformed: code)") [04:59] umm... [05:00] perhaps [05:00] I do still get some intermittant failures [05:00] happens 100% of the time [05:00] will bisect in a few mins [05:00] hmm [05:01] I ran tests just before I went out [05:01] and all passed [05:01] trying to improve my jenkins builder to run our tests [05:01] let me check my trunk revision [05:01] thumper: which revno [05:01] r1024 [05:01] davecheney: what do you have? [05:01] hmm, how can I check [05:01] this branch has local changes [05:02] bzr revno [05:02] yeah, checking 1024 now [05:03] thumper: yup, totally repeatable @1024 [05:03] if you can confirm the failure I will log a bug about it [05:03] hmm... I don't get it on r1024 [05:03] we've seen failures like this before [05:03] let me triple check [05:04] races between the client reading the reseponse and the server closing the connection [05:04] ok launchpad.net/juju-core/rpc 0.186s [05:04] that is with r1024 of trunk [05:15] thumper: can you please try GOMAXPROCS=2 go test launchpad.net/juju-core/rpc [05:16] davecheney: tried three times, succeeded each time [05:16] * thumper is trying to land the upload tools tweaks [05:16] with GOMAXPROCS=2 (or any number other than 1) [05:16] fair enough [05:16] OMG there were a lot of conflicts with trunk [05:17] davecheney: yes, with set to 2 [05:17] that is important, gets the review queue unblocked [05:17] exactly [05:17] carry on [05:18] * thumper nods [05:24] bigjools: https://launchpad.net/~juju/+archive/experimental/+packages [05:24] looks like it worked [05:24] davecheney: cool [05:24] so hax0r away [05:30] bigjools: have you fixed mongo? [05:30] davecheney: branch landed [05:30] rofl [05:30] * thumper is done [05:31] thumper: it's not a packaging problem AFAICS therefore it's a juju problem [05:32] or mongo.... take your pick. either way, it's not *my* problem :) [05:32] heh [05:32] you said you saw libssl linked? [05:32] perhaps 2.2.3 has something that breaks juju [05:33] maybe... NFI [05:33] * thumper goes to help make dinner [05:36] LFTM, ldd $(which mongod) linux-gate.so.1 => (0xb76ef000) libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xb7690000) [05:36] mongo is stupid [05:36] they require the elephant that is libboost [05:36] but they only need it for the headers [05:40] thumper: ok, the rpc test failure is real [05:40] just verified under 1.0.3 as well [05:41] it fails under my stress test script [05:41] will raise a bug [05:43] https://bugs.launchpad.net/juju-core/+bug/1157553 [05:43] <_mup_> Bug #1157553: rpc: tests are unreliable < https://launchpad.net/bugs/1157553 > [08:21] jam1: question about juju cli for windows ? === jam1 is now known as jam [08:21] yes davecheney? [08:21] did you get a cross compile working, or did you do it directly on win32 ? [08:22] davecheney: just did it directly [08:22] fair enough [08:22] that is what I tought [08:22] thought [08:22] as you were [08:22] well, I need to actually run it there anyway, right ? :) [08:22] yes [08:22] sorry, was answerin a question from another channel [08:22] np [08:23] I did recompile go, but I probably could have just downloaded the 32-bit version. The big key was just needing 'gcc' for cgo. [08:23] Though maybe I would need a "close" match between the gcc for go and the one for goyaml [08:23] so maybe I would need to recompile go [08:23] C usually isn't as version specific as C++ [08:24] i would really like to remove the cgo requirement for goyaml [08:24] which is a medium sized job [08:25] but might be helpful if we have to cross compiile a lot in the future [08:25] when I mentioned it in the past (1yr?) gustavo claimed that he didn't want to implement the mess that was yaml parsing. [08:25] ie, I don't see lp supporting a win32 target any ti,e in the future [08:25] yeah, that is very true [08:25] goyaml just wraps the python yaml c code [08:25] right [08:25] so it has the same compatibilty as the python version [08:25] a decent compromise [08:26] from what kapil said, yaml parsing speed becomes a bottleneck at large scale, so having a slow parser might also be bad [08:26] but it could be *really* useful if the API was compatible [08:26] so you could use "A" or "B" yaml libsd [08:26] libs [08:26] and then we could have native go yaml for stuff like win32 [08:27] i don't think yaml parsing speed is that importnat [08:27] davecheney: do you know why cgo doesn't support cross-compiling? You certainly have cross-compiling gcc [08:27] we don't have the topology node [08:27] jam: it's not that it doesnt' support it [08:27] but the moving parts required especially to go from elf -> PE [08:27] are substantial [08:28] if you did all the compilation steps by hand, and had the right cross compiler and cross linker, as well as headers and .so's [08:28] you could do it [08:28] but it was just too hard to autoate with the simple go tool [08:28] sure. So for Bazaar, we just created an EC2 instance that we bundled, and then brought up when we did a release to build the next binaries. [08:29] It wouldn't be hard to set that up again. [08:29] mornin' all [08:29] hi rogpeppe, hope your day has started well so far [08:29] morning rogpeppe [08:29] jam: the shower was hot :-) [08:29] davecheney: hiya [08:29] jam: i think that is a good suggestion [08:29] lets see how it pans out [08:30] maybe someone will kick in the resources for this machine on a native platform [08:30] :P [08:30] davecheney: so in the short-term, I have no problem doing the compiling on win32, but I imagine we'll want a more automated system so we can detect issues pre-release. [08:31] morning [08:31] jam: smells like a jenkins shaped problem [08:31] hi dimitern [08:31] davecheney: it does, indeed. Though my personal jenkins-fu is quite rusty. [08:31] jam: i've setup a jenkins CI build now that i have the right i386 mongo [08:31] I've used it, I've played with it, but not allt hat much. [08:32] davecheney: you have a mongod that runs on Windows? Or is that Linux-i386? [08:32] jam: jenkins is easy, imagine a hammer that has been worn down by repeatedly bashing on hard thins [08:32] that is jenkins [08:32] jam: i386, see mail to juju-dev about backstop plan for how to get away from using a tarball for mongo [08:33] vila from our old squad had jenkins stuff set up. I think his biggest trouble was trying to create a reproducible save state (so if needed someone else could bring it up similarly). It wasn't terrible to configure and sort of hack it together. [08:33] davecheney: yeah, I saw the "start at a ppa" [08:33] though IIRC the ppa build breaks the test suite. [08:33] If you run with '-gocheck.vv' I *think* rogpeppe and I (mostly him at my request) made it so the failing mongod would at least get logged. [08:33] jam: i think we fixed that [08:36] setting up jenkins is painful, but at least takes less than a day, even from scratch - did it twice :) [08:36] davecheney: i saw your TestTransformErrors failure yesterday [08:36] davecheney: it only happens in go tip [08:36] davecheney: and i haven't narrowed it down yet [08:39] rogpeppe: it happens with 1.0.3 [08:39] i checked [08:39] davecheney: orly? [08:39] it's timing related [08:39] rogpeppe: http://play.golang.org/p/lSPW2BO2Tk [08:39] cd $PKG [08:39] bash stress.bash [08:39] davecheney: i'm sure it never happened before on go tip, so i'm surprised about 1.0.3 [08:39] fails in a few seconds [08:40] fwereade: https://codereview.appspot.com/7497047/ please? [08:46] davecheney: ah, i've managed to reproduce the problem on 1.0.2 (and i also saw a log-target-race related panic) [08:47] it's less prevelent under the old 1.0.x scheduler [08:47] but the race is there [08:48] davecheney: yeah (this time i saw the issue in a different test, BTW, but still "connection reset by peer") [08:49] davecheney: (when reading a response, but writing the request though - it might be a different issue but i suspect not) [08:49] s/but/not/ [08:49] rogpeppe: indeed, the faliure modes are always subtly different but it appears to be the client and the server racing to read the final message [08:49] rogpeppe: didn't dimeter fix a very similar bug in Atlanta ? [08:49] dimitern, sorry, on it right now [08:49] fwereade: cheers! [08:50] davecheney: ah, i *think* i might see the problem [08:51] how can i subscribe to canonical-juju ? [08:51] dimitern: how much cash do you have ? [08:51] davecheney: :D [08:53] dimitern: https://lists.canonical.com/mailman/listinfo/canonical-juju [08:53] davecheney: yup, fixed it, i think [08:53] davecheney: as a BG rapper sang once "i own tens of bucks" [08:53] davecheney: cheers [08:56] davecheney: https://codereview.appspot.com/7919043 [08:57] * davecheney looks [08:58] rogpeppe: that'll do it every time [08:58] davecheney: yup :-) [08:58] i'm surprised that ever work [08:58] worked [08:58] davecheney: yup. [08:58] what is the history on that file [08:59] i have a worrying feeling that we tried to 'fix' it before [08:59] (poorly) [08:59] davecheney: i guess it was almost always running the new goroutine first [08:59] davecheney: i'm not sure. i don't remember doing so [09:00] i have a vague memory from atlanta [09:01] davecheney: i might've missed it, being involved with gui stuff [09:01] * davecheney checks [09:01] the reason i mentoin it is we had a very similar bug that week [09:04] davecheney: well, there are no fixes of that kind in the rpc package at any rate [09:04] davecheney: this produces only ian's recent changes to log: for(i in *.go) {echo $i; bzr blame $i | grep -v '^ +\|' | grep -v roger.p } [09:05] someone showed me [09:05] bzr log --show-diffs [09:05] but I cna't make it work [09:05] what am I doing wrong ? [09:05] davecheney: i just checked that noone other than me has made any changes to the files in rpc. :-) [09:06] maybe it was a similar error in another package [09:06] screw it [09:06] get one more LGTM and job done [09:07] yup, i'm happy we are not reverting another fix [09:11] dimitern, qualified LGTM, ping me if there's any uncertainty [09:12] fwereade: tyvm [09:14] fwereade: no, i'm not getting the thing about using the wrong charm url in unit.go, please explain [09:15] dimitern, the service config we care about from the perspective of the unit is the config that is known to match the *unit*'s charm url [09:15] * TheMue likes failing tests *hmpf* [09:16] fwereade: exactly what i'm doing isn't it? [09:16] fwereade: getting u.doc.CharmURL + u.doc.Service for the key [09:16] (well, vice versa, but the code is correct i think) [09:17] dimitern, looking up the service's charm url is defeating the point of doing all the work in the first place [09:17] dimitern, not entirely ofc, because you do the right thing in watcher.go [09:17] dimitern, when watching the unit's service config [09:17] fwereade: are you talking about WatchServiceConfig() ? [09:17] dimitern, WatchServiceConfig is Correct [09:17] dimitern, ServiceConfig is not [09:17] fwereade: aah, got you :) [09:18] dimitern, they should be using the same document [09:18] fwereade: right, sorry - i'll fix it [09:18] dimitern, np, I didn't catch that first time round anyway [09:19] dimitern, but, sorry, wait a mo [09:20] dimitern, no, we're good [09:20] dimitern, thanks :) [09:21] fwereade: i'm a bit divided what comments to put around the ops [09:21] dimitern, which ones? :) [09:21] fwereade: this case you described about inc ops with a single upgraded unit in error state getting reverted [09:22] fwereade: should we document this somehow, or make the "first use" comment more correct [09:23] dimitern, I think that the explanatory line should be either made strictly accurate, or maybe even dropped; as it is, it clearly contradicts the preceding if/else chain [09:24] dimitern, I'm not sure what explanatory power a strictly accurate version has though [09:24] fwereade: ok, i'm dropping it :) can be bothered to wrap my mind around commenting all cases in a sentence [09:24] dimitern, how about "The document might need to be created"? [09:24] dimitern, I think that is accurate and high-level helpful [09:25] dimitern, "A new settings document might need to be created"? [09:25] fwereade: that's like saying the water is wet [09:25] fwereade: we're creating it anyway [09:26] dimitern, ha, sorry, "a new refcount document might need to be created"? [09:26] fwereade: hmm... let me think a bit [09:27] fwereade: what we're actually doing there is either creating a refcount=1 or just refcount++ [09:27] dimitern, honestly, it is documented anyway is settingsIncRefOp [09:28] fwereade: yeah, i think it makes sense, although not saying when we might do it... ah right - just take a look at the settingsIncRefOp [09:28] dimitern, on service creation we just blat it out directly because we don't need the complexity of an incref, but in this case we need it so we use it [09:28] fwereade: ok, i'll change both inc and dec comments so [09:29] dimitern, maybe the comments are best couched in terms of "the unit adds a reference to the new settings doc" and "the service drops its reference to its old settings doc"? [09:29] fwereade: even better! 10x [09:30] dimitern, cool [09:32] Ha, killed the next failure. *g* [09:32] * fwereade cheers at TheMue [09:34] fwereade: After changes the hard coded references to $HOME/.juju there are now still some hidden glitches in the tests. ;) [09:34] TheMue, yeah, no doubt -- good luck with them [09:34] fwereade: thx [09:44] the update manager this morning suggested to do a "partial distribution upgrade" - never seen this before, i did it and /etc/issue still reports 12.10 - anyone seen this? [09:46] fwereade: done with the changes - would you like one last check (mostly for wording in comments) before I submit? https://codereview.appspot.com/7497047/ [09:59] dimitern, sure [10:22] good night gentlemen [10:22] don't forget, release on friday [10:23] i'll do the release notes dance tomorrow [10:23] davecheney: good night! [10:23] night y'all [10:23] night davecheney [10:24] fwereade: so we had a question come up recently about Series vs Arch. Specifically, one seems to be a conf parameter, and one is meant to be a --constraint (from what I could tell). [10:24] I noticed because both are a bit borked on Windows [10:24] where it wants i386, and we don't have those charms available :) [10:25] I can change the code so that if series is unknown, it returns the default series from conf, but where do I overload the arch? (--constraint was the recommended method from mgz, IIRC) [10:26] mgz, dimitern: can either of you try bootstrapping on HP? I'm getting weird inability to write to swift, but I don't know if it is something about me. [10:26] I would ask wallyworld, but he is obviously away right now. [10:26] jam, heyhey [10:27] jam, usage of version.Current.Series will hopefully be evaporating imminently: tim's in the process of clearing up the environs api to accept series instead of tools [10:27] also, fwereade, https://code.launchpad.net/~fwereade/juju-core/bootstrap-constraints-3a/+merge/153725 landed, so I think your "EC2 should choose" kanban card can go into merged? [10:28] fwereade: yeah, I was hoping I wouldn't have to do much about series, and could let Tim do the work for me there. [10:28] But Arch is also important in this context, and it was unclear how that happens. [10:28] At the very least, it seemed both Arch and Series should be configured in the same manner [10:28] (environments.yaml, or --constraints, but not both) [10:29] well, even both, but not one one way and the other differently [10:29] jam: can check [10:29] thanks mgz, good morning, btw [10:29] I hope your Muselix is tasty today [10:29] jam, I don't consider my card really done until I've merged -6 -- it was originally meant to include that too [10:29] jam, but I am working on merging it all today [10:29] k [10:29] jam, wrt series and arch I think matters are a little more subtle [10:30] eaten long ago, the fun of getting on the 7:45 bus... [10:30] mgz: I thought colocation was Thurs? [10:30] at least I have a net connection up to doing audio+ssh today, not sure what was up with the crazy packet loss at home yesterday [10:30] yeah, that got pretty crazy at the end. [10:30] it is, I'm casually in town [10:31] I could hear you fine, but your ssh lag was pretty bad [10:31] and irc stayed up... [10:31] but incoming audio was being mangled, and screen was paaainful [10:32] mgz: so how much to get Fi-OS to your house? :0 [10:32] well, there have been promises from the local authority... [10:32] we promise to make you pay through the nose [10:32] to get 1Mbit [10:32] jam, would you like a quick hangout? [10:32] I guess T3 was 1.5Mbit? [10:32] fwereade: sure [10:33] fwereade: you want to set it up or me? [10:33] it's mostly a service reliablity and cost thing these days rather than speed, which is actually pretty reasonable [10:33] jam, I was getting water but will do so now [10:33] np [10:38] fwereade: ping [10:41] dimitern, pong [10:41] fwereade: does it look ok? [10:41]