**** BEGIN LOGGING AT Wed Dec 21 03:00:00 2016 Dec 21 04:31:52 Hello yocto world Dec 21 04:36:20 Anyone lurk around here this late? Dec 21 07:50:27 Good morning Dec 21 07:51:12 How do u append ur .config for linux kernel? Do I must rename it to defconfig? Dec 21 07:56:54 yes I must. But now I see there is another approach, incremental change Dec 21 09:17:58 Hi all. Just to make sure: When having a git repository for SRC_URI it's fetched recursivley (meaning including submodules) by default, isn't it? Dec 21 09:19:54 Or maybe i am wrong.. I've looked at the git fetcher but can't find anything like 'recursive' in there Dec 21 09:19:57 So how would i do that? Dec 21 09:21:02 Anticom: the default git fetcher doesn't handle submodules Dec 21 09:21:14 nrossi: i've found out that there's gitsm:// Dec 21 09:22:00 Anticom: yep, the gitsm:// does a recursive checkout of submodules Dec 21 09:22:07 i'm currently looking at the fetcher sources but i'm not sure whether to just replace git:// with gitsm:// or would i have to explicitly add each and every submodule? I'm thinking the former, right? Dec 21 09:23:16 Anticom: just replacing git:// with gitsm:// should do the trick. It looks like it defaults to doing a recursive init of submodules Dec 21 09:29:45 nrossi: "just replacing" blows up on me Dec 21 09:30:46 Anticom: make sure you clean, follow the little header help in the code for the gitsm. http://git.openembedded.org/bitbake/tree/lib/bb/fetch2/gitsm.py#n13 Dec 21 09:32:06 oh Dec 21 09:32:20 hm, i did a clean, bb started with do_unpack and still blows up on me Dec 21 09:32:46 Anticom: clean the downloaded repo in downloads/git2/ Dec 21 09:32:51 "cp: cannot stat '/path/to/downloads/git2/<...>/modules': No such file or directory" Dec 21 09:33:02 it should start on the fetch task Dec 21 09:40:23 Hm this is strange, now i get an error during building Dec 21 09:41:49 Are the submodules placed exactly as if i would do a 'git clone --recursive ' ? Dec 21 09:43:42 Anticom: no it does a "submodule update --init --recursive" Dec 21 09:44:09 nrossi: well maybe i was a little unprecise, i meant whether the resulting directory structue is the same. It seems it is Dec 21 09:44:41 Anticom: Ah, it is git that handles the submodules so yes Dec 21 09:44:45 So maybe it's a cmake related issue then... I'm doing set/CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../cmake" ${CMAKE_MODULE_PATH}) in there Dec 21 09:44:56 set( * Dec 21 09:45:08 however that should work Dec 21 09:45:47 I'm not particularly familiar with CMake, but if its setting up the submodules in the locations you expect than your issue is likely not with the checkout or gitsm:// Dec 21 09:52:26 Hello there, I am trying to add my own dtb to the kernel, when I execute: "recipetool appendsrcfile -wm imx6qpsabreauto /home/ilker/work/gunsel/sources/meta-fsl-arm virtual/kernel /home/ilker/imx6qp-sabreauto-gunsel.dts 'arch/${ARCH}/boot/dts/imx6qpsabreauto-gunsel.dts' I got error: ImportError: cannot import name CmakeExtensionHandler Dec 21 09:56:19 Hence, when I run recipetool, the output is: http://pastebin.com/xLRw15wJ Is there anybody here to help me ? Dec 21 10:13:50 on a packaegroup recipe, if there is no PACKAGES variable, then the name of the package generated is the name of the recipe? Dec 21 10:49:35 ^yes Dec 21 10:53:53 Once kergoth suggested me to create my own layer based on another bsp layer. How it's done that? My goal is to extend that layer, not to maintain it entirely. E.g: I would add add configuration fragments to the linux recipe that has the bsp layer Dec 21 11:04:11 in your bsp layer have a machine conf that just does require the-other-machine.conf Dec 21 11:04:16 and then tweaks it as required Dec 21 11:04:24 and add whatever special bits you want Dec 21 11:05:31 then I'm creating a "new" machine, isn't? Dec 21 11:06:36 and I should target that new machine instead of the original Dec 21 11:13:59 yeah Dec 21 11:26:15 I did: require conf/machine/foo.conf Dec 21 11:26:35 no errors but it seems it doesn't applied Dec 21 11:27:05 because the variables values aren't as they should be Dec 21 11:33:34 aV_V: don't forget to setup MACHINEOVERRIDES to also include the 'require'd machines name, so that its overrides are also applied to your machine. Dec 21 11:43:00 nrossi: I don't get it Dec 21 11:43:29 aV_V: like this: http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/conf/machine/raspberrypi0.conf Dec 21 11:52:27 nrossi: on local.conf I must set MACHINE to the original machine or my custom-machine ? Dec 21 11:55:48 aV_V: you mentioned above that you were "require conf/machine/foo.conf" in your custom machine. But were having issues with some variables not being applied as if it were "foo". It is likely this is because the machine you are including has a number of overrides that are set based on its machine name e.g. "KERNEL_FEATURES_append_foo = ...". In order to get Dec 21 11:55:49 those overrides to apply for you machine, you can add the 'foo' machine to your machines overrides. This would be done in your custom-machine.conf, whilst keeping your MACHINE="custom-machine" in your local.conf Dec 21 11:58:07 no, the original .conf hasn't overrides based on machine name, but it's good to know Dec 21 11:58:54 then, I must use include or require? that what confuse me Dec 21 12:01:10 I think I'm not able to include the original .conf, it's on another layer btw Dec 21 12:02:08 aV_V: include and require do the same thing, include is just ignored if the file doesn't exist Dec 21 12:02:47 you should be fine to include the conf from another layer as long as it is on the BBPATH, and than you don't have a file of the same name in your layer Dec 21 12:09:59 nrossi: this is the content of the conf folder of my new layer: http://pastebin.com/yiKxWEDF Dec 21 12:10:04 is there something wrong? Dec 21 12:10:52 aV_V: is "cm-fx6" the name of the layer? Dec 21 12:11:03 nrossi: yes Dec 21 12:11:17 aV_V: and the name of the machine of the "other" layer? Dec 21 12:11:30 cm-fx6.evk Dec 21 12:11:37 cm-fx6-evk* Dec 21 12:11:50 aV_V: then "MACHINEOVERRIDES = "cm-fx6:${MACHINE}"" -> should be MACHINEOVERRIDES = "cm-fx6-evk:${MACHINE}" Dec 21 12:13:11 ok, but my new .conf still not applying :S Dec 21 12:13:21 what do you mean "not applying"? Dec 21 12:14:21 e.g, I set IMAGE_FSTYPES, if I do bitbake recipe -e | grep IMAGE_FSTYPES= the value is not what I set Dec 21 12:15:07 aV_V: ok, two things... is there already another machine named "cm-fx6" in the "other layer"? and what is your MACHINE=? in local.conf Dec 21 12:16:01 no, there isn't. And I've set MACHINE=cm-fx6 as u said before Dec 21 12:17:33 aV_V: is this other layer publicly accessible? i think its just a matter of it setting "IMAGE_FSTYPE" with an "=" operator, such that the first one setting the value is used Dec 21 12:18:57 actually, IMAGE_FSTYPES value I get is not even the value set by the original .conf Dec 21 12:19:33 so I'm sure the original .conf is not used here Dec 21 12:22:38 aV_V: could you pastebin the output of "bitbake recipe -e | awk '/^# \$IMAGE_FSTYPES /,/^IMAGE_FSTYPES=/'" (or equivalent) so I can see what/how IMAGE_FSTYTPES is being set Dec 21 12:22:47 just tried with relative path, neither works :S Dec 21 12:23:01 ok Dec 21 12:24:53 http://pastebin.com/ht7FX0Uq Dec 21 12:29:02 aV_V: are you sure there are no other machines called 'cm-fx6'? cause it looks like its not even getting set. Can you run "bitbake -e | grep "#.*conf/machine/cm-fx6\.conf" | head -1" Dec 21 12:30:50 oh Dec 21 12:30:52 there is Dec 21 12:30:57 sorry xD Dec 21 12:31:19 aV_V: give your machine a different name and that should sort it out ;) Dec 21 12:34:20 nrossi: nice! thanks for u patience, I'm sorry, very dumb mistake Dec 21 13:24:27 hi Dec 21 13:25:20 is there some mechanism to create environment variables during image creation? Dec 21 13:28:39 I am a total newbie and I have some trouble with shared libraries. I have a custom reciepe which builds upon postgresql (libpq). I have the dependecy in RDEPENDS but if I hit configure it will fail since it is not able to find libpq. If I check the tmp build directory the library is missing. which means to me there is something wrong with the order maybe? how can I tell yocto to install postgres first a Dec 21 13:28:45 nd then my reciepe apperently I am doing something wrong with the DEPENDS flag Dec 21 13:29:08 zauberstuhl: you want DEPENDS=postgresql Dec 21 13:29:14 rdepends is runtime, not build time Dec 21 13:29:21 oh Dec 21 13:29:50 well that was quick. let me check if that fix my problem thanks rburton Dec 21 13:29:58 fixes* Dec 21 13:37:16 rburton: does that look right ? -> http://pastebin.com/tD3UMCiz still no libpq in the tmp build dir Dec 21 13:45:30 using DEPENDS it means it's needed to build but not be installed? Dec 21 13:48:03 aV_V: I added postgresql to IMAGE_INSTALL as well. if I start qemu I actually can find the libpq in the rootfs. so I thought something is wrong with the build order Dec 21 13:48:48 hello everybody! I would have a question regarding bitbake: Is it possible to get the version numbers of depended recipes. Let's assume I define a package group and want to write a file that contains the version numbers (PV) of all referenced recipes into my image? I'm struggling to getting started with bitbake as I can't find where stuff like the d variable is documented... Dec 21 13:52:06 tttm: I can help you with the last one http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-D Dec 21 13:52:28 zauberstuhl: this looks fishy: --with-pg-lib="${STAGING_DIR_NATIVE}/usr/lib" Dec 21 13:53:19 is there a reason it's native? Dec 21 13:54:12 rburton: hey Dec 21 13:54:17 jku: that one fails cause of the missing lib but I haven't really started tweaking cause I cannot find the lib in the whole tmp build directory. Dec 21 13:54:33 rburton: any thoughts on my proposal here: http://lists.genivi.org/pipermail/genivi-projects/2016-December/004999.html Dec 21 13:54:52 jku: the ntaive thing was paste'n'copy since I needed an example to start with Dec 21 13:55:07 zauberstuhl: I'm talking about python DataSmart d variable, not D ;) Dec 21 13:55:20 tttm: ups sorry Dec 21 13:55:52 rburton: i'm assuming you're familiar with g-d-p but do correct me if i'm wrong :) Dec 21 13:59:27 zauberstuhl: so if you expect something to be in build sysroot, look in $TMPDIR/sysroots. I'm currently building for qemux86-64 so it's "build/tmp/sysroots/qemux86-64/usr/lib/" for target libraries Dec 21 14:02:21 jku: yes I cannot find anything in build/tmp/sysroots/x86_64-linux/ but build/tmp/work/qemuarm-poky-linux-gnueabi/rpi-basic-image/1.0-r0/rootfs/usr/lib/libpq.so exists Dec 21 14:03:11 do I miss something Dec 21 14:03:11 zauberstuhl: No problem... Dec 21 14:05:11 zauberstuhl: x86_64-linux sounds like your build host (i.e native sysroot) Dec 21 14:05:42 have you looked in the target (qemuarm) sysroot? Dec 21 14:07:26 I just thought it must be easy to read PV for certain (depended) recipes before I tried to read buildhistory.bbclass (which exports SRCREV for packages); I really don't get it: Who decides which variables are visible and which are not... Dec 21 14:09:50 Can i supply more than one task to a bitbake invokation? (something like 'bitbake -c foo -c bar target' or 'bitbake -c foo,bar target' etc.) Dec 21 14:11:35 jku: ahhh right.. I was wondering myself. ok just read the native section. I should use STAGING_DIR_TARGET instead of STAGING_DIR_NATIVE right? Dec 21 14:12:04 then it resolves to the qemu dir Dec 21 14:14:44 zauberstuhl: well, it's bound to be less wrong :) Without knowing ruby/gem at all it's hard to say but that's worth a try Dec 21 14:15:48 jku: thank u, sir! seams to be working Dec 21 14:18:19 where do I specify on my bsp layer if I would want to append some packages to any image thats going to be used? Dec 21 14:23:20 my goal is to create a generic distro, so it's the machine used that specifies what packages should be added to that image Dec 21 14:29:53 aV_V: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#ref-varlocality-config-machine, pick one of the _RDEPENDS or _RRECOMMENDS. Dec 21 14:35:29 nrossi: perfect :) Dec 21 14:48:17 One last thing. My image before being generic had "inherit populate_sdk_qt5". Now, I must remove it if I want to be generic, so what alternative do I have to get the same result? Dec 21 14:49:21 or it's fine inheriting that class? Dec 21 14:52:51 zeenix: literally no idea what gdp is :) Dec 21 14:55:00 rburton: nm then :) Dec 21 14:58:27 hello guys, if I have CC=g++ variable in the package's makefile will be it used by Yocto in compilation phase? Dec 21 15:09:52 aV_V: i doubt you really want to pull that in for every image, but if you do, use IMAGE_CLASSES. Dec 21 15:14:45 kergoth: would be right if I use that on the machine .conf? Dec 21 15:15:03 you have to be careful about the boundaries between machine, distro, and image Dec 21 15:15:11 supporting qt5 is more of ad istro than a bsp decision Dec 21 15:15:28 hmmm Dec 21 15:15:42 they're really 3 orthogonal axes around which the build orients. the key thing to remember is *any* machine should work with *any* distro which should work with *any* image Dec 21 15:15:57 if there's an image that only works for one machine, that violates that, for example (not your situation, just an example) Dec 21 15:16:25 that's exactly what I want to accomplish Dec 21 15:17:43 if I don't inherith qt, then what other options do I have? Dec 21 15:19:39 doing "bitbake meta-toolchain-qt5" would create an SDK against my iamge? the issue is how do I specify agains which image should be generated the sdk Dec 21 15:23:47 i'm not really familiar with the qt5 sdk specifically, but for example the populate_sdk task creates an sdk whose content mirrors the image content — if you run it on an image with qt5 libs, then you'll have qt5 libs and development headers in the sdk. my guess is populate_sdk_qt5 just adds the native tools that are useful in developing for qt5, rather than just the headers. ideally it'd only do that when qt5 libs are in the sdk, i.e. automatically Dec 21 15:23:47 add the qt5 tools only when the qt5 libs are in the sdk, then it'd be safe to inherit it in any image without blindly adding qt5 tools to the image — i haven't read the class, maybe it does that already, maybe not Dec 21 15:23:50 but something to think about Dec 21 15:24:09 s/to the image/to the sdk/ Dec 21 15:32:36 I understand better now, thank you. Then I could do a function checking for qt libs and then inherit the qt class Dec 21 15:42:36 Hi, I am trying to override a varaible (I think it is an array?) by platform, but not sure which is the correct syntax. Dec 21 15:42:56 For variables I usually use MYVAR_machine1 = "something" and then MYVAR_machine2 = "otherthing" and that works Dec 21 15:43:18 overrides don't work with flags at all Dec 21 15:43:37 the semantics of foo[bar]_something or foo_something[bar] would be unclear. Dec 21 15:43:48 most likely you'd need to use anonymous or inline python to do it Dec 21 15:43:55 how about foo[bar_something] ? Dec 21 15:44:00 But this uses '[]' so I am not sure if I am using the wrong syntax, but ti does not work... should it be MYVAR[attr]_machine1 = "something" or MYVAR_machine1[attr] = "SOMETHING"? Dec 21 15:44:07 see above Dec 21 15:44:09 OH Dec 21 15:44:10 see also https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html Dec 21 15:44:28 aka "the secret yocto manual" :P Dec 21 15:44:38 why the bitbake info isn't in the mega manual is beyond me Dec 21 15:44:52 Oh, thanks Dec 21 15:47:08 so foo[bar_something]wouldn't work either, right? Dec 21 15:47:18 probably because technically bitbake is not part of yocto but a separate project, and also because the MM is build from the yocto git, not the bitbake git Dec 21 15:47:27 but from a practicall point of view, it should... Dec 21 15:47:46 ttllkk: no, that would do nothing Dec 21 15:47:49 ttllkk: no, I mentionned it as an "it be cool if" but it's not implemente Dec 21 15:47:50 d Dec 21 15:47:52 boucman_work1: oe-core is a separate project too Dec 21 15:47:58 by that argument yocto should have no docs at all :P Dec 21 15:48:32 my point was that the MM is built from a single repo (IIUC) which is not the bitbake repo, but I may be wrong Dec 21 15:49:18 that's probably true, but i can't imagine it'd be impossible to pull it in. use a submodule, worst case Dec 21 15:49:19 * kergoth shrugs Dec 21 15:50:21 oof. been doing world build testing, with an isolated sstate from the rest of my builds, to avoid bloating that up.. the new sstate is 50GB and counting :| Dec 21 15:56:47 how it's possible that during a build my internet connection cuts O_o Dec 21 15:56:59 It happened me several times Dec 21 17:31:01 RP: thoughts on splitting mirror tarball generation out of do_fetch? currently the fetcher goes running through mirrors and stuff if tarball generation fails, which is just weird and wrong, and it's not exactly part of the fetching anyway. thinking a separate method which is called by a new task or postfunc Dec 21 17:32:12 could also make it possible to write to a different dir than DL_DIR, which could be useful, if i'm populating a new mirror that won't have the git repos, and the mirror tarballs being in the current DL_DIR is largely redundant due to having the git repos.. Dec 21 17:37:27 where is the good place to set PREFERRED_VERSION for a component Dec 21 17:37:45 i tried in image recipe, but looks like it isn't the right place Dec 21 17:39:09 it has no meaning in that context Dec 21 17:39:17 preferences are global and affect what recipes are selected up front Dec 21 17:39:22 it only works in a .conf Dec 21 17:39:44 you cannot select recipes depending on which image you're building, it wouldn't make sense. which files would end up in the sysroot? what if you build 4 images in a single bitbake command? Dec 21 17:40:12 ok Dec 21 17:40:16 got it Dec 21 17:40:40 new question: i have a recipe that build a package from SVN source tree Dec 21 17:40:42 so Dec 21 17:41:14 my $PV is something like 1.0+svn-987-r0 Dec 21 17:41:46 can i use PREFERRED_VERSION_my-component ?= "1.0+svn-XXX-r0" where XXX is a valid SVN reference ? Dec 21 17:42:11 % is a wildcard Dec 21 17:42:19 but no Dec 21 17:42:30 the recipe fetches the revision specified in SRCREV in the recipe Dec 21 17:42:37 you can't change that by changing PREFERRED_VERSION Dec 21 17:42:45 PREFERRED_VERSION must match the PV (version) of the recipe Dec 21 17:42:50 if they don't, the pref will do nothing Dec 21 17:43:06 set PREFERRED_VERSION_my-component = "1.0+svn%" and then if necessary adjust SRCREV Dec 21 17:43:44 kergoth: my PV is computed: PV = "1.0+svn-${SRCPV}" Dec 21 17:43:56 and? Dec 21 17:44:12 idk Dec 21 17:44:17 again, PREFERRED_VERSION must match PV, and again, % is a wildcard Dec 21 17:44:25 1.0+svn% will match any SRCREV Dec 21 17:44:29 ensuring that hte svn recipe is chosen Dec 21 17:44:38 yeah Dec 21 17:44:40 i got that Dec 21 17:44:48 so Dec 21 17:45:02 if i have PREFERRED_VERSION-bla ?= "XX" Dec 21 17:45:09 i must have bla_XX.bb Dec 21 17:45:16 right ? Dec 21 17:45:20 no Dec 21 17:45:30 hmmm Dec 21 17:45:30 it has to match up with PV, not the filename Dec 21 17:45:33 ok Dec 21 17:45:35 the filename is only a default Dec 21 17:45:43 foo_svn.bb doesn't have PREFERRED_VERSION_foo = "svn" Dec 21 17:45:49 it has to match PV, not the filename Dec 21 17:46:00 ok Dec 21 17:46:22 so, is there a way to specify revision to use for the svn co if not specified in SRC_URI Dec 21 17:46:29 ? Dec 21 17:46:42 i mean, not by writing a bbappend that will rewrite SRC_URI Dec 21 17:48:20 as i just said, the recipe fetches SRCREV Dec 21 17:48:34 either bbappend and set SRCREV, or set SRCREV_pn-my-component in a .conf Dec 21 17:48:45 oh Dec 21 17:48:49 that sound exaxctly what i want Dec 21 17:48:51 thanks kergoth Dec 21 17:48:53 np Dec 21 17:49:10 this is why SRCREV exists, rather than specifying it in the url, to make it easier to set and override Dec 21 17:49:15 ok Dec 21 17:49:44 and if SRCREV is set to ${AUTOREV} in my recipe, will it be overridden with SRCREV_pn-my-component in a .conf ? Dec 21 17:49:57 or shall i remove SRCREV setting from my recipe ? Dec 21 17:50:20 _pn-${PN} is called an override. by definition, it overrides the value Dec 21 17:50:28 see the bitbake manual for details Dec 21 17:50:47 ok Dec 21 19:31:08 sometimes it looks as if this build system was really thought out well Dec 21 19:33:30 sometimes? ;) Dec 21 19:38:40 ha, I knew someone would bite :) Dec 21 19:38:52 Yeah, the rest of the times we are fixing meta data. Dec 21 20:25:54 likewise: howdy Dec 21 20:42:44 khem: hi there! Dec 21 20:43:01 long time what are you upto these days Dec 21 20:43:06 hardly seen here Dec 21 20:43:34 khem: I played with FPGA's mostly, RISC-V a bit, and now back more on the Linux side of things Dec 21 20:43:52 i see Dec 21 20:44:19 khem: and you? I remember you we working on a big media centric RDK, Yocto based. Dec 21 20:44:26 we=where Dec 21 20:45:08 yes same thing still just different profiles home routers and stuff Dec 21 21:41:35 Anyone run into update_font_cache failing on ubuntu 14.04 due to qemu segfaulting? Dec 21 21:41:42 Don't see it on 16.04, only 14.04 Dec 21 21:51:52 Anyone have a good experience with toaster? Is it being used pretty commonly, or do folks tend to prefer just command line bitbake? Dec 21 22:04:36 kergoth: I think I saw qemu crashes on 14.04 dont remember if it was font-cache but gdk-pixbuf I think Dec 21 22:04:52 hmm **** ENDING LOGGING AT Thu Dec 22 02:59:59 2016