*** vineela <vineela!vtummala@nat/intel/x-kcsbwwkkzuibcrdc> has joined #yocto | 00:01 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 00:04 | |
*** DanZ <DanZ!49e55fc8@c-73-229-95-200.hsd1.co.comcast.net> has joined #yocto | 00:09 | |
*** DanZ <DanZ!49e55fc8@c-73-229-95-200.hsd1.co.comcast.net> has left #yocto | 00:10 | |
*** bps3 <bps3!~bps@80.71.142.18> has joined #yocto | 00:11 | |
*** lukma <lukma!~lukma@89-64-25-12.dynamic.chello.pl> has quit IRC | 00:16 | |
*** bps3 <bps3!~bps@80.71.142.18> has quit IRC | 00:30 | |
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.101.91> has quit IRC | 00:30 | |
*** lukma <lukma!~lukma@89-64-25-12.dynamic.chello.pl> has joined #yocto | 00:30 | |
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.101.91> has joined #yocto | 00:33 | |
*** bps3 <bps3!~bps@80.71.142.18> has joined #yocto | 00:33 | |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 00:46 | |
*** jkprg <jkprg!~jkprg@jkprgvip.z.praha12.net> has quit IRC | 00:51 | |
*** jkprg <jkprg!~jkprg@jkprgvip.z.praha12.net> has joined #yocto | 00:52 | |
*** vineela <vineela!vtummala@nat/intel/x-kcsbwwkkzuibcrdc> has quit IRC | 00:55 | |
*** hpsy <hpsy!~hpsy@92.118.12.22> has quit IRC | 01:04 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 01:07 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 01:08 | |
*** mbulut <mbulut!~nameclash@ip1f128e0d.dynamic.kabel-deutschland.de> has quit IRC | 01:38 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 01:45 | |
*** jkprg <jkprg!~jkprg@jkprgvip.z.praha12.net> has quit IRC | 01:46 | |
*** rpcme <rpcme!345f0407@52.95.4.7> has quit IRC | 01:54 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 01:54 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 01:56 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:08 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:08 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 02:08 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 02:23 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 02:24 | |
*** camus is now known as kaspter | 02:24 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 02:40 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 02:45 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 02:45 | |
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto | 02:47 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:52 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:55 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:58 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 02:58 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 02:59 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 03:08 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 03:10 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 03:10 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 03:13 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:21 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 03:34 | |
*** ahadi <ahadi!~ahadi@i5E86AE08.versanet.de> has quit IRC | 03:49 | |
*** ahadi <ahadi!~ahadi@88.130.221.104> has joined #yocto | 03:50 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 04:04 | |
*** gonkulator <gonkulator!~brandon@75.71.150.20> has quit IRC | 04:26 | |
*** gonkulator <gonkulator!~brandon@75.71.150.20> has joined #yocto | 04:30 | |
*** NiksDev <NiksDev!~NiksDev@192.91.75.30> has quit IRC | 04:31 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 04:58 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 04:59 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 05:05 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 05:09 | |
*** Mr_Singh_ <Mr_Singh_!~Mr_Singh@2607:fea8:bdf:dda2:4908:564f:8430:8c41> has quit IRC | 05:23 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 05:32 | |
*** jobroe <jobroe!~manjaro-u@p579eb3c2.dip0.t-ipconnect.de> has joined #yocto | 05:35 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 05:37 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 05:38 | |
*** camus is now known as kaspter | 05:39 | |
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC | 05:49 | |
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 05:52 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 06:01 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 06:01 | |
*** camus is now known as kaspter | 06:01 | |
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 06:13 | |
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has joined #yocto | 06:18 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zqgrxdtkitxbuyfs> has quit IRC | 06:29 | |
*** meow` <meow`!~sbourdeli@107.159.31.190> has quit IRC | 06:29 | |
*** meow` <meow`!~sbourdeli@107.159.31.190> has joined #yocto | 06:30 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 06:30 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 06:32 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 06:33 | |
*** camus is now known as kaspter | 06:33 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 06:33 | |
*** Mr_Singh_ <Mr_Singh_!~Mr_Singh@cpe889e683666fd-cm889e683666fb.cpe.net.cable.rogers.com> has joined #yocto | 06:38 | |
*** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has joined #yocto | 06:39 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 06:39 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC | 06:42 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:45 | |
*** Mr_Singh_ <Mr_Singh_!~Mr_Singh@cpe889e683666fd-cm889e683666fb.cpe.net.cable.rogers.com> has quit IRC | 06:47 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 06:49 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 06:51 | |
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 06:59 | |
*** DanmerZ <DanmerZ!~op@46.150.10.5> has joined #yocto | 07:06 | |
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 07:15 | |
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 07:17 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:17 | |
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 07:26 | |
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:9b5:3ed5:8608:6454> has quit IRC | 07:31 | |
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:8d87:d553:3a99:8ac1> has joined #yocto | 07:33 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:34 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 07:35 | |
*** camus is now known as kaspter | 07:35 | |
*** Shikadi` <Shikadi`!~Shikadi@135.30.27.136.in-addr.arpa> has quit IRC | 07:35 | |
*** meego_ <meego_!~meego@2a01:e0a:1ec:b0e0:c932:4fcb:2a9a:e761> has joined #yocto | 07:36 | |
*** meego__ <meego__!~meego@2a01:e0a:1ec:b0e0:e0bd:ca5b:2a5a:35b2> has joined #yocto | 07:37 | |
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:8d87:d553:3a99:8ac1> has quit IRC | 07:38 | |
mcfrisk | what 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 #yocto | 07:38 | |
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-rkguvahxfaqbtscp> has joined #yocto | 07:39 | |
*** agust <agust!~agust@p5483339b.dip0.t-ipconnect.de> has joined #yocto | 07:39 | |
*** meego_ <meego_!~meego@2a01:e0a:1ec:b0e0:c932:4fcb:2a9a:e761> has quit IRC | 07:40 | |
*** meego___ <meego___!~meego@2a01:e0a:1ec:b0e0:59ed:b5bc:c892:4af7> has joined #yocto | 07:40 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 07:41 | |
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 07:41 | |
*** meego__ <meego__!~meego@2a01:e0a:1ec:b0e0:e0bd:ca5b:2a5a:35b2> has quit IRC | 07:42 | |
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:84a5:fd88:7e20:615e> has quit IRC | 07:43 | |
zyga | good morning | 07:43 |
*** mckoan|away is now known as mckoan | 07:44 | |
mckoan | good morning | 07:44 |
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:7c53:e0f:b7a:5c32> has joined #yocto | 07:45 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 07:45 | |
*** meego___ <meego___!~meego@2a01:e0a:1ec:b0e0:59ed:b5bc:c892:4af7> has quit IRC | 07:45 | |
LetoThe2nd | yo dudX | 07:46 |
*** meego_ <meego_!~meego@2a01:e0a:1ec:b0e0:8d7d:13e:4810:8b25> has joined #yocto | 07:47 | |
*** mmurto <mmurto!55c2ed82@85-194-237-130.s1networks.fi> has joined #yocto | 07:47 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC | 07:49 | |
*** meego <meego!~meego@2a01:e0a:1ec:b0e0:7c53:e0f:b7a:5c32> has quit IRC | 07:49 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 07:51 | |
*** meego_ <meego_!~meego@2a01:e0a:1ec:b0e0:8d7d:13e:4810:8b25> has quit IRC | 07:52 | |
*** frwol <frwol!~frwol@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 07:53 | |
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has joined #yocto | 07:53 | |
mmurto | I'm trying to build core-image-sato on 3.2, but I'm running into an error fetching http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/d/docbook-xml/docbook-xml_4.5.orig.tar.gz. Multiple tries, always "Read error at byte 14600/421525 (Connection reset by peer)." Anyone else or is it something on my end? | 07:54 |
mckoan | mmurto: try a manual wget | 08:02 |
mmurto | mckoan: Same failure manually | 08:06 |
mmurto | Tried on an external vpn and it works, so probably something to do with my network config. | 08:08 |
*** TPRoberts <TPRoberts!~TPRoberts@37.48.229.2> has joined #yocto | 08:13 | |
*** mbulut <mbulut!~nameclash@ip1f128e0d.dynamic.kabel-deutschland.de> has joined #yocto | 08:14 | |
*** tnovotny <tnovotny!~tnovotny@176-74-132-138.netdatacomm.cz> has joined #yocto | 08:17 | |
LetoThe2nd | mmurto: 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!~guillaume@176-172-89-74.abo.bbox.fr> has joined #yocto | 08:24 | |
mmurto | LetoThe2nd: 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 |
LetoThe2nd | mmurto: 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 |
mmurto | LetoThe2nd: Can't blame them too much, as the quick build documentation uses sato as the example ;) | 08:30 |
LetoThe2nd | mmurto: does it? | 08:31 |
LetoThe2nd | qschulz: hey mister documentation, thoughts on this? ;-) | 08:31 |
*** mbulut <mbulut!~nameclash@ip1f128e0d.dynamic.kabel-deutschland.de> has quit IRC | 08:32 | |
mmurto | LetoThe2nd: Yep, at least here: https://docs.yoctoproject.org/brief-yoctoprojectqs/brief-yoctoprojectqs.html | 08:33 |
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@80.71.142.18> has quit IRC | 08:33 | |
LetoThe2nd | Good point. Maybe we should change that to something more sensible. | 08:35 |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 08:36 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 08:36 | |
*** creich <creich!~creich@p200300f6af0a9910000000000000039b.dip0.t-ipconnect.de> has quit IRC | 08:44 | |
*** creich <creich!~creich@p200300f6af0a9910000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 08:45 | |
*** meego <meego!~meego@62.23.104.2> has joined #yocto | 08:53 | |
*** mbulut <mbulut!~nameclash@ip1f128e0d.dynamic.kabel-deutschland.de> has joined #yocto | 08:57 | |
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC | 08:57 | |
*** meego <meego!~meego@62.23.104.2> has quit IRC | 08:58 | |
*** hpsy <hpsy!~hpsy@92.118.12.22> has joined #yocto | 09:05 | |
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 09:33 | |
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto | 09:35 | |
qschulz | LetoThe2nd: 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@83.80.130.15> has quit IRC | 09:42 | |
Ad0 | I 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 mounts | 09:44 |
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto | 09:45 | |
LetoThe2nd | qschulz: 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 IRC | 09:50 | |
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto | 09:51 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 10:02 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 10:02 | |
*** mbulut <mbulut!~nameclash@ip1f128e0d.dynamic.kabel-deutschland.de> has quit IRC | 10:04 | |
*** meego <meego!~meego@2001:41d0:fe7e:c800:88c4:e895:3c95:5a56> has joined #yocto | 10:09 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 10:11 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 10:41 | |
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC | 10:41 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 10:43 | |
*** camus is now known as kaspter | 10:43 | |
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto | 10:43 | |
*** TPRoberts <TPRoberts!~TPRoberts@37.48.229.2> has quit IRC | 10:52 | |
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has quit IRC | 11:03 | |
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has joined #yocto | 11:09 | |
*** jleightcap <jleightcap!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has joined #yocto | 11:18 | |
wyre | what's the point of making the difference between a distro and a image recipe? | 11:20 |
*** ptsneves <ptsneves!b0dd7824@176.221.120.36> has joined #yocto | 11:22 | |
ptsneves | Hey all. I am constantly getting pseudo aborts due to .python-history being created by python | 11:23 |
qschulz | wyre: a distro is how you do things, image is what you want. | 11:23 |
ptsneves | has anybody had the issue? | 11:23 |
qschulz | you select your init system in a distro, not in an image | 11:23 |
qschulz | there's a very important different between a distro and an image. One is a conf file, the other a recipe | 11:24 |
qschulz | and Yocto chant #1 taught us: conf data is global, recipe data is local. | 11:24 |
qschulz | which means, you cannot impact other recipes from a recipe, only from a conf file. | 11:25 |
wyre | qschulz, thank you very much for the clarification 😊 | 11:25 |
paulbarker | wyre: I recommend looking at the poky distro config and then the core-image-base & core-image-full-cmdline recipes to see how it fits together | 11:27 |
LetoThe2nd | qschulz: https://youtu.be/o-8g0TPVVGg :) | 11:27 |
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto | 11:34 | |
qschulz | wyre: ^ | 11:34 |
*** loblik <loblik!a5e150fc@165.225.80.252> has joined #yocto | 11:36 | |
*** creich <creich!~creich@p200300f6af0a9910000000000000039b.dip0.t-ipconnect.de> has quit IRC | 11:37 | |
wyre | paulbarker, I've been checking the full-cmdline recipe and ... I'm wondering why is not appending to the IMAGE_INSTALL var? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/images/core-image-full-cmdline.bb#n6 | 11:39 |
wyre | could be due it's inheriting form a class instead requiring another recipe? 🤔 | 11:41 |
*** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 11:54 | |
*** creich <creich!~creich@p200300f6af0a9910000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 11:56 | |
*** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 12:00 | |
*** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has joined #yocto | 12:13 | |
*** mmurto <mmurto!55c2ed82@85-194-237-130.s1networks.fi> has quit IRC | 12:15 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 12:20 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC | 12:20 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 12:20 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 12:25 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 12:33 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 12:33 | |
paulbarker | wyre: 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 directly | 12:35 |
paulbarker | It's like you don't have to use `SRC_URI_append` in a recipe, you just go ahead and set `SRC_URI` | 12:35 |
wyre | then where you have to use `_append` or `+=` ? (if not in a recipe, I mean) | 12:36 |
rburton | kanavin_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 |
qschulz | wyre: _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 resolved | 12:38 |
wyre | qschulz, I know that, I mean, if I don't need to use append in a image recipe ... where is intended to use? | 12:38 |
qschulz | you 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 it | 12:39 |
qschulz | also, if you want to add to a variable only in the case of a machine, you need to use _append_<machine> | 12:39 |
rburton | kanavin_home: no matter, found it | 12:39 |
qschulz | because FOO_machine += will replace FOO | 12:39 |
*** robert1 <robert1!~robert@user-5-173-160-16.play-internet.pl> has joined #yocto | 12:39 | |
qschulz | instead of appending to it | 12:39 |
loblik | I'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 |
wyre | so `VAR += "whatever"` and `VAR_append = " whatever"` are not exactly equivalents, qschulz? | 12:41 |
loblik | Or can I specify a default somehow and use the other configuration only for system controller package? | 12:41 |
*** robert1 is now known as robertd | 12:43 | |
rburton | hm i wonder what the best way of saying in a tune "can't build linux" | 12:45 |
qschulz | wyre: definitely not equivalents | 12:46 |
wyre | qschulz, 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 |
LetoThe2nd | building gatesgarth core-image-minimal in 80s: hot sstate and pcie nvme :) | 12:50 |
rburton | nice! | 12:50 |
LetoThe2nd | ayup | 12:50 |
rburton | tell my CI runner to get a wriggle on, takes 5 minutes from clean tmp with sstate | 12:51 |
rburton | which isn't that bad but there's 11 machines to run through | 12:51 |
qschulz | wyre: variables that apply to machines or distros only need to be defined in conf files, otherwise "it depends" | 12:52 |
LetoThe2nd | rburton: 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 IRC | 13:29 | |
*** dv|2 <dv|2!~dv@5.167.98.73> has joined #yocto | 13:30 | |
dv|2 | how can I define what package managemenet tool to use in the image (if I enable both RPM and DEB in my conf)? | 13:31 |
rburton | dv|2: first one builds the image | 13:31 |
dv|2 | rburton, sorry? | 13:32 |
rburton | where you set PACKAGE_CLASSES = "package_rpm package_deb" | 13:32 |
rburton | the first one in the list, builds the imag | 13:32 |
rburton | so that would build both rpms and debs, but rpm is used to build the image and is the installed tool | 13:33 |
dv|2 | rburton, I set it in my local.conf | 13:34 |
dv|2 | I am building several images with the same config. May I set it per-image? | 13:34 |
LetoThe2nd | what is the usecase? | 13:40 |
dv|2 | LetoThe2nd, to have two images: one is my own repos, another may use debian/ubuntu repos | 13:45 |
*** Yumasi <Yumasi!~guillaume@176-172-89-74.abo.bbox.fr> has quit IRC | 13:45 | |
LetoThe2nd | that sounds extramely fishy, to say the least. | 13:46 |
dv|2 | LetoThe2nd, 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 linuxois | 13:48 |
LetoThe2nd | i can't see that making sense.. but hey, its your "people" | 13:49 |
*** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 13:50 | |
dorinda | Hi 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|2 | LetoThe2nd, 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 all | 13:52 |
LetoThe2nd | dv|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 |
LetoThe2nd | dorinda: howdy there! welcome on board! | 13:53 |
dv|2 | LetoThe2nd, 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 |
LetoThe2nd | dv|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 |
qschulz | dorinda: o/ | 13:55 |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:55 | |
ecdhe | I 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|2 | LetoThe2nd, if I can define it in distro with the same local.conf - it is ok. Can I? | 13:57 |
ecdhe | What 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 |
LetoThe2nd | dv|2: i don't get why you're so totally insisting on "single local.conf" | 13:58 |
ecdhe | Is there an intermediate directory I can install their files into where a third recipe can find them? | 13:58 |
*** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has quit IRC | 13:58 | |
LetoThe2nd | dv|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 |
JPEW | ecdhe: Yes, you want to deploy the files... do_deploy | 13:59 |
JPEW | Then 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 |
LetoThe2nd | dorinda: type the first couple of letters of the nick, then press tab :) | 14:00 |
ecdhe | Okay JPEW, I'll give that a try. Is that the only canonical holding tank for intermediate files? | 14:01 |
dv|2 | 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 help | 14:01 |
dorinda | LetoThe2nd: oh great thanks 😊 | 14:01 |
dv|2 | LetoThe2nd, 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 help | 14:01 |
LetoThe2nd | dv|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!~tnovotny@176-74-132-138.netdatacomm.cz> has quit IRC | 14:02 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-newlcgobaocajeyy> has joined #yocto | 14:03 | |
JPEW | ecdhe: 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 |
rburton | welcome dorinda :) | 14:04 |
dorinda | qschulz: "o/" don't know what that means, but i assume its a welcome, thank you :) | 14:04 |
rburton | it's one half of a high five | 14:04 |
JPEW | ecdhe: 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 |
rburton | \o | 14:04 |
dorinda | rburton: | 14:04 |
rburton | dorinda: o/ \o. <-- two people high fiving | 14:05 |
paulbarker | I've used IRC for well over a decade and never seen that one before haha | 14:05 |
dorinda | rburton: ohh thank you :) | 14:05 |
JPEW | Should be more like o/ \o these days | 14:05 |
ecdhe | JPEW: 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 |
rburton | JPEW: lol | 14:06 |
rburton | paulbarker: kids these days | 14:06 |
*** TobSnyder <TobSnyder!~schneider@p54aa8f7f.dip0.t-ipconnect.de> has joined #yocto | 14:06 | |
qschulz | dorinda: 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 |
TobSnyder | Am I allowed to change DISTRO_NAME within recipes-core/images/my-custom-image.bb ? | 14:06 |
ecdhe | JPEW: so do I put ${DEPLOY_IMAGE_DIR} in my SRC_URI? Or just assume that the assets I need are there already? | 14:06 |
TobSnyder | Or is it only allowed to change DISTRO_NAME in conf/distro/mydistro.conf ? | 14:07 |
rburton | TobSnyder: what do you expect to happen when you change it in an image? | 14:07 |
LetoThe2nd | TobSnyder: please apply yocto chant #1 and think about your question again. | 14:07 |
JPEW | ecdhe: In your "assembly" task (which I will call do_assemble for example), you would just directly reference ${DEPLOY_DIR_IMAGE} | 14:07 |
dorinda | qschulz: lol alright. funny signs though | 14:08 |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 14:08 | |
TobSnyder | what is yocto chant #1? | 14:08 |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 14:08 | |
LetoThe2nd | TobSnyder: https://www.instagram.com/p/CBgEgS_jXTD/?utm_source=ig_web_copy_link | 14:09 |
JPEW | ecdhe: 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 |
JPEW | ecdhe: That ensure the deploy artifacts will be present in the deploy directory by the other recipes before the do_assemble task runs | 14:10 |
* JPEW looks for an example.... | 14:10 | |
JPEW | ecdhe: It's not a third recipe pulling in from two others, but here is an example: https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/recipes-bsp/u-boot/u-boot%25.bbappend | 14:12 |
JPEW | ecdhe: This u-boot recipe pulls ATF from ${DEPLOY_DIR_IMAGE} during do_compile to add it to the u-boot image | 14:13 |
qschulz | ecdhe: i think you could actually do the merging into boot.bin from the image recipe | 14:13 |
idadel | Hello 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 |
TobSnyder | I 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 I | 14: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 |
TobSnyder | So how to solve this? | 14:14 |
qschulz | idadel: \o | 14:14 |
Ad0 | is 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 |
qschulz | TobSnyder: 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 |
LetoThe2nd | TobSnyder: in a custom DISTRO, sure. thats what its meant for. in an image: no. | 14:17 |
LetoThe2nd | idadel: howdy there too! | 14:20 |
tlwoerner | dorinda: o/ nice to meet you! welcome to the project/community | 14:26 |
dorinda | tlwoerner: \o nice meeting you too! thank you :) | 14:29 |
tlwoerner | idadel: hi! o/ | 14:32 |
rburton | qschulz: what have you done now everyone is waving! ;) | 14:33 |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 14:33 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 14:33 | |
tlwoerner | ecdhe: 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 pieces | 14:33 |
*** dv|2 <dv|2!~dv@5.167.98.73> has quit IRC | 14:34 | |
*** ayaka <ayaka!~ayaka@103.42.215.143> has joined #yocto | 14:34 | |
qschulz | rburton: \o~ ~o~ ~o/ | 14:35 |
idadel | qschulz: | 14:35 |
rburton | qschulz: what's that one?! | 14:35 |
qschulz | rburton: or whatever can look like a dance :p | 14:35 |
idadel | qschulz: o/ | 14:35 |
ayaka | before the filesystem I compiled from yocto can load the debug symbols auto | 14:35 |
ayaka | but recently I may just update my host system, the debug file compiled from yocto, it's debug symbols won't be loaded by gdb auto | 14:36 |
ayaka | is there any related configure ? | 14:36 |
idadel | LetoThe2nd: We e-meet again! :) | 14:37 |
*** jobroe <jobroe!~manjaro-u@p579eb3c2.dip0.t-ipconnect.de> has quit IRC | 14:37 | |
idadel | tlwoerner: o/ | 14:37 |
dorinda | qschulz: lol | 14:38 |
LetoThe2nd | idadel: i'm hard to miss in terms of yocto during european office times! | 14:38 |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-lmcsjkxslwtyaqkb> has joined #yocto | 14:43 | |
TobSnyder | qschulz: 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 SDKs | 14:47 |
*** konsgnxx <konsgnxx!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 14:48 | |
TobSnyder | so 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.conf | 14:49 |
LetoThe2nd | TobSnyder: so why not create a common-distro.inc and pull it in in two distint distros, that just override the particular bits? | 14:50 |
*** rcw <rcw!~rcwoolley@104.247.231.196> has joined #yocto | 14:50 | |
TobSnyder | ok so this would also be some possible way, resulting in just also creating another distro.conf in the layer that contains the application image | 14:56 |
LetoThe2nd | yup. a classic approach, if you ask me. | 14:57 |
sgw | rburton: RP: Morning | 14:58 |
rburton | morning sgw | 14:58 |
sgw | Before I go digging to deep did one of you already look at the build failure ? | 14:59 |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 14:59 | |
LetoThe2nd | "the build failure" | 15:00 |
* LetoThe2nd starts giggling uncontrollably, progressing into mad laughter and rolling on the office florr | 15:00 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 15:02 | |
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 15:06 | |
rburton | sgw: i haven't and RP has been out all morning, so i think its on you :) | 15:08 |
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-08-142-114-156-131.dsl.bell.ca> has joined #yocto | 15:09 | |
sgw | rburton: thanks, just did not want to duplicate effort. the systemd packaging failure seems interesting and really random! | 15:10 |
*** psiva87 <psiva87!45fde314@c-69-253-227-20.hsd1.pa.comcast.net> has joined #yocto | 15:15 | |
RP | sgw: rburton is correct, I've not been around until now | 15:15 |
sgw | RP hope you where out for some fun and adventure! I am looking into the 3 issues from the full build. | 15:17 |
*** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has joined #yocto | 15:17 | |
RP | sgw: I got soaked and very muddy ;-) | 15:18 |
psiva87 | Thanks bluelightning, can I add SYSROOT_DIRS += "${bindir}" if we want the binary in rootfs. | 15:18 |
sgw | that means fun! | 15:20 |
qschulz | JaMa: too fast for me :/ | 15:23 |
*** davidinux <davidinux!~davidinux@185.183.105.28> has quit IRC | 15:23 | |
TobSnyder | LetoThe2nd: just for my understanding your proposal would mean I will have a distro for each image probably | 15:25 |
*** davidinux <davidinux!~davidinux@37.179.242.118> has joined #yocto | 15:25 | |
RP | sgw: I might agree when I warm up a bit :) | 15:27 |
LetoThe2nd | If your usecase mandates this it is possible, of course | 15:28 |
qschulz | psiva87: no, FILES_ is what you're looking for | 15:28 |
qschulz | SYSROOT_DIRS is a way to make files available to other recipes at build time | 15:29 |
qschulz | psiva87: 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 IRC | 15:30 | |
TobSnyder | If 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 |
Ad0 | is 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 |
qschulz | Ad0: there exists support for config fragments | 15:32 |
Ad0 | oh yeah I totally forgot about that, I thought it was restricted to kernel only | 15:33 |
qschulz | TobSnyder: it'll work just fine | 15:33 |
Ad0 | thanks | 15:33 |
qschulz | Ad0: it's on a per-recipe basis | 15:33 |
Ad0 | nice | 15:33 |
qschulz | not all kernel recipes actually support config fragments | 15:33 |
qschulz | Ad0: no, I think you misunderstood if you said nice :p | 15:33 |
Ad0 | LOL | 15:34 |
Ad0 | I said "nice" to the fact that you reminded me of the fragments stuff | 15:34 |
qschulz | Ad0: ack | 15:34 |
Ad0 | sorry for being unclear | 15:34 |
Ad0 | also I might switch back to openssh instead of dropbear | 15:34 |
qschulz | Ad0: no worries, how I phrased my sentence was also not great ;) | 15:35 |
Ad0 | hehe | 15:35 |
qschulz | Ad0: what for? | 15:35 |
Ad0 | I mean I did dropbear -i -r /var/lib/dropbear/dropbear_rsa_host_key -p [127.0.0.1]:22 -p [::1]:22 -s | 15:35 |
Ad0 | still binds to 0.0.0.0 since I can connect from LAN | 15:35 |
Ad0 | tcp 0 0 :::22 :::* LISTEN | 15:35 |
Ad0 | seems like it completely ignores it (v2019.78 found in Warrior) | 15:36 |
Ad0 | it seems a bit silly to fiddle with ipchain to fix it | 15:36 |
*** davidinux <davidinux!~davidinux@37.179.242.118> has quit IRC | 15:46 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:47 | |
ecdhe | thanks JPEW, got that working | 15:58 |
ecdhe | thanks tlwoerner, yes, the rockchip situation is pretty similar | 15:58 |
qschulz | JPEW: I guess it's time to start bisecting the kernel :) | 16:00 |
ecdhe | So 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 |
JPEW | qschulz: 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!d9d0c05b@217-208-192-91-no98.tbcn.telia.com> has joined #yocto | 16:00 | |
lxc | can ipk package manager be used to update the boot and kernel? | 16:01 |
ecdhe | I modified myrecipe.bb to include the line PROVIDES = "myrecipe" but still no luck | 16:02 |
JPEW | ecdhe: Is the 'myrecipe' package created by myrecipe.bb empty (no files?) | 16:03 |
tlwoerner | qschulz: Ad0: i think config fragments only works with kernel, not busybox? | 16:03 |
JPEW | ecdhe: That happens a lot with recipes that are only a static library | 16:03 |
JPEW | ecdhe: .... or recipes that only deploy something ;) | 16:04 |
ecdhe | JPEW: yes, it only deploys something | 16:05 |
ecdhe | it does have 'inherit deploy' | 16:05 |
JPEW | ecdhe: Ya, in that case installing the "package" doesn't really make any sense | 16:05 |
JPEW | By default, bitbake will not generate an (ipk,deb,rpm) for any package that doesn't contain any files | 16:06 |
JPEW | This is the same problem bobbyJ was having yesterday | 16:06 |
ecdhe | yeah, and in this case I want to install files onto the FAT partition of my SD card, not the ext partition | 16:06 |
ecdhe | It would be nice if there was a concept of an additional filesystem | 16:07 |
*** Ninic0c0 <Ninic0c0!5a5cde4f@lfbn-idf2-1-1163-79.w90-92.abo.wanadoo.fr> has joined #yocto | 16:07 | |
JPEW | Are you using wic? | 16:07 |
ecdhe | no? | 16:07 |
JPEW | ecdhe: wic lets you do that FWIW.... I *highly* recommend using it | 16:08 |
Ninic0c0 | Hi 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 |
ecdhe | JPEW, looks neat | 16:09 |
ecdhe | It 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 file | 16:11 |
*** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-33-174-93-106-232.dsl.bell.ca> has joined #yocto | 16:13 | |
matthewcroughan | Does anyone know what the MACHINE name is for qemux86_64? | 16:13 |
matthewcroughan | Is that the correct machine name? | 16:13 |
matthewcroughan | is there a list of all yocto supported machines? | 16:14 |
JPEW | ecdhe: The key is --sourceparams="loader=u-boot" on line 23: https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/wic/rk3399-boot.wks#n23 | 16:18 |
codyps | matthewcroughan: 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 machines | 16:18 |
codyps | many layers (bsp layers) exist solely to add various MACHINEs | 16:19 |
JPEW | ecdhe: Then, you can control what files are put in that partition with WKS_FILE_DEPENDS/WKS_BOOT_FILES: https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/conf/machine/rock-pi-4.conf | 16:19 |
codyps | matthewcroughan: `qemux86-64` is a valid machine name (provided by openembedded-core) | 16:20 |
*** robertd <robertd!~robert@user-5-173-160-16.play-internet.pl> has quit IRC | 16:21 | |
*** lxc <lxc!d9d0c05b@217-208-192-91-no98.tbcn.telia.com> has quit IRC | 16:21 | |
codyps | If you're using `poky`, you can find it in `meta/conf/machine/qemux86-64.conf` | 16:21 |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-newlcgobaocajeyy> has quit IRC | 16:23 | |
marex | khem: have you seen clang segfault while linking chromium before ? | 16:25 |
marex | khem: seems both clang10 and clang11 does | 16:26 |
ecdhe | JPEW: 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 |
qschulz | tlwoerner: no there is support for config fragments with busybox | 16:38 |
qschulz | tlwoerner: see all the .cfg files in https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-core/busybox/busybox_1.32.0.bb | 16:39 |
*** davidinux <davidinux!~davidinux@37.120.137.9> has joined #yocto | 16:40 | |
qschulz | matthewcroughan: find all machines in all layers by doing finding the .conf files in meta-*/conf/machine/ | 16:41 |
qschulz | it's probably qemux86-64 since underscores aren't supported in machine names | 16:41 |
tlwoerner | qschulz: awesome, thanks for the update | 16:41 |
qschulz | matthewcroughan: c.f. https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/machine/qemux86-64.conf | 16:41 |
*** frsc <frsc!~frsc@85-78-142-46.pool.kielnet.net> has joined #yocto | 16:45 | |
*** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has quit IRC | 16:46 | |
*** davidinux <davidinux!~davidinux@37.120.137.9> has quit IRC | 16:47 | |
*** frsc <frsc!~frsc@85-78-142-46.pool.kielnet.net> has quit IRC | 16:47 | |
*** davidinux <davidinux!~davidinux@37.179.242.118> has joined #yocto | 16:49 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 16:50 | |
*** bps3 <bps3!~bps@80.71.142.18> has joined #yocto | 16:56 | |
JPEW | ecdhe: That tells wic to populate the (FAT?) partition with files necessary for u-boot | 17:00 |
*** frwol <frwol!~frwol@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 17:00 | |
JPEW | ecdhe: Sorry, I link I pointed you in the wrong direction... | 17:03 |
JPEW | You only need the --source bootimg-paritition which will copy the files specified in WKS_BOOT_FILES | 17:03 |
JPEW | The --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 kernel | 17:04 |
JPEW | If you've modified u-boot with your own boot flow, you don't need that | 17:05 |
tlwoerner | JPEW: which conflicts with other u-boot tooling to create extlinux.cfg files :-( | 17:06 |
tlwoerner | (outside of wks) | 17:06 |
JPEW | tlwoerner: Maybe? We never use it because we use boot scripts instead | 17:07 |
JPEW | It looks like you can specify your own extlinux.cfg: bootloader --configfile="directdisk-bootloader-config.cfg" | 17:07 |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 17:07 | |
*** amitk_ is now known as amitk | 17:09 | |
JPEW | tlwoerner: 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 off | 17:09 |
JPEW | boot 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_FILES | 17:11 |
*** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto | 17:12 | |
JPEW | Ah, darn.... ecdhe: everywhere I previously said WKS_BOOT_FILES should be IMAGE_BOOT_FILES. My bad | 17:12 |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 17:12 | |
*** lexano <lexano!~lexano@cpeb03956d8c2f4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 17:16 | |
*** yann <yann!~yann@88.120.44.86> has quit IRC | 17:17 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 17:18 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 17:18 | |
*** lexano <lexano!~lexano@cpeb03956d8c2f4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 17:21 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 17:22 | |
*** yann <yann!~yann@88.120.44.86> has joined #yocto | 17:29 | |
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has quit IRC | 17:34 | |
*** mckoan is now known as mckoan|away | 17:36 | |
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto | 17:38 | |
*** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-33-174-93-106-232.dsl.bell.ca> has quit IRC | 17:39 | |
*** meego <meego!~meego@2001:41d0:fe7e:c800:88c4:e895:3c95:5a56> has quit IRC | 17:42 | |
tlwoerner | JPEW: 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 confusing | 17:43 |
tlwoerner | especially 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 |
Ninic0c0 | My basic custom recipe soens't populate recipeinfo anyone can point me a direction to fix that ? | 17:44 |
tlwoerner | in any case, it's somewhere on my todo list to see if the variables in one's machine.conf could be used by wks | 17:44 |
v0n | Trying 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@80.71.142.18> has quit IRC | 18:06 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 18:07 | |
JPEW | tlwoerner: Ah I didn't even know about those variables | 18:08 |
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-rkguvahxfaqbtscp> has quit IRC | 18:09 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 18:11 | |
*** davidinux <davidinux!~davidinux@37.179.242.118> has quit IRC | 18:12 | |
OutBackDingo | welp 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_64 | 18:12 |
OutBackDingo | tsk tsk tsk | 18:12 |
*** davidinux <davidinux!~davidinux@217.138.203.190> has joined #yocto | 18:13 | |
*** mbulut <mbulut!~nameclash@ip1f11b371.dynamic.kabel-deutschland.de> has joined #yocto | 18:19 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 18:20 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:24 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 18:35 | |
*** asteriusio <asteriusio!~derek@104-179-196-18.lightspeed.brhmal.sbcglobal.net> has quit IRC | 18:36 | |
*** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-33-174-93-106-232.dsl.bell.ca> has joined #yocto | 18:37 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 18:40 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 18:47 | |
*** davidinux <davidinux!~davidinux@217.138.203.190> has quit IRC | 18:50 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:51 | |
*** davidinux <davidinux!~davidinux@37.179.242.118> has joined #yocto | 18:52 | |
*** lexano <lexano!~lexano@cpeb03956d8c2f4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 18:58 | |
*** lexano <lexano!~lexano@cpeb03956d8c2f4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 19:01 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:02 | |
*** Ninic0c0 <Ninic0c0!5a5cde4f@lfbn-idf2-1-1163-79.w90-92.abo.wanadoo.fr> has quit IRC | 19:04 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:04 | |
*** davidinux <davidinux!~davidinux@37.179.242.118> has quit IRC | 19:05 | |
*** ecdhe_ <ecdhe_!~ecdhe@unaffiliated/ecdhe> has joined #yocto | 19:06 | |
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC | 19:09 | |
*** davidinux <davidinux!~davidinux@91.132.136.60> has joined #yocto | 19:09 | |
*** bps3 <bps3!~bps@80.71.142.18> has joined #yocto | 19:13 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 19:20 | |
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-lmcsjkxslwtyaqkb> has quit IRC | 19:22 | |
*** bps3 <bps3!~bps@80.71.142.18> has quit IRC | 19:25 | |
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC | 19:26 | |
*** mbulut <mbulut!~nameclash@ip1f11b371.dynamic.kabel-deutschland.de> has quit IRC | 19:29 | |
*** psiva87 <psiva87!45fde314@c-69-253-227-20.hsd1.pa.comcast.net> has quit IRC | 19:33 | |
codyps | v0n: sounds like some kind of alignment issue when loading from memory? thought the `linefetch` bit seems a bit more strict than normal | 19:36 |
v0n | codyps: yeah... can I be missing a kernel option or something? | 19:38 |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:44 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:49 | |
sgw | RP: 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 |
sgw | That's the high level, digging deeper | 19:57 |
*** bps3 <bps3!~bps@80.71.142.18> has joined #yocto | 19:59 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 20:03 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 20:03 | |
*** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has quit IRC | 20:06 | |
v0n | codyps: 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@80.71.142.18> has quit IRC | 20:08 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 20:10 | |
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 20:12 | |
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 20:14 | |
*** jleightcap <jleightcap!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has quit IRC | 20:18 | |
*** jleightcap <jleightcap!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has joined #yocto | 20:19 | |
*** Shikadi` <Shikadi`!~Shikadi@135.30.27.136.in-addr.arpa> has joined #yocto | 20:20 | |
*** konsgnxx <konsgnxx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 20:27 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 20:28 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 20:32 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 20:33 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 20:33 | |
v0n | Hey, why does Yocto define a new machine "beaglebone-yocto"? | 20:35 |
zeddii | because 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 |
v0n | hum 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 stuffs | 20:43 |
*** Konsgn <Konsgn!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 20:44 | |
*** Konsgn is now known as Guest4252 | 20:45 | |
*** Guest4252 is now known as konsgnxx | 20:49 | |
zeddii | there are no rules about anything like that. | 20:50 |
zeddii | it's just a hardware description. | 20:50 |
zeddii | and no, that would be way worse | 20:50 |
v0n | ok | 20:50 |
zeddii | trying to undo what a changing base does, means you chase your tail forever | 20:50 |
v0n | but isn't why yocto is designed for? extending existing machine and packages? | 20:50 |
zeddii | it's a use of it, sure | 20:51 |
v0n | ok | 20:51 |
v0n | zeddii: 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 |
zeddii | it 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 |
v0n | also 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 |
zeddii | keep 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 |
v0n | zeddii: 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 |
zeddii | I 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-timo | in 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 do | 21:07 |
moto-timo | we are only trying to use the reference platform to have a reasonably available hardware target | 21:07 |
moto-timo | there are folks that wish the machine name in poky was not beaglebone at all, but at the time it made sense | 21:08 |
moto-timo | but the project has no where near enough resources to deal with the thrash of official vendor support on the reference platforms | 21:09 |
moto-timo | either the vendor contributes that directly or we simply have a scaled back subset of features | 21:09 |
v0n | that'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 |
v0n | That'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!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 21:17 | |
v0n | zeddii: 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!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC | 21:38 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 21:51 | |
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto | 21:52 | |
*** konsgnxx <konsgnxx!~Konsgnx3@66-109-34-138.tvc-ip.com> has quit IRC | 22:01 | |
*** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto | 22:06 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:17 | |
*** jleightcap <jleightcap!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has quit IRC | 22:19 | |
*** jleightcap <jleightcap!~jleightca@c-174-60-161-106.hsd1.pa.comcast.net> has joined #yocto | 22:21 | |
*** otavio__ <otavio__!~otavio@200-180-244-15.user3p.brasiltelecom.net.br> has joined #yocto | 22:23 | |
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 22:23 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 22:28 | |
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 22:31 | |
*** kiwi_29_ <kiwi_29_!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 22:33 | |
*** King_InuYasha is now known as Conan_Kudo | 22:58 | |
*** Conan_Kudo is now known as King_InuYasha | 22:58 | |
*** agust <agust!~agust@p5483339b.dip0.t-ipconnect.de> has quit IRC | 23:16 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!