**** BEGIN LOGGING AT Thu Mar 04 02:59:56 2021 Mar 04 07:18:29 Hi armpit Any chance we can get https://lists.openembedded.org/g/openembedded-devel/message/89698 in the next dunfell pull? Mar 04 09:16:16 Hi, Mar 04 09:20:35 if i want to enable some kernel configs and instead of doing it  by $bitbake virtual/kernel -c menuconfig i am adding that kconfig directly into defconfig of workdir but lets say if CONFIG_XYZ is dependent on CONFIG_PQR then will it automatically enabled that one or do ineed to check and then add that also in defconfig ?? Mar 04 09:20:58 RP: i pressed rebuild on the AB and the rebuild job immediately failed https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/3178 Mar 04 09:26:01 hello, I know nothing to python debuging. But I have seen there is PDB. I would like to know how to use it or another debuger in a python function in a bbclass during the bitbake parsing? is it possible? the goal is to know the available object env in the python function Mar 04 09:27:29 the goal is to know the available objects in the env of the python function Mar 04 09:33:08 if you just want do that then bb.warn(locals()) works Mar 04 09:33:15 but yes you can attack a pdb Mar 04 09:33:53 you need to do something like https://github.com/rossburton/meta-ross/blob/master/classes/pdb.bbclass to use remote-pdb as the workers don't have any connection to stdin/stdout Mar 04 09:34:22 that is, call into rpdb when you want the debugger to break Mar 04 09:35:52 @rburton thanks you. I'm going try Mar 04 09:45:04 vygu2: in a bbclass the only magic is that d may be in the locals for you, that's a bb.data instance so you can d.getVar() etc Mar 04 09:47:46 rburton: right, known issue with the shared checkouts which get deleted when the build finishes Mar 04 09:48:41 rburton: bah: Mar 04 09:48:42 https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1594/steps/12/logs/stdio Mar 04 10:08:12 ok Mar 04 10:09:19 rburton: is it worth trying another cpu core? Mar 04 10:12:08 Hello there, is there a clean way to use a recipe from a master layer instead of the current branch, for example with zbar https://layers.openembedded.org/layerindex/recipe/108505/ Mar 04 10:17:33 The thing with zbar is that the 0.10 was abandoned in 2012, the version in the master layer comes from a fork. Mar 04 10:19:40 How/When master recipes are pushed in the different branches ? **** BEGIN LOGGING AT Thu Mar 04 10:48:20 2021 Mar 04 10:49:31 does somebody now something about INITSCRIPT_PACKAGES? i am trying to create 2 init scripts in one recipe -> https://pastebin.com/xLHPGFz2 Mar 04 11:10:13 chris_ber: INITSCRIPT_NAME_${PN}-server Mar 04 11:10:22 you're missing the ${PN} in your second parts I assume Mar 04 11:10:43 ok, i will try it Mar 04 11:19:55 (same for PARAMS) Mar 04 11:24:37 Hi, I don't really have a question, and I hope I'm not breaking any rules. My team is looking for a contractor for 2-3 months max. Short term we need to (among other things) setup RAUC with our custom systems to enable remote updates on our machines - just so you have an idea. Email me on adamp.burner gmail.com for more information. Mar 04 11:29:52 Sponge5: https://www.yoctoproject.org/community/consultants/ might help? Not sure how up-to-date it is though Mar 04 11:45:34 qschulz: should be Mar 04 11:49:27 thanks qschulz Mar 04 12:21:03 qschulz: as you mentioned and descripted here(http://www.embeddedlinux.org.cn/OEManual/update-rc-d_class.html) i changed it and it is still not working :( Every suffix will be ignored Mar 04 12:21:05 INITSCRIPT_PACKAGES = "${PN} ${PN}-B" Mar 04 12:21:09 INITSCRIPT_NAME_${PN}-B= "B" Mar 04 12:21:13 INITSCRIPT_PARAMS_${PN}-B = "start 47 2 3 4 5 ." Mar 04 12:25:11 the rc package without the suffix "-B" is correctly created Mar 04 12:57:54 Hello guys ! There is a way to force an eth device tree entry (let's say @) to be named as in linux so that I can use ifconfig to set the interface's parameters ? Mar 04 13:08:09 thekappe: if you're using systemd it can be done with .link files Mar 04 13:10:08 thekappe: otherwise, should be doable with a udev rule Mar 04 13:11:47 smurray, I've run udevadm info /sys/class/net/eth1/ --attribute Mar 04 13:12:05 ... Mar 04 13:12:16  looking at parent device '/devices/platform/amba/ff0c0000.ethernet': Mar 04 13:12:22 KERNELS=="ff0c0000.ethernet" Mar 04 13:12:33 SUBSYSTEMS=="platform" Mar 04 13:12:35 ... Mar 04 13:13:06 So I need to add a rule with KERNELS=="ff0c0000.ethernet" ? Mar 04 13:17:19 thekappe: I've not done it for a long time, but I imagine that would work. The other option would be to use ATTR{address} to select by MAC Mar 04 13:17:37 chris_ber: are you creating a bbappend or a "normal" recipe? Mar 04 13:18:04 smurray, the fact is that the address will change since we will have Mar 04 13:18:16 a set of board to be used Mar 04 13:18:22 asking because the fact that the PN recipe works, might be a sign that what you're developing isn't actually parsed (PN is by default in INITSCRIPT_PACKAGES) Mar 04 13:18:54 using the DT address will be transparent for all of them Mar 04 13:19:03 thekappe: okay, wasn't clear to me if this was for testing or not Mar 04 13:19:10 thekappe: look at what Ubuntu or others are doing Mar 04 13:19:12 by the way it's not working :D Mar 04 13:19:21 as usual Mar 04 13:19:54 thekappe: first call a script when the udev rule matches to check that it does actually match correctly Mar 04 13:20:14 mmm Mar 04 13:20:59 I think that's not matching.. Mar 04 13:21:08 I used this syntax: https://unix.stackexchange.com/questions/91085/udev-renaming-my-network-interface Mar 04 13:22:22 removing some entries related to his hw and adding KERNELS=="ff0c0000.ethernet" Mar 04 13:22:45 thekappe: at least with the systemd udev there's a knob to turn on very verbose udev debugging, can't remember if it's in the conf file or set via kernel cmdline Mar 04 13:31:06 is it KERNELS with an S??? Mar 04 13:31:55 yeah, that's one of the udev attributes Mar 04 13:32:24 the KERNEL w/o a S attribute is the name the kernel has generated, I believe Mar 04 13:37:03 qschulz: it is a "normal" cmake recipe with src_uri = "git@..." Mar 04 13:38:20 what could be a reason, that this will not be parsed? in http://www.embeddedlinux.org.cn/OEManual/update-rc-d_class.html is mentioned: "... Note that each init script must be in it's own package. ..." Mar 04 13:39:39 RP: I managed to remove three built-in paths from perf, but the test is still failing here (and still taking 141 minutes to run), so I was looking for things manually. Have you been running diffoscope yourself when fixing these, or something else ? Mar 04 13:43:10 zeddii: I used a combination of diffoscope and meld Mar 04 13:43:31 zeddii: you could manually setup two builddirs and then compare perf from both Mar 04 13:44:10 I have the reproducibleA and reproducibleB dirs still around. So that should work, no ? Mar 04 13:44:23 the perf buid artifacts are all there Mar 04 13:44:38 I was checking to confirm that the build local was no longer in the executable, and it is gone. Mar 04 13:53:21 zeddii: yes, you should be able to run builds in them as normal Mar 04 13:56:38 chris_ber: yeah, that was the next suggestion, you need to install the init script in the correct package Mar 04 13:58:36 RP: I tried last night to rebuild perf in them and couldn't get the incantation right. I'll look at the selftest and see what I was messing up when trying to initialize the env. Mar 04 13:59:12 (I saw no mention of the reproducibleA/B directories, so I assume it is written in last minute and then removed). Mar 04 14:02:31 zeddii: selftest is a bit paranoid about cleanup lest the tests contaminate each other Mar 04 14:03:10 It seems like Epiphany is broken both in master and dunfell (webkitprocess segfaults at runtime on weston). Mar 04 14:03:17 even if I don't build, I should be able to run some compares between the buildirs, etc, and maybe even run diffoscope/meld (which I've never done for either). Mar 04 14:05:22 zeddii: meld is helpful to know what is different between two dirs. Since you know its the perf binary it may be less helpful here Mar 04 14:05:45 diffoscope is more helpful at telling you why/how two binaries are different but can take longer Mar 04 14:09:08 and my builder isn't exactly speedy :D but I can try. I had to bolt it's disk back together yesterday, so hopefully it holds up until I get this sorted. Mar 04 14:09:24 but I know for a fact there were three build directories in the binary, and those are now gone. Mar 04 14:09:41 strings perf | grep showed me that Mar 04 14:09:54 zeddii: its all about incremental progress :) Mar 04 14:10:11 zeddii: I have some weird intermittent issue with ltp for example but at least every binary isn't different all the time Mar 04 14:24:31 qschulz: i am not sure what are you saying by this. How do i install it? i mean i install the init script themself with the "do_install_append" routine Mar 04 14:26:47 chris_ber: FILES_${PN}-B = "/path/to/initscript" Mar 04 14:29:37 qschulz: https://pastebin.com/1XGNFSXt Mar 04 14:30:55 can't see my mistake Mar 04 14:31:45 and the recipe is called thermostat_0.1.7.bb Mar 04 14:33:14 chris_ber: you need to create ${PN}-server and ${PN}-client packages, then specify which files they should contain Mar 04 14:33:32 spoiler: PACKAGES and FILES_ variables are the one you're looking for Mar 04 14:33:48 ones* Mar 04 14:34:24 ok, i will try. Thx Mar 04 14:51:40 hi Mar 04 14:51:43 how to migrate python code in to a bb class Mar 04 14:51:53 Can anyone help me with the references Mar 04 14:53:14 Manjunath: the question is not specific enough, what exactly are you trying to do? Mar 04 14:55:06 i have a python script for which i have created a custom recipe file(.bb) for it to execute when i run a bitbake command Mar 04 14:55:20 i want to port that to a bbclass file instaed Mar 04 14:57:10 So there is a recipe file example.bb for that python script when i run bitbake example it will run that python script Mar 04 14:57:48 i want to create a bbclass file instead so that i can use INHERIT option instead Mar 04 14:58:01 in local.conf file Mar 04 14:58:09 * dwagenk sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/AAynEfUuWpkfUTpCXAqPSrkn/message.txt > Mar 04 14:59:54 dwagenk: people usually don't read links, please try to keep it short or split your message in multiple lines Mar 04 15:00:09 So can anybody help me with this Mar 04 15:00:33 Manjunath: do you have your script in SRC_URI and then call the script from within the recipe or do you have the script verbatim in the recipe as a function and call the function from within the recipe? Mar 04 15:00:41 qschulz: OK. Link was just for reference. Mar 04 15:01:17 dwagenk: no, I meant that we received: 15:58:09 * | dwagenk sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/AAynEfUuWpkfUTpCXAqPSrkn/message.txt > Mar 04 15:01:30 i have script uri Mar 04 15:01:52 qschulz: OK, sorry, that was really not intended! Mar 04 15:02:28 dwagenk: I know, Matrix and its wonders :) Mar 04 15:03:07 Manjunath: what does your python script do and what do you want to have it included for all recipes in all layers? Mar 04 15:05:31 In short: would it be sensible to modify libcap-native (openembedded-core) PACKAGECONFIG to include "attr"? Only "in-tree" usage I found would be gnome-keyring (meta-openembedded) that would then work with pkg_postinst instead of pkg_postinst_ontarget. Mar 04 15:05:32 it generates report based on the Timesys Vigiles meta data Mar 04 15:06:09 no i want to write a bbclass Mar 04 15:06:26 every examples say about bb files(recipes) Mar 04 15:06:55 dwagenk: we're now missing a lot of context as to what brought you to this conclusion. It's fine to have your message in three or four parts :) just no Matrix link, to increase the chances of people reading you (and being nice to search engines since this channel is archived) Mar 04 15:07:09 Manjunath: INHERIT in local.conf will add your bbclass to ALL recipes of ALL layers Mar 04 15:08:10 Manjunath: c.f. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#inherit-configuration-directive Mar 04 15:10:25 Actually my intent was to execute the python script at the last of the build , means meta-timesys  layer will generate vigiles metadata later i need to execute this script Mar 04 15:11:16 Vigiles is a vulnerability management tool that provides build-time Yocto CVE Analysis of target images. It does this by collecting metadata about packages to be installed and uploading it to be compared against the Timesys CVE database Mar 04 15:11:19 setting file capabilities on a binary in an image during do_rootfs is possible with pseudo/fakeroot since the pyro release. It needs setcap from the libcap-native package with PACKAGECONFIG "attr". libcap-native has an empty default value for PACKAGECONFIG so far. Mar 04 15:12:10 Wanted to get some opinion on that before submitting interdependent patches to two different openembedded layer Mar 04 15:13:40 mmm Mar 04 15:14:01 I've added the following rule in /etc/udev/rules.d: Mar 04 15:14:14 ACTION=="add",SUBSYSTEM=="net",KERNELS=="ff0c0000.ethernet",RUN+="/bin/sh -c 'echo == >> /home/root/udev-env.txt; env >> /home/root/udev-env.txt'" Mar 04 15:14:39 afte rebooting I've found the file udev-env.txt Mar 04 15:14:44 so the rule is matching Mar 04 15:15:17 Now, AM I supposed to add NAME=="myifacename" to rename the iface ? Mar 04 15:15:36 thekappe: that's how I understand it to work, yes Mar 04 15:17:01 qschulz Mar 04 15:17:48 I'm shocked Mar 04 15:17:51 it worked Mar 04 15:17:55 hi Mar 04 15:17:58 @smur Mar 04 15:18:12 smurray, qschulz, thanks Mar 04 15:18:27 thekappe: cool Mar 04 15:18:47 smurray Mar 04 15:18:51 Manjunath: probably looking for IMAGE_POSTPROCESS_COMMAND Mar 04 15:19:47 that is ok Mar 04 15:19:59 but i want to create a bbclass file Mar 04 15:20:52 how to proceed with that Mar 04 15:21:37 Manjunath: Actually my intent was to execute the python script at the last of the build Mar 04 15:21:39 that's what you said Mar 04 15:21:43 IMAGE_POSTPROCESS_COMMAND foes that Mar 04 15:21:45 does* Mar 04 15:22:11 i want to learn how to create a bbclass file Mar 04 15:22:17 otherwise, play with https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_CLASSES Mar 04 15:22:28 Manjunath: bbclasses are not much more different than bb recipes Mar 04 15:23:33 ok Mar 04 15:24:00 Manjunath: something like image-buildinfo.bbclass is sort of along the same lines, but you'll note it just adds the function it defines to IMAGE_PREPROCESS_COMMAND Mar 04 15:24:08 any documentation on how to write one Mar 04 15:24:31 or you have any suggestion for me to follow Mar 04 15:24:42 can you give me* Mar 04 15:26:12 Manjunath: it's litterally a bb recipe, just in meta/classes and you inherit its content with `inherit myclass` if your bbclass is myclass.bbclass Mar 04 15:26:15 see it as an include file Mar 04 15:26:53 otherwise, just take inspiration from the plethora of bbclasses that already exist, I'm not sure there is any documentation for that nor there is a need for it Mar 04 15:27:54 where can i find plethora of bbclasses Mar 04 15:28:07 see meta/classes Mar 04 15:28:16 in oe-core or poky Mar 04 15:28:27 smurray: please stop me, i'm about to create meta-classes.... Mar 04 15:28:50 LetoThe2nd: heh Mar 04 15:33:11 qschulz Mar 04 15:34:59 Thank you Mar 04 15:37:04 dwagenk: if you don't have any answer by tmrw...since your blocker would be libcap-native in oe-core, just send a patch for the added PACKAGECONFIG explaining why it's needed and you'll see what RP or others will say about it :) Mar 04 16:11:28 khem: armpit Do you guys have any idea when is the next pull for meta-oe/dunfell? I see that the dunfell branch wasn't updated in a couple of good months so I'm wondering what is the process of getting stuff on that branch. Mar 04 17:09:14 JPEW: RP: I'm trying to run diffoscope by hand and failing. Is it looking at the package build dirs, or the output packages ? I'm looking at the reproducible.py and don't know what 'packages' dir it is talking about, since I don't seem to have one in my build-st directory. Mar 04 17:09:39 alephan: meta-oe/dunfell was updated recently, maybe you're looking at wrong repo Mar 04 17:10:04 alephan: 13 days ago Mar 04 17:14:40 zeddii: personally, I put perfXX.deb in A/, the other perfXX.deb in B/ then diffoscope A B --html-dir C and then look at C with a browser Mar 04 17:15:12 ahah. I think my packages got deleted, but the build directories are still there. Mar 04 17:15:19 zeddii: in the repro build, it would look at whatever you set the saved output to Mar 04 17:15:43 zeddii: the code would copy differing tmp/deploy/deb/XXX there Mar 04 17:15:59 zeddii: I use deb or ipk as diffoscope understands it better Mar 04 17:16:06 I didn't set the saved output. is that an oeselftest argument ? I see self.save_results reference in the code, but never assigned. Mar 04 17:17:27 but a search does show they are still in my tmp/deploy/deb directories for both A and B. i can manually copy them out. Mar 04 17:18:10 zeddii: I mentioned it originally when I described it Mar 04 17:19:32 zeddii: OEQA_DEBUGGING_SAVED_OUTPUT=/tmp/somewhere oe-selftest XXX Mar 04 17:20:10 ahah. yes. I see that now. I wasn't near needing that yet and managed to forget. I'm running it manually, but will set it next time Mar 04 17:21:06 now to figure out how ot export the html from the headless builder with no server. Mar 04 17:21:10 * zeddii opts for scp Mar 04 17:27:56 hmm. my diffoscope output was sh*t compared to one you shared before. Mar 04 17:28:20 zeddii: which version of diffoscope? Mar 04 17:28:41 random ubuntu one, probably pretty old. I couldn't get the native one to run Mar 04 17:28:50 (by hand that is) Mar 04 17:29:01 version says 103 Mar 04 17:29:11 this is a really old builder and OS. Mar 04 17:30:28 zeddii: current is 168 Mar 04 17:31:17 ok. will upgrade. Mar 04 17:51:16 JPEW: RP: I'm seeing a bit more decent output now. I can't say I understand it all, but I'm sseing a lot of yy* references. You mentioned a bison fix on another package ? do you have a pointer to it ? Mar 04 17:54:30 zeddii: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=b6018a1625c22393c1f94e9d23d84f7842b95f24 Mar 04 17:54:53 zeddii: Bascially, bison support --file-prefix-map=$OLD=$NEW Mar 04 17:55:43 * zeddii ponders. Mar 04 17:56:19 My bad JaMa Mar 04 17:56:37 I need some sleep :) Mar 04 18:03:31 JPEW: RP: one other question, have you run into this NT_GNU_BUILD_ID before ? It's set in the perf sources, but yet, it seems that diffoscope is showing it as a difference. I checked the commit history and do see anything else forcing it. Mar 04 18:03:57 google tells me what it is, but not why it would vary. I'm digging into that now. Mar 04 18:09:42 the GNU build ID uses a hash function to give the program a custom id so that when debugging sources/symbols and binary don't "drift" Mar 04 18:09:55 as to why it changes, I'm not sure.. I THOUGHT it was purely hash based Mar 04 18:10:53 it can't be just perf that has it in our builds, so there must be a standard solution to making it not differ Mar 04 18:11:08 found this on stack overflow: No, there is no such tool because the precise way a build-id is calculated isn't specified. It just has to be universally unique. Even the precise length of the build-id isn't specified. There are various ways using different hashing algorithms a build-id could be calculated to get a universally unique value. And not all data might (still be) in the ELF file to recalculate it even if you knew how it was created originally. Mar 04 18:12:00 https://stackoverflow.com/questions/41743295/elf-build-id-is-there-a-utility-to-recompute-it Mar 04 18:12:09 it goes on a bit more about how it works and is computed Mar 04 18:12:10 hahah Mar 04 18:12:11 https://tests.reproducible-builds.org/debian/issues/unstable/build_id_differences_only_issue.html Mar 04 18:12:15 it's possible perf is computing itself.. Mar 04 18:12:37 RP: do we have a way to ignore some differences ? Mar 04 18:13:07 found from here: https://github.com/polybar/polybar/issues/2102 Mar 04 18:14:29 check the perf sources to see if something is passing into the linker --build-id= apparently some programs try to set their own build info, and to keep it unique mix in the current datestamp of the build Mar 04 18:14:35 sources/makefile Mar 04 18:15:33 if you can (binary diff) the build_id between two builds, it could show if somehow text is being inserted that has meaning Mar 04 18:15:40 or if it is just a pure hex string.. Mar 04 18:16:49 it claims sha1 Mar 04 18:17:10 I'll hack around it, when it is the last thing Mar 04 18:17:28 since it could still be other differenes that result in the different hash Mar 04 18:19:11 the key is the value is defined as 'arbitrary identification data'. It's USUALLY a hash, but doesn't have to be. Any program can link using --build-id= and that will be used instead Mar 04 18:19:46 yah, since it already seems to be specified, it should be easy enough to just pick something, but I'll do that last if the has doesn't "just match' eventually. Mar 04 18:19:53 So some programs can say "hash my sources, add todays time/date" and this is my magic build-id (ignoring whatever GNU would have defined). It's promised to be "unique", but rebuilds will also ALWAYS get a new value, which we don't want Mar 04 18:20:45 I'd say we need to make sure it's NOT just picking someting, but instead using the default. Now if the default keeps changing.. then we can try to set a value. (using the OE task hash for do_compile) would be a completely valid way or doing it Mar 04 18:21:41 and if this is an issue beyond perf, then using the task hash as a generic solution might be valid.. Mar 04 18:42:10 hi I would like to test the edsk but I don't understand where I have to download it Mar 04 19:03:58 alephan, I was updated last week Mar 04 19:24:46 Thanks. It was my fault messing with forks locally. armpit Mar 04 19:25:06 Do you plan for another one soon? Mar 04 19:26:30 alephan, is there something you are looking for. I am queuing up changes, its my builds that take a long time Mar 04 19:28:40 That's awesome. Yes. I'm looking for getting in the nss fix. Mar 04 19:28:54 It's already in master-next. Mar 04 19:33:06 https://github.com/openembedded/meta-openembedded/commit/dad2aef6be76564103952e0ad78a7d666b49f72e Mar 04 19:55:47 zeddii: Usually the build-id differing is a side effect of other differences and will disappear when the others are fixed Mar 04 19:57:10 Since the default is to hash the input to get the build ID, if the input differs in any way, than the build ID will differ also... I guess we could force it to a specific value, but you'd still have to fix the other places that are different Mar 04 19:57:16 Unless I mistaken Mar 04 19:57:28 *I'm mistaken Mar 04 19:57:49 that's what I grokk'd as well. Will see if my yacc fixup smoothes that out. Mar 04 20:12:59 huh, i didn't know yacc had a prefix map, interesting Mar 04 20:48:18 RP, vmeson pointed me at this link, and mentioned some code might have been merged from it but I'm not seeing anything related on master-next in bitbake. Am I overlooking something? Mar 04 20:48:21 https://lists.openembedded.org/g/bitbake-devel/topic/77645766 Mar 04 20:52:19 paulg: It was a hurried conversation with vmeson and I'm half remembering things. It looks like the submitter didn't agree with what I was asking for and didn't implement it so it didn't make it in. It does give an idea of where the discussion got to Mar 04 20:52:46 paulg: I do think what was suggested there should be quote workable/useful Mar 04 20:54:14 yep, I'm glad vmeson pointed me at it. I think what I'm doing should be useful, and since vmeson let the cat out of the bag, you can expect me to solicit your opinion on it sometime soon. Mar 04 20:54:51 I should break out some bits, write some commit logs and get an RFC out... Mar 04 20:55:11 paulg: sounds good, particularly as we're technically past feature freeze point ;-) Mar 04 20:55:43 yeah, I don't worry myself with other people's deadlines. :-P I just do what I can when I can. Mar 04 20:57:53 If it doesn't suck, then someday maybe it gets merged. ;-) Mar 04 21:01:18 paulg: fair enough. Just mentioning the point we're at to set expectations. I get a lot of unhappy people about feature freeze Mar 04 21:28:42 RP: Didn't the pseudo patches made it to dunfell? Mar 04 21:29:25 I think I've seen the update in the PR - was that missed or is there an issue I didn't follow? Mar 04 21:30:48 alephan: thought I pushed them earlier? Mar 04 21:31:19 I just updated the dunfell branch and they weren't there Mar 04 21:31:22 Let me recheck Mar 04 21:31:33 alephan: which pseudo patch specifically? Mar 04 21:31:46 https://lists.openembedded.org/g/openembedded-core/message/148367 Mar 04 21:32:16 alephan: the pseudo revision was updated to cover it rather than patches? Mar 04 21:32:33 That's what I was expecting but... hm. Let me check again Mar 04 21:52:54 It is there RP sorry for the noise. Mar 04 21:53:33 Also confirmed dunfell is compiling fine now with glibc 2.33 Mar 04 21:53:45 alephan: cool, glad its working :) Mar 04 21:57:10 hi .. I am testing esdk .. how do I make the cross compiler ? bitbake -c populate_sdk like in sdk ? Mar 04 22:09:11 jdrol: the esdk equivalent is -c populate_sdk_ext Mar 04 22:15:36 JPEW: for the file-prefix-map to bison. Do you have real world person description of what ti does ? I tried patching it into my perf build and it made no difference Mar 04 22:15:59 specifically, do you think it would help with the #ifdef's in generated .h files ? Mar 04 22:16:20 that seems to be what is still sneaking into the perf binary an blowing up the reproducibility Mar 04 22:37:15 pwd Mar 04 22:58:59 RP thanks Mar 05 00:09:31 armpit: found the link to the exact patch: https://lists.openembedded.org/g/openembedded-devel/message/89698 Mar 05 00:09:34 Thanks once again. **** ENDING LOGGING AT Fri Mar 05 02:59:57 2021