...in the update script and remove it from the Gemfile.lock. Having
it there causes a failure with the error message:
Could not find libv8-node-16.10.0.0-aarch64-linux in any of the
sources (Bundler::GemNotFound)
And since we're not using the prebuilt binary packages anyway, we
don't need it there in the first place.
Instead of patching the path to /public in Discourse's sources, make
the nginx configuration refer to the symlink in the discourse
package which points to the real path.
When there is a mismatch between the path nginx serves and the path
Discourse thinks it serves, we can run into issues like files not
being served - at least when sendfile requests from the ruby app are
processed by nginx. The issue I ran into most recently is that backup
downloads don't work.
Since Discourse refers to the public directory relative to the Rails
root in many places, it's much easier to just sync this path to the
nginx configuration than trying to patch all occurrences in the
sources. This should hopefully mean less potential for breakage in
future Discourse releases, too.
Add a DiscourseVersion class which handles Discourse's version
numbering properly when sorting - beta versions are sorted lower than
their respective release versions. It can also return both its version
number and equivalent git tag, removing the need for `rev2version` and
manually adding `v` to the front.
Using DiscourseVersion instead of LooseVersion, we can list all
current version number tags from the `discourse` repo and sort them
correctly, giving us the latest one, regardless of type; i.e. we don't
have to filter for only release versions or beta versions anymore.
This also implements the plugin pinning algorithm laid out here:
https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971
to make sure we don't upgrade plugins further than what's compatible
with our currently packaged Discourse version. While it likely won't
matter much most of the time if we continue packaging the beta
versions, it could be helpful if we decide to go back to packaging
release versions or if we run into issues with future upgrades. In
that case, the plugins could still be updated safely even though we're
not on the latest version of Discourse.
Also, add support for updating plugins which keep gem versions in
files at the root of the repo (discourse-prometheus) and replace the
`up-plugin.sh` script with a README file pointing to the plugin
packaging documentation.
Change the path to the public directory reported by Discourse
to its real path instead of the symlink in the store, since
the store path won't be matched by any nginx rules.
Fixes#142528.
Discourse normally overrides the default notification email setting,
which makes the `notificationEmailAddress` setting ineffective. Add a
patch to remove this override.
Fixes#140114.
When restoring a backup, discourse decompresses the backup archive in
the /share/discourse/tmp dir. Before this change, it is linked to /run
which is typically backed by memory, so the backup will fail to
restore if you do not have enough memory on your system to contain the
backup. This has already happened to me on two small forums.
This moves tmp to the StateDirectory /var/lib/discourse/tmp which is
typically backed by disk.
ChangeLog: https://github.com/hedgedoc/hedgedoc/releases/tag/1.9.0
As documented in the Nix expression, I unfortunately had to patch
`yarn.lock` manually (the `yarn.nix` result isn't affected by this). By
adding a `git+https`-prefix to
`midi "https://github.com/paulrosen/MIDI.js.git#abcjs"` in the lock-file
I ensured that `yarn` actually uses the `MIDI.js` from the offline-cache
from `yarn2nix` rather than trying to download a tarball from GitHub.
Also, this release contains a fix for CVE-2021-39175 which doesn't seem
to be backported to 1.8. To quote NVD[1]:
> In versions prior to 1.9.0, an unauthenticated attacker can inject
> arbitrary JavaScript into the speaker-notes of the slide-mode feature
> by embedding an iframe hosting the malicious code into the slides or by
> embedding the HedgeDoc instance into another page.
Even though it "only" has a medium rating by NVD (6.1), this seems
rather problematic to me (also, GitHub rates this as "High"), so it's
actually a candidate for a backport.
[1] https://nvd.nist.gov/vuln/detail/CVE-2021-39175
Some plugin repos already have a `gems` directory. This lets the
packager choose whether it should be kept and the nix packaged ruby
gems should be copied into it or if it should be removed in favor of
our ruby gems.
Let the update.py script handle the initial, repetitive task of
packaging new plugins. With this in place, the plugin only needs to be
added to the list in `update-plugins` and most of the work will be
done automatically when the script is run. Metadata still needs to be
filled in manually and some packages may of course require additional
work/patching.
Perform the tests on the package that the `tests` attribute is a child
of, i.e. if `discourseAllPlugins.tests` is built, the tests will run
with the `discourseAllPlugins` package, not the `discourse` package as
previously.
Fixes runtime error during `migrate.sh`:
** (UndefinedFunctionError) function ClickhouseEcto.lock_for_migrations/3 is undefined or private
The function `lock_for_migrations` indeed does not exist in the `ClickhouseEcto`
module packaged so far.
Reason:
So far we use the patch `ecto_sql-fix.patch` doing
- {:ecto_sql, "~> 3.0"},
+ {:ecto_sql, "~> 3.6"},
@scvalex found that the commit that makes the `plausible/clickhouse_ecto` fork
compatible with 3.6 is _newer_ than the commit pinned in the `.lock` file,
namely `1969f14ecef - Update for ecto 3.6.1`:
https://github.com/plausible/clickhouse_ecto/commit/1969f14ecef
That commit introduces the function that my error shows (`def lock_for_migrations`).
This means that the version that's in the lockfile (and pulled) was
incompatible with the version the nixpkgs patch forces.
This commit fixes it by patching the `.lock` file to have the version of
`plausible/clickhouse_ecto` that makes it compatible with `ecto_sql` 3.6.
