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