=== pgraner-afk is now known as pgraner [07:12] is there a asia RMB tonight? persia ? [07:12] * persia checks the wiki for those who don't like URLs [07:14] lifeless: I think "no", as the wiki page claims the next meeting is on the 11th. I suspect the next meeting is really on the 25th. [07:14] persia: thanks! === plars is now known as plars-away === doko__ is now known as doko === doko is now known as doko_ === doko_ is now known as doko [11:51] pleia2, Technoviking, popey, nixternal: 9m? [12:01] hum, I guess I'll wait with my 2 agenda items: https://wiki.ubuntu.com/CommunityCouncilAgenda :) [12:02] :) [12:02] At least the second one really ought be discussed in this timeslot, as interested folks are more likely to be around. [12:02] given that it's just boring administrative stuff, I could also take it to email [12:03] I guess it's just a matter of filing an RT ticket [12:03] Is it just adjustment of the subscription lists to match the recent selection process? [12:03] yes [12:04] Oh, then yeah, no point to discussion ;) [12:04] amachu unfortunately didn't find the time [12:04] * persia thought it was something more complicated, as it was on the agenda [12:04] who will send the RT ticket? [12:04] heh. I can do the second one, but not the first, if that helps. Might be easier to put both in one though. [12:04] the other discussion is separate [12:05] persia: thanks a bunch for taking on the rmb asia update! [12:05] Which other discussion is separate? [12:05] I suggested on team-council-members@lists.u.c that we move the list to LP to make updating a bit easier [12:05] I'll prod the discussion again [12:06] Yeah, that's probably best. That does need discussion (branding, etc.) [12:06] right-o [12:06] Is there anything more that needs to be discussed? [12:06] I think you need quorum to have a meeting, and it's not present, so no point formally ending the meeting :) [12:08] well, there's people who were interested in discussing these things and we got some stuff sorted out already :) [12:08] so I asked if there was anything more [12:09] Not from me. [12:09] ok cool [12:09] popey: all set? [12:10] nothing here [12:10] alright, thanks everybody :) [12:10] short n sweet [12:11] I am [12:11] popey: you're sweet. I'm not so sure about short. [12:12] awww [12:12] *hugs* [12:12] * Pendulum hugs popey back [12:14] hello folks, sorry for being late [12:21] np, i think dholbach is taking it to the ml sabdfl [12:21] okdokey [12:21] happy to be home? [12:21] oh yes! [12:22] kids nearly exploded :) === thekorn_ is now known as thekorn === txwikinger2 is now known as txwikinger [14:00] #startmeeting [14:00] Meeting started at 08:00. The chair is NCommander. [14:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [14:00] rool call first ? [14:00] G'day NCommander [14:00] *roll [14:01] o/ [14:01] who's here? [14:02] GrueMaster: you here? [14:02] yep [14:02] dyfet, you about? [14:02] persia, ? [14:03] no dyfet or persia :-/ [14:03] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100518 [14:03] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100518 [14:03] (i think cooloney also attends for kernel parts still) [14:04] There are no outstanding action items from last week [14:04] (there were all checked and completed) [14:04] the work item link is wrongi think [14:04] should be rather http://people.canonical.com/~pitti/workitems/canonical-mobile-ubuntu-10.10.html [14:04] (not that it matters since there isnt anything on it anyway atm) [14:05] I think we should use QA Status standing item to talk about SRU targets or something until first milestone for maverick is out [14:05] GrueMaster: ^^? [14:05] what do you think? [14:06] [topic] Kernel Status (cooloney) [14:06] New Topic: Kernel Status (cooloney) [14:06] oh, right, i have an action item to add for myself for next meeting [14:06] Well, since I don't have a current image, I have nothing to report on image status. [14:06] oh, actually, nothing new from my side about fsl-imx51 [14:06] kernel [14:06] i talked to slangasek at UDS, we're allowed to SRU bug #568736, NCommander please add an action item for me that i take care [14:06] Launchpad bug 568736 in netbook-meta "Having Evolution installed along with Desktop-Email is pointlessly redundant" [High,Triaged] https://launchpad.net/bugs/568736 [14:07] * NCommander coughs [14:07] we'll need it for our PPA build [14:07] Stay on topic people :-) [14:07] cooloney, i think OMAP is the kernel topic for now :) [14:07] [action] ogra to SRU bug #568736 [14:07] ACTION received: ogra to SRU bug #568736 [14:07] ogra: ok, got it [14:07] thanks [14:07] just discussed with amitk [14:08] so we are going to use .33 based omap4 kernel code for 10.07 [14:09] right [14:09] and for 10.10, we will have one more flavor in our kernel master branch named omapmainline [14:09] fyi 2.6.34 is out, [14:09] which will contains upstream omap3/omap4 [14:09] GrueMaster: since 10.07 is critical, and we will try to use the lucid ti-omap branch code base [14:09] so .33 is much easier [14:09] not only that [14:09] Ok. [14:10] 10.07 is lucid [14:10] and ti's git tree is also based on .33 [14:10] yeah [14:10] 10.07 is lucid [14:10] cooloney: will we use -omap (for 3) and -omap4 as subarch in kernel package names? [14:10] or also rename to -omap3? [14:10] u-boot uses -omap3 currently btw [14:10] asac: actually, i plan to use -omap4 [14:11] cooloney, any keep -omap [14:11] ? [14:11] Its a pain to rename for 10.07 if we do omap3 there, but we should rename the image for maverick [14:11] right. my question was if you are going for -omap3 or still to -omap for 3 (for maverick that is) [14:11] NCommander, 10.07 is out of discussion [14:11] but -omap or -omap4 is not a big problem for me [14:11] asac, i think the masterplan is to have one -omap kernel in the end (maverick+1) [14:12] asac: yeah, [14:12] so the version based fully on mainline should probably stay -omep [14:12] heh [14:12] -omap [14:12] at end, the omap kernel will be in mainline supporting omap3 and omap4 [14:12] ok that would be a good line [14:12] it will be just a flavour [14:12] not a branch [14:12] fine with me [14:13] but before that, we will have a topic branch named omap4patchdump for sync up with ti's patch drop [14:13] what about uboot? do we need to rename that using the same rule? [14:13] for u-boot you will have -omap3 and -omap4 packages [14:13] no [14:13] or will it always be -omap3 vs. -omap4 vs. -omap5? [14:13] etc [14:13] because they are completely different versioned sources [14:13] kk [14:13] so, ogra, for 10.07, is -omap4 for PPA better or just -omap [14:13] *if* we can have one u-boot source i'll consider calling it -omap [14:13] asac, OMAP 3 is planned for 10.10 if at all possible [14:14] yep. [14:14] cooloney, i think -omap4 might be better wrt upgrades to maverick [14:14] ogra: allowed to SRU> I think I suggested getting a second opinion from pitti or cjwatson, first? [14:14] since 10.07 will be installed from scratch we save one package transition [14:14] I don't want to drop the community, the Gumstix and Beagle boards are very nice and OMAP 3 [14:14] ogra: ok, got it. [14:14] davidm: ++ [14:14] slangasek, yes, but i'm good at bribing :) [14:15] The 512M Gumstix board is NICE [14:15] currently, i git clone the branch from ti's git tree [14:15] and rebased to our ti-omap branch [14:15] now fixed the kernel config [14:15] right, so name the resulting binary -omap4 [14:15] for future consistency [14:15] during the building, met some compiling issues which should be ti omap4 code's problem [14:16] talk to ndec about that please (and put me on CC) [14:16] we should probably invite him to this meeting [14:16] NCommander, can you take an action for that ? [14:16] so now, i am closed to build a omap4 kernel package [14:17] [action] NCommander to invite ndec to meeting [14:17] ACTION received: NCommander to invite ndec to meeting [14:17] makes sense to have him around if he has time [14:17] cooloney, cool ! [14:17] as soon as you have something to test, NCommander and i have the HW to test it ... [14:18] cooloney, what target SoCs did you enable yet ? [14:18] ogra: is the kernel and header .deb enough for your testing? [14:18] no need for the header for now [14:18] cooloney: yes [14:18] i wont build modules [14:18] ogra: i imported the omap4 defconfig [14:18] hmm [14:18] i wonder if there are differences between blaze and panda [14:18] perferably we want to have both supported [14:19] mpoirier, !! [14:19] welcome ! [14:19] good morning all [14:19] hello [14:19] welcome [14:19] omap_4430sdp_defconfig [14:19] ogra: ^^ [14:19] cooloney, sounds pretty generic [14:19] heh [14:19] welcome mpoirier [14:20] cooloney, for the omap3 kernel in maverick we seem to lack some patches btw [14:20] ogra: yeah, DSS patches? [14:20] cooloney, i tried the lucid kernel and cant get the display to work on the touchbook [14:20] right [14:20] there is a bug for that [14:20] amitk added them [14:20] between lucid and today ? [14:21] oh, sorry, not that [14:21] right [14:21] ok, after i build the package i will take a look [14:21] there might also be patches for zoom2 that we are missing [14:21] for the omap config, [14:21] (also omap3) [14:21] (and also display related) [14:21] ogra: do you have the working kernel config for your hardware? [14:22] cooloney, nope, for the zoom i know XorA has it, we can ask him in #ubuntu-arm after the meeting [14:22] for the touchbook i have to dig it up, but their current kernel is something like 2.6.29 [14:23] ogra: good. so for 10.07, which one is our target hardware? [14:23] we have general touchbook and zoom2 support in the lucid kernel [14:23] both boot fine [14:23] its just the display [14:23] for 10.07 its panda and blaze [14:23] both omap4 [14:24] so, we don't have the kernel configs i guess [14:24] 10.10 omap3: beagle, zoom, gumstix, touchbook .... 10.07 omap4: blaze, panda [14:24] anything else or can I moveon? [14:24] cooloney, we have them enabled already [14:24] cooloney, (omap3 that is) [14:25] ogra: understand [14:25] cooloney, for omap3 only DSS2 patches seem to be missing [14:25] NCommander: i am done, nothing more now [14:25] and probably sound [14:25] cooloney, for omap4 we need to get them from TI [14:25] QA Status (GrueMaster) [14:25] if there are any specific items at least [14:25] [topic] QA Status (GrueMaster) [14:25] New Topic: QA Status (GrueMaster) [14:26] I thought we were skipping this? [14:26] why should we ? :) [14:26] ogra: ok, i see [14:26] NCommander: sorry was late getting back [14:26] Because there is nothing to report at this time. [14:27] GrueMaster, so any masterplan for omap testing ? [14:27] Give me boards, testing will happen. [14:27] i really think we should keep SRU stuff on topic for QA [14:27] note that the images will be different [14:27] That's the current plan. [14:27] so nothing SRU worthy ? fine. [14:27] what is your testing plan if I may ask? [14:27] * zyga looks from ubuntu-on-arm qa perspective [14:28] right, i'd like to hear about that too ... but GrueMaster is right, no testing without HW ... [14:28] msg davidm do we *really* want ubuntu-on-arm mixing with mobile right now? [14:28] argh [14:28] fuck me [14:28] I don't know how to define "SRU worthy" wrt the bugs in Lucid. There are a lot of bugs that need fixing, but I don't know how they affect contract status, etc. [14:28] GrueMaster, so you should get a gumstix and we need to get you a beagle XM at least for the omap3 testing [14:28] NCommander, I'm not sure I understand your question [14:29] ogra: That would help, yes. [14:29] GrueMaster, for omap4 we need to wait for the pandas [14:29] I am going to look into the gumstix later today. [14:30] zyga, do you have any suggestions for testing ? [14:30] As to SRU issues, My main issues are kernel on dove & babbage related. [14:31] whats open there ? [14:32] I'll have to dig up a list, but off the top of my head, bug 559065 and bug 509006. [14:32] Launchpad bug 559065 in linux-fsl-imx51 "ifconfig eth0 down will cause system hang after fec.c driver update" [High,In progress] https://launchpad.net/bugs/559065 [14:32] Launchpad bug 509006 in linux-mvl-dove "[dove] hibernation failed to resume" [High,Confirmed] https://launchpad.net/bugs/509006 [14:32] ah, good [14:33] GrueMaster, given that we wont build installer images this time, your testing will likely become a bit different [14:33] Had I known we were going to look at SRU bugs, I would have compiled a more detailed list. [14:33] if you work out test plans, try to take that into account [14:33] Yes, I understand that. [14:33] you will dd a fully installed system to SD with the new images that are coming [14:34] though oem-config might need special attention here [14:34] So, I have a new server that is currently actively mirroring ports. I also am mirroring cdimage.ubuntu.com for daily image builds. [14:34] great [14:34] nifty [14:34] That will help immensly. [14:34] our images will likely also be a lot bigger [14:34] sorry I had a call [14:35] so that should help you a lot [14:35] ogra, not really, I'd like to see what you do currently and how it fits into our plans, perhaps there is some common effort or piece of technology [14:35] As to actual image testing, daily (as long as there is a new image to test) boot testing, then into deep testing with installed apps & some app testing from main. [14:35] zyga, well, see above, i'm not sure how comparable our images will be to yours [14:36] GrueMaster, oem-config testing too [14:36] Give me a honey-do list, and I'll get a round to-it. [14:36] the image will be preinstalled, extend itself to the full SD card size on first boot and fire up oem-config to set upü the user etc [14:36] ogra, so all testing you do is manual, correct? (unless I missed something) [14:37] so the special code that resizes needs special attention as well as the setup [14:37] zyga, yes, its mainly for milestone tests [14:37] What is the plan for maximum image size ? [14:37] * zyga has to go away now, darn [14:37] since for daily the archive is unreliable anyway [14:37] GrueMaster: probably 1GiB ish [14:37] GrueMaster, we dont have one ... [14:37] I'll read the backlog when I get back from lunch [14:37] compressed [14:37] 1G would be nice to have [14:38] 1G is easy. Leaves room for language support in the image. [14:38] GrueMaster: not quite, there is no squashfs [14:38] GrueMaster, the plan is to compress out all spare space and then to extend the system partition to max size of the SD on first boot [14:38] we dont know yet how well it will be compressed [14:39] there wont be language support beyond english [14:39] that will be installed by oem-config in case a network connection exists [14:39] if not it has to stay english [14:39] No squashfs? I would recommend it as it makes for easier recovery methods. [14:39] no [14:40] we dont have an installer [14:40] no squashfs [14:40] GrueMaster: this is a completely new type of image. [14:40] its and "oem" image :) [14:40] Not really. This is similar to a Moblin 1.0 image. [14:40] what you dd to the SD card is your install [14:40] right [14:40] And Moblin 1.0 used squashfs. [14:40] its in some areas similar to a moblin image [14:41] you cant use squashfs in a sane way [14:41] I'm just suggesting that we can still use squashfs. [14:41] for installed systems [14:41] folks [14:41] No? [14:41] no [14:41] lets take this offline and bring it back later [14:41] right [14:41] lets move on [14:41] [topic] ARM Porting/FTBFS status (NCommander, dyfet) [14:41] New Topic: ARM Porting/FTBFS status (NCommander, dyfet) [14:42] Nothing to report, archive still is in too much churn to really see whats broken [14:42] * ogra sees libnih, apr, eglibc, kde4libs [14:42] the first three definately need some research [14:42] well, libnih and eglibc [14:42] ogra: crap, those must be new from last night :-/ [14:42] they are there since about two weeks [14:42] eglibc failed with the first upload [14:42] * NCommander sighs and thinks he's gone blind [14:43] libnih failed short before uds [14:43] is doko sitll maintaining the armel toolchain? [14:43] i would hope so [14:43] asac, ?? °° [14:43] ^^ [14:43] do you know ? [14:43] yes, for now he is our contact [14:43] ok [14:44] asac, do you know if anyone from your lside will care for things like eglibc ? [14:44] given that its quite essential to have it build [14:44] or do we need to take action here [14:45] same as for toolchain. things might change as we move on, but atm its doko [14:45] ok [14:45] the eglibc build failure can be ignored for now [14:45] ok [14:45] that leaves libnih [14:45] NCommander, dyfet, can one of you contact Keybuk ? [14:46] iirc we had a similar timeout issue before with it [14:46] (its hitting the 150 minutes barrier) [14:46] not sure why though [14:46] [action] NCommander to poke Keybuk on libnih [14:46] ACTION received: NCommander to poke Keybuk on libnih [14:47] anything else to bring up? [14:47] not here [14:47] [topic] ARM Image Status (ogra, NCommander) [14:47] New Topic: ARM Image Status (ogra, NCommander) [14:47] ogra: I have livecd-rootfs voodoo for you [14:47] * ogra hangs his head in shame for not having the spec ready yet [14:48] ogra: which spec? [14:48] NCommander, i saw, i need to go over it a bit deeper ... i'm not really happy with your getopts stuff [14:48] NCommander, for the image [14:48] ogra: lamont thought it was fine, but feel free to abuse it :-) [14:48] if lamont says its fine i'm fine too :) [14:49] ogra: BuildLiveCD is a manual merge anyway on the buildds [14:49] i'm not such a big fan of getopts in shell scripts where you can solve it with a simple case [14:49] ogra: the simple code was causing my eyes to bleed [14:49] its what we use everywhere [14:49] livecd.sh uses getopts [14:49] since case is fast and doesnt require external deps [14:50] er [14:50] getopts is a bash builtin [14:50] yes, thats historically from infinity [14:50] nope not that one [14:50] mcasadevall@daybreak:/home/buildd/src/chroot-scripts$ which getopts [14:50] mcasadevall@daybreak:/home/buildd/src/chroot-scripts$ getopts [14:50] getopts: usage: getopts optstring name [arg] [14:50] Its not a built-in? [14:50] getopt is builtin [14:51] and getopts is a standlone prog iirc [14:51] ogra: you've got it backwards [14:51] getopt is standalone, getopts is built in [14:51] (do which getopt) [14:51] hmm, k [14:51] anyway, if lamont is happy i'm happy too [14:51] woo, we're all happy! [14:52] i'll write up the spec before next meeting [14:52] so we have work items etc [14:52] cool [14:52] anything else on this topic? [14:52] btw, you skipped the work item review [14:52] ogra: bit hard to do it if the burndown charts are broken [14:52] we have at least three specs and i know persia was planning on more [14:53] they arent broken [14:53] the main page is empty [14:53] we dont have any specs submitted yet [14:53] Oh [14:53] davidm needs to approve etc etc [14:53] [topic] Work Item Review [14:53] New Topic: Work Item Review === Ubot-Tn is now known as MaWaLe [14:53] but indeed we need to have them written and workitems added etc first [14:53] so i have three to add here [14:54] one is the rootfs building without root permissions [14:54] one is upanel [14:54] and one is the new image [14:54] does anyone else have any specs that will be on the tracker ? [14:54] * pitti waves [14:54] as i said i know persia had some planned [14:55] arm softbootloader [14:55] heya piit [14:55] but i dont know which [14:55] improved arm subnarch [14:55] er, pitti [14:55] NCommander, does that make any sense ? if we only support one arch ? [14:55] while it was done under the arm track, I am not sure where the ofono spec will be under... [14:55] (softbootloader i mean) [14:55] dyfet, arm i guess [14:55] dyfet, talk to asac about it [14:56] ogra: ok, let's assume that for now then...and I will discuss with asac separately [14:56] NCommander, also did cjwatson have a look at your plans to change the installer for subarch ? [14:57] ogra: not yet, will do this week [14:57] great [14:57] so lets make sure we have them given to davidm by next meeting for approval [14:58] can you make an action for all of us to have all specs ready for the tracker by next week ? [14:58] [action] Mobile team to have spec completed by next week [14:58] ACTION received: Mobile team to have spec completed by next week [14:58] done [14:58] preferct [14:58] Ok, we're short on time :-/ [14:58] or so [14:58] right, but we're done, no ? [14:58] [topic] AOB [14:59] New Topic: AOB [14:59] I wanted to discuss changing the meeting time [14:59]