On Mon, 26 Mar 2012 22:45:16 +0100
Richard Purdie richard.pur...@linuxfoundation.org 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
On Mon, 2012-03-26 at 02:43 -0500, Peter Seebach wrote:
On Sat, 24 Mar 2012 17:15:15 +
Richard Purdie richard.pur...@linuxfoundation.org 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
On Mon, 2012-03-26 at 11:44 -0500, Peter Seebach wrote:
On Sat, 24 Mar 2012 17:41:43 +
Richard Purdie richard.pur...@linuxfoundation.org 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
On Mon, 26 Mar 2012 17:47:29 +0100
Richard Purdie richard.pur...@linuxfoundation.org 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.
On Sat, 24 Mar 2012 17:15:15 +
Richard Purdie richard.pur...@linuxfoundation.org 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
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
On Mon, 2012-03-26 at 12:18 -0500, Peter Seebach wrote:
On Mon, 26 Mar 2012 17:47:29 +0100
Richard Purdie richard.pur...@linuxfoundation.org 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
On Mon, 26 Mar 2012 22:45:16 +0100
Richard Purdie richard.pur...@linuxfoundation.org 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
On Fri, 2012-03-23 at 17:45 -0500, Peter Seebach wrote:
On Fri, 23 Mar 2012 12:20:08 +
Paul Eggleton paul.eggle...@linux.intel.com 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
On Sat, 2012-03-24 at 17: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 back to
On Fri, 23 Mar 2012 11:21:26 +0800
Xu, Dongxiao dongxiao...@intel.com 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)
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 changes such that this will end up happening.
I now have a fairly simple test case outside of
On Fri, 23 Mar 2012 12:20:08 +
Paul Eggleton paul.eggle...@linux.intel.com 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 changes
On Fri, 23 Mar 2012 12:20:08 +
Paul Eggleton paul.eggle...@linux.intel.com 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 changes
On Thu, 22 Mar 2012 09:49:41 +0800
Xu, Dongxiao dongxiao...@intel.com 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
On Thu, 2012-03-22 at 11:18 -0500, Peter Seebach wrote:
On Thu, 22 Mar 2012 09:49:41 +0800
Xu, Dongxiao dongxiao...@intel.com 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
On Fri, 23 Mar 2012 09:01:16 +0800
Xu, Dongxiao dongxiao...@intel.com 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
On Thu, 2012-03-22 at 21:29 -0500, Peter Seebach wrote:
On Fri, 23 Mar 2012 09:01:16 +0800
Xu, Dongxiao dongxiao...@intel.com 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
Hi Mark,
Any update on this one? I think we may need to track it in bugzilla.
Thanks,
Dongxiao
On Wed, 2012-03-14 at 17:02 +0800, Xu, Dongxiao wrote:
Hi Mark,
When using the new Hob to build targets, I also observed the pseudo
output:
pseudo: You must set the PSEUDO_PREFIX environment
19 matches
Mail list logo
