Package Details: mlpack 4.6.2-1

Git Clone URL: https://aur.archlinux.org/mlpack.git (read-only, click to copy)
Package Base: mlpack
Description: A fast, flexible, scalable C++ machine learning library
Upstream URL: https://mlpack.org
Keywords: c++ go julia learning machine python R
Licenses: BSD-3-Clause
Submitter: jerry73204
Maintainer: carlosal1015
Last Packager: carlosal1015
Votes: 13
Popularity: 0.024357
First Submitted: 2015-10-29 03:40 (UTC)
Last Updated: 2025-05-27 12:38 (UTC)

Dependencies (18)

Required by (0)

Sources (1)

Latest Comments

1 2 3 Next › Last »

micwoj92 commented on 2025-09-15 00:18 (UTC)

Please drop unneeded python-pytest-runner makedep.

BonnyAD9 commented on 2025-07-01 07:47 (UTC)

Hi, I have problem updating the package. If this is not the correct place to report this issue, feel free to redirect me elswhere. Here is the log that I think is relevant (I can provide more if needed):

/* other previous parts installing successfully */
-- Installing: /home/kubas/.cache/yay/mlpack/pkg/mlpack/usr/include/mlpack/methods/kernel_pca/kernel_rules
-- Installing: /home/kubas/.cache/yay/mlpack/pkg/mlpack/usr/include/mlpack/methods/kernel_pca/kernel_rules/naive_method.hpp
-- Installing: /home/kubas/.cache/yay/mlpack/pkg/mlpack/usr/include/mlpack/methods/kernel_pca/kernel_rules/nystroem_method.hpp
Looking in links: ./
Processing /home/kubas/.cache/yay/mlpack/src/build/src/mlpack/bindings/python
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'
Building wheels for collected packages: mlpack
  DEPRECATION: Building 'mlpack' using the legacy setup.py bdist_wheel mechanism, which will be removed in a future version. pip 25.3 will enforce this behaviour change. A possible replacement is to use the standardized build interface by setting the `--use-pep517` option, (possibly combined with `--no-build-isolation`), or adding a `pyproject.toml` file to the source tree of 'mlpack'. Discussion can be found at https://github.com/pypa/pip/issues/6334
  Building wheel for mlpack (setup.py): started
  Building wheel for mlpack (setup.py): finished with status 'done'
  Created wheel for mlpack: filename=mlpack-4.6.2-cp313-cp313-linux_x86_64.whl size=16415036 sha256=c654cde7270d8188ff43a4c86fded419f9278698d14b46aef7301badce893321
  Stored in directory: /tmp/pip-ephem-wheel-cache-h8f5haud/wheels/f2/26/52/9be731a24244886a4fef678a5e83cbac37926475c15ca3413a
Successfully built mlpack
Installing collected packages: mlpack
  Attempting uninstall: mlpack
    Found existing installation: mlpack 4.6.0
    Uninstalling mlpack-4.6.0:
ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied: '/usr/lib/python3.13/site-packages/mlpack-4.6.0.dist-info/'
Consider using the `--user` option or check the permissions.

CMake Error at /home/kubas/.cache/yay/mlpack/src/mlpack-4.6.2/src/mlpack/bindings/python/PythonInstall.cmake:26 (message):
  Error installing Python bindings!
Call Stack (most recent call first):
  src/mlpack/bindings/python/cmake_install.cmake:66 (include)
  src/mlpack/bindings/cmake_install.cmake:50 (include)
  src/mlpack/cmake_install.cmake:72 (include)
  cmake_install.cmake:55 (include)


gmake: *** [Makefile:110: install] Error 1
==> ERROR: A failure occurred in package().
    Aborting...
 -> error making: mlpack-exit status 4

My current mlpack package version is 4.6.0-1 and I'm updating to the currently latest 4.6.2-1.

It seems that the package fails installing the python bindings because it doesn't have permissions. It tries to install them directly into the system. Maybe they should be installed in the provided fakeroot instead? (idk, this is just guess). Or maybe they should be installed only for the current user (without requiring the permissions).

Samega7Cattac commented on 2022-04-27 11:56 (UTC)

This pakage requires python-pip on a python script

robertohueso commented on 2021-10-12 11:46 (UTC)

Updated :)

GRAPHENE commented on 2021-10-06 06:17 (UTC)

Updates?

Lone_Wolf commented on 2019-10-19 18:10 (UTC)

https://bbs.archlinux.org/viewtopic.php?id=250062

masca commented on 2019-10-03 09:20 (UTC)

It now compiles with GCC9, but it still fails to install.

I somehow obtain the following:

file in conflitto:
mlpack: /usr/bin/cygdb esiste già nel filesystem
mlpack: /usr/bin/cython esiste già nel filesystem
mlpack: /usr/bin/cythonize esiste già nel filesystem
mlpack: /usr/bin/f2py esiste già nel filesystem
mlpack: /usr/bin/f2py3 esiste già nel filesystem
mlpack: /usr/bin/f2py3.7 esiste già nel filesystem

nicolino commented on 2019-07-16 17:47 (UTC) (edited on 2019-07-16 17:47 (UTC) by nicolino)

I have had the same problems as Relyak. I have modified the PKGBUILD as indicated. The lib64 conflict was resolved. The others did not.

Reylak commented on 2019-06-14 10:46 (UTC) (edited on 2019-06-17 15:32 (UTC) by Reylak)

I second masca's comment and its conflict errors. Mine are:

mlpack: /usr/bin/cygdb exists in filesystem (owned by cython)
mlpack: /usr/bin/cython exists in filesystem (owned by cython)
mlpack: /usr/bin/cythonize exists in filesystem (owned by cython)
mlpack: /usr/bin/f2py exists in filesystem (owned by python-numpy)
mlpack: /usr/bin/f2py3 exists in filesystem (owned by python-numpy)
mlpack: /usr/bin/f2py3.7 exists in filesystem (owned by python-numpy)
mlpack: /usr/lib64 exists in filesystem (owned by filesystem)

(same as masca's but without the "easy-install.pth" one; I see in the PKGBUILD that "easy-install.pth" is deleted in the package() function)

For the lib64 conflict, it seems that CMake does not properly handle the UsrMerge of ArchLinux with your PKGBUILD. Passing -D CMAKE_INSTALL_LIBDIR="lib" to cmake fixes the issue as suggested here. This is what is used by this package for example. That does not solve the other conflicts though.

EDIT: the other conflicts actually ended up disappearing but I'm not sure why, sorry :(

1 2 3 Next › Last »