layerindex updates are broken for meta-lmp-base

[moto-timo]

Some choices in how the recipes are defined are breaking the ability of layerindex-web to make updates:

https://layers.openembedded.org/layerindex/updates/37925/

ERROR: Unable to read /opt/workdir/https___github_com_foundriesio_meta-lmp/meta-lmp-base/recipes-kernel/linux/linux-lmp-dev.bb: Fetcher failure: Recipe uses a floating tag/branch 'master' for repo 'git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).
ERROR: Error executing a python function in <code>:

The stack trace of python calls that resulted in this exception/failure was:
File: '<code>', lineno: 11, function: <module>
     0007:__anon_35__opt_workdir_git___git_openembedded_org_openembedded_core_meta_classes_global_debian_bbclass(d)
     0008:__anon_42__opt_workdir_git___git_openembedded_org_openembedded_core_meta_classes_global_devshell_bbclass(d)
     0009:__anon_167__opt_workdir_git___git_openembedded_org_openembedded_core_meta_classes_global_sstate_bbclass(d)
     0010:__anon_101__opt_workdir_git___git_openembedded_org_openembedded_core_meta_classes_create_spdx_2_2_bbclass(d)
 *** 0011:__anon_91__opt_workdir_https___github_com_foundriesio_meta_lmp_meta_lmp_base_recipes_bsp_lmp_boot_firmware_lmp_boot_firmware_bb(d)
File: '/opt/workdir/https___github_com_foundriesio_meta-lmp/meta-lmp-base/recipes-bsp/lmp-boot-firmware/lmp-boot-firmware.bb', lineno: 90, function: __anon_91__opt_workdir_https___github_com_foundriesio_meta_lmp_meta_lmp_base_recipes_bsp_lmp_boot_firmware_lmp_boot_firmware_bb
     0086:"
     0087:
     0088:python() {
     0089:    # we need to set the DEPENDS as well to produce valid SPDX documents
 *** 0090:    fix_deployed_depends('do_install', d)
     0091:}
Exception: NameError: name 'fix_deployed_depends' is not defined

ERROR: Unable to read /opt/workdir/https___github_com_foundriesio_meta-lmp/meta-lmp-base/recipes-bsp/lmp-boot-firmware/lmp-boot-firmware.bb: 
ERROR: Error executing a python function in <code>:

The stack trace of python calls that resulted in this exception/failure was:
File: '<code>', lineno: 11, function: <module>
     0007:__anon_35__opt_workdir_git___git_openembedded_org_openembedded_core_meta_classes_global_debian_bbclass(d)
     0008:__anon_42__opt_workdir_git___git_openembedded_org_openembedded_core_meta_classes_global_devshell_bbclass(d)
     0009:__anon_167__opt_workdir_git___git_openembedded_org_openembedded_core_meta_classes_global_sstate_bbclass(d)
     0010:__anon_101__opt_workdir_git___git_openembedded_org_openembedded_core_meta_classes_create_spdx_2_2_bbclass(d)
 *** 0011:__anon_63__opt_workdir_https___github_com_foundriesio_meta_lmp_meta_lmp_base_recipes_support_mfgtool_files_mfgtool_files_0_1_bb(d)
File: '/opt/workdir/https___github_com_foundriesio_meta-lmp/meta-lmp-base/recipes-support/mfgtool-files/mfgtool-files_0.1.bb', lineno: 62, function: __anon_63__opt_workdir_https___github_com_foundriesio_meta_lmp_meta_lmp_base_recipes_support_mfgtool_files_mfgtool_files_0_1_bb
     0058:addtask deploy after do_compile before do_build
     0059:
     0060:python() {
     0061:    # we need to set the DEPENDS as well to produce valid SPDX documents
 *** 0062:    fix_deployed_depends('do_deploy', d)
     0063:}
Exception: NameError: name 'fix_deployed_depends' is not defined

ERROR: Unable to read /opt/workdir/https___github_com_foundriesio_meta-lmp/meta-lmp-base/recipes-support/mfgtool-files/mfgtool-files_0.1.bb:

[ricardosalveti]

Thanks for reporting the issue, it seems it is now tracking main which is the correct branch (before it was on master and the error was different).

@quaresmajose mind having a look?

[moto-timo]

I manually updated the actual branch name to main.

latest update run still shows some layer dependency issues (kirkstone, honister, hardknott, dunfell): https://layers.openembedded.org/layerindex/updates/37926/

[quaresmajose]

@moto-timo could you please clarify if it is possible to run the layer update on my side? so I can replicate all the possible problems on my side.

[moto-timo]

It is possible to setup your own instance with the dockersetup.py script, but downloading all the layer metadata from the DB is slow. To run the update on the actual instance requires ssh access and elevated privileges. I will poke around a bit more to figure out what might be causing those LAYERDEPENDS errors... it might be something unrelated to you (some dependent layer might be failing to update).

[moto-timo]

At least for dunfell it appears that for some reason meta-security is failing to find its dependent layers which is bubbling up to bite meta-lmp-base.

http://layers.openembedded.org/layerindex/updates/37931/ http://layers.openembedded.org/layerindex/updates/37934/

There was also no meta-lmp-base:dunfell Layer Branch entry, but I manually created it.

[moto-timo]

http://layers.openembedded.org/layerindex/updates/37937/

This shows we needed a dependency on meta-arm (but not "Required"), which I manually added. That turned into fixing meta-arm's layer dependencies. But looks like dunfell for meta-lmp-base is fixed now. On to the next branch... and layer.

[moto-timo]

For some reason layerindex kept pulling in meta-security master leading to addpylib parsing errors. Anyway, I was able to manually run updates for hardknott, honister, kirkstone (plus the previous dunfell and master). I cannot populate gatesgarth because of the python3.10 version on the layersindex.oe.o host.

Closing since this seems resolved and if it isn't there is no action for you anyway.

[ricardosalveti]

Anyway, I was able to manually run updates for hardknott, honister, kirkstone (plus the previous dunfell and master). I cannot populate gatesgarth because of the python3.10 version on the layersindex.oe.o host.

@moto-timo thanks for looking and fixing this one!

[quaresmajose]

It is possible to setup your own instance with the dockersetup.py script, but downloading all the layer metadata from the DB is slow. To run the update on the actual instance requires ssh access and elevated privileges. I will poke around a bit more to figure out what might be causing those LAYERDEPENDS errors... it might be something unrelated to you (some dependent layer might be failing to update).

Thanks for fixing the problem and also for the details that will definitely give me a better context.