[00:01]  * balloons wonders about specifying a delegate
[00:04] <balloons> ah-ha, yeppers
[00:04] <balloons> I think I got you elopio :-)
[00:05] <elopio> :) that's the kind of english that I don't get.
[00:06] <elopio> balloons: do you mean that you could add the objectNames, or that you couldn't?
[00:06] <balloons> elopio, lol :-) Yes, I believe I can add the objectnames by adding a delegate, and defining the listmodel
[00:06] <balloons> it sounds more confusing that it is..
[00:06] <balloons> let me confirm now
[00:06] <elopio> awesome.
[00:26] <balloons> woot
[00:26] <balloons> got it..
[00:26] <balloons> so you can grab the delgate by objectname and check there text values
[00:27] <balloons> or whatever you want
[00:30] <elopio> balloons: that's just what I want.
[00:30] <elopio> will you propose a merge against trunk that I can use as a prerequisite?
[00:30] <balloons> sure thing
[00:31] <elopio> balloons: oh, wait, no, because I already have a prerequisite.
[00:31] <balloons> elopio, I'll just pass you the qml
[00:31] <balloons> you can adjust your merge then
[00:31] <elopio> balloons: or propose your branch against mine.
[00:31] <elopio> whatever you prefer.
[00:32] <balloons> i'll push a branch, you merge to yours, commit and we'll go with your mp
[00:36] <balloons> shoot
[00:36] <balloons> the short version didn't work and i didn't commit the long one.. haha.. redoing
[00:37] <balloons> there is one caveat, it break internationalization, if I have to do the other way...
[00:39] <balloons> elopio, lp:~nskaggs/ubuntu-weather-app/optionselector-objectnames
[00:40] <balloons> I think I have to define the listmodels again, which breaks internationalization due to some weird thing with qt not liking me using non literal values
[00:41] <balloons> see if that's enough or not
[00:42] <elopio> balloons: I think that's not what I need, I might be explaining it bad. I need the option with text "Millimeters" to have an objectName="milimetersOption", or something like that.
[00:43] <balloons> yes elopio I know.. I'm going to have to add the listmodel's too
[00:43] <balloons> just sucks because it won't let me assign the internationalized strings
[00:44] <elopio> I think I need a break, I'm just going slower and slower.
[00:45] <elopio> and while the maguros are stuck, there isn't much I can do.
[00:45] <elopio> or do you need me now for something else thomi?
[00:46] <balloons> elopio, ok, pushed the version with listmodels
[00:47] <balloons> you can select like OptionSelectorDelegate, objectName = WindUnitsSelectorDelegate
[00:49] <balloons> you'll get multiple returns, you can check the text, and see which one is selected
[00:49] <balloons> selected  = True
[00:49] <thomi> elopio: sure, I'm just approving branches as they come up
[00:55] <elopio> I'm sorry balloons, I'll check it after a little rest.
[00:56] <elopio> be back in a while,
[01:29] <balloons> this bug sucks: https://bugreports.qt-project.org/browse/QTBUG-20631
[01:40] <balloons> elopio, alrighty, whenever you are back around. int'l string support works again.. ugh, so silly
[01:40] <balloons> that was my qml limit for the day
[02:30] <elopio> balloons: still around?
[02:45] <elopio> veebers: the keyboard tests failed: http://<IP_ADDRESS>:8080/job/autopilot-trusty-master/58/
[02:45] <elopio> can you please take a look? It might be because of this autopilot-trusty-master environment.
[02:46] <veebers> elopio: d'oh, sure can
[02:50] <elopio> thomi: I left rss and weather apps running on autopilot-trusty-master
[02:50] <elopio> I'm going to have dinner, and then I'll be back to check how they went.
[02:50] <thomi> cool
[02:50] <elopio> it's all updated on the etherpad in case you guys want to give them a push.
[02:51] <elopio> bbl.
[08:18] <DanChapman> morning all
[08:20] <elfy> hi DanChapman
[08:23] <DanChapman> hey elfy :-)
[08:25] <Noskcaj> hey DanChapman
[08:27] <DanChapman> Noskcaj, hey mate :-)
[08:27] <Noskcaj> Have you got time to finish off the testdrive gtk3 work? I'll try to port to python3 when you finish (breaks quickly), so it's probably not worth starting from scratch like you did. All that still needs doing should be fixing glade's files and adding gsettings
[08:29] <DanChapman> Noskcaj, I've just got to take my boy to school can i talk to you about it when i get back?
[08:30] <Noskcaj> DanChapman, Sure, as long as i'm not asleep then
[08:30] <Noskcaj> bye
[09:52] <DanChapman> jibel, hey i read on yesterdays logs you had some concerns with the ubiquity tests picking a random language each time. Would it be better if I was to create a 2 testcases for each scenario 1 in english and the other picks a random language??
[10:58] <davmor2> Morning all
[14:06] <elopio> hello everybody.
[14:06] <TheLordOfTime> o/
[14:12] <davmor2> morning elopio
[16:04] <elfy> DanChapman: does autopilot work with thunderbird? lderan is too scared to ask :p
[16:06] <balloons> elfy, I get Gtk-Message: Failed to load module "autopilot"
[16:06] <DanChapman> elfy it does but only using process manager which means we are unable to introspect it like other autopilot tests and can only check things like the window title and window visible etc.
[16:06] <balloons> so I would say no introspection support
[16:07] <elfy> thanks guys :)
[16:07] <elfy> probably the same with mousepad then - I think was the same issue
[16:08] <balloons> autopilot launch -i Gtk leafpad
[16:08] <balloons> Gtk-Message: Failed to load module "autopilot"
[16:08] <elfy> I can see us getting a lot of that :)
[16:09] <elfy> on another related note - how's autopilot and images looking for the likes of us?
[16:09] <DanChapman> same with mouspad "Gtk-Message: Failed to load module "autopilot""
[16:09] <balloons> elfy, thunderbird is not a surprise butthe others are
[16:09] <balloons> might be able to fix those with some investigating
[16:09] <elfy> balloons: cool
[16:10] <DanChapman> is mousepad gtk2?
[16:14] <elfy> I thought gtk3 - but I could be wrong
[16:14]  * elfy really ought to do himself a list
[16:20] <lderan> DanChapman & balloons thank you :)
[16:20] <DanChapman> Your welcome lderan :-)
[16:20] <balloons> not sure what I did ;-) but you are most welcome
[16:23] <DanChapman> elfy i missed your question just then. Last i read on image testing for your lot was jibel was activating it yesterday.  I'm not sure what the status is on that today though
[16:23] <elfy> aah yes - I remember seeing that now - sorry
[16:24] <DanChapman> :-)
[16:24] <elfy> I don't even know where to go to see results lol
[16:24] <DanChapman> elfy, https://jenkins.qa.ubuntu.com/job/autopilot_ubiquity-devel/
[16:26] <elfy> DanChapman: thanks
[16:27] <DanChapman> elfy no problem. Thats the ones that are running atm. When the ones for the flavors come up i'll send you the link :-)
[16:28] <elfy> woohoo :)
[16:32] <balloons> DanChapman, re: language.. yes english + random
[16:32] <balloons> imho
[16:33] <DanChapman> balloons, ok mate easy enough to do
[16:33] <balloons> great.. jibel can toss in, but I believe that was the idea.. having an english install keeps things consistent between tests
[16:52] <elopio> balloons: they merged the weather without your objectName changes. I think now it would be good to wait for the optionselector emulator, and fix it in the nicest way possible
[16:52] <elopio> what do you think?
[16:52] <balloons> elopio, I saw that :-(
[16:54] <balloons> as far as the emulator, wouldn't you still need to define the objectnames?
[16:55] <elopio> balloons: yes. We need both. So what I'm asking is if you want me to continue your object names branch and merge it today, or would you prefer to wait for the emulator and do the objectNames+emulator when it's ready.
[16:56] <balloons> elopio, I'd put it in now, may as well.. in case any work is done in that section of the qml
[16:56] <balloons> leaving it out means it may not merge clean later
[16:58] <elopio> balloons: ok, I'll grab your branch now or I will forget.
[16:59] <elopio> balloons: today and tomorrow I'll be cleaning tests everywhere I can :D If you want something, assign a bug to me.
[17:09] <balloons> elopio, ;-) got t
[17:55] <TheLordOfTime> balloons: ping
[17:55] <TheLordOfTime> has that session RE: bugsquad/QA merging had a specific time/date set?
[17:56] <balloons> TheLordOfTime, setting it now.. and I'm expanding the session list as it's been pointed out I was thinking rather superhumanly that I could get the whole agenda done in one session
[17:56] <elfy> http://summit.ubuntu.com/uds-1311/meeting/21987/community-1311-quality-bugsquad/
[17:56] <balloons> http://summit.ubuntu.com/uds-1311/meeting/21987/community-1311-quality-bugsquad/
[17:56] <elfy> ahah - didn't see you there balloons :)
[17:56] <balloons> lol.. that was in sync
[17:56] <elfy> spooky
[17:58]  * elfy should be about (ish) on the Tuesday/Wednesday - try and get a bit more involved this year - as much as is possible with only IRC
[17:59] <TheLordOfTime> balloons: awesome, now that this is on my calendar i can see i have to be awake before 2.
[17:59] <TheLordOfTime> which is easy.
[17:59] <balloons> elfy, IRC works fine ;-) just having you around would be lovely
[17:59] <elfy> balloons should tell the rest of the people in his team that if they aren't talking then they should be checking IRC channels as people often get ignored ;)
[18:00] <elfy> well - it does up to a point :)
[18:00] <balloons> it's hard to multi-task sometimes if I'm doing the talking as well
[18:00] <balloons> but I'm getting better
[18:00] <elfy> I wasn't saying you :)
[18:01] <elfy> tbh - anyone on any of these sessions who's there on video that isn't talking should be aware of IRC :)
[18:01] <elfy> balloons: there - does that sound like I'm not pointing fingers now :)
[18:02] <balloons> elfy, lol.. I speak only for me
[18:02] <elfy> usually when I say something on IRC - it get's noticed too late and the talkers are then talking about something else
[18:02] <balloons> no finger pointing felt
[18:02] <elfy> probably should have said this in #u-c-t :)
[18:05] <elfy> so I did :)
[18:05] <balloons> nice
[18:07] <elfy> I think that makes sense :)
[18:08]  * elfy keeps thinking about getting a webcam - but the cost of getting a balaclava at the same time just tips it over the edge :)
[18:16] <balloons> elfy, I'll kindly remind you that you can join audio only
[18:16] <balloons> webcam is not required.. but a mic is :-)
[18:17] <elfy> yep - I know that - then I'd have to buy earplugs ... :)
[18:17] <balloons> elfy, TheLordOfTime see my last email to the qa list for an updated look at the sessions
[18:17] <elfy> when I actually do it - I'll do both :)
[18:17] <balloons> let me know if it makes sense :-)
[18:18] <elfy> stupid tbird filters - mails are in -release ...
[18:21] <phillw> balloons: ping
[18:21] <balloons> phillw, pong
[18:21] <elfy> balloons: looks fine to me - though "Let's talk about revamping calls for testing to let everyone in the community schedule there own" doesn't make sense unless you're mother tongue is English and you read the sentiment rather than the sentence
[18:21] <balloons> mmm.. well noted.. thank you
[18:22] <phillw> balloons: with the dropping of cadence from ubuntu, are you going for the alpha / beta stream, or just testing "whenever" until RC?
[18:23] <phillw> btw, hi elfy I also hope you are well!
[18:24] <elfy> hey phillw - I'm almost always well - I trust you are kicking too :)
[18:24] <balloons> phillw, I hope this is thoroughly covered and communicated in exploratory testing session, https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-community-exploratory-testing, however yes
[18:25] <balloons> in other words.. I'd like to have people testing all of the time, all cycle
[18:25] <balloons> and using the release as there daily driver
[18:25] <phillw> balloons: and for the flavours who prefer milestones?
[18:25] <balloons> also allowing for people to schedule there own calls for testing, so rather than cadence weeks, perhaps we'll have more special calls for testing
[18:25] <balloons> https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-calls-for-testing
[18:26] <balloons> phillw, for flavors on milestones, nothing changes.. you will do your milestones as usual..
[18:26] <balloons> as will ubuntu ofc
[18:26] <balloons> we simply opt out of the earlier ones
[18:26] <elfy> HA - I'm trying to sort out cadence type testing for us lol
[18:26] <balloons> i think that is a sane enough way to think of it
[18:27] <elfy> which is more than we've done before
[18:27] <elfy> I sort of hope to get people on the packages.qa bandwagon and just test test test
[18:27] <phillw> elfy: I tried it with lubuntu, it was a big failure. nothing like a dead line to stir the testers into action :)
[18:27] <balloons> elfy, yep
[18:28] <elfy> so - a bit of the old and a bit of let's try this for us and see how it goes
[18:28] <balloons> you might consider pushing exploratory testing, using the release all the time, and then have specific calls for testing
[18:28] <balloons> aka, like milestones for packages
[18:28] <balloons> heh
[18:28] <elfy> phillw: well we did get all the package testing we'd asked for done
[18:28] <balloons> ^^ rather impressively
[18:29] <elfy> balloons: from our point of view - we are going to have very specific things land needing testing - but mostly it is abouit get more than 20 people testing stuff
[18:29] <phillw> balloons: elfy as package testing <> iso testing, when a new release of a package arrives, it is justifiable to ask for a test of it.
[18:29] <elfy> I'm trying to look ahead at the same time as deal with LTS
[18:29] <elfy> phillw: up to a point
[18:30] <elfy> we want more people testing - more people = different ways of using an app
[18:30] <elfy> a test can only cover so much
[18:31] <elfy> so ... constant testing/specific tests for specific issues/someone available to fix them
[18:31] <elfy> it's really about eyes
[18:31] <phillw> elfy: as balloons just said, do we have more than 20 testers to descend on a test? I think not, certainly for the flavours. Smoke testing, however, is a better route IMHO.
[18:33] <elfy> well I plan to have more than 20 by the time LTS releases
[18:33] <phillw> for 14.04 lts, we need some sort of 'stable' pre-release (alpha) and get people to actually USE it, not try to write tests :)
[18:33] <elfy> I do not want Xubuntu to release with something like the sound indicator issue again
[18:33] <elfy> phillw: agreed :)
[18:34] <elfy> we'll not be writing tests :)
[18:34] <phillw> elfy: we had issues with lubuntu as well :) http://ubuntuforums.org/showthread.php?t=2182038
[18:35] <phillw> stuff that we never smoke tested.
[18:35] <elfy> oh I know other's had issues - but they are, while important, not as much so to me :)
[18:38] <phillw> I had only the zram issue which was solved.. It is not until people actually start using the release do we find out that all the work on auto-tests etc. count for nothing as they can not simulate "real life" :D
[18:38] <phillw> Never try to 2nd guess a user :P
[18:39] <elfy> indeed - it's trying to get the few happy to run a dev and released version at the same time
[18:39] <phillw> good evening from the UK Noskcaj
[18:39] <elfy> takes someone willing to play with fire a bit - at least someone without a /home ;)
[18:39] <elfy> hi Noskcaj
[18:40] <elfy> I'll be running tahr properly next time I get week off
[18:41] <phillw> elfy: IMHO, I do think that is doable...
[18:43] <elfy> I do as well with some cajoling
[18:43] <phillw> elfy: these were my thoughts, which got copied over... https://wiki.ubuntu.com/QATeam/Overview/TheStages
[18:44] <phillw> we do now have a decent set of instructions for using VM's.
[18:45] <phillw> goes and fines some super-glue for Noskcaj
[19:00] <balloons> the goal with exploratory testing is to get more eyes on the release sooner..
[19:00] <balloons> there's no reason to not be running trusty right now for quality team members :-)
[19:03] <elfy> there is here balloons - I've not had time to set up the media mount properly ...
[19:07] <TheLordOfTime> thanks for the +1 on my answer about private bug triage, on Ask Ubuntu, elfy xD
[19:07] <TheLordOfTime> sorry to add noise, though, to the channel :)
[19:08] <qengho> phillw: Heya. I'm interested in getting help testing chromium-browser for stable releases.
[19:09] <qengho> phillw: I've been using the distro development edge to look for and fix problems, but that doesn't get the right bug reports to me quickly enough.
[19:09] <qengho> phillw: Have any advice?
[19:11] <elfy> TheLordOfTime: welcome :)
[19:12] <phillw> qengho: I'm only a tester now! But... the guy looking after chromium is a good guy from my previous involvements with him.  https://launchpad.net/~chromium-daily/+archive/stable Chad is his name, and from memory, he would like people to test and report back. I always do.
[19:13] <elfy> TheLordOfTime: it actually is ontopic in here anyway :)
[19:16] <TheLordOfTime> indeed.
[19:16] <TheLordOfTime> elfy: i quoted information and put it there, but the wiki and "HOw to Triage" is the best guide out there
[19:17] <elfy> aaand really easy to read ;)
[19:17] <qengho> phillw: Oh, er, I'm Chad.  And thanks.  :)
[19:18] <elfy> TheLordOfTime: just saying :p
[19:18] <elfy> qengho: lol
[19:19] <TheLordOfTime> elfy: heheh
[19:19] <TheLordOfTime> elfy: true.  The answer on AskUbuntu is a TL;DR version of the how to triage guide xD
[19:21] <phillw> qengho: oops! But I will continue to test chromium for you :)
[19:22] <TheLordOfTime> at least, specifically for crash bugs
[19:22] <elfy> yep
[19:22] <TheLordOfTime> IDK about security bugs or other projects, because i'm not on the security team, and because other projects have their own guidelines xD
[19:23] <elfy> :)
[19:23] <phillw> qengho: I'm currently on Version 30.0.1599.114 Ubuntu 13.10 (30.0.1599.114-0ubuntu1~cm0saucy) do you want me to try a newer version?
[19:24] <qengho> phillw: hah, thank you.  I'm going to try to get most recent LTS and most recent stable release updated really often in a place where I can just hand tested results to security team to release.
[19:26] <phillw> qengho: I did install 14.04 pre-alpha today for lubuntu, let me just fire it up and see what version it has
[19:28] <phillw> qengho: ah, we switched back to firefox! Would it be helpful for me to install it and check what version it is on?
[19:30] <qengho> phillw: Well, for now that'd be precise and saucy that I'm most interested in.  I'm dev/trusty at least has my eyes already.
[19:32] <phillw> qengho: I'm running 13.10 as my system (have been since alpha 1 was passed for smoke testing). The only issue I have with chromium is that it has run-aways in CPU usage with facebook.
[19:33] <qengho> phillw: huh.  Report that Facebook problem?  Shift-ESC to list processes.
[19:34] <qengho> My Facebook tab gets 2% to 0% CPU.
[19:34] <phillw> qengho: I just kill the process and restart the tab :)
[19:43] <elopio> balloons, robotfuel: review please: https://code.launchpad.net/~elopio/ubuntu-weather-app/fix1248648-options_object_names/+merge/194217
[19:44] <robotfuel> elopio: this is for 1.3?
[19:45] <elopio> robotfuel: no, 1.4.
[19:45] <elopio> ahh, right, it's full of Eventually(Is(Not(None))) I need to clean that up too.
[19:46] <robotfuel> self.assertThat(lambda: self.main_window.select_single('OptionSelector', objectName='TemperatureUnitsSelector'), Eventually(Not(Is(None)))) should just be wait_select_single
[19:46] <elopio> robotfuel: I'll clean that in a different branch so we keep issues separate.
[19:48] <balloons> :-)
[19:49] <balloons> elopio, makes sense.. one thing at a time
[19:49] <robotfuel> elopio: I don't like that it's using an index
[19:49] <elopio> balloons: I basically reordered the things you had. How can I be sure if I'm not screwing the i18n ?
[19:50] <robotfuel> elopio: can you give an object name to the item in the option selector?
[19:50] <elopio> robotfuel: index where? That's precisely what I'm trying to avoid.
[19:50] <robotfuel>  current_option = units_selector.select_many('ShapeItem')[1]
[19:51] <robotfuel> for example
[19:52] <elopio> robotfuel: yes, that's bad. But again, I would prefer that for a future clean up.
[19:52] <elopio> I would like to split the tests, and get most of those methods on a settings page emulator.
[19:52] <balloons> elopio, I see.. I too had tried to re-use a generic unitsSelectorDelegate but had trouble with it
[19:52] <robotfuel> elopio: ok
[19:53] <balloons> elopio, the int'l thing is that you need to translate in the delegate.. that was the magical secret. listelements can't use functions to set properties
[19:53] <balloons> too me awhile to come around to that conclusion :-)
[19:53] <dkessel> good evening
[19:54] <balloons> dkessel, guten tag
[19:54] <dkessel> guten abend balloons
[19:54] <balloons> guten abend I suppose
[19:54] <balloons> :-)
[19:54] <dkessel> yay, new indicator package updates... finally =D
[19:55] <dkessel> and lightdm... +1 :)
[20:03]  * slickymaster is away: (Dinner time)
[20:03] <elopio> balloons: I would also like to get reviews from the app devs, so they know how and why we are cleaning things.
[20:03] <elopio> who can I get from the weather app?
[20:03] <balloons> elopio, mbo is the man for weather
[20:03] <balloons> let's ping him
[20:03] <balloons> not around :-(
[20:04] <balloons> we can email him
[20:04] <elopio> balloons: thanks, I'll send an email.
[20:04] <balloons> elopio, need the email?
[20:04] <elopio> balloons: I can dig for it on launchpad. No need to take more of your time :)
[20:11] <elopio> balloons: would it be a good policy to have an approval from one QA and one dev on every branch?
[20:11] <elopio> or would it be too slow?
[20:14] <balloons> elopio, we should think about that.. for this 1.4 stuff, let's get it in
[20:14] <balloons> moving forward, I think it would be good
[20:15] <balloons> in the past it's been 50/50.. I don't see every merge that doesn't affect tests and vice versa for devs
[20:18] <elopio> ok, I suppose this is part of the things we will try this cycle focusing on two projects at a time.
[20:19]  * elopio eats.
[20:28] <balloons> dkessel, still on saucy right?
[20:28] <dkessel> balloons, yup... I am. why are you asking?
[20:30] <balloons> just curious.. I'm not going to ask you to jump through any hoops ;-)
[20:30] <balloons> gonna be able to make the vUDS stuff?
[20:31] <dkessel> the vUDS stuff ?-)
[20:32] <dkessel> oh i see.
[20:32] <dkessel> no i guess not... i have to work
[20:33] <balloons> :-( That work thing
[20:34] <dkessel> so now I placed a reminder in my calendar to review the videos/results after it :)
[20:35] <balloons> dkessel, that works too.. feel free to add comments in advance on the blueprints or pad
[20:35] <dkessel> ok fine :)
[20:38] <balloons> hehe.. I value your opinion..
[20:39] <balloons> Letozaf_, buonasera
[20:39] <Letozaf_> balloons, buonasera
[20:39] <balloons> come stai?
[20:40] <Letozaf_> balloons, :-) bene e tu ?
[20:40] <balloons> bene :-)
[20:40] <balloons> rss reader treating you well?
[20:41] <Letozaf_> balloons, no :(  I merged this evening before continuing yesterday's work and found some new failures, I'm trying to fix them :P
[20:42] <dkessel> balloons, is this about usb-creator-gtk? https://wiki.ubuntu.com/ubuntu-usb-startup-creator
[20:43] <balloons> dkessel, heck ya.. cool stuff huh?
[20:44] <dkessel> balloons, mh. well... partly :) improving the usability - yes. not allowing me to create booting usb devices from other linux OS'es - definately no
[20:48] <balloons> well, this is a community proposal.. I didn't catch the plan to only support ubuntu and nothing else
[20:48] <dkessel> i like the "making stuff easier idea" - but the unetbootin approach also has a plus... maybe it would be possible to talk with the authors if they would accept a "simple mode"
[20:48] <balloons> certainly the ubuntu use case is the primary one
[20:49] <balloons> anyways, do add your thoughts to the proposal
[20:49] <balloons> we'll discuss them
[20:49] <balloons> Letozaf_, how's about you? going to be able to make vUDS?
[20:50] <dkessel> balloons, yes it is a community proposal :) I'll comment on it
[20:50] <Letozaf_> balloons, hope so, maybe I will be a little late but I won't miss
[20:51] <balloons> me <3's community proposals.. especially such nice ones
[20:51] <balloons> Letozaf_, wonderful
[20:52] <Letozaf_> balloons, :D
[21:14] <dkessel> see you the other day :) gute nacht / buena notte (?) :)
[21:20] <Letozaf_> balloons, I see that wait_select_single has been put in rssreader app tests, but I am still using autopilot 1.3 is that ok, or do I have to use autopilot 1.4 ?
[21:21] <balloons> Letozaf_, yep ap 1.4 is needed now
[21:21] <Letozaf_> balloons, autopilot 1.4 is not out yet I think
[21:21] <thomi> Letozaf_: you need to use autopilot 1.3
[21:21] <thomi> 1.4!
[21:21] <balloons> lolo
[21:21] <balloons> thomi, I did a doubletake
[21:21] <thomi> sorry :)
[21:21] <thomi> 3 and 4 are so close to each other on this keyboard ;)
[21:21] <Letozaf_> balloons, so that wait_select_single is wrong I suppose
[21:21] <Letozaf_> thomi, :D
[21:22] <Letozaf_> balloons, it's supposed to be used in 1.4
[21:22] <thomi> Letozaf_: well, not really - we need all the apps to be compatible with 1.4 before we can release 1.4 itself
[21:22] <thomi> that should happen in the next 24 hours *i hope*.
[21:22] <thomi> Letozaf_: in the mean time, you can get 1.4 by adding ppa:autopilot/experimental
[21:24] <Letozaf_> thomi, so I should fix rssreader app tests using 1.4 now ? ok, I thought I had to use 1.3
[21:24] <thomi> Letozaf_: yes - although there may already be an rssreader 1.4 branch... let me check...
[21:24] <balloons> sorry Letozaf_ if I confused you
[21:24] <thomi> Letozaf_: ahh, it already landed
[21:25] <Letozaf_> balloons, not matter
[21:25] <thomi> Letozaf_: so yeah - we ought to talk about rssreader tests :)
[21:25] <thomi> they fail in CI often because they try and fetch a real RSS feed
[21:25] <thomi> ideally, we'd mock out the external server, so they can run without any network access
[21:26] <Letozaf_> thomi, balloons ok but if I branch rssreader-app tests now, are these tests for 1.4 or 1.3 ?
[21:26] <thomi> Letozaf_: 1.4
[21:26] <Letozaf_> thomi, ah ok
[21:26] <thomi> everything (almost) is 1.4 now, we're just cleaning up the last few projects
[21:27] <Letozaf_> thomi, balloons ok thanks :D I was working with 1.3 wonder why everything was weired
[21:27] <Letozaf_> lol
[21:34] <elopio> Letozaf_: do you know if the rss will work if we add a path to an rss.xml in the local file system instead of the on in canonical.com?
[21:35] <elopio> I'll just give it a try.
[21:35] <Letozaf_> elopio, nope never tried, sorry :P
[21:37] <elopio> Letozaf_: it doesn't work. I think that's where we should start, asking the devs to support also file:// urls.
[21:38] <Letozaf_> elopio, honestly I never used local feeds, do you use them ?
[21:39] <elopio> Letozaf_: no, I don't. But that will improve testability a lot letting us test most of the functions with no internet connection and no server.
[21:39] <Letozaf_> elopio, oh! clear I understand
[21:39] <elopio> most tests will be faster and simpler.
[21:39] <Letozaf_> elopio, so yes it would be a good idea
[21:40] <balloons> so we could include a test file feed with the tests
[21:40] <Letozaf_> balloons, elopio sounds good
[21:41] <elopio> balloons, Letozaf_, even better, create it on the fly on the test set up.
[21:41] <elopio> and then we can modify it on the fly for tests checking updates on the feed.
[21:41] <balloons> ahh, yes, that works nicely too
[21:41] <balloons> hehe
[21:46] <elopio> balloons, Letozaf_: https://bugs.launchpad.net/ubuntu-rssreader-app/+bug/1248737
[21:47] <elopio> do you know how are the priorities set for this project? It would be great if we can convince the devs to give it a high importance.
[21:50] <balloons> I set it high, I'll ping the devs to look
[21:53] <Letozaf_> balloons, elopio have you tried rssreader app's tests on a desktop or only on a device ?
[21:54] <elopio> Letozaf_: I have tried them in trusty desktop, and in trusty nexus 4.
[21:55] <elopio> they all pass for me, but they might be unstable on CI because they are a little too big, and because of the internet dependency.
[21:55] <Letozaf_> elopio, I also have tried them on trusty desktop, but do they work for you ? I have the toolbar acting funny
[21:55] <elopio> thanks balloons.
[21:55] <balloons> Letozaf_, no, they don't work on the desktop
[21:55] <elopio> Letozaf_: oh, I tried them yesterday.
[21:55] <balloons> the app doesn't work on the desktop for me
[21:55] <balloons> sorry i meant to say that
[21:55] <elopio> let me run them again.
[21:55] <balloons> i think i'm unique though, others don't seem to be affected
[21:56] <Letozaf_> balloons, oh! I feel better now, I ran them with trusty and autopilot 1.4
[21:56] <Letozaf_> balloons, but the toolbar acts strange
[21:56] <Letozaf_> balloons, what problems have you got on the desktop?
[21:57] <elopio> yeah, they don't work today.
[21:58] <Letozaf_> elopio, ok so I'm not the "only one" :P
[21:58] <elopio> Letozaf_: it seems we are assuming that the toolbar will be visible after entering the feed URL
[21:58] <elopio> so it will try to click a button that's outside of the window.
[22:00] <Letozaf_> elopio, yes looks like
[22:00] <Letozaf_> well guy's it's late for me now, going to bed see you tomorrow! night!
[22:01] <elopio> Letozaf_: good night.
[22:08] <alesage> does anyone know, what's the best way in Python to just snoop on D-Bus to listen slash ensure that a signal has been generated?
[22:08] <alesage> where by 'best' I mean requiring the least effort to set up :)
[22:11] <balloons> alesage, that's definitely a thomi question
[22:28] <thomi> hmmm?
[22:29] <thomi> alesage: use python-dbus and connect to the signal in question?
[22:29] <alesage> thomi will try thx
[23:10] <elopio> Can somebody reproduce this bug 1248759 ?
[23:13] <elopio> ubuntu-qa? someone still around? ^
[23:14] <veebers> elopio:
[23:14] <veebers> elopio: err, my device is just flashing. I can try when it's complete
[23:15] <elopio> veebers: you can try it on your desktop.
[23:15] <elopio> branch lp:ubuntu-rssreader-app
[23:15] <veebers> elopio: ah right, will try now
[23:30] <veebers> elopio: I can reproduce that bug
[23:31] <elopio> veebers: thank you.


[08:25] <TheMue> re
[09:12] <niemeyer> Good morning all!
[09:18] <TheMue> niemeyer: hiya
[09:30] <fwereade__> heya niemeyer, you're on early :)
[09:30] <niemeyer> fwereade__: Yeah, a bit :)
[09:46]  * rog finally makes his network connection work again
[09:47] <niemeyer> rog: Welcome back
[09:48] <rog> niemeyer: hi!
[09:49] <rog> niemeyer: you're up earlier than usual...
[09:49] <TheMue> rog: hiya
[09:49] <rog> TheMue: morning!
[09:50] <niemeyer> rog: Yeah, a bit
[09:50] <rog> niemeyer: any chance you could have another look at those CLs? i'm hoping to get something pushed this week.
[09:52] <niemeyer> rog: Not right now
[09:52] <rog> niemeyer: k
[09:55] <fwereade__> niemeyer, btw, there was a conversation the other day I think you missed about gozk panicing in C when a Conn is closed (and something else is busy in C code)
[09:55] <niemeyer> fwereade__: Ugh, that's not good
[09:55] <fwereade__> niemeyer, would fixing this just be a matter of a RWMutex on handle accesses, or is it more subtle?
[09:55] <niemeyer> fwereade__: Well.. I'd need some more information about the crash
[09:57] <fwereade__> niemeyer, I've seen it in a couple of cases, but the common feature is that some goroutine is always somewhere like: launchpad.net/gozk/zookeeper._C2func_zoo_wexists(0x36edf80, 0x36ef380)
[09:57] <niemeyer> fwereade__: Ok, do you have a full traceback?
[09:58] <fwereade__> niemeyer, here's the one I just saw
[09:58] <rog> niemeyer: i had a brief look at this - it just happens when zk derefs the nil handle, because handle access isn't mutexed, as fwereade__ suggestes
[09:58] <fwereade__> niemeyer, http://paste.ubuntu.com/855178/
[09:58] <rog> suggests
[09:59] <fwereade__> niemeyer, the set line shouldn't be the problem, because that conn is not closed
[10:01] <niemeyer> fwereade__: Is this looping while you're calling Close on the zk Conn?
[10:01] <fwereade__> niemeyer, yes
[10:02] <niemeyer> fwereade__: That's going back to the point we talked about
[10:02] <niemeyer> fwereade__: We shouldn't do that
[10:02] <niemeyer> fwereade__: We shouldn't ever close a connection behind the back of logic that we're managing ourselves
[10:03] <fwereade__> niemeyer, ok, maybe I'm missing something
[10:03] <niemeyer> fwereade__: That's true for tests, and also for real logic
[10:04] <niemeyer> fwereade__: We can even implement locking to prevent the nil pointer reference at some point, but that's not the most critical issue
[10:04] <niemeyer> fwereade__: Ok, but do you recall that conversation?
[10:04] <fwereade__> niemeyer, ok, in that case I guess the tests I was trying to write are not actually relevant, because I'm really trying to test deal-with-session-event handling that doesn't exist yet
[10:05] <niemeyer> Feb 22 12:09:11 <niemeyer>      fwereade_: We should never, ever, ever, leave background logic unattended while we're messing around with the  system state in disruptive ways
[10:05] <niemeyer> fwereade__: Hmm, can you expand on that?
[10:05] <fwereade__> niemeyer, yes, I do; the reason I saw this one just now is because all I *thought* I had active on that conn was a watch
[10:06] <fwereade__> niemeyer, I was trying to verify that the watch channel got closed when the underlying ZK connection got yanked out from underneath
[10:06] <niemeyer> fwereade__: Ok, that's an interesting case.. maybe we have something to fix then
[10:06] <niemeyer> fwereade__: Can you please paste waitFor?
[10:07] <fwereade__> niemeyer, http://paste.ubuntu.com/855189/
[10:09] <niemeyer> fwereade__: Sorry, I thought that was where the loop was.. TestDisconnectAliveWatch then, I guess
[10:10] <niemeyer> Ah, this is the guy blowing up: launchpad.net/gozk/zookeeper._C2func_zoo_set2(0x0, 0x36ef360)
[10:10] <fwereade__> niemeyer, yep
[10:10] <niemeyer> fwereade__: Please paste the test and (*Pinger).run
[10:10] <fwereade__> niemeyer, before I paste this: I know the stuff in the goroutine comment is wrong :p
[10:10] <fwereade__> niemeyer,
[10:10] <fwereade__> http://paste.ubuntu.com/855193/
[10:11] <niemeyer> fwereade__: Cool :)
[10:11] <fwereade__> niemeyer, http://paste.ubuntu.com/855195/
[10:13] <fwereade__> niemeyer, wait, you're right, it is set and not exists, bugger, I'm at least partially on crack (in a way that I was not hitherto aware of)
[10:13] <niemeyer> fwereade__: You know it's wrong in which way?
[10:13] <fwereade__> niemeyer, "this should be equivalent"
[10:16] <fwereade__> niemeyer, ie, what we should actually be doing is *not* just closing the conn until we've dealt with everything
[10:17] <fwereade__> niemeyer, but if it is indeed the set that's blowing up, anmd it looks like it is, then I'm completely confused because that's using a different conn to the one that gets closed
[10:17] <niemeyer> fwereade__: Not really
[10:17] <niemeyer> fwereade__: Oh, wait.. yes
[10:18] <fwereade__> niemeyer, so I would appear to be crackful in an entirely fascinating and original way :/
[10:18] <niemeyer> fwereade__: But!
[10:18] <niemeyer> fwereade__: Please paste Close
[10:18] <niemeyer> fwereade__: I bet you have a race
[10:18] <fwereade__> niemeyer, oh balls, I try to hit the target node again
[10:19] <fwereade__> niemeyer, (to give clients as long a time as possible before they see a timeout)
[10:19] <fwereade__> niemeyer, (naively trusting that if the connection is borked it'll just error and I can ignore it)
[10:19] <niemeyer> fwereade__: That's fine
[10:20] <niemeyer> fwereade__: But a race is not fine.. please paste Close
[10:21] <TheMue> Interesting, http://cocode.io/beta/ will provide collaborative coding. It's written in Go knows Go as a highlighted lang. Sadly yet only GitHub, no Bazaar (or others).
 fwereade_: That's fine
 fwereade_: But a race is not fine.. please paste Close
[10:23] <niemeyer> fwereade_, fwereade__: Are you having wifi issues too?
[10:23] <niemeyer> fwereade_, fwereade__, fwereade: Are you having wifi issues too? :-)
[10:23] <fwereade> niemeyer, seems so :p
[10:24] <fwereade> niemeyer, http://paste.ubuntu.com/855206/
[10:24] <fwereade> niemeyer, if you didn't see above
[10:24] <niemeyer> fwereade_, fwereade__, fwereade: I always knew you were not a single person..
[10:24] <niemeyer> fwereade: Yeah, you have a race indeed
[10:25] <niemeyer> fwereade: Can you please have a look at this post: http://blog.labix.org/2011/10/09/death-of-goroutines-under-control
[10:25] <fwereade> niemeyer, I'm a globally distributed collection of outsourced drones, but don't tell anyone
[10:25] <niemeyer> fwereade: I'll highlight a few things afterwards, if they're not obvious
[10:25] <fwereade> niemeyer, cool, thanks
[10:25]  * fwereade reads
[10:27] <rog> niemeyer: where's the race?
[10:28] <fwereade> niemeyer, I remember reading that when you wrote it, and totally forgot about it until now
[10:28] <fwereade> niemeyer, it seems clear, but I'd appreciate the highlighting all the same
[10:31] <rog> oh yeah, in TestDisconnectAliveWatch. i was looking in the pinger methods
[10:36] <fwereade_> grar
[10:37] <niemeyer> fwereade_: Are you here? :)
[10:38] <fwereade_> niemeyer, er, probably
[10:38] <niemeyer> fwereade_: Ok :)
[10:38] <niemeyer> fwereade_: So, quicklY! :-)
[10:38] <niemeyer> fwereade_: Observe the way Stop is implemented in the blog post
[10:39] <niemeyer> fwereade_: It sends a fatal error, and *waits*
[10:39] <TheMue> niemeyer: next round of https://codereview.appspot.com/5671055/
[10:39] <niemeyer> TheMue: Thanks, I'll have a look at that next to rog's
[10:39] <TheMue> niemeyer: yep, thx
[10:40] <niemeyer> fwereade_: You're sending a stop signal, and ignoring the fact that, naturally, stopping isn't instantaneous
[10:40] <fwereade_> niemeyer, yeah; I had a "closed" channel I was waiting on originally, but it was pointed out that since closing was unbuffered I wasn't getting any benefit from waiting on closed after sending to closing
[10:41] <niemeyer> fwereade_: Uh.. this is bogus
[10:41] <niemeyer> fwereade_: Oh, or maybe not.. let me see again
[10:41] <rog> niemeyer: it looked ok to me :-)
[10:41] <fwereade_> niemeyer, I'm not saying there weren't subtle bugs in what I was doing, or in what I am doing ;)
[10:42] <rog> niemeyer: i *hope* it's not bogus otherwise my understanding of channels is fundamentally flawed...
[10:43] <niemeyer> rog: No, you're right.. as long it's unbuffered, that's fine
[10:43] <rog> phew
[10:44] <niemeyer> fwereade_: The race is in the test itself
[10:44] <rog> yup
[10:44] <niemeyer> fwereade_: No, sorry.. crack again..
[10:45] <niemeyer> altConn is in a different end
[10:45] <niemeyer> Hmm
[10:46] <rog> niemeyer: isn't is a race that waitFor(c, altConn, path) is called concurrently with altConn.Close() ?
[10:46] <rog> (not that i've looked at waitFor)
[10:47] <niemeyer> rog: No.. the pinger is blowing up with a nil handle
[10:48] <niemeyer> Despite anything else, there's a race here in that the handle is being cleaned up underneath its feet
[10:48] <rog> niemeyer: that still looks like a race to me
[10:48] <niemeyer> rog: :-)
[10:48] <rog> niemeyer: even if it's not the thing that's blowing up
[10:49] <niemeyer> rog: If the logic in the test is sane, the Close won't happen before the kill
[10:50] <niemeyer> rog: if..
[10:51] <rog> niemeyer: oh yes, i hadn't seen connect - i was assuming that the session event was the connection event, not the teardown event.
[10:51] <rog> but presumably connect waits for the first session event
[10:51] <fwereade_> rog, yes
[10:51] <niemeyer> rog: That's what I'm assuming too
[10:56] <rog> fwereade_: how reproducible is this?
[10:56] <fwereade_> rog, not very :(
[10:56] <fwereade_> rog, it'll happen eventually
[11:00] <rog> fwereade_, niemeyer: AliveW is busy on altConn at the same time that altConn is closed, right?
[11:00] <rog> so that looks like a race to me
[11:01] <fwereade_> rog, yes; so that Close could happen at any time, and that's definitely a problem
[11:01] <rog> i.e. the server gets killed, the goroutine receives the session event and closes altConn, at the same time AliveW happens to do a Change
[11:02] <fwereade_> rog, there are similar tests that really are *only* watching when the conn gets closed, and they're fine; yes
[11:02] <niemeyer> rog: If that's the case, then the connection is being Closed before kill()
[11:02] <rog> niemeyer: i don't think so
[11:03] <rog> niemeyer: the kill happens, then the close happens, then AliveW does something
[11:03] <niemeyer> rog: AliveW is run before kill..
[11:03] <rog> niemeyer: AliveW has a goroutine
[11:03] <fwereade_> niemeyer, I guess it's not impossible that there's another session event confusing me
[11:03] <niemeyer> rog: OH, does it?
[11:03] <niemeyer> Why?
[11:03] <niemeyer> To transform the event, I guess
[11:03] <rog> niemeyer: yup
[11:03] <niemeyer> But it should be listening only
[11:03] <niemeyer> On a channel.. that's not supposed to blow up
[11:04] <niemeyer> fwereade_: Can you please paste the whole file, or just push the branch?
[11:04] <rog> yeah
[11:04] <fwereade_> niemeyer, sure
[11:04] <fwereade_> niemeyer, ~fwereade/juju/go-presence-nodes
[11:05] <fwereade_> niemeyer, when we're watching for aliveness we can't just dumbly watch a channel
[11:05] <fwereade_> niemeyer, we need to keep rewatching when we get changes before timeouts
[11:05] <niemeyer> fwereade_: Ho ho ho
[11:05] <fwereade_> niemeyer, technically, above, when we're watching for *deadness*
[11:06] <fwereade_> niemeyer, have I misunderstood something fundamental?
[11:06] <niemeyer> fwereade_: I'm just curious about the rewatching.. that may explain it
[11:06] <fwereade_> niemeyer, (also we may need to rewatch when waiting for liveness too, it's a bit of an edge case, but...)
[11:07] <niemeyer> fwereade_: Yeah, there's a race there..
[11:07] <niemeyer> fwereade_: You're firing goroutines that use zk in a way that closing the connection will ignore completely
[11:08] <fwereade_> niemeyer, huh, I thought that closing the conn would close all the watches, and I'd see that
[11:08] <rog> niemeyer: i don't think there's a way to do it without either having a way to Close an AliveW or by making zk.Close concurrent-safe
[11:08] <rog> niemeyer: personally, i think i'd opt for the latter
[11:08] <rog> niemeyer: (after all, all the other routines are ok to call concurrently)
[11:09] <rog> s/routines/zk methods/
[11:10] <niemeyer> rog: Yes, there may be something to change in gozk, but there's something to be handled in presence itself that I'm trying to understand
[11:11] <rog> niemeyer: presence seems ok to me, but i'm probably missing something
[11:11] <niemeyer> fwereade_: Why do we need awaitDead and awaitAlive to loop?
[11:12] <fwereade_> niemeyer, awaitDead to refresh the data watch until I get a timeout without the data watch having fired
[11:12] <niemeyer> fwereade_: Ah, right.. it's the opposite.. it fires when it doesn't get a watch
[11:12] <niemeyer> Hmm
[11:12] <fwereade_> niemeyer, awaitAlive to handle the case where a known-unresponsive node is deleted -- it's still dead but not in the same way and IMO I shouldn't really alert the client to say "yeah, nothing changed"
[11:14] <niemeyer> Well, looks like we need our Watcher type back..
[11:15] <rog> niemeyer: if zk Close was concurrent-safe, everything would be fine
[11:15] <niemeyer> So that we can stop this logic in a sane way
[11:15] <rog> niemeyer: just like closing a net.Conn
[11:15] <rog> niemeyer: then the logic just stops as a matter of course
[11:16] <niemeyer> rog: What do you mean by concurrency safe?
[11:16] <rog> niemeyer: i mean that you could Close a zk conn concurrently with executing some other operation on the conn
[11:16] <fwereade_> niemeyer, it feels like one of the advantages of gozk is that the watches can just get auto-closed, and it would be really nice if we could follow the same convention here
[11:16] <fwereade_> rog, nitpick, technically it's all the other methods that aren't concurrent-safe ;)
[11:17] <niemeyer> rog: That's not enough
[11:17] <rog> fwereade_: they're concurrent-safe with each other...
[11:17] <rog> niemeyer: no?
[11:17] <niemeyer> fwereade_: Exactly
[11:17] <niemeyer> rog: What fwereade_ said
[11:17] <rog> niemeyer: i don't understand. wouldn't a mutex around the handle access be acceptable?
[11:18] <fwereade_> niemeyer, it still seems to me that a RWMutex on handle around C calls would be enough; what am I missing?
[11:18] <rog> niemeyer: (every method would have to respect it, of course)
[11:18] <niemeyer> rog: This is something else, not what you originally said
[11:18] <rog> niemeyer: that's what is necessary to make it ok to call Close concurrently, AFAICS
[11:18] <rog> niemeyer: which is what i was suggesting
[11:18] <niemeyer> rog: You're still missing the point..
[11:19] <fwereade_> niemeyer, so am I I think
[11:19] <niemeyer> rog: It's not just about concurrency
[11:19]  * rog usually does
[11:19] <niemeyer> rog: Close(); Set(foo).. BOOM!
[11:19] <rog> niemeyer: no.
[11:19] <rog> niemeyer: not if Set checks to see if handle is nil and then returns an error
[11:19] <niemeyer> rog: Dude.. please make up your mind
[11:20] <fwereade_> niemeyer, wouldn't we just grab a read lock, check for nil, and error back cleanly?
[11:20] <rog> fwereade_: exactly
[11:20] <niemeyer> fwereade_: YES!
[11:20] <niemeyer> fwereade_: We'd just do that.. that's not what was being said so far!
[11:20] <fwereade_> niemeyer, ha, I thought it was
 rog: What do you mean by concurrency safe?
 niemeyer: i mean that you could Close a zk conn concurrently with executing some other operation on the conn
[11:20] <rog> niemeyer: i just said "make Close concurrent-safe". that doesn't imply that Close is the only method that needs to change.
[11:21] <niemeyer> rog: This is not about concurrency! Serial operations blow up!
[11:21] <rog> niemeyer: well, that's a different (although related) issue.
[11:21] <fwereade_> niemeyer, Close might block for a while (or *possibly for ever if enough is going on...) but that seems preferable to unrecoverable panics in C if if a hamfisted amateur like myself is trying to use the library
[11:21] <niemeyer> rog: Yes, it's the issue we're seeing
[11:22] <rog> niemeyer: i think we're seeing an issue because of concurrency, no?
 rog: This is not about concurrency! Serial operations blow up!
[11:22] <rog> niemeyer: is that the case in this example? i thought we were doing things in two separate goroutines
 rog: This is not about concurrency! Serial operations blow up!
[11:23] <niemeyer> rog: You can inline.. Close(); Set(); BOM!
[11:23] <fwereade_> rog, niemeyer: sorry, lamb chops are hot on the table, back shortly :)
[11:24] <rog> niemeyer: that's not what's happening in this issue though, right?
[11:24] <niemeyer> rog: Yes, it is
[11:24] <rog> niemeyer: in the same goroutine?
[11:24] <niemeyer> rog: No.. the fact there are two goroutines is completely irrelevant
[11:25] <rog> niemeyer: to my mind, it's not. if we were in a single goroutine it would be easy to avoid doing an operation after Close.
[11:25] <rog> niemeyer: it's the concurrency issue that makes it harder
[11:26] <niemeyer> rog: Sorry, but a "concurrency issue" is something else than what you have in mind
[11:26] <rog> niemeyer: ok, fair enough
[11:26] <rog> niemeyer: so...
[11:26] <niemeyer> rog: You can put a lock across every single function in gozk, and it will still blow up
[11:26] <rog> niemeyer: only if they don't check that handle is not nil before calling into C, no?
[11:27] <niemeyer> rog: Yes, and that's not a concurrency issue.. this is about using a connection after it's been closed.
[11:27] <niemeyer> rog: and make that not panic
[11:27] <rog> niemeyer: agreed. but just doing that won't fix our problem either.
[11:27] <rog> niemeyer: because then there would be a race.
[11:29] <niemeyer> rog: Sure, because you can't trust on the test for the handle to be valid without a lock
[11:29] <rog> niemeyer: exactly
[11:37] <niemeyer> fwereade_: So..
[11:37] <rog> niemeyer: i think a RWMutex would probably do the job just fine
[11:37] <rog> on zk.Conn, that is
[11:38] <niemeyer> fwereade_: You're right, we must definitely fix gozk itself so that we protect from that kind of issue
[11:38] <niemeyer> fwereade_: I'm just still wondering if we should change the interface for that
[11:38] <niemeyer> fwereade_: I guess it's fine to keep it running it in background, and simply error out, given that this is purely a read operation without any side effects
[11:40] <rog> niemeyer: that was my thought.
[11:40] <niemeyer> fwereade_: Btw, I'd prefer to not have the  (s state) as a parameter to the await functions
[11:41] <niemeyer> fwereade_: There's actually a bug in that regard in the current logic
[11:42] <niemeyer> fwereade_: No, there isn't, sorry
[11:42] <niemeyer> fwereade_: You're passing the parameter as a copy, which is safe
[11:42] <niemeyer> fwereade_: Still, I don't see why the parameter is necessary
[11:43] <rog> niemeyer: it saves passing the path and timeout parameters as separate arguments
[11:44] <rog> niemeyer: but i'm with you
[11:47] <niemeyer> rog: Yeah, I think the organization there needs some tweaking for clarification
[11:51] <rog> niemeyer: i wondered if things might be clearer if there was an internal watcher type which held the params that are being passed around.
[11:52] <niemeyer> rog: I was wondering about that too, but this is makes it seem like there wouldn't be much benefit compared to what is there now:
[11:52] <niemeyer>                                 s, zkWatch, err = newStateW(conn, s.path)
[11:52] <rog> niemeyer: s, err := w.getStateW() ?
[11:52] <niemeyer> rog: The only bit that is actually constant is the path
[11:53] <rog> yeah
[11:53] <niemeyer> rog: Right, w is the path..
[11:53] <niemeyer> rog: Which renders fwereade_ design elegant
[11:53] <rog> it was the other methods i was really thinking about (waitAlive and waitDead)
[11:54] <niemeyer> rog: Right.. as methods, they would have to live on a type that is simply the path
[11:54] <niemeyer> rog: Because timeout and aliveness changes
[11:55] <rog> niemeyer: that's fine. they can still be fields in the waiter type. it will change when they change.
[11:55] <rog> niemeyer: (it's not used concurrently)
[11:55] <niemeyer> rog: There's no point in having them as fields.. it's only used in that one function
[11:55] <rog> maybe "node" might be a better name for the type
[11:56] <niemeyer> rog: Yeah, path :)
[11:56] <niemeyer> rog: type node string, where node is the path
[11:57] <niemeyer> rog: That won't improve much what fwereade_ has there now, though. The design feels sound on that level
[11:57]  * rog is thinking about it
[11:57] <niemeyer> rog: Well.. I guess we could have the connection on it too
[11:58] <niemeyer> Which would make it more interesting
[11:58] <rog> niemeyer: yeah
[11:58] <niemeyer> type node string
[11:58] <rog> niemeyer: and the watch channel to send to
[11:58] <niemeyer> func (n node) readState() (alive, timeout, error)
[11:58] <niemeyer> func (n node) readStateW() (alive, timeout, watch, error)
[11:58] <rog> func (n node) get() error
[11:58] <rog> sorry
[11:58] <rog> func (n *node) get() error
[11:58] <niemeyer> func (n node) awaitAlive
[11:58] <niemeyer> func (n node) awaitDead
[11:58] <rog> func (n *node) getW() error
[11:59] <niemeyer> rog: What's get?
[11:59] <niemeyer> rog: get error? :)
[11:59] <rog> niemeyer: gets the current state of the node. stores it in n.
[11:59] <rog> niemeyer: getW also gets a wait channel and stores that in n too.
[11:59] <niemeyer> rog: That's a bad name then.. update() maybe
[11:59] <rog> sure
[12:01] <niemeyer> and updateW()
[12:01] <niemeyer> rog: Yeah, that should improve things indeed, +1
[12:02] <rog> cool
[12:02]  * fwereade_ reads back...
[12:02] <niemeyer> rog, fwereade_: So.. I'd just like to take an eagles view on the whole issue to close it down, if that's ok
[12:02] <niemeyer> We have one bug, and one design approach we're agreeing that breaks a prior rule
[12:02]  * rog feels those sharp eyes on him from far far above.
[12:02] <niemeyer> :)
[12:03] <niemeyer> The bug is, as we discussed at length, the fact closing and using a connection is a blow up in gozk for sure. We must fix that.
[12:03] <niemeyer> The design decision is a more subtle one
[12:04] <niemeyer> The prior goal I was personally attempting to ensure is that we never have background logic under our control running in parallel with other stuff that will break down the concurrently executing logic
[12:04] <niemeyer> Under that design approach, we'd need a Stop() method on the watcher
[12:05] <niemeyer> So that we can stop it.. that would avoid the gozk bug too
[12:05] <niemeyer> But, we're agreeing to not do that, and instead fix gozk, and establish a new condition:
[12:05] <niemeyer> If the background logic is entirely innocuous, it's fine to allow it to die a cold death
[12:07] <rog> sounds good to me. as long as the logic *will* die, and not be left around as garbage
[12:07] <fwereade_> niemeyer, that sounds sensible to me personally, but then I would say that
[12:07] <niemeyer> AliveW is one example of that.. by itself, it's doing nothing. If it blows up in the background, there are zero side effects, _as long as the logic that is using the watch does nothing_!!
[12:07] <fwereade_> niemeyer, this feels consistent with every other ZK watch
[12:08] <niemeyer> It's _NOT_ ok to have someone waiting on the watch resulting from AliveW, and doing further actions like changing the FS or whatever else, despite the fact the connection has been closed
[12:08] <rog> and the logic using the watch will just see a close on the channel, which means an error, so hopefully this kind of logic can cascade
[12:08] <niemeyer> fwereade_: Agreed
[12:08] <fwereade_> niemeyer, excellent
[12:08] <rog> fwereade_: agreed
[12:08] <niemeyer> rog: No, that's exactly what we don't want
[12:09] <niemeyer> rog: We'd have to reevaluate the use of the watch, if it's also in background
[12:09] <rog> niemeyer: no? i'm imagining some other innocuous logic layered on top of AliveW
[12:09] <niemeyer> rog: For it to be alright, it'd have to be innocuous too
[12:09] <rog> niemeyer: yes, definitely
[12:09] <niemeyer> rog: Cool, we're in agreement then
[12:09] <rog> yup
[12:10] <niemeyer> So, those are the relevant decisions
[12:10] <niemeyer> Glad we're in agreement, phew :)
[12:10] <niemeyer> fwereade_: In addition to that, we were nitpicking over the interface around the state type
[12:11] <niemeyer> fwereade_: Which is not terribly important, but that might be interesting to sort out if you still have the energy
[12:11] <fwereade_> niemeyer, I saw that and I'm not strongly invested in what I currently have; the fields seemed to go well together, and to stop the function signatures breaking lines, and so I decided it was good :)
[12:11] <niemeyer> fwereade_: rog was suggesting a node type, which feels nice to clarify the state handling
[12:12] <niemeyer> fwereade_: Something like this is the status quo of the discussion:
[12:12] <niemeyer> type node struct { conn, path, timeout, alive }
[12:12] <niemeyer> func (node) update() error
[12:12] <niemeyer> func (node) updateW() (watch, error)
[12:13] <rog> *node
[12:13] <niemeyer> Sorry, yes
[12:13] <niemeyer> func (*node) waitAlive()
[12:13] <niemeyer> func (*node) waitDead()
[12:13] <niemeyer> (the last two with the necessary return types and parameters)
[12:13] <fwereade_> niemeyer, LGTM
[12:13] <fwereade_> thanks guys, productive discussion :-)
[12:14] <niemeyer> fwereade_: waitAlive and waitDead would be implemented on top of the former two
[12:14] <niemeyer> fwereade_: Likewise!
[12:14] <rog> i keep on wondering if waitAlive and waitDead might not be better named as deadWait and liveWait respectively
[12:14] <rog> i.e. name them after the state they start in rather than the state they're waiting for.
[12:14] <rog> dunno
[12:14] <niemeyer> rog: -1.. these are nouns
[12:14] <niemeyer> we need verbs
[12:14] <rog> yeah
[12:15] <rog> i want to call waitDead waitDeath
[12:15] <rog> but can't think of an appropriate name for the other one
[12:15] <fwereade_> rog, I considered similar but "waitBirth" wasn't right
[12:15] <fwereade_> rog, indeed
[12:15] <niemeyer> waitAlive and waitDead feels great to me
[12:15] <rog> yeah
[12:16] <niemeyer> And on that node, I'll do some reviews..
[12:16] <rog> that's fine. just thought i'd mention it in case others has similar thoughts.
[12:16] <fwereade_> niemeyer, would you like me to take a look at gozk as well?
[12:16] <niemeyer> Actually, let me finish answering emails first
[12:16] <fwereade_> niemeyer, I don't want to overload you :)
[12:16] <rog> i could do gozk
[12:16] <niemeyer> fwereade_: Yes, please
[12:16] <niemeyer> or rog.. whatever works
[12:16] <rog> or fwereade_ sure
[12:17] <rog> i'm a bit ahead of myself anyway currently
[12:17]  * fwereade_ bows out gracefully
[12:18] <rog> fwereade_: how about you refactor presence (again!) and i'll do zk.
[12:18] <fwereade_> rog, give me a shout if it becomes a hassle in any way and I can grab it
[12:18] <fwereade_> rog, but that sounds good to me
[12:18]  * rog thinks is shouldn't be too much problem.
[12:18] <rog> s/is/it/
[12:27] <andrewsmedina> niemeyer: hi
[12:27] <niemeyer> andrewsmedina: Hey
[12:35] <rog> fwereade_, niemeyer: ok, zk changes made. now for the harder bit... the testing.
[12:36] <fwereade_> rog, good luck :)
[12:38]  * rog thinks of a devious way of forcing a zk request to take a long time.
[12:44] <andrewsmedina> niemeyer: in the last weekly version Go isn't  work with two packages in same project
[12:46] <andrewsmedina> andrewsmedina: in some of your projects you put a example.go which is a different package.
[13:08] <fwereade_> rog, just a thought; I have a couple of `switch event.Type`s without defaults; if I get totally unexpected events, it would probably be sensible to `close(watch)`, right?
[13:08] <rog> fwereade_: you could probably panic
[13:09] <rog> fwereade_: it's part of the contract that the correct event types should be returned
[13:09] <rog> fwereade_: if they're not, then something's very broken
[13:09] <rog> the contract with zk, that is
[13:09] <fwereade_> rog, in that case I think explicitly panicking may be excessively defensive
[13:10] <rog> fwereade_: i'd prefer to see a panic rather than a silent failure in that case
[13:10] <fwereade_> rog, ok, just `panic(event)` then?
[13:10] <rog> fwereade_: panic(fmt.Errorf("unexpected event %v", event))
[13:10] <rog> or something like that
[13:11] <fwereade_> rog, ok then :)
[13:11] <rog> it's nice to see the thing that caused the panic
[13:12] <fwereade_> rog, sounds good
[13:16] <fwereade_> rog, hm, I guess I can lose the forward() stuff once we have a Close-safe gozk
[13:16] <rog> fwereade_: yeah. that'll be good.
[13:16] <rog> fwereade_: i could push a version that you could use until i've done the tests, if you like.
[13:17] <fwereade_> rog, a good thing but also sort of a shame, that stuff made me very happy :)
[13:17] <fwereade_> rog, I guess that would be useful
[13:17] <rog> fwereade_: it's still there for when you need it again...
[13:17] <rog> fwereade_: in fact i think i might be using that technique in the zk tests... (my "devious way")
[13:18] <fwereade_> rog, indeed, the pleasure of deleting code still outweighs the pleasure I took in the code to begin with
[13:18] <fwereade_> rog, nice :)
[13:18] <rog> fwereade_: i'm gonna have a forwarder and stop all incoming traffic. then i know that the reply can't come back quickly...
[13:20] <rog> fwereade_: in fact i might steal your code directly, since it's still there...
[13:20] <fwereade_> rog, go for it :)
[13:24] <TheMue> So, solved a merging prob, 76 tests passed
[13:25] <rog> TheMue: nice
[13:26] <TheMue> rog: yeah, it goes on, piece by piece
[13:26] <rog> TheMue: i bet you're glad you speeded up the tests now :-)
[13:35] <TheMue> rog: definitely
[13:36] <TheMue> rog: when zk is cold (first start) about 11 sec, then about 6.3 sec.
[13:37] <rog> TheMue: how long if you run just one test?
[13:37] <TheMue> not yet tested
[13:39] <fwereade_> rog, TheMue, IME live-zookeeper tests have a 5s overhead
[13:39] <fwereade_> (when hot)
[13:39] <rog> so about 1.3 seconds to run the tests. that's not bad
[13:40] <rog> TheMue: try go gotest -gocheck.run patternMatchingOneTest :-)
[13:40] <TheMue> rog: with a lot i/o
[13:40] <rog> oh, i think it might be gocheck.f actually
[13:40] <fwereade_> rog, it is
[13:41] <rog> fwereade_: i'm going to change that soon - it should be the same as the equivalent test option
[13:41] <rog> fwereade_: i just haven't pushed the change yet
[13:41] <rog> well, the merge request
[13:41] <fwereade_> rog, fine with me; I'll discover it, swear, check the options and be happy :)
[13:45] <TheMue> rog: a single test is 5.11 vc 6.36 for all tests
[13:45] <rog> ain't java wonderful?
[13:45] <TheMue> fwereade_: your guess with 5 sec seems good
[13:45] <TheMue> rog: haha
[13:52] <fwereade_> niemeyer, should ExpectFailure (gocheck) possibly output something in test runs? as it is, its "don't forget this test exists" value seems a touch limited
[13:54] <niemeyer> fwereade_: The purpose is precisely to not forget that there are broken tests without having a failure that we'll learn to ignore
[13:56] <fwereade_> niemeyer, agree that ignored-by-convention failures are poisonous; I just don't see how it stops us forgetting any better than renaming the methods to DontTest* would
[13:57] <niemeyer> fwereade_: It mentions that there are expected failures at the end of the run, doesn't it?
[13:57] <fwereade_> niemeyer, perhaps I'm Doing It Wrong, but not afaics
[13:57] <fwereade_> william@diz:~/code/go/src/launchpad.net/juju/go$ go test launchpad.net/juju/go/state/presence
[13:57] <fwereade_> ok  	launchpad.net/juju/go/state/presence	5.890s
[13:57] <niemeyer> Hmm
[13:58] <niemeyer> fwereade_: Run it without the package name
[13:58] <niemeyer> fwereade_: Within the directory
[13:58] <niemeyer> fwereade_: Or with -v
[13:58] <niemeyer> fwereade_: go test is eating the output
[13:58] <fwereade_> niemeyer, no dice either way
[13:58] <fwereade_> niemeyer, ah, somehow run it without using "go test"?
[13:59] <niemeyer> No
[13:59] <niemeyer> fwereade_: There's something wrng indeed
[14:01] <fwereade_> niemeyer, it's not critical, shall I just open a bug?
[14:02] <fwereade_> niemeyer, (srry, I feel bad distracting you all the time while the store's still in progress)
[14:02] <niemeyer> fwereade_: No worries really
[14:02] <niemeyer> fwereade_: I haven't even managed to get to that yet
[14:03] <fwereade_> niemeyer, heh, that's a large part of why I feel bad about it ;)
[14:03] <niemeyer> fwereade_: Yes, please file a bug.. it's supposed to print it
[14:25] <niemeyer> Hey cliff-hm
[14:25] <niemeyer> cliff-hm: How're things going in the RedHat side of the world?
[14:27] <cliff-hm> Pretty OK thanks. :)
[14:28] <cliff-hm> Just trying to understand and play with Juju a bit to see how it fits itself together.
[14:28] <niemeyer> cliff-hm: Nice, please let us know what you think
[14:29] <cliff-hm> (I prefer not to hide away) :)
[14:31] <cliff-hm> Sure
[14:32] <cliff-hm> I may try to do that contest, not sure yet.
[14:32] <cliff-hm> (In my spare, non-company time)
[14:38] <niemeyer> cliff-hm: That'd be great
[14:38] <niemeyer> cliff-hm: When can we expect juju to be integrated into RedHat's products? :)
[14:43] <niemeyer> rog: Can you please sort out this branch so we can take it out of the review list: https://code.launchpad.net/~rogpeppe/juju/fix-tutorial-with-expose-2/+merge/75379
[14:43] <rog> niemeyer: jeeze, i thought i did that months ago :-)
[14:44] <niemeyer> rog: and this one too: https://codereview.appspot.com/5674051/
[14:45] <rog> niemeyer: TheMue wanted to do something different there, so i was thinking of abandoning it
[14:45] <niemeyer> rog: That's a fine solution, but we need to reject it so that that it goes out of the review list
[14:46] <rog> niemeyer: ok. i'll reject it.
[14:46] <niemeyer> rog: Thanks
[14:46] <cliff-hm> niemeyer, I don't know ;) I'm doing this on personal time ... out of my own interests.
[14:48] <niemeyer> cliff-hm: Ah, understood. I thought it was related to you being a managed of the Spacewalk/Satellite/RHN/etc team
[14:49] <niemeyer> cliff-hm: Please drop us a note if you have any suggestions then
[14:50] <cliff-hm> My interests stem from that background, yes. But I'm not under company orders to spy and look at what others do :) My day job is too busy for those tasks.
[14:53] <cliff-hm> And yeap. I will try to give feedback. Though likely to have more questions :)
[14:53] <cliff-hm> (been reading so far, hoping tonight and weekend to stay hands-on)
[14:54] <niemeyer> cliff-hm: Sweet
[14:54] <niemeyer> cliff-hm: I have good friends at RH, btw..
[14:54] <rog> niemeyer: both rejected - the earlier was submitted in some other form sometime.
[14:55] <niemeyer> cliff-hm: Probably not very close to you, though
[14:58] <cliff-hm> we have a lot of employees now. I know a bunch of people in my time here, but there is a lot more people that I do not know, than know.
[14:58] <niemeyer> cliff-hm: Can imagine.. most of the people I know are around kernel development, I believe
[15:02] <niemeyer> Rietveld cross-changes diffing is such a huuuge aid
[15:02] <niemeyer> cliff-hm: Do you work close to the Openshift guys?
[15:09] <niemeyer> Suddenly rietveld is crawling
[15:09] <niemeyer> Which makes this a good time to have lunch
[15:09] <niemeyer> rog: I did manage to LGTM one of hte pending branches, though
[15:09] <rog> niemeyer: magic, thanks
[15:10] <niemeyer> Will finish pending reviews when I'm back, and then will step out to do store work
[15:13] <cliff-hm> I know several, but not close with them. Closer to the Aoelous and Katello, pulp project guys.
[15:18] <rog> niemeyer, fwereade_: https://codereview.appspot.com/5694068/
[15:18] <rog> probably the most significant one yet.
[15:19] <rog> fwereade_: if you wanna have a look, probably the best place to start is in util.go, which has the basic robustness primitive.
[16:16] <rog> fwereade__: just checking: did you see my CL above?
[16:16] <rog> fwereade__: or is your network playing up?
[16:17] <rog> hmm, can anyone see this?
[16:29] <niemeyer> It's funny that every time Mark starts a rant in canonical-tech, there's a bunch of people asking to subscribe to the list
[16:41] <rog> niemeyer: i hadn't looked at that list recently
[16:49] <fwereade__> rog, sorry, I keep not seeing notifications
[16:50] <rog> fwereade__: that's fine. this is what i said:
[16:50] <fwereade__> rog, I did, and thank you for the advice to start looking in util, would have been a little mystifying otherwise ;)
[16:50] <rog> 15:18] <rog> niemeyer, fwereade_: https://codereview.appspot.com/5694068/
[16:50] <rog> [15:18] <rog> probably the most significant one yet.
[16:50] <rog> [15:19] <rog> fwereade_: if you wanna have a look, probably the best place to start is in util.go, which has the basic robustness primitive.
[16:50] <rog> fwereade__: np
[16:51] <niemeyer> rog: Yeah, I'm on reviews
[16:51] <rog> niemeyer: brill!
[16:54] <niemeyer> Man.. why is codereview *so slow*
[16:54] <niemeyer> rog: "there's deliberately only one securityGroup instance for each security group."
[16:54] <niemeyer> rog: Where's that enforced?
[16:57] <rog> niemeyer: there's only one occurrence of "&securityGroup" in the file, which is in newSecurityGroup, which is only called when group() has returned nil
[16:58] <rog> niemeyer: actually, i think the newSecurityGroup call in NewInstances (even though it conforms to that rule) might be ananachronism
[16:58] <rog> an anachronism
[16:58] <niemeyer> rog: There are two different calls to newSecurityGroup
[16:59] <rog> niemeyer: they're both called only when group() has returned nil
[16:59] <rog> niemeyer: i.e. they never create a group with the same contents twice
[16:59] <rog> niemeyer: but see above too
[17:00] <rog> i think the occurrence in NewInstances might be from before i implemented CreateSecurityGroup
[17:00] <niemeyer> rog: Still, this is a problem.. the current design is error prone, and there's a design not documented anywhere and scattered across the code
[17:01] <rog> niemeyer: if i deleted it from NewInstances (which i think i probably should) then it would not be scattered.
[17:01] <niemeyer> rog: It would still not be documented, and it would still be error prone
[17:01] <niemeyer> rog: All it takes is a single line: &securityGroup{}.. BOOM, bug.
[17:02] <rog> niemeyer: so you don't like comparing pointers?
[17:02] <rog> niemeyer: or are you asking for a comment?
[17:02] <niemeyer> rog: I like comparing pointers.. I don't like error prone code that will break behind our back in hard to notice ways
[17:02] <niemeyer> rog: I'm asking to make the code not error prone
[17:02] <niemeyer> rog: I don't want to remind everybody that touches that file that they can't create security groups
[17:03] <rog> niemeyer: if i put a comment next to the securityGroup type saying "only create this through newSecurityGroup", would that be ok?
[17:03] <rog> niemeyer: (and have newSecurityGroup do the check)
[17:03] <niemeyer> rog: The comment + the latter sounds good
[17:04] <rog> niemeyer: cool, will do.
[17:04] <niemeyer> rog: This will prevent people from making silly but reasonable mistakes, I hope
[17:04] <niemeyer> rog: Thanks, and sorry for the trouble
[17:04] <rog> niemeyer: np. it was worth it to find the bug in NewInstances
[17:05] <rog> well, not precisely a bug
[17:09] <niemeyer> rog: Please also add a short note in the permKey struct, next to the pointer definition
[17:11] <fwereade__> EOD, and I'm exhausted :). happy weekends all!
[17:11] <niemeyer> rog: Nice comments, btw, thanks
[17:11] <niemeyer> fwereade__: have a good time man :)
[17:12] <rog> fwereade__: happy weekend to you to
[17:12] <rog> o
[17:15] <rog> niemeyer: something like this?
[17:15] <rog> // permKey represents permission for a given security
[17:15] <rog> // group or IP address (but not both) to access a given range of
[17:15] <rog> // ports. Equality of permKeys is used in the implementation of
[17:15] <rog> // permission sets, relying on the uniqueness of securityGroup
[17:15] <rog> // instances.
[17:17] <niemeyer> rog: Sounds great, thanks
[17:28] <rog> niemeyer: cool.
[17:29] <rog> with those changes, does it LGTY?
[17:29] <rog> niemeyer: here's the other comment, BTW:
[17:29] <rog> // securityGroup holds a simulated ec2 security group.
[17:29] <rog> // Instances of securityGroup should only be created through
[17:29] <rog> // Server.newSecurityGroup to ensure that groups can be
[17:29] <rog> // compared by pointer value.
[17:35] <rog> niemeyer: PTAL
[17:43] <niemeyer> rog: // It returns nil if a security group with the given name already exists.
[17:43] <niemeyer> rog: Feels like a trap
[17:43] <rog> niemeyer: really?
[17:44] <rog> niemeyer: do you want it to return an error?
[17:44] <rog> niemeyer: i considered that, but i haven't got an error type yet
[17:44] <rog> niemeyer: and the caller needs to call fatalf with an appropriate error code
[17:45] <rog> niemeyer: i could just delete the newSecurityGroup function
[17:45] <niemeyer> rog: Yeah, an error sounds good.. or make it panic internally and delegate the responsibility of checking to the call site
[17:46] <rog> niemeyer: what about my last suggestion?
[17:46] <rog> niemeyer: just inline it inside CreateSecurityGroup
[17:47] <niemeyer> rog: The abstraction is fine.. just make it panic internally if the group already exists
[17:47] <niemeyer> rog: We just want to make the error visible rather than a hidden issue
[17:47] <rog> niemeyer: it won't be hidden for long... anything that tries to use the returned group will panic.
[17:47] <rog> niemeyer: but ok
[17:48] <niemeyer> rog: Not really. Returning a nil group means people could get away with setting a permKey.group to it, for instance.
[17:49] <rog> given that it's only called in one place, i don't really see why the creation needs its own function.
[17:49] <niemeyer> rog: Sure, inline then..
[17:49] <rog> something in me slightly balks at doing two linear searches of the group list... (i know that's a ridiculous concern, too!)
[17:50] <niemeyer> rog: Keep a comment about the problem, please
[17:50] <rog> niemeyer: will do
[17:54] <rog> niemeyer: done.
[17:56] <rog> weird
[17:57] <rog> my irc client appears to have logged me in twice
[17:57] <rog> ah! that must've been carmen opening my laptop
[17:59] <rog> niemeyer, TheMue: i'm off now. have a good weekend.
[17:59] <niemeyer> rog: LGTM.. thanks
[17:59] <TheMue> rohave a good weekend too
[17:59] <niemeyer> rog: Have a good weekend
[17:59] <rog> niemeyer: thanks for the reviews.
[18:00] <rog> niemeyer: always nice to finish with a submit. thanks.
[18:00] <niemeyer> rog: Indeed! :-)
[18:00] <niemeyer> rog: and np


[09:41] <GPenguin> popey: so you want the entire story to be repeated on this channel?
[09:41] <popey> I kickbanned GPenguin because I believe him to be Patrick Frank
[09:42] <popey> from #ubuntu-uk that is
[09:42] <popey> if he has a problem with that, then he should take it up with the people who run this channel
[09:42] <popey> I am not willing to discuss it further until someone else steps in
[09:42] <GPenguin> [10:39] <GPenguin> popey: and then you seriously wonder why people react in a rude way to such violent attitude?
[09:42] <GPenguin> [10:40] <popey> GPenguin is I believe a certain patrick frank
[09:42] <GPenguin> [10:40] <popey> I kickbanned him from #ubuntu-uk
[09:42] <GPenguin> [10:40] <GPenguin> popey: you make up wild guesses about my real name and take violent action based on wild assumptions while there was no need to be massive
[09:42] <GPenguin> [10:40] <GPenguin> popey: thats not just unhealthy attitude, thats abusive
[09:42] <GPenguin> [10:41] <popey> raise it with the irc ops if you have an issue with me
[09:42] <GPenguin> [10:41] <GPenguin> popey: and the irony is that you claim Patrick Frank was rude because of such abuse
[09:42] <GPenguin> [10:41] <tonyyarusso> popey: loco stuff is handled in #ubuntu-irc now - this channel is just for #ubuntu, #kubuntu, et al and their offtopics
[09:42] <GPenguin> [10:41] <popey> oh ok
[09:42] <GPenguin> [10:41] <GPenguin> popey: why would i be interested in further escalation? i follow your invite to this channel to talk to you after you banned me without any reason
[09:42] <GPenguin> [10:41] <popey> GPenguin: take it to #ubuntu-irc :)
[09:43] <GPenguin> so the case is open
[09:45] <GPenguin> popey: are you at least aware that _you_ are escalating a peaceful situation?
[09:45] <Tm_T> hm?
[09:45] <Tm_T> GPenguin: peaceful situation and kickban doesn't fit
[09:45] <GPenguin> Tm_T: whats your role in the ubuntu community, please?
[09:46] <Tm_T> GPenguin: I'm the Overseer, but that doesn't matter
[09:46] <GPenguin> i was having peaceful smalltalk on #ubuntu-uk and popey banned me with the comment "i suspect you are Patrick Frank". then invited me to #ubuntu-ops where he told he wont discuss. then invited me to #ubuntu-irc
[09:47] <Tm_T> yes
[09:47] <GPenguin> Tm_T: it does matter if i talk to the right person or some random popey fanboy
[09:47] <Tm_T> no, I'm not any fanboy, sorry
[09:47] <GPenguin> good. so there is a chance that you manage this situation in a professional way
[09:48] <GPenguin> and to make this clear from the beginning. i am not claiming the right to be on #ubuntu-uk. since popey shows this hostile attitude i dont care to be there. what i care about is the abusive attitude
[09:48] <Tm_T> GPenguin: anyway, if popey or other ops in this channel discuss this matter with you, then do, if not, I can't help you other than point you to ubuntu irc council
[09:49] <GPenguin> Tm_T: so you want me to spend time and efforts outside of IRC to deal with some abusive jerk on IRC?
[09:50] <GPenguin> Tm_T: the behaviour of popey meets the classic "harassment policy"
[09:50] <Daviey> GPenguin: Please refrain from calling -uk operators jerks
[09:50] <GPenguin> Tm_T: and i expect this to be fixed where the problem occurs
[09:50] <Tm_T> GPenguin: unfortunately I can't help you other way, as I don't have nor like to have powers to "fix them"
[09:51] <GPenguin> Tm_T: i have seen network operators who k-line for the behaviour what popey did
[09:51] <Tm_T> GPenguin: then talk to them?
[09:51] <Daviey> GPenguin: if you are infact Patrick Frank - you are supposed to be on a kline
[09:51] <GPenguin> Tm_T: simple question: what is the purpose of this channel here?
[09:51] <GPenguin> Daviey: says who?
[09:52] <Tm_T> GPenguin: talk and collaboration between irc operators of loco channels
[09:52] <GPenguin> Tm_T: why was i invited to
[09:52] <Tm_T> GPenguin: we don't hold power over each other usually
[09:52] <GPenguin> Tm_T: why was i invited to #
[09:52] <Daviey> oh come on, you know as well as the rest of us that you are supposed to be klined
[09:52] <Daviey> Shall we ask freenode staff?
[09:52] <GPenguin> Tm_T: why was i invited to #ubuntu-ops first and then taken from there to this channel then?
[09:52] <Tm_T> GPenguin: to discuss this matte
[09:52] <popey> actually i asked him to come here to _escalate_ the matter
[09:52] <Tm_T> Daviey: please do if needed :))
[09:52] <GPenguin> Tm_T: and the discussion is where?
[09:52] <popey> I do _not_ want to discuss it and I'd rather the other -uk ops didnt either
[09:53] <popey> its a monumental waste of time
[09:53] <popey> but your time, so up to you
[09:53] <Daviey> Tm_T: asked one staffer
[09:53] <Tm_T> GPenguin: like to discuss it now? ok, first calm down
[09:53] <Tm_T> popey: I'll try :))
[09:53] <GPenguin> popey: right. you are intriguing to see a person k-lined. thats pretty weak ethics to be honest
[09:53] <GPenguin> Tm_T: calm down if somebody behaves like a jerk?
[09:53] <Tm_T> GPenguin: yes
[09:54] <GPenguin> popey: what do you think the community says about your ethics?
[09:54] <Tm_T> GPenguin: because if you do not, you might end up being a jerk yourself, I'm not qualified to say are you already
[09:54] <GPenguin> popey: do you think your ethics meet the Ubuntu Code of Conduct?
[09:54] <GPenguin> popey: or are you that much of a celebrity these days that such a Code of Conduct does not apply to you anymore?
[09:55] <GPenguin> popey: you say you want escalation?
[09:55] <Tm_T> since when popey has become celebrity? =)
[09:55] <GPenguin> popey: you want me to pick up this challenge?
[09:55] <GPenguin> popey: you want escalation so you can cry later that i was escalating a harmless situation?
[09:55] <Tm_T> GPenguin: anyway, thus far you have only tried to make huge fight rather than discuss
[09:55] <popey> GPenguin: I have already suggested what I think you should do
[09:56] <GPenguin> Tm_T: i tried to fight or popey?
[09:56] <popey> take it to the irc council GPenguin
[09:56] <Tm_T> GPenguin: you, calm down, son
[09:56] <GPenguin> popey: so you are actively provoking a mud fight on the council mailing lists?
[09:56] <popey> no, i am asking you to take it to the irc council
[09:56] <Tm_T> GPenguin: no, he is not asking any mud fighting
[09:56] <GPenguin> popey: again - how does that fit the Code of Conduct what you do here?
[09:57] <popey> as I have said many times, I am not willing to discuss it until you escalate it
[09:57] <popey> I believe I am too close to the issue to be impartial
[09:57] <Tm_T> GPenguin: calm down, I think I said it before already
[09:57] <GPenguin> popey: psycho logical explained what you do is begging for a punch in the face while there is no need
[09:58] <GPenguin> popey: and now think back how the situation was before you turned abusive. there was a random person on #ubuntu-uk having small talk in a friendly and peaceful way
[09:58] <Tm_T> bahhhhh
[09:58] <Tm_T> stupid borky scripts
[09:59] <popey> sorry everyone
[09:59] <Tm_T>  /remove GPenguin I said calm down
[09:59] <Tm_T> popey: thanks :))
[09:59] <Tm_T> popey: had fun for a moment there
[09:59] <Tm_T> tomaw: hi hi welcome
[09:59] <Daviey> tomaw: missed the fun :(
[10:00] <GPenguin> Ubuntu Developers invite people to #ubuntu-irc after they abused them, so other Ubuntu Developers can abuse them, too? is that the master plan? and the complaint was what again? that i turn violent on such input?
[10:00] <tomaw> hi
[10:00] <Tm_T> tomaw: ^^
[10:00] <Tm_T> GPenguin: no, no plan to abuse
[10:00] <GPenguin> tomaw: is that the deal here?
[10:00] <GPenguin> Tm_T: double check your behaviour
[10:00] <Tm_T> GPenguin: honestly, calm down, as long as you are raging around you can't discuss
[10:01] <tomaw> GPenguin: I have only just joined
[10:01] <Tm_T> GPenguin: I do my job, no abuse there
[10:01] <GPenguin> Tm_T: i am calm. even after your abusive behaviour
[10:01] <Tm_T> GPenguin: good then
[10:01] <GPenguin> Tm_T: no you dont do your job.
[10:01] <Tm_T> interesting
[10:01] <GPenguin> Tm_T: you are having ban fun like popey. and this abuse brought me to this channel
[10:02] <Tm_T> GPenguin: no, I am not having ban fun
[10:02] <GPenguin> Tm_T: i dont care that you dont value the Code of Conduct that you signed when becoming an Ubuntu Developer. i care about people who abuse me. do you get it?
[10:02] <Tm_T> GPenguin: hmm, you do make hard accusations, son :)
[10:02] <Tm_T> without any arguments
[10:03] <GPenguin> Tm_T: a start would be that you stop flooding me with crap like "calm down" while i am calm
[10:03] <Tm_T> GPenguin: good, good
[10:03] <GPenguin> Tm_T: the next step is that you dont look at me with the eyes of a ban happy jerk when i try to explain a problem
[10:03] <Tm_T> GPenguin: yes son
[10:04] <GPenguin> Tm_T: the third step is that you learn about respect and stop calling me "son", so i dont have to insult you
[10:04] <Tm_T> son, I do respect you, no need to insult
[10:04] <GPenguin> Tm_T: the basic principle about de-escalation. you play the access dude, then you should know about it
[10:04] <Daviey> GPenguin: I believe you are Paddy Frank also - for this reason i don't want you unbanned from -uk anytime soon.
[10:05] <GPenguin> Daviey: keep out of this at this point. thank you
[10:05] <GPenguin> i am sure Tm_T is mature enough to handle this on his own without support
[10:05] <Daviey> GPenguin: Would be good if you did also.
[10:05] <GPenguin> Daviey: remember - i was invited to this place after i was abused by popey
[10:06] <GPenguin> and the bottom line was "i suspect this person is Patrick Frank who was rude some months ago. so i must ban him now without cause"
[10:06] <GPenguin> do you get this so far?
[10:07] <Tm_T> GPenguin: I need some prove for this, as I can't see inside popeys head
[10:07] <GPenguin> Tm_T: ask popey to provide you a log then
[10:07] <GPenguin> i will take a break now so you have enough time to _think_ how to proceed
[10:07] <GPenguin> but be warned. i am not taking anymore abuse from anybody
[10:08] <popey> http://logs.ubuntu-eu.org/freenode/2008/02/20/%23ubuntu-uk.html
[10:09] <GPenguin> post the Ubuntu Code of Conduct, too please. so all of you can re-read before you say _anything_
[10:09] <popey> I dont need to read it, I already did that.
[10:10] <Tm_T> GPenguin: ok, now I have seen this situation for some depth
[10:10] <Tm_T> GPenguin: any comments about this matter?
[10:15] <Tm_T> GPenguin: ok, I'll make some hot chocolate in the meantime
[10:15] <GPenguin> is it on me now to comment, or is the situation right now that popey has to justify, why he takes violent action based on wild assumptions?
[10:16] <Daviey> answer a question with a question?
[10:16] <GPenguin> i hope we are past the ethics of the old wild wild west days where you fire and forget
[10:17] <popey> GPenguin: what _exactly_ do you want to happen now?
[10:17] <GPenguin> the first step is that popey justifies his actions, then i will comment
[10:17] <popey> ok, here goes.
[10:17]  * Tm_T sips
[10:17] <popey> I believe that you are someone who has in the past been k-lined from freenode. I also believe that you are Paddy Frank. a) ban evasion. b) unsavoury person who makes threats to people.
[10:17] <GPenguin> popey: and try to avoid throwing mud and digging up old gossip. stick to facts
[10:18] <popey> ergo, I don't want you in the channel
[10:18] <popey> ^^ facts
[10:18] <GPenguin> yes, that is your assumption
[10:18] <popey> s/assumption/belief
[10:18]  * Daviey agrees with said belif
[10:18] <Daviey> belief*
[10:18] <GPenguin> and your IRC ethics are, that you take violent action based on assumption and belief?
[10:18] <popey> s/vilolent/appropriate
[10:18] <popey> yes
[10:19] <Tm_T> GPenguin: can you prove you are not this person they are talking about?
[10:19] <popey> i gave you an opportunity to say you were not paddy frank
[10:19] <popey> (although given you are him [IMO] that's tricky)
[10:19] <GPenguin> popey: my next question is - are you aware that _this_ is not acceptable regarding the Freenode Guidelines?
[10:19] <Daviey> and evading a k-line is?!
[10:19] <GPenguin> Tm_T: i dont have to prove anything. we are not in front of court.
[10:19] <popey> umm, you beat me - you broke guidelines by evading a kline
[10:19] <GPenguin> popey: assumption
[10:19] <Seeker`> what is "this"?
[10:20] <GPenguin> can you prove it?
[10:20] <popey> can I prove what?
[10:20] <GPenguin> and take note: i have to deal with 3 people the same time which is causing stress
[10:20] <popey> i can prove that you are paddy frank "beyond reasonable doubt" yes
[10:20] <popey> this conversation is pretty much proof
[10:20] <popey> IMO
[10:20] <Tm_T> GPenguin: if you don't have to prove, why popey have to prove? anyway, you are just attacking atm
[10:21] <popey> to be clear.  ;--P
[10:29] <Tm_T> glad I'm not a human
[10:29] <popey> :)
[10:29] <popey> hahah
[10:34] <Tm_T> what we should do to him in -classroom channels?
[10:35] <Seeker`> kick him?
[10:35] <Seeker`> he clearly isn't pleasent
[10:35] <Tm_T> who wants to do it? ;)
[10:36] <Tm_T> Seeker`: go ahead :)
[10:36] <Seeker`> ban as well?
[10:36] <Tm_T> why not
[10:36] <Seeker`> you sure?
[10:36] <Tm_T> he will come around soon enough but why not
[10:37] <Tm_T> lovely
[10:37] <popey> bah, i dont have ops in #ubuntu-doc
[10:37] <Tm_T> me neither
[10:41] <Seeker`> -10:39:06- GPenguin: more escalation that is absolutely not necessary
[10:41] <Seeker`> -10:39:18- GPenguin: you fail in understanding the Freenode Guidelines
[10:41] <Seeker`> -10:40:59- GPenguin: maybe what you do is useful to come closer to a friendship with popey
[10:41] <Seeker`> -10:41:17- GPenguin: but your behaviour creates any enemy as tradeoff
[10:42] <Seeker`> -10:41:36- GPenguin: thats not just weak ethics, thats dumb
[10:43] <Seeker`> I haven;t replied to him
[10:44] <Tm_T> nor need to
[11:40] <elektronik123> hello
[11:41] <elektronik123> halllo
[11:57] <elektronik123> hallo
[12:01] <jussi01> Hi
[12:01] <jussi01> elektronik123: you need to ask your question
[12:10] <elektronik123> i can`t join to #ubuntu-pl
[12:14] <Mez> elektronik123, you need to speak to pressenter who is the person that set your ban
[12:14] <Mez> there unfortunately is no bantracker for that channel, so I cant find out why this happened
[15:41] <jpatrick> LjL: oh, lord, no, Crysis is at it again
[15:42] <jpatrick> at least I think it's Crysis, same real name..
[15:46] <Pici> jpatrick: set a realname ban then?
[15:47] <jpatrick> Pici: don't worry, I've kicked him out and told him what he did wrong
[17:11] <Azag> ok
[17:11] <jpatrick> Azag: cuando te expulsaron?
[17:12] <jpatrick> no veo nada en el backlog..
[17:12] <Azag> hoy
[17:12] <Azag> hace 1 hora, o algo asi
[17:12] <Azag> si expulsan a alguien q usa la misma conexion me expulsan a mi?
[17:13] <jpatrick> ahhh
[17:13] <jpatrick> eso lo explica
[17:13] <jpatrick> TipXxi<EMAIL_ADDRESS>has left #ubuntu-es [requested by jpatrick: "no spam"]
[17:14] <Azag> TipXxi es un vecino qu se cuelga de mi Wifi
[17:14] <Azag> :(
[17:14] <jpatrick> Azag: lo siento no lo quieria hacer para ti, por no se premite spam en los canales de #ubuntu*
[17:14] <jpatrick> Azag: te quito el ban ahora
[17:14] <Azag> ok, thnx
[17:14] <Azag> le voy a decir, q pare el spam, y q deje de usar mi conexion...
[17:14] <Darksiteevil> mas bien protejela
[17:15] <jpatrick> Azag: ya esta, puedes entrar en el canal
[17:15] <Azag> gracias
[17:15] <Azag> :)
[17:15] <jpatrick> lo siento por las molestias
[17:16] <Azag> ningun problema
[17:17] <Azag> gracias y nos vemos en ubuntu-es
[18:47] <no0tic> question of the day: I banned an IP. Can a cloaked user join if he connects with that iP?
[19:02] <nalioth> no0tic: no
[19:03] <no0tic> thanks
[20:11] <Myrtti> boing
[20:12] <erUSUL> Myrtti: boing www.boingboing.net home of Doctorow XD
[20:31] <LjL> no0tic: if you ban the host, yes, if you actually ban the numeric address, no
[21:17]  * P3L|C4N0 saludos


[07:57] <dholbach> good morning
[14:48] <michagogo|cloud> rbasak: What would be the process to do that?
[14:51] <rbasak> michagogo|cloud: I'm not sure. I suggest you try the ubuntu-release mailing list, point out that bitcoin is not in testing in Debian and ask for the same in Trusty.
[14:52] <rbasak> michagogo|cloud: I'm not sure that it's actually possible, but it sounds like a reasonable request to me. Just provide the list with the same justifications.
[14:53] <michagogo|cloud> Also, as I understand it, auto-upgrading the wallet is a BDB thing, not a Bitcoin thing -- in other words, when BDB 5.1 opens a BDB 4.8 database, it upgrades it. Also, upstream specifically always uses 4.8 -- the contrib/debian/control file's Build-Depends calls for libdb4.8++-dev specifically
[14:54] <michagogo|cloud> rbasak: Is there a deadline for that to happen, by the way?
[14:55] <rbasak> michagogo|cloud: is there no way to get BDB to not do that? Eg. open read-only and check version first?
[14:55] <michagogo|cloud> (I don't want to unilaterally start making requests, I'd like to discuss it in #bitcoin-dev and/or the bitcoin-development mailing list first)
[14:56] <rbasak> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[14:56] <rbasak> michagogo|cloud: ^^ looks like Feb 20th for feature freeze. You should get it done in advance, though, since you'll need others to actually do things before that date.
[14:56] <michagogo|cloud> Right, of course
[14:56] <michagogo|cloud> Is FeatureFreeze the relevant date?
[14:58] <rbasak> It's a bit blurry for packages in universe, but I'd say that it's the most relevant point on the release schedule, yes. If it can be decided and done before then, then people shouldn't complain too much.


[13:28]  * rodrigo_ lunch
[19:36] <achiang> kenvandine: empathy-sip crash> i see the same crasher as you after attempting to dial
[19:36] <kenvandine> ok... :(
[19:36] <kenvandine> did apport fire for it?
[19:36]  * kenvandine is so glad g_debug is no longer spewing to .xsession-errors :)
[19:36] <achiang> kenvandine: no, i don't know what happened with apport. :(
[19:37] <achiang> kenvandine: i verified i have it turned on
[19:37] <achiang> but... i dunno. no worky
[19:37] <kenvandine> weird
[19:37] <achiang> kenvandine: but it is exactly the same symptom you describe: can enter in numbers to dial, but as soon as you try to dial, the windows go away
[19:37] <achiang> kenvandine: so... maybe you can catch it?
[19:37] <kenvandine> yeah
[19:37] <kenvandine> i can
[19:37] <kenvandine> thx
[19:37] <kenvandine> i'll give you a bug # when i file it
[19:39] <kenvandine> achiang, do you have contacts already added for sip?
[19:39]  * kenvandine doesn't see a way to add those, so maybe you can't
[19:39] <kenvandine> i was wondering if it crashes from calling from a contact instead of dialing
[19:41] <achiang> kenvandine: hm, no, i wasn't calling a contact
[19:41] <achiang> kenvandine: it was just dialing
[19:42] <kenvandine> achiang, is there a way to add a sip contact to your contact list?
[19:42] <achiang> let me try
[19:42] <kenvandine> i couldn't do it... the sip account wasn't available in the add contact dialog
[19:43] <kenvandine> which seemed weird to me
[19:43] <achiang> kenvandine: i see the sip account, but it is greyed out and does not let me select it
[19:43] <kenvandine> same here
[19:45] <kenvandine> the crash is in empathy_contact_get_account
[19:46] <achiang> maybe it's crashing because there is no account
[19:47] <kenvandine> perhaps, i think it is a g_return_if_fail on the account
[19:47] <achiang> kenvandine: i'll add you on g+
[19:47] <kenvandine> just not sure why the account isn't valid
[19:47] <achiang> and see about calling you. :)
[19:48] <kenvandine> hang on... i have empathy in gdb... not going to work for making calls right now :)
[19:48] <achiang> kenvandine: oh, i did add you, but maybe didn't get added back
[19:48] <achiang> or rather, you don't appear in my contacts list
[20:49] <dobey> kenvandine: can i bug you for some sponsoring? :)
[21:06] <kenvandine> achiang, bug 907916
[21:06] <ubot2> Launchpad bug 907916 in folks "empathy crashed with SIGSEGV in empathy_contact_get_account()" [Undecided,New] https://launchpad.net/bugs/907916
[21:07] <achiang> thx
[21:07] <kenvandine> np
[21:07] <kenvandine> seems upstream is already looking at it
[21:07] <kenvandine> dobey, perhaps, is it an easy one?
[21:07] <dobey> kenvandine: i would suspect they're all easy… how do you define easy? :)
[21:08] <dobey> one is a new source package for universe
[21:08] <kenvandine> something that won't take long to review... and not an SRU
[21:08] <dobey> the rest are updates to precise
[21:08] <dobey> no, it's all precise
[21:08] <kenvandine> dobey, i can take a swing at them
[21:08] <dobey> https://bugs.launchpad.net/ubuntu/+bug/907888 is the new package one
[21:08] <ubot2> Launchpad bug 907888 in ubuntu "[needs-packaging] dirspec" [High,In progress]
[21:08] <kenvandine> dobey, might be later tonight though
[21:09] <kenvandine> the new package i probably won't be able to do before the break... i am scrambling to do a bit too much right now
[21:09] <dobey> ah ok
[21:09] <kenvandine> not to say i won't do it over the break :)
[21:10] <kenvandine> but i usually try to do fun work over the break :-p
[21:10] <dobey> yeah i'm just trying to get it all in before, since the day i come back from back, we'll be doing another set of releases :)
[21:19] <dobey> kenvandine: and in the future you won't really have to sponsor, since i'm going to push to get us a delegated team for u1 :)
[21:36] <dobey> doh; found a typo in the new package, and launchpad is being evil right now