Package Details: rdma-core 41.0-1

Git Clone URL: (read-only, click to copy)
Package Base: rdma-core
Description: RDMA core userspace libraries and daemons
Upstream URL:
Keywords: infiniband rdma
Licenses: GPL2, BSD (MIT variant)
Conflicts: ibacm, infiniband-diags, libcxgb3, libcxgb4, libibcm, libibmad, libibumad, libibverbs, libiwpm, libmlx4, libmlx5, libmthca, libnes, libocrdma, librdmacm, rdma, srptools
Provides: ibacm, infiniband-diags, libcxgb3, libcxgb4, libibcm, libibmad, libibumad, libibverbs, libiwpm, libmlx4, libmlx5, libmthca, libnes, libocrdma, librdmacm, rdma, srptools
Replaces: ibacm, infiniband-diags, libcxgb3, libcxgb4, libibcm, libibmad, libibumad, libibverbs, libiwpm, libmlx4, libmlx5, libmthca, libnes, libocrdma, librdmacm, rdma, srptools
Submitter: nfnty
Maintainer: wuxb
Last Packager: wuxb
Votes: 50
Popularity: 0.000445
First Submitted: 2017-03-09 16:32 (UTC)
Last Updated: 2022-07-28 18:31 (UTC)

Latest Comments

rawhide commented on 2022-01-23 23:31 (UTC) (edited on 2022-01-23 23:33 (UTC) by rawhide)

The wiki is outdated, yes. Relevant services are autostarted if the correct hardware is present. As well, as far as I can tell, /etc/rdma/rdma.conf is no longer used. Instead, it looks at the config files in /etc/rdma/modules/ to decide what modules to load, which is most of them, by default. So your devices should just show up after a reboot, in general, without any further configuration.

iusrlinearb commented on 2021-09-02 09:04 (UTC) implies that rdma-core provides an rdma.service which should be enabled/started, but the package doesn't appear to contain one. Is this incorrect?

UweSauter commented on 2021-02-08 15:29 (UTC) (edited on 2021-02-08 15:31 (UTC) by UweSauter)

In order to build current version 33.1 the PKGBUILD needs to be edited.

  • change pkgver to 33.1
  • remove the following lines:

    install -D --mode=0755 rdma.kernel-init "${pkgdir}/usr/lib/rdma/rdma-init-kernel"

    install -D --mode=0644 rdma.service "${pkgdir}/usr/lib/systemd/system/rdma.service"

    install -D --mode=0755 rdma.sriov-init "${pkgdir}/usr/lib/rdma/rdma-set-sriov-vf"

    install -D --mode=0644 rdma.sriov-vfs "${pkgdir}/etc/rdma/sriov-vfs"

    install -D --mode=0644 rdma.udev-rules "${pkgdir}/usr/lib/udev/rules.d/98-rdma.rules"

After installing the update you might want to consider removing /etc/rdma/sriov-vfs.

jamespharvey20 commented on 2019-08-07 19:59 (UTC)

Upstream merged infiniband-diags into rdma-core, so when upgrading this, if you had infiniband-diags installed, it's OK to allow pacman to uninstall infiniband-diags, and you'll still have it.

wuxb commented on 2018-12-08 21:53 (UTC)

@jamespharvey20, thanks for the detailed explanation. I agree that a separate package like "-nopandoc" would make more sense than removing it from this package.

jamespharvey20 commented on 2018-11-09 22:18 (UTC)

@wuxb, it looks to me like the upstream package may handle building without pandoc, but unfortunately, there's not a way to do that. pandoc is in 'makedepends' rather than 'depends'. Dependencies can only be moved from depends to 'optdepends'. In that case, the dependency would not be necessary to build the package, and the package once installed would work regardless of if the 'optdepends' was installed, granted with different functionality. There's no counterpart to 'makedepends'. While building a package, since many users build them in a chroot, there would need to be a mechanism to ask the user if they'd like to install each hypothetical 'optmakedepends', regardless of if it's the first install or a new version. That hasn't been desired or implemented. The only way to go would be to create and maintain a new package, something like 'rdma-core-nopandoc', which completely removed it from 'makedepends'. I can't speak for nfnty, but IMO, it's not worth doing. This wouldn't help with build time or bandwidth usage, but if your desire is to keep pandoc and all of its haskell dependencies out of your main system, look into pkg devtools, specifically 'makechrootpkg' and 'extra-x86_64-build'. Not that this definitely matters, but the other distros I looked at also require pandoc as a make dependency. If you build AUR packages using a method that lets you edit a PKGBUILD first, you could try simply deleting 'pandoc' from 'makedepends' on your side. From a brief look at upstream's CMakeLists.txt, I think it would succeed, just without the man pages.

wuxb commented on 2018-11-09 16:59 (UTC)

The pandoc dependency is pretty huge. How about making it optional?

Jonhoo commented on 2018-08-29 15:38 (UTC)

@nfnty no worries, thanks for the quick update!

nfnty commented on 2018-08-29 15:19 (UTC)

@Jonhoo Fixed, sorry about that. Missed that the latest tag was signed.

Jonhoo commented on 2018-08-29 15:01 (UTC)

Any particular reason why the gpg validation was removed? You don't need the whole validate_tag function, you can just add ?signed to the git source url; see "query" under

nfnty commented on 2018-04-26 06:39 (UTC)

@FFY00 See previous comments.

FFY00 commented on 2018-04-25 21:32 (UTC)

Can't validate tag??

nfnty commented on 2018-02-03 11:47 (UTC)


ricefan123 commented on 2018-02-03 06:45 (UTC)

@nfnty Can you specified how to do so?

nfnty commented on 2018-01-22 08:54 (UTC)

@wuxb Stop using non-compliant software. The check is there for validating the source. You need to import the GPG key specified in validpgpkeys.

wuxb commented on 2018-01-22 04:28 (UTC) (edited on 2018-01-22 04:28 (UTC) by wuxb)

@nfnty Just found pacaur is unmaintained since last month. It's a dead end there. Is it a acceptable workaround if the check is moved after the substitions? It should not cause any trouble in my opinion. Thanks.

wuxb commented on 2018-01-22 04:21 (UTC) (edited on 2018-01-22 04:22 (UTC) by wuxb)

@nfnty I tried to run the find--sed command in the repo it works. I was using pacaur to install it. When I try to makepkg myself it shows an error message. Maybe with pacaur the compilation can still continue if prepare returns? I did get a package with pacaur with the wrong path in rdma.service. Anyway for now it goes through if I remove that validation.

$ makepkg ==> Making package: rdma-core 16.1-1 (Sun Jan 21 22:14:10 CST 2018) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Cloning rdma-core git repo... Cloning into bare repository '/home/wuxb/tmp/1/rdma-core'... remote: Counting objects: 23090, done. remote: Compressing objects: 100% (154/154), done. remote: Total 23090 (delta 143), reused 158 (delta 112), pack-reused 22824 Receiving objects: 100% (23090/23090), 6.71 MiB | 13.36 MiB/s, done. Resolving deltas: 100% (16545/16545), done. ==> Validating source files with sha512sums... rdma-core ... Skipped ==> Extracting sources... -> Creating working copy of rdma-core git repo... Cloning into 'rdma-core'... done. Switched to a new branch 'makepkg' ==> Starting prepare()... ==> ERROR: failed to validate tag v16.1

==> ERROR: A failure occurred in prepare(). Aborting...

nfnty commented on 2018-01-21 10:53 (UTC)

@wuxb Can't reproduce. rdma.service has the right path since it's explicitly being modified in prepare().

wuxb commented on 2018-01-21 04:19 (UTC)

rdma.service fails to start due to a wrong path in /usr/lib/systemd/system/rdma.service




nfnty commented on 2017-03-16 21:54 (UTC)

This package and multiple other rdma/infiniband libraries and daemons have been merged into `rdma-core` that tracks the new upstream repo.

nfnty commented on 2017-03-10 05:36 (UTC)

Issues and pull requests at

rbellamy commented on 2016-04-08 18:44 (UTC)

PKGBUILD needs parens removed from "url": ==> ERROR: url should not be an array

ashaman-crypto commented on 2016-02-20 19:30 (UTC)

==> ERROR: url should not be an array Removing the parenthesis around the url corrects the error.

jmsq commented on 2015-03-12 01:15 (UTC)

Updated and fixed.

dougvj commented on 2015-03-04 06:30 (UTC)

I am getting "/lib" exists in filesystem when trying to install. Any idea why?

twinshadow commented on 2014-04-16 05:09 (UTC)

I've gone and updated every package I maintain to use https.

twinshadow commented on 2014-04-16 05:09 (UTC)

I've gone and updated every package I maintain to use https.

twinshadow commented on 2014-04-16 05:02 (UTC)

I've gone and updated every package I maintain to use https. Not easy, and I wish I had a CI to catch this sooner.

Charlular commented on 2014-04-15 20:12 (UTC)

@pivotraze it appears that all packages sourcing from need to use https rather than http.

Charlular commented on 2014-04-15 20:10 (UTC)

No, 1.1.7 does exist, the problem is that the server hosting the file gives an HTTP 400 bad request error when trying to access the file without SSL. Simply changing the "http" to "https" for the location of the file inside the PKGBUILD fixes the problem.

pivotraze commented on 2014-04-15 16:16 (UTC)

Doesn't build. URL = 400 Bad Request Correct url is I'm not sure why yours doesn't work, it looks like the exact same thing, just on yours it fails to download. md5sum an sha512sum is the same.

pivotraze commented on 2014-04-15 16:13 (UTC)

md5sum for 1.1.4: c90739bd0178bb568aad3b2ba03bb73a sha512sum for 1.1.4: e92fdd1f20058e3cfa821e17b96a00c27eeb5b198774ef0af7d19ecb227979572b42c0271467d1192b504f9680534373d994143a5b9ac415a05684903c67d2ca

pivotraze commented on 2014-04-15 16:09 (UTC)

Won't build. File URL is incorrect. 1.1.7 doesn't seem to exist, but the correct source URL is

commented on 2010-12-07 10:11 (UTC)


commented on 2010-12-06 17:29 (UTC)

I am a robot. This is not an official message. You have accidentally tarred up some dotfiles. Examples: .PKGINFO Suggestion: use "makepkg --source". Feel free to disregard this as you would any other comment. This robot will not post here again.