=== robbiew is now known as robbiew_ === bjf is now known as bjf-afk === asac_ is now known as asac === Ioneye is now known as Ion[AFK] [01:49] valgrind complains that my code has a jump that depends on an uninitialized value, but I believe that is what I want (check if a value is null before operating on it). Is this the correct behavior, or should I tell valgrind to ignore it? [01:49] meanburrito920_, wrong roo [01:49] room [01:49] oops [01:49] sorry, thought I was on ##programming :) === jtisme is now known as jtholmes [02:42] meanburrito920_: damnit, I want to answer your question [02:43] why do you think that the value is NULL to begin with?: [02:43] I suspect your error is that you're assuming the value has been initialised to NULL [02:43] when, in fact, it hasn't [02:43] so you really are comparing uninitialised data [02:43] which is clearly the exact opposite of what you want [02:43] since uninitialised data may well not be NULL [02:43] i dont know if it will be null; it gets passed in from a function [02:44] right, valgrind follows things through [02:44] lets move this discussion to ##programming instead of using this channel === nxvl_ is now known as nxvl === cjwatson_ is now known as cjwatson [13:00] hi [13:00] O hai [13:00] moop [13:01] * plars is [13:01] hello [13:02] GrueMaster: dyfet: JamieBennett: meeting O'clock ;) [13:02] hello folks [13:02] hi [13:02] hi cooloney [13:02] who is running the meeting? [13:02] * GrueMaster Zzzzz. [13:02] * ogra saw GrueMaster [13:02] davidm: me i guess [13:02] NCommander didnt hand it off to anyone :( [13:02] davidm: is using mootbot essential? [13:02] asac, you need to start mootbot [13:03] we usually use it [13:03] asac, yes it logs the minutes [13:03] #startmeeting [13:03] Meeting started at 07:03. The chair is asac. [13:03] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [13:03] hi, all [13:03] I assume this is a public meeting? [13:04] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091201 [13:04] ericm, yup [13:04] [LINK] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091201 [13:04] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20091201 [13:04] [TOPIC] Specification Review [13:04] New Topic: Specification Review [13:04] [LINK] https://blueprints.edge.launchpad.net/ubuntu/lucid/+specs?searchtext=mobile+lucid [13:04] LINK received: https://blueprints.edge.launchpad.net/ubuntu/lucid/+specs?searchtext=mobile+lucid === persia` is now known as persia [13:05] so first thank you everyone for the spec work done [13:05] mobile-lucid-arm-gcc-v7-thumb2 should be marked informational (since it was informational) [13:05] ogra: the idea is to document the rebuild procedure etc. there [13:05] will be finished today. [13:05] right, but does that make it less informational ? [13:06] its only documenting what we do on the go, no ? [13:06] ogra: it has actions attached [13:06] well, apw attached one today [13:06] which he already solved [13:06] ogra: no. i mean: the rebuild archive notes have actions [13:06] we should track imo [13:06] ok [13:07] ok [13:07] i thought that was covered by the lib testing one [13:07] so one thing we need to ensure is that the milestone target is about right by end of today [13:07] if people arent aware yet davem created https://wiki.ubuntu.com/ARM/Thumb2 for the transition [13:07] there are quite a few with alpha-1 milestone ... which afaict sounds too eager [13:08] ogra: right. that will be referenced from the gcc spec [13:08] currently it doesntz look like we can even make A1 [13:08] but i'll elaborate later (in the ARM topic) [13:08] right [13:08] JamieBennett: mobile-lucid-une-2d-launcher ... you think its realistic to have something at alpha-1? [13:09] * asac answers questions and moves it to alpha-2 [13:10] ogra: mobile-lucid-imx51-debian-cd-to-uboot ... is imx51 uboot done already? [13:10] nope, only proof of concept [13:10] but based on that i should be able to implement it until A2 [13:10] ogra: implemente == includes the cleanup/unification? [13:10] the image issues we have are more serious, i'm concentrating my dev/debug work on that atm [13:11] k [13:11] no, unificatrion is NCommanders work, the uboot stuff for imx51 is the stuff thats not unifyable [13:11] ok but alpha-2 seems reasonable -> targetted for that milestone [13:11] right. just wanted to understand what work will be done by alpha-2 then [13:11] yeah [13:12] mobile-lucid-arm-alternate-images -> targetted for alpha-1 ... [13:12] i guess they buiold, didnt look depply yet [13:12] given that ncommander is on vacation till shortly before alpha-1, i would think thats not happening in time [13:12] hmm, no, they dont [13:13] there were no needed changes [13:13] Retargeting alternates for alpha-2 seems right. There might be some for alpha-1, but they wouldn't be well tested. [13:13] we used to build them before [13:13] We built them, but I don't think we tested the installs much. [13:13] so the general builds should just happen [13:13] ok doing. [13:13] right [13:13] well, i tested all imx51 once during karmic [13:14] i think the milestone we communicate in the spec should be the "beta available" delivery [13:14] but not for each milestone [13:14] so if we have QA and bugfixing actions they can be done after the mentioned milestone [13:14] testing alt. images simply takes to long [13:14] That's good to hear. I thought they were even less tested than that. [13:14] so "Smoke-test ARM alternate images built by the build system [2 days]: TODO" [13:14] they all had bugs :) [13:14] needs more days? [13:15] smoke test should be doable in 2 days [13:15] 2 days is enough to smoke-test 2 flavors on 2 boards, I'd say. [13:15] proper testing would need more [13:15] Yeah. [13:15] ok i think smoke test is what is covered by the spec [13:15] the rest should go into our QA processes [13:15] (alt install test on the babbage takes at least 3h per installation ... vs 1h for live) [13:15] ok next one: mobile-lucid-bringup-testing [13:16] asac: I'll have it partially done at A1, but would like to target for a2 completion [13:16] plars: i think this is mostly about documenting/specification of the testing and some checkbox support [13:16] plars: ok. so documentation/specification by A1, implementation/automization by A2? [13:16] asac: we need some additional tests, and a checkbox plugin [13:16] and a few other bits [13:16] right [13:17] ok [13:17] lets target it officially for alpha-2 then [13:17] plars: if you have work items yo know that will be finished for alpha-1 you can use this syntax: [13:18] Work items (MILESTONE): [13:18] ... [13:18] ok [13:18] MILESTONE=alpha-1 etc. [13:18] same for everyone ... if you want to split the work in chunks by milestones, you can use that syntax (pitti is working on implementating this for the burndownchart thing) [13:19] next: mobile-lucid-arm-lightweightbrowser [13:19] i think we should target both: optimized firefox as well as a chromium browser in archive for alpha-2 [13:19] Okay....and a2? [13:20] there will be some issues that might take till beta, like how to best integrate with mailto/doc content on the desktop [13:20] but those should be tracked in other specs imo [13:20] The one I noted was with gconf keys for default browser, but yes, there is likely other issues [13:21] dyfet: there is quite a few things to evaluate/implement. lets talk about that after meeting [13:22] agreed [13:22] next: per-soc-powermanagement -> ogra, i assume we target that for alpha-2 too? [13:22] yeah, at least [13:22] we need to wait for the new kernels anyway [13:22] ogra: you are the assignee i guess? [13:22] yep [13:22] at least i have most of the action items [13:23] ogra: can you add the "wait for new kernel" action item? [13:23] though its spread across people and teams [13:23] yup [13:23] it just struck me today that it doesnt makes sense to fiddle with the old kernels [13:23] ogra: ok. so alpha-3 is more realisitic? [13:23] huh, i cant edit [13:23] oh, somhow LP logged me out [13:24] hehe [13:24] yeah, i guess [13:24] ericm, cooloney, any ETA for new kernels ? [13:24] (we currently have the karmic ones only) [13:24] ogra, I think we have the kernel for Freescale it's not planned to change [13:24] ogra, not atm [13:24] ogra: as we just talked in #kernel [13:24] davidm, i was told differently by the kernel team today [13:24] since lucid imx51 kernel will still be .31 === fader|away is now known as fader_ [13:24] it will not be compiled into thumb2, [13:25] just let you guys know that. [13:25] davidm, the lucid kernel will use the complete new FSL drop instead of our forward ported patches [13:25] davidm, which definately adds delay [13:25] ogra, not until such time as Freescale drops one [13:25] ok lets add a agenda item about "kernel status" and continue with specs for now? [13:25] ogra: yeah, seperate tree [13:25] davidm, which is due this week [13:25] yes [13:26] next is mobile-lucid-arm-device-tree-support [13:26] JamieBennett: i assume that is earliest at alpha-3? [13:27] asac, I think jk has done some prototyping work on this [13:27] JamieBennett: do you want a standalone agenda item to report about the progress monitoring? [13:27] "Weekly monitoring of Grants git tree and report progress (until delivery DATE): TODO" [13:28] https://wiki.ubuntu.com/KernelTeam/ARMDeviceTrees [13:28] [LINK] https://wiki.ubuntu.com/KernelTeam/ARMDeviceTrees [13:28] LINK received: https://wiki.ubuntu.com/KernelTeam/ARMDeviceTrees [13:28] ok tentatively targetted for alpha-3 now [13:29] next: mobile-lucid-arm-suspend-resume-testplan [13:29] i think we need to finish drafting this. i added summary/rational/design to the wiki page already [13:29] plars: want to fill in the Implementation details maybe? [13:30] asac: during the discussion, the implementation details were supposed to be filled in by those who came up with the tests [13:30] its mostly filling in a table where we can track progress on each testcase i think [13:30] right. imo we should fill in the points now... then as one workitem, assign individual testcases to martinbogo etc. [13:31] to fill in details, and implement in checkbox if possible [13:31] ok [13:31] ok i set you as a drafter for now. we can talk about this after the meeting [13:31] sounds good [13:32] lets also decide on the target milestone then. [13:32] next one: mobile-lucid-arm-une [13:32] StevenK: ok to merge this into the application-choices? [13:33] I took stevenk's suggestion to do so....so I hope it is :) [13:33] mobile-lucid-arm-application-choices [13:33] * asac tries to do that now [13:34] ok that is a bit harder ... will do after meeting [13:34] next is mobile-lucid-arm-debian-cd-cleanup [13:35] i assume that is blocked by the uboot for freescale [13:35] somewhat [13:35] yep [13:35] so cannot happen by alpha-2 [13:35] -> alpha-3 [13:35] it can [13:35] it cant happen before [13:35] ok targetted for alpha-3 [13:36] the proof of concept i have is pretty fast to implement once i cleaned up the code both should be possible to happen hand in hand for the same milestone [13:36] ogra: right. alpha-3 doesnt mean that everything has to happen _after_ alpha-2 ;) ... we can do as much as possible before [13:36] (depending on michael indeed, my side shouldnt block here though) [13:36] ok [13:37] next is mobile-lucid-arm-ext-images [13:37] first ... is that really "Medium" priority? [13:37] rather than low? [13:37] * ogra guesse that waits until after NCommanders holidays [13:37] what win do we get from that? [13:37] nothing really [13:37] complication of the build process mainly :) [13:38] ok ... so priority Low i guess. feels like a beautification excersize to me [13:38] and hardlink support in the images (which we dont need) [13:38] i wouldnt even call it beautification :) [13:38] so how much ease would we gain from having ext2? [13:38] hmm [13:38] it was triggered by the fact that the vfat images had a bug [13:38] and cant use symlinks [13:39] right. but that is fixed afaict (the bug) [13:39] both issues are solved [13:39] but would symlinks be something we want? [13:39] switching the image build scripts to make ext2 iomages will definately add a lot complexity [13:39] we dont need symlinks [13:39] ok lets put it to Low [13:39] and maybe consider to not implement this [13:40] it only has a single action item anyway, no ? [13:40] * ogra remembers persia's going over the TODOs and busting one by one in the session [13:40] I'm in favor of dropping if we gain nothing [13:40] with proper and valid arguments :) [13:41] davidm: right. but lets not just kill it while ncommander is gone. i noted it in the whiteboard to consider dropping it [13:41] i would leave the banchmark thing in [13:41] it will at least gain us some info we might be able to use later [13:41] next is mobile-lucid-efficient-install-testing [13:42] all other TODOs depend on that one [13:42] plars: what milestone would you like to target this for? [13:42] when do we expect to have images building? [13:42] plars: feels like its something that is partly on QA team side [13:42] it is [13:42] plars: asap [13:42] they need to create virtual milestones to track this [13:42] plars: ok. have you discussed this in their meeting? [13:42] need someone with access to the iso tracker admin functions to do that [13:43] like: getting feedback if they are supportive etc. [13:43] asac: no, but discussed with ara at UDS, I didn't get the impression that it would be that big of a deal [13:43] ok. lets target it for alpha-2 then too for now... but with option to push the full implementation [13:43] I don't think there's a huge rush with it, due to the nature of the testing being done [13:44] that works for me [13:44] right. i see this more as a gradually process. first get it setup etc. in the end make it become standard procedure for the QA team [13:44] etc. [13:44] the focus is on mobile images for the moment [13:44] but they may be interested in picking it up for others as well [13:45] in reality, doing it *anywhere* has wide reaching benefits, since often times the install bugs are pervasive across all arches [13:45] ok. so for mobile images we can probably make this happen as soon as we get the iso tracker suppor then [13:45] *nod* [13:46] damn, sorry, had to go down the school to pick up a kids, accident but she's OK though. [13:46] * JamieBennett reads backchat [13:46] we have iso tracker support ... [13:46] it just has a few bugs, but we use the tracker since karmic [13:46] JamieBennett: we almost didnt notice ;) ... read backlog what we did to your specs ;) [13:46] next is mobile-lucid-une-casper-speedup [13:46] for which you just showed up in time :) [13:46] :D [13:46] JamieBennett: according to work items most is planned to be done by alpha-2 (with a good bunch for alpha-1) [13:47] is that still accurate? [13:47] the alpha-1 work itesm at least feel a bit at risk [13:47] (to me) [13:47] Yep, going to start on that when I finish packaging up netbook-launcher-efl today-ish [13:47] and it assumes we make A1 [13:47] wrt images [13:47] ogra: indeed [13:48] I can profile karmic though with timestamps in the casper.log file [13:48] thats a good start [13:48] ok . targetted the investigation part for alpha-2 ... commented that the actual speedup fixes obviously can take till final ;) [13:48] give us a good idea of where to start looking [13:48] right, lucid wont change so much here so the karmic numbers should be helpful enough [13:48] next mobile-lucid-arm-application-choices: i think that most stuff is well targetted for alpha-2 as well [13:49] modulo thumb2 improvements [13:49] i will fork out two more specs: a -webservices-mail-integration ... and -webservers-gdoc-integration [13:49] as those are bigger working blocks [13:49] there was a couple of questions deferred at UDS related to this... [13:50] right [13:50] music player [13:50] mail [13:50] openoffice [13:50] those three need work/exploration during the cycle [13:50] so lets move those out to separate specs imo. [13:50] Okay [13:51] dyfet: can you do a quick write up of the music player spec? e.g. what was discussed, what requirements found etc.? [13:51] You mean here or after? [13:51] anyway. back on topic. i think for the rest its safe to have it for alpha-2 [13:51] dyfet: after ... but we should get most done by today ;) [13:52] I will attach it to the current wiki spec page as a separate notes item... [13:52] dyfet: lets sync on this after meeting [13:52] i noted in whiteboard that we lok into splitting specs up [13:52] ok [13:52] but targetted the generic choices one for alpha-2 [13:53] ogra: mobile-lucid-arm-rootstock-gui ... [13:53] target for FF [13:53] same for the multiarch one [13:53] thats for alpha-3 (just so we dont squeeze everything i for alpha-2) [13:53] agree [13:53] unfortunately we have no FF milestone ... so alpha-3 is the best we can have there [13:53] its not on the CD and will be developed in archive [13:53] right [13:53] well, make it A3 [13:54] done [13:54] asac: 2D launcher is waiting on MIR's being promoted and me packaging up netbook-launcher-efl and uploading to REVU (do that today). After that we need add it to the ARM seed and figure out how we are going to determine if 3D or 2D is needed. [13:54] thanks :) [13:54] mobile-lucid-arm-softboot-loader -> i wondered whether this is really Medium priority [13:54] for me it feels unlikely that its going to get fixed in lucid timeframe [13:54] it depends on the kernels [13:54] so while we should work hard to make it happen after lucid+1 [13:55] we probably wont get to do it this cycle [13:55] it will be implemented quickly once we have working kexec support [13:55] we have several proof of concept implementations ... they are all blocked on kexec [13:55] ogra: right. i think we need at least work items for kexec then. [13:55] current spec just says "blocked" [13:56] not what can or will be done to unblock that [13:56] [ACTION]: NCommander to add work items on how to unblock softbootloader to spec [13:56] ACTION received: : NCommander to add work items on how to unblock softbootloader to spec [13:56] we cant do much but wait for kernel team [13:56] ogra: well. we can at least file bugs, bug kernel team, escalate etc. [13:56] or hope for upstreams (vendors) to have it fixed in their kernels [13:57] i am not sure if that has happened [13:57] i think there are bugs since jaunty [13:57] ogra, just file a bug so we can follow [13:57] ok targetting for alpha-3 so it comes back to our plate [13:57] right [13:57] in any case it needs vendor support anyway ... [13:57] mobile-lucid-lpia-future -> isnt that informational? [13:57] and that sounds rather like lucid+1 [13:58] ogra: thats what i thought. for me it feels really unlikely [13:58] that we will get that implemented for lucid [13:58] well, it would be good to have our side ready asap [13:59] right. thats why we have an action now to ensure that we work on unblocking it at least [13:59] ok14:57 < asac> mobile-lucid-lpia-future -> isnt that informational? [13:59] vendor support here means the vendors need to ship the HW with the softbootloader bits [13:59] StevenK: ^^ [13:59] and obviously the HW we'll work with in lucid will be already shipping [13:59] ok marked lpia spec as informational for now [14:00] mobile-lucid-lxde-goals -> alpha-3 ... dyfet? [14:00] asac: Hm. Yes, you're right [14:00] isnt it implemented too ? [14:00] It is really an informational spec [14:00] There are 3 separate community maintained specs [14:00] StevenK: ok. done now. feel free to add more content about what was decided when you have time ;) [14:00] dyfet: ok. [14:01] ok i think we have to hurry abit ;) [14:01] asac: Yeah, I think that one can wait [14:01] specs done for this meeting [14:01] [TOPIC] ARM Image Status [14:01] New Topic: ARM Image Status [14:02] ogra: lucid images broken atm? [14:03] asac: They are [14:03] any update? [14:03] asac: imx51 fails due to SIGILL, and dove due to what looks to be brokenness [14:04] hmpf ... [14:04] right [14:04] bad thing is is that the seeds are broken too [14:04] so debugging is currently impossible [14:04] Well, that certainly explains why dove is broken. :P [14:04] how are they broken? [14:04] and i cant reporduce it locally at all [14:04] asac, MIRs missing ... desktop team is working on it [14:05] but it will take its time, which delays us [14:05] hmm [14:05] is there any way for us to workaround broken seeds to get initial images? [14:05] no [14:05] the seed will be fixed today by the looks of it [14:06] i know pitti and cjwatson discussed promotion of the missing stuff already [14:06] as soon as thats ok we can go on debugging the SIGILL [14:06] i'm in contact with lamont on that since today [14:06] ogra_: do you know where the SIGILL was? [14:07] the prob here is that the buildd runs UNR jaunty [14:07] mksquashfs [14:07] what StevenK says [14:07] though it might be an inconsistency between kernel and userspace [14:07] OK [14:07] ok safe to assume that desktop team will fix the seeds or do we need an action to ensure things get fixed etc? [14:07] as i said, jaunty pegatron UNR kernel [14:07] no, we dont need any action for that [14:08] ok. [14:08] anything else on arm image status? [14:08] [TOPIC] ARM Kernel status [14:08] New Topic: ARM Kernel status [14:08] not yet [14:08] cooloney: ericm: your turn :) [14:08] A1 will still be redboot based for imx51 obviously :) [14:09] asac: thanks, for lucid imx51 kernel [14:09] i am waiting for the fsl drop [14:09] asac, same here for dove [14:09] ok. any timeline for that? [14:09] as soon as i get it, i will setup a seperate tree for that [14:09] i think i will get fsl drop on Dec 4th [14:10] ericm: when will mrvl drop the kernel? [14:11] asac, not yet known [14:11] ok. but we can continue with what had for karmic, right? [14:11] asac, right [14:11] what is the story about not getting thumb kernel ? [14:11] We need to ask Marvell on the next call when we can expect a drop [14:12] davidm, better if I can be invited [14:12] asac, thumb2 needs .32 [14:12] asac, which means we need to backport to .31 as vendor provides only .32 [14:12] .31 sorry [14:12] davidm: could you please forward the meeting minutes of the meeting with fsl [14:13] ericm: are you on marvell call? [14:13] asac, not yet [14:13] davidm: sorry i can't join the meeting, since it's 3am-4am here [14:13] ericm, as i understood MVL will be on .32 [14:13] ericm, only FSL will stay on .31 [14:13] Thumb-2 kernel is nice to have, but if we don't get it for imx51 it's not the end of the world. [14:13]