Friday, 2020-12-11

*** vineela <vineela!vtummala@nat/intel/x-kcsbwwkkzuibcrdc> has joined #yocto00:01
*** goliath <goliath!> has quit IRC00:04
*** DanZ <DanZ!> has joined #yocto00:09
*** DanZ <DanZ!> has left #yocto00:10
*** bps3 <bps3!~bps@> has joined #yocto00:11
*** lukma <lukma!> has quit IRC00:16
*** bps3 <bps3!~bps@> has quit IRC00:30
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC00:30
*** lukma <lukma!> has joined #yocto00:30
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto00:33
*** bps3 <bps3!~bps@> has joined #yocto00:33
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:46
*** jkprg <jkprg!> has quit IRC00:51
*** jkprg <jkprg!> has joined #yocto00:52
*** vineela <vineela!vtummala@nat/intel/x-kcsbwwkkzuibcrdc> has quit IRC00:55
*** hpsy <hpsy!~hpsy@> has quit IRC01:04
*** kpo_ <kpo_!> has quit IRC01:07
*** kpo_ <kpo_!> has joined #yocto01:08
*** mbulut <mbulut!> has quit IRC01:38
*** leon-anavi <leon-anavi!~Leon@> has quit IRC01:45
*** jkprg <jkprg!> has quit IRC01:46
*** rpcme <rpcme!345f0407@> has quit IRC01:54
*** kiwi_29_ <kiwi_29_!> has quit IRC01:54
*** kiwi_29 <kiwi_29!> has joined #yocto01:56
*** kiwi_29 <kiwi_29!> has quit IRC02:08
*** kiwi_29 <kiwi_29!> has joined #yocto02:08
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:08
*** camus <camus!~Instantbi@> has joined #yocto02:23
*** kaspter <kaspter!~Instantbi@> has quit IRC02:24
*** camus is now known as kaspter02:24
*** sakoman <sakoman!> has quit IRC02:40
*** kaspter <kaspter!~Instantbi@> has quit IRC02:45
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:45
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto02:47
*** kiwi_29 <kiwi_29!> has quit IRC02:52
*** kiwi_29 <kiwi_29!> has joined #yocto02:55
*** kiwi_29_ <kiwi_29_!> has joined #yocto02:58
*** kiwi_29 <kiwi_29!> has quit IRC02:58
*** kiwi_29 <kiwi_29!> has joined #yocto02:59
*** kiwi_29 <kiwi_29!> has quit IRC03:08
*** kiwi_29 <kiwi_29!> has joined #yocto03:10
*** sakoman <sakoman!> has joined #yocto03:10
*** kiwi_29 <kiwi_29!> has quit IRC03:13
*** sakoman <sakoman!> has quit IRC03:21
*** kiwi_29 <kiwi_29!> has joined #yocto03:34
*** ahadi <ahadi!> has quit IRC03:49
*** ahadi <ahadi!~ahadi@> has joined #yocto03:50
*** kiwi_29 <kiwi_29!> has quit IRC04:04
*** gonkulator <gonkulator!~brandon@> has quit IRC04:26
*** gonkulator <gonkulator!~brandon@> has joined #yocto04:30
*** NiksDev <NiksDev!~NiksDev@> has quit IRC04:31
*** kpo_ <kpo_!> has quit IRC04:58
*** kpo_ <kpo_!> has joined #yocto04:59
*** kiwi_29 <kiwi_29!> has joined #yocto05:05
*** kiwi_29 <kiwi_29!> has quit IRC05:09
*** Mr_Singh_ <Mr_Singh_!~Mr_Singh@2607:fea8:bdf:dda2:4908:564f:8430:8c41> has quit IRC05:23
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto05:32
*** jobroe <jobroe!> has joined #yocto05:35
*** camus <camus!~Instantbi@> has joined #yocto05:37
*** kaspter <kaspter!~Instantbi@> has quit IRC05:38
*** camus is now known as kaspter05:39
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC05:49
*** ericch <ericch!> has quit IRC05:52
*** camus <camus!~Instantbi@> has joined #yocto06:01
*** kaspter <kaspter!~Instantbi@> has quit IRC06:01
*** camus is now known as kaspter06:01
*** beneth <beneth!> has joined #yocto06:13
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has joined #yocto06:18
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC06:29
*** meow` <meow`!~sbourdeli@> has quit IRC06:29
*** meow` <meow`!~sbourdeli@> has joined #yocto06:30
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto06:30
*** camus <camus!~Instantbi@> has joined #yocto06:32
*** kaspter <kaspter!~Instantbi@> has quit IRC06:33
*** camus is now known as kaspter06:33
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC06:33
*** Mr_Singh_ <Mr_Singh_!> has joined #yocto06:38
*** alessioigor <alessioigor!> has joined #yocto06:39
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto06:39
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC06:42
*** AndersD <AndersD!> has joined #yocto06:45
*** Mr_Singh_ <Mr_Singh_!> has quit IRC06:47
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto06:49
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC06:51
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto06:59
*** DanmerZ <DanmerZ!~op@> has joined #yocto07:06
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC07:15
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:17
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:17
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC07:26
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:9b5:3ed5:8608:6454> has quit IRC07:31
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:8d87:d553:3a99:8ac1> has joined #yocto07:33
*** camus <camus!~Instantbi@> has joined #yocto07:34
*** kaspter <kaspter!~Instantbi@> has quit IRC07:35
*** camus is now known as kaspter07:35
*** Shikadi` <Shikadi`!> has quit IRC07:35
*** meego_ <meego_!~meego@2a01:e0a:1ec:b0e0:c932:4fcb:2a9a:e761> has joined #yocto07:36
*** meego__ <meego__!~meego@2a01:e0a:1ec:b0e0:e0bd:ca5b:2a5a:35b2> has joined #yocto07:37
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:8d87:d553:3a99:8ac1> has quit IRC07:38
mcfriskwhat about updating systemd in dunfell LTS from 244.3 to 244.5? could that be considered, or is systemd stable tree too unstable?07:38
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:84a5:fd88:7e20:615e> has joined #yocto07:38
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:39
*** agust <agust!> has joined #yocto07:39
*** meego_ <meego_!~meego@2a01:e0a:1ec:b0e0:c932:4fcb:2a9a:e761> has quit IRC07:40
*** meego___ <meego___!~meego@2a01:e0a:1ec:b0e0:59ed:b5bc:c892:4af7> has joined #yocto07:40
*** wz <wz!> has joined #yocto07:41
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:41
*** meego__ <meego__!~meego@2a01:e0a:1ec:b0e0:e0bd:ca5b:2a5a:35b2> has quit IRC07:42
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:84a5:fd88:7e20:615e> has quit IRC07:43
zygagood morning07:43
*** mckoan|away is now known as mckoan07:44
mckoangood morning07:44
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:7c53:e0f:b7a:5c32> has joined #yocto07:45
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto07:45
*** meego___ <meego___!~meego@2a01:e0a:1ec:b0e0:59ed:b5bc:c892:4af7> has quit IRC07:45
LetoThe2ndyo dudX07:46
*** meego_ <meego_!~meego@2a01:e0a:1ec:b0e0:8d7d:13e:4810:8b25> has joined #yocto07:47
*** mmurto <mmurto!> has joined #yocto07:47
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC07:49
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:7c53:e0f:b7a:5c32> has quit IRC07:49
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:51
*** meego_ <meego_!~meego@2a01:e0a:1ec:b0e0:8d7d:13e:4810:8b25> has quit IRC07:52
*** frwol <frwol!> has joined #yocto07:53
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:53
mmurtoI'm trying to build core-image-sato on 3.2, but I'm running into an error fetching Multiple tries, always "Read error at byte 14600/421525 (Connection reset by peer)." Anyone else or is it something on my end?07:54
mckoanmmurto: try a manual wget08:02
mmurtomckoan: Same failure manually08:06
mmurtoTried on an external vpn and it works, so probably something to do with my network config.08:08
*** TPRoberts <TPRoberts!~TPRoberts@> has joined #yocto08:13
*** mbulut <mbulut!> has joined #yocto08:14
*** tnovotny <tnovotny!> has joined #yocto08:17
LetoThe2ndmmurto: real life tip: sato is not that useful anyways, so unless you explicitly need it for some specific reason you're almost certainly better off starting with core-image-x11 or even better yet a custom image.08:23
*** Yumasi <Yumasi!> has joined #yocto08:24
mmurtoLetoThe2nd: Thanks! I'm working on a tool to analyze some aspects of the images, so not really too concerned with the specifics of the images :)08:26
LetoThe2ndmmurto: i see. its just that a lot of beginners think of sato as a good thing to start off as "it is full featured and graphical", and thats certainly not its use case. :)08:28
mmurtoLetoThe2nd: Can't blame them too much, as the quick build documentation uses sato as the example ;)08:30
LetoThe2ndmmurto: does it?08:31
LetoThe2ndqschulz: hey mister documentation, thoughts on this? ;-)08:31
*** mbulut <mbulut!> has quit IRC08:32
mmurtoLetoThe2nd: Yep, at least here:
mmurto"Start the Build: Continue with the following command to build an OS image for the target, which is core-image-sato in this example"08:33
*** bps3 <bps3!~bps@> has quit IRC08:33
LetoThe2ndGood point. Maybe we should change that to something more sensible.08:35
*** kpo_ <kpo_!> has quit IRC08:36
*** kpo_ <kpo_!> has joined #yocto08:36
*** creich <creich!> has quit IRC08:44
*** creich <creich!> has joined #yocto08:45
*** meego <meego!~meego@> has joined #yocto08:53
*** mbulut <mbulut!> has joined #yocto08:57
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC08:57
*** meego <meego!~meego@> has quit IRC08:58
*** hpsy <hpsy!~hpsy@> has joined #yocto09:05
*** dreyna <dreyna!> has quit IRC09:33
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto09:35
qschulzLetoThe2nd: anything serves as an example. Same goes for poky, it technically shouldn't be used, it's an example distro.09:37
*** Scoutboy <Scoutboy!~quassel@> has quit IRC09:42
Ad0I dunno if I remember but was there some .mount file magic going on ? if you included mount files it would automatically add them for systemd mounts09:44
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto09:45
LetoThe2ndqschulz: yeah, but especially sato is misleading IMHO. and it also gets mentioned upon oe-init-env, which isn't helpful either.09:47
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC09:50
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto09:51
*** kpo_ <kpo_!> has quit IRC10:02
*** kpo_ <kpo_!> has joined #yocto10:02
*** mbulut <mbulut!> has quit IRC10:04
*** meego <meego!~meego@2001:41d0:fe7e:c800:88c4:e895:3c95:5a56> has joined #yocto10:09
*** goliath <goliath!> has joined #yocto10:11
*** camus <camus!~Instantbi@> has joined #yocto10:41
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC10:41
*** kaspter <kaspter!~Instantbi@> has quit IRC10:43
*** camus is now known as kaspter10:43
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto10:43
*** TPRoberts <TPRoberts!~TPRoberts@> has quit IRC10:52
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC11:03
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto11:09
*** jleightcap <jleightcap!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has joined #yocto11:18
wyrewhat's the point of making the difference between a distro and a image recipe?11:20
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto11:22
ptsnevesHey all. I am constantly getting pseudo aborts due to .python-history being created by python11:23
qschulzwyre: a distro is how you do things, image is what you want.11:23
ptsneveshas anybody had the issue?11:23
qschulzyou select your init system in a distro, not in an image11:23
qschulzthere's a very important different between a distro and an image. One is a conf file, the other a recipe11:24
qschulzand Yocto chant #1 taught us: conf data is global, recipe data is local.11:24
qschulzwhich means, you cannot impact other recipes from a recipe, only from a conf file.11:25
wyreqschulz, thank you very much for the clarification 😊11:25
paulbarkerwyre: I recommend looking at the poky distro config and then the core-image-base & core-image-full-cmdline recipes to see how it fits together11:27
LetoThe2ndqschulz: :)11:27
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto11:34
qschulzwyre: ^11:34
*** loblik <loblik!a5e150fc@> has joined #yocto11:36
*** creich <creich!> has quit IRC11:37
wyrepaulbarker, I've been checking the full-cmdline recipe and ... I'm wondering why is not appending to the IMAGE_INSTALL var?
wyrecould be due it's inheriting form a class instead requiring another recipe? 🤔11:41
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC11:54
*** creich <creich!> has joined #yocto11:56
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto12:00
*** tgoodwin <tgoodwin!> has joined #yocto12:13
*** mmurto <mmurto!> has quit IRC12:15
*** camus <camus!~Instantbi@> has joined #yocto12:20
*** camus <camus!~Instantbi@> has quit IRC12:20
*** kaspter <kaspter!~Instantbi@> has quit IRC12:20
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:25
*** leon-anavi <leon-anavi!~Leon@> has quit IRC12:33
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto12:33
paulbarkerwyre: It's most likely that there's just no need to use `_append` here - it's the image recipe so it can set IMAGE_INSTALL directly12:35
paulbarkerIt's like you don't have to use `SRC_URI_append` in a recipe, you just go ahead and set `SRC_URI`12:35
wyrethen where you have to use `_append` or `+=` ? (if not in a recipe, I mean)12:36
rburtonkanavin_home: is there an idiomatic git tag regex for a.b.c to avoid the upstream checker thinking 20201010 is a newer tag than 1.2.3?12:36
qschulzwyre: _append is when you don't want to append a leading space (technically .= does it too).12:37
qschulz_append is "resolved" after all += =+ = ?= ??= .= =. are resolved12:38
wyreqschulz, I know that, I mean, if I don't need to use append in a image recipe ... where is intended to use?12:38
qschulzyou should use _append in conf files because those are parsed before recipes, so if you use a += and have a default (?=) in a recipe, you actually replace the default instead of appending to it12:39
qschulzalso, if you want to add to a variable only in the case of a machine, you need to use _append_<machine>12:39
rburtonkanavin_home: no matter, found it12:39
qschulzbecause FOO_machine += will replace FOO12:39
*** robert1 <robert1!> has joined #yocto12:39
qschulzinstead of appending to it12:39
loblikI've tried multiconfig to build system controller firmware (different arch). I've added do_compile[mcdepends] and it seems to work. But does it mean I have to prefix all my bitbake commands with mc:main_target: ?12:40
wyreso `VAR += "whatever"` and `VAR_append = " whatever"` are not exactly equivalents, qschulz?12:41
loblikOr can I specify a default somehow and use the other configuration only for system controller package?12:41
*** robert1 is now known as robertd12:43
rburtonhm i wonder what the best way of saying in a tune "can't build linux"12:45
qschulzwyre: definitely not equivalents12:46
wyreqschulz, also I'm a little bit confused about what variables are intended to use in conf files and what are intended to use in recipes 😕12:47
LetoThe2ndbuilding gatesgarth core-image-minimal in 80s: hot sstate and pcie nvme :)12:50
rburtontell my CI runner to get a wriggle on, takes 5 minutes from clean tmp with sstate12:51
rburtonwhich isn't that bad but there's 11 machines to run through12:51
qschulzwyre: variables that apply to machines or distros only need to be defined in conf files, otherwise "it depends"12:52
LetoThe2ndrburton: sure, its not exactly real life numbers (yet), just starting to test with rather clean poky builds.12:52
qschulz(and by apply I mean things that are either not applicable to recipes or applicable to all)12:53
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC13:29
*** dv|2 <dv|2!~dv@> has joined #yocto13:30
dv|2how can I define what package managemenet tool to use in the image (if I enable both RPM and DEB in my conf)?13:31
rburtondv|2: first one builds the image13:31
dv|2rburton, sorry?13:32
rburtonwhere you set PACKAGE_CLASSES = "package_rpm package_deb"13:32
rburtonthe first one in the list, builds the imag13:32
rburtonso that would build both rpms and debs, but rpm is used to build the image and is the installed tool13:33
dv|2rburton, I set it in my local.conf13:34
dv|2I am building several images with the same config. May I set it per-image?13:34
LetoThe2ndwhat is the usecase?13:40
dv|2LetoThe2nd, to have two images: one is my own repos, another may use debian/ubuntu repos13:45
*** Yumasi <Yumasi!> has quit IRC13:45
LetoThe2ndthat sounds extramely fishy, to say the least.13:46
dv|2LetoThe2nd, too much people says "i want ubuntu" meaning they want to install software from deb/ubuntu repos. I'm going to give it as an option while keeping my own image for true linuxois13:48
LetoThe2ndi can't see that making sense.. but hey, its your "people"13:49
*** wooosaiiii <wooosaiiii!> has joined #yocto13:50
dorindaHi Everyone, forgive me for my late introduction, however I am glad to be connected with the community on #yocto. My name is Dorinda, one of the Outreachy interns and I am working on the "Add support for elfutils debuginfod" bug with my mentors Ross Burton and Paul Eggleton. I hope to learn more about Yocto project and the community, and be able to give contributions too. Thank you.🙂13:51
dv|2LetoThe2nd, customers divided into two categories: they know linux and they want just use ubuntu on my device (because of the repos and apt/other simple set of commands they know). I won't build ubuntu. I want to give two Yocto images: one is rpm, another with apt. that's all13:52
LetoThe2nddv|2: well i personally think the approach of building a ubuntu-replacement-underpinning is completely wrong. but again, its my opinion, and your customers. go ahead :)13:53
LetoThe2nddorinda: howdy there! welcome on board!13:53
dv|2LetoThe2nd, they know "apt" command. that's all. Is it possible to build two images at the same time: one with DNF, another with APT?13:54
LetoThe2nddv|2: technically on yocto, your appraoch is wrong. you should build two distinct DISTRO sets - those can define the package management system to be used.13:55
qschulzdorinda: o/13:55
*** sakoman <sakoman!> has joined #yocto13:55
ecdheI have an embedded board that boots from a file called "boot.bin" which includes a first-stage-bootloader (FSBL) and u-boot.  I have a recipe that acquires the FSBL.  I have a recipe for u-boot.  I also have a recipe that builds the compiler for boot.bin and puts in in ${D}${bindir} so it can be called from other recipes.13:57
dv|2LetoThe2nd, if I can define it in distro with the same local.conf - it is ok. Can I?13:57
ecdheWhat I'm unclear on is how I can access the output of the fsbl and uboot recipes to combine them into boot.bin...13:57
LetoThe2nddv|2: i don't get why you're so totally insisting on "single local.conf"13:58
ecdheIs there an intermediate directory I can install their files into where a third recipe can find them?13:58
*** tgoodwin <tgoodwin!> has quit IRC13:58
LetoThe2nddv|2: if at all you can do a multiconfig build and with that yank out two images with different package managers in one go.13:59
JPEWecdhe: Yes, you want to deploy the files... do_deploy13:59
JPEWThen another recipe can pull them out of ${DEPLOY_DIR_IMAGE}13:59
dorinda@LetoThe2nd yeah, thank you. I really don't know how these replies tagging work.13:59
LetoThe2nddorinda: type the first couple of letters of the nick, then press tab :)14:00
ecdheOkay JPEW, I'll give that a try.  Is that the only canonical holding tank for intermediate files?14:01
dv|2because I want to share all my build results. I already have multiconfig...So I need to add one more into my local.conf with different arch? I don't get how multiconfig can help14:01
dorindaLetoThe2nd: oh great thanks 😊14:01
dv|2LetoThe2nd, because I want to share all my build results. I already have multiconfig...So I need to add one more into my local.conf with different arch? I don't get how multiconfig can help14:01
LetoThe2nddv|2: i have the extremely strong impression that there is a major flaw in your construction. but i can't put the finger on it - and my motication to ge and search it is not that high too, sorry.14:02
*** tnovotny <tnovotny!> has quit IRC14:02
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto14:03
JPEWecdhe: No, but in your case it's the one you want.... that boot flow is pretty common, there are a few examples of it (IMX8 and Rockchip both do similar things IIRC)14:03
rburtonwelcome dorinda  :)14:04
dorindaqschulz:  "o/" don't know what that means, but i assume its a welcome, thank you :)14:04
rburtonit's one half of a high five14:04
JPEWecdhe: It probably should be noted that if you are using one of those SoCs (or possibly others!), you might be able to save some time by using a BSP that does that already :)14:04
rburtondorinda: o/  \o.  <-- two people high fiving14:05
paulbarkerI've used IRC for well over a decade and never seen that one before haha14:05
dorindarburton:  ohh thank you :)14:05
JPEWShould be more like o/         \o these days14:05
ecdheJPEW: this board vendor shipped with only buildroot support, I've been targetting with yocto for a while but wanted to get this additional step into the build system (instead of doing it manually)14:05
rburtonJPEW: lol14:06
rburtonpaulbarker: kids these days14:06
*** TobSnyder <TobSnyder!> has joined #yocto14:06
qschulzdorinda: oh my bad, as rburton said, or just waving. \o/ is for achievements (two hands in the air), /o\ is for head-scratching/doom :)14:06
TobSnyderAm I allowed to change DISTRO_NAME within recipes-core/images/ ?14:06
ecdheJPEW: so do I put ${DEPLOY_IMAGE_DIR} in my SRC_URI?  Or just assume that the assets I need are there already?14:06
TobSnyderOr is it only allowed to change DISTRO_NAME in conf/distro/mydistro.conf ?14:07
rburtonTobSnyder: what do you expect to happen when you change it in an image?14:07
LetoThe2ndTobSnyder: please apply yocto chant #1 and think about your question again.14:07
JPEWecdhe: In your "assembly" task (which I will call do_assemble for example), you would just directly reference ${DEPLOY_DIR_IMAGE}14:07
dorindaqschulz:  lol alright. funny signs though14:08
*** sakoman <sakoman!> has quit IRC14:08
TobSnyderwhat is yocto chant #1?14:08
*** sakoman <sakoman!> has joined #yocto14:08
JPEWecdhe: Then, you need to make that task depend on the recipes that generate the deployed artifacts with something like: do_assemble[depends] += "u-boot:do_deploy"14:09
JPEWecdhe: That ensure the deploy artifacts will be present in the deploy directory by the other recipes before the do_assemble task runs14:10
* JPEW looks for an example....14:10
JPEWecdhe: It's not a third recipe pulling in from two others, but here is an example:
JPEWecdhe: This u-boot recipe pulls ATF from ${DEPLOY_DIR_IMAGE} during do_compile to add it to the u-boot image14:13
qschulzecdhe: i think you could actually do the merging into boot.bin from the image recipe14:13
idadelHello everyone. I'm Ida. Sorry for the late introduction too. I'm an Outreachy intern like dorinda and I'll be improving the YP's license tracing.14:13
TobSnyderI create for example two images: a base image and an image containing all applications. Both of them are based on my meta-custom-dist layer. But due to the fact that in this layer there is conf/distro/mydistro.conf that sets DISTRO_NAME and DISTRO_VERSION the same version would apply to both images. But both images have to be versioned independently. This also applies to SDK that is being created - it currently only depends on variables I14:14
TobSnyder set in mydistro.conf (like SDK_NAME or SDKPATH) but I would like to differentiate because every image bringst its own SDK (each image might have its own libs that are needed in SDK for linking)14:14
TobSnyderSo how to solve this?14:14
qschulzidadel: \o14:14
Ad0is there a huge advantage to use dropbear if your image is already big ?14:16
TobSnyder(I even ask myself if I am allowd to overwrite DISTRO)14:16
qschulzTobSnyder: IIUC, your problem is you want a different name per SDK for two images sharing the same distro and you're wondering how to do this. Right?14:17
LetoThe2ndTobSnyder: in a custom DISTRO, sure. thats what its meant for. in an image: no.14:17
LetoThe2ndidadel: howdy there too!14:20
tlwoernerdorinda: o/ nice to meet you! welcome to the project/community14:26
dorindatlwoerner: \o nice meeting you too! thank you :)14:29
tlwoerneridadel: hi! o/14:32
rburtonqschulz: what have you done now everyone is waving! ;)14:33
*** leon-anavi <leon-anavi!~Leon@> has quit IRC14:33
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto14:33
tlwoernerecdhe: in fact, the example JPEW pointed you to (the one in meta-rockchip) sounds a lot like your situation: a boot binary composed of multiple pieces14:33
*** dv|2 <dv|2!~dv@> has quit IRC14:34
*** ayaka <ayaka!~ayaka@> has joined #yocto14:34
qschulzrburton: \o~ ~o~ ~o/14:35
rburtonqschulz: what's that one?!14:35
qschulzrburton: or whatever can look like a dance :p14:35
idadelqschulz: o/14:35
ayakabefore the filesystem I compiled from yocto can load the debug symbols auto14:35
ayakabut recently I may just update my host system, the debug file compiled from yocto, it's debug symbols won't be loaded by gdb auto14:36
ayakais there any related configure ?14:36
idadelLetoThe2nd: We e-meet again! :)14:37
*** jobroe <jobroe!> has quit IRC14:37
idadeltlwoerner: o/14:37
dorindaqschulz: lol14:38
LetoThe2ndidadel: i'm hard to miss in terms of yocto during european office times!14:38
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto14:43
TobSnyderqschulz: you are right, I want to images that are based on one distro but that should use different versions (that I also can see in the running system later on) as well as different SDKs14:47
*** konsgnxx <konsgnxx!> has joined #yocto14:48
TobSnyderso for SDK I guess I have to overwrite TOOLCHAIN_OUTPUTNAME or SDK_NAME but as I understand those changes have to be done in distro.conf14:49
LetoThe2ndTobSnyder: so why not create a and pull it in in two distint distros, that just override the particular bits?14:50
*** rcw <rcw!~rcwoolley@> has joined #yocto14:50
TobSnyderok so this would also be some possible way, resulting in just also creating another distro.conf in the layer that contains the application image14:56
LetoThe2ndyup. a classic approach, if you ask me.14:57
sgwrburton: RP: Morning14:58
rburtonmorning sgw14:58
sgwBefore I go digging to deep did one of you already look at the build failure ?14:59
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto14:59
LetoThe2nd"the build failure"15:00
* LetoThe2nd starts giggling uncontrollably, progressing into mad laughter and rolling on the office florr15:00
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC15:02
*** ericch <ericch!> has joined #yocto15:06
rburtonsgw: i haven't and RP has been out all morning, so i think its on you :)15:08
*** ssajal <ssajal!> has joined #yocto15:09
sgwrburton: thanks, just did not want to duplicate effort.  the systemd packaging failure seems interesting and really random!15:10
*** psiva87 <psiva87!> has joined #yocto15:15
RPsgw: rburton is correct, I've not been around until now15:15
sgwRP hope you where out for some fun and adventure!  I am looking into the 3 issues from the full build.15:17
*** tgoodwin <tgoodwin!> has joined #yocto15:17
RPsgw: I got soaked and very muddy ;-)15:18
psiva87Thanks bluelightning, can I add SYSROOT_DIRS += "${bindir}" if we want the binary in rootfs.15:18
sgwthat means fun!15:20
qschulzJaMa: too fast for me :/15:23
*** davidinux <davidinux!~davidinux@> has quit IRC15:23
TobSnyderLetoThe2nd: just for my understanding your proposal would mean I will have a distro for each image probably15:25
*** davidinux <davidinux!~davidinux@> has joined #yocto15:25
RPsgw: I might agree when I warm up a bit :)15:27
LetoThe2ndIf your usecase mandates this it is possible, of course15:28
qschulzpsiva87: no, FILES_ is what you're looking for15:28
qschulzSYSROOT_DIRS is a way to make files available to other recipes at build time15:29
qschulzpsiva87: if you want a file in your rootfs, you add it to a package with FILES_ and then add this package to your image (via IMAGE_INSTALL usually)15:30
qschulz(or if a piece of SW depends on it, RDEPENDS/DEPENDS in that recipe)15:30
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has quit IRC15:30
TobSnyderIf I have DISTRO_VERSION in my common.conf and in my distroA.conf and SDK_VERSION = "v${DISTRO_VERSION}" in common.conf. will it use the one defined in distroA.conf when building an image based on distroA.conf?15:31
TobSnyder(the question is: when will those variables be resolved)15:31
TobSnyder(of course with something like "require common.conf" in distroA.conf)15:32
Ad0is there some variables for busybox that maps to configure variables or do I have to patch / replace the entire busybox config for build?15:32
Ad0( the defconfig vars)15:32
qschulzAd0: there exists support for config fragments15:32
Ad0oh yeah I totally forgot about that, I thought it was restricted to kernel only15:33
qschulzTobSnyder: it'll work just fine15:33
qschulzAd0: it's on a per-recipe basis15:33
qschulznot all kernel recipes actually support config fragments15:33
qschulzAd0: no, I think you misunderstood if you said nice :p15:33
Ad0I said "nice" to the fact that you reminded me of the fragments stuff15:34
qschulzAd0: ack15:34
Ad0sorry for being unclear15:34
Ad0also I might switch back to openssh instead of dropbear15:34
qschulzAd0: no worries, how I phrased my sentence was also not great ;)15:35
qschulzAd0: what for?15:35
Ad0I mean I did dropbear -i -r /var/lib/dropbear/dropbear_rsa_host_key -p []:22 -p [::1]:22 -s15:35
Ad0still binds to since I can connect from LAN15:35
Ad0tcp        0      0 :::22                   :::*                    LISTEN15:35
Ad0seems like it completely ignores it (v2019.78 found in Warrior)15:36
Ad0it seems a bit silly to fiddle with ipchain to fix it15:36
*** davidinux <davidinux!~davidinux@> has quit IRC15:46
*** AndersD <AndersD!> has quit IRC15:47
ecdhethanks JPEW, got that working15:58
ecdhethanks tlwoerner, yes, the rockchip situation is pretty similar15:58
qschulzJPEW: I guess it's time to start bisecting the kernel :)16:00
ecdheSo I got my recipe working, it depends on other recipes.  For a long time I tested it with 'bitbake myrecipe'.  Then I referenced it from "INSTALL_IMAGE_APPEND" in my layer.conf and went to build my image, and the build fails, saying:16:00
JPEWqschulz: Oh, I bisected pretty much all day yesterday.... it's quite puzzling :)16:00
ecdhe'Package 'myrecipe' has no installation candidate'16:00
*** lxc <lxc!> has joined #yocto16:00
lxccan ipk package manager be used to update the boot and kernel?16:01
ecdheI modified to include the line PROVIDES = "myrecipe" but still no luck16:02
JPEWecdhe: Is the 'myrecipe' package created by empty (no files?)16:03
tlwoernerqschulz: Ad0: i think config fragments only works with kernel, not busybox?16:03
JPEWecdhe: That happens a lot with recipes that are only a static library16:03
JPEWecdhe: .... or recipes that only deploy something ;)16:04
ecdheJPEW: yes, it only deploys something16:05
ecdheit does have 'inherit deploy'16:05
JPEWecdhe: Ya, in that case installing the "package" doesn't really make any sense16:05
JPEWBy default, bitbake will not generate an (ipk,deb,rpm) for any package that doesn't contain any files16:06
JPEWThis is the same problem bobbyJ was having yesterday16:06
ecdheyeah, and in this case I want to install files onto the FAT partition of my SD card, not the ext partition16:06
ecdheIt would be nice if there was a concept of an additional filesystem16:07
*** Ninic0c0 <Ninic0c0!> has joined #yocto16:07
JPEWAre you using wic?16:07
JPEWecdhe: wic lets you do that FWIW.... I *highly* recommend using it16:08
Ninic0c0Hi all, I'm trying to migrate a project from Zeus to Dunfell branch and I got a issue tmp/deploy/licenses/<image_name>/recipeinfo not found. It's a custom image recipe based on core-image-minimal (no trouble with this one) Any info about this file ? Thank you :)16:08
ecdheJPEW, looks neat16:09
ecdheIt looks like exactly what I need.  Except today I really just need to get the output of this build... perhaps I'll try to include a dummy file16:11
*** roussinm <roussinm!> has joined #yocto16:13
matthewcroughanDoes anyone know what the MACHINE name is for qemux86_64?16:13
matthewcroughanIs that the correct machine name?16:13
matthewcroughanis there a list of all yocto supported machines?16:14
JPEWecdhe: The key is --sourceparams="loader=u-boot" on line 23:
codypsmatthewcroughan: you'll want to look for files with paths matching `conf/machine/*.conf` to get a list of machine names. Different layers tend to add support for different machines16:18
codypsmany layers (bsp layers) exist solely to add various MACHINEs16:19
JPEWecdhe: Then, you can control what files are put in that partition with WKS_FILE_DEPENDS/WKS_BOOT_FILES:
codypsmatthewcroughan: `qemux86-64` is a valid machine name (provided by openembedded-core)16:20
*** robertd <robertd!> has quit IRC16:21
*** lxc <lxc!> has quit IRC16:21
codypsIf you're using `poky`, you can find it in `meta/conf/machine/qemux86-64.conf`16:21
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC16:23
marexkhem: have you seen clang segfault while linking chromium before ?16:25
marexkhem: seems both clang10 and clang11 does16:26
ecdheJPEW: I have sdimage-bootpart.wks, it looks close to what I need, but lacks  "--sourceparams="loader=u-boot"  why is that flag so important?16:34
qschulztlwoerner: no there is support for config fragments with busybox16:38
qschulztlwoerner: see all the .cfg files in
*** davidinux <davidinux!~davidinux@> has joined #yocto16:40
qschulzmatthewcroughan: find all machines in all layers by doing finding the .conf files in meta-*/conf/machine/16:41
qschulzit's probably qemux86-64 since underscores aren't supported in machine names16:41
tlwoernerqschulz: awesome, thanks for the update16:41
qschulzmatthewcroughan: c.f.
*** frsc <frsc!> has joined #yocto16:45
*** alessioigor <alessioigor!> has quit IRC16:46
*** davidinux <davidinux!~davidinux@> has quit IRC16:47
*** frsc <frsc!> has quit IRC16:47
*** davidinux <davidinux!~davidinux@> has joined #yocto16:49
*** wz <wz!> has quit IRC16:50
*** bps3 <bps3!~bps@> has joined #yocto16:56
JPEWecdhe: That tells wic to populate the (FAT?) partition with files necessary for u-boot17:00
*** frwol <frwol!> has quit IRC17:00
JPEWecdhe: Sorry, I link I pointed you in the wrong direction...17:03
JPEWYou only need the --source bootimg-paritition which will copy the files specified in WKS_BOOT_FILES17:03
JPEWThe --sourceparams="loader=u-boot" is only necessary if you want WKS to make a extlinux.cfg file, which will allow a default u-boot to automatically find and boot your kernel17:04
JPEWIf you've modified u-boot with your own boot flow, you don't need that17:05
tlwoernerJPEW: which conflicts with other u-boot tooling to create extlinux.cfg files :-(17:06
tlwoerner(outside of wks)17:06
JPEWtlwoerner: Maybe? We never use it because we use boot scripts instead17:07
JPEWIt looks like you can specify your own extlinux.cfg: bootloader --configfile="directdisk-bootloader-config.cfg"17:07
*** wz <wz!> has joined #yocto17:07
*** amitk_ is now known as amitk17:09
JPEWtlwoerner: I think the real advantage is that it "just works" for most of the standard use cases since it auto-detects the kernel type, boot args, etc. If you're doing anything custom, you're probably better turning it off17:09
JPEWboot scripts are the way to go there IMHO. Just turn on distro_boot in u-boot and put a boot.src file in IMAGE_BOOT_FILES17:11
*** vineela <vineela!~vtummala@> has joined #yocto17:12
JPEWAh, darn.... ecdhe: everywhere I previously said WKS_BOOT_FILES should be IMAGE_BOOT_FILES. My bad17:12
*** wz <wz!> has quit IRC17:12
*** lexano <lexano!> has quit IRC17:16
*** yann <yann!~yann@> has quit IRC17:17
*** wz <wz!> has joined #yocto17:18
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC17:18
*** lexano <lexano!> has joined #yocto17:21
*** wz <wz!> has quit IRC17:22
*** yann <yann!~yann@> has joined #yocto17:29
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC17:34
*** mckoan is now known as mckoan|away17:36
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto17:38
*** roussinm <roussinm!> has quit IRC17:39
*** meego <meego!~meego@2001:41d0:fe7e:c800:88c4:e895:3c95:5a56> has quit IRC17:42
tlwoernerJPEW: i'm just saying that when you fill your machine.conf file with a bunch of EXTLINUX_* variables then find that the extlinux.conf that is used has nothing to do with the variables you created, it gets confusing17:43
tlwoernerespecially since there's no warning or indication that what you put in your config file is getting clobbered by what wks wants to do :-)17:44
Ninic0c0My basic custom recipe soens't populate recipeinfo anyone can point me a direction to fix that ?17:44
tlwoernerin any case, it's somewhere on my todo list to see if the variables in one's machine.conf could be used by wks17:44
v0nTrying yocto on my beaglebone black, I get this: "Unhandled fault: external abort on non-linefetch (0x1008) at 0xe02e6000" any idea?17:50
*** bps3 <bps3!~bps@> has quit IRC18:06
*** wz <wz!> has joined #yocto18:07
JPEWtlwoerner: Ah I didn't even know about those variables18:08
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:09
*** wz <wz!> has quit IRC18:11
*** davidinux <davidinux!~davidinux@> has quit IRC18:12
OutBackDingowelp this is new   file /etc/ethertypes conflicts between attempted installs of netbase-1:6.2-r0.corei7_64 and ebtables-2.0.10+4-r4.corei7_6418:12
OutBackDingotsk tsk tsk18:12
*** davidinux <davidinux!~davidinux@> has joined #yocto18:13
*** mbulut <mbulut!> has joined #yocto18:19
*** sakoman <sakoman!> has quit IRC18:20
*** kiwi_29_ <kiwi_29_!> has joined #yocto18:24
*** sakoman <sakoman!> has joined #yocto18:35
*** asteriusio <asteriusio!> has quit IRC18:36
*** roussinm <roussinm!> has joined #yocto18:37
*** kiwi_29_ <kiwi_29_!> has quit IRC18:40
*** wz <wz!> has joined #yocto18:47
*** davidinux <davidinux!~davidinux@> has quit IRC18:50
*** kiwi_29_ <kiwi_29_!> has joined #yocto18:51
*** davidinux <davidinux!~davidinux@> has joined #yocto18:52
*** lexano <lexano!> has quit IRC18:58
*** lexano <lexano!> has joined #yocto19:01
*** kiwi_29_ <kiwi_29_!> has quit IRC19:02
*** Ninic0c0 <Ninic0c0!> has quit IRC19:04
*** kiwi_29_ <kiwi_29_!> has joined #yocto19:04
*** davidinux <davidinux!~davidinux@> has quit IRC19:05
*** ecdhe_ <ecdhe_!~ecdhe@unaffiliated/ecdhe> has joined #yocto19:06
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC19:09
*** davidinux <davidinux!~davidinux@> has joined #yocto19:09
*** bps3 <bps3!~bps@> has joined #yocto19:13
*** wz <wz!> has quit IRC19:20
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC19:22
*** bps3 <bps3!~bps@> has quit IRC19:25
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC19:26
*** mbulut <mbulut!> has quit IRC19:29
*** psiva87 <psiva87!> has quit IRC19:33
codypsv0n: sounds like some kind of alignment issue when loading from memory? thought the `linefetch` bit seems a bit more strict than normal19:36
v0ncodyps: yeah... can I be missing a kernel option or something?19:38
*** kiwi_29_ <kiwi_29_!> has quit IRC19:44
*** kiwi_29_ <kiwi_29_!> has joined #yocto19:49
sgwRP: Sorry it's taken me a while to get back to SWATing, this morning has been crazy with other stuff.  There is a systemd issue in altcfg, an NFS failure with qemux86-64 and an oe-selftest fail with reproducible_builds.19:56
sgwThat's the high level, digging deeper19:57
*** bps3 <bps3!~bps@> has joined #yocto19:59
*** kiwi_29_ <kiwi_29_!> has quit IRC20:03
*** kiwi_29_ <kiwi_29_!> has joined #yocto20:03
*** tgoodwin <tgoodwin!> has quit IRC20:06
v0ncodyps: found how to reproduce. This happens with a (custom) power reset. Hard power cycling fixes it. Might be due to some clock initialization or something.20:07
*** bps3 <bps3!~bps@> has quit IRC20:08
*** kiwi_29_ <kiwi_29_!> has quit IRC20:10
*** dreyna <dreyna!> has joined #yocto20:12
*** dreyna <dreyna!> has joined #yocto20:14
*** jleightcap <jleightcap!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has quit IRC20:18
*** jleightcap <jleightcap!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has joined #yocto20:19
*** Shikadi` <Shikadi`!> has joined #yocto20:20
*** konsgnxx <konsgnxx!> has quit IRC20:27
*** kiwi_29_ <kiwi_29_!> has joined #yocto20:28
*** kiwi_29_ <kiwi_29_!> has quit IRC20:32
*** leon-anavi <leon-anavi!~Leon@> has quit IRC20:33
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto20:33
v0nHey, why does Yocto define a new machine "beaglebone-yocto"?20:35
zeddiibecause it is the reference version that we build, not to be mistaken with the official one from TI. They have different features (fewer in the yocto reference) and a different kernel, etc.20:36
v0nhum ok, what's confusing to me is that I thought that a new machine should describe a new hardware, and in the case of yocto, the project could have just extended or overriden TI's kernel, features, packages and stuffs20:43
*** Konsgn <Konsgn!> has joined #yocto20:44
*** Konsgn is now known as Guest425220:45
*** Guest4252 is now known as konsgnxx20:49
zeddiithere are no rules about anything like that.20:50
zeddiiit's just a hardware description.20:50
zeddiiand no, that would be way worse20:50
zeddiitrying to undo what a changing base does, means you chase your tail forever20:50
v0nbut isn't why yocto is designed for? extending existing machine and packages?20:50
zeddiiit's a use of it, sure20:51
v0nzeddii: kinda same topic, if you were selling a hw/sw product based on a beaglebone, would you define a new machine (named "beaglebone-<company>", "beaglebone-<product>" or simply "<product>") or would you simply extend "beaglebone" in your company layer?20:53
zeddiiit depends if I thought that I'd need to do machine specific things at some point, being able to differentiate your machine from the base one, can come in handy. Just naming it something else, doesn't mean you aren't re-using and extending another BSP, just that you want a different name for it.20:54
v0nalso what would be the best practice strategy for handling a different platform in the future (let's say the second iteration of your hardware is based on Rpi now) or even qemu?20:55
zeddiikeep machine things in a separate BSP layer. That way you'd switch out the layer for the different platform when you move on. and in theory, everything else isn't impacted.20:56
v0n(since yocto seems to be designed around the fact that you can "swap" layers to build the same software around different hardware, I feel like I have to solve this before going further with yocto, sorry for being that verbose :))20:56
v0nzeddii: thank you. Would you see an in-house designed daughterboard for beaglebone as a different layer (requiring the beaglebone or custom BSP layer), or as a new machine?21:02
zeddiiI don't think there's a definitive answer to that, but depending on the config, the overlays, connectivity required for the daughterboard, I'd go with a separate machine (that both inherits the beagle and defines what the daughterboard needs). But I haven't looked at the TI layers in a while to see how they handle daughterboards.21:06
moto-timoin general, you are going to get better board support from the vendor... that is outside the scope of what the reference platforms are trying to do21:07
moto-timowe are only trying to use the reference platform to have a reasonably available hardware target21:07
moto-timothere are folks that wish the machine name in poky was not beaglebone at all, but at the time it made sense21:08
moto-timobut the project has no where near enough resources to deal with the thrash of official vendor support on the reference platforms21:09
moto-timoeither the vendor contributes that directly or we simply have a scaled back subset of features21:09
v0nthat's kind of the problem of having an "external layers" approach, compared to built-in drivers/modules/whatever, like the kernel that you can enable or not.21:12
v0nThat's why I was very skeptical to yocto at first, because manufacturers will publish their layers and forget about it, like some does with custom kernels. The support is better when it gets contributed upstream directly.21:13
*** wz <wz!> has joined #yocto21:17
v0nzeddii: I undestand that defining a new machine for the beaglebone+daughterboard is better because in an ideal world, I would like to have my distro built for MACHINE = "custom-bbb-hw" and even MACHINE = "beaglebone" for a generic development environement not sharing the daughter board specifics because you know, IP and stuffs.21:29
v0n(so I don't want the "beaglebone" machine to be extended in fact, because it does mean the stock public board, not a customized one.)21:29
*** mattsm <mattsm!> has quit IRC21:38
*** wz <wz!> has quit IRC21:51
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto21:52
*** konsgnxx <konsgnxx!> has quit IRC22:01
*** mattsm <mattsm!> has joined #yocto22:06
*** kiwi_29_ <kiwi_29_!> has joined #yocto22:17
*** jleightcap <jleightcap!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has quit IRC22:19
*** jleightcap <jleightcap!> has joined #yocto22:21
*** otavio__ <otavio__!> has joined #yocto22:23
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC22:23
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:28
*** beneth <beneth!> has left #yocto22:31
*** kiwi_29_ <kiwi_29_!> has quit IRC22:33
*** King_InuYasha is now known as Conan_Kudo22:58
*** Conan_Kudo is now known as King_InuYasha22:58
*** agust <agust!> has quit IRC23:16

Generated by 2.17.2 by Marius Gedminas - find it at!