**** BEGIN LOGGING AT Tue Feb 23 02:59:58 2010 Feb 23 04:26:55 My apologies, but is anyone familiar with zubuntu here? Feb 23 04:30:50 james_l: No apologies needed. Omegamoon was hanging out in here for a while some time back, but we never managed to get the Zubuntu kernel into Ubuntu. Feb 23 04:31:22 And only Ubuntu 9.04 can even run on that hardware: more recent versions require newer processors. Feb 23 04:31:53 (unless you're talking about https://launchpad.net/zubuntu , but I wouldn't expect this to be the right forum for that) Feb 23 04:31:58 That's a pity (I'm trying to get a working setup of either zubuntu or angstrom, and so far I've found little out about zubuntu, so I figured I'd ask) Feb 23 04:32:44 Well, you *shoud* be able to install Ubuntu on your Zaurus, as long as you restrict yourself to 9.04. Feb 23 04:33:05 Why is 9.04 the latest? Feb 23 04:33:12 Be warned that most of the default applications don't work very well at 640x480, so you may need to construct a special rootfs (the rootstock tool can help with this). Feb 23 04:33:42 Because the processor in those devices is old, and newer versions of Ubuntu require newer instruction sets that aren't supported. Feb 23 04:34:00 Same issue with the SheevaPlug, SmartQ series, etc. Feb 23 04:34:28 actually, I think the SmartQ series or Nokia n810 can run 9.10, but won't be able to run 10.04. Feb 23 04:34:33 * persia isn't quite sure Feb 23 04:34:44 Note that *all* of these devices need custom kernels. Feb 23 04:35:09 Yeah, I've played with that, unfortunately for every kernel I've tried, it's dying after Kernel Panic: aiiee attempted to kill init. Feb 23 04:35:35 Even ones that work (minus a few things) on angstrom, so I'm kind of at a loss on them. Feb 23 04:35:46 If you want something that supports the newer instruction sets, the Netwalker and Efika MX seem to be widely available. LOts of people use the BeagleBoard as well, but it's low on RAM Feb 23 04:35:57 (and these also all each require custom kernels). Feb 23 04:37:22 Hrm. I suspect there's something special in the kernel configs. Take a look at the kernel config for one of the Ubuntu-supplied kernels for 9.04 (-versatile might be a good candidate or the nslu2 kernel), and see if there are any obvious differences. Feb 23 04:37:29 Custom kernels aren't much of a problem, I just can't seem to find the kernel command line options that it wants, does ubuntu use the standard init, or something else? Feb 23 04:37:49 Ubuntu uses upstart Feb 23 04:38:20 Where is that stored? Feb 23 04:39:35 How do you mean? Where can you download it, or where is it stored in the image? Feb 23 04:39:46 Where it's stored in the image Feb 23 04:40:13 ie, is it started as /sbin/init Feb 23 04:40:30 If you have an initrd or initramfs, it's going to be in there. It provides /sbin/init, /sbin/initctl, /sbin/reboot, etc. Feb 23 04:40:58 Definitely /sbin/init Feb 23 04:41:21 So it's not actually stored on the rootfs image? Feb 23 04:42:21 No, it's in *both* places. If you're using initrd or initramfs, you need to have a copy there to deal with early boot, and you'll also have a copy in the rootfs to deal with keeping the system running. Feb 23 04:43:09 Ok, sorry the way you mentioned it made it sound as if it was only in the initial ramdisk. Feb 23 04:45:21 Sorry. Feb 23 04:46:19 Do you know if it requires a minimum kernel version? Feb 23 04:47:04 I don't offhand, but it's usually best to try to use the kernel that was released with a given release of Ubuntu. For 9.04 that was 2.6.28 Feb 23 04:48:01 Thanks, I'll keep messing with it. Feb 23 04:49:20 Good luck. If you get it working, please share: having a clean procedure to install Ubuntu on the Zauri would be appreciated by many. Feb 23 04:52:51 Do you know where Omegamoon went? I've tried to contact him about a few things, but alas have had no response. Feb 23 04:58:36 I don't. I haven't seen traffic from him in about a year in this channel. Feb 23 05:05:51 Anyone else work on zubuntu? Feb 23 05:37:07 persia: Any idea why when it boots, it would be killing init? Feb 23 06:54:20 Huzzah, got it to not kill init. Feb 23 06:55:22 On the other hand the touchscreen doesn't work Feb 23 06:55:28 Ooops Feb 23 06:57:28 That's just a driver thing :) Nice work. What was the magic change? Feb 23 07:05:46 Not much, I'm using the 1.0 from http://www.oesf.org/forum/index.php?showtopic=26510&st=0 on a tosa Feb 23 07:05:53 tosa = SL-6000 Feb 23 07:08:39 I know the kernel works for TS, and I think I should have fixed that. Feb 23 07:10:51 or not Feb 23 07:12:56 Oh, that should work. The 2.0 stuff seems suspicious to me because I *know* that large chunks of the archive were recompiled for an instruction set not available on those devices. Feb 23 07:16:35 Why was that, and does ubuntu have a build system capable of rebuilding them as armv5 (or even armv4) Feb 23 07:17:21 If you want ARMv4, I'll strongly recommend Debian armel. The team there has been maintaining support for this ISA, and does a great job. Feb 23 07:18:17 Its potentially possible to attempt to rebuild everything that has changed since 9.04 with a toolchain that supports ARMv5, but that's 1) going to take months, and 2) likely to require a significant number of build machines and a separate archive. Feb 23 07:18:53 I know it *can* be done, because some people recompiled 7.04, 7.10, and 8.04 for armel even before it was properly supported. Feb 23 07:19:05 I've got two SL-5500 which are strongarm (armv4 (l?)), and a SL-6000 which is armv5 (something or other) Feb 23 07:19:07 months? Feb 23 07:19:09 But I expect that such an effort would take 4-8 months. Feb 23 07:19:23 Yeah, there are thousands of packages involved. Feb 23 07:19:25 Why is ubuntu's build system so slow compared to others? Feb 23 07:19:52 I'm not sure to what you're comparing it, but I suspect the answer is that it's all native builds. Feb 23 07:20:00 I think our builds are faster than Debians. Feb 23 07:20:03 I'm not sure about other places. Feb 23 07:22:13 But to complete the answer to your question, ARMv7 was the initial target for Ubuntu armel, but it was impossible to get hardware at the time the project started. As hardware has become available, each release has gotten closer to the target. I'm hoping that we'll have enough hardware to be able to have a sane, stable, supported platform for buildds with our October release, but the path to get there has been confusing. Feb 23 07:22:28 Well, I've done cross compiling with a number of things, gentoo, angstrom, and even some debian and while each is probably far smaller than ALL the packages, it hasn't been that bad. Maybe a week for any of those. Feb 23 07:23:54 Yeah. Recompiling for a target rootfs is usually at most a tenth the size of recompiling the archive in terms of package count. Feb 23 07:24:10 But there's a couple other issues involved, as follows: Feb 23 07:24:20 1) Not all packages in Ubuntu are set up for correct cross-compilation Feb 23 07:24:55 2) Build-time test-suites run under cross-compilation don't tend to generate the expected results Feb 23 07:25:25 3) The combination of native-built and cross-compiled binaries is poorly tested, and it's unknown whether there may be ABI changes. Feb 23 07:25:59 Since working around 1) involves 20,000 patches, we chose native compilation. Feb 23 07:26:20 And because of 3) we discourage cross-compilation because we don't know how it would affect things. Feb 23 07:26:45 2) is a bit more of a happy accident, but would have likely been dealt with if we had to patch for 1) Feb 23 07:41:32 d'oh http://pastebin.ca/1806500 Feb 23 07:42:58 To be honest, that's a bit disappointing, considering that debian had the best CC years ago Feb 23 07:44:01 Well, it depends on the package. Anything that cross-compiles well in Debian likely cross-compiles well in Ubuntu. Feb 23 07:44:13 But the vast majority of packages have never been tested. Feb 23 07:44:32 *so*, if you're just looking to do something small, you could rebootstrap with cross-compilation. Feb 23 07:44:48 But if you want the entirety of the archive, it's not necessarily safe. Feb 23 08:27:14 ynezz: I saw that double free once, but it's usually not fatal Feb 23 08:27:28 ynezz: Try with MALLOC_CHECK_=0 Feb 23 08:34:21 ok, building again Feb 23 08:51:41 lool, usually not fatal ? it usually kills apt during package install :) Feb 23 08:52:28 lool, i think we should target that one for release and get doko on the case if possible Feb 23 08:57:33 ynezz, hey, the screenshow in your new bug looks different from the old one :) Feb 23 08:58:17 it's same URL, isn't it? :) Feb 23 08:58:19 ynezz, --serial ttyS2 .... vs console=ttyAMA0,115200 ;) you didnt build your image with the right serial device Feb 23 08:59:06 rootstock needs to use --serial ttyAMA0 in this case Feb 23 08:59:45 ogra, what did imx51 do to enable the serial console at boot by the way? Feb 23 09:00:02 ogra, by modifying flash-kernel? Feb 23 09:00:10 ericm, adding console=ttymxc0,115200 to the cmdline Feb 23 09:00:28 ogra, I mean not in boot loader Feb 23 09:00:29 no, we dont touch flash-kernel, the default cmdline is set durign image build Feb 23 09:00:47 ogra, but the default will only be used when no cmdline is passed Feb 23 09:00:52 right Feb 23 09:00:55 as always Feb 23 09:01:13 and u-boot will read the boot.scr scripts on disk to setup the command line, which is configured by flash-kernel Feb 23 09:01:14 ogra: ok, rebuilding with correct --serial Feb 23 09:01:28 so for dove - I guess to modify flash-kernel will be a better approach Feb 23 09:01:49 ericm, no, we dont want to have a console option by default in any of the images Feb 23 09:02:13 we only added that for the dev release and will drop it in one of the betas Feb 23 09:02:35 the cmdline on arm should not differ from the default in any other images Feb 23 09:02:51 ogra, I'm going to close bug 452737 Feb 23 09:02:52 the boot.scr for dove is created by the image build scripts on the cdimage server Feb 23 09:02:54 ericm: Bug 452737 on http://launchpad.net/bugs/452737 is private Feb 23 09:04:23 ericm, hmm, while its a bit late to enable that for lucid it might be helpful for L+1 until beta Feb 23 09:04:51 ogra, ok - got you Feb 23 09:04:58 ericm, but essentially it is fixed btw Feb 23 09:05:02 ynezz: note that you need to set MALLOC_CHECK_ in the installer script which gets copied by rootstock into the VM Feb 23 09:05:04 see my last comment Feb 23 09:05:32 ogra, right - if it is only wanted a way to enable that instead of every time Feb 23 09:05:35 lool, i'll set that by default in my next upload(risking that we lose duplicate copunt for the bug) Feb 23 09:06:13 ericm, yes, the liveimage specifically got that serialtty= option in casper to create the console Feb 23 09:06:47 ericm, but it will only come up after boot for the login prompt, what i suspect Li wants on that bug is kernel bootmessages :) Feb 23 09:07:10 ogra, exactly what he was talking about Feb 23 09:07:56 right, so he needs to set console= on the images boot.scr ... its not that hard to do from an x86 system on the mounted USB key/SD card Feb 23 09:08:12 (manually before booting) Feb 23 09:11:06 ogra, see - so I'll close that one Feb 23 09:11:20 yeah, but add proper comments :) Feb 23 09:13:59 morning Feb 23 09:15:40 lool: something like that? http://paste.ubuntu.com/382126/ Feb 23 09:16:57 ynezz, yes Feb 23 09:17:14 i'll add the same to rootstock as well Feb 23 09:20:01 ogra: I've rebuild that karmic image with this http://paste.ubuntu.com/382129/ Feb 23 09:20:17 ogra: and it's same, that serial device had no effect on it Feb 23 09:22:20 try without the --kernel-image parameter Feb 23 09:22:29 thats actually only for the beagel board Feb 23 09:22:53 better apt-get install linux-versatile after first boot manually :) Feb 23 09:23:18 btw - rootstack under Debian/sid + DIST=lucid hangs after extracting last package Feb 23 09:23:26 though you should get a login prompt Feb 23 09:23:45 hrw on first stage ? Feb 23 09:24:13 Kernel image must be specified Feb 23 09:24:13 note that rootstock isnt really written for debian and i dont even test it in that context Feb 23 09:24:20 ynezz, no Feb 23 09:24:24 not in rootstock Feb 23 09:25:04 --kernel-image is an addition for the beagleboard and it extracts a kernel directly, circumventing the package system Feb 23 09:25:19 ah Feb 23 09:25:20 (because beagle has no kernel in the archive yet) Feb 23 09:26:00 ogra: http://hrw.pastebin.ca/1806559 Feb 23 09:27:01 hm, had the same issue Feb 23 09:27:08 it's missing qemu-arm-static Feb 23 09:27:09 hrw, yeah, problem with the difference of our qemu packages i think Feb 23 09:27:40 debian doesnt have qemu-arm-static in any stable release ... and in testing its named differently Feb 23 09:27:45 ok Feb 23 09:28:03 (if it even entered testing already, not sure, might still be unstable) Feb 23 09:29:15 ynezz, thats why we have packages for rootstock ;) they install the needed deps Feb 23 09:30:02 there was no qemu-arm-static in 9.04 Feb 23 09:30:08 right Feb 23 09:30:25 thats why the 9.04 package uses a VM for that stage Feb 23 09:31:28 ah, ok Feb 23 09:33:32 * ogra thinks it became a FAQ so makes sense to have it in the topic :) Feb 23 09:34:26 ogra: which HW is used for native builds? Feb 23 09:34:38 imx51 Feb 23 09:34:50 cpu speed? memsize? Feb 23 09:35:26 800MHz, 512MB Feb 23 09:36:17 where are times when 64MB 400MHz was good machine ;D Feb 23 09:37:14 heh that was when we were young :) ... back then Feb 23 09:37:44 I still have slower devices on desk Feb 23 09:38:51 ogra: rootstock should have option to just generate images. as all is done in temporary dir it is harder to find where is image which was generated/used/failing Feb 23 09:38:52 * ogra too Feb 23 09:39:22 hrw, thats done with the --keepimage or --notarball options Feb 23 09:40:23 apart from that both, the gtk GUI and the script tell you wheer the image was stored at the end of the build (the GUI also has an option to select the target dir) Feb 23 09:41:08 dpkg-divert: cannot open diversions: No such file or directory Feb 23 09:41:08 eggonlea: Second stage build in Virtual Machine failed ! Feb 23 09:41:08 eggonlea: Please see the log to see what went wrong. Feb 23 09:41:08 ian_brasil: Cleaning up... Feb 23 09:41:21 ~curse irssi tabcompletion Feb 23 09:41:26 ian_brasil, eggonlea: sorry Feb 23 09:41:29 lool, so i'm considering to change the image fs from ext2, what would you prefer, ext3 or 4 ? Feb 23 09:41:35 hrw, heh Feb 23 09:41:39 ext2 is fine for images Feb 23 09:41:56 hrw, no, it causes fsck to kick in if the clock is off Feb 23 09:42:26 ext3 should be common on all kernels nowadays Feb 23 09:42:31 so go for ext3 and disable fsck by tune2fs Feb 23 09:42:58 i wont screw around ion the rootfs :) Feb 23 09:43:05 so no tune2fs Feb 23 09:43:15 ogra, lool: little change in error message :) http://paste.ubuntu.com/382146/ Feb 23 09:43:39 rootstock is supposed to build as identical installs as possible to a normal ubuntu Feb 23 09:44:52 which is why the --user and --passwd options are not used by default anymore in the latest commits for example Feb 23 09:46:14 ogra: I've rebuilt that karmic image with http://paste.ubuntu.com/382148/ Feb 23 09:46:18 ogra: but it's same Feb 23 09:47:36 thats weird, it should work Feb 23 09:48:09 do you see dmesg output on boot ? and do you see ttyAMA0 in there ? Feb 23 09:48:45 yes I see dmesg Feb 23 09:48:53 that screenshot was just the last part Feb 23 09:49:19 you should be able to scroll back and there should be some message about ttyAMA0 Feb 23 09:49:22 and I see ttyAMA0 there Feb 23 09:49:29 very weird Feb 23 09:49:30 1,2,3 too Feb 23 09:49:32 then it should work Feb 23 09:49:51 the problem is with devtmpfs I think Feb 23 09:49:57 no Feb 23 09:50:08 it get's mounted and is missing /dev/pts /dev/shm etc. Feb 23 09:50:09 devtmpfs is in all ubuntu kernels for lucid Feb 23 09:50:38 that should be handled by udev Feb 23 09:52:42 * ogra goes for some breakfast Feb 23 09:53:11 * hrw goes though rootstock and removes all removals Feb 23 09:53:41 ~hail 25Mbps download Feb 23 10:11:28 hmm. rootstack generated rootfs thinks that only dpkg is installed ;( Feb 23 10:25:27 ogra_cmpc: Please use ext4 for images of karmic+ Feb 23 10:25:49 and if you care, ext3 for << karmic Feb 23 10:26:16 Why, particularly? Feb 23 10:27:11 ynezz: that's "interesting" Feb 23 10:27:17 ynezz: Do you reproduce with "ldconfig"? Feb 23 10:27:50 persia: are you asking me? Feb 23 10:28:25 lool: Yes, and specifically about your filesystem selection suggestions. Feb 23 10:28:28 ynezz: Yes, that might be the issue, but mountall should cope with that I think Feb 23 10:28:38 I don't disagree: rather I'm curious why one ought select those. Feb 23 10:28:45 persia: because ext4 was the default fs starting with karmic installs Feb 23 10:29:00 And I think all Ubuntu subprojects should be consistent here Feb 23 10:29:08 Just like we patched vmbuilder to do this as well for instance Feb 23 10:30:03 This makes lots of sense. Thanks for the explanation. Feb 23 10:30:19 lool: how do you mean that 'ldconfig' ? mount that image and run it manualy using qemu-arm-static? Feb 23 10:30:55 ynezz: boot with init=/bin/sh Feb 23 10:31:59 lool: sorry, you're talking about that apt-get segfault? Feb 23 10:35:09 ynezz: Yes Feb 23 10:35:14 ynezz: I htink it's ldconfig Feb 23 10:39:19 lool: since it crashed I need to create qemu image manualy and copy the unfinished fs from /tmp/ right? Feb 23 10:39:32 ynezz: Sorry, I'm not sure about that part Feb 23 10:39:50 Probably there's a leftowver .img somewhere, unless it cleans it up on crash Feb 23 10:40:50 it cleans it Feb 23 10:41:15 ok I'll rebuild without that cleanup task and try it Feb 23 10:41:58 * lool & Feb 23 10:42:56 ah it's in /tmp also, good Feb 23 10:51:29 lool: if I run /sbin/ldconfig nothing happens Feb 23 10:53:16 lool: running it with --verbose it do something Feb 23 11:08:47 ynezz: try apt-get install vim ... as in the log instead? Feb 23 11:08:58 ynezz: It would be great to have a smaller testcase than running rootstock Feb 23 11:09:16 I saw that once myself, but couldn't trigger it again afterwards Feb 23 11:09:38 * ogra doesnt see it at all under lucid Feb 23 11:09:56 and i'm doing about ten testbuilds with rootstock per day currently Feb 23 11:10:31 though most of the time only minimal with no seeds Feb 23 11:11:35 ogra: would you mind trying this 'sudo project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 2G --seed wget,vim,network-manager --dist lucid --serial ttyAMA0' Feb 23 11:11:40 ? Feb 23 11:11:58 it does happen to me when there's network-manager in the seed... Feb 23 11:12:00 i'll try it in the next gui test later today Feb 23 11:12:05 ok, thanks Feb 23 11:12:20 without seed it's ok Feb 23 12:56:10 ##################### REMINDER: mobile team meeting in #ubuntu-meeting in 5 min ###################### Feb 23 15:20:35 ogra: Did you look at where rootstock would pull lucid kernels from? Feb 23 15:20:56 i didnt change the code you know Feb 23 15:21:07 ogra: You might want to check 431790 Feb 23 15:21:10 lp #431790 Feb 23 15:21:11 Launchpad bug 431790 in debian-installer (Ubuntu) (and 1 other project) "debian-installer images aren't signed in the archive (affects: 1)" [Undecided,New] https://launchpad.net/bugs/431790 Feb 23 15:21:12 but its not active yet either Feb 23 15:22:31 oh, thanks Feb 23 15:23:39 looks good, what key would be used, the normal archive key ? Feb 23 15:25:22 I guess Feb 23 16:48:44 lool, so it seems i can reproduce the issue with --seed wget,vim,network-manager here Feb 23 16:48:54 i get the same segfault Feb 23 16:53:32 ogra: Ok great, can you investigate? Feb 23 16:53:41 Starting by a bug report etc. Feb 23 16:53:49 * lool is about to leave for the day in 20 minutes or so Feb 23 16:55:16 * ogra too Feb 23 16:55:22 but i'll put it on my list Feb 23 18:43:05 lrg, ping when you're around! Feb 23 19:34:12 lool, the segfault does only happen with the non archive kernel ... i cant reproduce it with the archive kernel here, i guess i'll switch on the rootstock code to pull the deb with the next commit :) Feb 23 19:50:07 ok uploaded libv4l with workaround for arm gcc issue Feb 23 19:50:08 off Feb 23 19:50:23 yay Feb 23 19:50:46 * ogra is off too Feb 23 21:14:55 ogra: Could you comment on whether you intend to use d-i kernel in https://bugs.launchpad.net/bugs/431790 ? Feb 23 21:15:02 Launchpad bug 431790 in debian-installer (Ubuntu) (and 1 other project) "debian-installer images aren't signed in the archive (affects: 1)" [Undecided,New] Feb 23 21:18:10 ~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~/c Feb 24 00:40:47 GrueMaster: are you testing on imx or dove currently? Feb 24 00:41:15 * persia wonders why this is -arm and not -testing material. Feb 24 00:41:30 Finished testing imx live (well, may test more deeply). Installer is still broken and fix is released but not built yet. Feb 24 00:41:54 GrueMaster: same installer bug you mentioned in the meeting earlier today? Feb 24 00:42:19 yes. Feb 24 00:42:23 ouch Feb 24 00:43:39 GrueMaster: you are going to have the same problem on dove Feb 24 00:43:51 GrueMaster: we have ubiquity 2.1.24 on dove, assuming the same on imx Feb 24 00:43:58 snap Feb 24 00:44:02 That's what I thought. yes. Feb 24 00:44:07 So, respin it is. Feb 24 00:44:12 wheee. Feb 24 00:44:33 GrueMaster: is there any workaround for it? Feb 24 00:45:16 Yes. Install 2.1.25 as soon as it gets built. Feb 24 00:45:43 (I know, not a good answer) Feb 24 00:46:21 GrueMaster: well, if you want to get unblocked... Feb 24 00:46:25 it's a 1-line change Feb 24 00:46:27 Correct me if I'm wrong, but it seems to me we hit this bug at least once per release. Feb 24 00:46:45 http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/3830#ubiquity/components/ubi-partman.py Feb 24 00:49:13 Does python rebuild the pyc file automatically? Feb 24 00:49:17 GrueMaster: hopefully that's true, and our one time is over :) Feb 24 00:49:37 GrueMaster: you can force it if needed by deleting the .pyc file Feb 24 00:50:17 it's going to be 1-2 hours before I can get much more testing done, but may be moot since it looks like we'll need a respin Feb 24 00:50:37 I've made the change and will test it quickly. Feb 24 00:50:46 hmm, marvell dove... what actual board uses that? Feb 24 00:50:56 I can find Kirkwood just fine (that Sheeva thingy), but what's Dove? Feb 24 00:51:04 What I have is BeagleBoard (OMAP3). Feb 24 00:51:07 GrueMaster: thanks, let me know, gotta go afk for a bit Feb 24 00:51:16 see you. Feb 24 00:51:41 DanaG: The sheeva plug is an older generation. Feb 24 00:52:39 I thought it was the other way around... kirkwood newer than dove. Feb 24 00:52:56 oh, I see. Feb 24 00:53:03 Age of processor != Age of instruction set revision :) Feb 24 00:53:20 http://armin762.wordpress.com/2010/02/14/armv7-socs-freescale-i-mx51-babbage-ti-omap3-marvell-dovearmada-qualcomm-snapdragon/ Feb 24 00:53:20 ah Feb 24 00:53:32 http://www.slashgear.com/marvell-plug-computer-3-0-updates-sheevaplug-with-wifi-bluetooth-hdd-0567674/ Feb 24 00:54:04 Do any of you talk directly to Marvell? Feb 24 00:54:07 http://www.flickr.com/photos/22046787@N03/sets/72157623160058996/ Feb 24 00:54:23 I saw comments on Engadget, asking essentially: why cripple battery life by using a tiny battery? Feb 24 00:54:42 Product suggestion: take that same thing, and give it a normal-size battery (for insane-o battery life). Feb 24 00:57:32 DanaG: I've had the "why cripple" discussion with a hardware vendor before. Apparently the goals are low cost and low weight with market-acceptable battery life. Feb 24 00:57:55 DanaG: The impression I get is that marketing teams don't believe people will pay more for heavier devices just for extended runtimes Feb 24 00:57:57 Ah, it'd be nice if they could make interchangeable different-size batteries. Feb 24 00:58:09 http://www.engadget.com/2010/01/05/marvell-shows-off-an-odm-smartbook-thinner-than-strict-decency-p/ Feb 24 00:58:10 Some do, but not enough :) Feb 24 00:59:26 armin76: Do you have a link for the "Prototype" identified as an i.MX51 product, or did you just mean "Various prototype devices"? Feb 24 01:00:00 As it is, 4 hours is no better than I get with my full-size laptop -- and lower than many Atom netbooks. Feb 24 01:00:25 Well, yeah, but it's "The thinnest thing around", which is the highlight point. Feb 24 01:00:52 There was talk about the "20-hour laptop", which is perfectly doable at about 1.5Kg, and we can hope someone releases one. Feb 24 01:04:17 If they put the battery at the back, then they could do one design to satisfy both. Feb 24 01:05:21 http://gigapple.files.wordpress.com/2009/04/hp_battery.png?w=161&h=149 Feb 24 01:05:37 old pic, but that's the idea. Feb 24 01:06:07 Either that, or something like the 3/6/9/12 cell modular batteries available for some laptops. Feb 24 01:06:07 oh, and are there plans for an official in-repo beagleboard config (or at least kernel)? Feb 24 01:07:22 I think not for the current generation. There is an expetation of 192MB RAM in Ubuntu (or maybe that got bumped to 256MB or even 384MB), and I thought the BeagleBoards only had 128MB. Feb 24 01:07:36 I believe it has 256, actually. Feb 24 01:07:50 Oh, then I've been misinformed :) Feb 24 01:07:52 I'm running Lucid on it just fine right now -- http://elinux.org/BeagleBoardUbuntu Feb 24 01:08:01 I think Rev.A had 128; it changed to 256 later. Feb 24 01:08:05 Oh, I know it works. We have lots of Beagle users. Feb 24 01:08:17 Ah. That explains the confusion. Feb 24 01:08:49 I think it's too late for this development cycle (although I might be wrong), but it would perhaps be something to raise with the kernel team during planning for the next cycle. Feb 24 01:09:11 It depends on the level of effort that is expected from them, and the number of people willing to volunteer to support it, etc. Feb 24 01:09:36 If we just ask the existing team "Please also do this" the answer is almost certain to be "No" unless it's trivial to do. Feb 24 01:10:10 If we can get more volunteers to help join the team, and the question becomes "Please accept these patches that we'll help maintain", it'S easier. Feb 24 01:23:47 Even something like the kernel-ppa (that is, not even a 'real ppa' that you can add to sources.list) would be good. Feb 24 01:23:57 Just, something like a "sanctioned list of kernels you should try". Feb 24 01:24:15 Or something like that. Feb 24 01:24:31 Well, PPAs don't handle armel very well. Feb 24 01:24:49 Best current recommendation for Beagle users is to use rcn-ee's kernel, which tends to be in good shape. Feb 24 01:24:56 oh yeah, and speaking of batteries... the way HP business notebooks work: 8-cell primary, PLUS either 8 or 12-cell secondary. Feb 24 01:25:09 oh yeah, though none of the .33-rc kernels are there for Lucid. Feb 24 01:25:11 That's also a reasonable model. Feb 24 01:25:24 And 8 is bigger than necessary for ARM stock battery. Feb 24 01:25:27 =þ Feb 24 01:25:33 You could go all day on 8. Feb 24 01:25:47 Lucid isn't using .33-rc right now for anything. It's 2.6.32 still. Feb 24 01:26:08 "All day" isn't necessarily enough :) Feb 24 01:26:33 taken absurdly literally, "all day" is 24 hours. Feb 24 01:26:36 =þ Feb 24 01:26:42 er, at least 18. Feb 24 01:27:03 * persia has a laptop that (when the batteries were new) got 12 hours on two batteries. With travel, sleep, etc., this should have been enough (especially because the batteries recharge in 3.5 hours), but I've still run completely out of power. Feb 24 01:28:02 My laptop got 4 hours when new, on the 8-cell standard battery. Now I have like 17% wear, one year later. Feb 24 01:33:30 Oh, and what's Marvell's GPU, anyway? Feb 24 01:33:54 (two questions: open source? capable of compiz?) **** ENDING LOGGING AT Wed Feb 24 03:00:02 2010