Thursday, 2018-08-02

*** rrerolle <rrerolle!~rrerolle@2001:41d0:52:cff::c84> has quit IRC00:05
*** hattzy <hattzy!~hatter@h-37-123-162-70.NA.cust.bahnhof.se> has quit IRC00:08
*** rrerolle <rrerolle!~rrerolle@2001:41d0:52:cff::c84> has joined #yocto00:08
*** wto <wto!~wto@h-136-128.A336.priv.bahnhof.se> has quit IRC00:08
*** wto <wto!~wto@h-136-128.A336.priv.bahnhof.se> has joined #yocto00:09
*** sgw <sgw!~sgw@134.134.139.74> has joined #yocto00:43
*** anujm <anujm!~anujm@192.198.146.171> has quit IRC00:53
*** sgw <sgw!~sgw@134.134.139.74> has quit IRC00:56
*** sgw <sgw!~sgw@134.134.139.74> has joined #yocto00:59
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto00:59
*** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has joined #yocto00:59
*** sgw <sgw!~sgw@134.134.139.74> has quit IRC01:03
*** sgw <sgw!sgw@nat/intel/x-qvysumtwsocjghxi> has joined #yocto01:24
*** stephano <stephano!stephano@nat/intel/x-tstfscqunumzbfew> has joined #yocto01:24
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC02:04
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto02:10
*** anujm <anujm!~anujm@192.198.146.173> has joined #yocto02:14
-YoctoAutoBuilder- build #1195 of nightly-multilib is complete: Success [build successful] Build details are at https://autobuilder.yocto.io/builders/nightly-multilib/builds/119502:47
*** pabdaddy <pabdaddy!4066f914@gateway/web/freenode/ip.64.102.249.20> has quit IRC02:52
yoctiNew news from stackoverflow: Yocto recipe written in python giving me an error when trying to build with Bitbake <https://stackoverflow.com/questions/51467709/yocto-recipe-written-in-python-giving-me-an-error-when-trying-to-build-with-bitb>03:23
*** sgw <sgw!sgw@nat/intel/x-qvysumtwsocjghxi> has quit IRC03:23
*** sgw <sgw!~sgw@134.134.139.75> has joined #yocto03:27
*** tgraydon <tgraydon!tgraydon@nat/intel/x-trjnoxuzhjrvpkxy> has quit IRC03:37
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC04:05
*** RP <RP!~RP@5751f4a1.skybroadband.com> has quit IRC05:38
*** agust <agust!~agust@p50886A63.dip0.t-ipconnect.de> has joined #yocto05:46
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC06:24
*** fl0v0 <fl0v0!~fvo@i577A6179.versanet.de> has joined #yocto06:59
*** frsc <frsc!~frsc@200116b824be2700b3e8714f1f19b702.dip.versatel-1u1.de> has joined #yocto07:12
*** frsc <frsc!~frsc@200116b824be2700b3e8714f1f19b702.dip.versatel-1u1.de> has joined #yocto07:13
*** anujm <anujm!~anujm@192.198.146.173> has quit IRC07:16
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto07:19
*** anujm <anujm!~anujm@192.198.146.173> has joined #yocto07:25
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC07:37
*** rajm <rajm!~robertmar@148.252.241.226> has joined #yocto07:45
*** otavio <otavio!~otavio@static.203.17.243.136.clients.your-server.de> has quit IRC07:45
*** flying_sausages <flying_sausages!~flying_sa@static.88-198-40-49.clients.your-server.de> has quit IRC07:45
*** thaytan <thaytan!~thaytan@121-200-23-18.cust.aussiebb.net> has quit IRC07:46
*** flying_sausages <flying_sausages!~flying_sa@static.88-198-40-49.clients.your-server.de> has joined #yocto07:47
*** thaytan <thaytan!~thaytan@121-200-23-18.cust.aussiebb.net> has joined #yocto07:47
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yzwheakiamsudzbr> has joined #yocto07:50
*** malanecora <malanecora!b23cc82d@gateway/web/freenode/ip.178.60.200.45> has joined #yocto07:55
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto08:35
*** frsc <frsc!~frsc@200116b824be2700b3e8714f1f19b702.dip.versatel-1u1.de> has quit IRC08:36
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto08:36
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC08:42
*** frsc <frsc!~frsc@200116b824f53a00953c3d9bce6661a3.dip.versatel-1u1.de> has joined #yocto08:53
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has joined #yocto09:07
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has quit IRC09:11
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has quit IRC09:12
*** khem <khem!~khem@unaffiliated/khem> has quit IRC09:17
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has joined #yocto09:48
kinsifousHello09:49
kinsifouswhen i run tests for the qemu, i include the tests on the local.conf and then run bitbake <image> -c testimage09:49
kinsifousi added "bb.tests.data.TestConcatOverride.test_remove \"09:50
kinsifouswhich is not a part of the openembedded/openembedded-core/ but openembedded/bitbake09:51
kinsifoushowever, the test is not running and no error is being thrown09:51
kinsifousis there any way to add this test to run with the testimage?09:52
kinsifousor are the bitbake tests different from testimage?09:52
*** anujm <anujm!~anujm@192.198.146.173> has quit IRC09:56
*** nemunaire <nemunaire!~nemunaire@LFbn-1-9034-200.w86-238.abo.wanadoo.fr> has joined #yocto10:04
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto10:05
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC10:09
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto10:09
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC10:13
*** nemunaire <nemunaire!~nemunaire@LFbn-1-9034-200.w86-238.abo.wanadoo.fr> has quit IRC10:24
*** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has quit IRC10:28
kinsifousanybody?10:36
*** RzR <RzR!~RzR@lns-bzn-38-82-253-125-228.adsl.proxad.net> has quit IRC10:36
*** RzR <RzR!~RzR@unaffiliated/rzr> has joined #yocto10:36
*** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has quit IRC10:45
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto10:53
mihai-kinsifous, they are different10:54
mihai-that's a test for bitbake, you can run it with bitbake-selftest10:54
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has quit IRC11:03
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yzwheakiamsudzbr> has quit IRC11:04
*** robsta_ <robsta_!sid195711@gateway/web/irccloud.com/x-pjgvyfnbujuahldg> has quit IRC11:04
*** rhadye__ <rhadye__!sid217449@gateway/web/irccloud.com/x-kzqovahbqfdjtxdb> has quit IRC11:04
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-ynxlunocjkxvkjop> has quit IRC11:04
*** mtas__ <mtas__!sid127809@gateway/web/irccloud.com/x-onwrunizvcetfhue> has quit IRC11:06
*** rsalveti <rsalveti!sid117878@gateway/web/irccloud.com/x-eaayggnqolxhqjzw> has quit IRC11:06
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-qfwsksrzhepgghgw> has joined #yocto11:06
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has joined #yocto11:06
kinsifouswhoever gave me an answer before, Thank you. My session ended and logged me out.11:07
*** nighty- <nighty-!~nighty@s229123.ppp.asahi-net.or.jp> has joined #yocto11:09
malanecora[12:54] <mihai-> kinsifous, they are different [12:54] <mihai-> that's a test for bitbake, you can run it with bitbake-selftest11:13
kinsifousmihai: thank you11:13
kinsifousmalencora: thanks for the tip11:14
*** nemunaire <nemunaire!~nemunaire@LFbn-1-9034-200.w86-238.abo.wanadoo.fr> has joined #yocto11:14
*** flihp <flihp!~flihp@76.243.124.132> has quit IRC11:16
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC11:19
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto11:23
*** sgw <sgw!~sgw@134.134.139.75> has quit IRC11:24
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto11:25
*** marks__ <marks__!~marks@2a02:810d:640:67a0:e6a4:71ff:fe89:f1e3> has joined #yocto11:44
jofrPerhaps an "invalid" question since I'm still using pyro, but I started getting an error all of a sudden where quilt can't apply the default-gcc.patch..?11:48
jofrrejects in tools/Makefile and tools/env/Makefile11:48
jofrAaa, nevermind   :p11:51
*** marks__ <marks__!~marks@2a02:810d:640:67a0:e6a4:71ff:fe89:f1e3> has quit IRC11:52
*** marks__ <marks__!~marks@2a02:810d:640:67a0:e6a4:71ff:fe89:f1e3> has joined #yocto11:52
*** sgw <sgw!~sgw@134.134.139.76> has joined #yocto12:17
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has joined #yocto12:33
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC12:33
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC12:34
*** marks__ <marks__!~marks@2a02:810d:640:67a0:e6a4:71ff:fe89:f1e3> has quit IRC12:36
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has quit IRC12:37
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC12:44
yatesif a recipe foo has a DEPENDS = "bar", then is bar built to completion, or at least through do_deploy(), before foo "runs"?12:50
yatesi guess what i'm asking is, in this case, does bitbake/yocto still run through the tasks just once through firing the configured/addtask'ed tasks for both recipes, or does it run twice, once for each recipe?12:52
yates...i think...12:52
yatesi think the answer is just once12:52
yateswhich is why i needed a do_deploy[depends] = "virtual/kernel:do_deploy" in my foo recipe12:53
yatesor am i not making sense?12:56
yates:)12:56
yates\/12:59
yatesworks.12:59
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-qfwsksrzhepgghgw> has quit IRC13:05
malanecoraIf you have some DEPENDS13:05
malanecoraThe recipe is gonna be built after the do_sysroots/deploy, yes13:06
malanecoraBut the wirte_rpm/package tasks of the dependecy can be executed in parallel13:07
malanecora do_deploy[bar] = "virtual/kernel:do_deploy"13:08
malanecoraWill start to build the recipe after virtual/kernel:do_deploy is completed13:09
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has joined #yocto13:09
yatesi don't understand what the "do_deploy[bar] = "virtual/kernel:do_deploy" syntax means.13:11
JPEWyates: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#variable-flags13:12
yatesi think i understood "do_deploy[depends] = "virtual/kernel:do_deploy"", meaning the do_deploy of foo (the line being inside foo.bb and foo.bb having a do_deploy task) depends on the do_deploy of the virtual/kernel recipe(s) completion13:13
u1106does such a file make any sense? tmp/stamps/intel_corei7_64-poky-linux/nel-base/1.0-r0.do_image_complete_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene_setscene.0e1332570d90af079b91f4b3f31cdd2a.intel-corei7-6413:17
u1106if not does it ring any bell what could be wrong?13:18
JPEWu1106: I think I saw a patch on the mailing list about that....13:18
u1106JPEW: any keyword I could search for?13:18
JPEWrm_work setscene13:19
yatesi don't understand what the term "runtime" means in the context of bitbake. i would say run at bitbake time is build-time. re: section 3.10.5, https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#inter-task-dependencies13:19
yatess/run at bitbake/everything run at bitbake/13:20
JPEWu1106: Looks there was a patch, but RP reverted it and did something else13:20
JPEWu1106: https://patchwork.openembedded.org/series/12629/13:22
yatesJPEW: thanks, but i'm not sure which of the variable flag types in that section match [bar]. bar is a recipe, and none of the variable flags seem to be recipes13:23
yatesin any case, i'm good. do_deploy[depends] ... does what i want13:24
u1106JPEW: Thanks! Hmm, 19-June, unlikely I have that (in Rocko)13:25
JPEWyates: "runtime" referes to when the compile code runs on the target... for example if your program links against libfoo.so, it has a runtime dependency on libfoo.so.13:25
yatesyes, that's the "normal" definition, but it doesn't seem to make sense here.13:26
yateswhy does bitbake need to know about runtime dependencies ?13:27
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:27
JPEWyates: when bitbake generates the packages from a recipe, it need to add the meta-data into the package that indicates what other package each (runtime) depends on13:27
yatesaha. now THAT makes sense! thank you!13:28
*** kaspter <kaspter!~Instantbi@115.194.185.217> has joined #yocto13:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC13:32
JPEWyates: FYI, OE has code to automatically detect link time dependencies for compiled executables, which is why you don't see RDEPENDS for every library a program links against (it trawls through the ELF files to find the libraries the program is expecting)13:33
u1106JPEW: $ git log --grep "Simplify looping" --all --oneline13:34
u110652b11de rm_work: Simplify looping code13:34
u1106$ git branch -r --contains 52b11deeb921ba2013:34
u1106upstream/master13:34
u1106upstream/master-next13:34
u1106so not in any release yet I guess. Do you know whether that bug/problem had serious consquences? The reason I was looking in my stamps was that my rootfs had been updated, but bitbake thought that it did not have to re-run linux-intel:do_bundle_initramfs13:34
u1106(rootfs_cpio that is)13:36
JPEWu1106: I didn't follow the coversation, I just remember seeing the patches... It looks simple enough that it could get backported?13:36
u1106what mailing list would that have been on? I don't seem to see it on the Yocto list13:37
JPEWHere is the original patch (that was reverted): https://patchwork.openembedded.org/series/11989/13:37
JPEWLooks like it did eventually case a problem with filenames being too long13:38
JPEWopenembedded-core13:38
yatesJPEW: pretty impressive - i had no idea about all that13:42
u1106Yes I have seen that problem with too long names making the build fail completely. It happens after creating 10s of images in the same build area. Starting from scratch with a new build area helps. So I could guess the bug has no other serious conseqences than creating nonsense files, which eventually make the build fail. Today I did not hit that, my build area is relatively new.  So I guess linux-intel:do_bundle_initramfs not being called might be an13:44
u1106unrelated issues. The weird filename just raised my attention. Thanks for your help13:44
u1106JPEW: ^^^13:45
JPEWu1106: np13:45
*** majuk <majuk!~majuk@174-24-35-31.clsp.qwest.net> has joined #yocto14:08
*** rajm <rajm!~robertmar@148.252.241.226> has quit IRC14:27
*** webreformer <webreformer!~webreform@106.51.23.177> has joined #yocto14:38
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC14:40
webreformerHi All,14:40
webreformerHow to debug custom yocto layer ?14:40
webreformerplease provide me some input14:41
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has quit IRC14:49
*** xtungvu90 <xtungvu90!uid313450@gateway/web/irccloud.com/x-wplwmekoxukycbtd> has joined #yocto15:03
*** aehs29 <aehs29!~aehs29@149.199.62.254> has quit IRC15:08
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has quit IRC15:10
yateswebreformer: bitbake <recipe> -e15:16
yatesok, probably a very stupid, basic question: many python functions do things with "d", e.g., "d.getVarFlag("SWUPDATE_IMAGES_NOAPPEND_MACHINE", image, True)". what is "d"?15:17
JPEWbitbake "data store" (I think there is some better official name)15:18
yatesJPEW: i see. are the functions like getVarFlag standard python functions or defined in bitbake? if the latter, are they defined somewhere?15:19
JPEWNo, "d" is a class and those are member functions.... I don't have the exact source code path right now, but the bitbake manual can give more info15:20
JPEWso more to your question, they are defined by bitbake15:20
yatesthanks - i go dig15:21
yates(in the right place)15:21
JPEWyates: Be careful, you might find the cookie monster15:21
kergothbitbake/lib/bb/data_smart.py15:21
yatesthanks!15:22
kergothhaha, yeah, it's a bit odd the way it's implemented, an artifact of our performance requirements15:22
yates(cookie monsters are welcome...)15:22
kergothcookie monster is how overrides are handled, to avoid scanning the entire datastore to apply them15:22
yatesor it's not a joke?15:22
JPEWNo15:22
frayin most cases, 'd' is just available to you.. there are a few where it's 'e' (or environment), and to get 'd' (data) you need to do e.data.....15:23
kergothevent handlers have d now too15:23
frayas for the things to use.. d.expand, d.getVar, d.getVarFlags, d.setVar, d.setVarFlags are the common ones15:23
yatesgot d?15:23
yates:)15:23
fraykergoth ahh that got resolved, didn't realize that..15:23
kergothyeah, long standing annoyance.. it made sense at the time we implemented them, having everything in the event object, but writing 'd = e.data' all the damn time got old :)15:24
webreformeryates, I want to debug my yocto layer running inside board.15:24
frayquestion from someone, and I'm having a hard time finding a definitive resource.. 'VIRTUAL-RUNTIME' settings, I'm claiming they are 'distro' settings and can be used anywhere, by any recipe -- thus have to be globally set.15:24
yateswebreformer: gdb?15:24
yatesdepends on what exactly you're debugging15:25
fraythey are claiming, no they are image settings and can be set in an image context.. and other recipes should not use them15:25
*** jofr <jofr!~jofr@193.182.166.3> has quit IRC15:25
fraywebreformer, gdb is the debugger.. if you are doing kernel debugging (including modules) it is different then userspace debuggings..15:25
frayuserspace debugging, usually you want to generate a debug image, and tell gdb to use that debug image (when cross debugging)15:25
frayif you are debugging ON the target, then you need to add the debug symbols and sources onto the target image.15:26
yateswebreformer: you can also do remote debugging using gdb. i've found that to be helpful for embedded linux systems15:26
*** jofr <jofr!~jofr@193.182.166.3> has joined #yocto15:26
frayyes, that is the typical usage15:27
kergothI agree with you, nothing states they're image only, in fact aren't they already used in packagegroups too?15:27
webreformeryates, Yes, i am expecting remote debugging.15:27
webreformerWhere I can find more relevant information ?15:28
kergothuse of gdb isn't really yocto specific, there are lots of good resources for that. you haven't really given enough info about what sort of debugging you need to do to be able to elaborate much15:29
fraykergoth, that is exactly what I thought..15:29
yatesa trick i often do, if the applicaiton you want to debug does not depend on hardware on the embedded system, or that hardware can be substituted on a desktop system (e.g., a usb serial dongle), is to natively compile the app on a desktop linux and debug there. that is MUCH easier and faster.15:29
frayhttps://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#platdev-gdb-remotedebug15:29
fray(debuggign with GDB)15:29
fraywhoops.. thats an old manual..15:30
fraylet me get you a recent one15:30
kergothyates: that's a very good point, yeah, only work on hardware if you have to15:30
frayhttps://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#platdev-gdb-remotedebug15:30
webreformerI want to debug custom yocto layer which acts as Application manager15:30
fraythere that includes everything you need to get a proper gdb-server on the target, cross-gdb in the SDK, generate a regular and debug image..15:30
frayas well as configure cross-gdb to use the debug symbols from the debug image15:31
yateskergoth: right!15:31
fraydebugging a layer?  as in the build doesn't work right?   bitbake -e <recipe>  and inspecting the working directories are the ways to do that (for the most part)15:31
webreformerI want to debug C++ code build by 'layer' ?15:32
yateswebreformer: what C++ code?15:33
yateswhat layer?15:33
webreformerI have custom layer. recipe inside it build C++ code15:35
frayfollow the last link I posted15:35
frayhttps://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#platdev-gdb-remotedebug15:35
fraythis is how you cross-debug code..15:35
frayit tells you everything you should need to setup the debugging on target, as well as the host, etc15:35
fraycustomer layer doesn't matter.. code is code to the debugger15:35
fray'er.. custom15:35
webreformerI don't know exact terminologies here. sorry for that15:36
fraythe system, including debugging is setup to be extended with custom layers without having to change anything to do debugging..15:36
frayjust follow the instructions in the manual.  If you have questions about any instructions, ask those..15:36
webreformersure15:36
fray(actual GDB debugging steps are captured by the original GNU manuals..)15:36
*** justinttt <justinttt!49e56612@gateway/web/freenode/ip.73.229.102.18> has joined #yocto15:39
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC15:39
*** kaspter <kaspter!~Instantbi@115.194.185.217> has quit IRC15:44
*** kaspter <kaspter!~Instantbi@115.194.185.217> has joined #yocto15:45
*** frsc <frsc!~frsc@200116b824f53a00953c3d9bce6661a3.dip.versatel-1u1.de> has quit IRC15:50
*** dv_ <dv_!~dv@62.178.50.190> has joined #yocto15:54
yatesis there a human-readable doc for getVar and getVarFlag? i am not too good with python...15:55
yatesi guess it's obvoius?15:57
yatesif FOO = "a value" and FOO[a] = "another value", then getVar(FOO) = "a value" and getVarFlag(FOO, a) = "another value"?15:58
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:04
*** CoRfr <CoRfr!~CoRfr@carmd-fwm01.sierrawireless.com> has quit IRC16:06
frayd.getVar(value, [True/False]) -- the optional true/false is do you want the variable expanded or preserved.. True expands..16:13
frayd.getVarFlags(value, flag, [True/False])  flags are variables like:  VAR[flag] = 'value'16:13
frayd.setVar(variable, value)16:13
frayd.setVarFlags(variable, flag, value)16:14
fraythats about it.. pretty simple16:14
yateswhat does "expanded" and "preserved" mean?16:16
frayvariable = "${foobar}"16:16
frayfoobar = 'foo'16:16
yatesah16:17
frayd.getVar('variable', False) == "${foobar}"16:17
frayd.getVar('variable', True) == "foo"16:17
yatesgot it16:17
fraythe default value is True BTW16:17
fray(at least in any recent versions, it was False until YP 2.0 I believe16:17
yatesthat if foo = 'foo', bar = '${foo}', and 'whatisthis' = '${bar}' ? what would d.getVar('whatisthis', True) return?16:19
yatess/that is/what if/16:19
yatesi meant s/that if/what if/16:20
*** webreformer <webreformer!~webreform@106.51.23.177> has quit IRC16:20
yatesis expansion recursive?16:21
yatesi think this gets into earlly/late expansion?16:22
*** aehs29 <aehs29!~aehs29@149.199.62.254> has joined #yocto16:24
kergothyes, expansion is recursive, that would expand to foo16:28
kergothit's always expanded when the getVar happens, which is generally when the task is run in the case of a task, but also when the user runs bibake -e, etc. you can force early expansion with :=16:29
kergothi.e. foo="1"; bar="${foo}"; baz:="${bar}"; foo="2" -- getVar('bar') == '2', getVar('baz') == '1'16:29
*** fl0v0 <fl0v0!~fvo@i577A6179.versanet.de> has quit IRC16:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC16:32
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:33
*** wizofe <wizofe!~wizofe@185.52.146.174> has joined #yocto16:42
*** kism <kism!615a3e9e@gateway/web/freenode/ip.97.90.62.158> has joined #yocto16:43
kismHi, I'm an intern taking on a yocto project set up for our development board. Just wanted to introduce myself because I will have questions.16:44
*** kism <kism!615a3e9e@gateway/web/freenode/ip.97.90.62.158> has quit IRC16:48
*** kism <kism!615a3e9e@gateway/web/freenode/ip.97.90.62.158> has joined #yocto16:49
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto16:53
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC16:54
kismhow active is this chat?16:54
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto16:58
*** armpit <armpit!~armpit@2601:202:4180:c33:fc8c:8ad2:54e:b231> has quit IRC17:01
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto17:01
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto17:04
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto17:06
-YoctoAutoBuilder- build #1197 of nightly-multilib is complete: Success [build successful] Build details are at https://autobuilder.yocto.io/builders/nightly-multilib/builds/119717:07
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto17:10
kismhi vmeson17:14
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC17:29
kismHi I'm currently running into errors while running my build in bitbake, this is my command: bitbake phytec-headless-image -c populate_sdk17:34
kismim getting a fuction failed: patch_do_patch17:35
kergoththat doesn't tell us much of anything, you need to post the actual error log, ideally to a pastebin17:36
kismok https://pastebin.com/4CnYvpnF17:37
kismthats my error output17:38
kismthis is my log file of failure https://pastebin.com/dBdrBfMJ17:42
*** sgw <sgw!~sgw@134.134.139.76> has quit IRC17:50
fraylast file indicates you have a patch from the meta-phytex layer that does not apply17:51
frayyou need to manually apply it and fix the patch it references..17:51
fraypatch in question is located at: /opt/PHYTEC_BSPs/yocto_ti/sources/poky/../meta-phytec/recipes-bsp/barebox/files/0001-Makefile-add-TARGETCC.patch17:52
*** ntl <ntl!~nathanl@65-36-80-8.dyn.grandenetworks.net> has joined #yocto17:57
*** radsquirrel[m] is now known as radsquirrel[m]118:13
*** radsquirrel[m]1 is now known as radsquirrel[m]218:23
*** radsquirrel[m]2 is now known as radsquirrel[m]18:30
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto18:30
kism@fray how can I go about manually applying the patch? This is my first time. I'm completely new and learning.18:35
fraythis is one area, I'm not sure I can explain over IRC...  there have been Yocto Project classes in the past that talk about this stuff, you might want to search those for more tutorial like steps18:36
fray(I have MY way of doing this, but it's often very different then the general recommended way for new users)18:36
*** wizofe <wizofe!~wizofe@185.52.146.174> has quit IRC18:40
kismI tried adding this on to the .bb file "SRC_URI += "file://example.patch" with the patch in question which i got from a stackoverflow post and I tested the build again and it gave me errors as before. I removed that line and now bitbake hasn't prompted any errors and I'm on task 1442 already.18:41
justintttHello, currently my build sym links /var/log -> volatile/log, how can I remove this link? I would like my log files to persist over reboots.18:42
kismNow I'm confused as to how to continuing the build. Thanks for your help @fray I will look around for more information.18:43
kergothideally we'd be able to use devtool to fix patches, but i think there's still an open issue to get a good workflow for it18:43
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto18:47
*** BubuIIC <BubuIIC!bubuiicmat@gateway/shell/matrix.org/x-qqeaiywltqhzvbkx> has quit IRC18:49
*** BubuIIC <BubuIIC!bubuiicmat@gateway/shell/matrix.org/x-fhjgoekulalkvhtm> has joined #yocto18:49
tprestonI'm trying to install the package "kernel-image-initramfs" into my image, which installs files to /boot. I get an error when the package install tries to overwrite some files which are already there18:59
tprestonln: failed to create symbolic link '/Image': Permission denied18:59
*** rewitt3 <rewitt3!~rewitt@134.134.139.83> has quit IRC18:59
tprestonHow do I tell yocto to prefer the files from "kernel-image-initramfs"? Alternatively, how do find out what package installed those files so I can remove it19:01
JPEWarmpit: a6be8399295203c76d049363b79b3566929ca60b (rm_work: Stop appending _setscene....) in sumo-mnut was reverted on master19:01
JPEWarmpit: It had some issue and was replaced in favor of: https://patchwork.openembedded.org/series/12629/19:02
tprestonthe error is19:04
tprestonCollected errors:19:04
tpreston * check_data_file_clashes: Package kernel-image-image-4.4.38-l4t-r28.2+g41a10d67c1f0 wants to install file /home/tpreston/muos/build/tmp/work/jetson_tx2-poky-linux/resin-image/1.0-r0/rootfs/boot/Image19:04
tprestonBut that file is already provided by package  * kernel-image-initramfs19:04
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.204.77.163.55> has quit IRC19:11
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.204.77.163.55> has joined #yocto19:15
*** armpit <armpit!~armpit@64.2.3.196.ptr.us.xo.net> has joined #yocto19:27
*** hundeboll <hundeboll!~hundeboll@open-mesh.org/catwoman/hundeboll> has quit IRC19:40
tprestonI think I need to remove MACHINE_ESSENTIAL_EXTRA_RDEPENDS_remove = "kernel-image"19:49
tprestonSo that it isn't included in `packagegroup-core-boot`19:50
*** milindur <milindur!~milindur@deimos.ca-soft.de> has quit IRC19:57
*** justinttt <justinttt!49e56612@gateway/web/freenode/ip.73.229.102.18> has quit IRC20:02
*** justinttt <justinttt!49e56612@gateway/web/freenode/ip.73.229.102.18> has joined #yocto20:04
*** milindur <milindur!~milindur@deimos.ca-soft.de> has joined #yocto20:20
*** armpit <armpit!~armpit@64.2.3.196.ptr.us.xo.net> has quit IRC20:42
*** rewitt <rewitt!~rewitt@192.55.54.40> has joined #yocto20:46
*** sgw <sgw!~sgw@134.134.139.74> has joined #yocto20:56
*** wizofe <wizofe!~wizofe@90.255.13.142> has joined #yocto20:58
*** sgw <sgw!~sgw@134.134.139.74> has quit IRC21:01
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:02
*** noway96 <noway96!~noway96@50-244-213-195-static.hfc.comcastbusiness.net> has joined #yocto21:03
*** pabdaddy1995 <pabdaddy1995!4066f914@gateway/web/freenode/ip.64.102.249.20> has joined #yocto21:09
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:09
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:10
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC21:10
pabdaddy1995Does anyone know if you add a HOSTTOOLS_NONFATAL to local.conf that if that binary requires a library it looks for it in build/tmp/?21:10
pabdaddy1995sorry poorly worded21:11
pabdaddy1995if you add a binary to HOSTTOOLS_NONFATAL, lets say confdc, and that confdc requires a library called confdexec it looks for it in build/tmp/lib (which doesn't exist)21:12
pabdaddy1995is there another way to specify where HOSTTOOL_NONFATAL libraries exist?21:12
*** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC21:15
kergothit isn't bitbake looking for libraries21:16
kergothits confdc21:16
kergothdo a readelf -d /path/to/confdc21:16
*** Crofton <Crofton!~Crofton@64.124.121.174> has joined #yocto21:20
pabdaddy1995kergoth:  you're correct and i don't even need to do a readelf because confdc is a script.  So if confdc is a script and referencing a library in a certain location how should I handle that in bitbake?21:21
kergothit sounds like the confdc script it operating relative to $0, and since we symlink it, $0 points to the symlink, not the real script. the script should be checking for that and calling readlink to handle it, but it's not21:22
pabdaddy1995kergoth: wow ur good21:22
kergothI'd do: cd build; mkdir bin; echo '#!/bin/sh' >bin/confdc; echo '/path/to/real/confdc "$@"' >>bin/confdc; PATH="$PWD/bin:$PATH"21:22
kergoththen it's symlinking the wrapper script rather than the real thing21:22
kergothchmod +x bin/confdc too of course21:23
kergothdealing with $0 in a portable way in shell is a pain. it's not even guaranteed to be the absolute path, in some shells it could just be 'confdc' and you'd then have to find it in PATH yourself21:23
* kergoth does a fair bit of scripting21:23
pabdaddy1995let me give this a try21:24
*** stephano <stephano!~stephano@134.134.139.73> has joined #yocto21:27
kergothdamnit, why is linux-yocto failing on me repeatedly21:40
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:41
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:44
pabdaddy1995kergoth: symlinking the wrapper fixed the path problem but now I get a confdc: Cannot Fork error21:47
kergothit's recursing. the wrapper is calling itself21:47
kergothit has to either remove its own location from PATH, or explicitly call the full absolute path of the real binary21:47
kergothhence i had /path/to/real/confdc in the above example21:48
pabdaddy1995ok let me try to fix21:48
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:48
pabdaddy1995kergoth:  my wrapper has the full path to the real confdc binary.  Wrapper in tmp/hosttools/confdc looks like this #!/bin/sh /home/user/confd/bin/confdc "$0"  What is wrong with that?22:05
kergoth$0 is wrong, it's $@22:05
kergothlooks fine otherwise22:05
pabdaddy1995sorry typo here22:05
pabdaddy1995it is $@ in the script22:06
pabdaddy1995just a sec, the wrapper overwrote the one in my home directory22:08
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has quit IRC22:08
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has joined #yocto22:09
pabdaddy1995kergoth:  bitbake seems to be putting the /home/user/confd/bin/confdc in the tmp/hosttools directory even though build/bin/confdc is first in the patch22:11
pabdaddy1995path22:11
*** Crofton <Crofton!~Crofton@64.124.121.174> has quit IRC22:15
*** kism <kism!615a3e9e@gateway/web/freenode/ip.97.90.62.158> has quit IRC22:31
pabdaddy1995kergoth: r u still there?  wrapper script is working but i have another question regarding the use of update-alternatives class22:47
pabdaddy1995kergoth: for example i had a dnf error because two different components were using the same xml file.  However, if I try to use ALTERNATIVE, ALTERNATIVE_LINK_NAME, ALTERNATIVE_TARGET they all seem to default to /usr/bin.  But I need a path to /usr/confd/../../22:49
*** majuk <majuk!~majuk@174-24-35-31.clsp.qwest.net> has quit IRC22:52
kergothgrep -nrI ALTERNATIVE oe-core/meta|grep ':.*/'22:52
*** majuk <majuk!~majuk@174-24-35-31.clsp.qwest.net> has joined #yocto22:52
kergothplenty of usages for paths other than usr/bin there22:52
kergothexisting recipes are always a good reference22:53
*** majuk <majuk!~majuk@174-24-35-31.clsp.qwest.net> has quit IRC22:57
*** armpit <armpit!~armpit@2601:202:4180:c33:c03b:e0c:ade4:e24e> has joined #yocto22:59
*** ChanServ sets mode: +o yocti23:05
*** wizofe_ <wizofe_!~wizofe@90.255.13.142> has joined #yocto23:06
*** wizofe <wizofe!~wizofe@90.255.13.142> has quit IRC23:07
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto23:09
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC23:14
*** georgem <georgem!~georgem@216.21.169.52> has joined #yocto23:14
*** bviecelli <bviecelli!uid275978@gateway/web/irccloud.com/x-kejesvezlqiojubz> has quit IRC23:25
*** fray sets mode: -o fray23:26
*** sjolley_ <sjolley_!86868b48@gateway/web/freenode/ip.134.134.139.72> has joined #yocto23:49
*** sjolley_ <sjolley_!86868b48@gateway/web/freenode/ip.134.134.139.72> has quit IRC23:56

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!