**** BEGIN LOGGING AT Thu Jul 07 02:59:59 2016
Jul 07 06:56:27 <sambaran> guys is toaster working with the master branch?
Jul 07 06:56:42 <sambaran> for me it shows error
Jul 07 09:26:20 <gaurang> hi developers
Jul 07 09:27:27 <gaurang> how can we maintain linux kernel continuous development out of the yocto tree, still having some dependent recipes (like perf) inside yocto layer
Jul 07 09:27:31 <gaurang> any suggestion
Jul 07 09:27:53 <boucman_work> hmm
Jul 07 09:28:11 <boucman_work> do you need to modify perf or just recompile it with your modified kernel ?
Jul 07 09:28:28 <boucman_work> (I am not sure how tools like perf are built, yocto-wise)
Jul 07 09:29:04 <gaurang> there are even some kernel dependent recipes as well
Jul 07 09:29:47 <boucman_work> gaurang: and how do you develop your kernel ? do you use devtool (I think devtool can be used on kernels) externalsrc ? or do you just compile out of yocto and then replace the kernel on the generate images ?
Jul 07 09:30:23 <gaurang> currently it is inside yocto only
Jul 07 09:30:42 <gaurang> but like for continous development environment
Jul 07 09:31:22 <gaurang> like shall i build full yocto everytime when kernel developer commit their changes in git ??
Jul 07 09:32:15 <boucman_work> ok, so your devs work on their own git, then push to a repo and your CI infrastructure pulls from that repo, right ?
Jul 07 09:32:16 <gaurang> we have seperate kernel developers, who will keep committing their changes in git
Jul 07 09:33:13 <gaurang> yes kernel recipe is pointing to private repo
Jul 07 09:33:35 <gaurang> so for each commit, is it OK to build Yocto everytime? I don't think this is good idea
Jul 07 09:34:00 <gaurang> and I also need to take care kernel dependent other recipes
Jul 07 09:34:34 <gaurang> so confused like what is the best way to maintain always TOT of kernel ?
Jul 07 09:34:45 <boucman_work> gaurang: i am not sure I understand your question... it depends on the capacity of your CI, it's not really a yocto question
Jul 07 09:35:21 <gaurang> so you mean to say, per kernel commit, one yocto build ??
Jul 07 09:35:28 <boucman_work> I personnaly would rebuild nightly rather than on every commit, but that's really a question for you to answer...
Jul 07 09:36:06 <boucman_work> yocto is good at building "only what is needed" but when the kernel is changed, "what is needed" can be quite large
Jul 07 09:36:35 <gaurang> yes correct
Jul 07 09:38:37 <gaurang> because not i need to maintain kernel build, dependent recipe should also be built when there is a kernel change
Jul 07 09:38:45 <gaurang> so that is a big problem
Jul 07 09:40:30 <fredcadete> gaurang: are there that many recipes dependent on the *kernel*? considering that linux-libc-headers are separate
Jul 07 09:41:02 <gaurang> i would say for me its 8-9 recipes
Jul 07 09:41:22 <boucman_work> that's not many, you can probably rebuild at every commit...
Jul 07 09:55:09 <fredcadete> gaurang: maybe I'm not understanding your cost of "build full Yocto". Consider as well that if you reuse sstate, only the kernel+dependent recipes are built for that use case
Jul 07 09:57:42 <gaurang> yes cost is not much, but i would like to understand what is the best practise available and yocto developers are using
Jul 07 09:58:45 <lewiatan_> Hi. What will happen if I set do_configure_prepend() in my *.bbappend but such task is already in *.bb? I'm asking because I need to prepend something to existing prepend without changing original recipe.
Jul 07 09:58:59 <fredcadete> gaurang: ack. I'd also like to know of a better way if there is one
Jul 07 10:06:49 <rburton> lewiatan_: you can have multiple _prepends or _appends and they all apply
Jul 07 10:07:29 <lewiatan_> Great. Thank you rburton (and sorry to others for getting in the middle of conversation)
Jul 07 10:51:38 <learning_yocto> Hi! Is there any yocto variable with the absolute path of the layer in which your recipe is?
Jul 07 11:11:26 <rburton> learning_yocto: THISDIR?
Jul 07 11:12:18 <learning_yocto> That points to the recipe dir... I guess  could do ../../.. from there
Jul 07 11:12:27 <learning_yocto> but it would be nice if there was a varaible for the layer paht
Jul 07 11:13:37 <fredcadete> learning_yocto: LAYERDIR?
Jul 07 11:13:52 <fredcadete> oops it's only for layer.conf
Jul 07 11:29:10 <boucman_work> learning_yocto: out of curiosity, why do you need that ?
Jul 07 11:50:02 <learning_yocto> fredcadete: Yes.. I wish that was available from the recipies too....
Jul 07 11:50:38 <learning_yocto> boucman_work: because I have some scripts in a "scripts" folder under the layer. some packages need to call these scripts, so I need the path
Jul 07 11:51:37 <rburton> set a variable in the layer.conf
Jul 07 11:58:56 <learning_yocto> Umh, I will try that
Jul 07 11:58:58 <learning_yocto> thanks!
Jul 07 11:59:05 <learning_yocto> BTW, is there a variable with the name of the workspace?
Jul 07 11:59:07 <learning_yocto> with the path *
Jul 07 12:00:11 <boucman_work> what do you mean by workspace ? $TOPDIR ?
Jul 07 12:14:18 <learning_yocto> Yes! thanks
Jul 07 12:46:13 <learning_yocto> I am trying to make a recipe for some binaries which are needed on the development machine. They should also be included ni the sdk
Jul 07 12:46:55 <learning_yocto> I have used BBCLASSEXTEND = "native nativesdk" and I have added "DEPENDS += " mypackage-native" in those packages which need them
Jul 07 12:47:35 <boucman_work> DEPENDS is a recipe name, not a package name IIRC
Jul 07 12:47:38 <learning_yocto> Not sure how to implement the do_install() on the recipe for the native packages... The do_compile() generates several binaries in different paths. How should I implement the do_install method in order to have the binaries I need copieed?
Jul 07 12:47:39 <boucman_work> hmm
Jul 07 12:47:44 <boucman_work> or am I confused...
Jul 07 12:49:04 <rburton> everyone is confused!
Jul 07 12:49:21 <rburton> the recipe should use bbclassextend to be buildable for native and nativesdk
Jul 07 12:49:44 <learning_yocto> Yep, I have done that
Jul 07 12:49:45 <rburton> what do_install does is up to how the source builds, but generally speaking a do_install should work for all instances
Jul 07 12:50:06 <rburton> then a recipe which needs foo-native to build should depend on foo-native, as you say
Jul 07 12:50:11 <learning_yocto> yeah, so my source is a little bit special
Jul 07 12:50:28 <learning_yocto> In the do_compile several bianries are created
Jul 07 12:50:55 <learning_yocto> now I think in the do_install I need to copy them to some folder (${D}${bindir} ... ?) in order to be able to use them from any recipe
Jul 07 12:51:03 <rburton> yeah
Jul 07 12:51:26 <learning_yocto> oh, so is ${D}${bindir} the right folder?
Jul 07 12:51:32 <learning_yocto> do I also need to create any symbolic link?
Jul 07 12:51:51 <rburton> yes, and only if you want to make symlinks
Jul 07 12:51:54 <rburton> you don't need to
Jul 07 12:52:23 <learning_yocto> ok
Jul 07 12:52:23 <rburton> if you want nativesdk-foo in your SDK too - so you can run the binaries whilst using the sdk - then you need a variable i can't recall the name of
Jul 07 12:52:43 <learning_yocto> yes, I also need that
Jul 07 12:52:49 <learning_yocto> too bad you can recall that number =(
Jul 07 12:52:52 <learning_yocto> that name *
Jul 07 12:53:13 <learning_yocto> that name *
Jul 07 12:55:04 <rburton> SDK_RDEPENDS?
Jul 07 12:55:21 <learning_yocto> oh, i see what you mean
Jul 07 12:55:27 <learning_yocto> ok, i will look for that variable
Jul 07 12:55:28 <learning_yocto> thanks!
Jul 07 12:56:47 <rburton> yeah maybe append SDK_RDEPENDS in your image recipe with nativesdk-foo
Jul 07 12:56:54 <rburton> clearly this bit needs better documentation
Jul 07 12:57:24 <learning_yocto> shouldn't it be SDK_DEPENDS rather than SDK_RDEPENDS?
Jul 07 12:57:34 <learning_yocto> these are compile time dependencies
Jul 07 13:01:04 <rburton> SDK_DEPENDS is stuff that you need to build the sdk with
Jul 07 13:01:14 <rburton> you want RDEPENDS, things you want in the SDK
Jul 07 13:01:28 <rburton> (I think)
Jul 07 13:01:32 <learning_yocto> okey
Jul 07 13:01:37 <learning_yocto> thanks again
Jul 07 15:09:53 <joshuagl> vmeson: could you CC me, or let me know the # here, when you file the createrepo bug?
Jul 07 15:24:26 <lpapp> hey, why cannot opkg overwrite symlinks if some nasty colleague replaces symlinks manually in /usr/lib?
Jul 07 15:24:36 <lpapp> if I say opkg install mylib.
Jul 07 15:53:37 <florin> hi guys
Jul 07 15:54:03 <Guest80793> how can one know which version of bitbake works with a certain branch of openembedded?
Jul 07 15:54:12 <Guest80793> hi all
Jul 07 15:54:39 <Guest80793> more specifically, I need to know which version of bitbake works with the krogoth branch of openembedded
Jul 07 15:54:59 <Guest80793> openembedded-core that is
Jul 07 15:55:54 <rburton> Guest80793: https://wiki.yoctoproject.org/wiki/Releases, second table
Jul 07 15:58:32 <Guest80793> rburton, I tried that, using bitbake 1.30 and openembedded-core krogoth but I get this error
Jul 07 15:58:47 <Guest80793> http://pastebin.com/BZhbBrfV
Jul 07 15:58:58 <Guest80793> whereas this does not happen if using master of bitbake
Jul 07 15:59:19 <Guest80793> so I thought I did not get the correct matching between bitbake and openembedded-core but apparently there is a problem there
Jul 07 17:55:58 <khem> lpapp: opkg by default will not override however it does have options to do so
Jul 07 17:56:31 <khem> and if you are overriting files from different package its going to land you in trouble later when you update the original package.
Jul 07 17:56:42 <khem> so its better to resolve the namesapce issue beforehand
Jul 07 17:58:34 <lpapp> khem: it did not seem to overwrite with the overwrite options, either.
Jul 07 17:59:54 <khem> did you use --force-overwrite
Jul 07 17:59:57 <lpapp> khem: I tried --force-overwrite and --force-reinstall
Jul 07 18:00:30 <khem> interesting. here it has worked
Jul 07 18:00:34 <khem> whenever tried
Jul 07 18:10:38 <fester> so i have a device that boots an image that i think was built from yocto, how can i tell which target image it has?
Jul 07 18:11:06 <fester> like core-image-full-cmdline or core-image-lsb-sdk ?
Jul 07 18:13:47 <khem> fester: I dont think we have a standard way to denote that, however you may ask your device vendor if they have a version info file embedded into your rootfs
Jul 07 18:16:26 <fester> is there a typical location where that info might be found?
Jul 07 18:17:56 <fester> khem: thanks, by the way
Jul 07 19:26:41 <khem> fester: if the image has a package management tool like rpm or opkg on it then you may see what all packages are installed and deduce from that
Jul 07 21:08:55 <flor__> rburton, any clue about the rror I posted above?
Jul 07 21:16:49 <RP> flor__: it looks like you're trying to run bitbake master with python2 ?
Jul 07 21:17:38 <RP> flor__: either use oe-core master with bitbake master, or use the 1.30 branch of bitbake with the krogoth branch of oe-core. Master uses python3, the older 1.30 uses python2
Jul 07 21:18:39 <flor__> that error above is with oe-core krogoth and bitbake 1.30, Richard
Jul 07 21:19:10 <flor__> using oe-core krogoth and master bitbake works
Jul 07 21:27:37 <kergoth> bluelightning, RP: I notice dthe sstate mirror object availability progress bar replaces the preceding initializing tasks progress bar. I think there'd be value in keeping the previous one with its final completion time in the output. Would just need a newline on completion, I expect.
Jul 07 21:28:12 <bluelightning> kergoth: hmm perhaps yes - I think probably the issue is not calling finish() on the progressbar
Jul 07 21:28:27 <kergoth> ah, that'd make sense
Jul 07 21:40:06 <RP> flor__: it is not oe-core krogoth branch there. This is the code in the oe-core krogoth branch: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oe/maketype.py?h=krogoth#n56 and the get_callable_args() function does not have an inspect.signature() call.
Jul 07 21:41:23 <RP> well, http://git.openembedded.org/openembedded-core/tree/meta/lib/oe/maketype.py?h=krogoth#n56 but its the same code
**** ENDING LOGGING AT Fri Jul 08 02:59:58 2016