| === bladernr_afk is now known as bladernr_ | ||
| alourie | gema: thanks for the guide fixes, it's much better now | 08:23 |
|---|---|---|
| === bladernr_ is now known as bladernr_afk | ||
| === _salem is now known as salem_ | ||
| brendand | hey mvo | 13:13 |
| mvo | hey brendand | 13:14 |
| 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:15 |
| gema | alourie: no problem! | 13:41 |
| gema | alourie: it was good already, quite sharp on what needs doing, so *thank you* | 13:41 |
| === yofel_ is now known as yofel | ||
| brendand | mvo - so i wrote a script which junitizes all the tests. | 14:10 |
| 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:15 |
| brendand | mvo - yeah, i thought about that a little bit, but didn't get anywhere | 14:19 |
| jp_Hranice | Hallo | 14:23 |
| jp_Hranice | I can not run Ubuntu Precise in low-graphic mode to allow nvidia graphic driver. | 14:24 |
| === bladernr_afk is now known as bladernr_ | ||
| === bladernr_ is now known as bladernr_afk | ||
| mvo | brendand: I think I have some ideas around the junitest stuff, I will push a branch later | 15:09 |
| mvo | brendand: could you please check lp:~mvo/software-center/junitxml ? that contains a small unittest2junitxml helper | 15:14 |
| brendand | mvo - how to use it? | 15:17 |
| 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:23 |
| jibel | for example with s-c this works: python -m subunit.run test_netstatus|subunit2junitxml | 15:24 |
| brendand | jibel - great, thanks! | 15:24 |
| 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:25 |
| brendand | jibel - oh, but i wonder how to make it work with python-coverage then? | 15:28 |
| brendand | i can only seem to get the modified unittest cases to work with python-coverage | 15:38 |
| mvo | brendand: is my small helper not working? | 15:40 |
| mvo | jibel: oh, interessting, I was not aware of this, that would have saved me a bit of poking around :) | 15:41 |
| brendand | mvo - it does work, if you run it like 'PYTHONPATH=.:$PYTHONPATH ./unittest2junitxml test_debfileapplication.py' | 15:43 |
| brendand | and so does jibels tip | 15:44 |
| brendand | but i can't figure out how to combine them with python-coverage | 15:44 |
| mvo | brendand: dosn't "make" just work ? I thought it did for me | 15:46 |
| * mvo tries that | 15:46 | |
| brendand | mvo - ah, yes i see. it does then | 15:49 |
| 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:52 |
| 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:53 |
| brendand | haha, so many options. don't you love the linux world? | 15:54 |
| jibel | anything but rewriting something that already exists :) | 15:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| brendand | glebaron - so that one is just all onboard, intel graphics and intel wireless | 16:07 |
| glebaron | brendand, the T1600? | 16:09 |
| brendand | glebaron - yeah. | 16:10 |
| brendand | glebaron - the E6420 is a tricky one actually. we certified 3 different configs | 16:12 |
| glebaron | yep, it's kinda busy. | 16:13 |
| glebaron | brendand, is there a reason they are not tested with 10.04? | 16:13 |
| 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:15 |
| 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:16 |
| brendand | glebaron - could be it's new hardware that doesn't work with older kernels | 16:17 |
| glebaron | brendand, but then you update your kernel and you are good. | 16:18 |
| brendand | glebaron - update to what? an unsupported kernel? | 16:18 |
| 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:20 |
| 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:21 |
| brendand | latest is 2.6.32-37.81 | 16:22 |
| glebaron | brendand, I learn new stuff every day. Thanks for that. | 16:22 |
| brendand | last year it was 2.6.32-26.47 | 16:23 |
| glebaron | brendand and roadmr, thanks for the info. I will tell them that the only way to be sure is to test. | 16:25 |
| 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:26 |
| brendand | roadmr - didn't they talk at UDS about making 64-bit the officially supported version? | 16:38 |
| 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:39 |
| roadmr | but also, that ~80% of all installs are still 32-bit (similar %, but of course they don't necessarily overlap) | 16:40 |
| brendand | https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default | 16:41 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!