Arch Linux User Repository

As of 2024-09-16, this package is being co-maintained by official vesktop developers, and any packaging decisions they make will not be questioned on my part unless it's something harmful for the users, which is very unlikely to happen. As I see it coming, they will not use the system's electron on this package purposely, if you don't like it, use vesktop-electron, which is also maintained by the same devs.

Thanks!

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.

picokan, it's just being packaged properly, like any of the packages on the official repos are. There's no need to apologize for something that was done right. Cheers

I want to apologise to all the people that have had problems with the handling of this package. I should've known better than to give away the maintainer role to the first person that asked. If it's any consolation, I haven't had any problems with the vesktop_electron package.