Arch Linux User Repository

@Edu4rdSHL, It fixed my issue, now working! What's weird, the screen sharing was working out of the box for me on flatpak. Though, Vesktop itself was loading for ages, so this is working much better for me. Thank you for your work!

Ok, I experienced the issue itself. There was some Discord ¿? update that broke it. If you go to the app settings, you will not see anything related to Vesktop but only Discord, as if it has overwritten the whole Vesktop interface and options.

The fix: Close the Vesktop app, mv ~/.config/vesktop ~/config/vesktop.old, open the app again and login, see if the issue is fixed (that worked for me).

If everything is good, you can rm -r ~/.config/vesktop.old if you like.

Was the issue already reported to upstream? That isn't a packaging issue.

I have been having the exact same issue as XcroatoanX

Hey! Unfortunately, Screen Sharing stopped working, and started giving me this error

(node:20896) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 11)

code depends on electron29, for example. I am quite sure that discord depends on its bundled Electron because of a distribution agreement between Discord and Arch, since they are quite anal about "do not modify our app". (Also I heard something about them using a customised Electron, but I don't have a source for that :P)

So I would argue that in the official repos, discord is an exception, not the rule.

I understand if you are fed up with the issues caused by using a non-bundled Electron, and I respect the time and effort that you put as a maintainer into servicing this package. Nevertheless, I think that it is a reasonable option to ask for help, such as passing control of the package, or more reasonably I think, adding a co-maintainer who is willing to go through that hassle. Splitting the pain, if you will. (I have set up my PKGBUILDs in a GitHub repo to simplify such cooperation. It's worked nicely for me thus far.)

(Side note: the AUR isn't great for announcing (co-)maintainership requests? Short of a pinned comment with an email address, I'm not sure much can be done?)

You seem not to understand, it isn't about "someone who won't have those issues" because the issues were just there, regardless of who package it, these issues were going to be there. And yes, you discuss the "guidelines" except that every package on official repos just packages electron apps the same way that this package does to avoid these problems, and I don't see anything wrong with it: it basically uses whatever upstream wants to use, no matter if that version is on the repos or not.

If the excuse is "but we will have a copy of electron...", then it's a nonsense.

So, good luck using vesktop_electron, let's move on.

Edit: I just checked vesktop_electron and it's experiencing the same issues that I experienced months ago (because it isn't about who packaged it) right now, while we haven't had any issues since the new packaging format, so even less reasons to even reconsider that.

I saw these issues with using the system's electron and that, along with my previous experience with trying to you have you understand the arch packaging guidelines for electron apps, has me hoping you'll yield the maintainer role to someone who won't have those issues, or at least will handle them more gracefuly. But again, for now the vesktop_electron package is what I wanted this package to be.

I'm not going to revert it, feel free to use something else.

I have had sufficient issues when I tried to maintain the package using the system's electron.

Clearly, there's significant disagreement about "properly". (In summary: using bundled Electron goes against much of the spirit and benefits of the AUR outside of explicit -bin packages, and causes some breakage if only minor.)

I'd like to point out that vesktop_electron upgraded to Electron 31, which caused some breakage, and soon after reverted to Electron 30.

I wish this package had done the same during the original breakage, much digital ink would not have been spilled. I don't think it's too late to revert the change, either. I think everyone would be happy, and quickly move on.