[yocto] Fwd: Yocto 1.4: Bad behavior between rm_work and packaging causing failures?

[Jerrod Peach]

>
>
>
> I think it's probably worth concentrating on the first issue. I can run
> some
> tests, but the question is are you able to elaborate on what builds might
> have
> been done before the user runs the problem build, and the nature of any
> changes that were made between prior builds and the failing build? Are you
> adding any custom tasks in your setup at all?
>
> Cheers,
> Paul
>
>
Paul,

So, I just came to a realization: We don't have any commonalities in tasks
being added (or whether tasks are added at all) in the packages we saw it
in.  However, we are running the builds automatically through Jenkins (the
open source continuous integration software, if you're not familiar with
it).  We've never seen this on a build that wasn't run through Jenkins,
though we've only seen it twice, so that's not saying a whole lot.  We're
wondering if a build aborted through Jenkins gets a SIGKILL, and if it does
AND that happens during rm_work, I bet that could cause this problem.
 Granted, this is all speculation, and we don't even know if the failures
occurred immediately after aborted builds, but that's the only thing my
colleagues and I can think of right now.

If you do want to continue investigating (which might be worthwhile, as our
speculation could be totally off-base), the packages from poky with which
we had this problem were eglibc-mtrace and systemd-serialgetty.  (We had
the problem with 5 other packages, but they're all custom packages of
ours.)  I find the latter particularly interesting, as that recipe seems to
be quite boring aside from its several python functions.  That makes me
think even more that we're seeing some weird combination of factors in our
Jenkins builds.

Kind regards,

Jerrod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20130709/b4259bcb/attachment.html>