Arch Linux User Repository

Before marking the package out of date, please first check that the new version is not a pre-release. I'm tracking releases, not pre-releases.

Talk to community members here:

https://matrix.to/#/#teams-for-linux_community:gitter.im

Can you make it so that it uses electron34 ? Thank you

@je-vv, you gave me an idea that might have resolved the camera issue. I opened up chromium, signed into teams, and then granted it full camera permissions. Opened teams-for-linux and the camera is working fine now.

FYI just tested teams-for-linux 1.12.7-1 and the camera is working fine.

@xamindar, what Ismael actually replied is that he won't pay attention to a build he doesn't generate. I really dislike this sort of answers, since now it seems the tendency is being like windows releases, a binary provided through some app store and the ability to build doesn't matter, not sure if that actually makes the apps not really free/libre software at least, since one need to be able to build. Rant apart, it's not related with the AUR build, see what he also answered:

they have the same problem in the browser/PWA what means @otaolafranc issue is a microsoft or os configuration

And the OP who he's willing to provide support to just showed up saying he keeps getting the same issue on supported flatpak build.

My suggestion is to keep paying attention to that issue, and revert to the prior version if that was working fine. I don't use a camera so I can't confirm, but I bet the issue is there as the OP indicates. Now I suspect that's something on the chromium side having weird effects on electron, or electron itself for that matter. If you run teams under firejail or some sort of sandbox, perhaps it's worth looking it's profile, to see if camera is block...

This build can not use the camera. It says it has no permission to use it. Maintainer says it is the fault of the AUR package maintainer: https://github.com/IsmaelMartinez/teams-for-linux/issues/1567#issuecomment-2679793833

Any idea how to grant camera permission to it?

Weird @carlosnewmusic, it builds fine on two computers. What I could see from the log you posted is trying to create a new directory over a read-only FS:

npm error code 1
npm error path /var/cache/private/pamac/teams-for-linux/src/teams-for-linux-1.12.6/node_modules/electron
npm error command failed
npm error command sh -c node install.js
npm error Error: EROFS: read-only file system, mkdir '/.cache'

It might be an artifact from pamac, which I don't use, but why trying to create a cache directory in the root directory (/), no non-root user should be able to create directories there, but again I'm not clear what is pamac trying to do there. Can you try plain makepkg? I use aurutils to help me out, which directly uses makekpkg. Greetings !

build error https://pastebin.com/DxHZzPMi

@ogarcia and @pschichtel, there's no need for that makepkg option, it doesn't belong to the package. As packagers (AUR users become packagers of our own systems I guess) we control that through /etc/makepkg.conf:

#########################################################################
# GLOBAL PACKAGE OPTIONS
#   These are default values for the options=() settings
#########################################################################
#
# Makepkg defaults: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug !lto !autodeps)
#  A negated option will do the opposite of the comments below.
#
#-- strip:      Strip symbols from binaries/libraries
#-- docs:       Save doc directories specified by DOC_DIRS
#-- libtool:    Leave libtool (.la) files in packages
#-- staticlibs: Leave static library (.a) files in packages
#-- emptydirs:  Leave empty directories in packages
#-- zipman:     Compress manual (man and info) pages in MAN_DIRS with gzip
#-- purge:      Remove files specified by PURGE_TARGETS
#-- debug:      Add debugging flags as specified in DEBUG_* variables
#-- lto:        Add compile flags for building with link time optimization
#-- autodeps:   Automatically add depends/provides
#
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug lto)

Currently that also has the side effect of generating an extra package with debug symbols, and I guess it's not something one wants generally speaking, but again the package should not be aware of this, neither be forced to it, since that'll leave the user with no option at all. Granted the user can edit the PKGBUILD, but the same applies for either case, debug or !debug, so I don't thing that belongs in the PKGBUILD.

@ogarcia Can you refer to packaging documentation that recommends this? Otherwise I'm leaving the decision to the people building the package, whether they want -debug packages or not.

@jijojosephk or @pschichtel, please add options=('!debug') before source line to avoid the creation of the debug package (unnecessary in this case) when you makepkg :-)