From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Trevor Woerner <twoerner@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 3/4] kern-tools: fix processing for no branch meta-data
Date: Wed, 7 Dec 2016 22:23:12 -0500 [thread overview]
Message-ID: <462cfa93-c10d-c705-d380-3d1236fca597@windriver.com> (raw)
In-Reply-To: <CAHUNapQxmOANi1FinaTiXH+J2VdyvH4g5y2zRJydBso6epf00A@mail.gmail.com>
On 2016-12-07 6:50 PM, Trevor Woerner wrote:
> On Wed, Dec 7, 2016 at 1:05 PM, Trevor Woerner <twoerner@gmail.com> wrote:
>> On Wed, Dec 7, 2016 at 11:18 AM, Bruce Ashfield
>> <bruce.ashfield@windriver.com> wrote:
>>> With the attached patch, I see nothing else that is named in /tmp/
>>>
>>> If you have the cycles, can you give it a try and let me know ?
>>
>> Yes, I'm giving it a whirl right now. Thanks!
>
> That patch looks good, how soon can it land? ;-)
For my part, I'll send it first thing tomorrow along with some version
bumps to the kernel.
>
> I'm sure there's still something in the build that is creating
> temporary files in /tmp. I'm not sure which process is doing it, I
> have no reason to suspect it's the kernel tools (in fact I think it
> happens too early in the build to be the kernel tools), and the tmp
> files that are created are named with temporary names (e.g.
> /tmp/tmp.2wavbhTlDU) so they shouldn't interfere with multiple users
> building on the same machine. Each build appears to create two such
> temp files that aren't cleaned up at the end of the build. Not a big
> deal. I don't think it's something new that was introduced recently
> (but I'd have to do more investigation to verify).
I noticed one mktemp file leaking when I was fixing the bug at hand
today. I made a note to loop back and have a look for where an early
exit is skipping clean up.
If it is the tools, I'll fix it along with the patch I did today.
Bruce
>
next prev parent reply other threads:[~2016-12-08 3:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-02 21:09 [PATCH 0/4] kernel-yocto: consolidated pull request Bruce Ashfield
2016-12-02 21:09 ` [PATCH 1/4] linux-yocto/4.8: update to v4.8.10 Bruce Ashfield
2016-12-02 21:09 ` [PATCH 2/4] linux-yocto-dev: update to 4.9-rcX Bruce Ashfield
2016-12-02 21:09 ` [PATCH 3/4] kern-tools: fix processing for no branch meta-data Bruce Ashfield
2016-12-06 21:14 ` Patrick Ohly
2016-12-06 23:02 ` Paul Barker
2016-12-07 15:11 ` Trevor Woerner
2016-12-07 15:14 ` Bruce Ashfield
2016-12-07 16:18 ` Bruce Ashfield
2016-12-07 18:05 ` Trevor Woerner
2016-12-07 23:50 ` Trevor Woerner
2016-12-08 3:23 ` Bruce Ashfield [this message]
2016-12-08 15:27 ` Bruce Ashfield
2016-12-02 21:09 ` [PATCH 4/4] kernel-yocto: exit on non-zero return code Bruce Ashfield
2016-12-06 19:32 ` [PATCH 0/4] kernel-yocto: consolidated pull request Trevor Woerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=462cfa93-c10d-c705-d380-3d1236fca597@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=twoerner@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.