4426 2013-04-29 06:10:27 +0000 ghostscript: do_fetch failed due to checksums mismatch 2013-05-02 11:30:22 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.5 x86 Multiple RESOLVED NOTABUG Medium normal 1.5 M1 1 liezhi.yang liezhi.yang meta.mr.watcher meta.watcher richard.purdie sgw --- --- --- oldest_to_newest 32702 0 liezhi.yang 2013-04-29 06:10:27 +0000 ERROR: Checksum failure fetching http://downloads.ghostscript.com/public/ghostscript-9.05.tar.gz DEBUG: Python function base_do_fetch finished DEBUG: Python function do_fetch finished ERROR: Function failed: Fetcher failure for URL: 'http://downloads.ghostscript.com/public/ghostscript-9.05.tar.gz'. Checksum mismatch! File: '/build/time3/../share/downloads/ghostscript-9.05.tar.gz' has md5 checksum c33b6cc7cfe3099cbc5a3f241df4397b when f7c6f0431ca8d44ee132a55d583212c1 was expected File: '/build/time3/../share/downloads/ghostscript-9.05.tar.gz' has sha256 checksum 02b5c08a24bd70dc1a66e902889ba2394c44cc847b920b23eaeeeeab0ab76292 when 593f77f7584704bdf9de41598a084a4208c3ad3b940a1de1faaf8f59a15cc207 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[md5sum] = "c33b6cc7cfe3099cbc5a3f241df4397b" SRC_URI[sha256sum] = "02b5c08a24bd70dc1a66e902889ba2394c44cc847b920b23eaeeeeab0ab76292" Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified. This patch will fix the problem: diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.05.bb b/meta/recipes-extended/ghostscript/ghostscript_9.05.bb index 9ec5712..2a104e5 100644 --- a/meta/recipes-extended/ghostscript/ghostscript_9.05.bb +++ b/meta/recipes-extended/ghostscript/ghostscript_9.05.bb @@ -35,8 +35,8 @@ SRC_URI_class-native = "${SRC_URI_BASE} \ file://ghostscript-native-fix-disable-system-libtiff.patch \ " -SRC_URI[md5sum] = "f7c6f0431ca8d44ee132a55d583212c1" -SRC_URI[sha256sum] = "593f77f7584704bdf9de41598a084a4208c3ad3b940a1de1faaf8f59a15cc207" +SRC_URI[md5sum] = "c33b6cc7cfe3099cbc5a3f241df4397b" +SRC_URI[sha256sum] = "02b5c08a24bd70dc1a66e902889ba2394c44cc847b920b23eaeeeeab0ab76292" EXTRA_OECONF = "--without-x --with-system-libtiff --without-jbig2dec --without-jasper \ --with-fontpath=${datadir}/fonts --with-install-cups --without-libidn" P.S., I'm on holiday now, will send the PR on Thursday. 32732 1 sgw 2013-04-29 17:49:26 +0000 The more important question is why did the checksum change? That's the whole purpose of having these. If no update occurred then the the upstream tarball might be corrupted or changed, can you verify against the tarball on the Autobuilder? 32745 2 liezhi.yang 2013-04-30 02:03:46 +0000 (In reply to comment #1) > The more important question is why did the checksum change? That's the > whole purpose of having these. If no update occurred then the the upstream > tarball might be corrupted or changed, can you verify against the tarball on > the Autobuilder? (In reply to comment #1) > The more important question is why did the checksum change? That's the > whole purpose of having these. If no update occurred then the the upstream > tarball might be corrupted or changed, can you verify against the tarball on > the Autobuilder? Thanks for the hints, yes, I'm also curious about this, I will check it when I arrive at the office on Thursday. 32841 3 liezhi.yang 2013-05-02 11:30:22 +0000 (In reply to comment #1) > The more important question is why did the checksum change? That's the > whole purpose of having these. If no update occurred then the the upstream > tarball might be corrupted or changed, can you verify against the tarball on > the Autobuilder? It seems that this is caused by China's GFW, I also noticed this error on other machines (not the auto builder), but it showed me another checksum, not the one in the .bb file or the one that had show before, so I will close this bug.