Each of the fetcher backends makes some assumptions about what it considers to be "the same". For tarballs from whatever source this is easy and we use the hash of the tarball. For git, we work off

Right, now I see what you mean. The build process does not rely on static metadata in the source tree to determine the version, and is instead poking the git checkout to determine what the version is?

This platform has been removed from master, and is therefore not in M3. cu Adrian

Hi Alexander, thanks for your message. I will try to explain my issue once again, since it still seems not clearly formulated. We build our images on CI (Jenkins). There, we have a shared download

Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-3.1_M3.rc1. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1.

Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-3.1_M3.rc1. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1.

From: Aaron Chan <aaron.chun.yew.chan@...> Signed-off-by: Aaron Chan <aaron.chun.yew.chan@...> --- config.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.py

From: Aaron Chan <aaron.chun.yew.chan@...> Signed-off-by: Aaron Chan <aaron.chun.yew.chan@...> --- config.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.py

A build flagged for QA (yocto-3.1_M3.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1_M3.rc1 Build hash information: bitbake:

We have a legacy device with following configurations: Chipset Architecture : Intel NM10 express OS : Yocto warrior CPU : Atom D2250 Dual Core Volatile Memory : 2GB DDR3 CPU core : 4 I have

'devtool upgrade' updates SRCREV to match the version tag that you specify: devtool upgrade -V <tag> If you omit -V, it will upgrade to the latest tag. It updates PV as well. Why is it unsuitable for

Hi Alexander, does it solve the Problem of a SRCREV, that has been fetched (for example for a _git testbuild) and now gets a tag applied and build with the _<version> build. The problem is *not* that

Hi, I want to add a feature "autologin" to the core-image-base. I created a new layer for auto login as "meta-autologin" in the poky and added some sample script to run in the auto login. When I build

You can trivially script SRCREV updates ('devtool upgrade'/'devtool finish'). The disadvantage of using tags is that you lose reproducibility, as tags can be moved or deleted, and so I wouldn't

Hi Denys, 1) Would SRCREV not be affected by this as well? When the same hash is read, then no update of the repository (esp. the tags) is done. Or can you be sure this is not the case? 2) It allows

You have been invited to the following event. Yocto Project Technical Team Meeting When Monthly from 8am to 9am on the third Tuesday Pacific Time - Los Angeles Where Zoom Meeting:

Self answering below. Op 22-02-2020 om 16:06 schreef Ferry Toth: the emmc compared to separate partitions. And it allows multiple versions of the rootfs in the same pool. btrfs image and taking the

That was mainly addressed to JH. :) -- Regards, Andrey.

This was a rhetorical question - no answer was required. Exactly my point.