**** BEGIN LOGGING AT Thu Nov 10 03:00:01 2016
Nov 10 04:10:14 <dhirc> Hey, what do I need to change to skip the grub boot screen and just boot as fast as possible
Nov 10 04:21:14 <Guest_84857> allah is doing
Nov 10 04:21:21 <Guest_84857> sun is not doing allah is doing
Nov 10 04:21:29 <Guest_84857> moon is not doing allah is doing
Nov 10 04:21:35 <Guest_84857> stars are not doing allah is doing
Nov 10 04:21:45 <Guest_84857> planets are not doing allah is doing
Nov 10 04:21:52 <Guest_84857> galaxies are not doing allah is doing
Nov 10 04:21:58 <Guest_84857> oceans are not doing allah is doing
Nov 10 04:22:08 <Guest_84857> mountains are not doing allah is doing
Nov 10 04:22:15 <Guest_84857> trees are not doing allah is doing
Nov 10 04:22:21 <Guest_84857> mom is not doing allah is doing
Nov 10 04:22:47 <Guest_84857> dad is not doing allah is doing
Nov 10 04:22:56 <Guest_84857> boss is not doing allah is doing
Nov 10 04:23:02 <Guest_84857> job is not doing allah is doing
Nov 10 04:23:09 <Guest_84857> dollar is not doing allah is doing
Nov 10 04:23:17 <Guest_84857> degree is not doing allah is doing
Nov 10 04:23:26 <Guest_84857> medicine is not doing allah is doing
Nov 10 04:23:35 <Guest_84857> customers are not doing allah is doing
Nov 10 04:23:52 <Guest_84857> you can not get a job without the permission of allah
Nov 10 04:24:05 <Guest_84857> you can not get married without the permission of allah
Nov 10 04:24:25 <Guest_84857> nobody can get angry at you without the permission of allah
Nov 10 04:24:31 <Guest_84857> light is not doing allah is doing
Nov 10 04:24:37 <Guest_84857> fan is not doing allah is doing
Nov 10 04:24:48 <Guest_84857> businessess are not doing allah is doing
Nov 10 04:24:55 <Guest_84857> america is not doing allah is doing
Nov 10 04:25:07 <Guest_84857> fire can not burn without the permission of allah
Nov 10 04:25:23 <Guest_84857> knife can not cut without the permission of allah
Nov 10 04:25:30 <Guest_84857> rulers are not doing allah is doing
Nov 10 04:25:41 <Guest_84857> governments are not doing allah is doing
Nov 10 04:25:49 <Guest_84857> sleep is not doing allah is doing
Nov 10 04:25:55 <Guest_84857> hunger is not doing allah is doing
Nov 10 04:26:08 <Guest_84857> food does not take away the hunger allah takes away the hunger
Nov 10 04:26:28 <Guest_84857> water does not take away the thirst allah takes away the thirst
Nov 10 04:26:34 <Guest_84857> seeing is not doing allah is doing
Nov 10 04:27:33 <pweh> allah
Nov 10 04:57:25 <bananadev> again @@
Nov 10 05:17:53 <pweh> allah
Nov 10 08:39:40 <mborzecki> is oe-selftest assumed to be run only for x86 targets?
Nov 10 08:44:25 <aV_V> is there an easy way to transfer files from my host to my target through network?
Nov 10 08:48:25 <deva> aV_V: You could use scp?
Nov 10 08:54:18 <aV_V> deva: thanks!
Nov 10 08:54:29 <deva> aV_V: np ;)
Nov 10 08:54:36 <bluelightning> mborzecki: no, in fact it's regularly run for all of the major architectures on the YP autobuilder AFAIK
Nov 10 08:55:33 <bluelightning> mborzecki: what are you seeing that suggests it is?
Nov 10 08:55:57 <deva> What are the plans for 4.9 integration into yocto git/master ?
Nov 10 09:04:20 <mborzecki> bluelightning: test_sdimage_bootpart() assumes that there's a bzImage that can be installed as part of IMAGE_BOOT_FILES
Nov 10 09:05:06 <mborzecki> i'll fix that to fetch KERNEL_IMAGETYPE, just wanted to make sure that there's no arch specific assumptions
Nov 10 09:05:26 <bluelightning> looks like that's fairly new, probably an oversight
Nov 10 09:05:28 <rburton> khem: https://autobuilder.yoctoproject.org/main/builders/nightly-musl/builds/303/steps/Running%20Sanity%20Tests/logs/stdio <— new musl crashes in selftest
Nov 10 09:08:11 <mborzecki> bluelightning: btw. what would be the most reasonable way to detect architecture in oe-selftest? would looking at HOST_ARCH be sufficient?
Nov 10 09:16:11 <bluelightning> mborzecki: TARGET_ARCH I would have thought
Nov 10 09:20:08 <mborzecki> ok, i'll try that, thx
Nov 10 09:37:35 <fmeerkoetter> i am packaging an auto tools based project. i have a problem at the configure stage
Nov 10 09:37:55 <fmeerkoetter> namely the the configure stage isn't running ./configure
Nov 10 09:38:07 <fmeerkoetter> it passes sucessfully, failing at the compile stage
Nov 10 09:38:20 <fmeerkoetter> the log.do_configure says: NOTE: nothing to configure
Nov 10 09:38:23 <fmeerkoetter> any ideas?
Nov 10 09:57:18 <fmeerkoetter> https://paste.kde.org/pk248ho46
Nov 10 09:57:24 <fmeerkoetter> contains the full recipe
Nov 10 10:00:12 <rburton> fmeerkoetter: assuming autogen does nothing but run aclocal/autoconf/automake, you can just delete your do_configure
Nov 10 10:00:35 <fmeerkoetter> rburton: it fiddles around with some version stuff
Nov 10 10:00:39 <rburton> also FILESEXTRAPATH can be removed
Nov 10 10:00:44 <fmeerkoetter> but i am willing to ignorre this for now
Nov 10 10:01:22 <fmeerkoetter> the strange thing is. i've packaed a related autotools project this morning. also having a autogen.sh. it just worked
Nov 10 10:02:13 <rburton> have a look at what your do_configure is actually doing in the logs, i bet it isn't doing what you expect
Nov 10 10:02:26 <rburton> (autotools.bbclass sets $B, so do_configure isn't running in the source tree)
Nov 10 10:03:53 <fmeerkoetter> https://paste.kde.org/p36sdi583
Nov 10 10:03:55 <fmeerkoetter> rburton: ^
Nov 10 10:04:06 <fmeerkoetter> thats the log.do_configure
Nov 10 10:04:16 <fmeerkoetter> its pretty empty
Nov 10 10:05:15 <fmeerkoetter> would oe pick up autogen.sh or just run autoreconf (i am willing to give up on the stuff done in autogen.sh)
Nov 10 10:05:16 <rburton> hm put the inherit above your do_configure function
Nov 10 10:05:27 <rburton> as its not actually running your code at all
Nov 10 10:05:48 <fmeerkoetter> rburton: i've deleted my do_configure
Nov 10 10:06:04 <rburton> actually looked at the git repo
Nov 10 10:06:09 <rburton> its right
Nov 10 10:06:11 <rburton> there is no configure.ac
Nov 10 10:06:43 <rburton> the autogen doesn't respect NOCONFIGURE=true either
Nov 10 10:06:54 <fmeerkoetter> rburton: thanks. i will look into it. managed to locally build the package on my ubuntu box
Nov 10 10:07:03 <fmeerkoetter> assumed it was per se buildable
Nov 10 10:07:03 <rburton> yeah autogen.sh generates the configure.ac
Nov 10 10:07:21 <fmeerkoetter> rburton: ok. will look into it. thank you!
Nov 10 10:07:48 <rburton> a do_configure_prepend that does cd $S, ./autogen.sh should work
Nov 10 10:08:28 <rburton> you might have problems with their autoreconf not working as it doesn't get passed enough magic flags
Nov 10 10:45:09 <fmeerkoetter> rburton: how do i access $S?
Nov 10 10:45:39 <fmeerkoetter> an echo "__ $S __" tells me it is empty (in my do_configure_prepend)
Nov 10 10:48:14 <fmeerkoetter> ignore me
Nov 10 10:48:16 <fmeerkoetter> got it
Nov 10 10:48:27 <fmeerkoetter> needs to be written as cd ${S}
Nov 10 11:52:13 <fmeerkoetter> ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities.
Nov 10 11:52:40 <fmeerkoetter> how do i find out which part of the configure script caused this?
Nov 10 11:52:44 <fmeerkoetter> any hints?
Nov 10 12:17:11 <jku> fmeerkoetter: take a look at the actual config.log file, should find either "CROSS COMPILE Badness" or "is unsafe for cross-compilation" somewhere
Nov 10 12:31:43 <fmeerkoetter> jku: thanks. got it. upstream placed /usr/local/something into the include path
Nov 10 12:31:54 <fmeerkoetter> *sigh*
Nov 10 12:49:58 <Strike5150> Is it possible to append machine.conf files, I want to add an IMAGE_FSTYPES but only when building against qemux86
Nov 10 12:59:09 <nrossi> Strike5150: No, but you can always do it the other way around, append to IMAGE_FSTYPES based on the qemux86 machine override (IMAGE_FSTYPES_append_qemux86 = " extfoo")
Nov 10 12:59:53 <Strike5150> nrossi: Oh nice thanks!
Nov 10 13:54:01 <aV_V> If I want to build a package and then install it on my image without rebuilding the entire image, what would be the steps?
Nov 10 14:06:17 <aV_V> I tried this: http://pastebin.com/pTDz2RTs
Nov 10 14:06:35 <aV_V> but it can't find the package
Nov 10 14:06:54 <aV_V> when i try to install it
Nov 10 14:09:26 <zeenix> is krogoth branch expected to work with gcc6?
Nov 10 14:09:46 <zeenix> i'm sure i asked before but i dont' recall the exact answer
Nov 10 14:09:56 <jku> aV_V: when you bitbake a recipe the packages don't yet end up in tmp/deploy: look in $WORKDIR/deploy-rpms/  (tmp/work/<arch>/<recipe>/<version>/deploy-rpms)
Nov 10 14:22:38 <aV_V> jku: the package it's already on tmp/deploy
Nov 10 14:24:59 <aV_V> do I need to update repodata/repomd.xml ?
Nov 10 15:15:12 <zeenix> which component to choose for poky on bugzilla.yoctoproject.org ?
Nov 10 15:16:23 <zeenix> "Other YP Layers" ?
Nov 10 15:19:44 <rburton> zeenix: is it really poky specific or do you mean oe-core
Nov 10 15:20:04 <rburton> zeenix: considering poky is just the distro config and a few BSPs you're probably not using
Nov 10 15:20:38 <zeenix> rburton: nss-native build is broken against glibc 3.24
Nov 10 15:21:37 <zeenix> hm.. i might be wrong about the number, it's likely 2.24? :)
Nov 10 15:24:40 <zeenix> rburton: i mean git://git.yoctoproject.org/poky
Nov 10 15:24:51 <zeenix> quite a lot of recipes in there
Nov 10 15:25:18 <zeenix> s/a lot/a few/
Nov 10 15:25:33 <rburton> poky is oe-core + bitbake + meta-yocto, glued together into a single repo
Nov 10 15:25:50 <rburton> compare poky with http://git.openembedded.org/openembedded-core/
Nov 10 15:26:33 <rburton> i'd go as far as to say production use of Yocto shouldn't use poky, but your own way of managing bitbake + oe-core + any other layers
Nov 10 15:42:37 <aV_V> found it
Nov 10 15:42:42 <aV_V> "Whenever you perform any sort of build step that can potentially generate a package or modify an existing package, it is always a good idea to re-generate the package index with: "
Nov 10 15:42:52 <aV_V> $ bitbake package-index
Nov 10 15:48:25 <zeenix> rburton: ah ok, you can hopefully understand why it's confusing :)
Nov 10 15:48:40 <zeenix> and hard to remember
Nov 10 15:49:50 <rburton> zeenix: yeah we need to make less of a deal about poky imho. it's a vehicle for QA, that's all.
Nov 10 15:55:08 <zeenix> rburton: so i'll file the bug against meta-yocto for nss recipe
Nov 10 15:55:16 <rburton> zeenix: no, oe-core
Nov 10 15:55:29 <zeenix> ok :(
Nov 10 15:55:38 * zeenix still got it wrong
Nov 10 15:55:41 <rburton> meta/ -> oe-core
Nov 10 15:55:48 <rburton> meta-poky and meta-yocto* -> poky
Nov 10 16:04:30 <zeenix> rburton: that helps a lot
Nov 10 16:05:16 <rburton> zeenix: if in doubt, look in the openembedded-core repo.  and stop using poky.
Nov 10 16:05:41 <aV_V> on which recipe I can find readelf ? I searched on openembedded.org but didn't find it
Nov 10 16:06:28 <rburton> aV_V: that's typically part of binutils
Nov 10 16:08:09 <aV_V> that what I thought, I install it but there is no readelf command
Nov 10 16:09:42 <aV_V> I'm looking at the recipe now
Nov 10 16:29:45 <aV_V> it seems readelf isn't install it by default
Nov 10 16:31:41 <aV_V> any idea how to install it?
Nov 10 16:31:42 <aV_V> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/binutils?h=krogoth
Nov 10 16:33:15 <rburton> have you tried bitbake binutils?
Nov 10 16:33:36 <rburton> then use oe-pkgdata-util to see what package the binary ended up in
Nov 10 16:40:35 <aV_V> rburton: I did install binutils on my target
Nov 10 16:42:01 <aV_V> rburton: I did source oe-pkdata-util lookup-recipe binutils but my terminal seems frozen :>
Nov 10 16:44:22 <rburton> oe-pkgdata-util find-path */*readelf*
Nov 10 16:44:37 <rburton> binutils: /usr/bin/i586-poky-linux-readelf
Nov 10 16:55:39 <aV_V> rburton: ok, it found it
Nov 10 16:56:21 <aV_V> rburton: but that where are these? on my target there isn't
Nov 10 16:58:22 <yann> when using VARIABLE_class(target|native) ina recipe, what are the interactions with the unqualified VARIABLE ? is it ignored  ?
Nov 10 16:59:44 <rburton> aV_V: did you install that package?
Nov 10 17:00:00 <aV_V> rburton: binutils? yes
Nov 10 17:00:13 <rburton> yann: if the class is present then the variable effectively gets renamed
Nov 10 17:01:05 <rburton> aV_V: you ddn't just look for /usr/bin/readelf did you?
Nov 10 17:02:07 <yann> ok, thx
Nov 10 17:02:17 <aV_V> rburton: when u said to run oe-pkgdata-util find-path */*readelf*, did u referred on target machine? I run it on host
Nov 10 17:02:36 <rburton> yeah on the host
Nov 10 17:02:58 <rburton> but readelf doesnt' end up in /usr/bin/readelf
Nov 10 17:04:14 <aV_V> rburton: I got this:
Nov 10 17:04:15 <aV_V> binutils: /usr/bin/arm-poky-linux-gnueabi-readelf
Nov 10 17:04:24 <aV_V> binutils: /usr/arm-poky-linux-gnueabi/bin/readelf
Nov 10 17:04:55 <aV_V> I searched that on my target and there is nothing of this
Nov 10 17:07:21 <aV_V> rburton: I must go, hope I can fix it tomorrow. Thanx for ur help
Nov 10 17:07:22 <rburton> i'd check that you actually have binutils in the package index, and what it thinks is in that package on
Nov 10 17:10:05 <aV_V> rburton: now I understand. Yes, there is a readelf binary in the package
Nov 10 17:10:23 <aV_V> I will try to reinstall it
Nov 10 17:10:27 <aV_V> then
Nov 10 17:10:31 <aV_V> thanks
Nov 10 17:12:27 <khem`> rburton: its not clear which test is failing
Nov 10 17:12:48 <khem`> can you point to how I can reproduce it ?
Nov 10 17:15:45 <rburton> khem: some binary was segfaulting, but no idea what binary...
Nov 10 17:15:55 <rburton> i mean, i know the binary name, but not what it is
Nov 10 17:16:03 <khem`> whats the bin name
Nov 10 17:16:15 * khem` pulls his prism glass
Nov 10 17:16:35 <rburton> Central error: [    5.136799] autospawn[757]: segfault at b70fca9c ip b770e472 sp b70fcaa0 error 6 in libc.so[b76da000+93000]
Nov 10 17:16:55 <rburton> ah, pulseaudio?
Nov 10 17:18:34 <khem`> usually it seems to be like a dlopen issue
Nov 10 21:06:32 <yann> isn't it a bug that BUILD_CC and friends are not listed in the reference's variable glossary ?
Nov 10 21:15:13 <rburton> yann: yes
Nov 10 21:16:47 <ramos> is there some nice tip how to check why sstate mirror wasn't used ?
Nov 10 21:17:07 <ramos> bitbake-diffsigs use local sstate cache
Nov 10 21:18:14 <ramos> I found on sstate mirror sigdata but it seems identical
Nov 10 21:18:14 <yann> rburton: component "handbook" or "PRD" ? (what does the latter stand from btw ?)
Nov 10 21:21:39 <kergoth> ramos: options are limited there, since it has to know what to fetch, it can't scan other sigdata from other builds to compare against
Nov 10 21:23:40 <ramos> kergoth: any tips how to check sstate_mirror with local sstate cache, or have some -DDD print which points to the proper place ?
Nov 10 21:23:51 <ramos> kergoth: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc)
Nov 10 21:24:04 <kergoth> what do you mean by proper place?
Nov 10 21:24:50 <kergoth> there's no way for it to know what 'proper' is. all it knows is it tried to wget the file with this checksum and it didn't exist. it doesn't know *why* it doesnt' exist. the best we can do is heuristically examine the available signature data to see which one is closest, and show the differences, but we can't do that without local access to all the available sstates
Nov 10 21:25:41 <ramos> let mi describe situation
Nov 10 21:26:00 <ramos> I have a little bit customized base-files
Nov 10 21:26:03 <ramos> package
Nov 10 21:28:00 <ramos> built on old one server( sstate-mirror is updated properly ) can't be build from ssate mirror on other
Nov 10 21:28:17 <ramos> i asssume that probably some variable is not whitelisted
Nov 10 21:28:48 <ramos> and base files is fetched and then once again rebuild
Nov 10 21:31:19 <ramos> kergoth: i tried just to print stamp with -S none but i got Bitbake's cached basehash does not match the one we just generated
Nov 10 21:31:33 <kergoth> -S none doens't print anything, hence 'none'
Nov 10 21:31:38 <kergoth> all it does is dumps sigdata to disk
Nov 10 21:31:44 <kergoth> -S printdiff is probably what you're looking for
Nov 10 21:34:47 <ramos> kergoth: it does the same
Nov 10 21:35:04 <kergoth> of course, as i said, it can't compare the sigdata if it has nothing local to compare against
Nov 10 21:35:20 <ramos> bitbake -S ?
Nov 10 21:35:37 <ramos> compare local sstate cache ?
Nov 10 21:38:12 <ramos> kergoth: for printdiff it only compares accroding to help
Nov 10 21:38:34 <kergoth> do you expect it to get a list of available sigdata from the mirror via magic?
Nov 10 21:38:42 <kergoth> operations on the remote are much more limited than local
Nov 10 21:38:52 <kergoth> i've gone over this like 3 times now
Nov 10 21:39:17 <ramos> i copied sstate mirror now to local workspace
Nov 10 21:40:04 <ramos> just thouthg that there is some nice tool/script for debbuging sstate mirror signatures
Nov 10 21:41:39 <ramos> kergoth: you put sstate mirror on som glusterfs or ceph ?
Nov 10 21:42:10 <kergoth> bitbake -S printdiff is the correct mechanism to diagnose as long as all your signature data (.sigdata/.siginfo/.sigbasedata) is in SSTATE_DIR
Nov 10 21:49:03 <manju> hi all.. is there a way to collect all the commit ID's of packages being used in a build? meaning i want to collect kernel, u-boot etc information in a single file which has details about which commit id
Nov 10 21:51:34 <ramos> manju: check buildstats
Nov 10 21:52:34 <manju> ok thanks..looking into buildstats now
Nov 10 21:52:47 <ramos>  USER_CLASSES += "buildstats"
Nov 10 21:52:54 <ramos> in you local.conf
Nov 10 21:55:00 <manju> i tried using INHERIT += "distrodata"
Nov 10 21:55:10 <manju> but it applies to only one package at a time
Nov 10 21:55:38 <ramos> a sorry ;/ buildstats doesn't contain commit hashes
Nov 10 21:58:08 <kergoth> manju: `buildhistory-collect-srcrevs -a` after the build completes, assuming you have buildhistory enabled
Nov 10 21:58:47 <manju> ok will try buildhistory...
Nov 10 22:15:44 <manju> buildhistory is providing metadata revs, where can i find all the packages revs?
Nov 10 22:17:44 <kergoth> what are you referring to?
Nov 10 22:17:51 <kergoth> what do you mean 'commit ids'?
Nov 10 22:18:02 <kergoth> commit ids of what? bitbake? the layers? the upstream sources fetched for the recipes?
Nov 10 22:18:13 <kergoth> commit id at a package level is nonsensical, packages don't involve git at all
Nov 10 22:18:45 <ramos> probably manju wants SRC_REV
Nov 10 22:18:46 <manju> i meant "upstream sources fetched for the recipes"
Nov 10 22:19:29 <kergoth> which is what buildhistory has
Nov 10 22:19:32 <kergoth> so i don't see the problem
Nov 10 22:20:13 <ramos> manju: you built image or package ? from fresh without sstate cache ?
Nov 10 22:21:06 <manju> i built the image...i reused pervious sstate-cache (built without buildhistory)
Nov 10 22:23:49 <kergoth> as i said, buildhistory-collect-srcrevs gives you the SRCREV from the recipes, which was the rev of the upstream urls
Nov 10 22:24:00 <kergoth> it does not give you revs of the metadata layers
Nov 10 22:25:28 <manju> ok thanks.. i think i have a issue, i dont see packages directory under buildhistory
Nov 10 22:25:55 <yann> there is a problem in freetype recipe, wrt oe_multilib_header: the generated .h uses #include <freetype2/freetype/*>, where the .pc is designed so the app uses #include<freetype/*>
Nov 10 22:26:16 <yann> how best to fix that ?
Nov 10 22:26:40 <yann> we could add -I${includedir} in freetype2.pc, but that looks ugly
Nov 10 22:27:16 <rburton> yann: can't recall what PRD stands for, so handbook :)
Nov 10 22:27:48 <yann> rburton: ok done :)
Nov 10 22:29:24 <yann> apparently, oe_multilib_header simply assumes that packages will always use -I${includedir}
Nov 10 22:29:38 <yann> sounds nasty
Nov 10 22:30:00 <manju> rebuilding from scratch with buildhistory helped... thanks :)
Nov 10 22:32:18 <ramos> manju: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES
Nov 10 22:36:01 <ramos> kergoth: when package is built and sstate is used, all tasks are check for existence in sstate cache ? o bitbake tries from top that is do_build ?
Nov 10 22:44:26 <manju> thanks ramos and kergoth
Nov 10 22:52:52 <yann> hm, isn't there a quoting syntax to prevent variable expansion in a recipe ?  found nothing in bitbake manual, and neither backslash nor $$ work - don't we have anything better to use than '$''{varname}' ?
Nov 10 22:55:08 <kergoth> nope, there's no way to escape it right now, sadly
Nov 10 22:55:43 <ramos> kergoth: when package is built and sstate is used, all tasks are check for existence in sstate cache ? o bitbake tries from top that is do_build ?
Nov 10 22:55:58 <kergoth> i don't understand the question.
Nov 10 22:56:16 <ramos> bitbake calculates checksum of each task
Nov 10 22:56:19 <kergoth> bitbake checks for sstate availability before the build starts
Nov 10 22:56:32 <ramos> then i assume search in sstate for proper sing checksum
Nov 10 22:56:40 <kergoth> no
Nov 10 22:56:42 <kergoth> there's no "search"
Nov 10 22:56:56 <kergoth> it checks to see if it exists at a specific path (SSTATE_DIR) with that checksum
Nov 10 22:56:57 <kergoth> that's it
Nov 10 22:56:59 <kergoth> yes or no
Nov 10 22:57:18 <kergoth> if not, it tries sstate mirrors. if that fails, it'll run the real task
Nov 10 22:57:24 <ramos> ok for me it's like searching
Nov 10 22:57:35 <ramos> kind of heurystic
Nov 10 22:58:43 <kergoth> no, it's -S printdiff that searches for other sstates which are "similar to" the current
Nov 10 22:58:49 <kergoth> the build does nothing of the sort
Nov 10 22:58:51 <kergoth> only -S does
Nov 10 22:58:59 <ramos> ok
Nov 10 22:59:30 <ramos> so bitbake request for tasks outputs from sstate cache ?
Nov 10 23:00:08 <kergoth> it looks for all sigdata available for a given recipe+task, yes. then it determines which of those is closest to what it's looking for
Nov 10 23:00:23 <kergoth> without the other sigdata to compare against, there's no way for it to show you any information about what's changed
Nov 10 23:01:16 <ramos> i'm asking regarding bitbake sstate cache process work
Nov 10 23:01:35 <ramos> i read couple time manual about sstate cache
Nov 10 23:02:01 <ramos> whenvere sstate is used in temp dir i see 4 setscene tasks
Nov 10 23:02:17 <ramos> populate sysroot and some 3 more
Nov 10 23:02:34 <ramos> never seen compile or do fetch
Nov 10 23:03:27 <kergoth> those aren't needed.
Nov 10 23:03:50 <kergoth> populate_sysroot is needed to satisfy deps from other recipes, and package to get packages
Nov 10 23:04:05 <kergoth> why would you need to cmopile if we already have the files that came out of the build in the populate_sysroot and packaging setscenes?
Nov 10 23:05:20 <ramos> obiously no need
Nov 10 23:05:46 <ramos> but why task is not somehow flaged
Nov 10 23:05:50 <kergoth> we don't bother using sstate for those intermediate tasks, only the later tasks
Nov 10 23:05:54 <kergoth> i don't understand the question
Nov 10 23:06:14 <ramos> why do_compile has no setscene information
Nov 10 23:06:14 <kergoth> if you want to know how we configure which tasks use sstate, read sstate.bbclass
Nov 10 23:06:24 <kergoth> again, we only use sstate for later tasks
Nov 10 23:06:35 <kergoth> do_compile *should* have sigdata/siginfo, just no sstate tarball
Nov 10 23:06:50 <kergoth> if the sigdata/siginfo for those is missing, you didn't put them on your mirror when you did your original build
Nov 10 23:07:32 <kergoth> we need the sigdata from the intermediate tasks to fully show you what variables resulted in the sstate mismatch / checksum change
Nov 10 23:07:33 <ramos> ok I will need check code
Nov 10 23:09:14 <kergoth> for example, if a variable used in do_compile changes, the populate_sysroot checksum will change, but the variable changed in do_compile wont' be in the populate_sysroot sigdata. -S printdiff will walk the task dependencies to find the root cause if those are available, otherwise it'll just say the task checksum changed, but not why
Nov 10 23:13:14 <ramos> bitbake won't show in verbose mode that he can't get from sstate cache sigdata for do_compile ?
Nov 11 01:03:49 <yann> D'oh - pkg-config strips any -I${includedir} - but unfortunately bitbake does not add it systematically - and that causes problems with oe_multilib_header as noted above
Nov 11 01:05:43 <yann> -I${includedir}/. is a workaround, but well... who's prepending the $sysroot to pkgconfig paths ?
Nov 11 01:06:56 <manju> MACHINE_EXTRA_RRECOMMENDS += " kernel-modules" will this add all the kernel modules built into rootfs?
Nov 11 01:07:38 <manju> I dont see all the kernel modules in my rootfs, checking if there is a different method do it...
Nov 11 01:17:23 <nrossi> manju: MACHINE_EXTRA_RRECOMMENDS is only "recommends" and not all images add those packages (e.g. core-image-minimal does not, but any core-image derived does unless it overrides IMAGE_INSTALL/CORE_IMAGE_BASE_INSTALL)
Nov 11 01:20:01 <manju> thanks for the tip nathan...also the lockfiles worked great
Nov 11 01:20:28 <manju> flock has NFS issue, so using bitbake way of lockfiles really helped
Nov 11 01:21:25 <nrossi> manju: NFS has plenty of issues ;), its why oe-core generates a warning when you run on NFS :)
Nov 11 01:21:48 <manju> true that :)
Nov 11 02:16:23 <khem> nrossi: infact it ends up as a RRECOMMENDS which means unless you add it to BAD_RECOMMENDATIONS it will get into image
Nov 11 02:17:02 <khem> I think RRECOMMENDS has issues with rpm package-management too
Nov 11 02:17:12 <khem> it works fine with ipk
Nov 11 02:19:46 <nrossi> khem: True, but packagegroup-base is not part of rdepends for core-image-minimal. So it skips packagegroup-machine-base entirely
Nov 11 02:20:28 <khem`> thats right
Nov 11 02:25:33 <manju> khem: so having MACHINE_EXTRA_RRECOMMENDS in a custom image is not recommended? custom image is based off core-image-minimal to keep the size smaller
Nov 11 02:28:55 <khem`> manju: it depends what you want. Adding whole list may not be ideal
Nov 11 02:29:01 <khem`> but you may selectively add
Nov 11 02:29:07 <khem`> modules
Nov 11 02:29:13 <khem`> which are requested
Nov 11 02:30:18 <khem`> if you care for size then dont add MACHINE_EXTRA_RRECOMMENDS += " kernel-modules"
Nov 11 02:31:50 <manju> khem: yes make sense
Nov 11 02:32:14 <khem`> you can select individual modules packages
Nov 11 02:32:22 <khem`> and keep the size down
Nov 11 02:32:35 <bluelightning> just for clarity, setting MACHINE_EXTRA_RRECOMMENDS in an image recipe won't work - that variable needs to be set at the configuration level to take effect
Nov 11 02:32:43 <bluelightning> you can however add whatever you want to IMAGE_INSTALL
**** ENDING LOGGING AT Fri Nov 11 03:00:00 2016