Arch Linux User Repository

is there any reason for not allowing arm architectures?

I am getting the following npm ERR! semver.simplifyRange is not a function

@mrpg I downgraded to nodejs-lts, that did the trick for me. Seems like its a issue in node or a new interaction with latest nodejs.

Has anyone gotten this to run recently? I was not able to access the website, so I dug a little deeper.

It seems to break right after starting the service, with journalctl saying something like /usr/bin/node[147752]: ../src/api/callback.cc:125:void node::InternalCallbackScope::Close(): Assertion(env_->execution_async_id()) == (0)' failed.. I can also bind to port 9001 usingnc -4 -l 9001` with no errors, so it truly doesn't seem to be running anymore.

Any insights?

Please not that 1.8.13 seems to be broken, so I will refrain from packaging it until upstream has addressed the issue: https://github.com/ether/etherpad-lite/issues/4975

Is there a manual procedure I could follow to install a plugin?

@mrvdb: Not that I'm aware of. However, if you're up for the pain, you can of course start packaging extensions for etherpad-lite.

Even if this means redoing it on upgrading the package it's worth it sometimes. Having the secure base install is nice, but without /any/ option to get a plugin to work, most people will need to choose another install method than this package.

And people are free to do so.

I saw someone mentioning manually putting a .ep_initialized file in the plugin folder, but that didn't seem to work for me. Also, given that the upstream issue has been open for more than 2 years now, a workaround would perhaps be fitting.

The problem is, that etherpad-lite doesn't really have a "plugin directory", but pollutes its base install directory when installing plugins.

That being said: You're free to modify this PKGBUILD for your own purposes of course. From a packaging standpoint it makes no sense though as it is unsafe to use and would basically require manual intervention all the time.

If you have some time to spend it is always a good idea to help upstream figure out how to solve the plugin directory issue and fix this problem at the root instead of making your system less secure.

Is there a manual procedure I could follow to install a plugin?

Even if this means redoing it on upgrading the package it's worth it sometimes. Having the secure base install is nice, but without /any/ option to get a plugin to work, most people will need to choose another install method than this package.

I saw someone mentioning manually putting a .ep_initialized file in the plugin folder, but that didn't seem to work for me. Also, given that the upstream issue has been open for more than 2 years now, a workaround would perhaps be fitting.

The problem appears to be caused by the fact that our Etherpad instance is served by Apache (proxy) under /pad. The fonts seem to be searched for using absolute paths, which probably was not the case before.

So this is not a packaging issue.

@respiranto: is your docroot at /usr/share/etherpad-lite/src/? The files are part of the package and are in /usr/share/etherpad-lite/src/static/font.

Note: Fixed typo in path

The problem appears with both skins.