[00:15] wallyworld_: fwiw juju 1.20.8 proposed works the same for me as 1.21-alpha1 did, for the disable-network-management thing is concerned. [00:16] wallyworld_: as in, I can get a juju bootstrap working [00:16] bradm: that's good then :-) thank for letting me know [00:18] I'm having some weirdness with the rest of the deploy, but we haven't really gotten this going before, so I'm not sure what the issue is [00:30] ok, if you can pin it down to a specific issue, maybe we can help [00:36] wallyworld_: I'm leaning towards it being an issue with our preseed in maas, but thanks, will let you know if I think I'm seeing juju issues. [00:36] ok [00:44] waigani: review for http://reviews.vapour.ws/r/70/ done [00:49] menn0: thanks === thumper-afk is now known as thumper [01:48] waigani: so should I pick up another document to do the env UUID conversion for? [01:48] waigani: I guess I should wait for your services branch to land as it has some useful helpers [01:49] menn0: I've replied to your comments but not published them, should have the next pr up soon. Should I publish my comments now anyway? [01:49] waigani: wait til you have responded to them with code [01:49] otherwise you'll confuse other [01:49] waigani: what davecheney said [01:50] waigani: in the meantime I'll pick out the next one [01:50] and start figuring out what needs to happen [01:57] thumper: ready when you are [01:57] davecheney: ok [02:17] thumper: : I'm getting a panic in environInfoUserTag when running juju status against an env bootstrapped with trunk on Friday [02:17] menn0: otp, with you soonish [02:18] thumper: k [02:23] waigani: once we've done the env UUID work for units and machines we should then do the statuses collection. The "global keys" used there need a env UUID prefix. [02:23] menn0: how do I update rbt? [02:23] waigani: rbt post -r [02:24] waigani: rbt post -u will work too, but only if you haven't rebased [02:24] thought it was smart enough to remember, I just made a new pr accidentally [02:24] waigani: nope [02:25] menn0: http://reviews.vapour.ws/r/70 [02:25] waigani: looking [02:26] waigani: didn't hit publish? [02:26] what? [02:26] oh ffs... [02:27] now I get an 500 server error [02:27] waigani: just do it from the web interface [02:27] if you've uploaded a new diff there will be a publish button [02:27] yep I hit it and I get a 500 err [02:27] you could have also passed -p to rbt post to have it publish immediately [02:28] waigani: awesome [02:28] waigani: that's not something I have seen before [02:28] waigani: I've got my 1:1 now anyway [02:28] ericsnow: coded the easter egg just for me ;) [02:28] ERROR: Could not reach the Review Board server at https://reviews.vapour.ws/ [02:29] menn0: it's uptodate on github [02:29] waigani: can you get to the site at all? [02:29] menn0: yes [02:29] odd [02:30] menn0: https://github.com/juju/juju/pull/802 [02:30] menn0: did you get my replies to your comments? [02:31] yep [02:31] waigani: actually I can see an updated diff on RB now [02:31] is the right one? I still get the publish button and 500 every time I click it?!? [02:33] okay, looks like the right diff is up. So what is with this publish button then? [02:33] well it seems to have some of the changes I brought up [02:33] waigani: what happens if you refresh the page? [02:33] waigani: does the button go away? [02:33] menn0: nop [02:33] strange [02:34] I'm in perpetual draft - a draft that everyone can see... [02:34] waigani: hey there's still lots of cases where DocId should be getting used instead of called idForEnv [02:34] menn0: okay, I'll do another sweep [02:34] waigani: an idea: try removing the review request you accidentally added (mark it as Discarded) [02:34] menn0: there now, [02:38] runtime.panic(0xd79660, 0x1bc2aa8) [02:38] /usr/lib/go/src/pkg/runtime/panic.c:266 +0xb6 [02:38] github.com/juju/juju/juju.environInfoUserTag(0x0, 0x0, 0xc2101664c0, 0xc210145ba0, 0x9, ...) [02:38] /home/menno/go/src/github.com/juju/juju/juju/api.go:230 +0x2a [02:38] github.com/juju/juju/juju.func·003(0xc210165480, 0x0, 0x0, 0x0, 0x0) [02:38] /home/menno/go/src/github.com/juju/juju/juju/api.go:168 +0xc4 [02:38] github.com/juju/utils/parallel.func·005() [02:38] /home/menno/go/src/github.com/juju/utils/parallel/try.go:135 +0x41 [02:38] created by github.com/juju/utils/parallel.(*Try).loop [02:38] /home/menno/go/src/github.com/juju/utils/parallel/try.go:86 +0x9f [02:39] that's for thumper :) [02:39] menn0: I did change all the DocIDs, but files were not saved so didn't get added [02:39] waigani: cool. in 1:1 [03:09] thumper: are we doing standup? [03:09] 1:1 or whatever it's called [03:09] waigani: yes, just otp with menn0 and finishing up [03:54] menn0: otp [03:54] waigani: kk [03:55] * thumper goes to put the coffee machine on [04:21] waigani: http://reviews.vapour.ws/r/70/ [04:29] menn0: how do I look at the original diff you commented on? [04:30] waigani: There's a slider at the top of the diff viewer which lets you control the diff that's shown [04:30] thanks [04:30] waigani: you can also click on the title from the Reviews UI [04:30] waigani: (the page which just lists the review comments together) [04:55] waigani: review done [04:55] thumper: thanks [05:03] wallyworld_: could I get you to review axw's branch: http://reviews.vapour.ws/r/62/diff/# [05:03] wallyworld_: I'm not comfortable with the tools storage [05:03] sure [05:04] and I think I may miss something [05:04] np [05:04] cheers [05:04] I did the other one :) [05:04] \o/ [05:04] thanks [05:04] thumper: last day today, off tomorrow to central queensland [05:04] wallyworld_: have a nice holiday pre-sprint [05:05] wallyworld_: and I'll see in in Belgium [05:05] thumper: will do, scary bit is a gotta get straight on a plane when we get back so i gotta pack for the sprint this afternoon [05:05] haha [05:06] it's a 5 hour drive back to brisbane, then to airport, hope there's no delays [05:08] :) [05:20] axw: i just looked at http://reviews.vapour.ws/r/72/ - was that bug raised earlier really a critical regression then? [05:20] which bug? [05:20] in the topic - 1371605 [05:20] i marked it as Invalid [05:20] ah, missed it [05:20] looking [05:20] as i thought that HP Cloud should have a had a keystone product-stream endpoint [05:21] well, i'm sure it did, but may i misremember [05:21] if i'm wrong, we'll need to reopen [05:22] wallyworld_: even if it's meant to be there on HP, it won't be in all OpenStack installations [05:22] so yes, it's a real bug/regression [05:22] axw: ok, i'll reopen [05:22] for some reason i thought it would only kick in for CPCs [05:28] axw: in upgradejuju_test, why is there a change to append /tools to the tools-metadata-url? this seems like an error [05:28] the url should just be the base url [05:29] hmmm, maybe not [05:29] wallyworld_: pretty sure it didn't work without it. just a moment, will need to rewind [05:30] axw: igmore me, i think it is needed [05:30] but surprising that the original code didn't have it [05:30] maybe there was code to append /tools if it wasn't there at one point [05:30] wallyworld_: I think in the old code, that tools-metadata-url was just being skipped over and it was using provider storage [05:31] notice I took out the MustUpload... calls [05:31] haven't got to that bit yet [05:31] line #316, just below [05:39] axw: just came across the deletion of the assertMirrors test - for our CPCs, like AWS, HP Cloud etc, provider storage will still be used for mirroring the tools local to the cloud [05:39] so we will still need a test of some sort for that [05:43] wallyworld_: I'll write a new more targeted test [05:43] axw: awesome, ty [05:43] just for sync.StorageToolsUploader [05:45] axw: also, can you double check that there's still tests which check that tools can be downloaded from a local mirror? there will be simplestreams ones, but i can't recall if there are provider ones for wc2 or openstack [05:45] great that the retries bool is gone [05:46] wallyworld_: I don't recall seeing any tests of that sort in the providers [05:46] ok, i don't recall off hand what's there [05:46] i just wated to be sure we weren't reducing test coverage of the mirrors stuff [05:47] wallyworld_: pretty sure I didn't remove any mirror reading tests, I'll double check tho [05:47] ok, ta [05:48] it's got a fairly high risk of breaking something if we get it wrong [05:48] since mirrors are used for aws etc [05:53] thumper, menn0: http://reviews.vapour.ws/r/70/ [05:53] wallyworld_, menn0: http://reviews.vapour.ws/r/74/diff/ [05:53] waigani: I'm being dragged away, will look in the morning [05:54] wallyworld_: this is a critical bug fix [05:54] wallyworld_: I broke it last week [05:54] thumper: okay [05:54] thumper: i get a 404 [05:54] really? [05:54] ah, not anymore [05:54] thumper, menn0: I've made all requested changes - no push back. I'll run all the tests tonight [05:54] maybe i was too quick [05:55] wallyworld_: gah... who do I choose for a review? [05:55] reviewer [05:55] for the 74? [05:55] done [05:55] I hadn't published the review [05:55] geez [05:55] * thumper comes back later === thumper is now known as thumper-eod [06:07] waigani: that PR is looking good. make sure you test an actual upgrade from 1.20 to your latest to make sure the upgrade step actually does what you expect [06:07] menn0: good advice - I'm currently running make test - so far so good [06:07] also I've just found one more problem... sorry. see the review [06:11] menn0: fixed. I've hit some failing tests. So I'll push up the fix with the next round. === uru_ is now known as urulama [07:32] morning [07:38] morning TheMue [07:38] fwereade: I have a mongo question when you're around [07:57] axw: if you had time to look at http://reviews.vapour.ws/r/73/ that would be great, i have to pop out but will be back later [07:58] wallyworld: sure [07:58] ty [08:01] jam, oops, sorry [08:03] jam, (I'm here) [08:07] morning all [08:12] voidspace: heya, all preparations for your trip done? [08:16] TheMue: my visa arrived last week [08:16] TheMue: so just the packing to do :-) [08:16] TheMue: PyCon UK this weekend was fun too - and I got to practise my talk [08:16] TheMue: although the one for PyCon India needs to be 50% longer - so still some work to do [08:34] voidspace: sorry, had phone, insurance company because of my daughters :D [08:34] voidspace: India is fantastic, I enjoyed my -- too short -- time there [08:36] TheMue: it did occur to me that "treat your servers as cattle" is not the right metaphor for an Indian audience... [08:39] jam: I spent some time at PyCon UK with Wes Mason from online services [08:40] jam: he's the replacement for Sidnei on that team - and he's a mongo expert [08:40] (he hates it...) [08:40] jam: he's willing (beuno permitting) to give me or us some time looking at replicasets at some point [08:42] voidspace: what does he hate? mongo? [08:42] TheMue: yes :-) [08:43] voidspace: oh [08:43] TheMue: but he knows a lot about it [08:43] voidspace: sounds good [08:46] voidspace: TheMue: jam: there is a certain correlation between my experience and levels hate [08:46] wesleymason: I assumed that was the case... [08:46] wesleymason: where else is it being used? I thought U1 was using Cassandra, not Mongo [08:48] jam: push are using it for queues, but my experience is from previous workplace [09:13] wesleymason: maybe I can ask you my mongo question. If you do: "servicesCollection.Find(bson.D{}).All(&sdocs)" is there any particular order that the results would be in? [09:14] (in mongo, they seem to always come back in alphabetical sorted, in Tokumx I'm seeing them come back in the order they were inserted, I just wanted to confirm that the test is wrong) [09:17] jam: unless specified it's called "natural order", which is 99% of the time insertion order, but that can be different depending on factors, for example if data were restored from a backup it could be sorted by datetime encoded inside the _id ObjectId [09:17] fwereade: ^^ if you have an answer you're welcome to respond [09:17] wesleymason: well, I'm seeing "insert(wordpress), insert(mysql), Find() => mysql, wordpress" for Mongo and wordpress,mysql for Tokumx [09:18] now, the test claims: // Check the returned service, order is defined by sorted keys. [09:18] but I don't see any sorting anywhere [09:19] jam: have you tried the find on the mongo repl just to make sure there's nothing happening in the driver? [09:19] wesleymason: well, same driver, I believe [09:19] jam, I think if we care about order we should explicitly Sort() [09:20] fwereade: I don't think we care for State.AllServices() do we ? [09:20] jam, IMO, no [09:20] I think the test happened to get a sorted order and thought it was guaranteed [09:20] and we should be Sorting in the test [09:20] jam, agree [09:20] ^ this, and if it's really important sort on a key other than _id, as that can be recreated and not always guaranteed to have the original datetime [09:26] wesleymason: so it would appear that my data was backwards. Toku is returning in sorted order, Mongo was returning in insertion order. Anyway, fixing the test [09:28] jam: that makes MUCH more sense :D [09:29] wesleymason: yeah, I think Toku's "fractal index" and mvcc means that it ends up sorting on insert [09:54] http://reviews.vapour.ws/r/76/diff [09:55] thumper-eod: or wwitzel3 ^^ [09:55] or fwereade^ [09:56] jam, LGTM [09:58] wallyworld: not really sure why the bot is barfing on my branch. I think it must be running really close to the line on /tmp usage, and I tipped it over with the changes to how tools are build [09:58] built* [09:58] gotta make dinner, will take another look later [09:59] axw: your branch addresses bug #https://bugs.launchpad.net/juju-core/+bug/1371605 [09:59] ? [09:59] Bug #1371605: HP Bootstrap fails: no endpoints known for service type: product-streams

[10:16] jam: yes, amonst other things. if I can't land it soon I'll pull out the fix [10:28] can I get a review on http://reviews.vapour.ws/r/77/ please someone? fixes CI blocker === allenap_ is now known as allenap [10:40] TheMue: voidspace: I'm going to be late to standup, and dimiter is out today, so probably you two can just chat with eachother about what's going on and have a short standup, since I've talked with you both [10:40] jam: TheMue: cool [10:44] jam, voidspace: yep, sounds fine to me [10:47] voidspace: I'm hanging out now ;) [10:47] TheMue: omw === fabrice is now known as fabrice|lunch [10:54] axw: lgtm [10:56] mgz: ping [11:07] wallyworld: thanks [11:07] np [11:33] voidspace: yo [11:41] mgz: sorry, I thought the bot wasn't working [11:41] mgz: but we were actually blocked on a critical bug I hadn't noticed === fabrice|lunch is now known as fabrice [11:45] voidspace: I'm just trying to see if I can open trunk [11:46] but andrew's change hasn't made it through the testing yet [12:30] jam, ping [13:03] fwereade, perrito666: we should talk about charm sync. I have a little time right now, but will likely get interrupted in 20-ish minutes... but I know it gets late fast on the other side of the pond, so want to talk whenever is good for you, William. [13:04] hey hi natefinch [13:04] hi fwereade [13:04] perrito666, natefinch: hey guys [13:05] natefinch, how long will your interruption be, do you think? [13:05] natefinch, it's only 3pm for me, but in 90mins I will be going into meeting mode for the rest of the day [13:06] fwereade: ouch, I hope "rest of the day" doesn't mean until midnight [13:06] fwereade: probably 20-ish minutes of disruption. I think we can at least get a good start now if you like [13:06] natefinch, perrito666: ok, sgtm, would you start a hangout and I'll be there in <5? [13:07] https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 [13:35] wallyworld: I have nfi what your email says, because my pgp key is invalid :) [13:35] axw: just letting you know the tools stream branch has landed in trunk [13:35] okey dokey [13:36] quite a few yummy things landed in trunk [13:36] axw, so the provider storage removal is complete? [13:36] hazmat: *very* close to, but not quite [13:36] wallyworld, the --to on ensure-availability should also bring support for manual providers? [13:36] backups still relies on it [13:37] hazmat: (re --to): eventually it should, but currently "ssh:" is all handled CLI-side [13:37] axw, fair enough.. sounds like its enough though that a non storage providing provider could be made [13:38] axw, well --to an existing machine shouldn't need the ssh.. its a pointer to an env machine [13:38] hazmat: after my next branch, you could provide a dummy Storage() method on Environ and 99.9% of Juju would work [13:38] don't really need to --to=ssh: [13:38] axw, awesome [13:38] hazmat: ensure-availability --to nominally uses mass names, like is done with bootstrap [13:38] bootstrap --to [13:39] bummer [13:39] hazmat: the placement directive just gets passed through as is to the provisioner [13:39] wallyworld, if it took env machine ids, then it would work there as well.. i thought people could already specify maas-name via --constraints on ensure-avail [13:39] that's what the landscape guys wanted [13:40] that would involve promoting machines from non-state-server, which is something we don't do atm [13:40] yep [13:40] btw.. found a nice cli based git gui.. tig [13:40] http://jonas.nitro.dk/tig/ [13:40] "nice" and "git" often don't go together [13:42] wallyworld, its working for me, i needed a better browsing interface for keeping up.. and this one does the trick for me. tig --first-parent to browse merges and a custom external command to do proper diff (per juju workflow) on merge commits. [13:42] but yeah.. git tooling is relatively esoteric compared to bzr [13:43] yep [13:43] but i'll take the speed anyday ;-) [13:43] bzr is not reaaly slow nowadays [13:43] axw, so basically altering machine jobs post creation and updating stateServers 'e' doc for votingids stuff [13:44] wallyworld, for net ops.. git is still significantly faster for me [13:44] fairynuff [13:45] katco, re format=oneline, great stuff.. but i wonder if the name shouldn't just be line.. cause its not like oneline of output.. and its shorter. [13:45] hazmat: I forget what exactly we don't handle. it won't work at all on Azure, for example, because state servers are bound to the same cloud service [13:45] hazmat: conceptually we can change a machine's jobs, but the plumbing is not quite there yet, needs a bit of work [13:46] axw, oh.. that problem child ;-) [13:46] hazmat: i was leaning on feedback from the spec. that is fine with me as long as everyone agrees. [13:46] :) [13:48] hazmat: i'm going to focus on landing the tabular and summary formatters, and then we can circle back on the "oneline". can you leave some feedback on the spec, and maybe ping marco et. al.? [13:48] katco, sure [13:48] hazmat: ty, sir. good suggestion. [13:53] jam: so you can ask if the -short flag is on. So CI tests could skip if short is on. [13:53] jam: making the default developer invocation to use short, and CI to stay unchanged [14:00] what's the eta of the trunk landing being cleared now that the blocker is fixed? [14:01] natefinch, wwitzel3, perrito666: standup? [14:02] aghh amazon not having enough machines again [14:03] natefinch: ping === ev__ is now known as ev === fabrice is now known as fabrice|kanban [15:07] update for everyone on trunk landiness status: [15:08] blocking bug has been fixed by andrew, but CI got stuck on a job over the weekend and it catching up on several revisions now [15:08] so, need to wait a little bit still for the change to go through verification and the get bug marked fixed so things can land again [15:10] mgz: thanks === fabrice|kanban is now known as fabrice === fabrice is now known as fabrice|family [15:49] is there a provider interface? [15:50] ah.. environs/interface.go EnvironProvider [16:09] hazmat: would love to hear your thoughts on the process of writing a provider. And definitely if you need any help with a DO provider, I'd be happy to offer whatever help I can (given that I haven;t writt+ [16:09] * katco is off to get her glasses adjusted. bbiab. [16:09] written a provider, that may not be much ;) [16:09] natefinch, i need to convince DO to bake cloudinit into their packages atm. currently doing the email thing with them on it [16:10] s/packages/images [16:10] hazmat: oh interesting, didn't realize that was missing [16:10] natefinch, they added userdata support to get coreos going.. and its the exact same interface as ec2.. we just need them to rebake their ubuntu images with cloudinit installed [16:11] hazmat: sorta surprised we let people deploy "ubuntu" without cloudinit [16:14] natefinch, we don't generally control that [16:14] why don't they just use cloudimg? [16:14] its not a cpc cloud, so we don't build the images [16:14] no.. most non cpc clouds don't [16:15] the only public clouds using cloudimg are those that we push the image directly to their cloud images [16:17] hazmat: I guess I figured cloudinit was one of those things we require for an image to be called "ubuntu" [16:17] natefinch, its not on desktop or ubuntu core [16:17] ie. its not even on most of the images we distribute [16:18] getting userdata/cloudinit support is generally one of the harder aspects of juju enablement for clouds that don't have direct support for it [16:39] if anyone has time, we have a user that's discovered brokenness in our homebrew recipe build of juju: https://bugs.launchpad.net/juju-core/+bug/1372550 [16:39] Bug #1372550: juju metadata missing from brew juju 1.20.7

[16:49] hey hazmat /wave [16:50] sinzui or mgz: the bot still thinks bug #1371605 is blocking trunk [16:50] Bug #1371605: HP Bootstrap fails: no endpoints known for service type: product-streams

[16:50] * sinzui checks if test passed [16:51] jam, the commit is queued to test [16:51] sinzui: for 5 hrs ? [16:52] jam 1. CI was stuck testing a single test over the weekend. 2. 1.20 always tests before devel [16:52] jam, hey wanted to sync up on toku [16:52] and also some discoveries in mongo trunk [16:52] jam, I unblocked the stuck test 4 hours ago. I see 1.20 finishing its tests now [16:52] hazmat: sure. I'm in a meeting, but I'm done in about 5 min. [17:01] sinzui: so what is the process for unblocking trunk, it doesn't just check what the current blockers are, it checks them at the end of a test run? [17:02] jam, I checks that the bug is marked Fix Released. We mark our bug fixed released when we see the test pass [17:02] jam, this address the problem where a commit is made that does NOT fix the test [17:03] jam: it is somewhat painfully slow when it's a fix done at the start of a working day for us [17:03] mgz: I had hoped it was a bit more automated than requiring you guys to jump on it. [17:04] mgz, jam., AWS is painfully show today. The slow tests are all trying to provision instances in AWS [17:04] vacation/sickness means the dev team could be blocked for >24hrs [17:04] well, the testing is automated, just getting a revision through review, landing, then ci tests takes several hours at best [17:04] and today has been much slower as curtis explained [17:05] (partly my fault, I wanted to land a 1.20 change to see if that was blocked as well, which is now taking queue priority when it shouldn't really) [17:05] I guess we always have the JFDI hammer if we find you guys aren't responding. [17:06] jam: there's no reason that bugs can't be marked fixed by anyone [17:07] marking it Fixed Released vs Fix Committed seems a bit of a stretch, but sure, if that is the actual flag [17:07] I was told it was: https://bugs.launchpad.net/juju-core/+bugs?field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL [17:07] it's just whether the policy of waiting for a CI run to verify a blocking bug is fixed to do that marking is helpful [17:08] jam: yeah, that got changed, which I hadn't gathered initially either [17:08] I think blocking all of trunk to do an ammendment to a landed change is generally a bad idea [17:09] response to blockers should be identify the broken change, back that out, reopen the bug/pr that landed it for the followup fix [17:10] jam, sorry, I changed the rules a little over a week ago as an item from my meeting with alexisb , wallyworld , natefinch , and others. I failed to send an email explaining why we added Fix Committed as a blocking condition [17:10] mgz, I will add ...revert the ci test if it was discovered to be changed, or fix the test if it is discovered to be wrong [17:11] mgz, jam. 1.21-alpha2 started testing === uru_ is now known as urulama [18:03] jam, still around.. my meeting went a bit late? [18:03] .. === fabrice|family is now known as fabrice === abentley_ is now known as abentley === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None [20:38] thumper-eod: it's bod [20:39] thumper-eod: did you get my email about parseTag - what id should it return? [21:18] sinzui: i see you've created a 1.20.9 milestone. can i target the apt pinning and tools streams bugs at that? are you going to release the 1.20.8 built last week and then build a subsequent 1.20.9? [21:18] wallyworld, don't hesitate to target to it [21:19] wallyworld, Even if 1.20.8 is reviled, we will still move on to 1.20.9 [21:19] ok, will do [21:19] wallyworld, I don't think anyone will block 1.20.8. We are being polite and letting some say no [21:19] sinzui: ok, i'm off today till the sprint, andrew will backport the tools stream change. was my email about streams behaviour correct? [21:20] yes please, but wallyworld the promise for "moving" the dirs was this year, not this month [21:21] sinzui: the solution in my latest email doesn't require new dirs [21:21] wallyworld, we/my team can always make the index.json point to a locations we need [21:21] the streams are encoded in the existing json files [21:21] same dirs [21:21] wallyworld, rock, I just wanted to be clear that your plan for :released: :proposed: as stanzas in index.json was loved by many [21:22] sinzui: i hope it is because that's what i've implemented :-) seems to work well, and only requires you to generate the files, not any changes to the dirs as such [21:23] sinzui: one point - the mirrors file also has the :released:, :proposed: etc in it [21:24] wallyworld, oh! thank you for telling me. I had not noticed [21:24] sinzui: i hope that is ok, i think it makes sense [21:24] wallyworld, looks like I have a choice of many... [21:25] but now I recall Ben wanted just cpc-mirrors.json, so it will have all the stream names and index will point to it in each stanza [21:26] sinzui: so in that case, i think te implementation i did is correct - a single mirrors json file, containing different stanzas for each stream [21:27] sinzui: if you need tweaks, you can ask andrew; he's available till mid next week [21:27] wallyworld, thank you. I hope not to need anything more than time on my side of things [21:28] i hope so too [21:28] the work is in trunk, should be backported over the next day or so [21:28] 1.20.9 now has 3 bugs assigned [21:29] right, i have to go and drive for 6 hours to my first destination, see you in brussels [21:30]