Re: do_fetch: Fetcher failure: Unable to find revision bd340b0f7370015791413ea458c0f56715f17e19

Bas Mevissen

On 21/11/2017 14:31, Otavio Salvador wrote:
On Tue, Nov 21, 2017 at 11:26 AM, Bas Mevissen <abuse@...> wrote:
On 21/11/2017 12:03, Otavio Salvador wrote:

Hello Mans,

On Tue, Nov 21, 2017 at 4:02 AM, Måns Zigher <mans.zigher@...>


I am experiencing the do_fetch failure when trying to build for
PICO-PI-IMX7D. When trying to manually checkout the revision
bd340b0f7370015791413ea458c0f56715f17e19 I get the following

fatal: ambiguous argument 'bd340b0f7370015791413ea': unknown revision or
path not in the working tree.

If I replace the revision with an existing one it works. I think this is
really strange how can a sha disappear? Am I doing something wrong or is
there really an error in I can report a bug if it is
needed but would like to know how this is possible?

It was my fault. I ended doing a force push.

I did bump the revision now. Sorry for that inconvenience.
I also made a pick at some point (commit
bed180659337fc7f7df86dd9dc146516abcee108, somewhere in 4.14 rc5 - rc6 space)
that got deleted.

What is the best strategy when one wants to use a very recent kernel version
from linux-fslc? Can we have some kind of regular tags or another way to be
(reasonably) sure that the chosen commit isn't deleted afterwards?
It was my mistake; I don't do force pushes after adding the recipe but
I did forget it was meged. My fault.
No problem, just wanted to be sure that I can rely on a pick I make myself or that we can have some way of making a choice that will stay available.

See if reverting this commit it fixes your regression?
This looks like an answer to my other question about the SPI issues, right?

(I'm building the kernel with that one reverted right now, however I hoped for an OK on the DT snippet to be sure I didn't make a mistake there.)


Join { to automatically receive all group messages.