Package Details: zoom 6.2.6-1

Git Clone URL: https://aur.archlinux.org/zoom.git (read-only, click to copy)
Package Base: zoom
Description: Video Conferencing and Web Conferencing Service
Upstream URL: https://zoom.us/
Keywords: call conference meeting video
Licenses: LicenseRef-zoom
Submitter: edh
Maintainer: edh
Last Packager: edh
Votes: 669
Popularity: 7.40
First Submitted: 2015-08-15 13:18 (UTC)
Last Updated: 2024-10-28 11:11 (UTC)

Pinned Comments

arash-m commented on 2024-09-15 15:56 (UTC)

Tested 6.2.0-1. Sharing works for me, but it still crashes after stopping. The workaround for me is still downgrading pipewire and libpipewire to 1.0.7 before meetings.

a172 commented on 2022-06-13 14:25 (UTC) (edited on 2022-06-13 14:25 (UTC) by a172)

@edh - That's not the answer I was hoping for (I was really hoping we could get it to launch without xwayland), but at least I know I'm not missing something.

Some ~/.config/zoomus.conf updates:

  • SSO Login: I don't have qt5-webengine installed, and the ebeddedBrowserForSSOLogin line doesn't exist in my config zoomus.conf. SSO login works just fine (issues with Firefox containers aside).
  • Audio: I am using Pipewire via pipewire-pulse. system.audio.type defaulted to alsa for me (or I changed it without realizing it). I probably could have installed pipewire-alsa and fixed my issues, but I set system.autio.type=pulse (a lucky guess) and this worked. This should work for anyone using straight PulseAudio as well.

If anyone finds documentation on ~/.config/zoomus.conf, please let us know.

edh commented on 2016-08-26 11:03 (UTC) (edited on 2017-03-09 10:48 (UTC) by edh)

I contacted the zoom support on 13th July 2016 and tried to lure them into creating a proper PKGBUILD respectively adopting this one, considering they are providing a package over very none standard ways to the Arch Linux community (downloading via a *foreign* site) and not through the official repo or the AUR. However there was little to no progress so far.

Latest Comments

« First ‹ Previous 1 .. 33 34 35 36 37 38 39 40 41 42 43 .. 77 Next › Last »

edh commented on 2021-09-09 19:06 (UTC)

@darose Please read the previous comments. This issue has been extensively discussed.

P.s. a quick glance in the PKGBUILD will tell you that such an URL is already in use...

darose commented on 2021-09-09 18:22 (UTC)

When I went to the download page on their web site today (https://us05web.zoom.us/support/down4j) and checked what URL my browser used to do the download, I saw it used the full version number, including build: https://cdn.zoom.us/prod/5.7.31792.0820/zoom_x86_64.tar.xz . Any chance we could use that URL scheme for download going forward in order to avoid the version number issues?

internetuser commented on 2021-09-08 06:52 (UTC)

Anyone able to get hardware acceleration working?

jonathon commented on 2021-09-07 11:17 (UTC) (edited on 2021-09-07 11:21 (UTC) by jonathon)

Thanks for your patience. I didn't realise they reused the same build number in addition to version number (which is completely ridiculous - why even bother having a build number?).

edh commented on 2021-09-07 11:09 (UTC)

@jonathon As has been outlined a couple of times: This is not possible if upstream does not use unique identifiers. See for example the last commit. The version nor the build changed, the binary file though did change.

Now, there are only two options: I force an upgrade for every user by artificially changing the version to 5.7.6.a. This would require users who have already updated to reinstall the package without an actual need. The second option is to just wait and endure the current state of affairs until a new release is made. As of now, I am sticking to the second option.

jonathon commented on 2021-09-07 11:03 (UTC) (edited on 2021-09-07 11:16 (UTC) by jonathon)

Is there a reason not to include the build number at the end of the pkgver? e.g. 

_rel=5.7
_sub=6
_build=31792.0820
pkgver=$_rel.$_sub.$_build
...
source=("${pkgname}-${pkgver}_orig_x86_64.pkg.tar.xz"::"https://zoom.us/client/$_rel.$_build/zoom_x86_64.pkg.tar.xz")

This should help avoid all future issues with different builds of the same subversion?

alerque commented on 2021-09-05 08:38 (UTC)

@hexhu, @mnussbaum, and others commenting on the versioning issue. This has been covered at length in previous comments but it cannot be corrected until the next release upstream. Zoom release the same version twice with a silent update using the same version. No, using pkgrel to indicate this would not have been correct. The use of a to indicate this was correct and standard procedure. The only mistake was that it should have been separated from the version as its own segment .a so that it didn't get sorted incorrectly as an alpha version indicator. The maintainer has already indicated they will get that right next time, but it isn't possible to fix this time without introducing an obnoxious epoch version that will never go away.

hexhu commented on 2021-09-05 07:46 (UTC) (edited on 2021-09-05 07:48 (UTC) by hexhu)

The versioning seems wrong, should probably be 5.7.6-2 not the current 5.7.6a-1. Breaks pacman upgrade check (see below). On https://zoom.us/download#client_4meeting it shows "Version 5.7.6 (31792.0820)", we should stick to that when packaging. Same format is followed by the latest .PKGINFO: pkgver = 5.7.31792.0820-1.

:: Searching AUR for updates...
 -> zoom: local (5.7.6-1) is newer than AUR (5.7.6a-1)
 -> Flagged Out Of Date AUR Packages:  zoom

« First ‹ Previous 1 .. 33 34 35 36 37 38 39 40 41 42 43 .. 77 Next › Last »