=== yofel_ is now known as yofel [02:46] hello hello, anyone around to help me here? === Darkwing is now known as DWonderly [03:04] i need help cross compiling, since i am new to this im sure im missing something stupid [05:07] Hi, did Ubuntu 8.04 support ARMv6? [05:08] cdnjay: armel support was added in 9.04 [05:08] OK, so was 9.04 the only version to support ARMv6 then? [05:09] cdnjay: and 9.10, both EOL, Debian stable is the best bet for armv6 for an Ubuntu like setup [05:09] I don't recall exactly when each option was changed. [05:09] But yes, what micahg said. [05:09] Installed an unsupported release for ARMv6 isn't a sane option. [05:09] s/installed/installing/ [05:10] IIRC, Debian stable base arm support is armv4t [05:11] Aye. [05:11] cdnjay: http://www.debian.org/ports/arm/ and http://wiki.debian.org/ArmEabiPort for more information [05:12] micahg: OK, thanks. I was hoping an LTS had supported it. I guess I'll have to use Debian for Raspberry Pi. === infinity changed the topic of #ubuntu-arm to: Ubuntu ARMv7 Discussion & Development | If you have a Pi, try Debian! | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Get Precise beta 1 while it's hot! http://cdimage.ubuntu.com/releases/precise/beta-1/ Includes armhf images! | Logs at http://irclogs.ubuntu.com/ [05:13] cdnjay: Nothing wrong with running Debian. [05:13] infinity: Haha, thanks. [05:13] infinity: I haven't used it much but since Ubuntu is a fork I'm guessing they're somewhat similar? [05:14] * micahg hugs infinity [05:14] From a command-line, you'll be hard pressed to really notice any major differences. [05:14] The GUIs we provide are often quite different, but you can't possibly run a full Ubuntu deskop on a Pi anyway. [05:14] cdnjay: Debian stable has support for about another 18 months or so [05:14] er..closer to 20 [05:15] Debian's stable releases are supported for ~3 years, ~2 as current stable and 1 as oldstable [05:16] Hi everyone! I have a problem with playing videos in totem. So: http://img717.imageshack.us/img717/8930/20120311124553.png : RGB channels are moved from their positions. Is there some specific problem for arms and solution? [05:18] infinity: No, the Pi is a bit short on RAM for that. [05:18] cdnjay: A "bit"? ;) [05:19] infinity: Well, a lot short for Unity. [05:19] A lot short for GNOME in general. [05:19] xfce or lxde might barely squeeze in, but I still suspect you'd swap like made. [05:19] s/made/mad/ [05:20] I'd likely only use a Pi for CLI programming fun. [05:20] At which point, Debian and Ubuntu look nearly identical, other than a few little cosmetic bits like the motd. [05:21] lubuntu might actually run decently on it [05:21] gogasan: No idea. You might want to file a bug. [05:21] micahg: Sure, until you wanted to, like, run applications. [05:21] at least for basics, not for heavy browsing or video [05:21] video should be the one thing it doesn't suck at, actually. [05:21] In theory. [05:22] I'd just suggest running a browser other than chromium in that small footprint [05:22] Something webkit-based, ideally. [05:22] infinity: I thought minimum for Gnome was 128 MB? Pi has 256 MB. [05:22] Which reminds me, I promised Maya I'd package Wildfox for her one of these days. [05:23] well, aside from Firefox, that's all that's left in the archive ;) [05:23] Hard to take advantage of the 1080p decoding in CLI but yea, that [05:23] cdnjay: I don't tend to pay attention to stated minimums. [05:23] I the more likely use. [05:23] hmm, I shouldn't say that, I think we might have imported a browser based on fltk [05:24] I = is [05:24] dillo might actually run decently [05:24] epiphany might be alright, but every time they add a new feature to make it suck less, it gets closer to firefox in memory usage, while still being nowhere near in feature parity. [05:24] Anyway, thanks! [05:25] micahg: Surely, we must have a webkit-based browser in the archive? [05:25] infinity: firefox is going down in memory usage though, 13 is looking really good WRT memory, it used to use ~5GB resident for me and now is using ~750MB [05:25] micahg: We can't only be using webkit for embedded browsing widgets... [05:26] micahg: 13? I want your crack, I only have 11. [05:26] infinity: sure, there's midori, epiphany, I was saying the xul based browsers are gone save Firefox and I forgot, Seamonkey [05:26] infinity: firefox-trunk PPA [05:26] (But yes, I've noticed that 11 is wildly more efficient than 10 was) [05:26] Oh, epiphany switched to webkit? I must have missed when that happened. [05:27] infinity: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/ [05:27] Shows how much I pay attention. [05:27] infinity: epiphany switched to webkit in karmic with 2.28 (upstream still supported gecko for that release, but we dropped it) [05:28] Well, my ffox 11 is only eating 1.5G right now. Maybe I should try 13 and see how much gooder it is. [05:29] It does make me wonder just why it was so awful in 4 through 9, though, if it was this "easy" to find enough low-hanging fruit to cut my usage. [05:29] I used to be at around 6G on average with this same basic set of tabs. [05:29] infinity: they've started pouring resources into their memshrink operation [05:30] infinity: https://wiki.mozilla.org/Performance/MemShrink [05:30] seems also that 11 already uses a lot less memory tho' [05:31] i've got about 20 tabs open and just 400MB of usage [05:31] ah, could be, I've been on trunk for a while [05:31] gildean: Yeah, that's what I was saying. I've gone from ~6G to ~1.5G with the same set of tabs. [05:32] Still, if 13's even better, I'm willing to live on the edge for a bit. [05:32] infinity: that's pretty good too [05:33] i didn't test version 10, but between versions 9 and 11 it seems memory usage was cut in about half [05:34] micahg: Is that MemShrink thing focussing solely on firefox, or all mozilla projects? [05:34] with a small number of tabs with no heavy web-apps open in them [05:35] micahg: (Not counting shared code, of course, where they influence other projects by accident) [05:35] infinity: well, it affects the various parts of firefox which include the gecko core that affects other projects like thunderbird and seamonkey [05:36] Sure, but I suspect there are any number of Thunderbird-specific inefficiencies with local caching and the like. [05:36] sure, right, it's not focused on those, just stuff in mozilla-central AFAIK [05:37] Well, it's a start anyway. [05:37] And I might give tbird another try at some point. [05:37] Right now, it only gets opened when someone sends me pretty mail that piping to w3c from mutt can't really make sense of. [05:39] (The last such mail from from the Linux Foundation... I really need to write back and take issue with the fact that the effin' LINUX FOUNDATION was sending HTML-only email instead of multipart text/html) [05:39] It's enough to make a grown nerd cry. [05:40] i used to think that emails should be plain text [05:40] They should. [05:40] but then again, html is nothing more than plain text too [05:40] and i really like html, so i've changed my mind [05:40] But ever since html email came along, there's been an established standard for sending both in one mail. [05:40] all emails should be html [05:41] And the only people who mess up that standard are people writing broken mass-mailing software, generally. [05:41] Most MUAs get it right. [05:41] Even Outlook eventually figured it out. [05:41] So, it's pretty much just lazy web developers who think it's "too hard" to read standards and implement them in their spam scripts. === Guest35143 is now known as Termana [11:22] is there an issue with the linaro 4.6.3 compiler on armhf? if i build a kernel with it, it doesn't seem to boot. (Sadly I haven't really debugged what's going on, was just testing on a machine I had handy, most of my machines are still packed up as I moved yesterday) [11:23] infinity: personally i dislike html emails as well, there is one guy in our lug who insists on sending them, so his emails are always in this ginormous text compared to everyone elses. He also top posts so *shrug* [11:45] html emails are annoying === yofel_ is now known as yofel [19:19] hi all. is there a precise build available somewhere? [19:21] (for OMAP) [19:50] hi all. is there a precise build available somewhere? [19:50] (for OMAP) [19:50] sorry [19:50] RoyK, the URL is above, http://cdimage.ubuntu.com/releases/precise/beta-1/ [19:50] Or http://cdimage.ubuntu.com/daily-preinstalled/current/ for dailies. [20:50] hello [20:50] I am trying to boot Ubuntu Precise image using u-boot and a tegra2 board [20:51] but after typing the fatload command [20:51] it hangs [20:52] I am wondering why in the supplied boot.txt file is the fatload address 0x7000000 [20:52] what does this address mean [20:52] I was trying to find info on this in the web [20:53] but couldnt find a proper description [20:54] While reading guides on how to load different linux images on different arm devices, there was always a different address parameter [20:54] which makes sense, but what does it define exactly [20:54] and how do I know to which address should I load the uImage to? [20:55] which device [20:57] the Tegra2 board is the Colibri T20 from Toradex [20:57] and I am trying to boot Ubuntu Precise from microsdhc card [20:59] hmm [21:00] maybe try looking at their website, cause I know Colibri mainly focused on getting WinCE on their boards [21:00] not a lot of info about linux [21:00] exactly [21:00] They provide and Angstrom image [21:00] have a look at the Angstrom image [21:01] but no info on getting other Linux images running [21:01] there has to be a boot.scr or boot.cmd or boot.txt in that [21:02] the boot.* should only contain loading kernel and initrd, setenv paramters and the boot command itself, right? [21:04] here is the output of "printenv" command in u-boot [21:04] Tegra2 #printenv [21:04] baudrate=115200 [21:04] bootcmd=run flashboot; run nfsboot [21:04] bootdelay=5 [21:04] defargs=video=tegrafb vmalloc=248M [21:04] fdtaddr=17ef78 [21:04] flashargs=ip=off root=/dev/mtdblock0 rw rootfstype=yaffs2 [21:04] flashboot=setenv bootargs ${defargs} ${flashargs} ${mtdparts} ${setupargs}; echo Booting from NAND...; nboot $loadaddr 0 0x1200000 && bootm [21:04] ipaddr=192.168.10.2 [21:04] loadaddr=0x408000 [21:04] memargs=mem=372M@0M fbmem=12M@372M nvmem=128M@384M [21:04] mmcboot=echo Loading RAM disk and kernel from MMC/SD card...; mmc init && fatload mmc 0:1 0xC08000 rootfs-ext2.img.gz && fatload mmc 0:1 ${loadaddr} uImage;run ramboot [21:04] Is there any info that I can use? [21:12] fatload mmc 0:1 ${loadaddr} [21:12] load the uImage to 0x408000 [21:14] with loading the uRamdisk you need to be mindful of where other things are in memoryspace [21:16] I tend to try for ${loadaddr}+uImage+a little extra in case the uImage ends up needing a little more room [21:23] will try [21:25] So I loaded the uImage at 0x408000 [21:27] My knowledge here is limited [21:27] I am loading the image into ram [21:27] now what with the initrd? [21:28] I see: [21:28] ramargs=initrd=0xA1800000,32M ramdisk_size=32768 root=/dev/ram0 rw [21:28] so should I do: [21:29] fatload mmc 0:2 0xA1800000 uInitrd ? [21:35] so I loaded uImage into 0x408000 [21:35] initrd into 0x2408000 [21:35] changed [21:36] ramargs=initrd=0xA1800000,32M ramdisk_size=32768 root=/dev/ram0 rw [21:36] into [21:36] ramargs=initrd=0x2408000,32M ramdisk_size=32768 root=/dev/ram0 rw [21:36] typed [21:36] run ramboot [21:36] and this happened [21:36] Tegra2 # run ramboot [21:36] Booting from RAM... [21:36] ## Booting kernel from Legacy Image at 00408000 ... [21:36] Image Name: Ubuntu Kernel [21:36] Created: 2012-03-01 8:00:45 UTC [21:36] Image Type: ARM Linux Kernel Image (uncompressed) [21:36] Data Size: 4252072 Bytes = 4.1 MiB [21:36] Load Address: 70008000 [21:36] Entry Point: 70008000 [21:36] Verifying Checksum ... OK [21:36] Loading Kernel Image ... [21:37] and thats all [21:44] Test