[00:00] <waigani> menn0: what does your charm do?
[00:00] <menn0> I've found the source for the postgresql charm to be pretty helpful. it's written in Python and uses the charmhelpers package.
[00:01] <menn0> https://github.com/charms/postgresql
[00:01] <menn0> waigani: at thumper's suggestion, I'm productionising the github-watcher charm
[00:03] <menn0> waigani: what are you going to do?
[00:04] <waigani> menn0: good question! At some point I'd like to make a SPARQL endpoint charm
[00:04] <waigani> menn0: but I think I'll start with the Vanilla forum in the tut
[00:04] <menn0> waigani: sounds good
[00:25] <wallyworld_> axw: can you ping me when you're around for a quick catch up about 1.18.3?
[00:38] <menn0> i'm trying to deploy juju-gui using the local provider on my machine and I'm getting this: 2014-05-09 00:36:50 INFO juju.worker runner.go:260 start "api"
[00:38] <menn0> 2014-05-09 00:36:50 INFO juju.state.api apiclient.go:198 dialing "wss://<IP_ADDRESS>:17070/"
[00:38] <menn0> 2014-05-09 00:36:50 INFO juju.state.api apiclient.go:206 error dialing "wss://<IP_ADDRESS>:17070/": websocket.Dial wss://<IP_ADDRESS>:17070/: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "juju-generated CA for environment \"local\"")
[00:38] <menn0> 2014-05-09 00:36:50 ERROR juju.worker runner.go:218 exited "api": timed out connecting to "wss://<IP_ADDRESS>:17070/"
[00:38] <menn0> 2014-05-09 00:36:50 INFO juju.worker runner.go:252 restarting "api" in 3s
[00:38] <menn0> is this a regression? i've deployed juju-gui on my machine successfully before
[00:38] <menn0> i'm using a relatively recent build
[00:39] <menn0> (yesterday)
[00:40] <menn0> and wouldn't you know it... the deploy just worked.
[00:43] <menn0> nevermind I guess
[00:43] <menn0> it just took a really long time and I thought that error was related.
[00:58] <wallyworld_> menn0: local provider takes a long time for the first lxc container to go from pending since it has to download the ubuntu image file
[00:58] <axw> wallyworld_: ping
[00:58] <wallyworld_> axw: hiya, quick hangout?
[00:58] <menn0> wallyworld_: I knew that but it took like 20 mins. perhaps my link is slow today.
[00:58] <axw> wallyworld_: sure
[00:59] <wallyworld_> https://plus.google.com/hangouts/_/7ecpiklmm34hr8t7t02jinl5r0
[01:00] <axw> wallyworld_: same as yesterday... I'll try starting one
[01:01] <axw> wallyworld_: https://plus.google.com/hangouts/_/72cpjktbfqddemso04puald08o
[01:01] <wallyworld_> axw: my network has gone slow, will keep trying to get in
[01:41] <axw> wallyworld_: I don't get any warning about lxc-use-clone
[01:41] <wallyworld_> hmmmm
[01:41] <wallyworld_> it may have been his set up
[01:42] <wallyworld_> maybe he accidentally used an old client to bootstrap
[01:42] <wallyworld_> that would explain it
[01:45] <thumper> wallyworld_: so what is this standup thing?
[01:45] <thumper> that time is not good for me...
[01:45] <wallyworld_> thumper: it's on the calendar
[01:45] <thumper> I know, but it goes into the past
[01:45] <thumper> and looked like a mistake to me
[01:45] <wallyworld_> i assumed someone added it
[01:45] <thumper> it looks like a dupe of the other calender item
[01:46] <wallyworld_> ok
[01:47] <thumper> I'd be happy to do a standup sometime in the next hour
[01:48] <wallyworld_> might get messy two teams doing it though if we want it to be short
[01:55] <thumper> agreed
[01:55] <thumper> mramm: o/
[01:55] <thumper> mramm: are you real or a ghost in the machine?
[01:55] <mramm> hey hey
[01:55] <mramm> mostly real
[02:03] <rick_h_> ghost ramm I like it
[02:15] <stokachu> wallyworld_: yea my latest test didn't report any issues with the lxc-use-clone config item error
[02:15] <stokachu> so it was probably my setup initially
[02:16] <sinzui> wallyworld_, thumper CI is broken. looks like we cannot get errgo from github
[02:16] <sinzui> http://juju-ci.vapour.ws:8080/job/build-revision/1335/console
[02:17] <thumper> oh fuck
[02:17] <thumper> that was me
[02:17] <thumper> bugger
[02:17] <sinzui> oh, and the other branch for 1.18 is broken the same way
[02:17] <sinzui> http://juju-ci.vapour.ws:8080/job/build-revision/1336/console
[02:17] <thumper> shit shit shit
[02:17] <sinzui> thumper, did you break trunk and stable?
[02:17] <thumper> yes
[02:17] <sinzui> That's hard to do.
[02:17] <thumper> not if you delete the repo
[02:18] <sinzui> Oh dear
[02:19] <wallyworld_> sinzui: you see i've asked for input as to what version want for next week
[02:19] <sinzui> thumper, the failure is in " go get -v -d launchpad.net/juju-core/..." I don't think I can hack around that
[02:19]  * thumper hacks...
[02:20] <sinzui> wallyworld_, 1.18.3?
[02:20] <thumper> sinzui: you should be back in business
[02:20] <wallyworld_> sinzui:  i had thought so but then only 1.19.2 will have the new maas name placement directive
[02:20]  * thumper will be more careful before blowing shit away
[02:21] <sinzui> wallyworld_, I wrote release notes for 1.18.3 and 1.19.2
[02:21]  * sinzui retries the trunk build
[02:21] <wallyworld_> sinzui: ok, thank you that's great. so when they tell us what they want, we can just flip the switch on wither one
[02:22] <sinzui> wallyworld_, if we get CI building again. I will manually trigger 1.18 if a new revision doesn't land as I hammer trunk to build
[02:22] <wallyworld_> axw: if we were to go with 1.19.2, we will need a fix for bug 1313785, which i think you are familiar with?
[02:23] <_mup_> Bug #1313785: Can't SSH with "juju ssh" command to EC2 instance. <regression> <ssh> <juju-core:Triaged> <juju (Ubuntu):Triaged> <https://launchpad.net/bugs/1313785>
[02:23] <wallyworld_> sinzui: have you eaten all the Violet Crumble yet?
[02:23] <sinzui> thumper, yes! CI is on to the next phase to unittests and packaging
[02:23] <thumper> phew
[02:24] <sinzui> wallyworld_, Yes. the Cherry Ripes were stolen.
[02:24] <wallyworld_> lol
[02:24] <wallyworld_> i'll bring some more to the next sprint
[02:24] <axw> wallyworld_: ok. goddamn ssh
[02:25] <sinzui> My youngest daughter exclaimed Holy Sh*t when she had one, while the older daughter asked where that the Cherry Ripes been all her lide
[02:25] <sinzui> life
[02:25] <wallyworld_> axw: thanks, seemed like you had a handle on it already
[02:25] <sinzui> I hid one for Saturday
[02:25] <wallyworld_> lol
[02:26] <wallyworld_> sinzui: i can be youe dealer :-)
[02:26] <wallyworld_> your
[02:26] <sinzui> wallyworld_, 6 cherry ripes cost 18.00 USD from amazon. You could make a lot of money send them to the us by boat
[02:27] <wallyworld_> $18 !!!!!!
[02:27] <wallyworld_> wtf
[02:27] <wallyworld_> they cost about $10 here
[02:27] <wallyworld_> and they often go on sale for about $6 which is when i buy them for you :-)
[02:28] <wallyworld_> that's for 6
[02:31]  * axw wishes he had a cherry ripe now
[02:31]  * wallyworld_ does too :-(
[02:58] <wallyworld_> sinzui: bug 1316174. the local provider explicitly disables changing apt sources. do you think we should make juju-core require cloud-tools in the packaging rules then?
[02:58] <_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
[02:59]  * sinzui is thinking
[03:00] <sinzui> wallyworld_, cloud-tools, being an archive, must be added. Isn't think a cloud-inti responsibility? I thought all precise cloud images had cloud-tools as an archive
[03:01] <sinzui> wallyworld_, There is nothing we can package to make an archive be added
[03:01] <wallyworld_> sinzui: but this is for someone's local machine
[03:01] <sinzui> wallyworld_, hmm, oh
[03:01] <wallyworld_> where they just have not added cloud-tools to their own apt sources
[03:02] <wallyworld_> they are using local provider and local provider does not dick with their apt set up on purpose
[03:02] <sinzui> wallyworld_, this is like kiko's production precise running lxc. He didn't have cloud-tools and we require it
[03:03] <sinzui> so Juju on precise needs to require that the archive be added
[03:03] <sinzui> hmm
[03:03] <wallyworld_> maybe we should error early with a nice message then?
[03:03] <sinzui> wallyworld_, I think so
[03:03] <wallyworld_> ok, will do
[03:03] <wallyworld_> i'll comment on the bug
[03:04] <sinzui> wallyworld_, I copied lxc and other packages from ctools to ensure the right mongo and lxc were available in precise for users that upgrade without ctools
[03:04] <wallyworld_> oh, you mean those packages are in precise universe or something?
[03:05] <wallyworld_> or are they in the juju ppa?
[03:13] <axw> wallyworld_: can you please review? https://codereview.appspot.com/92140043
[03:13] <wallyworld_> axw: yeah, already looking :-)
[03:13] <axw> ta
[03:13] <axw> I will get onto backporting the lxc branch
[03:13] <wallyworld_> great thanks :-)
[03:16] <sinzui> wallyworld_, many precise local users were just using our juju ppa. It had older packages than the ones in ctools. I think I am the defactor maintainer of the ppa. I am backporting the same packages in ctools to our ppa to reduce the upgrade problems. The bug we are looking at was introduced when we decided to make juju be explicit about where the mongodb server comes from.
[03:17] <sinzui> wallyworld_, I think checking for and requiring the ctools archive is sane. Many users didn't know they were doing ricky deployments
[03:18] <wallyworld_> sinzui: ok, great thanks. i think that bug can definitely be deferred to next stable release then
[03:23] <wallyworld_> axw: so you're sure you got all the places where EnsureEnvName() is required?
[03:23] <axw> wallyworld_: pretty sure
[03:23] <wallyworld_> ok, i'll see if i can spot any others
[03:31] <jcw4> is there a URL I can view CI builds at?
[03:37] <sinzui> jcw4, At this hour they are at http://juju-ci.vapour.ws:8080/
[03:42] <jcw4> sinzui: thank you
[03:43] <jcw4> sinzui: does the CI url change regularly?
[03:44] <sinzui> jcw4, It has in the past. We deploy it with juju into the clouds that meet our needs. I purchased a domain to stop the nonsense or url changes.
[03:44] <sinzui> We will probably remove the ports from the url next week
[03:45] <jcw4> sinzui: I see
[03:45] <jcw4> sinzui: thanks
[03:46] <sinzui> wallyworld_, thumper I haven't announce the CI URL yet, but you might note I got canonistack running again. I got juju to trans-cloud machines
[03:47] <thumper> heh, nice
[03:47] <wallyworld_> great :-)
[03:47] <sinzui> Next week I will dare to provision my three machines in the lab. That will be a networking challenge
[03:53] <wallyworld_> indeed
[04:12] <waigani> has anyone hit this before: http://paste.ubuntu.com/7419545/
[04:15] <waigani> juju debug-log keeps logging: "machine-0: 2014-05-09 04:14:17 ERROR juju.worker runner.go:218 exited "peergrouper": cannot get replica set status: cannot get replica set status: not running with --replSet"
[04:35] <menn0> waigani: I get that too. From bits I overheard at the sprint it's related to the HA changes but I'm not sure how much of problem it is.
[04:35] <axw> wallyworld_: lxc change is in both 1.18 and trunk now
[04:35] <wallyworld_> whoohoo
[04:35] <menn0> waigani: it would be nice if it would go away!
[04:35] <axw> wallyworld_: I've fixed the SSH thing, just gonna test it on Azure before pushing
[04:35] <wallyworld_> awesome
[04:35] <wallyworld_> i'm just about to propose a fix for another 1.19 bug
[04:36] <waigani> menn0: I destroyed environ, re deploying everything, ensuring each agent is up before deploying the next
[04:36] <waigani> so far so good
[04:36] <wallyworld_> menn0: waigani: that peergrouper error is log noise due to running on local provider with ha enabled - it's on "someone's" todo list to clean up
[04:36] <axw> wallyworld_: I'll fix up the EnsureEnvName stuff in trunk next, unless there's something more pressing
[04:37] <menn0> wallyworld_: cool
[04:37] <wallyworld_> axw: no, that would be next thanks
[04:37] <waigani> wallyworld_: ah, good to know
[04:37] <waigani> menn0: how did you go today? Did you get a working charm?
[04:39] <menn0> waigani: after getting over a few mental hurdles I now have the github-watcher charm ported to Python using charmhelpers. It's cleaner and more robust but still needs more love.
[04:39] <menn0> waigani: it's been fun though!
[04:39] <menn0> waigani: how did you get on?
[04:39] <waigani> yay \o/
[04:40] <waigani> menn0: agent-state-info: 'hook failed: "install"'
[04:40] <waigani> hehe, that is my latest
[04:41] <menn0> waigani: debug logging is your friend :)
[04:41] <waigani> menn0: with less noise, yes
[04:42] <waigani> menn0: when you say charmhelpers, do you mean the tools e.g. charm create?
[04:43] <waigani> or the hook commands e.g. relation-get ...
[04:43] <menn0> waigani: to avoid all the peergrouper noise and just see the logs for the thing you're working on, look at /var/log/juju/unit-<the unit for your charm>.log. that's what i've been looking at.
[04:44] <waigani> menn0: awesome tip, thanks :)
[04:45] <menn0> waigani: I mean the Python package called charmhelpers. https://launchpad.net/charm-helpers
[04:45] <waigani> oh cool, a whole new world - that I'm NOT going to look at right now!
[04:45] <menn0> waigani: it provides a Python API for doing charm related things
[04:46] <wallyworld_> thumper: ping
[04:54] <wallyworld_> menn0: waigani: debug log also supports filtering, include exclude etc
[04:54] <waigani> ah cool, will try
[04:54] <wallyworld_> so you can look at info for a unit or several, and the machine it runs on etc
[04:54] <wallyworld_> see the recent release notes
[04:55] <axw> wallyworld_: the series stuff is just cut and paste right?
[04:55] <wallyworld_> axw: yep
[04:55] <wallyworld_> with a constant removed from testing
[05:27] <wallyworld_> axw: i can't see from the diff where we are testing that a pub address is used if proxy=false, but a private address is used if proxy=true
[05:28] <axw> wallyworld_: there's no explicit test for the latter; will see if I can add one
[05:28] <wallyworld_> that would be great, thanks
[05:28] <axw> wallyworld_: I changed setAddress to add an internal address, which broke the test before my fix
[05:29] <wallyworld_> yeah, i saw that we test the proxy=false case
[05:29] <axw> wallyworld_: problem with proxy=true is it causes a second invocation of juju
[05:29] <axw> wallyworld_: will see how practical it is tho
[05:29] <wallyworld_> ok
[05:39] <thumper> wallyworld_: whazzup?
[05:40] <wallyworld_> thumper: forgot to tell you - on monday we need to enter cards for the next 2 week's worth of work
[05:40] <thumper> ah... ok
[05:40] <thumper> will do
[05:40] <wallyworld_> i would think we'd need lanes for each squad
[05:40]  * thumper thinks
[05:40] <thumper> prolly
[05:40] <wallyworld_> but i ain't got editing permissions
[05:41] <wallyworld_> i'll bug someone later
[05:42] <wallyworld_> aveagoodweekend
[05:43] <thumper> kk
[05:43] <thumper> you too
[05:43] <wallyworld_> will try
[05:43] <thumper> chances are I'll be hacking away
[05:43] <thumper> on my personal project
[05:43] <wallyworld_> yeah, i gots stuff to do as well
[05:44] <wallyworld_> plus mother's day sunday
[05:44] <thumper> oh yeah...
[05:44] <thumper> must not forget...
[05:44] <wallyworld_> must... not....
[05:44] <wallyworld_> me -> buy dinner food
[06:35] <axw> wallyworld_: updated tests
[07:07] <axw> fwereade: I don't understand your comment about .dns vs. .internal
[07:08] <axw> fwereade: it's using .internal because that's what the default is- to proxy and use the internal address
[07:10] <fwereade> axw, right -- I'm just saying that we should probably test both code paths, because they're both viable results in different situations
[07:10] <fwereade> axw, especially when the bug you're working on is about picking one or the other
[07:12] <axw> fwereade: ok. I thought it'd be enough to do it in the common code, but I can do it there too
[07:13] <fwereade> axw, this feels to me like a case where the existing testing wasn't quite covering enough, and so it's worth testing a layer up
[07:13] <fwereade> axw, there's a lot that sucks about testing the same stuff at every layer too
[07:14] <axw> fwereade: indeed it was not covering enough. there was some code that very subtley changed the machine addresses, took me quite a while to figure out why it wasn't working like I thought it should
[07:14] <fwereade> axw, but in the absence of easy mocking we just have to find a balance between testing just-one-path and all-exponential-possibilities, and I think it's reasonable to shade a little closer to the latter when fixing actual bugs
[07:14] <axw> fwereade: nps
[07:15] <fwereade> axw, (not that mocking is a panacea or anything but it certainly helps to control the exponential growth)
[07:20] <vladk> jam, fwereade, axw: hi
[07:21] <axw> vladk: heya
[07:22] <fwereade> vladk, morning
[07:30] <wallyworld_> axw: hi, i just got back from the vet
[07:30] <wallyworld_> looks like you got your +1
[07:31] <axw> wallyworld_: hey. it's cool, fwereade has +1 and I am updating it now
[07:31] <axw> thanks
[07:31] <wallyworld_> great
[07:31] <wallyworld_> our poor dog got desexed today
[07:32] <wallyworld_> fwereade: for the kanban board,are we going to create lanes for each squad to put the 2 week cards?
[07:33] <fwereade> wallyworld_, I'm wondering if maybe we actually want a kanban board per team
[07:33] <fwereade> wallyworld_, harder to see what reviews are in flight, but there's always +activereviews
[07:34] <fwereade> wallyworld_, green have their own already
[07:34] <fwereade> wallyworld_, and honestly it felt a bit clunky with just 2 teams sharing a board before
[07:34] <fwereade> wallyworld_, 4 mightbe a couple of bridges too far
[07:35] <wallyworld_> yeah i agree
[07:38] <wallyworld_> fwereade: actually, i have soccer a bit later tonight so will miss the standup. there's a couple of things i wouldn't mind discussing. did you have time for a hangout anytime over the next hour or so?
[07:44] <fwereade> wallyworld_, I was planning to swap today for my public holiday during the sprint, so let's chat now
[07:44] <fwereade> wallyworld_, well 5 mins please?
[07:44] <wallyworld_> fwereade: it can wait, don't want to take up your day
[07:45] <fwereade> wallyworld_, let's do it anyway, start a hangout and I'll be with you v soon
[07:45] <wallyworld_> ok
[07:51] <jam1> test suite bugfix: for bug #1301353 https://codereview.appspot.com/97240043
[07:51] <_mup_> Bug #1301353: juju test suite should use juju-mongodb <tech-debt> <trusty> <juju-core:In Progress by jameinel> <juju-core 1.18:In Progress by jameinel> <https://launchpad.net/bugs/1301353>
[07:53] <jam1> fwereade: well appropriate Layering is (IMO) better than mocking, you just need a way to have an API Server that doesn't (for example) actually require a mongodb underneath
[07:53] <fwereade> jam1, I use the term mocking pretty loosely -- in my mind, that's just a mocked api server
[07:53] <jam1> that was our goals with interface based Doubles, though we only partially did it for providers
[07:53] <fwereade> jam1, indeed so
[07:53] <jam1> fwereade: sure, I just heavily distinguish Mocks from Doubles
[07:54] <jam1> Doubles can be tested alternative implementations, Mocks are "stub out just this call with this pre-canned response"
[07:54] <jam1> fwereade: anyway, if you're off today, don't bother, but the above code review should be reasonably small
[07:54] <jam1> and would be nice if we are going to have a 1.18.3
[07:55] <fwereade> jam1, yeah, I guess it's just that my experience with doubles lead me to consider them to be less-reliable mocks ;p
[07:55] <jam1> fwereade: if you actually have interface testing and run your test against a double that runs against the actual you can be more confident that you actually still match reality
[07:56] <fwereade> jam1, sure -- I've just found that when things change subtly it's easier to fix mocks than doubles
[07:56] <fwereade> jam1, not trying to say it's fundamentally unworkable or anything
[07:57] <jam1> fwereade: sure, it is easier to change mocks, but it is harder to know *when* it changed and should have broken but didn't. Though again, doubles expect that you actually have good test coverage :)
[07:57] <fwereade> jam1, if you get the double-testing *right* it's easy to tell when they're no longer accurate, but I don't think there's a *fundamental* reason it's easier to test the doubles than the mocks
[07:57] <jam1> its sort of "its possible with a Double, but harder"
[07:57] <fwereade> jam1, yeah
[07:58] <jam1> fwereade: you can write a test suite that runs against the doubles and the real thing
[07:58] <jam1> Mocks tend to not be very testable to compare against something else
[07:59] <fwereade> jam1, well the biggest problem with mocks is the skew, so you have to have *some* way of testing them, but it ends up being more implicit than explicit
[07:59] <fwereade> jam1, and we all know about explicit being betterthan implicit :)
[08:01] <fwereade> jam1, LGTM
[08:03] <jam1> fwereade: if they are properly tested, then IMO their closer to Doubles
[08:04] <jam1> fwereade: I've certainly seen mostly happy-to-skew Mocks
[08:05] <fwereade> jam1, hence my fuzzy handwaving over terminology -- doubles are often overcomplicated, mocks are often undertested, I suppose I'm happiest with something in the middle :)
[08:51] <wallyworld_> jam1: i'm looking to bump bug 1307643 off the 1.18 roadmap and just fix for 1.20. how do you feel about that? i sorta think it's a corner case that we don't really need to deal with on 1.18
[08:51] <_mup_> Bug #1307643: juju upgrade-juju --upload-tools does not honor the arch <upgrade-juju> <juju-core:Triaged> <juju-core 1.18:Triaged> <https://launchpad.net/bugs/1307643>
[08:52] <jam1> wallyworld_: given that I think we are actually unlikely to get 1.20 in trusty, I think I'd rather it stayed in there.
[08:52] <jam1> wallyworld_: but it certainly doesn't block 1.18.3
[08:52] <wallyworld_> hmmm. ok. i sorta though folks would just use the stable ppa moving forward
[08:52] <jam1> (I may be being pessimistic here, but our relationship and track record with Distro isn't very heartwarming)
[08:52] <wallyworld_> thought
[08:53] <jam1> wallyworld_: you don't "Just Get" the stable ppa or cloud-archive:tools on your system
[08:53] <jam1> so 1.18 is going to be the "out-of-the-box" experience people have with Juju
[08:54] <wallyworld_> sure, i guess i figured most folks using juju would be ok with adding an apt source given the nature of what juju does
[08:54] <jam1> wallyworld_: people may be comfortable with it, people just doing "what is this juju thing, and apt-get install juju" won't get what we want them to
[08:55] <jam1> wallyworld_: *hopefully* upload-tools isn't in their default flow, but I fear that it already is
[08:55] <wallyworld_> true, but how many of those would run into that particular bug?
[08:55] <wallyworld_> well, we *really* want to discourage using upload-tools
[08:55] <wallyworld_> i do think people using upload-tools equals the people who would get juju from the ppa
[08:55] <jam1> wallyworld_: until we actually address the use case (just work without scouring the internet)
[08:56] <jam1> we can't really avoid it
[08:56] <jam1> its how people testing it on a private cloud are likely to do it, but I think its fair enough
[08:56] <jam1> it does require mixed archs which is rare enough
[08:57] <wallyworld_> yeah, i figured the natre of the bug meant that people try trying out juju wouldn't come across it
[08:57] <wallyworld_> and those that did would be power users
[08:57] <wallyworld_> who would install from ppa anyway
[09:05] <jam1> wallyworld_: just to close the loop in case it wasn't clear, I'm ok with pulling it out of 1.18
[09:05] <jam1> after discussing it I think its reasonable
[09:06] <wallyworld_> ah ok, thanks. i did think you wanted it left. thanks for clarifying
[09:07] <wallyworld_> jam1: fyi, we'll be cutting either a 1.18 or 1.19 release tomorrow depending on what the maas folks say they want to use at ODS. we've put in fast lxc clonng for them (not just for local but everywhere) and driven down the bugs on both so we can pull the trigger. curtis has release notes prepared for both. i'm just waiting to hear back what they want to run with
[09:09] <jam1> wallyworld_: I thought we had to cut a 1.18 because of the Critical "sync-tools can destroy your environment" bug.
[09:09] <jam1> regardless of what we do for ODS
[09:09] <wallyworld_> jam1: the fix for that is now both in 1.18 and 1.19
[09:09] <jam1> wallyworld_: sure but we need it to go out to everyone else, too
[09:10] <jam1> (we have a critical issue in our current stable release, we should release a new version with a fix)
[09:10] <wallyworld_> jam1: yes, but curtis can only do one release at a time and we need to get ODS sorted out
[09:10] <wallyworld_> and that issue is only a very specific bug right?
[09:11] <jam1> wallyworld_: sure, I'm fine with delaying to do a different release, but we still need 1.18.3 regardles
[09:11] <wallyworld_> yes sure
[09:11] <jam1> wallyworld_: its a "nuke your running environment without running destroy-environment" bug. still pretty serious
[09:11] <wallyworld_> jam1: understood, it's just about what order we release in
[09:11] <wallyworld_> if we do a 1.19 for ODS, then 1.18.3 will have to come straight after
[09:12] <jam1> wallyworld_: I'd also like to stipulate that if we don't hear from them, just do 1.18.3 to get progress on it. (assuming that it takes 1 day to do a release, we can do whatever they like today but 1.18 if they don't say anything)
[09:13] <wallyworld_> yeah, that's what i was thinking, but we really need to know if they want the maas name placement stuff which is missing from 1.18
[09:13] <jam1> wallyworld_: and HA
[09:13] <wallyworld_> well, i guess so. but i didn't *think* that was goingto be the main focus
[09:14] <jam1> wallyworld_: alexis was telling us "we must have HA in by Apr 25 so that jamespage can put the demo together for ODS".
[09:14] <jam1> that may have been tempered
[09:14] <wallyworld_> i asked little mark and dan and alexis 12 hours ago so hopefully they'll get back to me
[09:15] <wallyworld_> if not, they get what they get, right?
[09:16] <jam1> I did think that 1.19 was the plan for ODS
[09:16] <jam1> but only as a 3rd person observer
[09:16] <jam1> I haven't been in any of the actual conversations around it
[09:16] <wallyworld_> then adam indicated they might want 1.18 so we're getting mixed messages
[09:16] <wallyworld_> me either
[09:17] <wallyworld_> hece i asked them explicitly to tell us - we're good to go on both
[09:18]  * jam1 realizes that with his wife away, his ability to separate himself from work-time diminishes greatly
[09:19] <wallyworld_> yep :-)
[09:19] <voidspace> hmmm... I have that issue where I blow away ~/.juju and then generate-config fails because it somehow creates (without sudo) a ~/.juju owned by root
[09:20] <voidspace> this is on a different machine
[09:20] <wallyworld_> axw: we may want to land the 1.18 fix for bug 1316869 straight into 1.19 so we can release if required, and do a followup to clean it up
[09:20] <_mup_> Bug #1316869: juju sync-tools destroys the environment when given an invalid source <juju-core:In Progress by axwalk> <juju-core 1.18:Fix Committed by axwalk> <https://launchpad.net/bugs/1316869>
[09:21] <voidspace> rebooting
[09:21] <axw> wallyworld_: 1.19 isn't really affected that badly
[09:21] <axw> wallyworld_: it was already partially fixed
[09:21] <jam1> voidspace: I've seen that, and even when it isn't using local. I was pretty surprised by it
[09:22] <voidspace> jam1: I have no environment and I *was* using openstack
[09:22] <axw> wallyworld_: there's one case where it could occur, which is if someone had an environments.yaml with multiple environments and no specified default (and no current-environment)
[09:22] <jam1> wallyworld_: it should be possible to just merge 1.18 into trunk. I've been keeping it in sync
[09:22] <voidspace> jam1: even happens in a new shell that I've not used sudo in
[09:22] <jam1> voidspace: yeah, I never dug into it, but I have seen it.
[09:22] <jam1> voidspace: I have  the feeling we aren't actually doing sudo
[09:22] <axw> wallyworld_: I'm in the process of fixing up trunk... but if you really want to merge it forwards, that's fine
[09:22] <voidspace> rebooting as that was the only way I fixed it at the sprint
[09:22] <voidspace> odd
[09:22] <jam1> maybe we are trying to chown it and accidently suppling UID =0
[09:23] <voidspace> right, that sounds likely
[09:23] <wallyworld_> axw: i just want to ensure that by your EOD, we have everything in place to pul the tigger on 1.19 if needed
[09:23] <jam1> like we were trying to fix the old bug about creating it as root, and the old fix to chown it back to $REAL_USER is still running
[09:23] <jam1> only REAL_USER isn't set, so we get UID=0
[09:24] <axw> wallyworld_: IMHO it is not critical for 1.19, so it could be cut now
[09:25] <wallyworld_> axw: ok, what i'll do after soccer is just merge 1.18 into trunk so they're consistent
[09:25] <axw> okey dokey
[09:57] <perrito666> morning
[10:21] <voidspace> natefinch: morning
[10:21] <natefinch> voidspace: morning
[10:27] <voidspace> wwitzel3: ping
[10:37]  * perrito666 has restore working except for a quoting nightmare on the bash script
[10:38] <natefinch> perrito666: awesome!
[10:39] <perrito666> I am thinking that it might be healthier to just send the script and run it remotely instead
[10:43] <natefinch> perrito666: what are you doing now?
[10:44] <perrito666> natefinch: well, currently the bash script is just a text template that i generated and being run over ssh
[10:46] <natefinch> perrito666: do you know about backticks for quoted strings?
[10:48] <perrito666> I do, altough the resulting script is very oddly quoted
[10:49] <perrito666> is standup at extremely early times happening today?
[10:49] <perrito666> or we already moved to our own teams one?
[10:50] <natefinch> I was assuming we were doing our own today
[10:55] <wwitzel3> voidspace: pong
[10:55] <voidspace> wwitzel3: hey, hi
[12:28] <perrito666> sinzui:
[12:28] <perrito666> amazon restored
[12:28] <perrito666> PASS
[12:28] <perrito666> :D
[12:28] <sinzui> perrito666, oh, should I re-enable the backup and restore test?
[12:29] <perrito666> sinzui: nop, I will propose the fix now and let you know when its landed :D just wanted to share the joy with someone else than my neighbors who are certainly happy that I scream of joy in the morning before they get up
[12:30] <sinzui> :)
[12:51] <sinzui> wallyworld_, backporting features to stable jepardises the release's inclusion in Ubuntu
[12:51] <wallyworld_> which bug in particular?
[12:52] <sinzui> wallyworld_, I think Ubuntu will reject 1.18.3 for trusty if it contains lxc-use-clone
[12:52] <wallyworld_> oh. but what if the maas h=guys need it for ODS
[12:53] <sinzui> wallyworld_, The maas guys are not Ubuntu
[12:54] <wallyworld_> hmmm. but i think the bug was raised against 1.18 in the first place
[12:54] <sinzui> wallyworld_, Ubuntu is still on 1.18.1. We can choose to ignore the situation and focus on getting 1.20.0 out with a MRE
[12:54] <wallyworld_> not sure now
[12:54] <sinzui> sorry SRU
[12:54] <wallyworld_> i'd love 1.20 to replace 1.18 in the archive
[12:55] <sinzui> wallyworld_, Ubuntu look at the diff. If they see lots of adds to introduce new behaviour, they will reject the micro version
[12:56] <wallyworld_> ok. so how to we handle the friction bewteen that and what customers (who are the ones who give us $$$$) want
[12:56] <sinzui> wallyworld_, I am in favour of helping the maas guys, I just want everyone to know that  Ubuntu has strict notions of what a micro release can contain
[12:57] <wallyworld_> maybe Ubuntu need to be pragmatic?
[12:57] <sinzui> wallyworld_, remember that Ubuntu rejected backup and restore additions to 1.16.
[12:57] <wallyworld_> it's not like it's a lib with<PHONE_NUMBER> users
[12:57] <sinzui> wallyworld_, they are being pragmatic, they do not accept new features because enterprise hates change
[12:58] <wallyworld_> and enterprise also need s features like backup and restore
[12:58] <wallyworld_> or else we wouldn't have had so much pressure to add that by a big enterprise
[12:59] <sinzui> wallyworld_, And enterprised used CTS's and our versions on the juju,
[13:20] <jcastro> wallyworld_, that's why the ubuntu cloud archive exists
[13:20] <wallyworld_> maybe juju belongs in there then?
[13:21] <jcastro> https://launchpad.net/~ubuntu-cloud-archive/+archive/cloud-tools-next
[13:23] <wallyworld_> so it's there already
[13:24] <jcastro> yeah, but it doesn't have the strictness of the proper archive, this lets us eat our cake
[13:24] <wallyworld_> jcastro: in that case, why was sinzui saying we shouldn't backport features to the 1.18 series, if juju is in cloud archive?
[13:24] <sinzui> wallyworld_, cloud-tools is for precise
[13:25] <wallyworld_> doesn't trusty also have cloud-tools?
[13:25] <sinzui> wallyworld_, no
[13:25] <wallyworld_> why?
[13:26] <sinzui> because we agreed last October to be very make juju super reliable with clearly define bugs and features to make Ubuntu like us
[13:27] <wallyworld_> lol
[13:27] <wallyworld_> we need to add new features at a rate greater than ubuntu will let us
[13:27] <sinzui> wallyworld_, If Ubuntu trusts juju, they will mre and sru it into trusty so that all users get it
[13:27] <wallyworld_> i can't see that the need for cloud-tools is gone
[13:27] <jcastro> new features won't go into ubuntu, they will go into the PPA and UCA
[13:28] <wallyworld_> jcastro: sometimes new features are a bug raised against 1.18 eg fast lxc
[13:29] <sinzui> wallyworld_, In Vegas we discussed the issue again. Changing packaging to provide a juju-client that is super stable and featureful juju-agents that are in the clouds may be a viable compromise
[13:29] <wallyworld_> and so we would expect 1.18.x to be put in trusty wouldn't we?
[13:29] <sinzui> wallyworld_, Everything in Lp is called a bug
[13:29] <wallyworld_> that would be good
[13:29] <sinzui> They are just issues.
[13:30] <wallyworld_> sure. but if a customer says 1.18 is unusable because feature x is missing what do we do
[13:30] <sinzui> wallyworld_, If we removed the config and made fast-lxc work, the  diff might look more like fix
[13:30] <jcastro> wallyworld_, it's not like they're being strict for no reason, there's 10 years of regressions and feedback from tons of projects who have tried.
[13:30] <jcastro> wallyworld_, they use the ubuntu cloud archive
[13:30] <wallyworld_> but there's no clod archive for trusty
[13:31] <jcastro> well, it's fresh so we didn't really need it yet
[13:31] <sinzui> wallyworld_, Customers don't care about semantics. Ubuntu cares about the diff. There is no point i arguing with me because I am not an Ubuntu upliader
[13:31] <wallyworld_> sorry, not meaning to argue, just trying to understand
[13:32] <wallyworld_> i just want to make customer happy
[13:32] <jcastro> it's ok
[13:32] <jcastro> the way distros work is weird
[13:33] <jcastro> wallyworld_, ok so the question is basically now "I have fixes that need to go to support MAAS and customers, and we think the diff might be too large to SRU into Ubuntu, is trusty cloud archive coming soon?"
[13:33] <wallyworld_> yeah, that sounds like what would be needed i think
[13:34] <sinzui> wallyworld_, Ubuntu cares about the meaning of major, minor, and micro. Micro doesn't introduce  configurable features. micro fix bugs in the code, not add new ways to use the software. lxc was not broken. It works fine of local-provider and that is what we documented. Adding fast-lxc is a minor change, extending an existing feature to be used elsewehere
[13:35] <wallyworld_> sinzui: we made it configurable (default existing behavior) so as to be stable so that seems ironic :-)
[13:36] <jcastro> you'd be surprised at the amount of things that can sneak into things like that; which is why they're strict by default
[13:37] <wallyworld_> sinzui: so for 1.19.2, there's one remaining critical bug: 1316869. i've just propose a mp which merges 1.18 into trunk which will fix that bug. as soon as that lands, 1.19.2 should be shippable
[13:37] <wallyworld_> https://code.launchpad.net/~wallyworld/juju-core/merge-latest-1.18/+merge/218989
[13:45] <hazmat`> wallyworld_, so prior to that merge lacking 'current' env file, any command that failed would destroy an env? i'm trying to understand where that destroy env logic is lurking.
[13:45] <hazmat`> that bit on sync-tools
[13:46] <sinzui> wallyworld_, okay. I am pulling down 1.18.2 tarball and win installer
[13:46] <wallyworld_> hazmat`: i'm not sure that is was any command. i thought it was just sync-tools
[13:47] <wallyworld_> but i could be wrong
[13:47] <hazmat`> wallyworld_, fair enough.. but i didn't see any destroy logic in sync tools or sync/sync.go .. and the fix doesn't appear to touch that either.
[13:47] <wallyworld_> the fix for 1.18 cleaned up a bit of stuff in that area which we want in trunk also
[13:47] <wallyworld_> let me check
[13:48] <wallyworld_> hazmat`: cmd/juju/synctools.go is changed
[13:48] <wallyworld_> natefinch: can i bother you for a review of the above mp? it's a merge of 1.18 into trunk to pick up a fix for bug 1316869. the changes end up being mechanical - replace EnvCommand.Init() with EnvCommand.EnsureEnvName()
[13:48] <_mup_> Bug #1316869: juju sync-tools destroys the environment when given an invalid source <juju-core:In Progress by axwalk> <juju-core 1.18:Fix Committed by axwalk> <https://launchpad.net/bugs/1316869>
[13:50] <wallyworld_> sinzui: what do you mean by pulling down?
[13:52] <hazmat`> wallyworld_, ic.. environFromName returns a cleanup/destroy env function
[13:52] <wallyworld_> hazmat`: also, i was told trunk (1.19) didn't really suffer the issue like 1.18 did. but 1.18 improved the checking and so we wanted that in trunk as well
[13:52] <sinzui> wallyworld_, CI makes the the tarball and installer and tests it. There is little point of risking me making something different from what CI tested
[13:53] <wallyworld_> sure. i was just confused my 1.18.2. did you mean 1.18.3?
[13:55] <sinzui> I do mean 1.18.3
[13:56] <wallyworld_> sinzui: ok. hopefully someone will +1 that mp and 1.19.2 can be ready for release also
[13:56] <wallyworld_> i still haven't heard back what the maas folks want to use
[13:56] <wallyworld_> 1.18 or 1.19
[13:57] <sinzui> wallyworld_, should I just release both today and tomorrow?
[13:58] <wallyworld_> sinzui: if you could that we be \o/
[13:58] <wallyworld_> would
[13:58] <natefinch> wallyworld_: I can review it in a minute
[13:58] <wallyworld_> then at least we have done our best to help them
[13:58] <wallyworld_> natefinch: thank you
[13:59] <wallyworld_> as soon as i land it i'm off to bed cause it's just turned into saturday here
[14:00] <natefinch> voidspace: standup?
[14:01] <voidspace> natefinch: coming
[14:31] <perrito666> if anyone has a moment https://codereview.appspot.com/94330043 please?
[14:36] <wallyworld_> natefinch: i gotta sleep, but if you did look at the mp (sorry rietveld rejected it) and +1 it, could you please also change to Approved so it lands. thanks
[14:50] <natefinch> wallyworld_: haven't looked yet, looking now.  Will reapprove after
[15:06] <perrito666> sinzui: are there ci tests for this? https://bugs.launchpad.net/juju-core/+bug/1305026
[15:40] <natefinch> man I wish canonical admin would do dates in yyyy/mm/dd ... I see a vacation from 06/10/2014 to 07/10/2014 and I think someone's taking a month off :/
[15:42] <perrito666> natefinch: it would be nice if it would use localized dates, or else that person might inadvertedly ask for a month vacation :p
[15:42] <natefinch> perrito666: that's why I specified yyyy/mm/dd because that's universal.  But yes, localized would also be good.
[15:49] <sinzui> perrito666, no. but since the restore and HA tests use the same test base, I think I can add a test by Monday that will work
[15:49] <perrito666> sinzui: ill test by hand in the mean time, tx
[16:31] <sinzui> natefinch, perrito666 Do either of you have a minute to review https://codereview.appspot.com/92170043
[16:31] <natefinch> sinzui: sure
[16:31] <natefinch> sinzui: looks like dimitern already got it
[16:31] <dimitern> i'm fast ;)
[16:32] <sinzui> very fast. Thank you dimitern
[16:35] <dimitern> sinzui, np
[17:38] <jcastro> ERROR state/api: websocket.Dial wss://<IP_ADDRESS>:17070/: dial tcp <IP_ADDRESS>:17070: connection refused
[17:38] <jcastro> can someone help me get around this error?
[17:38] <jcastro> I've done destroy-environment --force
[17:39] <jcastro> then I don't have any juju processes running
[17:39] <jcastro> then I rebootstrap, and always end up with this
[17:46] <perrito666> do we have any HA docs?
[17:46] <perrito666> jcastro: do you have the output of bootstrap with --debug?
[17:47] <jcastro> http://pastebin.ubuntu.com/7422575/
[17:47] <jcastro> there ya go!
[17:48]  * perrito666 looks
[17:48] <natefinch> jcastro: this is local, right?
[17:48] <jcastro> yep
[17:49] <natefinch> jcastro: do ps -Al | grep lxc   in my experience, sometimes lxc gets stuck and multiple lxc processes end up getting hung up.  Usually requires a reboot to fix
[17:50] <jcastro> no containers running
[17:51] <jcastro> should I reboot?
[17:54] <natefinch> jcastro: did you reboot, or was that just good timing? :)
[17:55] <jcastro> no I rebooted
[17:55] <natefinch> did it work?
[17:55] <jcastro> cleared out jenv file and the local directory in .juju
[17:55] <jcastro> same issue
[17:55] <natefinch> weird
[18:03] <jcastro> natefinch, how about mongodb?
[18:03] <jcastro> is there a daemon I can kill to start it over?
[18:07] <natefinch> jcastro: ps -Al | grep mongod
[18:08] <jcastro> yeah I had already killed that. :-/
[18:08] <natefinch> jcastro: this is my killlocal.sh :
[18:08] <natefinch> #!/bin/bash
[18:08] <natefinch> sudo rm  /etc/init/juju*
[18:08] <natefinch> sudo rm -rf ~/.juju/local
[18:08] <natefinch> rm ~/.juju/environments/local.jenv
[18:08] <natefinch> sudo killall mongod
[18:08] <natefinch> sudo killall jujud
[18:09] <jcastro> http://askubuntu.com/questions/403618/how-do-i-clean-up-a-machine-after-using-the-local-provider
[18:09] <jcastro> I am doing this one now
[18:09] <natefinch> jcastro: ahh, yeah, that cleans up some stuff I missed
[18:10] <natefinch> (mainly lxc stuff, which is honestly most likely the culprit)
[18:11] <jcastro> same issue. :-/
[18:12] <natefinch> what does which mongod tell you?
[18:12] <jcastro> huh
[18:12] <jcastro> mongodb-server not installed?
[18:12] <jcastro> that can't be right
[18:13] <natefinch> no, that's ok.  juju-local puts it in /usr/lib/juju/ .... something something
[18:13] <natefinch> which is not in the path
[18:13] <jcastro> let me add the juju ppa
[18:13] <jcastro> I am on 1.18.1
[18:20] <jcastro> natefinch, ok I have a deadline, so off to AWS I go!
[18:20] <jcastro> thanks anyway
[19:01] <_benoit_> Hi
[19:01] <_benoit_> niemeyer: So I want to add support in juju-core for Outscale SAS
[19:02] <_benoit_> niemeyer: they are a cloud provider implementing most of the EC2 API but not implementing S3
[19:02] <niemeyer> _benoit_: Okay
[19:02] <_benoit_> niemeyer: tim told me I could replace S3 by an  http storage worker
[19:02] <niemeyer> _benoit_: Do they have any notion of storage API?
[19:03] <_benoit_> niemeyer: for now I patched goamz and created a directory for the outscale provider
[19:03] <_benoit_> niemeyer: no
[19:03] <_benoit_> niemeyer: I also created their instance.go file
[19:03] <niemeyer> Sorry..
[19:03] <niemeyer> my xchat is misbehaving.. let me reconnect
[19:04] <_benoit_> niemeyer: but I don't see how I can reuse the EC2 code since most structure name are not capitalized (exported)
[19:04] <niemeyer> Okay
[19:04] <niemeyer> _benoit_: You say you patched goamz.. what for?
[19:05] <_benoit_> niemeyer: to add their regions (I submited the patch)
[19:05] <niemeyer> _benoit_: Ah, okay
[19:05] <_benoit_> niemeyer: I also added panic for nil endpoint in the other New constructor like you suggested
[19:05] <niemeyer> _benoit_: So it's plain EC2 sans S3?
[19:06] <_benoit_> _benoit_: the future release is almost EC2 excepted a few bits (they are adding VPC in this release)
[19:06] <_benoit_> s/_benoit_/niemeyer/
[19:06] <_benoit_> and yes no S3 and no storage
[19:07] <_benoit_> niemeyer: that the compatibility matrix of the current version -> (without VPCs for now) https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix
[19:08] <niemeyer> _benoit_: No S3 and no storage? What's the difference between these?
[19:08] <_benoit_> niemeyer: I mean dont even have an equivalent to S3
[19:08] <niemeyer> _benoit_: Ah, okay
[19:09] <niemeyer> _benoit_: So, did you manage to make it work?
[19:09] <_benoit_> niemeyer: No
[19:09] <_benoit_> niemeyer: I am still stuck trying to find a way to "inherit" EC2 stuff so I don't have to copy paste
[19:10] <_benoit_> I am new to go but have a C/Python background
[19:10] <niemeyer> _benoit_: Why do you need to copy & paste?
[19:10] <natefinch> _benoit_: if they're really so similar, it might make sense to have them in the same package
[19:10] <niemeyer> _benoit_: I mean, more specifically..
[19:10] <niemeyer> _benoit_: Why are you not using the ec2 backend itself?
[19:11] <natefinch> niemeyer: I think he means that the juju provider/ec2 code is almost entirely non-exported, and he wants to reuse a substantial portion of it
[19:11] <niemeyer> natefinch: I get that, thanks
[19:11] <natefinch> ok
[19:11] <_benoit_> niemeyer: If you think patching the ec2 provider is the way I'll do it like that
[19:12] <niemeyer> _benoit_: It's certainly where I would start
[19:12] <_benoit_> niemeyer: do you have any hint to do this ?
[19:12] <_benoit_> niemeyer: Given that the differences are regions, instance types price and no S3
[19:12] <niemeyer> _benoit_: To begin with, I'd try using Amazon's S3 with the EC2 endpoints of Outscale
[19:13] <niemeyer> _benoit_: This can get you to experience something actually working
[19:13] <_benoit_> _benoit_: ok Is there a recipe to bootstrap a juju comptible ubuntu AMI ?
[19:13] <_benoit_> _benoit_: maybe a list of packages to install on a ubuntu AMI ?
[19:13] <niemeyer> _benoit_: juju uses a plain Ubuntu AMI
[19:14] <_benoit_> _benoit_: would debootstrap work for this ?
[19:14] <niemeyer> _benoit_: It's tailored for juju with the proper packages at startup time
[19:14] <niemeyer> _benoit_: By juju itslef
[19:14] <niemeyer> _benoit_: debootstrap?
[19:14] <_benoit_> _benoit_: debootstrap is a way to create a debian or ubuntu system from scratch in a chroot
[19:15] <niemeyer> _benoit_: I know what it is, but why are we talking about it?
[19:15] <_benoit_> _benoit_: Outscale have only debian AMI right now
[19:15] <_benoit_> s/_benoit_/niemeyer/
[19:15] <niemeyer> _benoit_: Oh, that'd be an issue
[19:15] <niemeyer> _benoit_: Does it support custom images?
[19:15] <_benoit_> niemeyer: I was wondering if I could could create the first ubuntu image with debootstrap
[19:16] <niemeyer> _benoit_: I would write them and ask about Ubuntu images
[19:16] <niemeyer> _benoit_: Explaining you want to use juju
[19:16] <_benoit_> niemeyer: I would attach and EBS format it and dump a root filesystem on the EBS
[19:16] <niemeyer> _benoit_: SUre, whatever works.. you'll need to talk to them to sort out how to get an Ubuntu image there
[19:16] <_benoit_> niemeyer: Ok
[19:17] <_benoit_> niemeyer: thanks I think I have the first step to do
[19:17] <niemeyer> _benoit_: Super, glad it was useful
[19:17] <niemeyer> _benoit_: Please let us know how it goes
[19:17] <_benoit_> niemeyer: I'll do this monday and get back to you once it work to have some guidance for the rest
[19:17] <_benoit_> niemeyer: which timezone are you in ?
[19:20] <_benoit_> niemeyer: so I can catch you outside of lunch hours ;)
[19:21] <_benoit_> niemeyer: super thanks
[19:21] <niemeyer> _benoit_: I'm in UTC-3
[19:21] <_benoit_> niemeyer: I am in UTC+1
[19:22] <niemeyer> _benoit_: It's not too hard to find me here, but it's pretty certain you can find help coming here at any time
[19:22] <_benoit_> ok
[19:22] <_benoit_> have a nice week end
[19:37] <Makyo> Can you refer to a machine later on in the list of MachineParams, i.e.: [{create machine 1}, {create lxc on machine 1}] in the same AddMachines API call?
[19:40] <Makyo> (I'm guessing probably not due to needing to know the machine name before adding containers.)
[19:46] <natefinch> Makyo: what are you trying to do?  Just add a machine with a container on it?
[19:47] <Makyo> natefinch, adding AddMachine support in the GUI.  I was just wondering if the API call added machines in the MachineParams array one at a time synchronously.
[19:50] <natefinch> Makyo: I'm pretty sure you can just do "Create machine with lxc" and it'll create a new machine with an lxc container on it
[19:53] <natefinch> Makyo: AddMachineParams has a ContainerType you can set
[19:55] <Makyo> natefinch, I think we have much of that mirrored on our end: https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L921 I was just wondering since AddMachines takes an array of AddMachineParams.  Are those expected to be completed in order?  Create machine, create one container on that machine, create a second...&c
[19:56] <natefinch> Makyo: I wouldn't rely on them being executed synchronously, in order.
[19:57] <Makyo> natefinch, Alright. Will work with that assumption, then.
[19:57] <Makyo> Thanks!
[19:58] <natefinch> Makyo: right now they are, but that's an implementation detail that may change.
[19:59] <natefinch> Makyo: we'd like to batch up the provider requests into a single request, so we just say "make these 50 machines" rather than saying "make this one machine" 50 times.
[20:03] <Makyo> natefinch, alright, thanks.  Will make note of that in our docs.
[20:03] <natefinch> Makyo: welcome


[02:01] <mrooney> Can anyone confirm or deny bug 344626
[02:05] <bcurtiswx-mini> mrooney: can't reproduce
[02:10] <mrooney> bcurtiswx-mini: interesting, must be a quirk
[02:10] <bcurtiswx-mini> mrooney: maybe a keyboard binding problem?
[02:11] <mrooney> bcurtiswx-mini: I don't see how, the actual brightness does the right hting
[02:11] <mrooney> just the notification brightness moves the wrong direction in those cases
[02:12] <mrooney> bcurtiswx-mini: did you more than once? it seems to do the right thing about 20% of the time or so
[02:12] <mrooney> *try more than once
[02:13] <bcurtiswx-mini> mrooney: tried a bunch of times, as many different ways i can think... does it do this for sound too?
[02:13] <mrooney> nope, just brightness
[02:14] <bcurtiswx-mini> plugged in?
[02:15] <bcurtiswx-mini> mrooney: ^^
[02:19] <mrooney> bcurtiswx-mini: yeah I am plugged in
[02:19] <bcurtiswx-mini> mrooney: im on battery power,
[02:19] <mrooney> same thing on battery
[02:19] <mrooney> I'll add that though, good thinking!
[02:22] <bcurtiswx-mini> when i get it to full it flashes the notify white area brighter
[02:22] <bcurtiswx-mini> does it do that for you?
[02:22] <mrooney> yeah
[02:22] <mrooney> that is just to say "hey, it's full!"
[02:23] <bcurtiswx-mini> yeah, i figured... just thinking of why yours does that
[02:24] <bcurtiswx-mini> mrooney: this may be a dumb question.. but you are fully updated.. correct?
[02:24] <mrooney> bcurtiswx-mini: I updated this afternoon, I can try again
[02:24] <bcurtiswx-mini> mrooney: worth a shot
[02:25] <mrooney> there are some updates, nothing notification or power related, seemingly
[02:26] <mrooney> i'll give them a go and restart anyway
[02:26] <bcurtiswx-mini> ok
[02:27] <bcurtiswx-mini> mrooney: https://wiki.ubuntu.com/NotifyOSD#Logging%20notifications
[02:28] <bcurtiswx-mini> mrooney: may want to attach the log to the report
[02:30] <mrooney> I don't have that file, interesting!
[02:30] <bcurtiswx-mini> hmm, i don't either
[02:34] <mrooney> oh wikis
[02:35] <bcurtiswx-mini> well, since there is no debug, i'd say uname -a lsb_release -a apt-cache policy notify-osd
[02:38] <bcurtiswx-mini> mrooney: any luck?
[02:38] <mrooney> I just restarted, same thing
[02:38] <mrooney> and this is a different account so I lost my history, would you mind pasting the bug link and those things again?
[02:38] <bcurtiswx-mini> well, since there is no debug, i'd say uname -a,  lsb_release -a,  apt-cache policy notify-osd
[02:38] <mrooney> yes that is good
[02:38] <bcurtiswx-mini> bug #344626
[02:39] <mrooney> thanks so much
[02:39] <bcurtiswx-mini> idk if a trace/backtrace would help
[02:41] <mrooney> bam, information-ified!
[02:42] <bcurtiswx-mini> ok, i will triage it
[02:42] <mrooney> I don't know what there is to do really, other than add your comment that you can't confirm
[02:43] <mrooney> okay...going home, bbs!
[03:03] <dtchen> greg-g: sadly, your controller is buggy
[03:04] <dtchen> greg-g: there's a workaround; i'll see if i can spin a separate driver for you
[03:09] <mrooney> bcurtiswx: hm, I don't get why triaged makes sense for that report
[03:09] <mrooney> there isn't an upstream report and the cause isn't known
[03:12] <mrooney> oh I see
[03:12] <mrooney> I suppose the Triage explanation does fit it well
[05:19] <ApOgEE--> hi all... anybody here?
[05:19] <paulduf> Bug #217787 is messy, it has a task on hardy Won't fixed AND released, idem for Intrepid, and I THINK that the duplicate is a false one.
[05:20] <paulduf> This also means, yes, there is someone here :-)
[05:21] <paulduf> Did I mention the Samba task, in triaged state that I would consider invalid I guess.
[05:22] <ApOgEE--> paulduf, I got email saying my desktop-bugs membership is about to expire
[05:23] <ApOgEE--> paulduf, how to update?
[05:23] <ApOgEE--> I did sent email to brian murray... haven't got reply yet
[05:23] <paulduf> So I'd rather leave it to an expert triager.
[05:26] <paulduf> Well, I think this rule is not really applied anyway. (not sure) Best way to make it not to expire is normally to give the requested info.
[05:26] <paulduf> Which number is it?
[05:26] <sbeattie> paulduf: I'm failing to see what needs to be triaged with it: the apparmor policy for cups was insufficient, and that got fixed. libpam-smbpass has a bug in that when it can't access the files that apparmor prevented it from accessing, it causes the application its running in to crash, which is still an open bug that needs to be fixed, but won't be fixed in intrepid and hardy.
[05:27] <sbeattie> (in re bug 217787)
[05:27] <paulduf> sbeatie: oh, I see, like 2 bugs in one.
[05:28] <paulduf> That's why it is both released and won't fix (depending on which part)
[05:28] <sbeattie> exactly.
[05:39] <mrooney> can anyone test a quick notify-osd bug, on a laptop?
[05:39] <mrooney> it seems that if you adjust brightness to maximum, and then while the brightness notification is still up, change the volume, it flashes the brightness each time
[05:40] <mrooney> how interesting.
[05:46] <mrooney> I filed it as bug 344664 if anyone can confirm or deny
[06:52] <dholbach> good morning
[06:54] <maco> hi :)
[06:54] <dholbach> hi mac
[06:54] <dholbach> maco
[06:56]  * Hobbsee waves
[07:04]  * maco growls at the network
[07:04] <maco> it seems that seeding a torrent on ipv4 makes my miredo-based ipv6 connection unstable :(
[07:07] <YoBoY> hi
[11:44] <brendon1> what can I do to help?
[11:45] <hggdh> brendon1, please read http://wiki.ubuntu.com/HelpingWithBugs
[11:45] <hggdh> brendon1, then ask out your doubts. We will be happy to help
[11:49] <brendon1> I'm running Hardy, and I only have 1 computer available, does this mean if I want to try to fix bugs I'll be stuck to Hardy bugs only?  or would you recommend I keep multiple partitions to be helpful?
[11:51] <hggdh> brendon1, if you go to reproduce a bug, then you might need the same (or newer) release as the reporter. You might also (if possible) install virtual images
[11:52] <hggdh> OTH, you can check if the bug is correctly described, if steps for reproduction are listed, if the error is a consequence of incorrect usage, etc
[11:55] <brendon1> ok, I'm doing this to get experience at teamwork with programming.  So I would like to get as much hands on experience as possible.
[11:56] <hggdh> brendon1, I do not follow you how do you want to use teamwork programming on screening bugs?
[11:56] <brendon1> I'm a pretty good programmer, and a linux user for about 10 years, but I don't have any experience in working as a team on a shared system, know what I mean?
[11:57] <brendon1> so I thought that getting involved with the Ubuntu community would be a good start.  And this is where I found myself.
[11:57] <hggdh> ah, OK.
[11:57] <brendon1> Would you recommend I start triaging for starters?
[11:58] <hggdh> Yes, an online community helps.
[11:59] <hggdh> if you want to understand how Ubuntu works, yes (and we welcome the help!). There is a lot involved on fixing bugs, and most of it starts with understanding the bugs
[12:00] <hggdh> a developer will have a much easier task in a recode if the requirement (i.e. the bug that originated the request) is clear on what happened, how it happened, and why what happened is not the expected result
[12:00] <brendon1> ok, thanks, I'll see if I can't get started there.  Also, do you know if Ubuntu offers paid positions for people who contribute a lot?
[12:01] <hggdh> Ubuntu does not. Canonical, on the other hand, does offer employment positions
[12:03] <brendon1> that's good to know.  thanks.
[12:03] <hggdh> brendon1, you can look at http://webapps.ubuntu.com/employment/
[12:04] <hggdh> be aware that I would expect the requirements to be er, strong
[12:04] <brendon1> of course
[12:05] <brendon1> hggdh, do you contribute a lot for ubuntu?
[12:05] <hggdh> brendon1, not as much as I wish. I have limited time, being on the road a lot
[12:07] <brendon1> but you do what you can for free, correct?
[12:08] <hggdh> brendon1, correct. I am a volunteer, pretty much like most of the others around
[12:11] <brendon1> ok, good to know.  I'm happy to contribute for free myself.  Although I'm also looking for work these days.  I have a friend at HP and he's trying to get me in, but I'm not very optimistic.
[12:12] <hggdh> with the current market status in the US... yes, I understand you.
[12:12] <hggdh> OK, time to get out of the hotel & get to the current client. See you all this evening.
[12:12] <BUGabundo> bye hggdh
[12:13]  * BUGabundo slow fingers
[12:29] <brendon> if you want to correctly reproduce a bug should you be in the same release?
[12:48] <brendon> anybody home?
[12:51] <pedro_> brendon: in same and newer if there's any
[12:52] <brendon> hello pedro
[12:52] <pedro_> hey there :-)
[12:52] <pedro_> brendon: which bug are you looking?
[14:25] <bddebian> Boo
[14:31] <brendon> boo hoo
[14:35] <tw1tch> could some one help with https://bugs.launchpad.net/ubuntu/+bug/292355 should it be assigned to casper, or kde or xorg or other? thanks
[15:24] <evolio> hi guys
[15:24] <evolio> i am looking to upgrade to 9.04 to help look for bugs but i need help upgrading to it. does anyone have a macbook w/ intel graphics here?
[15:25] <pedro_> evolio: i have one and i'm using 9.04
[15:26] <evolio> ok, basically I tried to upgrade to it but when i rebooted I ran into bug #304871 i think
[15:26] <evolio> i got to GDM but it hung after that
[15:26] <evolio> is it likely to be that bug or is it another problem somewhere?
[15:27] <evolio> i have a 1.86GHz Core (1 not 2) duo w/ 2gb ram and GMA950
[15:28] <evolio> any idea pedro_?
[15:28] <pedro_> evolio: i'm looking
[15:29] <pedro_> evolio: did you tried the PPA version of the driver?
[15:30] <pedro_> i don't have such issue here with a 945GM
[15:31] <evolio> i haven't
[15:31] <evolio> but i get to GDM so I'm not sure if it's the same bug
[15:32] <evolio> i tried with alpha 5, so maybe 6 may of fixed something
[15:33] <evolio> do you recommend i just use update-manager -d?
[15:34] <pedro_> evolio: an apt-get update && apt-get dist-upgrade on the command line would work
[15:57] <ripps> Okay, I'm having a serious issue with libc-i686, I can't open any new programs because I'm having an error with /lib/tls/i686/cmov/libdl.so.2
[16:24] <martinald> hi there
[16:24] <martinald> i just upgraded my macbook from 8.10 to 9.04 and it's done the same thing - hangs after you type username and password into gdm
[16:25] <martinald> ah, may have a solution
[16:56] <pedro_> QA Team Meeting in ~4 minutes at #ubuntu-meeting
[16:56] <pedro_> hey jgoguen
[16:57] <jgoguen> hey pedro_
[17:36] <brendon> anyone here to help me get started with triaging?
[17:42] <mrooney> brendon: what do you need help with?
[17:42] <mrooney> brendon: we can always use help! the topic has some great resources such as https://wiki.ubuntu.com/HelpingWithBugs
[17:43] <brendon> I'm logged in to launch pad, I've read all the guides, I see a bug that I think I have input for.... so what do I do?
[17:43] <brendon> just respond to the post and confirm or deny the bug?
[17:43] <brendon> shall I click a certain button?
[17:44] <brendon> I want to help triaging
[17:45] <mrooney> brendon: what is the bug number? I can perhaps help you out
[17:45] <mrooney> but generally yes, if you can Confirm the bug it is great to do so
[17:47] <brendon> erm~  trying to get back there.
[17:47] <brendon> is there not a button to go directly to new bugs without discrimination?
[17:48] <brendon> here's one:  344546
[17:51] <brendon> and so, when we say to "confirm" the bug, that is just to leave a comment confirming that I can reproduce the bug?
[17:56] <mrooney> brendon: no it also means that you change the status to "Confirmed"
[17:56] <mrooney> bug 344546
[17:56] <mrooney> neato bug 344546
[17:57] <mrooney> brendon: okay so there are two steps here. If you can confirm it, before setting to confirmed, you should check if it has already been filed
[18:00] <brendon> ok, how would I do that?  just search?
[18:01] <mrooney> brendon: sure, google also works
[18:01] <mrooney> in this case I searched: firefox menu behind flash site:bugs.launchpad.net
[18:01] <brendon> ok, so I've searched now and I see that this has already been reported
[18:02] <brendon> so do I go back to the orignal and just make a note that it's already reported with bug num?
[18:02] <brendon> and in this case it seems there are multiple instances, which one do I go by?
[18:03] <mrooney> yeah so the second result there, is a duplicate of bug 49613
[18:04] <mrooney> HOWEVER this is getting complicated now because that is marked as Fix Released, meaning it shouldn't really be happening any more
[18:04] <mrooney> maybe bdmurray can help us
[18:05] <mrooney> ah no okay
[18:05] <brendon> well, first of all, I don't consider it a bug myself.  I think that it's just the behavior of the browser in linux.  I don't think it'll be changed.
[18:05] <mrooney> brendon: here we go! the reporter is using Hardy
[18:05] <mrooney> flash in Hardy is version 9
[18:05] <brendon> as am I
[18:06] <mrooney> reading the duplicate bug report, it was fixed in flash 10 beta 2
[18:06] <brendon> does that mean it's outdated?  what do I do in this case?
[18:06] <mrooney> so, what you should do is mark it is a duplicate of bug 49613 and leave a comment explaining that it is fixed in Flash 10 and upgrading to Intrepid or newer will solve the problem
[18:07] <mrooney> brendon: most reports are not nearly this complicated by the way :)
[18:07] <brendon> ok, well most reports seem more complex for me...
[18:07] <mrooney> brendon: so here are the stock responses: https://wiki.ubuntu.com/Bugs/Responses
[18:08] <brendon> I can only speak for my current release and for softwares which I use
[18:08] <mrooney> go to the duplicate one, copy that and add a comment
[18:08] <mrooney> changing NUMBER in it to the appropriate bug number
[18:09] <brendon> ok, thanks !
[18:09] <mrooney> then because the bug is fixed, add a line saying something like "This bug is fixed starting with Ubuntu 8.10, so upgrading should address this issue for you"
[18:09] <paulduf> https://wiki.ubuntu.com/UbuntuBugDay/20090319 have two copies of the bug #298844, as I said in bug #344961 (hugday close crased on it), one in New and one in Confirmed... wondering if it has been Confirmed during the list was created.
[18:10] <mrooney> brendon: and one last thing, that won't actually mark it as a dupe, you have to click "Mark as duplicate" below the title and type in the duplicate number, then you are done!
[18:10] <brendon> this one right?  "Bugs resolved after update or config change"
[18:10] <brendon> ok, gotcha
[18:10] <mrooney> brendon: no because it is a duplicate you want the "A duplicate" response
[18:11] <mrooney> brendon: let me know when you are done triaging it and I will look it over
[18:11] <brendon> ok
[18:11] <mrooney> paulduf: I guess that is possible, you could check the activity log
[18:17] <mrooney> brendon: okay so you duped it right but put the wrong bug in the description, and also didn't explain that the issue is fixed starting with Ubuntu 8.10
[18:17] <brendon1> ok mrooney: I'm all done: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/344546
[18:17] <mrooney> I'll add a comment :)
[18:18] <brendon1> that's a popular bug, I could un-duplicate it all day!!!
[18:19] <mrooney> brendon1: but do you see what I mean, how you put the wrong bug number in your comment
[18:20] <brendon1> yeah, I'm sorry about that, it wasn't until after I got to the dup page
[18:20] <mrooney> yeah no problem I added a comment explaining that and how to fix it :)
[18:20] <brendon1> I guess I should click back and change the number first next time
[18:20] <brendon1> ok
[18:24] <brendon1> what about people reporting bugs for old releases like Dapper or Hardy (which I use myself).  Do we always just recommend upgrading?
[18:25] <YoBoY> brendon1: no, Dapper and Hardy are LTS so the bugs have to be fixed :)
[18:26] <brendon1> LTS?
[18:26] <YoBoY> Long Time Support
[18:28] <Pici> !lts
[18:28] <brendon1> ok
[18:28] <YoBoY> oups term not time ^^"
[18:28] <brendon1> all the same ;)
[18:30] <brendon1> do you have a field of expertise in computers?  I mean, I'm pretty good with programming, but I'm a dunce at hardware or driver issues...
[18:31] <YoBoY> brendon1: if it's for helping with bugs ask here, if it's for support on install or compatibilityé better to ask on #ubuntu :)
[18:34] <brendon1> no problem, I was just getting chit-chatty
[18:44] <thekorn> pedro_, hi, which script is used to create the list of bugs for hug days?
[18:44] <thekorn> I'm wondering why 298844 is in the new and in the confirmed section for tomorrow
[18:45] <thekorn> which is breaking the hugday tool
[19:24] <pedro_> thekorn: we use bugnumbers for doing the list for the hug days
[19:32] <thekorn> pedro_, aha ok, so you run bugnumbers with an url for each section, there is no automation to create a wiki page with a few sections ("new", "confirmed", "with a patch") in one run
[19:34] <thekorn> so it is possible to have an entry with the same bug id in multiple sections, I think I will make the hugday tool to mark all this rows green in such case
[19:34] <pedro_> thekorn: yes that's correct and no there isn't a way to create everything in one run  AFAIK
[19:34] <pedro_> thekorn: that'd be a nice feature to have,  especially for bugs with patches for example ;-)
[19:35] <pedro_> they could appear on two lists too
[19:36] <thekorn> yeah, but I think closing one does not automatically mean that you can close this entry in the other section
[19:37] <thekorn> but I think we can just ignore this special cases
[19:37] <thekorn> to not overcomplicate things
[19:37] <mrooney> bdmurray: did you have any thoughts on my idea of making a package for the launchpad greasemonkey scripts?
[19:38] <mrooney> I'm willing to give it a shot if it seems useful
[19:45] <bdmurray> mrooney: The stuff I've read about converting gm scripts to extensions indicated the process is questionable
[19:45] <mrooney> bdmurray: oh really, any links? what was questionable?
[19:49] <bdmurray> mrooney: I'll have to look again.  If I find anything I'll reply to that thread on bugsquad
[19:50] <bdmurray> The scripts are updated rather frequently due to launchpad changes
[19:50] <bdmurray> However, the same was true of python-launchpad-bugs
[19:51] <mrooney> yeah that is why I think it is useful, one person updates the package, instead of everyone having to manually go to that page and install the new things one by one
[19:52] <thekorn> I have the greasemonkey scripts symlinked to the bzr tree, so it is only bzr pull and I'm up-to-date
[19:53] <bdmurray> thekorn: that's a good idea
[19:55] <mrooney> thekorn: where are the symlinked in to?
[19:58] <thekorn> ok what I did was: bzr pull lp:launchpad-gm-scripts  and opened the scripts with FF
[19:58] <thekorn> the I went into ~/.mozilla/ff/something/gm_scripts
[19:59] <thekorn> and searched for the javascript files and linked them to the ones in the bzr tree
[19:59] <mrooney> hm so if you want that to work on a multi-user environment, I wonder where you put them
[19:59] <mrooney> there is a /usr/share/mozilla/extensions
[20:00] <thekorn> not sure is this can be automated but at least for me it works
[20:00] <bdmurray> right, that's why an extension would be better
[20:00] <mrooney> yeah
[20:00] <mrooney> and then a package to install that EVEN better
[20:00] <bdmurray> I think adding it to the 9.10 roadmap would be a good idea
[20:01] <mrooney> I was just going to try to get something up in my PPA
[20:01] <mrooney> however looking at the adblock-plus package is hurting my brain
[20:01] <mrooney> I wonder if there is a simpler extension which is installed via a package
[20:01] <bdmurray> you might look at foxy proxy
[20:03] <thekorn> hehe, foxy proxy sounds funky
[20:03] <sectech> Ahoy! ...
[20:04] <sectech> bdmurray,  I have a bug for you that I flagged for review....
[20:04] <sectech> bug 313439
[20:04] <sectech> Originally I marked it as a wishlist and another triager came along and set it to high...
[20:05] <sectech> Even though upsteam invalidated it
[20:05] <sectech> upstream rather
[20:07] <bdmurray> sectech: its on the secuirty teams list
[20:08] <sectech> Not exactly sure who put it there though.
[20:08] <sectech> Or do you mean on there list outside of that report
[20:09] <bdmurray> I mean its on their radar for taking care of
[20:09] <sectech> Good enough... I'll unflag that on my to-do list..
[20:12] <sectech> I gotta start looking at when our meetings are, I keep missing them.
[20:13] <bdmurray> sectech: its the same time every week - 1700 UTC on Wednesdays
[20:14] <sectech> okay then I better start attending them then...
[20:23] <cadvocate> hi, which package should I submit an installation bug to?
[20:23] <bdmurray> cadvocate: the gui installer?
[20:24] <cadvocate> the Live CD installer.
[20:24] <cadvocate> for 8.10
[20:24] <bdmurray> cadvocate: ubiquity then
[20:24] <cadvocate> thanks.
[21:19] <sectech> Bug 264054, kind of interesting...
[21:20] <sectech> Is there an interrupt that cups could trigger or something to indicate the system shouldn't be put to sleep?
[21:23] <sectech> Actually I just noticed that the bug is quite dated.
[21:40] <axel_foley> hello @ all
[21:40] <axel_foley> i want to report a bug
[21:40] <axel_foley> my english is bad, but i hope u understand me
[21:40] <sectech> Are you familiar with launchpad?
[21:41] <axel_foley> no
[21:41] <sectech> All of our bugs are reported on a system called launchpad https://launchpad.net/ubuntu
[21:42] <axel_foley> sectech: i am the most of my time in "#ubuntu-de"
[21:42] <axel_foley> sectech: ok. thanks
[21:42] <sectech> That's fine...  I am just looking for the guidelines on filing a bug, I'll just be a sec
[21:42] <bdmurray> You can report a bug from your desktop though and a lot of information will gathered for you
[21:42] <sectech> apport, whoops
[21:45] <axel_foley> there some problems rebooting a system, when installed on a sw-raid5
[21:45] <axel_foley> i report this tomorrow. good night
[21:46] <sectech> bdmurray, Unless they specifically a gui application in mind I normally just direct them towards launchpad?
[21:47] <sectech> If it is an application that has a "report a problem" I will direct them towards that..
[21:47] <bdmurray> sectech: No, its really best to use apport first.  http://www.murraytwins.com/blog/?p=38
[21:48] <bdmurray> sectech: You can use 'ubuntu-bug linux' in a terminal and it'll grab a ton of information for you
[21:49] <sectech> Hmm.. okay... you just solved a question I had then...  I will be directing people towards that now
[21:49] <bdmurray> sectech: Are there any other unasked questions you have? ;-)
[21:51] <sectech> hehe.. That specifically wasn't the question... I did know about apport.    My unasked question refers to the "in the field" testing that I am doing with people... In an attempt to gain some feedback from "general" computer users who may not normally come across Ubuntu I have asked for participants (so far 3 have been requested)
[21:52] <sectech> Can these people that I am doing this trial with assign the bugs to me until I can look at them and then I will deal with them?
[21:53] <sectech> Chances are they will have no idea on even what a package is let alone how to file a bug... At the moment there instructions are to let me know what issues they run into before they get reported.
[21:54] <bdmurray> sectech: I don't think there is any way to guarantee that'll you be the first responser
[21:54] <bdmurray> responder
[21:55] <sectech> No your right... which is why I was going to get them to record what the bug # was and I was going to go in and assign them to me until I can look into them further.
[21:56] <sectech> It doesn't matter if another triager gets to them first... I just want to keep track of what issues are being ran into and what any concerns are.
[21:56] <sectech> The idea of assigning them to me would be so I can screen them
[21:58] <jgoguen> sectech: I'd be very interested in what you find from your field trials, maybe help with things in Fredericton
[21:59] <sectech> jgoguen,  I actually have 2 out of the 3 that I am looking for.. One is a UNB student, the other just uses her computer for general activities... It will be a good trial for providing feedback
[21:59] <sectech> It is important that they report any issues that they have... The question comes though, do I really want these posted to launchpad right away...
[21:59] <jgoguen> sectech: indeed, doing what at UNB?
[22:00] <sectech> jgoguen, Sorry STU I guess, not UNB. She is a getting a bachelor of arts I believe
[22:00] <sectech> I wanted 3 people who were not techies at all
[22:00] <jgoguen> sectech: depends...if it's something like "ZOMG cannt view YooToobe!" probably not :)
[22:01] <sectech> yeah, hence the idea of assigning them to me lol
[22:02] <sectech> I can't really ask them not to report bugs using apport because if they are legit I will want the system information that comes with it
[22:02] <sectech> I have a bunch of other marketing plans in the works too, which is off topic to this channel
[22:03] <jgoguen> sectech: you might want to get them to email you what they can to start and decide if they should report to Launchpad or not?  that way you avoid things that are trivial or not bugs, and you can still get them to use apport
[22:04] <sectech> Absolutely, at the moment the 2 I have are just getting acquainted with the system... I have received positive feedback so far.
[22:05] <jgoguen> and if they say something to start, you might say (for example) to report using "ubuntu-bug firefox" when it should be gnash...so if you talk to them before they report anything, you can get the right package right away
[22:05] <sectech> The trial is 6 months long, I probably won't get into bug reporting until they are in their 3rd month
[22:06] <sectech> You probably saw my facebook "Ubuntu Challenge" egh?
[22:06] <jgoguen> sectech: I did, and I like it :)


[00:34] <jjmiv> evening
[00:34] <rmg51> o/
[00:37] <jjmiv> what is everyone up to
[00:41] <rmg51> sleeping :-D
[00:43] <jjmiv> good point
[00:44] <rmg51> it's been quiet in here most of the day
[00:45] <rmg51> I'm getting ready to take a shower
[00:45] <jjmiv> yeah?brb
[01:24] <jjmiv> back
[01:45] <ChinnoDog> rmg51 can IRC in his sleep
[01:52] <rmg51> I just let Teddy do it for me ;-)
[01:55] <jjmiv> haha
[01:57] <jjmiv> night\
[09:29] <rmg51> Morning
[12:09] <teddy-dbear> Morning peoples, dogs, turkeys and everything else
[13:23] <ChinnoDog> morning teddy-dbear
[13:23] <teddy-dbear> o/


[19:33] <bashfulrobot> Hey guys. Just popping in to see what is up. Small intro. In Vancouver, Ubuntu Budgie team member, snapcrafter, and doing release management. Just trying to get a feel for the Canadian team status, goings on, etc.
[21:57] <genii> Hi bashfulrobot :)
[21:57] <genii> bashfulrobot: Toronto here. Some others in the channel are around Waterloo area
[21:58] <bashfulrobot> genii: Nice!
[21:58] <bashfulrobot> Prodominately east coast?
[21:58] <genii> Seems mostly, we may have one or two from Alberta
[21:59] <genii> bashfulrobot: I know of several more Canucks in other *buntu spaces, but they generally don't hang in this one
[21:59] <bashfulrobot> Ah I see.
[22:00] <genii> There's also #ubuntu-qc but I haven't been in there for a while
[22:02] <genii> bashfulrobot: I hold release parties here in Toronto since about 2010, one of the guys from Waterloo area usually comes up, we generally have 12-15 attendees
[22:02] <genii> And they hold one down there but usually after the actual release date
[22:02] <bashfulrobot> Yeah, I am starting to feel out hte local group.
[22:03] <bashfulrobot> I usually meet more people down at Linux Fest NorthWest.
[22:03] <bashfulrobot> in Bellingham.
[22:03] <bashfulrobot> Great Fest
[22:03] <genii> Yeah, we need a linux fest northeast ;)
[22:04] <bashfulrobot> get on it?
[22:04] <bashfulrobot> ha ha
[22:04] <bashfulrobot> I met so many great people there last year.
[22:04] <bashfulrobot> And starting 18.10 planning when we get there
[22:05] <genii> Well, I'd like to but
[22:05] <genii> I have a lot of other projects to keep me busy right now..
[22:05] <bashfulrobot> yeah.... I agree. Always hte issue
[22:05] <bashfulrobot> ( for me)


[01:22] <cube1> No NVIDIA driver version 470 for 21.10? There is for 21.04.
[01:23] <Bashing-om> !info nvidia-driver-470 impish
[01:24] <Bashing-om> !info nvidia-driver-470 hirsute
[01:32] <Bashing-om> !bug
[01:32] <cube1> Where can I follow the progress on, or the plans for adding newer packages? I'm excited for a few but too lazy to be manually compiling them.
[01:32] <cube1> newer versions* of packages
[01:33] <Bashing-om> !backports
[01:39] <Bashing-om> cube1: Not having much luck comming up with the happenstance of the nvidia-driver-470 package :(
[01:42] <Bashing-om> lotuspsychje: Ya keeping abreast of the nvidia 470 driver - by some chance ? "https://launchpad.net/ubuntu/+source/<package>/+publishinghistory" does not like me :D
[01:42] <TJ-> cube1: it's in impish-proposed
[01:43] <TJ-> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-470/+publishinghistory
[01:46] <Bashing-om> TJ-: :D Helps when the correct package name is used in serching :D
[01:48] <TJ-> Bashing-om: tip:   " apt-cache show nvidia-driver-470 | grep ^Source: "
[01:48] <TJ-> works for all binary packages
[01:48] <TJ-> also ubottu I think
[01:48] <TJ-> !info nvidia-driver-470
[01:49] <TJ-> well, for a release series !
[01:49] <TJ-> !info nvidia-driver-470 hirsute
[01:56] <lotuspsychje> Bashing-om: if its any help, i recently saw bug #1939673 passby
[01:57] <Bashing-om> TJ-: Thanks for the pro tip - noted :D
[01:58] <Bashing-om> lotuspsychje: I had thought that I had ran across where the 470 version driver in impish was on hold - but can not find my reference to that :(
[01:59] <TJ-> Bashing-om: mailing list ubuntu-devel maybe?
[02:00] <Bashing-om> TJ-: Seems most likely was on the M/L .
[08:43] <krytarik> !info nvidia-driver-470 impish-proposed
[08:48] <lotuspsychje> does that work with wayland these days?
[08:51] <krytarik> I've not heard so yet at least..
[11:49] <lotuspsychje> anyone up for a quick bug test, try this if you can reproduce in impish bug #1904316
[15:27]  * enyc meows
[15:27] <enyc> lotuspsychje: hrrm i have 21.04 on netbook, what problems happen if you  upgrade to impish directly already?
[15:28] <lotuspsychje> enyc: i didnt upgrade, im curious if this bug of mine on 20.04 persists on 21.10 aswell
[15:30] <enyc> https://discourse.ubuntu.com/t/impish-indri-release-schedule/18540   =)
[15:30] <enyc> not yet the ''testing week''
[15:30] <lotuspsychje> you can test on 21.04 too if you like
[15:31] <enyc> I see debian import is a thing about now
[15:31] <enyc> sa basicalyl 21.01 starts off with bullseye or so , seemingyl
[15:31] <enyc> or maybe they are importing many ''testing'' new packages already
[15:32] <lotuspsychje> enyc: im not looking for a release discussion, just this quick bug test
[15:34] <enyc> lotuspsychje: aaah 21.04 I can do...
[15:34] <enyc> well this is a ubuntu-next channel and 21.10 release and ideas others can discuss
[15:38] <enyc> lotuspsychje: not misformed on this 21.04 netbook
[15:39] <lotuspsychje> hmm interesting, tnx for testing enyc