=== pace_t_zulu_ is now known as pace_t_zulu
=== mdz_ is now known as mdz
[11:22] <davmor2_> davmor2: hello
[11:23] <davmor2> hello back davmor2_
[11:31] <davmor2_> adium themes :)
=== torkiano is now known as jjardon
[12:03] <davmor2> guys acn someone else test if salut in empathy karmic can talk to bonjour in pidgin jaunty please?
=== fader|away is now known as fader_
[14:53] <davmor2_> meh works after a reboot so don't worry :)
[17:27] <ara> hey eeejay_ :)
[17:28] <eeejay_> Hey ara! Is the meeting in 30 minutes?
[17:28] <ara> eeejay_, QA meeting is in 30 minutes, but auto testing meeting is in 2 minutes
[17:28]  * ara wonders who is going to show up...
[17:29] <eeejay_> Good question
[17:29] <eeejay_> I think I will
[17:30] <ara> eeejay_, hehe
[17:31] <eeejay_> ara: started working on ubiquity testing. Very exciting
[17:32] <ara> eeejay_, cool :)
[17:33] <ara> eeejay_, do you have any news about daily testing? cr3 is not online, apparently
[17:34] <eeejay_> ara: Nope!
[17:35] <eeejay_> ara: Maybe everyone went to a conference on some island.
[17:35] <ara> eeejay_, have you seen the merge request I sent today? suite args were not working in mago...
[17:36] <eeejay_> ara: No, didn't see that. Will look now
[17:38] <eeejay_> Lp is slow..
[17:40] <ara> eeejay_, classic
[18:02] <ara> cr3, hey! I wanted to ask you how is the mago daily testing going?
[18:03] <cr3> ara: it won't be going for a week or two still, I need to work on other priorities which I've confirmed with heno
[18:04] <ara> cr3, and results? will there be going to the certification site?
[18:05] <cr3> ara: yep, and we'll be opening up the certification site gradually to show the community the latest results every day
[18:05] <cr3> ara: if we define the output of mago as an attachment to the test results, you'll be able to download a bunch of test results at once within a single zip file
[20:44] <sbeattie> fader_: FYI, I never was able to get your checkbox bzr branch to run the glibc test... but checkbox generally seems to hate me.
[20:46] <fader_> sbeattie: Heh, cr3 put some hidden code in there... if ($USERNAME == 'sbeattie') be_evil();
[20:47] <fader_> sbeattie: To be more serious, I haven't looked at it in a bit but I will put it back on my list.  I believe schwuk is going to be working on checkbox tests as of next week as well, so maybe we can get some help from him if I can't get it working for you.
[20:48] <cr3> sbeattie: what seems to be the problem?
[20:49] <fader_> cr3: Almost certainly stuff I did :/
[20:52] <cr3> sbeattie: seriously, if I could be of assistance, let me know
[21:06] <sbeattie> cr3: mostly my issue is with figuring out how to get it to run correctly in place out of bzr branchs without installing into the system locations.
[21:37] <cr3> sbeattie: "in place out of bzr branchs"? and, without installing what into the system locations?
[21:38] <cr3> (sorry for the lag, been hopping in and out of the lab)
[21:39] <sbeattie> checkbox; e.g. I want to bzr co testbranches to hack on, without having to install things into /usr and /etc
[21:40] <sbeattie> which I'm sure is possible, I just haven't figured out the right magic to do it.
[21:40] <cr3> sbeattie: just to be clear, do you want to: 1. checkout testbranches of checkbox itself and run it from the source tree? or, 2. write a plugin in checkbox which checkouts testbranches of some test suite?
[21:41] <sbeattie> 1.
[21:41] <cr3> sbeattie: bzr branch lp:checkbox; cd checkbox; sudo ./bin/checkbox-gtk
[21:41] <cr3> sbeattie: let me know if that doesn't work
[21:42] <sbeattie> when I've done that in the past, it never seems to honor suites I've added.
[21:42] <sbeattie> (to the local bzr tree)
[21:42] <cr3> sbeattie: ok, so I misunderstood the problem then, I thought you couldn't run checkbox from the source directory
[21:43] <cr3> sbeattie: if the problem is that checkbox doesn't recognize new suites, might you happen to have a sample suite which didn't work?
[21:44] <cr3> there should be no magic, you should just be able to drop your suite into the suites directory and be done
[21:44] <cr3> if there is magic necessary, then that's a bug
[21:44] <sbeattie> in the suites directory in the bzr tree, or the one in /usr/share/checkbox/suites
[21:44] <sbeattie> ?
[21:45] <sbeattie> I never got the former to work, even with simple /bin/true testcases.
[21:45] <cr3> sbeattie: if you're running checkbox from the bzr tree, in the bzr tree. if you're running checkbox from the system, in the system /usr/share/... directory. it should be logical
[21:46] <sbeattie> right, running from the bzr tree + adding suites to the bzr tree never worked for me.
[21:46] <cr3> sbeattie: your expectations were correct then, if you were working from the bzr tree, you should indeed expect that dropping new suites in that directory should work
[21:46] <cr3> sbeattie: "might you happen to have a sample suite which didn't work?"
[21:47] <cr3> sbeattie: I've made plenty of demonstrations to people from the source tree and dropping new suites, so perhaps there was a problem in the formatting of the suites file
[21:55] <sbeattie> lemme dig one up, it's been a while. But I'm also unclear as to how to use the additional checkbox bzr trees (checkbox-certification, etc.) in conjunction with either the system checkbox or a bzr checkout.
[21:57] <cr3> sbeattie: using checkbox-* in conjunction with checkbox becomes a bit complicated because, if you also want to use the bzr tree of checkbox and you're working on checkbox-compatibility for example, then you have to set environment variables such as CHECKBOX_DATA and CHECKBOX_SHARE
[22:01] <sbeattie> cr3: okay, yay, must have been operator error, the dropin thing is working.
[22:02] <sbeattie> cr3: but documenting which env variables to set in the checkbox-* case would be helpful.
=== fader_ is now known as fader|away