500 Internal Server Error

=== Andre_Gondim is now known as Andre_Gondim-afk [08:06] Hi, can I use fridge calendar when calendar has moved to google calneda? Can I import ical calendar like before? [08:06] nikolam: I answered in #ubuntu-devel [08:12] thanks dholbach :) [08:12] no worries === GrueMaster1 is now known as GrueMaster [12:00] OK. Time for the Mobile meeting. [12:00] * lool waves [12:00] #startmeeting [12:00] Meeting started at 06:00. The chair is persia. [12:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:00] * GrueMaster Zzzzzzzz [12:00] persia: I guess davidm_ can't make it? [12:00] * ogra waits for the stranding StevenK [12:00] * NCommander is here [12:00] lool, about 30%, I believe. [12:00] I'm here [12:01] he said he would watch as much as he can [12:01] Anyway: agenda is at https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090226 [12:01] * StevenK shores [12:01] [LINK] https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090226 [12:01] LINK received: https://wiki.ubuntu.com/MobileTeam/Meeting/2009/20090226 [12:01] [TOPIC] outstanding action items (persia) [12:01] New Topic: outstanding action items (persia) [12:01] I got distracted by something else, and completely forgot to check these, and will chase them all tomorrow. === davidm_ is now known as davidm [12:02] Ack; co I guess [12:02] [TOPIC] outstanding action items (NCommander) [12:02] New Topic: outstanding action items (NCommander) [12:02] licipc-sharelite-perl - some progress has been made, but still outstanding [12:02] (I found the cause, but I'm localizing) [12:02] Also working on ARM benchmarking, but that's not getting very far [12:03] And I did the i386 jax10 testing, still can't test the lpia kernels (the lpia alternate CD kinda ... wonky) [12:03] That's all for me. [12:03] Um. What about arm-softboot-loader and bug #280669? (these were the action items from last week) [12:03] NCommander, you messed up the table on the roadmap [12:03] Launchpad bug 280669 in linux "Doesn't detect second part of SSD drive on jax10" [Low,Incomplete] https://launchpad.net/bugs/280669 [12:04] persia, that was the jax10 testing [12:04] I thought that bug was fixed? [12:04] Semi-fixed [12:04] I can see both SSD drives [12:04] DMA still shot. [12:04] OK. [12:04] StevenK: The patch which I rescued might allow for faster SSD performance with a higher DMA mode [12:05] lool, I can'tg et an lpia install on it to test apw's kernel [12:05] NCommander: What's the problem? [12:05] ubiquity doesn't work at 640x480 [12:05] WHich is what the MID image boots up as [12:05] NCommander: And with the alternate CD? [12:05] and I can't complete an install with the lpia CD, at least the dailies. [12:06] How so? [12:06] where does it fail [12:06] and did you keep the installer log ? [12:06] Partman has issues [12:06] No [12:06] SOmeone (persia I think) told me that the lpia image has kernel install problems [12:06] so I'm trying a 8.10 lpia image, just so I can kill this testing image. [12:07] NCommander: Otherwise, create an USB stick with the lpia kernel; getting dmesg output is all you need [12:08] NCommander: Please file bugs if you discover issues on the jax10 with the current install CDs [12:08] Well the ubiquity issue is know; having jaunty psb drivers might help too [12:08] Alright, I'll do a full install and keep logs [12:08] lool, actually, I was about to try that (I'm waiting for my pendisk to finish writing now) [12:08] it would be helpful if you did one std. install and saved the log somewhere public [12:08] [ACTION] NCommander to report installer bugs with logs from jax10 install [12:09] ACTION received: NCommander to report installer bugs with logs from jax10 install [12:09] Moving on... [12:09] [TOPIC] outstanding action items (StevenK) [12:09] New Topic: outstanding action items (StevenK) [12:09] ogra, it works fine with the i386 install, its just lpia that flakes out. [12:09] Oh? What have I done? [12:09] NCommander, right, and a log will help [12:09] # StevenK to file poulsbo packaging bugs (co) [12:09] StevenK, StevenK to file poulsbo packaging bugs (co) [12:10] I could have sworn there is a kernel bug [12:10] StevenK, StevenK, StevenK to file poulsbo packaging bugs (co) [12:10] :P [12:10] Okay, so I need to actually find some time to file bugs for the packages we need for Intrepid? [12:11] I'll make some time tomorrow to file them [12:11] Yep. [12:11] So, that's action item review. [12:11] Next up: Roadmap. [12:11] [topic] offline-installer [12:11] New Topic: offline-installer [12:11] ogra^ [12:12] still in "beta available" [12:13] i focused on the nslu2 A5 this week [12:13] OK. [12:13] so no further progress [12:13] [topic] unr-handling-jaunty [12:13] New Topic: unr-handling-jaunty [12:13] Still proceeding. I think it shouldn't be Good Progress any more, but Beta Available, since we have nearly 3 alphas out [12:14] Then flip the bit :) [12:14] I shall :-) [12:14] [topic] mobile-setup-wizard [12:14] New Topic: mobile-setup-wizard [12:14] 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] [topic] Roadmap management [12:15] New Topic: Roadmap management [12:16] 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] persia: Let's move back to mobile-setup-wizard; I'll change the project of the specs to be ubuntu [12:17] cjwatson, I'm going to grab the lastest daily image and rerun the install, and grab the logs, and post the issues. [12:17] lool, sure [12:17] lool, Sounds good. [12:18] [topic] mobile-setup-wizard [12:18] New Topic: mobile-setup-wizard [12:18] Not progress to report [12:18] [topic] mobile-team-seed-management [12:18] New Topic: mobile-team-seed-management [12:20] Do we still need this there? Isn't it mostly blocked on ArchiveReorigansation at this point? [12:20] Yes [12:20] Drop it [12:20] OK. [12:20] [topic] general-resolution-for-touchscreen [12:20] New Topic: general-resolution-for-touchscreen [12:20] deferred ... [12:20] [topic] arm-softboot-loader [12:20] New Topic: arm-softboot-loader [12:21] bug 334711 touches it though [12:21] Launchpad bug 334711 in mobile-meta "Ubuntu MID misses several X input drivers" [Undecided,New] https://launchpad.net/bugs/334711 [12:21] (with an alternate solution request) [12:21] 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] [topic] selection-of-arm-images [12:22] New Topic: selection-of-arm-images [12:22] persia: So, I reckon we add -all to MID [12:22] StevenK, Ugly, but yes. [12:22] we have untested live images and no kernels to merge them yet [12:22] "in progress" [12:23] [topic] lpia-versus-i386 [12:23] New Topic: lpia-versus-i386 [12:23] StevenK, i'd like to research clashes first before we blindly add -all, many old drivers dont work [12:24] Nothing new to report on lpia-versus-i386 [12:24] [topic] mobile-spec-cleanup [12:24] New Topic: mobile-spec-cleanup [12:24] they are still in the ring and fighting :P [12:24] I'll get back to it when my plate is clearer [12:24] [topic] bug #299847 [12:24] New Topic: bug #299847 [12:24] Launchpad bug 299847 in linux "Shared memory operations on very fast ARM hardware suffer from non-atomic operations and race conditions." [High,Triaged] https://launchpad.net/bugs/299847 [12:24] NCommander already reported on bug #299847; NCommander: you're not stuck at this point, right? [12:24] We localized it to a race condition [12:25] I'd like someone to review my test case, but it looks like its a perl problem vs. kernel [12:25] but you still didnt see it on any local HW, did you ? [12:25] A Perl problem?. [12:25] ogra: Fair enough, I'm subscribed to the bug, so just bleat there. [12:25] only on the porter box [12:25] Well, I rewrote the perl test in C [12:25] Using the same APIs the perl libraries does [12:25] and I could not reproduce [12:26] 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] NCommander: Compare straces and see whether you're really reproducing the Perl case [12:27] I would doubt the Perl layer changes anything, especially at it works on other hw; perhaps the timing is not the same [12:27] I can't say I know enough about perl to say one way or another. [12:28] Ok, I'll look at the testcase you wrote [12:28] I'll attach it to the bug. [12:29] [topic] bug #331510 [12:29] New Topic: bug #331510 [12:29] Launchpad bug 331510 in linux "ixp4xx kernel to big to use with debian-installer on NSLU2" [High,Fix released] https://launchpad.net/bugs/331510 [12:29] fixed [12:29] Remove it then :) [12:29] [topic] bug #322217 [12:29] New Topic: bug #322217 [12:29] Launchpad bug 322217 in linux "ixp4xx image does not boot" [High,Fix released] https://launchpad.net/bugs/322217 [12:29] Also fixed :) [12:29] * persia previews [12:29] fixed :) [12:29] 322217 is fix released as well [12:29] Oh we skipped #331510 [12:30] No we didn't, it just goes too fast for me [12:30] [topic] bug #319729 [12:30] New Topic: bug #319729 [12:30] Launchpad bug 319729 in ubuntu-release-notes "ARM architecture lacks support for pselect() and ppoll()" [Undecided,Confirmed] https://launchpad.net/bugs/319729 [12:30] we hit another bug with langpack installation during my A5 tests which cjwatson fixed immediately [12:30] persia: This bug is moved to kernel team and it was decided to fix in a jaunty update [12:30] so its not recorded but will show up in A5 NSLU2 images, i'll file it and add it to the page [12:30] 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] Cool. Unless we need further discussion or tracking in the meetings, let's drop it from the roadmap. [12:31] Removed from roadmap [12:31] [topic] bug #328167 [12:31] New Topic: bug #328167 [12:31] Launchpad bug 328167 in gnome-keyring "gnome-keyring-daemon eating 100% CPU at login in Jaunty" [Medium,Incomplete] https://launchpad.net/bugs/328167 [12:31] Ah no, conflict [12:31] Actually no 500 Internal Server Error [12:31] But it worked, eh [12:31] i didnt save [12:31] I'd like someone to investigate 328167 [12:31] so no conflict :) [12:31] It's reported by jerone and is likely to affect all GNOME installs on armel [12:32] * ogra hasnt seen it ever [12:32] I was talking with jerone on this [12:32] but jerone insists he sees it everywhere [12:32] It only happens with fresh installations it seems [12:32] because he removes it right after the issue comes up ? [12:33] when does it go away exactly ? and how ? [12:33] He says he kills the process [12:33] you said it only shows up with fresh installs ... so i assume it doesnt show up on older used ones ? [12:33] Ok, would one of you two please investigate? [12:34] NCommander needs to stay on the initramfs stuff, i'll take a look next week [12:34] Do a GNOME install on babbage and see whether you reproduce, if not ask jerone [12:34] [action] ogra to investigate 328167 [12:34] ACTION received: ogra to investigate 328167 [12:34] ogra: => assign [12:34] [topic] NSLU2 enablement [12:34] New Topic: NSLU2 enablement [12:35] well, as i said above, d-i works so far apart from a bug with locale generation cjwatson fixed [12:35] but that fix isnt included in the A5 image [12:35] which makes an NSLU2 install 30h long or so [12:35] an infelicity rather than a bug, really [12:35] (generating one locale takes ~90min) [12:36] the bug is that localedef takes so much memory; that I haven't fixed ... [12:36] well, our d-i process was never designed for 30M systems :) [12:36] i guess i'm the first one ever to try ubuntu d-i on 30M :) [12:36] nothing really to do with its design [12:37] 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] [topic] VFP optimisations [12:37] New Topic: VFP optimisations [12:37] lool, 30h arent acceptable [12:37] 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] otherwise i agree [12:38] I sent patches to Debian for these issues and worked around them; I isolated what was causing the hang -- actually extreme slowness [12:38] Just calling nextafterf() takes 4.5 minutes on the porter box [12:38] 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] erm, could it be that the perl issue is related ? [12:39] 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] Or if not related, similar in root cause [12:39] right [12:39] ogra: No; it's not fp related [12:39] I highly doubt it is [12:40] 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] [topic] ARM Benchmarking [12:41] New Topic: ARM Benchmarking [12:41] I'll check with infinity whether we can build a new kernel with the patch included [12:41] Err. Sorry! [12:41] It's ok; I'm done now [12:41] ARMv5, ARMv5+some libs, ARMv5+fulLVFP done. [12:42] I can't install mojo armv6 with the babbage via d-i, and QEMU doesn't have the necessary emulator support [12:42] So I'm stuck ATM [12:42] I have a candidate project to help us test Ubuntu binaries with random opt flags [12:42] But I'd like to discuss it here first [12:43] This might serve OEM or ourselves if we ever want to provide an optimized archive (still pretending to be armel) [12:43] Or for testing of various opts [12:43] I don't have anything else (unless we want to go indepth on my armv6 issues :-/) [12:43] The idea I had is quite simple: use EC2 to mass-rebuild the archive in qemu [12:43] lool, Won't that run into the cross-grade issues that mojo has? [12:43] That won't work lool [12:43] persia: cross-grade? [12:43] at least for ARMv6/ARMv7 [12:43] So we need of course a patched qemu with omap3 support [12:43] lool, e.g. mixing Debian and mojo breaks things. [12:43] NCommander, is there any way likely to work to get the installer to work for you? [12:44] there is the beagleboard qemu hack [12:44] persia: Well if we use the good soft-float ABI, it shouldn't; not sure whether mojo did that [12:44] but that lacks support for the disk controller yet [12:44] 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] I *think* the beagleboard could generate the image however. [12:44] ogra: The problem is instruction set support I think [12:44] NCommander, send me a list of what they support please [12:44] davidm, will do [12:44] it has the omap3 instruction set afaik [12:45] Why don't we just pool all our ARM hardware and do an archive rebuild that way? [12:45] ogra: Well then we're suggesting the same thing, add omap3 instruction set support to our qemu :-) [12:45] NCommander: Because we use it? [12:45] but misses support for the peripherial chipsets yet [12:45] ogra: We don't really care as long as it runs a virtual machine [12:45] lool, so the builds run in the background ... [12:45] lool, no disk controller... [12:45] 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] lool, you wont fit a whole archive in the flash [12:45] I think we're looking at three different things now: benchmarking, optimised builds, and emulation improvements. Shall we separate them? [12:45] lool, mojo compiles on real hardware. [12:46] no disk contoller meaning no USB either [12:46] * NCommander has done some experimenting in the realm of optimized rebuilds ... [12:46] 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] NCommander: No [12:46] NCommander: It used to and moved to qemu [12:46] I'd like to know how they did the armv6 builds then ... [12:46] They used to build on thecus and moved to dell x86 servers running qemu [12:46] right [12:47] Because if there is patches for QEMU for ARMv6, I can generate the last image I need to do my benchmarks. [12:47] NCommander, mojo is native-compiled inside QEMU, rather than cross-compiled, but it's still on x86. [12:47] NCommander: They aren't qemu mainline but patch support for the instruction set in? [12:47] +using [12:47] * NCommander looked and didn't see any [12:47] If you know where they are, please send me a link :-) [12:47] 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] - people needing to build armel packages -- no armel PPA, remember [12:48] - testing opt flags [12:48] - OEM [12:48] - QA mass rebuilds [12:48] lool, well, I have no objection to doing that (I even can help setup the infrastructure to do it) [12:48] ++ [12:48] - maemo folks wanting to build armel packages for maemo ;-) [12:48] I'm just not sure QEMU has the support [12:48] 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] persia: I wanted to see what people think of it, and whether we can devote time to it [12:49] NCommander, the beagle patch adds that support ... [12:49] * NCommander needs to find it [12:49] and there should be other patches that are less board specific and hackish [12:49] If I could get versalite with armv6/7, we'd be in business [12:49] http://beagleboard.org/project/qemu-omap3/ [12:49] LINK received: http://beagleboard.org/project/qemu-omap3/ [12:49] 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] StevenK, davidm: Comments? [12:50] ogra seems to like the idea, NCommander isn't sure it's possible but doesn't seem to mind [12:50] persia: Comments? [12:50] 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] lool, well, I know it will work for ARMv5 rebuilds [12:50] lool: Hm. Unsure. [12:50] Its just ARMv6 I'm unsure about. [12:51] 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] StevenK: I think it's the good time to raise your concerns [12:51] lool: I have concerns about supportability, but not building it [12:51] 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] persia, it won't be very difficult to setup to have it track the main archive. [12:52] StevenK: You mean supporting users which would like to build their packages? indeed, that's a good point [12:52] 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] 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] Supportability of an archive if we publish it [12:52] NCommander, keeping persistent tracking in EC2 gets expensive quickly. [12:53] persia, we could run wanna-build and the archive software outside of EC2 [12:53] Oh. I'd be against even hinting at support for any result packages, whether standalone or in an archive. [12:53] StevenK: Oh we can discuss what we do with the archives later on [12:53] Right it's no support, internal use only [12:53] Fair enough. No other concerns I can think of [12:53] * NCommander is +1 for the no support one [12:54] Ok; I guess it needs spec-ing then [12:54] I'll start a rough draft of my initial ideas and call for comments [12:54] persia: please [action] me on that [12:54] [action] lool to spec ec2-package-builder for jaunty+1 [12:54] ACTION received: lool to spec ec2-package-builder for jaunty+1 [12:54] davidm: You wanted to bring up a last topic [12:54] Wait! [12:54] That's roadmap. [12:55] Next is agenda items. [12:55] Nothing shown. [12:55] So... [12:55] [topic] any other business [12:55] New Topic: any other business [12:55] I was wondering if we have discussed the softbootloader with cjwatson recently? I know we somewhat stalled on this [12:55] persia: Exactly :-) [12:55] [topic] arm-softboot-loader [12:55] New Topic: arm-softboot-loader [12:56] It may be less critical but I hate to lose track and complete headway on it. [12:56] davidm, do we have a requirement for it in jaunty ? [12:56] lool, I just want the mootbot logs organised to make writing the minutes easier :) [12:56] i dont thnk we need it for anything yet [12:56] 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] We don't even have the necessary kernel support (kexec) we wanted for the designs we were thinking of. [12:56] 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] cjwatson: If you're around, do you think we could discuss the spec with you in the next week? [12:57] davidm, yes, so it deserves UDS discussion and pre-UDS research [12:57] NCommander: Do we have a bug for that? [12:57] lool, We have a spec for it. [12:57] which is why NCommander shold redo the spec with that in mind [12:57] * NCommander searches [12:57] *should [12:57] persia: I think kexec being broken warrants a bug [12:57] Oh, right. [12:57] I just don't want to lose what we have done to date and I don't want to miss something [12:58] I remember filing one [12:58] so we can have a UDS discussion based on the research data [12:58] But it may have just been upstream, and not in LP [12:58] NCommander: If you don't find it, please file one [12:58] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/319240 [12:58] Ubuntu bug 319240 in linux "kexec broken on ARM" [Undecided,Fix committed] [12:58] * NCommander resets that back to Triaged [12:58] That was my first stab at a patch, which only fixed it on QEMU due to emulator quarks. [12:58] NCommander: You confirm it's broken even in 2.6.28/jaunty/qemu? [12:59] yeah [12:59] * ogra would still like to know if it fails with the packages kexec [12:59] and in 2.6.29 [12:59] *packaged [12:59] ogra, I tried it with every version I can find [12:59] NCommander: And same test case passes on x86? [12:59] Its a kernel issue :-/, the kexec syscall busted [12:59] you built it yourself from upstream source, right ? [12:59] ogra, yes [13:00] so i'd like to see a test of the packaged version that has ubuntu patches and all [13:00] I'd like to know whether it works on x86 in qemu [13:00] note that kexec is used by the kernel team for debugging ourposes [13:00] lool, I remember testing it, but the Ubuntu kernel ships with kexec disabled on x86 by default [13:00] I can test it in QEMU [13:00] that cant be [13:00] ogra, we use the crash kernel support, but the reboot bit [13:00] We're up on time. can details continue in another channel for this (maybe #ubuntu-arm)? [13:00] persia: Mind actionning NCommander a coulple of times? [13:00] SUre, no problem [13:00] I think that's going to be good enough for today [13:01] [action] ncommander to test packages kexec [13:01] ACTION received: ncommander to test packages kexec [13:01] please talk to the kernel team about it, i know kexec is used a lot there [13:01] 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] [action] NCommander to test with x86 [13:01] ACTION received: NCommander to test with x86 [13:02] persia: thanks for chairing [13:02] yeah, thanks [13:02] [topic] any other business [13:02] New Topic: any other business [13:02] thanks persia [13:02] If you have some, please put it on the agenda for the next meeting, we're out of time. [13:02] #endmeeting [13:02] Meeting finished at 07:02. [13:02] and move to -arm or -mobile for further discussion :) [13:02] minutes should be up in ~20 minutes [13:02] * GrueMaster crawls back to his cave. [13:21] lool: I guess so [13:22] lool: it was really just a random idea from me though; I'm not convinced I'm an expert [13:23] 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] 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] cjwatson: Does that make sense? [13:28] b) doesnt need to be like that [13:29] it can be way smaller and less gui [13:36] lool: sounds fine to me modulo ogra's comments [14:01] Who's here for the Java Meeting? [14:01] o/ <- the hacker formerly known as Koon [14:02] Ah. Saving electrons, I see :) [14:03] compression is good. [14:05] Anyone else? [14:08] apparently not. [14:08]