Package Details: nginx-mod-rtmp 1.2.1-1

Git Clone URL: (read-only, click to copy)
Package Base: nginx-mod-rtmp
Description: Module for nginx that adds RTMP support
Upstream URL:
Licenses: BSD
Submitter: XDjackieXD
Maintainer: XDjackieXD (Martchus)
Last Packager: XDjackieXD
Votes: 1
Popularity: 0.000001
First Submitted: 2018-03-31 20:33
Last Updated: 2021-01-03 01:30

Latest Comments

XDjackieXD commented on 2021-02-21 11:23

@kulpae: libxcrypt is a dependency of nginx which is a dependency of this package. on the machines I tried right now, libxcrypt and nginx get installed as part of the dependency resolution before makepkg lets me compile this aur package...

kulpae commented on 2021-02-13 00:24

I couldn't install this mod on my server initially. Had to pacman -S libxcrypt first, to make it compile nginx successfully.

Martchus commented on 2021-02-03 14:25

Here's my version which simply hard codes the nginx version:

One really needs to rebuild the package when a new nginx version comes out so the package needs to be bumped in this case anyways. My version also make use of the official nginx-src package.

hashworks commented on 2021-02-03 11:07

Could you replace _nginxver? With the current implementation it can't be build in a chroot environment.

Vrakfall commented on 2019-02-21 11:25

Oh ok, I didn't know. Interesting things I learned there. Your package works fine for me btw but I didn't test XDjackieXD's one. It's probably fine to push yours? Maybe ask #archlinux-aur.

Martchus commented on 2019-02-10 17:53

@Vrakfall I adjusted my version. Note that my version is not based on the PKGBUILD submitted by XDjackieXD. I've crafted it on my own when converting the nginx-custom package to the dynamic approach. That was a bunch of new packages to be created. Only after doing that I've noticed that some of the packages like this one would have already existed.

I also wonder how your "dynamic approach" works in all that and if there are things I need to do before using it as is.

It is not "my" dynamic approach. My packages is not different in that regard than the one submitted by XDjackieXD. If you're migrating from the "static approach", see my comment under the nginx-custom package.

I added the link to my version here because at that time the version here was outdated. But the only advantage of my version in contrast the the version provided here is that I also provide a binary repository. I usually rebuilt the packages soon after a new nginx release.

Vrakfall commented on 2019-02-10 16:28

@Martchus: In your script, the pkgdesc variable looks completely off of the tracks and I don't understand why you change the upstream link when the repo is the source used in the PKGBUILD. D: (That blogspot is referenced on the repo's readme anyway.)

I'm going to test it in a moment, it looks good so far. If it works, you should just push it with the modifications I talked about reverted and don't forget to mention back the names of the other authors.

I also wonder how your "dynamic approach" works in all that and if there are things I need to do before using it as is.

Martchus commented on 2018-12-09 18:32

@Fogel Here's an updated version:

I also provide a binary repo which is rebuilt as soon as possible after an nginx update:

(My version looks a bit different than the one provided by @XDjackieXD. So I'm not just uploading it here although he added me has co-maintainer.)

XDjackieXD commented on 2018-04-22 20:50

Martchus: I'll gladly take the offer if it isn't too much work for you. Thank you!

Martchus commented on 2018-04-22 20:44

Seems I unnecessarily created a new package for this when migrating my nginx-custom package to the dynamic approach:

If you like, you can add me as co-maintainer. I have to update/rebuild my other NGINX modules anyways. One more package shouldn't make a difference.

The binary repository I provided for nginx-custom will include also include this package when NGINX 1.14 is out: