[12:13] <ara> jcollado: hey!
[12:14] <jcollado> ara: Hola
[12:14] <ara> jcollado: I just wanted to ask you about your comment on mago vs. libmago
[12:14] <ara> don't you really think it will be confusing to have both as "mago"
[12:14] <ara> ?
[12:14] <davmor2> hello all
[12:15] <jcollado> ara: What's the difference between mago and libmago?
[12:15] <ara> hey davmor2
[12:16] <ara> jcollado: mago is the whole framework, meaning: the library, the runner and the tests. libmago would be just the library
[12:17] <jcollado> ara: Then we might use python-mago
[12:17] <ara> jcollado: yes, that's another possibility
[12:18] <jcollado> ara: Other thing to take into account if we proceed with the changes regarding the test suite discovery
[12:18] <jcollado> ara: is that the runner is now port of the library. Should we split the library in two different parts?
[12:19] <ara> jcollado: mmm, tricky...
[12:21] <ara> jcollado: here, the question behind would be: does it make sense to have the library installed without the runner?
[12:21] <ara> jcollado: I think it does
[12:22] <jcollado> ara: As long as it's possible to run the test cases without the runner, yes.
[12:23] <ara> jcollado: well, not the "test cases" as we use it now, but it would be possible to use the library as a standalone library to create scripts without the testcases library if people want to
[12:23] <ara> jcollado: not as something that we encourage to do, but as technically possible
[12:24] <jcollado> ara: Then the library should contain only the applications part, but not the runner and the test suite part
[12:26] <jcollado> ara: Do you agree?
[12:30] <ara> jcollado: I think that both solutions have pros and cons
[12:31] <jcollado> jcollado: Maybe we can move this discussion to the maillist so that everybody can think about it
[12:32] <jcollado> ara: ^
[12:32] <ara> jcollado: :D
[12:32] <jcollado> Working at home is bad. You may eventually talk to yourself.
[12:32] <ara> jcollado: yes, but first I would like to merge the mago branch to trunk, announce it in the mailing list, and then discuss the rest of the stuff
[12:33] <jcollado> ara: OK. I understand the priorities
[12:33] <ara> jcollado: I will rename desktoptesting to mago, if you think is more appropriate, and then discuss the rest of the things
[12:33] <ara> jcollado: is that ok?
[12:33] <jcollado> ara: Sure
[12:45]  * ara -> lunch
[14:42] <Opr8iVe> Good morning!
[14:51] <davmor2> hello
[14:56] <Opr8iVe> Was wondering if youall wanted install results for 9.04 unr on the brand new Dell Mini10v
[14:57] <Opr8iVe> if so, where would an apropriate place be to submit that?
[14:59] <persia> Opr8iVe, We've completed the test phase for the 9.04 images (which is why they are shipped).
[14:59] <persia> That said, if the overall experience is not so good, the best thing to do is file bugs.
[15:00] <Opr8iVe> Yes, but theres a list of known compatable / issues hardware there, and the new Dell Mini 10 series isnt listed
[15:00] <persia> If the overall experience is good, and you're up for reverifying it during the karmic cycle, so 9.10 can be even better, there's a wiki page.
[15:01] <Opr8iVe> The install went great! Once I figured out that Imagewriter chokes if theres spaces in the path to the image file.
[15:01] <persia> Which imagewriter did you use?
[15:01] <Opr8iVe> whatever 9.04 apt-get gave me
[15:01] <Opr8iVe> Im not at that computer right now, so I can't be sure
[15:02] <persia> OK.  When you can find out, please file a bug.  That should be fixed.
[15:02] <persia> If it works great, please add notes on https://wiki.ubuntu.com/HardwareSupport/Machines/Netbooks
[15:02] <Opr8iVe> ah.. cool.. thats what I was looking for.. Thanks!
[15:03] <persia> We'd appreciate it if you'd also volunteer to help test the Alpha and Beta images for the 9.10 release as they become available, to maintain the documentation on that model.
[15:03] <persia> (right now, Jaunty is the right thing to have documented.  Come 9.10 beta (or maybe a bit earlier), there will be an effort to update the page.
[15:04] <persia> And, once there's so many models there it becomes hard to track, we'll drop the page, and no longer have to warn people that it may not work on some models.
[15:04] <Opr8iVe> Sure.. Tho, Im no *nix guru.. I've played with it for years on and off, but am comfortable with the cli
[15:04] <Opr8iVe> Been (almost) windows free for 1.5 years now
[15:05] <Opr8iVe> wife still needs some convertin' :)
[15:05] <persia> Excellent.  The milestone schedule is at https://wiki.ubuntu.com/KarmicReleaseSchedule
[15:06] <persia> We usually start testing (in this channel) on the Tuesday for a given Thursday milestone, just to knock out the kinks.
[15:06] <charlie-tca> Is the tracker going to be updated for alpha 2?
[15:06] <persia> So, the Alpha 2 image testing ought start sometime soonish.
[15:06] <persia> charlie-tca, That's a good question.  One hopes so, as it's that time.
[15:07] <Opr8iVe> Rather relentless schedual yall keep, heh..
[15:07] <charlie-tca> My thought, exactly. Supposed to release tomorrow
[15:08] <persia> Opr8iVe, Well, we need to test quite a bit to be able to make sure that we have a decent release each six months.  Most of the "Alpha" milestones generate *lots* of bugs, but as we get closer, it becomes more just making sure nothing big broke since last time, and the big bugs from last time are really closed.
[15:10] <charlie-tca> bbl
[15:16] <Opr8iVe> okay.. Im gonna fire up the ubuntu partition.. Probably be back later.
[17:27] <slangasek> alpha2 candidate images posted
[18:15] <slangasek> and back down again, grub-pc was missing from the disks
[18:38] <eeejay> hey cr3?
[18:40] <cr3> eeejay: yo
[18:41] <eeejay> cr3, i am having a hard time deciding how we should be harvesting mago results in checkbox
[18:41] <eeejay> cr3, should i have it embedded in test.description?
[18:43] <cr3> eeejay: can you pastebin or upload the output of mago?
[18:43] <eeejay> cr3, the test results in mago don't go to stdout, they are written to a result file
[18:44] <cr3> eeejay: right, that output :)
[18:44] <cr3> eeejay: I have a feeling it is similar in concept to lsb which also creates some result file in its own format
[18:44] <eeejay> cr3, first of all, this is the last log line, after running a mago script: http://paste2.org/p/258493
[18:45] <cr3> eeejay: the solution is essentially to parse the result file and create new test instances for each test parsed: test = Test(None, name=entry["section_name"], description=entry["subsection_name"], plugin="lsb", suite=self.test.name)
[18:45] <cr3> eeejay: that example was taken from the lsb_prompt plugin in checkbox-certification
[18:45] <eeejay> cr3, ah. i will look more closely at that
[18:46] <cr3> eeejay: so, "yes" to your original question but, just to be clear, not necessarily through assignment (test.description = "foo") as much as through instantiation (above example)
[18:46] <eeejay> cr3, ok. gotcha
[18:47]  * eeejay looks at lsb things
[18:47] <cr3> eeejay: you can then create a test result object like this: TestResult(test, status, entry["log"], entry["duration"])
[18:47] <cr3> eeejay: to make things easier for you, simply search for _journal_entry_to_result
[18:48] <cr3> where "journal" is the name given by the lsb folks for their output file
[19:34] <cr3> eeejay: by the way, remember that you need to fire report-test and report-result evens so that other plugins might know about your new instances
[19:35] <eeejay> cr3, ah ok
[19:35] <eeejay> cr3, thanks for the png
[19:35] <eeejay> cr3, i hung it over my bed
[19:36] <cr3> eeejay: are you now settled in seattle?
[19:36] <eeejay> cr3, still looking for a house and such
[19:37] <cr3> eeejay: so when you say "bed", do you mean "cardboard box under a bridge"? :)
[19:37] <eeejay> cr3, no - we have homeless shelters here in seattle.
[19:37] <cr3> too bad, I have lots of good tips for living in a box
[19:38] <eeejay> cr3, hah
[19:38] <cr3> for example, gerbils are not only a good source of protein but they can also serve as entertainment too
[19:39] <eeejay> cr3, i think it will be cleaner if i subclass TestCommand in the MagoInfo plugin
[19:39] <eeejay> cr3, as opposed to MagoPrompt
[19:39] <eeejay> bye ara!
[19:40] <cr3> eeejay: that might preferable but it breaks my heart seeing integrators having to know so much about the core :(
[19:40] <eeejay> cr3, too late. i have a book deal with o'rielly
[19:40] <cr3> fortunately, the core isn't too big, but it's more than I feel comfortable exposing
[19:41] <cr3> "Checkbox: the good, the bad and the ugly"
[19:41] <cr3> make sure you have a good pic of me for the introduction to the "ugly" chapter
[19:41] <eeejay> "Control your Roomba with Checkbox"
[19:44] <eeejay> cr3: http://paste2.org/p/258692
[19:46] <cr3> eeejay: yeah, SystemExit was evil
[19:47] <eeejay> cr3, SystemExit is my addition. on't know how you want to deal with it, but it would be nice to be able to kill checkbox when it has a lingering thread
[19:50] <cr3> eeejay: ah, I used to do sys.exit(1) when KeyboardInterrupt was caught. one moment, I'll check why I removed that
[19:55] <cr3> eeejay: I made a related fix for bug #327810 in revno 457
[19:55] <ubot4> Launchpad bug 327810 in checkbox "Interrupt signal not handled properly for cli and gtk interfaces" [Medium,Fix released] https://launchpad.net/bugs/327810
[19:56] <cr3> eeejay: I'll check if introducing that signal doesn't revert the bug
[19:57] <eeejay> cr3, Test.command is confusing
[19:57] <eeejay> cr3, it is a string for a second, and then a TestCommand instance
[19:58] <cr3> eeejay: yeah, Test.description too. not one of my proudest moments
[19:59] <eeejay> cr3, i have had some low moments myself, besides living in a homeless shelter
[20:01] <cr3> eeejay: what behavior changes when you wrap the thread.join call in a try/catch block? I'm running checkbox in cli and gtk mode and I'm not observing that much difference
[20:02] <cr3> I think what we want is for the parent thread to also exit in the event the child is killed
[20:02] <eeejay> cr3, right
[20:02] <eeejay> cr3, i press ctrl+c
[20:02] <eeejay> cr3, get a KeyboardInterrupt stack trace printed
[20:02] <eeejay> cr3, but all keeps running
[20:02] <cr3> it doesn't seem like the exception is being propagated though. if I hit ctrl-c in cli mode when pulsating, I get thrown to the final prompt
[20:02] <eeejay> cr3, and then i press ctrl+c a gazzilion times in anger, but nothing
[20:03] <cr3> I get a similar behavior when I kill the pulse window in gtk mode... final propmt
[20:03] <eeejay> cr3, ok. so we misunderstood each other
[20:03] <eeejay> a term signal should terminate the entire deal, imho
[20:04] <cr3> moment... call
[20:04] <eeejay> cr3, when i get this mago crap working you could experiment with that. they are more complex processes than the usual scripts checkbox runs
[20:43] <eeejay> cr3: https://code.launchpad.net/~eeejay/+junk/checkbox-mago
[20:43] <eeejay> cr3, i can't figure out how to fire report-result with the correct TestResult instance
[20:44] <eeejay> cr3: interface.show_test() returns a new instance that has little to do with the actual test
[20:44] <eeejay> cr3: lunch!
[22:09] <cr3> eeejay: ok, off the phone finally!
[22:09] <eeejay> cr3. finally!
[22:10] <cr3> eeejay: so, why do you grab the output of stderr in MagoCommand.post_execute?
[22:10] <eeejay> cr3, because that is where the log output is
[22:12] <cr3> eeejay: didn't you say mago created a log file?
[22:12] <cr3> 13:43 < eeejay> cr3, the test results in mago don't go to stdout, they are written to a result file
[22:12] <eeejay> cr3, there is the regular debug log, which goes to stderr, but the actual results are written to file
[22:13] <cr3> eeejay: ah, so you grab the debug log in order to find the results file, right?
[22:13] <eeejay> cr3, xactly!
[22:14] <cr3> eeejay: does mago support a -o or --output command line parameter to specify the path to the result file?
[22:14] <eeejay> cr3, now i got it doing "report-test" with the right results, but i don't know what happens now...
[22:14] <cr3> ... which could potentially take a dash (-) as argument to specify stdout? :)
[22:14] <eeejay> cr3, probably
[22:14] <eeejay> cr3, i doubt it supports dash
[22:15] <eeejay> cr3, but that is minutiae, i figured out how to populate result.data properly.
[22:16] <eeejay> cr3, it could be pretty, i'll work on that
[22:16] <eeejay> cr3, but now after report-test, what comes next?
[22:17] <eeejay> cr3, pushing more changes
[22:18] <cr3> eeejay: at that point, you probably want to look at shell_prompt.py for the MagoPrompt implementation
[22:18] <cr3> ie, you want to show a progress bar and run mago in a child thread
[22:19] <cr3> by the way: directory = Path(default="%(dt_path)s")
[22:19] <cr3> and you don't want to self._manager.reactor.fire("report-result", result) in MagoCommand
[22:20] <eeejay> cr3, i only et the right report if i fire it from MagoCommand
[22:21] <eeejay> cr3, show_test() returns the wrong result
[22:21] <eeejay> cr3, i already got the progress bar
[22:21] <cr3> eeejay: mago should be automated, so you shouldn't need to show anything other than the pulse bar
[22:22] <eeejay> cr3, oh.. so no wizardy pages?
[22:22] <cr3> eeejay: I suspect MagoPrompt might not even be needed. try changing the plugin from "mago" to "shell" when creating new test instances
[22:23] <eeejay> cr3, ok
[22:23] <cr3> eeejay: well, from my understanding of mago, those wizardy pages shouldn't really be necessary
[22:23] <eeejay> cr3, i wanted it to be an option, to run each individual mago suite interactively
[22:23] <cr3> eeejay: in that case, s/shell/manual/ :)
[22:24]  * eeejay first tries shell
[22:24] <cr3> in other words, since you deriving MagoCommand, you can probably reuse the manual_prompt or shell_prompt plugins
[22:26] <cr3> base on your sample xml, I'm assuming each mago test has a single result. if this is not necessarily the case, that can be handled too
[22:27] <cr3> by the way, if you reuse the shell or manual prompt plugins, you shouldn't need to fire the report-result event in MagoCommand.post_execute anymore
[22:27] <cr3> and, therefore, you shouldn't need to pass the manager instance as an additional argument to the constructor... you might not even need to override the constructor at all
[22:36] <cr3> eeejay: I hope things are looking good...
[22:45] <eeejay> cr3, sorry, wifi issues here at the shelter
[22:45] <eeejay> cr3, everyone is back from lunch at the mission and trying to check e-mail
[22:49] <cr3> eeejay: I feel we're pretty close to having something working nicely so I might be getting overly excited
[22:49]  * cr3 gets more coffee.. not bouncing off the walls enough
[23:05] <eeejay> cr3, if i don't explicitly fire report-result in post_execute(), i don't get the result in the final report
[23:05] <eeejay> cr3, i just get an empty "skip" result
[23:05] <eeejay> but if i fire the event, i get both
[23:15] <cr3> eeejay: can you try: 1. push the current state of your branch; 2. comment out the firing of report-result from post_execute; 3. run checkbox with the argument --log-level=debug; 4. pastebin the output
[23:15] <eeejay> um
[23:15] <eeejay> yeah?
[23:15] <cr3> that reminds me, I need to start using pastebinit
[23:25] <eeejay> cr3, http://dl.getdropbox.com/u/280491/submission.xml
[23:26] <eeejay> cr3, http://dl.getdropbox.com/u/280491/checkbox-mago.log
[23:30] <cr3> eeejay: aha! so, if you're running tests manually: 1. the result status will be taken from the radio buttons which is set to skip by default; 2. the result data will be taken from the comment box.
[23:30] <cr3> eeejay: try with plugin = "shell" just for kicks
[23:31] <cr3> perhaps an improvement could be that running the test should reset the radio buttons based on the status of the command
[23:31] <eeejay> cr3, yes!
[23:31] <eeejay> cr3,  please
[23:31] <eeejay> cr3, before i run them as shell, i need to put whitelist blacklists in place
[23:32] <cr3> eeejay: I'll see if I can kick that change in the trunk quickly, one moment
[23:33] <eeejay> cr3, it is bizarre how in the gtk user interface in makes a new testresult instead of using the one from the test.
[23:34] <cr3> the preconception was that the manual feedback was the result
[23:35] <cr3> if the test outputs data and the user provides a comment, what to do?
[23:36] <eeejay> the test's result should populate the UI
[23:36] <eeejay> at least in half-manual tests
[23:37] <cr3> eeejay: so the comment box should be filled with the output of running the test?
[23:37] <cr3> I have considered that before but it felt weird to me. if it feels alright to other people, I'm easy
[23:37] <eeejay> cr3, more importantly the "yes"/"no" should be changed
[23:39] <cr3> eeejay: I'm done with the gtk interface, now doing the cli interface
[23:47] <cr3> eeejay: fix pushed
[23:54] <eeejay> i am off for a bit
[23:56] <cr3> eeejay: pip pip, cheerio