=== Ursinha-dinner is now known as Ursinh === Ursinh is now known as Ursinha === noy_ is now known as noy === apachelogger is now known as fluffymaster === yofel_ is now known as yofel [11:59] mako, Technoviking, popey, pleia2: around? [12:01] o/ [12:01] JeffWaugh May I add Ubuntu's Bleeding Edge to PlanetUbuntu? 11 UTC [12:02] is the only agenda item - I'm happy to follow up on that via email [12:02] hi popey - is there anything else we should talk about? [12:04] not that I can think of [12:05] kubuntu council? [12:05] ah yes, I need to follow up on that thread too [12:05] mako, Technoviking, popey, pleia2: ^ feel yourself poked about this :) [12:05] also I'll talk to mdke about the wiki licensing again [12:06] but that's all I can think is on our agenda [12:06] "agenda" [12:06] indeed [12:06] alright, I'll go and send a few mail, update the team report, etc. [12:06] Adjourned. :) [12:07] wow, that was quick.. [12:07] dont blink! [12:08] great, I can go to lunch now :) [12:08] popey: bon appetit === Ursinha-afk is now known as Ursinha === fluffymaster is now known as apachelogger [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] G'day NCommander [14:00] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100615 [14:00] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100615 [14:00] ogra: GrueMaster dyfet ping [14:00] davidm: morning [14:00] * ogra refuses to take part in a meeting that wasnt announced :P [14:00] * GrueMaster mumbles [14:00] (you forgot the mail again) :) [14:01] * NCommander coughs [14:01] [topic] Action Items from June 8th, 2010 [14:01] New Topic: Action Items from June 8th, 2010 [14:01] [topic] NCommander to discuss build timeout with lamont [14:01] New Topic: NCommander to discuss build timeout with lamont [14:02] I discussed it with him, but before we came to a conclusion, the troublesome package (qt4-x11) magically started building again ... [14:02] so its fixed, though we're not sure why [14:02] well, we still need a proper solution for that [14:02] its not only one package that times out [14:02] ogra: lamont has made it so its easier to update the build timeouts then before, so it can be changed with less pain [14:03] hmm, k [14:03] [topic] NCommander to poke Keybuk on libnih [14:03] New Topic: NCommander to poke Keybuk on libnih [14:03] libnih is no longer FTBFS so I'm dropping this item (I didn't get a chance to talk with him or do any FTBFS work all week) [14:03] [topic] Standing Items [14:03] New Topic: Standing Items [14:03] err [14:03] ogra: ? [14:04] libnih cant build because upstart ftbfs [14:04] be sure it will return [14:04] oh, d'oh. why isn't it on the depwait list then :-/ [14:04] c/o on that item then [14:04] [link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html [14:04] LINK received: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html [14:05] We're making progress [14:05] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-2.html would be more intresting though [14:05] LINK received: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-2.html would be more intresting though [14:05] given thats our next milestone [14:06] if we get 4 todos done in that we'll look good for A2 [14:06] 5 would be even better :) [14:06] indeed [14:07] I refactored and cleane dup the preinstalled d-cd branch last night, so its good for initial merging [14:07] great [14:07] give me something to review later today [14:07] How close are we to having daily images? [14:08] debian-cd merge, cdimage merge of the publisher scripts [14:08] GrueMaster: jasper needs to go in archive, we need an MIR, and I need to finish compressed image support [14:08] and some jasper fixes [14:08] ok [14:08] NCommander, jasper is in the archive since 2 weeks [14:08] ogra: d'oh [14:08] * NCommander dons dunce cap [14:08] but i cant test it without a working kernel [14:08] (which brings us to next topic i guess) [14:08] I thought we had a working OMAP 3 kernel [14:09] Not that I have seen. [14:09] [topic] Kernel Status (cooloney, mpoirier) [14:09] New Topic: Kernel Status (cooloney, mpoirier) [14:09] the .34 omap3 kernels did work [14:09] with the switch to .35 they broke [14:09] i have yet to test. [14:09] should get to it today. [14:09] GrueMaster, where is the bug you wanted to file yesterday ? [14:09] in any case, [14:10] about SD card ? [14:10] no [14:10] 594382 [14:10] bug 594382 [14:10] Launchpad bug 594382 in linux-ti-omap (Ubuntu) "Wake up daisy chain activation failed on omap3" [Undecided,New] https://launchpad.net/bugs/594382 [14:10] haven't looked at it. [14:10] still on SD card. [14:10] Oh, on the sd card. I'll have to look [14:10] I don't have it up atm. [14:11] fine, I'm looking at code at this time and can reproduce on my rig. [14:11] bug 592688 [14:11] Launchpad bug 592688 in linux-ti-omap (Ubuntu Maverick) "Timing issues with certain SD cards on beagleboard" [Undecided,New] https://launchpad.net/bugs/592688 [14:12] yes, that is the one. [14:12] Should I assign those to you? [14:12] * ogra comments on the bug and adds some pointers [14:12] (the daisy chain one) [14:12] mpoirier, you need an OMAP3 board correct? [14:12] I suppose you could. [14:13] Well, I could use a bb C4. [14:13] have C2 atm. [14:14] I'll send a C4 out today [14:14] very well thank you. [14:14] DavidLevin, do we still have spare XMs ? [14:14] err [14:14] davidm, ^^^ [14:14] since i see massive issues there too with the curent omap3 kernel [14:14] ogra, I have 1 unit now [14:14] i think lag has one [14:15] I can ship that if you need it. [14:15] well, lag, amitk and me each have one unit, depends if mpoirier will work on XM issues too [14:15] NCommander, give me an action to ship mpoirier a C4 this week please [14:15] then it would make sense to ship one to him [14:15] [action] davidm to ship mpoirier a beagle C4 [14:15] ACTION received: davidm to ship mpoirier a beagle C4 [14:15] NCommander, also add ship mpoirier a XM too [14:16] [action] davidm to ship mpoirier a XM board [14:16] ACTION received: davidm to ship mpoirier a XM board [14:16] great [14:16] I think I'll cry, every time I get hardware I have to ship it out..... [14:16] heh [14:16] heh [14:17] lag, any news about omap4 ? [14:17] * NCommander gives davidm a Babbage board [14:17] News? [14:17] well, we're waiting for a binary package in teh arm team :) [14:18] I have a working build [14:18] do you know whats the progress there is ? [14:18] But I didn't build it [14:18] I'm afraid cooloney is your man [14:18] yeah, i'm more intrested about something in the archive :) [14:18] Nothing as yet [14:18] AFAIK [14:18] ok [14:19] NCommander, move ? [14:19] [topic] QA Status (GrueMaster) [14:19] New Topic: QA Status (GrueMaster) [14:19] I have been doing a lot of testing and retesting of the image ogra handrolled last week on various sd cards. [14:19] GrueMaster, could we have a list of milestoned bugs on the meeting agenda ? [14:20] that would help a lot with the release meetign preparation and with keeping an easier overview [14:20] I can add them later today. [14:20] only the critical and high ones that are milestoned [14:20] * GrueMaster needs coffee still. [14:20] Ok. [14:20] should only be a few each week [14:20] * NCommander needs that magicial substance as well [14:21] NCommander, move ? [14:22] [topic] ARM Porting/FTBFS status (NCommander, dyfet) [14:22] New Topic: ARM Porting/FTBFS status (NCommander, dyfet) [14:22] * NCommander has nothing to report since he hasn't had time to work on this [14:22] Well, there are some items pending from upstream [14:22] (glib2.0 and gobject introspection) [14:22] I did work on others though as well, and did btrfs-tools [14:23] did you tak to seb128 about glib ? [14:23] Yes [14:23] *talk [14:23] ok [14:23] Thats why I did not submit my patch for it [14:23] anything NCommander or i need to sponsor ? [14:24] I sponsored with rainct :) [14:24] I may have openmpi resolved later today, but I know we need to get kde unstuck [14:24] can you make sure your name shows up in the uploads ? [14:25] else sponsored uploads wont help you with MOTU [14:25] ok [14:25] true :) [14:25] I had to pass on glib2 since there was an upstream fix being merged... [14:26] what about compiz ? [14:26] I can look at that later tonight or tomorrow [14:26] and xscreensave seems to have failed too [14:27] the rest looks like glib or qt fallout [14:27] ok [14:28] [topic] ARM Image Status (ogra, NCommander) [14:28] New Topic: ARM Image Status (ogra, NCommander) [14:28] pretty much covered above already ... [14:28] indeed [14:28] [topic] AOB [14:28] New Topic: AOB [14:28] we need functioning kernels [14:29] * ogra has an AOB topic :) [14:29] davidm, what do we do with the mailing list now that we're being renamed [14:29] and also with #ubuntu-mobile [14:30] Well, with #ubuntu-mobile, I thinkw e can let it die, we use #ubuntu-arm mostly now [14:30] shuld #ubuntu-mobile become a redirect to #ubuntu-arm or do we leave it idling [14:30] NCommander, define "let it die" :) [14:30] let it idle [14:30] just leaving it wont magically make it go away [14:31] ogra, I need to talk with IS about the mailing list [14:31] its a registered ubuntu channel [14:31] ogra, I'd leave #ubuntu-mobile idle I think [14:31] hmm, k [14:31] there is value to it, just not for us right now [14:32] indeed, but someone needs to be the owner (and make sure to be able to OP when spamboats or trolls show up) [14:32] hmm, I did not realize it was a registered channel, is #ubuntu-arm registered? [14:32] i think it is [14:32] has a chanserv [14:32] We should likely make sure [14:32] yeah [14:35] i think persia cared for -arm back when we got it new [14:35] NCommander, action for me to talk to persia about IRC channels [14:35] [action] ogra to talk to persi about IRC channels [14:35] ACTION received: ogra to talk to persi about IRC channels [14:35] Can I close out the meeting? [14:35] yeah [14:35] #endmeeting [14:35] Meeting finished at 08:35. [14:36] NCommander, you might take a tad more time to let folks respond to closing the meeting [14:36] davidm: did you want to say something? (I can open it again) [14:37] I used the going 1 - 3 before closing to allow any last minute things [14:37] NCommander, no not worth opening again [14:37] sorry about it [14:37] makes a new log [14:37] No worries [14:57] \o [14:57] o/ [14:59] \o [15:01] o|_|/ [15:01] hello all [15:01] cjwatson: ping [15:02] hi, was just finishing up on the phone with lool [15:02] and that's everyone [15:02] Keybuk: relaxing then? [15:02] #startmeeting [15:02] Meeting started at 09:02. The chair is cjwatson. [15:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:02] [TOPIC] Action review [15:02] New Topic: Action review [15:02] I don't see anything in the minutes from the last meeting that requires review [15:02] oh, wait [15:02] FTR, I'm in a parallel mumble OEM meeting, so I'm lagging a bit [15:03] The board resolved that the issue of ubuntu-drivers many roles should be a medium-priority bug, and should be fed back to the Launchpad team as part of the usual process [15:03] mdz: did you raise that as resolved? [15:03] cjwatson: I've passed it on to marjo for the next stakeholder meeting [15:03] ok, thanks [15:04] [TOPIC] Review StableReleaseUpdates policy of contacting the Technical Board regarding regressions (mdz) [15:04] New Topic: Review StableReleaseUpdates policy of contacting the Technical Board regarding regressions (mdz) [15:04] mdz: go ahead [15:04] so, we've had a couple of regressions discovered in -proposed recently [15:04] and the wiki page tells people to email the tech board [15:05] this doesn't seem like the most helpful point of contact [15:05] so I would like to suggest that we direct these reports elsewhere [15:05] seems like maybe "If you can't reach anyone else who will take responsibility, then email TB..." [15:05] right, I usually mark them as regression-proposed/verification-failed to prevent it being copied to -updates [15:05] for example to the QA team, or the SRU team, or someone like that [15:05] regressions in -updates are a different story, of course, and we should rather tell more people than fewer [15:05] there's also a rather out-of-date list of individuals in there somewhere [15:06] so, wait [15:06] I think this is actually bad wording on the page [15:06] pitti: yes, I think the page actually only says to email the TB regarding regressions in -updates [15:06] mdz: you're looking at the bit under "Procedure", right? [15:06] but people get confused [15:07] I'll take an action to reword that so that it explicitly applies to -updates [15:07] and I don't think the TB is ideal in that case either [15:07] [ACTION] cjwatson to reword StableReleaseUpdates to indicate that panic button only applies to -updates [15:07] ACTION received: cjwatson to reword StableReleaseUpdates to indicate that panic button only applies to -updates [15:07] (pending other discussion - that much is obviously sane, though) [15:07] agreed [15:08] does anyone else feel that the panic button could be improved as well? [15:08] I share some of that feeling, just thinking [15:08] the point of the panic button is to quickly escalate to people who can be effective [15:08] in doing things like reverting the update if appropriate, getting IS to block it if appropriate, etc. [15:09] I take pitti's point that we want to make sure the message gets through, but I'd rather see a clear escalation path than a scattershot approach [15:09] I think it should be a set of people who have upload privileges (i.e. not in general the QA team - no disrespect intended), in order that if it's appropriate they can revert immediately with minimal fuss [15:09] if we want is quick and accurate action, what we want to see is one person acknowledging and owning the problem and escalating it methodically [15:10] rather than potentially several people acting at once [15:10] we certainly want to end up with a single owner [15:10] IRC is pretty good for this [15:10] but it's valuable not to depend on a single person [15:10] because everyone else can see if someone has already responded [15:10] emailing the TB...not so much [15:10] which set of people is appropriate? I would say either ~ubuntu-archive or ~ubuntu-sru [15:11] I think ~ubuntu-sru [15:11] probably the latter except that it's kind of small. but maybe that's ok [15:11] we can delegate [15:11] do you think it's appropriate for IRC to be the only method? [15:12] ~ubuntu-archive would be appropriate, since all of them can use copy-package, lp-remove-package, etc. [15:12] ~ubuntu-sru has a subset of archive admins [15:12] and telling IS to block updates is easier for Canonical folks with the emergency phone numbers [15:14] cjwatson: IRC seems fine to me; a lot of folks (slangasek, you, mdz, me) use proxies and are online 24/7 [15:14] so should we have an explicit list of people, rather than a complicated set union/intersection? [15:14] and explain the rationale for that list, so that we can keep it up to date reasonably easily [15:15] ideally, a bot could handle this, and look up the team membership in LP [15:15] (which the current list hasn't been - AIUI Cody isn't the Xubuntu lead any more) [15:15] I liked the copy&paste "pitti, cjwatson, slangasek, ...: PANIC" quite a lot [15:15] so we keep it all in one place [15:15] (and Hobbsee hasn't been around much for a while) [15:15] it has few technical dependencies (bots, etc.) [15:15] mdz: we can probably do that, it's analogous to !ops [15:15] and is quick and easy to document and follow [15:15] we could have !sru [15:16] can this regularly sync team membership from LP without the need to look it up on the fly? [15:16] I wouldn't rely on the latter [15:16] seems technically possible :-) [15:16] agreed [15:17] that's all I had to say on the topic [15:17] the main point being dropping the "email technical-board@" step, since I don't think it adds value [15:17] there's nothing on there about creating an incident report either, and perhaps there should be [15:19] cjwatson: since you're on the hook for editing the document anyway, could you remove the email-TB step as well if there are no objections? [15:19] is somebody interested in taking an action to get the bot changes made? [15:19] otherwise it'll devolve to me I guess [15:19] the code appears to be in lp:ubuntu-bots [15:20] ah, I think I can try spending some time on that [15:20] that bit is less important, maybe we could just ask for help? [15:20] it's a bite-sized project someone could step up and do; it doesn't have to be one of us [15:20] I'd rather we get it done and close out the topic [15:20] fair enough [15:20] (hi, joining) [15:21] [ACTION] pitti to (ask for help to) get !sru added to ubuntu-bots [15:21] ACTION received: pitti to (ask for help to) get !sru added to ubuntu-bots [15:21] [ACTION] cjwatson to remove "mail TB" step from SRU docs [15:21] ACTION received: cjwatson to remove "mail TB" step from SRU docs [15:22] move on? [15:22] yep [15:22] doko__: are you here? [15:22] yes === doko__ is now known as doko [15:22] doko: do you have any sheep? [15:23] Keybuk: just a robber for you [15:24] [TOPIC] Selection of the Linaro GCC for other architectures (doko) [15:24] New Topic: Selection of the Linaro GCC for other architectures (doko) [15:24] cjwatson: how should we proceed? https://wiki.ubuntu.com/TechnicalBoardAgenda has the input about the Linaro GCC and the main question [15:24] so doko brought some concerns about this up over the weekend, and was kind enough to write it up for the agenda [15:24] the question for the TB is what we should be doing regarding the default Ubuntu toolchain [15:24] actually, I think this is doko's decision as maintainer, but he'd like advice [15:25] I didn't have the time to prepare anything for the meeting myself, but I wanted to share that I think the concerns are valid one and that it's more important for Linaro that we take a decision one way or the other than deferring too much; we offered support on all architectures, but obivously we have to balance that against time spent on further developments [15:25] I don't have context on this; did I miss something on the mailing list? [15:25] *ones [15:26] does the CodeSourcery GCC offer advantages for non-ARM platforms? [15:26] mdz: afraid not, this came up over the last couple of days and hasn't hit the list [15:26] mdz: we had an UDS session on that, but it came up recently that we had not decided on the final list of architectures and that it was starting to get late [15:26] I think the UDS session called for testing on x86 and arm, and was reserved about usage on other arches [15:27] if the linaro patchset is only applied to the armel build of gcc, it seems like that minimizes the potential "alienation". [15:27] the CS changes include some middle-end changes and changes to backends. the ones we may be interested in are the intel archs and powerpc [15:27] kees: doko and lool have both indicated to me that they're reasonably content with that option, and I'm inclined to agree, although there are of course risks associated with having architectures be different from each other [15:28] there are risks with every option though :-) [15:28] I do not want to touch archs which are not actively supported in the CS GCC [15:28] Yes; the smallest maintenance burden is when the toolchain is the same on all arches obviously; in any case, we can do some tests on intel even if Linaro patches aren't used on intel in Ubuntu [15:28] cjwatson: right, it just seems like that one contains the risk a bit more. doing archive rebuilds is very expensive. [15:29] us using the CS patches for all arch's would help accelerate their upstreaming [15:29] lool: smallest> well, depends on how you look at it, the ability to forward patches upstream to the FSF and have them not be rejected is a maintenance win too [15:29] cjwatson: Linaro also forwards patches upstream though [15:29] and if there's an easy way to get a package built on x86 without the patches, we have a good way to triage toolchain/CS issues [15:29] the non-technical question I see is, how is Ubuntu seen if it uses a toolchain not directly from upstream [15:30] cjwatson: it's our mission to upstream this stuff too, so we could in the end help upstreaming [15:30] my concern about using the CS patches for all architectures is that, if push comes to shove, CS's priorities for Linaro are going to be ARM [15:30] I realise that they and Linaro have offered support otherwise [15:30] but I can't see how it can be top priority if there's a crunch [15:30] doko: i can see it providing an easy excuse for someone to dismiss a bug report from us, but those people will likely find other reasons if we don't give them this one [15:30] cjwatson, possibly -- but they do maintain the x86 side of the toolchain as well, just to be clear [15:30] kiko: not exclusively [15:30] they certainly help to do so [15:30] doko: this was brought up at the UDS session, one thing which we mentionned, albeit not a full answer, is that we should still provide FSF packages in Ubuntu (gcc-snapshot being one) [15:30] cjwatson: not exactly, having an "interest" and providing support is different [15:30] cjwatson, no, I mean that they have x86 customers [15:31] sabdfl: we provide gcc-snapshot though [15:31] so they do maintain it as well [15:31] FAOD I am not questioning either CS's skills or good faith [15:31] it does make things harder for e.g. doko because he has to reproduce an issue with a FSF toolchain first, but he might have to do that anyway? [15:31] lool: right, so it's always possible to test if the CS work is the root cause of an issue [15:31] lool: yes, we'll have a GCC version which is close to the upstream branches [15:31] doko: Do you currently test with a vanilla toolchain before reporting upstream? [15:31] sabdfl: that's time-consuming work in an already time-consuming process, of course [15:32] I wonder if we should take a slightly different approach [15:32] we face this same story on kernel and elsewhere, anywhere we deviate from pristine upstream [15:32] cjwatson: yes, i understand that [15:32] Yes, albeit the difference is substantial [15:32] package both the FSF gcc and the CS branch as separate packages [15:32] then, if there's a problem with one, a package can build-depend on and compile with the other [15:32] how expensive are rebuilds? [15:32] assuming that ABIs haven't skewed too much [15:32] sabdfl: very! [15:32] lool: yes, depends on the situation. currently testing with both debian and ubuntu and trunk before reporting bugs [15:32] at least in Ubuntu [15:32] cjwatson: I guess I took that as a given [15:33] cjwatson: Yes, just like gcc-4.5/gcc-4.4, gcc-linaro-4.4/4.5 [15:33] that if we are going to use two different toolchains, we would package them separately [15:33] mdz: it wasn't doko's original proposition, but I'm interested how he feels about it [15:33] cjwatson: well, there's still the problem of overlapping packages (runtime libs) [15:33] sabdfl: full rebuilds in Ubuntu are significant mirror-losing events [15:33] doko: mm, the runtimes concern me less really although I can see why we might want to think about them ... [15:33] mdz: the options so far was to apply a Linaro patch in the gcc-4.4 build [15:33] cjwatson: sorry, i meant private rebuilds not hammering-the-archive [15:33] there were other options, but basically resulting in the same [15:34] (e.g. have gcc-4.4 on some arches, and gcc-linaro-4.4 on others) [15:34] sabdfl: oh, well, they monopolise PPA builders for the best part of a week IIRC [15:34] doko: So in a way, you already have the pain of testing with a trunk toolchain, that doesn't change; it just makes it more likely that you hit branch specific bugs [15:34] if it's a question of more builders, that's relatively cheap [15:34] and for Linaro we're designing for them, although I imagine we still don't want to do that too often [15:34] or more often than necessary [15:35] doko: when you say trunk, you mean tip? [15:35] lool: I would prefer that we package both, and let both build on both architectures, to make it easier to isolate bugs [15:35] sabdfl: yes [15:35] doko: how tight is the binding between g++-4.4 and libstdc++6-4.4-dev [15:35] ? [15:35] mdz: doko's right though, got to pick one or the other to win libgcc1 [15:35] mdz: It's possible albeit expensive, for buildd time and for the maintenance of the forked debian/ [15:35] and libstdc++6 [15:35] cjwatson: it should be merged [15:35] doko: I'm not sure what that means [15:35] mdz: but I see the value in your point [15:35] cjwatson, doko: are the runtime libraries significantly different? [15:36] sabdfl, cjwatson: one thing I asked yesterday, and that I'd like to reiterate, is that we at the moment we don't have the results of a test rebuild back, so we're not very well-informed as to the impact of the toolchain change [15:36] Sufficiently that we need to include the CS patchset in gcc-4.5 [15:36] lool: why buildd time? the toolchain doesn't change that much [15:36] mdz: the only concern is libstdc++6, but we already have this problem with the 4.4/4.5 overlap [15:36] (that often, rather) [15:36] sabdfl, cjwatson: so while we should be careful to consider things now, we could postpone making a decision until we do have a rebuild as evidence [15:36] mdz: No, but the time to deploy a fix across all toolchains is longer; toolchain build time is very long, on armel notably [15:36] kiko: we could ack CS patches subject to "no disasters in the rebuild review" [15:36]