14:41 <NishanthMenon> dl9pf, halstead__ logger is online on yocto -> could you update the topic to include https://libera.irclog.whitequark.org/yocto/ to indicate to folks that this channel is being logged?

15:01 <paulg> no yocti bot as of yet?

15:15 <fullstop> Is it possible to do "devtool update-recipe" *without* updating SRCREV?

15:16 <fullstop> My SRCREV is using ${PV} and I needed to make a minor change to the Makefile

15:17 <fullstop> I really wanted ${PV} to remain and add a patch to the recipe.

15:27 <JPEW> Hmm it would be nice if the buildhistory task could remove the "base path" from the task signatures so that they were more comparable

15:27 <JPEW> In particular, our CI doesn't build with fixed paths, so every line ends up different

15:32 <fray> there are other places removing the base path would be useful.. even in bitbake-diffsigs

15:32 <fray> (I always recommend to people to NOT use fixed paths, primarily because it hides problems)

15:44 <qschulz> fullstop: just create the patch and add it to the original recipe manually?

15:44 <fullstop> qschulz: I mean, technically yes

15:45 <fullstop> I was wondering if there was any way to do it with devtool but I guess that doesn't exist yet.

15:45 <qschulz> maybe? I'm not using devtool to modify my recipes so I cannot say

15:47 <fullstop> Any good suggestions on using yocto's cross compilers and such a development environment for making new recipes?

15:47 <fullstop> Kind of like bitbake -c devshell but without locking up bitbake. I'd like to use the sysroot and the cross compilers to build and eventually make a recipe using that code.

15:47 <rburton> devtool?

15:48 <fray> what I see people doing is using cross compilers to build new applications.. then use either devtool (or just doing it in a layer) for the integration. often different teams, different knowledge bases..

15:48 <fullstop> rburton: it's close

15:48 <qschulz> then SDK

15:49 <fullstop> Let's say that I have code which is used in two platforms, and there are a few changes to the Makefile

15:49 <fray> The cross compilers/SDK is produced by an "OS" person.. given to the app devs.. they dev, and work back and forth with OS folks.. then when the app is done their either integrate (create the recipe) or hand off the app to an integration / OS team..

15:50 <fullstop> I'd like to get changes merged into the same branch, but the patch generated by devtool will get merged as well since it's applied to the git tree.

15:51 <fullstop> I feel like I'm not quite explaining myself well, but devtool is 90% of what I want.

15:52 <fullstop> Maybe I should look at extracting the toolchain and sysroot for a package and using it outside of yocto.

15:52 <fray> Most of the developers in here "know too much" to use devtool, it would slow down our work. For people who aren't YP experts, then devtool can be very useful

15:53 <fray> already implemented.. bitbake core-image-minimal -c populate_sdk -- (adjust as needed) but this is what we give to our app developers..

15:53 <qschulz> fullstop: what about having a patch specific to your platform? e.g. adding your patch in a subdir named after your machine, or use SRC_URI_append_machine for the patch

15:54 <fullstop> fray: that looks very promising

16:00 <jsbronder> fullstop: I build meta-ide-support (with some extra packages appened to the list and writing a cmake toolchain file like cmake.bbclass) and then source the environment file it produces.

16:01 <fullstop> jsbronder: I'll look at that next if populate_sdk doesn't do what I think it does.

16:02 <fray> populate_sdk builds an installable SDK that matches the libraries available in an image 1:1

16:02 <fray> it does NOT include a copy of the YP build environment (devtool) like the 'eSDK' will.. (populate_sdk_ext)

16:03 <fray> so the app developer has to deploy (for test) their own way with an SDK.. while the eSDK has devtool and can help them generate new images, etc -- but it's much larger

19:38 <ecdhe> How can I override oe_runmake running more jobs than BB_NUMBER_THREADS?

19:40 <zeddii> add -j <whatever you want> ?

19:40 <zeddii> assuming Make that is :D

19:40 <ecdhe> Was hoping to override it globally

19:52 <RP> ecdhe: set PARALLEL_MAKE

20:23 <paulg> that reminds me ; we probably should move the || options from the largely ignored sample file to be commented out options in the autocreated default so they are easily tweaked/enabled

20:24 <paulg> I always have to go looking for them in a new build/machine-deploy to ensure I don't fark up the spealing.

21:34 <manuel1985> I'm setting up CI for yocto. Do you people keep the TMPDIR between builds?

21:44 <JPEW> manuel1985: TMPDIR no. Share you sstate though

21:45 <manuel1985> JPEW: Alright, thought so. Thanks.

22:11 <JaMa> manuel1985: depends on the build, for some faster incremental CI builds I'm sharing TMPDIR as well (so that the build of big image doesn't spend most of the time unpacking the same sstate during every run)

22:13 <JaMa> JPEW: I have a question about your last bitbake fix https://lists.openembedded.org/g/bitbake-devel/message/12343 does this happen always or only rarely? I'm seeing bitbake hanging after early parsing errors (typically b.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Unable to resolve 'foo' in

22:13 <JaMa> upstream git repository in git ls-remote output for ...

22:14 <JaMa> but it's quite rare and I haven't found a reliable way to trigger this yet

22:15 <JPEW> It seems like it's always

22:16 <JPEW> It came up a lot in the YP summit when the students would mistype something

22:16 <JaMa> rm -rf tmp-glibc cache/ __pycache__/; bitbake --runall=write_bom_data lib32-some-big-image; in for loop was able to eventually reproduce it, but when I try to replicate it on something smaller with less layers it doesn't happen (or I wasn't patient enough)

22:17 <tlwoerner> fullstop: maybe you want "devtool modify …"

22:18 <JPEW> JaMa: Interesting. It could be related... Its caused by the client not sending an message to the server, perhaps there is something else that could cause it

22:19 <JPEW> Something more likely with a lot of layers

22:19 <tlwoerner> fullstop: it unpacks the sources in workspace, edit the sources, make a commit, then "devtool finish …" and the recipe gets updated automatically with the patch(es)

22:19 <JaMa> it left 3 processes behind, strace -p shows:

22:19 <JaMa> select(12, [10 11], [], [], {tv_sec=30, tv_usec=0}) = 0 (Timeout)

22:19 <JaMa> 2nd one:

22:20 <JaMa> futex(0x12e9930, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1622142706, tv_nsec=509127000}, 0xffffffff) = -1 ETIMEDOUT (Connection timed out)

22:20 <JaMa> 3rd:

22:20 <JaMa> read(20,

22:21 <JPEW> JaMa: The defining characteristic was that bitbake-server didn't exit and you had to kill it...I didn't look for other processes

22:21 <JaMa> ok, possibly different path then, here bitbake-server is already gone

22:22 <JPEW> Probably then

22:22 <JPEW> Sorry :)

22:22 <JaMa> will continue to debug this, it's also worth noting that I see it on dunfell, but that's just because most our developers produce those parsing errors on dunfell based builds :)

22:23 <JaMa> no problem, thanks anyway