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