Linux-toradex produces artifact names containing the string "AUTOINC"

We are using a customized yocto image based on the the toradex-manifest.

After upgrading our manifest from 50fbf92e2b38605d1e80d736eef763f91e480e4e to d62c42de093b248fbeecb4ace72b609ae2094a59 there is an issue with the names of the files produced by meta-toradex-nxp/recipes-kernel/linux/linux-toradex_5.4-2.3.x.bb. All names contain the string “AUTOINC”:

SPL-colibri-imx6-mender-2020.07+gitAUTOINC+4baed78646-r0-spl-2020.07+gitAUTOINC+4baed78646-r0
fw_env.config-colibri-imx6-mender-2020.07+gitAUTOINC+4baed78646-r0
imx6dl-colibri-aster--5.4.193+gitAUTOINC+eb8d1c92da-r0.0-colibri-imx6-mender-20240315072744.dtb
imx6dl-colibri-cam-eval-v3--5.4.193+gitAUTOINC+eb8d1c92da-r0.0-colibri-imx6-mender-20240315072744.dtb
imx6dl-colibri-eval-v3--5.4.193+gitAUTOINC+eb8d1c92da-r0.0-colibri-imx6-mender-20240315072744.dtb
imx6dl-colibri-iris--5.4.193+gitAUTOINC+eb8d1c92da-r0.0-colibri-imx6-mender-20240315072744.dtb
imx6dl-colibri-iris-v2--5.4.193+gitAUTOINC+eb8d1c92da-r0.0-colibri-imx6-mender-20240315072744.dtb
modules--5.4.193+gitAUTOINC+eb8d1c92da-r0.0-colibri-imx6-mender-20240315072744.tgz
u-boot-initial-env-colibri-imx6-mender-spl-2020.07+gitAUTOINC+4baed78646-r0
u-boot-spl-2020.07+gitAUTOINC+4baed78646-r0.img
zImage--5.4.193+gitAUTOINC+eb8d1c92da-r0.0-colibri-imx6-mender-20240315072744.bin

As this issue did not exist in commit 50fbf92e2b38605d1e80d736eef763f91e480e4e maybe you can help me to find out what modifications on your side caused this change of behavior and how I can fix this on my side.

Our *.bbappend file was based on recipes-kernel/linux/linux-toradex_5.4-2.1.x.bb and is now based on recipes-kernel/linux/linux-toradex_5.4-2.3.x.bb.

To see the differences I used this line in meta-toradex-nxp:

git diff fa41855fb9a79718aa16b8e76b0255a40e8d16f3 -- recipes-kernel/linux/linux-toradex_5.4-2.1.x.bb d7075d95ca68661d0e95f5324a19e0397d6b1a45 -- recipes-kernel/linux/linux-toradex_5.4-2.3.x.bb

But this shows no changes which seem to be relevant to this issue.

Seems like I solved it for linux-toradex (but I have still check if it has some unwanted side effects).

Inspired by commit b97a88c0cb100e059673cbcc75ac79ef0eb24f39 in meta-toradex-nxp I added this line to my recipes-kernel/linux/linux-toradex_5.4-2.3.x.bbappend file:

# Remove AUTOINC from PV="5.4.193+gitAUTOINC+498c1d54ef"
PV ="${LINUX_VERSION}+git${@'${SRCPV}'.replace('AUTOINC+', '')}"

And to recipes-bsp/u-boot/u-boot-toradex_%.bbappend:

# Remove AUTOINC from PV="2020.07+gitAUTOINC+4baed78646"
PV = "2020.07+git${@'${SRCPV}'.replace('AUTOINC+', '')}"

I could not find out which variable defines 2020.07, but for now it will do.

Hi @lmoellendorf !

From what you shared, you are using the head of dunfell-5.x.y, right?

This release is not tagged.

You should get fixed version strings (no AUTOINC) from tagged releases. For example, you could use toradex-manifest.git - Repo manifest for Toradex Embedded Linux TorizonCore and BSP layer setup for Yocto Project/Openembedded, which is currently the latest tagged release (5.7.5) for BSP 5.

Or, if possible for you, you could migrate to BSP 6 :slight_smile:

Best regards,

You should get fixed version strings (no AUTOINC) from tagged releases.

Do I understand correctly that AUTOINC is replaced if the the checked out manifest is tagged?

But if I base our custom manifest on yours, I get a merge commit “Merge tag ‘5.7.5’ into …” which is not tagged. So AUTOINC won’t be replaced in this case?

Could you please point me to a documentation of this AUTOINC feature is explained? And/or to the script where this AUTOINC replacement takes place?

I need to get a better understanding to decide how to proceed.

Hi @lmoellendorf !

To get more information about OpenEmbedded/Yocto/Bitbake, the best place is their documentation.

Here are some direct links I found:

Also, is it possible that you enabled the use-head-next in your build? As an example, from the link below, we can see that using it will enable the AUTOREV for SRCREV.

Best regards,

Also, is it possible that you enabled the use-head-next in your build? As an example, from the link below, we can see that using it will enable the AUTOREV for SRCREV.

I enabled AUTOREV in our kernel’s *.bbappend for development.

Thanks for the links. I learned that I can add PRSERV_HOST = "localhost:0" to my local.conf in order to start the PR server. It works locally, but it does not work on our CI server.

For now I will use the workaround mentioned above.

Hi @lmoellendorf!

Thanks for the feedback!

Have a nice day!