Package Details: ydotool-git 1:1.0.4.r0.g57ba7d0-1

Git Clone URL: https://aur.archlinux.org/ydotool-git.git (read-only, click to copy)
Package Base: ydotool-git
Description: Generic command-line automation tool (no X!)
Upstream URL: https://github.com/ReimuNotMoe/ydotool
Keywords: wayland xdotool
Licenses: AGPL3
Conflicts: ydotool
Provides: ydotool
Submitter: depau
Maintainer: kyechou
Last Packager: kyechou
Votes: 18
Popularity: 0.94
First Submitted: 2019-01-20 17:17 (UTC)
Last Updated: 2023-08-20 19:39 (UTC)

Required by (27)

Sources (2)

Pinned Comments

depau commented on 2019-10-16 21:43 (UTC) (edited on 2019-10-16 21:44 (UTC) by depau)

Hi, please report ydotool bugs to upstream. Only report packaging issues here. Thank you.

Latest Comments

1 2 3 Next › Last »

glitsj16 commented on 2021-01-23 01:57 (UTC)

Upstream has changed its license to AGPLv3. Also, why are boost-libs still in depends? For me ydotool{,d} build and work fine without it. The only depends IMO is glibc, which seems to be what upstream states here.

depau commented on 2021-01-23 00:03 (UTC)

Upstream updated the package and added back make install functionality.

So everything should be where it is supposed to be now, as long as they continue to ensure it follows the GNU standard path variables conventions.

I verified that the systemd unit and the manpages are where they're supposed to be.

bwidawsk commented on 2021-01-19 18:40 (UTC)

Boost is no longer needed makedepend. scdoc is now a needed makedepend.

depau commented on 2021-01-17 16:30 (UTC)

That's extremely dumb, I wonder what these options are for:

-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_INSTALL_LIBDIR=/usr/lib \

Anyway, an update is coming.

Saluu commented on 2021-01-09 13:40 (UTC) (edited on 2021-01-10 12:21 (UTC) by Saluu)

Not sure if this is an upstream issue or needs to be fixed in the PKGBUILD, but as of some recent changes in upstream, this package no longer builds correctly. The resulting directory structure for the pkg folder is

pkg
└── ydotool-git
    └── usr
        ├── include
        │   └── cxxopts.hpp
        └── lib
            ├── cmake
            │   └── cxxopts
            │       ├── cxxopts-config-version.cmake
            │       ├── cxxopts-config.cmake
            │       └── cxxopts-targets.cmake
            └── systemd
                └── user
                    └── ydotool.service

In particular, the binaries are missing and actually, it just looks completely incorrect.

I created https://github.com/ReimuNotMoe/ydotool/issues/94. Depending on the discussion there, it might be necessary to make some changes to the PKGBUILD. It might also make sense to switch to the ninja based build that https://aur.archlinux.org/packages/ydotool/ is using.

EDIT: So apparently, this change is intentional by upstream. the cmake based build does not support installing to directories anymore.

CMake will no longer build the packages or install compiled files to system directories. Because it's complicated to build packages for every distro correctly using CPack, and every distribution has its own customs of filesystem hierarchy. I suggest you to copy compiled files to desired destination manually.

The author suggest to copy the files to the desired directories manually, which the PKGBUILD would need to do.

nicolai_d commented on 2020-11-25 20:46 (UTC)

Hi, this builds fine on aarch64, is there a reason for not including it in the PKGBUILD ? (Same goes for libevdevplus and libuinputplus btw)

adventurer commented on 2020-10-22 12:10 (UTC)

Thanks for providing this package which I installed today. I can confirm that Auto-Type works for KeePass with Wayland on KDE. Cool!

depau commented on 2020-04-02 23:28 (UTC)

Oh, that explains a lot of things, thanks for reporting that. I'll fix it tomorrow.

FunctionalHacker commented on 2020-03-31 12:18 (UTC)

Hey I think the systemd service file should go to /usr/lib/systemd/user. At least I have previously run my own service as a user service. Tried running it as a system service and ydotool doesn't find it.

Also, in my opinion it would make more sence if it was called ydotoold.service, but this is an issue at upstream. I will open a ticket there when I find the time.

depau commented on 2020-03-07 07:40 (UTC)

@novenary yes, it looks like it is.

I added a workaround so us Arch users should be good for now :)

1 2 3 Next › Last »