=== robbiew is now known as robbiew_ === asac_ is now known as asac === KatieKitty is now known as KatieOffline === KatieOffline is now known as KatieKitty === KatieKitty is now known as KatieOffline === KatieOffline is now known as KatieKitty === KatieOffline is now known as KatieKitty [10:58] popey, pleia2, technoviking, nixternal: around? [11:00] yup [11:01] mako is not on freenode, or he is somebody else or something and sabdfl can't make it, mdke probably neither [11:01] I just had a look at https://wiki.ubuntu.com/CommunityCouncilAgenda and it seems that every topic is a 21 UTC topic [11:02] I realise that mdke's and my item has been on it for a very long time, so I'll try to take if off of there (as I normally can't make the 21 UTC times) and try to figure out something via email [11:03] ok [11:03] Emmet's item depends on the DMB election, so it'll need to wait a bit until the DMB election was closed [11:03] fastest meeting ever [11:03] do you have anything that needs to be discussed? [11:03] or does anybody else have anything? [11:03] i dont [11:04] let's wait a few ticks then to see if anybody else does :) [11:05] alrightie... I'll write something quick up for the team report then [11:05] does this meeting time ever work ? [11:05] czajkowski: usually it does :) [11:05] hmm ok [11:05] it's just that we didn't have much to discuss this time :) === dholbach_ is now known as dholbach [12:17] Um, my item was covered in the last meeting, and passed by a majority. Sorry to not remove it from the agenda for this time. [13:00] #startmeeting [13:00] Meeting started at 07:00. The chair is NCommander. [13:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [13:00] * JamieBen1ett waves === JamieBen1ett is now known as JamieBennett [13:00] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100119 [13:00] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100119 [13:00] * ogra coughs [13:00] * GrueMaster opens a weary eye. [13:01] [link] http://piware.de/workitems/mobile/lucid/report.html [13:01] LINK received: http://piware.de/workitems/mobile/lucid/report.html [13:01] * cooloney1 waves [13:01] [topic] Action Item review [13:01] New Topic: Action Item review [13:01] hi [13:01] [topic] asac, ogra, persia to make sure .32 backporting for imx51 kernels is documented somewhere (c/o). [13:01] New Topic: asac, ogra, persia to make sure .32 backporting for imx51 kernels is documented somewhere (c/o). [13:01] It's documented somewhere. It's just not very complete. [13:01] ok [13:01] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100112/FSLKernelBackport [13:02] persia, do we need a c/o on this one? [13:02] yeah, i updated some on it [13:02] Needs more input from the people wo haven't finished (JamieBennet, cooloney) [13:02] * JamieBennett got sidetracked this week [13:02] NCommander: Better would be to have specific action for JamieBennet on bootspeed (or reassign) [13:02] leave it with me [13:02] i will ping dtchen again [13:03] [action] JamieBennett to complete imx51 backportng documentation on bootspeed. [13:03] ACTION received: JamieBennett to complete imx51 backportng documentation on bootspeed. [13:03] [topic] [topic] asac to discuss with dmart how to best tackle the list and assign packages to team members etc. [13:03] New Topic: [topic] asac to discuss with dmart how to best tackle the list and assign packages to team members etc. [13:03] cooloney1: Are there really only two patches of interest in kernel/ubuntu? [13:03] yes, we started to go through the list [13:03] persia: actually, i am not sure about the requirement. [13:03] added more variables for prioritization (e.g. number of rdepends) [13:03] and section [13:03] so thats done [13:03] its work in progress [13:03] we will assign bugs for the important ones etc. [13:04] just got that requests from ogra before, than looked at those feature and backported and built the kernel [13:04] asac, do we need any action items for actually opening the bugs? [13:04] cooloney1, requirement is that most or all HW i plug into my laptop should work the same way on my babbage [13:04] no [13:04] thats part of the thumb2 spec imo [13:04] already covered [13:04] [topic] dmart to investigate test procedures at ATM which may work on dove [13:04] New Topic: dmart to investigate test procedures at ATM which may work on dove [13:05] cooloney1, and that features we develop in-house should not be broken due to linux-imx being behind [13:05] dmart: did you find anything= [13:05] ? [13:05] is that actually still relevant? [13:05] Unfortunately, I didn't come up with much useful. Most of our tests are hardware-level, and can't be used on real silicon. [13:05] yeah [13:06] Running things like the GCC bootstrap / testsuite seems a good idea if not done already [13:06] Was there any progress on that? [13:06] dmart, negative, board is too unstable to even get that far [13:06] who had that item? [13:06] me? [13:06] ogra: heh, that needs go through all the .32 kernel patches, a hugh task [13:06] dmart: or doko ? [13:06] [topic] ericm, NCommander, GrueMaster to work on dove kernel debugging [13:06] cooloney1: Yep. [13:06] New Topic: ericm, NCommander, GrueMaster to work on dove kernel debugging [13:07] cooloney1, nah, not *all* ... focus should be on in-hoouse development we do (apparmor, aufs ... and kernel/ubuntu ) [13:07] seems I joined the right moment [13:07] hi ericm [13:07] Not much I could do, as once the system locks, nothing is logged. [13:07] ericm, indeed :-) [13:07] So, based on conversations with Marvell, we have an actual silicon bug, not a kernel bug. [13:07] asac: test / boostrap wasn't a formal action. I can't do it because I don't have the board though ;) [13:07] well, here are some updates [13:07] ogra: ok, got you, will go through all our Ubuntu lucid .32 master kernel patches [13:07] dmart: ok lets talk afterwards so i understand what this involves [13:08] OK [13:08] I was in Marvell Shanghai office and helped them test a little bit on their X0 board [13:08] For my understanding, is this purely a kernel issue, or userspace? (or both?) [13:08] so far so good, no system freeze issue (once ever been observed though not sure if it's the same symptom as in Y1) [13:09] ericm: could you reproduce the issue in front of them with YX? === fader|away is now known as fader_ [13:09] Y1 [13:09] yet gnome-panel still respawns and ubiquity failed when partitioning [13:09] or Y0 [13:09] asac, yes they know the issues [13:09] ericm, thats a general bug (ubiquity) [13:09] ericm, the ubiquity fails with partitioning is a code bug, not a thumb2 bug :-) [13:10] ogra, well I guess this doesn't happen on imx51? [13:10] it does apparently [13:10] It does :( [13:10] ericm: ok. what about the emulation front. do they know which instructions trigger this? [13:10] i havent seen it, but i didnt test with manual partitioning [13:10] but gnome-panel also respawns again and again on imx51? [13:10] no [13:10] afaik it even happened on x86 [13:10] for me it feels related [13:10] the panel issue seems related, yes [13:11] partitioning doesnt [13:11] right [13:11] asac, what you mean by emulation front and instructions trigger this? [13:11] [action] eric and NCommander to investigate what causes the gnome-panel crash/restart cycle [13:11] ACTION received: eric and NCommander to investigate what causes the gnome-panel crash/restart cycle [13:12] ericm: i thought we think that some thumb2 instruction triggers this [13:12] do we know which one [13:12] ? === yofel_ is now known as yofel [13:13] asac, ah yes - it's VLDR [13:13] and only when VLDR in thumb2 mode [13:13] it's actually not a thumb2 instruction, but a VFP register load instruction [13:13] Is there any bug report or other info I could look at? [13:13] but if that instruction happens in thumb2 mode, incorrect alignment fault happens [13:13] ericm, can't we use the kernel to trap and rewrite the thumb2 instruction so we shift back to ARM mode during the VFP register load? [13:14] NCommander, they already provided the workaround and was merged in karmic, otherwise will be overwhelmed in alignment faults error messages [13:14] so we can pull that workaround? [13:14] NCommander, and the workaround works almost same as you mentioned [13:15] ericm, if the workaround is in karmic, then why do we still see such broken behavior? We merged previous thumb2 patches which helped [13:15] Might this be connected with the other instability? [13:15] ericm: ? [13:15] probably [13:15] (instability) [13:15] I'll say the patch doesn't work all the time [13:15] ericm: my question is: qhy isnt that workaround in karmic [13:15] you mean lucid [13:15] asac, it's already in karmic-proposed [13:15] yeah [13:15] sorry [13:15] lucid [13:16] it's there [13:16] but its not sufficient apparently [13:16] ogra, exactly [13:16] ogra, likely another instruction or two has issues [13:16] right [13:16] thats what you say NCommander .... ericm didnt say that [13:17] he said tits just that instruction [13:17] NCommander, either another instruction or the workaround doesn't solve the issue in some corner cases [13:17] yet I guess the latter is more likely [13:17] ok. how serios is this worked on at marvell side? [13:17] since I don't see system freezing on X0 (once - but not confirmed it's related to this) [13:17] do we need to elevate priority on their side? [13:17] would that help? [13:18] ericm, try and build GCC and other large packages as a stability test on X0 [13:18] asac, they are already aware of the issues - and provide some suggestions as could be seen from the mails I get you CC'ed [13:18] but nothing really made progress [13:19] ok. just want to understand if we need to ensure that this gets top priority for them. [13:19] but lets talk after meeting [13:19] by now, I guess we need to push Marvell to provide some more X0 boards to us [13:20] [action] asac, ericm, and NCommander to talk about Thumb2 issues after the meeting and report back [13:20] ACTION received: asac, ericm, and NCommander to talk about Thumb2 issues after the meeting and report back [13:20] ericm: our primary objective would be to get it worked around in X1 [13:20] Y1 [13:20] or 0 [13:20] asac, I agree we need to make sure they know this as top priority [13:20] [topic] ogra to care for seed changes to get oo.o off the image [13:20] New Topic: ogra to care for seed changes to get oo.o off the image [13:20] ericm: right [13:20] NCommander, wasnt needed [13:20] that turned out to be a non-issue [13:20] cool [13:21] [topic] Standing Items [13:21] New Topic: Standing Items [13:21] oh [13:21] wait [13:21] that url is wrong now [13:21] [LINK] http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html [13:21] LINK received: http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html [13:21] thats the new one [13:21] the trend line will be set to 145 [13:21] asac, thanks [13:21] * asac updates [13:21] wiki [13:21] shriek [13:21] [topic] Kernel Status (cooloney, ericm) [13:21] New Topic: Kernel Status (cooloney, ericm) [13:22] NCommander: sop ;) [13:22] stop [13:22] so [13:22] i got a new fsl bsp from ogra [13:22] the work items seems quiet a lot [13:22] that introduces 30+ kernel patches. [13:22] i would reall like to see everyone going through it and checking the count of workitems and see if there are things that are reall off for alpha-3 [13:23] * ogra hands asac two y's [13:23] NCommander: can you please wait before moving on in general? [13:23] asac, sorry [13:23] you never ask if a topic was done [13:23] doesnt matter now ;) [13:23] asac: yeah, i stopped, heh [13:24] so move on. just include that prominently in the meeting notes [13:24] [topic] Kernel Status (cooloney, ericm) [13:24] New Topic: Kernel Status (cooloney, ericm) [13:24] asac, what are canonical-mobile workitems ? [13:24] ogra: thats a pool of items anyone can claim ;) [13:24] team specs ;) [13:25] you can claim items by adding [ogra] before them [13:25] given the amount of personal items we already all have i think its unlikely anyone would do that [13:25] not sure that applies for everyone [13:25] yeah, probably not [13:26] I suppose if no-one claims them asac can distribute them ;) [13:26] heh [13:26] yeah [13:26] yes, but we should set a deadline for that [13:26] anyway. you can also pick such items if you are blocked or something [13:26] else they will likely just be lost [13:26] and make us look bad [13:27] the deadline is the milestone [13:27] so are we done with the burndown charts? [13:27] the items there will not make us look bad if all other items are done :) [13:27] * ogra is [13:27] NCommander: why? that url has a burndown too [13:27] http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html [13:27] LINK received: http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html [13:27] well, they add to the overall statistic :) [13:28] http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html [13:28] asac, I know. [13:28] LINK received: http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html [13:28] ok [13:28] yes, that topic is over i hope [13:28] ericm, cooloney1 anything else you want to bring up on the topic of the ARM kernels? [13:28] if anyone has something we can move that to AOB [13:28] NCommander: yeah [13:28] continue my words. [13:28] ok lets focus on kernel ;) [13:29] asac, nothing from my side [13:29] i already tested the Alpha2 kernel + 30+ new kernel patch [13:29] it works fine. [13:29] the existing patches didnt change in the new BSP ? [13:29] and for the NEON issue, I provided 2 solution kernels [13:29] what do such tests involve? are you running a full image? [13:30] asac: i just build the kernel and replace it on my board [13:30] installed the kernel on my board [13:30] the package i guess ? [13:30] ok [13:30] and will post the package to you guys to test [13:30] curious about the NEON things ;) [13:30] yeah [13:30] what approaches? [13:30] yeah, NEON things, i provided 2 packages [13:31] 1 disable NEON defaultly [13:31] 2 a kernel side dynamic checking [13:31] i think dmart tested all of them on bb2.5 [13:31] cooloney1, is that the patch you worked on last week? I tested on babbage 2.0, bug I think ogra or someone had a problem on 2.5? [13:31] wehat made me curious is the different revisions we see in /proc/cpuinfo [13:32] but as we discussed before, method 2 might not be very safe for all the solution [13:32] dmart, i didnt test that kernel yet [13:32] must be someone else [13:32] (likely plars) [13:32] hmmm [13:32] yeah, JamieBennett tested that , [13:32] ah [13:32] cooloney1: what does t method 2 base the decision to enable thumb on? [13:32] ogra, I think you're right [13:32] but from JamieBennett's cpuinfo, i was confused [13:32] yes but revision numbers seem to be different from expected [13:32] yes, thats what i meant above [13:32] the cpuinfo of his JamieBennett's BB3 is the same as my BB2.5 [13:33] and mine seems totally different from all of them [13:33] (i noted mine in the bug) [13:33] ogra: yeah, i have no idea about that [13:33] cooloney1, ugh :P [13:33] That's a problem... [13:34] cant the kernel find out about that on a different (lower) level ? [13:34] ogra: yeah i was told bb3 should be 51130 [13:34] Look at the implementation of the BSP's "get revision" function? [13:34] * ericm wonders what is 51130 ... [13:35] ericm: the revision of the chip [13:35] ericm: sorry, the board, [13:35] so we probably cannot detect reliably if NEON is stable enough? [13:35] looking at the different outputs it seems the last two numbers are what counts [13:35] Maybe not... I have a conf call with David Mandala later today about what the high-level strategy should be for CONFIG_NEON in general [13:35] but that still doesnt explain why JamieBennett's ends in 20 [13:35] dmart: yeah, agree. need to discuss that [13:36] asac and ogra, what's you guys suggestion? [13:36] method 1 disable NEON for all [13:36] well, if there is another way to determine the revision, we should go for that one [13:36] or method 2 dynamic check that [13:36] if not, drop NEON for now if possible [13:37] cpuinfo surely doesnt seem reliable enough [13:37] dynamic check if we can do it reliably [13:37] otherwise NO [13:37] ++ [13:37] ogra and asac, understand. [13:37] agree. [13:38] I can double check everything after the meeting with cooloney1 [13:38] Is that everything on the imx51 kernel to talk about here? [13:38] please add me an action about 'ping fsl for more reliable chip rev checking method' [13:38] one more thing is i am working on suspend/resume [13:38] and pinged fsl about suspend, they did not reply yet [13:38] NCommander: action please. [13:38] [action] cooloney1 to ping fsl for more reliable chip rev checking method [13:38] ACTION received: cooloney1 to ping fsl for more reliable chip rev checking method [13:39] for me in former tests suspend worked [13:39] [action] cooloney1 to ping fsl about suspend [13:39] ACTION received: cooloney1 to ping fsl about suspend [13:39] is that possible davidm to help that. [13:39] ogra, what action do you need? [13:39] cooloney1, we can bring it up in the weekly call [13:39] NCommander, none [13:39] NCommander: sorry, i ping fsl about suspend before. heh [13:39] May I move on? [13:39] ogra: thanks a lot [13:39] yeah, [13:39] yes. thanks ericm and cooloney1 [13:39] [topic] ARM Application status (JamieBennett, dyfet) [13:39] New Topic: ARM Application status (JamieBennett, dyfet) [13:39] cooloney1, my issue was that i couldnt find a methid to wake it up [13:40] not problem asac [13:40] ogra: ok, your board is different with magic rev? ;)) [13:40] well, its a 2.5 :) [13:41] dyfet, JamieBennett, ping? [13:41] anyway, thats details we can discuss out of meeting [13:41] I have nothing to report on package issues [13:41] although I see the FTBFS list has some important packages failing [13:41] JamieBennett, indeed, we'll get there in a moment :_) [13:41] Haven't looked into them though [13:41] JamieBennett, can I move on? [13:42] yes from me [13:42] [topic] ARM Porting/FTBFS status (NCommander, dyfet) [13:42] New Topic: ARM Porting/FTBFS status (NCommander, dyfet) [13:42] as JamieBennett said, we do have a few FTBFS'es that need to be resolved (evolution being the big one my list this morning) [13:42] looks like a give back to me [13:42] Over all, there is a general trend of improvement on this, so we're goingthe right way [13:42] ogra, cool (I hadn't looked at the log yet) [13:43] i havent looked either [13:43] but evo, ampathy and evo-couchdb are ususally give back candidates [13:43] NCommander: can you help dyfet a bit on his ftbfs'es? [13:43] asac, sure [13:43] i would hope that you could work together in a pair-programming approahc [13:43] they rely on arch all packages [13:43] asac, pair-programming? [13:43] ... usually you get same or better throughput than doing alone [13:43] I am waiting on one ftbfs to be updated in debian, but I will coordinate this week on ftbfs with NCommander to get high priority ones done [13:44] NCommander: yes, try to work with him on a shared pool of tasks. taking about the steps, ideas etc. [13:44] asac, ah [13:44] plymouth just needs a rebuild, pending a fix for libdrm (in sponsors queue) [13:44] dyfet, mind if I move on, or do you have other things to add? [13:44] nope [13:44] [topic] ARM Image Status (ogra, persia) [13:44] New Topic: ARM Image Status (ogra, persia) [13:45] I'm having issues finding the logs that I don't get in mail, so I'm not entirely sure about current state of kubuntu or xubuntu. [13:45] hmm, se didnt get images since 13th [13:45] Ubuntu livefs needs evolution help. [13:45] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-imx51/ [13:45] LINK received: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-imx51/ [13:45] i'll check clementine ... guess she's unhappy again [13:45] ogra: I was looking there, but no recent updates that I saw (but I have newer logs in email) [13:46] regarding the image status - found package xorg not properly named in pool/main/x/xorg/ in alternate image (looks like a DOS name error to me) [13:46] well, if logs dont show up there its very likely that clementine hangs [13:46] * NCommander grumbles [13:46] ogra: It's not clementine: the processes are running. Check how the logs are published, perhaps? [13:46] [action] NCommander to investigate ericm's xorg naming bug. [13:46] ACTION received: NCommander to investigate ericm's xorg naming bug. [13:46] ericm, hmm, i thought NCommander fixed that [13:46] ogra, I did. xorg might have broke it again :-/ [13:46] * persia is getting livefs build failure notifications [13:46] persia, i'll look on clementine dircetly fiurst [13:46] OK. [13:47] persia, ogra ok to proceed? [13:47] Yes. [13:47] so is that an mtools bug again=? [13:47] asac: No. [13:47] NCommander, yup [13:47] [topic] Ubuntu Liquid [13:47] New Topic: Ubuntu Liquid [13:47] asac, looks like to me [13:48] rbelem and I worked on packaging some of the outstanding interface stuff on Saturday and Sunday. [13:48] great. [13:48] Unfortuantely we both fell simultaneously and unrelatedly ill, and didn't get everything compelted. [13:48] We're hoping to push the rest of the missing packages this week. [13:48] how many packages are needed? [13:48] just rough estimate [13:49] plasma-mobile, ubuntu liquid metapackage and liquid default settings to start [13:49] I can't find the list right now. [13:50] ian_brasil_: thanks. [13:50] so anyone feels that this is at risk? [13:50] persia, anything else, or can I go onto AOB? [13:50] It's a couple plasma widgets + kdm-mobile and kwin-mobile (as we can't integrate the stuff upstream for lucid) [13:50] or needs a push? [13:50] Oh right, and -default-settings and -meta :) [13:51] persia: Riddell offered to helkp on the plasma bits [13:51] afaik [13:51] so tap him to get the packaging going :) [13:51] rbelem and I get back in touch about an hour back, and feel we can make good progress this week. We might ask for help to get REVU advocations for some of the new stuff. [13:51] yes. [13:51] persia, FYI, seems the logs are missing due to rookery reorganization [13:51] asac: Riddell has been helping a lot :) [13:51] ok cool. [13:51] ogra: That makes sense. Let's get that sorted :) [13:51] yep [13:51] persia: ping me and ogra for revu review [13:51] NCommander: I'm done, unless ian_brasil_ has something else (rbelem couldn't make it today) [13:52] and NCommander ... i guess [13:52] ian_brasil_, can I go ahead? [13:52] yes..persia if you can help with kwin-mobile that would be great [13:52] yes [13:52] [topic] Any Other Business [13:52] New Topic: Any Other Business [13:52] did we skip QA status? [13:52] yep [13:52] ian_brasil_: We're planning that for tonight, if we can. [13:52]