Package Details: zoom 6.4.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: 689
Popularity: 9.44
First Submitted: 2015-08-15 13:18 (UTC)
Last Updated: 2025-04-22 04:41 (UTC)

Dependencies (31)

Required by (1)

Sources (1)

Pinned Comments

erbrecht commented on 2024-11-19 13:06 (UTC)

@Rhinoceros - I finally got screen sharing to work under KDE with Wayland. Looks like I'm using the same versions as you:

  • Zoom 6.2.10
  • pipewire 1.2.6

I followed the Screen share section on the Zoom wiki page:

https://wiki.archlinux.org/title/Zoom_Meetings

The only thing I didn't need to do was set XDG_CURRENT_DESKTOP=gnome. I followed the other steps, and now I can choose my desktop/window to share. Prior to following the wiki I couldn't stop screen sharing without the hanging issue, which I was experiencing prior to 6.2.10.

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 .. 37 38 39 40 41 42 43 44 45 46 47 .. 83 Next › Last »

mvdan commented on 2021-10-07 09:15 (UTC)

I've also been running Zoom with xwayland for over a year now - their Wayland support just crashes too easily. At every major release I try Wayland again, and it just crashes again :)

nadavz commented on 2021-10-07 09:12 (UTC)

I've fixed many Wayland related crashes by changing Zoom to use X11. cp /usr/share/applications/Zoom.desktop ~/.local/share/applications/ and apply

< Exec=/usr/bin/zoom %U
---
> Exec=env QT_QPA_PLATFORM=xcb /usr/bin/zoom %U

pintert3 commented on 2021-10-03 18:59 (UTC)

@je-vv thanks for your suggestions, I tried most of them but none in particular made immediate impact, however, I believe it was probably a sort of glitch when some hosts added me to a meeting. If the host ever went offline, the problem would clear from that point onwards. The last update cleared the issue. Thanks again

sispus commented on 2021-09-30 07:11 (UTC)

hi, I am unable to get sound in zoom with pipewire on archlinux. As hv15 says, changing the line system.audio.type=default to system.audio.type=alsa in ~/.config/zoomus.conf works. However, I cannot use bluetooth headphones, it requires bluetooth to connect for alsa ( using bluez-alsa ) package and make necessary configurations (which results not to use pipewire for bluetooth).

Are there anyone use pipewire without problem?

openmindead commented on 2021-09-25 16:05 (UTC) (edited on 2021-09-25 16:07 (UTC) by openmindead)

Speaking of ibus dependency: fcitx5 works with Zoom just fine. So there's no need to force ibus to be installed as Zoom's dependency. Those who use it already have it installed right? And as of now those who don't use it just get a bunch of extra useless packages.

async commented on 2021-09-23 19:50 (UTC)

I looked through some of the recent comments and didn't see anything about this.. after a recent update, Zoom is now adjusting the volume of my microphone down to near-zero each time I join a call. It is driving me absolutely crazy.

I am using zoom-firejail.. combined with recent updates, I'm thinking it may have introduced a bug?

edh commented on 2021-09-22 20:27 (UTC)

Yes! Finally! I have been patiently waiting for a new release to free me from the current situation! :)

zeroconf commented on 2021-09-22 14:52 (UTC)

Zoom 5.8.0 has arrived - https://zoom.us/download#client_4meeting Appreciate, that available at Arch!

bulletmark commented on 2021-09-21 22:23 (UTC) (edited on 2021-09-21 22:26 (UTC) by bulletmark)

@alerque, why wouldn't that fix it? When this issue arose, the checksum could have just been updated (for the new binary), along with a pkgrel bump, and all of this drama would have been averted. Marking it version 5.7.6.a is less semantically correct because it implies an upstream version number change, which did not occur.

alerque commented on 2021-09-21 22:05 (UTC)

@bulletmark Bumping the pkgrel would not fix this, nor would it be semantically correct.

@edh Marking this as 5.7.6.a isn't a bad option actually. I don't think many who have already built this will care about doing so again, most are going to be using AUR helpers anyway that will just take care of it.