Arch Linux User Repository

As of 2025-08-14, I have removed the vesktop developers from maintaining this package for the following reasons:

• They tried to include binaries (the .deb one) in this package, which I refused to, telling them that it's what vesktop-bin is for.
• As a result of my refusal, I got banned from their Discord server, which is not the correct approach, in my opinion.
• As per the latest comments, it's clear that they don't have the expertise required to be maintainers, as a basic concept such as a clean chroot seems to be strange for them.
• Now, they are trying to forcefully take the package, creating a orphan request: https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/4I64TLEVB2GCVAGSHHUBZ3D5B4U63MQV/

Thank you!

@Edu4rdSHL Maybe you should look into nvm? I think it can manage multiple nodejs installs locally, so you can have the nodejs version that the package requires to be installed. If you take a look at vscodium, you can see how nvm can be used to manage a nodejs install for a package specifically. Maybe this will help you.

@Vendicated

If you want to officially support a package that uses your upstream build, go to vesktop-bin. Base packages are meant to be compiled from scratch on the AUR.

I cannot talk about who said what or how anybody acted, but I know from personal experiences that whenever an upstream project tries to create a PKGBUILD for the aur, things can happen. Sometimes, they can be good. Other times, they can be bad. I know an upstream AUR package that has zero dependencies listed. Or, sometimes, they created an automated PKGBUILD generator and don't touch it all until somebody does it for them.

If an AUR maintainer says what you're doing is not the best thing to do, then you should hear them out. Clean chroot builds with extra-x86_64-build are important to ensure everything works. If you want to have a package where it uses pre-made Linux binaries, go to vesktop-bin.

You were the one wanting to add the .deb binary to a non -bin package - nothing much to add there.

Moreover, you keep saying that I'm "uncooperative", when:

• I provided you with access to the package without any issue when you requested it.
• I didn't interfere with the packaging for almost 1 year, and made it clear with a pinned comment there.

Basically I refused to add a -bin and to keep the package broken by an issue on nodejs, if that's being "uncooperative", that's okay. The reasons for removing vesktop people from maintainership are related to technical decisions, as explained in the pinned comment; that's not going to be reverted unless a proper talk is done. AUR users are first, then developers, sorry.

Thank you.

Hello.

You were kicked - not banned - from our server, because you were being rude/arrogant and uncooperative, even after being told to stop it.

You continue to be uncooperative now by removing us and claiming full control.

If you do not revert this action and are more cooperative in the future, I will have no choice but to explicitly warn our users against using your package, due to a lack of trust and unwillingness to cooperate.

As of 2025-08-14, I have removed the vesktop developers from maintaining this package for the following reasons:

• They tried to include binaries (the .deb one) in this package, which I refused to, telling them that it's what vesktop-bin is for.
• As a result of my refusal, I got banned from their Discord server, which is not the correct approach, in my opinion.
• As per the latest comments, it's clear that they don't have the expertise required to be maintainers, as a basic concept such as a clean chroot seems to be strange for them.
• Now, they are trying to forcefully take the package, creating a orphan request: https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/4I64TLEVB2GCVAGSHHUBZ3D5B4U63MQV/

Thank you!

"Chroot part is only mentioned several sections down" - yes, and it says:

To avoid problems caused by your particular system configuration, build packages in a clean chroot. If the build process still fails in a clean chroot, the issue is probably with the PKGBUILD.

Which is precisely the problem here. Anyway, I'm not going to continue this discussion anymore, as the points have been made clear.

If it was the default way, it would be stated so in the AUR guide. But it only mentions running makepkg normally: https://wiki.archlinux.org/title/Arch_User_Repository#Installing_and_upgrading_packages. Chroot part is only mentioned in passing several sections down.

But yeah, I agree that at the moment, there is really no good other solution, since package does not build with the new nodejs.

Using a clean chroot is basically the only way to do right packaging; See https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot and https://wiki.archlinux.org/title/Creating_packages#Set_up_clean_chroot; it's clearly explained there. It isn't any "workaround", it's called "doing the right thing".

Also, adding nodejs<24.4 doesn'tr solve anything, the user will be prompted with:

==> Installing missing dependencies...
:: There are 2 providers available for nodejs<24.4:
:: Repository extra
   1) nodejs-lts-iron  2) nodejs-lts-jod

which will cause the same result as the current approach, but with unpredictable results.

I've never once had to use a clean chroot to build packages, and never had package issues that required it. I don't see that as "doing the right thing", its just a workaround. With nodejs<24.4 that gives the user more freedom to either wait, downgrade, or use chroot. In a situation like this there's really no good solution unfortunately.

People should be doing the right thing, building packages in a clean chroot, adding nodejs-lts-nod is not problematic there. Also, adding <24.4 is basically encouraging people to do partial updates (holding nodejs in this case). When a new nodejs version that fixes this issue is release, we will switch back.

Basically, it affects people doing the things wrong.