=== pgraner is now known as pgraner-afk === nhandler_ is now known as nhandler === calc_ is now known as calc === _neversfelde is now known as neversfelde === asac_ is now known as asac === cjwatson_ is now known as cjwatson [11:57] * ogra waves [11:57] * StevenK shores [11:57] * ogra waits for StevenK to make his std. joke [11:57] * StevenK smirks [11:57] :) [11:57] * NCommander thinks stdjoke should be added to the next revision of the C language [11:57] :-) [11:58] MootBot! [11:58] Yay! [11:58] Its the first time its been here since I joined Canonical :-) [11:59] * NCommander hugs MootBot [12:00] #startmeeting [12:00] Meeting started at 06:00. The chair is davidm. [12:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:00] mobile meeting is started :-) [12:00] awesome [12:01] persia, do we not have a meeting scheduled today? [12:01] We do have a meeting scheduled today. [12:01] * lool waves [12:01] The bot doesn't track the schedule due to a bug. [12:01] Ah that explains it then [12:01] Thanks [12:02] We have a few todos from last week [12:02] first persia you ran last weeks meeting correct? [12:02] I did. [12:03] thank you [12:03] NCommander: You're running the next BTW IIUC [12:03] On the other hand, I didn't actually test oem-setup this week. I'll try for tomorrow. [12:03] Do we have a meeting next week due to Germany? [12:03] [topic] persia to get initial results from mobile-setup-wizard [12:03] New Topic: persia to get initial results from mobile-setup-wizard [12:03] I didn't run that test. I'll try for tomorrow. [12:03] [action] persia to get initial results from mobile-setup-wizard (co) [12:03] ACTION received: persia to get initial results from mobile-setup-wizard (co) [12:04] [topic] NCommander to take over driving ship-seed-for-mobile-images to close it [12:04] New Topic: NCommander to take over driving ship-seed-for-mobile-images to close it [12:04] That just needs the spec written and then it can be marked Implemented [12:04] * NCommander didn't even see that he was assigned to me. [12:04] Er [12:04] s/written/finished off/ [12:05] NCommander, can you get to it today? [12:05] No, it needs a test plan, and to be tested, and it's gone. [12:05] davidm, sure, no problem. [12:05] Was this assigned to me last meeting, or just now? [12:05] persia: Ah, right [12:05] NCommander, Last meeting. [12:05] hrm [12:05] [action] NCommander to take over driving ship-seed-for-mobile-images to close it, will do by EOD 29 Jan [12:05] ACTION received: NCommander to take over driving ship-seed-for-mobile-images to close it, will do by EOD 29 Jan [12:06] NCommander: I will tell you how to test it, then you can write the test plan and actually test it [12:06] [topic] NCommander to reset arm-softboot-loader to "Drafting", and work towards a solution in #ubuntu-arm over the next week. [12:06] New Topic: NCommander to reset arm-softboot-loader to "Drafting", and work towards a solution in #ubuntu-arm over the next week. [12:06] StevenK, thanks, I just changed the assignee in Launchpad [12:07] NCommander, No, don't change the Assignee: you're "Drafter", StevenK is Assignee (and did the implementation) [12:07] Oh [12:07] I didn't change the spec, but discussion hasn't gone anywhere. People who have ARM hardware have a sane(ish) booting solution, so there isn't much coming from #u-arm [12:07] * persia didn't see any discussion there at all [12:07] * ogra still doesnt call a serial console "sane" :) [12:08] +1 ogra [12:08] Do I need to carry over the topic? [12:08] Yes. [12:08] or do we have something else in it's place? [12:08] I think it's too early to pursue implementation of shism [12:08] do we still want it ? [12:08] Yes, but I'm not expecting to get much out of #u-arm [12:08] shism ? :) [12:08] heh [12:08] I'd say it's pretty clear we will want bootable SD cards [12:08] But not sure [12:09] We have a set of patches for redboot to start extending it in that matter [12:09] If we need a way to send redboot over a serial port or stuff it in a SD card image, we have to package redboot [12:09] [action] NCommander to reset arm-softboot-loader to "Drafting", and work towards a solution in #ubuntu-arm over the next week. (co) [12:09] ACTION received: NCommander to reset arm-softboot-loader to "Drafting", and work towards a solution in #ubuntu-arm over the next week. (co) [12:09] lool, but bootable SD can also carry a dd'ed preconfigured bootloader [12:10] Which bootloader? [12:10] the one for the target arch [12:10] I don't think we really want to touch the bootloaders, the board vendors should be doing that work I think [12:10] whatever that is for this specific one [12:10] ogra: So we need it in the archive, right? [12:10] I think the point is that at least with the babbage we would have a bootloader on the SD card [12:10] lool, thats what i say since *months* [12:10] davidm: If we have to ship it, we have to provide and maintain source for it I'm afraid [12:10] (although I'm not clear how you would set the board to boot from SD vs. PATA) [12:10] lool, good point [12:10] * persia notes that there's a whole channel to discuss this in, and an action to discuss outside the meeting (and the roadmap is busy) [12:11] ogra: And I never disagreed [12:11] ogra: I just postponed until it was clear we needed it :) [12:11] I guess the babbage board does something that most boards don't the boot loader is written to the SD card and not internal flash [12:11] well, we should have at least something like a redboot-source and a uboot-source package [12:11] not sure we want/need actual binaries [12:11] [topic] StevenK to review selection-of-arm-images [12:11] New Topic: StevenK to review selection-of-arm-images [12:12] davidm, well, as far as we know, that internal flash is going away, no idea what's happening there specifically though. [12:12] NCommander, agreed [12:12] davidm: I did review it -- it looks good to me [12:12] davidm, the beagle and EVM can both boot fine with bootloader on SD [12:12] OK, I'll mark that as closed, thanks StevenK [12:12] (side note, we are now building ARM CD images and netboot images) [12:12] davidm, so please approve that spec :) [12:12] ogra, good to know [12:13] i'll set it to pending approval [12:13] ogra, thainks [12:13] [topic] persia to request conclusions from application research delegates for mobile-applications [12:13] New Topic: persia to request conclusions from application research delegates for mobile-applications [12:14] * ogra whistles innocently ... [12:14] I made requests, but wasn't very forceful, and didn't get responses. I'll send out a more forceful request in a couple hours. [12:14] We *need* to get these seed changes in by Monday, or we miss Alpha 4, and there's no point. [12:14] thank you, I'll carry over [12:14] Yes and I don't want to miss A4 [12:15] [action] persia to request conclusions from application research delegates for mobile-applications again [12:15] ACTION received: persia to request conclusions from application research delegates for mobile-applications again [12:15] wll, unr and mid images look fine so far [12:15] *well even [12:15] good enough for A4 [12:15] OK that concludes prior action items [12:15] ogra: Did you see the new UNR image! [12:15] the touchscreen situation is very bad though [12:15] My blood, sweat and tears are all through that image! [12:15] StevenK, i tried yesterdays because of the touchscreens [12:15] persia, would you be so kind as to lead the roadmap review? [12:16] its great [12:16] [topic] roadmap review [12:16] ... so be sure to wash your hands and your USB key [12:16] StevenK, latest evtouch should at least recieve taps ... i have to fix the issues with movement events though [12:16] davidm, No. Just topic each item in the list, and the assigned person will say someting. [12:17] [topic] roadmap review [12:17] (MootBot doesn't like me) [12:17] New Topic: roadmap review [12:17] [topic] offline-installer [12:17] New Topic: offline-installer [12:17] well, my build-arm-rootfs script seems to be widely used [12:18] next step is to work out a way to do the same with d-i and preseeding [12:18] additionally we need to discuss how to combine the livefses and kernels [12:18] livefses for armel are available since last night [12:18] Isn't that just dropping the installed kernel package into the livefs? [12:18] d-i images as well [12:18] persia, FSVO "just" yes [12:19] Oh, right, the kernel d-i udebs. [12:19] its actually "installing the kernel package inside the livefs in a VM [12:19] " [12:19] and then re-roll the livefs [12:19] persia: Please link the roadmap for lazy people who aren't sure they have it open? [12:19] https://wiki.ubuntu.com/MobileTeam/Roadmap [12:19] StevenK, its linked on the agenda [12:19] [link] https://wiki.ubuntu.com/MobileTeam/Roadmap [12:19] LINK received: https://wiki.ubuntu.com/MobileTeam/Roadmap [12:20] ogra, you done? [12:20] thats it so far about offline-installer, yes [12:20] [topic] unr-handling-jaunty [12:20] New Topic: unr-handling-jaunty [12:21] * davidm needs to program his keyboard with Mootbot shortcuts ;-P [12:21] The UNR image this week has gotten new versions of the launcher, maximus and other fun things, and looks to be shaping up well [12:21] bfiller has gone insane and has prodded upstream about a few issues and filed a mass of bugs [12:21] it looks great ! [12:21] * StevenK does the happy dance [12:21] I'm hoping to install it on my Q1 before I leave [12:22] StevenK, Are you pushing a new -meta soon? [12:22] persia: For? [12:22] I pushed one before I left for dinner [12:22] Ah, then my cache is just old :) [12:22] 1.131 was published 6 hours ago [12:23] RIght. I'll fight with apt. Moving on... [12:23] I just installed Intrepid on my brand spanking new eee PC 900a had some fun getting WiFi to work, are we need to be able to solve that for Jaunty [12:23] * StevenK points davidm at the kernel team [12:23] * persia points davidm at the Any Other Business section of the agenda [12:23] The eee PC will be a target. [12:24] [topic] mid-application-switcher [12:24] New Topic: mid-application-switcher [12:24] there are DKMSified drivers in stgraber's PPA for the eee [12:24] Haven't started work. Am expecting to have time to start next week. [12:24] i can give you a link after the meeting [12:25] kernel team should just include them [12:25] Speaking of the kernel team! [12:26] poor cking ... entering at the wrong moment :P [12:26] * StevenK grins [12:27] persia, you done? [12:27] Yes. Just bump to the next for these after a line or two, if there's no response, or we'll run over. [12:27] [topic] mobile-setup-wizard [12:27] New Topic: mobile-setup-wizard [12:28] Need to test: see my action item :) Should have a set of work to be done ready tomorrow, but don't expect it to be done until Alpha 5. [12:28] [topic] mobile-team-seed-management [12:28] New Topic: mobile-team-seed-management [12:29] StevenK, ^^ [12:29] Yeah, thinking [12:29] It's mostly done, aside from the last bit which I'm waiting for archive reorg [12:29] Last week it was basically pending: do we want to block it on deeper specification of archive reorg? [12:29] I'd rather we declare it done [12:30] And have the other bit be ad-hoc fallout of archive-reorg? [12:30] Sure [12:30] [topic] ship-seed-for-mobile-images [12:30] New Topic: ship-seed-for-mobile-images [12:30] I'm fine with that, so long as it gets documented in Unresolved Issues. [12:31] NCommander, ^^ :) [12:32] Guessing from action items he has no input now [12:32] (hint: just say "in progress" :) ) [12:32] I'll finish this up today with StevenK's assistance. [12:32] [topic] general-resolution-for-touchscreen [12:32] New Topic: general-resolution-for-touchscreen [12:32] looks very bad [12:32] none of my touchscreens work with evdev [12:32] upstram are liars :P [12:33] Haha [12:33] so i'm currently working first prio on getting evtouch back in shape to avoid regressions [12:33] i *will* look into evdev and do what i can, but want to avoid us to release without a working solution [12:34] so that spec might become jaunty+1 depending on upstream [12:34] [topic] arm-softboot-loader [12:34] New Topic: arm-softboot-loader [12:34] Well, some good, some bad [12:34] kexec is still broken on ARM (my patch doesn't work on real hardware) [12:35] On Freescale's HW, we still can't boot an initramfs from RedBoot (I did poke jerone about this) [12:36] NCommander, you done [12:36] ? [12:36] No [12:36] Still typing [12:36] On the plus side, ogra came up with IMHO a very impress shell script based menu that parses grub's menu.lst and spits out a nice ASCII menu; I am planning to package this, and a modified kexec package so we can generate an initramfs on x86/amd64/etc. to test this, and to work on getting such packages in the archive [12:36] I also plan to try and bring futher discussion of this in #u-arm. [12:36] * NCommander is done. [12:37] well, it can parse any kind of file, not only menu.lst [12:37] [topic] mid-jaunty-launcher [12:37] New Topic: mid-jaunty-launcher [12:37] Need time [12:37] kourou ! [12:38] [topic] selection-of-arm-images [12:38] New Topic: selection-of-arm-images [12:38] image side is done, we have live, d-i and server images [12:38] I've not had time to draft the parts of the spec/picking out what needs to be done [12:38] davidm: I wasn't done yet! [12:38] (I am now) [12:38] rest will depend on how i implement the kernel merge stuff and waits for kernels [12:38] [topic] StevenK sorry [12:38] New Topic: StevenK sorry [12:38] Like that needed a seperate topic [12:39] [topic] selection-of-arm-images [12:39] New Topic: selection-of-arm-images [12:39] well, what i said above :) [12:39] * davidm has to stop prequeuing [12:39] ogra> image side is done, we have live, d-i and server images [12:39] rest will depend on how i implement the kernel merge stuff and waits for actual kernels [12:39] done ... [12:39] [topic] mid-screen-rotation [12:39] New Topic: mid-screen-rotation [12:40] not started yet, but since its a trivial gui that will take me only a day [12:40] Safe to target for Alpha 5? [12:40] i'll kick it off probably in a spare hour at the sprint [12:40] yeah [12:40] A5 should be fine [12:40] does the spec define a language to be used ? [12:40] [action] target mid-screen-rotation for A5 [12:40] ACTION received: target mid-screen-rotation for A5 [12:41] [topic] mid-display-manager [12:41] New Topic: mid-display-manager [12:41] ogra, Nope, although it presumes python. [12:41] (C or python ?) [12:41] C will be smaller though [12:41] ogra, either is fine [12:41] oki [12:42] lool, mid-display-manager?? [12:42] We discussed the implementation with Emmet shortly; no other update. [12:42] [topic] hildon-packaging-jaunty [12:42] New Topic: hildon-packaging-jaunty [12:43] I' m about 60% drafted locally: should post for review in the next couple days. [12:44] [topic] lpia-versus-i386 [12:44] New Topic: lpia-versus-i386 [12:44] Will discuss with cjwatson and doko over the sprint along other toolchain changes. (Nothing else to report on lpia-versus-i386.) [12:44] [topic] mobile-applications [12:44] New Topic: mobile-applications [12:44] I've mostly wrestled it into an actual spec, but will need input. Will be sending reminder email in a couple hours. [12:45] [topic] mobile-spec-cleanup [12:45] New Topic: mobile-spec-cleanup [12:45] Haven't touched it, and don't expect to get back to it until FF. [12:45] [topic] recovery-partition [12:45] New Topic: recovery-partition [12:46] But it doesn't get blocked by FF \o/ [12:46] No progress this week. High on my TODO list along the other high priority stuff. (Nothing else to report on recovery-partition.) [12:46] that concludes roadmap review [12:46] yay [12:46] [topic] Other Business [12:46] New Topic: Other Business [12:47] * ogra really likes the productivity of the new meeting structure [12:47] Yup. [12:47] same [12:47] Wifi drivers for the Eee. [12:47] We're nearly done and there's still 13 minutes to go [12:47] Yes, WiFi drivers for eee PC [12:47] https://launchpad.net/~stgraber/+archive/ppa has a rt2860 driver package [12:47] working fine with DKMS [12:48] it would be good to get that merged into our kernel if legally possible [12:48] (not sure what holds it back or if that hanst actually happened in jaunty even) [12:48] ogra: (for the record, livefses for armel have been available for a lot longer than since last night) [12:48] *hasnt [12:48] cjwatson, *publically* available :) [12:50] we will need to look into WiFi status to see how it can be solved. Took me a couple of hours to track down a working solution for the 900a, and 30 minutes to compile and install same. [12:50] Will need solutions for 700 900 and 1000 [12:50] right, the DKMS solution is way cleaner and will update automatically with the kernel [12:50] davidm: I think the kernel team is the first port of call [12:50] ++ [12:50] Agreed, I'll explore with pgraner [12:51] [action] davidm to explore eee PC WiFi with pgraner this week [12:51] ACTION received: davidm to explore eee PC WiFi with pgraner this week [12:51] OK any other business? Or I can close the meeting/ [12:51] i think the 700 is supported OOTB btw [12:52] using ath5k [12:52] Yes, I have one [12:52] Are we having a meeting next week? [12:52] we probably should try [12:52] StevenK, I think so we can have it from sprint [12:53] Easy enough I think unless bandwidth is too poor [12:53] Having an IRC meeting at 1pm will be a novelty [12:53] bandwidth will not be great [12:53] not really :P [12:53] apparently the hotel has only given us 40% of what we asked for [12:53] bah [12:53] do we have local mirrors ? [12:53] cjwatson, yes I saw that but I think we can sneak IRC through [12:54] so it'll be 2Mbit [12:54] ogra: yes [12:54] * davidm crosses fingers [12:54] worked fine in london that way [12:54] O_O; [12:54] 2Mb? [12:54] cjwatson: Oh good. It will feel just like home [12:54] and 200 people from Canonical? [12:54] .... [12:54] synchronous [12:54] 200? since when? [12:54] heh [12:54] this is a distro sprint, not allhands [12:54] Oh [12:54] *coughs* [12:54] Ok [12:54] Fail [12:54] NCommander, we dont all bring our families [12:54] Haha [12:54] StevenK, nah, it will still be a meg more then you have at home [12:54] people will have to be reasonably parsimonious about bandwidth [12:55] * StevenK glares at davidm [12:55] * NCommander notes to download all Ubuntu ISOs before he leaves [12:55] davidm: I have 1.5Mbit, thank you oh so much [12:55] OK sounds like we don't have anything else so endmeeting going once [12:55] NCommander, we'll have local mirrors, i hope that includes cdimage [12:55] NCommander: we'll have a local cdimage mirror [12:55] snap :) [12:55] StevenK, but OZ only has 1 Meg off the land ;-) [12:56] haha [12:56] Oh, thank $DEITY [12:56] rsyncing images to test won't suck, then [12:56] yay for !suck [12:56] berlin has lots of cafes with free wlan though ;) [12:56] I'll just need to remember to copy said images to my laptop [12:56] we culd just swarm out [12:56] endmeeting going twice [12:57] #endmeeting [12:57] Meeting finished at 06:57. [12:57] Thanks everyone [12:58] thanks [12:58] amazing, we finished a meeting with time to spare [12:59] Ooh, 3 minutes [14:02] Who's here for the Java meeting? [14:02] o/ [14:03] me [14:03] Agenda is at https://wiki.ubuntu.com/JavaTeam/Meeting [14:03] No special agenda items this time. [14:04] robilad is missing: Do we want to keep that on the RoadMap? It's been a while since there was any activity. [14:04] If nothing else, might be good to try to specify things in more detail there. [14:07] persia: I will mail him asking to update roadmap [14:08] slytherin, OK. I'm in favour of making Java servers work, but it needs someone driving :) [14:09] Next up: MoveToUniverse: is there anything significant still pending? Work to be done? [14:09] jboss packages moved to universe. :-) [14:09] * ScottK is curious if there will be any discussion about packaging policy? [14:09] That was the last big chunk, right? The rest require licensing issues? [14:10] Probably. The only one I am planning to file bug for is worldwind. [14:10] ScottK, It's not on the agenda, but can be raised after the Roadmap. [14:10] slytherin, OK. When you get that sorted, maybe move it to Done ? [14:10] ScottK: yep, i'll summarize the current thread [14:10] persia: sure [14:10] Koon, Maven (and let's leave glassfish/geronimo until after) [14:11] wait [14:11] I have just one last update. [14:11] Right. Still MoveToUniverse then. [14:11] there are two jboss related packages in depwait in universe, libjboss-cache2-java and libjboss-buildmagic-java. buildmagic is circular build dep (on itself) and cache2 has build dep on a package which is not even in Debian. [14:12] buildmagic can be sorted by special application to the buildd admins to do a manual build once. Has a request been made? [14:12] No. I haven't even checked if the circular dep is actually required [14:13] It would be great if someone can take over the work. [14:13] And what's the issue with cache2? How do we resolve that? New package in pkg-java? [14:13] persia: probably look into Torsten's personal repository for the package and if it is found ask him to upload to Debian so we can do a sync [14:14] So it sounds like these aren't big issues, but it's just a time thing? [14:14] yes, and I am tired of solving the circular build deps. :-( [14:16] Right. Maybe issue a call for help to the mailing list? [14:17] Anything else on MoveToUniverse? [14:19] OK. Moving to maven : Koon? [14:19] For Maven we are working on converging approaches with Debian. I'll meet with doko and Torsten next week to discuss that. [14:19] The approaches are mostly the same (no Maven patch), I just have to make sure our use cases are covered. And Torsten knows a lot more about Maven/Java than I do so his approach is probably better [14:20] Do you think we'll hit Jaunty, or is it likely jaunty+1? [14:21] Looking at recent progress I think we may be able to hit Jaunty. It all depends on Torsten though, since we'll most likely sync his work [14:21] And that includes ludovicc's work? [14:22] yes, AFAIK. [14:22] ludovicc has been working on the tools together with Torsten. [14:22] OK. That sounds like a good plan. Looking forward to next week. [14:22] definitely [14:22] Anything else for maven? [14:22] Nope. [14:23] OK. For Removing Java 5: [14:23] I got as far as registering the spec [14:23] (https://blueprints.launchpad.net/ubuntu/+spec/java5-removal) but haven't drafted it. [14:23] I have a couple script fragments slytherin put together earlier, and expect to have something for review by the next meeting. [14:23] Not yet sure how to get the spec approved, but I'll try to get that sorted as well. [14:24] And that's where we are. [14:24] Now, anyone have other items they want to raise? [14:24] none from my side. [14:25] I'm curious if there's any conclusion from the how do we package Java thread. [14:25] No conclusion yet... [14:25] general position from the ML answers so far seem to be to keep the clean approach we've had until now... do the packages we can from source and binary-package those we can't. [14:25] influence upstream to be compatible with the stack we provide [14:26] I'm curious if there's any conclusion from the how do we package Java thread. [14:26] Sorrt for the double post [14:26] The pointers to JPackage were interesting: is there much we can share there, or did they fall into the trap of specified versions? [14:26] Sorry even [14:26] No they didn't fall into that trap [14:27] It just sort of lost momentum? [14:27] My impression is that their appraoch (as well as ours) doesn't scale well [14:27] One point that I don't think got much mention on the list is that code copies are a security nightmare. [14:27] at one point, you cannot add any package anymore because you'll break some others [14:27] I just don't understand how that's special for Java, as compared to other languages. [14:28] persia: Which 'that'? [14:28] There's a somewhat related thread on ubuntu-devel-discuss about jabref, and when responding to that I noticed just *how* much random embedded stuff ended up in some .jar files. [14:28] ScottK, "at one point, you cannot add any package anymore because you'll break some others". [14:28] ScottK: I think everyone knows that code duplication is bad for security (hopefully) [14:29] I think it's particularly relevant here because at least one proposal is particulalry bad in that regard. [14:30] ScottK, Well, the "binary-in-multiverse" is bad in that regard too. [14:30] The issue is more that upstreams tend to try to bundle everything, rather than working with their upstreams. [14:30] unfortunately in most cases it's not pure code duplication. It's duplication of code that exist in an API-incompatible version somewhere else [14:31] Agreed, but I think in Multiverse there is no suggestion that things are supportable from a security perspective. [14:31] pure code duplicates are easy to solve with a couple symlinks and Depends: entries [14:31] This is a lot like the Ruby Gems argument we had last cycle. [14:31] I don't know of a good answer beyone help upstream gain some sanity. [14:32] Well, it's also user education. Many users don't actually care about it (cf. Jabref thread). [14:32] I still kinda hope we can build from source + a static API description [14:32] They just download something from a website that works cross-platform that also works in Ubuntu. [14:33] because imho there is no technical reason to require the presence of the binary artifact [14:33] for bytecode generation [14:33] Koon, That's an interesting idea, but I wonder why the API is being checked. [14:33] I think there is some good work to be done around this. [14:33] maven proved that you can generate bytecode with one version and use another one at runtime [14:33] Also, how do we confirm that the checked API matches that of our packaged library? [14:34] Until we have a good way to support this, there's really not much reason to put it in the archive, IMO. [14:34] ScottK, Well, I'd argue that anything with sufficient user demand would benefit from mirroring support, etc. (even in multiverse). [14:35] Lets us do things like track a version that was tested, and worked at release time. [14:35] yes, it all depends how bad the software is wanted [14:35] it's just not something we would recommend as a general way of doing things [14:35] Except if it's GPL, I don't think we can just toss a binary blob over the fence and declare victory. [14:36] Oh, certainly. Copyleft licenses are special that way. [14:36] BSD/X/ISC/CDDL are a little more forgiving. [14:36] * slytherin has to be away for some work. will be in 15-20 minutes [14:37] If users can download it from a web site and have it work, until it's actually maintainable, I'd suggest let them do that, but that's just me. [14:37] Err, except CDDL is copyleft, so scratch that one. [14:37] There is no Java compilation option allowing to ignore method checking... but maybe we could talk with Sun about this. That would /so/help [14:38] They tend to have presence at UDS: let's make sure it's one of the items for discussion in May. [14:38] i'm pretty sure it would generate the very same binaries [14:38] I think that's the kind of thinking we need now... What are the tools we need to make these Java amalgamations distro friendly. [14:38] There's usually only one Java session, about the JDK/JRE, but having a couple might let us explore more topics (if there is room). [14:38] I think figure policy and tools for the long run and then figure out how to get there. [14:39] sidenote: robilad discussed API tracking tools that Sun wants to more closely integrate in future Java [14:40] So there is definitely room for improvement [14:40] Yeah. There's a lot of thought about hjaving Java7 be sensibly modular, and encouraging use of common libraries. [14:40] It's just that Java7 is always rather future. [14:40] So I'd use temporary workarounds rather than policy transhing [14:40] trashing [14:40] to get the Java software we may require in today [14:41] I'd encourage you to make very sure you have a broad consensus on how you decide to approach that. [14:41] Well, most of the workarounds end up pushing to multiverse, where there's much less worry. [14:41] How much consensus is required? [14:41] persia: or restricted ? [14:42] Restricted is for drivers. [14:42] Koon, No, not restricted. [14:42] ok [14:42] Koon, The incentive to have things in restricted ought be going away before any of these stacks are in shape to be considered. [14:42] Koon: I think if it stays in multiverse and is legal (no GPL/CDDL blobs), then not a lot. [14:43] But whatever approach is taken, it needs to be documented and get some community review. [14:47] So, anything else about this packaging thread, or are we done? [14:48] nothing from my side [14:48] OK. Anyone else have anything to raise? [14:49] In that case, meeting adjourned. [14:49] Thank you all for coming, and we'll do it again next week. === dholbach_ is now known as dholbach === Pricey is now known as Guest39261 === _neversfelde is now known as neversfelde === mc44_ is now known as mc44