Torizon IDE Extensions Issue Tracker

Description: If you build a custom Torizon OS image and the string "TorizonCore" is not present in the NAME variable on /etc/os-release, the IDE Extension doesn't work.

Workaround: Make sure your custom build includes the string "TorizonCore" in the NAME.

Description: The Torizon IDE Extension for VS Code must be installed inside WSL on Windows machines. If you try to install it outside WSL a message tells that Windows is not supported.

A clear message was added to the extension description to help users find out how to install on Windows - which is through WSL.

Description: The IDE 1 is in maintenance mode, and new projects must use the IDE 2. To clarify this with new users, the version 1 is being set as deprecated on the VS Code marketplace, so you don't install it by mistake and start using it on a new project.

Description: Since CMake is a common build system, a template will be added to the vscode-torizon-templates.

Description: For Windows users, the Toradex SoMs IP are listed instead of their hostname, which makes the user experience of the IDE Extension less optimal.

Description: When using a C++ Qt QML project, a warning about Python is printed "No qmlls can be found in current Python environment."

Workaround: Just ignore the warning.

Description: After connecting a device to the IDE Extension 2 for the first time, the following message is printed in the device debug UART or SSH session: WARNING: THIS DEVICE IS IN ENGINEERING MODE

To provide a more meaningful message, a hyperlink to https://developer.toradex.com/torizon/application-development/ide-extension/ is printed so you can learn more about it.

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

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: When a C/C++ project is opened inside a container on VS Code - which is common - it is not possible to enable ARM emulation. This is because ARM emulation must be enabled on the host.

Workaround: Either (1) close the remote container and run the command again or (2) run the command from the command-line.

Description: The EnvironmentName on an ASP.NET project is being defined as Production even if you are developing in Debug Mode.

Update: there are no plans to fix this potential bug, because it is considered a configuration issue. A potential fix might adversely impact other customers' projects.

Workaround: Add the following line to your project's ".vscode/launch.json" file:

"env": { "ASPNETCORE_ENVIRONMENT": "Development" },

Description: An end-user has a specific application that uses WebSockets to connect back to a PC running a standalone application. When running their app in a container manually on the target, the connections to the PC go through. However, when debugging their app from within the IDE extension, those connections are never seen by the PC.

Update: this task has been rejected because the issue was on misuse of "System.Net.WebSockets". As general advice, if you face a similar issue, and you can use a library that provides a higher level of abstraction, that might help prevent such type of error.

Description: Running version 1.4.271 of the IDE extension under VSCode for Windows, a customer trying to deploy a .NET Core console “hello world” app gets a popup that “The pipe program ‘ssh’ exited unexpectedly with code 255.”

Starting: "ssh" -T -p %{port} -i %{keypath} -o StrictHostKeyChecking=no -o "UserKnownHostsFile /dev/null" %{devicelogin} "/vsdbg/vsdbg --interpreter=vscode"
Error from pipe program 'ssh': Bad port '%{port}'
The pipe program 'ssh' exited unexpectedly with code 255.

Description: The IDE Extensions debugger comes configured in a way that it’s very easy to debug the application source code. It does not include symbols and source code for the Debian packages in the SDK, though.
This makes it one step harder for users to get more meaningful stack traces or “step into“ library functions, often useful to debug potential issues with the libraries themselves.

Workaround: To shorten this gap, it was documented one way to allow library debugging on Add Debug Symbols and Source Code From Debian Feeds.

Description: At the moment, often the Torizon configuration files are modified and Git keeps stating they have changed. It contains info that is not essential to the project. Let's call this info *environment configuration*.
On the other hand, the same file has very important info that is essential to the project and that only changes when you modify them, let's call it *project configuration*.
It is annoying to keep being asked to commit environment configuration if needed at all. We plan to split it into two files and keep the environment configuration in .gitignore.

Description: VS Code has a feature to remote access another development machine through remote SSH connections.
You may have two machines where you do development: (1) is a headless machine where the processing is done, and (2) is a computer where you run VS Code and do the programming.
Also, the same mechanism is used by VS Code when you have (1) an instance of VS Code installed on Windows and (2) want to create a Torizon C/C++ project in WSL.

In such situations, when creating a Torizon C/C++ project you will get the following error: The Remote-Containers extension (ms-vscode-remote.remote-containers) is required to develop C/C++ applications on Torizon.

Workaround: Currently, it is only possible to create a new Torizon C/C++ project on a local machine, without the use of the remote SSH connection. Please create your project on the same machine you have VS Code installed and don’t use WSL.

Description: When you deploy and debug a Python application for the second time in a row, VS Code may not switch focus from the terminal to the debug console.

Workaround: Manually click on the debug console to switch focus.

Description: Actually, any change to the configuration will force a rebuild of the container. This, in addition to the need of re-deploying it to the device, increases development time.

Description: The project configuration is autogenerated and stored on a "config.yaml" file in the project directory. When this file is changed manually - for example, on a "git checkout" - the IDE does not recognizes changes, which leads to build errors.

Workaround: Whenever you check out a new git branch, reload the VS Code window.

Description: At the moment, we only support creating Torizon projects using the VS Code command palette. For new users, it may be interesting to have a button that guides them through their first project creation.

Workaround: Create and configure a project from the command palette.

Description: Often when developing an app that has a remote UI or any kind of back-end server over the network, one has to do the following:

• Open browser
• Find IP or copy hostname, e.g. `apalis-imx8-01234567.local`
• Paste on browser

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.