Arch Linux User Repository

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

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?

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

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?

command: pakku -Sy howdy

FIXED, I was using Pamac GUI to install the the Howdy package, so I tried pakku from the CLI and that worked. I did not try to use pamac from the CLI... FYI

Trying to build in Manjaro I get the following;

==> Starting prepare()... Cloning into 'dlib_clone'... patching file src/pam_python.c Hunk #1 succeeded at 39 (offset 7 lines). Hunk #2 succeeded at 1526 (offset 29 lines). patching file src/pam_python.c Hunk #1 succeeded at 2227 (offset 53 lines). patching file src/Makefile Hunk #1 succeeded at 1 with fuzz 1. sudo: no tty present and no askpass program specified ==> ERROR: A failure occurred in prepare(). Aborting...

This is a leftover from the debian build, where some distros like ubuntu 16.04 have broken python-dlib packages and which cause the installation to fail. I don't have an arch instance to test the installation, so feel free to propose changes.

Is there a reason why you are silently installing dlib inside this PKGBUILD instead of using either dlib or python-dlib-cuda from the AUR as depends? That would IMHO be 'cleaner' and avoid issues with improper config flags for dlib, as those packages handle them on the fly based on cpu flags, instead of using defaults as you do here.

As a temporary fix until I have the chance to fix it, you can remove the pip installation of click and pillow in the PKGBUILD. You can also uninstall those packages and reinstall them with the PKGBUILD as Howdy needs the versions listed in the PKGBUILD.

Edit: It shouldn't be an issue anymore with the newest PKGBUILD