Git rev: master/f19b4e995ea47f9243f152b39337330307453c9f I found the bitbake doesn't check the m5d and sha256 checksum for source tarball if the tarball and .done file already exist in download directory in some case. Here is a simple example for connman: 1. bitbake connman 2. Set invalid md5 and sha256 checksums in connman bb file. 3. bitbake connman -c cleansstate 4. bitbake connman Looks like the bitbake doesn't check the checksum and it can be built without errors. Another example is a little complex. The current connman version is 1.25 in master and I want to downgrade to 1.24: Steps: 1. Make sure the source tarball and .done file are in the download directory $ ls downloads/connman-1.24.tar.xz* -l -rw-r--r-- 1 builder builder 629616 Jun 8 02:59 downloads/connman-1.24.tar.xz -rw-r--r-- 1 builder builder 0 Nov 3 16:21 downloads/connman-1.24.tar.xz.done 2. mv meta/recipes-connectivity/connman/connman_1.25.bb to meta/recipes-connectivity/connman/connman_1.24.bb Do not change any lines in the bb file, that means the SRC_URI[md5sum] and SRC_URI[sha256sum] are for 1.25, not for 1.24 3. bitbake connman The connman 1.24 can be built without any errors. I need to clean the source tarball by using: bitbake connman -c cleanall And run: bitbake connman Then the checksum error occurs: ############# WARNING: Checksum failure encountered with download of http://kernel.org/pub/linux/network/connman/connman-1.24.tar.xz - will attempt other sources if available WARNING: Renaming /buildarea3/yzhao1/poky-build/build-qemux86-64/downloads/connman-1.24.tar.xz to /buildarea3/yzhao1/poky-build/build-qemux86-64/downloads/connman-1.24.tar.xz_bad-checksum_dd6e1b4d9b9a28d127edb9f9b58bdec1 ERROR: Checksum failure fetching http://kernel.org/pub/linux/network/connman/connman-1.24.tar.xz ############### If I change the SRC_URI[md5sum] and SRC_URI[sha256sum] to 1.24 in bb file and move the bb file to connman_1.25.bb, the connman 1.25 also can be built.(the 1.25 source tarball and .done file already exist in download directory).
This is currently expected behaviour. There is an enhancement open relating to changing the behaviour though, therefore I'm marking this one as a duplicate of that. *** This bug has been marked as a duplicate of bug 5571 ***