**** BEGIN LOGGING AT Tue Jan 06 02:59:59 2015 Jan 06 06:26:14 I never thought configuring yocto would be complex, but I've got twenty-four pages of notebook paper that detail simple things @_@ Jan 06 06:26:18 "simple" Jan 06 06:38:34 oldtopman: you mean configuring OE, right? Yocto is an umbrella project, not something you can configure Jan 06 06:41:15 koen: My bad. Still getting used to the divisions between intel/yocto/oe here. Jan 06 06:41:50 I only found this place because the documentation recommended downloading a lot more packages from the oe repositories :) Jan 06 06:58:55 packages or recipes? Jan 06 07:47:24 how do I undo a task[noexec] = "1" inside a .bb using a bbappend? Jan 06 07:47:49 task[noexec] = "0" nor task[noexec] = "" do the trick Jan 06 07:50:45 QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so Jan 06 07:50:48 it looks like noexec is a flag, not a boolean :( Jan 06 07:51:01 is there a flag I can set that disables the qa on dodgy .so symlinks? Jan 06 07:51:02 pompomJuice: fix your code to generate proper SOVERSIONs Jan 06 07:51:46 my do_install contains a ln -s ../foo.so ${D}/foo.so Jan 06 07:51:50 its a hack Jan 06 07:52:02 I put it there Jan 06 07:52:10 Is there no way other than doing it correctly? Jan 06 07:55:13 you could paper it over with INSANE_SKIP Jan 06 07:56:34 thats the plan, 1.7 docs contain INSANE_SKIP instructions? Jan 06 07:57:04 I have tried guessing in the past how that mechanism works, but I found out that is a bad idea Jan 06 07:58:30 I rarely read the docs Jan 06 07:58:38 I just grep the metadata in oe-core/meta-oe Jan 06 08:00:50 oh, I thought all this functionality is contained within the bitbake stuff Jan 06 08:00:59 no wonder I cant find any of this in the code Jan 06 08:01:06 no Jan 06 08:01:07 il try metadata forsure Jan 06 08:01:18 not all is in bitbake Jan 06 08:01:21 omg Jan 06 08:01:35 I did not know that Jan 06 08:04:07 but 1.7 now has a nice section on insane skip Jan 06 08:04:09 im impressed Jan 06 08:04:41 yes the intel guys does a good job to improve the docs Jan 06 09:35:18 morning all Jan 06 12:21:41 gm Jan 06 12:23:24 ford Jan 06 12:24:35 bmw Jan 06 12:25:45 embedded Jan 06 12:40:39 could someone do a quick test of the file util for me on a recent OE build Jan 06 12:40:52 SDK build that should be Jan 06 12:41:15 if I use file from the SDK it whinges about the magic file being broken Jan 06 12:41:33 a simple 'file anyfile' will show if it's working or not Jan 06 12:41:58 if it makes any difference the target machine is x86 and the SDK is x86_64 Jan 06 12:49:47 ah, that old problem Jan 06 12:50:03 iirc 'file' hardcodes the absolute location to its magic Jan 06 12:50:14 try running 'strings' on it Jan 06 12:50:19 (and strace) Jan 06 12:57:57 yeah, thats similar to what it's crying about Jan 06 12:58:36 x86_64-oecore-linux/usr/share/misc/magic.mgc, 1916: Warning: type `.' invalid Jan 06 12:58:37 file: Size of `/eng/jmitchell/oe-sensors/sdk/sysroots/x86_64-oecore-linux/usr/share/misc/magic.mgc' 3043460 is not a multiple of 248 Jan 06 12:58:38 etc etc Jan 06 13:07:01 so the magic file is set, and it is set to the correct file, but it seems as if the magic.mgc itself is maybe corrupt or wrong Jan 06 13:07:12 I can point file at my hosts magic file and it works fine Jan 06 13:41:19 jackmitchell: the error looks like a 32bit/64bit mismatch, dunno how that could happen Jan 06 13:42:51 koen: yeah I imagined as much Jan 06 14:26:30 fark, dizzy broke wic, or I need to check the rm_work inhibitor Jan 06 14:32:28 RP, 38b1f9d8e4fa9afb8644e4be55191fbe5cfd99a1 breaks wic for sd cards Jan 06 14:32:40 * Crofton|work grumbles Jan 06 14:33:09 and it got into dizzy Jan 06 14:35:11 Crofton|work: how does that break wic? Jan 06 14:35:24 Crofton|work: wic is poking around WORKDIR? Jan 06 14:35:32 it cleans out the directory with the rootfs that the image is made from Jan 06 14:35:34 yes Jan 06 14:35:54 beat tomz Jan 06 14:35:54 I think Jan 06 14:36:56 Crofton|work: don't use rm_work? Set rm_work_rootfs[cleandirs] = "" ? Jan 06 14:37:36 I can see why its been done like that, I can't win, we got complaints the directory wasn't cleaned up Jan 06 14:37:38 I had https://github.com/balister/meta-sdr/commit/7eab2f7835be3ebae009ca4be1a24d99827da47b Jan 06 14:37:38 doone that to fix it earlier Jan 06 14:37:39 but the commit broke that Jan 06 14:38:25 people are all wrong Jan 06 14:39:30 Happy New Year also, in case I forgot to wish you that earlier Jan 06 14:42:34 I was trying to get the reporter to open a bug last week, rather than have me dot it, sounds like it didn't happen :( Jan 06 14:44:34 RP, https://bugzilla.yoctoproject.org/show_bug.cgi?id=7114 Jan 06 14:44:50 apparently some people went on holiday last weekend .... Jan 06 14:46:04 Crofton: you didn;'t mention RM_WORK_EXCLUDE, that is a little different Jan 06 14:49:31 the was in the git has I pasted above Jan 06 14:49:45 multitasking and being lazy Jan 06 14:49:52 anyway, bug report got opened Jan 06 14:50:18 not by me, trying to get people to report upstream if they can Jan 06 19:55:38 I'm having some difficulty getting the postgresql recipe working. bitbake builds it just fine with no errors or warnings and it flashes to my Intel Edison just fine but I can't actually find psql anywhere on the system. What gives? Jan 06 20:06:50 deception, I'd try inspecting the outputted postgresql packages, looking for the binary in them Jan 06 20:06:58 then doublechecking that that particular package gets installed in the image Jan 06 20:10:45 deception you need to include it in your image Jan 06 20:10:49 the right package Jan 06 20:11:22 deception -client something Jan 06 21:46:33 kroon, Good idea, that's a good starting point. Let me see if psql exists at all. **** BEGIN LOGGING AT Tue Jan 06 23:21:19 2015 Jan 07 00:36:47 <_oldtopman> Can someone here test an openembedded package for me? Jan 07 00:37:14 <_oldtopman> I don't think it works, so I'd like to patch it, yet I've heard that it wouldn't be distributed unless it built correctly. Jan 07 00:59:52 Hey guys. I'm trying to make use of Bitbake to build images for an Intel Galileo board ; the BSP is based on Pokey Jan 07 01:00:39 The build is failing on OpenCV since version 2.4.3 can't be found anywhere . I've renamed the opencv_2.4.3.bb to 2.4.9.bb , under the meta-oe/meta-oe/recipies-support/opencv folder, any place else I need to modify? the build fails Jan 07 01:06:50 Anyone alive? Jan 07 01:34:29 yeah, but we are mostly a .eu/us left coast crowd Jan 07 01:34:43 and the left coast is winding down for the day Jan 07 02:15:40 Crofton|work: Ah, thanks. Jan 07 02:17:28 I'm guessing not many people have galileo boards yet either Jan 07 02:28:20 Yeah. None the less, can you confer upon me how the recipies are generally handled? Jan 07 02:28:29 The Galileo "port" is using Poky as a reference **** ENDING LOGGING AT Wed Jan 07 02:59:58 2015