I saw you're still having problems even with the latest pseudo
revisions. I'll make some comments below.

On Thu, 2023-02-23 at 02:27 -0800, Tamis wrote:
> Install error:
> --------------------------------------------
> + install -m 0644 
> WORKDIR/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_list.h 
> WORKDIR/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_pdinc.h 
> WORKDIR/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_util.h 
> WORKDIR/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_varmsg.h 
> WORKDIR/lib32-las/M-WBS0.1-r0/image/usr/include
>  
> abort()ing pseudo client by server request. See 
> https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
> Check logfile: WORDIR/lib32-las/M-WBS0.1-r0/pseudo//pseudo.log
>  
> Aborted (core dumped)
> + bb_exit_handler
> + ret=134
> + echo WARNING: exit code 134 from a shell command.
> WARNING: exit code 134 from a shell command.
> + exit 134
> ---------------------------------------------------------------------------------
> And pseudo log error output:
> ------------------------------------------------------------------
> pid 26345 [parent 26344], doing new pid setup and server start
> Setup complete, sending SIGUSR1 to pid 26344.
> path mismatch [3 links]: ino 7868999 db 
> 'WORKDIR/lib32-las/M-WBS0.1-r0/package/usr/src/debug/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_list.h'
>  req 'WORKDIR/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_list.h'.

This is saying the file on disk with inode 7868999 is:
WORKDIR/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_list.h 

but the pseudo database thinks this is:

WORKDIR/lib32-las/M-WBS0.1-r0/package/usr/src/debug/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_list.h

so the question is when was this file created? It would be created by
do_package since it is in the /package/ directory. It would seem to be
being deleted outside of pseudo context.

> db cleanup for server shutdown, 08:38:52.482
> memory-to-file backup complete, 08:38:52.482.
> db cleanup finished, 08:38:52.482
> debug_logfile: fd 2
> pid 6423 [parent 6422], doing new pid setup and server start
> Setup complete, sending SIGUSR1 to pid 6422.
> path mismatch [3 links]: ino 7868999 db 
> 'WORKDIR/lib32-las/M-WBS0.1-r0/package/usr/src/debug/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_list.h'
>  req 'WORKDIR/lib32-las/M-WBS0.1-r0/git/lasiflib/include/lasif_list.h'.
> db cleanup for server shutdown, 09:13:45.899
> memory-to-file backup complete, 09:13:45.899.
> db cleanup finished, 09:13:45.899
> -----------------------------------------------------------------------------------------------------------------------------------
> 
> I added the export PSEUDO_DEBUG = "nfoPcvdDyerpswikVx" in the recipe but I 
> couldn't understand much.
> In the whole build we have the RM_WORK enabled but for that current recipe we 
> have excluded it.

How are you excluding it? I have to wonder if that is somehow breaking
things due to dependency changes.

> Also the task order is the following:
> do_cleansstate (20698): log.do_cleansstate.20698
> do_cleanall (22404): log.do_cleanall.22404
> do_rm_work (24346): log.do_rm_work.24346
> do_fetch (24434): log.do_fetch.24434
> do_prepare_recipe_sysroot (24465): log.do_prepare_recipe_sysroot.24465
> do_unpack (24466): log.do_unpack.24466
> do_patch (24493): log.do_patch.24493
> do_populate_lic (24665): log.do_populate_lic.24665
> do_deploy_source_date_epoch (24666): log.do_deploy_source_date_epoch.24666
> do_configure (24765): log.do_configure.24765
> do_compile (24809): log.do_compile.24809
> do_install (27477): log.do_install.27477
> do_populate_sysroot (27510): log.do_populate_sysroot.27510
> do_package (27509): log.do_package.27509
> do_packagedata (29544): log.do_packagedata.29544
> do_package_qa (29592): log.do_package_qa.2959
> do_package_write_ipk (29593): log.do_package_write_ipk.29593
> 
> Ok build till now.
> Next invocation
> do_prepare_recipe_sysroot (23311): log.do_prepare_recipe_sysroot.23311
> do_configure (23769): log.do_configure.23769
> do_compile (24132): log.do_compile.24132
> do_install (26628): log.do_install.26628

Are you saying the first failure is here in the do_install above?

> do_install (32535): log.do_install.32535
> do_install (4454): log.do_install.4454
> do_install (26343): log.do_install.26343
> do_rm_work (4905): log.do_rm_work.4905

This is odd. Why would an rm_work run here?

> do_deploy_source_date_epoch (4919): log.do_deploy_source_date_epoch.4919
> do_configure (4954): log.do_configure.4954
> do_compile (5003): log.do_compile.5003
> do_install (6421): log.do_install.6421

This is also odd since if rm_work did run, shouldn't the unpack/patch
need to run again? Didn't you say you'd disabled rm_work for this
recipe?

> All above are failures in do_install phase. You see multiple
> invocations trying to fix the error and adding more debug.
> If I don't do a cleansstate or cleanall the recipe is not building.
> We do not delete or manipulate any files in the WORKDIR folder. We
> might only copy some files after the end of the build in some folders
> outside of yocto. So the WORKDIR structure remains untouched from our
> actions.

Something is deleting the files in /package/ which is confusing pseudo.
The question is what/when. Stepping through this and seeing when the
files there disappear would be the next step to debug it, narrow down
when something is deleting them.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59343): https://lists.yoctoproject.org/g/yocto/message/59343
Mute This Topic: https://lists.yoctoproject.org/mt/91650136/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: 
https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to