=== bjf is now known as bjf-afk === asac_ is now known as asac === asac_ is now known as asac [11:06] asac, so did you bring up your babbage already ? [11:08] ogra: yes and no ;) ... default image boots ... karmic image doesnt get really far [11:08] need to get serial adapter ;) [11:09] but i think karmic image is not supposed to work? [11:09] it is [11:09] yeah [11:09] and the others (i.e. JamieBennett, dyfet and plars ) use it [11:09] hmm [11:09] i get splash [11:09] and then ? [11:10] in contrast to factory image the keyboard works [11:10] but it doesnt get further ... getting IO errors [11:10] * ogra points to https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-une-casper-speedup [11:10] give it 5 min [11:10] asac, works fine here [11:10] IO errors ? [11:10] hmm. five minutes ;) ... i waited quite some time [11:10] CF card problems? [11:11] how did you write the image to SD [11:11] using instructions on wiki [11:11] https://wiki.ubuntu.com/ARM/BabbageKarmicInstall [11:11] yeah, that should just work [11:12] * JamieBennett uses ImageWriter :) [11:12] which way did you use to write the image ? [11:12] dd [11:12] imagewriter is essentially dd [11:12] ogra: yes [11:12] but prettier [11:12] http://releases.ubuntu.com/9.10/ubuntu-9.10-desktop-armel+imx51.img [11:12] though it doesnt use bs=16M [11:12] no idea who added that [11:12] try witrhout the bs=16M [11:13] checking [11:13] bs=1024 is the default in imagewriter [11:13] * ogra just checked the source [11:14] ok using bs=1024 [11:15] what kind of SD is that ? (brand/model) [11:15] only thing the dealer had [11:15] former versions of the babbage (i.e. the B1) had probs with some cheapo SDs [11:15] sandisk wasnt there ;) [11:16] hmm [11:16] but that should be fixed since 2.0 [11:16] have to check when its not in my laptop [11:16] 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. [11:16] i think its Trans* something [11:16] Transcend probably [11:16] transcend [11:16] yeah [11:16] bah, persia beats me :P [11:16] sounds right [11:17] * persia just happened to have a transchend box at eye-level [11:17] * ogra doesnt think he has transcend around to test [11:20] ok at least i dont see any I/O error atm [11:21] it says "writing IMID and MAP to secure the partition" [11:21] UMID [11:22] ogra: does that sound familiar? [11:22] JamieBennett: ? [11:22] asac: you have a serial adapter now? [11:23] or is that on the screen [11:23] ? [11:23] screen [11:23] no serial adapter [11:23] need to figure that during lunch i guess ;) [11:23] That should take around 90 seconds then it continues to boot [11:23] now i have like udevd.*worker.*failed... [11:24] That shouldn't happen ;) [11:24] thats a kernel message [11:24] yeah. seems it cannot handle the partitions somehow [11:24] so your kernel boots :) [11:24] no [11:24] that partition thing belongs to an encryption device in the SoC [11:24] just ignore it, we dont use that device [11:24] just be patient :) [11:25] * asac patient ;) [11:25] ok if this is right there is definitly room for improving the image experience ;) [11:26] * ogra had patches to get that noisy messages away [11:26] no i got "stadin: I/O error" [11:26] but the kernel team refused [11:26] stdin: I/O error [11:26] not sure if that is missing serial [11:27] freescale likes to use KERN_CRIT where it only needs KERN_INFO in many areas [11:27] with my previous dd'ed image i only got those [11:27] Have you tried another CF card to make sure its not that? Most of the problems seem to stem from some breakage there. [11:27] strange [11:27] whats the md5sum of the .img file? [11:28] 297875d2a7531824a0fb08f241d33e8 [11:28] 297875d2a7531824a0fb08f241d33e85 ubuntu-9.10-desktop-armel+imx51.img [11:28] http://releases.ubuntu.com/9.10/MD5SUMS [11:28] hmm seems right [11:28] whoops paste error [11:29] anyone uses this without a serial console attached ;)? [11:29] ok got another SD out of the bag from same brand though ;) [11:30] i never use a serial console if i dont have to [11:30] the other option would be to kill the windows CE sandisk thing that was delivered ;) [11:30] and i only have to when i create new bootloader setups [11:30] windows CE ? [11:30] yes [11:30] ugh [11:30] well, dd it off the SD [11:30] two SD things where there: linux ... and windows CE [11:30] hey... there even is a license ;) [11:30] and overwrite the SD then [11:31] you can always dd it back [11:31] yeah [11:31] and order some sandisk cards ;) [11:31] if thats the reason [11:31] you dont have a mediamarkt around in hamburg ? [11:31] i have [11:31] they usually have multiple brands [11:31] also saturn ;) [11:32] they too [11:32] do they have usb to serial adapters ;)? [11:32] just buy three different ones [11:32] hehe [11:32] sure [11:32] sure ... i wouldnt say that for saturn [11:32] they really have close to nothing [11:32] nothing == everything that is too low level for main stream customer is missing [11:33] wow, the kassel saturn seems to be better then [11:33] asac: That's just a call to change the needs of the "main stream consumer" :) [11:34] heh [11:34] yeah, just buy 10000 SD cards and you will change them [11:35] 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) [11:36] you mean saturn would give away the cards for free to students ? [11:36] * ogra wonders how japan does business these days *g* [11:36] No, but the students would pay rather than the instigator. [11:36] ah [11:36] hah [11:36] the other SD card worked ;) [11:37] ubuntu X is starting ;) [11:37] Saturn *might* give away cards, if it was part of some special program: I don't know enough about German tax provisions. [11:37] \o/ [11:37] saturn is a rip-of-company ... say that they sell stuff cheap, but then you see the cheapest wireless router is 60 EUR [11:37] while i get one at my dealer of same brand for 39 EUR [11:37] yeah [11:38] asac, congrats ! [11:38] asac, install should take up to 1h [11:38] depending on the speed of your USB device [11:39] (or more I have found) [11:39] * ogra takes a break [11:58] hmm found out that the image kernel doesnt like my usb mass storage thing [11:59] on x86 is fine with karmic kernel === ian_brasil is now known as ian_brasil_afk === bjf-afk is now known as bjf [16:24] dmart: you said initially you have some ideas about the mksquashfs issue? current bt is: http://paste.ubuntu.com/337345/ === bjf is now known as ___bjf [16:36] dmart: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3 [16:39] dmart: so you need to download the .deb files and force install them because the codec package (just something dloaded) isnt there for chromium [16:40] of course all depends but chromium...-ffmpeg should get installed ;) [16:41] did you build that yesterday ? [16:42] right [16:42] let me check if that worked ;) [16:42] nope. failied to build [16:42] https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1384064 [16:43] worked everywhere else, but arm as it seems [16:43] ogra: is that the same error we get on ffmpeg in archive? [16:43] fno-signed-zeros -c -o libavformat/oggparseogm.o libavformat/oggparseogm.c [16:43] In file included from libavformat/oggparseogm.c:27: [16:43] ./libavcodec/get_bits.h:93:2: error: invalid preprocessing directive #warn [16:43] hmm [16:45] to be honest i havent looked at ffmprg yet [16:45] *ffmpeg [16:45] post A1 stuff :) [16:45] sure [16:46] 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 ;) [16:46] yeah [16:46] ogra: upgrading karmic image yields a Read-only file system error [16:47] when flashing kernel [16:47] is that known? [16:47] is mounted rw from what i can see [16:47] upgrading to what ? [16:47] ogra: just upgrading to karmic-security/-updates [16:47] just security fixes ? [16:47] yes [16:47] 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 [16:47] dmart, you have a pegatron nettop, right ? [16:48] dmart: http://paste.ubuntu.com/337345/ thats the backtrace without symbols [16:48] dmart, just create a lucid chroot ... chroot into it and run mksquashfs on any dir you like [16:48] it will fail with SIGILL [16:48] in some mutex stuff. though i doubt that pthread mutex can be broken completely [16:49] but ... we can something similar for dchroot on the porter box which is also a pegatron afaik [16:49] but not a sigill ;) [16:49] dchroot -c lucid [16:49] dchroot: pthread_mutex_lock.c:87: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. [16:49] Aborted [16:51] is your call over ? [16:51] yes [16:54] asac, can you throw me a link to the Chromium build and logs? [16:54] dmart: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+packages [16:54] dmart: you can access the build logs there [16:54] https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1377663 [16:54] dmart: ^^ [16:55] dmart: the .debs are on the +packages page [16:55] just the unfold the topmost build [16:55] Oh, right. "mozilla" confused me ;) [16:55] sorry [16:55] was the only place i had spare that has native ppa capabilities ;) [16:55] will get a better place [16:56] Cheers [17:03] ogra: where is this "Flashing kernel..." done? [17:03] FIS create failed. [17:03] create ? [17:03] what are you doing there ? [17:04] triggers update-initramfs [17:04] ogra: i dist-upgraded ... kernel wants to update initramfs etc. [17:04] update-initramfs calls flash-kernel [17:04] then it says "flashing kernel" [17:04] yeah [17:04] i want to add debug statement to see which device it tries to write to [17:04] but found it in triggers now [17:04] and flash-kernel replaces the initramfs in the existing fis [17:04] the device is defined in /etc/flash-kernel.conf [17:05] as well as the offset and lenght [17:05] hmm its wrong [17:05] i still have the sd card with installer in the first slot [17:05] is that wrong? [17:05] the install SD card didnt boot on its own [17:05] the SD turns into a boot floppy [17:05] after install [17:06] asac, ogra: I tried running mksquashfs /etc etc.squash --- didn't crash for me. Do I need a heavier test? [17:06] it needs to stay where it was when you installed [17:06] dmart: it only happens on pegatron lucid [17:06] are you trying that? [17:06] afaik it doesnt happen on babbage etc. [17:06] ogra: right. so the flash-kernel.conf is wrong ... unless thats the define it is supposed to be flashed to [17:06] dmart, you need a lucid chroot and be chrooted and do all that on a nettop [17:06] s/define/device/ [17:06] asac, what does it contain ? [17:07] it contains mmm.*0 ... but the actual SD card the main install is on is mm.*1 [17:07] fis_dev=/dev/mmcblk0 [17:07] fis_offset_hex=0x40000 [17:07] fis_size_hex="0x1F000" [17:07] yes thats what i have [17:07] thats the default [17:07] ogra, I'm doing that except in a Babbage2.0 board... I'll try one of the nettops. [17:07] but the actual install is on mmcblk1 [17:07] blk0 is the boot floppy thing ... which is read-only as it seems [17:07] asac, not your bootloader [17:07] yeah [17:07] so 0 is correct i guess [17:08] wonder if all is lost now ;) [17:08] yes [17:08] no [17:08] it just doesnt use the new initramfs [17:08] did you lock the card physically ? [17:08] right. thats why i want to shutdown now ... to check [17:08] or is it safe to remove it while running ;)? [17:09] you can remove the "bootfloppy" any time you dont boot or run flash-kernel [17:09] oh ok [17:09] * ogra needs to go for dinner ... [17:09] back soon [17:09] hmm removing and adding worked [17:10] odd [17:10] let me try the trigger again [17:10] ok cool [17:10] the issue just flew away ;) [17:10] * asac reboots and hopes that the mass storage thing is fixed in latest kernel [17:29] asac, ogra: OK, I see the mksquashfs bug now. Weeeird, I wonder what's different from the other platforms :O [17:46] dmart: how sure are we that the mutex stuff in libc is correctly ported? [17:46] i couldnt even find the arm specific code for that on quick glance ... but then i looked in redhat libc - which isnt what we use anyway [17:50] hmm ... i constantly get complains about expired password === gletelli__ is now known as gletelli [18:39] ogra, lool: ping [18:40] dmart, yup [18:40] Hi there... looks like I may have some info on the mksquashfs problem [18:40] ah, cool [18:41] mksquashfs contains a misaligned multi-register store instruction [18:41] misaligned in which way ? [18:41] i mean it works with the right kernel [18:42] STM with base register not a multiple of 4 (which might itself be due to a bug) [18:42] hmm [18:42] The kernel traps and emulates certain kinds of misaligned memory access, but the emulation for Thumb is not complete in 2.6.28 [18:42] i find it significant that it only happens with the pegatron kernel [18:43] ah [18:43] So for "proper" karmic, it works [18:43] right [18:43] I think NCommander's error in GCC may have been similar [18:43] well, he used a karmic kernel iirc [18:43] but lucid userspace [18:44] Why is it generated in the first place though, the toolchain should avoid it if it can right? [18:44] (misaligned stores, that is) [18:45] Yeah, we'd have to check what NCommander was doing. [18:46] The compiler should not generate misaligned stores, so either it's a compiler code gen bug, or a pointer is getting corrupted due to a C bug [18:46] ojn, the issue is with a 2.6.28 kernel that was compiled for ARMv5 and userspace tools that are v7, the userspce toold for squashfs are very closely connected to the kernel module [18:47] ogra: Right, but like dmart says gcc should avoid operations with performance penalties such as trapped and emulated loads/stores. [18:47] yeah, iondeed [18:47] The SIGILL goes away with -O0 [18:48] ah [18:48] good pointer [18:49] cool [18:49] When you do something like int *p; *p = x; GCC knows ints are aligned and so can assume that p is properly aligned, but if p gets corrupted, this assumption may break [18:49] yeah [19:37] ogra: is the hardware clock supposed to work? [19:37] for bbg? [19:37] yes [19:37] seems mine always goes back to 1970 ... which then causes [19:37] password for auto login to expire [19:37] note that the battery needs about 8h [19:37] and autologin breaking [19:37] ah [19:38] hmm [19:38] wait until tomorrow, if it still doesnt work thats a 3.0 issue [19:38] kk [19:38] we had issues on 2.5 but we solved them# [19:40] we solved them? [19:40] so its not battery related? [19:40] hmm [19:40] i remember something sourrounding hwclock by scott [19:40] there were battery related and non battery related issues [19:41] he basically broke my laptop to always bail out when it got a power off shutdown [19:41] the battery related ones pointed out that you need to run the board for 8h first [19:41] we solved the non battery related ones though [19:41] ok. so really running or just with power plugged in? [19:41] its the kernel, not the hwclock userspce proggy [19:42] it can well be that the 3.0 hwclock driver isnt fully functional [19:42] why do we ask for password renewal at all? [19:42] since we didnt have 3.0 boards to even test [19:42] how can i turn that off for now? is that a gdm config? [19:42] i didnt even change the clock. but still it resets to time=0 all the time [19:42] and logging in becomes highly painful ;) [19:42] how do you restart ? [19:42] even sudo [19:43] do you power off the board completely ? [19:43] this time i restarted as pusing the installer button [19:43] previously i also powered off completely [19:43] and are you sure the clock is at 1970 ? [19:43] yes. 1st jan 1970 [19:43] we had an issue where the board set the clock to something like 1939 ... [19:43] 2:38am now [19:43] (probably 1:38 sincei started it) [19:43] which nohting could cope with (pre epoch) [19:43] hmm [19:44] let me check on terminal. i only look at gnome clock atm [19:44] ogra: it had problems with passwords too [19:44] yes its 1st jan 1970 [19:44] and gets reset on reboot [19:44] yup, sounds right [19:44] so not even full power cycle [19:44] is needed [19:44] one thing to make sure the clock is right is to use ethernet :) [19:44] JamieBennett: ogra says it needs to be 8h power on [19:44] ntpdate runs on ifup [19:44] though i cannot see how a quick power off needs a full 8h [19:44] ;) [19:45] its just for a minute or two off [19:45] but the battery doent have the needed voltage yet [19:45] hmm. i didnt brin gup network for install this time [19:45] asac: mine has been plugged in for more than 8hrs, whats the betting it keeps its time? [19:45] it needs to be at 2.6V or some such [19:45] JamieBennett: my guess is that it will get reset ;) [19:45] :) [19:45] ogra might want to bet against ;) [19:46] well, in any case ntpdate fixes it ... so ethernet on boot helps a lot [19:46] or just set the time ;) [19:46] no, i wouldnt bet on anything for a board i have never seen :) [19:46] * JamieBennett goes to check [19:46] i can only talk about B2.5 [19:46] the password is too simple thing is also just annoying ;) [19:46] ogra: you saw a pic ;) [19:46] and i know we had massive issues with the hwclock driver during karmic ... but for the 2.5 they were solved [19:47] asac, there was no arrow pointing to the RTC chip on it ! [19:47] how am i supposed to know it works without that ! [19:48] * ogra needs arrows on pics [19:48] its super annoying [19:48] i have to change password everytime i run sudo [19:48] plug in ethernet [19:49] i am online ;) [19:49] oh right [19:49] thats the reason why [19:49] i just got beamed to present ;) [19:49] how can i disable this shitty password expiry feature ;)? [19:49] * asac checks passwd [19:49] its a bug in shadow [19:50] and i'm sure it was fixed once so it doesnt ask for passwords if it recognizes that timestamp [19:50] its a bug that we have it enabled at all? [19:50] probably the patch got lost [19:50] yes imho [19:50] talk to colin, i think he applied the patch back sometime between hardy and jaunty [19:51] (it was my bug actually, but i didnt do the fix) [19:51] lets see if setting --maxdays=0 helps [19:53] just make sure to have the ethernet cable plugged in on boot :) [19:54] hmm [19:54] let me setup nm to startup wifi on boot [19:54] eth is just too spartanic ;) [19:55] heh [19:55] its reliable ... [19:55] no microwaves can interfere [20:28] my microwave fried itself a year ago ... never got a new one ;) [20:29] but how do you melt chocolate then? [20:48] bain-marie [20:48] asac, did you copy the codecs just yet? [20:53] fta: not yet. shall i? [20:53] last time i looked they were 15h old [20:54] that's ok, it's the one [20:54] not sure if those are the bits i should give a spin [20:54] * asac checks [20:55] 18h [20:55] fta: chromium-codecs-ffmpeg - 0.5+svn20091208r34028-0ubuntu1~ucd1 [20:55] please confirm so i dont waste built time ;) [20:55] yes, correct [20:56] ok let me copy existing binaries so it doesnt steal amd64 time [20:56] ok copied [20:56] and failed to copy binaries ;) [20:57] hmmm ... instantly got a buildd [20:57] odd scheduling [20:57] https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1386748 === asac_ is now known as asac [21:38] dyfet: did you manage to get the strace and backtrace for chromium? [21:38] would be really helpful ;) [21:44] fta: no luck: http://launchpadlibrarian.net/36600814/buildlog_ubuntu-lucid-armel.chromium-codecs-ffmpeg_0.5%2Bsvn20091208r34028-0ubuntu1~ucd1_FAILEDTOBUILD.txt.gz [22:04] asac, hm, grr, thanks, will have a look [22:05] fighting to setup a beta channel ppa right now [22:12] asac: it died in the strace, somewhere on a poll, just froze, long before any window opened, so it did not seem to go through the actual crash [22:13] but I can send you that file right now [22:15] plese not in my email ;) [22:15] fta: i can fix it by adding -fPIC [22:15] just tried [22:15] by accing $(PIC) to CFLAGS in common.mak actually [22:15] by adding [22:15] it wasnt that long before strace...stopped...but if you have a new build, I could try that right now [22:16] not sure if that would break anything somewhere ese [22:16] dyfet: we have a lucid build. have you been trying that? [22:16] dyfet: without strace ... do you see it start? [22:16] dyfet: i assume you directed the strace output in a file? [22:16] no on karmic. Without strace, it starts, opens the main window, then has the pure virtual function call error and dies [22:17] with strace, it just "stops" on a poll call it cannot seem to print out completely... [22:17] asac, with the sumo change, i will no longer use the upstream build system (autoconf) but use the gyp file provided by chromium, so it has their own optimizations [22:18] hmm [22:18] fta: when is sumo change? [22:19] asac, not today [22:19] close, far ? [22:26] not much, i have http://codereview.chromium.org/463050/show and i need http://code.google.com/p/gyp/issues/detail?id=119 [22:27] the 1st just landed, the 2nd is in progress [23:09] fta: also: libavcodec/get_bits.h:93:2: warning: #warning TODO - secure this against read overrun [23:09] libavcodec/aac.c: In function 'aac_decode_frame': [23:09] libavcodec/aac.c:1634: error: 'GetBitContext' has no member named 'index' [23:10] after fPIC [23:10] that seems to be some code path that is usually not used ... :/ [23:10] guess the gyp thing might help here [23:10] the TODO is from a patch [23:10] yeah [23:10] that patch is probably bogus [23:10] where did you get that from? [23:11] hmm which patch ;) [23:11] i thought i found it at some point. now i dont see it [23:12] ./patches/ugly/17_get_bits_overrun.patch [23:12] dont see that this patch introduces that issue [23:12] its really that ALT_BITSTREAM_READER [23:13] is probably set usually [23:13] but here we have some other reader [23:14] ah ... so my patch about right [23:14] they do it for other ->index refereces too [23:17] dyfet: so did you direct the output of strace to a file rather than to stdout/err? [23:22] Yes [23:23] ok and that stalled still? [23:23] Yes [23:23] hmm. maybe try just strace -eopen -f ... [23:23] that doesnt dump that many data [23:23] and the gdb/bt ? [23:24] also to no success? [23:24] dyfet: ? [23:24] that I can still do also [23:24] I thought you had asked me not too :) [23:25] no. i wanted strace first ;) [23:25] but since that failed we reach for the other straw ;) [23:25] anyway [23:26] dyfet: we want to understand whats going on ... sudo apt-get install -f ... what does that suggest you? [23:26] only complaining aobut the ffmpeg things missing? [23:27] Yes. They were the chromium version of ffmpeg it was complaining about [23:27] only that? [23:27] sure you have everything else? [23:28] about to check [23:29] Package chromium-codecs-ffmpeg is not installed. [23:29] Package chromium-codecs-ffmpeg-nonfree is not installed. [23:31] and strace so far is still not being very friendly... [23:34] I can run it but if I go anywhere, I get a sad face and a pure virtual method called. But if I use strace, it never even comes up to an initial screen... [23:34] I am adding dbg package now [23:37] asac: its taking its time coming up with gdb... [23:38] yeah [23:45] asac: https://pastebin.canonical.com/25504/ [23:45] S32A_Opaque_BlitRow32_neon [23:45] neon [23:45] doesnt work i guess [23:45] fta: ^^ ... does the armv7 switch enable neon? [23:46] nope. doesnt seem to... [23:46] looked in chromium sure? [23:47] I did not snag your sources at the time, only the debs... [23:47] asac, add -mfpu=neon [23:49] whats the current default? [23:49] hmm seems that is bogus i guess [23:50] armv7==1 sets the following: [23:50] '-march=armv7-a', [23:50] '-mtune=cortex-a8', [23:50] '-mfpu=neon', [23:50] '-mfloat-abi=softfp', [23:50] yes. i think =neon is bad [23:51] fta: i see that ffmpeg in chromium source already has a gyp [23:51] so its already done there? [23:51] yes [23:52] ok .... so we need to remove the =neon somewhere [23:52] seems there is no way around a quick and dirty patch [23:52] well there is, but not quickly :) [23:52] -march=armv7-a -mthumb -mfpu=vfpv3-d16 -mfloat-abi=softfp -Wa,-mimplicit-it=thumb [23:52] build/common.gypi but you might want to file a bug and explain why it's bad, i know nothing about =neon [23:52] thats what we use by default [23:53] -Wa,-mimplicit-it=thumb is set when arm_thumb == 1 [23:53] neon is not available on all armv7 [23:53] oh [23:53] i actually think we just want what we have set by default [23:54] maybe we should just build without armv7 [23:54] let me kill the build and try that over night [23:54] yay [23:54] ffmpeg builds now [23:55] though there seem to be switches somewhere that made it fail without armv7 [23:55] imo the CFLAGS should get decoupled from that switch somehow [23:59] fta: so i added CFLAGS = -fPIC -DPIC to rules (for armel most likely - not sure why there only) [23:59] and i added this patch: [23:59] patches/ugly/51_get_aac_build_for_arm.patch: [23:59] http://pastebin.com/f65476f12