This is weird since ${S} is usually in PSEUDO_IGNORE_PATHS.
And if I understand it correctly, if ${S} is in PSEUDO_IGNORE_PATHS,
pseudo should not complain about any file under ${S}.
Could you please check if your recipe's PSEUDO_INGORE_PATHS contains
"WORKDIR/lib32-las/M-WBS0.1-r0/git"?
Regards,
Qi
On 3/6/23 02:08, Richard Purdie wrote:
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 (#59344): https://lists.yoctoproject.org/g/yocto/message/59344
Mute This Topic: https://lists.yoctoproject.org/mt/91650136/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
