[00:24] <rcn-ee> ogra, with 2.6.32-rc6 landing alot of the beagleboard now works on mainline.  What's the best way to introduce a new target via config for lucid? ;)
[05:48] <Ford_Prefect|w> Hello folks
[05:49] <Ford_Prefect|w> I'm trying to build an ARM cross toolchain to match the native toolchain from Ubuntu's ARM repository
[05:49] <Ford_Prefect|w> Has anybody done this already?
[05:53] <Stskeeps> lbt may have
[05:53] <Stskeeps> we use one in our obs cross setup at least
[05:58] <Ford_Prefect|w> Um lbt? obs?
[05:59] <Ford_Prefect|w> Thought I'd try apt-cross but it obstinately refuses to look at Ubuntu source mirrors
[06:00] <Stskeeps> lbt=a nickname, obs=a builder service
[06:00] <Ford_Prefect|w> Stskeeps, okay. Will wait till lbt shows up, I guess.
[06:05] <NCommander> Ford_Prefect|w, why do you want a cross-compiler
[06:05] <NCommander> The toolchain packages are the same across all architectures. You can get the most recent source suitable for building cross-compilers by installing binutils-source, gcc-source, and glibc-source
[06:09] <Ford_Prefect|w> NCommander, I'm working on an SDK which provides a cross-compiler
[06:09] <Ford_Prefect|w> So development happens on the host, binaries are copied to the target
[06:10] <NCommander> Ford_Prefect|w, with the target running Ubuntu or?
[06:10] <Ford_Prefect|w> NCommander, I can pull the sources on the host but I was hoping to find scripts to do the whole bootstrapping shebang
[06:10] <Ford_Prefect|w> NCommander, Ubuntu
[06:10] <Ford_Prefect|w> On the target and host, both
[06:10] <NCommander> Ford_Prefect|w, in general, we don't support cross-compiling for Ubuntu.
[06:10] <NCommander> Everything is natively compiled
[06:11] <NCommander> There are a few guides though to getting the toolchain off the ground
[06:12] <Ford_Prefect|w> Okay. I think before long I won't be the only one who needs this. :)
[06:16] <Ford_Prefect|w> As in, cross-compiling is a common enough use case in a lot of development environments, so it wouild be good to have a standard method to generate and use these.
[06:19] <Stskeeps> Ford_Prefect|w: talk to lbt for sure :) we have a very cool solution in this regard
[06:19] <Stskeeps> building qt for armel in 4 hours
[06:20] <Ford_Prefect|w> Ah, excellent
[06:20] <Ford_Prefect|w> But wow, 4 hours?
[06:20] <Ford_Prefect|w> Does it really take that long on the host?
[06:20]  * Ford_Prefect|w huggles gtk and glib :P
[06:20] <Stskeeps> it takes 3-4 days natively

[06:21] <Ford_Prefect|w> These are those orion5x' I've hear of?
[06:22] <Stskeeps> either way we compiled our entire Mer with gtk,glib,qt in a day :P
[06:22] <Ford_Prefect|w> Ah, omap2 :)
[06:22] <Ford_Prefect|w> Reminds me that I need to try Mer out on my N810
[06:22] <Stskeeps> doesnt have to be omap2 :P
[06:23] <Ford_Prefect|w> :) True, dat
[06:25] <Stskeeps> check out http://wiki.maemo.org/Mer/Build , especially the cross section
[06:26] <Ford_Prefect|w> Thanks! ... looking
[06:36] <Ford_Prefect|w> We're actually using CodeSourcery's toolchain for cross-compiling right now, but there's potential for ABI breakage there, since they're not the same version as on the target
[06:36] <Stskeeps> yeah, it is better to have matching
[06:40]  * armin76 looks at Ford_Prefect|w 
[06:40] <Ford_Prefect|w> Heya armin76 :)
[06:40] <Ford_Prefect|w> (don't ask me why we're not just using Gentoo and crossdev :P)
[07:06] <NCommander> Stskeeps, depends on what hardware you have ;-)
[07:06] <Stskeeps> NCommander: yes, of course :P
[07:06] <NCommander> Stskeeps, I can build Qt4 on native hardware in 18-25 hours
[07:33] <dpb> Anyone know some legal stuff here? If I release an image for some hardware that's mainly Ubuntu but has some other packages added, can it be called an Ubuntu image, or do I need to rename it?
[08:23] <Ford_Prefect|w> NCommander, out of curiosity, what hardware is that?
[08:23] <NCommander> Ford_Prefect|w, Marvell Dove Y0/Y1, and Freescale Babbage iMX51
[08:24] <Ford_Prefect|w> Ah
[08:24] <NCommander> dpb, http://www.ubuntu.com/aboutus/trademarkpolicy - trademark policy if here
[08:25] <NCommander> dpb, its pretty clear on what you can and can't call Ubuntu or an Ubuntu Remix
[08:45] <Stskeeps> Ford_Prefect|w: /msg lbt
[09:00] <Ford_Prefect|w> Stskeeps, doing so
[13:35] <BeardedChimp> If I have the source code that compiled the kernel, where from that source code can I extract the headers that are normally downloaded through apt-get install linux-headers-(uname -r)
[15:29] <dmart> Has anyone tried newest kernel from jaunty-security (2.6.28-16.55) on armel?  It appears badly broken... gdm and X don't work, and logging in is impossible except as root.
[15:29] <dmart> A simple program which just uses setresgid and setresuid to become a normal user and then exec's a shell receives SIGKILL when the exec is attempted :O
[15:30] <dmart> The OOM killer did not run though
[15:31] <ogra> dmart, thats imx51 ?
[15:31] <dmart> Yes, babbage1
[15:31] <dmart> Am I doing something stupid... ?
[15:31] <ogra> bjf, amitk ^^^ ?
[15:31] <ogra> dmart, definately not, it should work
[15:32] <bjf> ogra, no idea, should just work
[15:32] <ogra> you didnt change the patchset or anything in jaunty, right ?
[15:33] <bjf> ogra, no change to the patchset, I think there may have been a rebase done
[15:33] <ogra> hrm
[15:33] <dmart> I think the only think I did was to upgrade the kernel via apt-get install linux-imx51
[15:33] <dmart> If a roll back to 2.6.28-15.52, that seems to work normally.
[15:33] <bjf> ogra, we aren't building that kernel for updates are we
[15:33] <dmart> Dunno, this was from jaunty-security
[15:34] <bjf> ogra, the only one I work on is the one in the jaunty topic branch
[15:34] <ogra> bjf, you mean jaunty->karmic ?
[15:34] <ogra> will likely not workj since the jaunty kernel didnt support B2.x and the karmic kernel doesnt support <B2.x
[15:35] <dmart> But 2.6.28 isn't the karmic kernel, right?
[15:35] <bjf> this is a jaunty update
[15:35] <bjf> dmart, no that's jaunty
[15:35] <ogra> bjf, so what did you mean with "<bjf> ogra, we aren't building that kernel for updates are we" ?
[15:35] <ogra> for sure security updates should work
[15:36] <ogra> release to release wont work because of the different patchsets
[15:36] <dmart> Sure; that I would expect
[15:36] <bjf> ogra, the only work I've done w.r.t. imx51 on jaunty is in the imx51 topic branch and that branch doesn't get built for updates (or any other reason that I'm aware of)
[15:36] <ogra> right
[15:36] <dmart> There's been a regular trickle of updates to the jaunty kernel through jaunty-security
[15:37] <ogra> i was just wondering if someone was insane enough to merge that one into the security update for whatever reason
[15:39] <dmart> Sounds like I should go ahead and raise a bug on this?
[15:39] <bjf> dmart, can I get you to file a bug on this issue?
[15:39] <dmart> Yeah, I can.
[15:39] <dmart> Thought I should check with you guys first though
[15:40] <bjf> dmart, thanks, what you are seeing should _not_ be happening
[15:41] <ogra> right
[15:41] <dmart> It's very weird...  the kernel mostly works, but with some very strange behaviours
[15:43] <bjf> dmart, if you stick with -15.52 you should be ok, we'll look at the bug and try to get it sorted out
[15:43] <bjf> dmart, post the bug number here and I'll assign it to myself
[15:44] <dmart> I can use the older kernel, no problem... but if something got merged in the jaunty imx51 kernel tree that shouldn't have been, I guess that needs sorting out.  I'll raise a bug.
[15:45]  * bjf-afk will be back in a few minutes
[15:53] <dmart> I've raised a bug and subscribed you guys— cheers.
[15:54] <ogra> thanks
[16:05] <bjf> dmart, got a bug number for that?
[16:06] <dmart> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/474322
[16:06] <ubot4> Launchpad bug 474322 in linux "linux-image-2.6.28-16-imx51 appears broken on armel" [Undecided,New]
[16:06] <bjf> tanks
[16:11] <armin76> looks like freescale is now selling an eval board of imx51