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.
(cherry picked from commit f933c68374b9c6195dc74d26c95fc9bf240fead8)
Need to patch out the contextvars dependency (which is included in
python 3.7+).
The same patch is discussed in arch:
https://bugs.archlinux.org/task/71344
(cherry picked from commit c0b46c6b596dd25f32733ff01156d3d769640ab5)
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
(cherry picked from commit 0a10c17c8d01e5f9fefa3d6dbb7802a3cbce7e23)
The src points to the obsidiansystems repo as it has the ghcjs ported from
8.10.5 to 8.10.7, and a bunch of other fixes (#812, #811, #809)
(cherry picked from commit ba25b274f4bb0240a8ffa71e41b55712930af3d8)
Modified the stm_2_5_0_1 -> stm_2_5_0_0
Backport which adds, rather than updates, the GHC release.
----
The only big change is required for darwin since GHC 8.10.5 now
runs xattr in the install phase on darwin:
* 11e1dcde0d
* ec451cac39
Unfortunately, it uses the host /usr/bin/xattr by default which is
present in the build due to a lack of sandboxing on darwin. That xattr
version however still requires Python 2.7 whereas Python 3.8 is in PATH
in our build. We solve this by setting the XATTR environment variable.
We can't use python3Packages.xattr since GHC expects Apple's fork of
xattr which provides some extra flags to utilize.
Co-authored-by: Cheng Shao <cheng.shao@tweag.io>
(Adapted from cb330ce4f05f5a6e2da3021e9cbf4ea2eb592631)
The `services.mastodon` module currently hardcodes sidekiq's concurrency
to 25, but doesn't set a DB pool size, which defaults to 5 or the number
of configured web threads.
(This behaviour is very strange, and arguably a mastodon bug.)
This also makes sidekiq's concurrency configurable, because 25 is a tad
high for the hardware I'm running it on.
(cherry picked from commit e8fd7792d1eeb4ea4943cc34525da1159ab50bc9)
Ryan Mulligan
Kim Lindberger
Michael Weiss
Flakebi
Maximilian Bosch
Kerstin Humm
adisbladis
Bernardo Meurer
Moritz Hedtke
taku0
John Ericson
Divam
Alexandre Esteves
sternenseemann
sternenseemann
Robert Scott
TredwellGit
Pavol Rusnak
Jörg Thalheim
Artturi
Sumner Evans
Henri Menke
embr
pennae