[00:33] thumper: back? [00:36] wallyworld: https://code.launchpad.net/~dave-cheney/+recipe/juju-core [00:36] what has happened to the build recipe ?!? [00:36] why don't the debs end in the series ? [00:37] i have no idea. my knowledge of packaging stuff is zero :-( [00:37] bigjools: ? [00:37] sup [00:37] ^^^ [00:38] fuck [00:38] this broke the release [00:38] bugger it [00:38] i can fix this in the release script [00:38] what is the question for me, exactly? [00:38] [10:36:18] what has happened to the build recipe ?!? [00:38] [10:36:33] why don't the debs end in the series ? [00:38] bigjools: why do the debs produced by the recipe no longer end in the series [00:38] that makes no sense [00:39] what do you mean by "end in the series" ? [00:39] the name of the deb used it end in ~saucy [00:39] for example [00:39] now it ends in ~ubuntu13.10 [00:40] because your recipe says "{debupstream}-1~{revno:juju-core}" [00:40] bigjools: that has never changed [00:40] and that gives me -1~1739 [00:40] the remainder was added by the build bot [00:41] I don't see any complete builds that don't have that [00:41] bigjools: [FULLYBUILT] juju-core - 1.13.2-4~1703~saucy1 [00:41] bigjools: https://code.launchpad.net/~juju/+archive/devel/+builds?build_text=&build_state=built [00:41] somethign happened in the last two weeks [00:41] look at the name of the 1.13.2 packages [00:41] and earlier [00:42] it has changed to use release names instead of code names by the looks of things [00:42] which is correct IMHO [00:43] nothing is broken [00:43] bigjools: is it possible to change it back ? [00:43] i was relying on that misfeature [00:43] in what way? [00:43] i used the series in the name of the file produce to deduce the series the deb was produced for [00:44] can't you change it to look at the ubuntuNN.NN.N instead? [00:45] i can [00:45] but I wanted to know why this changed [00:45] no idea [00:45] who can I talk to about this ? [00:45] I'd ask steve or william [00:45] i poked in laucnhpad-ops [00:45] waiting on a reply [00:45] * davecheney joins [00:46] I asked in #launchpad-dev :) [00:46] but there's probably better ways to deduce the series [00:47] bigjools: suggestions welcome [00:47] i have a deb file [00:47] i'd like to know which series it came form [00:47] maybe the changelog [00:47] use the LP API [00:48] bigjools: i have the file [00:48] all i have is the file [00:48] davecheney: here's the answer [00:48] [10:46:35] wallyworld_: It's changed to ~ubuntuYY.MM.1 [00:48] [10:46:45] As Ubuntu's backports have been for a while. [00:48] [10:46:53] Because in a few releases the alphabet will wrpa. [00:48] the file is all i have [00:48] where arey you getting the file? [00:48] wallyworld: bigjools ok [00:48] i'll fix it in code [00:48] thanks for your help [00:48] davecheney: where are you getting the deb from? [00:49] the link from the recipe [00:49] i'll just make a table to convert from number to name [00:49] how are you accessing the recipe? [00:49] hang on :) [00:50] bigjools: manuallyu [00:50] copy and paste the url [00:50] you have a script that scrapes the page? [00:50] http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/doc/juju-core-release-process.txt [00:50] i have a person that scrapes the page [00:51] release notes should always talk about version numbers not code names, FWIW [00:51] I was never comfortable with juju's config files containing "precise" etc [00:51] should be 10.04 [00:51] 12.04 even [00:52] bigjools: i don't think its possible to change that now [00:52] it's always possible :) [00:52] just work [00:53] bigjools: if you feel strongly about it [00:53] raise an issue [00:53] it's not one anyones radar [00:53] well I am just pointing out UBuntu policy [00:54] given my prior work area [00:54] it's kinda on my radar; I was thinking ahead about how tools might be named for non-Ubuntu targets, if we were to support them [00:54] given that so many people get it wrong anyway it's not worth pushing hard [00:54] LSB codename doesn't work so well for other distros [00:54] lol at lsb [00:54] but it's something to be aware of because Ubuntu may change things like you just experienced [00:55] ubunutu doesn't start with the letter l [00:55] bigjools: fair enough, i am so warned [00:55] cool [00:55] davecheney: anyway I am struggling from that large page of text to work out what exactly you're doing with the deb [00:56] you get the deb url manually then? [00:56] oh and the script parses the deb file name. [00:56] you might want to specify that manually tbh [00:57] in Ubuntu debs can be in more than one release if they didn't change between [00:58] bigjools: that page just documents what happens now [00:58] it does not describe what we want to happen [00:58] fair enough [00:58] I'd honestly make an LP API script to automate this [00:59] bigjools: i'm sure someone will replace this with somthing much better [00:59] ok. said my piece :) [01:00] thanks all for your help [01:00] any time [01:00] wasn't hard to work around [01:07] davecheney: i know i am stupid, but i'm getting a nil pointer panic and i can't see why :-( any clues? http://pastebin.ubuntu.com/6057264/ [01:08] wallyworld: can't do it like that [01:08] what is happening is gocheck does this [01:08] s := new(LegacyToolsSuite) [01:08] legacy tools suite contains a ToolsSuite as a valid initalised to its zero value [01:09] and inside that is a field called toolsTestHelper which is an interface [01:09] the interface is initalised to it's zero value [01:09] which is a nil pointer [01:09] why is polymorphism so hard in Go :-( [01:09] cos there is no polymorphism [01:10] yeah :-( [01:10] kinda limiting [01:10] thanks, i'll rework it [01:12] ok, i've found another bug with that change [01:12] the version inside the 12.10 deb is 13.10 [01:13] \o/ [01:13] http://paste.ubuntu.com/6057271/ [01:14] i'll ask in launchpad-ops [01:14] oh [01:14] hang on [01:14] something is wrong [01:14] shit [01:14] sorry [01:14] i fucked up [01:14] :-) [01:15] thumper: ping [01:27] axw: lp:~axwalk/juju-core/lp1218329-azure-released-images [01:27] wallyworld: hi [01:27] are you able to backport that to the 1.14 branch ? [01:27] davecheney: sure [01:28] ta [01:28] there is no bot [01:28] merge manually [01:28] okey dokey [01:29] thumper: hi, i was reviewing your pass-through-agent-config branch. i couldn't tell for sure, but are you ensuring the default value for dataDir is "/var/lib/juju". it looks like that is missing with the rework? [01:29] wallyworld: that is because it is dumb :) [01:29] it was saying "if it is empty" [01:29] it is never empty [01:29] agent.Config will not be created with an empty dataDir [01:30] ok. other than that, it all looks pretty mechanical [01:46] right [01:46] this release is a dud [01:47] spot the bug., http://paste.ubuntu.com/6057341/ [01:51] davecheney: pushed to 1.14 [01:55] thanks [01:55] might have been for naught [01:55] the machiner can't restart properly [01:56] it has a requirement on the api server being up [01:56] and that races with the api server job [01:56] restarting [01:56] ok, it looks like it finally gets there [01:56] but takes many many rstarts [01:56] * davecheney files bug [02:00] https://bugs.launchpad.net/juju-core/+bug/1220027 [02:00] <_mup_> Bug #1220027: worker/provisioner: cannot restart cleanly due to hard dependency on api server [02:03] I think this would be pretty easily solved if we didn't make everything fatal [02:04] that way the provisioner would try to start, fail and then retry [02:04] while the api server comes up [02:04] or, [02:04] we should make sure the at the api server comes up before we start any other jobs that depend on it [02:04] that sounds sensible [02:05] thumper: i think we have to do that [02:05] before the provisioniner didn't use the api to provision [02:05] now it does [02:05] we used to have this for state [02:05] at least it made sure the state connection was valid [02:05] now we need a valid api endpoint [02:08] this is the danger of testing on ec2 [02:08] we expect everything to be dog slow [02:10] wallyworld: can someone sync tools to canonistack and hp cloud ? [02:10] davecheney: ok [02:11] wallyworld: ta much [02:16] axw: https://bugs.launchpad.net/juju-core/+bug/1218329 [02:16] <_mup_> Bug #1218329: Update default environment.yaml for Azure to use Precise for default-series

[02:16] which rev was this fixed on 1.14 ? [02:17] axw: what is a simple way to copy a clice? [02:17] foo[:] ? [02:18] thumper: nope [02:18] use the copy() statement [02:18] works in python :P [02:18] sorry functoin [02:18] builtin? [02:18] that will give you a new slice with the same backing array [02:19] what benefit does that really give us over returning the slice itself? [02:19] thumper: sorry missed... append([]x, y...) [02:19] it it shares the backing array [02:19] []x{} rather [02:19] thumper: i don't know, i don't know what the question is [02:20] davecheney: axw suggested in a review to return a copy of our caCert []byte instead of the one we have [02:20] just so it isn't misused [02:20] accidentally [02:20] append([]byte{}, caCert...) [02:20] axw: does append(nil, caCert..) work? [02:20] or does it need to be a typed nil? [02:20] umm. I don't recall [02:21] don't think so, but I'll try [02:21] thumper: nope [02:21] (nope doesn't work; needs to be typed) [02:23] * thumper nods [02:23] * thumper uses append [02:23] thumper: as for your question of "what benefit does that [returning a resliced slice] give" - none in this case [02:23] the new copy I get [02:24] * thumper returns a copy [02:24] and runs the tests prior to submitting [02:24] axw: I also fixed the comment. [02:24] thumper: thanks [02:35] oh god [02:35] it's going to take ~24h to get to SFO [02:38] axw: WHAT [02:38] 4 hours to Syd [02:38] then 14 to SFO [02:38] 14 to LAX [02:38] then 2 to SFO [02:39] davecheney: not all in the air [02:39] don't forget fun times waiting at the airports [02:39] davecheney: syncing finished for canonistack and hp cloud [02:39] wallyworld: ta [02:39] testing now [02:39] axw: serves you right for living in perth :-P [02:40] wallyworld: yeah :( let's all have the next one here.. ha ha [02:40] i'd rather europe :-) [02:41] or that [02:41] ooooooooooooooooooooooh [02:42] now i understand what hazmat is talking about [02:42] if the provisioner gets into the restart loop [02:42] still a long flight, but at least there's cheap beer and good food at the end of it [02:42] status will take ages [02:42] because there is no api server [02:42] axw: in SFO [02:42] davecheney: ? [02:42] uh, are you sure ? [02:42] europe [02:43] davecheney: what's the provisioner problem? this sounds a bit like an issue I saw with the local provider [02:43] https://bugs.launchpad.net/juju-core/+bug/1220027 [02:43] <_mup_> Bug #1220027: worker/provisioner: cannot restart cleanly due to hard dependency on api server

[02:44] mk [02:44] that does look similar [02:44] lucky(~) % juju bootstrap -v [02:44] 2013-09-03 02:44:45 INFO juju.provider.openstack provider.go:126 opening environment "nec-az3" [02:45] 2013-09-03 02:44:45 INFO juju.environs.tools tools.go:29 reading tools with major version 1 [02:45] 2013-09-03 02:44:45 INFO juju.environs.tools tools.go:37 filtering tools by series: precise [02:45] 2013-09-03 02:44:48 INFO juju.environs.tools tools.go:44 falling back to public bucket [02:45] 2013-09-03 02:44:48 INFO juju.environs.tools tools.go:93 picked newest version: 1.13.2 [02:45] wallyworld: did you sync tools to hp cloud ? [02:45] davecheney: supposedly [02:45] what public bucket are you using? [02:46] i've got https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910 [02:46] public-bucket-url: https://region-a.geo-1.objects.hpcloudsvc.com/v1/60502529753910 [02:46] wallyworld: i am using az3 [02:46] wtf, they're different [02:46] they look the same to me [02:46] ok, so i need to sync to your's too [02:47] oh hang on [02:47] i can't read [02:47] they're the same [02:48] so looks like sync tools lied to me [02:48] wallyworld: should I try a different az ? [02:48] wallyworld: how do you have sync tools setup ? [02:48] do you put the public bucket as your cotrol bucket then run juju-sync tools ? [02:49] no, i've not run it before,i assumed it would upload to the public bucket of the env [02:49] * davecheney has no idea [02:50] i'll take another look [02:50] davecheney: i forgot the --public [02:50] bzzzzzzzzzzzzzzt [02:50] so it uploaded to my private bucket [02:50] sorry [02:50] rofl [02:50] fuck off :-) [02:51] damn [02:51] auth error [03:05] davecheney: ok, i've had to do hp cloud by hand since there are different credentials for public bucket vs my normal account i think. i'll now do canonistack, but there are authentication issues there too [03:08] let me try [03:08] maybe my creds work for hp cloud [03:12] davecheney: i can upload via the web ui. but i think my creds to write to the public bucket differ from the creds i need to use to access my juju assets and so sync-tools doesn't like that [03:13] similar issue with canonistack - i'm having to do that by hand tool [03:14] davecheney: canonistack done too hopefully [03:15] kk [03:17] wallyworld: tools in hpcloud look good now [03:17] thanks [03:17] great [03:47] * thumper goes to make coffee [04:10] * thumper puts the music on loud to try to cover the screaming kids [04:10] they are playing some xbox game [04:28] * thumper shelves the logging work until someone can help explain the api [04:29] wallyworld: hey there [04:29] wallyworld: wotcha up to? [04:29] yo [04:30] tools stuff [04:30] call? [04:30] ok [04:30] wallyworld: https://plus.google.com/hangouts/_/775c25d6dba9048907bcf2c54e570e6a4008a22f?hl=en [04:56] * thumper back later === thumper is now known as thumper-afk === tasdomas_afk is now known as tasdomas [09:18] fwereade: you may have an interest in this https://codereview.appspot.com/13343046, i've used some new interfaces, get out the paint cans [09:18] wallyworld, nice [09:18] wallyworld, thanks [09:18] i'd be happy to discuss before/after the standup [09:19] * wallyworld unpacks his new Nexus 7 II tablet :-D [09:46] fwereade: hey [09:46] dimitern, heyhey [09:47] fwereade: so looking at the code I think it's high time I start doing the migration from relation-id to relation-key tags [09:47] dimitern, good plan, +1 [09:47] fwereade: this, and the relationunitswatcher are the only missing bits at server-side [09:48] fwereade: otherwise most of the stuff that's left is mostly trivial [09:51] dimitern, that is music to my ears :) [09:52] fwereade: :) [09:56] fwereade: I need to dig up logs for rogpeppe's findings on relation names format, do you know that site that has all irc logs in html format? [09:57] dimitern, er not offhand, I usually just search and poke around until something shows up [09:57] fwereade: ah, found it http://irclogs.canonical.com/YYYY/MM/DD/ [09:57] dimitern, same time as me :) [09:59] fwereade: hmm, but this one doesn't have the freenode logs [09:59] fwereade: so, for the record it's http://irclogs.ubuntu.com/2013/08/16/ [10:00] dimitern, cheers :) [10:01] fwereade: [a-z][a-z0-9]*(-[a-z0-9]+)* seems to be the right regexp for relation names [10:02] fwereade: so for the tag format itself, what do you think? "relation-" with the format above, no changes to dashes, etc.? === thumper-afk is now known as thumper [10:03] fwereade: ah, but that's just one name, we have "name1:service1 name2:service2" [10:04] fwereade: so we need something like "relation-@|@" ? [10:04] dimitern, yeah, I think so [10:05] dimitern, the first step is tidying up the names considered to be valid in charms [10:05] fwereade: hmm.. the pipe is not a valid filename char [10:05] fwereade: maybe ~ ? [10:05] dimitern, I would prefer to preserve filename-sanity if possible [10:06] dimitern, # maybe? [10:06] fwereade: "relation-my-relation123@some-service~my-other-relation42@remote-service23" [10:06] fwereade: is it valid? [10:06] fwereade: ok, I'll go with # [10:07] dimitern, ehh I'm uncertain about swapping the service:relation ordering [10:08] dimitern, seems mainly like an opportunity to make mistakes [10:08] dimitern, I understand it fits nicely with @ [10:08] fwereade: ah, was it the other way around? no problem, wasn't sure [10:08] dimitern, yeah, but then "service@relation" is kinda crazy [10:09] fwereade: it kinda is [10:10] dimitern, how abouut... relation-svc.rel#svc.rel perhaps? [10:10] fwereade: dots? [10:10] are they bad? [10:10] fwereade: don't think so, just a bit weird, sgtm [10:11] dimitern, svc.rel feels to me closest to svc:rel [10:11] dimitern, and it's an endpoint on a specific service so i think the ordering is useful [10:12] fwereade: according to wikipedia http://en.wikipedia.org/wiki/Filename dots should be ok [10:12] dimitern, so I would hope indeed :) [10:12] fwereade: but : is definitely not [10:12] dimitern, quite so [10:13] dimitern, svc:rel is the existing syntax though [10:13] dimitern: are you saying "sane filenames on Linux" or "sane filenames on Windows". Because on Linux any 8-bit is allowed except for "/" and "\x00". [10:13] jam: well, not really - some are shell special chars [10:13] jam: and need escaping, which is ugly [10:14] dimitern: they are "valid filename chars" [10:14] it happens that shell likes to do things with them [10:14] fwereade: so the conversion should be s/:/./ and s/ /#/ + "relation-" as prefix [10:14] which is more about clarity "not shell characters" is not the same as "only filename chars" [10:15] : ; ^ , {} [] " ' all have shell meaning but are valid in filenames [10:15] jam: yeah, but let's not make our lives harder in the remote possibility we actually need to use tags as filenames :) [10:15] dimitern, sgtm I think [11:30] mgz, fwereade, dimitern, TheMue, wallyworld_: standup time: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 [11:31] ta [11:33] fwereade: poke ? [11:33] jam, oops, sorry [11:52] TheMue: can you link me to the ssl bug ? [11:53] wallyworld_: you may have hit: 1207294 [11:53] bug #1207294 [11:53] <_mup_> Bug #1207294: sync-tools fails with --public [11:54] fwereade: https://codereview.appspot.com/13490043 [11:54] jam: yes, at first glance could be [11:55] mgz: do you know the status of https://bugs.launchpad.net/juju-core/+bug/1215949 and how we fix it? [11:55] <_mup_> Bug #1215949: juju-core in the devel ppa does not use alternatives [11:55] would be really good to have for 1.14 (without having to go via Saucy) [11:55] sort of... [11:55] we just need to get that building from the ubuntu-branch packaging [11:56] the reason that's not quite trivial is the ubuntu packaging is set to build from a stable tarball, rather than pull trunk of everything, [11:56] so, if we update deps, we'd break the devel packaging potentially [11:57] could overlay everything still.. [12:03] mgz: things in ppa:juju/devel are still releases, so we can still build from *a* tarball [12:16] wallyworld_: if you are still here, did this get landed: https://bugs.launchpad.net/goose/+bug/1132618 [12:16] <_mup_> Bug #1132618: swift service double lacks container list prefix filtering [12:16] it looks old, but it is still open as "Critical" [12:17] TheMue: another poke if you have the bug # for the ssh-hostname-verify stuff. [12:17] There is an old bug #1074025 where we said we needed to support it, and then disabled it or something [12:17] <_mup_> Bug #1074025: environs/config: juju must support ssl-hostname-verification config option [12:18] but I'm pretty sure there should be a new bug [12:24] natefinch: https://codereview.appspot.com/13079045/ has been review [12:24] reviewed [12:25]