**** BEGIN LOGGING AT Thu Sep 27 02:59:59 2018
Sep 27 06:46:14 <angelo_ts> hi, by runquemu qem,ux86 (testing sato) i get "ValueError: invalid literal for int() with base 10: 'ctl failed:'"
Sep 27 06:53:19 <angelo_ts> seems something related with setup_tap, full error log https://pastebin.com/DKCxxT9g
Sep 27 07:07:52 <angelo_ts> i disabled the config.setup_network() line, now runqemu scripts completes, but cannot find qemu in the path  : https://pastebin.com/wx0AGts8
Sep 27 07:08:55 <angelo_ts> so, using the command line from the script, with just /usr/bin/qemu-system-i386 as a command, all works, image finally run
Sep 27 07:43:54 <mckoan> good morning
Sep 27 08:02:23 <LetoThe2nd> mckoan: morning, at least.
Sep 27 08:09:28 <mckoan> LetoThe2nd: :-D
Sep 27 09:27:50 * JaMa created 2 enhancement tickets for 2.7, lets see how it helps with self-motivation :)
Sep 27 09:30:49 <yocti> New news from stackoverflow: Yocto: Is there a way to remove items of SRC_URI in local.conf? <https://stackoverflow.com/questions/52533401/yocto-is-there-a-way-to-remove-items-of-src-uri-in-local-conf>
Sep 27 09:40:00 <RP> jdel: The variable naming may become a problem and be confusing, that is my main worry :/
Sep 27 10:00:55 <yocti> New news from stackoverflow: Yocto do_install(): install utility manual <https://stackoverflow.com/questions/52534382/yocto-do-install-install-utility-manual>
Sep 27 10:55:51 <eduardas_m> hello, I have updated from Sumo 2.5 to Sumo 2.5.1 and now my u-boot recipe fails to compile
Sep 27 10:56:08 <eduardas_m> I get a unable to execute 'x86_64-linux-gnu-gcc': No such file or directory when building libfdt target
Sep 27 10:56:34 <eduardas_m> this seems related to this commit in poky: https://git.yoctoproject.org/cgit.cgi/poky/commit/?h=sumo&id=b91562697d1d04fb7cad15c1ab7d7bf3cd178589
Sep 27 10:57:19 <eduardas_m> what would be the proper solution here?
Sep 27 11:01:05 <yocti> New news from stackoverflow: A literal string containing escape slashes on groovy. <https://stackoverflow.com/questions/52534956/a-literal-string-containing-escape-slashes-on-groovy>
Sep 27 12:01:17 <yocti> New news from stackoverflow: A literal string containing escape slashes on groovy <https://stackoverflow.com/questions/52534956/a-literal-string-containing-escape-slashes-on-groovy>
Sep 27 12:45:14 <stash_> I can't make 'combo-layer init' work unless I manually go into the local_repo_dir and 'git checkout rocko'. Do I have something mis-configured?
Sep 27 13:08:46 <JPEW> eduardas_m: What target are you building u-boot for?
Sep 27 14:37:53 <cquast> Is it possible to treat all warnings as errors in yocto? I feel like things are maybe not working because I don't fix my warnings, but I should.
Sep 27 14:46:25 <JaMa> cquast: depends on which warnings you mean, the QA warnings are easy to turn into errors, see WARN_QA and ERROR_QA variables (yes, I have all WARN_QA in ERROR_QA in my builds)
Sep 27 15:02:35 <cquast> there is no switch to treat all warnings as errors?
Sep 27 15:02:52 <cquast> because to edit ERROR_QA, I would need to find out all possible errors first, right?
Sep 27 15:13:26 <rburton> cquast: ERROR_QA_append =  " ${WARN_QA}"
Sep 27 15:26:41 <dreyna> rbuton: https://windriver.webex.com/join/webex_1931429
Sep 27 17:56:25 <jdel> is RDEPENDS supposed to be a super-set of FILERDEPENDS?
Sep 27 18:00:27 <fray> yes.. FILERDEPENDS is specific to figuring out what is needed and rolls 'up' to RDEPENDS which is at a package level
Sep 27 18:06:09 <jdel> so anything in FILERDEPENDS that isn't RDEPENDS triggers a package_qa error?
Sep 27 18:07:25 <fray> implementation has changed, so that I'm nto sure about
Sep 27 18:07:32 <jdel> i'm trying to understand why I'm getting package_qa errors about missing RDEPENDS
Sep 27 18:07:50 <jdel> it looks like the package routine computes FILERDEPENDS properly, but doesn't update RDEPENDS
Sep 27 18:07:51 <fray> basically the 'rpmdeps' program is run, and seeds the system to know what type sof dependencies are present.. that eventually rolls up to RDEPENDS
Sep 27 18:08:01 <fray> what is the error?
Sep 27 18:08:16 <fray> there are specific QA checks on RDEPENDS that look for file types and complain..
Sep 27 18:08:20 <jdel> do_package_qa: QA Issue: /usr/lib/libconfigdb.so.0.0.0 contained in package configdb requires libxml.so.0, but no providers found in RDEPENDS_configdb
Sep 27 18:08:24 <fray> things like shell dependencies..
Sep 27 18:08:29 <jdel> but libxml is properly found in FILERDEPENDS
Sep 27 18:08:38 <jdel> and it's in the recipe sysroot etc
Sep 27 18:08:51 <fray> ok.. yes.. so the issue is that the system found a dependency on a library provided by something that was not other wise 'required' by the system.
Sep 27 18:09:12 <jdel> right, but that should have been auto-computed via a DEPENDS, right?
Sep 27 18:09:18 <fray> file dependencies only work in RPM.. you need to manually specify DEPENDS or RDEPENDS so non-rpm based dependency resolvers work..
Sep 27 18:09:39 <fray> no.. the system doesn't know what provides libxml.so.0.. it only knows it was provided and no RDEPENDS items are providing it
Sep 27 18:10:02 <jdel> but do_package runs objdump on all execs and shlibs to compute RDEPENDS
Sep 27 18:10:21 <fray> so you need to specify something that provides libxml.so.0..  (this is where my memory gets fuzzy) if it's in DEPENDS (I need this recipe for sources) then I think it's automatic in most cases..
Sep 27 18:10:47 <fray> yes.. but it needs to map binary package to binary package and can not always do that..
Sep 27 18:11:03 <fray> if the dependency is not in DEPENDS, it doesn't know where to look.. and it's entirely possible you have host contamination..
Sep 27 18:11:13 <jdel> it's in DEPENDS properly, but RDEPENDS gets computed wrong
Sep 27 18:11:24 <fray> (this is much less likely since recipe specific sysroots has happened.. YP 2.4? I think)
Sep 27 18:11:25 <jdel> the mystery deepens because this only happens when building using the sstate cache
Sep 27 18:11:51 <fray> ya, it's an issue where DEPENDS may not be right... or if it is -- then something else makes it unable to be determined..
Sep 27 18:11:54 <fray> which YP version?
Sep 27 18:12:03 <fray> (or branch)
Sep 27 18:26:26 <jdel> it's some qualcom repackaging
Sep 27 18:26:36 <jdel> i think all the issues are with their custom classes
Sep 27 18:31:21 <jdel> i thought I had resolved it with the patch I pasted into the channel yesterday
Sep 27 18:31:38 <jdel> but I'm still fumbling around with how all this stuff is supposed to work
Sep 27 18:45:34 <dkc> any idea why the NPM fetcher is taking ages? 1200s spent in do_fetch so far, kind of crazy
Sep 27 19:22:33 <jdel> dkc: network problems on the build host
Sep 27 19:23:23 <jdel> ?
Sep 27 19:23:28 <dkc> nope, I'm tail'ing -f the do_fetch logs, it's moving and checking the dependencies, in a recursive way i'd say
Sep 27 19:23:48 <dkc> what it's doing is not clear to me though
Sep 27 19:24:01 <jdel> the do_fetch of npm?
Sep 27 19:24:12 <dkc> yes
Sep 27 19:24:53 <jdel> if it's making progress, could it be slow throughput on the download?
Sep 27 19:27:52 <dkc> it's querying npmjs like hell to inspect dependencies, and there seems to be a pause between command but I got bored and appended noverify=1 on every single npm:// lines
Sep 27 22:13:16 <RP> jdel: I suspect you're missing a DEPENDS maybe?
Sep 27 22:13:38 <RP> the fact it takes a build from sstate to discover that is worrying
Sep 27 22:13:51 <RP> I can kind of guess how it may happen though
Sep 27 23:09:34 <ssingh02> @here I'm using the meta-security layer to install apparmor but it installs unwanted packages such as the man info, perl, python etc. I tried using PACKAGECONFIG_remove = " perl python man" but the packages are still built and the large binaries present on the rootfs, why is PACKAGECONFIG_remove working?
Sep 27 23:10:01 <ssingh02> I mean PACKAGECONFIG_remove += " perl python man"
Sep 27 23:20:53 <ssingh02> not working* PACKAGECONFIG_remove += " perl python man" is NOT working apparmor bbappend recipe
Sep 27 23:21:13 <ssingh02> does anyone have any suggestions?
Sep 27 23:21:55 <bluelightning> ssingh02: try bitbake -e apparmor | less and look at the history for the variable
Sep 27 23:22:38 <rburton> they could be coming from other packages too, not just apparmour
Sep 27 23:23:58 <bluelightning> https://wiki.yoctoproject.org/wiki/Technical_FAQ#I.27ve_created_a_bbappend_for_a_recipe_but_what_I.27m_setting_there_isn.27t_having_any_effect.2C_how_do_I_fix_this.3F
Sep 27 23:26:10 <ssingh02> @rburton you're right, I suspect that too. meta-security has so many packages in it :O
Sep 27 23:28:09 <ssingh02> thanks @bluelightnning I'm going to check now
Sep 27 23:28:17 <bluelightning> ssingh02: in terms of what is pulling stuff into the image see https://wiki.yoctoproject.org/wiki/Technical_FAQ#How_do_I_find_out_why_something_is_in_my_image.3F
Sep 27 23:31:01 <ssingh02> Ok
Sep 27 23:58:35 <armpit> apparmor is inheriting perlnative and pythonnative, maybe there may a need for futher recipe clean up ?
Sep 28 00:00:04 * armpit this looks funny 
Sep 28 00:00:08 <armpit> CONFIGUREOPTS_remove = "--disable-static"
Sep 28 00:00:08 <armpit> EXTRA_OECONF_append = " --enable-static"
Sep 28 00:00:19 <ssingh02> here's what my apparmor looks like from buildhistory: https://pastebin.com/8d2TRni4
Sep 28 00:01:50 <ssingh02> and here's what perl looks like: https://pastebin.com/D3YyQWFg
Sep 28 00:02:07 <ssingh02> is it safe to conclude that my apparmor doesn't directly install perl?
Sep 28 00:02:46 <ssingh02> what does "glibc-mtrace" -> "perl" exactly mean? glibc-mtrace is installing perl?
Sep 28 00:04:25 <ssingh02> @armpit how can I remove the inheritance on perlnative and pythonnative  via apparmor bbappend? Is that even possible?
Sep 28 00:12:22 <armpit> ssingh02, not sure. if you can hack up the recipe to remove the bits you don't need, then I can look at if there is a way to clean it up to be more flexible
Sep 28 00:14:25 <ssingh02> ok, I'll try to get rid of mtrace and see if that gets rid of perl, if not then I'll hack something up
**** ENDING LOGGING AT Fri Sep 28 03:00:01 2018