**** BEGIN LOGGING AT Tue Sep 08 02:59:58 2015 Sep 08 03:00:53 bitbake is so much easier these days. I remember when it took hours to parse recipes :p Sep 08 03:02:33 s/easier/quicker/ i guess Sep 08 03:12:34 yeah, you can just override BUILD_ARCH in local.conf if you want Sep 08 03:12:54 * kergoth has done so in the past with 32-bit chroots Sep 08 03:15:31 how do I import Python modules so bitbake.conf can use them? Sep 08 03:16:06 you can either define a python function in a .inc and call it from the inline python, or you can add the module name to OE_IMPORTS. e.g. OE_IMPORTS += "foo.bar" Sep 08 03:16:08 iirc anyway Sep 08 03:23:22 kergoth: how do I get the .inc used? Sep 08 03:23:46 echo 'require conf/foo.inc' >>conf/local.conf; touch conf/foo.inc Sep 08 03:24:12 then def foo(d): ... in the .inc, and you can ${@foo(d)} in a variable Sep 08 03:28:20 scripts/ doesn't appear to be in PATH :/ Sep 08 03:31:31 * Luke-Jr gives up fixing this for now and just uses local.conf :| Sep 08 04:27:47 scripts is in the PATH after you source the setup script, assuming you're using the oe-core setup script Sep 08 05:11:14 I have autoconf 2.69, which seems to be making eglibc impossible to build :/ Sep 08 05:13:54 sounds extremely unlikely, considering your autoconf version is irrelevent, oe builds its own Sep 08 05:35:47 well, it says | aclocal.m4:5: error: Exactly version 2.68 of Autoconf is required but you have 2.69 Sep 08 07:39:43 Can someone tell me what the default size of time_t in openembedded? Sep 08 07:54:02 umut: that question doesn't make sense Sep 08 07:54:18 it's like asking "what's the default size of time_t when using cmake instead of make?" Sep 08 08:11:05 umut: i think what you are after is this: http://www.gnu.org/software/libc/manual/html_node/Simple-Calendar-Time.html -> in glibc the time_t is ~= long int Sep 08 08:19:22 morning all Sep 08 08:19:34 morning bluelightning Sep 08 08:19:42 hi nrossi Sep 08 08:29:14 nrossi, thanks. That would be 4 bytes in 32 bit systems Sep 08 08:30:30 we started having problems with systemd and dates set passed 2038. https://github.com/systemd/systemd/issues/1143. I am wondering if this is the case for the rest of the openembedded builds on 32 bits. Can anyone have a product they can test? Sep 08 08:30:35 umut: the answer to that question depends on the architecture specifically, but it will be at least 32bits Sep 08 08:42:10 good morning Sep 08 08:42:44 hi mckoan Sep 08 11:07:10 is there an example of how to properly install extra kernel headers as detailed in meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc Sep 08 11:07:31 would it just be something as simple as Sep 08 11:08:00 install KERNEL_STAGING_DIR/include/header.h $incdir/linux/ Sep 08 11:08:32 then what happens if multiple applications need it? split it out into a custom kernel header package? Sep 08 11:18:25 jackmitchell: I'm guessing you need non-generic headers Sep 08 11:18:32 jackmitchell: the stuff needed to build modules? Sep 08 11:18:56 or the other use case: crappy vendor userspace code with too much knowledge of the kernel? Sep 08 11:31:05 koen: I have a driver with an IOCTL, all the IOCTL stuff is in a header in the include directory of my linux fork Sep 08 11:31:29 koen: I'd like to install that header to my sdk so devs can compile against it Sep 08 11:31:53 koen: I thought it would automatically get installed, but as the kernel and headers are seperated, it doesn't Sep 08 11:32:15 ah Sep 08 11:32:23 jackmitchell: patch the linux-libc-headers Sep 08 11:32:46 koen: to use my source tree rather than the yocto-kernel source tree? Sep 08 11:34:51 so I could take a copy of meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb Sep 08 11:34:53 ehm Sep 08 11:34:59 change it to my source tree Sep 08 11:35:03 since when is l-l-h using that bogus tree? Sep 08 11:35:11 * koen checks Sep 08 11:35:17 ah, still using mainline Sep 08 11:35:31 jackmitchell: this is what I did for ILP32: https://git.linaro.org/openembedded/meta-linaro.git/blob/HEAD:/meta-linaro-integration/recipes-overlayed/linux-libc-headers/linux-libc-headers_3.18.bb Sep 08 11:35:33 and then find where that version gets specified and over ride it? Sep 08 11:35:58 I made a copy because I only had patches for 3.18 and oe-core was at 3.14 or so Sep 08 11:36:35 koen: do you know offhand where you specify the version, in a preffered provider somewhere I guess Sep 08 11:37:07 PREFERRED_VERSION_linux-libc-headers = "4.26" Sep 08 11:37:23 in local.conf, layer.conf or any other global confs Sep 08 11:37:48 for meta-maker I put it in layer.conf: http://git.yoctoproject.org/cgit/cgit.cgi/meta-maker/tree/conf/layer.conf Sep 08 11:38:24 I still feel uncomfortable about that, but I hate meta-java like "paste me to unbreak this layer" even less Sep 08 11:38:33 koen: sure, I wasn't sure if the libc-headers would be a special case or not, thanks Sep 08 11:38:52 l-l-h isn't a special case Sep 08 11:38:55 *but* Sep 08 11:39:03 don't use an older version that OLDEST_KERNEL Sep 08 11:39:07 than* Sep 08 11:39:23 we're 3.4 so we should be ok Sep 08 11:40:36 meta/conf/bitbake.conf:OLDEST_KERNEL = "2.6.32" Sep 08 11:40:37 meta/conf/bitbake.conf:OLDEST_KERNEL_aarch64 = "3.14" Sep 08 11:40:42 I got bitten by that a while ago Sep 08 11:41:02 since my beloved vendor kernel is 3.10 and has the aarch64 stuff.... Sep 08 12:58:58 bluelightning: what are your thoughts on a switch for buildhistory to *not* make those empty "No changes" commits? Sep 08 13:00:01 koen: I'd be happy to add one... at the same time I think it might be nice to have one that does a single commit per build as well Sep 08 13:01:44 heh, apparently it was you that added those "no changes" commits (though it was three years ago, and on April 1st no less) Sep 08 13:15:53 bluelightning: I know :) Sep 08 14:06:29 JaMa: ping Sep 08 14:06:41 another small issue with qtwebkit Sep 08 14:06:54 it is not picking gst headers automatically Sep 08 14:07:25 we have to provide -I option to gst folder in sysroot Sep 08 14:07:51 should it be added automatically Sep 08 14:08:06 I know gstreamer is not enabled by default Sep 08 14:08:10 we have enabled it Sep 08 14:10:45 1.0 or 0.10? Sep 08 14:24:44 OK, I deelted the do not use copies of oe-core and meta-oe Sep 08 14:24:53 does anyone need to update the things that updated them? Sep 08 14:25:01 * nrossi cheers Sep 08 14:34:16 JaMa: I think both Sep 08 14:53:45 Noor: please send patch Sep 08 14:54:33 JaMa: Need some pointer where we should look that this info get fillied automatically Sep 08 14:55:04 I thought it will work similar to libxml2 but gstreamer does not have any config.test thing Sep 08 14:55:42 Right now we are adding paths manually using OE variables Sep 08 15:43:46 ERROR: Function failed: Fetcher failure for URL: 'ftp://ftp.debian.org/debian/pool/main/l/linux-tools/linux-tools_4.0.2.orig.tar.xz'. Unable to fetch URL from any source. Sep 08 15:45:54 heh, gotta love fetching from debian Sep 08 15:48:33 did a git pull, maybe it was fixed .. Sep 08 15:49:35 this should be in our OE mirror unless it's a recipe elsewhere... Sep 08 15:49:59 (elsewhere meaning outside of the main set of OE layers that Martin builds) Sep 08 16:08:56 restarting seemed to help Sep 08 17:18:50 hmm, this may be the real error: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory Sep 08 17:19:21 yet adding libmpc as a dependency results in a recursive dep :/ Sep 08 18:29:01 is there no longer a need to update the PR field on recipes? I thought that the PR server would increment the version on each build, using the PR on the recipe as a base Sep 08 18:29:33 I submitted a recipe where there were enough changes that in my mind warranted a PR version bump Sep 08 18:29:52 but I am not sure if the guideline is to just not do it anymore Sep 08 18:29:56 that's correct, yes. PR is not bumped manually anymore Sep 08 18:30:07 whether the PR server is in use or not, bitbake will know whether things need to rebuild. if it's in use, then the rev gets bumped so package upgrades are handled Sep 08 18:30:09 (on target) Sep 08 18:30:32 bitbake uses the metadata checksumming to determine whether we need to re-run tasks, and whether to use sstate Sep 08 18:32:09 ok I see, so now bitbake handles the metadata to determine if a recipe needs to rebuild internally....so there is no need for recipe authors to handle that manually Sep 08 18:32:58 yep Sep 08 18:33:10 correct. the only reason pr even needs to be incremented is to ensure package upgrades are handled (the version in the binary packages gets increased)j, and the pr server handles that Sep 08 18:34:13 makes sense, that was my initial understanding, but got a message on the ML saying that I should have bumped PR Sep 08 18:34:43 I guess I should have researched first, =) Sep 08 18:34:50 kergoth: thanks Sep 08 18:35:12 naturally it does depend on what version you're using. old versions would still require a pr bump, e.g. when submitting a bugfix to one of the stable branches Sep 08 18:35:37 I am submitting to master, so no bump should be good Sep 08 18:36:34 * kergoth nods Sep 09 02:24:52 has anyone made the time to look at x-compile in OE and http://mesonbuild.com ? It's been on my to do list but I won't get time for a long time... Sep 09 02:26:51 it's YAATR (yet another autotools/make replacement) but maybe one with legs. It certainly aims to be clear and fast. **** ENDING LOGGING AT Wed Sep 09 02:59:59 2015