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