[02:17] <therussianjig> is the OMAP4 build optimimized for an ARMv7 arch?
[02:19] <lilstevie> therussianjig: ubuntu-arm is only built for the v7 arch
[02:19] <twb> ubuntu only provides armv7 binaries AFAIK
[02:19] <therussianjig> kk ty
[02:31] <twb> lilstevie: btw you still ship ext[234] rootfs images, right?
[02:31] <twb> lilstevie: if you run zerofree(8) on them they will compress better
[02:31] <twb> http://paste.debian.net/147769/ -- dunno what the numbers mean, but I think it's saying that it *did* make your image more compressible :-)
[02:32] <lilstevie> yes, ext4 images
[02:32] <lilstevie> I will keep that in mind
[02:33] <lilstevie> anything that brings the size down further makes my life easier
[02:33] <twb> If you have just created a fresh image with e.g. genextimage it won't help much, but if you've an ext that has been lying around and have >>0 edits to it, then it should help
[02:33] <twb> (I'm doing it now because I'm out of disk on my netbook so zerofree + xz -9e on the rootfs.ext's to save some space :-)
[02:33] <lilstevie> well it is the omap image from ubuntus servers
[02:34] <lilstevie> with some edits
[02:34] <twb> Ah, I didn't know that, interesting
[02:34] <twb> It'd be cool if you could just ship it as a .mod for a union filesystem, like morphos used to do :-)
[02:35] <twb> i.e. you say "go download ubuntu's image, then apply my copy-on-write union"
[02:37] <twb> Or even sexier, a bootloader than can access a /boot on .sq, because then you can just ship an xz-compressed .squashfs and DD it directly onto the disk.
[02:37] <lilstevie> heh union is a pain
[02:38] <lilstevie> and it isn't the bootloader that prevents access to boot
[02:38] <lilstevie> it is the partition layout
[02:38] <twb> Yes that too
[02:39] <lilstevie> also
[02:39] <lilstevie> the other day you said about the 360 s being loud?
[02:39] <twb> The new ones, yes
[02:39] <lilstevie> I got one yesterday
[02:39] <lilstevie> whisper quiet
[02:40] <twb> lilstevie: the PSU fan?
[02:40] <twb> That is, the power brick
[02:40] <lilstevie> yeah, whole thing
[02:40] <twb> Huh.
[02:40] <lilstevie> barely makes a sound
[02:40] <lilstevie> it is a corona board though
[02:40] <lilstevie> not trinity
[02:40] <twb> It probably doesn't help that I play games with the sound off/down, and my desk is basically designed to act as a sounding box for any speakers on it
[02:41] <twb> lilstevie: dunno about corona/trinity business
[02:41] <lilstevie> trinity is the 360 S initial revision
[02:41] <twb> I use a 360 because its turnkey, i.e. I don't have to care about that
[02:41] <lilstevie> corona is the newer lower power one
[02:41] <lilstevie> heh
[02:42] <twb> Is there a 1:1 correspondence between corona and having the newer kinect power doodad?
[02:42] <lilstevie> no idea
[02:42] <twb> Ah, no I think 360 S is that line, and within that is your two mobo models
[02:42] <lilstevie> the corona has only been in production for the last 2 or 3 months
[02:43] <lilstevie> it is going to be my only unhacked console :p
[02:44] <twb>   7.5 %        93.8 MiB / 158.7 MiB = 0.591   224 KiB/s      12:04   2 h 30 min
[02:45] <twb> ^^ xz -9e is chugging away on my image still :-)
[02:45] <lilstevie> heh
[02:46] <twb> Well, the actual command was "nice ionice -c3 xz -v9eM75%"
[02:46] <twb> Which translates to be as slow and compressy as possible
[02:46] <lilstevie> heh
[02:47] <twb> Probably be faster to scp it to the buildd, compress it, scp it back :P
[02:47] <lilstevie> lol
[02:48] <twb> Incidentally you can also make a disk image sparse again using zum(1) from the perforate package
[02:57] <lilstevie> and you can make it deceptively attractive with rum(1)?
[02:57] <twb> NFI
[02:58] <lilstevie> lol
[04:43] <twb> lilstevie.geek.nz/ports/ubuntu.img (1/2)
[04:43] <twb>   100 %     334.5 MiB / 2,048.0 MiB = 0.163   503 KiB/s    1:09:30
[04:43] <twb> That's using plain xz, i.e. -6 or so not -9e
[04:45] <twb> The other thing you could do, of course, is simply resize2fs -M it (reducing its actual size to its used size), and instruct users to do "resize2fs foo.img 2G" or whatever to grow it back out prior to use
[06:51] <lilstevie> twb: seriously there is like <60MB extra in that image
[06:51] <lilstevie> and I grow it on first boot
[06:52] <twb> k
[06:52] <twb> I'm just brainstorming here, you don't have to do what I say obviously
[12:34] <fisuk> umm.. anyone else have this kind of behaviour when playing HD video https://groups.google.com/d/msg/pandaboard/HxKHj_n0d0g/b78ZmXhI6cMJ ?
[12:35] <fisuk> (i'm not the same guy as the poster, but I too have that problem)
[16:02] <suihkulokki> who was the one here asking about chromium and arm?
[16:06] <ogra_> suihkulokki, micahg maintains it in ubuntu if you mean that
[16:06] <ogra_> (and is still urgently looking for help to build it on arm)
[16:14] <suihkulokki> micahg: if you want to try cross-compiling chromium, see: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/ChromiumCrossCompile
[16:14] <ogra_> i think he rather wants it to not FTBS in natvie builds first :)
[16:15] <suihkulokki> yes, and with native builds it will take him 27h per build ;)
[16:19] <ogra_> which is fine gievn that the binary didnt build since two releases now
[16:20] <ogra_> would be good to have something more recent than 13.0.xx
[16:34] <micahg> ogra_: I was hoping to cross compile in an attempt to fix the native builds faster than a +20hr iteration as suihkulokki pointed out :), my goal is that native builds should work though
[16:34] <ogra_> yeah
[16:35] <ogra_> i guess both is good
[16:35] <micahg> yeah, if there's an arm person interested in keeping it building, I'll take patches that look sane
[16:35] <ogra_> given that firefox still takes munites to start from SD ...
[16:35] <micahg> otherwise, it's best effort on my part for ARM
[16:35] <ogra_> vs seconds for chromium ...
[16:35] <ogra_> *minutes
[16:36] <micahg> ogra_: hmm...I would've thought omnijar fixed that, I guess we would need PGO to really make that happen
[16:36] <ogra_> well, to be honest i havent touched FF since mid oneiric cycle anymore
[16:36] <micahg> does the imx51 smartbook support armhf and would that make it perform faster?
[16:36] <ogra_> at least for my day to day work on my ac100
[16:37] <micahg> ogra_: ah, well, speedup is a focus of theirs now
[16:37] <ogra_> all cortex-a8 and upwards should support armhf
[16:37] <micahg> cool, will that speed build times though and performance?
[16:37] <ogra_> the speedup you gain with hf is purely floating point stuff ... it wont improve i.e. disk IO
[16:37] <micahg> ah
[16:38] <ogra_> but things like pango and cairo should render lots faster
[16:38] <ogra_> i heard something about 30% in best case scenarios
[16:38] <dmart> JavaScript numeric data is mostly floating-point
[16:38] <ogra_> yeah, that will speed up as well
[16:38] <ogra_> its like 486DX vs 486SX :)
[16:39] <ogra_> in case you still remember the difference
[16:39] <dmart> I *had* an SX (and felt suitably cheated) ;)
[16:41] <ogra_> heh
[16:41] <taruti> any idea what could cause black areas form around letters in firefox and after a while X becoming unresponsive?
[16:42] <taruti> on pandaboard that is
[16:42] <dmart> accelerated graphics drivers would be the most likely cause
[16:43] <taruti> so uninstalling those could help, will try
[16:43] <dmart> You could try the most recent linaro LEB and see whether it makes a difference -- http://releases.linaro.org/11.11/ubuntu/leb-panda/panda-ubuntu-desktop.img.gz
[16:43] <dmart> Maybe there are some issues which have been fixed in the meantime (depending on what you're using)
[16:44] <ogra_> there surely are issues with 4460 boards and oneiric ... but i dont think many of these have been distributed yet
[16:44] <ogra_> thermal issues ... not sure they would influence the graphics
[16:45] <dmart> I'm not familiar with all the different OMAP4 variants -- is this a newer rev Panda, or a different board entirely?
[16:45] <ogra_> newer panda ... next gen SoC
[16:46] <ogra_> up to 1.2GHz (or was it 1.4 ...) etc
[16:46] <dmart> ah, right
[16:47] <ogra_> i know for the temp issues there are fixes in linaro ubuntu doesnt have yet
[16:47] <ogra_> we'll get them with the next drop into precise
[16:47] <taruti> ok
[16:48] <ogra_> if you dont have a 4460 (which is likely) then that doesnt affect you though
[16:50] <taruti> the older revision
[16:51] <suihkulokki> micahg: the chromium 15 linked from the instrutions compiles both natively and cross (cross needs some libraries from the linaro staging).
[16:52] <ogra_> awesome !
[16:52] <ogra_> micahg, upload upload upload !!!!
[16:52] <suihkulokki> micahg: so only thing needing fixing is reverting from system libvpx to the bundled one
[16:52]  * ogra_ jumps up and down
[16:53] <taruti> any idea whether two displays work simultaneously at the moment (dualhead)?
[16:53] <ogra_> i dont think so
[16:54] <ogra_> iirc the kernel only drives one of HDMI or DVI at once
[16:54] <ogra_> though my info might be outdated
[16:54] <taruti> googling reveals only people having problems
[16:55] <ogra_> yep
[16:57] <micahg> suihkulokki: great, thanks, unfortunately, I had a new build failure with .121 on amd64 that I have to fix first, but it's awesome that you got it working
[17:04] <suihkulokki> micahg: I'll head asleep in few hours, email me if you bump into problems
[17:05] <micahg> suihkulokki: thanks, I probably won't get to it until next week (cross compiling that is), but will let you know if I run into any issues
[18:46] <ogra_> infinity, monday ... :)
[18:46]  * ogra_ grins
[18:47] <infinity> ogra_: Hrm?
[18:47] <ogra_> -core
[18:47] <infinity> ogra_: Oh, it would have been last night, but lamont kinda screwed up the setup on the buildd. ;)
[18:47] <ogra_> ah, k *g*
[19:03] <MrCurious> anyone know of a way to get pandaboard to run ubuntu11.10 at 1ghz instead of 800mhz?
[19:04] <prpplague> MrCurious: should be able to force it to 920MHz as part of the frequency scaling
[19:05] <MrCurious> i thought i read that it was disabled and locked at 800mhz in ubuntu11.10
[19:05] <MrCurious> and the auto scaling was not yet working in 3.0 linux
[19:07] <MrCurious> i am trying to catch up after a hiatus
[19:15] <infinity> MrCurious: Where are you seeing it set to 800?
[19:16] <MrCurious> read on a blog post
[19:16] <MrCurious> bogomips on 11.10 is ~ 1500
[19:16] <MrCurious> on 10.10 ~2000
[19:17] <MrCurious> the blog post reasoned it to be 800mhz
[19:17] <MrCurious> getting the url
[19:17] <infinity> Oh, we seem to be lacking scaling in 3.0, so it gets stuck low.  Or some such unpleasantness.
[19:18] <MrCurious> bit.ly/unRZt3 of fb.me/1bAMqhwYc
[19:20] <infinity> That blog has the answer.
[19:20] <infinity> Basically, wait for smartflex support.
[19:22] <MrCurious> yeah
[19:22] <MrCurious> i have active cooling for my board though, so was checking if it was a easy config to kick it up to 1ghz
[19:37] <infinity> Not at runtime, since runtime support for changing the frequency is, well, not there.
[19:37] <infinity> I suspect it wouldn't be much trouble to change it at the source level.