**** BEGIN LOGGING AT Mon Mar 09 02:59:57 2020 Mar 09 03:10:31 New news from stackoverflow: Added meta-oe recipe failed Mar 09 03:38:57 How to build nfs in yocto? Is there any command in yocto to build nfs? Basically, I don't want to create rootf.tar.gz everytime, instead I want to just update the unzipped root file system that I point to my nfs server. How can I do so? Mar 09 05:27:41 sj52: I don't think there's anything that automatically does this. But if you really want to do it with bitbake it shouldn't be too hard to add a simple image-type for this. See https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass?h=zeus Mar 09 05:37:09 erbo - Thanks, but I don't want to build the rootfs.tar.gz all the time. In fact, I want to just build an unextracted rootfs which gets updated everytime I run a build command. Basically, this unextracted rootfs is my nfs root. I want to point this rootfs there and don't want to change the rootfs source location. I will just reboot my device to get Mar 09 05:37:09 the updated contents from rootfs. Mar 09 05:37:37 Is there any way to do so? Mar 09 05:40:06 I guess yes, if you 1. add a new new type that handles the copying of IMAGE_ROOTFS to a location exposed by NFS. 2. Remove other image types (like tar.gz) from your IMAGE_FSTYPES. Mar 09 05:41:32 You mean uncompressed and not unextracted, right? Mar 09 05:54:20 Sorry, I mean uncompressed Mar 09 05:55:00 $ls -l /home/shreyas/rootfs_microzed/ Mar 09 05:55:01 root root 4096 Mar 9 15:50 etc Mar 09 05:55:04 root 4096 Mar 9 09:19 run Mar 09 07:41:23 New news from stackoverflow: Yocto: add musl library giving build error Mar 09 07:44:03 Anybody online who has experience with re-generating the python manifest? Mar 09 08:17:22 Hi, so I've successfully addressed the dozens of issues in my client's project which caused the builds to break when you enable sstate caching (mostly typical stuff, like naively linking into build directories of other recipes, or installing directly into the staging sysroot instead of the ${D} install directory) Mar 09 08:17:51 And now that I have builds that dont break, I'm faced with a new problem I'm not entirely sure how to debug Mar 09 08:18:34 That is: Some recipes are getting rebuilt from one clean build to another, even though the sources have not changed *at all* between builds and the same sstate cache is present Mar 09 08:19:05 Any tips on how to debug this brand of problem would be appreciated, what to watch out for etc Mar 09 08:20:06 For one thing: It would be nice to be able to track what inputs are going into the sstate cache keys, and ensure that cache keys are stable (unchanging between invocations of bitbake when the sources don't change) Mar 09 08:21:07 Any tips on what bitbake voodoo I might invoke to track what inputs are being considered in the calculation of an sstate cache key, and/or just "bitbake show-key recipe-name" to just simply view the key for a given recipe ? Mar 09 08:21:32 bitbake diffsigs maybe, or whatsitcalled? Mar 09 08:24:01 LetoThe2nd, that appears helpful thanks :) Mar 09 08:24:13 it's a program called bitbake-diffsigs here Mar 09 08:31:03 Ah that is quite helpful indeed, I'll have to double check this all, but it managed to explain to me precisely what changed (with a bit of digging) Mar 09 08:31:06 Hi, I've some questions about re-generating the python3 manifest. Mar 09 08:31:42 When I do in my project, what's on the Zeus release, the output without changing the input is a bit different. Mar 09 08:31:53 And my rootfs gives an error. Mar 09 08:32:46 The error seems to be related with the fact that python3-pkgutil is with the manifest before re-generating in an own package. Mar 09 08:32:50 * gtristan38 also discovers bitbake-whatchanged Mar 09 08:33:06 And after re-generating it is in python3-core. And python3-pkgutils seems to be empty. Mar 09 08:49:58 good morning Mar 09 08:52:07 mckoan: howdy! Mar 09 08:52:51 morning Mar 09 08:53:44 Morning guys Mar 09 09:05:03 hello, I've a strange issue. for some reason my sdk exports also a huge set of source files (.c/.cpp) Mar 09 09:05:34 hello Mar 09 09:05:36 small question - I'm trying to flash Renesas R-Car M3 board and when I'm going into SCIF Download mode it's locked on some weird memory address like here: https://www.paste.org/103450 Mar 09 09:05:42 any idea how to reset it? Mar 09 09:06:30 nopeman, what power supply do you use? I had the same issue on my H3 when my power supply didn't deliver enough amps Mar 09 09:08:48 axio met Ax-3010ds 0-30V 0-10A Mar 09 09:09:25 im giving it 5v and it's taking below 1A Mar 09 09:10:58 JPEW: I doubt you want to append to MACHINEOVERRIDES as the default value of MACHINEOVERRIDES is ${MACHINE} and I don't think it quite makes sense to have something more specific than the name of the machine. Mar 09 09:12:36 JPEW: MACHINEOVERRIDES is "read" from rightmost to leftmost. Though having ${MACHINE} as default value for MACHINEOVERRIDES means that you can only prepend to it. The trick is that you want to prepend before inheriting other files doing the same otherwise your order is messed up (we messed it up twice here already) Mar 09 09:14:30 JPEW: also, MACHINEOVERRIDES is only a part of the overall OVERRIDES mechanism, and I don't know if it's used alone somewhere. So I'd have a look at the content of OVERRIDES and see if you have something with higher priority than your newly added MACHINEOVERRIDES (e.g. DISTROOVERRIDES has higher priority than MACHINEOVERRIDES ;) ) Mar 09 09:39:19 Hi, i want to create a custom ubi layout with ubinize. Is there a way to do this with a special image? I inherit from core-image. Mar 09 09:42:02 Guest5287: if it involves seperate partitions, this sounds very much like something to look into with wic Mar 09 09:42:40 i use only one MTD partition and multiple ubi volumes Mar 09 09:42:56 Guest5287: yeah but what do the volumes represent? Mar 09 09:43:33 Guest5287: ubi in IMAGE_TYPEFS and declare MKUBIFS_ARGS and UBINIZE_ARGS in your machine configruation file? Mar 09 09:44:52 ubi and ubifs are already in my IMAGE_FSTYPES UBINIZE_ARGS is new to me... Mar 09 09:45:11 qschulz: another option, but i think it depends very much on the usecase, in the end. Mar 09 09:45:14 Oh no, i have all of them already declared... Mar 09 09:45:47 But this is only the layout of the flash? Mar 09 09:46:07 LetoThe2nd ubi is managing them ? Mar 09 09:46:18 Guest5287: ? Mar 09 09:46:35 LetoThe2nd or what did you mean with your question? Mar 09 09:47:56 Guest5287: no, i meant what the ubi volumes are meant to repesenr. parts of the userland? or just additional partitions that are initially empty? Mar 09 09:48:48 LetoThe2nd they represent userland, kernel and multiple DTBs. And that two times, beause of the update concept Mar 09 09:48:59 I just did a pull on poky master and rebuilt my image. I'm seeing lots of noise about unihash, is that now normal? Mar 09 09:49:27 paulbarker: how does the noise sound if you pipe it to your stereo? Mar 09 09:55:02 For example: `Task virtual:native:/home/pbarker/Projects/Yocto/poky/meta/recipes-support/popt/popt_1.16.bb:do_populate_sysroot unihash changed to c6b6a3568c70e1d9ad48d85001273b1d52f83785ec8113265186cb86ac6b66cb` Mar 09 09:56:07 Also `Already covered setscene for /home/pbarker/Projects/Yocto/poky/meta/recipes-core/images/core-image-base.bb:do_package so ignoring rehash (remap)` Mar 09 09:56:27 And `Reported task /home/pbarker/Projects/Yocto/poky/meta/recipes-core/images/core-image-base.bb:do_package as unihash 1af3abb29e5c8dec9ee74818bf4e8d3e3ce69e8313c331fa2e2613b3643a7d23 to u Mar 09 09:56:27 nix:///b/Yocto/poky/build/hashserve.sock ({'taskhash': 'd67ee50cce5a58d71e17e129455d27286f360a7c8e0be0faf6cb4af2dff8ecfb', 'method': 'oe.sstatesig.OEOuthashBasic', 'unihash': '1af3abb29e5c8 Mar 09 09:56:28 dec9ee74818bf4e8d3e3ce69e8313c331fa2e2613b3643a7d23'})` Mar 09 09:57:28 There's hundreds of lines of this output so it buries any other messages Mar 09 10:05:46 as shameless promotion of my python manifest issue: https://stackoverflow.com/questions/60589245/python3-pkgutil-added-to-python3-core-at-zeus Mar 09 10:17:25 guys: can somebody point me which WIC part (.py module) is responsible for writing grub core.img to disk image? Mar 09 10:20:53 warpme_: It'll be one of the source plugins, likely `bootimg-*.py` Mar 09 10:21:12 In `scripts/lib/wic/plugins/source/` Mar 09 10:24:33 for sure :-) but I scanned those files carefully multiple times and probably i'm blind as I can find it.... simply can't understand how wic is doing this stage in EFI bootable image preparation.... Mar 09 10:30:23 warpme_: What's your target MACHINE? Mar 09 10:38:07 Good day everyone, I have a question regarding good practice when extending an existing layer (meta-oe) with a third party recipe (https://github.com/gpanders/oe-scipy): Should I `cp` or `ln` the recipe's subdirectories content (`recipes-devtools`) into the meta-oe layer`s subdirectory `meta-python` because it's a python package (scipy) I'm Mar 09 10:38:08 actually targeting? That seemed odd to me. Thus I created a dedicated layer `meta-scipy` to only contains to recipe of that github link. But this also feels a bit add, to have a layer with only one recipe... Any hint on where to put that recipe? Mar 09 10:38:16 target is x86_64....but maybe some context: i'm using part of Yocto (mainly wic) in my project (https://github.com/warpme/minimyth2). So far with great success (bootable SD card images for allwinner/rockchip/amlogic/broadcom; x86 BIOS bootable live USB keys). Issue I have is adopting WID to produce EFI bootable images. So far missing part is instaltion of GRUB part on already prepared image (EFI & root partitions seems Mar 09 10:38:16 to be OK; just ESP nor core.img seem to be missing). Mar 09 10:39:43 emrius: if you feel like oe-scipy should be part of meta-python or meta-oe, please send a patch to make it part of the master version. If you want to work with old branches of the layers or can't update them, you need a separate layer. Do NOT touch anything that isn't maintained by you is the rule of thumb Mar 09 10:40:19 Ok, that agrees with my guts :) Mar 09 10:40:44 * LetoThe2nd agrees with qschulz and therefore transitionally with emrius' guts. Mar 09 10:41:58 warpme_: Ok. Which specific MACHINE are you using when you see the issue though? Mar 09 10:43:06 Ok, but for now, I would like to test that recipe. It contains patches for cmake and lapack. Is it best to throw it into it's own layer so that it is kinda isolated from everything else? Mar 09 10:43:45 emrius: bbappends for cmake and lapack and you're good Mar 09 10:44:33 in your own layer Mar 09 10:47:34 qschulz: Thanks! I'll try that right away Mar 09 10:47:53 But wait. Mar 09 10:48:22 I face a naming convention issue/question here. Mar 09 10:49:33 the repo is called oe-scipy. Is that a bad name in the first place? Should that rather be meta-scipy? Mar 09 10:49:55 This might seem pedantic but I just want to make sure I don't mess things up in the first place Mar 09 10:50:15 oe-scipy then contains recipes-devtools Mar 09 10:51:09 And I thought that it would be best to take the convention: `meta-mylayername/meta-mypackage/recipes-recipetype/content` Mar 09 10:52:14 `meta-mypackge` would then coincide with `oe-scipy`. Am I overthinking things? Mar 09 10:52:52 emrius: you are a bit wrong indeed. Mar 09 10:53:03 emrius: the repo should be named meta-something. Mar 09 10:53:35 emrius: and the structure roughly this: meta-something/recipes-something/something/something_x.y.z.bb Mar 09 10:53:51 thanks a lot for the clarification! That charms my guts yet again Mar 09 11:07:35 emrius: the layout you suggested is more for repos having multiple layers in them. I'd say it's rather rare to have such needs as YP users? Mar 09 11:13:11 paulbarker: I'm using WIC to create EFI bootable image for x86. For WIC log (and to see how far i'm with this) - pls see my msg in this IRC posted 6:33PM 8/03. There I put also .wks file i'm using to create image. Basically: wic ends without any error - but during inspecting created image I'm getting impression there is no ESP partition with grub core.img nor any log from wic about embedding grub core.img into Mar 09 11:13:12 MBR<->part_table gap in mage.... Mar 09 11:13:43 paulbarker: I'm using WIC to create EFI bootable image for x86. For WIC log (and to see how far i'm with this) - pls see my msg in this IRC posted 6:33PM 8/03. There I put also .wks file i'm using to create image. Basically: wic ends without any error - but during inspecting created image I'm getting impression there is no ESP partition with grub core.img nor any log from wic about embedding grub core.img into Mar 09 11:13:44 MBR<->part_table gap in image.... Mar 09 11:15:53 qschulz: ah ok, you mean large projects like e.g. meta-openembedded, right? Mar 09 11:16:44 Is there a good resource that wraps layouts and good practices up? Mar 09 11:19:56 emrius: #yocto on freenode :D Mar 09 11:20:36 ;D (y) Mar 09 11:21:06 emrius: the thing is, most of the time "it depends" (TM LetoThe2nd) Mar 09 11:22:17 hmm okay. Not very surprising but not very satisfying, either =( Mar 09 11:22:19 emrius: but layout in a layer is bound to BBFILES in conf/layer.conf. The layout (if matched to BBFILES) does not really matter. Mar 09 11:22:36 ok Mar 09 11:22:37 it's not really used AFAIK? Mar 09 12:20:22 Hi. I am trying to understand how to develop a program external to yocto which can run on my newly developed yocto build. Typically I would download the toolchain from arm e.g arm-none-eabi-g++ or similar. Can I build such a toolchain with yocto? I read some places, that its found in opt//sdk but I am not sure what that means exactly... Mar 09 12:25:09 mattis: https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Mar 09 12:25:24 mattis: i think #3 is on sdks and how to develop stuff :) Mar 09 12:25:57 mattis: the nutshell version: you can generate a sdk for a given image (which is the target to run on, then.) Mar 09 12:27:22 mattis: and that sdk traditionally installs to said /opt path. but if you don't have the image/app developer split, its way easier to just use the build directly (#10 or #11 on the videos, on app developemnt) Mar 09 12:29:28 LetoThe2nd: Thanks I am watching it right now. So I assume this is going to be explained. Mar 09 12:29:57 mattis: well certainly not *EVERYTHING* is being explained, but certainly enough to get started. Mar 09 12:33:08 Hey, I am trying to make an SDK based on my image that will be used for cross compiling. One of my recipes downloads some files from git and I want them to be included in the SDK. Currently the SDK has some of the header files from that recipe, but lack other headers and several source files that I need for cross compilation. I tried to search for Mar 09 12:33:08 a way to do this but nothing worked for now. Anyone know a way to do this? Mar 09 12:33:31 Ilya_S: depends (TM) Mar 09 12:34:43 Ilya_S: this can either be a badly packaged thing, something that doesn't have a proper DEPENDS on it, or something that is compile-time only. in the latter case you probably want to look at TOOLCHAIN_TASK_HOST (or pretty similar, i can't ever get the var name right) Mar 09 12:34:44 essentially I just want to know if there is a specific folder that I could copy these files and the SDK build will just grab them along Mar 09 12:35:19 tried TOOLCHAIN_TARGET_TASK_append Mar 09 12:35:23 no. it does not work like "just grab and copy". it works like "package properly and get your dependencies sorted out" Mar 09 12:35:25 TOOLCHAIN_TARGET_TASK_append = " osdk-staticdev" Mar 09 12:35:51 Ilya_S: then maybe that thing does not contain what you acutally want/need. look at the packages. Mar 09 12:36:17 plus, shouldn't it be TOOLCHAIN_HOST_TASK? Mar 09 12:36:36 i mean you want the things to run on the host? but i might be mistaken. Mar 09 12:36:54 I think these files are not part of the compilation. They are just there as sample code with helper functions, so they won't be in any depends Mar 09 12:37:17 Ilya_S: like i said then, fix the packaging. Mar 09 12:37:36 make a whatever-examples package out of them, or something similar. Mar 09 12:38:29 I'm not sure I understand what you mean by "packaging"? Mar 09 12:39:31 Ilya_S: a recipe does generate a number of packages. ${PN}, ${PN}-dev, ${PN}-dbg... so if you think the recipe should provide somthing, then it has to go into a pacakge. Mar 09 12:40:16 Ilya_S: one of the live coding sessions covers this, i think its called depends, redepends, packaging or something close. IIRC, #5 Mar 09 12:40:32 Ah, yeah, I tried to do that too. Are all these ${PN} included in the SDK? Mar 09 12:40:44 no. Mar 09 12:40:59 those which you either depend on or explicitly ask for are included. Mar 09 12:41:57 How can I ask them to be included? If it's covered in the coding session, I can try to check that out Mar 09 12:42:53 Ilya_S: again, included means "TOOLCJHAIN_HOST_TASK" Mar 09 12:43:41 Ah, I see, thanks. I'll try to figure it out Mar 09 12:52:04 I'm trying to have Yocto generate my ubi, but my needs are different than that of the ubi / ubifs image class. I attempted to make my own image class but can't seem to get bitbake to actually make the thing. Mar 09 12:53:16 I added IMAGE_CLASSES += " myimagetype " and the bbclass is included in the layer configuration. Mar 09 13:07:09 fullstop: aren't you more intestered in IMAGE_CMD_ instead? Add your own IMAGE_TYPES and define an IMAGE_CMD_mytype for it? Mar 09 13:07:22 (see image_types.bbclass) Mar 09 13:07:35 qschulz: that is in my bbclass Mar 09 13:09:38 fullstop: missing IMAGE_FSTYPES in your image recipe? Mar 09 13:10:26 perhaps, let me look once this build fails Mar 09 13:10:55 qschulz: where is the best place to put IMAGE_FSTYPES? local.conf? distro.conf? Mar 09 13:11:52 fullstop: I can see that's it's both in image recipes and in machine conf files... So... /me shrugs? Mar 09 13:12:24 fullstop: there are types specific to an image and other specific to a machine, your call Mar 09 13:12:31 I understand Mar 09 13:13:35 * fullstop moves this stuff to machine conf Mar 09 13:24:50 hey, it's doing something. Thanks, qschulz! Mar 09 13:26:27 fullstop: nice :) Mar 09 13:42:40 New news from stackoverflow: systemd: Freezing execution in Yocto Mar 09 14:09:14 okay feeling dumb Mar 09 14:09:29 (no smart jokes LetoThe2nd) Mar 09 14:10:04 so if i run a binary from a devshell from the native sysroot i get libgomp.so.1: cannot open shared object file: no such file or directory Mar 09 14:10:23 but if I ldd the binary inside the devshell, it resolves to /usr/lib64/libgomp.so.1 Mar 09 14:10:43 rburton: is it the multilib stuff hitting hard again? Mar 09 14:10:58 which ldd? Mar 09 14:11:01 :) Mar 09 14:11:19 struggling to understand how ldd says something different considering its just a wrapper around the loader Mar 09 14:11:31 rburton: does it pick the same loader? Mar 09 14:11:38 * RP doesn't trust ldd Mar 09 14:11:40 hm Mar 09 14:11:45 rburton: there was a couple of things related lately. wrong loader? Mar 09 14:11:54 RP was faster. Mar 09 14:12:02 ah Mar 09 14:12:03 /scratch/poky/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 Mar 09 14:15:52 right if i use the sysroot ld directly i get the error Mar 09 14:18:48 so for some reason the uninative ld.so isn't even attempting to look in the host paths Mar 09 14:19:44 Could somebody shine a bit of light into how the python manifest works? Mar 09 14:20:02 vermaete: what bit of it? Mar 09 14:20:41 I've *just* recreated it without modify anything in it. And it looks like the python3-pkgutil is not in the python3-core. Mar 09 14:20:47 What's probably not correct. Mar 09 14:20:53 I have this at Zeus and master. Mar 09 14:21:19 see: https://stackoverflow.com/questions/60589245/python3-pkgutil-added-to-python3-core-at-zeus Mar 09 14:21:50 Because of this, my rootfs is not building anymore. Mar 09 14:22:14 maybe that class doesn't get explicitly mentioned in the dependency trees, might need special casing Mar 09 14:22:22 This because the few recipes that are using python3-pkgutil are not able to include in the image. Mar 09 14:22:57 @rburton: fine, but every release this manifest if probably regenerated, not? Mar 09 14:23:24 Why is it different at my side when re-generating it? Mar 09 14:23:34 Because I'm using different layers? Mar 09 14:24:13 vermaete: only regenerated when needed Mar 09 14:24:34 and the generated onemight be fiddled by hand further Mar 09 14:24:55 okay, I've got this. Mar 09 14:25:27 so LD_DEBUG=all shows that it only looks in my sysroot and not on the host Mar 09 14:31:59 Not sure what is happening, bitbake core-image-minimal works, but bitbake core-image-minimal -c populate_sdk fails, should this not work for the same reason as the original? Mar 09 14:32:02 ERROR: Task (/home/mattis/development/cgm_yocto/build/build/poky/meta/recipes-devtools/gdb/gdb-cross-canadian_9.1.bb:do_compile) failed with exit code '1' Mar 09 14:32:56 mattis: gdb-cross-canadian is only needed for the SDK so that wouldn't cause the image build to fail Mar 09 14:33:22 Can you post the full bitbake output via a pastebin? Mar 09 14:36:38 rburton: I can't remember how we designed it to work :/ Mar 09 14:36:44 me neither! Mar 09 14:37:48 https://pastebin.com/7eG4kzM3 Mar 09 14:40:10 paulbarker: Yes but its the sdk I want to build and this is failing. Mar 09 14:45:45 mattis: That is a strange one. I'd recommend dropping meta-freescale temporarily and seeing if you can build gdb-cross-canadian on its own for a similar machine (maybe qemuarm). That should show whether the issue is in the Freescale BSP or in oe-core Mar 09 14:51:31 need to run the yocto check layer script against meta-freescale Mar 09 14:53:12 meta-freescale has some oddness around packaging wrt tuning Mar 09 14:54:49 paulbarker: ok. I had some issues earlier with some out of memory on hdd, since I am using docker, I will first do a clean install. Mar 09 14:54:57 Crofton|road: it has a significant number of bbappends in dynamic-layers on top of the ones in the layers, I'm pretty sure it violates the yocto layer reqs Mar 09 14:55:36 Crofton|road: it even has a dynamic bbappend for AGL that we have to BBMASK out, as it's wrong :/ Mar 09 14:56:29 damn, no wonder BSP's make people angry Mar 09 14:57:45 not sure it's in the YP guidelines, but any package 'tweaked' by a BSP has to be declared machine specific.. what a mess Mar 09 14:59:04 smurray: and others did I do something wrong? Mar 09 14:59:10 everything make me angry : ) Mar 09 14:59:31 mattis: no, you might just be stumbling upon someone else's brokenness Mar 09 15:01:26 mattis: I'd recommend trying what paulbarker suggested, try building the SDK without meta-freescale in the mix, to hopefully narrow down where the problem lies Mar 09 15:01:50 smurray: I will, just starting off fresh now. Mar 09 15:02:55 If you have a small moment. Mar 09 15:03:49 That manifest file, is this something that is input to generated some output. And that output is imported in git. Or is this parsed and used by bitbake itself. Mar 09 15:04:53 vermaete: Are you asking me? Mar 09 15:05:20 sorry, was for rburton. If he has time. Mar 09 15:35:27 vermaete: the manifest is used to build the package and dependency lists Mar 09 16:27:44 Which mailing list do I use for doc updates to bitbake? Mar 09 16:30:49 JPEW, bitbake-devel last time I checked Mar 09 16:31:45 with a suggested "bitbake-user-manual:" heading Mar 09 16:43:19 New news from stackoverflow: systemd: Freezing execution in Yocto [closed] Mar 09 17:56:40 hello ... I have a custom distro which installs many applications using IMAGE_INSTALL . Mar 09 17:58:21 When I run. "bitbake customdistro -c populate_sdk". I get error like this Mar 09 18:01:36 do_populate_sdk: Unable to install packages. Command /0-r0/recipe-sysroot-native/usr/bin/apt-get install --force-yes --allow-unauthenticated target-sdk-provides-dummy Mar 09 18:01:39 Reading package lists...Building dependency tree...Reading state information...Some packages could not be installed. This may mean that you haverequested an impossible situation or if you are using the unstabledistribution that some required packages have not yet been createdor been moved out of Incoming.The following information may help to Mar 09 18:01:40 resolve the situation:The following packages have unmet dependencies: target-sdk-provides-dummy : Conflicts: coreutilsE: Unable to correct problems, you have held broken packages. Mar 09 18:02:20 kiwi_29: Could you post the full bitbake output via a pastebin? Mar 09 18:07:59 Loading cache: 100% |#################################################################################################################################################################################| Time: 0:00:00Loaded 3357 entries from dependency cache.NOTE: Resolving any missing task queue dependenciesBuild Configuration:BB_VERSION = Mar 09 18:07:59 "1.44.0"BUILD_SYS = "x86_64-linux"NATIVELSBSTRING = "universal"TARGET_SYS = "x86_64-poky-linux"MACHINE = "genericx86-64"DISTRO = "customdistro"DISTRO_VERSION = "0.0.1"TUNE_FEATURES = "m64 core2"TARGET_FPU = ""meta meta-poky meta-yocto-bsp = Mar 09 18:08:00 "cpe-yocto3.0-poky:94f6b31befda5c496f65e863a6f8152b42d7ebf0"meta-customdistro = "wncagent:dc4822f9484d1ab8b66c7b25164f8ace4a40046b"meta-oe meta-python meta-networking = "zeus:e855ecc6d35677e79780adc57b2552213c995731"Initialising tasks: 100% Mar 09 18:08:00 |############################################################################################################################################################################| Time: 0:00:02Sstate summary: Wanted 184 Found 183 Missed 1 Current 949 (99% match, 99% complete)NOTE: Executing TasksNOTE: Setscene tasks completedERROR: Mar 09 18:08:01 customdistro-distro-1.0-r0 do_populate_sdk: Unable to install packages. Command '/home/kiwiuser/projects/targethardware/src/customdistrodistro/poky/build/tmp/work/genericx86_64-poky-linux/customdistro-distro/1.0-r0/recipe-sysroot-native/usr/bin/apt-get install --force-yes --allow-unauthenticated Mar 09 18:08:01 target-sdk-provides-dummy ' returned 100:Reading package lists...Building dependency tree...Reading state information...Some packages could not be installed. This may mean that you haverequested an impossible situation or if you are using the unstabledistribution that some required packages have not yet been createdor been Mar 09 18:08:02 moved out of Incoming.The following information may help to resolve the situation:The following packages have unmet dependencies: target-sdk-provides-dummy : Conflicts: coreutilsE: Unable to correct problems, you have held broken packages.ERROR: Logfile of failure stored in: Mar 09 18:08:02 /home/kiwiuser/projects/targethardware/src/customdistrodistro/poky/build/tmp/work/genericx86_64-poky-linux/customdistro-distro/1.0-r0/temp/log.do_populate_sdk.19581ERROR: Task (/home/kiwiuser/projects/targethardware/src/customdistrodistro/poky/meta-customdistro/recipes-core/images/customdistro-distro.bb:do_populate_sdk) failed with exit code Mar 09 18:08:03 '1'NOTE: Tasks Summary: Attempted 3941 tasks of which 3940 didn't need to be rerun and 1 failed.Summary: 1 task failed: /home/kiwiuser/projects/targethardware/src/customdistrodistro/poky/meta-customdistro/recipes-core/images/customdistro-distro.bb:do_populate_sdkSummary: There was 1 ERROR message shown, returning a non-zero exit code. Mar 09 18:08:42 I wish the indentation was good Mar 09 18:08:57 one of the packages in the list is coreutils Mar 09 18:09:21 when I do "bitbake core-image-minimal -c populate_sdk" does not throw any error Mar 09 18:10:39 kiwi_29: Use a pastebin please Mar 09 18:14:56 kiwi_29: Are you using deb packages? Mar 09 18:15:29 paulbarker. https://pastebin.com/KwTGU3jv Mar 09 18:15:47 kiwi_29: Are you using deb packages? Mar 09 18:16:21 paulbarker yes Mar 09 18:16:39 when I removed coreutils from list inside "IMAGE_INSTALL" Mar 09 18:16:51 kiwi_29: I'd recommend switching to ipk or rpm as they're much better tested and supported Mar 09 18:16:53 The bitbake command succeeds Mar 09 18:17:29 The bitbake command is "bitbake customdistro -c populate_sdk" Mar 09 18:18:19 kiwi_29: Ok. Can you try this with ipk or rpm packages and see if that works? Mar 09 18:18:28 With coreutils still included Mar 09 18:18:43 populate_sdk seems to injecting target-sdk-provides-dummy which conflicts with coreutils Mar 09 18:19:02 I have to use deb unfortunately for some time Mar 09 18:19:21 kiwi_29: At least try it without so you can narrow down where the issue is Mar 09 18:20:06 If the bug report is "works with ipk but not deb" we've got a much smaller area to search for the underlying problem Mar 09 18:20:43 true... also https://stackoverflow.com/questions/60058817/bitbake-populate-sdk-for-image-fails-with-error. it mentions to go away from deb Mar 09 18:29:37 btw paulbarker. ... I wanted to install all the development tools gcc, ldd etc on target system and my understanding is that "-c populate_sdk" accomplishes that ..please let me know if my understanding is correct Mar 09 18:29:56 I basically want to debug an application produced as part of yocto build. I want to debug on the target Mar 09 18:30:14 so I want gcc, gdb, ldd, readelf etc tools on target machine. Mar 09 18:30:24 is "-c populate_sdk" the right way of doing it Mar 09 18:31:43 kiwi_29: No, that creates an SDK for use on the host. If you want those on the target just add them to your image Mar 09 18:33:26 I see...so populate_sdk creates an sdk for cross-compilation environment where development/compilation and even debugging happens on host Mar 09 18:35:33 Is there a single recipe that provides all these devtools so that it compiles as part of target Mar 09 18:37:48 kiwi_29: Maybe a packagegroup but I can't recall the name Mar 09 18:40:08 https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb Mar 09 18:41:21 I have an image that is packages inside a `wic.zip`, but some windows client, when unzipping can't "see" the `wic` when using a tool to burn the image to an sdcard. I would like to intervene after the image creation but before the zip task. I would like to rename to .wic image to an .img so that the window tool can "see" the file, because the combobox has "*.img" Mar 09 18:44:34 I think what I'm trying to accomplish looks like : addtask makezip before do_build after do_image_complete. Inside the makezip task I would rename the file and execute the CONVERSION_CMD_zip. Mar 09 18:59:42 wget in ubuntu-20.04 doesn't like the ssl on eula-downloads.yoctoproject.org: Mar 09 18:59:44 Connecting to eula-downloads.yoctoproject.org (eula-downloads.yoctoproject.org)|140.211.169.56|:443... connected. Mar 09 18:59:47 OpenSSL: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol Mar 09 19:01:40 it's a Let'sEncrypt cert.. so maybe affected by the recent problems there? Mar 09 19:01:49 but even so, both Safari and Chrome load it fine fo rme Mar 09 19:03:16 Firefox also complains it's using weak crypto Mar 09 19:04:10 ECDHE_RSA_AES_256_CBC_SHA. Not exactly the most modern cipher suite, and not AEAD. Mar 09 19:17:03 I get "No such file or directory" when I run an application on yocto target Mar 09 19:17:26 the application is present on the path , has execute permission for user Mar 09 19:19:52 kiwi_29: /lib64/ld-linux-x86-64.so.2 --list $binary, I bet a library is missing. Mar 09 19:19:58 (adjust for your architecture, of course) Mar 09 19:22:27 this is the output Mar 09 19:24:19 https://pastebin.com/CEXpZyh7 Mar 09 19:24:25 neverpanic Mar 09 19:25:33 seems fine. Mar 09 19:27:30 kiwi_29: runs strace of the binary. maybe a config file, dlopen() or something else is failing. The file path from strace output will give hints. Mar 09 19:56:53 mcfrisk neverpanic this is a go binary ..just fyi Mar 09 19:58:26 kiwi_29: let me guess. you did not crosscompile this through bitbake? Mar 09 19:58:55 kiwi_29: its just another case of using the wrong loader. Mar 09 19:59:05 for reasons this is the new cool s**t. Mar 09 20:11:40 LetoThe2nd. the binary is generated as part of the Yocto build . Yocto generates the distro and also compiles this binary. Host is x86-64 (Xeon). and target is x86-64(celeron) Mar 09 20:13:37 kiwi_29: ah. well there was something really similar lately which ultimately boiled down to multilib. don't remember for sure if it was also host contamination involved, but thats the way to look. Mar 09 20:14:34 how do I get multilib support on target? Mar 09 20:14:37 LetoThe2nd Mar 09 20:15:03 btw ..output of strace https://pastebin.com/srkNJwwj Mar 09 20:15:18 mcfrisk neverpanic Mar 09 20:16:37 kiwi_29: i've poked the person who can share enlightenment. i'm personally not in touch with the topic, sorry. Mar 09 20:19:48 kiwi_29: what does 'file /usr/bin/yourapp' say? Mar 09 20:28:39 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=Z5k_gYnNQnexc0-pOqvx/l4ovWnRBgEF7GKYjAxmT/cU6SkJFIAj-Opt94rLKw/vXNKfIKTs_g7zuGJayny, not stripped Mar 09 20:28:43 kanavin_home Mar 09 20:29:34 kiwi_29: does /lib64/ld-linux-x86-64.so.2 exist? Mar 09 20:31:20 no... the output of dependecies is. https://pastebin.com/CEXpZyh7 Mar 09 20:34:01 kiwi_29: what language is the app written in? Mar 09 20:34:08 go Mar 09 20:34:10 (e.g. what was used to compile it) Mar 09 20:34:48 kiwi_29: it seems golang compiler is not aware of ldso path Mar 09 20:35:55 kiwi_29: it seems a bug to me in OE, we should be aligning the ldso paths across compilers be it c/c++ or rust or golang Mar 09 20:35:58 I see..however it is found as we see https://pastebin.com/CEXpZyh7. no ? Mar 09 20:36:22 is that a cmd you ran manually ? Mar 09 20:36:41 kiwi_29: the interpreter is the one you see in the 'file' output, and if it's not there, exec() will immediately fail with a file not found error Mar 09 20:36:52 what libs is the binary linked with is irrelevant then Mar 09 20:37:07 can you show the recipe? Mar 09 20:37:30 its not recipe problem, Mar 09 20:38:40 usually this happens when ppl transfer something they compiled in ubuntu, and expect it to 'work' Mar 09 20:38:49 kiwi_29: on your build host, go to builddir of the app and find the binary and run readelf -e on it and it should show you what interpreter is encoded into the binary, if that exact path is missing on target then we know the proble Mar 09 20:39:20 khem: see above - file says 'ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=Z5k_gYnNQnexc0-pOqvx/l4ovWnRBgEF7GKYjAxmT/cU6SkJFIAj-Opt94rLKw/vXNKfIKTs_g7zuGJayny, not stripped' Mar 09 20:41:18 here is recipe khem kanavin_home. https://pastebin.com/jPhntUFk Mar 09 20:43:10 kiwi_29: right so does /lib64/ld-linux-x86-64.so.2 exist on target ? Mar 09 20:43:18 khem. no Mar 09 20:43:27 how do I get it? Mar 09 20:43:27 right so thats the problem Mar 09 20:43:50 we have to teach the go compiler to use right paths that match OEs norms Mar 09 20:43:56 my custom distro is based on core-image-minimal Mar 09 20:44:02 should I base it on core-image-multilib Mar 09 20:44:09 thats ok, you are doing all well Mar 09 20:44:09 kiwi_29: I think your recipe might be using the host go compiler Mar 09 20:44:25 this 'go this' 'go that' stuff looks wrong Mar 09 20:44:44 I have used inherit go in beginning of recipe Mar 09 20:44:53 without that go command does not work Mar 09 20:45:32 yeah, but the correct form is ${GO} , not go Mar 09 20:45:42 I see Mar 09 20:45:56 and the inherit go should set up the compilation already, no need to overwrite it Mar 09 20:46:15 yeah you should defer as much work as possible to templates provides in go.bbclass Mar 09 20:46:28 so cross compiling can work as expected Mar 09 20:47:05 so what should go inside do_compile ? Mar 09 20:47:42 ${GO} build ABCagent.go Mar 09 20:48:20 trying it out right now...will update you in a moment Mar 09 20:48:21 kiwi_29: nothing Mar 09 20:50:02 kiwi_29: Infact your recipe could be cleaned up please look at recipes-extended/go-examples/go-helloworld_0.1.bb Mar 09 20:50:03 kanavin_home I see your point... how do I make sure I m compiline MYAPP.go. which variable I use in beginning of recipe to specify that it is the Mar 09 20:50:06 target Mar 09 20:50:40 e.g. you can define GO_IMPORT and GO_INSTALL Mar 09 20:50:53 and thats pretty much you would need besides boiler plate code Mar 09 20:52:16 * RP finally finds the locale relocation bug in glibc Mar 09 21:02:10 RP: memory check for you, it's about commit from 2011/2009 :) do you know why we have 2 different CACHE settings in default setup? Mar 09 21:02:13 meta/conf/bitbake.conf:CACHE = "${TMPDIR}/cache${@['', '/' + str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d, 1))]}${@['', '/' + str(bb.data.getVar('SDKMACHINE', d, 1))][bool(bb.data.getVar('SDKMACHINE', d, 1))]}" Mar 09 21:02:17 meta/conf/distro/defaultsetup.conf:CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d, 1))]}${@['', '/' + str(bb.data.getVar('SDKMACHINE', d, 1))][bool(bb.data.getVar('SDKMACHINE', d, 1))]}" Mar 09 21:03:12 2nd was introduced in 2011 with http://git.openembedded.org/openembedded-core/commit/?id=c0a148077ae27a1ef57c55ac22953c68d001af57 Mar 09 21:03:29 any objection to update the 1st one and drop 2nd? Mar 09 21:04:44 2009 was last "functional" change in the 1st one (other than getVar API change updates later twice) http://git.openembedded.org/openembedded-core/commit/?id=1d4f93e8f63395220da652bae055acde11544577 Mar 09 21:04:53 JaMa: presumably its because TCMODE and TCLIBC are nodistro specific Mar 09 21:05:13 JaMa: we've had wider adoption of that convention since Mar 09 21:05:55 JaMa: if someone had a summy nodistro conf file, it would break with TCMODE/TCLIBC not in bitbake.conf Mar 09 21:06:03 JaMa: no object to simplifying this though Mar 09 21:06:19 s/summy/dummy/ Mar 09 21:06:40 ok, will do that in 3.2 Mar 09 21:07:24 TCLIBC is used in quite a few places now, TCMODE only in meta/conf/local.conf.sample.extended + defaultsetup.conf Mar 09 21:07:43 JaMa: right, TCLIBC is pretty much required now Mar 09 21:12:30 tgamblin: you've seen my coreutils hack in master-next right? Mar 09 21:12:43 khem kanavin_home. ..thanks .. I m working on it and will update Mar 09 21:13:19 will ping back with results Mar 09 21:56:28 JaMa: its tempting to consider removing nodistro entirely and mandate setting MACHINE/SDKMACHINE, simplify the code Mar 09 21:56:45 I think reasons for now setting those are now historical Mar 09 21:57:31 JPEW: with the new logging, does it capture hashequiv to the on disk logs by default? Mar 09 22:00:53 RP: agreed, e.g. meta-updater settings also expects MACHINE to be set and causes more ugly parsing error when it isn't, having more simple base and error early enough when not set would be nicer Mar 09 22:04:22 RP: I see it now Mar 09 22:07:37 kiwi_29 could try /lib/ld-linux-x86-64.so.2 /usr/bin/APPNAME, but I guess at this point it's pretty much established that the loader path is the problem. Mar 09 22:08:16 tgamblin: it gets us part way towards merging Mar 09 22:08:35 tgamblin: gcc-plugin reproducibility issue remains Mar 09 22:13:49 hmm ok Mar 09 22:15:55 I've got a recipe, "A", that wants files to be owned by a user account created by recipe "B". B works, the account appears in its sysroot and the image. "A" DEPENDS on B, but the sysroot for A doesn't have the accounts. It does have other files provided by B. Mar 09 22:17:52 tgamblin: just be glad it resolves the multilib one ;-) Mar 09 22:19:59 I see there was a bug related to this, but it looks like it was fixed long ago. I'm on zeus. https://www.yoctoproject.org/pipermail/yocto/2017-October/038395.html Mar 09 22:20:12 RP: Whatever works I suppose. The nuclear option would've been to just remove that assert test Mar 09 22:21:06 tgamblin: is there just one test using that module? Mar 09 22:21:21 tgamblin: that would solve the problems and let us merge if it were disabled Mar 09 22:22:03 RP: it's a single test that's failing on qemux86, from what I can tell (and from what Alex was saying) Mar 09 22:22:29 I did a few test runs earlier today but got sidetracked from actually writing a patch to nuke that particular test case Mar 09 22:22:42 tgamblin: oh, there is that and the second issue of gcc being added to the build chain and gcc-plugin not being reproducible Mar 09 22:23:00 Ah. Hmm, let me have a look Mar 09 22:23:03 gcc comes from the libperl-module-build dependency Mar 09 22:23:35 tgamblin: there was a third problem of gcc multilib conflicts but I fixed that Mar 09 22:24:29 RP: Ah, right, if I remember correctly, removing libmodule-build-perl causes 9ish test cases to fail Mar 09 22:25:12 * tgamblin starts a build to confirm the number Mar 09 22:25:17 tgamblin: right and they'd not fail deterministicly either as it would depend on image contents Mar 09 22:25:47 tgamblin: libperl-module-build has ptests so is installed in ptest images so wouldn't get "seen" by our autobuilder Mar 09 22:26:04 tgamblin: RP: the test fails on both arm and x86 - ['tests/tail-2/assert.sh'] Mar 09 22:26:33 it has to be core-image-sato-sdk-ptest though if you want to reproduce Mar 09 22:31:34 kanavin_home: it fails on our autobuilder too Mar 09 22:31:45 at least its consistent Mar 09 22:32:16 My bad, I'm adding a lot of extra work for the release :/ Mar 09 22:33:31 tgamblin: its not the only thing holding things up Mar 09 22:37:21 xyzzy42: Ah, yes, the dreaded user management thing. The relevant code is around here: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/useradd.bbclass#n99 Mar 09 22:39:20 I suggest you always choose statically configured uids and gids when re-using users across recipes, because otherwise you may get different uids and gids depending on when tasks are re-run, and you may get different uids when creating packages and at install time on target Mar 09 22:39:30 RP: kanavin_home: make that 63 tests failing without libmodule-build-perl - I had that number mixed up with my older total for when I was mulling over adding/not adding valgrind + strace Mar 09 22:40:28 tgamblin: ok, so we do need it, thanks Mar 09 22:41:01 at $work, we've avoided dependencies between recipes for users to prevent triggering rebuilds of everything when we were adding or changing users, and instead just had an include file that contained the statically assigned UID/GID of those users, and had a single recipe that would create them all. Mar 09 22:41:23 Every other recipe just includes the list of UIDs/GIDs and chowns files to the UIDs directly, without having the users in sysroot. Mar 09 22:43:21 Looks like do_populate_sysroot is what's supposed to be adding them. From the log, it looks like it gets skipped. "NOTE: Installed into sysroot: []" then "NOTE: Skipping as already exists in sysroot: ['package-with-users', ...]" Mar 09 22:44:11 well, you'll have to clean to see the code that should add the user run. Mar 09 22:44:27 yep, cleansstate before I did that Mar 09 22:45:15 I would assume it's the recipe-specific sysroot task for recipe A that would add the user, though. Mar 09 22:45:47 yes, I see the dependency of do_preapre_recipe_sysroot has package_with_users:do_populate_sysroot in it Mar 09 22:46:27 but as I said, writing a recipe-B.inc file that contains user_B_UID = "1234" user_B_GID = "3456", including it from both recipes and doing chown ${user_B_UID}:${user_B_GID} in recipe A may be the simpler solution, and in our experience, has fewer problems. Mar 09 22:50:01 Also pacakge_using_user:do_prepare_recipe_sysroot does depend on package_with_users:do_populate_sysroot, but package_with_users:do_populate_sysroot would create the user in the separate sysroot staging area for package_with_users, but not in the recipe-specific sysroot for package_using_user Mar 09 22:50:49 the do_populate_sysroot can't do that, as the recipe specific sysroot doesn't exist yet, and the /etc/passwd file in package_with_users's sysroot can't simply be copied either (and usually isn't, as only specific subfolders are staged into the sysroot) Mar 09 22:51:10 So there needs to be some additional logic running in package_using_user's do_prepare_recipe_sysroot to get this right. Mar 09 22:52:54 I thought that extra logic was the purpose of this, https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/useradd.bbclass#n154 Mar 09 22:54:41 Seems so. Maybe you're running into the filter in line 122? Mar 09 22:55:13 hmm, exit 0, odd choice of exit code, maybe that's it Mar 09 22:56:00 another thing I thought of, is that I do reference the group systemd-journal in a package, which is created by a systemd recipe, and that does work Mar 09 22:56:46 seems meta/recipes-core/base-passwd/base-passwd_3.5.29.bb takes care of running the postinst scripts. Mar 09 22:56:52 the group is created by the systemd recipe, the recipe that uses the systemd-journal group doesn't create, but does DEPENDS on it, and that worked Mar 09 23:00:13 Hm, or meta/classes/staging.bbclass:583 in extend_recipe_sysroot called by do_prepare_recipe_sysroot. Mar 09 23:02:25 I see recipe-sysroot/usr/bin/postinst-useradd-{systemd,my-package-withuser} both exists. But the users/groups created by the former are present in sysroot/etc/passwd, while the latter are not. Mar 09 23:36:02 I'm having problem with "git pack-redundant" it's called by git fetcher under some conditions, it gives me always sigfaults Mar 09 23:36:21 it's using git on your host.. Mar 09 23:37:03 yes, I just want to ask if someone having same problem, I'm having this with 2.15.1 Mar 09 23:43:29 ups I mean 2.25.1, I also have this with 2.14.1 and 2.13.1. Not sure it's my custom host configuration, I ruleout memory corruption and disk corruption Mar 09 23:48:49 ok, not my day, affected version 2.25.1, 2.24.1 and 2.23.1. Probably my distribution fault somehow, this sigfault not crashing bitbake I just found that Yocto builds giving me sigfauls in dmesg from time to time Mar 09 23:59:46 RP: No. the AB needs to set BB_LOGCONFIG... Which maybe should be in the env whitelist Mar 10 00:05:43 JPEW, it looks like he added that to the AB Mar 10 00:32:17 armpit: excellent. thanks **** ENDING LOGGING AT Tue Mar 10 02:59:57 2020