[00:02] <cmaloney> Evening
[00:02] <cmaloney> I think the Starbucks thing may need to be rethought
[00:02] <cmaloney> Managed to luck into a table here
[00:37] <greg-g> http://gondwanaland.com/mlog/2013/10/22/open-source-proliferation-problem/
[01:07] <trevlar> http://fitztrev.github.io/ubuntu-irc-logs/
[01:07] <waf> trevlar++
[01:29] <widox> waf: hola
[01:30] <waf> widox: test
[06:04] <greg-g> rick_h_: does your team use any specific dev methodology? You have in-person sprints, but do ya'll also do the 1-2 week sprint idea? Still use LP for managing those sprints?
[14:14] <rick_h_> greg-g: so I think it's just kanban + agile? We do have 1-2 week "features" we break into single branch-ish kanban cards we move across the board from study, coding, review, landing/qa, done
[14:14] <rick_h_> greg-g: but we don't really call them sprints
[14:34] <jrwren> scrumban!
[14:35] <brousch> jrwren: Is there a charity I can give to to help you get over that ailment?
[15:06] <jrwren> this does not work for me. is it supposed to in 12.04.2 ? http://techxana.blogspot.com/2012/09/ubuntu-12-dhclient-logging-options.html
[15:52] <greg-g> jrwren: is that an endorsement?
[15:54] <greg-g> "In the case of decentralized teams, stage-illustration software such as Assembla, ScrumWorks, Rational Team Concert or JIRA in combination with Jira Agile." oh no! my only floss option is JIRA?!
[15:54] <greg-g> from https://en.wikipedia.org/wiki/Scrum_%28software_development%29#Scrum-ban
[15:54] <cmaloney> Did someone wave the magic scrum wand?
[15:55] <cmaloney> Seems we're also "doing Scrum"
[15:55] <rick_h_> greg-g: yea, we don't use open source kanban/etc.
[15:55] <rick_h_> leankit.com
[15:56] <cmaloney> (and Jira is only this side of OSS)
[15:56] <greg-g> cmaloney: well, being a little more reactive to reality, for us. Also, our team needs something to help us stay on task.
[15:56] <greg-g> we're your typical fire-fighting team (the "Platform/Core" team) so we're the ones called in when shit breaks and people don't know how to fix it immediately
[15:57] <greg-g> but, we also have things we need to build, so, yeah
[15:58] <jrwren> agile with a capital A is bullshit.
[15:58] <jrwren> the only agile I care about are the 4 values defined in the agile manifesto.
[15:58] <jrwren> as for scrum or scrumban, yes, they are fine methodologies
[15:58] <jrwren> implementing them can be challenging
[16:00] <cmaloney> I think Agile got the same problems as some of the other methodologies, namely this idea of purity in implementation
[16:01] <cmaloney> That and XP
[16:01] <cmaloney> "Thou shalt have a 10 person team for a two person project"
[16:02] <cmaloney> "And thou shalt not call it 'Agile' unless thou has delinated these roles to ten separate people"
[16:22] <greg-g> jrwren: that's my perspective as well
[16:23] <greg-g> cmaloney: yeah, we ain't pure :)
[16:38] <jrwren> cmaloney: that is why...
[16:38] <jrwren> agile with a capital A is bullshit.
[19:34] <cmaloney> That moment you find someone on G+, think it would be interesting to follow them, and then get hit with a stream of political posts
[19:35] <greg-g> that moment when you think about doing something on G+, open it up, and run away screaming
[19:35] <cmaloney> Hey now. :)
[19:35] <greg-g> you feel icky when someone says scrum, I feel icky when someone says G+ ;)
[19:36] <cmaloney> I didn't say I felt icky about scrum
[19:36] <greg-g> hehe
[19:36] <cmaloney> just that i've heard it a lot lately
[19:36] <cmaloney> And nothing wrong with G+. It's actually a nice community
[19:36] <brousch> greg-g: Where do you converse with fellow nerds?
[19:36] <cmaloney> that said, i follow a shit-ton of gamers
[19:36] <greg-g> brousch: right here, on IRC
[19:37] <brousch> But there's no pictures!
[19:37] <cmaloney> Used to be identi.ca, but people fell off that wagon.
[19:37] <greg-g> ASCII ART!
[19:37] <greg-g> also, yeah, identi.ca, but too quiet
[19:37] <greg-g> apparently quittr.se (statusnet based) is pretty popular
[19:38] <greg-g> but, I think full of mega chatters, the likes of whats his name from that one outlaw podcast
[19:38] <cmaloney> fabsh
[19:38] <greg-g> yeah, him
[19:39] <cmaloney> We are a federation of microbloggers who care about ethics and solidarity and want to quit the centralised capitalistic services. We've been around since 2010 and will always be non-profit.
[19:39] <cmaloney> And... no.
[19:40] <cmaloney> (from http://quitter.se)
[19:40] <greg-g> what's wrong with being non-profit?
[19:40] <cmaloney> heh
[19:46] <jrwren> scrum is just a to short of scrotum
[19:47]  * _stink_ steals that
[23:02] <tony-smlr> SMLR is Live on Google Hangouts On Air  http://www.youtube.com/embed/f_mJKAzO42g and Audio Stream  http://live.smlr.us:8000/streaming  IRC Chat on Freenode Channel #smlr


[15:01] <flacoste> me
[15:02] <mars> (psst, flacoste, we haven't started yet)
[15:02] <mars> as evidenced by barry's absence
[15:06] <barry> sorry for the delay folks!
[15:06] <barry> #startmeeting
[15:06] <MootBot> Meeting started at 09:06. The chair is barry.
[15:06] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:06] <barry> welcome to today's ameu reviewer's meeting, who's here today?
[15:06] <allenap> me
[15:06] <mars> me
[15:06] <gary_poster> me
[15:06] <intellectronica> me
[15:06] <bac> me
[15:06] <flacoste> me
[15:06] <salgado> me
[15:07] <intellectronica> barry: abel apologises, he's in transit
[15:07] <barry> intellectronica: thanks
[15:07] <abentley> me
[15:07] <BjornT> me
[15:08] <barry> bigjools, cprov, EdwinGrubbs ping
[15:08]  * bigjools offers apologies as he is sprinting
[15:08] <bigjools> as is cprov
[15:08] <barry> gmb:, rockstar, salgado, sinzui ping
[15:08] <sinzui> oops
[15:08] <barry> bigjools, cprov no worries!  enjoy the sprint
[15:08] <salgado> barry, me'ed already. :)
[15:09] <bigjools> we're redesigning the world, it's very enjoyable
[15:09] <barry> salgado: oops, sorry ;}
[15:09] <EdwinGrubbs> me
[15:09] <barry> [TOPIC] agenda
[15:09] <MootBot> New Topic:  agenda
[15:09] <barry>  * Roll call
[15:09] <barry>  * encourage appropriate RENormalizer use in doctests (it is nicer than ellipses in many cases), gary
[15:09] <barry>  * Action items
[15:09] <barry>  * Mentoring update
[15:09] <barry>  * Peanut gallery (anything not on the agenda)
[15:09] <flacoste> i have a peanut gallery item
[15:10] <abentley> bigjools: remember to include beer waterfalls.
[15:10] <gmb> me (sprinting, so distracted)
[15:10] <bigjools> abentley: ++
[15:10] <barry> flacoste: cool, i'll make sure we get to it
[15:10] <barry> [TOPIC] * encourage appropriate RENormalizer use in doctests (it is nicer than ellipses in many cases), gary
[15:10] <MootBot> New Topic:  * encourage appropriate RENormalizer use in doctests (it is nicer than ellipses in many cases), gary
[15:10] <barry> gary_poster: the floor is yours
[15:11] <gary_poster> :-) k.  So, I wanted to make sure everyone knew about the RENormalizing in zope.testing
[15:11] <gary_poster> And I wanted to see if we could encourage folks to use it more when appropriate
[15:11] <gary_poster> is anyone not familiar with what it does?
[15:11] <barry> gary_poster: can you explain what that is for those not familiar with it?
[15:11] <abentley> gary_poster: me
[15:11] <bac> me
[15:11] <intellectronica> gary_poster: not a clue, tbh
[15:11] <gary_poster> k
[15:11]  * BjornT knows about it, and doesn't like it so much :)
[15:12] <gary_poster> so, you use it when an ellipsis is too generic, and when an example output might be more helpful
[15:12] <gary_poster> so for instance, in your test, you might not want to specify what a host name is
[15:12] <gary_poster> so you can write in your test that http://launchpad.net/ should be normalized.
[15:12] <gary_poster> It's not good for big long strings IMO
[15:13] <barry> gary_poster: do you have an example?
[15:13] <gary_poster> but good for short bits in which having real text would help
[15:13] <flacoste> my main gripes for it is that it's hard to setup using our current infrastructure
[15:13] <abentley> gary_poster: What does normalized mean in this context?
[15:13] <intellectronica> gary_poster: is there an example we can look at?
[15:13] <rockstar> me
[15:13] <gary_poster> yeah I was thinking that I should have gotten that.  One sec, we have one in the tree (my fault ;-) )
[15:13] <mars> is this a feature already in doctest?
[15:14] <flacoste> no
[15:14] <flacoste> it's an addition on top of doctest
[15:14] <flacoste> you have to install it as an outputchecker
[15:14] <flacoste> iirc
[15:14] <gary_poster> right.  you hook it up in tests.py
[15:14] <flacoste> that's the setup part that isn't convenient
[15:14] <flacoste> since we usually don't have a separate setup for doctests
[15:14] <flacoste> but it's probablys omething we should change
[15:14] <mars> setuptools extension points FTW
[15:15] <sinzui> me
[15:15] <BjornT> gary_poster: fwiw, i would like RENormalizing more, if it was possible to use it from within the doctest, instead of doing everything in the harness
[15:15] <gary_poster> right.  sorry my grep was too promiscuous
[15:15] <barry> flacoste: well, we kind of do, but it's tricky to add stuff globally
[15:15]  * sinzui keeps typing into the wrong window
[15:15] <gary_poster> BjornT: I can see that.
[15:15] <barry> BjornT: you mean something like a + option?
[15:15] <flacoste> like Bjorn says, having to modify the harness everytime you want to use it isn't convenient
[15:16] <mars> oh, /that/ kind of setup - not activating the tool, but setting up the harness.  I get it.
[15:16] <BjornT> gary_poster, flacoste: i'm not worried about the difficulty of setting up, but rather making it clear to the reader that something special is going on
[15:16] <flacoste> barry: +1
[15:16] <BjornT> barry: yes, something like
[15:16] <barry> flacoste, BjornT that makes a lot of sense (maybe: i still don't quite know what renormalizing looks like :)
[15:16] <intellectronica> gary_poster: perhaps it would be better to write about this to the list, so that we can discuss after we've all familiarized ourselves with it?
[15:16] <gary_poster> ok, so in the set up:
[15:16] <gary_poster> lib/canonical/launchpad/mail/ftests/test_stub.py
[15:16] <flacoste> barry: think of it as a regex that is applied before comparing the output
[15:17] <barry> flacoste: that's kind of cool
[15:17] <flacoste> barry: it is!
[15:17] <flacoste> not just that convenient to use
[15:17] <flacoste> especially if you need a bunch of different normalizing rules for different examples in the same test
[15:18] <flacoste> being able to control it from within the doctest would be a huge gain
[15:18] <intellectronica> oh, now i understand. i agree with BjornT, having this transformation done behind the scene without any indication in the document itself sounds very confusing to me
[15:18] <barry> gary_poster: nice example, i get it
[15:18]  * barry agrees
[15:18] <flacoste> well
[15:19] <flacoste> i think the confusion springs for us to be accustomed to seeing ellipses everywhere
[15:19] <gary_poster> so the premise is that it is supposed to make it easier to get the gist; and that it makes the test a-bit-to-a-lot more precise than an ellipsis
[15:19] <flacoste> if the policy was never to use ellipses
[15:19] <flacoste> it isn't confusing
[15:19] <flacoste> because you know that normalisation is happening
[15:19] <flacoste> always
[15:19] <flacoste> or can expect it to be
[15:20] <barry> i've never looked: how hard is it to add new +OPTIONS?
[15:20] <flacoste> i think it is very hard
[15:20] <flacoste> not pluggable at all
[15:20] <gary_poster> so anyway, my proposal is that we encourage the use of this thing.
[15:20] <gary_poster> Right
[15:20] <barry> dang
[15:20] <mars> barry, doctest.register_optionflag(name)
[15:20] <gary_poster> You may be able to do it in zope.testing
[15:20] <flacoste> ok, i'm on crack
[15:20] <gary_poster> because that is already essentially a fork of dictes
[15:20] <gary_poster> heh
[15:20] <gary_poster> doctest
[15:21] <gary_poster> since it is not pluggable
[15:21] <flacoste> well, mars seems to indicate that it is
[15:21] <mars> http://docs.python.org/library/doctest.html#doctest.register_optionflag
[15:21] <MootBot> LINK received:  http://docs.python.org/library/doctest.html#doctest.register_optionflag
[15:21] <abentley> bzr development frequently uses assertContainsRe in its unittests, and it's quite useful.
[15:21] <flacoste> heh MootBot, you're not on strike today!
[15:21] <barry> um, okay, that registers the flag, how do you tell it what the flag should do?
[15:21] <abentley> (It asserts that a string contains a given regex)
[15:21] <gary_poster> Well, I know that customizing doctest has been a problem
[15:21] <gary_poster> and right
[15:22] <gary_poster> this is not just a flag
[15:22] <abentley> This seems similarly useful.
[15:22] <abentley> Though it does kinda get away from the idea that the tests are documentation.
[15:22] <barry> gary_poster: are you interested in investigating whether renormalization can be hooked into a +flag?  if so, then i think we could start using it in a limited/experimental way
[15:22] <flacoste> barry: i don't think we should start there
[15:23] <flacoste> i think we can try using it today
[15:23] <flacoste> with the current limitations
[15:23] <gary_poster> abentley: do you feel that the example I gave took it away from documentation?
[15:23] <flacoste> which will give us more exposure to the setup problems
[15:23] <gary_poster> the idea there was that it helped, since an example revision # is more informative than an ellipsis
[15:23] <abentley> gary_poster: No.  The example you gave didn't seem to need it either, though.
[15:23] <barry> flacoste: that sounds good to me
[15:24] <gary_poster> abentley: you mean, an ellipsis would have been as good or better for you?
[15:24] <abentley> Regexes tend to look like line noise.
[15:24] <abentley> gary_poster: Yes.
[15:24] <gary_poster> abentley: hm.  diff'rent strokes and all I guess.
[15:24] <barry> abentley: but you don't generally see the regexp in the doctest, and also ellipses can often be distracting
[15:25] <gary_poster> ok so anyway, barry, that's my spiel. :-)
[15:25] <gary_poster> as an aside, maybe we ought to investigate manuel or other more flexible doctest mechanisms at some point, but that's a much bigger deal
[15:25] <barry> gary_poster: thanks.  can you send an email to the ml explaining this and letting them know we can use it experimentally?
[15:25] <abentley> gary_poster: Okay, I skimmed too quickly.
[15:25] <barry> gary_poster: yeah, and yeah :)
[15:26] <abentley> gary_poster: It's not as bad as I thought.
[15:26] <gary_poster> abentley: cool
[15:26] <gary_poster> barry: will do.
[15:26] <barry> [ACTION] gary_poster to send an email to ml explaining RENormalization
[15:26] <MootBot> ACTION received:  gary_poster to send an email to ml explaining RENormalization
[15:26] <barry> thanks
[15:26] <flacoste> my item?
[15:26] <barry> flacoste: sure
[15:26] <barry> [TOPIC] flacoste peanut gallery item
[15:26] <flacoste> it's about dead zone reviews
[15:26] <MootBot> New Topic:  flacoste peanut gallery item
[15:26] <flacoste> TOPC: dead zone reviews
[15:27] <barry> flacoste: you mean reviews outside my cell phone range?
[15:27] <flacoste> how to proceed with branches that are ready when nobody is on call
[15:27] <flacoste> for example, stuart put out a branch last week for review
[15:27] <flacoste> that hasn't been picked up by anybody yet
[15:28] <flacoste> simply because he didn't try finding a reviewer
[15:28] <barry> rockstar: when are we getting mp queues? :)
[15:28] <flacoste> nobody was on call when the branch was reviewed
[15:28] <rockstar> barry, dunno.  thumper talked about it.
[15:28] <barry> flacoste: didn't try or couldn't find?
[15:29] <flacoste> i think the former, but nobody was on call
[15:29] <flacoste> and previously
[15:29] <rockstar> barry, but there is http://edge.launchpad.net/launchpad/+requestedreviews
[15:29] <flacoste> the general queue was assigned automatically
[15:29] <flacoste> but this kind of died with the advent of OCR
[15:29] <barry> flacoste: well, not so much automatically, but i get what you're saying
[15:29] <rockstar> flacoste, I still think it's the reviewee's responsibility to find a reviewer, even if there are tools for the reviewer to find outstanding reviews.
[15:29] <flacoste> right, you put a branch on pending reviews and somebody would get to it
[15:29] <barry> flacoste: as a fallback, you can always ping someone on #lp-code.  i've done reviews that way several times
[15:30] <allenap> rockstar: Do you mean +merges? That link breaks.
[15:30] <barry> rockstar: yep
[15:30] <rockstar> allenap, no, +requestedreviews
[15:30] <barry> flacoste: or, set up a mp and pick some reviewer at random to review it
[15:30] <flacoste> well
[15:30] <flacoste> that would be annoying for everybody i think
[15:31] <barry> flacoste: yeah, but it shouldn't happen often, right?
[15:31] <allenap> rockstar: Ah yeah, I see it.
[15:31] <rockstar> allenap, sorry, address is https://edge.launchpad.net/~launchpad/+requestedreviews
[15:31] <gmb> flacoste: can't we just make it policy that the OCR checks the queue at the start of their shift for any un-owned branches?
[15:31] <flacoste> that's more what I was getting into
[15:31] <flacoste> back in the days of PendingReviews
[15:31] <flacoste> allocating reviews was part of the OCR shift
[15:31] <flacoste> and this was never replaced when we switched to MPs
[15:31] <gmb> flacoste: Also
[15:32] <gmb> A simple option would be to put your nick and a link to the mp in the queue in #lp-r
[15:32] <gmb> Regardless of whether someone is on call.
[15:32] <gmb> That way the next OCR knows what needs dealing with.
[15:32] <flacoste> IRC is a lossy medium
[15:32] <rockstar> I re-he-ally don't like the idea of just throwing a review on a pile and saying "get to this"
[15:32] <flacoste> so i wouldn't count on it
[15:33] <gmb> rockstar: What, any more than we do already? The only difference now is that hte reviewer can say "sorry, branch X took longer than I expected, no can do sunny jim"
[15:33] <rockstar> gmb, but there's still an personal interaction there.
[15:34] <gmb> True
[15:34] <rockstar> For instance, I think there's real value in someone ASKING me if I can do a review even if I'm OCR.
[15:34] <flacoste> ok, so we are changing the policy here
[15:34] <flacoste> if we agreees on this change
[15:34] <rockstar> Code reviews should not be mechanical.
[15:34] <rockstar> Maybe we're changing the policy to match our current flow.
[15:34] <flacoste> well
[15:34] <barry> rockstar: i tend to agree with you
[15:34] <flacoste> what about when we get drive-by contributors?
[15:35] <flacoste> we'll have to have some form of queue there
[15:35] <rockstar> My understanding has always been that it's reviewee's responsibility to make sure the branch gets reviewed.
[15:35] <flacoste> rockstar: it is
[15:35] <flacoste> but
[15:35] <flacoste> there were mechanism to make that easy
[15:35] <flacoste> now, it's much more "personal"
[15:35] <rockstar> Yes, it's called "hey flacoste, can you review my branch" ?
[15:35] <BjornT> rockstar: the problem is that it's not always easy to find someone online. if there's a policy that if you submitted the merge request yesterday, you can jump the queue, then it might work. otherwise we'll have branches that take a long time to get reviews, just because you'r not at irc at the right time
[15:35] <flacoste> exactly
[15:36] <flacoste> especially in dead zones like thailand
[15:36] <barry> flacoste: the main thing i want to ensure tho, is that it's foolproof that the queue is managed correctly.  meaning specifically it cannot be possible that someone forgot to pop an item off the queue and an ocr wastes time reviewing something already reviewed because they failed to look in the magical right place
[15:36] <rockstar> BjornT, you can email.  I've done reviews for jtv that way before.
[15:36] <flacoste> which increase the turn-around time even more
[15:37] <flacoste> since there is no queue management right now
[15:37] <rockstar> If you're requesting a review from someone on the other side of the world, you're not worried about turnaround time.
[15:37] <bac> email increases turn-around time?  not if stub/whoever looks at the schedule and picks the next OCR to come on duty
[15:37] <flacoste> i think it's ok for the policy to be, you have to find someone to agree to review your branch
[15:37] <flacoste> given the current number of reviewers it shouldn't be a problem
[15:37] <flacoste> but we need to make that official policy
[15:38] <flacoste> it means that once you have a merge proposal out there
[15:38] <flacoste> there should be an indivual assigned to it
[15:38] <flacoste> not just the LP team
[15:38] <flacoste> otherwise, your branch isn't going to get reviewed
[15:38] <flacoste> that's how review allocation is done through Launchpad
[15:38] <rockstar> flacoste, well, it can be the LP team, just in case that person doesn't get to it in time (like in gmb's case).
[15:38] <flacoste> that doesn't work
[15:39] <rockstar> In that case, you ask someone else and they pick it up instead.
[15:39] <mars> flacoste, rockstar, would adding a "Pending review by" column to +activereviews help?
[15:39] <flacoste> and you assign it to them
[15:39] <flacoste> if it's assigned to the team
[15:39] <barry> flacoste, or anyone: do we know of other people having problems or is it primarily stub?  if the latter, we can add special cases for his situation
[15:39] <flacoste> it's assigned to no one
[15:39] <gary_poster> barry: foolproof that queue is managed correctly: sometimes you get a branch that has not been assigned specifically for you to review.  Maybe in that case you make a "i'm reviewing it" review initially as a marker for others?
[15:39] <rockstar> mars, I don't know if it would.  It wouldn't help me.
[15:39] <mars> rockstar, ok
[15:40] <barry> dammit!
[15:40] <rockstar> It would be helpful if you could un-request someone to review it.
[15:40] <flacoste> barry: i only know of stub, but that's mainly because he's used to the old scheme
[15:40] <barry> what did i miss? ;)
[15:40] <barry> rockstar: that would be useful.  then stub could pick the next schedule ocr, which would work 90% of the time
[15:41] <rockstar> Because ideally, once every reviewer says "Approve" then the status of the BMP should be "approved"
[15:41] <barry> flacoste: as an ocr, i'd be happy if there were a stub branch or two that were waiting for me when i started
[15:41] <abentley> gary_poster: Would it make sense for "claim review" to be separate from "perform review"?
[15:41] <flacoste> yes!
[15:41] <flacoste> there is no way to claim a review
[15:41] <gary_poster> abentley: I think that would be cool
[15:41] <flacoste> except by doing it
[15:42] <barry> flacoste: i'd just pick them off first.  the question is, how best to seed the queue?
[15:42] <flacoste> or marking your vote as abstain
[15:42] <flacoste> which sounds weird
[15:42] <barry> flacoste: what about this as a trial: stub can pick the next scheduled ocr, assign the mp to him, and leave a note in the channel topic
[15:43] <barry> flacoste: that sounds simple and i think it would work for me.  if that fails then we can try something else
[15:43] <flacoste> barry: i don't think making an exception for stub is useful at this point
[15:43] <flacoste> we just have to state that you have to find a reviewer for your branch
[15:43] <flacoste> so if there is no indivual reviewer assigned to it
[15:44] <flacoste> your branch is not going to be reviewed
[15:44] <flacoste> and run with it for a while
[15:44] <barry> flacoste: stub was just an example.  i think most devs don't fall into dead zones
[15:44] <flacoste> it's possible that it's not a problem in practice for anybody to be able to find somebody to commit to a review
[15:44] <bac> reviewers will need to get in the habit of checking their +requestedreviews ... i know i've never looked at it before
[15:44] <flacoste> the problem here is that he was expecting somebody to pick it up, like it used to work
[15:44] <rockstar> bac, it's a relatively new view.
[15:44] <flacoste> the problem is that there was a subtle change in workflow without any formal announcement
[15:45] <flacoste> bac: well, if you commit to something, you commited to something
[15:45] <barry> flacoste: i think i get what you're saying
[15:45] <bac> flacoste: well, i didn't commit to it if someone just assigns the review to me
[15:45] <flacoste> you only need to look at +requestedreviews if you have trouble remembering your commitments :-)
[15:45] <flacoste> bac: nobody would
[15:45] <flacoste> they would ask you permission to assign you to it
[15:46] <bac> that's not what barry suggested ^^, which seems reasonable to me
[15:46] <barry> flacoste: it's always been dev's responsibility to get reviewed, but you're right that it's relatively new that you had to actively round up a reviewer
[15:46] <flacoste> hey bac, can you review this branch for me (because you are OCR, or simply because you are cool)
[15:46] <flacoste> sure!
[15:46] <flacoste> then I assign the review to you
[15:46] <bac> flacoste: that's great if it is the flow we decide on.
[15:47] <barry> flacoste: also would work: an email saying "hey barry, you're on call tomorrow so i left you a present"
[15:47] <flacoste> well, it's the one that we seem to be using and that is possible given the current tool
[15:47] <flacoste> (since we don't want to manage a queue somewhere else)
[15:47] <bac> ah, nm.  being assigned a review will generate email addressed directly to me, so i'd know about it.
[15:48] <barry> bac: yeah
[15:48]  * bac still like the new +requestedreviews view...
[15:48] <rockstar> bac, yeah, I do too, but I think it's important to have that acknowledgement/handshake in the review process.
[15:49] <barry> flacoste: we're out of time today.  can you bring this up on the ml just to solidify the policy?  or email me to hash it out first
[15:49] <BjornT> the problem with this workflow is that now you suddenly rely on a single person to have time to review your branch, instead of relying that any of the OCRs have time
[15:49] <bac> Q:  i see ~launchpad/+requestedreviews has very few listed, which means ~launchpad is not automatically being added to some new MPs.  why is that?
[15:49] <bac> BjornT: only if you're not around for the OCR.
[15:50] <abentley> bac: Most likely because reviews created by email don't have that set.
[15:50] <BjornT> bac: or the branch is around too late, so that you have to wait the next OCRs to start their shift
[15:50] <flacoste> barry: i'll start a thread
[15:50] <barry> bac: there are also some cases where mp's won't auto-assign a team
[15:50] <bac> abentley: i created one this morning using lpsend
[15:51] <barry> flacoste: thanks
[15:51] <flacoste> BjornT: that's what I usually do, if i'm too late, i'll just ask somebody the next day
[15:51] <abentley> bac: and it automatically requested ~launchpad to review?
[15:51] <barry> [ACTION] flacoste to take dead zone reviews discussion to ml
[15:51] <MootBot> ACTION received:  flacoste to take dead zone reviews discussion to ml
[15:51] <bac> abentley: it did not.  i expected it would.
[15:51] <bac> abentley: wrong assumption?
[15:51] <BjornT> flacoste: right. it would still be nicer to ask a group of people, instead of a single person.
[15:51] <abentley> bac: Wrong assumption.
[15:52] <abentley> bac: Not that it shouldn't, but it doesn't.
[15:52] <bac> abentley: ok.
[15:52] <flacoste> BjornT: yeah, but my experience is that this doesn't really work in practice
[15:52] <flacoste> at least, that's my experience with the advent of OCR
[15:52] <flacoste> sure, the OCR might swap it between themselve
[15:52] <flacoste> but only because the first one agreed to it
[15:53] <BjornT> flacoste: that's why i said "would" :) it doesn't work atm, but it would be nice if it would
[15:53] <flacoste> i agree
[15:53] <barry> okay, sorry to do this and my apologies for starting the meeting late, but we're way over, so let's end things here and take it to the ml or #lp-code
[15:53] <barry> #endmeeting
[15:53] <MootBot> Meeting finished at 09:53.
[15:53] <barry> thanks everybody


[07:46] <ppisati> yawn
[09:02] <apw> ppisati, do we still test pandas with 3.13?  infinity was trying to switch the omap4 images to generic kernel and was having trouble with framebuffer and network?
[09:02] <apw> and ... morning
[09:02] <smb> apw, mourning morning
[09:03] <apw> i normally am mourning bed at this time of the morning
[09:03] <ppisati> apw: i tried that last week, network was definitely, but didn't test the framebuffer
[09:03] <smb> apw, lazy git
[09:03] <apw> was definalty working or not working
[09:03] <ppisati> apw: working
[09:05] <ppisati> apw: http://paste.ubuntu.com/6807371/
[09:05] <apw> ppisati, prolly need to get you and infinity together next week to figure out his pain in the installer
[09:06] <ppisati> apw: let me see the framebuffer
[09:06] <apw> ppisati, perhaps upgrade it to -5 as well, i am amazed it works so well for you -4 being a bit of a turkey
[09:06] <ppisati> eh
[09:06] <ppisati> apw: let's see -5
[09:07] <apw> -4 had a hideous brown paper bag in a core allocation primative, it is very bad generally :)
[09:18] <ppisati> apw: flag@panda:~$ uname -a
[09:18] <ppisati> Linux panda 3.13.0-5-generic #20-Ubuntu SMP Mon Jan 20 19:57:47 UTC 2014 armv7l armv7l armv7l GNU/Linux
[09:18] <ppisati> flag@panda:~$ sudo mii-tool
[09:18] <ppisati> eth0: negotiated 1000baseT-HD flow-control, link ok
[09:19] <ppisati> fb seems to be broken though
[09:19] <ppisati> my bet is that infinity has an old boot loader
[09:20] <apw> ppisati, thanks at least we know it isn't systemic, is the boot loader upgradble ?
[09:20] <ppisati> apw: manually repleaceable? yes
[09:20] <ppisati> apw: do we do it automatically? AFAIK no
[09:21] <ppisati> apw: but let's check when he appears
[09:25] <ogra_> we dont do it automatically ... i would have loved to back then but always got pushback "uboot is like BIOS ... we dont replace the BIOS either on upgrades"
[09:26] <ppisati> ogra_: oh, there you are, hello Olli :)
[09:32] <ogra_> :)
[09:36] <apw> ppisati, sounds like a plan to me, thanks
[10:47] <apw> henrix, this set of fixes for CVE-2013-0160, as it does not do the INOTIFY bit due to the lack of that feature in that release, how does it avoid the issue
[10:49] <henrix> apw: since this fsnotify isn't in lucid, the user can't actually monitor a ptmx without reading atime/mtime
[10:49] <henrix> hmm....
[10:50] <henrix> but now that i think about it, i may be wrong
[10:50]  * henrix goes back into old code to check if this is actually true
[10:51] <apw> fsnotify is there, the nonotify flag isn't, right ?
[10:52] <henrix> yes, it is
[10:52] <apw> henrix, worse it seems to have inotify and fsnotify "unmerged" in there, gah
[10:53] <henrix> so... ok, let me take a closer look at this.  i guess i assumed something that is not true :/
[10:53] <apw> henrix, though you also tested it, so perhaps the test is bogus, not sure
[10:54] <apw> henrix, in better news the bit which introduces the very basic support looks pretty easy to backport (commit ecf081d1a73b077916f514f2ec744ded32b88ca1)
[10:54] <henrix> apw: yes, i've used the PoCs and they don't work with these backports. *however* the PoCs don't use fsnotify, they read the atime
[10:55] <apw> henrix, thoguh it has a fix applied on top to change the constant (12ed2e36c98aec6c41559222e311f4aa15d254b6)
[10:56] <apw> henrix, ahh that would explain it then, so i think those two are trivial to backport, if we ignore the rest of the functionality that is for, ie all the other bugs FANONOTIFY is meant to fix :)
[10:56] <apw> though in the backport the inotify bits need to be in the "if"
[10:57] <henrix> apw: yep, makes sense.  sooooo.... let me send myself a NACK and go take another look at this
[10:58] <henrix> apw: and thanks for keeping your eyes open!
[10:59] <apw> i've replied with the bits of info here summarised, and ... that is why we do peer review of these things, as it is unrealistic to expect people to never make an error, never happen
[11:00] <henrix> cool!  so, i'll work on these 2 additional backports and re-tests.
[11:00] <henrix> thanks ;)
[11:00] <apw> henrix, wonderful indeed
[11:01] <apw> there is an inotify_watch oro somethign which ought to allow you to confirm it doesn't work
[11:02] <apw> inotifywait -m /dev/ptmx
[11:02] <apw> i think that is the baby which should show it
[11:02] <apw> henrix, ^^
[11:03] <henrix> apw: ah, nice. i'll use that for additional testing.
[11:10]  * apw tries to confirm that works
[11:10] <apw> as alll my kernels are fixed :/
[11:11] <apw> seems that someone has been toooo efficient
[11:12] <brendand> does anyone here know much about hdd parking? we're trying to test it and it seems atm as if there's a lot of different implementations, only some of which are supported
[11:12] <brendand> hdaps being one that works
[11:12] <apw> brendand, do you mean parking as in "oh shit i am falling and likely there will be some hitting real soon, park NOW"
[11:13] <apw> brendand, and if so, then not much is know but yes, it is a fragmented secret sauce part of the h/w eco system
[11:14] <brendand> apw - what other kind of parking is there :/ ?
[11:15] <apw> well parking is just then "putting the heads away", you do this on poweroff of the drive, sometimes on idle
[11:15] <apw> and in some cases on "oh shit i am falling"
[11:15] <apw> i would call it "emergency HDD parking" or something to be clear you mean that
[11:15] <brendand> apw - do you know any other implementations (that are supported in ubuntu)?
[11:16] <apw> but cirtainly it has never been something we have investigated, so no i don't think we do know
[11:16] <apw> i doubt any are configured automatically correctly
[11:16] <apw> as from even the hdaps for IBM stuff is randomly model specific, gah what a mess
[11:26] <brendand> apw, yes - somebody needs to take the initiative to make a standard interface for it
[11:49] <apw> henrix, ok ... confirmed that without your patches at all lucid shows the inotify issue using the test above
[11:50] <henrix> apw: ack, thanks. i haven't reached that point yet -- still building test kernel, and will re-test in a few minutes
[11:51] <apw> henrix, figured i would test an unfixed kernel first :)
[11:52] <henrix> yep, makes sense :)
[11:59] <apw> henrix, as the lucid installs i have are server only, i ran that on the console and then ssh'd in
[12:02] <henrix> apw: i've just tested in a vanilla lucid VM as well and confirmed your test result ;)
[13:12] <apw> henrix, yay
[13:13] <henrix> apw: hey...?
[13:13] <henrix> what's up?
[13:21] <apw> henrix, nothing: yay == poisitive sounds for your confirmation of my test result
[13:21] <henrix> apw: ahh! :)
[13:22] <henrix> apw: and i've just finished my testing with v2 of the patchset.  just finishing the cover letter and will send it in a bit
[13:26] <apw> henrix, sweet
[13:35]  * henrix curses AUFS
[13:41]  * Kaloz is wondering why anyone would use aufs
[13:41] <henrix> beats me :)
[13:42]  * Kaloz handles henrix the note about the current year ;)
[13:43] <Kaloz> we never adopted unionfs/aufs, went straight to overlayfs from mini_fo
[13:58] <rsalveti> apw: updated tree for flo (new nexus 7): http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/flo
[13:59] <rsalveti> apw: tested and working fine with my 4.4 based image, so can already be pushed to the archive
[13:59] <rsalveti> apw: just need a new release + meta
[14:03] <rsalveti> apw: grouper rebase for kitkat: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-trusty.git;a=shortlog;h=refs/heads/grouper-rebase-kitkat (also tested with 4.4)
[14:03] <rsalveti> apw: but that would need to go into a PPA for now
[14:04] <apw> rsalveti, ack
[14:10] <apw> rsalveti, do i need to interact with someone to upload the flo one or can i dump it in -proposed
[14:11] <rsalveti> apw: just dump it in proposed
[14:11] <rsalveti> argh, wrong monitor (contro + w) :-)
[14:15] <apw> heh focus fail, a common problem with unity in my experience
[14:18] <ogra_> we just need to add eyetracking via webcam ... and use focus follows eyes
[14:19] <ogra_> trivial stuff :P
[14:20]  * henrix sends v2 of CVE fix and runs
[15:35] <apw> rsalveti, ok flo in the queue
[15:41] <apw> rsalveti, do this grouper rebase is just to 3.1.10 its not a 3.4 rebase
[15:43] <apw> rsalveti, so ... is still a 3.1 kernel then ... just checking
[16:12] <rsalveti> apw: yeah, still 3.1, just rebase on top of the 4.4.2
[16:12] <rsalveti> changes
[16:12] <apw> ok
[16:51] <apw> rsalveti, ok uploaded grouper to ckt PPA
[17:11] <rsalveti> apw: great, thanks


[02:20] <thumper> davecheney: does go test buffer output?
[02:47]  * thumper loses davecheney
[02:47] <thumper> hmm...
[02:47]  * thumper waits
[05:58] <jam> wallyworld_: if you prefer today, https://plus.google.com/hangouts/_/750982817f7631223162e5af2eceb6726c27bfe3
[07:03] <jam> thumper: /wave
[07:42] <rogpeppe1> mornin' all
[07:44] <dimitern> morning!
[08:29] <thumper> jam: oh hai
[08:29] <thumper> jam: just read your email respons
[08:29] <jam> hi thumper
[08:29] <thumper> jam: I'll pop back in in 30min to see if fwereade is around
[08:29] <jam> I'm pretty sure william is gone today
[08:30] <thumper> ah, that's right
[08:30] <thumper> leave
[08:30] <thumper> geez
[08:30] <jam> so we can check in 30min, but probably just going for tomorrow might work better
[08:30] <dimitern> thumper: fwereade is gone all week btw
[08:30] <jam> dimitern: thanks for the clarification.
[08:30] <jam> he still wanted to meet with us during that time, but it is hard to meet up today.
[08:31] <jam> thumper: I can do the same time tomorrow
[08:31] <jam> thumper: does it work for you?
[08:31] <dimitern> jam: not sure about that - he'll probably pop in at some point in irc at least (provided he has decent connection in backwater gozo :)
[08:32] <thumper> jam: can you do now?
[08:33] <thumper> hi dimitern
[08:33] <jam> thumper: I could do now for a bit. I techincally have a call with dimitern in 30min, but I think he would accept moving it around a bit.
[08:33] <jam> obviously mark won't be there.
[08:33] <dimitern> thumper: do you have 5m about a couple of bzr pipes question?
[08:33] <thumper> jam: we could be done in 30 minutes
[08:33] <thumper> jam: I don't think there is that much to discuss :)
[08:33] <dimitern> thumper: hiya
[08:33] <thumper> dimitern: leave the question and I'll answer as fast as I can
[08:34] <dimitern> jam: sure, np moving it later
[08:34] <thumper> jam: I'm fine with mark not being there
[08:34] <thumper> jam: lets hang out
[08:35] <thumper> oh for the love of god why did hangouts get so hard to start?
[08:36] <jam> thumper: https://plus.google.com/hangouts/_/16239e7d8ea236f8aa18ed4ada6c87f9e6dc3dfc
[08:40] <dimitern> thumper: ah, actually thanks to the very good docs you wrote I managed :) cheers
[08:41] <dimitern> jam: ping me when you're done
[09:11] <jam> dimitern: poke
[09:12] <jam> would you prefer hangout to mumble?
[09:12] <dimitern> jam: don't mind a hangout
[09:13] <jam> dimitern: https://plus.google.com/hangouts/_/e7c22066f25817d34f2bb47a6c1eabc32def3fc6d
[09:13] <dimitern> jam: i'm there
[09:15] <jam> dimitern: I don't see you yet, I'm also in mumble if it is easier for you to get there.
[09:15] <dimitern> jam: hmm - ok. let's mumbe then
[09:15] <mgz> mum-be!
[09:16] <thumper> night all
[09:16] <jam> let's get ready to mummmbleeee!!!
[10:17] <dimitern> mgz: ping
[10:17] <mgz> pong
[10:19] <dimitern> mgz: sorry, stupid question maybe, but i'm trying to unlearn cobzr workflow and switch to normal bzr one - i'm using a LW checkout of juju-core, my current branch is trunk, how to create a feature branch out of it? tried bzr branch . new-branch, but it seems to do more than it should
[10:21] <mgz> `bzr switch -b new-feature`
[10:21] <dimitern> mgz: and running go build ./... && go test ./... afterwards gives me lots of errors: http://paste.ubuntu.com/5683245/
[10:22] <mgz> your commands tells bzr to create a new copy of the current branch under the same tree structure, which no doubt confuses go
[10:22] <mgz> (fix by `rm -rf new-branch`)
[10:24] <dimitern> mgz: ah, ok, so how can I fix what I messed up? I did the rm -fr new-branch, but how to switch back to trunk? (040-move-set-agent-alive-out-of-machiner) dimitern@kubrik:~/work/juju-core$ bzr switch trunk
[10:24] <dimitern> bzr: ERROR: Not a branch: "/home/dimitern/work/go/src/launchpad.net/juju-core/trunk/".
[10:24] <mgz> what does `bzr branches` say?
[10:25] <dimitern> mgz: bzr: ERROR: Not a branch: "/home/dimitern/work/go/src/launchpad.net/juju-core/040-move-set-agent-alive-out-of-machiner/".
[10:25] <mgz> exciting.
[10:26] <dimitern> mgz: oh well, maybe I should scrach everything and start over - nothing done yet, so nothing to lose
[10:26] <mgz> edit .bzr/branch/branch.conf
[10:26] <mgz> or yeah, just start over
[10:26] <dimitern> mgz: thanks
[10:26] <mgz> so, are you aiming for native colo,  or a shared repo?
[10:27] <mgz> the general idea is the same, but what you need in the go world is slightly different
[10:28] <dimitern> mgz: i want to have ~/src/juju-core shared repo with no trees, have $GOPATH/../j-c bound to that lwco and have a symlink in ~/work/juju-core to safe typing
[10:29] <mgz> okay, like jam does. pretty sure he still uses switch, but also has some locations magic
[10:30] <dimitern> mgz: i'm a bit confused that i have to specify paths for switch and merge - with cobzr i needed just the branch names
[10:32] <dimitern> mgz: so generally, when i'm in trunk to create a new branch I just need bzr branch -b new-branch and it'll switch to it as well?
[10:34] <mgz> no, `bzr switch -b`, which creates the branch
[10:35] <dimitern> mgz: ah, right. and then while i'm in new-branch to merge trunk in: bzr merge trunk ?
[10:35] <mgz> you need a path for merge, but often you just want `bzr merge :parent`
[10:36] <dimitern> mgz: cool! i'll add alias for this
[10:39] <dimitern> mgz: strange though while in new-branch "bzr branches" shows * . only and "bzr show-pipeline" shows what I expected: * new-branch
[10:39] <mgz> yeah, branches go borked about the shared repo case again I think
[10:40] <mgz> *got
[10:40] <dimitern> mgz: but i did a fresh clone of trunk
[10:42] <dimitern> mgz: and now, while in new-branch i did bzr switch trunk, then bzr remove-branch new-branch and it said: bzr: ERROR: Branch is active. Use --force to remove it.
[10:42] <mgz> what does `bzr info` say now?
[10:43] <dimitern> mgz: http://paste.ubuntu.com/5683309/
[10:44] <mgz> that still seems sane
[10:45] <dimitern> mgz: light chechout root: . seems fishy - should it be like that?
[10:45] <mgz> ah, wait
[10:46] <mgz> no, should be okay
[10:47] <mgz> it may be just a confused remove-branch somehow
[10:47] <dimitern> mgz: how to manually remove it?
[10:48] <mgz> it's not very useful for the branch-in-dir layout anyway, as you want to rm the directory after, and that's what you need to remove the branch too
[10:48] <mgz> dimitern: just `rm -rf ~/src/juju-core/new-feature`
[10:49] <mgz> you can try `bzr rmbranch ~/src/juju-core/new-feature` first
[10:49] <mgz> and use --force if that complains
[10:49] <dimitern> mgz: too late :)
[10:49] <mgz> new experiment time :)
[10:50] <mgz> just `bzr switch -b new-feature && bzr switch trunk` then go
[10:50] <dimitern> mgz: i'll try again
[10:50] <mgz> (or `bzr branch . ~/src/juju-core/new-feature`)
[10:52] <dimitern> mgz: in addition to --no-trees what else should i specify to init-repo so there are no files in there? with cobzr there were just empty dirs for branches and the root dir was empty as well (safe for .bzr)
[10:52] <mgz> just that
[10:53] <dimitern> mgz: oh, I see the problem - instead of doing init-repo i just did mkdir juju-core && bzr branch lp:juju-core trunk before
[10:57] <dimitern> mgz: now it works and bzr branches reports * new-branch \n trunk as expected
[10:58] <dimitern> mgz: i added bash completions for bzr commands (very handy!) and a small script to show me the current branch name in the prompt. it will be really useful if somehow i can complete branch names as well in bzr commands - any idea what can i use?
[10:59] <mgz> not off hand
[11:02] <dimitern> oh well, it's not that bad with a few aliases and such
[11:02]  * dimitern bbiab
[11:22] <dimitern> back
[11:48] <dimitern> rogpeppe1: ping
[11:48] <rogpeppe1> dimitern: pong
[11:48] <dimitern> rogpeppe1: if i move setagentalive in MA.Entity(), when should I stop the pinger then?
[11:48] <rogpeppe1> dimitern: i don't think that's the right place for it
[11:49] <dimitern> rogpeppe1: where then? runloop?
[11:49] <rogpeppe1> dimitern: possibly. let me look again, one mo
[11:51] <rogpeppe1> dimitern: hmm, how many pingers do we want going at once?
[11:51] <dimitern> rogpeppe1: how many? just one i think
[11:51] <dimitern> rogpeppe1: for the machine entity the MA is responsible for
[11:51] <rogpeppe1> dimitern: in which case i think that the current way is perhaps the only decent solution
[11:52] <rogpeppe1> dimitern: unless we make another worker specifically to maintain the pinger
[11:52] <dimitern> rogpeppe1: i thought we agreed to move it
[11:52] <rogpeppe1> dimitern: yes, but i'm not sure it's right
[11:52] <rogpeppe1> dimitern: in the machine agent there are two concurrent runLoops
[11:53] <dimitern> rogpeppe1: which are?
[11:53] <rogpeppe1> dimitern: the API server and the rest of the workers
[11:53] <rogpeppe1> dimitern: and we will have three
[11:53] <rogpeppe1> dimitern: as we move towards using the API for the workers
[11:53] <dimitern> rogpeppe1: william mentioned you agreed to merge some of these loops
[11:54] <dimitern> rogpeppe1: not sure what was it
[11:54] <rogpeppe1> dimitern: i'm not sure that's what we arrived at
[11:54] <dimitern> rogpeppe1: well this is kinda blocking me
[11:55] <rogpeppe1> dimitern: in my understanding we decided to have a separate loop for workers which connect to mongo and workers which connect to the API
[11:55] <dimitern> rogpeppe1: i can switch to the other task - machine api instead
[11:56] <dimitern> rogpeppe1: and leave the AA stuff until next week to have an agreement
[11:56] <rogpeppe1> dimitern: i think that's not a bad idea, particularly as fwereade doesn't appear to be around currently.
[11:56] <rogpeppe1> dimitern: sorry not to be more help
[11:57] <dimitern> rogpeppe1: it's ok, i just need to start from somewhere. can do the AA stuff later, it's orthogonal
[12:02] <dimitern> rogpeppe1: do you have 20m for a quick hangout about the machine api?
[12:02] <rogpeppe1> dimitern: sure
[12:02] <dimitern> rogpeppe1: i'll start one as soon as we finish the standup
[12:02] <rogpeppe1> dimitern: ok
[12:10] <dimitern> rogpeppe1: they changed *everything* on g+ - how do i start a hangout now??
[12:11] <rogpeppe1> dimitern: i'll try!
[12:11] <rogpeppe1> dimitern: do you think "hangouts" are the same as "hangouts on air" ?
[12:12] <dimitern> rogpeppe1: no - those are live streaming ones
[12:12] <dimitern> rogpeppe1: public
[12:14] <rogpeppe1> dimitern: https://plus.google.com/hangouts/_/efbe73ddf30405282d381b4767ff0762c0dee700?authuser=0&hl=en-GB
[12:21] <ahasenack> hi guys, I'm getting "ERROR: Not a branch" for goose when I run go get -v -u launchpad.net/juju-core/... : http://pastebin.ubuntu.com/5683526/
[12:21] <ahasenack> I didn't see anything in the juju-dev@ mailing list about this, or about some branch changing
[13:35] <dimitern> ahasenack: you probably didn't update goose for a while
[13:36] <ahasenack> dimitern: I run go get -v -u everyday
[13:36] <dimitern> ahasenack: trunk moved to another location owned by the go-bot
[13:36] <ahasenack> dimitern: if I trash everything under $GOPATH/src and run go get -v launchpad.net/juju-core/... will it be using the right branch?
[13:36] <dimitern> ahasenack: you'll need to pull it from lp:goose and use --remember and --overwrite
[13:36] <dimitern> ahasenack: that should work if you can do it\
[13:37] <ahasenack> sure, it's fast
[13:37] <ahasenack> dimitern: thanks
[13:37] <dimitern> ahasenack: but use go get -v -u
[14:01] <dimitern> mramm2, rogpeppe1: kanban?
[14:42] <dimitern> rogpeppe1: you did godef right?
[14:42] <rogpeppe1> dimitern: yeah
[14:43] <dimitern> rogpeppe1: awesome! it turns out go mode for emacs supports it as an alternative to searching for tags
[14:43] <dimitern> rogpeppe1: and it works way better than tags as well
[14:43] <rogpeppe1> dimitern: ah, cool. i knew someone integrated it at some point
[14:43] <rogpeppe1> dimitern: i wasn't sure if it was available anywhere
[14:44] <rogpeppe1> dimitern: it doesn't *always* work, but it's not bad
[14:44] <dimitern> rogpeppe1: in go 1.1 it's used
[14:44] <rogpeppe1> dimitern: the go parser it uses is an ancient fork of the go parser package
[14:45] <rogpeppe1> dimitern: i really want to update it to use go/types some time, but y'know, "in my copious spare time" :-)
[14:45] <dimitern> rogpeppe1: if it doesn't work for some code i'll tell yu :)
[14:45] <rogpeppe1> dimitern: someone should make it work for vim too
[14:45] <dimitern> rogpeppe1: yeah
[14:45] <rogpeppe1> dimitern: it doesn't know about import .
[14:46] <rogpeppe1> dimitern: as in the way we import gocheck
[14:46] <dimitern> rogpeppe1: yeah
[14:46] <rogpeppe1> dimitern: that's the main limitation i know about currently
[14:47] <rogpeppe1> dimitern: i find the functionality indispensible when browsing through other people's code (and our own, actually, come to that)
[14:47] <rogpeppe1> dimitern: you can get it to tell you type information too
[14:47] <rogpeppe1> dimitern: although i rarely use that functionality
[14:48] <dimitern> rogpeppe1: i'm content with having a "jump" shortcut that works for most cases, rather than having to grep
[14:48] <rogpeppe1> dimitern: yeah. that's the main thing.
[14:48] <rogpeppe1> dimitern: it should work with any identifier
[14:49] <rogpeppe1> dimitern: including field names, type names, method names etc
[14:49] <dimitern> rogpeppe1: yeah, just tested it within the apiserver - sweet! ws.ws.x.y.z.Stop() - no problem :)
[14:50] <rogpeppe1> dimitern: yup, even when ws itself comes from a for loop or something
[14:51] <dimitern> rogpeppe1: really nice
[14:56] <rogpeppe1> dimitern: at one point i instrumented the godoc web interface so that every identifier was shown as a link. that was quite cool.
[14:57] <dimitern> rogpeppe1: they actually have that now in go 1.1
[14:57] <dimitern> rogpeppe1: not sure how
[14:58] <rogpeppe1> dimitern: not really - only in the doc pages, not in the source code itself.
[14:58] <dimitern> rogpeppe1: ah, i see - well it's a start at least
[14:59] <rogpeppe1> dimitern: yeah, it's a great improvement
[15:16] <dimitern> rogpeppe1: why isn't there a srvService? ServiceExpose/Unexpose are global
[15:17] <rogpeppe1> dimitern: ServiceExpose and ServiceUnexpose are client methods
[15:17] <rogpeppe1> dimitern: we need srvService too
[15:17] <rogpeppe1> dimitern: (and that will not have an Expose method)
[15:17] <dimitern> rogpeppe1: hmm.. i have no way to see how some methods on srvMachine should look like
[15:18] <rogpeppe1> dimitern: i suggest you add methods on srvMachine only as they are needed
[15:18] <dimitern> rogpeppe1: let me paste you a few i have so far and tell me if i'm on the right track
[15:19] <rogpeppe1> dimitern: these are all the calls i think we need: http://paste.ubuntu.com/5684020/
[15:20] <dimitern> rogpeppe1: a bit more we need in srvMachine
[15:20] <rogpeppe1> dimitern: oh yes?
[15:20] <dimitern> rogpeppe1: http://paste.ubuntu.com/5684027/
[15:20] <rogpeppe1> dimitern: i did the survey that led to that list ages ago, so things have probably changed since then
[15:21] <rogpeppe1> dimitern: that looks right. we've only done proper lifecycles and status setting relatively recently
[15:22] <dimitern> rogpeppe1: so it looks sane?
[15:22] <rogpeppe1> dimitern: yes apart from SetStatus
[15:22] <rogpeppe1> dimitern: API calls can have at most one argument
[15:22] <dimitern> rogpeppe1: why?
[15:22] <rogpeppe1> dimitern: and that argument must be a struct
[15:23] <rogpeppe1> dimitern: because we need the parameters to be named
[15:23] <rogpeppe1> dimitern: and function params have no associated names
[15:23] <dimitern> rogpeppe1: ah, ok - so params.MachineSetStatus ?
[15:23] <rogpeppe1> dimitern: read go doc launchpad.net/juju-core/rpc
[15:23] <rogpeppe1> dimitern: no, SetStatus is fine
[15:23] <rogpeppe1> dimitern: oops
[15:23] <rogpeppe1> dimitern: yes
[15:23] <rogpeppe1> dimitern: that sounds about right
[15:24] <dimitern> rogpeppe1: yeah, there's unit setstatus as well
[15:24] <dimitern> rogpeppe1: but it's the same
[15:24] <rogpeppe1> dimitern: perhaps just params.SetStatus then
[15:24] <dimitern> rogpeppe1: ok
[15:24] <dimitern> rogpeppe1: and i need to do state.Life -> params.Life conversion as well
[15:25] <rogpeppe1> dimitern: yes. i think you can just use state.Life.String actually.
[15:26] <dimitern> rogpeppe1: ah, cool, even better
[15:32] <dimitern> rogpeppe1: i just realized i have to implement a whole Pinger similarly to EntityWatcher in apiclient as well
[15:33] <rogpeppe1> dimitern: not nearly that complex.
[15:33] <rogpeppe1> dimitern: it's much more similar to  AllWatcher
[15:33] <rogpeppe1> dimitern: but simpler than that
[15:33] <rogpeppe1> dimitern: it'll only have one method, Stop.
[15:33] <dimitern> rogpeppe1: not only that - Alive() as well
[15:34] <rogpeppe1> dimitern: ah yes, that too
[15:34] <rogpeppe1> dimitern: but no complex logic - just a call-through to the api
[15:37] <dimitern> rogpeppe1: yeah seems so
[15:41] <dimitern> rogpeppe1: the problem is pingers are in state/presence, and I don't see how to use that when I'm supposed to have st *State only
[15:42] <rogpeppe1> dimitern: you'll need to define an api.Pinger type
[15:42] <rogpeppe1> dimitern: oh sorry, wrong problem.
[15:42] <dimitern> rogpeppe1: by api you mean put it in apiclient.go
[15:42] <rogpeppe1> dimitern: i'm not sure i see your problem
[15:42] <dimitern> rogpeppe1: yes, i'm there
[15:43] <rogpeppe1> dimitern: what's the difficulty with using a pinger in the API server?
[15:43] <dimitern> rogpeppe1: well the api.EntityWatcher uses stuff like err := w.st.call(w.etype, w.eid, "Watch", nil, &id);
[15:43] <dimitern> rogpeppe1: but i need to call stuff not in state/ but state/presence/
[15:44] <rogpeppe1> dimitern: from the API client? or the server?
[15:44] <dimitern> rogpeppe1: from the client
[15:44] <rogpeppe1> dimitern: why so?
[15:44] <dimitern> rogpeppe1: ok, think for a moment - SetAgentAlive -> *pinger, error
[15:45] <rogpeppe1> dimitern: you will need a new srvPinger type, if you hadn't realised that already
[15:45] <dimitern> rogpeppe1: in the api it's params.PingerId instead
[15:45] <dimitern> rogpeppe1: ah
[15:45] <rogpeppe1> dimitern: so do just what the watcher stuff does
[15:45] <dimitern> rogpeppe1: yeah
[15:45] <dimitern> rogpeppe1: ok, sorry :)
[15:45] <rogpeppe1> dimitern: np
[19:16] <dpb1> Hey -- juju-core has a rather nasty behavior for relation-list if you are calling it on something like a peer relation with only one unit.  Should it be a bug?  It breaks charm suppor and probably many other charms:  See here for an example: https://pastebin.canonical.com/91346/
[21:36] <dpb1> FYI -- I have filed: https://bugs.launchpad.net/juju-core/+bug/1182224
[21:36] <_mup_> Bug #1182224: relation-list returns null with json-output <juju-core:New> <https://launchpad.net/bugs/1182224>
[23:23]  * kyhwana pokes Makyo idly
[23:23] <Makyo> Oh, hey Kyh.
[23:24] <kyhwana> Makyo: oh his :)
[23:24] <kyhwana> Is it idly time around here? Was planning on trying to write a smokeping charm, since there doesn't seem to be one.
[23:26] <Makyo> kyhwana, Yeah, it's past EOD for a lot of folks.  #juju might be more active?
[23:26] <kyhwana> ahh ok
[23:27] <Makyo> kyhwana, mmmmaaybe marcoceppi or m_3 would know a bit more, too, if you need :)
[23:27] <kyhwana> well, will ask around later. That'll be today's After Work project :) I keep breaking my smokeping install at home :|
[23:28] <Makyo> Ah, yeah :S
[23:29] <Makyo> I keep wanting to do some random charm, but every time I think I have a good idea, I find it's already been done :P
[23:34] <kyhwana> hah, I checked the charm list and there's no smokeping one. (otherwise I would've deployed it myself)
[23:35] <Makyo> Yeah, well, hey, there's your chance \o/


[00:08] <teward> enyc: if it's regarding the behavior in -hu it's already on the radar, and on the radar higher than the IRC Council
[05:56] <enyc> teward: ooh interesting, just i'm hearing different opinions between diferent apparent authority.
[05:56] <enyc> teward: I'm somewhat more curious and trying to learn how these things work than wonting to ... insist, I lurk in many places and so-on.


[21:57] <Unit193> AlanBell: Howdy.  Mind if I snag your applicents.py script?  (Or, any others that may be useful)
[22:04] <AlanBell> Unit193: snag away :)
[22:04] <Unit193> Checked in people.u.c, didn't see it.
[22:05]  * AlanBell wonders where it is too
[22:05] <Unit193> Hah, I keep mine in ~/junk/ or ~/Public/ if that helps! :P
[22:06] <AlanBell> http://people.ubuntu.com/~alanbell/scripts/ there now
[22:07] <Unit193> Great, thanks!


[08:37] <b247_eu> Hi, I can't lock my screen, Win+L doesn't work, "gnome-screensaver-command -l" returns "unable to send message: Timeout was reached"; Using Ubuntu 20.04 LTS


[15:00] <liushuyu> o/
[15:01] <ginggs> o/
[15:01] <mclemenceau_> o/
[15:01] <zhsj> o/
[15:01]  * vorlon waves
[15:02] <mateus-morais> o/
[15:02] <waveform> #startmeeting Weekly Ubuntu Foundations team
[15:02] <meetingology> Meeting started at 15:02:43 UTC.  The chair is waveform.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:02] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:02] <waveform> #topic Lightning rounds
[15:03] <waveform> #link https://discourse.ubuntu.com/t/foundations-team-updates-thursday-18-may-2023/35817
[15:03] <waveform> Let's take some time to read the status as usual
[15:03] <vorlon> netplan everywhere landed in mantic-proposed \o/
[15:04] <vorlon> so when network-manager migrates, mantic users will have netplan yaml as the authoritative backend for their network config on desktop :)
[15:07] <waveform> okay, let's look at the incoming stuff
[15:07] <waveform> #topic Release incoming bugs
[15:07] <waveform> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-mm-incoming-bug-tasks.html#foundations-bugs
[15:08] <waveform> bug 2016471
[15:08] -ubottu:#ubuntu-meeting- Bug 2016471 in eztrace (Ubuntu Mantic) "eztrace FTBFS with LTO" [Undecided, In Progress] https://launchpad.net/bugs/2016471
[15:08] <bdmurray> vorlon: How dd you specifically reduce the libreoffice tests?
[15:09] <vorlon> bdmurray: finding any tests still in the queues for lunar and mantic, and re-queuing a replacement --all-proposed test to consolidate the requests (though, I did this for mantic but not yet for lunar)
[15:10] <bdmurray> The bug is already tagged foundations-todo and has a card
[15:10] <waveform> okay, moving on
[15:10] <waveform> bug 2018721
[15:10] -ubottu:#ubuntu-meeting- Bug 2018721 in netkit-telnet-ssl (Ubuntu) "[MIR] netkit-telnet-ssl vs. inetutils-telnet" [Undecided, New] https://launchpad.net/bugs/2018721
[15:10] <bdmurray> The report is 8 days old
[15:10] <dbungert> If the report is that old should we just move on?
[15:10] <vorlon> enr0n: fwiw linux-lowlatency passed its autopkgtest on a rerun with just fakeroot as the trigger so didn't need hinted. I did hint past sbuild/amd64 which is the postfix craziness
[15:11] <waveform> doh
[15:11] <waveform> okay, moving on to ll
[15:11] <enr0n> vorlon: ah okay thanks. I thought I saw a PR for hinting linux-lowlatency somehwere and assumed that did it
[15:11] <waveform> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ll-incoming-bug-tasks.html#foundations-bugs
[15:12] <vorlon> enr0n: there was a PR but I nacked it :)
[15:12] <waveform> bug 2012698
[15:12] <enr0n> vorlon: ah ok
[15:12] -ubottu:#ubuntu-meeting- Bug 2012698 in plymouth (Ubuntu) "Plymouth is stuck on a plain black screen" [Undecided, New] https://launchpad.net/bugs/2012698
[15:12] <vorlon> did we discuss this one last week?
[15:12] <waveform> looks like desktop are still investigating that one, and that's it for ll
[15:12] <waveform> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs
[15:13] <waveform> nothing for foundations this week
[15:13] <waveform> and nothing for foundations in ff either
[15:13] <waveform> #topic Team proposed-migration report
[15:13] <vorlon> bdmurray: libreoffice/i386/mantic is in big_packages instead of never_run?  It's a useless test, there are no i386 libreoffice binaries
[15:13] <waveform> #link https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:13] <waveform> over to vorlon?
[15:14] <vorlon> down to 5 this week
[15:14] <vorlon> openssh vs sbuild: that's the known postfix issue and I'll handle hinting that
[15:14] <vorlon> glib2.0 vs libreoffice, I would ask that people NOT work on this since when I looked last night there were still 90 libreoffice tests running in parallel
[15:14] <vorlon> cmake vs boost - any volunteers?
[15:15] <ginggs> i'll take it
[15:15] <bdmurray> vorlon: My status report was incorrect its in never_run
[15:15] <vorlon> cmake vs boost: ginggs
[15:15] <vorlon> ginggs: thanks
[15:15] <ginggs> i've already retried the test, it *should* padd this time
[15:15] <ginggs> s/padd/pass/
[15:15] <vorlon> and fwupd needs its autopkgtests sorted. volunteer?
[15:15] <liushuyu> I can take one
[15:16] <vorlon> fwupd: liushuyu
[15:16] <vorlon> thanks
[15:16] <vorlon> that's all for today
[15:16] <vorlon> waveform:
[15:16] <waveform> thanks!
[15:16] <waveform> #topic AOB
[15:16] <ginggs> merge party?
[15:16] <ginggs> a small party, since most of europe is out
[15:17] <waveform> sounds good -- there's certainly some I want to take a look at
[15:17] <ginggs> here's the filtered list of outstanding merges
[15:17] <ginggs> https://merges.ubuntu.com/main.html?query=foundations-bugs&showProposed=true&showMergeNeeded=true
[15:17] <waveform> #link https://merges.ubuntu.com/main.html?query=foundations-bugs&showProposed=true&showMergeNeeded=true
[15:18] <vorlon> (also available from the commandline as grep-merges foundations-bugs)
[15:19] <waveform> very nice!
[15:30] <waveform> right, so we've got: enr0n on openssh (and git later); grub2 is being kept for julian_k; I'll take lvm2 (and sbuild, flash-kernel later); vorlon for brltty
[15:31] <waveform> mateus-morais for adduser; dbungert for util-linux; ginggs for base-files; danilogondolfo for sudo (and libpcap2)
[15:32] <vorlon> fwiw I don't suggest taking user-setup
[15:32] <vorlon> I've pinged seb128 about it internally as TIL - the thing is user-setup is primarily consumed by ubiquity, which bundles the source BUT NOT THE VERSION FROM THE ARCHIVE so I'm asking him if he wants to take a look at reconciling this
[15:33] <waveform> good point, I still have some ticket to look at regarding that ...
[15:33] <waveform> okay, have I missed anyone?
[15:33] <waveform> or any other business?
[15:34] <waveform> going once
[15:34] <waveform> going twice
[15:34] <waveform> sold!
[15:34] <waveform> #endmeeting
[15:34] <meetingology> Meeting ended at 15:34:14 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-18-15.02.moin.txt
[15:34] <ginggs> thanks all!
[15:37] <ginggs> boost vs cmake already passed on arm64
[15:39] <waveform> nice


[01:56] <robert_ancell> Has anything changed with how to run Mir demo servers? I'm running sudo mir_demo_server ; chown me.me /run/usr/1000/mir_socket ; mir_demo_client_basic -m /run/user/1000/mir_socket and getting "Failed to connect to server `/run/user/1000/mir_socket': No such file or directory"
[01:56] <robert_ancell> /run/usr/1000/mir_socket definitely exists
[01:57] <duflu> robert_ancell: Not that I'm aware of. Everything should work as before..
[01:57] <robert_ancell> duflu, any debugging tips?
[01:58] <robert_ancell> The client/server seem otherwise happy
[02:06] <robert_ancell> aha, strace suggest the failure is actually to open /usr/lib/x86_64-linux-gnu/mir/client-platform/
[02:09] <duflu> robert_ancell: Try installing mir-graphics-drivers-desktop
[02:10] <duflu> I think there's a bug for that but it's also arguably a feature
[02:10] <robert_ancell> duflu, yeah, I'm looking at the Mir code so see how the error text could be clearer
[02:10] <duflu> I agree, our lack of useful error messages is an issue. There are one or two bugs for that.
[02:10] <robert_ancell> The issue is there's more than one thing that might not exist, so the error text needs to be clear
[02:11] <robert_ancell> ugh, I give up trawling the frontend code. Bug it is.
[02:13] <duflu> robert_ancell: A new bug is fine. Although I remember it was logged recently somewhere and ended up being won't fix/can't fix because you can't automatically determine the best driver package to have installed. We do however have: https://bugs.launchpad.net/mir/+bug/1381398
[02:14] <robert_ancell> yeah, they're the server side messages.
[02:14] <robert_ancell> The client side should be easier to fix
[02:14] <robert_ancell> bug 1473268
[02:23] <duflu> robert_ancell: Wait, what?! If your server is already running you must have graphics drivers installed...
[02:23] <duflu> You must have installed a working mir-platform-* to get the server driver but be missing the client driver package
[02:24] <robert_ancell> duflu, I had mir-platform-graphics-mesa2 installed but not mir-client-platform-mesa2
[02:24] <duflu> robert_ancell: Yeah OK, no problem.
[02:24] <duflu> robert_ancell: At last discussion this was labelled "not an issue" as our desktop-next metapackage has the required deps
[02:24] <duflu> But we can do better
[02:25] <robert_ancell> It would be fine if the error message actually indicated the mismatch
[02:25] <duflu> robert_ancell: Totally agree. Should be a simple enhancement
[02:28] <duflu> robert_ancell: Also I have had thoughts that "driver" should be a single package, not separate client/server.
[02:28] <duflu> Even a single binary
[02:28] <robert_ancell> Yeah, it would be nicer to have one package though I guess there are potential small gains in splitting?
[02:29] <duflu> robert_ancell: We can keep two binaries and still have a single package. But also code reuse (and hence total system memory used) might be reduced by a single binary
[02:30] <duflu> -reuse +duplication
[02:35] <duflu> robert_ancell: Incidentally, this week I was focussing on "bugs that users can actually see"
[03:34] <robert_ancell> duflu, do you know of an issue running mir_demo_server on wily and it crashing when a client connects with "*** stack smashing detected ***"?
[03:36] <duflu> robert_ancell: I am aware of only one stack smashable issue. That is apparently fixed in 0.13.3 and later - https://bugs.launchpad.net/mir/+bug/1465883
[03:37] <duflu> robert_ancell: Obviously first check if it's the client rather than Mir doing the smashing
[03:37] <robert_ancell> the message is on the servers stderr
[03:37] <robert_ancell> ah, I have a 0.14.0 version of libmirprotobuf it seems
[03:38] <duflu> robert_ancell: From memory you need the fix in libmirclient and libmirserver packages (0.13.3 and later)
[03:38] <duflu> Not libmirprotobuf, despite that being closely related
[03:39] <robert_ancell> duflu, I downgraded and that fixed it, thanks!
[03:39] <robert_ancell> btw fingerpaint is fun with a 10 fingers :)
[03:39] <duflu> robert_ancell: That's a worry if 0.14 caused issues
[03:39] <duflu> Yay, fingerpaint
[03:40] <robert_ancell> Should libmirclient8 0.13.3+15.10.20150617-0ubuntu1 with with libmirprotobuf0 0.14.0+15.10.20150701-0ubuntu1?
[03:41] <duflu> robert_ancell: I think so. But there might be bugs we're not aware of
[03:42] <duflu> If you can install them simultaneously then that's theoretically a supported combination. But not a guarantee that they will talk to each other (you might have multiple versions of a package installed too)
[04:18] <robert_ancell> RAOF, with DRI3 do you create a Pixmap then use DRI3BufferFromPixmap or do you create the buffer using some direct call to the driver and then use DRI3PixmapFromBuffer?
[04:27] <duflu> robert_ancell: He's on holiday for a week now
[04:27] <robert_ancell> ah
[04:27] <duflu> Although reading email on the go
[04:27] <duflu> sometimes
[10:02] <UukGoblin> hi :-)
[10:02] <UukGoblin> is there a way to run applications written for X11 under Mir?
[10:21] <anpok_> yes
[10:21] <anpok_> in wily the new package is called xmir .. on vivid it was xserver-xorg-xmir
[10:22] <anpok_> you bascially launch xmir with -mirSocket /path-to-your-mir-socket/ (i.e. /run/3201/mir_socket) and assign a display id and launch the x-application with that DISPLAY
[10:23] <anpok_> UukGoblin: depending on the mir shell in use you might need additional steps.. I believe for unity8 you need to append a --desktop-file-hint <path-to-a-desktop-file> if in doubt ask in #ubuntu-unity
[11:08] <UukGoblin> cool, thanks :-)
[16:22] <kgunn> alf_: i'm assumign the system setting for "lock screen timout" does not alter or change the dimming timer?
[16:22] <kgunn> (it's currently conflating lock with screen blank i think)
[16:23] <kgunn> so for 1 minute.... 50 bright, 10 sec dim
[16:23] <alf_> kgunn: the dimming timout is set to power-off timout - 10s
[16:23] <kgunn> ah...so fixed
[16:24] <alf_> kgunn: (by other components, we are not forcing it, our API is set_timeouts(dim, poweroff)
[16:26] <kgunn> alf_: for your ques 6 i think scenario 1 makes the most sense to me at least
[16:34] <alf_> kgunn: note: there was mistake in the description of (6) (fixed now), the initial trigger is a power key event
[16:34] <kgunn> sure
[19:54]  * kdub figures out how to tease apart BufferQueue
[20:05] <camako> \o/