[OE-core] pseudo diagnostics: please do not ignore these completely!

Peter Seebach peter.seebach at windriver.com
Tue Aug 21 19:28:20 UTC 2012


If you have really weird build problems:

Check the pseudo.log file for a given package. A lot of packages are
generating a fair number of diagnostics and warnings some of which
indicate that stuff is non-trivially busted for some packages. A quick
scan of a small build turned up 16 packages with no diagnostics, and 21
which had diagnostics of some sort. Of those 21, 18 had at least one
case in which the database showed an inode as being a directory, and a
request showed that it wasn't anymore, or vice versa.

Pseudo is fairly paranoid about trying to catch stuff like this, but it
tends to do its best to fail quietly and just log the errors -- these
logs don't do much if we don't follow up on them, though.

The basic rule is:

If pseudo is aware of or using a file or directory, that file or
directory should not be moved/renamed, or replaced, except under
pseudo.

In many cases, things will recover. If a file is created under pseudo,
then renamed outside pseudo, then statted under pseudo again, the
database entry for the inode will be found and pseudo will probably do
the right thing. If there's a mismatch where an inode's basic type
(file/directory/link) mismatches between the database and an incoming
request, pseudo will nuke the bogus database entry.

But this won't catch everything.

So if you have a strange problem that you can't reproduce, check the
pseudo.log file. It may not mean much to you, but if it says anything
about "dir err" or "ino mismatch", something has gone pretty badly
wrong. If you can reproduce "this file is full of weird messages" with
a given package, that's probably a bug in the package, and I will try
to look into some of these when I have a minute or three and see
whether I can find any patterns.

And yes, I'm aware that running things under pseudo is slow. I have
plans to work on that too. Maybe I should do a kickstarter. :)

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.




More information about the Openembedded-core mailing list