I've been running into "Fetcher failures" for my recipes using mercurial recently. They only seem to crop up the first time a package that comes from a hg repo is fetched.
I believe the issue stems from the combination of the arguments used by the hg fetcher and the fact that I specified a tag rather than revision number. I've included a "trimmed" log at the end of this post, where I've pruned out useless and personal information. Here are some of of my comments and questions. I'm no mercurial expert, so please do correct me if and where I'm wrong! - Why is GIT_CONFIG being exported for mercurial invocations? - I think the 'clone -r v1.1.0' followed by the 'update -C -r v1.1.0' is possibly responsible for the failure. - In mercurial, the tag is a commit after the revision that's being tagged. tip 41:58b8f368be68 v1.1.0 40:a925b596c163 v1.0.4 39:6bf84da2571e - In the above, rev 41 contains the action of tagging 40 as 'v1.1.0' - Therefore, if we clone the version associated with tag v1.1.0, we get rev 40 and earlier. At this point, there's no "knowledge" of there being a 'v1.1.0' tag! - As such, the 'hg update -C -r v1.1.0' that follows the 'hg clone -r v1.1.0' fails. - One possible fix might be to remove the "-r <rev>" usage from the hg fetcher. (lines 101 and 102 in bitbake/lib/bb/fetch2/hg.py) - A fetch always follows an update to the revision anyway, doesn't it. (Per comment @ lines 142-143). - Con: You have to fetch the whole darn repo. It makes sense that we wouldn't want to do that when we don't have to. :) - Pro: You'll have the revision you wanted. - Disclaimer: I'm not familiar enough with this code to know whether this would cause undesired side effects or break things! - Workaround: Don't use tags in SRCREV - This stinks, because I like to write my .bb's as follows, so that updating a version is just a matter of copy/renaming the .bb require <my_package>.inc PR = "${INC_PR}.0" SRCREV = "v${PV}" DEBUG: Fetch: checking for module directory '/export/home/jon/projects/yocto/poky/build/test/downloads/hg/host/some_dir/my_package' NOTE: Fetch hg://hg@host/some_dir;module=my_package;protocol=ssh DEBUG: Running /usr/bin/env hg clone -r v1.1.0 ssh://hg@host/some_dir/my_package my_package DEBUG: Fetcher accessed the network with the command /usr/bin/env hg clone -r v1.1.0 ssh://hg@host/some_dir/my_package my_package DEBUG: Running export HOME="/export/home/jon"; export SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK="<snipped>"; export GIT_CONFIG="<snipped>/gitconfig"; export PATH="<snipped>"; /usr/bin/env hg clone -r v1.1.0 ssh://hg@host/some_dir/my_package my_package DEBUG: Running /usr/bin/env hg update -C -r v1.1.0 DEBUG: Running export HOME="/export/home/jon"; export SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK="<snipped>"; export GIT_CONFIG="<snipped>/gitconfig"; export PATH="<snipped>"; /usr/bin/env hg update -C -r v1.1.0 WARNING: Failed to fetch URL hg://hg@host/some_dir;module=my_package;protocol=ssh, attempting MIRRORS if available DEBUG: Fetcher failure: Fetch command failed with exit code 255, output: abort: unknown revision 'v1.1.0'! DEBUG: Python function base_do_fetch finished DEBUG: Python function do_fetch finished ERROR: Function failed: Fetcher failure for URL: 'hg://hg@host/some_dir;module=my_package;protocol=ssh'. Unable to fetch URL from any source. Thank you, Jon _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto