Package Details: dvb-usb-rtl2832u-openpli 20130918-6

Git Clone URL: (read-only)
Package Base: dvb-usb-rtl2832u-openpli
Description: Linux module for the RTL2832U DVB-T USB2.0 device
Upstream URL:
Licenses: GPL
Provides: dvb-usb-rtl2832u
Submitter: R00KIE
Maintainer: R00KIE
Last Packager: R00KIE
Votes: 18
Popularity: 0.000731
First Submitted: 2012-04-02 18:06
Last Updated: 2017-07-23 11:59

Latest Comments

R00KIE commented on 2016-06-22 12:41

Thanks for the patch :)

Sooner or later some change in the kernel is going to break this driver beyond what just a few small patches here and there can workaround/fix, therefore I strongly encourage the users of this driver to try using the driver that comes with the kernel, and if it doesn't work to submit bugs upstream.

Even if this driver can be continuously fixed with small patches and mostly keep working it is inevitable that some functionality will break. I'm just packaging this driver, when that breakage comes I don't have the necessary knowledge and skills to fix it.

takieszti91 commented on 2016-06-21 20:20

I couldn't build it with 4.6 kernel headers. That's why I created a patch file. You can find it at

R00KIE commented on 2016-05-17 20:32

I did a quick test with my usb dvb receiver and it seemed to be detected properly in a RPI 1B using the driver that comes with the kernel (no extra packages needed), at least I could get the frontend info just fine but I didn't test actually tuning as my rpi is a headless system.

That said, you most probably want to ask for help in the Arch Linux ARM forums[1]. Do note that Arch Linux ARM (for arm cpus) is not the same as Arch Linux (for i686 and x86_64 cpus) and have separate websites and forums.


Kresimir commented on 2016-05-11 15:32

(apologies if at the end it turns out I made some trivial mistakes, I'm quite new with this DVB stuff)

On my system there are no drivers which came with the kernel.
I followed WIKI page but modprobe fails.
Also worth mentioning is that my output of dmesg is notably shorter than the one in the WIKI.

I have also installed package "rtl-sdr".
The first "rtl_test" command described on didn't complain about missing the device or something else, so I assume the device itself is functional.
I have removed (commented) all blacklist entries related to dvb drivers which came with the rtl-sdr package.

Any hint or recommendation where to read/learn/...?

R00KIE commented on 2016-05-11 14:26

The problem is that ALARM is not Arch, their extramodules directory has a different name. You will have to adjust the PKGBUILD to take that into account. Also expect that other things might break.

That said, you should see if your receiver works with the driver that comes with the kernel. I haven't tried on a raspberry but at least on x86-64 it works just fine.

Kresimir commented on 2016-05-11 14:10

Build is failing on 4.4.9-1-ARCH (Raspberry Pi3, armv7h) at a very early stage.

[kreso@RPi3 dvb-usb-rtl2832u-openpli]$ makepkg -sr
cat: /usr/lib/modules/extramodules-4.4-ARCH/version: No such file or directory
==> Making package: dvb-usb-rtl2832u-openpli 20130918-4 (Wed May 11 14:08:42 UTC 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Downloading dvb-usb-rtl2832u.patch...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 187 100 187 0 0 278 0 --:--:-- --:--:-- --:--:-- 278
100 2924k 100 2924k 0 0 1422k 0 0:00:02 0:00:02 --:--:-- 8997k
-> Found Makefile
-> Found dvb-usb-rtl28xxu.conf
-> Found linux42.patch
==> Validating source files with md5sums...
dvb-usb-rtl2832u.patch ... Passed
Makefile ... Passed
dvb-usb-rtl28xxu.conf ... Passed
linux42.patch ... Passed
==> Extracting sources...
==> Starting build()...
patching file rtl2832u_fe.c
patching file rtl2832u.h
make -C /usr/lib/modules//build SUBDIRS=/home/kreso/AUR/dvb-usb-rtl2832u-openpli/src/build_dir modules
make[1]: *** /usr/lib/modules//build: No such file or directory. Stop.
Makefile:30: recipe for target 'default' failed
make: *** [default] Error 2
==> ERROR: A failure occurred in build().

Please be so kind to recommend how to deal with this issue.

donny commented on 2015-09-29 15:27

Thanks for the workaround, I would never manage it by myself. So DVB-T works again in Kaffeine. I didn't run scan.

R00KIE commented on 2015-09-29 14:40

I have submitted a "fix".

This is a quick and very dirty workaround, it builds and it works (only tried with VLC) but it _will_ break scanning with w_scan and any other programs that support scan for channels the same way as w_scan does. It might also break programs that rely on getting the frontend status for some of their functionality.

Signal level, SNR and BER still seem to be reported but I can't confirm if the values are correct.

R00KIE commented on 2015-09-29 13:46

I can confirm that it doesn't build on linux 4.2.

The warning about USB_PID_WINFAST_DTV2000DS_PLUS being redefined would be easy to fix, but the error about fe_status_t being unknown might not be as trivial and I don't know if I can fix it myself.

To make matters worse it seems the driver that comes with the kernel is not working properly since linux 4.0 although the dev responsible for maintaining the driver can't reproduce the problems[1].


donny commented on 2015-09-29 12:48

Cannot build on 4.2.1-1-ARCH. Can anybody confirm?

drathir commented on 2014-09-08 06:25

Yes looks like location problem solved, thanks for fast response R00KIE...

trzalica commented on 2014-09-07 20:57

I'm using kernel 3.10 and I couldn't start mine DVB-t card without this driver (device wasn't recognized)... All problems with patch location were solved now? And one more question: if any of you guys managed to configure remote control with this driver (I don't even know if that is covered in this driver?

trzalica commented on 2014-09-07 20:54

I'm using kernel 3.10 and I couldn't start mine DVB-t card without this driver (device wasn't recognized)... Is this new version of package with it's patch (did you find that patch you're usually using in this package)? And one more question: if any of you guys managed to configure remote control with this driver (I don't even know if that is covered in this driver?

drathir commented on 2014-09-07 13:41

btw at kernel drivers sadly not all dvb are corectly discovered...

drathir commented on 2014-09-07 13:39

For temporaly usage:

R00KIE commented on 2014-09-02 08:19

I too was looking in the repos at sourceforge and I couldn't find the patch I'm using here, I could find an older one though.

What I suggest you do is try without this driver, if you are using either linux or linux-lts from the official repos there is support for the rtl2832, like Gringo says.

I'll ask on the openpli forums what happened to the patch.

Gringo commented on 2014-09-02 08:10

Perhaps the patch has been included in the openpli software now? I cannot find the path anywhere in their repository. It seems a lot has changed. You could try to install without the patch and see if that works. Unfortunately I don't have the time to thoroughly check this myself at the moment.

@monyo: note that this driver is not required in most cases. The Linux kernel includes a 'bare bone' version of the driver since version 3.7.4, i.e. without support for the remote control and such.

monyo commented on 2014-09-02 05:14

I got 404 error when downloading the patch. Could you fix the link? Thanks in advance!

R00KIE commented on 2014-05-18 20:03

Thanks for bringing this to my attention. Package update.

Lenny commented on 2014-05-18 18:25

Upstream changed url for rtl2832 patch.
New git raw url:

R00KIE commented on 2014-02-23 16:02

You may not need to recompile the driver on every minor kernel release but you never know when and how it's going to break if you don't ;)

As for the remote, I'm not using it. When I bouth my receiver I took the time to make the remote control work but never published the patch, I think a different patch may be needed for every different remote so it's not really worth the trouble.

The guys at openpli don't bother with it either, I believe they use dedicated IR receivers and configure lirc to use that instead of the one on the dvb receiver.

trzalica commented on 2014-02-23 15:19

Thanks for reply to @R00KIE & @Gringo!
I don't need to recompile this driver and reinstall it after each small kernel update but sometimes it brakes but that isn't big deal. It important that now everything works! :) I don't use driver in kernel because it simply doesn't recongnize my device (I look through terminal and it doesn't show DVB-t device).
Just one more small question: you're using remote controler you get with your DVB-t card or?

Once again thanks for answers!

Gringo commented on 2014-02-23 15:14

@trzalica: lol, I see that Kaffeine is a media player, while Caffeine is a screensaver blocker. Confusing!!

R00KIE commented on 2014-02-23 14:50

Using this package means __recompiling__ and __reinstalling__ the package on every kernel update as even minor updates can break the driver.

R00KIE commented on 2014-02-23 13:57

Like Gringo says I only package the driver, if the problem was a missing vid:pid I suppose I could manage to add it (assuming that all the harware in the receiver was supported), however my programing skills and knowledge about the driver and usb/dvb subsystem would not allow me to do more.

Even upstream, which in this case is the openpli community, probably can't do more than they already have, which is "fix" the driver provided by realtek and make it compile cleanly with modern kernels.

What is included in the kernel is a different driver, written from scratch, and not this or any of the other drivers floating around, I beleive the reason for doing this was license concerns.

That said (and I've posted this view before), from my experience, I'd say that for normal everyday use the driver included with the kernel works better if it supports your hardware.

This driver is most useful if and when you need to position an antenna, because it will report sane snr and signal strength values (and tools like femon will properly report when the receiver has a lock on the signal).

Gringo commented on 2014-02-23 13:56

@trzalica: I use 3.12.13, but the driver is included since 3.7.4. Remember that you might have to recompile the driver on a kernel update in case you do want this package, e.g. when you want to use the remote. That means re-installing the package!

If you use the in-kernel module you don't have to do anything, since the package is pre-compiled (unless you build the kernel from source of course), which is very convenient.

I don't see what Kaffeine has to do with this. It's a just a very bulky program that accomplishes the simple task of disabling the screensaver. I don't see the need for a screensaver, let alone a screensaver blocker.

Gringo commented on 2014-02-23 13:54

@trzalica: I use 3.12.13, but the driver is included since 3.7.4. Remember that you might have to recompile the driver on a kernel update. That means re-installing the package!

If you use the in-kernel module you don't have to do anything, since the package is pre-compiled (unless you build the kernel from source of course), which is very convenient.

I don't see what Kaffeine has to do with this. It's a just a very bulky program that accomplishes the simple task of disabling the screensaver. I don't see the need for a screensaver, let alone a screensaver blocker.

trzalica commented on 2014-02-23 13:20

@Gringo - please, can you tell me which kernel you're using? Maybe 3.13 or?

I used older version of this driver (from openpli community and it worked well). Today I tried to reinstall once again driver and Kaffeine and now everything works again - it's a little bit weird...

Gringo commented on 2014-02-23 11:10

@trzalica: what doesn't work? Do you have logs you can share? Remember this is not a support website of the driver. R00KIE just packages the driver for Arch Linux, which you can also do yourself.

If this is the first time you tried this package/driver on Linux, we might not even be able to help you. You should ask 'upstream' (openpli project) instead. Also, I don't need even need this driver myself for basic support (scanning and viewing channels) anymore, since this driver is included in the kernel.

trzalica commented on 2014-02-22 18:53

This version doesn't work with LifeView LV5T DELUXE TV, please fix it! (It simply doesnt show anything, screen is black and I tried to scan for programs but nothing... I use Kaffeine...)

R00KIE commented on 2014-02-22 16:26


Location of header files has changed from 3.12 to 3.13. Fix should be backwards compatible with older kernels.

vibee commented on 2014-02-21 17:02

FYI: My dvb stick (MSI Digi Vox Mini II) now seems to work out of box without this package, so I don't need it any more.

vibee commented on 2014-02-21 16:37

I can not install the package after Upgrading to 3.13.4 today. This is the output:

==> Starting build()...
make -C /usr/lib/modules/3.13.4-1-ARCH/build SUBDIRS=/tmp/yaourt-tmp-clemens/aur-dvb-usb-rtl2832u-openpli/src/build_dir modules
make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
make[1]: Entering directory '/usr/lib/modules/3.13.4-1-ARCH/build'
Makefile:326: /usr/src/linux-3.13.4-1-ARCH/scripts/Kbuild.include: No such file or directory
Makefile:582: /usr/src/linux-3.13.4-1-ARCH/arch/x86/Makefile: No such file or directory
/bin/sh: /usr/src/linux-3.13.4-1-ARCH/scripts/ No such file or directory
make[1]: *** No rule to make target '/usr/src/linux-3.13.4-1-ARCH/arch/x86/Makefile'. Stop.
make[1]: Leaving directory '/usr/lib/modules/3.13.4-1-ARCH/build'
Makefile:30: recipe for target 'default' failed
make: *** [default] Error 2

Any idea how to fix?

R00KIE commented on 2013-09-18 14:01

According to the openpli forum post these are the changes from the previous version:

"The only changes since the latest version are 2 more USB PIDs that were requested a long time ago:

added definition of a new Terratec PCI-E stick (using the rtl2832u USB chip):
- TERRATEC Cinergy T Stick+ [ID 0ccd:00d7]
(thanks to sfasf);

added definition of a new Leadteck USB stick:
- Leadtek WinFast DTV2000 DS PLUS [ID 0413:6f12]
(thanks to michaelp);"

kamiljk87 commented on 2013-09-06 12:25

Correct, checked and looks like patch file updated and yaourt dont auto replace old one. Thanks for confirm that works...

R00KIE commented on 2013-09-05 16:27

No it didn't, the checksum is the same.

Check with a browser or with wget that you can get the patch file.

kamiljk87 commented on 2013-09-05 15:23

Looks like patch file checksum changed...

R00KIE commented on 2013-09-03 14:00

Good that it works with the driver included in the kernel :)

Out of curiosity, what's the output of 'pacman -Q linux' and 'uname -r' when building the driver fails?

Exeleration-G commented on 2013-09-02 14:22

Tried that, didn't help. But it seems like Arch can run this DVB dongle without installing this package, too. Pretty cool, that wasn't possible in Ubuntu.

R00KIE commented on 2013-08-31 21:25

Reboot and try again.

Exeleration-G commented on 2013-08-31 21:11

Getting an error while building:

R00KIE commented on 2013-08-31 15:15

If you want to try the kernel's driver just uninstall this one.

The easiest way would be, uninstall this driver, reboot without the usb receiver plugged in, then watch the output of dmesg before and after you plug the receiver. Check if your device is recognized and if the tuner inside supported, give it a test with the program you usually use to watch tv.

For reference here is what I get when I plug my adapter when using the kernel's driver:
usb 6-1: new high-speed USB device number 7 using ehci-pci
usb 6-1: dvb_usb_v2: found a 'Dexatek DK DVB-T Dongle' in warm state
usbcore: registered new interface driver dvb_usb_rtl28xxu
usb 6-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
DVB: registering new adapter (Dexatek DK DVB-T Dongle)
usb 6-1: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
i2c i2c-5: fc0012: Fitipower FC0012 successfully identified
Registered IR keymap rc-empty
input: Dexatek DK DVB-T Dongle as /devices/pci0000:00/0000:00:13.5/usb6/6-1/rc/rc0/input16
rc0: Dexatek DK DVB-T Dongle as /devices/pci0000:00/0000:00:13.5/usb6/6-1/rc/rc0
usb 6-1: dvb_usb_v2: schedule remote query interval to 400 msecs
usb 6-1: dvb_usb_v2: 'Dexatek DK DVB-T Dongle' successfully initialized and connected

vibee commented on 2013-08-31 14:48

@R00KIE: Thanks for the fast update and your comment. If I want to try the driver provided by the kernel, do I need to load it initially? WIthout installing this driver, it hasn't been working yet.

R00KIE commented on 2013-08-31 12:03

I have made the change you suggested.

It seems the sources were moved and one patch I was applying is no longer needed as it was included in these newer sources. The new sources match my local copy of the old sources after applying the patch.

Again I recommend that you check if the driver provided by the kernel works for your usb receiver. The driver from the kernel lacks the refinements included in this driver (1) but it should work more reliably from my experience. As a bonus if you use the kernel driver there is nothing to rebuild with each kernel update.

(1) Some changes were made to this driver so that signal strength and snr are normalized and shown in a scale of 0-100%.

vibee commented on 2013-08-31 01:21

Seems like the package is broken due to a kernel patch update?

I tried to edit the PKGBUILD and typed the correct URL to dvb-usb-rtl2832.patch and updated the md5sum as well. Unfortunately, I am being asked which file to patch (I have no clue).

duncant commented on 2013-04-22 23:25

Hi! My kernel version happens to have a dash in the patch name (3.8.6-1-ck-pax), so the _extramodules variable in the PKGBUILD gets set wrong. If you replace the definition:
_extramodules="extramodules-$(uname -r | cut -f-2 -d.)-$(uname -r | cut -f3 -d-)"
_extramodules="extramodules-$(uname -r | cut -f-2 -d.)-$(uname -r | cut -f3- -d-)"
it fixes that problem. You don't need to fix the PKGBUILD, I just thought I'd comment in case somebody else runs into the same problem.

kataja commented on 2013-03-09 20:46

Thanks, it was so simple! :)

R00KIE commented on 2013-03-09 18:10

Reboot after installing the driver and try again.

kataja commented on 2013-03-09 16:47

This is not working, I downloaded the tarball, ran makepkg -i and it compiled fine. But still it doesn't detect my the tuner of my dongle.

usb 1-3: dvb_usb_rtl28xxu: unknown tuner=NONE
usb 1-3: dvb_usb_v2: 'Realtek RTL2832U reference design' error while loading driver (-19)
usb 1-3: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully deinitialized and disconnected

My tuner is R820t and id 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

Gringo commented on 2013-01-23 17:03

I can confirm that kernel 3.7.4 supports the Ezcap EZTV645 [1] identified by lsusb as [2]. I don't use the remote, but just watch TV with VLC Player using a list of channels generated by w_scan. Therefore I cannot test all aspects of the DVB-T dongle, but the audio and video look just fine. dmesg should probably show the same message [3] on your system if the new drivers support your chipset.

Thanks for updating the package and putting in the credits, R00KIE! :)

[1] Ezcap EZTV645 (
[2] lsusb: 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
[3] dmesg | grep dvb: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully initialized and connected

R00KIE commented on 2013-01-23 16:01

Based on Gringo's patches I have uploaded an updated PKGBUILD.
The package now ships a file to blacklist the driver that comes with the kernel.

Thanks for looking into this and providing patches.

Be aware that the kernel now has a driver that may already support your device.

I'd say the kernel driver should be used instead of this one if possible. The only downside is that signal strength, snr and fe lock are not reported in the same way as this driver, this means that using femon will not work as expected.

Scanning for channels with w_scan for example works fine. Remote control support may be much better than with this driver (I haven't tested it).

donny commented on 2013-01-23 07:22

Hi Gringo, nice job! I gonna try it tonight.

Gringo commented on 2013-01-22 19:55

Whoohoo, I fixed it! :) An updated source tarball can be downloaded from [1].

- I changed the include directories in the Makefile, because the paths were indeed changed.
- Also, a member field was removed from a struct in the kernel, but it was still in rtl2832u.c . I simply removed the lines containing the calls to this function and updated rtl2832u_ioctl.h to reflect the same change.

The source tarball below should be unrolled (tar -xzvf) and a package can be made with, for example, makepkg -cis (compile, install, clean). The added files are three patches, which can be checked if you want: Makefile.patch, rtl2832u.c.patch and rtl2832u_ioctl.h.patch. The resulting kernel module was tested and seems to work as good as the old one. Enjoy!


donny commented on 2013-01-22 19:40

I also tried to manually create some symlinks to previous locations and add paths to some #includes, but it didn't work. Also bumblebee stopped working with new kernel, so I downgraded back to 3.6.11. If you want to do the same and you cleaned your /var/cache/pacman/pkg, you can get the linux and linux-headers packages and .sig on

Gringo commented on 2013-01-21 22:58

@donny: that could be it. The 'missing' file is actually on my drive, but maybe it cannot be found. I tried to fix it by adding the directory that contains to file to my $PATH, but it didn't work.

The location is: /usr/src/linux-3.7.3-1-ARCH/drivers/media/usb/dvb-usb/dvb-usb.h

donny commented on 2013-01-21 21:53

does ot compile on 3.7.3. It looks like some dvb/usb directories in kernel sources has been changed.

Gringo commented on 2013-01-21 11:54

I'm getting an error compiling the module for Linux kernel 3.7.3-1-ARCH.

==> Starting build()...
patching file rtl2832u.h
make -C /usr/lib/modules/3.7.3-1-ARCH/build SUBDIRS=/tmp/yaourt-tmp-benny/aur-dvb-usb-rtl2832u-openpli/src/build_dir modules
make[1]: Entering directory `/usr/src/linux-3.7.3-1-ARCH'
make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
CC [M] /tmp/yaourt-tmp-benny/aur-dvb-usb-rtl2832u-openpli/src/build_dir/demod_rtl2832.o
In file included from /tmp/yaourt-tmp-benny/aur-dvb-usb-rtl2832u-openpli/src/build_dir/dvbt_demod_base.h:289:0,
from /tmp/yaourt-tmp-benny/aur-dvb-usb-rtl2832u-openpli/src/build_dir/demod_rtl2832.h:72,
from /tmp/yaourt-tmp-benny/aur-dvb-usb-rtl2832u-openpli/src/build_dir/demod_rtl2832.c:13:
/tmp/yaourt-tmp-benny/aur-dvb-usb-rtl2832u-openpli/src/build_dir/foundation.h:19:21: fatal error: dvb-usb.h: No such file or directory
compilation terminated.
make[2]: *** [/tmp/yaourt-tmp-benny/aur-dvb-usb-rtl2832u-openpli/src/build_dir/demod_rtl2832.o] Error 1
make[1]: *** [_module_/tmp/yaourt-tmp-benny/aur-dvb-usb-rtl2832u-openpli/src/build_dir] Error 2
make[1]: Leaving directory `/usr/src/linux-3.7.3-1-ARCH'
make: *** [default] Error 2

kamiljk87 commented on 2012-09-05 19:29

Confirm also successfull compiling and detecting on kernel "linux-3.5.3-1-ARCH". Thanks.

R00KIE commented on 2012-08-28 01:20

It should work since /lib, which is owned by glibc, is a symlink to /usr/lib, however I have updated the package anyway since I prefer not to rely on symlinks.

kamiljk87 commented on 2012-08-23 19:47

In kernel 3.4.9-1-ARCH to compile successfull must change in Makefile line 22 from /lib/modules/$(KVER)/build to /usr/lib/modules/$(KVER)/build . And compilation was successfull.

R00KIE commented on 2012-07-14 17:37

Updated the PKGBUILD to install the module into /usr/lib.

R00KIE commented on 2012-04-06 13:42

Small status update regarding remote control support:

Upstream(1) does not plant to work on making the USB tuners work as generic IR receivers since they already use/support generic receivers that work with all remotes. As it is the driver needs to be patched to support the _one_ remote that is intended to be used with the USB tuner (eg. the bundled remote).

The bundled remote should work fine if the correct mappings are patched into the driver, however other remotes may not work, this depends on the IR protocol used by the remote(2). The current package does not patch the upstream driver as it doesn't make sense, since support is specific to each type of remote. I can provide some instructions on how to get each button code and an example patch if anyone is interested.

The (better) alternative to patching the driver is to use an IR receiver that works well with LIRC and supports all remotes.

(1) The OpenPLi devs working on keeping this driving building and working with current kernels.
(2) Based on the test I have performed with the USB tuner and remotes I own.

Anonymous comment on 2012-04-03 10:27

thanks !

R00KIE commented on 2012-04-02 18:12

Updated package here [1]. It builds cleanly and works with kernel 3.3 and includes a signal strength reporting fix and 3 more supported adapters.

I will leave this package here for future reference in case the git repo starts to be updated again or some other repo appears with a better driver.


R00KIE commented on 2012-04-02 18:09

This is an updated version of [1] which compiles cleanly with kernel 3.3 and should also work with 4.4.
This also includes 3 more supported adapters and a signal strength reporting fix.

Module name is dvb_usb_rtl2832u as requested in [1].


R00KIE commented on 2012-04-02 13:45

I can reproduce the problem but solving it is beyond my capabilities. I have posted in [1] asking if there are any plans to update the driver to compile with kernel 3.3 or if there is already any code available that works.

Meanwhile there isn't much I can do and I will be in the same situation as you when linux-3.3 is moved to core.


Anonymous comment on 2012-03-29 09:18

Error while compiling for me:

R00KIE commented on 2012-03-18 21:47

You are right, linux-headers needs to be added to makedepends.

As I have linux-headers installed, building has never exploded for me. Updated pkgbuild has been submitted.

Anonymous comment on 2012-03-18 21:27

or makedepends, preferably

Anonymous comment on 2012-03-18 21:19

Same problem, both with plain makepkg and doing the build steps manually.
The makefile contains

KDIR = /lib/modules/$(shell uname -r)/build

after patching, which obviously expands to the path /lib/modules/3.2.11-1-ARCH/build -- which doesn't exist.
I've installed the linux-headers package and now it works.

So this pgkbuild should probably be changed to

depends=('linux' 'linux-headers')

thanks for your help and the quick reply!

R00KIE commented on 2012-03-18 16:18

Compiles fine here, I don't use AUR helpers such as yaourt so I don't provide support for that.

Try building manually without using yaourt or other AUR helpers.

R00KIE commented on 2012-03-18 15:03

Compiles fine here, I don't use AUR helpers such as yaourt so I don't provide support for that.

Anonymous comment on 2012-03-18 13:26

Fails to compile for me. Looks like something stupid (missing prerequisite) on my part.

Make tries to access /lib/modules/3.2.11-1-ARCH/build, which does not exist.

Do I have to have a manually build kernel or something?

==> Starting make...
Cloning into '/tmp/yaourt-tmp-empinchen/aur-rtl2832u-git/src/rtl2832-build'...
patching file Makefile
make -C /lib/modules/3.2.11-1-ARCH/build SUBDIRS=/tmp/yaourt-tmp-empinchen/aur-rtl2832u-git/src/rtl2832-build/RTL2832-2.2.2_kernel-3.0.0 modules
make: *** /lib/modules/3.2.11-1-ARCH/build: File or directory not found.
make: *** [default] Error 2

letku commented on 2012-03-02 16:54

Deleted everything on it ,and now it works, mysterious.. never had a problem like this one..
But it's my own mistake, and sorry for wasting your time.

R00KIE commented on 2012-03-01 19:44

Compiles and works fine here.

Why on earth is it exploding on .local/share/Trash for you?

letku commented on 2012-02-29 22:18

This seem's to be broken with 3.2.8-1 ARCH I'm getting error:
make[1]: *** [_module_/home/letku/.local/share/Trash/files/rtl2832u-git/src/rtl2832-build] Error 2
With older kernels things were fine.

R00KIE commented on 2012-02-12 10:44

I will upload a new renamed package and ask to merge the votes and comments, but first have to check a few things about the remote control handling so I upload an updated package and instructions.

Right now I have tested if the remote control works, and it does, but the key mappings have to be hardcoded in the driver so things work automagically with the dev/input driver in lirc, this means you have to find which code corresponds to each key of the remote you want to use and then write a patch against the driver, this is cumbersome and there is probably a better way to do it.

masutu commented on 2012-02-08 22:56

Thanks, works great with "0ccd:00a9 TerraTec Electronic GmbH RTL2838 DVB-T COFDM Demodulator [TerraTec Cinergy T Stick Black]", +1 vote!
Would you mind to rename this package to dvb-usb-rtl2832u-git (create new pkgbuild, merge request)? IMHO it would better fit (module name as you already mentioned/searchability/other PKGBUILDs like dvb-usb-rtl2832u-stv20, dvb-usb-rtl2838u-arch, dvb-usb-rtl2838u-lts).

R00KIE commented on 2012-01-19 14:21

Updated package to fetch the sources from another git repository because the previous sources no longer compiled under kernel 3.2, the new git repository has v.2.2.2 of the driver while the previously used repository had v.2.2.0. These sources also seem to be actively maintained.

The name of the module has changed to dvb-usb-rtl2832u (previous name was rtl2832u). This has been tested on a x86_64 system only with kernel 3.2.1-1-ARCH. I did not test if the IR receiver is working with this newer sources.

R00KIE commented on 2011-11-09 14:03

Updated to comply with kernel modules packaging guidelines[1].