<div dir="ltr"><div dir="ltr">Hi, Mark:<div><br></div><div>I have done a quick test, seems the problem fixed with this patch, the steps are as follows:</div><div>```</div><div>bitbake aktualizr -c cleanall</div><div>bitbake aktualizr<br></div><div>```</div><div>build succeeded.</div><div><br></div><div>the best,</div><div>thank you</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Mark Hatle <<a href="mailto:mark.hatle@windriver.com">mark.hatle@windriver.com</a>> 於 2019年1月27日 週日 上午2:19寫道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/26/19 7:50 AM, Stefan Agner wrote:<br>
> On 26.01.2019 14:35, Richard Purdie wrote:<br>
>> On Sat, 2019-01-26 at 13:07 +0100, Patrick Vacek wrote:<br>
>>> On Sat, Jan 26, 2019 at 11:15 AM Stefan Agner <<a href="mailto:stefan@agner.ch" target="_blank">stefan@agner.ch</a>><br>
>>> wrote:<br>
>>>>> So it seems to be that something in the recipe was expecting<br>
>>>> semi-broken<br>
>>>>> behavior.. and its actually a recipe problem.<br>
>>>><br>
>>>> Agreed, in this case we need to fix the recipe.<br>
>>><br>
>>> Sorry, I must be missing something. What might be wrong with the<br>
>>> recipe? Is there more that needs to be specified than a SRCREV and a<br>
>>> branch? As far as I understand git, it keeps track of the submodules,<br>
>>> so I don't know what other information there would be to provide. The<br>
>>> reason this particular case is difficult is because there are<br>
>>> recursive submodules. When we build aktualizr, we have to be careful<br>
>>> to specify that. See<br>
>>> <a href="https://github.com/advancedtelematic/aktualizr#building" rel="noreferrer" target="_blank">https://github.com/advancedtelematic/aktualizr#building</a>:<br>
>>><br>
>>> git submodule update --init --recursive<br>
>><br>
>> The problem is the checkout from the old version of the fetcher was<br>
>> broken, it incorrectly checked out that SRCREV. The recipe was written<br>
>> to build that broken checkout.<br>
>><br>
>> We've fixed the fetcher and Mark is saying that it now checks out the<br>
>> correct thing (as compared with a git checkout outside of the build<br>
>> system, independent of the fetcher).<br>
>><br>
>> The recipe assumed the old broken code so now fails to build. The<br>
>> recipe therefore needs to change to adapt to the now correct source<br>
>> code.<br>
> <br>
> I was not able to reproduce Marks findings.<br>
> <br>
> In particular:<br>
> <br>
>> For instance, the submodule partial/extern/isotp-c:<br>
>><br>
>> In the current version is checked out on<br>
>> 4c5904bff3ed83ec471c8586b5faed62898d0224. (Which matches the manual git behavior.)<br>
>><br>
>> While the gitsm fetcher in the older system checkedout commit<br>
>> 614fe48fe55aeea98b49804b7e31ef2d304f62de. Which is incorrect.<br>
> <br>
> That wasn't the case for me, the old code checked out 4c5904bf just<br>
> fine.<br>
> <br>
> However, I think Ming Liu's recent findings point out the culprit.<br>
> <br>
> The submodule isotp-c requires a submodule on its own, and the new code<br>
> seems not to unpack that.<br>
<br>
i see what you are saying, but for some reason the version of git on my machine<br>
(using the steps I mentioned in the original email) for some reason did not pull<br>
down the recursive git submodule, which would explain why my diff didn't find<br>
it. (It's pretty clear to me that even within git itself, some submodule<br>
operations have been broken in various versions in the past.. my guess is that<br>
I'm hitting one of those errant behaviors locally.)<br>
<br>
If I manually go to the isotp-c directory and run git init ; git submodule<br>
update it -then- downloads it. (So apparently the --recursive argument isn't in<br>
some versions. My system has 1.8.3.1 on it BTW.)<br>
<br>
Looking at this quickly, I suspect I know what the problem is:<br>
<br>
if not ud.bareclone and self.process_submodules(ud, ud.destdir,<br>
unpack_submodules, d):<br>
<br>
if ud.bareclone is set, then python will optimize and not even run the<br>
process_submodules which is what does the unpack. This is set for recursive<br>
submodule parsing.<br>
<br>
I'm getting ready to board a plane in a few hours. So it'll be a day or so<br>
before I can get back to this. I think I have a fix, see:<br>
<br>
<a href="http://git.openembedded.org/bitbake-contrib/commit/?h=mgh/gitsm&id=ce5bb0056e6c510855811a26afb95073daf90f2a" rel="noreferrer" target="_blank">http://git.openembedded.org/bitbake-contrib/commit/?h=mgh/gitsm&id=ce5bb0056e6c510855811a26afb95073daf90f2a</a><br>
<br>
If you see this and can test it... I can formally send it for review if it's<br>
resolved the issues when I get to my destination.<br>
<br>
--Mark<br>
</blockquote></div>