Package Details: janus-gateway 0.9.5-1

Git Clone URL: https://aur.archlinux.org/janus-gateway.git (read-only, click to copy)
Package Base: janus-gateway
Description: Janus WebRTC Server
Upstream URL: http://janus.conf.meetecho.com
Licenses: GPL3
Submitter: dseg
Maintainer: caleb (feighur, robertfoster)
Last Packager: feighur
Votes: 7
Popularity: 1.57
First Submitted: 2016-01-29 11:22
Last Updated: 2020-05-20 07:24

Dependencies (29)

Required by (1)

Sources (3)

Pinned Comments

caleb commented on 2020-05-06 08:48

Note to anyone trying to version-bump this package: You must actually (re)build the package before trying to regenerate the .SRCINFO file or the backups array won't be populated. The upstream seems to have a revolving door of config files so it is scanning what make configs actually installs to catch all the non-sample files. You can't cheat and bump the PKGBUILD without actually building it.

Latest Comments

1 2 Next › Last »

caleb commented on 2020-05-24 18:12

@vithatt: You could report that to ask for more useful error messages upstream, but there really isn't much they could do either other that to propose the two most likely reasons: the port is in use and or the user doesn't have permission to open it. Detecting which is the case is hard because the operating system often doesn't want (for security reasons) to reveal that information, hence the generic error. You are expected to know as an admin what ports your system has open and what processes are running them. Try sudo netstat -lntp to see them all. Beyond that I think you need to get upstream support, it doesn't sound like an issue with this packaging.

vithatt commented on 2020-05-23 06:42

@feighur ah ok:( I am only using port 22, It is really annoying with this because there is no hint in the logs about why it could not start, even if debug output level is set to 7:/

feighur commented on 2020-05-23 04:32

@vithatt That is usually caused by some other process using the same port. If that is not the problem then I don't know what it is

vithatt commented on 2020-05-22 13:56

It does not work for me, when i start using systemctl start janus I get this: [FATAL] [transports/janus_http.c:janus_http_init:738] Couldn't start webserver on port 8088...

Full log while using debug level 7: https://pastebin.com/1WKinJXN

caleb commented on 2020-05-07 19:47

@feighur I've done a first pass at noting the things that are optional. It looks like I might be wrong and only some of those are required at build time, it looks like others may be run-time checks. If you get any solid info on which are which I'd be happy to help get this updated to reflect that or you can submit PRs from Github.

caleb commented on 2020-05-07 19:32

Thanks for the tips @feighur. I'll definitely cleanup the certs/install thing based on your input.

About dependencies though, I think you're handling them wrong. It does sort of work that way on the AUR, but the problem is those are not actually optdepends. By rights they would be optmakedepends — they must be present (or not) and compile time in order to be useful. In Arch packaging parlance optdepends are for packages you can install to your system and have the extra functionality available at run time. This is the only way it can work for most Arch Linux package repositories, whether the official core/extras/community/testing ones or any of the unofficial ones. This includes the unofficial one I host (that has this package). Since packages are precompiled whatever options you are going to bake in (or not) have to be done at the time of making the package. That means the packager has do decide on what to enable, and usually that means most/all of the common features and plugins possible.

About the best compromise I can think of is annotating the PKGBUILD so that people building it on there own can know what dependencies can be commented out if they don't want the extra features.

By the way if you have anything you want to contribute directly you can also open PRs against this package here.

feighur commented on 2020-05-07 16:17

I'd like to offer a few PKGBUILD modification I'm using myself:

The certs and the entire /usr/share/janus directory are no longer created or required in the current version of Janus. I've simply removed the .install file and all references to the directory

A set of (not fully tested) {make,opt,}depends that builds all features except docs and JS modules (as reported by configure), and is sufficient for the echo test demo without any optdepends. Descriptions for the optdepends items are taken from the upstream website (not fully tested)

depends=('jansson' 'libconfig' 'libnice' 'openssl' 'libsrtp' 'glib2'
         'libusrsctp-git' 'libmicrohttpd')
optdepends=('libwebsockets: WebSockets support for Janus API'
            'librabbitmq-c: RabbitMQ support for the Janus API or events'
            'paho-mqtt-c-git: MQTT support for the Janus API or events'
            'nanomsg: Nanomsg support for the Janus API'
            'curl: TURN REST API support, RTSP support in Streaming/Event Handler plugin'
            'sofia-sip: SIP plugin'
            'opus: Bridge plugin'
            'libogg: Voicemail plugin and/or post-processor'
            'ffmpeg: Post-processor'
            'lua: Lua plugin')
makedepends=('gengetopt' 'libwebsockets' 'librabbitmq-c' 'paho-mqtt-c-git'
             'nanomsg' 'curl' 'sofia-sip' 'opus' 'libogg' 'lua' 'ffmpeg')

caleb commented on 2020-05-06 08:48

Note to anyone trying to version-bump this package: You must actually (re)build the package before trying to regenerate the .SRCINFO file or the backups array won't be populated. The upstream seems to have a revolving door of config files so it is scanning what make configs actually installs to catch all the non-sample files. You can't cheat and bump the PKGBUILD without actually building it.

caleb commented on 2020-05-06 08:45

@ubuntourist The first packaging issue you mentioned is fixed, the new package finds and makes backups of all config files.

The second issue you note is more problematic, and I didn't attempt to fix it yet. Honestly the current solution using the post_install() hook looks like a really dirty hack to me. I'm wondering if there is a better mechanism to handle that. Any thoughts @robertfoster?

caleb commented on 2020-05-06 08:02

I'm sorry @robertfoster I didn't mean to snip this orphaned package from you. I got an email notification about it and actually thought I had filed the orphan request. I have some previous attempts at updating the package that I'll be posting as soon as I can verify their current build status. The dependencies have changed quite a bit since this was pasted and it looks like not all of the dependencies currently build from the AUR so it might take a bit before I actually post it. I've added you as a co-maintainer too, we can ever reverse that if it matters to you.