[02:10] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/distroseries-spec-preload/+merge/180046 is updated, and it failed ec2 last night, but the only failures were related to builders and Fault 8002.
[02:12] <wgrant> StevenK: When last night did you start it?
[02:12] <wgrant> I thought I fixed the 8002s in the early afternoon.
[02:12] <wgrant> Hum
[02:12] <wgrant> No, 21:06
[02:12] <StevenK> wgrant: It finished at 9pm, so 5ish
[02:12] <wgrant> Right, so you had the bad lpbuildd
[02:12] <wgrant> So that's fine
[02:12] <wgrant> I'll review after lunch
[02:12] <wgrant> :)
[02:13] <StevenK> wgrant: Than microservices!!
[02:13] <wgrant> I'm melting strawberry atm.
[02:16] <StevenK> Poor strawberry
[04:08] <StevenK> wgrant: It's after lunch; good news, bad news, no news?
[04:54]  * StevenK takes that as 'no news'
[05:09] <wgrant> Soon soon
[05:09] <stub> StevenK: You can review my branches if you are bored ;)
[05:36] <wgrant> StevenK: I've done a bit of testing of buildd-manager on DF.
[05:36] <wgrant> Have you looked at all?
[05:36] <StevenK> I have not.
[05:36] <wgrant> I think it's probably OK to deploy, particularly now that the ARM buildds don't suck; slightly overzealous error handling isn't going to be a huge problem any more.
[05:37] <StevenK> The pandas are still around, just manualed, right?
[05:37] <wgrant> I believe they're inactived.
[05:37] <wgrant> But probably not actually switched off yet.
[05:37] <wgrant> Yeah, still not there on /builders.
[05:37] <StevenK> They seem to be gone, indeed
[05:37] <StevenK> We probably need a fitz, though
[05:39] <StevenK> wgrant: If the new stuff works fine with un-upgraded buildds, then I agree about the error handling, and we should deploy.
[05:45] <wgrant> If something goes terribly wrong we can always undeploy :)
[07:09] <StevenK> wgrant: WRT lines 125-127, the method involved is one that deletes workitems that aren't referenced any more and is only called by updateWorkItems. I wanted to be certain it grabbed whatever was latest. But I can change it to use the cached version if you wish.
[07:13] <wgrant> StevenK: I thought the one I pointed out was in workitems_text
[07:13] <wgrant> The one after was updateWorkItems
[07:13] <wgrant> But I may be wrong
[07:14] <StevenK> The one after is lines 134-137
[07:15] <StevenK> That one doesn't used the cached version since we just deleted non-matching workitems, and the old code duplicated the method anyway.
[07:15] <StevenK> And we blow the cache away at the end of the method anyway
[07:16] <StevenK> wgrant: workitems_text is lines 88-89 and 97-102
[07:16] <StevenK> And does make use of the cached property, for obvious reasons.
[07:16] <wgrant> Ah, you're right
[07:16] <wgrant> I was looking at the wrong part of the file.
[07:17] <StevenK> wgrant: Your objection is withdrawn?
[07:17] <wgrant> Indeed
[07:18] <StevenK> wgrant: I'm looking into your suggestion about rewriting the horrible double loop
[07:20] <StevenK> wgrant: Blah, I forgot about a comment I rewrote to be less like a novel, but: http://pastebin.ubuntu.com/6005501/
[07:21] <wgrant> StevenK: That makes a lot less nonsense.
[07:22] <StevenK> I didn't want to stuff around with going back from specid in work_items_by_spec.keys() to spec so I could get a cache -- if the spec id isn't in work_items_by_spec it returns [] anyway since it's a defaultdict.
[07:23] <wgrant> StevenK: Oh, since you're going through rows this time you can remove the code that presets the work_items cache to []
[07:24] <StevenK> Good point, killed.
[07:24] <StevenK> I shall push and land


[00:14] <veebers> elopio: good question, I print_tree'd the unity proxy object and found it that way
[00:15] <veebers> elopio: I'll see if I have any logs left over that I cn use to find ie, otherwise I'll have to suggest you generate the log sorry (don't have a device handy right now)
[00:15] <elopio> veebers: that's ok. I can do the print and grep.
[00:16] <veebers> elopio: ah, I found this snippet, I presume it's correct :-) http://paste.ubuntu.com/9826927/
[00:16] <veebers> elopio: sorry I couldn't be of any more direct help
[00:17] <elopio> I tried that and didn't work. I'll retry, I might have done something wrong.
[00:18] <veebers> elopio: hmm, also try grep __orientationAngle in the ubuntu ui tk sources
[00:45] <knome> balloons, until i forget this... i think we should have two main "paths" in the QA docs
[00:46] <knome> balloons, the other being for new contributors, that's the "Roles" path, which is pretty well laid now up until the actual documentation on how to get started
[00:46] <knome> balloons, and the other being the "toolbox" for advanced people working with stuff
[00:46] <knome> balloons, the latter should have probably most of the links to tutorials and stuff handy at least
[00:47] <knome> balloons, but in a more concise format... and if anything is explained there, then we should be able to expect they know the basics already
[00:48] <knome> balloons, in addition to those, we'll of course have the calendar and contact stuff, but that's just general information
[00:53] <knome> balloons, and as you might have noticed, didn't mention the FAQ... because i believe it was only needed (if it was) because the new contributor documentation was a bigger mess than it is now, and what we want to make it
[01:41] <balloons> knome, interesting. I'm not sure how this toolbox would look, and it's interesting you would want to put tutorials in the advanced section
[01:41] <balloons> i'm ok with the thought on the faq
[01:42] <knome> balloons, don't overthink it... just consider it as a landing page for most of the content we have scattered around
[01:43] <balloons> hmm ok, I'm seeing something
[01:44] <knome> again, since it's for people who are already sticking around, we don't need the bling, we just need it to work
[01:46] <elopio> veebers: it's finally working the rotation.
[01:46] <veebers> elopio: oh cool, what was the issue
[01:47] <elopio> the set up is a little complex, we need two threads running at the same time.
[01:47] <elopio> ricmm has pushed the code. I have some details in my phone that I will push, and then I will ask you to make a new review.
[01:48] <elopio> I need to clean up my tweaks to use threading instead of thread, and a wait instead of a sleep.
[01:48] <elopio> but I could use the four orientations and the app turns around.
[01:54] <veebers> elopio: why the 2 threads? Also, I refreshed the MP and I'm a little concern that the fixture is starting unity but UnityTestCase start unity by default (unless you set an obscure member variable). I think that should be improved
[01:54] <veebers> but I don't have an answer for it right now
[01:54] <elopio> veebers: UnityTestCase doesn't start unity. IndicatorTestCase does. We need to change that.
[01:54] <veebers> perhaps (if it doesn't already exist) create a decorator for the unity tests to wrap around the setting of that flag
[01:55] <elopio> and the thread is because while unity is starting, we need to put some content on the sensors fifo.
[01:55] <elopio> otherwise, unity will wait forever.
[01:55] <elopio> and we can't put the info before because the fifo file needs the unity pid.
[01:56] <veebers> elopio: ah right, I could have sworn that the testcase started unity (I had to do something with the sanity tests suites from prev sprint
[01:56] <veebers> )
[01:57] <elopio> I'm going to take a big break now. bbl.
[01:57] <veebers> elopio: I might not be online when you get back
[01:58] <veebers> have a good weekend elopio. You did great work this sprint!
[01:59] <elopio> veebers: yeah, I will probably finish tomorrow, but this won't land before your monday. You will have plenty of time to look at it and request more things from ric.
[01:59] <elopio> veebers: thanks! you too.
[02:17] <veebers> elopio: fyi have re-reviewed (and by accident 'approved' it (then re-commented with the NFing)
[02:22] <knome> off to sleep, nighty everybody and balloons, get some rest as well, you sleepy man ;)
[02:26] <balloons> night knome !
[12:32] <elfy> balloons knome - front page for manual testcases - or at least a start ... https://wiki.ubuntu.com/Elfy/Sandbox
[12:36] <knome> elfy, looks good to me
[12:37] <knome> though i'd probably cut off the contact stuff and just go on with the actual content if this was to be the testcases startpage
[12:37] <knome> the page will have the QA header where we have the contact link anyway
[12:38] <elfy> the learn more bits?
[12:38] <knome> If you want to talk to someone about manual testcases then there are 2 main ways to do so.
[12:38] <knome> We recommend subscribing to the Ubuntu Quality mailing list.
[12:38] <knome> Also consider stopping by on IRC and saying hello in realtime! We hang out in the #ubuntu-quality IRC channel on the Freenode IRC network.
[12:38] <knome> that
[12:39] <knome> and unless you plan to extend the previous section, that too probably
[12:39] <knome> since we go through what is required to do X in the roles documentation
[12:39] <elfy> oic - well I did think about that - but I added them because someone might bookmark that page and not others
[12:39] <knome> in that case we should have the contact info on every page
[12:39] <elfy> but not that bothered on the otherhand
[12:39] <knome> that gets repetitive quickly
[12:40] <knome> and if it's always at the top... it'll look like we only care about those things, not the content
[12:40] <elfy> ok - can see that
[12:40] <knome> if we feel like that's needed, we can design a contact footer or sth
[12:40] <elfy> how about on pages that aren't the front page - making Ubuntu Quality at the top a link to the main page
[12:40] <knome> but tbh i'd just trust people being able to connect the dots and see the contact page :P
[12:41] <knome> just include the QATeam header on every page that is in the QATeam tree/path
[12:41] <knome> unless it's clearly a common page, in which case just leave it
[12:42] <knome> and by tree/path i mean every page that is discoverable just by looking at the QA wiki and wondering what you should do
[12:44] <elfy> looks ok with the header imo
[12:44] <elfy> changed it
[12:44] <knome> yep
[12:45] <elfy> \o/
[12:46] <elfy> need seperate pages for manual and automated perhaps now
[12:46] <elfy> this one being the new manual page
[12:46] <knome> well, you could also lay them on top of each other
[12:46] <knome> but sure, many of the actual content links are different
[12:46] <knome> but i'm not opposed to separating them either
[12:47] <elfy> no idea what you mean - currently both are at https://wiki.ubuntu.com/QATeam/ContributingTestcases
[12:47] <knome> yeah, that's icky
[12:47] <knome> just separate
[12:47] <knome> as long as the content is good... :)
[12:47] <elfy> https://wiki.ubuntu.com/QATeam/ContributingTestcases/Manual_Testcases
[12:48] <elfy> that?
[12:48] <knome> you lost me
[12:48] <knome> :D
[12:49] <elfy> that ok as the new page url?
[12:49] <knome> just overwrite the current
[12:49] <elfy> mmm
[12:49] <knome> we'll save one redirect
[12:49] <elfy> the current includes automated
[12:50] <knome> https://wiki.ubuntu.com/QATeam/ContributingTestcases/Manual
[12:50] <knome> nope
[12:50] <knome> hmm, right, that's used for a different usecase
[12:50] <elfy> that's the page linked to from the front page at Writing :)
[12:50] <knome> just move that under /Writing
[12:51] <knome> and replace it with the new page
[12:51] <elfy> ok
[12:51] <knome> if people have bookmarks, it's easy enough to update them since the new page is clean
[12:51] <elfy> you're making no sense - need tea ...
[12:51] <knome> heh
[12:51] <knome> once that's done, let's link directly to that page from the testwriter role page
[12:51] <knome> currently we link to the mishmash page
[12:52] <knome> that being https://wiki.ubuntu.com/QATeam/ContributingTestcases
[12:56] <elfy> https://wiki.ubuntu.com/QATeam/ContributingTestcases/Writing being the new page ?
[12:56] <knome> no
[12:56] <knome> let me try to be clear:D
[12:56] <elfy> that'd help :D
[12:57] <knome> ~ = ContributingTestcases
[12:57] <knome> that clear?
[12:57] <elfy> yep
[12:57] <knome> so move ~/Manual  to  ~/Manual/Writing
[12:57] <knome> then replace ~/Manual with your new landing page
[12:57] <elfy> right
[12:58] <elfy> I did the one you said no to - so that'll need deleting :p
[12:58] <knome> then let's link directly to ~/Manual, not ~, from the role page (i can do that)
[12:58] <knome> oki, i'll do that
[12:58] <knome> done
[12:59] <elfy> hang on
[12:59] <knome> yes?
[12:59] <elfy> I can't replace /Manual with the new landing page
[12:59] <knome> you must manually copy the contents
[12:59] <elfy> not what I mean
[12:59] <knome> oh...
[12:59] <knome> why can't you then? :)
[13:00] <elfy> oh right - just need to update links in the new landing page - as one of those links to /Manual currently
[13:00] <knome> heh, yeah
[13:00] <elfy> I've got so many wiki pages open currently ...
[13:00] <knome> i know
[13:00] <knome> it's horrible
[13:00] <knome> especially with only one monitor..
[13:00] <elfy> yea :)
[13:02] <knome> updated https://launchpad.net/ubuntu-manual-tests
[13:03] <knome> eh
[13:03] <knome> not that!
[13:03] <knome> https://wiki.ubuntu.com/QATeam/ContributingTestcases
[13:03] <knome> that
[13:03] <knome> now only has a link to that new landing page and to the lp project page
[13:05] <elfy> ok - done that now
[13:05] <knome> goodie
[13:05] <knome> it's good to see things moving forward again..
[13:05] <elfy> so /Manual is now a landing page
[13:05] <knome> yep
[13:05] <elfy> and /Man/Writ has the old stuff in it
[13:05] <knome> and it's linked to from https://wiki.ubuntu.com/QATeam/Roles/TestWriter directly
[13:05] <knome> so no more detour
[13:05] <knome> ++
[13:06] <elfy> yep
[13:06] <knome> i'll give https://wiki.ubuntu.com/QATeam/ContributingTestcases/Launchpad a slight nudge next
[13:07] <elfy> I'm just going to work through the pages on the new landing page today
[13:07] <elfy> so you can leave that if you like
[13:07] <knome> nah,
[13:07] <knome> it'll only need a visual update tbh
[13:08] <elfy> ok - I'll wait and see what you do then before I fiddle with the others - at least make pages we're freshening up look the same (ish)
[13:08] <elfy> if nothing else we'll all know which ones have been looked at :p
[13:08] <knome> i'll make it look like https://wiki.ubuntu.com/QATeam/DevelopmentSetup
[13:09] <elfy> right
[13:09] <elfy> lunch time I think
[13:09] <knome> ok, bon appetit :)
[13:47] <elfy> knome: so at the moment - the new landing page is a bit circular - points to contributing test cases - which then points to it
[13:48] <elfy> though contributing does include automated as well
[13:49] <knome> heh
[13:49] <knome> i'd say remove all links back to the upper level
[13:49] <knome> so - lose the first box
[13:51] <elfy> yea was trying - that's the trouble with complicated wiki syntax and copy pasting it
[13:52] <elfy> so I gave up for the moment :)
[13:52] <knome> hehe
[13:52] <knome> i can do it
[13:53] <knome> what happened
[13:53] <knome> oh
[13:53] <knome> heh
[13:53] <knome> i fail
[13:54] <knome> only took three edits :)
[13:54] <elfy> heh
[13:54] <knome> and fourth to fix the padding
[13:55] <elfy> really not sure about the contact icon ... perhaps it's me - but it looks like it's stoned
[13:56] <knome> haha
[13:56] <knome> a bit
[13:56] <knome> fortunately we can change it ;)
[14:04] <knome> fwiw, i think QATeam/ContributingTestcases/Launchpad should be renamed to probably QATeam/DevelopmentToolsSetup
[15:19] <elfy> knome: yea - I'd probably agree with that - I'd say that QATeam/ContributingTestcases/ManualStyleGuide/test_case_format_script could be on the same page tbh
[15:19] <knome> yep
[15:20] <knome> so maybe the page should be named DevelopmentTools
[15:21] <elfy> the launchpad one?
[15:22] <elfy> and add the script to that - makes sense to me
[15:22] <knome> yep
[15:23] <knome> then it could be the number one place for all development tools
[15:23] <elfy> yep +1 to that
[15:25] <knome> working on that now
[15:27] <knome> actually...
[15:28] <knome> i think the script should be in the ubuntu-manual-tests repository
[15:28] <elfy> that's a different kettle of fish altogether
[15:31] <knome> sure, i can handle that
[15:32] <teward> where's the qa tracker for Alpha 2?  (lost bookmarks due to hardware glitch)
[15:32] <knome> alpha 2 is released
[15:32] <teward> knome: i still need the tracker :P
[15:32] <teward> for future
[15:33]  * teward lost the link in bookmarks and history due to disk corruption
[15:33] <knome> which qa tracker? ISO?
[15:33] <teward> yep
[15:33] <knome> http://iso.qa.ubuntu.com/
[15:33] <teward> knome: thank you kindly
[15:34] <teward> knome: main reason for wanting it was to see what bugs were happening.
[15:34] <teward> :)
[15:34] <elfy> http://iso.qa.ubuntu.com/qatracker/reports/defects
[15:35] <elfy> would be better then - that's got reported bugs on it
[15:35] <teward> elfy: wanted to see it with the specific testcases
[15:35] <teward> either works
[15:36]  * balloons sees more boxes :-)
[15:36] <knome> just set up QATeam/DevelopmentToolsSetu
[15:36] <knome> +p
[15:36] <elfy> I see ticky tacky balloons
[15:36] <teward> knome: stuck on Windows, otherwise I would.
[15:36]  * knome pops a balloon
[15:36]  * teward isn't on his own computer right now
[15:36] <knome> teward, would what?
[15:37] <teward> knome: set up the dev tools on that page
[15:37] <teward> can't do anything from campus systems >.>
[15:37] <knome> no.. i meant i just set that page up.
[15:37] <teward> ahh
[15:37] <teward> oh joy, my computer asploded >.>
[15:37] <knome> balloons, so, what about pushing the format testing script to the branch?
[15:38] <knome> "sudo mv test-case-format /usr/local/bin" is.... uhh
[15:38] <balloons> knome, elfy I would be down for including a readme in the branch as well explaining it, etc :-)
[15:38]  * balloons doesn't move it to bin
[15:39] <knome> i'm sure there would be other ways to check the markup than having to depent on vim too
[15:50] <sak> Hello guys, I applied some grammar fixes this wiki page, https://wiki.ubuntu.com/QATeam/Overview/TheStages#preview. Have a look at it.
[15:57] <balloons> thanks sak
[15:58] <sak> welcome ;-)
[16:04] <elfy> balloons: I had a question a while back which I'd forgotten - unfortunately for you I've now remembered it :)
[16:05] <elfy> what is all this stuff doing sitting in testcase/images? especially all the ones un-numbered and I guess not on the tracker
[16:05] <elfy> http://bazaar.launchpad.net/~ubuntu-testcase/ubuntu-manual-tests/trunk/files/head:/testcases/image/ubuntu%20touch/
[16:06] <sak> If I installed an alpha release using a CD/DVD disc to test on hardware, but would like to test other milestone releases, can I update my installed release to the next milestone release?
[16:08] <balloons> elfy, how interesting. I guess at some point it was to be used. We could remove it
[16:08] <balloons> as you said, it is not on the tracker
[16:08] <balloons> sak, yes once you've installed it, update it like any other normal installation of ubuntu. The updates just come in much more often :-)
[16:09] <balloons> if you wish to test the next version via installation, you can do that at that time as well
[16:09] <elfy> sak: there is no milestone for testing now until beta 1
[16:09] <balloons> depends on the flavor, but for ubuntu, nothing until final beta
[16:10] <elfy> as soon as it's a new day and new updates - your using the daily
[16:10] <elfy> balloons: and that too :)
[16:12] <sak> Ok, balloons and elfy. I read that is recommended to test milestone releases on actual hardware not just a virtual machine. Yet, I don't have a usb drive at the moment. Plus I prefer to use hardware.
[16:12] <sak> I will only test milestones on hardware, dailies on a virtual machine
[16:18] <knome> elfy, "you're"
[16:18] <elfy> pffft
[16:18] <elfy> I'm lazy :p
[16:28] <sak> Lazy is good :-)
[16:31] <balloons> WHOA! present for me.. someone else on the internet used your for you're
[16:32]  * balloons feels SLIGHTLY less bad about his inability to speak his native language
[16:35] <elfy> I have it on the phone balloons
[16:35] <elfy> speeling or grummer error now and again to cheer balloons and knome up :)
[16:49] <alesage> elopio I see that our two pairing tasks are still marked as todo, do we intend to move them over?
[16:54] <elopio> alesage: not sure. We didn't define a good acceptance criteria for those.
[16:55] <balloons> ok, round two for https://wiki.ubuntu.com/Jams/Testing. I'm happy with it now
[16:55] <elopio> alesage: charles said that his bootstrapping was succesful
[16:55] <alesage> elopio, yes in our last Wed. meeting
[16:55] <charles> indeed
[16:56] <elopio> paulliu: do you think that with the work we did these two weeks, you'll be able to keep writing these tests and teach your team how to do it?
[16:59] <alesage> elopio, I took the liberty of moving charles' and my card
[16:59] <elopio> alesage: yes, thanks.
[16:59] <elopio> alesage: pdf should go back to the TODO pile, right?
[17:00] <alesage> balloons, it's under review, waiting on Jenkins https://code.launchpad.net/~canonical-platform-qa/autopilot/pdf-build/+merge/247249
[17:00] <alesage> oops elopio ^^
[17:00] <alesage> was just going to welcome a balloons review of that pdf generation for autopilot docs
[17:10] <balloons> alesage, care to add json in there too, hehe?
[17:10] <balloons> I have a bug for getting json output, and since it's post sprint and you are adding things  . . .
[17:10] <alesage> balloons let's make a new card for that :) #rainmakingFTW
[18:02] <dobey> balloons: hi. do you know how i can have adt-run use the tests from the local tree on a click package?
[18:06] <dobey> or anyone?
[18:06] <balloons> dobey, indeed. pass the folder as the first argument to adt-run
[18:06] <dobey> balloons: so adt-run . --click=../foo.click?
[18:07] <balloons> yep
[18:07] <dobey> someone needs to fix the docs if that's true
[18:08] <dobey> because --click-source=. doesn't seem to work, and that's what --help suggests to use
[18:09] <balloons> ohh really? bug filing time if so.. the args can be specified multiple ways generally
[18:38] <dobey> hmm, does self.launch_click_package() require the full app triplet with version #?
[18:54] <dobey> balloons: ok. so --click-source works, but only if it's *before* the --click argument. :(
[18:55] <dobey> so that seems like a bug, yeah
[18:58] <balloons> dobey, ahh.. I always used it before and parse order is clearly important. I wonder if it has to be
[19:00] <dobey> balloons: there's no good reason for these arguments to be required to be in a specific order
[19:01] <dobey> balloons: anyway, i filed bug #1414122 about it
[19:01] <balloons> excellent
[19:02] <dobey> now, why is self.launch_click_package('') timing out
[19:02] <dobey> hmm, maybe i can't use that
[19:20] <balloons> dobey, should just be app_proxy = self.launch_click_package( "com.ubuntu.music")
[19:21] <dobey> balloons: maybe it's because for payui to 'work' we have to actually pass it a uri?
[19:22] <balloons> dobey, you can pass it a uri too
[19:22] <balloons> http://paste.ubuntu.com/9838894/
[19:23] <dobey> ah ok
[19:51] <dobey> gah, argument parsing order dependence strikes again :(
[20:08] <dobey> ** (run.py:4869): WARNING **: Unable to connect to Upstart bus: The given address is empty
[20:08] <dobey> hrmm, and that's not helpful :(
[21:37] <Letozaf_> balloons, hi
[21:37] <Letozaf_> https://code.launchpad.net/~carla-sella/ubuntu-rssreader-app/fixing-flaky-test/+merge/247482
[21:38] <Letozaf_> balloons, I am trying to fix the flaky tests, but now they pass :) and I fixed only one of them theoretically
[21:38] <Letozaf_> balloons, what do you do in these cases ?
[21:41] <balloons> Letozaf_, fixing one might have been enough.. sometimes the following tests failed because of one. That said, keep going if there's more to fix
[21:41] <Letozaf_> balloons, ok
[21:41] <balloons> trunk *sometimes* did work, so :-)
[21:42] <Letozaf_> balloons, yeah that's why I was wondering what to do, how do I know if it will fail again :-P
[21:46] <balloons> Letozaf_, getting it to pass locally in the sandbox is a good start
[21:46] <balloons> I can help try to break it once you are done :-)
[21:47] <Letozaf_> balloons, ok thanks, on my desktop it passes also in sandbox when I've finished I will let you try to break it
[21:48] <balloons> that sounds awesome :-)
[21:48] <Letozaf_> :)