[07:04] <ara> morning all!
[08:37] <davmor2> Morning all
[11:01] <davmor2> welcome back world
[11:13] <davmor2> welcome back ara
[11:13] <czajkowski> davmor2: aloha
[11:14] <persia> So, recently I offered to talk to folk about using schroot to test individual applications.  Are any of those folk around at this hour?
[11:14] <davmor2> czajkowski: morning are you snowed in?
[11:14] <davmor2> persia: pass
[11:15] <davmor2> I think it was fagan wasn't it
[11:15] <czajkowski> davmor2: nope no snow here, rain yes
[11:15] <persia> I forget.  I was half-asleep :)
[11:23] <davmor2> czajkowski: No none here either
[12:41]  * ara -> lunch
[13:56] <fader_> Bonan matenon, ĉian personojn!
[14:01] <davmor2> fader_: This is an English speaking channel I think you want #ubuntu-fr ;)
[14:02] <fader_> Bah... not French.  :P  And sadly there's no #ubuntu-eo.
[14:05] <davmor2> morning dude
[14:05] <davmor2> morning cr3
[14:05] <cr3> davmor2: hey dude
[14:13] <fader_> cr3: Bonjour!
[14:15] <cr3> fader_: gerard depardieu vit sur l'ile de man
[14:16] <fader_> Heh... I'm not sure if that pun works en français.
[14:16] <cr3> fader_: nope, but that makes it funnier for me and my twisted sense of humor
[14:16] <fader_> :)
[14:23]  * davmor2 is liking python idle :D
[14:25] <moustafa> cr3, fader_, davmor2: Baguette
[14:26] <fader_> moustafa: Merhaba!
[14:26] <moustafa> fader_ :)  Actually, it's "marhaba"  :)
[14:27] <moustafa> Then again, I might've been influenced by the Lebanese dialect
[14:27] <fader_> moustafa: Blame the Interwebs.  $turkish_fader_knows = 0
[14:27] <fader_> :)
[14:28] <moustafa> fader_ That would explain it.  Turkish and arabic aren't the same, but they are very much alike
[14:28] <moustafa> Same mistake as going to Portugal and claiming to not understand spanish
[14:28] <fader_> moustafa: Ah, darn.  I must have misremembered; I thought you were from Turkey.
[14:29] <fader_> Yeah, well, my Spanish is bad enough that it might pass for Portugese :)
[14:29] <moustafa> fader_: It's not a big deal.  Lebanon's not very far from Turkey.  Besides, we took some of their foods and made them better.
[14:31] <fader_> Hehe
[14:45] <davmor2> moustafa: cheese
[14:46] <moustafa> davmor2: John Cleese has nothing to do with this
[14:47] <davmor2> moustafa: no that would be butter scones
[15:29] <sbeattie> cr3: what are valid settings for the user: attribute?
[15:35] <cr3> sbeattie: for now, just root is supported
[15:36] <sbeattie> so, uh, how is non-root to be supported?
[15:36] <sbeattie> the kernel tests from qa-r-t don't run here because they want to be run as a normal user with sudo privs.
[15:37] <sbeattie> ... and it appears the infrastructure is in place via the sudoers editing to allow that; it just doesn't happen.
[15:38] <sbeattie> cr3: do the kernel tests actually run in the certification setup?
[15:40] <cr3> sbeattie: in scripts/qa_regression_suite, see the function set_sudoers_nopasswd
[15:42] <sbeattie> right, which implies that scripts/qa_regression_suite (and checkbox at large) has to be run as root to set it; and needs to drop priv to run the test-kernel scripts, which it doesn't do.
[15:42] <sbeattie> cr3: ^^
[15:43] <cr3> sbeattie: the suite script is run as root, as defined in suites/qa_regression.txt.in. what makes you say that the individual scripts generated by that script are also being run as root?
[15:43] <sbeattie> cr3: have you looked at the output of the tests?
[15:44] <cr3> sbeattie: the output of the tests or the output of the suite script?
[15:44] <sbeattie> cr3: when run through checkbox, have you looked at the output in submission.xml.
[15:44]  * ara wonders about the differences between cr3 and cr3_holidays
[15:45] <sbeattie> cr3: when I run checkbox here with the kernel tests enabled, they say they failed to run because they need to run as a normal user with sudo access.
[15:46] <sbeattie> cr3: http://paste.ubuntu.com/343615/
[15:47] <cr3> sbeattie: I'll try it out, one moment
[15:48] <cr3> ara: the difference is that I mostly wear my community hat and I choose to wear my canonical hat when it could help other people :)
[15:48] <ara> :)
[16:04] <cr3> sbeattie: the only problem I'm observing is that the tests aren't run on the first pass but run fine on the second pass: http://paste.ubuntu.com/343620/
[16:04] <cr3> sbeattie: are you running checkbox itself as root?
[16:08] <sbeattie> cr3: yes. I thought when I tried to run as non-root, I had a different failure. Trying again.
[16:09] <cr3> sbeattie: there's a little catch 22 here, unfortunately because of the dbus backend manager
[16:09] <cr3> sbeattie: in order to run some tests as the user and some tests as root, the former must run in the checkbox client and the latter must run in the checkbox backend through dbus
[16:10] <cr3> sbeattie: this could potentially be worked around by playing with the real and effective user id somehow, along with the SUDO_USER environment variable
[16:10] <cr3> sbeattie: however, for now, the preferred work around is to simply make sure to install checkbox: debuild; sudo dpkg -i ../checkbox_0.9_all.deb ../checkbox-gtk_0.9_all.deb
[16:11] <cr3> sbeattie: you can then still run checkbox from the source directory but at least you'll now have the dbus backend available for running stuff as root
[16:11] <cr3> sbeattie: note that for security purposes, the backend manager will only agree to run commands found under /usr/share/checkbox
[16:12] <cr3> sbeattie: otherwise, if the backend manager could run arbitrary commands, then kees would slap me around with a wet trout... and rightly so
[16:12] <sbeattie> cr3: okay.
[16:12]  * cr3 goes on to chop the mightiest tree in the forest with a hering
[16:13] <fader_> *musical sting, dramatic zoom*
[16:13] <sbeattie> cr3: I've been thinking about how to cope with qa-r-t's differing privilege requirements for the various scripts.
[16:14] <sbeattie> cr3: from what I've seen, they fall into three classes (1) don't care, probably prefer non-root, (2) non-root with sudo access and (3) full blown root
[16:15] <cr3> sbeattie: all three cases should now be supported, with the only caveat that the comments in the test would need to convey its preferences so that the checkbox test definition could behave accordingly
[16:15] <sbeattie> cr3: was thinking of adding a QRT-privilege meta field to the scripts to capture that, that scripts/qa_regression could emit the correct user: field for.
[16:16] <cr3> sbeattie: excellent, that'd be perfect
[16:16] <cr3> sbeattie: I think you'll only need QRT-privilege: root, you won't need to cover the sudo use-case since it's already covered implicitly
[16:17] <sbeattie> cr3: I *think* that I'd prefer the sudo editing to only occur for test cases that need it; if you manage to select a set of testcases that don't then I don't think the edit should happen.
[16:18] <cr3> sbeattie: I wouldn't worry about it, qrt is for a very specific target audience, it won't be enabled by default
[16:18] <sbeattie> (it's just the security nerd in me coming out, not wanting to grant privileges where it isn't needed)
[16:19] <cr3> sbeattie: if you're concerned, I would be inclined to either remove the test or rewrite it to not be interactive (ie, not call sudo)
[16:20] <cr3> sbeattie: if you consider rewriting, you might like to know that checkbox happens to set the SUDO_USER environment variable when running tests as root, so if you need to flip flop between the user and root, at least you know the username in question
[16:21] <sbeattie> okay, cool, good to know.
[16:22] <cr3> sbeattie: if you need little bits of information like that to make refactoring easier, don't hesitate to let me know
[19:23] <GrueMaster> Who do I talk to about setting up a series of wiki pages on http://testcases.qa.ubuntu.com for suspend/resume?
[19:25] <GrueMaster> Nevermind.  Found http://testcases.qa.ubuntu.com/System/SuspendResume.
[19:55] <sbeattie> GrueMaster: also, it's a wiki.
[19:56] <GrueMaster> Yea, I know.  Just no home page.
[19:56] <GrueMaster> Threw me off for a bit.
[20:13] <lexsoOr> hi guys
[20:15] <moustafa> Hello lexsoOr
[20:16] <lexsoOr> downloading lucid right now :P
[20:17] <moustafa> I have about a dozen lucid-based isos here :D
[20:17] <lexsoOr> nice
[20:17] <moustafa> It's not yet strikingly different from Karmic, but the changes are there
[20:18] <lexsoOr> well I am about to find out
[20:18] <lexsoOr> ...in 1h 20min -.-
[20:18] <plars> anyone ever done a script to test the startup time of various applications?
[20:18] <lexsoOr> nope
[20:18] <plars> for instance, if I wanted to time how long it took a system from the time something like firefox, or Oo.o was launched, to the moment it became available
[20:19] <plars> I was experimenting with using ldtp for it, but it seems to not detect it the moment the window becomes available, there seems to be a lag
[20:20] <moustafa> lexsoOr: You should have used wget, or (if you're using firefox) the downthemall! extension
[20:20] <lexsoOr> how comes
[20:20] <lexsoOr> how comes ?
[20:21] <fader_> lexsoOr: Also, if you're interested in helping us out with testing lucid a bit more formally, please consider joining the QA mailing list at https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa
[20:21] <lexsoOr> fader_: I will :)
[20:21] <fader_> We'll be doing ISO testing of Alpha 2 in a few weeks, and even before then it's a good place to discuss what you're testing and seeing, or any questions you might have around testing
[20:21] <fader_> lexsoOr: Great! :D
[20:22] <lexsoOr> fader_: done :P
[20:23] <fader_> lexsoOr: Fantastic!  Thank you for helping to make Ubuntu better :)
[20:23] <lexsoOr> fader_: and I guess not to many people have my crappy laptop so it's good to know how it behaves there ^^
[20:23] <fader_> lexsoOr: The more testing the better!
[20:25] <sbeattie> plars: watch out for caching issues as well; are you hoping to measure cold-cache or hot-cache times?
[20:25] <moustafa> lexsoOr: wget and downthemall! download faster than the traditional method (graphically, that is).  I can't remember the "why" exactly but they do
[20:25] <moustafa> lexsoOr: To update your images, you can use zsync, which only updates the things that changed, rather than re-downloading the entire image
[20:26] <fader_> lexsoOr: Just to be sure -- if you are testing on your main or only system, be careful and make sure you have backups!  lucid is still an early alpha at this point and there's always the possibility of you finding a major bug :)
[20:26] <moustafa> tip here: http://www.linuxjournal.com/video/updating-isos-zsync
[20:26] <lexsoOr> moustafa: hm well I turned off the uploads so I'll have my hands on it in 45min now
[20:26] <plars> sbeattie: of course, I'm more interested in cold-cache startup time, from a freshly booted system, however I'd like to automate the test so that it can be used as part of some information gathering for bringup testing
[20:27] <lexsoOr> fader_: I have allways a spare partition for testing :P
[20:27] <fader_> lexsoOr: Smart :)
[20:27] <lexsoOr> fader_: :D thanks
[20:28] <sbeattie> plars: right, but if it gets automated for more than one app, and they share common libraries, you'll want to flush the disk buffer cache in between.
[20:28] <lexsoOr> fader_: messed up my system so often ^^ at one point I started to have some more partitions
[20:28] <plars> sbeattie: due to the nature of the systems I'm dealing with, rough estimates are good enough for my purposes. I'm a lot more interested in finding out whether it took 10 seconds, or 5 min, vs. finding a precise average
[20:28] <sbeattie> plars: and alas, no, I have not written such a script.
[20:29] <plars> sbeattie: but the rest of the testing is being done in checkbox, and it's what I'm using to gather up my results, so would be nice if I didn't have to ask the user to drag out a stopwatch, launch the app and time it, then manually insert the results
[20:29] <sbeattie> plars: oh, I agree, completely. Just pointing out sharp edges to watch out for.
[20:30] <plars> sbeattie: sure, I'm aware of those but thanks.  I'm looking at this on arm based systems too, so I'm really looking for things that take dramatically long times
[20:31] <sbeattie> nagappan: have you done anything like what plars is hoping to do with ldtp?
[20:32] <plars> sbeattie: I did do something like this a while back in ldtp, but I wasn't happy with the results.  I could pretty easily prove to myself that the window I was searching for with getwindowlist was available before ldtp actually saw it, sometimes seemed to be off by as much as a few seconds.
[20:33] <plars> anything I launched that took less than 5 seconds, seemed to say it took about 5 seconds to launch for instance
[20:38] <lexsoOr> quick question: how can I see what proces uses how much down and upload ?
[20:39] <sbeattie> cr3: if you've got a chance, can you see if what I'm doing in https://code.launchpad.net/~sbeattie/checkbox/checkbox-qart is sensible?
[22:17] <nagappan> plars, that's just a delay, we have introduced
[22:17] <nagappan> plars, just to be common for all the applications
[22:18] <plars> nagappan: any way to set it not to delay?
[22:20] <nagappan> plars, delay = 5 is the default argument, you can change that to what ever value you want :)
[22:20] <nagappan> plars, this is applicable with both LDTPv1 and v2
[22:20] <nagappan> plars, me heading home, you can email me nagappan @ gmail . com