[BUG] Installer doesn't work for non-privileged users

``` Bare metal or virtual machine: Windows 11, x86_64 (If in VM, which VM software): VMWare Workstation 17.5.1 (Try running 'toshy-env' in a terminal to fill out the following fields...) Linux distro name: rhel Distro version: 8.9 Distro variant: notfound X11/Xorg or Wayland: x11 Desktop environment(s): gnome DE version(s): 3 Keyboard type (IBM, Chromebook, Windows, Apple): Logitech MX Keys (Apple) Keyboard device name (try 'toshy-devices'): ``` * * * Problem observed: When executing setup_toshy.py as a normal/standard user (not an admin user), I get the following error: ``` $ ./setup_toshy.py install (!!) NOTICE: It is ESSENTIAL to have your system completely updated. Have you updated your system recently? [y/N]: y Â§ Getting environment information... ================================================================================ The active init system is: 'systemd' (Systemd) (EV) Toshy installer sees this environment: DISTRO_ID = 'rhel' DISTRO_VER = '8.9' VARIANT_ID = 'notfound' SESSION_TYPE = 'x11' DESKTOP_ENV = 'gnome' DE_MAJ_VER = '3' Sorry, user vmuser1 is not allowed to execute '/bin/bash -c echo -e " Using elevated privileges..."' as root on vmdi-f82c-jeff-haynes. Traceback (most recent call last): File "./setup_toshy.py", line 2956, in handle_cli_arguments() File "./setup_toshy.py", line 2794, in handle_cli_arguments main(cnfg) File "./setup_toshy.py", line 2841, in main elevate_privileges() File "./setup_toshy.py", line 418, in elevate_privileges subprocess.run(['sudo', 'bash', '-c', 'echo -e "\nUsing elevated privileges..."'], check=True) File "/usr/lib64/python3.6/subprocess.py", line 438, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['sudo', 'bash', '-c', 'echo -e "\nUsing elevated privileges..."']' returned non-zero exit status 1. ``` However, when I execute as an admin user (a non-root user set as an "administrator", the command succeeds.

I never really considered making the script work for a user with no access to sudo, since the typical Linux desktop user will be their own admin. I suppose it’s possible. After the install everything runs as user (as long as the udev rules work to allow the user to access the necessary event devices).

Generally I wanted to avoid having the user run the whole script with superuser privileges, so it just uses sudo where necessary, to run sub-commands. I’ll have to think about how to get the job done with su or something, but I’m not sure it would work the same way.

Is it working OK otherwise? I’m a bit worried about the VMWare environment. Never tested it myself but I’ve seen reports from users trying similar software over the years who had inexplicable issues with some modifiers.

I am thinking it would be possible to use a flag to bypass all the installer functions that require sudo if there is a sudo error and the user chooses to continue anyway. This would necessitate first running the installer while su-ing into an admin user, then rebooting and trying it in the non-privileged user account.

This would of course cause the Toshy config files and "user" services to be installed for that admin user (until I can implement a flag that would just do the "prep" stuff in the admin account). Those services could be easily removed before rebooting with a single command. Adding a new flag like install --prep-only or something like that will take a while. But the command toshy-systemd-remove will already completely remove the user services.

The tray icon would also be auto-loaded if you logged into a desktop as that admin user, unless you clean out the files Toshy puts in ~/.config/autostart/. That and the ~/.config/toshy/ folder would be the only remnant of the install process in the admin account.

It should be relatively simple to tweak the function where that error appeared to catch the error and let the user proceed with installing in a non-privileged environment. As long as non-privileged users can still have "user" systemd services running. If they can't, there's still the option to run the config manually with toshy-config-start (or with the "Script" option in the tray icon menu).

I'll see what I can do, and try to test it with a non-admin account in a VM.

@jeff9finger-usda

I've got a version of Toshy in the dev_beta branch now that is doing what I envisioned and described earlier. In a VM where a privileged user had already installed Toshy, I was able to make a new non-admin user and install Toshy in that account, and after the error when I told it to proceed by entering the code (that makes the user actually read the message in the terminal), the install was successful.

As noted before, there's no compatible GNOME shell extension for the older GNOME version in RHEL 8, so you'll have to stick to the X11 session.

The only thing I can imagine not working right away for you is that the function to put the user into the input group is skipped with this install sequence, and if the uaccess options in the udev rules file don't work on RHEL 8 like they seem to on more modern distros, an admin user will need to do:

sudo usermod -aG input nonadminusername

And then the unprivileged user would need to log out and log back in to get that group membership activated in the login session. That should be the end of the story, if that is even necessary.

I'll try to set up a new AlmaLinux 8.x VM and see what happens. That version of AlmaLinux was still a "clone" so the results should be identical to actual RHEL 8.

Meanwhile I can test in a CentOS Stream 8 VM, but that's not quite the same as RHEL 8. This initial test was on Fedora 40 Workstation (GNOME).

Darn, there's a Python interpreter version issue that is usually handled when you run the install as an admin user. It sets the Python interpreter for building the virtual environment folder to a much newer versions on systems like RHEL 8 and CentOS Stream 8 and earlier.

I'll need to do something to decouple that Python version redirect from the whole package install process. Or find some other solution to get through the installer.

Phew. Finally got it to work again on CentOS Stream 8, for an unprivileged user.

As noted in the distro support list, on CentOS Stream 8 you can install the "AppIndicator and KStatusNotifierItem" extension from the GNOME Software app, to support the tray icon. Should be the same situation for RHEL 8.

I did find that I needed to use an admin user or root to add the unprivileged user to the input group, and then logging out was not sufficient to get that user to appear to be in that group. I had to restart the VM entirely, then Toshy started working. The uaccess trick in the udev rules file did not appear to have any effect here.

Haven't had a chance yet to test in AlmaLinux 8, but I expect it to work, as I worked on the RHEL Python quirks handler at the same time.

Another quirk that a few distros like this have is that the user needs to be in the systemd-journal group if you want to see the services output. You'll see a message to that effect when using the terminal command toshy-services-log, and the tray icon menu item will appear to not work at all.

This time, after fixing the user group with the admin user, logging out was sufficient to get that user in the group, and the services log output was available.

The time when I had to restart to get the group to update might have been related to using "Switch user" at the time, and having the original admin user still logged in. Not sure.

You will see error blocks like this in the log if you accidentally log back into a GNOME Wayland session (I did this after the restart because it defaulted back to Wayland):

May 04 01:26:24 localhost.localdomain bash[3085]: (EE) D-Bus error querying GNOME Shell extension 'xremap@k0kubun.com':
May 04 01:26:24 localhost.localdomain bash[3085]:         org.freedesktop.DBus.Error.UnknownMethod: No such interface 'com.k0kubun.Xremap' on object at path /com/k0kubun/Xremap
May 04 01:26:24 localhost.localdomain bash[3085]: (EE) D-Bus error querying GNOME Shell extension 'window-calls-extended@hseliger.eu':
May 04 01:26:24 localhost.localdomain bash[3085]:         org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.gnome.Shell.Extensions.WindowsExt' on object at path /org/gnome/Shell/Extensions/WindowsExt
May 04 01:26:24 localhost.localdomain bash[3085]: (EE) D-Bus error querying GNOME Shell extension 'focused-window-dbus@flexagoon.com':
May 04 01:26:24 localhost.localdomain bash[3085]:         org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.gnome.shell.extensions.FocusedWindow' on object at path /org/gnome/shell/extensions/FocusedWindow
May 04 01:26:24 localhost.localdomain bash[3085]: (EE) ############################################################################
May 04 01:26:24 localhost.localdomain bash[3085]: (EE) SHELL_EXT: No compatible GNOME Shell extension responding via D-Bus.
May 04 01:26:24 localhost.localdomain bash[3085]:         (Ignore this error if screen was locked/inactive at the time.)
May 04 01:26:24 localhost.localdomain bash[3085]:         These shell extensions are compatible with keyszer:
May 04 01:26:24 localhost.localdomain bash[3085]:             xremap@k0kubun.com (supports pre-GNOME 41.x):
May 04 01:26:24 localhost.localdomain bash[3085]:                 (https://extensions.gnome.org/extension/5060/xremap/)
May 04 01:26:24 localhost.localdomain bash[3085]:             window-calls-extended@hseliger.eu:
May 04 01:26:24 localhost.localdomain bash[3085]:                 (https://extensions.gnome.org/extension/4974/window-calls-extended/)
May 04 01:26:24 localhost.localdomain bash[3085]:             focused-window-dbus@flexagoon.com:
May 04 01:26:24 localhost.localdomain bash[3085]:                 (https://extensions.gnome.org/extension/5592/focused-window-d-bus/)
May 04 01:26:24 localhost.localdomain bash[3085]: (EE) Install "Extension Manager" from Flathub to manage GNOME Shell extensions
May 04 01:26:24 localhost.localdomain bash[3085]: (EE) ############################################################################

And the toshy-env command will also easily reveal whether you are logged into an X11 or Wayland session type, in case Toshy is not working.

Well, as always there are unexpected differences between "RHEL" (AlmaLinux 8.9) and CentOS Stream 8. The uaccess tags actually seem to work. As long as you can do the install first from an admin user's desktop session, it should work right away for the unprivileged user account after that user does their own Toshy install. Without even putting that user in the input group and rebooting.

The admin user has to install from a full graphical login session at the moment, because some steps in the install are specific to the desktop environment detected. I might be able to use that idea of a new "--prep-only" flag to bypass the things that care about the user's environment, since none of that should be relevant to actually doing the prep work if we're NOT installing all of Toshy for the user doing the "prep" on behalf of the unprivileged user.

In theory it might even be possible to do the prep part via su --login adminuser and then just exit out of the su shell and proceed with the unprivileged user install. But I'll have to take a close look at the steps involved in the "prep" parts.

Got it working.

Say testuser us your admin user, with access to sudo, and nonadminuser is the unprivileged user.

Right now I'll use dev_beta for the zip URL for the admin user to download. This is if you want to do it without needing to log into a graphical session as testuser.

First download and unzip the Toshy dev_beta zip in the Downloads folder of nonadminuser, and cd into the folder.

Then:

su --login testuser
wget https://github.com/RedBearAK/toshy/archive/refs/heads/dev_beta.zip
unzip dev_beta.zip
rm dev_beta.zip
cd toshy-dev_beta
./setup_toshy.py prep-only
# prep-only finishes, exit from the `su --login testuser` shell
# run the install from within the `nonadminuser` account
./setup_toshy.py install
# error will happen, asks for code, continues with "unprivileged" install
# the end, Toshy works right away if you're in an X11 session

When I'm confident enough to merge these changes into main, all the references here to dev_beta would need to change to main.

Still need to do the manual step of installing the AppIndicator & KStatusNotifierItem extension from the Software app (which doesn't require a password), if you want to see the tray icon in the top bar. It's very useful.

Wow! Thanks for this.

I executed the steps above. All succeeded except the last one...

I'm still getting an error in the last step: ./setup_toshy.py install as the 'nonadminuser'

$ ./setup_toshy.py install

(!!) NOTICE: It is ESSENTIAL to have your system completely updated.

Have you updated your system recently? [y/N]: y

§  Getting environment information...
================================================================================
The active init system is: 'systemd' (Systemd)

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

Is user "vmuser1" an admin user that can run "sudo" commands? [y/N]: N

The secret code for this run is "iXtm". You will need this.

It is possible to install as an unprivileged user, but only after an
admin user first runs the full install or a "prep-only" sequence.
The admin user must install from a full desktop session, or from
a "su --login adminuser" shell instance. The admin user can do
just the "prep" steps with "./setup_toshy.py prep-only" instead of
using "./setup_toshy.py install", if it is not desired that Toshy
should also run when the admin user logs into a desktop session.
When using "su --login adminuser", that user will also need to
download an independent copy of the Toshy zip file to install from,
using a "wget" or "curl" command. Or use "sudo" to copy the zip
file from the unprivileged user's Downloads folder. See the Wiki.

If you understand everything written above or already took care of prepping the
system and want to proceed with an unprivileged install, enter the secret code: iXtm
Continuing with an unprivileged install of Toshy's user components.

§  Cloning keymapper branch...
================================================================================
Cloning branch "main" from https://github.com/RedBearAK/xwaykeyz.git...
Cloning into '/home/vmuser1/toshy/toshy-dev_beta/keymapper-temp'...
remote: Enumerating objects: 2807, done.
remote: Counting objects: 100% (2807/2807), done.
remote: Compressing objects: 100% (707/707), done.
remote: Total 2807 (delta 1823), reused 2794 (delta 1811), pack-reused 0
Receiving objects: 100% (2807/2807), 579.49 KiB | 672.00 KiB/s, done.
Resolving deltas: 100% (1823/1823), done.
   >> Task completed successfully <<   

§  Backing up existing Toshy config folder...
================================================================================
Prepared existing config file data for merging into new config.
No existing preferences db file found in /home/vmuser1/.config/toshy.
Backup completed to '/home/vmuser1/.config/toshy_config_backups/toshy_20240506_150348'
   >> Task completed successfully <<   

§  Installing Toshy files...
================================================================================
Installed default Toshy config file.
Toshy files installed in '/home/vmuser1/.config/toshy'.
Existing user customizations applied to the new config file.
   >> Task completed successfully <<   

§  Setting up the Python virtual environment...
================================================================================
Using Python version 3.11.
Python virtual environment setup complete.
Location: '/home/vmuser1/.config/toshy/.venv'
   >> Task completed successfully <<   

§  Installing/upgrading Python packages...
================================================================================
Requirement already satisfied: pip in /home/vmuser1/.config/toshy/.venv/lib64/python3.11/site-packages (22.3.1)
Collecting pip
  Using cached pip-24.0-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 22.3.1
    Uninstalling pip-22.3.1:
      Successfully uninstalled pip-22.3.1
Successfully installed pip-24.0
Collecting wheel
  Using cached wheel-0.43.0-py3-none-any.whl.metadata (2.2 kB)
Using cached wheel-0.43.0-py3-none-any.whl (65 kB)
Installing collected packages: wheel
Successfully installed wheel-0.43.0
Requirement already satisfied: setuptools in /home/vmuser1/.config/toshy/.venv/lib64/python3.11/site-packages (65.5.1)
Collecting setuptools
  Using cached setuptools-69.5.1-py3-none-any.whl.metadata (6.2 kB)
Using cached setuptools-69.5.1-py3-none-any.whl (894 kB)
Installing collected packages: setuptools
  Attempting uninstall: setuptools
    Found existing installation: setuptools 65.5.1
    Uninstalling setuptools-65.5.1:
      Successfully uninstalled setuptools-65.5.1
Successfully installed setuptools-69.5.1
Collecting pillow
  Using cached pillow-10.3.0-cp311-cp311-manylinux_2_28_x86_64.whl.metadata (9.2 kB)
Using cached pillow-10.3.0-cp311-cp311-manylinux_2_28_x86_64.whl (4.5 MB)
Installing collected packages: pillow
Successfully installed pillow-10.3.0
Collecting lockfile
  Using cached lockfile-0.12.2-py2.py3-none-any.whl.metadata (2.4 kB)
Collecting dbus-python
  Using cached dbus-python-1.3.2.tar.gz (605 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [106 lines of output]
      + meson setup /tmp/pip-install-kqm92cm7/dbus-python_dbfffcb0bebf4a68a7ea344c5ba95cad /tmp/pip-install-kqm92cm7/dbus-python_dbfffcb0bebf4a68a7ea344c5ba95cad/.mesonpy-vakwiic_ -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --native-file=/tmp/pip-install-kqm92cm7/dbus-python_dbfffcb0bebf4a68a7ea344c5ba95cad/.mesonpy-vakwiic_/meson-python-native-file.ini
      The Meson build system
      Version: 1.4.0
      Source dir: /tmp/pip-install-kqm92cm7/dbus-python_dbfffcb0bebf4a68a7ea344c5ba95cad
      Build dir: /tmp/pip-install-kqm92cm7/dbus-python_dbfffcb0bebf4a68a7ea344c5ba95cad/.mesonpy-vakwiic_
      Build type: native build
      Project name: dbus-python
      Project version: 1.3.2
      C compiler for the host machine: cc (gcc 8.5.0 "cc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20)")
      C linker for the host machine: cc ld.bfd 2.30-123
      Host machine cpu family: x86_64
      Host machine cpu: x86_64
      Compiler for C supports arguments -fno-common: YES
      Compiler for C supports arguments -Wno-missing-field-initializers: YES
      Compiler for C supports arguments -Wno-declaration-after-statement: YES
      Compiler for C supports arguments -Wno-inline: YES
      Compiler for C supports arguments -Wno-redundant-decls: YES
      Compiler for C supports arguments -Wno-switch-default: YES
      Compiler for C supports arguments -Wno-write-strings: YES
      Compiler for C supports arguments -Wcast-align: YES
      Compiler for C supports arguments -Wdouble-promotion: YES
      Compiler for C supports arguments -Wduplicated-cond: YES
      Compiler for C supports arguments -Wfloat-equal: YES
      Compiler for C supports arguments -Wformat-nonliteral: YES
      Compiler for C supports arguments -Wformat-security: YES
      Compiler for C supports arguments -Wformat=2: YES
      Compiler for C supports arguments -Winit-self: YES
      Compiler for C supports arguments -Wlogical-op: YES
      Compiler for C supports arguments -Wmissing-declarations: YES
      Compiler for C supports arguments -Wmissing-format-attribute: YES
      Compiler for C supports arguments -Wmissing-include-dirs: YES
      Compiler for C supports arguments -Wmissing-noreturn: YES
      Compiler for C supports arguments -Wnull-dereference: YES
      Compiler for C supports arguments -Wpacked: YES
      Compiler for C supports arguments -Wpointer-arith: YES
      Compiler for C supports arguments -Wshadow: YES
      Compiler for C supports arguments -Wswitch-enum: YES
      Compiler for C supports arguments -Wundef: YES
      Compiler for C supports arguments -Wunused-but-set-variable: YES
      Compiler for C supports arguments -Wjump-misses-init: YES
      Compiler for C supports arguments -Wmissing-prototypes: YES
      Compiler for C supports arguments -Wnested-externs: YES
      Compiler for C supports arguments -Wold-style-definition: YES
      Compiler for C supports arguments -Wpointer-sign: YES
      Compiler for C supports arguments -Wstrict-prototypes: YES
      Configuring _dbus-python-config.h using configuration

      Executing subproject dbus-gmain

      dbus-gmain| Project name: dbus-gmain
      dbus-gmain| Project version: undefined
      dbus-gmain| C compiler for the host machine: cc (gcc 8.5.0 "cc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20)")
      dbus-gmain| C linker for the host machine: cc ld.bfd 2.30-123
      dbus-gmain| Compiler for C supports arguments -fno-common: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wno-missing-field-initializers: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wcast-align: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wdouble-promotion: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wduplicated-branches: YES
      dbus-gmain| Compiler for C supports arguments -Wduplicated-cond: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wfloat-equal: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat-nonliteral: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat-security: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat=2: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Winit-self: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wlogical-op: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-declarations: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-format-attribute: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-include-dirs: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-noreturn: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wnull-dereference: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpacked: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpointer-arith: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wredundant-decls: YES
      dbus-gmain| Compiler for C supports arguments -Wshadow: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wswitch-default: YES
      dbus-gmain| Compiler for C supports arguments -Wswitch-enum: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wundef: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wunused-but-set-variable: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wwrite-strings: YES
      dbus-gmain| Compiler for C supports arguments -Wdeclaration-after-statement: YES
      dbus-gmain| Compiler for C supports arguments -Wjump-misses-init: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-prototypes: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wnested-externs: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wold-style-definition: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpointer-sign: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wstrict-prototypes: YES (cached)
      dbus-gmain| Found pkg-config: YES (/bin/pkg-config) 1.4.2
      dbus-gmain| Run-time dependency dbus-1 found: YES 1.12.8
      dbus-gmain| Run-time dependency glib-2.0 found: YES 2.56.4
      dbus-gmain| Run-time dependency gthread-2.0 found: YES 2.56.4
      dbus-gmain| Program dbus-run-session found: YES (/bin/dbus-run-session)
      dbus-gmain| Build targets in project: 1
      dbus-gmain| Subproject dbus-gmain finished.

      Program python found: YES (/home/vmuser1/.config/toshy/.venv/bin/python)
      Dependency dbus-1 found: YES 1.12.8 (cached)
      Run-time dependency python found: YES 3.11
      Configuring TestSuitePythonService.service using configuration
      Configuring tmp-session-bus.conf using configuration
      Program dbus-run-session found: YES (/bin/dbus-run-session)
      ../test/meson.build:75: DEPRECATION: Project uses feature that was always broken, and is now deprecated since '1.3.0': str.format: Value other than strings, integers, bools, options, dictionaries and lists thereof..
      Run-time dependency python found: NO (tried pkgconfig, pkgconfig and sysconfig)

      ../test/meson.build:98:15: ERROR: Python dependency not found

      A full log can be found at /tmp/pip-install-kqm92cm7/dbus-python_dbfffcb0bebf4a68a7ea344c5ba95cad/.mesonpy-vakwiic_/meson-logs/meson-log.txt
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
Error installing/upgrading Python packages. Installer exiting.

But, I guess the issue is that I am in a gnome session?

$  scripts/bin/toshy-env.sh 

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

One other item to note: My nonadminuser is able to perform sudo for some things, but not for all. I'm not sure it matters for what you need to do, but just wanted to provide that detail.

Hmm. Unlikely to have anything to do with GNOME, but there must be some dependency missing for the build of dbus-python. Something that for some reason was not missing on CentOS Stream 8 or Alma Linux 8.9 (all RHEL-type distros draw on the same package list in the setup script). Sometimes there has been something missing from the dependencies that would only show up in a different architecture or something like a container environment.

That dbus-python has been the bane of my existence, and the build errors are usually almost useless. But I think there's a critical line here:

      Run-time dependency python found: NO (tried pkgconfig, pkgconfig and sysconfig)

So I would use the admin user that can run DNF with sudo to see what happens when you do:

sudo dnf install pkgconfig

If that comes back and says something like pkgconf-pkg-config is already installed, move on to:

sudo dnf install python3-pkgconfig

That was not installed in my AlmaLinux VM, but then again I was not having this build error in AlmaLinux, so it doesn't make much sense for that to be the missing dependency.

One other item to note: My nonadminuser is able to perform sudo for some things, but not for all. I'm not sure it matters for what you need to do, but just wanted to provide that detail.

You probably only have limited specific commands you can run with sudo. There are several different commands that need to be run with sudo in the setup script. It most likely would not be practical to try to figure out what your limited user can and can't do versus what the setup script needs to do. But by all means if you can check the individual packages above with the limited user, there's no need to su into the admin user.

There's a possibility that one of the packages didn't install, but you didn't include the log output from the prep-only run, so I assume there was no obvious error there.

On second thought I might be misinterpreting the error line, as usual. Make sure this package actually installed:

sudo dnf install python3-devel

Just guessing but that should be the one that enables meson to find "python" as a dependency. But it would be odd for it to not be installed, since it's in the package list that prep-only handles, so if prep-only showed no errors...

sudo dnf install pkgconfig showed pkgconfig already installed. So, I executed sudo dnf install python3-pkgconfig and this one was not installed and it installed. sudo dnf install python3-devel was already installed.

I tried to execute meson and it was not found. So I installed it manually - sudo dnf install meson

I tried executing the installer again and it still failed. I will have to get more details to you tomorrow

Thanks for the suggestions!

I think it's fairly unlikely that this will have an affect, but it shouldn't hurt anything. You can try finding this in the setup_toshy.py script:

    commands        = [
        [venv_python_cmd, '-m', 'pip', 'install', '--upgrade', 'pip'],
        [venv_pip_cmd, 'install', '--upgrade', 'wheel'],
        [venv_pip_cmd, 'install', '--upgrade', 'setuptools'],
        [venv_pip_cmd, 'install', '--upgrade', 'pillow'],
        [venv_pip_cmd, 'install', '--upgrade'] + filtered_pip_pkgs
    ]

And make it look like this:

    commands        = [
        [venv_python_cmd, '-m', 'pip', 'install', '--upgrade', 'pip'],
        [venv_pip_cmd, 'install', '--upgrade', 'wheel'],
        [venv_pip_cmd, 'install', '--upgrade', 'setuptools'],
        [venv_pip_cmd, 'install', '--upgrade', 'pillow'],
        [venv_pip_cmd, 'install', '--upgrade', 'pkgconfig'],
        [venv_pip_cmd, 'install', '--upgrade'] + filtered_pip_pkgs
    ]

I actually have no idea if this pkgconfig does anything different than the DNF package with a similar name. But it will at least be installed inside the venv with pip, and doing it this particular way will mean it's there before dbus-python gets installed (it's part of filtered_pip_pkgs).

At the moment I don't even know what else to throw at this. I'm downloading a copy of RHEL 8.9 after registering a free developer account, but I don't expect it to be any different from AlmaLinux 8.9. I think there's just something off about your specific setup that will have to be discovered. We'll see.

Thanks for the suggestion. There was no change :-( Is there a way to prevent the log files from being cleaned up? Perhaps I can determine more about what is happening if these files were available after a failed execution.

Not that I know of. I saw others referring to the same issue with the meson log link always being invalid.

More than one Wayland method requires dbus-python inside the keymapper. But if a user is sticking with X11/Xorg sessions it is possible to use the core of Toshy (the keymapping) without that package. So in a sense it's sort of pointless to waste time even figuring out how to get dbus-python installed.

Here's a rough way to go ahead and re-run the installer while bypassing dbus-python. This will leave the tray icon and preferences apps unable to start, but I should be able to put some tweaks in place to fix that. In the meantime, the toshy-* terminal commands can be used to check that the service is running, stop or restart, or start the verbose output option.

I think I can make it a lot more elegant than this, and allow the tray icon and GUI app to work (without the ability to show the services status).

Note that this has to be done after at least one attempted run of the installer, when there will be a new "keymapper-temp" folder where the setup script cloned the keymapper (xwaykeyz) during the last run. Then we can disable the cloning function and cause the setup script to install a version of xwaykeyz that doesn't pull in dbus-python.

File: toshy-dev_beta/keymapper-temp/src/xwaykeyz/lib/window_context.py

Keep import dbus from causing a ModuleNotFoundError, with this try/except:

import os
import abc
try:
    import dbus
except (ModuleNotFoundError, ImportError):
    dbus = None
import json
import time
import i3ipc
import shutil
import socket
import subprocess

...

File: toshy-dev_beta/keymapper-temp/pyproject.toml

Remove the dbus-python dependency, so it looks like this:

...
dependencies = [
    "appdirs ~= 1.4",
    "evdev ~= 1.5",
    "hyprpy ~= 0.1.5",
    "i3ipc ~= 2.2.1",
    "inotify_simple ~= 1.3",
    "ordered_set ~= 4.1",
    "python-xlib == 0.31",
    "pywayland ~= 0.4.17",
]
...

File: toshy-dev_beta/setup_toshy.py

Block the keymapper cloning function by inserting a return right at the beginning:

...
def clone_keymapper_branch():
    """Clone the designated keymapper branch from GitHub"""
    print(f'\n\n######### Not cloning keymapper\n\n')
    return

    print(f'\n\n§  Cloning keymapper branch...\n{cnfg.separator}')
...

Save all these changes and run the install command again. I fully expect this to at least allow finishing the install and getting the keymapper config working.

Once it's done, you can try Cmd+T to open a new tab in the terminal, try to move between tabs with Shift+Cmd+Left_Brace/Right_Brace (or Shift+Cmd+Left/Right, which is even better proof that Toshy sees the terminal as a terminal app), and Cmd+W to close a tab. And one of the best checks is using Cmd+Comma in Firefox, to see if it takes you to the Firefox settings in a new tab. It should open a new tab, type out "about:preferences" and hit Enter for you. Relatively quickly.

My goal is to allow all this to be accomplished by just using a new install option like --no-dbus. We'll see how that goes.

If you grab a new dev_beta zip, it should now tolerate the lack of dbus-python better. The tray icon app and preferences app will run, and they will just not be able to monitor the Toshy services and show the status of those services.

This hacked install can be accomplished with this option:

./setup_toshy.py install --no-dbus-python

You'll end up with a monochrome tray icon. That will be the only obvious difference. It's usually colorful to show the services are running, or subdued colors to show the services are stopped. But in this case the service status is unknown, so the icon will remain gray with a black command key symbol. Like the first of the three icons in the README.

Thanks for all that you have done to help! I tried the above, and it failed with similar errors. I can try to get the details to you, if those are helpful. Just have to do this in "spare" time as I have deliverables to work on.

I would need to see that error output to see if it is feasible to continue trying to get your environment to work.

It would also be helpful to see the output from doing the “prep-only” step with the admin user. The true source of the problem still eludes me.

Finally, I was able to carve out some time for this. Thanks for your patience. I tried uninstalling to existing version and start from scratch. Here are the logs As admin user:

$ ./setup_toshy.py prep-only

(!!) NOTICE: It is ESSENTIAL to have your system completely updated.

Have you updated your system recently? [y/N]: y

§  Getting environment information...
================================================================================
The active init system is: 'systemd' (Systemd)

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

Is user "jhaynes" an admin user that can run "sudo" commands? [y/n]: y

Using elevated privileges...

§  Installing native packages for this distro type...
================================================================================
Doing prep/checks for RHEL-type distro...
Last metadata expiration check: 0:15:00 ago on Fri 17 May 2024 09:05:58 AM CDT.
Dependencies resolved.
================================================================================================================================================
 Package                               Architecture                    Version                             Repository                      Size
================================================================================================================================================
Installing:
 epel-release                          noarch                          8-19.el8                            epel8                           25 k

Transaction Summary
================================================================================================================================================
Install  1 Package

Total download size: 25 k
Installed size: 35 k
Downloading Packages:
epel-release-8-19.el8.noarch.rpm                                                                                 17 kB/s |  25 kB     00:01    
------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                            17 kB/s |  25 kB     00:01     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                        1/1 
  Installing       : epel-release-8-19.el8.noarch                                                                                           1/1 
  Running scriptlet: epel-release-8-19.el8.noarch                                                                                           1/1 
Many EPEL packages require the CodeReady Builder (CRB) repository.
It is recommended that you run /usr/bin/crb enable to enable the CRB repository.

  Verifying        : epel-release-8-19.el8.noarch                                                                                           1/1 
Installed products updated.

Installed:
  epel-release-8-19.el8.noarch                                                                                                                  

Complete!
Repository epel is listed more than once in the configuration
1Password Stable Channel                                                                                        685  B/s | 3.0 kB     00:04    
Extra Packages for Enterprise Linux 8 - x86_64                                                                  566 kB/s |  14 MB     00:24    
packages-microsoft-com-prod                                                                                     356  B/s | 1.5 kB     00:04    
rhel8-supplementary                                                                                             8.2 kB/s | 3.8 kB     00:00    
rhel8-codeready-builder                                                                                         9.6 kB/s | 4.5 kB     00:00    
epel8                                                                                                           9.5 kB/s | 4.4 kB     00:00    
rhel8-appstream                                                                                                 9.8 kB/s | 4.5 kB     00:00    
rhel8-baseos                                                                                                    8.9 kB/s | 4.1 kB     00:00    
code                                                                                                            3.3 kB/s | 1.5 kB     00:00    
vmdi-yum-local                                                                                                  2.9 kB/s | 1.4 kB     00:00    
google-chrome                                                                                                   1.2 kB/s | 1.3 kB     00:01    
vmdi-common-yum                                                                                                 3.0 kB/s | 1.4 kB     00:00    
Azure Command Line Interface                                                                                    3.3 kB/s | 1.5 kB     00:00    
Metadata cache created.
Enabling CRB repo
Repository epel is listed more than once in the configuration
This system has no repositories available through subscriptions.
Repository epel is listed more than once in the configuration
CRB repo is enabled and named: rhel8-codeready-builder
Repository epel is listed more than once in the configuration
Last metadata expiration check: 0:00:04 ago on Fri 17 May 2024 09:21:44 AM CDT.
No match for argument: python3.14
No match for argument: python3.14-devel
No match for argument: python3.14-tkinter
Error: Unable to find a match: python3.14 python3.14-devel python3.14-tkinter
No match for potential Python version 3.14.
Repository epel is listed more than once in the configuration
Last metadata expiration check: 0:00:06 ago on Fri 17 May 2024 09:21:44 AM CDT.
No match for argument: python3.13
No match for argument: python3.13-devel
No match for argument: python3.13-tkinter
Error: Unable to find a match: python3.13 python3.13-devel python3.13-tkinter
No match for potential Python version 3.13.
Repository epel is listed more than once in the configuration
Last metadata expiration check: 0:00:08 ago on Fri 17 May 2024 09:21:44 AM CDT.
No match for argument: python3.12
No match for argument: python3.12-devel
No match for argument: python3.12-tkinter
Error: Unable to find a match: python3.12 python3.12-devel python3.12-tkinter
No match for potential Python version 3.12.
Repository epel is listed more than once in the configuration
Last metadata expiration check: 0:00:11 ago on Fri 17 May 2024 09:21:44 AM CDT.
Package cairo-devel-1.15.12-6.el8.x86_64 is already installed.
Package cairo-gobject-devel-1.15.12-6.el8.x86_64 is already installed.
Package dbus-daemon-1:1.12.8-26.el8.x86_64 is already installed.
Package dbus-devel-1:1.12.8-26.el8.x86_64 is already installed.
Package gcc-8.5.0-20.el8.x86_64 is already installed.
Package git-2.39.3-1.el8_8.x86_64 is already installed.
Package gobject-introspection-devel-1.56.1-1.el8.x86_64 is already installed.
Package libappindicator-gtk3-12.10.0-19.el8.x86_64 is already installed.
Package libnotify-0.7.7-6.el8.x86_64 is already installed.
Package python3-dbus-1.2.4-15.el8.x86_64 is already installed.
Package python36-devel-3.6.8-38.module+el8.9.0+20976+d3c38525.x86_64 is already installed.
Package python3-pip-9.0.3-23.el8_9.1.noarch is already installed.
Package python3-tkinter-3.6.8-56.el8_9.3.x86_64 is already installed.
Package systemd-devel-239-78.el8.x86_64 is already installed.
Package xorg-x11-server-utils-7.7-27.el8.x86_64 is already installed.
Package zenity-3.28.1-2.el8.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
All necessary native distro packages are installed.
   >> Task completed successfully <<   

§  Checking status of "uinput" kernel module...
================================================================================
The "uinput" module is already loaded.
   >> Task completed successfully <<   

§  Installing "udev" rules file for keymapper...
================================================================================
Correct "udev" rules already in place.
   >> Task completed successfully <<   

########################################################################
FINISHED with prep-only tasks. Unprivileged users can now install Toshy.

And then as the standard (non-admin) user. - this user does have some sudo access, but probably not enough.

$ ./setup_toshy.py install --no-dbus-python

(!!) NOTICE: It is ESSENTIAL to have your system completely updated.

Have you updated your system recently? [y/N]: y

§  Getting environment information...
================================================================================
The active init system is: 'systemd' (Systemd)

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

Is user "vmuser1" an admin user that can run "sudo" commands? [y/n]: n

ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!

The secret code for this run is "BFrg". You will need this.

It is possible to install as an unprivileged user, but only after an admin user
first runs the full install or a "prep-only" sequence. The admin user must
install from a full desktop session, or from a "su --login adminuser" shell
instance. The admin user can do just the "prep" steps with:

./setup_toshy.py prep-only

... instead of using:

./setup_toshy.py install

Use the "prep-only" command if it is not desired that Toshy should also run when
the admin user logs into a desktop session. When using "su --login adminuser",
that user will also need to download an independent copy of the Toshy zip file
to install from, using a "wget" or "curl" command. Or use "sudo" to copy the zip
file from the unprivileged user's Downloads folder. See the Wiki for a better
example of the full "prep-only" sequence with a separate admin user.

If you understand everything written above or already
took care of prepping the system and want to proceed
with an unprivileged install, enter the secret code: BFrg

Good code. Continuing with an unprivileged install of Toshy user components...

§  Cloning keymapper branch...
================================================================================
Cloning branch "main" from https://github.com/RedBearAK/xwaykeyz.git...
Cloning into '/home/vmuser1/toshy/toshy-dev_beta/keymapper-temp'...
remote: Enumerating objects: 2830, done.
remote: Counting objects: 100% (2830/2830), done.
remote: Compressing objects: 100% (719/719), done.
remote: Total 2830 (delta 1836), reused 2810 (delta 1818), pack-reused 0
Receiving objects: 100% (2830/2830), 585.71 KiB | 590.00 KiB/s, done.
Resolving deltas: 100% (1836/1836), done.
   >> Task completed successfully <<   

§  Backing up existing Toshy config folder...
================================================================================
Prepared existing config file data for merging into new config.
No existing preferences db file found in /home/vmuser1/.config/toshy.
Backup completed to '/home/vmuser1/.config/toshy_config_backups/toshy_20240517_111911'
   >> Task completed successfully <<   

§  Installing Toshy files...
================================================================================
Installed default Toshy config file.
Toshy files installed in '/home/vmuser1/.config/toshy'.
Existing user customizations applied to the new config file.
   >> Task completed successfully <<   

§  Setting up the Python virtual environment...
================================================================================
Using Python version 3.11.
Python virtual environment setup complete.
Location: '/home/vmuser1/.config/toshy/.venv'
   >> Task completed successfully <<   

§  Installing/upgrading Python packages...
================================================================================
Requirement already satisfied: pip in /home/vmuser1/.config/toshy/.venv/lib64/python3.11/site-packages (22.3.1)
Collecting pip
  Using cached pip-24.0-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 22.3.1
    Uninstalling pip-22.3.1:
      Successfully uninstalled pip-22.3.1
Successfully installed pip-24.0
Collecting wheel
  Using cached wheel-0.43.0-py3-none-any.whl.metadata (2.2 kB)
Using cached wheel-0.43.0-py3-none-any.whl (65 kB)
Installing collected packages: wheel
Successfully installed wheel-0.43.0
Requirement already satisfied: setuptools in /home/vmuser1/.config/toshy/.venv/lib64/python3.11/site-packages (65.5.1)
Collecting setuptools
  Using cached setuptools-69.5.1-py3-none-any.whl.metadata (6.2 kB)
Using cached setuptools-69.5.1-py3-none-any.whl (894 kB)
Installing collected packages: setuptools
  Attempting uninstall: setuptools
    Found existing installation: setuptools 65.5.1
    Uninstalling setuptools-65.5.1:
      Successfully uninstalled setuptools-65.5.1
Successfully installed setuptools-69.5.1
Collecting pillow
  Using cached pillow-10.3.0-cp311-cp311-manylinux_2_28_x86_64.whl.metadata (9.2 kB)
Using cached pillow-10.3.0-cp311-cp311-manylinux_2_28_x86_64.whl (4.5 MB)
Installing collected packages: pillow
Successfully installed pillow-10.3.0
Collecting lockfile
  Using cached lockfile-0.12.2-py2.py3-none-any.whl.metadata (2.4 kB)
Collecting systemd-python
  Using cached systemd-python-235.tar.gz (61 kB)
  Preparing metadata (setup.py) ... done
Collecting pygobject<=3.44.1
  Using cached PyGObject-3.44.1.tar.gz (720 kB)
  Installing build dependencies ... error
  error: subprocess-exited-with-error

  × pip subprocess to install build dependencies did not run successfully.
  │ exit code: 1
  ╰─> [51 lines of output]
      Collecting setuptools
        Using cached setuptools-69.5.1-py3-none-any.whl.metadata (6.2 kB)
      Collecting wheel
        Using cached wheel-0.43.0-py3-none-any.whl.metadata (2.2 kB)
      Collecting pycairo
        Using cached pycairo-1.26.0.tar.gz (346 kB)
        Installing build dependencies: started
        Installing build dependencies: finished with status 'done'
        Getting requirements to build wheel: started
        Getting requirements to build wheel: finished with status 'done'
        Installing backend dependencies: started
        Installing backend dependencies: finished with status 'done'
        Preparing metadata (pyproject.toml): started
        Preparing metadata (pyproject.toml): finished with status 'done'
      Using cached setuptools-69.5.1-py3-none-any.whl (894 kB)
      Using cached wheel-0.43.0-py3-none-any.whl (65 kB)
      Building wheels for collected packages: pycairo
        Building wheel for pycairo (pyproject.toml): started
        Building wheel for pycairo (pyproject.toml): finished with status 'error'
        error: subprocess-exited-with-error

        × Building wheel for pycairo (pyproject.toml) did not run successfully.
        │ exit code: 1
        ╰─> [21 lines of output]
            running bdist_wheel
            running build
            running build_py
            creating build
            creating build/lib.linux-x86_64-cpython-311
            creating build/lib.linux-x86_64-cpython-311/cairo
            copying cairo/__init__.py -> build/lib.linux-x86_64-cpython-311/cairo
            copying cairo/__init__.pyi -> build/lib.linux-x86_64-cpython-311/cairo
            copying cairo/py.typed -> build/lib.linux-x86_64-cpython-311/cairo
            warning: build_py: byte-compiling is disabled, skipping.

            running build_ext
            building 'cairo._cairo' extension
            creating build/temp.linux-x86_64-cpython-311
            creating build/temp.linux-x86_64-cpython-311/cairo
            gcc -pthread -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DPYCAIRO_VERSION_MAJOR=1 -DPYCAIRO_VERSION_MINOR=26 -DPYCAIRO_VERSION_MICRO=0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid -I/home/vmuser1/.config/toshy/.venv/include -I/usr/include/python3.11 -c cairo/bufferproxy.c -o build/temp.linux-x86_64-cpython-311/cairo/bufferproxy.o -Wall -Warray-bounds -Wcast-align -Wconversion -Wextra -Wformat=2 -Wformat-nonliteral -Wformat-security -Wimplicit-function-declaration -Winit-self -Winline -Wmissing-format-attribute -Wmissing-noreturn -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wreturn-type -Wshadow -Wsign-compare -Wstrict-aliasing -Wundef -Wunused-but-set-variable -Wswitch-default -Wno-missing-field-initializers -Wno-unused-parameter -Wno-unused-command-line-argument -fno-strict-aliasing -fvisibility=hidden -std=c99
            cairo/bufferproxy.c:32:10: fatal error: Python.h: No such file or directory
             #include <Python.h>
                      ^~~~~~~~~~
            compilation terminated.
            error: command '/bin/gcc' failed with exit code 1
            [end of output]

        note: This error originates from a subprocess, and is likely not a problem with pip.
        ERROR: Failed building wheel for pycairo
      Failed to build pycairo
      ERROR: Could not build wheels for pycairo, which is required to install pyproject.toml-based projects
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× pip subprocess to install build dependencies did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.
Error installing/upgrading Python packages. Installer exiting.

And while I'm at it, here is the output from the install as a non-admin user.

$ ./setup_toshy.py install 

(!!) NOTICE: It is ESSENTIAL to have your system completely updated.

Have you updated your system recently? [y/N]: y

§  Getting environment information...
================================================================================
The active init system is: 'systemd' (Systemd)

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

Is user "vmuser1" an admin user that can run "sudo" commands? [y/n]: n

ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!  ALERT!

The secret code for this run is "VryI". You will need this.

It is possible to install as an unprivileged user, but only after an admin user
first runs the full install or a "prep-only" sequence. The admin user must
install from a full desktop session, or from a "su --login adminuser" shell
instance. The admin user can do just the "prep" steps with:

./setup_toshy.py prep-only

... instead of using:

./setup_toshy.py install

Use the "prep-only" command if it is not desired that Toshy should also run when
the admin user logs into a desktop session. When using "su --login adminuser",
that user will also need to download an independent copy of the Toshy zip file
to install from, using a "wget" or "curl" command. Or use "sudo" to copy the zip
file from the unprivileged user's Downloads folder. See the Wiki for a better
example of the full "prep-only" sequence with a separate admin user.

If you understand everything written above or already
took care of prepping the system and want to proceed
with an unprivileged install, enter the secret code: VryI

Good code. Continuing with an unprivileged install of Toshy user components...

§  Cloning keymapper branch...
================================================================================
Cloning branch "main" from https://github.com/RedBearAK/xwaykeyz.git...
Cloning into '/home/vmuser1/toshy/toshy-dev_beta/keymapper-temp'...
remote: Enumerating objects: 2830, done.
remote: Counting objects: 100% (2830/2830), done.
remote: Compressing objects: 100% (719/719), done.
remote: Total 2830 (delta 1836), reused 2810 (delta 1818), pack-reused 0
Receiving objects: 100% (2830/2830), 585.71 KiB | 533.00 KiB/s, done.
Resolving deltas: 100% (1836/1836), done.
   >> Task completed successfully <<   

§  Backing up existing Toshy config folder...
================================================================================
Prepared existing config file data for merging into new config.
No existing preferences db file found in /home/vmuser1/.config/toshy.
Backup completed to '/home/vmuser1/.config/toshy_config_backups/toshy_20240517_112723'
   >> Task completed successfully <<   

§  Installing Toshy files...
================================================================================
Installed default Toshy config file.
Toshy files installed in '/home/vmuser1/.config/toshy'.
Existing user customizations applied to the new config file.
   >> Task completed successfully <<   

§  Setting up the Python virtual environment...
================================================================================
Using Python version 3.11.
Python virtual environment setup complete.
Location: '/home/vmuser1/.config/toshy/.venv'
   >> Task completed successfully <<   

§  Installing/upgrading Python packages...
================================================================================
Requirement already satisfied: pip in /home/vmuser1/.config/toshy/.venv/lib64/python3.11/site-packages (22.3.1)
Collecting pip
  Using cached pip-24.0-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 22.3.1
    Uninstalling pip-22.3.1:
      Successfully uninstalled pip-22.3.1
Successfully installed pip-24.0
Collecting wheel
  Using cached wheel-0.43.0-py3-none-any.whl.metadata (2.2 kB)
Using cached wheel-0.43.0-py3-none-any.whl (65 kB)
Installing collected packages: wheel
Successfully installed wheel-0.43.0
Requirement already satisfied: setuptools in /home/vmuser1/.config/toshy/.venv/lib64/python3.11/site-packages (65.5.1)
Collecting setuptools
  Using cached setuptools-69.5.1-py3-none-any.whl.metadata (6.2 kB)
Using cached setuptools-69.5.1-py3-none-any.whl (894 kB)
Installing collected packages: setuptools
  Attempting uninstall: setuptools
    Found existing installation: setuptools 65.5.1
    Uninstalling setuptools-65.5.1:
      Successfully uninstalled setuptools-65.5.1
Successfully installed setuptools-69.5.1
Collecting pillow
  Using cached pillow-10.3.0-cp311-cp311-manylinux_2_28_x86_64.whl.metadata (9.2 kB)
Using cached pillow-10.3.0-cp311-cp311-manylinux_2_28_x86_64.whl (4.5 MB)
Installing collected packages: pillow
Successfully installed pillow-10.3.0
Collecting lockfile
  Using cached lockfile-0.12.2-py2.py3-none-any.whl.metadata (2.4 kB)
Collecting dbus-python
  Using cached dbus-python-1.3.2.tar.gz (605 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [106 lines of output]
      + meson setup /tmp/pip-install-_56kkncl/dbus-python_1e7df1fc7fa64c10aa7d71f723f4df70 /tmp/pip-install-_56kkncl/dbus-python_1e7df1fc7fa64c10aa7d71f723f4df70/.mesonpy-68aksqnl -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --native-file=/tmp/pip-install-_56kkncl/dbus-python_1e7df1fc7fa64c10aa7d71f723f4df70/.mesonpy-68aksqnl/meson-python-native-file.ini
      The Meson build system
      Version: 1.4.0
      Source dir: /tmp/pip-install-_56kkncl/dbus-python_1e7df1fc7fa64c10aa7d71f723f4df70
      Build dir: /tmp/pip-install-_56kkncl/dbus-python_1e7df1fc7fa64c10aa7d71f723f4df70/.mesonpy-68aksqnl
      Build type: native build
      Project name: dbus-python
      Project version: 1.3.2
      C compiler for the host machine: cc (gcc 8.5.0 "cc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20)")
      C linker for the host machine: cc ld.bfd 2.30-123
      Host machine cpu family: x86_64
      Host machine cpu: x86_64
      Compiler for C supports arguments -fno-common: YES
      Compiler for C supports arguments -Wno-missing-field-initializers: YES
      Compiler for C supports arguments -Wno-declaration-after-statement: YES
      Compiler for C supports arguments -Wno-inline: YES
      Compiler for C supports arguments -Wno-redundant-decls: YES
      Compiler for C supports arguments -Wno-switch-default: YES
      Compiler for C supports arguments -Wno-write-strings: YES
      Compiler for C supports arguments -Wcast-align: YES
      Compiler for C supports arguments -Wdouble-promotion: YES
      Compiler for C supports arguments -Wduplicated-cond: YES
      Compiler for C supports arguments -Wfloat-equal: YES
      Compiler for C supports arguments -Wformat-nonliteral: YES
      Compiler for C supports arguments -Wformat-security: YES
      Compiler for C supports arguments -Wformat=2: YES
      Compiler for C supports arguments -Winit-self: YES
      Compiler for C supports arguments -Wlogical-op: YES
      Compiler for C supports arguments -Wmissing-declarations: YES
      Compiler for C supports arguments -Wmissing-format-attribute: YES
      Compiler for C supports arguments -Wmissing-include-dirs: YES
      Compiler for C supports arguments -Wmissing-noreturn: YES
      Compiler for C supports arguments -Wnull-dereference: YES
      Compiler for C supports arguments -Wpacked: YES
      Compiler for C supports arguments -Wpointer-arith: YES
      Compiler for C supports arguments -Wshadow: YES
      Compiler for C supports arguments -Wswitch-enum: YES
      Compiler for C supports arguments -Wundef: YES
      Compiler for C supports arguments -Wunused-but-set-variable: YES
      Compiler for C supports arguments -Wjump-misses-init: YES
      Compiler for C supports arguments -Wmissing-prototypes: YES
      Compiler for C supports arguments -Wnested-externs: YES
      Compiler for C supports arguments -Wold-style-definition: YES
      Compiler for C supports arguments -Wpointer-sign: YES
      Compiler for C supports arguments -Wstrict-prototypes: YES
      Configuring _dbus-python-config.h using configuration

      Executing subproject dbus-gmain

      dbus-gmain| Project name: dbus-gmain
      dbus-gmain| Project version: undefined
      dbus-gmain| C compiler for the host machine: cc (gcc 8.5.0 "cc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20)")
      dbus-gmain| C linker for the host machine: cc ld.bfd 2.30-123
      dbus-gmain| Compiler for C supports arguments -fno-common: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wno-missing-field-initializers: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wcast-align: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wdouble-promotion: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wduplicated-branches: YES
      dbus-gmain| Compiler for C supports arguments -Wduplicated-cond: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wfloat-equal: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat-nonliteral: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat-security: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wformat=2: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Winit-self: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wlogical-op: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-declarations: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-format-attribute: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-include-dirs: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-noreturn: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wnull-dereference: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpacked: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpointer-arith: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wredundant-decls: YES
      dbus-gmain| Compiler for C supports arguments -Wshadow: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wswitch-default: YES
      dbus-gmain| Compiler for C supports arguments -Wswitch-enum: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wundef: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wunused-but-set-variable: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wwrite-strings: YES
      dbus-gmain| Compiler for C supports arguments -Wdeclaration-after-statement: YES
      dbus-gmain| Compiler for C supports arguments -Wjump-misses-init: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wmissing-prototypes: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wnested-externs: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wold-style-definition: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wpointer-sign: YES (cached)
      dbus-gmain| Compiler for C supports arguments -Wstrict-prototypes: YES (cached)
      dbus-gmain| Found pkg-config: YES (/bin/pkg-config) 1.4.2
      dbus-gmain| Run-time dependency dbus-1 found: YES 1.12.8
      dbus-gmain| Run-time dependency glib-2.0 found: YES 2.56.4
      dbus-gmain| Run-time dependency gthread-2.0 found: YES 2.56.4
      dbus-gmain| Program dbus-run-session found: YES (/bin/dbus-run-session)
      dbus-gmain| Build targets in project: 1
      dbus-gmain| Subproject dbus-gmain finished.

      Program python found: YES (/home/vmuser1/.config/toshy/.venv/bin/python)
      Dependency dbus-1 found: YES 1.12.8 (cached)
      Run-time dependency python found: YES 3.11
      Configuring TestSuitePythonService.service using configuration
      Configuring tmp-session-bus.conf using configuration
      Program dbus-run-session found: YES (/bin/dbus-run-session)
      ../test/meson.build:75: DEPRECATION: Project uses feature that was always broken, and is now deprecated since '1.3.0': str.format: Value other than strings, integers, bools, options, dictionaries and lists thereof..
      Run-time dependency python found: NO (tried pkgconfig, pkgconfig and sysconfig)

      ../test/meson.build:98:15: ERROR: Python dependency not found

      A full log can be found at /tmp/pip-install-_56kkncl/dbus-python_1e7df1fc7fa64c10aa7d71f723f4df70/.mesonpy-68aksqnl/meson-logs/meson-log.txt
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
Error installing/upgrading Python packages. Installer exiting.

@jeff9finger-usda

I am really wondering if there is some other kind of Python virtual environment like conda at work here. None of these issues show up on a standard install of RHEL (well, clones like Rocky and AlmaLinux, I gave up attempting to register/activate a real RHEL install). My installer takes into account the possibility of a venv like I use, so it does a deactivate in case there is one active in the current shell. But something else like conda might need another technique.

It would be good to see the PATH variable contents from a fresh shell/terminal tab.

This in particular is pinned specifically to get through the install on a RHEL 8 type distro.

Collecting pygobject<=3.44.1

But what's going wrong here seems similar to what was going wrong with dbus-python missing the "python" dependency, which seems to indicate some issue with the build process not finding what it is looking for, even though all the usual supporting packages were installed without any errors.


            gcc -pthread -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DPYCAIRO_VERSION_MAJOR=1 -DPYCAIRO_VERSION_MINOR=26 -DPYCAIRO_VERSION_MICRO=0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid -I/home/vmuser1/.config/toshy/.venv/include -I/usr/include/python3.11 -c cairo/bufferproxy.c -o build/temp.linux-x86_64-cpython-311/cairo/bufferproxy.o -Wall -Warray-bounds -Wcast-align -Wconversion -Wextra -Wformat=2 -Wformat-nonliteral -Wformat-security -Wimplicit-function-declaration -Winit-self -Winline -Wmissing-format-attribute -Wmissing-noreturn -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wreturn-type -Wshadow -Wsign-compare -Wstrict-aliasing -Wundef -Wunused-but-set-variable -Wswitch-default -Wno-missing-field-initializers -Wno-unused-parameter -Wno-unused-command-line-argument -fno-strict-aliasing -fvisibility=hidden -std=c99
            cairo/bufferproxy.c:32:10: fatal error: Python.h: No such file or directory
             #include <Python.h>
                      ^~~~~~~~~~
            compilation terminated.
            error: command '/bin/gcc' failed with exit code 1

Let's take a look at the package install results...

Package python3-dbus-1.2.4-15.el8.x86_64 is already installed.
Package python36-devel-3.6.8-38.module+el8.9.0+20976+d3c38525.x86_64 is already installed.
Package python3-pip-9.0.3-23.el8_9.1.noarch is already installed.
Package python3-tkinter-3.6.8-56.el8_9.3.x86_64 is already installed.

That python36-devel seems a little sus. Wondering if you can go ahead and try to manually install something like python311-devel to match the Python 3.11 that is being used to create the venv, and maybe be able to get through the install, even without the --no-dbus-python.

The python3-devel package is referred to generically without a more specific version number in the package name, and maybe that's going wrong on your system for some reason. I'll have to double-check but I don't think python36-devel is normally what satisfies that in my testing VMs.

Yeah, that's definitely not what happens on AlmaLinux 8.9 in my VM. It's installing python3.11-devel specifically, which is probably what you're missing.

Installing:
 python3.11                                                     x86_64                                    3.11.5-1.el8_9                                        appstream                                     29 k
 python3.11-devel                                               x86_64                                    3.11.5-1.el8_9                                        appstream                                    247 k
 python3.11-tkinter                                             x86_64                                    3.11.5-1.el8_9                                        appstream                                    407 k
Installing dependencies:
 mpdecimal                                                      x86_64                                    2.5.1-3.el8                                           appstream                                     92 k
 python3.11-libs                                                x86_64                                    3.11.5-1.el8_9                                        appstream                                     10 M
 python3.11-pip-wheel                                           noarch                                    22.3.1-4.el8_9.1                                      appstream                                    1.4 M
 python3.11-setuptools-wheel                                    noarch                                    65.5.1-2.el8                                          appstream                                    719 k
 tcl                                                            x86_64                                    1:8.6.8-2.el8                                         baseos                                       1.1 M
 tk                                                             x86_64                                    1:8.6.8-1.el8                                         appstream                                    1.6 M

Looks like I may have to more tightly control the versioned package names that get fed to the installer process, like I do for openSUSE systems.

Argh. OK, never mind. On a second run I see the same thing:

Package python3-dbus-1.2.4-15.el8.x86_64 is already installed.
Package python36-devel-3.6.8-38.module_el8.9.0+3700+efebe9fd.x86_64 is already installed.
Package python3-pip-9.0.3-23.el8_9.1.noarch is already installed.
Package python3-tkinter-3.6.8-56.el8_9.3.alma.1.x86_64 is already installed.

So... Back to wondering if there is some competing virtual environment acting on the system and messing with the build process.

PATH from new shell:

$ echo $PATH
/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/scripts:/home/vmuser1/.local/share/JetBrains/Toolbox/bin:/home/vmuser1/.local/share/JetBrains/Toolbox/scripts

(Wow just noticed that JetBrains ToolBox is in there 3 times! -- need to fix that)

As non-admin user.

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

Success!

Also, you recommend installing AppIndicator. I may have it installed, but not sure...

$ flatpak install extensionmanager
Looking for matches…
error: No remote refs found similar to ‘extensionmanager’
$ sudo dnf list | grep extensionmanager
$ sudo dnf install extensionmanager
Last metadata expiration check: 0:21:14 ago on Fri 17 May 2024 03:04:32 PM CDT.
No match for argument: extensionmanager
Error: Unable to find a match: extensionmanager

But looks like I have gnome-shell-extension-appindicator installed. Is that sufficient?

$ sudo dnf install gnome-shell-extension-appindicator
Last metadata expiration check: 0:25:31 ago on Fri 17 May 2024 03:04:32 PM CDT.
Package gnome-shell-extension-appindicator-1:29-8.el8.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!

Thanks

Yes, you can get the AppIndicator extension in the Software app on the RHEL 8 distro types. There's a little note about that on the distro compatibility list, but maybe I should add a note to spit out of the installer script at the end, for those installing on RHEL 8 or equivalent.

You don't see Extension Manager being available because you haven't set up the Flathub repo. But I don't think it's compatible with the old 3.38 or whatever version of GNOME on that distro version. And since you can get the AppIndicator extension from the Software app and don't need a Wayland extension, you really don't need it.

I think that is the right package name, but when I'm testing I usually just pop into the Software app and type "appindicator" and click the one that also says "KStatusNotifierItem". I don't like to try to install the package in the terminal because it seems like that doesn't always result in the extension being enabled right away. When I install from the Software app it always just activates immediately and the Toshy icon appears in the top bar.

Success!

Wow, it actually worked? And without attempting to bypass dbus-python, I hope? I knew it had to be something peculiar about your setup. And I take such great pains to deactivate a venv and build a standardized path inside the installer script environment, because I ran into similar things early on after people started using Toshy. I'm going to have to analyze whether I can do something to once again make the script more resilient against unusual path/environment setups. But I'm not sure what else I can do.

Your patience to continue with the troubleshooting and get through this has been impressive. A lot of people drop in here, leave an incomplete issue with insufficient information, and never show up again. Thanks for the excellent reporting. This will at the very least result in a FAQ entry.

In case installing that package didn't immediately activate the AppIndicator extension, you'll have to open the GNOME Extensions app (not the same as the Extension Manager Flatpak app) or install that app from the Software app, and use it to enable the extension. Or, log out, and log back in after about 10 seconds. Or, look up the terminal command to do the same thing, which is complicated and I can never remember exactly how it goes. The terminal command is confusingly similar to the binary name of the GNOME Extensions graphical app, but comes from the a different package.

(As much as I like GNOME, it's kind of annoying to deal with sometimes, if you need to use any extensions.)

Thanks. I think I have it installed and working correctly. IIUC, the evidence for this is the Joshy icon in the toolbar with all the controls. Is that right?

Also, just to confirm, if I want the Mac key mappings, and the physical keyboard is a Dell Laptop keyboard (well, its actually a Logitech MX Keys Mini), I just use the Keyboard Type as "Auto-Adapt" or "Windows", correct?

icon in the toolbar with all the controls. Is that right?

Yes. Though if you had not been able to get the icon to appear, the GUI "Toshy Preferences" app replicates most of the options you'll see in the tray icon menu. Not quite all, but most.

Also, just to confirm, if I want the Mac key mappings, and the physical keyboard is a Dell Laptop keyboard (well, its actually a Logitech MX Keys Mini), I just use the Keyboard Type as "Auto-Adapt" or "Windows", correct?

Unless the keyboard has a "Mac" mode but isn't actually an Apple keyboard with an identifiable name, you shouldn't need to think about the keyboard type. At least, that was the idea. The other options in that submenu are really just a way to temporarily force the Toshy config to identify all keyboard devices it sees as a specific type, while you follow the FAQ entry about getting a specific device to be identified correctly by adding some info to your config file.

In most cases, PC keyboards will effectively "fall through" the rest of the identification logic and just be treated as the default "Windows" type, while Apple keyboards will be identified with some search terms that usually work effectively.

Do let me know if that's not the case. The device name should be available when you use the diagnostic dialog shortcut:

https://github.com/RedBearAK/toshy#toshifying-an-application

And how to fix it in your config if it's misidentified:

https://github.com/RedBearAK/toshy/wiki/FAQ-(Frequently-Asked-Questions)#my-keyboard-is-not-recognized-as-the-correct-type

Before you vanish, can you share what you have in this environment variable, if anything? (Edit: I don't have that pre-defined in the AlmaLinux terminal environment, so it may be irrelevant, or if you have it defined it may have overridden some standard "assumed" path that would normally be used.)

LD_LIBRARY_PATH

Might have something to do with the chain of failures during builds.

Also, this may be the closest I can come to explaining what happened, but I'm not sure if this actually happened. Though it does seem like something modified (or escaped) my standardized path during the build processes.

This is from ChatGPT-4:

Subprocesses Modify PATH: Some build processes, especially those involving native extensions or additional toolchains (like those needing make, gcc, etc.), might modify or prepend to the PATH internally, relying on certain system tools that could be shadowed by the node directory.

I looked through the links you provided, and my keyboard seems to not be labeled as "Apple", so seems ok.

The only thing so far that I see is the CTRL-C in the terminal does not work. I have to use Cmd-C to send the signal to the process. In macos, using iTem2, I have this capability, and it would be nice to have here as well. I did a quick search in the FAW, but maybe I missed it. Is there a config option for this?

$ echo $LD_LIBRARY_PATH

Will you be incorporating these things into the regular release at some point?

Thanks again for your responsiveness!

The only thing so far that I see is the CTRL-C in the terminal does not work

Embedded terminal in VSCode or something? There's a whole Wiki page about that problem. With partial solution for VSCode.

I'm traveling so answers may be brief and infrequent for a while.

If not an embedded terminal inside a "GUI" app, get the app class of the terminal app window and the Ctrl-C issue should be fixable by adding to the "terminals" list. The standard GNOME terminal should already work as expected from macOS terminals.

The only thing so far that I see is the CTRL-C in the terminal does not work

Embedded terminal in VSCode or something? There's a whole Wiki page about that problem. With partial solution for VSCode.

No, just the plain terminal. the gnome-terminal is not mapping things correctly.

Class: 'Gnome-terminal' 
Title: 'vmuser1@vmdi-f82c-jeff-haynes:~' 

Input keyboard name: 'VMware VMware Virtual USB Keyboard' 
Device seen as type: 'Windows' 

Toshy config file sees this environment:  
 • DISTRO_ID ____________ 'rhel' 
 • DISTRO_VER ___________ '8.9' 
 • VARIANT_ID ___________ 'notfound' 
 • SESSION_TYPE _________ 'x11' 
 • DESKTOP_ENV __________ 'gnome' 
 • DE_MAJ_VER ___________ '3' 

Do any app class groups match on this window?:  
 • Terminals ____________ 'True' 
 • Remotes/VMs __________ 'False' 
 • File Managers ________ 'False' 
 • Web Browsers _________ 'False' 
 • VSCode(s) ____________ 'False' 
 • Dialogs ______________ 'False' 

 __________________________________________________ 
Keyboard shortcuts (Ctrl+C/Cmd+C) may not work here.
Select text with mouse. Triple-click to select all. 
Right-click with mouse and choose 'Copy' from menu.

I poked around in the config file, but could not figure out where to start for the terminal. Any hints?

I was able to get Ctrl-Space to perform code completion in IntelliJ, by making some customizations. They seem to work fine. And a shell from intellij works well - Ctrl-C, Cmd-C, Cmd-V work as expected

You won't have any luck fixing Ctrl+C in GNOME Terminal from the config file. This behavior is abnormal when the diagnostic dialog confirms that the window is being recognized as a terminal.

This smells like VMware interfering with the shortcut, which I've read about before online.

At the moment my suggestion is to substitute the physical equivalent of Cmd+Dot, which should send Ctrl+C to terminals, as it does in Terminal.app in macOS. I think that doesn't work in iTerm2, so you may have lost or never developed the habit of using Cmd+Dot to "cancel" things.

Will try to see if VMware can be tweaked to stop it from interfering.

I will look into the VMWare config. I'm also gonna try hyper as it is close to iTerm2 and supposedly runs on linux and windows

The hyper terminal app should work since I added the app class to the terminals list several months ago when someone mentioned it. But I didn't spend much time with it to check that all shortcuts work as expected. If you find something that doesn't seem to react like you would expect from Terminal.app or iTerm2, open a new issue and we can work on a specific keymap for hyper to apply some fixes if necessary.

hyper seems to work great! I had to get some npm repo infrastructure changes in order to install its plugins... but finally got it. So it seems to be working well at the moment!

Thank you!

RedBearAK / toshy

[BUG] Installer doesn't work for non-privileged users #278