Search Criteria
Package Details: leap-motion-sdk 2.3.1-7
Package Actions
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 (UTC) |
Last Updated: | 2019-01-31 23:15 (UTC) |
Latest Comments
pix3l commented on 2021-01-29 20:26 (UTC)
@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 (UTC)
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 (UTC)
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 (UTC)
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 (UTC) (edited on 2021-01-24 19:13 (UTC) by pix3l)
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 (UTC)
@rigred Thanks
rigred commented on 2019-01-31 23:10 (UTC)
@parkerlreed - fixed with the appropriate systemd syntax.
rigred commented on 2019-01-31 21:51 (UTC)
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 (UTC)
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 (UTC)
Thanks for keeping this up to date! Such a fun device to play with.
rigred commented on 2018-12-28 18:48 (UTC)
That is correct
I've run run ldd over all the binaries & libraries to check and currently only
/usr/bin/LeapControlPanel
appears to have been linked against/usr/bin/libsqlite3.so.0
but also works with the included arch sqlite library.The upstream leap-motion uses a very windows-like packaging for the included Mono code.
I'm going to test with preloading the included libs to be sure.
robertfoster commented on 2018-12-28 18:22 (UTC) (edited on 2018-12-28 18:26 (UTC) by robertfoster)
@rigred https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Acccording to POSIX standard and to your observations, you should move not only the previously highlighted libs but also the Playground data folder (now under /usr/bin and that should be moved under /usr/share or /opt). So I humbly suggest to review and check the paths created by this package and use symlinks to static binaries. Maybe after you have to check if these binaries are executed correctly or if LD_LIBRARY_PRELOAD env variable is needed.
rigred commented on 2018-12-28 17:16 (UTC)
Ok wow - sorry Did not mean any offense by this. I just wanted an explanation.
I don't have an issue taking over the package.
robertfoster commented on 2018-12-28 17:09 (UTC)
@rigred Your attitude is not constructive. This is voluntary work and put a simple and critic "this is BAD" is not something that can help to advance in maintaining packages especially if the criticism come from someone that maintain one only package (rocm-smi) and have no past experiences on AUR. The explaination is based on the fact that the original debs distributed by Leap Motion have this folder structure and, until now, I don't realized that. So thanks for your observations on this kind of shitty proprietary software. I abandon it. Take care of it, if you want, and keep calm
rigred commented on 2018-12-28 16:25 (UTC)
Why does this package include
/usr/bin/libsqlite3.so
?This is just breaking plenty of other sqlite dependencies particularly when compiling things with cmake - as cmake finds sqlite in
/usr/bin/libsqlite3.so
instead of/usr/lib/libsqlite3.so
Can you please explain the reasoning for placing these here?
This is BAD
commented on 2017-05-20 09:30 (UTC)
Muflone commented on 2017-04-17 10:13 (UTC)
Muflone commented on 2017-04-09 22:51 (UTC)
Nagasaki45 commented on 2017-03-17 01:22 (UTC)
gafalcon commented on 2017-01-16 17:05 (UTC)
quigybo commented on 2016-04-27 22:02 (UTC)
ackalker commented on 2016-03-15 16:23 (UTC)
ackalker commented on 2016-02-05 15:51 (UTC) (edited on 2016-02-05 15:56 (UTC) by ackalker)
Nagasaki45 commented on 2016-01-15 10:51 (UTC)
Nautigsam commented on 2015-09-21 12:20 (UTC)
xuv commented on 2015-08-27 00:24 (UTC)
DevPump commented on 2015-08-09 03:17 (UTC)
bfg commented on 2015-08-08 14:28 (UTC)
marcs commented on 2015-08-07 10:04 (UTC)
0x414A commented on 2015-06-02 16:24 (UTC)
xiangzhai commented on 2015-04-30 03:20 (UTC)
xiangzhai commented on 2015-04-30 03:18 (UTC)
AnAkkk commented on 2015-02-11 14:02 (UTC)
nekoxmachina commented on 2015-01-08 21:22 (UTC)
ido commented on 2014-12-31 01:31 (UTC)
marcs commented on 2014-11-12 23:12 (UTC)
marcs commented on 2014-11-12 23:02 (UTC)
marcs commented on 2014-11-12 16:20 (UTC)
ido commented on 2014-07-05 22:24 (UTC)
libcg commented on 2014-06-15 00:53 (UTC)
libcg commented on 2014-06-15 00:51 (UTC)
rggjan commented on 2014-05-06 19:17 (UTC)
tasqa commented on 2014-04-23 15:31 (UTC)
robertfoster commented on 2014-01-17 22:43 (UTC)
retrakker commented on 2014-01-15 10:50 (UTC)
flokli commented on 2014-01-07 14:12 (UTC)
robertfoster commented on 2013-09-23 16:36 (UTC)
neXyon commented on 2013-09-17 21:26 (UTC)
robertfoster commented on 2013-07-31 14:36 (UTC)
commented on 2013-07-30 11:33 (UTC)