**** BEGIN LOGGING AT Wed Dec 02 02:59:57 2009 Dec 02 11:32:15 ogra, asac: I see https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-multiarch-execution-environment just got a work item: research possibility of integrating the build-arm-chroot script Dec 02 11:32:19 functionallity directly into debootstrap (2 days): TODO Dec 02 11:32:22 Isn't that what I just did? Dec 02 11:34:52 lool, well, sending that patch to colin, getting it approved upstream etc ... see the spec now, we postponed it Dec 02 11:35:18 Is it research or is it implementation then? Dec 02 11:35:24 if we keep binfmt as well as the build-arm-chroot script for now the world wont end Dec 02 11:35:40 well, actually both, i could have formulated it better Dec 02 11:36:01 This work item doesn't mention the static versus shared bit Dec 02 11:36:28 the work items are kind of void as we pushed it back for lucid Dec 02 11:36:29 lets just keep it as is... if one gets to create the code beyond a proof of concept it gets implemented ... i consider it nice to have Dec 02 11:36:36 if you want to fill stuff in in the spec go ahead Dec 02 11:36:50 s/it gets implemented/and it gets implemented/ Dec 02 11:36:56 I've put down my research; did you guys check it out? Dec 02 11:37:05 i read it, yes Dec 02 11:37:06 I was surprized not to hear back from any of you two Dec 02 11:37:08 ogra: right. thats what "Low" means. if someone gets to it fine. otherwise no problem Dec 02 11:37:27 s/put/written Dec 02 11:38:18 lool: will read it later today. needed to work full-time on spec stuff esterday ;) Dec 02 11:39:02 lool, if you feel like implementing what you found, feel free (i'm not really happy with the idea to fiddle with binfmt on the fly, but as long as it doesnt stop working i dont care) Dec 02 11:39:12 What would really rock is doing it with multiarch, but it's not clear it will happen this cycle Dec 02 11:39:21 right Dec 02 11:39:31 ogra: Well I'm not happy with relying on the host setup instead :-) Dec 02 11:39:35 until then i'm happy to keep it as is Dec 02 11:39:42 right, i know Dec 02 11:40:08 Frankly where the binfmt stuff happens is just a technical detail; I hate the requirement that the chroot pathname needs to match the host pathname though Dec 02 11:40:10 as i said, as long as the functionallity persists i dont really care, if you have spare cycles to implement it your way, feel free Dec 02 11:40:46 Moving binfmt to this script is the only thing I didn't research -- as noted -- I dont know whether it's container friendly Dec 02 11:41:47 It's probably though to do it in the chroot without a special helper: you can't run anything in the chroot without the wrapper and you need to setup the wrapper from withing the chroot for the container stuff to work :-/ Dec 02 11:41:50 i think the container stuff happens at another level ... i wouldnt see why it shouldnt work Dec 02 11:42:48 the kernels binfmt module just reacts on the magic number ... i dont think it cares if that happens in a container or not Dec 02 11:43:05 as long as the wrapper is found at least Dec 02 11:43:36 * suihkulokki has a way to execute arm binaries in a chroot using a dynamically linked qemu-arm without binfmt_misc Dec 02 11:43:54 suihkulokki: I can do that for a single binary as well, but not one that forks Dec 02 11:44:02 including forks Dec 02 11:44:11 suihkulokki: Oh scratchbox2? Dec 02 11:44:21 lool, anyway, if you find a way thats as easy as buiold-arm-chroot for the user, feel free to go ahead and implement it Dec 02 11:44:25 well, sb2 can do that too Dec 02 11:44:33 suihkulokki: Would love to hear your way then Dec 02 11:44:33 my way is just much more lightweight Dec 02 11:44:38 suihkulokki: I've documented what I tried in https://wiki.ubuntu.com/Specs/Mobile/QemuStaticExecutionEnv/Research Dec 02 11:44:51 what i dont want is that the user needs to type in a chain of commands and options to create a chroot Dec 02 11:45:09 ogra: That can always be reduced to a script :-) Dec 02 11:45:21 as i said, feel free :) Dec 02 11:45:39 ogra: My worries with the proposals I heard at UDS were: specific to Ubuntu, package proliferation Dec 02 11:45:43 i will only put time into it if i actually have a lazy day before FF ... Dec 02 11:45:47 which is unlikely Dec 02 11:45:48 I hope to show my way next weekend latest Dec 02 11:46:07 suihkulokki: Well you said too much now; mind sharing the high-level idea? Dec 02 11:46:21 suihkulokki: Did you patch qemu to spawn itself on forks? Dec 02 11:46:30 or exec rather Dec 02 11:48:32 basicly a LD_PRELOAD a library that executes qemu on exec if the binary to be executed is not host arch Dec 02 11:48:58 Ok; I thought of something similar by patching qemu's syscall emulation of the exec() syscall Dec 02 11:49:34 Your approach is probably more self-contained and might also allow calling into a host binary more easily Dec 02 11:49:42 Hmm not sure actually Dec 02 11:50:19 LD_PRELOAD has to be inherited by all childs; it fails with env -i and the new childs will look for the preload data in the chroot Dec 02 11:50:23 But still more self contained Dec 02 11:50:47 ld.so.preload maybe? Dec 02 11:50:50 and will fail for static binaries.. Dec 02 11:51:44 dpb, look, the ld_preload only affects qemu, not the binaries running inside qemu so it doesn't matter if the muck the env or are static Dec 02 11:52:58 s/look/lool/ Dec 02 11:54:14 suihkulokki: Oh so it's a ld_preload trick to change qemu's behavior for exec(); ok that's exactly what I thought of except I envisionned that in the qemu code itself Dec 02 11:54:42 That would work very well I think; good idea Dec 02 11:59:07 lool: yeah. if some hardcoding is acceptable it would be easy to do the same modifying qemu's exec Dec 02 12:00:12 suihkulokki: Is hardcoding really necessary? can't qemu-arm exec() into itself with enough info to proceed to the target binary? Dec 02 12:00:12 suihkulokki: ah, right. I'm tired. :) Dec 02 12:00:43 (I didn't look at the qemu syscall emulation itself at all, so feel free to call that impossible or very hard!) Dec 02 12:20:21 asac: glib > we want to get rid of swp uses for v7 in any case, a short term stop gap would be to change the build flags of glib to build in arm mode; that would at least avoid failing a gazillion of builds, images etc. Dec 02 12:21:08 lool: right. we dont want arm mode ... unles we cant find a patch quickly ;) Dec 02 12:21:34 Well I'm only suggesting that as a stopgap Dec 02 12:22:00 glib impacts a lot of packages Dec 02 12:22:01 Of course we want thumb2 Dec 02 12:22:09 lool, do you know swp will fail with -Wa,-mimplicit-it=thumb ? Dec 02 12:22:26 lool: right. i just hope we can have a patch really quick ;) Dec 02 12:22:29 (this afternoon) Dec 02 12:22:31 I think it's not available in t2 mode Dec 02 12:22:36 otherwise i agree we hsould upload with -marm Dec 02 12:22:37 hrm Dec 02 12:23:02 Which would seem logical since v7 introduced thumb2 AND new stuff to get rid of swp Dec 02 12:24:00 http://paste.ubuntu.com/333081/ Dec 02 12:24:03 thats the code Dec 02 12:26:25 SWP instruction Dec 02 12:26:31 is not supported in Thumb2 mode at all Dec 02 12:26:35 i know Dec 02 12:26:38 As confirmed from the Slide 5 notes in https://wiki.ubuntu.com/Mobile/ARMv7AndThumb Dec 02 12:26:38 ;) Dec 02 12:26:54 You were asking whether implicit-it=arm would help, it will not Dec 02 12:26:59 its also here: https://wiki.ubuntu.com/ARM/Thumb2 Dec 02 12:27:00 I just double checked Dec 02 12:27:05 lool: right. thats what i suspected Dec 02 12:27:09 or here https://wiki.ubuntu.com/Mobile/ARMv7AndThumb Dec 02 12:27:46 Well since ogra was about to fire a build with implicit-it=, I figured it was worth mentionning that it wouldn't help Dec 02 12:27:56 Anyway, /me hops to pressing stuff Dec 02 12:27:59 well, i'm still writing on a spec Dec 02 12:28:04 __sync_val_compare_and_swap Dec 02 12:28:11 i wouldnt have fired it off right away :) Dec 02 12:47:59 is there a good resource to track armel build failures? Dec 02 13:08:11 ubuntuwire Dec 02 13:08:18 http://qa.ubuntuwire.com/ftbfs/ Dec 02 13:28:56 th Dec 02 13:28:58 x Dec 02 16:40:24 that's the failing qt4-x11 code http://paste.ubuntu.com/333247/ Dec 02 16:40:30 The #else Dec 02 16:41:07 ../../corelib/io/qfsfileengine_unix.cpp:1309: error: unrecognizable insn: Dec 02 16:41:07 (insn 636 635 218 23 ../../corelib/io/qfsfileengine_unix.cpp:1286 (set (reg:SI 9 r9 [+4 ]) Dec 02 16:41:26 set reg sounds like assembler to me, surely not like C++ Dec 02 17:29:35 Hm, what's the reason for using softfp? I thought all supported platforms today had proper implementations? Dec 02 17:29:52 oh, nevermind. that's just the abi Dec 02 17:35:42 asac, do you need -Wa,-mimplicit-it=thumb or is -mthumb good enough? Dec 02 17:43:09 fta, https://wiki.ubuntu.com/ARM/Thumb2 Dec 02 17:43:28 i dont think -mthumb is enough Dec 02 17:44:11 i get /tmp/ccRUIN1V.s:131: Error: thumb conditional instruction should be in IT block -- `moveq ip,#8' Dec 02 17:44:44 but as it happens after 19h+ of build, i prefer to ask ;) Dec 02 17:45:21 i should probably setup a crosscompile env Dec 02 17:48:36 no, that gets painful Dec 02 17:48:52 since you need to cross build all the deps first Dec 02 17:49:39 crossbuilding is fine for packages with only a few deps ... i wouldnt build something with lots of deps in a cross way Dec 02 18:27:35 ogra, upstream provides this recipe: http://code.google.com/p/chromium/wiki/LinuxChromiumArm Dec 02 18:27:51 looks possible but could be easier :P Dec 02 18:31:13 well, as long as you are sure the cross toolchain they provide uses the same options, that might work Dec 02 18:32:53 ogra: our cross toolchain is not sysrooted Dec 02 18:34:07 zumbi, well, does it default to the options documented on https://wiki.ubuntu.com/ARM/Thumb2 ? Dec 02 18:34:48 ogra, no, i do not think so Dec 02 18:34:56 right, thats what i suspected Dec 02 18:35:35 so it doesnt help much unless you hack around it in debian/rules since fta wants to fix build errors happening on the buildds Dec 02 18:36:34 btw, which cross tool do you use? lool PPA? Dec 02 18:36:39 none Dec 02 18:36:55 * ogra is highly anti cross :) i build on real HW Dec 02 18:37:23 ogra: do you native build kernels for new bootstraps? Dec 02 18:37:33 for small packages i use the ubuntu qemu-arm-static package Dec 02 18:38:09 oh, for test kernels i sometimes use codesourcery ... Dec 02 18:38:12 yes, qemu is nice and helpful, also cross building Dec 02 18:38:21 but most of the time i simply use my dove board :) Dec 02 18:39:02 which is fine and if you have the time and the power, it is best practice :-) Dec 02 18:39:21 but cross building does only cut down buildtime in half or so ... and i usually dont touch kernels Dec 02 18:39:50 ogra: you can not native build a uclibc based device (no space) Dec 02 18:40:05 we dont use uclibc in our ubuntu images Dec 02 18:40:24 all devices we support have at least 800MHz and 512MB Dec 02 18:40:33 and usually a SATA port Dec 02 18:40:47 ricer board Dec 02 18:40:51 yes, in those cases, cross building is not needed Dec 02 18:41:08 but, i can not native build on my lynksys Dec 02 18:41:12 armin76, still envious, eh ? Dec 02 18:41:32 zumbi, well, i did native builds on my nslu2 ... but i agree its no fun Dec 02 18:41:59 armin76, just wait for the next gen sheeva plug :) Dec 02 18:42:08 boo Dec 02 18:42:19 ogra: why do i have to wait?! Dec 02 18:42:20 it will be dove based Dec 02 18:42:37 at least thats what roumours said :) Dec 02 18:42:56 armin76: still you have not got an armv7? Dec 02 18:43:07 zumbi: nope Dec 02 18:43:14 zumbi: ogra doesn't wanna share *g* Dec 02 18:43:33 armin76: get a beagleboard :) Dec 02 18:44:49 or if you are rich, get a babbage board Dec 02 18:45:05 ogra: cross building is needed when you have to maintain a distro which runs on 4MB devices up to several GB Dec 02 18:45:12 indeed Dec 02 18:45:29 luckily ubuntu went beyond that :) Dec 02 18:45:40 also uclibc would enter in thecocktail Dec 02 18:45:53 zumbi: or compiling qt and not waste several days on it :P Dec 02 18:46:11 qt-embedded ? Dec 02 18:46:37 ogra: i could get your babbage *g* Dec 02 18:46:50 Stskeeps, https://launchpad.net/ubuntu/+source/qt4-x11/4.5.3really4.5.2-0ubuntu1/+build/1292073 22h :) not even a day Dec 02 18:48:18 armin76, sure, i could sell it to you :) it being used i would even go down with the price by $50 ... so it would only be $700 :P Dec 02 18:48:58 afaik freescale sells them now Dec 02 18:52:40 genesi are shipping their pegatron smarttop rebranded device too (with u-boot as firmware) Dec 02 18:53:00 right, but you could only use ubuntu userspace with it Dec 02 18:53:07 there is no pegatron kernel Dec 02 18:53:27 and its stuck on 2.6.28 ... Dec 02 18:53:45 yeah i know. nice gpl compliance there. Dec 02 18:53:50 heh Dec 02 18:54:22 lucid will use uboot on the babbage too ... Dec 02 18:56:03 * ogra calls it a day Dec 02 18:56:38 yikes, 800 bucks from arrow Dec 02 18:56:43 * zumbi wonders if any of you know mpc8548 ppc processors Dec 02 18:57:31 zumbi: plenty of people on #mklinux do Dec 02 19:00:10 ojn: yes, i just went there Dec 02 21:14:28 ogra, i'm confused by the "-Wa,-mimplicit-it=thumb is not implemented as of gcc-4.4 4.4.2-3ubuntu1".. does it mean that passing it is useless as won't work, or that it's just not yet the default? Dec 02 21:14:42 +it **** BEGIN LOGGING AT Thu Dec 03 04:00:15 2009 Dec 03 04:23:44 * zooko reads https://wiki.ubuntu.com/Mobile/ARMv7AndThumb Dec 03 04:30:20 Is it publicly known who are the hardware makers working with Canonical on ARM devices? Dec 03 04:35:50 Marvell and Freescale make the boards that are officially supported, if that's what you mean? Dec 03 04:36:46 I meant the story that Canonical is working with makers of netbooks./ Dec 03 04:36:57 I suppose which makers is secret. Dec 03 04:37:08 Or maybe I'm supposed to call them smartbooks if they are ARM based. Dec 03 04:37:17 By the way, I'm also really interested in ARM-based servers. Hard to find. Dec 03 04:37:25 Oh. Yeah, I don't think they've talked publically about that Dec 03 04:37:47 http://perspectives.mvdirona.com/2009/11/30/2010TheYearOfMicroSliceServers.aspx Dec 03 04:38:06 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 Dec 03 10:12:51 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) Dec 03 10:45:52 ogra, ok, thanks. that sentence is just confusing then. Dec 03 10:47:12 its a wiki, feel free to fix ;) Dec 03 11:22:06 dmart, you rock ! Dec 03 11:22:14 * ogra does a testbuild of glib Dec 03 11:22:51 -er- not yet, I've just been looking at the compiler output... __sync_synchronize() compiles away to nothing :( Dec 03 11:24:42 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. Dec 03 11:25:13 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. Dec 03 12:33:01 dmart, hmm, i have some prob with your patch ... Dec 03 12:33:30 it succeeded with offset, i triggered a build but failed ... looking closer i see that: Dec 03 12:33:38 patching file glib/gatomic.c Dec 03 12:33:38 patching file configure.in Dec 03 12:33:38 Hunk #1 succeeded at 2491 (offset 11 lines). Dec 03 12:33:44 root@babbage2:/glib2.0-2.23.0# wc -l glib/gatomic.c Dec 03 12:33:44 1089 glib/gatomic.c Dec 03 12:34:03 did you patch the actual latest lucid upload ? Dec 03 12:34:06 or a former source Dec 03 12:35:53 It was against 2.22.2. Do source packages not appear in the archive until a successful binary build has been uploaded? Dec 03 12:36:26 they do, did you apt-get update before apt-get source ? Dec 03 12:36:34 2.23.0 here Dec 03 12:36:49 Hmmm, possibly not. I'll try again Dec 03 12:37:42 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)? Dec 03 12:38:02 both is fine Dec 03 12:38:04 OK, now 2.23.0-1ubuntu1 Dec 03 12:38:38 Is the build log for your failure visible on launchpad? Dec 03 12:38:42 do as you like it most, someone needs to touch the package anyway for sponsoring the upload Dec 03 12:39:25 OK... I'll attach a new patch to the bug when I've sorted it out. Dec 03 12:39:33 (its indeed less work if the patch is on top of the stack but doesnt make a big difference) Dec 03 12:41:44 ogra: whats the prob? Dec 03 12:42:00 configure.in problem? Dec 03 12:42:17 asac, the build fails with the same error due to the patch being for the karmic version Dec 03 12:42:30 well. Dec 03 12:42:35 but that cant be a big problem Dec 03 12:42:40 its just confiugre.in, right? Dec 03 12:42:45 yes Dec 03 12:43:31 ogra: it applies ... sure you ran autoconf? Dec 03 12:43:55 doesnt debian/rules do that ? Dec 03 12:44:37 hmm, seems not Dec 03 12:44:52 no Dec 03 12:44:56 gnome packages dont do that Dec 03 12:44:59 you have to do a patch Dec 03 12:45:28 i thought they usually use some autoreconf.mk thingie Dec 03 12:45:38 No Dec 03 12:45:38 no Dec 03 12:45:41 ok Dec 03 12:45:43 thats dirty anyway Dec 03 12:46:03 i know but i thought i saw that before in gnome packages Dec 03 12:46:06 ogra: just remove the if stuff etc al Dec 03 12:46:19 ogra: those are not real gnome packages then ;) Dec 03 12:46:26 anyway Dec 03 12:47:51 http://people.canonical.com/~asac/tmp/70_glib2.0-gatomic-arm.patch Dec 03 12:47:52 ogra: Dec 03 12:47:54 use that Dec 03 12:47:58 and ignore the confiugre stuff Dec 03 12:48:04 oki Dec 03 12:48:35 has a hacked "define ..." obviously not for upstream, but beter than doing the full configure thing in package Dec 03 12:48:47 yeah Dec 03 12:49:51 dmart: so no need to update it to lucid version from what i see. should be ok as it is for now ;) Dec 03 12:51:06 ^ 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 Dec 03 12:52:04 Do you need an extra patch from me? Dec 03 12:52:24 ogra, asac, do you need an extra patch, or are you OK for now? Dec 03 12:52:37 no all fine. thanks a lot Dec 03 12:52:57 once we know we let you know ;) Dec 03 12:53:27 got past gatomic.c/o Dec 03 12:53:32 very good ;) Dec 03 12:53:34 so seems all fine Dec 03 12:53:42 i'll let it finish Dec 03 12:53:44 Is it usual to upstream things like this, and what would the timescale be? Dec 03 12:54:00 heh, depends on the upstream i guess Dec 03 12:54:01 dmart: real quick if there are no questions etc. Dec 03 12:54:07 (for glib) Dec 03 12:54:12 Yeah, of course Dec 03 12:54:14 yeah, glib should be fast Dec 03 12:55:08 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. Dec 03 12:56:31 right, our main focus atm is to get all packages building for alpha1 Dec 03 12:56:47 agreed Dec 03 12:57:43 if we have packages with temp workarounds we need to touch later again, we should collect them somewhere though Dec 03 12:57:44 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. Dec 03 12:58:06 orga, is the ARM/Thumb2 page the right place for that? Dec 03 12:59:23 yeah, probably a package section at the bottom would make sense Dec 03 13:26:53 we should keep a bug open so we remember to rebuild glib etc. after the intrinsics are fixed Dec 03 13:26:57 dmart: ogra: ^ Dec 03 13:27:47 asac, ogra: I'm raising a bug on GCC to track this; we can reference it from the existing glib2.0 bug? Dec 03 13:28:09 dmart: unfortuantely we can only dupe stuff (which isnt right here) Dec 03 13:28:17 dmart: i would suggest to add a new bug to GCC Dec 03 13:28:24 and then add the packages we identified as targets Dec 03 13:28:43 so after filing the gcc bug, click on "also affects distributioN" ... and select glib2.0 there for now Dec 03 13:29:11 then drop a comment that glib is affected blah blah blah and reference the other bug in the comment for background info Dec 03 13:33:55 ogra, asac: Raised: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491872 Dec 03 13:33:59 Launchpad bug 491872 in glib2.0 "[armel] Atomic intrinsics are not implemented correctly" [Undecided,New] Dec 03 13:35:04 I've added a note to https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491342 Dec 03 13:35:12 Launchpad bug 491342 in glib2.0 "assembly fails to build on armel/lucid " [Critical,Triaged] Dec 03 15:18:13 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? Dec 03 15:18:34 (main use for me would be to use it for distcc:ing across to a faster machine) Dec 03 16:31:42 asac, did you retry chromium? Dec 03 16:54:35 asac: whats the status on chromium? did it build? Dec 03 16:58:43 it should, but i don't have access to any arm builder Dec 03 17:14:49 copying now Dec 03 17:15:12 just lucid though Dec 03 17:15:46 copyied Dec 03 18:33:36 asac, sure, no need to even try karmic unless i enforce armv7 Dec 03 18:34:34 (karmic is v6 and no thumb) Dec 03 18:35:54 ogra, yep, what i meant is upstream only supports v7, at least until someone ports it to something else Dec 03 18:36:09 ah, well ... Dec 03 18:36:20 thumb doesn't seem to be required though Dec 03 18:36:36 i think we'Re the only distro building with thumb2 atm Dec 03 18:36:57 not even angstrom (beagleboard default distro and highly optimized) does use thumb Dec 03 18:38:34 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 Dec 03 18:39:18 roumors say up to 30% size reduction and up to 30% speedup is possible through thumb2 Dec 03 18:40:49 fta: the problem for non-armv7 was broken assembly? Dec 03 20:30:30 maemo used to have thumb1 support, not sure whether they are using thum2 now Dec 03 20:54:08 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 Dec 03 22:01:54 asac, when built for android, v8 build system adds a bunch of flags, incl -march=armv5te & -mthumb-interwork **** ENDING LOGGING AT Fri Dec 04 02:59:57 2009