**** BEGIN LOGGING AT Tue Feb 09 03:00:29 2021 Feb 09 05:54:16 How to fix the problem ? Thanks. ERROR: sg-1.0-r0 do_package_qa: QA Issue: sg: The compile log indicates that host include and/or library paths were used. Feb 09 08:22:15 yo dudX Feb 09 08:47:23 reading native.bbclass. Can't understand this: bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}". What is it? Feb 09 08:59:29 dorinda: mmmm... this ssh-server-dropbear thingy should just work. Maybe you want to give us the exact version of poky you're using (commit hash), all layers and their commit hash too, if any of the git repos are dirty and if so, what are your modifications/additions? What's the content in local.conf you modified/added, etc... Feb 09 08:59:38 dorinda: but glad you got unstuck :) Feb 09 09:17:28 I need non-standard path binaries to be in my -native recipe. Instead of ${D}/${bindir} I need it at ${D}//somedir. How can I do that? Feb 09 09:19:42 qschulz: hmmm, you were right i added this `DEBUGINFOD_URLS = "http://localhost:8002/"` in local.conf, so when i removed it the `ssh-server-dropbear` worked, then i added the `DEBUGINFOD_URLS = "http://localhost:8002/"` afterwards and it still built successfully without error. i wonder why that is :/ Feb 09 09:21:01 dorinda: if you still have the error log, we might guess but since you aren't able to reproduce it now AFAIU, then... it'll be hard to fix it without knowing the exact state in which Yocto was when building your image Feb 09 09:22:08 ok here's the error log Feb 09 09:23:43 https://www.irccloud.com/pastebin/enML6yPy/errorlog.txt Feb 09 09:24:42 Allright, making progress, sort of Feb 09 09:25:35 So, I have this working recipe (some stuff redacted due to company policies), but I feel this is a very roundabout way to go about stuff Feb 09 09:25:59 https://pastebin.com/D2eiUS6r Feb 09 09:26:33 dvorkindmitry: just install in those paths? Feb 09 09:26:55 What I want to do: make sure the kernel tool bpf is crosscompiled for arm64 in the SDK Feb 09 09:27:18 The method I'm using now works, but feels very hack-ish, is there a better way? Feb 09 09:27:36 dorinda: corrupted sstate-cache? Feb 09 09:30:23 qschulz, but ${D} does not contain the complete path while installing into sysroot-destdir/... There are only several dirs defined in native.bbclass (bindir,datadir...) but not the root dir of the sysroot-destdir/+prefix. I am trying to udertand how can I concatenate ${D} + prefix correctly for the native recipe Feb 09 09:34:40 dvorkindmitry: SYSROOT_DIRS_NATIVE Feb 09 09:35:31 but then your path won't be part of PATH in recipes DEPENDS'ing on it Feb 09 09:36:03 wertigon: Hey, you helped me yesterday. End of story was: I had to enable file system locks in the kernel... They were disabled Feb 09 09:36:36 qschulz, I add SYSROOT_DIRS_NATIVE += "${base_prefix}/sp_tools" into my native recipe without effect Feb 09 09:40:07 dvorkindmitry: define "without effect" Feb 09 09:40:21 do you have your binary in the other recipe's recipe-sysroot-native? Feb 09 09:44:47 GeneralStupid: Thanks for letting me know, might come in handy sometime :) Feb 09 09:45:14 GeneralStupid: And sorry I couldn't be of more help, but yeah. The solution was painfully obvious as I suspected :D Feb 09 09:45:53 wertigon: no problem. I just hope the next guy who have this issue finds that solution. I was really happy about everyone that helped me Feb 09 09:50:43 rburton: around? do you remember more details about icu race failures you reported upstream? or can you check top 2 commits in https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/dunfell Feb 09 10:00:54 qschulz: i guess Feb 09 10:07:05 qschulz, I install it into ${D}${bindir} too and have it at this path. But I need ${D}${base_prefix}/sp_tools too Feb 09 10:10:36 dvorkindmitry: check the value of SYSROOT_DIRS_NATIVE and SYSROOT_DIRS with bitbake -e | grep -e "^SYSROOT_DIRS". Is it of the value you expect? Feb 09 10:32:23 JaMa: looks good Feb 09 11:12:05 morning all, just asking if anyone has heard about glslangkernel-modules as nothing seems to proovide that, the error appeared after adding the line "CORE_IMAGE_EXTRA_INSTALL_append = "kernel-modules" to the local.conf I need kernel modules as I need the Radeon driver for the Ryzen am working with Feb 09 11:14:11 intera91: sounds like you might want to break that doen a bit more. Feb 09 11:18:09 paulbarker: did you see the cargo patches on the bitbake list? Feb 09 11:18:39 morning all, just asking if anyone has heard about glslangkernel-modules as nothing seems to proovide that, the error appeared after adding the line "CORE_IMAGE_EXTRA_INSTALL_append = "kernel-modules" to the local.conf I need kernel modules as I need the Radeon driver for the Ryzen am working with Feb 09 11:18:39 sorry got disconnected Feb 09 11:18:39 paulbarker: also, do we have a plan in mind for the hashequiv debug issue? Feb 09 11:19:27 intera91: https://www.yoctoproject.org/irc/%23yocto.2021-02-09.log.html Feb 09 11:21:37 qschulz: thanks for the link;-)  any idea? Feb 09 11:22:51 intera91: 12:14:11 LetoThe2nd | intera91: sounds like you might want to break that doen a bit more. Feb 09 11:26:10 ok, sure well the platform for yocto is a Ryzen with integrated GPU (Radeon Vega Series) the software we are ading is using vulkan and other stuff. now in order for Vulkan to work it has to detect the GPU and in order for that to happen we need the proper driver which is a kernel module, I already have the open source xf86-video-ati driver Feb 09 11:26:10 installed into my Yocto image. The problem is that the kernel module radeon.ko, and all of its dependencies under the GPU and I2C folders seems to be missing from the kernel. Without these .ko files, Yocto cannot recognize the external graphics card, and udev cannot generate an appropriate device node (/dev/dri/card0) for Xorg to use. Feb 09 11:26:23 I've already tried adding the following line to my local.conf: Feb 09 11:26:24 CORE_IMAGE_EXTRA_INSTALL_append = "kernel-modules" Feb 09 11:27:30 and that is where I get this error Nothing RPROVIDES 'glslangkernel-modules' (but /home/user/workspace/poky/build/toaster-custom-images/recipes/mysoftware.bb RDEPENDS on or otherwise requires it) Feb 09 11:27:49 qschulz, yes, I have the directory I want at SYSROOT_DIRS*. But I needto know how can I install to this location at do_install() step? Feb 09 11:27:50 and indeed our software requires gslang and gslang-native in its bb Feb 09 11:27:53 Is anyone else seeing kernels fail to build with odd linkage problems since this weekend in master? Feb 09 11:29:44 dvorkindmitry: just install in the path you've given SYSROOT_DIRS but prepend it with ${D} Feb 09 11:32:26 intera91: sounds somewhat fishy in the dependency process, als "glslangkernel-modules" also doesn't match the canonical name, which should be "glslang-kernel-module" or something similar, check the package feed directories for examples. Feb 09 11:32:53 intera91: so my advice would be to start digging where this RDEPENDS actually comes from Feb 09 11:33:47 qschulz, how can I correctly set the prefix to install? I am trying like this: install -p -m0755 ${S}/tools/add_uhdr.sh ${D}/sp_tools/. what prefix should I correctly use at destination? Feb 09 11:40:25 dvorkindmitry: ${D}${base_prefix}/sp_tools should work just fine since it's what you added in SYSROOT_DIRS_NATIVE but probably yours is correct too Feb 09 11:40:44 dvorkindmitry: there might be an issue with /sp_tools dir being at the root of the "filesystem" Feb 09 11:40:57 I know there were some things to do first Feb 09 11:41:14 (you need install -d ${D}/sp_tools/ before that one line btw) Feb 09 11:41:30 but can't remember which things Feb 09 13:07:53 Hi all, where should I look for remote support tools that would run on Yocto? (Enterprise/corp. contracting, somewhat strict filtering rules, used in an industrial plant) Feb 09 13:09:24 I'm currently doing a quick market analysis, seen things like BeyondTrust, which look promising. Do you have some other specific recommendations? (other than, you know, simple SSH because corps will be corps and SSH is too simple) Feb 09 13:51:49 in multiconfig how can I correctly set IMAGE_BOOT_FILES += "a926.img" for WIC if a926.img generated by another arch? a926.img is placed into another deploy/ dir and not found by the current WIC tool Feb 09 13:52:54 may I have the recipe that have an access to two deploy/ dirs (two archs) ? Feb 09 13:53:48 wshat causes this error message: ("Nothing RPROVIDES 'glslangkernel-modules'") is when the line CORE_IMAGE_EXTRA_INSTALL_append = "kernel-modules" is added to the local.conf file Feb 09 13:54:12 dvorkindmitry: It's a little tricky, but you can access the DEPLOY_DIR from another recipe Feb 09 13:54:14 qschulz: sorry forgot to tag you on previous message Feb 09 13:54:18 s/recipe/multiconfig Feb 09 13:54:29 intera91: you need a space before kernel-modules, _append does not add one Feb 09 13:55:38 *** hitting oneself on the head with a big ugly stick *** Feb 09 13:56:49 dvorkindmitry: The trick is to set DEPLOY_DIR to a known value in each multiconfig so that you know how to reference it from another one; then write a recipe that stages a deliverable from one deploy dir to another Feb 09 13:57:41 dvorkindmitry: We wrote a class to help with that: https://github.com/garmin/whisk/blob/master/meta-whisk/classes/deploy-alias.bbclass Feb 09 14:11:55 ooh Feb 09 14:20:58 JPEW, interesting. may I use it with dunfell or gatesgarth ? Feb 09 14:30:05 dvorkindmitry: Ya, I think it works with either Feb 09 14:31:05 JPEW, is there any simple example using it in the recipe? Feb 09 14:32:56 I don't have any public ones, sorry. It's just 2 lines: 'inherit deploy-alias' 'DEPLOY_ALIASES = "..."' Feb 09 14:33:56 The trick is that you have to know the path to the deliverable you want to copy, which is where the known paths comes in Feb 09 14:35:48 dvorkindmitry: The tool we wrote to manage our products (https://github.com/garmin/whisk) does this for us Feb 09 14:37:06 JPEW, yea. I see. just going to add this class into my layer and try to use in some MC recipe. just curious how to do it correctly Feb 09 14:38:04 JPEW: wondering what to do with the hashserve patches and this debug issue :/ Feb 09 14:38:36 RP: Ya, I was going to try and work up a patch series to rename debug( -> debug2( & debug3( Feb 09 14:38:48 IIRC, it only affect bitbake proper Feb 09 14:39:28 JPEW: I hope so... Feb 09 14:40:07 Right because we only have to change it where tools are using the Python logging facilities. Places using `bb.debug(` don't have to change Feb 09 14:40:51 JPEW: we're not so lucky: meta/lib/oe/terminal.py: logger.debug(1, 'No custom terminal (OE_TERMINAL_CUSTOMCMD) set') Feb 09 14:40:52 So, it's not as much as it first seems Feb 09 14:41:04 JPEW: not many references in oe but there are some by the looks of i Feb 09 14:41:14 Hmm, I missed that one Feb 09 14:41:51 JPEW: looks like only two in that file and a couple of commented ones Feb 09 14:55:11 Hi, I'm trying to setup multiconfig, does "bitbake mc::target" make target for all machines, or just one? Feb 09 15:02:07 Sponge5: I don't think so Feb 09 15:02:22 Sponge5: Sorry, I don't think that will build it for all targets Feb 09 15:03:35 JPEW: Already tried and seems like you're right Feb 09 15:13:55 Is there a way to do that? Feb 09 15:23:19 Tried bitbake mc:*:target and it seems to be working. got bunch of "Deferring" messages, but I guess that happens if you run bitbake mc for just one machine before that Feb 09 15:24:14 Because bitbake mc should compile common binaries once, so it makes sense it would reuse what it already had Feb 09 15:24:40 Sponge5: I don't think there is a way to make it compile the same target for all multiconfigs at once Feb 09 15:25:38 I'll tell you tomorrow morning if it built successfuly :) Feb 09 15:25:42 Sponge5: We've worked around that with a few classes: https://github.com/garmin/whisk/tree/master/meta-whisk/classes Feb 09 15:26:50 With those classes you can write a recipe that depends on all the targets you want to build across multiple multiconfigs. Our tool (whisk) does this with the all-targets recipe: https://github.com/garmin/whisk/blob/master/meta-whisk/recipes-core/targets/all-targets.bb Feb 09 15:27:27 Thus, when we run `bitbake all-targets` it builds all the desired targets for all configured products (each product is it's own multiconfig) Feb 09 15:27:49 Err, builds all the *default* targets Feb 09 15:29:53 huh, so you get around the issue of use of multiconfig with multiple conflicting layers/releases with bbmask? Feb 09 15:30:00 whisk seems interesting, might have to play with that Feb 09 15:30:40 kergoth: Ya. Just be aware that you may need to backport support... I don't think that landed until gatesgarth(?) Feb 09 15:30:40 JPEW: bitbake mc:*:target-image is building so far, it did show all the machines that it should. I will know tomorrow for sure Feb 09 15:30:50 Sponge5: Ok Feb 09 15:31:22 ah, good to know. do you run into problems with non-machine changes between multiconfigs? I've had issues changing distro configuration across multiconfigs, for example Feb 09 15:32:06 kergoth: No, but whisk automatically gives each mc (product) it's own build and deploy directories Feb 09 15:32:23 kergoth: Which probably prevents a lot of those problems Feb 09 15:32:37 ah, so isolating the build area per-product you avoid issues with tmpdir getting mucked up by rebuilding things with differing configs Feb 09 15:32:38 makes sense Feb 09 15:32:54 kergoth: Right. If they can share something, they do it through sstate anyway Feb 09 15:33:28 It does mean your build directory can get pretty big if you build a lot of products at once :) Feb 09 15:33:30 yeah, makes a lot of sense, thanks. i'll have to try whisk, seems promising for kicking off multiple builds with differing setups Feb 09 15:34:44 Ya. There's also not a 1-1 correspondance between products and multiconfigs. It's designed so that if you have a multiconfig for a second coproc you can include it in a product along with the product's multiconfig Feb 09 15:36:20 We do something similar (starting with gatesgarth), and using rm_work, the build directory really doesn't get all that big (compared to running individual builds before). Feb 09 15:36:39 Overall the build looks more efficient, but I'm not sure that it's actually any faster then running one build after another (re-using the sstate-cache) Feb 09 15:37:14 We did observe a problem where there was some sort of deadlock in the task deferral mechansism. The code thats in there to break the deadlock worked, but ends up running tasks serially after that point. Feb 09 15:37:30 (I've had no time to go back to figure out if there is an easy way to reproduce the problem and/or diagnose what might be there to fix it.) Feb 09 15:37:41 fray: Ya, we don't do it for build efficiency per-say, we do it for release management (automatically release *all* these products from a CI build) Feb 09 15:38:01 The symptom of the deadlock is basically everything gets to a point it's deferred, and then you get messages that nothing is in the task runqueue, so it will just pull the next task and run it Feb 09 15:38:20 fray: Huh, I haven't really noticed that Feb 09 15:38:54 we're trying to do it for both reasons. we have groups of machines that are tightly related. As-in 90% of what they build is the same. So it makes sense to group those in multiconfigs and then do a single build. Feb 09 15:39:18 the deadlock may very well be related to the environment, including one of our layers/recipes, etc. Like I said, we've not tracked it down yet. Feb 09 15:39:39 The configuration was in excess of 150k tasks, across 8 machines Feb 09 15:40:51 (normal serial build for us takes about 12-14 hours for that config. The multiconfig build took about 15+ minutes to parse, but then was really efficient [until the deadlock]... I'm guessing, if we had not hit that problem, we'd have finished in about 10-12 hours.. so anywhere from 2 to roughly even (best case) Feb 09 15:41:13 but I stopped it, and restarted it at 14 hours, no further dead lock and it finished in minutes Feb 09 15:43:57 (parse was cached, and it turned out everything it needed was already in the sstate-cache as well) Feb 09 15:51:12 RP: Sent patches Feb 09 15:54:57 JPEW: thanks. I'd better try and sort bitbake version bumps with that too Feb 09 15:56:17 RP: Ya Feb 09 16:19:24 Hi all. I see a couple of reports (in irc logs) about image generation (mkfs) failing on ZFS. Did anyone figured it out? Feb 09 16:42:00 https://gitlab.com/fedora-iot/meta-rpm/-/tree/master Feb 09 16:42:37 ^^^ for those on the YP call -- meta-rpm is a yocto layer that replaces the "poky" base distribution by one based on pre-built rpms from an existing rpm-based distribution. Currently only Centos is supported, but the plan is to allow others too, like Fedora. Feb 09 17:16:19 JPEW, https://www.yoctoproject.org/reproduce/ is a start. I'll get it integrated into the site now. Feb 09 17:50:24 halstead: Great! Thanks! Feb 09 17:50:53 JPEW, Getting close https://www.yoctoproject.org/reproducible-build-results/ Feb 09 17:52:56 halstead: Did you have to do anything with the cross-site scripting filter, or does it just work because it's hosted on yoctoproject.org? Feb 09 17:54:49 JPEW, I added a header to Apache on git.yoctoproject.org. I could add one to enable your site as well if you'd like. Feb 09 17:55:33 halstead: Not necessary. I have the browser extension that allows me to fake it for testing, and I don't really want my site to be "cannoical" Feb 09 17:57:17 JPEW, Does https://www.yoctoproject.org/reproducible-build-results/ look ready? Is there anything else needed? Feb 09 17:58:07 halstead: It would be nice if the tables had a little left and right padding in the cells to make it easier to read, but otherwise it looks good Feb 09 18:00:39 hi, what is the proper way to overwrite a file (/etc/xdg/weston/weston.ini) ? I am considering to add a link and override weston packaging , or is there anything like debian's alternatives ? Feb 09 18:02:37 RzR: we have alternatives, yes. you can also just bbappend the recipe to adjust/replace the file, i.e. recipetool appendfile command Feb 09 18:04:00 ok thx i'll dig into this Feb 09 18:09:26 with alternatives of course you could install your own recipe/package with a higher priority alternative, but i'm not sure if conffiles and alternatives work well together.. Feb 09 18:23:26 JPEW, https://www.yoctoproject.org/reproducible-build-results/ better? Feb 09 18:32:18 halstead: can that say "OpenEmbedded-Core Master Branch" please? Feb 09 18:33:00 halstead: nice though, thanks (and JPEW!) Feb 09 18:33:20 kergoth, yea i am not sure i can use alternatives for conffiles Feb 09 18:34:44 RP: do we need tcf-agent anymore given that we have dropped eclipse Feb 09 18:35:15 RP, Yep. It's using that value to fetch the results so just changing it breaks the page. Easy enough to fix. Feb 09 18:37:15 RP, Done. Feb 09 18:37:42 halstead: Excellent! Thank you so much! Feb 09 18:38:15 I submitted the PR to update the link on reproducible-builds.org, so it should be live there soon Feb 09 18:38:43 RP, I coded it so that "master" is replaced by "OpenEmbedded-Core Master" on output. other branches will still be the branch name. Feb 09 18:39:07 Ah, like: https://www.yoctoproject.org/reproducible-build-results/?branch=master-next Feb 09 18:40:09 JPEW, Yes. RP, should that say "OpenEmbedded-Core master-next"? Feb 09 18:40:32 halstead: ideally, I just wanted to try and indicate somewhere the numbers were for OE-Core Feb 09 18:40:53 halstead: I didn't realise it was pulling the branch from the data :) Feb 09 18:41:03 halstead: It should probably always be "OpenEmbedded-Core {branch}" Feb 09 18:41:25 RP: Other way around, it pulls the data from the branch argument in the URL Feb 09 18:41:52 JPEW: right, that makes more sense :) Feb 09 18:42:13 RP: I was going to ask why there aren't any results for the release branches Feb 09 18:42:16 RP, I've changed it to always say OpenEmbedded-Core $branch branch. Feb 09 18:42:34 kanavin_home: might be an incentive to get the exclusion list minimised :) Feb 09 18:42:39 Rp: e.g. https://www.yoctoproject.org/reproducible-build-results/?branch=gatesgarth Feb 09 18:42:57 JPEW: hmm, there should be something Feb 09 18:43:26 https://git.yoctoproject.org/cgit.cgi/yocto-testresults/plain/oeselftest/testresults.json?h=gatesgarth isn't quite right eh? Feb 09 18:44:32 halstead, RP: I think it's the right URL, there's just nothing there (on that branch) Feb 09 18:44:58 JPEW: I have no idea why there isn't, there should be :/ Feb 09 18:45:07 Yay, we are live: https://reproducible-builds.org/citests/ Feb 09 18:45:54 JPEW: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.1/testresults/oe-selftest-centos/ so they do exists Feb 09 18:46:12 not sure what happened to the git repo additions Feb 09 18:46:33 JPEW, because yocto-testresults is such a huge repo all these dynamic requests are really loading the cgit server. How long can we cache these testresults.json responses without causing trouble? Feb 09 18:47:04 halstead: Probably 24 hours? Feb 09 18:47:07 At least Feb 09 18:47:10 halstead: long cache times are ok, the test repo likely changes about every 24 hours Feb 09 18:47:17 JPEW: I'm curious, is package_rpm not in the reproducibility results because it still has issues? Feb 09 18:47:26 smurray: correct Feb 09 18:47:27 smurray: Ya, it's not tested yet Feb 09 18:47:42 okay Feb 09 18:47:43 smurray: nobody has stepped up to make it work Feb 09 18:47:59 RP: how bad does it look? Feb 09 18:48:05 smurray: no idea now Feb 09 18:48:12 RP: okay, gotcha Feb 09 18:48:17 Thanks. 24 hours will make this simple. ;) Feb 09 18:48:20 smurray: the content is clearly fine so its just dealing with rpm Feb 09 18:48:24 RP, halstead The other option is to pull the testresults.json from a URL not hosted by cgit Feb 09 18:48:27 RP: right Feb 09 18:49:07 6hours to build image + sdk. i5-2500k. Not bad. I kinda want a new cpu though. Feb 09 18:49:39 RP, halstead: That's just the only one I could find that had a consistent URL we could use without having to change the js code all the time Feb 09 18:49:42 JPEW, That's a good option too. I could even remove the custom header options at that point. Then there is the problem of keeping those up to date. Feb 09 18:50:44 halstead: It could something a simple as having the AB publish results somewhere like: http://downloads.yoctoproject.org/releases/yocto/current/$branch/testresults.json Feb 09 18:51:30 (at least, I assume the things in there are published by the AB) Feb 09 18:51:43 JPEW, The AB can publish directly to http://autobuilder.yocto.io/pub/ Feb 09 18:52:36 Ah, that would work Feb 09 18:52:48 JPEW, I just made https://autobuilder.yocto.io/pub/testresults/ Feb 09 18:59:23 RP: I'm not very familiar with the AB, where would I go to make it publish to that URL? Feb 09 19:37:13 JPEW: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/scripts/collect-results and http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/scripts/send-qa-email Feb 09 19:37:29 JPEW: the latter script is badly named now, it did do just that originally Feb 09 21:11:43 I have systemd-container installed, but I don't have systemd-importd.service on my machine. Any idea? Feb 09 21:16:44 Is Chen Qi here? Feb 09 21:23:33 it's listed in FILES_${PN}-container. but doesn't end up in my rootfs :/ Feb 09 21:25:26 vdl are you sure you added the pkg to your image ? Feb 09 21:25:54 yes. Feb 09 21:26:48 and you can find trace in of if in bitbake -e your_image ? Feb 09 21:30:22 vdl: check the image manifests to confirm, or opkg gon target if you have package-management in the image features Feb 09 21:35:09 kergoth: the package is in the manifest and I also have binaries from systemd-container on my system ;) Feb 09 21:36:57 except systemd-importd{,.service} Feb 09 22:11:16 on the topic of dynamic checksum , anyone using a specific method ? I'v seen this : http://www.burtonini.com/blog/2017/06/13/dynamic-source-checksums/ Feb 09 22:31:12 Hello... Not sure how this work but if I have a yocto question should I post it here or somewhere else? Feb 09 22:35:53 moose: Here is fine, just ask Feb 09 22:45:56 Okay thanks. Are there any resources or documentations discuss how to setup common IDEs (ex: eclipse or VC) with yocto SDK? The live coding #4 video on youtbe is really helpful and explain how to cross-compile on the commend line but not really sure how to have a full IDE setup where I can cross-compile, remote connect and remote debug my Feb 09 22:45:56 application/image. I am open to whichever IDE that integrates best with yocto. Apparently, there used to be a yocto eclipse plug-in but that seems to be not supported anymore. Feb 09 22:46:24 JPEW: with https://bugzilla.yoctoproject.org/show_bug.cgi?id=13973 in mind, do you think we should change the format of the data in siginfo files to json? Feb 09 22:50:50 RP: If it's simple types, we could do that. It would make it easier to look at without any tools Feb 09 22:52:53 JPEW: all really simple. I was thinking it would aid readability Feb 09 22:53:12 JPEW: pickle is from before we had json available in python easily :/ Feb 09 22:53:31 RP: Ya, pickle isn't always the best option anymore Feb 09 22:54:23 pickle will recursively handle certain objects, I'm not sure json does though.. so that could still be a problemw ith some data structures Feb 09 22:57:02 fray: It can handle the basic container types (dict, list, tuple) just fine Feb 09 22:57:19 And you can extended it to serialize whatever you want Feb 09 22:58:18 point is it has to be extended for other data structures.. json is much better way to do things IMHO, but it's not all automatic Feb 09 22:59:43 fray: Ah, yes. You can't necessarily just replace pickle() with json.dumps() Feb 09 23:01:51 fray: right, but the data here should be really simple, its about key value pairs, not complex data Feb 09 23:02:37 JPEW: I'm also wondering if the parsing problem I found today in bitbake is the long standing memres mystery bug Feb 10 02:45:54 finally! the gcc build calls the work-shared ./configure script with a relative path, presumably to deal with reproducibility, but by doing that, it results in ridiculously long relative path filenames in the debug info, and the file *names* don't get debug-prefix-map applied, only the directory does! Feb 10 02:46:01 khem: ^ in case you're curious Feb 10 02:46:16 fixing it to use absolute paths there results in correct map application for work-shared paths Feb 10 02:46:30 then just need to see what breaks reproducibility wise, and figure out the best place to put this.. **** ENDING LOGGING AT Wed Feb 10 03:04:52 2021