| *** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:8118:6d73:54b:c75b> has joined #yocto | 00:00 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has quit IRC | 00:00 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 00:33 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 00:34 | |
| *** camus is now known as kaspter | 00:34 | |
| *** ismailouch <ismailouch!~ismailouc@2a01:e0a:17a:9a50:1d5:4c97:6932:35a6> has joined #yocto | 00:35 | |
| *** kpo__ <kpo__!~kpo@gl226-39.master.pl> has quit IRC | 00:43 | |
| *** Wouter0100 <Wouter0100!~Wouter010@84-80-174-188.fixed.kpn.net> has quit IRC | 00:50 | |
| *** Wouter0100 <Wouter0100!~Wouter010@84-80-174-188.fixed.kpn.net> has joined #yocto | 00:51 | |
| *** extorr <extorr!extor@unaffiliated/extor> has joined #yocto | 00:55 | |
| *** Bunio_FH <Bunio_FH!~bunio@37.30.22.215.nat.umts.dynamic.t-mobile.pl> has quit IRC | 01:11 | |
| *** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:8118:6d73:54b:c75b> has quit IRC | 01:17 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.128> has joined #yocto | 01:26 | |
| *** Bunio_FH <Bunio_FH!~bunio@37.30.21.117.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 01:28 | |
| *** ismailouch <ismailouch!~ismailouc@2a01:e0a:17a:9a50:1d5:4c97:6932:35a6> has quit IRC | 01:30 | |
| *** extorr <extorr!extor@unaffiliated/extor> has quit IRC | 01:33 | |
| *** extorr <extorr!extor@unaffiliated/extor> has joined #yocto | 01:34 | |
| *** extorr <extorr!extor@unaffiliated/extor> has quit IRC | 01:39 | |
| *** extorr <extorr!extor@unaffiliated/extor> has joined #yocto | 01:40 | |
| *** rostam <rostam!~bgholikha@2601:644:8100:6650:f52b:2c7e:4dcc:94d3> has joined #yocto | 01:47 | |
| *** [Sno] <[Sno]!~sno@p4fe936f4.dip0.t-ipconnect.de> has joined #yocto | 02:01 | |
| *** sno <sno!~sno@p4fe93dfc.dip0.t-ipconnect.de> has quit IRC | 02:03 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 02:04 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 02:04 | |
| *** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:634d:583c:6674:c157:37fa> has joined #yocto | 02:06 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 02:32 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 02:32 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 02:33 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:c595:8045:5f62:447d> has quit IRC | 02:42 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.128> has quit IRC | 02:49 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:dc08:9c62:7698:5e41> has joined #yocto | 02:56 | |
| *** sno <sno!~sno@p4fe93f04.dip0.t-ipconnect.de> has joined #yocto | 03:01 | |
| *** [Sno] <[Sno]!~sno@p4fe936f4.dip0.t-ipconnect.de> has quit IRC | 03:03 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 03:06 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 03:07 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 03:14 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 03:17 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 03:17 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 03:33 | |
| *** ahadi <ahadi!~ahadi@88.130.217.180> has quit IRC | 03:57 | |
| *** Kyubi <Kyubi!~Kyubi@c-73-158-78-163.hsd1.ca.comcast.net> has joined #yocto | 03:59 | |
| *** ahadi <ahadi!~ahadi@i5E869133.versanet.de> has joined #yocto | 04:00 | |
| *** Kyubi_ <Kyubi_!~Kyubi@149.199.62.129> has joined #yocto | 04:06 | |
| *** Kyubi <Kyubi!~Kyubi@c-73-158-78-163.hsd1.ca.comcast.net> has quit IRC | 04:07 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ngmqeehnipnwaxko> has quit IRC | 04:20 | |
| *** ssajal_ <ssajal_!~ssajal@bras-base-otwaon1146w-grc-08-142-114-156-118.dsl.bell.ca> has quit IRC | 04:49 | |
| *** stacktru2t <stacktru2t!~stacktrus@cpe-68-174-158-185.nyc.res.rr.com> has quit IRC | 04:55 | |
| *** jobroe <jobroe!~manjaro-u@p579eb604.dip0.t-ipconnect.de> has joined #yocto | 04:56 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-187.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 05:04 | |
| *** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:634d:583c:6674:c157:37fa> has quit IRC | 05:17 | |
| *** stacktru1t <stacktru1t!~stacktrus@cpe-68-174-158-185.nyc.res.rr.com> has joined #yocto | 05:23 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 05:24 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 05:33 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 05:34 | |
| *** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:37 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 05:38 | |
| *** plntyk <plntyk!~plntyk@ip5b40590c.dynamic.kabel-deutschland.de> has joined #yocto | 05:43 | |
| *** Kyubi_ <Kyubi_!~Kyubi@149.199.62.129> has quit IRC | 06:02 | |
| *** vineela <vineela!vtummala@nat/intel/x-kshfkxcccdhmycdp> has quit IRC | 06:06 | |
| *** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:a90d:58fd:63e6:e420> has joined #yocto | 06:12 | |
| *** oobitots51 <oobitots51!ad26d108@aer01-mda1-dmz-wsa-3.cisco.com> has joined #yocto | 06:14 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 06:15 | |
| mcfrisk | hmm pseudo related trouble in dunfell, nativesdk recipes are failing at do_package with "Cannot change ownership to uid 0, gid 0: Operation not permitted" after applying poky updates from the past 6 weeks | 06:19 |
|---|---|---|
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 06:19 | |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 06:28 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:29 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 06:30 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:31 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 06:34 | |
| *** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:634d:583c:6674:c157:37fa> has joined #yocto | 06:35 | |
| *** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:634d:583c:6674:c157:37fa> has quit IRC | 06:37 | |
| *** agust <agust!~agust@pd95f1388.dip0.t-ipconnect.de> has joined #yocto | 06:57 | |
| *** jobroe <jobroe!~manjaro-u@p579eb604.dip0.t-ipconnect.de> has quit IRC | 07:00 | |
| *** jobroe <jobroe!~manjaro-u@p579eb604.dip0.t-ipconnect.de> has joined #yocto | 07:03 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto | 07:06 | |
| mcfrisk | so turns out S is now ignored by pseudo. So if anything sets S and expects permissions to be preserved from there will fail. As workaround don't use S to the path where files are but set S to WORKDIR and in do_install append the other paths. Not sure I follow this.. | 07:09 |
| *** sno <sno!~sno@p4fe93f04.dip0.t-ipconnect.de> has quit IRC | 07:13 | |
| *** dl9pf_home <dl9pf_home!~quassel@opensuse/member/dl9pf> has quit IRC | 07:18 | |
| *** sno <sno!~sno@p4fe93f04.dip0.t-ipconnect.de> has joined #yocto | 07:18 | |
| *** dl9pf_home <dl9pf_home!~quassel@static.253.98.203.116.clients.your-server.de> has joined #yocto | 07:18 | |
| *** dl9pf_home <dl9pf_home!~quassel@opensuse/member/dl9pf> has joined #yocto | 07:18 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 07:19 | |
| *** mrpelotaz0 <mrpelotaz0!~mrpelotaz@HSI-KBW-109-192-067-084.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 07:20 | |
| *** wertigon <wertigon!~per@c-6d61225c.021-396-7673741.bbcust.telenor.se> has joined #yocto | 07:24 | |
| *** sno <sno!~sno@p4fe93f04.dip0.t-ipconnect.de> has quit IRC | 07:29 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-187.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 07:31 | |
| wertigon | Hmmm, question - why does NodeJS always fail twice or thrice on a fresh compile on dunfell? If I compile again, it is no problem. | 07:32 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 07:32 | |
| wertigon | Build system is a Ryzen 3400G, 2x8 GB 3200 MHz DDR4 non-ecc memory, and an ssd SATA drive. | 07:34 |
| *** Spectrejan[m] <Spectrejan[m]!spectrejan@gateway/shell/matrix.org/x-scnteshgffyrzjuc> has joined #yocto | 07:34 | |
| wertigon | Could it be that I run out of RAM or CPU cores? | 07:35 |
| *** frsc <frsc!~frsc@i59F72919.versanet.de> has joined #yocto | 07:38 | |
| *** huseyinkozan <huseyinkozan!~hk@95.70.162.2> has joined #yocto | 07:38 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 07:39 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 07:41 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 07:41 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 07:42 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 07:42 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:43 | |
| *** kyrix <kyrix!~ashwoods@78.142.65.171> has joined #yocto | 07:46 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:ba39:67f5:3885:dbb6> has joined #yocto | 07:53 | |
| *** fl0v0 <fl0v0!~fvo@i5E86AFF3.versanet.de> has joined #yocto | 07:55 | |
| *** caiortp <caiortp!~caiortp@92-108-245-63.cable.dynamic.v4.ziggo.nl> has joined #yocto | 07:56 | |
| wertigon | As far as I can tell, my only nodejs recipes come from meta-oe. | 07:59 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:59 | |
| *** beratiks <beratiks!52de0992@82.222.9.146> has joined #yocto | 08:07 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC | 08:08 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 08:12 | |
| wertigon | Am I the only one seeing this consistently? :o | 08:12 |
| *** gsalazar <gsalazar!~gsalazar@173.111.90.149.rev.vodafone.pt> has quit IRC | 08:16 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 08:16 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 08:17 | |
| *** mckoan|away is now known as mckoan | 08:19 | |
| *** sno <sno!~sno@tmo-117-15.customers.d1-online.com> has joined #yocto | 08:21 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-109-192-066-054.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 08:21 | |
| *** yannholo <yannholo!~yannholo@fs-141-0-205-41.fullsave.info> has joined #yocto | 08:22 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC | 08:25 | |
| resoum | I see this happen on thud occasionally. | 08:40 |
| wertigon | I think something is borked in the build instructions, like internally it is building stuff out-of-order | 08:41 |
| resoum | I bumped up the RAM on our build VM and it went away. | 08:41 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:41 | |
| wertigon | resoum: Did you do a full rebuild? | 08:42 |
| *** medaliyou <medaliyou!c4b3dd32@196.179.221.50> has joined #yocto | 08:42 | |
| resoum | Yup, had to do a -c cleansstate | 08:42 |
| wertigon | Ok, that explains it | 08:42 |
| resoum | Otherwise it just kept on failing. | 08:42 |
| wertigon | Then yes, the explanation is that 14 GB of memory is probably not enough for building this | 08:42 |
| medaliyou | hey guys | 08:42 |
| medaliyou | what is the correct way to tell bitbake to build all QT5 libraires and my QT5 App statically ? | 08:43 |
| resoum | wertigon: 2 Gig of RAM per CPU seemed to be about where the build failures stopped. | 08:43 |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 08:43 | |
| resoum | YMMV of course... | 08:43 |
| wertigon | resoum: Aha, I have only 1.75 GB per thread :/ | 08:44 |
| wertigon | 2 is reserved for the APU on my CPU | 08:44 |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 08:44 | |
| resoum | It feels like a bug somewhere, but I really do not have the time to dig in to it if RAM solves it. | 08:44 |
| wertigon | I can get around this with multiple compiles | 08:45 |
| resoum | Yeah, that is how I generally do it too. | 08:45 |
| resoum | bitbake nodejs and boost, and then fire off the full image builds. | 08:45 |
| wertigon | I just do full image like, 3 or 4 times :) | 08:46 |
| resoum | Yuck | 08:46 |
| wertigon | -k option | 08:46 |
| resoum | Whenever I get a failure like that, I cleansstate the offender, build it manually, and go back to the image build. | 08:46 |
| resoum | Our build server is much more beefy and does not seem to encounter the problem. | 08:47 |
| wertigon | Ok so if I cleansstate and check logs I get this, only two rebuilds necessary this time, but... | 08:48 |
| wertigon | Pastebin coming up | 08:48 |
| *** plntyk <plntyk!~plntyk@ip5b40590c.dynamic.kabel-deutschland.de> has quit IRC | 08:49 | |
| wertigon | https://pastebin.com/qJnS9ui0 | 08:53 |
| wertigon | obviously slightly censored :) | 08:54 |
| *** plntyk <plntyk!~plntyk@ip5b40590c.dynamic.kabel-deutschland.de> has joined #yocto | 08:54 | |
| wertigon | The people paying me want as little info to leak as possible | 08:54 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 08:56 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 08:56 | |
| *** camus is now known as kaspter | 08:58 | |
| *** hpsy <hpsy!~hpsy@196.158.194.225> has joined #yocto | 09:01 | |
| wertigon | So what is interesting here is that it consistently fails on the same things. | 09:14 |
| wertigon | 1st run: Release/node, Release/cctest, Release/mkcodecache, Release/embedtest | 09:16 |
| wertigon | 2nd run: Release/node, Release/cctest, Release/mkcodecache | 09:16 |
| wertigon | 3rd run: Release/node | 09:16 |
| wertigon | 4th run: Success | 09:16 |
| wertigon | Running again with a cleansstate I get: | 09:17 |
| wertigon | 1st run: Release/node, Release/cctest, Release/mkcodecache | 09:18 |
| wertigon | 2nd run: Release/node | 09:18 |
| wertigon | 3rd run: Success | 09:18 |
| *** dev1990 <dev1990!~dev@dynamic-78-8-61-64.ssp.dialog.net.pl> has joined #yocto | 09:19 | |
| *** huseyinkozan_ <huseyinkozan_!~hk@95.70.162.2> has joined #yocto | 09:20 | |
| *** frsc <frsc!~frsc@i59F72919.versanet.de> has quit IRC | 09:20 | |
| *** huseyinkozan <huseyinkozan!~hk@95.70.162.2> has quit IRC | 09:20 | |
| *** ak77 <ak77!~ak77@93-103-81-73.static.t-2.net> has quit IRC | 09:22 | |
| *** ak77 <ak77!~ak77@93-103-81-73.static.t-2.net> has joined #yocto | 09:24 | |
| wertigon | So it is the same steps I'm always failing on and the reason is either OOM or tests/targets are performed in the wrong order | 09:24 |
| wertigon | Good to know atleast :) | 09:24 |
| *** frsc <frsc!~frsc@i59F72919.versanet.de> has joined #yocto | 09:25 | |
| *** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 09:26 | |
| *** plntyk <plntyk!~plntyk@ip5b40590c.dynamic.kabel-deutschland.de> has quit IRC | 09:32 | |
| *** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has quit IRC | 09:35 | |
| *** linums <linums!~linums@apn-94-44-122-137.vodafone.hu> has joined #yocto | 09:35 | |
| *** plntyk <plntyk!~plntyk@ip5b40590c.dynamic.kabel-deutschland.de> has joined #yocto | 09:41 | |
| *** sno <sno!~sno@tmo-117-15.customers.d1-online.com> has quit IRC | 09:49 | |
| *** sno <sno!~sno@tmo-117-15.customers.d1-online.com> has joined #yocto | 09:49 | |
| *** sno <sno!~sno@tmo-117-15.customers.d1-online.com> has quit IRC | 09:53 | |
| *** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has joined #yocto | 10:04 | |
| *** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has quit IRC | 10:08 | |
| *** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:a90d:58fd:63e6:e420> has quit IRC | 10:08 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 10:16 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 10:20 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 10:21 | |
| mcfrisk | bitbake parallel options which only take into account avalaible cores/threads is just wrong, amount of RAM is more often the limiting factor. One needs find out what the limits for RAM are, and tweak BB_NUMBER_THREADS and PARALLEL_MAKE down. | 10:26 |
| *** timemaster <timemaster!~timemaste@cst2-170-164.cust.vodafone.cz> has joined #yocto | 10:29 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto | 10:30 | |
| timemaster | Hi, just checking, variable or conditional in DISTRO_VERSION is a bad idea, correct? I wanted to distinguish between our dev and release, but this variable has proven to be difficult with conditionals :) | 10:33 |
| timemaster | I saw some other projects changing their image names, i.e adding version or datestamp in the image name instead of fiddling with DISTRO_VERSION | 10:35 |
| creich | hi there, i am trying to verify a current HAB setup on an imx6 board. for that i wanted to use the u-boot hab_status command. to get that we enabled IMX_HAB in the u-boot config. but the command still isn't available. any ideas what else we might be missing? | 10:36 |
| *** Sponge5 <Sponge5!~adam@cst2-170-164.cust.vodafone.cz> has joined #yocto | 10:37 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 10:37 | |
| qschulz | creich: how did you enable IMX_HAB option? | 10:37 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 10:38 | |
| *** camus is now known as kaspter | 10:38 | |
| mario-goulart | mcfrisk: I wonder if setting PARALLEL_MAKE to "-l <acceptable load>" would help at that. | 10:38 |
| mcfrisk | timemaster: using DISTRO_VERSION is good, we use it. but note that SDK version information in yocto is quite broken and buildhistory data for SDK can be annoying to handle if meta/classes/buildhistory.bbclass doesn't have "BUILDHISTORY_DIR_SDK = "${BUILDHISTORY_DIR}/sdk/${DISTRO}-${TCLIBC}-${SDK_ARCH}-${TUNE_PKGARCH}/${IMAGE_BASENAME}"" | 10:38 |
| creich | we used the menuconfig and saved the def_config that should be used | 10:38 |
| creich | atm we try to verify that the build used the correct config using some other options like the 'date' command from the misc setup | 10:39 |
| creich | but as for the hab_status, should there anything else be needed? or is it supposed to be that one option only? | 10:40 |
| mcfrisk | mario-goulart: that could help, sure. then would also need to do the same for ninja etc | 10:40 |
| timemaster | mcfrisk: but how to change it dynamically? anonymous python functions are not being parsed in distro configuration context for some reason which I couldn't track down | 10:41 |
| mcfrisk | timemaster: we change it for every build which re-generates conf/local.conf | 10:42 |
| mcfrisk | e.g. for all clean builds | 10:43 |
| mario-goulart | mcfrisk: oh, good point. | 10:43 |
| timemaster | mcfrisk: yep, it seems to me like the easiest way too | 10:43 |
| Sponge5 | Hi all, are all of the testing frameworks (testimage, selftest, ptest) meant to run on target? I'm looking for a way to test the existence of files in the filesystem on host, what should I use? | 10:46 |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC | 10:46 | |
| mcfrisk | timemaster: oh sorry, it looks like we do use anonymous python, e.g. DISTRO_VERSION := "${@get_distro_version(d)}" in distro config. That checks git tree status and provides a pure tag for clean and a unique has and "dirty" for all non-clean builds. | 10:46 |
| mcfrisk | /has/hash/ | 10:47 |
| wertigon | mcfrisk: Ok, so if I understand you correctly, I should simply remove two threads from the build chain options? :) | 10:49 |
| timemaster | mcfrisk: oh really, this works for you? that's great then, and this is in your local.conf or <distro>.conf? | 10:51 |
| mcfrisk | timemaster: distro config. but if I'd do it now, I'd put this into the generated local.conf. we basically have a 'configure' script for bitbake builds. | 10:52 |
| mcfrisk | wertigon: or don't blindly add threads per core, but limit this to e.g. 2 gigs of RAM per thread. | 10:53 |
| timemaster | mcfrisk: yeah, once you have a proper build server it makes sense.. since there is not much automation currently on our side, I would like yocto itself to take care of such things | 10:53 |
| mcfrisk | but the RAM limit depends on what you need to build, for C projects almost everything is fine. for C++ with templates, build time RAM usage can explode. Try building chromium, webkit etc to find out. | 10:54 |
| qschulz | creich: that should be it, check that arch/arm/mach-imx/hab.o exists after compilation, that should help you | 10:55 |
| timemaster | mcfrisk: would it be possible to share your get_distro_version function? | 10:55 |
| *** linums <linums!~linums@apn-94-44-122-137.vodafone.hu> has quit IRC | 10:57 | |
| *** linums <linums!~linums@apn-94-44-245-60.vodafone.hu> has joined #yocto | 10:58 | |
| mcfrisk | timemaster: not directly. we use git submodules for all meta layers so a base repo "git describe --abbrev=8 --dirty --always" will be fine, except for dirty builds we also add "git submodule status | awk '{print $2, $1}' | sort | sha1sum | cut -c1-6" | 10:58 |
| creich | qschulz: thx, we'll check that | 10:59 |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto | 11:00 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has joined #yocto | 11:04 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has quit IRC | 11:07 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has joined #yocto | 11:08 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC | 11:08 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto | 11:09 | |
| timemaster | mcfrisk: thanks for pointers, that will save some time :) I was asking mainly to check where you have a definition of that function.. I am expecting something like def get_distro_version(d): somewhere in distro conf, which doesn't work for me.. bitbake immediately throws parsing error | 11:10 |
| timemaster | cause inherit <bbclass> doesn't for me in distro conf either, which is otherwise a good place for such stuff | 11:12 |
| mcfrisk | timemaster: in distro.conf "require classes/distroversion.bbclass", then that class only has get_distro_version() python function which returns the string. nb, we also use that with another custom bbclass to fill in same info to /etc/os-release | 11:13 |
| timemaster | mcfrisk: cool, so this is how to fool bitbake so it accepts python in distro conf, thank you very much for that! | 11:17 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 11:17 | |
| mcfrisk | timemaster: not sure if this is cool, or just overly complex and part of the 'fun' of bitbaking /facepalm | 11:20 |
| mcfrisk | everything would be a lot simple to just fill in DISTRO_VERSION to local.conf... | 11:21 |
| timemaster | mcfrisk: well, yes... after trying ten different easy ways which works on other places in yocto, I end up with this.. | 11:22 |
| timemaster | the problem with local.conf is that it is a temporary configuration storage, if you have some infrastructure around which fills it for you, then you are ok, but if you just want to clone the repo, run source and happily watch all the configuration growing automatically using native templating infrastructure, local.conf is just not enough | 11:25 |
| RP | timemaster: you can use INHERIT in conf files to include a class which can add functions | 11:25 |
| timemaster | RP: that might work, good point.. tried only inherit | 11:26 |
| *** linums <linums!~linums@apn-94-44-245-60.vodafone.hu> has quit IRC | 11:28 | |
| mcfrisk | with latest dunfell, I also hit sstate warning incremented to error of missing manifest files. I guess I have some custom stuff which generated empty manifest files.. | 11:30 |
| RP | mcfrisk: I think we'll have to back that one out, it will stay in master though | 11:38 |
| mcfrisk | RP: I've seen this a lot in the past, the warning, and I'm sure it's a bug in our setup, but I haven't figured out what and where it comes from. Looks like "inherit allarch" and another custom bbclass that we use results in missing do_prepare_recipe_sysroot etc manifest files... | 11:39 |
| *** bps <bps!~bps@80.71.142.18> has joined #yocto | 11:41 | |
| RP | mcfrisk: that seems odd as prepare_recipe_sysroot is not a setscene task so would never have a manifest | 11:42 |
| bps | hi, currently I am used to using bitbake and devtool in my standard yocto workspace, and use an SDK for application development. I am looking into the eSDK but I don't understand how devtool modify should work in the eSDK environment? where will it find the recipe files? are they also included in the eSDK? | 11:43 |
| mcfrisk | RP: but there is a manifest file missing, and it looks like our bbclass uses MACHINE_ARCH when it should be using PACKAGE_ARCH.. | 11:45 |
| wertigon | mcfrisk: Ok, I'll make sure to add a recommendation to buy more RAM for build machines then :) | 11:48 |
| wertigon | Unfortunately we do build qtwebengine | 11:48 |
| wertigon | I have no idea why nodejs though | 11:49 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-fpjrdvmflkyvxinw> has joined #yocto | 11:50 | |
| mcfrisk | what is the official way for a sstate cached task to re-do_deploy and overwrite output files? Or is manual cleanup of tmp/deploy the only solution? "The recipe blabla is trying to install files into a shared area when those files already exist." | 11:57 |
| qschulz | mcfrisk: -c deploy -f but that will taint your sstate-cache and you'll need to clean it later | 11:59 |
| qschulz | I think Yocto detects when files from deploydir are removed and reinstall them but I am definitely not sure this is true | 12:00 |
| mcfrisk | qschulz: hmm, or should recipes provide a "do_clean" task which cleans up the deployed files? | 12:00 |
| qschulz | mcfrisk: mmmm good point, clean might work too? | 12:04 |
| *** berton <berton!~user@200-180-244-11.user3p.brasiltelecom.net.br> has joined #yocto | 12:12 | |
| mcfrisk | qschulz: nah, clean doesn't work. just cleaning the deployed file is not enough. would need to clean the manifest file too. | 12:13 |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 12:26 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 12:27 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has quit IRC | 12:31 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has joined #yocto | 12:31 | |
| *** linums <linums!~linums@apn-94-44-102-126.vodafone.hu> has joined #yocto | 12:34 | |
| yates | if this is in a custom layer "require conf/machine/include/qemu.inc" does it get from the poky/meta layer or from the custom layer? | 12:40 |
| yates | i.e., from poky/meta/conf/... or from poky/meta-custom/conf/...? | 12:41 |
| yates | or does it try one then the other? | 12:44 |
| yates | How Does It Work(TM)? | 12:44 |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:ba39:67f5:3885:dbb6> has quit IRC | 12:48 | |
| *** Yumasi <Yumasi!~guillaume@static-176-175-104-214.ftth.abo.bbox.fr> has joined #yocto | 12:48 | |
| *** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 13:01 | |
| *** tpierre <tpierre!~tpierre@218.160.135.77.rev.sfr.net> has joined #yocto | 13:03 | |
| *** frsc <frsc!~frsc@i59F72919.versanet.de> has quit IRC | 13:04 | |
| nohit | is there a way for modifying a distro without editing the files manufacturer provides directly or creating own distro ? | 13:05 |
| nohit | similar to bbappend | 13:05 |
| derRichard | you can override many things in your local.conf | 13:06 |
| nohit | okay | 13:07 |
| qschulz | nohit: just create your own distro that requires your manufacturer distro conf file | 13:08 |
| nohit | i would like to remove splash screen and make it permanent | 13:08 |
| qschulz | nohit: not sure this is done in distro but more in image recipe? | 13:08 |
| qschulz | nohit: might also be a hard dependency (DEPENDS/RDEPENDS) in one of the packages/recipes included in your image recipe | 13:09 |
| nohit | oh yes its in image receipe | 13:10 |
| smurray | yates: see https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#require-directive | 13:11 |
| *** medaliyou <medaliyou!c4b3dd32@196.179.221.50> has quit IRC | 13:15 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 13:17 | |
| *** frsc <frsc!~frsc@i59F72919.versanet.de> has joined #yocto | 13:17 | |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 13:18 | |
| *** camus is now known as kaspter | 13:18 | |
| Sponge5 | I'm looking around for oe-selftest usage and I can't seem to find a good example of a sysroot verification. I simply want to check if the files appear in sysroot after a successful build | 13:22 |
| *** caiortp <caiortp!~caiortp@92-108-245-63.cable.dynamic.v4.ziggo.nl> has quit IRC | 13:26 | |
| *** jobroe <jobroe!~manjaro-u@p579eb604.dip0.t-ipconnect.de> has quit IRC | 13:30 | |
| yates | smurray: thanks - i looked in the bbum but could not find that. | 13:30 |
| yates | low-priority question: how are the docs (e.g., https://docs.yoctoproject.org/bitbake) generated? | 13:31 |
| rburton | yates: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/ | 13:34 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:54 | |
| qschulz | yates: rburton: http://git.openembedded.org/bitbake/tree/doc for https://docs.yoctoproject.org/bitbake I think. https://docs.yoctoproject.org/ is handled in the git repo pointed by rburton | 14:09 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 14:10 | |
| derRichard | when i have a custom kernel, with a custom uapi, shouldn't yocto use these kernel headers as glibc kernel-headers? | 14:13 |
| derRichard | or another way asked, where does the glibc recipe take the kernel uapi headers from? | 14:13 |
| qschulz | linux-kernel-headers recipe | 14:18 |
| qschulz | derRichard: kernels are machine specific recipes | 14:18 |
| derRichard | ahhhh, linux-kernel-headers | 14:18 |
| derRichard | thx! | 14:18 |
| derRichard | this is why i miss stuff | 14:18 |
| *** timemaster1 <timemaster1!~timemaste@cst2-170-164.cust.vodafone.cz> has joined #yocto | 14:19 | |
| qschulz | so making glibc dependent on kernel headers is basically making any package non-reusable by other machines | 14:19 |
| qschulz | which is extremely inefficient | 14:19 |
| qschulz | if you want to add an entry to the uapi, you need to create a recipe that install a header file into the sysroot which will be used by the kernel, kernel modules and userspace applications that requires it | 14:19 |
| derRichard | the problem is less complicated. my kernel is 5.4 but linux-kernel-headers seems to use 5.2 | 14:21 |
| derRichard | so, i miss new stuff | 14:21 |
| *** timemaster <timemaster!~timemaste@cst2-170-164.cust.vodafone.cz> has quit IRC | 14:22 | |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:1818:56c8:141a:a2e1> has joined #yocto | 14:22 | |
| qschulz | derRichard: makes sense to upgrade linux-kernel-headers recipe AND USE IT FOR ALL MACHINES | 14:25 |
| qschulz | derRichard: since 5.4 is an LTS, we probably have/had a recipe for that in oe-core/poky | 14:26 |
| derRichard | thx, this is what i was about to do :) | 14:27 |
| fray | the Linux-kernel-headers are ONLY used by userspace. The versions and content do NOT have to match the running ekrenl.. | 14:27 |
| fray | I would NOT upgrade it, as you can break glibc/musl, etc.. | 14:28 |
| fray | as long as the linux-kernel-headers are the same or older then the running kerenl, it will work fine | 14:28 |
| fray | people need to stop thinking there is something magic in the linux-kernel-headers.. there isn't, it's just defining the APIs used by the system libc. The Linux kernel folks have promised that they will remain backwards compatible in newer versions of the kernel -- so there is no reason to upgrade it (as a user) even if you are rolling foward your kernel version. | 14:29 |
| fray | Additionally, programs that are trying to talk to module interfaces should NOT be using it as a foundation for ioctl and similar. As ioctls are not part of the defined glibc mechanisms | 14:29 |
| fray | (best way to handle this, think of the system as userspace and kernel space. linux-kernel-headers, libc, etc are all userspace. Linux _kernel_ and modules are all kernel space.. When building, one should space should not refer to another. | 14:31 |
| qschulz | fray: well now the question is... what derRichard Is missing in 5.2 kernel headers | 14:33 |
| derRichard | since socketcan folks broke the uabi, i need to use 5.4 heards on both sides | 14:34 |
| *** timemaster1 <timemaster1!~timemaste@cst2-170-164.cust.vodafone.cz> has quit IRC | 14:34 | |
| derRichard | https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5223e9eee651e005c0f6d6d078909087601b7e9 | 14:34 |
| derRichard | struct socketaddr_can now has differenct sizes :( | 14:34 |
| derRichard | (this needs to be fixed anyway) | 14:34 |
| derRichard | but for now i need to work around that | 14:34 |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC | 14:35 | |
| fray | Any userspace driver that needs specific knowledge of a kernel interface (magic numbers, including ioctl) should carry it's own knowledge. Often this is done with a copy of a specific chunk of the driver's (kernel) header in the userspace driver.. | 14:35 |
| fray | For well defined interfaces, glibc handles the interactions/translations for you | 14:35 |
| derRichard | not if due to a kernel bug the uabi was broken | 14:37 |
| derRichard | ...which is here the case | 14:37 |
| fray | in this case, I would verify that glibc has no references to can.h (I'm pretty sure it doesn't, as it has no specific knowledge of can inteface, unlike sockets/pipes/tcp/ip.. | 14:37 |
| fray | Assuming glibc does NOT have direct knowledge of the can.h interfaces, then you can carry a temporary copy of it -- or patch linux-kernel-headers with the one file. Either will work fine.. | 14:38 |
| * derRichard checked | 14:38 | |
| *** ThomasD13 <ThomasD13!~thomas@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 14:38 | |
| fray | This is a bit of an unusual situation as it should be a "more" stable interface.. | 14:38 |
| fray | where I usually see this is ioctls and other 'magic numbers' that userspace programs are trying to get access. In those cases, the right answer is always to include a copy of the magic numbers within the userspce component.. | 14:39 |
| JPEW | Ya, that one is a little annoying because it's a change in the socket address type | 14:39 |
| derRichard | i found that an hour ago, will talk later to socket can folks. IMHO this is a bad bug | 14:39 |
| derRichard | but for now i need to get my application stack in shape again | 14:39 |
| fray | since they placed it at the end of the structure, theoretically it's compatible.. but ya.. iffy.. | 14:39 |
| fray | I'd almost consider defining a new structure specifically to resolve this issue.. i.e. can_new.. can_2.. etc etc etc | 14:40 |
| fray | breaking an existing interface is not a good idea | 14:40 |
| JPEW | derRichard: Is the problem that the program is receiving the address into a `struct sockaddr_can` struct? | 14:40 |
| fray | (even for a less used interface like CAN) | 14:40 |
| derRichard | JPEW: yes. i use recvfrom() on AF_CAN | 14:40 |
| JPEW | Ya, the recieve buffer should be something else... "struct sockaddr" maybe? That ensures it's big enough and you typecast it to the specific type (I think) | 14:41 |
| fray | (for a VERY long time, CAN required a local to the app copy of the can headers.. just as an FYI..) | 14:41 |
| derRichard | JPEW: let me check that the application really does (it was not written by me) | 14:42 |
| derRichard | *what the | 14:43 |
| JPEW | derRichard: Ah, how unfortunate: it looks like the struct sockaddr only reserves 14 bytes for sa_data, but the sockaddr_can has 17 data bytes, so even that wouldn't fix it :( | 14:47 |
| JPEW | derRichard: Oh, right, use "struct sockaddr_storage". It's big enough :) | 14:48 |
| *** alexlarsson <alexlarsson!~alexl@c-31a4e255.022-110-73746f36.bbcust.telenor.se> has quit IRC | 14:50 | |
| * armpit rust is nuts | 14:51 | |
| derRichard | qschulz: JPEW: should i add a recipes-kernel/linux-libc-headers/ recipe to my layer? | 14:52 |
| derRichard | i'm not sure that the best way is | 14:53 |
| derRichard | i don't really want to copy linux-libc-headers.inc into my layer | 14:53 |
| JPEW | derRichard: No, fray is correct. If your application needs specific kernel API, it should have it's own copy of the header... a lot of libraries that wrap kernel functionality do this (e.g. libdrm) | 14:54 |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 14:55 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 14:55 | |
| derRichard | JPEW: and what about can-utils? they use can too with recvfrom() | 14:55 |
| derRichard | it will break too | 14:55 |
| JPEW | Ya, that's a bug in can-utils | 14:56 |
| JPEW | They should be using struct sockaddr_storage | 14:56 |
| derRichard | just checked, they have their own copy of can.h. so, they are safe | 14:58 |
| JPEW | derRichard: They still should be using struct sockaddr_storage | 14:58 |
| JPEW | Otherwise, they have to be kept in lock-step with the kernel | 14:58 |
| JPEW | Well, maybe not since they pass their own size I guess | 14:59 |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-18-184-147-76-169.dsl.bell.ca> has joined #yocto | 14:59 | |
| derRichard | and why is poky even upgrading thir recipes-kernel/linux-libc-headers/? | 14:59 |
| derRichard | you say every application has to ship their own headers, which makes only kind of sense | 15:00 |
| RP | derRichard: linux-libc-headers is the copy of the headers for libc | 15:01 |
| *** jesuspc <jesuspc!592445a4@89.36.69.164> has joined #yocto | 15:01 | |
| derRichard | RP: yes, these headers will then be available in sdks, right? | 15:02 |
| RP | derRichard: since the sdk contains libc, yes | 15:02 |
| derRichard | i'm using kernel 5.4 and want the headers from 5.4 in my sdk, and not 5.2. :) | 15:02 |
| derRichard | IIUC i need to move linux-libc-headers to 5.4 then | 15:02 |
| RP | derRichard: correct. But just use a plain upstream kernel for linux-libc-headers, not some machine hacked up one | 15:03 |
| derRichard | of course, yes | 15:04 |
| derRichard | in my case a plain kernel will do it | 15:04 |
| RP | derRichard: if a plain kernel wouldn't do it, there would be an issue somewhere | 15:04 |
| derRichard | agreed | 15:05 |
| derRichard | so i'll have my own linux-libc-headers in my layer with 5.4 upstream such that it matches my upstream 5.4 kerel | 15:05 |
| derRichard | *kernel | 15:05 |
| RobertBerger | @derRichard: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13955 | 15:11 |
| vdl | What are the best practices to include custom systemd udev rules for your platform? | 15:14 |
| *** hpsy <hpsy!~hpsy@196.158.194.225> has quit IRC | 15:16 | |
| Spooster | not sure about best practices, but I'd expect just jamming *.rules in your FILES_${PN} and shuffling them into the proper places in your recipe is more than sufficient | 15:17 |
| Spooster | and I'd expect .bbappend-ing the various recipes that splat in other rules would be decent path forward when editing existing rule-sets | 15:18 |
| *** timemaster1 <timemaster1!~timemaste@cst2-170-164.cust.vodafone.cz> has joined #yocto | 15:18 | |
| *** timemaster1 <timemaster1!~timemaste@cst2-170-164.cust.vodafone.cz> has left #yocto | 15:18 | |
| *** McAwesome <McAwesome!b0c6c9d4@ip-176-198-201-212.hsi05.unitymediagroup.de> has joined #yocto | 15:19 | |
| *** hpsy <hpsy!~hpsy@196.158.194.225> has joined #yocto | 15:19 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 15:26 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 15:26 | |
| Spooster | I'm getting myself into a funky state with kas/bitbake. It looks like one of the patches I applied in a `bbappend` already has been applied to the source the last time this built. I have since edited another part of the recipe, and now the bbappend is failing to apply the patch a second time | 15:30 |
| Spooster | I'd like it to either: Not apply the patch twice in a row because it already did that.... or clean everything so it downloads source, and rebuilds everything and applies the patch to a clean state | 15:30 |
| Spooster | I don't know if the former is possible... and `bitbake -c cleanall <package>` mysteriously doesn't fix my problem | 15:31 |
| Spooster | do I need to run some other command other than cleanall to "go back to a time before patches were applied?" | 15:31 |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:1818:56c8:141a:a2e1> has quit IRC | 15:36 | |
| qschulz | Spooster: no, -c cleanall does that. Is it possible you have your patch twice in SRC_URI? | 15:36 |
| Spooster | It must be something silly like that | 15:37 |
| Spooster | unfortunately, in the bbapend I'm aware of, the patch is only listed once | 15:38 |
| Spooster | but I'd suspect something somewhere is bring it in | 15:38 |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 15:38 | |
| Sponge5 | vdl: I'm just working on that and what I'm trying to do is to have udev-<basedistro>.bb recipe which plops out multiple PACKAGES, where each package has just one udev rule. Then either specify the package in <machine>.conf or <layer>.conf | 15:38 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 15:39 | |
| *** camus is now known as kaspter | 15:39 | |
| *** jesuspc <jesuspc!592445a4@89.36.69.164> has quit IRC | 15:39 | |
| Spooster | qschulz: .bbappend for the curious. My only guess at the moment, is that I might have to read more about what `FILESEXTRAPATHS_prepend := /${THISDIR}/files` is doing... because it's probably doing exactly that | 15:40 |
| Spooster | https://pastebin.com/g2ySjeFF | 15:41 |
| *** linums <linums!~linums@apn-94-44-102-126.vodafone.hu> has quit IRC | 15:43 | |
| lukma | Dear community, | 15:43 |
| lukma | Is there a way to replace program (like tar) from work/hosttols directory? And replace it with -native one build from Yocto ? | 15:44 |
| lukma | The problem is that I do use the old machine to build recent yocto | 15:44 |
| lukma | and tar is not supporting features needed by contemporary yocto/OE | 15:45 |
| Sponge5 | Spooster: did you check the files/ directory for the recipe you're appending to? | 15:45 |
| *** sno <sno!~sno@p4fe93f04.dip0.t-ipconnect.de> has joined #yocto | 15:45 | |
| Spooster | I only have one patch in the files I'm appending... | 15:47 |
| rburton | lukma: run install-buildtools | 15:47 |
| Spooster | and the recipe's original source doesn't have any patches to speak of | 15:47 |
| *** AndersD__ <AndersD__!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 15:47 | |
| vdl | Sponge5: got it | 15:48 |
| vdl | btw is there some kind of naming convention for custom tty? like ttyCUSTOMER[0-9] or customer-tty-[0-9], etc.? | 15:50 |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:50 | |
| *** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has joined #yocto | 15:51 | |
| lukma | rburton: I will check this option :-), thanks | 15:53 |
| Spooster | checking `bitbake-layers show-appends`, I see that only my one .bbappend is being applied | 15:53 |
| Spooster | I just moved the recipe to it's own folder to make sure other nearby files and recipes weren't causing trouble | 15:53 |
| *** AndersD__ <AndersD__!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:54 | |
| qschulz | Spooster: when you do -c cleanall, do you still have a workdir for your recipe? | 15:55 |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 15:57 | |
| Spooster | qschulz: I think yes... it looks like `build/tmp/work/raspberrypi4_64-poky-linux/weston-init` persists after a `bitbake -c cleanall weston-init` | 15:59 |
| *** tpierre <tpierre!~tpierre@218.160.135.77.rev.sfr.net> has quit IRC | 16:00 | |
| Spooster | I'm not sure I expected to fine `weston-init` under `raspberrypi4` like that... | 16:01 |
| Spooster | the recipes comes from poke/meta/recipes-graphics/wayland | 16:01 |
| *** JaBen1 <JaBen1!Thunderbir@gateway/vpn/mullvad/jaben> has joined #yocto | 16:01 | |
| *** bps2 <bps2!~bps@80.71.142.18> has joined #yocto | 16:03 | |
| Spooster | (I think I'm at like... a negative typing accuracy at this point... *find, *recipe, *poky/) | 16:03 |
| *** JaBen1 is now known as JaBen | 16:04 | |
| lukma | rburton: Is the install-builtools script doing the same as installing https://downloads.yoctoproject.org/releases/yocto/yocto-3.1.5/buildtools/x86_64-buildtools-nativesdk-standalone-3.1.5.sh ? | 16:04 |
| rburton | yes | 16:04 |
| lukma | rburton: I do manually downlod those tools and install them | 16:04 |
| lukma | despite of that the OE/Yocto uses the tar from ./hosttols/ directory which is a sym link to system's old tar | 16:05 |
| rburton | maybe only the extended one includes tar? | 16:05 |
| *** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has quit IRC | 16:05 | |
| rburton | nope the 3.2 non-extended one definitely includes tar | 16:06 |
| *** bps <bps!~bps@80.71.142.18> has quit IRC | 16:06 | |
| rburton | you need to source the setup script before doing oe-init-build-env, and if hosttools already exists it won't get updated | 16:06 |
| Spooster | update... while the folder still exists, the contents of the folder are indeed being wiped out by the `bitbake -c cleanall` | 16:06 |
| lukma | rburton: It may be that I had hosttols setup earlier | 16:08 |
| lukma | so those won't get updated | 16:08 |
| Spooster | running `bitbake -c fetch` and bitbake -c unpack` shows that the file and patch are already coming in... and the `weston.ini` is somehow "pre-patched" | 16:09 |
| qschulz | Spooster: how did you create your patch for weston.ini? | 16:10 |
| qschulz | it seems to me there's a mismatch between your development environment for the patch and the sources in Yocto | 16:11 |
| lukma | rburton: Why hosttols links are not updated? Is this a design decision? | 16:11 |
| Spooster | I copied the file on the running system, made my changes, ran a diff, and formatted it accordingly | 16:12 |
| JaBen | Hi, I am trying to generate an archive of source files used in the rootfs to scan with a separate tool regarding license compliance. I tried using the archiver class but this currently includes build dependencies, not just the runtime dependencies. As far as I can tell, there currently is no mechanism for filtering this, right? | 16:12 |
| Spooster | I actually want to verify I didn't much around in the src from /poky/meta... that might have been something silly I did | 16:13 |
| Spooster | yep... I think I mucked around in my source files at one point | 16:14 |
| *** frsc <frsc!~frsc@i59F72919.versanet.de> has quit IRC | 16:17 | |
| *** bps2 <bps2!~bps@80.71.142.18> has quit IRC | 16:17 | |
| *** bps2 <bps2!~bps@80.71.142.18> has joined #yocto | 16:22 | |
| *** Bunio_FH <Bunio_FH!~bunio@37.30.21.117.nat.umts.dynamic.t-mobile.pl> has quit IRC | 16:26 | |
| *** rostam <rostam!~bgholikha@2601:644:8100:6650:f52b:2c7e:4dcc:94d3> has quit IRC | 16:27 | |
| qschulz | Spooster: hehe | 16:28 |
| *** rostam <rostam!~bgholikha@2601:644:8100:6650:c5:b2c2:6ff2:3409> has joined #yocto | 16:29 | |
| *** wertigon <wertigon!~per@c-6d61225c.021-396-7673741.bbcust.telenor.se> has quit IRC | 16:31 | |
| Spooster | hehe exactly | 16:39 |
| Spooster | tyvm | 16:39 |
| qschulz | glad you found out by yourself, that would have been a tricky one to debug. | 16:42 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 16:44 | |
| *** McAwesome <McAwesome!b0c6c9d4@ip-176-198-201-212.hsi05.unitymediagroup.de> has quit IRC | 16:46 | |
| *** clementp[m] <clementp[m]!cperonmatr@gateway/shell/matrix.org/x-lwibzlzzglbpdvgo> has quit IRC | 16:47 | |
| *** t_unix[m] <t_unix[m]!tunixmatri@gateway/shell/matrix.org/x-ejhionrffylkztjf> has quit IRC | 16:47 | |
| *** lexano[m] <lexano[m]!lexanomatr@gateway/shell/matrix.org/x-nkweywtjwsborrzj> has quit IRC | 16:47 | |
| *** clementp[m] <clementp[m]!cperonmatr@gateway/shell/matrix.org/x-xwzuddkycrjulrfj> has joined #yocto | 16:49 | |
| RP | rburton: wondering if seeing https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/3256 is the meson change? :/ | 16:50 |
| *** lexano[m] <lexano[m]!lexanomatr@gateway/shell/matrix.org/x-ggaldxjtcpultkhs> has joined #yocto | 16:50 | |
| RP | oobitots51: ^^^ | 16:50 |
| rburton | RP: i suspect it is :( | 16:50 |
| rburton | shall try to replicate | 16:50 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 16:52 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 16:52 | |
| *** mario-goulart <mario-goulart!~user@static.172.139.76.144.clients.your-server.de> has quit IRC | 16:53 | |
| rburton | RP: i expect that's because i tested on arm64 so it can run native | 16:54 |
| rburton | i'll do a rebuild with qemux86 | 16:54 |
| RP | rburton: right, the failures all look cross related | 16:54 |
| rburton | i suspect i just need to pass another option | 16:55 |
| rburton | sorry about that | 16:55 |
| RP | rburton: np, happens :) | 16:55 |
| RP | rburton: I'll abort, drop that bit and retry which will confirm it is that change | 16:56 |
| *** t_unix[m] <t_unix[m]!tunixmatri@gateway/shell/matrix.org/x-slnvcjntpfbgnruy> has joined #yocto | 17:03 | |
| *** rr123 <rr123!~xxiao@159.89.184.51> has joined #yocto | 17:04 | |
| *** fl0v0 <fl0v0!~fvo@i5E86AFF3.versanet.de> has quit IRC | 17:05 | |
| rr123 | does each tag(e.g. yocto-3.2.2) has its upstream branch so I can track and merge any changes for each stable releases, if any | 17:05 |
| rr123 | it appears to be a fixed tagged tarball to me | 17:05 |
| RP | rr123: 3.2 is the gatesgarth branch | 17:06 |
| RP | codenames in repos are easier to match than having every repo use the same version scheme | 17:07 |
| rburton | $ git branch --contains yocto-3.2.2 -r | 17:07 |
| rburton | origin/gatesgarth | 17:07 |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 17:08 | |
| rr123 | agree, the quick-build doc uses 'git checkout tags/yocto-3.2.2 -b my-yocto-3.2.2' which is what most newcomers will follow, but it can not be pulled-merged in the process, I will assume gatesgarth has the up-to-date 3.2 code then | 17:08 |
| RP | rr123: we should perhaps change change. | 17:08 |
| RP | michaelo: ^^^ - might be worth a look | 17:09 |
| *** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 17:09 | |
| *** camus is now known as kaspter | 17:09 | |
| rr123 | personally i actually prefer 3.2 to gatesgarth, honestly after a while i forgot the name but I appreciate the first letter keeps some order to stay sane, now the question, is yocto-3.2 the same as gatesgarth(i.e. the tip of all 3.2.x releases), or is it just the first 3.2 checkpoint, sort of 3.2.0? | 17:12 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 17:12 | |
| RP | rr123: 3.2.0 I suspect | 17:12 |
| rr123 | a little ambiguous to the paranoid, anyway I got it, thanks | 17:13 |
| RP | rr123: it is effectively impossible to make "3.2" work for all the repos that would use it unfortunately | 17:13 |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC | 17:15 | |
| *** vineela <vineela!vtummala@nat/intel/x-cgzhuflinjhjmbyo> has joined #yocto | 17:15 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto | 17:15 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 17:18 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 17:19 | |
| *** Sponge5 <Sponge5!~adam@cst2-170-164.cust.vodafone.cz> has quit IRC | 17:19 | |
| qschulz | JaBen: I guess you could use buildhistory which lists all packages installed in an image and archive to get the source of said packages? | 17:21 |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto | 17:25 | |
| *** sno <sno!~sno@p4fe93f04.dip0.t-ipconnect.de> has quit IRC | 17:26 | |
| *** linums <linums!~linums@apn-94-44-117-148.vodafone.hu> has joined #yocto | 17:28 | |
| JaBen | @qschulz: hm... I had a similar idea involving the rootfs manifest... but I wasn't sure if and how I would be able to integrate that in the yocto build itself. from the top of my head I wouldn't be able to tell if parsing individual package names to the archiver class is possible. Would you have a rough idea where to start? | 17:32 |
| JaMa | rr123: bookmark https://wiki.yoctoproject.org/wiki/Releases to preserve sanity | 17:40 |
| *** mario-goulart <mario-goulart!~user@static.172.139.76.144.clients.your-server.de> has joined #yocto | 17:40 | |
| JaBen | @qschulz: imo the "clean" way would be being able to parse a flag to the archiver class itself, maybe extend the COPYLEFT_RECIPE_TYPES with rdepends and depends though I'm not sure how hard it would be to access the package meta-info "depends or rdepends?". I think I'll might look into it, if you guys agree on this approach | 17:42 |
| michaelo | rr123, RP: do you mean we should add "git branch --set-upstream-to=origin/gatesgarth my-yocto-3.2.2" to the documentation, so that people can later run "git pull" on their branch? | 18:00 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 18:00 | |
| rr123 | michaelo: yes, or I just do: git checkout -t origin/gatesgarth -b my-3.2.x | 18:01 |
| *** mckoan is now known as mckoan|away | 18:03 | |
| michaelo | rr123: yes, indeed much better. I was indeed thinking about my-3.2.x for the local branch name. Good catch, thanks! | 18:03 |
| michaelo | Then I'll probably replace the "git tag" command by "git branch -a" to find out which remote branch to pick, together with a reference to the correspondance between release names and version numbers. | 18:05 |
| michaelo | I'll propose something to the docs@ mailing list for review. Thanks again | 18:06 |
| rr123 | cool, thanks! | 18:06 |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-187.hsi6.kabel-badenwuerttemberg.de> has joined #yocto | 18:08 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 18:17 | |
| *** yannholo <yannholo!~yannholo@fs-141-0-205-41.fullsave.info> has quit IRC | 18:19 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 18:24 | |
| *** gsalazar <gsalazar!~gsalazar@173.111.90.149.rev.vodafone.pt> has joined #yocto | 18:26 | |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 18:29 | |
| *** kyrix <kyrix!~ashwoods@78.142.65.171> has quit IRC | 18:31 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 18:31 | |
| *** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 18:44 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has joined #yocto | 18:48 | |
| *** oobitots51 <oobitots51!ad26d108@aer01-mda1-dmz-wsa-3.cisco.com> has quit IRC | 18:51 | |
| *** tnovotny <tnovotny!~tnovotny@ip-78-45-64-220.net.upcbroadband.cz> has quit IRC | 18:51 | |
| *** linums <linums!~linums@apn-94-44-117-148.vodafone.hu> has quit IRC | 18:51 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 18:51 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 18:53 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 18:54 | |
| *** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC | 19:00 | |
| *** JaBen <JaBen!Thunderbir@gateway/vpn/mullvad/jaben> has quit IRC | 19:00 | |
| rr123 | last time i worked with yocto is 2017, any major changes since then? after I tested with x86 build and now I want to cleanall for the whole build, is there a command or I just brutally `rm -rf build/`? | 19:06 |
| aleblanc | you could always bitbake you_image -c cleanall | 19:07 |
| rr123 | plan to do a raspberry pi 4 build to warm up cross-build steps, and last but not least, i'm a debian guy so i don't really use rpm, is deb/ipk as golden as rpm as far as yocto's test procedure goes(are they both tested as much somehow)? | 19:07 |
| rburton | cleanall will spend ages carefully wiping your sstate, so that's not a good idea | 19:08 |
| rburton | rr123: opkg and rpm are equally good, dpkg less tested | 19:08 |
| rburton | if you want to blast the build, just rm -rf tmp | 19:08 |
| rburton | it can rebuild entirely from sstate-cache, so leave that be unless you'll never need it again | 19:09 |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 19:09 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC | 19:10 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 19:10 | |
| rr123 | itbake -c cleanall core-image-minimal -- does not really do much, it probablly only delete that final image | 19:10 |
| rr123 | yeah i don't need this for x86 so I intend to remove all sstate and tmp | 19:10 |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 19:13 | |
| * rr123 did `rm -rf build` after saved the downloads directory there | 19:14 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 19:18 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 19:19 | |
| *** sno <sno!~sno@2001-4dd4-29d4-0-49c6-18d7-a8ca-b25a.ipv6dyn.netcologne.de> has joined #yocto | 19:24 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 19:30 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 19:33 | |
| *** kpo_ <kpo_!~kpo@gl226-39.master.pl> has joined #yocto | 19:44 | |
| *** Yumasi <Yumasi!~guillaume@static-176-175-104-214.ftth.abo.bbox.fr> has quit IRC | 20:06 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has quit IRC | 20:07 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has joined #yocto | 20:09 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 20:10 | |
| *** huseyinkozan <huseyinkozan!~hk@95.70.167.204> has joined #yocto | 20:12 | |
| *** huseyinkozan_ <huseyinkozan_!~hk@95.70.162.2> has quit IRC | 20:12 | |
| *** hpsy <hpsy!~hpsy@196.158.194.225> has quit IRC | 20:13 | |
| *** huseyinkozan <huseyinkozan!~hk@95.70.167.204> has quit IRC | 20:17 | |
| *** feddischson <feddischson!~feddischs@HSI-KBW-109-192-195-187.hsi6.kabel-badenwuerttemberg.de> has quit IRC | 20:18 | |
| *** eFfeM <eFfeM!~fmeulenbr@a97014.upc-a.chello.nl> has joined #yocto | 20:19 | |
| eFfeM | Hi, anyone an idea on the following: I'm trying to backport python 3.7.6 to yocto gatesgarth as I have a program that can't use 3.8 or 3.9.. | 20:21 |
| eFfeM | I copied over the recipe and all files, but when building the rootfs I get a compile error in meson-0.55.1 | 20:21 |
| eFfeM | from setuptools import setup | 20:21 |
| eFfeM | ModuleNotFoundError: No module named 'setuptools | 20:21 |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 20:23 | |
| eFfeM | however the meson recipe has an inherit setuptools3 line | 20:23 |
| eFfeM | any idea what can be wrong here? If I reset all of recipes-devtools to the last hash that has 3.7.6 everything builds but that gives me other old packages | 20:24 |
| vdl | why package-management is an image feature and not a distro feature? | 20:25 |
| *** eFfeM1 <eFfeM1!3ea3610e@a97014.upc-a.chello.nl> has joined #yocto | 20:26 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 20:39 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 20:40 | |
| *** linums <linums!~linums@apn-94-44-245-93.vodafone.hu> has joined #yocto | 20:41 | |
| *** eFfeM1 <eFfeM1!3ea3610e@a97014.upc-a.chello.nl> has quit IRC | 20:59 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC | 21:01 | |
| *** linums <linums!~linums@apn-94-44-245-93.vodafone.hu> has quit IRC | 21:02 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 21:02 | |
| *** wallthar <wallthar!~wallthar@34-61-201-31.ftth.glasoperator.nl> has joined #yocto | 21:06 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 21:06 | |
| *** wallthar <wallthar!~wallthar@34-61-201-31.ftth.glasoperator.nl> has quit IRC | 21:06 | |
| *** sbach <sbach!~sbachmatr@192.184.90.156> has quit IRC | 21:18 | |
| *** berton <berton!~user@200-180-244-11.user3p.brasiltelecom.net.br> has quit IRC | 21:18 | |
| *** sbach <sbach!~sbachmatr@192.184.90.156> has joined #yocto | 21:18 | |
| *** bps2 <bps2!~bps@80.71.142.18> has quit IRC | 21:19 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 21:23 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 21:23 | |
| RP | vmeson: my concerns about valgrind seem founded ;-) | 21:33 |
| RP | Saur|home: I'm trying a slightly more invasive util-linux cleanup patch in master-next | 21:43 |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC | 21:47 | |
| *** psnsilva <psnsilva!~psnsilva@161.230.35.203> has quit IRC | 21:55 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 21:59 | |
| *** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 22:06 | |
| *** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 22:06 | |
| *** eFfeM <eFfeM!~fmeulenbr@a97014.upc-a.chello.nl> has quit IRC | 22:15 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 22:21 | |
| *** psnsilva <psnsilva!~psnsilva@161.230.35.203> has quit IRC | 22:21 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 22:22 | |
| *** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 22:23 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has quit IRC | 22:23 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has joined #yocto | 22:27 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 22:28 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 22:29 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has quit IRC | 22:31 | |
| *** vineela <vineela!vtummala@nat/intel/x-cgzhuflinjhjmbyo> has quit IRC | 22:38 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 22:39 | |
| rr123 | is glibc the only officially supported c lib in yocto? any plan for official musl support | 22:48 |
| rr123 | where deep embedded system might find it useful(no gtk, no GUI, etc) | 22:49 |
| RP | rr123: musl is available | 22:49 |
| RP | rr123: poky-tiny uses it as one example | 22:49 |
| rr123 | it isn't 'extensively used' so I guess it provides a base for others to leverage, other than that you're on your own. will look into for more, so far the newest check in is 2020.8 for 5.8 kernel upgrade | 22:56 |
| yates | i'm trying to do some RTS, but i'm getting this error when setting up the build environment: Please set a MACHINE in your local.conf or environment | 22:57 |
| yates | the whole message is here: http://paste.ubuntu.com/p/375bZhGRZd/ | 22:58 |
| yates | RTS == Really Tricky Shit | 22:58 |
| yates | but there IS a conf/local.conf and it DOES have a MACHINE setting | 22:58 |
| yates | and there is a layer added to bblayers.conf which has a conf/machine/xyz.conf file for the MACHINE setting xyz | 23:01 |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC | 23:02 | |
| yates | here's my RTS: http://paste.ubuntu.com/p/wzxC2Cnj65/ | 23:02 |
| yates | well, no. try here: http://paste.ubuntu.com/p/HTkBtw6jNj/ | 23:03 |
| yates | are there any other environment variables setup by oe-init-build-env besides BBPATH, BB_ENV_EXTRAWHITE, and BUILDDIR? | 23:04 |
| yates | also note that i did not emit all the comments into the local.conf file - shirley that doesn't matter? | 23:06 |
| yates | RP: isn't there newlib too? | 23:07 |
| rr123 | for env is it 'bitbake -e' | 23:12 |
| yates | rr123: are you talking to me? | 23:15 |
| RP | rr123: we do test world builds for musl so it does have some support | 23:28 |
| RP | yates: yes, there is a newlib option | 23:29 |
| RP | yates: that error means MACHINE wasn't set when bitbake checked it so somehow it isn't being set | 23:29 |
| *** agust <agust!~agust@pd95f1388.dip0.t-ipconnect.de> has quit IRC | 23:33 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 23:42 | |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-18-184-147-76-169.dsl.bell.ca> has quit IRC | 23:43 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!