**** BEGIN LOGGING AT Wed Nov 18 03:02:03 2020 Nov 18 03:17:11 Hello... while generating and sdk (not extensible sdk) using. bitbake -c populate_sdk , I get errors ----> ERROR: binutils-crosssdk-x86_64-pokysdk-linux-2.34-r0 do_configure: configure failed Nov 18 03:17:45 Last few lines of config output are Nov 18 03:18:06 checking where to find the target windres... pre-installed Nov 18 03:18:06 checking where to find the target windmc... pre-installed Nov 18 03:18:06 checking whether to enable maintainer-specific portions of Makefiles... no Nov 18 03:18:08 configure: creating ./config.status Nov 18 03:18:10 config.status: error: cannot find input file: `Makefile.in' Nov 18 03:18:12 WARNING: exit code 1 from a shell command. Nov 18 03:18:33 basically config.status when called by configure in the end, throws error Nov 18 03:19:01 but when I run config.status separately inside devshell, it succeeds and there is a Makefile.in also present in the source dir Nov 18 03:19:07 does this ring any bells? Nov 18 03:53:28 RP: sending a v2. you'll have it in your inbox in your morning. Nov 18 04:57:45 RP: 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. Nov 18 06:03:40 good morning Nov 18 06:17:59 When 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 = ..." Nov 18 06:18:35 Is 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 = ..." ? Nov 18 06:20:12 ThomasD13: 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. Nov 18 06:22:00 mcfrisk, okay thank you. Where do I specify the BBMASK variable? Nov 18 06:22:58 ThomasD13: for example in your distro config Nov 18 06:23:11 alright, thank you Nov 18 06:38:42 ThomasD13: 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, including Nov 18 06:38:48 most 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. Nov 18 06:39:41 Okay, I didn't know that using BBMASKing is a common thing Nov 18 06:57:02 ThomasD13: 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. Nov 18 07:00:05 for 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 for Nov 18 07:00:11 bootloader and kernel. Nov 18 07:03:38 mcfrisk, did you work also on TI BSP layers? Nov 18 07:05:24 ThomasD13: a bit, yes Nov 18 07:07:24 so far meta-ti only required one BBMASK line in my use: BBMASK += "meta-ti/recipes-devtools/doxygen" # use from meta-openembedded instead Nov 18 07:09:13 Okay. I need to change the used kernel repository of linux kernel source code. Thought this would be trivial, but it seems its not :) Nov 18 07:10:02 Not sure if I should just define a own machine, and use the standard kernel recipe not the ti ones Nov 18 07:10:32 ThomasD13: for sure, you need your own machine config for custom HW Nov 18 07:11:04 you can start with a copy from eval board machine config from meta-ti Nov 18 07:14:48 Yes, I just started to looking on j7-evm configuration. But I'm still not sure about these "_append_j7" variable extensions in some ti recipes Nov 18 07:15:26 I think they link somehow to the machine configuration name. Need to reread yocto manual to understand this Nov 18 07:18:23 ah jacinto stuff Nov 18 07:18:30 yes :) Nov 18 07:21:38 I 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. Nov 18 07:35:41 When I have a variable "SOMEVAR = "value1"", and "SOMEVAR_foo = "value2"". How is the "_foo" extension called, so I can google for it? Virtual Provider? Nov 18 07:36:25 And additionally, if I have a machine configuration, called "foo", does the value of SOMEVAR is value2 ? Nov 18 07:38:49 ThomasD13: https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#override-style-operation-advantages and yes. Nov 18 07:39:38 ThomasD13: sorry, link to wrong paragraph. should be https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides Nov 18 07:40:41 ThomasD13: you can always check the net effect of all settings with "bitbake -e recipe". There you can see which overrides bbappends etc take effect. Nov 18 07:41:14 Thank you LetoThe2nd. Does this override only affects on machine names? Nov 18 07:41:43 ThomasD13: nope. machine, disro... no idea about all effects. time to read the manual. Nov 18 07:41:50 *thumpsup Nov 18 07:42:24 mcfrisk: to add on what mcfrisk just said, you can use the magic given at https://theyoctojester.info/session_14/main.html for some neat extraction of variable evaluation from bitbake -e Nov 18 07:43:01 ah meh, that was for ThomasD13 obviously. Nov 18 07:43:16 Ill check it out Nov 18 07:46:29 oh and g'mournin (UGT) dudX Nov 18 07:47:36 GM Nov 18 07:49:22 Ahh, maybe this is part of the key :) bitbake/conf/bitbake.conf:OVERRIDES = "local:${MACHINE}:${TARGET_OS}:${TARGET_ARCH}" Nov 18 07:49:32 Thanks guys! Much more clear now for me Nov 18 07:55:26 ThomasD13: cue https://youtu.be/8F8xqbgxRaA Nov 18 07:57:16 Sorry, won't visist youtube on my working pc :) But later when I'm home Nov 18 07:57:26 böring :P Nov 18 08:42:48 ThomasD13: look at OVERRIDES set in oe-core's bitbake.conf as its slightly different. The version in bitbake isn't used Nov 18 08:50:49 hi, when I'm using --exclude-path=home/ for my rootfs partition whole image become owned by 1000:1000, is this a known bug ? Nov 18 08:55:00 dev1990: Which Yocto Project branch are you using? Nov 18 08:55:46 gatesgarth Nov 18 08:56:14 by typing here I found that I'm using "=" in syntax, maybe this is wrong Nov 18 08:57:44 `--exclude-path=home` should be right, you can probably drop the trailing `/` Nov 18 08:58:22 Are you running wic under bitbake or directly from the command line? Nov 18 08:58:53 paulbarker: 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) Nov 18 08:58:56 from bitbake Nov 18 09:01:10 I don't want to drop* Nov 18 09:01:26 https://github.com/dev-0x7C6/meta-retro/blob/master/wic/sdimage-dual-raspberrypi-retro.wks.in Nov 18 09:02:06 this becomes a problematic image when I add "--exclude-path=home/" Nov 18 09:03:33 dev1990: If you modify it to have just one copy of the rootfs does it work then? Nov 18 09:04:10 Could you also check the `log.do_image_wic` file for any warnings or errors Nov 18 09:13:18 RP: some progress on world reproducibility Nov 18 09:13:18 2020-11-18 01:14:44,957 - oe-selftest - INFO - Reproducibility summary for deb: same=11214 different=61 missing=0 total=11275 Nov 18 09:13:18 2020-11-18 01:21:44,991 - oe-selftest - INFO - Reproducibility summary for ipk: same=11214 different=61 missing=0 total=11275 Nov 18 09:14:10 RP: 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 cache Nov 18 09:14:53 I'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 items Nov 18 09:15:12 those 61 packages translate to roughly 30 recipes Nov 18 09:18:32 kanavin_home: Looks like the go compile tool has a `-buildid` argument: https://golang.org/cmd/compile/ Nov 18 09:19:43 paulbarker: 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 allowed Nov 18 09:19:59 kanavin_home: That's particularly helpful Nov 18 09:20:58 paulbarker: i got it sorted for go-runtime and go-target, but go-dep and go-helloworld are still writing different buildids with every build Nov 18 09:33:23 * qschulz waves to all dudX Nov 18 09:34:12 are minutes taken of the tuesday technical calls? Nov 18 09:37:08 kanavin_home: its great progress. Please do submit what you have and take a break! :) Nov 18 09:37:25 kanavin_home: its always been a case of slowly working our way improving things! Nov 18 09:37:47 kanavin_home: could we switch the tests to core-image-sato-sdk and full-cmdline yet? Nov 18 09:37:53 rburton: usually, yes Nov 18 09:43:04 paulbarker: 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:1000 Nov 18 09:43:29 no warning or errors in log file Nov 18 09:46:42 RP: I'm not sure, I simply added 'world' to existing targets in the test Nov 18 09:47:49 kanavin_home: right, I'm just wondering if we can stop things regressing by increasing coverage Nov 18 09:48:05 kanavin_home: I might try a patch Nov 18 09:48:10 RP: that was my idea, add a world already now, with an exception list Nov 18 09:48:36 kanavin_home: ah, ok :) Nov 18 10:08:57 Hi everyone! So my problem; Nov 18 10:09:41 I have a recipy bbappend, and I want to apply a patch *only* if it is the correct image being built Nov 18 10:09:53 How do I best do this? Nov 18 10:11:37 e.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. Nov 18 10:12:15 I have been able to insert the trace point as a patch file, now I just need for it to apply selectively. Nov 18 10:12:22 wertigon: can't do. recipe data is local to the recipe. Nov 18 10:12:40 qschulz: Ok, can I create a co-package or something then? Nov 18 10:12:43 wertigon: and image recipes are recipes Nov 18 10:13:06 wertigon: you could do a second recipe which is requiring the first and just adding a patch Nov 18 10:13:14 and then select the appropriate package in the image recipe Nov 18 10:13:38 qschulz: ++ Nov 18 10:14:00 With include then? So I do something like package_%.bbappend and package-test.1.0.bb or something Nov 18 10:14:01 if 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 route Nov 18 10:14:15 wertigon: no bbappend, just a normal bb Nov 18 10:14:55 package_1.0.bb and package-test_1.0.bb with require package_1.0.bb at the very beginning of the package-test_1.0.bb file Nov 18 10:15:37 qschulz: Aha... And if the package is part of another meta layer? :) Nov 18 10:15:51 It is a leaf node package as far as I can tell, but Nov 18 10:15:57 RP: 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 me Nov 18 10:18:55 kanavin_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 itself Nov 18 10:19:38 dev1990: That definitely sounds like something is broken in the way the pseudo database is copied Nov 18 10:20:54 kanavin_home: I'm just really happy to see it moving forward and improving Nov 18 10:21:50 dev1990: I know that the `--exclude-path` support was tested when it was added by ribalda. There were several patches making pseudo changes recently. Nov 18 10:22:05 RP: right, I think adding world with exception list would be beneficial to prevent regressions particularly! Nov 18 10:22:25 dev1990: Can you roll poky back to 6bf90676038a7a6111bbfeaef2f73614c7206b9e (or oe-core to 429efe4d8a74b5cb2ab1f76088642a078a6f8829) and re-test? Nov 18 10:22:38 RP: and you probably know how I am, once an idea is planted in my head :) but this is a bit much :D Nov 18 10:22:41 kanavin_home: yes, agreed! Nov 18 10:30:02 paulbarker: "patches making pseudo changes" is an awesome quote out fo context. Nov 18 10:36:13 qschulz: 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 it Nov 18 10:36:31 e.g. either use the package OR use the package-test Nov 18 10:37:21 And then I just copy the recipe, change names and make sure not to use the regular package in the image Nov 18 10:37:22 wertigon: 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/linux-yocto_5.4.bb) Nov 18 10:37:33 Least headache methinks Nov 18 10:37:48 the package recipe* Nov 18 10:38:05 Ok :) Nov 18 10:44:26 paulbarker: after rebuilding with 6bf90676038a7a6111bbfeaef2f73614c7206b9e --exclude-path working as expected an rootfs is owned by 0:0 Nov 18 10:53:11 RP: ^^^ Nov 18 10:53:40 Looks like some interference between the pseudo fixes and the code in wic which handles --exclude-path by copying the rootfs & the pseudo db Nov 18 10:54:17 The commit I asked dev1990 to test was the last one before http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=gatesgarth&id=b5c5d84b8be27c611c1c21d5c13039a90977bbd4 Nov 18 10:55:02 That would suggest that PSEUDO_IGNORE_PATHS is set incorrectly when using wic? Nov 18 10:55:49 That sounds likely Nov 18 10:56:21 dev1990: Could you file a bug for this? Nov 18 10:58:05 ok Nov 18 10:58:54 I'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 variables Nov 18 11:30:33 I'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.yml Nov 18 11:30:35 repos: Nov 18 11:30:35 meta-raspberrypi-selinux: Nov 18 11:30:35 path: meta-raspberrypi-selinux Nov 18 11:30:38 paulbarker: ok thanks for help, I reported bug there https://bugzilla.yoctoproject.org/show_bug.cgi?id=14129 Nov 18 11:30:58 The resulting bblayers looks like: Nov 18 11:30:58 ... Nov 18 11:30:58 meta-raspberrypi-selinux/" Nov 18 11:32:36 I found no example for the path usage for repos online Nov 18 11:35:13 *** brb Nov 18 11:52:57 ndec: +1 for LTS variable in poky.yaml :) Nov 18 11:53:13 ;) Nov 18 11:57:39 I'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)? Nov 18 12:03:18 dleppich: You probably want to add the path into the `layers` list for the current repository instead of adding it as a new repository Nov 18 12:04:22 I don't get it, how do I do this? Nov 18 12:05:04 Are you using any other repos which contain multiple layers, e.g. meta-openembedded? Nov 18 12:05:10 Yes Nov 18 12:05:59 Copy that pattern for the entry for the repo where your running kas Nov 18 12:07:12 dleppich: Like https://pastebin.com/VsKzwggg Nov 18 12:08:03 I just threw that together quickly so it may not be exactly right, should hopefully point you in the right direction though Nov 18 12:08:18 I'll try that out Nov 18 12:09:35 dleppich: If you can't get it working post to https://groups.google.com/g/kas-devel, you're probably more likely to get good advice there than here though several of us here do use kas Nov 18 12:13:06 Thanks, your example worked. Except I had to add a colon at the end ;) Nov 18 13:36:13 is it possible to the result of a conditional with d.getVar in a "require" directive in a recipe? Nov 18 13:37:03 require "${@ 'recipe-2' if d.getVar('ENV_VAR') else 'recipe-1'}" ? Nov 18 13:47:26 Hey 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 machine Nov 18 13:48:27 Ad0: Yes, that is possible. Nov 18 13:48:38 cool Nov 18 13:49:00 and in distro.conf, is the same thing possible to use those functions ? Nov 18 13:51:56 Yes. Nov 18 13:52:46 nice Nov 18 13:53:12 But beware that the require is done when the configuration file is parsed, not when the recipes are built. Nov 18 13:53:22 that's fine Nov 18 13:53:28 (For require in *.conf files, that is.) Nov 18 13:53:31 I try to export environment variable in the init Nov 18 13:53:50 so like export OS_TYPE="dev", then use d.getVar("OS_TYPE") Nov 18 13:54:09 I am not sure if normal environment variables are included Nov 18 13:54:45 They are not by default. You will have to whitelist any such variable for them to propagate into bitbake. Nov 18 13:57:43 emrius: you can happily share the DL_DIR globally. Nov 18 13:58:00 emrius: all projects, all distros, all machines. Nov 18 13:58:30 LetoThe2nd thanks for the clarification! Nov 18 13:59:10 ok Saur I gotta check that out Nov 18 14:00:34 Two questions regarding kas: Nov 18 14:00:34 1. Do you know of examples or active projects using kas in combination with GitLab CI Nov 18 14:00:34 2. 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 :) Nov 18 14:00:37 BB_ENV_WHITELIST I Suppose Nov 18 14:00:47 YEs Nov 18 14:00:59 just put it in local.conf.sample? Nov 18 14:03:02 dleppich, 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 that Nov 18 14:03:42 dleppich: 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. :) Nov 18 14:05:43 LetoThe2nd: Are you answering 1. or 2.? Which releases page do you mean? I only know of the github project (https://github.com/siemens/kas) and the kas documentation (https://kas.readthedocs.io/). Nov 18 14:08:59 dleppich: 2) Nov 18 14:20:46 2) 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. Nov 18 14:20:46 Better solutions are still appreciated :) Nov 18 14:22:18 ndec: now that I'm thinking about it... do we actually need DISTRO_NAME_MINUS_ONE if we have DISTRO_NAME_LTS? Nov 18 14:23:00 we need to check where/how it's used.. Nov 18 14:23:08 but it's a good question! Nov 18 14:30:37 ndec: I think we can afford it Nov 18 14:31:07 it's not going to be perfect examples then (non consecutive version examples, e.g. for LAYERSERIES_COMPAT) Nov 18 14:31:15 but I think it's fine? Nov 18 14:31:46 also... is there any plan to have two LTS at the same time? in which case it should be named DISTRO_NAME_LATEST_LTS? Nov 18 14:37:03 qschulz: not plan, but ... never say never ;-) Nov 18 14:41:17 qschulz: right now , no. but right.. it might happen, it really depends if members/community need (and can afford) to contiue! Nov 18 14:42:15 now everybody, this is the LTS theme: https://youtu.be/2nX6qGeyaGM Nov 18 14:42:55 ndec: well to be honest, at ELC-Not-Really-EU, you sounded very much like "insert coins and get more LTS" Nov 18 14:43:20 well, it does boil down to that.. Nov 18 14:44:12 * LetoThe2nd ponders finding some metal song about boiling down... Nov 18 15:10:51 LetoThe2nd: BTW, I'm still surprised you don't have "It depends (TM)" in your Twitter bio :p Nov 18 15:11:23 qschulz: not everything need to be on twitter... though I could put it on instagram :P Nov 18 15:12:20 i''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. Nov 18 17:49:10 the next OE Happy Hour is 1 week +4 hrs from right now :-) Nov 18 18:38:56 Hello... for this recipe https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb?h=dunfell Nov 18 18:39:56 in 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 " Nov 18 18:41:18 because ${WORKDIR} is place where packges are downloaded, compiled and packaged where as COREBASE is parent of meta directory Nov 18 18:41:57 Please let me know if what I am saying makes sense Nov 18 18:46:46 kiwi_29: that is a bit odd looking I agree - it has been that way for quite a long time though Nov 18 18:47:23 bluelightning yes . should I open a bug ticket? Nov 18 18:47:39 oh, I see where it's coming from Nov 18 18:48:25 I checked the history and the first commit has that too Nov 18 18:49:08 it'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) Nov 18 18:49:26 what is the value of COREBASE in your case ? Nov 18 18:50:53 SRC_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_URI Nov 18 18:51:01 SRC_URI path is correct Nov 18 18:51:15 however the ${WORKDIR}${COREBASE} path never exists Nov 18 18:52:00 bluelightning .. 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 correct Nov 18 18:52:41 It probably may be designed that way deliberately..because I am running this command "bitbake -c populate_sdk " Nov 18 18:52:50 I am generate yocto sdk Nov 18 18:52:56 *generating Nov 18 18:53:05 well, the full ${COREBASE} path is appended onto ${WORKDIR} when unpacking (standard behaviour for absolute paths in SRC_URI) Nov 18 18:53:26 but what exactly is COREBASE expanding to in your configuration? Nov 18 18:53:30 but not correct path in do_install ..correct? Nov 18 18:53:41 well, they should match up Nov 18 18:53:45 COREBASE is the parent of meta source dir in my builds too Nov 18 18:54:10 and therefore ${WORKDIR}${COREBASE} never exists Nov 18 18:54:14 the recipe as written is correct based upon the behaviour of bitbake when it unpacks files referenced with an absolute path, unless COREBASE is somewhat unusual Nov 18 18:55:07 I 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" Nov 18 18:55:43 it should exist because that's where we expect bitbake to unpack it to - I know it looks weird Nov 18 18:56:15 if it's not doing that then there is something unusual in your configuration (I say unusual, not necessarily wrong) Nov 18 18:57:45 The first line in do_install is install -d ${D}${bindir} Nov 18 18:58:11 so there should also be install -d ${WORKDIR}${COREBASE} Nov 18 18:58:14 no? Nov 18 19:12:29 halstead: can you please unblock patchwork again? it got stuck 8 days ago Nov 18 19:14:26 Yes JaMa, It's odd it's not blocked on all the projects. More permanent solution on the way. Nov 18 19:16:46 I'll get the missing patches into oe-core patchwork project. Nov 18 19:26:57 halstead: thanks Nov 18 20:45:43 kiwi_29: no - you're mixing up source and destination there, ${WORKDIR}${COREBASE} is the source in that operation Nov 18 20:50:22 bluelightning ..let me doublecheck Nov 18 20:53:26 bluelightning .. when I run bitbake -c populate_sdk -e , I get WORKDIR=/poky/build/tmp/work/MACHINE/DISTRO/1.0-r0 Nov 18 20:54:00 which is basically where stuff related to distro gets fetched, compiled and packed Nov 18 20:55:39 so inside that folder there is no way to have COREBASE Nov 18 20:56:50 COREBASE is Nov 18 20:57:50 so while I agree WORKDIR is not the destination for nativesdk-qemu-helper package , WORKDIR is destination for packages mean for DISTRO . Nov 18 21:00:18 The destination for nativesdk-qemu-helper is /poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-qemu-helper/1.0-r9/ Nov 18 21:19:17 Can 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. Nov 18 21:45:25 Is meta-oe master busted? I'm seeing errors now that I wasn't seeing a couple hours ago Nov 18 21:45:25 ERROR: ParseError at /home/jdm/yocto/poky/meta-openembedded/meta-oe/recipes-extended/libimobiledevice/libplist_2.2.0.bb:9: Could not inherit file classes/python3targetconfig.bbclass Nov 18 21:45:49 obviously, I'm not messing with any of this, just trying to build meta-arm stuff Nov 18 21:49:55 bluelightning .. I think the problem has to do with the way my filesystem is organized ..debugging it now Nov 18 22:07:42 jonmason: maybe you need to update oe-core? Nov 18 22:08:40 RP: using `bitbake-layers layerindex-fetch -b master` Nov 18 22:08:43 so it should be the latest Nov 18 22:09:04 jonmason: ok, other option may be the patches in master-next Nov 18 22:09:58 I'm temporarily using gatesgarth branches to get around it Nov 18 22:10:26 jonmason: 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 settled Nov 18 22:11:09 no prob, just weird to see it happen mid-day. I was worried I did something stupid in my changes :) Nov 18 22:11:43 jonmason: I don't know, I haven't followed things closely enough Nov 18 23:05:05 RP: pkg_postinst_ontarget_${PN} does not play well with readonly rootfs whats the way out for such recipes Nov 18 23:05:33 deltask pkg_postinst_ontarget_${PN} in a bbappend ? Nov 18 23:07:56 khem: usually the postinsts are needed so it means the recipe isn't suited to ro rootfs :( Nov 18 23:08:22 khem: they're not tasks so deltask won't work. you could delVar I guess Nov 18 23:09:01 yeah the case I have is that this postinst is not needed in ro case Nov 18 23:13:16 khem: delVar I guess. Makes me wonder whether we really need it at all... Nov 18 23:20:55 for RO case they are probably good suggestions but not needed most of time Nov 19 01:50:44 bluelightning the issue of ${WORKDIR}${COREBASE} was misconfiguration on my end :( Nov 19 02:28:09 Hello all, I am currently building sdk using "bitbake -c populate_sdk " Nov 19 02:28:13 kiwi_29: ah ok - anything we might want to consider in terms of additional checks / documentation? Nov 19 02:28:53 The following packages have unmet dependencies: Nov 19 02:28:53 target-sdk-provides-dummy : Conflicts: coreutils Nov 19 02:28:53 E: Unable to correct problems, you have held broken packages. Nov 19 02:28:55 and I am getting this error Nov 19 02:29:29 bluelightning - the previous talk we had about ${WORKDIR}${COREBASE} was entirely my configuration problem Nov 19 02:30:02 the current issue about target-sdk-provides-dummy which conflicts with coreutils is a known bug it seems https://bugzilla.yoctoproject.org/show_bug.cgi?id=13338 Nov 19 02:30:15 has anybody been able to solve the issue? Nov 19 02:42:08 kiwi_29: I've just reopened the bug FWIW Nov 19 02:49:14 many thanks bluelightning Nov 19 02:49:53 I am using deb ... and not rpm or ipk . I wonder if that is related **** ENDING LOGGING AT Thu Nov 19 02:59:59 2020