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 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: 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: As reported on Pyhton app ownership issue, the release Dockerfiles for Python pass the wrong argument to "setup.sh", leading to a wrong app ownership issue.

Description: This is a regular maintenance task and not impact users, unless you want to build Moses from source. As versions of libraries used by Moses mismatch, it fails to start with the error "ModuleNotFoundError: No module named 'openapi_spec_validator.handlers'"

Update: if you want to build Moses from source, use the "dev" branch, where this is fixed.

Description: To make it easier for you to set up your own CI pipeline from a project built with VS Code, we plan to write documentation and create an example.

Update: documentation is available on Visual Studio Code Extension for Torizon - Continuous Integration and Conntinuous Delivery.

Description: The Torizon IDE Backend Command-line Interface does not allow building the SDK container for C/C++ projects. Due to this, it is currently not possible to build such projects in a CI environment.

Update: this task has been rejected because SDK operations including build the SDK, are already supported.

Description: The current Torizon QtDesignStudio support plugin asks for a folder where the QtDesignStudio is installed. Any input, even a valid one, triggers a red error saying "URI with a scheme is expected".

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: When trying to execute the command Torizon: Build release container for the applicationon Qt-based C/C++ projects the source code does not compile, showing the following error: make: *** No rule to make target 'install'. Stop.

Workaround: Workaround: Switching to the release configuration with the command `Torizon C/C++: Switch to release configuration`, executing the default build, deploy and run on debug mode command by pressing `F5` and them running the command `Torizon: Build release container for the application`

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.