=== smoser` is now known as smoser === gpc is now known as IdleOne === steveire_ is now known as steveire === kenvandine_ is now known as kenvandine === Quintasan_ is now known as Quintasan === transitlogger is now known as apachelogger === apachelogger is now known as randalogger [15:54] fnop [15:57] * ppisati waves [15:59] * davidm_ waves back at ppisati [15:59] #startmeeting [15:59] Meeting started at 09:59. The chair is NCommander. [15:59] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:00] * NCommander kicks the wiki [16:00] http://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110602 [16:00] LINK received: http://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110602 [16:00] * davidm_ waves at NCommander [16:00] [topic] Action Item Review [16:00] New Topic: Action Item Review [16:00] [topic] ogra to trim down desktop seed on ARM [16:00] New Topic: ogra to trim down desktop seed on ARM [16:00] not yet ... A2 [16:01] c/o'ing [16:01] * davidm_ arm is tired of waving [16:01] [topic] ogra to follow up with Linaro on binutils segfault [16:01] New Topic: ogra to follow up with Linaro on binutils segfault [16:01] hmm [16:01] * NCommander waves back at davidm_ [16:01] * ogra_ cant remember what exactly that was [16:01] off hand, I think you had to deal with the bug with bintuils segfaulting [16:01] */captian obvious* [16:01] lol [16:01] that much i would have guessed :) [16:02] anyway, havent done that [16:02] c/o [16:02] k [16:02] [topic] Standing Items [16:02] New Topic: Standing Items [16:02] [link] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html [16:02] LINK received: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html [16:03] [link] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-1.html [16:03] LINK received: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-1.html [16:03] hrm [16:03] I think we're off the trendline a bit :-P [16:03] yeah, i'll fix that [16:03] just waited until we have all specs in [16:03] is anyone missing anything from the tracker ? [16:04] please tell me now [16:04] ogra_: I'll add sometihng after you fix it [16:04] :-P [16:04] * ogra_ whacks NCommander [16:04] (all the specs have work items, checked that this morning and added a few more) [16:04] looks like GrueMaster has a really boring cycle [16:04] nothig to do really [16:05] * GrueMaster suffers a massive aneurysm looking at the number of tasks overall assigned to him. [16:05] do you really expect to finish 48 WIs ? [16:05] we should see that we get this lower [16:05] They're all relatively small [16:05] and somehow move WIs to other tema members where possible [16:05] i figured I could write one massive work item [16:05] *team [16:05] 'Test Ubuntu Server:' [16:06] or a lot of little small ones which could be distributed [16:06] well, a WI needs to at least take a day [16:06] ogra_: I disagree [16:06] if you have like 10min tasks for WIs the amount indeed rises [16:06] NCommander, thats the definition, i didnt make it up [16:06] they aren't 10m tasks, but I suspect one or two a day could be done reasonably [16:07] and again, GrueMaster can help delgate his work items to interested parties [16:07] ogra_, we may have to adjust our definition as we have to make sure items get tracked for this cycle closely [16:07] * NCommander knows theres people out there with vested interested in PXE, ARM server, etc. [16:07] I'm OK with 1/2 wi if they are tracking things we need to track [16:08] 1/2 day that is [16:08] davidm_, well, but 48 seems like an awful big number [16:08] we never managed to get more than 20-25 done per release [16:08] (per person that is) [16:08] ogra_: our work items are usually something like 're-implement the world' [16:08] (7 days) [16:08] (sorry, couldnt resist :P) [16:09] I also broke GrueMaster's QA spec in two specifically because the -qa- one should be medium priority [16:09] anywayx, move ... [16:09] ogra_, I know but I asked NCommander to make them finer for the ARM server stuff [16:09] things we care about, but we can ship broken [16:09] and GrueMaster will likely have some help [16:10] [topic] Kernel Status (cooloney, rsalveti, ppisati) [16:10] New Topic: Kernel Status (cooloney, rsalveti, ppisati) [16:10] nothing exciting except for a boatload of CVE fixes for every release/flavour (lucid/[fsl-imx51|mvl-dove], maverick/ti-omap4, natty/ti-omap4) [16:10] \o/ [16:10] BTW: All (3) of my A1 WI are done. Just updated the bp. [16:10] CVEs are awesome [16:10] er [16:11] :) [16:11] CVE FIXES are awesome [16:11] actually i'm wonderting when we'll get the TI .39 drop [16:11] ppisati: I think ogra still looking for the virgin sacirfice [16:11] ;-) [16:11] :) [16:12] me ? [16:12] ppisati: Do you have an omap3 (beagle/beagleXM)? bug 791552 is for you. [16:12] Launchpad bug 791552 in linux (Ubuntu) "No USB support on beagle/beagleXM" [Undecided,New] https://launchpad.net/bugs/791552 [16:12] nah, i'm to aged for that virgin stuff [16:12] * NCommander leaves that where it falls. [16:12] GrueMaster: ouch, didn't notice it [16:12] GrueMaster: ok, i'll add to the backlog [16:12] i could need some kernel guy to look at ac100 though :) [16:12] Just filed yesterday. [16:12] * NCommander needs a kernel guy for the mx5 too :-/ [16:13] you have an mx5 ? [16:13] just use a linro kernel [16:13] *linaro [16:13] ogra_: well yeah. it doesn't work. [16:13] there should exiost one [16:13] hence why I need a kernel guy [16:13] ah [16:13] :-P [16:13] well, my kernel isnt in the archive yet, so you go first :P [16:14] ppisati: so all the CVE fixes are in *-security now? [16:14] we're just discussing to switch to .38 first before i upload [16:14] NCommander: nope, but i'm pushing a lot of stuff [16:14] NCommander: next cycle [16:14] ppisati: awesome [16:14] ogra_: .38 for tegra? [16:14] ppisati, yes [16:15] * ppisati hopes to get the ac100 soon :) [16:15] we're currently at .37 [16:15] ppisati, oh, that would be awesome [16:15] we really lack a person who knows kernel development [16:15] ogra_: davidm told me he pushed one to me [16:15] even more awesome ! [16:15] * ogra_ hugs davidm_ [16:16] davidm_: ah, btw, can you keep me on the list for the new TI hw when it comes? thanks [16:17] can I move? [16:17] yep [16:17] [topic] ARM Porting/FTBFS status (NCommander, janimo) [16:17] New Topic: ARM Porting/FTBFS status (NCommander, janimo) [16:17] I will keep the entire team in line for new hardware as it arrives [16:17] davidm_: cool [16:17] no news, I was working on WIs [16:17] * NCommander has nothing to report as I've been dealing with humans [16:17] looks okayish ... [16:17] at least the images built [16:17] I think this is the first time we hit A1 [16:17] nope [16:18] Natty was. [16:18] I am glad to see package maintainers applying arm bits and not leaving it all to us [16:18] we did hit it the last two releases [16:18] oh yay [16:18] GrueMaster, maverick too iirc [16:18] some natty poatches that were dropped get reapplied without our intervention [16:18] Maybe for omap3. [16:18] well, this time its omyp4 only :) [16:18] I think we missed maverick due to an ill-timed openoffice rebuild [16:18] *omap [16:18] but off-topic [16:18] universe is in a sorry mess [16:19] You're going to have all that fixed by EOW, right? [16:19] yes, we need more community involvement [16:19] we should have specs for that for next UDS [16:19] :P [16:20] with more HW availability in the community, we should work out strategies how to get them more involved [16:20] arm-p-free-beer-for-every-bug-fixed [16:20] That will solve the problem. [16:20] hard to deliver though [16:20] To be delivered at UDS R [16:20] :-) [16:21] anyway [16:21] [topic] ARM Image Status (ogra, NCommander) [16:21] New Topic: ARM Image Status (ogra, NCommander) [16:21] ARM Image Status (ogra, NCommander) [16:21] $#!@#! [16:21] omap4 is fine [16:21] I think we kinda already did this one [16:21] omap3 is screwed [16:21] and GrueMaster and NCommander rock !! [16:22] tzhanks guys for making A1 happen without me [16:22] This I know. [16:22] :P [16:22] Thank GrueMaster. [16:22] * NCommander only did paperwork [16:22] ac100 iamge is new and up on http://people.canonical.com/~ogra/tegra/2.6.37 [16:22] I noticed that LibreOffice is in the A1 netbook image. Works good too. [16:22] (and now bugfree) [16:23] thanks to NCommander and Daviey for helping to identify the bugs [16:23] GrueMaster: right, but now when someone opens libreoffice, we'll miss a milestone :-/ [16:23] ogra_: heh [16:23] er [16:23] builds libreoffice [16:23] well, with the panda cluster it should at least get better [16:24] * NCommander salutees GrueMaster for his hard work on that [16:24] ogra_: but more the images skew when libreoffice is uploaded [16:24] I'm (in my 'free' time) working on making LP less brain dead in this respect [16:24] but its slow going [16:24] didnt you have a spec for it ? [16:25] and do you have to do it alone [16:25] ? [16:25] I have a placeholder [16:25] Short of someone evelating this internally, I'm not expecting any help on this [16:26] NCommander, well, infinity should be around soon [16:26] he should be able to do a bit of soyuz stuff [16:26] I'm hoping that since we're over the A1 hump, I might find enough free time to get this implemented and save us a TON of pain [16:26] ogra_: TBH, I'd prefer to implement it myself, its a good unwind project [16:27] NCommander, then shove some of the other WIs over to him [16:27] Will do [16:27] no matter how you do it, it would be really really good to have it fixed this cycle [16:27] I'm working towards loadbalancing the team. A lot of GrueMaster's work items will get moved onto janimo and infinity [16:27] and if we need to make some spare time for you to do it, we should be able to find a way [16:27] * janimo overflows with joy [16:28] lol [16:28] anyway, nothing more for images here [16:28] janimo: that's -65334 tears of happiness :-) [16:28] [topic] QA Status (GrueMaster) [16:28] New Topic: QA Status (GrueMaster) [16:29] Spent most of the day yesterday just trying to file a sensible bug report on the broken omap kernel. [16:29] NCommander, my hapiness is a short apparently [16:29] We need to have apport installed on the headless images. [16:29] long long is preferred [16:30] GrueMaster, tricky since we dont have a seed [16:30] (and i dont really want to maintain one) [16:30] Other than that, I did some basic boot tests on the images for A1, and dabbled a little in some of the apps that are on the netbook image for omap4. [16:30] might have to change for the server images though [16:31] ogra_: er, we could just add apport-cli to livecd-rootfs */hack* [16:31] Well, the issue I had was that usb support was non-existant. It would initialize and recognize the onboard usb hubs, but nothing that was attached from there. [16:31] So no network support. [16:31] NCommander, well, sure [16:31] NCommander, but i assume our server images should have apport by default anyway [16:32] ogra_: one would hope so [16:32] hopefully the migration to live-helper will be done [16:32] We should have some way of adding some minimal stuff anyways. wifi on omap4 is non-existant on headless. [16:32] I 'look' forward to implementing support for live headless images [16:32] ogra_: as much as I hate to say it, I think we need a headless seed [16:33] GrueMaster, yes, the basic wifi apps arent in minimal ... nor is wpa-supplicant [16:33] begin crying now [16:33] NCommander, i disagree [16:33] * ppisati kicks an omap3 kernel compilation... [16:33] i think we need a server seed and images for it [16:33] ogra_: adding packages to livecd-rootfs isn't going to scale :-P [16:33] and leave the headless image as is :) [16:33] ogra_: er, didn't we agree we wanted both? [16:33] right [16:33] I think yo umight be missing the point [16:34] * ogra_ would rather make the headless images unofficial and move forward with server here [16:34] instead of having to mintain extra hacks for headless [16:34] Headless is next to useless without some base level of packages installed. [16:34] although server != minimal which headless was supposed to be [16:34] We're getting offtopic [16:34] True. [16:34] [topic] ABO [16:34] New Topic: ABO [16:34] Now we're on topic [16:35] we [16:35] *er [16:35] heh [16:35] [topic] AOB [16:35] New Topic: AOB [16:36] nothing here [16:36] shoot it down :) [16:36] (unless someone else shouts) [16:36] I'd actually like to propose to returning on reporting individual spec status [16:36] Er, sorry, individual's status [16:37] returning ? [16:37] (my brain is kinda fried) [16:37] We used to do it when we were called the Embedded Team [16:37] did we ever drop it (beyond nobody doing it i mean) [16:37] We used to do NCommander's status, ogra's status [16:37] when were we called the embedded team ? [16:37] Back when we dealt with Moblin. It was the MobileAndEmbedded Team [16:37] (according to the wiki anyway) [16:38] heh [16:38] * ogra_ only knew it as mobile team, but well) [16:38] you mean reporting personal status in the meeting ? [16:38] yeah [16:38] instead of wikipage ? [16:38] I realize there is a time concern [16:38] No, both [16:39] that will eat a *loT* of extra time [16:39] when we did that our meetings were like 1.5h and longer [16:39] I know. [16:39] thats why we dropped it [16:39] hrm [16:39] right [16:39] I forgot that bit [16:39] shutting up now [16:39] so find something else to drop [16:39] to compensate ... [16:39] :) [16:40] One other point [16:40] bah [16:40] Daviey isn't around [16:40] Daviey is around [16:40] I wanted to get some cross-reporting between Ubuntu ARM and Ubuntu Server [16:40] not in this channel [16:40] oh [16:40] bah [16:40] * ogra_ takes away NCommanders blindfold [16:40] I hate autocomplete [16:41] And I'd like to find some volunteers to attend the weekly server team meeting [16:41] and some volunteers from the server team to attend ours regularly [16:41] * GrueMaster hides [16:41] (the meeting is 16:00 UTC on Tuesday) [16:42] Same time as the linaro meeting. [16:42] thats wed. [16:42] or not ? [16:43] No, the sync meeting moved to Tuesday as I found out [16:43] ah, no, mixed it up with the porting jam [16:43] o/ [16:43] that's an unfortunate choice of timezone [16:43] er [16:43] time [16:43] oh hai Daviey [16:43] hello! [16:44] Daviey: we're trying to get some cross-pollination going between teh ARM and server meetings [16:44] NCommander: funny you say that! :) [16:44] NCommander: have you witnessed one of the -server meetings? [16:44] I'd like to add a 'ARM Server' sectoin to our meeting page, with someone present from the Ubuntu Server Team [16:44] Daviey: I haven't had opportunity [16:44] NCommander: I'm wondering if it would be a better fit for someone arm to join a server meeting? [16:45] Or format has sections for each 'interest' area. [16:45] QA, Kernel, Community, Documentation [16:45] as does ours (although ATM, we're quite generalized) [16:45] We would happily add an Arm section :) [16:45] My plan was to add a Server section [16:46] NCommander: ok.. I think the thing that is a challenge.. I'm not quite sure if Oneiric ARM server is a Server project or an ARM project? [16:46] Daviey: its both [16:47] I don't want to hold the meeitng open, so why don't we take this offline, and then drop a notice with the next {Server,ARM} Meeting Reminder email [16:47] NCommander: Okay, just for information... the interested parties in ARM on the server team are myself, zul and hallyn. [16:47] [action] Daviey and NCommander to discuss cross-server/ARM team meeting [16:47] ACTION received: Daviey and NCommander to discuss cross-server/ARM team meeting [16:47] NCommander: sounds good. [16:47] #endmeeting [16:47] Meeting finished at 10:47. === jelmer_ is now known as jelmer === robrt` is now known as robrt`` === robrt`` is now known as robrt` [18:56] #startmeeting [18:56] Meeting started at 12:56. The chair is mdz. [18:56] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:56] [link] https://wiki.ubuntu.com/TechnicalBoardAgenda [18:56] LINK received: https://wiki.ubuntu.com/TechnicalBoardAgenda [18:57] \o [18:59] pitti isn't online, so I assume he isn't going to make it [18:59] sabdfl declined in the calendar [18:59] cjwatson is online, but he's on holiday, so he presumably won't be here [18:59] is 3 quorum? [19:00] * mdz nods [19:00] we've regarded it as such in the past [19:00] yeah, that's my memory too [19:00] [topic] Action review [19:00] New Topic: Action review [19:00] Persia to see if Bryce is willing to serve as LP stakeholder for Ubuntu [19:01] I've asked bryce asynchronously for an update [19:01] [topic] ffmpeg vs. libav [19:01] New Topic: ffmpeg vs. libav [19:01] I guess this was discussed some at the last meeting, which I wasn't present for [19:01] the notes said that we wanted to hear from Reinhard, and he's responded now [19:01] [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html [19:01] LINK received: https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html [19:02] right. given that I've seen both sides of this, I think I'm satisfied to stay where we are: libav [19:02] trying to track ffmpeg would require a dedicated maintainer, and Ubuntu does not seem to have anyone willing to do that currently. [19:02] I only see downsides to switching from libav. [19:03] libav is the status quo, so we would need a justification to switch away from it [19:03] right, and I don't see anything significant to do that currently. [19:04] it's all feeling a little bit cdrecordish to me [19:05] Keybuk, any thoughts? [19:05] bryce: we're looking at https://wiki.ubuntu.com/TechnicalBoardAgenda and have "Persia to see if Bryce is willing to serve as LP stakeholder for Ubuntu". can you speak to this at all? [19:06] sure, I'd be happy to help [19:06] mdz: I don't believe I have the necessary background [19:06] all I saw was flamewar [19:06] kees, yes we spoke a couple UDSes ago, and yes I'd be happy to help [19:06] bryce: ah-ha, perfect. thanks! [19:07] Keybuk: did you have additional questions based on the techboard thread? [19:07] kees: I didn't see anything in the techboard thread that led me to have technical questions [19:07] nothing suggested ffmpeg was technically better, so I don't see any need to dispute the current maintainer decisions [19:08] [19:08] Keybuk: okay, so you're okay with status quo too. [19:08] OK, so this came in as an inquiry from an upstream developer, suggesting that what the Ubuntu maintainer had done was not in the best interest of our users [19:08] I haven't heard of any complaints from our users about it yet [19:08] mdz: it came from the upstream developer of a package we weren't using though, right? [19:08] Keybuk, yes [19:09] I must admit, I wrote that of us "how dare Ubuntu not use *my* software, and use something else" [19:09] if someone wanted to maintain the other fork in Ubuntu as well, and make both available to users, that wouldn't seem unreasonable to me [19:09] and then failed to find any technical argument from the author as to why we should [19:09] mdz: agree [19:09] but if the maintainer chose to follow libav, the TB can't tell them whether they should package something else [19:10] they should be regarded as different software at this point [19:10] one is packaged for Ubuntu, the other is not yet (but would be welcome) [19:10] kees, does that seem like a reasonable position to you? [19:10] mdz: yup. [19:10] OK, I'll follow up on the list [19:10] to me also [19:11] [action] mdz to summarize consensus on libav/ffmpeg to the mailing list [19:11] ACTION received: mdz to summarize consensus on libav/ffmpeg to the mailing list [19:11] they would have colliding binary packages, though [19:11] kees, that could presumably be fixed in packaging [19:11] * kees nods [19:11] [topic] Set series RM to ubuntu-release? [19:11] New Topic: Set series RM to ubuntu-release? [19:11] [link] https://bugs.launchpad.net/ubuntu-community/+bug/174375/comments/21 [19:11] LINK received: https://bugs.launchpad.net/ubuntu-community/+bug/174375/comments/21 [19:11] Ubuntu bug 174375 in Launchpad itself "Distribution drivers permissions may need redesign" [Low,Triaged] [19:11] the bug mentioned there is now fixed [19:12] so in theory we should be able to set the series release manager to ubuntu-release [19:12] let's do it and see what breaks? [19:12] let's tell people that we're doing it, and then do it, and see what breaks :-) [19:12] any volunteers? [19:13] seems like it should be coordinated with skaet at least? [19:13] yse [19:13] yes [19:14] I'm not entirely comfortable volunteering myself for this since these discussions have mostly been involved people doing archive admin work, so perhaps cjwatson? [19:14] s/been //g [19:14] we can push this to the next meeting where cjwatson is here [19:14] it's not urgent [19:14] ok [19:14] [topic] Measuring installation success/failure [19:14] New Topic: Measuring installation success/failure [19:15] [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000857.html [19:15] LINK received: https://lists.ubuntu.com/archives/technical-board/2011-May/000857.html [19:15] [link] https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033194.html [19:15] LINK received: https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033194.html [19:15] aiui, ev is looking for a TB "blessing" for this data gathering. [19:15] I like the general idea of gathering data which will give us an indication of how effective our installer is [19:16] I generally do too. I remain unconvinced that the proposed data gather is substantially useful, though. [19:17] *gathering [19:17] Evan wasn't crystal clear about what he wanted decided [19:17] and several issues have cropped up in the discussion [19:17] Keybuk was concerned about how the collected data would be shared [19:17] kees, I think that's a valid concern, but perhaps not something for the TB to decide [19:18] I think it's Evan's responsibility to make it useful, and our responsibility to set policy for what's permissible [19:18] mdz: that's fair [19:19] kees, and FWIW I would recommend to evan that he consider your advice carefully :-) [19:20] so the policy questions I think are regarding what data is collected, and what we do with it [19:20] right. I don't want to get us into the trap where we approve "meaningless data collection" since it's harmless, and then end up on an unregulated slippery slope of "harmful" data collection just happening without review. [19:20] what is proposed to be collected is a GUID [19:21] right, it's a random number. I have no problem with that. [19:21]