From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Reexecuting do_fetch after do_unpack failed with reference is not a tree
Date: Wed, 24 Apr 2013 10:08:26 +0100 [thread overview]
Message-ID: <1366794506.23738.94.camel@ted> (raw)
In-Reply-To: <20130424084615.GG3217@jama>
On Wed, 2013-04-24 at 10:46 +0200, Martin Jansa wrote:
> Hi,
>
> I guess this will be hard to fix correctly, but please comment if I've
> overlooked something:
>
> 1) update foo git repository with new commit ABCD, but forget to push it
> 2) bump SRCREV in foo.bb to ABCD
> 3) run bitbake foo, it will run do_fetch to catch new changes in remote
> repo, but ABCD is not there, so do_unpack will fail like this:
>
> NOTE: Running task 2289 of 4227 (ID: 1185, foo.bb, do_unpack)
> NOTE: recipe foo-1.0+gitr2+ABCD: task do_unpack: Started
> ERROR: Function failed: Fetcher failure: Fetch command failed with exit code 128, output:
> fatal: reference is not a tree: ABCD
>
> 4) realize missing "git push" in step 1) and push it now
> 5) run bitbake foo again, but do_unpack is still failing, because
> do_fetch checksums is the same (nothing changed in metadata) so stamp
> is still valid.
>
> 6) fix it with "bitbake -c fetch -f foo", but that could be complicated
> if bump SRCREV was pushed already and possibly many builders already
> executed do_fetch, so maybe push PR bump or something like that.
>
> Only better solution than 6) I can think of, is to detect
> "fatal: reference is not a tree" in do_unpack and if it's git repository
> then remove do_fetch stamp and hope it was fixed in remote git repo.
I'd say do_fetch should detect that the specified revision isn't present
and fail there and then in do_fetch.
Cheers,
Richard
prev parent reply other threads:[~2013-04-24 9:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 8:46 Reexecuting do_fetch after do_unpack failed with reference is not a tree Martin Jansa
2013-04-24 9:08 ` Paul Eggleton
2013-04-24 9:08 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1366794506.23738.94.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.