> > if grep -q "host-user-contaminated" ${fname}_$i.log; then
> > echo "error !"
> > exit 2
> > #else
> > #rm ${fname}_$i.log
> > fi
> >
> > done
> >
> &
lto:openembedded-core-boun...@lists.openembedded.org>] on behalf
of Seebs [se...@seebs.net <mailto:se...@seebs.net>]
Sent: Saturday, August 03, 2019 7:23 AM
To: Khem Raj
Cc: openembedded-core@lists.openembedded.org
<mailto:openembedded-core@lists.openembedded.org&g
exit 2
> #else
> #rm ${fname}_$i.log
> fi
>
> done
>
>
> From: openembedded-core-boun...@lists.openembedded.org [
> openembedded-core-boun...@lists.openembedded.org] on behalf of Seebs [
> se...@seebs.net]
> Sent: Satu
...@seebs.net]
Sent: Saturday, August 03, 2019 7:23 AM
To: Khem Raj
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix openat()
with a directory symlink [NAK]
On Sat, 3 Aug 2019 05:33:46 -0700
Khem Raj wrote:
> Will this fix the file
If we understood more about the nature of the race condition a test case could
probably be constructed. For now, it is worth a try to see if it is any better.
I am certain the timing will change ever so slightly, so we could hit the
glibc-locale issue more or less...
All of the regression tes
On 8/3/19 9:57 AM, Khem Raj wrote:
> I see the locale issue atleast 5-7 times a week on world builds so I
> will be able to see if that frequency stays same after this fix.
Internally we turned it into an error due to the frequency... out of 3-4k+
builds a week I think we're seeing it may 20 times?
I see the locale issue atleast 5-7 times a week on world builds so I
will be able to see if that frequency stays same after this fix.
On Sat, Aug 3, 2019 at 7:23 AM Seebs wrote:
>
> On Sat, 3 Aug 2019 05:33:46 -0700
> Khem Raj wrote:
>
> > Will this fix the file ownership issue that we see with
On Sat, 3 Aug 2019 05:33:46 -0700
Khem Raj wrote:
> Will this fix the file ownership issue that we see with Glibc-locale
> packages from time to time?
I have no idea. Since I haven't got a reliable reproducer for it, I
can't test it in a sane way.
-s
--
On Fri, Aug 2, 2019 at 10:49 AM Seebs wrote:
> On Fri, 2 Aug 2019 12:07:33 -0500
> Seebs wrote:
>
> > Note that there's no lstat, and no AT_SYMLINK_NOFOLLOW. Which is to
> > say, these stats will be following the symlink even though O_NOFOLLOW
> > was set. I can probably patch this in a bit.
>
>
On Fri, 2 Aug 2019 12:07:33 -0500
Seebs wrote:
> Note that there's no lstat, and no AT_SYMLINK_NOFOLLOW. Which is to
> say, these stats will be following the symlink even though O_NOFOLLOW
> was set. I can probably patch this in a bit.
Followup: Patch applied to master, but also in addition to f
On Fri, 2 Aug 2019 11:27:45 -0500
Jason Wessel wrote:
> The sequence of openat() followed by an fstat() on the opened file
> handle, will erase the pseudo uid entry for the symlink, as shown by
> the following lstat() in test 5. The culprit appears to be the
> fstat(), but it could be something m
It took a while to narrow this down to a concise test case, and I am not
exactly sure what is going on in pseudo. The C app is created based on
mimicking exactly the python code that causes the failure, so that bitbake can
be entirely removed from the picture.
If you use the master branch of
On Thu, 1 Aug 2019 16:37:26 -0500
Jason Wessel wrote:
> It seems to have caused really odd problems with the oe link
> management that were not there previously, such as:
>
>
> WARNING: pinentry-1.1.0-r0 do_package_qa: QA Issue:
> pinentry: /usr/bin/pinentry is owned by uid 5002, which is the s
While this is a real problem. We need to put this patch on hold.
It seems to have caused really odd problems with the oe link management that
were not there previously, such as:
WARNING: pinentry-1.1.0-r0 do_package_qa: QA Issue: pinentry: /usr/bin/pinentry
is owned by uid 5002, which is the
14 matches
Mail list logo
