Package Details: leap-motion-driver 2.3.1-7

Git Clone URL: https://aur.archlinux.org/leap-motion.git (read-only, click to copy)
Package Base: leap-motion
Description: The Leap Motion Developer SDK
Upstream URL: https://developer.leapmotion.com/downloads
Licenses: custom
Submitter: robertfoster
Maintainer: rigred
Last Packager: rigred
Votes: 31
Popularity: 0.000000
First Submitted: 2017-04-16 17:28
Last Updated: 2019-01-31 23:15

Latest Comments

1 2 3 4 5 6 Next › Last »

pix3l commented on 2021-01-29 20:26

@rigred: I've came to conlcusion that all archlinux build infrastructure is bunch of broken hacky scripts. Why? It's one of the examples (take a look on different pkgrels [totally different PKGBUILD] returned trough git):

https://aur.archlinux.org/packages/leap-motion-sdk/ Package Details: leap-motion-sdk 2.3.1-7

https://aur.archlinux.org/packages/leap-motion 404 - Page Not Found

git clone "https://aur.archlinux.org/leap-motion-sdk.git" grep pkgrel leap-motion-sdk/PKGBUILD pkgrel=2

git clone "https://aur.archlinux.org/leap-motion-driver.git" grep pkgrel leap-motion-sdk/PKGBUILD pkgrel=2


I know that most of archlinux devs deserve that, but i have sometimes feeeling that it's directed by bunch of clowns. Not because of bugs(shit happens), but because how hard it's to communicate with them. They have many mailing lists listed on site, but after writing with bug reports and PKGBUILD diffs once, I've got mails bounced to me(because of unsuficient priviliges. Then I wonder why they are listed publicly and not marked as dev-only). And once I found list where my mail has been accepted, while it has been pointing valid bug in PKGBUILD it has been rejected, because I've used AUR as conflict example (it has been corrected soon, after fighting more on lists).

It's very dissapointing and frustrating, that devs are acting like politicians/lawyers(non-meritocratically), because I've got many corrected/updated and self-written PKGBUILDs and bug reports saved on HDD, because I don't feel the power to go trough all this cat and mouse game. And, I'm not new to OSS world or distro development. I was an active PLD developer trough many years and I hope I will back soon to it, because happily they returned to RedHat's RPM 4 (from rpm5.org). Pacman is the most primitive and frustrating package manager I've ever met(at least in latest release they take package version into account, unlike previous versions that took the one from first repo). And PKGBUILD [especially from AUR, but official too] are the worst build receipes I've ever worked with (I worked with thousands of them from PLD, Fedora, Debian, FreeBSD and Gentoo over the years). And if you ask me, why then I'm using Arch if I hate so much it's tooling and quality? Because I love rolling-release distros(but with frequent python releases[with incompatible ABI] I'm starting to hate it), I like high selection of packages in official and unoficial repos and AUR. The strongest point of Arch is big community of skilled devs. The problem is quality(or lack of and lazyines of many of thems. It's caused by lack of strict rules for PKGBUILDs and lack of enforcement of them). There are thousands packages in arch (and some in extra/commmunity) that got dconflicting files, with python as example where I had to add rm -rf "${pkgdir}/usr/lib/python3./site-packages/tests/" It could be automated and even checked by makepkg(with big red warnings abouy it) there are also many conflicts with init.py and pycache/init.cpython-.pyc

Other distros got easilly accessible mailing lists and IRC channels, while Archlinux is like China with Great FireWall.

Sorry for offtopic, but I'm frustrated with dealing with all this bugs and other inconveniences to fetch latest PKGBUILD. It should be easy as possible (AUR is promoted as one of the strongest points of ArchLinux, but all this svn2git is bugged as hell)

rigred commented on 2021-01-29 12:11

Btw you should really switch to something like yay instead of yaourt. yaourt is vulnerable abandonware at this point

rigred commented on 2021-01-29 12:01

Thanks @pix3l I will take a look at it again and see about cleaning up this package a bit. leap-motion development has stalled almost completely over the past year.

pix3l commented on 2021-01-29 11:57

I found the cause of issue. aur search (and yaourt and webpage) don't find 'leap-motion', 'leap-motion-driver 'leap-motion-sdk' and they are downloaded with older release. Downloading it by aur fetch leap-motion fixes that, but why base name ins not searchable? Am I doing something wrong?

pix3l commented on 2021-01-24 19:13

In the past it worked correctly. Problem appeared in last few months It starts correctly, but hangs on shutdown (systemctl stop), so it slows down shutodown/reboot

systemctl status leapd ● leapd.service - Leap Motion Service Daemon Loaded: loaded (/usr/lib/systemd/system/leapd.service; enabled; vendor preset: disabled) Active: failed (Result: timeout) since Sun 2021-01-24 20:11:13 CET; 1min 52s ago Process: 2698138 ExecStart=/usr/bin/leapd (code=killed, signal=KILL) Main PID: 2698138 (code=killed, signal=KILL)

sty 24 20:11:13 sinistar systemd[1]: leapd.service: State 'stop-sigterm' timed out. Killing. sty 24 20:11:13 sinistar systemd[1]: leapd.service: Killing process 2698138 (leapd) with signal SIGKILL. sty 24 20:11:13 sinistar systemd[1]: leapd.service: Killing process 2698149 (leapd) with signal SIGKILL. sty 24 20:11:13 sinistar systemd[1]: leapd.service: Killing process 2698150 (leapd) with signal SIGKILL. sty 24 20:11:13 sinistar systemd[1]: leapd.service: Killing process 2698152 (leapd) with signal SIGKILL. sty 24 20:11:13 sinistar systemd[1]: leapd.service: Killing process 2698158 (leapd) with signal SIGKILL. sty 24 20:11:13 sinistar systemd[1]: leapd.service: Killing process 2698170 (n/a) with signal SIGKILL. sty 24 20:11:13 sinistar systemd[1]: leapd.service: Main process exited, code=killed, status=9/KILL sty 24 20:11:13 sinistar systemd[1]: leapd.service: Failed with result 'timeout'. sty 24 20:11:13 sinistar systemd[1]: Stopped Leap Motion Service Daemon.

parkerlreed commented on 2019-02-01 16:32

@rigred Thanks

rigred commented on 2019-01-31 23:10

@parkerlreed - fixed with the appropriate systemd syntax.

rigred commented on 2019-01-31 21:51

This package is a bit klunky - and includes a good few workarounds to the strange choices made by leap motion.

I'll have to take a look at things and iron out some of it's naughty behaviour.

parkerlreed commented on 2019-01-31 15:49

A suggestion for the leapd.service

Adding

ExecStop=/usr/bin/killall -9 leapd

Since leapd does not respond to SIGINT (^C)

More times than not my shutdown hangs because it doesn't exit properly.

parkerlreed commented on 2019-01-29 20:34

Thanks for keeping this up to date! Such a fun device to play with.