[01:53] <mwhudson> ha https://code.launchpad.net/~gophers/golang/+git/golang/+index# is marked as failed now
[01:54] <cjwatson> yeah I need to sort out getting that backport in
[01:54] <cjwatson> hopefully will get a bit of time tomorrow to push it up the hill a bit
[01:56] <mwhudson> cjwatson: thanks


[00:01] <alexisb> anastasiamac, wallyworld is holding me up ;)
[00:01] <alexisb> I will be there soon
[00:01] <anastasiamac> alexisb: np - gives me more time to get ready
[00:09] <katco> thumper: wow, i am never visiting NZ. bleck: http://www.buzzfeed.com/nicholaswray/nz-sux#.lweRbQN7Zl
[00:18] <thumper> katco: yeah, it is terrible here
[00:20] <sinzui> fwereade, et al, the run-unit-test script will now retry tagging ec2 instances so that you will see fewer failures setting up in git-merge-juju
[00:21] <thumper> fwereade: the bot hates you
[00:22] <fwereade> thumper, doesn't it just
[00:22] <thumper> fwereade: wanna chat?
[00:22] <fwereade> thumper, although I love it, because one time it was doing its job and preventing me from checking in shite
[00:22] <fwereade> thumper, just a quick one, don't want to distract myself too much ;)
[00:31] <alexisb> thumper, you beat me too it
[00:31] <alexisb> fwereade, I think you need to send the bot some flowers and chocolates
[00:32] <alexisb> or maybe some scotch??
[00:32] <fwereade> alexisb, for sure :)
[00:32] <alexisb> alrighty all, I am off to pick-up kiddo will be back tonight
[00:59] <thumper> fwereade: I see it merged
[01:02] <fwereade> thumper, one of them :)
[02:23] <wallyworld> axw: one thing i forgot to mention in standup - tests on windows are broken because of various reasons, one of which is the loop stuff
[02:23] <axw> wallyworld: ah, doh :(
[02:23] <axw> I have no Windows machine ...
[02:23] <wallyworld> i thought about it ages ago and then forgot
[02:23] <wallyworld> yeah, i'll add a build directive
[02:31] <wallyworld> axw: actually, looking at the code again, i recall we abstracted out all the *nix specific stuff in tests behind stubs/mocks, i think it's just filepath stuff that breaks things
[02:31] <axw> wallyworld: is there a windows build job whose output I can look at?
[02:31] <wallyworld> yeah, that's where i'm heading now, i believe there is
[02:35] <mup> Bug #1428430 was filed: AllWatcher does not remove last closed port for a unit, last removed service config <api> <juju-core:Triaged> <https://launchpad.net/bugs/1428430>
[02:50] <ericsnow_> menn0: would you mind taking another look at http://reviews.vapour.ws/r/1060/
[02:52] <menn0> ericsnow_: looking
[02:53] <ericsnow> menn0: thanks!
[02:56] <wallyworld> axw: only 2 failing tests :-) trivial http://pastebin.ubuntu.com/10534173/
[02:56] <axw> wallyworld: cool
[02:57] <wallyworld> i'll fix (without windows machine but should be ok :-)
[02:58] <alexisb> wallyworld, there is detailed instructions on the cloudbase site for testing windows workloads with juju
[02:58] <alexisb> let me get the link
[02:59] <alexisb> http://wiki.cloudbase.it/juju-testing
[03:01] <alexisb> cmars, jam leads call?
[03:06] <menn0> ericsnow: looking good to me. have you done some manual tests against actual systems with different init systems to make sure this all works?
[03:06] <ericsnow> menn0: my local system (upstart) and a vm running systemd
[03:06] <menn0> ericsnow: ok cool. then ship it.
[03:07] <menn0> ericsnow: there's just one thing I raised (more an idea than an issue)
[03:08] <ericsnow> menn0: I had considered it (reusing identifyExecutable), but wasn't convinced it would always be the same
[03:08] <mup> Bug #1428439 was filed: retry-provisioning launches instances for containers; cannot retry containers at all <juju-core:Triaged> <https://launchpad.net/bugs/1428439>
[03:09] <menn0> ericsnow: yeah, that's why I suggested it with some uncertaintity
[03:09] <menn0> ericsnow: just leave it
[03:09] <ericsnow> menn0: k
[03:10] <ericsnow> menn0: thanks for the reviews
[03:11] <menn0> ericsnow: np
[04:20] <anastasiamac> axw: wallyworld: https://github.com/go-amz/amz/pull/34
[04:23] <axw> anastasiamac: looking
[04:30] <dimitern> now that's much better - from 58 PRs down to 38
[04:31]  * thumper is done
[04:31] <thumper> laters
[04:42] <anastasiamac> axw: wallyworld: tyvm for review :D all updated but I do not have merge rights on goamz...
[04:43] <wallyworld> np, i can do it
[04:43] <wallyworld> anastasiamac: merged
[04:43] <wallyworld> one more branch to go
[04:44] <wallyworld> axw: did you have anything to say wrt that maas doc the other day?
[04:45] <axw> wallyworld: I added comments already
[04:45] <wallyworld> ah, ty. i need to learn how to use refreah i think
[04:45] <axw> wallyworld: essentially, LGTM.
[04:45] <wallyworld> great
[04:46] <anastasiamac> wallyworld:  when u say "1 more branch",  which one u have in mind? ec2 pricing?
[04:46] <wallyworld> anastasiamac: updating the current juju core branch to add instance types, depes, and pricing yeah
[04:46] <anastasiamac> wallyworld: k :D
[05:13] <anastasiamac> axw: wallyworld: pricing branch http://reviews.vapour.ws/r/1073/
[05:13] <wallyworld> already looking
[05:13] <anastasiamac> wallyworld: i *think* i've fixed bad formatting ...
[05:13] <anastasiamac> wallyworld: tabs vs spaces, etc...
[05:14] <wallyworld> yep, looks much beter
[05:16] <wallyworld> anastasiamac: and there's no cost info for chinese regions?
[05:17] <anastasiamac> wallyworld: i could not find any chines prices... maybe they r on chinese site but I do not read chines :(
[05:17] <anastasiamac> wallyworld: i have looked at chines site in english but nothing...
[05:18] <anastasiamac> chinese*
[05:18] <wallyworld> hmmm, i can't see how juju would work in china then as instance selection is broken without cost info from what i can see
[05:18] <anastasiamac> do we have any means of testing ?..
[05:19] <wallyworld> not easily
[05:19] <anastasiamac> wallyworld: unless we put 0 for everything?...
[05:19] <wallyworld> it's mor ethan just cost, it's also knowing what instance types are available
[05:21] <anastasiamac> wallyworld: would it be a separate bug tho? so this PR added frankfurt for bug 1428117 and c4+others for bug 1427840
[05:21] <mup> Bug #1428117: EC2 eu-central-1 region not in provider <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1428117>
[05:21] <mup> Bug #1427840: ec2 provider unaware of c3 types in sa-east-1 <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1427840>
[05:21] <wallyworld> yeah
[05:22] <wallyworld> anastasiamac: fix axw's issue and then ship
[05:25] <wallyworld> anastasiamac: chinese instance types http://www.amazonaws.cn/en/ec2/details/
[05:25] <wallyworld> so we can add those before shipping
[05:26] <wallyworld> set all costs to 0 or something if no cost info can be found
[05:26] <anastasiamac> wallyworld: k but what shall i add for price? 0...?
[05:26] <anastasiamac> wallyworld: k
[05:35] <wallyworld> anastasiamac: school pickup time back later, andrew can check the final branch before landing
[05:35] <anastasiamac> wallyworld: school pickup but will try to repropose for axw :D
[05:37] <anastasiamac> axw:wallyworld: btw, i'll try to do the same with USGov region as with  China - just add instance types with 0 cost
[05:49] <jw4> per special request by marcoceppi for 1.23 - juju action status now returns multiple matches or all if no prefix is given: OCR PTAL http://reviews.vapour.ws/r/1085/
[06:49] <axw> jw4: added some comments
[06:59] <axw> wallyworld: responded to your comments on my branch, would appreciate another look when you've got time
[07:26] <anastasiamac> axw: wallyworld is delayed - car broke down :(
[07:26] <axw> doh
[07:27] <anastasiamac> axw: yep :( dunno what's with the car but it's realllly hot here today
[07:42] <mup> Bug #1425788 changed: multiple definition of http.HandlerFunc <ci> <gccgo> <regression> <test-failure> <juju-core:Fix Released by dimitern> <https://launchpad.net/bugs/1425788>
[08:21] <mup> Bug #1292536 changed: maas provider apt-get install bridge-utils should  be better <maas-provider> <network> <tech-debt> <juju-core:Fix Released> <https://launchpad.net/bugs/1292536>
[08:21] <mup> Bug #1377262 changed: please expose network-bridge to manual provider also <cts> <cts-cloud-review> <maas-provider> <network> <juju-core:Won't Fix> <https://launchpad.net/bugs/1377262>
[08:51] <mup> Bug #1314442 changed: MAAS non-deterministic private-address with non-ethN interfaces <addressability> <canonical-is> <maas-provider> <network> <production> <juju-core:Fix Released> <https://launchpad.net/bugs/1314442>
[09:17] <wallyworld> axw: sorry about delay, car broke, heavy traffic, waited ages for tow truck
[09:18] <axw> wallyworld: no worries. that sucks :(
[09:18] <wallyworld> yeah, clutch cylinder i think
[09:26] <axw> wallyworld: doh, I think anastasiamac may have forgotten to upload her changes before merging
[09:27] <axw> other things weren't updated either
[09:36] <wallyworld> axw: yeah, i figured that after seeing another issue that was unresolved
[09:49] <axw> anastasiamac: I'm definitely looking at the latest diff on RB
[09:49] <axw> I'll check GitHub
[09:49] <anastasiamac> wallyworld: axw: my bad - did not push :D
[09:49] <anastasiamac> fixing it noww...
[09:58] <anastasiamac> axw: wallyworld: probably cleaner as separate pr?.. :D http://reviews.vapour.ws/r/1087/
[09:59] <axw> anastasiamac: LGTM
[09:59] <anastasiamac> axw: :P
[10:00] <anastasiamac> axw: brain-numbing experience over :D tyvm for urs and wallyworld attention to detail!!
[10:00] <axw> anastasiamac: :)
[10:05] <axw> jam: team meeting, if you want to join
[10:23] <dimitern> TheMue, dooferlad_, guys let's do our standup now?
[10:23] <dooferlad_> dimitern: sure
[10:23] <TheMue> dimitern: omw
[10:24] <dimitern> I'm in the hangout
[12:29] <axw> katco: I'd appreciate another look over my branch in your day, I've responded to your comments - thanks
[14:21] <jw4> axw: I assume you're off now, but thanks for the review
[14:23] <jw4> TheMue: thanks for your review - do you want to give it one last pass before merging? http://reviews.vapour.ws/r/1085
[14:24] <TheMue> jw4: sure
[14:32] <TheMue> jw4: looks good now
[14:32] <jw4> TheMue, ta
[14:32] <TheMue> jw4: yw
[15:02] <marcoceppi> is the environment UUID per .jenv file or is it per bootstrap?
[15:02] <marcoceppi> if i create an environment, bootstrap, destroy, bootstrap again does it have the same UUID?
[15:04] <perrito666> natefinch: standup?
[15:06] <natefinch> perrito666: oops, lost track of time, thanks
[15:39] <sinzui> natefinch, dimitern (and ericsnow) I reported bug 1428692 about a vivid regression
[15:39] <mup> Bug #1428692: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:40] <ericsnow> sinzui: yep, saw that :(
[15:40] <ericsnow> sinzui: BTW, sounds like the systemd cutover is scheduled for today
[15:40] <sinzui> ericsnow, I did a dist-upgrade on the machine and cleared containers hoping the issue was a stale machine
[15:40] <ericsnow> sinzui: so that test would be failing either way
[15:41] <sinzui> ericsnow, the test now runs with --debug to get more info too
[15:41] <ericsnow> sinzui: unfortunately the logs for the failed job aren't too informative
[15:41] <ericsnow> sinzui: --debug will help
[15:41] <ericsnow> sinzui: so thanks
[15:45] <perrito666> ericsnow: wallyworld natefinch http://ftp.osuosl.org/pub/fosdem//2015/devroom-go/
[15:45] <ericsnow> perrito666: cool
[15:47] <perrito666> word of advice, your wife will scold you if you try to watch those on the big tv during dinner
[15:51] <sinzui> dimitern, you made bug 1428345 high. Which milestone does it go to? 1.23-beta1 or 1.24?
[15:51] <mup> Bug #1428345: unit-get private-address returns ipv6 address <addressability> <ipv6> <manual-provider> <network> <juju-core:Triaged> <https://launchpad.net/bugs/1428345>
[15:51] <mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:52] <mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:52] <mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:52] <jw4> mup, bad boy
[15:52] <mup> jw4: Roses are red, violets are blue, and I don't understand what you just said.
[15:52] <dimitern> sinzui, hey, yes I did, but it's still getting investigated - so 1.24 I guess
[15:52] <mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:52] <mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:52] <sinzui> thank you dimitern
[15:52] <mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:53] <mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:53] <dimitern> mup is heading for an excessive flood quit message
[15:53] <mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:53] <mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:53] <mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:54] <mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:54] <mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:54] <mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:55] <mup> Bug #1428692 changed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:55] <mup> Bug #1428692 was filed: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:55] <perrito666> dimitern: mup is heading for a kick in the head
[15:55] <perrito666> I am not sure what is triggering those, when I see the bug there seems to be no changes
[15:58] <dimitern> mup, shut up
[15:58] <mup> dimitern: I really wish I understood what you're trying to do.
[15:59] <dimitern> perrito666, it's seeing somebody (itself) mentioning bug # and goes
[15:59] <dimitern> bug 1428692
[15:59] <mup> Bug #1428692: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[15:59] <ericsnow> mup is taunting me
[15:59] <dimitern> lol
[15:59] <ericsnow> mup, sit
[15:59] <mup> ericsnow: Unknown commands are unknown.
[15:59] <ericsnow> mup, stay
[15:59] <mup> ericsnow: In-com-pre-hen-si-ble-ness.
[16:00] <perrito666> dimitern: most bots have a feat not to listen to themselves
[16:02] <dimitern> perrito666, yeah, but this one is written in erlang ;)
[16:03] <perrito666> dimitern: I thought this thing was written in go
[16:03] <perrito666> or I missed a joke there
[16:03] <dimitern> perrito666, https://launchpad.net/mup
[16:04] <dimitern> :) no joke - it's a dead serious language lol
[16:05]  * TheMue reads Erlang?
[16:06] <TheMue> didn't know that it's written in a cool language
[16:06] <perrito666> dimitern: https://github.com/go-mup/mup
[16:07] <perrito666> TheMue: erlang is a fine language, if you are an ericsson telephone central
[16:07] <katco> mup used to be written in erlang, niemeyer ported it to go
[16:07] <TheMue> perrito666: or a couchdb or rabbitmq or ejabberd develoepr (and many more)
[16:07] <Spads> no, couchdb developers did not really know erlang
[16:08] <dimitern> :D
[16:09] <TheMue> maybe, never looked into the couch details
[16:12] <perrito666> TheMue: I agree there are many things written in erlang, yet its not cool in all contexts :p
[16:12] <TheMue> perrito666: would write a mobile game app with it, yes
[16:13] <TheMue> perrito666: but for something like juju it would be fine
[16:13] <niemeyer> perrito666, dimitern, TheMue, katco, ericsnow: Sorry for the trouble.. Launchpad seems to be giving inconsistent results, likely as a side effect of caching+balancing
[16:14] <niemeyer> It's not listening to itself, though.. note the filed/changed/filed/changed/etc
[16:14] <TheMue> niemeyer: mup simply has been lonely and wanted to talk to us
[16:14] <perrito666> niemeyer: you took the trouble to write the thing, no need to apologize, we are just curious on what was the cause
[16:14] <dimitern> niemeyer, ah, I thought something more sinister was happening :)
[16:14] <katco> TheMue: i like that explanation :)
[16:15] <niemeyer> I will increase the delay between updates, to give time for Launchpad to update its internal cache
[16:16] <perrito666> I see you are hitting the same change in different caches each time, that is  an odd thing for launchpad to do
[16:55] <dimitern> sinzui, is it possible to change http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/jujupy.py#L284 so it calls subprocess.check_output(args, env=env) instead of check_call ?
[16:57] <sinzui> dimitern, no because we already have get_juju_output() whcih does that. what callsite needs to look at the output?
[16:58] <dimitern> sinzui, well, looking at that vivid failure it's hard to understand whether "Operation failed: No such file or directory" comes from juju bootstrap's output or something else
[17:00] <dimitern> sinzui, for example, it could be coming from dump_env_logs in the except BaseException as e: block below
[17:01] <dimitern> sinzui, no, actually not that block, but the previous try that ends with a raise
[17:06] <sinzui> dimitern, I don't think your going to see more information by switching which method we call. We are seeing the stdout and stderr in the console log already. The output captured would be the same as we are seeing now
[17:08] <dimitern> sinzui, I guess so
[17:08] <sinzui> dimitern, I am going to run this my hand on the machine to see if I get something more
[17:09] <dimitern> sinzui, thanks!
[17:10] <dimitern> sinzui, while you're there can you check if it runs out of disk space (or mongo runs out of the prealloc block)?
[17:15] <dimitern> sinzui, it just *smells* like a mongo issue - i've just noticed juju-mongodb in vivid is /usr/lib/juju/bin/mongod --version: "db version v2.4.10\nThu Mar  5 15:00:16.736 git version: nogitversion\n"
[17:16] <dimitern> sinzui, while in the cloud-tools, in trusty and pretty much everywhere we run and test with officially it's 2.4.9-0ubuntu3
[17:17] <aisrael> sinzui: FYI, this bug doesn't seem to be fixed: https://bugs.launchpad.net/juju-core/+bug/1424069
[17:17] <mup> Bug #1424069: juju resolve doesn't recognize error state <resolved> <juju-core:Fix Released> <https://launchpad.net/bugs/1424069>
[17:24] <sinzui> dimitern, sorry this is taking longer. I just verified other juju do work on the machine. Mongo doesn't seem to be a factor with 1.21 and 1.22
[17:28] <dimitern> sinzui, is it the same version?
[17:28] <sinzui> dimitern, yes, there is only one mongod on the host
[17:29] <dimitern> sinzui, and where is that one ("gitnorevision"?) coming from
[17:29] <sinzui> dimitern, I don't know.
[17:30] <sinzui> dimitern, we are testing a package we built else where on the vivid machine. the machine was dist-upgraded to get the current packages, of which juju-db will be selected
[17:32] <dimitern> sinzui, ok, so this is the first time we're actually testing with that version of mongo?
[17:34] <sinzui> dimitern, I think so. I see juju-mongodb at 2.4.10-0ubuntu1
[17:38] <sinzui> dimitern, this is the log from the manual run https://bugs.launchpad.net/juju-core/+bug/1428692/+attachment/4335369/+files/vivid-bootstrap.log
[17:38] <mup> Bug #1428692: cannot boostrap vivid: Operation failed: No such file or directory <ci> <local-provider> <regression> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1428692>
[17:38] <dimitern> sinzui, ok, looking - thanks!
[17:40] <sinzui> dimitern, though the bootstrap failed, the mongod is still up. Is there anything you want me to do to interrogate it?
[17:40] <dimitern> sinzui, I'd appreciate you can paste cloud-init-output.log and /var/log/syslog where mongo logs a lot
[17:42] <dimitern> sinzui, or if there's nothing mongo related in syslog, then /var/log/mongodb/mongod.log if it exists
[17:44] <sinzui> dimitern, this is the cloud-init-output.log https://pastebin.canonical.com/127005/
[17:44] <dimitern> ok, thanks again
[17:45] <dimitern> sinzui, that's how it ends? well, we'll need to look at /var/log/cloud-init.log then just in case - it should say "cloud-init ver finished" etc.
[17:46] <sinzui> dimitern, I don't see that. remember that this is a localhost
[17:46] <dimitern> sinzui, ah, right
[17:47] <dimitern> sinzui, so then it's not strange
[17:48] <dimitern> sinzui, and you can confirm the machine is not out of disk space, right?
[17:49] <sinzui> dimitern, 26G free
[17:49] <dimitern> sinzui, ok, good
[17:52] <sinzui> dimitern, there are no logs for the mongo in the juju home dir or in /var/log
[17:53] <dimitern> sinzui, and you said it's still running?
[17:53] <dimitern> sinzui, is it listening on 37017?
[17:54] <sinzui> dimitern, I see the pid
[17:59] <sinzui> dimitern, I think this is just a zombie left behind from a failed destroy. Juju removed itself from the system, but left the juju-db behind
[18:00] <dimitern> sinzui, and there's nothing you say in /var/log/syslog or /var/log/* about mongo?
[18:04] <sinzui> dimitern, There are lines in the syslog. I am collecting them
[18:06] <dimitern> sinzui, good
[18:06] <sinzui> dimitern, this is from my run bootstrapped https://pastebin.canonical.com/127008/
[18:07] <cmars> anyone see map ordering-type failure in firewallerSuite.TestWatchOpenedPorts ?
[18:07] <cmars> go1.4 here
[18:09] <sinzui> aisrael, okay, I will reopen the bug
[18:10] <mup> Bug #1424069 was filed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
[18:10] <mup> Bug #1424069 changed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
[18:11] <mup> Bug #1424069 was filed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
[18:11] <mup> Bug #1424069 changed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
[18:11] <mup> Bug #1424069 was filed: juju resolve doesn't recognize error state <resolved> <juju-core:Triaged> <https://launchpad.net/bugs/1424069>
[18:11] <sinzui> cmars, that test doesn't fail on vivid which is using go1.3
[18:13] <dimitern> sinzui, looking
[18:13] <dimitern> cmars, haven't checked recently with 1.4
[18:21] <dimitern> sinzui, ok so now that's some error in there
[18:25] <dimitern> sinzui, did you stop mongod manually?
[18:27] <cmars> dimitern, sinzui should i open a bug? http://paste.ubuntu.com/10541924/
[18:30] <cmars> sinzui, here it is: https://bugs.launchpad.net/juju-core/+bug/1428788
[18:30] <mup> Bug #1428788: Probabilistic test failure in firewallerSuite.TestWatchOpenedPorts <juju-core:New> <https://launchpad.net/bugs/1428788>
[18:30] <mup> Bug #1428788 was filed: Probabilistic test failure in firewallerSuite.TestWatchOpenedPorts <juju-core:New> <https://launchpad.net/bugs/1428788>
[18:31] <dimitern> cmars, I seem to recall a bug about this or similarly named test - can you check if there is one already?
[18:31] <cmars> dimitern, looking
[18:32] <cmars> dimitern, i see no obvious matches
[18:32] <sinzui> cmars, you can at medium tagged intermittent-failure. CI only saw 1 failure with that test a few days ago on ppc64el gccgo. It was a panic, not an assert failure
[18:33] <cmars> sinzui, idk if that's the same thing. does gccgo even scramble map ordering? I forget..
[18:33] <sinzui> cmars, it does. it behaves like go1.3's spec
[18:33] <sinzui> cmars, but vivid is go 1.3 and we haven't seen tht failure
[18:34] <cmars> sinzui, not yet :)
[18:34] <perrito666> sinzui: well its a non deterministic failure, I presume that if you constraint enough the memory you will see it
[18:41] <dimitern> sinzui, so were there 2 mongod running on that machine? one from juju and another one?
[18:42] <sinzui> dimitern, I didn't see one. I only terminated the single pid
[18:43] <sinzui> dimitern, remember that we run other jujus that they don't fail
[18:44] <sinzui> dimitern, The machine is very idle right now I can run the job again
[18:45] <sinzui> dimitern, only one job can use the machine at a time. so it is unlikely for another to be up. if one was, the call to destroy-environment --force would remove it. That is what I called to ensure the mongo was removed
[18:48]  * sinzui rebuilds and inspects which procs are left behind
[18:48] <dimitern> sinzui, ok, seems all in order then
[18:49] <dimitern> sinzui, I mean it's not mongo most likely, but I was really suspicious due to the version and some bug reports for 2.4.10 I've read :)
[18:49] <sinzui> dimitern, we got the expected failure and I can see a mongo was left behind
[18:51] <dimitern> sinzui, was that mongo there before the bootstrap?
[18:52] <sinzui> no
[18:52] <sinzui> i dimitern it was just created and left behind by the juju. it claims to have destroyed the env, but it did not
[18:53] <sinzui> dimitern, all tests start with destroy-environment --force to be sure the env is clean
[18:53] <sinzui> dimitern, I am setting up an upgrade test on the machine that will show you that other jujus are happy
[18:59] <dimitern> sinzui, ok, sounds good
[19:05] <niemeyer> perrito666, dimitern, TheMue, katco, ericsnow: The delay was updated.. please let me know if you see any other issues
[19:06] <ericsnow> niemeyer: k, thanks
[19:06] <katco> niemeyer: ty!
[19:06] <perrito666> niemeyer: thanks a lot, sorry for the complaining
[19:06] <niemeyer> perrito666: No worries, and totally justified
[19:13] <TheMue> niemeyer: thanks for update, and never has been meant as complain
[19:14] <ericsnow> anyone PTAL (revert vivid-breaking merge): http://reviews.vapour.ws/r/1090/
[19:18] <sinzui> dimitern, good news of sorts. http://juju-ci.vapour.ws:8080/job/local-upgrade-vivid-amd64/3/ shows other juju bootstrap, but we cannot upgrade. Since we had a server running. we got logs
[19:23] <natefinch> ericsnow: ship it
[19:23] <ericsnow> natefinch: thanks
[19:24] <natefinch> ericsnow: I just skimmed it... it 's just a revert, so I trust that there shouldn't be much to go wrong.  .... which makes me wish there was a tool that could just look at this and say "yep, this is just a revert of that other change".
[19:24] <dimitern> sinzui, great!
[19:24] <dimitern> sinzui, I'll have a look tomorrow though - it was a rather long day
[19:24] <sinzui> thank you for your time dimitern
[19:25] <dimitern> not at all :)
[19:25] <perrito666> natefinch: it would be nice if we could get the bot to trigger reverts from github
[19:26] <perrito666> with a $$unmerge$$ or smth like that
[19:26] <natefinch> perrito666: that's brilliant
[19:27] <natefinch> Btw, for those interested, Brian Kernighan (the K in K&R's C Programming) is writing a book on Go: http://www.amazon.com/Programming-Language-Addison-Wesley-Professional-Computing/dp/0134190440/
[19:28] <mgz> perrito666: revert isn't an entirely automatic process, the merge can need manual resolution
[19:28] <perrito666> dunno K&D does not soound as cool as K&R :p
[19:29] <mgz> (could be done in the common case though)
[19:29] <perrito666> mgz: I believe that github only offers it after doing the same analisys that it does for merge
[19:41] <perrito666> man, processAgent is an elussive piece of code
[19:45] <ericsnow> sinzui: I've landed a revert of what I believe is the merge that broke the vivid test
[19:46] <sinzui> thank you ericsnow
[19:46] <ericsnow> sinzui: I expect that it will also clear up the issue of the zombie mongod
[20:12] <jw4> natefinch, per davecheney command I've pre-ordered the book
[20:14] <perrito666> jw4: wow he has such commands? how does it work? is it something like davecheney order book?
[20:18] <jw4> perrito666, hahah
[20:23] <natefinch> jw4: it'll be good.  K&R's C influenced a generation of programmers.
[20:24] <perrito666> natefinch: you do need to bear in mind that is that generation that coded the pieces of code we hate the most :p
[20:47] <natefinch> ericsnow: you around?
[20:47] <ericsnow> natefinch: yep
[20:47] <natefinch> "there was an error displaying this diff": http://reviews.vapour.ws/r/861/diff/#
[20:48] <natefinch> It says to please try again... does that mean like rbt post or something?
[20:48]  * natefinch forgets how to do this stuff manually
[20:49]  * TheMue has to refresh his Go book, it's already 4 years old
[20:50] <natefinch> TheMue: there aren't many good choices right now.  There's this upcoming Kernighan one, plus some of the Gophercon people are working on one
[20:50] <jw4> TheMue, that's the problem with being an early adopter - all the investment into books when the technology is really young
[20:51] <jw4> natefinch, agree about K&$
[20:51] <jw4> K&R too
[20:51] <perrito666> I wonder if it comes for kindle
[20:51] <natefinch> The Gophercon guys are writing this one: http://www.manning.com/ketelsen/
[20:52] <TheMue> jw4: funnily Go hasn't changed a lot since then, only details. but more experience about common patterns
[20:52] <TheMue> jw4: and surely the packages
[20:52] <ericsnow> natefinch: I've been seeing that more frequently of late
[20:52] <jw4> TheMue, yeah
[20:53] <TheMue> jw4: and mine is sadly only available in German
[20:53] <ericsnow> natefinch: it may be that unicode characters are starting to leak into commits (I've seen RB struggle with unicode)
[20:53] <ericsnow> natefinch: but it's probably not that
[20:53] <ericsnow> natefinch: did you do a rebase in there somewhere?  that can confuse RB
[20:53] <natefinch> ericsnow: yes. :/
[20:54]  * natefinch loves teh rebase
[20:54] <ericsnow> natefinch: I expect that's it
[20:54] <natefinch> I didn't realize reviewboard didn't like it
[20:54] <ericsnow> natefinch: it's hit and miss
[20:54] <ericsnow> natefinch: I haven't looked into it too hard
[20:54] <jw4> I use rebase all the time and haven't had an issue yet...:(
[20:55] <jw4> I wonder what the secret ingredient is that triggers RB
[20:55] <ericsnow> natefinch: try using rbt -u to update the review request
[20:55] <natefinch> ericsnow: rbt is asking for authorization... remind me how to do that?
[20:55] <ericsnow> I think it's when you rebase and have a conflict that you have to resolve (so history changes)
[20:56] <ericsnow> natefinch: it's in docs/contributing/reviewboard...
[20:56] <ericsnow> natefinch: I'll look it up
[20:57] <ericsnow> natefinch: "username: <github username> password: oauth:<github username>@github"
[20:57] <natefinch> ericsnow: ok, thanks... I could have looked it up, just forgot where itwas
[20:57] <ericsnow> natefinch: no worries
[20:58] <natefinch> ericsnow: that did it, thanks
[20:58] <ericsnow> natefinch: cool, thanks
[20:59] <ericsnow> natefinch: I think RB stores the base revision when you first create the request (or the hook does for you)
[20:59] <ericsnow> natefinch: I probably just need to fix the hook to be cognizant of changes to the base revision
[21:00] <jw4> ericsnow, ah, that sounds like a plausible root cause for the display conflicts after rebasing when the base revision changes significantly
[21:00] <natefinch> conflicts?  Son of a....
[21:01] <ericsnow> yeah, he said conflicts :)
[21:01] <jw4> haha
[21:01] <ericsnow> jw4: if it gets to be much of a problem I'll look into fixing the hook
[21:02] <jw4> ericsnow, you've done a lot of work to give us nice review tools, thanks
[21:02] <natefinch> no no.. sorry, my branch has conflicts with master... in that file that was having problems. That may have been what caused RBT to puke
[21:02] <natefinch> ericsnow, jw4: +1
[21:02] <ericsnow> natefinch: ah hah
[21:04] <perrito666> go test github.com/juju/juju/cmd/juju/... takes too long
[21:05] <ericsnow> perrito666: right up there with replicaset
[21:18] <natefinch> man yaml is terrible
[21:23] <perrito666> anyone knows where the filtering happens for juju status comand?
[21:24] <perrito666> I think I found it
[21:42] <perrito666> there is a LOT of unhappy poorly documented unclear code in the filtering
[21:54] <ericsnow> sinzui, natefinch: Monday is D-Day: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-March/001130.html
[21:55] <sinzui> thank you eric
[22:08] <sinzui> ls  /var/lib/mongodb/
[22:08] <sinzui> ls  /var/log/mongodb/
[22:08] <sinzui> ls /etc/default/mongodb
[22:09] <jw4> sinzui, wrong window?
[22:09] <sinzui> jw4, yes, thank you
[22:09] <jw4> lol :)
[22:09] <jw4> I thought a ping might help
[22:11] <thumper> perrito666: filtering of what?
[22:14] <perrito666> thumper: nevermind, tx, I was trying to make sure I had all the right pieces added to BuildPredicate and surounding code
[22:14] <perrito666> I did
[22:14] <perrito666> that could really benefit from a couple of comments
[22:15] <perrito666> ok EOD
[22:15] <perrito666> cheers
[22:17] <jw4> cheers perrito666
[22:34] <ericsnow> cmars: any reason why you have 2 review requests up for mongo logs?
[22:34] <cmars> ericsnow, rbt freaked out on me. deleted the first one
[22:59] <ericsnow> cmars: I've reviewed your mongod log patch
[22:59] <cmars> ericsnow, thanks
[22:59] <ericsnow> cmars: np :)
[23:00] <cmars> ericsnow, i'm thinking of adding --quiet as well. you could always turn that on with the mongo setParameter command if you needed the replication info
[23:00] <cmars> currently bootstrapping with that option enabled
[23:00] <ericsnow> cmars: or a feature flag <wink>
[23:00] <cmars> ericsnow, ooh good point
[23:01] <ericsnow> cmars: it could also key of juju's debug level
[23:02] <cmars> ericsnow, interesting.. how would I read that?
[23:02] <ericsnow> cmars: no clue :)
[23:04]  * ericsnow takes off on an errand for a bit
[23:44] <mup> Bug #1428893 was opened: agent-state-info: no matching tools available <oil> <juju-core:New> <https://launchpad.net/bugs/1428893>
[23:50] <cmars> ericsnow, updated 1093
[23:53] <ericsnow> cmars: LGTM (but I'm not a senior reviewer)
[23:53] <cmars> ericsnow, thanks!


[19:35] <bkerensa> slangasek: http://www.oregonlive.com/hillsboro/index.ssf/2013/11/hillsboro_school_district_cons_1.html#incart_river
[19:35] <bkerensa> Ubuntu ^ Hillsboro
[19:44] <blkperl> bkerensa: lulz, "It has all the same features" is a lie
[19:44] <bkerensa> blkperl: that was also a misquote
[19:44] <bkerensa> I never said darn either
[19:44] <bkerensa> lol
[19:44] <bkerensa> I said it has a line up of similar features
[19:45] <blkperl> oregonian likes to misquote a lot....
[19:45] <bkerensa> blkperl: I think he was perhaps not writing down what I was saying or recording idk
[19:46] <blkperl> shoddy journalism? shocking! :D
[19:46] <bkerensa> Well you know half of Oregonians posts are copied from press releases
[19:46] <bkerensa> heck they strip out suspect details when reporting crime
[19:49] <bkerensa> wait
[19:49] <bkerensa> Kerensa said of Ubuntu's office suite
[19:49] <bkerensa> meh
[19:49] <bkerensa> its not Ubuntu's office suite either
[19:49] <bkerensa> damn journalists
[21:05] <bkerensa> adam_g: happy birthday!
[23:29] <c_smith> lulz @ the Oregonian's (and journalism in general) failure at grasping key details


[10:51] <java_lfs> A "seek" with offset larger than 2GB (-1)  does not work under Ubuntu 10.04 32Bit. But in the bash shell I can easily cat a 8 GB file. How can I fix this 2GB barrier in Java?
[10:51] <java_lfs> .seek(1024*1024*1024*2-1); Result: OK. .seek(1024*1024*1024*2); Result: java.io.IOException: Negative seek offset
[10:53] <java_lfs> I would like to use Large File Support in Java, without the need to switch to a 64Bit JVM. Is this possible ?
[11:37] <java_lfs> anyone there ?


[04:08] -queuebot:#ubuntu-release- New: accepted ceph [amd64] (eoan-proposed) [14.2.1-0ubuntu1]
[04:08] -queuebot:#ubuntu-release- New: accepted ceph [s390x] (eoan-proposed) [14.2.1-0ubuntu1]
[04:08] -queuebot:#ubuntu-release- New: accepted ceph [i386] (eoan-proposed) [14.2.1-0ubuntu1]
[04:08] -queuebot:#ubuntu-release- New: accepted ceph [arm64] (eoan-proposed) [14.2.1-0ubuntu1]
[04:08] -queuebot:#ubuntu-release- New: accepted ceph [ppc64el] (eoan-proposed) [14.2.1-0ubuntu1]
[04:09] -queuebot:#ubuntu-release- New: accepted ceph [armhf] (eoan-proposed) [14.2.1-0ubuntu1]
[04:10] <tsimonq2> infinity: Right, so our workaround for that is literally just running "touch /boot/initrd.img-$(uname -r)" to trick initramfs-tools. :P
[04:18] <tsimonq2> infinity, vorlon, xnox: Upstream Calamares bug I just filed, in case anyone wants to add anything: https://github.com/calamares/calamares/issues/1180
[04:18] <gitbot> calamares issue 1180 in calamares "update-initramfs should be more specific" [Open]
[04:19] <tsimonq2> I don't have access to my GPG key at the moment, so I'll hold off on submitting the bug to Debian.
[05:36] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1044.49] (kernel)
[05:36] -queuebot:#ubuntu-release- Unapproved: ceph (disco-proposed/main) [13.2.4+dfsg1-0ubuntu2 => 13.2.6-0ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[05:37] -queuebot:#ubuntu-release- Unapproved: ceph (cosmic-proposed/main) [13.2.4+dfsg1-0ubuntu<IP_ADDRESS> => 13.2.6-0ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[05:40] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1044.49]
[07:06] -queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.17-0ubuntu<IP_ADDRESS> => 9.5.18-0ubuntu<IP_ADDRESS>] (core)
[08:05] -queuebot:#ubuntu-release- Unapproved: accepted vaultlocker [source] (bionic-backports) [1.0.3-0ubuntu<IP_ADDRESS>~ubuntu18.04.1]
[09:13] -queuebot:#ubuntu-release- New binary: brasero [i386] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
[09:13] -queuebot:#ubuntu-release- New binary: brasero [s390x] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
[09:14] -queuebot:#ubuntu-release- New binary: brasero [amd64] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
[09:14] -queuebot:#ubuntu-release- New binary: brasero [ppc64el] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
[09:18] -queuebot:#ubuntu-release- New binary: brasero [arm64] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
[09:18] -queuebot:#ubuntu-release- New binary: brasero [armhf] (eoan-proposed/universe) [3.12.2-5ubuntu1] (ubuntu-desktop)
[09:36] -queuebot:#ubuntu-release- New: accepted brasero [amd64] (eoan-proposed) [3.12.2-5ubuntu1]
[09:36] -queuebot:#ubuntu-release- New: accepted brasero [armhf] (eoan-proposed) [3.12.2-5ubuntu1]
[09:36] -queuebot:#ubuntu-release- New: accepted brasero [ppc64el] (eoan-proposed) [3.12.2-5ubuntu1]
[09:36] -queuebot:#ubuntu-release- New: accepted brasero [arm64] (eoan-proposed) [3.12.2-5ubuntu1]
[09:36] -queuebot:#ubuntu-release- New: accepted brasero [s390x] (eoan-proposed) [3.12.2-5ubuntu1]
[09:36] -queuebot:#ubuntu-release- New: accepted brasero [i386] (eoan-proposed) [3.12.2-5ubuntu1]
[10:07] -queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1014.15~18.04.1] (kernel)
[10:07] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1035.37] (no packageset)
[10:15] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1014.15~18.04.1]
[10:15] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1035.37]
[13:48] <acheronuk> vorlon: would it perhaps be ok to not have the new appstream in proposed until the lmdb MIR is done? it will block important parts of new Plasma versions until then if it stays
[13:59] <seb128> acheronuk, why not filing that MIR request now if that's important to you guys? maybe the MIR team can help to get it reviewed, always best to move toward the goal rather than stepping back when we can
[14:00] <teward> archive admin, at the request of the ubuntu studio devs please reject ubuntustudio-menu-add in Eoan NEW queue, they discovered a bug after they said it was ready to upload.  (I think i'mma sit on them for a few days this time before they get another consideration for it getting a sponsor...)
[14:00]  * teward preps the drive-by fixes for other things and another NGINX upload in the interim
[14:03] <seb128> teward, done
[14:03] <teward> seb128: thanks
[14:03] <seb128> np
[14:03] -queuebot:#ubuntu-release- New: rejected ubuntustudio-menu-add [source] (eoan-proposed) [0.1]
[14:04] <teward> seb128: hate having to keep asking it to be NACK'd but the first was security/code concern, this time they discovered a bug >.>
[14:04] <teward> maybe I should sit on their project leader for a while, lol...
[14:04] <seb128> teward, well, depending of the bug it's not the end of the world to let it in the review queue and do another upload later to fix the bug
[14:04] <seb128> depends if it's ok to let it in with that bug or not
[14:05] <seb128> while it's in the queue it has more chances to be NEW reviewed :)
[14:05] <teward> seb128: AIUI the bug is it doesn't work as is with their attempt to move to array-based subprocess calls in the python
[14:05] <teward> which they only discovered AFTER asking for the second sponsoring.
[14:05] <teward> at least the shell=True subprocess calls for cp and rm are gone... *shivers*
[14:05] <teward> thanks sarnold for pointing those out :P
[14:05] <seb128> ok, probably makes sense to postpone then in that case
[14:05] <teward> seb128: yep.
[14:06] <teward> seb128: i also have inside knowledge that they're doing this in Python for compat but they use a lot of other language 'approaches' to things, and are a tad new to the Python.  (if you look at the changelogs I've added a few things with Eickmeyer's approval to fix some of the major concerns)
[14:06] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1016.18] (kernel)
[14:07] <teward> right now though NGINX needs my attention :p
[14:07] <teward> distropatch for a PIDfile race condition problem
[14:07] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1016.18]
[14:56] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1009.9] (core, kernel)
[14:57] <teward> seb128: wow confusion is chaos, but it seems they wer ebugging me on A DIFFERENT package >>>
[14:57] <teward> i think context is key in things :|
[14:57]  * teward once again uploads this to NEW for them.
[14:57]  * teward then returns to watching update_excuses and update_output with regards to NGINX
[14:58] <seb128> teward, ah :)
[14:58] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1009.9]
[14:58] <teward> seb128: BUT at least now i can focus on nginx for the next... *checks averate timespan* ... 8 hours.
[14:58] <seb128> that's a long day!
[14:58] -queuebot:#ubuntu-release- New source: ubuntustudio-menu-add (eoan-proposed/primary) [0.1]
[14:59] <teward> seb128: nah that's just how long things're going to take xD
[14:59] <teward> because i still have my full time job as well :)
[14:59] <teward> seb128: unrelated, I don't think there's anything that'd block ubuntustudio-menu-add so if you or another AA have some spare cycles to look at that, I'm sure Eickmeyer would be appreciative
[14:59] <teward> :P
[15:00] <Eickmeyer> ^he speaks the truth
[15:03] <teward> note i don't care either way
[15:03] <teward> Eickmeyer is the one who cares :P
[16:15] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1048.52] (kernel)
[16:15] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1016.18~16.04.1] (kernel)
[16:15] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1035.37~16.04.1] (kernel)
[16:16] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1011.12] (no packageset)
[16:20] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1011.12]
[16:20] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1048.52]
[16:20] -queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1016.18~16.04.1]
[16:20] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1035.37~16.04.1]
[16:37] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.5+dfsg-0ubuntu2.1 => 5.9.5+dfsg-0ubuntu2.3] (kubuntu, qt5, ubuntu-desktop)
[17:13] -queuebot:#ubuntu-release- New binary: node-d3-scale-chromatic [amd64] (eoan-proposed/none) [1.3.3-1] (no packageset)
[17:13] <vorlon> acheronuk: as seb128 says, it would be better to move appstream forward rather than removing it from -proposed.  also, merely removing appstream doesn't unblock plasma, you'd also need to reupload and rebuild... someone should at least start the MIR
[17:27] <acheronuk> vorlon: LP: #1833745
[17:30] <acheronuk> plasma will be rebuilt on Tuesday anyway, as there is a new bugfix release then
[17:55] <wxl> @tsimonq2: looks like adam and i both hit that one up
[17:57] <vorlon> acheronuk: do you plan to fill it out with the template as described on https://wiki.ubuntu.com/MainInclusionProcess and subscribe ubuntu-mir team?
[18:01] <acheronuk> vorlon: most of those headings I really am not confident about filling in, so as Laney said the "<Laney> desktop team's going to sign on for that one" then its probably best for someone who can get it right at the start to do so
[18:02] <acheronuk> I would of course follow to try to learn...
[18:02] <vorlon> acheronuk: well, they get filled in as described on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[18:11] <tsimonq2> infinity, wxl: cala issue> Much appreciated.
[18:16]  * acheronuk nudges tsimonq2 towards that MIR
[18:18] <seb128> acheronuk, one random MIR example if you need one, https://bugs.launchpad.net/ubuntu/+source/libnfs/+bug/1746598
[18:21] <acheronuk> vorlon seb128: ok. let me look over the weekend. no promises. this is a bit out of my comfort zone
[18:23] <seb128> acheronuk, the sections are pretty straightforward and it should be fine if you follow the wiki/example but feel free to ping/email me if you have question/need help (I'm not on IRC during the w.e email might work better)
[18:24] <acheronuk> seb128: ok. thanks. not going to tackle it tonight at least, as beer o'clock is here
[18:24] <seb128> right, same here
[18:25] <seb128> enjoy beer o'clock & w.e :)
[18:25] <acheronuk> you too :)
[18:25] <seb128> thx
[19:04] <Eickmeyer> I have a relatively urgent SRU I'd like to get pushed through. Fairly trivial, it just, uh... is there a nicer term for idiot-proofing? (bug 1833740)
[19:05] <Eickmeyer> Debdiff is attached.
[19:05] <teward> Eickmeyer: why do you need to revert the debhelper compat for Eoan?
[19:05] <teward> just curious (looking at the packaging)
[19:06] <Eickmeyer> teward: Because bionic backports ppa.
[19:06]  * teward headscratches
[19:06] <teward> your changelog entries are wrong then
[19:06] <teward> debdiff MACL
[19:06] <teward> NACK'd for Sponsoring because it's not targeting Bionic, etc.
[19:06] <Eickmeyer> teward: The sponsoring in this case only needs to go to disco.
[19:12] <teward> then the changelog needs updated :P
[19:12] <teward> but i'll leave that for SRU, etc. to handle.
[19:12]  * teward goes back to kicking some python packages into submission
[20:11] <seb128> teward, Eickmeyer, looking to ubuntustudio-menu-add there is no COPYING file nor mention of copyright holder or license outside of the debian dir, that seems suboptimal
[20:13] <seb128> k, and on that side comment calling it a week, bye :-)
[21:12] -queuebot:#ubuntu-release- Unapproved: ubuntustudio-installer (disco-proposed/universe) [0.02 => 0.04~19.04.1] (ubuntustudio)
[21:50] <Eickmeyer> vorlon, infinity: Please reject ubuntustudio-menu-add per seb128's request. Those items have now been added.
[21:50] <Eickmeyer> teward: wrt ^ changes now in git.


[08:56] <Kilos> morning all
[09:30] <Morganvd> morning
[09:30] <Tonberry> hi
[09:31] <Kilos> hi Morganvd Tonberry
[10:23] <Tonberry> is it possible to compile a .deb for ubuntu 10.04 from a 10.10 box?
[10:25] <tumbleweed> Tonberry: yes. Some things (i.e. perl, php, some python) will build the same debs on 10.04 and 10.10. Otherwise you can use something like pbuilder to create a 10.04 chroot and build things in it.
[10:26] <Tonberry> i see
[10:26] <tumbleweed> oh, and obviously you could use a launchpad PPA to build it for 10.04 for you.
[16:54] <bmg505> Hello, trying to get used to this after 16+ years of slackware is quite an experience
[16:55] <superfly> hi bmg505
[16:58] <drubin> hi and welcome bmg505
[17:01] <Symmetria> ok
[17:01] <Symmetria> mirror.ac.za is back online completely reinstalled
[17:01] <Symmetria> and working 100%
[17:01] <Symmetria> its tcp stack has been properly optimized, the 10G nic seems a lot happier, and the large file systems are up and running
[17:24] <nlsthzn> Hey all :)
[17:32] <Symmetria> [19:27] <@ytti> why the egyptians got angry now?
[17:32] <Symmetria> [19:27] <@Lysis> because the streets are too crowded without internet
[17:32] <Symmetria> [19:27] <@Lysis> they couldn'T walk like an egyptian anymore
[17:34] <nlsthzn> Symmetria, :/ hope it doesn't get to ugly there
[17:34] <Symmetria> nlsthzn heh
[17:34] <Symmetria> 2 late for that
[17:34] <Symmetria> the army was refusing to help, so the latest news is that now the airforce is flying fighter jets low over the crowds to try scare em away
[17:34] <Symmetria> crowd is ignoring the jets as well
[17:35] <Symmetria> and I mean, wtf they gonna do with the jets, drop some missiles on the crowd? yeah right
[17:35] <nlsthzn> Symmetria: :( sad when ppl have to revert to this
[18:16] <superfly> nlsthzn: I think the word you are looking for is "resort", not "revert" ;-)
[18:17] <nlsthzn> superfly: yes, thanks ;)
[18:27] <inetpro> eish
[18:29] <nlsthzn> hi inetpro, why the eish?
[18:30] <inetpro> nlsthzn: sad that they have to resort to fighter jets in egypt now
[18:30] <nlsthzn> yup...
[18:32] <inetpro> Maaz: Symmetria ++ [ for looking after mirror.ac.za ]
[18:33] <inetpro> Symmetria: thanks for all your efforts if that
[18:33] <inetpro> s/if/with/
[18:37] <drubin> Symmetria: Now you need to explain to WebAfrica they need to keep theirs running :)
[18:41] <Symmetria> drubin I told webafrica not to run the damn thing in the first place
[18:41] <Symmetria> since its kinda pointless
[18:42] <drubin> Symmetria: just convince them to add mirror.ac.za to their freezone
[18:42] <Symmetria> they have a GigE connection to us, which is barely used above 40megabit, they dont have the proper hardware or the disk space to run a real mirror, nor do they have the resources to keep it properly synched
[18:42] <Symmetria> drubin thats what I told em all along
[18:42] <drubin> Symmetria: Please try again :)
[18:42] <Symmetria> heh inetpro did ya see my pretty disk upgrade in mirror.ac.za?
[18:43] <inetpro> Symmetria: I noticed you talking about it, how much you having now?
[18:43] <Symmetria> ./dev/sdb3             1.3T  227G  974G  19% /diskspace
[18:43] <Symmetria> ./dev/sda              6.8T  4.5T  2.2T  68% /diskspace2
[18:43] <Symmetria> ./dev/sdc               13T   13T  243G  99% /diskspace3
[18:43] <Symmetria> ./dev/sdd               26T  282G   26T   2% /diskspace4
[18:44] <inetpro> yikes
[18:44] <Symmetria> heh, diskspace4 is the new one
[18:44] <Symmetria> we did that in preperation for sourceforge which we're now just waiting for sourceforge on
[18:44] <inetpro> Symmetria: very nice
[18:44] <nlsthzn> Thats a lot of bytes oO
[18:44] <Symmetria> apparently they woulda already given us the info to get it started if they hadnt had the security shit htey had in the last few days
[18:45] <inetpro> Symmetria: you're running out of space on disk 3 :-)
[18:45] <Symmetria> inetpro yeah its busy transferring 7 terabytes onto /diskspace4
[18:45] <Symmetria> but that takes forever :)
[18:46] <Symmetria> heh, inetpro we also did something about the synch speeds as well to sort out sync isues
[18:46] <Symmetria> will show u something in a second
[18:46] <bmg505> worst is old Bob is getting ideas :(
[18:46]  * inetpro wonders what is the fastest way of transferring between partitions
[18:47] <inetpro> s/fastest way/fastest method/
[18:48] <bmg505> mount both with tar maybe? tar -cf - * |(cd /target; tar -cpf - --same-owner)
[18:49] <bmg505> or old dd
[18:49] <Symmetria> root@jhb:/diskspace4# wget -4 -O /dev/null ftp://ftp.belnet.be/debian-cd/5.0.8/amd64/iso-cd/debian-508-amd64-CD-23.iso
[18:49] <Symmetria> --2011-01-30 20:47:26--  ftp://ftp.belnet.be/debian-cd/5.0.8/amd64/iso-cd/debian-508-amd64-CD-23.iso
[18:49] <Symmetria>            => `/dev/null'
[18:49] <Symmetria> Length: 657008640 (627M) (unauthoritative)
[18:49] <Symmetria> 100%[[18:49] <Symmetria> 2011-01-30 20:48:06 (16.8 MB/s) - `/dev/null' saved [657008640]
[18:49] <Symmetria> heh
[18:49] <Symmetria> thats an international transfer
[18:49] <Symmetria> and actually, was running a LOT faster earlier, I think belnet must be synching right now
[18:50] <Symmetria> we optimized to the point where using multiple parallel sessions we can sync 4.5gigs of data from london in 56 seconds
[18:50] <bmg505> and here we are measuring ourselfs at bits/day :)
[18:50] <inetpro> Symmetria: looks slow to me based on previous figures from you
[18:50] <inetpro> :-
[18:50] <inetpro> )
[18:50] <Symmetria> inetpro yeah, earlier in the day I was doing 85MBytes/second
[18:50] <Symmetria> ooops
[18:50] <Symmetria> 85Mbit/second
[18:50] <Symmetria> :P which I think was pretty much capping out belnet's lan card
[18:52] <inetpro> Symmetria: I'm sure you must be getting grey by now with all your available bandwidth while seeing everyone else being the bottleneck
[18:52]  * Symmetria checks it from london again to make sure nothing broke
[18:52] <Symmetria> heh inetpro its frustrating actually when we sit with this much bandwidth and there are times when you need to transfer stuff to other people in country
[18:52] <Symmetria> or get stuff from them
[18:53] <Symmetria> and you gotta sit and watch it crawl cause of the crap bandwidth at other isps
[18:54] <Symmetria> heh
[18:54] <Symmetria> [  3] 30.0-60.0 sec  2.54 GBytes    728 Mbits/sec
[18:54] <Symmetria> thats london -> south africa
[18:54] <Symmetria> in 30 seconds
[18:54] <nlsthzn> oO
[18:54] <inetpro> Symmetria: sounds like in the old days around 1995 when we were on 64kbps lines while everyone else was on 9600bps
[18:55] <nlsthzn> 33.6kbps modems rocked
[18:55] <Symmetria> wierd thing is, linux actually sometimes performs better with high speed latency stuff if the window size is actually SMALLER
[18:56] <Symmetria> (which I suspect is because of pull back on the odd dropped frame)
[18:57] <inetpro> nlsthzn: heh, I remember synchronising our financial system from data all over the country with a 2400bps modem
[18:58] <Symmetria> heh I remeber doing FSP on 64kbit lines
[18:58] <inetpro> was a lot of fun
[18:58] <Symmetria> :P it used to take an age to download a game that was a 1.4meg disk big
[18:58] <Symmetria> and then some bastard came out with monkey island that was like, super huge
[18:58] <Symmetria> and it took us a week and a half to download it
[19:00] <Symmetria> heh
[19:01] <Symmetria> iperf keeps dying on me
[19:01] <Symmetria> the moment it gets really fast
[19:03] <Symmetria> don't one of you feel like debugging iperf fo rme
[19:03] <Symmetria> since its been so long since I coded anything I dont think I can remeber any of my debugging skills
[19:11] <inetpro> Symmetria: do you get errors?
[19:14] <Symmetria> inetpro heh no
[19:14] <Symmetria> it just locks up
[19:14] <Symmetria> the moment you start using real big window sizes
[19:14] <Symmetria> and the data transfer speeds get high
[19:14] <Symmetria> then you get a coupla lines of b.s output
[19:15] <Symmetria> [  3] 60.0-75.0 sec  1.75 GBytes  1.00 Gbits/sec
[19:15] <Symmetria> [  3] 75.0-90.0 sec  1.41 GBytes    810 Mbits/sec
[19:15] <Symmetria> [  3] 90.0-105.0 sec  0.00 Bytes  0.00 bits/sec
[19:15] <Symmetria> [  3] 105.0-120.0 sec  0.00 Bytes  0.00 bits/sec
[19:15] <Symmetria> [  3] 120.0-135.0 sec  0.00 Bytes  0.00 bits/sec
[19:15] <Symmetria> ^^ and thats a load of crap :)
[19:16] <Symmetria> oh well, will figure it out in the morning
[19:16] <Symmetria> am going to get some sleep :)
[19:18] <bmg505> probably pointer problem, or 64k segment that wraps
[19:23] <inetpro> good night Symmetria
[21:12] <Symmetria> hrm
[21:12] <Symmetria> Im trying to figure out what exactly they are trying to do with bgp now
[21:12] <Symmetria> some how putting pki into the routing tables