Element is offline after the first log on

[Ithvr]

Steps to reproduce

1. Log on the client for the first time
2. Verify the client
3. Restart the client

Outcome

What did you expect?

I expect that when I start Element that I get log on as normal

What happened instead?

Everything works fine when I log on Element Desktop the first time, but after I restart the client is stuck being offline telling that "Connectivity to the server has been lost." I know the server is working well since it works on other clients, and the browser version of element

Operating system

OpenSUSE Tumbleweed

Application version

Element-Desktop 1.11.15

How did you install the app?

OpenSUSE repository

Homeserver

element.ithvr.no

Will you send logs?

Yes

[N0Manches]

I have the same error on opensuse tumbleweed for weeks. Tried to delete all configs, reinstall... nothing works.

Clicking on "Help & About" just closes the window.

Information for package element-desktop:
----------------------------------------
Repository     : openSUSE-Tumbleweed-Oss
Name           : element-desktop
Version        : 1.11.17-1.1
Arch           : noarch
Vendor         : openSUSE
Installed Size : 4.0 MiB
Installed      : Yes
Status         : up-to-date
Source package : element-desktop-1.11.17-1.1.src
Upstream URL   : https://github.com/vector-im/element-desktop
Summary        : A glossy Matrix collaboration client - desktop
Description    : 
    A glossy Matrix collaboration client - desktop

openSUSE Tumbleweed 20230110

When I try to use flatpak or the PWA with ungoogled-chromium I am logged out as soon the process is terminated. So it also does not work on Fedora.

Really annoying... atm I can only use the web version in the browser on all my operating system I use. (Of course the other version are also web versions... but I think one can understand the point...)

[t3chguy]

I suggest reporting this upstream to the OpenSUSE package (community) maintainer. It isn't one we package & support

[N0Manches]

It is a pity that only debian based distros are officially supported :(.

So on debian based distros everything works fine? There is no spam on your server requests?

M_MISSING_TOKEN: MatrixError: [401] Invalid Authorization header.

In another thread someone explained that sometimes (sometimes is not the case for me here) a key... is incorrectly saved in the Browser IndexedDB.

[t3chguy]

@N0Manches that can happen if your keyring isn't available when the app launches, so the key to unlock idb is missing

[N0Manches]

found the others https://github.com/vector-im/element-desktop/issues/1079 https://github.com/vector-im/element-web/issues/18584

But of course I verified it with my Android phone then everything works fine until I restart the application, everytime. No idea what I could do differently. But what is a bit strange to me that I need to verify it twice first it asked for the keys desktop -> android. Afterwards my phone says there is a new device android -> desktop. Is that normal? The verification process with the qr code are both the same.

[AUSBird]

I'm also having the same issue. I login and it works until the application restarts when the whole app just wont connect.

My console output after restarting gives me this

Keytar isn't installed; secure key storage is disabled.
Seshat isn't installed, event indexing is disabled.
/home/ausbird/.config/Element exists: yes
/home/ausbird/.config/Riot exists: no
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change
Resetting the UI components after locale change
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[19320:0116/080329.443447:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[19383:0116/080329.500425:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change

I noticed it mentions Keytar isn't installed; secure key storage is disabled., is this potentially part of a cause for the issue?

[subscribernamegoeshere]

where would i find this keytar message? my ctrl shift i from inside element-desktop client on this opensuse 15.4 machine doesnt show keytar error. those look like very early-on messages from a log, but i can only just as fast press ctrl+shift+i and eventually only kind of see later bootstrapping messages of this element-desktop client?

I see stuff like the following:

.... rageshake.ts:73 Restoring session for @subscribernamegoeshereyougettheidea:matrix.org rageshake.ts:73 setLoggedIn: mxid: @subscribernamegoeshereyougettheidea:matrix.org deviceId: DEVICEIDHERE000000 guest: false hs: https://matrix-client.matrix.org/ softLogout: false freshLogin: false .... rageshake.ts:73 StorageManager: Checking storage consistency rageshake.ts:73 StorageManager: Local storage supported? true rageshake.ts:73 StorageManager: IndexedDB supported? true rageshake.ts:73 StorageManager: Local storage contains data? true rageshake.ts:73 StorageManager: Crypto initialised? true rageshake.ts:73 StorageManager: Sync store using IndexedDB contains data? true rageshake.ts:73 StorageManager: Crypto store using IndexedDB contains data? true rageshake.ts:73 StorageManager: Storage consistency checks passed rageshake.ts:73 Expected a pickle key, but none provided. Encryption may not work. ..... rageshake.ts:73 Session persisted for @subscribernamegoeshereyougettheidea:matrix.org rageshake.ts:73 Lifecycle: Starting MatrixClient rageshake.ts:73 EventIndex: Event indexing isn't installed for the platform, not initializing. rageshake.ts:73 IndexedDBStore.startup: connecting to backend rageshake.ts:73 MatrixClientPeg: waiting for MatrixClient store to initialise rageshake.ts:73 StorageManager: Persistent? true rageshake.ts:73 Switching to room id ROOMID1GOESHERE:matrix.org at event undefined rageshake.ts:73 IndexedDB worker is ready logger.ts:46 LocalIndexedDBStoreBackend.connect: connecting... logger.ts:46 LocalIndexedDBStoreBackend.connect: awaiting connection... logger.ts:46 LocalIndexedDBStoreBackend.connect: connected logger.ts:46 LocalIndexedDBStoreBackend: loading account data... logger.ts:46 LocalIndexedDBStoreBackend: loading sync data... logger.ts:46 LocalIndexedDBStoreBackend: loaded sync data logger.ts:46 LocalIndexedDBStoreBackend: loaded account data logger.ts:46 LocalIndexedDBStoreBackend: loaded initial data rageshake.ts:73 IndexedDBStore.startup: loading presence events rageshake.ts:73 IndexedDBStore.startup: processing presence events rageshake.ts:73 Crypto: Starting up crypto store... rageshake.ts:73 connecting to indexeddb matrix-js-sdk:crypto rageshake.ts:73 connected to indexeddb matrix-js-sdk:crypto rageshake.ts:73 Crypto: initialising roomlist... rageshake.ts:73 Crypto: initialising crypto object... rageshake.ts:73 Crypto: initialising Olm... rageshake.ts:73 Crypto: initialising Olm device... rageshake.ts:73 Unable to initialise e2e Error: OLM.BAD_ACCOUNT_KEY .......

[AUSBird]

I ran the element app from a terminal and it gave me that output

On Sat, Jan 21, 2023 at 10:07 PM subscribername goes here < @.***> wrote:

where would i find this keytar message? my ctrl shift i from inside element-desktop client on this opensuse 15.4 machine doesnt show keytar error. those look like very early-on messages from a log, but i can only just as fast press ctrl+shift+i and eventually only kind of see later bootstrapping messages of this element-desktop client?

I see stuff like the following:

.... rageshake.ts:73 Restoring session for @subscribernamegoeshereyougettheidea: matrix.org rageshake.ts:73 setLoggedIn: mxid: @subscribernamegoeshereyougettheidea: matrix.org deviceId: DEVICEIDHERE000000 guest: false hs: https://matrix-client.matrix.org/ softLogout: false freshLogin: false .... rageshake.ts:73 StorageManager: Checking storage consistency rageshake.ts:73 StorageManager: Local storage supported? true rageshake.ts:73 StorageManager: IndexedDB supported? true rageshake.ts:73 StorageManager: Local storage contains data? true rageshake.ts:73 StorageManager: Crypto initialised? true rageshake.ts:73 StorageManager: Sync store using IndexedDB contains data? true rageshake.ts:73 StorageManager: Crypto store using IndexedDB contains data? true rageshake.ts:73 StorageManager: Storage consistency checks passed rageshake.ts:73 Expected a pickle key, but none provided. Encryption may not work. ..... rageshake.ts:73 Session persisted for @subscribernamegoeshereyougettheidea: matrix.org rageshake.ts:73 Lifecycle: Starting MatrixClient rageshake.ts:73 EventIndex: Event indexing isn't installed for the platform, not initializing. rageshake.ts:73 IndexedDBStore.startup: connecting to backend rageshake.ts:73 MatrixClientPeg: waiting for MatrixClient store to initialise rageshake.ts:73 StorageManager: Persistent? true rageshake.ts:73 Switching to room id ROOMID1GOESHERE:matrix.org at event undefined rageshake.ts:73 IndexedDB worker is ready logger.ts:46 LocalIndexedDBStoreBackend.connect: connecting... logger.ts:46 LocalIndexedDBStoreBackend.connect: awaiting connection... logger.ts:46 LocalIndexedDBStoreBackend.connect: connected logger.ts:46 LocalIndexedDBStoreBackend: loading account data... logger.ts:46 LocalIndexedDBStoreBackend: loading sync data... logger.ts:46 LocalIndexedDBStoreBackend: loaded sync data logger.ts:46 LocalIndexedDBStoreBackend: loaded account data logger.ts:46 LocalIndexedDBStoreBackend: loaded initial data rageshake.ts:73 IndexedDBStore.startup: loading presence events rageshake.ts:73 IndexedDBStore.startup: processing presence events rageshake.ts:73 Crypto: Starting up crypto store... rageshake.ts:73 connecting to indexeddb matrix-js-sdk:crypto rageshake.ts:73 connected to indexeddb matrix-js-sdk:crypto rageshake.ts:73 Crypto: initialising roomlist... rageshake.ts:73 Crypto: initialising crypto object... rageshake.ts:73 Crypto: initialising Olm... rageshake.ts:73 Crypto: initialising Olm device... rageshake.ts:73 Unable to initialise e2e Error: OLM.BAD_ACCOUNT_KEY .......

— Reply to this email directly, view it on GitHub https://github.com/vector-im/element-desktop/issues/850, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWKI2NJ7GQR6KXIIKEWZJTWTPGRJANCNFSM6AAAAAATCTAQXI . You are receiving this because you commented.Message ID: @.***>

[subscribernamegoeshere]

I ran the element app from a terminal and it gave me that output

thanks for this information. by the way did you already file a bugreport with opensuse folks for this situation or anyone in here to really get this stuff solved on the opensuse platforms? thanks.

[asdil12]

The keytar and Seshat messages are unrelated. They are, because on openSUSE element-desktop is build without native bindings that would allow searching for messages. This is because of the abysmal node/cargo build process not being easy to run in the secure build environment that doesn't have internet access.

I have to say that I don't run into this issues on tumbleweed. This is my startup log:

Keytar isn't installed; secure key storage is disabled.
Seshat isn't installed, event indexing is disabled.
/home/MYUSER/.config/Element exists: yes
/home/MYUSER/.config/Riot exists: no
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to de
Fetching translation json for locale: de
Resetting the UI components after locale change
Resetting the UI components after locale change
Changing application language to de
Fetching translation json for locale: de
Resetting the UI components after locale change

[subscribernamegoeshere]

i am far from being technically knowledgeable about all of this, i dont build my software on my own. coming back to this logged out state after every restart of the element application, what is the actual root cause that opensuse vendor and their compilation does have this bug? is this already known? will opensuse ever again have a working and lasting element application? what was different in december or november of last year that their compiled and built application worked normally and now does not any more? any real answers to this?

[asdil12]

The problem is that I cannot reproduce this issue on my tumbleweed installation.

You could try to delete your .config/Element directory and start with a fresh config. (Make sure you have a different client still logged in to keep your encrypted chats). Also you could create a test account on a different server and see if the issue only appears on that particular server.

[subscribernamegoeshere]

doesnt help at all removing the .config/Element/ folder. the client re-logs in and re-verfiies with other existing devices.

upon first shutdown of the new opensuse logged-in instance newly creasted device id and all, it is immediately offline for good upon the next re-start of this client. once again. all the same.

how are we gonna figure out whats happening? please solve this. :( p,s, but this is open suse 15.4 x64 over here not tumbleweed. also this uses matrix.org simple username password account. what i remember maybe changed around the very end of last year is that for the first time i have had a second fellow participant chat with a second person via matrix and this user created a very new user account on matrix.org and this chat was immediately kind of end to end encrypted or was forced to this setting by this other party. my other chats to one other person is not yet end to end encrypted. thats the only thing i remember.

also the newly created linux client shows this one settings complaint in the security area that components would be missing to be able to search through end to end encrypted messages or so it complains in that one area with explanatory text or something on how to build the client or what components would be missing. maybe this is another hint.

[asdil12]

I'm sorry but I only package that software for openSUSE and have no idea about the inner workings of element. This sounds like a bug in element that only appears under very specific circumstances that I can't even reproduce.

I can only recommend you to try a different matrix client. Nheko is in the openSUSE repos and works pretty well.

[subscribernamegoeshere]

wow this is no good answer at all, we are all bugreporting a bug about the element client here, the solution should not be to disregard a bug and abandon ship :(

how do we work to solve this stuff? what can be next steps in the proper direction?

[subscribernamegoeshere]

can you please create yourself a test account on matrix.org to use the same server and backend situation? and on leap 15.4 . i have added this single repository

https://download.opensuse.org/repositories/devel:/languages:/nodejs/15.4/

and I guess these three packages are being used from that rpm-md repo

element-desktop-1.11.20-lp154.1.1.noarch element-web-1.11.20-lp154.2.1.noarch nodejs-electron-22.1.0-lp154.1.1.x86_64

thanks for looking into this matter. it was working happily for a long time on 15.4 but now it does not :(

[subscribernamegoeshere]

one other thing that strikes me odd is that a simple not logged in element desktop client only showing the basic matrix.org landscape scene fotography with the login signup etc buttons would not load of this element desktop application is pinned to the taskmanager area and thus being automatic started when the kde desktop of the opensuse 15.4 starts for the normal user session. when there having a basic simple wifi connection that is slow to establish or taking a while to acquire ip addresses and all this element desktop application shows in its fullscreen window that something is wrong and it could not resolve element.io and it should be restarted and what not. so even the basic starting up of an non logged in element desktop application (client) is not robust enough to handle non networking and non online states of the machine when the networking connection the internet connection is not yet established, cut, broken or dns servers are not responding yet etc.

is it maybe possible as my opensuse 15.4 element-desktop was always in the automagic startup when it tries to reestablish the user account it maybe first quickly fails to get hold of ip addresses dns results and what not then somehow yanks all this information or parts of the authentication headers cookies or session states or whichever exact technical details and then lands in this failed state of profile or user account and user session of the matrix.org account, and when shortly thereafter the networking layers of the machine are there and fully established the session is already hosed and borked and of no use any more?

just an idea. please look into this bug. why would opensuse 15.4 users be left out in the dark and have no real working element-desktop client any more? this cant be state of the art for the opensuse 15.4 platform and this cant be a serious thing going on that a user needs to endure these days. can it? thanks

btw, a native firefox (rpm) on opensuse 15.4 can happily run a matrix-web (surfing element.io) way to connect to the matrix.org backend and this session happily works, survives firefox shutdowns, machine shutdowns, machine reboots and all that. as it ought to be.

what now? thanks.

[subscribernamegoeshere]

still all the same tried over again everything with currently:

element-desktop-1.11.22-lp154.1.1.noarch element-web-1.11.22-lp154.1.1.noarch nodejs-common-5.0-150400.1.4.x86_64 nodejs16-16.18.1-150400.3.12.1.x86_64 nodejs-electron-22.2.1-lp154.3.1.x86_64

opensuse 15.4 is only able to have a matrix element client running from within a webbrowser. so sad :(

[subscribernamegoeshere]

still defunct after todays rpm

element-web-1.11.23-lp154.1.1.noarch element-desktop-1.11.23-lp154.1.1.noarch nodejs-common-5.0-150400.1.4.x86_64 nodejs16-16.18.1-150400.3.12.1.x86_64 nodejs-electron-22.2.1-lp154.3.1.x86_64

[barathrm]

Same issue, also opensuse tumbleweed, KDE. kwallet is open. Same logs as others.

• Tried removing ~/.config/Element
• Tried removing ~/.pki

Related?

• https://github.com/vector-im/element-web/issues/18584#issuecomment-1046303527
• https://github.com/vector-im/element-desktop/issues/849

element.log

[subscribernamegoeshere]

thanks for further participants in this bug. is it maybe possible that a security store (kde wallet?) is involved in this issue? although my kde wallet (same here) does not show any access or prompt when element desktop on opensuse leap 15.4 is running or starting. my kde wallet is also not automatically unlocked and needs a password.

at present this kde wallet only seems to store wifi credentials. thanks.

[subscribernamegoeshere]

okay this is still the same, with:

element-desktop-1.11.26-lp154.1.1.noarch element-web-1.11.26-lp154.2.1.noarch

nodejs16-16.19.1-150400.3.15.1.x86_64 nodejs-common-5.0-150400.1.4.x86_64 nodejs-electron-22.3.4-lp154.1.1.x86_64

---

invalid authorization header after returing to this client / instance. no connection possible. okay seriously, will this ever be investigated any further? what can we as users do more?

it seems as if opensuse platform is kind of becoming abandonware and steering itself in very differnt directions from where it has once been, what I read at various places but thats another story I guess.

[t3chguy]

@subscribernamegoeshere have you reported it to the community maintainer of your package?

[AUSBird]

Update from me, I’m not sure if this will help others but I updated my homeserver to the latest version available (Cant remember what version I was on but can get that info later, this was a few weeks ago) and it works for me now.

I don’t know why the client wasn’t saving keys, but to my surprise the server update fixed the client

shrugs

On Thu, 30 Mar 2023 at 1:59 am, Michael Telatynski @.***> wrote:

@subscribernamegoeshere https://github.com/subscribernamegoeshere have you reported it to the community maintainer of your package?

— Reply to this email directly, view it on GitHub https://github.com/vector-im/element-desktop/issues/850, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWKI2MB3OOFZZSEFTVBRZTW6RL7FANCNFSM6AAAAAATCTAQXI . You are receiving this because you commented.Message ID: @.***>

[subscribernamegoeshere]

updated what exactly on your homeserver? the element packages? anyhow, this machine with KDE desktop auto-starts element desktop application ( element-desktop-1.11.26-lp154.1.1.noarch ) automatically after a full shutdown and reboot thereafter. Upon login of the normal user into the KDE, the desktop gets restored, some simple "konsole" application starts at my machine and the element desktop app appears immediately complaining about:

Failed to start Your Element is misconfigured Unexpected error resolving homeserver configuration Go to element.io

as this machine has wireless access and the wifi connection doesnt come up and get connected as quickly and it does not have ip stack and its own address and route to public internet immediately.

is this maybe a hint as well to shortcoming of this opensuse element-desktop built binaries and package and so? maybe this situation gives additional hints into some causes why authentication headers or basic connection does not succeed or why some stages of the handshake with the element/matrix backend servers are failing or missing or something in this regard?

thanks.

[subscribernamegoeshere]

@subscribernamegoeshere have you reported it to the community maintainer of your package?

If I understand this thread and its participants posting right, https://github.com/asdil12 @asdil12 is actually the? or some package maintainer of the element stuff for open/suse and he is aware of the situation or something?

i am only participating in this issue here on github in this bug and my other one I already referenced in this thread thanks.

[asdil12]

is this maybe a hint as well to shortcoming of this opensuse element-desktop built binaries and package and so? maybe this situation gives additional hints into some causes why authentication headers or basic connection does not succeed or why some stages of the handshake with the element/matrix backend servers are failing or missing or something in this regard?

This is something I can actually help with:

You could use this script to wait for internet access and only afterwards start element-desktop:

for i in {1..300} ; do ping -c1 opensuse.org && break ; sleep 1 ; done
element-desktop

[subscribernamegoeshere]

i wonder utmostly how can the internationally? famous? distribution named suse be in such disarray that a simple? open source project like this matrix element client does not run on it and is in such elementary shattered state after every shutdown of the application. i guess its time to abandon ship. opensuse is just not the distro to run.

still authentication header errors for months now currently at:

element-web-1.11.30-lp154.2.1.noarch element-desktop-1.11.30-lp154.1.1.noarch nodejs-common-5.0-150400.1.4.x86_64 nodejs-electron-22.3.6-lp154.3.1.x86_64 nodejs16-16.20.0-150400.3.18.2.x86_64

[UkeHa]

I'm also affected by this issue on latest suse tumbleweed. Using the flatpak version shuts down after a couple of seconds, using the distro version works flawlessly but forgets the login every time the application is restarted.

[t3chguy]

Sounds like an issue with the keyring access, I suggest opening a ticket with that package's maintainer

[subscribernamegoeshere]

t3chguy, what keyring stuff is this about exactly? the element desktop local native app (.rpm) on opensuse 15.4 never asked me for any kde wallet (?) or whatever if thats what you mean? i am not an expert about this. how can we progress? maybe we are lucky now that also the grand tumbleweed would be affected by this bug, maybe some opensuse fellas will become busy at last? wondering :(

[t3chguy]

@subscribernamegoeshere Element Desktop uses Keytar to store secrets in your keyring, those secrets are used to encrypt/pickle things in IndexedDB such as your Access Token, if accessing your keyring fails your token may end up wrongly unpickled and thus you cannot authenticate to your server. The opensuse and flatpak apps are community maintained, you'd need to ask them for help with this.

[LeoniePhiline]

Hi! Also openSUSE Tumbleweed here, and same problem. The console output says keytar is in fact not used (not installed) (notably, keytar is not even maintained any more):

$ element-desktop
Keytar isn't installed; secure key storage is disabled.
Seshat isn't installed, event indexing is disabled.
/home/leonie/.config/Element exists: yes
/home/leonie/.config/Riot exists: no
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change
Resetting the UI components after locale change
Changing application language to en-us
Fetching translation json for locale: en-us
Resetting the UI components after locale change

Relevant lines:

• https://github.com/vector-im/element-desktop/blob/a6e175268ec2f7e849fd2c3ff5a5cbcba525bdca/src/keytar.ts#L25
• https://github.com/vector-im/element-desktop/blob/a6e175268ec2f7e849fd2c3ff5a5cbcba525bdca/src/seshat.ts#L44

Is this in indication that...:

• the error lies in keytar not being installed?
• or does this indicate the error must in fact lie somewhere else, since keytar isn't even in use?

---

By the way, --devtools do not work:

$ element-desktop --devtools
Keytar isn't installed; secure key storage is disabled.
Seshat isn't installed, event indexing is disabled.
/home/leonie/.config/Element exists: yes
/home/leonie/.config/Riot exists: no
Error: Cannot find module 'electron-devtools-installer'
Require stack:
- /usr/share/element/app.asar/lib/electron-main.js
- /usr/lib64/electron/resources/default_app.asar/main.js
- 
    at Module._resolveFilename (node:internal/modules/cjs/loader:963:15)
    at n._resolveFilename (node:electron/js2c/browser_init:2:109751)
    at Module._load (node:internal/modules/cjs/loader:811:27)
    at f._load (node:electron/js2c/asar_bundle:2:13330)
    at Module.require (node:internal/modules/cjs/loader:1035:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at /usr/share/element/app.asar/lib/electron-main.js:380:80
    at Generator.next (<anonymous>)
    at fulfilled (/usr/share/element/app.asar/lib/electron-main.js:46:58) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/usr/share/element/app.asar/lib/electron-main.js',
    '/usr/lib64/electron/resources/default_app.asar/main.js',
    undefined
  ]
}
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change
Resetting the UI components after locale change
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change

---

OpenSUSE factory package is here: https://build.opensuse.org/package/show/openSUSE%3AFactory/element-desktop

@t3chguy Is the build script correct?

https://build.opensuse.org/package/view_file/openSUSE:Factory/element-desktop/element-desktop.spec?expand=1

E.g. is ELECTRON_SKIP_BINARY_DOWNLOAD=1 ok since changes like https://github.com/vector-im/element-desktop/pull/631? Are any modules supposedly downloaded rather than built, which causes them to end up missing with this build script?

I added a comment for the maintainers here: https://build.opensuse.org/package/show/openSUSE:Factory/element-desktop#comment-1787999

---

Notably, the "further upstream" package at https://build.opensuse.org/package/show/devel%3Alanguages%3Anodejs/element-desktop has the same problem.

---

keytar (which is no longer maintained) requires libsecret, which I have installed (i+):

S  | Name                               | Type    | Version    | Arch   | Repository
---+------------------------------------+---------+------------+--------+--------------------------
   | git-credential-libsecret           | package | 2.41.0-1.1 | x86_64 | Main Repository (OSS)
   | git-credential-libsecret           | package | 2.41.0-1.1 | x86_64 | openSUSE:Tumbleweed
   | git-credential-libsecret           | package | 2.41.0-1.1 | x86_64 | openSUSE:Tumbleweed
   | git-credential-libsecret           | package | 2.41.0-1.1 | x86_64 | openSUSE-20230612-0
   | git-credential-libsecret-debuginfo | package | 2.41.0-1.1 | x86_64 | openSUSE-Tumbleweed-Debug
i+ | libsecret-1-0                      | package | 0.20.5-1.5 | x86_64 | Main Repository (OSS)
i+ | libsecret-1-0                      | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
i+ | libsecret-1-0                      | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
i+ | libsecret-1-0                      | package | 0.20.5-1.5 | x86_64 | openSUSE-20230612-0
   | libsecret-1-0-32bit                | package | 0.20.5-1.5 | x86_64 | Main Repository (OSS)
   | libsecret-1-0-32bit                | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
   | libsecret-1-0-32bit                | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
   | libsecret-1-0-32bit                | package | 0.20.5-1.5 | x86_64 | openSUSE-20230612-0
   | libsecret-1-0-32bit-debuginfo      | package | 0.20.5-1.5 | x86_64 | openSUSE-Tumbleweed-Debug
   | libsecret-1-0-debuginfo            | package | 0.20.5-1.5 | x86_64 | openSUSE-Tumbleweed-Debug
   | libsecret-debugsource              | package | 0.20.5-1.5 | x86_64 | openSUSE-Tumbleweed-Debug
   | libsecret-devel                    | package | 0.20.5-1.5 | x86_64 | Main Repository (OSS)
   | libsecret-devel                    | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
   | libsecret-devel                    | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
   | libsecret-devel                    | package | 0.20.5-1.5 | x86_64 | openSUSE-20230612-0
   | libsecret-lang                     | package | 0.20.5-1.5 | noarch | Main Repository (OSS)
   | libsecret-lang                     | package | 0.20.5-1.5 | noarch | openSUSE:Tumbleweed
   | libsecret-lang                     | package | 0.20.5-1.5 | noarch | openSUSE:Tumbleweed
   | libsecret-lang                     | package | 0.20.5-1.5 | noarch | openSUSE-20230612-0

[t3chguy]

@LeoniePhiline the build script isn't correct, it omits native dependencies

yarn run build:native

is commented out.

This is why there is no keytar & seshat, as for whether that is the issue I would need your element logs (Settings > Help & About) to know

[asdil12]

openSUSE element package maintainer here.

I was finally able to reproduce the issue by deleting my ~/.config/Element/ and logging in again. I was getting this "couldn't connect to server" issue after a restart of element.

I tried with the official static builds, which contain native binaries (see https://packages.element.io/desktop/install/linux/glibc-x86-64/index.html) which worked fine.

So with the help of some outdated comments in some closed issue (https://github.com/vector-im/element-desktop/issues/594#issuecomment-1484614214) and the semi-helpful documentation on native modules (https://github.com/vector-im/element-desktop/blob/develop/docs/native-node-modules.md) as well as some patch that was needed to convince this gyp thing to build keytar…

--- .hak/keytar/x86_64-unknown-linux-gnu/build/node_modules/node-gyp/gyp/pylib/gyp/input.py 2023-06-15 12:09:05.127000000 +0200
+++ .hak/keytar/x86_64-unknown-linux-gnu/build/node_modules/node-gyp/gyp/pylib/gyp/input.py 2023-06-15 13:34:18.969088855 +0200
@@ -1190,7 +1190,7 @@
         else:
             ast_code = compile(cond_expr_expanded, "<string>", "eval")
             cached_conditions_asts[cond_expr_expanded] = ast_code
-        env = {"__builtins__": {}, "v": StrictVersion}
+        env = {"__builtins__": {"openssl_fips": ""}, "v": StrictVersion}

… as well as finding out, how to bundle cargo dependencies, which was surprisingly easy after finding out, where cargo was actually called, I was able to build with native modules within our offline build environment.

I already submitted my changes to the devel project (https://build.opensuse.org/package/rdiff/devel:languages:nodejs/element-desktop?linkrev=base&rev=36), but as the nodejs-electron package was updated today and is currently building, I don't expect anything being built before tomorrow.

In the meantime here is my locally built element-desktop:

element-desktop-1.11.32-0.x86_64.rpm.gz

[LeoniePhiline]

@asdil12 You are THE hero! Thank you so much!

[subscribernamegoeshere]

opensuse leap 15.5 with

element-desktop-1.11.32-lp155.3.1.x86_64 element-web-1.11.32-lp155.1.1.noarch

seems to work stable now.

[subscribernamegoeshere]

this bug / issue probably can be closed (resolved?) now. keeps working with opensuse leap 15.5, current version from today due to CVE

element-desktop-1.11.36-lp155.1.1.x86_64 element-web-1.11.36-lp155.1.1.noarch nodejs-electron-22.3.14-lp155.1.1.x86_64

[sebix]

I can confirm 1.11.34-1.1 on Tumbleweed works too