[14:59] <henninge> Hi jtv!
[15:00] <jtv> hi henninge!
[15:00] <danilos> hi jtv!
[15:00] <danilos> hi henninge!
[15:00] <abentley> Hi danilos, jtv, henninge!
[15:01]  * mars wonders if he has the right meeting - looks like translations
[15:01] <jtv> hi abentley!
[15:01] <danilos> hi abentley!
[15:01] <rockstar> Hey, code's here too!
[15:01] <jtv> mars: we arrive by team now, like the Olympics
[15:01] <henninge> Hi rockstar!
[15:01] <danilos> ok, ok, we can stop this :)
[15:01] <abentley> Hi rockstar!
[15:01] <abentley> Hi mars!
[15:01] <mars> jtv, heh, so who gets to light the MootBot flame?
[15:01] <danilos> heh
[15:01] <mars> hi abentley!
[15:02]  * jtv plots out n² for some ballpark values of n
[15:02] <bac> hi barry?
[15:02] <rockstar> It's really early for me.  This is my least favorite meeting of the week.
[15:02] <sinzui1> barry lost his connection 3 minutes
[15:02] <sinzui1> ago
[15:02] <mars> rockstar, could be worse - look at thumper's TL calls :)
[15:02] <rockstar> mars, yes, those would be even worse.
[15:09] <mars> barry!
[15:09] <barry> irc sucks for me today
[15:09] <barry> sorry
[15:09] <sinzui> barry: your back for our meeting?
[15:09] <barry> #startmeeting
[15:09] <MootBot> Meeting started at 09:09. The chair is barry.
[15:09] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:10] <barry> hi everyone.  who's here today?
[15:10] <EdwinGrubbs> me
[15:10] <jtv> me
[15:10] <BjornT> me
[15:10] <mars> me
[15:10] <bac> me
[15:10] <henninge> me
[15:10] <abentley> me
[15:10] <adeuring> me
[15:10] <gary_poster_> me did not send the email *and* is not around for to give reviews today, again.
[15:10] <jtv> and danilos, too
[15:10] <gmb> me
[15:10] <danilos> me
[15:11]  * mars pokes flacoste
[15:11] <flacoste> me
[15:11] <barry> gary_poster_: ack
[15:11] <salgado> me
[15:12] <barry> allenap: ping
[15:12] <barry> cprov: ping
[15:12] <allenap> me
[15:12] <cprov> me
[15:12] <sinzui> me
[15:12] <barry> gmb: ping
[15:12] <barry> oops, gmb sorry
[15:12] <gmb> still me...
[15:12] <barry> noodles775: ping
[15:13] <barry> rockstar: ping
[15:13] <noodles775> me :)
[15:13] <rockstar> me
[15:13] <barry> [TOPIC] agenda
[15:13] <MootBot> New Topic:  agenda
[15:13] <barry> very light day today i thik
[15:13] <barry>     * Roll call
[15:13] <barry>     * Action items
[15:13] <barry>     * Mentoring update
[15:13] <barry>     * Peanut gallery (anything not on the agenda)
[15:13] <barry> [TOPIC] mentoring update
[15:14] <MootBot> New Topic:  mentoring update
[15:14] <barry> anything to report ?
[15:14] <henninge> I hear I graduated?
[15:14] <adeuring> yes, that's at least my proposal
[15:14] <henninge> Sorry for missing last week's meeting ...
[15:14] <barry> henninge: you did. i will send out the announcement today.  congratulations!
[15:14] <cprov> barry: noodles775 is almost there.
[15:14] <barry> cprov: fantastic
[15:15] <henninge> barry, adeuring. Thank you!
[15:15] <jtv> barry missed the opportunity for a cruel joke there
[15:15] <barry> jtv: :)
[15:15] <barry> henninge: you can switch from euro/friday if you want
[15:15] <henninge> anybody any suggestion?
[15:15] <barry> henninge: we have good euro coverage, so it's up to you.  if anyone else wants to switch, that's fine too
[15:16] <barry> i just want at least one person for each euro day
[15:16] <henninge> I think I had look a Tuesdays
[15:16] <barry> and remember al-maisan is on loan to ubuntu
[15:16] <barry> henninge: cool, just ping me when you decide
[15:17] <henninge> ok
[15:17] <barry> who is currently /not/ a reviewer (other than team leads)?  i know about deryck and leonardr
[15:18] <jtv> barry: I'm a reviewer but without OCR slot
[15:18] <jtv> (was holding this for the peanut gallery)
[15:18] <barry> jtv: let's get you a slot!
[15:18] <henninge> barry: noodles775 and me were the only ones when we started.
[15:18] <barry> jtv: what would work for you?
[15:19] <henninge> barry: so since onyl deryck has joined lately, I guess that is all.
[15:19] <jtv> barry: working day when I'm here starts 06:00 UTC.
[15:19] <barry> henninge: right.  and deryck has started doing js reviews
[15:19] <jtv> any glaring holes in the schedule for the hours after that?
[15:20] <barry> jtv: so america probably doesn't work for ya :)
[15:20] <jtv> barry: nyet, comrade
[15:20] <barry> jtv: we have two wholes in asia on tuesday and wednesday
[15:20] <jtv> barry: oh, you're beginning to spell like an Asian
[15:20] <barry> jtv: but other than that we have pretty good coverage.  you're always welcome to double up on a euro slot
[15:21] <danilos> jtv, henninge: it would be nice not to have you guys taken up on the same day to OCR
[15:21] <barry> jtv: sorry, i meant too hoales
[15:21] <henninge> danilos: I was just thinking that
[15:21] <jtv> barry: ohh, hoales
[15:21] <intellectronica> me (apologies for joining late)
[15:21] <jtv> so we're looking at a swap, not a hole
[15:21] <jtv> s/at/for/
[15:22] <gmb> jtv: How about Tuesday?
[15:22]  * gmb just wants an easier life ...
[15:22] <barry> gmb: or henninge on tuesday and jtv on friday?
[15:22] <jtv> gmb: yes, that would work
[15:22] <gmb> Either way works for me.
[15:22] <henninge> me on tuesday, jtv on wednesday.
[15:23] <jtv> barry: disadvantage of friday is: one needs-reply can bump your branch across my weekend.
[15:23] <henninge> friday gets pretty crowded, too.
[15:23] <henninge> reviewer-wise
[15:23] <jtv> which is just great for week 3's
[15:23] <henninge> yeah
[15:24] <barry> jtv, henninge why don't you guys work it out.  i'm fine with whatever you decide, just let me know
[15:24] <barry> i do think friday is well covered either way
[15:24] <jtv> barry: aye-aye
[15:24] <barry> thanks!
[15:24] <henninge> barry: me on tuesday, jtv on wednesday. My favorite.
[15:24] <barry> henninge: works for me.  jtv?
[15:24] <jtv> henninge: shall we do this out-of-channel?
[15:24] <jtv> oh
[15:24] <jtv> yeah, sure
[15:25] <barry> [AGREED] henninge to move to euro/tue, jtv to euro/wed
[15:25] <MootBot> AGREED received:  henninge to move to euro/tue, jtv to euro/wed
[15:25]  * jtv conspicuously fails to race to the needs-review queue Right Now
[15:25] <barry> [TOPIC] peanut gallery
[15:25] <MootBot> New Topic:  peanut gallery
[15:25] <barry> anybody have any topics not on the agenda?
[15:26] <flacoste> mars:
[15:26] <flacoste> ?
[15:26] <noodles775> Maybe the import error lint (F040...)
[15:26] <barry> noodles775: can you elaborate?
[15:26] <mars> barry, I have one
[15:26] <noodles775> There seems to be disagreement whether the lint warning about import errors should be disabled or left...
[15:26] <barry> mars: you're next
[15:27] <noodles775> Currently many files complain about this (i think after the code-reorgs...)
[15:27] <flacoste> noodles775: i think it's more buildout related actually
[15:27] <flacoste> i don't kjnow
[15:27] <abentley> noodles775 is describing lint failure messages when anything imports from canonical.launchpad
[15:27] <flacoste> but i also noticed that pylint is reporting crack error
[15:27] <barry> flacoste: maybe pylint doesn't have the correct sys.path?
[15:27] <flacoste> barry: it probably doesn't
[15:28] <gary_poster_> I'll look...
[15:28] <barry> flacoste: let's fix pylint if possible
[15:28] <barry> gary_poster_: thanks!
[15:28] <sinzui> We have other pylint issues
[15:28] <barry> [ACTION] gary_poster_ to look at bogus pylint import failures
[15:28] <MootBot> ACTION received:  gary_poster_ to look at bogus pylint import failures
[15:28] <danilos> we've seen them before buildout as well
[15:28] <sinzui> pylnt is different on jaunty and hardy
[15:28] <sinzui> They support different error messages
[15:28] <flacoste> yeah the utilities lint script should probably be moved to be generated by buildout
[15:28] <flacoste> so that it has the correct sys.path
[15:28] <bac> gary_poster_: if you fix the problem please look to remove directives in code which disable that warning
[15:28] <barry> flacoste: +1
[15:29] <flacoste> gary_poster is on leave for the next week
[15:29] <flacoste> so that will wait for 2 weeks at least
[15:29] <gary_poster_> bac, barry, flacoste, ok.  I'm out for a week and a day starting tomorrow, so I was intending to just diagnose
[15:29] <barry> gary_poster_: diagnose is fine.  please submit a bug report
[15:29] <gary_poster_> barry: ack, cool
[15:30] <barry> gary_poster_: thanks
[15:30] <barry> sinzui: as for the other pylint problems.  new bug report, or tack onto the one gary_poster 's going to file?
[15:31] <gary_poster> the interface stuff sinzui was mentioning in the review channel seemed unrelated, IIUC
[15:31] <sinzui> If we control the version of pylint, the we do not need to second guess what warning and suppressions are supported
[15:31] <noodles775> gary_poster: just fyi, an example here: https://code.edge.launchpad.net/~michael.nelson/launchpad/bug-376320-add-ppa-name-to-builder-status/+merge/7236
[15:31] <gary_poster> noodles775: gotcha.  looks very suspiciously buildout related, yes
[15:32] <sinzui> gary_poster: the interface/adapter stuff is not new, but in jaunty the frequency of false positives has increased
[15:32] <barry> cool, thanks guys.  let's move on to mars's issue
[15:32] <gary_poster> gotcha.  sounds like a legitimate problem, worthy of a bug report, maybe
[15:32] <sinzui> gary_poster: I don't think we can teach pylint about differed_import
[15:33] <mars> thanks barry
[15:33] <mars> ok, something for the JavaScript writers in the room
[15:33] <gary_poster> deferred, maybe not
[15:33] <mars> about two weeks ago QA started an experiment to bring manual testing into the JavaScript review pipeline
[15:33] <mars> https://wiki.canonical.com/Launchpad/Experiments/JavascriptTesting
[15:33]  * sinzui has pondered replacing his navel-lint script with apure python script that only enforces his rules.
[15:34] <mars> the idea is to have QA look at the work in different browsers during the code review step
[15:35] <mars> since it should be easier to catch and fix UI and browser issues while the branch is in development, rather than after-the-fact, on staging
[15:35] <mars> By the way, this is unrelated to the [js] landing tag
[15:36] <barry> mars: since after this cycle, it's all ui from here on out, should we enforce this experiment for the next cycle at least, if not all of the rest of 3.0?
[15:36] <mars> barry, I was going to ask for volunteers, rather than a team-wide experiment
[15:36] <mars> but it could work both ways
[15:36] <mars> the process is pretty simple
[15:37] <barry> what do others think?
[15:37] <intellectronica> i think it would be better to have everyone participate
[15:37] <rockstar> barry, I think it should be enforced now.
[15:37] <intellectronica> we don't really have time for partial experimentation. if we find that there are problems, we'll fix them
[15:37] <barry> i don't want to start this cycle, but i'd be willing to enforce it for 2.2.7
[15:38] <gmb> One thing to bear in mind here
[15:38] <gmb> Is sabdfl's edict at UDS:
[15:38] <gmb> UI reviews shouldn't be blockers to landing things.
[15:38] <gmb> Does this come under that?
[15:38] <intellectronica> that's a different thing
[15:38] <intellectronica> and no, it doesn't come under that
[15:39] <flacoste> "UI reviews shouldn't be blockers to landing things."
[15:39] <barry> gmb: right, separate.  and remember we have [ui=rs] (with the understanding that you'll back fill that review later)
[15:39] <flacoste> !?!
[15:39] <flacoste> that's the first i heard of it
[15:39] <flacoste> and not what we are applying now
[15:39] <mars> gmb, that's a design review, rather than "I just denied IE users access to the site"
[15:39] <rockstar> gmb, yes, this is the first I've heard of it too.
[15:39] <intellectronica> imperfect UI can be fixed (and anyway it's often a matter of taste). broken code is really bad and the shortest time to fixing is too long
[15:39] <flacoste> beuno's review are blocking
[15:39] <gmb> flacoste, rockstar: He said it in a Launchpad gripe session for, IIRC, the community team (could be wrong about which track it was in; it was all a blur).
[15:39] <intellectronica> yeah, i also never heard about ui reviews not blocking, b.t.w
[15:39] <jtv> flacoste: that's exactly the part that he said we shouldn't be blocking on.
[15:40] <gmb> What jtv said
[15:40] <flacoste> that's new
[15:40] <sinzui> The principle problem with UI reviews blocking is that developers are not submitting designs to beuno *before* they write code
[15:40] <flacoste> and should be discussed
[15:40] <flacoste> i don't agree
[15:40] <rockstar> gmb, I think we need clarification on what he meant, because as it is now, beuno's reviews block.
[15:40] <flacoste> we are very bad at fixing thigns later
[15:40] <intellectronica> are UI reviews a bottleneck at the moment? i didn't have that impression
[15:40] <gmb> So why does ui=rs exist then?
[15:40] <flacoste> for trivial stuff
[15:40] <gmb> intellectronica: A bit. It depends how much of a fight beuno and kiko get into.
[15:40] <flacoste> it's not uised anyway
[15:41] <sinzui> gmb: I can get rs if I designed the UI with beuno *first*
[15:41] <barry> flacoste: no.  ui=rs exists explicitly not to block on beuno's review
[15:41] <intellectronica> gmb: for trivial landings or when you absolutely can't get a ui review and are very confident
[15:41]  * barry remembers discussion that very fact with the man himself :)
[15:41] <rockstar> flacoste, the fact that we are bad at fixing things later is another issue.
[15:41] <intellectronica> gmb: surely if there's a disagreement it's even more important to resolve it before landing
[15:41] <sinzui> I am doing UI review *before* code, and I don't start until Martin and seen my proposal
[15:41] <rockstar> sinzui, I am doing the same.
[15:41] <gmb> intellectronica: Right, but I've had branches wait up to three weeks because of UI disagreements + week 4.
[15:42] <gmb> I'm not saying that we should just land things without talking to Martin.
[15:42] <jtv> I believe full UI reviews were ultimately to be for "real" design decisions, not for "does it look okay like this."
[15:42] <rockstar> sinzui, because often, more code changes happen on UI review than code review.
[15:42] <gmb> That's just crackpottery.
[15:42] <sinzui> rockstar: :)
[15:42] <intellectronica> gmb: sounds like you have to work a bit on your social engineering skills ;)
[15:42] <mars> jtv, good point
[15:42] <jtv> just repeating...
[15:42] <barry> rockstar: yes!  it's the 80/20 rule
[15:42] <flacoste> gmb: we should do a root-cause-analysis on your experience
[15:42] <rockstar> sinzui, also, I dread UI reviews, where I don't dread code reviews, so I do the band-aid thing.
[15:43] <barry> or its inverse. or something.
[15:43] <flacoste> anwyay, that's kind of besides the current discussion i think
[15:43] <flacoste> if we want to discuss UI reviews, we should bring that separately as another topic
[15:43] <gmb> flacoste: Well, I've got another big UI branch coming up in the next couple of days, so let's analyse that one rather than rehash my previous experience.
[15:43] <barry> flacoste: good point.
[15:43] <barry> let's take up ui review issues on the ml please
[15:44] <barry> as for js, let's vote on requiring the experiment for all devs in 2.2.7
[15:44] <rockstar> So, with the current QA plan, at least they can defer it.  I think we should request a review from them (so they get an email) but not block on it.
[15:44] <mars> barry, so!  full-team experiment for manual UI testing next cycle?
[15:44] <barry> [VOTE] require full-team experiment for manual ui testing in 2.2.7
[15:44] <MootBot> Please vote on:  require full-team experiment for manual ui testing in 2.2.7.
[15:44] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[15:44] <MootBot> E.g. /msg MootBot +1 #launchpad-meeting
[15:44] <barry> +1
[15:44] <MootBot> +1 received from barry. 1 for, 0 against. 0 have abstained. Count is now 1
[15:44] <mars> rockstar, we'll see if they get swamped - it's their call
[15:44] <mars> +1
[15:44] <MootBot> +1 received from mars. 2 for, 0 against. 0 have abstained. Count is now 2
[15:45] <gmb> +0
[15:45] <adeuring> +0
[15:45] <MootBot> Abstention received from gmb. 2 for, 0 against. 1 have abstained. Count is now 2
[15:45] <MootBot> Abstention received from adeuring. 2 for, 0 against. 2 have abstained. Count is now 2
[15:45] <rockstar> +0
[15:45] <MootBot> Abstention received from rockstar. 2 for, 0 against. 3 have abstained. Count is now 2
[15:45] <bac> +0
[15:45] <MootBot> Abstention received from bac. 2 for, 0 against. 4 have abstained. Count is now 2
[15:45] <jtv> +0
[15:45] <MootBot> Abstention received from jtv. 2 for, 0 against. 5 have abstained. Count is now 2
[15:45] <gary_poster> +0
[15:45] <MootBot> Abstention received from gary_poster. 2 for, 0 against. 6 have abstained. Count is now 2
[15:45] <noodles775> +0
[15:45] <MootBot> Abstention received from noodles775. 2 for, 0 against. 7 have abstained. Count is now 2
[15:46] <henninge> +1
[15:46] <MootBot> +1 received from henninge. 3 for, 0 against. 7 have abstained. Count is now 3
[15:46] <jtv> maybe we haven't talked this through enough; I for one don't have a clear picture of how it would fit into the process.
[15:46] <intellectronica> +1
[15:46] <MootBot> +1 received from intellectronica. 4 for, 0 against. 7 have abstained. Count is now 4
[15:46] <flacoste> +0
[15:46] <MootBot> Abstention received from flacoste. 4 for, 0 against. 8 have abstained. Count is now 4
[15:46] <flacoste> actually, that should be a +1
[15:46] <sinzui> What really is manual UI testing? What how do I know it is successful
[15:46] <flacoste> +1
[15:46]  * sinzui cannot vote, and wants to
[15:47] <mars> sinzui, I was about to get to that, then a car hit my topic :)
[15:47] <barry> sinzui: it's outlined on the wiki page
[15:47]  * gmb apologises for DUI.
[15:47] <intellectronica> sinzui: ideally, we should prepare test plans with clear predicates, but sometimes it will be just monkeying about with the interface
[15:47] <mars> the process is simple: you write up a manual test plan in the cover letter
[15:47] <abentley> -0
[15:47] <abentley> +0
[15:47] <MootBot> Abstention received from abentley. 4 for, 0 against. 9 have abstained. Count is now 4
[15:47] <mars> QA follows it for the A and C browsers
[15:48] <jtv> mars: who is responsible for making sure the branch goes all the way through the process?  Still the reviewee as usual?
[15:48] <mars> jtv, yes
[15:48] <flacoste> actually, i'm -1 on a full team experiment at this point
[15:48] <flacoste> not that it matters :-)
[15:48] <sinzui> I don't think this test can be performed by the team if they do not posses all the A-grade browsers
[15:48] <intellectronica> flacoste: why? and it does matter
[15:49] <mars> jtv, QA handles wrangling the people with the browsers for testing
[15:49] <flacoste> well, i don't have a veto :-)
[15:49] <mars> sinzui, we do
[15:49] <jtv> flacoste: I think that brings you to a total of 3 votes  :-)
[15:49] <barry> sinzui: devs don't but qa does
[15:49] <flacoste> i think the experiment is too vague at this point to make the whole team follow it
[15:49] <intellectronica> sinzui: iiuc diogo and ursula have access to all platforms, and it's up to them to delegate the work if and when they feel they can't handle the load
[15:49] <mars> sinzui, we do have the browsers.  QA has access to them, and to the pool of people who have registered as having the alternative environemnets
[15:49] <flacoste> and given that 2.2.7 is all-UI
[15:49] <flacoste> it could degenerate
[15:49]  * noodles775 is unsure *how* i can go about fixing my branch if it fails for IE6 on XP? XP licenses as per the email?
[15:50] <intellectronica> flacoste: it's clear in my mind. could it be that it's not adequately expressed?
[15:50] <flacoste> noodles775: you disable the feature for IE :-)
[15:50] <flacoste> intellectronica: probably
[15:50] <mars> noodles775, disable the feature, yes
[15:50] <flacoste> and we haven't experimented it at all yet
[15:50] <flacoste> (i think)
[15:50] <sinzui> our China OEMs are using IE6 on XP. They are not permitted to change browser or OS
[15:50] <intellectronica> flacoste: that's why experimenting during the remainder of 2.2.6 can help doing the real thing for 2.2.7
[15:50] <sinzui> They do not like Launchpad
[15:51] <noodles775> flacoste, mars: ok, FF3 on OSX?
[15:51] <jtv> sinzui: my shoes are broken, I don't like pavements :)
[15:51] <mars> sinzui, that's what we are addressing with this
[15:51] <barry> intellectronica, mars so perhaps volunteers for 2.2.6 to flesh out the process so everyone understands it?
[15:51] <flacoste> intellectronica: so let's do a two-weeks experiment using volunteers
[15:51] <mars> noodles775, not a concern, just the browser, not the environment
[15:51] <barry> btw, if the experiment is a failure we don't need to keep running it for the whole cycle!
[15:51] <noodles775> ok
[15:51] <sinzui> jtv: I bought new All-stars and Doc Martins in London because I had holes in my shoes
[15:51] <mars> noodles775, Opera on Linux is fine, no need for Opera on Win/OSX
[15:51] <jtv> flacoste: sounds good to me—reviewers could encourage reviewees to participate
[15:52] <jtv> flacoste: ...and if people don't want to, note a probable point for improvement
[15:52] <flacoste> that's the idea, volunteering reviewers
[15:52] <flacoste> are to make sure that the process is followed
[15:53] <sinzui> When using safari (Webkit) can we substitute Konqueror or Epiphany-webkit?
[15:53] <barry> we've gone over, and i apologize for that.  i will really try to fix my irc by next week
[15:53] <flacoste> if all the AJAX-team reviewers volunteer
[15:53] <mars> flacoste, I'll rely on barry's experiement experience here, but I do agree with your points, there is risk because it hasn't been tried yet
[15:53] <intellectronica> i rather do it for the remainder of 2.2.6 rather than two weeks, for simplicity, but either way is fine. i agree that a limited experiment is a good idea
[15:53] <flacoste> we kind of have a de-facto whole team experiment
[15:53]  * Ursinha reads
[15:53] <mars> sinzui, that I'm not sure about
[15:53]  * sinzui want to add small devices to to list
[15:53] <intellectronica> i'll most definitely volunteer, as i'm sure everyone from the bugs team will ;)
[15:53] <mars> sinzui, for Konqueror, no, you absolutely can not
[15:53] <sinzui> mars: they run the webkit version
[15:54] <barry> let's defer the whole-team decision until we see how the volunteer experiment works for the rest of 2.2.6
[15:54] <sinzui> Epiphany is on tip
[15:54] <mars> sinzui, heh, nice try, but no, the Webkit Konqueror is *not* Safari
[15:54] <flacoste> volunteers should sign up on the JavaScript experiment page
[15:54] <mars> I know, I tried it
[15:54] <sinzui> mars: 4.2 is I thought
[15:54] <barry> flacoste: +1 thanks
[15:54] <sinzui> QT
[15:54] <flacoste> and
[15:54] <jtv> barry: may haev to start a new vote before the bot gets confused
[15:54] <flacoste> we should put the link to the experiment in the launchpad-reviews channel
[15:54] <flacoste> for OCR
[15:54] <mars> sinzui, the engine, sure.  But it still doesn't work the same as Safari.
[15:55] <barry> #endvote
[15:55] <flacoste> so that dev can look if they need to follow-it
[15:55]  * barry knows a sure fire way to end the vote...
[15:55] <barry> #endmeeting
[15:55] <MootBot> Vote is in progress. Finishing now.
[15:55] <MootBot> Final result is 4 for, 0 against. 9 abstained. Total: 4
[15:55] <MootBot> Meeting finished at 09:55.
[15:55] <barry> thanks everybody!
[15:55] <intellectronica> thanks barry
[15:55] <jtv> thanks barry!
[15:55] <EdwinGrubbs> sinzui, mars: I had some good results using Arora to test webkit after I disabled its network caching.
[15:55] <sinzui> flacoste: can we engineer a JS oops AJAX lib that run in staging/edge clients and send us reports when our users know we broke something
[15:56] <mars> sinzui, yes, we can try.  It's on my Todo list
[15:56] <mars> sinzui, well, my Todo wishlist :)
[15:57] <flacoste> sinzui: we can anything, priorities, priorities, priorities
[15:59] <sinzui> flacoste: I think that by putting enough eyes on the problem (per the Open Source mantra) there will not be a problem
[15:59] <sinzui> We use automated testing because we do not have enough eyes
[15:59] <sinzui> JS + automated testing is painful
[16:00] <sinzui> so using oopses might be the best way to verify scripts
[16:00] <abentley> sinzui: JS + manual testing is also painful
[16:01] <sinzui> abentley: test for the sake of testing is painful. but users of staging and edge do not mind testing for us because we provide them newer services
[23:30] <thumper> hi barry
[23:30] <barry> #startmeeting
[23:30] <MootBot> Meeting started at 17:30. The chair is barry.
[23:30] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[23:30] <barry> hi thumper
[23:30] <barry> jml, mwhudson hi
[23:30] <mwhudson> hello
[23:31] <jml> hi
[23:31] <barry> [TOPIC] agenda
[23:31] <MootBot> New Topic:  agenda
[23:31] <barry> # Roll call
[23:31] <barry> # Action items
[23:31] <barry> # Mentoring update
[23:31] <barry> # Peanut gallery (anything not on the agenda)
[23:31] <barry> [TOPIC] mentoring update
[23:31] <MootBot> New Topic:  mentoring update
[23:32] <barry> just wanted to let you know that henninge has graduated
[23:32] <thumper> cool
[23:32] <barry> [TOPIC] peanut gallery
[23:32] <MootBot> New Topic:  peanut gallery
[23:32] <thumper> I've got a few things
[23:33] <barry> thumper: go ahead
[23:33] <thumper> the launchpad code team have moved all interface enums to lp.code.enums module
[23:33] <thumper> you may want to consider this too
[23:33] <thumper> also looking into trying out lp.code.errors for our exceptions
[23:33] <thumper> moving the enums reduces circular dependency issues
[23:33] <thumper> as they only rely on lazr.enum
[23:33] <barry> thumper: very nice
[23:33]  * jml has one item.
[23:33] <thumper> it was mentioned in the team lead call this morning
[23:34] <thumper> and foundations and registry may do the same
[23:34] <thumper> although I don't think foundations has any...
[23:34] <barry> thumper: +1
[23:34] <barry> registry has a lot
[23:34] <barry> thumper: did you talk at all about making .enums a package?
[23:34] <thumper> I'm done
[23:35] <thumper> barry: not exactly
[23:35] <barry> i'm a little concerned about having really huge modules
[23:35] <thumper> why make it a package than a module?
[23:35] <thumper> would the enums/__init__.py pull them in?
[23:36] <barry> thumper: no, but maybe that would just re-introduce the circs
[23:36] <barry> in any event, it's not a big deal for now at least
[23:36]  * barry was just curious
[23:36]  * thumper nods
[23:36] <thumper> lets see how it goes
[23:36] <barry> thumper: +1.  thanks.  did you have another issue?
[23:36] <thumper> there are advantages to just having one module
[23:36] <thumper> to get enums
[23:36] <thumper> from
[23:36] <thumper> like not having to think :)
[23:36] <barry> :)
[23:36] <jml> barry: does beuno attend a reviewers meeting?
[23:36]  * thumper passes floor to jml
[23:37] <barry> jml: he does not.  probably should though
[23:37] <thumper> perhaps I should pass the talking-stick to jml
[23:37] <jml> barry: even if it's just every second week, it'd probably be useful.
[23:37] <barry> jml: +1 i'll ask him to (i think he did at one point)
[23:38] <barry> jml: you're up
[23:38]  * barry has one when you're done
[23:38] <jml> barry: that was my topic :)
[23:38] <barry> jml: cool!
[23:38] <barry> at the ameu meeting, mars brought this up: https://wiki.canonical.com/Launchpad/Experiments/JavascriptTesting
[23:39]  * thumper looks
[23:39] <barry> the idea is to put qa in the critical path for branch approval.  this is manual js testing by qa
[23:39] <thumper> hmm..
[23:39]  * mwhudson mutters something about a "fix verified" bug status
[23:39] <barry> mars and company are asking for volunteers for 2.2.6 and we're considering making it mandatory team-wide (as an experiment) for 2.2.7
[23:39] <thumper> seems like a branch blocker
[23:40] <barry> that's not decided yet though
[23:40] <thumper> "fix confirmed" ?
[23:40] <barry> thumper: it could be yes
[23:40] <thumper> how would the qa be done?
[23:40] <jml> barry: I'll try to have a look at the page later on today
[23:40] <thumper> if it wasn't landed on trunk?
[23:41] <mwhudson> ec2!
[23:41] <barry> thumper: i think qa would run the branch and try it with the A and C browsers
[23:41] <jml> barry: my first reaction is "I thought we were trying to improve UI velocity"
[23:41] <barry> jml: btw, this is separate from ui=* and the js tags on pqm commits
[23:41] <barry> it's also separate from ui reviews
[23:42] <thumper> is it going to be a requested review from the qa team that has to be approved?
[23:42] <barry> thumper: i believe that's the idea
[23:42] <thumper> hmm...
[23:42] <jml> barry: this seems to confirm my impression that this will slow down branches :)
[23:42] <barry> ;)
[23:42] <thumper> I'm with jml on the velocity issue
[23:43] <barry> anyway, i just wanted to make you aware of the discussion at ameu :)
[23:43] <thumper> I was also going to raise the UI review not being blocking issue
[23:43] <jml> barry: thanks.
[23:43] <barry> that's all i have
[23:43] <jml> barry: I'd like to read this page & send my thoughts on later.
[23:43] <barry> jml: please do!
[23:43] <mwhudson> maybe we could have something like, if it works, the qa person should submit the branch
[23:43] <mwhudson> 1 less handoff
[23:44] <barry> that's an interesting idea too
[23:44] <mwhudson> or say, it's something the code reviewer should do
[23:45] <barry> anything else guys?
[23:45] <mwhudson> if we can build tools to make it easy
[23:45]  * thumper wants branch merge queues in LP
[23:45] <jml> barry: a low priority thing
[23:45] <mwhudson> thumper: yes
[23:45] <mwhudson> thumper: also, a pony
[23:46] <jml> barry: have you ever looked at the bzr developer docs?
[23:46] <barry> jml: it's been a while
[23:46] <jml> barry: http://doc.bazaar-vcs.org/latest/developers/index.html
[23:46] <jml> barry: maybe this is something we can work towards before, during & after open sourcing
[23:47] <barry> yes!  i'd also like to take a shot at sphinxing our docstrings
[23:47] <jml> doctests, itym
[23:47] <barry> both actually, as we markup more of our docstrings
[23:47] <mwhudson> there's still nightly pydoctor output
[23:48] <jml> right. was about to mention :)
[23:48] <mwhudson> at https://devpad.canonical.com/~mwh/canonicalapi/
[23:49] <thumper> :(
[23:49] <thumper> we don't have much documentation for lp.code
[23:49] <jml> barry: anyway, what I mean is -- *I* get lost trying to find our reviewer, developer, testing docs & guidelines
[23:49] <jml> barry: it's an oral tradition for me
[23:49] <mwhudson> (i get emailed a list of which docstrings aren't valid reST every night...)
[23:49] <jml> (which is why these meetings are so valuable)
[23:49] <barry> jml: i hear ya
[23:50] <barry> mwhudson: any chance you can send those to launchpad@?  would make a nice email nag to reduce techdebt
[23:50] <jml> better yet, any chance you can get 'make lint' to tell us about them.
[23:50] <barry> or that
[23:50] <mwhudson> i would really really really like it if it was someone's job to make the developer experience better
[23:51] <thumper> foundations?
[23:51] <mwhudson> barry/jml: yes, am wary of spamming launchpad@ more
[23:51] <jml> me too.
[23:51] <mwhudson> thumper: a nice idea, it's not what they actually do though
[23:51] <barry> i'm not.  i already have too much spam, so a little more won't hurt :)
[23:51]  * jml tries.
[23:51] <mwhudson> jml: file a bug about having make lint warn about this?
[23:51] <barry> mwhudson: me too.  *especially* after we open source. i'm hoping to find time to actually work on that
[23:52] <jml> ok.
[23:52] <mwhudson> jml: it's not that we don't try, it's that it's noone's main responsibility
[23:53] <barry> mwhudson: exactly
[23:53] <jml> mwhudson: agreed.
[23:53] <jml> I think we're coming to a close here.
[23:53] <thumper> agreed
[23:54] <barry> and with that...
[23:54] <barry> #endmeeting
[23:54] <MootBot> Meeting finished at 17:54.
[23:54] <mwhudson> thanks barry
[23:54] <barry> thanks guys
[23:54] <thumper> thanks barry
[23:54] <jml> mwhudson: https://bugs.edge.launchpad.net/launchpad/+bug/385736
[23:55] <mwhudson> jml: thanks


[00:02] <jrwren> I listened to this not too long ago, Josh was involved: http://www.thisislabel.com/discography/multiples-multiples/
[00:07] <jgransden> i have to be in the right mood to listen to any of that kind of stuff
[00:28] <jgransden> btw, we were talking about headphones like a week ago, you said that cheap synheisers were good, i picked up a pair and they are. Dont think they are as nice as my sonys but great to have in my laptop bag
[00:29] <rick_h__> jrwren: yep hello from monday morning
[01:16] <jrwren> rick_h__: good luck! have fun!
[01:16] <rick_h__> jrwren: wheeee
[01:16] <jrwren> rick_h__: be proud. :)
[01:16] <rick_h__> damn straight
[02:38] <cmaloney> domo arigatou Mr. Roboto
[02:39] <rick_h__> hah
[11:53] <rick_h__> evening
[13:59] <wolfger> Morning
[13:59] <wolfger> Where are you at, rick_h__ ?
[14:13] <jrwren> wolfger: he is in Tokyo for Openstack Dev Summit
[14:18] <cmaloney> Morning pt. 1
[14:21] <brousch> Is OpenStack the same as OpenShift?
[14:21] <jrwren> no.
[14:21] <cmaloney> Openshat. ;)
[14:22] <jrwren> what is openshift.
[14:22] <jrwren> brousch: openstack is an umbrella project like apache, but its not run as nonprofit like apache. It is run as a trade association, I think.
[14:23] <brousch> Ah, OpenStack is IAAS and OpenShift is PAAS which can be run on OpenStack
[14:25] <wolfger> Cool. I never have been to Tokyo. Mostly Kumamoto.
[14:26] <cmaloney> Kumao. ;)
[14:27] <cmaloney> Comau, actually. Isn't that the robotics company?
[14:28] <jrwren> brousch: is openshift even open? I've never heard of anyone running it.
[14:30] <brousch> https://blog.openshift.com/openshift-origin-vs-openstack/
[14:30] <brousch> I guess part of it is
[14:33] <jrwren> i honestly didn't know there was opensource paas other than cloud foundry
[14:35] <jrwren> so... i just read the splash page at http://www.openshift.org/  and I already don't like it :)
[14:36] <jrwren> anyone here use openshift?
[14:42] <jcastro> there's like 9 billion OSS PaaSes
[14:44] <jrwren> jcastro: only 1 that matters. Cloudfoundry :p


[06:13] <Azendale> zradmin_: could you eloborate (or just point me to something the tells me) what is up with quantum/neutron in havana? I'm trying to set up my first HA setup (in a test lab) and I have been trying to get Quantum and Havana
[08:02] <AskUbuntu> If a Juju HA Cluster charm fails to deploy, will removing the HA cluster charm service mess up the service that was behind it? | http://askubuntu.com/q/366059
[21:22] <Azendale> I'm trying to debug why the havana rabbitmq-server is ha-relation-changed hook failing for me. Looking at it with the python debugger, it looks like it is trying to get the IP address if an interface that is part of a bridge. I have posted the log of the debugging session at http://paste.ubuntu.com/6308674/ and the section of my config for the two charms at http://paste.ubuntu.com/6308674/.  Could someone tell me if it's something I'm doing/setting wrong? Or is
[21:26] <Azendale> specifically, is setting "vip_iface: 'eth0'" for the rabbitmq-server breaking it?
[21:53]  * Azendale decides he'll try re-deploying rabbitmq without that option and find out
[21:59] <stryderjzw> How does one debug a install hook? Just destroy-service and deploy? Can I just run the hook?
[22:02] <Azendale> stryderjzw: first, run 'juju status' so that you know exactly which unit of the service failed
[22:02] <Azendale> stryderjzw: (unit(s) are grouped together to make a service, which is what you deploy)
[22:03] <stryderjzw> I see
[22:03] <Azendale> stryderjzw: a unit name should have something like 'mysql/2' (unit names end in a slash and some number)
[22:04] <Azendale> stryderjzw: then run 'juju debug-hooks <unitname>' from the juju client
[22:04] <stryderjzw> My node-app/0 install hook is failing
[22:04] <stryderjzw> so i'd have to run juju resolved --retry after that?
[22:04] <Azendale> stryderjzw: yep, you got it
[22:04] <stryderjzw> Azendale: Thanks!
[22:05] <Azendale> stryderjzw: it will ssh you to the box. Then when you run retry, it will start another prompt for you with the name of the hook
[22:06] <Azendale> stryderjzw: then you just want to run/debug the script 'hooks/<hook_name>', which in your case would probably be 'hooks/install'
[22:07] <Azendale> stryderjzw: See (if you haven't already) http://askubuntu.com/questions/362687/juju-debug-hooks-how-to-run-hook-in-debug-terminal-or-get-more-information
[22:07] <stryderjzw> Azendale: Thanks. So, when I make changes to the hooks/install... what's the best way to update the charm?
[22:08] <Azendale> stryderjzw: no problem, your welcome
[22:10] <Azendale> stryderjzw: unfortunately, I really don't know the best way to update. I'm learning it from the user side towards learning how to debug/fix, so I haven't tried to develop a charm before -- I've only tried to get it to work when it breaks
[22:10] <stryderjzw> Azendale:  Ah. This node-app charm doesn't take a PRIVATE repo from github. So I'm trying to modify it.


[00:08] <cmaloney> evening
[00:19] <rick_h_> evening
[00:22] <cmaloney> how goes?
[00:23] <greg-g> yo yo
[10:42] <brousch> Hm, U-M has 2 Coursera courses: Python and web design. Python course is from Charles Severance
[10:42] <brousch> https://www.coursera.org/browse/computer-science
[10:59] <cmaloney> Morning
[11:59] <brousch> yes
[13:15] <jrwren> pretty sure you know python better than any course could teach you.
[13:16] <jrwren> then again, its college, so some of the general compsci might be good.
[13:16] <jrwren> i don't remember if you were a compsci major, brousch ?
[13:20] <mrgoodcat> i occasionally run through a course like that just to see. sometimes you learn little things like syntax shortcuts and such
[13:21] <jrwren> good point.
[13:21] <jrwren> there are a lot of python syntax shortcuts I never mastered because python2 is still a thing :(
[13:21]  * jrwren rages against python2
[13:22] <mrgoodcat> i use py3 when i can
[13:22] <mrgoodcat> i dislike that python2 is still teh default python in most distros
[13:23] <jrwren> mrgoodcat: you'll love ubuntu wiley  :)
[13:23] <brousch> jrwren: I didn't take anything above CS 200 level courses. I have a BS in Anthropology
[13:23] <jrwren> mrgoodcat: less than 4 weeks away!
[13:23] <jrwren> brousch: ah, then algorthims stuff in a college course would likely be great.
[13:23] <mrgoodcat> jrwren: can't wait :)
[13:23] <brousch> I don't plan on taking the courses, I just find it interesting what U-M is up to these days
[13:24] <mrgoodcat> although the only ubuntu i use has been lts as of late
[13:24] <jrwren> brousch: oh, u-m is still all c++ afaik
[13:24] <mrgoodcat> so i have to wait for 16.04
[13:24] <jrwren> then again, it has been a few years since I met any students or recent graduates.
[13:24] <mrgoodcat> i'm a student
[13:24] <jrwren> mrgoodcat: at umich?
[13:24] <mrgoodcat> no
[13:24] <mrgoodcat> but that wasn't what you said
[13:25] <jrwren> context.
[13:25] <brousch> I am weak in algorithms and design patterns
[13:28] <brousch> I thought U-M was moving to Java when I left in 1999
[13:29] <mrgoodcat> likely they were
[13:29] <jrwren> brousch: design patterns are just knowing names for things. Its like knowing the names of birds. Its only useful if it is useful.
[13:29] <mrgoodcat> most schools i know of are java now
[13:29] <mrgoodcat> although usually there is still some c++ required
[13:30] <jrwren> brousch: they definitely were not in the early 2000s. They were c++. I know a handful of grads who finished in '05 and they were very good c++ devs.
[13:30] <jrwren> I was impressed because most kids coming out of college think they can code and think they know c++, but really don't. These kids were the real deal.
[13:31] <jrwren> Then again, c++ now is quite a bit different than c++ 10 years gao :)
[13:31] <jrwren> *ago
[13:32] <cmaloney> I still don't know Design patterns
[13:32] <cmaloney> at least the name of things
[13:32] <cmaloney> Every time I start reading about them I get bored and drift off
[13:32] <jrwren> cmaloney: they are exceptionally dull
[13:32] <jrwren> and knowing more than a few of them is utterly useless
[13:33] <jrwren> many of them are language specific.
[13:33] <cmaloney> Yeah
[13:33] <cmaloney> Same with knowing bird taxonomy
[13:33] <jrwren> e.g. Observer Pattern in C# is implemented in the language - its called events.
[13:33] <jrwren> haha, birds.
[13:34] <jrwren> i see a black bird, and I say, hi black bird. I see a blue bird, and I say hi blue bird. and so on...
[13:35] <jrwren> I think knowing antipatterns is more useful than knowing design patterns.
[13:35] <brousch> EECS 281 (Data structures and Algorithms) kicked my butt twice. I hated memory management (C/C++) and pointers. these are the primary things that kept me from getting to 300 level CS courses
[13:35] <cmaloney> I get that we need to have lingua franca and what-not, but I'll be damned if I'll pull "Observer Pattern" out of something that's "Event driven"
[13:35] <cmaloney> memory management is tricky stuff. Even the computer doesn't get it right
[13:36] <brousch> this is why I use Python now, but I'm not really an awesome programmer
[13:36] <cmaloney> "Did you free that memory?" "0" "Does that mean yes?" "Banana!"
[13:37] <jrwren> all the recent c++ trends agree. its considered bad form to use new and delete yourself now.
[13:37] <jrwren> C++ folks have basically said, memory management is hard.
[13:37] <cmaloney> "Yo! I heard you liked releasing memory so I free'd the free'd the free'd the free'd the SEGFAULT"
[13:38] <cmaloney> Hah
[13:38] <cmaloney> jrwren: How times change
[13:38] <cmaloney> 1990 / 2000 was all about that destructor
[13:39] <jrwren> cmaloney: well, its also a different world. 20yrs ago when I started c/c++, most programs weren't long lived. they'd run, do their thing and terminate. Now everythign is a long time running server.
[13:39] <jrwren> cmaloney: oh, the destructor is still there and important, afaik. you just won't call delete from it :)
[13:39] <cmaloney> heh
[13:39] <cmaloney> Been a while since I looked at C++
[13:39] <cmaloney> I need to give it a peek again
[13:40] <cmaloney> see if it makes my stomach churn
[13:40] <jrwren> cmaloney: just be careful where you look. there is a lot of bad info, bad advice out there.
[13:40] <cmaloney> I wouldn't look at a book prior to 2010
[13:40] <jrwren> Bjarn actually said this in his cppcon talk
[13:40] <cmaloney> and certainly not Bjarne's book
[13:40] <jrwren> :)
[13:40] <jrwren> EffectiveC++ then?
[13:40] <cmaloney> possibly
[13:40] <cmaloney> I think I have that laying around
[13:41] <cmaloney> Picked up a decent looking C++ Games book
[13:42] <cmaloney> http://www.amazon.com/Beginning-Through-Programming-Fourth-Edition-ebook/dp/B00LZW07P0
[13:43] <cmaloney> "4.0 out of 5 starsI'd say taht this is a good, a realy good"
[13:43] <cmaloney> Can't go wrong with that review
[13:44] <jrwren> why a game programming book?
[13:44] <cmaloney> I like games? :)
[13:45] <cmaloney> Plus it doesn't teach a library, all of the games are text-based
[13:45] <cmaloney> so you're not fighting with something like Unity3d while learning hte language
[13:46] <jrwren> ha, timely: https://twitter.com/wc_duck/status/646957178235035649
[13:47] <cmaloney> heh
[13:49] <jrwren> for the record: I'm a total c++ n00b.
[13:49] <cmaloney> The syntax put me off
[13:49] <jrwren> really?
[13:50] <jrwren> well, it is hard to beat python.
[13:50] <cmaloney> It just felt like it was bastardized C to me
[13:50] <cmaloney> I find C can be quite beautiful
[13:51] <cmaloney> C++ felt like a lot of boilerplate
[13:51] <cmaloney> similar to Java
[13:52] <jrwren> so, that is kind of what bjarne said in that same keynote.
[13:52] <jrwren> he said most c++ is bad.
[13:52] <jrwren> he said clases are overused, there is a reason c++ has functions just like C
[13:52] <jrwren> he said a lot of c++ devs go out their way to use all htese complex features when simple things would work.
[13:53] <cmaloney> Did he fall on his sword because that's what it sounds like. ;)
[13:56] <jrwren> :)
[13:56] <jrwren> I think he more cried, "its not my fault everyone else sucks."
[13:56] <cmaloney> heh
[14:23] <mrgoodcat> after lots of work i finally reduced my vimrc to 72 lines (only 27 of which are actually directives) and got rid of all vim plugins
[14:23] <mrgoodcat> removed all the old crufty crap that i installed, used once, and forgot about
[14:23] <cmaloney> heh
[14:23] <mrgoodcat> my vimrc also has a comment for every single directive now
[14:23] <cmaloney> " This sets the value of a to 42
[14:23] <mrgoodcat> lol
[14:23] <mrgoodcat> some of them are simple like that
[14:24] <cmaloney> "This ensures that something down the chain works. Fuck if I know what it actually does
[14:24] <cmaloney> " This sends my bank information to the IRS, FBI, and NDA
[14:24] <cmaloney> NSA
[14:24] <cmaloney> hah, NDA my ass
[14:25] <mrgoodcat> https://github.com/dyladan/dotfiles/blob/master/vimrc
[14:25] <jrwren> I should probably do that.
[14:25] <mrgoodcat> it feels nice
[14:26] <jrwren> i bet I have 27 color directives commented out, so that I know what color options are available
[14:26] <mrgoodcat> like replacing all your socks and getting all matching pairs
[14:27] <mrgoodcat> i think line 17 and 23 are my most used
[14:27] <cmaloney> You can do that?
[14:27] <mrgoodcat> imap jk <esc>`^:%s/ \+$//eg<return>`^:w<return>
[14:27] <mrgoodcat> imap kj <esc>
[14:27] <mrgoodcat> jk leaves insert mode, removes trailing spaces, and saves
[14:27] <mrgoodcat> kj just leaves insert mode
[14:27] <mrgoodcat> screw reaching for esc
[14:28] <jrwren> i would hit that all teh time navigating up and down lines.
[14:28] <_stink_> doesn't rick_h_ use jj or something?
[14:28] <_stink_> for esc
[14:28] <mrgoodcat> jrwren: not in insert mode you wouldn't
[14:28] <rick_h_> _stink_: yes, in zsh and in vim
[14:28] <rick_h_> ftw
[14:28] <rick_h_> yes in insert mode
[14:29] <rick_h_> and it's awesome, home row and one char ftw
[14:29] <jrwren> map esc to ` as god and the terminal on which vi was written intended :)
[14:29] <jrwren> err, tab.
[14:29] <rick_h_> heh, except ~ moves on keyboards, especially kenisis/etc
[14:29] <jrwren> maybe it was tab location is esc?
[14:29] <rick_h_> esc was where tab or caps lock was on that terminal
[14:30] <rick_h_> so it was close/on home row
[14:30] <rick_h_> jj is awesome, there's like 3 words that use that
[14:30] <rick_h_> and if you do NEED a jj you just type it slowly
[14:30] <mrgoodcat> jk and kj are the best
[14:30] <mrgoodcat> and in insert mode i'm not using them to move
[14:30] <rick_h_> there's a timer on that for 100ms or something
[14:30] <_stink_> what words use jj?
[14:30] <mrgoodcat> very few if any
[14:30]  * cmaloney still needs to get rick_h_ a proper ADM terminal
[14:30] <rick_h_> mrgoodcat: nope, why two fingers? when you can do one?
[14:30] <jrwren> there is no except. look at the keyboard as it was on a adm-3a, make your KB the same. then vi is usable
[14:30] <mrgoodcat> rick_h_: can hit faster with two
[14:31] <jrwren> https://en.wikipedia.org/wiki/ADM-3A  the KB used to write vi
[14:31] <rick_h_> mrgoodcat: with proper keys I disagree
[14:31] <rick_h_> you're not taking your finger off
[14:31] <cmaloney> https://en.wikipedia.org/wiki/ADM-3A
[14:31] <cmaloney> ;)
[14:31] <mrgoodcat> roll right for save roll left for not save
[14:31] <mrgoodcat> can hit the second key while key 1 is still down
[14:31] <mrgoodcat> hitting them at pretty much the same time
[14:31]  * jrwren maps tab to esc :)
[14:31]  * cmaloney looks for the "Here is" key
[14:32] <rick_h_> jrwren: how do you tab in code then?
[14:32] <jrwren> rick_h_: i'd never do that. gofmt does it for me :)
[14:32] <rick_h_> jrwren: ugh
[14:32] <jrwren> ctrl-i maybe :)
[14:32] <rick_h_> insanity
[14:32] <cmaloney> Or you use CTRL-I
[14:32] <cmaloney> Dammt
[14:32] <rick_h_> lol
[14:32] <cmaloney> jrwen is jinxing me
[14:32] <rick_h_> once you go jj you never go back :P
[14:33] <jrwren> rick_h_: gofmt is opoiste of insanity. imagine all pep8 violations being automatically resolved on every file save. its glorious
[14:33] <jrwren> unfortunately, nothing fixes my spelling.  opposite?
[14:33] <rick_h_> http://www.wordfind.com/contains/jj/
[14:33] <jrwren> grep jj /usr/share/dict/words
[14:33] <jrwren> jk is in Dijkstra :)
[14:34] <jrwren> jj wins.
[14:34] <cmaloney> rick_h_: I hope you never have a Scandanavian employee. :)
[14:34] <mrgoodcat> http://www.wordfind.com/contains/jk/
[14:34] <mrgoodcat> 1 word
[14:34] <mrgoodcat> 3 contain kj
[14:36] <jrwren> more than 3
[14:36] <jrwren> well, blackjack, lockjaw, and some propernames.
[14:37] <mrgoodcat> wordfind didn't find blackjack
[14:37] <mrgoodcat> interesting
[14:37] <mrgoodcat> did find inkjet though
[14:38]  * rick_h_ claims enough old man greybeard cli points to guffaw at alternatives to jj :P
[14:38] <rick_h_> without any data other than experience
[14:39] <cmaloney> funnily enough I knew a gent who had an IRC nick with jj in it
[14:40]  * cmaloney remembers simpler times when sending +++ over IRC would reset some stupider modems
[14:40] <jrwren> ha, inkjet isn't in dict/words :)
[14:40] <cmaloney> NOCARRIER
[14:41] <rick_h_> cmaloney: you'd tab complete that anyway and never type it :P
[14:41] <rick_h_> boom!
[14:41] <cmaloney> Well, it also assumes you're using IRC from vim in insert mmode
[14:41] <cmaloney> so MMMOOOOOOBBB
[14:46] <mrgoodcat> yea
[15:27] <cmaloney>  Shigeto - There Is Always Hope (Mux Mool Remix)
[15:27] <cmaloney> ^ hearing an echoey voice saying "Michigan michigan michigan..."
[15:27] <cmaloney> Thanks Soma.fm
[15:28] <cmaloney> also: have a replacement for how I use last.fm
[16:46] <jrwren> so... we went from no python podcasts, to a new one every month, it seems.
[16:46] <jrwren> anyone want to start a python podcast?
[16:54] <cmaloney> heh
[17:38] <cmaloney> I think I've hit mini-rick_h_
[17:38] <rick_h_> ?
[17:38] <cmaloney> I have multiple tmux sessions, each full-screen, with multiple panes in each.
[17:39] <jrwren> but all one tmux server?
[17:39] <cmaloney> Each is it's own server
[17:41] <jrwren> ah. bummer. that sounds rough
[17:42] <cmaloney> Nah, it's quite cool
[17:42] <cmaloney> No complaints, or I wouldn't do it
[22:12] <brousch> What the ...  https://blog.adafruit.com/2015/09/23/a-breadboard-for-pebble-smartstrap-lovers-wearablewednesday/
[22:45] <cmaloney> That is awesome.


[00:26] <thumper> wallyworld: I need an extra 10 minutes to kick out the in-laws
[00:26] <thumper> wallyworld: chat after that?
[00:26] <wallyworld> sure
[00:59] <axw> wallyworld: ping
[01:00] <wallyworld> axw: hey, just talking to tim, see you in standup hangout soon?
[01:00] <axw> wallyworld: sure, I'll wait in there
[03:14] <wallyworld> axw: could you take a look at http://reviews.vapour.ws/r/963/ for me?
[03:14] <axw> looking
[03:14] <wallyworld> ty
[03:15] <wallyworld> axw: also, eric raised a point about the rootfs provider - it won't work as written on windows
[03:15] <axw> wallyworld: yeah, storage in general is not expected to work on windows in the first iteration AFAIK
[03:16] <axw> we will need to disable it in tests if they're going to break
[03:16] <wallyworld> good yes, i couldn't quite recall if we agreed to that or not
[03:16] <wallyworld> tests shouldn;t break as it's all stubbed out
[03:16] <axw> 99% sure that Mark agreed to that
[03:16] <wallyworld> yes i do recall that now
[03:27] <axw> wallyworld: reviewed
[03:27] <wallyworld> ty
[03:33] <axw> wallyworld: I don't think the error is to do with arch mismatch... I created an env on AWS and it's missing the tools symlink for the container
[03:33] <wallyworld> axw: hmmm. that doesn't make sense based on the code
[03:33] <wallyworld> the symlink might be missing
[03:33] <axw> wallyworld: the container was started with the correct arch.
[03:33] <wallyworld> but the tools selection si broken
[03:33] <axw> wallyworld: where?
[03:34] <wallyworld> yes, the container image itself will be correct
[03:34] <wallyworld> in provisioner_task
[03:34] <wallyworld> possibleTools, err := task.toolsFinder.FindTools(
[03:35] <wallyworld> this used to use the HasTools interface implemented by the container provisioner to lok h tols
[03:35] <wallyworld> lock the tools
[03:36] <axw> HasTools was a hack. what's there will work if the constraints has the correct arch... which seems to be the case since it's picking the right arch
[03:40] <wallyworld> but the constraints won't always have the correct arch
[03:41] <wallyworld> they may be empty
[03:42] <axw> wallyworld: perhaps there's two bugs, I'll keep looking
[03:42] <wallyworld> axw: the constraints will be empty if you just bootstrap with nothing else
[03:42] <wallyworld> then the new machine 1 will have m.Constraints() without an Arch
[03:43] <axw> wallyworld: I thought Juju might add the host machine's arch as a constraint for LXC, doesn't look like it does tho
[03:43] <wallyworld> yeah
[03:43] <wallyworld> that's the issue I think
[03:43] <wallyworld> and the HasTools thing hacked around that
[03:52] <axw> wallyworld: sorry I got confused, thinking tools would be in the same location as the host, like in local
[03:52] <wallyworld> ah right
[03:52] <axw> just the one bug
[03:53] <axw> wallyworld: so... rather than reinstating HasTools, I'd prefer to just set Constraints.Arch to the host's if it's not already set. IIRC there was a bug caused by HasTools, where you couldn't create, say, i386 containers on amd64 hosts
[03:53] <axw> which is why it was removed in the first place
[03:54] <wallyworld> that solution of setting Arch was what occurred to me also - but only for containers
[03:55] <axw> wallyworld: actually... I think the LXC provisioner should just filter by the host arch. that's what we'd do for any other provider right?
[03:55] <axw> give it all it we know about, and let it make the informed decision
[03:55] <wallyworld> that would work, yeah
[03:56] <wallyworld> i think setting the arch seemed ok because it would constraint the search
[03:56] <wallyworld> but it's cleaner for sure to ket the provisioner decide
[04:19] <axw> wallyworld: http://reviews.vapour.ws/r/965/
[04:19] <wallyworld> looking
[04:19] <wallyworld> axw: I've updated the apt review from before also
[04:20] <axw> wallyworld: already LGTMd
[04:20] <wallyworld> ah ty :-)
[04:21] <wallyworld> axw: there's also a names one https://github.com/juju/names/pull/41 and one eric looked at but which i'd like your review of pretyy please
[04:21] <axw> will do
[04:31] <wallyworld> axw: done with a suggestio
[04:31] <wallyworld> n
[04:31] <axw> ta
[04:43] <wallyworld> axw: the filesystem tag uses the datasource name as the tag id (seemed reasonable at the time). the broad definition was to accommodate the behaviour where the datasource name is used as the dir name if no location is specified. I did think about using a numeric sequence value but then there's the issue of how to generate the numbers. i'd have to use a mongo sequence or something, or just count the number of filesystem docs
[04:43] <wallyworld> i can change to number though
[04:44] <axw> wallyworld: datasource name?
[04:44] <axw> as in ... the pool name?
[04:44] <wallyworld> in the charm metadata
[04:45] <wallyworld> storage name
[04:45] <axw> wallyworld: I'm a little wary of that. volumes can be disassociated from a storage instance, it may end up being a requirement for filesystems too
[04:46] <wallyworld> yeah, fair enough. i can make it like volume will be once your current branch lands (I didn't see it when I did this so didn;t appreciate the machine name aspect)
[04:46] <wallyworld> i do prefer opaque identifiers
[05:54] <anastasiamac_> wallyworld:
[05:54] <wallyworld> yo
[05:57] <anastasiamac_> wallyworld: looks like u've quit on PM
[05:57] <wallyworld> sigh, stupid irc
[05:57] <wallyworld> i'm here
[05:58] <wallyworld> got to go get kid from train station in a few minutes
[07:47] <wallyworld> axw: i've updated the juju/names branch to make fs tag more like volume tag
[07:48] <axw> wallyworld: thanks, will take a look
[07:56] <axw> wallyworld: LGTM
[07:57] <wallyworld> axw: ty. btw, what did you think about eric's comment re: Path vs Location?
[07:58] <axw> wallyworld: Path sounds fine for FilesystemAttachment. It really only needs to be Location on the StorageAttachment, which normalises volume/filesystem
[07:58] <wallyworld> sounds good to me
[07:59] <wallyworld> i sometime use location in conversation but path is better
[08:29] <TheMue> morning
[08:29] <dimitern> o/
[09:09] <dooferlad> morning
[09:13] <TheMue> dooferlad: o/
[09:14] <dimitern> TheMue, dooferlad, o/
[09:14]  * dimitern bbiab
[10:01] <dimitern> TheMue, dooferlad omw - ~3m
[10:57] <mattyw> fwereade, do you have 10 minutes?
[11:14] <dimitern> TheMue, reviewed
[11:14] <TheMue> dimitern: thx
[11:15] <TheMue> dimitern: and regarding the reviewer please take a look at the calendar. today michael and william are (ok, michael isn't available)
[11:16] <TheMue> dimitern: I for example have been last Friday and will be next Friday again
[11:16] <dimitern> TheMue, ah! yeah - I was thinking about last friday
[11:16] <dimitern> :)
[11:16] <dimitern> TheMue, but james is today
[11:16] <TheMue> dimitern: yep, our new ocr
[11:17] <TheMue> dimitern: btw, you've got a review too ;)
[11:17] <dimitern> TheMue, thanks you your review
[11:17] <TheMue> dimitern: h5
[11:17]  * dimitern h5s :)
[11:19] <TheMue> dimitern: thanks for the name retry pattern hint, this is exactly what I've looked for
[11:20] <dimitern> TheMue, yw, I had to look for it too, so decided to save you the trouble heh
[11:20] <TheMue> dimitern: great :)
[11:21] <dimitern> dooferlad, OCR PTAL: http://reviews.vapour.ws/r/961/
[11:21] <dimitern> (as you might see sometimes)
[11:22] <dooferlad> dimitern: looking
[11:22] <dimitern> dooferlad, ta!
[11:41] <dimitern> mgz, hey, are you around?
[12:59] <dimitern> dooferlad, hey, thanks for the review - I've responded. Is this the only question you have, everything else is clear? :)
[13:02] <dooferlad> dimitern: yep, everything else is fine.
[13:02] <dimitern> dooferlad, awesome!
[13:03] <dimitern> dooferlad, the state code is one of the gnarliest places btw - beware
[13:04] <dooferlad> dimitern: Heh, it did look a bit... interesting.
[13:04] <dooferlad> dimitern: not too scary though!
[13:04]  * dooferlad goes for lunch
[13:06] <dimitern> dooferlad, ;)
[13:30] <perrito666> natefinch: around?
[13:38] <jw4> sinzui: can I JFDI a backout merge?
[13:39] <jw4> it's actually one of the suspects in blocking bug 1423782 (but I don't think it's the culprit in that case)
[13:39] <mup> Bug #1423782: ppc64el /usr/bin/ld: error in $WORK/github.com/juju/juju/cmd/juju/_obj/exe/a.out <ci> <gccgo> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1423782>
[13:56] <sinzui> jw4 fixes-1423782 is what the lander is looking for. Use __JFDI__ when it is clear something has to merge to unblok other proitities
[13:56] <jw4> sinzui: okay; I don't think this backout does fix that though
[13:57] <jw4> sinzui: I just noticed it was referenced in the bug
[13:58] <jw4> sinzui: I think in this case it is blocking other priorities... i.e. removing a wrong implementation to make way for the right one?
[13:58] <sinzui> jw4, agreed, __JFDI__
[13:58] <jw4> sinzui: ta
[14:40] <stokachu> does anyone know what this error means: WARNING juju.replicaset replicaset.go:87 Initiate: fetching replication status failed: cannot get replica set status: can\'t get local.system.replset config from self or any seed (EMPTYCONFIG)
[14:40] <aisrael> I seem to be running into a new (to me) issue in trunk. I have a service in an error state, but `juju resolved` doesn't see it being in an error state.
[14:40] <aisrael> http://pastebin.ubuntu.com/10325205/
[14:41] <perrito666> stokachu: your mong rs.config() is empty, there was most likely an error while creating the base replicaset
[14:41] <stokachu> perrito666: so this happens randomly, whereas if i re-run the bootstrap it works the second time around
[14:43] <stokachu> just prior to that error the logs shows several mongo connection failures due to connection refused but then the connection succeeds and thats when the above error is shown
[14:43] <stokachu> this only happens when I bootstrap a bare metal from maas
[14:44] <perrito666> stokachu: sounds to me that I already heard this story, I believe there is even a bug about it, if not perhaps there should be
[15:02] <marcoceppi> is there any way to tell if trunk is blocked?
[15:04] <jw4> marcoceppi: I use https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All
[15:05]  * marcoceppi registers isjujucoreblocked.com
[15:05] <jw4> marcoceppi: if you do that then use the official blocker check script... I'll find that for you after my stand up
[15:05] <marcoceppi> jw4: I found it in juju-ci-tools
[15:05] <marcoceppi> http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/check_blockers.py
[15:06] <jw4> yep
[15:06] <marcoceppi> sweet
[15:23] <ericsnow> marcoceppi: I just go here: https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL
[15:24] <dimitern> sinzui, I think we should try reverting https://github.com/juju/juju/commit/0621a1ad40ba15004ef6c3c5e4da22661243041f - since ppc64el tests started failing after it, and the other suspect commit jw4 already reverted
[15:25] <sinzui> dimitern, I am just reviewing 1.22 results to verify the linker issue isn't present in 1.22
[15:26] <dimitern> sinzui, sure
[15:26] <dimitern> sinzui, I spend the last hour looking at various bugs for gccgo-ppc64 - in the gcc bug tracker, in lp, etc. as it does seem like a compiler issue
[15:26] <sinzui> dimitern, no gcc/linker errors in 1.22, so I am sure the machine is good. Revert
[15:27] <dimitern> sinzui, cool, I'll propose it then
[15:38] <dimitern> sinzui, reverted and it's already getting tested - http://juju-ci.vapour.ws:8080/job/github-merge-juju/2210/console
[15:38] <dimitern> sinzui, provided it lands ok, can you trigger the ppc64 job manually to see if it worked and save time?
[15:41] <sinzui> dimitern, I cannot trigger manually.
[15:42] <sinzui> dimitern, I think wallyworld's fix for ppc lxc has bad tests: http://juju-ci.vapour.ws:8080/job/run-unit-tests-trusty-ppc64el/2398/consoleText
[15:43] <sinzui> ^ mgz, do you agree? I think we have another regression in 1.22, but one that is just a test
[15:43] <dimitern> sinzui, looking
[15:47] <mgz> sinzui: yup, failed across 3+ runs
[15:47] <mgz> looks like it'll be trivial to fix though
[15:49] <mgz> yeah, the startInstance helper on that test class just hardcodes some pretend tools and quantal-amd64
[15:49] <mgz> *as
[15:50] <dimitern> mgz, sinzui, actually the tests are bad, because with axw's patch all tests now take the current machine's arch
[15:51] <dimitern> i.e. tests need better isolation
[15:51] <sinzui> mgz, dimitern natefinch : I just reported bug 1423950 about the ppc64 test failures just added to 1.22
[15:51] <mup> Bug #1423950: lxc-broker_test tests fail on ppc64el <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1423950>
[15:51] <mgz> worker/provisioner/lxc-broker_test.go l96
[15:51] <mgz> either that also needs to take current arch or the test needs to mock/isolate the tool selection
[15:52] <dimitern> mgz, the latter is better I think
[15:56] <dimitern> sinzui, I commented on that bug, however I don't think 1.23 is affected as there's not such patch there
[15:58] <sinzui> dimitern, good point. But note that 1.23 wasn't affected by the precise bug until someone ported it there. We need to stop the ppc fix from being ported without this fix also being present
[15:58] <dimitern> sinzui, I agree and will add another comment for this
[15:59] <sinzui> dimitern, I removed 1.23
[15:59] <sinzui> dimitern, I don't see a pr/review of a port of the ppc fix, so I wont worry
[16:04] <dimitern> sinzui, cheers - I've commented on both bugs - 1420049 and 1423950
[16:11] <sinzui> dimitern, mgz: I think I want to cry: the joyent trusty deploy is failing. the units cannot contact the state server to download the agent
[16:11] <sinzui> + printf Attempt 5 to download tools from %s...\n https://<IP_ADDRESS>:17070/tools/1.22-beta4-trusty-amd64
[16:11] <sinzui> I can only think to try the test again to get a friendly network
[16:12] <mgz> urk
[16:14] <dimitern> sinzui, aw, that's the "i'll give you a machine on a random network" type of joyent issue
[16:15] <sinzui> dimitern, exactly. we broadened the network we will accept, but joyent went broader
[16:16] <sinzui> dimitern, I can see in recent days, 1 in 4 attempts pass (but different branches). I will try again for a 4th attempt in the sequence
[16:17] <dimitern> sinzui, that's not a real solution, but if it makes the job pass more often, yeah
[16:18] <dimitern> unfortunately the "real" solution is not something joyent seems to support via their api
[16:18] <sinzui> dimitern, this isn't a juju regression, and I want to show there isn't one looking at the repeatability
[16:19] <dimitern> sinzui, I agree
[16:20] <sinzui> dimitern, joyent deploy precise passed the first time (with the new fix), quickstart passed for the last two revisions, and that test is pretty unreliable, and the upgrade trusty also passed. so I am sure juju is good
[16:20] <dimitern> sinzui, the revert of #1615 landed - can you give me an eta when the ppc64 tests job will run?
[16:21] <dimitern> sinzui, that's good news indeed
[16:21] <sinzui> dimitern, with the hour. we are waiting for 1.22 to conclude
[16:21] <dimitern> sinzui, ok, thanks
[16:23] <sinzui> dimitern, and we get a pass for the statistically consistent 1 in 4 will get a good network
[16:24] <sinzui> dimitern, natefinch : can you ask someone to fix the broken tests for bug 1423950?
[16:24] <mup> Bug #1423950: lxc-broker_test tests fail on ppc64el <ci> <ppc64el> <regression> <test-failure> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1423950>
[16:32] <dimitern> sinzui, sure
[16:47] <marcoceppi> jw4 ericsnow: http://juju.fail/status.json ;)
[16:53] <wwitzel3> hah I was right
[16:53] <dimitern> sinzui, it seems the ppc64-slave is free - how does it decide to try a new master commit?
[16:54] <aisrael> I'm running into an issue w/trunk. I have a service in an error state, but `juju resolved` reports it isn't in an error state. Seems like this change happened within the past week.
[16:54] <sinzui> dimitern, when all tests for a revision have run, a new revision will be tested. we are waiting on maas
[16:54] <aisrael> http://pastebin.ubuntu.com/10325205/
[16:54] <dimitern> sinzui, I see, ok
[16:56]  * dimitern steps out for a bit
[17:35] <natefinch> dimitern, sinzui:  Sorry, was out this morning.  I can take a look at that bug, if you want?
[17:36] <sinzui> natefinch, thank you
[17:42] <perrito666> is there a way to run the whole test suite supressing logs? I just want to know which packages fail
[17:53] <dooferlad> sinzui: https://github.com/juju/juju/pull/1645 should fix Bug #1423950 but needs a review
[17:53] <mup> Bug #1423950: lxc-broker_test tests fail on ppc64el <ci> <ppc64el> <regression> <test-failure> <juju-core 1.22:In Progress by dooferlad> <https://launchpad.net/bugs/1423950>
[17:53] <dooferlad> TheMue: Could you take a look? ^^
[17:54] <sinzui> natefinch, ^
[17:54] <TheMue> dooferlad: yep, will do
[17:59] <TheMue> dooferlad: looks simple and ok, sadly don't know how to test it better than let it do by CI
[17:59] <dooferlad> TheMue: indeed.
[17:59] <TheMue> dooferlad: so I'll give it a ship-it
[17:59] <dooferlad> TheMue: shipped!
[18:00] <TheMue> dooferlad: :)
[18:03] <dimitern> perrito666, there is
[18:05] <dimitern> perrito666, I found out yesterday - export TEST_LOGGING_CONFIG=CRITICAL or something then run them; however some of them fail when the <root> logger is not at least at DEBUG
[18:05] <perrito666> dimitern: tx
[18:05] <dimitern> dooferlad, re that fix
[18:05] <dooferlad> dimitern: yep
[18:05] <dimitern> dooferlad, I think you should restore this change at some point - i.e. in the suite's TearDownTest
[18:06] <dooferlad> can do
[18:06] <dimitern> dooferlad, back to what version.Current.Arch was; otherwise other tests can fail
[18:07] <dimitern> dooferlad, have you run make check?
[18:07] <dooferlad> dimitern: yes
[18:08] <dimitern> dooferlad, well if it passes, that's good news - nothing apparently broken, but I still think it should be restored - maybe in a follow-up?
[18:10] <dimitern> dooferlad, also, instead of "amd64" I'd use the arch.AMD64 const
[18:10] <dooferlad> dimitern: just testing restoring it in func (s *lxcProvisionerSuite) TearDownTest(c *gc.C)
[18:10] <dooferlad> dimitern: OK, will change that.
[18:10] <dimitern> dooferlad,despite that, great job for doing it so quickly! :)
[18:10] <dimitern> dooferlad, cheers
[18:14] <natefinch> dooferlad: agreed, great job
[18:14] <dooferlad> dimitern, natefinch: thanks!
[18:15] <dooferlad> dimitern: can the followup wait until Monday. It felt urgent to get a fix in, but I would like to finish promptly today.
[18:15] <dooferlad> dimitern: (insert ? where needed in above)
[18:15] <dimitern> sinzui, most jobs have disappeared from jenkins, which I presume is due to not being publicly visible; anyway any update on the ppc64 job?
[18:16] <sinzui> dimitern, I sure can
[18:16] <dimitern> dooferlad, it can wait, but please add a card and comment on the bug about it
[18:17] <dooferlad> dimitern: cool. It isn't writing the code, it is waiting for the tests to run :-) I will leave it going and see if I can get checked in later.
[18:18] <dimitern> dooferlad, you can then integrate axw's fix and yours + the follow up to port that fix to trunk
[18:18] <dimitern> dooferlad, sure, np
[18:18] <sinzui> dimitern, I is visible now
[18:20] <dimitern> sinzui, I can see it - thanks
[18:23] <sinzui> dimitern, We are using 10.0.40.x addresses in network we test mass kvm with.
[18:23] <sinzui> dimitern, do we need to change that to avoid the lxcbr0 issue?
[18:24] <dimitern> sinzui, the one I fixed recently?
[18:24] <dimitern> (too many lxcbr0 issues in the past 2 months :/)
[18:25] <sinzui> dimitern, yes, we aren;t using lxcbr0, but we are using that address range on an eth1
[18:25] <sinzui> we can change the range
[18:25] <dimitern> sinzui, the issue was that 10.0.3.* sorts before any 10.0.X.* where X > 3
[18:26] <dimitern> sinzui, so if you're hitting that issue I'd suggest changing the range to 10.0.2.*
[18:27] <dimitern> sinzui, what juju version is the ci environment using?
[18:27] <marcoceppi> alexisb: aisrael and I are seeing a weird issue in trunk. We'd like to debug to see if it's a bug or not, anyone we can chat with?
[18:27] <sinzui> dimitern, thank you. I think this means our address sis okay
[18:28] <sinzui> juju.api api.go:273 connecting to API addresses: [<IP_ADDRESS>:17070]
[18:29] <dimitern> sinzui,ah, now I got it - your lxcbr0 address is from 10.0.40.x ? yep, then it's fine
[18:29] <alexisb> marcoceppi, any of the use based developers
[18:29] <marcoceppi> natefinch: halp
[18:29] <alexisb> natefinch, wwitzel3, cherylj, katco, ericsnow_afk
[18:29] <natefinch> marcoceppi: heh
[18:30] <marcoceppi> aisrael: ^
[18:30] <natefinch> whazzup?
[18:48] <marcoceppi> natefinch: "I seem to be running into a new (to me) issue in trunk. I have a service in an error state, but `juju resolved` doesn't see it being in an error state. http://pastebin.ubuntu.com/10325205/"
[18:55] <natefinch> marcoceppi: wacky
[18:56] <marcoceppi> natefinch: yeah, aisrael is experiencing it atm
[18:56] <marcoceppi> with trunk from this am
[18:57] <natefinch> marcoceppi: I'll do some poking around and see if I can repro
[18:57] <marcoceppi> natefinch: ta
[19:16] <dimitern> I'd appreciate a review on http://reviews.vapour.ws/r/973/
[19:18] <TheMue> dimitern: already started ;)
[19:20] <dimitern> TheMue, cheers!
[19:21] <dimitern> TheMue, it's a long diff, but it should be easy to follow
[19:21] <TheMue> dimitern: so far yes, otherwise I'll ping you here
[19:24] <dimitern> ta!
[19:38] <jw4> marcoceppi: cool!
[19:43] <mbruzek> ping jog
[19:43] <jog> hi mbruzek
[19:43] <mbruzek> I can't get to http://reports.vapour.ws/charm-summary/kubernetes
[19:44] <mbruzek> Is it just me or is that page down?
[19:44] <jog> mbruzek, please use http://reports.vapour.ws/charm-tests-by-charm/kubernetes
[19:44] <jog> mbruzek, I update the site this morning
[19:45] <jog> mbruzek, the change was to merge the old charm reporting page with that we've recently been working on.
[19:45] <mbruzek> OK
[19:57] <TheMue> dimitern: you've got a review. really like this PR
[19:58] <dimitern> TheMue, thank you! It *did* a week to get this good :)
[19:58] <TheMue> dimitern: was worth it
[19:58] <dimitern> TheMue, indeed!
[19:59] <TheMue> dimitern: I'll now give my PR another merge kick and then enjoy my Glenrothes Single Malt :D
[19:59] <dimitern> TheMue, trunk is still blocked though
[19:59] <dimitern> TheMue, otherwise, enjoy! :)
[19:59] <TheMue> dimitern: oh, ok, then I'll do it tomorrow and now only enjoy *hicks*
[20:00]  * TheMue wishes the channel a nice weekend
[20:05] <whit> mbruzek, https://raw.githubusercontent.com/whitmo/bundle-kubernetes/master/specs/cs-latest-release-v0.9.3.yaml
[20:05] <mbruzek> jog I think pointing to the actual file in s3 would be better.
[20:06] <whit> jog, ie grabbing the file when the tests run and sticking it in s3 to refer to later
[20:06] <whit> tvansteenburgh mentioned doing this before
[20:07] <whit> jog, when the bundle is in source control, there is no guarantee that the file you link to is actually the file from the test run
[20:08] <jog> whit, agreed I'll like to what we archive in S3
[20:10] <tvansteenburgh> jog, whit: i'm not uploading the bundle file to s3 yet but i'll try to get that done this afternoon
[20:15] <whit> tvansteenburgh, thanks!
[20:35] <natefinch> perrito666: you have a shipit
[20:36] <perrito666> natefinch: you have $drink on my tab
[20:36]  * perrito666 cries
[20:39] <jog> mbruzek, whit, arosales, removing kubernetes test data older than Feb. 18, is A-OK with everyone?
[20:39] <whit> jog +1
[20:39] <mbruzek> jog that is my understanding yes
[20:44] <arosales> jog, yes please do
[20:45] <arosales> aisrael, did you get the help you were looking for on your development
[20:45] <aisrael> arosales: natefinch was going to see if he could reproduce it; I rolled back to binaries from the end of Jan to get unblocked in the meantime
[20:48] <arosales> natefinch, thanks for the help there, getting that moving forward will help us in our charm action development
[20:52] <arosales> aisrael, if we don't have a resolution today lets open a bug so we can bring other folks in if necessary
[20:52] <aisrael> arosales: ack
[20:52] <arosales> aisrael, thanks
[21:23] <natefinch> arosales, marcoceppi, aisrael: the good news is that I can reproduce it, so now it's just a matter of figuring out what's wrong, which I imagine will be pretty obvious.  Probably won't be able to entirely track it down before EOD, but most likely by early Monday.... either way, filing a bug would be appreciated
[21:24] <marcoceppi> natefinch: thanks, are we excercising that mechanism in testing?
[21:24] <jw4> natefinch, is this the error state bug that marcoceppi pastebinned earlier?
[21:24] <natefinch> jw4: yes
[21:25] <jw4> are you able to reproduce with the latest in master?
[21:25] <aisrael> natefinch: ack, I'll file a bug report shortly
[21:25] <natefinch> marcoceppi: probably?  I'll have to look at the tests.  But obviously there's a codepath that is not being tested.
[21:25] <jw4> (I'm just afraid that it might incidentally touch a PR that I just reverted this morining)
[21:25] <natefinch> jw4: tested it with latest master as of half hour ago-ish
[21:25] <jw4> natefinch: whew (for me)
[21:25] <arosales> natefinch, thanks
[21:37] <aisrael> https://bugs.launchpad.net/juju-core/+bug/1424069
[21:37] <mup> Bug #1424069: juju resolve doesn't recognize error state <juju-core:New> <https://launchpad.net/bugs/1424069>
[21:41] <alexisb> perrito666, ping
[21:41] <alexisb> if you are still around :)
[21:41] <perrito666> alexisb: barely
[21:41] <perrito666> tell me
[21:42]  * perrito666 braces
[21:42] <alexisb> perrito666, yeah I always come in with fun requests
[21:43] <alexisb> perrito666, I need a volunteer to work with eco team on a windows workload demo
[21:43] <alexisb> eco will be leading but we need a core dude to help if questions come up
[21:43] <perrito666> I am interested
[21:43] <perrito666> how urgent is this
[21:43] <mbruzek> alexisb: windows?  What is that
[21:44] <alexisb> well we have one week to get a working demo
[21:44] <alexisb> but I want to get all the techie names lined up today so I can get the effort organized
[21:45] <alexisb> mbruzek, it is for david duffey, just coming down the pipeline
[21:45] <alexisb> perrito666, no need for work until monday, but I do want to get everyone identified that will be enlisted to help
[21:46] <alexisb> and from the core front it should be mostly helping with questions and orchestrating getting gsamfira and team involved if needed
[21:46] <alexisb> perrito666, you have been working closely with cloudbase so you are my first ask :)
[21:47] <perrito666> alexisb: sure, whatever I dont know I will most likely know who to ask
[21:47] <alexisb> perrito666, cool
[21:47]  * alexisb goes to send email and get the ball rolling
[21:48] <perrito666> Ill try to run the whole tutorial they sent to get a working workload at home for reference
[21:49] <perrito666> well after not dodging that bullet I am EOW, see you all on monday
[21:49] <perrito666> :p
[21:50] <jw4> perrito666: o/
[22:00] <alexisb> by perrito666 and thanks!


[02:17] <RAOF> Sarvatt: Have you done any mesa-demos packaging?
[02:18] <RAOF> Sarvatt: I get the feeling that asac will be wanting some stuff from there, and I think we can happily ship it without necessarily needing mesa 7.9 first.
[02:19] <Sarvatt> no i havent, was shopping around for other packages to rip the packaging off of :) need to go through and figure out what other demos to package from it and write up man pages
[02:20] <RAOF> Well, I think I'll start packaging it up and push something to pkg-xorg git.
[02:20] <RAOF> Feel free to wander through the manpage maze :)
[02:23] <Sarvatt> any idea what demos they even want?
[02:24] <RAOF> I think something testing EGL & GL|ES.
[02:24] <RAOF> So glesgears would proabably be one :)
[07:33] <eagles0513875> hey guys i am still having random nvidia driver issues the ones in lucid wouldnt allow my monitor to resume after an unspecified period of time. i upgraded to the version of the nvidia driver you have in ur ppa and its solved the problem, but now i have had my first crash and reboot into gdm instead of kdm
[07:33] <eagles0513875> any ideas as to what i should do
[09:17] <asac> RAOF: guess you are gone?
[09:18] <|eagles0513875|> asac:
[09:18] <|eagles0513875|> are you an x or video related expert by any chance
[09:18] <asac> eagles0513875: unlikely ;)
[09:18] <asac> on arm i am moving in that direction. on x86, not so much ;)
[09:18] <|eagles0513875|> ahhh ok :(
[09:19] <|eagles0513875|> cuz im having nasty video issues with the nvidia driver causing my system to hang then after rebooting to find out that the driver has crashed and the default kdm cant be loaded
[09:19] <|eagles0513875|> but gdm until i reboot again and it boots back into kdm
[09:31] <RAOF> asac: I can be pung.
[09:32] <RAOF> asac: I'll be a-makin' dinner, but you can tell me what you mean by  those demos and I'll remember.  Like a fox.
[09:32] <asac> RAOF: lol
[09:33] <asac> RAOF: read the clutter/mutter: section notes here: https://wiki.linaro.org/Platform/UserPlatforms/2010-08-10 ... maybe that gives you background
[09:33] <asac> ping me after dinner ... have to hop on a sequence of calls now for a bit ;)
[11:16] <RAOF> asac: Yo!
[11:36] <|eagles0513875|> yofel:
[11:36] <|eagles0513875|> how are you
[11:37] <yofel> good so far ;)
[11:40] <|eagles0513875|> i need some help i am having random video card driver crashes actually just one so far with the driver from teh x ppa
[11:40] <|eagles0513875|> the exact issue is this
[11:40] <|eagles0513875|> when the video driver crashes it brings up the dialogue box about low graphics mode
[11:40] <|eagles0513875|> i restart x and i on the gdm login
[11:40] <|eagles0513875|> restart the machine and im back on kdm
[11:40] <|eagles0513875|> also
[11:41] <|eagles0513875|> i have issues with plasma crashing as well i start seeing icons disappearing etc
[11:41] <|eagles0513875|> im on kde 4.4.5
[11:41] <|eagles0513875|> dunno what else could be the problem
[11:41] <asac> RAOF: hey
[11:42] <|eagles0513875|> any ideas yofel
[11:42] <asac> RAOF: so ;) ... did the link above make any sense to you?
[11:42] <RAOF> asac: So, you're interested in the egl texture_from_pixmap demo?
[11:43] <asac> RAOF: right. i am interested in a) getting the KHR extension used there backported to our mesa ... and b) getting the demo work
[11:43] <yofel> |eagles0513875|: actually I think I know what you're talking about
[11:43] <yofel> if you have the same issue I have choosing 'drop to terminal' should give you a working kdm
[11:43] <asac> RAOF: i basically only need the extension in mesa ... someone else can make the demo work (and port to gles2 i guess)
[11:43] <|eagles0513875|> yofel: i have gnome installed so i just restart x and it gets me to the gdm login
[11:44] <|eagles0513875|> rebooting gets me back to the kdm login prompt
[11:44] <asac> RAOF: wonder how hard it would be to backport that extension
[11:44] <RAOF> Hm.
[11:44] <|eagles0513875|> in regards to my plasma desktop issue i kill the p-d process and restart it from commandline and it fixes the problem
[11:44] <|eagles0513875|> yofel: do you think i should upgrade xorg tahts in the ppa
[11:44] <RAOF> I don't have a good idea how hard it would be.
[11:44] <yofel> |eagles0513875|: yes, if I restart X I get gdm, if I drop to a terminal I get kdm
[11:45] <|eagles0513875|> O_o must try that when it happens again
[11:45] <RAOF> On the other hand, that's available in (what will be) 7.9, yes?
[11:45] <asac> good question
[11:45] <|eagles0513875|> yofel: what video card do you have cuz it only happened to me once so far with the nvidia-current from the ubuntu-x ppa
[11:45] <asac> will we get 7.9?
[11:45] <asac> RAOF: ?
[11:45] <|eagles0513875|> its helped alot
[11:46] <asac> RAOF<EMAIL_ADDRESS>[11:46] <RAOF> asac: It won't be available before feature freeze, but it might be worth an exception.
[11:46] <|eagles0513875|> yofel: what video card do you have
[11:46] <yofel> nVidia Corporation GT218 [NVS 3100M] (rev a2) with 256.44   works fine except for the occasional failsave x as you said
[11:46] <asac> RAOF: ok. and without 7.9 we are unlikely to be able to backport it?
[11:47] <|eagles0513875|> strange and your experiencing the same issues on a newer card
[11:47] <|eagles0513875|> im on an 8800gt
[11:47] <|eagles0513875|> the 256 driver fixed a bunch of issues i was having except for the radnom driver crash
[11:47] <|eagles0513875|> as well as plasma-desktop issue
[11:47] <yofel> I suspect kdm trying to load before the driver has loaded, but that's simply guessing
[11:47] <|eagles0513875|> yofel: any ideas regarding my plasma-desktop issue
[11:48] <asac> RAOF: is 7.9 daily already in a ppa or something?
[11:48] <RAOF> asac: xorg-edgers
[11:48] <RAOF> xorg-edgers is wonderful (thanks Sarvatt!)
[11:48] <asac> RAOF: would just copying mesa be good enough? or do we need other parts?
[11:49] <yofel> |eagles0513875|: what plasma-desktop issue?
[11:49] <RAOF> It looks like that series is self-contained, yeah.  So it would be just mesa.
[11:50] <|eagles0513875|> yofel: mind if i pm ya as its probably not related to the channel and i dont wanna take it offtopic
[11:58] <yofel> sure
[14:10] <tseliot> Sarvatt, RAOF: maybe I should upload the new nvidia driver and suggest users to use the ignoreabi option? (not that I'm fond of this solution...)
[14:15] <tjaalton> bumping the abi in depends would then give false hopes
[14:16] <tjaalton> aaronp asked keithp yesterday if the abi was final, so a proper driver might appear soon?
[14:16] <tseliot> tjaalton: oh, I thought the abi was final
[14:16] <tseliot> hmm...
[14:17]  * tseliot is so glad to be using radeon on his main pc
[14:18] <tjaalton> it is
[14:18] <tjaalton> but bumping it in the nvidia package would say that it supported the abi
[14:18] <tjaalton> which is wrong
[14:20] <tseliot> yes, but, in theory (I have my reasons to believe so), 256.44 should already be ABI compatible
[14:21] <tjaalton> no it isn't if it doesn't work without ignoreABI
[14:21] <tseliot> yes, I'm waiting for Nvidia to get back to me to see what's going on
[15:13] <shadeslayer_> hi after the latest round of X updates, my X doesnt start with nvidia drivers
[15:13] <shadeslayer_> log at : http://paste.ubuntu.com/476453
[15:14] <shadeslayer_> also, i have maverick
[15:29] <Sarvatt> tjaalton, tseliot well the alternative is having X removed on upgrades breaking nouveau too for those people unless they know to remove nvidia-common before trying to upgrade, uploading it even though it only works with IgnoreABI seems like a better idea to me..
[15:29] <Sarvatt> and yes a large amount of people are actually letting it remove X :(
[15:29] <shadeslayer_> oh oh .. how do i enable this IgnoreABI ?
[15:29] <tseliot> shadeslayer_: in the serverflags section in xorg.conf
[15:30] <tseliot> Sarvatt: yes, that was my main concern
[15:30] <Sarvatt> shadeslayer_: you need to add the ubuntu-x-swat/x-updates PPA and update to 256.44 first for that to work until it's in the archives, 256.35 thats in maverick doesn't work
[15:31] <shadeslayer_> ah ok.. lemme remove my xorg then, and boot with nouveau
[15:31] <shadeslayer_> brb
[15:31] <Sarvatt> huh??
[15:31] <Sarvatt> shadeslayer_: just add the PPA and do a apt-get dist-upgrade
[15:32] <shadeslayer_> uh ok.. can you give me the ppa address? i have no X :P
[15:32] <tseliot> links FTW :-)
[15:32] <Sarvatt> deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu maverick main
[15:33] <shadeslayer_> ok
[15:33] <shadeslayer_> Sarvatt: no apt-add-repository link?
[15:33] <Sarvatt> ppa://ubuntu-x-swat/x-updates ?
[15:33] <shadeslayer_> yes
[15:33] <Sarvatt> err ppa:ubuntu-x-swat/x-updates
[15:35] <Sarvatt> guess I lost that patch to jockey I wrote up last time this happened that added IgnoreABI to xorg.conf for nvidia, bah
[15:37] <Sarvatt> oh maybe because i'm looking for a jockey patch and it was another package, hmm
[15:38] <Sarvatt> nope it was jockey, data/handlers/nvidia.py
[15:38] <tseliot> Sarvatt: no, it should be in Jockey (in the nvidia handler). I can do that but I'll have to discuss this with pitti tomorrow
[15:40] <Sarvatt> oh was it just this?
[15:40] <Sarvatt>         if self.version == 'current':
[15:40] <Sarvatt>             self.xorg_conf.addOption('ServerFlags', 'IgnoreABI', 'True', optiontype='Option', position=0)
[15:41] <Sarvatt> around line 80
[15:42] <eagles0513875> tseliot: i had another nvidia crash again like i was priro to trying the nvidia driver in the ppa
[15:43] <tseliot> Sarvatt: yes, I think that would do it
[15:43] <tseliot> eagles0513875: the plasma crash again?
[15:43] <eagles0513875> #no
[15:44] <eagles0513875> the other thing where nvidia driver crashes it complains about low graphics mode
[15:44] <eagles0513875> i restart x
[15:44] <eagles0513875> #and i get gdm
[15:44] <eagles0513875> when i reboot i get back to kdm but thats besides the point
[15:44] <eagles0513875> in regards to that im not sure what else to try
[15:44] <eagles0513875> yofel: is kinda having the same issue in that respect as well cuz i was discussing it with him this morning tseliot
[15:45] <tseliot> eagles0513875: I guess it depends on 1) how you restart X 2) whatever DM you set as a default
[15:45] <eagles0513875> for me kdm is default
[15:45] <tseliot> a driver can't change your dm
[15:46] <eagles0513875> thing is then when the low graphics prompt pops up and it gives you a list of options yofel drops down to console it loads kdm
[15:46] <eagles0513875> tseliot: where should i redirect this issue then?
[15:46] <tseliot> ok, how do you restart X?
[15:47] <tseliot> I'm not really sure about the status of failsafe X and kdm
[15:47] <tseliot> therefore you should file a bug report against kdm
[15:47] <eagles0513875> tseliot: when this happens it complains about low graphics then gives me a list of options and restart x is one of them
[15:47] <tseliot> well, either you or yofel
[15:48] <tseliot> aah
[15:48] <shadeslayer_> uh.. apachelogger was working on this i think
[15:48] <tseliot> yes, failsafe X is gnome-centric
[15:48] <shadeslayer_> tseliot: more like gdm-centric
[15:48] <eagles0513875> tseliot: what doesnt make sense is when dropping into a root console it loads kdm
[15:48] <eagles0513875> hi shadeslayer_
[15:48] <tseliot> so I guess that it simply restarts gdm
[15:48] <shadeslayer_> eagles0513875: hey :D
[15:49] <tseliot> eagles0513875: that's a bug in kdm
[15:49] <eagles0513875> thats not whats bothering me
[15:49] <eagles0513875> whats bothering me is the driver crashing
[15:49] <eagles0513875> what has changed since the driver version in karmic, i never had this issue of random crashes on karmic
[15:51] <tseliot> eagles0513875: have you filed a bug report about it?
[15:51] <tseliot> if not, please do
[15:51] <tseliot> and I'll make sure that Nvidia have a look at it
[15:51] <eagles0513875> i will if it crashes again cuz the driver in the ppa has been quite stable
[15:51] <eagles0513875> this so far happened only once compared to the one in the lucid repos
[15:52] <tseliot> ok
[15:57] <shadeslayer_> um sorry for asking again but what do i need to insert into xorg.conf? you see i lost the logs :(
[16:00] <tseliot> shadeslayer_: I'll give you an example on pastebin
[16:00] <shadeslayer_> tseliot: i dont have X :P
[16:01] <shadeslayer_> i cant navigate to the pastebin
[16:01] <tseliot> Section "ServerFlags"
[16:01] <tseliot> Option "IgnoreABI" "True"
[16:01] <tseliot> EndSection
[16:02] <tseliot> add these 3 lines in your xorg.conf
[16:02] <tseliot> shadeslayer_: ^
[16:02] <shadeslayer_> thanks tseliot
[16:02] <tseliot> np
[16:03] <yofel> eagles0513875 tseliot: actually there is bug 585930 (just found it) will see if delaying kdm start helps
[16:04] <ubot4> Launchpad bug 585930 in kdebase-workspace (Ubuntu) "kdm starts before nvidia driver is fully loaded (affects: 2) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/585930
[16:04] <shadeslayer_> tseliot: time to reboot and see :D
[16:04] <tseliot> ah good
[16:04] <eagles0513875> yofel: for me its only happened once to me with the 256 nvidia driver
[16:05] <eagles0513875> yofel: will have to work on that once im done performing surgery on my mac lol
[16:08] <shadeslayer> tseliot: whee... it works \o/
[16:08] <tseliot> :-)
[16:23] <tjaalton> Sarvatt: then that should be fixed
[16:24] <tjaalton> or the dependency dropped completely
[18:08] <Sarvatt> shoot, i wonder if we should add clickpad support to synaptics before feature freeze, the kernel side was added way back in lucid
[18:50] <LucidFox> Greetings! I've had a problem for a few days now - not sure what package causes it, though.
[18:50] <LucidFox> After GNOME fully boots, the Nautilus desktop background is replaced by flat white
[18:50] <LucidFox> (on maverick)
[18:51] <LucidFox> I'd file a bug, but I don't even know what against
[18:56] <eagles0513875> LucidFox: ask in ubuntu+1 that is specific for maverick development questions
[18:56] <LucidFox> heh, and I was sent here from #ubuntu-desktop :)
[18:56]  * LucidFox goes