| 00:16.54 | *** join/#oe Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 00:17.19 | Luke-Jr | ERROR: Task 545 (virtual:native:/oe/setup-scripts/sources/openembedded-core/meta/recipes-support/gmp/gmp_5.1.0.bb, do_compile) failed with exit code '1' |
| 00:17.36 | Luke-Jr | seems to be trying to build native stuff for x86_64, but my system is x86_*32* |
| 00:27.37 | *** join/#oe Lightsword (~Lightswor@104.194.126.111) |
| 01:09.44 | *** join/#oe nslu2-log_ (~nslu2-log@140.211.169.184) |
| 01:12.41 | *** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net) |
| 01:42.02 | *** join/#oe nrossi (671a3dd4@gateway/web/freenode/ip.103.26.61.212) |
| 02:10.15 | vmeson | Luke-Jr: why :) it should work but you're building lots of code, a bigger 64 bit machine is useful. even 8 GB of RAM would help and isn't that expensive these days. |
| 02:10.36 | Luke-Jr | vmeson: I have 16 GB of RAM, but my OS is 32-bit |
| 02:10.57 | Luke-Jr | vmeson: it seems bitbake is incorrectly using uname -m to determine build architecture |
| 02:13.18 | vmeson | Luke-Jr: I thought that uname -m and arch would give the same result. If not , can you send a patch? |
| 02:14.04 | vmeson | uname -m and arch agree on my 32bit rhel-6 box. |
| 02:15.56 | Luke-Jr | arch is also incorrect |
| 02:16.10 | Luke-Jr | uname -m and arch give the kernel architecture, not the system |
| 02:16.10 | vmeson | Luke-Jr: see: https://en.wikipedia.org/wiki/Physical_Address_Extension <-- you're running a 'retro' distro. :) |
| 02:16.17 | Luke-Jr | no, I'm running a normal 64-bit kernel |
| 02:17.14 | Luke-Jr | 64-bit kernel + 32-bit system |
| 02:17.56 | vmeson | Luke-Jr: I see. Again I wonder why but patches to make this work might be accepted. |
| 02:18.23 | Luke-Jr | it's a fairly standard configuration these days :p (lower memory use than x86_64) |
| 02:19.44 | vmeson | yeah, I'm spoilt with my 16x2 core, 64 GB build server.. :) |
| 02:19.50 | Luke-Jr | :P |
| 02:19.56 | Luke-Jr | gcc -dumpmachine => i686-pc-linux-gnu |
| 02:20.21 | Luke-Jr | I *think* this is the best way to determine it, but it's not the same format as uname -m |
| 02:21.26 | Luke-Jr | what's the best repo to build bitbake merge reqs on? |
| 02:21.31 | vmeson | my old rhel632 gcc says: i686-redhat-linux |
| 02:22.03 | vmeson | Luke-Jr: git://git.openembedded.org/bitbake |
| 02:22.10 | vmeson | master. |
| 02:22.17 | Luke-Jr | and best way to submit a merge req? |
| 02:23.11 | vmeson | hmm... http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded but that doesn't mention bitbake directly. |
| 02:23.25 | *** join/#oe florian__ (~fuchs@Maemo/community/contributor/florian) |
| 02:25.24 | vmeson | Luke-Jr: subject: [bitbake-devel] [PATCH 0/6] Fix handling of "default" project |
| 02:25.34 | vmeson | to bitbake-devel@lists.openembedded.org |
| 02:25.39 | vmeson | goes to sleep... |
| 02:26.08 | Luke-Jr | thanks |
| 02:26.34 | vmeson | thanks for doing the right thing and hopefully sending a patch, Luke-Jr. |
| 02:27.10 | Luke-Jr | hmm, quite a few calls to uname -m ; is there a place I could sanely put a helper script for this? |
| 02:28.09 | Luke-Jr | is sources/openembedded-core/scripts/ likely to be in $PATH ? |
| 02:31.49 | *** join/#oe Lightsword (~Lightswor@104.194.126.111) |
| 02:32.47 | nrossi | Luke-Jr: 'openembedded-core/scripts/' will be on PATH |
| 02:34.02 | Luke-Jr | hmm. just realised I've left bitbake in this grep |
| 02:34.52 | Luke-Jr | ponders where build arch is actually being set |
| 02:35.46 | Luke-Jr | sources/openembedded-core/meta/conf/bitbake.conf:BUILD_ARCH = "${@os.uname()[4]}" |
| 02:35.49 | Luke-Jr | seem probable? |
| 02:36.21 | nrossi | yep thats the one |
| 02:43.30 | *** join/#oe anarsoul (~anarsoul@S0106848dc7ec0367.vs.shawcable.net) |
| 03:00.53 | Luke-Jr | bitbake is so much easier these days. I remember when it took hours to parse recipes :p |
| 03:02.33 | Luke-Jr | s/easier/quicker/ i guess |
| 03:12.34 | kergoth | yeah, you can just override BUILD_ARCH in local.conf if you want |
| 03:12.54 | kergoth | has done so in the past with 32-bit chroots |
| 03:15.31 | Luke-Jr | how do I import Python modules so bitbake.conf can use them? |
| 03:16.06 | kergoth | 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" |
| 03:16.08 | kergoth | iirc anyway |
| 03:22.14 | *** join/#oe Lightsword (~Lightswor@104.194.126.111) |
| 03:23.22 | Luke-Jr | kergoth: how do I get the .inc used? |
| 03:23.47 | kergoth | echo 'require conf/foo.inc' >>conf/local.conf; touch conf/foo.inc |
| 03:24.12 | kergoth | then def foo(d): ... in the .inc, and you can ${@foo(d)} in a variable |
| 03:28.21 | Luke-Jr | scripts/ doesn't appear to be in PATH :/ |
| 03:31.31 | Luke-Jr | gives up fixing this for now and just uses local.conf :| |
| 03:44.06 | *** join/#oe joshuagl (~joshuagl@host109-158-222-141.range109-158.btcentralplus.com) |
| 03:54.29 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 04:27.47 | kergoth | scripts is in the PATH after you source the setup script, assuming you're using the oe-core setup script |
| 05:11.14 | Luke-Jr | I have autoconf 2.69, which seems to be making eglibc impossible to build :/ |
| 05:13.04 | *** join/#oe hamis (~irfan@110.93.212.98) |
| 05:13.54 | kergoth | sounds extremely unlikely, considering your autoconf version is irrelevent, oe builds its own |
| 05:16.49 | *** join/#oe clio (~andrej@85.159.109.222) |
| 05:25.35 | *** join/#oe roric (~roric@h196n19-vrr-a31.ias.bredband.telia.com) |
| 05:34.17 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 05:35.47 | Luke-Jr | well, it says | aclocal.m4:5: error: Exactly version 2.68 of Autoconf is required but you have 2.69 |
| 06:09.25 | *** join/#oe Lightsword (~Lightswor@104.194.126.111) |
| 06:35.43 | *** join/#oe tasslehoff (~Tasslehof@82.147.55.166) |
| 06:51.46 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 07:38.50 | *** join/#oe umut (Adium@nat/axis/x-qzqgtqvaieamkarj) |
| 07:39.43 | umut | Can someone tell me what the default size of time_t in openembedded? |
| 07:54.02 | koen | umut: that question doesn't make sense |
| 07:54.18 | koen | it's like asking "what's the default size of time_t when using cmake instead of make?" |
| 08:06.05 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:11.05 | nrossi | 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 |
| 08:12.42 | *** join/#oe jku (jku@nat/intel/x-lovxkuxbrsxzepvj) |
| 08:15.09 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 08:19.22 | bluelightning | morning all |
| 08:19.34 | nrossi | morning bluelightning |
| 08:19.42 | bluelightning | hi nrossi |
| 08:29.14 | umut | nrossi, thanks. That would be 4 bytes in 32 bit systems |
| 08:30.31 | umut | 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? |
| 08:30.35 | nrossi | umut: the answer to that question depends on the architecture specifically, but it will be at least 32bits |
| 08:38.34 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 08:42.10 | mckoan | good morning |
| 08:42.44 | bluelightning | hi mckoan |
| 08:48.21 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 08:49.28 | *** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com) |
| 08:51.52 | *** join/#oe belen (Adium@nat/intel/x-lbdpkmmlqmdsvaiz) |
| 09:43.31 | *** join/#oe rburton (~Adium@host81-153-67-238.range81-153.btcentralplus.com) |
| 10:56.02 | *** join/#oe fcambus_ (~root@103-245-47-212.rev.cloud.scaleway.com) |
| 10:56.18 | *** part/#oe fcambus_ (~root@103-245-47-212.rev.cloud.scaleway.com) |
| 11:07.11 | jackmitchell | 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 |
| 11:07.32 | jackmitchell | would it just be something as simple as |
| 11:08.00 | jackmitchell | install KERNEL_STAGING_DIR/include/header.h $incdir/linux/ |
| 11:08.32 | jackmitchell | then what happens if multiple applications need it? split it out into a custom kernel header package? |
| 11:15.19 | *** join/#oe pidge (~pidge@2a02:8084:0:3000:a0d1:2ce7:b40c:221b) |
| 11:18.25 | koen | jackmitchell: I'm guessing you need non-generic headers |
| 11:18.32 | koen | jackmitchell: the stuff needed to build modules? |
| 11:18.56 | koen | or the other use case: crappy vendor userspace code with too much knowledge of the kernel? |
| 11:31.05 | jackmitchell | koen: I have a driver with an IOCTL, all the IOCTL stuff is in a header in the include directory of my linux fork |
| 11:31.29 | jackmitchell | koen: I'd like to install that header to my sdk so devs can compile against it |
| 11:31.53 | jackmitchell | koen: I thought it would automatically get installed, but as the kernel and headers are seperated, it doesn't |
| 11:32.11 | *** join/#oe ldnunes (~ldnunes_@177.100.224.236) |
| 11:32.15 | koen | ah |
| 11:32.23 | koen | jackmitchell: patch the linux-libc-headers |
| 11:32.46 | jackmitchell | koen: to use my source tree rather than the yocto-kernel source tree? |
| 11:34.51 | jackmitchell | so I could take a copy of meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.19.bb |
| 11:34.53 | koen | ehm |
| 11:34.59 | jackmitchell | change it to my source tree |
| 11:35.03 | koen | since when is l-l-h using that bogus tree? |
| 11:35.11 | koen | checks |
| 11:35.17 | koen | ah, still using mainline |
| 11:35.32 | koen | 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 |
| 11:35.33 | jackmitchell | and then find where that version gets specified and over ride it? |
| 11:35.58 | koen | I made a copy because I only had patches for 3.18 and oe-core was at 3.14 or so |
| 11:36.35 | jackmitchell | koen: do you know offhand where you specify the version, in a preffered provider somewhere I guess |
| 11:37.07 | koen | PREFERRED_VERSION_linux-libc-headers = "4.26" |
| 11:37.23 | koen | in local.conf, layer.conf or any other global confs |
| 11:37.48 | koen | for meta-maker I put it in layer.conf: http://git.yoctoproject.org/cgit/cgit.cgi/meta-maker/tree/conf/layer.conf |
| 11:38.24 | koen | I still feel uncomfortable about that, but I hate meta-java like "paste me to unbreak this layer" even less |
| 11:38.33 | jackmitchell | koen: sure, I wasn't sure if the libc-headers would be a special case or not, thanks |
| 11:38.52 | koen | l-l-h isn't a special case |
| 11:38.55 | koen | *but* |
| 11:39.03 | koen | don't use an older version that OLDEST_KERNEL |
| 11:39.07 | koen | than* |
| 11:39.23 | jackmitchell | we're 3.4 so we should be ok |
| 11:40.36 | koen | meta/conf/bitbake.conf:OLDEST_KERNEL = "2.6.32" |
| 11:40.37 | koen | meta/conf/bitbake.conf:OLDEST_KERNEL_aarch64 = "3.14" |
| 11:40.42 | koen | I got bitten by that a while ago |
| 11:41.02 | koen | since my beloved vendor kernel is 3.10 and has the aarch64 stuff.... |
| 11:49.14 | *** join/#oe dustinm` (~dustinm@167.114.152.105) |
| 12:27.32 | *** join/#oe ntl (~ntl@99-127-51-4.lightspeed.austtx.sbcglobal.net) |
| 12:32.53 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 12:58.58 | koen | bluelightning: what are your thoughts on a switch for buildhistory to *not* make those empty "No changes" commits? |
| 13:00.01 | bluelightning | 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 |
| 13:01.44 | bluelightning | heh, apparently it was you that added those "no changes" commits (though it was three years ago, and on April 1st no less) |
| 13:03.34 | *** join/#oe JaMa (~martin@86.49.34.37) |
| 13:08.38 | *** join/#oe blitz00 (stefans@nat/intel/x-kgkzumqzfeaqgmsz) |
| 13:08.38 | *** join/#oe blitz00 (stefans@unaffiliated/blitz00) |
| 13:15.53 | koen | bluelightning: I know :) |
| 13:17.59 | *** join/#oe Lightsword (~Lightswor@104.194.126.111) |
| 13:27.49 | *** join/#oe tsramos (~tsramos@192.55.54.36) |
| 13:54.48 | *** join/#oe jku (jku@nat/intel/x-jqgrqvkifdzxelem) |
| 14:01.41 | *** join/#oe belen (Adium@nat/intel/x-vzgjxaliiwqoweld) |
| 14:06.29 | Noor | JaMa: ping |
| 14:06.41 | Noor | another small issue with qtwebkit |
| 14:06.54 | Noor | it is not picking gst headers automatically |
| 14:07.25 | Noor | we have to provide -I option to gst folder in sysroot |
| 14:07.51 | Noor | should it be added automatically |
| 14:08.06 | Noor | I know gstreamer is not enabled by default |
| 14:08.09 | Noor | we have enabled it |
| 14:09.35 | *** join/#oe anarsoul (~anarsoul@S0106848dc7ec0367.vs.shawcable.net) |
| 14:10.45 | JaMa | 1.0 or 0.10? |
| 14:22.11 | *** join/#oe belen1 (Adium@nat/intel/x-jhdmjjzsjeoskryh) |
| 14:24.44 | Crofton|work | OK, I deelted the do not use copies of oe-core and meta-oe |
| 14:24.53 | Crofton|work | does anyone need to update the things that updated them? |
| 14:25.02 | nrossi | cheers |
| 14:33.18 | *** join/#oe adelcast (~adelcast@130.164.62.82) |
| 14:34.16 | Noor | JaMa: I think both |
| 14:53.45 | JaMa | Noor: please send patch |
| 14:54.33 | Noor | JaMa: Need some pointer where we should look that this info get fillied automatically |
| 14:55.04 | Noor | I thought it will work similar to libxml2 but gstreamer does not have any config.test thing |
| 14:55.42 | Noor | Right now we are adding paths manually using OE variables |
| 15:16.06 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 15:38.56 | *** join/#oe tsramos_ (~tsramos@134.134.139.74) |
| 15:43.46 | Crofton|work | 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. |
| 15:45.54 | kergoth | heh, gotta love fetching from debian |
| 15:46.10 | *** join/#oe jku (~jku@d-lltyxzqsj--98wl3k-3.rev.dnainternet.fi) |
| 15:46.39 | *** join/#oe jku (~jku@d-lltyxzqsj--98wl3k-3.rev.dnainternet.fi) |
| 15:48.33 | Crofton|work | did a git pull, maybe it was fixed .. |
| 15:49.35 | bluelightning | this should be in our OE mirror unless it's a recipe elsewhere... |
| 15:49.59 | bluelightning | (elsewhere meaning outside of the main set of OE layers that Martin builds) |
| 15:51.52 | *** join/#oe gabrbedd (~beddingfi@li680-65.members.linode.com) |
| 15:56.28 | *** join/#oe tsramos (~tsramos@134.134.139.74) |
| 16:02.45 | *** join/#oe gabrbedd (~beddingfi@li680-65.members.linode.com) |
| 16:08.36 | *** join/#oe darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 16:08.56 | Crofton|work | restarting seemed to help |
| 17:08.48 | *** join/#oe jku (~jku@d-lltyxzqsj--98wl3k-3.rev.dnainternet.fi) |
| 17:13.46 | *** join/#oe jku (~jku@212-149-207-214.bb.dnainternet.fi) |
| 17:15.43 | *** join/#oe tsramos (~tsramos@192.55.55.39) |
| 17:18.50 | Luke-Jr | 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 |
| 17:19.21 | Luke-Jr | yet adding libmpc as a dependency results in a recursive dep :/ |
| 17:20.05 | *** join/#oe jku (~jku@d-lltyxzqsj--98wl3k-3.rev.dnainternet.fi) |
| 17:23.57 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 17:30.34 | *** join/#oe vmeson (~rmacleod@24-212-184-107.cable.teksavvy.com) |
| 17:51.06 | *** join/#oe bradfa (~andrew@clr-vpn01.kodakalaris.com) |
| 17:54.20 | *** join/#oe darknighte (~darknight@pdpc/supporter/professional/darknighte) |
| 18:04.40 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 18:13.58 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 18:29.01 | adelcast | 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 |
| 18:29.33 | adelcast | I submitted a recipe where there were enough changes that in my mind warranted a PR version bump |
| 18:29.52 | adelcast | but I am not sure if the guideline is to just not do it anymore |
| 18:29.56 | kergoth | that's correct, yes. PR is not bumped manually anymore |
| 18:30.07 | kergoth | 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 |
| 18:30.09 | kergoth | (on target) |
| 18:30.33 | kergoth | bitbake uses the metadata checksumming to determine whether we need to re-run tasks, and whether to use sstate |
| 18:32.09 | adelcast | 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 |
| 18:32.58 | kergoth | yep |
| 18:33.10 | kergoth | 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 |
| 18:34.13 | adelcast | makes sense, that was my initial understanding, but got a message on the ML saying that I should have bumped PR |
| 18:34.43 | adelcast | I guess I should have researched first, =) |
| 18:34.50 | adelcast | kergoth: thanks |
| 18:35.12 | kergoth | 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 |
| 18:35.37 | adelcast | I am submitting to master, so no bump should be good |
| 18:36.34 | kergoth | nods |
| 18:39.30 | *** join/#oe caiortp (~inatel@131.221.240.204) |
| 18:42.15 | *** join/#oe NightMonkey (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 18:42.23 | *** join/#oe deception (~deception@unaffiliated/deception) |
| 19:00.56 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 19:17.00 | *** join/#oe belen1 (~Adium@17.114.2.81.in-addr.arpa) |
| 19:17.21 | *** join/#oe paulg (~paulg@72.1.195.9) |
| 19:25.10 | *** join/#oe limbrik (~textual@64.197.89.235) |
| 19:26.51 | *** join/#oe rburton (~Adium@host81-153-67-238.range81-153.btcentralplus.com) |
| 19:58.17 | *** join/#oe berton (~fabio@201.22.227.56) |
| 20:15.57 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 20:19.37 | *** join/#oe cbrake (~Thunderbi@cable2-pool191-cs-134.doycomm.com) |
| 20:41.13 | *** join/#oe tasslehoff (~Tasslehof@ti0260a430-0437.bb.online.no) |
| 20:46.30 | *** join/#oe cbrake (~Thunderbi@cable2-pool191-cs-134.doycomm.com) |
| 20:48.17 | *** join/#oe tasslehoff (~Tasslehof@ti0260a430-0437.bb.online.no) |
| 20:49.43 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 20:50.35 | *** join/#oe pidge (~pidge@2a02:8084:0:3000:a85e:c86:5874:2272) |
| 21:11.06 | *** join/#oe dfaught (~dfaught@cpe-70-119-105-90.tx.res.rr.com) |
| 21:17.07 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 22:07.05 | *** join/#oe paulg (~paulg@184-94-55-234.dedicated.allstream.net) |
| 22:14.21 | *** join/#oe Aethenelle (~Aethenell@166.175.61.105) |
| 22:30.13 | *** join/#oe rburton (~Adium@host81-153-67-238.range81-153.btcentralplus.com) |
| 22:40.49 | *** join/#oe rsalveti (~rsalveti@162.243.213.221) |
| 22:50.59 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 23:14.35 | *** join/#oe Lightsword (~Lightswor@104.194.126.111) |
| 23:28.21 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 23:35.37 | *** join/#oe alimon (~alimon@134.134.139.72) |
| 23:41.56 | *** join/#oe oldtopman (~oldtopman@unaffiliated/oldtopman) |