[00:21] <RobotGuy> Is there a way to get gcc 4.3 instead of 4.4 or 4.5?
[01:20] <RobotGuy> Is there a way I can tell rootstock to use gcc 4.3 instead of the later compilers?
[01:21] <rcn-ee> RobotGuy, are building stuff in roostock? otherwise select the 'gcc-4.3' package..
[01:22] <RobotGuy> Yes, rootstock.  I tried selecting gcc-4.3 but it doesn't seem to work.
[01:22] <rcn-ee> what do you mean it doesn't work?
[01:23] <RobotGuy> It still takes gcc 4.5
[01:23] <RobotGuy> Or maybe it is 4.4, but not 4.3
[01:23] <rcn-ee> when you call "gcc" in your image? gcc-default does that, either call "gcc-4.3" in your build script or change the setting in ubuntu..
[01:24] <RobotGuy> I already told you I did that - selected "gcc-4.3" and it doesn't get me gcc 4.3
[01:24] <rcn-ee> which distro?
[01:25] <RobotGuy> Ubuntu built with rootstock.
[01:25] <rcn-ee> RobotGuy, lucid/maverick?
[01:25] <RobotGuy> 10.10 Maverick
[01:26] <rcn-ee> it exists.. http://packages.ubuntu.com/maverick/gcc-4.3 package name "gcc-4.3" to your seed or "sudo apt-get install gcc-4.3" will instal it later..
[01:26] <rcn-ee> but you 'unverise' enabled in rootstock..
[01:27] <RobotGuy> I haven't done anything to rootstock - it is as it was installed.
[01:28] <rcn-ee> RobotGuy, so you added "gcc-4.3" to the seed and you say it doesn't work..  what doesn't work about it in your mind?
[01:40] <RobotGuy> I still see it pulling "gcc-4.5-base"
[01:40] <cwillu_at_work> RobotGuy, adding a package won't generally remove a package
[01:40] <cwillu_at_work> I believe there's an option to remove a package from the seed though
[01:40] <cwillu_at_work> (not sure, my rootstock is thoroughly hacked up, and I promised to write up my changes and upstream them some day :p)
[01:41] <RobotGuy> This is not intuitive at all.
[01:41] <rcn-ee> it's not really suppost to be.. just a quick way to make a base image... add the extra's later...
[01:41] <cwillu_at_work> RobotGuy, adding a package shouldn't remove packages.
[01:42] <RobotGuy> I want to replace a package.
[01:42] <cwillu_at_work> RobotGuy, if you want to replace a desk, how do you go about doing that?
[01:43] <RobotGuy> There is also apparently a problem with Ubuntu recognizing the ethernet on the Beagle-xM.
[01:43] <ScottK> RobotGuy: Having GCC 4.5 installed doesn't preclude you from building with 4.3 if it's also installed.  4.5 is part of the build-essential metapackage for 10.10 so it's assume to be there for building.
[01:43] <cwillu_at_work> unrelated :p
[01:43] <RobotGuy> cwillu_at_work: I'm not a first grader
[01:44] <rcn-ee> RobotGuy, pulling in 'gcc-4.5-base' happens.. you want "gcc-4.3" that depends on "libc6" which depends on "libgcc1" which depends on "gcc-4.5-base" ... ;)
[01:44] <rcn-ee> just a big circle..
[01:44] <cwillu_at_work> RobotGuy, I didn't say that you were, and supplying an analogous example was recognition of intelligence
[01:45] <cwillu_at_work> there's that bit, too :)
[01:45] <RobotGuy> gcc 4.4 and 4.5 just seem to be big problems.
[01:46] <cwillu_at_work> what problems are you seeing?
[01:46] <RobotGuy> Internal compiler errors
[01:46] <cwillu_at_work> I suspect you're doing something wrong somewhere;  what's your build setup like?
[01:47] <RobotGuy> I'm just trying to build a kernel.
[01:47] <cwillu_at_work> how?
[01:47] <cwillu_at_work> native builds?  cross compiling?  qemu?
[01:47] <RobotGuy> On beagleboard
[01:48] <cwillu_at_work> c4?
[01:48] <RobotGuy> No, Beagle-xM A2
[01:49] <cwillu_at_work> okay;  xm is a different beast from the other beagles
[01:49] <cwillu_at_work> and one which I don't own  :(
[01:49]  * cwillu_at_work accepts donations :p
[01:50] <cwillu_at_work> which distro and version?
[01:50] <cwillu_at_work> any oddities on how things were installed?
[01:50] <cwillu_at_work> hell, is the xm even stable in general?  :)
[01:51] <RobotGuy> Ubuntu 10.10 built from rootstock.
[01:52] <rcn-ee> the most important thing is 'what' kernel and 'what' clockspeed only angstrom's can handle the full 1Ghz, mine limited to 800mhz otherwise it's unstable..
[01:53] <cwillu_at_work> not even rcn-ee is perfect :)
[01:53] <rcn-ee> specially with zippy's... i think it esd'd it today, everything but the ks8851 works on it..
[01:53] <RobotGuy> It's a 2.6.35 kernel.
[01:54] <rcn-ee> ubuntu's?
[01:54] <cwillu_at_work> RobotGuy, the included patches matter
[01:54] <RobotGuy> Yes
[01:54] <RobotGuy> I don't have any idea what patches - it comes with linux-image-omap
[01:54] <rcn-ee> it should work, never tested itmy self.. can you "dmesg | grep mpurate|core"
[01:55] <RobotGuy> rcn-ee: I haven't changed the clock rate
[01:55] <rcn-ee> then it should be the default 500ish.. no idea why your board is iceing in gcc, it shouldn't..
[01:56] <RobotGuy> 500? Mine says 800
[01:56] <rcn-ee> oh great...
[01:56] <rcn-ee> your running an image with my install script with ubuntu's kernel and pushing 800... no idea if that's stable, nor have tested it..
[01:57] <RobotGuy> I didn't change anything.
[01:57] <rcn-ee> can you pastebin the boot.scr in the fatfs?
[01:58] <RobotGuy> You're telling me that to use Ubuntu, I have to run at half the speed of my board?
[01:58] <cwillu_at_work> rcn-ee, your kernel brings up the network on that, no?
[01:59] <RobotGuy> I've never been  able to get networking to work.
[01:59] <cwillu_at_work> RobotGuy, you're not using rcn's kernel
[01:59] <rcn-ee> it should, it does on all my xM boards..
[02:00] <cwillu_at_work> RobotGuy, rerun rootstock with one of his kernel's (which iirc is how rootstock is intended to be used anyway)
[02:00] <rcn-ee> RobotGuy, the ubuntu guys didn't get a working xM board till a week before freeze... my timelines are much more relaxed.. 'aka oh crap, lets upload a fix now'
[02:00] <RobotGuy> You're not listening to me.
[02:00] <cwillu_at_work> RobotGuy, no, you're not listening to us.
[02:00] <RobotGuy> I have not changed anything in rootstock.
[02:00] <cwillu_at_work> you're doing things wrong, and expecting it not to matter.
[02:01] <RobotGuy> How am I doing things wrong?
[02:02] <RobotGuy> What am I doing wrong?
 then it should be the default 500ish.. no idea why your board is iceing in gcc, it shouldn't..
[02:02] <cwillu_at_work> because
 RobotGuy, the ubuntu guys didn't get a working xM board till a week before freeze
[02:02] <cwillu_at_work> therefore
 the most important thing is 'what' kernel and 'what' clockspeed only angstrom's can handle the full 1Ghz, mine limited to 800mhz otherwise it's unstable..
[02:03] <RobotGuy> We seem to be going round in circles and I am getting quite dizzy.
[02:03] <cwillu_at_work> :)
[02:03] <cwillu_at_work> RobotGuy, if you want to use rootstock, and you want to run at 800mhz, then you need to supply rcn's kernel.  You can probably do this without remaking the image, although it's a bit finicky
[02:04] <cwillu_at_work> If you use rcn's kernel, the network will also Just Work.
[02:04] <RobotGuy> I keep telling you people that I did not change the clockrate.
[02:04] <cwillu_at_work> (incidently, I can has preempt_voluntary kernel now rcn-ee?)   :)
[02:04] <cwillu_at_work> RobotGuy, and we keep telling you that the ubuntu kernel isn't stable at the default clockrate
[02:05] <cwillu_at_work> there are required patches which weren't available when ubuntu's kernel was frozen for release
[02:05] <cwillu_at_work> only angstrom's kernel has all the patches (because that's where they get developed for the most part)
[02:05] <cwillu_at_work> eventually everybody will have them, but the hardware only came out a couple months ago.
[02:05] <rcn-ee> RobotGuy, if it's running 800Mhz, more then likely you used my "setup_sdcard.sh" script.. a "cat boot.scr | pastebinit" would prove it..
[02:05] <RobotGuy> Obviously, trying to use Ubuntu was not a good idea for me.  Bummer.  I thought it would be better.
[02:06] <rcn-ee> it's that boot.scr script that changes it to 800
[02:06] <cwillu_at_work> RobotGuy, don't be that way.  Every mainline distro will be weird at this point.
[02:06] <cwillu_at_work> er, major
[02:06] <cwillu_at_work> You need to substitute one piece, and everything will work fine.
[02:07] <RobotGuy> What piece?
[02:07] <cwillu_at_work> rcn-ee, 2.6.36-dl13?
[02:07] <cwillu_at_work> http://rcn-ee.net/deb/maverick/v2.6.36-dl3/
[02:07] <cwillu_at_work> RobotGuy, as it stands, you're mixing and matching pieces which assume you're doing it this way anyway
[02:08] <cwillu_at_work> it's an honest mistake, especially common with new hardware
[02:08] <cwillu_at_work> but it's not our fault any more than it's your fault.
[02:08] <RobotGuy> This is not making sense to me. :(
[02:09] <cwillu_at_work> RobotGuy, can you run the command rcn-ee gave you please?
[02:09] <RobotGuy> I need to be able to use the full speed of my Beagle-xM. If Ubuntu can't do that, then I can't use Ubuntu right now.
[02:09] <cwillu_at_work> pastebinit boot.scr
[02:10] <rcn-ee> RobotGuy, 'full' speed is only one option right now and it's angstrom, and it's on TI's 2.6.32 kernel.. The rest of us will have that hopefully in 2.6.37...
[02:10] <cwillu_at_work> RobotGuy, so you run a different kernel, which is already packaged at the address I gave you above.
[02:11] <RobotGuy> Which is it? Ubuntu can or can not run at full speed on a Beagle-xM?
[02:11] <cwillu_at_work> none of this has anything to do with networking, nor gcc-4.4/4.5
[02:11] <cwillu_at_work> RobotGuy, ubuntu with rcn's kernel will run at 800mhz right now, and will run at 1ghz in january
[02:12] <RobotGuy> OK, that answers my question.  I'll try Ubuntu again in January or Feb then.
[02:12] <RobotGuy> We can't hold up development that long.
[02:12] <cwillu_at_work> how does this hold up development?
[02:12] <rcn-ee> i was thinking next week.. ;) but git rebase of dvfs-pm was a huge mess. ;)
[02:12] <cwillu_at_work> rcn-ee, I was being conservative :p
[02:12] <RobotGuy> I told you - we need the full speed of the Beagle-xM now.
[02:13] <cwillu_at_work> how could you possibly know that?
[02:13] <rcn-ee> yeah stable for everyone else..  january.. ;)
[02:13] <rcn-ee> cwillu_at_work, does btrfs seem to bog down for you in git tree's?
[02:13] <RobotGuy> The nature of our project requires top speed.
[02:13] <cwillu_at_work> rcn-ee, heh, complicated question :p
[02:14] <cwillu_at_work> RobotGuy, this is probably a good time to mention that ti's hardware isn't intended for prototyping of actual products, or actual deployment
[02:14] <cwillu_at_work> er, the beagle's
[02:14] <rcn-ee> git checkout's seem to bog when going from Head to a older branch... i think i really need to enable the new 2.6.37 mount opiton..
[02:14] <rcn-ee> RobotGuy, optomize more.. ;)
[02:15] <RobotGuy> I am well aware of that.  We are developing, not producing.
[02:15] <cwillu_at_work> RobotGuy, if you're developing, then the product speed doesn't matter.  multiply your benchmarks by 20% :p
[02:15] <RobotGuy> Speed does matter, but I am not here to argue.
[02:16] <cwillu_at_work> rcn-ee, you mean the git commands themselves?
[02:16] <rcn-ee> yeah, like a git fetch; git checkout HEAD; git checkout an old branch..
[02:17] <cwillu_at_work> I haven't noticed anything, but
[02:17] <cwillu_at_work> might try running a defrag
[02:17] <cwillu_at_work> which mount options are you using currently?  (or have used in the past, some are sticky)
[02:17] <cwillu_at_work> (note that defrag operates on specific folders and files;  it's not enough to specify the root)
[02:17] <rcn-ee> could be, i build a lot of kernels on this machine.. or one of the two enabled but not 'advertised' cores is failing on this fake x4..
[02:18] <rcn-ee> just 'btrfs defaults' in /etc/fstab...
[02:18] <cwillu_at_work> nochecksum,nocow might help matters, at least for things like builds and so forth
[02:18] <cwillu_at_work> you'd have to do a separate btrfs filesystem though, as those currently can't be set separately on subvolumes
[02:19] <rcn-ee> okay, i'll try that..
[02:19] <cwillu_at_work> bah, he left
[02:19] <cwillu_at_work> I was going to mention that pandaboard might be more useful
[02:20] <rcn-ee> he's been stuck on that issue since like tuesday night...
[02:20] <cwillu_at_work> yeah, I'm pretty sure he's been told 3 different build approaches that would give him the end result he wants
[02:20] <cwillu_at_work> and he's consistently refused to follow any one of them :p
[02:21] <rcn-ee> yeap, it's a receipe for disaster..
[02:21] <cwillu_at_work> I feel like I was getting overly crotchety, but...
[02:22] <cwillu_at_work> anyways
[02:22] <cwillu_at_work> rcn-ee, so, I see you're at home now  :)
[02:23] <rcn-ee> yeah... 8ish to 5ish.. ;)
[02:23] <cwillu_at_work> do you know what that means?  :)
[02:23] <rcn-ee> i can never be found...
[02:23] <cwillu_at_work> hint:  it involves a kernel :)
[02:24] <rcn-ee> cwillu_at_work, here they are: http://rcn-ee.homeip.net:81/testing/2.6.36-something/  (forgot what i enabled, but it was that one thing)
[02:25] <cwillu_at_work> \o/
[02:25] <cwillu_at_work> thanks
[02:25] <cwillu_at_work> preempt_voluntary I believe
[02:26] <rcn-ee> yeah that.. i knew it was 'something'
[02:28] <cwillu_at_work> rcn-ee, without ck?
[02:28] <rcn-ee> yeah, without ck...
[02:38] <enth> Does ubuntu ARM work on StrongARM / PXA27xx processors?
[02:39] <rcn-ee> enth, not really, that stuff is too old... debian or angstrom is really your only options...
[02:42] <enth> \: Ok thanks.
[02:44] <cwillu_at_work> download complete
[02:44] <rcn-ee> yay i get my bandwidth back. ;)
[02:45] <cwillu_at_work> I was going to apologize for your untimely responses :)
[02:45] <rcn-ee> i'm just drinking a beer, waiting for stuff to build.. ;)
[02:46] <cwillu_at_work> while you wait:  http://www.fanfiction.net/s/4068153/1/
[02:46] <cwillu_at_work> :p
[02:48] <cwillu_at_work> booting
[02:48] <cwillu_at_work> (with the network plugged in, no less!)
[02:49] <cwillu_at_work> that was quick
[02:49] <rcn-ee> quick hard lock?
[02:50] <cwillu_at_work> yep
[02:52] <cwillu_at_work> and again
[02:53] <cwillu_at_work> okay, it's not my full preempt sillyness triggering this then
[02:53] <cwillu_at_work> rcn-ee, incidently, you mentioned that ks8851 was troublesome at 1ghz;  it isn't troublesome in the same way is it?
[02:54] <rcn-ee> no, it's the omap part, needs a voltage bump to the next level thru smartreflex
[02:55] <cwillu_at_work> okay
[02:55] <cwillu_at_work> tempted to get one just to reproduce this :p
[12:56] <sveinse> I understand that a lot of you is running Ubuntu off a (micro) SD card, right?
[12:57] <sveinse> Yesterday I purchased a new Class 4 Kingston 8GB micro SD. However, this card is something of the slowest I've ever seen running Ubuntu on
[12:58] <sveinse> My old 2GB Trancend (which was bundled with a HTC phone) is *much* faster
[12:58] <sveinse> Have any of you experienced differences and difficulties in respect of memory cards?
[12:58] <sveinse> I.e. how can I find one with is fast?..
[13:15] <ogra_ac> take class 10
[13:18] <sveinse> But the class is related to read/write speeds.
[13:18] <sveinse> I did a bonnie++ comparison between the two cards. Suprisingly the read/write rates were comparible
[13:20] <sveinse> However the latency on IO were 4-5 times higher on the newest card.  Example. latency on random create read were 3174 us on the new, while 184 us on the old
[13:21] <sveinse> So obviously there is some other parameter here which is not covered by the class concept
[13:24] <ogra_ac> well, i get nearly USB results with class 10 cards here
[13:24] <sveinse> Yeah, I'll see if I can get my hands on one. Which brand?
[13:25] <ogra_ac> i had good results with panasonic gold cards
[13:25] <sveinse> Panasonic. Interesting
[13:27] <sveinse> I not surprised though. I've had previous experiences that the off-the-radio-shack-shelf cards can be cheap (i.e. poor quality)
[17:06] <Neko__> hey guys, anyone have any official view or a wiki or something on how to version packages based on git repos?
[17:10] <Neko__> mainly for kernel packages
[17:10] <Neko__> git commit ids aren't debian standards compliant so I can't make the debian --revision thing the tag
[18:18] <ScottK> Neko: Debian package versioning has to be monotonically increasing so using git ids is out.  I usually use the date, i.e. 2010113, instead.
[18:18] <Neko> but some packages have stuff like +gitblahblah or ~gitsomething or ~something at least
[18:18] <Neko> I never found anything which tells me what these really mean or what is recommended
[18:18] <Neko> now I check I can't even find a package with that versioning but I know there are some :D
[18:22] <ScottK> I'm familiar with it.
[18:22] <ScottK> In Debian versionin "~" is somewhat magical in that it's less than anything else.
[18:23] <ScottK> So 1.0~git20101113 is less than 1.0.  You'd use this to indicate some pre-1.0 snapshot.
[18:23] <ScottK> If you're packaging something that's a bit beyond 1.0, you'd use 1.0+git20101113 since that's higher than 1.0.
[18:24] <ScottK> Neko: Does that clarify it?
[18:25] <Neko> oh-ho! I see :)