**** BEGIN LOGGING AT Wed May 21 02:59:58 2014 May 21 07:19:44 woglinde, omap_wdt works, forgot about the NOWAYOUT kernel config option May 21 08:03:26 good morning May 21 08:03:42 mckoan, morning May 21 08:34:50 hrm May 21 08:35:05 looks like meta-qt5 doesn't generate an env file for the target May 21 08:35:28 * koen gets a dejavu May 21 08:41:06 morning all May 21 08:45:21 hi bluelightning, all May 21 08:45:33 hi mckoan, koen May 21 08:45:42 hey mckoan & bluelightning May 21 08:53:39 rob_w good to know May 21 08:53:44 hi koen May 21 08:53:58 hi mckoan and bluelightning May 21 08:56:55 hi woglinde May 21 09:05:53 hey woglinde May 21 10:06:20 seriously this bitbake process splitting my images into multiple packages... it only causes ball-ache... May 21 10:07:21 I just wanna quickly compile and run linaro flashbench, but the git repo is set to build debug binaries. Bitbake notices these debug binaries and puts them in flashbench-dev that you cannot install since you can't install flashbenhch because it is empty... this entire insane system is well, insane! May 21 10:07:40 stop thinking and to what I say May 21 10:07:46 so frustrating May 21 10:09:25 pompomJuice: it depends on what files you are building and how they get laid out... some software fits less well to our defaults May 21 10:10:47 what files the software you are building produces* that is May 21 10:17:25 ... May 21 10:18:13 git://git.linaro.org/people/arnd.bergmann/flashbench.git May 21 10:18:19 its a simple little makefile project May 21 10:18:21 nothing fancy May 21 10:18:34 I make a recipy, it takes me 2 minutes May 21 10:18:57 then I start wresling with the insane system... that takes me 5 days to get the thing to release my binaries into the god damn ipk May 21 10:19:23 because it deems them to be debug May 21 10:19:28 even though the human knows better May 21 10:21:26 does someone know what I must put in here to stop insane from removing debug binaries? -> INSANE_SKIP_${PN}="??" May 21 10:23:14 insane doesn't actually do any packaging, at all May 21 10:23:20 it's what reports potential issues May 21 10:23:39 if you do not want the default packaging layout, change PACKAGES and FILES as desired May 21 10:24:13 FILES_${PN}= ... May 21 10:24:15 I do have that May 21 10:24:29 but something takes them out of my main ipk since they are debug May 21 10:24:40 AFAIK it is the insane system May 21 10:24:45 no, it isn't May 21 10:24:53 files will go into the package whose FILES matches first in the order the packages are mentioned in PACKAGES May 21 10:24:57 what part of bitbake is doing this? May 21 10:25:15 ${PN}-dbg and ${PN}-dev are *before* ${PN} in the default value of PACKAGES, it couldn't work otherwise May 21 10:25:34 aah May 21 10:26:34 this is all in package.bbclass, but you don't have to look there; just change FILES_${PN}-dev = "" or something like that May 21 10:26:47 jsut did May 21 10:26:50 compiling... May 21 10:27:01 any python gurus around May 21 10:27:09 Crofton|work: sort of... May 21 10:27:31 let me pastebin the diff between pyconfig.h for native and target builds May 21 10:28:46 http://pastebin.com/XixrJufE May 21 10:29:03 the problem line is at 15 or so May 21 10:29:10 I can't see why it is different May 21 10:29:20 ok that just made the files dissapear May 21 10:29:26 now the two binaries are nowhere May 21 10:29:35 not inserted in any IPK May 21 10:29:43 and it gets defiend for the native pyconfig.h, which leads to a build failure for ice May 21 10:29:54 pompomJuice: did you get installed but not shipped warnings? May 21 10:30:53 yes May 21 10:30:55 Crofton|work: I don't know much about this file, but if I had to guess it would be that it simply could not do the test when cross-compiling; if that's the case it would probably be a bug in how we build python for the target May 21 10:31:10 well, it look s lik eundef is correct May 21 10:31:19 pompomJuice: ok, don't ignore those - it's warning you about this exact problem May 21 10:31:22 that is what it is on the build machine May 21 10:31:30 but we get it wrong for the native case May 21 10:31:38 that is what is strange May 21 10:31:47 Crofton|work: clues in config.log for python-native? May 21 10:31:49 I guess I need to read the code May 21 10:31:55 ok May 21 10:31:56 will do May 21 10:32:03 just hoping someone had a short answer May 21 10:32:05 flashbench builds 2 binaries: flashbench and erase May 21 10:32:18 which should go into ${bindir} May 21 10:32:27 yea May 21 10:32:34 if they end up in -dev, then you weren't installing them into ${bindir} May 21 10:32:37 do_install () { May 21 10:32:38 install -d ${D}${bindir} May 21 10:32:38 install -m 0755 ${S}/erase ${D}${bindir} May 21 10:32:38 install -m 0755 ${S}/flashbench ${D}${bindir} May 21 10:32:38 } May 21 10:32:45 FILES_${PN} = "\ May 21 10:32:45 ${D}/${bindir}/erase \ May 21 10:32:45 ${D}/${bindir}/flashbench \ May 21 10:32:45 " May 21 10:32:48 that does not work May 21 10:32:55 pompomJuice: there's your problem May 21 10:33:02 what? May 21 10:33:03 tell me May 21 10:33:04 pompomJuice: remove ${D}/ from the FILES value May 21 10:33:21 omg May 21 10:33:36 take it slow bob May 21 10:33:40 remove the FILES_{PN} value completely May 21 10:33:48 yes, in fact what koen said May 21 10:33:48 ok May 21 10:33:49 ${bindir} is in there by default May 21 10:33:53 the default value will do the right thing May 21 10:34:10 in fact you can now remove the FILES_${PN}-dev = "" thing as well May 21 10:34:26 koen@beast:/build/v2013.12/sources/meta-qt5$ grep FILES_ ../openembedded-core/meta/conf/bitbake.conf May 21 10:34:27 building... May 21 10:34:29 FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \ May 21 10:34:43 aah May 21 10:35:20 now it is saying that files were not shipped May 21 10:35:30 in particular, those two binaries May 21 10:35:37 remember this does not have autotools May 21 10:35:42 doesn't matter May 21 10:35:43 and no make install May 21 10:36:06 still does not work May 21 10:36:18 you're definitely sure you removed your FILES_${PN} value? May 21 10:36:19 there is no flashbench-0.1 package May 21 10:36:23 yes May 21 10:36:41 because it's behaving like you haven't... May 21 10:36:44 SRC_URI = " \ May 21 10:36:45 git://git.linaro.org/people/arnd.bergmann/flashbench.git \ May 21 10:36:45 " May 21 10:36:45 S = "${WORKDIR}/git" May 21 10:36:45 do_compile () { May 21 10:36:45 oe_runmake -f Makefile May 21 10:36:45 } May 21 10:36:46 do_install () { May 21 10:36:46 install -d ${D}${bindir} May 21 10:36:47 install -m 0755 ${S}/erase ${D}${bindir} May 21 10:36:47 install -m 0755 ${S}/flashbench ${D}${bindir} May 21 10:36:48 } May 21 10:36:48 that is my entire recipy May 21 10:36:58 excluding licence stuff at the top May 21 10:37:02 that is on bitbake 1.20 May 21 10:37:07 yocto 1.5 May 21 10:37:12 all the latests stuff May 21 10:37:35 did a -c cleansstate May 21 10:37:46 1.6 is out already May 21 10:37:55 yea il wait with that... May 21 10:38:03 that sneaky 1.4 -1.5 move cost me 3 months May 21 10:38:24 in the end I found that memcpy from memory given to me by the syslink shared memory API breaks May 21 10:38:26 fun May 21 10:38:30 this will work just fine in 1.5 May 21 10:39:08 most likely since the new linaro uses neon to do memcpy or something... that is my guess May 21 10:39:29 bah I have to go May 21 10:39:32 damnit May 21 10:39:36 thanks for trying to help though May 21 10:39:41 be back in 30 mins May 21 10:39:44 ah syslink May 21 10:39:57 the joy of abandonded vendor kernel extensions May 21 11:37:42 btw removing FILES_${PN} is not the issue, the issue is that something sees that the files are debug and then moves them to the -dev ipk whick cannot be install because of a built in dependency to the parent package that does not exist because there are no files for it, they were moved to the -dev ipk May 21 11:38:22 its shooting itself in the foot May 21 11:38:44 what do you mean with 'files are debug'? May 21 11:38:54 debug files get moved to -dbg, not -dev May 21 11:38:57 gcc -g May 21 11:39:06 oh yea soz May 21 11:39:08 dbg May 21 11:39:11 I got those mixed May 21 11:39:16 patebin the recipe as well as the output from bitbake May 21 11:39:34 I am so used to the same happening to .so files.. they are usually moved to -dev May 21 11:40:24 http://pastebin.com/BDEpQbMB May 21 11:40:36 remove PR=r0 May 21 11:40:46 kk May 21 11:42:05 building for output May 21 11:42:13 http://hastebin.com/mixonoxajo.vbs May 21 11:42:16 that's what I get May 21 11:43:05 http://hastebin.com/uyavaqohir.rb May 21 11:43:27 do you have ipks? May 21 11:43:52 with files in them? May 21 11:45:33 I get the same prolems with some other sources that only produce .so files ( as supposed to .so.1 )... such as mono May 21 11:45:40 http://hastebin.com/wojuvuboxi.avrasm May 21 11:46:02 yea May 21 11:46:06 but that wont install May 21 11:46:18 why not? May 21 11:46:21 flashbench_git-r0.0_armv7ahf-vfp-neon.ipk has the files May 21 11:46:32 oh wait May 21 11:47:09 ok so that is on 1.6? May 21 11:47:20 I see the package names look different May 21 11:47:27 mine is May 21 11:47:31 no, 1.5 May 21 11:47:38 but that won't make a difference May 21 11:48:55 ok now I am confused May 21 11:49:03 yours is working May 21 11:49:05 mine is not May 21 11:49:15 that depends on bitbake right? May 21 11:49:20 that behaviour? May 21 11:49:23 mine is on 1.20 May 21 11:49:25 no May 21 11:49:37 where does that behaviour come from? May 21 11:49:46 the packaging behaviour that would influence that hasn't changed in years May 21 11:49:54 it's in package*bbclass and bitbake.conf May 21 11:50:09 meta-angstrom,git://github.com/Angstrom-distribution/meta-angstrom,angstrom-v2013.12-yocto1.5,HEAD May 21 11:50:20 meta-openembedded,git://github.com/Angstrom-distribution/meta-oe.git,angstrom-staging-yocto1.5,HEAD May 21 11:50:29 if you do 'bitbake flashbench -c package_write' what end up in packages-split? May 21 11:50:31 openembedded-core,git://github.com/Angstrom-distribution/oe-core.git,angstrom-staging-yocto1.5,HEAD May 21 11:50:37 checking May 21 11:51:43 interesting May 21 11:52:32 http://hastebin.com/tagodatire.sm May 21 11:52:57 the files are in flashbench/usr/bin May 21 11:53:07 as they should May 21 11:53:22 and bitbake flashbench -c package_write -f ? May 21 11:53:26 that should give you ipks May 21 11:53:45 kk May 21 11:54:24 there it is May 21 11:54:28 weird May 21 11:55:00 that worked May 21 11:55:13 the packace is located in deploy-ipks May 21 11:55:16 and that is a neat trick May 21 11:55:21 package* May 21 11:55:48 I suspect you had some caching issues where bitbake didn't pickup changes in your recipe May 21 11:56:03 aah May 21 11:56:06 I've seem some weird heisenbugs with that May 21 11:56:10 it shouldn't happen May 21 11:56:15 aah May 21 11:56:20 nuke cache? May 21 11:56:32 let me see May 21 11:56:44 a bitbake flashbench -c cleansstate would fix that May 21 11:56:55 yea I do cleansstate all the time May 21 11:57:01 you have to May 21 11:57:20 or the thing just stucks in it's current state as you know May 21 11:57:20 I wish I could reproduce those cache issue May 21 11:57:29 filing a bug without a reproducer is useless May 21 11:57:38 and gets me more comic sans spam from intel people May 21 11:58:06 rm cache/bb_codeparser.dat May 21 11:58:12 that fixes a lot of things May 21 11:58:32 yea doing that now May 21 11:58:36 if you don't bitbake will start using a few gigabyte more ram after a few builds May 21 11:58:50 keep the sqlite stuff in cache/ May 21 11:59:00 bad things happen when those go away May 21 11:59:06 oh ok May 21 11:59:11 normally I just trash the folder May 21 11:59:17 those sqlite things come through the repo May 21 11:59:23 yes May 21 11:59:25 why do cache things come down from the repo? May 21 11:59:33 to keep versions in sync May 21 11:59:34 I am sure I deleted them since May 21 11:59:40 must I restore themmm May 21 11:59:44 as bad things are happening May 21 11:59:59 if you delete them the build will produce foo_1.0-r0.0.ipk May 21 12:00:08 the online feeds will have foo_1.0-r0.5.ipk May 21 12:00:10 aah May 21 12:00:19 that is what I have May 21 12:00:42 I thought that was part of a new system that enables "upgrades" since versions that stay the same get pertubated with .5? May 21 12:00:46 to avoid 'opkg update' doing spurious updates the sqlite files are in git May 21 12:00:55 which of course is a binary merge nightmare :( May 21 12:01:02 yea disaster May 21 12:01:10 but importing the info with bitbake-prserv-tool takes ~3 minutes May 21 12:01:12 does that even work May 21 12:01:38 no, binary merges don't work May 21 12:01:39 do you think I broke something by deleteing those files"? May 21 12:01:44 better, they don't even exist May 21 12:02:06 'opkg update ; opkg upgrade' will try to upgrade nearly everything May 21 12:02:14 koen: do not discourage people from filing bugs, please May 21 12:02:15 ok but it worked May 21 12:02:35 somehow May 21 12:02:37 it worked May 21 12:02:45 your package_write -f May 21 12:02:53 somehow got the thing to make new ipks May 21 12:03:02 they are now located in the deploy folder May 21 12:03:12 * pompomJuice happy May 21 12:04:02 aand poof it worked May 21 12:04:14 seems we unlocked it somehow May 21 12:04:57 why did you say I must remove PR? May 21 12:05:07 I use PR to indeicate recipy changes...? May 21 12:05:19 but lately bitbake has been incredible in detecting changes... May 21 12:05:28 it even knows that I change "patch" files May 21 12:05:49 right May 21 12:05:58 that's why I called it 'heisenbugs' May 21 12:06:04 it works about 98% of the time May 21 12:06:12 lol May 21 12:06:15 bizarre May 21 12:06:58 this is unlikely to be a cache bug May 21 12:07:00 * koen stabs meta-qt5 again for not being able to used to on-target builds May 21 12:27:13 bluelightning, looks like the patch that fixes the issue is applied to pyhton but not python-native May 21 12:27:15 testing now May 21 12:28:36 that reminds me, we really ought to upgrade to a new version of Python 2.7 May 21 12:28:42 yeah May 21 12:28:53 if someone feels like taking that task on, I did make a start on it last cycle May 21 12:28:56 I just need to fix the host contaminatoin May 21 12:29:21 looks like the guy that did the work weaseled around the root cause, and used host python :) May 21 12:30:11 yep May 21 12:30:19 let me make a patch for python-native May 21 12:30:32 frak more backports for diane May 21 12:31:14 adelcast, gm May 21 12:47:28 annoying, the oe-core READm lacks the git send-email line to copy/paste May 21 12:48:05 is anyone around who has experience with meta-mingw ? I'm trying to use it but run into build errors. May 21 12:51:56 meta-mingw ? is it supposed to work ? May 21 12:53:06 Crofton|work: much easier to set the options in the .git/config file for the repository May 21 12:53:23 then you never have to remember the appropriate options again May 21 12:53:36 well, nothing in the README about that either :) May 21 12:53:45 yes, i am cranky this morning May 21 12:53:46 Crofton|work: no, there isn't May 21 12:54:04 yet another reference to the Yocto Project as a build system on the tubes May 21 12:54:08 basically add this http://pastebin.com/hpTvT74s May 21 12:54:39 bencoh: I don't know. I assume that's the point of it. :-) (http://layers.openembedded.org/layerindex/branch/dylan/layer/meta-mingw/) May 21 12:56:07 hm btw, not sure the default separate builddir in autotools.bbclass was a good idea May 21 12:57:17 bencoh: why not? May 21 12:57:40 stefan__: could you pastebin the error you are getting? May 21 12:59:09 bluelightning: sure, one sec. May 21 13:00:41 bluelightning: it's been getting on my nerves the whole morning to the point I ended up changing .bbclass to B = $S :] May 21 13:00:52 too many broken packages May 21 13:09:44 bencoh: there is patch on ML to set it only in broken recipes May 21 13:10:10 bencoh: well for the layers which are included in my world builds May 21 13:11:31 koen: I'm not very keen on that meta-qt5 backport, the usage of path variable is documented on wiki and I don't want to change behavior in release branch (even that in this case it's not dangerous) May 21 13:12:04 JaMa: I needed it to build stuff against qt5 May 21 13:12:51 koen: https://github.com/meta-qt5/meta-qt5/wiki/Building-with-OE#bad-include-paths-and-build-failing-to-find-qt5-headers May 21 13:14:42 JaMa: oh ? May 21 13:14:50 Crofton|work: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Streamlining_git-send-email_with_configuration May 21 13:15:00 JaMa: autotools-brokensep, or something else ? May 21 13:15:14 bencoh: it's a change for the better in the long run May 21 13:15:20 bluelightning: yeah :) May 21 13:15:28 we're just not there yet though May 21 13:15:44 bencoh: yes B=S or brokensep May 21 13:16:39 JaMa: the backport makes more things work "out of the box", which I why I proposed it May 21 13:19:40 * koen gets back to trying to generate a qt.conf use on the target May 21 13:20:30 JaMa: btw, getting the target qmake to build and work wasn't hard, just a matter of S=B and a few small tweaks (adding -p to mkdir) May 21 13:20:49 JaMa: is S!=B a hard requirement for qtbase or can we disable it to get qmake? May 21 13:34:13 bluelightning: sorry for the latency, got caught in a conference call... May 21 13:34:25 bluelightning: so my problem with producing the mingw SDK is this: May 21 13:35:35 nativesdk-mingw-w64-runtime_2.0.8.bb runs do_configure, which fails, because configure can't find the compiler. (The specific error from config.log is: May 21 13:36:07 stefan__: which version of the build system are you building with? May 21 13:36:13 /usr/local/OpenEmbedded/yocto/poky/build/tmp/work/x86_64-nativesdk-mingw32-pokysdk-mingw32/nativesdk-mingw-w64-runtime/2.0.8-r0/mingw-w64-v2.0.8/mingw-w64-crt/configure: line 3184: x86_64-pokysdk-mingw32-gcc: command not found May 21 13:36:44 I'm working with the 'daisy' branch. May 21 13:37:02 should I retry with master ? May 21 13:38:09 stefan__: no, I wouldn't expect much difference, and you're better off with daisy unless you need to be on the bleeding edge (and daisy is fairly new already) May 21 13:38:29 but I'm also not sure why there would be a configure task involving a target compiler (where 'target' is not the OE target, but the host) May 21 13:38:39 right, thought so. May 21 13:39:58 stefan__: Which SDKMACHINE is that with? May 21 13:40:28 RP: x86_64-mingw32 May 21 13:40:45 (I'm trying your meta-mingw layer...) May 21 13:40:52 stefan__: high BB_NUMBER_THREADS? May 21 13:41:13 yeah, the default (which I always find too high) May 21 13:41:26 is there a race condition involved ? May 21 13:41:55 stefan__: I'm wondering if there is a missing dependency. You could try "bitbake gcc-crosssdk-initial", "bitbake gcc-crosssdk" and then retry your original command May 21 13:42:02 ("the default" == "BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"") May 21 13:43:31 Actually, this is the second invocation. The first time I got lots of errors on the terminal which I failed to redirect into a file (errors during the sysroot setup due to header files not being found...) May 21 13:43:56 Then I just restarted (with "&> log" appended), and got this new error I'm reporting here. May 21 13:45:22 stefan__: logs should be in tmp/logs/cooker FWIW May 21 13:46:59 RP: so I tried running the steps individually as you suggested. The first (gcc-crosssdk-initial) was already completed. gcc-crosssdk then fails, with the same log as above. May 21 13:47:26 stefan__: DISTRO=poky? May 21 13:47:44 yes May 21 13:48:08 stefan__: I'm just seeing if this will reproduce here May 21 13:48:24 great, thanks. May 21 13:48:39 stefan__: it doesn't :( May 21 13:48:47 darn May 21 13:49:24 Well, "find . -name x86_64-pokysdk-mingw32-gcc" does find something. It just isn't in the PATH it seems. May 21 13:49:55 stefan__: does ls tmp/sysroots/x86_64-linux/usr/bin/x86_64-pokysdk-mingw32.gcc-crosssdk-initial/ show the gcc ? May 21 13:50:29 yes, with prefix (x86_64-pokysdk-mingw32-gcc) May 21 13:51:24 stefan__: can you confirm that binary executes ok? May 21 13:51:30 so that path should be in the env when configure is invoked ? May 21 13:51:38 koen: I would prefer to keep B!=S in qmake5, because when I was initially working on meta-qt5 I was hit by incorectly "pre-configured" B many times May 21 13:51:40 stefan__: I think so May 21 13:51:54 it does execute fine (with the usual error message "...no input files" May 21 13:52:35 stefan__: You are using the daisy branch of meta-mingw? May 21 13:52:48 I don't think so. May 21 13:53:00 just the default (master ?) May 21 13:53:07 stefan__: aha, use daisy May 21 13:53:25 * stefan__ switches and retries May 21 13:55:04 do I need to make clean ? Just rebuilding yields the same errors. May 21 13:56:19 stefan__: just to be clear, you now have daisy main metadata and meta-mingw daisy ? May 21 13:56:23 oups, pilot error. ('daisy' != 'origin/daisy') May 21 13:56:35 stefan__: I'd have thought it would rebuilt things... May 21 13:57:20 still no joy. May 21 14:02:51 stefan__: well, the mingw-w64-runtime recipe does: May 21 14:02:51 STAGINGCC_class-nativesdk = "gcc-crosssdk-initial" May 21 14:02:51 PATH_prepend = "${STAGING_BINDIR_TOOLCHAIN}.${STAGINGCC}:" May 21 14:03:08 stefan__: so somehow its not seeing that or not having the right effect :/ May 21 14:04:08 * stefan__ tries to debug that May 21 14:12:11 stefan__: bitbake nativesdk-mingw-w64-runtime -e | grep PATH= and similar might help May 21 14:13:25 yeah, I'm looking at something similar. What does "${STAGINGCC}" expand to ? May 21 14:13:57 oups, just a few lines up. :-) May 21 14:15:08 hmm, I can't see any "gcc-cross-initial" in PATH, so that PATH_prepend doesn't seem to have happened. May 21 14:15:50 is there a way to inject print commands right into .bb files ? May 21 14:17:46 stefan__: you're looking for gcc-crosssdk-initial May 21 14:18:04 which should be the value STAGINGCC will have taken May 21 14:19:45 that isn't in PATH either. May 21 14:25:34 is there a way to debug (i.e., trace) all this variable assignment and expansion business ? May 21 14:29:28 moin May 21 14:29:55 * nerdboy waves at RP May 21 14:30:03 hi nerdboy May 21 14:30:32 stefan__: if you look at the full output of -e, that is pretty much the method available May 21 14:30:56 stefan__: there should be a variable history in there May 21 14:33:49 still not sure why gentoo amd64 multilib and libpseudo don't get along... May 21 14:40:46 JaMa: I'll see if I can make target qmake work with B!=S, if that fails I guess I can make a qmake_5.x.bb recipe May 21 14:43:28 RP: what is the best target to use if I only want to build the SDK, i.e. if I'm not interested in the target image ? May 21 14:43:40 sorry for the 'target' overload. :-) May 21 14:44:11 stefan__: gcc-cross-canadian May 21 14:44:34 * RP suspects you'll not get around the error that way May 21 14:44:45 right, that was a separate question May 21 14:45:01 stefan__: if you pastebin the complete failure including the header I can take a look and see if I can spot anything obvious May 21 14:45:20 what do you mean by "header" ? May 21 14:46:20 stefan__: the bit which says "Build Configuration:" May 21 14:47:06 ok, so the full output of "bitbake gcc-crosssdk " ? May 21 14:49:30 RP: http://pastebin.com/ecnjrriY May 21 14:51:32 stefan__: that is quite a different error to the one you pasted earlier :( May 21 14:51:35 stefan__: can you also post the config.log stuff? May 21 14:51:45 RP: hi, I didn't pay attention..are we building with gcc 4.9 already? May 21 14:51:48 stefan__: we need to see the contents of config.log May 21 14:51:56 ant_work: not by default quite yet May 21 14:52:02 ant_work: but its there May 21 14:54:13 RP, nerdboy: http://pastebin.com/6qzD9J0y May 21 14:54:38 stefan__: stdio.h: No such file or directory - header issues May 21 14:54:49 stefan__: can you clean tmp and start again now you have the right branches May 21 14:54:54 stefan__: we need to rule that out May 21 14:55:05 RP: just this knob? May 21 14:55:05 GCCVERSION ?= "4.8%" May 21 14:55:30 error: no include path in which to search for limits.h May 21 14:55:48 RP: do I need to blow away the entire tmp/ dir ? May 21 14:56:33 you can try the previous command with -c cleansstate May 21 14:56:55 but might need to nuke the whole thing and rebuild... May 21 14:57:50 ant_work: yes May 21 14:57:54 ok. This is going to take a while... May 21 14:58:12 stefan__: At this point I think you need to build something known good May 21 14:58:14 RP: ok, I'll have fun tonite May 21 14:58:58 RP: yeah, right. Switching branches in the middle of a build isn't helpful. :-) May 21 15:00:33 why do you have mixed paths? => /opt/poky/1.6/sysroots/x86_64-pokysdk-mingw32/usr/include May 21 15:00:40 that doesn't look right... May 21 15:01:25 everything should be under /usr/local/OpenEmbedded/yocto/poky/build/tmp/... May 21 15:01:56 stefan__: can you check your *.conf paths? May 21 15:03:13 nerdboy: I definitely haven't added any "/opt/poky/..." paths anywhere. Where should I look ? May 21 15:03:33 local.conf first i guess May 21 15:03:50 that's clean. May 21 15:04:20 then i don't get the /opt/poky part May 21 15:05:34 perhaps that's a prefix injected by meta-mingw ? May 21 15:05:43 it's still early, but i'm pretty sure that should be /usr/local/OpenEmbedded/yocto/poky/build/tmp/sysroots/x86_64-nativesdk-mingw32-pokysdk-mingw32/usr/include May 21 15:06:50 * nerdboy goes to fire up the coffee May 21 15:15:58 vim fails May 21 15:16:08 | touch: cannot touch 'auto/config.mk': No such file or directory May 21 15:18:57 look sliek S != B issues May 21 15:19:29 meh May 21 15:19:30 :) May 21 15:19:47 fix it the wrong way or figure out the right way? May 21 15:19:51 that is the question May 21 15:28:19 anarsoul: should I take that version of the DMA patch or the revised one on LAKML ? May 21 15:28:49 ant_work: well, take the version which I sent to you, it works May 21 15:28:57 ok, thx May 21 15:28:59 any advice on fixing this: http://pastebin.com/W71Srg7w May 21 15:29:04 fro S != B May 21 15:45:25 Crofton|work: i tend to separate the autoconf stuff from the actual configure May 21 15:46:05 can you be more specific May 21 15:46:08 had an issue not long ago where it only worked as a separate task, but in do_configure it failed May 21 15:46:14 I jsut hacked in the S's and B's :) May 21 15:46:25 :) May 21 15:47:05 there seems to be some funkiness in how the autotools stuff works in do_configure May 21 15:47:24 * nerdboy not the auto-expert May 21 15:47:58 i just beat on it until i get tired or it does what i want... May 21 15:48:43 RP, nerdboy: this time the build finished successfully. Yay ! :-) May 21 15:48:55 stefan__: great :) May 21 15:49:00 good deal May 21 15:51:36 Crofton|work: aclocal and autoconf must run in ${S} sinc they write configure from configure.ac and aclocal.m4 from the other macros. oe_runconf should run in ${B}. May 21 15:52:05 Crofton|work: also, the way that hardcodes those things rathe rthan using autotools.bbclass is pretty gross :) May 21 15:52:17 (i realize you probably weren't the one that wrote that, but on general principle) May 21 15:52:17 yeah May 21 15:52:50 so you'd probably want to cd ${S}, do your autoconf stuff, then cd back to ${B} to do the configure May 21 15:53:03 afaik thats a pretty common pattern in do_configures like this one May 21 15:53:03 what is the default for do_configure? May 21 15:53:11 read autotools.bbclass :) May 21 15:53:14 trying with the mess commented out May 21 15:53:35 ah, the whole do_configure task commented? worth a shot, certainly May 21 15:53:36 RP: I do have a few followup questions. Since I have just built a mingw compiler (with sysroot), what would be the most appropriate package to use for this so I can install it on Windows ? Right now I only have rpms. May 21 15:53:38 | NOTE: make DESTDIR=/home/balister/src/oe-core/build/tmp-eglibc/work/armv7at2hf-vfp-neon-oe-linux-gnueabi/vim/7.4.258-r0/image install May 21 15:53:38 | make: *** No rule to make target `install'. Stop. May 21 15:54:06 s/package/package format/ May 21 15:54:21 Crofton|work: here's the example i was thinking of: https://github.com/openembedded/meta-oe/commit/b306212c8919a8638d5e97acfd6262bcbd3401ed May 21 15:54:45 stefan__: didn't it build a zip? May 21 15:55:05 Crofton|work: also what kergoth said... May 21 15:55:06 stefan__: tmp/deploy/sdk/ ? May 21 15:55:25 RP: there is no sdk/ in tmp/deploy/, only rpm/ and licenses/ May 21 15:55:34 stefan__: what did you build? May 21 15:55:44 stefan__: bitbake meta-toolchain is probably what you want May 21 15:55:58 nerdboy: fyi, i see a problem in that commit. it relies on bitbake's hardcoded built in 'dirs' flag. when you create a new task and assume it runs from somewhere in particular, sit should really have do_src_prepare[dirs] = "${S}" :) May 21 15:56:04 s/sit/it/ May 21 15:56:33 basically in general no one should assume that they know where a new task will run from, just to keep people aware May 21 15:56:46 we want to kill bitbake's dirs flag default at some point, so it's something to be aware of May 21 15:56:57 good to know... May 21 15:57:24 heh, gentoo went the other way a while back May 21 15:57:43 our problem is we want to retain the bitbake vs oe separation, and right now bitbake has knowledge of ${B} May 21 15:57:44 RP: OK, running that now. The second question is how I can add packages to be included in the SDK. May 21 15:57:46 Bad Thing(tm) May 21 15:58:01 (In fact, I would assume that question to be answered in some online document, I just didn't find it.) May 21 15:58:18 kergoth: curse you for caring about coupling and information hiding May 21 15:58:41 nerdboy: you wouldn't know I care about such things if were to read the old bitbake code... but that was written a long time ago :) May 21 15:58:54 stefan__: the same way you would with the linux version of the sdk. bitbake -c populate_sdk will build an SDK that corresponds to the image's contents May 21 15:59:21 damn, i really don't sound much like a geophysics guy anymore... May 21 15:59:55 RP: right. But how do I add packages, i.e. how do I indicate in the recipe of a package that it is going to be part of the SDK, not just the target ? May 21 16:00:13 (I'm talking about a tool, not a library) May 21 16:01:42 the "normal" way would be the image recipe May 21 16:02:20 ie, bitbake image_name -c do_populate_sdk May 21 16:03:24 stefan__: target recipes can be freely included in the sdk's target sysroot. if it's a build tool, you need a nativesdk variant (add nativesdk to BBCLASSEXTEND), then you could add nativesdk-yourrecipe to the host syroot of the sdk May 21 16:04:41 * stefan__ isn't sure he can semantically analyze that yet, but will store that info for later use. :-) May 21 16:04:42 nerdboy: that commit reminds me, I think it'd be cool to provide, in our classes, a pre-configure "prepare the source tree" task, which is only run if it's defined. then recipes could just define the function and it'd be used, no messing with adding tasks May 21 16:04:57 in the classic setup i "inherited" the previous guy had made his own meta-toolchain tasks and added package names May 21 16:05:22 kergoth: i like that May 21 16:05:53 it seems to be a common pattern, and it'd make our recipes at least slightly more declarative May 21 16:05:54 seem like src prep and configure need some real separation May 21 17:28:52 RP: OK, I got much further, but still an error: "ERROR: nativesdk-packagegroup-sdk-host not found in the base feeds (x86_64-nativesdk-mingw32 noarch any all)." May 21 17:29:25 (in the meta-toolchain do_populate_sdk task) May 21 17:29:53 all, I'm having an issue connecting to WPA-enterprise networks when switching from dylan to dora branches of yocto build system. My issue is similar to: http://shr-project.org/trac/ticket/2107 . I was wondering if anyone has seen this issue before, and if there was an actual solution that allows CONFIG_WPS to be enabled? May 21 17:34:26 morphis, I believe the commit that introduced this came from you https://github.com/openembedded/oe-core/commit/2e4d939b6a0061eec22b859a827dedda51b299ba May 21 17:35:06 morphis, do you have any idea on some dependencies that may be required with this change? May 21 17:35:14 how do I make a user on angstrom have root access? May 21 17:37:29 you mean install sudo? May 21 17:38:33 why is -natine appended and nativesdk- prepended? to confuse me? May 21 17:41:13 JBD1986: what are you using on top of wpa-supplicant to connect to the network? May 21 17:42:02 JBD1986: if only wpa-supplicant maybe ask on the wpa-supplicant mailinglist May 21 17:42:07 didn't saw a problem with it yet May 21 17:46:17 morphis, we're using connman 1.21 May 21 17:46:33 JBD1986: maybe also ask in #connman May 21 17:46:52 I already tried connman, they referred me to wpa_supplicant lol May 21 17:47:27 kergoth: any idea about the above error ? May 21 17:47:35 the issue is definitely resolved by removing CONFIG_WPS from wpa_supplicant May 21 17:50:19 no idea May 21 17:53:33 JBD1986: but removing CONFIG_WPS isn't a real solution May 21 17:53:44 so there is a problem somewhere inside the stack May 21 17:54:02 ask in #connman I am sure they will help you May 21 18:49:22 * kergoth experiments with automatic set/unset of noexec flags based on conditions May 21 18:54:16 * nerdboy scrounges a power brick for the udoo thing **** BEGIN LOGGING AT Thu May 22 02:25:11 2014 **** ENDING LOGGING AT Thu May 22 02:59:58 2014