Search Criteria
Package Details: netatop-dkms 3.1-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/netatop-dkms.git (read-only, click to copy) |
---|---|
Package Base: | netatop-dkms |
Description: | Atop network kernel module, enables network statistics in atop |
Upstream URL: | http://www.atoptool.nl/ |
Keywords: | atop dkms kernel module netatop |
Licenses: | GPL |
Groups: | modules |
Conflicts: | netatop |
Submitter: | m1kc |
Maintainer: | m1kc |
Last Packager: | m1kc |
Votes: | 13 |
Popularity: | 0.000061 |
First Submitted: | 2015-06-02 10:10 (UTC) |
Last Updated: | 2020-12-24 08:31 (UTC) |
Dependencies (4)
- atop
- bash (bash-devel-static-gitAUR, bash-devel-gitAUR, busybox-coreutilsAUR, bash-gitAUR)
- dkms (dkms-gitAUR)
- zlib (zlib-ng-compat-gitAUR, zlib-gitAUR, zlib-ng-compat)
Latest Comments
« First ‹ Previous 1 2 3 4 5 Next › Last »
m1kc commented on 2020-12-24 08:33 (UTC)
Package updated.
It seems to me that netatop.service just loads the netatop module into kernel, and this is already provided by /etc/modules-load.d/netatop.conf. Still, I guess it's okay to follow the upstream on this one.
Glad to hear that. Is there anything else I can do to help the ARM users?
lekin commented on 2020-12-23 16:23 (UTC)
Remark: Can be compiled and runs fine on armv7h
m1kc commented on 2020-12-22 17:59 (UTC)
No. Will fix.
lekin commented on 2020-12-21 21:08 (UTC)
Is there a specific reason for netatop.service not being part of the package?
m1kc commented on 2020-05-10 13:36 (UTC)
3.1 is out, with support for 5.6 kernel and stuff.
As an experiment, hard dependency on linux-headers package has been removed. Instead, warnings at build & upgrade time are shown so you still know in advance what could go wrong. Let me know how these work for you.
<deleted-account> commented on 2020-05-10 13:23 (UTC)
That's the thing, I wouldn't specify the headers at all, it's supposed to be common knowledge when you are willing to install non-standard kernel modules. I'd leave an info post pinned in the comment section about it perhaps, but I won't mutilate the PKGBUILD for it.
But thats just my opinion!!
m1kc commented on 2020-05-10 12:38 (UTC)
What would you do instead?
<deleted-account> commented on 2020-05-10 12:29 (UTC)
I dont think that letting people know you need kernel headers for dkms module is a well suited job for a random package its pkgbuild. but thats just my opinion...
m1kc commented on 2020-05-10 12:25 (UTC)
That's one of the interesting problems I have to address. To build a DKMS module, you need headers for every kernel you want this module to work with. The problem is, PKGBUILD has no idea about that. Statically requiring linux-headers is an option that works for most people, and people who use non-standard kernels in addition to
linux
package usually install their headers as well, so this looks like, at least, a sane default. But yes, it's not perfect, and it's confusing that PKGBUILD requireslinux-headers
when you don't have thelinux
itself.Actually, it seems technically possible to detect installed kernels at build time and try to infer which header packages they need. So, if anyone's willing to try to pull that off, PRs are welcome, as usual.
P.S. I want to thank (again) all the people who submit patches. You're helping a lot.
<deleted-account> commented on 2020-05-09 09:26 (UTC)
amen to that. good catch!
« First ‹ Previous 1 2 3 4 5 Next › Last »