=== Ursinha_ is now known as Guest63174 [04:58] looks like upstream Chromium almost fixed the build on arm :) [05:07] micahg: I and markos attached patches that fix chromium on armel/armhf to the debian bug [05:08] suihkulokki: now I find out, I just uploaded a new version :) [05:08] ok, I"ll grab them for the next updat [06:03] suihkulokki: I realized that I was only checking for armel in debian/rules, I fixed that for the next upload [10:28] hey kalikiana, good to see you around :) [10:31] heyhey [10:32] I checked out #arm before, seems the cool kids are all here :-P [10:32] well, here is where the community is ... way more important than the other channel ;) [10:56] hey micahg, whats that patch you talked about last night ? i think kalikiana would like to know about it === Guest18047 is now known as zumbi [10:56] ogra_: patch, what patch? [10:56] chromium [10:56] micahg: oh, you're there, was just typing a mail [10:57] I think it might work now without any patches [10:57] I'm waiting on the first armel build from yesterday [10:57] micahg: so who builds it? where's the package source? [10:57] * ogra_ only saw that riku said he attached the patches to a bug ... but didnt mention the bug number [10:58] kalikiana, in the ubuntu archive i guess [10:58] (precise sources) [10:58] I couldn't find working steps to get a cross-compile setup with all packages [10:58] kalikiana: chromium-browser? the same way anything else in the archive is built [10:58] micahg: well, but a human must have tested it :-) [10:59] kalikiana: I think Debian must have upstream their patches [10:59] meh, so yet another possible team to poke... [10:59] why ? [10:59] they will just end up in precise [10:59] I also found a bug in the packaging, which I'll fix for the next upload to get armhf [10:59] just pull the precise source package for your project [10:59] we don't merge from Debian for Chromium [11:00] micahg, that would be helpful, given we will make the switch today :) [11:00] micahg: so do you have a working build setup? [11:00] I'm running into broken deps [11:00] (armel will become unsupported from today on) [11:00] kalikiana: no, these are archive builds, I upload 2 recent stable releases to precise [11:01] hmm [11:01] I really need to build it locally [11:01] ogra_: I figured another chromium upload will come in a week or 2, if you need it sooner and armel works, I can upload with the armhf fix [11:01] yes please, we will stop caring for armel from today on [11:02] we wont stop building it, but nobody will look at issues [11:02] ok, I'll keep an eye on it [11:02] micahg: can you recommend a person who cross-compiles usually? [11:02] kalikiana: only one I know is suihkulokki :) [11:02] ogra_: "nobody" is a bit much, I always watch build issues on all ports. [11:02] ogra_: I just prioritize. :P [11:02] infinity, hey, you are not supposed to be up at that time ! [11:03] * micahg does that too :) [11:03] ogra_: I'm not, it's all in your head. [11:03] * micahg is also not supposed to be up now [11:03] micahg: k, I'll wait for him then [11:03] * ogra_ was just trying to secretly spread FUD while infinity wasnt watching ... [11:03] damned ! [11:03] (or her) [11:04] I'll be sure to call Riku a her the next time I see him. ;) [11:04] kalikiana: did you try the instructions on the linaro wiki? [11:04] lol [11:04] micahg: yes. but gconf2 and bzip2 at least are broken [11:05] file bugs? [11:06] * infinity wonders why everyone gets so excited about cross-compiling. [11:06] Especially to the point of wasting days/weeks trying to make it all work right. [11:07] infinity: because it is several times faster [11:07] When you could just build natively (sure, more slowly), but be done with it. [11:07] kalikiana: Not when you factor in all the annoyance. :P [11:08] well, the setup is actually simple. the problem is really that arm is relatively recent [11:08] yeah, its such a waste [11:08] "recent"? [11:08] heh [11:08] we even wronte instructions to cross-compile chromium: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/ChromiumCrossCompile [11:08] infinity: as in packaging :-) [11:08] yes [11:08] and those don't do it [11:08] we have it since jaunty ... [11:08] hey suihkulokki [11:08] and debian has it since ... hmm, forever [11:09] suihkulokki: gconf2 and bzip2 are broken [11:09] bug# ? [11:09] suihkulokki: the packages don't install [11:09] infinity, do you know if anyone talked to kate about armhf ? we should make her announce it in the FF announcement i think [11:10] suihkulokki: is it expected to work as described there, as in used by somebody on a regular basis? [11:10] ogra_: I brought it up when I spoke to her on the phone on Monday, but we didn't discuss a formal announcement. [11:10] kalikiana: yes if you don't deviate from the steps [11:10] ok, i'll ping here if she is up to make sure she doesnt forget [11:11] ogra_: Also, I think we need to be careful how we word such an announcement. [11:11] ogra_: People seem gung-ho to say things like "we only support armhf now!" which is patently untrue. [11:11] ogra_: It's just that we've selected armhf as the LTS arch. [11:11] k [11:12] lets make sure that goes into the announcement then [11:12] suihkulokki: I don't. so is there somebody who I could poke about those packages? I'd think bugs might not exactly receive attantion very quickly [11:12] though i suspect we will stop building armel images for some flavours [11:12] at least until your LP changes are ready [11:12] ogra_: (From a Canonical standpoint, yes, we only support armhf now, but Canonical != Ubuntu, and we need to be clear about that, or just steer clear of such statements, I prefer the latter) [11:12] kalikiana: pastebin your errors please (as well as what is in your sources.list) [11:12] ogra_: I intend to drop armel images for !omap tomorrow. [11:13] ogra_: But installer/image support != archive support. Again, distinction is key. :) [11:13] if we can it would be nice to keep el and hf for ac100 [11:13] simply for the binary driver [11:13] ogra_: Yeah, that's fair. It's also a good platform for us to keep testing armel on as a community port. [11:13] ogra_: Alright, I'll keep omap and ac100, and drop mx5 and omap4. [11:14] ++ [11:14] (The reason I'm keeping omap is simply because it's the only kernel that builds from mainline, so it's "free" from a maintenance perspective) [11:14] yeaqh [11:15] Plus, we might free up some beagles from the DC soon, and pass them around to people, thus making omap useful. ;) [11:17] ogra_: Oh, we did get some indication at Connect that nvidia is actually planning armhf builds of their binary driver. [11:17] ogra_: I was told they've already done builds in-house, they're just working on the tarball drop. [11:17] yeah, but they dont exist yet and we have no promises they will be there by release [11:17] So, we'll see. [11:18] i'm carefule about them if it comes to timelines (unlike ndec whom i belive blindly if he says it will come) [11:18] Heh. [11:18] Well, this was engineers, not legal. [11:18] suihkulokki: http://pastebin.ubuntu.com/844219/ [11:18] Which is a double-edged sword, I guess. [11:19] The engineers are doing the real work, and they know what they've done. [11:19] Then again, they don't get to do the final release to the website. [11:19] yep [11:19] fi engeneering had a say, we would have everything in since a year or two, i know [11:21] * micahg still would like an mx51 kernel for precise, but fears that's not happening [11:22] micahg: For babbage, or efika? [11:22] micahg, complain to linaro, we donmt maintain that arch :) [11:22] efika [11:22] micahg: For efika, talk to markos. [11:22] micahg: He promised me a kernel. [11:22] for what ? netbook or nettop ? [11:22] micahg: I even promised him unofficial image enablement if he got me a working kernel. :P [11:22] ogra_: Yes. [11:22] there was an or in the question [11:23] ogra_: (He seemed to think he could build one that would work on both) [11:23] ogra_: I have both, would prefer the smartbook [11:23] unless they very recently started having a unified kernel [11:23] * ogra_ too, i have one here as well [11:23] although, I guess I'd prefer an armhf kernel for mx51 :) [11:23] * infinity has a smarttop. [11:23] micahg: Kernels are FP agnostic. [11:23] oh, ok, cool [11:24] packages arent indeed :) [11:24] micahg: But seriously, nag markos. If he can get me something that's sane, I'll get it into universe. [11:24] infinity: I'm happy to be the second reviewer on that ;) [11:24] micahg: I wouldn't mind a vaguely current kernel on my efika either. :P [11:25] kalikiana: argh. looks like I have uploaded a precise targetted gconf to the ppa's oneiric side [11:25] (Though it is the slowest ARM device in my house) [11:25] you dont have beacgle A/B versions ? [11:25] kalikiana: tho the bzip2 should install just fine [11:25] * ogra_ has a beagle A1, thats definitely the slowest [11:26] suihkulokki: is there something we should fix in precise for cross compiling? [11:26] ogra_: I have no beagles. [11:26] ah [11:26] ogra_: My N900 used to be the slowest ARM device on my desk, but I sold it to Sledge. [11:26] yeah, and thats already twice as fast as an A1 [11:27] ogra_: So, now I have the efikaMX, an i.MX53, a Panda, an ac100, and an LGP999 (Tegra2 phone). [11:27] suihkulokki: ah. yes, sorry, bzip seems okay at this point. I tried a different ppa before, but made sure to clean up before I pasted [11:27] and has enormous amounts of ram compared... [11:27] It's a bit sad that the phone is actually the fastest of the bunch. [11:27] suihkulokki: any chance you could re-upload it correctly? anything I can bribe you with? :-P [11:27] stop using it as a phone then and send it to lamont as a buildd :) [11:28] I used it as a buildd during the armhf bootstrap. :P [11:28] heh [11:28] we should make tobin build a cluster of them in a rack case :) [11:31] kalikiana: testing.. will ping back in a hour or so [11:32] micahg: gconf2 is probably the most annoying thing missing multiarch conversion in precise. [11:33] micahg: So, I harassed markos, and he said they're (A) working on 3.2 for efika/mx51, and (B) it will be a unified smarttop/smartbook kernel. [11:33] micahg: And he's going to try to get me half-functional bits ASAP so I can work with them in my copious free time. [11:33] suihkulokki: we might be able to do something about that, it's still got a lot of reverse dependencies though [11:34] infinity: that's awesome, let me know if I can help with my copious amounts of free time [11:34] can't we just make chromium not use gconf? =) [11:35] not for another year :) [11:35] * micahg wonders if they have an option to s/gconf/gsettings/ [11:37] suihkulokki: wrt bzip2, I get this http://pastebin.ubuntu.com/844238/ [11:39] removing gconf from chromium shouldn't be that hard, but more time probably than fixing gconf2 packages :-P [11:39] * micahg has plenty of other archive cleanup work to do [11:39] well, it eventually needs to move to gsettings anyway [11:39] kalikiana / suihkulokki: That looks like the bzip2 in the linaro PPA was built with a broken gzip. We've fixed that bug in precise... Though, if this is an oneiric PPA, it's a crap shoot if it'll break or not. :/ [11:40] yes, it's oneriric I need to build for [11:40] kalikiana: You can work around it by just doing "dpkg --force-overwrite -i /var/cache/apt/archives/libbz2-1.0_1.0.5-6ubuntu2linaro1_armel.deb" [11:42] I'll throw backport of gzip to the ppa [11:43] infinity: same error [11:44] kalikiana: Oh, right. "rm /usr/share/doc/libbz2-1.0/changelog.Debian.gz && dpkg -i /var/cache/apt/archives/libbz2-1.0_1.0.5-6ubuntu2linaro1_armel.deb" [11:44] kalikiana: That'll make it happy. :P [11:45] evil :-D let's try [11:45] you won't believe, same error [11:46] Err, that's not possible. [11:46] Or, shouldn't be. [11:46] * ogra_ wonders how that cross build setup is set up ... might be caused by that [11:46] ogra_: No, it's just straight up multiarch and gzip sadness, I'm sure. [11:47] weird [11:47] But deleting the target before installing the other arch's package should work... [11:47] kalikiana: It's not complaining about another file now, perhaps? [11:47] kalikiana, seriously, how many days did you spend on getting that working now ? [11:47] presumably "different" here includes that it exists [11:48] ogra_: I had a different setup before that, native arm, wither other problems. although I could get it to sort of work, it wasn't exactly working well [11:48] it took in the hour range to test anything [11:50] well, the build only takes 12h [11:50] at least the lsat successfull one in the archive did [11:50] given that you alkready spent several days to get your cross setup working ... [11:51] it was not 12h, more like 2h, but still, that's no basis for working on code [11:52] 2h ? for a plain make you mean, surely not for the package build (natively) [11:52] * infinity decides to refrain from "when I was your age" stories. [11:52] haha [11:53] ogra_: when I say native I mean chroot. which I guess is faster, but still a pain [11:53] Besides, if you're "working on code", you don't rebuild from scratch every time, you have a built tree, and you let the magic of make only re-compile and re-link the bits you changed. [11:53] right [11:53] and that should just take minutes [11:53] unless you make clean every build [11:53] infinity: unfortunately it includes changing the build system [11:54] Fun. [11:54] yes. plenty. [11:54] Speaking of build systems. [11:55] I'm grumpy that I need to teach fpc about armhf after all. :/ [11:55] give it to NCommander :P [11:55] he did it several times before [11:55] Because, despite not being VFP-aware, it DOES hardcode the linker path when linking with C code. [11:55] and doesnt have libO anymore on his plate .... he needs a new challenge [11:57] suihkulokki: Say, about LibreOffice... [11:58] infinity: looks like janimo is ahead of me.. [11:59] Oh, I didn't realise Jani was working on it too. [11:59] Hrm. [11:59] Duplication of effort, for the loss. [12:00] ogra_: I could always tell people to use ebuilds when they want to cross-compile ;) [12:00] infinity: any idea how to bootstrap gnat-4.6? [12:00] micahg: Cross-compile from another arch, native compile and check for correctness. [12:01] micahg: markos was working on it, and seemed to be stuck on the latter step. [12:01] infinity: right, but how to do for the archive, same? [12:01] suihkulokki, lol [12:02] micahg: Cross, native, plunk native in my stage-2 repo of doom, build on buildds. [12:03] infinity: ah, cool, ok, that's what I thought which is why I can't do it :) [12:03] micahg: If you can get the first two steps done, I won't mind. :P [12:03] \o/ libreoffice passes the bridge tests on armhf, on to the rest of the build [12:03] micahg: If you give me a self-hosting gnat, I'll happily turn it into something archivey. [12:03] janimo`: ! [12:04] infinity, ! [12:04] * janimo` does not let himself be intimidated by excalmation marks [12:04] janimo`, !!!! [12:04] ! [12:04] Hahaha. [12:04] * janimo` collapses [12:04] janimo`: !o! [12:05] janimo`: That's awesome news. And I suspect awesome news for suihkulokki, who now doesn't have to care. :P [12:05] infinity, yep. I just need top make sure it works on OABI - the code still has that support although I am not sure who still cares [12:06] xranby, is that the 'happy drummer' sign? [12:06] janimo`: Pardon my French, but fuck OABI. [12:06] janimo`: If anyone's building Open/LibreOffice for OABI, they should be shot. [12:06] infinity, my thoughts exactly only I express them more delicately [12:07] I was not sure how much Debian cares about baxckporting TBH, I am not sure either how much of Debian users are on legacy hw/installs [12:07] janimo`: More to the point, while an upstreamable fix might need to keep OABI working (though, god knows why), a Debian/Ubuntu patch clearly doesn't. [12:08] I plan on pushing upstream today [12:08] and deal with bug reports if OABI people come along [12:08] janimo`: Debian doesn't support OABI. [12:08] OABI is forgotten in debian. however we should check it doesn't break EABI softfloat [12:08] I'll put ifdef around FP regs usage and that should be all I guess [12:08] suihkulokki: EABI soft, or softfp? [12:08] suihkulokki, test passes on armel as well [12:08] but only hardfloat tested [12:08] (God, that's confusing) [12:09] janimo`: Our armel is softfp, which is still VFP-aware. [12:09] I have no soft (no FPREGS usage at all) setup [12:09] janimo`: Debian's armel isn't. [12:09] And somewhere along the way, my head explodes. [12:09] aha, that indeed needs to be checked for, I'll make use of the SOFTFP define then and hope it is not too much work [12:11] infinity, suihkulokki can I test a Debian/softfloat setup in an ubuntu hosted chroot ? just create a sid-armel one? [12:11] janimo`: yes [12:11] schroot I mean if it matters [12:11] oh great then [12:12] janimo`: Yeah, kernels are completely VFP agnostic, so debian-armel chroots work fine. [12:12] (And armhf, and, and) [12:13] excellent [12:14] janimo`: didn't you ifdef the hardfb abi with__ARM_PCS_VFP already? that should not be set on either debian or ubuntu armel [12:14] suihkulokki, yes that one I used [12:14] but I noticed there's another SOFTFP variable too [12:14] so it may all just work indeed [12:14] Which may or may not relate to softfp. [12:14] hardfb ? hard floating bubble ? [12:15] Because the soft/softfloat/softfp naming between toolchain and userspace applications is never consistent. :P [12:15] (Heck, it gets even worse when Oracle refers to softfp as "hard-float") [12:15] heh yes. [12:15] haha [12:15] And they're not wrong. It is hard float. Just not what WE call hard float. [12:16] its kind of funny oracle compared their tuned armel builds against icedte built using debian squeeze [12:16] could have been worse [12:16] they could have built against woddy [12:17] We didn't have armel in woody, did we? [12:17] nah [12:17] woody would have been OABI, I believe. [12:17] only arm i think, if at all [12:17] But it's been a while. [12:18] i think we are doing good, at least our work runs on the armhf ABI [12:19] I dunno. I gnored all you ARM weirdos back then. I was working on promising new future technologies like m68k and parisc. [12:19] mips ? [12:19] I wasn't a mips porter, no. :) [12:20] 68k, parisc, powerpc, and alpha. I sure can pick 'em. [12:20] 1 out of 4 isn't bad, right? :P [12:21] mmm, alpha ... i loved them [12:21] * janimo` completely forgot how he created the precise-armhf schroot, now needs to figure out same for debian.sigh [12:21] I do not recall running debootstrap explicitly [12:21] and my bash history agrees [12:21] it may have been mk-sbuild [12:22] janimo`: debootstrap --variant=buildd --arch=armel sid sid-armel http://ftp.debian.org/debian [12:22] janimo`: Ish? [12:22] yes, it was not that I guess, probably mk-sbuild did it all behinf the curtains for me [12:23] do debootstrap and schroot have a common location for chroots in which case I may just do that above [12:23] mk-sbuild --eatmydata --arch=armel precise was it [12:25] * janimo` remembers seeing the one and only alpha machine sometime in 94 at an expo. It was higher Mhz that the 486's (150 I think) and it had a video promo of Jean Luc Picard extolling its virtues [12:26] probably they though it was meant for enterprise servers [12:26] janimo`: debootstrap has no canonical location for anything, it just creates the chroot where you tell it to. [12:27] infinity, ok I just started a mk-sbuild so it is stored along with the rest of schroots [12:28] perhaps I can do the debian/armel build and testing [12:29] suihkulokki, sure thanks. I am setting up a sid chroot now but my panda would be happier if left to build only a precise armhf and not something else in parallel :) [12:32] janimo`: ok, on it [12:36] suihkulokki, softfloat in debian mean no actual VFP instructions in asm right? Not that they are trapped and emulated by the kernel [12:41] suihkulokki, you can stop the build after a couple of hours (not sure when) once the deps for bridges/ and testtools/ are built. [12:41] then make bridges.deliver testtools alternating with changes to code is easy iteratin [12:42] janimo`: do you have a line to grep in the buildlog when bridges have compiled? [13:04] suihkulokki, hmm, not sure I know where the bridges' module number is [13:04] what I did was ctrl-c and see if make brdiges works or says it has files missing [13:05] but gcc3_linux_arm is a dir within bridges that needs to be entered so maybe good for grepping [13:11] last build of libo on armel in the buildd: 5 days 19 hours. Ouch [13:11] janimo`: On a babbage, I assume? [13:12] assuming a panda is used instead of babbage it still likely be 1-2 days [13:12] infinity, yes some old board [13:12] I think with pandas it was over a day too last cycle [13:12] or whenever we had pandas built libo [13:12] Yeah, a dayish sounds about right. [13:12] by accident [13:12] so I am not holding my breath today for it to complete === doko_ is now known as doko [15:06] .c [15:48] infinity: actually, the test suite failure I was fixing in upstart was unrelated... the one on arm*/ppc is still there, and I'm not sure what to make of it [15:52] slangasek: Oh, it just happens to be in the same test. But, you're right, different error. [16:12] infinity: yes, the "same", 4kloc test ;) [16:16] slangasek: Ugh. [16:27] suihkulokki: did you upload updates for libbz2 or gconf2 yet? [16:36] kalikiana: yes but bzip2 is still building [16:56] this morning's dump of updates seems to have another alsa bug [16:56] ALSA lib conf.c:1220:(parse_def) show is not a compound [16:56] ALSA lib conf.c:1686:(snd_config_load1) _toplevel_:24:26:Unexpected char [16:56] ALSA lib conf.c:3406:(config_file_open) /usr/share/alsa/pulse-alsa.conf may be old or corrupted: consider to remove or fix it [16:57] show { [16:57] @func refer [16:57] name defaults.namehint.basic [16:57] } [17:34] infinity: ah, I understand jhunt has figured out the race in the test that was causing things to fail, so we should have a fixed package tomorrow-ish [17:34] slangasek: \o/ [18:17] ALLCON: I am attempting to setup ubuntu server 11.10 on a Pandaboard es with no luck. I attempted multiple times with the same pre-installed distro with different outcomes. They range to when the system unpacks and reboots, I either booting and then nothing, booting and then root access. With root access I try to adduser and get one of two options: The user is added but not in the sudoers list, or the user is not added and I [18:18] I gave up for a while and tried installing 12.04 and had no issues at all. It went straight to the installation screen, gave me all my options, and then worked great. I just went back to 11.10 since it is supported [18:18] Is there anyone who may know what is wrong and could help [18:18] orion___: 11.10 doesn't have full support for the 4460 in u-boot or kernel. [18:19] It can cause overheating. [18:19] is there a better option to go with [18:19] I am testing 12.04 daily. It is very stable, but since it is in development, constantly updating stuff. [18:20] You should be fairly safe running Alpha 2, then upgrading during milestones (beta 1, 2, etc). [18:20] yeah, this is going onto a robot that needs to be mostly stable. I will only need usb, ethernet, wireless (maybe bluetooth), and the ability to work with the gpio if needed [18:21] Ah. Yea, stick with the 12.04 and just turn off auto-updating. [18:21] How are the service packages with 12.04. For instance, I tried to download openjdk as a quick test with 12.04 and couldnt find it [18:22] It is there. I use it daily to run a Jenkins slave. I use open-jdk-jre-headless, but I also just tried default-jdk. [18:22] got it [18:23] just must have missed it then [18:23] default-jdk will give you a lot more packages, but only really usefull cor compiling java. [18:23] /cor/for [18:23] and would you say that 12.04 server is the fastest build for pandaboard es right now? [18:24] Yes. Especially the armhf release. BTW, we will no longer be making armel images after today. [18:25] orion___: i will voice for 12.04 armhf builds be wicked fast [18:25] got it. I would rather hf anyways [18:25] err confirm [18:25] my english this morning is a little off [18:26] thanks to both of you. I will go back to 12.04 then [18:26] (though slap a hard drive on the thing.. running off the sd card is pure pain) [18:26] yeah, that is another area I am noticing [18:26] Linux panda 3.2.0-1406-omap4 #8-Ubuntu SMP PREEMPT Tue Feb 14 16:12:38 UTC 2012 armv7l armv7l armv7l GNU/Linux [18:26] thinking of getting an ssd [18:26] here is what i did [18:26] LABEL=home /home ext4 defaults,noatime,errors=remount-ro 0 0 [18:26] LABEL=usr /usr ext4 defaults,noatime,errors=remount-ro 0 0 [18:26] LABEL=var /var ext2 defaults,noatime,errors=remount-ro 0 0 [18:26] tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0 [18:26] tmpfs /var/log tmpfs defaults,noexec,nosuid 0 0 [18:26] tmpfs /var/run tmpfs defaults,noexec,nosuid 0 0 [18:26] tmpfs /var/lock tmpfs defaults,noexec,nosuid 0 0 [18:27] though ill probably migrate /var/log to the hard drive [18:27] i had it in a ramdisk before i added the hd [18:27] got it [18:28] GrueMaster: btw it looks like that sound patch made it in the recent kernel build \o/ [18:28] thanks to both of you [18:28] for your robot usage, SD should be fine. It really only sucks when you have a lot of io load. [18:28] (by a lot he means more then 2 MB/s [18:28] pbuckley: Yes, I was told today. Also fixed the ucm configs last week. [18:28] ) [18:28] the robot will be communicating with the google cloud and with other robots [18:28] indeed.. there is a new alsa bug i mentioned earlier [18:28] but it doesnt break functionality [18:28] sounds cool. [18:28] just throws a warning [18:29] orion___: sweet.. graduate project? [18:29] also, may be using opencv, so there is a bit of IO [18:29] pbuckley: I'll look into it. [18:29] pbuckley: yes [18:29] reminds me of [18:29] http://www.google.com/url?sa=t&rct=j&q=ryan%20walker%20robot&source=web&cd=1&ved=0CCYQFjAA&url=http%3A%2F%2Fweb.cs.swarthmore.edu%2F~meeden%2Fcs81%2Fs09%2Ffinals%2FRyan.pdf&ei=Eks9T4H4AuTUiALj-dzDAQ&usg=AFQjCNG3THVik7wByH61j67PnDqGDWn2Ww&cad=rja [18:30] pbuckley: pioneer robots? [18:32] pbuckley: same ideas. Going to be multiple ground and air vehicles cooperating togehter [18:32] *together [18:32] if you want me to hook you up with that author of that paper hes usually interested in talking about robots ;) [18:33] that's be great, however this wont be my common irc name. Using webirc now, working on setting up a more permanent version right now === orion is now known as Guest77645 [18:37] strange [18:37] pbuckley: think i got it setup [18:39] pbuckley: yeah, looking at the paper, it seems pretty good with the adaptive controls [18:40] orion__: When you start diving into this on the panda, I recomment you keep a complete copy of your workspace on your desktop that you can just dump into the SD after flashing a new image. It is much faster to flash a fresh image than it is to update on SD. [18:41] GrueMaster: do you mean a complete copy of code, etc. I haven't moved anything to the distro yet. I am currently getting the board setup first to move code from a chumby hacker board [18:43] Yes. What I do with my test projects is store them in a self-contained tarball, When I run them, I assume a clean image and install the necessary packages, change the environment settings, etc accordingly. [18:44] Too often someone on here complains that they lose a lot of work when they decide to upgrade and they are on SD. [18:44] I prefer to think of the SD as a good demo image/embedded project storage that is volatile. [18:45] I see what you are saying. I will be working on setting up a cross compiler environment on my laptop soon. I will then be holding my projects both on the laptop and pandaboard so that shouldnt be a problem [18:46] Can't wait to see your project on youtube. :P [18:47] orion__: distcc is also fun [18:47] me too. We already have 6 ground vehicles working well. Working on building 2 quadcopters at the moment, but those won't be done until the beginning of summer [18:49] Anways, I don't want to tie up the board. I appreciate both of your help. [18:50] come back soon ;) [18:50] I'll be hanging out. Still have to see if this goes smoothly [18:50] :D [18:51] and the download for 12.04 is going very slow today === orion__ is now known as Epsilonorion [18:55] pbuckley: This will be my main name if I am on [18:58] alright.. ill let him know.. he's in the zone tippity tapping [18:58] GrueMaster: Actually one question. Should I download the current daily build or the alpha 2 version the channel provides a link for [18:59]