[11:57]  * ogra moos
[11:58]  * lool waes
[11:58] <lool> *waves
[11:58]  * StevenK beaches
[11:58] <ogra> haha
[11:59]  * NCommander gurgles
[11:59] <persia> OK.  Let's get started then.
[11:59] <persia> #startmeeting
[11:59] <MootBot> Meeting started at 05:59. The chair is persia.
[11:59] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[11:59] <persia> [LINK] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090305
[11:59] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090305
[11:59] <persia> [TOPIC] persia's action items
[11:59] <MootBot> New Topic:  persia's action items
[12:00] <persia> Actually running an OEM install without hand-editing the command line is currently blocked by bug #309396
[12:00] <persia> Other than that, it seems most of the right bits are in place.
[12:01] <persia> I've added the arm-library-optimisation and pouslbo packaging to the roadmap, as well as that bug.
[12:01] <persia> I haven't looked at the test cases at all, and will be carrying over that action item.
[12:01] <persia> [topic] NCommander's action items
[12:01] <MootBot> New Topic:  NCommander's action items
[12:02] <NCommander> jax10 installer works
[12:02] <NCommander> Most of my other items are carry over however, due to work on the Babbage board.
[12:02] <persia> [topic] StevenK's action items
[12:02] <MootBot> New Topic:  StevenK's action items
[12:03] <StevenK> Bug 335276 filed.
[12:03] <persia> [topic] ogra's action items
[12:03] <MootBot> New Topic:  ogra's action items
[12:03] <ogra> bug forwarded on request of the desktop team (seb128)
[12:03] <ogra> http://bugzilla.gnome.org/show_bug.cgi?id=574152
[12:03] <MootBot> LINK received:  http://bugzilla.gnome.org/show_bug.cgi?id=574152
[12:03] <ogra> attached a stack trace but upstream doesnt seem happy yet
[12:04] <ogra> (oh, and i can finally reproduce it)
[12:04] <persia> [topic] lool's action items
[12:04] <MootBot> New Topic:  lool's action items
[12:05] <davidm> ogra, is it only ARM or does it happen on other arches?
[12:05] <lool> 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] <ogra> currently its only arm afaik, the other comments there look rather like red herrings
[12:05] <ogra> davidm, ^^
[12:05] <persia> davidm, That bug is in the roadmap: let's hit details when we get there
[12:05] <lool> I'm busy with other stuff, so I intend to continue research around the next week
[12:05] <davidm> thanks ogra
[12:05] <lool> (done)
[12:06] <persia> lool, Do you need the action item carried, or does it belong somewhere else?
[12:06] <ogra> 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] <lool> persia: Let's keep it in the specs list, without any pointer?
[12:06] <lool> I should open a dummy blueprint for it
[12:06] <NCommander> ogra, try grepping the source for ppoll/pselect
[12:07] <persia> Opening the dummy blueprint was the action item.  I'll carry it over.
[12:07] <persia> OK.  Moving on
[12:07] <persia> [topic] Roadmap review
[12:07] <MootBot> New Topic:  Roadmap review
[12:07] <lool> Well what I said last week is that I would *spec* it  :-)
[12:07] <persia> [topic] offline-installer
[12:07] <MootBot> New Topic:  offline-installer
[12:07] <lool> But it was before the OMG lot's of stuff to do
[12:08] <ogra> yeah, last week somewhat changed all our schedules
[12:08] <ogra> err, no changes
[12:08] <persia> [topic] unr-handling-jaunty
[12:08] <MootBot> New Topic:  unr-handling-jaunty
[12:08] <ogra> like for all my roadmap items
[12:08] <StevenK> Hm.
[12:09] <StevenK> I'd like to move unr-handling-jaunty to Implemented
[12:09] <StevenK> It's firmly in bug fixing mode
[12:09] <ogra> \o/
[12:09] <StevenK> What does everyone else think?
[12:09] <ogra> ++
[12:09] <persia> Do it then, and drop it from the roadmap.  Congratulations!
[12:09] <StevenK> :-D
[12:09] <NCommander> yay
[12:09] <StevenK> That leaves me with no specs in the roadmap ...
[12:10] <StevenK> Perhaps I shouldn't have announced that.
[12:10] <persia> You can surely find some bugs :)
[12:10] <persia> [topic] arm-library-optimisation
[12:10] <MootBot> New Topic:  arm-library-optimisation
[12:11] <persia> lool?
[12:11] <lool> So some progress here; I'm working on pango1.0 and gtk+2.0 patches which should be done today
[12:11] <lool> Glibc's situation looks better now: the kernel issue is sorted out and it's IS to fix the kernels
[12:11] <lool> I am late in providing a final list of libs we will VFP
[12:11] <lool> ffmpeg-debian will be handled specially
[12:12] <lool> 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] <lool> And not using the vfp trick
[12:12] <lool> It will require rebuilds of rdeps
[12:13] <lool> (done)
[12:13] <persia> [topic] poulsbo-packaging
[12:13] <MootBot> New Topic:  poulsbo-packaging
[12:14] <persia> 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] <persia> [topic] general-resolution-for-touchscreen-handling
[12:14] <MootBot> New Topic:  general-resolution-for-touchscreen-handling
[12:14] <persia> no change as above
[12:15] <persia> [topic] arm-softboot-loader
[12:15] <MootBot> New Topic:  arm-softboot-loader
[12:15] <NCommander> No change, carry over please.
[12:15] <persia> [topic] selection-of-arm-images
[12:15] <MootBot> New Topic:  selection-of-arm-images
[12:15] <persia> no change as above
[12:15] <persia> [topic] lpia-versus-i386
[12:15] <MootBot> New Topic:  lpia-versus-i386
[12:15] <lool> Nothing new to report
[12:16] <davidm> Should we defer this to 9.10?
[12:16] <persia> [topic] mobile-spec-cleanup
[12:16] <MootBot> New Topic:  mobile-spec-cleanup
[12:16] <persia> [topic] lpia-versus-i386
[12:16] <MootBot> New Topic:  lpia-versus-i386
[12:16] <lool> moo?
[12:16] <lool> davidm: lpia-versus-i386?
[12:16] <lool> davidm: It's already deffered to that; it needs to be done in the infrastructure before we build 9.10
[12:16] <davidm> Yes, I was wondering if we should defer the questions
[12:16] <persia> 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] <lool> The goal is to change the opt flags just before the archive opens
[12:16] <davidm> Ah sorry
[12:17] <davidm> ignore me please sorry
[12:17] <persia> [topic] mobile-spec-cleanup
[12:17] <MootBot> New Topic:  mobile-spec-cleanup
[12:17] <persia> I've not taken any progress here.  I'm expecting to have some time to look at it again next month.
[12:17] <persia> [topic] bug#299847
[12:17] <MootBot> New Topic:  bug#299847
[12:18] <NCommander> Made a little more progress
[12:18] <lool> C test case?
[12:18] <NCommander> 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] <lool> Well it might be that the previous tests break the kernel or something
[12:19] <lool> That's what was happening to some extent in some vfp tests in glibc
[12:19] <StevenK> NCommander: "bizarre", bazaar is the DVCS
[12:19] <lool> NCommander: Start with all tests, remove half, remove the next half etc.
[12:19] <NCommander> Shoo, my coffee is low
[12:19] <lool> StevenK: Oh you're not using bizr?
[12:19] <NCommander> lool, which causes the nature of the failures to change and disappear :-/
[12:19] <GrueMaster> I've also had tests that cause future tests to fail in processor validation.  Could be cache related.
[12:20] <lool> NCommander: Stop removing tests when the failure disappear?
[12:20] <NCommander> Well, the test suite is a framework of intermixed code
[12:20] <NCommander> So to remove a test, you have to change the other tests to update at least for a new reference count
[12:20] <lool> NCommander: In the end it's a bunch of syscalls
[12:21] <NCommander> 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] <NCommander> Anyway, I don't except much progress on this until after A6 freeze kicks in next week.
[12:21] <persia> [topic] bug #331510
[12:21] <MootBot> New Topic:  bug #331510
[12:23] <persia> Right.  Seems fix released.  Removing bugs from the roadmap when fixing them is nice, unless you have something to say about them.
[12:23] <persia> [topic] bug #322217
[12:23] <MootBot> New Topic:  bug #322217
[12:23] <ogra> persia, eh, please reload :)
[12:24] <persia> Excellent!
[12:24] <persia> [topic] bug #328167
[12:24] <MootBot> New Topic:  bug #328167
[12:25] <persia> There was interspersed discussion above.  Anyone have anything to add, or shall we move to the next?
[12:25] <ogra> well, nothig to add to this one
[12:25] <lool> "Being debugged"
[12:25] <ogra> upstream has it, i offered more logs on request
[12:25] <persia> [topic] bug #309396
[12:25] <MootBot> New Topic:  bug #309396
[12:26] <persia> Essentially, this is an infrastructure issue only.  We need to use jaunty syslinux, but have to run it under intrepid.
[12:26] <persia> I've started work on a tool in perl that will do precisely that, but it will need significant testing, etc.
[12:26] <lool> LOVELY: the new edit description of launchpad bugs (AJAX-ish one) is really cool
[12:26] <persia> With luck, I'll have something almost-but-not-quite working by Friday.
[12:26] <lool> (sorry)
[12:27] <persia> [topic] bug #280669
[12:27] <MootBot> New Topic:  bug #280669
[12:27] <lool> persia: I find it's a bit of a waste of effort if you need to reimplement stuff because of IS constraitns   :-/
[12:27] <lool> NCommander: ^ that's yours
[12:27] <StevenK> persia: s/intrepid/hardy/
[12:27] <NCommander> Tested with both mainline lpia/i386 kernels, and apw's PPA kernel
[12:28] <StevenK> lool: I don't think it's an IS constraint at all
[12:28] <NCommander> All three can see both SSD devices
[12:28] <StevenK> Anyway, I don't want to have this argument here
[12:28] <lool> StevenK: So why can't we use the jaunty version?
[12:28] <NCommander> With the i386 kernel, it comes up in UDMA/66 mode (no ability to change in hdparam)
[12:29] <NCommander> apw's kernel causes it to come u pin UDMA/100 mode
[12:29] <StevenK> lool: Because the image is constructed on a hardy machine that would be very hard to run a jaunty binary on?
[12:29] <lool> NCommander: and with lpia?
[12:29] <lool> StevenK: So why don't we get a jaunty chroot?
[12:29] <NCommander> 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] <lool> StevenK: Even if it's just for running syslinux
[12:30] <lool> That seems like a machine effort rather than a human effort
[12:30] <persia> [action] NCommander to post dmesg for jacx10 to 280669
[12:30] <MootBot> ACTION received:  NCommander to post dmesg for jacx10 to 280669
[12:30] <lool> NCommander: excellent, so apw's kernel improves the DMA mode
[12:30] <lool> NCommander: So we can report back that we want this patch?
[12:30] <lool> NCommander: I think you want to hdparm -tT it though to confirm there's really a change and it work
[12:30] <lool> ss
[12:31] <ogra> ++
[12:31] <NCommander> lool, well, the dmesg comes up differently but I can test that
[12:31] <NCommander> (on apw's kernel vs. i386/lpia stock)
[12:31] <lool> NCommander: Well if it breaks the device under high IO for instance it might be wrong to merge the patch
[12:32] <NCommander> One would hope the hardware would prevent the IO mode from being switched to prevent breakage ...
[12:32] <persia> Hardware doesn't tend to be sufficiently self-aware to have a sense of self-protection
[12:33] <lool> NCommander: I just want to make sure the patch wont break anything
[12:33] <lool> NCommander: Consider that we will use this info to eventually upstream it
[12:33] <lool> NCommander: also, if it makes no speed difference then it might be worthless and erroneous
[12:34] <NCommander> I can run a HDD stress test with say dd and /dev/random to see if there is an actual change.
[12:34] <lool> NCommander: Yes, and I'm interested in hdparm -tT output
[12:34] <GrueMaster> Actually, use bonnie++.  It works great as an io stress test.
[12:35] <lool> Good idea
[12:35]  * NCommander dislikes the notion of extreme HDD tests on an SSD
[12:36] <persia> Well, it's better to burn one SSD getting it right than release something that burns thousands of them.
[12:36] <lool> NCommander: We're only speaking of 5 minutes of stress
[12:36] <GrueMaster> Actually, it is what I used to use to test the drivers when I was at Intel.
[12:36] <lool> It's at the logic level, not at the hardware wear out level
[12:36] <NCommander> 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] <persia> OK.  Anything else for 280669?
[12:37] <persia> NCommander, Do you need more actions?  I didn't see more commitments.
[12:37] <NCommander> Put down that I will confirm the change in performance with apw's kernel vs. stock kernels.
[12:38] <persia> [action] NCommander to confirm changes in performance between apw's kernel and stock kernel
[12:38] <MootBot> ACTION received:  NCommander to confirm changes in performance between apw's kernel and stock kernel
[12:38] <lool> NCommander: (it's tracked via the bug though)
[12:38] <persia> [topic] bug #336770
[12:38] <MootBot> New Topic:  bug #336770
[12:38] <ogra> well, somewhat not my highest prio item atm, but i plan to look into it next week
[12:39] <ogra> babbage is more important to get going now
[12:39] <persia> ogra, Do you need an action, or is roadmap sufficient?
[12:39] <ogra> roadmap is enough
[12:39] <ogra> well, doesnt matter really, we wont meet before A6
[12:39] <NCommander> ogra, it might be just that flash-kernel is in universe vs. main (I dunno if d-i calls it)
[12:39] <ogra> 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] <ogra> and the error only shows up at the very end
[12:40] <persia> Well, that naturally segues into
[12:40] <persia> [topic] NSLU2 enablement
[12:40] <MootBot> New Topic:  NSLU2 enablement
[12:40] <ogra> NCommander, yes, thats what i suspect, but i havent confirmed yet
[12:40] <ogra> persia, right
[12:40] <persia> Is this accurately covered by bugs at this point, or does it still need a special item?
[12:40] <ogra> but since two days babbage enablement is higher prio on my list
[12:41] <ogra> which includes the keyring daemon hang and images
[12:41] <persia> Maybe you want to add Babbage enablement to the roadmap?
[12:41] <lool> Makes sense
[12:41]  * ogra adds
[12:42] <persia> [topic] ARM Benchmarking
[12:42] <MootBot> New Topic:  ARM Benchmarking
[12:42] <ogra> bah, lool owns it
[12:42] <lool> done
[12:42] <lool> " OliverGrawert, LoicMinier, Michael Casadevall " on it
[12:42] <ogra> yep
[12:42] <ogra> saw that
[12:42] <persia> 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] <ogra> well, we share the load on different levels
[12:43] <NCommander> ALl ARM bencharmsk for ARMv5, and ARMv6 done except two graphical ones on ARMv6 (due to monitor issues back home)
[12:43] <ogra> and share the work, each of us works on different parts
[12:43] <NCommander> 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] <persia> NCommander, So results are expected next week or so?
[12:43] <NCommander> persia, results have been up for ages.
[12:44] <persia> Well, except for the two graphical ARMv6 ones :)
[12:44] <persia> Anyway...
[12:44] <NCommander> the ARMv7 benchmarks is depwait on loic's ec2 spec, unless someone else has an idea how to do an archive rebuild.
[12:44] <persia> [topic] Babbage enablement
[12:44] <MootBot> New Topic:  Babbage enablement
[12:44] <ogra> slow progess ...
[12:44] <lool> good progress here :-)
[12:44] <NCommander> painful progress ...
[12:44] <ogra> waiting on the kernel package
[12:45] <lool> I managed to create SD card images which work on any size of cards which the ROM will take
[12:45] <ogra> will work on getting a casper initramfs going today
[12:45] <NCommander> ogra, that won't fly without a merged kernel
[12:45] <ogra> and with luck even boot the suashfs
[12:45] <NCommander> Baseline doesn't have AuFS
[12:45] <ogra> *squash
[12:45] <lool> With a partition protecting the redboot + fis with kernel and initramfs and config
[12:45] <lool> I'm working on removing the need to run redboot to achieve that
[12:45] <ogra> NCommander, getting into an initramfs prompt is my first target atm
[12:45] <ogra> in a casper initramfs
[12:46] <NCommander> ogra, I sent you what I know about running an initramfs
[12:46] <ogra> that wont need aufs
[12:46] <NCommander> lool, if I known you had that progress, I would have made sure FSL had known
[12:46] <ogra> NCommander, right
[12:46] <lool> 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] <NCommander> s/configuration/communication/g
[12:47] <NCommander> 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] <persia> Indeed.
[12:47] <NCommander> Lets go from the top down
[12:47] <NCommander> RedBoot
[12:48] <NCommander> lool, care to fill us in what you managed to do specifically and what's left to do?
[12:48] <persia> We're tight on time.
[12:48] <persia> Rather, could one of you take charge, and put together a wiki page with all the bits, and link to it?
[12:48] <lool> NCommander: Not really, I prefer moving forward and doing the doc pass in the end
[12:48] <persia> That makes it easy for us to go through status quickly next week.
[12:48] <lool> I'm taking notes, but I don't want to document perfectly the intermediate attempts
[12:49] <NCommander> 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] <lool> 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] <lool> I'm working on removing that requirement
[12:50] <lool> I managed to build the target layout which we will use in the released image
[12:50] <lool> Now I need to make that fully automated without the need of a babbage board
[12:50] <lool> What's missing is a redboot binary built by ourselves from source
[12:50] <lool> preferably packaged
[12:50] <lool> That's on NCommander's plate
[12:50] <ogra> but worst case we could go with a binary blob from restricted, no ?
[12:50] <lool> And work on the contents of the rootfs; currently I'm running a plain Ubuntu install on it and it works fine
[12:50] <ogra> if everything fails
[12:51] <lool> (manual debootstrap)
[12:51] <NCommander> ogra, no, GPL problem.
[12:51] <ogra> NCommander, we can provide the source on request
[12:51] <lool> ogra: If we confirm we can really build it
[12:51] <lool> ogra: How can you tell your sources are the sources?
[12:51] <NCommander> 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] <ogra> lool, yeah, indeed
[12:52] <ogra> lool, but as a last resort a package with binary blob and the sources separately can do
[12:52] <ogra> indeed we need to build it once
[12:52] <ogra> i'm counting on NCommander here :)
[12:52] <NCommander> I've managed to build it once, in a dream :-/
[12:52] <davidm> 8 minutes
[12:53] <persia> So again, could one of you volunteer to drive the coordination, and report on it in the meeting?
[12:53] <lool> Oh you mean single reporter?
[12:53] <lool> I'm happy to report to someone so that he can report here
[12:53] <persia> That ought make the meeting go more smoothly.
[12:54]  * ogra takes that 
[12:54] <persia> [action] ogra to take charge of Babbage enablement
[12:54] <MootBot> ACTION received:  ogra to take charge of Babbage enablement
[12:54] <persia> So, that concludes the roadmap.
[12:54] <persia> [topic] Discuss moving meeting time to be more convenient for those in UTC-5 through UTC-8
[12:54] <MootBot> New Topic:  Discuss moving meeting time to be more convenient for those in UTC-5 through UTC-8
[12:55] <ogra> for the IRC meeting ?
[12:55] <persia> 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] <NCommander> (and UTC-5 :-P)
[12:55] <persia> Nobody in UTC-5 complained to me :p
[12:55]  * ogra wasnt aware we wanted to shuffle that as well
[12:55] <davidm>  We have daylight savings changes happening world wide over the next weeks
[12:55]  * GrueMaster doesn't recall complaining.
[12:55] <davidm> US is this weekend
[12:56]  * ogra didnt complain 
[12:56] <persia> So, when do we want it?
[12:56] <davidm> Does anyone know when all of the changes are complete?
[12:56] <lool> I don't care much if it stays one hour long and close to this time
[12:56] <lool> It's lunch time no matter what, but that's ok
[12:56] <ogra> ++
[12:57] <persia> 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] <StevenK> Australia doesn't switch until April
[12:57] <StevenK> Except for Western Australia, but they don't count
[12:57] <davidm> Wow it's an entire month this year to convert over
[12:57] <lool> Australia is in Summer and they walk on their hands, I don't see how we can do anything for these people
[12:58] <StevenK> lool: Remind me to punch you in the kneecaps when I see you
[12:58] <lool> davidm: What happens if we keep the current UTC time?
[12:58] <lool> StevenK: To force me to walk on the hands?
[12:58] <persia> 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] <StevenK> lool: No, because I can't reach your shoulder
[12:58] <lool> It's fortunate I'm not smaller, or you would have hit higher than the kneecaps
[12:58] <davidm> In the US it's an hour "nicer" to waking up
[12:58] <persia> So, we're *really* tight on time.  Anyone opposed to 20:00 or 21:00 UTC?
[12:59] <ogra> StevenK, his kneecaps might not agree with his heads opinion ... be careful :)
[12:59] <NCommander> No objection, that would be an improvement for us US folks.
[12:59] <StevenK> 20UTC is a little early for me
[12:59] <lool> persia: that's far from now
[12:59] <davidm> lool, meeting would move to 07:00 central time but that is still 05:00 for -8
[12:59] <GrueMaster> StevenK needs his beauty sleep.
[12:59] <persia> lool, 21:00 is nine hours.
[13:00] <davidm> StevenK, what time is 20 UTC local for you?
[13:00] <lool> What about two hours later, 2pm UTC
[13:00] <StevenK> davidm: 7 am
[13:00] <persia> 6am come April
[13:00] <davidm> StevenK, that beats waking folks at 05:00
[13:00] <davidm> Is 21:00 better?
[13:00]  * persia fails to do the math for UTC+9
[13:01] <StevenK> Hah
[13:01] <StevenK> davidm: 8am and then 7. Still makes me say ick :-)
[13:01] <NCommander> StevenK, you should try being in central time
[13:01] <lool> Hey why don't you folks move to France?
[13:01] <GrueMaster> Or PST
[13:01] <davidm> Yea, but it's quite a lot better then 05:00 or earlier
[13:01] <StevenK> NCommander: I like living in tomorrow, you're living in the past.
[13:01] <ogra> or germany
[13:02] <NCommander> StevenK, I don't have 24 hour+ flight times to go anywhere :-)
[13:02] <StevenK> NCommander: Yes, you do. Try flying to Auckland or Sydney
[13:02] <NCommander> lool, personally, I want to move to Alaska .... but that won't do anything good for our call time.
[13:03] <StevenK> Alaska is still -8 or is it -9?
[13:03] <NCommander> -9
[13:03] <persia> -10/-11 in some areas.
[13:03] <NCommander> and Hawaii is -10
[13:03] <GrueMaster> Personally, I vote for monthly face to face meetings in Australia.  Hawaii would work too.
[13:04] <lool> So late UTC is probably the best choice
[13:04] <lool> Which is middle of the night for asia where we have nobody, as persia pointed out recently
[13:04] <NCommander> lool, nobody yet.
[13:05] <persia> 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] <StevenK> And it's the middle of the day in the US?
[13:06] <persia> Yes.
[13:06] <GrueMaster> ~lunch time here.
[13:06] <persia> GrueMaster, You get no sympathy for that.
[13:06] <GrueMaster> none needed.
[13:06] <GrueMaster> My office is 5 feet from food.
[13:07] <davidm> StevenK, what time will 21:UTC be in a month local?
[13:07] <ogra> you work in your kichen ?
[13:07] <StevenK> Your office is in the kitchen?
[13:07]  * StevenK glares at ogra 
[13:07] <ogra> snap :)
[13:07] <persia> I'm not hearing consensus, and we're overtime.
[13:07] <GrueMaster> next too  the kitchen.
[13:07] <StevenK> davidm: 6am
[13:07] <persia> [action] meeting time discussion to be deferred to next week
[13:07] <MootBot> ACTION received:  meeting time discussion to be deferred to next week
[13:07] <persia> Please consider it, and let's review again then.
[13:07] <davidm> Good enough
[13:07] <persia> [topic] Any other business
[13:07] <MootBot> New Topic:  Any other business
[13:08] <davidm> persia, thanks for running meeting
[13:08] <lool> persia: thanks for chairing
[13:09] <persia> I'm not hearing anything.  If you have anything, please add it to the agenda for next time.
[13:09] <persia> #endmeeting
[13:09] <MootBot> Meeting finished at 07:09.
[13:09] <ogra> thanks
[13:09]  * GrueMaster drags his carcass back to the cave.
[14:03] <persia> Who's here for the Java Meeting?
[14:03] <ttx> o/
[14:03]  * sommer is loitering out of curiosity
[14:04] <persia> OK.  Meeting agenda is (as always) at https://wiki.ubuntu.com/JavaTeam/Meeting
[14:04] <persia> Nobody raised any special items.
[14:05] <persia> robilad doesn't appear to be present.
[14:05] <persia> slytherin doesn't appear to be present.
[14:05] <persia> ttx, Any updates for maven?
[14:06] <ttx> persia: no. I intended to have a look at the current state in Debian but haven't had time to
[14:07] <ttx> as a reminder, we decided to follow Debian work on this, and contribute missing libraries where appropriate
[14:08] <persia> Right.  Do we still need it as a Roadmap item if we're not actively chasing it?
[14:08] <ttx> persia: I would say no.
[14:08] <persia> Then let's drop it.
[14:09] <ttx> I'll remove it.
[14:10]  * persia frantically tries to finish the task for the next time
[14:12] <persia> Right.
[14:12] <persia> So, the only package remaining in the archive that build-depends on sun-java5-jdk is pj
[14:13] <persia> And the only package that binary-depends exclusively on sun-java5-jre is sunwderby.
[14:13] <persia> Since sunwderby has no rdepends, I'd like to remove it from the archive.
[14:13] <persia> I'm less sure what do do about pj, and need to investigate some more to see if it can be ported to openjdk.
[14:14] <persia> Once those are resolved, we ought to be able to drop sun-java5 entirely.
[14:15] <persia> I seem to remember derby being of especial concern for glassfish.  Does anyone know if there's some reason we need so many derby implementations in Ubuntu?
[14:15] <persia> (we currently have sun-java6-javadb, sunwderby, and sun-javadb-*
[14:17] <persia> I guess not.
[14:17] <persia> Anyway, I'll see what I can do with pj, and file the removal for sunwderby, expecting users to be able to select one of the other two packages of the code if they need it.
[14:17] <persia> OK.  Anyone have anything off the roadmap to raise?
[14:18] <ttx> yep
[14:18] <ttx> I've been working on documentation
[14:18] <ttx> I've written a Java library packaging guide...
[14:18] <ttx> https://wiki.ubuntu.com/JavaTeam/LibraryPackaging
[14:19] <ttx> this can probably also be useful to non-libraryt Java packagers
[14:19] <ttx> I intend to work on a few other useful resources
[14:19] <ttx> one is a complete list of classes / jars / Java packages in Ubuntu
[14:20] <ttx> it's a little difficult today to find where a given class might be provided
[14:20] <ttx> or find collision in the Java namespace
[14:20] <persia> That latter would be incredibly useful: I've spent quite a bit of time over the past week hunting down to see how many of the jars in an upstream source we already have.
[14:20] <ttx> I'll write a script that takes all packages containing jars, read the contents of each jarfile in there
[14:21] <ttx> and make a big file (one class per line) with class - jar - package info
[14:21] <ttx> so that a quick grep should yield useful info
[14:21] <persia> I've also been reading the javahelper documentation, with it's hints about setting the right classpath and manifest inside each .jar.  Would it be worth it for that script to also check to see which packages would benefit from adding this?
[14:21] <ttx> (ok, maybe some awk/uniq might come handy)
[14:22] <ttx> persia: once ready I'll push the script in LP somewhere so that it can be used/extended/fixed for other purposes
[14:23] <persia> That's enough for me :)
[14:23] <ttx> I also want to create a list of "libraries wanted" in Ubuntu
[14:24] <ttx> then we can complete it if an ITP is in progress in Debian, etc
[14:24] <ttx> but at least list what is clearly missing
[14:24] <ttx> then some devweek exercises could be plugged in
[14:24] <persia> It's probably worth filing those as RFPs, and tracking it that way.  Except for rare cases, I think we'd generally want to add the libraries to Debian.
[14:25] <persia> We could use a usertag in the BTS to be able to collect a simple report of the outstanding ones of specific Ubuntu interest.
[14:25] <ttx> persia: yes. First step is still to make the list :)
[14:26] <persia> Sure.  I'll try to document the relevant BTS wrangling for the next meeting then.
[14:26] <ttx> I'll add related items to the roadmap
[14:26] <ttx> that's all for me.
[14:26] <persia> Individually, or shall we just have one item to add more libraries?
[14:26] <persia> (and a tracking page, etc.)
[14:26] <ttx> one item for the magic script, one item for "libraries wanted"
[14:26] <persia> Right.
[14:27] <persia> I don't have anything further.
[14:27] <ttx> me neither
[14:27] <persia> sommer, You mentioned you were just loitering, but do you want to add anything?
[14:28] <sommer> persia: don't have anything specific... like I mentioned the other day I was thinking about packaging ejbca for karmic, or helping to
[14:28] <sommer> I think it's doable, but I was also wondering if there are other J2EE apps already packaged
[14:30] <sommer> I might have the wrong terminology, but glassfish creates a default domain1, and other packages add themselves to it or do they need to create their own domain?
[14:30] <persia> You might look at libaopalliance-java
[14:30] <sommer> cool will do
[14:32] <sommer> that's all I had
[14:32] <persia> Alright then.  Meeting adjourned.
[14:33] <sommer> thanks persia
[23:58] <st33med> I almost thought the meeting was tomorrow :|