=== asac___ is now known as asac
[02:37] <lajjr> hello cr3
[02:37] <cr3> lajjr: hi there!
[02:38] <lajjr> Marc do you think you will beat the clock??
[02:38] <lajjr> cr3 for check box that is??
[02:39] <cr3> lajjr: sure, I already implemented bug reporting yesterday evening and I have a pretty good idea where I'm going with udev
[02:39] <cr3> I think I'm forgetting something though
[02:39] <lajjr> great..
[02:40] <lajjr> I will help watch for bug and if you have any tasks give a yell?
[02:40] <cr3> lajjr: there was a problem with my changelog, so my latest package has been kinda postponned :(
[02:40] <lajjr> oh..man
[02:41] <cr3> aha, I remember now! there's also a bug with the way I use policykit, but that can wait after feature freeze, so no pressure from the clock
[02:41] <lajjr> nice..
[02:41] <lajjr> what is wrong with the changelog??
[02:42] <cr3> 1. The debian changelog entry is messed up. It should have all the entries from the previous package version plus one new entry describing the new upload.
[02:42] <cr3> 2. Is the removal of upstart checkbox event intentional? If so it hasn't been documented in the changelog entry.
[02:42] <cr3> I thought that I got #1 right, but I guess I was wrong :)
[02:42] <lajjr> oh not to bad..
[02:42] <cr3> yeah, it's not as if I had been completely negligeant :)
[02:43] <lajjr> you still have an old change from a prev package??
[02:44] <cr3> I found some interesting blog today which covered checkbox during uds: http://scubuntu.meraka.org.za/blogs/?tag=uds
[02:45] <cr3> "old change" from "prev package"? my brain is confused with the timeline
[02:45]  * cr3 steps out for a quick smoke
[02:45] <lajjr> nice it had to make you smile.
[02:49] <lajjr> a changelog from a previous package or a completed changelog to get info from??
[02:52] <cr3> lajjr: the previous package is the one currently in karmic, in lp:ubuntu/karmic/checkbox
[02:53] <cr3> I love that packages are now expressed as branches, special thanks to james_w
[02:53] <lajjr> oh.
[02:53] <lajjr> Yes nice branch out..
[02:55] <lajjr> There is enough time to make the correction?
[02:55] <cr3> lajjr: sure, there's plenty of time to make that correction and release another version before feature freeze even
[02:55] <cr3> I expect the next release will be available early next week
[02:56] <lajjr> nice.
[02:56] <cr3> the next release will include my device refactoring
[02:56] <cr3> lajjr: when I have the schema ready to express devices, I'll probably email it to a few folks for feedback including yourself
[02:56] <lajjr> and the suite of test
[02:57] <cr3> the suite of tests for checkbox-qa is not on my plate though, so one less thing to worry about :)
[02:57] <lajjr> heh spread it around.
[02:58] <lajjr> express device very cool. Can't wait.
[02:58] <lajjr> s/express device/express devices.
[03:00] <lajjr> yes happy to assist in the express devices.
[03:00] <cr3> I'll try to keep it as simple as possible, probably: bus, vendor id, product id, subvendor id, subproduct id, class id, subclass id, prog id, description, type and driver
[03:00] <lajjr> is Ronald on?? cr3
[03:01] <cr3> lajjr: he seems to be away, and so should I :)
[03:01] <lajjr> ok
[03:01] <lajjr> nice scheme set.
[03:02] <cr3> ultimately, the challenge is being able to express devices consistently whether using hal or udev information
[03:02] <lajjr> yes I have to go.
[03:02] <cr3> me too, need to prepare dinner
[03:02] <cr3> cheerio, talk to you soon
[03:02] <lajjr> enjoy cr3
[03:03] <lajjr> yes Be Safe.
[13:58] <foormea> hi
[13:58] <foormea> no desktop effects on karmic/kde with kernel 2.6.31, am i alone or other people having the same?
[13:58] <foormea> (nvidia)
[17:33] <davmor2> cr3: what you doing here it's like the wekend :)
[17:33] <davmor2> weekend even
[17:36] <cr3> davmor2: same question to you! :)
[17:36] <cr3> davmor2: actually, I often work on weekends but I mostly do research so I'm not always online
[17:37] <davmor2> playing catch up on my hours :) ill monday and tuesday.  Mostly caught up but I actually wanted to test the latest cds but they didn't arrive till 23:27 which was a bit late to start :)
[17:38] <cr3> cool, I'll see if I got some test results for the new images...
[17:38] <cr3> hm, I seem to have some results for ubuntu i386, but not nearly as much as I would've expected
[17:39] <davmor2> cr3: Plus as I'm off this Monday and tuesday I thought I'd get the extra hours in, mind you I'll make up for any others the following week with alpha 5 :)
[17:39] <davmor2> there all up to date now at least
[17:40] <davmor2> I got ubuntu-alt-64 installing and kub-live-32 just fired up and am burning xub-alt-32 as we speak
[17:42] <cr3> I seem to have a bunch of messages enqueued to run more tests, so maybe I'll see more results trickling in during the day
[17:44] <cr3> davmor2: I got an installation error: installer crashed, pageslen referenced before assignment
[17:44] <cr3> that was for: Kubuntu 9.10 "Karmic Koala" - Alpha amd64 (20090822)
[17:45] <davmor2> cr3: I'll have a look in a second and prize out some logs :)
[17:47] <cr3> davmor2: damnation, this is for the desktop image, I don't seem to be running httpd to get the logs from remote :(
[17:47] <cr3> I love the early_command and httpd netcat script on the alternate image, very useful
[17:48] <davmor2> cr3: do you not have to add those via seed though?
[17:48] <davmor2> preseed even
[17:51] <davmor2> cr3: what hw is it on I'll pick machine that most closely ressembles it :)
[17:54] <davmor2> cr3: kub live 32bit seems to be installing fine for me :(
[17:54] <cr3> reported bug #417417
[17:54] <ubot4> Launchpad bug 417417 in ubiquity "[Karmic] Ubiquity crashes with a UnboundLocalError on 20090822 image" [Undecided,New] https://launchpad.net/bugs/417417
[17:55] <cr3> davmor2: the problem is most likely preseed related
[17:57] <davmor2> my 32 bit install from live session just finished successfully so it could very well be an issue with the pre-seed :(
[17:58]  * davmor2 needs to setup up his forth machine
[17:58] <cr3> davmor2: I'll add a comment to that effect in the bug
[17:58] <cr3> do you mean "forth" or "fourth"? the former would be totally awesome!
[17:58] <davmor2> fourth
[17:59] <davmor2> cr3: I got given an older intel box for testing with so I'll have to drop it into my setup now :)
[18:00]  * davmor2 had to buy a load more dvd+rw's too my others were all burning out on me :(
[18:01] <davmor2> to be fair they had, had a number of installs burnt to them :)
[18:01] <cr3> davmor2: I wonder how much value testing from a physical image compares to installing the image over the network
[18:01] <davmor2> cr3: you lose out on the need for a modified pre seed for one :)
[18:02] <davmor2> but it's the way I prefer to test.  Vm to me is too much like a clean room and has no guarantees that they will work on hw
[18:03] <cr3> davmor2: you wouldn't need a modified preseed if you were still following the steps manually :)
[18:03] <cr3> oh, right, I was just considering tests on physical hardware using images nfs mounted over the network
[18:04] <cr3> however, testing images directly using kvm might be a good addition to my test framework
[18:04] <cr3> and/or I could also leverage vmware (server or esx) to do the same thing
[18:05] <davmor2> cr3: the clean room approach is good for automated if it work on kvm but doesn't on the machines it's most likely an issue with the hw :)
[18:05] <davmor2> well driver for the hw
[18:06] <cr3> davmor2: if we test the the image installs on kvm by directly mounting it and on physical hardware by mounting it over nfs, I wonder if we're missing any potential problems
[18:07] <davmor2> cr3: plus you can use it as a metering rod to gauge meterics by :)  All tests should be faster on hw :)
[18:08] <davmor2> cr3: well you might hit the same issues but it's hard to judge till you try it :)
[18:08] <cr3> davmor2: it's not the size of the rod that counts, it's how you use it :)
[18:09] <davmor2> trust you to bring the level of conversation down to toilet level :P
=== mdz_ is now known as mdz
[18:10] <cr3> seriously though, "faster on hw" really depends on too many factors: kvm can be easily faster on good hardware with virtual extensions than running natively on the hardware
[18:10] <davmor2> cr3: I did say should be :)
[18:11] <cr3> davmor2: the first release of metrics based testing I would like to introduce will only consider individual hardware, be it physical or virtual
[18:11] <cr3> I'm not sure how I'll be able to represent metrics spanning multiple machines to assess that hardware x is quicker/slower than hardware y
[18:12] <davmor2> which I agree would be better to check for overall performance issues/regressions
[18:12] <cr3> davmor2: exactly, the initial motivation will be to use metrics as a form of quantitative test to specifically detect regressions on hardware
[18:13] <cr3> davmor2: however, I know that Keybuk will want an overview across hardware to determine if some graphics controllers, for example, are causing boot speed to diverge significantly
[18:14] <cr3> ie, there was a recent assumption that nvidia was adding 2-3 seconds to the boot time compared to intel for example on the same hardware
[18:16] <cr3> that's weird, there's no lp:ubuntu/karmic/ubiquity... I really can't wait until all the packages have been bzrified
[18:16] <davmor2> yes that would be useful info, but you and I both know that the results will get compared between machines :)
[18:16] <davmor2> cr3: what for?
[18:16] <cr3> davmor2: yeah, so my trick will be to ask those people with most vested interest to help come up with a user interface for the reports :)
[18:17] <cr3> davmor2: I'm just branching ubiquity to see if I can suggest a quick patch
[18:18] <cr3> davmor2: the coolio process would be: bzr branch lp:ubuntu/karmic/ubiquity; fix; bzr push lp:~cr3/ubuntu/karmic/ubiquity/bug-417417; link branch to bug
[18:18] <cr3> that's so much more convenient for the developer than attaching a patch to a bug report
[18:20] <davmor2> yes that would be nice but hey
[18:21] <cr3> that's already how it is for lots of packages, such as checkbox. it's just that it takes a little while to bzrify all the packages
[18:33] <davmor2> it'll get there though :)
[18:40] <cr3> yay, I found the commit that broke automatic installs of ubiquity!
[18:41] <davmor2> cr3: good let them know on #ubuntu-installer :)
[19:07] <cr3> davmor2: do you happen to have access to a system with a floppy and/or a tape drive?
[19:08] <davmor2> floppy yes tape no
[19:09] <davmor2> cr3 why?
[19:09] <cr3> davmor2: hm, I just found a few machines with a floppy, so I'm just missing one with a tape drive then
[19:10] <cr3> refactoring checkbox to use udev instead of hal, so I want to express the type of device
[19:10] <davmor2> Ah :)
[19:13] <cr3> superm1 is everywhere, he's even committing stuff to udev!
[19:16] <davmor2> cr3: That's why he is super Mario :)