Arch Linux User Repository

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

The current version number is not the issue here! Zoom released a new binary package under the same seemingly unique URL thereby breaking this package. To correct for this I introduced an artificial version bump. During this step I did a mistake in updating the pkgver and appended an a instead of an .a. Thus, I did not force a rebuild but actually decreased the version number.

For the time being please update manually (e.g. by uninstalling and then re-installing zoom again). The seemingly lower version is actually the most recent version.

Note, while I could still "fix" this by appending the .a, doing so would force everybody who already manually upgrade to rebuild the package as well. In my opinion this bother people unnecessarily who already put in the effort.

@darose I think you're missing the fact that this is a two part problem. There is a general issue of the upstream releases updates without changing the build number and there is a current temporary issue in that this a business missed the necessary segment separator.

Your scheme would be a viable scheme, but it would not solve the problem that upstream keeps changing their package without changing versions. Neither the "5.7.6" version nor the "31753.0818" build data changed when the package was updated last. In other words following your scheme would still have required a .a version bump on the part of this PKGBUILD.

There are ways out of the current mishapp with a instead of the .a that it should have been, but those are temporary and introduce other problems down the road (switching to build numbers means we can't go back to chis schemed when they don't add them properly, and adding an epoch is ugly and confusing).

Just "downgrade" your package to 5.7.6a-1 and move on. The next time around I doubt @edh will make the same mistake.

@edh At your suggestion I went back and read old comments about the versioning. But I still don't understand what the issue is here.

I am currently running zoom 5.7.6 (31753.0818). Current build is 31792.0820. Would it not be possible to change the versioning scheme you're using to change the version number from 5.7.6 to 5.7.6.31753.0818? Then an update to the new build version of 5.7.6.31792.0820 would force an upgrade. Instead I see this:

warning: zoom: local (5.7.6-1) is newer than chaotic-aur (5.7.6a-1)

What am I missing here? Why would that not work?

Sorry for setting the "outdated" flag. I only now read all the discussion :( For reference in case someone stumbles upon this: Uninstalling zoom (5.7.6) and reinstalling zoom (to 5.7.6a) gives you the latest version.

@dack Thank you for you comment. I am aware of the problem. Please read the previous comments. This issue has been extensively discussed. Touching pkgrel is the wrong thing to do here in my opinion.

@edh Appending "a" to the version is a bit of a problem - it results in the wrong version ordering. For example, 1.0.0a is considered earlier than 1.0.0 (you can see this in man vercmp). For AUR helpers like yay, this will cause them to see the "new" version as a downgrade and not upgrade them. I think a better workaround would be to just bump pkgrel. That way it's treated as a newer package, and the upstream version number is kept as-is.

@pinter3, have you tried combinations with pulseaudio-alsa and without it? That might help... Also combining setting and not setting the audio type with those other combinations... With pulseaudio-alsa, no matter your app uses alsa backend, it'll be proxied to pulseaudio. Zoom does work great without pulse, when you do not have pulse at all in your system. Actually I don't use pulse at all, only plain alsa, neither I have ever configured the audio type, and I never had issues with mute/unmute, neither audio in general, but if you use pulse, the best should be for apps to use their pulseaudio backends if available, I'd guess... As an alterantive to plain alsa, and pulse, have you tried using pipewire instead? Perhaps with pipewire-pulse and pipewire-alsa, or a combination of them? The other thing you might try is dropping pulseaudio/pipewire at all, while you figure out the pulseaudio mess with zoom. Zoom is proprietary, so perhaps getting help from them, or a zoom hosted forum might also help get some answers. Proprietary apps are really annoying. I only use zoom given I have no choice at work, :(

Ok, so I'm pretty late to bring this up. And from the comments, a few others have had the same (or similar) issue. But I'm going to be more specific and bring it up again, cause the pinned solution doesn't seem to work for me. So ever since some update I think in June/July, when I enter some meetings not hosted by me, (I'm not yet sure what the criteria is exactly, except that it appears whenever I enter a meeting muted, and I'm not the host), I can't unmute myself to speak, so I basically only the chat bar to talk. I use pulseaudio for sound. I tried changing system.audio.type=default to alsa, but no difference after I restarted zoom. I don't know if there's any other fix, I tried waiting for an update, but no difference, and I'm surely now getting desperate. Do I need to change from pulse audio to something else entirely?

:: Searching AUR for updates... -> zoom: local (5.7.6-1) is newer than AUR (5.7.6a-1)

yay seems to think that 5.7.6a-1 is older than 5.7.6-1

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