armmbed / icetea Goto Github PK

• Type: Enhancement
• Version: icetea 2.0.1
• Reason: icetea 2.0.1 depends on prettytable<1.0. Version 0.7.2 is from 2013
• Enhancement: Update to use prettytable 2.0
• Pros: Easy environment, avoid dependency incompatibilities.

Note: This is just a template, so feel free to use/remove the unnecessary things

Description

• Type: Bug | Question

Bug

Icetea version
2.0.0

Expected Behavior
install normally with pip
Actual Behavior
Could not find a version that satisfies the requirement trollius==1.0.4 (from pyshark-legacy->icetea) (from versions: 2.1.post2, 2.2, 2.2.post1)
No matching distribution found for trollius==1.0.4 (from pyshark-legacy->icetea)

Steps to Reproduce
"pip install icetea" on a clean machine

Question

How to solve this error message?

After installation of icetea with setup.py, I'm not able to launch the icetea installed:

$ icetea --help
Traceback (most recent call last):
  File "C:\Python27\Scripts\icetea-script.py", line 11, in <module>
    load_entry_point('icetea==1.0.0', 'console_scripts', 'icetea')()
  File "C:\Python27\lib\site-packages\pkg_resources\__init__.py", line 570, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "C:\Python27\lib\site-packages\pkg_resources\__init__.py", line 2755, in load_entry_point
    return ep.load()
  File "C:\Python27\lib\site-packages\pkg_resources\__init__.py", line 2409, in load
    return self.resolve()
  File "C:\Python27\lib\site-packages\pkg_resources\__init__.py", line 2419, in resolve
    raise ImportError(str(exc))
ImportError: 'module' object has no attribute 'icedea_main'

However invoking icetea locally work (python icetea.py --help).

Description

• Type: Bug

Bug

Icetea does not list jsonschema as a requirement, but still depends on it.

Hi, as shown in the following full dependency graph of icetea, icetea requires mbed-ls >=1.5.1,<2.0, icetea requires mbed-flasher >=0.10.1,<0.11 (mbed-flasher 0.10.1 will be installed, i.e., the newest version satisfying the version constraint), and directed dependency mbed-flasher 0.10.1 transitively introduces mbed-ls <2.0,>=1.5.1.

Obviously, there are multiple version constraints set for mbed-ls in this project. However, according to pip's “first found wins” installation strategy, mbed-ls 1.7.10 (i.e., the newest version satisfying constraint >=1.5.1,<2.0) is the actually installed version.

Although the first found package version mbed-ls 1.7.10 just satisfies the later dependency constraint （mbed-ls >=1.5.1,<2.0), such installed version is very close to the upper bound of the version constraint of mbed-ls specified by mbed-flasher 0.10.1.

Once mbed-flasher upgrades，its newest version will be installed. Therefore, it will easily cause a dependency conflict (build failure), if the upgraded mbed-flasher version introduces a higher version of mbed-ls, violating its another version constraint >=1.5.1,<2.0.

According to the release history of mbed-flasher, it habitually upgrates Mbed-ls in its recent releases. For instance, mbed-flasher mbedls_v171_1 upgrated Mbed-ls’s constraint from ==1.5.1 to >=1.5.1,==1.,mbed-flasher pyocd_mbedls_v178_1 upgrated Mbed-ls’s constraint from >=1.5.1,==1. to ==1.7.7 and mbed-flasher pyocd_mbedls_v178_1 upgrated Mbed-ls’s constraint from ==1.7.7 to ==1.7.8.

As such, it is a warm warning of a potential dependency conflict issue for icetea.

Dependency tree

icetea - 2.0.1
| +- jsonmerge(install version:1.7.0 version range:>=1.4.0,<2.0)
| | +- jsonschema(install version:2.6.0 version range:*)
| +- jsonschema(install version:2.6.0 version range:<3.0.0)
| +- mbed-flasher(install version:0.10.1 version range:>=0.10.1,<0.11)
| | +- mbed-ls(install version:1.7.10 version range:<2.0,>=1.5.1)
| | +- pyserial(install version:3.4 version range:==3.)
| | +- six(install version:1.14.0version range:==1.)
| +- mbed-ls(install version:1.7.10 version range:>=1.5.1,<2.0)
| | +- mbed-os-tools(install version:0.0.13 version range:>=0.0.9,<0.1.0)
| | +- prettytable(install version:0.7.2 version range:>=0.7.2)
| +- prettytable(install version:0.7.2 version range:<1.0)
| +- pydash(install version:4.7.6 version range:<5.0,>=4.0)
| +- pyserial(install version:3.4 version range:>2.5)
| +- requests(install version:2.23.0 version range:*)
| | +- certifi(install version:2020.4.5.1 version range:>=2017.4.17)
| | +- chardet(install version:3.0.4 version range:>=3.0.2,<4)
| | +- idna(install version:2.9 version range:>=2.5,<3)
| | +- urllib3(install version:1.25.9 version range:>=1.21.1,<1.26)
| +- semver(install version:2.10.1 version range:<3.0,>=2.0)
| +- six(install version:1.14.0 version range:>=1.0,<2.0)
| +- transitions(install version:0.8.1 version range:<1.0)
| | +- six(install version:1.14.0 version range:*)
| +- yattag(install version:1.13.2 version range:>=1.0,<2.0)

Thanks for your help.
Best,
Neolith

Description

• Type: Bug | Enhancement
• Related Issue: pyocd/pyOCD#511,

Enhancement

In leiu of recent ARMmbed/mbed-os struggles, I'd strongly suggesting that icetea version pin their python modules, found in these three files:

• https://github.com/ARMmbed/icetea/blob/master/requirements.txt
• https://github.com/ARMmbed/icetea/blob/master/dev_requirements.txt
• https://github.com/ARMmbed/icetea/blob/master/extra_requirements.txt

Reason to enhance/problem with existing solution
Version numbers increase CI stability by preventlng a stray module update from halting testing in the repo.

Description

Evaluating 5.10 during OOB round 2.
Found Traceback error

Environment:

• Mbed CLI 1.8.0
• Python 3.7.0
• Both: Windows 10 and OSX El Capitan

>icetea --version
Traceback (most recent call last):
  File "C:\Users\marsal01\AppData\Local\Programs\Python\Python37-32\Scripts\icetea-script.py", line 11, in <module>
    load_entry_point('icetea==1.0.1', 'console_scripts', 'icetea')()
  File "c:\users\marsal01\appdata\local\programs\python\python37-32\lib\site-packages\icetea_lib\main.py", line 20, in icetea_main
    from icetea_lib import IceteaManager
  File "c:\users\marsal01\appdata\local\programs\python\python37-32\lib\site-packages\icetea_lib\IceteaManager.py", line 35, in <module>
    from icetea_lib.TestSuite.TestSuite import TestSuite, SuiteException
  File "c:\users\marsal01\appdata\local\programs\python\python37-32\lib\site-packages\icetea_lib\TestSuite\TestSuite.py", line 33, in <module>
    from icetea_lib.TestSuite.TestcaseContainer import TestStatus, DummyContainer
  File "c:\users\marsal01\appdata\local\programs\python\python37-32\lib\site-packages\icetea_lib\TestSuite\TestcaseContainer.py", line 29, in <module>
    from icetea_lib.bench import ReturnCodes
  File "c:\users\marsal01\appdata\local\programs\python\python37-32\lib\site-packages\icetea_lib\bench.py", line 53, in <module>
    from icetea_lib.DeviceConnectors.Dut import DutConnectionError
  File "c:\users\marsal01\appdata\local\programs\python\python37-32\lib\site-packages\icetea_lib\DeviceConnectors\Dut.py", line 330
    self.execute_command(cli_cmd[0], wait=wait, async=asynchronous)
                                                    ^
SyntaxError: invalid syntax

[ ] Question
[ ] Enhancement
[X] Bug

Mirroring issue from: ARMmbed/mbed-os#8116
ARM Internal Ref: MBOTRIAGE-1648

Facing multiple fails for test cases under TEST_APPS directory, my setup involves

DUT'S : NUCLEO_F429ZI x 2
TEST ALGORITH: ICE TEA

compiling using mbed cli interface with GCC_ARM. Please refer to attached logs for further info, looking for your valuable suggestion.

abhi

Description

Now "No suitable local device available" reported when need more devices and not found enough.

Expected something like: "1/2 suitable devices found" that it is more clear for user to add more devices

Original issue: ARMmbed/mbed-os#8028

Note: This is just a template, so feel free to use/remove the unnecessary things

Description

• Type: Question
• Related Issue:

Bug

Icetea version
(git rev-parse HEAD)

Expected Behavior

Actual Behavior

Steps to Reproduce

Enhancement

Reason to enhance/problem with existing solution

Suggested enhancement

Pros

Cons

Question

How to?

Description

Now "No suitable local device available" reported when need more devices and not found enough.

Expected something like: "1/2 suitable devices found" that it is more clear for user to add more devices

• Type: Enhancement
• Version: icetea 2.0.1
• Problem: requires jsonschema<3.0.0; Version 2.6.0 is from 2017
• Request: update to use >=3.2.0
• Pros: Easier environment setup by avoiding incompatibilities

python icetea.py --list return the following error (a testsuite is present in testcases):

No handlers could be found for logger "Icetea"

Note that this command was working before I removed mbed-clitest from my installed pip packages 😱 .

Description

When trying to run test_cmdline I am getting this error
12:09:43.006 | TC MainThread: Test Case fails because of: COM55 CMD timeout: set --retcode true
12:09:43.006 | TC MainThread: Test 'test_something' FAIL, reason: COM55 CMD timeout: set --retcode true
12:09:47.505 Test case test_something failed, No retries left.

+----------------+--------------+---------------------------------------+-------------+-----------+----------+
| Testcase | Verdict | Fail Reason | Skip Reason | platforms | duration |
+----------------+--------------+---------------------------------------+-------------+-----------+----------+
| test_something | inconclusive | COM55 CMD timeout: set --retcode true | | | 153.316 |
+----------------+--------------+---------------------------------------+-------------+-----------+----------+
+---------------+----------------+
| Summary | |
+---------------+----------------+
| Final Verdict | INCONCLUSIVE |
| count | 1 |
| passrate | 0.00 % |
| inconclusive | 1 |
| Duration | 0:02:33.316000 |
+---------------+----------------+
12:09:47.551 Cleanup done.

Description

• Type: Bug

Bug

Icetea version
a52a860

Expected Behavior
Icetea initialises cliapp-based DUT correctly and DUT responds to first command.

Actual Behavior
Initial command times out:

11:32:07.145 | D1 <-> MainThread: Use normal serial write mode
11:32:07.145 | D1     MainThread: Reset serial device /dev/tty.usbmodem14541
11:32:08.555 | TC     MainThread: Waiting for dut 1 to initialize.
11:32:08.556 | D1 --> DutThread: set --retcode true
11:32:08.615 | D1 <-- DutThread:    _   ___ __  __               _            _  ___  ___
11:32:08.626 | D1 <-- DutThread: /_\ | _ \  \/  |  ___   _ __ | |__  ___ __| |/ _ \/ __|
11:32:08.636 | D1 <-- DutThread: / _ \|   / |\/| | |___| | '  \| '_ \/ -_) _` | (_) \__
11:32:08.648 | D1 <-- DutThread: /_/ \_\_|_\_|  |_|       |_|_|_|_.__/\___\__,_|\___/|___/
11:32:09.815 | D1 <-- DutThread: /> 
11:32:58.738 | D1     MainThread: CMD timeout: set --retcode true

Steps to Reproduce
Run icetea on macOS and a cliapp-based DUT with --reset flag.

E.g.: icetea --tcdir /Users/dongar01/ws/ble-suite/ble-tests --tc all --reset

Workaround
Looks like icetea is sending the first command too early.
Only send command after device has performed reset, adding a wait does the trick but slows down device initialisation.

@@ -586,6 +586,7 @@ 
class Dut(object):
         :return: Nothing
         """
         Dut._logger.debug("Start DUT communication", extra={'type': '<->'})
+        time.sleep(2.5)
         while Dut._run:
             Dut._sem.acquire()
             try: