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!

I don't know why this is so hard for you to understand. I'm going to paraphrase a comment I made four days ago and make it as clear as possible.

As you just stated, the source of people's issues was electron 30, it had nothing to do with using system provided electron. Vesktop was working just fine with the electron29 package, so if this package uses electron29 then the people who were having issues and the people who dislike bundled electron will both be happy.

Honestly, I don't get the problem here. People came here to report that the package is broken because electron 30+ causes issues on his setups (I never experienced it) without providing any upstream bug report or anything. Then the upstream maintainer had to come here to confirm the breakage — again, I don't see even one upstream bug report linked.

Thereafter, I fixed the package by simply packaging what the upstream project build produces, and then people now argue why I did it? Come on.

This package supports setting flags on $HOME/.config/vesktop-flags.conf or directly in the .desktop file, so just set the Wayland-required flags there and problem solved.

The "officially supported" electron version upstream supports is the one they package, which is what this package is now using.

The officially supported electron version is electron 29, it makes no difference to them whether it is packaged by the vesktop devs or arch maintainers. If Vendicated wanted this package to switch to the bundled electron they would have specified that.

Further, upstream (good afternoon Vendicated ,o7) came and pointed out the fix.

The request from upstream was, "please stick to proper stable electron versions officially supported by us". The "officially supported" electron version upstream supports is the one they package, which is what this package is now using.

Avoiding downloads during build is not the crusade of anyone, it is simply good packaging practice, for several good reasons.

The mess will go away soon if this package is reverted. I can testify firsthand that this happened for at least two packages I was involved with, one being Aseprite (for which I was promoted to co-maintainer after submitting a patch to the PKGBBUILD that fixed the random crashes).

I also believe that a satisfying solution can be reached in less time by discussing this and reaching some consensus, instead of strong-arming each-other (a package will be voluntarily deleted far sooner by its disgruntled submitter if their complaints are addressed, than if their package is deleted against their will).

To be fair to the reporters, the maintainer hasn't asked for any details either. Too much information is as unhelpful as too little, and nowhere was any particular information requested. The issue isn't specific to Wayland either, so what info is pertinent anyway?

Further, upstream (good afternoon Vendicated ,o7) came and pointed out the fix. This comment thread, the dozen of issues reported upstream, and several annoyed users, could have been avoided by complying, instead of digging one's heels in "works for me". It is not how I think packaging ought to work: what if this user had been replied "well I don't use those plugins"? Instead, things just hummed along.

I have reported that the bundled Electron breaks fractional scaling for me. And besides, it is fine to request improvements even if they aren't resolving breakage. It happens all the time, and generally improving usability is considered a good thing.

Avoiding downloads during build is primarily the crusade of a single user who has a specific use case that requires it.

Even if this package were reverted, the "mess" is unlikely to go away soon because the turn around on orphan and deletion requests is months. Since vesktop_electron now exists, unless it is being mismanaged, users who want system electron might as well use it.

There is a difference between "reporting breakage" and complaining. The complainers did not provide any info about error messages, hardware specs, desktop and window managers, etc that could have helped the maintainer reproduce the issue. Nothing is reported broken in posts expressing discontent with using the packaged electron.

I have reverted to my aforementioned workaround, because the bundled Electron fails to use Wayland, and thus looks blurry in a way that I can't bear. The bundled Electron also causes issues, not only the system Electron :/

I would also like to kindly point out the existence of the vesktop-bin package; people who want to use the bundled Electron are already using that. Now we have three packages for (stable) Vesktop: vesktop-bin, vesktop, vesktop_electron... I think this is becoming a mess. (Additionally, re-reading the AUR guidelines, it seems like relying on the bundled Electron is not allowed for a non--bin package?)

Please allow me to renew that request to switch the PKGBUILD to electron29. That package exists for the specific purpose of supporting applications that need Electron 29, and Vesktop is just that. If you do not wish to handle that kind of change yourself, then I remain a volunteer for putting my money elbow grease where my mouth is, and co-maintaining the package. (Feel free to contact me by e-mail if you'd rather take this privately.)

As for pnpm, I remember reading a statement that "build() and prepare() should not access the network", but couldn't find it. It seems to be policy nonetheless.

Lastly, I would like to point out that reporting breakage is completely fair as long as demands are not made; and IMO what happened doesn't qualify as "complain-bombing", especially when the maintainer (initially) dismissed those reports curtly as a being a minority.

Assigning blame does not matter one iota, I would rather move on and find a compromise at least most of us will agree on.

You all complain-bombed the maintainer and got what you asked for – electron downgrade. Accept the consequences.

I'm not going to use “system” electron anymore on this package as it's proven to create issues

But system provided electron was not the source of the issue though, the source of the issue was electron 30. Vesktop was working just fine with the electron29 package. That's my point.