**** BEGIN LOGGING AT Mon Sep 30 02:59:58 2013 Sep 30 07:35:13 florian_kc: some linuxtogo.org/gowiki links have disappeared Sep 30 07:37:58 ant_work: yep... I know how to fix it... wait Sep 30 07:52:55 good morning Sep 30 07:59:59 florian: another thing is, gitweb looks ugly Sep 30 08:00:38 some config lost during update? Sep 30 08:22:37 Hi, I'm having a peculiar issue. The build process was interrupted due to an unterminated #ifdef. When I checked, it seems that the file was not completely downloaded for some reason. (I downloaded the package with my browser and compared) Is there a way to tell bitbake to purge and re-download one specific recipe? Sep 30 08:28:27 pvr: "bitbake foo --cc cleanall" will wipe everything, including downloaded items in DL_DIR Sep 30 08:28:58 damn ctrl-w Sep 30 08:29:31 rburton, I jsut trried "bitbake -c clean ", waiting for it to pass do_compile Sep 30 08:30:33 I'm just discovering oe, and pretty fond of it at the moment... Sep 30 08:31:03 clean won't delete anything from the downloads, so if that's where the corruption is then you'll have the same problem Sep 30 08:31:04 but the depth of bb configuration files and possibilities is slightly overwhelming Sep 30 08:31:30 clean just wipes out the work directory, cleansstate is clean + sstate cache, cleanall is cleansstate + download cache Sep 30 08:33:32 rburton, ah ok, I guess I will have the same problem then... I'll do the cleanall command. Why did you use --cc if I may ask? I'm guessing it's an alias for -c or --cmd= ? Sep 30 08:34:26 actually, now that I think of it, the problem might have been the unpacking... I compared the original with the working directory version, not the download cache... Sep 30 08:34:52 I'll see if it passes (takes a while on a core 2) Sep 30 08:37:08 oh, sorry Sep 30 08:37:11 just -c Sep 30 08:37:18 not sure where the -- came from either Sep 30 08:42:42 morning all Sep 30 08:44:38 florian: gowiki is back but pages are still missing Sep 30 08:45:52 ant_work: nasty.... which ones? Sep 30 08:46:06 http://www.openembedded.org/wiki/Zaurus Sep 30 08:46:21 florian: and gitweb has an unterminated tag Sep 30 08:47:04 at 487 /poky/meta/recipes-graphics/mesa/mesa_9.0.2.bb /<...>/poky/meta-raspberrypi/recipes-graphics/userland/userland_git.bb)." Sep 30 09:24:47 However, I have REFERRED_PROVIDER_virtual/libgles2 ?= "userland" in /meta-raspberrypi/conf/machine/include/rpi-default-providers.inc Sep 30 09:25:32 Why do I get the ERROR? Shouldn't it be a warning? or is it not picking up that I want it to use the raspberrypi provided GL libraries? Sep 30 09:26:34 (that's PREFERRED_PROVIDER_virtual/libgles2 of course) Sep 30 09:32:16 pvr: the clue is in the message on the next line that you didn't paste - "this usually indicates one provides something the other doesn't ..." Sep 30 09:33:02 virtual/mesa was added recently... Sep 30 09:33:30 I doubt meta-raspberrypi has been updated to handle that if it needs to be Sep 30 09:34:12 bluelightning, I think the point of the rasp.pi provided one is that it provides the GL headers and libs specific to the board... so I'm pretty sure that's what we're trying to achieve, no? ie. tell bitbake to use the rpi one, and not the default.... Sep 30 09:34:48 pvr: yes, except something will be depending on something that the "rpi one" does not provide Sep 30 09:35:57 Ok, so the message is basically "the preferred_provider chosen is probably out of date, or at least not up to date enough for some dependencies" ? Sep 30 09:36:38 So I guess this is indeed more of a warning than an error, since it seems to continue compiling... Sep 30 09:37:05 its a pretty nasty warning because you'll often end up with conflicting files in the rootfs. Sep 30 09:37:12 my hunch is virtual/mesa Sep 30 09:37:37 use depexp to see what is pulling in mesa. Sep 30 09:37:45 its probably something that is asking for virtual/mesa Sep 30 09:48:45 Thank you for the tip! I'm going to check it out before I continue... Sep 30 10:15:50 I think I have found some sort of solution here: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/26636 Sep 30 10:15:53 Not perfect though... Sep 30 10:16:36 hi Sep 30 10:16:56 hm for nativesdk we need virtual/gettext-nativesdk too Sep 30 10:18:18 pvr: what's the actual problem then? note that oe-core master has a "mesa-gl" if you only need mesa for software GL/GLX rendering. Sep 30 10:19:32 The problem is that mesa offers a GL implementation (software) that is pulled in by X, and afaiu the rpi bsp offers a hw accelerated GL implementation. These conflict, but it seems impossible to stop mesa from building it... Sep 30 10:20:04 I haven't touched the PACKAGECONFIG variable of the mesa recipe, as I think this wouldn't be a clean way of doing things... Sep 30 10:20:25 At least that's what I understand with my relatively limited knowledge of oe at this time Sep 30 10:21:44 from what I gather from said mailing list post, I can pretty much ignore it (MULTI_PROVIDER_WHITELIST seems to be suggested ...) but it seems wrong. Sep 30 10:28:41 rburton, this would be the cleaner solution: http://lists.openembedded.org/pipermail/openembedded-devel/2013-May/090796.html I'm not sure if it has been implemented... I'll scribble it down as possible todo once I know oe a little better... Sep 30 11:00:22 pvr: thats exactly what mesa-gl is Sep 30 11:11:19 Same paste as on friday: http://pastebin.com/TdvbZbRY . Am I the only one running into this with systemd 206? Sep 30 11:15:09 tasslehoff: I woudl check kernel config Sep 30 11:15:20 hi hrw Sep 30 11:15:40 hi woglinde Sep 30 11:15:52 tasslehoff yes probably no cgroup support in kernel Sep 30 11:17:24 hrw: woglinde: cgroup support is enabled in my defconfig Sep 30 11:21:30 tasslehoff hm all options? Sep 30 11:21:59 tasslehoff try qemu build and look if systemd says the same Sep 30 11:22:46 "namespace cgroup subsystem" was the only one not enabled Sep 30 11:23:07 2.6.39 kernel, but it should still work? Sep 30 11:25:17 antique Sep 30 11:27:16 hm Sep 30 11:27:38 look at the deps and versions systemd 206 needs Sep 30 11:29:04 woglinde: haven't been able to find it Sep 30 11:34:01 but now I did. Sep 30 11:34:04 >= 3.0 Sep 30 11:34:13 there you go Sep 30 11:35:05 tasslehoff: there isn't exactly a huge step between 2.6.39 and 3.0 ;) Sep 30 11:35:32 http://cgit.freedesktop.org/systemd/systemd/commit/README?id=e946948eff517e895b287d0fd8c6d069ab9bbbb9 Sep 30 11:35:48 ant lookslike for systemd and cgroups it is Sep 30 11:36:40 what stopped me from moving to 3.0 the last time was that 2.6.39 was the last version where pm/suspend worked well on my board Sep 30 11:36:55 sure, I meant it is just one version far Sep 30 11:37:49 but anyway. now it seems cruel that systemd_204.bb was removed Sep 30 11:37:53 :) Sep 30 12:01:07 tasslehoff make yourown layer Sep 30 12:21:39 Can someone tell me how to compile OpenCV with hard floating point support in OpenEmbedded with bitbake recipe? Sep 30 12:22:22 sanchayan_ did you measure how much performance you get? Sep 30 12:22:43 No Sep 30 12:22:45 hm Sep 30 12:22:57 right you first need to compile it Sep 30 12:23:16 I am currently building for Tegra 2 and wanted to use the VFP on it Sep 30 12:23:22 ah Sep 30 12:23:29 it has no neon Sep 30 12:23:33 Yes Sep 30 12:23:37 hi all Sep 30 12:23:39 so you will get around 5% Sep 30 12:23:43 if you are lucky Sep 30 12:23:54 so I wont got through that hassel Sep 30 12:24:12 I started it sometimes ago to add vfp-16 options for it Sep 30 12:25:02 Hmm. Is that so? Just 5%. Can it be enable with a flag to EXTRA_OECMAKE variable in bitbake recipe or some more things have to be done? Sep 30 12:25:19 hm looks like I never commited it in my github stuff Sep 30 12:25:49 sanchayan_ hm you need proably a whole chain with libc and so on Sep 30 12:26:03 sanchayan_ yes only 5% Sep 30 12:26:10 and if you are lucky Sep 30 12:26:11 I have the full toolchain and build system set up with oe-core Sep 30 12:26:29 I meant the full chain compiled with vfp-16 support Sep 30 12:26:49 you could try ubuntu first Sep 30 12:26:55 which is compiled with vfp-16 Sep 30 12:27:17 sanchayan_ what tegar2 platform you have? Sep 30 12:27:29 Toradex Colibri T20 Sep 30 12:28:58 okay Sep 30 12:30:11 than its easy Sep 30 12:30:15 From what i understand, the toolchain i built has hard floating point support. I base this on the VFPV3 flag specified in the bitbake machine conf file. Sep 30 12:32:09 Ok. Can you tell me how? Do i just change the bitbake recipe and if yes, exactly where? EXTRA_OECMAKE variable? Sep 30 12:32:38 gcc --help? Sep 30 12:33:24 its --vfp16-d3 or so but I am mostly sure it will not work with a libc compiled without it Sep 30 12:33:52 for qucik ubuntu follow this http://developer.toradex.com/software-resources/arm-family/linux/images/using-the-nvidia-provided-l4t-rootfs Sep 30 12:34:57 you only need the two pins for getting it into flashmode Sep 30 12:35:37 Yes its vfp16-d3 Sep 30 12:38:41 recovery mode is here http://developer.toradex.com/knowledge-base/txx-recovery-mode Sep 30 12:39:09 The OE build already uses L4T Sep 30 12:39:31 I already know how to use recovery mode and flash image Sep 30 12:39:49 okay Sep 30 12:40:07 no its about ubuntu Sep 30 12:40:14 which is compiled with vfp16-d3 Sep 30 12:40:28 which is faster to test out Sep 30 12:41:18 The rootfs is already compiled with vfp16-d3 support in my oe-core build Sep 30 12:42:02 ah I totally forgot the they have meta-toradex Sep 30 12:42:03 sorry Sep 30 12:42:12 yes Sep 30 12:42:20 they have their own layer Sep 30 12:42:33 UNE_CCARGS += "-mfpu=vfpv3-d16" Sep 30 12:42:37 ups TUNE_CCARGS += "-mfpu=vfpv3-d16" Sep 30 12:42:42 so just compile opencv Sep 30 12:42:55 and it will have hardfloat Sep 30 12:43:06 unless there is some switch inside opencv Sep 30 12:43:28 I thought i had to use a seperate switch for OpenCV Sep 30 12:43:46 http://docs.opencv.org/doc/tutorials/introduction/crosscompilation/arm_crosscompile_with_cmake.html Sep 30 12:45:50 sanchayan hm and your are not able to read "Enable hardware optimizations"? Sep 30 12:46:01 or is your problem to set the cmake extra option? Sep 30 12:47:42 I didn't get you exactly. I was under the impression that a seperate switch is to be specified in bitbake recipe which will then be passed to CMake for building OpenCV with vfp support. Sep 30 12:47:54 I wanted to know this switch if i am correct or if something else has to be done. Sep 30 12:48:29 okay do the following Sep 30 12:48:38 cd openembbeded-core Sep 30 12:48:47 git grep -i cmake Sep 30 12:48:58 than you should get it Sep 30 12:50:04 Already did that. All i could find was CMakeLists.txt for opencv docs. Sep 30 12:58:58 o.O Sep 30 12:59:26 meta/recipes-support/libproxy/libproxy_0.4.7.bb:EXTRA_OECMAKE = "-DWITH_WEBKIT=no -DWITH_GNOME=yes -DWITH_KDE4=no \ Sep 30 12:59:35 no you should get it Sep 30 12:59:57 http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/opencv/opencv_2.4.3.bb Sep 30 13:00:06 I can see it straight in here Sep 30 13:00:41 yes Sep 30 13:01:20 no add it for VFPV3 Sep 30 13:02:59 -DUSE_VFPV3=ON? Sep 30 13:03:44 Or something else? Sep 30 13:04:50 sorry got disconnected Sep 30 13:05:00 No probs Sep 30 13:05:20 if I tell you the line you own me a beer Sep 30 13:05:47 If i ever make it to where you stay i will buy you 10 beers Sep 30 13:06:12 o.O common its not really hard Sep 30 13:06:17 its alreay in for SSE Sep 30 13:06:20 as you see Sep 30 13:08:43 ${@bb.utils.contains("TARGET_CC_ARCH", "-mfpu", Sep 30 13:09:14 close Sep 30 13:09:24 Correct? What do i specify in the DENABLE_ i cant understand Sep 30 13:09:36 *sigh* Sep 30 13:09:48 ${@bb.utils.contains("TARGET_CC_ARCH", "-mfpu", "-DENABLE_VFPV3", "", d)} \ Sep 30 13:09:59 you did not read the last section in http://docs.opencv.org/doc/tutorials/introduction/crosscompilation/arm_crosscompile_with_cmake.html Sep 30 13:10:00 ${@bb.utils.contains("TARGET_CC_ARCH", "-mfpu", "-DENABLE_VFPV3=1", "", d)} \ Sep 30 13:10:17 Hahaha. I did :d Sep 30 13:10:23 hm maybee ENBALE and USE is the same Sep 30 13:10:25 in camke Sep 30 13:10:28 ups cmake Sep 30 13:10:28 I wrote -DUSE_VFPV3=ON Sep 30 13:10:38 a bit above Sep 30 13:10:53 but let me check what it is doing inside opencv Sep 30 13:11:02 maybee only setting cflags Sep 30 13:11:12 ${@bb.utils.contains("TARGET_CC_ARCH", "-mfpu", "-DUSE_VFPV3=ON", "", d)} \ Sep 30 13:15:03 TUNE_CCARGS += "-mfpu=vfpv3-d16" Sep 30 13:15:23 so I would use TUNE_CCARGS instead of TARGET_CC_ARCH and -mfpu=vfpv3-d16 Sep 30 13:17:09 So that makes it ${@bb.utils.contains("TARGET_CCARGS", "-mfpu=vfpv3-d16", "", d)} \ Sep 30 13:17:49 btw. did you read http://answers.ros.org/question/10273/speeding-up-opencv-on-arm/ ? Sep 30 13:17:58 no Sep 30 13:18:01 TUNE_CCARGS Sep 30 13:18:17 Ah sorry. I wrote TARGET by mistake Sep 30 13:18:33 hms slow inet connection so cloning opencv last a while here Sep 30 13:19:13 Yes i had seen that link Sep 30 13:27:05 @woglinde. So thats all that has to be done?. On a side note, i now recall Toradex recommends your meta-java layer. Sep 30 13:33:22 sanchayan_ yes but oracle has arm support in his java8-preview Sep 30 13:33:35 only advantage I now have is uclibc support Sep 30 13:35:24 That is a significant advantage i would say Sep 30 13:42:40 hm opencv git is around 280 mb Sep 30 13:47:30 @woglinde. Don't know if the above will work or not, but, mostly should. Thanks a million for the help and walking me through. Thanks Henning Heinold. :D. I will test it out. Sep 30 13:47:45 he mom Sep 30 13:47:51 wait a minute Sep 30 13:47:58 ok Sep 30 13:48:02 git is nearly finished Sep 30 13:48:17 so I can look up what this option really does Sep 30 13:48:30 while you wait for git, you can look at the meta-java patches I just sent :) Sep 30 13:48:43 Ok. Thanks. That will be really great. Sep 30 13:48:54 suihkulokki hm which was it the native build one? Sep 30 13:49:48 woglinde_: well jamvm-native issues in general Sep 30 13:49:59 hm oh Sep 30 13:50:09 I updated the stuff yesterday Sep 30 13:50:17 and tested it a lot Sep 30 13:50:22 this time Sep 30 13:51:30 sanchayan_ just as I thought its useless to set Sep 30 13:51:44 Why? Sep 30 13:52:16 http://paste.debian.net/47513/ Sep 30 13:52:52 we already have set it Sep 30 13:52:56 ;) Sep 30 13:53:50 sanchayan_ you could try to use the verbos cmake flag to see if it vfp3-d16 is really set or if cmake overwrites our CFLAGS Sep 30 13:54:50 suihkulokki wher did you send it? Sep 30 13:55:17 Alright. Sep 30 13:59:15 @woglinde. Thanks for the help again. It will be a while before i can test OpenCV with this. I will get buy beers if i come to Germany. :d Sep 30 14:00:02 I will buy beers for you if i come to Germany, i meant. Sep 30 14:00:11 yes good luck Sep 30 14:01:32 suihkulokki ah okay Sep 30 14:01:33 sorry Sep 30 14:01:43 yes damn wget inside openjdk Sep 30 14:03:32 heinold@inf.fu-berlin.de and openembedded-devel Sep 30 14:03:39 well one of the patches is atleast broken... Sep 30 14:03:43 yes Sep 30 14:03:56 ericb already highlited it Sep 30 14:04:10 if you do not mine I will fix it Sep 30 14:04:28 but I wonder why I did no see your last error Sep 30 14:05:19 feel free to fix it, if you think the fix in general is correct Sep 30 14:06:15 I was not sure why IFS was there in the first place Sep 30 14:08:32 suihkulokki actually I stole it from cacao Sep 30 14:17:59 suihkulokki hm strange the script works for dash Sep 30 14:18:12 suihkulokki whats the shell you are using on your testing host? Sep 30 14:20:08 have to go Sep 30 14:20:10 till later Sep 30 15:52:10 On the meta-openembedded/meta-multimedia git repository (master branch), I see that the XBMC recipe is still at version 11.0 (eden) ... This version is now over 1 and half years old and doesn't compile on some ARM systems. Does anyone know if there is a more up-to-date recipe? Sep 30 15:52:35 I'm checking if I should do this myself or not.... I have never done this before, but I need it. :) Sep 30 15:58:44 I'm off, probably shouldn't have posted this 5 minutes before leaving. I should be back later though. Bye Sep 30 16:27:32 sgw_, thanks for adding me to the meta-xilnx bug Sep 30 16:27:41 I'll forward the info to the meta-xilnf list Sep 30 16:28:09 I can poke a little, but it will be next week since I am off to the GNU Radio conference this week Sep 30 16:30:25 Crofton: I can set the priority also, medium ? **** ENDING LOGGING AT Tue Oct 01 02:59:58 2013