"qmake -install qinstall" reproducer from the bugzilla ticket still
reproduces the issues every time even with latest pseudo, but that might be
different root cause than glibc-locale issue.
On Wed, Aug 14, 2019 at 6:02 PM Randy MacLeod
wrote:
> On 8/6/19 2:51 AM, Martin Jansa wrote:
> > This is
On 8/6/19 2:51 AM, Martin Jansa wrote:
This is the same reproducer I am using in:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
but with this SRCREV I haven't reproduced it yet in first 500
iterations, so it's definitely improving for me (used to reproduce it at
least once in first
This is the same reproducer I am using in:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
but with this SRCREV I haven't reproduced it yet in first 500 iterations,
so it's definitely improving for me (used to reproduce it at least once in
first 500 iterations)
Now I'm testing the
I can reproduce the problem fairly easily (and, sadly even with the latest
commits as 060058bb29f70b244e685b3c704eb0641b736f73 ).
In my case, it seems easy to reproduce if I have 40+ threads running.
The reproducer script (below) fails typically within the first 10 iterations.
#!/bin/bash
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
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
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
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
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
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
14 matches
Mail list logo
