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
On Mon, 2012-03-26 at 12:18 -0500, Peter Seebach wrote:
> 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 an
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 Mon, 2012-03-26 at 11:44 -0500, Peter Seebach wrote:
> 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
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 Mon, 2012-03-26 at 02:43 -0500, Peter Seebach wrote:
> 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 we
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 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 b
On Fri, 2012-03-23 at 17:45 -0500, Peter Seebach wrote:
> 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 o
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 changes such that this will en
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 changes such that this will en
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 h
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 Thu, 2012-03-22 at 21:29 -0500, Peter Seebach wrote:
> 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
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, 2012-03-22 at 11:18 -0500, Peter Seebach wrote:
> 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 und
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
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 environ
Hi Mark,
When using the new Hob to build targets, I also observed the pseudo
output:
"pseudo: You must set the PSEUDO_PREFIX environment variable to run
pseudo."
Here is the step to reproduce it:
1) source oe-init-build-env
2) hob
3) select machine and base image. Here I use qemux86 and
core-im
We're looking into this issue. You should never get the "pseudo: You must set
the PSEUDO_PREFIX environment variable to run pseudo." message. This means
something appears to have avoided the wrappers.
I'll let you know once we figure out something.
--Mark
On 2/17/12 9:35 AM, Paul Eggleton w
Hi all,
I'm trying to extend buildhistory to write out the metadata revisions just
before it does the commit to the buildhistory repository, and I'm having some
pseudo-related trouble. The structure is a little unusual, in that the
execution flow is an event handler that calls a shell function
24 matches
Mail list logo
