Arch Linux User Repository

I've made a new version of the corrections that does now use the updated build, and they did fix their yarn.lock finally.

As of such, I've just aligned my corrections with what thelounge-deb does and use the same exact build commands. This is the patch I use on top of the AUR Git repo: https://gist.github.com/ChrisTX/b44f73f415b65ea02c41da096d90f761

I should also mention that this fixes other issues like /etc/thelounge/users having incorrect permissions and bypasses this issue that otherwise prevents 4.5.1 from running (at least until they fixed their tarballs).

Also, pkgrel=0 is a bit unconventional. The Arch package guidelines recommends that "when a new package version is first released, the release count starts at 1".

In addition to my previous comment, namcap identifies some issues with the package:

1. MIT is not a valid license specifier without a license file. Any specifier not in licenses needs a license, see the wiki.

2. pkgsuffix is not a valid variable name. Custom variables have to start with an underscore, see here.

3. .yarn-integrity contains source directory references. File should not be packaged.

4. Debug is not disabled, c.f. here.

Adding all of this up, I've arrived at this final patch: https://bpa.st/MMEA It will work on all NodeJS versions >= 22, build cleanly in a chroot with devtools, and pass namcap cleanly.

Edit: There's some more issues:

1. CRITICAL Your package has the WRONG LICENSE. All AUR packages should be licensed as 0BSD, see the AUR submission guidelines. The LICENSE file included in a package is the license of the PKGBUILD etc. and NOT the upstream license. Alas, this is wrong. See also this. Any AUR package should pass pkgctl license check.

2. There should be an REUSE.toml (see the previous point's link) and it's recommended to have an nvchecker integration.

3. namcap still complains about some extra files in node_modules not having correct dependencies, namely yarn and extra stuff in ldapjs in the examples folder. Neither is needed or indeed used by thelounge and can be removed from the node_modules without issue.

4. strip is left enabled, despite the package not containing any binaries. This slows down the build massively.

ALL this added together, with the build fixes, and etc. yields this as the final final patch: https://bpa.st/3BGQ

This addresses all the issues mentioned:

sh-5.3$ git clone https://aur.archlinux.org/thelounge.git
Cloning into 'thelounge'...
remote: Enumerating objects: 238, done.
remote: Counting objects: 100% (238/238), done.
remote: Compressing objects: 100% (118/118), done.
remote: Total 238 (delta 120), reused 236 (delta 119), pack-reused 0 (from 0)
Receiving objects: 100% (238/238), 53.01 KiB | 53.01 MiB/s, done.
Resolving deltas: 100% (120/120), done.
sh-5.3$ cd thelounge/
sh-5.3$ git apply ~/full.patch
sh-5.3$ pkgctl build -c
==> Updating pacman database cache
:: Synchronizing package databases...
 core downloading...
 extra downloading...
 multilib downloading...
==> Building thelounge
  ->   repo: extra
  ->   arch: x86_64
  -> worker: cpfeiffer-3
==> Building thelounge for [extra] (x86_64)
==> Creating chroot for [extra] (x86_64)...
[...]
(1/1) Arming ConditionNeedsUpdate...
Checking PKGBUILD
Checking thelounge-4.5.0-1-any.pkg.tar.zst
==> Running checkpkg
error: target not found: thelounge
==> WARNING: Skipped checkpkg due to missing repo packages
==> Generating .SRCINFO...done
==> Finished building thelounge 4.5.0-1
sh-5.3$ namcap thelounge-4.5.0-1-any.pkg.tar.zst
sh-5.3$

sh-5.3$ nvchecker -c .nvchecker.toml
[I 05-24 18:15:45.159 core:416] nvchecker: updated to 4.5.0 revision=93f8e256172cc940dda28f92a9c354696b32acd0

sh-5.3$ reuse lint
# SUMMARY

* Bad licenses: 0
* Deprecated licenses: 0
* Licenses without file extension: 0
* Missing licenses: 0
* Unused licenses: 0
* Used licenses: 0BSD
* Read errors: 0
* Invalid SPDX License Expressions: 0
* Files with copyright information: 9 / 9
* Files with license information: 9 / 9

Congratulations! Your project is compliant with version 3.3 of the REUSE Specification :-)

As you can see - the package builds cleanly with that, avoids the NodeJS >= 25 compatibility issue, is clean in REUSE, is properly licensed and has a nvchecker config as well.

@aminvakil That issue is the one I have opened. It does work, try building the package with the patch I posted. The problem stems from using the yarn.lock file, which the official build instructions do not specify for NPM and is only used by upstream for a specific purpose.

Edit Preferably use https://bpa.st/3BGQ as that's the patch with the other issues I listed fixed, too.

@ChrisTX I agree with you on the first part, but thelounge does not work on latest nodejs (https://github.com/thelounge/thelounge/issues/4997).

I couldn't make it work on nodejs as well (without patching).

@S13ntist I was NOT using an AUR helper. As you can see from the output in my last post, I ran extra-x86_64-build. This is not an AUR helper, but a tool in the official ArchLinux devtools to build in a clean chroot. That's the recommended way to do this, compare the respective article in the Wiki.

Any package should be buildable in a clean chroot, and part of building in a clean chroot is that builds are reproducible and that's why the devtools utility doesn't support interactive input there. The other reason is that for a package to work correctly after building, all choices for dependency should also work. Now, this package has the weird effect that installing it offers the same dialogue with the same choice.

In other words, the package after having been built cannot be installed with default options either. Building the package on a system and then attempting to use the resulting package faces the same issue. So even if you were to use a manual chroot or inject the "right" NodeJS LTS version into one, the resulting package cannot be used normally. By extension, this also effects pre-built AUR repositories like Chaos AUR.

This looks as follows btw:

sh-5.3$ pacman -Qs nodejs
sh-5.3$ sudo pacman -U --noconfirm thelounge-4.5.0-0-any.pkg.tar.zst
loading packages...
resolving dependencies...
:: There are 3 providers available for nodejs<25:
:: Repository extra
   1) nodejs-lts-iron  2) nodejs-lts-jod  3) nodejs-lts-krypton

Enter a number (default=1):
looking for conflicting packages...
warning: removing 'nodejs-26.2.0-1' from target list because it conflicts with 'nodejs-lts-iron-20.20.2-1'
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'nodejs>=22' required by thelounge

As a user, I wouldn't know what the hell this error is supposed to tell me, because it's a fault with the package. I should be able to install a package with default options. Pacman does not support this syntax depends=('nodejs>=22' 'nodejs<25') because it will see these as separate statements. Note that depends=('nodejs>=22') conflicts('nodejs>=25') will not work either as conflicts() is only used for dependency resolution on installation, not during building a package.

yarn upgrade won't help, you need to actually have them support the new version and adapt to the new APIs (where needed, say convert to modules and such) Some deps are simply unmaintained but that's something upstream will need to (and is about to) fix.

I refer you to this previous post of mine explaining the situation. TheLounge supports NodeJS 26.2 perfectly fine, and in fact, I have been running on latest NodeJS for months now. And this comment of another user confirms this to be working as well. That's also what they document: "The Lounge requires latest Node.js LTS version or more recent.".

The incompatibility stems from jwa and not theLounge itself. And jwa did address this exact issue with this PR and released the corrected version v2.0.1 that does not use the dropped SlowBuffer API anymore.

Using yarn upgrade (not even --latest) is thus sufficient to upgrade - or in fact, so does not using the yarn.lock at all. Upstream only uses it for their Debian package, but not for their Docker build. That one is just built off NPM using the same exact instructions the official theLounge documentation gives for such a build.

For packages using the upstream yarn.lock is very ill-advised actually, as yarn.lock is NodeJS version specific and only makes sense when being used in a consistent build environment. Hence, NPM packages do not contain yarn.lock files - and official ArchLinux packages do not use them nor do the Node.js package guidelines require or suggest at any point to use lockfiles.

Just dropping the yarn.lock download shenanigans and following the official instructions yields a working build on any Node version >= 22 and then depends('nodejs>=22') is sufficient.

The following makes the build work on any NodeJS >= 22 and work with the regular devtools utilities for chroot builds: https://bpa.st/A6EQ

Packages is broken, whatever aur helpers do is not relevant, package must gets built and installed correctly using makepkg -sri --noconfirm, this package does not.

You can always pick a provider, pacman is supposed to be run interactively. If your aur helper doesn't support that, that's the fault of your helper. For aur, you can prep the container such that it's already fulfilled.

I've done what I could with the deps, given the upstream source doesn't support latest node but must have minimally 22 to get the sqlite dep.

yarn upgrade won't help, you need to actually have them support the new version and adapt to the new APIs (where needed, say convert to modules and such) Some deps are simply unmaintained but that's something upstream will need to (and is about to) fix.

No, it doesn't and you can't necessarily pick a provider: Chroot-builds do not support that, and this package won't built under chroot:

$ git clone https://aur.archlinux.org/thelounge.git
$ extra-x86_64-build
[...]
==> Installing missing dependencies...
:: There are 3 providers available for nodejs<25:
:: Repository extra
   1) nodejs-lts-iron  2) nodejs-lts-jod  3) nodejs-lts-krypton

Enter a number (default=1):
resolving dependencies...
[...]
(1/1) Arming ConditionNeedsUpdate...
==> Missing dependencies:
  -> nodejs>=22
  -> nodejs<25
==> ERROR: Could not resolve all dependencies.
==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/cpfeiffer/build

This is because pacman does not support putting multiple constraints on a package. As you can see from my output it says "There are 3 providers available for nodejs<25". It will ask the user to install any NodeJS < 25 and ignore the NodeJS >= 22 constraint for that list of targets. However, the default (when not entering anything, which is what happens under chroot builds) is to pick the first lexicographical option. And since NodeJS names their LTS releases after elements starting with consecutive first letters, that target is nodejs-lts-iron aka NodeJS 20, which then conflicts later on.

You cannot fix this, as pacman doesn't support this by design - conflicts() and friends cannot fix this either. And fixing the NodeJS version to Jod or Krypton will be an issue for people that need a specific version for other packages on their system.

What you want to do here is what I've been saying for a while, namely to insert a yarn upgrade. That way you can drop the NodeJS < 25 requirement, and just leave it to NodeJS >= 22, which would resolve correctly by default.

P.S.: The pkgrel is 0 atm, should be 1 at least.

This works just fine, pick the provider that satisfies the constraints.