Package Details: python-dlib-cuda 19.22-1

Git Clone URL: https://aur.archlinux.org/python-dlib-cuda.git (read-only, click to copy)
Package Base: python-dlib-cuda
Description: Dlib is a general purpose cross-platform C++ library designed using contract programming and modern C++ techniques.
Upstream URL: http://www.dlib.net/
Keywords: dlib
Licenses: boost
Conflicts: python-dlib
Provides: python-dlib
Submitter: agradzki
Maintainer: AbysmalBiscuit
Last Packager: AbysmalBiscuit
Votes: 1
Popularity: 0.000000
First Submitted: 2017-11-17 14:12 (UTC)
Last Updated: 2021-03-30 08:41 (UTC)

Required by (5)

Sources (1)

Latest Comments

jaantoots commented on 2018-12-01 20:48 (UTC)

makedepends should include python{,2}-setuptools instead of just python{,2}.

Also, there is no need to list all three cuda, cudnn and libx11 as separate dependencies, as the other two are already dependencies of cudnn.

petronny commented on 2018-11-30 07:56 (UTC) (edited on 2018-11-30 07:57 (UTC) by petronny)

@AbysmalBiscuit

  1. Thanks for the tests on optional dependencies.

  2. ccache-ext is available in AUR now.

  3. You can set license=('Boost') to use /usr/share/licenses/common/Boost/license.txt in licenses.

  4. I see your changes about using the NEON instructions. But I think you misunderstand that this NEON is a kind of ARM instruction technology, not the neon package in [extra] which is a HTTP and WebDAV client library with a C interface.
    I think neon can be only enabled ARM architectures like armv7h or aarch64 and it's useless to python{,2}-dlib-cuda.

  5. I have updating the PKGBUILD of python-dlib to build python{,2}-dlib-cuda as well (currently disabled). So would you like to be a co-maintainer of python-dlib and merge these 2 packages to it?
    And I've disabled the detection of AVX, SSE2, SSE4 instructions and enabled all the optdepends because I'm providing binaries of python{,2}-dlib in my repositories with this PKGBUILD. If you don't agree with these, we can keep our packages separate.

AbysmalBiscuit commented on 2018-08-29 08:35 (UTC)

@Kicer Thanks! That's a good suggestion; I have added it.

Kicer commented on 2018-08-27 19:49 (UTC)

I think provides section should contain entry python-dlib=${pkgver} (version included). Otherwise pakages like python-face_recognition won't install due to insufficient version.

AbysmalBiscuit commented on 2018-07-21 09:17 (UTC)

@Kicer You are correct about gcc6 not being needed. In the past dlib and cuda programs did need gcc6 to compile properly, but it seems that is no longer the case.

@flipflop97 I have added the provides and conflicts.

@petronny I have gone through all the optional dependencies. Only sqlite and neon can be removed and python-dlib will still work. If any of the others are removed it will fail to import due to missing libraries of the shared object: dlib.cpython-36m-x86_64-linux-gnu.so. Note: removing sqlite will likely break parts of your system. :p

Kicer commented on 2018-07-19 20:19 (UTC)

Hi

Why is there gcc6 needed? I've modified PKBUILD to use system gcc and it works fine.

flipflop97 commented on 2018-07-04 19:50 (UTC) (edited on 2018-07-04 19:58 (UTC) by flipflop97)

Hi,

I have a package that depends on either python-dlib or python-dlib-cuda. I'd like to let it depend on either of them.

Right now both packages are totally separate. Can you maybe add a provides/conflicts/replaces rule for python-dlib so that both packages are treated as the same?

petronny commented on 2018-07-01 13:13 (UTC)

@AbysmalBiscuit Thanks for your answers and I'm clear to my first question.

My second question, or the other questions are:

  1. If I build and install python-dlib with sqlite, then remove sqlite with pacman -Rdd sqlite, will python-dlib run?
  2. If I build and install python-dlib with lapack, then remove lapack with pacman -Rdd lapack, will python-dlib run?
  3. If I build and install python-dlib with libpng, then remove libpng with pacman -Rdd libpng, will python-dlib run?

etc.

AbysmalBiscuit commented on 2018-06-28 08:15 (UTC)

@petronny Sorry for the delay in answering your questions.

  1. If you remove cuda or cudnn (since both are needed to compile and run dlib with cuda support) with pacman -Rdd cuda cudnn, python-dlib-cuda will not fallback to using only the cpu. In fact importing dlib will simply fail with an ImportError with not being able to open the shared object file(s) (either cuda or cudnn).

  2. I do not fully understand your question, I will assume that you are asking if it is possible to replace cuda with another dependency and still have be capable of using dlib in python. You cannot replace cuda with something else, or only with cudnn. You need both cuda and cudnn, hence why they are not only make dependencies, but also dependencies.

The dependency issue and the need to recompile if you would want to switch from having cuda support to using cpu only are likely the reason why python dlib was originally split into a cuda and non-cuda version.

If you have any other questions please don't hesitate to ask.

petronny commented on 2018-06-26 15:41 (UTC) (edited on 2018-06-26 15:41 (UTC) by petronny)

Hi I just took over python-dlib and I'm trying to merge this and python-dlib into one PKGBUILD.

So I have some questions:

  1. If I build and install python-dlib-cuda with cuda, then remove cuda with pacman -Rdd cuda, will python-dlib-cuda run and fallback to cpu?

  2. Replace cuda in 1 with cudnn or an optional dependency like cblas, will python-dlib-cuda run without it?

AbysmalBiscuit commented on 2018-04-30 12:43 (UTC) (edited on 2018-05-03 10:55 (UTC) by AbysmalBiscuit)

@p00h cuda presence is tested for by cmake (in dlib/CMakeLists.txt from line 593 you can see the cuda tests), hence there is no need to explicitly invoke it. Also even if it is explicitly invoked, and cudnn isn't installed the package will still build fine, but without gpu support. However, avx and sse are not tested for by cmake (as far as I could find), which is why they are tested for by the PKGBUILD.

You are absolutely correct about cudnn being a missing essential dependency, thanks for pointing it out!

p00h commented on 2018-04-18 11:56 (UTC)

Unfortunately, the provided PKGBUILD is invalid: 1) It lacks of essential cudnn package in dependencies 2) It does not contain the essential --yes DLIB_USE_CUDA param.

If you tried to make a package, it would be compiled but without the CUDA support. Feel free to check it out: cmake configuration process will claim that.

So there is the working (fixed) PKBUILD, it was tested with face_recognition package and 100% works. https://pastebin.com/c4eyhzEZ

AbysmalBiscuit commented on 2018-03-16 10:19 (UTC) (edited on 2018-03-16 11:04 (UTC) by AbysmalBiscuit)

agradzki,

I'll adopt the package and maintain it then. :)

agradzki commented on 2018-03-12 13:49 (UTC)

AbysmalBiscuit,

I have disowned this package as I do not have an Arch Linux system to test this on right now.

Thanks for posting the fixes!

AbysmalBiscuit commented on 2018-03-12 11:38 (UTC) (edited on 2018-03-12 11:41 (UTC) by AbysmalBiscuit)

Hey,

TLDR: Fixed and improved PKGBUILD updated to the latest version (19.9) is available here: https://pastebin.com/NufcQpRj

There are other issues besides those pointed out by Karmadon.

First, the environment variables that indicate the compiler that CUDA needs are not set before building the Python3 version, hence the Python3 package has no CUDA support.

Second, there is no need to specify the CUDA include and library directories as they get auto detected.

Third, no SSE optimizations are set, as compared with the 'dlib' package also available in the AUR.

Fourth, compiling times for Python3 can be improved somewhat via the use of multiple proceses (although this isn't that much of an issue).

I have fixed and improved the PKGBUILD file, which can be downloaded from the pastebin link in the TLDR.

Karmadon commented on 2018-01-20 16:26 (UTC)

Hello!

I have to change variable "md5" to "md5sums" and add _pkgname=dlib in order to be able to compile it.