Package Details: rtl8812au-dkms-git 5.13.6.r46.gcbe2fd6-1

Git Clone URL: https://aur.archlinux.org/rtl8812au-dkms-git.git (read-only, click to copy)
Package Base: rtl8812au-dkms-git
Description: rtl8812AU chipset driver with firmware v5.13.6
Upstream URL: https://github.com/morrownr/8812au-20210820
Licenses: GPL2
Conflicts: rtl8812au
Submitter: thelinuxguy
Maintainer: zebulon (zebulon)
Last Packager: zebulon
Votes: 76
Popularity: 0.115947
First Submitted: 2015-06-08 13:04 (UTC)
Last Updated: 2024-05-23 13:07 (UTC)

Dependencies (3)

Required by (0)

Sources (2)

Pinned Comments

zebulon commented on 2019-10-01 06:19 (UTC)

To all having an issue with this driver: please try https://aur.archlinux.org/packages/rtl88xxau-aircrack-dkms-git alternatively.

Latest Comments

« First ‹ Previous 1 .. 12 13 14 15 16 17 18 19 20 21 22 .. 32 Next › Last »

gordboy commented on 2017-12-28 11:18 (UTC)

@zebulon and @S4KB7mMgdW3XzeFA

I would be quite interested in that source too, and I await further developments.

Once that is cleared up, I will decide whether to patch the existing 5.2.9.3 for kernel 4.15, or whether to switch to the 5.2.20 and patch that.

gordboy commented on 2017-12-28 11:14 (UTC)

@And1G

The main Makefile uses 'bc' to determine if the kernel version you have is >= 4.9, so that another flag can be added to the CFLAGS in order to fix compile errors.

Obviously 'bc' is an install dependency, as you need it to install. Runtime means when the module is running, not when it is compiled. And let's face it, not many kernel modules depend on anything in userland except firmware, while running.

The use of 'bc' is very common practice in kernel modules, and quite apart from that, it is a good thing to have in your command line arsenal. And in this case it is an absolute requirement for installation.

And1G commented on 2017-12-26 00:13 (UTC) (edited on 2017-12-26 00:14 (UTC) by And1G)

After having a closer look at the log, it now builds after installing bc. But I do not understand how installing the tool can fix the compilation errors... But I think this behaviour makes bc a runtime dependency, not an install dependency.

And1G commented on 2017-12-25 23:48 (UTC)

Log uploaded to pastebin, as line breaks did not survive in the previous comment: https://pastebin.com/SGxCpXy8

And1G commented on 2017-12-25 23:45 (UTC)

Building rtl8812au-dkms-git-5.2.9.3.r50.g0acfa00-1 fails for me. The failure seems to be caused by warnings being treated as errors.

DKMS make.log for rtl8812au-5.2.9.3.r50.g0acfa00 for kernel 4.14.8-1-ARCH (x86_64) Tue Dec 26 00:41:28 CET 2017 /bin/sh: bc: command not found make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/4.14.8-1-ARCH/build M=/var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build modules make[1]: Entering directory '/usr/lib/modules/4.14.8-1-ARCH/build' /bin/sh: bc: command not found CC [M] /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_cmd.o CC [M] /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_security.o CC [M] /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_debug.o CC [M] /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_io.o /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_debug.c: In function 'dump_drv_version': /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_debug.c:50:62: error: macro "DATE" might prevent reproducible builds [-Werror=date-time] RTW_PRINT_SEL(sel, "build time: %s %s\n", DATE, TIME); ^ /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_debug.c:50:62: error: macro "TIME" might prevent reproducible builds [-Werror=date-time] CC [M] /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_ioctl_query.o cc1: some warnings being treated as errors make[2]: [scripts/Makefile.build:314: /var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build/core/rtw_debug.o] Error 1 make[2]: Waiting for unfinished jobs.... make[1]: [Makefile:1504: module/var/lib/dkms/rtl8812au/5.2.9.3.r50.g0acfa00/build] Error 2 make[1]: Leaving directory '/usr/lib/modules/4.14.8-1-ARCH/build' make: [Makefile:1799: modules] Error 2

<deleted-account> commented on 2017-12-22 00:19 (UTC)

@zebulon: Yes, please make a search using my email address on major key servers (pgp.mit.edu / keys.gnupg.net / etc.). I signed and encrypted my email, so you should be able to verify my signature once you get my PGP public key. (I am sorry that for some reasons, I prefer not to tell my key fingerprint here.)

zebulon commented on 2017-12-21 12:20 (UTC)

@S4KB7mMgdW3XzeFA: I have received your email and thank you very much. Can I reply using the same email address? Have you got a PGP key too?

zebulon commented on 2017-12-20 15:28 (UTC)

@S4KB7mMgdW3XzeFA: please use instead this key: 2048R/E253097C I just uploaded it to http://pool.sks-keyservers.net and it may require further time to appear on other public servers. A further note: I am happy to work on new driver versions, but - I am sure you will understand - I will need to assess authenticity/code to the best of my knowledge. I would prefer to source them from a Realtek FTP server at best, but am open to possibilities. I cannot guarantee I can achieve this before the new year but will try my best.

<deleted-account> commented on 2017-12-20 01:19 (UTC)

@zebulon May I know if your PGP key (and email address listed in AUR user info page) is (are) still valid? (pub 1024D/71BC7009 2005-05-19) If so, I can send you encrypted emails regarding the matter.

zebulon commented on 2017-12-19 09:44 (UTC)

@S4KB7mMgdW3XzeFA: thanks for the tip, but can you please let me know how/where to get it? The original FTP server from Realtek is not online anymore.