**** BEGIN LOGGING AT Thu Jul 11 03:01:20 2019
**** BEGIN LOGGING AT Thu Jul 11 03:41:56 2019
Jul 11 07:18:43 <Dvorkin> did anybody see overlayfs for / in yocto/oe?
Jul 11 08:28:36 <mcfrisk> what change between sumo/2.5 and warrior/master could cause our custom image creation classes to fail with missing package index files? I can't seem to find the differences in task or their ordering. we are adding custom tasks after do_rootfs before do_image_complete.
Jul 11 08:30:44 <mcfrisk> failures look like "../our-image-image/1.0-r0/oe-rootfs-repo/Packages: No such file."
Jul 11 08:31:46 <shan1> I am trying to move from krogoth to rocko for Phytec IMX6 boards and was unable to get past through the error logs which are thrown whilst making a recipe for influxdb. I have documented the it as a [SE Query](https://stackoverflow.com/questions/56761899/influxdb-recipe-for-yocto-fails-with-devtool-workflow-in-rocko) but I am unable to get a soluti
Jul 11 08:31:47 <shan1> on as to why the build fails
Jul 11 09:02:41 <mcfrisk> gah, my problem was the missing self.pm.write_index() call. somehow lost the fix again..
Jul 11 10:36:24 <TurkCypriot> Hi follks
Jul 11 10:36:40 <TurkCypriot> i need a pre-build yocto for vmware
Jul 11 10:36:53 <TurkCypriot> Can anybody help me about finding and running on vm?
Jul 11 10:37:30 <LetoThe2nd> TurkCypriot: maybe you should rather point out what it should be used for, or what you expect to gain from it.
Jul 11 10:37:58 <TurkCypriot> Just for testing and developing purposes
Jul 11 10:38:00 <LetoThe2nd> i mean, running a generic minimal image is like... not exactly offering a lot of functionality or such.
Jul 11 10:38:15 <TurkCypriot> My main goal's to run and develope a .net core application
Jul 11 10:38:38 <LetoThe2nd> TurkCypriot: ok, and what do you expect a generic image to help you there?
Jul 11 10:38:40 <TurkCypriot> yes minimal- build i'Ll need
Jul 11 10:39:03 <LetoThe2nd> and then?
Jul 11 10:39:06 <TurkCypriot> My company's
Jul 11 10:39:13 <TurkCypriot> developing casino games like SlotUI
Jul 11 10:39:34 <LetoThe2nd> i don't really care about your application. just tell me. you boot it, and then?
Jul 11 10:39:35 <TurkCypriot> and we have a dispatcher application which runs on dotnet core on centos
Jul 11 10:40:01 <TurkCypriot> i will move our application on yocto officially
Jul 11 10:40:24 <TurkCypriot> and then we will run this application with small boxes like rpi or latte panda vs..
Jul 11 10:40:38 <LetoThe2nd> i don't think you got the point. how do you expect the minimal image to help you?
Jul 11 10:41:06 <TurkCypriot> yes sorry for my english
Jul 11 10:41:22 <LetoThe2nd> just try to explain what you want to do with the minimal image once it is booted.
Jul 11 10:41:29 <TurkCypriot> i just want my minimal yocto to run dotnet application and identify hardware
Jul 11 10:41:37 <TurkCypriot> like ethernet and usb
Jul 11 10:41:44 <LetoThe2nd> but a minimal image will not do that.
Jul 11 10:41:53 <TurkCypriot> so minimal yocto probably will feed my needs
Jul 11 10:42:10 <LetoThe2nd> it will not bring dotnet, it will not offer ethernet connectivity, it will not offer ssh to copy anything in....
Jul 11 10:42:19 <LetoThe2nd> so what do you *ACTUALLY* want?
Jul 11 10:42:28 <TurkCypriot> i'll add metadatas ofcourse
Jul 11 10:42:48 <LetoThe2nd> and thats where you are wrong
Jul 11 10:42:54 <TurkCypriot> i see sir.
Jul 11 10:43:02 <LetoThe2nd> yocto is not a distribution where you can add things at will
Jul 11 10:43:02 <TurkCypriot> So what's the correct path that i need to follow
Jul 11 10:43:32 <LetoThe2nd> it is a toolkit to create a distribution that suits your needs. so you need to start out with a simple build and add the things you need
Jul 11 10:44:08 <LetoThe2nd> actually, since only 2 days, we have a couple of WONDERFUL videos on youtube explaining hands-on how to get started. :)
Jul 11 10:44:30 <TurkCypriot> Sounds great for noobs like me :)
Jul 11 10:44:48 <TurkCypriot> Can you please share the links if  you have?
Jul 11 10:45:04 <LetoThe2nd> i think you can google the link just as good as i can
Jul 11 10:45:05 <TurkCypriot> i already used yocto minimal before
Jul 11 10:45:14 <LetoThe2nd> youtube yocto project :)
Jul 11 10:45:20 <TurkCypriot> i have build with some metas
Jul 11 10:45:25 <TurkCypriot> for playing gif files.
Jul 11 10:45:33 <TurkCypriot> but it was 3 years ago
Jul 11 10:46:05 <TurkCypriot> so i mean i am not that beginner
Jul 11 10:46:19 <TurkCypriot> also i am developing c++ projects over 18 years
Jul 11 10:46:30 <LetoThe2nd> that is all nice and well
Jul 11 10:46:47 <TurkCypriot> and i have also worked for defence industry for 12 years
Jul 11 10:46:52 <TurkCypriot> yes. these r nice
Jul 11 10:46:52 <LetoThe2nd> sweet. and?
Jul 11 10:47:10 <yocti> New news from stackoverflow: Updating Yocto causes exception 'bb.data' has no attribute 'getVar' <https://stackoverflow.com/questions/56986970/updating-yocto-causes-exception-bb-data-has-no-attribute-getvar>
Jul 11 10:47:12 <TurkCypriot> and next time when someone asked  for help
Jul 11 10:47:20 <TurkCypriot> please don't be rude that much
Jul 11 10:47:37 <TurkCypriot> you are acting like you are professional
Jul 11 10:47:53 <LetoThe2nd> if you think that telling you that your appraoch is completely wrong is rude, then i beg your pardon.
Jul 11 10:47:59 <LetoThe2nd> but your approach is wrong.
Jul 11 10:48:05 <TurkCypriot> No
Jul 11 10:48:09 <TurkCypriot> i say it is not
Jul 11 10:48:19 <LetoThe2nd> and i tried to guide you to creating that conclusion for yourself.
Jul 11 10:48:22 <TurkCypriot> i have experience with yocto and i know what i am looking for
Jul 11 10:48:33 <LetoThe2nd> if you think you know better, then well, go ahead, and have fun!
Jul 11 10:48:33 <TurkCypriot> i have just asked for the pre-built binary for the vmware
Jul 11 10:49:02 <LetoThe2nd> well then good luck.
Jul 11 10:49:06 <TurkCypriot> Lol
Jul 11 10:49:22 <TurkCypriot> i thought ur greeting bot at first really
Jul 11 10:49:35 <TurkCypriot> if you don't know anything about yocto minimal
Jul 11 10:49:40 <TurkCypriot> and adding metas
Jul 11 10:49:43 <TurkCypriot> just google it
Jul 11 10:49:55 <TurkCypriot> u'll see that yocto is more than what you know
Jul 11 11:46:52 <tgoodwin> Has anyone tried having two git fetchers in a recipe?  I've given each a different destsuffix however the first unpack seems to get clobbered.
Jul 11 11:47:23 <yocti> New news from stackoverflow: How to debug kernel crash on /sbin/init during bootup? <https://stackoverflow.com/questions/56987978/how-to-debug-kernel-crash-on-sbin-init-during-bootup>
Jul 11 12:04:58 <jmiehe> anyone familiar with meta-rust?
Jul 11 12:08:17 <mckoan> Has anyone tried Qt5 with MACHINE=qemux86 ?
Jul 11 12:14:21 <jmiehe> can I update the hosttools inside my own layer?
Jul 11 12:15:32 <tgoodwin> Never mind on mine..it was an override-specific append that was actually clearing SRC_URI.  Fix was to not mix an override with += ;-)
Jul 11 12:15:40 <tgoodwin> I shoudl know better by now.
Jul 11 12:46:59 <__angelo> how could i add cryptsetup to a sumo image recipe ? seems not in the recipe list
Jul 11 12:49:02 <LetoThe2nd> __angelo: it exists at least in master, so in the worst case you have to backport: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-crypto/cryptsetup/cryptsetup_2.1.0.bb?h=master
Jul 11 12:54:40 <jmiehe> I found an answer "HOSTTOOLS is a global configuration option, its not per-recipe. You therefore need to set it in the core distro config, not in a recipe." (https://lists.yoctoproject.org/pipermail/yocto/2018-March/040280.html)
Jul 11 12:54:40 <jmiehe> Ok, not per-recipe, but can I induce a change per-layer? If so, how? If not, where else?
Jul 11 12:56:46 <__angelo> LetoThe2nd, many thanks. In sumo is not there, so i backport it
Jul 11 12:58:24 <rburton> jmiehe: layer.conf works, iirc
Jul 11 13:00:02 <LetoThe2nd> __angelo: have fun
Jul 11 13:00:54 <jmiehe> rburton: to add hosttool "foo", what would I write?
Jul 11 13:00:54 <jmiehe> HOSTTOOLS_append = "foo"
Jul 11 13:00:54 <jmiehe> HOSTTOOLS += "foo"
Jul 11 13:00:54 <jmiehe> or something with an array notation? Where is the original definition of HOSTTOOLS?
Jul 11 13:01:08 <rburton> you can see that in bitbake.conf
Jul 11 13:02:36 <rburton> so either += or _append works but if you use append remember the whitespace quirk
Jul 11 13:02:52 <rburton> (i'd just use +=)
Jul 11 13:02:54 <jmiehe> where is bitbake.conf?
Jul 11 13:03:18 <jmiehe> I have local.conf
Jul 11 13:03:25 <jmiehe> or bblayers
Jul 11 13:03:35 <rburton> its part of oe-core
Jul 11 13:06:33 <jmiehe> meta-oe/recipes-core?
Jul 11 13:07:58 <jmiehe> … found something
Jul 11 13:10:06 <jmiehe> find project/ -iname "bitbake.conf" => poky/meta/conf/bitbake.conf
Jul 11 13:10:31 <jmiehe> so HOSTTOOLS seems to be a simple space-separated string rather than an array
Jul 11 13:21:41 <jmiehe> rburton: thanks, HOSTTOOLS += "foo bar" added both tools to HOSTTOOLS. Nice!
Jul 11 13:22:23 <jmiehe> (obviously added them to HOSTTOOLS, but more importantly, it added the links in hosttools directory, too.
Jul 11 13:30:07 <jmiehe> can I also change an env variable (for build process, not for target) in my layer.conf?
Jul 11 13:32:52 <jmiehe> this might be as simple as an `export VAR=value` in the layer.conf -- sorry to bother.
Jul 11 13:50:18 <__angelo> LetoThe2nd, seems quite full od dependencies. Is there any other way ?
Jul 11 14:05:58 <jmiehe> now my bitbake is trying to build cdrtools-native and I don't know why. Can I find out where that dependency comes from?
Jul 11 14:06:51 <LetoThe2nd> __angelo: updateing or trying to strip down dependencies.
Jul 11 15:14:13 <rburton> jmiehe: to build an iso, because you've got hddimg selected as the image type
Jul 11 15:47:02 <tlwoerner> zeddii: OE linux kernel versioning seems off (?) the 4.14 OE kernel is at 4.14.40 but the highest 4.14.y ever went upstream is 4.14.20?
Jul 11 15:52:26 <zeddii> do you mean 4.18 and not 4.14 ? Paul Gortmaker has been making (and announcing) stable updates to 4.18 on the linux-yocto list for a while, and continues to number off then end of where Greg stopped.
Jul 11 15:52:58 <tlwoerner> zeddii: oops, yes 4.18
Jul 11 15:53:10 <tlwoerner> okay thanks
Jul 11 15:54:21 <tlwoerner> 4.18.20 vs 4.18.40
Jul 11 16:24:56 <aehs29> RP: ok great, I guess my problem with the ML is just with the oe-core one then
Jul 11 16:28:39 <tlwoerner> for me: upstream kernel.org 4.18.20 compiles fine, linux-yocto-4.18.40 doesn't :-(
Jul 11 16:29:03 <armpit> tlwoerner, the base kernel version and the YP BSP may not be at the save version either
Jul 11 16:29:30 <tlwoerner> armpit: more fun :-S
Jul 11 16:29:45 <armpit> is this master or stable ?
Jul 11 16:30:04 <tlwoerner> thud
Jul 11 16:30:08 * RP wonders how long to wait for review on runqueue changes
Jul 11 16:30:20 <armpit> ship it
Jul 11 16:30:35 <RP> armpit: tempting ;-)
Jul 11 16:32:31 <fray> tlwoerner you can back off to an older version if you need to -- but if something is broken, we really should try to fix it
Jul 11 16:33:43 <tlwoerner> i've added an upstream remote from kernel.org/linux-stable so i can try to generate a list of changes between the two
Jul 11 16:33:58 <zeddii> that won't be particularly useful.
Jul 11 16:34:14 <zeddii> there are hundreds (thousands) of -stable changes ported to that kernel.
Jul 11 16:34:41 <zeddii> it would be more useful to just share the build error and config to the linux-yocto list, cc paul gortmaker and go from there.
Jul 11 16:36:37 <tlwoerner> there's only 1244 commits difference between "git show-branch v4.18/standard/base upstream-local/linux-4.18.y"
Jul 11 16:36:57 <zeddii> like I said, hundreds of patches.
Jul 11 16:37:50 <armpit> tlwoerner, please open a bug for thud
Jul 11 16:37:58 <fray> ya.. I'd expect a bisect behavior will be needed. but 1244 commits is actually less then I thought..
Jul 11 16:38:06 <zeddii> dear lord no
Jul 11 16:38:07 <fray> (why do I keep reading 'thud' as 'turd'?)
Jul 11 16:38:12 <zeddii> why is this being over complicated.
Jul 11 16:38:15 <armpit> I am working on getting it ready for another dot release
Jul 11 16:38:18 <zeddii> the kernel has been building, has been booted.
Jul 11 16:38:31 <zeddii> just share the reproducer and spin a patch.
Jul 11 16:38:49 <zeddii> I mean, put it in bugzilla if you want. but the person that would fix it, would never look there.
Jul 11 16:39:25 <zeddii> bisect it if you want, but narrowing down the ported commit isn't that interesting. it just needs a stacked fix. Could be a merge conflict or something. We aren't going to revert a commit, it would be additional changes.
Jul 11 16:39:52 <fray> I was suggesting it to figure out what is broken, if you already know the fix that is different..
Jul 11 16:40:13 * zeddii hasn't seen the build error. It can't be complicated.
Jul 11 16:44:48 <tlwoerner> hmm... stranger yet, v4.18/standard/base builds fine for me, but i had been using v4.18/standard/arm-versatile-926ejs because i am actually targetting an NXP LPC32xx SoC, which has an arm926ej-s at its cor
Jul 11 16:44:51 <tlwoerner> core
Jul 11 16:45:28 <tlwoerner> include/linux/compiler-gcc.h:305:38: error: impossible constraint in ‘asm’
Jul 11 16:46:29 <tlwoerner> is there any reason to use v4.18/standard/arm-versatile-926ejs over v4.18/standard/base?
Jul 11 16:47:11 <zeddii> if you are building qemuarm. yes.
Jul 11 16:47:17 <zeddii> it has patches for the board.
Jul 11 16:49:58 <tlwoerner> crazy! the build error is when compiling lib/vsprintf.o, there are only changes to 2 files between v4.18/standard/arm-versatile-926ejs and v4.18/standard/base, one of those changes is with lib/Makefile, and that change is to tweak the CFLAGS to add -O0
Jul 11 16:50:49 <tlwoerner> according to others who have seen the problem, the problem occurs due to conflicting -O flags: https://github.com/intel/linux-sgx-driver/issues/50
Jul 11 16:51:32 <fray> it's the -O0 change then.. the compiler is constrained when that happens and something there is trying to do more then it can..
Jul 11 16:51:43 <fray> if there is assembly being compiled, it could be the issue -- otherwise it's likely a bug in the compiler itself
Jul 11 16:53:28 <zeddii> or the compiler is finally generating the right code and we no longer need that constraint.
Jul 11 16:53:44 <zeddii> the patch has been around since 2015.
Jul 11 16:54:06 <fray> true
Jul 11 16:54:29 <zeddii> printf was broken due to the optimized code. was pretty nasty at the time to find/fix.
Jul 11 16:55:04 <zeddii> fray. there must be an wind river build of qemuarm against 4.18. it should be showing that as well. odd that it isn't.
Jul 11 16:55:24 <zeddii> and by that, I mean an older release. in a current it would be the v5 qemuarm.
Jul 11 16:55:28 <fray> that's assuming we've updated to the latest kernel.  I don't know if we have (for the thud based product)
Jul 11 16:56:02 <zeddii> aha. right. Paul's -stable versions may not be fully in those builds yet.
Jul 11 17:20:08 <tlwoerner> a little further down the rabbit hole... ;-)
Jul 11 17:20:32 <fray> I did check, we are using the release work, including the -O line.. so I don't know why you are seeing issues...
Jul 11 17:20:48 <tlwoerner> my build failed because i was working outside of OE itself, using an SDK i created with thud and the kernel from thud (4.18)
Jul 11 17:21:08 <tlwoerner> thud is the only release that uses a 4.18 kernel
Jul 11 17:21:20 <fray> (I specifically compared our v4.18/standard/arm-versatile-926ejs vs the linux-yocto version on git.yoctoproject.org they are identical except for a few vhost files..
Jul 11 17:21:41 <fray> ok, so it fails only outside the build.. odd
Jul 11 17:21:42 <tlwoerner> but thud pins the v4.18/standard/arm-versatile-926ejs branch 1121 commits behind HEAD
Jul 11 17:22:28 <tlwoerner> i was using the HEAD checkout of v4.18/standard/arm/versatile-926ejs instead of SRCREV_machine_qemuarm ?= "813d81df5defc4e552b7c3085673437eaba4eea7"
Jul 11 17:24:08 <fray> this is where I don't know which commit is being used.. I just looked at the raw system..
Jul 11 17:24:51 <zeddii> I just spawned a thud build for qemuarm. I'll test the tip of the branches to see if the -stable updates introduced the issue.
Jul 11 17:28:47 <tlwoerner> d'oh!! i'm using my sdk from warrior (gcc-8.3.x) to build the v4.18 kernel from thud; thud uses gcc-8.2.x
Jul 11 17:29:18 <tlwoerner> let me align those things and re-check...
Jul 11 17:34:03 <fray> ok.. I did verify we ARE building the v4.18.40 version in our thud version..
Jul 11 17:34:09 <fray> so ya, it's probably toolchain related at this point
Jul 11 18:42:52 <__angelo> ho cna i find a recipe, name lvm2-udevrules  from oe git ?
Jul 11 18:48:26 <rburton> __angelo: https://layers.openembedded.org/layerindex/recipe/57510/
Jul 11 18:48:42 <rburton> you meant package, lvm2-udevrules is a package built by the lvm2 recipe
Jul 11 18:49:03 <__angelo> oh, thanks
Jul 11 18:54:38 <__angelo> what is the difference from openembedded-core and meta-openembedded ? I mean, why meta-openembedded recipes are kept separated ?
Jul 11 19:11:44 <rburton> __angelo: oe-core is the core recipes that most platforms need and is well maintained, tested on the autobuilder etc.
Jul 11 19:12:02 <rburton> meta-oe is a collection of a lot more other stuff
Jul 11 19:12:30 <rburton> layers are split into functional pieces so you can mix and match what you need without the logistical overhead of testing it all at once
Jul 11 19:43:19 <__angelo> rburton, many thanks !
Jul 11 19:44:31 <__angelo> have still aa question in case someone may know. I set up an image recipe for a rootfs, but would avoid to download/fetch/build/incluse kernel, since it is built in another initramfs recipe
Jul 11 19:44:53 <__angelo> so is there a way to exclude kernel from the rootfs image recipe ?
Jul 11 19:48:49 <LetoThe2nd> __angelo: set linux-dummy as the provider for virtual/kernel. for example in your distro.
Jul 11 19:49:24 <__angelo> uhm, my layer has conf/machine but not distro actually
Jul 11 19:51:21 <rburton> __angelo: you can set it per-machine, thats fine
Jul 11 19:52:33 <__angelo> mmm ok. Well, i can also set a distro, but check-layer script complains my layer cannot be bsp and distro at the same time
Jul 11 19:56:48 <rburton> right. by definition you have a distro set
Jul 11 19:56:50 <rburton> in local.conf
Jul 11 19:56:58 <rburton> be it nodistro or poky or something
Jul 11 19:57:22 <rburton> if its valid for your use case for the kernel to be linux-dummy, set that in the machine config
Jul 11 19:57:47 <rburton> i.e. meta-intel sets the kernel to linux-intel in the machine configs
Jul 11 19:58:24 <__angelo> rburton, ok, will create a different machine, ok
Jul 11 20:10:44 <tlwoerner> the problem i was seeing appears to be related to the configuration. linux-yocto uses voodoo to generate the .configure for qemuarm, which i'm guessing is based on arch/arm/configs/versatile_defconfig; this works. arch/arm/configs/lpc32xx_defconfig doesn't
Jul 11 23:24:13 <tlwoerner> for u-boot we have the UBOOT_MACHINE variable which allows us to "make ${UBOOT_MACHINE}_defconfig", followed by a "make"
Jul 11 23:24:35 <tlwoerner> is there something similar for linux-yocto?
Jul 12 00:38:58 <khem> RP: I am seeing packaging errors of this kind https://errors.yoctoproject.org/Errors/Details/251372/
Jul 12 00:39:28 <khem> this is with opkg backend but seems more PR server related any recent changes that could cause this ?
Jul 12 00:39:48 <khem> I am seeing it across the board but failures are random
Jul 12 00:40:02 <khem> happens on ubuntu 18.04 machines primarily
Jul 12 00:41:00 <khem> this is full build e.g. https://errors.yoctoproject.org/Errors/Build/83864/ and you can see bunch of do_package errors
Jul 12 01:46:15 <armpit> khem, I have seen that from time to time on thud
Jul 12 01:50:33 <khem> hmm thats worrying
**** ENDING LOGGING AT Fri Jul 12 02:59:57 2019