Wednesday, 2020-11-18

*** rperier <rperier!> has quit IRC00:03
*** rperier <rperier!> has joined #yocto00:03
*** kiwi_29 <kiwi_29!> has quit IRC00:04
*** kiwi_29 <kiwi_29!> has joined #yocto00:05
*** wbn <wbn!> has quit IRC00:06
*** wbn <wbn!> has joined #yocto00:06
*** anonzadas <anonzadas!> has quit IRC00:30
*** kiwi_29 <kiwi_29!> has quit IRC00:39
*** kiwi_29 <kiwi_29!> has joined #yocto00:44
*** Don91 <Don91!> has quit IRC00:45
*** anonzadas <anonzadas!> has joined #yocto00:47
*** kiwi_29 <kiwi_29!> has quit IRC00:57
*** kiwi_29 <kiwi_29!> has joined #yocto00:59
*** georgem <georgem!~georgem@> has quit IRC01:06
*** georgem <georgem!~georgem@> has joined #yocto01:06
*** kiwi_29 <kiwi_29!> has quit IRC01:13
*** kiwi_29 <kiwi_29!> has joined #yocto01:13
*** camus1 <camus1!~Instantbi@> has joined #yocto01:22
*** georgem <georgem!~georgem@> has quit IRC01:22
*** kaspter <kaspter!~Instantbi@> has quit IRC01:22
*** camus1 is now known as kaspter01:22
*** georgem <georgem!~georgem@> has joined #yocto01:23
*** dev1990 <dev1990!> has quit IRC01:27
*** dev1990 <dev1990!> has joined #yocto01:30
*** mbulut <mbulut!> has quit IRC01:31
*** paulg <paulg!> has quit IRC01:36
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC01:41
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto01:41
*** paulg <paulg!> has joined #yocto01:49
*** kaspter <kaspter!~Instantbi@> has quit IRC02:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:07
*** georgem <georgem!~georgem@> has quit IRC02:07
*** georgem <georgem!~georgem@> has joined #yocto02:08
*** kiwi_29 <kiwi_29!> has quit IRC02:13
*** kiwi_29 <kiwi_29!> has joined #yocto02:15
*** georgem <georgem!~georgem@> has quit IRC02:29
*** georgem <georgem!~georgem@> has joined #yocto02:30
*** B0ned1ger2 <B0ned1ger2!> has quit IRC02:35
*** B0ned1ge_ <B0ned1ge_!> has joined #yocto02:35
*** Saur <Saur!pkj@nat/axis/x-hzprbafhvayzokga> has quit IRC02:46
*** georgem <georgem!~georgem@> has quit IRC02:47
*** georgem <georgem!~georgem@> has joined #yocto02:47
*** Saur <Saur!pkj@nat/axis/x-hhuerjxhrvdbvmim> has joined #yocto02:49
*** ericch <ericch!> has quit IRC02:52
*** sakoman <sakoman!~steve@> has quit IRC02:54
*** georgem <georgem!~georgem@> has quit IRC02:55
*** georgem <georgem!~georgem@> has joined #yocto02:55
*** goliath <goliath!> has quit IRC02:56
*** stephano <stephano!> has quit IRC03:08
*** ahadi <ahadi!> has quit IRC03:09
*** ahadi <ahadi!~ahadi@> has joined #yocto03:10
kiwi_29Hello... while generating and sdk (not extensible sdk) using.    bitbake -c populate_sdk <MY_CUSTOM_DISTRO_RECIPE_NAME> , I get errors ----> ERROR: binutils-crosssdk-x86_64-pokysdk-linux-2.34-r0 do_configure: configure failed03:17
kiwi_29Last few lines of config output are03:17
kiwi_29checking where to find the target windres... pre-installed03:18
kiwi_29checking where to find the target windmc... pre-installed03:18
kiwi_29checking whether to enable maintainer-specific portions of Makefiles... no03:18
kiwi_29configure: creating ./config.status03:18
kiwi_29config.status: error: cannot find input file: `'03:18
kiwi_29WARNING: exit code 1 from a shell command.03:18
kiwi_29basically config.status when called by configure in the end, throws error03:18
kiwi_29but when I run config.status separately inside devshell, it succeeds and there is a also present in the source dir03:19
kiwi_29does this ring any bells?03:19
*** georgem <georgem!~georgem@> has quit IRC03:19
*** georgem <georgem!~georgem@> has joined #yocto03:19
*** Guest13027 <Guest13027!~dqx@unaffiliated/dqx> has quit IRC03:41
*** kiwi_29 <kiwi_29!> has quit IRC03:42
*** kiwi_29 <kiwi_29!> has joined #yocto03:42
*** georgem <georgem!~georgem@> has quit IRC03:49
zeddiiRP: sending a v2. you'll have it in your inbox in your morning.03:53
*** kiwi_29 <kiwi_29!> has quit IRC04:13
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC04:22
*** kiwi_29 <kiwi_29!> has joined #yocto04:23
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto04:29
*** paulg <paulg!> has quit IRC04:31
*** paulg <paulg!> has joined #yocto04:31
*** kiwi_29 <kiwi_29!> has quit IRC04:46
zeddiiRP: patch sent. I tried to dive into the exit handling to grok why the compile and install tasks are different and failed. I tested 5.8 on a branch without my patch, hence why it passed. So I fell back to the if [] construct that we know works. Should be good now.04:57
*** paulg <paulg!> has quit IRC05:21
*** kiwi_29 <kiwi_29!> has joined #yocto05:28
*** camus1 <camus1!~Instantbi@> has joined #yocto05:28
*** kaspter <kaspter!~Instantbi@> has quit IRC05:28
*** camus1 is now known as kaspter05:28
*** kiwi_29 <kiwi_29!> has quit IRC05:30
*** kiwi_29 <kiwi_29!> has joined #yocto05:30
*** kiwi_29 <kiwi_29!> has quit IRC05:34
*** B0ned1ge_ <B0ned1ge_!> has quit IRC05:35
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto05:35
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto05:49
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto05:54
*** ThomasD13 <ThomasD13!> has joined #yocto06:03
ThomasD13good morning06:03
*** beneth <beneth!> has joined #yocto06:12
*** seebs <seebs!~seebs@> has quit IRC06:15
ThomasD13When I have a bbappend-file in a layer which is not controlled by me, which adds some patches for a recipe like this "SRC_URI_append_j7-evm = ..."06:17
ThomasD13Is it correct if I want to remove these patches, when I create another bbappend-file in my own layer with higher priority, like this: "SRC_URI_remove_j7-evm = ..." ?06:18
mcfriskThomasD13: nope, it's next to impossible to remove things added by _append. just modify the bbappend which does this, or BBMASK the whole bbappend file away.06:20
ThomasD13mcfrisk, okay thank you. Where do I specify the BBMASK variable?06:22
mcfriskThomasD13: for example in your distro config06:22
ThomasD13alright, thank you06:23
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC06:23
*** AndersD <AndersD!> has joined #yocto06:35
*** AndersD_ <AndersD_!> has joined #yocto06:37
mcfriskThomasD13: when adding layers, BSP or community ones, I find it mandatory to review each layer, bbclass, bbappend and recipe .bb file to figure out what is really needed and wanted. The interfaces between layers is not at all clear. Thus I end up BBMASKing away many things in layers, but this is better than finding out odd things on target HW, like changed busybox config or systemd. Some layers, including06:38
mcfriskmost BSP SW ones, are changing a lot of recipes from e.g. poky in ways which you as user or product developer don't want.06:38
ThomasD13Okay, I didn't know that using BBMASKing is a common thing06:39
*** AndersD <AndersD!> has quit IRC06:39
*** oberstet <oberstet!~oberstet@> has joined #yocto06:47
*** pohly <pohly!> has joined #yocto06:52
mcfriskThomasD13: it's a bit of a workaround, a sledge hammer, to throw away stuff that you don't need. it's not pretty but sadly very much needed. for simple use cases layer defaults may be ok, but they often tie the whole build env to only specific yocto/poky version etc.06:57
mcfriskfor example yocto updates become much easier if one uses only bootloader and kernel recipes from BSP SW layers and has a config for the real product elsewhere. I've done updates from 2.1 to 2.5 to 3.0 to 3.1 with several SoC and BSP SW stacks from different vendors without waiting for the vendors to support that yocto version. Only almost trivial changes were needed to BSP layers to support dunfell for07:00
mcfriskbootloader and kernel.07:00
ThomasD13mcfrisk, did you work also on TI BSP layers?07:03
mcfriskThomasD13: a bit, yes07:05
mcfriskso far meta-ti only required one BBMASK line in my use: BBMASK += "meta-ti/recipes-devtools/doxygen" # use from meta-openembedded instead07:07
ThomasD13Okay. I need to change the used kernel repository of linux kernel source code. Thought this would be trivial, but it seems its not :)07:09
ThomasD13Not sure if I should just define a own machine, and use the standard kernel recipe not the ti ones07:10
*** jobroe <jobroe!> has joined #yocto07:10
mcfriskThomasD13: for sure, you need your own machine config for custom HW07:10
mcfriskyou can start with a copy from eval board machine config from meta-ti07:11
ThomasD13Yes, I just started to looking on j7-evm configuration. But I'm still not sure about these "_append_j7" variable extensions in some ti recipes07:14
ThomasD13I think they link somehow to the machine configuration name. Need to reread yocto manual to understand this07:15
mcfriskah jacinto stuff07:18
ThomasD13yes :)07:18
mcfriskI think it boild down to COMPATIBLE_MACHINE things and jacinto SoC bits. I'd start with a TI eval board and compatible machine config from meta-ti and start modifying that for real target HW, and/or product. You will also need distro config, to select distro features, and image recipe to select needed packages. Then a bbappend to modify the kernel that gets built via a bbappend.07:21
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:21
*** frsc <frsc!> has joined #yocto07:28
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:31
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:288f:f657:6da1:7ce4> has quit IRC07:34
ThomasD13When I have a variable "SOMEVAR = "value1"", and "SOMEVAR_foo = "value2"". How is the "_foo" extension called, so I can google for it? Virtual Provider?07:35
ThomasD13And additionally, if I have a machine configuration, called "foo", does the value of SOMEVAR is value2 ?07:36
LetoThe2ndThomasD13: and yes.07:38
*** agust <agust!> has joined #yocto07:39
LetoThe2ndThomasD13: sorry, link to wrong paragraph. should be
mcfriskThomasD13: you can always check the net effect of all settings with "bitbake -e recipe". There you can see which overrides bbappends etc take effect.07:40
ThomasD13Thank you LetoThe2nd. Does this override only affects on machine names?07:41
*** kaspter <kaspter!~Instantbi@> has quit IRC07:41
LetoThe2ndThomasD13: nope. machine, disro... no idea about all effects. time to read the manual.07:41
*** zandrey <zandrey!~zandrey@> has joined #yocto07:42
LetoThe2ndmcfrisk: to add on what mcfrisk just said, you can use the magic given at for some neat extraction of variable evaluation from bitbake -e07:42
LetoThe2ndah meh, that was for ThomasD13 obviously.07:43
ThomasD13Ill check it out07:43
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:45
LetoThe2ndoh and g'mournin (UGT) dudX07:46
*** beneth <beneth!> has quit IRC07:47
*** mckoan|away is now known as mckoan07:47
*** beneth <beneth!> has joined #yocto07:47
ThomasD13Ahh, maybe this is part of the key :) bitbake/conf/bitbake.conf:OVERRIDES = "local:${MACHINE}:${TARGET_OS}:${TARGET_ARCH}"07:49
ThomasD13Thanks guys! Much more clear now for me07:49
LetoThe2ndThomasD13: cue
ThomasD13Sorry, won't visist youtube on my working pc :) But later when I'm home07:57
LetoThe2ndböring :P07:57
*** fl0v0 <fl0v0!~fvo@> has joined #yocto07:57
*** davidinux1 <davidinux1!~davidinux@> has quit IRC08:21
*** davidinux1 <davidinux1!~davidinux@> has joined #yocto08:23
*** aLEX32 <aLEX32!5bb7e8b1@> has joined #yocto08:31
*** mbulut <mbulut!> has joined #yocto08:41
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:42
RPThomasD13: look at OVERRIDES set in oe-core's bitbake.conf as its slightly different. The version in bitbake isn't used08:42
*** Yumasi <Yumasi!> has joined #yocto08:45
dev1990hi, when I'm using --exclude-path=home/ for my rootfs partition whole image become owned by 1000:1000, is this a known bug ?08:50
paulbarkerdev1990: Which Yocto Project branch are you using?08:55
*** davidinux1 is now known as davidinux08:55
dev1990by typing here I found that I'm using "=" in syntax, maybe this is wrong08:56
paulbarker`--exclude-path=home` should be right, you can probably drop the trailing `/`08:57
*** RobertBerger <RobertBerger!> has joined #yocto08:57
paulbarkerAre you running wic under bitbake or directly from the command line?08:58
dev1990paulbarker: I don't have to drop `/` since this will make home non available directory and create a problem later (I'm using separete home partition)08:58
dev1990from bitbake08:58
dev1990I don't want to drop*09:01
dev1990this becomes a problematic image when I add "--exclude-path=home/"09:02
paulbarkerdev1990: If you modify it to have just one copy of the rootfs does it work then?09:03
paulbarkerCould you also check the `log.do_image_wic` file for any warnings or errors09:04
*** sstiller <sstiller!> has joined #yocto09:04
*** shan1 <shan1!> has joined #yocto09:08
kanavin_homeRP: some progress on world reproducibility09:13
kanavin_home2020-11-18 01:14:44,957 - oe-selftest - INFO - Reproducibility summary for deb: same=11214 different=61 missing=0 total=1127509:13
kanavin_home2020-11-18 01:21:44,991 - oe-selftest - INFO - Reproducibility summary for ipk: same=11214 different=61 missing=0 total=1127509:13
kanavin_homeRP: particularly go-releated items are complicated, as they write 'buildid' into every binary, and that buildid is sensitive to any change in build environment, not dissimilar to sstate cache09:14
kanavin_homeI'm thinking of taking a break, and submitting the work done so far, and adding world to repro test with an exception list for the remaining items09:14
kanavin_homethose 61 packages translate to roughly 30 recipes09:15
*** shan1 <shan1!> has quit IRC09:15
paulbarkerkanavin_home: Looks like the go compile tool has a `-buildid` argument:
kanavin_homepaulbarker: yes, but we can't override it, as go build system relies on it to trigger rebuilds - and when building go itself it's not even allowed09:19
paulbarkerkanavin_home: That's particularly helpful09:19
kanavin_homepaulbarker: i got it sorted for go-runtime and go-target, but go-dep and go-helloworld are still writing different buildids with every build09:20
*** mbulut <mbulut!> has quit IRC09:26
*** sno <sno!> has quit IRC09:33
* qschulz waves to all dudX09:33
rburtonare minutes taken of the tuesday technical calls?09:34
*** erbo <erbo!> has quit IRC09:36
*** erbo <erbo!> has joined #yocto09:36
RPkanavin_home: its great progress. Please do submit what you have and take a break! :)09:37
RPkanavin_home: its always been a case of slowly working our way improving things!09:37
RPkanavin_home: could we switch the tests to core-image-sato-sdk and full-cmdline yet?09:37
RPrburton: usually, yes09:37
dev1990paulbarker: I've now a single line: "part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label rootfs.0 --align 4096" which generates proper image, but when I'm inserting "--exclude-path=home/" everything inside rootfs is owned by 1000:100009:43
dev1990no warning or errors in log file09:43
*** faba_ <faba_!> has joined #yocto09:44
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:c8f9:3eda:1e2b:ce68> has quit IRC09:45
kanavin_homeRP: I'm not sure, I simply added 'world' to existing targets in the test09:46
RPkanavin_home: right, I'm just wondering if we can stop things regressing by increasing coverage09:47
RPkanavin_home: I might try a patch09:48
kanavin_homeRP: that was my idea, add a world already now, with an exception list09:48
*** dleppich <dleppich!~Thunderbi@> has joined #yocto09:48
RPkanavin_home: ah, ok :)09:48
*** dleppich <dleppich!~Thunderbi@> has quit IRC09:50
*** dleppich <dleppich!~Thunderbi@> has joined #yocto09:50
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:642b:952b:fb05:74c1> has joined #yocto10:05
*** wertigon <wertigon!> has joined #yocto10:08
*** elGamal <elGamal!~elg@> has quit IRC10:08
wertigonHi everyone! So my problem;10:08
wertigonI have a recipy bbappend, and I want to apply a patch *only* if it is the correct image being built10:09
wertigonHow do I best do this?10:09
wertigone.g. I want to build a test image that allows for running some automated tests, and I want to do some slight modifications to one of the packages that allows me to insert a trace point, but only if it is the test image being built, not the production or dev image.10:11
wertigonI have been able to insert the trace point as a patch file, now I just need for it to apply selectively.10:12
qschulzwertigon: can't do. recipe data is local to the recipe.10:12
wertigonqschulz: Ok, can I create a co-package or something then?10:12
qschulzwertigon: and image recipes are recipes10:12
qschulzwertigon: you could do a second recipe which is requiring the first and just adding a patch10:13
qschulzand then select the appropriate package in the image recipe10:13
LetoThe2ndqschulz: ++10:13
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto10:13
wertigonWith include then? So I do something like package_%.bbappend and or something10:14
qschulzif your recipe/package is used by anything else than the image recipe (RDEPENDS/DEPENDS, etc...), then you are out of luck and need to go the distro route10:14
qschulzwertigon: no bbappend, just a normal bb10:14 and with require at the very beginning of the file10:14
wertigonqschulz: Aha... And if the package is part of another meta layer? :)10:15
wertigonIt is a leaf node package as far as I can tell, but10:15
kanavin_homeRP: so I think I will complete at least reproducibility of go items, and then submit all that's been done so far - it's intricate, manual, tiring work for each recipe, and needs to be done in stages, or spread over more people than just me10:15
RPkanavin_home: right, it is something we've worked incrementally on. I wasn't expecting you to do it all! I was just hoping to figure out where things are at and continue to improve. If people know the list of recipes with issues, that would be a huge win in itself10:18
paulbarkerdev1990: That definitely sounds like something is broken in the way the pseudo database is copied10:19
RPkanavin_home: I'm just really happy to see it moving forward and improving10:20
paulbarkerdev1990: I know that the `--exclude-path` support was tested when it was added by ribalda. There were several patches making pseudo changes recently.10:21
kanavin_homeRP: right, I think adding world with exception list would be beneficial to prevent regressions particularly!10:22
paulbarkerdev1990: Can you roll poky back to 6bf90676038a7a6111bbfeaef2f73614c7206b9e (or oe-core to 429efe4d8a74b5cb2ab1f76088642a078a6f8829) and re-test?10:22
kanavin_homeRP: and you probably know how I am, once an idea is planted in my head :) but this is a bit much :D10:22
RPkanavin_home: yes, agreed!10:22
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:d5b3:b52e:7842:617b> has joined #yocto10:23
LetoThe2ndpaulbarker: "patches making pseudo changes" is an awesome quote out fo context.10:30
*** B0ned1ger2 <B0ned1ger2!> has quit IRC10:35
*** B0ned1ge_ <B0ned1ge_!> has joined #yocto10:35
wertigonqschulz: I think you led me down the proper path there, instead of using a require_once I think I'll just make a mutually exclusive recipe for it10:36
wertigone.g. either use the package OR use the package-test10:36
wertigonAnd then I just copy the recipe, change names and make sure not to use the regular package in the image10:37
qschulzwertigon: the package can be in another meta layer, the require path is then relative to the root of *any* layer (e.g. recipes-bsp/kernel/
wertigonLeast headache methinks10:37
qschulzthe package recipe*10:37
wertigonOk :)10:38
dev1990paulbarker: after rebuilding with 6bf90676038a7a6111bbfeaef2f73614c7206b9e --exclude-path working as expected an rootfs is owned by 0:010:44
*** dreyna <dreyna!> has joined #yocto10:46
paulbarkerRP: ^^^10:53
paulbarkerLooks like some interference between the pseudo fixes and the code in wic which handles --exclude-path by copying the rootfs & the pseudo db10:53
paulbarkerThe commit I asked dev1990 to test was the last one before
RPThat would suggest that PSEUDO_IGNORE_PATHS is set incorrectly when using wic?10:55
paulbarkerThat sounds likely10:55
paulbarkerdev1990: Could you file a bug for this?10:56
*** VAngelo <VAngelo!bd7379b5@> has joined #yocto10:58
paulbarkerI'm busy for the rest of today now but I'll see if I can take a look tomorrow. Perhaps this can be fixed in the wic code by modifying the appropriate variables10:58
*** seebs <seebs!~seebs@> has joined #yocto10:59
*** VAngelo <VAngelo!bd7379b5@> has quit IRC11:00
*** kaspter <kaspter!~Instantbi@> has joined #yocto11:01
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto11:23
*** emrius <emrius!> has joined #yocto11:25
dleppichI'm currently trying out kas for yocto project setups. I have a git repo containing the kas-project.yml file and my custom layer (meta-raspberrypi-selinux). I tried to add this custom layer to my kas config file, but the generated bblayers.conf file does not contain the correct absolute path. According to kas' documentation I thought, it will prepend the kas-working dir to relative paths. This is what I wrote in the kas.yml11:30
dleppich  meta-raspberrypi-selinux:11:30
dleppich    path: meta-raspberrypi-selinux11:30
dev1990paulbarker: ok thanks for help, I reported bug there
dleppichThe resulting bblayers looks like:11:30
dleppich    meta-raspberrypi-selinux/"11:30
dleppichI found no example for the path usage for repos online11:32
*** hpsy <hpsy!~hpsy@> has quit IRC11:33
dleppich*** brb11:35
*** B0ned1ge_ <B0ned1ge_!> has quit IRC11:35
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto11:35
qschulzndec: +1 for LTS variable in poky.yaml :)11:52
*** Yumasi <Yumasi!> has quit IRC11:53
*** sno <sno!> has joined #yocto11:53
*** jobroe <jobroe!> has quit IRC11:57
*** jobroe_ <jobroe_!> has joined #yocto11:57
dleppichI'm back. Does nobody have an idea how to handle relative paths in kas layers? Or maybe an alternative how to deal with own custom layers (other than having them in a separate git repo)?11:57
paulbarkerdleppich: You probably want to add the path into the `layers` list for the current repository instead of adding it as a new repository12:03
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto12:03
dleppichI don't get it, how do I do this?12:04
paulbarkerAre you using any other repos which contain multiple layers, e.g. meta-openembedded?12:05
paulbarkerCopy that pattern for the entry for the repo where your running kas12:05
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC12:06
paulbarkerdleppich: Like
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC12:07
paulbarkerI just threw that together quickly so it may not be exactly right, should hopefully point you in the right direction though12:08
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto12:08
dleppichI'll try that out12:08
paulbarkerdleppich: If you can't get it working post to, you're probably more likely to get good advice there than here though several of us here do use kas12:09
dleppichThanks, your example worked. Except I had to add a colon at the end ;)12:13
*** goliath <goliath!> has joined #yocto12:29
*** dreyna <dreyna!> has quit IRC12:32
*** emrius <emrius!> has quit IRC12:42
*** rperier <rperier!> has quit IRC12:44
*** rperier <rperier!~quassel@unaffiliated/bambee> has joined #yocto12:44
*** emrius <emrius!> has joined #yocto12:48
*** kpo_ <kpo_!> has quit IRC13:03
*** kpo_ <kpo_!> has joined #yocto13:03
*** kaspter <kaspter!~Instantbi@> has quit IRC13:16
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto13:21
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC13:24
*** B0ned1ger2 <B0ned1ger2!> has quit IRC13:35
*** B0ned1ger <B0ned1ger!> has joined #yocto13:35
Ad0is it possible to the result of a conditional with d.getVar in a "require" directive in a recipe?13:36
Ad0require "${@ 'recipe-2' if d.getVar('ENV_VAR') else 'recipe-1'}"  ?13:37
*** Yumasi <Yumasi!> has joined #yocto13:41
emriusHey I have a question regarding the `DL_DIR`. In the mega manual it says: "You can safely share this directory between multiple builds on the same development machine." Does "builds" refer to builds of the same setup or can I have a global DL_DIR used for e.g. the same project which has different image configurations using multiconfigs? Are there any pitfalls there that I don't see yet? I'm the only user on that machine13:47
SaurAd0: Yes, that is possible.13:48
Ad0and in distro.conf, is the same thing possible to use those functions ?13:49
SaurBut beware that  the require is done when the configuration file is parsed, not when the recipes are built.13:53
Ad0that's fine13:53
Saur(For require in *.conf files, that is.)13:53
Ad0I try to export environment variable in the init13:53
Ad0so like export OS_TYPE="dev", then use d.getVar("OS_TYPE")13:53
Ad0I am not sure if normal environment variables are included13:54
SaurThey are not by default. You will have to whitelist any such variable for them to propagate into bitbake.13:54
LetoThe2ndemrius: you can happily share the DL_DIR globally.13:57
LetoThe2ndemrius: all projects, all distros, all machines.13:58
emriusLetoThe2nd thanks for the clarification!13:58
Ad0ok Saur I gotta check that out13:59
*** sakoman <sakoman!~steve@> has joined #yocto13:59
dleppichTwo questions regarding kas:14:00
dleppich1. Do you know of examples or active projects using kas in combination with GitLab CI14:00
dleppich2. I would like to use kas-docker (kas-container) and still share the DL_DIR and SSTATE_CACHE between multiple projects. I saw the video from LetoThe2nd on this topic, but this specific issue wasn't covered due to time limitations. Has anyone found a nice solution for this? I might be able to do some customizations per project to add some extra mounts to the docker container, but I don't want to reinvent the wheel, when there is a nice solution existing :)14:00
Ad0BB_ENV_WHITELIST I Suppose14:00
Ad0just put it in local.conf.sample?14:00
emriusdleppich, I'm on the same path there. I'm using drone ci, not gitlab but I'm facing the same issue :) This +1 for suggestions from anyone... just wanted to share that14:03
LetoThe2nddleppich: well we're hacking the script here, but AFAIK there's already upstream support for it. look at the kas releases page, and/or ask paulbarker once he's arouind again. i think he's the one who implemented it. :)14:03
dleppichLetoThe2nd: Are you answering 1. or 2.? Which releases page do you mean? I only know of the github project ( and the kas documentation (
LetoThe2nddleppich: 2)14:08
*** g0hl1n_ <g0hl1n_!> has joined #yocto14:10
*** g0hl1n_ <g0hl1n_!> has joined #yocto14:10
*** g0hl1n_ <g0hl1n_!> has quit IRC14:11
*** g0hl1n <g0hl1n!> has joined #yocto14:11
*** jubalh <jubalh!~jubalh@unaffiliated/jubalh> has quit IRC14:13
dleppich2) I found out, that kas-container has a parameter "--runtime-args". It is possible to pass it mount parameters for the docker container. Already a bit cleaner than hacking something into the script.14:20
dleppichBetter solutions are still appreciated :)14:20
qschulzndec: now that I'm thinking about it... do we actually need DISTRO_NAME_MINUS_ONE if we have DISTRO_NAME_LTS?14:22
ndecwe need to check where/how it's used..14:23
ndecbut it's a good question!14:23
*** florian_kc is now known as florian14:25
qschulzndec: I think we can afford it14:30
qschulzit's not going to be perfect examples then (non consecutive version examples, e.g. for LAYERSERIES_COMPAT)14:31
qschulzbut I think it's fine?14:31
qschulzalso... is there any plan to have two LTS at the same time? in which case it should be named DISTRO_NAME_LATEST_LTS?14:31
*** stephano <stephano!> has joined #yocto14:36
LetoThe2ndqschulz: not plan, but ... never say never ;-)14:37
ndecqschulz: right now , no. but right.. it might happen, it really depends if members/community need (and can afford) to contiue!14:41
LetoThe2ndnow everybody, this is the LTS theme:
LetoThe2ndndec: well to be honest, at ELC-Not-Really-EU, you sounded very much like "insert coins and get more LTS"14:42
ndecwell, it does boil down to that..14:43
* LetoThe2nd ponders finding some metal song about boiling down...14:44
*** ssajal <ssajal!> has joined #yocto14:45
*** Saur <Saur!pkj@nat/axis/x-hhuerjxhrvdbvmim> has quit IRC14:53
*** Saur <Saur!pkj@nat/axis/x-hmcalcodgxxyinwg> has joined #yocto14:53
*** ericch <ericch!> has joined #yocto14:53
*** Saur <Saur!pkj@nat/axis/x-hmcalcodgxxyinwg> has quit IRC14:54
*** Saur <Saur!pkj@nat/axis/x-mkyufnjfzystsaac> has joined #yocto14:57
*** ThomasD13 <ThomasD13!> has quit IRC15:03
qschulzLetoThe2nd: BTW, I'm still surprised you don't have "It depends (TM)" in your Twitter bio :p15:10
LetoThe2ndqschulz: not everything need to be on twitter... though I could put it on instagram :P15:11
LetoThe2ndi''m really curious about the attendance of the next session specifically, and next couple ones generally... as i've started announcing on youtube and instagram too.15:12
*** King_InuYasha is now known as Conan_Kudo15:12
*** Conan_Kudo is now known as King_InuYasha15:12
*** emrius <emrius!> has quit IRC15:15
*** roussinm <roussinm!> has joined #yocto15:16
*** paulg_ <paulg_!> has joined #yocto15:19
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto15:24
*** yann <yann!~yann@> has quit IRC15:26
*** yann <yann!~yann@> has joined #yocto15:26
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto15:28
*** paulg_ <paulg_!> has quit IRC15:30
*** yann <yann!~yann@> has quit IRC15:30
*** renaudk32 <renaudk32!5bb7e8b1@> has joined #yocto15:30
*** renaudk32 <renaudk32!5bb7e8b1@> has left #yocto15:38
*** paulg_ <paulg_!> has joined #yocto15:38
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC15:43
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto15:50
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC15:52
*** AndersD_ <AndersD_!> has quit IRC15:54
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto16:00
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC16:04
*** Konsgn <Konsgn!> has joined #yocto16:07
*** Konsgn is now known as Konsgnx16:07
*** Konsgnx is now known as Konsgnxx16:07
*** dleppich <dleppich!~Thunderbi@> has quit IRC16:08
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC16:15
*** sstiller <sstiller!> has quit IRC16:20
*** sno <sno!> has quit IRC16:23
*** jobroe_ <jobroe_!> has quit IRC16:24
*** fl0v0 <fl0v0!~fvo@> has quit IRC16:34
*** fl0v0 <fl0v0!~fvo@> has joined #yocto16:35
*** kpo_ <kpo_!> has quit IRC16:39
*** kpo_ <kpo_!> has joined #yocto16:40
*** Yumasi <Yumasi!> has quit IRC16:55
*** Yumasi <Yumasi!> has joined #yocto17:01
*** mckoan is now known as mckoan|away17:01
*** zandrey <zandrey!~zandrey@> has quit IRC17:01
*** fl0v0 <fl0v0!~fvo@> has quit IRC17:13
*** frsc <frsc!> has quit IRC17:22
*** sagner <sagner!~ags@2a02:169:3df5::979> has quit IRC17:30
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC17:31
*** B0ned1ger <B0ned1ger!> has quit IRC17:35
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto17:35
*** dmoseley <dmoseley!~dmoseley@> has quit IRC17:47
tlwoernerthe next OE Happy Hour is 1 week +4 hrs from right now :-)17:49
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:51
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto17:51
*** sno <sno!> has joined #yocto17:58
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC17:58
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto17:59
*** sno <sno!> has quit IRC18:07
*** leon-anavi <leon-anavi!~Leon@> has quit IRC18:18
*** vineela <vineela!vtummala@nat/intel/x-lypbevzileyitytt> has joined #yocto18:18
*** kiwi_29 <kiwi_29!> has joined #yocto18:38
kiwi_29Hello... for this recipe
kiwi_29in the do_install the line  install -m 0755 ${WORKDIR}${COREBASE}/scripts/oe-* ${D}${bindir}/   does not seem correct and seems to be erroring when I run "bitbake -c populate_sdk <MY_CUSTOM_DISTRO>"18:39
kiwi_29because ${WORKDIR} is place where packges are downloaded, compiled and packaged where as COREBASE is parent of meta directory18:41
kiwi_29Please let me know if what I am saying makes sense18:41
*** faba_ <faba_!> has quit IRC18:43
bluelightningkiwi_29: that is a bit odd looking I agree - it has been that way for quite a long time though18:46
kiwi_29bluelightning yes . should I open a bug ticket?18:47
bluelightningoh, I see where it's coming from18:47
kiwi_29I checked the history and the first commit has that too18:48
bluelightningit's because SRC_URI uses ${COREBASE} references, which means that the files are unpacked in that subdir (which frankly I consider a separate bug, but then that is how it's been for a while too and is a bit of a corner case)18:49
bluelightningwhat is the value of COREBASE in your case ?18:49
kiwi_29SRC_URI looks ok because the parent of meta directory (meta as in the poky source code) contains script folder and all the items mentioned in SRC_URI18:50
kiwi_29SRC_URI path is correct18:51
kiwi_29however the ${WORKDIR}${COREBASE} path never exists18:51
kiwi_29bluelightning .. I see what you are saying..when the recipes run it unpacks those files in COREBASE ...which is odd in itself ..eventough the SRC_URI path is correct18:52
kiwi_29It probably may be designed that way deliberately..because I am running this command "bitbake -c populate_sdk <MY_CUSTOM_DISTRO>"18:52
kiwi_29I am generate yocto sdk18:52
bluelightningwell, the full ${COREBASE} path is appended onto ${WORKDIR} when unpacking (standard behaviour for absolute paths in SRC_URI)18:53
bluelightningbut what exactly is COREBASE expanding to in your configuration?18:53
kiwi_29but not correct path in do_install ..correct?18:53
bluelightningwell, they should match up18:53
kiwi_29COREBASE is the parent of meta source dir in my builds too18:53
kiwi_29and therefore ${WORKDIR}${COREBASE} never exists18:54
bluelightningthe recipe as written is correct based upon the behaviour of bitbake when it unpacks files referenced with an absolute path, unless COREBASE is somewhat unusual18:54
kiwi_29I dont see any reason for ${WORKDIR}${COREBASE}. to be used in install ... ${WORKDIR}${COREBASE} probably will never exist.. that is the error I get   "No such file or directory"18:55
bluelightningit should exist because that's where we expect bitbake to unpack it to - I know it looks weird18:55
bluelightningif it's not doing that then there is something unusual in your configuration (I say unusual, not necessarily wrong)18:56
kiwi_29The first line in do_install is install -d ${D}${bindir}18:57
kiwi_29so there should also be install -d ${WORKDIR}${COREBASE}18:58
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:59
*** wertigon <wertigon!> has quit IRC19:01
*** kiwi_29 <kiwi_29!> has quit IRC19:05
*** kiwi_29 <kiwi_29!> has joined #yocto19:05
JaMahalstead: can you please unblock patchwork again? it got stuck 8 days ago19:12
halsteadYes JaMa, It's odd it's not blocked on all the projects. More permanent solution on the way.19:14
halsteadI'll get the missing patches into oe-core patchwork project.19:16
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC19:19
*** kiwi_29 <kiwi_29!> has quit IRC19:25
JaMahalstead: thanks19:26
*** Yumasi <Yumasi!> has quit IRC19:30
*** dreyna <dreyna!> has joined #yocto19:32
*** beneth <beneth!> has left #yocto19:36
*** kiwi_29 <kiwi_29!> has joined #yocto19:40
*** oberstet <oberstet!~oberstet@> has quit IRC19:45
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto19:56
*** maudat <maudat!> has joined #yocto20:07
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:642b:952b:fb05:74c1> has quit IRC20:15
*** kiwi_29 <kiwi_29!> has quit IRC20:19
*** kiwi_29 <kiwi_29!> has joined #yocto20:33
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:d5b3:b52e:7842:617b> has quit IRC20:40
bluelightningkiwi_29: no - you're mixing up source and destination there, ${WORKDIR}${COREBASE} is the source in that operation20:45
kiwi_29bluelightning ..let me doublecheck20:50
*** vineela <vineela!vtummala@nat/intel/x-lypbevzileyitytt> has quit IRC20:52
kiwi_29bluelightning .. when I run bitbake <MYCUSTOMDISTRO> -c populate_sdk -e , I get WORKDIR=<MY_POKY_INSSTALL_PATH>/poky/build/tmp/work/MACHINE/DISTRO/1.0-r020:53
kiwi_29which is basically where stuff related to distro gets fetched, compiled and packed20:54
kiwi_29so inside that folder there is no way to have COREBASE20:55
kiwi_29so while I agree WORKDIR is not the destination for nativesdk-qemu-helper package , WORKDIR is destination for packages mean for DISTRO .20:57
kiwi_29The destination for nativesdk-qemu-helper  is <MY_POKY_INSTALL_PATH>/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu-helper/1.0-r9/21:00
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:58da:1312:27b2:8581> has joined #yocto21:00
*** kiwi_29 <kiwi_29!> has quit IRC21:05
*** manuel19851 <manuel19851!> has joined #yocto21:16
manuel19851Can anyone tell me why I cannot join this channel with Konversation, only with pidgin? Strictly speaking, with Konversation, I CAN join the channel, but it's as if I were alone here.21:19
*** kiwi_29 <kiwi_29!> has joined #yocto21:35
jonmasonIs meta-oe master busted?  I'm seeing errors now that I wasn't seeing a couple hours ago21:45
jonmasonERROR: ParseError at /home/jdm/yocto/poky/meta-openembedded/meta-oe/recipes-extended/libimobiledevice/ Could not inherit file classes/python3targetconfig.bbclass21:45
jonmasonobviously, I'm not messing with any of this, just trying to build meta-arm stuff21:45
kiwi_29bluelightning .. I think the problem has to do with the way my filesystem is organized ..debugging it now21:49
*** zillolo <zillolo!~zillolo@> has joined #yocto21:56
*** hpsy <hpsy!~hpsy@> has joined #yocto21:58
RPjonmason: maybe you need to update oe-core?22:07
jonmasonRP: using `bitbake-layers layerindex-fetch -b master`22:08
jonmasonso it should be the latest22:08
RPjonmason: ok, other option may be the patches in master-next22:09
*** Konsgnxx <Konsgnxx!> has quit IRC22:09
jonmasonI'm temporarily using gatesgarth branches to get around it22:09
RPjonmason: there was a lot of discussion on the lists and there is a patch in master-next but I was waiting to see if the discussion settled22:10
jonmasonno prob, just weird to see it happen mid-day.  I was worried I did something stupid in my changes :)22:11
RPjonmason: I don't know, I haven't followed things closely enough22:11
*** meow` <meow`!~sbourdeli@> has quit IRC22:11
*** meow` <meow`!~sbourdeli@> has joined #yocto22:25
*** m1ster_r- <m1ster_r-!> has joined #yocto22:27
*** lexano[m] <lexano[m]!lexanomatr@gateway/shell/> has quit IRC22:27
*** lexano[m] <lexano[m]!lexanomatr@gateway/shell/> has joined #yocto22:28
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC22:28
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has quit IRC22:28
*** m1ster_r0b0t <m1ster_r0b0t!> has quit IRC22:28
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto22:28
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has joined #yocto22:31
*** pohly <pohly!> has quit IRC22:33
*** vineela <vineela!~vtummala@> has joined #yocto22:46
*** agust <agust!> has quit IRC22:58
khemRP:  pkg_postinst_ontarget_${PN} does not play well with readonly rootfs whats the way out for such recipes23:05
khemdeltask pkg_postinst_ontarget_${PN} in a bbappend ?23:05
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC23:06
RPkhem: usually the postinsts are needed so it means the recipe isn't suited to ro rootfs :(23:07
RPkhem: they're not tasks so deltask won't work. you could delVar I guess23:08
khemyeah the case I have is that this postinst is not needed in ro case23:09
*** marka <marka!> has quit IRC23:12
*** geissonator <geissonator!~geissonat@> has quit IRC23:12
*** marka <marka!> has joined #yocto23:12
RPkhem: delVar I guess. Makes me wonder whether we really need it at all...23:13
*** smartin <smartin!> has quit IRC23:13
*** geissonator <geissonator!~geissonat@> has joined #yocto23:14
khemfor RO case they are probably good suggestions but not needed most of time23:20
*** smartin <smartin!> has joined #yocto23:24
*** vdehors <vdehors!> has joined #yocto23:27
*** vdehors_ <vdehors_!> has quit IRC23:29
*** vdehors <vdehors!> has quit IRC23:35
*** vdehors_ <vdehors_!> has joined #yocto23:35
*** maudat <maudat!> has quit IRC23:53

Generated by 2.17.2 by Marius Gedminas - find it at!