=== bladernr_afk is now known as bladernr_ [08:23] gema: thanks for the guide fixes, it's much better now === bladernr_ is now known as bladernr_afk === _salem is now known as salem_ [13:13] hey mvo [13:14] hey brendand [13:15] mvo - if i were to propose a branch with the junitxml changes, would you take it? [13:15] mvo - i could potentially make the xml output switchable (-x option for example) [13:41] alourie: no problem! [13:41] alourie: it was good already, quite sharp on what needs doing, so *thank you* === yofel_ is now known as yofel [14:10] mvo - so i wrote a script which junitizes all the tests. [14:15] brendand: right, I wonder if there is a better way, i.e. simply using a tiny wrapper, let me try this out (a tiny wrapper instead of having to modify every file) [14:19] mvo - yeah, i thought about that a little bit, but didn't get anywhere [14:23] Hallo [14:24] I can not run Ubuntu Precise in low-graphic mode to allow nvidia graphic driver. === bladernr_afk is now known as bladernr_ === bladernr_ is now known as bladernr_afk [15:09] brendand: I think I have some ideas around the junitest stuff, I will push a branch later [15:14] brendand: could you please check lp:~mvo/software-center/junitxml ? that contains a small unittest2junitxml helper [15:17] mvo - how to use it? [15:23] mvo - never mind [15:23] mvo, brendand i'm jumping into the conversation, so forgive me if I'm out of context but you can also run python unittest with subunit and pipe the stream to subunit2junitxml [15:23] it works this way: python -m subunit.run test_yourtest | subunit2junitxml [15:23] hurray! [15:23] jibel saves the day [15:24] for example with s-c this works: python -m subunit.run test_netstatus|subunit2junitxml [15:24] jibel - great, thanks! [15:25] yw :) [15:25] mvo - so actually all is really necessary is to modify test-all.sh to allow it to specify xml output [15:28] jibel - oh, but i wonder how to make it work with python-coverage then? [15:38] i can only seem to get the modified unittest cases to work with python-coverage [15:40] brendand: is my small helper not working? [15:41] jibel: oh, interessting, I was not aware of this, that would have saved me a bit of poking around :) [15:43] mvo - it does work, if you run it like 'PYTHONPATH=.:$PYTHONPATH ./unittest2junitxml test_debfileapplication.py' [15:44] and so does jibels tip [15:44] but i can't figure out how to combine them with python-coverage [15:46] brendand: dosn't "make" just work ? I thought it did for me [15:46] * mvo tries that [15:49] mvo - ah, yes i see. it does then [15:52] mvo - there's some little faults in your wrapper. i don't want to pick on it, since i couldn't have written the same, but it seems to depend on unittest.TestCase derived classes being named a particular way [15:52] if name.startswith("Test"): [15:53] brendand, nose is another options in this case [15:53] nosetests --with-coverage --with-xunit --xunit-file=result.xml test_netstatus [15:53] or something like that [15:54] haha, so many options. don't you love the linux world? [15:54] anything but rewriting something that already exists :) [15:55] I have some questions about hardware certification that I hope someone can answer. [15:55] glebaron - ask me [15:55] I am currently looking at a Dell Precision T1600 workstation which has been certified on 11.04 and 10.10 pre-installed. [15:56] glebaron - sure [15:56] They want to run 10.04 64-bit. [15:56] Is this a problem. [15:56] brendand: *cough* you got me ;) its just a quick wrapper and jibel pointed us to better options. so I guess we say goodbye to it and use e.g. nose [15:57] thanks jibel btw [15:57] mvo - sure thing, i'll look into jibel's nose [15:57] (weird sentence) [15:57] enjoy! [15:57] Same question for a Dell Latitude E6420. [15:57] :D [15:58] glebaron - it's our policy to only certify clients (laptops and desktops) with 32-bit. why do they want 64-bit? [15:58] 8gb ram. [15:58] doing analysis on multi-million record datasets. [15:59] glebaron - you mean a server? [15:59] glebaron - is the system already purchased, or being considered? [15:59] brendand, well no, it's laptop and workstation, I know that. [15:59] brendand, it's being considered. [15:59] the E6420 is a laptop, the T1600 a workstation [16:00] brendand, I am leaning toward telling them it's not an issue. [16:00] I run 64-bit on all kinds of stuff with no problems. [16:00] but I just thought I would get your opinions first. [16:00] glebaron - true. but they are *not* certified with 64-bit. [16:01] glebaron: we have seen cases of systems working fine in 32-bit and then failing certification on 64-bit (I think it was a video driver issue) [16:01] so the only way to tell would be to get one and test it. [16:01] glebaron: if possible, my advice would be to get a sample system and test it yourself [16:02] roadmr, I would love to do that. [16:02] glebaron: you could check Dell's return policy, get a system to test, and if it fails (unlikely, but as I said, no promises) you can just return it [16:04] I have an E6400 that I can test on. [16:04] I guess I will try that and then research hardware differences to see what I can find out. [16:05] glebaron: beware, even if the model number is the same, the manufacturer may change components without warning, it's caused us some headaches when a certified model's components change and it stops working for people [16:05] glebaron: it's why in the certification website we show a detailed list of components [16:06] glebaron - +1 to what roadmr said. that's way more important than the difference between 32 and 64 bit [16:06] roadmr, thanks, for the info. It's a very good site. [16:06] glebaron - http://www.ubuntu.com/certification/hardware/201011-6865 [16:06] glebaron - make sure the components match, particularly CPU, wireless and graphics cards [16:06] ok. [16:07] glebaron - so that one is just all onboard, intel graphics and intel wireless [16:09] brendand, the T1600? [16:10] glebaron - yeah. [16:12] glebaron - the E6420 is a tricky one actually. we certified 3 different configs [16:13] yep, it's kinda busy. [16:13] brendand, is there a reason they are not tested with 10.04? [16:15] glebaron: maybe the manufacturer didn't request 10.04 certification [16:15] glebaron - that's complicated [16:15] roadmr's answer is pretty much true [16:15] it's up to the OEM which releases they want certified [16:16] as to why they didn't ask for 10.04, that's what's complicated [16:16] I was just curious. I like 10.04 because I tend to stick with LTS. [16:17] glebaron - could be it's new hardware that doesn't work with older kernels [16:18] brendand, but then you update your kernel and you are good. [16:18] glebaron - update to what? an unsupported kernel? [16:20] brendand, don't they update the kernel pretty regularly. My current one is 2.6.32 and I'm pretty sure I didn't start off with that one. [16:21] glebaron - true, but with bug fixes - not enabling hardware [16:21] glebaron - and actually Lucid has always been 2.6.32, but different versions within that [16:22] latest is 2.6.32-37.81 [16:22] brendand, I learn new stuff every day. Thanks for that. [16:23] last year it was 2.6.32-26.47 [16:25] brendand and roadmr, thanks for the info. I will tell them that the only way to be sure is to test. [16:26] glebaron: yep, sorry about that - 64-bit certification for clients may come in the future, but we don't have a definite timeframe for that [16:38] roadmr - didn't they talk at UDS about making 64-bit the officially supported version? [16:39] brendand: yep, the consensus was to gather information before making a decision - it may or may not happen for 12.04, there's no firm decision that I know of [16:39] brendand: we were asked to provide information from UF and checkbox testing results, I think cr3 found that like 80% of all systems are 64-bit capable [16:40] but also, that ~80% of all installs are still 32-bit (similar %, but of course they don't necessarily overlap) [16:41] https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default === salem_ is now known as _salem