**** BEGIN LOGGING AT Wed Nov 09 03:00:00 2016 Nov 09 06:18:27 benz: did some more digging. the first point seems to be that gcc-runtime.inc has to become libbacktrace-aware Nov 09 07:25:10 I would like to call `git describe` of meta-mylayer from an image recipe Nov 09 07:25:46 Is it possible to get the path of meta-mylayer in the image recipe Nov 09 07:39:42 svalan: Did ${COREBASE}/meta-yourlayer work? Nov 09 08:49:13 LetoThe2nd: jep, thought also of that, but you can't do that with RUNTIMETARGET Nov 09 08:50:11 benz: exactly, the recipe is just not aware of it. Nov 09 08:51:14 hi Nov 09 08:51:30 benz: plus, the RUNTIMETARGET_pn appending does not work Nov 09 08:51:44 somebody: Hi Nov 09 08:51:52 really? Nov 09 08:51:55 somebody: Hello Nov 09 08:51:55 at least not as expected Nov 09 08:52:00 somebody: Are you out there? Nov 09 08:53:47 somebody: Just nod if you can hear me Nov 09 08:53:54 somebody: Is there anyone at home? Nov 09 08:54:34 LetoThe2nd: Other question, do you now a good recipe by chance, which uses normal make and make install? I wanted an example to create my own openblas recipe Nov 09 08:55:14 LetoThe2nd: Or is there a special class which I could inherit? Nov 09 08:55:22 Conceptual question: when we build an SDK with yocto, which is the reason to create a separate sysroot that includes extra libs & headers and these aren't part of the original image rootfs? Nov 09 08:55:43 what is the extra sysroot you talk about? Nov 09 08:56:09 benz: there is a make example in the dev manual, is that not sufficient? Nov 09 08:56:33 benz: there is no such thing as "normal make and make install". the default behaviour is to run "make" for do_compile but if the makefile isn't using autotools/cmake/etc then there is no standard for install Nov 09 08:56:48 rburton: I mean after running the SDK installer u have a sysroot directory Nov 09 08:56:50 if it is autotools/cmake/etc then there's a class for that Nov 09 08:57:23 rburton: yeah found it, thx Nov 09 08:59:03 aV_V: yeah that's the SDK Nov 09 09:03:14 bananadev: Thank you! ${COREBASE} is a subrepo in mylayer, so by using ${COREBASE}/.. it works like a charm! Nov 09 09:39:08 @rburton is there a plan for a 2.1.2 release? Nov 09 09:46:39 ernstp: yes but i can't recall the planned date. soon. Nov 09 09:47:07 rburton: is 2.1 a bit "LTS"? :-) Nov 09 09:47:23 looks like it's getting more maintenance than previous releases Nov 09 09:47:36 security updates and stuff... Nov 09 09:47:50 ernstp: its always the last two releases Nov 09 09:48:13 armpit is a better maintainer than I was Nov 09 09:48:14 but I guess the activity on krogoth will drop sharply now that 2.2 is out Nov 09 09:48:57 ernstp: no LTS, just last two. Nov 09 09:51:01 rburton: I had the idea that there weren't very many .2 and .2 point releases but now I see there are Nov 09 09:51:08 .3 ... Nov 09 09:51:27 and a big update on the krogoth branch in the last days also :-) Nov 09 09:57:53 I want to sometime override BUILDNAME from the outside Nov 09 09:58:24 so I added BUILDNAME := "${@ d.getVar('BB_ORIGENV', False).getVar('BUILDNAME', False) or d.getVar('DATETIME', False) }" Nov 09 09:58:24 to local.conf Nov 09 09:58:38 that works... but it kills the recipe cache Nov 09 10:31:55 is there a clean way to do conditionnal appends on SRC_URI ? Nov 09 10:32:17 for example, apply a patch on a src tree only if DISTRO_FEATURES contains some flag ? Nov 09 10:38:46 not sure about distro features, but the usual appending rules should apply Nov 09 10:40:33 binarym: see https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides Nov 09 10:40:48 LetoThe2nd: yeah, i was on it thanks. Nov 09 10:40:54 binarym: sorry, current version is here: https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides Nov 09 10:50:29 LetoThe2nd: i don't understand well the OVERRIDE feature Nov 09 10:50:43 the variable selection isn't really clear for me Nov 09 10:51:21 OVERRIDES = "nfsroot" will check nfsroot var, right ? Nov 09 11:01:44 binarym: there's lots of stuff like this also: RDEPENDS_${PN} += " ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-plugin-limits pam-plugin-keyinit', '', d)}" Nov 09 11:04:31 hmmm Nov 09 11:04:40 this syntax looks easier to understand, thanks ernstp Nov 09 12:49:46 any ideas how oeqa test case IDs are generated? Nov 09 12:51:46 I'm looking at poky/meta/lib/oeqa/selftest/wic.py, most testcases have IDs assigned, but some are missing IDs thus if I run `oe-selftest --list-tests-by module wic` I get a nice backtrace Nov 09 13:01:54 mborzecki: they're just test IDs from testopia, see bugzilla.yoctoproject.org Nov 09 13:05:06 ok, so a test case without an ID is perfectly valid then? Nov 09 13:10:41 yeah absolutely Nov 09 13:10:59 if list-tests is breaking as a test doesn't have an ID, that's a bug Nov 09 13:48:16 i tried this : SRC_URI += ${@bb.utils.contains('DISTRO_FEATURES', 'nfsroot', "file://nfs_support.cfg", "", d)} Nov 09 13:48:27 in a .bbappend for a kernel recipe Nov 09 13:48:34 but bitbake complains about parse error Nov 09 13:49:32 binarym: quotes :), += "foo('')" Nov 09 13:49:57 with the inline python would be like += "${@foo('')}" Nov 09 13:50:19 nrossi: wow ... i feel such an asshole ... :) Nov 09 13:50:34 thx you :) Nov 09 13:50:37 np :) Nov 09 14:02:12 What are the plans for inclusion of the 4.9 kernel? Nov 09 14:02:38 I see the latest it git master is still 4.8 Nov 09 14:03:37 *in git Nov 09 14:05:02 (4.9 is still in RC, but when it is finally release, probably ultimo november, it will the next LTS kernel) Nov 09 14:34:22 rburton: thx, I'll be posting a fix for oe-selftest along with v2 of wic patches Nov 09 14:35:00 thanks mborzecki Nov 09 15:47:59 should I be able to install an allarch package in the nativesdk via TOOLCHAIN_HOST_TASK_append? Nov 09 15:49:01 an allarch nativesdk package, sure. an allarch target package, unlikely. more than just the architecture is different between target and nativesdk recipe builds Nov 09 15:49:42 so I would need to do also BBCLASSEXTEND =+ "native nativesdk" in the allarch pckg recipe? Nov 09 15:50:03 and then installvia TOOLCHAIN_HOST_TASK_append = " nativesdk-allarchpkg" Nov 09 15:52:33 you'd treat it as any other recipe, yes Nov 09 15:53:08 ... ah nasty one ... just done it like this and lost some cmake stuff since native there is no toolchain file ... longer story but ok like this it works Nov 09 15:58:00 hmm ... still ... should EXTRA_OECMAKE_nativesdk-${PN} = "-DCMAKE_INSTALL_PREFIX=/usr/" work? so I can give a special install prefix for the nativesdk package build? Nov 09 16:04:05 that'll break things, guaranteed Nov 09 16:04:12 but you're welcome to try Nov 09 16:10:15 ... drive me nuts ... is it correct that if I have something in an allarch pkg and I do bbclassextend I just get the stuff in the all ipk and since its "packed" away it is not ending up as well in the nativesdk pckg Nov 09 16:10:35 i have no idea what your'e talking about Nov 09 16:11:01 bbclassextend creates multiple entire recipes from the perspective of bitbake Nov 09 16:11:07 what one happens to package is irrelevent to the rest Nov 09 16:11:40 is the real problem that cmake is breaking when used in an allarch recipe, because allarch goes and ensures the compiler won't work? Nov 09 16:11:57 * rburton guessing Nov 09 16:13:55 I think the problem is I dont have real binaries ... it's a simple cmake macro ... why it is allarch it should end up in /usr/share/foo ... so and now I want the two ipks one in deploy/ipk/all and one in deploy/ipk/x86 which basically works but just the allarch contains the files the nativesdk package is empty and even is not existing then Nov 09 16:14:43 but I get the nativesdk-pn-dev and dgb :) Nov 09 16:16:00 sounds like your recipe is a bit bust Nov 09 16:16:10 nativesdk does set a different prefix Nov 09 16:16:16 can you share the recipe? Nov 09 16:17:15 ... just give me a sec try to make some reproducible one Nov 09 16:25:16 so ... basically this is what I want pretty stripped down ... http://pastebin.com/LfPj6rzW Nov 09 16:25:31 1         install -d ${D}/usr/share/foo                                         <— don't do that Nov 09 16:25:36 ${D}${datadir}/foo Nov 09 16:25:51 because nativesdk changes prefix Nov 09 16:26:45 ok ... originally I do this anyway in cmake but effectively should end up there Nov 09 16:27:12 is there a way to get display DISTRO_FEATURES and SRC_URI variables as in the scope of a .bbappend ? Nov 09 16:27:16 in recent versions there is a tool/script that manages multimple layers donwload like 'repo' but I don't remember the name Nov 09 16:27:53 do I remember it correctly and what is it? Nov 09 16:28:05 mdnneo: well ${prefix} isn't /usr in nativesdk recipes, so if you have one part of the recipe using ${D}/usr/share and eg FILES using the default assignments then it will break Nov 09 16:28:39 mckoan: combo-layer has existed since before yocto. it doesn't really manage multiple layers, but is a tool to squash multiple layers into one. Nov 09 16:28:50 (its what makes the poky repo) Nov 09 16:29:48 rburton: this is what I tried to "hack" via EXTRA_OECMAKE_nativesdk-${PN} = "-DCMAKE_INSTALL_PREFIX=/usr/" ... what is the prefix for nativesdk then? Nov 09 16:30:42 mdnneo: got a meeting but git grep will tell you if you start with nativesdk.bbclass Nov 09 16:32:06 rburton: thx Nov 09 16:33:06 rburton: strange poky/meta/conf/bitbake.conf says prefix_nativesdk = "/usr" ... Nov 09 16:34:01 mdnneo: is there a reason you're not using ${prefix} like everything else? what's the point in hardcoding it when we already know the correct prefix? Nov 09 16:34:15 mdnneo: but nativesdk does prefix = "${SDKPATHNATIVE}${prefix_nativesdk}" Nov 09 16:35:19 kergoth: was just a quick hack maybe simply because of this the nativesdk package is empty since they just end up somewhere else Nov 09 16:35:55 just strange I didn't get not installed and not shipped warnign? Nov 09 16:36:15 then the files aren't being installed at all Nov 09 16:40:13 kergoth: so in my small example do_install is not called for the nativesdk package?? Nov 09 16:41:56 that's not what i said. i said the files weren't installed, which could have multiple causes. it's up to you to determine which is the case Nov 09 17:06:49 If I am upgrading Yocto versions from 2.1 to 2.2, is there any chance of saving my "downloads" or shared state cache or is it best to start from a clean slate? Nov 09 17:07:23 Definitely keep your downloads directory Nov 09 17:07:29 dscully: definitely save downloads, it's just tarballs. you can reuse sstate but its quite unlikely anything in there matches. Nov 09 17:07:38 might as well start from scratch to save disk space Nov 09 17:08:10 ah ok, that makes sense.. thx Nov 09 17:15:58 hi i am using busybox and i want to use tftp ........can somebody tell me the steps Nov 09 17:16:12 ok so ... http://pastebin.com/AaMLs1Dp works now ... I think now I have a nativesdk package contains /sdkinstallpath/usr/share and an allarch pckg whith just /usr/share Nov 09 17:17:03 mdnneo: 1 FILES_nativesdk-${PN} = "${datadir_native}" shoud be redundant Nov 09 17:25:25 rburton: hmm ... ok not much left in my example ... ok still give it another try tomorrow with cmake ... thx so far Nov 09 17:28:00 let's say i have multiple recipes for the same software component. How can i find out wich one is used ? Nov 09 17:28:57 the layer with the highest priority should get picked Nov 09 17:29:14 you can override it thought with the preferred flag in local.conf etc Nov 09 17:29:32 binarym: and bitbake-layers show-layers Nov 09 17:30:26 ok, thx Nov 09 18:14:55 Goodday Gents, I am trying to create a machine layer for a new board we received. Is there some documentation anyone can recommend? Nov 09 18:16:24 Secondly I have started to try and create one but I'm basically getting a DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-XXXXXX issue. Where bitbake can't find packagegroup-cross-canadian-adsp-sc58x. Which elephant did I just not see Nov 09 18:39:27 which release are you on ? are you building SDK ? Nov 09 18:46:30 khem: I'm on krogoth atm, and I'm not building an sdk. I was hoping to rejig the existing probably beablebone/corexa5 stuff and import some patches from a custom kernel Nov 09 18:47:15 khem: honestly in the dark atm, so I would like to have something to read to make sense of what my objectives should be. Nov 09 18:48:11 khem: I'm reading the yocto manual on BSP's and anything else I can find. If you have something else that helps clarify the whole picture a bit I'd be greatful Nov 09 18:59:18 there are docs on yp website Nov 09 18:59:28 especially on adding new BSPs Nov 09 18:59:34 is relevant to your case Nov 09 19:01:29 khem: Ok i'll read some more and hopefully come with some more relevant answerable questions in the next few days :D. Thanks Nov 09 19:04:42 Where is the right place to put MACHINE settings, lets say I have an image I want to deploy on x86 and ARM, same packages but diff architecture. Is that something you can put in an image.bb Nov 09 19:53:28 Strike5150: you can't control that from the image recipe, it needs to be done at the configuration level (e.g. conf/local.conf) Nov 09 19:57:38 bluelightning: If thats the case it seems difficult do revision control and to build diff architectures, and by difficult I mean I have to edit conf/local.conf before running the image recipe. Is that correct? Nov 09 19:58:31 Strike5150: you can have multiple build directories, or you can pass MACHINE= before the bitbake command (provided you leave MACHINE set with ?= in local.conf) Nov 09 19:59:54 bluelightning: great thanks for the info Nov 09 20:37:01 Is it possible to whitelist environment variables from within a bitbake config file (ex: in local.conf)? BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE aren't clear about whether they are able to be used in this way. Nov 09 20:57:53 fishey1: You must set this variable in the external environment Nov 09 20:58:14 khem: so is that a "no" to the question I asked? Nov 09 20:58:29 thats rightt Nov 09 21:04:15 so it looks like I could use python and BB_ORIGENV to grab the item I'm after. Is there a reason I should avoid that? (will it have some bad effect on hashes?) Nov 09 21:07:53 blast, local.conf can't have python anonymous functions in it, apparently. Nov 09 21:18:13 fishey1: you can INHERIT += a class and then have the python stuff in that class though Nov 09 21:19:06 I'm curious though - why not just set BB_ENV_EXTRAWHITE externally? surely that's less complicated than this Nov 09 21:19:11 bluelightning: interesting. would that be a sane way of appending to DISTRO_VERSION though? Nov 09 21:19:30 bluelightning: I've just gone with appending a fragment to local.conf in the build, which is also pretty easy Nov 09 21:20:04 the standard way of bringing in stuff from the external environment is BB_ENV_EXTRAWHITE Nov 09 21:20:28 BB_ORIGENV is only really for things that you generally want filtered out but need to query under certain circumstances Nov 09 21:21:34 ok. I already had some local.conf appending in place (to set distro & machine), so it was easy to add a bit more: `DISTRO_VERSION .= "+${BUILD_TAG}"` (where BUILD_TAG gets expanded by the shell appending to local.conf) Nov 09 21:22:35 I guess I could set all of those with BB_ENV_EXTRAWHITE though Nov 09 21:22:52 right, that setting part makes sense ... all you'd need to do is set BB_ENV_EXTRAWHITE="BUILD_TAG" in the external environment (or prefixed on the bitbake command line) and set BUILD_TAG there as well Nov 09 21:26:28 Sure. I guess the thing is I've got a bitbake config fragment that does a bunch of things for this automated builder, so I was appending to local.conf something like `require conf/include/jenkins.inc`, lets me keep most of my config for the builder in 1 place. was hoping to add the bits to look at the BUILD_ID in environment there. Unlikely to switch to a pure BB_ENV_EXTRAWHITE setup because I'd likely need to Nov 09 21:26:30 create a script that does the exporting to mimic the bitbake inc fragment I've got. Nov 09 21:30:38 fishey1: aside: is there ar eason you're mucking with local.conf when auto.conf exists specifically for autobuilders and whatnot? :) Nov 09 21:50:54 kergoth: I didn't know about auto.conf until you mentioned it. Is there a reason I should prefer creating + appendning to it instead of appending to local.conf? Just cleanliness? Nov 09 21:55:42 I"m having an issue where my kernel zImage isn't present in /boot after build and I'm not sure why Nov 09 21:56:02 It only happens when trying to build for my custom MACHINE https://github.com/lolsborn/meta-bearclaw-bsp/tree/krogoth Nov 09 21:56:49 jmesmon: cleanliness, from bitbake's perspective there's no difference, just load order. if you read meta/conf/bitbake.conf, you can see the 'include' lines for local.conf, auto.conf, distro, machine, etc. Nov 09 21:57:00 I copied the bsp tree directly from yocto-bsp and just made a copy of beaglebone.conf to bearclaw.conf, and I have some uboot patches that are applied for that machine Nov 09 21:57:18 uboot works, but no kernel image present Nov 09 21:57:28 IF I go back to MACHINE=beaglebone I don't have issues Nov 09 21:59:28 lolsborn: recipes often use overrides. by changing the machine name, the older machine override is no longer applied Nov 09 21:59:44 you can use MACHINEOVERRIDES to include both 'bearclaw' and 'beaglebone' in your overrides, if the beaglebone overrides are still valid for bearclaw Nov 09 22:14:49 kergoth: in the machine overrides in recipes it is just FOO_beaglebone? I have ensured there is an equivalent FOO_bearclaw in all of the recipes I'm using. Nov 09 22:15:19 lolsborn: most likely you forgot about COMPATIBLE_MACHINE in the kernel recipe Nov 09 22:15:28 without which the recipe is seen as unbuildable Nov 09 22:15:48 https://github.com/lolsborn/meta-bearclaw-bsp/blob/krogoth/recipes-kernel/linux/linux-yocto_4.4.bbappend#L22 Nov 09 22:16:08 If I did that it would just complain loudly that it wasn't in the list Nov 09 22:16:47 Everything _seems_ to build fine without complains but there /boot/zImage is absent Nov 09 22:16:59 ah, i see Nov 09 22:19:12 the presence of the kernel in the image is usually a result of whether the kernel-image package is part of the image Nov 09 22:19:54 by default there is a dependency from the kernel package on kernel-image, so unless you were overriding that it should be there - but worth double-checking if it's in the image or not (check the manifests) Nov 09 22:28:00 adding kernel-image to MACHINE_EXTRA_RRECOMMENDS seemed to fix it. Kind of odd though. I basically just cloned yocto-bsp and made some slight modifications Nov 09 22:28:40 let me track down where that line is Nov 09 22:28:52 possibly pulled in by core-boot? hmmm Nov 09 22:29:09 meta/classes/kernel.bbclass:RDEPENDS_kernel-base ?= "kernel-image" Nov 09 22:29:22 unless for some reason kernel-base wasn't in the image? Nov 09 22:29:38 it's conceivable that if you had no modules and no other dependencies, it might not be Nov 09 22:30:12 bitbake -e | less would at least confirm that RDEPENDS wasn't being overridden Nov 09 22:30:25 well, bitbake -e virtual/kernel | less Nov 09 22:32:47 taking a look Nov 09 22:43:33 my comcast is insanely slow today. 900k/dl was getting 100mb yesterday Nov 09 22:46:15 This looks like it might be stomping on RDEPENDS? https://gist.github.com/lolsborn/d75153fde25351503130da4711edacd2 Nov 09 22:47:38 lolsborn: RDEPENDS_kernel-base should be listed separately Nov 09 22:49:20 it appears to be RDEPENDS_kernel-base="kernel-image" Nov 10 00:47:47 how do I move a module to a running VM using scp Nov 10 00:48:13 that's a good question! Nov 10 00:48:27 ty **** ENDING LOGGING AT Thu Nov 10 03:00:00 2016