building python 3.10.1 on jetpack 4.5.1 and the jetson xavier nx

This is a follow-up to my last Python build and installation back in February ( /2021/02/14/building-python-3-9-1-on-jetpack-4-5-and-the-jetson-xavier-nx/ ). That post has all the directions for setting up a build environment including installation of all packages. This time I downloaded the source to Python 3.10.1, unpacked it, and built it. I then performed an alt-install as before. Everything went well until the very end, when the alt-install process spit this out (see all the highlighted lines):

WARNING: Value for scheme.headers does not match. Please report this to <https://github.com/pypa/pip/issues/10151>distutils: /usr/local/include/python3.10/UNKNOWNsysconfig: /ssd/jetson/Python-3.10.1/Include/UNKNOWNWARNING: Additional context:user = Falsehome = Noneroot = '/'prefix = NoneLooking in links: /tmp/tmplaxd5qzjProcessing /tmp/tmplaxd5qzj/setuptools-58.1.0-py3-none-any.whlProcessing /tmp/tmplaxd5qzj/pip-21.2.4-py3-none-any.whlInstalling collected packages: setuptools, pip  WARNING: Value for scheme.headers does not match. Please report this to <https://github.com/pypa/pip/issues/10151>  distutils: /usr/local/include/python3.10/setuptools  sysconfig: /ssd/jetson/Python-3.10.1/Include/setuptools  WARNING: Value for scheme.headers does not match. Please report this to <https://github.com/pypa/pip/issues/10151>  distutils: /usr/local/include/python3.10/pip  sysconfig: /ssd/jetson/Python-3.10.1/Include/pipSuccessfully installed pip-21.2.4 setuptools-58.1.0WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

I have never had a problem before now, and I suspect it’s all to do with Python 3.10. I went looking for an explanation and fix ( see https://stackoverflow.com/questions/67244301/warning-value-for-scheme-data-does-not-match-when-i-try-to-update-pip-or-inst for example), but the explanation(s) are confusing, with the general consensus as “don’t worry about it.” Which I consider crap.

So far 3.10.1 seems to work, with one notable exception: you can’t install PyQt6, as there is no qt6-default support package, and PyQt6 won’t build without it. You’re thus stuck with PyQt5.

Determining Various Version Numbers

This section is primarily for me to remember for the future. I’m tired of looking it up.

To determine what version of Ubuntu you’re running:

$ cat /etc/os-release NAME="Ubuntu"VERSION="18.04.6 LTS (Bionic Beaver)"ID=ubuntuID_LIKE=debianPRETTY_NAME="Ubuntu 18.04.6 LTS"VERSION_ID="18.04"HOME_URL="https://www.ubuntu.com/"SUPPORT_URL="https://help.ubuntu.com/"BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"VERSION_CODENAME=bionicUBUNTU_CODENAME=bionic$

To determine what version of Jetpack you’re running:

$ sudo apt-cache show nvidia-jetpackPackage: nvidia-jetpackVersion: 4.5.1-b17Architecture: arm64Maintainer: NVIDIA Corporation...

 

dealing with buggy software: visual studio code rendering issue

Ubuntu 20.04.2 running as a full desktop VM within Parallels on macOS 11.2.2

I have for some time now been running multiple versions of Linux as VMs on my 2019 MacBook Pro via Parallels. Up to this point everything has run smoothly. Until recently, that is, with Visual Studio Code. For whatever reason, something was altered within VSCode that causes it to completely render the display either as you see it above, or if I resize the window, as a red-only window with the white, in which the black is replaced with red. I at least traced to the release where the problem did not occur to 1.52.1, the November 2020 release. Every release since then has exhibited this problem.

Normally I’d take this as something of a challenge and try to find and fix the issue, but before I decided to dive in and look into it I fired up a RHEL 8.3 VM. I had VSCode installed on it and I needed to do some rather quick code work inside VSCode. I have all my VMs sharing common data using a folder on the Mac so it’s rather easy to keep data and source code easily synced. Unfortunately the same problem reared its ugly head on the RHEL VM.

I believe that there is something unique about the current release of VSCode that causes it to improperly render when running within a Parallels Linux VM.

In the mean time I’ve dropped back to VSCode 1.52.1 and blocked it from being updated. I’ve also built and installed Emacs 28, just like I did on the Nvidia Xavier under Ubuntu 18.04. If this problem remains unsolved in VSCode then it looks like I’ll stick with Emacs.