Bug 11501

Cannot reproduce the issue. Tested with bitbake nufs3 and nativesdk-nufs3. Both successful fetch and build. Try to clean before bitbake
bitbake nufs3 -c cleanall
bitbake nativesdk-nufs3 -c cleanall

A quick test on my end shows, that it builds with my patched version.

Version: 0.9.22.r497-r0

bitbake -c cleanall unfs3
bitbake unfs3

bitbake -c cleanall nativesdk-unfs3
bitbake nativesdk-unfs3

But I just did this:

wget http://downloads.yoctoproject.org/mirror/sources/trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz

md5sum trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz
2e43e471c77ade0331901c40b8f8e9a3  trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz

sha256sum trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz
21009468a9ba07b72ea93780d025a63ab4e55bf8fc3127803c296f0900fe1bac  trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz

So it looks like your original checksums are OK.

No idea where I get the different checksum from.

Will further investigate, but this worries me.

Maybe somewhere in my SSTATE or DL caching server?

I found the version with a different checksum on my source caching server.

md5sum trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz-from-source-cache trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz-from-wget
db06a7cdb1c0752d12f45be4e5520d5d  trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz-from-source-cache
2e43e471c77ade0331901c40b8f8e9a3  trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz-from-wget


sha256sum trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz-from-source-cache trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz-from-wget
0872a96910d1df779390f74375cb50cd2df1c5d9d1ffb016aff596384fdff409  trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz-from-source-cache
21009468a9ba07b72ea93780d025a63ab4e55bf8fc3127803c296f0900fe1bac  trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz-from-wget

I extracted the 2 tarballs and compared the results.

diff -r from-source-cache from-wget

they are identical!

A possible explanation would be, that morty fetched from:

svn://svn.code.sf.net/p/unfs3/code;module=trunk;rev=${MOD_PV};protocol=http

SRC_URI[md5sum] = "3687acc4ee992e536472365dd99712a7"
SRC_URI[sha256sum] = "274b43ada9c6eea1da26eb7010d72889c5278984ba0b50dff4e093057d4d64f8"

see:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/unfs3/unfs3_0.9.22.r497.bb?h=morty

while pyro fetches from:

http://downloads.yoctoproject.org/mirror/sources/trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz

SRC_URI[md5sum] = "2e43e471c77ade0331901c40b8f8e9a3"
SRC_URI[sha256sum] = "21009468a9ba07b72ea93780d025a63ab4e55bf8fc3127803c296f0900fe1bac"

see:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/unfs3/unfs3_0.9.22.r497.bb?h=pyro

First conclusion:

It looks like on the same tarball with different checksums exists. I suggest that instead of a tarball a subversion checkout should being used.

---

On further investigation I saw that it's fetched from

http://downloads.yoctoproject.org/mirror/sources/trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz

and not from upstream

so I tried:
svn co svn://svn.code.sf.net/p/unfs3/code;module=trunk;rev=497;protocol=http

And it turns out, that the tarball on the yoctoproject mirror is not the same with what's under subversion:

diff -r from-wget/ code/trunk
Only in code/trunk: aclocal.m4
Only in code/trunk: afsgettimes.c
Only in code/trunk: afssupport.c
Only in code/trunk: afssupport.h
Only in code/trunk: attr.c
Only in code/trunk: attr.h
Only in code/trunk: backend.h
Only in code/trunk: backend_unix.h
Only in code/trunk: backend_win32.h
Only in code/trunk: bootstrap
Only in code/trunk: BRANCHES
Only in code/trunk: Config
Only in code/trunk: configure.ac
Only in code/trunk: contrib
Only in code/trunk: CREDITS
Only in code/trunk: daemon.c
Only in code/trunk: daemon.h
Only in code/trunk: doc
Only in code/trunk: error.c
Only in code/trunk: error.h
Only in code/trunk: Extras
Only in code/trunk: fd_cache.c
Only in code/trunk: fd_cache.h
Only in code/trunk: fh.c
Only in code/trunk: fh_cache.c
Only in code/trunk: fh_cache.h
Only in code/trunk: fh.h
Only in code/trunk: indent-all
Only in code/trunk: install-sh
Only in code/trunk: LICENSE
Only in code/trunk: locate.c
Only in code/trunk: locate.h
Only in code/trunk: Makefile.in
Only in code/trunk: md5.c
Only in code/trunk: md5.h
Only in code/trunk: mount.c
Only in code/trunk: mount.h
Only in code/trunk: NEWS
Only in code/trunk: nfs.c
Only in code/trunk: nfs.h
Only in code/trunk: password.c
Only in code/trunk: password.h
Only in code/trunk: readdir.c
Only in code/trunk: readdir.h
Only in code/trunk: README
Only in code/trunk: README.nfsroot
Only in from-wget/: trunk
Only in code/trunk: unfs3.spec
Only in code/trunk: unfsd.8
Only in code/trunk: unfsd.init
Only in code/trunk: user.c
Only in code/trunk: user.h
Only in code/trunk: winerrno.h
Only in code/trunk: winsupport.c
Only in code/trunk: winsupport.h
Only in code/trunk: xdr.c
Only in code/trunk: xdr.h

I am a bit confused as how this tarball was created.

Can you please clarify?

FYI the reason we switched to a tarball snapshot is this was the last remaining subversion-native dependency in a normal build for qemu machines, and for something that changes relatively infrequently it seemed superfluous.

I suspect the issue here is if you'd already generated the tarball locally, the new one (generated on a different machine) wouldn't have the same checksums. However, I can't explain why the content is different to the repository. I would have assumed it was just a mirror tarball that bitbake created after fetching from svn at revision 497.

I tested 2 source both are identical.
wget http://downloads.yoctoproject.org/mirror/sources/trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz

This link will download as trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz
We use tar zxvf trunk_svn.code.sf.net_.p.unfs3.code_497_.tar.gz to untar it and the folder name is trunk/.

Continue download with the svn source:-
svn co svn://svn.code.sf.net/p/unfs3/code;module=trunk;rev=497;protocol=http

The downloaded source will be name code/ folder. Now we got folder trunk/ and folder code/. We only wish to compare folder trunk/ because the main source is only in trunk folder. Therefore, the diff command as below:-
diff -r code/trunk/ trunk/ - (1st is code from svn, 2nd is code from yoctoproject download link)

And result both folder content is identical. Please verify the diff path. Only compare with the trunk/ folder.

I confirm it's the same.

Somehow one of my yocto builds created a tarball with a different checksum, but the same content and my scripts copied this over to my SOURCE_MIRROR server.

After I removed the file with the other checksum from my SOURCE_MIRROR server all is fine.

Well, it's not quite fixed - we should still rename the tarball and update the recipe to match so that anyone else with their own source mirror tarball doesn't hit this.

As Paul suggests I reopen it.

(In reply to comment #8)
> As Paul suggests I reopen it.

I already change the SRC_URI with updated source without SVN to avoid confuse as suggested by Paul.

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4063637e687f388131914c4f85cadb71e9048bb2