[00:21] <axw>  mgz: are you about? CI won't merge my critical fix, looks like because we have turned on Windows unit test gating but still have a bunch of failing Windows unit tests ...
[00:22] <axw> wallyworld: ^^ I'd rather not spend all my time fixing Windows unit tests right at this point in time
[00:23] <wallyworld> axw: agreed, i'm not sure why gating was turned on before tests passed
[00:24] <wallyworld> we may have to skip them depending on how many there are
[02:18] <wallyworld> axw: did i recall perhaps incorrectly that bug 1598049 had been sorted out in some form?
[02:20] <axw> wallyworld: I *think* that's sorted out by perrito666's patch, which I merged into my branch and landed
[02:20] <axw> but I don't have windows handy to verify
[02:20] <wallyworld> axw: yeah, that rings a bell, that's what i thought had happened
[02:20] <wallyworld> i might mark as fix committed
[02:35] <wallyworld> axw: this updates the juju/rfc repo with the changes to remove the custom tls package https://github.com/juju/rfc/pull/1
[02:37] <axw> wallyworld: you just did a straight copy of changes from juju/juju/standards right?
[02:37] <axw> apart from txt file of course
[02:37] <wallyworld> axw: yep, and i could only see that one change
[02:37] <wallyworld> client.go plus deletes
[02:37] <axw> wallyworld: cool. LGTM, thanks
[02:38] <wallyworld> ta
[02:38] <axw> wallyworld: I'd like to move that rfc5424 package to live under juju/syslog at some point
[02:38] <axw> lumping all standards together is a bit odd, since there's many standards for wildly different things
[02:39] <wallyworld> yeah, could do. although i thik the intent was to gather all rfc things there
[02:39] <axw> wallyworld: I know that was the intent, it just seems very strange to me. maybe just me...
[02:40] <wallyworld> can easily be done, let's discuss with tech board or whatever
[02:40] <axw> sure, no rush anyway
[02:55] <wallyworld> axw: and here's the juju/juju change http://reviews.vapour.ws/r/5218/ (not that it can land, sigh)
[02:57] <axw> wallyworld: LGTM
[02:57] <wallyworld> ta
[04:03] <veebers> Hi axw, you have a moment to help me out. I'm attempting to generate some certs that I can use with the log forwarding feature and a rsyslog sink (this is for testing the feature)
[04:04] <veebers> axw I can't seem to generate a cert that juju is happy with, it complains about there not being any IP SANs, I'm sure I'm generating the certs correctly
[04:06] <axw> veebers: what are you using for "syslog-host" config?
[04:07] <veebers> axw syslog-host: <IP_ADDRESS>:10514
[04:07] <veebers> axw I'm using certtool to gen the certs (creating a ca cert and some client/server certs too)
[04:08] <axw> veebers: try using the hostname that you used when generating the cert
[04:08] <axw> rather than IP
[04:15] <veebers> axw: I don't have any dns setup for this as I've just bootstrapped and deployed rsyslog, added certs and config then exposed it for the rsyslog sink. Are you suggesting that I need dns settings for that machine for this to work?
[04:16] <axw> veebers: either you need DNS, or when you generate the cert you need to include an IP SAN
[04:17] <veebers> axw: the IP SAN is that for both the ca cert and the client/server cert or just one of them? I'm pretty sure I'm setting that for the ca cert
[04:18] <axw> veebers: for the server cert at least, not sure how client cert verification works
[04:20] <veebers> axw: hmm so what I'm doing at the moment is creating a ca cert, then I'm creating a cert that I sign with the ca cert and using that on the rsyslog server as well as the juju config. For the server should I create a cert and use that + ca cert and then a different cert for the client?
[04:24] <axw> veebers: for a more realistic setup, yes. I'd stick with the one cert to start with until you get that working, and expand, though.
[04:24] <veebers> Probably worth mentioning; the certs that I'm generating work fine when using just rsyslog (i.e. 2 machines one sending to the other)
[04:25] <axw> veebers: interesting. that would seem to imply they're not doing strict host verification
[04:25] <veebers> axw: ok, right now I'll try adding the ip address to the client cert (as opposed to the ca cert) too and see if I get any joy
[04:26] <veebers> axw: that thought did cross my mind, could be the way I have it configured
[04:26] <veebers> i.e. Using the config from the top answer here: http://serverfault.com/questions/666827/using-rsyslog-with-tls-without-generating-a-self-signed-cert
[04:43] <veebers> axw: huh, I think that's working now. Is there an action I can do that would create a log that would be forwarded?
[04:44] <axw> veebers: anything and everything that goes over the API
[04:45] <axw> veebers: you shouldn't need to do anything really, logs just happen
[04:46] <veebers> axw: I'm wanting something reproduce-able so I can check that it works now as well as incorporate it into the ci test :-)
[04:47] <veebers> I saw a large influx of messages just at the end of the bootstrap but nothing since, want to force some message so I can confirm all is wired up correctly
[04:47] <axw> veebers: fair enough. umm. I'm not sure what's a good candidate for a useful log message. you can just do "juju status", and you should expect to see an apiserver log message
[04:47] <axw> that should have the word "FullStatus" in it
[04:50] <veebers> axw: Hmm, 'juju status' doesn't change anything in either the rsyslog sync or the logs in /var/log/juju/machine-0.log (on the newly bootstrapped machine) although there seems to be an error in the last log: http://pastebin.ubuntu.com/19050127/
[04:51] <axw> veebers: dunno what that's about. I think you won't get the log message unless you're at DEBUG level. I'll see if there are anyt interesting INFO messages
[04:52] <axw> although, I think we default to WARNING?
[04:54] <veebers> I'm not sure about the default logging level, I don't mind changing it for now or during the test assuming that's valid test cover
[04:57] <axw> veebers: I think it's going to be necessary, at least until we change the default to INFO (which I think there was agreement upon in London)
[04:57] <axw> veebers: if you're at INFO level, you should see "API connection from <IP>" whenever a client connects
[04:58] <axw> veebers: so you could just run "juju status" and look for that
[04:58] <veebers> axw: sweet, so changing log level is as easy as: juju set-model-config logging-config="<root>=INFO" -m controller ?
[04:58] <axw> veebers: yup
[04:58] <veebers> sweet cheers
[04:59] <veebers> axw: wow ok, so doing that and then a status floods the log with: http://pastebin.ubuntu.com/19050776/
[04:59] <veebers> over and over again
[05:00] <veebers> I just killed the controller as it was pegging my system (jujud)
[05:03] <axw> veebers: huh :/
[05:03] <axw> wallyworld: ^^ there's probably a log forwarding loop
[05:04] <wallyworld> awesome
[05:05] <wallyworld> hmmm, i think i saw a bug last week with that outout
[05:09] <wallyworld> veebers:  axw: this seems to be the same thing https://bugs.launchpad.net/juju-core/+bug/1599779
[05:09] <mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:New> <https://launchpad.net/bugs/1599779>
[05:09] <wallyworld> not sure that it's log forward related
[05:10] <axw> ah yes, I think this is the same issue that jam mentioned to me during the sprint - because of how we're using "ForModel" internally in state
[05:11] <veebers> wallyworld: that looks like what I saw, but seems it was more than once a second. /var/log/syslog on the controller was flooded
[05:12] <wallyworld> hmmm, maybe the log forward worker is not marking logs as sent, so it just keeps sending the same thing, not sure
[05:13] <veebers> axw, thanks for you help. At any rate I was able to get something working. I'll look at using dns in the certs and how we might do that under a test environment
[05:13] <axw> veebers: no worries
[08:56] <mup> Bug #1600722 opened: MachineSuite.TestHostedModelWorkers is unreliable <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1600722>
[09:02] <voidspace> frobware: babbageclunk: be at standup in 5 minutes or so
[09:09] <frobware> dooferlad: standup today?
[09:12] <axw> wallyworld: first of many: http://reviews.vapour.ws/r/5219/
[09:12] <wallyworld> ok
[09:15] <wallyworld> axw: fyi i've removed the controller model check - just get the controller uuid directly now, still getting tests to pass in my branch
[09:15] <axw> wallyworld: great, thanks
[09:23] <wallyworld> axw: lgtm, hopefully we can land stuff soon
[09:24] <axw> wallyworld: ta. I've got another one coming with changes how we pass timeouts to MAAS and the bootstrap-state jujud code
[09:24] <wallyworld> ok, may be afk for a fried time
[09:24] <wallyworld> brief
[09:24] <wallyworld> lol
[09:24] <urulama> axw, wallyworld: is this a fix for access key issue?
[09:25] <axw> urulama: authorized-keys issue?
[09:25] <urulama> axw, wallyworld: and good evening :)
[09:25] <urulama> axw: yes, sorry
[09:25] <wallyworld> urulama: yeah
[09:25] <wallyworld> but the landing bot is preventing landings as it wants all windows tests to pass
[09:27] <urulama> geat :-/
[09:36] <frobware> voidspace: want to do 1:1?
[09:38] <urulama> mgz: you around? can you revert the changes for windows tests so that beta12 actually becomes useful (like be able to deploy an application)
[09:41] <urulama> wallyworld, axw: do you know what the status of this one is? https://bugs.launchpad.net/juju-core/+bug/1593828
[09:41] <mup> Bug #1593828: cannot assign unit E11000 duplicate key error collection: juju.txns.stash <ci> <conjure> <deploy> <intermittent-failure> <oil> <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1593828>
[09:43] <axw> urulama: no clue, sorry
[09:44] <voidspace> frobware: sorry, my wife got back from dropping off her dad at the airport and I went to talk to her
[09:44] <voidspace> frobware: sure, can do 1:1
[09:46] <frobware> voidspace: in the ho
[09:51] <babbageclunk> urulama: I'm working on it - it's a bug in mgo. There's a PR to fix it, I've had it reviewed and am waiting to get it merged.
[09:52] <babbageclunk> urulama: once it's merged into the v2 branch I can start updating the mgo version in the various dependencies.tsv files.
[09:53] <urulama> babbageclunk: thanks ... any estimation when it might land? it's annoyingly consistent when trying to stress test the controller how many machines and units it can handle :)
[09:53] <urulama> (annoyingly consistent at failing that is)
[09:57] <babbageclunk> urulama: Hopefully merged into mgo today (depending on reviewer time) - then there are 11 packages to get updated, so that might not get into juju/juju (at the end of the dependency chain) until tomorrow sometime.
[09:58] <babbageclunk> urulama: Are you using beta packages or source? It should be in the beta getting cut this week.
[09:58] <urulama> babbageclunk: cool, thanks. also, it looks like tests are failing, which might be an issue to land it as well :) https://github.com/go-mgo/mgo/pull/291
[09:59] <babbageclunk> urulama: Yeah - that's an occasional failure in the mgo test suite. :(
[10:00] <urulama> babbageclunk: using source, will have an eye on when this lands
[10:00] <babbageclunk> urulama: not anything to do with my change but I'm going to try to sort it out, it's bitten me twice now.
[10:01] <babbageclunk> urulama: ok - I'll put an update on the bug now and keep you updated when there's movement
[10:08] <jamespage> frobware, one for your list - https://bugs.launchpad.net/juju-core/+bug/1600546
[10:09] <mup> Bug #1600546: lxd subnet setup by juju will interfere with openstack instance traffic <sts> <juju-core:New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1600546>
[10:11] <frobware> jamespage: ack & thanks
[10:12] <jamespage> well lathiat can take the credit for finding that one :-)
[10:17] <babbageclunk> Ugh, I just realised I'll need to do a topological sort of the transitive closure of packages that depend on mgo.
[10:37] <urulama> babbageclunk: thanks (and auch, on the last one)
[10:37] <babbageclunk> urulama: :)
[11:21] <mgz> urulama: sorry, which tests?
[11:21] <mgz> oh, it's the whole do we want gating or not thing
[11:21] <urulama> yes
[11:21] <mgz> well, there's a reason I pushed back on adding gating here, but... we *were* asked to
[11:21] <urulama> ok
[11:22] <mgz> urulama: there's actually a fun bug that circumvents the gate
[11:22] <urulama> lol
[11:22] <mgz> urulama: but I will disable the windows part if we have general agreement
[11:23] <urulama> i mean, critical bug fixes can't land
[11:23] <urulama> we can wait for Torsten to be up in 2h ...
[11:23] <mgz> urulama: more a question for cherylj/alexisb
[11:23] <mgz> but you+ian will do
[11:23] <mgz> test regressions generally are critical bugs
[11:24] <urulama> agree
[11:24] <mgz> urulama: anyway, I'll fix the bug in the script and remove windows from the list of jobs for now
[11:25] <urulama> mgz: ok, thanks
[11:26] <mgz> urulama: done
[11:26] <urulama> ty ... now i hope Andrew's branches land soon :)
[11:26] <mgz> you can retrigger if it's approved
[11:27] <mgz> I doubt he'd mind
[11:29] <urulama> mgz: done, let's see if tests pass now :)
[11:31] <babbageclunk> jam: gah, so there are a couple of cycles in the dependencies: juju-romulus and charmstore-charmrepo. How do you think I should handle those?
[11:32] <dooferlad> macgreagoir: standup?
[11:32] <urulama> rogpeppe, ashipika: ^ see comment from babbageclunk
[11:32] <mgz> babbageclunk: kill romulus
[11:32] <urulama> LOL
[11:33] <babbageclunk> mgz: very classical
[11:34] <ashipika> mgz:  et tu?
[11:34] <ashipika> urulama, mgz, babbageclunk: the proposed solution was to integrate romulus into juju core.. which is on our todo list..
[11:35] <mgz> kill, integrate, much the same
[11:35] <ashipika> mgz: there's a certain Julius C. that would disagree :D
[11:36] <ashipika> we're one sprint in Rome short of a Remus.. then we'd have a classical duel on our hands :)
[11:43] <urulama> mgz: thanks, https://github.com/juju/juju/pull/5772 landed
[11:44] <mgz> urulama: ace
[11:44] <babbageclunk> ashipika: Ok, that's the long-term solution, but how should I update mgo in the meantime? (Trying to think it through but it's making my head hurt.)
[11:45] <ashipika> babbageclunk: update the juju-core dependency first, merge, update the romulus dependency second (it depends on the core), merge.. i guess
[11:46] <babbageclunk> ashipika: And it doesn't matter that the dependencies will conflict?
[11:47] <babbageclunk> ashipika: does godeps handle that already?
[11:47] <ashipika> babbageclunk: hmmm.. i think it should all work out.. i hope..
[11:47] <babbageclunk> ashipika: I guess I can just try it! Thx
[11:48] <ashipika> babbageclunk: good luck.. ping me if it doesn't work
[11:49] <babbageclunk> ashipika: It should be ok, since the bugfix doesn't change any interfaces.
[11:49] <babbageclunk> ashipika: thanks, will do!
[11:52] <urulama> mgz: hm, so how come that branch from Andrew got merged, but then CI stated it's bad (at juju.fail) and then if you try it, it works? (/me just tries to understand what failed and why :D)
[11:54] <mgz> urulama: hm, I guess I screwed something up
[11:55] <mgz> oh, there's a trailing backslash all the way over there >_<
[11:56] <urulama> babbageclunk: does this mean that you already have your fix landed in mgo?
[11:59] <mgz> welp. fixed, good thing the branch had in fact already passed.
[12:05] <rogpeppe> babbageclunk: what specific problem are you having?
[12:08] <babbageclunk> urulama: No, just getting ready for the next bit.
[12:09] <babbageclunk> rogpeppe: nothing yet - just trying to decide what order to update the dependencies when it's time to.
[12:09] <rogpeppe> babbageclunk: note that the cyclic dependencies from charmstore<->charmrepo are only because charmrepo uses charmstore for its tests
[12:10] <babbageclunk> rogpeppe: ah, ok - that is a lot less worrying.
[12:10] <rogpeppe> babbageclunk: FWIW i think it's a mistake that it should do so and i think i've worked out what the right answer is, but it'll be a while before we get around to fixing that
[12:11] <babbageclunk> rogpeppe: but if the tests pass then it should be ok, anyway.
[12:11] <rogpeppe> babbageclunk: yup
[12:13] <babbageclunk> rogpeppe: Thinking it through a bit more I was worrying too much - it's not like there'll be two versions of the code in memory, it just determines which version godeps checks out. Right?
[12:13] <rogpeppe> babbageclunk: right
[12:14] <rogpeppe> babbageclunk: you'll need to choose one version for all deps
[12:14] <rogpeppe> babbageclunk: i usually use the newest version of all deps if in doubt
[12:14] <babbageclunk> rogpeppe: yeah, that makes sense
[12:14] <rogpeppe> babbageclunk: the -N flag to godeps can be useful too
[12:15] <rogpeppe> babbageclunk: for coming up with a coherent "latest tested" set of deps from several projects' dependencies.tsv files
[12:15] <babbageclunk> rogpeppe: ok, will use that. Thanks!
[13:27] <jam> babbageclunk: I would think that neither romulus or charmrepo expose mgo as part of their interface.
[13:27] <jam> as long as they aren't returning an mgo.Doc or something like that, we should be ok
[13:27] <jam> (mgo.D/B)
[13:28] <jam> babbageclunk: I'm in favor of updating deps, I'd just mention that if we aren't on the latest *today*, there there is probably a reason, and I don't want to dump all of that on you.
[13:28] <jam> babbageclunk: they need your mgo fix more than they need newest of all other deps
[13:42] <junaidali> Hi everyone, what is the equivalent command for $ juju set-constraints tags=controller     in Juju2.0
[13:53] <frobware> junaidali: set-model-constraints (http://pastebin.ubuntu.com/19079305/)
[14:09] <junaidali> thanks frobware
[14:11] <babbageclunk> jam: good point, I'll make sure that I'm only updating deps (other than mgo) when they're on the latest.
[16:09] <mup> Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>
[16:12] <voidspace> babbageclunk: frobware: dooferlad: firefox crash! omw
[16:24] <mup> Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>
[16:26] <voidspace> frobware: are you going to mid-cycle?
[16:26] <frobware> voidspace: nope
[16:27] <mup> Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>
[16:27] <voidspace> frobware: do you know anyone from the UK who is?
[16:27] <frobware> voidspace: and from juju core?
[16:28] <voidspace> frobware: I left my boots behind in the US - so if I can get them shipped to someone in the US going to the mid-cycle and get someone from the UK to bring them back
[16:28] <voidspace> frobware: then it will be cheaper than getting them shipped to the UK
[16:28] <voidspace> frobware: anyone from the UK willing to do me a favour... :-)
[16:28] <voidspace> frobware: but I have no idea who's going
[17:09] <mup> Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>
[17:12] <mup> Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>
[17:30] <mup> Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>
[17:32] <mgz> anyone got something they want to land and doesn't mind being a guinea pig?
[17:37] <voidspace> dooferlad: ping
[18:56] <mbruzek> mgz: or balloons: did you come up with another solution for the bash completion problem?
[18:57] <mbruzek> mgz: or balloons: I had the wrong target on Friday, it is cleaned up to this: https://bugs.launchpad.net/juju-core/+bug/1600257 but balloons mentioned there might be a "better" way to solve that problem.
[18:57] <mup> Bug #1600257: The tab completion on juju yields KeyError: 'services' <bash-completion> <packaging> <juju-core:New> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1600257>
[19:01] <mgz> mbruzek: I do wonder if we want a wrapper script like juju-version rather than a symlink, I'm not sure how nicely the bash completion mechanism plays with that
[19:01] <mgz> does it avoid registering completions twice if the same script is executed twice under different names?
[19:01] <mbruzek>  mgz: OK but I believe the issue was how to not collide with juju1 bash completion
[19:01] <mgz> is there a better way of auto-loading for aliases?
[19:02] <mgz> mbruzek: that is an issue, but we also need to update the juju 1.25 packaging, and own both parts
[19:02] <mbruzek> mgz in my testing the symbolic link worked and I was not getting double completions, but I will admit my testing was incomplete
[19:03] <mgz> mbruzek: so, that's the jist of my code review questions
[19:04] <mbruzek> mgz: OK I will read up on bash completion aliases and see what I can find. If you or balloons have a different solution please let me know to stand down
[21:10] <alexisb> do we have anyone still online on the networking side
[21:10] <alexisb> frobware, voidspace possible??
[21:11] <frobware> alexisb: if we're quick...
[21:12] <alexisb> frobware, was just recreating this bug: https://bugs.launchpad.net/juju-core/+bug/1516150
[21:12] <mup> Bug #1516150: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-reboot> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1516150>
[21:12] <alexisb> and when looking at the code paths for filtering ip address I found this fucntion:
[21:12] <alexisb> filterLXCAddresses
[21:12] <alexisb> in : juju/juju/network/network.go
[21:13] <alexisb> which seems rather useless given /etc/default/lxc-net doesnt exits anymore, right??
[21:13] <alexisb> frobware, this is not urgent I am just curious
[21:13] <alexisb> if I should open a bug
[21:14] <frobware> alexisb: jam recently landed a change for filtering lxd bridge addresses
[21:14] <alexisb> ah, ok I iwll look at those
[21:14] <alexisb> thanks
[21:15] <frobware> alexisb: http://reviews.vapour.ws/r/4478/
[21:16] <frobware> alexisb: if there's nothing else then it's EOD for me. I only popped in to turn off some of my machines...
[21:16] <alexisb> frobware, nope, I will catch you tomorrow, thanks!
[21:16] <alexisb> sorry for the intrusion
[21:16] <frobware> np
[21:24] <mup> Bug #1602010 opened: juju status doens't display proper error when machine fails <juju-core:New> <https://launchpad.net/bugs/1602010>
[21:46] <jcastro> does anyone know how I can set this? https://github.com/juju/juju/search?utf8=%E2%9C%93&q=test-mode%3A+true
[21:47] <jcastro> I need to be able to set that variable in 2.x
[21:47] <jcastro> but since I don't have an environments.yaml to put it in ...
[21:47] <jcastro> test-mode:true is what I am trying to set
[23:22] <mup> Bug #1602032 opened: Add machine and core count to 'models' output <juju-core:New> <https://launchpad.net/bugs/1602032>
[23:45] <mgz> wallyworld: can you explain your change for bug 1599905 to me?
[23:45] <mup> Bug #1599905: rfc5424 standard has a non-free license <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1599905>
[23:49] <axw> wallyworld: http://reviews.vapour.ws/r/5221/
[23:52] <mup> Bug #1602034 opened: 'ERROR connecting with bootstrap config' for status on destroyed model <juju-core:New> <https://launchpad.net/bugs/1602034>


[16:56] <ChinnoDog> o/
[16:57] <teddy-dbear> \o
[18:48] <ChinnoDog> I booted my laptop to 16.04 via USB stick yesterday. I need to upgrade.
[18:51] <ChinnoDog> I don't think I will dist-upgrade though. Instead I will use Chef to configure 16.04 with all my settings.
[21:01] <jthan> ugh. chef.
[22:48] <pleia2> hah


[08:37] <ginggs> launchpad doesn't seem to be picking up new versions from debian, e.g. https://launchpad.net/debian/+source/lazarus hasn't picked up the 1.8.4+dfsg-3 upload from about 17 hours ago
[08:40] <wgrant> ginggs: That should fix itself within a few hours. There were some configuration changes on the internal mirror overnight that caused some trouble.
[08:42] <ginggs> wgrant: thanks!
[13:34] <joelkraehemann> hi all
[13:34] <joelkraehemann> https://code.launchpad.net/~jkraehemann/+recipe/gsequencer-daily
[13:34] <joelkraehemann> ^^ launchpad doesn't use clean bazar tree to do the build
[13:35] <joelkraehemann> this is why it fails
[13:37] <joelkraehemann> ^^ obviously I didn't push, sorry


[06:34] <luis220413> Is anyone from the Ubuntu Security Team here?
[08:48] <luis220413> I must leave now but I will see your replies in the logs.
 "Is anyone from the Ubuntu..." <- on a Saturday?  I would presume "limited availability" is the proper assessment
[13:59] <tomreyn> i don't know anything about luis other than he seems to be a newer dev and communicates differently than most others.
[14:02] <ahasenack> hi #security, could you help me with steve's comment in this nfs-utils SRU about hardening flags? https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1980095/comments/2
[14:02] <ahasenack> back then I asked here if you would prefer that I include that hardning change in an SRU I was already doing
[14:09] <ahasenack> sbeattie: when you have a moment, could you please add a comment to that bug above?


[21:55] <len-1304> zequence, Just reading about reaper (http://reaper.fm/about.php) and came across a new (to me) concept... That of plugin firewalling.
[21:56] <len-1304> It seems VSTs fail/crash pretty often even on windows systems...
[21:57] <len-1304> The idea of the PFW is to isolate the plugin from the the software it is plugged into so that the DAW is not crashed by the plugin.
[22:00] <len-1304> Sounds like a plugin wrapper of some sort. Kind of like running a VST in a jackrack kind of deal except keeping all the audio flow internal to the DAW.
[22:01] <len-1304> I ended up on the reaper page because a user was asking about compiling ninjam.