**** BEGIN LOGGING AT Wed Feb 03 02:59:57 2021 Feb 03 03:24:45 ...never say you have something solved late in the day on Groundhog Day. Feb 03 06:31:29 Hello.. I have a third party recipe here https://github.com/linsam/meta-s6/blob/master/recipes-s6/s6/s6_2.2.4.2.bb which uses PV = 2.2.4.2 in recipe name . This is too old Feb 03 06:32:04 How do I make sure to get latest source with PV = 2.10.0.1 Feb 03 06:32:22 is there a way to write bbappend ? Feb 03 07:41:39 @kiwi_29: I would just write a new recipe s6_2.10.0.1.bb Feb 03 07:42:13 hi RobertBerger ..thank you :) .. I just wrote one and currently debugging errors ..phew Feb 03 07:42:45 @kiwi_29: I hope you enjoy ;) That's always fun. Feb 03 07:42:57 :) Feb 03 07:45:07 @kiwi_29: and once you get it to run, I guess you will have even more fun integrating it, I guess, if I understand correctly what it does Feb 03 07:46:45 yes... its a mess ..trying to get it to work somehow Feb 03 07:47:12 so you are after a really small system it seems Feb 03 07:48:38 khem: looks like the glibc patch needs attention :/ Feb 03 07:52:30 RobertBerger ...thats correct Feb 03 08:23:23 hello Feb 03 09:02:50 I think my build takes a lot time, is there something in the configs I might set? for linux-yocto-tiny-5.10 Feb 03 09:11:45 kayterina: define "a lot of time" and on which machine you're building Feb 03 10:14:47 I stopped the build and didn't complete. It was over 2 hours for bitbake virtual/kernel and it started at 46% from where I stopped it yesterday. The machine has an i7-10700 CPU @ 2.90GHz Feb 03 10:15:31 46% of the linux-yocto-tiny, not the whole tasks Feb 03 10:30:11 Hello all! A few people in my team would like to include a python project in Yocto. The Python project has its dependencies in a requirement.txt. I know that The Right Way(tm) would be to move over the dependencies to the RDEPENDS variable in the recipe, but they want to keep them there. (For development outside Yoct I suppose.) Feb 03 10:30:33 Can you have Yocto read and respect that requirements.txt somewhow? Feb 03 10:33:06 manuel1985: requirements.txt is for pip, it doesn't use yocto or host package system to satisfy dependencies. So I'd say no, requirements.txt can not be used directly. You can use it to fill in bitbake recipe DEPENDS and RDEPENDS fields though, but need to manually check that versions are compatible. Feb 03 10:34:08 mcfrist: By "you can use it" you mean automatically? Like, is there some tool I can leverage for this? Feb 03 10:37:21 manuel1985: there is no official supported mechanism, no. You may see if devtool can correctly build a recipe for your project and then script around that to regenerate the recipe. I don't know if it will work or not though Feb 03 10:40:17 RP: I see, thanks Feb 03 10:40:46 kayterina: that does not seem correct indeed. Usually it's a good thing to look at what the current process is doing (the PID is printed on the bitbake output), to check if it's hung somewhere Feb 03 10:46:05 i5-2500k@4.2Ghz, took 4h + 2h for the sdk. Not bad considering I've got a load of crap into that image. Feb 03 10:46:53 in my preious job I built on my laptop with a i3/8gb, here they got me a deeloper's machine, I am expecting miracles Feb 03 10:47:36 heh I'm just building on my own desktop, since working from home Feb 03 10:48:30 ha,you should pay tax for the gas you are not consuming! Feb 03 10:48:40 (or was it in the preious quarantine?) Feb 03 10:49:57 anyways, I found a bsp from the vendor with a 3.4, can I use its u-boot and dtb with the linux-yocto 5.4/sunxi_defconfig? Feb 03 10:51:43 kayterina: why would you take a 3.4 kernel? Feb 03 10:51:53 and no, you cannot take the defconfig from 5.4 kernel Feb 03 10:53:03 kayterina: check if your machine is still doing something with `top` or `htop` and check the output of the process with `PID=20151; tail -f /proc/$PID/fd/2` Feb 03 10:53:12 (change the PID obviously) Feb 03 10:53:29 was it 2h for only virtual/kernel or for the whole build? Feb 03 10:53:54 bitbake virtual/kernel , wait I'll run the commands Feb 03 10:57:22 I ran again bitbake virtual/kernel and in another terminal `PID=31806; tail -f /proc/$PID/fd/2` it is blank. No errors? Feb 03 10:57:50 blank=no output on terminal,blinking cursor Feb 03 10:58:12 "3.4 vendor kernel". kayterina - Show me where they hurt you :( Feb 03 10:59:13 Kyubi: on a serious note, what kind of board are you guys using? Feb 03 11:00:54 malinus: bpi-m2 zero IIRC, just old Allwinner boards didn't have decent BSP support from the vendor. Feb 03 11:01:26 kayterina: the PID corresponded to which task? and sometimes you got to wait a bit Feb 03 11:02:05 ah I bet it's during the fetch task? Feb 03 11:02:18 git isn't very verbose while fetching very big repos Feb 03 11:04:01 you can also read the logs still with tail -f from ${WORKDIR}/temp/log.do_ (workdir being tmp/work/...../linux-yocto/5.4.../) Feb 03 11:12:58 d'gh,yes it is during do_fetch, I'll search the logs Feb 03 11:22:48 so it is just downloading that is slow, so I leave it to finish? It says 3gb, is it networking on my side? it says Feb 03 11:23:16 Length: 3177321323 (3.0G), 585744215 (559M) remaining [application/octet-stream] Feb 03 11:23:16 Saving to: ‘/***/poky/build/downloads/git2_git.yoctoproject.org.linux-yocto.git.tar.gz’ Feb 03 14:19:20 halstead: Do you have some time to sort out that reproducibility page with me? Feb 03 14:21:51 are dts and dtsi appended to the kernel recipe or uboot? Feb 03 14:55:35 kayterina: what do you mean? Feb 03 14:56:47 Hello Guys, Hope you all are doing well ... Feb 03 14:58:21 How to make a binary or a script (ELF or whatever) be included with image whenever i bitbake it ? Let's say i cross compiled things and ii want them to be automatically included (copied) to /usr/bin/${ELF-NAME} everytime i create the image ? Feb 03 15:01:44 medaliyou: https://docs.yoctoproject.org/dev-manual/common-tasks.html#packaging-externally-produced-binaries Feb 03 15:03:01 medaliyou: but note, usually its better to actually write a recipe that properly does the compilation inside the build process. Feb 03 15:05:33 moto-timo: Hello. I have a short question about `meta-python` do you accept some python modules which are present in v>dunfell but are needed for other layers, backported to dunfell? Feb 03 15:06:05 namely: python3-betamax, python3-mccabe, python3-mock, python3-pep8 and python3-requests-toolbelt Feb 03 15:06:09 Mainly because that's an LTS and these are needed as dependencies for other layers (for example homeassistant) Feb 03 15:06:31 as i asked before,  i ve to optimize boot-time, so is it better to cross compile a big QT project or to install a QT layer and recipes ??? Does it affect system boot time that much ? Feb 03 15:08:19 moto-timo: I'm willing to push patches and test so I don't have to maintain them as a separate temporary layer Feb 03 15:09:11 kayterina: uboot and kernel have device trees support but they can (and often are) different Feb 03 15:09:59 medaliyou: why should the boot time of your device be affected by where you compiled the application? the device runs a binary. Feb 03 15:11:08 I want to build for bpi zero with latest kernel. How do I provide the device tree? Feb 03 15:11:13 alephan: generally we do not add anything new to a stable branch Feb 03 15:11:56 i mean booting a small FS is faster than a larger one ? Feb 03 15:12:19 medaliyou: and why do you think manually crosscompiling and packaging makes the FS smaller? Feb 03 15:13:10 alephan: but dunfell is the first LTS, so it is worth discussing with the OE TSC. Feb 03 15:13:32 @mo Feb 03 15:13:51 moto-timo: Yes. That's exactly why I'm asking. I hope we can push them due to that being an LTS. Feb 03 15:14:16 please excuse me if i'm not asking things well, i'm an amateur & still learning, but from what i understand buidling a linux containing a QT layer (various libQTs) is gonna take much time to boot VS a linux containg only some binaries in /bin ??? Feb 03 15:14:49 alephan: you must ask OE TSC. It is a deviation from stable branch policy. Feb 03 15:15:10 alephan: moto-timo: i would rather vote for a form of HWE-style layer/branch. e.g., leaving dunfell untouched, but providing dunfell-enablement-backports (or comparable) Feb 03 15:15:37 medaliyou: its not about the way you ask - i'm just trying to make you think about your own question. Feb 03 15:15:58 medaliyou: hint: you are on the COMPLETELY wrong track. Feb 03 15:16:20 hhhhhhhh, great news, HELPPPPPPPPPPPP ! Feb 03 15:17:12 LetoThe2nd: I can always have a separated layer which ads/does the required changes. But that was the whole idea of not having to maintain a duplication for a full LTS. Feb 03 15:18:00 medaliyou: well, how about actually working through some of the documentation on boot time reduction? theres probably a gazillion of tutorials on youtube already. Feb 03 15:18:00 If you meant to have a additional branch in meta-oe for it, I find it a maintenance overhead just transferred to another place without any real benefit. Feb 03 15:19:09 I am confused. There are at least 3 sources for the bpi images. Shouldn't I take something from them? Uboot for example? And if it is possibly to use latest kernel,why all images have 3.4 or 4.4? Feb 03 15:19:24 kayterina: the dts is already provided arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts Feb 03 15:20:05 alephan: the point is - from the LTS perspective, whats to be gained if we start randomly adding new packages just because "somebody depends on ot"? Feb 03 15:20:12 *i Feb 03 15:20:15 *it, even Feb 03 15:20:17 kayterina: because Allwinner is (was?) a very bad vendor in terms of BSP quality and updates Feb 03 15:20:39 so, board vendors using Allwinner shitty BSP probably didn't want to make more effort that this Feb 03 15:20:41 than* Feb 03 15:21:18 The gain is to enable it to be used on more external layers. Because LTS will be a place to stay for a good while now LetoThe2nd Feb 03 15:21:26 now, there was a huge community effort behind Allwinner SoCs that enabled the upstream linux kernel to have support for them Feb 03 15:21:30 alephan: but of course as moto-timo put it - the TSC is authoritative on that. i am not. Feb 03 15:22:25 alephan: where do you end? "just new recipes".. "erm now, see, this set of recipes just needs that new class"... "ya sure, its just a tiny backport..." Feb 03 15:23:11 The alternative is for all the other people to reinvent the wheel - and that for an LTS so for a long time. I find it a bit unappealing. But I see the point Feb 03 15:24:21 alephan: an LTS will inevitably age and need more and more massaging to be used on new things. and no, nobody needs to reinvent anything. it can all be done just the way you worded it. just not in the core layer. but thats what we have layers for, right? just make a meta-python-lts-special-sauce that you can share. zero reinvention. Feb 03 15:25:37 one of the reasons why an LTS isn't an idea as good as it sounds. Feb 03 15:26:21 hm.interesting. So I am left with the machine.conf. where is the path with available tunes? I suppose there will be one for sun8iw? Feb 03 15:27:51 LetoThe2nd: Sure. That was indeed the initial idea. I will stick to that for now. Feb 03 15:30:01 alephan: :) but of course, please take it to the TSC nonetheless. its always good to have opinions, and eventually a decision that can be referred to! Feb 03 15:30:17 kayterina: I wouldn't take inspiration from meta-sunxi as they decided to go with one tune, the common denominator between all supported machines, which means it won't squeeze as much as possible from your HW Feb 03 15:30:46 c.f. https://github.com/linux-sunxi/meta-sunxi#performance Feb 03 15:31:28 @LetoThe2nd I think your point was clear and I tend to agree generally with it when wearing the maintainer/LTS hat. From the user perspective I was trying an easier way forward though. Feb 03 15:31:48 Thanks LetoThe2nd and moto-timo Feb 03 15:32:24 alephan: thanks for the input! Feb 03 15:34:26 Cheers! Feb 03 15:45:23 LetoThe2nd: I just realized with whom I just talked. Prost! Feb 03 15:53:19 alephan: hehe, prost! Feb 03 16:20:47 RP: yeah I think the binutils patch series touches glibc as well and so they need to be sequenced Feb 03 16:22:01 khem: oh, I understand now :/ Feb 03 16:22:27 RP: I will have to send v2 anyway so lets get the binutils settled first Feb 03 16:22:51 khem: we'll need a new uninative release once we get glibc in Feb 03 16:22:58 RP: one issue I am seeing is due to hwcaps introduction in glibc 2.33 Feb 03 16:23:11 khem: ok. I'm worried about the wic failure on the AB and whether its from binutils or not Feb 03 16:23:26 our tuning for qemux86-64 is core2duo and glibc ldso does not lilke it Feb 03 16:23:35 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/58/builds/2980 Feb 03 16:23:41 recipe-sysroot//lib/libc.so.6: CPU ISA level is lower than required Feb 03 16:24:05 if I use -cpu Nehalem instead of -cpu core2duo then it works ok Feb 03 16:24:19 this is when runing qemu usermode Feb 03 16:24:56 khem: hmm, interesting :/ Feb 03 16:28:11 khem: the initramfs issue is due to things like pxeboot.img in grub growing to 132MB in size with loads of zero padding Feb 03 16:28:20 khem: looks bintutils to me Feb 03 16:28:44 so one option is to change using -cpu core2duo in machine conf for qemu other option perhaps is to bump qemu defaulttune to corei7-64 Feb 03 16:30:17 yeah its likely due to linker perhaps but can we know which given binary is causing it ? Feb 03 16:33:38 khem: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=6643507ce30f775008e093580f0c9499dfb2c485 maybe? Feb 03 16:34:06 khem: glibc effectively dropped support for older x86 cpus? Feb 03 16:35:30 RP: yeah that grub patch looks promising, .note.gnu.property has got changes to support the x86-64 ISA levels in 2.33 Feb 03 16:36:01 I dont think its dropped but defaults have changed somehow Feb 03 16:37:08 khem: I applied locally and the 132MB file is now 1024 bytes :) Feb 03 16:37:23 yay Feb 03 16:38:28 khem: and confirmed it fixed the issue with the initramfs locally Feb 03 16:38:41 khem: we can have another pass at building with these pieces included Feb 03 16:38:43 GNU_PROPERTY_X86_ISA version support has been added to toolchain recently which now we have for glibc and binutils with these upgrades and gcc 11 will introduce the needed -march options too Feb 03 16:42:24 RP: this is the patch https://sourceware.org/git/?p=glibc.git;a=commit;h=ecce11aa0752735c4fd730da6e7c9e0b98e12fb8 Feb 03 16:47:32 khem: I guess the question is why we seem to build binaries that won't run with the qemu options they're supposed to be compatible with? :/ Feb 03 16:52:00 when I do a `devtool modify , and bitbake writes ERROR: Task do_patch does not exist for target , should I just add do_patch to the recipe by hand? Feb 03 16:53:49 chrysh_: which recipe is that? Feb 03 16:54:48 I'd assume someone did a deltask do_patch instead of do_patch[noexec] = "1" Feb 03 16:55:03 or maybe you're trying to devtool modify an image recipe? Feb 03 16:57:17 qschulz: true. it's still the gcc recipe. and yes, there is a `deltask do_patch` in gcc-shared-source.inc. Feb 03 16:57:26 zeddii: thanks for the uprev, really helps! Feb 03 16:57:28 why is that there? Feb 03 16:58:15 chrysh_: gcc-source provides the source code for the gcc recipes which is extracted once and shared between the gcc recipes Feb 03 16:59:20 RP: thats a good question I am trying to find the answer to as well Feb 03 16:59:50 so its probing h/w for features and qemu is reporting perhaps less capabilities Feb 03 17:00:06 so it could be that now that ldso is doing the check Feb 03 17:00:10 RP: still, why can't I patch them? Feb 03 17:00:33 chrysh_: you can in the gcc-source recipe Feb 03 17:03:42 RP: in which situation would a person want to remove a task (in gcc)? Feb 03 17:04:20 https://pastebin.ubuntu.com/p/thSt4MP5dR/ Feb 03 17:04:37 this is how the recipe looks like. why the two ways of disabling do_fetch? Feb 03 17:04:56 chrysh_: I think the catch is that gcc is a "special" recipe because it's using the work-shared mechanism. e.g. I couldn't also build modules from a devtool modified kernel recipe IIRC. Feb 03 17:07:00 qschulz: so if I have compile time errors and would want to fix that, how would I create the patches? Feb 03 17:07:42 chrysh_: you'd add them to the gcc-source recipe Feb 03 17:08:19 unfortunately devtool doesn't work well with gcc based recipes because it uses a shared workdir and devtool doesn't understand shared workdirs Feb 03 17:08:55 RP: yet. There's always room for improvement :) Feb 03 17:09:58 qschulz: well, yes. There is an open bug but we can't seem to get anyone to work on it :( Feb 03 17:10:33 chrysh_ just volonteered :D Feb 03 17:11:09 Since the initramfs scripts might have hard dependency on the init manager (e.g. using systemctl switch-root), but the init manager choice is supposed to be done in the distro conf, how do you guys handle that? Feb 03 17:17:11 vdl: you can configure to allow sysvinit and systemd together Feb 03 17:21:04 jonmason: I dropped the libical upgrade from master-next due to the reproducibility issue, I've not replied on list though. The initramfs issues in selftest and wic builds are hopefully addressed by the grub patch I've sent and is in testing Feb 03 17:21:18 (caused by the binutils uprev) Feb 03 17:21:30 RP: what if I want systemd in the initramfs? Feb 03 17:21:48 jonmason: the genericx86-64 failure was reported on list and Bruce's patch to meta-yocto should help Feb 03 17:21:58 vdl: then depend on and include it? Feb 03 17:22:51 RP: from the initramfs image recipe? Feb 03 17:23:52 vdl: sure Feb 03 17:25:43 RP: thanks. Also, good reminder to get on the swat task :) Feb 03 17:28:05 jonmason: I did triage one of the builds out the way for you Feb 03 17:35:00 thanks Feb 03 17:39:33 hey RP (or anyone else who might know!), are we doing any tests on AB to check/ensure that package versions are 'right' (increasing?) and do we test with the pr server? Feb 03 17:48:56 i think version-going-backwards is a default warning Feb 03 19:00:46 RP: sent a v2 of glibc patch on top of current master-next Feb 03 19:48:33 RP: glibc 2.33 going in reminded me of this: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level/ Feb 03 19:49:46 RP: it seems possible that aligning oe-core qemux86-64 / genericx86-64 to match x86-64-v2 might be worthwhile to match what other distros are doing Feb 03 20:01:02 yeah speculatively :) Feb 03 20:05:15 I think if we switch to using corei7 things will happen automatically but then we know that we are dumping core2 Feb 03 20:08:00 khem: yeah, raising the default seems like fun for the TSC to discuss Feb 03 20:09:09 khem: even w/o doing that, I could maybe see adding some tuning definitions to match v1/v2/v3 to make it easier for people that want it Feb 03 20:09:52 Perhaps defaulting to v2 is good option moving forward Feb 03 20:10:05 folks who need v1 can test and let us know Feb 03 20:10:12 right Feb 03 20:11:01 the other "fun" might be trying to enable getting multiple libraries in for the hwcaps stuff Feb 03 20:11:31 I think that only matters for binaries distros Feb 03 20:11:35 seems reasonable to have a way to do both.. pre "current gen" and origin Feb 03 20:11:36 might not be a large demand for that for OE users, yeah Feb 03 20:12:20 The one thing likely needed is a way to tag which configs are v2 and v1.. I know I have atom systems I use (for home automation) that I have no idea what they count as Feb 03 20:14:07 lots of digging around on arc.intel.com, maybe ;) Feb 03 20:16:06 fray: cat /proc/cpuinfo and we can find Feb 03 20:16:37 istr some test bits in the microarchitecture reference git repo, they might have a script Feb 03 20:16:41 if it has SSE4.2 then you are v2 most probably Feb 03 20:16:44 ya, but who has access to every possible board.. like I said, I don't know what is a v2 and what isn't when it comes to the embedded stuff Feb 03 20:16:56 model name: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz Feb 03 20:17:10 flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl nonstop_tsc aperfmperf eagerfpu pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm arat Feb 03 20:17:20 I see sse2, but not '4.2' Feb 03 20:18:15 Add to that all of the AMD, Cyrix and other stuff that is still in the market.. and both are probably needed.. I'm definitely not against adding v2 support, since it really is needed for current work Feb 03 21:57:25 RP: Found a solution for the x86 issue, you can try v2 of glibc plus the enable-cet patch Feb 03 21:57:46 khem: will we see the pseudo build issue? i.e. do I need to figure that out first? Feb 03 21:57:52 khem: I've merged binutils Feb 03 21:59:05 smurray: right, I just want to ensure that the support for older stuff still works. We can and should discuss the default Feb 03 22:21:00 Can anyone direct me to a source for how to install a Python package in both python 2 and python 3? I've got a transient need to do both so I can port and test several packages to Python 3. Feb 03 22:45:33 RP: https://sourceware.org/bugzilla/show_bug.cgi?id=27318 is the issue we are facing with glibc 2.33, I have cherry-picked the proposed patch locally and see if this helps out I will send this incremental patch after that Feb 03 22:45:45 RP: yes pseudo for target will fail Feb 03 22:46:48 ichabod_crane: you need to include meta-python2 layer and then have python3-.bb and python-.bb recipes to build for each version of py Feb 03 23:03:52 khem: I'll have a go at building pseudo locally, see if I can spot what we need there Feb 03 23:07:27 ndec: we turned version going backwards off as we don't run prserv on the infra any more :( Feb 03 23:07:40 ndec: the question with upgrades is always "compared to what", that is the hard bit Feb 03 23:22:15 RP: sounds good Feb 03 23:43:08 khem: attempt at a fix in -next Feb 03 23:43:18 I have this downstream kernel that builds up to `make[2]: *** No rule to make target 'msm8909-pm8916-mpp3-hw00.dts'. Stop.` This dts is in the kernel sources in `arch/arm/boot/dts/qcom/`, and the name ("mpp3") corresponds to how the manufacturer calls the device. So it seemed correct. Feb 03 23:43:18 The way I set it is in the machine file, with `KERNEL_DEVICETREE += "msm8909-pm8916-mpp3-hw00.dts"`. I have also read posts from 2016 that suggest using a `.dtb` (instead of `.dts`) and let the build system build it from the corresponding `.dts` by using `require recipes-kernel/linux/linux-dtb.inc` in the kernel recipe. But linux-dtb.inc does not seem to exist anymore with Gatesgarth. Feb 03 23:43:19 Question: am I on the right track, or am I doing it completely wrong? 🙂 Feb 03 23:43:59 khem: https://www.spinics.net/lists/fedora-devel/msg281020.html Feb 03 23:45:41 (note that the docs refers to `linux-dtb.inc`, but I'm pretty sure I don't have it on gatesgarth 🤔: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#migration-2.4-kernel-device-tree-move) Feb 03 23:48:19 khem: did that cherry-picked patch work? Just wondering if I can start a build before sleeping! :) Feb 03 23:48:51 (also I `#inherit kernel`, which I read inherits kernel-devicetree, which is supposed to replace linux-dtb.inc. But somehow the way I specify `KERNEL_DEVICETREE += "msm8909-pm8916-mpp3-hw00.dts"` is not enough 😕 Feb 03 23:57:49 RP: https://github.com/YoeDistro/openembedded-core/commit/37ff0324e1778347525f5e1c7edca8c132b8d90e.patch Feb 03 23:57:51 :) Feb 03 23:58:36 RP: seems to work let me send Feb 04 00:00:17 RP: patch is on ml now but you need to fix the pseudo typo in master-next as well otherwise all is red Feb 04 00:04:19 khem: typo fixed :) Feb 04 00:04:53 khem: don't have your patch yet, ml is obviously being slow Feb 04 00:05:16 cool Feb 04 00:05:40 khem: is that patch in a tree anywhere? Feb 04 00:06:22 you can download it from here https://github.com/YoeDistro/openembedded-core/commit/14473d1109fc240f70a5898e07bed92ff53a0d03.patch Feb 04 00:07:10 khem: thanks, will try a build Feb 04 00:07:44 I hope 2.33 helps with intermittent build race that was reported in glibc Feb 04 00:07:53 but we should keep an eye Feb 04 00:08:14 khem: can but hope :) Feb 04 00:09:58 yeah I know even fixing reproducible issues is hard forget about intermittent ones now a days Feb 04 01:21:25 kind of surprised the LF threw in the towel completely for ELC! Feb 04 02:22:38 * jonesv[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/NzFivGjQKLnDvbBlZBwoOasj/message.txt > Feb 04 02:51:24 * jonesv[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/TsIIcVBTFyVdIcAOgNBTXlNH/message.txt > **** ENDING LOGGING AT Thu Feb 04 03:02:57 2021