ara | jcollado: hey! | 12:13 |
---|---|---|
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:14 |
jcollado | ara: What's the difference between mago and libmago? | 12:15 |
ara | hey davmor2 | 12:15 |
ara | jcollado: mago is the whole framework, meaning: the library, the runner and the tests. libmago would be just the library | 12:16 |
jcollado | ara: Then we might use python-mago | 12:17 |
ara | jcollado: yes, that's another possibility | 12:17 |
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:18 |
ara | jcollado: mmm, tricky... | 12:19 |
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:21 |
jcollado | ara: As long as it's possible to run the test cases without the runner, yes. | 12:22 |
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:23 |
jcollado | ara: Then the library should contain only the applications part, but not the runner and the test suite part | 12:24 |
jcollado | ara: Do you agree? | 12:26 |
ara | jcollado: I think that both solutions have pros and cons | 12:30 |
jcollado | jcollado: Maybe we can move this discussion to the maillist so that everybody can think about it | 12:31 |
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:32 |
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:33 |
* ara -> lunch | 12:45 | |
Opr8iVe | Good morning! | 14:42 |
davmor2 | hello | 14:51 |
Opr8iVe | Was wondering if youall wanted install results for 9.04 unr on the brand new Dell Mini10v | 14:56 |
Opr8iVe | if so, where would an apropriate place be to submit that? | 14:57 |
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. | 14:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
Opr8iVe | wife still needs some convertin' :) | 15:05 |
persia | Excellent. The milestone schedule is at https://wiki.ubuntu.com/KarmicReleaseSchedule | 15:05 |
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:06 |
Opr8iVe | Rather relentless schedual yall keep, heh.. | 15:07 |
charlie-tca | My thought, exactly. Supposed to release tomorrow | 15:07 |
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:08 |
charlie-tca | bbl | 15:10 |
Opr8iVe | okay.. Im gonna fire up the ubuntu partition.. Probably be back later. | 15:16 |
=== smb is now known as smb-topper | ||
=== smb-topper is now known as smb | ||
slangasek | alpha2 candidate images posted | 17:27 |
slangasek | and back down again, grub-pc was missing from the disks | 18:15 |
eeejay | hey cr3? | 18:38 |
cr3 | eeejay: yo | 18:40 |
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:41 |
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:43 |
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:44 |
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:45 |
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:46 |
* 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:47 |
cr3 | where "journal" is the name given by the lsb folks for their output file | 18:48 |
=== fader is now known as fader|lunch | ||
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:34 |
eeejay | cr3, ah ok | 19:35 |
eeejay | cr3, thanks for the png | 19:35 |
eeejay | cr3, i hung it over my bed | 19:35 |
cr3 | eeejay: are you now settled in seattle? | 19:36 |
eeejay | cr3, still looking for a house and such | 19:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
eeejay | cr3: http://paste2.org/p/258692 | 19:44 |
cr3 | eeejay: yeah, SystemExit was evil | 19:46 |
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:47 |
cr3 | eeejay: ah, I used to do sys.exit(1) when KeyboardInterrupt was caught. one moment, I'll check why I removed that | 19:50 |
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:55 |
cr3 | eeejay: I'll check if introducing that signal doesn't revert the bug | 19:56 |
eeejay | cr3, Test.command is confusing | 19:57 |
eeejay | cr3, it is a string for a second, and then a TestCommand instance | 19:57 |
cr3 | eeejay: yeah, Test.description too. not one of my proudest moments | 19:58 |
eeejay | cr3, i have had some low moments myself, besides living in a homeless shelter | 19:59 |
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:01 |
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:02 |
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:03 |
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:04 |
=== fader|lunch is now known as fader | ||
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:43 |
eeejay | cr3: interface.show_test() returns a new instance that has little to do with the actual test | 20:44 |
eeejay | cr3: lunch! | 20:44 |
cr3 | eeejay: ok, off the phone finally! | 22:09 |
eeejay | cr3. finally! | 22:09 |
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:10 |
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:12 |
cr3 | eeejay: ah, so you grab the debug log in order to find the results file, right? | 22:13 |
eeejay | cr3, xactly! | 22:13 |
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:14 |
eeejay | cr3, but that is minutiae, i figured out how to populate result.data properly. | 22:15 |
eeejay | cr3, it could be pretty, i'll work on that | 22:16 |
eeejay | cr3, but now after report-test, what comes next? | 22:16 |
eeejay | cr3, pushing more changes | 22:17 |
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:18 |
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:19 |
eeejay | cr3, i only et the right report if i fire it from MagoCommand | 22:20 |
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:21 |
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:22 |
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:23 |
* 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:24 |
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:26 |
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:27 |
cr3 | eeejay: I hope things are looking good... | 22:36 |
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:45 |
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 | 22:49 | |
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:05 |
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:15 |
eeejay | cr3, http://dl.getdropbox.com/u/280491/submission.xml | 23:25 |
eeejay | cr3, http://dl.getdropbox.com/u/280491/checkbox-mago.log | 23:26 |
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:30 |
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:31 |
cr3 | eeejay: I'll see if I can kick that change in the trunk quickly, one moment | 23:32 |
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:33 |
cr3 | the preconception was that the manual feedback was the result | 23:34 |
cr3 | if the test outputs data and the user provides a comment, what to do? | 23:35 |
eeejay | the test's result should populate the UI | 23:36 |
eeejay | at least in half-manual tests | 23:36 |
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:37 |
cr3 | eeejay: I'm done with the gtk interface, now doing the cli interface | 23:39 |
cr3 | eeejay: fix pushed | 23:47 |
eeejay | i am off for a bit | 23:54 |
cr3 | eeejay: pip pip, cheerio | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!