Package Details: ydotool 1.0.1-2

Git Clone URL: (read-only, click to copy)
Package Base: ydotool
Description: Generic command-line automation tool (no X!)
Upstream URL:
Licenses: AGPL3
Submitter: 1ace
Maintainer: LiteracyFanatic (Arvedui, evybongers)
Last Packager: Arvedui
Votes: 11
Popularity: 1.38
First Submitted: 2020-05-15 15:50 (UTC)
Last Updated: 2022-03-13 13:46 (UTC)

Latest Comments

X_m7 commented on 2022-06-23 09:05 (UTC)

In my case starting the ydotool service and using ydotool afterwards works with no root access required, and my user is not even in the input group, and I also got rid of the 80-uinput.rules file.

After digging deeper it turns out that Steam (or the Arch package at least) installs the below udev rule (as part of /usr/lib/udev/rules.d/70-steam-input.rules), which appears to give access to /dev/uinput to the user already in my case:

KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput", TAG+="uaccess", OPTIONS+="static_node=uinput"

The Steam Controller known issues page says that the rule is needed for the gamepad emulation mode.

trox commented on 2022-03-16 19:04 (UTC)

It seems that 80-uinput.rules is no longer required. I removed it and ydotool still works.

Arvedui commented on 2022-03-13 13:47 (UTC)

Thanks! I just made the changes.

1ace commented on 2022-03-12 17:11 (UTC)

@Arvedui: sorry, I didn't see your message; I apparently had the notifications turned off on this package.

You got it mostly right, but the libevdevplus & libuinputplus dependencies are no longer used, and there's a build flags that doesn't apply anymore (cmake warns that it's ignored). The following patch fixes those :)

diff --git a/PKGBUILD b/PKGBUILD
index c5dbc208bbccab1573c6..01e3c8e01307bbf0ade8 100644
@@ -5,7 +5,6 @@ pkgver=1.0.1
 pkgdesc="Generic command-line automation tool (no X!)"
 arch=('x86_64' 'aarch64')
-depends=('libevdevplus' 'libuinputplus')
 makedepends=('cmake' 'ninja' 'scdoc')
@@ -24,7 +23,6 @@ build() {
     -DCMAKE_INSTALL_MANDIR=/usr/share/man \
     -DCMAKE_BUILD_TYPE=Release \
     -G Ninja \
     -S "$pkgname-$pkgver" -B build
   ninja -C build

bbgun7 commented on 2022-03-01 00:01 (UTC)

I think the latest patch is here:

debendra commented on 2022-02-10 07:38 (UTC) (edited on 2022-02-10 07:39 (UTC) by debendra)

I added the bin version of this package, hope it might be a interest.

Arvedui commented on 2022-02-08 19:44 (UTC)

I think only Depau can do that, but if you send the patch my way I will happily apply and push it.

1ace commented on 2022-02-06 19:49 (UTC)

Depau, LiteracyFanatic, Arvedui, evybongers: hey all! I've been too quick to remove myself from the maintainers for this package (and I forgot I did that); could you add me back? I have the update to 1.0.0 ready but when I pushed I got an error remembered that I removed myself ^^

dr460nf1r3 commented on 2021-11-05 11:42 (UTC)

Please add git to makedepends :)

ForrestHilton commented on 2021-09-07 21:20 (UTC) (edited on 2021-09-07 21:22 (UTC) by ForrestHilton)

I struggled to activate ydotool.service. systemctl --user enable ydotool is the correct command, but --user is incompatible with sudo, so I had to put setuid on ydotoold itself. Would you please consider adding this?

I didn't understand what was going on with the input group, but I don't want user programs able to record keystrokes, so ydotool should still need sudo.

goetzc commented on 2021-04-17 16:24 (UTC) (edited on 2021-04-17 16:26 (UTC) by goetzc)

Hey, can you add a post_install message (similar as the one for the input group) suggesting to enable the newly ydotool.service user service?

Arvedui commented on 2021-03-22 08:05 (UTC)

makepkg supports using a common source directory for all pkgbuilds and that is exactly what I do. And I have tons of v${something} packages floating around in that directory because of github. This causes two problems for me: 1. I can not easily purge them because I have to look into them to know what source they contain. 2. If two packages have the same version, even when not at the same time, they can conflict on the file name in the sources directory and makepkg will complain about not being able to validate the source files.

1ace commented on 2021-03-21 23:16 (UTC)

Hi everyone! Sorry I haven't been active for a couple of months.

In order to avoid issues lingering on this package in the future, I've added those of you who suggested contributions and are already maintainers of some other package as maintainers of this one too; use your power wisely :)

@Arvedui: I don't quite understand what your use-case could be where the file names between packages need to be unique; could you explain it to me?
Note that you have now push access to this package, and I'm not opposed to you pushing this change, but I'd like to understand why :)

@bbaserdem: I have no idea what the issue is; could you report that upstream?

@mergen: thanks, removed :)

@allexj: Thanks for the report! I'll have to admit I don't think I've tried to use it since the rewrite, so I haven't noticed this issue (and my user is in the input group so I wouldn't have noticed that issue anyway).
@evybongers has sent me patches that I have applied to the repo; they should fix this; let me know if you still experience issues :)

allexj commented on 2021-03-01 17:56 (UTC)

If you install it you can't use it. You have to follow these steps:

mergen commented on 2021-02-26 12:04 (UTC)

Thx for great work mate, According to the source "boost" is no longer a dependency.

bbaserdem commented on 2021-02-04 14:45 (UTC)

I'm getting compilaton errors; specifically this. (I'm guessing issues finding IODash; whatever it is.) Do you know how to fix it? I have not used cmake myself before.

-- CPM: adding package IODash@0.1.0 (v0.1.0)
CMake Error at /usr/share/cmake-3.19/Modules/ExternalProject.cmake:2542 (message):
  error: could not find git for clone of iodash-populate
Call Stack (most recent call first):
  /usr/share/cmake-3.19/Modules/ExternalProject.cmake:3430 (_ep_add_download_command)
  CMakeLists.txt:13 (ExternalProject_Add)

-- Configuring incomplete, errors occurred!
See also "/build/ydotool/src/build/_deps/iodash-subbuild/CMakeFiles/CMakeOutput.log".

CMake Error at /usr/share/cmake-3.19/Modules/FetchContent.cmake:977 (message):
  CMake step for iodash failed: 1
Call Stack (most recent call first):
  /usr/share/cmake-3.19/Modules/FetchContent.cmake:1118:EVAL:2 (__FetchContent_directPopulate)
  /usr/share/cmake-3.19/Modules/FetchContent.cmake:1118 (cmake_language)
  /usr/share/cmake-3.19/Modules/FetchContent.cmake:1161 (FetchContent_Populate)
  /build/ydotool/src/build/cmake/CPM_0.27.5.cmake:461 (FetchContent_MakeAvailable)
  /build/ydotool/src/build/cmake/CPM_0.27.5.cmake:347 (cpm_fetch_package)
  CMakeLists.txt:16 (CPMAddPackage)

-- Configuring incomplete, errors occurred!
See also "/build/ydotool/src/build/CMakeFiles/CMakeOutput.log".
==> ERROR: A failure occurred in build().

Arvedui commented on 2021-01-28 14:40 (UTC) (edited on 2021-01-28 14:47 (UTC) by Arvedui)

Could you please give the source a unique name? Having sources like v0.2.0.tar.gz when using a common source directory is kinda problematic.

You can do that by prepending the source url with something like this: ${pkgname}-${pkgver}::

(same for libevdevplus and libuinputplus if you would be so kind)

This package is also missing a make dependency on git it seems.

LiteracyFanatic commented on 2021-01-09 18:42 (UTC)

Haha, no problem. As far as build errors go, this was an easy one to figure out.

1ace commented on 2021-01-09 18:39 (UTC)

@LiteracyFanatic: ah you're right, I forgot to do that :facepalm:

LiteracyFanatic commented on 2021-01-09 18:37 (UTC)

Could you please add scdoc as a build dependency?

Libgxps commented on 2020-12-01 10:06 (UTC) (edited on 2020-12-05 17:58 (UTC) by Libgxps)

Please add the aarch64 architecture. It builds quite nicely. Thank you for your support.