Torizon IDE Extensions Issue Tracker

Description: As reported on ApolloX Multicontainer Project generates files with absolute path, having absolute paths on multicontainer projects leads to a bad UX when sharing the project with other colleagues, who will download the project in different directories.

Description: Due to the version of pip available on the Ubuntu 22.04 LTS package feeds being too old, an error installing dependencies with pip prevents the Python debug to work.

Workaround: Upgrade pip with "pip install --upgrade pip" instead of using the apt package manager.

Description: If you save a project in the Windows file system, a huge performance drawback will happen due to this Windows-Linux file system translation being done through a network protocol, leading to 10x slower build times.

Workaround: Create a project in a folder that is not "/mnt/c"

Description: When the host PC has more than one network interface, the extension will pick the first one, which may not be the interface that the target device is connected to. This leads to the extension not being able to connect to the target.

Workaround: Edit the "host_ip" in the VS Code settings.json to use the IP address of the network interface that is the same one the target is connected to.

Description: The Torizon IDE Extension 2 has a feature that allows a user to update their project against the latest version of the template that created it, so they get the latest features and fixes at the template level.

For TorizonCore Builder templates, this feature does not work, and the following error is displayed: "Cannot find path '/home/username/.apollox/tcb/.conf/update.json' because it does not exist."

Description: The Torizon IDE Extension 2 does not connect to the device if the password has special characters, with the error "undefined".

Description: As reported in a community post , when a device IP changes, the insecure registry entry is not updated in the daemon.json. This generates a "Device not reached! Please check if the device is turned on and connected to the network" warning message followed by a device not reached error.

Workaround: Remove the device from the IDE extension device list and re-add it.

Description: The Toradex templates for the IDE 2.0 come with integrated CI pipelines for popular platforms. In this task, GitLab CI integration is added.

Description: As ASP.NET is a popular web development framework, Toradex will provide a ASP.NET Blazor Server template for the new IDE Extensions.

Description: In a few scenarios, setting the user inside the container as "root" instead of "torizon" is required. The IDE Extensions debugger process needs to know this information somehow, in addition to setting it on the Dockerfile or the Docker Compose file.

Description: The .NET Console and Uno templates are not working when deployed to the board, with the error "unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /var/rootdirs/home/torizon/Dockerfile.debug: no such file or directory".

Description: Different TorizonCore releases may use different versions of Debian Containers for Torizon. For example, in TorizonCore 5, containers are based on Debian Bullseye whereas, in TorizonCore 6, they are based on Debian Bookworm.

Due to this, a mechanism to allow you to create a project for the version of the Debian containers that matches the version of TorizonCore you are using is required.

Description: In the IDE 2.0, also known as ApolloX, it is envisioned that the integration with the Torizon Platform Services - possible through their API - is part of the development workflow and the project lifecycle from day 1, and not just a command to run at the end of the development cycle right before release.

To achieve such goal, we plan to setup projects around a DevOps-oriented workflow where the CI pipelines already have steps that integrate with the Torizon Platform Services, including operations such as pushing the application to the platform and deploying it to a test fleet of devices.

The CI pipelines will be provided for GitHub Actions.

Description: In the latest Docker installation instructions for Ubuntu which is the Linux distro we test ApolloX against, Docker Compose V2 is installed. Therefore, all templates are being updated to call Docker Compose V2 as "docker compose" instead of "docker-compose", which was the default way for Compose V1.

Workaround: Either install Docker Compose V2 on your development PC (recommended), or symlink/alias the "docker-compose" to point to "docker compose".

Description: Documentation for ApolloX will be released as it gets promoted to stable.

Description: The new Torizon IDE will have a repository with two types of templates: (1) those maintained by Toradex and (2) those provided and maintained by the community. This task aims to create the repository and structure.

Update: the repository is available on our GitHub as vscode-torizon-templates.

Description: We plan to make some changes to .gitignore files, deprecating project-specific entries. With that, we will also document what is supported and what is expected from users with regards to .gitignore files generated by the IDE Extension.

Description: The new IDE 2.0 Extension for Torizon, also known as ApolloX, is meant to be a tool that simplifies the development workflows for TorizonCore. This includes OS customization and integration tests.

By providing a TorizonCore Builder template, we allow customers to easily develop their application against a custom TorizonCore, as well as simplify the deployment of such apps and custom OS on a CI pipeline.

Description: The IDE extension CLI documentation is outdated, missing the information about the new CI/CD Pipeline Generation Command and it should be updated. Also, the IDE Extensions back-end is built and published as a standalone package, meant to be used in CI scripts. It is available on our artifacts server.

The documentation on how to install it is outdated, stating that one must also install either the Visual Studio or the VS Code extension, while it is not necessary anymore.

Description: The error "FileNotFoundError: [Errno 2] No such file or directory: '/credentials/credentials.zip'" happens when trying to push files to OTA from the VS Code extension on a C/C++ project.

Description: Today in a CI/CD environment, you need to write a "docker run" command to build the application. This disrupts the IDE Extensions experience since while on the IDE this is made by VS Code behind the scenes, using data present in "launch.json" and "tasks.json".
We will introduce a command on VS Code that generates the build instructions, so the UX of setting up a DevOps CI pipeline is simplified.

Update: the command is available in the early access release, and documentation on how to use it in the Visual Studio Code Extension for Torizon.

Description: Recently, the support of some SoMs was dropped (apalis-imx8x, colibri-imx8x-v10b, colibri-imx7, colibri-imx6ull) and others were added (colibri-imx6ull-emmc). We are reviewing the list of supported SoMs, adding the missing ones and removing the obsolete ones.

Description: The IDE Backend for our VS and VS Code extensions is bundled with the IDE Extensions installers. This means that, in practice, if you want to install it you must also install an extension.
This is not ideal for CI/CD pipelines, therefore we plan to release the backend standalone, so it can be easily integrated.

Update: this is done and Moses is being published on https://artifacts.toradex.com:443/artifactory/ideextension-moses-prod-frankfurt/moses-linux.zip.

Description: The extension currently relies on a number of protocols and ports that are used on the host machine. When access to these are blocked by firewall/antivirus it can cause the extension to fail in ways that aren't obvious to debug.

Additionally, this info is useful to use Moses in a CI environment. This is especially useful given that projects that use an SDK (C/C++) run on a different port.

Description: To learn more about this bug, refer to the community post Visual Studio 2019 remote connection issue on Verdin iMX8M Mini

Description: When a tag is configured, it should be used by the generated commandline and docker-compose file to make them more generic.

Description: The IDE Extensions should be able to push docker-compose files to Torizon OTA.

Description: When creating or opening an existing C/C++ application, a console reports "chgrp: changing group of '/var/run/docker.sock': Operation not permitted".

Workaround: While this message seems alarming at first sight, it has no negative impact and you can ignore it.

Description: When running the command "Torizon: export docker-compose file", the generated Docker Compose file misses cgroup rules configured in the project.

Workaround: Manually add the cgroup_rules to the generated Docker Compose file. Check out the Compose v2 reference doc.

Description: The first time that a c/c++ project is loaded, also every time the devpackages change which lead to a reload and rebuild of the SDK (that uses the devcontainer feature) the extension is not loaded and in fact is disabled.

Workaround: To enable it, the workaround is to reload the window (ctrl+shift+p->→ Reload Window)

Description: This error is a side-effect of another known bug, in which device_cgroup_rules is not being properly added to the autogenerated Docker Compose files.

Description: Verdin iMX8M Plus support in the IDE Extensions.

Description: Base container for arm64-wayland platform does not include Vivante drivers.

Description: It's possible to specify a docker-compose file for an application and it will be merged with additional parameters to run the application. The docker-compose file can be specified also by the platform (ex: for platforms who need to run weston), but it is ignored during export.

Description: Using a local Docker registry improves performance and decreases dependencies on external projects.

Description: Add support to Colibri iMX6ULL in the IDE extensions.

Description: Add support to generated Dockerfiles and docker-compose files in the IDE Extensions.

Description: The versions of .NET Core 3 and .NET 6 must be bumped to the latest. This is in preparation for our upcoming stable release.

Description: We have found a high-severity vulnerability in the NPM package simple-get tracked by CVE-2022-0355 when running "npm audit" in our CI pipeline. If you are using the extension V1.3.0, please switch to the latest early access release.

Description: When creating a new ASP.net application, you will see the following error: Internal server error :: Error (500) - 'PlatformConfig' object has no attribute 'init_validation_tables'

Description: When trying to set device_cgroup_rules in the extraparams property, a syntax validation error prevents from proceeding.
If setting up the property as device_cgroup_rule just to be able to continue and after that edit the YAML, another syntax validation error happens when trying to set the rules to \[ "c 199:* rmw" , "c 226:* rmw" ].

Workaround: Edit the property manually inside the file "appconfig_0/config.yaml".

Description: A vulnerability in the NPM package "follows-redirects" has been patched and we must update to using the patched version as soon as possible. Learn more about the vulnerability on CVE-2022-0155: Exposure of sensitive information in follow-redirects

Description: When editing environment variables in the tasks.json file, for example when configuring a C/C++ build, the extension overwrites - and therefore ignores - them during the build process.

Workaround: This is fixed. Update to the latest early access of the VS Code extension.

Description: Due to validation files missing for .NET Blazor applications, it is not possible to create projects for the provided Blazor templates.

Description: To make the user experience with the extensions more reliable, we have introduced input fields validation. With it, file paths with some characters like dot (.) and dash (-) were evaluated as invalid, even though they are actually valid.

Description: A customer reported that when he tries to deploy his application using the VS Code Extension, it was taking way too long. He noticed that each time he tried to build the image, a new appconfig_0 folder would be created inside of the previous one, in a loop-like format. This issue only affects .NET projects.

Description: Currently when developing Qt applications there seems to be a limitation with debugging Qt data types/objects. For example when debugging the value of a `QString`, you'll see basic information like the size of the data, but it won't actually show the value of the string. This is due to Qt implementing somewhat complex data types that can't be easily parsed by GDB. So we should seek to improve the debugging experience for Qt applications, by at least allowing proper debugging of Qt-specific data types, if possible.

Description: Often during development, you may need to reboot your device. We are conveniently adding reboot and shutdown buttons to our IDE Extensions, so the task is made easier.

Description: The IDE Extensions should be able to push docker-compose files to Torizon OTA.

Description: It seems that images that include extra attributes are no longer converted to HTML in the right way by the website.

Description: Docker on Windows generates an internal exception when the IDE backed checks if the SDK container is actually running. This behavior is not reproducible on all Windows 10 machines, even when they run the same docker ad Windows 10 releases.

Description: When a download error happens the operation will not complete, no error message is shown and the menu option remains grayed out until visual studio is restarted.

Description: Sometimes Visual Studio displays the message "Visual Studio stopped responding for X seconds. Disabling the extension Torizon Visual Studio Development Tools might help". It may be possible to optimize the plugin to avoid it from happening. Despite the latency caused by Visual Studio becoming non-responsive, there are no side-effects reported.

Workaround: Just click "Don't report this extension again".

Description: This can be done using CMake and may be provided as a template. The project should be minimal, building a library with one function and an executable calling it. It could be used to show how to do this and also how such a thing can be debugged.

Description: The IDE Extension causes a high CPU usage when checking if Docker is running.

Description: After installing the latest Early Access on Visual Studio Code, every time Visual Studio Code is opened, the user is prompt to accept the NXP EULA.

Description: Using VSCode version 1.55.2 or newer a random invalid device appears in the devices list and features like starting the debugger or creating a new project stop working.

Description: When the extra-parameter "network_mode" is set to "host" the debugger stops working.

Workaround: Issue has been fixed in v1.3.117, available via early access on marketplace.

Description: Our template code does not append a newline after the message, this means that no output is visible in the output terminal until a new line is printed or execution terminates. Since this may be confusing for new users doing step-by-step execution, we should add a line ending to fix the issue.

Description: The rw mount specifier is appended to the mount point name using the wrong separator, this leads to an incorrect mount point name inside the container.

Description: If a user configured git to convert line ending from the original format to Windows CR+LF this will change the setup.sh and cleanup.sh scripts, generating an error when those are executed in the Linux container during build.

Workaround: Convert startup.sh, cleanup.sh and requirements.txt to unix-style line endings.

Description: the torizon.ccpp.getHostTriplet command that can be used in tasks returns a string that is missing the last character, this can lead to build errors.

Description: This may happen when a device is deleted or when the information is refreshed, the info panel content is not refreshed and may show old information.

Workaround: Click on the object to refresh the information.

Description: In C/C++ projects when changing configuration from arm32 to arm64 or vice-versa the system may not rebuild the final executable (depending on the build system) and this may lead to a wrong exe being executed on the target during debug/release.

Workaround: Manually rebuild application when changing active configuration.

Description: Uno Platform templates integrated into the IDE Extensions.

Description: Fix a change in packages for vivante-imx8 specific libraries that broke the platform template used by the extension.

Description: It's possible to specify a docker-compose file for an application and it will be merged with additional parameters to run the application. The docker-compose file can be specified also by the platform (ex: for platforms who need to run weston), but it is ignored during export.

Description: This can be fixed by forcing the different controls using during app creation to ignore focus change. The user will have to press ESC to abort project creation.

Description: Update .NET runtime version to 5.

Description: The IDE extensions should be able to push container image to a registry.

Description: When building an image, during the apt-get update command execution you may get the following error: {code:bash} Release file for http://snapshot.debian.org/archive/debian/20200908T070000Z/dists/bullseye/InRelease is not valid yet (invalid for another 18513d 2h 11min 31s). Updates for this repository will not be applied. {code} When this happens time on the linux/arm platform seem to be set to the wrong date (usually the beginning of unix epoch). You can test this by running a standard debian image: {code:bash} docker run -it --rm --platform linux/arm debian:bullseye-slim Unable to find image 'debian:bullseye-slim' locally bullseye-slim: Pulling from library/debian 5ed966da184b: Pull complete Digest: sha256:6dd2509b000570c24fbf0dd6ea4c907227e36f77b8a7ca2b818464bbff8287dc Status: Downloaded newer image for debian:bullseye-slim root@cb280c464483:/# date Thu Jan 1 00:00:00 UTC 1970 {code}

Workaround: Usually just running the container build multiple times solves the issue. Restarting docker also works, but if you are using VSCode inside a container this will force you to exit the system.

Description: Add support to Debian Bullseye in the IDE extensions

Description: This setting can be used to configure additional settings related to container execution. It's available in Visual Studio Code UI, but not in Visual Studio 2019.

Description: Customer in referenced community post has an issue in the VScode extension where attempting to add a device via serial seems to fail.

Description: Run "Torizon: Rebuild SDK and reload in container" results in an EPERM error (3).

Description: Docker on Windows generates an internal exception when the IDE backed checks if the SDK container is actually running. This behavior is not reproducible on all Windows 10 machines, even when they run the same docker ad Windows 10 releases.

Description: When debugger is started the project is correctly built and deployed, but then debugger fails to start

Workaround: Add .local as suffix to the device hostname or replace hostname with the device IP address.

Description: When building an image, during the apt-get update command execution you may get the following error: {code:bash} Release file for http://snapshot.debian.org/archive/debian/20200908T070000Z/dists/bullseye/InRelease is not valid yet (invalid for another 18513d 2h 11min 31s). Updates for this repository will not be applied. {code} When this happens time on the linux/arm platform seem to be set to the wrong date (usually the beginning of unix epoch). You can test this by running a standard debian image: {code:bash} docker run -it --rm --platform linux/arm debian:bullseye-slim Unable to find image 'debian:bullseye-slim' locally bullseye-slim: Pulling from library/debian 5ed966da184b: Pull complete Digest: sha256:6dd2509b000570c24fbf0dd6ea4c907227e36f77b8a7ca2b818464bbff8287dc Status: Downloaded newer image for debian:bullseye-slim root@cb280c464483:/# date Thu Jan 1 00:00:00 UTC 1970 {code}

Workaround: Usually just running the container build multiple times solves the issue. Restarting docker also works, but if you are using VSCode inside a container this will force you to exit the system.

Description: Add support to Debian Bullseye in the IDE extensions

Description: Publish one additional extension in the marketplace (for each IDE) called Preview to release development versions of the Extensions.

Description: Using VS Code Insiders version with the C/C++ Template returns "Error property 'program' is missing or empty"

Workaround: This is an internal version, so no public workaround

Description: Qt applications development support in VS Code.

Description: When trying to add files/folder that are located outside of the the main VS project folder the project folder structure then gets altered. This alteration of the folder structure then causes things like compilation and debugging to fail.

Description: Visual studio code activates the extensions on different event. Torizon extension is activated and loaded when an existing project is opened, when a new python or .NET application is create or when the Torizon bar is used. ASP.NET app creation command was not considered an activation event and so it fails if you try to execute it when the extension is not already loaded.

Workaround: Open the torizon bar by clicking on the Torizon logo in the Visual Studio code Activity Bar on the left side of VS Code main window, this will activate the extension and allow you to run the ASP.NET application create command.

Description: ASP.NET provides multiple application types. Current template uses basic MVC, but this may not fit customer’s requirement. New templates has been added for most of the ASP.NET application types supported by the “dotnet new” command. A more flexible template definition (via YAML file) has been added and may allow definition of more templates also for other languages.

Description: Currently settings added via the "env" property are applied only when the application runs in the release container. Debugger connects over SSH and those variables are not defined when the application runs.

Description: Error in Visual Studio Code extension when adding device from network

Description: In the VS Code Extension for Torizon 1.x (early access only), the TorizonCore Builder integration has been added to the main extension, as documented on TorizonCore Builder VS Code Integration.

In the version 2.x, also known as ApolloX, we reintegrated the TorizonCore Builder support. ApolloX uses TorizonCore Builder VS Code extension as a dependency for OS customization features.

Description: For C/C++ projects, the devcontainer fails to load with "Exit code 1". This happens since the Microsoft Remote - Containers version 0.238.2 was released.

We have reported the issue upstream and are following-up on it: Problem when opening a devcontainer on Ubuntu 20.04

Update: Further investigation seems to indicate that a newer version of Docker (20.10.17) fixes the issue.

Workaround: Either downgrade the Remote - Containers extension to version 0.234.0 or upgrade Docker to version 20.10.17

Description: This is not a supported use case.

It is currently not possible to configure a custom base image for the container in a project created via the Torizon Visual Studio Code Extension. This does not affect projects that can use the images that are provided in the templates.

Workaround: If you must start from a base image that is not supported, you must write and build your own Dockerfile.

We are working on a new template-oriented concept for the VS Code IDE Extension, where it will be possible to configure this field.

Description: When creating a new TorizonCore Customization Project with the VSCode IDE Extension, it prompts you to select the TorizonCore version to be used. After the setup is finished, the generated template tcbuild.yaml sets the property "build-date" as "NaN"

Workaround: For quarterly or LTS images, remove the "build-date" field.

Description: A new project configuration is useful in some cases, for example when adding support for two different platforms (32-bit and 64-bit) in the same project, or testing a new configuration for the same platform.

In the command palette, the command to add a new configuration will be rephrased from "Torizon: Add support for a different platform" to "Torizon: Add a new configuration".

Description: As of today, to keep IDs and keys outside a Git repository, you need to run the command Torizon: Remove IDs and keys from application

We plan to deprecate this command and keep all related files ignored in the .gitignore that generated when you create a new Torizon project from template.

Description: Currently, when exporting a Docker Compose file, the default name is "# docker-compose.yml", but sometimes it is reported by users that the file name defaults to whatever name of the directory you plan to save it to.

Workaround: Rename your file before saving it for the first time. If you have already saved it with the wrong name, rename the file to your liking.

Description: It was only possible to reproduce it in the case that the tag parameter was set as "" instead of "/". But this is not a bug, as the proper way to push images to Dockerhub (or another registry) is by using the tag as "/".

Refer to the Docker tag reference for more information.

Description: The Visual Studio Extension for Torizon does not support a CMake oriented workflow.

Workaround: We focus our development on the Visual Studio Code Extension for Torizon. It is a cross-platform environment, supports the C/C++ workflows and already provides templates for CMake.
Read the article C/C++ Development and Debugging on TorizonCore Using Visual Studio Code to learn more.

Description: As of now, the IDE extensions provide a field name "extraparams" that allows users to pass extra arguments to the Docker calls when running a container. Those extra arguments are expected in the Docker Python API syntax, since it is the same API used by Moses, the IDE back-end.

This is a bit confusing, since everywhere else in our documentation we use the command-line syntax instead. Therefore, to bridge this gap, we are introducing a configuration field named "dockercmdline" that has the same purpose as "extraparams" but accepts the command-line syntax instead of the Python API syntax.

Workaround: Use "extraparams" with the Docker Python API syntax

Description: In the VS Code IDE Extension info panel, some memory numbers are presented in full, instead of using engineering notation (for example kB, MB, GB, etc.). This makes it hard to read those numbers.

Description: It's possible to fix the issue by configuring a custom port in launch.json (replacing the ${port} entry) and by adding to buildcommands a command that changes it in sshd configuration.

Description: Although it is possible to choose and add a TCB template to create a multi-container project, this is not supported yet.

Description: We don't have resources to add and - especially - maintain .gitignore files for all technologies we support (C Makefile, autotools, CMake, Qt QML, Qt Widgets, and so on). Let's call this project-specific entries.
We want, though, to keep .gitignore for everything that we create and users should not keep versioned. Let's call this Torizon-specific entries.
For this reason, we are removing support for project-specific entries and keeping only the Torizon-specific ones.

Description: When exporting a docker-compose.yml using the VS Code extension, the "cap_add" field is formatted in a way that makes the YML file invalid. This required manual intervention to fix the file syntax after exporting it.
There are many scenarios where you'd need to set the "cap_add" field. One of them would be to configure the container to use the host network, required for using the CAN on TorizonCore.

Workaround: Manually fix the syntax issue.

Description: When opening a project that has no SDK container the tool should prompt for a rebuild. Unfortunately this does not happen 100% of the times.

Workaround: Rebuild SDK container manually when re-opening the project on a different machine or after having removed containers from your development machine.

Description: After adding the --delete flag to ensure that files removed from application folder on dev PC are also removed from the host there is an issue with the __pycache__ folder, created by the python interpreter. When root is used as container user, the folder is owned exclusively by root and can't be deleted by rsync running as torizon.

Workaround: There are multiple workarounds: - run the application as torizon user until issue is fixed - add ENV PYTHONDONTWRITEBYTECODE="1" as env property to avoid cache generation from python interpreter - manually cleanup the pycache folder before deployment

Description: As reported in the Toradex community, on the post Specify the GPU using ApolloX - create-production-image, some tasks and their respective required properties are not well-described, thus leading users to not be able to use them without asking the Toradex support.