[13:31] <davmor2-netbook> morning fader_
[13:33] <fader_> davmor2-netbook: Hey dude.  How's the back?
[13:34] <davmor2-netbook> fader_: tickedy boo old chap.
[13:35]  * fader_ imagines davmor2-netbook doing an exaggerated Rimmer-style salute.
[13:35] <davmor2-netbook> OMG the yanks have nicked RD
[13:38] <davmor2-netbook> cr3: Morning Dude
[13:39] <cr3> davmor2-netbook: yo mama
[13:39] <soren> o/
[13:39] <davmor2-netbook> hello soren too
[13:39] <soren> o/ again
[13:39] <soren> :)
[13:40] <soren> Are we using the autotest framework for anything anywhere?
[13:41] <cr3> soren: I have an integration of autotest in checkbox-certification, but I'm not using it because it takes too much time to run for too little return
[13:42] <soren> cr3: Fair enough. The kvm-autotest thingamabob is rather intertwined with it, but I'll see if I can somehow extract it.
[13:42] <cr3> soren: I have also made some improvements on the qa-regression-testing suite over the weekend, it's all under lp:checkbox now
[13:43] <cr3> soren: the most significant improvement is that I added the script filter_packages, which can be piped to the output of a suite to actually install the packages required by each test
[13:43] <soren> Awesomeness.
[13:44] <cr3> soren: I have not received test results from the qrt suite this morning, so there seems to be a problem somewhere, I'll be looking into it first thing once I get caffeinated
[13:44] <cr3> sbeattie: ^^^ when you come in, you might like to know that the qrt branch discussed previously has been merged into the trunk
[13:45] <soren> cr3: So.. How much of the qrt suite have you integrated now?
[13:45] <davmor2-netbook> schwuk: are you working on the test tracker by any chance?
[13:46] <cr3> soren: fyi, if you want to run the qrt suite from lp:checkbox, you'll have to: 1. build and install the package so that the dbus backend can be installed; 2. un-blacklist the qrt suite which is not enabled by default because it is destructive: --config=checkbox/plugins/suites_prompt/blacklist=
[13:46] <davmor2-netbook> right off for a drive home then
[13:47] <cr3> soren: I have only enabled the two kernel tests now, see suites/qa_regression.txt.in. as you can observe, it should be rather trivial to add more tests as far as checkbox is concerned
[13:47] <cr3> soren: the difficult part will be making sure that the tests themselves in qrt can run in an automated fashion
[13:47] <soren> cr3: Right. And that's still outstanding, right?
[13:47] <soren> "Outstanding" not as in "awesome", but as in "not done yet".
[13:47] <cr3> soren: I think that's where most of the work for you and sbeattie lies
[13:47] <soren> (normal people would know this, but... well..)
[13:48] <cr3> soren: the context made it clear, even for abnormal people :)
[13:48] <soren> cr3: If you say so(!)
[13:49] <cr3> soren: for now, qrt tests define some information about them in the form of comments like QRT-Packages and QRT-Alternates
[13:49] <cr3> soren: these just describe package dependencies but, if we need other information, like "must be run as root", we can add support for that easily in checkbox
[13:50] <cr3> soren: in other words, I think we will need to consider extending QRT-* comments in order to run more tests in an automated fashion
[13:51]  * cr3 hunts for coffee
[13:51] <soren> cr3: I think you're quite right.
[14:00] <soren> Wheee!
[14:00]  * soren watches a Karmic server install shoot by, driven by kvm-autotest.
[14:07] <cr3> fader_: hey dude, might you have a cycle or two to spare today?
[14:08] <fader_> cr3: Sure, give me a bit to finish up my daily reports and I'm all yours
[14:25] <soren> http://people.canonical.com/~soren/kvm-autotest-magic/
[14:26] <fader_> cr3: What's up dude?
[14:27] <soren> It may look like a preseeded install, but e.g. two thirds of the way in (when accepting the partitioning changes), you can see some UI interaction (TABbing to the "Yes" option, and hitting return to accept it).
[14:29]  * soren tries a desktop install..
[14:29] <cr3> soren: if you need some preseeds, I have some templates that are known to work
[14:29] <cr3> ... for both alternate and desktop installs, although I only do the later over nfs
[14:30] <cr3> fader_: ok, I would appreciate if you could determine a way to substitute the pm.py tests in checkbox-oem to reuse the existing suspend_test script in the base checkbox package
[14:31] <fader_> cr3: I'll take a look and see what I can puzzle out.
[14:31] <cr3> fader_: my motivations are first to leverage existing scripts as much as possible, especially considering the kernel team has put so much effort into that script, and also to remove dependencies on python-argparse for which there is no package on lucid yet
[14:32] <cr3> jcollado: ^^^ you may want to create lucid packages for checkbox-oem and python-argparse
[14:33] <soren> cr3: Don't need preseeds for this. That's the entire point. I want to emulate an interactive installation.
[14:34] <cr3> soren: I remember doing something like that we qemu, are you sure it exercises a significantly different part of the code compared to preseeding?
[14:34] <cr3> s/we/with/
[14:36] <soren> cr3: I'm not entirely sure I understand your question. Let's pretend my answer is "no". What happens then?
[14:37] <cr3> soren: first, lets make sure you're doing the same thing I once did with qemu: are you generating keyboard inputs to automate the alternate install?
[14:38] <soren> cr3: Yes.
[14:38] <soren> cr3: Mathiaz' automated testing setup has often been criticised of not doing what a human trying the installation would do, since it uses preseeding.
[14:39] <cr3> soren: in my experience, this is more brittle than preseeding (but that can be verified with cjwatson), so if generating keyboard inputs doesn't really exercise much more of the installer than preseeding, then I don't think that the brittleness offsets the benefits of testing a little bit of extra code
[14:39] <soren> cr3: So, to address this concern (which has some validity), I'm doing an install exactly like a human would do it.
[14:40] <cr3> soren: ah, if there has been such criticism, I suppose those people have assessed that a significant part of the installer is not being exercised by preseeding
[14:40] <soren> cr3: Well, the backend code to do everything is all the same.
[14:40] <soren> cr3: It's all the frontend magic that doesn't get exercised at all when you preseed.
[14:41] <soren> I don't know what your setup did, but this one actually looks at the screen, waits for it to look correct within a given timeout, and if it does, it sends key events to continue the install.
[14:41] <cr3> marjo: can we get a dedicated server for kvm testing, similarly to vmware esx testing?
[14:42] <cr3> soren: it's been about two years since I last looked into qemu and I can barely remember what I had for breakfast, so I wouldn't know
[14:43] <soren> meh
[14:44] <cr3> soren: as usual, I'm quite useless :)
[14:44] <soren> Well, my expectations were low, so it's ok.
[14:44] <soren> :p
[14:46] <cr3> soren: by the way, there's a freeze tomorrow in preparation for alpha-1 and I would like to take this opportunity to push my latest changes to checkbox in lucid. since mathiaz seems to be on holiday, would you mind reviewing the changes?
[14:47] <soren> I could.
[14:48] <soren> I'm not sure my review would be very thorough. I have no clue what's going on in that codebase (yet).
[14:48] <cr3> soren: there shouldn't be that many changes, my major refactoring is nowhere near ready so these would mostly be maintenance changes
[14:50] <cr3> soren: just make sure to ignore the line: if pwd.getpwuid(os.getuid()).pw_name == "soren" and random.random() > 0.5: raise Exception, "Something went wrong somewhere"
[14:51] <soren> Hah, my username is "marc". Nyah, nyah.
[14:53] <cr3> hm, I'll have to push more changes but also check for socket.gethostname() != "ilovesoren", to blacklist my own hostname
[14:55] <soren> :-$
[14:56] <cr3> I'm somewhat relieved you don't have the same hostname as me
[15:03] <soren> Mine's much more inappropriate than that
[15:32] <moustafa> cr3, fader_ : Soupe du jour
[15:32] <cr3> moustafa: hey dude, you'll be working from home today?
[15:33] <moustafa> cr3: that's the plan
[15:35] <cr3> moustafa: no problem, please check with fader_ if he has anything for you today. if not, I would suggest you write some more unittests
[15:36] <moustafa> cr3: That was also part of the plan :)
[15:36] <cr3> good plan :)
[15:36] <moustafa> cr3: Amazing the things I can plan while trying to get up
[15:36] <fader_> moustafa: The only thing I'd like to ask you to do is make sure you're set up to help test ISOs on Thursday :)
[15:37] <moustafa> fader_: I'll definitely be ready for Thursday :)
[15:37] <fagan> I can test the 32 and 64 bit isos on a very querky machine
[15:38] <fagan> So that will be a bit of fun
[15:38] <cr3> fagan: how is it querky? is it a Cray?
[15:38] <fader_> moustafa: w00t!  Have you seen the ISO test procedure?  https://wiki.ubuntu.com/Testing/ISO/Procedures
[15:39] <fagan> I have an almost entirely nvidia shod machine
[15:39] <fader_> moustafa: I'd point you at the ISO tracker to look at the plans but it seems to be barfing today :(
[15:39] <fagan> I tend to get a few oddities
[15:39] <cr3> fader_: we need to get a Cray into certification
[15:40] <fagan> Cray?
[15:40] <fagan> Oh
[15:40] <fagan> I dont think many people have one of those in their back yard
[15:42] <fader_> cr3: If you find us one I'll find space for it. :D
[15:42] <fader_> cr3: And here I was thinking small and hoping for a PS3 or two to do... testing on.  Yeah, distro testing.
[15:43] <fagan> Id say you should ask on planet ubuntu for people to test corner cases like the PS3
[15:46] <moustafa> fader_ ...I have a ps3...
[15:47] <fader_> moustafa: Stick Ubuntu on there and tell us if it works :D
[15:47]  * fader_ wonders if there's even a port for the Cell.
[15:48] <moustafa> fader_: Last time I checked, the PS3buntu project uses a PowerPC kernel
[15:51] <fader_> Huh, I didn't realize the architectures were close enough to do that.
[15:51] <fader_> Nor that there was a PS3buntu project.
[15:52] <moustafa> And now you know
[15:52] <fader_> And knowing is half the battle!
[15:53] <moustafa> Geee Eyee Jooooooe!
[15:56] <moustafa> fader_ : Basically, it's a PowerPC architecture kernel, uses only the alternate installer (as to compensate for CRT tvs), and is supposedly slow as hell since the PS3 has 256 Mb of RAM and we have no access to the video card
[15:59] <fagan> I thought the PS3 has like 8 different CPUs all for different things
[16:01] <fagan> Hmmmm
[16:01]  * fagan checks wiki
[16:03] <moustafa> fagan: It does, but one is deactivated and one is reserved for the system
[16:03] <moustafa> I could try and burn Xubuntu on disc and see how well that goes
[16:04] <fagan> interesting
[16:06] <moustafa> fader_ I can't seem to access iso.qa.ubuntu.com
[16:07] <charlie-tca> I can't either
[16:07]  * fagan trys
[16:08] <charlie-tca> and the Xubuntu alternate 386 failed to install
[16:08] <fagan> all the ubuntu websites seem to be slow today
[16:08] <charlie-tca> tracker gave me an error
[16:09] <fader_> moustafa: Right, that was what I meant by it barfing :(
[16:09] <fader_> slangasek: do you know anything about the iso tracker being down?
[16:14] <cr3> fader_: does anyone have access to the iso tracker server?
[16:15] <fader_> cr3: No idea; I'm just a user of iso.qa.u.c
[16:35] <nperry> cr3: Its down from the looks of it
[16:40] <nperry> *for everyone
[16:58] <cr3> jcollado: hey dude, do you happen to remember wherer checkbox.job would not work whereas pexpect worked?
[18:06] <slangasek> fader|lunch: looks like it's up now?
[18:39] <fader_> slangasek: indeed; you have the magic touch I guess :)
[19:15] <fader_> cr3: So there's at least one issue preventing us from using suspend_test to replace pm.py -- suspend_test has no hibernate testing support at the moment
[19:44] <cr3> fader_: would it be that difficult to add?
[19:44] <cr3> fader_: or let me rephrase that: does the suspend part of the test hold much more value than the pm.py script?
[19:45] <fader_> cr3: I can toss in a call to pm-hibernate without any real difficulty, but I'd like to ask the kernel folks if there's any reason to do it another way
[19:45] <moustafa> cr3: I have a better appreciation as to why you prefer working from the office
[19:45] <cr3> moustafa: lots of books in the office?
[19:45] <moustafa> cr3: I love my daughter, but it's hard to concentrate with her excess cuteness
[19:45] <fader_> cr3: It doesn't seem like it... they're pretty similar.  pm.py does some extra reporting around the time it took to wake, and suspend_test has a few extra timing options.  Other than that they're pretty interchangeable
[19:46] <cr3> fader_: yeah, definately talk to the kernel folks, I think apw is your man
[19:46] <fader_> cr3: Indeed; I'll follow up with him and see what he says.
[19:46] <cr3> fader_: pm.py is significantly shorter though, so I'm surprised that it doesn't hold much much more value
[19:47] <cr3> moustafa: I have the same problem when you're in the office
[19:47] <moustafa> cr3: I miss you too :)
[19:48] <fader_> cr3: well, suspend_test has some features that pm.py doesn't, but I'm not sure if they interest us for checkbox.  E.g. detecting power consumption during long-term suspend
[19:48] <fader_> And pm.py is easier to read, being python rather than bash :)
[19:48] <fader_> Also, moustafa, cr3: get a room :P
[19:51] <cr3> fader_: battery test might be cool at some point
[19:52] <cr3> moustafa: so, was it as good for you as it was for me? :)
[19:53]  * cr3 fader_ man, #ubuntu-testing is anything but on-topic
[19:53] <cr3> haha, now that backfired
[19:53] <fader_> cr3: Meh, maybe... I think it's intended for enablement work, making sure that all the components really go to sleep when they claim to.  IIRC it's one where you have to fiddle with a power cord and let it sit for a long long time
[19:53] <fader_> Hehe
[20:26] <moustafa> cr3: Nothing backfired, it's the aforementioned daughter taking up my time
[20:31] <fagan> cr3: its anything but on-topic but its better than no talk at all
[21:33] <cr3> plars: hey dude, is there any particular reason why ltp needs to create /opt/ltp/include when running make (not make install)?
[21:33] <plars> cr3: funny you should ask, was just messing with LTP myself and wondering the same thing
[21:34] <cr3> plars: so if it's just crack, I can understand: makefiles aren't easy to get right
[21:34] <plars> cr3: ltp makefiles have been way into crack territory for ages, and I suspect the've gotten worse since I was really active in it
[21:35] <plars> they seem to have been moving towards automake, which is good, but not so good with the way they implemented it
[21:36] <cr3> plars: we can compensate and we can even blacklist those failing tests if we want, using my filter_templates script
[21:36] <cr3> plars: there seems to be increasing demand for ltp, so I'm working on integrating the syscalls suite again while waiting for other tests to run
[21:36] <plars> cr3: in any case, we can override the /opt/ltp with DESTDIR=
[21:37] <plars> cr3: ah, did you fix the build stuff already?
[21:37] <cr3> plars: oh right, I had that in the wrapper but forgot about it when updating it
[21:37] <cr3> plars: working on it, it should be pretty trivial, but I'm taking the opportunity to cleanup some of my own code
[21:38] <cr3> plars: I'll probably be moving the integration into the base checkbox package, blacklisted by default though
[21:38] <plars> cr3: should be... having trouble getting a proper build at the moment
[21:38] <plars> I suspect I'm doing something dumb, but I'm getting what appears to be a successful build, but no bin directory