=== Sarvatt_ is now known as Sarvatt === bizkut-miau is now known as bizkut-redhat [03:06] armin76: o/ [03:06] asac: so you need to build for armv7 but no neon? [03:07] fta: isn't the localtime bug (the one you were referring to as the javascript bug) fixed in newer versions of the nivia driver? [03:46] Anyone ever heard of "xpg3sh" as a shell? [09:04] shenki: hi [09:04] shenki: still there? [09:04] asac: yeah [09:04] shenki: yes. if such a disable_neon=1 flag would magically appear in gyp I would start to cry ;) [09:04] okay, i will write the patch [09:05] there are a few other things that need to get fixed [09:05] asac: why do you need this? [09:05] we dont have NEON on armv7 [09:05] because not all armv7 things support that [09:05] Hrm? I thought it was only available on *some* armv7, rather than none. [09:05] ok, so some non-cortex chipset? [09:06] yes ... also old cortex chipsets have issues - like CPU hangs etc. - I was told [09:06] hrm. i wonder if this stuff should be runtime-dependant, like the ffmpeg sse asm [09:06] i asked for that in the bug [09:06] which bug is this? [09:06] cant remember who replied, but that guy said that chromium doesnt want it [09:06] one sec [09:07] http://code.google.com/p/chromium/issues/detail?id=30991 [09:08] Wasn't there a couple chips that claimed NEON support, but it didn't work? I thought I saw a bug about that. [09:09] not sure. in the end it boils down to NEON not working eeverywhere ;) [09:09] thats why we ended up with this approach [09:09] Well, yeah. I'm just not even sure it's safe to do runtime-detect (like for altivec) [09:10] asac: so what floating point hardware do these boards have? [09:11] ah, the dove ones. i should read the entire bug. [09:12] 43 celcius here today, brain is suffering [09:12] i thínk you have no specialized code for those atm [09:12] heh. thats 50 hoter than here ;) [09:12] are you in the outback ;)? [09:12] heh, nup. i leave next to the sea [09:13] s/leave/live [09:13] * asac thinks it must be near a desert :) [09:13] only 48 ... its -5 atm [09:14] nice. i was looking at footage of england on the news, the entire landmass covered in snow. a world away. [09:19] we also need http://code.google.com/p/chromium/issues/detail?id=31274 [09:19] and -fno-tree-sink for gcc44_version=1 http://code.google.com/p/chromium/issues/detail?id=31063 [09:19] (or -fstrict-aliasing) [09:20] shenki: ^^ [09:20] ok [09:23] woah, how did you build v8 with strict aliasing turned on? [09:23] it used to not build with that... dtoa.c was the main culprit, but there was other issues iirc [09:31] shenki: it just builds ;) [09:31] w dont run the test suite [09:31] but the resulting binary worked well too [09:32] there you go [09:33] in which direction :-P? [09:33] mind the walls ! [09:33] ha [09:44] anyone awake with a dove board? [09:50] persia: how did the lsb lib packaging mess work out last night? [09:50] i saw things about /opt etc ;) [09:53] tet-harness is complete. Haven't yet determined if it's sufficient to build t2c-harness yet. [09:53] s/yet/ [09:56] super [10:02] persia: do you have a qemu chroot? [10:02] that works quite well for stuff not too big [10:03] I have hardware :) Can't run a karmic or lucid kernel, but chroots are fine for building. [10:04] The issue is more the complete lack of documentation on t2c-harness, rather than anything else. The docs about t2c-harness talk about t2c-desktop, and the instructions for t2c-desktop don't actually do the expected stuff for t2c-harness. [10:04] Plus, almost none of the code is actually licensed :) [10:05] But I do have a patch to make t2c-harness build for arm: it's just a matter of fiddling to get a debian/rules that can build it. [10:08] sounds like a perfect job ;) [10:08] * persia really prefers nice clean upstreams [10:09] that reminds me to poke ccheney ;) [10:09] heh [10:09] about ugly backports for rolling ffox 3.6 to hardy ;) [10:10] Um, I don't want to know anything more about that. [10:10] hehe... its actually about rolling lucid webkit to hardy ;) [10:10] including all the gnome libs [10:10] required for that mess [10:10] better? [10:10] ;) [10:10] That's going to totally break some stuff. Like midbrowser. [10:11] Just hope nobody with Ubuntu MID has backports enabled. [10:24] shenki, yes, it's the one. there's already a patch: http://codereview.chromium.org/525109 [10:27] fta: okay. so ubuntu still ships old nvidia drivers? [10:28] shenki, depends. we have several flavors. but as i do backports of chromium down to hardy, i have to workaround that bug [10:28] ah [10:29] i forgot that you build for old releases === jmc93739653 is now known as jmc93739653_AWAY [11:07] asac, d'oh! http://identi.ca/notice/18474703 [11:10] ouch [11:16] ricing fail [11:16] why do you guys have so much trouble getting it built :/ [11:16] looks like i was pretty lucky to have it run [11:18] because we live on the edge [11:18] :D [11:19] latest toolchain and compiler as well as the most modern build defaults have their costs [11:33] asac, boooo, upgraded my desktop (karmic), same error [11:33] ok ... escalation needed i guess [11:34] would love to have a working tarball for the archive upload ;) [11:34] :-P [11:34] fta: you said that dev channel isnt updated anymore? [11:34] maybe because of breakages like this? [11:35] fta: gyp was NEWed by heroic seb128 btw [11:35] i already filed a bug ;) [11:35] bug 504716 [11:35] no, the channels (mine) are no updated because they stopped maintaining the LATEST.txt file i use to get the revisions [11:35] noT [11:35] Launchpad bug 504716 in gyp "debian/copyright incomplete" [High,Triaged] https://launchpad.net/bugs/504716 [11:35] any info what they do now? [11:35] or any official reason why they stopped that? [11:36] not yet, internal discussions still going on [11:36] also no reason? [11:36] nope [11:36] sigh [11:36] would prefer to do uploads to archive from dev channel [11:37] sure [11:37] rather than random happy uploads [11:37] but channels are obviously frozen atm [11:38] dev channel has started up again yesterday [11:38] not in ubuntu [11:38] oh, your channels are frozen? [11:39] imo they need to use the same resource that we use [11:39] otherwise it will always end up like that [11:40] shenki, yes, because http://src.chromium.org/svn/releases/LATEST.txt is frozen [11:40] similar to mozilla build systems make install always being busted because they dont use it for their own builds [11:41] asac: where does your system differ? [11:41] from what i understand google uses something internally to update the channels ... [11:42] while LATEST was just for chromium [11:42] yes [11:42] oh. they use svn to branch and release from those [11:42] those branches [11:42] well all the DEPS revisions etc. [11:42] all that info isnt available ... e.g. what revision of webkit they pull for a dev update etc. [11:43] so we cannot produce sources matchine their chrome releases [11:43] we can only build trunk ;) [11:43] okay. i thought that was fixed a while ago...there was a windows guy who kept asking for it [11:43] yes, they introduced LATEST.txt [11:43] i used to have an awesome contact in the google team, he mentord me for the summer of code [11:44] but as they seem to have stopped it i assume they didnt use the same ... e.g. it was just a secondary service for us [11:44] but he quit not long after, and i dont really know anoyne else on the team quite as well [11:44] imo something they dont use will never be reliable enough [11:45] yeah. but even then. thats probably a huge process internally [11:45] yeah [11:45] shenki, i know a bunch of people there, they are working on the problem [11:45] most likely someone loves their cool build system so much that they cannot move to something like LATEST [11:46] but i have no idea whats the status or problems are ;) ... and given that it stalled just a few days ago, i am not yet panicking ;) [11:46] okay [11:47] most likely fta noticed it before they noticed it ;) [11:47] are any of the ubuntu arm guys going to be at linux.conf.au? [11:47] not that i know. when is that? [11:47] week of the 18th [11:47] january? [11:47] in new zealand [11:47] yeah [11:48] ah. so yeah. they guy wanting to go there was pulled into something more important ... [11:48] so no. [11:48] ok [11:48] is that particular important for arm? [11:49] or just a conference you are attending and would like to meet? [11:49] the latter [11:49] kk [11:49] asac, http://paste.ubuntu.com/353424/ [11:50] so it still works without sandbox? [11:50] ;) [11:50] ok, there's already a popular bug: http://code.google.com/p/chromium/issues/detail?id=31809 [11:50] * asac voted [12:17] so plymouth dies [12:30] yeah [12:30] i think we can live with that for now [12:30] also its not even seeded in desktop so there probably is a reason - maybe this? [12:42] might be [13:29] oh, nice - http://www.engadget.com/2010/01/07/freescale-smartbook-prototype-is-a-dockable-tablet-we-go-hands/ [13:29] nifty [13:30] I remember playing with an old HTC device like that at the shop last year, but feared I'd lose the keyboard. This one looks a little bigger. [14:15] plars: here ;) [14:15] asac: so the uboot package version is useful? How if it is different from what's in flash? [14:16] plars: for imx with bootfloppy the uboot package updates the bootloader on install/upgrade .. so there it should match [14:16] i would think we are doing the same for flash on dove [14:17] plars: does dove install update flash? [14:17] * asac has no dove [14:17] asac: the times I've updated uboot on dove before, it was through a tftp image [14:17] manual process, though there may be a better way now [14:18] plars: ok so for now i dont see that we can do anything different than getting the information we see at runtime [14:18] we could mark uboot version as "MIGHT NOT BE RIGHT" [14:18] one thing we could make happen is to pass parameters to the kernel [14:18] Even if there is an mtd driver, and one can access the flash, it's tricky to determine useful information from binary blobs. [14:18] that we can the read later [14:19] like teach uboot to append stuff we want to know: XX_info_uboot_version=XXX [14:19] asac: this might be a good one to defer till A3, when we have uboot support for imx51? [14:19] yeah. i think so [14:19] but we should clarify what info we need for that item [14:19] currently there is just "uboot etc." :) [14:20] certainly [14:21] asac: something we should probably discuss is the review of tests on suspend/resume testing [14:21] the summary data for most of them is filled in, a few NEEDINFO's still there [14:21] but most are not the base tests [14:21] let me check [14:22] asac: https://wiki.ubuntu.com/Specs/Mobile/Lucid/ArmSuspendResumeTesting for the wiki page [14:22] good lp is slow as hell for me atm ;) [14:22] asac: heh [14:22] asac: one of the items targetted for A2 was to review these with you and discuss which should be targetted to do this cycle [14:22] plars: ok lets go through them and assign priorities [14:23] asac: sounds good [14:23] let me dumb what i think maybe update the wiki for things you agree: [14:23] network -> high [14:23] Are these two-level priorities, beyond the BASE, STD, EXTRA we already did? [14:24] no ;) [14:24] heh [14:24] good [14:24] so its done ;) [14:24] I did that last month :) [14:24] I wasn't part of the conversation on base, std, extra [14:24] right. but you didnt put that in the prio column ;) [14:24] so that was a question I had for you [14:24] right [14:24] I'll fix that [14:24] i think memory is not high [14:25] I was thinking that the intention could have been to have priority different from class [14:25] Um, yes it is. [14:25] its of course important [14:25] but we cant test [14:25] If a bank of memory doesn't come back, bad things happen. [14:25] memory/ECC, my thoughts on this were to run [insert memory test here, TBD] while doing suspend/resume, see if anything ugly happens in the process [14:25] besides general stability [14:25] We can certainly test to make sure the amount of ram is the same. [14:25] We can't test the subtleties. [14:25] how do you run a memory test in a running system? [14:26] but do we know that a problem would show up as "reduced amount of memory"? [14:26] otherwise i am fine with that [14:26] that sounds more reasonable [14:26] for me it feels more likely that the system crashes :) [14:26] I can't remember the command right now. There's one that shows you the detected physical memory map. [14:26] asac: true, and things are using memory no matter what... should get tested implicitly to some degree [14:27] right. what we could write is a script that fills up memory until OOM [14:27] or something [14:27] or just arbitrary use of something that uses lots of mem after resume [14:28] we can certainly compare /proc/meminfo [14:28] is that avail on arm [14:28] ? [14:28] yes [14:28] Yep [14:28] memtotal should match before/after suspend [14:28] Right. That's enough of a test. [14:28] Anything else is subtle [14:29] ok [14:29] we could run soimething that makes abit extensive use of mem [14:29] but lets use the memtotal thing for now [14:29] asac: I suspect that will be implicitly covered in some of the other tess [14:29] tests [14:30] for instance, video playback while suspend/resume [14:30] yes, but crashes in there could easily come from graphics driver etc. [14:30] so we have to be carefuly [14:30] some memory intensive calculation algorithm would be a base test [14:30] more we cant do [14:31] audio devices -> the stream should resume where it stopped [14:31] how can that be done? [14:31] using aplay to play something we know how long it is [14:31] and measure the time before suspend and after resume until it finishes? [14:31] and then if the time is close enough we are done? [14:31] asac: that has to be somewhat manual I'm afraid, ask the user to be aware that it doesn't start over, or suddenly skip to the end [14:32] pacat and parec might be a test that more closely matches the audio subsystems in use. [14:32] but we shouldnt use any high level app to rules out app bugs [14:32] asac: user is going to have to listen for it anyway, aplay can't tell you if sound is actually still coming out [14:32] right. but we can measure if it skipped something [14:32] user still needs to provide feedback if there was sound after resume [14:33] Can that just pull the standard test from the desktop hardware testing suite? [14:33] is there such a test? [14:33] Err, yes, but nevermind. [14:33] lets not check how to implement it now [14:33] but rather what we want [14:33] yes, iirc it plays a tone and asks the user if they heard something [14:33] We need to test that it doesn'T skip on suspend, not that it might break on suspend. [14:33] right. but we want to check if things got skipped ... which i am not sure how that can be a suspend/resume problem [14:34] at least not hardware/driver [14:34] feels really like that skipping or starting over would be app prob [14:34] is this spec supposed to cover that? [14:34] if so we should use the default media player [14:35] I recall that was one of the things that was mentioned as an interesting way to test it during the UDS session [14:35] what way is that? [14:35] using default media player? and getting manual confirm that the music continued? [14:35] lets do that then [14:35] if there was heavy skipping, starting over, etc [14:35] ok lets do that [14:36] even if it's an app problem... if it's something that doesn't normally happen, but only happens when returning from resume, then it's good to catch it here I think [14:36] fan/cooling -> we dont have fans on arm, do we? [14:36] thats not BASE imo [14:36] I don't think it's *that* important to have microsecon. accuracy to determine if some amount of audio was skipped though [14:36] cpufreq/voltage can be done by compraing /proc/cpuinfo i woul dhope [14:37] plars: yes. lets implement that .. .asking the user if the music continued [14:37] (explicitly saying: did it start over etc.) [14:37] asac: so should we cancel fan/cooling? I haven't seen a fan on any of my arm procs so far [14:37] move to EXTRA [14:37] thats currently the dump that doesnt get implemented by us [14:37] hmm [14:38] ok for cpufreq test? [14:38] no [14:38] cpuinfo will not tell us that [14:38] iirc, bogomips only gets calculated on boot, everything else there is pretty static I think [14:38] ok. then you want to do what? see how long a algorithm takes with nice -MAX ? [14:38] yes. but if there is cpufreq change on my intel/amd the output adapts e.g. for powersave [14:39] if thats not good enough we should run something complex and see how long it takes with max prio [14:39] and if it doesnt deviate consierably (like 20%) we are fine [14:39] makes senes? [14:40] i am spotting media playback in STD [14:40] so how about really keeping the desktop test case for the audio devices test [14:40] and doing the media player tihng we discussed there? [14:40] PLUS video [14:41] asac: you mean combining it? [14:41] yes. e.g. the STD: media playback thing would get the high level app testing we discuss [14:42] and the BASE one would be just the current test we already have [14:42] e.g. BASE == hardware ... STD == application level [14:42] asac: sounds good [14:42] cool [14:42] SD card removal during sleep [14:42] for mounted devices [14:42] ? [14:42] without replug= [14:42] ? [14:43] that is what was discussed at UDS [14:43] same for usb/usb ... isnt that covered by the BASE HID test? [14:43] mounted, but should not be in use [14:43] plars: ok so we want to see that removing mounted SD card during suspend gets unmounted on resume [14:43] I wouldn't think that would be in base HID [14:43] thats easy to check [14:43] plars: the usb/usb thing? [14:43] asac: right, usb [14:43] why not? we have a bunch of usb stuff for HID [14:44] asac: ah, I'm referring to USB block devices, not char [14:44] usb char devs, such as kbd, mouse, etc would certainly be covered under HID [14:45] ok so cant we make a generic "block device" removal + unmount test? [14:45] e.g. combine that with the SD thing? [14:45] anyway, if thats clear its ok to keep it [14:45] asac: it would save us one test, but might muddy up the results [14:45] we can figure that during implementation [14:46] but checking for something being not in mount after resume is easy enough [14:46] if the tester forgets to specify (we hope not, but still) then you know that there was either a problem with SD removal, or USB removal [14:46] lets clarify on wiki that usb/usb is about block devices ... then i am happy [14:46] STD:NAND/MTD -> i think that should go to extra unless we know whats going on [14:46] agree [14:46] for now i would think that NAND is only relevant during boot [14:47] so it isnt even touched at resume/suspend [14:47] cool lets move it down, maybe dropping that comment in there ... [14:47] Um, depends on the device. [14:47] NAND *is* the primary secondary storage on a number of devices. [14:48] But the test is easy: just confirm you can read from the mtd [14:48] writing is a bonus. [14:48] persia: you have generic way of doing that? [14:48] if you think its doable thats ok. is NAND a secondary storage on any of our supported devices? [14:48] how do we detect NAND mounts? [14:48] Umm... [14:49] for me it feels like EXTRA ;) [14:49] Fine. [14:49] backlight ... no idea how to test that. for some devices we might be able to check the value in /sys/proc [14:49] plars: I have a way that works on my hardware. No idea if it works on supported boards. [14:49] add persia to the comments column ;) [14:49] asac: Do any supported boards have built-in screens? [14:50] no. but devices [14:50] like smartbooks ;) [14:50] Yeah, but it's a lot harder to test backlights when you can't see them. [14:50] right, I don't have a way of testing it with anything I have at the moment [14:50] I'd be happy to do a backlight test, if I had a kernel :) [14:50] we can see them. we need a pegatron or something [14:50] plars: manual would be only option [14:51] imo its EXTRA too ;) [14:51] maybe we can ask if chaning backlight after resume works still [14:51] that would be more STD [14:51] asac: fair enough, we can easily implement a manual test for it at the moment, and that can be adapted later if we have an improved way [14:51] wireless soft switch is a none issue ... for instance NM resets that on resume ;) [14:51] plars: so asking if changing backlight still works or if screen is still same brightness? [14:52] asac: wireless soft switch is to confirm that NM *can* reset it on resume [14:52] asac: both! [14:52] the summary says its supposed to test if its the same [14:52] problem is that we have a race [14:52] Then drop it. Doesn't make sense to test that. [14:52] but its doable [14:53] we can compare rfkill info [14:53] thats easily [14:53] If it's easy, then nevermind. [14:53] yes. lets keep it. rfkill compare ... and ensuring that its off in the end [14:54] a) compare rfkill output from before suspend with before NM gets resume dbus call [14:54] b) does NM reset it [14:54] latter probably manually [14:54] we can certainly do a) [14:54] keyboard softswitches is probably ok. [14:54] not sure if that is that important though ;) [14:54] if they work its fine [14:55] but thats covered by HID somewhat [14:55] hmm... is there an easy automatic way to determine if caps/num, etc are set/unset? [14:55] encryption engine? ... maybe for installs with encrypted home check if we can still read from home? [14:55] I don't like the HID testcase. [14:55] why? [14:55] I think the thing to check is that putting power back on USB actually restores the device function. [14:55] Not just removal during sleep. [14:55] encryption engines I believe should be in extra [14:56] I've had laptops where USB HID didn't work over suspend/resume. [14:56] persia: so a better test you think would probably be just to see if they still work after resume? makes sense [14:57] plars: Both make sense, but HID still working after resume is significantly more critical than being able to hotplug. [14:57] agree [14:57] encrypted home is a official install option. if that falls under encryption engine we should keep it in STD [14:57] Because if some device has internal USB HID connections to, say, the keyboard, the end user isn't going to be able to reset it. [14:58] persia: HID definitly covers that it still works [14:58] its about replugging while asleep [14:58] asac: I took encryption engine to refer to hardware special purpose processors that some devices may/may not have [14:58] we can extend that test case to ask for not replug though [14:58] asac: But I also want to test that it works when you don't do anything and sleep. [14:58] plars: ok. then extra [14:58] if we extend it to cover ecryptfs, then it's not hardware related at all [14:58] persia: right. lets extend the test case ... add that to summary [14:58] I thought encryption was about encrypted home too, which is why I put it in STD. [14:59] plars: yeah. not sure if the fs thing would make use of those hardware things [14:59] i would hope it does [14:59]