Add `-debuglogfile` option #11781

laanwj commented at 9:36 AM on November 28, 2017: member

This patch adds an option to configure the name and/or directory of the debug log file.

The user can specify either a relative path, in which case the path is relative to the (network specific) data directory. They can also specify an absolute path to put the log anywhere else in the file system.

Alternative to #11741 that gets rid of the concept of a "log directory" by specifying the path for the specific kind of log, the debug log. Which happens to be the only kind of log we have at this point*, but a hypothetical new kind of log (say, an audit log) would get a new option. This has more flexibility than specifying a directory which has to contain all of them.

* excluding db.log which is internally generated by the wallet database library, but that one moves along with -walletdir.

laanwj added the label Docs and Output on Nov 28, 2017

promag commented at 10:29 AM on November 28, 2017: member

Can't test right now, but what happens if the absolute path doesn't exist?

laanwj commented at 10:31 AM on November 28, 2017: member

Can't test right now, but what happens if the absolute path doesn't exist?

bitcoind: /home/orion/projects/bitcoin/bitcoin/src/util.cpp:359: int LogPrintStr(const std::string &): Assertion `vMsgsBeforeOpenLog' failed.
Aborted (core dumped)

Gah, seems like we need a check in init before the logging stuff is initialized.

promag commented at 10:35 AM on November 28, 2017: member

Right, current code knows that data dir exists.

promag commented at 10:37 AM on November 28, 2017: member

If you do handle that, then add an init test for inexistent path.

laanwj commented at 10:38 AM on November 28, 2017: member

@promag Apparently there is some logic for handling the case that the debug log could not be opened: https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp#L201 . So it's a matter of passing it on to the caller.

laanwj force-pushed on Nov 28, 2017

laanwj commented at 11:06 AM on November 28, 2017: member

Pushed error handling when the log file could not be opened.

$ src/bitcoind -testnet -debuglogfile=/dfdf                                                                                                             
Error: Could not open debug log file /dfdf

(currently this segfaults afterwards, but that is due to an unrelated problem introduced in #10286, see #11783)

laanwj referenced this in commit bf72888e72 on Nov 28, 2017

laanwj referenced this in commit d31e5c1d0f on Nov 28, 2017

in src/init.cpp:1215 in 2501383615 outdated

1208 | @@ -1208,8 +1209,11 @@ bool AppInitMain(boost::thread_group& threadGroup, CScheduler& scheduler)
1209 |          ShrinkDebugFile();
1210 |      }
1211 |  
1212 | -    if (fPrintToDebugLog)
1213 | -        OpenDebugLog();
1214 | +    if (fPrintToDebugLog) {
1215 | +        if (!OpenDebugLog()) {
1216 | +            return InitError(strprintf("Could not open debug log file %s", GetDebugLogPath().string()));

promag commented at 12:12 PM on November 28, 2017:

Nit, missing test.

laanwj commented at 12:40 PM on November 28, 2017:

Will add a test, though testing this particular message only makes sense after #11783 goes in

laanwj commented at 2:39 PM on November 28, 2017:

Added test anyway, temporarily adding "Fix shutdown in case of errors during initialization" into here

promag commented at 12:13 PM on November 28, 2017: member

utACK 2501383.

Care to update release notes? At least add tag.

in src/init.cpp:345 in 2501383615 outdated

 341 | @@ -342,6 +342,7 @@ std::string HelpMessage(HelpMessageMode mode)
 342 |      if (showDebug)
 343 |          strUsage += HelpMessageOpt("-feefilter", strprintf("Tell other nodes to filter invs to us by our mempool min fee (default: %u)", DEFAULT_FEEFILTER));
 344 |      strUsage += HelpMessageOpt("-loadblock=<file>", _("Imports blocks from external blk000??.dat file on startup"));
 345 | +    strUsage += HelpMessageOpt("-debuglogfile=<dir>", _("Specify location of debug log file (default: debug.log in datadir)"));

promag commented at 12:54 PM on November 28, 2017:

Fix =<dir>.

laanwj commented at 2:40 PM on November 28, 2017:

Thanks, done

laanwj force-pushed on Nov 28, 2017

laanwj referenced this in commit e1fae70700 on Nov 28, 2017

laanwj force-pushed on Nov 28, 2017

jonasschnelli commented at 7:35 PM on November 28, 2017: contributor

utACK ad4e94a4aa8cebfa2147c47cd57098a2901b3e62

For me, it was not clear from the release notes and the init.cpp help line that one can use absolute paths (but maybe it's obvious).
What if someone uses -debuglogfile=wallet.dat?

in test/functional/loggingtest.py:31 in ad4e94a4aa outdated

  26 | +        self.restart_node(0, ["-debuglogfile=%s" % tempname])
  27 | +        assert(os.path.isfile(tempname))
  28 | +
  29 | +        # check that invalid log (relative) will cause error
  30 | +        self.stop_node(0)
  31 | +        self.assert_start_raises_init_error(0, ["-debuglogfile=ssdksjdf/sdasdfa/sdfsdfsfd"],

promag commented at 10:19 PM on November 28, 2017:

Replace with foo/foo.log? :trollface: (before squash).

laanwj commented at 8:11 AM on November 29, 2017:

Why? any invalid filename will do equally and this is as likely to stay invalid as anything.

promag commented at 8:26 AM on November 29, 2017:

Below you use foo/foo.log, not shydhehhaghdhdjs.

laanwj commented at 8:54 AM on November 29, 2017:

That's a different test case, there's no need for them to use the same (non-existent) file name.

ajtowns commented at 1:17 AM on December 1, 2017:

It's the only keyboard mashing in the codebase, by the looks? Something like "-debuglogfile=no/path/for/debug.log" or similar seems like it would be clearer. Having a similar path for both relative and absolute cases would make it a bit more obvious what the key difference that's being tested is too.

in test/functional/loggingtest.py:57 in ad4e94a4aa outdated

  35 | +        self.stop_node(0)
  36 | +        invalidname = os.path.join(self.options.tmpdir, "foo/foo.log")
  37 | +        self.assert_start_raises_init_error(0, ["-debuglogfile=%s" % invalidname],
  38 | +                "Error: Could not open debug log file")
  39 | +
  40 | +

promag commented at 10:23 PM on November 28, 2017:

~~Nit, remove 2nd empty line.~~

From PEP 8:

Blank Lines

Surround top-level function and class definitions with two blank lines.

in test/functional/loggingtest.py:7 in ad4e94a4aa outdated

   0 | @@ -0,0 +1,42 @@
   1 | +#!/usr/bin/env python3
   2 | +# Copyright (c) 2017 The Bitcoin Core developers
   3 | +# Distributed under the MIT software license, see the accompanying
   4 | +# file COPYING or http://www.opensource.org/licenses/mit-license.php.
   5 | +"""Test debug logging."""
   6 | +
   7 | +from test_framework.test_framework import BitcoinTestFramework
   8 | +from test_framework.util import assert_equal
   9 | +import os

promag commented at 10:26 PM on November 28, 2017:

Nit, from PEP 8:

Imports should be grouped in the following order:

standard library imports

related third party imports

local application/library specific imports

You should put a blank line between each group of imports.

Example: https://github.com/bitcoin/bitcoin/blob/26efc220a13aa3413f6e55e311e8991445104f82/test/functional/multiwallet.py#L5-L16

laanwj commented at 8:10 AM on November 29, 2017:

I literally copied this from another test (uacomment.py), so it should be consistent at least. PEP8 compliance is not really my goal, sorry.

promag commented at 8:27 AM on November 29, 2017:

Fine.

jnewbery commented at 6:13 PM on November 29, 2017:

My personal preference is to follow pep8 convention. I agree that it doesn't make sense to go and change all existing tests, but when adding new tests there's no harm in following the standard convention.

uacomment.py doesn't import any standard libraries, so pep8 import ordering isn't a consideration for that test.

promag commented at 11:20 PM on November 28, 2017: member

Tested ACK.

What if someone uses -debuglogfile=wallet.dat?

It will corrupt the db by appending the log and eventually rotate the content. Later we could only an existing file if it is text/plain?

promag commented at 1:10 AM on November 29, 2017: member

µnit, just test/functional/logging.py?

laanwj commented at 8:16 AM on November 29, 2017: member

It will corrupt the db by appending the log and eventually rotate the content. Later we could only an existing file if it is text/plain?

I guess it could do a berkeleydb magic check (from #11485) before opening the log for appending, but I'm not going to do so in this PR.

At least the walletdir makes it less likely people will overwrite an existing wallet. You can't 100% prevent people from overwriting wallets.

test/functional/logging.py

I first had it named by that, but renamed it to this because logging.py is more easily confused with logging of the test framework.

promag commented at 8:29 AM on November 29, 2017: member

I think this is good as it is.

laanwj commented at 9:02 AM on November 29, 2017: member

For me, it was not clear from the release notes and the init.cpp help line that one can use absolute paths (but maybe it's obvious).

Couldn't hurt mentioning it, I agree, will add it, though I don't think we mention this for any other options. Maybe we should though... for many options it's clear you can use an absolute path, but it's quite unclear what a relative path even does.

laanwj force-pushed on Nov 29, 2017

laanwj referenced this in commit 4b5f4f5b42 on Nov 29, 2017

laanwj commented at 10:10 AM on November 29, 2017: member

Ok, updated the message (as well as added DEFAULT_DEBUGLOGFILE constant) and squashed

promag commented at 2:38 PM on November 29, 2017: member

re-Tested ACK b382a24.

in doc/release-notes.md:95 in b382a246da outdated

  89 | @@ -90,6 +90,9 @@ Low-level RPC changes
  90 |    * `getmininginfo`
  91 |  - The wallet RPC `getreceivedbyaddress` will return an error if called with an address not in the wallet.
  92 |  
  93 | +Changed command-line options
  94 | +-----------------------------
  95 | +- `-debuglogfile=<file>` can be used to specify an alternative debug logging file.

jnewbery commented at 6:03 PM on November 29, 2017:

Can you update the text to say that this can be absolute or relative (just like you have for the help text: this can be an absolute path or a path relative to the data directory)?

laanwj commented at 9:22 AM on November 30, 2017:

The release notes are not documentation. This minor change does not warrant a long write-up in the release notes. If anyone wants to have documentation they can just look at bitcoind's help which is documentation.

in test/functional/loggingtest.py:8 in b382a246da outdated

   0 | @@ -0,0 +1,42 @@
   1 | +#!/usr/bin/env python3
   2 | +# Copyright (c) 2017 The Bitcoin Core developers
   3 | +# Distributed under the MIT software license, see the accompanying
   4 | +# file COPYING or http://www.opensource.org/licenses/mit-license.php.
   5 | +"""Test debug logging."""
   6 | +
   7 | +from test_framework.test_framework import BitcoinTestFramework
   8 | +from test_framework.util import assert_equal

jnewbery commented at 6:13 PM on November 29, 2017:

imported but unused

in test/functional/loggingtest.py:32 in b382a246da outdated

  27 | +        assert(os.path.isfile(tempname))
  28 | +
  29 | +        # check that invalid log (relative) will cause error
  30 | +        self.stop_node(0)
  31 | +        self.assert_start_raises_init_error(0, ["-debuglogfile=ssdksjdf/sdasdfa/sdfsdfsfd"],
  32 | +                "Error: Could not open debug log file")

jnewbery commented at 6:15 PM on November 29, 2017:

nit: pep8 convention would have this continuation line aligned with the opening parens of the line above, ie:

        self.assert_start_raises_init_error(0, ["-debuglogfile=ssdksjdf/sdasdfa/sdfsdfsfd"],
                                            "Error: Could not open debug log file")

again, this is more personal preference than a fast rule.

jnewbery commented at 6:16 PM on November 29, 2017: member

Tested ACK b382a246dafbb1895c66445bef2a5aac595933de with just a few nits

jonasschnelli commented at 7:11 PM on November 29, 2017: contributor

utACK b382a246dafbb1895c66445bef2a5aac595933de. I don't really care about PEP.

jnewbery commented at 7:41 PM on November 29, 2017: member

I don't really care about PEP.

I appreciate I may be in the minority here, but some reasoning for why I think it's a good idea to follow standard style conventions (at least when introducing new code):

having a canonical ordering for imports makes scanning much quicker for anyone reading the code.
people who have worked on other projects may be used to following PEP8, so will feel more comfortable when starting to contribute to this project. This import ordering is not only specified in PEP8, but also in the google python coding standard: https://google.github.io/styleguide/pyguide.html?showone=Imports_formatting#Imports_formatting and other style guides
it's good practice to always run a linter over the file whenever you save. That doesn't only highlight style nits, but also catches genuine bugs and makes it much less likely that you'll introduce a hard-to-track-down bug. Only committing files when they're free of lint warnings is a good safeguard against introducing unnecessary bugs.

https://stackoverflow.com/a/20763446/933705 has more rationale for import ordering.

Code is read far more than it's written, so a better question than 'why?' is 'why not?'. A small amount of effort now makes it easier for all future readers of the code to understand the intent.

jonasschnelli commented at 8:19 PM on November 29, 2017: contributor

@jnewbery. I generally agree.

The point I'm trying to make is that we tend to loose important focus or time with minor code ordering discussions. I think we should make contributors aware of the recommended rules and standard but then, at the same time, let it go a bit for the sake of focus on the important stuff.

Though I don't want to advocate bad code quality with this.

promag commented at 8:33 PM on November 29, 2017: member

@jnewbery +1

laanwj commented at 9:24 AM on November 30, 2017: member

Please, not the PEP8 talk again. Let's just agree to disagree. I want to move the project forward and it doesn't help if PRs stay stuck for ages on minor code cosmetics issues, certainly not in the tests. If you feel like spending a lot of time on that, by all means go ahead, but don't force all contributors to do so.

The point I'm trying to make is that we tend to loose important focus or time with minor code ordering discussions.

Yes, exactly.

laanwj force-pushed on Nov 30, 2017

laanwj commented at 10:08 AM on November 30, 2017: member

Anyyhow, updated to reorder the imports etc. And got rid of "Fix shutdown in case of errors during initialization" which is merged.

Add `-debuglogfile` option

This patch adds an option to configure the name and/or directory of the
debug log.

The user can specify either a relative path, in which case the path
is relative to the data directory. They can also specify an absolute
path to put the log anywhere else in the file system.

cf5f432c69

laanwj force-pushed on Nov 30, 2017

laanwj referenced this in commit 16fff80257 on Nov 30, 2017

laanwj added the label Utils/logging/libs on Nov 30, 2017

laanwj removed the label Docs and Output on Nov 30, 2017

jnewbery commented at 1:37 PM on November 30, 2017: member

@laanwj - I'm not going to argue about import ordering, but I do wholeheartedly disagree with your sentiment.

I want to move the project forward and it doesn't help if PRs stay stuck for ages on minor code cosmetics issues,

If I were nit sniping on a PR that had been open for a long time and was otherwise ready for merge, you may have a point. That's not what's happening here. This PR was opened two days ago. @promag and I are the only two people who have actually tested this code. When I write tested ACK, it means that I've: compiled the code, run the test suite over it, manually tested the edge cases, reviewed the code changes, and then suggested updates (including to improve readability). It's a little disheartening if the response is that you think I'm wasting your time.

I actually think that running a linter over new code and following our own style guide (https://github.com/bitcoin/bitcoin/blob/60d739eb49478a7d3a3c6def34467ce068580ad7/test/functional/README.md#style-guidelines) when submitting PRs actually saves time. It lowers the burden on reviewers and makes the code more likely to be maintained to a high standard.

certainly not in the tests

I've never understood the argument that standards should be lower for test code than product code. Style rules exist for future code readers. Tests should be read as much as product code, so style rules should be as important in test code as in product code. Some of our test code is rotten or abandoned precisely because it's unmaintainable or badly written. Better quality test code => better quality testing => better quality product.

promag commented at 2:03 PM on November 30, 2017: member

re-tested ACK 07c8970.

laanwj commented at 4:31 PM on November 30, 2017: member

It's a little disheartening if the response is that you think I'm wasting your time.

That's not what I was trying to suggest. Thanks for taking the time to test and review!

Sorry if I somehow overreacted.

On a high level I completely agree with you, it's just that following some style guide to the letter ranks lower in my code quality metrics than it does for you.

promag commented at 4:50 PM on November 30, 2017: member

IMO (keep) working for consistency throughout pays off on the long term.

in src/util.h:39 in cf5f432c69 outdated

  35 | @@ -36,6 +36,7 @@ int64_t GetStartupTime();
  36 |  static const bool DEFAULT_LOGTIMEMICROS = false;
  37 |  static const bool DEFAULT_LOGIPS        = false;
  38 |  static const bool DEFAULT_LOGTIMESTAMPS = true;
  39 | +extern const char * const DEFAULT_DEBUGLOGFILE;

ajtowns commented at 1:22 AM on December 1, 2017:

Would have expected this to have accompanied

extern const char * const BITCOIN_CONF_FILENAME;
extern const char * const BITCOIN_PID_FILENAME;

lower in the file.

laanwj commented at 3:28 AM on December 1, 2017:

I thought about that, but it's grouped with the other DEFAULT_ here, that makes more sense to me than grouping by type.

ajtowns commented at 7:54 AM on December 1, 2017:

The others are defaults that can be overridden via an option; calling it BITCOIN_DEBUGLOG_FILENAME could make it fit by both name and type?

laanwj commented at 9:11 AM on December 1, 2017:

I don't get you. This is the default for -debuglogfile, which can is an option. We use the convention DEFAULT_X where X is the option name everywhere. These are all constants that cannot be changed and are only used for getarg(...).

ajtowns commented at 9:35 AM on December 1, 2017:

Same thing is true for BITCOIN_{CONF,PID}_FILENAME - they're constants that can't be changed and are only used for getArg and HelpMessageOpt. But that's a better argument for renaming those to DEFAULT_X like almost every single other option, so nevermind.

laanwj commented at 9:53 AM on December 1, 2017:

I agree! the DEFAULT_ convention is more frequently used so would make sense to use everywhere. BITCOIN_CONF_FILENAME and BITCOIN_PID_FILENAME are very old options so they didn't follow that yet. Feel free to send a patch (but not to this PR as it's pretty out of scope :-)

in test/functional/loggingtest.py:18 in b96c6e8d60 outdated

  13 | +        self.num_nodes = 1
  14 | +        self.setup_clean_chain = True
  15 | +
  16 | +    def run_test(self):
  17 | +        # test default log file name
  18 | +        assert(os.path.isfile(os.path.join(self.nodes[0].datadir, "regtest", "debug.log")))

ajtowns commented at 1:43 AM on December 1, 2017:

Python asserts are statements not functions, so the bracketing probably isn't a good idea, even though lots of the other tests also do it :(

in test/functional/test_runner.py:129 in 07c8970522 outdated

 125 | @@ -126,6 +126,7 @@
 126 |      'p2p-fingerprint.py',
 127 |      'uacomment.py',
 128 |      'p2p-acceptblock.py',
 129 | +    'loggingtest.py',

ajtowns commented at 1:47 AM on December 1, 2017:

Consider naming the file "function_debuglogfile.py" to match the naming scheme in #11796 ?

laanwj commented at 3:32 AM on December 1, 2017:

function_ isn't one of the allowed prefixes according to #11796?

Also I think it would make sense to extend this test later to test other logging related things such as the logging RPC call, that's why I used a more general name than "debuglogfile".

ajtowns commented at 7:55 AM on December 1, 2017:

Gah. feature_. Apparently there's more that one two-syllable word beginning with f.

laanwj commented at 10:28 AM on December 1, 2017:

ok renamed to simply feature_logging.py

in test/functional/loggingtest.py:42 in 07c8970522 outdated

  28 | +
  29 | +        # check that invalid log (relative) will cause error
  30 | +        self.stop_node(0)
  31 | +        self.assert_start_raises_init_error(0, ["-debuglogfile=ssdksjdf/sdasdfa/sdfsdfsfd"],
  32 | +                                                "Error: Could not open debug log file")
  33 | +

ajtowns commented at 1:56 AM on December 1, 2017:

Doesn't actually test that relative paths with slashes will ever actually work. Probably doesn't matter, but if you like, https://github.com/laanwj/bitcoin/pull/5 remedies that.

laanwj commented at 3:44 AM on December 1, 2017:

Thanks, will pull that in.

ajtowns approved

ajtowns commented at 1:59 AM on December 1, 2017: member

ACK 07c897052273853777eff859970687c9a930f86e

laanwj force-pushed on Dec 1, 2017

test: Add test for `-debuglogfile` 23232422e5

doc: Update release notes for `-debuglogfile` 4158734946

test: Add tests for `-debuglogfile` with subdirs 5a7c09aebf

laanwj force-pushed on Dec 1, 2017

laanwj commented at 10:53 AM on December 1, 2017: member

Pulled in @ajtowns's changes, squashed the commit that changes assert(...) but not the one that adds tests (to keep author information).

jonasschnelli commented at 6:42 AM on December 2, 2017: contributor

Re-utACK 5a7c09aebf8b0229e9f320135472275d244a7a35

ajtowns commented at 3:54 AM on December 4, 2017: member

testedACK 5a7c09aebf8b0229e9f320135472275d244a7a35

laanwj merged this on Dec 4, 2017

laanwj closed this on Dec 4, 2017

laanwj referenced this in commit 24df9af816 on Dec 4, 2017

in test/functional/feature_logging.py:38 in 5a7c09aebf

  33 | +        self.assert_start_raises_init_error(0, ["-debuglogfile=%s" % (invalidname)],
  34 | +                                                "Error: Could not open debug log file")
  35 | +        assert not os.path.isfile(os.path.join(invdir, "foo.log"))
  36 | +
  37 | +        # check that invalid log (relative) works after path exists
  38 | +        self.stop_node(0)

jnewbery commented at 7:45 PM on December 4, 2017:

nit: not required (the previous attempt to start the node failed)

in test/functional/feature_logging.py:52 in 5a7c09aebf

  47 | +        self.assert_start_raises_init_error(0, ["-debuglogfile=%s" % invalidname],
  48 | +                                               "Error: Could not open debug log file")
  49 | +        assert not os.path.isfile(os.path.join(invdir, "foo.log"))
  50 | +
  51 | +        # check that invalid log (absolute) works after path exists
  52 | +        self.stop_node(0)

jnewbery commented at 7:45 PM on December 4, 2017:

nit: not required (the previous attempt to start the node failed)

in test/functional/feature_logging.py:37 in 5a7c09aebf

  32 | +        self.stop_node(0)
  33 | +        self.assert_start_raises_init_error(0, ["-debuglogfile=%s" % (invalidname)],
  34 | +                                                "Error: Could not open debug log file")
  35 | +        assert not os.path.isfile(os.path.join(invdir, "foo.log"))
  36 | +
  37 | +        # check that invalid log (relative) works after path exists

jnewbery commented at 7:46 PM on December 4, 2017:

nit: check that a previously invalid log (relative) works after path exists would be more accurate. Same for comment below.

jnewbery commented at 7:46 PM on December 4, 2017: member

post-merge tested ACK 5a7c09aebf8b0229e9f320135472275d244a7a35

HashUnlimited referenced this in commit 050cfaf11f on Mar 14, 2018

PastaPastaPasta referenced this in commit a5c3d3331b on Jan 17, 2020

PastaPastaPasta referenced this in commit 49345744c7 on Jan 17, 2020

PastaPastaPasta referenced this in commit 05bc8343a7 on Jan 22, 2020

PastaPastaPasta referenced this in commit a1c71b4cde on Jan 22, 2020

PastaPastaPasta referenced this in commit e4996fc941 on Jan 22, 2020

PastaPastaPasta referenced this in commit 3770ad9ab2 on Jan 22, 2020

PastaPastaPasta referenced this in commit 0211cbff80 on Jan 29, 2020

PastaPastaPasta referenced this in commit 83ce3bf78d on Jan 29, 2020

PastaPastaPasta referenced this in commit 696cd2869c on Jan 29, 2020

PastaPastaPasta referenced this in commit 9634b5f32c on Jan 29, 2020

PastaPastaPasta referenced this in commit 5091ab5bcc on Jan 29, 2020

PastaPastaPasta referenced this in commit 68bc3f31da on Jan 29, 2020

PastaPastaPasta referenced this in commit 608fad56a0 on Jan 30, 2020

random-zebra referenced this in commit b26dbc4e55 on Apr 9, 2020

zkbot referenced this in commit 4ffccda774 on Jun 4, 2020

furszy referenced this in commit 7d688a3152 on Nov 15, 2020

furszy referenced this in commit 59876a4873 on Dec 17, 2020

furszy referenced this in commit a60a7ee8e1 on Dec 17, 2020

furszy referenced this in commit 4188f0475f on Dec 17, 2020

furszy referenced this in commit 7343143695 on Feb 5, 2021

furszy referenced this in commit 218747678d on Feb 5, 2021

furszy referenced this in commit e7e9d4375a on Feb 10, 2021

furszy referenced this in commit 9e523a7b3e on Feb 14, 2021

ckti referenced this in commit 8ac6f5c0b4 on Mar 28, 2021

ckti referenced this in commit dd03301e1b on Mar 28, 2021

random-zebra referenced this in commit 096a0f9640 on May 17, 2021

gades referenced this in commit 05fe2d7eee on Jun 30, 2021

gades referenced this in commit 2bd785ac60 on Feb 10, 2022

gades referenced this in commit b80463372f on Feb 15, 2022

DrahtBot locked this on Feb 15, 2022