#ubuntu-arm 2009-12-01 <neel_> hi i need some help with a OMAP3 board <neel_> hi i need some help with a OMAP3 board <amitk> neel_: what help? <neel_> oh hi <neel_> sorry you still there amitk? <lool> ogra, asac: I'm writing an email summarizing my research and thoughts on the UDS session we had on debootstrap/qemu-arm; I was writing this as an email to you two, should I send it to some ML instead? <lool> I'm not sure ubuntu-mobile@ is good for this, and people might lack context, but I would also like this to be archived so that I can point to it during discussions <lool> ogra_: 15:00 < lool> ogra, asac: I'm writing an email summarizing my research and thoughts on the UDS session we had on debootstrap/qemu-arm; I was writing this as an email to you two, should I send it to some ML instead? <lool> 15:00 < lool> I'm not sure ubuntu-mobile@ is good for this, and people might lack context, but I would also like this to be archived so that I can point to it during discussions <ogra_> hmm, i was planning to put a TODO item for that into the spec <ogra_> probably just add it to the wikipage ? <lool> Ok <GrueMaster> asac: wrt mobile-lucid-arm-lib-tests, the issues I'm running into are mainly poor/out of date documentation and the way the system is designed. Each test build requires the LSB build environment, which is a set of library stubs. This is generated partially from a database of functions. I just got the mysql database up and running (poor documentation) on my desktop, need to get my dove to connect to it. <GrueMaster> After I get database connectivity, I need to figure out how to populate the database with info on arm. Right now it has none. Once I get that, there is a script in the build_env source tree to generate new code for arm. <asac> GrueMaster: right. <asac> sounds like a plan <asac> remember to document what you do to setup etc. <GrueMaster> Heh, yea. <asac> in that way if you get blocked we can have someone else helping you ;) <asac> without much communication <asac> this is an important spec for us ... <GrueMaster> I already have an email in to the linux foundation and key developers of LSB. I hope to hear from them this week. <asac> GrueMaster: maybe add progress and things we are waiting for to the whiteboard too <asac> thanks <GrueMaster> I could, but it is mostly trial and error at this point. <asac> GrueMaster: right. what i meant was: asked XXX for clarification; waiting for reply ... <asac> so we know that we are waiting for something <asac> but do it like you prefer <asac> ;) <GrueMaster> Part of the problem is that while I can get a daily snapshot of their database, they are using an old version of mysql. <asac> we will review this spec at least weekly ;) <GrueMaster> I'd rather not say I'm waiting for them. <GrueMaster> I prefer to continue hacking at this while waiting for them. That way I'm still making some progress. <asac> GrueMaster: have you found/documented the source trees by now? <GrueMaster> Yes, I think I have. let me check. <GrueMaster> The only link I don't have is for the ABI tests, and any other tests we may add/replace. <asac> lool: the idea was to document your qemu approach somewhere ... either mailing list or even in the spec <asac> GrueMaster: add what you have for now. and maybe split those things in separate work items ;) <GrueMaster> But the ABI test is a simple script that compares the old libs with the new ones. <GrueMaster> Ok. <asac> so we can document that there is progress ;) <asac> thanks <asac> ok have to do lunch and stuff <asac> will be back in 1h or so <ogra> lunch is a good idea ! <GrueMaster> I have a dental appoinment in 2.5 hours. <lool> asac: Yeah that's why I was wondering where <lool> asac: But I didn't think of the wiki and will copy that to the wiki now that I finished typing it #ubuntu-arm 2009-12-02 <jerone-mobile> https://bugs.launchpad.net/bugs/487979 <ubot4> jerone-mobile: Error: This bug is private <jerone-mobile> ubot4, wrong channel <ubot4> Factoid 'wrong channel' not found <jerone-mobile> ubot4, sorry about that <ubot4> jerone-mobile: Error: I am only a bot, please don't think I'm intelligent :) <Ramiz> hello <Ramiz> any one know ETM 3.2? <Ramiz> any one know ETM 3.2? <Ramiz> hi <Ramiz> hi <Ramiz> any one know ETM 3.2? <Ramiz> any one know ETM 3.2? <Ramiz> any one know ETM 3.2? <ojn> Ramiz: Repeating your question over and over will not give you a quicker answer <Ramiz> no i am so sorry <Ramiz> i repeted cuz i did not sure if it sent or not cuz i am not login <Ramiz> sorry <Ramiz> i am wating <ojn> ah. What's ETM anyway? <Ramiz> Embedded Trace Macrocell <ojn> ok, figured it was but was but wanted to make sure. I'm guessing most people here aren't working with tools that low level <ojn> you might be better off asking in a group related to the specific SoC you're trying to debug <Ramiz> where i can find this on irc u think? <ojn> depends. what chip are you working on? <Ramiz> it is arm11 cutome one <Ramiz> it is like omap <ojn> custom? so your own soc? <Ramiz> it is not mine <lool> 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 <lool> functionallity directly into debootstrap (2 days): TODO <lool> Isn't that what I just did? <ogra> lool, well, sending that patch to colin, getting it approved upstream etc ... see the spec now, we postponed it <lool> Is it research or is it implementation then? <ogra> if we keep binfmt as well as the build-arm-chroot script for now the world wont end <ogra> well, actually both, i could have formulated it better <lool> This work item doesn't mention the static versus shared bit <asac> the work items are kind of void as we pushed it back for lucid <ogra> 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 <asac> if you want to fill stuff in in the spec go ahead <ogra> s/it gets implemented/and it gets implemented/ <lool> I've put down my research; did you guys check it out? <lool> I was surprized not to hear back from any of you two <ogra> i read it, yes <asac> ogra: right. thats what "Low" means. if someone gets to it fine. otherwise no problem <lool> s/put/written <asac> lool: will read it later today. needed to work full-time on spec stuff esterday ;) <ogra> 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) <lool> What would really rock is doing it with multiarch, but it's not clear it will happen this cycle <ogra> right <lool> ogra: Well I'm not happy with relying on the host setup instead :-) <ogra> until then i'm happy to keep it as is <ogra> right, i know <lool> 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 <ogra> 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 <lool> Moving binfmt to this script is the only thing I didn't research -- as noted -- I dont know whether it's container friendly <lool> 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 :-/ <ogra> i think the container stuff happens at another level ... i wouldnt see why it shouldnt work <ogra> the kernels binfmt module just reacts on the magic number ... i dont think it cares if that happens in a container or not <ogra> as long as the wrapper is found at least * suihkulokki has a way to execute arm binaries in a chroot using a dynamically linked qemu-arm without binfmt_misc <lool> suihkulokki: I can do that for a single binary as well, but not one that forks <suihkulokki> including forks <lool> suihkulokki: Oh scratchbox2? <ogra> 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 <suihkulokki> well, sb2 can do that too <lool> suihkulokki: Would love to hear your way then <suihkulokki> my way is just much more lightweight <lool> suihkulokki: I've documented what I tried in https://wiki.ubuntu.com/Specs/Mobile/QemuStaticExecutionEnv/Research <ogra> what i dont want is that the user needs to type in a chain of commands and options to create a chroot <lool> ogra: That can always be reduced to a script :-) <ogra> as i said, feel free :) <lool> ogra: My worries with the proposals I heard at UDS were: specific to Ubuntu, package proliferation <ogra> i will only put time into it if i actually have a lazy day before FF ... <ogra> which is unlikely <suihkulokki> I hope to show my way next weekend latest <lool> suihkulokki: Well you said too much now; mind sharing the high-level idea? <lool> suihkulokki: Did you patch qemu to spawn itself on forks? <lool> or exec rather <suihkulokki> basicly a LD_PRELOAD a library that executes qemu on exec if the binary to be executed is not host arch <lool> Ok; I thought of something similar by patching qemu's syscall emulation of the exec() syscall <lool> Your approach is probably more self-contained and might also allow calling into a host binary more easily <lool> Hmm not sure actually <lool> 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 <lool> But still more self contained <Stskeeps> ld.so.preload maybe? <dpb> and will fail for static binaries.. <suihkulokki> 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 <suihkulokki> s/look/lool/ <lool> 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 <lool> That would work very well I think; good idea <suihkulokki> lool: yeah. if some hardcoding is acceptable it would be easy to do the same modifying qemu's exec <lool> suihkulokki: Is hardcoding really necessary? can't qemu-arm exec() into itself with enough info to proceed to the target binary? <dpb> suihkulokki: ah, right. I'm tired. :) <lool> (I didn't look at the qemu syscall emulation itself at all, so feel free to call that impossible or very hard!) <lool> 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. <asac> lool: right. we dont want arm mode ... unles we cant find a patch quickly ;) <lool> Well I'm only suggesting that as a stopgap <lool> glib impacts a lot of packages <lool> Of course we want thumb2 <ogra> lool, do you know swp will fail with -Wa,-mimplicit-it=thumb ? <asac> lool: right. i just hope we can have a patch really quick ;) <asac> (this afternoon) <lool> I think it's not available in t2 mode <asac> otherwise i agree we hsould upload with -marm <ogra> hrm <lool> Which would seem logical since v7 introduced thumb2 AND new stuff to get rid of swp <asac> http://paste.ubuntu.com/333081/ <asac> thats the code <lool> SWP instruction <lool> is not supported in Thumb2 mode at all <asac> i know <lool> As confirmed from the Slide 5 notes in https://wiki.ubuntu.com/Mobile/ARMv7AndThumb <asac> ;) <lool> You were asking whether implicit-it=arm would help, it will not <lool> I just double checked <asac> its also here: https://wiki.ubuntu.com/ARM/Thumb2 <asac> lool: right. thats what i suspected <lool> or here https://wiki.ubuntu.com/Mobile/ARMv7AndThumb <lool> Well since ogra was about to fire a build with implicit-it=, I figured it was worth mentionning that it wouldn't help <lool> Anyway, /me hops to pressing stuff <ogra> well, i'm still writing on a spec <asac> __sync_val_compare_and_swap <ogra> i wouldnt have fired it off right away :) <asac> is there a good resource to track armel build failures? <lool> ubuntuwire <lool> http://qa.ubuntuwire.com/ftbfs/ <asac> th <asac> x <lool> that's the failing qt4-x11 code http://paste.ubuntu.com/333247/ <lool> The #else <ogra> ../../corelib/io/qfsfileengine_unix.cpp:1309: error: unrecognizable insn: <ogra> (insn 636 635 218 23 ../../corelib/io/qfsfileengine_unix.cpp:1286 (set (reg:SI 9 r9 [+4 ]) <ogra> set reg sounds like assembler to me, surely not like C++ * ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | <suihkulokki> is there gym excersizes to make ARMs faster? | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | build probs with your packages in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2 <ojn> Hm, what's the reason for using softfp? I thought all supported platforms today had proper implementations? <ojn> oh, nevermind. that's just the abi <fta> asac, do you need -Wa,-mimplicit-it=thumb or is -mthumb good enough? <ogra> fta, https://wiki.ubuntu.com/ARM/Thumb2 <ogra> i dont think -mthumb is enough <fta> i get /tmp/ccRUIN1V.s:131: Error: thumb conditional instruction should be in IT block -- `moveq ip,#8' <fta> but as it happens after 19h+ of build, i prefer to ask ;) <fta> i should probably setup a crosscompile env <ogra> no, that gets painful <ogra> since you need to cross build all the deps first <ogra> crossbuilding is fine for packages with only a few deps ... i wouldnt build something with lots of deps in a cross way <fta> ogra, upstream provides this recipe: http://code.google.com/p/chromium/wiki/LinuxChromiumArm <fta> looks possible but could be easier :P <ogra> well, as long as you are sure the cross toolchain they provide uses the same options, that might work <zumbi> ogra: our cross toolchain is not sysrooted <ogra> zumbi, well, does it default to the options documented on https://wiki.ubuntu.com/ARM/Thumb2 ? <zumbi> ogra, no, i do not think so <ogra> right, thats what i suspected <ogra> so it doesnt help much unless you hack around it in debian/rules since fta wants to fix build errors happening on the buildds <zumbi> btw, which cross tool do you use? lool PPA? <ogra> none * ogra is highly anti cross :) i build on real HW <zumbi> ogra: do you native build kernels for new bootstraps? <ogra> for small packages i use the ubuntu qemu-arm-static package <ogra> oh, for test kernels i sometimes use codesourcery ... <zumbi> yes, qemu is nice and helpful, also cross building <ogra> but most of the time i simply use my dove board :) <zumbi> which is fine and if you have the time and the power, it is best practice :-) <ogra> but cross building does only cut down buildtime in half or so ... and i usually dont touch kernels <zumbi> ogra: you can not native build a uclibc based device (no space) <ogra> we dont use uclibc in our ubuntu images <ogra> all devices we support have at least 800MHz and 512MB <ogra> and usually a SATA port <armin76> ricer board <zumbi> yes, in those cases, cross building is not needed <zumbi> but, i can not native build on my lynksys <ogra> armin76, still envious, eh ? <ogra> zumbi, well, i did native builds on my nslu2 ... but i agree its no fun <ogra> armin76, just wait for the next gen sheeva plug :) <armin76> boo <armin76> ogra: why do i have to wait?! <ogra> it will be dove based <ogra> at least thats what roumours said :) <zumbi> armin76: still you have not got an armv7? <armin76> zumbi: nope <armin76> zumbi: ogra doesn't wanna share *g* <zumbi> armin76: get a beagleboard :) <ogra> or if you are rich, get a babbage board <zumbi> ogra: cross building is needed when you have to maintain a distro which runs on 4MB devices up to several GB <ogra> indeed <ogra> luckily ubuntu went beyond that :) <zumbi> also uclibc would enter in thecocktail <Stskeeps> zumbi: or compiling qt and not waste several days on it :P <zumbi> qt-embedded ? <armin76> ogra: i could get your babbage *g* <ogra> Stskeeps, https://launchpad.net/ubuntu/+source/qt4-x11/4.5.3really4.5.2-0ubuntu1/+build/1292073 22h :) not even a day <ogra> 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 <ogra> afaik freescale sells them now <ojn> genesi are shipping their pegatron smarttop rebranded device too (with u-boot as firmware) <ogra> right, but you could only use ubuntu userspace with it <ogra> there is no pegatron kernel <ogra> and its stuck on 2.6.28 ... <ojn> yeah i know. nice gpl compliance there. <ogra> heh <ogra> lucid will use uboot on the babbage too ... * ogra calls it a day <ojn> yikes, 800 bucks from arrow * zumbi wonders if any of you know mpc8548 ppc processors <ojn> zumbi: plenty of people on #mklinux do <zumbi> ojn: yes, i just went there <fta> 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? <fta> +it #ubuntu-arm 2009-12-03 * cwillu_at_work pokes at rcn-ee <rcn-ee> how's it going cwillu_at_work <cwillu_at_work> building my debs in qemu as we speak becuase _somebody_ didn't build it for me :p <ojn> qemu? painful. <rcn-ee> well that's the proper way, no cross compiling allowed! ;) <cwillu_at_work> what's the slow down in comparison to doing it native? <cwillu_at_work> I was figuring that 2gb of ram + quad lauren32@example.com is faster at playing arm than an arm is <ojn> pretty bad last time I compared (native freescale vs qemu on nehalem). Don't remember exactly how many times slower qemu was though. <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.. ;) <cwillu_at_work> maybe I'll race them next time <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 <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.. ;) * cwillu_at_work nearly resists the urge to say "meh, I get paid by the hour" :p <ojn> if you're going to distcc then you might as well distcc out to a native cross compiler <ojn> that'd be better/faster/easier <cwillu_at_work> that actually sounds sane <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. <ojn> any plans on providing that, canonicalites? <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... <ojn> rcn-ee: why would anyone want that? <rcn-ee> take on the top500? ;) not sure, but he's doing it.. <rcn-ee> Eric Fung here: http://groups.google.com/group/beagleboard/browse_thread/thread/f5f14f4ec66ab45d/df03479bf1ca0861?lnk=gst&q=44#df03479bf1ca0861 <ojn> Haha. the beagles aren't exactly fast. sounds like a good way to burn 5000 dollars to me. <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... <ojn> oh, he uses them for industrial automation? still, sounds odd not to do something more monolithic. <cwillu_at_work> rcn-ee, is that why we can't buy beagleboards these days? :p <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. <rcn-ee> the dvi/video chip is very hard to get right now.. So the boards can't be finished for sale... * ojn heads to dinner. <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... :( <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? <ojn> s/the thumb2 bug/the thumb2 branch bug/ <ojn> might be fixed in the new ones, not sure. <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 * zooko reads https://wiki.ubuntu.com/Mobile/ARMv7AndThumb <zooko> Is it publicly known who are the hardware makers working with Canonical on ARM devices? <ojn> Marvell and Freescale make the boards that are officially supported, if that's what you mean? <zooko> I meant the story that Canonical is working with makers of netbooks./ <zooko> I suppose which makers is secret. <zooko> Or maybe I'm supposed to call them smartbooks if they are ARM based. <zooko> By the way, I'm also really interested in ARM-based servers. Hard to find. <ojn> Oh. Yeah, I don't think they've talked publically about that <zooko> http://perspectives.mvdirona.com/2009/11/30/2010TheYearOfMicroSliceServers.aspx <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 <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) <fta> ogra, ok, thanks. that sentence is just confusing then. <ogra> its a wiki, feel free to fix ;) <ogra> dmart, you rock ! * ogra does a testbuild of glib <dmart> -er- not yet, I've just been looking at the compiler output... __sync_synchronize() compiles away to nothing :( <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. <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. <ogra> dmart, hmm, i have some prob with your patch ... <ogra> it succeeded with offset, i triggered a build but failed ... looking closer i see that: <ogra> patching file glib/gatomic.c <ogra> patching file configure.in <ogra> Hunk #1 succeeded at 2491 (offset 11 lines). <ogra> root@babbage2:/glib2.0-2.23.0# wc -l glib/gatomic.c <ogra> 1089 glib/gatomic.c <ogra> did you patch the actual latest lucid upload ? <ogra> or a former source <dmart> It was against 2.22.2. Do source packages not appear in the archive until a successful binary build has been uploaded? <ogra> they do, did you apt-get update before apt-get source ? <ogra> 2.23.0 here <dmart> Hmmm, possibly not. I'll try again <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)? <ogra> both is fine <dmart> OK, now 2.23.0-1ubuntu1 <dmart> Is the build log for your failure visible on launchpad? <ogra> do as you like it most, someone needs to touch the package anyway for sponsoring the upload <dmart> OK... I'll attach a new patch to the bug when I've sorted it out. <ogra> (its indeed less work if the patch is on top of the stack but doesnt make a big difference) <asac> ogra: whats the prob? <asac> configure.in problem? <ogra> asac, the build fails with the same error due to the patch being for the karmic version <asac> well. <asac> but that cant be a big problem <asac> its just confiugre.in, right? <ogra> yes <asac> ogra: it applies ... sure you ran autoconf? <ogra> doesnt debian/rules do that ? <ogra> hmm, seems not <asac> no <asac> gnome packages dont do that <asac> you have to do a patch <ogra> i thought they usually use some autoreconf.mk thingie <lool> No <asac> no <ogra> ok <asac> thats dirty anyway <ogra> i know but i thought i saw that before in gnome packages <asac> ogra: just remove the if stuff etc al <asac> ogra: those are not real gnome packages then ;) <asac> anyway <asac> http://people.canonical.com/~asac/tmp/70_glib2.0-gatomic-arm.patch <asac> ogra: <asac> use that <asac> and ignore the confiugre stuff <ogra> oki <asac> has a hacked "define ..." obviously not for upstream, but beter than doing the full configure thing in package <ogra> yeah <asac> dmart: so no need to update it to lucid version from what i see. should be ok as it is for now ;) <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 <dmart> Do you need an extra patch from me? <dmart> ogra, asac, do you need an extra patch, or are you OK for now? <asac> no all fine. thanks a lot <asac> once we know we let you know ;) <ogra> got past gatomic.c/o <asac> very good ;) <ogra> so seems all fine <ogra> i'll let it finish <dmart> Is it usual to upstream things like this, and what would the timescale be? <ogra> heh, depends on the upstream i guess <asac> dmart: real quick if there are no questions etc. <asac> (for glib) <dmart> Yeah, of course <ogra> yeah, glib should be fast <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. <ogra> right, our main focus atm is to get all packages building for alpha1 <dmart> agreed <ogra> if we have packages with temp workarounds we need to touch later again, we should collect them somewhere though <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. <dmart> orga, is the ARM/Thumb2 page the right place for that? <ogra> yeah, probably a package section at the bottom would make sense <asac> we should keep a bug open so we remember to rebuild glib etc. after the intrinsics are fixed <asac> dmart: ogra: ^ <dmart> asac, ogra: I'm raising a bug on GCC to track this; we can reference it from the existing glib2.0 bug? <asac> dmart: unfortuantely we can only dupe stuff (which isnt right here) <asac> dmart: i would suggest to add a new bug to GCC <asac> and then add the packages we identified as targets <asac> so after filing the gcc bug, click on "also affects distributioN" ... and select glib2.0 there for now <asac> then drop a comment that glib is affected blah blah blah and reference the other bug in the comment for background info <dmart> ogra, asac: Raised: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491872 <ubot4> Launchpad bug 491872 in glib2.0 "[armel] Atomic intrinsics are not implemented correctly" [Undecided,New] <dmart> I've added a note to https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491342 <ubot4> Launchpad bug 491342 in glib2.0 "assembly fails to build on armel/lucid " [Critical,Triaged] <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? <ojn> (main use for me would be to use it for distcc:ing across to a faster machine) <fta2> asac, did you retry chromium? <armin76> asac: whats the status on chromium? did it build? <fta2> it should, but i don't have access to any arm builder <asac> copying now <asac> just lucid though <asac> copyied <fta> asac, sure, no need to even try karmic unless i enforce armv7 <ogra> (karmic is v6 and no thumb) <fta> ogra, yep, what i meant is upstream only supports v7, at least until someone ports it to something else <ogra> ah, well ... <fta> thumb doesn't seem to be required though <ogra> i think we'Re the only distro building with thumb2 atm <ogra> not even angstrom (beagleboard default distro and highly optimized) does use thumb <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 <ogra> roumors say up to 30% size reduction and up to 30% speedup is possible through thumb2 <asac> fta: the problem for non-armv7 was broken assembly? <lool> maemo used to have thumb1 support, not sure whether they are using thum2 now <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 <fta> asac, when built for android, v8 build system adds a bunch of flags, incl -march=armv5te & -mthumb-interwork #ubuntu-arm 2009-12-04 <siji> hi all <siji> good evening <siji> How to disable VSYNC in Ubuntu+Bealge Board <fta> asac, http://codereview.chromium.org/download/issue463027_1001.diff <asac> ok <asac> but does that help? <asac> i dont think that would fix builds < armv7 <asac> i agree its right to split this up though <asac> is there no good codebrowser for chromium? <asac> with cross reference? <asac> fta: ? <fta> no, there's google code search but it's not uptodate <fta> asac, i wanted to setup an lxr but the deb package is a mess <asac> kk <rek> where can i find the repositories? <ogra> ports.ubuntu.com <rek> i man <rek> where can i find what to put in etc sources list <rek> hi ogra i remember you are in germany now <ogra> deb http://ports.ubuntu.com/ubuntu-ports <distro> main universe <fta> asac, chromium succeeded on lucid! \o/ (took 9 hours, 43 minutes, 23.6 seconds) <ogra> rek, right, thats where i live * asac dances <ogra> 9h isnt bad ! <rek> ? <rek> ogra it's for a smartq 5 <fta> a big part of these 9h is due to the testsuite <asac> fta: 9 hours is wrong imo <asac> i think it started right when i uploaded <asac> and that was aboug 24h ago ;) <asac> about <asac> hmm maybe a few hours later <fta> Build needed 21:39:16, 6295520k disk space <fta> hm <ogra> rek, smartq 5 is ARMv5, right ? <rek> i have karmic main universe restricted multiverse i want jaunty <fta> bad lp <rek> i think it's arm <asac> 17:36 < asac> chromium for lucid bits are here: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3 <asac> 17:36 < asac> anyone give it a check? <asac> 17:37 < asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1377663 ;) <ogra> sure ... the version counts :) <asac> dont ask me about the team name ;) <fta> asac, can't you ask for a rename? <ogra> rek, but if its v5 you will need to replace karmic with jaunty in your line <asac> no <asac> that team is still needed <asac> ;) <rek> ok i'll try <asac> just was too lazy to get a new native ppa <fta> asac, or ask for more generic team? <ogra> ubuntu-arm-browser ? <asac> atm native ppas are not avialable to anyone but employees unfortunately <rek> ? <fta> or just an arm native ppa <asac> i will try to get that revisited <ogra> i think its blocked on XEN <asac> i would think that motu/core-dev together with a damn good reason should be ok too <asac> ogra: reall ppas yes <asac> real <ogra> we'd need spare HW for PPA work <rek> locale not supported by C library why? <asac> ogra: it was about policy for native ppa <ogra> right <ogra> rek, prefix your commands with LANG=C then that goes away ... or run locale-gen <yourlocale> <rek> don't understand <rek> it happens also if i do apt-ge <ogra> right, prefix the commands with LANG=C or generate the proper locale <rek> what's a locale? <rek> what does "umet dependencies/it's not going to be installed " means.... every time i try to get a new application <rek> unmet <ogra> that means that a depending package is missing <ogra> a locale is a set of translations etc <rek> so i cannot have a single application working damn? <ogra> what exactly are you trying to do ? <rek> sudo apt-get install amsn for example <rek> i did apt get f now <rek> var log apt missing damnit another error? <ogra> did you do apt-get update after adding the line to sources.list ? <rek> yeah <ogra> and the smartq has ubuntu installed already ? <rek> yes <rek> ok <rek> now it works <rek> wait <ogra> well, then its likely that a package amsn depends on failed to build and nobody fixed it <rek> gimme a name of a cool application i can install <ogra> no idea <ogra> http://qa.ubuntuwire.org/ftbfs/jaunty.html has the list of packages that didnt build in jaunty <ogra> as you can see there are a lot of broken packages in universe <rek> why can't we have a flah? <rek> flash <ogra> ask adobe :) <rek> is that true? <ogra> they own flash <rek> how can i have a sound recorder? <ogra> probably with: apt-get install gnome-sound-recorder <rek> how can i hae skype? <ogra> no idea <ogra> ask skype ... its proprietary <rek> suggestions? <asac> rek: check the download page. get the all static tar gz .. .unpack it somewhere in your home and run the skype command inside <asac> but for arm ;) ... <asac> hehe <asac> sry didnt check the channel <asac> try gnash <ogra> yeah, gnash might work as flash replacement <rek> gnash? <rek> sure? <rek> and skype? <ogra> there is no skype for arm <rek> can i have the sources and compile them all? <ogra> its proprietary ... as long as skype doesnt offer an arm build ... <ogra> same as with adobes flash <rek> strange <rek> is there something like skype out there? <ogra> the protocol is proprietary <ogra> so no <ogra> they recently released the source for the client but it still uses a binary blob which would have to be compiled for arm <rek> blob? can i do something? <ogra> no <lool> ogra: N810 and N900 have Skype for ARM though :-) <pwnguin> woo! Estimated Delivery Date:12/8/2009 (updated) <pwnguin> nokia n900 on the way <pwnguin> were there any notes from the arm track at UDS? <pwnguin> particularly, I'd like to review the stuff i heard about arm board descriptors or something like that <ojn> device trees? yes. <ojn> one sec <ojn> https://wiki.ubuntu.com/UDS-L/RemoteParticipation see gobby instructions. Notes were taken there (they were still there when I checked a week and a half ago) <pwnguin> quite a few gobby docs <pwnguin> hmm. what's the difference between a flattened tree and a list? #ubuntu-arm 2009-12-05 <powderluv> Folks anyone use rootstock to create Lucid rootfs ? It gets as far as the second stage but qemu doesnt seem to start (prints out usage and bails) so maybe some qemu parameters have changed?? <rcn-ee> powderluv, rootstock as isn't ready for lucid.. it need a couple changes: https://code.launchpad.net/~beagleboard-kernel/+junk/project-rootstock-lucid doing daily builds with it right now.. <powderluv> rcn-ee: cool thanks i will check it out and let you know how it goes <powderluv> rcn-ee: do you build ubuntu-minimal <rcn-ee> powderluv, a lot of packages are in flux so keep it minimal.. although 'xfce4,gdm' worked on this morning's build.. <powderluv> rcn-ee: fyi, ubuntu-minimal works. ubuntu-desktop failed on gedit. so these packages are all built with thumb2 already ? <rcn-ee> powderluv, until atleast alpha-1 but it could be later it's really going to be very hit and miss with missing packages/dependices.. Yeap, everything should be thumb2, unless the package is broken.. It's still really early thou, i still haven't successfully built a kernel in a native lucid chroot for the beagleboard <powderluv> ohh because of thumb2 or just churn in the packages ? <rcn-ee> powderluv, both.. ubuntu has a tinkerbox style build status log, don't remember the address, lots of red for armel.. <powderluv> ok i see. i will dig for it. have you tried running any of the lucid rootfs on a system. is it at a bootable state ? <rcn-ee> powderluv, found it: http://qa.ubuntuwire.com/ftbfs/ <powderluv> thanks. we are leading the way in number of package failures :) <rcn-ee> well i have a chroot setup for lucid on my beagleboard i use to build stuff, but lots of "illegal instructions" and random hardlocks. It would be interesting to run it on a another cortex-aX platform.. <rcn-ee> i even have to rule out thumb mode, since i ran the gcc testsuite with it enabled and disabled, not much difference. which just leaves bad packages... <powderluv> i will try them out let you know <powderluv> do you recompile those packages independently with thumb disabled? <rcn-ee> powderluv, full gcc bootstrap.. digs for the two reports.. <rcn-ee> thumb: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02447.html <rcn-ee> nonthumb: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02538.html <OSS542> Good Evening All <OSS542> anyone here using Zubuntu ? <rek> i want an application like skype <rek> can i have a flash player? <armin76> rek: you already asked that yesterday <rek> really? <rek> iis there a solution? <kblin> yeah, reverse engineer the skype protocol and write an app supporting said protocol that compiles on arm <OSS542> anyone here using Zubuntu ? <rek> hi i need an application to refresh my ip,i need also an application to manage a ftp server <fta> asac, could you copy the codecs package to the arm ppa too? it's needed (dep) <Stskeeps> g w00t <Stskeeps> err. <asac> fta: why is it a dep if its not needed during build. should at most be recommends <fta> asac, because it's loaded dynamically and is not a build-dep, but i made chromium depends in either the free or non-free set of codecs <fta> asac, depends vs recommends because upstream didn't want us to change the user experience, that whole free vs non-free is just to give users the choice <asac> fta: we already change upstream experience by allowing free/non-free, right? i think that recommends should be similarly ok. #ubuntu-arm 2009-12-06 <MarkGil> Hi, I due to Ubuntu dropping armV5 support, I was forced to move my Sheevaplug from Ubuntu to Debian, however I need to cross-compile for arm on my Ubuntu desktop machine, using emdebian, do I also need to switch my desktop PC's to Debian too, or is there a way to run emdebian on Ubuntu? #ubuntu-arm 2009-12-07 <DieB1984> Hello. I had jaunty running on my nslu and asked my self if there is an actual installer? Or do you know which kind of arm image i might need? thx a lot <DieB1984> excuse me pls if i disturb, but might anyone know what image i shall use to install ubuntu on my nslu? is it still the jaunty installer or is it one of the new kernel ones. thx very mucho <ogra> we stopped supporting ARMv5 systems with karmic, so you can only use jaunty on NSLU2's <ogra> karmic is built for ARMv6, lucid even for v7, neither binaries will run on the slug <DieB1984> thank u <asac> fta: copied ffmpeg to native ppa now ;)( <asac> lets see. wont expect it to start soonish ;) <fta> asac, thanks <MarkGil> Stupid question time: Whats the difference between ARM and ARMEL? <MarkGil> in the context of this: http://people.debian.org/~aurel32/qemu/ <ojn> MarkGil: arm is the old pre-EABI distro. <ojn> s/distro/distro arch/ <ojn> http://wiki.debian.org/ArmEabiPort #ubuntu-arm 2009-12-08 <ogra> asac, so did you bring up your babbage already ? <asac> ogra: yes and no ;) ... default image boots ... karmic image doesnt get really far <asac> need to get serial adapter ;) <asac> but i think karmic image is not supposed to work? <ogra> it is <asac> yeah <ogra> and the others (i.e. JamieBennett, dyfet and plars ) use it <asac> hmm <asac> i get splash <ogra> and then ? <asac> in contrast to factory image the keyboard works <asac> but it doesnt get further ... getting IO errors * ogra points to https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-une-casper-speedup <ogra> give it 5 min <JamieBennett> asac, works fine here <ogra> IO errors ? <asac> hmm. five minutes ;) ... i waited quite some time <JamieBennett> CF card problems? <ogra> how did you write the image to SD <asac> using instructions on wiki <asac> https://wiki.ubuntu.com/ARM/BabbageKarmicInstall <ogra> yeah, that should just work * JamieBennett uses ImageWriter :) <ogra> which way did you use to write the image ? <asac> dd <ogra> imagewriter is essentially dd <JamieBennett> ogra: yes <JamieBennett> but prettier <asac> http://releases.ubuntu.com/9.10/ubuntu-9.10-desktop-armel+imx51.img <ogra> though it doesnt use bs=16M <ogra> no idea who added that <ogra> try witrhout the bs=16M <asac> checking <ogra> bs=1024 is the default in imagewriter * ogra just checked the source <asac> ok using bs=1024 <ogra> what kind of SD is that ? (brand/model) <asac> only thing the dealer had <ogra> former versions of the babbage (i.e. the B1) had probs with some cheapo SDs <asac> sandisk wasnt there ;) <asac> hmm <ogra> but that should be fixed since 2.0 <asac> have to check when its not in my laptop <persia> asac: You might want to hunt up the specs on the card. I've found that using bs=${NATIVE_BLOCKSIZE} causes faster and more accurate writes. <asac> i think its Trans* something <persia> Transcend probably <ogra> transcend <asac> yeah <ogra> bah, persia beats me :P <asac> sounds right * persia just happened to have a transchend box at eye-level * ogra doesnt think he has transcend around to test <asac> ok at least i dont see any I/O error atm <asac> it says "writing IMID and MAP to secure the partition" <asac> UMID <asac> ogra: does that sound familiar? <asac> JamieBennett: ? <JamieBennett> asac: you have a serial adapter now? <JamieBennett> or is that on the screen <JamieBennett> ? <asac> screen <asac> no serial adapter <asac> need to figure that during lunch i guess ;) <JamieBennett> That should take around 90 seconds then it continues to boot <asac> now i have like udevd.*worker.*failed... <JamieBennett> That shouldn't happen ;) <ogra> thats a kernel message <asac> yeah. seems it cannot handle the partitions somehow <ogra> so your kernel boots :) <ogra> no <ogra> that partition thing belongs to an encryption device in the SoC <ogra> just ignore it, we dont use that device <ogra> just be patient :) * asac patient ;) <asac> ok if this is right there is definitly room for improving the image experience ;) * ogra had patches to get that noisy messages away <asac> no i got "stadin: I/O error" <ogra> but the kernel team refused <asac> stdin: I/O error <asac> not sure if that is missing serial <ogra> freescale likes to use KERN_CRIT where it only needs KERN_INFO in many areas <asac> with my previous dd'ed image i only got those <JamieBennett> Have you tried another CF card to make sure its not that? Most of the problems seem to stem from some breakage there. <ogra> strange <asac> whats the md5sum of the .img file? <ogra> 297875d2a7531824a0fb08f241d33e8 <asac> 297875d2a7531824a0fb08f241d33e85 ubuntu-9.10-desktop-armel+imx51.img <ogra> http://releases.ubuntu.com/9.10/MD5SUMS <asac> hmm seems right <ogra> whoops paste error <asac> anyone uses this without a serial console attached ;)? <asac> ok got another SD out of the bag from same brand though ;) <ogra> i never use a serial console if i dont have to <asac> the other option would be to kill the windows CE sandisk thing that was delivered ;) <ogra> and i only have to when i create new bootloader setups <ogra> windows CE ? <asac> yes <ogra> ugh <ogra> well, dd it off the SD <asac> two SD things where there: linux ... and windows CE <asac> hey... there even is a license ;) <ogra> and overwrite the SD then <ogra> you can always dd it back <asac> yeah <ogra> and order some sandisk cards ;) <asac> if thats the reason <ogra> you dont have a mediamarkt around in hamburg ? <asac> i have <ogra> they usually have multiple brands <asac> also saturn ;) <ogra> they too <asac> do they have usb to serial adapters ;)? <ogra> just buy three different ones <asac> hehe <ogra> sure <asac> sure ... i wouldnt say that for saturn <asac> they really have close to nothing <asac> nothing == everything that is too low level for main stream customer is missing <ogra> wow, the kassel saturn seems to be better then <persia> asac: That's just a call to change the needs of the "main stream consumer" :) <ogra> heh <ogra> yeah, just buy 10000 SD cards and you will change them <persia> Or start a local digital photo group for students, and get them to buy cards (this costs a few hours a week, rather than money) <ogra> you mean saturn would give away the cards for free to students ? * ogra wonders how japan does business these days *g* <persia> No, but the students would pay rather than the instigator. <ogra> ah <asac> hah <asac> the other SD card worked ;) <asac> ubuntu X is starting ;) <persia> Saturn *might* give away cards, if it was part of some special program: I don't know enough about German tax provisions. <persia> \o/ <asac> saturn is a rip-of-company ... say that they sell stuff cheap, but then you see the cheapest wireless router is 60 EUR <asac> while i get one at my dealer of same brand for 39 EUR <ogra> yeah <ogra> asac, congrats ! <ogra> asac, install should take up to 1h <ogra> depending on the speed of your USB device <JamieBennett> (or more I have found) * ogra takes a break <asac> hmm found out that the image kernel doesnt like my usb mass storage thing <asac> on x86 is fine with karmic kernel <asac> dmart: you said initially you have some ideas about the mksquashfs issue? current bt is: http://paste.ubuntu.com/337345/ <asac> dmart: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3 <asac> dmart: so you need to download the .deb files and force install them because the codec package (just something dloaded) isnt there for chromium <asac> of course all depends but chromium...-ffmpeg should get installed ;) <ogra> did you build that yesterday ? <asac> right <asac> let me check if that worked ;) <asac> nope. failied to build <asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1384064 <asac> worked everywhere else, but arm as it seems <asac> ogra: is that the same error we get on ffmpeg in archive? <asac> fno-signed-zeros -c -o libavformat/oggparseogm.o libavformat/oggparseogm.c <asac> In file included from libavformat/oggparseogm.c:27: <asac> ./libavcodec/get_bits.h:93:2: error: invalid preprocessing directive #warn <asac> hmm <ogra> to be honest i havent looked at ffmprg yet <ogra> *ffmpeg <ogra> post A1 stuff :) <asac> sure <asac> ogra: i think from the start of the call it felt like dmart had an idea on the mksquashfs thing ... lets wait what he says ;) <ogra> yeah <asac> ogra: upgrading karmic image yields a Read-only file system error <asac> when flashing kernel <asac> is that known? <asac> is mounted rw from what i can see <ogra> upgrading to what ? <asac> ogra: just upgrading to karmic-security/-updates <ogra> just security fixes ? <asac> yes <dmart> I have no particular idea on mksquashfs yet, but I'd be intrested in reproducing the bug if you can give me a test case <ogra> dmart, you have a pegatron nettop, right ? <asac> dmart: http://paste.ubuntu.com/337345/ thats the backtrace without symbols <ogra> dmart, just create a lucid chroot ... chroot into it and run mksquashfs on any dir you like <ogra> it will fail with SIGILL <asac> in some mutex stuff. though i doubt that pthread mutex can be broken completely <asac> but ... we can something similar for dchroot on the porter box which is also a pegatron afaik <asac> but not a sigill ;) <asac> dchroot -c lucid <asac> dchroot: pthread_mutex_lock.c:87: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. <asac> Aborted <ogra> is your call over ? <asac> yes <dmart> asac, can you throw me a link to the Chromium build and logs? <asac> dmart: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+packages <asac> dmart: you can access the build logs there <asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1377663 <asac> dmart: ^^ <asac> dmart: the .debs are on the +packages page <asac> just the unfold the topmost build <dmart> Oh, right. "mozilla" confused me ;) <asac> sorry <asac> was the only place i had spare that has native ppa capabilities ;) <asac> will get a better place <dmart> Cheers <asac> ogra: where is this "Flashing kernel..." done? <asac> FIS create failed. <ogra> create ? <ogra> what are you doing there ? <asac> triggers update-initramfs <asac> ogra: i dist-upgraded ... kernel wants to update initramfs etc. <ogra> update-initramfs calls flash-kernel <asac> then it says "flashing kernel" <asac> yeah <asac> i want to add debug statement to see which device it tries to write to <asac> but found it in triggers now <ogra> and flash-kernel replaces the initramfs in the existing fis <ogra> the device is defined in /etc/flash-kernel.conf <ogra> as well as the offset and lenght <asac> hmm its wrong <asac> i still have the sd card with installer in the first slot <asac> is that wrong? <asac> the install SD card didnt boot on its own <ogra> the SD turns into a boot floppy <ogra> after install <dmart> asac, ogra: I tried running mksquashfs /etc etc.squash --- didn't crash for me. Do I need a heavier test? <ogra> it needs
{'channel': 'ubuntu-arm', 'month': 12}