menn0veebers: i'm able to replicate what you're seeing... still digging00:09
menn0veebers: ah ... now I see why00:11
menn0veebers: users connected to the controller using "juju register" have a macroon, not a password00:12
anastasiamacaxw: wallyworld: this is on 1.25 with old azure... is may have troubles deploying to it and could become critical... is it easily fixed?  https://bugs.launchpad.net/juju-core/+bug/145914800:12
mupBug #1459148: azure: juju can't create compute/network optimized instances <add-machine> <azure-provider> <canonical-is> <constraints> <feature> <juju-core:Triaged> <https://launchpad.net/bugs/1459148>00:12
menn0veebers: the migration infrastructure doesn't support that00:13
anastasiamacaxw: my pR has not landed. will consider a proper fix rather than a badage solution :D00:15
veebersmenn0: hmm, so should I be doing something different or are we attempting to test something that isn't completely there?00:22
menn0veebers: you have uncovered a gaping hole in functionality :-/00:23
veebersah ok, that's a result at least :-)00:23
menn0veebers: the way users are handled has changed a lot and migrations needs to be updated to work with it00:23
menn0veebers: better that we find this out now rather than later :)00:24
veebersheh yeah true that :-)00:24
menn0veebers: that'll be me for the rest of the day then00:24
veebersmenn0: ok, let me know how you get on (or have a build you would like me to test.) I'll clean up this test and get it ready for review00:25
anastasiamacaxw: the problem was me - reverted tests. should be all good now \o/00:35
axwanastasiamac: "The bug is reference in PR title. All you need to do is look it up."  <- I know it's there, and I know I can look it up. The usual pattern is to have it in the description, so I didn't see it to start with. Please do what's standard so it makes a reviewer's life easier.00:57
axwanastasiamac: if you wanted to go the extra mile, it would be even better to use a clickable link. not everyone does that, but it's more helpful than just a bug number01:00
anastasiamacaxw: sure. however, each reviewer works differently. m happy to add bug link in pr - no need to stress on Monday :D01:02
axwanastasiamac: thank you01:02
anastasiamacaxw: a rare pleasure. i'd rather have u smiling :)01:03
anastasiamacor at least content \o/01:03
axwanastasiamac wallyworld: assuming I can get chrome and my webcam to play nice, happy to chat whenever. what was it about? tools/image arch constraints?01:05
blahdeblah_wallyworld: anastasiamac tells me you are awesome for fixing bugs quickly. So thanks. :-)01:05
anastasiamacaxw: wallyworld: yes and m not really stressing about but m happy to chat :)01:05
wallyworldblahdeblah_: i didn't know it was a bug, the need for it came up in another context01:06
anastasiamacwallyworld: u r too humble \o/01:06
anastasiamacwallyworld: u've fixed it and now must accept the title of "awesome" ;)01:06
wallyworldwell if a 50 line bug fix is all it takes...01:07
axwwallyworld: it's a trap, they're trying to get you to stop doing feature work01:07
wallyworldi know right01:08
blahdeblah_features schmeatures01:18
axwmenn0: sorry missed yor message before01:18
menn0axw: no worries01:19
axwmenn0: well we have model status, shouldn't we be setting it when we're doing a migration?01:19
menn0axw: is this in the output of the show-model command?01:19
axwmenn0: yes01:19
menn0axw: yep, we should show something there01:20
menn0axw: there will be a "migration" field under "status" with an info string01:20
menn0axw: but the "current" field should reflect the status too01:20
menn0axw: i'll be changing show-model soon so I'll make that change then as well01:21
axwmenn0: cool, sounds good01:21
menn0axw: thanks, I just wanted to clarify that it you were talking about show-model and not something else01:21
axwwallyworld: FYI I have a fix that works for speeding up add-machine in azure, basically by not synchronising on the provisioning state for VMs01:23
wallyworldgreat ok01:23
axwwallyworld: doing this means we'll regress on a recent change though, you won't be able to see why provisioning fails when it does01:23
anastasiamacaxw: m looking at bug 1567747 as I am in this area right now. do u have more info? what provider? what commands, especially flags and options were run? pastebin is no longer accessbile...01:23
mupBug #1567747: "juju metadata generate-image" does not validate architectures <observability> <simplestreams> <ui> <juju-core:Triaged> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1567747>01:23
axwwallyworld: so I'm looking at whether we can easily get that info into the instance status01:23
wallyworldi think we'd be able to hopefully01:24
axwwallyworld: yeah just not sure about how much work is involved, whether we should defer till next beta01:24
wallyworldIMO having a fast deploy is more important01:24
axwanastasiamac: sorry, I don't know - pretty sure that pastebin came from the user01:24
axwanastasiamac: IIRC you just pass "-a x86_64" ?01:25
axwanastasiamac: which should fail, because x86_64 is not an arch we understand01:25
anastasiamacaxw: k. tyvm01:26
thumperaxw: do you have any examples of charms / deployment args I could use on lxd to test migration of storage constraints?01:35
axwthumper: here's a metadata.yaml that I use: http://paste.ubuntu.com/23077118/. create a charm dir with that, then use "juju deploy <path/to/charm> --storage filesystem=tmpfs,1G"01:37
thumperaxw: awesome, ta01:37
mupBug #1219582 changed: bootstrap lookups tools multiple times <canonistack> <performance> <simplestreams> <juju-core:Invalid> <https://launchpad.net/bugs/1219582>01:50
mupBug #1237378 changed: "juju bootstrap --upload-tools" fails sometimes for ssl-hostname-verification: false <bootstrap> <simplestreams> <upload-tools> <juju-core:Invalid> <https://launchpad.net/bugs/1237378>01:50
mupBug #1219582 opened: bootstrap lookups tools multiple times <canonistack> <performance> <simplestreams> <juju-core:Invalid> <https://launchpad.net/bugs/1219582>01:56
mupBug #1237378 opened: "juju bootstrap --upload-tools" fails sometimes for ssl-hostname-verification: false <bootstrap> <simplestreams> <upload-tools> <juju-core:Invalid> <https://launchpad.net/bugs/1237378>01:56
mupBug # changed: 1219582, 1237378, 1317680, 1345567, 134969101:59
axwwallyworld: it looks like it's going to be a PITA to get the error message, so I'm thinking I'll propose as is and then address after. sound ok?02:04
axwwallyworld: there's another approach we can take to provisioning as well, which will speed everything up further - and then the error messages can be got at02:04
mupBug #1317680 opened: can't juju add machine when multiple images with same arch/release exist <amd64> <apport-bug> <cloud-installer> <kvm> <simplestreams> <streams> <trusty> <juju-core:Fix Released> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1317680>02:05
mupBug #1345567 opened: problems bootstrapping aws due to s3 write errors when uploading tools <ec2-provider> <simplestreams> <upload-tools> <juju-core:Invalid> <https://launchpad.net/bugs/1345567>02:05
mupBug #1349691 opened: support aws govcloud <ec2-provider> <simplestreams> <streams> <juju-core:Fix Released> <https://launchpad.net/bugs/1349691>02:05
mupBug #1317680 changed: can't juju add machine when multiple images with same arch/release exist <amd64> <apport-bug> <cloud-installer> <kvm> <simplestreams> <streams> <trusty> <juju-core:Fix Released> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1317680>02:14
mupBug #1345567 changed: problems bootstrapping aws due to s3 write errors when uploading tools <ec2-provider> <simplestreams> <upload-tools> <juju-core:Invalid> <https://launchpad.net/bugs/1345567>02:14
mupBug #1349691 changed: support aws govcloud <ec2-provider> <simplestreams> <streams> <juju-core:Fix Released> <https://launchpad.net/bugs/1349691>02:14
thumpercar's ready, relocating back home02:14
mupBug #1210482 changed: use simplestreams info for endpoint labels instead of specifying endpoints <simplestreams> <juju-core:Fix Released> <https://launchpad.net/bugs/1210482>02:20
mupBug #1212173 changed: juju bootstrap searches for tools 2 times <bootstrap> <performance> <simplestreams> <juju-core:Triaged> <https://launchpad.net/bugs/1212173>02:20
mupBug #1230367 changed: environs/simplestreams: could do with splitting <simplestreams> <tech-debt> <juju-core:Fix Released> <https://launchpad.net/bugs/1230367>02:20
anastasiamacwallyworld: plz update bug 126217502:22
mupBug #1262175: debate drop --upload-tools flag <jujuqa> <simplestreams> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1262175>02:22
wallyworldwow, that's an old one02:22
wallyworldsadly the bug is still valid02:23
wallyworldupload tools still exists and is used, it's just now implicit02:23
wallyworldso the complaint in the bug report is still there02:24
wallyworldand because people rely on it, and we now need it for snaps, it's probably here to stay02:25
wallyworldwill have to discuss a bit before marking as invalid02:25
anastasiamacwallyworld: m not asking u to mark as invali. m asking u to update the bug with current view (like the work that you have done in the area last couple of weeks)02:28
wallyworldi think we'll just mark it as invalid, i just need to check will william. the work that's been done doesn't change anything that the bug says is "evil", all the functionality is still present in juju; the only thing different is that upload-tools flag is gone02:32
wallyworldi could update the bug title02:32
wallyworlddone, that is now more accurate02:33
veeberswhere can I find docs on the --show-log argument?02:34
wallyworldnot sure that there is any02:36
veebersoh ok, so --show-log puts all the logs to stdout? Nothing goes to stdin?02:37
anastasiamacaxw: wallyworld: in ur recent work with credentials revamp, did u encounter/fixed scenarios with # in pwds?02:45
mupBug #1567607: vsphere bootstrap fails when environments.yaml has a password with the # character <bootstrap> <cdo-qa> <vsphere> <juju-core:Triaged> <https://launchpad.net/bugs/1567607>02:45
axwanastasiamac: no02:45
wallyworldino from me too02:46
wallyworlddidn't realise we had that issue02:46
anastasiamacaxw: wallyworld: k. thnx02:46
wallyworldveebers: --show-log pritns to stdout what would normally not be seen because it goes to a log sink rather than stdou02:46
thumpermenn0: back, and in hangout02:49
menn0thumper: ok, hang on02:49
veeberswallyworld: with --show-log used are errors still spat out to stderr or is everything now out to stdout via the logs (which include normal and error messages etc.)02:49
wallyworlderrors should still go to stderr02:50
veebers(I of course meant stderr not stdin beforehand :-\)02:50
wallyworldthe only change IIANM is that we show additonal output02:50
mupBug #1400971 changed: all agents except machine agent logging "INFO juju.worker.upgrader upgrader.go:121 desired tool version:" every 15 minutes following02:50
mup"juju upgrade-juju" <prodstack> <simplestreams> <upgrade-juju> <upload-tools> <juju-core:Invalid> <juju-core 1.18:Won't Fix> <https://launchpad.net/bugs/1400971>02:50
mupBug #1457068 changed: bootstrap failed, no tools available <simplestreams> <ui> <juju-core:Won't Fix> <https://launchpad.net/bugs/1457068>02:50
veeberswallyworld: cool thanks02:50
veeberswallyworld: seems --show-log outputs the logs to stderr, is this expected behaviour? (i.e. juju --show-log status --help 2>>out.err 1>>out.std && cat out.err)02:57
wallyworldyou don't want to sully stdout with it02:57
veebersack, fair enough02:58
wallyworldpeople might need to parse stdout yaml or whatever02:58
veebersyeah that's a very good ponint02:58
mupBug #1242476 changed: Bootstrap fails with --upload-tools on private openstack cloud <bootstrap> <canonical-is> <canonical-webops> <openstack-provider> <simplestreams> <upload-tools> <juju-core:Fix Released> <https://launchpad.net/bugs/1242476>02:59
mupBug #1242476 opened: Bootstrap fails with --upload-tools on private openstack cloud <bootstrap> <canonical-is> <canonical-webops> <openstack-provider> <simplestreams> <upload-tools> <juju-core:Fix Released> <https://launchpad.net/bugs/1242476>03:08
thumperveebers: logs generally go to stderr, except when you use the command debug-log, when they go to stdout03:09
veebersthumper: ack thanks.03:09
mupBug #1242476 changed: Bootstrap fails with --upload-tools on private openstack cloud <bootstrap> <canonical-is> <canonical-webops> <openstack-provider> <simplestreams> <upload-tools> <juju-core:Fix Released> <https://launchpad.net/bugs/1242476>03:20
wallyworldthumper: i got 2 PRs up, you able to do your OCR duties :-)03:29
thumper$ juju dump-model03:38
thumperERROR facade "ModelManager" not supported for model API connection (not supported)03:38
thumpersomeone broke dump-model03:38
thumperwhy limit it?03:39
axwthumper: can you please review http://reviews.vapour.ws/r/5492/ if you haven't already03:40
axwif you aren't*03:40
wallyworldthumper: thanks for reviews03:40
wallyworldthumper: rog made that change, they need to separate controller vs model facades for jaas03:41
wallyworldit was explained in an email last week03:41
wallyworldor the week before maybe03:41
wallyworldironically, it also broke their gui and metrics03:41
thumperI recall it coming up03:41
thumperbut just frustrated03:41
veebersthumper: if you file a bug for the dump-model issue you just saw can you tag it EDA and link me to the bug please?03:43
veebersthumper: Escaped Defect Analysis. Means we'll (qa) have a meeting discussing bugs/defects/issues that could have or should have been caught by testing03:45
veebersi.e why did this get through the net03:45
mupBug #1219123 changed: Azure provider: Juju unable to locate any image when "image-stream: released" is set (doesn't validate content of image-stream) <azure-provider> <papercut> <juju-core:Invalid> <https://launchpad.net/bugs/1219123>03:50
anastasiamacthumper: m not sure why this failed to land... https://github.com/juju/juju/pull/5289 shall i try again?03:52
thumperanastasiamac: no, it needs a tweak03:55
thumperand I need to ask sinzui what the tweak is03:55
anastasiamacthumper: \o/03:56
anastasiamacthumper: there are also 2 Jesse's MADE PRs.. they seem to want a rebase :)03:56
thumperyes, I know03:56
mupBug #1588897 changed: Unable to kill or destroy the lxd controller <destroy-controller> <lxd-provider> <juju-core:Expired> <https://launchpad.net/bugs/1588897>04:20
mupBug #1591939 changed: juju failed unmarshal the /server/{server_id} api  response body <juju-core:Expired> <https://launchpad.net/bugs/1591939>04:20
mupBug #1593303 changed: Google Compute Engine provider often reports wrong IP address as the public address <juju-core:Expired> <https://launchpad.net/bugs/1593303>04:20
=== gnuoy` is now known as gnuoy
=== frankban|afk is now known as frankban
voidspacehas anyone managed to go back to lxd 2.0.0 on Wily after 2.1 landed in the stable PPA?07:52
babbageclunkIs anyone working on bug 1614559? I've got a fix for it if not, but I haven't proposed it because I still can't bootstrap.08:37
mupBug #1614559: Juju rejects lxd 2.1 <bootstrap> <ci> <jujuqa> <lxd> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1614559>08:37
babbageclunk(So I guess not totally a fix)08:38
babbageclunkI get "ERROR failed to bootstrap model: cannot start bootstrap instance: unable to get LXD image for ubuntu-xenial: The requested image couldn't be found."08:39
babbageclunkWhich is weird because I can lxc launch a xenial instance fine.08:39
babbageclunkdimitern: ^^08:39
dimiternbabbageclunk: I'm looking at the code to see where's that version check08:40
dimiternbabbageclunk: do you know how to get lxd 2.1 ?08:40
babbageclunkdimitern: It was just on this loaner laptop I'm using.08:41
babbageclunkI think you can just update?08:41
dimiternbabbageclunk: is it running yakkety?08:41
dimiternbabbageclunk: nope, on xenial at least I see these options: launch a xenial instance fine.08:42
dimitern<babbageclunk> dimitern: ^^08:42
dimitern[#juju-dev] oops not that08:42
dimiternbabbageclunk: http://paste.ubuntu.com/23077711/08:42
babbageclunkdimitern: no, it's xenial08:42
dimiternbabbageclunk: ok I did `sudo add-apt-repository ppa:ubuntu-lxc/lxd-stable` and now I see lxd 2.1 as available08:44
babbageclunkdimitern: I think this is using the lxd ppa08:44
babbageclunkdimitern: yeah, that would do it.08:44
babbageclunkdimitern: https://github.com/juju/juju/compare/master...babbageclunk:lxd-version?expand=108:45
babbageclunkdimitern: That's where it does the version check, but I don't think my error's around there.08:45
dimiternbabbageclunk: I'll try that, but I don't think this is the real fix08:46
dimiternbabbageclunk: we should be checking the lxd api version to be 1.0, not the lxc cli version08:46
babbageclunkdimitern: Well, it fixes the bad logic in the version checking.08:46
babbageclunkdimitern: oh, sure.08:46
babbageclunkdimitern: really I just hacked something up so I can bootstrap.08:47
babbageclunkdimitern: (but I can't).08:47
dimiternbabbageclunk: sure :)08:53
babbageclunkdimitern, fwereade: could you have a look at this? https://github.com/juju/juju/pull/604208:56
dimiternbabbageclunk: to just fix bootstrapping, why not try to comment the if !isSupportedLxdVersion() check in tools/lxdclient/client.go ?08:56
babbageclunkdimitern: I did better than that - I made the check right for 2.1. (Although checking the API version is better still.) But then something else still fails.08:57
axwdimitern: hey, don't suppose you had any time to look at the neutron APIs?08:57
dimiternaxw: not yet :/ when do we need to know/reply about that?08:58
axwdimitern: (completely unrelated) in general, do you know if cloud-init should be writing /etc/network/interfaces.d/50-cloud-init.cfg with all NICs of a cloud VM? I've created a VM in Azure with 2 NICs, and it's only got a stanza for eth008:58
axwdimitern: ASAP, but if you don't have time I can have a stab08:59
dimiternaxw: we're taking the defaults for any cloud apart from maas - there we disable cloud-init's /e/n/i generation explicitly, so we don't get the fallback 50-cloud-init.cfg to mess up our statically configured /e/n/i09:01
dimiternaxw: If you can, I'd appreciate it! I'll can have a look if something else could be needed for spaces support09:02
axwdimitern: yeah, just wondering if you know what I should expect from cloud-init's default behaviour. can't find any docs on this bit09:02
axwdimitern: ok, I was specifically asking about what's needed for spaces though :)09:02
axwdimitern: I'll have a look tomorrow09:02
dimiternaxw: the default behaviour is to get a fallback dhcp eth0 from cl-in09:02
axwdimitern: only eth0, even if there's multiple NICs?09:03
dimiternaxw: for spaces we need basically 2 things at minimum - listing subnets of a network, and deploying to a subnet09:03
dimiternaxw: yeah - it's "designed" to be the fallback case when we don't known anything else09:04
babbageclunkdimitern, fwereade: also this? http://reviews.vapour.ws/r/5495/09:07
dimiternbabbageclunk: I managed to bootstrap with lxd 2.1 and this quick-n-dirty patch: http://paste.ubuntu.com/23077748/09:07
dimiternbabbageclunk: looking09:08
fwereadebabbageclunk, former LGTM09:08
natefinchjam: good morning09:09
voidspaceanyway to get reviewboard to notice PRs created when it was down?09:10
voidspaceshort of re-creating the PR09:10
jamhi natefinch. brt09:10
jamnatefinch: https://hangouts.google.com/hangouts/_/canonical.com/john-meinel-nat09:10
natefinchjam: cool.  https://hangouts.google.com/hangouts/_/canonical.com/moonstone?authuser=109:10
natefinchI'll go to yours09:10
babbageclunkfwereade: thanks!09:10
dimiternbabbageclunk: LGTM on your ealier PR as well09:11
jamok. I'm in mine. I'll wait a bit longer.09:11
babbageclunkdimitern: Also thanks! Hmm - I wonder what's going on with my lxd then?09:11
dimiternbabbageclunk: what do you get as errors?09:12
voidspacelxd being screwed is a real downer09:13
dimiternbabbageclunk: ok, sorry - my bootstrap appears to be still going and logging errors in c-i-output.log09:13
babbageclunkdimitern: I get "ERROR failed to bootstrap model: cannot start bootstrap instance: unable to get LXD image for ubuntu-xenial: The requested image couldn't be found."09:13
voidspaceand in trying to revert to lxd 2.0 in xenial I've managed to screw lxd totally it seems09:13
babbageclunkvoidspace: oh no09:13
dimiternbabbageclunk: ah, that's different - try lxc image copy ubuntu:16.04 --alias ubuntu-xenial local:09:13
voidspacebabbageclunk: heh, yeah09:14
voidspacebabbageclunk: trying a purge and re-install of 2.1 to at least get back to a "just juju and lxd is screwed" situation09:14
babbageclunkdimitern: ahh, thanks. Why haven't I needed to do that before?09:14
fwereadebabbageclunk, I'm a bit twitchy about AllMachineRemovals being []model => []machine (rather than [][]machine -- I think of them as an array of requests). did my brain completely skate over that in the apiserver review?09:15
dimiternbabbageclunk: not sure - but I've seen this months ago and that's how I fixed it (it was needed for trusty as well)09:15
babbageclunkfwereade: I think it did, yeah. :( I can see why you say that now though.09:17
dimiternbabbageclunk: the errors preventing my lxd bootstrap were due to "no space left on device" for my zfs pool09:17
mupBug #1615552 opened: Juju 2: Cannot add new key to default model config. <juju-core:New> <https://launchpad.net/bugs/1615552>09:17
babbageclunkdimitern: ha, yeah I've seen that before.09:17
babbageclunkdimitern: thanks, seems to be working now.09:17
voidspaceyay, back to "normally screwed" instead of termially screwed09:19
babbageclunkfwereade: By which I mean I don't think you mentioned that (I'll check now). I can change it though.09:21
fwereadebabbageclunk, sorry :(09:21
dimiternkatco: are you working on bug 1614559 ?09:23
mupBug #1614559: Juju rejects lxd 2.1 <bootstrap> <ci> <jujuqa> <lxd> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1614559>09:23
dimiternkatco: the card's assigned to you, but the bug to rick_h_ ..09:23
dimiternkatco: figured out how to fix it, and I'll take it over, if you don't mind09:24
voidspacedimitern: katco talked about it at standup on Friday - not sure if she's started it though09:24
voidspacedimitern: ah, hah09:24
voidspacedimitern: I doubt she'll mind you doing it09:24
dimitern;) ok09:24
voidspacedimitern: you might even finish before I succeed in deploying a bundle to aws!! :-) (slooooow)09:24
dimiternbasically we need to bump the lxd shared library version we're using to stable-2.0 and check the APIVersion field of server status, not its binary version09:25
dimiternvoidspace: ;) let's see09:25
voidspacedimitern: yep09:25
voidspacedimitern: rick_h_ said he wanted an option (like a force option) to attempt to use a more recent version of the api than the one we expect09:26
voidspacedimitern: current api version is 1.0 I believe09:26
dimiternvoidspace: that would've been ok, if we actually checked the api version :)09:26
voidspacedimitern: we need to work with lxd 2.0 still though as well as 2.109:26
mupBug #1615552 changed: Juju 2: Cannot add new key to default model config. <juju-core:New> <https://launchpad.net/bugs/1615552>09:32
mupBug #1615552 opened: Juju 2: Cannot add new key to default model config. <juju-core:New> <https://launchpad.net/bugs/1615552>09:35
babbageclunkdimitern: now when I bootstrap jujud won't start in the container - it says unable to connect to: - any ideas?10:05
dimiternbabbageclunk: here's my fix - I'd appreciate a review and a QA on it - see if it fixes the issue?10:14
dimiternvoidspace: ^^10:14
voidspacedimitern: looking10:15
babbageclunkdimitern: also looking10:15
dimiternthanks guys!10:16
voidspacedimitern: hmmm... I can't checkout your branch10:19
voidspacedimitern: I can checkout your master but not lp-1614559-lxd-api-version10:19
dimiternvoidspace: do you have my remote added?10:19
voidspacedimitern: yep :-)10:19
dimiternvoidspace: try `git remote -v update`10:20
dimiternvoidspace: and then checkout10:20
voidspacedimitern: I think I just need a fetch --all10:20
dimiternvoidspace: ;) np10:21
voidspacedimitern: works for me10:25
frobwaredimitern: I commented on your PR. the changes break packaging.10:25
voidspacedimitern: just trying again as I didn't specify build-agent, however that doesn't matter as it works10:25
frobwaredimitern: I know this as I had to revert my changes that used the shared.Devices form of Init()10:25
dimiternvoidspace: cheers!10:26
dimiternfrobware: can you clarify please?10:26
voidspacesomeone with lxd 2.0 should check it still works with this as well10:26
frobwaredimitern: HO?10:26
dimiternfrobware: ok, joining standup now10:26
frobwaredimitern: http://pastebin.ubuntu.com/23078034/10:30
babbageclunkdimitern: That works for me but then I get the same error - unable to connect to
voidspacefrobware: have you created a bot to add "in-progress" tags to PRs?10:43
frobwarevoidspace: nope10:43
frobwarevoidspace: were you expecting me to?10:44
voidspacefrobware: https://github.com/juju/juju/pull/605510:44
voidspacefrobware: an in progress label appeared within seconds of me creating the PR!10:44
mupBug #1615580 opened: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju-core:New for thumper> <https://launchpad.net/bugs/1615580>10:44
babbageclunkfwereade: so, I'll make AllMachineRemovals return a params.EntitiesResults, which has Results which is []params.Entities?10:49
babbageclunkfwereade: does that mean that WatchMachineRemovals should also return a NotifyWatchResults (instead of a NotifyWatchResult as it does now) for the same reason?10:51
babbageclunkfwereade: Hmm, I guess that doesn't actually need to - it can be one watcher which notifies when any of the things change, right?10:51
dimiternbabbageclunk: are you sure lxd is listening on that address? lxc config show ?10:53
babbageclunkdimitern: That just shows "core.https_address: '[::]'"10:54
babbageclunkdimitern: does that mean it's only listening on ipv6?10:54
dimiternbabbageclunk: and what's your lxd-bridge config? /etc/default/lxd-bridge10:55
dimiternbabbageclunk: no, it should listen on both10:55
menn0frobware: what's with the "in progress" label?10:55
frobwaremenn0: why is everybody asking me this?10:56
frobwaremenn0, voidspace: there's a disconnect here. I don't know anything about this label.10:56
babbageclunkfrobware: Why'd you tag my PR in-progress?10:56
frobwarebabbageclunk: ^^10:56
babbageclunkdimitern: http://paste.ubuntu.com/23078076/10:56
menn0frobware: I just created a new PR and within seconds you apparently added a label to the PR. looks like something automated that's using your credentials or something.10:56
babbageclunkfrobware: :)10:56
babbageclunkfrobware's been haxxored.10:57
menn0frobware: see here: https://github.com/juju/juju/pull/605610:57
frobwaremenn0: ah, crap. I have an idea.10:57
* menn0 hears a distant penny dropping10:58
frobwaremenn0, voidspace, babbageclunk: apologies. I was playing with waffle.io this morning, took the dog for a walk, then forget I had integrated that into my github account. oops.11:00
* babbageclunk can't work out why all these brooms keep bringing more water in!11:00
dimiternbabbageclunk: for good measure, I'd re-run sudo dpkg-reconfigure -p medium lxd11:00
dimiternbabbageclunk: and just take the current settings11:00
menn0frobware: that'll be it then :)11:01
frobwaremenn0: yep, sorry for the noise. :(11:01
dimiternbabbageclunk: that seems to help sometimes with partially screwed up lxd bridge config11:01
menn0frobware: no harm done11:01
frobwaremenn0: I revoked access to juju/juju on my account for waffle.io11:01
babbageclunkdimitern: Aha, that's something - at the end of the reconfigure there's an error restarting lxd11:04
dimiternbabbageclunk: there you go :) what's the error?11:05
babbageclunkdimitern: http://paste.ubuntu.com/23078092/11:06
babbageclunkdimitern: might be time for a reboot11:06
dimiternbabbageclunk: do you have srw-rw----  1 root lxd            0 Aug 22 10:15 unix.socket in /var/lib/lxd ?11:07
babbageclunkdimitern: yup11:08
dimiternbabbageclunk: lxc info ?11:09
fwereadebabbageclunk, hell sorry11:10
babbageclunkdimitern: connection refused - presumably that's because it failed to restart after the reconfigure.11:10
fwereadebabbageclunk, I think both really ought to be multiple, shouldn't they?11:10
dimiternbabbageclunk: anything in /var/log/syslog re lxd-bridge ?11:11
babbageclunkfwereade: I could see it either way in terms of the watcher.11:11
fwereadebabbageclunk, I would follow the common.AgentEntityWatcher model, I think11:13
babbageclunkdimitern: lots of "lxd-bridge.service: Start request repeated too quickly." - scrolling back to see if there's a different error at the start.11:13
fwereadebabbageclunk, at least NotifyWatchResults already exists11:13
babbageclunkfwereade: ok - makes sense. It all ends up the same on the client side, for now.11:14
babbageclunkfwereade: True. :)11:14
fwereadebabbageclunk, cheers11:15
babbageclunkdimitern: Lots of this: http://paste.ubuntu.com/23078109/11:17
dimiternbabbageclunk: I see - network manager gets in the way11:17
dimiternbabbageclunk: or maybe not .. still looking11:18
dimiternbabbageclunk: what's your `sudo iptables-save` content?11:19
dimiternbabbageclunk: it looks like iptables rules lxd-bridge tries to add are duplicated or clash somehow11:20
babbageclunkdimitern: http://paste.ubuntu.com/23078114/11:22
dimiternbabbageclunk: ufw it is then!11:23
babbageclunkdimitern: huh>11:24
* babbageclunk is lost.11:24
dimiternbabbageclunk: ufw is the so-called "uncomplicated firewall"11:24
dimiternbabbageclunk: with seems to be eager to take over most of your iptables with custom rules for chains that are missing (e.g. ufw-before-forward)11:25
babbageclunkdimitern: So it's got some config that's stopping lxd-bridge from listening on port 8443?11:25
dimiternbabbageclunk: try this - set ENABLED=no in /etc/ufw/ufw.conf and then systemctl restart ufw.service11:27
dimiternbabbageclunk: it's trying to firewall off most things, including lxd-bridge11:27
dimiternbabbageclunk: you can either configure ufw to allow specific traffic, or (better IMO) just disable ufw11:28
dimiternbabbageclunk: sorry, so the ufw custom chains are there, but the default policy seems to be DROP, not ACCEPT - hence the issues, disabling ufw should clean up the output of iptables-save and let you lxd-bridge to start ok11:32
babbageclunkdimitern: ok, ufw is now "active (exited)"11:32
dimiternbabbageclunk: good - mine shows the same11:32
babbageclunkdimitern: but restarting lxd-containers still isn't working. Hang on, checking syslog11:32
dimiternbabbageclunk: restart lxd-bridge.service instead11:33
dimiternbabbageclunk: lxd-containers seems to rely on the former11:33
babbageclunkdimitern: ah, ok11:34
babbageclunkdimitern: No, still see lots of "Bad rule (does a matching rule exist in that chain?)." in `systemctl status lxd-bridge.service`11:35
babbageclunkdimitern: to be precise: http://paste.ubuntu.com/23078151/11:36
dimiternbabbageclunk: reviewed your second PR btw11:37
babbageclunkdimitern: Thanks11:37
dimiternbabbageclunk: I'd try reconfiguring lxd again, but picking another subnet, e.g. - it might be getting confused by the IP range you used11:38
babbageclunkdimitern: Is it possible that the rules ufw set up are still lurking in iptables?11:38
babbageclunkdimitern: ok, will try that.11:38
dimiternbabbageclunk: grep sudo iptables-save for ufw11:38
babbageclunkdimitern: yeah, still lots of them11:40
babbageclunkdimitern: reconfiguring didn't help11:40
dimiternbabbageclunk: so it ufw didn't remove its rules :/ I guess a reboot should fix it11:40
babbageclunkdimitern: w00t!11:41
babbageclunkdimitern: see you in a bit. Thanks for all the help!11:41
dimiternnp, hope it helps ;)11:41
* dimitern steps out for ~30m11:44
* babbageclunk goes to grab some lunch and post some shorts.11:45
natefinchfwereade: an idea I had on friday when it seemed likely we were compiling with the wrong version of go in some places in CI: http://reviews.vapour.ws/r/5499/diff/#11:57
fwereadenatefinch, nice! LGTM12:01
natefinchfwereade: :D12:02
* dimitern is back12:06
dimiternmgz: ping12:10
rick_h_dimitern: yea, the bug is meant to be grabbed from me to the dev working on it12:10
rick_h_dimitern: that just indicates I've claimed the bug for my team vs alexis's12:10
dimiternrick_h_: I see - good to know, ok :)12:10
dimiternrick_h_: it was easy to fix, but frobware has some concerns mgz raised earlier re packaging12:11
rick_h_dimitern: yea, you'll see a bunch of bugs assigned to me, and they line up with the cards in the todo lane12:11
rick_h_dimitern: how so? is this in the backlog?12:11
mupBug #1615601 opened: 2.0 beta 14 + openstack: generated hostnames exceed 255 byte limit <juju-core:New> <https://launchpad.net/bugs/1615601>12:11
dimiternrick_h_: no, from a chat they had in london, as frobware changed something similar to my fix12:12
rick_h_dimitern: oh interesting. Ok, let me know if we want to talk it through or something then12:12
frobwarerick_h_, dimitern: I don't believe we should land the change until we have chatted with mgz12:13
dimiternrick_h_: let's raise it up at standup I guess12:13
rick_h_frobware: rgr12:13
rick_h_mgz: ping around?12:13
rick_h_frobware: dimitern you two have time to chat on networking/Y?12:22
frobwarerick_h_: yep, would appreciate doing so now so I can go grab some lunch....12:22
rick_h_frobware: k, meet you in the standup room12:22
dimiternrick_h_: omw as well12:22
mupBug #1615552 changed: Juju 2: Cannot add new key to default model config. <juju-core:Invalid> <https://launchpad.net/bugs/1615552>13:02
frobwarerick_h_, dimitern: for reference https://bugs.launchpad.net/juju-core/+bug/1597342 regarding LXD deps bump13:37
mupBug #1597342: Juju 2 is using a LXD API that is not in the released version of LXD 2.0 <juju-core:Fix Released by frobware> <https://launchpad.net/bugs/1597342>13:37
frobwarerick_h_, dimitern: and the PR - https://github.com/juju/juju/pull/576913:38
dimiternfrobware: looking13:38
babbageclunkNo alexisb today?13:53
babbageclunkI thought she was back from "horsing around".13:54
anastasiamacbabbageclunk: it may be still a bit early for her :)13:55
babbageclunkanastasiamac: That's probably why she normally leaves her camera off.13:56
anastasiamacbabbageclunk: maybe :D13:56
voidspacefwereade: ping13:57
voidspacefwereade: will you have some bandwidth tomorrow to talk about bug 153410313:57
mupBug #1534103: "unknown operation kind run-action" (1.26alpha3) <2.0-count> <actions> <sts> <juju-core:Triaged by rharding> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1534103>13:57
voidspacefwereade: IRC will be fine if you're still badwidth-ly challenged13:57
anastasiamacfwereade: did wallyworld ping u for bug 1262175? do we have any further comments?13:58
mupBug #1262175: debate drop tools upload capability <jujuqa> <simplestreams> <upload-tools> <juju-core:Triaged> <https://launchpad.net/bugs/1262175>13:58
rick_h_dimitern: fwereade macgreagoir ping for standup14:01
voidspacemacgreagoir: you have a review by the way14:01
natefinchsinzui: where did we land with the 1.25 landing bot using go 1.6?  THe makefile seems to install the "golang" package, but I have no idea what that installs on various systems.  I wish we could be more explicit in our dependency on a specific version of Go.14:06
natefinchcc mgz ^^14:07
sinzuinatefinch: I repeat the bot ues GO 1.6 and has since April 1014:08
sinzuinatefinch: If juju's makefile is correct, it will also use go 1.614:08
natefinchsinzui: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8853/artifact/artifacts/trusty-out.log    output from go version: go version go1.2.1 linux/amd6414:10
sinzuinatefinch: Unit tests are runing according to how the branch states they run. The essential comands are: make install-dependencies; make build; make check14:10
sinzuinatefinch: again, the 1.25 branch's makefile needs updating to match the engineering intent.14:12
sinzuinatefinch: update you branch, and then your work and everyone elses will test with the right version of go14:12
fwereadevoidspace, sorry! I would be happy to talk about it now in fact14:14
voidspacefwereade: I'm nearly EOD and going to the gym14:15
fwereadevoidspace, ack, np, tomorrow is fine then :)14:15
voidspacefwereade: if you're around later I'll be back online14:15
fwereadevoidspace, might be, but with family, so relatively unlikely14:15
voidspacefwereade: ok, cool14:15
fwereadeanastasiamac, I don't think so14:15
natefinchsinzui: are people going to have a heart attack if I just explicitly curl the right version of go from golang.org?  Because that's really the only way we can ensure things don't change out from underneath us.14:15
sinzuinatefinch: you cannot curl because that wont work on canonical machines14:16
fwereadeanastasiamac, I am generally in favour -- but it all depends on the experience of self-publishing them, right?14:16
sinzuinatefinch: go1.6 a deb packge ready to be installed14:16
sinzuinatefinch: follow the example of the master Marefile14:17
natefinchsinzui: ahh, yeah, ok.14:17
sinzuinatefinch: master is doing this: https://pastebin.canonical.com/163656/14:18
voidspacekatco: http://reviews.vapour.ws/r/5497/14:18
voidspacekatco: it's little :-)14:19
katcovoidspace: yeah already looking at it :)14:19
katcovoidspace: you mentioned that there are existing tests, but how do we qa that the bug is actually fixed?14:19
sinzuinatefinch: though I think the gccgo clause cannot ever be reeasched14:19
natefinchsinzui: I sure hope not, because it won't work14:19
voidspacekatco: that's a question we haven't been able to answer for any of the places we've fixed this bug14:19
katcovoidspace: ah bc it's based on load?14:20
voidspacekatco: we can't deterministically trigger the mongo behaviour14:20
voidspacekatco: yep14:20
katcofair enough14:20
voidspacemongo turns a bson.D into a bson.M (I think that's the right way round) and our assert becomes order dependent14:21
katcoyeah that whole thing =|14:22
katcovoidspace: ok, lgtm. ship it14:22
katcovoidspace: sorry i didn't find this fri.14:22
natefinchsinzui: should I add bzip2 to the deps?  master has that for some reason14:22
sinzuinatefinch: that wont hurt14:22
voidspacekatco: thanks14:23
sinzuinatefinch: in vaguely recall there is a  missing package for race testing in master's makefile. I am not sure how to handle that case if the package is not the same in all series14:24
anastasiamacfwereade: awesome! tyvm :D14:24
natefinchsinzui: should we update our list of supported architectures in 1.25 then also?14:26
natefinchsinzui: like, just the list in the makefile14:26
sinzuinatefinch: absolutely. It's driven by the golang goodness14:26
sinzuinatefinch: we officially don't support s390x with 1.x, but is does build and appear to work14:27
natefinchsinzui: mind if I change the no-gopath check to an error?  Seems like if you're ever running the makefile, you really must have a GOPATH14:33
sinzuinatefinch: +114:34
frobwarevoidspace: when the nodes don't commission using my scripts does it eventually error with "error: maas19-node7 did not reach 'shut off' state after 240s"?14:40
natefinchsinzui: http://reviews.vapour.ws/r/5503/14:41
voidspacefrobware: didn't try with maas 1.9  - don't recall any error like that14:43
voidspacefrobware: I'm just off now, can try later if you like14:43
frobwarevoidspace: don't worry14:44
sinzuinatefinch: LGTM14:46
natefinchsinzui: thanks14:47
dimiternrick_h_, frobware: I've updated http://reviews.vapour.ws/r/5496/ to allow unsupported versions, but log a warning as suggested14:55
mupBug #1615013 opened: Autopilot: Nagios uses the wrong subnet IP to reach one host <landscape> <juju-core:New> <Landscape Server:Invalid> <MAAS:New> <nagios (Juju Charms Collection):New> <https://launchpad.net/bugs/1615013>15:00
* natefinch adds files that aren't even compiled.... CI fails :/15:01
natefinch(not because of my files, just flaky tests on windows)15:02
natefinchrick_h_: oh, btw, talked to john, he ok'd the use of the go-jsschema package I was using, as long as we also remove the use of the gojsonschema package we've been using (which is fine, it's only used in a couple files, and should be less than a dozen lines of code to change, all told).15:07
natefinchsinzui, mgz: how hard is it to set up https://github.com/juju/jsonschema with the landing bot?  All it really needs to do is run go get github.com/juju/jsonschema && go test github.com/juju/jsonschema15:22
mgznatefinch: it's pretty easy15:24
rick_h_natefinch: <315:24
natefinchmgz: when you get some time, please and thank yuo.15:25
mgznatefinch: sure thing15:25
mgznatefinch: branch currently just has a licence?15:26
natefinchmgz: I can't land the PR with the code without a bot to land it :)15:26
=== akhavr1 is now known as akhavr
mgznatefinch: okay :)15:26
dimiternmgz: hey there ;)15:26
dimiternmgz: did you see my ping earlier?15:27
mgzah, I see, it already has bots over hackers in ther perms15:27
mgzdimitern: no, sorry, only just around now15:27
mgzdimitern: how can I help15:27
mgzhm, interesting dep version issue of some kind?15:27
mgzlets have a look at the lxd code15:28
mgzdimitern: what did you need the bump for?15:29
sra__can anyone provide me the better requirements for deploying openStack on a single VM using JUJU OpenStack-base bundle15:29
dimiternmgz: well, frobware and you had some chat about packaging issue wrt lxd and juju15:30
dimiternmgz: see http://reviews.vapour.ws/r/5496/15:30
mgzdimitern: our main issue is that because lxd is in the archive, even api compatible code changes to lxd can cause issues, if the 'abi' has changed,15:30
mgzso, for example,15:31
mgzwe update a dep to a new version that has an extra field in a struct - which is normally fine15:32
mgzhowever, when we backport that juju code, it is then building against the older version of the dep without that field, and breaks15:32
mgzso, the fix would be sru the dep at the same time,15:32
dimiternok, but that seems unsolvable15:33
dimiterncatch 2215:33
mgzbut, if *anything else at all* uses that dep, we risk then breaking the other way, as those projects could expect something different at compile time15:33
dimiternjuju-core does not depend on lxd AFAICS (packaging-wise)15:33
mgzwe build against it15:33
* dimitern is still confused what's the right call here15:34
mgzanyway, the specifics matter here, we may be okay15:34
mgzdimitern: I don't see how we do this other than by taking the change, and as needed, dropping our build dep on the archive15:36
mgzit's what we had to do before15:36
mgzit means we build with a smaller and smaller set of packaged deps as things update15:37
mgzbut snaps sort of avoid all this anyway15:37
mgzand that's where we're going15:38
mgzdimitern: I'll comment on the mp15:38
dimiternmgz: cheers!15:39
mgzdimitern: from the diff, it's not totally clear to me, did you need the lxdDevices arg? or did you update just because?15:40
dimiternmgz: it was needed after bumping lxc/lxd's revision, Init() now takes devices15:41
mgzdimitern: when I last looked that change wasn't on stable-2.0 branch15:43
dimiternmgz: it still isn't15:44
frobwaredimitern: and did we need to bump as far as we did for this change?15:44
mgzis the change you actually need on that branch?15:44
dimiternfrobware: this is the commit that is needed: https://github.com/lxc/lxd/commit/0d172e3080f768fd419f0c97f5246983797db24315:45
frobwaredimitern: oh, 10 days ago... :(15:46
mgzso, we flat out depend on lxd 2.1 then...15:46
dimiternyeah, so if it's so recent I thought bumping to tip of lxc/lxd master shouldn't be a big deal15:47
dimiternmgz: if we need to cut it exactly, 2.0.4 will work15:48
dimiternmgz: https://github.com/lxc/lxd/commit/1a6adb0332e8f1da761cf899a92f9b8d8af5326815:48
frobwaremgz, dimitern: wouldn't 2.0.4 be better here15:49
mgzyeah, I think while we can15:49
mgzwe should stick on that branch15:50
frobware2.1 would invalidate all the testing we've done15:50
babbageclunkfwereade: Take another look at http://reviews.vapour.ws/r/5495/? The types should be more to your liking now.15:50
fwereadebabbageclunk, ta15:51
mgzthis isn't a panacea for the basic problem of 'abi' compat, but does keep what we test and expect to work more consitent at least15:51
dimiternmgz, frobware: updated the PR to use 2.0.4's rev# and just pushed the change15:53
mgzdimitern: thanks! does that build? reviewboard only shows me the depedencies.tsv change for the interdiff15:55
frobwaredimitern: how did Init(...with... devices) end up in 2.0.4?15:55
frobwaredimitern: isn't that a breaking API change on 2.0?15:56
dimiternmgz: it builds and works - redid my live bootstrap15:56
dimiternfrobware: I don't know, but it's there15:56
dimiternfrobware: it's a breaking ABI change more than an API change :)15:56
dimiternwell, both I guess15:57
dimiternone of those oops moments - sh*t we forgot to report the API version!15:57
mgzyeah, the terms don't quite map to go15:57
katcomorning redir16:04
mupBug #1615719 opened: [juju-2.0-beta15] during the bootstrap stage the no-proxy config is ignored <openstack-provider> <juju-core:New> <https://launchpad.net/bugs/1615719>16:12
fwereadebabbageclunk, reviewed16:16
* fwereade out for a while, back for thumper meeting this evening16:16
babbageclunkfwereade: thanks!16:16
dimiternrick_h_, frobware, mgz: I'll leave http://reviews.vapour.ws/r/5496/ and we should decide tomorrow for sure whether to land it or not16:23
frobwaredimitern: ack16:23
=== frankban is now known as frankban|afk
=== akhavr1 is now known as akhavr
redirbrb system wants reboot18:23
=== akhavr1 is now known as akhavr
* rick_h_ goes to get the boy from school, biab19:31
menn0veebers: I have the changes ready for review which add macaroon support for migrations. once that lands you should be able to proceed with the authentication tests21:38
menn0thumper: http://reviews.vapour.ws/r/5498/21:38
thumperin bootstrap21:39
menn0thumper: after a helpful chat with rogpeppe last night, i'm going to improve the way macaroons are used with migrations but this PR is good enough for now and lets veebers press on with CI tests21:39
thumpermenn0: on the release call just now21:40
veebersmenn0: cool, cheers :-)21:40
rogpeppethumper: did you see this bug BTW? https://bugs.launchpad.net/juju-core/+bug/161558021:40
mupBug #1615580: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju-core:New for thumper> <https://launchpad.net/bugs/1615580>21:40
menn0thumper: yep, dev is my lxd cloud with all the right options set21:40
rogpeppethumper: (hi, BTW!)21:40
thumpero/ rogpeppe21:41
thumperrogpeppe: I'll make term = dumb work21:41
rogpeppethumper: thanks21:41
* menn0 needs to update the wiki with the latest config advice21:41
rogpeppethumper: really i think it should be anything except term=ansi, but i guess not many people use non-ansi ttys any more :)21:41
rogpeppethumper: strictly speaking you should be parsing termcap/terminfo21:42
thumper$ env | grep TERM21:42
thumperrogpeppe: it makes a syscall to determin whether a terminal or not21:42
thumperand it is someone else's package21:43
rogpeppethumper: yeah, but that says nothing about what escape codes it supports21:43
thumperbut where we are using it, we can check for particulars21:43
rogpeppethumper: tbh i'm not sure it's great to be adding this stuff as a dep to juju21:43
rogpeppethumper: couldn't we just colourize post-hoc if desired?21:44
thumpersome people desire color21:44
thumperI can understand that some don't like it, but they are definitely a minority21:44
rogpeppethumper: i just see all the trivial deps we're adding to anything that imports juju/cmd21:45
thumperit has been specifically asked for by sabdfl21:45
rogpeppethumper: fair enough. doesn't necessarily mean it needs to built in at quite such a low level though, i think.21:46
mupBug #1597601 opened: ERROR cannot deploy bundle: cannot deploy application: i/o timeout <2.0> <bundles> <deploy> <oil> <oil-2.0> <repeatability> <retry> <juju-core:New for thumper> <https://launchpad.net/bugs/1597601>21:55
* rick_h_ runs for the day22:02
redirHave a good evening rick_h_22:06
mupBug #1615839 opened: Manual-provider claims s390x is not supported <ci> <manual-provider> <regression> <s390x> <juju-core:Triaged> <https://launchpad.net/bugs/1615839>22:25
mupBug # changed: 918386, 1227942, 1358219, 1453096, 1470820, 1473197, 1473466, 1476060, 1477357, 1479194, 1483672, 1486965, 1488139, 1490480, 1491353, 1492237, 1493458, 1493598, 1493600, 1493601, 1493604, 1493606, 1494661, 1495978, 1496159, 1497351, 1498235, 1499900, 1500298, 1503990, 1510689,22:55
mup1513466, 1516669, 1516676, 1520373, 1524171, 153267022:55
mupBug # changed: 1534923, 1536461, 1536480, 1539216, 1547665, 1552815, 1557918, 1566545, 1568160, 1569106, 1574076, 1574773, 1575764, 1581878, 1582105, 1590143, 1592887, 1598291, 1598292, 1602508, 1610397, 1613516, 1613823, 161386423:10
axwwallyworld: cam is still playing up, will join soon23:16
wallyworldthumper: alexisb standup?23:17
mupBug # opened: 1534923, 1536461, 1536480, 1539216, 1547665, 1552815, 1557918, 1566545, 1568160, 1569106, 1574076, 1574773, 1575764, 1581878, 1582105, 1590143, 1592887, 1598291, 1598292, 1602508, 1610397, 1613516, 1613823, 161386423:19
perrito666wallyworld: you dropped23:19
mupBug # changed: 802117, 1386425, 1445174, 1454059, 1490789, 1501709, 1510133, 1534923, 1536461, 1536480, 1539190, 1539216, 1547665, 1552815, 1554120, 1557918, 1563705, 1566545, 1568160, 1569106, 1570269, 1570285, 1574076, 1574773, 1575764, 1576700, 1577598, 1581878, 1582105, 1590143, 1590598,23:25
mup1590821, 1590961, 1592887, 1598291, 1598292, 1602508, 1609643, 1610397, 1613516, 1613823, 1613864, 1614072, 161501323:25
alexisbthumper, can you rejoin please23:43
thumperanastasiamac: hello on call reviewer23:43
thumperanastasiamac: http://pastebin.ubuntu.com/23077491/23:43
anastasiamacthumper: want me to review a pastebin? :D23:44
* thumper sighs23:49
thumperanastasiamac: http://reviews.vapour.ws/r/5505/23:49
thumperwrong thing in the buffer23:49
anastasiamacthumper: looking23:49
alexisbwallyworld, free when you are23:51
wallyworldok, joining standup23:51
menn0thumper: http://reviews.vapour.ws/r/5498/ if you have a chance23:55
thumpermenn0: ok23:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!