Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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
On Tue, Jul 13, 2021 at 01:23:58PM +0100, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
<...>
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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
On 13/07/2021 15:07, Tru Huynh wrote:
hi
On Tue, Jul 13, 2021 at 01:23:58PM +0100, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
<...>
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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).
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
Cheers
Tru
CentOS mailing list CentOS@centos.org https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cent...
On 13/07/2021 15:07, Tru Huynh wrote:
hi
On Tue, Jul 13, 2021 at 01:23:58PM +0100, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
<...>
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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).
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
On 14/07/2021 09:04, Simon Matter wrote:
On 13/07/2021 15:07, Tru Huynh wrote:
hi
On Tue, Jul 13, 2021 at 01:23:58PM +0100, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
<...>
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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).
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 :)
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
Simon
CentOS mailing list CentOS@centos.org https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cent...
On 14/07/2021 09:04, Simon Matter wrote:
On 13/07/2021 15:07, Tru Huynh wrote:
hi
On Tue, Jul 13, 2021 at 01:23:58PM +0100, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
<...>
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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).
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 :)
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
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 toralf.lund@pgs.com said:
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...
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".
On Wed, 14 Jul 2021, Chris Adams wrote:
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).
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
At Wed, 14 Jul 2021 08:33:42 +0200 CentOS mailing list centos@centos.org wrote:
On 13/07/2021 15:07, Tru Huynh wrote:
hi
On Tue, Jul 13, 2021 at 01:23:58PM +0100, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
<...>
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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).
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...
That assumes that the RPM was *properly* build from source. Many producers of closed source software "cheat" and create RPMs (and/or DEBs) that don't actually have proper dependencies and it might be possible to install software that actually won't work because of missing dependencies or something.
- Toralf
Cheers
Tru
CentOS mailing list CentOS@centos.org https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cent...
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 13/07/2021 14:23, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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.
I can check what version I'm running later for you, if that would be helpful.
Well, it would be kind of interesting...
- T
CentOS mailing list CentOS@centos.org https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cent...
On 14/07/2021 07:28, Toralf Lund wrote:
On 13/07/2021 14:23, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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.
I can check what version I'm running later for you, if that would be helpful.
Well, it would be kind of interesting...
- T
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 pperry@elrepo.org said:
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.
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".
On 15/07/21 8:13 am, Phil Perry wrote:
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)
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
On 15/07/21 4:14 pm, Peter wrote:
Try this installing gcc10-libstdc++ from GhettoForge (https://ghettoforge.org/) and then set LD_LIBRARY_PATH=/opt/gcc-10.2.1
Sorry that's http, not https: http://ghettoforge.org/
Peter
Hello Peter,
On Thu, 15 Jul 2021 16:21:58 +1200 Peter Ajamian peter@pajamian.dhs.org wrote:
On 15/07/21 4:14 pm, Peter wrote:
Try this installing gcc10-libstdc++ from GhettoForge > (https://ghettoforge.org/) and then set LD_LIBRARY_PATH=/opt/gcc-10.2.1
Sorry that's http, not https: http://ghettoforge.org/
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,
On 14/07/2021 22:13, Phil Perry wrote:
On 14/07/2021 07:28, Toralf Lund wrote:
On 13/07/2021 14:23, Phil Perry wrote:
On 13/07/2021 13:02, Toralf Lund wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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.
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.
I can check what version I'm running later for you, if that would be helpful.
Well, it would be kind of interesting...
- T
My currently installed/working version is: # rpm -qa | grep teams teams-1.4.00.7556-1.x86_64
OK. Thanks.
That's the one that works here, obviously.
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)
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
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
CentOS mailing list CentOS@centos.org https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cent...
Le 13/07/2021 à 14:02, Toralf Lund a écrit :
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
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
On Tue, Jul 13, 2021 at 2:03 PM Toralf Lund toralf.lund@pgs.com wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
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
On 15/07/2021 09:37, Gianluca Cecchi wrote:
On Tue, Jul 13, 2021 at 2:03 PM Toralf Lund toralf.lund@pgs.com wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
At the end I think you have something broken with your repo config or you installed forcing something.
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
The repo should be:
[teams] name=teams baseurl=https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpackages.m... enabled=1 gpgcheck=1 gpgkey=https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpackages.m...
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://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpackages.m... 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 _______________________________________________ CentOS mailing list CentOS@centos.org https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cent...
On Thu, 15 Jul 2021 at 05:30, Toralf Lund toralf.lund@pgs.com wrote:
On 15/07/2021 09:37, Gianluca Cecchi wrote:
On Tue, Jul 13, 2021 at 2:03 PM Toralf Lund toralf.lund@pgs.com wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
At the end I think you have something broken with your repo config or you installed forcing something.
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.
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.
On 15/07/2021 12:57, Stephen John Smoogen wrote:
On Thu, 15 Jul 2021 at 05:30, Toralf Lund toralf.lund@pgs.com wrote:
On 15/07/2021 09:37, Gianluca Cecchi wrote:
On Tue, Jul 13, 2021 at 2:03 PM Toralf Lund toralf.lund@pgs.com wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
At the end I think you have something broken with your repo config or you installed forcing something.
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.
That isn't provided..
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.
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.
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.
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)'`
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.
Basically Microsoft teams will need to bundle this newer version of glibc they are using to make your software work.
On 15/07/2021 12:57, Stephen John Smoogen wrote:
On Thu, 15 Jul 2021 at 05:30, Toralf Lund toralf.lund@pgs.com wrote:
On 15/07/2021 09:37, Gianluca Cecchi wrote:
On Tue, Jul 13, 2021 at 2:03 PM Toralf Lund toralf.lund@pgs.com wrote:
Does anyone else run Microsoft Teams on CentOS 7?
I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything.
Has anyone else seen this? Is there anything I can do to make the GUI appear?
This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system.
The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556.
- Toralf
At the end I think you have something broken with your repo config or you installed forcing something.
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.
That isn't provided..
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.
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.
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.
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)'`
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
On 16/07/21 8:41 pm, Simon Matter wrote:
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.
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?
IMHO, if it's like that, then the chrome packages are crap :-)
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.
What happens if you try this:
$ export LD_LIBRARY_PATH=/opt/google/chrome/lib $ teams....
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
On 16/07/21 8:41 pm, Simon Matter wrote:
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.
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?
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.
IMHO, if it's like that, then the chrome packages are crap :-)
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
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.
What happens if you try this:
$ export LD_LIBRARY_PATH=/opt/google/chrome/lib $ teams....
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 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 16/07/21 10:19 pm, Simon Matter wrote:
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?
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.
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.
It may have worked before because older teams required a libstdc++ version which is available on CentOS 7.
Correct.
The broken chrome packages are the reason why RPM allowed the new teams version being installed.
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++).
But because the chrome package doesn't really provide to the systems what it claims,
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 won't work an is in a broken state.
teams should work if LD_LIBRARY_PATH is set appropriately.
Peter
On 16/07/21 10:19 pm, Simon Matter wrote:
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?
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.
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.
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.
It may have worked before because older teams required a libstdc++ version which is available on CentOS 7.
Correct.
The broken chrome packages are the reason why RPM allowed the new teams version being installed.
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++).
But because the chrome package doesn't really provide to the systems what it claims,
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.
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
On 16.07.21 12:39, Simon Matter wrote:
On 16/07/21 10:19 pm, Simon Matter wrote:
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?
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.
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.
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.
$ 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 $
-- Leon
On 16.07.21 12:39, Simon Matter wrote:
On 16/07/21 10:19 pm, Simon Matter wrote:
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?
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.
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.
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.
$ 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/AutoProvidesAndReq... 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
On 16.07.21 13:28, Simon Matter wrote:
On 16.07.21 12:39, Simon Matter wrote:
On 16/07/21 10:19 pm, Simon Matter wrote:
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?
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.
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.
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.
$ 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.
<snip>
That's why teams fails here, Microsoft is NOT the culprit in this case :-)
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 ...
-- Leon
On 16/07/21 10:39 pm, Simon Matter wrote:
And I ask again, how else would you expect the package to satisfy the dependency in chrome for the newer libstdc++?
And yet you still have not answered this question.
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.
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
On 16/07/21 10:39 pm, Simon Matter wrote:
And I ask again, how else would you expect the package to satisfy the dependency in chrome for the newer libstdc++?
And yet you still have not answered this question.
Simple answer: you can NOT without breaking RPMs dependency system.
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.
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."
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
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.
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
-
Chris Adams -
Gianluca Cecchi -
Leon Fauster -
Mark Milhollan -
Nicolas Kovacs -
Peter -
Peter Ajamian
-
Phil Perry -
Robert Heller -
Simon Matter -
Stephen John Smoogen -
Toralf Lund -
Tru Huynh -
wwp