Open chaim1221 opened 1 year ago
@chaim1221
Disclaimer: I'm not the Kinto dev, just a user and minor contributor.
Yeah, so temporary way around this is installing pipx
and using pipx
to install from the local xkeysnail
folder that the Kinto installer clones into ~/Downloads/kinto-master/xkeysnail
. I described how this allowed me to complete the Kinto install and get Kinto working, in issue #805.
Long term solution is to do what the Python docs have been recommending for years, which is to create a Python virtual environment if you have any need to install a Python package that isn't provided by a native distro package. Then you can do whatever you want in your venv
and the system won't complain about you using pip
, or installing any Python packages that might interfere with the system-wide Python installation (and possibly break things like the distro's package managers).
Apparently Python virtual environments are not as scary as I thought. They are just directories with some copies and symlinks to the main Python interpreter and the standard Python libraries, and when you "activate" the virtual environment it tells your app to look for what it needs inside that directory, rather than looking for things in the main system paths. You do have to "source" the activation binary/script before you try to run your Python app, but that's about it.
I have it all working in my own project, which is closely related to Kinto, but using keyszer
instead of xkeysnail
. So I'm able to install on Xubuntu and I'm sure Ubuntu 23.04 without running into this error. I'll probably test Ubuntu next.
@chaim1221
Sorry, looks like I can't test on Ubuntu until I find some hardware to put it on, because of a bug that makes it impossible to log into an Xorg session in a virtual machine created by software like GNOME Boxes or Virt-Manager (i.e., a QEMU VM).
https://ubuntuforums.org/showthread.php?t=2486167&page=3
Unbelievable that they let this get through QA, and still haven't fixed it with an update.
I have NEVER had the kind of trouble with a Linux distro that I've now had in the last few days with Xubuntu 23.04 (desktop frequently crashed when using file manager) and Ubuntu 23.04 (can't login to Xorg at all). Can't say that I'm impressed with Canonical's work in this release cycle. My testing on Fedora and Mint in the same VM software has gone much better.
Edit: Trying to login to an Xorg session also fails on VirtualBox. Amazing.
Hey there—
re: Lunar Lobster. I’m on bare metal at home, I haven’t tried virtualizing it. I would totally believe they don’t have everything in order.
re: Py. I can make a virtualenv and try installing it there. If it works maybe we could get fpm
to install it in a virtualenv, then make a deb and rpm that will put the result on the path somewhere.
What distro are you all developing on? Fedora? Arch?
@chaim1221
FWIW, I tested my installer on Ubuntu 22.04 and had no issues, and it worked on Xubuntu 23.04, so I have no reason to think it wouldn't work on Ubuntu 23.04. If you're feeling particularly adventuresome you can try it:
https://github.com/RedBearAK/toshy/tree/dev_alpha
Note that this is a completely separate project from Kinto, so if you have issues submit them on that repo, please do not report them here in Kinto's issues:
https://github.com/RedBearAK/toshy/issues
The dev_alpha
branch is the only one with commits so far, but that's just because I'm still in the process of tweaking the installer to make it as widely compatible as possible. It's more like an early beta as far as the installer goes, but the actual config, if the installer works, should be solid.
There's no explicit "uninstall" yet, but there are some "remove" scripts that will disable and remove basically everything that does anything meaningful, if you want to back it out.
@chaim1221
Tested my installer on Ubuntu 23.04 on a MacBookPro5,5 model. Went perfectly, just had to remember to log in with "GNOME on Xorg" after rebooting, since Ubuntu has been defaulting to a Wayland session for a while now.
There is a working "draft" branch of keyszer
with Wayland+GNOME support that would actually work in this situation, but I haven't decided yet if I should integrate it into my installer.
Unfortunately I bricked the computer I tried this on (unrelated), and haven't gotten around to chrooting it again yet. As soon as I do I'll let y'all know. Thanks for taking a look. <3
I solve this in a few steps:
~/Downloads/kinto-master/xkeysnail
and do python3 -m pip install .
~/Downloads/kinto-master/xkeysnail_service.sh
and remove https://github.com/rbreaves/kinto/blob/master/xkeysnail_service.sh#L408 and https://github.com/rbreaves/kinto/blob/master/xkeysnail_service.sh#L569~/Downloads/kinto-master
and it should be goodI'm not sure why the installation script asks for sudo pip
in the two cases, @RedBearAK do you know the reason? If sudo pip
could be safely removed, I can draft a PR for this.
@wtdcode
I'm not sure why the installation script asks for sudo pip in the two cases, @RedBearAK do you know the reason? If sudo pip could be safely removed, I can draft a PR for this.
Although my own offshoot project (Toshy) uses a Python virtual environment and I've been poking around in the Kinto installer for a long time, you should take the following with a grain of salt:
From what I understand, historically the keymapper Kinto uses (xkeysnail) has been run as root to get around permission issues with accessing the uinput
device (as far as I know). This then required using xhost
to open up the X server to root. The installer uses sudo pip3
probably because it was the easiest way to get access to the necessary utilities to get things to work. If you just use pip3
to install things they get installed in a folder structure in your home rather than the system Python library locations. And if you create a Python virtual environment then the packages installed by pip will get installed in the venv
location you created. In both cases you have to make sure the install location is in the paths that Python sees when you attempt to use something that needs one of those packages. This usually requires modifying the PYTHONPATH
environment variable and sys.path
when running a Python script.
And, just in case you're not aware of this, in order to actually use the virtual environment once you leave the shell where you activated it, you need launcher scripts that will re-activate that specific venv before running the actual commands you're trying to use (e.g., the keymapper command that actually loads your config). That's what I've had to do with my own project.
My own project uses a Python virtual environment, activates it whenever it needs to do anything, and doesn't run the keymapper as root. Instead Toshy uses a udev
rules file to give your user write access to the uinput
device for the virtual keyboard. By not running as a separate user it was possible to modify the keymapper (keyszer, forked from xkeysnail) to make it support a couple of different Wayland environments (KDE and GNOME).
Toshy is in a fairly stable state and has installed successfully on a large selection of the most common Linux distros, including all the Ubuntu flavors I've tried. If you want to try it, just make sure you don't post issues about it here in the Kinto issues. It's a completely separate project, although in a way it is meant as a laboratory to test things that could be added to Kinto in the future.
@wtdcode
I'm not sure why the installation script asks for sudo pip in the two cases, @RedBearAK do you know the reason? If sudo pip could be safely removed, I can draft a PR for this.
Although my own offshoot project (Toshy) uses a Python virtual environment and I've been poking around in the Kinto installer for a long time, you should take the following with a grain of salt:
From what I understand, historically the keymapper Kinto uses (xkeysnail) has been run as root to get around permission issues with accessing the
uinput
device (as far as I know). This then required usingxhost
to open up the X server to root. The installer usessudo pip3
probably because it was the easiest way to get access to the necessary utilities to get things to work. If you just usepip3
to install things they get installed in a folder structure in your home rather than the system Python library locations. And if you create a Python virtual environment then the packages installed by pip will get installed in thevenv
location you created. In both cases you have to make sure the install location is in the paths that Python sees when you attempt to use something that needs one of those packages. This usually requires modifying thePYTHONPATH
environment variable andsys.path
when running a Python script.
This is a bit weird to me as kintosh is a userland program, no?
And, just in case you're not aware of this, in order to actually use the virtual environment once you leave the shell where you activated it, you need launcher scripts that will re-activate that specific venv before running the actual commands you're trying to use (e.g., the keymapper command that actually loads your config). That's what I've had to do with my own project.
I activate a default venv on my shell startup so it should be fine.
My own project uses a Python virtual environment, activates it whenever it needs to do anything, and doesn't run the keymapper as root. Instead Toshy uses a
udev
rules file to give your user write access to theuinput
device for the virtual keyboard. By not running as a separate user it was possible to modify the keymapper (keyszer, forked from xkeysnail) to make it support a couple of different Wayland environments (KDE and GNOME).Toshy is in a fairly stable state and has installed successfully on a large selection of the most common Linux distros, including all the Ubuntu flavors I've tried. If you want to try it, just make sure you don't post issues about it here in the Kinto issues. It's a completely separate project, although in a way it is meant as a laboratory to test things that could be added to Kinto in the future.
I checked it and gave it a start because it looks insanely good! I will definitely give it a try.
This is a bit weird to me as kintosh is a userland program, no?
Not sure how to answer that. The keymapper that actually does the work just needs access to input devices for incoming key codes, then uses /dev/uinput to send key codes into the Linux input system. When keyszer
was forked from xkeysnail
the running as root was kind of deprecated, in favor of a udev
rule solution. Either way some permissions need to be tweaked to make it work, because Linux tries to keep the input stack secure so other users can't eavesdrop on your input that easily. I still only have a superficial understanding of most of what happens at the lower levels.
I activate a default venv on my shell startup so it should be fine.
That will certainly work if you're just running commands in a terminal. Not sure how well that will work when some other process outside the shell needs to run a command with the venv
active. My installer creates its own virtual environment specific to what it needs, and installs a very customized version of keyszer
to support what it does. You would be able to install the official keyszer
package system-wide or in your user Python library and the two (or more) copies of keyszer
shouldn't interfere with each other.
I checked it and gave it a star because it looks insanely good! I will definitely give it a try.
Thanks! Let me know if you run into problems.
Describe the bug I tried the install script. It failed.
I heard about the project from multiple sources and had high hopes. I was a little worried when it started messing with Python. To be clear the solution I'm looking for is not
--break-system-packages
haha.Expected behavior Expected the install script to succeed.
Install Type: Bare Metal, haven’t tried VM Distro: Ubuntu Lunar Lobster 23.04 DE: Gnome Branch: master Commit:
Logs and status if relevant
Screenshots
Additional context Add any other context about the problem here.