Package Details: zoom 6.2.0-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: 661
Popularity: 8.25
First Submitted: 2015-08-15 13:18 (UTC)
Last Updated: 2024-09-15 14:44 (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 .. 32 33 34 35 36 37 38 39 40 41 42 .. 74 Next › Last »

daniel_shub commented on 2021-08-24 13:51 (UTC)

@edh first, thanks for maintaining the package. I maintain the rememberthemilk package and they pull the same crap of updating the binary without changing the version number. I want to say that I think your approach was almost spot on and what I am going to do in the future. Bumping the pkgrel for a change in the upstream binary is not what pkgrel is designed for while updating the pkgver to trigger a new download and rebuild is the way to go. Had you set pkgver to be 5.7.6.a instead of 5.7.6a, then vercmp would detect the change and everything would be fine. Of course no one should expect a maintainer to nail all the nuances of vercmp and the package build process every time. Again, thanks for maintaining this package.

edh commented on 2021-08-23 22:53 (UTC)

@bulletmark

Sorry, I forgot about the vercmp specifics here. I indeed intended to make the new version large than the one before. However, since the checksum was in a sense outdated, users who did not adapt the PKGBUILD could not upgrade anyways and those who did, do not need upgrade now.

No, this is simply not what pkgrel is for. Upstream updating the binary package is not the same as a mere rebuild with different configuration flags or changes to the PKGBUILD. See @aditya comment on the definition of pkgrel.

The reason why I was reluctant to change the pkgrel is because it does not force users to re-download the binary file. Of course I could have included pkgrel in the target filename but this did not seem proper to me.

bulletmark commented on 2021-08-23 22:10 (UTC)

Adding that 'a' doesn't trigger an update. Upstream has published a new binary so I would say an update is required, i.e. the pkgrel should be updated.

edh commented on 2021-08-23 19:01 (UTC)

@aditya

The PKGBUILD really did not change, i.e. it is not a consecutive build. It is zoom that pushed a new binary package to the same URL.

aditya commented on 2021-08-23 18:48 (UTC) (edited on 2021-08-23 18:50 (UTC) by aditya)

Shouldn't the pkgrel have been bumped instead of adding the "a"?

The release number. This is usually a positive integer number that allows to differentiate between consecutive builds of the same version of a package. As fixes and additional features are added to the PKGBUILD that influence the resulting package, the pkgrel should be incremented by 1. When a new version of the software is released, this value must be reset to 1. In exceptional cases other formats can be found in use, such as major.minor.

From: https://wiki.archlinux.org/title/PKGBUILD#pkgrel

rockneurotiko commented on 2021-08-23 09:31 (UTC) (edited on 2021-08-23 09:32 (UTC) by rockneurotiko)

The checksum of the last release (5.7.6-1) is different than the one specified on the PKGBUILD, maybe they changed the file without releasing a new version?

The sha512 for the file at the moment is 7c34f2f1951a22391ced31960fedba4f1058abf55f1e530b1069bc9b2946f54cd3a12713135ab7ea0ae57131e2ce30521315ce4a67673f7f024cd23f6e03c4be

Edit: I just saw the last comments, just ignore this one

edh commented on 2021-08-23 07:56 (UTC)

@sarovin Zoom changed the package without changing the URL. I'll update the package soon.

sarovin commented on 2021-08-23 07:54 (UTC)

Hi, I have a problem with the sha512sums validation.

:: (1/1) Parsing SRCINFO: zoom
==> Creazione del pacchetto: zoom 5.7.6-1 (lun 23 ago 2021, 09:50:20)
==> Download dei sorgenti in corso...
  -> È stato trovato zoom-5.7.6_orig_x86_64.pkg.tar.xz
==> Validazione di source file con sha512sums...
    zoom-5.7.6_orig_x86_64.pkg.tar.xz ... NON RIUSCITO
==> ERRORE: Uno o più file non hanno superato il controllo di validità!
error downloading sources: zoom

filotek commented on 2021-08-20 00:08 (UTC) (edited on 2021-08-20 00:10 (UTC) by filotek)

The Zoom desktop client isn't calling ::UnInhibit() method (against org.freedesktop.ScreenSaver) via DBUS when the meeting is over and the video window is closed. The call to ::Inhibit() is working fine when the video starts.

For services that observe the DBus calls to org.freedesktop.ScreenSaver (ie. caffeine or xssproxy), without the corresponding ::UnInhibit() call the screensaver stays inhibited, preventing xss-lock from kicking in and locking the screen, even if no video is playing, until the Zoom process is terminated.

I submitted a support request to Zoom, but I thought of mentioning it here in-case someone had some kind of work-around that I'm not aware of. Well... I do have a work-around; it's terminating the Zoom Desktop Client every-time I'm done with a conference call :(

EDIT: Missing DBus reference and grammar.

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