I have been thinking about this, and also tried to reproduce it, unsuccessfully...
If fetch is deemed successful, it is stored in the shared state cache, and then it is not repeated until the relevant signature changes - I think this is the metadata reference you found. However as long as the download folder's content is only modified by one project only, it supposed keep track of it fine. One question about the DL_DIR: is it possible that it is shared between multiple projects, while keeping separate shared state cache? Or that the DL_DIR's content modified manually? The shared state cache supposed to keep track of what is downloaded by bitbake and what is not, but if the DL_DIR's content is changed without bitbake (or by a separate bitbake), that can break the shared state, and cause such issues. On 12/4/25 22:41, christian.leeb via Lists.Yoctoproject.Org wrote: > I'm using Yocto 4.0, kirkstone. > > We set > URI is > git://dev.azure.com/PG-CT/PGLinux/_git/pg-linux;protocol=https;branch=pg-am57xx-ti-rt-linux-5.4.106 > SRCREV="7818dfe57e1d1e2d2eaf039d1231560611811d67" > BRANCH="pg-am57xx-ti-rt-linux-5.4.106" > > The DL_DIR contains above repo > (git2/dev.azure.com.PG-CT.PGLinux._git.pg-linux) and above branch but > just not the latest commit of this branch. > Also, between > recipe linux-ti-staging-rt-5.4.106+gitAUTOINC+7818dfe57e-r7a.spark10: > task do_fetch: Started > and > recipe linux-ti-staging-rt-5.4.106+gitAUTOINC+7818dfe57e-r7a.spark10: > task do_fetch: Succeeded > there is only a few seconds. Another proof IMHO that there was no > network access. > > Fetch works properly if the repo is not present at all in the DL_DIR. > > I also check if shallow clone is set: seems that this is not the case > unless there is some other setting to consider. > > bitbake virtual/kernel -e | grep ^BB_GIT_SHALLOW > BB_GIT_SHALLOW:pn-binutils="1" > BB_GIT_SHALLOW:pn-binutils-cross-arm="1" > BB_GIT_SHALLOW:pn-binutils-cross-canadian-arm="1" > BB_GIT_SHALLOW:pn-binutils-cross-testsuite="1" > BB_GIT_SHALLOW:pn-binutils-crosssdk-x86_64-spark-linux="1" > BB_GIT_SHALLOW:pn-binutils-native="1" > BB_GIT_SHALLOW:pn-glibc="1" > > In addition I got this info from the internet: > /Why do_fetch didn’t update the repo:/ > /BitBake’s fetcher logic:/ > /If the repo exists in DL_DIR and the SRCREV is marked as available > (based on metadata), it skips network fetch./ > /It doesn’t *verify the actual commit presence during do_fetch*—that > check happens in do_unpack./ > /So the 2-second fetch means it reused the cached repo without pulling > new commits./ > > I wonder what it means "/SRCREV is marked as available (based on > metadata)/". It's obviously not there. > > Thanks a lot for your support. > > Chris >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#66091): https://lists.yoctoproject.org/g/yocto/message/66091 Mute This Topic: https://lists.yoctoproject.org/mt/116612004/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
