[08:06] <nikolam> Hi, can I use fridge calendar when calendar has moved to google calneda? Can I import ical calendar like before?
[08:06] <dholbach> nikolam: I answered in #ubuntu-devel
[08:12] <nikolam> thanks dholbach :)
[08:12] <dholbach> no worries
[12:00] <persia> OK.  Time for the Mobile meeting.
[12:00]  * lool waves
[12:00] <persia> #startmeeting
[12:00] <MootBot> Meeting started at 06:00. The chair is persia.
[12:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:00]  * GrueMaster Zzzzzzzz
[12:00] <lool> persia: I guess davidm_ can't make it?
[12:00]  * ogra waits for the stranding StevenK 
[12:00]  * NCommander is here
[12:00] <persia> lool, about 30%, I believe.
[12:00] <davidm_> I'm here
[12:01] <ogra> he said he would watch as much as he can
[12:01] <persia> Anyway: agenda is at https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090226
[12:01]  * StevenK shores
[12:01] <persia> [LINK] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090226
[12:01] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090226
[12:01] <persia> [TOPIC] outstanding action items (persia)
[12:01] <MootBot> New Topic:  outstanding action items (persia)
[12:01] <persia> I got distracted by something else, and completely forgot to check these, and will chase them all tomorrow.
[12:02] <lool> Ack; co I guess
[12:02] <persia> [TOPIC] outstanding action items (NCommander)
[12:02] <MootBot> New Topic:  outstanding action items (NCommander)
[12:02] <NCommander> licipc-sharelite-perl - some progress has been made, but still outstanding
[12:02] <NCommander> (I found the cause, but I'm localizing)
[12:02] <NCommander> Also working on ARM benchmarking, but that's not getting very far
[12:03] <NCommander> And I did the i386 jax10 testing, still can't test the lpia kernels (the lpia alternate CD kinda ... wonky)
[12:03] <NCommander> That's all for me.
[12:03] <persia> Um.  What about arm-softboot-loader and bug #280669?  (these were the action items from last week)
[12:03] <ogra> NCommander, you messed up the table on the roadmap
[12:04] <NCommander> persia, that was the jax10 testing
[12:04] <StevenK> I thought that bug was fixed?
[12:04] <NCommander> Semi-fixed
[12:04] <NCommander> I can see both SSD drives
[12:04] <NCommander> DMA still shot.
[12:04] <persia> OK.
[12:04] <lool> StevenK: The patch which I rescued might allow for faster SSD performance with a higher DMA mode
[12:05] <NCommander> lool, I can'tg et an lpia install on it to test apw's kernel
[12:05] <lool> NCommander: What's the problem?
[12:05] <NCommander> ubiquity doesn't work at 640x480
[12:05] <NCommander> WHich is what the MID image boots up as
[12:05] <lool> NCommander: And with the alternate CD?
[12:05] <NCommander> and I can't complete an install with the lpia CD, at least the dailies.
[12:06] <lool> How so?
[12:06] <ogra> where does it fail
[12:06] <ogra> and did you keep the installer log ?
[12:06] <NCommander> Partman has issues
[12:06] <NCommander> No
[12:06] <NCommander> SOmeone (persia I think) told me that the lpia image has kernel install problems
[12:06] <NCommander> so I'm trying a 8.10 lpia image, just so I can kill this testing image.
[12:07] <lool> NCommander: Otherwise, create an USB stick with the lpia kernel; getting dmesg output is all you need
[12:08] <lool> NCommander: Please file bugs if you discover issues on the jax10 with the current install CDs
[12:08] <lool> Well the ubiquity issue is know; having jaunty psb drivers might help too
[12:08] <NCommander> Alright, I'll do a full install and keep logs
[12:08] <NCommander> lool, actually, I was about to try that (I'm waiting for my pendisk to finish writing now)
[12:08] <ogra> it would be helpful if you did one std. install and saved the log somewhere public
[12:08] <persia> [ACTION] NCommander to report installer bugs with logs from jax10 install
[12:09] <MootBot> ACTION received:  NCommander to report installer bugs with logs from jax10 install
[12:09] <persia> Moving on...
[12:09] <persia> [TOPIC] outstanding action items (StevenK)
[12:09] <MootBot> New Topic:  outstanding action items (StevenK)
[12:09] <NCommander> ogra, it works fine with the i386 install, its just lpia that flakes out.
[12:09] <StevenK> Oh? What have I done?
[12:09] <ogra> NCommander, right, and a log will help
[12:09] <lool> # StevenK to file poulsbo packaging bugs (co)
[12:09] <persia> StevenK, StevenK to file poulsbo packaging bugs (co)
[12:10] <StevenK> I could have sworn there is a kernel bug
[12:10] <ogra> StevenK, StevenK, StevenK to file poulsbo packaging bugs (co)
[12:10] <ogra> :P
[12:10] <StevenK> Okay, so I need to actually find some time to file bugs for the packages we need for Intrepid?
[12:11] <StevenK> I'll make some time tomorrow to file them
[12:11] <persia> Yep.
[12:11] <persia> So, that's action item review.
[12:11] <persia> Next up: Roadmap.
[12:11] <persia> [topic] offline-installer
[12:11] <MootBot> New Topic:  offline-installer
[12:11] <persia> ogra^
[12:12] <ogra> still in "beta available"
[12:13] <ogra> i focused on the nslu2 A5 this week
[12:13] <persia> OK.
[12:13] <ogra> so no further progress
[12:13] <persia> [topic] unr-handling-jaunty
[12:13] <MootBot> New Topic:  unr-handling-jaunty
[12:13] <StevenK> Still proceeding. I think it shouldn't be Good Progress any more, but Beta Available, since we have nearly 3 alphas out
[12:14] <persia> Then flip the bit :)
[12:14] <StevenK> I shall :-)
[12:14] <persia> [topic] mobile-setup-wizard
[12:14] <MootBot> New Topic:  mobile-setup-wizard
[12:14] <lool> davidm: The links to specs on the Roadmap page are broken because they use the UbuntuSpec: shortcut which works only for blueprints in the Ubuntu project; did you care to have the blueprints filed under the ubuntu-mobile versus the ubuntu project?
[12:15] <persia> [topic] Roadmap management
[12:15] <MootBot> New Topic:  Roadmap management
[12:16] <cjwatson> NCommander: there are general problems with partitioning that seem to be racy, so I wouldn't label it as being just one architecture if I were you
[12:17] <lool> persia: Let's move back to mobile-setup-wizard; I'll change the project of the specs to be ubuntu
[12:17] <NCommander> cjwatson, I'm going to grab the lastest daily image and rerun the install, and grab the logs, and post the issues.
[12:17] <davidm> lool, sure
[12:17] <persia> lool, Sounds good.
[12:18] <persia> [topic] mobile-setup-wizard
[12:18] <MootBot> New Topic:  mobile-setup-wizard
[12:18] <persia> Not progress to report
[12:18] <persia> [topic] mobile-team-seed-management
[12:18] <MootBot> New Topic:  mobile-team-seed-management
[12:20] <persia> Do we still need this there?  Isn't it mostly blocked on ArchiveReorigansation at this point?
[12:20] <StevenK> Yes
[12:20] <StevenK> Drop it
[12:20] <persia> OK.
[12:20] <persia> [topic] general-resolution-for-touchscreen
[12:20] <MootBot> New Topic:  general-resolution-for-touchscreen
[12:20] <ogra> deferred ...
[12:20] <persia> [topic] arm-softboot-loader
[12:20] <MootBot> New Topic:  arm-softboot-loader
[12:21] <ogra> bug 334711 touches it though
[12:21] <ogra> (with an alternate solution request)
[12:21] <NCommander> No progress. I think we need to defer this one until jaunty+1, and work out specific if we want/need it, and how to implement it at UDS.
[12:22] <persia> [topic] selection-of-arm-images
[12:22] <MootBot> New Topic:  selection-of-arm-images
[12:22] <StevenK> persia: So, I reckon we add -all to MID
[12:22] <persia> StevenK, Ugly, but yes.
[12:22] <ogra> we have untested live images and no kernels to merge them yet
[12:22] <ogra> "in progress"
[12:23] <persia> [topic] lpia-versus-i386
[12:23] <MootBot> New Topic:  lpia-versus-i386
[12:23] <ogra> StevenK, i'd like to research clashes first before we blindly add -all, many old drivers dont work
[12:24] <lool> Nothing new to report on lpia-versus-i386
[12:24] <persia> [topic] mobile-spec-cleanup
[12:24] <MootBot> New Topic:  mobile-spec-cleanup
[12:24] <ogra> they are still in the ring and fighting :P
[12:24] <persia> I'll get back to it when my plate is clearer
[12:24] <persia> [topic] bug #299847
[12:24] <MootBot> New Topic:  bug #299847
[12:24] <lool> NCommander already reported on bug #299847; NCommander: you're not stuck at this point, right?
[12:24] <NCommander> We localized it to a race condition
[12:25] <NCommander> I'd like someone to review my test case, but it looks like its a perl problem vs. kernel
[12:25] <ogra> but you still didnt see it on any local HW, did you ?
[12:25] <lool> A Perl problem?.
[12:25] <StevenK> ogra: Fair enough, I'm subscribed to the bug, so just bleat there.
[12:25] <ogra> only on the porter box
[12:25] <NCommander> Well, I rewrote the perl test in C
[12:25] <NCommander> Using the same APIs the perl libraries does
[12:25] <NCommander> and I could not reproduce
[12:26] <NCommander> Which suggests the issue is not in the kernel or glibc, but somewhere in the library or perl itself. I don't see anything obvious from the library code though on what could be causing it.
[12:26] <lool> NCommander: Compare straces and see whether you're really reproducing the Perl case
[12:27] <lool> I would doubt the Perl layer changes anything, especially at it works on other hw; perhaps the timing is not the same
[12:27] <NCommander> I can't say I know enough about perl to say one way or another.
[12:28] <lool> Ok, I'll look at the testcase you wrote
[12:28] <NCommander> I'll attach it to the bug.
[12:29] <persia> [topic] bug #331510
[12:29] <MootBot> New Topic:  bug #331510
[12:29] <ogra> fixed
[12:29] <persia> Remove it then :)
[12:29] <persia> [topic] bug #322217
[12:29] <MootBot> New Topic:  bug #322217
[12:29] <persia> Also fixed :)
[12:29]  * persia previews
[12:29] <ogra> fixed :)
[12:29] <lool> 322217 is fix released as well
[12:29] <lool> Oh we skipped #331510
[12:30] <lool> No we didn't, it just goes too fast for me
[12:30] <persia> [topic] bug #319729
[12:30] <MootBot> New Topic:  bug #319729
[12:30] <ogra> we hit another bug with langpack installation during my A5 tests which cjwatson fixed immediately
[12:30] <lool> persia: This bug is moved to kernel team and it was decided to fix in a jaunty update
[12:30] <ogra> so its not recorded but will show up in A5 NSLU2 images, i'll file it and add it to the page
[12:30] <lool> because taking a contractor to fix this was too expensive, so we'll implement ourselves when we have time which is after jaunty
[12:30] <persia> Cool.  Unless we need further discussion or tracking in the meetings, let's drop it from the roadmap.
[12:31] <lool> Removed from roadmap
[12:31] <persia> [topic] bug #328167
[12:31] <MootBot> New Topic:  bug #328167
[12:31] <lool> Ah no, conflict
[12:31] <lool> Actually no <title>500 Internal Server Error</title>
[12:31] <lool> But it worked, eh
[12:31] <ogra> i didnt save
[12:31] <lool> I'd like someone to investigate 328167
[12:31] <ogra> so no conflict :)
[12:31] <lool> It's reported by jerone and is likely to affect all GNOME installs on armel
[12:32]  * ogra hasnt seen it ever
[12:32] <NCommander> I was talking with jerone on this
[12:32] <ogra> but jerone insists he sees it everywhere
[12:32] <NCommander> It only happens with fresh installations it seems
[12:32] <ogra> because he removes it right after the issue comes up ?
[12:33] <ogra> when does it go away exactly ? and how ?
[12:33] <NCommander> He says he kills the process
[12:33] <ogra> you said it only shows up with fresh installs ... so i assume it doesnt show up on older used ones ?
[12:33] <lool> Ok, would one of you two please investigate?
[12:34] <ogra> NCommander needs to stay on the initramfs stuff, i'll take a look next week
[12:34] <lool> Do a GNOME install on babbage and see whether you reproduce, if not ask jerone
[12:34] <persia> [action] ogra to investigate 328167
[12:34] <MootBot> ACTION received:  ogra to investigate 328167
[12:34] <lool> ogra: => assign
[12:34] <persia> [topic] NSLU2 enablement
[12:34] <MootBot> New Topic:  NSLU2 enablement
[12:35] <ogra> well, as i said above, d-i works so far apart from a bug with locale generation cjwatson fixed
[12:35] <ogra> but that fix isnt included in the A5 image
[12:35] <ogra> which makes an NSLU2 install 30h long or so
[12:35] <cjwatson> an infelicity rather than a bug, really
[12:35] <ogra> (generating one locale takes ~90min)
[12:36] <cjwatson> the bug is that localedef takes so much memory; that I haven't fixed ...
[12:36] <ogra> well, our d-i process was never designed for 30M systems :)
[12:36] <ogra> i guess i'm the first one ever to try ubuntu d-i on 30M :)
[12:36] <cjwatson> nothing really to do with its design
[12:37] <lool> Frankly, I wouldn't like the team spending much more time to make the installation on NSLU2 faster or more pleasant; we spent a lot of time on it already, and we have other things on our plates
[12:37] <persia> [topic] VFP optimisations
[12:37] <MootBot> New Topic:  VFP optimisations
[12:37] <ogra> lool, 30h arent acceptable
[12:37] <lool> So I spent most of last week on glibc; it was terribly time consuming as I hit a bunch of unrelated build issues
[12:37] <ogra> otherwise i agree
[12:38] <lool> I sent patches to Debian for these issues and worked around them; I isolated what was causing the hang -- actually extreme slowness
[12:38] <lool> Just calling nextafterf() takes 4.5 minutes on the porter box
[12:38] <lool> It is likely due to a bug of the Marvell FPU hardware, which Catalin (from ARM) hinted me at by pointing at a thread on linux-arm-kernel
[12:39] <ogra> erm, could it be that the perl issue is related ?
[12:39] <lool> The only solution seems to have an ifdef quirk in the kernel, albeit I'm not sure why this is true; I've contacted our two ARM contacts and two people I was told are working on the Marvell support in the ARM kernel
[12:39] <persia> Or if not related, similar in root cause
[12:39] <ogra> right
[12:39] <lool> ogra: No; it's not fp related
[12:39] <lool> I highly doubt it is
[12:40] <lool> So at this point I'll drop the glibc vfp pass and will work on other vfp work; I personally think this might hold up VFP enablement for packages where we run the testsuite during build
[12:41] <persia> [topic] ARM Benchmarking
[12:41] <MootBot> New Topic:  ARM Benchmarking
[12:41] <lool> I'll check with infinity whether we can build a new kernel with the patch included
[12:41] <persia> Err.  Sorry!
[12:41] <lool> It's ok; I'm done now
[12:41] <NCommander> ARMv5, ARMv5+some libs, ARMv5+fulLVFP done.
[12:42] <NCommander> I can't install mojo armv6 with the babbage via d-i, and QEMU doesn't have the necessary emulator support
[12:42] <NCommander> So I'm stuck ATM
[12:42] <lool> I have a candidate project to help us test Ubuntu binaries with random opt flags
[12:42] <lool> But I'd like to discuss it here first
[12:43] <lool> This might serve OEM or ourselves if we ever want to provide an optimized archive (still pretending to be armel)
[12:43] <lool> Or for testing of various opts
[12:43] <NCommander> I don't have anything else (unless we want to go indepth on my armv6 issues :-/)
[12:43] <lool> The idea I had is quite simple: use EC2 to mass-rebuild the archive in qemu
[12:43] <persia> lool, Won't that run into the cross-grade issues that mojo has?
[12:43] <NCommander> That won't work lool
[12:43] <lool> persia: cross-grade?
[12:43] <NCommander> at least for ARMv6/ARMv7
[12:43] <lool> So we need of course a patched qemu with omap3 support
[12:43] <persia> lool, e.g. mixing Debian and mojo breaks things.
[12:43] <davidm> NCommander, is there any way likely to work to get the installer to work for you?
[12:44] <ogra> there is the beagleboard qemu hack
[12:44] <lool> persia: Well if we use the good soft-float ABI, it shouldn't; not sure whether mojo did that
[12:44] <ogra> but that lacks support for the disk controller yet
[12:44] <NCommander> davidm, if I had access to something Hasty ARMv6 supports, I can generate the image and do the benchmarks, but I don't have anything with the right hardware
[12:44] <NCommander> I *think* the beagleboard could generate the image however.
[12:44] <lool> ogra: The problem is instruction set support I think
[12:44] <davidm> NCommander, send me a list of what they support please
[12:44] <NCommander> davidm, will do
[12:44] <ogra> it has the omap3 instruction set afaik
[12:45] <NCommander> Why don't we just pool all our ARM hardware and do an archive rebuild that way?
[12:45] <lool> ogra: Well then we're suggesting the same thing, add omap3 instruction set support to our qemu :-)
[12:45] <lool> NCommander: Because we use it?
[12:45] <ogra> but misses support for the peripherial chipsets yet
[12:45] <lool> ogra: We don't really care as long as it runs a virtual machine
[12:45] <NCommander> lool, so the builds run in the background ...
[12:45] <ogra> lool, no disk controller...
[12:45] <lool> NCommander: Also, from mojo experience it's far more effective to rebuild on a large cluster of x86 hw than on ARM hw
[12:45] <ogra> lool, you wont fit a whole archive in the flash
[12:45] <persia> I think we're looking at three different things now: benchmarking, optimised builds, and emulation improvements.  Shall we separate them?
[12:45] <NCommander> lool, mojo compiles on real hardware.
[12:46] <ogra> no disk contoller meaning no USB either
[12:46]  * NCommander has done some experimenting in the realm of optimized rebuilds ...
[12:46] <lool> NCommander: I'm rebooting, I don't have tons of space, and some packages are very long to build (e.g. glibc takes days on an evm -- didn't complete, and a day on babbage)
[12:46] <lool> NCommander: No
[12:46] <lool> NCommander: It used to and moved to qemu
[12:46] <NCommander> I'd like to know how they did the armv6 builds then ...
[12:46] <lool> They used to build on thecus and moved to dell x86 servers running qemu
[12:46] <ogra> right
[12:47] <NCommander> Because if there is patches for QEMU for ARMv6, I can generate the last image I need to do my benchmarks.
[12:47] <persia> NCommander, mojo is native-compiled inside QEMU, rather than cross-compiled, but it's still on x86.
[12:47] <lool> NCommander: They aren't qemu mainline but patch support for the instruction set in?
[12:47] <lool> +using
[12:47]  * NCommander looked and didn't see any
[12:47] <NCommander> If you know where they are, please send me a link :-)
[12:47] <lool> Anyway, I think the proposal is appealing because we have unlimited computing power on EC2 and if we develop such a mass build infrastructure we have a good story for:
[12:48] <lool> - people needing to build armel packages -- no armel PPA, remember
[12:48] <lool> - testing opt flags
[12:48] <lool> - OEM
[12:48] <lool> - QA mass rebuilds
[12:48] <NCommander> lool, well, I have no objection to doing that (I even can help setup the infrastructure to do it)
[12:48] <ogra> ++
[12:48] <lool> - maemo folks wanting to build armel packages for maemo   ;-)
[12:48] <NCommander> I'm just not sure QEMU has the support
[12:48] <persia> lool, Do you want to add that to the roadmap?
[12:48]  * NCommander has set up the entire software stack for Debian/m68k before ...
[12:48] <lool> persia: I wanted to see what people think of it, and whether we can devote time to it
[12:49] <ogra> NCommander, the beagle patch adds that support ...
[12:49]  * NCommander needs to find it
[12:49] <ogra> and there should be other patches that are less board specific and hackish
[12:49] <NCommander> If I could get versalite with armv6/7, we'd be in business
[12:49] <ogra> http://beagleboard.org/project/qemu-omap3/
[12:49] <MootBot> LINK received:  http://beagleboard.org/project/qemu-omap3/
[12:49] <lool> My idea was to create a script to create an EC2 image which would support building any type of packages -- armel on jaunty or others -- and a master "archive" image; then it's trivial to do the rebuild
[12:50] <lool> StevenK, davidm: Comments?
[12:50] <lool> ogra seems to like the idea, NCommander isn't sure it's possible but doesn't seem to mind
[12:50] <lool> persia: Comments?
[12:50] <davidm> lool, I think it's a good use of EC2 resources, I was exploring something like this with some friends that do ARM stuff
[12:50] <NCommander> lool, well, I know it will work for ARMv5 rebuilds
[12:50] <StevenK> lool: Hm. Unsure.
[12:50] <NCommander> Its just ARMv6 I'm unsure about.
[12:51] <persia> I'm intrigued by the idea, but think it needs a bunch of research on emulation and fear that might interfere with bugfixing in the next couple months.
[12:51] <lool> StevenK: I think it's the good time to raise your concerns
[12:51] <StevenK> lool: I have concerns about supportability, but not building it
[12:51] <lool> persia: I agree, I think it should be low priority, unless we consider it critical to test flags for jaunty+1 in time
[12:51] <NCommander> persia, it won't be very difficult to setup to have it track the main archive.
[12:52] <lool> StevenK: You mean supporting users which would like to build their packages?  indeed, that's a good point
[12:52] <persia> StevenK, Supportability of the vm-builder script that produces the ec2 image, or supportability of the results of having such a tool available?
[12:52] <NCommander> You'd setup wanna-build to track the main archive, and then make sure sbuild is uploading full packages to your source archive. (or use rebuildd)
[12:52] <StevenK> Supportability of an archive if we publish it
[12:52] <persia> NCommander, keeping persistent tracking in EC2 gets expensive quickly.
[12:53] <NCommander> persia, we could run wanna-build and the archive software outside of EC2
[12:53] <persia> Oh.  I'd be against even hinting at support for any result packages, whether standalone or in an archive.
[12:53] <lool> StevenK: Oh we can discuss what we do with the archives later on
[12:53] <lool> Right it's no support, internal use only
[12:53] <StevenK> Fair enough. No other concerns I can think of
[12:53]  * NCommander is +1 for the no support one
[12:54] <lool> Ok; I guess it needs spec-ing then
[12:54] <lool> I'll start a rough draft of my initial ideas and call for comments
[12:54] <lool> persia: please [action] me on that
[12:54] <persia> [action] lool to spec ec2-package-builder for jaunty+1
[12:54] <MootBot> ACTION received:  lool to spec ec2-package-builder for jaunty+1
[12:54] <lool> davidm: You wanted to bring up a last topic
[12:54] <persia> Wait!
[12:54] <persia> That's roadmap.
[12:55] <persia> Next is agenda items.
[12:55] <persia> Nothing shown.
[12:55] <persia> So...
[12:55] <persia> [topic] any other business
[12:55] <MootBot> New Topic:  any other business
[12:55] <davidm> I  was wondering if we have discussed the softbootloader with cjwatson  recently?  I know we somewhat stalled on this
[12:55] <lool> persia: Exactly :-)
[12:55] <persia> [topic] arm-softboot-loader
[12:55] <MootBot> New Topic:  arm-softboot-loader
[12:56] <davidm> It may be less critical but I hate to lose track and complete headway on it.
[12:56] <ogra> davidm, do we have a requirement for it in jaunty ?
[12:56] <persia> lool, I just want the mootbot logs organised to make writing the minutes easier :)
[12:56] <ogra> i dont thnk we need it for anything yet
[12:56] <lool> cjwatson: I think we discussed this spec in its infancy with you; in the mean time we had a fair number of implementation ideas; also there are some concerns with the kboot/petitboot implementations; finally there's the concern of boot time
[12:56] <NCommander> We don't even have the necessary kernel support (kexec) we wanted for the designs we were thinking of.
[12:56] <davidm> ogra, it's getting decreasing small for the need, but I don't want to lose track and research, we will need for J+1 for sure
[12:57] <lool> cjwatson: If you're around, do you think we could discuss the spec with you in the next week?
[12:57] <ogra> davidm, yes, so it deserves UDS discussion and pre-UDS research
[12:57] <lool> NCommander: Do we have a bug for that?
[12:57] <persia> lool, We have a spec for it.
[12:57] <ogra> which is why NCommander shold redo the spec with that in mind
[12:57]  * NCommander searches
[12:57] <ogra> *should
[12:57] <lool> persia: I think kexec being broken warrants a bug
[12:57] <persia> Oh, right.
[12:57] <davidm> I just don't want to lose what we have done to date and I don't want to miss something
[12:58] <NCommander> I remember filing one
[12:58] <ogra> so we can have a UDS discussion based on the research data
[12:58] <NCommander> But it may have just been upstream, and not in LP
[12:58] <lool> NCommander: If you don't find it, please file one
[12:58] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/319240
[12:58]  * NCommander resets that back to Triaged
[12:58] <NCommander> That was my first stab at a patch, which only fixed it on QEMU due to emulator quarks.
[12:58] <lool> NCommander: You confirm it's broken even in 2.6.28/jaunty/qemu?
[12:59] <NCommander> yeah
[12:59]  * ogra would still like to know if it fails with the packages kexec
[12:59] <NCommander> and in 2.6.29
[12:59] <ogra> *packaged
[12:59] <NCommander> ogra, I tried it with every version I can find
[12:59] <lool> NCommander: And same test case passes on x86?
[12:59] <NCommander> Its a kernel issue :-/, the kexec syscall busted
[12:59] <ogra> you built it yourself from upstream source, right ?
[12:59] <NCommander> ogra, yes
[13:00] <ogra> so i'd like to see a test of the packaged version that has ubuntu patches and all
[13:00] <lool> I'd like to know whether it works on x86 in qemu
[13:00] <ogra> note that kexec is used by the kernel team for debugging ourposes
[13:00] <NCommander> lool, I remember testing it, but the Ubuntu kernel ships with kexec disabled on x86 by default
[13:00] <NCommander> I can test it in QEMU
[13:00] <ogra> that cant be
[13:00] <NCommander> ogra, we use the crash kernel support, but the reboot bit
[13:00] <persia> We're up on time.  can details continue in another channel for this (maybe #ubuntu-arm)?
[13:00] <lool> persia: Mind actionning NCommander a coulple of times?
[13:00] <NCommander> SUre, no problem
[13:00] <lool> I think that's going to be good enough for today
[13:01] <persia> [action] ncommander to test packages kexec
[13:01] <MootBot> ACTION received:  ncommander to test packages kexec
[13:01] <ogra> please talk to the kernel team about it, i know kexec is used a lot there
[13:01] <lool> cjwatson: Perhaps we can setup a meeting this week between mobile team and you to discuss the kexec path?
[13:01]  * NCommander talked about this with them at the last sprint
[13:01] <persia> [action] NCommander to test with x86
[13:01] <MootBot> ACTION received:  NCommander to test with x86
[13:02] <lool> persia: thanks for chairing
[13:02] <ogra> yeah, thanks
[13:02] <persia> [topic] any other business
[13:02] <MootBot> New Topic:  any other business
[13:02] <davidm> thanks persia
[13:02] <persia> If you have some, please put it on the agenda for the next meeting, we're out of time.
[13:02] <persia> #endmeeting
[13:02] <MootBot> Meeting finished at 07:02.
[13:02] <ogra> and move to -arm or -mobile for further discussion :)
[13:02] <persia> minutes should be up in ~20 minutes
[13:02]  * GrueMaster crawls back to his cave.
[13:21] <cjwatson> lool: I guess so
[13:22] <cjwatson> lool: it was really just a random idea from me though; I'm not convinced I'm an expert
[13:23] <lool> cjwatson: Ok; then I'd like to quickly update you on a couple things in this spec: a) kboot/petitboot turned out to not be in a very good shape according to Michael b) Oliver implemented a prototype boot menu in an initramfs shell function c) we discovered there were a bunch of boot menu projects for beagleboard
[13:24] <lool> cjwatson: I personally concluded we didn't want a), I didn't like the shell-based terminal tricks of b) (kind of a shell ncurses implementation), so I would personally recommend c), and falling back to b) if we really want to continue with a kexec route
[13:24] <lool> cjwatson: Does that make sense?
[13:28] <ogra> b) doesnt need to be like that
[13:29] <ogra> it can be way smaller and less gui
[13:36] <cjwatson> lool: sounds fine to me modulo ogra's comments
[14:01] <persia> Who's here for the Java Meeting?
[14:01] <ttx> o/ <- the hacker formerly known as Koon
[14:02] <persia> Ah.  Saving electrons, I see :)
[14:03] <ttx> compression is good.
[14:05] <persia> Anyone else?
[14:08] <ttx> apparently not.
[14:08] <persia> ttx, Anything exciting, or shall we skip this week, and try again next week?
[14:09] <ttx> I've started to write https://wiki.ubuntu.com/JavaTeam/LibraryPackaging
[14:09] <ttx> based on my recent experiences
[14:10] <persia> Oh, that's exciting.  Are you planning to add it to the KnowledgeBase when you're done?
[14:10] <ttx> once it's done we could make a list of wanted packages
[14:10] <persia> https://wiki.ubuntu.com/JavaTeam/KnowledgeBase
[14:10] <ttx> yes, I need to clean up the other howtos that are referenced from there
[14:11] <ttx> The idea is to more aggressively use java libraries as example packages for DevWeeks or other open forums
[14:11] <ttx> and hopefully gather some momentum on that.
[14:11] <persia> Excellent idea.  I'm currently working on an application package: I'll document my steps, and try to have a mirror doc to match.
[14:12] <ttx> One of the tricks is to make sure we don't duplicate effort w/ debian
[14:12] <ttx> and make sure our work is pushed back there
[14:12] <ttx> On that subject, tomcat6 recently made it back to Debian
[14:12] <ttx> thanks to Torsten Werner that took our current Jaunty version up there
[14:13] <persia> Nifty.
[14:13] <ttx> So if we make a wishlist,we'll make sure it's communicated to the appropriate people in debian-java
[14:14] <persia> slytherin is often a good person for that, sitting in both camps (and with commit access to pkg-java on alioth).
[14:14] <persia> If you're expecting to handle a bunch of libraries, you might want to take that path as well.
[14:15] <ttx> I'm not expecting to do a lot of them. I want to empower several others to do it though.
[14:15] <ttx> mentoring, documentation
[14:15] <ttx> sounds like a better long-term solution.
[14:15] <persia> Then it's not so essential to have commit :)
[14:16] <persia> So, until next week then?
[14:16] <ttx> anyway, I expect slytherin to participate into validating https://wiki.ubuntu.com/JavaTeam/LibraryPackaging
[14:16] <ttx> yes, nothing else on my front
[14:17] <persia> OK.  I7ve nothing.  See you on the 5th.
[14:17] <ttx> ok
[16:52] <nixternal> 10 Minute Notice - Ubuntu MOTU Council Meeting - #ubuntu-meeting
[16:52] <nixternal> more like 8 now :p
[16:52] <RainCT> heh
[16:57]  * persia polishes the MootBot controls
[16:58]  * vorian read that as persia polishes his boots
[16:59] <persia> That too :)
[17:00] <persia> #startmeeting
[17:00] <MootBot> Meeting started at 11:00. The chair is persia.
[17:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:00] <persia> So, welcome everyone to the first MOTU Council applications processing meeting.
[17:00] <persia> Err, second ever.
[17:01] <persia> According to https://wiki.ubuntu.com/MOTU/Council/Meeting we have only one application to process today
[17:01] <persia> [link] https://wiki.ubuntu.com/MOTU/Council/Meeting
[17:01] <MootBot> LINK received:  https://wiki.ubuntu.com/MOTU/Council/Meeting
[17:01] <persia> So, first up, do we have quorum?
[17:01]  * geser is here
[17:02] <persia> nixternal, ?  soren ?
[17:02] <nixternal> yo yo
[17:02] <nixternal> that would be a quorum
[17:02] <persia> Right.
[17:02] <persia> Well, then.
[17:02] <persia> [topic] Core Developer Application for Steve Stalcup (vorian)
[17:03] <MootBot> New Topic:  Core Developer Application for Steve Stalcup (vorian)
[17:03] <persia> [link] https://wiki.ubuntu.com/StephenStalcup/CoreDeveloperApplication
[17:03] <MootBot> LINK received:  https://wiki.ubuntu.com/StephenStalcup/CoreDeveloperApplication
[17:03]  * vorian waves
[17:05] <persia> vorian, You mention you're planning on a bunch more Kubuntu uploads.  Do you anticipate any changes in the content of these uploads if you're a core-dev, rather than working through sponsors?
[17:05] <vorian> persia: we are in the process of waiting for KDE 4.2.1 to be pushed out to packagers
[17:06] <vorian> this round, I will need to work throught sponosrs again
[17:07] <vorian> for sanity sake, if i were a core dev - i would have a trusted friend look over my changes
[17:07] <vorian> the only changes with this next release will be bug-fixes
[17:07] <vorian> we simply remove patches, and make sure the upstream changes are sane
[17:11] <nixternal> sorry, was reading through his app
[17:11] <nixternal> I know Steve's history here in buntuland (very much like candyland I must say)
[17:12] <nixternal> I am sure I sponsored some stuff back in the day, as a matter of fact I know I did...I remember him going REVU crazy and bugging the heck out of me with REVUs a while back
[17:12] <vorian> yeah, sorry about that :)
[17:12] <nixternal> he is quick, good, and exactly what we need, we not only being the Kubuntu community, but also the entire Ubuntu community
[17:13] <nixternal> heh, I was reading ScottK-desktop's feedback and misread "ice storm" as "ice cream"...
[17:13] <vorian> that ice storm was not fun at all ...
[17:14] <nixternal> vorian: have you followed the "Archive Reorganization" topic at all?
[17:14] <vorian> nixternal: somewhat, not enough to have an informed opinion
[17:14] <nixternal> sounds like me :p
[17:14] <vorian> :)
[17:15] <vorian> I understand that the archive will be mostly open, save a handful of extremely core packages
[17:15] <nixternal> what other plans do you have for the server team? do you see yourself working more with them and doing something 50/50 between them and Kubuntu? or will you be doing a majority of your work with Kubuntu/KDE packages and a package here-or-there with the server team?
[17:16] <nixternal> I have always wanted to hack on the kernel, but I don't think Ben C. will let me :p
[17:16] <vorian> That is a great question
[17:16] <nixternal> well then, I expect a great answer :)
[17:16] <vorian> The server side of things for me is _very_ new, and I was reluctant to even add it to my application
[17:17] <vorian> I asked ScottK how I could test the waters out, and he pointed me in the right direction
[17:17] <nixternal> groovy...how did you like the waters?
[17:18] <vorian> it's been great so far
[17:18] <vorian> I've been working on getting rid of old libdb cruft
[17:18] <vorian> and as of Monday, libdb4.5 is history \o/
[17:19] <vorian> I am hitting a snag with libdb4.4 - and trying to seek a solution with the debian pkg-lustre-maintainers
[17:20] <nixternal> ya, libdb wasn't any fun for me either, as I did pretty much the same thing you did, just with CentOS and my last job
[17:20] <vorian> not fun at all
[17:20] <nixternal> groovy, how has working with the debian devs been for you?
[17:20] <vorian> I would like to do 50/50, but with the lack of packagers at the moment, it's going to be hard
[17:20] <nixternal> one thing I tend to enjoy the most is working with the Debian peeps when I get a chance...especially the Qt/KDE team, who are some packaging monsters
[17:21] <vorian> I have taken on the challenge of hosting our release building tools (some secret/some not)
[17:21] <nixternal> ahh ya, with the temporary (I hope) loss of Harald, I know it is going to be tough
[17:21] <vorian> he set us up with a great foundation
[17:21] <nixternal> who is "our" (I Know, but nobody else may not)
[17:21] <nixternal> and why are some secret?
[17:22] <vorian> although, I'm on my 3rd ruby book
[17:22] <nixternal> I won't hold that against you
[17:22] <vorian> ours refers to kubuntu ninja's
[17:22] <vorian> ninjas are the kubuntu team of packagers who do KDE release updates
[17:22] <nixternal> what all do these building tools do? refresh my memory because I have been an absent ninja for almost a year
[17:23] <vorian> ok
[17:23] <vorian> they are dubbed 'batscripts' (written in ruby)
[17:24] <nixternal> oh man, I do not want to learn ruby...it isn't in my planned "learn 2 languages this year" routine...for some reason, I have become a ruby hater
[17:24] <vorian> actually, let me get the bzr link for that
[17:24] <nixternal> why are some of them secret?
[17:25] <vorian> There are secrets because KDE allows packagers to have release ready versions a week or so before they are released to the public
[17:26] <vorian> This allows us to get better quality packages
[17:26] <nixternal> ahh, so I am guessing the secret sauce here has information on how to get the packager releases?
[17:26] <vorian> what secret sauce?
[17:26] <nixternal> the secret scripts :p
[17:26] <nixternal> you said some of the batscripts are secret
[17:26] <vorian> they are published
[17:27] <persia> Is it that the scripts are secret, or the credentials for early access?
[17:27] <vorian> bzr branch lp:kubuntu-dev-tools
[17:27] <vorian> the scripts are not secret, just the tarballs
[17:27] <nixternal> gotcha
[17:27] <nixternal> well, I am ready to vote, persia? geser? soren?
[17:28] <vorian> sorry for any confusion
[17:28] <geser> one question
[17:28] <vorian> fire away :)
[17:29] <geser> Harald mentioned in his comment a messed kde4libs update. What went wrong and how do you want to prevent it from happening in the future?
[17:29] <vorian> as a rule, we tend to follow Debian packaging methods
[17:31] <vorian> kdelibs is vital to the entire KDE stack.  With the last release - I got my directories reversed (an un-noticed merge to say)
[17:32] <vorian> from that time, I have made it a habbit of creating a new clean directory, and diffing the two
[17:33] <vorian> If I would have done that, I would have caught the mistake - it was only a coulple of build-dep versions, but caused all other packages to fail due to dependancy issues
[17:34] <vorian> I also will stay away from merging until after releases are complete, and published :)
[17:34] <geser> persia, soren: your turn with questions
[17:34] <persia> vorian: In your application you mention your pbuilder foo: have you considered merging it with ubuntu-dev tools?  Why or why not?
[17:35] <persia> Or, more specifically, If so, why didn't you, and if not, why not?
[17:35] <vorian> persia: it's not an application per se, it's more of a guide to set up multiple pbuilders
[17:36] <vorian> I wouldn't mind adding a few things to the Pbuilder wiki page
[17:36] <persia> Yes.  That's why I ask :)  Some of it looks remarkably like pbuilder-dist
[17:36] <nixternal> well add it, I need to set up pbuilder on my new machine here
[17:36] <vorian> I will do it today :)
[17:37] <persia> So, the answer is: you didn't consider it, and that was because you hadn't thought of it?
[17:37] <RainCT> vorian, nixternal: Are you aware of pbuilder-dist (rewritten version in jaunty and intrepid-backports)? If there's some use case for which it doesn't work please tell me.
[17:37] <nixternal> RainCT: yes I am...I am lazy and just want a simple copy paste pbuilderrc :p
[17:38] <vorian> persia: I hadn't thought of it really
[17:38] <persia> vorian, Right.  So the second part of the question: as a core-dev, you'll be uploading to the core part of Ubuntu, on which everything relies.  What strategies to you expect to employ to avoid similar sorts of duplication in the future?
[17:42] <vorian> As for packages, I will continue to triple check those I am confident of
[17:42] <vorian> when I have the slightest doubt, I will consult with the prior uploader - or last person to commit a change
[17:43] <vorian> with something like the pbuilder-foo page, that was mostly documentation for myself - and those I was trying to help create multiple pbuilders.
[17:45] <vorian> I'll just make note of changing wiki pages as I come across something that may be done better/or differently
[17:45] <vorian> I shy away from changing any of the major wiki pages, which is something I can correct
[17:46] <persia> Well, there's a balance of course :)
[17:46] <vorian> yes :)
[17:46] <persia> soren, seems to have been idle for an improbable number of minutes.  geser, nixternal, ready for voting?
[17:46] <nixternal> yes
[17:47] <geser> yes
[17:47] <persia> [vote] Recommend Steve Stalcup (vorian) to become an ubuntu-core-dev
[17:47] <MootBot> Please vote on:  Recommend Steve Stalcup (vorian) to become an ubuntu-core-dev.
[17:47] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[17:47] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[17:47] <persia> +1
[17:47] <MootBot> +1 received from persia. 1 for, 0 against. 0 have abstained. Count is now 1
[17:47] <geser> persia: just didn't want to disturb your questioning :)
[17:47] <geser> +1
[17:47] <MootBot> +1 received from geser. 2 for, 0 against. 0 have abstained. Count is now 2
[17:47] <nixternal> +1
[17:47] <MootBot> +1 received from nixternal. 3 for, 0 against. 0 have abstained. Count is now 3
[17:47] <vorian> Thanks persia geser, and nixternal :)
[17:47] <persia> [endvote]
[17:47] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[17:47] <johnc4510> vorian: congrats!! w00t
[17:48] <RainCT> vorian: congrats! :)
[17:48] <persia> vorian, so, we'll recommend you to the TB, who will surely have an even more extreme set of questions for you to answer :)
[17:48] <RainCT> vorian: and check out pbuilder-dist! ;)
[17:48] <vorian> :)
[17:48] <persia> So, that completes our scheduled topics.
[17:48] <vorian> thanks RainCT and johnc4510 :)
[17:48] <persia> Anyone have anything special they want to raise before we adjourn?
[17:49] <nixternal> vorian: congrats on this leg of your journey, you just wait until mdz, cjwatson, and others grill you :D
[17:49] <vorian> ohmy
[17:49] <vorian> thanks :)
[17:49] <nixternal> nothing here persia
[17:50] <persia> Right.  Meeting adjourned then.
[17:50] <persia> #endmeeing
[17:50] <nixternal> you have to do it like endvote iirc
[17:52] <nixternal> persia: [endmeeting] ?
[17:55] <persia> [endmeeting]
[17:56] <persia> No, it7s #endmeeting.  I just have to include the letter 't'
[17:56] <persia> #endmeeting
[17:56] <MootBot> Meeting finished at 11:56.
[17:56] <persia> See :)
[17:56] <nixternal> ahh, you just can't speel :p