| * cwillu_at_work pokes at rcn-ee | 00:23 | |
| rcn-ee | how's it going cwillu_at_work | 00:24 |
|---|---|---|
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| * cwillu_at_work nearly resists the urge to say "meh, I get paid by the hour" :p | 00:31 | |
| 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:33 |
| 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:36 |
| 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:37 |
| rcn-ee | take on the top500? ;) not sure, but he's doing it.. | 00:38 |
| 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:39 |
| 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:41 |
| 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:42 | |
| 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:43 |
| ojn | might be fixed in the new ones, not sure. | 00:44 |
| 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 | 00:47 |
| === asac_ is now known as asac | ||
| === bjf is now known as bjf-afk | ||
| * zooko reads https://wiki.ubuntu.com/Mobile/ARMv7AndThumb | 04:23 | |
| zooko | Is it publicly known who are the hardware makers working with Canonical on ARM devices? | 04:30 |
| ojn | Marvell and Freescale make the boards that are officially supported, if that's what you mean? | 04:35 |
| zooko | I meant the story that Canonical is working with makers of netbooks./ | 04:36 |
| zooko | I suppose which makers is secret. | 04:36 |
| 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:37 |
| 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 | 04:38 |
| 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:12 |
| fta | ogra, ok, thanks. that sentence is just confusing then. | 10:45 |
| ogra | its a wiki, feel free to fix ;) | 10:47 |
| 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:22 |
| 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:24 |
| 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. | 11:25 |
| 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:33 |
| ogra | did you patch the actual latest lucid upload ? | 12:34 |
| ogra | or a former source | 12:34 |
| dmart | It was against 2.22.2. Do source packages not appear in the archive until a successful binary build has been uploaded? | 12:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| asac | ogra: whats the prob? | 12:41 |
| 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:42 |
| asac | ogra: it applies ... sure you ran autoconf? | 12:43 |
| ogra | doesnt debian/rules do that ? | 12:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| asac | dmart: so no need to update it to lucid version from what i see. should be ok as it is for now ;) | 12:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| ogra | right, our main focus atm is to get all packages building for alpha1 | 12:56 |
| dmart | agreed | 12:56 |
| 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:57 |
| dmart | orga, is the ARM/Thumb2 page the right place for that? | 12:58 |
| ogra | yeah, probably a package section at the bottom would make sense | 12:59 |
| 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:26 |
| dmart | asac, ogra: I'm raising a bug on GCC to track this; we can reference it from the existing glib2.0 bug? | 13:27 |
| 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:28 |
| asac | then drop a comment that glib is affected blah blah blah and reference the other bug in the comment for background info | 13:29 |
| 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:33 |
| 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] | 13:35 |
| 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) | 15:18 |
| === bjf-afk is now known as bjf | ||
| fta2 | asac, did you retry chromium? | 16:31 |
| armin76 | asac: whats the status on chromium? did it build? | 16:54 |
| fta2 | it should, but i don't have access to any arm builder | 16:58 |
| asac | copying now | 17:14 |
| asac | just lucid though | 17:15 |
| asac | copyied | 17:15 |
| fta | asac, sure, no need to even try karmic unless i enforce armv7 | 18:33 |
| ogra | (karmic is v6 and no thumb) | 18:34 |
| fta | ogra, yep, what i meant is upstream only supports v7, at least until someone ports it to something else | 18:35 |
| 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:36 |
| 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:38 |
| ogra | roumors say up to 30% size reduction and up to 30% speedup is possible through thumb2 | 18:39 |
| asac | fta: the problem for non-armv7 was broken assembly? | 18:40 |
| lool | maemo used to have thumb1 support, not sure whether they are using thum2 now | 20:30 |
| === Q_Continuum_ is now known as Q_Continuum | ||
| 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 | 20:54 |
| fta | asac, when built for android, v8 build system adds a bunch of flags, incl -march=armv5te & -mthumb-interwork | 22:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!