Wednesday, 2021-03-24

*** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:8118:6d73:54b:c75b> has joined #yocto00:00
*** Kyubi <Kyubi!~Kyubi@> has quit IRC00:00
*** camus <camus!~Instantbi@> has joined #yocto00:33
*** kaspter <kaspter!~Instantbi@> has quit IRC00:34
*** camus is now known as kaspter00:34
*** ismailouch <ismailouch!~ismailouc@2a01:e0a:17a:9a50:1d5:4c97:6932:35a6> has joined #yocto00:35
*** kpo__ <kpo__!> has quit IRC00:43
*** Wouter0100 <Wouter0100!> has quit IRC00:50
*** Wouter0100 <Wouter0100!> has joined #yocto00:51
*** extorr <extorr!extor@unaffiliated/extor> has joined #yocto00:55
*** Bunio_FH <Bunio_FH!> has quit IRC01:11
*** Kyubi_ <Kyubi_!~Kyubi@2601:647:4080:f10:8118:6d73:54b:c75b> has quit IRC01:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto01:26
*** Bunio_FH <Bunio_FH!> has joined #yocto01:28
*** ismailouch <ismailouch!~ismailouc@2a01:e0a:17a:9a50:1d5:4c97:6932:35a6> has quit IRC01:30
*** extorr <extorr!extor@unaffiliated/extor> has quit IRC01:33
*** extorr <extorr!extor@unaffiliated/extor> has joined #yocto01:34
*** extorr <extorr!extor@unaffiliated/extor> has quit IRC01:39
*** extorr <extorr!extor@unaffiliated/extor> has joined #yocto01:40
*** rostam <rostam!~bgholikha@2601:644:8100:6650:f52b:2c7e:4dcc:94d3> has joined #yocto01:47
*** [Sno] <[Sno]!> has joined #yocto02:01
*** sno <sno!> has quit IRC02:03
*** kaspter <kaspter!~Instantbi@> has quit IRC02:04
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:04
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:634d:583c:6674:c157:37fa> has joined #yocto02:06
*** kpo <kpo!> has quit IRC02:32
*** kpo <kpo!> has joined #yocto02:32
*** sakoman <sakoman!> has quit IRC02:33
*** armpit <armpit!~armpit@2601:202:4180:a5c0:c595:8045:5f62:447d> has quit IRC02:42
*** Kyubi <Kyubi!~Kyubi@> has quit IRC02:49
*** armpit <armpit!~armpit@2601:202:4180:a5c0:dc08:9c62:7698:5e41> has joined #yocto02:56
*** sno <sno!> has joined #yocto03:01
*** [Sno] <[Sno]!> has quit IRC03:03
*** yizhao <yizhao!~zhaoyi@> has quit IRC03:06
*** yizhao <yizhao!~zhaoyi@> has joined #yocto03:07
*** sakoman <sakoman!> has joined #yocto03:14
*** yizhao <yizhao!~zhaoyi@> has quit IRC03:17
*** yizhao <yizhao!~zhaoyi@> has joined #yocto03:17
*** sakoman <sakoman!> has quit IRC03:33
*** ahadi <ahadi!~ahadi@> has quit IRC03:57
*** Kyubi <Kyubi!> has joined #yocto03:59
*** ahadi <ahadi!> has joined #yocto04:00
*** Kyubi_ <Kyubi_!~Kyubi@> has joined #yocto04:06
*** Kyubi <Kyubi!> has quit IRC04:07
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:20
*** ssajal_ <ssajal_!> has quit IRC04:49
*** stacktru2t <stacktru2t!> has quit IRC04:55
*** jobroe <jobroe!> has joined #yocto04:56
*** feddischson <feddischson!> has joined #yocto05:04
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:634d:583c:6674:c157:37fa> has quit IRC05:17
*** stacktru1t <stacktru1t!> has joined #yocto05:23
*** beneth <beneth!> has joined #yocto05:24
*** Spooster <Spooster!> has quit IRC05:33
*** Spooster <Spooster!> has joined #yocto05:34
*** ThomasD13 <ThomasD13!> has joined #yocto05:37
*** Spooster <Spooster!> has quit IRC05:38
*** plntyk <plntyk!> has joined #yocto05:43
*** Kyubi_ <Kyubi_!~Kyubi@> has quit IRC06:02
*** vineela <vineela!vtummala@nat/intel/x-kshfkxcccdhmycdp> has quit IRC06:06
*** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:a90d:58fd:63e6:e420> has joined #yocto06:12
*** oobitots51 <oobitots51!> has joined #yocto06:14
*** yizhao <yizhao!~zhaoyi@> has quit IRC06:15
mcfriskhmm 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 weeks06:19
*** yizhao <yizhao!~zhaoyi@> has joined #yocto06:19
*** w00die <w00die!~w00die@> has quit IRC06:28
*** AndersD <AndersD!> has joined #yocto06:29
*** w00die <w00die!~w00die@> has joined #yocto06:30
*** AndersD_ <AndersD_!> has joined #yocto06:31
*** AndersD <AndersD!> has quit IRC06:34
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:634d:583c:6674:c157:37fa> has joined #yocto06:35
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:634d:583c:6674:c157:37fa> has quit IRC06:37
*** agust <agust!> has joined #yocto06:57
*** jobroe <jobroe!> has quit IRC07:00
*** jobroe <jobroe!> has joined #yocto07:03
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto07:06
mcfriskso 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!> has quit IRC07:13
*** dl9pf_home <dl9pf_home!~quassel@opensuse/member/dl9pf> has quit IRC07:18
*** sno <sno!> has joined #yocto07:18
*** dl9pf_home <dl9pf_home!> has joined #yocto07:18
*** dl9pf_home <dl9pf_home!~quassel@opensuse/member/dl9pf> has joined #yocto07:18
*** rcoote <rcoote!> has joined #yocto07:19
*** mrpelotaz0 <mrpelotaz0!> has quit IRC07:20
*** wertigon <wertigon!> has joined #yocto07:24
*** sno <sno!> has quit IRC07:29
*** feddischson <feddischson!> has quit IRC07:31
wertigonHmmm, 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 #yocto07:32
wertigonBuild 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/> has joined #yocto07:34
wertigonCould it be that I run out of RAM or CPU cores?07:35
*** frsc <frsc!> has joined #yocto07:38
*** huseyinkozan <huseyinkozan!~hk@> has joined #yocto07:38
*** kaspter <kaspter!~Instantbi@> has quit IRC07:39
*** rcoote <rcoote!> has quit IRC07:41
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:41
*** rcoote <rcoote!> has joined #yocto07:42
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:42
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:43
*** kyrix <kyrix!~ashwoods@> has joined #yocto07:46
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:ba39:67f5:3885:dbb6> has joined #yocto07:53
*** fl0v0 <fl0v0!> has joined #yocto07:55
*** caiortp <caiortp!> has joined #yocto07:56
wertigonAs far as I can tell, my only nodejs recipes come from meta-oe.07:59
*** goliath <goliath!> has joined #yocto07:59
*** beratiks <beratiks!52de0992@> has joined #yocto08:07
*** zeddii <zeddii!> has quit IRC08:08
*** zeddii <zeddii!> has joined #yocto08:12
wertigonAm I the only one seeing this consistently? :o08:12
*** gsalazar <gsalazar!> has quit IRC08:16
*** kpo <kpo!> has quit IRC08:16
*** kpo <kpo!> has joined #yocto08:17
*** mckoan|away is now known as mckoan08:19
*** sno <sno!> has joined #yocto08:21
*** mrpelotazo <mrpelotazo!> has joined #yocto08:21
*** yannholo <yannholo!> has joined #yocto08:22
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC08:25
resoumI see this happen on thud occasionally.08:40
wertigonI think something is borked in the build instructions, like internally it is building stuff out-of-order08:41
resoumI bumped up the RAM on our build VM and it went away.08:41
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:41
wertigonresoum: Did you do a full rebuild?08:42
*** medaliyou <medaliyou!c4b3dd32@> has joined #yocto08:42
resoumYup, had to do a -c cleansstate08:42
wertigonOk, that explains it08:42
resoumOtherwise it just kept on failing.08:42
wertigonThen yes, the explanation is that 14 GB of memory is probably not enough for building this08:42
medaliyouhey guys08:42
medaliyouwhat is the correct way to tell bitbake to build all QT5 libraires and my QT5 App statically ?08:43
resoumwertigon: 2 Gig of RAM per CPU seemed to be about where the build failures stopped.08:43
*** yizhao <yizhao!~zhaoyi@> has quit IRC08:43
resoumYMMV of course...08:43
wertigonresoum: Aha, I have only 1.75 GB per thread :/08:44
wertigon2 is reserved for the APU on my CPU08:44
*** yizhao <yizhao!~zhaoyi@> has joined #yocto08:44
resoumIt feels like a bug somewhere, but I really do not have the time to dig in to it if RAM solves it.08:44
wertigonI can get around this with multiple compiles08:45
resoumYeah, that is how I generally do it too.08:45
resoumbitbake nodejs and boost, and then fire off the full image builds.08:45
wertigonI just do full image like, 3 or 4 times :)08:46
wertigon-k option08:46
resoumWhenever I get a failure like that, I cleansstate the offender, build it manually, and go back to the image build.08:46
resoumOur build server is much more beefy and does not seem to encounter the problem.08:47
wertigonOk so if I cleansstate and check logs I get this, only two rebuilds necessary this time, but...08:48
wertigonPastebin coming up08:48
*** plntyk <plntyk!> has quit IRC08:49
wertigonobviously slightly censored :)08:54
*** plntyk <plntyk!> has joined #yocto08:54
wertigonThe people paying me want as little info to leak as possible08:54
*** kaspter <kaspter!~Instantbi@> has quit IRC08:56
*** camus <camus!~Instantbi@> has joined #yocto08:56
*** camus is now known as kaspter08:58
*** hpsy <hpsy!~hpsy@> has joined #yocto09:01
wertigonSo what is interesting here is that it consistently fails on the same things.09:14
wertigon1st run: Release/node, Release/cctest, Release/mkcodecache, Release/embedtest09:16
wertigon2nd run: Release/node, Release/cctest, Release/mkcodecache09:16
wertigon3rd run: Release/node09:16
wertigon4th run: Success09:16
wertigonRunning again with a cleansstate I get:09:17
wertigon1st run: Release/node, Release/cctest, Release/mkcodecache09:18
wertigon2nd run: Release/node09:18
wertigon3rd run: Success09:18
*** dev1990 <dev1990!> has joined #yocto09:19
*** huseyinkozan_ <huseyinkozan_!~hk@> has joined #yocto09:20
*** frsc <frsc!> has quit IRC09:20
*** huseyinkozan <huseyinkozan!~hk@> has quit IRC09:20
*** ak77 <ak77!> has quit IRC09:22
*** ak77 <ak77!> has joined #yocto09:24
wertigonSo it is the same steps I'm always failing on and the reason is either OOM or tests/targets are performed in the wrong order09:24
wertigonGood to know atleast :)09:24
*** frsc <frsc!> has joined #yocto09:25
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto09:26
*** plntyk <plntyk!> has quit IRC09:32
*** linums <linums!> has quit IRC09:35
*** linums <linums!> has joined #yocto09:35
*** plntyk <plntyk!> has joined #yocto09:41
*** sno <sno!> has quit IRC09:49
*** sno <sno!> has joined #yocto09:49
*** sno <sno!> has quit IRC09:53
*** mbulut <mbulut!> has joined #yocto10:04
*** mbulut <mbulut!> has quit IRC10:08
*** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:a90d:58fd:63e6:e420> has quit IRC10:08
*** yizhao <yizhao!~zhaoyi@> has quit IRC10:16
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC10:20
*** yizhao <yizhao!~zhaoyi@> has joined #yocto10:21
mcfriskbitbake 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!> has joined #yocto10:29
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto10:30
timemasterHi, 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
timemasterI saw some other projects changing their image names, i.e adding version or datestamp in the image name instead of fiddling with DISTRO_VERSION10:35
creichhi 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!> has joined #yocto10:37
*** camus <camus!~Instantbi@> has joined #yocto10:37
qschulzcreich: how did you enable IMX_HAB option?10:37
*** kaspter <kaspter!~Instantbi@> has quit IRC10:38
*** camus is now known as kaspter10:38
mario-goulartmcfrisk: I wonder if setting PARALLEL_MAKE to "-l <acceptable load>" would help at that.10:38
mcfrisktimemaster: 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
creichwe used the menuconfig and saved the def_config that should be used10:38
creichatm we try to verify that the build used the correct config using some other options like the 'date' command from the misc setup10:39
creichbut as for the hab_status, should there anything else be needed? or is it supposed to be that one option only?10:40
mcfriskmario-goulart: that could help, sure. then would also need to do the same for ninja etc10:40
timemastermcfrisk: 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 down10:41
mcfrisktimemaster: we change it for every build which re-generates conf/local.conf10:42
mcfriske.g. for all clean builds10:43
mario-goulartmcfrisk: oh, good point.10:43
timemastermcfrisk: yep, it seems to me like the easiest way too10:43
Sponge5Hi 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 IRC10:46
mcfrisktimemaster: 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
wertigonmcfrisk: Ok, so if I understand you correctly, I should simply remove two threads from the build chain options? :)10:49
timemastermcfrisk: oh really, this works for you? that's great then, and this is in your local.conf or <distro>.conf?10:51
mcfrisktimemaster: 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
mcfriskwertigon: or don't blindly add threads per core, but limit this to e.g. 2 gigs of RAM per thread.10:53
timemastermcfrisk: 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 things10:53
mcfriskbut 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
qschulzcreich: that should be it, check that arch/arm/mach-imx/hab.o exists after compilation, that should help you10:55
timemastermcfrisk: would it be possible to share your get_distro_version function?10:55
*** linums <linums!> has quit IRC10:57
*** linums <linums!> has joined #yocto10:58
mcfrisktimemaster: 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
creichqschulz: thx, we'll check that10:59
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto11:00
*** tnovotny <tnovotny!> has joined #yocto11:04
*** tnovotny <tnovotny!> has quit IRC11:07
*** tnovotny <tnovotny!> has joined #yocto11:08
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC11:08
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto11:09
timemastermcfrisk: 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 error11:10
timemastercause inherit <bbclass> doesn't for me in distro conf either, which is otherwise a good place for such stuff11:12
mcfrisktimemaster: 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-release11:13
timemastermcfrisk: 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 #yocto11:17
mcfrisktimemaster: not sure if this is cool, or just overly complex and part of the 'fun' of bitbaking /facepalm11:20
mcfriskeverything would be a lot simple to just fill in DISTRO_VERSION to local.conf...11:21
timemastermcfrisk: well, yes... after trying ten different easy ways which works on other places in yocto, I end up with this..11:22
timemasterthe 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 enough11:25
RPtimemaster: you can use INHERIT in conf files to include a class which can add functions11:25
timemasterRP: that might work, good point.. tried only inherit11:26
*** linums <linums!> has quit IRC11:28
mcfriskwith 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
RPmcfrisk: I think we'll have to back that one out, it will stay in master though11:38
mcfriskRP: 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@> has joined #yocto11:41
RPmcfrisk: that seems odd as prepare_recipe_sysroot is not a setscene task so would never have a manifest11:42
bpshi, 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
mcfriskRP: 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
wertigonmcfrisk: Ok, I'll make sure to add a recommendation to buy more RAM for build machines then :)11:48
wertigonUnfortunately we do build qtwebengine11:48
wertigonI have no idea why nodejs though11:49
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto11:50
mcfriskwhat 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
qschulzmcfrisk: -c deploy -f but that will taint your sstate-cache and you'll need to clean it later11:59
qschulzI think Yocto detects when files from deploydir are removed and reinstall them but I am definitely not sure this is true12:00
mcfriskqschulz: hmm, or should recipes provide a "do_clean" task which cleans up the deployed files?12:00
qschulzmcfrisk: mmmm good point, clean might work too?12:04
*** berton <berton!> has joined #yocto12:12
mcfriskqschulz: 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!> has quit IRC12:26
*** kpo <kpo!> has joined #yocto12:27
*** tnovotny <tnovotny!> has quit IRC12:31
*** tnovotny <tnovotny!> has joined #yocto12:31
*** linums <linums!> has joined #yocto12:34
yatesif this is in a custom layer "require conf/machine/include/" does it get from the poky/meta layer or from the custom layer?12:40
yatesi.e., from poky/meta/conf/... or from poky/meta-custom/conf/...?12:41
yatesor does it try one then the other?12:44
yatesHow Does It Work(TM)?12:44
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:ba39:67f5:3885:dbb6> has quit IRC12:48
*** Yumasi <Yumasi!> has joined #yocto12:48
*** Spooster <Spooster!> has joined #yocto13:01
*** tpierre <tpierre!> has joined #yocto13:03
*** frsc <frsc!> has quit IRC13:04
nohitis there a way for modifying a distro without editing the files manufacturer provides directly or creating own distro ?13:05
nohitsimilar to bbappend13:05
derRichardyou can override many things in your local.conf13:06
qschulznohit: just create your own distro that requires your manufacturer distro conf file13:08
nohiti would like to remove splash screen and make it permanent13:08
qschulznohit: not sure this is done in distro but more in image recipe?13:08
qschulznohit: might also be a hard dependency (DEPENDS/RDEPENDS) in one of the packages/recipes included in your image recipe13:09
nohitoh yes its in image receipe13:10
smurrayyates: see
*** medaliyou <medaliyou!c4b3dd32@> has quit IRC13:15
*** camus <camus!~Instantbi@> has joined #yocto13:17
*** frsc <frsc!> has joined #yocto13:17
*** kaspter <kaspter!~Instantbi@> has quit IRC13:18
*** camus is now known as kaspter13:18
Sponge5I'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 build13:22
*** caiortp <caiortp!> has quit IRC13:26
*** jobroe <jobroe!> has quit IRC13:30
yatessmurray: thanks - i looked in the bbum but could not find that.13:30
yateslow-priority question: how are the docs (e.g., generated?13:31
*** sakoman <sakoman!> has joined #yocto13:54
qschulzyates: rburton: for I think. is handled in the git repo pointed by rburton14:09
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:10
derRichardwhen i have a custom kernel, with a custom uapi, shouldn't yocto use these kernel headers as glibc kernel-headers?14:13
derRichardor another way asked, where does the glibc recipe take the kernel uapi headers from?14:13
qschulzlinux-kernel-headers recipe14:18
qschulzderRichard: kernels are machine specific recipes14:18
derRichardahhhh, linux-kernel-headers14:18
derRichardthis is why i miss stuff14:18
*** timemaster1 <timemaster1!> has joined #yocto14:19
qschulzso making glibc dependent on kernel headers is basically making any package non-reusable  by other machines14:19
qschulzwhich is extremely inefficient14:19
qschulzif 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 it14:19
derRichardthe problem is less complicated. my kernel is 5.4 but linux-kernel-headers seems to use 5.214:21
derRichardso, i miss new stuff14:21
*** timemaster <timemaster!> has quit IRC14:22
*** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:1818:56c8:141a:a2e1> has joined #yocto14:22
qschulzderRichard: makes sense to upgrade linux-kernel-headers recipe AND USE IT FOR ALL MACHINES14:25
qschulzderRichard: since 5.4 is an LTS, we probably have/had a recipe for that in oe-core/poky14:26
derRichardthx, this is what i was about to do :)14:27
fraythe Linux-kernel-headers are ONLY used by userspace.  The versions and content do NOT have to match the running ekrenl..14:27
frayI would NOT upgrade it, as you can break glibc/musl, etc..14:28
frayas long as the linux-kernel-headers are the same or older then the running kerenl, it will work fine14:28
fraypeople 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
frayAdditionally, 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 mechanisms14: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
qschulzfray: well now the question is... what derRichard Is missing in 5.2 kernel headers14:33
derRichardsince socketcan folks broke the uabi, i need to use 5.4 heards on both sides14:34
*** timemaster1 <timemaster1!> has quit IRC14:34
derRichardstruct socketaddr_can now has differenct sizes :(14:34
derRichard(this needs to be fixed anyway)14:34
derRichardbut for now i need to work around that14:34
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC14:35
frayAny 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
frayFor well defined interfaces, glibc handles the interactions/translations for you14:35
derRichardnot if due to a kernel bug the uabi was broken14:37
derRichard...which is here the case14:37
frayin 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
frayAssuming 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 checked14:38
*** ThomasD13 <ThomasD13!> has quit IRC14:38
frayThis is a bit of an unusual situation as it should be a "more" stable interface..14:38
fraywhere 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
JPEWYa, that one is a little annoying because it's a change in the socket address type14:39
derRichardi found that an hour ago, will talk later to socket can folks. IMHO this is a bad bug14:39
derRichardbut for now i need to get my application stack in shape again14:39
fraysince they placed it at the end of the structure, theoretically it's compatible.. but ya.. iffy..14:39
frayI'd almost consider defining a new structure specifically to resolve this issue.. i.e. can_new..  can_2.. etc etc etc14:40
fraybreaking an existing interface is not a good idea14:40
JPEWderRichard: 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
derRichardJPEW: yes. i use recvfrom() on AF_CAN14:40
JPEWYa, 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
derRichardJPEW: let me check that the application really does (it was not written by me)14:42
derRichard*what the14:43
JPEWderRichard: 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
JPEWderRichard: Oh, right, use "struct sockaddr_storage". It's big enough :)14:48
*** alexlarsson <alexlarsson!> has quit IRC14:50
* armpit rust is nuts14:51
derRichardqschulz: JPEW: should i add a recipes-kernel/linux-libc-headers/ recipe to my layer?14:52
derRichardi'm not sure that the best way is14:53
derRichardi don't really want to copy into my layer14:53
JPEWderRichard: 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@> has quit IRC14:55
*** yizhao <yizhao!~zhaoyi@> has joined #yocto14:55
derRichardJPEW: and what about can-utils? they use can too with recvfrom()14:55
derRichardit will break too14:55
JPEWYa, that's a bug in can-utils14:56
JPEWThey should be using struct sockaddr_storage14:56
derRichardjust checked, they have their own copy of can.h. so, they are safe14:58
JPEWderRichard: They still should be using struct sockaddr_storage14:58
JPEWOtherwise, they have to be kept in lock-step with the kernel14:58
JPEWWell, maybe not since they pass their own size I guess14:59
*** ssajal <ssajal!> has joined #yocto14:59
derRichardand why is poky even upgrading thir recipes-kernel/linux-libc-headers/?14:59
derRichardyou say every application has to ship their own headers, which makes only kind of sense15:00
RPderRichard: linux-libc-headers is the copy of the headers for libc15:01
*** jesuspc <jesuspc!592445a4@> has joined #yocto15:01
derRichardRP: yes, these headers will then be available in sdks, right?15:02
RPderRichard: since the sdk contains libc, yes15:02
derRichardi'm using kernel 5.4 and want the headers from 5.4 in my sdk, and not 5.2. :)15:02
derRichardIIUC i need to move  linux-libc-headers to 5.4 then15:02
RPderRichard: correct. But just use a plain upstream kernel for linux-libc-headers, not some machine hacked up one15:03
derRichardof course, yes15:04
derRichardin my case a plain kernel will do it15:04
RPderRichard: if a plain kernel wouldn't do it, there would be an issue somewhere15:04
derRichardso i'll have my own linux-libc-headers in my layer with 5.4 upstream such that it matches my upstream 5.4 kerel15:05
vdlWhat are the best practices to include custom systemd udev rules for your platform?15:14
*** hpsy <hpsy!~hpsy@> has quit IRC15:16
Spoosternot 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 sufficient15:17
Spoosterand I'd expect .bbappend-ing the various recipes that splat in other rules would be decent path forward when editing existing rule-sets15:18
*** timemaster1 <timemaster1!> has joined #yocto15:18
*** timemaster1 <timemaster1!> has left #yocto15:18
*** McAwesome <McAwesome!> has joined #yocto15:19
*** hpsy <hpsy!~hpsy@> has joined #yocto15:19
*** yizhao <yizhao!~zhaoyi@> has quit IRC15:26
*** yizhao <yizhao!~zhaoyi@> has joined #yocto15:26
SpoosterI'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 time15:30
SpoosterI'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 state15:30
SpoosterI don't know if the former is possible... and `bitbake -c cleanall <package>` mysteriously doesn't fix my problem15:31
Spoosterdo 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 IRC15:36
qschulzSpooster: no, -c cleanall does that. Is it possible you have your patch twice in SRC_URI?15:36
SpoosterIt must be something silly like that15:37
Spoosterunfortunately, in the bbapend I'm aware of, the patch is only listed once15:38
Spoosterbut I'd suspect something somewhere is bring it in15:38
*** camus <camus!~Instantbi@> has joined #yocto15:38
Sponge5vdl: 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>.conf15:38
*** kaspter <kaspter!~Instantbi@> has quit IRC15:39
*** camus is now known as kaspter15:39
*** jesuspc <jesuspc!592445a4@> has quit IRC15:39
Spoosterqschulz: .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 that15:40
*** linums <linums!> has quit IRC15:43
lukmaDear community,15:43
lukmaIs there a way to replace program (like tar) from work/hosttols directory? And replace it with -native one build from Yocto ?15:44
lukmaThe problem is that I do use the old machine  to build recent yocto15:44
lukmaand tar is not supporting features needed by contemporary yocto/OE15:45
Sponge5Spooster: did you check the files/ directory for the recipe you're appending to?15:45
*** sno <sno!> has joined #yocto15:45
SpoosterI only have one patch in the files I'm appending...15:47
rburtonlukma: run install-buildtools15:47
Spoosterand the recipe's original source doesn't have any patches to speak of15:47
*** AndersD__ <AndersD__!> has joined #yocto15:47
vdlSponge5: got it15:48
vdlbtw is there some kind of naming convention for custom tty? like ttyCUSTOMER[0-9] or customer-tty-[0-9], etc.?15:50
*** AndersD_ <AndersD_!> has quit IRC15:50
*** AndersD_ <AndersD_!> has joined #yocto15:51
lukmarburton: I will check this option :-), thanks15:53
Spoosterchecking `bitbake-layers show-appends`, I see that only my one .bbappend is being applied15:53
SpoosterI just moved the recipe to it's own folder to make sure other nearby files and recipes weren't causing trouble15:53
*** AndersD__ <AndersD__!> has quit IRC15:54
qschulzSpooster: when you do -c cleanall, do you still have a workdir for your recipe?15:55
*** rcoote <rcoote!> has quit IRC15:57
Spoosterqschulz: 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!> has quit IRC16:00
SpoosterI'm not sure I expected to fine `weston-init` under `raspberrypi4` like that...16:01
Spoosterthe recipes comes from poke/meta/recipes-graphics/wayland16:01
*** JaBen1 <JaBen1!Thunderbir@gateway/vpn/mullvad/jaben> has joined #yocto16:01
*** bps2 <bps2!~bps@> has joined #yocto16: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 JaBen16:04
lukmarburton: Is the install-builtools script doing the same as installing ?16:04
lukmarburton: I do manually downlod those tools and install them16:04
lukmadespite of that the OE/Yocto uses the tar from ./hosttols/ directory which is a sym link to system's old tar16:05
rburtonmaybe only the extended one includes tar?16:05
*** AndersD_ <AndersD_!> has quit IRC16:05
rburtonnope the 3.2 non-extended one definitely includes tar16:06
*** bps <bps!~bps@> has quit IRC16:06
rburtonyou need to source the setup script before doing oe-init-build-env, and if hosttools already exists it won't get updated16:06
Spoosterupdate... while the folder still exists, the contents of the folder are indeed being wiped out by the `bitbake -c cleanall`16:06
lukmarburton: It may be that I had hosttols setup earlier16:08
lukmaso those won't get updated16:08
Spoosterrunning `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
qschulzSpooster: how did you create your patch for weston.ini?16:10
qschulzit seems to me there's a mismatch between your development environment for the patch and the sources in Yocto16:11
lukmarburton: Why hosttols links are not updated? Is this a design decision?16:11
SpoosterI copied the file on the running system, made my changes, ran a diff, and formatted it accordingly16:12
JaBenHi, 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
SpoosterI actually want to verify I didn't much around in the src from /poky/meta... that might have been something silly I did16:13
Spoosteryep... I think I mucked around in my source files at one point16:14
*** frsc <frsc!> has quit IRC16:17
*** bps2 <bps2!~bps@> has quit IRC16:17
*** bps2 <bps2!~bps@> has joined #yocto16:22
*** Bunio_FH <Bunio_FH!> has quit IRC16:26
*** rostam <rostam!~bgholikha@2601:644:8100:6650:f52b:2c7e:4dcc:94d3> has quit IRC16:27
qschulzSpooster: hehe16:28
*** rostam <rostam!~bgholikha@2601:644:8100:6650:c5:b2c2:6ff2:3409> has joined #yocto16:29
*** wertigon <wertigon!> has quit IRC16:31
Spoosterhehe exactly16:39
qschulzglad you found out by yourself, that would have been a tricky one to debug.16:42
*** goliath <goliath!> has quit IRC16:44
*** McAwesome <McAwesome!> has quit IRC16:46
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has quit IRC16:47
*** t_unix[m] <t_unix[m]!tunixmatri@gateway/shell/> has quit IRC16:47
*** lexano[m] <lexano[m]!lexanomatr@gateway/shell/> has quit IRC16:47
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has joined #yocto16:49
RPrburton: wondering if seeing is the meson change? :/16:50
*** lexano[m] <lexano[m]!lexanomatr@gateway/shell/> has joined #yocto16:50
RPoobitots51: ^^^16:50
rburtonRP: i suspect it is :(16:50
rburtonshall try to replicate16:50
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC16:52
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto16:52
*** mario-goulart <mario-goulart!> has quit IRC16:53
rburtonRP: i expect that's because i tested on arm64 so it can run native16:54
rburtoni'll do a rebuild with qemux8616:54
RPrburton: right, the failures all look cross related16:54
rburtoni suspect i just need to pass another option16:55
rburtonsorry about that16:55
RPrburton: np, happens :)16:55
RPrburton: I'll abort, drop that bit and retry which will confirm it is that change16:56
*** t_unix[m] <t_unix[m]!tunixmatri@gateway/shell/> has joined #yocto17:03
*** rr123 <rr123!~xxiao@> has joined #yocto17:04
*** fl0v0 <fl0v0!> has quit IRC17:05
rr123does 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 any17:05
rr123it appears to be a fixed tagged tarball to me17:05
RPrr123: 3.2 is the gatesgarth branch17:06
RPcodenames in repos are easier to match than having every repo use the same version scheme17:07
rburton$ git branch --contains yocto-3.2.2 -r17:07
rburton  origin/gatesgarth17:07
*** camus <camus!~Instantbi@> has joined #yocto17:08
rr123agree, 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 then17:08
RPrr123: we should perhaps change change.17:08
RPmichaelo: ^^^ - might be worth a look17:09
*** kaspter <kaspter!~Instantbi@> has quit IRC17:09
*** camus is now known as kaspter17:09
rr123personally 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!> has joined #yocto17:12
RPrr123: 3.2.0 I suspect17:12
rr123a little ambiguous to the paranoid, anyway I got it, thanks17:13
RPrr123: it is effectively impossible to make "3.2" work for all the repos that would use it unfortunately17:13
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC17:15
*** vineela <vineela!vtummala@nat/intel/x-cgzhuflinjhjmbyo> has joined #yocto17:15
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has joined #yocto17:15
*** goliath <goliath!> has quit IRC17:18
*** goliath <goliath!> has joined #yocto17:19
*** Sponge5 <Sponge5!> has quit IRC17:19
qschulzJaBen: 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 #yocto17:25
*** sno <sno!> has quit IRC17:26
*** linums <linums!> has joined #yocto17: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
JaMarr123: bookmark to preserve sanity17:40
*** mario-goulart <mario-goulart!> has joined #yocto17: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 approach17:42
michaelorr123, 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 IRC18:00
rr123michaelo: yes, or I just do: git checkout -t origin/gatesgarth -b my-3.2.x18:01
*** mckoan is now known as mckoan|away18:03
michaelorr123: yes, indeed much better. I was indeed thinking about my-3.2.x for the local branch name. Good catch, thanks!18:03
michaeloThen 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
michaeloI'll propose something to the docs@ mailing list for review. Thanks again18:06
rr123cool, thanks!18:06
*** feddischson <feddischson!> has joined #yocto18:08
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto18:17
*** yannholo <yannholo!> has quit IRC18:19
*** dreyna <dreyna!> has joined #yocto18:24
*** gsalazar <gsalazar!> has joined #yocto18:26
*** w00die <w00die!~w00die@> has quit IRC18:29
*** kyrix <kyrix!~ashwoods@> has quit IRC18:31
*** w00die <w00die!~w00die@> has joined #yocto18:31
*** kiwi_29 <kiwi_29!> has joined #yocto18:44
*** aleblanc <aleblanc!> has joined #yocto18:48
*** oobitots51 <oobitots51!> has quit IRC18:51
*** tnovotny <tnovotny!> has quit IRC18:51
*** linums <linums!> has quit IRC18:51
*** linums <linums!~linums@> has joined #yocto18:51
*** linums <linums!~linums@> has quit IRC18:53
*** linums <linums!~linums@> has joined #yocto18:54
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:b0dd:8b05:f149:714f> has quit IRC19:00
*** JaBen <JaBen!Thunderbir@gateway/vpn/mullvad/jaben> has quit IRC19:00
rr123last 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
aleblancyou could always bitbake you_image -c cleanall19:07
rr123plan 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
rburtoncleanall will spend ages carefully wiping your sstate, so that's not a good idea19:08
rburtonrr123: opkg and rpm are equally good, dpkg less tested19:08
rburtonif you want to blast the build, just rm -rf tmp19:08
rburtonit can rebuild entirely from sstate-cache, so leave that be unless you'll never need it again19:09
*** kpo <kpo!> has quit IRC19:09
*** vmeson <vmeson!> has quit IRC19:10
*** kpo <kpo!> has joined #yocto19:10
rr123itbake -c cleanall core-image-minimal  -- does not really do much, it probablly only delete that final image19:10
rr123yeah i don't need this for x86 so I intend to remove all sstate and tmp19:10
*** vmeson <vmeson!> has joined #yocto19:13
* rr123 did `rm -rf build` after saved the downloads directory there19:14
*** linums <linums!~linums@> has quit IRC19:18
*** linums <linums!~linums@> has joined #yocto19:19
*** sno <sno!> has joined #yocto19:24
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:30
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto19:33
*** kpo_ <kpo_!> has joined #yocto19:44
*** Yumasi <Yumasi!> has quit IRC20:06
*** aleblanc <aleblanc!> has quit IRC20:07
*** aleblanc <aleblanc!> has joined #yocto20:09
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC20:10
*** huseyinkozan <huseyinkozan!~hk@> has joined #yocto20:12
*** huseyinkozan_ <huseyinkozan_!~hk@> has quit IRC20:12
*** hpsy <hpsy!~hpsy@> has quit IRC20:13
*** huseyinkozan <huseyinkozan!~hk@> has quit IRC20:17
*** feddischson <feddischson!> has quit IRC20:18
*** eFfeM <eFfeM!> has joined #yocto20:19
eFfeMHi, 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
eFfeMI copied over the recipe and all files, but when building the rootfs I get  a compile error in meson-0.55.120:21
eFfeM    from setuptools import setup20:21
eFfeMModuleNotFoundError: No module named 'setuptools20:21
*** beneth <beneth!> has left #yocto20:23
eFfeMhowever the meson recipe has an     inherit setuptools3 line20:23
eFfeMany 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 packages20:24
vdlwhy package-management is an image feature and not a distro feature?20:25
*** eFfeM1 <eFfeM1!> has joined #yocto20:26
*** beneth <beneth!> has joined #yocto20:39
*** linums <linums!~linums@> has quit IRC20:40
*** linums <linums!> has joined #yocto20:41
*** eFfeM1 <eFfeM1!> has quit IRC20:59
*** Lihis <Lihis!> has quit IRC21:01
*** linums <linums!> has quit IRC21:02
*** linums <linums!~linums@> has joined #yocto21:02
*** wallthar <wallthar!> has joined #yocto21:06
*** Lihis <Lihis!> has joined #yocto21:06
*** wallthar <wallthar!> has quit IRC21:06
*** sbach <sbach!~sbachmatr@> has quit IRC21:18
*** berton <berton!> has quit IRC21:18
*** sbach <sbach!~sbachmatr@> has joined #yocto21:18
*** bps2 <bps2!~bps@> has quit IRC21:19
*** linums <linums!~linums@> has quit IRC21:23
*** linums <linums!~linums@> has joined #yocto21:23
RPvmeson: my concerns about valgrind seem founded ;-)21:33
RPSaur|home: I'm trying a slightly more invasive util-linux cleanup patch in master-next21:43
*** Lihis <Lihis!> has quit IRC21:47
*** psnsilva <psnsilva!~psnsilva@> has quit IRC21:55
*** leon-anavi <leon-anavi!~Leon@> has quit IRC21:59
*** beneth <beneth!> has left #yocto22:06
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto22:06
*** eFfeM <eFfeM!> has quit IRC22:15
*** linums <linums!~linums@> has quit IRC22:21
*** psnsilva <psnsilva!~psnsilva@> has quit IRC22:21
*** linums <linums!~linums@> has joined #yocto22:22
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto22:23
*** aleblanc <aleblanc!> has quit IRC22:23
*** aleblanc <aleblanc!> has joined #yocto22:27
*** linums <linums!~linums@> has quit IRC22:28
*** linums <linums!~linums@> has joined #yocto22:29
*** aleblanc <aleblanc!> has quit IRC22:31
*** vineela <vineela!vtummala@nat/intel/x-cgzhuflinjhjmbyo> has quit IRC22:38
*** Lihis <Lihis!> has joined #yocto22:39
rr123is glibc the only officially supported c lib in yocto? any plan for official musl support22:48
rr123where deep embedded system might find it useful(no gtk, no GUI, etc)22:49
RPrr123: musl is available22:49
RPrr123: poky-tiny uses it as one example22:49
rr123it 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 upgrade22:56
yatesi'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 environment22:57
yatesthe whole message is here:
yatesRTS == Really Tricky Shit22:58
yatesbut there IS a conf/local.conf and it DOES have a MACHINE setting22:58
yatesand there is a layer added to bblayers.conf which has a conf/machine/xyz.conf file for the MACHINE setting xyz23:01
*** Lihis <Lihis!> has quit IRC23:02
yateshere's my RTS:
yateswell, no. try here:
yatesare there any other environment variables setup by oe-init-build-env besides BBPATH, BB_ENV_EXTRAWHITE, and BUILDDIR?23:04
yatesalso note that i did not emit all the comments into the local.conf file - shirley that doesn't matter?23:06
yatesRP: isn't there newlib too?23:07
rr123for env is it 'bitbake -e'23:12
yatesrr123: are you talking to me?23:15
RPrr123: we do test world builds for musl so it does have some support23:28
RPyates: yes, there is a newlib option23:29
RPyates: that error means MACHINE wasn't set when bitbake checked it so somehow it isn't being set23:29
*** agust <agust!> has quit IRC23:33
*** Lihis <Lihis!> has joined #yocto23:42
*** ssajal <ssajal!> has quit IRC23:43

Generated by 2.17.2 by Marius Gedminas - find it at!