[BUG] Unable to install (again) after executing some system maintenance

[jeff9finger-usda]

toshy-services-log.txt toshy-services-status.txt toshy-out.txt

(EV) Toshy env module sees this environment:
                 DISTRO_ID       = 'rhel'
                 DISTRO_VER      = '8.10'
                 VARIANT_ID      = 'notfound'
                 SESSION_TYPE    = 'x11'
                 DESKTOP_ENV     = 'gnome'
                 DE_MAJ_VER      = '3'

Bare metal or virtual machine: (If in VM, which VM software): VMWare Workstation Pro 17.5.2 build-23775571

Keyboard type (IBM, Chromebook, Windows, Apple): Windows (I guess) Logitech MX Keys Mini Keyboard device name (try 'toshy-devices'):

$ toshy-devices 

List of devices seen by the keymapper (xwaykeyz or keyszer): 

Neither "xwaykeyz" nor "keyszer" command was found in: 
/home/vmuser1/.config/toshy/.venv/bin:/home/vmuser1/.nvm/versions/node/v18.17.1/bin:/home/vmuser1/.local/bin:/home/vmuser1/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/vmuser1/.local/share/JetBrains/Toolbox/scripts:/home/vmuser1/.local/share/JetBrains/Toolbox/bin:/home/vmuser1/.local/share/JetBrains/Toolbox/scripts:/home/vmuser1/.local/share/JetBrains/Toolbox/scripts.
Toshy config cannot be loaded until one of these is installed.

---

Executed setup_toshy.py prep-only as admin user. Completed successfully Executed setup_toshy.py install as non admin user (who can still execute sudo). Failed See [toshy-out.txt]

[RedBearAK]

Isn’t this probably the same issue of needing to remove the older Python “devel” package that interferes?

Downloading Packages:
(1/2): python36-devel-3.6.8-39.module+el8.10.0+20784+edafcd43.x86_64.rpm                                                      30 kB/s |  17 kB     00:00    
(2/2): platform-python-devel-3.6.8-62.el8_10.x86_64.rpm                                                                      295 kB/s | 241 kB     00:00    

The reason the reinstall was needed was most likely the new Python version. Looks like RHEL 8.10 brought in Python 3.12 to replace 3.11.

I think once you do the same thing you did last time it should succeed in finishing.

[jeff9finger-usda]

Yes. I think that is correct. I mainly6 just wanted to report it, for visibility. I will try the things we tried before and let you know

[jeff9finger-usda]

Executed the following and it works. Hope this helps others. @RedBearAK Thanks

$ sudo dnf remove python36-devel
$ sudo dnf install python3.12-devel
$ ./setup_toshy.py install

[RedBearAK]

@jeff9finger-usda

I appreciate the thorough report and log attachments, and the follow-up showing the same solution still works. I'll continue to try to find a better solution to the package conflict during the build process, when I get some time.

[RedBearAK]

@jeff9finger-usda

I took a closer look at the way the installer handles the "quirks" of RHEL 8, to get it into a state to continue installing the full package list. As part of that, it figures out the latest version of the Python packages that are available to use for the Python virtual environment, to get something newer than the default Python 3.6 that isn't compatible with the keymapper. So it's already pre-installing a few packages like python3.12-devel on RHEL 8.10 (or AlmaLinux).

However it was not installing python3.12-pip, which it probably should have been. And, the primary cause of your issue is most likely that I wasn't removing the python3-devel package name, so it somehow ends up also installing python36-devel. Now I'm having the quirks handler strip out those version-generic packages, so maybe that will help.

I still don't know why this isn't a problem with AlmaLinux 8. It doesn't install python36-devel for some reason.

I've tested it in AlmaLinux 8.10 just to make sure the install still works with the changes. Seems fine. I know you don't have much time to mess around with stuff like this, so it's fine if you can't get around to testing it. I'll just assume that it at least won't make anything worse.

The only way to test whether the new changes will keep the problem from happening on your system is for you to test it yourself. And you'd have to do it in this sequence for it to mean anything:

1. Test the installer you downloaded previously, starting from the prep-only step that installs packages, to see if the problem with the conflicting package recurs.
2. If the problem recurs, grab the new dev_beta zip.
3. Remove the conflicting package like you did before. (Important!)
4. Test the new installer from the dev_beta zip, starting from the prep-only step.
5. Cross fingers.

I'll re-open this since technically it isn't confirmed as resolved yet.

If you can't get to it before RHEL 8.11 arrives, or some other system maintenance happens, either keep hold of the previous installer you downloaded or you'd need to grab the zip from the v24.06 release to have equivalent code. I may end up merging this into main before long, so the main branch would change its behavior.

[RedBearAK]

@jeff9finger-usda

I managed to find a couple of things in the core property matching function that I could change to reduce CPU usage while typing. One of the changes was pretty significant. It's in the dev_beta branch for now. After a bit more testing I'll probably merge into main.

You may want to check it out since you're having to work in a virtual machine, with possibly limited resources compared to running on the host.

Before this change it was possible to easily max out a thread (or a core on a CPU with no threads) by just rapidly typing. Now the keymapper will use no more than about 2-3% of my CPU in normal typing, on a 4c/8t Ryzen 3700u (fairly old by now). The maxed out thread was about 12.5% of the CPU. I can't get anywhere near that now, even while mashing keys much faster than most people will ever be able to type.

With this change there should be less of a problem with a noticeable delay in typing when a system is really busy. Some users noticed that, including me at times. It may still happen with a really busy system, but I think it will be far less prevalent.