20110210

February 10th, 2011, 15:00 UTC in #ubuntu-meeting.

Agenda

Action Items from last meeting

  • NCommander to talk to the release team on which team to track w.r.t. to bugs (co)

Standing Items

Meeting Outcome

[15:00] <NCommander> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is NCommander.
[15:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:00]  * rsalveti waves
[15:00] <NCommander> good morning world
[15:00] <janimo> hello
[15:00] <NCommander> who's here?
[15:01] <ogra> froop
[15:01]  * NCommander smacks the wiki
[15:01] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110210
[15:01] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110210
[15:01] <NCommander> [topic] Action Item Review
[15:01] <MootBot> New Topic:  Action Item Review
[15:01] <NCommander> [topic] NCommander to talk to the release team on which team to track w.r.t. to bugs (co)
[15:01] <MootBot> New Topic:  NCommander to talk to the release team on which team to track w.r.t. to bugs (co)
[15:01] <NCommander> co again
[15:02] <NCommander> [topic] Standing Items
[15:02] <MootBot> New Topic:  Standing Items
[15:02] <NCommander> [link] http://people.canonical.com/~platform/workitems/natty/ubuntu-armel.html
[15:02] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/ubuntu-armel.html
[15:02] <NCommander> [link] http://people.canonical.com/~platform/workitems/natty/ubuntu-armel-natty-alpha-3.html
[15:02] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/ubuntu-armel-natty-alpha-3.html
[15:02]  * NCommander closed two work items today :-)
[15:02] <NCommander> and started work on modifying f-k to use archdetect
[15:03]  * NCommander pokes everyone else
[15:04] <NCommander> no one else has any comments?
[15:04]  * janimo works on updating  bootfiles
[15:04] <janimo> I'll close some WIs soon
[15:04] <ogra> i dont think archdetect will get you anywhere
[15:04] <ogra> what you want is persias new detection tool
[15:04] <ogra> thats why more precise
[15:04] <ogra> *way
[15:04] <persia> It's *too* precise.
=== oubiwann is now known as oubiwann_
[15:05] <persia> f-k should install the same kernel on multiple devices when the kernel supports multiple devices.
[15:05] <persia> archdetect is the right way to do this.
[15:05] <ogra> hmm, k
[15:05] <ogra> who is testing that and how ?
[15:05] <NCommander> ogra: well, first it needs to exist to be tested :-)
[15:06] <ogra> we only have omap for that but not the devices
[15:06] <ogra> unless anyone has an igep2
[15:06] <ogra> or gumstix that works
[15:06] <persia> Send out a call for testing.  There's plenty of folk with igep2 around.
[15:06] <persia> Doesn't gumstix have an MMC issue?
[15:06] <ogra> should be in the testing plan
[15:06] <ogra> i dont know if all of them do
[15:06] <ogra> mine surely does
[15:07] <ogra> s/does/did in lucid/
[15:07] <persia> lucid is an old kernel :p  Try again
[15:07] <ogra> anyway, jasper rewrite has to wait until i'm done with unity-2d .... there are updates in the queue
[15:08] <davidm> ogra, how many are there?
[15:08] <ogra> my other specs arent FF relevant
[15:08] <ogra> davidm, all of it
[15:08] <ogra> davidm, i'll talk about it in the unity-2d topic
[15:08] <davidm> Ah OK
[15:09] <NCommander> [topic] Unity 2D Status
[15:09] <MootBot> New Topic:  Unity 2D Status
[15:09] <ogra> hehe
[15:09] <NCommander> ogra: your time is now :-)
[15:09] <ogra> so i had a call with Kaleo today
[15:09] <ogra> to sync up
[15:09] <ogra> they have 3.4 ready
[15:10] <ogra> i'm holind that back until the already reviewed packages are in main
[15:10] <ogra> which should happen before end of the week
[15:10] <ogra> *holding
[15:10] <ogra> (since i dont want everything to be reviewed again)
[15:10] <ogra> (by MIR team)
[15:10] <ogra> there are two metacity patches we need
[15:11] <ogra> both have been reviwed by me and desktop team
[15:11] <ogra> one of them needs fixes from bfiller
[15:11] <ogra> if these patches are in and the packages are in main i'll care for the 3.4 update
[15:11] <ogra> right before FF we will get 3.8
[15:12] <ogra> (not sure if i will upload 3.6 specifically during next week)
[15:12] <davidm> ogra, that makes sense
[15:12] <ogra> the unity-2d team has a policy that features are not to have bugs
[15:12] <ogra> so they are under more pressure than us here wrt FF
[15:13] <ogra> i'll likely be busy while in cambridge :)
[15:13] <ogra> doing their package upgrades
[15:13] <ogra> well, thats it
[15:13] <ogra> ..
[15:14] <ogra> questions ?
[15:14] <ogra> else move
[15:14] <NCommander> [topic] Kernel Status (cooloney, rsalveti)
[15:14] <MootBot> New Topic:  Kernel Status (cooloney, rsalveti)
[15:14] <rsalveti> for omap 3 we got the new update from 38-rc4
[15:15] <rsalveti> should work the same way as before
[15:15] <rsalveti> did some tests around here and it seems to be quite stable
[15:15] <rsalveti> GrueMaster: how are your omap 3 testing going?
[15:15] <rsalveti> we need to test sound, s-video, usb-otg
[15:15] <janimo> I filed bug to drop versatile from kernel (only indirectly affects us now by having shorter build time)
[15:16] <ogra> did anyone test rootstock yet ?
[15:16] <GrueMaster> I was focusing on unity-2d testing yesterday.  Will test with new image today.
[15:16] <persia> Does the current qemu support omap well enough already?
[15:16] <rsalveti> janimo: cool, sounds a good timing, as everybody is testing the omap 3 kernel
[15:16] <rsalveti> ogra: have that on may todo list
[15:16] <ogra> great
[15:16] <GrueMaster> I have no way to test s-video.
[15:16] <rsalveti> persia: yup, linaro is using on their tools
[15:16] <ogra> persia, yes
[15:16] <rsalveti> GrueMaster: ok, I believe I can test the s-video output here
[15:17] <rsalveti> omap 4 kernel got some more stable updates, but still no release
[15:17] <ogra> we have a ppa kernel
[15:17] <rsalveti> we had the kernel discussion this week
[15:17] <ogra> that waits for testing
[15:17] <rsalveti> to have a 38
[15:17] <rsalveti> yup, ppa https://launchpad.net/~canonical-kernel-team/+archive/ppa
[15:17] <GrueMaster> ogra: I haven't seen any notification of anything that needs testing.
[15:17] <rsalveti> this is from the ti-omap4-dev branch, at the natty's kernel
[15:17] <ogra> GrueMaster, two lines above :)
[15:18] <ogra> that kernel wont have a working display driver yet
[15:18] <rsalveti> this kernel is basically the upstream one (same as master), but for omap 4
[15:18] <GrueMaster> yea, I see it now.
[15:18] <ogra> so make sure to have serial enabled when testing it
[15:18] <rsalveti> seems we have proper dvi patches at the linux-omap
[15:18] <rsalveti> so we should get at least dvi display working soon
[15:18] <ogra> could someone ask for them to be pulled into our branch ?
[15:18] <ogra> or poke cooloney
[15:19] <rsalveti> I can help with the patches, but can't work as my board has a broken dvi
[15:19] <rsalveti> *test
[15:19] <rsalveti> cooloney should be able to work on this
[15:19] <rsalveti> NCommander: put an action point for me to poke cooloney to work on the dvi patches
[15:19] <ogra> ++
[15:19] <ogra> though someone said he is on vacation
[15:20] <rsalveti> hm, true, but should be back soon probably
[15:20] <GrueMaster> Chinese new year.
[15:20] <rsalveti> anyway, I can email him
[15:20] <rsalveti> no other update atm
[15:20] <NCommander> [action] rsalveti to poke cooloney w.r.t. to DVI patches on OMAP4
[15:20] <MootBot> ACTION received:  rsalveti to poke cooloney w.r.t. to DVI patches on OMAP4
[15:21] <ogra> that kernel should get main focus during testing
[15:21] <rsalveti> I'll work to push the patch that gets beagle running at 720mhz soon too
[15:21] <ogra> the .35 one we have wont see any updates anymore
[15:21] <rsalveti> that should improve the omap 3 performance
[15:21] <ogra> ++
[15:22] <rsalveti> yup
[15:22] <rsalveti> questions? :-)
[15:22] <rsalveti> ..
[15:22] <janimo> yes, any news on .38 ?
[15:22] <ogra> are we there yet ?
[15:22] <janimo> for omap4
[15:22] <rsalveti> janimo: not much
[15:22] <ogra> janimo, read above ?
[15:22] <rsalveti> we have upstream working on it
[15:22] <rsalveti> got a branch with a ppa
[15:23] <rsalveti> but still no patchset from ti
[15:23] <janimo> ogra, must have missed it
[15:23] <ogra> too much side conversation around :)
[15:23] <GrueMaster> Are we at least guaranteed that the .38 kernel won't burn up any hardware?  I don't want another babbage 2.5 incident.
[15:23] <janimo> and too much use of Ctrl-L on my part :)
[15:24] <rsalveti> GrueMaster: should be safe
[15:24] <GrueMaster> ok
[15:24] <ogra> GrueMaster, it should work already, no idea if it will burn up anything but i doubt it
[15:24] <ogra> feel free to be at the friday call
[15:24] <ogra> to find out expected issues
[15:24] <GrueMaster> requires waking up.
[15:25] <davidm> GrueMaster, that was a hardware failure, OMAP does not suffer from that
[15:25] <NCommander> GrueMaster: unable to satisfy dependencies: Coffee is not available, but is referenced by other packages.
[15:25] <ogra> GrueMaster, its the same time as this meeting
[15:25]  * NCommander runs
[15:26] <GrueMaster> davidm: Just making sure.  Better safe than...
[15:26] <davidm> True enough
[15:26] <rsalveti> move?
[15:26] <NCommander> [topic] QA Status (GrueMaster)
[15:26] <MootBot> New Topic:  QA Status (GrueMaster)
[15:26] <NCommander> Moved
[15:26] <ogra> where to ?
[15:26] <ogra> left to right or back -> forward ?
[15:26] <rsalveti> forward is always better :P
[15:26] <ogra> hehe
[15:27] <GrueMaster> Discussed bug reports with marjo and davidm.  List we care about for reporting purposes is http://reports.qa.ubuntu.com/reports/team-assigned/canonical-arm-assigned-bug-tasks.html
[15:27] <ogra> GrueMaster, you assigned some bugs to the team recently
[15:27] <ogra> can we have them listed in the meeting in the future and assign them right after to individuals ?
[15:27] <GrueMaster> List for discussing open bugs that the team should look at and take individual ownership of is http://reports.qa.ubuntu.com/reports/team-assigned/ubuntu-armel-assigned-bug-tasks.html
[15:27] <ogra> awesome
[15:28] <ogra> you are ahead of my thoughts :)
[15:28] <marjo> GrueMaster, ogra: thx!
[15:28] <GrueMaster> The second one will have the team assigned bugs as well as individual bugs.
[15:28] <ogra> though i really dislike to assigne them to the team
[15:28] <ogra> we explicitly avoided that in the past
[15:28] <GrueMaster> Come up with a better way to do a list and I'll use it.
[15:29] <davidm> ogra, is only way to differentiate bugs we care about vs armel general bugs
[15:29] <ogra> davidm, why doesnt the way we use since years work ?
[15:29] <GrueMaster> what way is that?
[15:29] <davidm> there are a lot of bugs we just don't care about making it far to easy to miss those that we do care for.  signal to noise ratio is too high on general armel list
[15:30] <ogra> subscribing the team instead of hard assigning them
[15:30] <ogra> and then assign them to the individual that actually works on it
[15:30] <ogra> we never used the team as asignee
[15:30] <ogra> and imho that can only be a temporary thing
[15:30] <GrueMaster> there are a lot of bugs we don't care about that the team is subscribed to.
[15:31] <davidm> I don't think it really matters too much and what GrueMaster just said
[15:31] <ogra> who subscribed the team to them ?
[15:31] <davidm> lots of folks subscribe us to bugs
[15:31] <ogra> can we at least fix the bug policy accordingly then
[15:32] <ogra> policy was to subscribe the team for awareness but leave them unassigned until someone actually works on them
[15:32] <GrueMaster> What about the bugs that linaro is working on that our team is subscribed to?  We care about them from a knowledge standpoint, but not a reporting standpoiint.
[15:32] <ogra> assigning them to the team generates the false assumption someone works on it
[15:32] <ogra> GrueMaster, right
[15:32] <GrueMaster> assigning them to the team acknowledges that they have been seen and are being reviewed by the team.
[15:33] <ogra> assignment clearly means someone works on it
[15:33] <ogra> which isnt true for team assigned bugs
[15:33] <davidm> Well I think we can adjust the policy document
[15:33] <ogra> k
[15:34] <ogra> how do we make sure someone works on it
[15:34] <persia> Best to be aligned with the general bugsquad guides, which matches what ogra has been saying.
[15:34] <ogra> we need to make up a period for reviewing them regulary and assign
[15:34] <davidm> persia, then how do we tell what we care about in general?
[15:34] <GrueMaster> Also, I am not sure how easy it is to generate a report with bugs the team is subscribed to.
[15:34] <davidm> The list of bugs we are subscribed to is too large, the signel to noise ratio is much to hight
[15:35] <davidm> s/hight/high/
[15:35] <GrueMaster> without excessive noise.
[15:35] <ogra> davidm, we *care* about all bugs the team is subscribed to ... we *work* on all bugs assigned to team membvers
[15:35] <davidm> Not true
[15:35] <persia> davidm, There's currently a gap in managing buglists for teams in launchpad.  It's been discussed by the LP team, and has had some preliminary spec work, but it's a ways from deployment.
[15:35] <ogra> davidm, if thats not trues someone screwed it up
[15:35] <persia> NCommander, action me to go follow up on that status, and report usefully.
[15:36] <ogra> davidm, that has beed our bug policy since years now
[15:36] <davidm> it is very true, with Linaro in the mix now its even more true
[15:36] <NCommander> [action] persia to work on determining the gap w/ managing bug lists on LP
[15:36] <MootBot> ACTION received:  persia to work on determining the gap w/ managing bug lists on LP
[15:36] <persia> *status* I know the gap :)
[15:36] <davidm> not disagreeing what has been old policy, what I'm saying is old policy has now hit wall making it less useful to us
[15:37] <ogra> well, i still want to be subscribed to get bugmail for the team
[15:37] <rsalveti> the problem is that now we have linaro in the game
[15:37] <GrueMaster> my goal is less about following our bug policy and more about making a meaningful report for these meetings.
[15:37] <davidm> I want an easy way to get a report that I care fully about vs a report with a signal to noise ratio that is too hight to be useful
[15:38] <davidm> persia, do you understand what I am looking for?
[15:38] <persia> The problem isn't linaro.  The problem is that LP never had any way to manage teams, and as the number of teams grows, this gets noticed.
[15:38] <ogra> i dont see the team assignment as wrong as long as we make sure such bugs are assigned to actual persons within a very short timeframe (max a week)
[15:38] <persia> davidm, Precisely.  You want to be able to identify a set of bugs that you want your team to work on, prioritise them, and collect reports on progress.
[15:38] <davidm> I'm OK with a max of a week
[15:38] <ogra> but that puts a high load on tobin
[15:38] <davidm> persia, yes
[15:39] <GrueMaster> ogra: not really.
[15:39] <ogra> to assemble these liasts and do a lot of triage
[15:39] <ogra> *lists
[15:39] <GrueMaster> And please don't assume you know what my workload is.
[15:39] <persia> ogra, No, LP should be able to do it.  I need to resync with mpt about the design work done last month, and maybe toss up a PoC or something.
[15:39] <ogra> i dont, but i can assume how it raises ;)
[15:40] <ogra> assigning a bug needs conversation
[15:40] <GrueMaster> If my workload becomes a concern, I will raise a flag.
[15:40] <ogra> that will definitely add time
[15:40] <ogra> and guesswork on your side to find the right person to take it etc etc
[15:41] <GrueMaster> Thats why I am assigning the team.  So we can discuss the list of team assigned bugs in this meeting (not the report formats).
[15:41] <ogra> geez
[15:41] <persia> That's a reasonable stop-gap.  Let's keep that list to be small for now, and actually cover them during the meeting, so they can be better reassigned.
[15:41] <ogra> your list has tons of crap
[15:41] <GrueMaster> My idea was to spend time throughout the week triaging bugs (which I do while platforms are downloading & installing).  Then we have a nice report to discuss here.
[15:42] <GrueMaster> It's a work in progress.
[15:42] <ogra> yeah
[15:42] <ogra> i see that
[15:42] <ogra> there are many bugs that can just be closed
[15:42] <ogra> (the babbage ones stick out in my face ;) )
[15:42] <persia> Lots of those aren't platform-specific
[15:42] <GrueMaster> then close them.  At least start closing the bugs that you have fixed but not updated.  That takes a lot of my time too.
[15:43] <ogra> they are rather wontfix
[15:43] <GrueMaster> I am working on it.
[15:43] <ogra> what about the bugs assigned to others i.e, i see lool, asac and dyfet
[15:44] <ogra> will you assign them back to the team ?
[15:44] <GrueMaster> I have a novel idea.  Instead of complaining, how about coming up with some valid suggestions on how to fix this?  It would be much more productive than calling my work crap.
[15:44] <janimo> GrueMaster, persia  I see some bugs (not arm ones) LP automatically closed after a period of inactivity. Is that up to the project's admins?
[15:44] <ogra> GrueMaster, i dont call your work crap ...
[15:44] <GrueMaster> LP closes some bugs after a period of inactivity.
[15:45] <persia> janimo, It's on a per-package basis.  There's a lot of debate about it.  I believe it's actively harmful for things to be closed like that.
[15:45] <ogra> i call the bugs crap, nothing to do with you or the list
[15:45] <GrueMaster> And I am working on it.  As I said.
[15:45] <ogra> janimo, if you leave a bug in incomplete status for 60 days it gets autoclosed
[15:46] <NCommander> I don't think we're going to resolve this in a single meeting, persia has an action item to deal with the bug/noise ratio, now can we please move on?
[15:46] <janimo> ogra, I seem to remember some arm bugs from 2 years back
[15:46] <persia> Sometimes, depending, and it's supposed to get autoexpired, rather than autoclosed.
[15:46] <persia> NCommander, Please.
[15:46] <ogra> janimo, then they werent marked incomplete
[15:46] <ogra> NCommander, go
[15:46] <NCommander> [topic] ARM Porting/FTBFS status (NCommander, janimo)
[15:46] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, janimo)
[15:46] <NCommander> QT works
[15:46] <NCommander> queue celebration :-P
[15:46] <NCommander> *que
[15:46] <janimo> :)
[15:46] <NCommander> *cue
[15:46] <NCommander> bah
[15:46] <ogra> how about the rest of the ftbfs list :)
[15:47] <NCommander> lack of coffee upsets me :-(
[15:47] <janimo> Qt celebration FTFY
[15:47] <NCommander> ogra: looked at kdebindings
[15:47] <ogra> awesome !
[15:47] <NCommander> Looks like the CMakeLists.txt file is bugging up on ARM which causes the second failure, or a binding is out of whack
[15:47] <NCommander> Haven't had a lot of time to look at it, but its next my list, which should clear the rest ofARM Porting/FTBFS status (NCommander, janimo)
[15:47] <NCommander> ...
[15:47] <NCommander> ahem
[15:47] <NCommander> *clear the rest of KDE
[15:48] <janimo> NCommander, that should be mostly give-backs right?
[15:48] <NCommander> janimo: one hopes
[15:48] <janimo> on my part, small progress again on two haskell packages. Most time was Qt-debugging
[15:49] <ogra> yeah, it stole a lot of time
[15:49] <ogra> awesome work from you two !!!!
[15:50] <rsalveti> yup, nice work
[15:50] <davidm> NCommander, did you see the GCC4.5 bug has a patch?
[15:50] <NCommander> Linaro is handling with the toolchain regression which is the underlying cause of the qt breakage. I'll be syncing up regularly with the linaro folks on that
[15:50] <NCommander> davidm: no. my inbox has 490 unread threads :-(
[15:50] <davidm> Looks like it's fixed
[15:50] <janimo> we should tackle banshee next, with renewed confidence and sharpened debugging skills
[15:50] <ogra> haha
[15:50] <davidm> they have a root cause and a patch
[15:50] <ogra> the eternal banshee bug
[15:51] <NCommander> janimo: statements like that always lead to weird dreams and a desire to slit my wrists
[15:51] <davidm> is that not the eternal mono bug?
[15:51] <janimo> NCommander, that is why  I brought it up :P
[15:51] <ogra> yeah, or that
[15:51] <ogra> getting banshee working would be really noce though
[15:51] <ogra> *nice
[15:52] <janimo> likely mono. Mono team says no mono 2.8 in natty so we stick with 2.6 . 2.8 has arm fixes
[15:52] <NCommander> janimo: your welcome to work on mono. I warn you that staring into the untempered schism that is mono's codebase will drive most mortals insane
[15:52] <ogra> i think much of the future featuresets in ubuntu use banshee features
[15:52] <janimo> but not easy to locate, may be side effects of rewrites done in the 2.8 cycle
[15:52] <ogra> whats the reason to hold back 2.8 ?
[15:52] <NCommander> janimo: might want to try 2.8, and see if it works. Not holding my breath, but maybe we'll get lucky
[15:52] <ogra> was it not released upstream yet ?
[15:52] <janimo> NCommander, I had started on looking at the test cases a month or so ago, we need to sync up
[15:53] <janimo> ogra, lack of manpower
[15:53] <janimo> on part of the debian-mono team
[15:53] <ogra> hmm
[15:53] <janimo> as it is a large transition apparently
[15:53] <ogra> and there is no chance to pull it into ubuntu first i guess
[15:53] <janimo> talked to directhex a few weeks ago
[15:53] <ogra> ahead of debian
[15:54] <janimo> ogra, I am fine with debugging mono, but packaging the whole CIL ecosystem gives me the willies
[15:54] <ogra> heh
[15:54] <persia> Not a lot of point: the CLI/Mono folk are fairly closely integrated between Debian and Ubuntu
[15:54] <ogra> we can give that to NCommander dont worry
[15:54] <janimo> I think it is a large task if it is not done by now
[15:54] <janimo> I thin 2.8 is months old
[15:54]  * ogra giggles evil
[15:55] <NCommander> ogra: oh come on. I have a one evil bug per cycle. No fair giving me a second one
[15:55] <NCommander> :-P
[15:55] <davidm> running low on time folks
[15:55] <NCommander> indeed
[15:55] <NCommander> [topic] ARM Image Status (ogra, NCommander)
[15:55] <MootBot> New Topic:  ARM Image Status (ogra, NCommander)
[15:55] <ogra> they buuld
[15:55] <ogra> *build
[15:55] <NCommander> and spin
[15:55] <ogra> nothing to report ...
[15:55] <ogra> ..
[15:55] <GrueMaster> What's the status on the minimal images?
[15:56] <NCommander> as soon as unity-2d is in main, ogra or I will adjust the seeds and unseed UNE-2D
[15:56] <ogra> oh, right
[15:56] <janimo> GrueMaster, no progress yet
[15:56] <janimo> GrueMaster, next up
[15:56] <NCommander> [topic] AOB
[15:56] <MootBot> New Topic:  AOB
[15:56] <janimo> I'll start asking for merges
[15:56] <ogra> foo
[15:56] <davidm> ogra, what are the odds of having Unity 2D as default in image by next Thursday?
[15:56] <NCommander> bah
[15:56] <ogra> davidm, i planned end of this week (as i said in the report above)
[15:56] <ogra> (mentioned it at unity-2d topic)
[15:57] <davidm> slid past me, sorry
[15:57] <ogra> we need two symbols files and an automatic bug assignee
[15:57] <ogra> they they are ready for main
[15:57] <davidm> I'm off to Scale and TI will be there so I'm going to carry some SD cards for them to use
[15:57] <ogra> (that were the MIR team requests)
[15:58] <ogra> note that there are bugs with the dash atm
[15:58] <NCommander> ogra: do you want me to do any symbol file work?
[15:58] <ogra> (expected ones)
[15:58] <ogra> they will go away with 3.4
[15:58] <ogra> NCommander, well, if you like to add the files to the bugs that would help
[15:58] <NCommander> ogra: ah
[15:58] <NCommander> ogra: I could just commit and upload them :-P
[15:59] <ogra> NCommander, but to trunk please with a review from Kaleo
[15:59] <ogra> NCommander, i gave you the bug numbers yesterday i think
[15:59] <ogra> or do you need them again
[15:59] <NCommander> ogra: probably have them in my logs
[15:59] <rsalveti> #ubuntu-arm then
[15:59] <ogra> anyway, lets close and move to -arm
[16:00] <NCommander> I don't think we have anything else
[16:00] <NCommander> going once
[16:00] <NCommander> twice
[16:00] <NCommander> three times
[16:00] <NCommander> #endmeeting
[16:00] <MootBot> Meeting finished at 10:00.

Action Items

Weekly Reports

Michael Casadevall (NCommander)

  • Toolchain regression in Qt identified; workaround uploaded

Next Week

  • KDE FTBFS work

Ricardo Salveti (rsalveti)

Next Week

  • Edid autodetection for OMAP 3
  • Start the set-up box bp

Minutes

ARM/Meeting/2011/20110210 (last edited 2011-07-28 17:57:40 by pool-96-226-234-14)