So I've got patches for meta-mingw which make it fail in an interesting way
instead of in a boring way.
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=seebs/gcc52gw
With these, we get past all the obvious not-even-applying, and blow up
because one of the mingw headers complains that
rg/poky-contrib seebs/semanage-python-depends
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/semanage-python-depends
Peter Seebach (1):
policycoreutils.inc: Add missing dependencies for semanage
recipes-security/selinux/policycoreutils.inc | 2 ++
1 file changed, 2 insertions(+)
On Mon, 26 Mar 2012 22:45:16 +0100
Richard Purdie wrote:
> I'm still a little surprised we don't make any system() calls though.
> I just tried putting a os.system("true") call into the "breakit"
> class and it doesn't trigger the warnings. Could that be down to the
> lack of a popen wrapper?
Co
On Mon, 26 Mar 2012 22:45:16 +0100
Richard Purdie wrote:
> I'm still a little surprised we don't make any system() calls though.
> I just tried putting a os.system("true") call into the "breakit"
> class and it doesn't trigger the warnings. Could that be down to the
> lack of a popen wrapper?
I
Oh, nevermind, I just realized: We use antimagic as the implementation
goo for PSEUDO_DISABLED.
So a call to os.popen() from a program which has PSEUDO_DISABLED set is
going to think it's in antimagic mode.
And suddenly, the trick is revealed:
os.popen() is bypassing all the runqueue stuff whic
On Sat, 24 Mar 2012 17:15:15 +
Richard Purdie wrote:
> What puzzles me is we get this value from envbackup[key] =
> os.environ.get("PSEUDO_PREFIX") so its already not in the environment.
>
> So basically if we read "PSEUDO_PREFIX" from the environment we get
> nothing. If we unset the value
On Mon, 26 Mar 2012 17:47:29 +0100
Richard Purdie wrote:
> This is pretty much what we do at the moment, it gets unset after we
> load. Pseudo is of course disabled at this point.
>
> I guess we just got lucky to this point and avoided "Bad Things"?
I suspect so. What's weird to me is that PSE
On Sat, 24 Mar 2012 17:41:43 +
Richard Purdie wrote:
> One or the other of the above on their own doesn't do this. Funky.
That's very strange. I wouldn't have expected LOCALSTATEDIR to have
any effect either way; it might change how pseudo runs, but it shouldn't
affect whether it's being en
On Sat, 24 Mar 2012 17:15:15 +
Richard Purdie wrote:
> This implies that once we enable pseudo for a child, there is some
> change in the parent which persists.
Hmm.
Is the parent running with pseudo loaded? If it were, then I would
expect this -- pseudo does some environment magic that ca
On Fri, 23 Mar 2012 12:20:08 +
Paul Eggleton wrote:
> On Friday 23 March 2012 02:16:35 Peter Seebach wrote:
> > Still really weird to me that I can't reproduce this outside of hob.
> > I am pretty sure there exists a series of forks and execs and
> > environment c
On Fri, 23 Mar 2012 12:20:08 +
Paul Eggleton wrote:
> On Friday 23 March 2012 02:16:35 Peter Seebach wrote:
> > Still really weird to me that I can't reproduce this outside of hob.
> > I am pretty sure there exists a series of forks and execs and
> > environment c
On Fri, 23 Mar 2012 11:21:26 +0800
"Xu, Dongxiao" wrote:
> What do you mean by first build? Did you click "Just bake" button?
Yes. The original reproducer I saw said that it worked the first time,
but failed the second time.
> 1) build_target(packages)
> 2) build_target(image)
> I noticed th
On Fri, 23 Mar 2012 09:01:16 +0800
"Xu, Dongxiao" wrote:
> I think the difference between Hob and other UI (e.x., knotty) is
> that, when building image is finished in knotty, the UI, bitbake
> server, and pseudo all quit. But in Hob, everything still alive after
> a build. I noticed that the pse
On Thu, 22 Mar 2012 09:49:41 +0800
"Xu, Dongxiao" wrote:
> Hi Mark,
>
> Any update on this one? I think we may need to track it in bugzilla.
I have been looking into this. I've convinced myself that popen() is
broken under pseudo, but that's not enough to explain this:
* I have a fixed pseudo
On Thu, 09 Dec 2010 21:09:36 -0600, Xu, Dongxiao
wrote:
fp = fopen("/tmp/12321.txt", "w");
fakeroot doesn't intercept or alter fopen(). It'd be better to test
something
that is actually affected by fakeroot for a comparison. :)
fakeroot only traps things like stat and
15 matches
Mail list logo
