Package Details: netatop-dkms 3.1-1

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: 11
Popularity: 0.058368
First Submitted: 2015-06-02 10:10
Last Updated: 2020-05-10 13:29

Latest Comments

1 2 3 4 Next › Last »

m1kc commented on 2020-05-10 13:36

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.

eggz commented on 2020-05-10 13:23

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

What would you do instead?

eggz commented on 2020-05-10 12:29

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

After rebuilding a few more times, I found the problem. netatop-dkms has a dependency on linux-headers, which it pulls in even if I am using the LTS kernel and results in the error.

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 requires linux-headers when you don't have the linux 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.

eggz commented on 2020-05-09 09:26

amen to that. good catch!

hexadecagram commented on 2020-05-09 04:02

I am performing full upgrades on 3 different systems, and obviously I jumbled them. Two machines strictly run the linux-lts kernel but the third (which I use for software testing) has both linux-lts and linux packages installed.

After rebuilding a few more times, I found the problem. netatop-dkms has a dependency on linux-headers, which it pulls in even if I am using the LTS kernel and results in the error. The linux-lts package uses the linux-lts-headers package, so DKMS finds those modules. But then it finds the linux-headers package but no linux package is installed, which results in the error.

The problem with installing the netatop package rather than netatop-dkms package that I was experiencing in the past was, if the kernel gets upgraded but netatop does not, then it doesn't get rebuilt for the new kernel. I would think that adding a hook in /etc/pacman.d/hooks is one way of addressing that.

eggz commented on 2020-05-08 06:38

yeah I can imagine so, the maintainers of the netatop pkgs dont really test their packages.. now, the error you showed was from the vanilla kernel, and the folder you showed was from the lts kernel? are the modules present from the vanilla as well?

hexadecagram commented on 2020-05-08 05:48

Oh I remember what it was, it wasn't ZFS. I seem to remember tripping over netatop when I would do kernel upgrades in the past. That's why I switched to the DKMS version.

hexadecagram commented on 2020-05-08 05:44

@eggz I know, it struck me as odd too.

% pacman -Qo /usr/lib/modules/5.4.38-1-lts/vmlinuz

/usr/lib/modules/5.4.38-1-lts/vmlinuz is owned by linux-lts 5.4.38-1

I did upgrade the kernel earlier this evening and rebooted. Even after rebooting, reinstalling all of the linux-* packages, and rebuilding, I get the same error.

I am using DKMS because I am currently using ZFS on this system, and had to upgrade to a new release of that package (for what reason escapes me at the moment), and can't, AFAIK, safely downgrade, so I figured why not just throw netatop in DKMS as well. I suppose I could switch to the non-DKMS version.