**** BEGIN LOGGING AT Fri Jul 12 02:59:57 2019
Jul 12 03:52:40 <Marex> hum, where's rburton when you want to reply to his PM
Jul 12 06:18:16 <chrusel> just wondering: poky warrior was bumped to 2.7.1 eleven days ago, what is missing for releasing it? I also saw that https://wiki.yoctoproject.org/wiki/Weekly_Status is a little outdated ... do you feel okay 'Yocto SWAT Team' <3 ?
Jul 12 06:20:11 <yocti> New news from stackoverflow: Audit daemon does not take rules from audit.rules <https://stackoverflow.com/questions/56337307/audit-daemon-does-not-take-rules-from-audit-rules>
Jul 12 06:20:16 <LetoThe2nd> chrusel: probably autotests still missing, or nobody gotten round to actually check and properly release it
Jul 12 06:21:04 <LetoThe2nd> chrusel: i personally tend to not take those tags overly serious, i just care about branches.
Jul 12 06:23:58 <litb> hello all
Jul 12 06:24:42 <litb> we want to compile our application separate from yocto. i.e without a recipe. but we still want to use the yocto compiler/linker etc, prefeably on the yocto build machine, directly using the yocto environment without the SDK
Jul 12 06:24:45 <litb> is this possible?
Jul 12 06:25:15 <LetoThe2nd> litb: its only software, so anything is possible.
Jul 12 06:25:39 <LetoThe2nd> litb: but why not do the sdk dance? i mean, its exactly what you seem to want
Jul 12 06:29:28 <litb> LetoThe2nd, i was in the impression that the SDK is for the developers, to develop their programs independent from other developers and the CI-systems
Jul 12 06:30:11 <litb> but we want to compile our applications on the CI systems of course. and if we always have to rebuild and install a new SDK or update an SDK on the CI-systems (buildbot) just to be able to compile our application
Jul 12 06:30:18 <litb> it seems that would be overkill
Jul 12 06:44:21 <LetoThe2nd> litb: hm. you could also use a pro-forma recipe and externalsrc
Jul 12 06:45:12 <litb> hm, i forgot about that. main reason is that we want to avoid mixing our company sources and resources with opensource yocto things
Jul 12 06:46:43 <LetoThe2nd> now thats a kind of no-reason
Jul 12 06:47:46 <LetoThe2nd> "we want to build with an open source toolchain provided by an open source build system that we already on on our servers"
Jul 12 06:48:21 <litb> LetoThe2nd, because when we release the source code of the system + the build scripts, we want the user to be able to rebuild the system. and our company software should not be part of that source code release
Jul 12 06:48:31 <LetoThe2nd> you can always set a breaking license on that pro forma recipe, but i mean in the end you'll probably want to ship your application anyways.
Jul 12 06:49:02 <LetoThe2nd> litb: there is more than enough documentation on that particular topic in the manual
Jul 12 06:49:52 <litb> hm, I find there's little documentation. for example, I don't find documentation how to tell yocto: "download this recipe's SRC_URIs to an alternative DL_DIR"
Jul 12 06:50:15 <litb> so that when done building the system, we can just zip-up the DL_DIR and create a mirror of it, for releasing it to the public
Jul 12 06:50:17 <LetoThe2nd> litb: providing the DL dir is not the way to go anyways.
Jul 12 06:50:36 <LetoThe2nd> litb: we have the archiver class thats exactly meant to do what you want.
Jul 12 06:50:51 <LetoThe2nd> -> create a source tarball for a particular build
Jul 12 06:51:00 <litb> LetoThe2nd, it is not able to archive the sources in a way that yocto can use them to rebuild the system
Jul 12 06:51:46 <litb> it just archives the sources and optionally the used recipes. but the sources are for example named in incompatible manner, not compatible to mirror-formats
Jul 12 06:52:10 <LetoThe2nd> ah. thats possible, yes.
Jul 12 06:52:20 <litb> GPL requires that sources are released together with build scripts so that users can rebuild their own modifications
Jul 12 06:52:43 <LetoThe2nd> litb: GPLv3 requires this. major difference!
Jul 12 06:54:42 <LetoThe2nd> anyways, for coming back to your actual problem. you'd have to somehow trick the build into providing a sysroot that you can use and harness from external.
Jul 12 06:54:59 <LetoThe2nd> its certainly possible, but i'm not aware of any documented use
Jul 12 07:05:02 <litb> LetoThe2nd, one thing that bugs is is that GPLv2 requires that build scripts be published with the source code. therefore, we would be required to publish yocto. but the archvier doesn't archive the buildsystem. just the recipes
Jul 12 07:05:31 <litb> the user may not need to be able to completely reproduce the system. but the build scripts need to be provided nontheless
Jul 12 07:07:02 <LetoThe2nd> litb: gplv3 requires this, not gplv2. its the main reason why so many stick to old gplv2 versions.
Jul 12 07:08:59 <litb> LetoThe2nd, GPLv2.0 says: "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. "
Jul 12 07:10:08 <litb> i think it's very plausible that this means that just providing the upstream tarballs + patches is not sufficient. this is also what we gathered from reading several books on gplv2
Jul 12 07:10:54 <LetoThe2nd> litb: i think i have heard other interpretations too, but of course. better be safe than sorry.
Jul 12 07:13:39 <RP> khem: We have seen that occasionally on the autobuilder, did think there was a possible ulimit issue of some kind
Jul 12 07:13:53 <RP> khem: I ended up turning prserv off since it was corrupting buildhistory
Jul 12 07:14:04 <RP> khem: is that with a single prserv?
Jul 12 07:17:22 <mcfrisk> hmm, why are ptests compiled in S, B seems to point there? protobuf ptest compilation is failing
Jul 12 07:17:28 <litb> LetoThe2nd, I suppose it's not possible to specify different download directories on a per-layer base?
Jul 12 07:17:43 <LetoThe2nd> litb: nope, never heard of that.
Jul 12 07:18:01 <LetoThe2nd> i mean in the end its only software..... :P
Jul 12 07:18:35 <litb> I wonder whether it's possible to build an SDK where the SDK contains the sources of specific packages, instead of the sstate-cache.
Jul 12 07:18:45 <LetoThe2nd> huh?
Jul 12 07:18:54 <LetoThe2nd> the sdk contains no sources and no sstate.
Jul 12 07:19:23 <LetoThe2nd> the esdk contains sstate.
Jul 12 07:19:24 <litb> normally the eSDK contains a populated sstate-cache with fixed checksums, so that you can't modify the recipes, but so that everything is already prebuilt
Jul 12 07:19:33 <litb> sorry, meant esdk
Jul 12 07:20:28 <litb> i wonder whether it's possible to let yocto build an SDK that builds everything from sources when saying "devtool build-image"
Jul 12 07:20:57 <LetoThe2nd> "its only software"
Jul 12 07:21:24 <litb> then, the build-sdk step would only include those sources that one wants in his sdk. and we would just blacklist our company recipes or layer and it magically wouldn't be included in source-form in the sdk
Jul 12 07:21:47 <litb> LetoThe2nd, how hard woudl it be to add this? does it sound useful at all, anyway?
Jul 12 07:22:24 <LetoThe2nd> i can see usecases, so it might be worth doing it. how hard, no idea.
Jul 12 07:22:31 <LetoThe2nd> RP: ^^^^^
Jul 12 07:26:31 <litb> maybe it suffices if we release the eSDK without sources actually, combined with the result of the archiver
Jul 12 07:26:57 <litb> after all, this would end up being the source code + scripts that control the build process. and the user is even able to modify source code and recompile the image
Jul 12 07:27:37 <litb> LetoThe2nd, with "devtool modify", the user can point eSDK to the tarball created by the archiver, right?
Jul 12 07:30:27 <LetoThe2nd> litb: i think that should work, yes.
Jul 12 07:31:23 <litb> not that it barks out if they provide a tarball from the archiver, but devtool expects a git-workingdirectory because SRC_URI is a git uri
Jul 12 07:32:18 <RP> litb: I don't think it would be hard to do that
Jul 12 07:33:45 <mckoan> good morning
Jul 12 07:36:29 <litb> good morning
Jul 12 07:38:41 <litb> LetoThe2nd, is it advised against to publish the eSDK to the public/customers? advised against to publish it for license-compliance purposes?
Jul 12 07:38:54 <LetoThe2nd> litb: i don't think so.
Jul 12 07:39:01 <litb> haven't read about this in the manual. is this just a creative way to be compliant?
Jul 12 07:42:00 <LetoThe2nd> litb: no i don't think so. what i meant to say is that i do not see any reason to *NOT* publish the esdk to customers.
Jul 12 07:45:49 <RP> litb: esdk was designed as a "half way house" between giving someone an sdk and the full build system
Jul 12 07:46:42 <RP> litb: e.g. how do you give an end user a way of rebuilding an image without the risk of the full build system?
Jul 12 07:47:14 <RP> litb: I think our view was that esdk is ok but we could still do better. Nobody has worked on trying another set of improvements to it as yet
Jul 12 08:02:17 <litb> i'm creating a container-layer  "meta-<company>" that contains other layers. i.e "meta-<company>/meta-<company>-os" "meta-<company>/meta-<company>-bsp" etc. this naming is a bit long. is there something wrong with this?
Jul 12 08:04:54 <LetoThe2nd> litb: technically no, meta-openembedded uses the same approach. just note that depending on your CI, commits might trigger rebuilds of unrelated things, and that you will have an intermingled commit log.
Jul 12 08:20:35 <yocti> New news from stackoverflow: Use different Sourcefiles in .bbappend (Immediate variable expansion) <https://stackoverflow.com/questions/57002931/use-different-sourcefiles-in-bbappend-immediate-variable-expansion> || Using Yocto with a distribution using python3 by defaults <https://stackoverflow.com/questions/28360862/using-yocto-with-a-distribution-using-python3-by-defaults> || Running Bitback with Python3, I have this error, Anyone can tell me t
Jul 12 09:00:34 <litb> one of my recipes needs to build a kernel module which is rather deep within the directories of a git repository of ours
Jul 12 09:01:36 <litb> the repository needs to be checked out by other recipes anyway. if i check it out in the kernel recipe, will yocto be smart enough to share the files between the recipes? i.e use hardlinks or something?
Jul 12 09:02:00 <litb> i know it will clone only once into the DL_DIR. but the source needs to be in the work-directory. and for that it needs to be copied
Jul 12 09:06:32 <RP> litb: no, it won't. You could however use a parameter in the fetcher url to limit the path it checks out to be some subtree
Jul 12 09:06:50 <RP> (it won't be smart enough to hardlink files)
Jul 12 09:07:11 <litb> ah, "subpath", thanks!
Jul 12 09:07:41 <RP> litb: sounds right, I'd have had to look at the code to know :)
Jul 12 09:30:28 <opennandra> hello just want to check if anyone have recipe for google-fluentd: https://github.com/GoogleCloudPlatform/google-fluentd
Jul 12 09:36:19 <RP> opennandra: have you checked the layer index?
Jul 12 09:36:30 <opennandra> RP: yes
Jul 12 09:36:47 <RP> opennandra: ok, good!
Jul 12 09:37:12 <opennandra> RP: I plan to work on it if there is no recipe available
Jul 12 10:02:41 <litb> what's wrong with this?   http://coliru.stacked-crooked.com/a/5fd350ef9bc8109b
Jul 12 10:03:07 <litb> it keeps checking out "sources/foo" directly into ${WORKDIR} rather than into ${WORKDIR}/git
Jul 12 10:03:45 <litb> and it fails to apply the patch. even though it applies between   a/foo/Makefile   and b/foo/Makefile   . it complains "can't find file to patch at input line 5"
Jul 12 10:04:00 <litb> this file is  "b/foo/Makefile"
Jul 12 10:04:57 <litb> in ${WORKDIR} there is a     foo/Makefile    . and the default "striplevel" option of patch files is  1. but even with an explicit ";striplevel=1" it won't work
Jul 12 10:08:09 <litb> ah i get it now... S = ... doesn't tell it where to checkout. but it tells yocto where to look for the source. the checkout dir is an option of the fetcher
Jul 12 10:20:08 <RP> litb: yes, get the checkout dir right and the rest should fall into place
Jul 12 10:57:01 <shan1> What is an efficient way to move from `krogoth` to `sumo`? Should I checkout the sumo branch in all the meta layers?
Jul 12 11:00:23 <tgoodwin> shan1: that's usually the way I go; that and read the release notes in the mega manual because there have been a lot of changes since krogoth.
Jul 12 11:00:27 <JaMa> yes, but if you're upgrading now, then it's worth spending some extra efford to upgrade all the way to warrior
Jul 12 11:00:54 <JaMa> sumo is out of support already
Jul 12 11:02:10 <tgoodwin> +1 what JaMa said, if you can.
Jul 12 11:02:56 <shan1> I am dependent on the phytec board's development. I inquired through them and said that for the board I use they currently have only krogoth and  rocko support! sumo is a bit of an opptimistic shot for me.
Jul 12 11:05:04 <tgoodwin> shan1: I recently jumped from rocko to thud and the main "gotcha" was changes to how DEPENDS and python modules interact, the need to install python-modules in my image, and boost changes breaking some of my libraries.
Jul 12 11:06:08 <shan1> Okay! looks like a weekend project to take up!
Jul 12 11:06:18 <JaMa> shan1: depends on how much you actually need from phytec, I don't know their BSP but some BSPs are relatively easy to use with newer releases with small fixes
Jul 12 11:07:50 <shan1> As of now I used their rocko dev for the board where the minimal image was build well. However when I tried bringing in InfluxDB recipes into it, it fails miserably.
Jul 12 11:08:40 <shan1> Everything with golang and npm is much of a hassle.
Jul 12 11:54:18 <rburton> tgoodwin: the python thing is a simple bug in the rdepends on numpy, patches welcome
Jul 12 12:00:19 <litb> What's the best approach if you need to install an out-of-tree kernel module into its  own directory in  /root  as opposed to the stadnard directory in  /lib/modules/<kernel>   ?
Jul 12 12:01:00 <rburton> why would you do that?
Jul 12 12:01:01 <litb> i'm thinking of using  module.class  but defining my  own do_install which would just manually install the   built .ko file to /root, and not call  module_install at all
Jul 12 12:01:16 <litb> rburton, our current system does that, and while porting to yocto, i want to change as little as possiböe
Jul 12 12:01:46 <rburton> use the usual class and then use a do_install_append to mv the file
Jul 12 12:02:42 <litb> hope it won't break the system  if a  kernel-module-... package doesn't install its file to  /lib/modules tho.
Jul 12 12:02:46 <litb> thanks, i will try that
Jul 12 12:04:11 <tgoodwin> rburton: thanks, I haven't had a chance to do anything with it yet.  I'm chasing my tail with a bake that keeps crashing in different spots.
Jul 12 12:04:30 <tgoodwin> ones that don't make any sense...have worked for a long time, completely untouched by patches, etc.  Yay...
Jul 12 13:20:08 <TurkCypriot> Hiya ppl, i need help acout yocto toaster. When i try to build core-image-minimal from the command line it's done and i could run my os by using qemu
Jul 12 13:20:54 <TurkCypriot> But when i try to create another project from the Toaster web panel i am facing an error
Jul 12 13:21:00 <TurkCypriot> Bad path or missing 'conf' directory (/home/hakan/poky/build/conf)
Jul 12 13:21:14 <TurkCypriot> How can i get rid off it any ideas??
Jul 12 13:23:02 <TurkCypriot> is there anyone alive up there?
Jul 12 13:25:16 <mckoan> TurkCypriot: mix YP command line with Toaster is now as safe as expected. Read our experience here http://wiki.koansoftware.com/index.php/Toaster_setup_and_usage
Jul 12 13:25:33 <mckoan> s/now/not
Jul 12 13:27:35 <TurkCypriot> Click on "New project", type a name and select "Import command line project", then specify the build path.
Jul 12 13:27:36 <TurkCypriot> ted build.
Jul 12 13:27:58 <TurkCypriot> This is what i am trying to do actually but i am facing this error
Jul 12 13:27:59 <TurkCypriot> Bad path or missing 'conf' directory (/home/hakan/poky/build/conf)
Jul 12 13:28:09 <TurkCypriot> i'll keep givin a try
Jul 12 13:28:19 <TurkCypriot> thank you very much mckoan.
Jul 12 13:30:39 <TurkCypriot> lOL.
Jul 12 13:30:46 <TurkCypriot> Another issue now
Jul 12 13:30:55 <TurkCypriot> DoesNotExist at /toastergui/newproject/
Jul 12 13:31:40 <TurkCypriot> im selecting "import command line project" and seting the existing project directory as "Import existing project directory"
Jul 12 13:31:47 <TurkCypriot> but now im facing this issue
Jul 12 13:31:57 <TurkCypriot> DoesNotExist at /toastergui/newproject/
Jul 12 13:32:00 <TurkCypriot> els/query.py in get, line 380
Jul 12 13:32:05 <TurkCypriot> kages',
Jul 12 13:41:21 <tlwoerner> does the linux-yocto tooling allow a user to configure a kernel build by _defconfig? e.g. make lpc32xx_defconfig; make
Jul 12 13:42:04 <tlwoerner> with u-boot the *_defconfig is specified by UBOOT_MACHINE
Jul 12 13:42:21 <tlwoerner> anything similar for linux-yocto?
Jul 12 13:43:09 <TurkCypriot> yes
Jul 12 13:43:20 <TurkCypriot> it allows
Jul 12 16:20:43 <litb> hello folks
Jul 12 16:56:26 <khem> RP: PRSERV_HOST = "localhost:0" is what we use in local.conf
Jul 12 16:59:28 <RP> khem: that isn't being shared so that isn't likely being useful
Jul 12 17:51:05 <khem> right we really dont use PR server
Jul 12 18:05:44 <khem> halstead: I am getting this error lately http://sprunge.us/EPGJSu on oe git, any ideas
Jul 12 18:05:52 <khem> it seems to be related to server
Jul 12 18:12:56 <halstead> khem, looks like the automated clean needs some tending to.
Jul 12 18:32:00 <opennandra> hi, I'm trying to setup provision image which will flash build image to emmc storage. Basically I define provision image and add dependency on provisioned image and then add rootfs_postprocess to copy provisioned image. But provision image do_rootfs is finished earlier before other image and it fails. Any idea how to setup proper dependency here? Thx
Jul 12 18:48:35 <khem> opennandra: you can add dependency on a given task of a recipe e.g. do_deploy[depends] += "depmodwrapper-cross:do_populate_sysroot"
Jul 12 18:49:49 <opennandra> ok I've added that and for copying [rovision image I plan to use  IMAGE_PREPROCESS_COMMAND
Jul 12 18:50:20 <opennandra> khem: so I need to add dependency on when first image is created ?
Jul 12 18:50:48 <khem> yes
Jul 12 18:51:43 <yates> in a yocto recipe, how do i specify special inclucde paths, such as the "dbus-1.0" in /usr/include/dbus-1.0? I know it's with the -I option, but how do you get all the upper level build path in the -I ?
Jul 12 18:52:25 <opennandra> khem: well it fails because previous image is not yet created even added dependency
Jul 12 18:53:36 <yates> is it $S or $D?
Jul 12 18:53:37 <opennandra> khem: do_rootfs[depends] += "final-image:do_rootfs"
Jul 12 18:54:02 <opennandra> yates: $S point to source and $D to destination
Jul 12 18:54:11 <JaMa> khem: that git error is IMHO caused by too many rebases locally, I have it on many repos from different servers, so I don't think it's server related
Jul 12 18:55:19 <yates> i need to get at the sysroot path, i believe
Jul 12 18:57:41 <yates> ${includedir} ?
Jul 12 18:59:54 <JPEW> yates: You want the ${STAGING_DIR} family of variables: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-sharing-files-between-recipes
Jul 12 19:02:08 <JPEW> yates: most likely ${STAGING_DIR_HOST}
Jul 12 19:03:01 <yates> is this sort of stuff defined in the staging class?
Jul 12 19:08:24 <yates> is there a command for listing all recipes?
Jul 12 19:09:57 <yates> JPEW: is dbus (actually libdbus, the native C API to dbus) built by another recipe or is it somehow automatically included in the build environment?
Jul 12 19:14:04 <yates> how can you show what packages are generated by a recipe?
Jul 12 19:14:31 <yates> i've foudn the dbus recipe with "bitbake-layers show-recipes"
Jul 12 19:16:21 <yates> JPEW: so if the dbus recipe generates .../dbus-1.0/dbus.h (and others), then how would you use the ${STAGING_DIR_HOST} to access that path in my own recipe do_compile task?
Jul 12 19:16:58 <yates> or anyone..
Jul 12 19:21:16 <LetoThe2nd> yates: the usual way is just DEPENDing
Jul 12 19:21:38 <yates> i've done that
Jul 12 19:22:07 <yates> but i'm getting the error /Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/smart-display/1.0+3398-r0/branches/production-1.0/lib/inc/dbusutil/dbusutil.h:8:23: fatal error: dbus/dbus.h: No such file or directory
Jul 12 19:22:36 <opennandra> yates: which build systemd is thing recipe using
Jul 12 19:22:41 <opennandra> cmake, automake ... ?
Jul 12 19:22:54 <yates> opennandra: my own make file
Jul 12 19:22:57 <yates> gnumake
Jul 12 19:23:56 <yates> i need to specify -I ${sysrootstuf}/usr/include/dbus-1.0 in my compiles do that "#include "dbus/dbus.h" will find the file
Jul 12 19:24:10 <yates> so how do i get ${sysrootstuff}?
Jul 12 19:24:20 <opennandra> yates: EXTRA_OEMAKE = "-"
Jul 12 19:24:59 <yates> you mean (e.g.) EXTRA_OEMAKE = "dbus-1.0"?
Jul 12 19:25:07 <opennandra> but path to dbus it's in sysroot
Jul 12 19:26:13 <opennandra> check recipe temp dir and see which include directoeies yocto add
Jul 12 19:26:23 <opennandra> also do you have dependency for dbus in your recipe?
Jul 12 19:27:55 <yates> let me ask the question this way: if i were running a compile command "gcc -c -I<path-to-toplevel-system-include-dir>/dbus-1.0 myfancycode.c", then what syntax at do_compile time with give me <path-to-toplevel-system-include-dir>>?
Jul 12 19:28:08 <yates> opennandra: i do already have the DEPENDS on dbus, yes
Jul 12 19:28:32 <yates> i can see dbus-1.0/dbus.h in my tmp folder (down deep)
Jul 12 19:28:52 <zeddii> by default the compiler is called with the sysroot parameter, which makes all the includes relative to that point.
Jul 12 19:28:57 <yates> s/with give me/will give me/
Jul 12 19:29:56 <yates> zeddii: yeah but you need to extend the sysroot down to the library's include subdirectory, in this case dbus-1.0
Jul 12 19:30:05 <yates> how do i do THAT with a -I?
Jul 12 19:30:33 <yates> lots of libraries work this way - their includes are in subdirectories under the main include directory
Jul 12 19:32:01 <yates> this same code builds on my desktop linux, but i have defined the proper -I command to swoop down into the dbus-1.0 subdirectory so the compile includes that path in its searching
Jul 12 19:33:02 <yates> perhaps it's for versioning. you might have dbus-0.7 and dbus-1.0, e.g.
Jul 12 19:33:14 <yates> surely this isn't that unusual?
Jul 12 19:33:35 * zeddii reads above. the EXTRA_OEMAKE is the right way to pass options to the build. or you'd have to append to CFLAGS, and oe_runake takes care of passing that into the build (assuming it is using gnu make).
Jul 12 19:34:38 <opennandra> yates: what about to use cmake and properly find dependencies
Jul 12 19:34:43 <opennandra> then it wil lsetup paths
Jul 12 19:34:48 <opennandra> and all will be good :)
Jul 12 19:35:07 <yates> yeah, sure ... i'm going to rewrite my entire build system to accommodate this.. .
Jul 12 19:35:15 <yates> pfffft.
Jul 12 19:36:23 <yates> zeddii: regarding EXTRA_OEMAKE, let me read more. are you saying it appends an include directory to the compiler search paths like a "-I <path>" does?
Jul 12 19:37:14 <zeddii> it is passed as-is to the call to make. so your makefile needs to be taking inputs from the environment, etc.
Jul 12 19:37:57 <yates> is just read this: https://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-EXTRA_OECONF
Jul 12 19:38:24 <yates> i thought i'd stated repeatly that i am NOT using automake/configure etc. just my own gnumake file
Jul 12 19:38:54 * zeddii isn't gong to scroll through history
Jul 12 19:38:59 * zeddii wanders off
Jul 12 19:39:21 <yates> zeddii: better to wander off than give bad information due to a lack of understanding..
Jul 12 19:39:27 <zeddii> hahahahah
Jul 12 19:39:37 <zeddii> funny.
Jul 12 19:39:44 <zeddii> great way to ask for help you have.
Jul 12 19:40:33 <yates> i just grow weary of wasting hours troubleshooting the bad advice i often get. and it's Friday afternoon and i'm getting cranky...
Jul 12 19:41:52 <halstead> khem, Can you check if the issue is resolved?
Jul 12 19:53:09 <khem> halstead: I will let you know once I push again to contrib
Jul 12 19:53:15 <opennandra> yates: try use : STAGING_INCDIR
Jul 12 19:53:28 <opennandra> -I ${STAGING_INCDIR}/... untested
Jul 12 19:53:41 <opennandra> you can at least get info where it is pointing
Jul 12 19:53:44 <opennandra> in logs
Jul 12 19:54:08 <halstead> Thank you khem.
Jul 12 19:55:13 <khem> yates: usually pkgconfig solves such path issues since we have pkgconfig aware of cross-compiling it will add the sysroot automatically
Jul 12 19:56:16 <khem> STAGING_INCDIR is OE specific and should not be used inside component Make systems unless OE is all you care for building for. Usually its better to make component build systems independent of meta builders
Jul 12 19:56:52 <opennandra> khem: this is true but soemtimes you just need to use it ;) if you cannot fix you makefile
Jul 12 19:58:23 <khem> when you head from San Francisco to Tokyo but do a 1 degree direction adjustment at beginning, thinking its small, you will end up being in hawaii instead of tokyo
Jul 12 19:58:40 <khem> so I always recommend to do the 'right thing' when you know it
Jul 12 19:58:56 <opennandra> khem: understand, was just joking
Jul 12 20:02:24 <khem> yates: on bad advice, Trust me you can dance - Vodka
Jul 12 20:03:32 <khem> should I heed to vodka ? prolly no :) but that my decision
Jul 12 20:03:47 <khem> also takes some knowing :)
Jul 12 20:05:12 <khem> JaMa:git prune should fix it, but it does not for contrib repos somehow
Jul 12 20:08:06 <JaMa> khem: ok, interesting - works for me
Jul 12 20:10:01 <yates> ha. vodka is good - yah!
Jul 12 20:12:51 <yates> khem: pkgconfig is a good suggestion
Jul 12 20:13:01 <yates> i use it some places already but not everywhere
Jul 12 20:13:50 <yates> (stated after yates noticed khem had been speaking about more than just vodka...)
Jul 12 20:13:58 <JaMa> halstead: can you please delete following 3 branches from meta-openembedded repo? http://git.openembedded.org/meta-openembedded/log/?h=jansa/dizzy jansa/fido jansa/master ?
Jul 12 20:14:40 <halstead> JaMa, Sure. Or I can add config to allow you to delete any jansa/* branch if you prefer.
Jul 12 20:15:27 <JaMa> you can just delete them, they are really old and I shouldn't create any more of them :)
Jul 12 20:15:36 <halstead> JaMa, One moment.
Jul 12 20:19:15 <halstead> JaMa, Removed now.
Jul 12 20:19:26 <JaMa> halstead: thanks
Jul 12 21:52:57 <yocti> New news from stackoverflow: does yocto have a package called realpath <https://stackoverflow.com/questions/57013620/does-yocto-have-a-package-called-realpath> || Yocto renames packages <https://stackoverflow.com/questions/57013587/yocto-renames-packages>
Jul 13 00:14:58 <khem> halstead: I think we can also delete stable/thud-next and stable/nmut
Jul 13 00:15:11 <khem> but lets confirm with Armin
Jul 13 01:23:25 <yocti> New news from stackoverflow: How do I set an environmental variable on my target board using a yocto recipe? <https://stackoverflow.com/questions/57015416/how-do-i-set-an-environmental-variable-on-my-target-board-using-a-yocto-recipe>
**** ENDING LOGGING AT Sat Jul 13 02:59:57 2019