Quick update on the config options switching to common: The team has confirmed this is a bug, and it’s currently being investigated. Thank you for the report!
I don’t known if it happens on a new template project. How can I use a new template with my existing project ?
To illustrate what happens, see the following output after invoking F5 on VSCode.
...
[10-04 13:26:23.766] Selecting device...
[10-04 13:26:23.788] Device 06852340 selected.
[10-04 13:26:23.789] Updating app configuration...
[10-04 13:26:23.834] Image is not up to date, building it (this may take some time)...
[10-04 13:29:45.362] Step 1/12 : FROM --platform=linux/arm64 torizon/qt5-wayland-vivante:2
[10-04 13:29:56.874] ---> ac9480d4076a
[10-04 13:29:56.903] Step 2/12 : EXPOSE 6502
[10-04 13:29:56.904] ---> Using cache
[10-04 13:29:56.905] ---> f0706834af12
[10-04 13:29:56.907] Step 3/12 : ARG SSHUSERNAME=torizon
[10-04 13:29:56.908] ---> Using cache
[10-04 13:29:56.909] ---> 54fa11141b11
[10-04 13:29:56.910] Step 4/12 : ENV DEBIAN_FRONTEND="noninteractive"
[10-04 13:29:56.912] ---> Using cache
[10-04 13:29:56.915] ---> 7c59382c9f9e
[10-04 13:29:56.917] Step 5/12 : RUN apt-get -q -y update && apt-get -q -y install gdbserver procps && rm -rf /var/lib/apt/lists/*
[10-04 13:29:56.920] ---> Using cache
[10-04 13:29:56.921] ---> 86baac177b83
[10-04 13:29:56.922] Step 6/12 : RUN if [ ! -z "libopencv-core4.4 libgomp1 libomp5 libcap2 libqt5core5a libqt5serialport5 libopencv-core4.4 net-tools openssh-client apt libopencv-imgcodecs4.4 libopencv-imgproc4.4 file libglfw3-wayland libatomic1 udev procps usbutils libusb-1.0-0 kmod pciutils libpng16-16 libjpeg62-turbo libglapi-mesa libglu1-mesa systemd vim fxload x11-apps strace feh libimlib2" ]; then apt-get -q -y update && apt-get -q -y install libopencv-core4.4 libgomp1 libomp5 libcap2 libqt5core5a libqt5serialport5 libopencv-core4.4 net-tools openssh-client apt libopencv-imgcodecs4.4 libopencv-imgproc4.4 file libglfw3-wayland libatomic1 udev procps usbutils libusb-1.0-0 kmod pciutils libpng16-16 libjpeg62-turbo libglapi-mesa libglu1-mesa systemd vim fxload x11-apps strace feh libimlib2 && rm -rf /var/lib/apt/lists/* ; fi
[10-04 13:29:56.924] ---> Using cache
[10-04 13:29:56.925] ---> b740ee64fdfa
[10-04 13:29:56.926] Step 7/12 : COPY ueye_4.94.0.1220_arm64.run ids-software-suite-linux-arm64-4.95.2-debian.tgz NITLibrary-bin-3.0.1.tar.gz libffmpeg-bin-3.2.18.tar.gz libboost-bin-1.62.0.tar.gz AlliedVision_Apalis_iMX8_Torizon-4.14.126-00001-ga39899f.tar.gz NUC.tar.gz entrypoint-torizon.sh /home/torizon/
[10-04 13:29:56.927] ---> Using cache
[10-04 13:29:56.928] ---> 10dbc86bedbb
[10-04 13:29:56.929] Step 8/12 : RUN yes y | sh /home/torizon/ueye_4.94.0.1220_arm64.run && tar -C / -xvf /home/torizon/NITLibrary-bin-3.0.1.tar.gz && ln -sf /lib/libNITLibrary.so.3.0.1 /lib/libNITLibrary.so && tar -C /usr -xvf /home/torizon/libffmpeg-bin-3.2.18.tar.gz && tar -C /usr -xvf /home/torizon/libboost-bin-1.62.0.tar.gz && tar -C /home/torizon -xvf /home/torizon/NUC.tar.gz && usermod -a -G plugdev torizon && usermod -a -G sudo torizon
[10-04 13:29:56.931] ---> Using cache
[10-04 13:29:56.932] ---> c4c3101b8f98
[10-04 13:29:56.934] Step 9/12 : ENTRYPOINT sudo sh -c "/home/torizon/entrypoint-torizon.sh" && stdbuf -oL -eL gdbserver 0.0.0.0:6502 /phosddvr/phosddvr_core_exe `cat appargs.txt`
[10-04 13:29:56.936] ---> Using cache
[10-04 13:29:56.937] ---> 1c5c61dcd717
[10-04 13:29:56.938] Step 10/12 : USER torizon
[10-04 13:29:56.938] ---> Using cache
[10-04 13:29:56.940] ---> 3b071c900958
[10-04 13:29:56.941] Step 11/12 : WORKDIR /phosddvr
[10-04 13:29:56.941] ---> Using cache
[10-04 13:29:56.942] ---> 79418dd2eeea
[10-04 13:29:56.943] Step 12/12 : CMD stdbuf -oL -eL gdbserver 0.0.0.0:6502 /phosddvr/phosddvr_core_exe `cat appargs.txt`
[10-04 13:29:56.944] ---> Using cache
[10-04 13:29:56.944] ---> 74dc21decaef
[10-04 13:29:57.701] Successfully built 74dc21decaef
[10-04 13:29:57.738] Successfully tagged phosddvr_arm64v8-qt5-vivante-no-ssh_bullseye_debug_513050ae-f541-4a8a-baef-1599a9e43911:latest
[10-04 13:29:57.832] Deploying image to device (may take a few minutes)...
[10-04 13:29:58.053] Deploying application to device...
[10-04 13:29:58.487] Image on target is already up to date.
[10-04 13:30:00.422] sending incremental file list
...
So it first says
[10-04 13:26:23.834] Image is not up to date, building it (this may take some time)...
(even though it uses the cache at every step) and then
[10-04 13:29:58.487] Image on target is already up to date.
which is a bit contradictory, isnt’ it ?
I also wonder how ENTRYPOINT (step 9) and CMD (step 12) are dealt with when executing the container ? It seems only ENTRYPOINT is executed and CMD is ignored (which is what I want).
Best regards,
Fabian
Hi @fdortu ,
I don’t known if it happens on a new template project. How can I use a new template with my existing project ?
I meant to test this on a new project altogether, to verify if this happens only on your project or if this is a general problem with the extension.
Looking at the logs you provided the build itself (steps 1 to 12) takes around 12 seconds to complete, which is expected. The unusual part is the time it takes before the build starts: it took 3 minutes when it should take no more than a few seconds. Can you check if you have the latest Docker version on your host computer?
I also wonder how ENTRYPOINT (step 9) and CMD (step 12) are dealt with when executing the container ? It seems only ENTRYPOINT is executed and CMD is ignored (which is what I want).
In a simple manner, if ENTRYPOINT and CMD are defined, ENTRYPOINT is executed and CMD defines the default arguments for ENTRYPOINT. More details can be found here: docker - What is the difference between CMD and ENTRYPOINT in a Dockerfile? - Stack Overflow
Best regards,
Lucas Akira
Build time issue
The speed issue was indeed linked to docker apparently. Actually docker was even refusing to launch this morning, and I had to uninstall and reinstall it. Now VSCode Torizon works as expected. Docker instabilities are quite frequent unfortunately.
Regarding ENTRYPOINT and CMD.
They are defined as follows in my example :
ENTRYPOINT sudo sh -c "/home/torizon/entrypoint-torizon.sh" && stdbuf -oL -eL gdbserver 0.0.0.0:6502 /#%application.appname%#/#%application.exename%#
#%application.appargs%#
CMD stdbuf -oL -eL gdbserver 0.0.0.0:6502 /#%application.appname%#/#%application.exename%#
#%application.appargs%#
So of CMD specifies the argument to be fed to ENTRYPOINT, my application should receive stdbuf -oL -eL gdbserver 0.0.0.0:6502 /#%application.appname%#/#%application.exename%# #%application.appargs%# as argument, which is not what I want, and it is apparently not the case because my application displays all the arguments that are passed and I don’t see it.
From your stackoverflow link (look at The tables below shows what command is executed for different ENTRYPOINT / CMD combinations: ), it seems that CMD is passed to ENTRYPOINT only if entrypoint is defined with the [" ", " " ] syntax, which is not my case. So its seems CMD is ignored in my case, which is what I want.
Thanks for all your support. I think this issue is solved now!
Fabian
1 Like
