Package Details: mx-puppet-discord-git v0.1.1.r5.gfd44022-1

Git Clone URL: (read-only, click to copy)
Package Base: mx-puppet-discord-git
Description: This is a Matrix bridge for Discord
Upstream URL:
Licenses: Apache
Conflicts: mx-puppet-discord
Provides: mx-puppet-discord
Submitter: BrainDamage
Maintainer: BrainDamage
Last Packager: BrainDamage
Votes: 2
Popularity: 0.58
First Submitted: 2020-11-06 09:15 (UTC)
Last Updated: 2022-05-12 10:17 (UTC)

Latest Comments

Ta180m commented on 2022-05-14 00:56 (UTC) (edited on 2022-06-10 16:39 (UTC) by Ta180m)

<del>I think this might have to do with binary stripping, but directly installing this package doesn't work for me while doing a git clone of upstream and manually building from that works perfectly. Here's a diff of this package's build vs my manual build:</del>

Edit: It works for me now with the following tweak: I had to comment out SystemCallFilter=@system-service in the systemd service to avoid a coredump.

Ta180m commented on 2022-05-10 21:46 (UTC) (edited on 2022-05-11 19:16 (UTC) by Ta180m)

Upstream recently switched from npm to yarn, which causes this to currently fail to build.

To fix this, it should be as simple as using yarn install and yarn build instead of the current npm commands, then cp -r the build to the /usr/lib/node_modules directory.

BrainDamage commented on 2022-05-06 12:38 (UTC)

I apologize for the delay, I've had the changes made ... one month ago, but I've just noticed I never pushed them

Ta180m commented on 2022-02-19 23:55 (UTC)

I finally figured out a solution to my issue from 10 months ago! I needed to add options=(!strip) to the PKGBUILD, and now this package works perfectly.

marcool04 commented on 2021-05-28 09:58 (UTC)

Right. I've tracked it down to the component. Somebody opened an issue there already:

BrainDamage commented on 2021-05-09 14:07 (UTC) (edited on 2021-05-09 14:07 (UTC) by BrainDamage)

that's a different error, unrelated to the previous unfortunately, it seems to be an upstream problem, npm pins versions of libs while archs track official releases, and arch's sqlite libs are incompatible with that version of better-sqlite in nodejs

now I'm not sure if a newer version of better-sqlite exists which fixes the issue and mx-pupppet-discord has to just point to a different version, or it doesn't exist entirely and you'll have to wait even more

I'd suggest you to report it to mx-puppet-discord bugtracker for now

marcool04 commented on 2021-05-04 20:31 (UTC)

Thanks for your insights and helpful suggestions @Ta180m and @BrainDamage. Unfortunately, makepkg --cleanbuild made no difference. Indeed, I even cloned the git repo from this package fresh, and that made no difference. Attempting to perform the makepkg as a brand new user failed. I spun up a local vanilla archlinux vm and still get the same error. This is not related to my "upgrade"… as it stands, the PKGBUILD doesn't build, see log from fresh VM here:

BrainDamage commented on 2021-05-02 22:42 (UTC)

the sqlite error is because npm cache mechanism prevents a rebuild of the package against a new .so, it thinks that the lib is already compiled and working for the current version

to have it working without hassle, you can nuke the cache dir along the src files with makepkg --cleanbuild, with penalty that the rebuild will be longer since you'll be rebuilding more than just the sqlite bindings

... alternatively, just selectively delete the sqlite bindings folder in the cache and issue a rebuild as usual, but ymmv if more than just sqlite bindings broke

Ta180m commented on 2021-05-01 22:40 (UTC)

If you use PostgreSQL instead of SQLite, you can remove the SQLite dependencies from the relevant files, which will also fix the problem.

marcool04 commented on 2021-05-01 17:49 (UTC)

Hi there. After last system upgrade, mx-puppet-discord failed to start with following error:

        throw e;
Error: /usr/lib/node_modules/mx-puppet-discord/node_modules/better-sqlite3/build/Release/better_sqlite3.node: undefined symbol: _ZN4node6AtExitEPFvPvES0_
    at Object.Module._extensions..node (node:internal/modules/cjs/loader:1167:18)
    at Module.load (node:internal/modules/cjs/loader:988:32)
    at Function.Module._load (node:internal/modules/cjs/loader:828:14)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:93:18)
    at bindings (/usr/lib/node_modules/mx-puppet-discord/node_modules/bindings/bindings.js:112:48)
    at Object.<anonymous> (/usr/lib/node_modules/mx-puppet-discord/node_modules/better-sqlite3/lib/database.js:6:40)
    at Module._compile (node:internal/modules/cjs/loader:1108:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1137:10)
    at Module.load (node:internal/modules/cjs/loader:988:32) {

The DLOPEN error points to a .so change – not sure which one, I suspect one of these:

$ rg "2021-04-30.* \[ALPM\] upgraded" /var/log/pacman.log
nodejs (15.14.0-2 -> 16.0.0-1)
npm (7.10.0-1 -> 7.11.2-1)

I figured that a simple rebuild should fix it, so I bumped the pkgrel in PKGBUILD, but ran into issues with this stage of building:

npm install --cache "${srcdir}/npm-cache"

This fails with a C related error, which has something to do with better-sqlite3 Try as I may, I can't figure out what's wrong with it. However… I did notice that this:

sudo npm install --global better-sqlite3

Actually works fine! So I then copied /usr/lib/node_modules/better-sqlite3/ over into the src/mx-puppet-discord/node_modules/ directory, ran npm install --cache "${srcdir}/npm-cache" manually from src/mx-puppet-discord/, and finally commented that line out in the PKGBUILD and ran makepkg -si to reinstall. Working! If anybody can figure out what's up with better-sqlite3 that'd be helpful… it's beyond me!

Ta180m commented on 2021-04-07 23:51 (UTC)

@podiki Thanks, I actually found that guide when I was first getting this set up. Unfortunately, I think something's wrong with my Node installation since the Node scripts don't seem to run as root.

podiki commented on 2021-04-07 21:36 (UTC)

@BrainDamage thanks again for the package, the Discord bridge has been very handy!

I do have a brief line about the shared secret module, but just pointing people to what's in the sample config and the module readme. I found that simple and easy enough when I did it, but would be easy enough to add for completeness. And that module is good to have for other bridges as well.

BrainDamage commented on 2021-04-07 21:28 (UTC) (edited on 2021-04-07 21:32 (UTC) by BrainDamage)

I apologize for all the mistakes, normally I am not this sloppy ...

I'll try to be careful from now on

@podiki: you can avoid .well-known by using the functionality in mx-puppet-discord/config.yaml ( few other bridges also support this functionality )

# Map of homeserver URLs to their C-S API endpoint
# Useful for double-puppeting if .well-known is unavailable for some reason
homeserverUrlMap: http://localhost:8008

podiki commented on 2021-04-07 21:09 (UTC)

@Ta180m (and anyone else) If it is helpful, I wrote up a guide to using this:

Ta180m commented on 2021-04-07 21:06 (UTC)

Thanks for maintaining this package! I tried the latest version, and I'm still running into tons of problems though, although I did get it to work with a lot of workarounds.

Also, I think the permissions on /var/lib/mx-puppet-discord should be 700, not 600.

Ta180m commented on 2021-03-29 16:25 (UTC) (edited on 2021-03-31 22:09 (UTC) by Ta180m)

For some reason, after editing /etc/mx-puppet-discord/config.yaml, when I run node /usr/lib/node_modules/mx-puppet-discord/build/index.js -c /etc/mx-puppet-discord/config.yaml -r -f /root/registration.yaml as root, the command never stops running. Checking my active processes, it doesn't even seem like node is doing anything. The same thing happens with node /usr/lib/node_modules/mx-puppet-discord/build/index.js -h which should print the help message. Does anyone know why this is happening? Perhaps something is wrong with my node installation?

EDIT: I generated a registration.yaml using the instructions in the GitHub repository, and now when I try to start mx-puppet-discord.service, I get the error Failed at step NAMESPACE spawning.

EDIT 2: I finally got the original GitHub repository to work. I don't know what's wrong with this package though.

EDIT 3: I figured out how to fix the systemd error: Turns out you need to manually create the /var/lib/mx-puppet-discord directory.

EDIT 4: Finally got a working setup! I first cloned the repo directly from GitHub, configured it, transferred ownership to the mx-puppet-discord user and reused the systemd service. Now it works perfectly!

EDIT 5: Synapse wasn't starting up fast enough on boot for mx-puppet-discord, so I had to add ExecStartPre=sleep 5 to the service file for it to work after a reboot.

podiki commented on 2021-03-02 01:14 (UTC)

Ah okay, that makes sense and would explain it! I guess you really only need to generate the file once (unless certain changes to config I guess?) which would explain why you wouldn't have noticed this.

Sorry to belabor the point, I did see how WorkingDirectory is expanded, but where is mx-puppet-discord's home directory set to /var/lib/mx-puppet-discord? I'm not seeing it in the user creation here or aware of where else it might be set. I just checked (via /etc/passwd) and I see the home directory for this user is /.

BrainDamage commented on 2021-03-02 00:06 (UTC)

I guess upstream changed behaviour since I did manage to get it to work in the past ...

I'll remove the file from the package and update the post-install instructions

re: working directory

   Takes a directory path relative to the service's root directory specified by RootDirectory=, or the special value "~". Sets the working directory for executed processes. If set to "~", the home
   directory of the user specified in User= is used. If not set, defaults to the root directory when systemd is running as a system instance and the respective user's home directory if run as user.

podiki commented on 2021-03-01 23:50 (UTC)

Thanks for the speedy response, much appreciated. I know I was mucking around a bit so may have made a little mess. I was doing this before the post install command message was fixed, and so may have changed something before fixing the typo. Not excluding anything below is just due to something I did, but figured I'd report back.

  1. Makes sense, figured that was the case, but

  2. I did indeed run with sudo and it won't overwrite. I just did it now with same permissions on a blank (touch only) file as included in the package (0644 root:mx-puppet-bridge) and gave an error (below). For some reason I didn't think to add synapse to the group, whoops!

  3. This doesn't happen for me, I need to explicitly set the working directory in the service file. I'm not seeing documentation where ~ expands to /var/lib/$USER or something similar, but I know little of systemd. I can try reinstalling this package or looking around, not sure why that happens for me (on ARM for what's that worth).

Mar-1 18:24:07.672 [PuppetBridge] info: Generating registration file...
Mar-1 18:24:07.677 [PuppetBridge] error: Registration file already exists!
Couldn't generate registration file: Error: Registration file already exists!
    at PuppetBridge.generateRegistration (/usr/lib/node_modules/mx-puppet-discord/node_modules/mx-puppet-bridge/lib/src/puppetbridge.js:226:19)
    at Object.<anonymous> (/usr/lib/node_modules/mx-puppet-discord/build/index.js:81:16)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:708:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
    at internal/main/run_main_module.js:17:47

BrainDamage commented on 2021-03-01 23:14 (UTC) (edited on 2021-03-01 23:23 (UTC) by BrainDamage)


the included empty registration file is so that it has the correct ownership and permissions from the installation, if you just create it on the fly it ends up world-readable by default, which leads us to


yes, there's a very good reason, the registration.yaml contains shared secrets between synapse and the bridge, so it's best if no other users can read it

the file is g+r by default, readable by members of mx-puppet-discord group (which includes its own user), so all it's necessary for the synapse user ro access it is to add it to the mx-puppet-discord group:

# usermod -aG mx-puppet-discord synapse

this of course is only valid if synapse runs on the same machine as the bridge, if it's not the file has to be copied over or made accessible through network mounts

the reason why the file is g-w and owned by another user (root) is in the case of a bug in the software itself it cannot overwrite the config, neither accidentally nor in the case of a software vulnerability (and it doesn't need to in order to run), also valid for synapse since it'd use the group membership to read it (but not write)

the daemon editing its own config doesn't apply to all cases, e.g. mautrix-telegram tries to auto-update its own config, so it does need to write permissions and be owned by the daemon's user, but mx-puppet-discord doesn't, so it's uneccessary to give it


WorkingDirectory=~ is expanded by systemd to the user's home dir as specified by man 5 systemd.exec, so what you did is redundant

ReadWritePaths is unnecessary as well, since the daemon only needs to read the config, not write it

Lastly: did you run the registration command as root? The # is standard slang for root executed commands (as opposed to $), which would've given the command the right permission to write the file's contents; having yourself deleted and re-created the file, now it has different permissions and ownership from the package so all my discourse about access may or may not apply depending on what you did

podiki commented on 2021-03-01 22:43 (UTC)

Thanks for the package! A few questions/comments/suggestions:

  1. Besides what marcool04 noted, I also had to remove the included (empty) registration.yaml as it would not overwrite the existing file. Is there a reason to include it? Is it because the user will generate and want to note that it is a user modified file? (Sorry, don't know much about packaging.)

  2. Permissions on registration.yaml? It needs to be readable by synapse user, not sure what the protocol here is as I've seen different bridges do different things. Is there a good reason it shouldn't be world readable? I've also seen the user:group for both config and registration be root:<bridge-user> (Oddly enough everything worked as is at first, but not on a later restart.)

  3. I had to change the systemd service to have WorkingDirectory=/var/lib/mx-puppet-discord. (I also updated ReadWritePaths for /etc/mx-puppet-discord and its node directory, but maybe I didn't need that as it was because of #2?)

BrainDamage commented on 2021-02-27 22:51 (UTC)

fixed, thanks sorry for the typos, I forgot to test the command myself

marcool04 commented on 2021-02-27 21:26 (UTC)

Could probably use this to fix the message that is printed after installation regarding registration file generation (not that it's hard for users to figure out the mistakes but hey…):

diff --git a/mx-puppet-discord.install b/mx-puppet-discord.install
index 017ab50..6c7d8ee 100644
--- a/mx-puppet-discord.install
+++ b/mx-puppet-discord.install
@@ -1,6 +1,6 @@
 post_install() {
        cat <<- 'EOF'
                after editing /etc/mx-puppet-discord/config.yaml, generate a registration file using:
-               # node /usr/lib/node_modules/mx-puppet-discord/build/index.js-c /etc/mx-puppet-discord/config.yaml -r -f /etc/mx-puppet-discord/registration.yaml -r
+               # node /usr/lib/node_modules/mx-puppet-discord/build/index.js -c /etc/mx-puppet-discord/config.yaml -r -f /etc/mx-puppet-discord/registration.yaml

Thanks for the package btw! Regards, Mark.