Arch Linux

I have been using this package successfully for quite a while. However recently I realised that when I connect my bluetooth headphones, I get a segfault:

Object::connect: No such slot VDController::OnReceiveInitialBuddyList(VDRequestResponseBuddyList*) in ../source/VDController.cpp:2092
Object::connect: (sender name: 'VDLoginWindow')
/usr/bin/VidyoDesktop: line 6: 1121 Segmentation fault (core dumped) /opt/vidyo/VidyoDesktop/$EXEC $option $audioflag $@

Has anyone seen this before, or does anyone have an idea where to go looking to fix it?

Thanks!

@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.

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').

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?

@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.

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.

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.

@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.

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.

I'd been struggling to understand why, after installing on two machines with different desktop environments, one machine would refuse to run this package.

$ VidyoDesktop
CLIENT: socket_error
removed server QTVD-IPC-SERVER
IPC server fired successfully
QPainter::begin: Widget painting can only begin as a result of a paintEvent

It would seem that Vidyo really does want you be using Pulse Audio. The error given is not exactly obvious, but it's a problem connecting to pulse. Starting it this way works:

VIDYO_AUDIO_FRAMEWORK=ALSA VidyoDesktop


Hopefully this helps somebody else!

As usual Carl I agree with everything. :) While I'm usually not a fan of changing what the vendor wants to do, I agree that shipping the XDG file that causes an autostart *for every user* is just a bad idea, and have used your changes to stop shipping it.

Not sure about that weird extract problem either -- I've uploaded a new -4 release with the changes and just did a full 'yaourt -Syua' (woo, new kernel!) and the vidyodesktop package is upgrading cleanly without those errors. Give it a shot on your end and see if the errors went away...

Thanks for the reports on problems!

I'm not sure what changed to cause this, but now I'm getting build errors

od: /build/vidyodesktop/src/: read error: Is a directory
expr: non-integer argument
expr: non-integer argument
expr: syntax error
expr: non-integer argument
od: invalid -j argument '-N'
expr: non-integer argument
expr: non-integer argument
expr: syntax error
expr: syntax error
bsdtar: Error opening archive: Unrecognized archive format

I removed the rpmextract stuff from the PKGBUILD so that makepkg can correctly use bsdtar to extract the rpm. Now it builds fine.

package() {
cp -dpr "${srcdir}/opt" "${pkgdir}"
cp -dpr "${srcdir}/usr" "${pkgdir}"
install -dm1777 "${pkgdir}/opt/vidyo/VidyoDesktop/lic"
install -Dm0644 "${srcdir}/opt/vidyo/VidyoDesktop/license.txt" \
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}

I intentionally left out /etc because the only file in there is a .desktop file that is causing the application to be autostarted (regardless of what the check box in the settings says). /etc/xdg/autostart/VidyoDesktop.desktop is just a duplicate of /usr/share/applications/VidyoDesktop.desktop, with an extra flag. The extra flag is parsed by /usr/bin/VidyoDesktop and just causes the application to wait 8 seconds before starting. I would just leave that file out to prevent the autostart.

The AUR can't parse custom variables in the source array, so the sources section here on the web interface is not displaying properly. I would change it to this instead.

if [ "$CARCH" == "i686" ]; then
source=("https://demo.vidyo.com/upload/VidyoDesktopInstaller-sl5-TAG_VD_3_3_0_027.rpm")
md5sums=('02e44ed593066c6cca6dd69e165a864b')
elif [ "$CARCH" == "x86_64" ]; then
source=("https://demo.vidyo.com/upload/VidyoDesktopInstaller-sl564-TAG_VD_3_3_0_027.rpm")
md5sums=('ce446bf9f222675891c2437394102d92')
fi

Thanks for the report -- I've updated the PKGBUILD (-3 release) to address both:

1) variable name is now preceded by _ as per guidelines, I copied/pasted that part and missed it.

2) The used of the name in the package was 100% intentional, as the phrase is a trademarked term. Since packaging guidelines indicate the name of the package must be all lowercase, the name VidyoDesktop is intentional in the desciption -- I have updated PKGBUILD to use the *proper* (oops) phrase, "VidyoDesktop(TM)" which I should have done - this is their trademark and must be represented as such according to the websites I was able to Google. (actually most say to use the non-ASCII ^TM symbol, but I won't do that).

http://www.vidyo.com/products/use/#tab=Desktop

Fixing it to add (TM) to satisfy the legal requirement has a side effect of namcap not calling it out as broken. We want to be careful with packaging commercial software to represent all trademarks, etc.

$ namcap PKGBUILD
PKGBUILD (vidyodesktop) W: Non standard variable 'rpmfilename' doesn't start with an underscore
PKGBUILD (vidyodesktop) W: Description should not contain the package name.

https://wiki.archlinux.org/index.php/Arch_packaging_standards#Package_etiquette

"Do not introduce new variables into PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables used in makepkg itself. If a new variable is absolutely required, prefix the variable name with an underscore (_)..."

"When creating a package description for a package, do not include the package name in a self-referencing way. For example, "Nedit is a text editor for X11" could be simplified to "A text editor for X11"."

Roger that -- I've uploaded 3.3.0.027-2 changing the depends() for libgl, give it a shot now. Thanks for reporting!

Please require libgl instead of mesa-libgl. libgl can be provided by either mesa-libgl or nvidia-libgl, but you don't want to force users to either one. I'm sure there is some AMD/ATI equivalent as well.