**** BEGIN LOGGING AT Wed Aug 28 02:59:57 2019
Aug 28 06:56:46 <Proffalken> LetoThe2nd / qschulz: I've just tried to run with "stock" poky and get exactly the same error about the *.bb files not being found.  I've uploaded the entire repo to https://github.com/proffalken/yocto-testing and would really appreciate it you or someone else could take a look and see where I'm going wrong given that this isn't specific to the original project I was working on?
Aug 28 07:16:24 <LetoThe2nd> Proffalken: the repo doesn't seem to contain the layer in question?
**** BEGIN LOGGING AT Wed Aug 28 07:17:39 2019
Aug 28 07:20:42 <qschulz> LetoThe2nd: one of us misinterpreted :) Let's see what Proffalken was trying to say
Aug 28 07:22:18 <LetoThe2nd> :)
Aug 28 07:55:38 <Proffalken> Hmmm, hang on, let me find out what's going on here...
Aug 28 07:55:47 <Proffalken> The layer should be in the "top level" directory
Aug 28 07:57:46 <Proffalken> hahahah, I pushed the wrong branch... try https://github.com/proffalken/yocto-testing/tree/my-yocto-2.7.1
Aug 28 07:58:12 <Proffalken> (as you can see, I've just cut&pasted the commands from the quickstart to get the branch name etc)
Aug 28 08:05:29 <LetoThe2nd> ok, now it makes sense :)
Aug 28 08:55:58 <qschulz> Proffalken__: which machine are you building for?
Aug 28 09:01:41 <qschulz> Proffalken__: cd /tmp; git clone https://github.com/proffalken/yocto-testing -b my-yocto-2.7.1; cd yocto-testing; source oe-init-build-env; [add /tmp/yocto-testing/meta-telegraf to BBLAYERS in conf/bblayers]; echo 'DISTRO_FEATURES+="systemd"' >> conf/local.conf; MACHINE=beaglebone-yocto bitbake telegraf;
Aug 28 09:01:46 <qschulz> no warning
Aug 28 09:01:47 <qschulz> building
Aug 28 09:03:13 <qschulz> I got the warning only when building qemux86 (default machine) because your recipe is buildable for arm only (and you explicited it). Then building beaglebone-yocto which is arm-based would have the same warning because telegraf can be built only when DISTRO_FEATURES has systemd in it
Aug 28 09:03:41 <qschulz> hence, you've got a layer without recipes in it because all the recipes (telegraf only) can't be built for the specific distro or machine
Aug 28 09:03:53 <LetoThe2nd> qschulz: interesting, i only set qemuarm, and still got the warning. didn't make the mental transition to enabling systemd too :-(
Aug 28 09:03:56 <qschulz> since this is resolved durnig parsing, you're including a layer which is empty
Aug 28 09:04:45 <qschulz> LetoThe2nd: I saw it only because I tried to build telegraf only and it failed for the two aforementioned reasons :)
Aug 28 09:04:57 <LetoThe2nd> qschulz: kudos, good find!
Aug 28 09:05:56 <qschulz> LetoThe2nd: \o/
Aug 28 09:07:18 <Proffalken> https://www.irccloud.com/pastebin/D3A4jVKf
Aug 28 09:07:35 <Proffalken> qschultz: Ah, cool, ok, so I need to add a systemd layer as well?
Aug 28 09:07:57 <Proffalken> I'm building for armhf (pi3/pi0) if that makes a difference?
Aug 28 09:09:07 <qschulz> Proffalken__: well that makes the recipe OK from the compatible_host/machine point of view. But you still need systemd in your DISTRO_FEATURES
Aug 28 09:09:38 <qschulz> because of https://github.com/proffalken/yocto-testing/blob/my-yocto-2.7.1/meta-telegraf/recipes-telegraf/telegraf/telegraf_0.1.bb#L22 , I assume
Aug 28 09:10:03 <qschulz> so 1. remove this if it's not a hard requirements
Aug 28 09:11:18 <qschulz> or 2. add DISTRO_FEATURES += "systemd" in the correct place (and I never know where it should be, maybe conf/local.conf but I don't like putting things there, or conf/machine/machineyoureusing.conf, or recipes-*/*/imageyourebuilding.bb or conf/distro/distroyourebuilding.conf)
Aug 28 09:11:40 <Proffalken> Cool, thanks, I'll give that a go...
Aug 28 09:12:00 <qschulz> Proffalken__: OR, have more than one recipe that does not depend on the compatible or distro features :)
Aug 28 09:12:20 <qschulz> but anyway, to be able to build telegraf you'll need a correct machine and a correct DISTRO_FEATURES
Aug 28 09:13:02 <qschulz> so having a second recipe "compatible-free and systemd-free" is just going to remove the warning but not going to make telegraf buildable
Aug 28 09:13:09 <yocti> New news from stackoverflow: YOCTO : Where can I find my linux image kernel headers Needed to build drivers and how can I install them? <https://stackoverflow.com/questions/57688613/yocto-where-can-i-find-my-linux-image-kernel-headers-needed-to-build-drivers-a>
Aug 28 09:29:54 <PinkSnake> I'm trying to create an extended sdk for dev team but i'm stuck here : checking target system type... Invalid configuration `x86_64-custdistro-sdk-linux': system `sdk-linux' not recognized. I can't find where the trouble is inside the distro conf ... any idea ? Full log: https://pastebin.com/Yuvm6KWc
Aug 28 09:43:15 <yocti> New news from stackoverflow: How to structure Yocto conf files for two different machines and same bblayers <https://stackoverflow.com/questions/57689040/how-to-structure-yocto-conf-files-for-two-different-machines-and-same-bblayers>
Aug 28 10:30:09 <MarcWe1> Hi, i have an issue whit my buid system/sdk ( i cant get geoclue to build ). arm-oe-linux-gnueabi-gcc gives the error  unrecognized command line option '-fstack-clash-protection'
Aug 28 10:31:01 <MarcWe1> and i can finde somthing in geoclue that is truning on the option
Aug 28 10:43:26 <yocti> New news from stackoverflow: Rotate framebuffer works only with 180° and 0° <https://stackoverflow.com/questions/57690401/rotate-framebuffer-works-only-with-180-and-0>
Aug 28 11:13:29 <yocti> New news from stackoverflow: Why does the yocto bblayers.conf file use absolute paths? <https://stackoverflow.com/questions/38890788/why-does-the-yocto-bblayers-conf-file-use-absolute-paths>
Aug 28 11:31:36 <orzen> Hi, just noticed that my patch (posted on 16th of august) havn't received any comments or got merged. How far does the patch backlog stretch and when can I expect that my patch get some attention? :)
Aug 28 11:43:35 <kroon> orzen, wiki page says its perfectly fine to send a reminder ping to the list, but the project is in feature freeze now I believe, so perhaps patch review/merge takes longer
Aug 28 11:58:31 <orzen> kroon: I see, thank you!
Aug 28 12:27:44 <zeddii> RP: sorry for not sending that series. *both* my builders had full disks, so I had to deal with that before starting my round of builds.
Aug 28 12:40:45 <RP> zeddii:  np, I'm having fun with plenty of other patches
Aug 28 12:44:02 <zeddii> I'm 3/4 of the way through the builds, so it will be out today.
Aug 28 12:45:25 <ykrons> Hi all
Aug 28 12:46:57 <ykrons> I'm trying to create a recipe from a git repository with devtool add ssh://git@stash.xxx.xx.com:7999/yyyy/zzzz.git
Aug 28 12:48:40 <ykrons> but I get an error Failed to fetch URL xxxx with ERROR: Command 'script -e -q -c "recipetool --color=always create --devtool -o /tmp/devtoolertuu76w 'git://git@stash.xxx.xx.com:7999/yyyy/zzzz.git'  -x /home/guillaume/data/Fusion/stuff/oe-core-SCR2/build/workspace/sources/devtoolsrc5vqso2w4" /dev/null' failed
Aug 28 12:51:12 <ykrons> Having a look to the recipetool commands, it seems the final SRC_URI generated is something like SRC_URI = "git://git@stash.xxx.xx.com/7999/yyyy/zzzz.git;protocol=ssh". It seems there is an issue with the custom ssh port 7999.
Aug 28 12:52:15 <ykrons> Does someone know the right way to pass URL to devtool / recipetool for git repository accessed through SSH on port 7999? I have tried to add ";port=7999" but it don't fix the issue
Aug 28 13:13:24 <jwessel> RP: Do you know where the checkvnc comes from?   I am trying to duplicate the failure that was detected to see whats up.  It will be interesting to understand the cause/effect, because I would not have expected any kind of drastic change with the fast fail tty for systemd.
Aug 28 13:13:49 <yocti> New news from stackoverflow: How to build a working TPM2 image for Raspberry Pi with Yocto? <https://stackoverflow.com/questions/57693130/how-to-build-a-working-tpm2-image-for-raspberry-pi-with-yocto> || Change YOCTO Linux kernel version <https://stackoverflow.com/questions/57692753/change-yocto-linux-kernel-version>
Aug 28 13:13:57 <jwessel> The log you pointed me at showed: Running '. ./oe-init-build-env; /home/pokybuild/yocto-worker/qa-extras2/yocto-autobuilder-helper/scripts/checkvnc; DISPLAY=:1 bitbake core-image-sato:do_testimage -k' with output to /home/pokybuild/yocto-worker/qa-extras2/build/build/command.log.6c
Aug 28 13:14:04 <jwessel> That is the checkvnc I was asking about.
Aug 28 13:20:01 <RP> jwessel: you mean the contents of that script?
Aug 28 13:20:26 <RP> jwessel: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/scripts/checkvnc
Aug 28 13:20:29 <jwessel> yes.  It seems to be related to the autobuilder.   I am not sure if that is part of the failure, part of the test or what.
Aug 28 13:20:45 <RP> jwessel: its ensuring there is a DISPLAY available
Aug 28 13:23:47 <jwessel> So in theory I just have to run:  bitbake core-image-sato:do_testimage
Aug 28 13:30:43 <RP> jwessel: yes
Aug 28 13:30:54 <RP> jwessel: that is just autobuilder boilerplate around the command
Aug 28 14:22:16 <ykrons> I find the issue, it has already been fixed : https://github.com/openembedded/openembedded-core/commit/4290e04b69360b5e1da9f37166015e30f66cb335
Aug 28 14:44:03 <yocti> New news from stackoverflow: Yocto recipe python whl package <https://stackoverflow.com/questions/48660051/yocto-recipe-python-whl-package>
Aug 28 15:32:44 <__angelo> is there a suggested linxu distro to work with yocto ?
Aug 28 15:33:01 <__angelo> *linux :)
Aug 28 15:33:16 <fray> no, but there are basic functional requirements..
Aug 28 15:33:16 <LetoThe2nd> __angelo: anything listed in the manual as being supported?
Aug 28 15:33:35 <LetoThe2nd> fray: "it boots", "it can run vi"
Aug 28 15:33:47 <fray> Ubuntu seems to be the easiest to get a modern system to build easily, but RHEL/CentOS 7 works fine..  I've not used RHEL 8 yet..
Aug 28 15:34:03 <fray> but RHEL/CentOS 7 may require some additional (newer) software to be installed..
Aug 28 15:34:13 <__angelo> LetoThe2nd, the fact is that i fight to work with an updated linux. Ok will check.
Aug 28 15:34:49 <LetoThe2nd> my vote would be in ubuntu too. if in doubt, yank up a docker container running it on whatever your preferred host system is (that my technique)
Aug 28 15:34:59 <fray> if you are on a specific release, say 'Thus' (YP 2.8).. then you should create a VM or Container with a Linux OS from that era.. say Ubuntu 18.04 LTS.. and use that for development.. because newer OSes will change interfaces that the system may depend on.
Aug 28 15:35:15 <fray> but for 'master', it should work on the latest versions of the common OSes
Aug 28 15:36:16 <__angelo> fray,  LetoThe2nd ok thanks
Aug 28 15:43:24 <RP> nrossi: let me know if/as/when you're around
Aug 28 16:52:01 * zeddii waits for the last builds to complete ....
Aug 28 17:03:45 * kanavin_ is running a world build in a python2-less environment
Aug 28 17:04:05 <kanavin_> so far, ca-certificates has failed, and, surprisingly, pseudo
Aug 28 17:06:17 <smurray> kanavin_: I did a bit of tinkering with that yesterday as well, I'm wondering did you tweak things so python -> python3, or did you remove it altogether?
Aug 28 17:07:08 <kanavin_> smurray, I removed it on the host distro, then dropped it from HOSTTOOLS, and also dropped the python-native and python recipes for good measure
Aug 28 17:07:26 <kanavin_> python -> python3 is a really wrong thing to do
Aug 28 17:08:20 <smurray> kanavin_: slight issue is some distros have done it, so there are some checks for it
Aug 28 17:08:53 <kanavin_> smurray, I have removed that bit as well
Aug 28 17:09:37 <smurray> kanavin_: you went further than I did, I left the python recipes in place so python-native could work, as I thought that was RP was implying on the call yesterday
Aug 28 17:10:08 <kanavin_> smurray, there are basically 3 recipes that need them, ltp, perf and kernel-devsrc
Aug 28 17:10:17 <kanavin_> I fixed ltp, and removed perf and kernel-devsrc :)
Aug 28 17:10:28 <kanavin_> (and tweaked the packagegroups to not include them)
Aug 28 17:10:41 <kanavin_> I trust Bruce will get to fixing the last two
Aug 28 17:10:57 <kanavin_> okay llvm-native is the latest to go bust
Aug 28 17:11:02 <smurray> kanavin_: I think my having python -> python3 avoided some issues, ca-certificates and pseudo built here
Aug 28 17:11:38 <kanavin_> smurray, good to know they're compatible with py3 then, it's probably a matter of patching them to use python3 explicitly
Aug 28 17:11:41 <smurray> kanavin_: systemtap blew up for me, but I suspect its python3 detection logic is wonky and may work with just python3 available
Aug 28 17:14:38 <smurray> kanavin_: I did look at kernel-devsrc a bit, afaict all the scripts in the kernel "scripts" directory are python3 compatible, though some of them use /usr/bin/python :/
Aug 28 17:16:23 <kanavin_> smurray, right, I trust Bruce will find the right way to handle this, as he knows better what scripts are important
Aug 28 17:16:31 <smurray> kanavin_: yeah
Aug 28 17:20:56 <RP> kanavin_, smurray: this all sounds like good data. I suspect pseudo's python usage is really simple and easily tweaked to python3 explicitly
Aug 28 17:21:07 <RP> zeddii: cool
Aug 28 17:22:07 <smurray> kanavin_: I think the only other thing I noticed that would need cleanup is the gpgme recipe, the python2 PACKAGECONFIG would need to be removed
Aug 28 17:23:05 <kanavin_> smurray, yes, but it is not enabled by default, so not a priority really :)
Aug 28 17:23:13 <smurray> kanavin_: and I just noticed with grep that there's a PACKAGECONFIG in alsa-tools  that references "python-core python-pygobject pyalsa"
Aug 28 17:23:20 <kanavin_> smurray, same there
Aug 28 17:23:28 <smurray> easy enough to fix
Aug 28 17:23:31 <kanavin_> RP: I fixed ca-certificates and pseudo, and resumed the build
Aug 28 17:23:56 <kanavin_> RP, it's at gcc-cross now, so the bulk of recipes are yet to be tests
Aug 28 17:24:02 <kanavin_> *tested
Aug 28 17:24:10 <zeddii> kanavin_, yah. I have the kernel ones done. they'll be in my series in a few hours
Aug 28 17:30:17 <smurray> heh, I need a second build machine, I switched off of python tinkering to churn some AGL builds
Aug 28 19:59:27 <RP> smurray: As long as they're not on my default they're ok. We have precedent for things which add dependencies external to oe-core as long as they're not default
Aug 28 20:03:44 <smurray> RP: is the thinking that the python 2 recipes will shift to meta-python?
Aug 28 20:12:46 <RP> smurray: probably a dedicated meta-python2
Aug 28 20:13:02 * zeddii nods. 
Aug 28 20:13:15 <zeddii> RP: you’ve seen my series, I think the kernel can be out from under the python2 thumb now :D
Aug 28 20:14:34 * zeddii is glad to get that fixed up. 
Aug 28 20:54:41 <Crofton|work> zeddii, thanks
Aug 28 20:58:20 <RP> zeddii: yes, sounds good thanks :)
Aug 28 21:15:47 <smurray> RP: it occurs to me that u-boot is unresolved wrt python.  I asked Tartarus, aiui the python3 support for libfdt is tied to other changes that currently block a simple upgrade of libfdt in the u-boot tree
Aug 28 21:16:55 <Tartarus> And we're in turn grumbling at libfdt folks
Aug 28 22:06:41 <RP> Tartarus: :/
Aug 28 22:06:57 <RP> smurray: on the call the other day it seemed uboot would be the final hurdle
Aug 28 22:07:37 <Crofton|work> but that doesn't inject py2 into the image?
Aug 28 22:07:46 <smurray> RP: yep
Aug 28 22:07:56 <smurray> Crofton|work: correct
Aug 28 22:08:13 <RP> zeddii: can I just remove that foo patch?
Aug 28 22:08:14 <zeddii> sometimes random bikeshedding on patch series tires me out.
Aug 28 22:08:21 <zeddii> RP. yup.
Aug 28 22:08:28 <zeddii> I just git rm'd it and rebased the patch.
Aug 28 22:09:10 * zeddii goes into only reply to useful comments mode.
Aug 28 22:09:32 <RP> zeddii: thanks, I'll just delete it than rejuggle patches :)
Aug 28 22:09:47 <zeddii> yah. my v2 was more overhead than it was worth :D
Aug 28 22:10:03 <zeddii> that'll teach me to "git add ." in myeta/recipes-kernel/ :D
Aug 28 22:10:18 <RP> zeddii: just trying to think of the easiest way to fix it in my tree :)
Aug 28 22:10:53 <zeddii> I hear you. I'm not a fan of a single v2 in the middle of a series, but re-issuing it, seemed worse in this case.
Aug 28 22:11:10 <RP> zeddii: right, that is fine. I just had to check that was the only difference
Aug 28 23:05:40 <RP> zeddii: first error is in: https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/975 :/
Aug 28 23:07:32 <RP> zeddii: looks like some scripts still reference "python" :/
Aug 28 23:15:27 <yocti> New news from stackoverflow: How to install files in the native sysroot with yocto when doing populate_sdk? <https://stackoverflow.com/questions/57576746/how-to-install-files-in-the-native-sysroot-with-yocto-when-doing-populate-sdk>
Aug 28 23:45:32 <yocti> New news from stackoverflow: Cross compiling a kernel module issue in Makefile <https://stackoverflow.com/questions/57701136/cross-compiling-a-kernel-module-issue-in-makefile>
Aug 29 00:11:35 <zeddii> RP: bugger! will send an updated patch.
**** ENDING LOGGING AT Thu Aug 29 02:59:57 2019