[OE-core] [PATCH 0/1] Uprev to pseudo 1.2

Wed Nov 2 21:39:42 UTC 2011

On 11/2/11 4:22 PM, Martin Jansa wrote:
> On Wed, Nov 02, 2011 at 04:11:57PM -0500, Mark Hatle wrote:
>> Uprev to pseudo 1.2.
>>
>> This was heavily tested by building oe-core with numerous image 
>> configurations.  Each configuration generated the same image before and 
>> after the change from the current to new version of pseudo.
>>
>> The primary purpose of this change is to enable the PSEUDO_UNLOAD 
>> functionality that may be used for performance enhancements in future 
>> versions of oe-core.
>>
>> The following changes since commit 37579d7d74d127c90c1e078d05c5bf4ba0b3f755:
>>
>>   meta: glib-2.0: don't apply qsort_r test removable patch for native version (2011-11-02 09:08:21 +0000)
>>
>> are available in the git repository at:
>>   git://git.pokylinux.org/poky-contrib mhatle/pseudo
>>   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/pseudo
> 
> Is there branch with pseudo-1.2 for oe-core?

^^^^^^^^^^^^^^^^^^^^^^^^

git://git.pokylinux.org/poky-contrib mhatle/pseudo

Grab that -- or simply grab the top commit and add it to your oe-core checkout.

> I would like to try it because we have strange errors when libstc++
> isn't found when building with pseudo, but same binaries are working
> fine without pseudo (seems related to /etc/ld.so.cache being ignored
> sometimes from pseudo env).
> 
> And while I was trying to debug it I've noticed that files.db and
> pseudo.log is quite big.
> -rw-r--r-- 1 bitbake bitbake 240M Aug 15 13:49 files.db
> -rw-r--r-- 1 bitbake bitbake  91K Aug 15 13:50 logs.db
> -rw-r--r-- 1 bitbake bitbake 305M Aug 15 13:49 pseudo.log

The files.db is based on the number of files accessed during the time pseudo is
running.

logs.db and pseudo.log are based on the debug settings of pseudo.  If you don't
have debugging enabled (you would have to do this manually) and the logs are
that big, something is going seriously wrong with the path/inode translation...
 It's fairly normal to have a set of logs that are in the 10-20k range for
complex packages.. (These are documenting cases where pseudo has to guess about
inode to path mapping..)

> with pseudo.log full of errors like this
> pseudo: path mismatch [12 links]: ino 39721500 db
> '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor'
> req
> '/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'.

Are you building on a NFS filesystem?  NFS (and a few other filesystems) have a
habit of remapping inodes out from under the filesystem.  pseudo uses the inodes
as a validation that the file hasn't changed.  If these inodes are changing,
pseudo will do it's best to keep things in sync, but there is a chance it won't
always succeed.

(This is done because someone could access a file in pseudo control that was
created outside..  so pseudo could only capture the inode..  then if in a future
action the file is accessed the inode/path can be checked.  If the inode matches
it assumes it's the same file and now a path name exists..  if someone makes
changes outside of pseudo control a similar check happens.. this time it'll see
the path is the same but inode has changed.. so it guesses the file was modified
and I believe resets everything based on the new inode.   Each of these will
generate a warning in the logs.)

--Mark

> Cheers,
> 
> 
>>
>> Mark Hatle (1):
>>   pseudo: Uprev pseudo to version 1.2
>>
>>  .../conf/distro/include/distro_tracking_fields.inc |    6 +-
>>  .../pseudo/pseudo/realpath_fix.patch               |  165 --------------------
>>  .../pseudo/{pseudo_1.1.1.bb => pseudo_1.2.bb}      |    7 +-
>>  meta/recipes-devtools/pseudo/pseudo_git.bb         |    6 +-
>>  4 files changed, 9 insertions(+), 175 deletions(-)
>>  delete mode 100644 meta/recipes-devtools/pseudo/pseudo/realpath_fix.patch
>>  rename meta/recipes-devtools/pseudo/{pseudo_1.1.1.bb => pseudo_1.2.bb} (48%)
>>
>> -- 
>> 1.7.3.4
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core