**** BEGIN LOGGING AT Thu Aug 09 03:00:00 2018
Aug 09 06:59:11 <khem> armpit yes
Aug 09 07:03:58 <frsc> I have a Yocto problem and no idea how to debug this. Maybe someone has a hint?
Aug 09 07:04:42 <frsc> I have a recipe with PACKAGE_ARCH = "${MACHINE_ARCH}, but when I switch between different MACHINES no rebuild happens.
Aug 09 07:12:03 <bluelightning> frsc: first thing to verify would be to bitbake -e recipename | less to see whether that value is being overridden
Aug 09 07:12:45 <frsc> bluelightning: I can see that PACKAGE_ARCH changes correctly when I change the MACHINE
Aug 09 07:13:39 <bluelightning> when you say no rebuild happens, how are you determining that?
Aug 09 07:14:26 <xtron> how to use [bb.utils.contains] in anonymous python function?
Aug 09 07:14:26 <frsc> bluelightning: nothing happens at all, I get "Attempted 472 tasks of which 472 didn't need to be rerun and all succeeded."
Aug 09 07:15:18 <bluelightning> frsc: if you've built it before with that MACHINE set (which surely you must have) then that would be expected ...
Aug 09 07:16:27 <frsc> bluelightning: No, because actually it's a u-boot recipe and I expect at least that the correct bootloader image for this MACHINE is deployed
Aug 09 07:16:55 <frsc> No matter if it was already built
Aug 09 07:18:50 <frsc> So what I expect is that it uses sstate, but rerun do_deploy. At least that's how I think it should work.
Aug 09 07:19:39 <bluelightning> the first time, yes, I would expect the same
Aug 09 07:20:00 <frsc> Or maybe it doesn't even need sstate, but I need to have the correct binary for the selected MACHINE in my deploy dir
Aug 09 07:20:10 <bluelightning> right
Aug 09 07:20:43 <bluelightning> I can't honestly say what might be happening in your tree without further information, but I can confirm it should work as you expect
Aug 09 07:26:29 <frsc> bluelightning: Ok, do you have any idea how to debug this? What places do I need to look at, that might provide some hints?
Aug 09 07:28:20 <frsc> Because the current situation is, that I switch MACHINE and build an image and the image contains a wrong u-boot binary and it doesn't boot and that's really bad.
Aug 09 07:28:28 <bluelightning> frsc: the thing is, if PACKAGE_ARCH is changing then WORKDIR must be changing, and that would have to force at minimum a restore from sstate
Aug 09 07:29:12 <bluelightning> frsc: first thing to do would be to bitbake -c clean for both values of MACHINE
Aug 09 07:29:29 <bluelightning> then run the experiment again
Aug 09 07:31:28 <bluelightning> how is the recipe written such that MACHINE influences how it is built?
Aug 09 07:34:26 <frsc> bluelightning: There's a bbappend that includes some files in SRC_URI for all machines, but there are subdirs for the different machines that hold different versions of those files for each MACHINE
Aug 09 07:36:10 <bluelightning> RP: this is something you would expect to work without anything more explicit in the recipe, right?
Aug 09 07:36:41 <frsc> bluelightning: I cleaned and retried and it seems to work on the first run with each MACHINE, but once both versions exist in tmp no re-deploy happens and I am stuck with the same binary in the deploy dir
Aug 09 07:37:05 <bluelightning> ah - right... so how exactly is the deploy being done
Aug 09 07:37:07 <bluelightning> ?
Aug 09 07:37:44 <bluelightning> (for this to work properly the deploy must *not* write directly to the output directory, it needs to be going through sstate)
Aug 09 07:39:06 <RP> bluelightning: it should work, yes
Aug 09 07:39:15 <bluelightning> OE-Core's u-boot.inc does seem to be doing the deployment the correct way
Aug 09 07:39:47 <frsc> bluelightning: I'm using the core's u-boot.inc in my recipe
Aug 09 07:40:51 <frsc> It's basically the core u-boot.inc with a few additional variables and files
Aug 09 07:43:34 <bluelightning> hmm... puzzling
Aug 09 07:44:36 <bluelightning> frsc: in your testing right now are you still building the image or just u-boot ?
Aug 09 07:44:48 <frsc> bluelightning: just u-boot
Aug 09 07:45:07 <bluelightning> ok, that simplifies things a little
Aug 09 07:47:15 <bluelightning> so there are two possible avenues: 1) bitbake -DDD (which will print a whole bunch of uninteresting things but should somewhere make reference to u-boot's deploy task)
Aug 09 07:47:40 <bluelightning> and 2) the stamps for the two different machines, which you should be able to compare with bitbake-diffsigs
Aug 09 07:51:23 <frsc> bluelightning: Ok in the log I get: "We can skip tasks [...]/u-boot/u-boot-exceet_2017.03.bb:do_deploy"
Aug 09 07:51:41 <frsc> Whatever leads to this
Aug 09 08:07:22 <frsc> bluelightning: This is what I get when I compare the stamps for the deploy task of both machines: https://paste.ee/p/Y0SW9
Aug 09 08:08:57 <bluelightning> hmm, so it differs in the way you would expect it to...
Aug 09 08:16:33 <frsc> bluelightning: So what could lead to the task being skipped?
Aug 09 08:16:55 <frsc> This is what I see in the log:
Aug 09 08:17:01 <frsc> [...]/u-boot-exceet/2017.03-r0.do_deploy_setscene.b19c8a38f546274270c1fb5a4603e03c.imxceet-ul-2-s not available
Aug 09 08:17:05 <frsc> DEBUG: Normal stamp current for task [...]/u-boot/u-boot-exceet_2017.03.bb:do_deploy
Aug 09 08:17:10 <frsc> DEBUG: Found task [...]/u-boot/u-boot-exceet_2017.03.bb:do_deploy which could be accelerated
Aug 09 08:19:15 <frsc> And after that the task gets listed in the "skip list"
Aug 09 08:19:20 <RP> frsc: are these things deploying to the same filename?
Aug 09 08:20:12 <frsc> RP: yes, and additional some machine-specific symlinks
Aug 09 08:20:55 <frsc> like u-boot.imx, u-boot-imxceet-ul-2-s.imx, etc.
Aug 09 08:46:14 <luneff> hey guys! I have wrong machine-specific SRC_URI_append which I'd like to override. how do I do so with such a beast? :-)
Aug 09 08:46:59 <luneff> I've filed an issue report to original layer, but it could take some time before the fix gets in. Given, I understood it's an issue correctly. https://github.com/SolidRun/meta-solidrun-arm-imx6/issues/6
Aug 09 08:49:18 <RP> frsc: I'm going to guess that this is the problem, the underlying files are probably all there but the main link which isn't machine specific is going to be the last one the task deployed
Aug 09 08:50:02 <RP> frsc: the file names really need to be machine specific since the deploy task will only run once, then the system will think its current and not run it again
Aug 09 08:52:36 <bluelightning> luneff: it's not ideal but you should be able to do SRC_URI_remove = "0015-Add-eglfs_viv_wl-to-IMX-GPU.patch" and then SRC_URI_append = "0015-Add-eglfs_viv-to-IMX-GPU.patch"
Aug 09 08:52:53 <bluelightning> luneff: you could make those conditional as well if you need to
Aug 09 08:53:15 <luneff> yeah, thinking about the same, thank you :-)
Aug 09 08:53:47 <bluelightning> heh, I missed the leading space in the append, but you probably won't do that :)
Aug 09 08:55:06 <frsc> RP: I guess you're right. Actually we use a common UBOOT_CONFIG for all machines and that leads to the filename of the binary being the same.
Aug 09 08:55:49 <frsc> So we probably have to change our setup as this does not seem to be an intended use case.
Aug 09 08:55:55 <RP> frsc: you need to use different filenames for the two different machines, its not designed to work otherwise
Aug 09 08:56:24 <frsc> RP: Ok
Aug 09 08:58:37 <RP> frsc: I am surprised the system didn't warn about the filename overlap
Aug 09 08:59:06 <RP> ah, sstate.bbclass:SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/
Aug 09 08:59:31 <RP> frsc: I'd guess if you remove that from the whitelist you would see warnings
Aug 09 09:05:44 <frsc> RP: Indeed. If I remove the dir from the whitelist and rebuild I even get errors.
Aug 09 09:10:46 <RP> frsc: I think we shouldn't need that in the main whitelist any more, if we have some idle time on the autobuilder I might see if we do still overlap files anywhere
Aug 09 09:12:00 <frsc> RP: Ok, great
Aug 09 09:24:45 <yocti> New news from stackoverflow: Yocto Linux on a virtual machine <https://stackoverflow.com/questions/50815948/yocto-linux-on-a-virtual-machine>
Aug 09 09:38:55 <bluelightning> RP: in the ab helper, does layer-config need both targetbuilddir and targetdir? they appear to be the same thing and neither get changed
Aug 09 10:34:54 <frsc> bluelightning: RP: I changed my setup to use different UBOOT_CONFIG for each MACHINE instead of the common one and now everything seems fine. The common link like "u-boot.imx" is not updatet, but I guess that's normal and it's not used to include the binary in the image.
Aug 09 10:35:23 <frsc> bluelightning: RP: So thanks a lot for helping!
Aug 09 10:49:19 <bluelightning> frsc: no problem, glad we were able to help figure it out
Aug 09 10:49:44 <bluelightning> seems like you uncovered a bug in any case (or at least undesirable behaviour)
Aug 09 10:52:56 <frsc> bluelightning: Yes I guess my setup was uncommon and it seems it is not really supported and therefore leads to some undesired results
Aug 09 10:53:51 <bluelightning> I tend to think that if it's possible to trigger bad behaviour it should be prevented somehow, so I do think it could be improved
Aug 09 11:04:22 <frsc> bluelightning: Right, I think the root cause is more like a restriction of the u-boot recipe and config classes that caused my setup to fail
Aug 09 11:05:21 <frsc> bluelightning: So having a warning for that case would be nice and as we have seen it would actually trigger an error if the deploy dir wouldn't be whitelisted
Aug 09 11:25:06 <yocti> New news from stackoverflow: How to exclude packages when populate_sdk in Yocto <https://stackoverflow.com/questions/51765275/how-to-exclude-packages-when-populate-sdk-in-yocto>
Aug 09 11:28:54 <RP> bluelightning: the fix is fewer things in the whitelist
Aug 09 11:30:09 <RP> bluelightning: that looks like some kind of abstraction which never worked out, they are set set to the same thing?
Aug 09 11:35:34 <luneff> is there something to auto-edit a google repo manifest file? like "convert all branch references to exact commit revisions'?
Aug 09 11:41:24 <JoeR> Hey all. This is perhaps a wish rather than a realistic hope but is it possible to find the list of CVEs open against any particular image recipe?..
Aug 09 11:42:52 <JoeR> I mean, in any kind of automated manner :-)
Aug 09 11:44:33 <bluelightning> RP: ok... I'm working on the argparse stuff so I guess I'll just replace the two with one
Aug 09 12:05:47 <RP> bluelightning: I think we need to get rid of OETestDepends, its particularly urgent for sdk/esdk/selftest, images don't parallelise so those are less of an issue
Aug 09 12:06:05 <RP> bluelightning: just looking at the esdk devtool tests and wondering if they really need that dependency?
Aug 09 12:06:20 <RP> (the test_devtool_location one)
Aug 09 12:08:02 <bluelightning> RP: I'm pretty sure we can do without that dependency yes
Aug 09 12:12:51 <RP> bluelightning: we could make it a function and call it but I'm not sure that is worth it?
Aug 09 12:13:36 <bluelightning> I believe the only purpose is to save time in case that test fails, pretty much like all of the other dependencies we've put in
Aug 09 12:14:02 <RP> bluelightning: the other dependencies were less about time and more about better error messages
Aug 09 12:14:39 <RP> bluelightning: particularly "your network is dead" which otherwise can be hard to figure out from a series of different timeouts
Aug 09 12:15:42 <bluelightning> right
Aug 09 12:55:24 <yocti> New news from stackoverflow: Openembedded: How to add python-robotframework to Yocto <https://stackoverflow.com/questions/51767077/openembedded-how-to-add-python-robotframework-to-yocto>
Aug 09 13:47:06 <tlwoerner> has anyone else noticed builds failing due to pigz crashing?
Aug 09 13:49:59 <tlwoerner> i've been seeing these failures since we started using pigz, but maybe only 1 or so per week
Aug 09 13:51:36 <tlwoerner> so far, 3/8 of last night's builds failed because of pigz crashing
Aug 09 13:51:52 <tlwoerner> pigz: abort: internal threads error
Aug 09 13:52:06 <tlwoerner> pigz: abort: internal threads error
Aug 09 13:52:20 <tlwoerner> pigz: try.c:42: try_throw_: Assertion `try_stack_ != NULL && "try: naked throw"' failed.
Aug 09 13:54:38 <tlwoerner> i see it's the host's pigz that is used, my host is openSuSE 15.0, pigz --version 2.3.3
Aug 09 14:55:47 <yocti> New news from stackoverflow: How do I clone a custom Intel Edison? <https://stackoverflow.com/questions/32445283/how-do-i-clone-a-custom-intel-edison>
Aug 09 14:56:13 <mihai-> http://downloads.yoctoproject.org/mirror/sources/ looks nice :)
Aug 09 14:57:44 <mihai-> halstead, ^
Aug 09 14:57:56 <mihai-> I'm not sure who should look at that
Aug 09 15:14:17 <moto-timo> which mailing list is used for submitting yocto-autobuilder related patches?
Aug 09 15:17:16 <bluelightning> moto-timo: the main yocto list
Aug 09 15:18:12 <moto-timo> bluelightning: thank you
Aug 09 16:38:10 <kanavin__> RP: I'd like to know where is the source and configuration for the 'new' autobuilder? the last commits in yocto-autobuilder are several months old, yet there's been activity lately, from the status emails
Aug 09 16:38:31 <kanavin__> RP: basically pelux is struggling with jenkins and I suggested, why not use what upstream is using :D
Aug 09 16:39:43 <RP> kanavin__: yocto-autobuilder2 and yocto-autobuilder-helper are the two codebases
Aug 09 16:40:29 <kanavin__> ah, '2' :)
Aug 09 16:41:08 <kanavin__> cheers
Aug 09 16:49:44 <joaocfernandes> hi, I have generated a Build system derived toolchain for arm and I am able to run and debug it on the Qemu through the eclipse launcher + plugin using the autotools project , still if I create a cmake project I have some issues with the toolchain
Aug 09 16:50:46 <joaocfernandes> it looks like is looking for /lib/ld-linux.so.3 on my local machine instead of using what is contained within the toolchain
Aug 09 16:53:23 <joaocfernandes> some logs https://pastebin.com/MGP6KHSp
Aug 09 17:12:55 <joaocfernandes> $CC -print-sysroot
Aug 09 17:13:24 <joaocfernandes>  /home/user/yocto/poky/build/tmp/work/armv5e-poky-linux-gnueabi/meta-ide-support/1.0-r3/recipe-sysroot
Aug 09 17:14:04 <joaocfernandes> can't really understand what is happening and why only with cmake
Aug 09 18:54:11 <JPEW> \
Aug 09 18:54:55 <JPEW> Hmm, this isn't vim... my leader key doens't work here....
Aug 09 20:30:15 <RP> kanavin__: The "2" codebase since there wasn't much in common with the older buildbot!
Aug 09 20:32:26 <pabaddy1995> is anyone in here familiar with u-boot-fw-utils?
Aug 09 21:05:49 <aehs29> RP: are we planning on switching to AB '2' entirely at some point?
Aug 09 21:08:59 <RP> aehs29: yes, soon
Aug 09 21:34:42 <pabaddy1995> I know I keep asking this, but I'm really confused why my u-boot-fw-utils is using the wrong header file to mirror env variables.  When the .config file appears correct.
Aug 09 22:11:59 <JPEW> Alright, version 2 of hash equivalence.... bombs away!
Aug 09 22:14:26 <kergoth> damn, that reminds me, i need to look at that at some point
Aug 09 22:15:51 <JPEW> kergoth: I think I was trying to use persist_data in a way it wasn't originally intended.... but it was kinda fun fixing it :)
Aug 09 22:25:43 <armpit> JPEW, if you labeled it hashish, you might get more reviewers
Aug 09 22:28:12 <JPEW> armpit: hmm.... but maybe not too many full reviews.... to distracting
Aug 09 22:43:35 <RP> JPEW: persist data was not my best moment...
**** ENDING LOGGING AT Fri Aug 10 03:00:01 2018