[00:23]  * cwillu_at_work pokes at rcn-ee 
[00:24] <rcn-ee> how's it going cwillu_at_work
[00:25] <cwillu_at_work> building my debs in qemu as we speak becuase _somebody_ didn't build it for me :p
[00:25] <ojn> qemu? painful.
[00:25] <rcn-ee> well that's the proper way, no cross compiling allowed! ;)
[00:26] <cwillu_at_work> what's the slow down in comparison to doing it native?
[00:26] <cwillu_at_work> I was figuring that 2gb of ram + quad cores at 2.6ghz is faster at playing arm than an arm is
[00:26] <ojn> pretty bad last time I compared (native freescale vs qemu on nehalem). Don't remember exactly how many times slower qemu was though.
[00:27] <rcn-ee> man it's been a long time, but i think it took like 6 hours on my old x2 4200 to build 2.6.27 where the beagle did it in like 3... haven't used qemu since.. ;)
[00:27] <cwillu_at_work> maybe I'll race them next time
[00:27] <ojn> been toying some with scratchbox2 here. it's not entirely pain free either (especially when you realize you need another package installed), but performance is reasonable
[00:28] <rcn-ee> cwillu_at_work, qemu is also not very good with multicores, so maybe two-three qemu sessions with distcc to share the compile.. ;)
[00:31]  * cwillu_at_work nearly resists the urge to say "meh, I get paid by the hour" :p
[00:33] <ojn> if you're going to distcc then you might as well distcc out to a native cross compiler
[00:33] <ojn> that'd be better/faster/easier
[00:33] <cwillu_at_work> that actually sounds sane
[00:36] <ojn> what would be nice is if there was a shipped version of the cross toolchain for x86{,_64} that was built from the same sources as the native arm toolchain, just to be bug compatible with native builds.
[00:37] <ojn> any plans on providing that, canonicalites?
[00:37] <rcn-ee> i just want to get a setup like a guy on the beagleboard group email is building, a 13U server with 44+ beagles...
[00:37] <ojn> rcn-ee: why would anyone want that?
[00:38] <rcn-ee> take on the top500? ;)  not sure, but he's doing it..
[00:39] <rcn-ee> Eric Fung here: http://groups.google.com/group/beagleboard/browse_thread/thread/f5f14f4ec66ab45d/df03479bf1ca0861?lnk=gst&q=44#df03479bf1ca0861
[00:39] <ojn> Haha. the beagles aren't exactly fast. sounds like a good way to burn 5000 dollars to me.
[00:41] <rcn-ee> since they are backordered he will be getting the new 720Mhz ones..  But otherwise it's hard to find cheap cortex-a8 boards...
[00:41] <ojn> oh, he uses them for industrial automation? still, sounds odd not to do something more monolithic.
[00:41] <cwillu_at_work> rcn-ee, is that why we can't buy beagleboards these days? :p
[00:41] <ojn> rcn-ee: I prefer my cortex a8's to be able to cache clean data in l2. 3430/3530 can't. pretty amazing actually.
[00:42] <rcn-ee> the dvi/video chip is very hard to get right now.. So the boards can't be finished for sale...
[00:42]  * ojn heads to dinner.
[00:43] <rcn-ee> ojn, yeah, the cortex-a8 in the beagle has a couple bad bugs, my chroot is puking on every lucid update right now... :(
[00:43] <ojn> rcn-ee: it's got the thumb2 bug but the ubuntu toolchain should have the workaround for it. i don't know if it's enabled though?
[00:43] <ojn> s/the thumb2 bug/the thumb2 branch bug/
[00:44] <ojn> might be fixed in the new ones, not sure.
[00:47] <rcn-ee> yeah, i think it's that one.. although my quick gcc compare didn't show too much damage.. thumb: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02447.html and nonthumb: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02538.html
=== asac_ is now known as asac
=== bjf is now known as bjf-afk
[04:23]  * zooko reads https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
[04:30] <zooko> Is it publicly known who are the hardware makers working with Canonical on ARM devices?
[04:35] <ojn> Marvell and Freescale make the boards that are officially supported, if that's what you mean?
[04:36] <zooko> I meant the story that Canonical is working with makers of netbooks./
[04:36] <zooko> I suppose which makers is secret.
[04:37] <zooko> Or maybe I'm supposed to call them smartbooks if they are ARM based.
[04:37] <zooko> By the way, I'm also really interested in ARM-based servers.  Hard to find.
[04:37] <ojn> Oh. Yeah, I don't think they've talked publically about that
[04:37] <zooko> http://perspectives.mvdirona.com/2009/11/30/2010TheYearOfMicroSliceServers.aspx
[04:38] <ojn> there aren't many arm based servers, no. smooth-stone are supposedly working on something but I'd expect silicon product to be years away from mass production
[10:12] <ogra> fta, it means that the default is supposed to change, but that gcc version doesnt have the change yet (it's supposed to happen with the next upload of gcc)
[10:45] <fta> ogra, ok, thanks. that sentence is just confusing then.
[10:47] <ogra> its a wiki, feel free to fix ;)
[11:22] <ogra> dmart, you rock !
[11:22]  * ogra does a testbuild of glib
[11:22] <dmart> -er- not yet, I've just been looking at the compiler output... __sync_synchronize() compiles away to nothing :(
[11:24] <dmart> We're looking into this, but I might suggest using a slightly different patch using __sync_lock_test_and_set() and __sync_lock_release().  This will be cleaner example for people to copy, and avoids the explicit __sync_synchronize() call.
[11:25] <dmart> Shall I just supply another patch on top of the old one?  The code will build as-is and work on Cortex-A8, so we have no immediate problem.
[12:33] <ogra> dmart, hmm, i have some prob with your patch ...
[12:33] <ogra> it succeeded with offset, i triggered a build but failed ... looking closer i see that:
[12:33] <ogra> patching file glib/gatomic.c
[12:33] <ogra> patching file configure.in
[12:33] <ogra> Hunk #1 succeeded at 2491 (offset 11 lines).
[12:33] <ogra> root@babbage2:/glib2.0-2.23.0# wc -l  glib/gatomic.c
[12:33] <ogra> 1089 glib/gatomic.c
[12:34] <ogra> did you patch the actual latest lucid upload ?
[12:34] <ogra> or a former source
[12:35] <dmart> It was against 2.22.2.  Do source packages not appear in the archive until a successful binary build has been uploaded?
[12:36] <ogra> they do, did you apt-get update before apt-get source  ?
[12:36] <ogra> 2.23.0 here
[12:36] <dmart> Hmmm, possibly not.  I'll try again
[12:37] <dmart> Is it more conveinent to provide a patch which applies on top of the patch stack in debian/patches, or against the original files (which is what I gave you before)?
[12:38] <ogra> both is fine
[12:38] <dmart> OK, now 2.23.0-1ubuntu1
[12:38] <dmart> Is the build log for your failure visible on launchpad?
[12:38] <ogra> do as you like it most, someone needs to touch the package anyway for sponsoring the upload
[12:39] <dmart> OK... I'll attach a new patch to the bug when I've sorted it out.
[12:39] <ogra> (its indeed less work if the patch is on top of the stack but doesnt make a big difference)
[12:41] <asac> ogra: whats the prob?
[12:42] <asac> configure.in problem?
[12:42] <ogra> asac, the build fails with the same error due to the patch being for the karmic version
[12:42] <asac> well.
[12:42] <asac> but that cant be a big problem
[12:42] <asac> its just confiugre.in, right?
[12:42] <ogra> yes
[12:43] <asac> ogra: it applies ... sure you ran autoconf?
[12:43] <ogra> doesnt debian/rules do that ?
[12:44] <ogra> hmm, seems not
[12:44] <asac> no
[12:44] <asac> gnome packages dont do that
[12:44] <asac> you have to do a patch
[12:45] <ogra> i thought they usually use some autoreconf.mk thingie
[12:45] <lool> No
[12:45] <asac> no
[12:45] <ogra> ok
[12:45] <asac> thats dirty anyway
[12:46] <ogra> i know but i thought i saw that before in gnome packages
[12:46] <asac> ogra: just remove the if stuff etc al
[12:46] <asac> ogra: those are not real gnome packages then ;)
[12:46] <asac> anyway
[12:47] <asac> http://people.canonical.com/~asac/tmp/70_glib2.0-gatomic-arm.patch
[12:47] <asac> ogra:
[12:47] <asac> use that
[12:47] <asac> and ignore the confiugre stuff
[12:48] <ogra> oki
[12:48] <asac> has a hacked "define ..." obviously not for upstream, but beter than doing the full configure thing in package
[12:48] <ogra> yeah
[12:49] <asac> dmart: so no need to update it to lucid version from what i see. should be ok as it is for now ;)
[12:51] <dmart> ^ I had to rerun autoconf, but I didn't publish a patch for configure itself, because it came out half a MB smaller than before, which I found a bit scary
[12:52] <dmart> Do you need an extra patch from me?
[12:52] <dmart> ogra, asac, do you need an extra patch, or are you OK for now?
[12:52] <asac> no all fine. thanks a lot
[12:52] <asac> once we know we let you know ;)
[12:53] <ogra> got past gatomic.c/o
[12:53] <asac> very good ;)
[12:53] <ogra> so seems all fine
[12:53] <ogra> i'll let it finish
[12:53] <dmart> Is it usual to upstream things like this, and what would the timescale be?
[12:54] <ogra> heh, depends on the upstream i guess
[12:54] <asac> dmart: real quick if there are no questions etc.
[12:54] <asac> (for glib)
[12:54] <dmart> Yeah, of course
[12:54] <ogra> yeah, glib should be fast
[12:55] <dmart> Note that we need to patch gcc to work round an issue with the implementation of the atomics; then glib2.0 should be rebuilt.  But the problems will only emerge on multi-core, so this isn't so urgent.
[12:56] <ogra> right, our main focus atm is to get all packages building for alpha1
[12:56] <dmart> agreed
[12:57] <ogra> if we have packages with temp workarounds we need to touch later again, we should collect them somewhere though
[12:57] <dmart> I'll upload another patch to tidy up the implementation a bit more in gatomic.  Since this will serve as an example for other packages, I'd like to get this one as clear as possible.
[12:58] <dmart> orga, is the ARM/Thumb2 page the right place for that?
[12:59] <ogra> yeah, probably a package section at the bottom would make sense
[13:26] <asac> we should keep a bug open so we remember to rebuild glib etc. after the intrinsics are fixed
[13:26] <asac> dmart: ogra: ^
[13:27] <dmart> asac, ogra: I'm raising a bug on GCC to track this; we can reference it from the existing glib2.0 bug?
[13:28] <asac> dmart: unfortuantely we can only dupe stuff (which isnt right here)
[13:28] <asac> dmart: i would suggest to add a new bug to GCC
[13:28] <asac> and then add the packages we identified as targets
[13:28] <asac> so after filing the gcc bug, click on "also affects distributioN" ... and select glib2.0 there for now
[13:29] <asac> then drop a comment that glib is affected blah blah blah and reference the other bug in the comment for background info
[13:33] <dmart> ogra, asac: Raised: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491872
[13:33] <ubot4> Launchpad bug 491872 in glib2.0 "[armel] Atomic intrinsics are not implemented correctly" [Undecided,New]
[13:35] <dmart> I've added a note to https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491342
[13:35] <ubot4> Launchpad bug 491342 in glib2.0 "assembly fails to build on armel/lucid " [Critical,Triaged]
[15:18] <ojn> ogra: did you see my question from last night? I.e. are there any plans on providing an x86-hosted arm crosstoolchain built with the same options/from the same sources as a deb?
[15:18] <ojn> (main use for me would be to use it for distcc:ing across to a faster machine)
=== bjf-afk is now known as bjf
[16:31] <fta2> asac, did you retry chromium?
[16:54] <armin76> asac: whats the status on chromium? did it build?
[16:58] <fta2> it should, but i don't have access to any arm builder
[17:14] <asac> copying now
[17:15] <asac> just lucid though
[17:15] <asac> copyied
[18:33] <fta> asac, sure, no need to even try karmic unless i enforce armv7
[18:34] <ogra> (karmic is v6 and no thumb)
[18:35] <fta> ogra, yep, what i meant is upstream only supports v7, at least until someone ports it to something else
[18:36] <ogra> ah, well ...
[18:36] <fta> thumb doesn't seem to be required though
[18:36] <ogra> i think we'Re the only distro building with thumb2 atm
[18:36] <ogra> not even angstrom (beagleboard default distro and highly optimized) does use thumb
[18:38] <ogra> given that ubuntu runs on beagle with an externally maintained kernel it will be very intresting if lucid runs faster than angstrom on the beagle
[18:39] <ogra> roumors say up to 30% size reduction and up to 30% speedup is possible through thumb2
[18:40] <asac> fta: the problem for non-armv7 was broken assembly?
[20:30] <lool> maemo used to have thumb1 support, not sure whether they are using thum2 now
=== Q_Continuum_ is now known as Q_Continuum
[20:54] <fta> asac, apparently, it's supposed to work even on armv5. but as they don't have an arm buildbot yet, it probably diverged a bit and needs fixes
[22:01] <fta> asac, when built for android, v8 build system adds a bunch of flags, incl -march=armv5te & -mthumb-interwork