**** BEGIN LOGGING AT Thu Sep 05 03:00:00 2013 Sep 05 06:49:37 good morning Sep 05 06:54:07 Hi I created a native recipe and copied stuff to the $datadir Sep 05 06:54:23 How can I access that data from other recipes Sep 05 06:54:41 If I copy to bin dir then I can just use the command directly Sep 05 06:55:00 but from $datadir I am not sure. Anybody know?? Sep 05 06:58:20 [09:54] Hi I created a native recipe and copied stuff to the $datadir [09:54] How can I access that data from other recipes [09:54] If I copy to bin dir then I can just use the command directly [09:55] but from $datadir I am not sure. Anybody know?? Sep 05 06:58:23 ?? Sep 05 06:58:51 Any help much appreciated Sep 05 07:38:59 hi, is the meta-networking maintainer, Joe using irc? Sep 05 07:46:00 what is this error again? http://paste.kde.org/~lpapp/p9734f00f/ Sep 05 07:50:35 i suppose that if you ask, you already check that the file exists, right? Sep 05 07:50:35 No such file or directory: '/home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf' Sep 05 07:51:36 it is a fresh denzil branch checkout. Sep 05 07:51:59 I do not understand why it would complain about non-existent files with a fresh and default state. Sep 05 07:53:35 there is no meta-yocto-bsp in denzil? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/?h=denzil&id=6caa7d1d6c122d084ed01d1f5e1dae0bf259f854 Sep 05 07:54:30 lpapp: you might be using conf/bblayer.conf fom dylan then. Sep 05 07:54:56 ndec: that might be true, yes. Sep 05 07:55:52 it is better to delete that file, and add stuff manually again. Sep 05 07:58:03 ndec: ERROR: Layer dependency core of layer networking-layer not found Sep 05 07:58:24 lpapp: make sure that meta-oe is on denzil branch also Sep 05 07:58:43 nrossi: ?? Sep 05 07:58:55 I think it is because meta did not have the core name in denzil. Sep 05 07:59:58 but then how can I depend on a layer with denzil? Sep 05 08:02:14 I guess I simply cannot. Sep 05 08:04:42 lpapp: are you using any other additional layers apart from meta-sourcery and the layers in poky? Sep 05 08:05:04 nrossi: denzil does not need meta-sourcery Sep 05 08:05:15 nrossi: yes, I am using additional layers. Sep 05 08:07:29 JaMa: why is it called qt5-layer rather than qt5? core is also called "core" rather than "core-layer". The "layer" is somewhat duplication as it is implicit in the context. Sep 05 08:08:31 lpapp: consistency with meta-oe layers Sep 05 08:08:52 that is unfortunate. Sep 05 08:09:18 nrossi: no, it's all in meta-yocto Sep 05 08:11:56 do I understand correctly that SDK is good for people who would like to develop applications on your platforms built by Yocto? Sep 05 08:12:11 i.e. if we do the whole stack ourselves, it is not much of use? Sep 05 08:15:07 morning all Sep 05 08:25:57 lpapp: i think you are right. Sep 05 08:26:12 about SDK, i mean. Sep 05 08:33:31 bluelightning: good morning Sep 05 08:56:16 ndec: right. Sep 05 09:00:05 rburton: hi ! my build have succeeded, however I still have /yocto/poky/thinkpad/tmp/sysroots/chiefriver/usr/lib/libX11.so etc ... does this mean it hasn't succeeded or is it normal ? Sep 05 09:02:52 elbc_: if you didn't wipe your sysroot they won't have been deleted, so you should check the image Sep 05 09:03:13 ok thanks ! Sep 05 09:03:48 elbc_: the wipe-sysroot will cleanly delete just the sysroot so you can re-build quickly to verify Sep 05 09:05:27 rburton: how do I do use this exactly ? sorry for my lack of knowledge Sep 05 09:05:34 just run wipe-sysroot Sep 05 09:05:40 ok thanks ! Sep 05 09:06:07 sorry, forgot to say "the wipe-sysroot script" Sep 05 09:06:21 wiper.sh ? Sep 05 09:06:48 if its not on your path then you haven't sourced oe-init-build-env Sep 05 09:07:00 which you need to do so it knows what to delete Sep 05 09:07:02 (as it runs bitbake) Sep 05 09:08:53 ok I've found, running it and after bitbake core-image-opencpn again ? Sep 05 09:08:58 yes Sep 05 09:09:02 thks Sep 05 09:16:49 rburton: I still have the libx11 in several directories, but maybe it's not efficient, I don't know Sep 05 09:25:11 Hi how can I access data from datadir ? Sep 05 09:26:09 I copy stuff to datadir in native recipe and what to access that data from other recipe Sep 05 09:26:11 s? Sep 05 09:26:37 rburton: I think my problem is solved, thank you very much for your time ! Sep 05 09:31:31 Guest49245 / mike: if recipe a-native installs files to ${D}${datadir} in do_install and recipe b has "a-native" in DEPENDS, then the files should be available in ${STAGING_DATADIR_NATIVE} when b's do_configure (and later tasks) executes Sep 05 09:32:11 elbc_: no problem Sep 05 09:35:07 ok thanks bluelightning. I try that Sep 05 09:36:15 Hah.... found this article guys: http://lpapp.blogspot.dk/2013/07/yocto-mature-or-not.html Sep 05 09:41:49 I'll be nice. Sep 05 10:40:31 bluelightning : how can I access that variable if I call a shell script from the recipe without passing the variable to the shell script? Sep 05 10:44:47 Guest49245: you need to either pass the variable directly to the script on its command line, or export a variable containing the value (or export the variable itself, whichever is more appropriate) Sep 05 10:45:02 Guest49245: some variables are exported by default, but STAGING_DATADIR_NATIVE is not one of them AFAIK Sep 05 10:48:09 alright Sep 05 10:50:23 bluelightning : what is the syntax to export variable Sep 05 10:50:38 Guest49245: export VARIABLENAME Sep 05 10:50:52 alright Sep 05 10:51:10 if you do that outside of a shell function it'll export the bitbake variable of that name Sep 05 10:51:30 within a shell function you'd probably need to do export VARIABLENAME=${VARIABLENAME} Sep 05 10:52:09 it's worth noting that outside of a shell function export will export the variable for all tasks associated with the recipe, not just a single one Sep 05 10:53:48 alright. Sep 05 12:09:17 bluelightning : how to do addtask for a shell function Sep 05 12:09:36 is syntax similar. At least its not running the function Sep 05 12:09:47 I changed the function from python to shell Sep 05 12:09:49 ? Sep 05 12:10:06 Guest49245: if it's not an already added task function it won't run automatically no... Sep 05 12:10:27 addtask yourfunction after do_someothertask Sep 05 12:10:49 but the question is do you really need another task for what you're doing? Sep 05 12:10:50 ok so syntax is same whether function is python or shell Sep 05 12:10:55 yes Sep 05 12:11:40 its a long story Sep 05 12:11:51 but this is way I attempt for now Sep 05 12:14:43 it doesnt run the new task anymore for some reason Sep 05 12:17:12 ok it is running but doesnt print the bbwarn messages like in pyhon Sep 05 12:18:02 Guest49245: the shell logging only goes to the logfiles unfortunately Sep 05 12:22:38 rburton: if you're available I might need your help Sep 05 12:23:04 ERROR: Nothing PROVIDES 'virtual/libx11' (but /home/elebideau/yocto/poky/meta/recipes-support/consolekit/consolekit_0.4.6.bb DEPENDS on or otherwise requires it) Sep 05 12:24:13 I've succeeded to build pulseaudio without any dependencies to libx11 at all, but doing a cleanall on my image before building displays me this error Sep 05 12:25:00 need to remove completeley this virtual/libx11 thing (still want to using wayland and just wayland) Sep 05 12:35:08 Does anyone here know about wget and SSL? The ca-certificates recipe contains a number of certificates, but it seems that since Amazon started using a new cert with a larger keysize I can't wget from https:// amazon urs, getting "self-signed certificate encountered" Sep 05 12:35:31 But what bugs me is that all the ca-certs that have anything to do with DigiCert (The cert it complains about) have identical checksums to on my debian box, where things do work. Sep 05 12:36:08 The only difference is that I have a certificate missing on the box, which I have on my own system. This seems to be the "right" certificate - But is only part of libpurple, and what's worse, moving it out of its proper location doesn't cause the failture. Sep 05 12:36:09 Any hints? Sep 05 12:55:31 elbc_: what are you building that needs consolekit? Sep 05 12:56:09 still the same image https://github.com/alan-mushi/meta-opencpn/wiki/Requirements Sep 05 12:57:04 my goal is to have this same image, but without any traces of virtual/libx11 (I just want to use wayland) Sep 05 13:00:40 sure, I understand the requirements, but the question is what is it in what you are building that depends on consolekit, and is it really needed? Sep 05 13:05:16 I don't know is consolekit is needed, but I have no right to remove it Sep 05 13:06:09 by "what is it in what you are building that depends on consolekit" do you mean the RDEPENDS line Sep 05 13:06:10 ? Sep 05 13:32:48 elbc_: the error where it says it can't build x11 might tell you the entire dependency chain Sep 05 14:38:05 does the ADT support Qt out of the box? Sep 05 14:55:30 zeddii, I am having a wierd patch failure Sep 05 14:55:43 is there anyway to get more infor on how the patch failed to apply? Sep 05 15:00:41 we really need to get some more *useful* debug messages in bitbake Sep 05 15:00:49 not just what it's doing, but *why*, would be ideal Sep 05 15:02:51 Crofton: log.do_patch? or maybe run bitbake with just the failing recipe and use the "-v" option? or maybe set PATCHRESOLVE to ""? Sep 05 15:03:38 guys, is yocto-kernel much different from vanilla one? Sep 05 15:09:41 n01: iirc, vanilla with fixes, mostly backports/reverts Sep 05 15:12:15 uhm the problem is that I have kernel patches made by customer on vanilla kernel Sep 05 15:12:47 rburton: do you suggest to go with linux-yocto-custom? Sep 05 15:14:06 n01: you may find they just apply to linux-yocto Sep 05 15:14:28 * rburton points at zeddii etc for real kernel advice Sep 05 15:14:57 rburton: yep, but this could be not true for future patches Sep 05 15:15:19 I think it would be safer to work with vanilla kernel Sep 05 15:16:00 hi, I am getting this error when trying to patch net-snmp, http://paste.kde.org/~lpapp/p6c53f68c/ Sep 05 15:16:07 why is this patch not applying correctly? Sep 05 15:16:22 this is where I got the patch from, http://patches.openembedded.org/patch/20563/ Sep 05 15:16:33 oh, wow Sep 05 15:16:39 d'oh, my bad Sep 05 15:16:44 lpapp: :) Sep 05 15:17:20 lpapp: publicly announcing a problem is a sure way to make the obvious problems apparent straight away Sep 05 15:17:46 zeddii: any suggestion? Sep 05 15:18:49 rburton: and shoot myself in the foot. :) Sep 05 15:18:56 anyway, this should be applied against the latest as well Sep 05 15:19:04 I need to figure out why it was dropped in latest meta-networking. Sep 05 15:19:25 perhaps because they updated libnl Sep 05 15:19:33 and it is not needed anymore accordingly. Sep 05 15:19:58 although the patch would make meta-networking / net-snmp work against denzil, so I think it is still useful if otherwise it does not introduce any harm. Sep 05 15:22:24 how can I check if a patch is applied succesfully? Sep 05 15:22:40 lpapp: the do_patch log will say what patches were applied Sep 05 15:22:50 if it doesn't apply cleanly, do_patch fails Sep 05 15:23:27 is there a patch command for bitbake? Sep 05 15:23:30 * Crofton|work curses the do_patch log Sep 05 15:23:31 bitbake -c patch or something Sep 05 15:23:43 bb after lunch to figure this out Sep 05 15:24:02 NOTE: Applying patch 'net-snmp-libnl.patch' (../meta/recipes-foo/net-snmp/net-snmp-libnl.patch) Sep 05 15:24:05 rburton: ^ Sep 05 15:24:12 but I am still getting the same issue as before.... Sep 05 15:24:21 what the patch was supposed to solve.... Sep 05 15:24:32 bitbake net-snmp -c clean && bitbake net-snmp Sep 05 15:24:35 this is what I ran. Sep 05 15:25:01 then the patch doesn't actually solve your problem... Sep 05 15:25:02 best off just dropping into ${S} and running quilt push, i think. that'd try applying it again. it always does a dry-run first, so it doesn't leave the source in a half-applied state unless you quilt pu -f Sep 05 15:25:46 * lpapp will rm -rf everything except conf to make sure Sep 05 15:26:06 lpapp: -c clean will wipe out the work directory for that recipe Sep 05 15:26:10 so that's all the cleaning you need Sep 05 15:26:25 practice disagrees with that on my side. Sep 05 15:27:02 it doesn't wipe existing built packages, or the sstate Sep 05 15:27:10 NOTE: package net-snmp-5.7.2-r1: task do_patch: Succeeded Sep 05 15:27:14 but it most certainly does wipe the work directory Sep 05 15:28:30 ok, I am getting a different issue now Sep 05 15:28:35 patches welcome, they say... :D Sep 05 15:28:59 hmm, no, it is the same'ish Sep 05 15:30:24 khem: there? Sep 05 15:30:45 khem: you added systemd-rpm-macros, but surely as we built own our spec files thats entirely useless in yocto Sep 05 15:33:46 rburton: I have put the change accidentally beside the recipe Sep 05 15:33:49 and it did not get apply Sep 05 15:33:56 why did bitbake not complain it did not find the patch there?! Sep 05 15:34:05 where it looked for it Sep 05 15:34:10 as it was listed in the recipe ... Sep 05 15:34:19 I would kinda expect an error, or at least warning... Sep 05 15:35:12 still does not apply even from files, sig Sep 05 15:35:13 h Sep 05 15:35:17 what am I doing wrong, seriously? Sep 05 15:35:26 oh... Sep 05 15:35:44 right... Sep 05 15:35:47 I downloaded the patch Sep 05 15:35:53 and just removed the stuff for the recipe.... Sep 05 15:35:58 so I got a double patched patch... Sep 05 15:35:59 funky... Sep 05 15:37:37 is there any simple way on patchflow to get one raw file? Sep 05 15:37:42 rather than the whole double patched stuff? Sep 05 15:38:21 sigh, I do not even see a raw version on patchwork ... Sep 05 15:38:28 isn't there a nicer solution for tracking changes? Sep 05 15:38:28 its the patch, which contains a patch Sep 05 15:38:32 so apply it to your local tree Sep 05 15:38:49 of course I cannot Sep 05 15:38:51 if you can't do that, then just apply it to anywhere and you'll get the directory Sep 05 15:38:55 since it is a terribly old patch Sep 05 15:38:55 s/directory/file/ Sep 05 15:39:07 and it is definitely not for the denzil tree with custom recipes, custom location, etc etc etc Sep 05 15:39:15 so what I would need is the *raw* content Sep 05 15:39:24 of the patch, and copy/paste stuff out what I need Sep 05 15:39:57 seriously, this is where gerrit beats patchwork thousand times Sep 05 15:40:09 you can simply do this in gerrit without this pain an hour debugging. Sep 05 15:41:23 also, that patch does not apply against the latest networking either. :( Sep 05 15:41:33 what a mess Sep 05 15:46:39 lpapp: apply the patch to an empty directory, and you'll get the subpatch out Sep 05 15:47:17 rburton: I already got the patch out. Sep 05 15:47:24 the current problem is that it does not apply against 5.7.2 Sep 05 15:47:28 although it was made against 5.7. Sep 05 15:47:30 1 Sep 05 15:48:10 * lpapp will rewrite the patch from scratch Sep 05 15:49:43 perhaps bitbake could help here? Sep 05 15:49:50 I am sure there could be a feature to update changes automatically. Sep 05 15:49:57 in the simplest cases. Sep 05 15:51:02 lpapp: patch will do its best when a patch almost applies Sep 05 15:51:14 if that doesn't work you don't want a machine stepping in! Sep 05 15:52:32 rburton: sigh Sep 05 15:52:42 then I blame Joe Sep 05 15:52:53 dropping this change without any reasno Sep 05 15:52:54 reason* Sep 05 16:06:46 rburton: does the patch task ignore whitespaces by default? Sep 05 16:07:06 lpapp: doubt it, but i'd have look at the source to find out Sep 05 16:07:16 can I pass it somehow? Sep 05 16:07:32 I am afraid, patch is stupid to handle it. Sep 05 16:07:36 the patch task, that is. Sep 05 16:07:41 it should not fail on damn whitespaces. Sep 05 16:07:51 darn* Sep 05 16:10:05 yeah, it does not ignore whitespaces Sep 05 16:10:07 looks like a GR Sep 05 16:10:08 FR* Sep 05 16:10:22 or I can already pass that somehow? Sep 05 16:10:49 does GNU patch support that? if not, then I doubt it Sep 05 16:11:04 sure, it does. Sep 05 16:11:19 patch --help | grep whitespace -l --ignore-whitespace Ignore white space changes between patch and input. Sep 05 16:11:30 patch -v Sep 05 16:11:31 patch 2.6.1 Sep 05 16:14:32 I need to reimplement do_patch? Sep 05 16:14:36 or how can I customize patch? Sep 05 16:15:44 * lpapp is submitting a bugreport Sep 05 16:15:53 lpapp: probably easier to fix the whitespace in your patch Sep 05 16:16:56 that's what most people do Sep 05 16:17:24 rburton: well, that is what bugreports are for. Sep 05 16:17:33 rburton: I do not think it is easier in my case. Sep 05 16:17:44 rburton: passing one option would be a few seconds. Sep 05 16:17:51 rburton: I have been trying to fix that for half an hour Sep 05 16:17:51 apply manually with -ignore-whitespace, re-generate diff Sep 05 16:17:54 that's a few seconds of work Sep 05 16:17:54 and still does not apply. Sep 05 16:18:04 you are welcome to do it Sep 05 16:18:10 I have been trying to resolve it for half an hour now. Sep 05 16:18:21 and frankly, I do not wanna waste more time with it in the future Sep 05 16:20:46 so, is there an option for this Sep 05 16:20:54 or I should file a bugreport Sep 05 16:28:34 is it possible with Yocto to apply a patch if a dependency meets a certain requirement? Sep 05 16:28:41 say, it is 2.X, not 3.X Sep 05 16:30:00 lpapp: not through PV checks Sep 05 16:30:35 if you have foo_2 and foo_3 and a .inc, then apply the patch just in the foo_2.bb Sep 05 16:31:20 rburton: no, I mean foo depends on bar Sep 05 16:31:31 and apply a change agaisnt foo only if bar 2 is used, but not if bar 3. Sep 05 16:31:35 oh, right, no. Sep 05 16:40:00 bah Sep 05 16:40:14 dylan broke another thing... the toolchain is not called anymore how it was..... Sep 05 16:41:04 so, is there a prettier way in my Makefile than this: Sep 05 16:41:18 cd openflow; ./boot.sh; ./configure --build=`gcc -dumpmachine` --host=`arm-foo-linux-gnueabi-gcc -dumpmachine`; $(MAKE) Sep 05 16:41:24 this seems to work with dylan, but not with denzil. Sep 05 16:41:42 - /bin/sh: 1: arm-foo-linux-gnueabi-gcc: not found Sep 05 16:41:58 checking whether we are cross compiling... configure: error: in ... Sep 05 16:42:04 | configure: error: cannot run C compiled programs. Sep 05 16:42:04 | If you meant to cross compile, use `--host'. Sep 05 16:42:06 etc... Sep 05 16:42:15 is there a cross-platform way of doing this between dylan and denzil? Sep 05 16:42:24 I am using the smae toolchain. Sep 05 16:42:41 although I am not using meta-sourcery for denzil. Sep 05 16:42:46 and I do not wish. Sep 05 16:42:57 is there a way which works with meta-sourcery and the builtin stuff? Sep 05 16:43:06 lpapp: whoa watch the flooding :) Sep 05 16:43:40 mranostay: ? Sep 05 16:55:30 bluelightning: ^ Sep 05 17:00:45 IMO, yocto has a pretty complex system to resolve it, so I would rather not copy and paste that bitbake stuff out Sep 05 17:01:00 for instance I would not know what TUNE_ARCH are, and how they are supposed to work. Sep 05 17:06:57 lpapp: don't know Sep 05 17:07:43 lpapp: re TUNE_ARCH there is a README file under meta/conf/machine/include/ that talks about how the tuning stuff works Sep 05 17:07:46 * lpapp dislikes that we have an imported stuff rather using a yocto package Sep 05 17:08:00 this whole misery would be pointless if we did not use an internal clone.... Sep 05 17:08:06 and trying to call its buildsystem from our makefile... Sep 05 17:08:13 because oe would manage the build of it for us just fine. Sep 05 17:08:36 that happens when a software is not designed, just written. :( Sep 05 17:09:08 bluelightning: right, but I cannot copy and paste the whole few ten/hundred lines out anyway. Sep 05 17:22:06 bluelightning: can I make my buildsystem Yocto specific for now as a workaround? Sep 05 17:22:13 bluelightning: I would not build the software outside yocto anyway Sep 05 17:22:22 i.e. can I get the host variable from Yocto and pass that in? Sep 05 17:22:34 that would be an acceptable shortcut for now... Sep 05 17:25:41 rburton: ^ Sep 05 17:31:46 zeddii, should I expect PATCHRESOLVE to work with linux-yocto.inc? Sep 05 17:33:44 * lpapp thinks that something changed around the machine naming in dylan compared to denzil Sep 05 17:33:54 probably some undocumented stuff like the kernel name... :( Sep 05 17:56:10 Wow. I think I can safely say that sstate-cache just utterly revolutionised my experience of Yocto... Sep 05 17:56:28 hopefully in a good way .... Sep 05 17:57:08 Yeah.... I'd got my full build time down to about 65 minutes with download caching and a VERY fast new dual-xeon build server Sep 05 17:57:39 Then finally got around to setting up sstate and its dropped to a spritely 18 odd minutes. Sep 05 17:57:55 I thought it had gone wrong it was so fast... Sep 05 18:00:23 Now I just need to work out how to get my board to do opkg nicely (i think I can serve up packages from my build machine easily somehow?) and I'll be laughing Sep 05 18:07:26 Actually now I've refreshed it, my *full* build takes 5 (five) minutes with sstate. Superb. Sep 05 18:11:15 JaMa: where to put uthash inside meta-oe? support, devtools, etc? Sep 05 18:11:38 RP: am I correct in saying that _remove can't undo an _append? such seems to be the case here. Sep 05 18:11:53 hmm Sep 05 18:12:32 pev: yep, you should be able to serve up tmp/deploy/ipk/ via a web server and add that uri as a feed to your opkg.conf on the target Sep 05 18:16:51 aha! nailed down the bitbake bug i've been fighting Sep 05 18:19:35 kergoth: it can't? :/ Sep 05 18:19:54 kergoth: Ah, smart - so is it normal to serve straight from your development directory or would it be better to rsync to a common dir for the web server for example? Also is there some clever mappng required on the target? My boards opkg seems to want to talk to my.local.com? Is this a convention? Sep 05 18:19:57 kergoth: I thought _remove was the last thing to be processed so it should be able to ? Sep 05 18:20:11 if you have a git mirror tarball in your downloads, but no repo, the fetcher thinks it needs to be udpated (presumably to check and see if it has the refs we need), but this means it spawns off a premirror fetch even though i already have the damn tarball it'd be trying to fetch. then, if you have a git:// premirror, rather than just tarball mirrors, and it fails to fetch that, it calls clean(), removing my perfectly fine local mirror tarball, never e Sep 05 18:20:29 So, I have found a thing I want to do, but which I can't do, and maybe I shouldn't be able to. Sep 05 18:20:41 RP: Hmm, I thought so too, but DISTRO_FEATURES_remove = "wayland" isn't removing the bits appended by the poky distro config for me. maybe I have appends being applied multiple times somehow Sep 05 18:20:52 * kergoth digs Sep 05 18:20:53 What I have: A bunch of layers with names like foo-layer-x.y, and a value, MAGIC_NUMBER, which is some x.y. Sep 05 18:21:15 kergoth: it certainly was intended to be last but its possible something isn't right Sep 05 18:21:17 What I want: To pick up foo-layer-x.y for the value MAGIC_NUMBER, which may be determined by interactions with overrides. Sep 05 18:21:30 I'll try to nail down a bit more information and either fix it or open a bug Sep 05 18:21:35 Like, I might have MAGIC_NUMBER_mips = "1.3" and MAGIC_NUMBER_x86 = "1.5" Sep 05 18:21:54 was looking to replace user_features (what otavio based EXTRA_DISTRO_FEATURES on) and found it wasn't doing hte equivalent Sep 05 18:22:00 heh Sep 05 18:22:19 I was looking at the sanity_conf_update magic for rewriting bblayers.conf, but I am pretty sure that is brittle and should not get used for very much, as it seems highly dependent on no one else using it. Sep 05 18:22:54 seebs: can't you use normal variable expansion? Sep 05 18:23:00 For layer inclusion? Sep 05 18:23:07 I don't *think* I can. Sep 05 18:23:48 overrides doesn't have a useful value when bblayers.conf is being parsed, as its default is in bitbake.conf Sep 05 18:23:50 I don't know of a way to add another layer that doesn't involve bblayers.conf. Sep 05 18:23:52 seebs: well, its early in the config building so overrides probably aren't available Sep 05 18:24:25 right, its the interactions with overrides I missed Sep 05 18:24:36 I mean, I could get away from overrides, I think. Sep 05 18:25:05 I could do it with variable expansion instead of overrides. Probably. But I still need a way to say "okay, now that I know you're on MIPS, I need to include layer X instead of layer Y". Sep 05 18:25:28 by the time your local.conf is parsed, so you know what machine you have, it's too late to alter the layers Sep 05 18:25:45 Yup. Sep 05 18:26:35 The context: Our toolchain deliverables come with source-rebuilding layers. We sometimes have slightly different toolchains for different architectures. So I want to be able to pick up "the corresponding layer" for the binary toolchain, but I don't know which layer that is until I know which toolchain I'm using. Sep 05 18:27:13 seebs: why can't you include all the layers and then just have the one you need become active? Sep 05 18:27:51 Possibly because I didn't know there was a distinction between "included" and "active". Sep 05 18:28:31 seebs: control the functionality in the layer with overrides Sep 05 18:28:37 Hmm. In general, is there a thing I can put in a layer.conf, or otherwise in something other than bblayers.conf, which would include other layers? Part of my goal is to reduce this to a single line in bblayers.conf (which is being pre-generated), and have my layer then do whatever magic it needs. Sep 05 18:29:18 seebs: that simply isn't part of the current design Sep 05 18:29:35 Oh, hey. I could in fact probably get the results I want by, instead of having multiple layers, having a single layer with multiple recipes-foo subdirectories, and using something in BBFILES. Sep 05 18:29:47 seebs: what's your *real* underlying goal? take a step back and explain the goal and perhaps we can help you find a different way to get there Sep 05 18:30:00 Like BBFILES += "${LAYERDIR}/recipes-${FOO}/*/*.bb" Sep 05 18:30:12 seebs: of just have a set of recipes which raise SkipPackage if they shouldn't be active Sep 05 18:30:17 s/of/or/ Sep 05 18:30:51 Okay, the underlying goal: We get binary toolchains from a vendor. Each binary toolchain has a corresponding source layer which uses bbappends so that, if you use that source layer, and just build the toolchain normally, the toolchain is built with roughly the same source used for the binary toolchain. Sep 05 18:31:23 If the user requests the source-build option, I want to pick up the corresponding source layer. Sep 05 18:31:55 seebs: look at how COMPATIBLE_MACHINE and COMPATIBLE_HOST work Sep 05 18:32:00 But I don't want to have to encode the awareness of which versions are which in the code that's doing the initial creation of local.conf/bblayers.conf, because that code shouldn't have to change with every uprev. Sep 05 18:32:07 i'd say take RP's advice and just aalways suck it in but have it not always be active Sep 05 18:32:18 seebs: just put all the recipes in the BBFILES and then have them decide whether to be parsed or not Sep 05 18:32:20 And ideally, I don't want to have to modify the contents of those source layers at all. Sep 05 18:32:30 alternatively, build additional tooling at a higher level in oyur setup scripts Sep 05 18:33:26 I'm sort of wondering whether ${LAYERDIR}/sources-${THIS_SPECIFIC_VERSION}/recipies/*/*.bb would work in BBFILES. Sep 05 18:33:57 Because if it would, that would solve the problem; all the recipes are present, but only the ones matching the selected version are picked up by BBFILES. Sep 05 18:34:15 i think it should.. Sep 05 18:34:34 That might be simpler. Sep 05 18:36:04 I really hate libtool Sep 05 18:36:35 I just want it to install the library. It has not moved. /usr/lib/../lib is /usr/lib/ Sep 05 18:36:38 Basically, my fundamental problem is that I've painted myself into a corner where I want to make very fundamental configuration choices based on information that I don't want to duplicate outside of my bitbake conf files. Sep 05 18:36:57 You may hate libtool, but libtool loves you. Sep 05 18:37:02 seebs: the BBFILES approach could work Sep 05 18:37:08 Possibly a bit much, which is why it is clingy and wants to monopolize your time. Sep 05 18:37:44 I might also want to do something similar in the BBPATH .= line. Sep 05 18:37:51 Okay, I have an idea of how I could do this. Sep 05 18:38:05 ... This is so the wrong week for me to have mild sniffles or something. I cannot think clearly. Sep 05 18:56:53 I'm trying to work with cortexa8hf-vfp-neon-angstrom-linux-gnueabi-Linux-x86 with Netbeans and it doesn't find iostream? I've added the include path to iostream. Not sure where it's failing. Sep 05 18:58:47 well, this question is loads better than last weeks questions :) Sep 05 19:00:00 Crofton|work, oh is it now? lol Sep 05 19:00:27 I barely know what netbeeans is Sep 05 19:01:29 iostreams is a standard C++ header so it suggests the SDK's C++ search path may be incorrect? Sep 05 19:01:46 does anything c++ work? Sep 05 19:14:19 Huh. Sep 05 19:17:13 So, it appears that BBPATH = Sep 05 19:17:17 ... argh Sep 05 19:17:24 RP, I added the include path (found via 'find . -name iostreams) in my sdk directory. Sep 05 19:18:18 BBPATH .= ":${FOO}" does not pick up overrides which affect the value of ${FOO}. Sep 05 19:18:47 iostreams should be found automatically. It's a standard header. Sep 05 19:18:48 RP, if i just source the environment and run MAKE from the project directory it works. If i source the environment and start netbeans it doesn't find the header files. Sep 05 19:19:28 cfo215, sounds as if netbeans stes some conflicting environmen variables. Sep 05 19:19:31 RP, ... when building the project from netbeans. I also tried exporting CPATH Sep 05 19:19:36 sets Sep 05 19:20:11 cfo215, is nuts, he is actually tryin gto do work based on OE output :) Sep 05 19:20:41 Crofton|work, nice! lol Sep 05 19:23:00 RP, I created a 'tool collection' in netbeans just for the angstrom toolchain. Including (sorry for pun) the include paths. Sep 05 19:25:05 RP, "/home/cfo215/opt/angstrom/sysroots/cortexa8hf-vfp-neon-angstrom-linux-gnueabi/usr/include/c++" which is where I found iostream Sep 05 19:26:07 I've been called worse Crofton|work :) Sep 05 19:31:43 RP, hno the build output is at http://pastebin.com/CVtGpSRy if you care to look. Sep 05 19:32:28 RP, hno: I'm going to look at that .build-conf file that shows up in the output. Sep 05 19:42:53 seebs: still around? Sep 05 19:47:43 So Crofton|work, does anyone actually use this #yocto stuff for real work? Just wondering... Since it's been oh so much fun getting to this point. Sep 05 19:48:33 My day job is working on yocto, all day every day, for a commercial product. Sep 05 19:48:34 cfo215: yes, people use it for real work Sep 05 19:48:42 one of quite a lot of companies that do so Sep 05 19:50:39 cfo215: company can find experienced contractor to start with the fun a bit faster, I agree that learning curve is a bit steep Sep 05 19:53:04 thanks everyone. Sep 05 19:54:44 Yeah, I doubt anyone would disagree that it's not as easy as it could be. The documentation is greatly improved over what existed before yocto, however, now that there are actual technical writers doing the work Sep 05 19:55:56 Are any of you using Netbeans? Sep 05 19:56:25 Or just Eclipse since you have the Yocto plugin for that? Sep 05 19:56:44 cfo: Is that build system removing some of the parameters from the commands like the --sysroot option? Sep 05 20:01:35 RP, I put the output in http://pastebin.com/UK7E15QC, and to answer your question I don't see --sysroot anywhere. Sep 05 20:02:25 cfo215: I think that is the problem then, you need to get the option in there... Sep 05 20:02:54 cfo215: you could try a wrapper script which adds the extra option to prove its the issue... Sep 05 20:10:52 RP, I also found this http://pastebin.com/fpKgfXnD... so I'll double check my includes for the toolchain. i found the features.h so I'll double check my includes and then try the wrapper Sep 05 20:11:10 cfo215, does it work if you from the shell (after sourcing the environmen): "cd /home/cfo215/NetBeansProjects/Welcome_1; arm-angstrom-linux-gnueabi-g++ -c -g -MMD -MP -MF build/Debug/cortexa8hf-vfp-neon-angstrom-linux-gnueabi-Linux-x86/welcome.o.d -o build/Debug/cortexa8hf-vfp-neon-angstrom-linux-gnueabi-Linux-x86/welcome.o welcome.cc" Sep 05 20:16:21 RP is --sysroot used with gcc or gmake? Sep 05 20:16:46 RP, I have some places where I can add switches... Sep 05 20:18:03 cfo215: you need to pass it in the compiler flags so that it calls arm-angstrom-linux-gnueabi-g++ with the option Sep 05 20:18:25 RP, thanks. Sep 05 20:22:53 RP, OK added --sysroot, now getting cc1plus: error: to generate dependencies you must specify either -M or -MM Sep 05 20:23:25 hno, trying your request now. Sep 05 20:27:19 hno, welcome.cc:31:20: fatal error: iostream: No such file or directory Sep 05 20:27:45 cfo215, and with a proper --sysroot=... ? Sep 05 20:30:03 hno, all is well in the world again... ;-) thanks Sep 05 20:31:17 now working in netbeans... thanks everyone!!! You guys ROCK! Sep 05 21:07:56 cfo215: glad you got there! :) Sep 05 21:08:19 cfo215: so do we have any issues in the core? Sep 05 21:09:12 RP, not as far as I know, but I'm just getting started :-) Sep 05 21:09:37 RP, I did find this issue(?), I have my own recipe for the Phidgets Library (libphidget) inside of my meta layer (meta-cfo215) but the header files and libraries don't get included when I do a bitbake meta-toolchain-qte. I have it included in my local.conf and bblayers.conf files. Sep 05 21:10:13 the ipk gets generated and the library is available when I bitbake console-image. Sep 05 21:10:28 if it automatically included every recipe in all our layers, it'd be a *really* big toolchain :) Sep 05 21:11:05 kergoth, that's probably very true... lol. So where is the majic done if you don't mind? Sep 05 21:11:40 I need to modify meta-toolchain-qte I'm guessing. Sep 05 21:11:42 cfo215: Do you have an image which includes your app ? Sep 05 21:12:11 if you do then just bitbake -c populate_sdk will do it Sep 05 21:12:14 khem, it gets included when I bitbake console-image (Angstrom) Sep 05 21:13:00 khem, i'll try that and get back to you. Sep 05 21:13:31 cfo215: if you want to specifically add it to a meta-toolchain target then you need to append it to TOOLCHAIN_TARGET_TASK Sep 05 21:13:56 ah good, thanks khem, i was going to look it up, sdk sutff isn't fresh in my mind :) Sep 05 21:14:21 kergoth: yeah and I cant get it out of my mind even though I want to Sep 05 21:14:29 haha Sep 05 21:17:28 drenched in lot of non OE stuff Sep 05 21:23:06 khem: I just checked out libgfortran with gcc-4.8 and found problems with the libquadmath :( Sep 05 21:23:13 khem: is that something you're interested in or not? Sep 05 21:23:38 khem: anyhow, I cc'd you on my hacks, not sure I'll do anything more with it Sep 05 21:25:13 hmm, if you use an override to define SSTATE_DIR and DL_DIR, the non-override dirs get created anyway, though they end up empty. guess we must have a rogue reference with non-finalized data Sep 05 21:25:54 kergoth: I think we have a few of these :/ Sep 05 21:26:44 kergoth: ls tmp/work/i586-poky-linux/bblayers/ shows "1.0-r0" here :/ Sep 05 21:27:03 I don't recall such a recipe... Sep 05 21:28:21 kergoth, "if it automatically included every recipe in all our layers, it'd be a *really* big toolchain", was kind of under the impression that what I did in local.conf and bblayers.conf was sort of a global override. I guess that is not the case. Sep 05 21:28:43 kergoth, I figured if I had it added there, then anything i bitbaked would include it. Sep 05 21:31:30 RP: hah :) Sep 05 21:32:24 RP: i think we should, if we don't already, have an "official" finalized configdata in the cooker, which everyone should use for config values, and potentially also have an event that carries it for the common case of altering non-finalized configdata based on the finalized configdata values Sep 05 21:32:32 heh Sep 05 21:32:47 RP: I also see bblayers in every WORKDIR and another interesting fact is that it doesn't respect architecture set by DEFAULTTUNE Sep 05 21:34:00 JaMa: I'm not surprised. For better or worse, I have worse things to chase down atm though :( Sep 05 21:34:19 JaMa: I think I did find the mystery pseudo on arm issue though :) Sep 05 21:34:30 I'm already testing that one Sep 05 21:34:47 I'm surprised it was so deterministic in your test Sep 05 21:35:16 because when I was trying to reproduce it it was behaving a bit strangly Sep 05 21:35:16 JaMa: you just had to understand what was triggering it. The bitbake -e history for the variable gave a very big clue in helping understand it Sep 05 21:35:57 JaMa: if you build for an arch which didn't set the suffix, you wouldn't see it Sep 05 21:36:41 JaMa: so you have to use MACHINE= with the allarch package you were tageting not in sstate or the tmpdir Sep 05 21:37:14 RP: yes it's possible that I was overlooking something in bitbake -e Sep 05 21:38:26 RP: I've another reproducer for weird pseudo issue, but this one seems unrelated to this finding Sep 05 21:39:10 JaMa: just when I thought I could get my bug count under control? :) Sep 05 21:39:24 RP: if you build core-image-minimal (with procps added to IMAGE_INSTALL), then cleansstate procps and build core-image-minimal again, buildhistory usually shows couple of file attributes changed in procps files Sep 05 21:40:16 JaMa: that does sound rather odd Sep 05 21:40:19 I've already discussed it with seebs, he gave me some great tips (first with NO32LIBS flag) Sep 05 21:40:53 JaMa: you have mixed 32 and 64 bit binaries? Sep 05 21:41:03 but there is still something fishy in it and it shows the signs a bit randomly (different procfs files get different permissions etc) Sep 05 21:41:41 RP: that was where I found it first (mixed binaries) but now I can reproduce it even with latest oe-core and internal toolchain Sep 05 21:42:16 JaMa: hmm, sounds like something we should try and look into Sep 05 21:42:22 my last attempt was to build with PSEUDO_OPTS=-l and share logs.db with seebs but that doesn't seem to work Sep 05 21:42:40 but you don't need to worry about this one, I'll try to resolve it with seebs Sep 05 21:43:16 I just wanted to warn you that there is something fishy (and it was there in dylan already) Sep 05 21:44:51 JaMa: thanks for the heads up. I did see some of your conversation but thought it had been resolved as static binaries or 32/64 bit libs :/ Sep 05 21:44:56 khem, I did the bitbake -c populate_sdk console-image... and now i have an sdk with the libphidget library, but it don't get my qte tools (no qmake, moc, etc.) I need it all ;-) Sep 05 21:45:11 JaMa: perhaps worth putting the reproducer in bugzilla and we can assign it to you/seebs? Sep 05 21:46:07 RP: yes looks like static binaries were caused big part of the problem, but haven't resolved all the differences detected by buildhistory Sep 05 21:46:49 RP: I'll do that tomorrow (hopefully will resolve logs.db before that to provide more useful info too) Sep 05 21:48:10 cfo215: then pick a qt image. console-image is .. console Sep 05 21:48:18 cfo215: pick, or create, that is Sep 05 21:49:35 kergoth, I think the only Qt image in Angstrom is the gnome-cloud9 image. I don't need the fatness of X11 for my project. Just Qt console using -qws on the command line. Sep 05 21:50:13 I am interested in this pseudo thing, although I am not sure what my availability is like in the next week or so. Sep 05 21:50:25 kergoth, I was actually just thinking of rsyncing the two sdks into one. Sep 05 21:50:38 cfo215: then follow the second approach I suggested above Sep 05 21:51:04 indeed, just add to meta-toolchain-qte via TOOLCHAIN_TARGET_TASK, if none of the images suit, or create an image that ahs what you want Sep 05 21:51:39 seebs: any idea why export PSEUDO_OPTS="-l" doesn't cause logs.db to contain the log entries? Sep 05 21:51:43 that said, there apparently is a qte demo image in oe-core/poky, see meta/recipes-qt/images/qt4e-demo-image.bb Sep 05 21:51:46 khem, kergoth, I add the TOOLCHAIN_TARGET_TASK in the .bb for console-image then? Sep 05 21:51:52 no Sep 05 21:52:07 seebs: I thought I had it working before, but now using the same (from bash history) doesn't seem to work Sep 05 21:52:08 well, you could, but it'd likely be easier to just add to the one in meta-tolchain-qte Sep 05 21:52:10 in my local.config Sep 05 21:52:12 JaMa: No, although the obvious suspicion would be that PSEUDO_OPTS might not be in the environment whitelist. Sep 05 21:52:14 rather than trying to add everything to a console image Sep 05 21:52:32 seebs: I even tried it to export it from local.conf Sep 05 21:52:43 s/it //g Sep 05 21:55:03 kergoth, khem, sorry I'm very newb to all of this. I just finally got OE/Yocto/Angtrom working a few days ago. After many trials and tribulations. You guys are way over my head now. I'm trying to learn. Guess I need to look at the manuals some more. Sep 05 21:59:53 echo 'TOOLCHAIN_TARGET_TASK_append_pn-meta-toolchain-qte = " somepackage"' >>conf/local.conf Sep 05 22:00:15 though a bbappend or custom recipe would be a cleaner long term approach, that may get you there for now Sep 05 22:21:38 seebs: exporting it inside FAKEROOTBASEENV works, tomorrow I'll share bugzilla report with you :) Sep 05 22:42:39 JaMa: ah, I can see why exporting it there helps now. We should document that somewhere perhaps **** ENDING LOGGING AT Fri Sep 06 02:59:59 2013