**** BEGIN LOGGING AT Mon Jul 11 02:59:58 2016 Jul 11 07:37:36 good morning Jul 11 08:19:08 morning Jul 11 10:40:43 bluelightning, does this look familiar to you Jul 11 10:40:45 http://pastebin.com/XwkF0c8C Jul 11 10:41:05 I think I did it when I tried an extensible sdk Jul 11 10:48:29 Crofton|work: yep because if you don't do that you hit https://bugzilla.yoctoproject.org/show_bug.cgi?id=9479 Jul 11 10:48:35 ok Jul 11 10:48:37 Thanks Jul 11 10:48:44 I knew there was a reason Jul 11 10:49:02 trying to commit all my uncommitted crap :) Jul 11 10:49:28 Now I can have a non nonsense commit message Jul 11 10:49:44 and the lesson here is commit before you forget why you did something Jul 11 10:50:10 yep, and make full use of branches :) Jul 11 10:52:34 heh Jul 11 10:52:39 yeah Jul 11 14:15:46 When did OE switch from classic to core? (What year?) Jul 11 14:37:04 awozniak: there wasn't specific flag day for switch as different project switched at different times, but oe-classic is pretty much dead since early 2012 Jul 11 14:37:20 ty Jul 11 14:40:10 awozniak: the 1.0 release of oe-core was in 2011 Jul 11 14:40:33 rburton: ty! Jul 11 15:53:48 khem: if i sent you a trivial patch for glibc, would you be able to get it upstream smoothly? Jul 11 17:10:07 rburton: let me check. If its a no nonsense thing then it should be ok Jul 11 18:08:16 http://pastebin.com/cW0HYZ6W Jul 11 18:08:40 linkage issue with __atomic ops in master Jul 11 18:08:43 any ideas Jul 11 18:20:06 Crofton|work: which arch and machine are you building for ? Jul 11 18:20:22 dragon board Jul 11 18:20:33 aarch64 Jul 11 18:24:59 Crofton|work: I think you need to disable libatomips_ops Jul 11 18:25:06 libatomics_ops Jul 11 18:28:00 so mixing that with aarch64 leads to trouble? Jul 11 18:28:21 yes Jul 11 18:29:11 lboost_atomic-mt Jul 11 18:29:13 maybe? Jul 11 18:31:25 or you need to link with -latomic_ops Jul 11 18:31:48 do you have libatomic_ops.so* in your sysroot ? Jul 11 18:31:50 hmmm Jul 11 18:31:52 or .a Jul 11 18:32:01 I'll see what I can do Jul 11 18:32:23 need to figure out why this gnuradio thing is different to others Jul 11 18:33:16 it might be using 128-bit arithmatics and x86 does have CMPXCHG16B Jul 11 18:33:20 but aarch64 doesnt Jul 11 18:33:33 so it will need aid from library Jul 11 18:41:20 this should keep me busy :) Jul 11 18:48:49 I have a prototype for a video tool that connects to a CCD and also a video stream, It calculates the CCD's input, and modifies the input video stream, outputting a secondary video stream in various resolutions. I am trying to grasp how I would build this hardware in real life. The program is written in C++. Any resources to share? Thoughts? Jul 11 18:52:25 khem: http://pastebin.com/jt7YmrmG <— needed to make the kernel build with glibc master. or, there's a fix for the kernel which i also have. basically they're both broken Jul 11 19:34:06 rburton: this can be contentious Jul 11 19:35:12 since kernel already has a define and is guarding it for itself why does it depend on glibc headers ? Jul 11 19:35:40 khem: to build with glibc master the kernel needs http://pastebin.com/jt7YmrmG Jul 11 19:35:49 khem: (both untested right now, building underway) Jul 11 19:35:58 erm wrong link Jul 11 19:36:09 http://pastebin.com/CafKN3P0 is the kernel one Jul 11 19:37:50 rburton: for kernel part you should guard each one seprately e.g. ifndef X then define X endif Jul 11 19:47:21 i thought the check-all-three was a good compromise to avoid a boring pile :) Jul 11 19:49:55 ok changed, if you think thats the sort of thing that will upset the lords of lkml ;) Jul 11 19:52:12 sent Jul 11 19:52:41 now, will the patch be ignored, or will i get flamed for a linguistic error in my commit message :) Jul 11 20:03:36 khem: i've sent the kernel fix upstream but can we just apply my glibc patch to our recipe to fix all kernels? Jul 11 20:06:02 (i'll post it to libc-alpha too) Jul 11 20:06:15 it actually breaks all kernel builds, so that's not something to release with Jul 11 21:07:35 khem: sent my glibc patch to oe-core Jul 11 22:14:13 hi all Jul 12 00:30:57 does oe-core have i2c userspace tools? Wondering how to get it? Jul 12 00:31:48 using bitbake Jul 12 00:55:01 i2c-tools I think Jul 12 00:55:49 http://layers.openembedded.org/layerindex/recipe/27859/ Jul 12 01:08:22 Crofton|work: thanks a ton. Jul 12 01:25:40 rburton, kernel patch is certainly not needed, its not wrong though, but I think it wont be accepted Jul 12 01:26:24 peoliye: add i2c-tools to IMAGE_INSTALL Jul 12 01:43:42 khem: very new to bitbake. I just did bitbake i2c-tools and it worked. However how to add that in IMAGE_INSTALL? Jul 12 01:47:50 peoliye: you may find this useful if you haven't already seen it: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Jul 12 02:07:53 Is there a good prototyping SOM whose principles generally apply to all SOM's? Jul 12 02:08:12 e.g. http://wiki.solid-run.com/lib/exe/fetch.php?media=imx6:microsom:docs:sr-data_sheet-imx6-microsom-i1.pdf Jul 12 02:54:34 two questions: 1. how do I make do_configure[depends] += "virtual/kernel:do_shared_workdir" only for some $MACHINE, do I append _mymachine after configure or after [depends] Jul 12 02:56:33 2. how to provide the path to this header to my cmake project: ./BUILD/work-shared/imx6dlsabreauto/kernel-source/include/uapi/linux/ipu.h I am guessing via a cmake extra config that is ${STAGING_KERNEL_DIR} Jul 12 02:58:05 1. You can't do it like that - if you really need to I suspect you'll need to do something like: do_configure[depends] += "${SOMEVAR}" SOMEVAR = "" SOMEVAR_yourmachine = "virtual/kernel:do_shared_workdir" Jul 12 02:59:27 is that the right order? I guess it gets evaluated later? **** ENDING LOGGING AT Tue Jul 12 02:59:58 2016