Package Details: howdy 2.6.1-2

Git Clone URL: https://aur.archlinux.org/howdy.git (read-only, click to copy)
Package Base: howdy
Description: Windows Hello for Linux
Upstream URL: https://github.com/boltgolt/howdy
Keywords: facial-recognition hello howdy ir pam-plugin windows-hello
Licenses: MIT
Submitter: kelleymcches
Maintainer: boltgolt (kageurufu, Raymo111, xuanruiqi, komex, myghi63)
Last Packager: komex
Votes: 40
Popularity: 0.011942
First Submitted: 2018-06-25 05:25 (UTC)
Last Updated: 2021-07-30 08:42 (UTC)

Pinned Comments

Raymo111 commented on 2024-07-12 05:45 (UTC) (edited on 2024-07-12 05:46 (UTC) by Raymo111)

For anyone getting "RuntimeError: Unsupported image type, must be 8bit gray or RGB image", downgrade python-numpy to 1.26.4-2 and all will be okay... for now. See https://github.com/boltgolt/howdy/issues/937 for further discussion.

Latest Comments

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 Next › Last »

jaysee commented on 2019-03-16 14:42 (UTC)

Failing to build both in and outside of a chroot.

==> Starting package()...
Collecting face_recognition
  Downloading https://files.pythonhosted.org/packages/3f/ed/ad9a28042f373d4633fc8b49109b623597d6f193d3bbbef7780a5ee8eef2/face_recognition-1.2.3-py2.py3-none-any.whl
Installing collected packages: face-recognition
  The scripts face_detection and face_recognition are installed in '/build/howdy/pkg/howdy/usr/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed face-recognition-1.2.3
The --yes options to dlib's setup.py don't do anything since all these options
are on by default.  So --yes has been removed.  Do not give it to setup.py.
==> ERROR: A failure occurred in package().
    Aborting...
==> ERROR: Build failed, check /home/build/aur-builder/chroot/590961/build/build
Error executing command: makechrootpkg -c -r /home/build/aur-builder/chroot/590961

Removing '--yes USE_AVX_INSTRUCTIONS' from dlib_clone lets the build finish.

vitorrossi commented on 2019-02-04 16:04 (UTC)

@joeknock instructions for 2.5.0 worked flawlessly. Please update PKGBUILD

joeknock commented on 2019-01-08 19:11 (UTC) (edited on 2019-01-08 19:12 (UTC) by joeknock)

@MrKMG

Edit the package build as follows

line 4: pkgver=2.5.0

change the howdy source to <https://github.com/boltgolt/howdy/archive/v2.5.0.tar.gz>

change the first sha256sum to "a42c278f05866a6a616e8f5dd8349e35769063a229c236e680e566c5a6580334"

change line 78 FROM: cd howdy-2.3.1

TO cd howdy-$pkgver

Please update the PKGBUILD

MrKMG commented on 2019-01-07 18:16 (UTC)

Anyone have a PKGBUILD for v2.5.0?

boltgolt commented on 2019-01-02 22:38 (UTC)

@andrej take a look at issue 70: https://github.com/boltgolt/howdy/issues/70

andrej commented on 2019-01-02 22:11 (UTC)

I'm getting the following API mismatch when trying to add a face. :-(

raceback (most recent call last):
  File "/usr/bin/howdy", line 90, in <module>
    import cli.add
  File "/usr/lib/security/howdy/cli/add.py", line 117, in <module>
    enc = face_recognition.face_encodings(frame)
  File "/usr/lib/python3.7/site-packages/face_recognition/api.py", line 210, in face_encodings
    return [np.array(face_encoder.compute_face_descriptor(face_image, raw_landmark_set, num_jitters)) for raw_landmark_set in raw_landmarks]
  File "/usr/lib/python3.7/site-packages/face_recognition/api.py", line 210, in <listcomp>
    return [np.array(face_encoder.compute_face_descriptor(face_image, raw_landmark_set, num_jitters)) for raw_landmark_set in raw_landmarks]
TypeError: compute_face_descriptor(): incompatible function arguments. The following argument types are supported:
    1. (self: dlib.face_recognition_model_v1, img: numpy.ndarray[(rows,cols,3),uint8], face: dlib.full_object_detection, num_jitters: int=0, padding: float=0.25) -> dlib.vector
    2. (self: dlib.face_recognition_model_v1, img: numpy.ndarray[(rows,cols,3),uint8], faces: dlib.full_object_detections, num_jitters: int=0, padding: float=0.25) -> dlib.vectors
    3. (self: dlib.face_recognition_model_v1, batch_img: List[numpy.ndarray[(rows,cols,3),uint8]], batch_faces: List[dlib.full_object_detections], num_jitters: int=0, padding: float=0.25) -> dlib.vectorss

Invoked with: <dlib.face_recognition_model_v1 object at 0x7f55613a1ae8>, array([[27, 28, 26, ..., 28, 28, 27],
       [25, 27, 26, ..., 27, 28, 27],
       [26, 28, 26, ..., 27, 27, 27],
       ...,
       [31, 30, 32, ..., 29, 29, 30],
       [31, 32, 32, ..., 29, 29, 29],
       [32, 30, 32, ..., 30, 29, 29]], dtype=uint8), <dlib.full_object_detection object at 0x7f55610a3068>, 1

donpicoro commented on 2018-12-02 17:26 (UTC)

Interesting... I did try removing those 3 lines

diff --git a/PKGBUILD b/PKGBUILD
index 1835294..e466245 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -46,10 +46,10 @@ prepare() {
        patch -p1 < ../pam-python-1.0.6-fedora.patch
        patch -p1 < ../pam-python-1.0.6-gcc8.patch

-       # Doing some fixes for pam-python so that it can compile
-       sudo pkgfile -u
-       sudo pkgfile /usr/include/sys/cdefs.h core/glibc
-       cd ..
+       ## Doing some fixes for pam-python so that it can compile
+       #sudo pkgfile -u
+       #sudo pkgfile /usr/include/sys/cdefs.h core/glibc
+       #cd ..
 }
 build() {
        # Building pam-python

and it compiles without a hitch. Care to try it?

kelleymcches commented on 2018-11-25 06:33 (UTC)

I had to use pkgfile to make the build succeed. This is my first PKGBUILD and if you know of a way to do it without sudo or just not do it, please let me know. The build WILL fail though if you remove that line, you can try it and see

donpicoro commented on 2018-11-21 10:36 (UTC)

Hi, I am confused.... What's the intention behind the line: [sudo] pkgfile /usr/include/sys/cdefs.h core/glibc?

1) I have a tight user to compile AUR package and it is not a sudoers one. is sudo really needed? I understand pkgfile -u but not this second line.

2) I really do not know what does the second part (core/glibc) do? The output is nothing!

3) Would it matter if I just remove that line? What is it's purpose? if the idea is to verify the presence of the /usr/include/sys/cdefs.h file... isn't it enough to demand glibc as a dependence? Isn't this one of those dependencies that are assumed to exist as it belongs to the base group?

JoaoMachado commented on 2018-11-21 03:53 (UTC)

command: pakku -Sy howdy