Filed against bug 713010.
oops sorry
ping.
$ rpm -qpR teams-1.3.00.16851-1.x86_64.rpm says it relies on libsecret and not libgnome-keyring
(In reply to Pacho Ramos from comment #3) > $ rpm -qpR teams-1.3.00.16851-1.x86_64.rpm > > says it relies on libsecret and not libgnome-keyring scanelf -n usr/share/teams/resources/app.asar.unpacked/node_modules/keytar3/build/Release/keytar.node ET_DYN libgnome-keyring.so.0,libstdc++.so.6,libc.so.6
it seems they are packing an old keytar.node version https://github.com/atom/node-keytar/pull/53 For example skype provided keytar.node is using libsecret
(In reply to Pacho Ramos from comment #5) > it seems they are packing an old keytar.node version > https://github.com/atom/node-keytar/pull/53 > > For example skype provided keytar.node is using libsecret More interesting, teams has keytar3 and keytar4 ;) Anyways, I tested teams with libsecret only and it works for me several weeks now.
(In reply to Stephan Hartmann from comment #6) > Anyways, I tested teams with libsecret only and it works for me several > weeks now. Does this mean that you nowhere have libgnome-keyring.so on your system?
When I install teams (from my "seden" overlay via layman) without libgnome-keyring, I get: ----- * Final size of build directory: 249108 KiB (243.2 MiB) * Final size of installed tree: 249104 KiB (243.2 MiB) * QA Notice: Unresolved soname dependencies: * * /usr/share/teams-insiders/resources/app.asar.unpacked/node_modules/keytar3/build/Release/keytar.node: libgnome-keyring.so.0 * ----- I guess we have to wait until https://github.com/MicrosoftDocs/msteams-docs/issues/2039 is resolved.
I do not have libgnome-keyring and have been using teams for a few months now with no problem. I download the teams RPM straight from microsoft.com, extract it into my home directory and run it right from there. I chose to install it this way because the ebuild wanted me to install gnome-keyring.
Could someone clearly confirm that without libgnome-keyring.so* on their system, and disregarding QA notices, Teams do work without it?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e8f8cb5dd48ac39e69d7eb4214063cc98c741d68 commit e8f8cb5dd48ac39e69d7eb4214063cc98c741d68 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2020-09-20 08:04:25 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2020-09-20 08:16:43 +0000 net-im/teams: Remove dep on libgnome-keyring According to the linked bug report, teams work just fine without it. My guess is that upstream supports both libgnome-keyring and libsecret, and dynamically uses whichever is available. Closes: https://bugs.gentoo.org/719922 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-im/teams/{teams-1.3.00.16851.ebuild => teams-1.3.00.16851-r1.ebuild} | 1 - 1 file changed, 1 deletion(-)
To stop emerge complaining about missing libs you should consider deleting the whole keytar3 dir. #keytar3 obsolete, uses libgnome-keyring.so rm -rf "${D}"/usr/share/teams-insiders/resources/app.asar.unpacked/node_modules/keytar3 There is an keytar4 dir too with libsecret.
(In reply to Joakim Tjernlund from comment #12) > To stop emerge complaining about missing libs you should consider deleting > the whole keytar3 dir. > #keytar3 obsolete, uses libgnome-keyring.so > rm -rf > "${D}"/usr/share/teams-insiders/resources/app.asar.unpacked/node_modules/ > keytar3 > > There is an keytar4 dir too with libsecret. This might probably avoid: !!! existing preserved libs: >>> package: gnome-base/libgnome-keyring-3.12.0-r1 * - /usr/lib64/libgnome-keyring.so.0 * - /usr/lib64/libgnome-keyring.so.0.2.0 * used by /usr/share/teams/resources/app.asar.unpacked/node_modules/keytar3/build/Release/keytar.node (net-im/teams-1.3.00.16851-r1) Use emerge @preserved-rebuild to rebuild packages using these libraries
(In reply to Toralf Förster from comment #13) > (In reply to Joakim Tjernlund from comment #12) > > To stop emerge complaining about missing libs you should consider deleting > > the whole keytar3 dir. > > #keytar3 obsolete, uses libgnome-keyring.so > > rm -rf > > "${D}"/usr/share/teams-insiders/resources/app.asar.unpacked/node_modules/ > > keytar3 > > > > There is an keytar4 dir too with libsecret. > > This might probably avoid: > > !!! existing preserved libs: > >>> package: gnome-base/libgnome-keyring-3.12.0-r1 > * - /usr/lib64/libgnome-keyring.so.0 > * - /usr/lib64/libgnome-keyring.so.0.2.0 > * used by > /usr/share/teams/resources/app.asar.unpacked/node_modules/keytar3/build/ > Release/keytar.node (net-im/teams-1.3.00.16851-r1) > Use emerge @preserved-rebuild to rebuild packages using these libraries Yes, that was what I meant. I have deleted the keytar3 here and teams works OK.
(In reply to Joakim Tjernlund from comment #14) > Yes, that was what I meant. I have deleted the keytar3 here and teams works > OK. I have added this for testing to my app-office/teams-insiders ebuild ("seden" overlay) : ( In src_install() : ) -------- # Remove keytar3, it needs libgnome-keyring. keytar4 uses libsecret and is used instead rm -rf "${WORKDIR}/usr/share/teams-insiders/resources/app.asar.unpacked/node_modules/keytar3" || die -------- Then I removed libgnome-keyring, merged that new teams-insiders revision, restarted teams, and it is working just fine since then. I know that issuing an "rm" like that in an ebuild is quite blunt. But for "just testing" it at least worked.