Arch Linux User Repository

@stuartiannaylor Can you share the output of "lspci -knn" ?

I have installed via makepkg and pacman Prob being dumb but even after a depmod -a its still using the cdc_ncm driver

Anyone help? :)

@pappi there are no packages like that in arch linux. I'm pretty sure you're referring to manjaro linux. Maybe add that info so people don't get confused. The AUR is used by several distros so it's not easy to always know what works where. On arch linux you need linux-headers which automatically comes as a dependency.

Hi,

just for information. Installed on Dell XPS with WD15 (ethernet) dock. Working but had to manually

sudo pacman -S linux420-headers

prior and then install r8152-dkms to get the updated driverversion=v2.11.0 (2018/12/21)

I'm on Kernel 4.20. Without it got an error on build: "...missing kernel headers..."

Newer Kernel 5.0 needs:

sudo pacman -S linux50-headers

Thanks for this work! you can check driverversion with:

sudo lshw -c network

@hv15 - thank you for your patch, it's integrated in the PKGBUILD now.

Edit2: i've come up with a patch for this, see the github issue...

Edit: created issue on github project.

Not building on 4.20... anyone else experiencing this?

make: Entering directory '/usr/lib/modules/4.20.0-pf1/build'
  CC [M]  /var/lib/dkms/r8152/2.10/build/src/r8152.o
/var/lib/dkms/r8152/2.10/build/src/r8152.c:7318:3: error: ‘const struct ethtool_ops’ has no member named ‘get_settings’; did you mean ‘get_strings’?
  .get_settings = rtl8152_get_settings,
   ^~~~~~~~~~~~
   get_strings
/var/lib/dkms/r8152/2.10/build/src/r8152.c:7318:18: error: initialization of ‘int (*)(struct net_device *)’ from incompatible pointer type ‘int (*)(struct net_device *, struct ethtool_cmd *)’ [-Werror=incompatible-pointer-types]
  .get_settings = rtl8152_get_settings,
                  ^~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/r8152/2.10/build/src/r8152.c:7318:18: note: (near initialization for ‘ops.get_regs_len’)
/var/lib/dkms/r8152/2.10/build/src/r8152.c:7319:3: error: ‘const struct ethtool_ops’ has no member named ‘set_settings’; did you mean ‘get_strings’?
  .set_settings = rtl8152_set_settings,
   ^~~~~~~~~~~~
   get_strings
/var/lib/dkms/r8152/2.10/build/src/r8152.c:7319:18: error: initialization of ‘void (*)(struct net_device *, struct ethtool_regs *, void *)’ from incompatible pointer type ‘int (*)(struct net_device *, struct ethtool_cmd *)’ [-Werror=incompatible-pointer-types]
  .set_settings = rtl8152_set_settings,
                  ^~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/r8152/2.10/build/src/r8152.c:7319:18: note: (near initialization for ‘ops.get_regs’)
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:298: /var/lib/dkms/r8152/2.10/build/src/r8152.o] Error 1
make: *** [Makefile:1563: _module_/var/lib/dkms/r8152/2.10/build/src] Error 2
make: Leaving directory '/usr/lib/modules/4.20.0-pf1/build'

Ok, thank you :)

I asked Bruno Pagain (ArchAnge) and indeed this is forbidden to upload to the git repo.

+1 for github. Done. I changed the package accordingly and have given to you write access to the repo as well. :)

It cannot be automated or it's too complicated, since it sends a download link by e-mail with a validity of 5 minutes (!?). Also, adding the source code to the PKGBUILD repository is against good packaging guidelines, if one day you apply to be a trusted user, it will be fingerpointed. ;)

I'm in favor of re-uploading the source code to a git repository on github and tag/sign the new release, or reupload the original tarball elsewhere...

@hcartiaux Thanks for having taken care of this issue. Yes. Ideally, we need to find a way to get the file properly by adding some additional parsing logic to the PKGBUILD. But I don't know if this is possible to have a PKGBUILD without a "source" array statement and getting the file manually from the prepare() function. Maybe indeed this isn't worth the effort this time and hosting the sources elsewhere is best for now. Do you know if this is possible to add the source code directly to this git repo (since this one is still quite small)?