02:32 <geoff_> halloy4743: It depends if you use a package manager like opkg, rpm, etc. to update your packages on a target. If so you should use a PR server and set PV = "1.0+git${SRCPV}" in your AUTOREV recipes so the package versions increase via the AUTOINC placeholder varialble. (AUTOINC is not the same as AUTOREV). You can use AUTOREV without a PR service running. bitbake will query the repo of each AUTREV recipe during the build and download

02:32 <geoff_> the latest recipe if necessary. See section 25.2.3 of the yocto documentation. https://docs.yoctoproject.org/dev-manual/packages.html#automatically-incrementing-a-package-version-number

03:19 <mischief> after a few years of personal experience using AUTOREV, i would suggest not using it.

04:21 <khem> stgl: maybe halstead can help ?

04:23 <khem> Tyaku: are you building using OE buildsystem or using the SDK generated out of OE builds

09:45 <Najjar> Hello eveyone,

09:45 <Najjar> I have a quick question regarding the virtual/kernel recipe.

09:45 <Najjar> What causes the WORKDIR to be cleaned automatically and work-shared removed after building the kernel ?

09:45 <Najjar> I am not inherting rm_work also.

10:18 <Tyaku> khem: I was using the toolchain generated by Yocto, to build externally. But the problem is fixed: To build kernel modules using the toolchain, we firstly need to "prepare" the toolchain for it with 'make scripts prepare' command in toolchain_dir/sysroots/cortexa55-poky-linux/lib/modules/5.10.201-cip41-yocto-standard/build

18:31 <halloy4743> geoff_: Currently not using a package manager at all. Working with a yocto project I inherited. The AUTOREV is used in the recipes for our private application git repos that are built in our layer

18:34 <halloy4743> In general PV ends up as e.g. 3.0.3+gitAUTOINC+25efc6ade8, where the checksum is the git commit

18:36 <halloy4743> But in one odd case PV ends up as: 0.10.8+gitAUTOINC+_c025a727f1_9693c926d8_f6a588d8d8, but I don't understnd why there are three checksums there.

18:36 <halloy4743> And Using AUTOREV just to add the label "AUTOINC" to that PV seems pointless.

18:38 <halloy4743> Like I said I'm new to this so there is plenty that doesn't make sense to me yet. I want the git commit hash in the PV, but not the AUTOINC label (?)

19:01 <khem> Najjar: everything under TMPDIR is treated ephemeral by the build system. So any change that requires sources to be modified that can result in do_unpack/do_patch to be rerun which will remove the sources and create then afresh and rerun followup tasks as well e.g. configure/compile/install etc.

19:02 <khem> Najjar:if you want sources to persist, look into devtools method of setting up external tree for a recipe during development

19:03 <khem> halloy4743: AUTOREVs are not recommended in general, they are a convenience for developers for short term activities perhaps to run a tight CI loop or some such

19:04 <khem> halloy4743:those underscores that you see in PV are due to multiple SRC_URIs

19:06 <khem> e.g. see https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/breakpad/breakpad_2023.06.01.bb

19:06 <khem> it has multiple git repos being checked out

19:07 <khem> and then it adds SRCREV_FORMAT which is responsible to add these versions between underscores for each repo referred to by name= in SRC_URI

19:11 <khem> to get rid of AUTOINC you need to enable PR server which will replace it with a number which is always incremented on rebuild of that package

19:12 <khem> you can set something like PRSERV_HOST ?= "localhost:0" in local.conf if you do not have central PR server

19:20 <JerryM> anyone who knows if the tickets for openembedded workshop at fosdem are all sold out or whether there will be more available later?

19:35 <khem> JerryM:reach out to Phil Balister

19:48 <geoff_> halloy4743: I agree with mischief, after many years of using AUTOREV on a project I inherited, I wish we ditched it long ago and switched to using fixed SRCREV hashes. I plan to switch over this year. It's like quiting a bad habit. The best way to quit is never start it in the first place :-).

19:54 <mischief> we have way too many and it makes the build slow as hell, and the build often breaks when people update the code being built

20:00 <khem> think of amounts of git ls-remotes you are doing as a result for no reason.

20:01 <khem> your git servers will be inundated as you scale

20:02 <khem> AUTOREV impacts are multifold with one convenience, that build system will automagically include your changes

20:15 <mischief> khem: i am acutely aware but other people don't want to change it.

20:20 <khem> I know a case where they have to keep putting more compute and more morrors for gerrit because builds were pouding the server and git access became so slow for everyone

20:26 <mischief> we use github, but i would probably be annoyed by us if i was github

23:25 <halstead> stgl: Please forward the rejection notice email to helpdesk@yoctoproject.org with the address you subscribed to openembedded-core list with.