=== jj-afk is now known as jjohansen === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === zul_ is now known as zul === debfx_ is now known as debfx === jjohansen is now known as jj-afk [15:03] #startmeeting [15:03] Meeting started at 09:03. The chair is NCommander. [15:03] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:03] moo [15:03] * rsalveti waves [15:03] [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110310 [15:03] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110310 [15:03] hello [15:03] so who's here? [15:03] I'm not [15:03] Hi [15:04] [topic] Action Items [15:04] New Topic: Action Items [15:04] [topic] ogra to fix WI tracker [15:04] New Topic: ogra to fix WI tracker [15:04] hmm, havent checked it yet, but it should be fine now [15:05] [topic] everyone to check their WI status on the whiteboards that the right beta tag is set [15:05] New Topic: everyone to check their WI status on the whiteboards that the right beta tag is set [15:05] looks fine [15:06] NCommander, no beta WIs for you at all ? [15:06] everyone else seems to show up [15:07] ogra: my one spec was axed because you, me,a nd persia agreed the design was unworkable for generic subarch support [15:07] well, i guess you still have enough mono to do ;) [15:07] ... [15:08] [topic] Standing Items [15:08] New Topic: Standing Items [15:08] [link] http://people.canonical.com/~platform/workitems/natty/ubuntu-armel.html [15:08] LINK received: http://people.canonical.com/~platform/workitems/natty/ubuntu-armel.html [15:08] [link] http://people.canonical.com/~platform/workitems/natty/ubuntu-armel-ubuntu-11.04-beta-1.html [15:08] LINK received: http://people.canonical.com/~platform/workitems/natty/ubuntu-armel-ubuntu-11.04-beta-1.html [15:08] most my WI related to GLES are basically waiting the implementation to finish [15:08] so no much to do [15:08] then just remain the others [15:09] webkit fix is now uploaded, and should hit the archive soon [15:09] then we can go back and use ubiquity with the slideshow [15:09] rsalveti: once we have it confirmed fixed, I'll delete the livecd-rootfs hack [15:09] * ogra still cant remember what packageselection-arm-n-device-type-detection meant [15:10] NCommander: I tested already with a preinstalled image [15:10] err, the Wi i have for that [15:10] NCommander: and it worked fine, just need to wait it to build and hit the archive [15:10] and that will take between 1 and 2 days [15:10] persia, i think that was yours, could you somehow brief me again offline ? [15:11] anything else on the WIs? [15:12] i wonder if we shouldnt remove the ppa cluster [15:12] davidm, ^^^ [15:12] ^- davidm [15:12] its totally not bound to release cycle but makes us look slightly bad [15:12] i think we're doing really great, but thanks to that spec the tracker doesnt really reflect that [15:13] it's not something that affect the release [15:13] yeah, thats what i mean [15:13] it's more a launchpad feature than ubuntu, in some way [15:13] ogra: maybe simply target it to O cycle? [15:14] NCommander, right, something like that, but its davids spec and his decision [15:14] seems he's not around so lets move [15:14] we can clearify that later [15:14] [topic] Unity 2D Status [15:14] New Topic: Unity 2D Status [15:14] will see an update before end of the week [15:14] cool [15:14] lots of fixes in trunk we dont have in the image/archive yet [15:15] nothing new otherwise [15:15] anything else? [15:15] not from me [15:15] [topic] Kernel Status (cooloney, rsalveti) [15:15] New Topic: Kernel Status (cooloney, rsalveti) [15:15] where is our .38 build ? [15:16] i thought GrueMaster approved it [15:16] no other news beside the same package from last week that GrueMaster tested [15:16] I pulled the PPA cluster from the timeline [15:16] davidm, thanks :) [15:16] and removed it from natty entirely [15:16] I did. [15:16] move it to O [15:16] I did that weeks and weeks ago [15:16] GrueMaster reported back to cooloney, but now it'd probably be good to reply the email thread saying we want it by default [15:16] it makes us look good from the beginning :) [15:16] and change the boot.scr arguments, to use the DVI output [15:16] ah, right [15:16] I did that as well (I think). [15:17] rsalveti, how will we handle upgrades = [15:17] ogra, it's it's still showing up let me know what I need to do to remove it entirely [15:17] we still have no solution for that [15:17] email that is. [15:17] yes, i saw GrueMaster's mail [15:17] i dont think there should be any blocker [15:17] statement was clear [15:17] no, and we could just do the switch [15:17] for the update I believe we could just document it for now [15:18] otherwise we would need to hack the boot args [15:18] but the user will need to change the cable anyway [15:18] yes, i actually did expect tim had done it after GrueMaster's mail [15:18] yup, that's whay it may need another email requesting it [15:19] well, i'll use IRC ;) [15:19] * ogra pinged tim [15:19] :-) [15:19] i still would like to have a proper upgrade path though [15:19] GrueMaster: anything to report for the kernel tests? [15:19] * janimo is running the 2.6.38-1024-omap4 kernel from PPA, looks fine after a few days [15:19] yeah, it'd be good to have [15:20] i.e. some message from update-manager "please plug your cable into the dvi port after reboot" [15:20] headless only though, mostly building workloads [15:20] thats the least we should have [15:20] ogra: yup, that can be changed at the package itself? [15:20] like a postinst? [15:20] there is a script in u-m somewhere [15:21] we added a warning for ARMv5 vs v6 between karmic and jaunty [15:21] ogra: ok, so should we wait this to be done before putting it as default? [15:21] I can dig to see what was done [15:21] dyfet was actually supposed to add a v7 warning too and never managed [15:21] This is only temporary though, right? [15:21] i think that can happen hand in hand [15:21] it shuold be [15:21] GrueMaster, we dont know if it will be solved by release [15:21] before the release we want to use hdmi again [15:22] and have a proper driver [15:22] sure [15:22] but we dont have it at all yet [15:22] no, and not completely sure if TI will manage to implemente the hdmi driver [15:23] but that's another problem [15:23] so at least being prepared for such a warning in u-m before string freeze is needed [15:23] we can still drop it [15:23] ok, will look to have it [15:23] ok, kernel switch triggered, tim is building it now [15:23] awesome [15:23] any other question for kernel? [15:23] (seems he missed GrueMaster's mail) [15:23] outstanding [15:24] ogra: guess he was waiting the reply at the pull request email [15:24] GrueMaster, use a tag in the subject line in the future ;) [15:24] * NCommander is having chromium stability issues this morning :-( [15:24] [topic] ARM Porting/FTBFS status (NCommander, janimo) [15:24] New Topic: ARM Porting/FTBFS status (NCommander, janimo) [15:24] Interesting. We even discussed it on IRC. [15:25] GrueMaster, but you didnt use there either :P [15:25] some progress on FTBFS count [15:25] So on ARM porting, I'm kinda grinding my gears w.r.t. to mono [15:25] closed a few arm-porting-queue tagged bugs [15:25] We've gotthe SMP patch which does wonders for the mono 2.10 test suite (and was incorperated in the 2.10.1 release) [15:25] NCommander, do we need to send Tobin some earplugs ? [15:25] including the two outstanding Qt ones (pending a test for neon still) [15:26] but I'm not making any headway with a successful backport to 2.6, I think the underlying mono crashes are coming from PInvoke() failures in Gtk# [15:26] but it seems odd to me that they're over occuring in 1-processor mode [15:27] NCommander, can we just apply the membarrier patch to 2.6 and do an upload, if it is clearly needed even if does not seem to direclty impact banshee? [15:27] I was able to produce the same failures on Debian sid, so at least I've ruled out thumb2 as the immediate cause [15:27] we could just quickly rewrite banshee in C :) [15:27] janimo: I can do that, but I don't really want to do multiple mono uploads [15:28] janimo: are you sure banshee fully worked when in nosmp mode? Its slightly more stable, but trying to do anything like play music or rescan library causes a crash [15:28] (also, f-spot is still crashing) [15:28] luckily we dont ship f-spot anymore since maverick [15:28] NCommander, no I am not sure at all. rsalveti and GrueMaster looked at nosmp testing in more detail [15:28] how is tomboy [15:28] ogra: its still a valid test case [15:28] ogra: tomboy works [15:28] Tomboy never failed. [15:28] we usually had it working while all other apps failed [15:29] right [15:29] rsalveti: ^- banshee nosmp question [15:29] My guess is that it is not multithreaded. [15:29] The bug is probably in mono but some apps manage to not trigger it [15:29] janimo: well, that's why I think its pinvoke() [15:29] depending on how Gtk intesive they are [15:29] tomboy is really trivial indeed [15:29] (for reference sake, pinvoke is the magic C# to C binding) [15:29] I just tested with banshee [15:29] NCommander, IIRc in Dallas I managed to get stable banshee if I uninstalled the default theme [15:29] and using some ghetto default [15:30] gtk theme that is [15:30] janimo: doesn't work here, I have it using no theme and still crash city [15:30] rsalveti: right, but what did you do in banshee beside launch it? [15:30] NCommander: use it normally, playing music and such [15:30] nothing, look at the About menu :) [15:30] NCommander: I played audio for a good hour on my BeagleXM [15:30] yeah, it was quite stable [15:30] grumble [15:31] I guess I need to run the test suite in nosmp mode and see if we still get failures or if we're looking at a red hearing [15:31] GrueMaster, never had crash recently on single core? [15:31] Could be we are seeing multiple issues. [15:31] What's making things difficult w.r.t. to backporting is the JIT is passing all the tests [15:31] And between 2.6 -> 2.10, someone added iPhone support [15:31] which means there's a TON of commits clogging up the works [15:31] ouch :-( [15:32] plus I'm not even sure mono is fixed in 2.10 since I can't run banshee without spending a week recompiling the entire stack [15:32] argh, problem of using a quite old version [15:32] (I'm semi-tempted to throw Gentoo ina chroot and test it that way) [15:32] NCommander, right, when I looked I could find may arm commits but nothing which wuld imply it fixes some tests [15:32] janimo: I'm almost thinking it probably got improved as part of the iPhon10:30:37 < janimo> nothing, look at the About menu :) [15:32] 10:30:49 < GrueMaster> NCommander: I played audio for a good hour on my BeagleXM [15:32] 10:31:02 < rsalveti> yeah, it was quite stable [15:32] NCommander, or Suse or any distro with new mono I guess [15:32] &^%$@$!# [15:32] ah they may not have arm [15:32] janimo: SuSE doesn't have an ARM port [15:33] fedora? [15:33] hrm [15:33] * NCommander looks [15:33] probably not very wdely tested [15:33] or OE [15:33] Fedora has an arm port in the works (I think). [15:33] but then don't know if they are building banshee and mono [15:34] there is a mono recipe at OE, but 2.6.3 [15:34] doesnt OE even default to hardfloat ? [15:34] they've got banshee available for Fedora [15:35] that should have build options close to ours (v7 thumb2) [15:35] don't think they already changed it [15:35] ogra: I already elimated v7+thumb2 as the cause of the regression [15:35] bah [15:35] Fedora is shipping 2.6 still [15:35] argh [15:35] who is using 2.10? [15:35] opensuse only? [15:35] megoo ? [15:35] checking [15:35] did anyone check there [15:35] ogra: no [15:36] various IPhone and Android 3rd partuy apps maybe [15:36] ogra: but its of limited use. the problem is the entire dependency stack [15:36] Might simply need to build a chroot then build mono + gtksharp + everything else from scratch [15:36] * NCommander wimpers [15:36] * GrueMaster votes to bag mono for this cycle - again. [15:36] but I think we need to confirm 2.10 is regression free [15:36] GrueMaster: it'd be nice to have [15:36] NCommander, does C# have the equivalent of inline functions, so Gtk sharp has some bits unless rebuilt against a new mono, even if we upload a fixed mono? [15:36] GrueMaster, that means we need to take over rhythmbox mainteanance [15:36] and it seems we're getting closer somehow [15:37] janimo: nout out of the box [15:37] at least [15:37] I don't think so [15:37] janimo: I know the official Microsoftimplementation can make native code .exe's [15:37] I don't know if mono embeds native code into the generated PE files [15:37] NCommander: Instead of trying to build it locally, should it go in a ppa? [15:38] GrueMaster: repackaging mono for 2.10 would be an absolute nightmare [15:38] and I'm not confortable in my packaging skills to try it [15:38] NCommander, well it is packaged for Deb as you said, just too risky to sync at this point [15:39] janimo: its not uploaded, the transition is sitll in progress [15:39] I say we should keep debugging (I will help as well) and only keep Rhythmbox if we cannot fix it say 2 weeks before release [15:39] and what would we gain ? we cant upload it at all without affecting the other arches [15:40] 2.10 is clearly not natty for the others [15:40] ogra: right, but we need to make sure that 2.10 is fixed. At the very release, O cycle which we could ship 2.10 will work [15:40] sure [15:40] if we know 2.10 works, then we can bisect, and deal with all the iphoneos patches [15:40] but I don't want to deal with that without a "verification-confirmed" in hand :-P [15:41] yeah, we need to test with 2.10 [15:41] or git upstream [15:41] I'll work with git, since I at least have been making progress with mono upstream devs :-) [15:41] actually [15:41] well, it should work :-) [15:41] * NCommander checks gentoo very quickly [15:41] if I can do 'emerge banshee' and let it run for a day, I'd be happy [15:42] NCommander, so gentoo has good arm support? [15:42] Nafallo: http://packages.gentoo.org/package/dev-lang/mono [15:42] * ogra would suspect OE to be easier [15:42] oh right, nuts [15:42] gentoo's ARM port is kinda ... [15:42] If I may, we don't want to throw all or even most of our engineering effort at one package. We have enough other stuff that is in the image that needs attention. [15:42] janimo: it would be easier to have an arm rootfs [15:42] in the same state as its m68k port [15:42] NCommander, one of the mono arm devs is from Budapest, worst case we track him down at UDS and let him fix this :) [15:43] Nafallo: sorry [15:43] NCommander: http://packages.gentoo.org/package/dev-lang/mono [15:43] 2.10.1-r1 [15:43] davidm: I think a bit of direction is needed: how high is mono on the priority list [15:43] * Nafallo steps away from the gentoo. [15:43] and banshee 1.8.1 [15:43] no worries [15:43] rsalveti: right but its masked to powerpc/amd64/i386 only. There's an armel overlay but this is leading to the path to madness [15:43] * ogra guesses the banshee shop is pretty high [15:43] argh, no easy path [15:44] rsalveti: right, so best bet is to simply try and build mono stack by hand and pray [15:44] yeah [15:44] NCommander, really, take OE [15:44] GrueMaster, well I mean since our WIs seem to be getting close to solved and we get into more bugfixing mode, this is one important bug. Of course we should see if there are other more important issues [15:44] [action] NCommander to build mono stack by hand and confirm 2.10 fixes mono regression [15:44] ACTION received: NCommander to build mono stack by hand and confirm 2.10 fixes mono regression [15:44] ogra: looking at OE, I don't even see a package list [15:45] NCommander, but debian arm does not experience this crash een on 2.6 ? [15:45] ogra: mono is still 2.6 [15:45] so he would first need to update the mono recipe [15:45] and that can take the same amount of work as updating the ubuntu package by hand [15:45] janimo: no, it does [15:46] rsalveti: I was able to reproduce the crash in a Sid chroot with the SMP patch [15:47] NCommander, great than. I had the impression we were special because of ARMv7 and newer toolchain [15:47] janimo: its probably a good idea to have someone double check my results to make sure I made no error [15:47] NCommander, do we absolutely rule out hw errors [15:47] panda kernel/memory stuff [15:47] janimo: mono devs did report they don't see issues on tegra [15:48] although I'm blocking if that's SMP or not [15:48] that is SMP AFAIK [15:48] all tegra2 cpus are multicore [15:48] my tegra system is currently got a trashed install on it [15:48] Was it tegra or tegra 2? [15:48] ogra: can you easy test banshee? [15:48] only on maverick [15:48] oh, argh [15:48] i cant upgrade to natty [15:48] ogra: we had the issue with maverick I believe [15:49] ^as well [15:49] ogra, it used to fail on maverick too so ok [15:49] Yes, we did. [15:49] right, what would a test on tegra improve here ? [15:49] [action] ogra to determine if mono still crashes on tegra [15:49] for maverick [15:49] ACTION received: ogra to determine if mono still crashes on tegra [15:49] ogra: rules out panda HW. [15:49] k [15:49] well, mono version from maverick is quite the same [15:49] you probably need the SMP patch [15:50] NCommander: don't you also have a ac100 in hands? [15:50] rsalveti: the install is trashed [15:50] hehe :-) [15:50] Best to fail first, then test the fix. [15:50] yeah, and restoring an SD takes 10mins [15:51] wrong window [15:51] right, we're running out of time [15:51] so lets take this offline [15:51] ++ [15:51] yup, move [15:51] [topic] ARM Image Status (ogra, NCommander) [15:51] New Topic: ARM Image Status (ogra, NCommander) [15:51] headless is there !!! [15:51] :) [15:51] go ogra + janimo [15:51] \o/ [15:52] Needs work, but it is booting. [15:52] bug 732576 needs some testing for the fis [15:52] Launchpad bug 732576 in ubiquity (Ubuntu Natty) "oem-config-debconf does not start on preinstalled images" [High,New] https://launchpad.net/bugs/732576 [15:52] *fix [15:52] should be in the next ubiquity upload, i'll test the fix after meeting [15:52] serial by default is still miissing [15:53] NCommander, sorry was pulled away on a call [15:53] and to make GrueMaster happy i hardcoded "localhost" as hostname for all preinstalled images today ;) [15:53] mono is important [15:54] Bug 732581 is an intresting one [15:54] davidm: not a problem [15:54] Launchpad bug 732581 in ubiquity (Ubuntu Natty) "oem-config colormap distorted during package removal in oem-config-debconf on omap4 preinstalled images" [Medium,New] https://launchpad.net/bugs/732581 [15:54] davidm: ok, just wanted to make sure I wasjustified to continue working on it [15:54] NCommander, we need to fix it, if at all possible [15:54] i would like to see someone test on a beagle [15:54] ogra: Will do later this am. [15:54] since i'm not sure its the panda framebuffer being broken here [15:55] GrueMaster, just wait for the next build, that shuld also have the ubiquity-dm fix so you dont need to tinker with the image [15:55] k [15:56] headless will be the first image to build every day, ist also the fastest build (shoudl be available at 00:30 UTC) [15:56] so we can easily test core bits before netbook gets built [15:56] Especially if netbook crashes. [15:57] yep [15:57] awesome [15:57] NCommander, to avoid building the whole stack of mono, you may first build banshee from source too with a minimal set of dependencies and plugins which still lead to crash [15:57] its a good measure [15:57] .. done with image status [15:57] janimo: I'm going to follow the instructions on the website to build banshee [15:57] [topic] QA Status (GrueMaster) [15:57] New Topic: QA Status (GrueMaster) [15:58] janimo: I don't think it will be TOO bad [15:58] Documented installation process at http://wiki.ubuntu.com/ARM/HeadlessInstall [15:58] NCommander, ok, I now it has lots of plugins enabled as it is [15:58] meh [15:58] For the minimal image. [15:58] janimo: almost all ship with banshee [15:58] GrueMaster, can you follow the naming scheme thats on /OMAP [15:59] since thats what we link from the image download pages [15:59] ogra: I left it this way in case we start building more images for other platforms next cycle. Reduce wiki clutter. [15:59] NCommander, right. I mean if there are plugins written in C# which now ship, but which if disabled still crash banshee, those you don;t need to include in the full rebuild [15:59] GrueMaster, well, it should be linked from /OMAP and have a releasename in the url [15:59] janimo: fair enough [16:00] * GrueMaster waits for mono discussion to finish. [16:00] ogra: This was also just a first run. [16:00] uh sorry, I brought it up again [16:01] Time's up. [16:01] GrueMaster, yeah https://wiki.ubuntu.com/ARM/OMAP links to https://wiki.ubuntu.com/ARM/OMAPMaverickInstall and should also link to https://wiki.ubuntu.com/ARM/OMAPNattyInstall ... [16:01] * NCommander can't remember if we're running into another meeting [16:01] make the headless instructions a link on the natty one [16:01] [topic] Any Other Business [16:01] New Topic: Any Other Business [16:01] (very quickly :-)) [16:01] NCommander, finish, we can take the rest offline [16:02] #endmeeting [16:02] Meeting finished at 10:02. === jj-afk is now known as jjohansen === dholbach_ is now known as dholbach [17:59] mdz, kees, cjwatson: TB meeting in 1 min? [17:59] no trace of sabdfl or Keybuk [17:59] pitti: hola. I emailed keybuk just now [17:59] pitti: haven't heard back though [18:00] hi pitti [18:00] * pitti still chews up the last bits of his dinner [18:00] #startmeeting [18:00] Meeting started at 12:00. The chair is mdz. [18:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:01] ah, you're chairing? thanks [18:01] * pitti just noticed that he is signed up as fallback, but I don't insist :) [18:02] I have done zero prep, because I thought someone else was chairing, and didn't get a response when I asked on the list [18:02] there were no minutes sent out for the previous meeting, so I don't know if there were any actions [18:02] I updated the agenda about 15 min ago with the statuses from the last meeting [18:03] $ bzr lp-propose [18:03] bzr: ERROR: No reviewer specified [18:03] sorry, -EFOCUS [18:03] mdz: I don't see your email to the list either [18:04] http://www.novarata.net/mootbot/ubuntu-meeting.log.20110222_0932.html [18:04] LINK received: http://www.novarata.net/mootbot/ubuntu-meeting.log.20110222_0932.html [18:04] https://wiki.ubuntu.com/TechnicalBoardAgenda [18:04] kees, thanks for that [18:04] np [18:04] looks like the actions are all done [18:04] [topic] Quarterly brainstorm review (mdz) [18:04] New Topic: Quarterly brainstorm review (mdz) [18:05] so it's been 3 months since the last one, so it's time for the second installment of the brainstorm review [18:05] I would be grateful if someone else could drive it this time [18:05] it's not a huge amount of work, but requires some day-to-day care and feeding to keep things moving [18:06] I can share the email templates, blog text, spreadsheet, etc. which I used the last time [18:06] that would be helpful indeed [18:06] mdz: what was your criteria for what to respond to out of all the stuff there? [18:06] so that was about reviewing the top n and picking out the sensible stuff? [18:07] I think I can squeeze in some time for that [18:07] pitti, yes [18:07] kees, I more or less picked the top 10 off of the "most popular over 6 months" list [18:07] though I would be glad to see some experimentation there [18:07]