Package Details: ckb-next 0.4.2-6

Git Clone URL: https://aur.archlinux.org/ckb-next.git (read-only, click to copy)
Package Base: ckb-next
Description: Corsair Keyboard and Mouse Input Driver, release version
Upstream URL: https://github.com/ckb-next/ckb-next
Licenses: GPL2
Conflicts: ckb-git, ckb-git-latest, ckb-next-git
Provides: ckb-next
Submitter: tatokis
Maintainer: tatokis (steinex)
Last Packager: tatokis
Votes: 24
Popularity: 3.72
First Submitted: 2018-12-29 16:24
Last Updated: 2020-10-10 15:29

Latest Comments

1 2 3 Next › Last »

Pillgar commented on 2020-11-22 02:14

Not sure if this is the right place to post this, but it appears libxkbcommon and libxkbcommon-x11 v1.0.2 causes ckb-next to crash on start up after pressing any key on the keyboard. I noticed core-dumps referencing these two packages after ckb-next tray-applet loads on startup. The keyboard is still functioning after crash, and I can reload the applet manually.

Downgrading both packages fixes the bug.

TYVM

Edit: I think it's just related to libxkbcommon-x11 v1.0.2. Upgrading libxkbcommon didn't cause any crash (just libxkbcommon-x11)

yochananmarqos commented on 2020-08-26 03:10

@tatokis: Thank you for the detailed explanation.

tatokis commented on 2020-08-25 21:31

If libpulse is not installed during build, it complains:

That is intentional, since people didn't want to pull in pulse as a dependency. If we add pulse to makedepends, then it'll be installed no matter what. I've been wondering if there's a way to add it in makedepends and make it easy for people to disable it by editing the PKGBUILD.

This does not require libappindicator-gtk2 to display the icon, libappindicator-gtk3 works fine.

It only searches for the gtk2 version of appindicator (not appindicator3) [0], and only prefers it if certain conditions are met [1] [2]. You were most likely not using appindicator in the first place. It's also why it's optional. In the end, it doesn't matter, since appindicator support was removed in git. [3]

[0] https://github.com/ckb-next/ckb-next/blob/v0.4.2/cmake/modules/FindAppindicator.cmake#L51 [1] https://github.com/ckb-next/ckb-next/blob/v0.4.2/src/gui/CMakeLists.txt#L91 [2] https://github.com/ckb-next/ckb-next/blob/v0.4.2/src/gui/mainwindow.cpp#L180-L189 [3] https://github.com/ckb-next/ckb-next/commit/4c070c5d3619416d5c7866ce29f546911ffe8faa

yochananmarqos commented on 2020-08-20 04:27

If libpulse is not installed during build, it complains:

-- Could NOT find PulseAudioSimple (missing: PULSEAUDIOSIMPLE_LIBRARY PULSEAUDIOSIMPLE_INCLUDE_DIR)
-- Could NOT find PulseAudio (missing: PULSEAUDIO_LIBRARY PULSEAUDIO_INCLUDE_DIR)
CMake Warning at src/animations/mviz/CMakeLists.txt:31 (message):
  Missing PulseAudio Simple API.  Not building mviz.

namcap complains about libpulse being in optdepends():

Dependency libpulse detected but optional (libraries ['usr/lib/libpulse.so.0', 'usr/lib/libpulse-simple.so.0'] needed in files ['usr/bin/ckb-next', 'usr/lib/ckb-next-animations/mviz'])

I imagine it's being kept optional for those who don't want to install PulseAudio, but it should be at least in makedepends().

This does not require libappindicator-gtk2 to display the icon, libappindicator-gtk3 works fine.

depends=('quazip' 'hicolor-icon-theme')
makedepends=('git' 'cmake' 'libpulse')
optdepends=('libappindicator-gtk3: tray icon'
            'libpulse')

mithrial commented on 2020-08-06 16:05

Thank you!

tatokis commented on 2020-08-06 11:29

@mithrial Apologies, I committed the wrong thing and didn't even realise. Should be fixed now.

mithrial commented on 2020-08-06 09:42

The prepare function fails for me because it doesn't find the provided patch file (it's not copied into the source directory).

Adding the patch file to the list of sources will fix it:

source=(
    "https://github.com/ckb-next/$pkgname/archive/v$pkgver.tar.gz"
    "a9f41cd8b8f5b04c0c66c6d94f96a9725943831e.patch"
)
sha256sums=(
    '75b6908d5590c293dee8258a83d4ebe206306d3df9f867596e953ef7c6a86440'
    '33eb682dfb0b0651fcf7e922978fb09ae07f072dabe538976a3b1ecf9115120f'
)

Magotchi commented on 2020-05-21 14:00

The "Linking C executable" part of the build fails for me as follows:

[ 24%] Linking C executable ../../bin/ckb-next-daemon
/usr/bin/ld: CMakeFiles/ckb-next-daemon.dir/device_keyboard.c.o:(.rodata+0x0): multiple definition of `devpath'; CMakeFiles/ckb-next-daemon.dir/command.c.o:(.rodata+0x120): first defined here
/usr/bin/ld: CMakeFiles/ckb-next-daemon.dir/device_mouse.c.o:(.rodata+0x0): multiple definition of `devpath'; CMakeFiles/ckb-next-daemon.dir/command.c.o:(.rodata+0x120): first defined here
/usr/bin/ld: CMakeFiles/ckb-next-daemon.dir/devnode.c.o:(.data.rel.ro.local+0x0): multiple definition of `devpath'; CMakeFiles/ckb-next-daemon.dir/command.c.o:(.rodata+0x120): first defined here
/usr/bin/ld: CMakeFiles/ckb-next-daemon.dir/firmware.c.o:(.rodata+0x1e0): multiple definition of `devpath'; CMakeFiles/ckb-next-daemon.dir/command.c.o:(.rodata+0x120): first defined here
/usr/bin/ld: CMakeFiles/ckb-next-daemon.dir/main.c.o:(.rodata+0x8): multiple definition of `devpath'; CMakeFiles/ckb-next-daemon.dir/command.c.o:(.rodata+0x120): first defined here
/usr/bin/ld: CMakeFiles/ckb-next-daemon.dir/notify.c.o:(.rodata+0x0): multiple definition of `devpath'; CMakeFiles/ckb-next-daemon.dir/command.c.o:(.rodata+0x120): first defined here
/usr/bin/ld: CMakeFiles/ckb-next-daemon.dir/usb.c.o:(.rodata+0x40): multiple definition of `devpath'; CMakeFiles/ckb-next-daemon.dir/command.c.o:(.rodata+0x120): first defined here
/usr/bin/ld: CMakeFiles/ckb-next-daemon.dir/usb_linux.c.o:(.rodata+0xf8): multiple definition of `devpath'; CMakeFiles/ckb-next-daemon.dir/command.c.o:(.rodata+0x120): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [src/daemon/CMakeFiles/ckb-next-daemon.dir/build.make:451: bin/ckb-next-daemon] Error 1
make[1]: *** [CMakeFiles/Makefile2:374: src/daemon/CMakeFiles/ckb-next-daemon.dir/all] Error 2
make: *** [Makefile:172: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Tanghe commented on 2020-05-18 20:57

this package is broken for me i get allot of errors during the build. not as manny zhen installing from git and that install doesn't fail.

Roken commented on 2019-11-05 19:19

Good call. /usr/bin was owned by $USER.

Changed to root:root and all good. This seems to stem from a "minor" error some 3 -4 years ago (which I thought I'd by now fully fixed). Wonder why it only just became a problem.

Nevertheless, update now built and installed.