=== asac_ is now known as asac === asac_ is now known as asac === ianmcorvidae|alt is now known as ianmcorvidae === dantalizh is now known as dantalizing === dantalizing is now known as zz_dantalizh === zz_dantalizh is now known as dantalizing === dantalizing is now known as zz_dantalizing [11:57] * ogra moos === pgraner-afk is now known as pgraner [11:58] * lool waes [11:58] *waves [11:58] * StevenK beaches [11:58] haha [11:59] * NCommander gurgles [11:59] OK. Let's get started then. [11:59] #startmeeting [11:59] Meeting started at 05:59. The chair is persia. [11:59] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [11:59] [LINK] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090305 [11:59] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090305 [11:59] [TOPIC] persia's action items [11:59] New Topic: persia's action items [12:00] Actually running an OEM install without hand-editing the command line is currently blocked by bug #309396 [12:00] Launchpad bug 309396 in syslinux "Ubuntu UMPC boot menu is truncated" [Undecided,Invalid] https://launchpad.net/bugs/309396 [12:00] Other than that, it seems most of the right bits are in place. [12:01] I've added the arm-library-optimisation and pouslbo packaging to the roadmap, as well as that bug. [12:01] I haven't looked at the test cases at all, and will be carrying over that action item. [12:01] [topic] NCommander's action items [12:01] New Topic: NCommander's action items [12:02] jax10 installer works [12:02] Most of my other items are carry over however, due to work on the Babbage board. [12:02] [topic] StevenK's action items [12:02] New Topic: StevenK's action items [12:03] Bug 335276 filed. [12:03] Launchpad bug 335276 in xserver-xorg-video-psb "[Intrepid] SRU for 2D Poulsbo" [Undecided,New] https://launchpad.net/bugs/335276 [12:03] [topic] ogra's action items [12:03] New Topic: ogra's action items [12:03] bug forwarded on request of the desktop team (seb128) [12:03] http://bugzilla.gnome.org/show_bug.cgi?id=574152 [12:03] LINK received: http://bugzilla.gnome.org/show_bug.cgi?id=574152 [12:03] Gnome bug 574152 in general "Hangs with 100% CPU usage on ARM hardware" [Critical,Unconfirmed] [12:03] attached a stack trace but upstream doesnt seem happy yet [12:04] (oh, and i can finally reproduce it) [12:04] [topic] lool's action items [12:04] New Topic: lool's action items [12:05] ogra, is it only ARM or does it happen on other arches? [12:05] So I gave thoughts to the EC2 architecture I'd use; I looked into the AutoInstall testing in update-manager and it teached me a lot about EC2 and Python bindings, but I didn't spec anything yet [12:05] currently its only arm afaik, the other comments there look rather like red herrings [12:05] davidm, ^^ [12:05] davidm, That bug is in the roadmap: let's hit details when we get there [12:05] I'm busy with other stuff, so I intend to continue research around the next week [12:05] thanks ogra [12:05] (done) [12:06] lool, Do you need the action item carried, or does it belong somewhere else? [12:06] davidm, it might be though that its caused by a) the FSL kernel we use missing something or b) by the way we set up the rootfs, i wil find out both soon :) [12:06] persia: Let's keep it in the specs list, without any pointer? [12:06] I should open a dummy blueprint for it [12:06] ogra, try grepping the source for ppoll/pselect [12:07] Opening the dummy blueprint was the action item. I'll carry it over. [12:07] OK. Moving on [12:07] [topic] Roadmap review [12:07] New Topic: Roadmap review [12:07] Well what I said last week is that I would *spec* it :-) [12:07] [topic] offline-installer [12:07] New Topic: offline-installer [12:07] But it was before the OMG lot's of stuff to do [12:08] yeah, last week somewhat changed all our schedules [12:08] err, no changes [12:08] [topic] unr-handling-jaunty [12:08] New Topic: unr-handling-jaunty [12:08] like for all my roadmap items [12:08] Hm. [12:09] I'd like to move unr-handling-jaunty to Implemented [12:09] It's firmly in bug fixing mode [12:09] \o/ [12:09] What does everyone else think? [12:09] ++ [12:09] Do it then, and drop it from the roadmap. Congratulations! [12:09] :-D [12:09] yay [12:09] That leaves me with no specs in the roadmap ... [12:10] Perhaps I shouldn't have announced that. [12:10] You can surely find some bugs :) [12:10] [topic] arm-library-optimisation [12:10] New Topic: arm-library-optimisation [12:11] lool? [12:11] So some progress here; I'm working on pango1.0 and gtk+2.0 patches which should be done today [12:11] Glibc's situation looks better now: the kernel issue is sorted out and it's IS to fix the kernels [12:11] I am late in providing a final list of libs we will VFP [12:11] ffmpeg-debian will be handled specially [12:12] It was intended to be pure VFP build, but instead because the NEON opts are too hard to enable at runtime says ARM I'll look into doing a VFP + NEON build [12:12] And not using the vfp trick [12:12] It will require rebuilds of rdeps [12:13] (done) [12:13] [topic] poulsbo-packaging [12:13] New Topic: poulsbo-packaging [12:14] I've not written this up: I need to catch up with StevenK's bug, but I'm expecting to be in shape for next week, and I understand it ought be implemented in a couple more. [12:14] [topic] general-resolution-for-touchscreen-handling [12:14] New Topic: general-resolution-for-touchscreen-handling [12:14] no change as above [12:15] [topic] arm-softboot-loader [12:15] New Topic: arm-softboot-loader [12:15] No change, carry over please. [12:15] [topic] selection-of-arm-images [12:15] New Topic: selection-of-arm-images [12:15] no change as above [12:15] [topic] lpia-versus-i386 [12:15] New Topic: lpia-versus-i386 [12:15] Nothing new to report [12:16] Should we defer this to 9.10? [12:16] [topic] mobile-spec-cleanup [12:16] New Topic: mobile-spec-cleanup [12:16] [topic] lpia-versus-i386 [12:16] New Topic: lpia-versus-i386 [12:16] moo? [12:16] davidm: lpia-versus-i386? [12:16] davidm: It's already deffered to that; it needs to be done in the infrastructure before we build 9.10 [12:16] Yes, I was wondering if we should defer the questions [12:16] I think we need to have some idea prior to archive-open, so we can influence the toolchain, although I don't think it's essential until next month. [12:16] The goal is to change the opt flags just before the archive opens [12:16] Ah sorry [12:17] ignore me please sorry [12:17] [topic] mobile-spec-cleanup [12:17] New Topic: mobile-spec-cleanup [12:17] I've not taken any progress here. I'm expecting to have some time to look at it again next month. [12:17] [topic] bug#299847 [12:17] New Topic: bug#299847 [12:18] Made a little more progress [12:18] C test case? [12:18] Its an absolutely bazaar case because I can't reproduce where the race condition occurs, and if I change the perl code to remove all tests except for the one that fails, it doesn't. [12:18] Well it might be that the previous tests break the kernel or something [12:19] That's what was happening to some extent in some vfp tests in glibc [12:19] NCommander: "bizarre", bazaar is the DVCS [12:19] NCommander: Start with all tests, remove half, remove the next half etc. [12:19] Shoo, my coffee is low [12:19] StevenK: Oh you're not using bizr? [12:19] lool, which causes the nature of the failures to change and disappear :-/ [12:19] I've also had tests that cause future tests to fail in processor validation. Could be cache related. [12:20] NCommander: Stop removing tests when the failure disappear? [12:20] Well, the test suite is a framework of intermixed code [12:20] So to remove a test, you have to change the other tests to update at least for a new reference count [12:20] NCommander: In the end it's a bunch of syscalls [12:21] Yes, well, thats what I'm going to end up reimplementing. A C list of syscalls from top to bottom because I think thats the only way we're getting a C based test case [12:21] Anyway, I don't except much progress on this until after A6 freeze kicks in next week. [12:21] [topic] bug #331510 [12:21] New Topic: bug #331510 [12:22] Launchpad bug 331510 in linux "ixp4xx kernel too big to use with debian-installer on NSLU2" [High,Fix released] https://launchpad.net/bugs/331510 [12:23] Right. Seems fix released. Removing bugs from the roadmap when fixing them is nice, unless you have something to say about them. [12:23] [topic] bug #322217 [12:23] New Topic: bug #322217 [12:23] Launchpad bug 322217 in linux "ixp4xx image does not boot" [High,Fix released] https://launchpad.net/bugs/322217 [12:23] persia, eh, please reload :) [12:24] Excellent! [12:24] [topic] bug #328167 [12:24] New Topic: bug #328167 [12:24] Launchpad bug 328167 in gnome-keyring "gnome-keyring-daemon eating 100% CPU at login in Jaunty" [Medium,Triaged] https://launchpad.net/bugs/328167 [12:25] There was interspersed discussion above. Anyone have anything to add, or shall we move to the next? [12:25] well, nothig to add to this one [12:25] "Being debugged" [12:25] upstream has it, i offered more logs on request [12:25] [topic] bug #309396 [12:25] New Topic: bug #309396 [12:25] Launchpad bug 309396 in syslinux "Ubuntu UMPC boot menu is truncated" [Undecided,Invalid] https://launchpad.net/bugs/309396 [12:26] Essentially, this is an infrastructure issue only. We need to use jaunty syslinux, but have to run it under intrepid. [12:26] I've started work on a tool in perl that will do precisely that, but it will need significant testing, etc. [12:26] LOVELY: the new edit description of launchpad bugs (AJAX-ish one) is really cool [12:26] With luck, I'll have something almost-but-not-quite working by Friday. [12:26] (sorry) [12:27] [topic] bug #280669 [12:27] New Topic: bug #280669 [12:27] Launchpad bug 280669 in linux "DMA mode and driver jax10" [Low,Triaged] https://launchpad.net/bugs/280669 [12:27] persia: I find it's a bit of a waste of effort if you need to reimplement stuff because of IS constraitns :-/ [12:27] NCommander: ^ that's yours [12:27] persia: s/intrepid/hardy/ [12:27] Tested with both mainline lpia/i386 kernels, and apw's PPA kernel [12:28] lool: I don't think it's an IS constraint at all [12:28] All three can see both SSD devices [12:28] Anyway, I don't want to have this argument here [12:28] StevenK: So why can't we use the jaunty version? [12:28] With the i386 kernel, it comes up in UDMA/66 mode (no ability to change in hdparam) [12:29] apw's kernel causes it to come u pin UDMA/100 mode [12:29] lool: Because the image is constructed on a hardy machine that would be very hard to run a jaunty binary on? [12:29] NCommander: and with lpia? [12:29] StevenK: So why don't we get a jaunty chroot? [12:29] lpia was UDMA/66 (same as i386). I forgot to post the dmesg for it however, I'll do that when I get back home. [12:30] StevenK: Even if it's just for running syslinux [12:30] That seems like a machine effort rather than a human effort [12:30] [action] NCommander to post dmesg for jacx10 to 280669 [12:30] ACTION received: NCommander to post dmesg for jacx10 to 280669 [12:30] NCommander: excellent, so apw's kernel improves the DMA mode [12:30] NCommander: So we can report back that we want this patch? [12:30] NCommander: I think you want to hdparm -tT it though to confirm there's really a change and it work [12:30] ss [12:31] ++ [12:31] lool, well, the dmesg comes up differently but I can test that [12:31] (on apw's kernel vs. i386/lpia stock) [12:31] NCommander: Well if it breaks the device under high IO for instance it might be wrong to merge the patch [12:32] One would hope the hardware would prevent the IO mode from being switched to prevent breakage ... [12:32] Hardware doesn't tend to be sufficiently self-aware to have a sense of self-protection [12:33] NCommander: I just want to make sure the patch wont break anything [12:33] NCommander: Consider that we will use this info to eventually upstream it [12:33] NCommander: also, if it makes no speed difference then it might be worthless and erroneous [12:34] I can run a HDD stress test with say dd and /dev/random to see if there is an actual change. [12:34] NCommander: Yes, and I'm interested in hdparm -tT output [12:34] Actually, use bonnie++. It works great as an io stress test. [12:35] Good idea [12:35] * NCommander dislikes the notion of extreme HDD tests on an SSD [12:36] Well, it's better to burn one SSD getting it right than release something that burns thousands of them. [12:36] NCommander: We're only speaking of 5 minutes of stress [12:36] Actually, it is what I used to use to test the drivers when I was at Intel. [12:36] It's at the logic level, not at the hardware wear out level [12:36] RIght, point taken. I'll put it on my TODO, but I don't except to get it until late into next week [12:37] OK. Anything else for 280669? [12:37] NCommander, Do you need more actions? I didn't see more commitments. [12:37] Put down that I will confirm the change in performance with apw's kernel vs. stock kernels. [12:38] [action] NCommander to confirm changes in performance between apw's kernel and stock kernel [12:38] ACTION received: NCommander to confirm changes in performance between apw's kernel and stock kernel [12:38] NCommander: (it's tracked via the bug though) [12:38] [topic] bug #336770 [12:38] New Topic: bug #336770 [12:38] Launchpad bug 336770 in debian-installer "Problems Installing Jaunty On NSLU2" [Undecided,Confirmed] https://launchpad.net/bugs/336770 [12:38] well, somewhat not my highest prio item atm, but i plan to look into it next week [12:39] babbage is more important to get going now [12:39] ogra, Do you need an action, or is roadmap sufficient? [12:39] roadmap is enough [12:39] well, doesnt matter really, we wont meet before A6 [12:39] ogra, it might be just that flash-kernel is in universe vs. main (I dunno if d-i calls it) [12:39] i would like to fix it for A6 but its a matter of time i can put in, the slug install simply are massively time consuming [12:40] and the error only shows up at the very end [12:40] Well, that naturally segues into [12:40] [topic] NSLU2 enablement [12:40] New Topic: NSLU2 enablement [12:40] NCommander, yes, thats what i suspect, but i havent confirmed yet [12:40] persia, right [12:40] Is this accurately covered by bugs at this point, or does it still need a special item? [12:40] but since two days babbage enablement is higher prio on my list [12:41] which includes the keyring daemon hang and images [12:41] Maybe you want to add Babbage enablement to the roadmap? [12:41] Makes sense [12:41] * ogra adds [12:42] [topic] ARM Benchmarking [12:42] New Topic: ARM Benchmarking [12:42] bah, lool owns it [12:42] done [12:42] " OliverGrawert, LoicMinier, Michael Casadevall " on it [12:42] yep [12:42] saw that [12:42] I'd rather just have one person who is responsible for commenting in the meeting, but that's just because it makes running the meeting easier :) [12:43] well, we share the load on different levels [12:43] ALl ARM bencharmsk for ARMv5, and ARMv6 done except two graphical ones on ARMv6 (due to monitor issues back home) [12:43] and share the work, each of us works on different parts [12:43] I'll see if I can get that done sometime soon since the benchmarks left to run take a few minutes, but I need a working console. [12:43] NCommander, So results are expected next week or so? [12:43] persia, results have been up for ages. [12:44] Well, except for the two graphical ARMv6 ones :) [12:44] Anyway... [12:44] the ARMv7 benchmarks is depwait on loic's ec2 spec, unless someone else has an idea how to do an archive rebuild. [12:44] [topic] Babbage enablement [12:44] New Topic: Babbage enablement [12:44] slow progess ... [12:44] good progress here :-) [12:44] painful progress ... [12:44] waiting on the kernel package [12:45] I managed to create SD card images which work on any size of cards which the ROM will take [12:45] will work on getting a casper initramfs going today [12:45] ogra, that won't fly without a merged kernel [12:45] and with luck even boot the suashfs [12:45] Baseline doesn't have AuFS [12:45] *squash [12:45] With a partition protecting the redboot + fis with kernel and initramfs and config [12:45] I'm working on removing the need to run redboot to achieve that [12:45] NCommander, getting into an initramfs prompt is my first target atm [12:45] in a casper initramfs [12:46] ogra, I sent you what I know about running an initramfs [12:46] that wont need aufs [12:46] lool, if I known you had that progress, I would have made sure FSL had known [12:46] NCommander, right [12:46] I found a fconfig utility and a fis utility and am trying them out; the goal is to generate the image with the fis and update the config with fconfig [12:46] * NCommander is not doing well with get genernal configuration blackout [12:46] s/configuration/communication/g [12:47] I think we need to break it down on where each component stands w.r.t. to enablement (all of us typing at once made that very confusing) [12:47] Indeed. [12:47] Lets go from the top down [12:47] RedBoot [12:48] lool, care to fill us in what you managed to do specifically and what's left to do? [12:48] We're tight on time. [12:48] Rather, could one of you take charge, and put together a wiki page with all the bits, and link to it? [12:48] NCommander: Not really, I prefer moving forward and doing the doc pass in the end [12:48] That makes it easy for us to go through status quickly next week. [12:48] I'm taking notes, but I don't want to document perfectly the intermediate attempts [12:49] lool, I understand that, but I need to take that to FSL, and say what we've done; we have duplication of effort ATM. [12:49] What I had to say as an updated I said already: I can now create a SD image with just RedBoot and a kernel as input, but I still need to run RedBoot on the babbage [12:49] I'm working on removing that requirement [12:50] I managed to build the target layout which we will use in the released image [12:50] Now I need to make that fully automated without the need of a babbage board [12:50] What's missing is a redboot binary built by ourselves from source [12:50] preferably packaged [12:50] That's on NCommander's plate [12:50] but worst case we could go with a binary blob from restricted, no ? [12:50] And work on the contents of the rootfs; currently I'm running a plain Ubuntu install on it and it works fine [12:50] if everything fails [12:51] (manual debootstrap) [12:51] ogra, no, GPL problem. [12:51] NCommander, we can provide the source on request [12:51] ogra: If we confirm we can really build it [12:51] ogra: How can you tell your sources are the sources? [12:51] That last bit probably won't happen for A6, but I think I can build the binaries before then, then focus on getting everything packaged and promoted. [12:51] lool, yeah, indeed [12:52] lool, but as a last resort a package with binary blob and the sources separately can do [12:52] indeed we need to build it once [12:52] i'm counting on NCommander here :) [12:52] I've managed to build it once, in a dream :-/ [12:52] 8 minutes [12:53] So again, could one of you volunteer to drive the coordination, and report on it in the meeting? [12:53] Oh you mean single reporter? [12:53] I'm happy to report to someone so that he can report here [12:53] That ought make the meeting go more smoothly. [12:54] * ogra takes that [12:54] [action] ogra to take charge of Babbage enablement [12:54] ACTION received: ogra to take charge of Babbage enablement [12:54] So, that concludes the roadmap. [12:54] [topic] Discuss moving meeting time to be more convenient for those in UTC-5 through UTC-8 [12:54] New Topic: Discuss moving meeting time to be more convenient for those in UTC-5 through UTC-8 [12:55] for the IRC meeting ? [12:55] So, there's been some requests from people in UTC-6 and UTC-8 that this meeting is far too early in the morning. [12:55] (and UTC-5 :-P) [12:55] Nobody in UTC-5 complained to me :p [12:55] * ogra wasnt aware we wanted to shuffle that as well [12:55] We have daylight savings changes happening world wide over the next weeks [12:55] * GrueMaster doesn't recall complaining. [12:55] US is this weekend [12:56] * ogra didnt complain [12:56] So, when do we want it? [12:56] Does anyone know when all of the changes are complete? [12:56] I don't care much if it stays one hour long and close to this time [12:56] It's lunch time no matter what, but that's ok [12:56] ++ [12:57] Personally, I see most activity from Australia, the Americas, and Europe, so I'd suggest something like 20:00 UTC or 21:00 UTC. [12:57] Australia doesn't switch until April [12:57] Except for Western Australia, but they don't count [12:57] Wow it's an entire month this year to convert over [12:57] Australia is in Summer and they walk on their hands, I don't see how we can do anything for these people [12:58] lool: Remind me to punch you in the kneecaps when I see you [12:58] davidm: What happens if we keep the current UTC time? [12:58] StevenK: To force me to walk on the hands? [12:58] Actually, not converting at the same time is a good thing. I remember a meeting moving by two hours Australian time once because the people in the US didn't want to change. [12:58] lool: No, because I can't reach your shoulder [12:58] It's fortunate I'm not smaller, or you would have hit higher than the kneecaps [12:58] In the US it's an hour "nicer" to waking up [12:58] So, we're *really* tight on time. Anyone opposed to 20:00 or 21:00 UTC? [12:59] StevenK, his kneecaps might not agree with his heads opinion ... be careful :) [12:59] No objection, that would be an improvement for us US folks. [12:59] 20UTC is a little early for me [12:59] persia: that's far from now [12:59] lool, meeting would move to 07:00 central time but that is still 05:00 for -8 [12:59] StevenK needs his beauty sleep. [12:59] lool, 21:00 is nine hours. [13:00] StevenK, what time is 20 UTC local for you? [13:00] What about two hours later, 2pm UTC [13:00] davidm: 7 am [13:00] 6am come April [13:00] StevenK, that beats waking folks at 05:00 [13:00] Is 21:00 better? [13:00] * persia fails to do the math for UTC+9 [13:01] Hah [13:01] davidm: 8am and then 7. Still makes me say ick :-) [13:01] StevenK, you should try being in central time [13:01] Hey why don't you folks move to France? [13:01] Or PST [13:01] Yea, but it's quite a lot better then 05:00 or earlier [13:01] NCommander: I like living in tomorrow, you're living in the past. [13:01] or germany [13:02] StevenK, I don't have 24 hour+ flight times to go anywhere :-) [13:02] NCommander: Yes, you do. Try flying to Auckland or Sydney [13:02] lool, personally, I want to move to Alaska .... but that won't do anything good for our call time. [13:03] Alaska is still -8 or is it -9? [13:03] -9 [13:03] -10/-11 in some areas. [13:03] and Hawaii is -10 [13:03] Personally, I vote for monthly face to face meetings in Australia. Hawaii would work too. [13:04] So late UTC is probably the best choice [13:04] Which is middle of the night for asia where we have nobody, as persia pointed out recently [13:04] lool, nobody yet. [13:05] Right. So it's really between 20:00 UTC which can be 6:00 in Australia or 21:00 UTC which can be 23:00 in Europe. [13:05] And it's the middle of the day in the US? [13:06] Yes. [13:06] ~lunch time here. [13:06] GrueMaster, You get no sympathy for that. [13:06] none needed. [13:06] My office is 5 feet from food. [13:07] StevenK, what time will 21:UTC be in a month local? [13:07] you work in your kichen ? [13:07] Your office is in the kitchen? [13:07] * StevenK glares at ogra [13:07] snap :) [13:07] I'm not hearing consensus, and we're overtime. [13:07] next too the kitchen. [13:07] davidm: 6am [13:07] [action] meeting time discussion to be deferred to next week [13:07] ACTION received: meeting time discussion to be deferred to next week [13:07] Please consider it, and let's review again then. [13:07] Good enough [13:07] [topic] Any other business [13:07] New Topic: Any other business [13:08] persia, thanks for running meeting [13:08] persia: thanks for chairing [13:09] I'm not hearing anything. If you have anything, please add it to the agenda for next time. [13:09] #endmeeting [13:09] Meeting finished at 07:09. [13:09] thanks [13:09] * GrueMaster drags his carcass back to the cave. [14:03] Who's here for the Java Meeting? [14:03] o/ [14:03] * sommer is loitering out of curiosity [14:04] OK. Meeting agenda is (as always) at https://wiki.ubuntu.com/JavaTeam/Meeting [14:04] Nobody raised any special items. [14:05] robilad doesn't appear to be present. [14:05] slytherin doesn't appear to be present. [14:05] ttx, Any updates for maven? [14:06] persia: no. I intended to have a look at the current state in Debian but haven't had time to [14:07] as a reminder, we decided to follow Debian work on this, and contribute missing libraries where appropriate [14:08] Right. Do we still need it as a Roadmap item if we're not actively chasing it? [14:08] persia: I would say no. [14:08]