Package Details: netmap r3882.88ad54aa-3

Git Clone URL: https://aur.archlinux.org/netmap.git (read-only, click to copy)
Package Base: netmap
Description: A framework for high speed network packet I/O, using kernel bypass
Upstream URL: http://info.iet.unipi.it/~luigi/netmap
Licenses: BSD
Submitter: vmaffione
Maintainer: vmaffione
Last Packager: vmaffione
Votes: 7
Popularity: 0.000000
First Submitted: 2013-10-29 15:00 (UTC)
Last Updated: 2018-11-27 15:28 (UTC)

Dependencies (10)

Required by (0)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

vmaffione commented on 2017-05-30 14:20 (UTC)

Hi deyannis, I see the errors and warnings, thanks for the notification. I'll fix the bugs upstream asap, and report. Thanks, Vincenzo

deyannis commented on 2017-05-30 11:32 (UTC)

There are some compilation errors when building with GCC 7.1 Not this package's fault, but just reporting. This can be easily fixed for now, building with GCC <6

vmaffione commented on 2017-05-25 14:14 (UTC)

Updated PKGBUILD to replace "abs" with "asp"

vmaffione commented on 2017-04-07 08:06 (UTC)

I updated the dependencies, thanks!

dstaesse commented on 2017-04-07 05:07 (UTC)

Vincenzo, there is a missing dependency check for "patch"

vmaffione commented on 2016-12-16 10:16 (UTC)

Compilation issue solved for igb. Now all the netmap-provided drivers are available (e1000, e1000e, igb, ixgbe, i40e, veth, virtio_net, forcedeth).

vmaffione commented on 2016-12-14 12:42 (UTC)

Hi folks, I updated the netmap package to align with the new netmap build system, which makes the PKGBUILD a lot simpler. All the available patched drivers are currently installed (with a "_netmap" suffix to avoid ambiguity), except for igb, for which there is a compilation issue.

vmaffione commented on 2015-12-26 11:16 (UTC) (edited on 2015-12-26 11:17 (UTC) by vmaffione)

Thanks for the nice suggestions! However, taking inspiration from /usr/lib/yaourt/pkgbuild.sh, I think I managed to correctly override makepkg path variables, since I'm now able to build netmap with yaourt. Can you give a try? I also added a message regarding patched drivers to be shown at install time. Since I cannot replace the drivers installed by the linux package, one could bypass udev by blacklisting official driver modules and automatically loading patched drivers at boot time. However, I'm not sure this strategy should be included in the netmap package, since it would possibly conflict with other configuration files in /etc/modprobe.d and /etc/modules-load.d. That's why I think it's best to let the user carry out this configuration manually, to make sure he knows what she is doing. All things considered, this configuration should be done only once.

shallpion commented on 2015-12-26 02:05 (UTC)

Yes I can build it using the standard Arch makepkg way, and I think any future user who ran into this problem would easily figure out any possible workaround based on our discussion :) Or perhaps we can let PKGBUILD to spit out a warning if the users use yaourt. By the way, do you have any plan to possibly letting arch load patched NIC driver to replace the original one during bootup, so users don't have to do it by themselves? I noticed your PKGBUILD appended _netmap to the .ko modules but apparently they are not loaded by default and it would affect the function of netmap. Perhaps a little warning message about users having to load modules by themselves after the installation would be a lot helpful. Thanks :)

vmaffione commented on 2015-12-25 22:15 (UTC) (edited on 2015-12-25 22:17 (UTC) by vmaffione)

I've done some modification to the PKGBUILD, trying to force SRCDEST variable to the desired value. But I cannot make the thing work with yaourt even in this case. It keeps using SRCDEST=/tmp/yaourt-tmp-myname/aur-netmap/linux), as you pointed out. I would say that the easy way is not using yaourt in this case :) If I understand correctly you are able to build the netmap package with plain makepkg, which is the Arch way, aren't you? The only thing I can think of is an ugly workaround in build() where I try to detect this situation (sources stored in the different place) before running configure, and change the --kernel-sources argument consequently. But I'm not sure this is better than just require the user to build using makepkg directly - no yaourt.

« First ‹ Previous 1 2 3 4 5 Next › Last »