Friday, 2018-03-16

*** nighty- <nighty-!> has quit IRC00:04
*** welhm_ <welhm_!> has quit IRC00:09
*** welhm_ <welhm_!> has joined #yocto00:10
*** kpo__ <kpo__!> has joined #yocto00:11
*** bluelightning <bluelightning!~paul@> has joined #yocto00:23
*** bluelightning <bluelightning!~paul@> has quit IRC00:23
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto00:23
*** RP1 <RP1!> has quit IRC00:31
*** sjolley <sjolley!~sjolley@> has joined #yocto00:41
*** vmesons <vmesons!> has joined #yocto00:42
*** vmeson <vmeson!> has quit IRC00:42
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:48
*** learningc <learningc!> has joined #yocto00:57
*** sjolley <sjolley!~sjolley@> has quit IRC01:03
*** vmeson <vmeson!> has joined #yocto01:07
*** vmesons <vmesons!> has quit IRC01:07
*** joeythesaint <joeythesaint!~joe@2605:6400:2:fed5:22:41:45ec:bf91> has quit IRC01:08
*** joeythesaint <joeythesaint!> has joined #yocto01:08
*** nighty- <nighty-!> has joined #yocto01:10
*** nathani__ <nathani__!> has joined #yocto01:14
*** nathani_ <nathani_!> has quit IRC01:15
*** CoRfr <CoRfr!> has quit IRC01:15
*** CoRfr <CoRfr!> has joined #yocto01:15
*** sgw <sgw!> has joined #yocto01:20
*** sgw1 <sgw1!~swold@> has joined #yocto01:22
*** sgw <sgw!> has quit IRC01:24
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC01:24
*** sgw1 is now known as sgw01:25
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto01:59
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC02:33
*** bluelightning <bluelightning!paul@nat/intel/x-bdqxvnmczzgrnxoi> has joined #yocto03:27
*** bluelightning <bluelightning!paul@nat/intel/x-bdqxvnmczzgrnxoi> has quit IRC03:27
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has joined #yocto03:27
*** kpo__ <kpo__!> has quit IRC03:28
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has quit IRC03:58
*** RP <RP!> has joined #yocto04:05
*** thaytan_ is now known as thaytan04:38
-YoctoAutoBuilder- build #337 of nightly-musl-x86-64 is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #848 of buildtools is complete: Failure [failed BuildImages_1 BuildImages_2] Build details are at
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:12
*** AndersD <AndersD!> has joined #yocto05:12
*** agust <agust!> has joined #yocto05:22
*** behanw <behanw!uid110099@gateway/web/> has quit IRC05:23
*** Crofton <Crofton!~Crofton@2601:1c0:5201:42f2:3f76:16bb:a71:1d39> has joined #yocto05:27
*** armpit <armpit!> has joined #yocto05:49
*** bluelightning <bluelightning!paul@nat/intel/x-utkkvvhknejqewxg> has joined #yocto05:58
*** bluelightning <bluelightning!paul@nat/intel/x-utkkvvhknejqewxg> has quit IRC05:58
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has joined #yocto05:58
-YoctoAutoBuilder- build #883 of nightly-multilib is complete: Failure [failed BuildImages_2 Running Sanity Tests_2] Build details are at
*** gtristan <gtristan!~tristanva@> has joined #yocto06:05
*** t0mmy <t0mmy!> has quit IRC06:09
-YoctoAutoBuilder- build #866 of nightly-arm-lsb is complete: Success [build successful] Build details are at
yoctiNew news from stackoverflow: OS Updating in Yocto <>06:21
-YoctoAutoBuilder- build #844 of nightly-arm64 is complete: Success [build successful] Build details are at
*** t0mmy <t0mmy!~tprrt@> has joined #yocto06:29
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has quit IRC06:36
*** tuupola <tuupola!> has joined #yocto06:54
*** pohly <pohly!> has joined #yocto07:05
*** Bunio_FH <Bunio_FH!> has quit IRC07:17
*** open-nandra_ <open-nandra_!~marek@> has joined #yocto07:21
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:31
*** varjag <varjag!> has joined #yocto07:32
*** TobSnyder <TobSnyder!> has joined #yocto07:34
*** TobSnyder <TobSnyder!> has quit IRC07:37
*** TobSnyder <TobSnyder!> has joined #yocto07:38
*** Noor <Noor!~quassel@> has quit IRC07:43
*** pidge <pidge!~pidge@2001:41d0:a:5dc5::> has joined #yocto07:44
*** Noor <Noor!~quassel@> has joined #yocto07:44
*** abelal <abelal!~quassel@> has quit IRC07:44
*** abelal <abelal!~quassel@> has joined #yocto07:46
*** rajm <rajm!> has joined #yocto07:46
*** pidge <pidge!~pidge@2001:41d0:a:5dc5::> has quit IRC07:52
*** wto <wto!> has quit IRC07:55
*** rajm <rajm!> has quit IRC07:58
-YoctoAutoBuilder- build #867 of nightly-qa-extras is complete: Failure [failed BuildImages_3] Build details are at
*** morphis <morphis!> has joined #yocto08:09
*** Bunio_FH <Bunio_FH!> has joined #yocto08:15
*** bluelightning <bluelightning!paul@nat/intel/x-hhsksvfuaefxssvt> has joined #yocto08:18
*** bluelightning <bluelightning!paul@nat/intel/x-hhsksvfuaefxssvt> has quit IRC08:18
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:18
*** yann <yann!> has quit IRC08:24
-YoctoAutoBuilder- build #915 of nightly-oe-selftest is complete: Failure [failed Running oe-selftest] Build details are at
*** bluelightning <bluelightning!paul@pdpc/supporter/professional/bluelightning> has quit IRC09:02
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto09:08
eduardas_mhello, can I use SRC_URI to fetch a binary blob from a locally mounted Samba share (using file://) ?09:12
eduardas_mhere is my recipe:
eduardas_mit does not seem to work, although the fetch stage does not fail09:14
eduardas_mwhen I check stuff in tmp/work, it does not contain the firmware file09:15
neverpaniceduardas_m: That should work, although the fetcher might end up not copying local files as an optimization09:18
eduardas_mneverpanic: this is the error that I get:
*** yann <yann!~yann@> has joined #yocto09:22
eduardas_mneverpanic: oh, it seems the blob is not copied directly to the work directory, but inside a certain directory hierarchy09:23
eduardas_mit appears under tmp/work/all-fod-linux/amped-rf-firmware/161215D-r0/home/eduardas/NAS_SOFTWARE/linux/binary_blobs/amped_rf/BT53H_161215D.bin09:25
eduardas_mhonestly, that was kind of counter-intuitive for me09:25
eduardas_mwhat is the point in replicating the full local path inside tmp/work?09:26
neverpanicfiles from different directories could have the same names, leading to conflicts?09:27
neverpanicthere's probably a flag you can set to determine the output file name09:27
*** skz81 <skz81!> has joined #yocto09:31
*** Flow86 <Flow86!> has quit IRC09:32
*** Flow86 <Flow86!> has joined #yocto09:32
*** otavio <otavio!> has quit IRC09:32
*** otavio <otavio!> has joined #yocto09:33
*** rburton <rburton!> has joined #yocto09:40
*** falk0n <falk0n!> has joined #yocto09:47
*** rajm <rajm!~robertmar@> has joined #yocto09:48
*** rodgort <rodgort!> has quit IRC09:57
*** xtron <xtron!~xtron@> has quit IRC09:58
*** rodgort <rodgort!> has joined #yocto10:02
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:11
*** nighty- <nighty-!> has quit IRC10:20
*** xtron <xtron!~xtron@> has joined #yocto10:22
*** Kakounet <Kakounet!> has quit IRC10:30
*** Kakounet <Kakounet!> has joined #yocto10:37
*** TobSnyder <TobSnyder!> has quit IRC10:50
*** TobSnyder <TobSnyder!> has joined #yocto10:51
*** learningc <learningc!> has quit IRC11:07
*** Kakounet <Kakounet!> has quit IRC11:13
*** Kakounet <Kakounet!> has joined #yocto11:21
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC11:24
*** Bunio_FH <Bunio_FH!> has quit IRC11:25
*** mmathen <mmathen!~manumanum@> has joined #yocto11:26
*** manum <manum!~androirc@> has joined #yocto11:33
*** manum <manum!~androirc@> has joined #yocto11:35
*** TobSnyder <TobSnyder!> has quit IRC11:37
*** luneff <luneff!~yury@> has joined #yocto11:45
*** mmathen <mmathen!~manumanum@> has quit IRC11:49
*** kaspter <kaspter!~Instantbi@> has quit IRC11:49
*** kaspter <kaspter!~Instantbi@> has joined #yocto11:50
-YoctoAutoBuilder- build #849 of buildtools is complete: Success [build successful] Build details are at
*** gtristan <gtristan!~tristanva@> has quit IRC11:59
*** welhm_ <welhm_!> has quit IRC12:14
*** nortor <nortor!> has joined #yocto12:16
*** welhm <welhm!> has joined #yocto12:18
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto12:23
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC12:25
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto12:25
*** aratiu <aratiu!~adi@> has quit IRC12:29
*** gtristan <gtristan!~tristanva@> has joined #yocto12:33
*** aratiu <aratiu!~adi@> has joined #yocto12:39
*** wto <wto!> has joined #yocto12:49
yoctiNew news from stackoverflow: Building packages to yocto image (image) without using recipes <>12:52
*** wto <wto!> has quit IRC12:54
*** Adam___ <Adam___!0c30d402@gateway/web/freenode/ip.> has quit IRC13:03
*** marka <marka!~masselst@> has joined #yocto13:14
*** morphis_ <morphis_!> has joined #yocto13:20
*** morphis <morphis!> has quit IRC13:24
*** wto <wto!> has joined #yocto13:28
*** JPEW <JPEW!cc4da337@gateway/web/freenode/ip.> has joined #yocto13:39
*** armpit <armpit!> has quit IRC13:46
*** nighty- <nighty-!> has joined #yocto13:48
*** hamis_lt_u <hamis_lt_u!~irfan@> has quit IRC14:07
*** luneff <luneff!~yury@> has quit IRC14:09
*** Crofton <Crofton!~Crofton@2601:1c0:5201:42f2:3f76:16bb:a71:1d39> has quit IRC14:25
*** Crofton <Crofton!~Crofton@2601:1c0:5201:42f2:3f76:16bb:a71:1d39> has joined #yocto14:26
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:27
*** open-nandra_ <open-nandra_!~marek@> has quit IRC14:29
*** oob <oob!> has joined #yocto14:35
*** zeddii <zeddii!> has joined #yocto14:35
*** paulg_ <paulg_!~paulg@> has quit IRC14:37
*** zeddiii <zeddiii!~bruce@> has quit IRC14:37
*** paulg_ <paulg_!~paulg@> has joined #yocto14:41
*** zeddiii <zeddiii!~bruce@> has joined #yocto14:41
*** stephano <stephano!~stephano@> has joined #yocto14:43
*** oob <oob!> has quit IRC14:45
*** zeddii <zeddii!> has quit IRC14:45
lukmaIf I may ask :)14:46
lukmaMy recipe is producing static library -> libfoo.a14:47
lukmano libfoo.so14:47
lukmaIt is correctly placed in /usr/lib/14:47
lukmaon foo/<version>/image14:47
lukmaif I build image wihich includes: include image_class.bb14:48
lukmaI do need to put14:48
lukmaRDEPENDS_${PN}-staticdev = "${PN}-dev"14:48
lukmaRDEPENDS_${PN}-dev = ""14:48
lukmain the recipe file14:48
lukma then, when I add foo-staticdev to packageroup14:49
lukmathe libfoo.a is installed14:49
lukmaWhy there is a dependency between -dev and -staticdev?14:49
lukmasome projects produce only static libraries14:49
lukmaCan somebody know what was the rationale behind this?14:50
*** kaspter <kaspter!~Instantbi@> has quit IRC15:05
*** vmeson <vmeson!> has quit IRC15:07
*** bluelightning <bluelightning!~paul@> has joined #yocto15:25
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto15:25
*** oob <oob!> has joined #yocto15:26
*** zeddii <zeddii!> has joined #yocto15:26
*** AndersD <AndersD!> has quit IRC15:27
*** zeddiii <zeddiii!~bruce@> has quit IRC15:29
*** paulg_ <paulg_!~paulg@> has quit IRC15:29
*** Nilesh__ <Nilesh__!uid116340@gateway/web/> has joined #yocto15:31
*** paulg_ <paulg_!~paulg@> has joined #yocto15:32
*** zeddiii <zeddiii!~bruce@> has joined #yocto15:32
*** zeddii <zeddii!> has quit IRC15:36
*** oob <oob!> has quit IRC15:36
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC15:42
*** WillMiles <WillMiles!> has joined #yocto15:45
*** rubdos <rubdos!> has quit IRC15:48
rburtonlukma: do you mean why is there a dependency on -dev from -staticdev?15:49
lukmarburton: Yes15:49
rburtonbecause a staticdev is no good without the headers which are in the -dev15:49
lukmaAch , ok, so headers are integral part of -dev15:49
rburtonyou *could* put the headers in the staticdev but that would just cause more pain and be unexpected behaviour15:50
neverpanicI'm really wondering what your usecase for shipping a *.a file in an image is, though.15:50
lukmarburton: And why I need to put this line in my recipe?15:50
lukma RDEPENDS_${PN}-dev = ""15:50
lukmaTo erase the -dev package (if I only produce *.a library)15:50
rburtonbecause we assume that you generate a PN15:51
rburtonif you don't then unset that15:51
rburtonthe staticdev -> dev dependency is a default one so you can drop that from the recipe15:51
lukmaneverpanic: I do have a project which produces *.a as its output.....15:52
lukmaat least this is what I got after following README and default cmake settings15:52
neverpaniclukma: Sure, but what's the point of having that on the image? *.a files are static libraries, so you'd need a compiler to use them?15:52
rburtonif its a development image for building *on* that makes sense15:52
rburtonotherwise its a massive waste of space15:52
*** rovanceo__ <rovanceo__!~rovanceo@> has joined #yocto15:53
lukmarburton: Those *.a libraries could be :15:54
lukma1. used on the target image for building (rare case) or15:54
lukma2. *.a would be a part of eSDK/SDK15:54
*** zeddii_home_ <zeddii_home_!> has joined #yocto15:54
*** miceopede_ <miceopede_!sid140053@gateway/web/> has joined #yocto15:55
*** clopez <clopez!> has quit IRC15:56
*** erbo_ <erbo_!> has joined #yocto15:56
*** sa2ajj <sa2ajj!> has joined #yocto15:56
*** hundebol1 <hundebol1!> has joined #yocto15:58
*** hundebol1 <hundebol1!> has joined #yocto15:58
*** stryx`_ <stryx`_!~stryx@> has joined #yocto15:58
*** cpo_ <cpo_!> has joined #yocto15:58
*** clopez_ <clopez_!> has joined #yocto15:59
*** rumble <rumble!~grumble@freenode/staff/grumble> has joined #yocto15:59
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC15:59
*** sa2ajj_ <sa2ajj_!~quassel@> has quit IRC16:03
*** zeddii_home <zeddii_home!> has quit IRC16:03
*** rovanceo_ <rovanceo_!~rovanceo@> has quit IRC16:03
*** cpo <cpo!> has quit IRC16:03
*** grumble <grumble!~grumble@freenode/staff/grumble> has quit IRC16:03
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC16:03
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC16:03
*** miceopede <miceopede!sid140053@gateway/web/> has quit IRC16:03
*** erbo <erbo!> has quit IRC16:03
*** gabrbedd <gabrbedd!> has quit IRC16:03
*** hundeboll <hundeboll!> has quit IRC16:03
*** zeddii_home_ is now known as zeddii_home16:03
*** miceopede_ is now known as miceopede16:03
*** rumble is now known as grumble16:03
-YoctoAutoBuilder- build #884 of nightly-multilib is complete: Success [build successful] Build details are at
*** stryx`_ <stryx`_!~stryx@> has quit IRC16:12
*** stryx`_ <stryx`_!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto16:12
*** stryx`_ is now known as stryx`16:13
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:17
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto16:18
*** gabrbedd <gabrbedd!> has joined #yocto16:18
*** vladzouth <vladzouth!500c5411@gateway/web/freenode/ip.> has joined #yocto16:21
*** armpit <armpit!> has joined #yocto16:26
vladzouthhello, how to modify the rootfs format in order to have it in tgz format ?16:28
lukmaIs there any workaround / fix for
lukmaPoint 2 ?>16:28
lukmaThe "ERROR: Unexecuted tasks found in preparation log:" in eSDK16:29
-YoctoAutoBuilder- build #950 of nightly is complete: Success [build successful] Build details are at
eduardas_mvladzouth: something like IMAGE_FSTYPES += " tar.gz" in your image recipe16:30
eduardas_mvladzouth: note the space right before tar.gz16:30
eduardas_mwhat is the proper way to have a production kernel and a testing kernel in my BSP... do I need to create a machine definition for each case or is there a better way?16:32
eduardas_mbecause I do not need DEBUG_FS enabled for production use for example, but that is useful to have if I want to use powertop during development16:34
vladzoutheduardas_m: i did this in my local.conf but it does'nt change anything i still have rootfs in tar.bz2 format16:35
eduardas_mvladzouth: can you paste your local.conf to pastebin?16:37
*** nerdboy <nerdboy!> has joined #yocto16:37
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:37
*** rubdos <rubdos!> has joined #yocto16:37
vladzoutheduardas_m: here is the link
eduardas_mvladzouth: are you sure your image was rebuilt? I usually am paranoid and do a "bitbake <image-name> -c cleanall" and only then a "bitbake <image-name>"16:39
eduardas_mvladzouth: missing "S"16:40
eduardas_mvladzouth: "IMAGE_FSTYPES"16:40
eduardas_mvladzouth: not "IMAGE_FSTYPE"16:40
*** armpit <armpit!> has quit IRC16:41
eduardas_mvladzouth: bitbake does not say anything about variables you add that have names it does not process and then eventually do not get used16:42
vladzouthedeouardas_m: Ok, thank you!16:42
eduardas_mquite sad, since it really does not catch cases when variables simply get misspelled16:42
eduardas_mhappened to me too16:42
eduardas_mvladzouth: no problem16:43
*** skz81 <skz81!> has quit IRC16:44
vladzoutheduardas_m: it still generate the rootfs in tar.bz2 format. is there anything else to add?16:47
sveinseAny of you had any experience with using Azure for yocto builds?16:48
eduardas_mvladzouth: it should still generate tar.bz2 if the image recipe you are using demands it, but if you add IMAGE_FSTYPES += " tar.gz" to local.conf, you should also get tar.gz in the deploy directory16:50
eduardas_mvladzouth: += means it will still generate all image types you used to generate previously16:53
eduardas_mvladzouth: just now you should get an additional one... are you sure there really is no tar.gz in deploy/images directory? I would find it kind of odd16:54
vladzouthOk i am going to look at my local.conf if there is something that i miss16:54
vladzoutheduardas_m: there is modules file which is in tgz format but nothing else16:56
eduardas_mvladzouth: try bitbake -e <your image> | grep IMAGE_FSTYPES and tell what you get16:57
eduardas_mvladzouth: if there is no tar.gz in the output, it means four addition to local.conf does not become valid for some reason16:58
eduardas_m"your addition", I mean16:58
eduardas_malso, my solution works on Yocto 2.4, not sure since which Yocto release tar.gz is a valid image type17:00
vladzoutheduardas_m: here is the result
kergothRP: hmm, not sure if this'd be useful or not: - searches paths for pathnames matching the specified wildcards, still returning just the first for each, relative to the search path. might be a better way to handle wildcards in file uris. I just used it to improve my class that grabs postinst intercepts from layers. function arguments align with shutil.which()17:03
eduardas_mvladzouth: on line 11 there is IMAGE_FSTYPES="tar.bz2", if your addition in local.conf would get processed, you should have gotten IMAGE_FSTYPES="tar.bz2 tar.gz".. at least I would expect that17:03
vladzoutheduardas_m: haa, so the bitbake parsing variable isn't work well17:05
eduardas_mvladzouth: not really sure why bitbake could ignore stuff in local.conf if it is written correctly17:05
rburtonvladzouth: bitbake -e <imagename>|less, search for IMAGE_FSTYPES, then scroll up a bit and you'll get a breakdown of what assignments happened.17:06
rburtonvladzouth: my guess is your += in local.conf gets overwritten by a BSP which uses =17:07
rburton(and is parsed after local.conf)17:07
rburtonso the solution would be to use _append in local.conf17:07
vladzoutheduardas_m: Ok, i am going to try that.17:08
vladzouthrburton: is that the same thing for all variable in local.conf?17:09
eduardas_mrburton: I honestly kind of always assumed local.conf takes top priority during parsing... so it can be overriden by a recipe after all? then what priority does local.conf actually have?17:10
*** ski7777 <ski7777!> has quit IRC17:10
rburtoneduardas_m: read bitbake.conf to find out17:10
rburton(it doesn't happen last)17:10
rburtonbecause it sets default values for a lot of things...17:11
eduardas_mrburton: useful info, thank you17:11
vladzouthok, i understand.17:11
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC17:11
vladzouthi confirm, it works !17:11
vladzouththank you !17:12
*** RP <RP!> has quit IRC17:12
*** ski7777 <ski7777!> has joined #yocto17:14
*** ski7777 <ski7777!> has quit IRC17:22
*** rajm <rajm!~robertmar@> has quit IRC17:27
*** ski7777 <ski7777!> has joined #yocto17:49
*** Nilesh__ <Nilesh__!uid116340@gateway/web/> has quit IRC17:50
*** vladzouth <vladzouth!500c5411@gateway/web/freenode/ip.> has quit IRC17:51
*** yann <yann!~yann@> has quit IRC17:52
*** manum <manum!~androirc@> has quit IRC17:54
sveinseare all of you running yocto builds on your own metal, or does any of you use any cloud computing for it?17:56
*** ski7777 <ski7777!> has quit IRC18:02
*** ski7777 <ski7777!> has joined #yocto18:02
Croftonsveinse, I've heard of people using cloud machines18:02
Croftonespecially for intermittent use, so they can leave it off a lot18:02
sveinseCrofton: Yeah. I've been analyzing our computing needs and with proper on/off control, it can we worth it18:04
sveinseEsp. as our IT deparment don't want anything else than windows in their farm, so our Linux buildserver is being frowned heavily upon.18:04
*** vmeson <vmeson!> has joined #yocto18:07
CroftonIT departments are a curse on productivity18:17
-YoctoAutoBuilder- build #916 of nightly-oe-selftest is complete: Success [build successful] Build details are at
sveinseCrofton: yeah. I'm working in a non-linux/unix work environment, so we're pretty alone with this product18:30
*** Crofton <Crofton!~Crofton@2601:1c0:5201:42f2:3f76:16bb:a71:1d39> has quit IRC18:34
seebsmy build stuff is mostly local on my laptop, if i were doing more, i might well be using cloud stuff.18:37
*** dreyna <dreyna!> has joined #yocto18:38
-YoctoAutoBuilder- build #870 of nightly-qa-extras is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #871 of nightly-qa-extras is complete: Failure [failed Running Sanity Tests_7] Build details are at
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto19:08
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC19:20
*** RP1 <RP1!~RP@> has joined #yocto19:23
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto19:25
*** everlook <everlook!> has joined #yocto19:26
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC19:28
*** yann <yann!> has joined #yocto19:39
*** dreyna <dreyna!> has quit IRC19:59
RP1kergoth: interesting. We do need to track where we searched even if we didn't match too...20:05
*** dreyna <dreyna!> has joined #yocto20:05
RP1kergoth: [so we can change the hash if some file appears earlier in the search path meaning we need to rebuild]20:06
kergothRP1: yep, it does. there's a history/candidate list for each file found by the globbing20:09
kergothbasically just a wildcard/glob version of our existing which()20:10
RP1kergoth: ok, I'm not thinking straight with travel at this point ;-)20:16
kergothno worries, just did it on a whim and figured i'd get an opinion, i'll open an issue20:16
*** ski7777 <ski7777!> has quit IRC20:21
*** ski7777 <ski7777!> has joined #yocto20:24
*** everlook <everlook!> has left #yocto20:24
*** ski7777 <ski7777!> has quit IRC20:25
*** ski4x7 <ski4x7!> has joined #yocto20:25
*** RP1 <RP1!~RP@> has quit IRC20:28
*** t0mmy <t0mmy!~tprrt@> has quit IRC20:28
-YoctoAutoBuilder- build #851 of buildtools is complete: Failure [failed BuildImages BuildImages_1 BuildImages_2] Build details are at
*** fancer <fancer!sid180736@gateway/web/> has joined #yocto21:04
*** jae <jae!95c73efe@gateway/web/freenode/ip.> has joined #yocto21:05
*** jae is now known as Guest2693921:05
*** falk0n <falk0n!> has quit IRC21:05
Guest26939Hi, I added another meta-layer where I am trying to add to oeqa,  i have a /lib/oeqa/controllers path.  If I include this layer, do_testimage fails complaining that it cant find module oeqa.core because its looking in my layer and not seeing a oeqa/core. pretty sure this is whats happening because if I dont include this layer in the bb file, its runs fine. think i am missing something, any ideas?21:06
-YoctoAutoBuilder- build #847 of nightly-arm64 is complete: Failure [failed Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 BuildImages_1 Running ESDK Sanity Tests] Build details are at
-YoctoAutoBuilder- build #899 of nightly-x86-64 is complete: Failure [failed Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 BuildImages_2 Running ESDK Sanity Tests] Build details are at
*** morphis_ <morphis_!> has quit IRC21:10
*** ntl <ntl!> has quit IRC21:12
-YoctoAutoBuilder- build #861 of nightly-mips64 is complete: Failure [failed Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 BuildImages_1 Running SDK Sanity Tests_1] Build details are at
-YoctoAutoBuilder- build #896 of nightly-x86 is complete: Failure [failed Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 Running SDK Sanity Tests_1 BuildImages_2 Running ESDK Sanity Tests] Build details are at
*** marka <marka!~masselst@> has quit IRC21:19
fancerHello, folks. Got a question about yocto and pre-built cross-toolchain.  My task is to make it being part of the build system as if one was built internally. I have already successfully followed the linaro-toolchain way, but it wasn't really what I needed. I want to completely embed my toolchain to yocto as fully available set of binutils/gcc/glibc/etc packages. As far as I could find, my toolchain can be split into21:22
fancerbinutils-cross (->mips), binutils-cross-canadian (x86_64->mips), gcc-cross (mips), gcc-cross-canadian (x86_64->mips), gcc-runtime (mips), libgcc (mips), libgfortran (mips), glibc-* (mips). I already got the concept of the target packages, there are no problems with it, but I am stuck with cross/cross-canadian and shared states part. Particularly I don't understand how to use the installation paths and default vars like21:22
fancer${libdir}, ${bindir} and so. As far as I can see cross{-canadian}.bbclass redefines the these variables so one got to be a !absolute! paths with base of STAGING_DIR_NATIVE. Could you tell me why does the gcc-cross recipe stages files with absolute path???21:22
kergothfancer: meta-external-toolchain now uses separate recipes for each external toolchain component21:24
fancerIt also seems weird, when uses combinations like: "${D}${libexecdir}/gcc/${TARGET_SYS}/${BINV}/", but for cross.bbclass base recipe ${D} is still the absolute destination directory and ${libexecdir} shall be expanded to ${STAGING_DIR_NATIVE}${prefix_native}/libexec/${CROSS_TARGET_SYS_DIR}21:24
kergothdon't think there's much cross-canadian there yet, but it's doable21:25
-YoctoAutoBuilder- build #884 of nightly-ppc is complete: Failure [failed Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 BuildImages_2 Running ESDK Sanity Tests] Build details are at
fancerkergoth: Cool! Thanks. It seems I got old linaro metas without packages splitting. I'll take alook there then.21:27
*** WillMiles <WillMiles!> has quit IRC21:28
kergothit's not perfect, but i think it's better than shoving everything into one monolithic recipe21:28
fancerYeah, that's why I almost got it myself.)21:29
kergoththe cross recipes write links/wrappers to the toolchain bindir, so there's no need to override TARGET_PREFIX anymore21:29
-YoctoAutoBuilder- build #863 of nightly-mips is complete: Failure [failed Building Toolchain Images Running SDK Sanity Tests Building Toolchain Images_1 BuildImages_2 Running ESDK Sanity Tests] Build details are at
kergothhmm, forgot to move the nopseudo bits from meta-external-toolchain to meta-sourcery when i split the layers21:31
kergoththe intention is meta-external-toolchain is the bits that are generic to any toolchain, while you can create another layer that builds on it for the particularities of the individual toolchain, which is what meta-sourcery is now for the Sourcery G++ toolchain21:31
kergothi dont' think anyone else has tried basing their toolchain support on the new layer yet21:32
kergothwould be glad to hear any feedback on it21:32
kergothhmm, need to update the readmes, too21:33
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC21:33
fancerYeah, it would be good to have any docs about the external toolchain embedding. I got nearly crazy trying to figure out how to do it. Hope the new meta-external-toolchain will d the trick. Did you test it with something else rather than with Sourcery G++ toolchain?21:35
fancerI got NG-toolchain bits.21:35
*** demonimin <demonimin!~demonimin@> has joined #yocto21:36
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto21:36
fancer* crosstool-NG21:36
kergothnot recently, but i've done so in the past, i.e. started in-progress work on supporting crosstool-ng-built toolchains. but it's been a while, so there could be kinks21:36
kergoththe downside to the broken-up-recipe approach is we can't just swipe the majority of the external toolchain sysroot and package what we want, instead it pulls just the files we need for each recipe, so some of the recipes end up with more detailed explicit lists of individual files to include, like glibc's headers. but i think that's for the best too, as annoying as it is to explicitly list everything21:37
kergothfyi, with current meta-external-toolchain, it uses the FILES_ variables both for what to package and what files to extract from the xternal toolchain sysroot, so you can just list those files once instead of having to do both do_install *and* the files bits for subpackaging, the way we used to have to do in the monolithic setup21:38
kergothtradeoffs, but i think it's still a net gain21:38
kergothmost of my time is spent dealing with sourcery & meta-mentor, of necessity, since that's my company's priority..21:39
kergothi would definitely like to see support for crosstool-ng working, ideally both external and internal (i.e. a recipe that builds a crosstool-ng toolchain from source)21:39
fancerYeah, that's what I did. I analyzed all the bits, created the files with lists if pairs: source file - install path, then created a small shell-function, which copies the source files to the ${D} directory with prefix like lib/, usr/lib, etc.21:40
* kergoth nods, not a bad approach21:40
kergothi ended up doing the extraction and copy in an approach which is similar to how bitbake's fetcher works. it checks multiple search paths and also has "mirror" support, to check alternate locations, i.e. sbin vs bin21:41
kergothto try to handle any arbitrary toolchain21:41
-YoctoAutoBuilder- build #934 of nightly-arm is complete: Failure [failed Building Toolchain Images Building Toolchain Images_1 BuildImages_2 Building Toolchain Images_2 Running SDK Sanity Tests Building Toolchain Images_3 BuildImages_3 Running ESDK Sanity Tests] Build details are at
fancerThe only problem was a lot of hand-working.)21:42
* kergoth nods21:42
-YoctoAutoBuilder- build #886 of nightly-multilib is complete: Failure [failed BuildImages_6 Running SDK Sanity Tests] Build details are at
fancerIf only crosstoolhain-NG supplied such a list of files.) At least it usually with executable like: bin/mipsel-unknown-linux-gnu-ct-ng.config, which prints the whole toolchain config.21:44
fancerSo we can extract components versions and another useful things.21:45
kergothah, that's very nice indeed21:45
kergothi should really talk the sourcery folks into shipping some form of metadata21:45
kergothhaving real info to use rather than having to guess would be better indeed21:47
fancerAnd it's much better than to hard-code the versions to recipes.21:47
kergothcurrently meta-external-toolchain does set some versions, i.e. pulls kernel version from the kernel headers, runs gcc -dumpversion, etc. but that doesn't work for everything21:48
fancerYeah, I saw it in previous meta-linaro/meta-linaro-toolchain/conf/distro/
fancerCopied it to my layer.)21:51
fancer* with minor alterations...21:52
fancerone more question. Does meta-external-toolchain allow to create an SDK with external toolchain embedded?21:53
kergothnot yet, though it should be doable without too much work. would be best off adding nativesdk and cross-canadian variants to the recipes, possibly adding additional search paths so it'd extract the toolchain binaries rather than just the files in the sysroots21:56
fancerAhhh, I knew, there couldn't be everything so great.) So what does the meta-external-toolchain basically do with the toolchain bits?21:59
fancerDoes it copies them to the sysroots without packages creation?22:00
kergothFor now, creates symlinks / wrapper scripts for the main toolchain binaries. doesn't copy internal components of gcc or binutils.22:04
fancer* sorry If I might have sounded rude. I am just very excited, that there is a layer, which does nearly everything, what I tried to create for nearly two weeks...22:04
kergothwhich is appropriate for cross, since cross recipes aren't packaged in any form22:04
kergothheh, no problem, hopefully it's at least a starting point for you22:04
fancerYeah, crosses doesn't, but libgcc, libgfortran, gcc-runtime, etc does.22:05
fancerand cross-canadians.22:05
-YoctoAutoBuilder- build #952 of nightly is complete: Failure [failed] Build details are at
kergothI'd suggest creating a gcc-cross-canadian recipe which inherits external-toolchain and cross-canadian, then add the toolchain binary path (${EXTERNAL_TOOLCHAIN}/bin) as well as the gcc internal binary paths to the search paths, then set the FILES variables to grab the appropriate files. it's actually even easier than you might think, since you could build gcc-cross-canadian with the internal recipes and then dump the contents of the binary packages and22:07
kergoth use those lists to set the FILES variables. then only after that adjust the search paths and files mirrors on an as-needed basis to ensure it can find those files in the external toolchain22:07
*** dreyna <dreyna!> has quit IRC22:07
*** vmeson <vmeson!> has quit IRC22:07
*** mattsm <mattsm!> has quit IRC22:07
*** lfa <lfa!~lfa@> has quit IRC22:07
*** seebs <seebs!~seebs@> has quit IRC22:07
*** comptroller <comptroller!> has quit IRC22:07
*** ZubairLK <ZubairLK!~Thunderbi@unaffiliated/zubairlk> has quit IRC22:07
*** grma <grma!~gruberm@> has quit IRC22:07
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC22:07
*** slips <slips!> has quit IRC22:07
*** wolfmitchell <wolfmitchell!~mitchell@unaffiliated/wolfmitchell> has quit IRC22:07
*** dreyna <dreyna!> has joined #yocto22:07
*** vmeson <vmeson!> has joined #yocto22:07
*** mattsm <mattsm!> has joined #yocto22:07
*** lfa <lfa!~lfa@> has joined #yocto22:07
*** seebs <seebs!~seebs@> has joined #yocto22:07
*** comptroller <comptroller!> has joined #yocto22:07
*** ZubairLK <ZubairLK!~Thunderbi@unaffiliated/zubairlk> has joined #yocto22:07
*** grma <grma!~gruberm@> has joined #yocto22:07
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto22:07
*** slips <slips!> has joined #yocto22:07
*** wolfmitchell <wolfmitchell!~mitchell@unaffiliated/wolfmitchell> has joined #yocto22:07
kergothcould also build gcc for target and use those packages for the files lists, but the paths might not line up perfectly due to how cross-canadian adjusts the prefix/etc22:07
*** comptroller <comptroller!> has quit IRC22:11
fancerThat was the reason I nearly got crazy, when found that cross/cross-canadians do the prefixes redefinition.22:12
fancerSo my yocto simple targets-based ordered world collapsed.)22:13
kergothnative does too. it's not ideal, but we used to have issues with path relocation. the main advantage to continuing to hardcode a path is we then have a known location to substitute when we run our relocation process to fix the binaries to run from the new location22:13
kergothmost projects aren't path relocatable, other than the toolchain itself22:13
kergothso we have to fix them up on install22:13
kergothi.e. we search/replace the install path in scripts22:14
kergothhard to do if the install root was / :)22:14
kergothcould really epxlicitly set something *invalid* as the default prefix rather than a hardcoded install path default the way we do today (SDKPATH)22:14
fancerYeah, I see.22:15
kergothbetter to patch the upstream projects to be path relocatable, but it's a huge effort and nobody else really cares about it22:16
fancerYou suggested: "...  add the toolchain binary path (${EXTERNAL_TOOLCHAIN}/bin) as well as the gcc internal binary paths to the search paths... " In two words, how can it be done?22:16
kergothsee external-common.bbclass22:17
kergoththe two variables that control where it looks for files are defined there22:17
fancerOk, thanks22:17
kergothso, lets say you add ${bindir}/${EXTERNAL_TARGET_SYS}-gcc to FILES_${PN}.. obviously that file doesn't exist in the external toolchain in that form.. i.e. not /usr/bin or whatever. so we'd want to 1) make sure ${EXTERNAL_TOOLCHAIN} is in the search paths, so it checks relative to toplevel, and then 2) make sure it checks /bin/ for ${bindir} using the mirrors variable, so it ends up finding ${EXTERNAL_TOOLCHAIN}/bin.22:19
kergothif that makes sense22:19
kergothit could have used a single list of paths to search, but that'd end up huge and unwieldy, hence the split in two variables, one for the install root / sysroot, the other for the paths relative to that root in the usual form, i.e. bindir, libdir, whatever22:20
kergothgrabbing just the main gcc binary is actually probably a good starting point as a proof of concept, then can add all the other binaries and the files they need22:21
fancerwhat do you by "mirror variables" ?22:22
kergoth = the first variable i mentioned, EXTERNAL_INSTALL_SOURCE_PATHS22:22
kergoth = the second variable i mentioned, FILES_MIRRORS22:23
kergothlooks like it already checks paths relative to the root of the toolchain (EXTERNAL_TOOLCHAIN)22:24
*** comptroller <comptroller!> has joined #yocto22:24
kergothand FILES_MIRRORS already checks base_prefix for prefix, i.e. it knows to check /bin for files in /usr/bin22:24
kergothso there's a possibliity it might just work as is, but might need to add to FILES_MIRRORS if not22:24
fancer* sorry for nuby question, just wanna make sure I grad the whole concept...22:24
kergothnp, yocto already has a high learning curve, and this layer does things in a unique way on top of that :)22:25
kergothtried to make it as simple as possible while easing the creation of recipes and having the minimum flexibility to support different toolchains with different layouts22:25
fancerI pretty much understand the way the yocto in general works, but when things get to creating something bigger than just a target recipe like toolchains thing and cross, and I get stuck with so-much-code-and-internal-variables-and-configs...22:27
kergoththere's a lot of moving parts, so until you see how everything fits together into a whole, it can be pretty confusing22:28
fancerYeah, exactly22:29
kergothcrosssdk = the toolchain that compiles the binaries that will run on SDKMACHINE, i.e. host binaries for the host sysroot.. i.e. it builds the nativesdk recipes. cross-canadian = binaries that run *on* SDKMACHINE, but target MACHINE, hence cross-canadian, which is a build where BUILD_SYS != HOST_SYS != TARGET_SYS22:29
kergothobviously creating cross-canadian recipes that redistribute the external toolchain will assume that the SDKMACHINE (the machine the sdk is installed on) is binary compatible with the host you're building on22:30
kergothbut that's probably a safe assumption, unless you're redistributing a 32-bit toolchain to a 64-bit host without the 32-bit libraries installed, or something22:30
fancerYeah, I understand that. I have read a lot about cross-compilation and used it since I started by carrier. I meant the yocto internals.22:30
kergothah, fair enough22:30
kergothreading bitbake.conf and then each of the recipe variant bbclasses, can be helpful, though you don't always see the rationale without digging into git history :)22:31
*** pohly <pohly!> has quit IRC22:32
fancerThat's anther way to understand why some things are got to be in a big opensource project - read mailing lists.)22:32
*** mmathen <mmathen!~manu@> has joined #yocto22:32
fancerby the way, what is meta-external-toolchain compatible with rocko?22:35
fancer* s/what//g22:35
*** fitzsim <fitzsim!> has quit IRC22:38
*** fitzsim <fitzsim!> has joined #yocto22:38
nathani__so I'm still having issue with the permissions of my output files on a native cmake recipe I'm working on22:39
fancerand another question. Do I really need the meta-sourcery to be copied into my yocto tree?22:39
nathani__The cmake_install.cmake output from my recipe has TYPE set to FILE22:40
nathani__whereas the cmake_install.cmake output from a native build has TYPE set to EXECUTABLE22:40
kergothfancer: meta-external-toolchain should work with or without meta-sourcery, the latter builds on the former, not vice versa. and yo udont need to copy anything anywhere, you can put your layers whereever you want, as long as you set BBLAYERS to match22:41
fancerYeah, right. It just easier, when everything in one place.)22:41
fancerI mean under one directory, so to have easier searched.22:42
kergothfancer: fyi, i just made a teeny tiny gcc-external-cross-canadian that does package up the main binaries, it's 3 lines22:42
kergothrequire recipes-external/gcc/gcc-external.inc22:42
kergothinherit external-toolchain cross-canadian22:42
kergothFILES_${PN} = "${@'${gcc_binaries}'.replace('${TARGET_PREFIX}', '${bindir}/${EXTERNAL_TARGET_SYS}-')}"22:42 already lists the binaries, so can just use that22:43
*** gtristan <gtristan!~tristanva@> has quit IRC22:43
fancerThats awesome!.) Thanks man! The same might be needed to be done for glibc...22:44
kergothlooks like mine incorrectly picked up the binary paths from ${EXTERNAL_TOOLCHAIN}/${EXTERNAL_TARGET_SYS} rather than the ones in ${EXTERNAL_TOOLCHAIN}, so should probably reorder it for this recipe to fix that: EXTERNAL_INSTALL_SOURCE_PATHS =+ "${EXTERNAL_TOOLCHAIN}"22:45
kergothnormally EXTERNAL_TOOLCHAIN is the last place it looks, since most recipes want files from the sysroot, not from elsewhere22:45
kergothmight want to add SDK_ARCH to PN or something, i'd examine gcc-cross-canadian in oe-core for those sorts of minor details22:45
kergothobviously there's a ton of other files to grab, not just the main binaries, but this shows it's doable, and you just need the list of files to grab and it should go pretty smoothly from there22:46
kergothfancer: we already have glibc. it's a target recipe, so we already package it22:47
kergoththe environment-setup shipped in the sdk will already set —sysroot= to the target sysroot in the sdk, which already has glibc22:47
kergothso all you really need is gcc and binutils for a complete redistributed toolchain in the sdk, in theory22:47
fancerAhhh, right.22:48
kergoththose being the main -cross recipes involved22:48
nathani__i can't see how cmake.bbclass so I'm guessing this is done elsewhere, how can I indicated that these files need to be executable?22:50
*** agust <agust!> has quit IRC22:50
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC22:50
fancerAnd one more crucial question. Will meta-external-toolchain work with poky distribution?22:51
nathani__They are generated as executable, but not installed as such.22:51
fancerkergoth: did you test it with poky tree?22:51
fanceror it doesn't matter?22:52
kergothnot sure what you mean by that22:52
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto22:52
kergothpoky is bitbake+oe-core+meta-poky22:52
kergothwhehter you use that or the individual components really isn't relevent22:52
fancerOk. I said I can ask nuby questions.)22:54
fancerStill confuse some terminologies... (22:55
fancerkergoth: Alright, thanks man for help. I'll get to work, start studying the external-toolchain internals. Don't you mind if I ask some questions about it from time to time here?22:57
*** dreyna <dreyna!> has quit IRC22:58
kergothnope, fine with me. neither meta-external-toolchain nor meta-sourcery really have a mailing list at this point, so irc or emailing the yocto@ list and cc'ing me would be best22:59
fancerOk, thanks man.23:01
kergothnp. i'm playing around with it here, too, so if i get anywhere i'll let you know23:01
kergothnot with much urgency of course, just out of curiosity23:02
fancerGreat, thanks. I'll be in touch here in the IRC. Got irccloud with history caches...23:03
*** nathani__ <nathani__!> has quit IRC23:05
fancerSomething new? )23:12
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC23:13
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto23:15
fancer* might also need to blacklist libgfortran: "PNBLACKLIST[libgfortran] = "not building with an external toolchain" and set the default provider as ""23:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto23:35
kergothyes, good point23:36

Generated by 2.11.0 by Marius Gedminas - find it at!