30 thoughts on - Microsoft Teams On CentOS 7. Does The Latest Version Work?

• My wife has been using it on el7, but for the last month or two yum has been complaining about broken dependencies when trying to update it, so I’d disabled the Teams repo from yum updating.

  I can check what version I’m running later for you, if that would be helpful.

• hi

  <...>

  AFAIK, the latest rpm version for c7 is teams-1.4.00.7556-1.x86_64
  after that they only support CentOS-8 for rpm or snap based for c7
  (but one needs to have $HOME under /home).

  Cheers

  Tru

• OK. Do you know what dependencies that might be? Just out of interest…

  I’ve never had any issues like that. Like I said, the latest (?) version installs just fine on my system, it’s just that it doesn’t do anything useful.

  Well, it would be kind of interesting…

  – T

• OK.

  The weird thing here is that the newer version actually installs. If it’s built on/for a later release, I’d normally expect complaints about the libc or libstdc++ version or something along those lines…

  – Toralf

• Hi,

  I’ve seen a lot of commercial software to completely disable the dependency thing in their RPM packages. So you can always install it, it just doesn’t work :)

  Simon

• I guess that’s true.

  But in that situation, you expect runtime errors. In this case, the application doesn’t just install, it also starts and stays running for as long as I care to let it. It just doesn’t do anything useful. Not as far as I can tell, anyway. I guess part of the question was if I’m missing something. Like, perhaps it doesn’t open any windows by default, but there’s some obscure way to make them come up…

  – Toralf

• Maybe the same folks who disabled dependency tracking also disabled logging… Or the software tries to call bluescreen() which obviously doesn’t exist on CentOS :)

  Simon

• Once upon a time, Toralf Lund said:

  Like a number of “desktop apps” for web-based sites, Teams is an Electron app. That means it’s really a package of Chrome plus the site’s client HTML/CSS/JavaScript, so you get all the fun bugs of Chrome (with no way to upgrade it). Microsoft’s RPM does appear to have all the proper RPM dependencies, so that’s probably not the issue (as long as it installs, they should be satisfied).

  Have you run Teams before on this system? If so, I’ve found that it tends to bog down over time, which I suspect is something like it growing a cache without bounds or the like. If that’s the case, I
  suggest removing its data and re-logging in. It looks like that
  “~/.config/Microsoft/Microsoft Teams”.

• Le 13/07/2021 à 14:02, Toralf Lund a écrit :

  For what it’s worth, Teams runs perfectly if you install the Flatpak version. I’m using it under OpenSUSE Leap, but since the purpose of Flatpak is precisely to be distribution-agnostic, you might want to give it a spin with Flatpak under CentOS.

  Extra advantage: potentially intrusive applications like Teams, Skype and Spotify thus get sandboxed in the Flatpak subsystem.

  Cheers,

  Niki

  —
  Microlinux – Solutions informatiques durables
  7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
  Mob. : 06 51 80 12 12

• My currently installed/working version is:
  # rpm -qa | grep teams teams-1.4.00.7556-1.x86_64

  and when I attempt a yum update, I get:

  Resolving Dependencies
  –> Running transaction check
  —> Package teams.x86_64 0:1.4.00.7556-1 will be updated
  —> Package teams.x86_64 0:1.4.00.13653-1 will be an update
  –> Processing Dependency: libstdc++.so.6(CXXABI_1.3.8)(64bit) for package: teams-1.4.00.13653-1.x86_64
  –> Processing Dependency: libstdc++.so.6(CXXABI_1.3.9)(64bit) for package: teams-1.4.00.13653-1.x86_64
  –> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) for package: teams-1.4.00.13653-1.x86_64
  –> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) for package: teams-1.4.00.13653-1.x86_64
  –> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.22)(64bit) for package: teams-1.4.00.13653-1.x86_64
  –> Finished Dependency Resolution Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(GLIBCXX_3.4.20)(64bit)
  Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(CXXABI_1.3.9)(64bit)
  Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(GLIBCXX_3.4.21)(64bit)
  Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(CXXABI_1.3.8)(64bit)
  Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(GLIBCXX_3.4.22)(64bit)

  So Teams now needs a newer version of libstdc++ than that in RHEL7. As others have mentioned, Microsoft clearly do not understand how to package software using RPM and you are probably better off with a snap/flatpak solution.

  –Phil

• Once upon a time, Phil Perry said:

  Umm, I would say that there is a proper dependency on a required library, they do understand how to package software using RPM. They’re just choosing to build on a newer OS version that has dependencies that aren’t handled on CentOS 7.

  I don’t know if they specify supported distributions anywhere (I didn’t find a list in a quick search), so don’t think they claim that CentOS 7
  is supported. I think they just say “here’s an RPM” and “here’s a repo”.

• Try this installing gcc10-libstdc++ from GhettoForge
  (https://ghettoforge.org/) and then set LD_LIBRARY_PATH=/opt/gcc-10.2.1

  If you have a desktop launcher edit the launcher and prefix “env LD_LIBRARY_PATH=/opt/gcc-10.2.1 ” to the command.

  Then see if it works.

  Peter

• Sorry that’s http, not https:
  http://ghettoforge.org/

  Peter

• At the end I think you have something broken with your repo config or you installed forcing something. The repo should be:

  [teams]
  name=teams baseurl=https://packages.microsoft.com/yumrepos/ms-teams enabled=1
  gpgcheck=1
  gpgkey=https://packages.microsoft.com/keys/microsoft.asc

  On a system with Fedora 34 I run without problems teams-1.4.00.13653-1.x86_64 using that repo. Unfortunately the repo itself is distro agnostic in the sense that I see the flat baseurl=https://packages.microsoft.com/yumrepos/ms-teams inside it and there is no check about distro
  (this I think was the note about “not understanding how to package software” pointed out by Phil)

  If I go to an updated CentOS 7.9 system without teams and put the repo file I get this, as other detailed before:

  yum install teams
  . . . Resolving Dependencies
  –> Running transaction check
  —> Package teams.x86_64 0:1.4.00.13653-1 will be installed
  –> Processing Dependency: libstdc++.so.6(CXXABI_1.3.8)(64bit) for package:
  teams-1.4.00.13653-1.x86_64
  –> Processing Dependency: libstdc++.so.6(CXXABI_1.3.9)(64bit) for package:
  teams-1.4.00.13653-1.x86_64
  –> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) for package: teams-1.4.00.13653-1.x86_64
  –> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) for package: teams-1.4.00.13653-1.x86_64
  –> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.22)(64bit) for package: teams-1.4.00.13653-1.x86_64
  –> Finished Dependency Resolution Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(GLIBCXX_3.4.20)(64bit)
  Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(CXXABI_1.3.9)(64bit)
  Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(GLIBCXX_3.4.21)(64bit)
  Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(CXXABI_1.3.8)(64bit)
  Error: Package: teams-1.4.00.13653-1.x86_64 (teams)
  Requires: libstdc++.so.6(GLIBCXX_3.4.22)(64bit)
  You could try using –skip-broken to work around the problem You could try running: rpm -Va –nofiles –nodigest

  But I can run:
  yum install teams-1.4.00.7556-1
  . . . Resolving Dependencies
  –> Running transaction check
  —> Package teams.x86_64 0:1.4.00.7556-1 will be installed
  –> Finished Dependency Resolution

  Dependencies Resolved

  I don’t know if there is a yum option or config parameter to say yum to choose the best version, without depsolve problems, even if not the latest available (in this case teams-1.4.00.7556-1) among the ones found inside a repo…. For sure they could have at least created with minimal effort a tree structure with distro versions and links to corresponding rpm packages, and then use the distroversion and not flat url inside the repo file. And inside the directory for el7 the latest package would have been teams-1.4.00.7556-1, while on CentOS 8 and Fedora I would find also the teams-1.4.00.13653-1

  Gianluca

• OK. Thanks.

  That’s the one that works here, obviously.

  Which I don’t see.

  But I found out what’s going on;

  [toralf@localhost ~]$ rpm -q –whatprovides
  ‘libstdc++.so.6(GLIBCXX_3.4.22)(64bit)’
  chrome-deps-stable-3.13-1.x86_64
  [toralf@localhost ~]$ rpm -ql chrome-deps-stable
  /opt/google/chrome/lib/libgnome-keyring.so.0
  /opt/google/chrome/lib/libstdc++.so.6
  /opt/google/chrome/lib/link-to-libgnome-keyring.so.0
  /opt/google/chrome/modify_wrapper

  The problem is, even though this package “provides” the lib, it’s not available for general use, in that /opt/google/chrome/lib isn’t added to the library path.

  I believe this package was supposed to help you get around some kind of dependency issue with chrome packages from Google a long time ago. Offered as a quick-fix by someone associated with the Fedora project, but probably not included in any of the “usual” repos. I’d quite forgotten that I had this.

  Didn’t think to check this sooner; I guess I assumed that everything would be OK with the dependencies, since the processes did not fail with the runtime linker error you might expect. But I suppose the components are loaded in a somewhat more roundabout way, i.e. the teams executable is not actually linked to the new libstdc++ or anything that uses it.

  – Toralf

• Like I said elsewhere, it turns out that it’s a little more complicated than that. The libraries are actually “provided”, but they’re not on the library path.

  [toralf@localhost ~]$ rpm -q –whatprovides
  ‘libstdc++.so.6(GLIBCXX_3.4.22)(64bit)’

  chrome-deps-stable-3.13-1.x86_64
  [toralf@localhost ~]$ rpm -ql chrome-deps-stable

  [ … ]

  /opt/google/chrome/lib/libstdc++.so.6

  I could of course add an ld.so.conf file or use LD_PRELOAD so that teams would “see” this library.

  – Toralf

• That isn’t provided.. that is a private copy that chrome bundles itself to use. It may or may not have all of the library calls in it
  (the chrome upstream may only turn on things it knows it wants), and it may have changes which the team doesn’t expect.

  Also teams is looking for `rpm -q –whatprovides
  ‘libstdc++.so.6(GLIBCXX_3.4.20)(64bit)’` and you typed
  `rpm -q –whatprovides ‘libstdc++.so.6(GLIBCXX_3.4.22)(64bit)’`

  Basically Microsoft teams will need to bundle this newer version of glibc they are using to make your software work.

• And it is still called a preview. I use the web version, directly, at
  <https://teams.microsoft.com>, so I can update my browser as I desire instead of being stuck with whatever happened to have been packaged until whenever Microsoft gets around to making a new package and decided to update their Electron base.

  /mark

• It’s quite definitely provided. I’m mean in the rpm/package install context, of course, which is what we were discussing.

  The libraries/abi versions are also provided in the sense that the actually exist on my system, event though teams can’t find them right now.

  I think you’re missing my point. The teams install works because the package *claims* that it provides everything teams wants (besides what’s in the “normal” system libs.) Whether it works or not is a different question.

  It most likely will, though, if I set up the necessary LD_PRELOAD etc.
  (haven’t been able to try because I needed to have a Teams version i
  *knew* worked.)  It’s unlikely that there are “changes which the team doesn’t expect”; I’m reasonably sure this is a straight rebuild/repackaging of newer upstream “libstdc++”. It’s also not an integral part of Chrome, but rather a package someone related to the Fedora team made to allow a certain “upstream” versions of chrome to work on a certain “downstream” OS release.

  No, it looks for several different “libstdc++.so.6” versions, and the
  “chrome” package provides them all. I just listed one of them to illustrate the point.

• I’m not sure that’s true. You said your chrome package provides it all but from what I see, it installs its libs into /opt/google/chrome/lib. But, your system doesn’t know about private libs installed in /opt and I think the chrome package should NOT “provide” its private libs in its RPM
  packages.

  IMHO, if it’s like that, then the chrome packages are crap :-)

  What happens if you try this:

  $ export LD_LIBRARY_PATH=/opt/google/chrome/lib
  $ teams….

  Or maybe even add

  $ export LD_PRELOAD=/opt/google/chrome/lib/libstdc++.so.6

  Regards, Simon

• I think you missed from a different post where the package was created by a different 3rd-party, not google. So how else would you expect the
  3rd-party package to satisfy the dependency?

  The chrome packages are not built for CentOS or supported on such, it is coincidence that they happened to have worked in the past. They will continue to work if the libstdc++ dependency is satisfied.

  Better to just do:
  LD_LIBRARY_PATH=/opt/google/chrome/lib teams

  …or if you have a desktop launcher that you use, edit the command and add this to the beginning:

  env LD_LIBRARY_PATH=/opt/google/chrome/lib

  Peter

• I didn’t say the chrome packages came from google. But, the TO has some chrome RPM installed which “provides” the libstdc++ version required by teams, but doesn’t really provide this libstdc++ version to the whole system. That’s why the RPM is broken, it claims to provide a libstdc++
  version which it doesn’t really provide.

  It may have worked before because older teams required a libstdc++ version which is available on CentOS 7.

  The broken chrome packages are the reason why RPM allowed the new teams version being installed. But because the chrome package doesn’t really provide to the systems what it claims, teams won’t work an is in a broken state.

  Did I miss something?

  Simon

• And I ask again, how else would you expect the package to satisfy the dependency in chrome for the newer libstdc++? The package was explicitly created to allow chrome to run on an older system that doesn’t have the newer libstdc++, by rights it should work with other programs that need a newer libstdc++ as well provided that they set LD_LIBRARY_PATH appropriately. So it does, in fact, provide the stated dependency for the entire system, you just have to tell programs that need it where to find it.

  Correct.

  Again, they are not broken, they are suitable for the systems they were built for, which would be current Fedora systems (which happen to have a newer libstdc++).

  You’re confusing here. I assume you mean the package that provides the libstdc++ dependency which happens to have chrome in it’s name but is not actually chrome and does not come from google or chrome.

  teams should work if LD_LIBRARY_PATH is set appropriately.

  Peter

• And that’s where it breaks the rules! It “provides” something that it doesn’t really provide. That’s NOT allowed with RPM because it breaks other applications. It breaks the whole meaning of dependency tracking of the RPM system. That’s why the mentioned chrome package has to be considered broken.

  I don’t know where the package comes from but it’s a broken package and has something with chrome in the name. This package is the reason why the teams RPM can be installed and doesn’t work. Without this broken package the new teams package could NOT have been installed and break.

  Simon

• $ LANG=C rpm -qp –provides https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm warning:
  https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm:
  Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY
  google-chrome = 91.0.4472.164
  google-chrome-stable = 91.0.4472.164-1
  google-chrome-stable(x86-64) = 91.0.4472.164-1
  $

• Hi Leon,

  The problem package is not from google but seems to be
  ‘chrome-deps-stable’ from wherever it comes.

  It provides ‘libstdc++.so.6(GLIBCXX_3.4.22)(64bit)’ which it can NOT
  because it installs its libs in /opt/google/chrome/lib.

  This is all explained in https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
  and this is why the package ‘chrome-deps-stable’ has to be considered broken and actually breaks teams.

  From the above text:
  –%<-------------------------------------- Examples Pidgin plugin package On a x86_64 machine, the pidgin-libnotify provides pidgin-libnotify.so()(64bit) which it shouldn’t as this library is not inside the paths searched by the system for libraries. It’s a private, not global, "provides" and as such must not be exposed globally by RPM. To filter this out, we could use: %global __provides_exclude_from ^%{_libdir}/purple-2/.*\\.so$ --%<-------------------------------------- The 'chrome-deps-stable' RPM should have used '%global __provides_exclude_from ...' to exclude /opt as those libraries are "private, not global, "provides" and as such must not be exposed globally by RPM". That's why teams fails here, Microsoft is NOT the culprit in this case :-) Regards, Simon

• Well, I see a lot of such customer/user behavior: “Doing _everything_
  just to get to the goal”. For example installing things that just do not fit and then wondering about the implications. Imagine a bakery that uses blue wall colour instead blueberrys. Just to get the cup cakes with a blue touch.

  Actually it is a naturally approach to getting things to work. So, not sure whom to blame. For the OP: as someone has already suggested, flatpaks do provide a coherent environment to execute proprietary software. Not sure how mature flatpak is under C7 but teams works here under C8/flatpak well. Alternatively a teams session do also work with the chromium browser directly.

  https://flatpak.org/setup/CentOS/
  https://flathub.org/apps/search/teams

  BTW: @OP Maybe its time to clean up your repository setup and the above mentioned obscure package …

• And yet you still have not answered this question.

  It is not broken, it does exactly what it intends to do. It needs to provide the dependency in order to allow chrome to be installed, and with the usage of the correct LD_LIBRARY_PATH it allows chrome to run on the system where otherwise it would not.

  Yes, it violates the Fedora packaging guidelines, it’s a good thing it’s not a Fedora package, then. Also please note the very first sentence on the main page of the guidelines:

  https://docs.fedoraproject.org/en-US/packaging-guidelines/

  “The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed.”

  Sometimes you have to break some rules to get things to work. In this particular case the results are worth it for a great many people.

  Peter

• Simple answer: you can NOT without breaking RPMs dependency system.

  It has nothing directly to do with Fedora but with RPM – and the Fedora folks have rules not to break RPM. For more info see

  https://rpm.org/user_doc/dependency_generators.html

  If you break it, then don’t wonder why your system doesn’t work as expected. If you break RPMs dependency system by installing broken packages, you get a broken system.

  Simon

• Hello Peter,

  Thanks! It worked here, after adding gf to the local yum’s repo list, installed gcc10-libstdc++, updated teams, and used a wrapper script like to call:
  $ LD_LIBRARY_PATH=/opt/gcc-10.2.1/usr/lib64:$LD_LIBRARY_PATH teams

  Regards,