*** rrerolle <rrerolle!~rrerolle@2001:41d0:52:cff::c84> has quit IRC | 00:05 | |
*** hattzy <hattzy!~hatter@h-37-123-162-70.NA.cust.bahnhof.se> has quit IRC | 00:08 | |
*** rrerolle <rrerolle!~rrerolle@2001:41d0:52:cff::c84> has joined #yocto | 00:08 | |
*** wto <wto!~wto@h-136-128.A336.priv.bahnhof.se> has quit IRC | 00:08 | |
*** wto <wto!~wto@h-136-128.A336.priv.bahnhof.se> has joined #yocto | 00:09 | |
*** sgw <sgw!~sgw@134.134.139.74> has joined #yocto | 00:43 | |
*** anujm <anujm!~anujm@192.198.146.171> has quit IRC | 00:53 | |
*** sgw <sgw!~sgw@134.134.139.74> has quit IRC | 00:56 | |
*** sgw <sgw!~sgw@134.134.139.74> has joined #yocto | 00:59 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 00:59 | |
*** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has joined #yocto | 00:59 | |
*** sgw <sgw!~sgw@134.134.139.74> has quit IRC | 01:03 | |
*** sgw <sgw!sgw@nat/intel/x-qvysumtwsocjghxi> has joined #yocto | 01:24 | |
*** stephano <stephano!stephano@nat/intel/x-tstfscqunumzbfew> has joined #yocto | 01:24 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 02:04 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 02:10 | |
*** anujm <anujm!~anujm@192.198.146.173> has joined #yocto | 02:14 | |
-YoctoAutoBuilder- build #1195 of nightly-multilib is complete: Success [build successful] Build details are at https://autobuilder.yocto.io/builders/nightly-multilib/builds/1195 | 02:47 | |
*** pabdaddy <pabdaddy!4066f914@gateway/web/freenode/ip.64.102.249.20> has quit IRC | 02:52 | |
yocti | New 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 IRC | 03:23 | |
*** sgw <sgw!~sgw@134.134.139.75> has joined #yocto | 03:27 | |
*** tgraydon <tgraydon!tgraydon@nat/intel/x-trjnoxuzhjrvpkxy> has quit IRC | 03:37 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 04:05 | |
*** RP <RP!~RP@5751f4a1.skybroadband.com> has quit IRC | 05:38 | |
*** agust <agust!~agust@p50886A63.dip0.t-ipconnect.de> has joined #yocto | 05:46 | |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 06:24 | |
*** fl0v0 <fl0v0!~fvo@i577A6179.versanet.de> has joined #yocto | 06:59 | |
*** frsc <frsc!~frsc@200116b824be2700b3e8714f1f19b702.dip.versatel-1u1.de> has joined #yocto | 07:12 | |
*** frsc <frsc!~frsc@200116b824be2700b3e8714f1f19b702.dip.versatel-1u1.de> has joined #yocto | 07:13 | |
*** anujm <anujm!~anujm@192.198.146.173> has quit IRC | 07:16 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 07:19 | |
*** anujm <anujm!~anujm@192.198.146.173> has joined #yocto | 07:25 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 07:37 | |
*** rajm <rajm!~robertmar@148.252.241.226> has joined #yocto | 07:45 | |
*** otavio <otavio!~otavio@static.203.17.243.136.clients.your-server.de> has quit IRC | 07:45 | |
*** flying_sausages <flying_sausages!~flying_sa@static.88-198-40-49.clients.your-server.de> has quit IRC | 07:45 | |
*** thaytan <thaytan!~thaytan@121-200-23-18.cust.aussiebb.net> has quit IRC | 07:46 | |
*** flying_sausages <flying_sausages!~flying_sa@static.88-198-40-49.clients.your-server.de> has joined #yocto | 07:47 | |
*** thaytan <thaytan!~thaytan@121-200-23-18.cust.aussiebb.net> has joined #yocto | 07:47 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yzwheakiamsudzbr> has joined #yocto | 07:50 | |
*** malanecora <malanecora!b23cc82d@gateway/web/freenode/ip.178.60.200.45> has joined #yocto | 07:55 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto | 08:35 | |
*** frsc <frsc!~frsc@200116b824be2700b3e8714f1f19b702.dip.versatel-1u1.de> has quit IRC | 08:36 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 08:36 | |
*** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC | 08:42 | |
*** frsc <frsc!~frsc@200116b824f53a00953c3d9bce6661a3.dip.versatel-1u1.de> has joined #yocto | 08:53 | |
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has joined #yocto | 09:07 | |
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has quit IRC | 09:11 | |
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has quit IRC | 09:12 | |
*** khem <khem!~khem@unaffiliated/khem> has quit IRC | 09:17 | |
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has joined #yocto | 09:48 | |
kinsifous | Hello | 09:49 |
kinsifous | when i run tests for the qemu, i include the tests on the local.conf and then run bitbake <image> -c testimage | 09:49 |
kinsifous | i added "bb.tests.data.TestConcatOverride.test_remove \" | 09:50 |
kinsifous | which is not a part of the openembedded/openembedded-core/ but openembedded/bitbake | 09:51 |
kinsifous | however, the test is not running and no error is being thrown | 09:51 |
kinsifous | is there any way to add this test to run with the testimage? | 09:52 |
kinsifous | or are the bitbake tests different from testimage? | 09:52 |
*** anujm <anujm!~anujm@192.198.146.173> has quit IRC | 09:56 | |
*** nemunaire <nemunaire!~nemunaire@LFbn-1-9034-200.w86-238.abo.wanadoo.fr> has joined #yocto | 10:04 | |
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 10:05 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 10:09 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 10:09 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 10:13 | |
*** nemunaire <nemunaire!~nemunaire@LFbn-1-9034-200.w86-238.abo.wanadoo.fr> has quit IRC | 10:24 | |
*** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has quit IRC | 10:28 | |
kinsifous | anybody? | 10:36 |
*** RzR <RzR!~RzR@lns-bzn-38-82-253-125-228.adsl.proxad.net> has quit IRC | 10:36 | |
*** RzR <RzR!~RzR@unaffiliated/rzr> has joined #yocto | 10:36 | |
*** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has quit IRC | 10:45 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 10:53 | |
mihai- | kinsifous, they are different | 10:54 |
mihai- | that's a test for bitbake, you can run it with bitbake-selftest | 10:54 |
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has quit IRC | 11:03 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yzwheakiamsudzbr> has quit IRC | 11:04 | |
*** robsta_ <robsta_!sid195711@gateway/web/irccloud.com/x-pjgvyfnbujuahldg> has quit IRC | 11:04 | |
*** rhadye__ <rhadye__!sid217449@gateway/web/irccloud.com/x-kzqovahbqfdjtxdb> has quit IRC | 11:04 | |
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-ynxlunocjkxvkjop> has quit IRC | 11:04 | |
*** mtas__ <mtas__!sid127809@gateway/web/irccloud.com/x-onwrunizvcetfhue> has quit IRC | 11:06 | |
*** rsalveti <rsalveti!sid117878@gateway/web/irccloud.com/x-eaayggnqolxhqjzw> has quit IRC | 11:06 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-qfwsksrzhepgghgw> has joined #yocto | 11:06 | |
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has joined #yocto | 11:06 | |
kinsifous | whoever 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 #yocto | 11:09 | |
malanecora | [12:54] <mihai-> kinsifous, they are different [12:54] <mihai-> that's a test for bitbake, you can run it with bitbake-selftest | 11:13 |
kinsifous | mihai: thank you | 11:13 |
kinsifous | malencora: thanks for the tip | 11:14 |
*** nemunaire <nemunaire!~nemunaire@LFbn-1-9034-200.w86-238.abo.wanadoo.fr> has joined #yocto | 11:14 | |
*** flihp <flihp!~flihp@76.243.124.132> has quit IRC | 11:16 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 11:19 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 11:23 | |
*** sgw <sgw!~sgw@134.134.139.75> has quit IRC | 11:24 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto | 11:25 | |
*** marks__ <marks__!~marks@2a02:810d:640:67a0:e6a4:71ff:fe89:f1e3> has joined #yocto | 11:44 | |
jofr | Perhaps 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 |
jofr | rejects in tools/Makefile and tools/env/Makefile | 11:48 |
jofr | Aaa, nevermind :p | 11:51 |
*** marks__ <marks__!~marks@2a02:810d:640:67a0:e6a4:71ff:fe89:f1e3> has quit IRC | 11:52 | |
*** marks__ <marks__!~marks@2a02:810d:640:67a0:e6a4:71ff:fe89:f1e3> has joined #yocto | 11:52 | |
*** sgw <sgw!~sgw@134.134.139.76> has joined #yocto | 12:17 | |
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has joined #yocto | 12:33 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 12:33 | |
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC | 12:34 | |
*** marks__ <marks__!~marks@2a02:810d:640:67a0:e6a4:71ff:fe89:f1e3> has quit IRC | 12:36 | |
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has quit IRC | 12:37 | |
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC | 12:44 | |
yates | if a recipe foo has a DEPENDS = "bar", then is bar built to completion, or at least through do_deploy(), before foo "runs"? | 12:50 |
yates | i 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 |
yates | i think the answer is just once | 12:52 |
yates | which is why i needed a do_deploy[depends] = "virtual/kernel:do_deploy" in my foo recipe | 12:53 |
yates | or am i not making sense? | 12:56 |
yates | :) | 12:56 |
yates | \/ | 12:59 |
yates | works. | 12:59 |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-qfwsksrzhepgghgw> has quit IRC | 13:05 | |
malanecora | If you have some DEPENDS | 13:05 |
malanecora | The recipe is gonna be built after the do_sysroots/deploy, yes | 13:06 |
malanecora | But the wirte_rpm/package tasks of the dependecy can be executed in parallel | 13:07 |
malanecora | do_deploy[bar] = "virtual/kernel:do_deploy" | 13:08 |
malanecora | Will start to build the recipe after virtual/kernel:do_deploy is completed | 13:09 |
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has joined #yocto | 13:09 | |
yates | i don't understand what the "do_deploy[bar] = "virtual/kernel:do_deploy" syntax means. | 13:11 |
JPEW | yates: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#variable-flags | 13:12 |
yates | i 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) completion | 13:13 |
u1106 | does 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-64 | 13:17 |
u1106 | if not does it ring any bell what could be wrong? | 13:18 |
JPEW | u1106: I think I saw a patch on the mailing list about that.... | 13:18 |
u1106 | JPEW: any keyword I could search for? | 13:18 |
JPEW | rm_work setscene | 13:19 |
yates | i 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-dependencies | 13:19 |
yates | s/run at bitbake/everything run at bitbake/ | 13:20 |
JPEW | u1106: Looks there was a patch, but RP reverted it and did something else | 13:20 |
JPEW | u1106: https://patchwork.openembedded.org/series/12629/ | 13:22 |
yates | JPEW: 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 recipes | 13:23 |
yates | in any case, i'm good. do_deploy[depends] ... does what i want | 13:24 |
u1106 | JPEW: Thanks! Hmm, 19-June, unlikely I have that (in Rocko) | 13:25 |
JPEW | yates: "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 |
yates | yes, that's the "normal" definition, but it doesn't seem to make sense here. | 13:26 |
yates | why does bitbake need to know about runtime dependencies ? | 13:27 |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 13:27 | |
JPEW | yates: 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 on | 13:27 |
yates | aha. now THAT makes sense! thank you! | 13:28 |
*** kaspter <kaspter!~Instantbi@115.194.185.217> has joined #yocto | 13:30 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 13:32 | |
JPEW | yates: 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 |
u1106 | JPEW: $ git log --grep "Simplify looping" --all --oneline | 13:34 |
u1106 | 52b11de rm_work: Simplify looping code | 13:34 |
u1106 | $ git branch -r --contains 52b11deeb921ba20 | 13:34 |
u1106 | upstream/master | 13:34 |
u1106 | upstream/master-next | 13:34 |
u1106 | so 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_initramfs | 13:34 |
u1106 | (rootfs_cpio that is) | 13:36 |
JPEW | u1106: I didn't follow the coversation, I just remember seeing the patches... It looks simple enough that it could get backported? | 13:36 |
u1106 | what mailing list would that have been on? I don't seem to see it on the Yocto list | 13:37 |
JPEW | Here is the original patch (that was reverted): https://patchwork.openembedded.org/series/11989/ | 13:37 |
JPEW | Looks like it did eventually case a problem with filenames being too long | 13:38 |
JPEW | openembedded-core | 13:38 |
yates | JPEW: pretty impressive - i had no idea about all that | 13:42 |
u1106 | Yes 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 an | 13:44 |
u1106 | unrelated issues. The weird filename just raised my attention. Thanks for your help | 13:44 |
u1106 | JPEW: ^^^ | 13:45 |
JPEW | u1106: np | 13:45 |
*** majuk <majuk!~majuk@174-24-35-31.clsp.qwest.net> has joined #yocto | 14:08 | |
*** rajm <rajm!~robertmar@148.252.241.226> has quit IRC | 14:27 | |
*** webreformer <webreformer!~webreform@106.51.23.177> has joined #yocto | 14:38 | |
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC | 14:40 | |
webreformer | Hi All, | 14:40 |
webreformer | How to debug custom yocto layer ? | 14:40 |
webreformer | please provide me some input | 14:41 |
*** kinsifous <kinsifous!53da50f3@gateway/web/freenode/ip.83.218.80.243> has quit IRC | 14:49 | |
*** xtungvu90 <xtungvu90!uid313450@gateway/web/irccloud.com/x-wplwmekoxukycbtd> has joined #yocto | 15:03 | |
*** aehs29 <aehs29!~aehs29@149.199.62.254> has quit IRC | 15:08 | |
*** joaocfernandes <joaocfernandes!~joaocfern@88.157.234.132> has quit IRC | 15:10 | |
yates | webreformer: bitbake <recipe> -e | 15:16 |
yates | ok, 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 |
JPEW | bitbake "data store" (I think there is some better official name) | 15:18 |
yates | JPEW: i see. are the functions like getVarFlag standard python functions or defined in bitbake? if the latter, are they defined somewhere? | 15:19 |
JPEW | No, "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 info | 15:20 |
JPEW | so more to your question, they are defined by bitbake | 15:20 |
yates | thanks - i go dig | 15:21 |
yates | (in the right place) | 15:21 |
JPEW | yates: Be careful, you might find the cookie monster | 15:21 |
kergoth | bitbake/lib/bb/data_smart.py | 15:21 |
yates | thanks! | 15:22 |
kergoth | haha, yeah, it's a bit odd the way it's implemented, an artifact of our performance requirements | 15:22 |
yates | (cookie monsters are welcome...) | 15:22 |
kergoth | cookie monster is how overrides are handled, to avoid scanning the entire datastore to apply them | 15:22 |
yates | or it's not a joke? | 15:22 |
JPEW | No | 15:22 |
fray | in 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 |
kergoth | event handlers have d now too | 15:23 |
fray | as for the things to use.. d.expand, d.getVar, d.getVarFlags, d.setVar, d.setVarFlags are the common ones | 15:23 |
yates | got d? | 15:23 |
yates | :) | 15:23 |
fray | kergoth ahh that got resolved, didn't realize that.. | 15:23 |
kergoth | yeah, 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 |
webreformer | yates, I want to debug my yocto layer running inside board. | 15:24 |
fray | question 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 |
yates | webreformer: gdb? | 15:24 |
yates | depends on what exactly you're debugging | 15:25 |
fray | they are claiming, no they are image settings and can be set in an image context.. and other recipes should not use them | 15:25 |
*** jofr <jofr!~jofr@193.182.166.3> has quit IRC | 15:25 | |
fray | webreformer, gdb is the debugger.. if you are doing kernel debugging (including modules) it is different then userspace debuggings.. | 15:25 |
fray | userspace debugging, usually you want to generate a debug image, and tell gdb to use that debug image (when cross debugging) | 15:25 |
fray | if you are debugging ON the target, then you need to add the debug symbols and sources onto the target image. | 15:26 |
yates | webreformer: you can also do remote debugging using gdb. i've found that to be helpful for embedded linux systems | 15:26 |
*** jofr <jofr!~jofr@193.182.166.3> has joined #yocto | 15:26 | |
fray | yes, that is the typical usage | 15:27 |
kergoth | I agree with you, nothing states they're image only, in fact aren't they already used in packagegroups too? | 15:27 |
webreformer | yates, Yes, i am expecting remote debugging. | 15:27 |
webreformer | Where I can find more relevant information ? | 15:28 |
kergoth | use 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 much | 15:29 |
fray | kergoth, that is exactly what I thought.. | 15:29 |
yates | a 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 |
fray | https://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#platdev-gdb-remotedebug | 15:29 |
fray | (debuggign with GDB) | 15:29 |
fray | whoops.. thats an old manual.. | 15:30 |
fray | let me get you a recent one | 15:30 |
kergoth | yates: that's a very good point, yeah, only work on hardware if you have to | 15:30 |
fray | https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#platdev-gdb-remotedebug | 15:30 |
webreformer | I want to debug custom yocto layer which acts as Application manager | 15:30 |
fray | there 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 |
fray | as well as configure cross-gdb to use the debug symbols from the debug image | 15:31 |
yates | kergoth: right! | 15:31 |
fray | debugging 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 |
webreformer | I want to debug C++ code build by 'layer' ? | 15:32 |
yates | webreformer: what C++ code? | 15:33 |
yates | what layer? | 15:33 |
webreformer | I have custom layer. recipe inside it build C++ code | 15:35 |
fray | follow the last link I posted | 15:35 |
fray | https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#platdev-gdb-remotedebug | 15:35 |
fray | this is how you cross-debug code.. | 15:35 |
fray | it tells you everything you should need to setup the debugging on target, as well as the host, etc | 15:35 |
fray | customer layer doesn't matter.. code is code to the debugger | 15:35 |
fray | 'er.. custom | 15:35 |
webreformer | I don't know exact terminologies here. sorry for that | 15:36 |
fray | the system, including debugging is setup to be extended with custom layers without having to change anything to do debugging.. | 15:36 |
fray | just follow the instructions in the manual. If you have questions about any instructions, ask those.. | 15:36 |
webreformer | sure | 15: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 #yocto | 15:39 | |
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 15:39 | |
*** kaspter <kaspter!~Instantbi@115.194.185.217> has quit IRC | 15:44 | |
*** kaspter <kaspter!~Instantbi@115.194.185.217> has joined #yocto | 15:45 | |
*** frsc <frsc!~frsc@200116b824f53a00953c3d9bce6661a3.dip.versatel-1u1.de> has quit IRC | 15:50 | |
*** dv_ <dv_!~dv@62.178.50.190> has joined #yocto | 15:54 | |
yates | is there a human-readable doc for getVar and getVarFlag? i am not too good with python... | 15:55 |
yates | i guess it's obvoius? | 15:57 |
yates | if 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 #yocto | 16:04 | |
*** CoRfr <CoRfr!~CoRfr@carmd-fwm01.sierrawireless.com> has quit IRC | 16:06 | |
fray | d.getVar(value, [True/False]) -- the optional true/false is do you want the variable expanded or preserved.. True expands.. | 16:13 |
fray | d.getVarFlags(value, flag, [True/False]) flags are variables like: VAR[flag] = 'value' | 16:13 |
fray | d.setVar(variable, value) | 16:13 |
fray | d.setVarFlags(variable, flag, value) | 16:14 |
fray | thats about it.. pretty simple | 16:14 |
yates | what does "expanded" and "preserved" mean? | 16:16 |
fray | variable = "${foobar}" | 16:16 |
fray | foobar = 'foo' | 16:16 |
yates | ah | 16:17 |
fray | d.getVar('variable', False) == "${foobar}" | 16:17 |
fray | d.getVar('variable', True) == "foo" | 16:17 |
yates | got it | 16:17 |
fray | the default value is True BTW | 16:17 |
fray | (at least in any recent versions, it was False until YP 2.0 I believe | 16:17 |
yates | that if foo = 'foo', bar = '${foo}', and 'whatisthis' = '${bar}' ? what would d.getVar('whatisthis', True) return? | 16:19 |
yates | s/that is/what if/ | 16:19 |
yates | i meant s/that if/what if/ | 16:20 |
*** webreformer <webreformer!~webreform@106.51.23.177> has quit IRC | 16:20 | |
yates | is expansion recursive? | 16:21 |
yates | i think this gets into earlly/late expansion? | 16:22 |
*** aehs29 <aehs29!~aehs29@149.199.62.254> has joined #yocto | 16:24 | |
kergoth | yes, expansion is recursive, that would expand to foo | 16:28 |
kergoth | it'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 |
kergoth | i.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 IRC | 16:30 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 16:32 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 16:33 | |
*** wizofe <wizofe!~wizofe@185.52.146.174> has joined #yocto | 16:42 | |
*** kism <kism!615a3e9e@gateway/web/freenode/ip.97.90.62.158> has joined #yocto | 16:43 | |
kism | Hi, 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 IRC | 16:48 | |
*** kism <kism!615a3e9e@gateway/web/freenode/ip.97.90.62.158> has joined #yocto | 16:49 | |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 16:53 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 16:54 | |
kism | how active is this chat? | 16:54 |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 16:58 | |
*** armpit <armpit!~armpit@2601:202:4180:c33:fc8c:8ad2:54e:b231> has quit IRC | 17:01 | |
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 17:01 | |
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 17:04 | |
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 17:06 | |
-YoctoAutoBuilder- build #1197 of nightly-multilib is complete: Success [build successful] Build details are at https://autobuilder.yocto.io/builders/nightly-multilib/builds/1197 | 17:07 | |
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 17:10 | |
kism | hi vmeson | 17:14 |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 17:29 | |
kism | Hi I'm currently running into errors while running my build in bitbake, this is my command: bitbake phytec-headless-image -c populate_sdk | 17:34 |
kism | im getting a fuction failed: patch_do_patch | 17:35 |
kergoth | that doesn't tell us much of anything, you need to post the actual error log, ideally to a pastebin | 17:36 |
kism | ok https://pastebin.com/4CnYvpnF | 17:37 |
kism | thats my error output | 17:38 |
kism | this is my log file of failure https://pastebin.com/dBdrBfMJ | 17:42 |
*** sgw <sgw!~sgw@134.134.139.76> has quit IRC | 17:50 | |
fray | last file indicates you have a patch from the meta-phytex layer that does not apply | 17:51 |
fray | you need to manually apply it and fix the patch it references.. | 17:51 |
fray | patch in question is located at: /opt/PHYTEC_BSPs/yocto_ti/sources/poky/../meta-phytec/recipes-bsp/barebox/files/0001-Makefile-add-TARGETCC.patch | 17:52 |
*** ntl <ntl!~nathanl@65-36-80-8.dyn.grandenetworks.net> has joined #yocto | 17:57 | |
*** radsquirrel[m] is now known as radsquirrel[m]1 | 18:13 | |
*** radsquirrel[m]1 is now known as radsquirrel[m]2 | 18:23 | |
*** radsquirrel[m]2 is now known as radsquirrel[m] | 18:30 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 18: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 |
fray | this 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 steps | 18: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 IRC | 18:40 | |
kism | I 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 |
justinttt | Hello, 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 |
kism | Now I'm confused as to how to continuing the build. Thanks for your help @fray I will look around for more information. | 18:43 |
kergoth | ideally 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 it | 18:43 |
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto | 18:47 | |
*** BubuIIC <BubuIIC!bubuiicmat@gateway/shell/matrix.org/x-qqeaiywltqhzvbkx> has quit IRC | 18:49 | |
*** BubuIIC <BubuIIC!bubuiicmat@gateway/shell/matrix.org/x-fhjgoekulalkvhtm> has joined #yocto | 18:49 | |
tpreston | I'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 there | 18:59 |
tpreston | ln: failed to create symbolic link '/Image': Permission denied | 18:59 |
*** rewitt3 <rewitt3!~rewitt@134.134.139.83> has quit IRC | 18:59 | |
tpreston | How 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 it | 19:01 |
JPEW | armpit: a6be8399295203c76d049363b79b3566929ca60b (rm_work: Stop appending _setscene....) in sumo-mnut was reverted on master | 19:01 |
JPEW | armpit: It had some issue and was replaced in favor of: https://patchwork.openembedded.org/series/12629/ | 19:02 |
tpreston | the error is | 19:04 |
tpreston | Collected 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/Image | 19:04 |
tpreston | But that file is already provided by package * kernel-image-initramfs | 19:04 |
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.204.77.163.55> has quit IRC | 19:11 | |
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.204.77.163.55> has joined #yocto | 19:15 | |
*** armpit <armpit!~armpit@64.2.3.196.ptr.us.xo.net> has joined #yocto | 19:27 | |
*** hundeboll <hundeboll!~hundeboll@open-mesh.org/catwoman/hundeboll> has quit IRC | 19:40 | |
tpreston | I think I need to remove MACHINE_ESSENTIAL_EXTRA_RDEPENDS_remove = "kernel-image" | 19:49 |
tpreston | So that it isn't included in `packagegroup-core-boot` | 19:50 |
*** milindur <milindur!~milindur@deimos.ca-soft.de> has quit IRC | 19:57 | |
*** justinttt <justinttt!49e56612@gateway/web/freenode/ip.73.229.102.18> has quit IRC | 20:02 | |
*** justinttt <justinttt!49e56612@gateway/web/freenode/ip.73.229.102.18> has joined #yocto | 20:04 | |
*** milindur <milindur!~milindur@deimos.ca-soft.de> has joined #yocto | 20:20 | |
*** armpit <armpit!~armpit@64.2.3.196.ptr.us.xo.net> has quit IRC | 20:42 | |
*** rewitt <rewitt!~rewitt@192.55.54.40> has joined #yocto | 20:46 | |
*** sgw <sgw!~sgw@134.134.139.74> has joined #yocto | 20:56 | |
*** wizofe <wizofe!~wizofe@90.255.13.142> has joined #yocto | 20:58 | |
*** sgw <sgw!~sgw@134.134.139.74> has quit IRC | 21:01 | |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:02 | |
*** noway96 <noway96!~noway96@50-244-213-195-static.hfc.comcastbusiness.net> has joined #yocto | 21:03 | |
*** pabdaddy1995 <pabdaddy1995!4066f914@gateway/web/freenode/ip.64.102.249.20> has joined #yocto | 21:09 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 21:09 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 21:10 | |
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 21:10 | |
pabdaddy1995 | Does 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 |
pabdaddy1995 | sorry poorly worded | 21:11 |
pabdaddy1995 | if 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 |
pabdaddy1995 | is there another way to specify where HOSTTOOL_NONFATAL libraries exist? | 21:12 |
*** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC | 21:15 | |
kergoth | it isn't bitbake looking for libraries | 21:16 |
kergoth | its confdc | 21:16 |
kergoth | do a readelf -d /path/to/confdc | 21:16 |
*** Crofton <Crofton!~Crofton@64.124.121.174> has joined #yocto | 21:20 | |
pabdaddy1995 | kergoth: 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 |
kergoth | it 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 not | 21:22 |
pabdaddy1995 | kergoth: wow ur good | 21:22 |
kergoth | I'd do: cd build; mkdir bin; echo '#!/bin/sh' >bin/confdc; echo '/path/to/real/confdc "$@"' >>bin/confdc; PATH="$PWD/bin:$PATH" | 21:22 |
kergoth | then it's symlinking the wrapper script rather than the real thing | 21:22 |
kergoth | chmod +x bin/confdc too of course | 21:23 |
kergoth | dealing 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 yourself | 21:23 |
* kergoth does a fair bit of scripting | 21:23 | |
pabdaddy1995 | let me give this a try | 21:24 |
*** stephano <stephano!~stephano@134.134.139.73> has joined #yocto | 21:27 | |
kergoth | damnit, why is linux-yocto failing on me repeatedly | 21:40 |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 21:41 | |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 21:44 | |
pabdaddy1995 | kergoth: symlinking the wrapper fixed the path problem but now I get a confdc: Cannot Fork error | 21:47 |
kergoth | it's recursing. the wrapper is calling itself | 21:47 |
kergoth | it has to either remove its own location from PATH, or explicitly call the full absolute path of the real binary | 21:47 |
kergoth | hence i had /path/to/real/confdc in the above example | 21:48 |
pabdaddy1995 | ok let me try to fix | 21:48 |
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 21:48 | |
pabdaddy1995 | kergoth: 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 |
kergoth | looks fine otherwise | 22:05 |
pabdaddy1995 | sorry typo here | 22:05 |
pabdaddy1995 | it is $@ in the script | 22:06 |
pabdaddy1995 | just a sec, the wrapper overwrote the one in my home directory | 22:08 |
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has quit IRC | 22:08 | |
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has joined #yocto | 22:09 | |
pabdaddy1995 | kergoth: 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 patch | 22:11 |
pabdaddy1995 | path | 22:11 |
*** Crofton <Crofton!~Crofton@64.124.121.174> has quit IRC | 22:15 | |
*** kism <kism!615a3e9e@gateway/web/freenode/ip.97.90.62.158> has quit IRC | 22:31 | |
pabdaddy1995 | kergoth: r u still there? wrapper script is working but i have another question regarding the use of update-alternatives class | 22:47 |
pabdaddy1995 | kergoth: 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 IRC | 22:52 | |
kergoth | grep -nrI ALTERNATIVE oe-core/meta|grep ':.*/' | 22:52 |
*** majuk <majuk!~majuk@174-24-35-31.clsp.qwest.net> has joined #yocto | 22:52 | |
kergoth | plenty of usages for paths other than usr/bin there | 22:52 |
kergoth | existing recipes are always a good reference | 22:53 |
*** majuk <majuk!~majuk@174-24-35-31.clsp.qwest.net> has quit IRC | 22:57 | |
*** armpit <armpit!~armpit@2601:202:4180:c33:c03b:e0c:ade4:e24e> has joined #yocto | 22:59 | |
*** ChanServ sets mode: +o yocti | 23:05 | |
*** wizofe_ <wizofe_!~wizofe@90.255.13.142> has joined #yocto | 23:06 | |
*** wizofe <wizofe!~wizofe@90.255.13.142> has quit IRC | 23:07 | |
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto | 23:09 | |
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 23:14 | |
*** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 23:14 | |
*** bviecelli <bviecelli!uid275978@gateway/web/irccloud.com/x-kejesvezlqiojubz> has quit IRC | 23:25 | |
*** fray sets mode: -o fray | 23:26 | |
*** sjolley_ <sjolley_!86868b48@gateway/web/freenode/ip.134.134.139.72> has joined #yocto | 23:49 | |
*** sjolley_ <sjolley_!86868b48@gateway/web/freenode/ip.134.134.139.72> has quit IRC | 23:56 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!