hi,
we are hitting some errors with repo init since last night.
Yes, I was investigating this failure too. Thanks very much for working it out.
After
looking into it , I came up with the following explanation and fix..
If I am correct, it will impact all our OE RPB build setup..
It definitely impacts on my WaRP7 builds, which are failing since last night too.
Can you please review that carefully?
The PR is on github:
https://github.com/96boards/oe-rpb-manifest/pull/121
I added myself as a reviewer and approved it.
You've highlighted problems below, but in the end, your fix is better than no fix. And anything else we do could be on top of this fix.
I put a copy of the commit message below to bring it to your attention!
cheers
nico
==
All along we have been using a relative symlink for setup-environment
which points outside of the project path. While we've enjoyed this
hack for several years, a recent change was in repo, and repo init now
fails with:
error.ManifestInvalidPathError: <linkfile> invalid "src":
../../.repo/manifests/setup-environment: bad component: .repo
The change in repo is this one:
https://gerrit.googlesource.com/git-repo/+/07392ed32662006c029299bc06617310cfe17957
Yes, I also worked out this was the culprit.
The repo documentation states: The symlink is created at “dest”
(relative to the top of the tree) and points to the path specified by
“src” which is a path in the project.
As such, repo clearly expects that 'src' is in the project path, which
is not the cause when using ../../.repo/ path.
This patch changes our folder structure in such a way that:
* the manifest git is checked out as ./conf/ folder in the top level
directory
* setup-environment link is created by repo, as a link to
conf/setup-environment-internal
The main drawback is that it feels non standard to duplicate the whole
manifest project again (since it's already checked out in .repo)
however using .repo content also meant we were making assumptions on
implementation details of repo itself.
I don't see an obvious way around this. We are using the repo contents, but we're not allowed to use it directly.
So unless we re-work how we do setup-environment, I don't see a way to avoid this. The only nagging thought I have is that setup-environment and default.xml are two distinct things, so we could split it into two repos. But as the repo is so small, I don't see the added value of doing this. It seems to be more overhead. That said, when I clone the manifest repo for my own projects, all I'm doing is editing default.xml, and nothing else. So it might make sense anyway, so I can get changes to things like setup-env without have to rebase my manifest repo. But again, it's such a small repo, it's not really a problem to have it like this. And probably makes life easier in the long term.
Cheers,
Ryan.
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
_______________________________________________
OpenEmbedded mailing list
OpenEmbedded@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/openembedded