=== ianmcorvidae|alt is now known as ianmcorvidae === _neversfelde is now known as neversfelde === asac_ is now known as asac [11:59] Hmm I wasn't here for some reason [12:00] a good reason ? [12:00] There is no good reason [12:00] * lool waves [12:00] * StevenK shores [12:00] * persia quashes humor [12:00] * Hobbsee hands out life jackets [12:00] * ogra coughs [12:01] Folks, I'll have to leave earlier today (need to go to the dentist for 2pm) [12:01] OK. Let's get started. [12:01] #startmeeting [12:02] Agenda is at https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090122 [12:02] Last week's action items: [12:02] ogra, Can we close the touchscreen spec item? [12:02] yep [12:03] Cool. [12:03] lool, You had an action item to finish specs. Do you still need that? [12:03] My specs: done except for recovery-partition where I have to collect some input from 2 people [12:03] persia: it's ok I don't need if I can grab you to review the r-p one [12:03] And I had an action to make sure all the specs had a driver, which I put in the Roadmap. [12:03] So, action items closed. [12:03] * ogra would like to see StevenK reviewing the arm-image spec ... since he has to do half of the implementation :) [12:04] Next up: Roadmap. [12:04] Err? [12:04] oh, i jumped ahead :) [12:04] Nobody added status to anything as we thought we might last week, so we'll go through them quickly. [12:04] Since lool is leaving early, let's do his first [12:04] mid-display-manager [12:04] Spec completed with your review; now needs approval and implementation [12:05] lpia-versus-i386 [12:05] Spec completed with your review; now needs approval and perhaps discussion with Foundation folks [12:05] OK. You want an action for the discussion? [12:05] To see if we can make something useful out of lpia; otherwise we keep it as documentation and lpia remains in maintenance mode [12:05] not kernel folks as well ? [12:05] persia: If you like [12:06] ogra: The kernel is orthogonal to the architecture [12:06] well [12:06] It's just named lpia for confusion [12:06] heh [12:06] lool, Are you expecting to do it for next week, or is it a long-term thing? [12:06] we're good at that [12:07] I have no problem with you guys changing the lpia compiler flags as long as you don't expect us to recompile the whole archive all at once [12:07] persia: I might or might not do it next week depending on availability, but I expect it will not be possible to change toolchain stuff before jaunty+1 [12:07] * persia doesn't file an action [12:07] cjwatson: I was expecting this should be deferred to jaunty+1 [12:07] cjwatson: I had in mind to setup a meeting with doko and you to discuss these [12:07] sure, or you could just talk to doko directly, he knows the field better than I [12:08] Ok [12:08] cjwatson: Do we have rebuild testing on lpia? I guess not [12:09] My fear if we change the flags is that we might have some bad surprizes when we actually need to upload random stuff at the end of th cycle or in upadtes [12:09] Anyway, will bring it up with doko [12:09] lool, That could be probably be arranged on the ubuntuwire rebuild tester, with appropriate scheduling, if we don't mind a chroot'd buildd. [12:10] Next up: recovery-partition [12:10] I don't think we'd mind [12:10] To finish spec-ing of r-p I need to try out superm1's USB image and discuss some implementation details with Evan [12:10] lool: I thought we did but am not sure; infinity would know [12:11] or ubuntu-installer at large; but I suspect a one to one will be more effective and he attended [12:11] cjwatson: Okay thanks [12:12] Going back to the order on the wiki page [12:12] offline-installer: ogra [12:12] (I dropped Adam an email) [12:12] in progres [12:12] s [12:12] Issues, concerns, needs from others? [12:13] http://people.ubuntu.com/~ogra/arm/build-arm-rootfs had a lot of community testing and i plan to make something like that the backend for the armel offline builds [12:13] I thought the dailies would be the backend ... [12:13] Speaking of [12:13] i have to try out the other arches [12:13] * StevenK digs up the livefs build logs [12:14] StevenK, thats arm-only images and the tool i write for that one will only merge livefs with kernel [12:14] offline installer will leave you with a configured system image [12:15] (user set up, hostname, timezone, kbd and language configured) [12:15] Bleh! evolution is broken [12:15] while the liveimages will start into a live session [12:15] StevenK: News@11 [12:15] :-P [12:15] and you have to run ubiquity [12:15] I knew the armel livefs log would be a train wreck [12:15] * StevenK tickles lool [12:16] StevenK: I already fixed that [12:16] * lool giggles [12:16] it's rebuildng [12:16] +i [12:16] cjwatson: Ah. I was going to check, but cool. :-) [12:16] it wasn't evolution's fault directly, it was due to a Soyuz bug that's also being fixed [12:16] any other questions for offline-installer ? [12:16] cjwatson: It should finish in time for the 20090128 daily build? :-P [12:17] persia, ? [12:17] did you fall over ? [12:17] ogra, No, just waiting for discussion to settle before moving on. [12:17] ah [12:18] StevenK: what's significant about 28? [12:18] cjwatson: It's six days away :-P [12:18] unr-handling-jaunty: StevenK [12:18] this morning's livefs build got stuck on a lock, but elmo poked it [12:19] anyway, the short answer is "I'm paying attention and sorting things out iteratively" [12:19] persia: In progress, waiting for code drops, etc, hand wave [12:19] StevenK, Need anything? Blocked on anything? [12:19] cjwatson: I know, I'm poking fun. :-) [12:19] persia: Yes, more hours in the day. Please fix. [12:20] * persia adds "searching for another timezone" to the todo list [12:20] StevenK, thats solvable by staying in motion [12:20] mid-application-switcher: persia [12:20] just hop timezones [12:20] Spec is mostly complete. I need to coordinate with njpatel to get the specifics for implementation. [12:20] mobile-setup-wizard: persia [12:21] Yet entirely untested. Expecting to get initial results this week [12:21] [ACTION] persia to get initial results for mobile-setup-wizard [12:21] wasnt that just oem-config for small screens ? [12:21] mobile-team-seed-management: StevenK [12:21] ogra, Yep. Needs testing though. [12:21] ah [12:22] persia: I'd like to whinge about moving the seeds, but other than that [12:22] I like them in -core-dev. They're happy in -core-dev. :-P [12:22] StevenK, Well, whinge all you want. Delay as long as you like. I think it's required to integrate with ArchiveReorg, but that can follow that schedule. [12:22] (until there is no core-dev) [12:23] ship-seed-for-mobile-images: StevenK [12:23] Implemented. [12:23] May require tweaks and such, but it's done. [12:23] persia: Let's have a last status column on the roadmap and stop bringing up the implemented specs according to their "last status" [12:23] Or just a status column actually [12:24] Unless someone wants to [12:24] lool, Once something is all done, I thought we'd just remove it. [12:24] persia: Hmm okay [12:24] NCommander, You're listed as ship-seed-for-mobile-images drafter: could you update the Test/Demo plan and get this tested so it goes away? [12:25] Sure I can do that [12:25] [ACTION] NCommander to take over driving ship-seed-for-mobile-images to close it [12:25] general-resolution-for-touchscreen: ogra [12:26] xorg team notified me that the right evdev and hal changes are in [12:26] spec pending approval [12:26] persia: Ah, excellent. [12:26] gui implementation pending [12:26] persia: (ship-seed-for-mobile-images) [12:26] arm-softboot-loader: NCommander [12:27] Ugh, hit a serious snag, since I no longer believe kboot can meet our needs, even if we were extensively to hack it [12:28] NCommander, erm ? [12:28] would you elaborate ? [12:28] It uses /etc/fstab vs. autodetection to find devices, and full access to the busybox shell is provided due to the nature of implementation (i.e., I can type ls at the kboot prompt, and it works) [12:28] * NCommander is typing :-P === ember_ is now known as ember [12:28] NCommander: I think you need to debunk kboot in your spec and move on to petitboot if it's any better [12:29] petitboot is based on kboot [12:29] same problem. [12:29] I know [12:29] What I don't know is how much kboot remains in petitboot [12:29] * ogra doesnt see the problem ... you can ls in initramfs as well if you boot with break= statement [12:29] If you tell me too much, just list petitboot as a non-option as well [12:29] I'll look at it, but getting petitboot down to 1.5MB is going to be extremely difficult [12:30] NCommander: What matters is finding the best existing base to start from IMO [12:30] ad autodetection is fixable via a minimal initramfs containing libvolid [12:30] Ok it's cut off time for me; /me goes teeth rebrushing [12:31] Sounds to me like this spec needs deeper review. [12:31] well, re-drafting at least [12:31] [ACTION] NCommander to reset arm-softboot-loader to "Drafting" and work towards a solution in #ubuntu-arm over the next week. [12:31] persia, yup; I didn't know about the kboot issues when we started writing it, I only recently got some life (by heavy hacks, and building on dappar) [12:32] mid-jaunty-launcher: StevenK [12:32] Requires extra hours in the day to write up [12:32] Or not sleeping. [12:32] Prefer first option [12:33] selection-or-arm-images: ogra [12:33] pending approval [12:33] persia: s/or/of/ ? [12:33] err [12:33] StevenK, Yes. [12:33] pending review actually [12:33] i'd like to get review from StevenK on that :) [12:33] [ACTION] StevenK to review selection-of-arm-images [12:33] Okay, I'll read it tomorrow [12:33] as i mentioned in the beginning, since he does the non gui tool parts [12:34] mid-screen-rotation: ogra [12:34] beyond that the buildd side seems done to an exted [12:34] and the gui side isnt started yet (n need kernels ...,. amitk .... ) [12:35] not started yet (but its an afternoon of work to get a prototype, will do that before the sprint) [12:35] Sigh. Thanks for crashing, Tasque [12:35] (the last sentence was on screen-rotation) [12:35] hildon-packaging-jaunty: persia [12:35] I need to write this. Plan is to mostly do nothing, except if that breaks something, or if the Mer project needs something. [12:36] (https://launchpad.net/m-r/ [12:36] mobile-applications: persia [12:36] Mer is arm related or arch independent ? [12:36] * ogra didnt really get yet what thats for [12:36] ogra, arch-independent. [12:36] ah, k [12:36] back to hildon-packaging-jaunty :) [12:37] well, question answered :) [12:37] Mer is an effort within the Maemo community to build most of the Maemo apps on an Ubuntu base, and push patches back into Maemo to improve upstream. [12:37] move on [12:37] ah [12:37] So, if we want hildon later, we want to support them now to make sure upstream can be adopted well. [12:37] sounds like a cool idea [12:38] Yeah. Lots of credit to those guys. Take a look at their patch collection. [12:38] Moving on. [12:38] mobile-applications: persia [12:38] thought there might be clashes and overlap on a low level with moblin2 [12:38] [ACTION] persia to request conclusions from application research delegates [12:39] Once I've done that, and I get the results, I'll finish the spec, and we can adjust the seeds. [12:39] mobile-spec-cleanup: persia [12:39] I've not spent any time on this recently, more focusing on current specs. I'm planning to get back to that once the current specs are in better shape [12:40] And that concludes the Roadmap review [12:40] yay [12:40] Next up: Wimax: we should start packaging this stack but need help from Kernel and Foundation folks for some bits (kernel drivers and DHCP patches); we also need hardware :-p amitk had started looking in some stuff [12:40] amitk, Anything to share on that? [12:40] [LINK] http://www.linuxwimax.org/Download [12:41] persia: We only carried wimax in hardy [12:41] and even that until v1.2 [12:41] Is upstream suitable for more general adoption or import into Ubuntu? [12:41] Actually, not even in Hardy. [12:41] do you now want it for hardy or jaunty? [12:42] StevenK: only the kernel drivers bits, true [12:42] wimax upstream has pushed some dependency patches for input layer into linus' tree [12:43] but the wimax driver itself is still outside [12:43] Well, do we want it? [12:43] Anyone volunteer to start a spec? [12:45] OK. Let's pass on that for now. If anyone wants to pick it up, please bring it to the next meeting. [12:45] Any other business? [12:45] playya, ? [12:45] did you have any topics ? [12:46] ... doesnt look like [12:47] OK. That's it then. Thanks for attending. Until next week. [12:47] #endmeeting [12:47] nope. not really [12:47] cya [12:47] wow, even with going over the specs we're 10min ahead [12:48] * ogra liked that meeting, had a very productive touch this time [12:58] Actions and minutes from the meeting now available at https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090122 [12:59] ogra, [13:00] randa, [14:08] Who's here for the Java Team Meeting [14:08] o/ [14:09] * \sh is here :) [14:09] \sh, Welcome. Don't usually see you at this meeting :) [14:09] the more, te merrier [14:09] <\sh> persia: yeah...it happened that I need to deal with java on ubuntu now and already found bugs... [14:10] Today's agenda (https://wiki.ubuntu.com/JavaTeam/Meeting) has nothing special. [14:10] \sh: Go add something quick if you have something, and we'll get to it after the roadmap [14:10] OK. Roadmap is first [14:11] <\sh> persia: we need to get java6b12 in jaunty and need backports [14:11] <\sh> oh sorry [14:11] I don't see robilad, so we'll skip that. [14:11] slytherin, MoveToUniverse [14:12] nothing much. only bug logged was tuxguitar [14:12] I haven't seen any activity on jboss bug, I will have to get hold of some archive admin. [14:14] Koon, maven [14:14] not so good news, I'm afraid [14:14] first about maven packaging support [14:14] Ludovic Claude disappeared since Christmas so implementation is stalled [14:15] furthermore Torsten Werner, the debian dev that works on maven now, hinted that our implementation was flawed [14:15] Koon: No he has not disappeared. He is working with Torsten in Debian. [14:15] slytherin: recently ? [14:15] I have synced quite a few packages from Debian. [14:15] ludovicc came to the meeting on the 8th, and presented activity [14:16] then it might be in a better shape than I supposed, they both didn't answer my recent emails [14:16] He also discussed the specifics of Torsten's concerns, and his work to rationalise the two approaches [14:16] log is at http://irclogs.ubuntu.com/2009/01/08/%23ubuntu-meeting.html [14:16] I'll have to get the log [14:16] ok [14:16] my other problem is that maven is probably not the main issue for large Java stacks support [14:17] the key problem is what maven results in : dependency on very precise versions of JARs [14:17] as runtime-depends and build-depends [14:17] we ship one, they want all of them. [14:18] I've been discussing with the upstreams, they clearly can't align their work to what we provide [14:18] this, combined with the inflation in Java deps in suych projects, leads to a major build-from-source issue [14:18] Not only that, but significant inflation of installation impact. [14:19] you basically have to package a few hundreds deps before starting to package any stack like Geronimo/Glassfish [14:19] I'm preparing an email to ubuntu-devel to discuss that question [14:19] you're more than happy to join in the discussion [14:19] We have a glassfish: is this just changes upstream? [14:20] it's a binary one [14:20] Oh, that's why. [14:20] glassfishv2 in multiverse. Only the easy glassfish bits are in universe [14:20] like apis [14:20] sun works on glassfishv3 in universe [14:20] sathyan has been piping up in #ubuntu-java the past few weeks. Have you been working with him? [14:21] yes [14:21] they have just hit the aforementionned walls [14:21] I see. [14:22] After turning the problem in all senses for a month, my best shot is to adapt some policies [14:22] but maybe someone else will find a less disruptive way [14:22] So maven not only has the issues Torsten pointed out, but incorporating it causes other issues to appear? [14:22] it's not really linked to Maven [14:22] It's about upstream mindset? [14:23] yes. Maven just makes it easier to have that mindset [14:23] I have a couple of other non-Maven projects that have exactly the same problem [14:23] (they ship their build deps as part of the sources) [14:23] This was a topic in Prague, and has long been an issue with larger Java projects. [14:23] it still is ;) [14:24] At some point of topic I even filed a bug in apache bugzilla about not shipping jars in batik source distribution. Never received a response. :-) [14:25] slytherin: if you don't take a distro-centric pov, but a product-oriented one, their appraoch makes sense [14:25] it's so much easier not to care about how your dependencies evolve [14:25] it's just *wrong* in a distro setting. [14:26] No. I don't agree. If I am providing source archive then I would expect users to read readme, download the required build dependencies. [14:26] The Geronimo guys ship with hundreds of external JARs in their tar.gz... they keep watch on security issues for all of them and release a new version of their software everytime they update one jar to fix. [14:27] anyway... I'll send that email and see if creative ideas come from the thread [14:28] next :) [14:29] persia, Killing Sun Java 5 [14:29] Erm. Didn't do anything at all. I'll report something next week. Sorry for dropping this. [14:30] That concludes the Roadmap. [14:30] No other agenda items from a refresh. [14:30] Any Other Business? [14:31] I have one. Not exactly related to our roadmap [14:31] \sh, ? [14:31] We're done with Roadmap. The floor is open. [14:32] <\sh> forget my request for now..I'll file bugs if needed..I'm testing 6u12 right now to check if my assumption is correct [14:32] Does anyone know how to disable auto update in azureus? I am working with merge. But as soon as I start the new vuze interface it starts downloading the latest version. [14:32] I tried commenting some code but that has not worked out. [14:32] * Koon just reads last week logs, apparently maven support is in good shape. [14:33] I can not upload the merge unless this issue is sorted out. As a last resort I will have to mail upstream. [14:33] \sh, OK. If it's just a package update, a bug is better. If there's impact to other stuff, we're happy to discuss. [14:34] <\sh> persia: looks like (if I'm correct) that we need to backport or SRU new packages down to hardy [14:35] slytherin, Have you checked with jdong? [14:35] \sh, sun-java or openjdk? [14:36] <\sh> persia: hopefully only sun-java...I need to check openjdk when it's based on the orig java source [14:36] persia: no, I will check [14:38] slytherin, Dunno if he still knows, but he was a regular uploader for a while. [14:38] persia: will check with him anyway [14:38] \sh, SRUs for sun-java are not uncommon, because we can't see it, and it sometimes has bugfixes. openjdk tends to follow normal update guidelines. [14:42] OK. Anything else, or shall we end the meeting? [14:42] Well, thanks for attending. Until next week. === Keybuk_ is now known as Keybjk === Keybjk is now known as Keybuk === apachelogger is now known as apachelogger_ === apachelogger_ is now known as apachelogger === bazhang_ is now known as bazhang