Package Details: vidyodesktop 3.6.3.017-7

Git Clone URL: https://aur.archlinux.org/vidyodesktop.git (read-only, click to copy)
Package Base: vidyodesktop
Description: VidyoDesktop(TM) video conferencing client
Upstream URL: http://www.vidyo.com
Keywords: client desktop proprietary videoconference
Licenses: custom
Conflicts: vidyo
Submitter: troyengel
Maintainer: seadanda
Last Packager: seadanda
Votes: 15
Popularity: 0.000000
First Submitted: 2014-09-05 20:19 (UTC)
Last Updated: 2018-10-26 09:42 (UTC)

Pinned Comments

seadanda commented on 2018-02-05 14:20 (UTC)

Hi @bunnybooboo, VidyoDesktop broke with an update to qt a few months ago. Unfortunately Vidyo stopped supporting Vidyo Desktop on Linux a long time ago and so I doubt we will see any attempts to fix this problem. The current version (3.6.3_017) was released back in March 2016. Since it is closed source the only way that we have found to run it succesfully is by using a systemtray application.

If you run trayer (which is installed as a dependency) before running Vidyo Desktop, Vidyo works without any issues. This is unfortunate but it is an upstream issue.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

davidovitch commented on 2015-02-12 07:49 (UTC)

@troyengel: I am not criticising the package in itself, I think it is great you give it so much care, and it clearly works properly. The only point I am trying to make is that it is a duplicate of the vidyo package (which also works fine, and is not tied to the CERN infrastructure as it was in the past). So ideally, both the vidyo and vidyodekstop packages should merge to avoid confusion, and not have a duplicate effort. I don't have any opinion on which name it should have (vidyo or vidyodesktop), and I don't have an opinion on who should maintain it. I can't imagine there is any technical reason to disagree about with the vidyo package maintainer either, because both packages are after all the same.

troyengel commented on 2015-02-12 01:09 (UTC)

davidovitch -- I just ran a clean makepkg on it, and do not see the etc/xdg present in the finished package. Is there anything unique about your build environment that could help explain it? The source RPM *does* have a xdg Desktop file (see carl.george's comment below) that we are choosing not to package, as it creates undesirable behaviour (autostarts the app on desktop login) for the end user. Only the items from opt/ and usr/ are being packaged (and the commercial LICENSE). BTW: I also took great care with the depends() array in this package to ensure that every last shared library was accounted for, a fresh Arch install and then adding this package will pull in anything that's missing so that the binaries launch (even that silly first-run shellscript code which requires 'zenity').

monticel commented on 2015-02-11 17:59 (UTC)

I second davidovitch. vidyo is not (at least any more) tied to CERN, and it would be great if both packages are merged to avoid confusion and duplication of maintenance manpower. vidyo-moz seems another duplication and is flagged as outdated. Maybe it should be asked for removal?

davidovitch commented on 2015-02-11 16:51 (UTC)

@troyengel: the vidyo package is not tied to CERN, it uses the deb package from the download site, while vidyodesktop uses the RPM package as source. There are some small differences though: * vidyodesktop includes the license file * vidyodesktop has an empty etc/xdg directory (at least when I use makepkg to build the package) * vidyodesktop has a .install file which kills any running vidyo clients before updating/removing, and a useful instruction/warning for non Pulseaudio systems. But other than that, both packages seem to be identical. It could be nice if both packages are to be merged to avoid confusion, because they are virtually the same.

troyengel commented on 2015-01-16 02:52 (UTC)

The Vidyo Desktop software is a bit of a strange thing, but not really that strange if you're used to working at a place where proprietary 3rd party software is deployed -- the client is tied to the server infrastructure, typically run by the IT department of your company (University, etc.) and it's common that your internal IT department may have a specific version of the client software they support. The 'vidyo' named package is target at the people who work at CERN and should probably get renamed for clarity to something like 'vidyo-cern', the 'vidyo-moz' is targeted at the Mozilla employees. This 'vidyodesktop' (which is the actual, trademarked name) was created to track the very latest upstream package and not be tied to a specific company/infrastructure. For some people this is what's needed, for others it's not -- you're internal IT department will set the standard for you as an end-user. The download for this latest version is via the landing page https://demo.vidyo.com/download.html, which has links to the RPM and DEB packages. The latest (as of this writing) is what's listed here, 3.3.0.127 -- the other two packages are currently older versions as CERN and Mozilla most likely need them that way (I don't work there, don't know). At my company, our IT department has blessed this later version for use for example.

basil commented on 2015-01-15 21:39 (UTC)

What is the difference between this package and the one just called 'vidyo'? And is the version number correct? I find only 3.3.0.027 upstream.

troyengel commented on 2014-12-09 14:52 (UTC)

@basil - this isn't the right place for that type of question, this comment area is for issues with the package itself. Post a thread over on the forums in the Applications area for help: https://bbs.archlinux.org/viewforum.php?id=18 Hint: posting "I assume VidyoDesktop is the reason for it" will get you little help without any proof at all, be prepared to actually debug your situation better and provide logs and evidence, etc.

troyengel commented on 2014-12-06 01:08 (UTC)

In the package I have this (pretty lame) snippet: post_install() { if test ! -f /usr/bin/pulseaudio ; then echo "Pulseaudio not detected - you may need to manually enable ALSA:" echo " export VIDYO_AUDIO_FRAMEWORK=ALSA" fi } I realize that's pretty basic, but I'm not sure of any better way to warn the user. The package install may take place during a core installation, so we can't check for a running process, socket or anything like that. Any better ideas, holler - I'm all ears.

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »