**** BEGIN LOGGING AT Tue Jan 23 03:00:03 2018
Jan 23 03:20:33 <yocti> New news from stackoverflow: Make yocto skip a recipe instead of stopping <https://stackoverflow.com/questions/48224871/make-yocto-skip-a-recipe-instead-of-stopping>
Jan 23 07:03:21 <learningc> Regarding the kernel, I see build-test/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/linux-imx and build-test/tmp/work-shared/imx6ull14x14evk/kernel-source.
Jan 23 07:03:55 <learningc> Why are there 2 kernel directories?
Jan 23 08:51:11 <learningc> I edited the defconfig file, but after I bitbake -c compile virtual/kernel, I cannot seee my changes applies, why?
Jan 23 09:09:06 <mckoan> learningc: it has been overwritten, use bitbake -c deploy virtual/kernel
Jan 23 09:10:06 <mckoan> learningc: https://www.yoctoproject.org/sites/default/files/kernel-lab-1.4.pdf
Jan 23 09:11:28 <learningc> ok thanks
Jan 23 09:42:17 <sveinse> I wonder if the bitbake parser could be included in a custom script for parsing other files, such as CM config files
Jan 23 10:54:10 <zachr_v> Hello. I'm unable to fetch linux-yocto-4.12.18+gitAUTOINC+b66a4f9730_558fe84d69-r0, it fails on timeout after reaching 100%. Can anybody help please?
Jan 23 11:22:04 <yocti> New news from stackoverflow: How to install module 'ws' with 'Node.js'? <https://stackoverflow.com/questions/48400070/how-to-install-module-ws-with-node-js> || I can't print the vprintf log by journalctl <https://stackoverflow.com/questions/48400060/i-cant-print-the-vprintf-log-by-journalctl>
Jan 23 11:51:48 <lukma> rburton: Thanks for tip
Jan 23 11:52:12 <lukma> However, I do have a question:
Jan 23 11:52:12 <lukma> FILESEXTRAPATHS_prepend_foo := "${THISDIR}/files:"
Jan 23 11:52:12 <lukma> FILESEXTRAPATHS_prepend_bar := "${THISDIR}/files.bar:"
Jan 23 11:52:40 <lukma> I do have foo1, which uses the same files as foo, then is it correct to do:
Jan 23 11:52:45 <lukma> FILESEXTRAPATHS_prepend_foo1 := "${THISDIR}/files:"
Jan 23 11:52:48 <rburton> are those for machine-specific files?
Jan 23 11:53:14 <lukma> rburton: Those are files with configuration - like rcS , rcK
Jan 23 11:53:35 <lukma> which are executed at system bootup (and yes in that sense they are specific to machine)
Jan 23 11:53:51 <rburton> i mean is all the prepends because foo and bar are machine names
Jan 23 11:54:16 <lukma> Yes, I now do have MACHINE=foo , MACHINE=bar
Jan 23 11:54:22 <lukma> and I want to add MACHINE=foo1
Jan 23 11:54:33 <rburton> bitbake supports per-machine files out of the box, have a look at the formfactor recipe
Jan 23 11:54:52 <rburton> (with fallbacks)
Jan 23 11:55:02 <lukma> rburton: Because I also could get:
Jan 23 11:55:13 <lukma>  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
Jan 23 11:55:20 <lukma> and then files/foo/
Jan 23 11:55:23 <lukma> files/bar/
Jan 23 11:55:26 <lukma> files/foo1
Jan 23 11:55:41 <lukma> but then how to re-use files from foo ?
Jan 23 11:55:52 <lukma> without copying them to files/foo1/ ?
Jan 23 11:56:01 <lukma> (Or have I misunderstood something)?
Jan 23 11:56:38 <rburton> well, symlinks would be one solution.  :)  or extend the override list to give you a foo-and-foo1 override
Jan 23 11:56:46 <rburton> as cal said yesterday, qemuall is an example here
Jan 23 11:57:50 <lukma> rburton: Are symlinks recommended ?
Jan 23 11:58:13 <rburton> if overrides won't work then thats definitely a solution
Jan 23 11:58:44 <eduardas_m> hello, can anyone tell if bitbake supports GYP projects like PDFium? https://gyp.gsrc.io/
Jan 23 11:59:20 <rburton> eduardas_m: http://layers.openembedded.org/layerindex/recipe/61379/
Jan 23 11:59:41 <rburton> *bitbake* doesn't care
Jan 23 12:00:08 <rburton> oe-core doesn't, yet.  there's a recipe for gyp so presumable that layer would be a good start
Jan 23 12:00:08 <lukma> rburton: In quemu I do have /machine/include/<arch>/*.inc
Jan 23 12:02:05 <sveinse> kergoth: ls --sort=time --time=access -l does not work recursively on the sstate dir. And it does not do a 'du' kind
Jan 23 12:02:11 <eduardas_m> rburton: thank you, I am currently trying and failing to write a recipe for this new Qt PDF rendering component that uses PDFium: http://blog.qt.io/blog/2017/01/30/new-qtpdf-qtlabs-module/
Jan 23 12:02:31 <rburton> eduardas_m: the layer index has a wonderful search button and lots of layers are listed
Jan 23 12:05:07 <eduardas_m> rburton: could you tell me what the standard solution for rendering PDF documents on embedded Linux is without getting into licencing problems for commercial usecases? It seems Poppler is not usable because of GPLv2 in my case
Jan 23 12:06:44 <lukma> rburton: Got it -> http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-MACHINEOVERRIDES Thanks for help
Jan 23 12:06:54 <lukma> rburton: Neat feature
Jan 23 12:18:06 <zachr_v> As I have written above, fetch of linux-yocto-4.12 failed again. Looking into log.do_fetch it seems like the ...git.tar.gz downloaded succesfully, the command causing a failure is this: LANG=C git -c core.fsyncobjectfiles=0 fetch -f --prune --progress git://git.yoctoproject.org/linux-yocto-4.12.git refs/*:refs/* . After this line follows this: fatal: unable to connect to git.yoctoproject.org: git.yoctoproject.org[0: 140.211.169.56]: e
Jan 23 12:20:20 <zachr_v> Could anyone help please? Can I set a mirror in case some source is unavailable?
Jan 23 12:21:07 <rburton> zachr_v: looks like networking/proxy problems at your end
Jan 23 12:23:03 <zachr_v> rburton: Thanks. I try to look on that.
Jan 23 12:24:18 <rburton> eduardas_m: considering i work exclusively in open source, no.
Jan 23 12:24:34 <rburton> no doubt there are many commercial PDF renderers
Jan 23 12:24:48 <rburton> including the ancestor of poppler, i believe
Jan 23 12:34:48 <john1987> rburton: it seems that pseudo has something to do with mkfs.ext3 ... made mkfs.ext3 with PSEUDO_UNLOAD=1 in front... and solved my problem
Jan 23 12:41:19 <rburton> john1987: you're using ancient release right?
Jan 23 12:42:10 <rburton> you probably want to upgrade pseudo then, there's a lot of xattr fixes in 2016 you'll be missing
Jan 23 12:46:48 <john1987> rburton : yes is 1.7.3  .I tried updating pseudo to a later version but i faced many problems mostly involving post install scripts
Jan 23 12:59:54 <rburton> well look at the pseudo commit log and you'll see a load of xattr commits, either backport those or grab a commit after those
Jan 23 13:23:36 <lukma> rburton: If I may ask - I've followed the qemu guidelines
Jan 23 13:24:03 <lukma> and without MACHINEOVERRIDES I do have all the foo packages included.....
Jan 23 13:24:07 <lukma> how is it possibe ?
Jan 23 13:25:10 <rburton> lukma: without seeing what you've done i have no idea
Jan 23 13:35:46 <lukma> rburton: MACHINE ?= "foo" in my <build>/conf/local.conf file does the trick
Jan 23 13:46:00 <t0mmy> Hi, Is there a clean solution to force fetch sources of recipes using AUTOREV, in order to always compile the latest version? Currently we are doing an appendix of SRCPV in PV, to do that. Is there a better solution?
Jan 23 13:57:00 <rburton> t0mmy:SRCREV=${AUTOREV} does that surely
Jan 23 14:02:30 <xthunderheartx> What is the best way to add a new package to your host dev machine without redeploying the entire SDK? Just copy the libs and headers to your host sysroot manually?
Jan 23 14:02:40 <xthunderheartx> Seems like there would be a better way.
Jan 23 14:19:59 <xthunderheartx> Maybe devtool ...?
Jan 23 14:34:25 <lukma> Ixthunderheartx:  do use devtool - it works . And has one nice features -> sourced stay even after finishing work
Jan 23 14:36:53 <kanavin> lukma: actually I think that's a misfeature :)
Jan 23 14:37:06 <kanavin> I would rather have it clean everything up
Jan 23 14:37:54 <cornel> hello
Jan 23 14:38:02 <lukma> kanavin: Hmm. .... what I can say....... my understanding of OE is on the level when I try not to hurt myself :P
Jan 23 14:38:57 <cornel> is there a known issue with boost downloads? it failed two days last week and now it fails again, this time from http://downloads.yoctoproject.org/mirror/sources/boost_1_65_0.tar.bz2
Jan 23 14:39:17 <cornel> inbetween, it worked once, yesterday
Jan 23 14:40:07 <kanavin> cornel: recipe says SRC_URI = "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2"
Jan 23 14:40:25 <cornel> kanavin, right, and somehow ends in the most unexpected places
Jan 23 14:40:36 <kanavin> sourceforge has been a pain point since 1995 though
Jan 23 14:40:44 <kanavin> the sooner it dies the better
Jan 23 14:40:49 <cornel> :)
Jan 23 14:41:53 <kanavin> cornel: I guess if you go to boost.org, and try to follow download links, you might get somewhere :)
Jan 23 14:42:09 <kanavin> patches welcome etc
Jan 23 14:42:21 <cornel> the most annoying thing is that the existing downloads/ directory is not used, even if the file is there
Jan 23 14:47:17 <cornel> kanavin, i'll try the boost.org way and report back but only tomorow /
Jan 23 14:47:46 <lukma> In the -e output I do have:
Jan 23 14:47:46 <lukma> MACHINEOVERRIDES="armv4:foo:bar"
Jan 23 14:48:01 <lukma> I suppose that bar is used only when there is no override for foo ?
Jan 23 14:48:14 <xthunderheartx> lukma: Thx dood.
Jan 23 14:48:49 <lukma> (and how/where can I check this) ?
Jan 23 14:50:01 <xthunderheartx> Also anybody ever been to Embedded Linux Conference? Worth the money? Early deadline is the 28th ...
Jan 23 14:50:52 <lukma> xthunderheartx: Europe (ELCE) or ELC ?
Jan 23 14:52:08 <xthunderheartx> LOL! No ... my rentz wouldn't spring for that.  Portland maybe.
Jan 23 14:52:50 <xthunderheartx> The trip would likely blow my training budget for the year.
Jan 23 14:53:16 <lukma> But are you from US or Europe?
Jan 23 14:53:23 <xthunderheartx> US.
Jan 23 14:55:29 <rburton> xthunderheartx: i've enjoyed it in the past, but work paid for it
Jan 23 14:56:40 <kanavin> I've been to ELC-E once about 10 years ago, and did enjoy it
Jan 23 14:57:18 <lukma> I was on ELCE last year .... it was a nice booth for yocto project
Jan 23 14:57:23 <lukma> with widget spinner....
Jan 23 14:57:43 <kanavin> I guess if I would have to pick once conference in europe, I'd be torn between fosdem and elc-e
Jan 23 14:57:47 <lukma> and it was a possibility to ask directly gentlemen who develop it :)
Jan 23 14:57:58 <kanavin> 'fortunately' at the moment, there's no need to make such a choice
Jan 23 14:58:15 <lukma> and most of all - they gave the audience widget spinners :)
Jan 23 14:58:16 <xthunderheartx> Yeah when I say rentz I really mean the suits at work.
Jan 23 14:59:03 <xthunderheartx> They do after all pay the rent, indirectly at least.
Jan 23 14:59:15 <xthunderheartx> Or the mortgage anyway ...
Jan 23 15:01:10 <xthunderheartx> The rest of my team spent their budget on "Linux for Dummies 101", and as I could spell "Linux", I saved mine for something else :)
Jan 23 15:22:56 <yocti> New news from stackoverflow: yocto bitbake: running bitbake python task with python command line options <https://stackoverflow.com/questions/48404908/yocto-bitbake-running-bitbake-python-task-with-python-command-line-options>
Jan 23 15:38:34 <xtron> anyone here tried WSL (windows subsystem) to build yocto based Linux image?
Jan 23 15:40:00 <rburton> xtron: someone on the list did recently, worked surprisingly well
Jan 23 15:40:20 <rburton> [yocto] Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows) on the yocto@yoctoproject list
Jan 23 15:41:37 <rburton> windows has a maximum hard link count of 1023 which breaks glibc-locale as some files end up with 1200 hard links during the build
Jan 23 15:41:40 <rburton> but there's a workaround
Jan 23 15:42:01 <xtron> rburton: I tried too, but It didn't work, if someone have done, I can tried it again
Jan 23 15:44:41 <xtron> rburton: on WSL build system is unable to connect to bitbake server, are you talking about this?
Jan 23 15:52:51 <t0mmy> rburton: thx
Jan 23 16:08:27 <RP> Why does "bitbake-layers add-layer X" parse the metadata? :/
Jan 23 16:11:06 <fray> the only metadata that should be parsed is the layer.conf and 'such', to determine dependencies
Jan 23 16:11:58 <RP> fray: right, its parsing the recipes :/
Jan 23 16:12:37 <fray> must be an artifact of the tinfoil stuff..
Jan 23 16:21:15 <lukma> If I may ask:
Jan 23 16:21:27 <lukma> IMAGE_INSTALL = "\
Jan 23 16:21:27 <lukma>                 packagegroup-core-boot \
Jan 23 16:21:27 <lukma>                 packagegroup-base \
Jan 23 16:21:27 <lukma>                 packagegroup-apps \
Jan 23 16:21:27 <lukma> "
Jan 23 16:21:45 <lukma> IMAGE_INSTALL_foo += "packagegroup-foo"
Jan 23 16:22:09 <lukma> when I build with MACHINE=foo I only see IMAGE_INSTALL with packagegroup-foo
Jan 23 16:22:34 <lukma> I do understand that the overriden IMAGE_INSTALL has higher priority
Jan 23 16:23:01 <lukma> but how to make the packagegroup-foo being only "appended" for foo machine?
Jan 23 16:23:08 <lukma> (Or do I miss something) ?
Jan 23 16:23:09 <yocti> New news from stackoverflow: Glide for Go lang <https://stackoverflow.com/questions/48406224/glide-for-go-lang>
Jan 23 16:25:30 <fray> lukma, IMAGE_INSTALL_foo += '..' says add '..' to IMAGE_INSTALL_foo..
Jan 23 16:25:33 <fray> it's likely wrong..
Jan 23 16:25:43 <fray> what you want is 'IMAGE_INSTALL_append_foo = " ..." (note leading space)
Jan 23 16:25:49 <fray> this says APPEND only if 'foo' override is set
Jan 23 16:27:58 <lukma> fray: Is this connected with the += (at very beginning) and append (after +=/= took place) difference?
Jan 23 16:28:42 <fray> FOO = "foo"
Jan 23 16:28:45 <fray> FOO += "bar"
Jan 23 16:28:54 <fray> will reuslt in 'FOO" being equal to 'foo bar'
Jan 23 16:28:59 <fray> FOO = "foo"
Jan 23 16:29:04 <fray> FOO_append = "bar"
Jan 23 16:29:13 <fray> will result in FOO being equal to 'foobar'  (note, no space..
Jan 23 16:29:18 <fray> this is 'similar' to:
Jan 23 16:29:20 <fray> FOO = "foo"
Jan 23 16:29:23 <fray> FOO .= "bar"
Jan 23 16:29:34 <fray> the difference between '.=' and 'append' is when the action happens..
Jan 23 16:29:36 <fray> such as:
Jan 23 16:29:39 <fray> FOO = "foo"
Jan 23 16:29:45 <fray> FOO_append = 'bar'
Jan 23 16:29:56 <fray> FOO += "something"
Jan 23 16:30:02 <fray> will result in 'foo somethingbar'
Jan 23 16:30:11 <fray> += happens right away, append is 'delayed' (late binding)
Jan 23 16:30:26 <fray> now if you add the _<override> syntax.. override is the 'most late binding'...
Jan 23 16:30:34 <fray> FOO = "foo"
Jan 23 16:30:38 <fray> FOO_bar = "bar"
Jan 23 16:30:49 <fray> until they are evaluated, that no change happens..
Jan 23 16:30:58 <fray> if 'bar' is in the override.. and they are evaluated.. then
Jan 23 16:31:00 <fray> FOO = "bar"
Jan 23 16:31:11 <fray> until the evalation at the end, the previous rules take effect..
Jan 23 16:31:24 <fray> (it's somewhat complicated)  but I believe there are a lot more examples in the bitbake guide
Jan 23 16:32:20 <lukma> fray: Yes, it is a bit compilicated
Jan 23 16:32:57 <lukma> how do you define 'late binding' -> which point in time it is? Is it after ${} is resolved ?
Jan 23 16:33:22 <fray> early binding.. happens before 'regular evaluation'.. afaik there is no such thing in bitbake..
Jan 23 16:33:34 <fray> regular evaluation... happens as the items are being parsed (effectively)
Jan 23 16:33:50 <fray> late binding.. (multiple stages of this.. but) happens just before the user of the variable evaluates it
Jan 23 16:34:07 <fray> FOO = "${BAR}"
Jan 23 16:34:38 <fray> the value of FOO is the literal "${BAR}".. but when a user finally loads this, it is then expanded.. that is when the regular evaluation and late binding happen for 'FOO'
Jan 23 16:34:58 <fray> but if you have: FOO := "${BAR}"   ':=' says evaluate BAR -now-..
Jan 23 16:35:14 <fray> again, there should be explanation and examples in the bitbake buide
Jan 23 16:35:42 <fray> bitbake -guide-
Jan 23 16:36:37 <lukma> fray: Thanks for explanation......
Jan 23 17:57:21 <xpete> I'am upgrading yocto from version 2.3.1 to 2.4.1. I have a recipe that was working with version 2.3.1 but with 2.4.1 the linker can't find a file that is in the folder where is expected to be... how can i fix this?
Jan 23 19:10:54 <jman> Hello, do_kernel_configme fails everytime I build with archiver on. This is the error I get:  [ERROR]: no configuration queue found in outdir (.kernel-meta)
Jan 23 19:11:16 <jman> My local.conf has the these additional settings "224 INHERIT += "archiver" 225 ARCHIVER_MODE[src] = "original" 226 ARCHIVER_MODE[diff] = "1" 227 ARCHIVER_MODE[recipe] = "1" 228 COPY_LIC_MANIFEST = "1" 229 COPY_LIC_DIRS = "1" 230 LICENSE_CREATE_PACKAGE = "1""
Jan 23 19:12:07 <jman> If I run the run.do_kernel_config manually from work dir, it runs without problems. But, when I run it as part of the image with the archiver specific lines in local.conf. It fails
Jan 23 19:12:20 <jman> Any suggestions to debug this?
Jan 23 21:04:17 <spierepf> If I have a buildroot defconfig entry like 'BR2_LINUX_KERNEL_UIMAGE_LOADADDR="c2008000"' and I wanted to achieve the same goal in yocto, what file in my meta-xxx/recipes-kernel/linux should I be adding it to?
Jan 23 21:04:48 <kergoth> hrmph, opkg_prepare_url_for_install: Couldn't find anything to satisfy 'target-sdk-provides-dummy'
Jan 23 21:10:28 <lukma> One question regarding CORE_IMAGE_BASE_INSTALL = ""
Jan 23 21:10:57 <lukma> Which is set in poky/meta/classes/core-image.bbclass:70
Jan 23 21:11:24 <lukma> When I do _append with my packages (not +=/=)
Jan 23 21:11:43 <lukma> it is always set and include packagegroup-core-boot     packagegroup-base-extended
Jan 23 21:12:08 <lukma> The packagegroup-core-boot I do add by hand
Jan 23 21:12:21 <lukma> however, I don't want to add packagegroup-base-extended
Jan 23 21:13:06 <lukma> Also it seems like the place where I do put: inherit core-image in my image-arch-foo.bb matters in respect of CORE_IMAGE_BASE_INSTALL setting
Jan 23 21:29:10 <lukma> Is it safe to remove inherit core-image from my image-arch-foo.bb recipe?
Jan 23 21:29:30 <lukma> WIthout it works as expected
Jan 23 22:24:24 <yocti> New news from stackoverflow: Glide for Go lang [on hold] <https://stackoverflow.com/questions/48406224/glide-for-go-lang>
Jan 23 23:03:39 <aehs29> lukma: you can simply inherit image and do things manually, its up to you
Jan 23 23:45:53 <ikkysleepy> is it possible to create and image so you can use noobs to install your image? Has anyone done this?
Jan 23 23:54:29 <ozzychard> what's the suggested way of adding files to a package before compiling?
Jan 23 23:55:13 <ozzychard> Keeping them as patches is not ideal because doing code reviews is almost impossible
Jan 24 00:10:58 <aehs29> ozzychard: can you ellaborate more?
Jan 24 00:24:38 <ozzychard> aehs29: sure
Jan 24 00:25:04 <ozzychard> I have a few self-written drivers for linux which are substantially large
Jan 24 00:26:08 <ozzychard> The way I have my yocto setup now, they're all under one patch file
Jan 24 00:26:54 <ozzychard> A patch file that does minimal modifications, but adds many new files
Jan 24 00:41:00 <ozzychard> The problem is, when I want to actively develop my driver,
Jan 24 00:43:30 <ozzychard> any changes I make, I'll have to update this patch file
Jan 24 00:45:51 <ozzychard> so when reviewing my changes, essentially the reviewer sees a diff of the patch file
Jan 24 00:46:14 <ozzychard> ideally I'd like to have my files as files, which are copied over to the src/build directory before compiling
Jan 24 01:14:36 <brianm_> Is it possible to make a package always rebuild?
Jan 24 01:14:44 <brianm_> Trying to make a package that has git info, timestamps, etc.
**** ENDING LOGGING AT Wed Jan 24 03:00:01 2018