[OE-core] [PATCH 01/30] oeqa/core/loader: Switch method definition for _make_failed_test

[Patrick Ohly]

On Mon, 2017-07-17 at 14:41 -0500, Aníbal Limón wrote:
> 
> On 07/17/2017 02:14 PM, Patrick Ohly wrote:
> > On Fri, 2017-07-14 at 10:27 -0500, Aníbal Limón wrote:
> >>
> >> On 07/14/2017 04:52 AM, Patrick Ohly wrote:
> >>> On Tue, 2017-07-11 at 15:23 -0500, Aníbal Limón wrote:
> >>>> This was a mistake of me to define wrong what methods needs
> >>>> to be defined by certain python version.
> >>>>
> >>>> See rev d8380d098a290510b442a7abd2dd5a50cabf5844.
> >>>
> >>> This will fix this error that we see in Refkit with current OE-core
> >>> master, right?
> >>>
> >>> 00:07:10.313 Traceback (most recent call last):
> >>> 00:07:10.313   File "/srv/jenkins/workspace/ci-2017-07-14_01-48-19-build-2315/openembedded-core/scripts/oe-selftest", line 70, in <module>
> >>> 00:07:10.313     ret = main()
> >>> 00:07:10.313   File "/srv/jenkins/workspace/ci-2017-07-14_01-48-19-build-2315/openembedded-core/scripts/oe-selftest", line 57, in main
> >>> 00:07:10.313     results = args.func(logger, args)
> >>> 00:07:10.313   File "/srv/jenkins/workspace/ci-2017-07-14_01-48-19-build-2315/openembedded-core/meta/lib/oeqa/selftest/context.py", line 215, in run
> >>> 00:07:10.313     rc = self._internal_run(logger, args)
> >>> 00:07:10.313   File "/srv/jenkins/workspace/ci-2017-07-14_01-48-19-build-2315/openembedded-core/meta/lib/oeqa/selftest/context.py", line 176, in _internal_run
> >>> 00:07:10.313     self.tc.loadTests(self.module_paths, **self.tc_kwargs['load'])
> >>> 00:07:10.313   File "/srv/jenkins/workspace/ci-2017-07-14_01-48-19-build-2315/openembedded-core/meta/lib/oeqa/core/context.py", line 51, in loadTests
> >>> 00:07:10.313     self.suites = self.loader.discover()
> >>> 00:07:10.313   File "/srv/jenkins/workspace/ci-2017-07-14_01-48-19-build-2315/openembedded-core/meta/lib/oeqa/core/loader.py", line 286, in discover
> >>> 00:07:10.313     pattern='*.py', top_level_dir=path)
> >>> 00:07:10.313   File "/usr/lib64/python3.4/unittest/loader.py", line 275, in discover
> >>> 00:07:10.313     tests = list(self._find_tests(start_dir, pattern))
> >>> 00:07:10.313   File "/usr/lib64/python3.4/unittest/loader.py", line 327, in _find_tests
> >>> 00:07:10.313     yield _make_failed_import_test(name, self.suiteClass)
> >>> 00:07:10.313   File "/usr/lib64/python3.4/unittest/loader.py", line 39, in _make_failed_import_test
> >>> 00:07:10.313     return _make_failed_test(name, ImportError(message), suiteClass)
> >>> 00:07:10.313 TypeError: _make_failed_test() missing 1 required positional argument: 'suiteClass'
> >>>
> >>> Can this particular patch please be merged into OE-core master
> >>> independently from the patch series? It's not really related to it
> >>> anyway.
> >>
> >> Yes this will fix that error, showing the error into the case.
> > 
> > The fix doesn't work for me:
> > 
> >   File "/usr/lib/python3.5/unittest/loader.py", line 41, in _make_failed_import_test
> >     return _make_failed_test(name, ImportError(message), suiteClass, message)
> > TypeError: _make_failed_test() takes 3 positional arguments but 4 were given
> > 
> > You need to mimic the exact same signature as in Python itself, and
> > Python 3.5 seems to be different again:
> > 
> > /usr/lib/python3.5/unittest/loader.py:def _make_failed_test(methodname, exception, suiteClass, message):
> 
> This is strange, i tested on a python 3.5.x and python 3.4.3 versions.
> I don't know why isn't working on your machine.

Have you tested with a test case that fails?

python3.5 = 3.5.3 definitely has four parameters, as quoted above.

I don't know which version has "def _make_failed_test(classname,
exception, suiteClass)".

The actual error in refkit is:

ImportError: Failed to import test module: refkit_ostree
Traceback (most recent call last):
  File "/usr/lib/python3.5/unittest/loader.py", line 428, in _find_test_path
    module = self._get_module_from_name(name)
  File "/usr/lib/python3.5/unittest/loader.py", line 369, in _get_module_from_name
    __import__(name)
  File "/fast/work/intel-iot-refkit-pr/meta-refkit-core/lib/oeqa/selftest/cases/refkit_ostree.py", line 12, in <module>
    class RefkitOSTreeUpdateBase(SystemUpdateBase):
  File "/fast/work/intel-iot-refkit-pr/meta-refkit-core/lib/oeqa/selftest/cases/refkit_ostree.py", line 35, in RefkitOSTreeUpdateBase
    'socat-native')
  File "/fast/work/intel-iot-refkit-pr/openembedded-core/meta/lib/oeqa/utils/commands.py", line 227, in get_bb_vars
    bbenv = get_bb_env(target, postconfig=postconfig)
  File "/fast/work/intel-iot-refkit-pr/openembedded-core/meta/lib/oeqa/utils/commands.py", line 221, in get_bb_env
    return bitbake("-e %s" % target, postconfig=postconfig).output
  File "/fast/work/intel-iot-refkit-pr/openembedded-core/meta/lib/oeqa/utils/commands.py", line 213, in bitbake
    return runCmd(cmd, ignore_status, timeout, output_log=output_log, **options)
  File "/fast/work/intel-iot-refkit-pr/openembedded-core/meta/lib/oeqa/utils/commands.py", line 191, in runCmd
    raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
AssertionError: Command 'bitbake  -e socat-native' returned non-zero exit status 1:
Loading cache...done.
Loaded 3495 entries from dependency cache.
Parsing recipes...done.
ERROR: No recipes available for:
  /fast/work/intel-iot-refkit-pr/openembedded-core/../meta-refkit-core/bbappends/meta-security/recipes-tpm/swtpm/swtpm-wrappers-native.bbappend
  /fast/work/intel-iot-refkit-pr/openembedded-core/../meta-refkit-core/bbappends/meta-security/recipes-tpm/trousers/trousers_%.bbappend
Parsing of 2606 .bb files complete (2602 cached, 4 parsed). 3499 targets, 415 skipped, 0 masked, 0 errors.

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

RefkitOSTreeUpdateBase calls get_bb_vars() as part of the class
definition. That's the part that is failing.

The failure is caused by meta-security re-structuring the layers. Will
be easy enough to fix in meta-refkit-core, now that I know what it is.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.