=== txwikinger4 is now known as txwikinger === thekorn is now known as thekorn_ === Nicke_ is now known as Nicke [11:01] moop === mcasadevall is now known as NCommander [11:59] RIght. Time for the Mobile Meeting. [12:00] * NCommander waves [12:00] #startmeeting [12:00] Meeting started at 07:00. The chair is persia. [12:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:00] Agenda is [LINK] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090319 [12:01] [topic] persia to investigate 338148 [12:01] New Topic: persia to investigate 338148 [12:01] At the last meeting we thought this was a simple merge. It's more than that. I've been looking at it, but don't have all the bits in my head yet. I'll need it carried over. [12:01] [topic] NCommander to post dmesg for jacx10 to 280669 [12:01] New Topic: NCommander to post dmesg for jacx10 to 280669 [12:02] please carry over, been working all week on Redboot [12:02] [topic] lool to spec ec2-package-builder for jaunty+1 [12:02] New Topic: lool to spec ec2-package-builder for jaunty+1 [12:03] lool ? [12:04] No progress [12:04] [topic] ogra to trim selection-of-arm-images to a smaller scope [12:04] New Topic: ogra to trim selection-of-arm-images to a smaller scope [12:05] carry over [12:05] as well as the next one [12:05] babbage kernel issues kept me busy [12:05] Right. That takes us to roadmap. [12:05] [topic] offline-installer [12:05] New Topic: offline-installer [12:05] same status [12:06] [topic] mobile-setup-wizard [12:06] New Topic: mobile-setup-wizard [12:06] no progress [12:06] [topic] arm-library-optimisation [12:06] New Topic: arm-library-optimisation [12:07] lool, ? [12:08] Progress but need to file FFE and blocked by betafreeze now [12:09] move to next item please [12:09] [topic] pouslbo-packaging [12:09] New Topic: pouslbo-packaging [12:09] I still need to document stuff: the plan is changing a bit, but it's still not working well enough to use properly. [12:10] WTF [12:10] ogra, ? [12:10] why is offline-installer a drupal project now ? [12:10] Because of a launchpad bug. [12:10] ah [12:10] Just ignore that for the moment :) [12:10] Moving on... [12:10] hard if you want to look at your specs :P [12:11] Yes. I expect we can get manual resolution of the outstanding ones in the next couple weeks. [12:11] [topic] general-resolution-for-touchscreen-handling [12:11] New Topic: general-resolution-for-touchscreen-handling [12:11] no progress [12:11] [topic] arm-softboot-loader [12:11] New Topic: arm-softboot-loader [12:11] No progress [12:11] [topic] selection-of-arm-images [12:11] New Topic: selection-of-arm-images [12:12] NCommander: You're looking into kexec soon though [12:12] slow progress, started the automatic image builder script for the babbage image today [12:12] but currently blocked on broken kernel [12:12] lool, true. [12:13] [topic] lpia-versus-i386 [12:13] New Topic: lpia-versus-i386 [12:13] nothing new to reprot [12:13] [topic] mobile-spec-cleanup [12:13] New Topic: mobile-spec-cleanup [12:13] status unchanged [12:13] [topic] bug #299847 [12:13] New Topic: bug #299847 [12:13] Launchpad bug 299847 in linux "Shared memory operations on very fast ARM hardware suffer from non-atomic operations and race conditions." [High,Triaged] https://launchpad.net/bugs/299847 [12:13] No progress [12:14] [topic] bug #328167 [12:14] New Topic: bug #328167 [12:14] Launchpad bug 328167 in gnome-keyring "gnome-keyring-daemon eating 100% CPU at login in Jaunty" [Medium,Triaged] https://launchpad.net/bugs/328167 [12:14] i need to rebuild from source onm upstream request [12:14] but need my babbage for other stuff atm [12:14] ogra, Do you want an action item for that, or is roadmap sufficient? [12:15] will do that once i have my hands off the image builder scripts [12:15] sure, make it an action item [12:15] [action] ogra to rebuild gnome-keyring-daemon to troubleshoot 328167 [12:15] ACTION received: ogra to rebuild gnome-keyring-daemon to troubleshoot 328167 [12:15] [topic] bug #280669 [12:15] New Topic: bug #280669 [12:15] Launchpad bug 280669 in linux "DMA mode and driver jax10" [Low,Triaged] https://launchpad.net/bugs/280669 [12:16] No progress. [12:16] [topic] bug #336770 [12:16] New Topic: bug #336770 [12:16] Launchpad bug 336770 in linux "Problems Installing Jaunty On NSLU2" [Undecided,Fix released] https://launchpad.net/bugs/336770 [12:16] * persia removes it from the roadmap [12:16] reload your wikipage :P [12:16] Let's drop that one? [12:17] its gone already [12:17] ogra, I reload before nearly every topic, and I skipped once, and you got me :) [12:17] * ogra removed it at the start of the meeting [12:17] [topic] bug #338148 [12:17] New Topic: bug #338148 [12:17] Launchpad bug 338148 in vnc4 "Needs new version from Debian: fails to build with removal of mesa-swx11-source" [High,Triaged] https://launchpad.net/bugs/338148 [12:17] fix your proxy :) [12:17] I've already got a carried over action item on it: needs more merge effort (different versions). [12:17] [topic] NSLU2 enablement [12:17] New Topic: NSLU2 enablement [12:18] works :) [12:18] could surely need some extra love [12:18] like tasksel adjustments and the like [12:18] Do you still want a roadmap item? Will more discussion or tracking help? [12:18] but really not in scope atm [12:18] well, if we see regressions i could report on it [12:18] OK. Let's leave it then. [12:19] [topic] Babbage enablement [12:19] New Topic: Babbage enablement [12:19] so leave it there, i can easily nod it off every meeting [12:19] RedBoot for Babbage board has been packaged [12:19] amit is working on the merged kernel configs [12:19] Its sitting in universe, pending MIRs [12:19] redboot and friends are packaged by NCommander [12:19] debian-installer-imx51-netboot has just been successfully started. [12:19] NCommander, hey, my duty ! [12:19] ogra, the installer or the news? [12:20] (leave the reporting to me and just add stuff i miss) [12:20] * NCommander goes mute [12:20] else it gets to confusing [12:20] lool is working on the fconfig scripts [12:20] we miss installer, either d-i or ubiquity, and that implies a good scenario for install still; some candidates have been discussed [12:20] i am working on the autobuild scripts atm [12:20] Depending on what works and on the final scenario, we need differing bits [12:21] we're currently hit hard by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/344370/ [12:21] flash-kernel integration is likely to be needed if we can't get a kexec solution to work [12:21] What support do we need in d-i outside the kernel? [12:21] Ubuntu bug 344370 in linux "imx51 AppArmor oops during bootup" [Medium,In progress] [12:21] Is it just kernel selection, or is something else broken? [12:21] persia, a bootloader udeb or some such [12:21] persia: We don't build any netboot image for babbage ATM, and I would think a SD image would be useful [12:21] ogra, we have a redboot udeb [12:21] We do? [12:21] Cool [12:22] Yeah, I figured you might want it so I saved some work and did it all in one go [12:22] https://bugs.launchpad.net/bugs/344955 sopped me form working forward the last three days [12:22] (much to the confusion of the poor REVU reviewers) [12:22] but its fixed now [12:22] Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/344955/+text) [12:22] OK, so the redboot udeb can give us an alternate image, and we can make an SD live image. [12:22] Then you also need some d-i logic for the redboot udeb, currently it only provides files [12:22] right, we need lools scripts [12:22] IOW we need a story for the d-i install as well [12:22] lool, it needs to be in the udeb build-deps, and then have the arch-image target glue all together, and get out a bin blob like NSLU2 [12:23] thats silly [12:23] lets just do a real alternate image [12:23] instead of netboot [12:23] ogra: netboot is trivial and is useful for people using various scripts [12:23] ogra, sure, I can add a cdrom target easily, netboot images are easy to do [12:23] We don't need it, but it would be the first thing I'd add [12:23] I already booted the imx51 netboot initrd [12:23] If we have alternate, netboot isn't significantly more work. [12:23] * NCommander hasn't run the install yet. [12:24] persia, other way round [12:24] ogra, either way :) [12:24] netboot is easier but not a good fallback if we fail live [12:24] Right. [12:24] so i'D like to se the focus on alternate [12:24] I don't think live is an issue, as long as we pick the right kernel. [12:24] ogra, netboot is three lines of code to get a initrd [12:24] in cae we hit issues with ubiquity we didnt foresee [12:24] In many ways, live is easier to do than alternate, because not as much of d-i is involved. [12:25] but live install isnt yet [12:25] Let's not debate netboot, it's not the target and will be done if anybody touches d-i because it's trivial [12:25] its easy up to the package install [12:25] but the final step to make the install bootable only exists theoretically yet [12:25] and we might hit issues we didnt expect [12:26] My main concerns for *either* install is a) getting partitioning right and b) installing redboot and flash-kernel properly if needs be [12:26] so i'd like an alternate image as a safety net [12:26] OK, so essentially we need the glue that installs the bootloader somewhere (which isn't grub)? [12:26] our target is to have a milestoneable image [12:26] Right. [12:26] which netboot isnt (and cant be) [12:27] ogra: Isn't that what we released for A5/verstaile? [12:27] so lets leave netboot as a nice to have [12:27] lool, netboot ? [12:27] ye [12:27] s [12:27] yes [12:27] It's at least something [12:27] but was considered not sufficientr [12:27] management request was a fixed milestoneable image [12:27] no netboot [12:28] for release [12:28] which is why i'd like to see NCommander working on a,ternate instead of netboot [12:28] so we have a fallback in case ubiquity fails [12:28] ogra, netboot already exists [12:28] let's forget netboot [12:28] right [12:28] ogra, just so I can fix the partitioning and flash-kernel, and then just drop the cdrom bits in. [12:28] * NCommander doesn't want to write a 700MB image just to test the installer. [12:29] but thats what we're supposed to have [12:29] ogra, let me rephrase [12:29] While we're developing the installer variant [12:29] NCommander, The trick is to just replace bits in the 700MB image with each iteration of installer work. I'd be happy to help you with workflow. [12:29] you will need significant cjhanges tro the cdrom detection code [12:29] to work from SD [12:29] ogra, we do? [12:29] Oh [12:29] No, we can use the cf variant [12:29] so please test with a real d-i image [12:30] if you can do that, thats fine, but please test it [12:30] ogra, to build alternates, I need access to cdimage.u.c [12:30] I can't build a full image on 127.0.0.1 with just the d-i package unless I'm mistaken. [12:30] NCommander, No you don't. After the meeting, let's chat about image construction. [12:30] fair enough. [12:30] [action] persia & NCommander to review workflow for testing alternate images. [12:30] ACTION received: persia & NCommander to review workflow for testing alternate images. [12:31] Anything else for Babbage enablement? [12:31] NCommander, http://cdimage.ubuntu.com/ports/daily/current/ [12:31] there are alternate images [12:31] use and modify them [12:31] OK. Moving on then. [12:31] [topic] ARM benchmarking [12:31] New Topic: ARM benchmarking [12:32] I think no progress [12:32] we anyway only need it as a base for KK [12:32] NCommander, ? [12:32] so its not milestone critical or something [12:32] sorry, no progress (no ARMv7 build) [12:32] OK. That concludes roadmap review. [12:32] just has to be there at release [12:33] We've one topic on the agenda that's been pending [12:33] [topic] Discuss moving meeting time to be more convenient for those in UTC-5 through UTC-8 [12:33] New Topic: Discuss moving meeting time to be more convenient for those in UTC-5 through UTC-8 [12:33] but still not all team members [12:33] No, but those absent fall into the range that's inconvenient. [12:33] same prob as last week [12:33] I thoughtthe idea was to wait for DST world wide. [12:33] Then shift. [12:33] I don't want to discuss this without david anyway [12:33] Given that the previous discussions were talking about times that would be inconvenient for all of those present, let's find the least inconvenient one. [12:34] OK. We'll carry it over another week then, and the next meeting will be at this time. [12:34] Anyone have any last minute additions to the agenda? [12:34] Action Reports are due NOW. [12:35] GrueMaster, you got mine. [12:35] GrueMaster: you're good! [12:35] heh [12:35] Ok, /me lunch & [12:36] OK. Meeting adjouned then. Thanks everyone. [12:36] #endmeeting [12:36] Meeting finished at 07:36. [13:54] * persia peers about [14:01] So, who's here for the Java meeting? [14:01] \o/ [14:01] Right. We need a bigger team :) [14:02] Nothing new on the agenda. [14:02] robilad isn't here [14:02] come on everyone, java is fun ! Or not. [14:02] slytherin isn't here [14:02] I didn't file the SRU for sun-java5 yet, so we can't drop it. [14:02] ttx, Any progress on Java-Contents? [14:02] yes, ! [14:03] So I finished the script and ran it through intrepid [14:03] documented here: https://wiki.ubuntu.com/JavaTeam/JavaContents [14:03] I will add a few examples to the docs, run it through current Jaunty [14:04] but I already accpt feedback / bugs in the script [14:04] Cool! [14:04] Could you add a link to that on the Roadmap? [14:04] I might create a project in LP rather than just a +junk branch [14:04] so that bugs can be filed against it [14:05] sure, i'll link it from the roadmap and the knowledge base pages [14:05] it's interesting to see unneeded code duplication as well [14:05] roxen4 in the example [14:06] anyway, that's a good tool for every Java packager [14:06] I know I've been missing something like that a lot during this cycle. [14:07] It's also a good tool to use to clean up. [14:07] We likely don't need all of that: I'd hope we could drop it from both roxen and glassfish in your example. [14:07] I'm sure we have *many* more. [14:07] oh yes, I picked javax.servlet by accident. [14:09] ludovicc: welcome, we were talking about https://wiki.ubuntu.com/JavaTeam/JavaContents [14:09] Dunno if it needs an LP project. Might make sense to add it to one of the developer tools packages. [14:09] Something like ubuntu-dev-tools or javahelper. [14:09] ludovicc: a mapping file that shows package/jar/classes contents in a release [14:09] persia: i'll try to find a good match [14:10] there isn't much point in regenerating it yourself though. takes time [14:10] there are ~800 packages containing jar files. [14:11] and more coming up :) [14:11] i'm not familiar with JavaContents, but it looks like it may duplicate the information you can get from Maven descriptors [14:11] I wonder if it's worth asking the archive-admins to add it to the scripts they run against the archive on a scheduled basis, and just referencing it. [14:12] ludovicc, It would, except that it also covers stuff that isn't maven. [14:12] persia: once it's debugged, might make sense, yes [14:12] lots of stuff is not Maven, yet even those have POM descriptors describing them [14:13] available on online Maven repositories [14:13] ludovicc, Ah. I see. The difference is that JavaContents provides a report on the contents of the Ubuntu archive, so we can detect duplication, etc. [14:13] We could probably run the same thing against Debian. [14:14] Until all the packages have been updated to include POM descriptors, it's a different view. [14:14] ok, so that's more like a tool for keeping the repository clean [14:14] In fact, one could probably use JavaContents to help identify what should be added for POM descriptors. [14:15] Well, and finding out on which package one needs to depend or build-depend when packaging. [14:15] ludovicc: it also helps in determining in which debian package is defined a given class [14:15] for example I've been looking for javax.faces [14:15] difficult to be sure it's not already provided *somewhere* [14:15] that would be good yes, but there are alternative solutions as always [14:15] with javaContents, I have the answer [14:16] the nice thing with this idea is snice you work with classes and packages, not with jars, it can work out very nicely with OSGi [14:16] so why not? [14:17] that's all on that subject [14:18] OK. Next up: attracting more Java packagers [14:18] OSGi uses package names to locate services and organize classloaders [14:18] persia: so I've been looking at missing libraries... apparently Maven in debian is now ready (ludovicc could confirm) so all basic libs/plugins have been added [14:19] many of them, but it's far from complete [14:20] ludovicc: do you have a list somewhere in debian of missing pieces ? [14:20] only 5 or 6 plugins have been packaged, there are dozens yet to package [14:20] ludovicc: the idea is that if we have some Java packagers wanabees we want to point them to a list of things they can do [14:20] (and contribute back to Debian) [14:21] I also wanted to run a few Java lib packaging classes, where that list could be used [14:21] no list, but it's easy to get it: compare the list of plugins on the Maven site with what's in the pkg-java svn repo [14:21] so you'd say what's missing are maven plugins ? [14:21] ludovicc, Do you think it would make sense to file a collection of RFPs for those, and for us to put out a call for Java packagers to tackle them? [14:22] that would be a good idea, but before I would like to be clear with Torsten Werner about the strategy for packaging Maven and its POMs [14:23] it's almost there though, so we can get started on that [14:23] I mean the RFP [14:23] ludovicc: ok [14:24] ludovicc, That sounds reasonable. Would you be able to get back to us next week about the strategy? [14:24] I'm sure ttx or I could find the time to file lots of bugs, and then put out the call. [14:24] hopefully yes, if I can get Torsten to work with me, he seems busy now [14:25] but anyway I have already a lot working on my side, if you could try it and give me your opinion, that would help [14:26] check https://code.launchpad.net/uj and https://code.launchpad.net/maven-packaging-support [14:26] lp:~ludovicc/maven-packaging-support/maven-repo-helper contains a tool for including Maven POMs into normal Java library packages [14:27] ludovicc: I seem to be confused on how complementary the work of Torsten and yours are [14:27] Torsten is working on a pure Maven solution, where you use Maven to build your package [14:28] I'm trying to complement this to provide Maven POMs for those many libraries not built with Maven [14:29] those POMs will then be placed in /usr/share/maven-repo, and used when building Maven projects dependent on external libraries [14:29] ok [14:30] so lp:~ludovicc/uj/junit and lp:~ludovicc/uj/modello are an exemple of those Maven-enabled libraries [14:30] I hope to get agreement from Torsten soon, and merge this work to Debian [14:31] that would be great. [14:31] ludovicc: do you plan to come at UDS ? [14:32] now I've got time, but no money... [14:32] that's why sponsoring is (was) for :) [14:32] missed it... [14:35] persia: anything else ? [14:37] I don't have anything. [14:37] ludovicc, ? [14:37] I started some time ago a guide for packaging Java libraries [14:37] https://wiki.ubuntu.com/JavaTeam/KnowledgeBase/Packaging [14:38] ludovicc: I wrote one too. [14:38] https://wiki.ubuntu.com/JavaTeam/LibraryPackaging [14:38] yeah, I saw it [14:38] mine is more Debian-packager oriented [14:39] "here are the differences in Java" [14:39] yours is more step-by-step [14:40] mine is more Java oriented (for the guy who know naught about Debian), but still very incomplete [14:40] it's based on the Python packaging guide, I'm sure we can do as well for Java [14:41] Those look nicely complimentary. [14:41] ludovicc, Do you need help, or just more time? [14:42] I need more time, but if you want to help, feel free to edit. [14:44] heh :) [14:44] OK. Anyone have anything else? [14:44] no [14:44] no [14:47] see u folks [14:48] bye ludovicc, thanks for coming ! === Ampelbein is now known as ampelbein === Lure_ is now known as Lure === fader is now known as fader|lunch === fader|lunch is now known as fader === beuno_ is now known as beuno === Sp4rKy is now known as Guest71433 === beuno_ is now known as beuno === pgraner is now known as pgraner-errands === calc_ is now known as calc === asac_ is now known as asac === claydoh_ is now known as claydoh