[OE-core] Merging problems

[Bruce Ashfield]

On 2014-12-20 5:40 PM, Richard Purdie wrote:
> On Sat, 2014-12-20 at 10:13 -0500, Bruce Ashfield wrote:
>> On 2014-12-20 6:15 AM, Richard Purdie wrote:
>>> So where are we at?
>>>
>>> Thanks to some great help from Ross, we have a number of patches merged
>>> and many of the issues in my last email have been addressed. I'm
>>> continuing to struggle with the kernel series. The last build on the
>>> autobuilder highlighted that:
>>>
>>> * there are problems in boot-directdisk.bbclass (have a fix)
>>> * there is a do_rootfs/do_package_qa race (have a fix)
>>> * the report-error.bbclass tasks could crash (have a fix)
>>> * the kernelmodule sanity tests were failing (have a fix)
>>> * qemumips gdb is failing to compile, probably due to new kernel
>>>     headers (no fix as yet)
>>> * systemd sanity QA tests continue to fail on xorg and systemd-login
>>>     (no fix as yet)
>>> * there are continuing problems with linux-imx from meta-fsl-arm, I
>>>     thought these were addressed but clearly not :(
>>>
>>> Ideally I'd like to take some time off over the holidays but I can't see
>>> that happening until the patch queues are under some kind of control :(.
>>
>> Let me know if there are one of these that you want me to take. I'm all
>> for pitching in and getting everyone some down time.
>
> Looks like I spoke too soon:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/132/steps/BuildImages_1/logs/stdio

Amazing how those race conditions pop out on the builders .. I probably
built this 100 times, and never managed to trigger these.

>
> which seems to be a race over the kernel source directory. I'm guessing
> the file in question is a temporary build artefact of lttng-modules
> which was running at the same time? Any way we can avoid temp files in
> the kernel source dir?

Hmm. The modules should already have their output directory set to their
own source (not the kernel), so they really shouldn't be dropping down
any temp files.

I was only using the cpio method to copy the source since that is what
was already being used .. and it is a bit faster. The stat of the
files to the pipe is what is catching us here.

The question is .. do we really care ? A straight copy of the files wouldn't
be so sensitive to this, or we could explicitly exclude then in the
existing cpio pipe. That would buy some time to track down what is
touching down the tmp file in the kernel build process, and I can't see
how the dual use of that staged directory will cause us a problem on
the copied kernel source side (we do clean things up before packaging).

Bruce

>
> Cheers,
>
> Richard
>
>