| ADcomp | hello .. I can't run X with omapfb :/ some help ? http://paste.ubuntu.com/355265/ | 00:25 |
|---|---|---|
| rcn-ee | ADcomp, i think omapfb requires running a dss2 enabled kernel: "Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or directory" Although i've never run it on anything else either... | 00:28 |
| ADcomp | hi rcn-ee .. I finally running karmic on my new board :) | 00:30 |
| ADcomp | but I don't compile new kernel from your tree yet .. | 00:30 |
| rcn-ee | hi ADcomp, i saw that.. (i was going to ask you about that too..) | 00:30 |
| rcn-ee | (i'd like to get all omap3 based boards working in that tree) | 00:31 |
| ADcomp | I don't have a working OE setup for compiling kernel .. | 00:33 |
| rcn-ee | omapfb isn't really a driver per say, (doesn't interact with the SGX engine) it just enables some features... http://git.debian.org/?p=collab-maint/xf86-video-omapfb.git;a=tree;f=src;h=45b69d636f30e09cfdc817c95856297986dd8883;hb=HEAD | 00:33 |
| ADcomp | btw touchscreen doesn't work .. | 00:35 |
| rcn-ee | probably isn't enabled in the defconfig, the original beagleboard doesn't have one.. might even have to patch for it.. | 00:37 |
| ADcomp | I don't think so .. It works fine with angstrom with same kernel | 00:37 |
| rcn-ee | there's a lot of kernels out there, (i just put two more out yesterday) which Angstrom works, and which one fails... | 00:39 |
| ADcomp | I think it's related to HAL | 00:39 |
| ADcomp | (EE) ADS7846 Touchscreen Unable to query/initialize Synaptics hardware. | 00:39 |
| ADcomp | (EE) PreInit failed for input device "ADS7846 Touchscreen" | 00:39 |
| rcn-ee | ADcomp, looking thru my tree's i've never enabled CONFIG_TOUCHSCREEN_ADS7846 which is what is needed.. | 00:44 |
| ADcomp | it's enabled in my config .. | 00:45 |
| ADcomp | CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y | 00:46 |
| rcn-ee | sure, but that's why it doesn't work with my kernels or Angstrom's... | 00:46 |
| rcn-ee | if you build my 2.6-stable, add this to yesterday's patch http://pastebin.com/f1fe738b3 | 00:48 |
| ADcomp | do you think I can use this to setup OE and compil kernel ? http://wiki.openembedded.net/index.php/Getting_started | 00:50 |
| rcn-ee | that's old, use http://www.angstrom-distribution.org/building-angstrom | 00:52 |
| ADcomp | ok .. ty. what about MACHINE ? beagleboard ? | 00:53 |
| rcn-ee | btw, that ADS7846 is a spi device, so arch/arm/mach-omap2/board-omap3"board".c will need to be patched.. spi devices need to be registerd... | 00:54 |
| rcn-ee | note sure... it's a beagle, but at the same time it's different.. all machines are listed in tree/conf/machine.... doesn't look like there is a tao... | 00:56 |
| ADcomp | no .. but I can maybe ask to technexion for thunder.conf they use to build angstrom ? | 00:58 |
| rcn-ee | ask them for an Angstrom (OE) overlay, a lot of companies are doing that now days. (specially for omap3 boards) | 00:59 |
| ADcomp | btw , this board is running fine under karmic .. X + Openbox :) | 01:05 |
| === martinb is now known as Martyn | ||
| === asac_ is now known as asac | ||
| lool | Hmm trying to run rootstock, I get mount -t devpts devpts /dev/pts | 11:13 |
| lool | mount: mount point /dev/pts does not exist | 11:14 |
| ogra | lool, hmm, i thought there is a mkdir -p in the code | 11:46 |
| lool | ogra: I dont see any | 11:47 |
| lool | This is in the installer BTW | 11:47 |
| lool | I tried moving udevd --daemon up one line, and get /bin/installer: line 14: udevd: command not found | 11:48 |
| ogra | hmm, the mount should probably run after udevd starts | 11:48 |
| lool | I suspect ubuntu-minimal isn't pulled | 11:48 |
| ogra | yeah, smells like | 11:48 |
| ogra | since you asked me to drop the hardcoding for it ;) | 11:48 |
| lool | It says the default is ubuntu-minimal | 11:48 |
| ogra | it should | 11:48 |
| ogra | unless debootstrap has some out-of-sync'ness | 11:49 |
| lool | debootstrap will use priorities to select packages | 11:49 |
| lool | I'm trying with an explicit ubuntu-minimal now | 11:50 |
| lool | same thing | 11:52 |
| lool | udev was certainly downloaded | 11:53 |
| lool | I think it's broken for vms; not sure why | 11:55 |
| lool | second stage isn't set | 11:57 |
| lool | The first failure is actually: | 11:59 |
| lool | + echo chroot: cannot run command `debootstrap/debootstrap': No such file or directory | 11:59 |
| lool | rcn-ee: Thanks for testing the --script patch; I tested it myself now and fixed a couple of issues with it | 13:28 |
| lool | rcn-ee: Pushed a new branch and requested a new merge; http://paste.ubuntu.com/355487/ is the diff of the interesting changes, branch is lp:~lool/project-rootstock/user-script | 13:29 |
| rcn-ee | thanks lool, just read the email actually.. ;) | 13:33 |
| ogra | cooloney, they have to fix that | 14:01 |
| ogra | they were in the crowd shouting for v7, neon and thumb2 too :) so they should make sure to have their code working with a recent compiler :P | 14:02 |
| cooloney | ogra: yeah, understand | 14:02 |
| ogra | asac, something for tonights call i guess | 14:02 |
| asac | cooloney: ericm_: you asked if we have cross compilers availble | 14:02 |
| ogra | ericm_, i thought lool prepared a ppa with cross tolls based on our compiler | 14:02 |
| asac | i dont know ... can you explain to me where you get those from? | 14:03 |
| asac | i thought you hvae to do them on your own | 14:03 |
| cooloney | asac: yeah, cross compiler 4.4 | 14:03 |
| ogra | lool, ^^^ is that gcc 4.4 ? | 14:03 |
| ogra | asac, you use codesourcery | 14:03 |
| cooloney | asac: normally, we get the binary gcc from codesourcery | 14:03 |
| ogra | but they are only on 4.3 iirc | 14:03 |
| cooloney | asac: and i think the latest one is 4.3 | 14:03 |
| cooloney | asac: but i am searching on their site now | 14:03 |
| asac | ah. i thought you have to do that on your own ... is there a good wiki explaining what you do? | 14:03 |
| ogra | amitk's blog :) | 14:04 |
| lool | I have cross compilers in my ppa | 14:04 |
| lool | They are suitable for the kernel, but not for userspace due to a bug | 14:04 |
| ogra | ericm_, cooloney, ^^^ | 14:04 |
| ogra | so use these | 14:04 |
| ericm_ | ogra, lool, thanks | 14:04 |
| lool | We decided we wont go this way though, so I'm not investing in fixing these right now | 14:04 |
| ericm_ | lool, you have a link? | 14:04 |
| lool | ppa:lool/ppa ? | 14:04 |
| ericm_ | lool, ok | 14:05 |
| ogra | lool, as long as the kernel can be built ... | 14:05 |
| cooloney | http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite | 14:05 |
| cooloney | i think we can try this 4.4 cross compiler from codesourcery now | 14:05 |
| lool | For the kernel, you might have to remove the libgcc linkage which I think should be dropped upstream; I think it's a terribly old construct | 14:05 |
| lool | Yes, codesourcery has 4.4 now | 14:05 |
| amitk | I would be very conservative about updating to a new compiler | 14:06 |
| amitk | they are almost always buggy | 14:06 |
| cooloney | amitk: got you guys | 14:06 |
| * ogra takes a break | 14:06 | |
| ericm_ | I think I've already been using the latest codesourcery gcc | 14:06 |
| ericm_ | might be a good chance to give marvell toolchain a try | 14:07 |
| persia | Native builds aren't that bad. Try them! You might find the results interesting, or even useful :) | 14:08 |
| ericm_ | persia, ok - will try | 14:08 |
| * ericm_ needs some sleep | 14:09 | |
| === ericm_ is now known as ericm-Zzz | ||
| cooloney | ericm-Zzz: good night | 14:11 |
| asac | dmart: hi | 14:40 |
| dmart | Hi | 14:40 |
| * asac gets the thumb2 link | 14:40 | |
| asac | https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList | 14:41 |
| asac | dmart: so can we clearly prioritize by what type of issue we have? | 14:42 |
| asac | e.g. swp > ldr > mov > ldrex (or some other order) | 14:43 |
| dmart | Maybe rather mov > (swp,ldrex) > ldr | 14:43 |
| dmart | I need to talk to the kernel guys, but we have a patch to emulate SWP in the kernel. This is slow, but it avoids us having broken packages and gives us a chance to migrate | 14:44 |
| dmart | ldrex packages may not be SMP-safe | 14:44 |
| dmart | ldr packages my just "perform a bit better" if built in ARM | 14:45 |
| dmart | ...so I separated them out and we can consider them low priority | 14:45 |
| asac | ok i added a few columns to the table | 14:47 |
| asac | which we can later use to sort: | 14:47 |
| asac | rdepends (number of packages that depend on it) | 14:47 |
| asac | section (base, standard, optional) | 14:47 |
| asac | and comments -> like for apex i added that its a none issue because its armv5 bootloader | 14:47 |
| ogra | we do use sections ? | 14:47 |
| asac | well | 14:48 |
| asac | its good to identify if something is part of the base system etc. | 14:48 |
| dmart | I found a few packages in main which have no rdepends in main... it might be worth tracking thta | 14:48 |
| asac | like binutils: is probably more important than some app | 14:48 |
| ogra | indeed | 14:48 |
| asac | dmart: those packages usually automatically get demoted . we have a component-mismatches | 14:49 |
| ogra | but i didnt know these sections actually mean anything in ubuntu | 14:49 |
| asac | url | 14:49 |
| asac | ogra: have that at hand? | 14:49 |
| ogra | i thought they are debian only | 14:49 |
| asac | ogra: they dont mean anything, but they give indication for the prioritization we are doing | 14:49 |
| asac | :) | 14:49 |
| asac | aka they still mean something, because they mean something in debian | 14:50 |
| ogra | http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 14:50 |
| ogra | ^^^ | 14:50 |
| asac | dmart: thx | 14:51 |
| asac | ooops | 14:51 |
| asac | ogra: thx | 14:51 |
| dmart | I don't mind :) | 14:51 |
| asac | dmart: that page above is regularly reviewed. stuff that has no rdepends in main should get demoted | 14:51 |
| dmart | OK, maybe we don't need to worry too much about that then | 14:51 |
| asac | look for " Source and binary demotions to universe | 14:51 |
| asac | " | 14:51 |
| asac | right | 14:51 |
| asac | dmart: you said in your mail you wanted to do something ... and before that we shouldnt remove anything from that list. did that happen? | 14:52 |
| asac | i dont mind to keep everything in there | 14:52 |
| dmart | If things get deleted, we don't track _why_ they were deleted... but we could move them to a separate table, with a brief note about why | 14:53 |
| dmart | That was my only concern | 14:53 |
| asac | ah ok. thats ok then. i think the comment column is good enough for now | 14:53 |
| asac | right | 14:53 |
| dmart | I think the first job is to do a fairly quick review through the whole list, getting the info for your suggested colums, and quickly assessing the impact of the source code issues | 14:53 |
| dmart | Maybe it would be easiest just to chop the list for main into a few pieces and try that? Do you know who would be available to review? | 14:54 |
| asac | right. so the mechanic stuff i can get someone doing (e.g. fill in the number of rdpends and then sort the wiki page | 14:54 |
| dmart | Yep, that should be fairly straightforward and quick to do | 14:54 |
| * ogra is happy to report that the imx51 kernel in the archive works well | 14:55 | |
| dmart | ogra: Is that 2.6.31.602.3? | 14:56 |
| ogra | yep, the one uploaded yesterday | 14:56 |
| dmart | Ah... I have a board here running it too | 14:56 |
| dmart | seems OK | 14:56 |
| asac | dmart: do you think it would take longer than 1h or so if we go through the list together here to add tne initial comments? that would ensure we make the progress and we dont have to wait on someone ;) | 14:56 |
| ogra | its aweesome | 14:56 |
| dmart | asac: No, that sounds like a good first step | 14:56 |
| asac | then i will get someone filling the sorting columns and we can distribute the real porting tasks to individuals based on that | 14:56 |
| ogra | way better than any first-release we ever had | 14:57 |
| asac | ok lets get started then ;) | 14:57 |
| asac | #startmeeting ;) | 14:57 |
| ogra | haha | 14:57 |
| asac | binutils | 14:57 |
| dmart | ? | 14:57 |
| asac | thats the first package in the table ;) | 14:57 |
| dmart | apex is first (though probably ignorable) | 14:58 |
| asac | let me open the filtered lists | 14:58 |
| asac | dmart: yes, already filled in the comment ;) | 14:58 |
| * dmart hits refresh | 14:58 | |
| dmart | ah | 14:58 |
| dmart | Might it be better to split the list and work offline? | 14:59 |
| asac | if that works for you. i just think its going to take longer that way ;) | 14:59 |
| asac | unless one takes all the workload | 14:59 |
| dmart | Maybe | 15:00 |
| asac | let me open the filtered files ... then i hope it will go quicker | 15:00 |
| dmart | All binutils and gcc packages: I suggest to ignore. This is dealt with separately with doko etc. | 15:00 |
| asac | right | 15:01 |
| asac | i can fill in the comments we find | 15:01 |
| asac | so we dont get conflicts | 15:02 |
| asac | dmart: eglibc too i guess? | 15:02 |
| dmart | Actually, gcc-4.4 has a problem with swp in the boehm-gc code... I'll try and find the lp bug tracking this for openjdk | 15:02 |
| dmart | Hmmm, no lp bug. Can you add a note on that? | 15:03 |
| asac | yes | 15:05 |
| asac | added that to comments | 15:05 |
| dmart | boost1.38 and boost1.40 both contain spinlocks and atomics code using swp | 15:07 |
| asac | ok finally have all the filtered files | 15:07 |
| asac | ok | 15:08 |
| asac | noted | 15:08 |
| asac | cacao-source -> | 15:08 |
| dmart | How to I find out the rdepends for a source package? | 15:08 |
| dmart | cacao-source has the same boehm-gc problem as in gcc-4.4, and also uses swp in a couple of other places. | 15:09 |
| asac | ldrex seem to be used in armv6 header there | 15:09 |
| asac | dmart: hmm. you have to check rdpeends for the binaries | 15:09 |
| dmart | Oh, OK | 15:09 |
| asac | one could write a script for that | 15:09 |
| dmart | I was hoping you had one :) | 15:09 |
| asac | or are you looking for build-rdepends? | 15:09 |
| dmart | Not really, should we? | 15:10 |
| asac | dmart: no. but i will get someone else fillin the rdepends ;) | 15:10 |
| dmart | OK | 15:10 |
| asac | dmart: that would be useful if we have issues in inline funcs in headers | 15:10 |
| asac | but i hope not ;) | 15:10 |
| dmart | Do you want to move this discussion to another channel? This is a lot of spam for people who aren't interested | 15:11 |
| asac | dmart: i think its ok this channel quite quiet ... if you prefer we can go somewhere else | 15:11 |
| persia | apt-cache rdepends ${package} can be useful | 15:11 |
| dmart | asac: OK, stay here for now them | 15:12 |
| persia | But one has to check the results, as it also lists Conflicts and Breaks, etc. | 15:12 |
| asac | dmart: unless someone complains ;) | 15:12 |
| asac | so cln | 15:12 |
| dmart | aptitude is also useful | 15:12 |
| asac | grep cln * | pastebinit | 15:12 |
| asac | http://pastebin.com/f33d714b6 | 15:12 |
| dmart | cacao-source: | 15:13 |
| dmart | ... is a JIT and it likely to make a lot of assumptions about ARM versus Thumb-2... some real work is probably needed for this. We should check with doko on priority for this one | 15:13 |
| asac | dmart: yes. i will add a comment about jit needing work | 15:14 |
| dmart | cln -> I already had a brief look. This is some kind of arbitrary precision library. The seems to be some run-time compilation for ARM, but comments in debian/rules say it's broken and appear to disable it anyway. | 15:15 |
| dmart | I think there are no rdepends in main for this one? | 15:16 |
| asac | check apt-cache rdepends libcnl6 | 15:17 |
| asac | there should be a bunch | 15:17 |
| asac | oh in main | 15:17 |
| asac | yes the lib is in binary demotions | 15:17 |
| asac | http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 15:17 |
| asac | but probably "pi" is used | 15:17 |
| asac | hmm. just by the lib from what i can tell | 15:18 |
| dmart | You can check this with a limit like ~smain~Dlibcln in aptitude | 15:18 |
| asac | dmart: so based on the grep those movs in cln needs to be fixed? | 15:18 |
| dmart | pi is a demo program which computes pi :) | 15:18 |
| dmart | In debian/rules it says "CLN's assembler support is not working properly ..." and adds -DNO_ASM. I did an offline build--- it builds in Thumb-2 without errors and the testsuite passes OK, so I think the assembler is not used. | 15:20 |
| asac | ok. great. | 15:20 |
| asac | noted | 15:20 |
| dmart | OK | 15:20 |
| asac | coreutils | 15:20 |
| asac | http://pastebin.com/f5115c6cb | 15:21 |
| asac | seems just one swp | 15:21 |
| asac | in a test | 15:21 |
| * asac checks build log if make check is run | 15:22 | |
| dmart | I think that's a false positive... doesn't look like assembler to em | 15:22 |
| asac | yes | 15:23 |
| asac | that test passes | 15:23 |
| asac | PASS: misc/printf-cov | 15:23 |
| asac | on armel | 15:23 |
| asac | http://launchpadlibrarian.net/33115198/buildlog_ubuntu-karmic-armel.coreutils_7.4-2ubuntu1_FULLYBUILT.txt.gz | 15:23 |
| asac | but that was karmic | 15:23 |
| asac | e.g. needs to get respun | 15:23 |
| dmart | I can't see any reason why printf would have atomics anyway | 15:23 |
| asac | ok db | 15:24 |
| asac | i thinnk i fixed db4.2 | 15:24 |
| asac | at least i added gcc atomics there to fix a build failure | 15:24 |
| asac | and the newer db versions seem to use pthread mutexes | 15:25 |
| asac | like db4.6 doesnt use that code anymore iirc | 15:25 |
| dmart | OK... db (4.8), db4.2 and db4.6 all seem to have the same code; can we apply the same patch to them all? | 15:25 |
| asac | dmart: yes, we probably can, but only 4.2 failed on that code, which is why i didnt do that | 15:26 |
| asac | anyway, we might want to do that anyway, and hope it flows upstream at some point | 15:26 |
| asac | noted | 15:27 |
| asac | djvulibre | 15:27 |
| dmart | Might be a good idea. Code involving swp will generally work (and pass tests) on our current platforms (except maybe on dove under stress?) ... this is more for avoiding future problems. | 15:27 |
| asac | search-arm-mov.filt: ./djvulibre-3.5.22/libdjvu/GThreads.cpp: "mov%?\t%|pc, %1" // branch to address %1 | 15:27 |
| asac | dmart: hmm ... strange that it failed to build for db4.2 though | 15:27 |
| asac | anyway, lets continue | 15:27 |
| asac | i noted that we should put the patch everywhere | 15:28 |
| dmart | db* - should we flag this up for SMP safety, or are you confident the memory barriers implied by the GCC intrinsics are adequate? | 15:28 |
| asac | lets flag this up. no clue if i messed it up ;) | 15:28 |
| asac | noted | 15:28 |
| dmart | OK, djvulibre | 15:29 |
| asac | seems that mov is assembler ... | 15:30 |
| dmart | Looks like it may need fixing. mov pc, <Rn> won't interwork correctly if built in Thumb. | 15:30 |
| asac | right | 15:30 |
| dmart | If it's in threading code, the branch could be supposed to go absolutely anywhere | 15:31 |
| asac | yeah | 15:31 |
| asac | ok ... dmake | 15:31 |
| dmart | dmake - looks like a false match: it's a sed munge in a Makefile | 15:32 |
| dmart | SH_n = $(@:s/swp-/-/:s,-,/,:s/scripts/${SCRIPTFILE}/) | 15:32 |
| asac | noted | 15:32 |
| asac | i have eglibc currently in the same boat as gcc etc. | 15:32 |
| asac | if you disagree we can make that a doko tasks | 15:32 |
| asac | search-arm-mov.filt: ./emacs23-23.1+1/lisp/emulation/pc-select.el: (pc-select-add-to-alist pc-select-saved-settings-alist ,var ,var) | 15:33 |
| dmart | It might be a good idea to flag up all the toolchain type stuff for doko to give a judgement on | 15:33 |
| asac | emacs23 sems to be a false positive | 15:33 |
| asac | grep erlang * | pastebinit | 15:33 |
| asac | http://pastebin.com/f7ec03435 | 15:33 |
| dmart | I guess so. I think elisp is strictly interpreted | 15:33 |
| asac | (emacs: the .el line is the only line that is in your filtered list, so its a false positive, yes.) | 15:34 |
| dmart | erlang: someone needs to take a more careful look. There might be some runtime code gen in there | 15:35 |
| dmart | It looks a bit like it from the matches | 15:35 |
| asac | yes, and the grep shows code that needs to be checked | 15:35 |
| asac | espeak | 15:36 |
| asac | search-arm-mov.filt: ./espeak-1.41.01/platforms/riscos/s/assemb:MOVNEr8,pc | 15:36 |
| asac | hmm. riscos? | 15:36 |
| asac | would that be us? | 15:36 |
| * asac wont think so | 15:36 | |
| ogra | ubuntu-risc FTW ! | 15:37 |
| asac | evolution-data-server | 15:37 |
| dmart | Unlikely to apply to us. Someone chould probably check it out... maybe some code was written for riscos but reused on ARM generally. But it feels low priority | 15:37 |
| dmart | (last comment applies to espeak btw) | 15:37 |
| asac | ./evolution-data-server-2.28.1/libdb/dbinc/mutex.h:asm volatile("swpb %0, %1, [%2]" | 15:37 |
| asac | seems that might be atomics | 15:38 |
| dmart | Looks like it | 15:38 |
| asac | noted | 15:38 |
| asac | ffmpeg -> guess that needs to build first ;) | 15:38 |
| dmart | FTBFS, or just not built yet? | 15:38 |
| asac | http://pastebin.com/f5558192 | 15:39 |
| asac | dmart: it currently ftbfs even | 15:39 |
| asac | http://qa.ubuntuwire.com/ftbfs/ | 15:39 |
| asac | https://edge.launchpad.net/ubuntu/+source/ffmpeg/4:0.5+svn20090706-2ubuntu4/+build/1409808/+files/buildlog_ubuntu-lucid-armel.ffmpeg_4:0.5+svn20090706-2ubuntu4_FAILEDTOBUILD.txt.gz | 15:39 |
| asac | but chromium ffmpeg builds ;) | 15:40 |
| dmart | We should check whether chromium ffmpeg is using the ARM asm and NEON in particular | 15:40 |
| dmart | ... should there be a separate ffmpeg there at all though? | 15:41 |
| asac | we dont use NEON, because we dont have NEON atm and the rest of chromium will not use hwcaps to use it based on support | 15:41 |
| Martyn | not surprised | 15:41 |
| asac | dmart: well. we kind of accepted that trying to use system libs for chromium isnt worth the effort | 15:41 |
| asac | they usually pull in snapshots | 15:42 |
| asac | and bump the revisions pulled in frequently | 15:42 |
| Martyn | I'm still trying to get NEON to work correctly in the latest builds of GCC | 15:42 |
| dmart | I'll try and raise a lp bug on that. Eventually, we do want good video performance in a browser ;) | 15:42 |
| asac | Martyn: ffmpeg? | 15:42 |
| Martyn | Even the latest CodeWarrior gcc doesn't seem to quite get it right | 15:42 |
| asac | dmart: there is a bug related ... one sec | 15:42 |
| lool | CodeWarrior or Sourcery? | 15:42 |
| Martyn | CodeSourcery | 15:42 |
| Martyn | Heh, spellcheck auto-fsked that | 15:43 |
| lool | he | 15:43 |
| asac | http://code.google.com/p/chromium/issues/detail?id=30991 | 15:43 |
| asac | dmart: ^^ | 15:43 |
| asac | thats where i asked about it | 15:43 |
| asac | though it was for non ffmpeg related neon | 15:43 |
| Martyn | however, I have seen some hand-coded ASM libs that reference NEON | 15:43 |
| asac | guess ffmpeg could be done | 15:43 |
| Martyn | and do the check to see if it's a vfp or NEON enabled processor | 15:44 |
| dmart | For ffmpeg proper, we build a separate library flavour and use ld.so hwcaps | 15:44 |
| Martyn | (not ffmpeg. In muy case, it's marble .. a biotech program) | 15:44 |
| dmart | There's a lot of hand-optimised code in ffmpeg anyway, so it may make sense to built ffmpeg with -marm. This might be done already, but can you make a note to double-check it? | 15:45 |
| lool | Not built with -marm ATM | 15:45 |
| asac | dmart: i saved what we have for now. i will probably finish and fill in what i can see after call | 15:46 |
| Martyn | lool : Shouldn't we be building with -marm? | 15:46 |
| asac | ffmpeg? thats the plan afaik | 15:46 |
| dmart | OK. I guess ffmpeg needs a bit of further review, but it doesn't look like there's a major problem | 15:46 |
| Martyn | Or is the effort to build v7-a thumb getting in the way of that? | 15:47 |
| dmart | Martyn: in the way of what? | 15:47 |
| asac | using -marm | 15:47 |
| dmart | No, we can still use -marm for specific packages | 15:47 |
| dmart | ...if needed | 15:48 |
| dmart | [...] | 15:48 |
| dmart | gccxml? | 15:48 |
| dmart | Is this effectively a port of GCC? I was never too sure | 15:48 |
| asac | XML output extension to GCC | 15:48 |
| asac | no clue ;) | 15:48 |
| dmart | Another one for doko then. I suspect it's a non-issue | 15:49 |
| asac | http://paste.ubuntu.com/355573/ | 15:49 |
| dmart | hmm | 15:49 |
| asac | ok noted | 15:49 |
| dmart | gdb -> doko ? | 15:50 |
| asac | yes | 15:50 |
| asac | ghostscript seems to be false positive | 15:50 |
| asac | grep ghostscript * | pastebinit | 15:51 |
| asac | http://pastebin.com/fc30016a | 15:51 |
| dmart | agreed | 15:51 |
| asac | search-arm-swp.filt: ./glib2.0-2.22.2/glib/gatomic.c: "swp %0, %1, [%2]\n" | 15:51 |
| asac | i think thats fixed | 15:51 |
| asac | by using intrisincs if available | 15:51 |
| asac | but i will add item to check that | 15:51 |
| dmart | I think I posted a patch for that :) I can probably get the bug number | 15:52 |
| dmart | glib2.0: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491872 | 15:53 |
| ubot4 | Launchpad bug 491872 in glib2.0 "[armel] Atomic intrinsics are not implemented correctly" [High,Fix released] | 15:53 |
| asac | yeah | 15:53 |
| asac | ok ... taking quick break; then call! | 15:54 |
| asac | saved the wiki | 15:54 |
| dmart | OK, thanks for the progress so far, I think that's 30-40% of the main list | 15:54 |
| asac | hehe yeah. took some time to ramp up, but that should be quick. of course loads of porting work will come out of this - so we definitly need to prioritize reasonably | 15:55 |
| asac | hmm i busted the wiki table ;) | 15:55 |
| dmart | Doing a quick first pass so we can make the right decisions seems the right thing to do | 15:56 |
| asac | found the issue | 15:56 |
| asac | yes | 15:56 |
| * asac checks if ffox 3.6 is happily spinning on arm before going away | 19:55 | |
| asac | ok seems like. waiting for xulrunner to finish: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3 | 19:56 |
| armin76 | http://www.youtube.com/watch?v=_qGNj0YqFMM | 21:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!